MIFARE DESFire EV1 MF3ICD81

MIFARE DESFire EV1 MF3ICD81 Rev.1.5 10 May 2011 BSI-DSZ-CC-0712 Evaluation Documentation Document information Info Keywords Abstract Content, MF3ICD81 Evaluation of the NXP Secure Smart Card Controller developed and provided by NXP Semiconductors, Business Unit Identification according to the Common Criteria for Information Technology Evaluation (CC) at Level EAL4 augmented

Revision history Rev Date Description Remarks 0.5 28 may 2008 Initial version Derived from full ST V1.3.1, Chapter 8.3 changed 0.9 28 may 2008 Internally Revised Version Revised by HGA & AHr 1.0 17 September 2008 Assumption A.Terminal_Support added (with related objective and requirement and further clarifications). Names of guidance documents changed. Derived from (full) ST V1.5 1.1 10 October 2008 Revision History corrected 1st line of Revision History of version 1.0 deleted 1.2 09 August 2010 Update: Table 1, hardware via and software Added new commercial type, MF3ICD01 1.3 14 February 2011 Role Nobody removed from FMT_SMR.1.1 Certification ID changed to 0712. 1.4 04 March 2011 Introduction of new delivery types: MOA8 and 75µm sawn wafer; Note added to FCS_COP.1[DES]. 1.5 10 May 2011 Added hardware version t507c. Latest version is: Rev.1.5 (10 May 2011) Contact information For additional information, please visit: http://www.nxp.com For sales office addresses, please send an email to: salesaddresses@nxp.com Evaluation Documentation Rev.1.5 10 May 2011 2 of 63

1. ST Introduction This chapter is divided into the following sections: ST Identification, ST Overview and CC Conformance and Evaluation Assurance Level. 1.1 ST Identification This Security Target (st-lite_mf3icd81.doc, Rev.1.5, 10 May 2011) refers to the "MIFARE DESFire EV1 MF3ICD81" (TOE) provided by NXP Semiconductors, Business Unit Identification for a Common Criteria evaluation. 1.2 ST Overview 1.2.1 Introduction NXP has developed the to be used with Proximity Coupling Devices (PCDs, also called terminal ) according to ISO14443 Type A. The communication protocol complies to part ISO 14443-4. The MF3ICD81 is primarily designed for secure contact-less transport applications and related loyalty programs as well as access control systems. It fully complies with the requirements for fast and highly secure data transmission, flexible memory organisation and interoperability with existing infrastructure. The TOE is a Smart Card comprising a hardware platform and a fixed software package (Smartcard Embedded Software). The software package provides an operating system with a set of functions used to manage the various kinds of data files stored in the nonvolatile EEPROM memory. The operating system supports a separation between the data of different applications and provides access control if required by the configuration. The TOE includes also IC Dedicated Software to support its start-up and for test purposes after production. The Smart Card Controller hardware comprises an 8-bit processing unit, volatile and non-volatile memories, cryptographic co-processors, security components and one communication interface. The TOE includes a functional specification and a guidance document. This documentation contains a description of the hardware and software interface, the secure configuration and usage of the product by the terminal designer. The security measures of the MF3ICD81 are designed to act as an integral part of the combination of hardware platform and software package in order to strengthen the product as a whole. Several security measures are completely implemented in and controlled by the hardware. Other security measures are controlled by the combination of hardware and software or software guided exceptions. 1.2.2 Life-Cycle Regarding the life cycle of the smartcard (refer to the Smartcard IC Platform Protection Profile, [7] section 8.1), the development and the production phase of the IC with its Smartcard Embedded Software as described for the Target of Evaluation (TOE) is part of the evaluation. Referring to the description in the PP [7], the TOE is delivered at the end of phase 3 or of phase 4 as described in section 2.1. Evaluation Documentation Rev.1.5 10 May 2011 3 of 63

Regarding the Application Note 1 of [7] the TOE does not provide additional functions supporting the card s life-cycle beyond those specified in the PP. Security during Development and Production During the design and the layout process of the IC and the development of the software only people involved in the specific development project have access to sensitive data. The security measures installed within NXP ensure a secure computer system and provide appropriate equipment for the different development tasks. The verified layout data is provided by the developers of NXP Semiconductors, Business Unit Identification directly to the wafer fab. The wafer fab generates and forwards the layout data related to the different photo masks to the manufacturer of the photo masks. The photo masks are generated off-site and verified against the design data of the development before the usage. The accountability and the traceability is ensured among the wafer fab and the photo mask provider. The test process of every die is performed by a test centre of NXP. Delivery processes between the involved sites provide accountability and traceability of the produced wafers. NXP embeds the dice into smartcard modules based on customer demand. Information about non-functional items is stored on magnetic/optical media enclosed with the delivery, available for download or the non-functional items are physically marked. In summary the TOE can be delivered in two different forms: Dice on wafers Smart Card Modules on a module reel The different (package) types are described in detail in section 2.2. 1.2.3 Specific Issues of Smartcard Hardware and the Common Criteria Regarding the Application Note 2 of [7] the TOE provides additional functionality which is not covered in the Smartcard IC Platform Protection Profile. The additional functionality is due to the Smartcard Embedded Software that is included in this evaluation. 1.3 CC Conformance and Evaluation Assurance Level The evaluation is based upon Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model, Version 2.3, August 2005, CCMB-2005-08-001, [1] Common Criteria for Information Technology Security Evaluation Part 2: Security functional requirements, Version 2.3, August 2005, CCMB-2005-08-002, [2] Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements, Version 2.3, August 2005, CCMB-2005-08-003, [3] For the evaluation the following methodology will be used: Common Methodology for Information Technology Security Evaluation: Evaluation Methodology, Version 2.3, August 2005, CCMB-2005-08-004, [4] The chosen level of assurance is EAL 4 augmented. The minimum strength level for the TOE security functions is SOF-high (Strength of functions high). This Security Target claims the following CC conformances: Evaluation Documentation Rev.1.5 10 May 2011 4 of 63

