K3-F - CPE - Criptochip 2 PDF

To Institutul Național de Cercetare – Dezvoltare în Informatică
București
Subject Protecția datelor din memoria fiscală Custom MF001-02 în stil OTP legate de
model: K3-F
Memoria fiscală Custom MF001-02 constă în două blocuri fizice și funcționale:
1) Primul bloc este o memorie Flash de 2 megaocteți „Winbond W25Q16BSSI”

2) Al doilea bloc este un criptocip de securitate „Infineon SLB9670VQ20”, utilizat și ca
microcontroler
Primul bloc de memorie constă într-un dispozitiv Flash cu o capacitate de 2 megaocteți,

care conține toate datele pentru care legea impune arhivarea în acest tip de dispozitiv
numit memorie fiscală.
Al doilea bloc, criptocipul, îndeplinește trei funcții elementare:
- Pentru a menține siguranța intactă, conține atât chei confidențiale cât și certificate de
securitate;
- Derulează în manieră certificată toate procesele implicate în criptografie și

procesarea sigură a datelor;
- Oferă acces și protecție la scriere pe memoria flash împotriva încercării de corupere

ca microcontroler,
Criptocipul nostru este un microcontroler de securitate construit și programat de către

„Infineon”, al cărui cod de produs identifică în mod unic firmware-ul instalat în fabrică de
către producător și certifică, conform procedurilor din „Criterii comune”, caracteristicile de
siguranță extremă.
Protecția datelor conținute de memoria fiscală este garantată de un BLOC HARDWARE

obținut printr-o conexiune între PIN-ul memoriei fiscale cu PROTECȚIE la scriere (WP =
Write-Protect (Protecție la scriere)) și cipul de securitate Winbond (a se vedea diagrama).
1 to 2
Funcția de activare a scrierii în memoria fiscală se activează în doi pași:
- Primul pas are loc când cipul de securitate a recunoscut cheile de acces, iar al doilea
când cipul de securitate trebuie să dea acordul de scriere prin creșterea stării logice a
PIN-ului, oferind de fapt acces la scriere EXCLUSIVĂ când aplicația certificată scrie în
celulele de memorie alocate.
- La finalizarea ciclului de scriere, PIN-ul revine în poziția PROTECȚIE LA SCRIERE și

elimină posibilitatea de a modifica date din memorie.
Memoria și criptocipul integrale sunt atașate și acoperite cu o rășină epoxi care nu permite
modificarea echipamentului hardware; astfel, dispozitivul Custom MF001-02 este extrem de
sigur și protejat împotriva încercărilor de a modifica datele salvate în memoria fiscală.
Certificatul de siguranță al criptocipului este anexat la schema completă a memoriei fiscale și la

diagrama electrică a plăcii de circuite.
anexat la documentul:
 Trusted Platform Module SLB9670_2.0 datasheet
 Test report BSI-DSZ-CC-0998-2016 issued by BSI - Bundesamt für Sicherheit in der
Informationstechnik
Glimboca 05/02/2018
Alberto Campanini
Legal representative
2 to 2
BSI-DSZ-CC-0998-2016
for
Infineon Technologies AG Trusted Platform

Module SLB9670_2.0, v7.40.2098.00
from
Infineon Technologies AG
BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn
Phone +49 (0)228 99 9582-0, Fax +49 (0)228 9582-5477, Infoline +49 (0)228 99 9582-111
Certification Report V1.0 CC-Zert-327 V5.14

BSI-DSZ-CC-0998-2016 (*)
Trusted Platform Module
Infineon Technologies AG Trusted Platform Module SLB9670_2.0
v7.40.2098.00
SOGIS
from Infineon Technologies AG Recognition Agreement
PP Conformance: Protection Profile, TPM Library specification Family
“2.0”, Level 0 Revision 1.16, December 10, 2014,
Version 1.0, Trusted Computing Group
Functionality: PP conformant plus product specific extensions
Assurance: Common Criteria Part 3 conformant
EAL 4 augmented by ALC_FLR.1, AVA_VAN.4
The IT Product identified in this certificate has been evaluated at an approved evaluation
facility using the Common Methodology for IT Security Evaluation (CEM), Version 3.1
extended by Scheme Interpretations and CC Supporting Documents as listed in the
Certification Report for conformance to the Common Criteria for IT Security Evaluation
(CC), Version 3.1. CC and CEM are also published as ISO/IEC 15408 and ISO/IEC
18045.
(*) This certificate applies only to the specific version and release of the product in its
evaluated configuration and in conjunction with the complete Certification Report and
Notification. For details on the validity see Certification Report part A chapter 4
The evaluation has been conducted in accordance with the provisions of the certification Common Criteria
scheme of the German Federal Office for Information Security (BSI) and the conclusions Recognition Arrangement
for components up to
of the evaluation facility in the evaluation technical report are consistent with the evidence EAL 4
adduced.
This certificate is not an endorsement of the IT Product by the Federal Office for
Information Security or any other organisation that recognises or gives effect to this
certificate, and no warranty of the IT Product by the Federal Office for Information
Security or any other organisation that recognises or gives effect to this certificate, is
either expressed or implied.
Bonn, 28 January 2016
For the Federal Office for Information Security
Bernd Kowalski L.S.

Head of Department
Bundesamt für Sicherheit in der Informationstechnik

Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn
Phone +49 (0)228 99 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 99 9582-111
Certification Report BSI-DSZ-CC-0998-2016
This page is intentionally left blank.
4 / 44
BSI-DSZ-CC-0998-2016 Certification Report
Preliminary Remarks
Under the BSIG1 Act, the Federal Office for Information Security (BSI) has the task of
issuing certificates for information technology products.
Certification of a product is carried out on the instigation of the vendor or a distributor,
hereinafter called the sponsor.
A part of the procedure is the technical examination (evaluation) of the product according
to the security criteria published by the BSI or generally recognised security criteria.
The evaluation is normally carried out by an evaluation facility recognised by the BSI or by
BSI itself.
The result of the certification procedure is the present Certification Report. This report
contains among others the certificate (summarised assessment) and the detailed
Certification Results.
The Certification Results contain the technical description of the security functionality of
the certified product, the details of the evaluation (strength and weaknesses) and
instructions for the user.
1
Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009,
Bundesgesetzblatt I p. 2821
5 / 44
Contents
A. Certification........................................................................................................................7
1. Specifications of the Certification Procedure.................................................................7
2. Recognition Agreements................................................................................................7
3. Performance of Evaluation and Certification..................................................................9
4. Validity of the Certification Result...................................................................................9
5. Publication....................................................................................................................10
B. Certification Results.........................................................................................................11
1. Executive Summary.....................................................................................................12
2. Identification of the TOE...............................................................................................13
3. Security Policy..............................................................................................................14
4. Assumptions and Clarification of Scope.......................................................................15
5. Architectural Information...............................................................................................16
6. Documentation.............................................................................................................18
7. IT Product Testing.........................................................................................................18
8. Evaluated Configuration...............................................................................................24
9. Results of the Evaluation..............................................................................................24
10. Obligations and Notes for the Usage of the TOE.......................................................25
11. Security Target............................................................................................................26
12. Definitions...................................................................................................................26
13. Bibliography................................................................................................................28
C. Excerpts from the Criteria................................................................................................31
CC Part 1:........................................................................................................................31
CC Part 3:........................................................................................................................32
D. Annexes...........................................................................................................................39
6 / 44
A. Certification
1. Specifications of the Certification Procedure

The certification body conducts the procedure according to the criteria laid down in the
following:
● Act on the Federal Office for Information Security2
● BSI Certification and Approval Ordinance3
● BSI Schedule of Costs4
● Special decrees issued by the Bundesministerium des Innern (Federal Ministry of the
Interior)
● DIN EN ISO/IEC 17065 standard
● BSI certification: Scheme documentation describing the certification process
(CC-Produkte) [3]
● BSI certification: Scheme documentation on requirements for the Evaluation Facility, its
approval and licencing process (CC-Stellen) [3]
● Common Criteria for IT Security Evaluation (CC), Version 3.1 5 [1] also published as
ISO/IEC 15408.
● Common Methodology for IT Security Evaluation (CEM), Version 3.1 [2] also published
as ISO/IEC 18045.
● BSI certification: Application Notes and Interpretation of the Scheme (AIS) [4]
2. Recognition Agreements
In order to avoid multiple certification of the same product in different countries a mutual
recognition of IT security certificates - as far as such certificates are based on ITSEC or
CC - under certain conditions was agreed.
2.1. European Recognition of ITSEC/CC – Certificates (SOGIS-MRA)

The SOGIS-Mutual Recognition Agreement (SOGIS-MRA) Version 3 became effective in
April 2010. It defines the recognition of certificates for IT-Products at a basic recognition
level and, in addition, at higher recognition levels for IT-Products related to certain SOGIS
Technical Domains only.
2
Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009,
Bundesgesetzblatt I p. 2821
3
Ordinance on the Procedure for Issuance of Security Certificates and approval by the Federal Office for
Information Security (BSI-Zertifizierungs- und -Anerkennungsverordnung - BSIZertV) of 17 December
2014, Bundesgesetzblatt 2014, part I, no. 61, p. 2231
4
Schedule of Cost for Official Procedures of the Bundesamt für Sicherheit in der Informationstechnik
(BSI-Kostenverordnung, BSI-KostV) of 03 March 2005, Bundesgesetzblatt I p. 519
5
Proclamation of the Bundesministerium des Innern of 12 February 2007 in the Bundesanzeiger dated
23 February 2007, p. 3730
7 / 44
The basic recognition level includes Common Criteria (CC) Evaluation Assurance Levels
EAL 1 to EAL 4 and ITSEC Evaluation Assurance Levels E1 to E3 (basic). For
"Smartcards and similar devices" a SOGIS Technical Domain is in place. For "HW Devices
with Security Boxes" a SOGIS Technical Domains is in place, too. In addition, certificates
issued for Protection Profiles based on Common Criteria are part of the recognition
agreement.
The new agreement has been signed by the national bodies of Austria, Finland, France,
Germany, Italy, The Netherlands, Norway, Spain, Sweden and the United Kingdom. The
current list of signatory nations and approved certification schemes, details on recognition,
and the history of the agreement can be seen on the website at https://www.sogisportal.eu.
The SOGIS-MRA logo printed on the certificate indicates that it is recognised under the
terms of this agreement by the nations listed above.
This certificate is recognized under SOGIS-MRA for all assurance components selected.
2.2. International Recognition of CC – Certificates (CCRA)

The international arrangement on the mutual recognition of certificates based on the CC
(Common Criteria Recognition Arrangement, CCRA-2014) has been ratified on 08
September 2014. It covers CC certificates based on collaborative Protection Profiles (cPP)
(exact use), CC certificates based on assurance components up to and including EAL 2 or
the assurance family Flaw Remediation (ALC_FLR) and CC certificates for Protection
Profiles and for collaborative Protection Profiles (cPP).
The CCRA-2014 replaces the old CCRA signed in May 2000 (CCRA-2000). Certificates
based on CCRA-2000, issued before 08 September 2014 are still under recognition
according to the rules of CCRA-2000. For on 08 September 2014 ongoing certification
procedures and for Assurance Continuity (maintenance and re-certification) of old
certificates a transition period on the recognition of certificates according to the rules of
CCRA-2000 (i.e. assurance components up to and including EAL 4 or the assurance
family Flaw Remediation (ALC_FLR)) is defined until 08 September 2017.
As of September 2014 the signatories of the new CCRA-2014 are government
representatives from the following nations: Australia, Austria, Canada, Czech Republic,
Denmark, Finland, France, Germany, Greece, Hungary, India, Israel, Italy, Japan,
Malaysia, The Netherlands, New Zealand, Norway, Pakistan, Republic of Korea,
Singapore, Spain, Sweden, Turkey, United Kingdom, and the United States.
The current list of signatory nations and approved certification schemes can be seen on
the website: http://www.commoncriteriaportal.org.
The Common Criteria Recognition Arrangement logo printed on the certificate indicates
that this certification is recognised under the terms of this agreement by the nations listed
above.
As this certificate is a re-certification of a certificate issued according to CCRA-2000
this certificate is recognized according to the rules of CCRA-2000, i.e. up to and including
CC part 3 EAL 4 components. The evaluation contained the components ALC_FLR.1 and
AVA_VAN.4 that are not mutually recognised in accordance with the provisions of the
CCRA-2000, for mutual recognition the EAL 4 components of these assurance families are
relevant.
8 / 44
3. Performance of Evaluation and Certification

The certification body monitors each individual evaluation to ensure a uniform procedure, a
uniform interpretation of the criteria and uniform ratings.
The product Infineon Technologies AG Trusted Platform Module SLB9670_2.0,
v7.40.2098.00 has undergone the certification procedure at BSI. This is a re-certification
based on BSI-DSZ-CC-0965-2015. Specific results from the evaluation process
BSI-DSZ-CC-0965-2015 were re-used.
The evaluation of the product Infineon Technologies AG Trusted Platform Module
SLB9670_2.0, v7.40.2098.00 was conducted by TÜV Informationstechnik GmbH. The
evaluation was completed on 21 December 2015. TÜV Informationstechnik GmbH is an
evaluation facility (ITSEF)6 recognised by the certification body of BSI.
For this certification procedure the sponsor and applicant is: Infineon Technologies AG.
The product was developed by: Infineon Technologies AG.
The certification is concluded with the comparability check and the production of this
Certification Report. This work was completed by the BSI.
4. Validity of the Certification Result

