NXP Secure Smart Card Controller P6021y VB Security Target Lite Rev. 1.51 — 19 July 2016 Evaluation document BSI-DSZ-CC-0955-V2 PUBLIC Document information Information Content Keywords CC Security Evaluation, Security Target Lite, Functional Requirements, Security Functionality, Assurance Level 5+/6+, P6021y VB, P6021P VB, P6021M VB, P6021D VB, P6021J VB Abstract Security Target Lite of the NXP Secure Smart Card Controller P6021y VB, which is developed and provided by NXP Semiconductors according to the Common Criteria for Information Technology Security Evaluation Version 3.1 at Evaluation Assurance Level 6 augmented for P6021P VB and at Evaluation Assurance Level 5 augmented for P6021M VB / P6021D VB / P6021J VB. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 2 / 129 Revision history Revision number Date Description 1.51 19.07.2016 Derived from P6021y VB Security Target v1.51 NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 3 / 129 1 ST Introduction This chapter is divided into the following sections: "ST Reference", "TOE Reference", "TOE Overview" and "TOE Description". 1.1 ST Reference “NXP Secure Smart Card Controller P6021y VB, Security Target Lite, NXP Semiconductors, Rev. 1.51, 19 July 2016”. 1.2 TOE Reference The TOE is named "NXP Secure Smart Card Controller P6021y VB including IC Dedicated Software". In this document the TOE is abbreviated to NXP Secure Smart Card Controller P6021y VB. 1.3 TOE Overview 1.3.1 Configuration of the TOE The TOE is configurable to P6021P VB which includes IC Dedicated Software, configurable to P6021M VB which includes IC Dedicated Software with MIFARE Plus MF1PLUSx0, configurable to P6021D VB which includes IC Dedicated Software with MIFARE DESFire EV1, or configurable to P6021J VB which includes IC Dedicated Software with both MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1. 1.3.2 Usage and major security functionality of the P6021P VB The P6021P VB is composed of the IC hardware platform of NXP Secure Smart Card Controller P6021P VB, the IC Dedicated Software, and the documentation describing the Instruction Set and the usage. The P6021P VB is delivered with a customer specific Security IC Embedded Software. The IC hardware platform of NXP Secure Smart Card Controller P6021P VB is a microcontroller incorporating a central processing unit, memories accessible via a Memory Management Unit, cryptographic coprocessors, other security components and two communication interfaces. The central processing unit supports a 32-/24-/16-/8-bit instruction set optimized for smart card applications, which is a super set of the 80C51 family instruction set. The first and in some cases the second byte of an instruction are used for operation encoding. On-chip memories are ROM, RAM and EEPROM. The non- volatile EEPROM can be used as data or program memory. It consists of high reliable memory cells, which guarantee data integrity. The EEPROM is optimized for applications requiring reliable non-volatile data storage for data and program code. Dedicated security functionality protects the contents of all memories. The IC Dedicated Software for NXP Secure Smart Card Controller P6021P VB comprises IC Dedicated Test Software for test purposes and IC Dedicated Support Software. The IC Dedicated Support Software consists of Boot-ROM Software which controls the boot process of the hardware platform and Plain Firmware Operating System (FOS-Plain) which can be called by the Security IC Embedded Software. The FOS-Plain provides an interface for programming of the internal EEPROM memory, which is mandatory for use by the Security IC Embedded Software when programming the EEPROM memory. Also, the FOS-Plain provides an interface for the Post Delivery Configuration functionality. The documentation includes a Product Data Sheet, an Instruction Set, a Guidance and Operation Manual, a Wafer and delivery specification and a Firmware Interface Specification Product data sheet addendum. This documentation comprises a description NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 4 / 129 of the architecture, the secure configuration and usage of the IC hardware platform and the IC Dedicated Software by the Security IC Embedded Software. The security functionality of the P6021P VB is designed to act as an integral part of a complete security system in order to strengthen the design as a whole. Several security mechanisms are completely implemented in and controlled by the P6021P VB. Other security mechanisms allow for configuration or even require handling of exceptions by the Security IC Embedded Software. The different CPU modes and the Memory Management Unit support the implementation of multi-application projects using the P6021P VB. A Security IC must provide high security in particular when being used in the banking and finance market, in electronic commerce or in governmental applications because the P6021P VB is intended to be used in a potential insecure environment. Hence the P6021P VB shall maintain • the integrity and the confidentiality of code and data stored in its memories, • the different CPU modes with the related capabilities for configuration and memory access and • the integrity, the correct operation and the confidentiality of security functionality provided by the P6021P VB. This is ensured by the construction of the P6021P VB and its security functionality. NXP Secure Smart Card Controller P6021P VB basically provides a hardware platform for an implementation of a smart card application with • functionality to calculate the Data Encryption Standard (Triple-DES) with up to three keys, • functionality to calculate the Advanced Encryption Standard (AES) with different key lengths, • support for large integer arithmetic operations like multiplication, addition and logical operations, which are suitable for public key cryptography (e.g. RSA or ECC), • a True Random Number Generator, • memory management control, • cyclic redundancy check (CRC) calculation, • ISO/IEC 7816 contact interface with UART, and • ISO/IEC 14443 A contactless interface supporting. In addition, several security mechanisms are implemented to ensure proper operation as well as integrity and confidentiality of stored data. For example, this includes security mechanisms for memory protection and security exceptions as well as sensors, which allow operation under specified conditions only. Memory encryption is used for memory protection and chip shielding is added to the chip. Note: Large integer arithmetic operations are intended to be used for calculation of asymmetric cryptographic algorithms. Any asymmetric cryptographic algorithm utilizing the support for large integer arithmetic operations has to be implemented in the Security IC Embedded Software. Thus, the support for large integer arithmetic operations itself does not provide security functionality like cryptographic support. The Security IC Embedded Software implementing an asymmetric cryptographic algorithm is not included in this evaluation. Nevertheless the support for large integer arithmetic operations is part of the Security IC and therefore a security relevant component of the P6021P VB, that must resist to the attacks mentioned in this Security Target and that must operate correctly as specified in the data sheet. The same scope of evaluation is applied to the CRC calculation. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 5 / 129 1.3.3 Usage and major security functionality of the P6021M VB/P6021D VB/ P6021J VB The P6021M VB/P6021D VB/P6021J VB is composed of the IC hardware platform of NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB, the IC Dedicated Software, and the documentation describing the Instruction Set and the usage. The P6021M VB/P6021D VB/P6021J VB is delivered with a customer specific Security IC Embedded Software. The IC hardware platform of NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB is identical to the IC hardware platform of NXP Secure Smart Card Controller P6021P VB. The IC Dedicated Software for NXP Secure Smart Card Controller P6021M VB/ P6021D VB/P6021J VB comprises IC Dedicated Test Software for test purposes and IC Dedicated Support Software. The IC Dedicated Support Software consists of Boot-ROM Software which controls the boot process of the hardware platform and Emulation Firmware Operating System (FOS-Emu) which can be called by the Security IC Embedded Software. The FOS-Emu provides an interface for programming of the internal EEPROM memory, which is mandatory for use by the Security IC Embedded Software when programming the EEPROM memory. Also, the FOS-Emu provides an interface for the Post Delivery Configuration functionality. In addition to P6021P VB, NXP Secure Smart Card Controller P6021M VB/P6021D VB/ P6021J VB includes Emulation MIFARE Plus MF1PLUSx0 or MIFARE DESFire EV1 or both MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1 in the FOS-Emu and is, therefore, part of the TOE. Note that MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1 are represented by the term MIFARE Software in this document. The MIFARE Software provides a set of functions used to manage the data stored in the non-volatile EEPROM memory owned by MIFARE Software respectively. Note that the Firmware Operating System (FOS) for the hardware platform is called the Plain Firmware Operating System (FOS-Plain) and the Firmware Operating System for the MIFARE Software Emulation is called the Emulation Firmware Operating System (FOS-Emu). NXP has developed MIFARE Software to be used with Proximity Coupling Devices (PCDs) according to ISO14443 Type A. The communication protocol complies to part ISO 14443-3 and 14443-4. MIFARE Software is primarily designed for secure contact-less transport applications and related loyalty programs as well as access management systems. It fully complies with the requirements for fast and highly secure data transmission, flexible data storage and interoperability with existing infrastructures. The TOE with MIFARE Plus MF1PLUSx0 supports the virtual card architecture by providing a selection mechanism for virtual cards. This allows using the TOE with MIFARE Plus MF1PLUSx0 in a complex environment where multiple virtual cards are stored in one physical object, however the TOE with MIFARE Plus MF1PLUSx0 does support only one virtual card. The TOE with MIFARE DESFire EV1 does not support the virtual card architecture. The documentation includes a Product Data Sheet, an Instruction Set, a Guidance and Operation Manual, a Wafer and delivery specification and a Firmware Interface Specification Product data sheet addendum. For the TOE with MIFARE Software, the documentation additionally includes a Functionality of implementation of MIFARE Software and a Guidance, Delivery and Operation Manual of MIFARE Software. This documentation comprises a description of the architecture, the secure configuration and usage of the IC hardware platform and the IC Dedicated Software by the Security IC Embedded Software. The security functionality of the P6021M VB/P6021D VB/P6021J VB is designed to act as an integral part of a complete security system in order to strengthen the design as a whole. Several security mechanisms are completely implemented in and controlled by the P6021M VB/P6021D VB/P6021J VB. Other security mechanisms allow for NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 6 / 129 configuration or even require handling of exceptions by the Security IC Embedded Software. The different CPU modes and the Memory Management Unit support the implementation of multi-application projects using the P6021M VB/P6021D VB/P6021J VB. A Security IC must provide high security in particular when being used in the banking and finance market, in electronic commerce or in governmental applications because the P6021M VB/P6021D VB/P6021J VB is intended to be used in a potential insecure environment. Hence the P6021M VB/P6021D VB/P6021J VB shall maintain • the integrity and the confidentiality of code and data stored in its memories, • the different CPU modes with the related capabilities for configuration and memory access and • the integrity, the correct operation and the confidentiality of security functionality provided by the P6021M VB/P6021D VB/P6021J VB. This is ensured by the construction of the P6021M VB/P6021D VB/P6021J VB and its security functionality. The P6021M VB/P6021D VB/P6021J VB basically provides a hardware platform for an implementation of a smart card application with • functionality to calculate the Data Encryption Standard (Triple-DES) with up to three keys, • functionality to calculate the Advanced Encryption Standard (AES) with different key lengths, • support for large integer arithmetic operations like multiplication, addition and logical operations, which are suitable for public key cryptography (e.g. RSA or ECC), • a True Random Number Generator, • memory management control, • cyclic redundancy check (CRC) calculation, • ISO/IEC 7816 contact interface with UART, • ISO/IEC 14443 A contactless interface supporting, and • for the TOE with MIFARE Software, contactless interface supporting MIFARE Software. In addition, several security mechanisms are implemented to ensure proper operation as well as integrity and confidentiality of stored data. For example, this includes security mechanisms for memory protection and security exceptions as well as sensors, which allow operation under specified conditions only. Memory encryption is used for memory protection and chip shielding is added to the chip. Note: Large integer arithmetic operations are intended to be used for calculation of asymmetric cryptographic algorithms. Any asymmetric cryptographic algorithm utilizing the support for large integer arithmetic operations has to be implemented in the Security IC Embedded Software. Thus, the support for large integer arithmetic operations itself does not provide security functionality like cryptographic support. The Security IC Embedded Software implementing an asymmetric cryptographic algorithm is not included in this evaluation. Nevertheless the support for large integer arithmetic operations is part of the Security IC and therefore a security relevant component of the P6021M VB/P6021D VB/P6021J VB, that must resist to the attacks mentioned in this Security Target and that must operate correctly as specified in the data sheet. The same scope of evaluation is applied to the CRC calculation. 1.3.4 TOE Type The TOE NXP Secure Smart Card Controller P6021y VB is provided as IC hardware platform for various operating systems and applications with high security requirements. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 7 / 129 1.3.5 Required non-TOE hardware/software/firmware None 1.4 TOE Description 1.4.1 Physical Scope of TOE 1.4.1.1 NXP Secure Smart Card Controller P6021P VB NXP Secure Smart Card Controller P6021P VB is manufactured in an advanced 90nm CMOS technology (85nm using optical shrink). The block diagram of the IC hardware platform of P6021y VB is depicted in Fig. 1. Figure 1. Block Diagram of NXP Secure Smart Card Controller P6021y VB The P6021P VB contains the IC hardware platform and the IC Dedicated Software which is composed of IC Dedicated Test Software and IC Dedicated Support Software. All other software is called Security IC Embedded Software. The Security IC Embedded Software is not part of the P6021P VB. This Security Target claims conformance to the assurance package EAL6 augmented for the P6021P VB. Please refer Section 2.2 for details. 1.4.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB is manufactured in an advanced 90nm CMOS technology (85nm using optical shrink). The block diagram of the IC hardware platform of P6021M VB/P6021D VB/P6021J VB is depicted in Fig. 1. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 8 / 129 The P6021M VB/P6021D VB/P6021J VB contains the IC hardware platform (see Fig. 1) and the IC Dedicated Software which is composed of IC Dedicated Test Software and IC Dedicated Support Software including MIFARE Software. All other software is called Security IC Embedded Software. The Security IC Embedded Software is not part of the P6021M VB/P6021D VB/P6021J VB. This Security Target claims conformance to the assurance package EAL5 augmented for the P6021M VB/P6021D VB/P6021J VB. Please refer Section 2.2 for details. 1.4.1.3 TOE Components The TOE components of NXP Secure Smart Card Controller P6021y VB are composed of the IC hardware platform (see Fig. 1), the IC Dedicated Software, and the documentation. The IC Dedicated Software consists of a IC Dedicated Test Software and IC Dedicated Support Software. The IC Dedicated Test Software contains the Test-ROM Software, and the IC Dedicated Support Software contains the Boot-ROM Software and the Firmware Operating System. The version of the Firmware Operating System as part of the IC Dedicated Support Software can be read-out by Security IC Embedded Software using FVEC interface as specified in [16], Section 2.1.9 Emulation Control Interface (FVEC0). 1.4.1.3.1 NXP Secure Smart Card Controller P6021P VB The TOE components of NXP Secure Smart Card Controller P6021P VB are listed in Table 1. Table 1. TOE Components for P6021P VB Type Name Release Date Form of delivery IC Hardware NXP Secure Smart Card Controller P6021P VB VB 19 February 2015 wafer, module, inlay, package (dice have nameplate 9071C) Security IC Dedicated Test Software Test-ROM Software 10.1D 25 April 2015 Test-ROM on the chip acc. to 9071C_LB010_TESTROM_v1 _btos_10v1D_fos_Cv21.hex (0C.21 / 0C.22) / 9071C_BB027_ TESTROM_v1_btos_10v1D_ fos_Cv6.hex (0C.60) Boot-ROM Software 10.1D 25 April 2015 Boot-ROM on the chip acc. to 9071C_LB010_TESTROM_v1 _btos_10v1D_fos_Cv21.hex (0C.21 / 0C.22) / 9071C_BB027_ TESTROM_v1_btos_10v1D_ fos_Cv6.hex (0C.60) Security IC Dedicated Support Software Plain Firmware Operating System (FOS-Plain) 0C.21 / 0C.22 / 0C.60 [1] June 2015 / January 2016 / April 2016 Firmware Operating System on the chip acc. to 9071C_LB010_ TESTROM_v1_btos_10v1D_ fos_Cv21.hex (0C.21 / 0C.22) / 9071C_BB027_TESTROM_v1 _btos_10v1D_fos_Cv6.hex (0C.60) Document Product Data Sheet SmartMX2 family P6021y VB, Secure high-performance smart card controller, NXP Semiconductors Electronic Document NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 9 / 129 Type Name Release Date Form of delivery Document Instruction Set for the SmartMX2 family, Secure smart card controller, NXP Semiconductors, Document Number 1478** Electronic Document Document Information on Guidance and Operation, NXP Secure Smart Card Controller P6021y VB, NXP Semiconductors Electronic Document Document Product data sheet addendum - SmartMX2 P6021y VB, Wafer and delivery specification, NXP Semiconductors, Document Number 3222** Electronic Document Document Product Data Sheet Addendum - SmartMX2P602xy VB family, Firmware Interface Specification, NXP Semiconductors, Document Number 2997** Electronic Document Document Firmware Interface Specification Addendum - SmartMX2P602xy VB family, Firmware Interface Specification Addendum, NXP Semiconductors, Document Number 3741** Electronic Document [1] Note that FW0C.60 does not support MIFARE Plus Security Level 2 since that part is not included in FW0C.60. 1.4.1.3.2 NXP Secure Smart Card Controller P6021M VB The P6021M VB includes the TOE components of P6021P VB which are listed in Table 1, and the additional components for MIFARE Plus MF1PLUSx0 which are listed in Table 2. Table 2. Additional TOE components for P6021M VB Type Name Release Date Form of delivery Security IC Dedicated Support Software Emulation Firmware Operating System (FOS-Emu) with MIFARE Plus MF1PLUSx0 configuration 0C.21 / 0C.22 / 0C.60 [1] June 2015 / January 2016 / April 2016 Firmware Operating System on the chip acc. to 9071C_LB010_ TESTROM_v1_btos_10v1D_ fos_Cv21.hex (0C.21 / 0C.22) / 9071C_BB027_TESTROM_v1 _btos_10v1D_fos_Cv6.hex (0C.60) Document Product Data Sheet - MIFARE Plus Functionality of implementations on smart card controllers, NXP Semiconductors, Document Number 2062** Electronic Document Document MIFARE Plus MF1PLUSx0 Guidance and Operation Manual, NXP Secure Smart Card Controller P602xy, NXP Semiconductors, Document Number 2335** Electronic Document [1] Note that FW0C.60 does not support MIFARE Plus Security Level 2 since that part is not included in FW0C.60. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 10 / 129 1.4.1.3.3 NXP Secure Smart Card Controller P6021D VB The P6021D VB includes the TOE components of P6021P VB which are listed in Table 1, and the additional components for MIFARE DESFire EV1 which are listed in Table 3. Table 3. Additional TOE components for P6021D VB Type Name Release Date Form of delivery Security IC Dedicated Support Software Emulation Firmware Operating System (FOS-Emu) with MIFARE DESFire EV1 configuration 0C.21 / 0C.22 / 0C.60 [1] June 2015 / January 2016 / April 2016 Firmware Operating System on the chip acc. to 9071C_LB010_ TESTROM_v1_btos_10v1D_ fos_Cv21.hex (0C.21 / 0C.22) / 9071C_BB027_TESTROM_v1 _btos_10v1D_fos_Cv6.hex (0C.60) Document Product Data Sheet - MIFARE DESFire EV1 Functionality of implementations on smart card controllers, NXP Semiconductors, Document Number 2258** Electronic Document Document MIFARE DESFire EV1 Guidance and Operation Manual, NXP Secure Smart Card Controller P602xy, NXP Semiconductors, Document Number 2400** Electronic Document [1] Note that FW0C.60 does not support MIFARE Plus Security Level 2 since that part is not included in FW0C.60. 1.4.1.3.4 NXP Secure Smart Card Controller P6021J VB The P6021J VB includes the TOE components of P6021P VB which are listed in Table 1, the additional TOE components of P6021M VB which are listed in Table 2, and the additional TOE components of P6021D VB which are listed in Table 3. 1.4.2 Evaluated configurations The NXP Secure Smart Card Controller P6021y VB can be delivered with various configuration options as described in this section. The configuration options are divided into two groups; major configuration options and minor configuration options. 1.4.2.1 Major configuration options The major configuration options of NXP Secure Smart Card Controller P6021y VB are described in this section. 1.4.2.1.1 NXP Secure Smart Card Controller P6021P VB The major configuration P6021P VB is equipped with the ISO/IEC 7816 contact interface only, or both the ISO/IEC 7816 contact interface and the ISO/IEC 14443 contactless interface. The major configuration P6021P VB is provided with several minor configuration options, which are introduced in Section 1.4.2.2.1. Major configuration P6021P VB also provides customers with several options for reconfiguration (Post Delivery Configuration), which are described in Section 1.4.2.3.1 in detail. The major configuration P6021P VB can be selected via Order Entry Form [13] by selecting value "P: Plain version, no emulation (default)" of "MIFARE TM implementations Convergence Selection" option. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 11 / 129 1.4.2.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The TOE with the IC Dedicated Software containing MIFARE Plus MF1PLUSx0 is named P6021M VB. The TOE P6021y VB with the IC Dedicated Software containing MIFARE DESFire EV1 is named P6021D VB. The TOE with the IC Dedicated Software containing both MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1 is named P6021J VB. The major configuration options of the P6021M VB/P6021D VB/P6021J VB include the major configuration options of the P6021P VB, and, in addition, the following major configuration options. All of the major configurations P6021M VB/P6021D VB/P6021J VB are equipped with both the ISO/IEC 7816 contact interface and the ISO/IEC 14443 contactless interface. 512 Bytes are reserved for Security Rows and configuration data of the manufacturer, 1024 Bytes are reserved for IC Dedicated Support Software control data and, depending on the minor configuration, several bytes are reserved for MIFARE Software depending on the EEPROM size of MIFARE Software. The major configurations of NXP Secure Smart Card Controller P6021M VB/P6021D VB/ P6021J VB must be selected via Order Entry Form [13] by selecting value “M: MIFARE Plus implementation”, “D: DESFire EV1 implementation” or “J: ("joint") DESFire EV1 and MIFARE Plus implementation” of “MIFARE TM implementations Convergence Selection” option. 1.4.2.2 Minor configuration options The minor configuration options of NXP Secure Smart Card Controller P6021y VB are described in this section. 1.4.2.2.1 NXP Secure Smart Card Controller P6021P VB The minor configuration options for NXP Secure Smart Card Controller P6021P VB can be selected by the customer via Order Entry Form [13]. The Order Entry Form identifies the minor configuration options, which are supported by a major configuration out of those introduced in Section 1.4.2.1.1. The evaluated minor configuration options for NXP Secure Smart Card Controller P6021P VB are listed in Table 4. Table 4. Evaluated minor configuration options for NXP Secure Smart Card Controller P6021P VB Name Value Description EEPROM Memory Size • 80K EEPROM memory • 40K EEPROM memory • xx EEPROM memory - where xx is a value in the range [12K - 80K] and xx is a multiple of 4K Defines the EEPROM memory size. Interface Selection • D: Dual Interface • C: Contact Interface Selection of both the ISO/IEC 7816 contact interface and the ISO/IEC 14443 contactless interface, or the ISO/IEC 7816 contact interface only (only available on the major configuration P6021P VB) Post Delivery Configuration (PDC) enabled • YES • NO Reconfiguration during card personalization enabled or not. Contactless Communication Parameters • ATQ0 Value • ATQ1 Value • SAK Value • TA Value Defines contactless communication protocol parameters. (not available on the major configuration P6021P VB with contact interface) NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 12 / 129 Name Value Description ROM read instructions executed from EEPROM allowed • YES • NO Instructions executed from EEPROM are allowed or not to read ROM contents. ROM read instructions by Copy Machine allowed • YES • NO Read access by Copy Machine to ROM is allowed or not. EEPROM read instructions by Copy Machine allowed • YES • NO Read access by Copy Machine to EEPROM is allowed or not. Code execution from RAM allowed • YES • NO Code execution from RAM allowed or not. Activation of 'Card Disable' feature allowed • YES • NO When the 'Card Disable' feature is allowed, the TOE can be locked completely. Once set by the Security IC Embedded Software, execution of the Security IC Embedded Software is inhibited after the next reset. EEPROM application content erase allowed • YES • NO Erase of application content of EEPROM allowed or not. EDATASCALE specification • EDATA size will be EDATASCALE * 16 bytes This value determines the size of the memory area available for the extended stack pointer. Default is 10h. Inverse EEPROM Error Correction Attack Detection activated • YES • NO If inverse error correction is activated the detection probability of fault injections to the EEPROM can be increased. Access to additional general purpose I/O pads TP1 and TP2 allowed in System Mode • YES • NO Additionally 2 general purpose I/O pads (TP1/TP2) can be accessed by the application OS. Selection of reset value for UART CRC algorithm • ISO13239/ HDLC • de facto PC/SC Selection of CRC algorithm for ISO7816 enhanced protocol support. Start-up with low CPU clock enabled • YES • NO Start-Up with low CPU clock to enable specific low power applications. If this option is enabled the ISO start-up timing is not met. RunMode enabled (select 'no' for ISO/IEC 7816 compliance) • YES • NO Special start-up behavior in order to support a start-up with: • RST_N pad forced to LOW or not connected • CLK pad forced HIGH or not connected Allow simultaneous operation of ISO 7816 and ISO 14443 applications • YES • NO Disables the Low Frequency Sensor to allow parallel operation via contact and contactless interfaces. The Low Frequency Sensor is disabled only when the CPU is free- running or runs at an internal clock. (not available on the major configuration P6021P VB with contact interface) Chip Health mode enabled • YES • NO Activation of read-out of IC identification items and start of built-in self test and ident routines is enabled or not. L_A/L_B input capacitance configuration • about 17pF (low cap.) for class 1 ("ID1") antennas (default) • about 69pF (high cap.) for class 2 ('half ID1') antenna • about 56pF (mid. cap.) for either – class 1 or – class 2 (= only 106 kbit/s supported) antennas Additional capacitance between L_A/L_B required meeting resonance frequency at ID1/2 operation. (not available on the major configuration P6021P VB with contact interface) NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 13 / 129 Name Value Description UID options • double UID, seven bytes • single FNUID, four bytes UID selection between single FNUID (four bytes, using the non-unique and revolving xFh range of ISO/IEC 14443) and double UID contactless communication protocol • proprietary protocol with bit anticollision • T=CL protocol with bit anticollision Selection of contactless communication protocol between proprietary protocol with bit anticollision (compliant to ISO/ IEC 14443 part 3) and T=CL protocol with bit anticollision (compliant to ISO/IEC 14443 part 3 and 4) PUF enabled • YES (default) • NO PUF functionality is enabled or not. Firmware Version • 0C.21 • 0C.22 • 0C.60 [1] Depending on the Firmware version of the development kit used for the submitted ROM .hex-file, different Firmware versions of the TOE have to be selected. Note that the option "0C.21" maps to FW version 0C.41 on the development kit,the option "0C.22" maps to FW version 0C.42 and the option "0C.60" maps to firmware version 0C.80 on the development kit. Convergence Implementation Selection • P: Plain version, no emulation No usage of emulation [1] Note that FW0C.60 does not support MIFARE Plus Security Level 2 since that part is not included in FW0C.60. See the Data Sheet [9] for details on all minor configuration options listed in Table 4. The availability of minor configuration options partly depends on the selected major configuration option. However in general the minor configuration options can be chosen independently. 1.4.2.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The minor configuration options for NXP Secure Smart Card Controller P6021M VB/ P6021D VB/P6021J VB can be selected by the customer via Order Entry Form [13]. The Order Entry Form identifies the minor configuration options, which are supported by a major configuration out of those introduced in Section 1.4.2.1. 1.4.2.2.2.1 NXP Secure Smart Card Controller P6021M VB The P6021M VB includes the minor configuration options of P6021P VB which are listed in Table 4, and the additional minor configuration options for MIFARE Plus MF1PLUSx0 which are listed in Table 5. Table 5. Additional evaluated minor configuration options for P6021M VB Name Value Description Convergence Implementation Selection • M: MIFARE Plus Implementation Defines the usage of MIFARE Plus MF1PLUSx0 OS emulation only. MIFARE Plus implementation subselection specify nominal user memory for MIFARE Plus implementation • MIFARE Plus 2K (MP2) • MIFARE Plus 4K (MP4) • MIFARE Classic 1K (MC1) [1] • MIFARE Classic 4K (MC4) [1] • MIFARE Plus/ Classic functionality disabled Defines the EEPROM size of MIFARE Plus MF1PLUSx0. MIFARE Plus MF1PLUSx0 in security level 1 is also referred to as MIFARE Classic (MCx). It can be selected in two different EEPROM size configurations 1k Bytes (MC1) and 4k Bytes (MC4). These configurations do not implement any Security Functional Requirement of MIFARE Plus MF1PLUSx0 and are not in the scope of the evaluation. They do not interfere with the security functionality provided by the IC hardware platform. Note that configuration 'MIFARE Plus/Classic functionality disabled' does not contain MIFARE Plus MF1PLUSx0. In this configuration MIFARE Plus MF1PLUSx0 is disabled permanently. The protocol strength of MIFARE Classic is not intended to guarantee protection of data assets. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 14 / 129 Name Value Description MIFARE Plus implementation subselection: Specify - in case of above MC1 or MC4 selection - the MIFARE Classic Sector Trailer Initialization compliance • MIFARE Classic MF1S50/70 (default) • SmartMX P5 family MIFARE Classic [1] The configurations MC1 and MC4 are limited to MIFARE classic functionality in Security Level 1 (see Section 1.4.3.2). These configurations are fixed to Security Level 1. MC1 and MC4 do not implement any Security Functional Requirement for MIFARE Plus MF1PLUSx0 and the functionality provided by the IC Dedicated Software when configured to MC1 and MC4 is not part of the evaluation (see Table 5). 1.4.2.2.2.2 NXP Secure Smart Card Controller P6021D VB The P6021D VB includes the minor configuration options of P6021P VB which are listed in Table 4, and the additional minor configuration options for MIFARE DESFire EV1 which are listed in Table 6. Table 6. Additional evaluated minor configuration options for P6021D Name Value Description Convergence Implementation Selection • D: DESFire EV1 implementation Defines the usage of MIFARE DESFire EV1 OS emulation only. MIFARE DESFire EV1/ Joint implementation subselection specify nominal user memory for DESFire implementation • 2 K (D2) • 4 K (D4) • 8 K (D8) • 16 K (D16) • 24 K (D24) • 32 K (D32) • MIFARE DESFire EV1 functionality disabled permanently Defines the EEPROM size of MIFARE DESFire EV1. 1.4.2.2.2.3 NXP Secure Smart Card Controller P6021J VB The P6021J VB includes the minor configuration options of P6021P VB which are listed in Table 4, the additional minor configuration options for MIFARE Plus MF1PLUSx0 which are listed in Table 5, and the additional minor configuration options for MIFARE DESFire EV1 which are listed in Table 6, except for the minor configuration option "Convergence Implementation Selection". The following table shows the minor configuration option "Convergence Implementation Selection" for the P6021J VB. Table 7. Additional evaluated minor configuration options for P6021J VB Name Value Description Convergence Implementation Selection • J: DESFire EV1 and MIFARE plus implementation Defines the usage of MIFARE DESFire EV1 and MIFARE Plus MF1PLUSx0 OS emulation 1.4.2.3 Post Delivery Configuration The Post Delivery Configuration (PDC) of NXP Secure Smart Card Controller P6021y VB can be applied by the customer himself after the TOE has been delivered to that customer. These options can be used to tailor the TOE to the specific customer requirements. The Post Delivery Configuration can be changed multiple times via the firmware vector (FVEC0.15) but must be set permanently by the customer before the TOE is delivered to phase 7 of the Security IC product life-cycle. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 15 / 129 1.4.2.3.1 NXP Secure Smart Card Controller P6021P VB The Post Delivery Configuration for P6021P VB is listed in Table 8. Table 8. Hardware Post Delivery Configuration for P6021P VB Name Value Description EEPROM size range 12 KBytes - 80 KBytes This value determines the maximum size of the EEPROM in steps of 4KBytes. CXRAM size range 128 Byte - 6.5 KBytes This value determines the maximum size of the CXRAM in steps of 128 Byte. FXRAM size range 32 Byte - 2.625 KBytes This value determines the maximum size of the FXRAM in steps of 32 Byte. Fame2 coprocessor Enabled or Disabled This value determines whether the Fame2 coprocessor is enabled or disabled. Default value is enabled. AES Enabled or Disabled [1] This value determines whether the AES coprocessor is enabled or disabled. Default value is enabled. Contactless Interface Enabled or Disabled This value determines whether the Contactless interface is enabled or not. Default value is enabled. [1] Without AES functionality, both MIFARE Plus and DESFire in whole are not accessible and the PUF functionality is not accessible. By applying the Post Delivery Configuration, the Security Rows content is updated for the changed configuration options and can, therefore, be used for identification of the P6021P VB after applying any Post Delivery Configuration. Further details regarding Security Rows content and identification of the P6021P VB after applying the Post Delivery Configuration, refer to [9]. The Post Delivery Configuration can be accessed using the FVEC interface (FVEC 0.15). 1.4.2.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The Post Delivery Configuration of the P6021M VB/P6021D VB/P6021J VB can be grouped into two different types: • Hardware Post Delivery Configuration: Options for EEPROM Size, CXRAM Size, Fame2 coprocessor, AES and Contactless Interface. • MIFARE Post Delivery Configuration: – Options for MIFARE Plus MF1PLUSx0: MIFARE Plus MF1PLUSx0 EEPROM Size, MIFARE Plus MF1PLUSx0 parameters and Enable MIFARE Plus MF1PLUSx0. – Options for MIFARE DESFire EV1: MIFARE DESFire EV1 EEPROM Size and Enable MIFARE DESFire EV1. For Hardware Post Delivery Configuration, please refer to the Post Delivery Configuration of P6021P VB described in Section 1.4.2.3.1. MIFARE Post Delivery Configuration can be changed only once via the firmware vector (FVEC 0.15) but must be set before the P6021M VB/P6021D VB/P6021J VB is delivered to phase 7 of the Security IC product life-cycle otherwise the IC Dedicated Support Software acts as if MIFARE Software is disabled. By applying MIFARE Post Delivery Configuration the EEPROM managed by the IC Dedicated Support Software is changed. FVEC interface for MIFARE Post Delivery Configuration is split into a GET and SET operation. While the SET operation can only be executed once, the GET operation can be executed multiple times. GET operation can also be used in phase 7 of the Security IC product life-cycle for identification of NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 16 / 129 the P6021M VB/P6021D VB/P6021J VB after applying the MIFARE Post Delivery Configuration. Further details regarding the FVEC and identification of the P6021M VB/ P6021D VB/P6021J VB after applying MIFARE Post Delivery Configuration refer to [9]. MIFARE Post Delivery Configuration can be accessed using the FVEC interface (FVEC0.15). This means that MIFARE Post Delivery Configuration must be done by the Security IC Embedded Software before phase 7 of the Security IC product life-cycle. 1.4.2.3.2.1 NXP Secure Smart Card Controller P6021M VB The Post Delivery Configuration options for P6021M include the Post Delivery Configuration options for P6021P VB which are listed in Table 8, and the additional Post Delivery Configuration options for MIFARE Plus MF1PLUSx0 which are listed in Table 9. Table 9. MIFARE Post Delivery Configuration for P6021M Name Value Description Enable MIFARE Plus MF1PLUSx0 Enabled or Disabled This value determines MIFARE Plus MF1PLUSx0 emulation is activated or not. MIFARE Plus MF1PLUSx0 EEPROM size 2 KBytes and 4 KBytes This value determines the size of the EEPROM image of MIFARE Plus MF1PLUSx0. The selected MIFARE Plus MF1PLUSx0 EEPROM size minor configuration option can only be downsized to 2 KBytes or 4 KBytes. 1.4.2.3.2.2 NXP Secure Smart Card Controller P6021D VB The Post Delivery Configuration options for P6021D include the Post Delivery Configuration options for P6021P VB which are listed in Table 8, and the additional Post Delivery Configuration options for MIFARE DESFire EV1 which are listed in Table 10. Table 10. MIFARE Post Delivery Configuration for P6021D Name Value Description Enable MIFARE DESFire EV1 Enabled or Disabled This value determines MIFARE DESFire EV1 emulation is activated or not. MIFARE DESFire EV1 EEPROM size 2 KBytes, 4 KBytes, 8 KBytes, 16 KBytes, 24 KBytes and 32 KBytes This value determines the size of the EEPROM image of MIFARE DESFire EV1. The selected MIFARE DESFire EV1 EEPROM size minor configuration option can only be downsized to 2 KBytes, 4 KBytes, 8 KBytes, 16 KBytes, 24 KBytes or 32 KBytes. 1.4.2.3.2.3 NXP Secure Smart Card Controller P6021J VB The Post Delivery Configuration options for P6021J include the Post Delivery Configuration options for P6021P VB which are listed in Table 8, the additional Post Delivery Configuration options for MIFARE Plus MF1PLUSx0 which are listed in Table 9, and the additional Post Delivery Configuration options for MIFARE DESFire EV1 which are listed in Table 10. 1.4.2.4 Evaluated package types 1.4.2.4.1 NXP Secure Smart Card Controller P6021P VB A number of package types are supported for each major configuration of the P6021P VB. The commercial types are named according to the following format. • P60xeeeypp(p)/9Brrff(o) for all allowed configurations of EEPROM size range NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 17 / 129 The commercial type name of each major configuration varies with the interface type (either C or D configuration) as indicated by the variable x, and EEPROM size range as indicated by the variable eee, and with the package type as indicated by the variable pp, and with the Security IC Embedded Software as indicated by the variables rr and ff. Variables y and o identify the activation of the firmware emulations MIFARE Plus and MIFARE DESFire which are not part of the evaluation of the P6021P VB. The number 9 is used as Fab identifier and B references to the silicon Version also available at major configuration naming as VB. The variables are replaced according to the rules in Table 11. Table 11. Variable definitions for commercial type names Variable Definition Interface and feature configuration identifier, as currently defined, e.g.: x=C: Asymmetric and symmetric cryptography implemented, ISO/IEC 7816 contact interface x x=D: Asymmetric and symmetric cryptography implemented, ISO/IEC 7816 contact + ISO/ IEC14443 contactless interface Indication of the Non-Volatile memory size in KB eee = 081: For example: 80 KByte EEPROM implemented. eee This “eee” figure may be increased by “+1”, “+2” or “+3” in case of a different family member with same Non-Volatile memory size. See the Data Sheet [9] for details on all Non-Volatile memory size configuration. Emulation Configuration identifier y y = P: no Emulation implemented pp(p) Package delivery type (alpha numeric, last character optional), e.g. 'A4' for MOB4 module. rr ROM code number, which identifies the ROM mask. ff FabKey number, which identifies the EEPROM content at TOE delivery. (o) Size of EEPROM area for firmware emulation, e.g. '2' 2 KByte MIFARE Plus Emulation, optional for Dual Interface Types. In case no firmware emulation is activated for a commercial type this character is left blank. For a detailed description of the package type names please refer to [12]. Table 12 depicts the package types, which are supported in this Security Target, and assigns these to the major configurations. The two characters in each entry of the table stand for the variable pp, and identify the package type. An empty cell means that the Security Target does not support the respective package type for the corresponding major configuration. Table 12. Supported Package Types P60DeeeP P60CeeeP Description [1] Ux Ux Wafer not thinner than 50 μm (The string “x” in “Ux” stands for a single capital letter or an identifier which determines the released wafer treatment variation: e.g. UA, U15, U75) Xx Xx Module (Contact, Contactless, Dual Interface) (The string “x” in” Xx” stands for a single capital letter or an identifier which determines the released package variation: e.g. XA, X21, XQ6) An MOB Module (Contactless) (The number "n" in "An" stands for a number which identifies the released package type: e.g. A4, A6, A10) Ax Inlay (Contactless) (The string "x" in "Ax" stands for a single capital letter or an identifier which determines both, the inlay type and the package type inside the inlay: e.g. AC, A2F) NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 18 / 129 P60DeeeP P60CeeeP Description [1] HN HVQFN32 SMD package [1] Package type descriptions consist of in total 2 or (optionally) 3 digits: a preceding main type letter (e.g. U, X, A) and an identifier which could consist of number(s) and letter(s). For example, commercial type name P60D081PX0/9Brrff denotes major configuration P6021P VB with 80 KB EEPROM size, supporting PDM1.1 dual interface smart card module. The characters `rr' and `ff' are individual for each customer product. The package types do not influence the security functionality of the P6021P VB. They only define which pads are connected in the package and for what purpose and in which environment the chip can be used. Note that the security of the P6021P VB is not dependent on which pad is connected or not - the connections just define how the product can be used. If the P6021P VB is delivered as wafer the customer can choose the connections on his own. Security during development and production is ensured for all package types listed above, for details refer to Section 1.4.4. The commercial type name identifies major configuration and package type of the P6021P VB as well as the Security IC Embedded Software. However, the commercial type name does not itemize the minor configuration options of the P6021P VB, which are introduced in Section 1.4.2.2.1. Instead, minor configuration options are identified in the Order Entry Form, which is assigned to the ROM code number and the FabKey number of the commercial type name. Minor configuration options as well as configuration options changed by means of Hardware Post Delivery Configuration are coded in the Security Rows and can be read out for identification of the P6021P VB. Further details regarding Security Rows content and identification of the P6021P VB after applying Hardware Post Delivery Configuration, please refer to [9]. 1.4.2.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB A number of package types are supported for each major configuration of the P6021M VB/P6021D VB/P6021J VB. The commercial types are named according to the following format. • P60Deeeypp(p)/9Brrff(o) for all allowed configurations of EEPROM size range The commercial type name of each major configuration varies with EEPROM size range as indicated by the variable eee, with the package type as indicated by the variable pp and with the Security IC Embedded Software as indicated by the variables rr and ff. Variable y is a placeholder for either 'M', 'D' and 'J'. 'M' identifies the availability of MIFARE Plus MF1PLUSx0, 'D' identifies the availability of MIFARE DESFire EV1 and 'J' identifies the availability of MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1. Variable o identifies the EEPROM size of MIFARE Software. The number 9 is used as Fab identifier and B references to the silicon Version also available at major configuration naming as VB. The variables are replaced according to the rules in Table 13. Table 13. Variable definitions for commercial type names Variable Definition Indication of the Non-Volatile memory size in KB eee eee = 081: For example: 80 KByte EEPROM implemented. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 19 / 129 Variable Definition This “eee” figure may be increased by “+1”, “+2” or “+3” in case of a different family member with same Non-Volatile memory size. See the Data Sheet [9] for details on all Non-Volatile memory size configuration. Emulation Configuration identifier y = M: MIFARE Plus (optional choice of MIFARE Classic) implementation y = D: MIFARE DESFire EV1 implementation y y = J: MIFARE Plus and MIFARE DESFire EV1 implementation pp(p) Package delivery type (alpha numeric, last character optional), e.g. 'A4' for MOB4 module. rr ROM code number, which identifies the ROM mask. ff FabKey number, which identifies the EEPROM content at TOE delivery. (o) Size of EEPROM area for MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1, e.g. ‘2’ 2 KBytes EEPROM size (MIFARE Plus MF1PLUSx0 or MIFARE DESFire EV1). For joint the first number represents the EEPROM size for MIFARE Plus MF1PLUSx0 or MIFARE Classic and the second number the EEPROM size for MIFARE DESFire EV1. For a detailed description of the package type names please refer to [12]. Table 14 depicts the package types, which are supported in this Security Target, and assigns these to the major configurations. The two characters in each entry of the table stand for the variable pp, and identify the package type. An empty cell means that the Security Target does not support the respective package type for the corresponding major configuration. Table 14. Supported Package Types P60DeeeP Description [1] Ux Wafer not thinner than 50 μm (The string “x” in “Ux” stands for a single capital letter or an identifier which determines the released wafer treatment variation: e.g. UA, U15, U75) Xx Module (Contact, Contactless, Dual Interface) (The string “x” in” Xx” stands for a single capital letter or an identifier which determines the released package variation: e.g. XA, X21, XQ6) An MOB Module (Contactless) (The number "n" in "An" stands for a number which identifies the released package type: e.g. A4, A6, A10) Ax Inlay (Contactless) (The string "x" in "Ax" stands for a single capital letter or an identifier which determines both, the inlay type and the package type inside the inlay: e.g. AC, A2F) [1] Package type descriptions consist of in total 2 or (optionally) 3 digits: a preceding main type letter (e.g. U, X, A) and an identifier which could consist of number(s) and letter(s). For example, commercial type name P60D081MX0/9Brrff2 denotes major configuration P6021M VB with MIFARE Plus MF1PLUSx0 and 84 KB EEPROM size, supporting 2 KBytes of EEPROM for firmware emulation and PDM1.1 dual interface smart card module. The characters `rr' and `ff' are individual for each customer product. The package types do not influence the security functionality of the P6021M VB/P6021D VB/P6021J VB. They only define which pads are connected in the package and for what purpose and in which environment the chip can be used. Note that the security of the P6021M VB/P6021D VB/P6021J VB is not dependent on which pad is connected or not - the connections just define how the product can be used. If the P6021M VB/P6021D VB/ P6021J VB is delivered as wafer the customer can choose the connections on his own. Security during development and production is ensured for all package types listed above, for details refer to Section 1.4.4. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 20 / 129 The commercial type name identifies major configuration and package type of the P6021M VB/P6021D VB/P6021J VB as well as the Security IC Embedded Software. However, the commercial type name does not itemize the minor configuration options of the P6021M VB/P6021D VB/P6021J VB, which are introduced in Section 1.4.2.2. Instead, minor configuration options are identified in the Order Entry Form, which is assigned to the ROM code number and the FabKey number of the commercial type name. Minor configuration options as well as configuration options changed by means of Hardware Post Delivery Configuration are coded in the Security Rows and can be read out for identification of the P6021M VB/P6021D VB/P6021J VB. Further details regarding Security Rows content and identification of the P6021M VB/P6021D VB/P6021J VB after applying Hardware Post Delivery Configuration, please refer to [9]. Minor configuration options changed by means of MIFARE Post Delivery Configuration can be read out for identification of the P6021M VB/P6021D VB/P6021J VB by the Security IC Embedded Software using the GET operation of FVEC0.15. Further details regarding FVEC0.15 and identification of the P6021M VB/P6021D VB/P6021J VB after applying MIFARE Post Delivery Configuration, please refer to [9]. 1.4.3 Logical Scope of TOE 1.4.3.1 Hardware description The CPU of the TOE NXP Secure Smart Card Controller P6021y VB supports a 32-/24-/16-/8-bit instruction set and distinguishes five CPU modes, which are summarized in Table 15. Table 15. CPU modes of the TOE Super System Mode System Mode User Mode Boot Mode Test Mode Firmware Mode System Mode User Mode Boot Mode, Test Mode and Firmware Mode are sub-modes of the so-called Super System Mode. These three modes are not available to the Security IC Embedded Software; they are reserved for the IC Dedicated Software. The IC Dedicated Software is composed of IC Dedicated Test Software and IC Dedicated Support Software (Boot- ROM Software and Firmware Operating System) as introduced in Section 1.4.1.1. The three software components are mapped one-to-one to the three CPU modes: In Boot Mode the TOE executes the Boot-ROM Software, in Test Mode the TOE executes the IC Dedicated Test Software and in Firmware Mode the TOE executes the Firmware Operating System. Please note that the Super System Mode is not a mode on its own: When the TOE is in Super System Mode, it is always either in Boot Mode, Test Mode or Firmware Mode. The TOE is able to control two different logical phases. After production of the Security IC every start-up or reset completes with Test Mode and execution of the IC Dedicated Test Software. The Test Mode is disabled at the end of the production test. Afterwards, every start-up or reset ends up in System Mode and execution of the Security IC Embedded Software. In case the minor configuration option 'Post Delivery Configuration' is enabled and not finally locked by the customer, the resource configuration functionality allows the customer to enable or disable specific functionality of the hardware platform. Please refer to Table 8 for details. In case the minor configuration option 'Chip Health/Ident Mode' is enabled, during the boot process routines either starting built-in self tests checking the functional integrity of the TOE or sending back identification items of the TOE can be activated by the user. System Mode and User Mode are available to the developer of the Security IC Embedded Software. System Mode has unlimited access to the hardware components NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 21 / 129 available to the Security IC Embedded Software. User Mode has restricted access to the CPU, specific Special Function Registers and the memories depending on the access rights granted by software running in System Mode. The hardware components are controlled by the Security IC Embedded Software via Special Function Registers. Special Function Registers are interrelated to the activities of the CPU, the Memory Management Unit, interrupt control, I/O configuration, EEPROM, timers, UART, the contactless interface and the coprocessors. The TOE provides two types of interrupts: (i) exception interrupts, called 'exception' in the following and (ii) event interrupts, called 'interrupts' in the following. Exceptions and interrupts each force a jump to a specific fixed vector address in the ROM. Any exception and interrupt can therefore be controlled and guided by a specific part of the Security IC Embedded Software. In addition, the TOE provides eight firmware vectors (FVEC) and 32 system call vectors (SVEC). These vectors have to be explicitly called by the Security IC Embedded Software. A jump to a firmware vector forces Firmware Mode and starts execution of the Firmware Operating System, a jump to a system call vector forces System Mode. The Watchdog timer is intended to abort irregular program executions by a time-out mechanism and is enabled and configured by the Security IC Embedded Software. Table 16. System Resources of P6021M VB/P6021D VB/P6021J VB Application RAM Major Configuration Application- ROM [kBytes] Test-ROM [kBytes] CXRAM [Bytes] FXRAM [Bytes] FOS-RAM [Bytes] EEPROM [kBytes] P6021P VB 384 128 6656 2688 576 range from 12 to 80 P6021M VB/ P6021D VB/ P6021J VB 384 128 6656 2688 576 range from 12 to 80 The TOE incorporates memory types ROM, RAM and EEPROM (see Table 16 for memory sizes). Access control to all three memory types is enforced by a Memory Management Unit. The Memory Management Unit partitions each memory into two parts: • ROM is partitioned in Application-ROM and Test-ROM (see Table 16). Application- ROM is reserved for the Security IC Embedded Software and Test-ROM reserved for the IC Dedicated Software. The Security IC Dedicated Support Software located in ROM always includes the full MIFARE functionality. Depending on selected major configuration option dedicated MIFARE functionality is deactivated. Note that the ROM size is displayed as Application-ROM size in the block diagram in Fig. 1 because only Application-ROM is available to the Security IC Embedded Software, • RAM is partitioned in Application-RAM, and FOS-RAM (see Table 16). Application- RAM is reserved for the Security IC Embedded Software, and FOS-RAM for the Firmware Operating System part of the IC Dedicated Support Software, • EEPROM is partitioned into the available EEPROM for the Security IC Embedded Software and the remaining part: – 512 Bytes of the EEPROM are always reserved for the manufacturer area, – 1024 Bytes of the EEPROM are always reserved for IC Dedicated Support Software for FOS control data, – 768 Bytes of the EEPROM are reserved for the PUF block, – remaining part of the EEPROM is reserved for MIFARE Software part of the IC Dedicated Support Software depending on the major configuration option. Furthermore the IC Dedicated Support Software contains functionality for programming the user EEPROM which must be called by the Security IC Embedded Software. Therefore the IC Dedicated Support Software has access also to the EEPROM area which is allocated to the Security IC Embedded Software, the separation between user data and NXP firmware data is guaranteed by means of a firewall. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 22 / 129 In Test Mode the CPU has unrestricted access to all memories. In Boot Mode and Firmware Mode access is limited to the Test-ROM, the manufacturer area of the EEPROM, FOS control data in EEPROM and the EEPROM space owned by MIFARE Software as well as the configured part of FOS-RAM. All other parts of the memories are accessible in System Mode and User Mode, namely the Application-ROM, Application- RAM and the larger parts of EEPROM. User Mode is further restricted by the Memory Management Unit, which can be configured in System Mode. Application-RAM is further split in two parts. These are general purpose RAM (CXRAM) and FXRAM (associated to the Fame2 coprocessor). Please refer to Table 16 for further details about the size of CXRAM. Both parts are accessible to the CPU, but the Fame2 coprocessor can only access the FXRAM. The Fame2 coprocessor can access the FXRAM without control of access rights by the Memory Management Unit. Since the Memory Management Unit does not control accesses of the Fame2 coprocessor, software which has access to the Fame2 coprocessor implicitly has access to the FXRAM. The Triple-DES coprocessor supports single DES and Triple-DES operations. Only Triple-DES is in the scope of this evaluation, in 2-key or 3-key operation with two/three 56-bit keys (112-/168-bit). The AES coprocessor supports AES operation with three different key lengths of 128, 192 or 256 bit. The Fame2 coprocessor supplies basic arithmetic functions to support implementation of asymmetric cryptographic algorithms by the Security IC Embedded Software. The random number generator provides true random numbers without pseudo random calculation. The CRC coprocessor provides CRC generation polynomial CRC-16 and CRC-32. The copy machine supports a mechanism to transfer data between specific Special Function Registers as well as memories without interaction of the CPU. The TOE operates with a single external power supply of 1.8 V, 3 V or 5 V nominal. Alternatively the TOE can be supplied via the RF interface by inductive coupling. The maximum external clock frequency used for synchronization of the ISO/IEC 7816 communication is 10 MHz nominal, the CPU and all coprocessors are supplied exclusively with an internally generated clock signal which frequency can be selected by the Security IC Embedded Software. The TOE provides power saving modes with reduced activity. These are named IDLE Mode and SLEEP Mode, of which the latter one includes CLOCK STOP Mode. The TOE protects secret data, which are stored to and operated by the TOE, against physical tampering. A memory encryption is added to the memories RAM, ROM and EEPROM. EEPROM double read function is included in this memory to check data consistency during EEPROM read. The PUF block supports the sealing/unsealing of user data of the Composite TOE in the memory. Chip shielding is added in form of active and passive shield over logic and memories. Sensors in form of light, voltage, temperature and frequency sensors are distributed over the chip area. The security functionality of the IC hardware platform is mainly provided by the TOE, and completed by the Security IC Embedded Software. This causes dependencies between the security functionality of the TOE and the security functionality provided by the Security IC Embedded Software. 1.4.3.2 Software description Operating system and applications of a Security IC are developed by the customers and included under the heading Security IC Embedded Software. The Security IC Embedded Software is stored in the Application-ROM and/or in the Application-EEPROM and is not part of the TOE. The Security IC Embedded Software depends on the usage of the IC hardware platform. The IC Dedicated Test Software of the TOE P6021y VB are stored to the Test-ROM and are used by the manufacturer of the Security IC during production test. The test functionality is disabled before the TOE is delivered (operational use of the Security IC) by disabling the Test Mode of the CPU in hardware. The IC Dedicated Test Software is developed by NXP and embedded in the Test-ROM. The IC Dedicated Test Software NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 23 / 129 includes the test operating system, test routines for the various blocks of the circuitry, control flags for the status of the EEPROM's manufacturer area and shutdown functions to ensure that security relevant test routines cannot be executed illegally after phase 3. The following figure shows the logical boundary of the hardware platform (see also Fig. 1) with the IC Dedicated Software of the TOE. For comparison, this figure also shows the logical boundary of two Evaluation Assurance Level (EAL6+ and EAL5+) which this Security Target claims to. Figure 2. Logical boundary of the TOE P6021y VB 1.4.3.2.1 NXP Secure Smart Card Controller P6021P VB The IC Dedicated Support Software of the P6021P VB is stored to the Test-ROM and consists of two parts. • The Boot-ROM Software, which is executed during start-up or reset of the P6021P VB, i.e. each time when the P6021P VB powers up or resets. It sets up the P6021P VB and its basic configuration to ensure the defined initial values. • The Plain Firmware Operating System (FOS-Plain) used as interface for firmware provided by NXP. This comprises the control of hardware related functionality such as access to the manufacturer area of the EEPROM, programming of user data into the EEPROM or the resource configuration functionality. The execution of the FOS-Plain is separated by security mechanism implemented in the hardware including the firewall separation of the Firmware Mode controlling the access to memories and Special Function Register as configured in hardware or by the Security IC Embedded Software. The P6021P VB is always delivered with a FOS-Plain. The related functionality is part of the hardware platform evaluation. The FOS-Plain of the P6021P VB is limited to the control of hardware related functionality and the resource configuration functionality. 1.4.3.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The IC Dedicated Support Software of the P6021M VB/P6021D VB/P6021J VB is also stored to the Test-ROM and consists of two parts. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 24 / 129 • The Boot-ROM Software, which is executed during start-up or reset of the P6021M VB/ P6021D VB/P6021J VB, i.e. each time when the P6021M VB/P6021D VB/P6021J VB powers up or resets. It sets up the P6021M VB/P6021D VB/P6021J VB and its basic configuration to ensure the defined initial values. • The Firmware Operating System provides an interface for the Security IC Embedded Software. This interface is called FVEC. There are several FVECs defined, namely FVEC0.x, FVEC1.x, FVEC2.x, FVEC3.x and FVEC7.x. The letter 'x' is a placeholder for the sub functions of the FVECs. 'x' can be a number between 1 and 255. Please note not all sub numbers are valid. Therefore please refer to [16] for a detailed description of the FVEC interface and all sub functions. – FVEC0.x: This interface establishes the contactless communication according to ISO/IEC 14443 for the Security IC Embedded Software. Furthermore it provides sub functions to enable MIFARE Software. – FVEC1.x: This interface is used to access the EEPROM owned by MIFARE Plus MF1PLUSx0 when in security level 1 or security level 2. MIFARE Plus MF1PLUSx0 in security level 1 or security level 2 does not implement any Security Functional Requirement and therefore FVEC1.x is not in the scope of the evaluation. – FVEC2.x: This interface provides the service to seal/unseal user data in a defined memory area using the Physical Unclonable Function (PUF) block. This interface is also used to read/clear the attack detector status and to read the error counter value. – FVEC3.x: This interface is used to access the EEPROM owned by MIFARE DESFire EV1 or MIFARE Plus MF1PLUSx0 (MIFARE Software). It only handles MIFARE Software commands specified for ISO14443-4. For MIFARE Plus MF1PLUSx0, this includes all security level 0 and security level 3 commands and the security level switch commands in security level 1 and security level 2. – FVEC7.x: This interface implements programming of the internal EEPROM memory, which is mandatory for use by the Security IC Embedded Software when programming the EEPROM memory. The Emulation Firmware Operating System includes the MIFARE Software, which is started by an FVEC call of the Security IC Embedded Software, as described above. • In addition the IC Dedicated Support Software can be used via an FVEC0.x call to establish the contactless communication according to ISO/IEC 14443 for the Security IC Embedded Software. Please refer to [9] for more information. • The execution of the Firmware Operating System is separated by security mechanisms implemented in the hardware including the firewall separation of the Firmware Mode controlling the access to memories and Special Function Registers as configured in hardware or by the Security IC Embedded Software. • The P6021M VB/P6021D VB/P6021J VB is always delivered with a Firmware Operating System. The related functionality is part of the hardware platform evaluation. The Firmware Operating System of the P6021M VB/P6021D VB/P6021J VB includes the control of hardware related functionality, the resource configuration functionality, and the MIFARE Software. • The P6021M VB/P6021D VB/P6021J VB includes security functional requirements of MIFARE Plus MF1PLUSx0and MIFARE DESFire EV1. Both MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1 can be enabled at the same time. Therefore the IC Dedicated Support Software distinguishes which OS Emulation is selected based on the first received command. However, Security IC Embedded Software can select the order of OS Emulations (MIFARE Plus MF1PLUSx0 or MIFARE DESFire EV1) to check a received command. MIFARE Plus MF1PLUSx0 The MIFARE Plus MF1PLUSx0 provides the following functionality: • A data storage system that contains blocks grouped in sectors which can store data (including so-called values which are blocks in a specific format representing a number). • Authentication on sector level with fine-grained access conditions blocks. • Message authentication to support replay attack protection. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 25 / 129 • Data encryption for confidentiality of the contact-less communication. • Unique serial number for each device (UID) with optional random UID. • MIFARE Plus MF1PLUSx0 offers four security levels, but can only be in one security level at a time. The main features of each security level are listed below: – Security level 0: The MIFARE Plus MF1PLUSx0 does not provide any functionality besides initialization. The MIFARE Plus MF1PLUSx0 is initialized in plaintext, especially keys for the further levels can be brought in. A MIFARE Plus MF1PLUSx0 in security level 0 is not usable for other purposes. After all mandatory keys and security attributes have been stored in the MIFARE Plus MF1PLUSx0 local EEPROM it shall be switched to a higher security level. – Security level 1: The card user can access the blocks in the card after an authentication procedure performed according to the MIFARE Classic proprietary protocol. The communication with the terminal is done using the MIFARE Classic proprietary protocol. Functionality provided by security level 1 does not implement any Security Functional Requirement and is therefore not in the scope of the evaluation. The only exception is the security level switch. Note: In security level 1 it is possible to switch to a higher security level if an authentication using the AES algorithm with the necessary key is performed. Note: MIFARE Plus MF1PLUSx0 in security level 1 is also referred to as MIFARE Classic. MIFARE Plus MF1PLUSx0 can be configured in a way that only MIFARE Classic functionality, which does not implement any Security Functional Requirement and is therefore not in the scope of the evaluation, is available to the Security IC Embedded Software (see minor configuration option "version and nominal user memory for MIFARE implementation" values MC1 and MC4) 1 . – Security level 2: The card user can access the blocks in the card after an authentication procedure involving an authentication using the AES algorithm and an authentication using the MIFARE Classic proprietary protocol. The communication with the terminal is done using the MIFARE Classic proprietary protocol. Functionality provided by security level 2 does not implement any Security Functional Requirement and is therefore not in the scope of the evaluation. The only exception is the security level switch. Note: In security level 2 it is possible to switch to a higher security level if an authentication using the AES algorithm with the necessary key is performed. – Security level 3: The card user can access the data and value blocks in the card via an adequate card terminal after an authentication procedure based on the AES algorithm. The communication with the card terminal can be protected with secure messaging. The authentication and the secure messaging are security services of the TOE. The P6021M VB/P6021J VB cannot be switched to a different security level. • The P6021M VB/P6021J VB provides the Security Services assigned to the MIFARE Plus MF1PLUSx0 in security level 3. In addition the personalisation in security level 0, the originality function, which allows verifying the authenticity of the P6021M VB/P6021J VB in all security levels, as well as the switching from security level 1 and security level 2 into security level 3 are within the scope of the evaluation. Note: Communication with the card terminal in security level 1 and security level 2 use the proprietary MIFARE Classic protocol, which do not implement any Security Functional Requirement and is therefore not in the scope of the evaluation. • The MIFARE Plus MF1PLUSx0 security level 0 is intended for personalisation in phase 6 according to the [6], section 1.2.4. The security levels 1 to 3 are intended for the phase 7 of the Security IC product life-cycle. • The additional SFRs for MIFARE Plus MF1PLUSx0 are defined in Section 6.1.2.1. The additional SFRs for the MIFARE Plus MF1PLUSx0 software include the iteration indicator "[MFP]" to clearly mark that they are only applicable for the MIFARE Plus MF1PLUSx0 software. 1 The configurations MC1 and MC4 are limited to MIFARE classic functionality in Security Level 1 (see Section 1.4.3.2). These configurations are fixed to Security Level 1. MC1 and MC4 do not implement any Security Functional Requirement for MIFARE Plus MF1PLUSx0 and the functionality provided by the IC Dedicated Software when configured to MC1 and MC4 is not part of the evaluation (see Table 5). NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 26 / 129 MIFARE DESFire EV1 The MIFARE DESFire EV1 provides the following functionality: • 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 additional SFRs for MIFARE DESFire EV1 are defined in Section 6.1.2.2. The additional SFRs for the MIFARE DESFire EV1 software include the iteration indicator "[DF]" to clearly mark that they are only applicable for the MIFARE DESFire EV1 software. • The P6021D VB/P6021J VB supports a MIFARE DESFire EV1 backward compatible mode for authentication. The backward compatible mode for authentication is not part of any Security Functional Requirement of MIFARE DESFire EV1 and is therefore not in the scope of the evaluation. • The P6021D VB/P6021J VB support MIFARE DESFire EV1 authentication with 2-key Triple-DES. The 2-key Triple-DES authentication is not part of any Security Functional Requirement of MIFARE DESFire EV1 and is therefore also not in the scope of the evaluation. 1.4.3.3 Documentation 1.4.3.3.1 NXP Secure Smart Card Controller P6021P VB The following documentation is available for the P6021P VB: • The data sheet "Product Data Sheet SmartMX2 family P6021y VB, Secure high- performance smart card controller, NXP Semiconductors " [9] contains a functional description and guidelines for the use of the security functionality, as needed to develop Security IC Embedded Software. • The instruction set of the CPU is described in "Instruction Set for the SmartMX2 family, Secure smart card controller, NXP Semiconductors, Document Number 1478**" [10]. • The manual "Information on Guidance and Operation, NXP Secure Smart Card Controller P6021y VB, NXP Semiconductors" [11] describes aspects of the program interface and the use of programming techniques to improve the security. • The wafer and delivery specification "Product data sheet addendum - SmartMX2 P6021y VB, Wafer and delivery specification, NXP Semiconductors, Document Number 3222**" [12] describes physical identification of the P6021P VB and the secure delivery process. • The FVEC interface of the IC Dedicated Support Software is described in "Product Data Sheet Addendum - SmartMX2P602xy VB family, Firmware Interface Specification, NXP Semiconductors, Document Number 2997** " [16]. • The FVEC interface specification addendum is described in "Firmware Interface Specification Addendum - SmartMX2P602xy VB family, Firmware Interface Specification Addendum, NXP Semiconductors, Document Number 3741**" [17]. 1.4.3.3.2 NXP Secure Smart Card Controller P6021M VB The documentation for the P6021M VB is composed of the documentation for the P6021P VB and the following additional documentation: • The functional specification of the MIFARE Plus MF1PLUSx0 is described in "Product Data Sheet - MIFARE Plus Functionality of implementations on smart card controllers, NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 27 / 129 NXP Semiconductors, Document Number 2062**" [14]. The whole documentation shall be used by the developer to develop the Security IC Embedded Software. • The guidance, delivery and operation for MIFARE Plus MF1PLUSx0 is described in "MIFARE Plus MF1PLUSx0 Guidance and Operation Manual, NXP Secure Smart Card Controller P602xy, NXP Semiconductors, Document Number 2335**" [18] improving secure operation of MIFARE Plus MF1PLUSx0. 1.4.3.3.3 NXP Secure Smart Card Controller P6021D VB The documentation for the P6021D VB is composed of the documentation for the P6021P VB and the following additional documentation: • The functional specification of the MIFARE DESFire EV1 Software is described in "Product Data Sheet - MIFARE DESFire EV1 Functionality of implementations on smart card controllers, NXP Semiconductors, Document Number 2258**" [15]. The whole documentation shall be used by the developer to develop the Security IC Embedded Software. • The guidance, delivery and operation manual for MIFARE DESFire EV1 is described in "MIFARE DESFire EV1 Guidance and Operation Manual, NXP Secure Smart Card Controller P602xy, NXP Semiconductors, Document Number 2400**" [19] improving secure operation of MIFARE DESFire EV1. 1.4.3.3.4 NXP Secure Smart Card Controller P6021J VB The documentation for the P6021J VB is composed of the documentation for the P6021P VB, the additional documentation for the P6021M VB, and the additional documentation for the P6021D VB. 1.4.4 Security during development and production The Security IC product life-cycle is scheduled in phases as introduced in the PP [6]. IC Development as well as IC Manufacturing and Testing, which are phases 2 and 3 of the life-cycle, are part of the evaluation. Phase 4 the IC Packaging is also part of the evaluation. The Security IC is delivered at the end of phase 3 or phase 4 in the life-cycle. The development and production environment of the TOE ranges from phase 2 to TOE Delivery. With respect to Application Note 3 in [6] the TOE supports the authentic delivery using the "Chip Health/Ident Mode" and the FabKey feature. For further details on these features please refer to the data sheet [9] and the guidance and operation manual [11]. During the design and the layout process only people involved in the specific development project for an IC have access to sensitive data. Different people are responsible for the design data and for customer related data. The production of the wafers includes two different steps regarding the production flow. In the first step the wafers are produced with the fixed masks independent of the customer. After that step the wafers are completed with the customer specific mask, including the ROM Code, and the remaining mask set. 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 TOE. NXP embeds the dice into modules, inlays or packages based on customer demand. Information about non-functional items is stored on magnetic/optical media enclosed with the delivery or the non-functional items are physically marked. In summary, the TOE can be delivered in four different forms, which are • dice on wafers • smartcard modules on a module reel • inlays • packaged devices in tubes or reels The availability of major configuration options of the TOE in package types is detailed in Section 1.4.2.4. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 28 / 129 1.4.5 TOE intended usage 1.4.5.1 NXP Secure Smart Card Controller P6021P VB The end-consumer environment of the P6021P VB is phase 7 of the Security IC product life-cycle as defined in the PP [6]. In this phase the Security IC product is in usage by the end-consumer. Its method of use now depends on the Security IC Embedded Software. The Security ICs including the P6021P VB can be used to assure authorized conditional access in a wide range of applications. Examples are identity cards, Banking Cards, Pay- TV, Portable communication SIM cards, Health cards and Transportation cards. The end-user environment covers a wide spectrum of very different functions, thus making it difficult to monitor and avoid abuse of the P6021P VB. The P6021P VB is intended to be used in an insecure environment, which does not protect against threats. The device is developed for most high-end safeguarded applications, and is designed for embedding into chip cards according to ISO/IEC 7816 [22] and for contactless applications according to ISO/IEC 14443 [23]. Usually a Security IC (e.g. a smartcard) is assigned to a single individual only, but it may also be used by multiple applications in a multi-provider environment. Therefore the P6021P VB might store and process secrets of several systems, which must be protected from each other. The P6021P VB then must meet security requirements for each single security module. Secret data shall be used as input for calculation of authentication data, calculation of signatures and encryption of data and keys. In development and production environment of the P6021P VB the Security IC Embedded Software developer and system integrators such as the terminal software developer may use samples of the P6021P VB for their testing purposes. It is not intended that they are able to change the behaviour of the Security IC in another way than an end-consumer. The user environment of the P6021P VB ranges from TOE delivery to phase 7 of the Security IC product life-cycle, and must be a controlled environment up to phase 6. Note: The phases from TOE Delivery to phase 7 of the Security IC Product life-cycle are not part of the P6021P VB construction process in the sense of this Security Target. Information about these phases is just included to describe how the P6021P VB is used after its construction. Nevertheless such security functionality of the P6021P VB, that is independent of the Security IC Embedded Software, is active at TOE Delivery and cannot be disabled by the Security IC Embedded Software in the following phases. 1.4.5.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The intended usage of P6021M VB/P6021D VB/P6021J VB includes the intended usage of P6021P VB. In addition, the P6021M VB/P6021D VB/P6021J VB covers the following intended usage. In the P6021M VB/P6021D VB/P6021J VB, the Security IC Embedded Software can interface with MIFARE Software. MIFARE Software indicates either MIFARE Plus MF1PLUSx0 or MIFARE DESFire EV1 or both MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1. If MIFARE Software is called, it provides its own security functionality and operates independent of the Security IC Embedded Software on the memory partitions assigned to MIFARE Software. The intended usage of the P6021M VB/P6021D VB/P6021J VB requires that MIFARE Software is personalised before the delivery to phase 7. MIFARE Plus MF1PLUSx0 is personalized in security level 0 within a secure environment and shall be switched to security level 3 afterwards. MIFARE DESFire EV1 needs also to be personalised but does not provide a dedicated security level for the personalisation. If MIFARE Plus MF1PLUSx0 is in security level 3 and is called it provides its own security functionality and operates independent of the Security IC Embedded Software on the memory partitions assigned to MIFARE Plus MF1PLUSx0. If MIFARE DESFire EV1 is called it also provides its own security functionality and NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 29 / 129 operates independent of the Security IC Embedded Software on the memory partitions assigned to MIFARE DESFire EV1. MIFARE Plus MF1PLUSx0 supports MIFARE Plus compatible applications in the field of: • Electronic fare collection • Stored value card systems • Access control systems • Loyalty The MIFARE DESFire EV1 supports DESFire compatible applications in the field of: • Electronic fare collection • Stored value card systems • Access control systems • Loyalty If privacy is an issue, the MIFARE Software can be configured not to disclose any information to unauthorized users. However in this case also the application(s) implemented in the Security IC Embedded Software must support this privacy issue. Otherwise the privacy enforced by the MIFARE Software can be circumvented by selecting another application of the P6021M VB/P6021D VB/P6021J VB. 1.4.6 Interface of the TOE 1.4.6.1 NXP Secure Smart Card Controller P6021P VB The electrical interface of the P6021P VB are the pads to connect the lines power supply, ground, reset input, clock input, serial communication pads I/O1 and depending on a minor configuration option TP1 and TP2, as well as two pads (called LA and LB) for the antenna of the RF interface. Communication with the P6021P VB can be established via the contact interface through the ISO/IEC 7816 UART or direct usage of the I/O ports. Contactless communication is done via the contactless interface unit (CIU) compatible to ISO/IEC 14443. The logical interface of the P6021P VB depends on the CPU mode and the associated software. • In Boot Mode the Boot-ROM Software is executed. Only in case the minor configuration option 'Chip Health/Ident Mode' is enabled, starting of built-in self test routines and read-out of TOE identification items is supported. If this minor configuration option is disabled the Boot-ROM Software provides no interface. In this case there is no possibility to interact with this software. • In Test Mode (used before TOE delivery) the logical interface visible on the electrical interface is defined by the IC Dedicated Test Software. This IC Dedicated Test Software comprises the test Operating System and the package of test function calls. • In Firmware Mode the Firmware Operating System is executed by the CPU. The Firmware Mode is always requested by the Security IC Embedded Software via an FVEC call. Please refer to [9] for more information. • In System Mode and User Mode (after TOE Delivery) the software interface is the set of instructions, the bits in the special function registers that are related to these modes and the physical address map of the CPU including memories. The access to the special function registers as well as to the memories depends on the CPU mode configured by the Security IC Embedded Software. Note: The logical interface of the P6021P VB that is visible on the electrical interface after TOE Delivery is based on the Security IC Embedded Software developed by the software developer. The identification and authentication of the user in System Mode or User Mode must be controlled by the Security IC Embedded Software. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 30 / 129 The chip surface can be seen as an interface of the P6021P VB, too. This interface must be taken into account regarding environmental stress e.g. like temperature and in the case of an attack, for which the attacker manipulates the chip surface. Note: An external voltage and timing supply as well as a logical interface are necessary for the operation of the P6021P VB. Beyond the physical behaviour the logical interface is defined by the Security IC Embedded Software. 1.4.6.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The interface of the P6021M VB/P6021D VB/P6021J VB includes the interface of the P6021P VB, and, in addition, the following logical interface for MIFARE Software. • The MIFARE Plus MF1PLUSx0 is part of the FOS and can be executed by using a specific FVEC call. The interface of the MIFARE Plus MF1PLUSx0 comprises the command interface as defined by the functional specification of the MIFARE Plus MF1PLUSx0. Please refer to [14]. • The MIFARE DESFire EV1 is part of the FOS and can be executed by using a specific FVEC call. The interface of the MIFARE DESFire EV1 comprises the command interface as defined by the functional specification of the MIFARE DESFire EV1. Please refer to [15]. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 31 / 129 2 Conformance claims This chapter is divided into the following sections: "CC Conformance Claim", "Package claim", "PP claim" and "Conformance Claim Rationale". 2.1 CC conformance claim This Security Target and the TOE P6021y VB claims to be conformant to version 3.1 of Common Criteria for Information Technology Security Evaluation according to • "Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 4, September 2012, CCMB-2012-09-001" [1] • "Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-002" [2] • "Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-003" [3] The following methodology will be used for the evaluation. • "Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, September 2012, CCMB-2012-09-004" [4] This Security Target and the TOE P6021y VB claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security Functional Requirements are defined in Section 5. 2.2 Package claim This Security Target claims conformance to the assurance package EAL6 augmented for P6021P VB and to the assurance package EAL5 augmented for P6021M VB/P6021D VB/P6021J VB. The augmentation to EAL6 is ALC_FLR.1 and the augmentation to EAL5 is AVA_VAN.5 and ALC_DVS.2. In addition, both assurance packages of this Security Target are augmented using the component ASE_TSS.2, which is chosen to include architectural information on the security functionality of the TOE. Table 17 summarizes the package claim of this Security Target. Table 17. Package claim Major configuration Evaluation assurance level Augmentation P6021P VB EAL6+ ALC_FLR.1, ASE_TSS.2 P6021M VB/P6021D VB/ P6021J VB EAL5+ AVA_VAN.5, ALC_DVS.2, ASE_TSS.2 Note: The PP "Security IC Platform Protection Profile" [6] to which this Security Target claims strict conformance (for details refer to Section 2.3) requires assurance level EAL4 augmented. The changes, which are needed for EAL5 and EAL6, are described in the relevant sections of this Security Target. The level of evaluation and the functionality of the TOE are chosen in order to allow the confirmation that the TOE is suitable for use within devices compliant with the German Digital Signature Law. 2.3 PP claim This Security Target claims strict conformance to the Protection Profile (PP) "Security IC Platform Protection Profile with Augmentation Packages, Version 1.0, registered NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 32 / 129 and certified by Bundesamt fuer Sicherheit in der Informationstechnik (BSI) under the reference BSI-PP-0084-2014" [6]. Since the Security Target claims strict conformance to this PP [6], the concepts are used in the same sense. For the definition of terms refer to the PP [6]. These terms also apply to this Security Target. The Security Target includes the packages from the PP [6] and claims conformance as follows: • Package “TDES” (Section 7.4 of PP [6]) Conformant; and • Package “AES” (Section 7.4 of PP [6]) Conformant. The TOE provides additional functionality, which is not covered in the PP [6]. This additional functionality is added using the policy "P.Add-Components-Plain" and "P.Add- Components-Mifare" (see Section 3.3.1 of this Security Target for details). 2.4 Conformance claim rationale According to Section 2.3, this Security Target claims strict conformance to the PP “Security IC Platform Protection Profile [6]. The TOE type defined in Section 1.3.4 of this Security Target is a smartcard controller. This is consistent with the TOE definition for a Security IC in section 1.2.2 of [6]. All sections of this Security Target, in which security problem definition, objectives and security requirements are defined, clearly state which of these items are taken from the PP [6] and which are added in this Security Target. Therefore this is not repeated here. Moreover, all additionally stated items in this Security Target do not contradict the items included from the PP (see the respective sections in this document). The operations done for the SFRs taken from the PP [6] are also clearly indicated. The evaluation assurance level claimed for this target (EAL6+ for P6021P VB and EAL5+ for P6021M VB, P6021D VB and P6021J VB) is shown in Section 6.2 to include respectively exceed the requirements claimed by the PP [6] (EAL4+). These considerations show that the Security Target correctly claims strict conformance to the PP [6]. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 33 / 129 3 Security Problem Definition This Security Target claims strict conformance to the PP “Security IC Protection Profile” [6]. Assets, threats, assumptions and organisational security policies are taken from the PP [6]. This chapter lists these assets, threats, assumptions and organisational security policies, and describes extensions to these elements in detail. The chapter is divided into the following sections: "Description of Assets", "Threats", "Organisational Security Policies", and "Assumptions". 3.1 Description of Assets 3.1.1 NXP Secure Smart Card Controller P6021P VB Since this Security Target claims strict conformance to the PP “Security IC Protection Profile” [6] the assets defined in section 3.1 of [6] are applied here. These assets are cited below. The assets related to standard functionality are: • integrity and confidentiality of user data of the Composite TOE being stored in the protected memory areas of the P6021P VB, • integrity and confidentiality of Security IC Embedded Software, stored and in operation, • correct operation of the security services and restricted hardware resources provided by the P6021P VB for the Security IC Embedded Software. Note the Security IC Embedded Software is user data and shall be protected while being executed/processed and while being stored in the protected memories of the P6021P VB. To be able to protect these assets the P6021P VB shall self-protect its TSF. Critical information about the P6021P VB shall be protected by the development environment and the operational environment. Critical information include: • logical design data, physical design data, Security IC Dedicated Software, configuration data, • Initialisation Data and Pre-personalisation Data, specific development aids, test and characterisation related data, material for software development support, photomasks. Note that the keys for the cryptographic calculations using cryptographic coprocessors are seen as user data of the Composite TOE. 3.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The assets of the P6021M VB/P6021D VB/P6021J VB includes the assets of the P6021P VB. In addition, if the Security IC Embedded Software includes the interface with the MIFARE Software, the assets are extended by: • integrity and confidentiality of the Keys and Data controlled by the MIFARE Software • integrity and confidentiality of the MIFARE Software, stored and in operation. Note that keys used by the Security IC Embedded Software for the cryptographic coprocessors are seen as user data of the Composite TOE because the Security IC Embedded Software is not part of the P6021M VB/P6021D VB/P6021J VB. Keys of the MIFARE Software are explicitly addressed because their protection is completely provided by the P6021M VB/P6021D VB/P6021J VB. 3.2 Threats NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 34 / 129 3.2.1 NXP Secure Smart Card Controller P6021P VB Since this Security Target claims strict conformance to the PP "Security IC Platform Protection Profile" [6] the threats defined in section 3.2 of [6] are valid for this Security Target. The threats defined in the PP [6] are listed below in Table 18. Table 18. Threats defined by the PP [6] Name Title T.Leak-Inherent Inherent Information Leakage T.Phys-Probing Physical Probing T.Malfunction Malfunction due to Environmental Stress T.Phys-Manipulation Physical Manipulation T.Leak-Forced Forced Information Leakage T.Abuse-Func Abuse of Functionality T.RND Deficiency of Random Numbers Considering Application Note 4 in [6] the P6021P VB provides additional functionality to protect against threats that may occur if the hardware platform is used for multiple applications. The P6021P VB provides access control to the memories and to hardware resources providing security services for the software. The Security IC Embedded Software controls all user data stored by the P6021P VB. If multiple applications are running on the P6021P VB the user data may belong to different applications. The access to user data from application A by the application B contradicts the separation between the different applications and is considered as threat. The user data is stored in the memory and processed by the hardware resources. The P6021P VB shall avert the threat "Unauthorised Memory or Hardware Access (T.Unauthorised-Access)" as specified below. T.Unauthorised-Access Unauthorised Memory or Hardware Access Adverse action: An attacker may try to read, modify or execute code or data stored in restricted memory areas. And or an attacker may try to access or operate hardware resources that are restricted by executing code that accidentally or deliberately accesses these restricted hardware resources. Any code or data executed in Boot Mode, Firmware Mode, System Mode or User Mode may accidentally or deliberately access User Data or code of another application stored on the TOE. Or any code or data executed in Boot Mode, Firmware Mode, System Mode or User Mode may accidentally or deliberately access hardware resources that are restricted or reserved for other CPU modes. Threat agent: having high attack potential and access to the TOE Asset: execution of code or data belonging to the Security IC Dedicated Support Software as well as belonging to Security IC Embedded Software. Access restrictions for the memories and hardware resources accessible by the Security IC Embedded Software must be defined and implemented by the security policy of the Security IC Embedded Software based on the specific application context. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 35 / 129 3.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The threats of the P6021M VB/P6021D VB/P6021J VB includes the threats of the P6021P VB, and, the additional threats related to the functionality provided by the MIFARE Software. Considering Application Note 4 in [6] the following threats are defined by this Security Target: T.Data-Modification Unauthorized modification of keys and data maintained by the MIFARE Software Adverse action: unauthorized subject modifies keys and data maintained by the MIFARE Software and stored by the TOE during processing of modifying commands received by the TOE. It is not concerned with verification of authenticity. Threat agent: having high attack potential and access to the TOE Asset: integrity of keys and data maintained by the MIFARE Software T.Impersonate Impersonating authorized users during the authentication process of the MIFARE Software Adverse action: unauthorized subject tries to impersonate an authorized subject during the authentication sequence of the MIFARE Software, e.g. by a man-in-the middle or replay attack Threat agent: having high attack potential Asset: confidentiality of keys and data maintained by the MIFARE Software T.Cloning Cloning using keys and data maintained by the MIFARE Software Adverse action: unauthorized subject reads out keys and data maintained by the MIFARE Software and stored on the TOE in order to create a duplicate Threat agent: having high attack potential and access to the TOE Asset: keys and data maintained by the MIFARE Software 3.3 Organizational Security Policies 3.3.1 NXP Secure Smart Card Controller P6021P VB Since this Security Target claims strict conformance to the PP "Security IC Platform Protection Profile" [6] the policy P.Process-TOE "Identification during TOE Development and Production" in [6] is applied here as well. The cryptographic security services implement the same organizational security policy but in different extend. P.Crypto-Service Cryptographic services of the TOE The TOE provides secure hardware based cryptographic services for the IC Embedded Software. Note that the P6021P VB provides the following cryptographic services for the IC Embedded Software: • Triple-DES encryption and decryption • AES encryption and decryption In accordance with Application Note 5 in [6] there are additional policies defined in this Security Target as detailed below. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 36 / 129 The P6021P VB provides further security functions or security services which can be used by the Security IC Embedded Software. In the following, specific security functionality is listed, which is not derived from threats identified for the environment of the P6021P VB. It can only be decided in the context of the application against which threats the Security IC Embedded Software will use this specific security functionality. The IC Developer/Manufacturer therefore applies the policy "Additional Specific Security Components (P.Add-Components-Plain)" as specified below. P.Add-Components-Plain Additional Specific Security Components of P6021P VB The P6021P VB shall provide the following additional security functionality to the Security IC Embedded Software: • Integrity support of data stored in EEPROM • Hardware Post Delivery Configuration: reconfiguration of customer selectable options as listed in Table 8 • PUF functionality 3.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The Organizational Security Policies (OSP) of the P6021M VB/P6021D VB/P6021J VB includes the OSP of the P6021P VB, and, in addition, the following OSP for MIFARE Software. P.Add-Components-Mifare Additional Specific Security Components for MIFARE Software The P6021M VB/P6021D VB/P6021J VB shall provide the following additional security functionality to the Security IC Embedded Software: • MIFARE Post Delivery Configuration: reconfiguration of customer selectable options as listed in Table 9 (for the P6021M VB), in Table 10 (for the P6021D VB), and in Table 9 and Table 10 (for the P6021J VB). In addition the MIFARE Software as part of the hardware platform provides the following organisational security policy "P.Emulation". The Security IC Embedded Software can call the MIFARE Software which implements this security policy. It is not mandatory for the Security IC Embedded Software to call the MIFARE Software. However if the P6021M VB/P6021D VB/P6021J VB shall emulate the MIFARE Software functionality the Security IC Embedded Software must call the MIFARE Software. Therefore the IC Developer/Manufacturer defines the additional policy as specified below. P.Emulation MIFARE Software Emulation The MIFARE Software provides the following specific security components: • Confidentiality during communication between the Security IC and the terminal provides the possibility to protect selected data elements from eavesdropping during contactless communication. Note that for MIFARE Plus MF1PLUSx0 confidentiality during communication between the Security IC and the terminal is only available in security level 3. • Integrity during communication between the Security IC and the terminal provides the possibility to protect the contactless communication from modification or injections. This includes especially the possibility to NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 37 / 129 detect replay or man-in-the-middle attacks within a session The following OSP is required only for the MIFARE DESFire EV1 software: P.DF-Transaction DESFire Transaction Mechanism The DESFire Emulation provides the following specific security components: • Transaction mechanism provides 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. 3.4 Assumptions 3.4.1 NXP Secure Smart Card Controller P6021P VB Since this Security Target claims conformance to the PP "Security IC Platform Protection Profile" [6] the assumptions defined in section 3.4 of [6] are valid for this Security Target. The following table lists these assumptions. Table 19. Assumptions defined in the PP [6] Name Title A.Process-Sec-IC Protection during Packaging, Finishing and Personalisation A.Resp-Appl Treatment of user data of the Composite TOE Note that the assumption A.Resp-Appl defined in the Protection Profile are relevant for all software running on the hardware platform. The assumptions are still applicable for the Security IC Embedded Software and therefore they will remain in this Security Target as defined in the Protection Profile [6]. The following assumptions are added in this Security Target according to Application Notes 6 and 7 in [6]. A.Check-Init-Plain Check of initialisation data by the Security IC Embedded Software The Security IC Embedded Software must provide a function to check initialisation data. The initialisation data is defined by the customer and injected by the TOE Manufacturer into the non-volatile memory to provide the possibility for TOE identification and for traceability. 3.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The assumptions of the P6021M VB/P6021D VB/P6021J VB include the assumptions of the P6021P VB. In addition, the P6021M VB/P6021D VB/P6021J VB includes the following assumptions for MIFARE Software. A.Check-Init-Mifare Check of initialisation data for MIFARE Software by the Security IC Embedded Software The Security IC Embedded Software must support the use of the originality key function provided by the MIFARE Software. The originality key is defined by NXP. The originality key is injected by the TOE Manufacturer into the non-volatile memory to provide the possibility for TOE identification and for traceability. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 38 / 129 The following two assumptions must be implemented to support the security functionality of the MIFARE Software. A.Secure-Values Usage of secure values Only confidential and secure keys shall be used to set up the authentication and access rights for the MIFARE Software. These values are generated outside the P6021M VB/P6021D VB/P6021J VB. They must be protected during generation, management outside the P6021M VB/P6021D VB/P6021J VB and downloading to the P6021M VB/P6021D VB/P6021J VB. A.Terminal-Support Usage of secure values The terminal verifies information sent by the P6021M VB/P6021D VB/P6021J VB in order to ensure integrity and confidentiality of the communication. Furthermore the terminal shall provide random numbers according to AIS20 (see [7]) or AIS31 (see [7]) for the MIFARE Software authentication. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 39 / 129 4 Security Objectives This chapter contains the following sections: “Security Objectives for the TOE”, “Security Objectives for the Security IC Embedded Software”, “Security Objectives for the Operational Environment”, and “Security Objectives Rationale”. 4.1 Security Objectives for the TOE 4.1.1 NXP Secure Smart Card Controller P6021P VB The P6021P VB shall provide the following security objectives, which are taken from the PP "Security IC Platform Protection Profile" [6]. Table 20. Security objectives defined in the PP [6] Name Title O.Leak-Inherent Protection against Inherent Information Leakage O.Phys-Probing Protection against Physical Probing O.Malfunction Protection against Malfunctions O.Phys-Manipulation Protection against Physical Manipulation O.Leak-Forced Protection against Forced Information Leakage O.Abuse-Func Protection against Abuse of Functionality O.Identification TOE Identification O.RND Random Numbers O.TDES Cryptographic service Triple-DES O.AES Cryptographic service AES Regarding Application Notes 8 and 9 in [6] the following additional security objectives are defined based on additional functionality provided by the P6021P VB as specified below. O.CUST_RECONF_PLAIN Post Delivery Configuration of Hardware The TOE shall provide the customer with the functionality to reconfigure parts of the TOE properties as specified for Hardware Post Delivery Configuration listed in Table 8. O.EEPROM_INTEGRITY Integrity support of data stored in EEPROM The TOE shall provide a retrimming of the EEPROM to support the integrity of the data stored in the EEPROM. O.FM_FW Firmware Mode Firewall The TOE shall provide separation between the NXP Firmware (i.e. NXP firmware functionality as part of the Security IC Dedicated Support Software) as part of the Security IC Dedicated Support Software and the Security IC Embedded Software. The separation shall comprise software execution and data access. O.MEM_ACCESS Area based Memory Access Control Access by processor instructions to memory areas is controlled by the TOE. The TOE decides based on the CPU mode (Boot Mode, Test Mode, Firmware Mode, System Mode or User Mode) and the configuration of the Memory Management Unit if the requested type of access to the memory area addressed by the operands in the instruction is allowed. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 40 / 129 O.SFR_ACCESS Special Function Register Access Control The TOE shall provide access control to the Special Function Registers depending on the purpose of the Special Function Register or based on permissions associated to the memory area from which the CPU is currently executing code. The access control is used to restrict access to hardware components of the TOE. The possibility to define access permissions to specialised hardware components of the TOE shall be restricted to code running in System Mode. O.PUF Sealing/Unsealing user data The TOE shall provide a PUF functionality that supports sealing/unsealing of user data. Using this functionality, the user data can be sealed within the TOE and can be unsealed by the same TOE that the user data was sealed on. The PUF functionality comprises import/ export of data, encryption/decryption of data and calculation of a MAC as a PUF authentication value. Note: The PUF functionality provided by the P6021P VB shall only be active if explicitly configured by the Security IC Embedded Software. 4.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The security objectives of the P6021M VB/P6021D VB/P6021J VB include the security objectives of the P6021P VB, and, in addition, the following security objectives for MIFARE Software. The security objectives of the IC Dedicated Support Software (MIFARE Software) can only be provided if this IC Dedicated Support Software is called by the Security IC Embedded Software. The MIFARE Software is part of the P6021M VB/P6021D VB/ P6021J VB and provides the following security objectives: O.CUST_RECONF_MIFARE Post Delivery Configuration for MIFARE Software The TOE shall provide the customer with the functionality to reconfigure parts of the TOE properties as specified for MIFARE Post Delivery Configuration in Table 9 (for the P6021M VB), in Table 10 (for the P6021D VB), and in Table 9 and Table 10 (for the P6021J VB). 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 all operations for data elements and to reading and modifying security attributes as well as authentication data. The cryptographic keys used for authentication shall never be output. O.AUTHENTICATION Authentication to external entities The TOE shall be able to authenticate itself to external entities. The Initialisation Data (or parts of them) are used for TOE authentication verification data. O.ENCRYPTION Confidential Communication The TOE must be able to protect the communication between the Security IC and the terminal by encryption. This shall be implemented by security attributes that enforce encrypted communication for the respective data elements. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 41 / 129 O.MAC Integrity-protected Communication The TOE must be able to protect the communication between the Security IC and the terminal by adding a MAC. This shall be mandatory for commands that modify data on the TOE and optional on read commands. In addition a security attribute shall be available to mandate MAC on read commands, too. Usage of the protected communication shall also support the detection of injected and bogus commands within the communication session before the protected data transfer. 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 and for block sizes. O.DF-TRANSACTION DESFire Transaction mechanism The P6021D VB and P6021J VB must be able to provide a transaction mechanism that allows updating of multiple data elements of the MIFARE DESFire EV1 software either all in common or none of them. This objective is only available in MIFARE DESFire EV1. 4.2 Security Objectives for the Security IC Embedded Software In this section, the Security Objectives for the Security IC Embedded Software of the TOE P6021y VB are described. In addition to the security objectives for the operational environment as required by CC Part 1 [1] the PP “Security IC Protection Profile” [6] defines security objective for the Security IC Embedded Software which is listed in the table below. Table 21. Security objectives for the Security IC Embedded Software, taken from the PP [6] Security Objective Description Applies to phase OE.Resp-Appl Treatment of user data of the Composite TOE Phase 1 Clarification of "Treatment of user data of the Composite TOE (OE.Resp-Appl)" By definition cipher or plain text data and cryptographic keys are user data of the Composite TOE. The Security IC Embedded Software shall treat these data appropriately, use only proper secret keys (chosen from a large key space) as input for the cryptographic function of the TOE and use keys and functions appropriately in order to ensure the strength of cryptographic operation. This means that keys are treated as confidential as soon as they are generated. The keys must be unique with a very high probability, as well as cryptographically strong. For example, if asymmetric algorithms are used, it must be ensured that it is not possible to derive the private key from a related public key using the attacks defined in this Security Target. If keys are imported into the TOE and/or derived from other keys, quality and confidentiality must be maintained. This implies that appropriate key management has to be realised in the environment. The treatment of user data of the Composite TOE is also required when a multi- application operating system is implemented as part of the Security IC Embedded Software on the TOE. In this case the multi-application operating system will not disclose security relevant user data of one application to another application when it is processed or stored on the TOE. 4.3 Security Objectives for the Operational Environment NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 42 / 129 4.3.1 NXP Secure Smart Card Controller P6021P VB The following security objectives for the operational environment are specified according to the PP “Security IC Protection Profile” [6]. Table 22. Security objectives for the operational environment, taken from the PP [6] Security Objective Description Applies to Phase OE.Process-Sec-IC Protection during composite product manufacturing TOE delivery up to the end of phase 6 Check of initialisation data The P6021P VB provides specific functionality that requires the TOE Manufacturer to implement measures for the unique identification of the P6021P VB. Therefore, OE.Check-Init is defined to allow a TOE specific implementation (refer also to A.Check- Init-Plain). OE.Check-Init Check of initialisation data by the Security IC Embedded Software To ensure the receipt of the correct TOE, the Security IC Embedded Software shall check a sufficient part of the pre-personalisation data. This shall include at least the FabKey Data that is agreed between the customer and the TOE Manufacturer. 4.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The security objectives of the P6021M VB/P6021D VB/P6021J VB for the operational environment include the security objectives of the P6021P VB for the operational environment, and, in addition, the following security objectives for the operational environment for MIFARE Software. The P6021M VB/P6021D VB/P6021J VB provides specific functionality that requires the TOE Manufacturer to implement measures for the unique identification of the P6021M VB/P6021D VB/P6021J VB. Therefore, in addition to OE.Check-Init, OE.Check- OriginalityKey is defined to allow a TOE specific implementation (refer also to A.Check- Init-Mifare). OE.Check-OriginalityKey Check of the Originality Key of the MIFARE Software To ensure the receipt of the original MIFARE Software functionality, the Security IC Embedded Software shall support the use of the originality function provided by the MIFARE Software. The originality key is introduced by NXP to check the authenticity of the MIFARE product. Note: It is not mandatory for the Security IC Embedded Software to use the MIFARE Software originality key or the originality key provided by NXP. The originality function of MIFARE Software is only available when MIFARE Software is enabled. OE.Secure-Values Generation of secure values The environment shall generate confidential and cryptographically strong keys for authentication purpose of the MIFARE Software. These values are generated outside the P6021M VB/P6021D VB/P6021J VB and they are downloaded to the P6021M VB/P6021D VB/ P6021J VB during the personalization or usage in phase 5 to 7. OE.Terminal-Support Terminal support to ensure integrity, confidentiality and use of random numbers NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 43 / 129 The terminal shall verify information sent by the Security IC 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. Furthermore the terminal shall provide random numbers according to AIS20 (see [7]) or AIS31 (see [7]) for the MIFARE Software authentication. 4.4 Security Objectives Rationale 4.4.1 NXP Secure Smart Card Controller P6021P VB Section 4.4 in the PP “Security IC Protection Profile” [6] provides a rationale how the assumptions, threats, and organisational security policies (OSPs) are addressed by the objectives that are specified in the PP [6]. Table 23 reproduces the table in section 4.4 of [6]. Table 23. Security Objectives versus Assumptions, Threats or Policies (PP [6]) Assumption, Threat or OSP Security objective Notes A.Resp-Appl OE.Resp-Appl P.Process-TOE O.Identification Phase 2 - 3 A.Process-Sec-IC OE.Process-Sec-IC Phase 4 - 6 T.Leak-Inherent O.Leak-Inherent T.Phys-Probing O.Phys-Probing T.Malfunction O.Malfunction T.Phys-Manipulation O.Phys-Manipulation T.Leak-Forced O.Leak-Forced T.Abuse-Func O.Abuse-Func T.RND O.RND Table 24 provides the justification for the additional security objectives. They are in line with the security objectives of the PP [6] and supplement these according to the additional assumptions, threats and organisational security policies. Table 24. Additional Security Objectives versus Assumptions, Threats or Policies Assumption/Threat/Policy Security objective Notes T.Unauthorised-Access O.FM_FW, O.MEM_ACCESS, O.SFR_ACCESS P.Add-Components-Plain O.CUST_RECONF_PLAIN, O.EEPROM_INTEGRITY, O.PUF A.Check-Init-Plain OE.Check-Init Phase 1 and Phases 4 - 6 The justification related to the threat "Unauthorised Memory or Hardware Access (T.Unauthorised-Access)" is as follows: According to O.FM_FW, O.MEM_ACCESS and O.SFR_ACCESS the P6021P VB must enforce the partitioning of memory areas in Firmware Mode, System Mode and User Mode and enforce the segmentation of the memory areas in User Mode so that access of software to memory areas is controlled. Any restrictions have to be defined by the Security IC Embedded Software. Thereby security violations caused by accidental or deliberate access to restricted data (which may include code) can be prevented (refer to NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 44 / 129 T.Unauthorised-Access). The threat T.Unauthorised-Access is therefore covered by the objective. It is up to the Security IC Embedded Software to implement the memory management scheme by appropriately administrating the TSF. This is also expressed both in T.Unauthorised-Access and O.FM_FW, O.MEM_ACCESS and O.SFR_ACCESS. The P6021P VB shall provide access control functions to be used by the Security IC Embedded Software. Therefore, the clarifications contribute to the coverage of the threat T.Unauthorised-Access. The justification related to the OSP "P.Crypto-Service" is as follows: Since the objectives O.TDES and O.AES require the P6021P VB to implement exactly the same specific security functionality as required by P.Crypto-Service, the organisational security policy is covered by the objectives. The justification related to the OSP "Additional Specific Security Components of P6021P VB (P.Add-Components-Plain)" is as follows: Since the objectives O.CUST_RECONF_PLAIN, O.EEPROM_INTEGRITY, and O.PUF requires the P6021P VB to implement exactly the same specific security functionality as required by P.Add- Components-Plain, the organisational security policy is covered by the objectives. Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement the specific security functionality required by "P.Add-Components-Plain". These security objectives are also valid for the additional specific security functionality since they must avert the related threats also for the components added related to the policy. The requirements for a multi-application platform necessitate the separation of users. Therefore it is volitional that most of the security functionality cannot be influenced or used in User Mode. The justification related to the assumption "Check of initialisation data by the Security IC Embedded Software (A.Check-Init-Plain)" is as follows: Since OE.Check-Init requires the Security IC Embedded Software developer to implement a function assumed in A.Check-Init-Plain, the assumption is covered by the objective. The justification of the additional threats, policies and assumptions show that they do not contradict to the rationale already given in the PP [6] for the assumptions, policies and threats defined there. 4.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The security objectives rationale of the P6021M VB/P6021D VB/P6021J VB include the security objectives rationale of the P6021P VB, and, in addition, the following security objectives rationale for MIFARE Software. Table 25 supplements the table in section 4.4 of [6] with additional MIFARE Software assumptions, threats and policies. Table 25. Additional Security Objectives versus Assumptions, Threats or Policies (MIFARE Software) Assumption / Policy / Threat Security Objectives Notes A.Check-Init-Mifare OE.Check-OriginalityKey Phase 1 and Phases 4 - 6 A.Secure-Values OE.Secure-Values Phase 7 A.Terminal-Support OE.Terminal-Support Phase 5 - 6 T.Data-Modification O.ACCESS-CONTROL, O.TYPE- CONSISTENCY, OE.Terminal-Support T.Impersonate O.AUTHENTICATION, OE.Secure- Values NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 45 / 129 Assumption / Policy / Threat Security Objectives Notes T.Cloning O.ACCESS-CONTROL, O.AUTHENTICATION, OE.Secure- Values P.Add-Components-Mifare O.CUST_RECONF_MIFARE P.Emulation O.ENCRYPTION, O.MAC, OE.Terminal-Support P.DF-Transaction [1] O.DF-TRANSACTION [1] Only available for P6021D VB and P6021J VB. The justification is related to the assumption "Check of initialisation data for MIFARE Software by the Security IC Embedded Software (A.Check-Init-Mifare)" is as follows: OE.Check-OriginalityKey requires the user of the MIFARE Software to check the originality of the P6021M VB/P6021D VB/P6021J VB as assumed in A.Check-Init-Mifare. This check is based on data stored in the EEPROM and defined by NXP. Both OE.Check-Init and OE.Check-OriginalityKey are suitable to check the P6021M VB/P6021D VB/P6021J VB as assumed in A.Check-Init-Plain and A.Check-Init-Mifare. Based on the two security objectives for the environment the administrator of the MIFARE Software and the user of the Security IC Embedded Software are independently able to identify the P6021M VB/P6021D VB/P6021J VB. Note: OE.Check-OriginalityKey is only available and required if MIFARE Software is enabled. The justification related to the assumption "Generation of secure values (A.Secure- Values)" is as follows: Since OE.Secure-Values requires using secure values for the configuration of the authentication and access control as assumed in A.Secure-Values, the assumption is covered by the objective. The management of the keys used for the authentication of roles for the MIFARE Software must be performed outside the P6021M VB/P6021D VB/P6021J VB. These keys must be loaded in a personalisation process and these keys must be protected by the environment. Since OE.Secure-Values requires using secure values for the configuration of the authentication and access control as assumed in A.Secure-Values, the assumption is covered by the objective. The justification related to the assumption "Terminal support to ensure integrity, confidentiality and use of random numbers (A.Terminal-Support)" is as follows: The objective OE.Terminal-Support is an immediate transformation of the assumption A.Terminal-Support, therefore it covers the assumption. The P6021M VB/P6021D VB/P6021J VB can only check the integrity of data received from the terminal. For data transferred to the terminal the receiver must verify the integrity of the received data. Furthermore the P6021M VB/P6021D VB/P6021J VB cannot verify the entropy of the random number sent by the terminal. The terminal itself must ensure that random numbers are generated with appropriate entropy for the MIFARE Plus MF1PLUSx0 authentication. This is assumed by the related assumption, therefore the assumption is covered. The additional threats T.Data-Modification, T.Impersonate and T.Cloning are related to the MIFARE Software. They supplement the threats defined in the Protection Profile for the specific application context of the MIFARE Software. The justification related to the threat "Unauthorised data modification (T.Data- Modification)" is as follows: According to threat T.Data-Modification the P6021M VB/P6021D VB/P6021J VB shall avoid that user data stored by the P6021M VB/P6021D VB/P6021J VB may be modified NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 46 / 129 by unauthorised subjects. The objective O.ACCESS-CONTROL requires an access control mechanism that limits the ability to modify data elements stored by the P6021M VB/P6021D VB/P6021J VB. O.TYPE-CONSISTENCY ensures that data types are adhered, so that data cannot be modified by abusing type-specific operations. The terminal must provide support by checking the TOE responses, which is required by OE.Terminal-Support. Therefore T.Data-Modification is covered by these three objectives. The justification related to the threat "Impersonating authorised users during authentication (T.Impersonate)" is as follows: The threat is related to the fact that an unauthorised subject may try to impersonate an authorised subject during authentication, e.g. by a man-in-the middle or replay attack. The goal of O. AUTHENTICATION is that an authentication mechanism is implemented in the P6021M VB/P6021D VB/P6021J VB that prevents these attacks. Therefore the threat is covered by O. AUTHENTICATION. This must be supported by OE.Secure- Values because the authentication is based on keys and the knowledge of the keys must be limited to the authorized users. The justification related to the threat "Cloning (T.Cloning)" is as follows: The concern of T.Cloning is that all data stored on the P6021M VB/P6021D VB/P6021J VB (including keys) may be read out in order to create a duplicate. The objectives O. AUTHENTICATION together with O.ACCESS-CONTROL require that unauthorised users cannot read any information that is restricted to the authorised subjects. The cryptographic keys used for the authentication are stored inside the P6021M VB/ P6021D VB/P6021J VB protected by O.ACCESS-CONTROL. This objective states that the P6021M VB/P6021D VB/P6021J VB shall never output any keys used for authentication. Therefore the two objectives cover T.Cloning. As already mentioned above, an appropriate key management according to OE.Secure-Values must be ensured. The additional OSPs P.Add-Components-Mifare, P.Emulation and P.DF-Transaction are related to the MIFARE Software. They supplement the OSPs defined in the Protection Profile for the specific application context of the MIFARE Software. The justification related to the OSP "Additional Specific Security Components for MIFARE Software (P.Add-Components-Mifare)" is as follows: Since the objective O.CUST_RECONF_MIFARE requires the P6021M VB/P6021D VB/P6021J VB to implement exactly the same specific security functionality as required by P.Add- Components-Mifare, the organisational security policy is covered by the objectives. The policy "MIFARE Software Emulation (P.Emulation)" is related to the IC Dedicated Support Software and covers the additional objectives O.ENCRYPTION, and O.MAC. The justification of the objectives is as follows: Since these objectives require the P6021M VB/P6021D VB/P6021J VB to implement exactly the same specific security functionality as required by P.Emulation, the organizational security policy is covered by the objectives. The functionality of the hardware platform is extended by additional IC Dedicated Support Software that emulates the security functionality defined by the MIFARE Software. The policy "DESFire Transaction Mechanism (P.DF-Transaction)" is related to the IC Dedicated Support Software and covers the additional objective O.DF-TRANSACTION. Note that the policy P.DF-Transaction is required only for the P6021D VB and P6021J VB. The justification of the objective is as follows: Since the objective requires the P6021D VB and P6021J VB to implement exactly the same specific security functionality as required by P.DF-Transaction, the organizational security policy is covered by the objective. The functionality of the hardware platform is extended by additional IC Dedicated Support Software MIFARE DESFire EV1. MIFARE DESFire EV1 implements the security functionality which allows updating of multiple data elements of the MIFARE DESFire EV1 software either all in common or none of them. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 47 / 129 The justification of the additional threats, policies and assumptions show that they do not contradict to the rationale already given in the PP [6] for the assumptions, policies and threats defined there. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 48 / 129 5 Extended Components Definition This Security Target does not define extended components. Note that the PP “Security IC Protection Profile” [6] defines extended security functional requirements in Chapter 5, which are included in this Security Target. The extended component definition used for Random Number Generator has been taken from [8]. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 49 / 129 6 Security Requirements This part of the Security Target defines the detailed security requirements that shall be satisfied by the TOE P6021y VB. The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE. This chapter consists of the sections "Security Functional Requirements", "Security Assurance Requirements" and "Security Requirements Rationale". The CC allows several operations to be performed on security requirements (on the component level); refinement, selection, assignment, and iteration are defined in paragraph 8.1 of Part 1 of the CC [1]. These operations are used in the PP [6] and in this Security Target, respectively. The refinement operation is used to add details to requirements, and, thus, further restricts a requirement. Refinements of security requirements are denoted in such a way that added words are in bold text and changed words are crossed out. The selection operation is used to select one or more options provided by the PP [6] or CC in stating a requirement. Selections having been made are denoted as italic text. The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignments having been made are denoted by showing as italic text. The iteration operation is used when a component is repeated with varying operations. It is denoted by showing brackets "[iteration indicator]" and the iteration indicator within the brackets. For the sake of a better readability, the iteration operation may also be applied to some single components (being not repeated) in order to indicate belonging of such SFRs to same functional cluster. In such a case, the iteration operation is applied to only one single component. Note: For the hardware component of the TOE the iteration indicator "[HW]" will be used. Regarding the access control to the memories and the special function registers the iteration indicators "[MEM]" and "[SFR]" will be used. For the software component MIFARE Plus MF1PLUSx0 the iteration indicator "[MFP]" will be used. For the software component MIFARE DESFire EV1 the iteration indicator "[DF]" will be used. Whenever an element in the PP [6] contains an operation that the PP author left uncompleted, the ST author has to complete that operation. 6.1 Security Functional Requirements The Security Functional Requirements (SFRs) of the TOE P6021y VB are presented in the following sections to support a better understanding of the combination of PP “Security IC Protection Profile” [6] and Security Target. 6.1.1 NXP Secure Smart Card Controller P6021P VB The Security Functional Requirements (SFRs) of the P6021P VB are presented in the following sections. 6.1.1.1 SFRs of the Protection Profile Table 26 shows all SFRs, which are specified in the PP [6] (in the order of definition in the PP). Some of the SFRs are CC Part 2 extended and defined in the PP [6]. This is shown in the third column of the table. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 50 / 129 Table 26. SFRs taken from the PP [6] SFR Title Defined in FRU_FLT.2 Limited fault tolerance CC, Part 2 FPT_FLS.1 Failure with preservation of secure state CC, Part 2 FMT_LIM.1 Limited capabilities PP, Section 5.2 FMT_LIM.2 Limited availability PP, Section 5.2 FAU_SAS.1 Audit storage PP, Section 5.3 FDP_SDC.1 Stored data confidentiality PP, Section 5.4 FDP_SDI.2 Stored data integrity monitoring and action CC, Part 2 FPT_PHP.3 Resistance to physical attack CC, Part 2 FDP_ITT.1 Basic internal transfer protection CC, Part 2 FPT_ITT.1 Basic internal TSF data transfer protection CC, Part 2 FDP_IFC.1 Subset information flow control CC, Part 2 FCS_RNG.1 Random number generation PP, Section 5.1 FCS_COP.1[TDES] Cryptographic operation - TDES PP, Section 7.4.1 FCS_CKM.4[TDES] Cryptographic key destruction - TDES PP, Section 7.4.1 FCS_COP.1[AES] Cryptographic operation - AES PP, Section 7.4.2 FCS_CKM.4[AES] Cryptographic key destruction PP, Section 7.4.2 The PP [6] partially leaves the assignments and selections for FAU_SAS.1 and FCS_RNG.1 open. These are included in the following.” For the SFR FAU_SAS.1 the PP [6] leaves the assignment operation open for the nonvolatile memory type in which initialisation data, pre-personalisation data or other data are stored. This assignment operation is filled in by the following statement. Note that the assignment operations for the list of subjects and the list of audit information have already been filled in by the PP [6]. FAU_SAS.1[HW] Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1[HW] The TSF shall provide the test process before TOE Delivery 2 with the capability to store the Initialisation Data, Pre-personalisation Data or other data 3 in the EEPROM 4 . For FCS_RNG.1.1 the PP [6] partially fills in the assignment for the security capabilities of the RNG by requiring a total failure test of the random source and adds an assignment operation for additional security capabilities of the RNG. In addition, for FCS_RNG.1.2 the PP [6] partially fills in the assignment operation for the defined quality metric for the random numbers by replacing it by a selection and assignment operation. For the above operations the original operations defined in chapter 5 of the PP [6] have been replaced by operations defined in chapter 3 of [8] and the open operations of the partially filled in operations in the statement of the security requirements in section 4.4 of [8] for better readability. Note that the selection operation for the RNG type has already been filled in by the PP [6]. 2 [assignment: list of subjects] 3 [assignment: list of audit information] 4 [assignment: type of persistent memory] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 51 / 129 FCS_RNG.1[HW] Random number generation (Class PTG.2) Hierarchical to: No other components. Note: The definition of the Security Functional Requirement FCS_RNG.1 has been taken from [8]. Note: The functional requirement FCS_RNG.1[HW] is a refinement of FCS_RNG.1 defined in PP [6] according to [8]. FCS_RNG.1.1[HW] The TSF shall provide a physical 5 random number generator that implements: (PTG.2.1) A total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output. (PTG.2.2) If a total failure of the entropy source occurs while the RNG is being operated, the RNG prevents the output of any internal random number that depends on some raw random numbers that have been generated after the total failure of the entropy source. 6 (PTG.2.3) The online test shall detect non-tolerable statistical defects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test has finished successfully or when a defect has been detected. (PTG.2.4) The online test procedure shall be effective to detect nontolerable weaknesses of the random numbers soon. (PTG.2.5) The online test procedure checks the quality of the raw random number sequence. It is triggered at regular intervals or continuously 7 . The online test is suitable for detecting nontolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time. 8 Note: The TOE provides the two options where the Embedded Software can choose one. FCS_RNG.1.2[HW] The TSF shall provide octets of bits 9 that meet: (PTG.2.6) Test procedure A 10 does not distinguish the internal random numbers from output sequences of an ideal RNG. (PTG.2.7) The average Shannon entropy per internal random bit exceeds 0.997. 11 5 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] 6 [selection: prevents the output of any internal random number that depends on some raw random numbers that have been generated after the total failure of the entropy source, generates the internal random numbers with a post-processing algorithm of class DRG.2 as long as its internal state entropy guarantees the claimed output entropy] 7 [selection: externally, at regular intervals, continuously, applied upon specified internal events] 8 [assignment: list of security capabilities] 9 [selection: bits, octets of bits, numbers [assignment: format of the numbers]] 10 [assignment: additional standard test suites] Note: according §295 in [8] the assignment may be empty 11 [assignment: a defined quality metric] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 52 / 129 Note: The Shannon entropy 0.997 per internal random bit compares to 7.976 per octet. Note: Application Note 21 in [6] requires that the Security Target specifies for the security capabilities in FCS_RNG.1.1 how the results of the total failure test of the random source are provided to the Security IC Embedded Software. The TOE features a hardware test which is called by the Security IC Embedded Software. The results of the internal test sequence are provided to the Security IC Embedded Software as a pass or fail criterion by means of a special function register. The entropy of the random number is measured by the Shannon-Entropy as follows: , where Pi is the probability that the byte (b7,b6,...,b0) 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" [7]. Dependencies: No dependencies. The definition of the SFR FDP_SDI.2 is repeated in the following because the SFR is extended to the integrity check operation of HW, FW, EEPROM, RAM and ROM. Based on the Data Processing Policy defined in PP [6] the SFR FDP_SDI.2 includes the requirement to ensure the integrity of the information of the user data. The (EEPROM adjustment operation of) P6021P VB shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as specified below. FDP_SDI.2[HW] Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring FDP_SDI.2.1[HW] The TSF shall monitor user data stored in containers controlled by the TSF for integrity violations due to ageing 12 on all objects, based on the following attributes: User data including code stored in the EEPROM 13 . FDP_SDI.2.2[HW] Upon detection of a data integrity error, the TSF shall adjust the EEPROM write operation 14 . Dependencies: No dependencies. Refinement: Each EEPROM memory block is considered as one container and the adjustment is done for one complete EEPROM memory block. The (EEPROM integrity check operation) of P6021P VB shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as specified below. FDP_SDI.2[FW] Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring FDP_SDI.2.1[FW] The TSF shall monitor user data stored in containers controlled by the TSF for integrity violations due to ageing and integrity check 15 on all objects, based on the 12 [assignment: integrity errors] 13 [assignment: user data attributes] 14 [assignment: action to be taken] 15 [assignment: integrity errors] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 53 / 129 following attributes: User data including code stored in the EEPROM 16 . FDP_SDI.2.2[FW] Upon detection of a data integrity error, the TSF shall indicate a data integrity error to the Security IC Embedded Software 17 . Dependencies: No dependencies. The (EEPROM integrity check operation of) P6021P VB shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as specified below. FDP_SDI.2[EEPROM] Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring FDP_SDI.2.1[EEPROM] The TSF shall monitor user data stored in containers controlled by the TSF for modification, deletion, repetition or loss of data 18 on all objects, based on the following attributes: parity bits of each byte in the EEPROM 19 . FDP_SDI.2.2[EEPROM] Upon detection of a data integrity error, the TSF shall correct 1-bit attack detectors in the EEPROM automatically and trigger a security reset for more-than- one-bit attack detectors 20 . Dependencies: No dependencies. The (RAM integrity check operation of) P6021P VB shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as specified below. FDP_SDI.2[RAM] Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring FDP_SDI.2.1[RAM] The TSF shall monitor user data stored in containers controlled by the TSF for modification, deletion, repetition or loss of data 21 on all objects, based on the following attributes: parity bits of each byte in the RAM 22 . FDP_SDI.2.2[RAM] Upon detection of a data integrity error, the TSF shall trigger a security reset 23 . Dependencies: No dependencies. The (ROM integrity check operation of) P6021P VB shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as specified below. FDP_SDI.2[ROM] Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring FDP_SDI.2.1[ROM] The TSF shall monitor user data stored in containers controlled by the TSF for modification, deletion, repetition or loss of data 24 on all objects, based on the following attributes: parity bits of each byte in the ROM 25 . FDP_SDI.2.2[ROM] Upon detection of a data integrity error, the TSF shall trigger a security reset 26 . 16 [assignment: user data attributes] 17 [assignment: action to be taken] 18 [assignment: integrity errors] 19 [assignment: user data attributes] 20 [assignment: action to be taken] 21 [assignment: integrity errors] 22 [assignment: user data attributes] 23 [assignment: action to be taken] 24 [assignment: integrity errors] 25 [assignment: user data attributes] 26 [assignment: action to be taken] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 54 / 129 Dependencies: No dependencies. The definition of the SFR FDP_SDC.1 is repeated in the following because the SFR is extended to the confidentiality operation of EEPROM and RAM. Based on the Data Processing Policy defined in PP [6] the SFR FDP_SDC.1 includes the requirement to ensure the confidentiality of the EEPROM and RAM data. The (EEPROM confidentiality operation of) P6021P VB shall meet the requirement “Stored data confidentiality (FDP_SDC.1)” as specified below. FDP_SDC.1[EEPROM] Stored data confidentiality Hierarchical to: No other components FDP_SDC.1.1[EEPROM] The TSF shall ensure the confidentiality of the information of the user data while it is stored in the EEPROM 27 . Dependencies: No dependencies. The (RAM confidentiality operation of) P6021P VB shall meet the requirement “Stored data confidentiality (FDP_SDC.1)” as specified below. FDP_SDC.1[RAM] Stored data confidentiality Hierarchical to: No other components FDP_SDC.1.1[RAM] The TSF shall ensure the confidentiality of the information of the user data while it is stored in the RAM 28 . Dependencies: No dependencies. The TOE shall meet the requirement "Cryptographic operation - TDES (FCS_COP.1[TDES])" as specified below. FCS_COP.1[TDES] Cryptographic operation - TDES Hierarchical to: No other components. 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 Cryptographic key destruction. FCS_COP.1.1[TDES] The TSF shall perform encryption and decryption 29 in accordance with a specified cryptographic algorithm TDES in ECB mode 30 and provide hardware support for CBC mode and cryptographic key sizes 112 or 168 bit 31 that meet the following NIST SP 800-67 [24], NIST SP 800-38A [25] 32 . Note: A complete ECB implementation of FCS_COP.1[TDES] requires actions of the IC Embedded Software Developer and the hardware support for the CBC mode of FCS_COP.1[TDES] is limited to encryption. Note: The cryptographic functionality FCS_COP.1[TDES] provided by the P6021P VB achieves a security level of maximum 80 Bits, if keying option 2 is used. Note: The security functionality is resistant against side channel analysis and similar techniques. To fend off attackers with high attack potential a security level of at least 80 Bits must be used. The TOE shall meet the requirement “Cryptographic key destruction – TDES (FCS_CKM.4[TDES])” as specified below. 27 [assignment: memory area] 28 [assignment: memory area] 29 [assignment: list of cryptographic operations] 30 [selection: ECB mode, CBC mode] 31 [assignment: cryptographic key sizes] 32 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 55 / 129 FCS_CKM.4[TDES] Cryptographic key destruction - TDES Hierarchical to: No other components. 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[TDES] The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method overwriting the internal stored key 33 that meets the following: none 34 . The TOE shall meet the requirement “Cryptographic operation - AES (FCS_COP.1[AES])” as specified below. FCS_COP.1[AES] Cryptographic operation - AES Hierarchical to: No other components. 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 Cryptographic key destruction. FCS_COP.1.1[AES] The TSF shall perform decryption and encryption 35 in accordance with a specified cryptographic algorithm AES in ECB mode 36 and provide hardware support for CBC mode and cryptographic key sizes 128, 192 or 256 bit 37 that meet the following: FIPS 197 [21], NIST SP 800-38A [25] 38 . Note: A complete ECB implementation of FCS_COP.1[AES] requires actions of the IC Embedded Software Developer and the hardware support for the CBC mode of FCS_COP.1[AES] is limited to encryption. The SFR FCS_COP.1[AES] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality and that is not disabled by PDC option. The TOE shall meet the requirement “Cryptographic key destruction (FCS_CKM.4[AES])” as specified below. FCS_CKM.4[AES] Cryptographic key destruction Hierarchical to: No other components. 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[AES] The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method overwriting the internal stored key 39 that meets the following: none 40 . The SFR FCS_CKM.4[AES] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. By this, all assignment/selection operations are performed. This Security Target does not perform any other/further operations than stated in [8]. 33 [assignment: cryptographic key destruction method] 34 [assignment: list of standards] 35 [assignment: list of cryptographic operations] 36 [selection: ECB mode, CBC mode] 37 [assignment: cryptographic key sizes] 38 [assignment: list of standards] 39 [assignment: cryptographic key destruction method] 40 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 56 / 129 Considering Application Note 12 of the PP [6] in the following paragraphs the additional functions for cryptographic support and access control are defined. These SFRs are not required by the PP [6]. As required by Application Note 14 of the PP [6] the secure state is described in the rationale for SF.OPC (see Security Target). Regarding Application Note 15 of the PP [6] generation of additional audit data is not defined for “Limited fault tolerance” (FRU_FLT.2) and “Failure with preservation of secure state” (FPT_FLS.1). As required by Application Note 19 of the PP [6] the automatic response of the P6021P VB is described in the rationale for SF.PHY (see Security Target). 6.1.1.2 Additional SFRs regarding cryptographic functionality Regarding on the PUF functionality, the following Security Functional Requirements (SFRs) are presented. The P6021P VB shall meet the requirements "Cryptographic key generation (FCS_CKM.1)" as specified below. FCS_CKM.1[PUF] Cryptographic key generation Hierarchical to: No other components. FCS_CKM.1.1[PUF] The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm key derivation function based on PUF 41 and specified cryptographic key sizes 128 bits 42 that meet the following: [20] 43 . Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction The SFR FCS_CKM.1[PUF] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. The P6021P VB shall meet the requirements "Cryptographic key destruction (FCS_CKM.4)" as specified below. FCS_CKM.4[PUF] Cryptographic key destruction Hierarchical to: No other components. FCS_CKM.4.1[PUF] The TSF shall destroy cryptographic keys derived by PUF block in accordance with a specified cryptographic key destruction method flushing of key registers 44 that meets the following: none 45 . 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] The SFR FCS_CKM.4[PUF] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. The P6021P VB shall meet the requirements "Cryptographic operation (FCS_COP.1)" as specified below. FCS_COP.1[PUF_AES] Cryptographic operation Hierarchical to: No other components. 41 [assignment:cryptographic key generation algorithm] 42 [assignment: cryptographic key sizes] 43 [assignment: list of standards] 44 [assignment: cryptographic key destruction method] 45 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 57 / 129 FCS_COP.1.1[PUF_AES] The TSF shall perform decryption and encryption 46 in accordance with a specified cryptographic algorithm AES in CBC mode 47 and cryptographic key size 128 bits 48 that meets the following: FIPS 197 [21], NIST SP 800-38A [25] 49 . 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 Cryptographic key destruction The SFR FCS_COP.1[PUF_AES] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. The P6021P VB shall meet the requirements "Cryptographic operation (FCS_COP.1)" as specified below. FCS_COP.1[PUF_MAC] Cryptographic operation Hierarchical to: No other components. FCS_COP.1.1[PUF_MAC] The TSF shall perform CBC-MAC used for calculation of a PUF authentication in accordance with a specified cryptographic algorithm AES in CBC-MAC 50 and cryptographic key size 128 bit 51 that meet the following: FIPS 197 [21], NIST Special Publication 800-38A [25] and ISO/IEC 9797-1 (MAC algorithm 1) [27] 52 . 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 Cryptographic key destruction. The SFR FCS_COP.1[PUF_MAC] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. 6.1.1.3 Additional SFRs regarding access control Access Control Policy The hardware shall provide different CPU modes to IC Dedicated Support Software and Security IC Embedded Software for separating the code and data of these two domains. The separation shall be supported by the partitioning of memories. Management of access to code and data as well as access to hardware resources shall be assigned to dedicated CPU modes. The hardware shall enforce separation between different applications (i.e. parts of the Security IC Embedded Software) running on the P6021P VB. The P6021P VB shall support this based on the CPU modes and the segmentation of the memories. The P6021P VB shall support secure operation on Special Function Register depending on register functionality or on the CPU mode. In addition an application shall not be able to access hardware components unless permission is granted explicitly. The hardware shall provide direct memory access for the Security IC Embedded Software without CPU interactions realized by a copy machine. The copy machine shall support different CPU modes and the segmentation of the memories. The Security Function Policy (SFP) Access Control Policy uses the following definitions. The subjects are 46 [assignment: list of cryptographic operations] 47 [assignment: cryptographic algorithm] 48 [assignment: cryptographic key sizes] 49 [assignment: list of standards] 50 [assignment: cryptographic algorithm] 51 [assignment: cryptographic key sizes] 52 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 58 / 129 • The Security IC Embedded Software i.e. data in the memories of the P6021P VB executed as instructions by the CPU • The Test-ROM Software as IC Dedicated Test Software, executed as instructions by the CPU • The Boot-ROM Software as part of the IC Dedicated Support Software, executed as instructions by the CPU • The Firmware Operating System as part of the IC Dedicated Support Software including the resource configuration firmware executed as instructions by the CPU and stored data integrity monitoring for EEPROM write accesses of the Security IC Embedded Software. • The Firmware Firewall configured by the IC Dedicated Support Software for restricted access of the Firmware Operating System to the hardware related Special Function Registers and separation between IC Dedicated Support Software and Security IC Embedded Software • The copy machine configured by the Security IC Embedded Software for direct memory access enforcing separation between different CPU modes and the segmentation of memories • The Fame2 coprocessor configured by the Security IC Embedded Software for implementation of asymmetric cryptographic algorithms and direct memory access to the FXRAM for accessing operands and storing resulting data. The objects are • the memories consisting of – ROM, which is partitioned into Test-ROM and Application-ROM – EEPROM, which is partitioned into two parts. To simplify referencing, the part reserved for the Firmware Operating System is called Firmware-EEPROM, the other part Application-EEPROM. – RAM, which is partitioned into two parts. To simplify referencing, the part reserved for the Firmware Operating System is called Firmware-RAM, the other part Application- RAM. – The code and data in the Memory Segments defined by the Memory Management Unit in Application-ROM, Application-EEPROM and Application-RAM. Note that this memory is a subset of the first three. • The virtual memory locations within the three memories that are used by the CPU and are mapped to physical addresses by the Memory Management Unit. • The physical memory locations within the three memories that are used by the Memory Management Unit for the MMU Segment Table. • The Special Function Registers consisting of – Special Function Registers to configure the MMU segmentation. This group contains the registers that define the pointer to the MMU Segment Table. – Special Function Registers related to system management, a number of Special Function Registers that are intended to be used for overall system management by the operating system. – Special Function Registers to configure the Firmware firewall. These Special Function Registers allow modifying the Firmware firewall regarding data exchange and Special Function Register access control. – Special Function Registers used by the Firmware Operating System including the resource configuration firmware. The Firmware Operating System uses a number of internal Special Function Registers. – Special Function Registers related to testing. These Special Function Registers are reserved for testing purposes. – Special Function Registers related to hardware components. These Special Function Registers are used to utilise hardware components like the coprocessors or the interrupt system. – Special Function Registers related to general CPU functionality. This group contains e.g. the accumulator, stack pointer and data pointers. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 59 / 129 – Special Function Registers related to general CPU functionality are implemented separately for System and User Mode. This group contains CPU watch exception register for System and User Mode. • The Firmware Firewall configured during bootflow that separates memories of Firmware Operating System from Security IC Embedded Software. The memory operations are • read data from the memory, • write data into the memory and • execute data stored in the memory. The Special Function Register operations are • read data from a Special Function Register and • write data into a Special Function Register. The security attributes are • CPU mode: There are five CPU modes that are sequentially active based on the configuration of Special Function Registers defining whether the instruction is executed in Boot Mode, Test Mode, Firmware Mode, System Mode or User Mode. • The values of the Special Function Registers to configure the MMU segmentation and Special Function Registers related to system management. These groups contain the pointer to the MMU Segment Table and those relevant for the overall system management of the P6021P VB. • MMU Segment Table: Configuration of the Memory Segments comprising access rights (read, write and execute), the virtual code memory base address of the first and last valid address, and the relocation offset of the physical memory location for each of the 64 possible Memory Segments. For every segment also the access rights to the Special Function Registers related to hardware components are defined. • The values of the Special Function Registers MMU_FWCTRLL, MMU_FWCTRLH, MMU_MXBASL, MMU_MXBASH, MMU_MXSZL and MMU_MXSZH belonging to the group Special Function Registers related to hardware components that define the access rights to the Special Function Registers related to hardware components for code executed in Firmware Mode and the RAM area used for data exchange between IC Dedicated Support Software (Firmware Operating System including resource configuration firmware) and Security IC Embedded Software. In the following the term “code running” combined with a CPU mode (e.g. “code running in System Mode”) is used to name subjects. Note: Use of a Memory Segment is disabled in case no access permissions are granted. It is not necessary to define all 64 possible Memory Segments, the Memory Management Unit is capable of managing an arbitrary number of segments up to the limit of 64. The P6021P VB shall meet the requirements “Subset access control (FDP_ACC.1)” as specified below. FDP_ACC.1[MEM] Subset access control Hierarchical to: No other components. FDP_ACC.1.1[MEM] The TSF shall enforce the Access Control Policy 53 on all code running on the TOE, all memories and all memory operations 54 . Dependencies: FDP_ACF.1 Security attribute based access control Application Note: The Access Control Policy shall be enforced by implementing a Memory Management Unit, which maps virtual addresses to physical addresses. The CPU always uses virtual addresses, which are mapped to physical addresses by the Memory Management Unit. 53 [assignment: access control SFP] 54 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 60 / 129 Prior to accessing the respective memory address, the Memory Management Unit checks if the access is allowed. FDP_ACC.1[SFR] Subset access control Hierarchical to: No other components. FDP_ACC.1.1[SFR] The TSF shall enforce the Access Control Policy 55 on all code running on the TOE, all Special Function Registers, and all Special Function Register operations 56 . Dependencies: FDP_ACF.1 Security attribute based access control Application Note: The Access Control Policy shall be enforced by implementing hardware access control to each Special Function Register. For every access the CPU mode is used to determine if the access shall be granted or denied. In addition, in User Mode and Firmware Mode the access rights to the Special Function Registers related to hardware components are provided by the MMU Segment Table and the Special Function Registers to configure the Firmware firewall. A denied read or write access triggers an exception. The read and/or write access to a Special Function Register may be not allowed depending on the function of the register or on the CPU mode to enforce the access control policy or ensure a secure operation. The P6021P VB shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified below. FDP_ACF.1[MEM] Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1[MEM] The TSF shall enforce the Access Control Policy 57 to objects based on the following: all subjects and objects and the attributes CPU mode, the MMU Segment Table, the Special Function Registers to configure the MMU segmentation and the Special Function Registers related to system management. 58 . FDP_ACF.1.2[MEM] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: Code executed in the Boot Mode • has read and execute access to all code/data in the Test-ROM • has read, write and execute access to all code/data in the Firmware-EEPROM • has read and write access to all data in the Firmware- RAM Code executed in the Test Mode • has read and execute access to all code/data in the whole ROM • has read, write and execute access to all code/data in the whole EEPROM 55 [assignment: access control SFP] 56 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 57 [assignment: access control SFP] 58 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP- relevant security attributes, or named groups of SFP-relevant security attributes] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 61 / 129 • has read and write access to all data in the whole RAM Code executed in the Firmware Mode • has read and execute access to its own code/data in the Firmware-ROM, • has read and write access to all code/data in the whole EEPROM for data integrity control during EEPROM write operations and read, write and execute access to the Firmware EEPROM for other purpose controlled by the Firmware Firewall, • has read and write access to all data in the Firmware- RAM Code executed in the System Mode • has read and execute access to all code/data in the Application-ROM • has read, write and execute access to all code/data in the Application-EEPROM, • has read and write access to all data in the Application-RAM Code executed in the User Mode • has read and/or execute access to code/data in the Application-ROM controlled by the MMU Segment Table used by the Memory Management Unit, • has read and/or write and/or execute access to code/data in the Application-EEPROM controlled by the MMU Segment Table used by the Memory Management Unit, • has read and/or write access to data in the Application- RAM controlled by the MMU Segment Table used by the Memory Management Unit 59 . FDP_ACF.1.3[MEM] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: Code running in Firmware Mode has access to the Application- RAM defined by the Special Function Register MMU_MXBASL, MMU_MXBASH, MMU_MXSZL and MMU_MXSZH. Code running in Boot Mode or Firmware Mode has read access to the Security Rows stored in the Application-EEPROM. Code running in Firmware Mode when called from System Mode has read and write access to the Application-EEPROM for data integrity control reasons during EEPROM write operations. The Fame2 coprocessor has read/write access to the FXRAM 60 . FDP_ACF.1.4[MEM] The TSF shall explicitly deny access of subjects to objects based on the following additional rules: if configured code executed in EEPROM cannot read ROM, if configured the copy machine cannot read ROM, if configured the copy machine cannot read EEPROM 61 . Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation 59 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 60 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 61 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 62 / 129 FDP_ACF.1[SFR] Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1[SFR] The TSF shall enforce the Access Control Policy 62 to objects based on the following: all subjects and objects and the attributes CPU mode, the MMU Segment Table and the Special Function Registers MMU_FWCTRLL and MMU_FWCTRLH 63 . FDP_ACF.1.2[SFR] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: • The code executed in Boot Mode is allowed to access all Special Function Register groups except Special Function Registers related to testing, Special Function Registers to configure the MMU segmentation and Special Function Registers related to general CPU functionality implemented separately for System and User Mode. • The code executed in Test Mode is allowed to access all Special Function Register groups except Special Function Registers to configure the MMU segmentation and Special Function Registers related to general CPU functionality implemented separately for System and User Mode. • The code executed in Firmware Mode is allowed to read Special Function Registers to configure the Firmware firewall and to read/write Special Function Registers used by the Firmware Operating System and the resource configuration firmware. Access to Special Function Registers related to hardware components is based on the access rights determined by the Special Function Registers MMU_FWCTRLL and MMU_FWCTRLH. • The code executed in System Mode is allowed to access Special Function Registers to configure the MMU segmentation, Special Function Registers related to system management, Special Function Registers to configure the Firmware firewall and Special Function Registers related to hardware components. • The code executed in the User Mode is allowed to access Special Function Registers related to hardware components based on the access rights defined in the respective Memory Segment in the MMU Segment Table from which the code is actually executed 64 . Application Note: Copy Machine continues operation in the CPU mode in which it has been started independent of any CPU mode changes initiated by the Security IC Embedded Software during copy machine operation. FDP_ACF.1.3[SFR] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: In any CPU mode access to the Special Function Registers related to general CPU functionality, except 62 [assignment: access control SFP] 63 [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] 64 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 63 / 129 those implemented separately for System and User Mode, is allowed. In System and User Mode access to the Special Function Registers related to general CPU functionality implemented separately for System and User Mode is allowed. The Special Function Register CPU_CSR belonging to group Special Function Registers related to system management is additionally readable in Firmware Mode and User Mode. The Special Function Register CFG_CLKSEL of the group Special Function Registers related to hardware components can be read in the Firmware Mode regardless of the Firmware firewall settings given by MMU_FWCTRLL and MMU_FWCTRLH. 65 FDP_ACF.1.4[SFR] The TSF shall explicitly deny access of subjects to objects based on the following additional rules: Access to Special Function Registers to configure the MMU segmentation is denied in all CPU modes except System Mode. Access to Special Function Registers related to general CPU functionality implemented separately for System and User Mode is denied in Boot, Test and Firmware Mode. The Special Function Register MMU_RPT2 of the group Special Function Registers related to system management is not readable. The Special Function Register RNG_RNR of the group Special Function Registers related to hardware components is read-only. The Special Function Registers SBC_KEY used as key registers for AES and Triple-DES coprocessors of the group Special Function Registers related to hardware components are not readable. 66 Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation 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 functionality. • Code executed in Boot Mode or Test Mode is quite powerful and used to configure and test the P6021P VB. • Code executed in Firmware Mode is separated from code executed in System Mode or User Mode. The separation is enforced by the partition of the memories provided by the Memory Management Unit. Only small memory areas are used for data exchange between the Firmware Operating System and the Security IC Embedded Software. Furthermore, the exchange area in RAM is fully controlled by code running in System Mode. The EEPROM data integrity function executed in Firmware Mode has access to the whole EEPROM area to guarantee data integrity for EEPROM write operations. The MIFARE Software only has access to a separated dedicated area in the EEPROM. Separation is realized by means of a Firmware Firewall. • Code executed in the System Mode can administrate the configuration of Memory Management Unit, because it has access to the respective Special Function Registers. Configuration means that the code can change the address of the MMU Segment Table and also modify the contents of it (as long as the table is located in write-able memory). • Code executed in the User Mode cannot administrate the configuration of the Memory Management Unit, because it has no access to the Special Function Registers to 65 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 66 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 64 / 129 configure the MMU segmentation. Therefore changing the pointer to the MMU Segment Table is not possible. • It may be possible for User Mode code to modify the MMU Segment Table contents if the table itself is residing in a memory location that is part of a Memory Segment that the code has write access to. The P6021P VB shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below. FMT_MSA.3[MEM] Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1[MEM] The TSF shall enforce the Access Control Policy 67 to provide restrictive 68 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[MEM] The TSF shall allow no subject 69 to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles Application Note: Restrictive means here that the reset values of the Special Function Register regarding the address of the MMU Segment Table are set to zero, which effectively disables any memory segment so that no User Mode code can be executed by the CPU. Furthermore, the memory partition cannot be configured at all. The TOE does not provide objects or information that can be created, since it provides access to memory areas. The definition of objects that are stored in the TOE’s memory is subject to the Security IC Embedded Software. FMT_MSA.3[SFR] Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1[SFR] The TSF shall enforce the Access Control Policy 70 to provide restrictive 71 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[SFR] The TSF shall allow no subject 72 to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles Application Note: The TOE does not provide objects or information that can be created since no further security attributes can be derived (i.e. the set of Special Function Registers that contain security attributes is fixed). The definition of objects that are stored in the TOE’s memory is subject to the Security IC Embedded Software. The P6021P VB shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified below. FMT_MSA.1[MEM] Management of security attributes Hierarchical to: No other components. 67 [assignment: access control SFP, information flow control SFP] 68 [selection: choose one of: restrictive, permissive, [assignment: other property]] 69 [assignment: the authorised identified roles] 70 [assignment: access control SFP, information flow control SFP] 71 [selection: choose one of: restrictive, permissive, [assignment: other property]] 72 [assignment: the authorised identified roles] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 65 / 129 FMT_MSA.1.1[MEM] The TSF shall enforce the Access Control Policy 73 to restrict the ability to modify 74 the security attributes Special Function Registers to configure the MMU segmentation 75 to code executed in the System Mode 76 . Dependencies: [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 Application Note: The MMU Segment Table is not included in this requirement because it is located in the memory of the TOE and access to it is possible for every role that has access to the respective memory locations. This component does not include any management functionality for the configuration of the memory partition. This is because the memory partition is fixed and cannot be changed after TOE delivery. FMT_MSA.1[SFR] Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1[SFR] The TSF shall enforce the Access Control Policy 77 to restrict the ability to modify 78 the security attributes defined in Special Function Registers 79 to code executed in a CPU mode which has write access to the respective Special Function Registers. 80 . Dependencies: [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 The P6021P VB shall meet the requirement “Specification of Management Functions (FMT_SMF.1)” as specified below. FMT_SMF.1[HW] Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1.1[HW] The TSF shall be capable of performing the following management functions: Change of the CPU mode by calling a system call vector (SVEC) or firmware vector (FVEC) address, change of the CPU mode by invoking an exception or interrupt, change of the CPU mode by finishing an exception/interrupt (with a RETI instruction), change of the CPU mode with a special LCALL/ACALL/ECALL address, change of the CPU mode by writing to the respective bits in the CPU_CSR Special Function Register and modification of the Special Function Registers containing security attributes, and modification of the MMU Segment Table, and temporary disabling and enabling of the security functionality EEPROM Size, CXRAM Size, AES coprocessor, Fame2 coprocessor and permanent disabling and enabling of the security functionality EEPROM Size, CXRAM Size, AES coprocessor, Fame2 73 [assignment: access control SFP(s), information flow control SFP(s)] 74 [selection: change_default, query, modify, delete, [assignment: other operations]] 75 [assignment: list of security attributes] 76 [assignment: the authorised identified roles] 77 [assignment: access control SFP(s), information flow control SFP(s)] 78 [selection: change_default, query, modify, delete, [assignment: other operations]] 79 [assignment: list of security attributes] 80 [assignment: the authorised identified roles] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 66 / 129 coprocessor and permanent disabling and enabling of the security functionality MIFARE Software and MIFARE Software EEPROM size 81 . Dependencies: No dependencies Application Note: The iteration of FMT_MSA.1 with the dependency to FMT_SMF.1[HW] may imply a separation of the Specification of Management Functions. All management functions rely on the same features implemented in the hardware. Note that the access control policy defined above also depends on the major configuration of the TOE, refer to Section 1.4.2. 6.1.1.4 Mapping of Security Functional Requirements to evaluated configurations of P6021P VB All the evaluated configurations of P6021P VB fulfil the Security Functional Requirements of P6021P VB which are presented in Section 6.1. 6.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The SFRs of the P6021M VB/P6021D VB/P6021J VB include the SFRs of the P6021P VB. In addition, the P6021M VB/P6021D VB/P6021J VB includes the Security Functional Requirements (SFRs) of the MIFARE Software, which are presented in the following sections. 6.1.2.1 Additional SFRs for the MIFARE Plus MF1PLUSx0 The following policy and security functional requirements can only be provided by the P6021M VB and P6021J VB if the MIFARE Plus MF1PLUSx0 software is called by the Security IC Embedded Software. The subjects and objects described in the following policy are dedicated for the MIFARE Plus MF1PLUSx0 software emulation. MFP Access Control Policy The Security Function Policy (SFP) "MFP Access Control Policy" uses the following definitions: The subjects are • The Personaliser who can personalise the P6021M VB and P6021J VB in security level 0. • The Card Administrator who can change security attributes which cannot be changed in the field. • The Card Manager who can change security attributes in the field. • The Card Security Level Manager who can switch the card to a higher security level. • The Card User who can perform operations with blocks. • The Originality Key User who can authenticate himself to prove the authenticity of the Security IC. Note that multiple subjects may have the same role, e.g. for every sector there are two Card Users (identified by the respective “Key A” and “Key B” for this sector). The assigned rights to the Card Users can be different, which allows having more or less powerful Card Users. There are also more than one Originality Key User and Card Security Level Manager. Any other subject belongs to the role Anybody which is not modelled explicitly in the policy because no access rights are granted to this role. This role includes the card holder (i.e. end-user) and any other subject e.g. an attacker. 81 [assignment: list of management functions to be provided by the TSF] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 67 / 129 The objects are • Blocks that are grouped in sectors. (Each sector consists of either 4 or 16 blocks. One block of each sector contains the access conditions and is called sector trailer. One specific type of data stored in a block is a value.) • Cryptographic keys (for a list of all cryptographic keys see [14], ch. 5.5). The operations that can be performed with the objects are • read data from a block • write data to a block, • increase, decrease, transfer or restore a value, • change a cryptographic key. The security attributes are (see [14] for further details) • the MFP Configuration Block, • the Field Configuration Block, • the sector trailer for a sector and • the Security Level of the P6021M VB and P6021J VB. The operations that can be performed with the security attributes are • read the MFP Configuration Block, the Field Configuration Block and the sector trailer • modify the MFP Configuration Block, the Field Configuration Block and the sector trailer • switch the security level. The MIFARE Plus MF1PLUSx0 software shall respect the following rules: • Nobody is allowed to read data from block 0 (first block of the first sector) or to write data to block 0 • Nobody is allowed to change the originality key • The Personaliser is allowed to write data to all blocks (except block 0) • The Personaliser is allowed to modify the MFP Configuration Block, the Field Configuration Block and the sector trailers. • In Security Level 0 the Personaliser is allowed to switch the Security Level to Security Level 1 • The Personaliser is allowed to change all cryptographic keys (except the originality key) • For every sector the Card User is allowed to read data from a block or to write data to a block, to increase, decrease, transfer or restore a value if the access conditions in the corresponding sector trailer grants him this right. • The Card Administrator is allowed to modify the MFP Configuration Block • The Card Administrator is allowed to change the Card Master Key • In Security Level 2 the Card Administrator is allowed to change the Level 3 Switch Key • The Card Manager is allowed to modify the Field Configuration Block • The Card Manager is allowed to change the Card Configuration Key • In Security Level 1 or 2 the Card Security Level Manager is allowed to switch the Security Level of the P6021M VB and P6021J VB to a higher Security Level. • The Card User is allowed to read and to modify the sector trailer if the access conditions in the corresponding sector trailer grants him this right. • The Card User is allowed to change the AES Sector Keys if the access conditions in the corresponding sector trailer grants him this right. • The Originality Key User is not allowed to perform any operation on objects. Note that subjects are authorised by cryptographic keys by using the authenticate operation. These keys are considered as authentication data and not as security attributes of the subjects. The P6021M VB and P6021J VB stores a dedicated cryptographic key for every subject. The key of the Card Administrator is called “Card Master Key” and the key for the Card Manager is called “Card Configuration Key”. The Card Security Level Manager keys are called “Level 2 Switch Key” and “Level 3 Switch NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 68 / 129 Key”. The keys of the Card Users are called “AES Sector Keys”. Since there are two keys for every sector the keys are called “AES Sector Key A” and “AES Sector Key B” or in short “Key A” and “Key B”. The keys of the Originality Key User are called “Originality Keys”. The additional SFRs for the MIFARE Plus MF1PLUSx0 software include the iteration indicator “[MFP]” to clearly mark that they are only applicable for the MIFARE Plus MF1PLUSx0 software. The additional SFRs for the MIFARE Plus MF1PLUSx0 software are only to be considered in case the TOE configuration indeed provides the SFR- requested functionality. The P6021M VB and P6021J VB shall meet the requirements “Subset access control (FDP_ACC.1)” as specified below. FDP_ACC.1[MFP] Subset access control Hierarchical to: No other components. FDP_ACC.1.1[MFP] The TSF shall enforce the MFP Access Control Policy 82 on subjects, objects, operations and security attributes as defined in the MFP Access Control Policy 83 . Dependencies: FDP_ACF.1 Security attribute based access control The P6021M VB and P6021J VB shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified below. FDP_ACF.1[MFP] Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1[MFP] The TSF shall enforce the MFP Access Control Policy 84 to objects based on the following: all subjects, objects and security attributes 85 . FDP_ACF.1.2[MFP] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: as defined for the operations within the rules specified in the MFP Access Control Policy 86 . FDP_ACF.1.3[MFP] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none 87 . FDP_ACF.1.4[MFP] The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none 88 . Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation Implications of the MFP Access Control Policy The MFP 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 not belong to the group of authorised users (Personaliser, Card Administrator, Card Manager, Card Security Level Manager, Card User, Originality Key User), but is regarded as 'Anybody' by the P6021M VB and P6021J VB. This means that the P6021M VB and P6021J VB 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 Personaliser is very powerful, although the role is limited to Security Level 0. 82 [assignment: access control SFP] 83 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 84 [assignment: access control SFP] 85 [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] 86 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 87 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 88 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 69 / 129 • Switching of the security level is an integral part of the TOE security. The P6021M VB/ P6021D VB/P6021J VB is switched from security level 0 to security level 1 at the end of the personalisation phase. The security level can be increased by the Card Security Level Manager afterwards. The P6021M VB and P6021J VB shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below. FMT_MSA.3[MFP] Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1[MFP] The TSF shall enforce the MFP Access Control Policy 89 to provide permissive 90 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[MFP] The TSF shall allow no subject 91 to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles The P6021M VB and P6021J VB shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified below. FMT_MSA.1[MFP] Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1[MFP] The TSF shall enforce the MFP Access Control Policy 92 to restrict the ability to modify 93 the security attributes MFP Configuration Block, Field Configuration Block, security level and sector trailers 94 to the Card Administrator, Card Manager, Card Security Level Manager and Card User, respectively 95 . Dependencies: [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 The P6021M VB and P6021J VB shall meet the requirement “Specification of Management Functions (FMT_SMF.1)” as specified below. FMT_SMF.1[MFP] Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1.1[MFP] The TSF shall be capable of performing the following management functions: Authenticate a user, Invalidating the current authentication state based on the functions: Issuing a request for authentication, Occurrence of any error during the execution of a command, Reset, Switching the security level of the TOE, DESELECT according to ISO 14443-3, explicit authentication reset; Finishing the personalisation phase by explicit request of the Personaliser, Modifying a security attribute, Selection and Deselection of the Virtual Card 96 . Dependencies: No dependencies 89 [assignment: access control SFP, information flow control SFP] 90 [selection, choose one of: restrictive, permissive, [assignment: other property]] 91 [assignment: the authorised identified roles] 92 [assignment: access control SFP(s), information flow control SFP(s)] 93 [selection: change_default, query, modify, delete, [assignment: other operations]] 94 [assignment: list of security attributes] 95 [assignment: the authorised identified roles] 96 [assignment: list of management functions to be provided by the TSF] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 70 / 129 The P6021M VB and P6021J VB shall meet the requirement “Security roles (FMT_SMR.1)” as specified below. FMT_SMR.1[MFP] Security roles Hierarchical to: No other components. FMT_SMR.1.1[MFP] The TSF shall maintain the roles Personaliser, Card Administrator, Card Manager, Card Security Level Manager, Card User and Originality Key User 97 . FMT_SMR.1.2[MFP] The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1 Timing of identification The P6021M VB and P6021J VB shall meet the requirements “Import of user data with security attributes (FDP_ITC.2)” as specified below. FDP_ITC.2[MFP] Import of user data with security attributes Hierarchical to: No other components. FDP_ITC.2.1[MFP] The TSF shall enforce the MFP Access Control Policy 98 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2[MFP] The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3[MFP] The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. FDP_ITC.2.4[MFP] 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. FDP_ITC.2.5[MFP] The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: no additional rules 99 . 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] FPT_TDC.1 Inter-TSF basic TSF data consistency The P6021M VB and P6021J VB shall meet the requirement “Inter-TSF basic TSF data consistency (FPT_TDC.1)” as specified below. FPT_TDC.1[MFP] Inter-TSF basic TSF data consistency Hierarchical to: No other components. FPT_TDC.1.1[MFP] The TSF shall provide the capability to consistently interpret data blocks 100 when shared between the TSF and another trusted IT product. FPT_TDC.1.2[MFP] The TSF shall use the rules: data blocks can always be modified by the write operation. If a data block is in the value format it can be modified by all dedicated value-specific operations honouring the value-specific boundaries. Sector trailers must have a specific format 101 when interpreting the TSF data from another trusted IT product. Dependencies: No dependencies. Application Note: The TOE does not interpret the contents of the data, e.g. it cannot determine if data stored in a specific block is an 97 [assignment: the authorised identified roles] 98 [assignment: access control SFP(s) and/or information flow control SFP(s)] 99 [assignment: additional importation control rules] 100 [assignment: list of TSF data types] 101 [assignment: list of interpretation rules to be applied by the TSF] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 71 / 129 identification number that adheres to a specific format. Instead the TOE distinguishes different types of blocks and ensures that type-specific boundaries cannot be violated, e.g. values do not overflow. For sector trailers the TOE enforces a specific format. The P6021M VB and P6021J VB shall meet the requirement “User identification before any action (FIA_UID.2)” as specified below. FIA_UID.2[MFP] User identification before any action Hierarchical to: FIA_UID.1 FIA_UID.2.1[MFP] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions implemented by the MIFARE Plus MF1PLUSx0 software on behalf of that user. Dependencies: No dependencies. Application Note: Identification of a user is performed upon an authentication request based on the key block number. For example, if an authentication request for key number 0x9000 is issued after selecting the Card, the user is identified as the Card Administrator. The P6021M VB and P6021J VB shall meet the requirement “User authentication before any action (FIA_UAU.2)” as specified below. FIA_UAU.2[MFP] User authentication before any action Hierarchical to: FIA_UAU.1 FIA_UAU.2.1[MFP] The TSF shall require each user to be successfully authenticated before allowing any other TSF- mediated actions implemented by the MIFARE Plus MF1PLUSx0 software on behalf of that user. Dependencies: FIA_UID.1 Timing of identification The P6021M VB and P6021J VB shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)” as specified below. FIA_UAU.5[MFP] Multiple authentication mechanisms Hierarchical to: No other components. FIA_UAU.5.1[MFP] The TSF shall provide ‘none’ and cryptographic authentication 102 to support user authentication. FIA_UAU.5.2[MFP] The TSF shall authenticate any user's claimed identity according to the following rules: • The 'none' authentication is performed with anyone who communicates with the TOE in Security Level 0. The 'none' authentication implicitly and solely authenticates the Personaliser. • The cryptographic authentication is used in Security Level 0 to authenticate the Originality Key User. • The cryptographic authentication is used in Security Level 1 to authenticate the Originality Key User and the Card Security Level Manager. • The cryptographic authentication is used in Security Level 2 to authenticate the Originality Key User, the Card Administrator, the Card Manager and the Card Security Level Manager. • The cryptographic authentication is used in Security Level 3 to authenticate the Originality Key User, the 102 [assignment: list of multiple authentication mechanisms] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 72 / 129 Card Administrator, the Card Manager and the Card User 103 . Dependencies: No dependencies Refinement: For the applied cryptographic operation please refer to FCS_COP.1[MFP_AES]. The P6021M VB and P6021J VB shall meet the requirement “Trusted path (FTP_TRP.1)” as specified below. FTP_TRP.1[MFP] Trusted path Hierarchical to: No other components. FTP_TRP.1.1[MFP] The TSF shall provide a communication path between itself and remote 104 users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from modification and disclosure or only modification 105 . FTP_TRP.1.2[MFP] The TSF shall permit remote users 106 to initiate communication via the trusted path. FTP_TRP.1.3[MFP] The TSF shall require the use of the trusted path for authentication requests, confidentiality and integrity protected data transfers or integrity protected data transfers, which are based on a setting in the MFP Configuration Block and the Sector Trailers 107 . Dependencies: No dependencies. Refinement: The TOE supports a variety of commands for reading and writing to the TOE, each with their own properties regarding integrity and confidentiality for the command and response part. With the MFP Configuration Block and the Sector Trailers it can be configured which commands are available (e.g. to enforce confidential transfer for specific blocks). Note that for any writing operation integrity verification is always enforced by the TOE and that for writing of cryptographic keys and security attributes confidentiality is always enforced by the TOE. For other operations, the requirements and recommendations of [18] are to be followed to ensure integrity protected or both confidentiality and integrity protected data transfers, depending on the needs of the application. The P6021M VB and P6021J VB shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as specified below. FCS_CKM.4[MFP] Cryptographic key destruction Hierarchical to: No other components. FCS_CKM.4.1[MFP] The TSF shall destroy cryptographic keys used by the MIFARE Plus MF1PLUSx0 software in accordance with a specified cryptographic key destruction method overwriting of memory 108 that meets the following: none 109 . 103 [assignment: rules describing how the multiple authentication mechanisms provide authentication] 104 [selection: remote, local] 105 [selection: modification, disclosure, [assignment: other types of integrity or confidentiality violation]] 106 [selection: the TSF, local users, remote users] 107 [selection: initial user authentication,[assignment: other services for which trusted path is required]] 108 [assignment: cryptographic key destruction method] 109 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 73 / 129 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] The P6021M VB and P6021J VB shall meet the requirement “Replay detection (FPT_RPL.1)” as specified below. FPT_RPL.1[MFP] Replay detection Hierarchical to: No other components. FPT_RPL.1.1[MFP] The TSF shall detect replay for the following entities: authentication requests, confidentiality and integrity protected data transfers or integrity protected data transfers, which are based on a setting in the MFP Configuration Block and the Sector Trailers 110 . FPT_RPL.1.2[MFP] The TSF shall perform rejection of the request 111 when replay is detected. Dependencies: No dependencies. Refinement: The TOE supports a variety of commands for reading and writing to the TOE, each with their own properties regarding integrity and confidentiality, and thus replay, for the command and response part. With the MFP Configuration Block and the Sector Trailers it can be configured which commands are available (e.g. to enforce integrity protected commands which cannot be replayed). Note that for any writing operation, integrity verification is always enforced by the TOE, including the detection of replay. For other operations, the requirements and recommendations of [18] are to be followed to ensure integrity protected or both confidentiality and integrity protected data transfers, including replay detection, depending on the needs of the application. The P6021M VB and P6021J VB shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1[MFP_AES] Cryptographic operation Hierarchical to: No other components. FCS_COP.1.1[MFP_AES] The TSF shall perform encryption, decryption and cipher-based MAC 112 used by the MIFARE Plus MF1PLUSx0 software for authentication and communication in accordance with the specified cryptographic algorithm AES inCBC mode, CMAC 113 and cryptographic key sizes of 128 bit 114 that meet the following: FIPS 197 [21], NIST SP 800-38A [25] and NIST SP 800-38B (CMAC mode) [26] 115 . 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 Cryptographic key destruction. 110 [assignment: list of identified entities] 111 [assignment: list of specific actions] 112 [assignment: list of cryptographic operations] 113 [assignment: cryptographic algorithm] 114 [assignment: cryptographic key sizes] 115 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 74 / 129 Refinement: MIFARE Plus MF1PLUSx0 uses the cryptographic algorithm for CBC according to NIST Special Publication 800-38A (CBC mode) [25] with the following modification: MIFARE Plus MF1PLUSx0 does not use an unpredictable IV instead it uses a constructed IV which is partially predictable. The SFR FCS_COP.1[MFP_AES] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. 6.1.2.2 Additional SFRs for the MIFARE DESFire EV1 The following policy and security functional requirements can only be provided by the P6021D VB and P6021J VB if the MIFARE DESFire EV1 software is called by the Security IC Embedded Software. The subjects and objects described in the following policy are dedicated for the DESFire Emulation. DESFire Access Control Policy The Security Function Policy (SFP) "DESFire 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 P6021D VB and P6021J VB 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 an application key that allows to perform operations with application objects. Note that the P6021D VB and P6021J VB 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 cannot perform operations that are restricted to the Administrator, Application Manager and Application User. • The Originality Key User who can authenticate himself to prove the authenticity of the Security IC. • The term Nobody will be used to explicitly indicate that no rights are granted to any subject. The objects are • The DESFire card level data itself. The DESFire card level is the lowest level of the MIFARE DESFire EV1 software (card level, application level, file level). On the DESFire card level applications can be created or deleted. • The MIFARE DESFire EV1 software can store a number of Applications. • An application can store a number of Data Files of different types. • One specific type of a data file is a Value. • Cryptographic keys (see [15], ch. 6.1.4 and ch. 6.1.6.). 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), NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 75 / 129 • decrease a value, • create an application, a value or a data file, • delete an application, a value or a data file, • change / freeze a cryptographic key. The security attributes are • Attributes of the DESFire card level, applications, values and data files. There is a set of attributes for the DESFire card level, 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 DESFire card level. The term "application attributes" will be used for the set of application attributes. The term "file attributes" will be used for the attributes of values and data files. The operations that can be performed with the security attributes are • modify, • freeze will be used as specific form of modify (freezing prevents any further modification of an attribute). The MIFARE DESFire EV1 software shall respect the following rules: • The Administrator is allowed to create and delete applications. • The Application Manager of an application is allowed to create and delete data files and values within this application. • The Application User is allowed to read or write a data file, to read, increase or decrease a value, if the access conditions in the corresponding file attribute grants him this right. • The Application Manager of an application is allowed to delete this application if this is allowed by a specific card attribute. • Everybody is allowed to create and delete data files or values of a specific application if this is allowed by a specific application attribute. • Everybody is allowed to read or write a data file, to read, increase or decrease a value if this is allowed by a specific file attribute. • Nobody is allowed to read or write a data file, to read, increase or decrease a value if this is explicitly set in the file attributes for the respective operation on the respective data file or value. • The Originality Key User is not allowed to perform any operation on objects. • Only the Administrator is allowed to modify or freeze the card attributes. • Only the Application Manager is allowed to modify or freeze the application attributes. • Only the Application Manager is allowed to modify or freeze the file attributes. • The Application Manager is allowed to transfer the modify ability of the file attributes to the Application User, Everybody or Nobody. The restriction to Nobody is equivalent to freezing the file attributes. • The Application User, Everybody or Nobody is allowed to modify the file attributes only if he gets these abilities transferred from the Application Manager. • Nobody is allowed to change the originality key. • The Administrator is allowed to change or freeze the card master key. • The Administrator is allowed to change the default key that is used as the application master key and for the application keys when an application is created. • The Application Manager of an application is allowed to change or freeze the application master key of the application assigned to him. • The Application Manager is allowed to transfer the change ability of the application keys to the Application User, Everybody or Nobody. The restriction to Nobody is equivalent to freezing the application key. • The Application User, Everybody or Nobody is allowed to change the application key only if he gets these abilities transferred from the Application Manager. • The Application Users can either change their own keys, when granted the right by the Application Manager, or one Application User can be defined by the Application NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 76 / 129 Manager that can change all keys of the Application Users within an application. The Application Manager is allowed to define an Application User who is allowed to change all application keys of the multiple Application Users within an application. Note that subjects are authorized by cryptographic keys. These keys are considered as authentication data and not as security attributes of the subjects. The DESFire card level 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 additional SFRs for the MIFARE DESFire EV1 software include the iteration indicator "[DF]" to clearly mark that they are only applicable for the MIFARE DESFire EV1 software. The additional SFRs for the MIFARE DESFire EV1 software are only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. The P6021D VB and P6021J VB shall meet the requirements "Subset access control (FDP_ACC.1)" as specified below. FDP_ACC.1[DF] Subset access control Hierarchical to: No other components. FDP_ACC.1.1[df] The TSF shall enforce the DESFire Access Control Policy 116 on subjects, objects, operations and security attributes as defined in the DESFire Access Control Policy 117 . Dependencies: FDP_ACF.1 Security attribute based access control Application Note: The DESFire Access Control Policy is related to the data maintained by the MIFARE DESFire EV1 Software. The P6021D VB and P6021J VB shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified below. FDP_ACF.1[DF] Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1[DF] The TSF shall enforce the DESFire Access Control Policy 118 to objects based on the following: all subjects, objects and security attributes 119 . FDP_ACF.1.2[DF] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: as defined for the operations within the rules specified in the DESFire Access Control Policy 120 . FDP_ACF.1.3[DF] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none 121 . FDP_ACF.1.4[DF] The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none 122 . Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation Implications of the DESFire Access Control Policy The DESFire Access Control Policy has some implications, that can be drawn from the policy and that are essential parts of the TOE security functions. 116 [assignment: access control SFP] 117 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 118 [assignment: access control SFP] 119 [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] 120 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 121 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 122 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 77 / 129 • The TOE end-user does not belong to the group of authorized users (Administrator, Application Manager, Application User, Originality Key User), but regarded as 'Everybody' by the P6021D VB and P6021J VB. This means that the P6021M VB/ P6021D VB/P6021J VB cannot determine if it is used by its intended end-user (in other words: it cannot determine if the current user is the owner of the Security IC). • The Administrator has the exclusive right to create and delete applications on the DESFire card level, however he can also grant this privilege to Everybody. 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. The P6021D VB and P6021J VB shall meet the requirement "Static attribute initialization (FMT_MSA.3)" as specified below. FMT_MSA.3[DF] Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1[DF] The TSF shall enforce the DESFire Access Control Policy 123 to provide permissive 124 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[DF] The TSF shall allow no subject 125 to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles The P6021D VB and P6021J VB shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified below. FMT_MSA.1[DF] Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1[DF] The TSF shall enforce the DESFire Access Control Policy 126 to restrict the ability to modify or freeze 127 the security attributes card attributes, application attributes and file attributes to the Administrator, Application Manager and Application User, or Everybody 128 tothe Card Administrator, Card Manager, Card Security Level Manager and Card User, respectively 129 . Dependencies: [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 The P6021D VB and P6021J VB shall meet the requirement “Specification of Management Functions (FMT_SMF.1)” as specified below. FMT_SMF.1[DF] Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1.1[DF] The TSF shall be capable of performing the following management functions: Authenticate a user, Invalidating the current authentication state based on the functions: 123 [assignment: access control SFP, information flow control SFP] 124 [selection, choose one of: restrictive, permissive, [assignment: other property]] 125 [assignment: the authorised identified roles] 126 [assignment: access control SFP(s), information flow control SFP(s)] 127 [selection: change_default, query, modify, delete, [assignment: other operations]] 128 [assignment: list of security attributes] 129 [assignment: the authorised identified roles] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 78 / 129 Selecting an application or the DESFire card level, 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 130 . Dependencies: No dependencies The P6021D VB and P6021J VB shall meet the requirements “Security roles (FMT_SMR.1)” as specified below. FMT_SMR.1[DF] Security roles Hierarchical to: No other components. FMT_SMR.1.1[DF] The TSF shall maintain the roles Administrator, Application Manager, Application User, Everybody and Originality Key User 131 . FMT_SMR.1.2[DF] The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1 Timing of identification The P6021D VB and P6021J VB shall meet the requirement “Import of user data with security attributes (FDP_ITC.2)” as specified below. FDP_ITC.2[DF] Import of user data with security attributes Hierarchical to: No other components. FDP_ITC.2.1[DF] The TSF shall enforce the DESFire Access Control Policy 132 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2[DF] The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3[DF] The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. FDP_ITC.2.4[DF] 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. FDP_ITC.2.5[DF] The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: no additional rules 133 . 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] FPT_TDC.1 Inter-TSF basic TSF data consistency The P6021D VB and P6021J VB shall meet the requirement “Inter-TSF basic TSF data consistency (FPT_TDC.1)” as specified below. FPT_TDC.1[DF] Inter-TSF basic TSF data consistency Hierarchical to: No other components. FPT_TDC.1.1[DF] The TSF shall provide the capability to consistently interpret data files and values 134 when shared between the TSF and another trusted IT product. FPT_TDC.1.2[DF] The TSF shall use the rule: data files or values can only be modified by their dedicated type-specific 130 [assignment: list of management functions to be provided by the TSF] 131 [assignment: the authorised identified roles] 132 [assignment: access control SFP(s) and/or information flow control SFP(s)] 133 [assignment: additional importation control rules] 134 [assignment: list of TSF data types] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 79 / 129 operations honoring the type-specific boundaries 135 when interpreting the TSF data from another trusted IT product. Dependencies: No dependencies. Note: The TOE does not interpret the contents of the data, e.g. it cannot 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 cannot be violated, e.g. values do not overflow, single records are limited by their size and cyclic records are handled correctly. The P6021D VB and P6021J VB shall meet the requirement “User identification before any action (FIA_UID.2)” as specified below. FIA_UID.2[DF] User identification before any action Hierarchical to: FIA_UID.1 FIA_UID.2.1[DF] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions implemented by the MIFARE DESFire EV1 software on behalf of that user. Dependencies: No dependencies. Application Note: Identification of a user is performed upon an authentication request based on the currently selected context and the key number. For example, if an authentication request for key number 0 is issued after selecting a specific application, the user is identified as the Application Manager of the respective application. Before any authentication request is issued the user is identified as ‘Everybody’. The P6021D VB and P6021J VB shall meet the requirement “User authentication before any action (FIA_UAU.2)” as specified below. FIA_UAU.2[DF] User authentication before any action Hierarchical to: FIA_UAU.1 FIA_UAU.2.1[DF] The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions implemented by the MIFARE DESFire EV1 software on behalf of that user. Dependencies: FIA_UID.1 Timing of identification The P6021D VB and P6021J VB shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)” as specified below. FIA_UAU.5[DF] Multiple authentication mechanisms Hierarchical to: No other components. FIA_UAU.5.1[DF] The TSF shall provide ‘none’ and cryptographic authentication 136 to support user authentication. FIA_UAU.5.2[DF] The TSF shall authenticate any user's claimed identity according to the following rules: • The ‘none’ authentication is performed with anyone who communicates with the TOE without issuing an explicit authentication request. The ‘none’ 135 [assignment: list of interpretation rules to be applied by the TSF] 136 [assignment: list of multiple authentication mechanisms] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 80 / 129 authentication implicitly and solely authorizes the ‘Everybody’ subject. • The cryptographic authentication is used to authorize the Administrator, Application Manager, Application User and Originality Key User 137 . Dependencies: No dependencies. Refinement: For the applied cryptographic operation please refer to FCS_COP.1[DF_AES] and FCS_COP.1[DF_TDES]. The P6021D VB and P6021J VB shall meet the requirement “Trusted path (FTP_TRP.1)” as specified below. FTP_TRP.1[DF] Trusted path Hierarchical to: No other components. FTP_TRP.1.1[DF] The TSF shall provide a communication path between itself and remote 138 users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from modification and disclosure or only modification 139 . FTP_TRP.1.2[DF] The TSF shall permit remote users 140 to initiate communication via the trusted path. FTP_TRP.1.3[DF] The TSF shall require the use of the trusted path for authentication requests with 3-key Triple-DES or AES, confidentiality and integrity protected data transfers with AES or integrity protected data transfers with AES, which are based on a setting in the file attributes 141 . Dependencies: No dependencies. Refinement: The TOE supports three communication modes for file data depending on the file attribute setting (see [15]) • The TOE supports three communication modes for file data depending on the file attribute setting (see [15]) • “Fully enciphered communication”: supports integrity verification and confidentiality for data transfers with AES; • “Plain communication secured by MACing”: supports integrity verification with AES; and, • “Plain communication”: does not support integrity verification or confidentiality. Please note that “Plain communication” is not protected and hence not covered by FTP_TRP.1[DF]. The P6021D VB and P6021J VB shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as specified below. FCS_CKM.4[DF] Cryptographic key destruction Hierarchical to: No other components. FCS_CKM.4.1[DF] The TSF shall destroy cryptographic keys used by the MIFARE DESFire EV1 software in accordance with a specified cryptographic key destruction method 137 [assignment: rules describing how the multiple authentication mechanisms provide authentication] 138 [selection: remote, local] 139 [selection: modification, disclosure, [assignment: other types of integrity or confidentiality violation]] 140 [selection: the TSF, local users, remote users] 141 [selection: initial user authentication,[assignment: other services for which trusted path is required]] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 81 / 129 overwriting of memory 142 that meets the following: none 143 . 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] The P6021D VB and P6021J VB shall meet the requirement “Basic rollback (FDP_ROL.1)” as specified below. FDP_ROL.1[DF] Basic rollback Hierarchical to: No other components. FDP_ROL.1.1[DF] The TSF shall enforce DESFire Access Control Policy 144 to permit the rollback of the operations that modify the value or data file objects 145 on the backup files 146 . FDP_ROL.1.2[DF] The TSF shall permit operations to be rolled back within the scope of the current transaction, which is defined by the following limitative events: chip reset, (re-)authentication (either successful or not), select command, explicit commit, explicit abort, command failure 147 . Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] The P6021D VB and P6021J VB shall meet the requirement “Replay detection (FPT_RPL.1)” as specified below. FPT_RPL.1[DF] Replay detection Hierarchical to: No other components. FPT_RPL.1.1[DF] The TSF shall detect replay for the following entities: authentication requests with 3-key Triple-DES or AES, confidentiality and integrity protected data transfers with AES or integrity protected data transfers with AES, which are based on a setting in the file attributes 148 . FPT_RPL.1.2[DF] The TSF shall perform rejection of the request 149 when replay is detected. Dependencies: No dependencies. Refinement: The TOE supports three communication modes for file data depending on the file attribute setting (see [15]) • “Fully enciphered communication”: supports integrity verification and confidentiality for data transfers with AES; • “Plain communication secured by MACing”: supports integrity verification with AES; and, • “Plain communication”: does not support integrity verification or confidentiality. Please note that replay protection is only supported on commands performed in “Fully enciphered communication” or “Plain communication secured 142 [assignment: cryptographic key destruction method] 143 [assignment: list of standards] 144 [assignment: access control SFP(s) and/or information flow control SFP(s)] 145 [assignment: list of operations] 146 [assignment: information and/or list of objects] 147 [assignment: boundary limit to which rollback may be performed] 148 [assignment: list of identified entities] 149 [assignment: list of specific actions] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 82 / 129 by MACing”. Commands performed in “Plain communication” are not protected against replay. The P6021D VB and P6021J VB shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1[DF_AES] Cryptographic operation Hierarchical to: No other components. FCS_COP.1.1[DF_AES] The TSF shall perform encryption, decryption and cipher-based MAC 150 used by the MIFARE DESFire EV1 software for authentication and communication in accordance with a specified cryptographic algorithm AES in CBC mode, CMAC 151 and cryptographic key sizes 128 bit 152 that meet the following: FIPS 197 [21], NIST SP 800-38A [25] and NIST SP 800-38B (CMAC mode) [26] 153 . 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 Cryptographic key destruction. Refinement: MIFARE DESFire EV1 uses the cryptographic algorithm for CMAC according to NIST Special Publication 800-38B (CMAC mode) [26] with the following modification: MIFARE DESFire EV1 does not use the standard zero byte IV instead it uses an IV defined by the previous cryptographic operation (chaining mode). The SFR FCS_COP.1[DF_AES] is only to be considered in case the TOE configuration indeed provides the SFR-requested functionality. The P6021D VB and P6021J VB shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1[DF_TDES] Cryptographic operation - TDES Hierarchical to: No other components. FCS_COP.1.1[DF_TDES] The TSF shall perform encryption and decryption 154 used by the MIFARE DESFire EV1 software for authentication in accordance with a specified cryptographic algorithm TDES in CBC mode 155 and cryptographic key sizes 168 bit 156 that meet the following NIST SP 800-67 [24], NIST SP 800-38A [25] 157 . 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 Cryptographic key destruction. 150 [assignment: list of cryptographic operations] 151 [assignment: cryptographic algorithm] 152 [assignment: cryptographic key sizes] 153 [assignment: list of standards] 154 [assignment: list of cryptographic operations] 155 [assignment: cryptographic algorithm] 156 [assignment: cryptographic key sizes] 157 [assignment: list of standards] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 83 / 129 6.1.2.3 Mapping of Security Functional Requirements to evaluated configurations P6021M VB/P6021D VB/P6021J VB The following table provides a mapping between the SFRs and the evaluated configurations P6021M VB/P6021D VB/P6021J VB. Table 27. Mapping of Security Functional Requirements to evaluated configurations P6021M VB/P6021D VB/P6021J VB M P 2 M P 4 M C 1 M C 4 D 2 D 4 D 8 D 1 6 D 2 4 D 3 2 M P 2/ D 2 M P 4/ D 2 M P 2/ D 4 M P 4/ D 4 M P 2/ D 8 M P 4/ D 8 M P 2/ D 1 6 M P 4/ D 1 6 M P 2/ D 2 4 M P 4/ D 2 4 M P 2/ D 3 2 M P 4/ D 3 2 M C 1/ D 2 M C 4/ D 2 M C 1/ D 4 M C 4/ D 4 M C 1/ D 8 M C 4/ D 8 M C 1/ D 1 6 M C 4/ D 1 6 M C 1/ D 2 4 M C 4/ D 2 4 M C 1/ D 3 2 M C 4/ D 3 2 FCS_COP.1[MFP_AES] x x x x x x x x x x x x x x FDP_ACC.1[MFP] x x x x x x x x x x x x x x FDP_ACF.1[MFP] x x x x x x x x x x x x x x FMT_MSA.1[MFP] x x x x x x x x x x x x x x FMT_MSA.3[MFP] x x x x x x x x x x x x x x FMT_SMF.1[MFP] x x x x x x x x x x x x x x FMT_SMR.1[MFP] x x x x x x x x x x x x x x FDP_ITC.2[MFP] x x x x x x x x x x x x x x FPT_TDC.1[MFP] x x x x x x x x x x x x x x FIA_UID.2[MFP] x x x x x x x x x x x x x x FIA_UAU.2[MFP] x x x x x x x x x x x x x x FIA_UAU.5[MFP] x x x x x x x x x x x x x x FTP_TRP.1[MFP] x x x x x x x x x x x x x x FCS_CKM.4[MFP] x x x x x x x x x x x x x x FPT_RPL.1[MFP] x x x x x x x x x x x x x x FCS_COP.1[DF_AES] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FCS_COP.1[DF_TDES] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FDP_ACC.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FDP_ACF.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FMT_MSA.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FMT_MSA.3[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FMT_SMF.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FMT_SMR.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FDP_ITC.2[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FPT_TDC.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FIA_UID.2[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FIA_UAU.2[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FIA_UAU.5[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FTP_TRP.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FCS_CKM.4[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FPT_RPL.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x FDP_ROL.1[DF] x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 84 / 129 6.1.3 Comparison of SFRs of the P6021P VB and P6021M VB/P6021D VB/P6021J VB Table 28 shows the comparison between the SFRs of the P6021P VB and P6021M VB/ P6021D VB/P6021J VB, and their Evaluation Assurance Level. Table 28. Comparison of SFRs of the P6021P VB and P6021M VB/P6021D VB/P6021J VB Major configuration SFRs of the TSF EAL6+ evaluation P6021P VB (plain configuration, no MIFARE software available) • All SFRs from PP [6], see Table 26, • SFRs which do not depend on the availability of AES, i.e., FCS_COP.1[TDES], FCS_CKM.4[TDES], FDP_ACC.1[MEM], FDP_ACC.1[SFR], FDP_ACF.1[MEM], FDP_ACF.1[SFR], FMT_MSA.3[MEM], FMT_MSA.3[SFR], FMT_MSA.1[MEM], FMT_MSA.1[SFR], FMT_SMF.1[HW], • SFRs which depend on the availability of PUF (can be deactivated by minor configuration; AES is mandatory): FCS_CKM.1[PUF], FCS_CKM.4[PUF], FCS_COP.1[PUF_AES], FCS_COP.1[PUF_MAC], • and SFRs which depend on the availability of AES (can be blocked via PDC), i.e., FCS_COP.1[AES], FCS_CKM.4[AES]. EAL5+ evaluation P6021M VB (MIFARE Plus available) • See P6021P VB, • SFRs which depend on the availability of MIFARE Plus (MP2 or MP4, see Section 1.4.2.2.2.1) (can be blocked or set to MIFARE Classic via minor configuration; AES is mandatory), i.e., FDP_ACC.1[MFP], FDP_ACF.1[MFP], FMT_MSA.3[MFP], FMT_MSA.1[MFP], SMT_SMF.1[MFP], FMR_SMR.1[MFP], FDP_ITC.2[MFP], FPT_TDC.1[MFP], FIA_UID.2[MFP], FIA_UAU.2[MFP], FIA_UAU.5[MFP], FTP_TRP.1[MFP], FCS_CKM.4[MFP], FPT_RPL.1[MFP], FCS_COP.1[MFP_AES]. P6021D VB (MIFARE DESFire available) • See P6021P VB, • SFRs which depend on the availability of MIFARE DESFire (can be blocked via minor configuration, AES is mandatory), i.e., FTP_TRP.1[DF], FPT_RPL.1[DF], FCS_COP.1[DF_AES], FDP_ACC.1[DF], FDP_ACF.1[DF], FMT_MSA.3[DF], FMT_MSA.1[DF], FMT_SMF.1[DF], FMT_SMR.1[DF], FDP_ITC.2[DF], FPT_TDC.1[DF], FIA_UID.2[DF], FIA_UAU.2[DF], FIA_UAU.4[DF], FCS_CKM.4[DF], FDP_ROL.1[DF], FCS_COP.1[DF_TDES]. P6021J VB (MIFARE Plus and MIFARE DESFire available) • See P6021P VB, • See P6021M VB, • See P6021D VB. 6.2 Security Assurance Requirements 6.2.1 NXP Secure Smart Card Controller P6021P VB (EAL6+) Table 29 lists all security assurance components that are valid for the P6021P VB. With two exceptions, Table 29 lists all security assurance components that are required by EAL6 (see Section 2.2) or by the PP "Security IC Platform Protection Profile" [6]. The exceptions are the components ASE_TSS.2 and ALC_FLR.1. ASE_TSS.2 is chosen as an augmentation to give architectural information on the security functionality of the P6021P VB. ALC_FLR.1 is chosen as an augmentation in this Security Target to cover policies and procedures of the developer applied to track and correct flaws and support surveillance of the P6021P VB. Considering Application Note 22 of [6] the column "Required by" shows the differences in the requirements of security assurance components between the PP [6] and the Security Target for the P6021P VB. The entry "EAL6 / PP" denotes, that an SAR is required by both EAL6 and the requirement of the PP [6], "EAL6" means that this requirement is due to EAL6 and beyond the requirement of the PP [6], and "PP" identifies this component NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 85 / 129 as a requirement of the PP which is beyond EAL6. The augmentations ASE_TSS.2, ALC_FLR.1 are denoted by "EAL6+". The refinements of the PP [6], which must be adapted for EAL6, are described in Section 6.2.1.1. Table 29. Security Assurance Requirements for EAL6+ SAR Title Required by ADV_ARC.1 Security architecture description EAL6 / PP ADV_FSP.5 Complete semi-formal functional specification with additional error information EAL6 ADV_IMP.2 Complete mapping TDS vs. Implementation EAL6 / PP ADV_INT.3 Entire design well structured EAL6 ADV_TDS.5 Semiformal description of all modules EAL6 ADV_SPM.1 Formal model of Security Policies EAL6 AGD_OPE.1 Operational user guidance EAL6 / PP AGD_PRE.1 Preparative procedures EAL6 / PP ALC_CMC.5 Production support, acceptance procedures and automation EAL6 ALC_CMS.5 Development tools CM coverage EAL6 ALC_DEL.1 Delivery procedures EAL6 / PP ALC_DVS.2 Sufficiency of security measures PP ALC_FLR.1 Basic flaw remediation EAL6+ ALC_LCD.1 Developer defined life-cycle model EAL6 / PP ALC_TAT.3 Standards used by 3rd party providers EAL6 ASE_CCL.1 Conformance claims EAL6 / PP ASE_ECD.1 Extended components definition EAL6 / PP ASE_INT.1 ST introduction EAL6 / PP ASE_OBJ.2 Security objectives EAL6 / PP ASE_REQ.2 Derived security requirements EAL6 / PP ASE_SPD.1 Security problem definition EAL6 / PP ASE_TSS.2 TOE summary specification with architectural design summary EAL6+ ATE_COV.3 All interfaces completely tested EAL6 / PP ATE_DPT.3 Testing: modular design EAL6 ATE_FUN.2 Functional testing, Analysis of test sequence EAL6 ATE_IND.2 Independent testing - sample EAL6 / PP AVA_VAN.5 Advanced methodical vulnerability analysis PP 6.2.1.1 Refinements of the Security Assurance Requirements for EAL6+ The Security Target for the P6021P VB claims strict conformance to the PP [6] and therefore it has to conform to the refinements of the TOE security assurance requirements (see Application Note 23 in [6]). The refinements in the PP [6] are defined for the security assurance components of EAL4+. It needs to be checked if refinements are necessary for assurance components of the higher level EAL6 claimed in the Security Target. Table 30 lists the refinements of the PP [6] for the P6021P VB. Most of the refined security assurance components have the same level in both documents (PP [6] and Security Target). The following five subsections apply the refinements to ALC_CMS.5, NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 86 / 129 ALC_CMC.5, ADV_FSP.5, ADV_IMP.2 and ATE_COV.3 which are different for the PP [6] and the Security Target for the P6021P VB. Table 30. Security Assurance Requirements, overview of differences of refinements Refined in PP [6] Effect on Security Target for EAL6 ALC_DEL Same as in PP, refinement valid without change ALC_DVS Same as in PP, refinement valid without change ALC_CMS ALC_CMS.5, refinements valid without change ALC_CMC ALC_CMC.5, refinement valid without change ADV_ARC Same as in PP, refinement valid without change ADV_FSP ADV_FSP.5, refinements have to be adapted ADV_IMP ADV_IMP.2, refinement valid without change ATE_COV ATE_COV.3, refinement valid without change AGD_OPE Same as in PP, refinement valid without change AGD_PRE Same as in PP, refinement valid without change AVA_VAN Same as in PP, refinement valid without change [1] [1] According to Application Note 29 in the PP [6] the Security Target should indicate the version of the document [5] used for the vulnerability analysis. The current version is given in the bibliography. The further Security Assurance Requirements especially the further augmentations added in this Security Target compared with the Protection Profile supplement and extent the Security Assurance Requirements and can be added without contradictions. 6.2.1.1.1 Refinements regarding CM scope (ALC_CMS) The Security Target for the P6021P VB requires a higher evaluation level for the CC family ALC_CMS, namely ALC_CMS.5 instead of ALC_CMS.4. The refinement of the PP [6] regarding ALC_CMS.4 is a clarification of the configuration item “TOE implementation representation”. Since in ALC_CMS.5, the content and presentation of evidence element ALC_CMS.5.1C only adds an additional configuration item to the list of items to be tracked by the CM system, the refinement can be applied without changes. The refinement of the configuration item “TOE implementation representation” of ALC_CMS.4 can be found in section 6.2.1.3 of PP [6] and is not quoted here. 6.2.1.1.2 Refinements regarding CM capabilities (ALC_CMC) The Security Target for the P6021P VB requires a higher evaluation level for the CC family ALC_CMC, namely ALC_CMC.5 instead of ALC_CMC.4. The refinement of the PP [6] regarding ALC_CMC.4 is a clarification of the “TOE” and the term "configuration items". Since in ALC_CMC.5 requires a higher assurance regarding the defined TOE and the configuration items, the refinement can be applied without changes. The refinements of the terms “TOE” and "configuration items" of ALC_CMC.4 can be found in section 6.2.1.4 of PP[6] and is not quoted here. 6.2.1.1.3 Refinements regarding functional specification (ADV_FSP) The Security Target for the P6021P VB requires a higher assurance level for the CC family ADV_FSP, namely ADV_FSP.5 instead of ADV_FSP.4. The refinement of the PP [6] regarding ADV_FSP.4 addresses the complete representation of the TSF, the purpose and method of use of all TSFI, and the accuracy and completeness of the SFR instantiations. The refinement is not a change in the wording of the action elements, but a more detailed definition of the items above is applied. The higher level ADV_FSP.5 requires a Functional Specification in a “semi-formal style" (ADV_FSP.5.2C). NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 87 / 129 The component ADV_FSP.5 extends the scope of the error messages to be described from those resulting from an invocation of a TSFI (ADV_FSP.5.6C) to also those not resulting from an invocation of a TSFI (ADV_FSP.5.7C). For the latter a rationale shall be provided (ADV_FSP.5.8C). Since the higher level ADV_FSP.5 only affects the style of description and the scope of and rationale for error messages, the refinements can be applied without changes and are valid for ADV_FSP.5. The refinement of the original component ADV_FSP.4 can be found in Section 6.2.1.6 of the Protection Profile [6] and is not quoted here. 6.2.1.1.4 Refinements regarding Implementation Representation (ADV_IMP.2) The refinement of the PP [6], section 6.2.1.7, regarding Implementation Representation states that the provided implementation representation is complete and sufficient to ensure that analysis activities are not curtailed due to lack of information. This Security Target requires assurance level EAL6 augmented which requires access to complete source code. Therefore the refinement of the PP [6] is implicitly fulfilled. 6.2.1.1.5 Refinements regarding Test Coverage (ATE_COV.3) Both refinements defined in the PP [6], section 6.2.1.8, regarding Test Coverage are applied without change. The refinements defining test coverage under different operating conditions and proof of existence and effectiveness of countermeasures against physical attacks. As this Security Target requires assurance level EAL6 augmented the latter refinement can be applied without change and can be fulfilled by access to complete source code and layout data. The refinement of test coverage under different operating conditions is not a change in the wording of the action elements, but a more detailed definition of the items above to be applied and therefore can be applied without changes. 6.2.1.2 Definition of ADV_SPM The developer shall provide a formal security policy model for the Capability/Availability Policy and the Access Control Policy 158 . The Access Control Policy comprises the following Security Functional Requirements: FDP_ACC.1[MEM], FDP_ACC.1[SFR], FDP_ACF.1[MEM], FDP_ACF.1[SFR], FMT_MSA.3[MEM], FMT_MSA.3[SFR], FMT_MSA.1[MEM], FMT_MSA.1[SFR], and FMT_SMF.1[HW]. Also access control related behavior of FAU_SAS.1[HW] and FDP_SDI.2[HW] is modeled. Further the reset behavior as required by FRU_FLT.2, FPT_FLS.1, FDP_SDC.1[EEPROM], FDP_SDC.1[RAM], FDP_SDI.2[EEPROM], FDP_SDI.2[RAM], FDP_SDI.2[ROM], and FPT_PHP.3 is included in the security policy model. Limited availability as defined in FMT_LIM.2 is modeled. 6.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB (EAL5+) Table 31 lists all security assurance components that are valid for the Security Target for the P6021M VB/P6021D VB/P6021J VB. With one exception, Table 31 lists all security assurance components that are required by EAL5 (see Section 2.2) or by the PP "Security IC Platform Protection Profile" [6]. The exception is the component ASE_TSS. The component ASE_TSS is chosen as an augmentation to give architectural information on the security functionality of the P6021M VB/P6021D VB/P6021J VB. Considering Application Note 22 of [6] the column "Required by" shows the differences in the requirements of security assurance components between the PP [6] and the Security Target. The entry "EAL5 / PP" denotes, that an SAR is required by both EAL5 and the 158 [assignment: list of policies that are formally modeled]. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 88 / 129 PP [6], "EAL5" means that this requirement is due to EAL5 and beyond the requirement of the PP [6], and "PP" identifies this component as a requirement of the PP which is beyond EAL5. The augmentations ALC_DVS.2, ASE_TSS.2 and AVA_VAN.5 are denoted by "EAL5+" or "EAL5+ / PP" respectively. The refinements of the PP [6], which must be adapted for EAL5, are described in Section 6.2.2.1. Table 31. Security Assurance Requirements for EAL5+ SAR Title Required by ADV_ARC.1 Security architecture description EAL5 / PP ADV_FSP.5 Complete semi-formal functional specification with additional error information EAL5 ADV_IMP.1 Implementation representation of the TSF EAL5 / PP ADV_INT.2 Well-structured internals EAL5 ADV_TDS.4 Semiformal modular design EAL5 AGD_OPE.1 Operational user guidance EAL5 / PP AGD_PRE.1 Preparative procedures EAL5 / PP ALC_CMC.4 Production support, acceptance procedures and automation EAL5 / PP ALC_CMS.5 Development tools CM coverage EAL5 ALC_DEL.1 Delivery procedures EAL5 / PP ALC_DVS.2 Sufficiency of security measures EAL5+ / PP ALC_LCD.1 Developer defined life-cycle model EAL5 / PP ALC_TAT.2 Compliance with implementation standards EAL5 ASE_CCL.1 Conformance claims EAL5 / PP ASE_ECD.1 Extended components definition EAL5 / PP ASE_INT.1 ST introduction EAL5 / PP ASE_OBJ.2 Security objectives EAL5 / PP ASE_REQ.2 Derived security requirements EAL5 / PP ASE_SPD.1 Security problem definition EAL5 / PP ASE_TSS.2 TOE summary specification with architectural design summary EAL5+ ATE_COV.2 Analysis of coverage EAL5 / PP ATE_DPT.3 Testing: modular design EAL5 ATE_FUN.1 Functional testing EAL5 / PP ATE_IND.2 Independent testing - sample EAL5 / PP AVA_VAN.5 Advanced methodical vulnerability analysis EAL5+ / PP 6.2.2.1 Refinements of the Security Assurance Requirements for EAL5+ The Security Target for the P6021M VB/P6021D VB/P6021J VB claims strict conformance to the PP [6] and therefore it has to conform to the refinements of the TOE security assurance requirements (see Application Note 23 in [6]). The refinements in the PP [6] are defined for the security assurance components of EAL4+. It needs to be checked if refinements are necessary for assurance components of the higher level EAL5+ claimed in the Security Target for the P6021M VB/P6021D VB/P6021J VB. Table 32 lists the refinements of the PP [6] for the Security Target for the P6021M VB/ P6021D VB/P6021J VB. Most of the refined security assurance components have the same level in both documents (PP [6] and the Security Target). The following two subsections apply the refinements to ALC_CMS.5 and ADV_FSP.5 which are different for the PP [6] and the Security Target. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 89 / 129 Table 32. Security Assurance Requirements, overview of differences of refinements Refined in PP [6] Effect on Security Target for EAL5 ALC_DEL Same as in PP, refinement valid without change ALC_DVS Same as in PP, refinement valid without change ALC_CMS ALC_CMS.5, refinements valid without change ALC_CMC Same as in PP, refinement valid without change ADV_ARC Same as in PP, refinement valid without change ADV_FSP ADV_FSP.5, refinement valid without change ADV_IMP Same as in PP, refinement valid without change ATE_COV Same as in PP, refinement valid without change AGD_OPE Same as in PP, refinement valid without change AGD_PRE Same as in PP, refinement valid without change AVA_VAN Same as in PP, refinement valid without change [1] [1] According to Application Note 30 in the PP [6] the Security Target should indicate the version of the document [5] used for the vulnerability analysis. The current version is given in the bibliography. The further Security Assurance Requirements especially the further augmentations added in this Security Target compared with the Protection Profile supplement and extent the Security Assurance Requirements and can be added without contradictions. 6.2.2.1.1 Refinements regarding CM scope (ALC_CMS) The Security Target for the P6021M VB/P6021D VB/P6021J VB requires a higher evaluation level for the CC family ALC_CMS, namely ALC_CMS.5 instead of ALC_CMS.4. The refinement of the PP [6] regarding ALC_CMS.4 is a clarification of the configuration item “TOE implementation representation”. Since in ALC_CMS.5, the content and presentation of evidence element ALC_CMS.5.1C only adds an additional configuration item to the list of items to be tracked by the CM system, the refinement can be applied without changes. The refinement of the configuration item “TOE implementation representation” of ALC_CMS.4 can be found in section the PP 6.2.1.3 of [6] and is not quoted here. 6.2.2.1.2 Refinements regarding functional specification (ADV_FSP) The Security Target for the P6021M VB/P6021D VB/P6021J VB requires a higher assurance level for the CC family ADV_FSP, namely ADV_FSP.5 instead of ADV_FSP.4. The refinement of the PP [6] regarding ADV_FSP.4 addresses the complete representation of the TSF, the purpose and method of use of all TSFI, and the accuracy and completeness of the SFR instantiations. The refinement is not a change in the wording of the action elements, but a more detailed definition of the items above is applied. The higher level ADV_FSP.5 requires a Functional Specification in a “semi-formal style" (ADV_FSP.5.2C). The component ADV_FSP.5 extends the scope of the error messages to be described from those resulting from an invocation of a TSFI (ADV_FSP.5.6C) to also those not resulting from an invocation of a TSFI (ADV_FSP.5.7C). For the latter a rationale shall be provided (ADV_FSP.5.8C). Since the higher level ADV_FSP.5 only affects the style of description and the scope of and rationale for error messages, the refinements can be applied without changes and are valid for ADV_FSP.5. The refinement of the original component ADV_FSP.4 can be found in Section 6.2.1.6 of the Protection Profile [6] and is not quoted here. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 90 / 129 6.3 Security Requirements Rationale 6.3.1 Rationale for the Security Functional Requirements 6.3.1.1 NXP Secure Smart Card Controller P6021P VB Section 6.3.1 in the PP [6] provides a rationale for the mapping between security functional requirements and security objectives defined in the PP [6]. The mapping is reproduced in Table 33. Table 33. Security Requirements versus Security Objectives Objective Security Functional Requirements of P6021P VB O.Leak-Inherent FDP_ITT.1 'Basic internal transfer protection' FPT_ITT.1 'Basic internal TSF data transfer protection' FDP_IFC.1 'Subset information flow control' O.Phys-Probing FDP_SDC.1[EEPROM], FDP_SDC.1[RAM] FPT_PHP.3 O.Malfunction FRU_FLT.2 “Limited fault tolerance” FPT_FLS.1 “Failure with preservation of secure state” O.Phys-Manipulation FDP_SDI.2[EEPROM], FDP_SDI.2[RAM], FDP_SDI.2[ROM] FPT_PHP.3 O.Leak-Forced All requirements listed for O.Leak-Inherent FDP_ITT.1, FPT_ITT.1, FDP_IFC.1 plus those listed for O.Malfunction and O.Phys-Manipulation FRU_FLT.2, FPT_FLS.1, FPT_PHP.3 O.Abuse-Func FMT_LIM.1 “Limited capabilities” FMT_LIM.2 “Limited availability” plus those for O.Leak-Inherent, O.Phys- Probing, O.Malfunction, O.Phys-Manipulation, O.Leak-Forced FDP_ITT.1, FPT_ITT.1, FDP_IFC.1, FPT_PHP.3, FRU_FLT.2, FPT_FLS.1 O.Identification FAU_SAS.1[HW] “Audit storage” O.RND FCS_RNG.1[HW] “Quality metric for random numbers” plus those for O.Leak- Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation, O.Leak- Forced FDP_ITT.1, FPT_ITT.1, FDP_IFC.1, FPT_PHP.3, FRU_FLT.2, FPT_FLS.1 The Security Target for the P6021P VB extends SFR defined in the PP [6] and additionally defines SFRs as listed in Table 34. The table gives an overview, how the requirements are combined to meet the security objectives. Table 34. Mapping of security objectives and requirements Objective Security Functional Requirements of P6021P VB O.TDES FCS_COP.1[TDES], FCS_CKM.4[TDES] O.AES FCS_COP.1[AES], FCS_CKM.4[AES] O.FM_FW FDP_ACC.1[MEM], FDP_ACF.1[MEM], FMT_MSA.3[MEM] O.MEM_ACCESS FDP_ACC.1[MEM], FDP_ACF.1[MEM], FMT_MSA.3[MEM], FMT_MSA.1[MEM], FMT_MSA.1[SFR], FMT_SMF.1[HW] O.SFR_ACCESS FDP_ACC.1[SFR], FDP_ACF.1[SFR], FMT_MSA.3[SFR], FMT_MSA.1[SFR], FMT_SMF.1[HW] O.CUST_RECONF_PLAIN FMT_SMF.1[HW] O.EEPROM_INTEGRITY FDP_SDI.2[HW], FDP_SDI.2[FW] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 91 / 129 Objective Security Functional Requirements of P6021P VB O.PUF FCS_CKM.1[PUF], FCS_CKM.4[PUF], FCS_COP.1[PUF_AES], FCS_COP.1[PUF_MAC] The justification related to the security objective “Cryptographic service Triple- DES” (O.TDES) is as follows: O.TDES requires the P6021P VB to support Triple-DES encryption and decryption. Exactly this is the requirement of FCS_COP.1[TDES]. The cryptographic key destruction is provided by overwriting the internal stored key when a new key value is provided through the key interface. This meets the requirement of FCS_CKM.4[TDES]. Therefore FCS_COP.1[TDES] and FCS_CKM.4[TDES] are suitable to meet O.TDES. Note: The P6021P VB supports directly the calculation of Triple-DES with up to three keys. The P6021P VB will ensure the confidentiality of the User Data (and especially cryptographic keys) during Triple-DES operation. This is supported by O.Leak-Inherent. The justification related to the security objective “Cryptographic service AES” (O.AES) is as follows: O.AES requires the P6021P VB to support AES encryption and decryption. Exactly this is the requirement of FCS_COP.1[AES]. The cryptographic key destruction is provided by overwriting the internal stored key when a new key value is provided through the key interface. This meets the requirement of FCS_CKM.4[AES]. Therefore FCS_COP.1[AES] and FCS_CKM.4[AES] are suitable to meet O.AES. Note: The P6021P VB supports directly the calculation of AES with three different key lengths. The P6021P VB will ensure the confidentiality of the User Data (and especially cryptographic keys) during AES operation. This is supported by O.Leak-Inherent. The justification related to security objective “Firmware Mode Firewall” (O.FM_FW) is as follows: The security functional requirement “Subset access control (FDP_ACC.1[MEM])” with the related Security Function Policy (SFP) “Access Control Policy” exactly require to implement a memory partition as demanded by O.FM_FW. Therefore, FDP_ACC.1[MEM] with its SFP is suitable to meet the security objective. The security functional requirement “Security attribute based access control (FDP_ACF.1[MEM])” with the related Security Function Policy (SFP) “Access Control Policy” defines the rules to implement the partition as demanded by O.FM_FW. Therefore, FDP_ACF.1[MEM] with its SFP is suitable to meet the security objective. The security functional requirement “Static attribute initialisation (FMT_MSA.3[MEM])” requires that the P6021P VB provide default values for the security attributes used by the Memory Management Unit to enforce the memory partition. These default values are generated by the reset procedure and the Boot-ROM Software for the related Special Function Register. Restrictive with respect to memory partition means that the partition cannot be changed at all and for the memory segmentation means that the initial setting is very restrictive since it effectively disables any memory segment. They are needed by the P6021P VB to provide a default configuration after reset. Therefore this requirement (as dependency from FDP_ACF.1) is suitable to meet the security objective. The security functional requirement “Management of security attributes (FMT_MSA.1)” requires that the ability to update the security attributes is restricted to privileged subject(s). No management ability is specified in the two iterations of FMT_MSA.1 that can be used to change the memory partition. Also no related management function is specified by FMT_SMF.1[HW]. Therefore the memory partition is fixed and cannot be changed any subject, which is the requirement of O.FM_FW. The justification related to the security objective “Area based Memory Access Control (O.MEM_ACCESS)” is as follows: NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 92 / 129 The security functional requirement “Subset access control (FDP_ACC.1[MEM])” with the related Security Function Policy (SFP) “Access Control Policy” exactly require to implement an area based memory access control as demanded by O.MEM_ACCESS. Therefore, FDP_ACC.1[MEM] with its SFP is suitable to meet the security objective. The security functional requirement “Security attribute based access control (FDP_ACF.1[MEM])” with the related Security Function Policy (SFP) “Access Control Policy” defines the rules to implement the area based memory access control as demanded by O.MEM_ACCESS. Therefore, FDP_ACF.1[MEM] with its SFP is suitable to meet the security objective. The security functional requirement “Static attribute initialisation (FMT_MSA.3[MEM])” requires that the P6021P VB provide default values for the security attributes used by the Memory Management Units. Since the P6021P VB is a hardware platform these default values are generated by the reset procedure for the related Special Function Register. They are needed by the P6021P VB to provide a default configuration after reset. Therefore this requirement (as dependency from FDP_ACF.1) is suitable to meet the security objective. The security functional requirement “Management of security attributes (FMT_MSA.1)” requires that the ability to update the security attributes is restricted to privileged subject(s). These management functions ensure that the required access control can be realised using the functions provided by the P6021P VB. The iteration of FMT_MSA.1 into FMT_MSA.1[MEM] and FMT_MSA.1[SFR] is needed because the different types of objects have different security attributes. The security attributes of the Memory Management Unit can be changed by the Security IC Embedded Software. Since the pointer to the MMU Segment Table can only be changed in System Mode and this protection is implemented by access control to the respective Special Function Registers, both iterations are needed for O.MEM_ACCESS. Finally, the security functional requirement “Specification of Management Functions (FMT_SMF.1)” is used for the specification of the management functions to be provided by the P6021P VB as required by O.MEM_ACCESS. Therefore, FMT_SMF.1[HW] is suitable to meet the security objective. The justification related to the security objective “Special Function Register Access Control (O.SFR_ACCESS)” is as follows: The security functional requirement “Subset access control (FDP_ACC.1[SFR])” with the related Security Function Policy (SFP) “Access Control Policy” require to implement access control for Special Function Register as demanded by O.SFR_ACCESS. Therefore, FDP_ACC.1[SFR] with its SFP is suitable to meet the security objective. The access to Special Function Register is related to the CPU mode. The Special Function Register used to configure the Memory Management Unit can only be accessed in System Mode. The Special Function Register required to use hardware components like e.g. the coprocessors or the Random Number Generator can be accessed in System Mode as specified by the Security Function Policy (SFP) “Access Control Policy”. In User Mode only Special Function Register required to run the CPU are accessible by default. In addition, specific Special Function Registers related to hardware components can be made accessible for the User Mode if the Memory Management Unit is configured to allow this. The security functional requirement “Security attribute based access control (FDP_ACF.1[SFR])” with the related Security Function Policy “Access Control Policy” exactly require certain security attributes to implement the access control to Special Function Register as required by O.SFR_ACCESS. Therefore, FDP_ACF.1[SFR] with its SFP is suitable to meet the security objective. The security functional requirement “Static attribute initialisation (FMT_MSA.3[SFR])” requires that the P6021P VB provides default values for the Special Function Register (values as well as access control). The default values are needed to ensure a defined setup for the operation of the P6021P VB. Therefore this requirement (as dependency from FDP_ACF.1) is suitable to meet the security objective. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 93 / 129 The security functional requirement “Management of security attributes (FMT_MSA.1[SFR])” is realised in a way that – besides the definition of access rights to Special Function Registers related to hardware components in User Mode and Firmware Mode – no management of the security attributes is possible because the attributes are implemented in the hardware and cannot be changed. Finally, the security functional requirement “Specification of Management Functions (FMT_SMF.1)” is used for the specification of the management functions to be provided by the P6021P VB as demanded by O.SFR_ACCESS. Therefore, FMT_SMF.1[HW] is suitable to meet the security objective. Note that the iteration of FDP_ACF.1 and FDP_ACC.1 with the respective dependencies are needed to separate the different types of objects because they have different security attributes. The justification related to the security objective “Integrity support of data stored in EEPROM” (O.EEPROM_INTEGRITY) is as follows: The security functional requirement “Stored data integrity monitoring and action (FDP_SDI.2)” is used for the specification of the control function to adjust the conditions of an EEPROM block such that the integrity of the data read from EEPROM is ensured even if the characteristics of the EEPROM changed e.g. due to ageing. Therefore, FDP_SDI.2[HW] and FDP_SDI.2[FW] are suitable to meet the security objective. The justification related to the security objective “Post Delivery Configuration of Hardware” (O.CUST_RECONF_PLAIN) is as follows: The security functional requirement “Specification of Management Functions (FMT_SMF.1)” is used for the specification of the management functions to be provided by the P6021P VB as demanded by O.CUST_RECONF_PLAIN. Therefore, FMT_SMF.1[HW] is suitable to meet the security objective. The justification related to the security objective "Sealing/Unsealing user data” (O.PUF) is as follows: The security functional requirement FCS_CKM.1[PUF] requires the generation of cryptographic key from the key derivation function based on the PUF block and the Random Number Generator (RNG). Since the PUF block and the Random Number Generator provide a TOE specific data to the key derivation function, the user data which is encrypted with this cryptographic key can be decrypted with the same TOE that the user data was encrypted on. The security functional requirement FCS_CKM.4[PUF] requires that the cryptographic keys which are derived by the key derivation function are destroyed by the method of flushing of key registers. The SFR FCS_COP.1[PUF_AES] defines the encryption and decryption of the user data using cryptographic algorithm AES. The SFR FCS_COP.1[PUF_MAC] defines the calculation of a MAC as a PUF authentication value. Therefore these SFRs together provide the functionality of sealing/ unsealing user data as required by the objective O.PUF. 6.3.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The rationale for the SFRs of the P6021M VB/P6021D VB/P6021J VB includes the rationale for the SFRs of the P6021P VB, and, in addition, the following rationale for the SFRs for MIFARE Software. The Security Target for the P6021M VB/P6021D VB/P6021J VB additionally defines the SFRs for the MIFARE Software ( MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1 that are listed in Table 35. The following table gives an overview, how the requirements are combined to meet the security objectives. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 94 / 129 Table 35. Mapping of security objectives and requirements Objective SFRs for MFP SFRs for DF Note O.ACCESS-CONTROL FMT_SMR.1[MFP] FDP_ACC.1[MFP] FDP_ACF.1[MFP] FMT_MSA.3[MFP] FMT_MSA.1[MFP] FMT_SMF.1[MFP] FDP_ITC.2[MFP] FCS_CKM.4[MFP] FMT_SMR.1[DF] FDP_ACC.1[DF] FDP_ACF.1[DF] FMT_MSA.3[DF] FMT_MSA.1[DF] FMT_SMF.1[DF] FDP_ITC.2[DF] FCS_CKM.4[DF] O.AUTHENTICATION FCS_COP.1[MFP_AES] FIA_UID.2[MFP] FIA_UAU.2[MFP] FIA_UAU.5[MFP] FTP_TRP.1[MFP] FPT_RPL.1[MFP] FCS_COP.1[DF_AES] FCS_COP.1[DF_TDES] FIA_UID.2[DF] FIA_UAU.2[DF] FIA_UAU.5[DF] FTP_TRP.1[DF] FPT_RPL.1[DF] O.ENCRYPTION FCS_COP.1[MFP_AES] FTP_TRP.1[MFP] FCS_COP.1[DF_AES] FTP_TRP.1[DF] Policy P.Emulation O.MAC FCS_COP.1[MFP_AES] FTP_TRP.1[MFP] FPT_RPL.1[MFP] FCS_COP.1[DF_AES] FTP_TRP.1[DF] FPT_RPL.1[DF] Policy P.Emulation O.DF-TRANSACTION FTP_ROL.1[DF] Policy P.DF-Transaction O.TYPE-CONSISTENCY FPT_TDC.1[MFP] FPT_TDC.1[DF] O.CUST_RECONF_MIFARE FMT_SMF.1[MFP] FMT_SMF.1[DF] Note: Sometimes in the following rationale “[*]” will be used, if the justifications related to the security objectives for the SFRs of the MIFARE Plus MF1PLUSx0 software and the MIFARE DESFire EV1 software are identical. The justification related to the security objective “Access Control” (O.ACCESS- CONTROL) is as follows: The SFRs FMT_SMR.1[MFP] and FMT_SMR.1[DF] define the roles of the MFP Access Control Policy and the DF Access Control Policy, respectively. The SFRs FDP_ACC.1[MFP] and FDP_ACF.1[MFP] define the rules and FMT_MSA.3[MFP] and FMT_MSA.1[MFP] the attributes that the MFP Access Control Policy is based on. The SFRs FDP_ACC.1[DF] and FDP_ACF.1[DF] define the rules and FMT_MSA.3[DF] and FMT_MSA.1[DF] the security attributes that the DF Access Control Policy is based on. The management functions are defined by FMT_SMF.1[*]. Since the P6021M VB/P6021D VB/P6021J VB P6021M VB/P6021D VB/P6021J VB stores data on behalf of the authorised subjects import of user data with security attributes is defined by FDP_ITC.2[*]. Since cryptographic keys are used for authentication (refer to O.AUTHENTICATION), these keys have to be removed if they are no longer needed for the access control. This is required by FCS_CKM.4[*]. These SFRs together provide an access control mechanism as required by the objective O.ACCESS-CONTROL. The justification related to the security objective “Authentication” (O.AUTHENTICATION) is as follows: In case that MIFARE Plus MF1PLUSx0 is used, the SFR FCS_COP.1[MFP_AES] requires that the TOE provides the basic cryptographic algorithm AES that can be used to perform the authentication. In case that MIFARE DESFire EV1 is used, the SFRs FCS_COP.1[DF_AES] and FCS_COP.1[DF_TDES] require that the P6021M VB/ P6021D VB/P6021J VB provides the basic cryptographic algorithms AES and Triple-DES respectively, that can be used to perform the authentication. The SFRs FIA_UID.2[*], FIA_UAU.2[*] and FIA_UAU.5[*] together define that users must be identified and NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 95 / 129 authenticated before any action. FTP_TRP.1[*] requires a trusted communication path between the P6021M VB/P6021D VB/P6021J VB and remote users, FTP_TRP.1.3[*] especially requires “authentication requests”. Together with FPT_RPL.1[*] which requires a replay detection for these authentication requests these SFRs fulfil the objective O.AUTHENTICATION. The justification related to the security objective “Confidential Communication” (O.ENCRYPTION) is as follows: The SFRs FCS_COP.1[MFP_AES] and FCS_COP.1[DF_AES] requires that the P6021M VB/P6021D VB/P6021J VB provides the basic cryptographic algorithm AES that can be used to protect the communication by encryption. FTP_TRP.1[*] requires a trusted communication path between the P6021M VB/P6021D VB/P6021J VB and remote users, FTP_TRP.1.3[MFP] especially requires a trusted path for “confidentiality and integrity protected data transfers or integrity protected data transfers, which are based on a setting in the MFP Configuration Block and the Sector Trailers”, whereas FTP_TRP.1.3[DF] especially requires a trusted path for “confidentiality and integrity protected data transfers with AES or integrity protected data transfers with AES, which are based on a setting in the file attributes”. These SFRs fulfil the objective O.ENCRYPTION. The justification related to the security objective “Integrity-protected Communication” (O.MAC) is as follows: The SFRs FCS_COP.1[MFP_AES] and FCS_COP.1[DF_AES] requires that the P6021M VB/P6021D VB/P6021J VB provides the basic cryptographic algorithms that can be used to compute a MAC which can protect the integrity of the communication. FTP_TRP.1[*] requires a trusted communication path between the P6021M VB/P6021D VB/P6021J VB and remote users, FTP_TRP.1.3[MFP] especially requires a trusted path for “confidentiality and integrity protected data transfers or integrity protected data transfers, which are based on a setting in the MFP Configuration Block and the Sector Trailers”, whereas FTP_TRP.1.3[DF] especially requires “confidentiality and integrity protected data transfers with AES or integrity protected data transfers with AES, which are based on a setting in the file attributes”. FPT_RPL.1[*] requires a replay detection for these data transfers. These SFRs fulfil the objective O.MAC. The justification related to the security objective “Data type consistency” (O.TYPE- CONSISTENCY) is as follows: The SFR FPT_TDC.1[*] requires the P6021M VB/P6021D VB/P6021J VB to consistently interpret data blocks. the P6021M VB/P6021D VB/P6021J VB will honour the respective file formats and boundaries (i.e. upper and lower limits, size limitations). This meets the objective O.TYPE-CONSISTENCY. The justification related to the security objective “Transaction control (O.DF- TRANSACTION)” is as follows: The SFR FDP_ROL.1[DF] requires the possibility to rollback a set of modifying operations on backup files in total. The set of operations is defined by the scope of the transaction, which is itself limited by boundary events. This fulfils the objective O.DF- TRANSACTION. The security objective “O.CUST_RECONF_MIFARE” maps to the SFR FMT_SMF.1[MFP] and SFR FMT_SMF.1[DF]. The justification related to the security objective “Post Delivery Configuration for MIFARE Software” (O.CUST_RECONF_MIFARE) is as follows: The security functional requirement “Specification of Management Functions (FMT_SMF.1)” is used for the specification of the management functions to be provided by the P6021M VB/P6021D VB/P6021J VB as demanded by O.CUST_RECONF_MIFARE. Therefore, FMT_SMF.1[MFP] and SFR FMT_SMF.1[DF] are suitable to meet the security objective. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 96 / 129 6.3.2 Dependencies of security functional requirements 6.3.2.1 NXP Secure Smart Card Controller P6021P VB The dependencies listed in the PP [6] are independent of the additional dependencies listed in the table below. The dependencies of the PP [6] are fulfilled within the PP [6] and at least one dependency is considered to be satisfied. The following discussion demonstrates how the dependencies defined by Part 2 of the Common Criteria [2] for the requirements specified in Section 6.1.1.2 and Section 6.1.1.3 are satisfied. The dependencies defined in the Common Criteria are listed in the Table 36: Table 36. Dependencies of security functional requirements Security Functional Requirement Dependencies Fulfilled by security requirements in this ST FCS_COP.1[TDES] FDP_ITC.1 or FDP_ITC.2, or FCS_CKM.1 FCS_CKM.4 See discussion below FCS_CKM.4[TDES] FDP_ITC.1 or FDP_ITC.2, or FCS_CKM.1 See discussion below FCS_COP.1[AES] FDP_ITC.1 or FDP_ITC.2, or FCS_CKM.1 FCS_CKM.4 See discussion below FCS_CKM.4[AES] FDP_ITC.1 or FDP_ITC.2, or FCS_CKM.1 See discussion below FDP_ACC.1[MEM] FDP_ACF.1 Yes, by FDP_ACF.1[MEM] FDP_ACC.1[SFR] FDP_ACF.1 Yes, by FDP_ACF.1[SFR] FDP_ACF.1[MEM] FDP_ACC.1 FMT_MSA.3 Yes, by FDP_ACC.1[MEM] Yes, by FMT_MSA.3[MEM] FDP_ACF.1[SFR] FDP_ACC.1 FMT_MSA.3 Yes, by FDP_ACC.1[SFR] Yes, by FMT_MSA.3[SFR] FMT_MSA.3[MEM] FMT_MSA.1 FMT_SMR.1 Yes, by FMT_MSA.1[MEM] See discussion below FMT_MSA.3[SFR] FMT_MSA.1 FMT_SMR.1 Yes, by FMT_MSA.1[SFR] See discussion below FMT_MSA.1[MEM] FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes, by FDP_ACC.1[MEM] See discussion below Yes, by FMT_SMF.1[HW] FMT_MSA.1[SFR] FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes, by FDP_ACC.1[SFR] See discussion below Yes, by FMT_SMF.1[HW] FCS_COP.1[PUF_AES] FDP_ITC.1, or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 Yes, by FCS_CKM.1[PUF] Yes, by FCS_CKM.4[PUF] FCS_COP.1[PUF_MAC] FDP_ITC.1, or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 Yes, by FCS_CKM.1[PUF] Yes, by FCS_CKM.4[PUF] FCS_CKM.1[PUF] FCS_CKM.2 or FCS_COP.1 FCS_CKM.4 Yes, by FCS_COP.1[PUF_AES] Yes, by FCS_CKM.4[PUF] NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 97 / 129 Security Functional Requirement Dependencies Fulfilled by security requirements in this ST FCS_CKM.4[PUF] FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes, by FCS_CKM.1[PUF] The developer of the Security IC Embedded Software must ensure that the additional security functional requirements FCS_COP.1[TDES], FCS_CKM.4[TDES], FCS_COP.1[AES] and FCS_CKM.4[AES] are used as specified and that the User Data processed by the related security functionality is protected as defined for the application context. The dependent requirements of FCS_COP.1[TDES], FCS_CKM.4[TDES], FCS_COP.1[AES] and FCS_CKM.4[AES] completely address the appropriate management of cryptographic keys used by the specified cryptographic function and the management of access control rights as specified for the memory access control function. All requirements concerning these management functions shall be fulfilled by the environment (Security IC Embedded Software). The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 must be fulfilled by the Security IC Embedded Software. The definition and maintenance of the roles that act on behalf of the functions provided by the hardware must be subject of the Security IC Embedded Software. 6.3.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The dependencies for the SFRs of the P6021M VB/P6021D VB/P6021J VB includes the dependencies for the SFRs of the P6021P VB, and, in addition, the following dependencies for the SFRs for MIFARE Software. The table below lists all dependencies of the SFRs only provided by the MIFARE Plus MF1PLUSx0. Table 37. Dependencies of security functional requirements (MIFARE Plus MF1PLUSx0) Security Functional Requirement Dependencies Fulfilled by security requirements in this ST FDP_ACC.1[MFP] FDP_ACF.1 Yes, by FDP_ACF.1[MFP] FMT_SMR.1[MFP] FIA_UID.1 Yes, by FIA_UID.2[MFP] FDP_ACF.1[MFP] FDP_ACC.1 FMT_MSA.3 Yes, by FDP_ACC.1[MFP] Yes, by FMT_MSA.3[MFP] FMT_MSA.3[MFP] FMT_MSA.1 FMT_SMR.1 Yes, by FMT_MSA.1[MFP] Yes, by FMT_SMR.1[MFP] FMT_MSA.1[MFP] FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes, by FDP_ACC.1[MFP] Yes, by FMT_SMR.1[MFP] Yes, by FMT_SMF.1[MFP] FDP_ITC.2[MFP] FDP_ACC.1 or FDP_IFC.1 FTP_ITC.1 or FTP_TRP.1 FPT_TDC.1 Yes, by FDP_ACC.1[MFP] Yes, by FTP_TRP.1[MFP] Yes, by FPT_TDC.1[MFP] FCS_COP.1[MFP_AES] FDP_ITC.1, or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.4 Yes, by FDP_ITC.2[MFP] Yes, by FCS_CKM.4[MFP] FIA_UAU.2[MFP] FIA_UID.1 Yes, by FIA_UID.2[MFP] FCS_CKM.4[MFP] FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes, by FDP_ITC.2[MFP] As shown in the table above all dependencies are satisfied. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 98 / 129 The table below lists all dependencies of the SFRs only provided by the MIFARE DESFire EV1. Table 38. Dependencies of security functional requirements (MIFARE DESFire EV1) Security Functional Requirement Dependencies Fulfilled by security requirements in this ST FDP_ACC.1[DF] FDP_ACF.1 Yes, by FDP_ACF.1[DF] FDP_ACF.1[DF] FDP_ACC.1 FMT_MSA.3 Yes, by FDP_ACC.1[DF] Yes, by FMT_MSA.3[DF] FMT_MSA.3[DF] FMT_MSA.1 FMT_SMR.1 Yes, by FMT_MSA.1[DF] Yes, by FMT_SMR.1[DF] FMT_MSA.1[DF] FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes, by FDP_ACC.1[DF] Yes, by FMT_SMR.1[DF] Yes, by FMT_SMF.1[DF] FMT_SMR.1[DF] FIA_UID.1 Yes, by FIA_UID.2[DF] FDP_ITC.2[DF] FDP_ACC.1 or FDP_IFC.1 FTP_ITC.1 or FTP_TRP.1 FPT_TDC.1 Yes, by FDP_ACC.1[DF] Yes, by FTP_TRP.1[DF] Yes, by FPT_TDC.1[DF] FIA_UAU.2[DF] FIA_UID.1 Yes, by FIA_UID.2[DF] FCS_CKM.4[DF] FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes, by FDP_ITC.2[DF] FDP_ROL.1[DF] FDP_ACC.1 or FDP_IFC.1 Yes, by FDP_ACC.1[DF] FCS_COP.1[DF_AES] FDP_ITC.1 or FDP_ITC.2, or FCS_CKM.1 FCS_CKM.4 Yes, by FDP_ITC.2[DF] Yes, by FCS_CKM.4[DF] FCS_COP.1[DF_TDES] FDP_ITC.1 or FDP_ITC.2, or FCS_CKM.1 FCS_CKM.4 Yes, by FDP_ITC.2[DF] Yes, by FCS_CKM.4[DF] 6.3.3 Rationale for the Security Assurance Requirements 6.3.3.1 NXP Secure Smart Card Controller P6021P VB The selection of assurance components is based on the underlying PP [6]. The Security Target for the P6021P VB uses the same augmentations as the PP, but chooses a higher assurance level. The level EAL6 is chosen in order to meet assurance expectations of digital signature applications and electronic payment systems. The rationale for the augmentations is the same as in the PP. The assurance level EAL6 is an elaborated pre-defined level of the CC, part 3 [3]. The assurance components in an EAL level are chosen in a way that they build a mutually supportive and complete set of components. The requirements chosen for augmentation do not add any dependencies, which are not already fulfilled for the corresponding requirements contained in EAL6, respectively. Therefore, these components add additional assurance to EAL6, but the mutual support of the requirements is still guaranteed. As stated in the Section 6.3.3 of the PP [6], it has to be assumed that attackers with high attack potential try to attack smartcards used for digital signature applications or payment systems. Therefore specifically AVA_VAN.5 was chosen by the PP [6] in order to assure that even these attackers cannot successfully attack the P6021P VB. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 99 / 129 6.3.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB (EAL5+) The selection of assurance components is based on the underlying PP [6]. The Security Target for the P6021M VB/P6021D VB/P6021J VB uses the same augmentations as the PP, but adds assurance component ASE_TSS.2 and chooses a higher assurance level. The level EAL5 is chosen in order to meet assurance expectations of digital signature applications and electronic payment systems. The rationale for the augmentations is the same as in the PP. The assurance level EAL5 is an elaborated pre-defined level of the CC, part 3 [3]. The assurance components in an EAL level are chosen in a way that they build a mutually supportive and complete set of components. The requirements chosen for augmentation do not add any dependencies, which are not already fulfilled for the corresponding requirements contained in EAL5, respectively. Therefore, these components add additional assurance to EAL5, but the mutual support of the requirements is still guaranteed. As stated in the Section 6.3.3 of the PP [6], it has to be assumed that attackers with high attack potential try to attack smartcards used for digital signature applications or payment systems. Therefore specifically AVA_VAN.5 was chosen by the PP [6] in order to assure that even these attackers cannot successfully attack the P6021M VB/P6021D VB/P6021J VB. 6.3.4 Security Requirements are Internally Consistent 6.3.4.1 NXP Secure Smart Card Controller P6021P VB The discussion of security functional requirements and assurance requirements in the preceding sections has shown that mutual support and consistency are given for both groups of requirements. The arguments given for the fact that the assurance components are adequate for the functionality of the P6021P VB also show that the security functional requirements and assurance requirements support each other and that there are no inconsistencies between these groups. The security functional requirements FDP_SDC.1 and FDP_SDI.2 address the protection of user data in the specified memory areas against compromise and manipulation. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the cryptographic algorithms, the integrity support of data stored in EEPROM and the memory access/separation control function as well as the access control to Special Function Register implemented according to the security functional requirement FCS_COP.1[TDES], FCS_CKM.4[TDES], FCS_COP.1[AES], FCS_CKM.4[AES], FDP_SDI.2[HW], FDP_SDI.2[FW], FDP_SDI.2[EEPROM], FDP_SDI.2[RAM], FDP_SDI.2[ROM], FDP_SDC.1[EEPROM], FDP_SDC.1[RAM], and FDP_ACC.1[MEM], FDP_ACC.1[SFR] with reference to the Access Control Policies defined in FDP_ACF.1[MEM] and FDP_ACF.1[SFR]. Therefore, these security functional requirements support the secure implementation and operation of FCS_COP.1[TDES], FCS_CKM.4[TDES], FCS_COP.1[AES], FCS_CKM.4[AES] and of FDP_ACC.1 with FDP_ACF.1 as well as the dependent security functional requirements. A hardware platform including the IC Dedicated Software requires Security IC Embedded Software to build a secure product. Thereby the Security IC Embedded Software must support the security functionality of the hardware as well as the IC Dedicated Support Software and implement a sufficient management of the security services implemented by the hardware platform including the IC Dedicated Software. The realisation of the Security Functional Requirements within the P6021P VB provides a good balance between flexible configuration and restrictions to ensure a secure behaviour of the P6021P VB. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 100 / 129 6.3.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The security requirements of the P6021M VB/P6021D VB/P6021J VB include the security requirements of the P6021P VB and they are internally consistent, as shown in Section 6.3.4.1. In addition, the discussion of security functional requirements and assurance components for MIFARE Software in the preceding sections has shown that consistency are given for both groups of requirements. The arguments given for the fact that the assurance components are adequate for the functionality of the P6021M VB/ P6021D VB/P6021J VB also shows the security functional requirements and assurance requirements for MIFARE Software support each other and there are no inconsistencies between these groups for MIFARE Software. The Security Functionality defined by P.Emulation is only provided if the MIFARE Software is called by the Security IC Embedded Software. However the Security Functionality provided by P.Emulation cannot be influenced by the Security IC Embedded Software because of the partitioning of the hardware platform by the Firmware Firewall. The partitioning works in both directions so that the Security Functionality of the Security IC Embedded Software cannot be influenced by the MIFARE Software. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 101 / 129 7 TOE Summary Specification This chapter is composed of sections “Portions of the TOE Security Functionality” and “TOE Summary Specification Rationale”. 7.1 Portions of the TOE Security Functionality The TOE Security Functionality (TSF) directly corresponds to the TOE security functional requirements defined in Section 6. The Security Functionality provided by the TOE P6021y VB is split into Security Services (SS) and Security Features (SF). Both are active and applicable to phases 4 to 7 of the Security IC product life-cycle. Note: Parts of the security functionality are configured at the end of phase 3 and all security functionality is active after phase 3 or phase 4 depending on the delivery form. The TOE also comprises security mechanisms, which are not listed as security functionality in the following. Such mechanisms do not implement a complete Security Services or Security Features. They can be used to implement further Security Services and/or Security Features based on Security IC Embedded Software using these security mechanisms, e.g. the Fame2 coprocessor for asymmetric cryptographic algorithms. 7.1.1 Security Services of the TOE 7.1.1.1 NXP Secure Smart Card Controller P6021P VB SS.RNG: Random Number Generator The Random Number Generator continuously produces random numbers with a length of one byte. The P6021P VB implements SS.RNG by means of a physical hardware Random Number Generator working stable within the valid ranges of operating conditions, which are guaranteed by SF.OPC. The TSF provides a hardware test functionality, which can be used by the Security IC Embedded Software to hardware detects or bad quality of the produced random numbers. According to AIS31 [7] the Random Number Generator claims the functionality class PTG2. This means that the Random Number Generator is suitable for generation of signature key pairs, generation of session keys for symmetric encryption mechanisms, random padding bits, zero-knowledge proofs, the generation of seeds for DRNGs and fulfils the online test requirements defined in [7]. SS.TDES: Triple-DES coprocessor The P6021P VB provides the Triple Data Encryption Standard (Triple-DES) according to the Data Encryption Standard (DES) [24]. SS.TDES is a modular basic cryptographic function, which provides the Triple-DES algorithm as defined by NIST SP 800-67 [24] by means of a hardware coprocessor and supports (a) the 3-key Triple-DES algorithm according to keying option 1 and (b) the 2-key Triple-DES algorithm according to keying option 2 in NIST SP 800-67 [24]. The two/three 56-bit keys (112-/168-bit) for the 2-key/3- key Triple-DES algorithm shall be provided by the Security IC Embedded Software. SS.TDES also supports hardware XOR-operation of two data blocks to support chaining modes of the encryption of Triple-DES if this is configured by the Security IC Embedded Software. Note that the hardware support for the CBC mode of SS.TDES is limited to encryption. SS.AES: AES coprocessor The P6021P VB provides the Advanced Encryption Standard (AES) algorithm according to the Advanced Encryption Standard as defined by FIPS PUB 197 [21]. SS.AES is a modular basic cryptographic function, which provides the AES algorithm by means of a NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 102 / 129 hardware coprocessor and supports the AES algorithm with three different key lengths of 128, 192 or 256 bit. The keys for the AES algorithm shall be provided by the Security IC Embedded Software. SS.AES also supports hardware XOR-operation of two data blocks to support chaining modes of the encryption of AES if this is configured by the Security IC Embedded Software. Note that the hardware support for the CBC mode of SS.AES is limited to encryption. SS.RECONFIG: Post Delivery Configuration SS.RECONFIG realizes the Post Delivery Configuration. The Hardware Post Delivery Configuration can be used by the customer to set the accessible size of the EEPROM and CXRAM and to enable or disable the Fame2 coprocessor, the AES coprocessor and the contactless interface. The configuration values of the Hardware Post Delivery Configuration options are stored in a special area in the Security Row (see SF.COMP). Note that if the Fame2 coprocessor and the AES coprocessor are disabled, both will no longer be available to the Security IC Embedded Software and attempting to use it will raise an exception. This means the availability of SS.AES is configurable. The customer can change the values of Hardware Post Delivery Configuration through invoking the Hardware Post Delivery Configuration functionality in Firmware Operating System (see SF.MEM_ACC). This functionality is invoked by using the FVEC interface (FVEC0.15). The customer can change these values as many times as he wishes. However, once he calls this Firmware Operating System using FVEC0.15 with a certain parameter set to a specific value, the options are locked permanently, and can no longer be changed. The options must be locked before the P6021P VB is delivered to the customer before phase 7 of the Security IC product life-cycle. 7.1.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The security services of the P6021M VB/P6021D VB/P6021J VB includes the security services of the P6021P VB, and, in addition, the following security services for MIFARE Software. The MIFARE Post Delivery Configuration can be used by the customer to enable MIFARE Software and to set MIFARE Software EEPROM size. The configuration values are stored in the EEPROM owned by the IC Dedicated Support Software. The customer can change the values of the MIFARE Post Delivery Configuration by calling the FVEC interface (FVEC0.15). FVEC interface for MIFARE Post Delivery Configuration is split into a GET and SET operation. While the SET operation can only be executed once, the GET operation can be executed multiple times. GET operation can be used in phase 7 of the Security IC product life-cycle for identification of the P6021M VB/P6021D VB/P6021J VB after applying the MIFARE Post Delivery Configuration. Further details regarding the FVEC and identification of the P6021M VB/P6021D VB/P6021J VB after applying Post Delivery Configuration, refer to [9]. 7.1.1.2.1 Security Services of MIFARE Plus MF1PLUSx0 In this chapter the security services SS.MFP_AUTH, SS.MFP_ACC_CTRL, SS.MFP_ENC and SS.MFP_MAC of the MIFARE Plus MF1PLUSx0 software will be described. Note that if the MIFARE Plus MF1PLUSx0 software is disabled, it will no longer be available to the Security IC Embedded Software and attempting to use it results in returning immediately from the FVEC interface with a return code MFP_NOT_PRESENT. This means the availability of the security services SS.MFP_AUTH, SS.MFP_ACC_CTRL, SS.MFP_ENC and SS.MFP_MAC are configurable. SS.MFP_AUTH: MIFARE Plus Authentication NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 103 / 129 The P6021M VB/P6021D VB/P6021J VB provides an authentication mechanism to separate authorised subjects from unauthorised subjects. The authentication of subjects is performed by a cryptographic challenge-response. The P6021M VB/P6021D VB/ P6021J VB supports the cryptographic algorithm 128-bit AES; according to FIPS PUB 197 [21]. A hardware random number generator according to “Anwendungshinweise und Interpretationen zum Schema, AIS31: Funktionalitaetsklassen und Evaluationsmethodologie fuer physikalische Zufallszahlengeneratoren, Version 2.1, 02.12.2011, Bundesamt fuer Sicherheit in der Informationstechnik”, functionality class PTG2, is used to protect the authentication against attacks like replay (see SS.RNG). SS.MFP_AUTH identifies the user to be authenticated by the key block number indicated in the authentication request. In security level 0 the P6021M VB/P6021D VB/P6021J VB identifies and authenticates the Personaliser by default, in addition the Originality Key User can be identified with an explicit authentication request. In the security level 1-3 SS.MFP_AUTH by default and before any authentication request identifies and authenticates the role Anybody. The roles Card Administrator, Card Manager, Card Security Level Manager, Card User and Originality Key User are authenticated during the authentication requested by the knowledge of the respective cryptographic key. The authentication state is remembered by SS.MFP_AUTH and the authentication needs not to be performed again as long as none of the following events occur: Occurrence of any error during the processing of a command, Reset, Selection and Deselection of the Virtual Card, Switching the security level of the P6021M VB/P6021D VB/P6021J VB, DESELECT according to ISO 14443 3, explicit authentication reset. These events will reset the authentication state to the default (Anybody). Of course a new authentication (possibly by another user) will invalidate the old authentication state, too. The authentication state will be invalidated as soon as the authentication request is received. SS.MFP_ACC_CTRL: Access Control to MIFARE Plus data SS.MFP_ACC_CTRL provides an access control mechanism to the objects and security attributes that are part of the MFP Access Control Policy. The access control mechanism assigns Card Users to 4 different groups of operations on blocks. The operations are “read”, “write”, “increase” and “decrease, transfer and restore”, whereby the last two groups are only applicable if the data is in the value format. There are several sets of predefined access conditions which may be assigned to each sector. These sets can also contain the access condition “never” for one group of operations. Card Users is allowed to modify the sector trailer or to change the AES sector keys, if the access conditions allow this. The Originality Key User is not allowed to perform any operation on objects, but with a successful authentication he can prove the authenticity of the Security IC. The Card Administrator is allowed to modify the MFP Configuration Block, which are attributes that do not have to be changed in the field. He is also allowed to change the Card Master Key and, if the P6021M VB/P6021D VB/P6021J VB is in security level 2, the L3 Switch Key. The Card Manager is allowed to modify the Field Configuration Block, which are attributes that may have to be changed in the field. He is also allowed to change the Card Configuration Key. The Card Security Level Manager can switch the security level of the card to a higher level by authenticating with the corresponding key. The MFP Access Control Policy and therefore SS.MFP_ACC_CTRL has to take care that all sectors are initialized with permissive default values in the sector trailer, this means the contained access conditions shall allow the Card User to access all blocks. Finally SS.MFP_ACC_CTRL ensures the type consistency of the blocks stored by the P6021M VB/P6021D VB/P6021J VB. It ensures that values cannot over- or underflow. Furthermore size limitations of blocks are obeyed. SS.MFP_ENC: MIFARE Plus Encryption NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 104 / 129 The TSF SS.MFP_ENC provides a mechanism to protect the communication against eavesdropping. In order to do this the data sent via wireless communication must be encrypted using the cryptographic algorithm 128-bit AES. The encryption algorithm is the same as the one used during authentication for the session, therefore the same cryptographic algorithm as described for SS.MFP_AUTH is supported by SS.MFP_ENC. Note that encryption can be set optional or mandatory on a block group basis in the sector trailer. SS.MFP_MAC: MIFARE Plus Message Authentication Code SS.MFP_MAC adds data to the communication stream that enables both the P6021M VB/P6021D VB/P6021J VB and the terminal to detect integrity violations, replay attacks or man-in-the-middle attacks using the cryptographic algorithm 128-bit AES CMAC, see [26]. The P6021M VB/P6021D VB/P6021J VB offers multiple modes in which protection by MAC is optional or mandatory for both communication parties. Regardless of the selected mode the terminal must always provide a MAC for commands that modify any TOE item (data or security attributes). The P6021M VB/P6021D VB/P6021J VB does also provide a mode in which the MAC on its responses can be cumulated, i.e. the last response contains a MAC that covers previously sent frames without MAC. The detection mechanism covers all frames exchanged between the terminal and the card up to the current encrypted frame. Therefore SS.MFP_MAC can detect any injected/modified frame in the communication before the transfer of the encrypted frame. Depending on the selected mode it can also detect what frame was injected/modified. 7.1.1.2.2 Security Services of MIFARE DESFire EV1 In this chapter the security services SS.DF_AUTH, SS.DF_ACC_CTRL, SS.DF_ENC, SS.DF_MAC and SS.DF_TRANS regarding the MIFARE DESFire EV1 software will be described. Note that if the MIFARE DESFire EV1 software is disabled, it will no longer be available to the Security IC Embedded Software and attempting to use it results in returning immediately from the FVEC interface with a return code MDF_NOT_PRESENT. This means the availability of the security services SS.DF_AUTH, SS.DF_ACC_CTRL, SS.DF_ENC, SS.DF_MAC and SS.DF_TRANS is configurable. SS.DF_AUTH: DESFire Authentication The P6021M VB/P6021D VB/P6021J VB provides an authentication mechanism to separate authorised subjects from unauthorised subjects. The authentication of subjects is performed by a cryptographic challenge-response. The P6021M VB/P6021D VB/ P6021J VB supports the cryptographic algorithms 3-key Triple-DES and 128-bit AES; for 3-key Triple-DES according to NIST SP 800-67 [24] and for AES according to FIPS PUB 197 [21]. The authentication mechanisms are implemented using the cryptographic coprocessors and the hardware random number generator provided by the hardware platform. The authentication is supported by the security services SS.TDES and SS.AES as well as SS.RNG that provides the random numbers used within the authentication protocol. The authentication mechanisms are protected against attacks like e.g. replay. SS.DF_AUTH identifies the user to be authenticated by the currently selected context (specific application, chosen by a ‘select’ command) and the key number indicated in the authentication request. By default and before any authentication request SS.DF_AUTH identifies and authenticates the role Everybody. The roles Administrator, Application Manager, Application User and Originality Key User are authenticated during the authentication request by the knowledge of the respective cryptographic key. The authentication state is remembered by SS.DF_AUTH and the authentication need not to be performed again as long as none of the following events occur: Issue of a ‘select’ command, occurrence of any error during the processing of commands, change of the key that was used for authentication and reset (any cause, either NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 105 / 129 internal or external reset). These events will reset the authentication state to the default (Everybody). Additionally, if the Application Manager deletes his application the authentication state will be reset as an implication. SS.DF_ACC_CTRL: Access Control to DESFire Data SS.DF_ACC_CTRL provides an access control mechanism to the objects and security attributes of the MIFARE DESFire EV1 software. The access control mechanism assigns subjects - (possibly multiple) Application Users - to 4 different groups of operations on files. For data files, the operations are “read”, “write”, “read and write” and “modify”. For values the operations are “read and decrease”, “read, decrease, limited increase”, “read, decrease, limited increase, increase” and “modify”. One subject can be assigned to each group of file operations. The special subjects Everybody and Nobody can also be assigned. For applications of the MIFARE DESFire EV1 software the operations are “create data file” and “delete data file”. These operations can be assigned to the Application Manager or to Everybody. The assignment is stored in the application attributes. If a file is created the file attributes must be supplied with the create request. On the DESFire card level the operations are “create application” and “delete application”. These operations can be assigned to the Administrator or to Everybody. The assignment is stored in the card attributes. If an application is created the application attributes must be supplied with the create request. A “delete application” operation will securely delete all application keys by overwriting them with random values. The Originality Key User is not allowed to perform any operation on objects, but with a successful authentication he can prove the authenticity of the Security IC. SS.DF_ACC_CTRL also controls access to the security attributes and the authentication data. The card attributes are only allowed to be modified and the card master key are only allowed to be changed by the Administrator, as long as the Administrator does not freeze the card attributes or the card master key. The application attributes are only allowed to be modified and application master keys are only allowed to be changed by the Application Manager, as long as the Application Manager does not freeze the application attributes or the application master key. Additionally the Application Manager is allowed to change the Application User keys and to decide if the Application Users are allowed to change their keys or not. For files, the attributes are allowed to be modified by the subject that has the “change attribute” right. SS.DF_ACC_CTRL allows the Administrator to specify a default application master key and application keys that will be used when an application is created. Finally SS.DF_ACC_CTRL ensures the type consistency of the file types stored by the P6021M VB/P6021D VB/P6021J VB. For value files the check comprises over- or underflow. Furthermore size limitations of files are obeyed and SS.DF_ACC_CTRL ensures that records read/writes are handled specific to the type of the record file. SS.DF_ENC: DESFire Communication Encryption The TSF SS.DF_ENC provides a mechanism to protect the communication against eavesdropping. In order to do this the communication can be encrypted. The encryption is performed based on the option in the file attributes. These options can be changed by the file owner (i.e. the subject that has the right to “change attribute” for a file). The encryption algorithm is the same as the one used during authentication for the session, however SS.DF_ENC only supports the AES algorithm, therefore it is bound to authentications with this algorithm. This is supported by SS.AES. Note that the TSF SS.DF_ENC can be activated after authentication performed with SS.DF_AUTH. SS.DF_MAC: DESFire Message Authentication Code SS.DF_MAC adds data to the communication stream that enables both the P6021M VB/ P6021D VB/P6021J VB and the terminal to detect integrity violations, replay attacks or man-in-the-middle attacks using the cryptographic algorithm 128-bit AES CMAC, see [26]. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 106 / 129 If an encrypted communication is requested, SS.DF_MAC verifies the data sent by the terminal and returns an error code if such an attack is detected. The detection mechanism covers all frames exchanged between the terminal and the MIFARE DESFire EV1 software up to the current encrypted frame. Therefore SS.DF_MAC can detect any injected/modified frame in the communication before the transfer of the encrypted frame, but it cannot detect what frame was injected/modified. SS.DF_TRANS: DESFire Transaction Protection The transaction mechanism implemented by SS.DF_TRANS ensures that either all or none of the (modifying) commands within a transaction are performed. The transaction mechanism is active for backup data files, value files, linear record files and cyclic record files. It is not active for standard data files. All file types with the exception of ‘standard data files’ are called ‘backup files’ in the following. SS.DF_TRANS is always active for the respective file types. This means that for every modifying operation with a backup file an explicit commit request must be issued in order to let the modifications take effect. Several reasons will abort a transaction: These are the explicit abort request, chip reset, an authentication request, a ‘select’ command or any failure of a command. 7.1.2 Security Features In this section, the security features of the TOE P6021y VB are described. 7.1.2.1 NXP Secure Smart Card Controller P6021P VB SF.OPC: Control of Operating Conditions SF.OPC ensures correct operation of the P6021P VB (functions offered by the microcontroller including the standard CPU as well as the Triple-DES coprocessor, AES coprocessor, the arithmetic coprocessor, the memories, registers, I/O interfaces and the other system peripherals) during execution of the IC Dedicated Support Software and Security IC Embedded Software. This includes all security mechanisms of the P6021P VB, which directly contribute to a Security Service or a Security Feature. The P6021P VB ensures its correct operation and prevents any malfunction using the following mechanisms: filtering of power supply, clock frequency and reset input as well as monitoring of voltage supply, clock frequency input and the temperature of the chip by means of sensors. There are multiple voltage and frequency sensors for the different ISO/IEC 7816 voltage classes and the contactless operation mode. Light sensors are distributed over the chip surface and used to detect light attacks. In addition to the light sensors the EEPROM provides two functions to detect light attacks. The Security IC Embedded Software can enable/disable the EEPROM double read function. Specific functional units of the P6021P VB are equipped with further fault injection detection. This comprises the Secure Fetch for the processing of code and data by the CPU or special circuitry within a functional unit. The functional units are the Program Counter, the stack pointer, the CPU control register, the MMU address cache and control registers, the SBC interface for the Triple-DES and the AES coprocessors, the Fame2 coprocessor, Copy Machine control registers and hardware configuration as well as test control registers. Furthermore the P6021P VB contains a watchdog timer which can be enabled and configured by the Security IC Embedded Software to protect the program execution. If one of the monitored parameters is out of the specified range, either (i) a reset is forced and the actually running program is aborted or (ii) an exception is raised which interrupts the program flow and allows a reaction of the Security IC Embedded Software. In case minor configuration option “Inverse EEPROM Error Correction” is enabled (see Section 1.4.2.2) the probability to detect fault injection attack detectors at the EEPROM memory and interface increases and the error correction logic raises an exception when detecting an error. The RAM memory is equipped with additional parity bits which are checked NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 107 / 129 when the corresponding data stored in RAM is read. Additionally a RAM parity watchdog mechanism is supported which checks the parity bits of the complete RAM in random order when the Security IC Embedded Software is not accessing the RAM. In case of detected RAM parity attack detectors both mechanisms trigger a security reset. In case the P6021P VB processes a reset all components of the P6021P VB are initialised with their reset values and the P6021P VB provides a reset cause indicator to the Security IC Embedded Software. In the case an exception is raised an indicator for the reason of the exception is provided. The P6021P VB defends the sensors from being disabled by the Security IC Embedded Software. The P6021P VB controls the specified range of the stack pointer. The stack pointer and the related control logic are implemented threefold for the User Mode, System Mode and Super System Mode (comprising Boot Mode, Test Mode and Firmware Mode). An exception is generated in case the specified limits are exceeded. In addition, SF.OPC comprises a sensor, which checks the high voltage of the write process to the EEPROM during each write sequence. The result of this sensor must be read from a Special Function Register and does not force an automatic event (e.g. exception). SF.PHY: Protection against Physical Manipulation SF.PHY protects the P6021P VB against manipulation of (i) the IC hardware, (ii) the IC Dedicated Software in ROM, (iii) the Security IC Embedded Software in ROM and EEPROM, (iv) the Application Data in EEPROM and RAM including TSF data in the Security Rows. It also protects User Data and TSF data against disclosure by physical probing when stored or while being processed by the P6021P VB. The protection of the P6021P VB comprises several security mechanisms in design and construction, which make reverse-engineering and tamper attacks more difficult. These mechanisms comprise dedicated shielding techniques for the P6021P VB and specific encryption- and check mechanisms for the memories and internal buses. SF.PHY supports the efficiency of other portions of the security functionality. SF.PHY also supports the integrity of the EEPROM, RAM and the ROM. The EEPROM is able to correct a 1-bit error within each byte. The EEPROM corrects these attack detectors automatically without user interaction. The RAM and the ROM provide a parity check. In both cases a reset is forced based on a parity error. The CRC coprocessor is used in Boot Mode by the IC dedicated Software for calculation of a CRC checksum for integrity protection of TSF data. SF.PUF: User Data Protection using PUF SF.PUF implements a mechanism to seal/unseal the user data stored in shared memory against unintended disclosure. SF.PUF encrypts/decrypts the user data with a cryptographic key derived from the PUF data. SF.PUF calculates a MAC as a PUF authentication value. SF.PUF provides this sealing/unsealing mechanism through the specified interfaces FVEC2 (see Fig. 3) only. SF.LOG: Logical Protection SF.LOG implements security mechanisms to limit or eliminate the information in the shape and amplitude of signals or in the time between events, which might be found by measuring such signals. This comprises the power supply, signals on other pads, which are not intentionally used for communication by the terminal or the Security IC Embedded Software as well as emanation of the hardware platform. Thereby SF.LOG prevents from disclosure of User Data and TSF data stored and/or processed in the Security IC through measurement of power consumption or emanation and subsequent complex signal analysis. This protection of the P6021P VB is enforced by several security mechanisms in the design, which support these portions of security functionality. The Triple-DES coprocessor includes specific security mechanisms to prevent SPA/ DPA analysis of shape and amplitude of the power consumption and emanation. The NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 108 / 129 implementation of the Triple-DES coprocessor further ensures that the calculation time is independent from the chosen key value and plain/cipher text. The AES coprocessor includes specific security mechanisms to prevent SPA/DPA analysis of shape and amplitude of the power consumption and emanation. The implementation of the AES coprocessor further ensures that the calculation time is independent from the chosen key any plain/cipher text for a given key length. The Fame2 coprocessor provides measures to prevent timing attacks on basic modular function. The calculation time of an operation depends on the lengths of the operands, but not on the value of the operands, with the following exceptions: multiplication with reduction, modular inversion and modular division. These three operations have no constant timing due to correction cycles that are needed based on the calculation method. In addition, mechanisms are included, which provide limitations of the capability for the analysis of shape and amplitude of the power consumption. Of course the Fame2 coprocessor does not realise an algorithm on its own and algorithm-specific leakage countermeasures have to be added by the Security IC Embedded Software when using the Fame2 coprocessor. Additional security mechanisms can be configured by the Security IC Embedded Software. This comprises the configuration of the clock that can be used to prevent the synchronisation between internal operations and external clock or characteristics of the power consumption that can be used as trigger signal to support leakage attacks (DPA or timing attacks) Some mechanisms described for SF.PHY (e.g. the encryption mechanisms) and for SF.OPC (e.g. the filter mechanisms) support SF.LOG. SF.COMP: Protection of Mode Control SF.COMP provides control of the CPU mode for (i) Boot Mode, (ii) Test Mode and (iii) Firmware Mode. This includes protection of electronic fuses stored in a protected memory area, the so-called Security Rows, and the possibility to store initialisation or pre-personalisation data in the so-called FabKey Area. Control of the CPU mode for Boot Mode, Test Mode and Firmware Mode prevents abuse of test functions after TOE delivery. It also inhibits abuse of features, which are used during start-up or reset to configure the P6021P VB. The integrity control of electronic fuses ensures secure storage and setup of configuration and calibration data, during the start-up in Boot Mode. The protection of electronic fuses especially ensures that configuration options with regard to the security functionality cannot be changed, abused or influenced in any way. The transfer of the content of the electronic fuses into the related hardware configuration registers is protected by a CRC checksum generated using the CRC coprocessor. SF.COMP ensures that activation or deactivation of security mechanisms cannot be influenced by the Security IC Embedded Software so that the TSF provides self-protection against interference and tampering by untrusted Security IC Embedded Software. SF.COMP protects CPU mode switches regarding Boot Mode, Test Mode and Firmware Mode in the following way: Switching from Boot Mode to Test Mode or Firmware Mode is allowed, switching from these modes back to Boot Mode is prevented. Switching to Test Mode is prevented as well after TOE delivery, because Test Mode then is permanently disabled. SF.COMP also ensures that Boot Mode is active only in the boot phase during start-up or reset of the P6021P VB, and cannot be invoked afterwards. Therefore, once the P6021P VB has left the test phase and each time the P6021P VB completed start-up or reset, Firmware Mode is the only Super System Mode available. The TSF controls access to the Security Rows, the top-most 512 Bytes of the EEPROM memory, accessible at reserved addresses in the memory map. The available EEPROM memory space for the Security IC Embedded Software is reduced by this area. SF.COMP provides three memory areas in the Security Rows, which can be used by the Security IC Embedded Software. These are • the User Read Only Area NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 109 / 129 • the User Write Protected Area and • the User Write Once Area. The User Read Only Area contains 32 bytes, which are read-only for the Security IC Embedded Software. The User Write Protected area contains 16 bytes, which can be write-protected by the Security IC Embedded Software on demand. The User Write Once Area contains 32 bytes of which each bit can separately be set to ‘1’ once only, and not reset to ‘0’. SF.COMP also provides a memory area in the Security Row where the current values for the Post Delivery Configuration (see SS.RECONFIG). This area cannot be accessed by the Security IC Embedded Software, but it can be accessed by the Resource Configuration Firmware. If minor configuration option “Card Disable” feature is used (refer to section 1.4.2.2) SF.COMP inhibits any start-up of the Security IC Embedded Software once the Security IC Embedded Software disables the card. If minor configuration option “EEPROM application content erase” is used (see Section 1.4.2.2) SF.COMP erases the application data stored in the EEPROM once the Security IC Embedded Software has activated this security feature. SF.COMP also provides the FabKey Area where initialisation and identification data can be stored. The FabKey area does not belong to the Security Rows and is not protected by hardware mechanisms. The FabKey Area as well as the Security Rows can be used by SF.COMP to store a unique identification for each die. The complete EEPROM is initialized during wafer testing and pre-personalisation. The values for the Security Row depend on the configuration options and choice of the Security IC Embedded Software developer. The values for the application EEPROM depend on the choice of the Security IC Embedded Software developer and are included in the Order Entry Form. The User Write Protected Area and the User Write Once Area are designed to store the identification of a (fully personalised) Security IC (e.g. smartcard) or a sequence of events over the life-cycle, that can be coded by an increasing number of bits set to "one" or protecting bytes, respectively. SF.COMP limits the capabilities of the test functions and provides test personnel during phase 3 with the capability to store identification and/or pre-personalisation data and/or supplements of the Security IC Embedded Software in the EEPROM. SF.COMP provides self-protection against interference and tampering by untrusted subjects both in the Test Mode and in the other modes. It also enforces the separation of domains regarding the IC Dedicated Software and the Security IC Embedded Software. SF.MEM_ACC: Memory Access Control SF.MEM_ACC controls access of any subject (program code comprising processor instructions) to the memories of the P6021P VB through the Memory Management Unit. Memory access is based on virtual addresses that are mapped to physical addresses. The CPU always uses virtual addresses. The Memory Management Unit performs the translation from virtual to physical addresses and the physical addresses are passed from the Memory Management Unit to the memory interfaces to access the memories. Access control is conducted in two ways: • Memory partitioning: Each memory type ROM, RAM and EEPROM is partitioned into two parts. In Boot Mode and Firmware Mode the CPU has access to the Firmware EEPROM, Firmware RAM and Test-ROM. In System Mode and User Mode the CPU has access to the Application EEPROM, Application RAM and Application ROM. Access to both parts of each type is allowed in Test Mode for testing. • Memory segmentation in User Mode: The three accessible parts of the memory in ROM, RAM and EEPROM can be segmented into smaller memory areas. Access rights (readable, writeable or executable) can be defined for these segments. In addition, access rights to Special Function Registers related to hardware components can be defined for code executed in User Mode. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 110 / 129 Memory partitioning is fixed and cannot be changed. It is determined during production of the P6021P VB and is solely dependent on the major configuration (see Section 1.4.2.1.1) and Post Delivery Configuration (see Section 1.4.2.3.1). Memory segmentation can be defined in System Mode. The segmentation is active when the CPU switches to User Mode. The segments, their access rights and the access rights to Special Function Registers related to hardware components are defined in the MMU Segment Table. The MMU Segment Table stores five values for each segment: The memory access rights, the virtual start address of the segment, the virtual end address of the segment, the address offset for the segment and the access rights to Special Function Registers for code that is executed in the segment. The address offset is used to relocate the segment anywhere in the memory map. The resulting address computed by the Memory Management Unit can not overrule memory partitioning. Up to 64 segments can be defined in the MMU Segment Table. Special configurations of the memory access rights allow to specify less than 64 segments and to split the MMU Segment Table into several parts being stored at different locations in memory. Note that the MMU Segment Table itself is stored in the memory and therefore the table itself can be placed in a segment accessible in User Mode. In addition, SF.MEM_ACC permanently checks whether accessed addresses point to physically implemented memory. Any access outside the boundaries of the physical implemented memory in all CPU modes except the Test Mode and access to forbidden memory addresses in User Mode are notified by raising an exception. The Memory Management Unit also handles access rights to Special Function Registers related to hardware components for code running in Firmware Mode. The configuration of the access rights for User Mode and Firmware Mode are used by SF.SFR_ACC to grant or block access to the related Special Function Registers. The access rights can be defined for up to 16 groups of Special Function Registers, which are related to 16 hardware peripherals or memories described in [9], section 12.4. Thus, User Mode and Firmware Mode can be restricted in their access to the Special Function Registers related to hardware components on demand of the Security IC Embedded Software. Note that SF.MEM_ACC only provides the access rights to SF.SFR_ACC, the access control is enforced by SF.SFR_ACC. SF.SFR_ACC: Special Function Register Access Control SF.SFR_ACC controls access to the Special Function Registers and CPU mode switches based on specific Special Function Register. SF.SFR_ACC implements access control to the Special Function Registers as specified in the Access Control Policy and the Security Functional Requirements FDP_ACC.1[SFR] and FDP_ACF.1[SFR]. The function of the Special Function Register and the CPU mode determine, whether read and/or write access to a Special Function Register is allowed or not. Key registers cannot be read since they are write-only to support the confidentiality of keys. Write access is granted depending on the CPU mode. Similar for the output register of the Random Number Generator, which is read-only based on its function, and read access is granted based on the CPU mode. SF.SFR_ACC controls accesses to Special Function Registers. If the access is not allowed or the Special Function Register addressed by the code is not implemented an exception is triggered. The Security IC Embedded Software can react on this exception. Some Special Function Registers are implemented threefold, one for User Mode, a second one for System Mode and a third one for Super System Mode meaning Boot Mode, Test Mode and Firmware Mode. Hence, such Special Function Registers are inherently separated and enforce the separation between the CPU modes. SF.SFR_ACC relies on access rights to Special Function Registers related to hardware components, which are provided by SF.MEM_ACC. Access rights to all other Special Function Registers are pre-defined and cannot be configured by the code running on the hardware platform. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 111 / 129 This implies that code running in User Mode or Firmware Mode is not able to use SS.RNG, SS.TDES, and SS.AES until access to the respective group of Special Function Registers is explicitly granted by code running in System Mode. This holds for all 16 hardware components, which are controlled by the 16 groups of Special Function Registers related to hardware components. SF.SFR_ACC also implements transitions among CPU modes based on specific Special Function Register. The CPU mode changes by the following operations. • Call of a system call vector (SVEC) address or a firmware vector (FVEC) address. A call of a SVEC enables System Mode, a call of a FVEC sets enables Firmware Mode. Calls of SVEC addresses are allowed in User Mode only, otherwise an exception is raised. • Execution of an exception or interrupt. Any event that leads to the execution of an exception leads to a special status of the related CPU mode. Any further exception in this special status forces a reset. Interrupts can be executed in User Mode or in System Mode as well as in Firmware Mode. The Security IC Embedded Software running in System Mode can configure this option at run time. • Return from an exception/interrupt or vector call with a RETI instruction. This restores the CPU mode before the event occurred. A RETI in User Mode is allowed only in case interrupts are allowed to be executed in User Mode and an interrupt is actually active, otherwise an exception is raised. • Execution of an LCALL/ACALL/ECALL instruction to a specific address. A call of address 0x800000 in System Mode enables User Mode and starts execution at this (virtual) address. This is similar to a FVEC or SVEC call, but no return address is pushed onto the stack. • Direct modification of the specific Special Function Register. Hardware provided by SF.SFR_ACC ensures that the bits can only be cleared. Therefore it is not possible for code running in User Mode to enter System Mode, but System Mode can switch to User Mode. Two CPU modes are available to the Security IC Embedded Software, which are System Mode and User Mode. System Mode is the more privileged CPU mode since it allows access to all Special Function Registers related to hardware components and for system management (i.e. configuration of Memory Management Unit, clock settings and some mechanisms provided by SF.LOG). User Mode is the less privileged, but in regard to hardware components it can be made as powerful as System Mode. SF.SFR_ACC and SF.COMP together ensure that other CPU modes are not available to the Security IC Embedded Software, but reserved for specific purposes fulfilled by the IC Dedicated Software. As described above, SF.MEM_ACC provides the access control information to Special Function Registers related to hardware components in Firmware Mode and User Mode. SF.FFW: Firmware Firewall SF.FFW (Protected Firmware Mode) implements a mechanism to protect the application data of the different firmware applications (NXP firmware functionality) running in Firmware Mode by means of a firewall separating the application data between each other. The firewall mechanism is based on the security features SF.MEM_ACC and SF.SFR_ACC. SF.FIRMWARE: Firmware Support SF.FIRMWARE (Firmware Operating System) implements specific basic support functionality for the Security IC Embedded Software. The basic support functionality is implemented in a way that the protection and separation of the different type of User Data is enforced. The security feature SF.FIRMWARE is based on the security features SF.MEM_ACC, SF.SFR_ACC and SF.FFW. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 112 / 129 7.1.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB The security features of the P6021M VB/P6021D VB/P6021J VB include the security features of the P6021P VB, except for SF.FFW and SF.FIRMWARE. The security features SF.FFW and SF.FIRMWARE of the P6021M VB/P6021D VB/P6021J VB are described in this section. SF.FFW: Firmware Firewall SF.FFW (Protected Firmware Mode) implements a mechanism to protect the application data of the different firmware applications (NXP firmware functionality and MIFARE Software) running in Firmware Mode by means of a firewall separating the application data between each other. The firewall mechanism is based on the security features SF.MEM_ACC and SF.SFR_ACC. SF.FIRMWARE: Firmware Support SF.FIRMWARE (Firmware Operating System) implements specific basic support functionality for the Security IC Embedded Software. The basic support functionality is implemented in a way that the protection and separation of the different type of User Data is enforced. The security feature SF.FIRMWARE is based on the security features SF.MEM_ACC, SF.SFR_ACC and SF.FFW. The support comprise • the integrity protection of the data stored in the EEPROM, • the baud rate configuration for the contactless operation, • the enabling / disabling of MIFARE Software, • the start of MIFARE Software contactless operation, • the control of exit conditions for MIFARE Software, • the MIFARE Post Delivery Configuration, • the MIFARE Remote Interface. 7.2 TOE Summary Specification Rationale 7.2.1 Mapping of Security Functional Requirements and the TOE Security Functionality 7.2.1.1 NXP Secure Smart Card Controller P6021P VB The following table provides a mapping of portions of the TOE security functionality to the Security Functional Requirements of the P6021P VB. The mapping is described in detail in the text following table. Table 39. Mapping of Security Functional Requirements and the portions of the Security Functionality of the P6021P VB SS. RNG SS.T DES SS. AES SF. OPC SF. PHY SF. LOG SF.C OMP SF.M EM_ ACC SF. SFR_ ACC SF. FFW SF.FI RMW ARE SS.R ECO NFIG SF. PUF FAU_SAS.1[HW] X FCS_RNG.1[HW] X FDP_IFC.1 O O O X FDP_ITT.1 O O O X FPT_ITT.1 O O O X FMT_LIM.1 X FMT_LIM.2 X X X NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 113 / 129 SS. RNG SS.T DES SS. AES SF. OPC SF. PHY SF. LOG SF.C OMP SF.M EM_ ACC SF. SFR_ ACC SF. FFW SF.FI RMW ARE SS.R ECO NFIG SF. PUF FPT_FLS.1 O O X O O O FRU_FLT.2 X FPT_PHP.3 X FCS_COP.1[TDES] X FCS_CKM.4[TDES] X FCS_COP.1[AES] X FCS_CKM.4[AES] X FDP_ACC.1[MEM] X X FDP_ACC.1[SFR] X X FDP_ACF.1[MEM] X X FDP_ACF.1[SFR] X X FMT_MSA.1[MEM] X X FMT_MSA.1[SFR] X X FMT_MSA.3[MEM] X X FMT_MSA.3[SFR] X X FMT_SMF.1[HW] X X X X FDP_SDI.2[HW] X FDP_SDI.2[FW] X FDP_SDI.2[EEPROM] X FDP_SDI.2[RAM] X FDP_SDI.2[ROM] X FDP_SDC.1[EEPROM] X FDP_SDC.1[RAM] X FCS_CKM.1[PUF] X FCS_CKM.4[PUF] X FCS_COP.1[PUF_AES] X FCS_COP.1[PUF_MAC] X "X" in the table above means that the specific portion of the TOE security functionality realises the functionality required by the respective Security Functional Requirement. “O” in the table above means that the specific portion of the TOE security functionality supports the functionality required by the respective Security Functional Requirement. As already stated in the definition of the portions of the TOE security functionality there are additional security mechanisms, which can contribute to security functionality when they are appropriately controlled by the Security IC Embedded Software. E.g. the Fame2 coprocessor can be used to implement leakage resistant asymmetric cryptographic algorithms. As part of the Security IC Dedicated Software the NXP firmware functionality is separated from the Security IC Embedded Software by memory partitioning according to SF.MEM_ACC, SF.FFW and by CPU mode control according to SF.SFR_ACC and SF.COMP. The data exchange areas are also controlled by SF.MEM_ACC and SF.FFW and must be configured by the Security IC Embedded Software. This ensures that the OS Emulation functionality does not violate the TSF. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 114 / 129 7.2.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB Mapping of Security Functional Requirements and the Security Functionality of the P6021M VB/P6021D VB/P6021J VB include Table 39. In addition, the following table provides an additional mapping of the portions of the TOE security functionality to the Security Functional Requirements of the P6021M VB/P6021D VB/P6021J VB. The mapping is described in the text following table in details. Table 40. Mapping of Security Functional Requirements and the portions of the Security Functionality of the P6021M VB/P6021D VB/P6021J VB SS. MFP_ AUTH SS. MFP_ ACC_ CTRL SS. MFP_ ENC SS. MFP_ MAC SS. DF_ AUTH SS. DF_ ACC_ CTRL SS. DF_ ENC SS. DF_ MAC SS. DF_ TRANS FCS_COP.1[MFP_AES] X X X FDP_ACC.1[MFP] X X X FDP_ACF.1[MFP] X X X FMT_MSA.1[MFP] X FMT_MSA.3[MFP] X FMT_SMF.1[MFP] X X FMT_SMR.1[MFP] X X FDP_ITC.2[MFP] X FPT_TDC.1[MFP] X FIA_UID.2[MFP] X FIA_UAU.2[MFP] X FIA_UAU.5[MFP] X FTP_TRP.1[MFP] X X X FCS_CKM.4[MFP] X FPT_RPL.1[MFP] X X FCS_COP.1[DF_AES] X X X FCS_COP.1[DF_TDES] X FDP_ACC.1[DF] X FDP_ACF.1[DF] X FMT_MSA.1[DF] X FMT_MSA.3[DF] X FMT_SMF.1[DF] X X FMT_SMR.1[DF] X X FDP_ITC.2[DF] X X FPT_TDC.1[DF] X FIA_UID.2[DF] X FIA_UAU.2[DF] X FIA_UAU.5[DF] X FTP_TRP.1[DF] X X X FCS_CKM.4[DF] X X FPT_RPL.1[DF] X X FDP_ROL.1[DF] X NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 115 / 129 "X" in the table above means that the specific portion of the TOE security functionality realises the functionality required by the respective Security Functional Requirement. “O” in the table above means that the specific portion of the TOE security functionality supports the functionality required by the respective Security Functional Requirement. As already stated in the definition of the portions of the TOE security functionality there are additional security mechanisms, which can contribute to security functionality when they are appropriately controlled by the Security IC Embedded Software. E.g. the Fame2 coprocessor can be used to implement leakage resistant asymmetric cryptographic algorithms. The MIFARE Software is part of the IC Dedicated Software and is therefore separated from the Security IC Embedded Software by memory partitioning according to SF.MEM_ACC, SF.FFW and by CPU mode control according to SF.SFR_ACC and SF.COMP. The data exchange areas are also controlled by SF.MEM_ACC and SF.FFW and must be configured by the Security IC Embedded Software. 7.2.2 Rationale for the portions of the TOE security functionality Details deleted here, available only in the full version of the Security Target. 7.2.3 Security architectural information Details deleted here, available only in the full version of the Security Target. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 116 / 129 8 Annexes 8.1 Further Information contained in the PP Chapter 7 of the PP "Security IC Platform Protection Profile" [6] provides further information. Section 7.1 in [6] describes the development and production process of Security ICs including a detailed life-cycle description and a description of the assets of the IC Designer/Manufacturer. Section 7.2 in [6] comprises security aspects of the Security IC Embedded Software, i.e. further information regarding A.Resp-Appl and examples of specific Functional Requirements for the Security IC Embedded Software. Section 7.3 in [6] contains examples of Attack Scenarios. 8.2 Glossary and Vocabulary Administrator (in the sense of the Common Criteria) The TOE may provide security functionality which can or need to be administrated (i) by the Security IC Embedded Software or (ii) using services of the TOE after delivery to Phases 4-6. Then a privileged user (in the sense of the Common Criteria, refer to definition below) becomes an administrator. Application Data All data managed by the Security IC Embedded Software in the application context. Application data comprise all data in the final Security IC. Boot Mode CPU mode of the TOE dedicated to start-up and reset of the TOE. This mode is not accessible for the Security IC Embedded Software. Composite Product Integrator Role installing or finalising the IC Embedded Software and the applications on platform transforming the TOE into the unpersonalised Composite Product after TOE delivery. The TOE Manufacturer may implement IC Embedded Software delivered by the Security IC Embedded Software Developer before TOE delivery (e.g. if the IC Embedded Software is implemented in ROM or is stored in the non-volatile memory as service provided by the IC Manufacturer or IC Packaging Manufacturer). Composite Product Manufacturer The Composite Product Manufacturer has the following roles (i) the Security IC Embedded Software Developer (Phase 1), (ii) the Composite Product Integrator (Phase 5) and (iii) the Personaliser (Phase 6). If the TOE is delivered after Phase 3 in form of wafers or sawn wafers (dice) he has the role of the IC Packaging Manufacturer (Phase 4) in addition. The customer of the TOE Manufacturer, who receives the TOE during TOE Delivery. The Composite Product Manufacturer includes the Security IC Embedded Software developer and all roles after TOE Delivery up to Phase 6 (refer to [6], Figure 2 on page 240H10 and Section 7.1.1) CPU mode Mode in which the CPU operates. The TOE supports five CPU modes, which are Boot Mode, Test Mode, Firmware Mode, System Mode and User Mode. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 117 / 129 DESFire DESFire EV1 emulation, names the DESFire OS as part of the IC Dedicated Software. Administrator (in the sense of the Common Criteria) The TOE may provide security functionality which can or need to be administrated (i) by the Security IC Embedded Software or (ii) using services of the TOE after delivery to Phases 4-6. Then a privileged user (in the sense of the Common Criteria, refer to definition below) becomes an administrator. FabKey Area A memory area in the EEPROM containing data, which are programmed during testing by the IC Manufacturer. The amount of data and the type of information can be selected by the customer. Firmware Mode CPU mode of the TOE dedicated to execution of the Firmware with MIFARE Software, which is part of the IC Dedicated Support Software. This mode is not accessible for the Security IC Embedded Software. End-consumer User of the Composite Product in Phase 7 Initialisation Data Initialisation Data defined by the TOE Manufacturer to identify the TOE and to keep track of the Security IC’s production and further life-cycle phases are considered as belonging to the TSF data. These data are for instance used for traceability and for TOE identification (identification data). If "Package Authentication of the Security IC" is used the Initialisation data contain the confidential authentication verification data of the IC. If the "Package 2: Loader dedicated for usage by authorized users only" may contain the authentication verification data or key material for the trusted channel between the TOE and the authorized users using the Loader. Integrated Circuit (IC) Electronic component(s) designed to perform processing and/or memory functions. kByte(s) / (KB) kByte (KB) used with k=1024 (K=1024) Memory IC hardware component, that stores code and/or data, i.e. ROM, RAM or EEPROM of the TOE. Memory Management Unit The MMU maps the virtual addresses used by the CPU into the physical addresses of RAM, ROM and EEPROM. This mapping is done based on (a) memory partitioning and (b) memory segments for code running in User Mode. Memory partitioning is fixed, whereas up to 64 memory segments can be configured individually. Each segment can be (i) positioned and sized (ii) enabled and disabled, (iii) configured for access rights in terms of read, write and execute in User Mode and (iv) configured for User Mode access rights to Special Function Registers related to hardware components of code executed in this segment. Memory Segment Address space provided by the Memory Management Unit according to the configuration in the MMU Segment Table. A memory segment defines a memory area, are NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 118 / 129 accessible for code running in User Mode. Memory segments may address RAM, ROM and EEPROM. MIFARE Contactless smartcard interface standard complying with ISO/IEC 14443 A. MIFARE Plus MIFARE Plus emulation, names the MIFARE Plus OS (MIFARE Plus MF1PLUSx0) as part of the IC Dedicated Software. MIFARE Software Term is used whenever MIFARE Plus MF1PLUSx0 or MIFARE DESFire EV1 is meant. MMU Segment Table This structure defines the memory segments for code running in User Mode, which are controlled by the MMU. The structure can be located anywhere in the memory that is available in System Mode. It also contains User Mode access rights to Special Function Registers related to hardware components of code executed in each segment. Pre-personalisation Data Any data supplied by the Card Manufacturer that is injected into the non-volatile memory by the Integrated Circuits manufacturer (Phase 3). These data are for instance used for traceability and/or to secure shipment between phases. S²C Smartcard interface standard complying with ISO/IEC 18092. Security IC (as used in the PP [6]) Composition of TOE, Security IC Embedded Software, user data of the Composite TOE and package (Security IC carrier). IC Dedicated Software IC proprietary software embedded in a Security IC (also known as IC firmware) and developed by the IC Developer. Such software is required for testing purpose (IC Dedicated Test Software) but may provide additional services to facilitate usage of the hardware and/or to provide additional services (IC Dedicated Support Software). IC Dedicated Test Software That part of the IC Dedicated Software (refer to above) which is used to test the TOE before TOE Delivery but which does not provide any functionality thereafter. Security IC Embedded Software Software embedded in a Security IC and normally not being developed by the IC Designer. The Security IC Embedded Software is designed in Phase 1 and embedded into the Security IC in Phase 3 or in later phases of the Security IC product life-cycle. Some part of that software may actually implement a Security IC application others may provide standard services. Nevertheless, this distinction does not matter here so that the Security IC Embedded Software can be considered as being application dependent whereas the IC Dedicated Software is definitely not. Security IC Product Composite product which includes the Security Integrated Circuit (i.e. the TOE) and the Embedded Software and is evaluated as composite target of evaluation in the sense of the Supporting Document NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 119 / 129 Secured Environment Operational environment maintains the confidentiality and integrity of the TOE as addressed by OE.Process- Sec-IC and the confidentiality and integrity of the IC Embedded Software, TSF data or user data associated with the smartcard product by security procedures of the smartcard product manufacturer, personaliser and other actors before delivery to the smartcard end-user depending on the smartcard life-cycle. Security Rows Top-most 256 bytes of the EEPROM memory reserved for configuration purposes as well as dedicated memory area for the Security IC Embedded Software to store life- cycle information about the TOE. Special Function Registers Registers used to access and configure the functions for communication with an external interface device, the cryptographic coprocessors for Triple-DES or AES, the Fame2 coprocessor for basic arithmetic functions to perform asymmetric cryptographic algorithms, the random numbers generator and chip configuration. Super System Mode This term represents either Boot Mode, Test Mode or Firmware Mode. System Mode CPU mode of the TOE with unrestricted access to the hardware resources. The Memory Management Unit can be configured in System Mode. Test Features All features and functions (implemented by the IC Dedicated Test Software and/or hardware) which are designed to be used before TOE Delivery only and delivered as part of the TOE. Test Mode CPU mode of the TOE for its configuration and execution of the IC Dedicated Test Software. The Test Mode is permanently and irreversible disabled after production testing. Specific Special Function Registers are accessible in Test Mode for test purposes. TOE Delivery The period when the TOE is delivered which is (refer to [6], Figure 2 on page 242H10) either (i) after Phase 3 (or before Phase 4) if the TOE is delivered in form of wafers or sawn wafers (dice) or (ii) after Phase 4 (or before Phase 5) if the TOE is delivered in form of packaged products. TOE Manufacturer The TOE Manufacturer must ensure that all requirements for the TOE (as defined in [6], Section 1.2.2) and its development and production environment are fulfilled (refer to [6], Figure 2 on page 10). The TOE Manufacturer has the following roles: (i) IC Developer (Phase 2) and (ii) IC Manufacturer (Phase 3). If the TOE is delivered after Phase 4 in form of packaged products, he has the role of the (iii) IC Packaging Manufacturer (Phase 4) in addition. TSF data Data for the operation of the TOE upon which the enforcement of the SFR relies. They are created by and for the TOE, that might affect the operation of the TOE. This includes information about the TOE’s configuration, if any is coded in non-volatile non-programmable memories (ROM), in non-volatile programmable NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 120 / 129 memories (for instance EEPROM or flash memory), in specific circuitry or a combination thereof. User (in the sense of the Common Criteria) The TOE serves as a platform for the Security IC Embedded Software. Therefore, the “user” of the TOE (as used in the Common Criteria assurance class AGD: guidance) is the Security IC Embedded Software. Guidance is given for the Security IC Embedded Software Developer. On the other hand the Security IC (with the TOE as a major element) is used in a terminal where communication is performed through the ISO/IEC interface provided by the TOE. Therefore, another “user” of the TOE is the terminal (with its software). User Data of the Composite TOE All data managed by the Smartcard Embedded Software in the application context. User Data of the TOE Data for the user of the TOE, that does not affect the operation of the TSF. From the point of view of TOE defined in this PP the user data comprises the Security IC Embedded Software and the user data of the Composite TOE. User Mode CPU mode of the TOE. Access to memories is controlled by the Memory Management Unit. Access to Special Function Registers is restricted. 8.3 List of Abbreviations ACK Acknowledge CC Common Criteria Version 3.1 CCDB Common Criteria Development Board CIU Contactless Interface Unit CPU Central Processing Unit CPU_CSR CPU Status Register DEA Data Encryption Algorithm DES Data Encryption Standard DRNG Deterministic Random Number Generator EAL Evaluation Assurance Level ECC Elliptic Curve Cryptography ECD Extended Component Definition acc. CC, part 3[3] FVEC Firmware VECtor FOS Firmware Operating System IC Integrated circuit IT Information Technology MFP MIFARE Plus MMU Memory Management Unit MX Memory eXtension NAK Not ACK NDA Non Disclosure Agreement NFC Near Field Communication PDC Post Delivery Configuration PKC Public Key Cryptography PP Protection Profile NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 121 / 129 PUF Physical Unclonable Function SAR Security Assurance Requirement SFR as abbreviation of the CC term: Security Functional Requirement, as abbreviation of the technical term of the SmartMX2 family: Special Function Register 159 SIM Subscriber Identity Module SOF Strength of Function SF Security Feature SS Security Service ST Security Target TOE Target of Evaluation TRNG True Random Number Generator TSF TOE Security Functionality TSFI TSF Interface TSP TOE Security Policy UART Universal Asynchronous Receiver and Transmitter 159 To avoid confusion this Security Target does not use SFR as abbreviation for Special Function Register in the explanatory text. However, the abbreviation is used in objective or security functionality identifiers and to distinguish iterations. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 122 / 129 9 Bibliography 9.1 Evaluation documents [1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 4, September 2012, CCMB-2012-09-001 [2] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-002 [3] Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-003 [4] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, September 2012, CCMB-2012-09-004 [5] Supporting Document Mandatory Technical Document Application of Attack Potential to Smartcards, Version 2.9, May 2013, CCDB-2013-05-002 [6] Security IC Platform Protection Profile with Augmentation Packages, Version 1.0, registered and certified by Bundesamt fuer Sicherheit in der Informationstechnik (BSI) under the reference BSI-PP-0084-2014 [7] Evaluation of random number generators, Version 0.8, Bundesamt für Sicherheit in der Informationstechnik [8] A proposal for: Functionality classes for random number generators, Version 2.0, 18 September 2011 9.2 Developer documents [9] Product Data Sheet SmartMX2 family P6021y VB, Secure high-performance smart card controller, NXP Semiconductors [10] Instruction Set for the SmartMX2 family, Secure smart card controller, NXP Semiconductors, Document Number 1478** [11] Information on Guidance and Operation, NXP Secure Smart Card Controller P6021y VB, NXP Semiconductors [12] Product data sheet addendum - SmartMX2 P6021y VB, Wafer and delivery specification, NXP Semiconductors, Document Number 3222** [13] Order Entry Form P6021y VB, NXP Semiconductors, online document [14] Product Data Sheet - MIFARE Plus Functionality of implementations on smart card controllers, NXP Semiconductors, Document Number 2062** [15] Product Data Sheet - MIFARE DESFire EV1 Functionality of implementations on smart card controllers, NXP Semiconductors, Document Number 2258** [16] Product Data Sheet Addendum - SmartMX2P602xy VB family, Firmware Interface Specification, NXP Semiconductors, Document Number 2997** [17] Firmware Interface Specification Addendum - SmartMX2P602xy VB family, Firmware Interface Specification Addendum, NXP Semiconductors, Document Number 3741** [18] MIFARE Plus MF1PLUSx0 Guidance and Operation Manual, NXP Secure Smart Card Controller P602xy, NXP Semiconductors, Document Number 2335** [19] MIFARE DESFire EV1 Guidance and Operation Manual, NXP Secure Smart Card Controller P602xy, NXP Semiconductors, Document Number 2400** [20] P602x Family PUF Key Derivation - Specification NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 123 / 129 9.3 Other documents [21] FIPS PUB 197 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, ADVANCED ENCRYPTION STANDARD (AES), National Institute of Standards and Technology, 2001 November 26 [22] ISO/IEC 7816-2:1996 Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 2: Dimensions and location of contacts [23] ISO/IEC 14443-3:2001: Identification cards - Contactless integrated circuit(s) cards - Proximity cards - Part 3: Initialization and anticollision [24] NIST SP 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, revised January 2012, National Institute of Standards and Technology [25] NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques, December 2001, Morris Dworkin, National Institute of Standards and Technology [26] NIST Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, May 2005, Morris Dworkin, National Institute of Standards and Technology [27] ISO/IEC 9797-1: 2011 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 124 / 129 10 Legal information 10.1 Definitions Draft — The document is a draft version only. The content is still under internal review and subject to formal approval, which may result in modifications or additions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included herein and shall have no liability for the consequences of use of such information. 10.2 Disclaimers Limited warranty and liability — Information in this document is believed to be accurate and reliable. However, NXP Semiconductors does not give any representations or warranties, expressed or implied, as to the accuracy or completeness of such information and shall have no liability for the consequences of use of such information. NXP Semiconductors takes no responsibility for the content in this document if provided by an information source outside of NXP Semiconductors. In no event shall NXP Semiconductors be liable for any indirect, incidental, punitive, special or consequential damages (including - without limitation - lost profits, lost savings, business interruption, costs related to the removal or replacement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory. Notwithstanding any damages that customer might incur for any reason whatsoever, NXP Semiconductors’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors. Right to make changes — NXP Semiconductors reserves the right to make changes to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publication hereof. Suitability for use — NXP Semiconductors products are not designed, authorized or warranted to be suitable for use in life support, life-critical or safety-critical systems or equipment, nor in applications where failure or malfunction of an NXP Semiconductors product can reasonably be expected to result in personal injury, death or severe property or environmental damage. NXP Semiconductors and its suppliers accept no liability for inclusion and/or use of NXP Semiconductors products in such equipment or applications and therefore such inclusion and/or use is at the customer’s own risk. Applications — Applications that are described herein for any of these products are for illustrative purposes only. NXP Semiconductors makes no representation or warranty that such applications will be suitable for the specified use without further testing or modification. Export control — This document as well as the item(s) described herein may be subject to export control regulations. Export might require a prior authorization from competent authorities. 10.3 Trademarks Notice: All referenced brands, product names, service names and trademarks are the property of their respective owners. Adelante, Bitport, Bitsound, CoolFlux, CoReUse, DESFire, EZ-HV, FabKey, GreenChip, HiPerSmart, HITAG, I²C-bus logo, ICODE, I-CODE, ITEC, Labelution, MIFARE, MIFARE Plus, MIFARE Ultralight, MoReUse, QLPAK, Silicon Tuner, NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 125 / 129 SiliconMAX, SmartXA, STARplug, TOPFET, TrenchMOS, TriMedia and UCODE — are trademarks of NXP Semiconductors N.V. HD Radio and HD Radio logo — are trademarks of iBiquity Digital Corporation. NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 126 / 129 Tables Tab. 1. TOE Components for P6021P VB ..................... 8 Tab. 2. Additional TOE components for P6021M VB ..... 9 Tab. 3. Additional TOE components for P6021D VB ....10 Tab. 4. Evaluated minor configuration options for NXP Secure Smart Card Controller P6021P VB .................................................................... 11 Tab. 5. Additional evaluated minor configuration options for P6021M VB ....................................13 Tab. 6. Additional evaluated minor configuration options for P6021D ..........................................14 Tab. 7. Additional evaluated minor configuration options for P6021J VB .....................................14 Tab. 8. Hardware Post Delivery Configuration for P6021P VB ...................................................... 15 Tab. 9. MIFARE Post Delivery Configuration for P6021M ............................................................16 Tab. 10. MIFARE Post Delivery Configuration for P6021D ............................................................ 16 Tab. 11. Variable definitions for commercial type names .............................................................. 17 Tab. 12. Supported Package Types .............................. 17 Tab. 13. Variable definitions for commercial type names .............................................................. 18 Tab. 14. Supported Package Types .............................. 19 Tab. 15. CPU modes of the TOE ...................................20 Tab. 16. System Resources of P6021M VB/P6021D VB/P6021J VB .................................................21 Tab. 17. Package claim ................................................. 31 Tab. 18. Threats defined by the PP [6] ..........................34 Tab. 19. Assumptions defined in the PP [6] ...................37 Tab. 20. Security objectives defined in the PP [6] ..........39 Tab. 21. Security objectives for the Security IC Embedded Software, taken from the PP [6] .....41 Tab. 22. Security objectives for the operational environment, taken from the PP [6] ................. 42 Tab. 23. Security Objectives versus Assumptions, Threats or Policies (PP [6]) ............................. 43 Tab. 24. Additional Security Objectives versus Assumptions, Threats or Policies .....................43 Tab. 25. Additional Security Objectives versus Assumptions, Threats or Policies (MIFARE Software) ..........................................................44 Tab. 26. SFRs taken from the PP [6] .............................50 Tab. 27. Mapping of Security Functional Requirements to evaluated configurations P6021M VB/P6021D VB/P6021J VB ............... 83 Tab. 28. Comparison of SFRs of the P6021P VB and P6021M VB/P6021D VB/P6021J VB ............... 84 Tab. 29. Security Assurance Requirements for EAL6+ .............................................................. 85 Tab. 30. Security Assurance Requirements, overview of differences of refinements ........................... 86 Tab. 31. Security Assurance Requirements for EAL5+ .............................................................. 88 Tab. 32. Security Assurance Requirements, overview of differences of refinements ........................... 89 Tab. 33. Security Requirements versus Security Objectives ........................................................ 90 Tab. 34. Mapping of security objectives and requirements .................................................... 90 Tab. 35. Mapping of security objectives and requirements .................................................... 94 Tab. 36. Dependencies of security functional requirements .................................................... 96 Tab. 37. Dependencies of security functional requirements (MIFARE Plus MF1PLUSx0) ......97 Tab. 38. Dependencies of security functional requirements (MIFARE DESFire EV1) .............98 Tab. 39. Mapping of Security Functional Requirements and the portions of the Security Functionality of the P6021P VB ....... 112 Tab. 40. Mapping of Security Functional Requirements and the portions of the Security Functionality of the P6021M VB/ P6021D VB/P6021J VB .................................114 NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 127 / 129 Figures Fig. 1. Block Diagram of NXP Secure Smart Card Controller P6021y VB ........................................ 7 Fig. 2. Logical boundary of the TOE P6021y VB ........ 23 NXP Semiconductors P6021y VB Security Target Lite P6021y VB All information provided in this document is subject to legal disclaimers. © NXP Semiconductors N.V. 2016. All rights reserved Evaluation document Rev. 1.51 — 19 July 2016 PUBLIC 128 / 129 Contents 1 ST Introduction .................................................... 3 1.1 ST Reference .....................................................3 1.2 TOE Reference .................................................. 3 1.3 TOE Overview ....................................................3 1.3.1 Configuration of the TOE ................................... 3 1.3.2 Usage and major security functionality of the P6021P VB .........................................................3 1.3.3 Usage and major security functionality of the P6021M VB/P6021D VB/P6021J VB ................. 5 1.3.4 TOE Type ...........................................................6 1.3.5 Required non-TOE hardware/software/ firmware ..............................................................7 1.4 TOE Description .................................................7 1.4.1 Physical Scope of TOE ......................................7 1.4.1.1 NXP Secure Smart Card Controller P6021P VB .......................................................................7 1.4.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ................................7 1.4.1.3 TOE Components .............................................. 8 1.4.1.3.1 NXP Secure Smart Card Controller P6021P VB .......................................................................8 1.4.1.3.2 NXP Secure Smart Card Controller P6021M VB .......................................................................9 1.4.1.3.3 NXP Secure Smart Card Controller P6021D VB .....................................................................10 1.4.1.3.4 NXP Secure Smart Card Controller P6021J VB .....................................................................10 1.4.2 Evaluated configurations ..................................10 1.4.2.1 Major configuration options .............................. 10 1.4.2.1.1 NXP Secure Smart Card Controller P6021P VB .....................................................................10 1.4.2.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................11 1.4.2.2 Minor configuration options .............................. 11 1.4.2.2.1 NXP Secure Smart Card Controller P6021P VB .....................................................................11 1.4.2.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................13 1.4.2.3 Post Delivery Configuration ..............................14 1.4.2.3.1 NXP Secure Smart Card Controller P6021P VB .....................................................................15 1.4.2.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................15 1.4.2.4 Evaluated package types .................................16 1.4.2.4.1 NXP Secure Smart Card Controller P6021P VB .....................................................................16 1.4.2.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................18 1.4.3 Logical Scope of TOE ......................................20 1.4.3.1 Hardware description ....................................... 20 1.4.3.2 Software description .........................................22 1.4.3.2.1 NXP Secure Smart Card Controller P6021P VB .....................................................................23 1.4.3.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................23 1.4.3.3 Documentation ................................................. 26 1.4.3.3.1 NXP Secure Smart Card Controller P6021P VB .....................................................................26 1.4.3.3.2 NXP Secure Smart Card Controller P6021M VB .....................................................................26 1.4.3.3.3 NXP Secure Smart Card Controller P6021D VB .....................................................................27 1.4.3.3.4 NXP Secure Smart Card Controller P6021J VB .....................................................................27 1.4.4 Security during development and production ....27 1.4.5 TOE intended usage ........................................ 28 1.4.5.1 NXP Secure Smart Card Controller P6021P VB .....................................................................28 1.4.5.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................28 1.4.6 Interface of the TOE ........................................ 29 1.4.6.1 NXP Secure Smart Card Controller P6021P VB .....................................................................29 1.4.6.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................30 2 Conformance claims ......................................... 31 2.1 CC conformance claim .....................................31 2.2 Package claim ..................................................31 2.3 PP claim ...........................................................31 2.4 Conformance claim rationale ............................32 3 Security Problem Definition ..............................33 3.1 Description of Assets ....................................... 33 3.1.1 NXP Secure Smart Card Controller P6021P VB .....................................................................33 3.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................33 3.2 Threats ............................................................. 33 3.2.1 NXP Secure Smart Card Controller P6021P VB .....................................................................34 3.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................35 3.3 Organizational Security Policies .......................35 3.3.1 NXP Secure Smart Card Controller P6021P VB .....................................................................35 3.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................36 3.4 Assumptions .....................................................37 3.4.1 NXP Secure Smart Card Controller P6021P VB .....................................................................37 3.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................37 4 Security Objectives ........................................... 39 4.1 Security Objectives for the TOE .......................39 4.1.1 NXP Secure Smart Card Controller P6021P VB .....................................................................39 4.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................40 4.2 Security Objectives for the Security IC Embedded Software .........................................41 4.3 Security Objectives for the Operational Environment ..................................................... 41 4.3.1 NXP Secure Smart Card Controller P6021P VB .....................................................................42 4.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................42 4.4 Security Objectives Rationale .......................... 43 4.4.1 NXP Secure Smart Card Controller P6021P VB .....................................................................43 4.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................44 5 Extended Components Definition .................... 48 6 Security Requirements ......................................49 6.1 Security Functional Requirements ....................49 NXP Semiconductors P6021y VB Security Target Lite 6.1.1 NXP Secure Smart Card Controller P6021P VB .....................................................................49 6.1.1.1 SFRs of the Protection Profile ..........................49 6.1.1.2 Additional SFRs regarding cryptographic functionality .......................................................56 6.1.1.3 Additional SFRs regarding access control ........57 6.1.1.4 Mapping of Security Functional Requirements to evaluated configurations of P6021P VB .......................................................66 6.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................66 6.1.2.1 Additional SFRs for the MIFARE Plus MF1PLUSx0 ..................................................... 66 6.1.2.2 Additional SFRs for the MIFARE DESFire EV1 ...................................................................74 6.1.2.3 Mapping of Security Functional Requirements to evaluated configurations P6021M VB/P6021D VB/P6021J VB ................83 6.1.3 Comparison of SFRs of the P6021P VB and P6021M VB/P6021D VB/P6021J VB ................84 6.2 Security Assurance Requirements ................... 84 6.2.1 NXP Secure Smart Card Controller P6021P VB (EAL6+) ...................................................... 84 6.2.1.1 Refinements of the Security Assurance Requirements for EAL6+ ..................................85 6.2.1.1.1 Refinements regarding CM scope (ALC_CMS) ...................................................... 86 6.2.1.1.2 Refinements regarding CM capabilities (ALC_CMC) ......................................................86 6.2.1.1.3 Refinements regarding functional specification (ADV_FSP) ..................................86 6.2.1.1.4 Refinements regarding Implementation Representation (ADV_IMP.2) ...........................87 6.2.1.1.5 Refinements regarding Test Coverage (ATE_COV.3) ................................................... 87 6.2.1.2 Definition of ADV_SPM ....................................87 6.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB (EAL5+) ................87 6.2.2.1 Refinements of the Security Assurance Requirements for EAL5+ ..................................88 6.2.2.1.1 Refinements regarding CM scope (ALC_CMS) ...................................................... 89 6.2.2.1.2 Refinements regarding functional specification (ADV_FSP) ..................................89 6.3 Security Requirements Rationale .....................90 6.3.1 Rationale for the Security Functional Requirements ................................................... 90 6.3.1.1 NXP Secure Smart Card Controller P6021P VB .....................................................................90 6.3.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................93 6.3.2 Dependencies of security functional requirements .....................................................96 6.3.2.1 NXP Secure Smart Card Controller P6021P VB .....................................................................96 6.3.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ..............................97 6.3.3 Rationale for the Security Assurance Requirements ................................................... 98 6.3.3.1 NXP Secure Smart Card Controller P6021P VB .....................................................................98 6.3.3.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB (EAL5+) ................99 6.3.4 Security Requirements are Internally Consistent .........................................................99 6.3.4.1 NXP Secure Smart Card Controller P6021P VB .....................................................................99 6.3.4.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ............................100 7 TOE Summary Specification ...........................101 7.1 Portions of the TOE Security Functionality .....101 7.1.1 Security Services of the TOE .........................101 7.1.1.1 NXP Secure Smart Card Controller P6021P VB ...................................................................101 7.1.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ............................102 7.1.1.2.1 Security Services of MIFARE Plus MF1PLUSx0 ................................................... 102 7.1.1.2.2 Security Services of MIFARE DESFire EV1 ... 104 7.1.2 Security Features ........................................... 106 7.1.2.1 NXP Secure Smart Card Controller P6021P VB ...................................................................106 7.1.2.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ............................112 7.2 TOE Summary Specification Rationale .......... 112 7.2.1 Mapping of Security Functional Requirements and the TOE Security Functionality ................................................... 112 7.2.1.1 NXP Secure Smart Card Controller P6021P VB ...................................................................112 7.2.1.2 NXP Secure Smart Card Controller P6021M VB/P6021D VB/P6021J VB ............................114 7.2.2 Rationale for the portions of the TOE security functionality .....................................................115 7.2.3 Security architectural information ................... 115 8 Annexes ............................................................116 8.1 Further Information contained in the PP .........116 8.2 Glossary and Vocabulary ............................... 116 8.3 List of Abbreviations .......................................120 9 Bibliography .....................................................122 9.1 Evaluation documents ....................................122 9.2 Developer documents .................................... 122 9.3 Other documents ............................................123 10 Legal information .............................................124 10.1 Definitions .......................................................124 10.2 Disclaimers .....................................................124 10.3 Trademarks .................................................... 124 © NXP Semiconductors N.V. 2016. All rights reserved For more information, please visit: http://www.nxp.com For sales office addresses, please send an email to: salesaddresses@nxp.com Released on 19 July 2016