Part 2 extended, Part 3 conformant, EAL 4 augmented Conformance to the Protection Profile Smartcard IC Platform Protection Profile, [7] Regarding the Application Note 3 of [7] the ST does not change the augmentation as chosen in the Protection Profile. The augmentations to EAL4 defined by the Protection Profile are ADV_IMP.2, ALC_DVS.2, AVA_MSU.3, and AVA_VLA.4. Evaluation Documentation Rev.1.5 10 May 2011 5 of 63

2. TOE Description This chapter is divided into the following sections: TOE Definition, Evaluated package types and Further Definitions and Explanations. TOE Definition has the sub-sections Hardware Description, Software Description, Documentation, Interface of the TOE, Life Cycle and Delivery of the TOE, TOE Intended Usage, TOE User Environment as well as General IT features of the TOE. 2.1 TOE Definition The Target of Evaluation (TOE) is the smartcard integrated circuit named MF3ICD81 together with its Smartcard Embedded Software. The TOE is available for two different hardware version called t504c (relating to commercial type name MF3ICD81) and t507c (relating to commercial type name MF3ICDH81). The TOE is manufactured in an advanced CMOS process. The TOE includes IC Designer/Manufacturer proprietary IC Dedicated Test Software and IC Dedicated Support Software. The DESFire EV1 Embedded Software is also called Smartcard Embedded Software, according to the terminology used in [7]. Note that this Smartcard Embedded Software is part of the TOE. The following tables list the TOE components. Table 1. Components of the TOE (MF3ICD81) Type Name Release Date Form of delivery Hardware MIFARE DESFire EV1 MF3ICD81 Master t504c t504c.gds2 (26.11.2007) Wafer or modules (dice include reference t504c) Hardware MIFARE DESFire EV1 MF3ICD81 Via1 005 romt0cdf005.eco (15.07.2010) As part of wafer resp. modules (dice include reference 005 on via) Software Test ROM Software (the IC Dedicated Test Software) t504c005 23.06.2010 ROM on the chip (DF8_TestOS.hex) Software Boot ROM Software (the IC Dedicated Support Software) t504c005 23.06.2010 ROM on the chip (DF8_TestOS.hex) Software DESFire EV1 Embedded Software (the Smartcard Embedded Software) t504c005 15.07.2010 ROM on the chip (DesFire8.hex) Table 2. Components of the TOE (MF3ICDH81) Type Name Release Date Form of delivery Hardware MIFARE DESFire EV1 MF3ICDH81 Master t507c t507c.gds2 (21.07.2009) Wafer or modules (dice include reference t507c) Hardware MIFARE DESFire EV1 MF3ICDH81 Via1 003 romt0cyf003.eco, (19.07. 2010) As part of wafer resp. modules Evaluation Documentation Rev.1.5 10 May 2011 6 of 63

Type Name Release Date Form of delivery (dice include reference 003 on via) Software Test ROM Software (the IC Dedicated Test Software) t507c003 30.06.2010 ROM on the chip (DF8_TestOS.hex) Software Boot ROM Software (the IC Dedicated Support Software) t507c003 30.06.2010 ROM on the chip (DF8_TestOS.hex) Software DESFire EV1 Embedded Software (the Smartcard Embedded Software) t507c003 15.07.2010 ROM on the chip (DesFire8.hex) Table 3. Additional components of the TOE Type Name Release Date Form of delivery Document Document MIFARE DESFire EV1 MF3ICD81 Functional Specification [9] MIFARE DESFire EV1 MF3ICD81 Guidance, Delivery and Operation Manual [10] Electronic document Electronic document 2.1.1 Hardware Description The CPU of the MF3ICD81 has an 8-bit architecture with an instruction set that is based on the 8051 family instruction set. The on-chip hardware components are controlled by the Smartcard Embedded Software via Special Function Registers. These registers are correlated to the activities of the CPU, the memory management unit, interrupt control, contact-less communication, EEPROM, timers and the co-processors. The communication with the MF3ICD81 can be performed through the contact-less interface. The MF3ICD81 is equipped with an interrupt controller. These interrupts force the jump to specific fixed vector addresses in the ROM. Every different interrupt is controlled and guided by a specific part of the Smartcard Embedded Software. The device includes ROM (32 kbyte), RAM (512 Byte) and EEPROM (8 kbyte physical configurable for an available logical size of 0.5kB, 2kB, 4kB or 8kB) memory. The ROM is split in Application-ROM and Test-ROM. The Triple-DES co-processor supports single DES and Triple-DES operations. Only Triple-DES will be used in this evaluation, either in 2-key or 3-key operation. The AES coprocessor supports AES operations with a key length of 128 bits. The random generator provides true random numbers without pseudo random calculation. 2.1.2 Software Description The IC Dedicated Test Software (Test ROM Software) in the Test-ROM of the TOE is used by the TOE Manufacturer to test the functionality of the chip. The test functionality is disabled before the operational use of the smart card. The IC Dedicated Test Software includes the test operating system, test routines for the various blocks of the circuitry, Evaluation Documentation Rev.1.5 10 May 2011 7 of 63