This Certification Report only applies to the version of the product as indicated. The
confirmed assurance package is only valid on the condition that
● all stipulations regarding generation, configuration and operation, as given in the
following report, are observed,
● the product is operated in the environment described, as specified in the following report
and in the Security Target.
For the meaning of the assurance levels please refer to the excerpts from the criteria at
the end of the Certification Report or in the CC itself.
The Certificate issued confirms the assurance of the product claimed in the Security Target
at the date of certification. As attack methods evolve over time, the resistance of the
certified version of the product against new attack methods needs to be re-assessed.
Therefore, the sponsor should apply for the certified product being monitored within the
assurance continuity program of the BSI Certification Scheme (e.g. by a re-certification).
Specifically, if results of the certification are used in subsequent evaluation and certification
procedures, in a system integration process or if a user's risk management needs regularly
updated results, it is recommended to perform a re-assessment on a regular e.g. annual
basis.
In order to avoid an indefinite usage of the certificate when evolved attack methods require
a re-assessment of the products resistance to state of the art attack methods, the
maximum validity of the certificate has been limited. The certificate issued on 28 January
2016 is valid until 27 January 2021. Validity can be re-newed by re-certification.
The owner of the certificate is obliged:
1. when advertising the certificate or the fact of the product's certification, to refer to
the Certification Report as well as to provide the Certification Report, the Security
6
Information Technology Security Evaluation Facility
9 / 44
Target and user guidance documentation mentioned herein to any customer of the
product for the application and usage of the certified product,
2. to inform the Certification Body at BSI immediately about vulnerabilities of the
product that have been identified by the developer or any third party after issuance
of the certificate,
3. to inform the Certification Body at BSI immediately in the case that security relevant
changes in the evaluated life cycle, e.g. related to development and production sites
or processes, occur, or the confidentiality of documentation and information related
to the Target of Evaluation (TOE) or resulting from the evaluation and certification
procedure where the certification of the product has assumed this confidentiality
being maintained, is not given any longer. In particular, prior to the dissemination of
confidential documentation and information related to the TOE or resulting from the
evaluation and certification procedure that do not belong to the deliverables
according to the Certification Report part B, or for those where no dissemination
rules have been agreed on, to third parties, the Certification Body at BSI has to be
informed.
In case of changes to the certified version of the product, the validity can be extended to
the new versions and releases, provided the sponsor applies for assurance continuity (i.e.
re-certification or maintenance) of the modified product, in accordance with the procedural
requirements, and the evaluation does not reveal any security deficiencies.
5. Publication
The product Infineon Technologies AG Trusted Platform Module SLB9670_2.0,
v7.40.2098.00 has been included in the BSI list of certified products, which is published
regularly (see also Internet: https://www.bsi.bund.de and [5]). Further information can be
obtained from BSI-Infoline +49 228 9582-111.
Further copies of this Certification Report can be requested from the developer 7 of the
product. The Certification Report may also be obtained in electronic form at the internet
address stated above.
7
Alter Postweg 101
86159 Augsburg
10 / 44
B. Certification Results
The following results represent a summary of
● the Security Target of the sponsor for the Target of Evaluation,
● the relevant evaluation results from the evaluation facility, and
● complementary notes and stipulations of the certification body.
11 / 44
1. Executive Summary
The Target of Evaluation (TOE) is the Infineon Technologies AG Trusted Platform Module
SLB9670_2.0, (or SLB9670_2.0 in short), version v7.40.2098.00, including related
guidance documentation as described in the Security Target.
The TOE is an integrated circuit and software platform that provides computer
manufacturers with the core components of a subsystem used to assure authenticity,
integrity and confidentiality in e-commerce and internet communications within a Trusted
Computing Platform. The SLB9670_2.0 is a complete solution implementing the version
2.0 of the TCG Trusted Platform Module Library Family “2.0” Specification and the TCG
PC Client Specific Platform TPM Profile (PTP) Family “2.0” Specification. The
SLB9670_2.0 uses the Serial Peripheral Interface (SPI) for the integration into existing PC
mainboards.
The Security Target [6] is the basis for this certification. It is based on the certified
Protection Profile Protection Profile, TPM Library specification Family “2.0”, Level 0
Revision 1.16, December 10, 2014, Version 1.0, Trusted Computing Group [8].
The TOE Security Assurance Requirements (SAR) are based entirely on the assurance
components defined in Part 3 of the Common Criteria (see part C or [1], Part 3 for details).
The TOE meets the assurance requirements of the Evaluation Assurance Level EAL 4
augmented by ALC_FLR.1, AVA_VAN.4.
The TOE Security Functional Requirements (SFR) relevant for the TOE are outlined in the
Security Target [6], chapter 7.2. They are selected from Common Criteria Part 2 and some
of them are newly defined. Thus the TOE is CC Part 2 extended.
The TOE Security Functional Requirements are implemented by the following TOE
Security Functionality:
TOE Security Functionality Addressed issue
SF_CRY Cryptographic Support
SF_I&A Identification and Authentication
SF_G&T General and Test
SF_OBH Object Hierarchy
SF_TOP TOE Operation
Table 1: TOE Security Functionalities
For more details please refer to the Security Target [6], chapter 8.1.
The assets to be protected by the TOE are defined in the Security Target [6], chapter 4.1.
Based on these assets the TOE Security Problem is defined in terms of Assumptions,
Threats and Organisational Security Policies. This is outlined in the Security Target [6],
chapter 4.1, 4.2 and 4.3.
This certification covers the configurations of the TOE as outlined in chapter 8.
The vulnerability assessment results as stated within this certificate do not include a rating
for those cryptographic algorithms and their implementation suitable for encryption and
decryption (see BSIG Section 9, Para. 4, Clause 2).
12 / 44
The certification results only apply to the version of the product indicated in the certificate
and on the condition that all the stipulations are kept as detailed in this Certification
Report. This certificate is not an endorsement of the IT product by the Federal Office for
Information Security (BSI) or any other organisation that recognises or gives effect to this
certificate, and no warranty of the IT product by BSI or any other organisation that
recognises or gives effect to this certificate, is either expressed or implied.
2. Identification of the TOE

The Target of Evaluation (TOE) is called:
Infineon Technologies AG Trusted Platform Module SLB9670_2.0, v7.40.2098.00
The following table outlines the TOE deliverables:
No. Type Item / Identifier Release / Form of Delivery
Version
1 HW Trusted Platform Module v7.40.2098.00 Packaged module
SLB9670_2.0
2 DOC TPM Trusted Platform Module, Revision 1.60, Hardcopy or pdf-file
Application Note, User Guidance [10] 2015-08
3 DOC Trusted Platform Module TPM SLB Revision 1.4, Hardcopy or pdf-file
9670 TCG Family 2 Level 00 Rev. 2015-10-12
01.16 Databook
[11]
4 DOC TPM Trusted Platform Module Revision 1.2, Hardcopy or pdf-file
Version 2.0 SLB 9670VQ2.0 SLB 2015-10-26
9670XQ2.0 Errata and Updates [12]
5 DOC TPM Library Part 1 Architecture, Revision Public document, downloadable from
Family “2.0”, Level 00 01.16, https://www.trustedcomputinggroup.org
[13 Pt. 1] 2014-10-30
6 DOC TPM Library Part 2 Structures, Revision Public document, downloadable from
[13 Pt. 2] 2014-10-30
7 DOC TPM Library Part 3 Commands, Revision Public document, downloadable from
[13 Pt. 3] 2014-10-30
8 DOC TPM Library Part 4 Supporting Revision Public document, downloadable from
Routines, Family “2.0”, Level 00 01.16, https://www.trustedcomputinggroup.org
[13 Pt. 4] 2014-10-30
9 DOC TCG PC Client Specific Platform Revision Public document, downloadable from
TPM Profile for TPM TPM 2.0 (PTP), 00.43, https://www.trustedcomputinggroup.org
Family “2.0”, Level 00 2015-01-26
[14]
Table 2: Deliverables of the TOE
TOE identification
The TOE hardware and firmware is identified by name and version number as listed in the
following table:
Type Name Version number
Security IC with integrated firmware Trusted Platform Module SLB9670_2.0 v7.40.2098.00
Table 3: Identifiers of the TOE
13 / 44
The fabricated modules are contained in a VQFN-32-13 package. They are physically
labelled with the TOE reference by printing.
Table 4 lists the labelling according to [11, 6.3]:
Line Content Remark
1 SLB9670 –
2 VQ20 yy or XQ20 yy The <yy> is an internal FW indication (only at
manufacturing due to field upgrade option)
3 <Lot number> H <datecode> –
Table 4: Labelling of TOE module, package VQFN-32-13
The version number of the hardware and firmware can be read out electronically with the
command TPM2_GetCapability. The command lists the returned values as identified in
[11, 4.6.1]:
Property Vendor specific value
TPM_PT_MANUFACTURER “IFX”
TPM_PT_VENDOR_STRING_1 “SLB9”
TPM_PT_VENDOR_STRING_2 “670”
TPM_PT_VENDOR_STRING_3 NULL
TPM_PT_VENDOR_STRING_4 NULL
TPM_PT_FIRMWARE_VERSION_1 Major and minor version, e.g. 0x00070028 indicates v7.40
TPM_PT_FIRMWARE_VERSION_2 Build number, e.g. 0x0008320y, whereas y=0 means TPM is
certified and y=2 means TPM is not certified
Table 5: Vendor specific properties of TPM2_GetCapability
Using actual TOE samples provided for evaluation by the developer, the evaluator
confirmed that the actual version information as returned by TPM2_GetCapability matches
the expected values, i.e. TPM_PT_FIRMWARE_VERSION_1==0x00070028 and
TPM_PT_FIRMWARE_VERSION_2==0x00083202, together indicating the TOE version
v7.40.2098.02. The TOE version v7.40.2098.02 corresponds to the certified TOE Version
v7.40.2098.00.
TOE Delivery
The delivery of the TOE related confidential documentation (No. 2 to 4 in Table 2) is done
from the Infineon Technologies department AE at the site Munich by secure methods of
delivery, only after signing a non-disclosure agreement (NDA) and explicitly ordering.
Confidential documentation in paper form is personalised with a serial number which is
printed as a watermark on the document.
All confidential electronic documents are delivered encrypted by using PGP tools within an
already established PKI, so the confidentiality and integrity of the documentation is
ensured because only the good recipient is able to decrypt the code. The detection of
modification is reached by the functionality of the PGP tools.
3. Security Policy
The Security Policy is expressed by the set of Security Functional Requirements and
implemented by the TOE. It covers the following issues:
14 / 44
● Cryptographic Support: generation of random numbers, generation of asymmetric key

pairs, RSA and ECC digital signature (generation and verification), RSA, ECC and AES
data encryption and decryption, key destruction, the generation of hash values and the
generation and verification of MAC values.
● Identification and Authentication: mechanisms for the identification and authentication
capability to authorize the use of a Protected Object and Protected Capability using
authentication values or policies.
● General and Test: provision and enforcement of the TPM role model, startup- and self-
tests, preservation of secure state in case of failures or shutdown, and resistance to
physical manipulation or probing.
● Object Hierarchy: state control on all subjects, objects and operations, modification of
security attributes, provision of TPM hierarchy model, monitoring of data storage,
enforcement of object hierarchy.
● TOE Operation: access control on different subjects, objects and operations,
enforcement of different rules of operation and interaction between subjects and objects,
enabling and disabling of functions, enforcement of NVM restrictions, and creation of
evidence of origin.
Specific details concerning the above mentioned security policy can be found in chapter 8
of [6].
4. Assumptions and Clarification of Scope

The Assumptions defined in the Security Target and some aspects of Threats and
Organisational Security Policies are not covered by the TOE itself. These aspects lead to
specific security objectives to be fulfilled by the TOE-Environment. The following topics are
of relevance:
The Assumptions defined in the Security Target and some aspects of Threats and
Organisational Security Policies are not covered by the TOE itself. These aspects lead to
specific security objectives to be fulfilled by the TOE-Environment. The following topics are
of relevance:
● The TOE must be installed and configured properly for starting up the TOE in a secure
state. The security attributes of subjects and objects shall be managed securely by the
authorised user.
● The developer of the host platform must ensure that trusted processes indicate their
correct locality to the TPM and untrusted processes are able to assert just the locality 0
or Legacy only to the TPM.
● The IT environment must create EK and AK credentials trustworthy procedures for the
root of trust for reporting. The platform part of the root of trust for measurement provides
a representation of embedded data or program (measured values) to the TPM for
measurement.
● The platform part of the root of trust for measurement provides a representation of
embedded data or program code (measured values) to the TPM for measurement.
● The developer via AGD documentation will instruct the admin doing the upgrade how to
do the upgrade and that the admin should inform the end user regarding the Field
15 / 44
Upgrade process, its result, whether the installed firmware is certified or not, and the
version of the certified TPM.
● The ECDAA issuer must support a procedure for attestation without revealing the
attestation information based on the ECDAA signing operation.
Details can be found in the PP [8], chapter 5.2.
5. Architectural Information
The hardware of the TOE consists of the following parts:
● Security Peripherals (filters, sensors),
● Core System:
• with proprietary CPU implementation of the Intel MCS251 standard architecture
from functional perspective,
• Cache with post failure detection,
• Memory Encryption/Decryption Unit (MED),
• Memory Management Unit (MMU);
● Memories:
• Read-Only Memory (ROM),
• Random Access Memory (RAM),
• SOLID FLASHTM NVM;
● Coprocessors:
• Crypto2304T for asymmetric algorithms like RSA and ECC,
• Symmetric Crypto Co-processor AES standard (SCP),
• Hash accelerator (HASH) for the SHA-1 and SHA-256 algorithms,
• Checksum module (CRC);
● Random number generator (RNG),
● Interrupt module (INT),
● Timer (TIM),
● Buses (BUS):
• Memory Bus,
• Peripheral Bus;
● Serial Peripheral Interface (SPI),
● Tick Counter.
16 / 44
The firmware of the TOE includes an operating system that provides the functionality
specified by the Trusted Platform Module Library specification. The chip initialisation
routine with security checks and identification mode as well as test routines for production
testing are located in a separate test ROM. The firmware also provides the mechanism for
updating the protected capabilities once the TOE is in the field as defined in the
TPM_FieldUpgrade command of the Trusted Platform Module Library specification.
One part is the operating system which includes the TPM application, the System
Management and the Platform Primary Seed (PPS) of the Endorsement Key and is used
to operate the IC. The operating system includes also the capability for updating the
protected capabilities once the TOE is in the field (TPM_FieldUpgrade).
The entire operating system of the TOE is comprised of:
● TPM Secure Operating System:
• ComSys,
• DataStore,
• DevCtrl,
• ECC,
• FieldUpgrade,
• GPIO,
• HashSys,
• Locality,
• MACSys,
• OSStartup,
• PKcs1,
• PowMan,
• RandData,
• RMSInt,
• RSA,
• SymEnc,
• SysMan,
• SysSec,
• SelfTest,
• TaskCtrl,
• TimCtrl,
• Cryptographic Library;
● OS Abstraction Layer,
● Crypto Engine,
17 / 44
● Platform,
● Storage,
● Support,
● TPM Commands,
● PCR,
● Authorization,
● Attack Logic,
● Command Execution Engine.
The other firmware/software parts are:
● Self Test Software (STS) stored in the especially protected test ROM,
● Service Algorithm Minimal (SAM),
● Resource Management System (RMS),
● Cryptographic Library,
● Flash Loader.
6. Documentation
The evaluated documentation as outlined in Table 2 is being provided with the product to
the customer. This documentation contains the required information for secure usage of
the TOE in accordance with the Security Target.
Additional obligations and notes for secure usage of the TOE as outlined in chapter 10 of
this report have to be followed.
7. IT Product Testing
Summary of Test results and Effectiveness analysis
The tests performed by the developer were divided into six categories:
● Simulation Tests (design verification),
● Qualification Tests,
● Verification Tests,
● Security Evaluation Tests,
● Production Tests,
● Software Tests.
The developer tests cover all security functionalities and all security mechanisms as
identified in the functional specification.
The evaluators were able to repeat the tests of the developer, either using the tools and
TOE samples delivered to the evaluator, or at the developer’s site.
They performed independent tests to supplement, augment and verify the tests performed
by the developer. The evaluator included all security features and related interfaces into
18 / 44
the testing subset. For the developer tests repeated by the evaluators other test
parameters were used and the test equipment was varied.
The evaluation has shown that the actual version of the TOE provides the security
functionalities as specified by the developer. The test results confirm the correct
implementation of the TOE security functionalities.
For penetration testing the evaluators took all security functionalities into consideration.
Intensive penetration testing was planned based on the analysis results and performed for
the underlying mechanisms of security functionalities. The penetration tests considered
both the physical tampering of the TOE and attacks which do not modify the TOE
physically. The penetration tests results confirm that the TOE is resistant to attackers with
moderate attack potential in the intended environment for the TOE.
7.1. Developer's Test according to ATE_FUN

The developer’s testing effort can be summarised as follows:
TOE test configuration:
The tests are either performed with the TOE itself, or with a simulated or emulated
representation of the TOE, as appropriate for the respective test.
Developer’s testing approach:
All TSF and related security mechanisms, subsystems and modules, except those that are
not used by the TOE and internally blocked, are tested in order to assure complete
coverage of all SFR.
Different classes of tests are performed to test the TOE in a sufficient manner:
● Simulation Tests (design verification):
In the course of the development of the TOE simulation tests are carried out. These
simulation tests yield CRC sums, which are used in the further testing.
● Qualification Tests:
For each mask version a qualification test is performed. Via the results of these tests a
qualification report is generated. The positive result of the qualification is one part of the
necessary testing results documented with the qualification report. The qualification
report is completed after the verification testing (see below) and the security evaluation
(see below) are performed successfully. The tests performed and their results are listed
in the qualification report. The results of the tests are the basis on which it is decided,
whether the TOE is released to production.
● Verification Tests:
With these tests in user mode the functionality in the end user environment is checked.
● Security Evaluation Tests:
In the context of security evaluation testing the security mechanisms is tested again in
the user mode only focusing on security. Here is not only verified that the security
functionality is working as this was already tested on every single TOE during
production, but also it is tested how well the security functionality is working and the
effectiveness is calculated. This step is necessary as the mechanisms work together and
that must be evaluated in the user mode.
● Production Tests:
Before delivery on every chip production tests are performed. These tests use the CRC
19 / 44
checksums attained by the simulation tests. The aim of these tests is to check whether
each chip is functioning correctly.
● Software Tests:
The firmware and software of the TOE is developed and tested with software tools like
simulator, emulator and on hardware tools during the development phase.
Amount of developer testing performed:
The tests are performed on security mechanisms and subsystem and module level.
As demonstrated by ATE_COV.2, the developer has tested all security mechanisms and
TSFIs.
As demonstrated by ATE_DPT.1 the developer has tested all the TSF subsystems against
the TOE design and against the security architecture description.
TOE security functionality tested:
● SF_CRY: Cryptographic Support,
● SF_I&A: Identification and Authentication,
● SF_G&T: General and Test,
● SF_OBH: Object Hierarchy,
● SF_TOP: TOE Operation.
Overall developer testing results:
The TOE has passed all except seven tests defined in the developer’s test plan. The
developer provided a justification for each of the tests which failed. The evaluator analyzed
the impact on the TOE and comes to the conclusion that all of these tests will not have any
impact on the security and functionality of the TOE, so that all TSF has been successfully
tested.
The developer’s testing results demonstrate that the TSFs behave as specified.
7.2. Evaluator Testing

Independent Testing according to ATE_IND
The evaluator’s testing effort is described as follows, outlining the testing approach,
configuration, depth and results:
Testing approach:
The evaluator's objective regarding this aspect was to test the functionality of the TOE,
and to verify the developer's test results by repeating developer's tests and additionally
add independent tests.
In the course of the evaluation of the TOE the following classes of tests were carried out:
● Module tests,
● Simulation tests,
● Emulation tests,
● Tests in user mode,
● Tests in test mode,
20 / 44
● Hardware tests,
● Software tests.
With this kind of tests the entire security functionality of the TOE was tested.
TOE test configuration:
For the functional tests of the TOE the following test resources were used:
● Windows PC,
● Infineon PCI-SPI device (FPGA controlling SPI communication to TPM),
● Infineon TDDL.dll (SPI driver/interface),
● ActiveState ActivePython 2.7.8.10 32Bit (based on Python 2.7.8),
● TUVIT TPM TestSuite (implemented in Python).
The tests were performed using samples of the TOE provided by the developer. The TOE
samples were identified by their version information. The TOE samples used were identical
to those finally delivered to the user.
Selection criteria:
All security features (portions of the TSF) and related interfaces were tested. Therefore no
selection criteria are applied. All security features and related interfaces are tested
regarding their functional behavior. The tests were chosen to perform at minimum one test
for each security feature of TSF and related interfaces.
Interfaces tested:
The evaluator included all security features and related interfaces into the testing subset.
Portions of the TSF and related interfaces (in brackets) tested:
● SF_CRY: Cryptographic Support (HW interfaces, External Software Interfaces),
● SF_I&A: Identification and Authentication (HW interfaces, External Software Interfaces),
● SF_G&T: General and Test (HW interfaces, External Software Interfaces).
● SF_OBH: Object Hierarchy (HW interfaces, External Software Interfaces),
● SF_TOP: TOE Operation (HW interfaces, External Software Interfaces).
Developer tests performed:
The developer performed six categories of tests (see above at ATE_FUN):
● Simulation Tests (design verification),
● Qualification Tests,
● Verification Tests,
● Security Evaluation Tests,
● Production Tests,
● Software Tests.
The evaluator has checked the simulation tests, qualification tests, and Security Evaluation
tests of the developer by sampling. The evaluator’s sample of developer tests covers all
portions of the TSF (security features) and related interfaces.
21 / 44
The TSF and the interfaces were found to behave as specified.

The results of the developer tests, which have been repeated by the evaluator, matched
the results the developer stated.
Overall the TSF have been tested against the functional specification, the TOE design and
the security architecture description. The tests demonstrate that the TSF performs as
specified.
Penetration Testing according to AVA_VAN
The evaluator’s effort for penetrating testing can be summarised as follows:
Overview:
The penetration testing was partially performed using the developer’s testing environment,
partially using the test environment of the evaluation body.
All configurations of the TOE being intended to be covered by the current evaluation were
tested.
The overall test result is that no deviations were found between the expected and the
actual test results; moreover, no attack scenario with the attack potential Moderate was
actually successful.
Penetration testing approach:
The evaluator performed a systematic search for potential vulnerabilities and known
attacks. This search is based on an ongoing observation of public domain sources for
vulnerabilities and past experiences with this type of product by the evaluation facility and
on a methodical analysis of the evaluation documents. The search was performed for this
TOE during preparation of the penetration testing in September and October 2015.
Analysis why these vulnerabilities are not exploitable in the intended environment of the
TOE was done. If the rationale is suspect in the opinion of the evaluator penetration tests
are devised.
Even if the rationale is convincing in the opinion of the evaluator penetration tests are
devised for some vulnerabilities, especially to support the argument of non-practicability of
the exploiting time in case of SPA, DPA and FI attacks.
TOE test configurations:
For tests of the TOE firmware the following test resources were used:
● Windows PC,
● Infineon PCI-SPI device (FPGA controlling SPI communication to TPM),
● Infineon TDDL.dll (SPI driver/interface),
● ActiveState ActivePython 2.7.8.10 32Bit (based on Python 2.7.8),
● TUVIT TPM TestSuite (implemented in Python).
For LFI and side channel attacks the following test resources were used by the evaluator
in the technical security laboratory of the evaluation lab:
● Digital Oscilloscope,
22 / 44
● Passive Probe,
● Active Differential Probe,
● EM Probe,
● Delay Generator,
● Laser Fault Injection System,
● Proprietary measuring/analyzing software,
● Windows PC.
The LFI tests were performed using samples of the TOE provided by the developer. The
TOE samples used were specially prepared for testing, i.e. the die was exposed and the
locking mechanism was disabled.
Attack scenarios having been tested:
The following attack scenarios have been tested:
● Statistical tests of the TOE DRNG according to [4], AIS20 requirements.

● Find undocumented capabilities which are sent by the TOE as response to
TPM2_GetCapabilitiy command.
● Try to circumvent access control by injecting faults through laser light (LFI attack).
● Effectiveness of the TOE security functionality.
● Effectiveness of filters and detectors.
● Effectiveness of bus and memory encryption.
● Differential Fault Analysis.
● Simple and Differential Power Analysis.
● EMA / SEMA / DEMA Attacks.
● Effectiveness of deactivation of test functions.
● Bypass of dictionary attack counter.
● Intentional misuse of TPM commands.
● Brute force of authValues.
SFRs penetration tested:
The following TSF interfaces have been tested:
● Electrical interface (INT 1.2),

● Data Interface (INT 1.3),
● SF_CRY (INT 2.1),
● SF_I&A (INT 2.2),
● SF_G&T (INT 2.3),
● SF_OBH (INT 2.4),
● SF_TOP (INT 2.5).
23 / 44
All security features of the TOE have been addressed by penetration testing.
Verdict for the sub-activity:
The evaluator has performed penetration testing based on the systematic search for
potential vulnerabilities and known attacks in public domain sources and from the
methodical analysis of the evaluation documents.
During the evaluator’s penetration testing of potential vulnerabilities, the TOE operated as
specified.
All potential vulnerabilities are not exploitable in the intended environment for the TOE.
The TOE is resistant to attackers with Moderate attack potential in the intended
environment for the TOE.
8. Evaluated Configuration
This certification covers the following configurations of the TOE: Trusted Platform Module
SLB9670_2.0 in version v7.40.2098.00 as described in [6], [11] and [12].
9. Results of the Evaluation

9.1. CC specific results
The Evaluation Technical Report (ETR) [7] was provided by the ITSEF according to the
Common Criteria [1], the Methodology [2], the requirements of the Scheme [3] and all
interpretations and guidelines of the Scheme (AIS) [4] as relevant for the TOE.
The Evaluation Methodology CEM [2] was used.
The following guidance specific for the technology was used:
(i) The Application of Common Criteria to Integrated Circuits
(ii) Evaluation Methodology for Hardware Integrated Circuits
(see [4], AIS 25 and AIS 26). For RNG assessment the scheme interpretations AIS 20 and
AIS 31 were used (see [4]).
As a result of the evaluation the verdict PASS is confirmed for the following assurance
components:
● All components of the EAL 4 package including the class ASE as defined in the CC (see
also part C of this report)
● The components ALC_FLR.1, AVA_VAN.4 augmented for this TOE evaluation.
As the evaluation work performed for this certification procedure was carried out as a
re-evaluation based on the certificate BSI-DSZ-CC-0965-2015, re-use of specific
evaluation tasks was possible. The focus of this re-evaluation was on the parts of the TOE
affected by the replacement of the Low Pin Count (LPC) interface with the Serial
Peripheral Interface (SPI).
The evaluation has confirmed:
24 / 44
● PP Conformance: Protection Profile, TPM Library specification Family “2.0”, Level 0

Revision 1.16, December 10, 2014, Version 1.0, Trusted
Computing Group [8]
● for the Functionality: PP conformant plus product specific extensions
● for the Assurance: Common Criteria Part 3 conformant
EAL 4 augmented by ALC_FLR.1, AVA_VAN.4
For specific evaluation results regarding the development and production environment see
annex B in part D of this report.
The results of the evaluation are only applicable to the TOE as defined in chapter 2 and
the configuration as outlined in chapter 8 above.
9.2. Results of cryptographic assessment

The strength of the cryptographic algorithms was not rated in the course of this certification
procedure (see BSIG Section 9, Para. 4, Clause 2). But Cryptographic Functionalities with
a security level of lower than 100 bits can no longer be regarded as secure without
considering the application context. Therefore, for these functionalities it shall be checked
whether the related crypto operations are appropriate for the intended system. Some
further hints and guidelines can be derived from the 'Technische Richtlinie BSI TR-02102'
(https://www.bsi.bund.de).
Any Cryptographic Functionality that is marked in column 'Security Level above 100 Bits'
of Table 3 in [6] with 'no' achieves a security level of lower than 100 Bits (in general
context).
10. Obligations and Notes for the Usage of the TOE

The documents as outlined in Table 2 contain necessary information about the usage of
the TOE and all security hints therein have to be considered. In addition all aspects of
Assumptions, Threats and OSPs as outlined in the Security Target not covered by the TOE
itself need to be fulfilled by the operational environment of the TOE.
The customer or user of the product shall consider the results of the certification within his
system risk management process. In order for the evolution of attack methods and
techniques to be covered, he should define the period of time until a re-assessment of the
TOE is required and thus requested from the sponsor of the certificate.
If available, certified updates of the TOE should be used. If non-certified updates or
patches are available the user of the TOE should request the sponsor to provide a
re-certification. In the meantime a risk management process of the system using the TOE
should investigate and decide on the usage of not yet certified updates and patches or
take additional measures in order to maintain system security.
The limited validity for the usage of cryptographic algorithms as outlined in chapter 9 has
to be considered by the user and his system risk management process.
In addition, the following aspects need to be fulfilled when using the TOE:
● In order to fulfil the “Key Requirements” as formulated in [9], the Annex D from [10] must
be followed.
25 / 44
11. Security Target

For the purpose of publishing, the Security Target [6] of the Target of Evaluation (TOE) is
provided within a separate document as Annex A of this report.
12. Definitions
12.1. Acronyms
AIS Application Notes and Interpretations of the Scheme
BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for
Information Security, Bonn, Germany
BSIG BSI-Gesetz / Act on the Federal Office for Information Security
CCRA Common Criteria Recognition Arrangement
CC Common Criteria for IT Security Evaluation
CEM Common Methodology for Information Technology Security Evaluation
cPP Collaborative Protection Profile
EAL Evaluation Assurance Level
ETR Evaluation Technical Report
IT Information Technology
ITSEF Information Technology Security Evaluation Facility
PP Protection Profile
SAR Security Assurance Requirement
SFP Security Function Policy
SFR Security Functional Requirement
ST Security Target
TOE Target of Evaluation
TPM Trusted Platform Module
TSF TOE Security Functionality
12.2. Glossary
Augmentation - The addition of one or more requirement(s) to a package.
Collaborative Protection Profile - A Protection Profile collaboratively developed by an
International Technical Community endorsed by the Management Committee.
Extension - The addition to an ST or PP of functional requirements not contained in CC
part 2 and/or assurance requirements not contained in CC part 3.
Informal - Expressed in natural language.
Object - A passive entity in the TOE, that contains or receives information, and upon which
subjects perform operations.
Package - named set of either security functional or security assurance requirements
26 / 44
Protection Profile - A formal document defined in CC, expressing an implementation

independent set of security requirements for a category of IT Products that meet specific
consumer needs.
Security Target - An implementation-dependent statement of security needs for a specific
identified TOE.
Subject - An active entity in the TOE that performs operations on objects.
Target of Evaluation - An IT Product and its associated administrator and user guidance
documentation that is the subject of an Evaluation.
TOE Security Functionality - Combined functionality of all hardware, software, and
firmware of a TOE that must be relied upon for the correct enforcement of the SFRs.
27 / 44
13. Bibliography
[1] Common Criteria for Information Technology Security Evaluation, Version 3.1,
Part 1: Introduction and general model, Revision 4, September 2012
Part 2: Security functional components, Revision 4, September 2012
Part 3: Security assurance components, Revision 4, September 2012
http://www.commoncriteriaportal.org
[2] Common Methodology for Information Technology Security Evaluation (CEM),
Evaluation Methodology, Version 3.1, Rev. 4, September 2012,
http://www.commoncriteriaportal.org
[3] BSI certification: Scheme documentation describing the certification process
(CC-Produkte) and Scheme documentation on requirements for the Evaluation
Facility, approval and licencing (CC-Stellen), https://www.bsi.bund.de/zertifizierung
[4] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE 8
https://www.bsi.bund.de/AIS
[5] German IT Security Certificates (BSI 7148), periodically updated list published also
on the BSI Website, https://www.bsi.bund.de/zertifizierungsreporte
[6] Security Target BSI-DSZ-CC-0998-2016, Version 1.0, 2015-11-06, Security Target
Trusted Platform Module SLB9670_2.0, Infineon AG
[7] Evaluation Technical Report, V3, 2015-12-16, Evaluation Technical Report
Summary, TÜV Informationtechnik GmbH – Evaluation Body for IT Security,
(confidential document)
[8] Protection Profile, TPM Library specification Family “2.0”, Level 0 Revision 1.16,
December 10, 2014, Version 1.0, Trusted Computing Group,
ANSSI-CC-PP-2015/07
[9] Key Requirements on “Trusted Computing” and “Secure Boot”, by the German
Federal Government, August 2012, https://www.bsi.bund.de/
[10] TPM Trusted Platform Module, Application Note, User Guidance, Infineon
Technologies AG, V1.60, 2015-08 (confidential developer document)
[11] Trusted Platform Module TPM SLB 9670 TCG Family 2 Level 00 Rev. 01.16
Databook, Version 1.4, Infineon Technologies AG, 2015-10-12
8
specifically
• AIS 20, Version 3, Funktionalitätsklassen und Evaluationsmethodologie für deterministische
Zufallszahlengeneratoren
• AIS 25, Version 8, Anwendung der CC auf Integrierte Schaltungen including JIL Document and CC
Supporting Document
• AIS 26, Version 9, Evaluationsmethodologie für in Hardware integrierte Schaltungen including JIL
Document and CC Supporting Document
• AIS 31, Version 3, Funktionalitätsklassen und Evaluationsmethodologie für physikalische
Zufallszahlengeneratoren
• AIS 32, Version 7, CC-Interpretationen im deutschen Zertifizierungsschema
• AIS 38, Version 2, Reuse of evaluation results
28 / 44
[12] TPM Trusted Platform Module Version 2.0 SLB 9670VQ2.0 SLB 9670XQ2.0 Errata
and Updates, Version 1.2 Infineon Technologies AG, 2015-10-26
[13] TPM Library Family “2.0”, Level 00
Part 1 Architecture, Rev. 01.16, 2014-10-30
Part 2 Structures, Rev. 01.16, 2014-10-30
Part 3 Commands, Rev. 01.16, 2014-10-30
Part 4 Supporting Routines, Rev. 01.16, 2014-10-30
https://www.trustedcomputinggroup.org
[14] TCG PC Client Specific Platform TPM Profile for TPM TPM 2.0 (PTP), Family “2.0”,
Level 00. Revision 00.43, 2015-01-26.
https://www.trustedcomputinggroup.org
29 / 44
30 / 44
C. Excerpts from the Criteria

CC Part 1:
Conformance Claim (chapter 10.4)

“The conformance claim indicates the source of the collection of requirements that is met
by a PP or ST that passes its evaluation. This conformance claim contains a CC
conformance claim that:
● describes the version of the CC to which the PP or ST claims conformance.
● describes the conformance to CC Part 2 (security functional requirements) as either:
– CC Part 2 conformant - A PP or ST is CC Part 2 conformant if all SFRs in that
PP or ST are based only upon functional components in CC Part 2, or
– CC Part 2 extended - A PP or ST is CC Part 2 extended if at least one SFR in
that PP or ST is not based upon functional components in CC Part 2.
● describes the conformance to CC Part 3 (security assurance requirements) as either:
– CC Part 3 conformant - A PP or ST is CC Part 3 conformant if all SARs in that
PP or ST are based only upon assurance components in CC Part 3, or
– CC Part 3 extended - A PP or ST is CC Part 3 extended if at least one SAR in
that PP or ST is not based upon assurance components in CC Part 3.
Additionally, the conformance claim may include a statement made with respect to
packages, in which case it consists of one of the following:
● Package name Conformant - A PP or ST is conformant to a pre-defined package
(e.g. EAL) if:
– the SFRs of that PP or ST are identical to the SFRs in the package, or
– the SARs of that PP or ST are identical to the SARs in the package.
● Package name Augmented - A PP or ST is an augmentation of a predefined package
if:
– the SFRs of that PP or ST contain all SFRs in the package, but have at least
one additional SFR or one SFR that is hierarchically higher than an SFR in the
package.
– the SARs of that PP or ST contain all SARs in the package, but have at least
one additional SAR or one SAR that is hierarchically higher than an SAR in the
package.
Note that when a TOE is successfully evaluated to a given ST, any conformance claims of
the ST also hold for the TOE. A TOE can therefore also be e.g. CC Part 2 conformant.
Finally, the conformance claim may also include two statements with respect to Protection
Profiles:
● PP Conformant - A PP or TOE meets specific PP(s), which are listed as part of the
conformance result.
● Conformance Statement (Only for PPs) - This statement describes the manner in
which PPs or STs must conform to this PP: strict or demonstrable. For more
information on this Conformance Statement, see Annex D.”
31 / 44
CC Part 3:
Class APE: Protection Profile evaluation (chapter 10)

“Evaluating a PP is required to demonstrate that the PP is sound and internally consistent,
and, if the PP is based on one or more other PPs or on packages, that the PP is a correct
instantiation of these PPs and packages. These properties are necessary for the PP to be
suitable for use as the basis for writing an ST or another PP.
Assurance Class Assurance Components
APE_INT.1 PP introduction
APE_CCL.1 Conformance claims
Class APE: Protection APE_SPD.1 Security problem definition
Profile evaluation APE_OBJ.1 Security objectives for the operational environment

APE_OBJ.2 Security objectives
APE_ECD.1 Extended components definition
APE_REQ.1 Stated security requirements

APE_REQ.2 Derived security requirements
APE: Protection Profile evaluation class decomposition”
Class ASE: Security Target evaluation (chapter 11)

“Evaluating an ST is required to demonstrate that the ST is sound and internally
consistent, and, if the ST is based on one or more PPs or packages, that the ST is a
correct instantiation of these PPs and packages. These properties are necessary for the
ST to be suitable for use as the basis for a TOE evaluation.”
ASE_INT.1 ST introduction
ASE_CCL.1 Conformance claims
Class ASE: Security ASE_SPD.1 Security problem definition
Target evaluation ASE_OBJ.1 Security objectives for the operational environment

ASE_OBJ.2 Security objectives
ASE_ECD.1 Extended components definition
ASE_REQ.1 Stated security requirements

ASE_REQ.2 Derived security requirements
ASE_TSS.1 TOE summary specification

ASE_TSS.2 TOE summary specification with architectural design
summary
ASE: Security Target evaluation class decomposition
32 / 44
Security assurance components (chapter 7)

“The following Sections describe the constructs used in representing the assurance
classes, families, and components.“
“Each assurance class contains at least one assurance family.”
“Each assurance family contains one or more assurance components.”
The following table shows the assurance class decomposition.

ADV: Development ADV_ARC.1 Security architecture description
ADV_FSP.1 Basic functional specification
ADV_FSP.2 Security-enforcing functional specification
ADV_FSP.3 Functional specification with complete summary
ADV_FSP.4 Complete functional specification
ADV_FSP.5 Complete semi-formal functional specification with
additional error information
ADV_FSP.6 Complete semi-formal functional specification with
additional formal specification
ADV_IMP.1 Implementation representation of the TSF
ADV_IMP.2 Implementation of the TSF
ADV_INT.1 Well-structured subset of TSF internals
ADV_INT.2 Well-structured internals
ADV_INT.3 Minimally complex internals
ADV_SPM.1 Formal TOE security policy model
ADV_TDS.1 Basic design
ADV_TDS.2 Architectural design
ADV_TDS.3 Basic modular design
ADV_TDS.4 Semiformal modular design
ADV_TDS.5 Complete semiformal modular design
ADV_TDS.6 Complete semiformal modular design with formal
high-level design presentation
AGD: AGD_OPE.1 Operational user guidance
Guidance documents AGD_PRE.1 Preparative procedures
ALC_CMC.1 Labelling of the TOE
ALC_CMC.2 Use of a CM system
ALC_CMC.3 Authorisation controls
ALC_CMC.4 Production support, acceptance procedures and
automation
ALC_CMC.5 Advanced support
ALC_CMS.1 TOE CM coverage
ALC_CMS.2 Parts of the TOE CM coverage
ALC_CMS.3 Implementation representation CM coverage
ALC: Life cycle support ALC_CMS.4 Problem tracking CM coverage
ALC_CMS.5 Development tools CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security measures
ALC_DVS.2 Sufficiency of security measures
ALC_FLR.1 Basic flaw remediation
ALC_FLR.2 Flaw reporting procedures
ALC_FLR.3 Systematic flaw remediation
ALC_LCD.1 Developer defined life-cycle model
33 / 44

ALC_LCD.2 Measurable life-cycle model
ALC_TAT.1 Well-defined development tools
ALC_TAT.2 Compliance with implementation standards
ALC_TAT.3 Compliance with implementation standards - all parts
ATE_COV.1 Evidence of coverage
ATE_COV.2 Analysis of coverage
ATE_COV.3 Rigorous analysis of coverage
ATE: Tests ATE_DPT.1 Testing: basic design
ATE_DPT.2 Testing: security enforcing modules
ATE_DPT.3 Testing: modular design
ATE_DPT.4 Testing: implementation representation
ATE_FUN.1 Functional testing
ATE_FUN.2 Ordered functional testing
ATE_IND.1 Independent testing – conformance
ATE_IND.2 Independent testing – sample
ATE_IND.3 Independent testing – complete
AVA: Vulnerability AVA_VAN.1 Vulnerability survey
assessment AVA_VAN.2 Vulnerability analysis
AVA_VAN.3 Focused vulnerability analysis
AVA_VAN.4 Methodical vulnerability analysis
AVA_VAN.5 Advanced methodical vulnerability analysis
Assurance class decomposition
Evaluation assurance levels (chapter 8)

“The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the
level of assurance obtained with the cost and feasibility of acquiring that degree of
assurance. The CC approach identifies the separate concepts of assurance in a TOE at
the end of the evaluation, and of maintenance of that assurance during the operational use
of the TOE.
It is important to note that not all families and components from CC Part 3 are included in
the EALs. This is not to say that these do not provide meaningful and desirable
assurances. Instead, it is expected that these families and components will be considered
for augmentation of an EAL in those PPs and STs for which they provide utility.”
Evaluation assurance level (EAL) overview (chapter 8.1)

“Table 1 represents a summary of the EALs. The columns represent a hierarchically
ordered set of EALs, while the rows represent assurance families. Each number in the
resulting matrix identifies a specific assurance component where applicable.
As outlined in the next Section, seven hierarchically ordered evaluation assurance levels
are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered
inasmuch as each EAL represents more assurance than all lower EALs. The increase in
assurance from EAL to EAL is accomplished by substitution of a hierarchically higher
assurance component from the same assurance family (i.e. increasing rigour, scope,
and/or depth) and from the addition of assurance components from other assurance
families (i.e. adding new requirements).
These EALs consist of an appropriate combination of assurance components as described
in Chapter 7 of this CC Part 3. More precisely, each EAL includes no more than one
34 / 44
component of each assurance family and all assurance dependencies of every component
are addressed.
While the EALs are defined in the CC, it is possible to represent other combinations of
assurance. Specifically, the notion of “augmentation” allows the addition of assurance
components (from assurance families not already included in the EAL) or the substitution
of assurance components (with another hierarchically higher assurance component in the
same assurance family) to an EAL. Of the assurance constructs defined in the CC, only
EALs may be augmented. The notion of an “EAL minus a constituent assurance
component” is not recognised by the standard as a valid claim. Augmentation carries with
it the obligation on the part of the claimant to justify the utility and added value of the
added assurance component to the EAL. An EAL may also be augmented with extended
assurance requirements.
Evaluation assurance level 1 (EAL 1) - functionally tested (chapter 8.3)

“Objectives
EAL 1 is applicable where some confidence in correct operation is required, but the threats
to security are not viewed as serious. It will be of value where independent assurance is
required to support the contention that due care has been exercised with respect to the
protection of personal or similar information.
EAL 1 requires only a limited security target. It is sufficient to simply state the SFRs that
the TOE must meet, rather than deriving them from threats, OSPs and assumptions
through security objectives.
EAL 1 provides an evaluation of the TOE as made available to the customer, including
independent testing against a specification, and an examination of the guidance
documentation provided. It is intended that an EAL 1 evaluation could be successfully
conducted without assistance from the developer of the TOE, and for minimal outlay.
An evaluation at this level should provide evidence that the TOE functions in a manner
consistent with its documentation.”
Evaluation assurance level 2 (EAL 2) - structurally tested (chapter 8.4)

“Objectives
EAL 2 requires the co-operation of the developer in terms of the delivery of design
information and test results, but should not demand more effort on the part of the
developer than is consistent with good commercial practise. As such it should not require a
substantially increased investment of cost or time.
EAL 2 is therefore applicable in those circumstances where developers or users require a
low to moderate level of independently assured security in the absence of ready
availability of the complete development record. Such a situation may arise when securing
legacy systems, or where access to the developer may be limited.”
Evaluation assurance level 3 (EAL 3) - methodically tested and checked (chapter 8.5)
“Objectives
EAL 3 permits a conscientious developer to gain maximum assurance from positive
security engineering at the design stage without substantial alteration of existing sound
development practises.
35 / 44
EAL 3 is applicable in those circumstances where developers or users require a moderate

level of independently assured security, and require a thorough investigation of the TOE
and its development without substantial re-engineering.”
Evaluation assurance level 4 (EAL 4) - methodically designed, tested, and reviewed

(chapter 8.6)
“Objectives
EAL 4 permits a developer to gain maximum assurance from positive security engineering
based on good commercial development practises which, though rigorous, do not require
substantial specialist knowledge, skills, and other resources. EAL 4 is the highest level at
which it is likely to be economically feasible to retrofit to an existing product line.
moderate to high level of independently assured security in conventional commodity TOEs
and are prepared to incur additional security-specific engineering costs.”
Evaluation assurance level 5 (EAL 5) - semiformally designed and tested (chapter

8.7)
“Objectives
EAL 5 permits a developer to gain maximum assurance from security engineering based
upon rigorous commercial development practises supported by moderate application of
specialist security engineering techniques. Such a TOE will probably be designed and
developed with the intent of achieving EAL 5 assurance. It is likely that the additional costs
attributable to the EAL 5 requirements, relative to rigorous development without the
application of specialised techniques, will not be large.
high level of independently assured security in a planned development and require a
rigorous development approach without incurring unreasonable costs attributable to
specialist security engineering techniques.”
Evaluation assurance level 6 (EAL 6) - semiformally verified design and tested

(chapter 8.8)
“Objectives
EAL 6 permits developers to gain high assurance from application of security engineering
techniques to a rigorous development environment in order to produce a premium TOE for
protecting high value assets against significant risks.
EAL 6 is therefore applicable to the development of security TOEs for application in high
risk situations where the value of the protected assets justifies the additional costs.”
Evaluation assurance level 7 (EAL 7) - formally verified design and tested

(chapter 8.9)
“Objectives
EAL 7 is applicable to the development of security TOEs for application in extremely high
risk situations and/or where the high value of the assets justifies the higher costs. Practical
application of EAL 7 is currently limited to TOEs with tightly focused security functionality
that is amenable to extensive formal analysis.”
36 / 44
Assurance Assurance Assurance Components by

Class Family Evaluation Assurance Level
EAL 1 EAL 2 EAL 3 EAL 4 EAL 5 EAL 6 EAL 7
Development ADV_ARC 1 1 1 1 1 1
ADV_FSP 1 2 3 4 5 5 6
ADV_IMP 1 1 2 2
ADV_INT 2 3 3
ADV_SPM 1 1
ADV_TDS 1 2 3 4 5 6
Guidance AGD_OPE 1 1 1 1 1 1 1
Documents AGD_PRE 1 1 1 1 1 1 1
Life cycle ALC_CMC 1 2 3 4 4 5 5
Support ALC_CMS 1 2 3 4 5 5 5
ALC_DEL 1 1 1 1 1 1
ALC_DVS 1 1 1 2 2
ALC_FLR
ALC_LCD 1 1 1 1 2
ALC_TAT 1 2 3 3
Security Target ASE_CCL 1 1 1 1 1 1 1

Evaluation
ASE_ECD 1 1 1 1 1 1 1
ASE_INT 1 1 1 1 1 1 1
ASE_OBJ 1 2 2 2 2 2 2
ASR_REQ 1 2 2 2 2 2 2
ASE_SPD 1 1 1 1 1 1
ASE_TSS 1 1 1 1 1 1 1
Tests ATE_COV 1 2 2 2 3 3
ATE_DPT 1 1 3 3 4
ATE_FUN 1 1 1 1 2 2
ATE_IND 1 2 2 2 2 2 3
Vulnerability AVA_VAN 1 2 2 3 4 5 5
assessment
Table 1: Evaluation assurance level summary”
37 / 44
Class AVA: Vulnerability assessment (chapter 16)
“The AVA: Vulnerability assessment class addresses the possibility of exploitable

vulnerabilities introduced in the development or the operation of the TOE.”
Vulnerability analysis (AVA_VAN) (chapter 16.1)

“Objectives
Vulnerability analysis is an assessment to determine whether potential vulnerabilities
identified, during the evaluation of the development and anticipated operation of the TOE
or by other methods (e.g. by flaw hypotheses or quantitative or statistical analysis of the
security behaviour of the underlying security mechanisms), could allow attackers to violate
the SFRs.
Vulnerability analysis deals with the threats that an attacker will be able to discover flaws
that will allow unauthorised access to data and functionality, allow the ability to interfere
with or alter the TSF, or interfere with the authorised capabilities of other users.”
38 / 44
D. Annexes
List of annexes of this certification report
Annex A: Security Target provided within a separate document.
Annex B: Evaluation results regarding development
and production environment
39 / 44
40 / 44
Annex B of Certification Report BSI-DSZ-CC-0998-2016
Evaluation results regarding

development and production environment
The IT product Infineon Technologies AG Trusted Platform Module SLB9670_2.0,

v7.40.2098.00 (Target of Evaluation, TOE) has been evaluated at an approved evaluation
facility using the Common Methodology for IT Security Evaluation (CEM), Version 3.1
extended by Scheme Interpretations as listed in the Certification Report and CC
Supporting Documents for conformance to the Common Criteria for IT Security Evaluation
(CC), Version 3.1.
As a result of the TOE certification, dated 28 January 2016, the following results regarding
the development and production environment apply. The Common Criteria assurance
requirements ALC – Life cycle support (i.e. ALC_CMC.4, ALC_CMS.4, ALC_DEL.1,
ALC_DVS.1, ALC_LCD.1, ALC_TAT.1, ALC_FLR.1) are fulfilled for the development and
production sites of the TOE listed below:
Name of site / Address Type of site Date of last
Company name audit
Agrate - DNP DNP Photomask Europe S.p.A. Mask Production 2015-09-30
Via C. Olivetti 2/A
20041 Agrate Brianza
Italy
Augsburg Infineon Technologies AG Development 2015-02-27
Alter Postweg 101
86159 Augsburg
Germany
Bangalore Infineon Technologies India Pvt. Ltd. SW Development and 2015-06-11
Kalyani Platina, Sy. No. 6 & 24 Testing
Kundanahalli Village
Krishnaraja Puram Hobli
Bangalore
"India – 560066
India"
Bukarest Infineon Technologies Romania Development 2014-06-03
Blvd. Dimitrie Pompeiu Nr. 6
Sector 2
020335 Bucharest
Romania
Corbeil Essones - Toppan Photomask, Inc. Mask Production 2014-05-14
Toppan European Technology Center
Boulevard John Kennedy 224
91105 Corbeil Essonnes
France
Dresden Infineon Technologies Dresden GmbH Wafer Production, 2014-07-08
& Co. OHG Initialization and
Königsbrücker Str. 180 Pre-personalizaiton
01099 Dresden
Germany
41 / 44

Company name audit
Dresden - Toppan Toppan Photomask, Inc Mask Production 2014-07-09
Rähnitzer Allee 9
01109 Dresden
Germany
Graz / Villach / Infineon Technologies Austria AG Development, IT 2014-10-14
Klagenfurt Development Center Graz
Babenbergerstr. 10
8020 Graz
Austria
Infineon Technologies Austria AG
Siemensstr. 2
9500 Villach
Austria
Infineon Technologies Austria AG
Lakeside B05
9020 Klagenfurt
Austria
Großostheim - Infineon Technology AG Distribution Center 2015-07-17
K&N DCE
Kühne & Nagel
Stockstädter Strasse 10 – Building 8A
63762 Großostheim
Germany
Hayward - K&N Kuehne & Nagel Distribution Center 2014-12-03
30805 Santana Street
Hayward, CA 94544
USA
Hsin-Chu - ARDT Ardentec Corporation Wafer Test 2015-09-17
No. 3, Gungye 3rd Rd.,
Hsin-Chu Industrial Park, Hu-Kou,
Hsin-Chu Hsien, Taiwan 30351,
R.O.C.
Taiwan 30351, R.O.C.
Manila - Amkor Amkor Technology Philippines Module Mounting 2015-10-17
Km. 22 East Service Rd.
South Superhighway
Muntinlupa City 1702
Philippines
Amkor Technology Philippines
119 North Science Avenue
Laguna Technopark, Binan
Laguna 4024
Philippines
Morgan Hill Infineon Technologies North America Inlay Testing, 2014-12-02
Corp. Distribution Center
18275 Serene Drive
Morgan Hill, CA 95037
USA
Munich Infineon Technologies AG Development 2014-05-28
Am Campeon 1-12 2014-07-27
85579 Neubiberg
Germany
42 / 44

Company name audit
Regensburg-West Infineon Technologies AG Module Mounting, Inlay 2015-07-20
Wernerwerkstraße 2 Mounting
93049 Regensburg
Germany
Singapore - DHL DHL Exel Supply Chain Distribution Center 2015-10-12
Richland Business Centre
11 Bedok North Ave 4, Level 3,
Singapore 489949
Singapore Kallang Infineon Technologies Asia Pacific Module Mounting, 2015-09-14
PTE Ltd. Electrical module
168 Kallang Way testing
Singapore 349253
Wuxi Infineon Technologies (Wuxi) Co. Ltd. Module Mounting, 2015-10-14
No. 118, Xing Chuang San Lu Distribution Center
Wuxi-Singapore Industrial Park
Wuxi 214028, Jiangsu
P.R. China
For the sites listed above, the requirements have been specifically applied in accordance
with the Security Target [6]. The evaluators verified, that the threats, security objectives
and requirements for the TOE life cycle phases up to delivery (as stated in the Security
Target [6]) are fulfilled by the procedures of these sites.
43 / 44
44 / 44
Security Target
Trusted Platform Module

SLB9670_2.0
Common Criteria CCv3.1 EAL4 augmented (EAL4+)
Resistance to attackers with MODERATE attack potential
Version: 1.1
Date: 2016-04-14
Autor: Jürgen Noller
PUBLIC
Edition 1.1
Published by
81726 Munich, Germany
© 2014 Infineon Technologies AG
All Rights Reserved.
Legal Disclaimer
The information given in this document shall in no event be regarded as a guarantee of conditions
or characteristics. With respect to any examples or hints given herein, any typical values stated
herein and/or any information regarding the application of the device, Infineon Technologies
hereby disclaims any and all warranties and liabilities of any kind, including without limitation,
warranties of non-infringement of intellectual property rights of any third party.
Information
For further information on technology, delivery terms and conditions and prices, please contact the
nearest Infineon Technologies Office (www.infineon.com).
Warnings
Due to technical requirements, components may contain dangerous substances. For information
on the types in question, please contact the nearest Infineon Technologies Office.
Infineon Technologies components may be used in life-support devices or systems only with the
express written approval of Infineon Technologies, if a failure of such components can reasonably
be expected to cause the failure of that life-support device or system or to affect the safety or
effectiveness of that device or system. Life support devices or systems are intended to be
implanted in the human body or to support and/or maintain and sustain and/or protect human life. If
they fail, it is reasonable to assume that the health of the user or other persons may be
endangered.
Security Target for SLB9670_2.0
REVISION HISTORY
1.0 2015-11-06 Final Version
1.1 2016-04-14 New software version v7.41 added
Trademarks of Infineon Technologies AG

AURIX™, C166™, CAMPEON™, CanPAK™, CIPOS™, CIPURSE™, CoolGaN™, CoolMOS™,
CoolSiC™, CoolSET™, CORECONTROL™, CROSSAVE™, DI-POL™, DrBLADE™, EasyPIM™,
EconoBRIDGE™, EconoDUAL™, EconoPACK™, EconoPIM™, EiceDRIVER™, eupec™,i-
Wafer™ (device), FCOS™, ISOFACE™, HybridPACK™, HITFET™, Infineon™, IsoPACK™,
MIPAQ™, ModSTACK™, my-d™, NovalithIC™, OmniTune™, OPTIGA™, OptiMOS™, ORIGA™,
PrimePACK™, PrimeSTACK™, POWERCODE™, PRIMARION™, PROFET™, PRO-SIL™,
RASIC™, ReverSave™, SatRIC™, SIEGET™, SIPMOS™, SOLID FLASH™, SPOC™,
SmartLEWIS™, TEMPFET™, thinQ!™, TriCore™, TRENCHSTOP™,
Last Trademark Update 2014-06-04
SLB9670_2.0 v1.1 3 of 59
TABLE OF CONTENTS
1 SECURITY TARGET INTRODUCTION (ASE_INT) ................................................................................. 5
1.1 SECURITY TARGET AND TARGET OF EVALUATION REFERENCE ............................................................... 5
1.2 TARGET OF EVALUATION OVERVIEW ..................................................................................................... 7
2 TARGET OF EVALUATION DESCRIPTION ............................................................................................ 8
2.1 TOE DEFINITION .................................................................................................................................. 8
2.2 SCOPE OF THE TOE ........................................................................................................................... 15
2.2.1 Hardware of the TOE ............................................................................................................... 15
2.2.2 Firmware of the TOE ............................................................................................................... 16
2.2.3 Guidance documentation ......................................................................................................... 16
2.2.4 Forms of delivery ..................................................................................................................... 16
2.2.5 Production sites ....................................................................................................................... 17
2.2.6 Life cycle of the TOE ............................................................................................................... 17
3 CONFORMANCE CLAIMS (ASE_CCL) ................................................................................................. 18
3.1 CC CONFORMANCE CLAIM ................................................................................................................. 18
3.2 PP CLAIM .......................................................................................................................................... 18
3.3 PACKAGE CLAIM ................................................................................................................................ 18
3.4 CONFORMANCE CLAIM RATIONALE...................................................................................................... 18
3.5 APPLICATION NOTES .......................................................................................................................... 18
4 SECURITY PROBLEM DEFINITION (ASE_SPD) .................................................................................. 19
4.1 ASSETS AND THREATS ....................................................................................................................... 19
4.2 ORGANISATIONAL SECURITY POLICIES ................................................................................................ 19
4.3 ASSUMPTIONS ................................................................................................................................... 19
5 SECURITY OBJECTIVES (ASE_OBJ) .................................................................................................. 20
5.1 SECURITY OBJECTIVES FOR THE TOE ................................................................................................. 20
5.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ............................................................ 20
5.3 SECURITY OBJECTIVES RATIONALE ..................................................................................................... 20
6 EXTENDED COMPONENTS DEFINITION (ASE_ECD) ........................................................................ 21
7 IT SECURITY REQUIREMENTS (ASE_REQ)........................................................................................ 22
7.1 PREFACE REGARDING SECURITY LEVEL RELATED TO CRYPTOGRAPHY .................................................. 22
7.2 SECURITY FUNCTIONAL REQUIREMENTS FOR THE TOE ........................................................................ 25
7.2.1 Extended Component FCS_RNG.1 ......................................................................................... 38
7.3 SECURITY ASSURANCE REQUIREMENTS .............................................................................................. 39
7.4 SECURITY REQUIREMENTS RATIONALE ............................................................................................... 40
8 TOE SUMMARY SPECIFICATION (ASE_TSS) ..................................................................................... 41
8.1 TOE SECURITY FEATURES ................................................................................................................. 41
8.1.1 SF_CRY - Cryptographic Support ........................................................................................... 41
8.1.2 SF_I&A - Identification and Authentication .............................................................................. 42
8.1.3 SF_G&T – General and Test ................................................................................................... 43
8.1.4 SF_OBH - Object Hierarchy .................................................................................................... 45
8.1.5 SF_TOP – TOE Operation ....................................................................................................... 46
8.1.6 Assignment of Security Functional Requirements ................................................................... 49
8.2 SECURITY FUNCTION POLICY .............................................................................................................. 52
9 REFERENCE ........................................................................................................................................... 53
9.1 LITERATURE....................................................................................................................................... 53
9.2 LIST OF ABBREVIATIONS ..................................................................................................................... 55
9.3 GLOSSERY......................................................................................................................................... 56
SLB9670_2.0 v1.1 4 of 59
1 Security Target Introduction (ASE_INT)
This section contains the document management and provides an information overview. The
Security Target (ST) identification provides the labelling and descriptive information necessary to
identify, catalogue, register, and cross-reference a ST. The ST overview summarizes the profile in
narrative form and provides sufficient information for a potential user to determine whether the ST
is of interest. The overview can also be used as a standalone abstract for ST catalogues and
registers.
1.1 Security Target and Target of Evaluation Reference

The title of the security target (ST) is Security Target Trusted Platform Module SLB9670_2.0.
The security target has the version 1.1 and is dated 2016-04-14.
The Target of Evaluation (TOE) is a security IC (Security Controller) with integrated firmware
(operating system) and guidance documentation, which is named Trusted Platform Module
SLB9670_2.0, is internally registered under the development code v7.40.2098.00 and
v7.41.2375.00.
The Security Target is based on the Trusted Computing Group
―Protection Profile PC Client Specific Trusted Platform Module Specification Version 2.0; Level 0;
Revision 116‖ (PP, [8]).
The Protection Profile and the Security Target are built in accordance with Common Criteria V3.1.
SLB9670_2.0 v1.1 5 of 59
Version Date Registration
Security Target 1.1 2016-04-14 Security Target Trusted Platform Module
SLB9670_2.0
Target of v7.40.2098.00 Trusted Platform Module SLB9670_2.0
Evaluation and
v7.41.2375.00
Protection 1.0 2014-12-10 Protection Profile PC Client Specific TPM
Profile TPM Library specification Family ―2.0‖
Level 0 Revision 1.16
Rev. 01.16 October 30, Trusted Platform Module Library
2014 Part 1: Architecture,
Family ‖2.0‖ Level 00 Revision 01.16
2014 Part 2: Structures
2014 Part 3: Commands
Rev 01.16 October 30, Trusted Platform Module Library
2014 Part 4: Supporting Routines
Rev. 00.43 January 26, TCG PC Client Specific Platform TPM Profile
2015 for TPM 2.0 (PTP), Family ―2.0‖,
Level 00 Revision 00.43
Rev. 1.4 2015-10-12 Trusted Platform Module TPM SLB9670
TCG Family 2 Level 00 Rev.01.16 Databook
Rev. 1.5 2016-04-08 Trusted Platform Module TPM SLB9670
TCG Family 2 Level 00 Rev.01.16 Databook
Rev. 1.60 2015-08 TPM Trusted Platform Module Version 2.0
Application Note User Guidance
Rev. 1.5 2016-04-11 TPM Trusted Platform Module Version 2.0
Errata and Updates
3.1 September Common Criteria for Information Technology
Rev 4 2012 Security Evaluation
Part 1: Introduction and general model
CCMB-2012-09-001
Part 2: Security functional requirements
CCMB-2012-09-002
Part 3: Security Assurance Components
CCMB-2012-09-003
Table 1: Identification
Remarks to the Target of Evaluation (TOE):
The TOE of this Security Target encloses different derivative, all have the same TOE version
v7.40.2098.00 and v7.41.2375.00. The hardware and the firmware/software of the derivatives are
identical (the version is for all v7.40.2098.00 and v7.41.2375.00), the only difference between the
derivatives are the extended temperature range, the packaging and the own intermediated IFX
certificate. The derivatives are listed in the document TPM Trusted Platform Module Version 2.0
Errata and Updates [13] in section 6 ―Sales Order Code‖. The document Trusted Platform Module
TPM SLB9670 TCG Family 2 Level 00 Rev.01.16 Databook [14] gives in section 4.5.1 ―TPM
Properties‖ a description to read out the version of the TOE.
SLB9670_2.0 v1.1 6 of 59
1.2 Target of Evaluation Overview
This Security Target (ST) describes the target of evaluation (TOE) known as the Trusted Platform
Module SLB9670_2.0 and gives a summary product definition. In the following description the
expressions SLB9670_2.0 or TPM stands for all the TOE derivates of the TOE.
The Trusted Platform Module SLB9670_2.0, called TPM or SLB9670_2.0 in the following text, is an
integrated circuit and software platform that provides computer manufacturers with the core
components of a subsystem used to assure authenticity, integrity and confidentiality in e-
commerce and internet communications within a Trusted Computing Platform. The SLB9670_2.0 is
a complete solution implementing the version 2.0 of the TCG Trusted Platform Module Library,
Family ―2.0‖, [5], [6], [7], [10] and the TCG PC Client Specific Platform TPM Profile (PTP) Family
―2.0‖ Specification [9].
The SLB9670_2.0 uses the Serial Peripheral Interface (SPI) for the integration into existing PC
mainboards. The SLB9670_2.0 is basically a secure controller with the following added
functionality:
 Random number generator (DRBG)
 Asymmetric key generation (RSA keys with key length up to 2048 bit, EC keys with key
length 256 bits)
 Symmetric key generation (AES keys)
 Symmetric and asymmetric key procedures (encryption/decryption, generation and
verification of digital signatures)
 Hash algorithms (SHA-1, SHA-256) and MAC (HMAC)
 Secure key and data storage
 Identification and Authorization mechanisms
In this security target the TOE (target of evaluation) is described and a summary specification is
given. The security environment of the TOE is defined. The assets are identified which have to be
protected through the security policy. The threats against these assets are described. The security
objectives as the objectives of the security policy are defined as well as the security requirements.
The applicable IT security requirements are taken from the Common Criteria, with appropriate
refinements. The security requirements are constructed out of the security functional requirements
as part of the security policy and the security assurance requirements, as the steps during the
evaluation and certification to prove that the TOE meet this requirements. The functionality of the
TOE to meet the requirements is described.
The assets, threats, security objectives and the security functional requirements are defined in the
―Protection Profile PC Client Specific TPM, TPM Library specification Family ―2.0‖
Level 0 Revision 1.16‖,[8], and are referenced here.
The TOE summary specification consisting of the security features, the assurance requirements
and the security function policies are defined in the ST as property of this specific TOE, the
SLB9670_2.0. The rationale presents evidence that the ST is a complete and cohesive set of
requirements and that a conformant TOE would provide an effective set of IT security
countermeasures within the security environment.
SLB9670_2.0 v1.1 7 of 59
2 Target of Evaluation Description
The TOE description helps to understand the specific security environment and the security policy.
In this context the assets, threats, security objectives and security functional requirements can be
employed. The following is a more detailed description of the TOE than in the ―Protection Profile
PC Client Specific Trusted Platform Module Specification Version 2.0; Level 0; Revision 116‖ [8] as
it belongs to the specific TOE.
2.1 TOE Definition

The Target of Evaluation (TOE) is the ―Trusted Platform Module SLB9670_2.0‖ of the Infineon
Technologies AG called ―SLB9670_2.0‖ or ―TPM‖ in the following description. The TOE is an
integrated circuit and software platform that provides computer manufacturers with the core
components of a subsystem used to assure authenticity, integrity and confidentiality in e-
commerce and internet communications within a Trusted Computing Platform as defined in the
Trusted Platform Module Library Specification. The SLB9670_2.0 is a complete solution
implementing the TCG Trusted Platform Module Library, Family ―2.0‖, [5], [6], [7], [10] and the TCG
PC Client Specific Platform TPM Profile (PTP) Specification [9].
A Trusted Platform is a platform that can be trusted by local users and by remote entities. The
basis for trusting a platform is a declaration by a known authority that a platform with a given
identity can be trusted to measure and report the way it is operating. That operating information
can be associated with data stored on the platform, to prevent the release of that data if the
platform is not operating as expected. Other authorities provide declarations that describe the
operating information the platform ought to produce when it is operating properly. The local user
and remote entities trust the judgment of the authorities; so, when they receive proof of the identity
of the platform, information about the current platform environment, and proof about the expected
platform environment, they can decide whether to trust the platform to behave in a sufficiently
trustworthy and predictable manner. The local user and/or remote entities must take this decision
themselves because the level of trust in a platform can vary with the intended use of that platform,
and only the local user and/or remote entities know that intended purpose.
The trusted mechanism of the platform uses cryptographic processes, including secrets. The
trusted mechanisms are required to be isolated from the platform in order to protect secrets from
disclosure and protect methods from subversion.
The subsystem protects itself against physical and software attacks to provide protection against
attacks to the platform.
The TPM provides three trusted capabilities (Roots of Trust): the measurement capabilities, the
reporting capabilities and the storage capabilities. The trusted measurement capabilities are called
the ―Root of Trust for Measurement‖ (RTM). The trusted reporting capabilities are called the ―Root
of Trust for Reporting‖ (RTR). The trusted storage capabilities are called the ―Root of Trust for
Storage‖ (RTS). The RTM makes reliable measurements about the platform and puts the
measurement results into the RTR. The RTR prevents unauthorized changes to the measurement
results, and reliably reports those measurement results. The RTS provides methods to minimize
the amount of trusted storage that is required. The ―Root of Trust for Measurement‖ and the ―Root
of Trust for Reporting‖ cooperate to permit an entity to believe measurements that describe the
current computing environment in the platform. An entity can assess those measurement results
and compare them with values that are to be expected if the platform is operating as expected. If
there is sufficient match between the measurement results and the expected values, the entity can
trust computations within the platform to execute as expected.
The RTR have a cryptographic identity in order to prove to a remote entity that RTR messages
come from genuine trusted capabilities, and not from bogus trusted capabilities.
The SLB9670_2.0 is basically a secure controller with the following added TOE security services:
SLB9670_2.0 v1.1 8 of 59
Random Number Generation (DRBG)
The random number generator (DRBG) is the source of randomness in the SLB9670_2.0. The
DRBG is a protected capability with no access control, intermediate results from the DRBG are
not available to any user. When the data is for internal use by the TPM (e.g. key generation,
nonces, randomess) the data is held in a shielded location and is not accessible to any user.
Platform Key Hierarchy

The SLB9670_2.0 holds a Platform Primary Seed (PPS) and can generate Platform Keys from
the PPS. The platform key hierarchy is controlled by the Platform firmware. The PPS is
generated and loaded during the production of the SLB9670_2.0 from the manufacturer
Infineon Technologies AG.
Cryptographic Services
The SLB9670_2.0 provides the following cryptographic services:
 the RSA algorithm according to PKCS#1 V2.1 for encryption, secret sharing and digital
signature with key sizes of 1024 and 2048 bits. The RSA implementation provides
protection and detection of failures during the Chinese Remainder Theorem (CRT)
process.
 the ECC algorithm according to PKCS#1 V2.1 for encryption, secret sharing and digital
signature with P-256 and BN-256 curves and with key sizes of 256 bits.
 the AES algorithm in CFB mode with key sizes of 128 bits for symmetric encryption and
decryption.
 the Secure Hash Algorithm-1 (SHA-1) and Hash Algorithm-256 (SHA-256) as defined
by United States Federal Information Processing Standard 180-4.
 the Hash Message Authentication Code (HMAC) for symmetric signing and signature
verification defined in FIPS 198a.
The TPM storage keys and TPM identity keys are of strength equivalent to a 2048 bit RSA
key. A storage key whose strength is less than that of a 2048 RSA key could not be stored in
the SLB9670_2.0. The TPM identity keys are RSA keys with key size of 2048 bits or EC keys
with key size of 256 bits.
Key Generation
The SLB9670_2.0 generates two different key types, the ordinary key, which is produced using
the DRBG to seed the computation, and the Primary Key, which is derived from a seed value,
not from the DRBG directly. The SLB9670_2.0 generates asymmetric key pairs for RSA and
ECC algorithms in accordance with different standards as defined in Table 3. The
SLB9670_2.0 generates symmetric AES keys with key sizes of 128 bits. The generation
function is a protected capability and the private key and the AES key is held in a shielded
location.
For the HMAC key generation and for the creation of all nonce values the next n bits are taken
from the internal TPM DRBG based on NIST standard.
Self-Tests
The SLB9670_2.0 provides startup self-tests and a mechanism to allow self-tests to be run on
demand of the user. The test result can be read out by the user. Self-tests include checks of
the following:
SLB9670_2.0 v1.1 9 of 59
 RNG functionality (according [11] class DRG.3).
 Endorsement key pair integrity. This test verifies the RSA/EC sign and verify engine by
signing and verifying a known value with the endorsement key pair.
 Integrity of the protected capabilities of the SLB9670_2.0.
If a failure during any self-test is detected, the part experiencing the failure will return an error
code and the TOE enters a secure state.
Identification and Authentication

The TPM identification and authentication capability is used to authorize the use of a protected
capability and protected object. The SLB9670_2.0 provides therefore two basic mechanisms.
The first is the prove of knowledge of a shared secret. This shared secret is assigned to the
entity as authValue; the second is the authentication of the user and the verification of an
intended state of the SLB9670_2.0 assigned to the entity as authPolicy. Note that the TCG
TPM Module Library specification refers to the identification and authentication process and
access control as authorization.
The protected entities and their authentication date may be held within the SLB9670_2.0 itself
or outside. The identification and authentication protocols use random nonces. This requires
that a nonce from one side be in use only for a message and its reply to prevent replay attacks
and man-in-the-middle attacks.
Access control is enforced in the SLB9670_2.0 on all data and operations performed on that
data. The SLB9670_2.0 provides access control by denying access to some data and
operations and allowing access to other data and operations based on the value of different
flags called security attributes which are listed in the PP [8], Table 8.
Clock and Time

The SLB9670_2.0 provides timing components (Clock, Time, resetCount, restartCount) for use
in time-stamping of attestations and for gating policy.
The SLB9670_2.0 provides also monotonic counters as an ever-increasing incremental value
(as long the SLB9670_2.0 is powered) for external use.
Support for the Root of Trust for Measurement

The SLB9670_2.0 supports the integrity measurement of the trusted platform by calculation,
storage and reporting of measurement digests of measured values. The measurement values
are representation of embedded data or program code scanned and provided to the
SLB9670_2.0 by the CPU of the platform (PCPU) controlled by the Core Root of Trust for
Measurement (CRTM). The SLB9670_2.0 supports cryptographic hashing of measured values
and calculates the measurement digest by extending the value of a Platform Configuration
Register (PCR) with a calculated or provided hash value (SHA-1/SHA-256). The PCR are
shielded locations of the SLB9670_2.0 which can be reset by SLB9670_2.0 reset or trusted
process, written only through measurement digest extensions and read. After each reset the
PCPU begins executing the CRTM and then sends values that indicates its identity to the Root
of Trust for Storage (RTS).
Root of Trust for Storage

The SLB9670_2.0 provides non-volatile storage as shielded location for data of external
entities. The TPM owner controls access to the non-volatile storage. The access control may
include the need of authorization of the user, delegations, PCR values and other controls.
SLB9670_2.0 v1.1 10 of 59
Additionally the SLB9670_2.0 has the capability of secure storage for an unlimited number of
private keys, private keys generated on the TPM or other data, by using external memory of
the platform. The data is transferred in an encrypted file, which contains header information in
addition to the data or key, it is called a blob and is outputted by the TPM. The blob can be re-
loaded in the TPM when needed, e.g. to use the keys later without ever exposing such keys in
the clear outside the TPM.
The SLB9665_2.0 holds the Storage Primary Seed (SPS) and generates the Storage Root
Keys (SRK) from the SPS. The SRK are roots of Protected Storage Hierarchies associated
with the SLB9665_2.0 including storage keys in this hierarchy used for symmetric encryption
and signing of other keys and data.
Root of Trust for Reporting

The Root of Trust for Reporting reports the contents of the RTS. The values on which the RTR
reports, are the evidence of the platform configuration stored in PCR, or audit logs, or key
properties. The RTR exposes the measurement digests stored in the PCRs and attest to the
authenticity of these measurement digests based on identities. The identity is in the form of
asymmetric aliases (Endorsement Key) derived from a common Endorsement Primary Seed
(EPS). Each SLB9670_2.0 is identified and validated by its Endorsement Key that is used as
proof that a SLB9670_2.0 is genuine. For assurance that these PCR values accurately reflect
that state of the platform (RTM), a binding between the RTR and the RTM is established by the
Endorsement Certificate which is generated from the certifying authority. The Endorsement
Primary Seed and the Endorsement Certificate are generated and encrypted by the certifying
authority outside the SLB9670_2.0 in a secure environment of the manufacturer Infineon
Technologies AG and then loaded encrypted into the SLB9670_2.0 during the production
phase.
Generation and import of the Endorsement Key pair and Platform Primary Seed
The Endorsement Primary Seed (EPS), the Endorsement Key (EK) and the Platform Primary
Seed (PPS) used in the TPM are generated outside the TPM with the TPM Personalization
Certification Authority (TPM-CA) located within the secure production area of the TOE. The
TPM-CA produce an Endorsement Primary Seed (EPS) and a Platform Primary Seed (PPS)
using a proved random number generator. From this Endorsement Primary Seed the EK pair
and the associated EK credential (Endorsement Certificate) are generated by the TPM-CA.
The EPS, the PPS and the Endorsement Certificate are loaded encrypted into the TPM during
the manufacturing process at the TOE lifecycle phase ―Manufacturing and Delivery‖. The TPM-
CA is located at the production site of the TOE in a secure room. The TPM-CA consists of a
Personalization Dataset Generator (PDG) including a hardware security module (HSM-PDA), a
Certification Authority (INCA) and a database server. The HSM-PDG generates the EPS, the
PPS and the EK pair and encrypts the EPS, the PPS and the Endorsement Certificate (EK
credential) using a master key and the algorithm three key Triple-DES in CBC mode. The INCA
creates the EK credential by certifying the public part of the EK. The EK credential is also
stored at the database server. For the production process the EPS and PPS are encrypted with
a TPM individual transport key and transported to the production facility. The personalization
process generates the TPM individual transport key and loads this key together with the
encrypted EPS, PPS and the EK credential into the TPM. Within the TPM the EPS and PPS
are encrypted with the transport key and stored in a shielded location. The generation and
import process of the EPS, PPS and Endorsement Certificate (EK credential) is done
completely in the secure production area of the TOE.
To simplify system integration into existing PC mainboards, the SLB9670_2.0 uses the Serial
Peripheral Interface (SPI).
SLB9670_2.0 v1.1 11 of 59
With these capabilities, the SLB9670_2.0 is able to realize the issue of the Trusted Platform
Module Library specification to insert a trusted subsystem – called the ―root of trust‖ – into the PC
platform, which is able to extend its trust to other parts of the whole platform by building a ―chain of
trust‖, where each link extends its trust to the next one. As a result, the TPM extends its
trustworthiness, providing a Trusted PC for secure transactions. As an example the TPM is able to
calculate hash-values of the BIOS at boot time as integrity metric. Once this metric is available, it is
saved in a secure memory location. Optionally, it could be compared to some predefined values
and the boot process could be aborted on mismatch.
During the boot process, other integrity metrics are collected from the platform, e.g. the boot loader
and the operating system itself. Device drivers may be hashed and even hardware like PCI cards
can be detected and identified. Every metric obtained is concatenated to the already available
metrics. This gives a final metric, which describes the operational state of the whole platform and
the state of its system integrity.
A challenger may now ask the platform for these metrics and make informed decisions on whether
to trust it based on the metric values obtained. To support the privacy issue, the user of the
platform may restrict the SLB9670_2.0 in answering to any challenge, but the user is never able to
make the SLB9670_2.0 report false metrics. Moreover, the user is able to create several identities
for his interactions.
Offering these features to a system, the SLB9670_2.0 can be used in a wide field of applications,
e.g. in a remote access network to authenticate platforms to a server and vice versa. Concerning
e-commerce transactions, contracts can be signed with digital signatures using the SLB9670_2.0
asymmetric encryption functionality. Regarding a network scenario, the client PCs equipped with a
SLB9670_2.0 are able to report their platform status to the server so that the network
administration is aware of their trustworthiness. In conclusion, the SLB9670_2.0 acting as a service
provider to a system helps to make transactions more secure and trustworthy.
The Target of Evaluation (TOE), the SLB9670_2.0, consists of the following hardware and
firmware components.
The hardware of the SLB9670_2.0 is based on the SLE70-Family architecture with additional
components and is manufactured by the Infineon Technologies AG.
The IC, whose block diagram is shown in Figure 1, consists of a dedicated microprocessor (CPU)
with a Memory Management Unit (MMU), several different memories, security logic, shield, timer,
an interrupt-controlled I/O interface and a Random Number Generator (RNG). Additionally, a
hardware hash accelerator and a Serial Peripheral Interface (SPI) interface have been added. This
SPI interface is the main interface of the chip.
The CPU is a real 16-bit CPU-architecture and is compatible to the Intel 80251 architecture. The
major components of the core system is the CPU (Central Processing Unit), the MMU (Memory
Management Unit) and MED (Memory Encryption/Decryption Unit). The CPU has
countermeasures included to detect faults and serve by this for data integrity. The TOE implements
a full 16 MByte linear addressable memory space for each privilege level, a simple scalable
Memory Management concept and a scalable stack size. The flexible memory concept consists of
ROM- and Flash-memory (SOLID FLASHTM NVM1) as part of the non volatile memory (NVM),
respectively EEPROM. For the SOLID FLASHTM NVM the Unified Channel Programming (UCP)
memory technology is used.
The SLB9670_2.0 uses an external clock of 33 MHz. The PLL unit allows operating the core
controller of the SLB9670_2.0 with a multiplication factor over the divided external clock signal or
free running with maximum frequency. The checksum module allows simple calculation of
checksums per ISO 3309 (16 bit CRC).
1 SOLID FLASH™ is an Infineon Trade Mark and stands for the Infineon EEPROM working as Flash memory. The abbreviation NVM is
short for Non Volatile Memory.
SLB9670_2.0 v1.1 12 of 59
Three modules for cryptographic operations are implemented on the TOE. The two cryptographic
co-processors serve the need of modern cryptography: The symmetric co-processor (SCP) for
AES hardware acceleration. The Asymmetric Crypto co-processor, called Crypto2304T in the
following, is used for RSA-2048 bit and Elliptic Curve (ECC) cryptography. The third module
named HASH provides Secure Hash Algorithms (SHA-1 and SHA-256).
To sum up, the TOE is a powerful security IC with a large amount of memory and special
peripheral devices with both improved performance and optimized power consumption at minimal
chip size.
Coprocessors
Memory
HASH CRC SCP Crypto SOLID

FLASH™
VCC
GND Core with
CLK Security CPU,
peripherals MED, MMU, Peripheral and Memory Buses
RST
I/O Cache
Interrupt Coun- User- Test- XRAM

Timer RNG SPI
Module ter ROM ROM
Peripherals
Memory
SPI Interface
Figure 1: Block diagram of the SLB9670_2.0
SLB9670_2.0 v1.1 13 of 59
The firmware/software required for operating the chip includes an operating system that provides
the TCG functionality specified in the Trusted Platform Module Library specification. The chip
initialisation routine with security checks and identification mode as well as test routines for
production testing are located in a separate test ROM. The firmware also provides the mechanism
for updating the protected capabilities once the TOE is in the field as defined in the
TPM_FieldUpgrade command of the Trusted Platform Module Library specification. The field
upgrade can only be downloaded to the chip if it has been encrypted and signed by the
manufacturer Infineon Technologies AG. The Figure 2 shows the firmware block diagram of the
SLB9670_2.0.
Figure 2: Firmware block diagram of the SLB9670_2.0
SLB9670_2.0 v1.1 14 of 59
2.2 Scope of the TOE
The TOE manufactured by Infineon Technologies AG, comprises the hardware of the security
controller, and the associated firmware/software required for operation provided in ROM and
SOLID FLASHTM NVM memory.
2.2.1 Hardware of the TOE

The hardware part of the TOE (cf. Figure 1) as defined in the PP [8] is comprised of:
 Security Peripherals (filters, sensors)
 Core System
- with proprietary CPU implementation of the Intel MCS251 standard architecture from
functional perspective
- Cache with post failure detection
- Memory Encryption/Decryption Unit (MED)
- Memory Management Unit (MMU)
 Memories
- Read-Only Memory (ROM)
- Random Access Memory (RAM)
- SOLID FLASHTM NVM
 Coprocessors
- Crypto2304T for asymmetric algorithms like RSA and ECC
- Symmetric Crypto Co-processor AES standard (SCP)
- Hash accelerator (HASH) for the SHA-1 and SHA-256 algorithms
- Checksum module (CRC)
 Random number generator (RNG)
 Interrupt module (INT)
 Timer (TIM)
 Buses (BUS)
- Memory Bus
- Peripheral Bus
 Serial Peripheral Interface (SPI)
 Tick Counter
SLB9670_2.0 v1.1 15 of 59
2.2.2 Firmware of the TOE

The entire firmware/software of the TOE consists of different parts. The one part is the operating
system which includes the TPM application, the System Management and the Platform Primary
Seed (PPS) of the Endorsement Key and is used to operate the IC. The operating system includes
also the capability for updating the protected capabilities once the TOE is in the field
(TPM_FieldUpgrade). Note that it is possible to update e.g. a certified TPM version v4.40.0119.00
(TPM 1.2) to a new certified version e.g. v7.40.2098.00 (TPM 2.0).
The other firmware/software parts are the Self Test Software (STS), the Service Algorithm Minimal
(SAM), the Resource Management System (RMS), the Cryptographic Library and the Flash
Loader. The STS routines are stored in the especially protected test ROM.
The entire operating system of the TOE (cf. Figure 2) as defined in the PP [8] is comprised of:
 TPM Secure Operating System
(including: ComSys, DataStore, DevCtrl, ECC, FieldUpgrade, GPIO, HashSys, Locality,
MACSys, OSStartup, PKcs1, PowMan, RandData, RMSInt, RSA, SymEnc, SysMan,
SysSec, SelfTest, TaskCtrl, TimCtrl, Cryptographic Library)
 OS Abstraction Layer
 Crypto Engine
 Platform
 Storage
 Support
 TPM Commands
 PCR
 Authorization
 Attack Logic
 Command Execution Engine
2.2.3 Guidance documentation

The guidance documentation consists of a set of information containing the description of all
interfaces to operate the TOE. The list of the guidance documentation is given in Table 1, section
Guidance Documentation.
2.2.4 Forms of delivery

The TOE is delivered in form of complete chips which include the hardware, the firmware, the
Platform Primary Seed, and the guidance documentation. The TOE is finished and the extended
test features are removed. The TOE is delivered in different packages (e.g. TSSOP and VQFN)
which are listed in the document TPM Trusted Platform Module Version 2.0 Errata and Updates
[13].
SLB9670_2.0 v1.1 16 of 59
2.2.5 Production sites

The TOE silicon is produced in the production site Dresden. The Chip Marking includes an
assembly side code which defines the assembly site. The exact coding of the chip marking is
described in [14], section 5.3 ―Chip Marking‖.
Table 2: Production site in chip identification
Production Site Chip Identification
Dresden, byte number 13 (Fab number):

Germany 02H
The delivery measures are described in the ALC_DVS aspect.
2.2.6 Life cycle of the TOE

The life cycle of the TOE as part of the evaluation covers phase 1 ―Development‖ and phase 2
―Manufacturing and Delivery‖ as defined in the PP [8] section 2.2.4 ―TPM Life Cycle‖. The phase 1
includes the TPM development, the phase 2 includes the TPM manufacturing, the TPM
conformance testing, the Platform Primary Seed and the TPM-Mfg EK credential issuance.
SLB9670_2.0 v1.1 17 of 59
3 Conformance Claims (ASE_CCL)
3.1 CC Conformance Claim

This Security Target (ST) and the TOE claim conformance to Common Criteria version v3.1 part 1
[1], part 2 [2] and part 3 [3].
Conformance of this ST is claimed for:
Common Criteria part 2 extended and Common Criteria part 3 conformant.
3.2 PP Claim
This Security Target is in strict conformance to the
Protection Profile PC Client Specific TPM, TPM Library specification Family ―2.0‖ Level 0 Revision
1.16; Version: 1.0, dated 10.12.2014 [8].
The Protection Profile (PP) [8] is registered and certified by the Agence nationale de la securite
des systemes d´information (ANSSI) under the reference ANSSI-CC-PP-2014, Version: 1.0, dated
10.12.2014.
The security assurance requirements of the TOE are according to the ―Protection Profile PC Client
Specific TPM‖ [8]. They are all drawn from Part 3 of the Common Criteria version v3.1.
3.3 Package Claim

This Security Target does not claim conformance to a package of the PP [8].
The assurance level for the TOE is EAL4 augmented with ALC_FLR.1 and AVA_VAN.4 defined in
CC part 3 [3].
3.4 Conformance Claim Rationale

This security target claims strict conformance only to one PP, the PP [8].
The Target of Evaluation (TOE) is a complete solution implementing the TCG Trusted Platform
Module Library, Family ―2.0‖, [5], [6], [7], [10] and the TCG PC Client Specific Platform TPM Profile
(PTP) Specification [9] as defined in the PP [8] section 2.2.1, so the TOE is consistent with the
TOE type in the PP [8].
The security problem definition of this security target are consistent with the statement of the
security problem definition in the PP [8], as the security target claimed strict conformance to the PP
[8] and no other threats, organisational security policies and assumptions are added.
The security objectives of this security target are consistent with the statement of the security
objectives in the PP [8], as the security target claimed strict conformance to the PP [8] and no
other security objectives are added.
The security requirements of this security target are consistent with the statement of the security
requirements in the PP [8], as the security target claimed strict conformance to the PP [8]. All
assignments and selections of the security functional requirements are done in the PP [8] and in
this security target at section 7.2, e.g. the security functional requirement FCS_RNG.1 ―Generation
of Random Numbers ―.
3.5 Application Notes

The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the
Protection Profile [8] according to ―Anwendungshinweise und Interpretationen zum Schema (AIS)‖
respectively ―Functionality classes for random number generators‖ [11].
SLB9670_2.0 v1.1 18 of 59
4 Security Problem Definition (ASE_SPD)
The content of the PP [8] applies to this chapter completely.
4.1 Assets and Threats

The assets of the TOE are defined in the PP [8], section 4.1 Assets. These assets have to be
protected while being executed as well as when the TOE is not in operation. The threats are
directed against the assets.
The threats to security are defined in the PP [8], section 4.2 Threats, no other threats are added.
4.2 Organisational Security Policies

The organisational security policies are defined in the PP [8], section 4.3 Organisational Security
Policies, no other organisational security policies are added.
4.3 Assumptions
The TOE environment is highly variable. In general, the TOE is assumed to be in an uncontrolled
environment with no guarantee of the TOE’s physical security.
The TOE assumptions to the IT environment are defined in the PP [8], section 4.4 Assumptions, no
other assumptions are added.
SLB9670_2.0 v1.1 19 of 59
5 Security Objectives (ASE_OBJ)
This section shows the security objectives which are relevant for the TOE. For this section the PP
[8] can be applied completely.
5.1 Security Objectives for the TOE

The security objectives of the TOE are defined and described in the PP [8], section 5.1 Security
Objectives for the TOE, no other security objectives are added.
5.2 Security Objectives for the Operational Environment

The security objectives for the operational environment are described in the PP [8], section 5.2
Security Objectives for the Operational Environment, no other security objectives for the
operational environment are added.
5.3 Security Objectives Rationale

The security objectives rationale is described in the PP [8], section 5.3 Security Objective
Rationale. No other security objectives rationale are added.
SLB9670_2.0 v1.1 20 of 59
6 Extended Components Definition (ASE_ECD)
The extended component ―FCS_RNG Generation of random numbers‖ is defined in the PP [8],
section 6.1. No other extended component definitions are added.
SLB9670_2.0 v1.1 21 of 59
7 IT Security Requirements (ASE_REQ)
For this section the PP [8] section 7 can be applied completely.
7.1 Preface regarding Security Level related to Cryptography
The strength of the cryptographic algorithms was not rated in the course of the product certification
(see [23] Section 9, Para.4, Clause 2). But cryptographic functionalities with a security level of
lower than 100 bits can no longer be regarded as secure without considering the application
context. Therefore, for these functions it shall be checked whether the related cryptographic
operations are appropriate for the intended system. Some further hints and guidelines can be
derived from the ―Technische Richtlinie BSI TR-02102‖, www.bsi.bund.de.
Any cryptographic functionality that is marked in the column ―Security level above 100 Bits‖ of the
following table with a ―no‖ achieves a security level of lower than 100 Bits (in general context).
Table 3: TOE cryptographic functionality
Purpose Cryptographic Standard of Key Size in Bits Security Comments

Mechanism Implementation Level
above
100 Bits
Authenticity RSA signature [RFC3447] |Modulus| = 1024 no [5], sections

generation / B.1 – B.7
verification [7], section 20.2
RSASSA- according section 8.2
PKCS1-v1_5,
RSASSA_PSS according section 8.1
SHA-1, [10118]
SHA-256
RSA signature [RFC3447] |Modulus| = 2048 yes [5], sections

generation / B.1 – B.7
verification [7], section 20.2
RSASSA- according section 8.2
PKCS1-v1_5,
RSASSA_PSS according section 8.1
SHA-1, [10118]
SHA-256
EC signature [F1864] |k| = 256 yes [5], section C.4

generation/ [159465] ECC_NIST_P256
verification
according to
ECDSA [14888]
ECDAA [5], section C4.2
SHA-1, [10118]
SHA-256
EC signature [F1864] |k| = 256 no [5], section C.4

generation/ [159465] ECC_BN_P256
verification
according to
SLB9670_2.0 v1.1 22 of 59
above
100 Bits
ECDSA [14888]
ECDAA [5], section C4.2
SHA-1, [10118]
SHA-256
RSA signature [RFC3447] |Modulus|= 2048 yes TPM-

verification [FUP] FieldUpgrade
(RSASSA-
PKCS1-v1_5)
SHA-1, [10118]
SHA-256
Authentication HMAC with [9797] |k| = 160 no [5], section 11.4.3

SHA-1 [10118]
ECDEC [N568], section 6.1.1.2 |k| = 256 [5], section C7
[F1864] ECC_NIST_P256
RSA decryption [RFC3447] |Modulus| = 2048
RSAES- according section 7.2
PKCS1-v1_5
AES decryption [18033], |k| = 128
in CFB mode [10116]
HMAC with [9797] |k| = 256 yes [5], section 11.4.3

SHA-256 [10118]
ECDEC [N568], section 6.1.1.2 |k| = 256 [5], section C7
[F1864] ECC_NIST_P256
RSA decryption [RFC3447] |Modulus| = 2048
RSAES- according section 7.2
PKCS1-v1_5
AES decryption [18033], |k| = 128
in CFB mode [10116]
Key Diffie-Hellmann [N856], section 6.1.1.2 |k| = 256 yes [5], section C7.1
Agreement (ECDH) [F1864] ECC_NIST_P256
KDFe [N856] [5], section
11.4.9.3
HMAC with [9797]
SHA-256 und [10118] |k| = 256
SHA-1 |k| = 160
KDFa [5], section 11.4.9.1 |Modulus| = 2048 yes [5], section

[N808] 11.4.9.1
HMAC with [9797]
SHA-256 und [10118] |k| = 256
SHA-1 |k| = 160
HMAC with [9797], [F1804] |k| = 256 yes TPM-

SHA-256 [N808], [FUP] FieldUpgrade
Integrity HMAC with [9797] yes [5], section 11.4.3

SHA-256 und [10118] |k| = 256
SLB9670_2.0 v1.1 23 of 59
above
100 Bits
SHA-1 |k| = 160
HMAC with [9797], [F1804] |k| = 256 yes TPM-

SHA-256 [N808], [FUP] FieldUpgrade
Confidentiality AES in CFB [18033], |k| = 128 yes [TPM]

mode [10116]
RSA encryption [RFC3447] |Modulus| = 1024 no [5], sections

/ decryption B.1 – B.7
RSAES- according section 7.2 [7],sections
PKCS1-v1_5 14.2, 14.3 etc
RSAES-OAEP according section 7.1
RSA encryption [RFC3447] |Modulus| = 2048 yes [5],sections

/ decryption B.1 – B.7
RSAES- according section 7.2 [7],sections
PKCS1-v1_5 14.2, 14.3 etc
RSAES-OAEP according section 7.1
AES in PCBC [18033], [N808] |k| = 128 yes TPM-

mode [FUP] FieldUpgrade
Cryptographic SHA-256 [10118] none no [5], section 11.4.2

Primitive
SHA-1 [10118] none no [5], section 11.4.2
HMAC with [9797] |k| = 160 no [5], section 11.4.3

SHA-1 [10118]
HMAC with [9797] |k| = 256 yes [5], section 11.4.3

SHA-256 [10118]
Deterministic [11], [N890] CTR_DRGB n.a [5], section

RNG DRG.3 implemented 11.4.10
Trusted HMAC with [9797] |k| = 256 yes [TPM]

Channel SHA-256 [10118]
AES in CFB [18033], |k| = 128 yes [TPM]

mode [10116]
RSA [RFC3447] |k| = 1024,
[159461], [N808] |k| = 2048
ECC [F1864] ECC_NIST_P256
|k| = 256
HMAC (SHA- [9797] |k| = 256
256) [10118]
SLB9670_2.0 v1.1 24 of 59
7.2 Security Functional Requirements for the TOE
The security functional requirements (SFR) for the TOE are defined and described in the PP [8],
section 7.1 Security Functional Requirements.
All assignments and selections of the security functional requirements are done in the PP [8] with
the exception of the following SFRs. The operations completed in the ST are marked in italic font.
FMT_MSA.2 Secure security attributes

Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for:
security attributes of keys, PCR, NV storage areas and counter.
Note: The TOE supports the mechanism for updating the protected capabilities once the
TOE is in the field as defined in the TPM_FieldUpgrade command of the Trusted Platform
Module Library specification. Within the scope of the TPM_FieldUpgrade command the
security attributes of the TOE are also updated.
FCS_CKM.1/PKRSA Cryptographic key generation (RSA primary keys)

Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/PKRSA The TSF shall generate cryptographic primary RSA keys in

accordance with a specified cryptographic key generation algorithm RSA key
generator and specified cryptographic key sizes 2048 bits that meet the following:
TPM library specification [5], [6], [7], and
RSA key generation:
1. According to TPM library specification [5], section B.8 and [N808]
2. According to sections 3.1 and 3.2 in PKCS#1 v2.1 [RFC3447],
for u = 2, i.e., without any (ri, di ,ti); i > 2:
 3.1 supported for n < 24096+128.
 3.2.(1) supported for n < 22048+64.
 3.2.(2) supported for p_q < 24096+128.
3. According to section 8.1.3.1 in IEEE Std 1363-2000 [IEEE1363]:
 8.1.3.1(1) supported for n < 22048+64.
 8.1.3.1(2) supported for p_q < 24096+128.
 8.1.3.1(3) supported for p_q < 22048+64 .
SLB9670_2.0 v1.1 25 of 59
FCS_CKM.1/PKECC Cryptographic key generation (ECC primary keys)
FCS_CKM.1.1/PKECC The TSF shall generate cryptographic primary ECC keys in

accordance with a specified cryptographic key generation algorithm ECC key
ECC key generation:
1. According to TPM library specification [5], section C.5, C.6, C.8 and [N808]
2. According to section ―6.1 Key Generation I‖ (not 6.1.1) in ISO/IEC 15946-1
:2002 [159461] with curves
 ECC_NIST_P256 [F1865]
 ECC_BN_P256 [159465]
FCS_CKM.1/PKSYM Cryptographic key generation (SYM primary keys)

FCS_CKM.1.1/PKSYM The TSF shall generate cryptographic primary symmetric keys in

accordance with a specified cryptographic key generation algorithm AES key
AES key generation:
1. The AES key is a 128 bit random number according to NIST Special
Publication 800-133; Recommendation for Cryptographic Key, section 5
[N8133]
2.
and
NIST Special Publication SP 800-108, October 2009, Recommendation for
Key Derivation Using Pseudorandom Functions (revised) [N808]
FCS_CKM.1/RSA Cryptographic key generation (RSA keys)

FCS_CKM.1.1/RSA The TSF shall generate cryptographic RSA keys in accordance with a
specified cryptographic key generation algorithm RSA key generator and specified
cryptographic key sizes 1024 and 2048 bits that meet the following: TPM library
specification [5], [6], [7], and
1. According to TPM library specification [5], section B.8
2. According to sections 3.1 and 3.2 in PKCS#1 v2.1 [RFC3447],
SLB9670_2.0 v1.1 26 of 59
 3.1 supported for n < 24096+128
 3.2.(1) supported for n < 22048+64
 3.2.(2) supported for p_q < 24096+128
3. According to section 8.1.3.1 in IEEE Std 1363-2000 [IEEE1363]:
 8.1.3.1(1) supported for n < 22048+64.
 8.1.3.1(2) supported for p_q < 24096+128
 8.1.3.1(3) supported for p_q < 22048+64.
FCS_CKM.1/ECC Cryptographic key generation (ECC keys)

FCS_CKM.1.1/ECC The TSF shall generate cryptographic ECC keys in accordance with a
specified cryptographic key generation algorithm ECC key generator and specified
cryptographic key sizes 256 bits that meet the following: TPM library specification
TPM Specification [5], [6], [7],
1. According to TPM library specification [5], section C.5 and C.8

2. According to section ―6.1 Key Generation I‖ (not 6.1.1) in ISO/IEC 15946-1
:2002 [159461] with curves
 ECC_NIST_P256 [F1865]
 ECC_BN_P256 [159465]
FCS_CKM.1/SYMM Cryptographic key generation (symmetric keys)

FCS_CKM.1.1/SYMM The TSF shall generate cryptographic symmetric keys in accordance

with a specified cryptographic key generation algorithm AES key generator and
specified cryptographic key sizes 128 bits that meet the following: TPM library
specification [5], [6], [7], and
the AES key is a 128 bit random number according to NIST Special
Publication 800-133; Recommendation for Cryptographic Key, section 5
[N8133].

Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method: key zeroise method that meets the following:
SLB9670_2.0 v1.1 27 of 59
FIPS PUB 140-2 [F1402], section 4.7.6 (overwriting all bits with ―0‖).
FCS_COP.1/AES Cryptographic operation (symmetric encryption/decryption)

FCS_COP.1.1/AES
The TSF shall perform symmetric encryption and decryption in accordance with a
specified cryptographic algorithm AES in the mode CFB and cryptographic key
sizes 128 bits that meet the following:
 ISO/IEC 18033-3: 2005, Information technology - Security techniques –
Encryption algorithms -- Part 3: Block ciphers [18033]
 ISO/IEC 10116:2006, Information technology — Security techniques —
Modes of operation for an n-bit block cipher [10116].
FCS_COP.1/HMAC1 Cryptographic operation (HMAC calculation)

FCS_COP.1.1/HMAC1 The TSF shall perform HMAC value generation and verification in
accordance with a specified cryptographic algorithm HMAC with SHA-1 and
cryptographic key sizes 160 bits that meet the following:
 ISO/IEC 9797-2, Information technology -- Security techniques –
Message authentication codes (MACs) -- Part 2: Mechanisms using a
dedicated hash-function [9797]
 ISO/IEC 10118-3: 2004, Information technology -- Security techniques --
Hashfunctions -- Part 3: Dedicated hash-functions [10118].
FCS_COP.1/HMAC Cryptographic operation (HMAC calculation)

FCS_COP.1.1/HMAC The TSF shall perform HMAC value generation and verification in
accordance with a specified cryptographic algorithm HMAC with SHA-256 and
cryptographic key sizes 256 bits that meet the following:
SLB9670_2.0 v1.1 28 of 59
 ISO/IEC 9797-2, Information technology -- Security techniques –
Message authentication codes (MACs) -- Part 2: Mechanisms using a
dedicated hash-function [9797]
 ISO/IEC 10118-3: 2004, Information technology -- Security techniques --
Hashfunctions -- Part 3: Dedicated hash-functions [10118].
FCS_COP.1/RSAED1 Cryptographic operation (Asymmetric encryption/decryption)

FCS_COP.1.1/RSAED1 The TSF shall perform asymmetric encryption and decryption in

accordance with a specified cryptographic algorithm RSA without padding, RSAES-
PKCS1-v1_5, RSAES-OAEP, and cryptographic key sizes 1024 bit that meet the
following: PKCS#1v2.1 [RFC3447], and
RSA encryption:
1. According to section "5.1.1 RSAEP‖ in PKCS#1 v2.1 [RFC3447]

 Supported for n < 2 2048+64
 5.1.1 (1) not supported
and with padding
 RSAES-PKCS1-v1_5, [RFC3447] according section 7.2
 RSAES-OAEP, [RFC3447] according section 7.1.
RSA decryption (without CRT):
2. According to section "5.1.2 RSADP‖ in PKCS#1 v2.1 [RFC3447]

 5.1.2(1) not supported
 5.1.2(2.a) supported for n < 22048+64
 5.1.2(2.b) supported for p_q < 2 4096+128
 5.1.2(2.b) (ii)&(v) not applicable due to u = 2
and with padding
FCS_COP.1/RSAED Cryptographic operation (Asymmetric encryption/decryption)

FCS_COP.1.1/RSAED The TSF shall perform asymmetric encryption and decryption in

accordance with a specified cryptographic algorithm RSA without padding, RSAES-
SLB9670_2.0 v1.1 29 of 59
PKCS1-v1_5, RSAES-OAEP, and cryptographic key sizes 2048 bit that meet the
following: PKCS#1v2.1 [RFC3447], and
RSA encryption:
3. According to section "5.1.1 RSAEP‖ in PKCS#1 v2.1 [RFC3447]

and with padding
RSA decryption (without CRT):
4. According to section "5.1.2 RSADP‖ in PKCS#1 v2.1 [RFC3447]

 5.1.2(2.a) supported for n < 22048+64
 5.1.2(2.b) supported for p_q < 2 4096+128
and with padding
FCS_COP.1/RSASign1 Cryptographic operation (RSA signature generation/verification)

FCS_COP.1.1/RSASign1 The TSF shall perform signature generation and verification in

accordance with a specified cryptographic algorithm RSAES-PKCS1-v1_5,
RSASSA_PSS, and cryptographic key sizes 1024 bit that meet the following:
PKCS#1v2.1 [RFC3447], and
RSA signature generation (without CRT):
1. According to section "5.2.1 RSASP1‖ in PKCS#1 v2.1 [RFC3447]

 5.2.1(2.a) supported for n < 22048+64
 5.2.1(2b) supported for p_q < 2 4096+128
and with
 RSASSA_PSS, [RFC3447] according section 8.1.
RSA signature verification:
2. According to section "5.2.2 RSAVP1‖ in PKCS#1 v2.1 [RFC3447]
SLB9670_2.0 v1.1 30 of 59
and with
FCS_COP.1/RSASign Cryptographic operation (RSA signature generation/verification)

FCS_COP.1.1/RSASign The TSF shall perform signature generation and verification in

accordance with a specified cryptographic algorithm RSAES-PKCS1-v1_5,
RSASSA_PSS, and cryptographic key sizes 2048 bit that meet the following:
PKCS#1v2.1 [RFC3447], and
RSA signature generation (without CRT):
3. According to section "5.2.1 RSASP1‖ in PKCS#1 v2.1 [RFC3447]

 5.2.1(2.a) supported for n < 22048+64
 5.2.1(2b) supported for p_q < 2 4096+128
and with
RSA signature verification:
4. According to section "5.2.2 RSAVP1‖ in PKCS#1 v2.1 [RFC3447]

and with
FCS_COP.1/ECDSA Cryptographic operation (ECC signature generation/verification)

FCS_COP.1.1/ECDSA The TSF shall perform signature generation and verification in

accordance with a specified cryptographic algorithm ECDSA with curve
SLB9670_2.0 v1.1 31 of 59
TPM_ECC_NIST_P256, and none and cryptographic key sizes 256 bit that meet the
following:
ECDSA signature generation:
5. According to section "6.4.3 Signature process" in ISO/IEC 14888-3:2006:

[14888]
 6.4.3.3 not supported
 6.4.3.5 not supported: – the hash-code H of the message has to
be provided by the caller as input to our function.
with curve
 ECC_NIST_P256 [F1864].
ECDSA signature verification:
6. According to section "6.4.4 Signature Verification Process" in ISO/IEC

14888-3:2006: [14888]
 6.4.4.3 not supported: – the hash-code H of the message has to
be provided by the caller as input to our function.
with curve
 ECC_NIST_P256 [F1864]
FCS_COP.1/ECDAA Cryptographic operation (DAA commit)

FCS_COP.1.1/ECDAA The TSF shall perform signature generation in accordance with a

specified cryptographic algorithm ECDAA with curve TPM_ECC_NIST_P256 and
TPM_ECC_BN_P256 and cryptographic key sizes 256 that meet the following: TPM
library specification [7], section C4.2 with curves
 ECC_NIST_P256 [F1864]
 ECC_BN_P256 [159465].
FCS_COP.1/ECDEC Cryptographic operation (decryption)

FCS_COP.1.1/ECDEC The TSF shall perform decryption of ECC key in accordance with a
specified cryptographic algorithm ECDH with curve TPM_ECC_NIST_P256, and
cryptographic key sizes 256 bit that that meet the following: TPM library
specification [5], NIST Special Publication 800-56A, section 6.1.1.2 [N856].
SLB9670_2.0 v1.1 32 of 59
FIA_UID.1 Timing of identification

Dependencies: No dependencies.
FIA_UID.1.1 The TSF shall allow

(1) to execute indication _TPM_Hash_Start, _TPM_Hash_Data and
_TPM_Hash_End,
(2) to execute commands that do not require authentication,
(3) to access objects where the entity owner has defined no authentication
requirements (authValue, authPolicy),
(4) none
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user, e.g. self-test.
FPT_TST.1 TSF testing

FPT_TST.1.1 The TSF shall run a suite of self tests

(1) at the request of the authorized user ―World‖
(a) the TPM2_SelfTest command and of selected algorithms using the
TPM2_IncrementalSelfTest command,
(2) at the conditions
(a) Initialization state after reset and before the reception of the first
command,
(b) prior to execution of a command using a not self-tested function,
(3) none
to demonstrate the correct operation of sensitive parts of the TSF.
FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of
the following TSF data: platformAuth, platformPolicy, ownerAuth, ownerPolicy,
lockoutAuth, lockoutPolicy, authValue and autPolicy.
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of
the TSF.
FPT_FLS.1/FS Failure with preservation of secure state (fail state)

FPT_FLS.1.1/FS The TSF shall preserve a secure state by entering the Fail state when the
following types of failures occur:
(1) If during TPM Restart or TPM Resume, the TPM fails to restore the state saved
at the last Shutdown(STATE), the TPM shall enter Failure Mode and return
TPM_RC_FAILURE.
SLB9670_2.0 v1.1 33 of 59
(2) failure detected by TPM2_ContextLoad when the decrypted value of sequence
is compared to the stored value created by TPM2_ContextSave(),
(3) failure detected by self-test according to FPT_TST.1,
(4) failure detected by the module SysSec and hardware errors (traps)
Note: The module SysSec is a part of the TPM operating system, the module implements
mechanisms to detect errors in the program flow.
FPT_PHP.3 Resistance to physical attack

FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing to the TSF by
responding automatically such that the SFRs are always enforced.
FDP_ACF.1/States Security attribute based access control (operational states)

Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/States The TSF shall enforce the TPM State Control SFP to objects based on the
following
Subjects as defined in Table 72:
(1) Platform firmware with the security attributes platformAuth and physical
presence if supported by the TOE,
(2) all other subjects; their security attributes are irrelevant for this SFP,
Objects as defined in Table 83 and Table 94:
(1) Shutdown BLOB with the security attribute validation status,
(2) Firmware update data with security attributes signature of the TPM
manufacturer and digest,
(3) all other objects; their security attributes are irrelevant for this SFP.
FDP_ACF.1.2/States The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) The Platform firmware is authorized to change the TPM state to FUM if the
authenticity of the first digest or the signature could be successfully verified.
(2) While in FUM state the Platform firmware is authorized to import or activate
firmware data only after successful verification of its integrity and authenticity
(see FDP_UIT.1/States).
(3) The FUM state shall only be left when the last data block has success fully been
received by the TOE.
(4) In the Init state the subject ―World‖ is authorized to execute the commands
TPM2_HashSequenceStart, TPM2_SequenceUpdate, TPM2_EventSequence-
Complete, TPM2_SequenceComplete, TPM2_PCR_Extend, TPM2_Startup,
TPM2_SelfTest, TPM2_GetRandom, TPM2_HierarchyControl, TPM2_Hierar-
2 located in the Protection Profile [8]
SLB9670_2.0 v1.1 34 of 59
chyChangeAuth, TPM2_SetPrimaryPolicy, TPM2_GetCapability,
TPM2_NV_Read, and the sequence _TPM_Hash_Start, _TPM_Hash_Data, and
_TPM_Hash_End.
(5) In the Init state every subject is authorized to process the Resume operation on
the Shutdown BLOB with state transition to Operational.
(6) In the Init state every subject is authorized to process the Restart operation on
the Shutdown BLOB with state transition to Operational.
(7) In the Init state, if no Shutdown BLOB was generated or if the Shutdown BLOB
is invalid (see attribute ―Validation status‖) every subject is authorized to process
the TPM2_Startup command. In case of the parameter TPM_SU_CLEAR the
TPM shall change the state to Operational and initialize its internal operational
variables to default initialization values (Reset), otherwise the TPM shall return
TPM_RC_FAILURE and stay in the same state.
(8) In the Operational state, nobody is authorized to execute the commands
TPM2_Startup. For all other subjects, objects and operations, the access control
rules of the Access Control SFP shall apply (see FDP_ACF.1/AC).
(9) The Operational state shall change to Self-Test state if the command
TPM2_Selftest or TPM2_IncrementalSelfTest is executed or when a test of a
dedicated functionality is required (see FPT_TST.1). In the Self-Test state,
nobody is authorized to execute any other TPM commands.
(10) The Self-Test state shall be left only after finishing the intended test of the
dedicated functionality. In case of a successful test result the state shall change
to Operational, otherwise to Fail.
(11) In the Fail state, every subject is authorized to execute the commands
TPM2_GetTestResult and TPM2_GetCapability.
(12) The Fail state the subject World is authorized to send a _TPM_Init indication
with state change to Init.
(13) Any subject is authorized to prepare the TPM for a power cycle using the
TPM2_Shutdown command and to create a shutdown BLOB by
TPM2_Shutdown(TPM_SU_STATE).
FDP_ACF.1.3/States The TSF shall explicitly authorize access of subjects to objects based on
the following additional rules: none.
FDP_ACF.1.4/States The TSF shall explicitly deny access of subjects to objects based on the
following additional rules:
(1) Once the TPM receives a TPM2_SelfTest command and before completion of all
tests, the TPM shall return TPM_RC_TESTING for any command that uses a
command that requires a test.
FDP_UIT.1/States Data exchange integrity (operational states)

Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FDP_UIT.1.1/States The TSF shall enforce the TPM state control SFP to receive firmware update
data in a manner protected from modification, deletion, insertion, replay errors.
SLB9670_2.0 v1.1 35 of 59
FDP_UIT.1.2/States The TSF shall be able to determine on receipt of firmware update data,
whether modification, deletion, insertion, replay has occurred.
FDP_ACF.1/AC Security attribute based access control (access control)

Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/AC The TSF shall enforce the Access Control SFP to objects based on the
following
Subjects:
(1) Platform firmware with security attribute authorization state gained by
authentication with platformAuth or platformPolicy and physical presence,
(2) Platform owner with security attribute authorization state gained by
authentication with ownerAuth or ownerPolicy,
(3) Privacy administrator with security attribute authorization state gained by
authentication with endorsementAuth or endorsementPolicy,
(4) Lockout administrator with security attribute authorization state,
(5) USER with authentication sate gained with userAuth or authPolicy,
(6) DUP with authentication sate gained with authPolicy,
(7) ADMIN with authentication sate gained with userAuth or authPolicy,
(8) World with no security attributes,
Objects:
(1) User key with security attributes TPM_ALG_ID, TPMA_OBJECT,
(2) TPM objects,
(3) Clock with security attributes: resetCount, restartCount, safe-flag,
(4) Data with security attribute ―externally provided‖.
FDP_ACF.1.2/AC The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
(1) The Platform firmware platformAuth, platformPolicy or with physical presence if
supported by the TOE and the Platform owner are authorized to control the
persistence of loadable objects in TPM memory (TPM2_EvictControl). The
physical presence is not required if it is not supported by the TOE or disabled for
TPM2_EvictControl command.
(2) The Platform firmware platformAuth, platformPolicy or with physical presence if
supported by the TOE and the Platform owner are authorized to advance the
value and to adjust the rate of advance of the TPMs clock (TPM2_ClockSet,
TPM2_ClockRateAdjust). The physical presence is not required if it is not
supported by the TOE or disabled for the TPM2_ClockSet respective
TPM2_ClockRateAdjust command.
(3) Any subject is authorized to get the current value of time, clock, resetCount and
restartCount (TPM2_ReadClock).
(4) No subject is authorized to set the clock to a value less than the current value of
clock using the TPM2_ClockSet command.
(5) No subject is authorized to set the clock to a value greater than its maximum
value (0xFFFF000000000000) using the TPM2_ClockSet command.
(6) A subject with the role USER is authorized to generate digital signatures using
the command TPM2_Sign for externally provided data (hash). The user
authorization shall be done based on the required authorization of the key that
will perform signing. The key attributes shall allow the signing operation for
externally provided data.
SLB9670_2.0 v1.1 36 of 59
(7) Any subject is authorized to verify digital signatures using the command
TPM2_VerifySignature.
(8) Any subject is authorized to request data from the random number generator
using the command TPM2_GetRandom.
(9) Any subject is authorized to add additional information to the state of the random
number generator using the command TPM2_StirRandom.
(10) Any subject is authorized to perform RSA encryption using the command
TPM2_RSA_Encrypt for externally provided data. The key attributes shall allow
the encrypt operation for externally provided data.
(11) A subject with the role USER is authorized to perform RSA decryption using
the command TPM2_RSA_Decrypt for externally provided data. The user
authorization shall be done based on the required authorization of the key that
will be used for decryption. The key attributes shall allow the decrypt operation
for externally provided data.
(12) Any subject is authorized to generate ECC ephemeral key pairs using the
command TPM2_ECDH_KeyGen.
(13) A subject with the role USER is authorized to recover a value that is used in
ECC based key sharing protocols using the command TPM2_ECDH_ZGen. The
user authorization shall be done based on the required authorization of the
involved private key.
(14) Any subject is authorized to request the parameters of an identified ECC
curve using the command TPM2_ECC_Parameters.
(15) The subject USER is authorized to start a HMAC sequence using the
command TPM2_HMAC_Start.
(16) The subject World is authorized to start a hash or event sequence using the
command TPM2_HashSequenceStart.
(17) The subject USER is authorized to add data to a hash, event or HMAC
sequence using the command TPM2_SequenceUpdate.
(18) The subject USER is authorized to add the last part of data (if any) to a hash
or HMAC sequence using the command TPM2_SequenceComplete.
(19) The subject USER is authorized to add the last part of data (if any) to an
event sequence using the command TPM2_EventSequenceComplete.
(20) Any subject is authorized to perform hash operations on a data buffer using
the command TPM2_Hash.
FDP_ACF.1.3/AC The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.4/AC The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: none.
SLB9670_2.0 v1.1 37 of 59
7.2.1 Extended Component FCS_RNG.1
To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of
the Class FCS (cryptographic support) is defined here. This family describes the functional
requirements for random number generation used for cryptographic purposes.
FCS_RNG.1 Random Number Generation
Hierarchical to: No other components

Dependencies: No dependencies
FCS_RNG.1 Random numbers generation Class DRG.3 according to [11]
FCS_RNG.1.1 The TSF shall provide a deterministic random number generator that
implements: NIST SP 800-90A CTR_DRBG. [N890]
FCS_RNG.1.2 The TSF shall provide random numbers that meet: Statistical test
suites cannot practically distinguish the random numbers from output
sequences of an ideal RNG.
Application Note 2: To fulfill the requirements defined in ―Anwendungshinweise und Interpre-

tationen zum Schema (AIS)‖ respectively ―Functionality classes for
random number generators‖ [11],
a refinement of the functional requirement FCS_RNG.1 is given in the
following:
FCS_RNG.1 Random numbers generation Class DRG.3 according to [11]
FCS_RNG.1.1 The TSF shall provide a deterministic random number generator that
implements:
(DRG.3.1) If initialized with a random seed using a PTRNG of class

PTG.2 as random source, the internal state of the RNG
shall have at least 100 bit of entropy and implements:
NIST SP 800-90A CTR_DRBG. [N890]
(DRG.3.2) The RNG provides forward secrecy.
(DRG.3.3) The RNG provides backward secrecy even if the current

internal state is known.
FCS_RNG.1.2 The TSF shall provide random numbers that meet:
(DRG.3.4) The RNG, initialized with a random seed, during every startup and
after 100 000 requests, of minimal 128 bits using a PTRNG of class
PTG.2, generates output for which more than 234 strings of bit length
128 are mutually different with probability w>1-2-16.
(DRG.3.5) Statistical test suites cannot practically distinguish the random

numbers from output sequences of an ideal RNG. The random
numbers must pass test procedure A.
End of Application Note 2.

SLB9670_2.0 v1.1 38 of 59
7.3 Security Assurance Requirements
The security assurance requirements (SAR) of the TOE are the assurance components of the
Evaluation Assurance Level 4 (EAL4) as defined in the Common Criteria [1] [2] [3] and augmented
with ALC_FLR.1 and ADV_VAN.4. They are all drawn from the Common Criteria V3.1 part 3. The
security assurance components are listed in Table 4.
The security assurance requirements defined in Table 4 are defined in section 7.2 of the PP [8].
Table 4: Assurance components
Assurance Assurance Assurance Components description

#
Class Component
1 ADV_ARC.1 Security architecture description
ADV:
2 ADV_FSP.4 Complete functional specification
Development
3 ADV_IMP.1 Implementation representation of the TSF
4 ADV_TDS.3 Basic modular design
AGD: Guidance
5 AGD_OPE.1 Operational user guidance
documents
6 AGD_PRE.1 Preparative procedures
Production support, acceptance procedures

7 ALC_CMC.4
and automation
ALC: Life-cycle
8 ALC_CMS.4 Problem tracking CM coverage
support
9 ALC_DEL.1 Delivery procedures
10 ALC_DVS.1 Identification of security measures
11 ALC_LCD.1 Developer defined life-cycle model
12 ALC_FLR.1 Basic flow remediation -- augmented
13 ALC_TAT.1 Well-defined development tools
14 ASE_CCL.1 Conformance claims
ASE: Security
15 Target ASE_ECD.1 Extended components definition
evaluation
16 ASE_INT.1 ST introduction
17 ASE_OBJ.2 Security objectives
18 ASE_REQ.2 Derived security requirements
19 ASE_SPD.1 Security problem definition
SLB9670_2.0 v1.1 39 of 59
20 ASE_TSS.1 TOE summary specification
21 ATE: Tests ATE_COV.2 Analysis of coverage
22 ATE_DPT.1 Testing: basic design
23 ATE_FUN.1 Functional testing
24 ATE_IND.2 Independent testing – sample
AVA :
25 Vulnerability AVA_VAN.4 Methodical vulnerability analysis -- augmented
assessment
7.4 Security Requirements Rationale

The security requirements rationale of the TOE are defined and described in the PP [8], section 7.3
Security Requirements rationale.
SLB9670_2.0 v1.1 40 of 59
8 TOE Summary Specification (ASE_TSS)
The product overview is given in section 2.1. In the following the security functionality and the
assurance measures of the TOE are described.
8.1 TOE Security Features

This section contains the definition and description of the security features (SF) of the TOE. The
TOE provides five security features (SF) to meet the security functional requirements. The security
features are:
SF_CRY: Cryptographic Support

SF_I&A: Identification and Authentication
SF_G&T General and Test
SF_OBH Object Hierarchy
SF_TOP TOE Operation
8.1.1 SF_CRY - Cryptographic Support
There are several functions within the TOE related to cryptographic support: generation of random
numbers, generation of asymmetric key pairs, RSA and ECC digital signature (generation and
verification), RSA, ECC and AES data encryption and decryption, key destruction, the generation
of hash values and the generation and verification of MAC values.
The TOE supports the generation of cryptographic keys in accordance with the specified
cryptographic key generation algorithm RSA key generator and ECC key generator and specified
cryptographic key sizes RSA 1024 and 2048 bits that meet the following: [RFC3447] and optional
[N808] and ECC with key sizes of 256 bits that meet [159461] and optional [N808]. The source of
randomness is the internal random generator.
The covered security functional requirements are FCS_CKM.1/PKRSA, FCS_CKM.1/PKECC,
FCS_CKM.1/RSA and FCS_CKM.1/ECC.
The TOE supports the generation of symmetric cryptographic keys in accordance with the
specified cryptographic key generation algorithm AES key generator and specified cryptographic
key sizes 128 bits that meet [N8133] and optional [N808].
The covered security functional requirements are FCS_CKM.1/PKSYMM and FCS_CKM.1/SYMM.
The TOE supports the destruction of cryptographic keys by erasure of volatile memory
areas containing cryptographic keys in accordance with FIPS PUB 140-2 [F1402], section 4.7.6.
The covered security functional requirement is FCS_CKM.4.
The TOE performs the encryption and decryption in accordance with the specified cryptographic
algorithm AES in the CFB mode and cryptographic key size of 128 bits that meet [18033] and
[10116].
The covered security functional requirement is FCS_COP.1/AES.
The TOE performs the hash value calculation in accordance with the specified cryptographic
algorithm SHA-1 and SHA-256 (cryptographic key sizes not available) that meets [10118].
The covered security functional requirement is FCS_COP.1/SHA.
The TOE performs HMAC value calculation and verification in accordance with the specified
cryptographic algorithm HMAC with SHA-1 and SHA-256 and cryptographic key sizes 160 bits that
meets [9797] and [10118].
SLB9670_2.0 v1.1 41 of 59
The covered security functional requirements are FCS_COP.1/HMAC1 and FCS_COP.1/HMAC.
The TOE performs asymmetric encryption and decryption in accordance with the specified
cryptographic algorithm RSA without padding, RSAES-PKCS1-v1_5, RSAES-OAEP and
cryptographic key sizes 1024 bits and 2048 bits that meet [RFC3447].
The covered security functional requirements are FCS_COP.1/RSAED1 and FCS_COP.1/RSAED.
The TOE performs signature generation and signature verification in accordance with the specified
cryptographic algorithm RSASA_PKCS1v1_5, RSASSA_PSS and cryptographic key sizes 1024
bits and 2048 bits that meet [RFC3447].
The covered security functional requirement is FCS_COP.1/RSASign1 and FCS_COP.1/RSASign.
The TOE performs signature generation and signature verification in accordance with the specified
cryptographic algorithm ECDSA with curve TPM_ECC_NIST_P256 and cryptographic key sizes
256 bits that meet TPM library specification [5] section C.4 and [14888].
The covered security functional requirement is FCS_COP.1/ECDSA.
The TOE performs signature generation in accordance with the specified cryptographic algorithm
ECDAA with curve TPM_ECC_NIST_P256 and TPM_ECC_BN_P256 and cryptographic key sizes
256 bits that meet TPM library specification [5], section C4.2.
The covered security functional requirement is FCS_COP.1/ECDAA.
The TOE performs decryption of ECC key in accordance with the specified cryptographic algorithm
ECDH with curve TPM_ECC_NIST_P256 and cryptographic key sizes 256 bits that meet TPM
library specification [7] and [N856], section 6.1.1.2.
The covered security functional requirement is FCS_COP.1/ECDEC.
The TOE provides a deterministic random number generator (DRBG) including a true random
generator, which is used for the seeding of the DRBG, to provide the random numbers. The TOE
provides random numbers that fulfils the requirements from the functional class DRG.3 of [11] and
[N890].The TOE uses the internal true random generator as the source for any randomness that
the processes defined in SF_CRY may require.
The covered security functional requirement is FCS_RNG.1.
The SF_CRY ―Cryptographic Support‖ covers the following security functional requirements:
FCS_CKM.1/PKRSA, FCS_CKM.1/PKECC, FCS_CKM.1/PKSYMM, FCS_CKM.1/RSA,
FCS_CKM.1/ECC, FCS_CKM.1/SYMM, FCS_CKM.4, FCS_COP.1/AES, FCS_COP.1/SHA,
FCS_COP.1/HMAC1, FCS_COP.1/HMAC, FCS_COP.1/RSAED1, FCS_COP.1/RSAED,
FCS_COP.1/RSASign1, FCS_COP.1/RSASign, FCS_COP.1/ECDSA, FCS_COP.1/ECDAA,
FCS_COP.1/ECDEC and FCS_RNG.1.
8.1.2 SF_I&A - Identification and Authentication
The TPM provides two mechanisms for the identification and authentication capability to authorize
the use of an Protected Object and Protected Capability. Note that the TCG TPM Library
specification refers to the identification and authentication process and access control as
authorization. The first authentication mechanisms is the prove of knowledge of a shared secret
(password or secret for HMAC) assigned to the entity as authValue. The second mechanism is the
authentication of the user and verification of an intended state of the TPM and its environment
encoded in authPolicy and assigned to the entity.
The TOE provides a mechanism to generate secrets that meet uniform distribution of random
variable generating the value, and is able to enforce the use of TSF generated secrets for nonce
values for authorization sessions unknown authValues.
SLB9670_2.0 v1.1 42 of 59
The covered security functional requirement is FIA_SOS.2.
The TOE use different rules to set the value of security attributes.
The covered security functional requirement is FMT_MSA.4/AUTH.
The TOE provides the management functionality of the TSF data by user authorization.
The covered security functional requirement is FMT_MTD.1/AUTH.
TOE detects when the maximal tries of unsuccessful authentication attempts occur for objects and
NV Index where DA is active and blocks the authorizations for a defined time.
The covered security functional requirement is FIA_AFL.1/Recover.
The TOE detect when one unsuccessful authentication attempts occur using lockoutAuth in the
command TPM2_DictionaryAttackLockReset and blocks the TPM2_DictionaryAttackLockReset
command for a defined time.
The covered security functional requirement is FIA_AFL.1/Lockout.
The TOE allows access to a defined number of commands and objects for the user to be
performed before the user is authenticated/identified.
The covered security functional requirements are FIA_UID.1 and FIA_UAU.1.
The TOE provides different authentication mechanisms to support user authentication and
authenticate any user's claimed identity according to the different rules. The TOE provides re-
authentication of the user for multiple command processing.
The covered security functional requirements are FIA_UAU.5 and FIA_UAU.6.
The TOE associate security attributes with subjects acting on the behalf of that user. The TOE
enforces different rules on the initial association of user security attributes with subjects acting on
the behalf of users and enforces different rules governing changes to the user security attributes
associated with subjects acting on the behalf of users.
The covered security functional requirement is FIA_USB.1.
The SF_I&A ―Identification and Authentication‖ covers the following security functional
requirements: FIA_SOS.2, FIA_MSA.4/AUTH, FMT_MTD.1/AUTH, FIA_AFL.1/Recover,
FIA_AFL.1/Lockout, FIA_UID.1, FIA_UAU.1, FIA_UAU.5, FIA_UAU.6 and FIA_USB.1.
8.1.3 SF_G&T – General and Test
The TOE provides the roles: Platform firmware, Platform owner, Privacy Administrator, Lockout
Administrator, User, Admin, DUP and World and associates users with roles. The roles are
enforced within the TOE because there are specific commands and specific keys bond to different
token.
The covered security functional requirement is FMT_SMR.1.
The TOE performs different management functions.
The covered security functional requirement is FMT_SMF.1.
The TOE ensures that only secure values are accepted for security attributes.
The covered security functional requirement is FMT_MSA.2.
The TOE provides reliable time stamps as number of milliseconds the TOE has been powered
since initialization of the Clock value.
The covered security functional requirement is FPT_STM.1.
SLB9670_2.0 v1.1 43 of 59
The TOE ensures that any previous information content of a resource is made unavailable upon
the deallocation of the resource from defined objects.
The covered security functional requirement is FDP_RIP.1.
The TOE supports a suite of self tests during startup and at the request of an authorized user world
to demonstrate the correct operation of sensitive parts of the TSF and to verify the integrity of
stored TSF executable code and parts of TSF data.
The covered security functional requirement is FPT_TST.1.
The TOE preserves a secure state by entering the Fail state when a failure during TPM Restart or
Resume occurs, a failure is detected by TPM2_ContecxtLoad or the self test, of any crypto
operations including RSA encryption, RSA decryption, AES encryption, AES decryption, SHA-1,
RNG, RSA signature generation, HMAC generation or failure of any commands or internal
operations and authorization occurs.
The covered security functional requirement is FPT_FLS.1/FS.
The TOE preserves a secure state by shutdown, when detecting a physical attack or an
environmental condition which is out of spec value.
The covered security functional requirement is FPT_FLS.1/SD.
The TOE resists physical manipulation and physical probing to the TSF by responding
automatically such that the SFRs are always enforced.
The TOE supports the following functions for protection against and detection of physical
manipulation and probing:
 The correct function of the TOE is only given in the specific range of the environmental
operating parameters. To prevent an attack exploiting those circumstances the external clock
conditions, the temperature and electro magnetic radiation (e.g. light) are observed to detect if
the specified range is left. The TOE falls into the defined secure state in case of a specified
range violation. The defined secure state causes the chip internal reset process.
 The data in the EEPROM are automatically monitored by the EDC. In case of a 1 bit error the
memory content is corrected by the ECC, in case of more bit errors the TOE enters the secure
state.
 Several mechanisms protect the TOE against snooping the design or the user data during
operation and even if it is out of operation (power down). There are topological design
measures for disguise, such as the protection of security critical lines by specific intelligent and
intrinsic shielding including secure wiring of security critical signals. The entire design is kept in
a non standard way to prevent attacks using standard analysis methods. A dedicated CPU with
a non public bus protocol is used which makes analysis complicated.
 The readout of data can be controlled with the use of encryption. An attacker can not use the
data obtained by espionage due to their encryption. The memory contents of the TOE are
encrypted on chip to protect against data analysis on stored data as well as on internally
transmitted data.
 The virtual physical address mapping together with the memory management unit (MMU) gives
the operating system the possibility to define different access rights for memory areas. In case
of an access violation the MMU will generate a non maskerable interrupt (NMI) and an interrupt
service routine react on the access violation.
The covered security functional requirement is FPT_PHP.3.
The SF_G&T ―General and Test‖ covers the following security functional requirements:
FMT_SMR.1, FMT_SMF.1, FMT_MSA.2, FPT_STM.1, FDP_RIP.1, FPT_TST.1, FPT_FLS.1/FS,
FPT_FLS.1/SD and FPT_PHP.3.
SLB9670_2.0 v1.1 44 of 59
8.1.4 SF_OBH - Object Hierarchy
The TOE supports different states during his life-cycle as described in [8] section 7.1.4.1 ―TPM
Operational States‖ in detail.
The TOE enforces the TPM State Control SFP on all subjects and objects and all operations
among subjects and objects covered by the SFP. The TOE ensure that all operations between any
subject controlled by the TSF and any object controlled by the TSF are covered by an access
control SFP and enforces different access control rules on controlled subjects and objects.
The covered security functional requirements are FDP_ACC.2/States and FDP_ACF.1/States.
The TOE enforce the TPM state control SFP to restrict the ability to modify the security attributes
TPM state and to provide restrictive default values for security attributes that are used to enforce
the SFP. The TOE enforce the TPM state control SFP to receive firmware update data in a manner
protected from errors and determines on receipt of firmware update data, whether error has
occurred.
The covered security functional requirements are FMT_MSA.1/States, FMT_MSA.3/States and
FDP_UIT.1/States.
The TOE supports three different hierarchies, the platform hierarchy, the storage hierarchy and the
endorsement hierarchy. The root of each TPM hierarchy is defined by a primary seed which is a
random value persistently stored in the TOE. A hierarchy may be disabled.
The TOE monitors user data stored in containers controlled by the TSF for data modifications and
modification of hierarchy on all objects, based on the different attributes.
The covered security functional requirement is FDP_SDI.1.
The TOE enforces the TPM Object Hierarchy SFP on defined subjects, objects and operations and
enforces different rules to determine if an operation among controlled subjects and controlled
objects is allowed and deny access of subjects to objects based on different rules.
The covered security functional requirements are FDP_ACC.1/Hier and FDP_ACF.1/Hier.
The TOE enforces the TPM Object Hierarchy SFP to not allow the modification of the security
attributes fixedTPM and fixedParent.
The covered security functional requirement is FMT_MSA.1/Hier.
The TOE enforces the TPM Object Hierarchy SFP to provide restrictive default values for security
attributes that are used to enforce the SFP and allows the creator of an object in a TPM hierarchy
to specify alternative initial values to override the default values when an object or information is
created.
The TOE enforces different rules to set the value of security attributes.
The TOE allows the import and export of data as an object of a hierarchy.
The TOE enforces the Data Export and Import SFP on subjects, objects and operations. The Data
Export and Import SFP enforce different rules to determine if an operation between a controlled
subject and controlled object is allowed.
The covered security functional requirements are FDP_ACC.1/ExIm and FDP_ACF.1/ExIm.
The TOE enforce the Data Export and Import SFP to restrict the ability to use the security attribute
authorization data to every subject, to provide restrictive default values for security attributes that
are used to enforce the SFP and to prevent to override the default values when an object or
information is created.
The covered security functional requirements are FMT_MSA.1/ExIm and FMT_MSA.3/ExIm.
SLB9670_2.0 v1.1 45 of 59
The TOE enforces the Data Export and Import SFP when exporting user data, controlled under the
SFP(s), outside of the TOE and to export the user data with the user data's associated security
attributes. The TOE ensure that the security attributes, when exported outside the TOE, are
unambiguously associated with the exported user data and different rules are enforced when user
data is exported from the TOE.
The covered security functional requirement is FDP_ETC.2/ExIm.
The TOE enforces the Data Export and Import SFP when importing user data, controlled under the
SFP(s), outside of the TOE. The correct interpretation, association and use of the security
attributes associated with the imported user data are ensured and different rules are enforced
when user data is imported from outside the TOE.
The covered security functional requirement is FDP_ITC.2/ExIm.
The TOE enforces the Data Export and Import SFP to transmit user data in a manner protected
from unauthorised disclosure and to transmit and receive user data in a manner protected from
modification errors. The TOE is able to determine on receipt of user data, whether modification has
occurred.
The covered security functional requirements are FDP_UCT.1/ExIm and FDP_UIT.1/ExIm.
The TOE enforces the Measurement and Reporting SFP on subjects, objects and operations. The
Measurement and Reporting SFP enforce different rules to determine if an operation among
controlled subjects and controlled objects is allowed.
The covered security functional requirements are FDP_ACC.1/M&R and FDP_ACF.1/M&R.
The TOE enforces the Measurement and Reporting SFP to restrict the ability to modify the security
attributes PCR attributes, PCR extension algorithm and used hash algorithm to the subject
Platform firmware, to provide restrictive default values for security attributes that are used to
enforce the SFP, and to prevent to override the default values when an object or information is
created.
The covered security functional requirements are FMT_MSA.1/M&R and FMT_MSA.3/M&R.
The TOE is able to generate evidence of origin for transmitted attestation structure and object
creation tickets at the request of the originator and provide a capability to verify the evidence of
origin of information to recipient given as soon as the recipient can verify the signature and has
confidence to the key that is used to sign.
The covered security functional requirement is FCO_NRO.1/M&R.
The SF_OBH ―Object Hierarchy‖ covers the following security functional requirements:
FDP_ACC.2/States, FDP_ACF.1/States, FMT_MSA.1/States, FMT_MSA.3/States,
FDP_UIT.1/States, FDP_SDI.1, FDP_ACC.1/Hier, FDP_ACF.1/Hier, FMT_MSA.1/Hier,
FMT_MSA.3/Hier, FMT_MSA.4/Hier, FDP_ACC.1/ExIm, FDP_ACF.1/ExIm, FMT_MSA.1/ExIm,
FMT_MSA.3/ExIm, FDP_ETC.2/ExIm, FDP_ITC.2/ExIm, FDP_UCT.1/ExIm, FDP_UIT.1/ExIm,
FDP_ACC.1/M&R, FDP_ACF.1/M&R, FMT_MSA.1/M&R, FMT_MSA.3/M&R and
FCO_NRO.1/M&R.
8.1.5 SF_TOP – TOE Operation
The TOE enforces the Access Control SFP on different subjects, objects and operations and
enforces different rules to determine if an operation among controlled subjects and controlled
objects is allowed. The TOE explicitly authorize access of subjects to objects based on different
additional rules and explicitly deny access of subjects to objects based on the different additional
rules.
The covered security functional requirements are FDP_ACC.1/AC and FDP_ACF.1/AC.
SLB9670_2.0 v1.1 46 of 59
The TOE enforces the Access Control SFP to restrict the ability to query and modify different
security attributes to specific subjects, to provide restrictive default values for security attributes
that are used to enforce the SFP and to specify alternative initial values to override the default
values when an object or information is created.
The covered security functional requirements are FMT_MSA.1/AC and FMT_MSA.3/AC.
The TOE enforces the Access Control SFP to transmit user data in a manner protected from
unauthorised disclosure. The TOE provides a communication channel between itself and another
trusted IT product that is logically distinct from other communication channels and provides
assured identification of its end points and protection of the channel data from modification or
disclosure. The TOE initiates communication via the trusted channel and permits another trusted IT
product to initiate communication via the trusted channel.
The covered security functional requirements are FDP_UCT.1/AC and FTP_ITC.1/AC.
The TSF shall restrict the ability to disable and enable the functions TPM2_Clear to the subjects
Platform firmware and Lockout administrator.
The covered security functional requirement is FMT_MOF.1/AC.
The TSF shall enforce the NVM SFP on different subjects, objects and operations and enforces
different rules to determine if an operation among controlled subjects and controlled objects is
allowed.
The covered security functional requirements are FDP_ACC.1/NVM and FDP_ACF.1/NVM.
The TOE enforces the NVM SFP to restrict the ability to query and modify the security attribute NV
index attributes to the authorized role of the subject that executes the NVM related command and
to provide restrictive default values when an object or information is created. The TOE prohibits to
override the default values with alternative initial values when an object or information is created.
The TOE enforces different rules to set the value of security attributes and restrict the ability to
modify the authorization secret (authValue) for a NV index to the subject ADMIN.
The covered security functional requirements are FMT_MSA.1/NVM, FMT_MSA.3/NVM,
FMT_MSA.4/NVM and FMT_MTD.1/NVM.
The TOE enforces the NVM SFP when importing user data, controlled under the SFP, and ignores
any security attributes associated with the user data when imported from outside the TOE.
Additionally the TOE enforces different rules when importing user data controlled under the SFP
from outside the TOE. The TOE enforces the NVM SFP when exporting user data, controlled
under the SFP(s), outside of the TOE.
The covered security functional requirements are FDP_ITC.1/NVM and FDP_ETC.1/NVM.
The TOE enforces the Credential SFP on different subjects, objects and operations and enforces
different rules to determine if an operation among controlled subjects and controlled objects is
allowed.
The covered security functional requirements are FDP_ACC.1/Cre and FDP_ACF.1/Cre.
The TOE enforces the Credential SFP to provide restrictive default values for security attributes
that are used to enforce the SFP and prevents to override the default values when an object or
information is created. The TOE enforces the Credential SFP to restrict the ability to use the
security attributes HMAC in the credential BLOB to the subject USER.
The covered security functional requirements are FMT_MSA.1/Cre and FMT_MSA.3/Cre.
The TOE generates evidence of origin for transmitted TPM objects at the request of the originator
and relates the information whether the object is resident in an authentic TPM of the originator of
the information, and the name and the public area of the TPM object of the information to which the
evidence applies. The TOE provides a capability to verify the evidence of origin of information to
the initiator given based on a credential BLOB that was generated by the credential provider.
The covered security functional requirement is FCO_NRO.1/Cre.
SLB9670_2.0 v1.1 47 of 59
The SF_TOE ―TOE Operation‖ covers the following security functional requirements:
FDP_ACC.1/AC, FDP_ACF.1/AC, FMT_MSA.1/AC, FMT_MSA.3/AC, FDP_UCT.1/AC,
FTP_ITC.1/AC, FMT_MOF.1/AC, FDP_ACC.1/NVM, FDP_ACF.1/NVM, FMT_MSA.1/NVM,
FMT_MSA.3/NVM, FMT_MSA.4/NVM, FMT_MTD.1/NVM, FDP_ITC.1/NVM, FDP_ETC.1/NVM,
FDP_ACC.1/Cre, FDP_ACF.1/Cre, FMT_MSA.1/Cre, FMT_MSA.3/Cre and FCO_NRO.1/Cre.
SLB9670_2.0 v1.1 48 of 59
8.1.6 Assignment of Security Functional Requirements

The justification of the mapping between security functional requirements and the security features
is given in sections 8.1.1 – 8.1.5. The results are shown at following table.
Security Functional SF_ SF_ SF_ SF_ SF_

Requirement CRY I&A G&T OBH TOP
FMT_SMR.1 X
FMT_SMF.1 X
FMT_MSA.2 X
FPT_STM.1 X
FDP_RIP.1 X
FCS_RNG.1 X
FCS_CKM.1/PKRSA X
FCS_CKM.1/PKECC X
FCS_CKM.1/PKSYM X
FCS_CKM.1/RSA x
FCS_CKM.1/ECC x
FCS_CKM.1/SYMM X
FCS_CKM.4 X
FCS_COP.1/AES X
FCS_COP.1/SHA X
FCS_COP.1/HMAC1 X
FCS_COP.1/HMAC X
FCS_COP.1/RSAED1 X
FCS_COP.1/RSAED X
FCS_COP.1/RSASign1 X
FCS_COP.1/RSASign X
FCS_COP.1/ECDSA X
FCS_COP.1/ECDAA X
FCS_COP.1/ECDEC X
FIA_SOS.2 X
SLB9670_2.0 v1.1 49 of 59
FMT_MSA.4/AUTH X
FMT_MTD.1/AUTH X
FIA_AFL.1/Recover X
FIA_AFL.1/Lockout X
FIA_UID.1 X
FIA_UAU.1 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_USB.1 X
FPT_TST.1 X
FPT_FLS.1/FS X
FPT_FLS.1/SD X
FPT_PHP.3 X
FDP_ACC.2/States X
FDP_ACF.1/States X
FMT_MSA.1/States X
FMT_MSA.3/States X
FDP_UIT.1/States X
FDP_SDI.1 X
FDP_ACC.1/Hier X
FDP_ACF.1/Hier X
FMT_MSA.1/Hier X
FMT_MSA.3/Hier X
FMT_MSA.4/Hier X
FDP_ACC.1/ExIm X
FDP_ACF.1/ExIm X
FMT_MSA.1/ExIm X
FMT_MSA.3/ExIm X
FDP_ETC.2/ExIm X
FDP_ITC.2/ExIm X
FDP_UCT.1/ExIm X
SLB9670_2.0 v1.1 50 of 59
FDP_UIT.1/ExIm X
FDP_ACC.1/M&R X
FDP_ACF.1/M&R X
FMT_MSA.1/M&R X
FMT_MSA.3/M&R X
FCO_NRO.1/M&R X
FDP_ACC.1/AC X
FDP_ACF.1/AC X
FMT_MSA.1/AC X
FMT_MSA.3/AC X
FDP_UCT.1/AC X
FTP_ITC.1/AC X
FMT_MOF.1/AC X
FDP_ACC.1/NVM X
FDP_ACF.1/NVM X
FMT_MSA.1/NVM X
FMT_MSA.3/NVM X
FMT_MSA.4/NVM X
FMT_MTD.1/NVM X
FDP_ITC.1/NVM X
FDP_ETC.1/NVM X
FDP_ACC.1/Cre X
FDP_ACF.1/Cre X
FMT_MSA.1/Cre X
FMT_MSA.3/Cre X
FCO_NRO.1/Cre X
Table 5: Assignment security functional requirement to security features
SLB9670_2.0 v1.1 51 of 59
8.2 Security Function Policy

The TOE enforces user access to cryptographic IT assets in accordance with the following security
function policies (SFP)
 TPM State Control SFP
 Access Control SFP
 NVM SFP
 TPM Object Hierarchy SFP
 Measurement and Reporting SFP
 Data Export and Import SFP
 Credential SFP
to meet the security functional requirements.
These policies include different subjects (roles), protected objects and operations which are
described in the following. A detailed description is given of the subjects and the protected objects
with there accompanying operations and security attributes are defined in PP [8], section 7.1.1 and
in Table 7 and Table 8.
The protected objects treated by the TOE are the data generated or stored in the shielded location
or to be imported into or be exported from the shielded locations. The operations of the TOE are
the protected capabilities of the TPM which are defined by the TPM commands (cf. [7]).
The Table 4 of the PP [8] lists the protected objects, the operation via reference to the commands
as described in the TPM Library specification [7] and the security attributes of the objects as
described in the TPM Library specification [6].
The policy ―TPM State Control SFP‖ enforces the TOE to fulfill the requirements given in the
following security enforcing functions: FDP_ACC.2/States, FDP_ACF.1/States,
FMT_MSA.1/States, FMT_MSA.3/States and FDP_UIT.1/States.
The policy ―Access Control SFP‖ enforces the TOE to fulfill the requirements given in the following
security enforcing functions: FDP_ACC.1/AC, FMT_MSA.1/AC, FMT_MSA.3/AC and
FDP_UCT.1/AC.
The policy ―NVM SFP‖ enforces the TOE to fulfill the requirements given in the following security
enforcing functions: FDP_ACC.1/NVM, FDP_ACF.1/NVM, FMT_MSA.1/NVM, FMT_MSA.3/NVM,
FDP_ITC.1/NVM and FDP_ETC.1/NVM.
The policy ―TPM Object Hierarchy SFP‖ enforces the TOE to fulfill the requirements given in the
following security enforcing functions: FDP_ACC.1/Hier, FDP_ACF.1/Hier, FMT_MSA.1/Hier and
FMT_MSA.3/Hier.
The policy ―Measuremet and Reporting SFP‖ enforces the TOE to fulfill the requirements given in
the following security enforcing functions: FDP_ACC.1/M&R, FDP_ACF.1/M&R, FMT_MSA.1/M&R
and FMT_MSA.3/M&R.
The policy ―Data Export and Import SFP‖ enforces the TOE to fulfill the requirements given in the
following security enforcing functions: FDP_ACC.1/ExIm, FDP_ACF.1/ExIm, FMT_MSA.1/ExIm,
FMT_MSA.3/ ExIm, ETC.2/ExIm, ITC.2/ExIm, UTC.1/ExIm and UIT.1/ExIm.
The policy ―Credential SFP‖ enforces the TOE to fulfill the requirements given in the following
security enforcing functions: FDP_ACC.1/Cre, FDP_ACF.1/Cre, FMT_MSA.1/Cre, and
FMT_MSA.3/Cre.
SLB9670_2.0 v1.1 52 of 59
9 Reference
9.1 Literature
[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; Version 3.1,
Revision 4, CCMB-2012-09-001, September 2012
[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security
Functional Requirements; Version 3.1,
[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Requirements; Version 3.1,
[4] Common Methodology for Information Technology Security Evaluation Methodology,
Evaluation Methodology, Version 3.1,
[5] Trusted Platform Module Library Part 1: Architecture, Family ‖2.0‖ Level 00
Revision 1.16, October 30, 2014, Trusted Computing Group, Incorporated
[6] Trusted Platform Module Library Part 2: Structures, Family ‖2.0‖ Level 00
[7] Trusted Platform Module Library Part 3: Commands, Family ―2.0‖, Level 00,
[8] Protection Profile PC Client Specific TPM, TPM Library specification Family ―2.0‖ Level 0
Revision 1.16; Version 1.0; December 10, 2014;
Certificate ANSSI-CC-PP-2015/07 dated 2015-05-06
[9] TCG PC Client Specific Platform TPM Profile (PTP) Specification, Family ―2.0‖, Level 00,
Revision 00.43, January 26, 2015
[10] Trusted Platform Module Library Part 4 Supporting Routines, Family ―2.0‖, Level 00,
[11] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS20 Version 3,
15.05.2013
A propsal for: Functionality classes for random number generators, Version 2.0, 2011-09-18
Bundesamt für Sicherheit in der Informationstechnik (BSI9
[12] TPM Trusted Platform Module Version 2.0 Application Note User Guidance
Infineon Technologies AG, Revision 1.60, 2015-08
[13] TPM Trusted Platform Module Version 2.0 Errata and Updates, Infineon Technologies AG,
Revision 1.5, 2016-04-11
[14] Trusted Platform Module TPM SLB9670 TCG Family 2 Level 00 Rev. 01.16, Databook,
Infineon Technologies AG, Revision 1.4, 2015-10-12
Trusted Platform Module TPM SLB9670 TCG Family 2 Level 00 Rev. 01.16, Databook,
Infineon Technologies AG, Revision 1.5, 2016-04-08
[TPM] Trusted Computing Group TPM Library be made of [5], [6], [7] and [10]
[RFC3447] IETF RFC 3447, Public-Key Cryptography Standards PKCS#1:
RSA Cryptography Specifications Version v2.1; June 14, 2002
RSA Cryptography Specifications Version v2.0; October 1, 1998
SLB9670_2.0 v1.1 53 of 59
[IEEE1363] IEEE Std 1363TM -2000, Standard Specifications for Public Key Cryptography
IEEE Std 1363aTM -2004, Standard Specifications for Public Key Cryptography
[N808] NIST Special Publication SP 800-108, October 2009, Recommendation for
Key Derivation Using Pseudorandom Functions (revised)
[N856] NIST SP800-56A, Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography (Revised)
[N890] NIST Special Publication 800-90A: Recommendation for Random Number
Generation Using Deterministic Random Bit Generators. January 2012
[N8133] NIST Special Publication 800-133; Recommendation for Cryptographic Key
Generation; December 2012
[159461] ISO/IEC 15946-1, Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 1: General
[14888] ISO/IEC 14888-3, Information technology - Security techniques – Digital
signature with appendix – Part 3: Discrete logarithm based mechanism
[18033] ISO/IEC 18033-3: 2005, Information technology -- Security techniques -- Encryption
algorithms -- Part 3: Block ciphers
[10116] ISO/IEC 10116:2006, Information technology — Security techniques — Modes
of operation for an n-bit block cipher;
NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of
Operation. December 2001
[10118] ISO/IEC 10118-3: 2004, Information technology -- Security techniques -- Hash-
functions -- Part 3: Dedicated hash-functions
[159465] ISO/IEC 15946-5: 2008; Information technology -- Security techniques --
Cryptographic techniques based on elliptic curves -- Part 5: Elliptic curve
generation; Clause 7.3 (definition of ‖Barreto-Naehrig (BN) elliptic curve)
[9797] ISO/IEC 9797-2, Information technology -- Security techniques – Message
authentication codes (MACs) -- Part 2: Mechanisms using a dedicated
hash-function
[F1402] FIPS PUB 140-2, Security Requirements for Cryptographic Modules,
Change Notices (12-03-2003), U.S. Department of Commerce, National Institute of
Standards and Technology
[F1804] FIPS PUB 180-4, Federal Information Processing Standard 180-4 Secure
Hash Standard (SHS), U.S. Department of Commerce, National Institute of
Standards and Technology, Information Technology Laboratory (ITL);
ISO/IEC 10118-3, Information technology — Security techniques — Hashfunctions
— Part 3: Dedicated hash functions
[F1863] FIPS PUB 186-3 chapter D.1.2.3 Curve P-256
[F1864] FIPS PUB 186-4, section D.1.2.3 (definition of NIST_P256 elliptic curve)
[FUP] TPM-FieldUpgrade, DoxyGen Documentation, Infineon Technologies AG,
2015-02-20
SLB9670_2.0 v1.1 54 of 59
9.2 List of Abbreviations

CC - Common Criteria
CI - Chip Identification mode (STS-CI)
CIM - Chip Identification Mode (STS-CI), same as CI
CRC - Cyclic Redundancy Check
DPA - Differential Power Analysis
DFA - Differential Failure Analysis
DRBG - Deterministic Random Number Generator
EAL - Evaluation Assurance Level
ECC - Error Correction Code
EDC - Error Detection Code
EEPROM - Electrically Erasable and Programmable Read Only Memory
EMA - Electro magnetic analysis
HW - Hardware
IC - Integrated Circuit
ID - Identification
IRAM - Internal Random Access Memory
IT - Information Technology
I/O - Input/Output
MED - Memory Encryption and Decryption
MMU - Memory Management Unit
OS - Operating system
PLL - Phase Locked Loop
PP - Protection Profile
RMS - Resource Management System
RNG - Random Number Generator
RAM - Random Access Memory
ROM - Read Only Memory
SF - Security Feature
SFP - Security Function Policy
SFR - Special Function Register
SPA - Simple power analysis
ST - Security Target
STS - Self Test Software
SW - Software
TM - Test Mode (STS)
TOE - Target of Evaluation
TSF - TOE Security Functionality
TSP - TOE Security Policy
UM - User Mode (STS)
XRAM - eXtended Random Access Memory
SLB9670_2.0 v1.1 55 of 59
9.3 Glossery
Blob: Opaque data of fixed or variable size. The meaning and interpretation
of the data is outside the scope and context of the Subsystem.
Central Processing Unit(CPU): Logic circuitry for digital information processing.
Chip  Integrated Circuit
Chip Identification Mode: Operational status phase of the TOE, in which actions for
identifying the individual take place.
Controller: IC with integrated memory, CPU and peripheral devices.
CRC: Process for calculating checksums for error detection.
Challenger: An entity that requests and has the ability to interpret integrity metrics
from a Subsystem.
EEPROM: Nonvolatile memory permitting electrical read and write operations.
Endorsement Key: A term used ambiguously, depending on context, to mean a pair
of keys, or the public key of that pair, or the private key of that pair; an
asymmetric key pair generated by or inserted in a TPM that is used as
proof that a TPM is a genuine TPM; the public endorsement key
(PUBEK); the private endorsement key (PRIVEK).
Firmware: Part of the software implemented as hardware.
Hardware: Physically present part of a functional system.
Hash value: Result of a hash calculation e.g. SHA-1.
HMAC: A mechanism for message authorization according RFC 2104 using
the cryptographic hash function SHA-1.
Integrity metrics: Values that are the results of measurements on the identity for the
TPM.
Integrated Circuit: Component comprising several electronic circuits implemented in a
highly miniaturized device using semiconductor technology.
Internal Random Access Memory: RAM integrated in the CPU.
Man-in-the-middle attack: An attack by an entity intercepting communications between two
others without their knowledge and by intercepting that communication
able to obtain or modify the information between them.
Mechanism: Logic or algorithm which implements a specific security function in
Hardware or software.
Memory: Hardware part containing digital information (binary data).
Memory Encryption and Decryption: Method of encoding/decoding data transfer between
CPU and memory.
Memory Management Unit (MMU): The MMU controls the different access rights of memory
areas.
Microcontroller  Controller
Microprocessor  CPU
Migratable: A key that may be transported outside the specific TPM.
SLB9670_2.0 v1.1 56 of 59
Nonce: A nonce is a random number value that provides protection from replay
and other attacks.
Non-migratable: A key that cannot be transported outside the specific TPM. A key
that is (statistically) unique to a particular TPM.
Owner: The entity that owns the platform in which a TPM is installed. Since
there is, by definition, a one-to-one relationship between the TPM and
the platform, the Owner is also the Owner of the TPM. The Owner of
the platform is not necessarily the ―user‖ of the platform (e.g., in a
corporation, the Owner of the platform might be the IT department
while the user is an employee). The Owner has administration rights
over the TPM.
Platform Configuration Register (PCR): A PCR consists of a 160 bit field that holds a
cumulatively updated hash value and a 4 byte status field.
Private Endorsement Key (PRIVEK): The private key of the key pair that proves that a TPM
is a genuine TPM. The PRIVEK is (statistically) unique to only one
TPM.
Protected function: Access to this function requires an authorization process.
Public Endorsement Key(PUBEK): The public key that proves that a TPM is a genuine TPM.
The PUBEK is (statistically) unique to only one TPM.
Protection Profile: A document that defines all attacks and how they are resisted by the
TPM, the RTM, and the methods by which these are incorporated into
the platform.
Random Access Memory: Volatile memory which permits write and read operations.
Random Number Generator: Hardware part for generating random numbers.
Read Only Memory: Nonvolatile memory which permits read operations only.
Resource Management System: Part of the firmware containing EEPROM programming routines.
Root of Trust for
Measurement(RTM): The point from which all trust in the measurement process is predicated.
Root of Trust for
Reporting(RTR): The point from which all trust in reporting of measured information is predicated.
Root of Trust for
Storing(RTS): The point from which all trust in Protected Storage is predicated.
RSA: An asymmetric encryption method using two keys: a private key and
a public key. Reference: http://www.rsa.com.
SAM: Service Algorithm Minimal
Security Feature: Part(s) of the TOE used to implement part(s) of the security objectives.
Security Target: Description of the intended state for countering threats.
Self Test Software: Part of the firmware with routines for controlling the operating state
and testing the TOE hardware.
SHA-1: A hashing algorithm producing a 160-bit result from an arbitrary source
as specified in FIPS 180-2.
SHA-256: A hashing algorithm producing a 256-bit result from an arbitrary source
as specified in FIPS 180-2.
Shielded location: Storage location within the TPM with a protection against
unauthorized access.
SLB9670_2.0 v1.1 57 of 59
Smart Card: Plastic card in credit card format with built-in chip.
Storage Root Key (SRK): The root key of a hierarchy of keys associated with a TPM;
generated within a TPM; a non-migratable key.
Subsystem: The combination of the TSS and the TPM.
Software: Information (non-physical part of the system) which is required to
implement functionality in conjunction with the hardware (program).
Target of Evaluation: Product or system which is being subjected to an evaluation.
Test Mode: Operational status phase of the TOE in which actions to test the TOE
hardware take place.
Threat: Action or event that might prejudice security.
TpmProof: A random number stored within the TPM. The tpmProof is a unique
secret for each TPM.
Trusted Platform Module: The set of functions and data that are common to all types of
platform, which must be trustworthy if the Subsystem is to be
trustworthy; a logical definition in terms of protected capabilities and
shielded locations.
Trusted Platform Support Services (TSS): The set of functions and data which are common
to all types of platform, which are not required to be trustworthy (and
therefore do not need to be part of the TPM).
TCG-protected capability: A function that is protected within the TPM, and has access
to TPM secrets.
Trusted Set (TS): Subsystem capability that must be trustworthy for the subsystem.
TPM Identity: One of the anonymous PKI identities belonging to a TPM; a TPM may have
multiple identities.
User: An entity that uses the platform in which a TPM is installed. The only
rights that a User has over a TPM are rights given to the User by the
Owner. These rights are expressed in the form of authorization data,
given by the Owner to the User, that permits access to entities
protected by the Owner of the platform (e.g. in a corporation, the
owner of the platform might be the IT department while the User is an
employee). There can be multiple Users.
User Mode: Operational status phase of the TOE in which actions intended for the
user take place.
SLB9670_2.0 v1.1 58 of 59
Infineon Technologies – innovative semiconductor solutions for energy efficiency, mobility and security.
www.infineon.com Published by Infineon Technologies AG

K3-F - CPE - Criptochip 2 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

K3-F - CPE - Criptochip 2 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

To Institutul Național de Cercetare – Dezvoltare în Informatică

Memoria fiscală Custom MF001-02 constă în două blocuri fizice și funcționale:

1) Primul bloc este o memorie Flash de 2 megaocteți „Winbond W25Q16BSSI”

Primul bloc de memorie constă într-un dispozitiv Flash cu o capacitate de 2 megaocteți,

Al doilea bloc, criptocipul, îndeplinește trei funcții elementare:

- Derulează în manieră certificată toate procesele implicate în criptografie și

- Oferă acces și protecție la scriere pe memoria flash împotriva încercării de corupere

Criptocipul nostru este un microcontroler de securitate construit și programat de către

Protecția datelor conținute de memoria fiscală este garantată de un BLOC HARDWARE

- La finalizarea ciclului de scriere, PIN-ul revine în poziția PROTECȚIE LA SCRIERE și

Certificatul de siguranță al criptocipului este anexat la schema completă a memoriei fiscale și la

Infineon Technologies AG Trusted Platform

Certification Report V1.0 CC-Zert-327 V5.14

Bernd Kowalski L.S.

Bundesamt für Sicherheit in der Informationstechnik

This page is intentionally left blank.

1. Specifications of the Certification Procedure

2.1. European Recognition of ITSEC/CC – Certificates (SOGIS-MRA)

2.2. International Recognition of CC – Certificates (CCRA)

3. Performance of Evaluation and Certification

4. Validity of the Certification Result

2. Identification of the TOE

● Cryptographic Support: generation of random numbers, generation of asymmetric key

4. Assumptions and Clarification of Scope

7.1. Developer's Test according to ATE_FUN

7.2. Evaluator Testing

The TSF and the interfaces were found to behave as specified.

● Statistical tests of the TOE DRNG according to [4], AIS20 requirements.

● Electrical interface (INT 1.2),

9. Results of the Evaluation

● PP Conformance: Protection Profile, TPM Library specification Family “2.0”, Level 0

9.2. Results of cryptographic assessment

10. Obligations and Notes for the Usage of the TOE

11. Security Target

Protection Profile - A formal document defined in CC, expressing an implementation

This page is intentionally left blank.

C. Excerpts from the Criteria

Conformance Claim (chapter 10.4)

Class APE: Protection Profile evaluation (chapter 10)

APE_CCL.1 Conformance claims

Class APE: Protection APE_SPD.1 Security problem definition

Profile evaluation APE_OBJ.1 Security objectives for the operational environment

APE_ECD.1 Extended components definition

APE_REQ.1 Stated security requirements

APE: Protection Profile evaluation class decomposition”

Class ASE: Security Target evaluation (chapter 11)

ASE_CCL.1 Conformance claims

Class ASE: Security ASE_SPD.1 Security problem definition

Target evaluation ASE_OBJ.1 Security objectives for the operational environment

ASE_ECD.1 Extended components definition

ASE_REQ.1 Stated security requirements

ASE_TSS.1 TOE summary specification

ASE: Security Target evaluation class decomposition

Security assurance components (chapter 7)

The following table shows the assurance class decomposition.

Assurance Class Assurance Components

Assurance class decomposition

Evaluation assurance levels (chapter 8)

Evaluation assurance level (EAL) overview (chapter 8.1)

Evaluation assurance level 1 (EAL 1) - functionally tested (chapter 8.3)

Evaluation assurance level 2 (EAL 2) - structurally tested (chapter 8.4)

EAL 3 is applicable in those circumstances where developers or users require a moderate

Evaluation assurance level 4 (EAL 4) - methodically designed, tested, and reviewed