control flags for the status of the EEPROM security row and shutdown functions to ensure that security relevant test operations cannot be executed illegally after phase 3. The TOE also contains IC Dedicated Support Software which is also stored in the Test- ROM. The IC Dedicated Support Software consists of the Boot ROM Software. This software is executed after each reset of the TOE, i.e. every time when the TOE starts. It sets up the TOE and does some basic configuration. The Smartcard Embedded Software provides the main functionality of the TOE in the usage phase. The MF3ICD81 is primarily designed for secure contact-less transport applications and related loyalty programs as well as access control systems. It fully complies with the requirements for fast and highly secure data transmission, flexible memory organisation and interoperability with existing infrastructure. Its functionality consists of: Flexible file system that can contain up to 28 applications with up to 32 files in each application. Support for different file types like values or data records. Mutual three pass authentication, also according to ISO 7816-4. Authentication on application level with fine-grained access conditions for files. Multi-application support that allows distributed management of applications and ensures application segregation. Data encryption for contact-less communication with replay attack protection. Transaction system with rollback that ensures consistency for complex transactions. Unique serial number for each device (UID) with optional random UID. The TOE features enable it to be used for a variety of applications: Electronic fare collection Stored value card systems Access control systems Loyalty If privacy is an issue, the TOE can be configured not to disclose any information to unauthorised users. 2.1.3 Documentation The Functional Specification [9] is also part of the TOE. It contains a functional description of the communication protocol and the commands implemented by the TOE. The provided documentation can be used by a customer to construct applications using the TOE. The Functional Specification is supported by the Application Note MIFARE DESFire EV1 MF3ICD81 Guidance, Delivery and Operation Manual [10] which gives additional guidance with regard to the secure usage of the TOE. 2.1.4 Interface of the TOE The electrical interface of the TOE are the pads to connect the RF antenna. The functional interface is defined by the commands implemented by the TOE and described in [9]. Evaluation Documentation Rev.1.5 10 May 2011 8 of 63

The chip surface can be seen as an interface of the TOE, too. This interface must be taken into account regarding environmental stress e.g. like temperature and in the case of an attack where the attacker e.g. manipulates the chip surface. 2.1.5 Life Cycle and Delivery of the TOE For the usage phase the MF3ICD81 chip will be implemented in a credit card sized plastic card (micro-module embedded into the plastic card) or another sealed package. The module and card embedding of the TOE provide external security mechanisms because they make it harder for an attacker to access parts of the TOE for physical manipulation. Regarding the Application Note 4 of [7] NXP will deliver the TOE at the end of phase 3 in form of wafers or at the end of phase 4 in packaged form. Regarding the Application Note 5 of [7] NXP will deliver the TOE with IC Dedicated Support Software and Smartcard Embedded Software, as described in this chapter. The TOE is able to control two different logical phases. After production of the chip every start-up will lead to the Test Mode and the execution of the IC Dedicated Test Software. At the end of the production test the Test Mode is disabled. With disabled Test Mode every start-up of the chip will lead to the Application Mode with the CPU executing the DESFire EV1 Embedded Software. 2.1.6 TOE Intended Usage Regarding to phase 7, the TOE is used by the end-user. The method of use of the product in this phase depends on the application. The TOE is intended to be used in an unsecured environment that does not avoid a threat. The device is developed for most high-end safeguarded applications, and is designed for embedding into contact-less smart cards according to ISO 14443 [13]. Usually the smart card is assigned to a single individual only although the smartcard may be expected to be used for multiple applications in a multi-provider environment. Therefore the TOE may store and process secrets of several systems that must be protected from each other. The secret data shall be used as input for the calculation of authentication data and the encryption of data. The system integrators such as the terminal software developer may use samples of the TOE during the development phases for their testing purposes. These samples do not differ from the TOE, they do not have any additional functionality used for testing. 2.1.7 TOE User Environment The TOE user environment is the environment from TOE Delivery to phase 7. At the phases up to 6, the TOE user environment must be a controlled environment. In the end-user environment (phase 7) Smartcard ICs are used in a wide range of applications to assure authorised conditional access. Examples of such are transportation or access control. The end-user environment therefore covers a wide spectrum of very different functions, thus making it difficult to avoid and monitor any abuse of the TOE. Note: The phases from TOE Delivery to phase 7 of the smart card life cycle are not part of the TOE construction process in the sense of this Security Evaluation Documentation Rev.1.5 10 May 2011 9 of 63

Target. Information about those phases are just included to describe how the TOE is used after its construction. Nevertheless the security features of the TOE cannot be disabled in these phases. 2.1.8 General IT features of the TOE The TOE IT functionality consists of: tamper resistant data storage control of operation conditions to provide correct operation in the specified range basic cryptographic functions (Triple-DES and AES co-processors) and physical random number generator as software support data communication via contact-less interface strong authentication mechanism to prevent unauthorised use access control to separate different applications and files different file types for data storage including stored values encryption of communication transaction mechanism for combining several operations in one atomic operation random UID to exacerbate tracing of end-users 2.2 Evaluated package types A number of package types are supported for the TOE. Each package type has a different commercial type name. The TOE will be available in four different packages and four different memory configurations. Additionally, there are two different hardware versions, t504c (relating to MF3ICD81) and t507c (relating to MF3ICDH81) which use either 17pF or 70pF input capacitance. The operating system is the same for all different configurations. The commercial type name is formed out of the following components: Evaluation Documentation Rev.1.5 10 May 2011 10 of 63

Table 4. Supported package types and memory configurations (MF3ICD81) Type Form Cap EE Package OS Description 81 41 21 UD 120µm sawn wafer, 8 kbytes EEPROM, 17pF cap. 120µm sawn wafer, 4 kbytes EEPROM, 17pF cap. 120µm sawn wafer, 2 kbytes EEPROM, 17pF cap. IC 01 81 120µm sawn wafer, 0.5 kbytes EEPROM, 17pF cap. 75µm sawn wafer, 8 kbytes EEPROM, 17pF cap. 41 21 UF 75µm sawn wafer, 4 kbytes EEPROM, 17pF cap. 75µm sawn wafer, 2 kbytes EEPROM, 17pF cap. MF3 D 01 81 01D /05 75µm sawn wafer, 0.5 kbytes EEPROM, 17pF cap. MOA4 module on reel, 8 kbytes EEPROM, 17pF cap. 41 21 A4 MOA4 module on reel, 4 kbytes EEPROM, 17pF cap. MOA4 module on reel, 2 kbytes EEPROM, 17pF cap. MO 01 81 MOA4 module on reel, 0.5 kbytes EEPROM, 17pF cap. MOA8 module on reel, 8 kbytes EEPROM, 17pF cap. 41 21 01 A8 MOA8 module on reel, 4 kbytes EEPROM, 17pF cap. MOA8 module on reel, 2 kbytes EEPROM, 17pF cap. MOA8 module on reel, 0.5 kbytes EEPROM, 17pF cap. Evaluation Documentation Rev.1.5 10 May 2011 11 of 63

Table 5. Supported package types and memory configurations (MF3ICDH81) Type Form Cap EE Package OS Description 81 41 21 UD 120µm sawn wafer, 8 kbytes EEPROM, 70pF cap. 120µm sawn wafer, 4 kbytes EEPROM, 70pF cap. 120µm sawn wafer, 2 kbytes EEPROM, 70pF cap. IC 01 81 120µm sawn wafer, 0.5 kbytes EEPROM, 70pF cap. 75µm sawn wafer, 8 kbytes EEPROM, 70pF cap. 41 21 UF 75µm sawn wafer, 4 kbytes EEPROM, 70pF cap. 75µm sawn wafer, 2 kbytes EEPROM, 70pF cap. MF3 DH 01 81 01D /05 75µm sawn wafer, 0.5 kbytes EEPROM, 70pF cap. MOA4 module on reel, 8 kbytes EEPROM, 70pF cap. 41 21 A4 MOA4 module on reel, 4 kbytes EEPROM, 70pF cap. MOA4 module on reel, 2 kbytes EEPROM, 70pF cap. MO 01 81 MOA4 module on reel, 0.5 kbytes EEPROM, 70pF cap. MOA8 module on reel, 8 kbytes EEPROM, 70pF cap. 41 21 01 A8 MOA8 module on reel, 4 kbytes EEPROM, 70pF cap. MOA8 module on reel, 2 kbytes EEPROM, 70pF cap. MOA8 module on reel, 0.5 kbytes EEPROM, 70pF cap. The DH reflects that the TOE uses the hardware version t507c. The D reflects that the TOE uses the hardware version t504c. For example, the commercial type name MF3ICDH4101DUD/05 denotes a DESFire EV1 supplied on 120µm thick wafer, with 4 K EEPROM and 70pF input capacitance. The commercial type name MF3MOD8101DA4/05 denotes a DESFire EV1 supplied in MOA4 modules on a reel, with 8K EEPROM and 17pF input capacitance. Evaluation Documentation Rev.1.5 10 May 2011 12 of 63

The package type does not influence the security functionality of the TOE. For all package types listed above the security during development and production is ensured (refer to section 1.2.2). All commercial types listed in the table above are subject of this evaluation. However only the identifier MF3ICD81 will be used in the rest of the document to make referencing easier. Unless described explicitly all information given in the remainder of the ST applies to all commercial types. 2.3 Further Definitions and Explanations Since the Security Target claims conformance to the PP Smartcard IC Platform Protection Profile, the concepts are used in the same sense. For the definition of terms refer to the Protection Profile [7]. This chapter does not need any supplement in the Security Target. Evaluation Documentation Rev.1.5 10 May 2011 13 of 63

3. TOE Security Environment This Security Target claims conformance to the Smartcard IC Platform Protection Profile. The Assets, Assumptions, Threats and Organisational Security Policies are completely taken from the Protection Profile. In the following only the extension of the different sections are listed. The titles of the sections that are not extended are cited here for completeness. 3.1 Description of Assets Since this Security Target claims conformance to the PP Smartcard IC Platform Protection Profile [7], the assets defined in section 3.1 of the Protection Profile are applied and the assets regarding threats are clarified in this Security Target. The assets regarding the threats are: logical design data, physical design data, IC Dedicated Software, Initialisation Data and Pre-personalisation Data, specific development aids, test and characterisation related data, material for software development support, and photomasks the TOE correct operation the Smartcard Embedded Software the special functions for the communication with an external interface device, the cryptographic co-processors for Triple-DES and AES, the random number generator the User Data comprising authentication data like keys issuer data like card holder name or processing options representation of monetary values, e.g. a stored value for transport applications the TSF Data. Regarding the Application Notes 6 and 7 of [7] this Security Target includes Smartcard Embedded Software and therefore does contain more assets compared to [7]. These assets are described above. 3.2 Assumptions Since this Security Target claims conformance to the PP Smartcard IC Platform Protection Profile [7], the assumptions defined in section 3.2 of the Protection Profile are valid for this Security Target. The following table lists the assumptions of the Protection Profile. Table 6. Name Assumptions defined in the Protection Profile Title A.Process-Card A.Plat-Appl A.Resp-Appl Protection during Packaging, Finishing and Personalisation Usage of Hardware Platform Treatment of User Data Evaluation Documentation Rev.1.5 10 May 2011 14 of 63

Note that the assumptions A.Plat-Appl and A.Resp-Appl defined in the Protection Profile address the development of the Smartcard Embedded Software. In this Security Target the Smartcard Embedded Software is part of the TOE, therefore the assumptions have to be met by the TOE and are no longer addressed to the operating environment of the TOE. A.Secure_Values Usage of secure values Only confidential and secure keys shall be used to set up the authentication and access rights. These values are generated outside the TOE and they are downloaded to the TOE. A.Terminal_Support Terminal support to ensure integrity and confidentiality The terminal verifies information sent by the TOE in order to ensure integrity and confidentiality of the communication. Regarding the Application Notes 8 and 9 of [7] this Security Target defines two additional assumptions regarding specific security functionality. 3.3 Threats Since this Security Target claims conformance to the PP Smartcard IC Platform Protection Profile [7], the threats defined in section 3.3 of the Protection Profile are valid for this Security Target. The following table lists the threats defined by the PP: Table 7. Name Threats defined by the Protection Profile Title T.Leak-Inherent T.Phys-Probing T.Malfunction T.Phys-Manipulation T.Leak-Forced T.Abuse-Func T.RND Inherent Information Leakage Physical Probing Malfunction due to Environmental Stress Physical Manipulation Forced Information Leakage Abuse of Functionality Deficiency of Random Numbers Considering the Application Notes 10 and 11 of [7] the following additional threats are defined in this Security Target: T.Data-Modification Unauthorised data modification User data stored by the TOE may be modified by unauthorised subjects. This threat applies to the processing of modification commands received by the TOE, it is not concerned with verification of authenticity. T.Impersonate Impersonating authorised users during authentication Evaluation Documentation Rev.1.5 10 May 2011 15 of 63

An unauthorised subject may try to impersonate an authorised subject during the authentication sequence, e.g. by a man-inthe middle or replay attack. T.Cloning Cloning 3.4 Organisational Security Policies User and TSF data stored on the TOE (including keys) may be read out by an unauthorised subject in order to create a duplicate. Since this Security Target claims conformance to the PP Smartcard IC Platform Protection Profile [7], the policy P.Process-TOE Protection during TOE Development and Production of the Protection Profile is applied here also. Regarding the Application Note 12 of [7] the following additional policies are defined in this Security Target: P.Confidentiality Confidentiality during communication The TOE shall provide the possibility to protect selected data elements from eavesdropping during contact-less communication. The TOE shall also provide the possibility to detect replay or man-in-the-middle attacks within a session. P.Transaction Transaction mechanism The TOE shall provide the possibility to combine a number of data modification operations in one transaction, so that either all operations or no operation at all is performed. P.No-Trace Un-traceability of end-users The TOE shall provide the ability that authorised subjects can prevent that end-user of TOE may be traced by unauthorised subjects without consent. Tracing of end-users may happen by performing a contact-less communication with the TOE when the end-user is not aware of it. Typically this involves retrieving the UID or any freely accessible data element. The following policies are part of this Security Target because the TOE implements Smartcard Embedded Software that addresses the assumptions A.Plat-Appl and A.Resp- Appl made in [7]. P.Plat-Appl Usage of hardware platform The Smartcard Embedded Software uses the TOE hardware platform according to the assumption A.Plat-Appl defined in [7]. P.Resp-Appl Treatment of user data The Smartcard Embedded Software treats user data according to the assumption A.Resp-Appl defined in [7]. Evaluation Documentation Rev.1.5 10 May 2011 16 of 63

4. Security Objectives This chapter contains the following sections: Security Objectives for the TOE and Security Objectives for the Environment. 4.1 Security Objectives for the TOE The TOE shall provide the following security objectives, taken from the Protection Profile Smartcard IC Platform Protection Profile [7]: Table 8. Name Security objectives defined in the PP Title O.Leak-Inherent O.Phys-Probing O.Malfunction O.Phys-Manipulation O.Leak-Forced O.Abuse-Func O.Identification O.RND Protection against Inherent Information Leakage Protection against Physical Probing Protection against Malfunctions Protection against Physical Manipulation Protection against Forced Information Leakage Protection against Abuse of Functionality TOE Identification Random Numbers Regarding the Application Notes 13 and 14 of [7] the following additional security objectives are defined based on additional functionality provided by the TOE as specified below. O.Access-Control Access Control The TOE must provide an access control mechanism for data stored by it. The access control mechanism shall apply to read, modify, create and delete operations for data elements and to reading and modifying security attributes as well as authentication data. It shall be possible to limit the right to perform a specific operation to a specific user. The security attributes (keys) used for authentication shall never be output. O.Authentication Authentication The TOE must provide an authentication mechanism in order to be able to authenticate authorised users. The authentication mechanism shall be resistant against replay and man-in-themiddle attacks. O.Confidentiality Confidential Communication The TOE must be able to protect the communication by encryption. This shall be implemented by security attributes that enforce encrypted communication for the respective data element. The TOE shall also provide the possibility to detect Evaluation Documentation Rev.1.5 10 May 2011 17 of 63

replay or man-in-the-middle attacks within a session. This shall be implemented by checking verification data sent by the terminal and providing verification data to the terminal. O.Type-Consistency Data type consistency The TOE must provide a consistent handling of the different supported data types. This comprises over- and underflow checking for values, for data file sizes and record handling. O.Transaction Transaction mechanism The TOE must be able to provide a transaction mechanism that allows to update multiple data elements either all in common or none of them. O.No-Trace Preventing Traceability The TOE must be able to prevent that the TOE end-user can be traced. This shall be done by providing an option that disables the transfer of any information that is suitable for tracing an end-user by an unauthorised subject. Note that the following two objectives are identical to the objectives OE.Plat-Appl and OE.Resp-Appl defined in [7]. O.Plat-Appl Usage of hardware platform To ensure that the TOE is used in a secure manner the Smartcard Embedded Software shall be designed so that the requirements from the following documents are met: (i) hardware data sheet for the TOE, (ii) TOE application notes, and (iii) findings of the TOE evaluation reports relevant for the Smartcard Embedded Software. O.Resp-Appl Treatment of user data 4.2 Security Objectives for the Environment Security relevant User Data (especially cryptographic keys) are treated by the Smartcard Embedded Software as required by the security needs of the specific application context. For example the Smartcard Embedded Software will not disclose security relevant user data to unauthorised users or processes when communicating with a terminal. According to the Protection Profile [7], the following security objectives for the environment are specified: Table 9. Security objectives for the environment, taken from the PP Security objective Description Applies to phase... OE.Plat-Appl Usage of Hardware Platform Phase 1 Evaluation Documentation Rev.1.5 10 May 2011 18 of 63

Security objective Description Applies to phase... OE.Resp-Appl Treatment of User Data Phase 1 OE.Process-TOE OE.Process-Card Protection during TOE Development and Production Protection during Packaging, Finishing and Personalisation Phase 2 up to the TOE Delivery at the end of phase 3 Begin of phase 4 up to the end of phase 6 Note that the objective OE.Plat-Appl of the Protection Profile is replaced by O.Plat-Appl in this Security Target. In the same way OE.Resp-Appl is replaced by O.Resp-Appl. OE.Secure_Values Generation of secure values The environment shall generate confidential and secure keys for authentication purpose. These values are generated outside the TOE and they are downloaded to the TOE during the personalisation or usage in phase 5 to 7 OE.Terminal_Support Terminal support to ensure integrity and confidentiality The terminal shall verify information sent by the TOE in order to ensure integrity and confidentiality of the communication. This involves checking of MAC values, verification of redundancy information according to the cryptographic protocol and secure closing of the communication session. Evaluation Documentation Rev.1.5 10 May 2011 19 of 63

5. IT Security Requirements 5.1 TOE Security Requirements This section consists of the subsections TOE Security Functional Requirements, TOE Security Assurance Requirements and Refinements of the TOE Security Assurance Requirements. 5.1.1 TOE Security Functional Requirements To support a better understanding of the combination Protection Profile vs. Security Target, the TOE SFRs are presented in the following two different sections. 5.1.1.1 SFRs of the Protection Profile Table 10 below shows all SFRs which are specified in the Protection Profile Smartcard IC Platform Protection Profile [7] (in the order of definition in the PP). Some of the SFRs are CC Part 2 extended and defined in the Protection Profile. This is shown in the third column of the table. Table 10. SFRs taken from the PP SFR Title Defined in... FAU_SAS.1 Audit storage PP, Section 8.6 FCS_RND.1 Quality metric for random numbers PP, Section 8.4 FDP_IFC.1 Subset information flow control CC, Part 2 FDP_ITT.1 Basic internal transfer protection CC, Part 2 FMT_LIM.1 Limited capabilities PP, Section 8.5 FMT_LIM.2 Limited availability PP, Section 8.5 FPT_FLS.1 Failure with preservation of secure state CC, Part 2 FPT_ITT.1 Basic internal TSF data transfer protection CC, Part 2 FPT_PHP.3 Resistance to physical attack CC, Part 2 FPT_SEP.1 TSF domain separation CC, Part 2 FRU_FLT.2 Limited fault tolerance CC, Part 2 With one exception, all assignment and selection operations are performed. The exception is the left open definition of a quality metric for the random numbers required by FCS_RND.1. This assignment operation is filled in by the following statement: FCS_RND.1 FCS_RND.1.1 Dependencies: Quality metric for random numbers The TSF shall provide a mechanism to generate random numbers that meet the requirement to provide an entropy of at least 7.976 bit in each byte 1. No dependencies. 1 [assignment: a defined quality metric] Evaluation Documentation Rev.1.5 10 May 2011 20 of 63

Note: The entropy of the random number is measured by the Shannon-Entropy as follows: 255 E p i log 2 p i, where p i is the probability that the i 0 ( 7, b6,, b0 byte b ) is equal to i as binary number. Here term bit means measure of the Shannon-Entropy. The value 7.976 is assigned due to the requirements of AIS31, [5]. By this, all assignment/selection operations are performed. This Security Target does not perform any other/further operations than stated in the Protection Profile. Considering the Application Note 15 of [7] in the following paragraphs several SFRs that are not required in the Protection Profile are defined. Regarding the Application Note 16 of [7] an additional generation of audit is not defined for Limited fault tolerance (FRU_FLT.2) and Failure with preservation of secure state (FPT_FLS.1). Considering the Application Note 17 of [7] no additional requirement is defined for the TOE itself. 5.1.1.2 Additional SFRs regarding access control Access Control Policy The Security Function Policy (SFP) Access Control Policy uses the following definitions: The subjects are The Administrator i.e. the subject that owns or has access to the card master key. The Application Manager i.e. the subject that owns or has access to an application master key. Note that the TOE supports multiple applications and therefore multiple Application Managers, however for one application there is only one Application Manager. The Application User i.e. the subject that owns or has access to a key that allows to perform operations with application objects. Note that the TOE supports multiple Application Users within each application and the assigned rights to the Application Users can be different, which allows to have more or less powerful Application Users. Any other subject belongs to the role Everybody. This includes the card holder (i.e. end-user) and any other subject e.g. an attacker. These subjects do not possess any key and can not perform operations that are restricted to the Administrator, Application Manager and Application User. The term Nobody will be used to explicitly indicate that no rights are granted to any subject. The objects are The Card itself. The card can store a number of Applications. An application can store a number of Data Files of different types. Evaluation Documentation Rev.1.5 10 May 2011 21 of 63

One specific type of data file are Values. Note that data files and values can be grouped in standard files and backup files, with values belonging to the group of backup files. When the term file is used without further information then both data files and values are meant. The operations that can be performed with the objects are read a value or data from a data file, write data to a data file, increase a value (with a limit or unlimited), decrease a value, create an application, a value or a data file, delete an application, a value or a data file and modify attribute of the card, an application, a value or a data file. Note that freeze will be used as specific form of modification that prevents any further modify. The security attributes are Attributes of the card, applications, values and data files. There is a set of attributes for the card, a set of attributes for every application and a set of attributes for every single file within an application. The term card attributes will be used for the set of attributes related to the card, the term application attributes will be used for the set of application attributes and the term file attributes will be used for the attributes of values and data files. Note that subjects are authorised by cryptographic keys. These keys are considered as authentication data and not as security attributes. The card has a card master key. Every application has an application master key and a variable number of keys used for operations on data files or values (all these keys are called application keys). The application keys within an application are numbered. The TOE shall meet the requirements Security roles (FMT_SMR.1) as specified below. FMT_SMR.1 Hierarchical to: FMT_SMR.1.1 FMT_SMR.1.2 Dependencies: Note: Security roles No other components. The TSF shall maintain the roles Administrator, Application Manager, Application User and Everybody 2. The TSF shall be able to associate users with roles. FIA_UID.1 Timing of identification Based on the definition Nobody is not considered as role. The TOE shall meet the requirements Subset access control (FDP_ACC.1) as specified below. FDP_ACC.1 Hierarchical to: Subset access control No other components. 2 [assignment: the authorised identified roles] Evaluation Documentation Rev.1.5 10 May 2011 22 of 63

FDP_ACC.1.1 Dependencies: The TSF shall enforce the Access Control Policy 3 on all subjects, objects, operations and attributes defined by the Access Control Policy 4. FDP_ACF.1 Security attribute based access control The TOE shall meet the requirement Security attribute based access control (FDP_ACF.1) as specified below. FDP_ACF.1 Hierarchical to: FDP_ACF.1.1 FDP_ACF.1.2 FDP_ACF.1.3 FDP_ACF.1.4 Security attribute based access control No other components. The TSF shall enforce the Access Control Policy 5 to objects based on the following: all subjects, objects and attributes 6. The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: The Administrator can create and delete applications. The Application Manager of an application can delete this application, create data file and values within this application, delete data files and values within this application. An Application User can read or write a data file; read, increase or decrease a value based on the access control settings in the respective file attribute. 7 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: Everybody can create applications if this is allowed by a specific card attribute. Everybody can create and delete data files or values of a specific application if this is allowed by a specific application attribute. Everybody can read or write a data file; read, increase or decrease a value if this is allowed by a specific file attribute. 8 The TSF shall explicitly deny access of subjects to objects based on the rules: 3 4 5 6 7 8 [assignment: access control SFP] [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] [assignment: access control SFP] [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFPrelevant security attributes, or named groups of SFP-relevant security attributes] [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Evaluation Documentation Rev.1.5 10 May 2011 23 of 63

Nobody can read or write a data file; read, increase or decrease a value if this is explicitly set for the respective operation on the respective data file or value. 9 Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation The TOE shall meet the requirement Static attribute initialisation (FMT_MSA.3) as specified below. FMT_MSA.3 Hierarchical to: FMT_MSA.3.1 FMT_MSA.3.2 Dependencies: Application Note: Static attribute initialisation No other components. The TSF shall enforce the Access Control Policy 10 to provide permissive 11 default values for security attributes that are used to enforce the SFP. The TSF shall allow no subject 12 to specify alternative initial values to override the default values when an object or information is created. FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles The only initial attributes are the card attributes. All other attributes have to be defined at the same time the respective object is created. The TOE shall meet the requirement Management of security attributes (FMT_MSA.1) as specified below. FMT_MSA.1 Hierarchical to: FMT_MSA.1.1 Dependencies: Management of security attributes No other components. The TSF shall enforce the Access Control Policy 13 to restrict the ability to modify or freeze 14 the security attributes card attributes, application attributes and file attributes 15 to the Administrator, Application Manager and Application User, respectively 16. [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions 9 10 11 12 13 14 15 16 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] [assignment: access control SFP, information flow control SFP] [selection, choose one of: restrictive, permissive, [assignment: other property]] [assignment: the authorised identified roles] [assignment: access control SFP, information flow control SFP] [selection: change_default, query, modify, delete, [assignment: other operations]] [assignment: list of security attributes] [assignment: the authorised identified roles] Evaluation Documentation Rev.1.5 10 May 2011 24 of 63

Refinement: The detailed management abilities are: The Administrator can modify the card attributes. The card attributes contain a flag that when set will prevent any further change of the card attributes, thereby allowing to freeze the card attributes. The Application Manager can modify the application attributes. The application attributes contain a flag that when set will prevent any further change of the application attributes, thereby allowing to freeze the application attributes. The Application Manager can decide to restrict the ability to modify the file attributes to the Application Manager, an Application User, Everybody or to Nobody. The restriction to Nobody is equivalent to freezing the file attributes. As an implication of the last rule, any subject that receives the modify abilities from the Application Manger gets these abilities transferred. The implication given in the previous rule includes the possibility for an Application User to modify the file attributes if the Application Manager decides to transfer this ability. If there is no such explicit transfer an Application User does not have the ability to modify the file attributes. The TOE shall meet the requirement Specification of Management Functions (FMT_SMF.1) as specified below. FMT_SMF.1 Hierarchical to: FMT_SMF.1.1 Specification of Management Functions No other components. The TSF shall be capable of performing the following security management functions: Authenticate a user, Invalidating the current authentication state based on the functions: Selecting an application or the card, Changing a key, Occurrence of any error during the execution of a command, Reset; Changing a security attribute, Creating or deleting an application, a value or a data file. 17 Dependencies: No dependencies The TOE shall meet the requirement Import of user data with security attributes (FDP_ITC.2) as specified below. FDP_ITC.2 Hierarchical to: Import of user data with security attributes No other components. 17 [assignment: list of security management functions to be provided by the TSF] Evaluation Documentation Rev.1.5 10 May 2011 25 of 63

FDP_ITC.2.1 FDP_ITC.2.2 FDP_ITC.2.3 FDP_ITC.2.4 FDP_ITC.2.5 Dependencies: The TSF shall enforce the Access Control Policy 18 when importing user data, controlled under the SFP, from outside of the TSC. The TSF shall use the security attributes associated with the imported user data. The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TSC: no additional rules 19. [FDP_ACC.1 Subset access control, or FDP_IFC.1Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FPT_TDC.1 Inter-TSF basic TSF data consistency The TOE shall meet the requirement Inter-TSF basic TSF data consistency (FPT_TDC.1) as specified below. FPT_TDC.1 Hierarchical to: FPT_TDC.1.1 FPT_TDC.1.2 Dependencies: Application Note: Inter-TSF basic TSF data consistency No other components. The TSF shall provide the capability to consistently interpret data files and values 20 when shared between the TSF and another trusted IT product. The TSF shall use the rule: data files or values can only be modified by their dedicated type-specific operations honouring the type-specific boundaries 21 when interpreting the TSF data from another trusted IT product. No dependencies. The TOE does not interpret the contents of the data, e.g. it can not determine if data stored in a specific data file is an identification number that adheres to a specific format. Instead the TOE distinguishes different types of files and ensures that type-specific boundaries can not be violated, e.g. values do not overflow, single records are limited by their size and cyclic records are handled correctly. 18 19 20 21 [assignment: access control SFP and/or information flow control SFP] [assignment: additional importation control rules] [assignment: list of TSF data types] [assignment: list of interpretation rules to be applied by the TSF] Evaluation Documentation Rev.1.5 10 May 2011 26 of 63

Implications of the Access Control Policy The Access Control Policy has some implications, that can be drawn from the policy and that are essential parts of the TOE security functions. The TOE end-user does normally not belong to the group of authorised users (Administrator, Application Manager, Application User), but regarded as Everybody by the TOE. This means that the TOE cannot determine if it is used by its intended end-user (in other words: it cannot determine if the current card holder is the owner of the card). The Administrator can have the exclusive right to create and delete applications on the Smart Card, however he can also grant this privilege to Everybody. Additionally, changing the Smart Card attributes is reserved for the Administrator. Application keys, at delivery time should be personalized to a preliminary, temporary key only known to the Administrator and the Application Manager. At application personalization time, the Application Manager uses the preliminary application key in order to personalize the application keys, whereas all keys, except the application master key, can be personalized to a preliminary, temporary key only known to the Application Manager and the Application User. Furthermore, the Application Manager has the right to create files within his application scope. 5.1.1.3 Additional SFRs regarding confidentiality and authentication The (DES co-processor of the) TOE shall meet the requirement Cryptographic operation (FCS_COP.1[DES]) as specified below. FCS_COP.1[DES] Hierarchical to: FCS_COP.1.1 Cryptographic operation No other components. The TSF shall perform encryption and decryption 22 in accordance with a specified cryptographic algorithm Triple Data Encryption Algorithm (TDEA) 23 and cryptographic key sizes of 112 or 168 bit 24 that meet the following list of standards 25 : FIPS PUB 46-3 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION DATA ENCRYPTION STANDARD (DES) Reaffirmed 1999 October 25, keying options 1 and 2. Dependencies: Note: [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 Cryptographic key destruction, FMT_MSA.2 Secure security attributes. The cryptographic functionality FCS_COP.1[DES] provided by the TOE achieves a security level of maximum 80 Bits, if keying option 2 is used. 22 23 24 25 [assignment: list of cryptographic operations] [assignment: cryptographic algorithm] [assignment: cryptographic key sizes] [assignment: list of standards] Evaluation Documentation Rev.1.5 10 May 2011 27 of 63