MF1P(H)x2 Security Target Lite Rev. 2.2 — 7 November 2022 Evaluation document NSCIB-CC-0011956 PUBLIC Document information Information Content Keywords Common Criteria, Security Target, MF1P(H)x2, MIFARE Plus EV2 Abstract Evaluation of the MF1P(H)x2 developed and provided by NXP Semiconductors, Business Line Connectivity & Security, according to the Common Criteria for Information Technology Evaluation Version 3.1 at EAL5 augmented NXP Semiconductors MF1P(H)x2 Security Target Lite Revision History Revision Date Description 2.2 2022-11-07 Updated references in Table 1 Minor editorial update after evaluator comments 2.1 2022-09-09 Derived from full Security Target Rev. 2.1 Updated references in Table 1 2.0 2020-06-05 Derived from full Security Target Rev. 2.0 1.0 2020-03-18 Derived from full Security Target Rev. 1.4 MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 2 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 1 Introduction 1.1 ST Reference MF1P(H)x2 Security Target Lite, Version 2.2, NXP Semiconductors, 7 November 2022. 1.2 TOE Reference NXP Secure Smart Card Controller MF1P(H)x2. 1.3 TOE Overview NXP has developed the MF1P(H)x2 to be used with Proximity Coupling Devices (PCDs, also called "terminal") according to ISO 14443 Type A. The communication protocol complies to part ISO 14443-4. The MF1P(H)x2 is primarily designed for secure contactless transport applications and related loyalty programs as well as access control management systems. It fully complies with the requirements for fast and highly secure data transmission, flexible data storage and interoperability with existing infrastructure. The TOE is a smart card comprising a hardware platform and a fixed software package. The software package is stored in Flash and ROM memory and provides an operating system with a set of functions, used to manage the data stored in Flash memory. The TOE includes also IC Dedicated Software to support its start-up and for test purposes after production. The Smart Card Controller hardware comprises an 16- bit CPU, volatile and non-volatile memories, cryptographic co-processors, security components and one communication interface. The TOE includes a functional specification and a guidance document. This documentation contains a description of the hardware and software interface, the secure configuration and usage of the product by the terminal designer. The security measures of the TOE are designed to act as an integral part of the combination of hardware platform and software package in order to strengthen the product as a whole. Several security measures are completely implemented in and controlled by the hardware. Other security measures are controlled by the combination of hardware and software. 1.3.1 Required non-TOE Hardware/Software/Firmware The TOE requires an ISO 14443 card terminal to be provided with power and to receive adequate commands. 1.4 TOE Description 1.4.1 Physical Scope of the TOE The Target of Evaluation (TOE) is the smartcard integrated circuit named MF1P(H)x2 in combination with a fixed software package, the IC Dedicated Software. The TOE includes IC manufacturer proprietary IC Dedicated Test Software and IC Dedicated Support Software, according to the terminology used in the Security IC Protection Profile [6]. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 3 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Type Name Release Form of delivery IC Hardware MF1P(H)x2 Hardware A1.C03 Sawn wafer (FFC), modules (MOA4, MOA8, MOB10) IC Dedicated Test Software Test Software A1.C03 On-chip software Boot Software A1.C03 On-chip software Firmware A1.C03 On-chip software IC Dedicated Support Software MIFARE Plus Software 2.0 On-chip software Document MF1P(H)x2, MIFARE Plus EV2, Product data sheet [7] 3.4 Electronic document (PDF via NXP DocStore) Document MF1P(H)x2, MIFARE Plus EV2 Post Delivery Configuration, Preliminary data sheet addendum [8] 2.0 Electronic document (PDF via NXP DocStore) Document MF1P(H)x2, Wafer and Delivery Specification, Product data sheet addendum [9] 3.2 Electronic document (PDF via NXP DocStore) Document MF1P(H)x2, Information on Guidance and Operation, Guidance and Operation Manual [10] 1.2 Electronic document (PDF via NXP DocStore) Table 1. TOE deliverables The TOE (hardware) is shipped to the customer by NXP. The available documentation can be downloaded by customers in PDF format directly from the NXP DocStore. The customer can check the version of the IC Hardware and IC Dedicated Software by using the GetVersion APDU as described in Section 4.1 of the Wafer and Delivery Specification [9]. Additionaly, the originality of the TOE can be determined by authentication with an Originality Key, as described in Section 4.2 of the Wafer and Delivery Specification [9]. 1.4.1.1 Evaluated Configurations The TOE is available in various configurations. Each configuration has a different commerical type name. A commercial type name for the TOE has the following general format: • MF1Pcxeywdpp(p)/svff The following table illustrates the commerical type names that are subject of the evaluation: Identifier Description Assignment Meaning c input capacitance H 17 pF 70 pF x memory size 2 4 2 KB of non-volatile memory 4 KB of non-volatile memory e evolution 2 MIFARE Plus EV2 Table 2. Variable definitions for commercial type names MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 4 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Identifier Description Assignment Meaning y UID length 0 3 7 byte UID 4 byte NUID w wafer fab code 0 1 multiple (for modules) GlobalFoundries d fixed value D pp(p) package type A4 A8 A10 UD UF MOA4 module MOA8 module MOB10 module 120µm wafer 75µm wafer / separator s SW minor version (higher nibble) 0 SW minor version information v SW minor version (lower nibble) 0 SW minor version information ff Type ID A...Z, 0...9 customer data identification default type without customer data Table 2. Variable definitions for commercial type names...continued All commercial type names are subject to this evaluation. However the identifier "MF1P(H)x2" will be used in the remainder of this document to make referencing easier. All information and security functionality described in this Security Target applies to all commercial types. 1.4.2 Logical Scope of the TOE 1.4.2.1 Hardware Description The CPU of the MF1P(H)x2 has an 16-bit architecture. The on-chip hardware components are controlled by the MIFARE Plus software via Special Function Registers. These registers are correlated to the activities of the CPU, the memory management unit, interrupt control, contactless communication, Flash, timers and the AES co-processor. The communication with the MF1P(H)x2 can be performed through the contactless interface. The AES co-processor supports AES operations with a key length of 128 bit. A hardware Random Number Generator provides true random numbers which are used to seed deterministic random number generators, used internally by the MIFARE Plus functionality for security purposes. 1.4.2.2 Software Description The IC Dedicated Test Software (Test ROM Software) located in ROM of the TOE is used by the TOE Manufacturer to test the functionality of the chip. The test functionality is disabled before the operational use of the smart card. The IC Dedicated Test Software includes the test operating system, test routines for the various blocks of the circuitry and shutdown functions to ensure that security relevant test operations cannot be executed illegally after phase 3 of the TOE Life cycle. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 5 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite The TOE also contains IC Dedicated Support Software. The Boot Software which is stored in ROM is part of the IC Dedicated Support Software. This software is executed after each reset of the TOE, i.e. every time when the TOE starts. It sets up the TOE and does some basic configuration. The MIFARE Plus software is also part of the IC Dedicated Support Software and provides the main functionality of the TOE in the usage phase. The MF1P(H)x2 is primarily designed for secure contactless transport applications and related loyalty programs as well as access control systems. It fully complies with the requirements for fast and highly secure data transmission, flexible data storage and interoperability with existing infrastructure. Its functionality consists of: • 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. • Data encryption for confidentiality of the contactless communication. • Unique serial number for each device (UID) with optional random ID. • The TOE supports MIFARE Plus EV0 and EV1. The TOE features enable it to be used for a variety of applications: • Electronic fare collection. • Stored value card systems. • Access control systems. • Loyalty. If privacy is an issue, the TOE can be configured not to disclose any privacy-related information to unauthorized users. MIFARE Plus Software offers three different SecurityLevels. The higher the SecurityLevel, the more secure the MIFARE Plus Software is intended to be. In addition, each Sector is associated its corresponding SectorSecurityLevel, where the SecurityLevel equals the SectorSecurityLevel of the Sector with the lowest SectorSecurityLevel at any time. As a consequence, the TOE supports multiple SectorSecurityLevel but only one designated SecurityLevel at one time. Note that in the remainder of the document the terms SL0, SL1 and SL3 are used equivalent to the terms SecurityLevel 0, SecurityLevel 1 and SecurityLevel 3, in order to make referencing easier. For SL1 and SL3 the SecurityLevel for the TOE as a whole, as well as the SectorSecurityLevels for dedicated Sectors can be switched to a higher level. A migration, both at TOE or at Sector level, is only possible to a higher level and not to a lower one. In case dedicated sectors have been migrated to higher SectorSecurityLevels, the overall TOE behaviour must remain by default according to the lowest SectorSecurityLevel among all Sectors of the TOE. If the TOE is in SL0, this must always hold for the whole TOE, which means that all Sectors are in SectorSecurityLevel 0. The TOE is delivered as ”L1 card”, indicating that SL0, SL1 and SL3 are available. The main features of each SecurityLevel are listed below: Security level 0: The TOE does not provide any functionality besides initialization. The TOE is initialized in plaintext, especially keys for the further levels can be brought in. A TOE in SL0 is not usable for other purposes. After all mandatory keys and security attributes have been stored in the TOE, it can be switched to SL1. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 6 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Security level 1: The CardUser can access the Blocks in the TOE after an authentication procedure. The communication with the terminal is protected, however the authentication and the protected communication in this SecurityLevel are not evaluated security services of the TOE. The functionality provided by SL1 (beside the exceptions stated in the subsequent Note) does not implement any Security Functional Requirement and is therefore not in the scope of the evaluation. The TOE can be switched to SL3, dedicated Sectors can be switched to SectorSecurityLevel 3. Both actions require preceding authentication using the AES algorithm with the appropriate key. Note: The functionality provided by SL1 that is within the scope of the evulation, is all key and configuration updating in SL1 using ISOL4 commands, the originality check, and the switch of the SecurityLevel from 1 to 3, both for sectors or full VC. Security level 3: The CardUser can access the data and Value Blocks in the TOE 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 TOE cannot be switched to a different SecurityLevel. In SL3, the TOE offers two secure messaging modes: EV0 Secure Messaging and EV1 Secure Messaging. Note: All functionality provided by SecurityLevel 3 is within the scope of the evaluation. In all SecurityLevels the TOE does additionally support the so-called originality function which allows verifying the authenticity of the TOE. 1.4.2.3 Documentation The Product Data Sheet [7] contains a functional description of the communication protocol and the commands implemented by the TOE. The provided documentation can be used by a customer to develop applications using the TOE. The Product Data Sheet is supported by a User Guidance Manual [10] which gives additional guidance with regards to the secure usage of the TOE. The Wafer and Deliver Specification data sheet addendum [9] gives additional information regarding the wafer dimensions, TOE identification and delivery processes. 1.4.3 Life Cycle and Delivery of the TOE The life-cycle phases are organized according to the Security IC Platform Protection Profile with Augmentation Packages [6], Section 1.2.4: • Phase 1: IC Embedded Software Development • Phase 2: IC Development • Phase 3: IC Manufacturing • Phase 4: IC Packaging • Phase 5: Composite Product Integration • Phase 6: Personalisation • Phase 7: Operational Usage For the usage phase the MF1P(H)x2 chip will be embedded in a credit card (meaning ID-1 sized) plastic card (micro-module embedded into the plastic card) or another supported package. The module and card embedding of the TOE provide external security mechanisms because they make it harder for an attacker to access parts of the TOE for physical manipulation. Regarding the Application Note 1 of the Protection Profile [6], NXP will deliver the TOE at the end of Phase 6. Therefore the TOE evaluation perimeter comprising the development MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 7 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite and production environment of the TOE, consists of life-cycle phases 1 - 6. The TOE is a fully integrated composite product comprised of the underlying security IC hardware combined with the embedded software developed by NXP. Therefore, Phase 5 is fully under control of NXP and does not involve data exchange with other parties. NXP also provides a commercial option to configure the TOE on behalf of the customer in order to personalize before the usage. Alternatively, the customer can also finalize the partially personalized TOE after delivery. In case that all required security anchors (key material) are already installed during personalization by NXP, the customer can finalize the personalization of the file system content relying on the operational security features of the TOE. The TOE Software is embedded in the TOE during the TOE evaluation perimeter (life- cycle phases 1 - 6) and the TOE does not allow the modification of installation of any piece of IC Embedded Software after TOE delivery. Moreover, the TOE is being locked to the user operating mode before TOE delivery at the end of Phase 6. The TOE is able to control two different logical phases. After production of the chip every start-up will lead to the initial operating mode. In the initial operating mode the production test shall be performed and the TOE is trimmed and initialized. The selection of the required variant is part of the initialization. At the end of the production test, the access to the test and initialization software is disabled. Subsequent start-ups of the chip will always enter the user operating mode with the CPU executing the TOE operating system software. The TOE will stay in the user operating mode until the end of its life-time. In exceptional cases, which impact the integrity of the TOE in a non-recoverable way (typically if the TOE configuration is corrupted or TOE faces physical damage) the TOE switches into the mute or freeze operating mode. In those modes the TOE is effectively unusable. 1.4.4 TOE Intended Usage The TOE user environment is the environment from TOE Delivery to Phase 7. At the phases up to 6, the TOE user environment must be a controlled environment. The only exception is that customer specific keys can be installed using trust provisioning services in Phase 6. In this case the customer can finalize the personalization at the end of Phase 6, already relying on the TOE provided operational security services. Regarding to Phase 7, the TOE is used by the end-user. The method of use of the product in this phase depends on the application. The TOE is intended to be used in an unsecured environment that does not avoid a threat. The device is developed for high-end safeguarded applications, and is designed for embedding into contactless smart cards according to ISO 14443. Usually the smart card is assigned to a single individual only and the smart card may be used for multiple applications in a multi-provider environment. The secret data shall be used as input for the calculation of authentication data, encryption and integrity protection of data for communication. In the end-user environment (Phase 7) smart card ICs are used in a wide range of applications to assure authorized conditional access. Examples of such are transportation or access management. The end-user environment therefore covers a wide spectrum of very different functions, thus making it difficult to avoid and monitor any abuse of the TOE. The system integrators such as the terminal software developer may use samples of the TOE during the development phases for their testing purposes. These samples do not differ from the TOE, they do not have any additional functionality used for testing. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 8 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 1.4.5 Interface of the TOE The electrical interface of the TOE are the pads to connect the RF antenna, which allows communication according to ISO 14443 Type A. The communication protocol complies to part ISO 14443-4. The functional interface is defined by the commands implemented by the TOE and described in the product data sheet. The chip surface can be seen as an interface of the TOE, too. This interface must be taken into account regarding environmental stress e.g. like temperature and in the case of an attack where the attacker e.g. manipulates the chip surface. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 9 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 2 Conformance Claims 2.1 CC Conformance Claim This Security Target claims to be conformant to the Common Criteria version 3.1: • Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 5, CCMB-2017-04-001, April 2017 [2]. • Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 5, CCMB-2017-04-002, April 2017 [3]. • Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 5, CCMB-2017-04-003, April 2017 [4]. For the evaluation the following methodology will be used: • Common Methodology for Information Technology Security Evaluation, Evaluation methodology, Version 3.1, Revision 5, CCMB-2017-04-004, April 2017 [5]. This Security Target claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security Functional Requirements are defined in Section 5. 2.2 PP Claim This Security Target claims strict conformance to the following Protection Profile: • Security IC Platform Protection Profile with Augmentation Packages, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Version 1.0, 13 January 2014 [6]. 2.3 Package Claim This Security Target claims conformance to the assurance package EAL5 augmented with AVA_VAN.5 and ALC_DVS.2. 2.4 Conformance Claim Rationale As the Protection Profile [6] requires strict conformance, no conformance claim requirement is needed in this Security Target. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 10 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 3 Security Problem Definition This section lists the assets, threats, organisational security policies and assumptions from the Protection Profile [6] and describes extensions to these elements in detail. 3.1 Description of Assets The assets to be protected (related to standard functionality) are described in Section 3.1 of the Protection Profile [6] and are listed below: • The user data of the Composite TOE. • The Security IC Embedded Software, stored and in operation. • The security services provided by the TOE for the Security IC Embedded Software. These assets are related to the following high-level security concerns: • Integrity of user data of the Composite TOE. • Confidentiality of user data of the Composite TOE being stored in the TOE’s protected memory areas. • Correct operation of the security services provided by the TOE for the Security IC Embedded Software. • Deficiency of random numbers. To be able to protect these assets the TOE shall self-protect its security functionality. Critical information about the security functionality shall be protected by the development environment and the operational environment. Critical information may include: • Logical design data, physical design data, IC Dedicated Software, and configuration data. • Initialisation Data and Pre-personalisation Data, specific development aids, test and characterisation related data, material for software development support, and photomasks. For details see Section 3.1 of the Protection Profile [6]. 3.2 Threats All threats for the TOE which are defined in section 3.2 of the Protection Profile are applied to this Security Target and are listed in Table 3. 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 Table 3. Threats defined in the Protection Profile (PP-0084) For details see Section 3.2 of the Protection Profile [6]. The following additional threats are defined in this Security Target: MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 11 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Name Title T.Data-Modification Unauthorised Data Modification T.Impersonate Impersonating authorised users during authentication T.Cloning Cloning Table 4. Additional threats defined in this Security Target T.Data-Modification Unauthorised Data Modification User data stored by the TOE may be modified by unauthorised subjects. This threat applies to the processing of modification commands received by the TOE, it is not concerned with verification of authenticity. T.Impersonate Impersonating authorised users during authentication An unauthorised subject may try to impersonate an authorised subject during the authentication sequence, e.g. by a man-in-the-middle or replay attack. T.Cloning Cloning User and TSF data stored on the TOE (including keys) may be read out by an unauthorised subject in order to create a duplicate. 3.3 Organisational Security Policies All organisational security policies defined in the Protection Profile are valid for this Security Target and are listed in Table 5. Name Title P.Process-TOE Identification during TOE Development and Production Table 5. Organisational security policies defined in the Protection Profile (PP-0084) This Security Target defines additional organisational security policies as detailed in the following. The TOE provides specific security functionality which can be used by the MIFARE Plus software. In the following specific security functionality is listed which is not derived from threats identified for the TOE’s environment because it can only be decided in the context of the smart card application against which threats the MIFARE Plus software will use the specific security functionality. The IC Developer / Manufacturer therefore applies the policies 'Confidentiality during communication', 'Integrity during communication', 'Transaction mechanism' and 'Untraceability of end-users' as specified below. Name Title P.Encryption Confidentiality during communication P.MAC Integrity during communication P.No-Trace Untraceability of end-users Table 6. Additional organisational security policies defined in this Security Target MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 12 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite P.Encryption Confidentiality during communication The TOE shall provide the possibility to protect selected data elements from eavesdropping during contactless communication. P.MAC Integrity during communication The TOE shall provide the possibility to protect the contactless communication from modification or injections. This includes especially the possibility to detect replay or man-in-the-middle attacks within a session. P.No-Trace Untraceability of end-users The TOE shall provide the ability that authorised subjects can prevent that end-user of TOE may be traced by unauthorised subjects without consent. Tracing of end-users may happen by performing a contactless communication with the TOE when the end-user is not aware of it. Typically this involves retrieving the UID or any freely accessible data element. 3.4 Assumptions All assumptions defined in the Protection Profile are valid for this Security Target and are listed in Table 7. Name Title A.Process-Sec-IC Protection during Packaging, Finishing and Personalisation A.Resp-Appl Treatment of user data of the Composite TOE Table 7. Assumptions defined in the Protection Profile (PP-0084) In compliance with Application Notes 6 and 7 in the Protection Profile [6], this Security Target defines two additional assumptions as follows: Name Title A.Secure-Values Usage of secure values A.Terminal-Support Terminal Support Table 8. Additional assumptions defined in this Security Target A.Secure-Values Usage of secure values Only confidential and secure cryptographically strong keys shall be used to set up the authentication. These values are generated outside the TOE and they are downloaded to the TOE. A.Terminal-Support Terminal Support The terminal verifies information sent by the TOE in order to ensure integrity and confidentiality of the communication. Furthermore the terminal shall provide random numbers according to AIS20/31 for the authentication. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 13 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite The additional assumptions as defined above are required for the correct functioning of the MIFARE security functionality. As the Protection Profile [6] does not cover this kind of functionality, the additional assumptions neither mitigate a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the Protection Profile [6], nor fulfil an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the Protection Profile [6]. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 14 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 4 Security Objectives 4.1 Security Objectives for the TOE All security ojectives for the TOE which are defined in section 4.1 of the Protection Profile are applied to this Security Target and are listed in Table 9. 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 Table 9. Security Objectives of the TOE (PP-0084) Regarding the Application Notes 8 and 9 in the Protection Profile [6], additional security objectives that are based on additional functionality provided by the TOE are defined below: Name Title O.Access-Control Access Control O.Authentication Authentication O.Encryption Confidential Communication O.MAC Integrity-Protected Communication O.No-Trace Preventing Traceability O.Type-Consistency Data Type Consistency Table 10. Additional security objectives defined in this Security Target O.Access-Control Access Control The TOE must provide an access control mechanism for application code and data stored by it. The access control mechanism shall apply to all operations for application elements and to reading and modifying security attributes. The cryptographic keys used for authentication shall never be output. O.Authentication Authentication The TOE must provide an authentication mechanism in order to be able to authenticate authorised users. The authentication mechanism shall be resistant against replay and man-in-the-middle attacks. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 15 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite O.Encryption Confidential Communication The TOE must be able to protect the communication by encryption. This shall be implemented by security attributes that enforce encrypted communication for the respective data elements. O.MAC Integrity-Protected Communication The TOE must be able to protect the communication 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.No-Trace Preventing Traceability The TOE must be able to prevent that the TOE end- user can be traced. This shall be done by providing an option that disables the transfer of privacy-related information that is suitable for tracing an end-user by an unauthorised subject. 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. 4.2 Security Objectives for the Security IC Embedded Software All security objectives for the Security IC Embedded Software which are defined in section 4.2 of the Protection Profile are applied to this Security Target and are listed in Table 11. Name Title OE.Resp-Appl Treatment of User Data Table 11. Security Objectives for the Security IC Embedded Software (PP-0084) 4.3 Security Objectives for the Operational Environment All security objectives for the operational environment which are defined in section 4.3 of the Protection Profile are applied to this Security Target and are listed in Table 12. Name Title OE.Process-Sec-IC Protection during composite product manufacturing Table 12. Security Objectives for the Operational Environment (PP-0084) The following additional security objectives for the operational environment are defined in this Security Target: MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 16 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Name Title OE.Secure-Values Generation of secure values OE.Terminal-Support Terminal support to ensure integrity, confidentiality and use of random numbers Table 13. Additional security objectives for the operational environment defined in this Security Target The TOE provides specific functionality that requires the TOE Manufacturer to implement measures for the unique identification of the TOE. Therefore, OE.Secure-Values is defined to allow a TOE specific implementation (refer also to A.Secure-Values). OE.Secure-Values Generation of Secure Values The environment shall generate confidential and cryptographically strong keys for authentication purpose. These values are generated outside the TOE and are downloaded to the TOE during the personalisation or usage in phase 5 to 7. The TOE provides specific functionality to verify the success of the application download process. Therefore, OE.Terminal-Support is defined to allow triggering the verification process. OE.Terminal-Support Terminal support to ensure integrity, confidentiality and use of random numbers The terminal shall verify information sent by the TOE in order to ensure integrity and confidentiality of the communication. This involves checking of MAC values, verification of redundancy information according to the cryptographic protocol and secure closing of the communication session. Furthermore the terminal shall provide random numbers according to AIS20/31 [1] for the authentication. The additional security objectives for the operational environment as defined above are required for the correct functioning of the MIFARE Plus security functionality. As the Protection Profile [6] does not cover this kind of functionality, the additional objectives neither mitigate a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the Protection Profile [6], nor fulfil an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the Protection Profile [6]. 4.4 Security Objectives Rationale Section 4.4 in the Protection Profile [6] provides a rationale how the threats, organisational security policies and assumptions are addressed by the security objectives defined in the Protection Profile. This rationale is not repeated here. The following table summarizes how threats, organisational security policies and assumptions are addressed by the security objectives with respect to those items defined in the Security Target. All these items are in line with those in the Protection Profile [6]. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 17 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Security Problem Definition Security Objective T.Data-Modification O.Access-Control O.Type-Consistency OE.Terminal-Support T.Impersonate O.Authentication T.Cloning O.Access-Control O.Authentication P.Encryption O.Encryption P.MAC O.MAC P.No-Trace O.Access-Control O.Authentication O.No-Trace A.Secure-Values OE.Secure-Values A.Terminal-Support OE.Terminal-Support Table 14. Security Problem Definition mapping to Security Objective The rationale for the mapping is given below: Justification related to T.Data-Modification: Security Objective Rationale O.Access-Control This objective requires an access control mechanism that limits the ability to modify data and code elements stored by the TOE. O.Type-Consistency This objective ensures that data types are adhered, so that TOE data can not be modified by abusing type-specific operations. OE.Terminal-Support This objective requires that the terminal must support this by checking the TOE responses. Justification related to T.Impersonate: Security Objective Rationale O.Authentication This objective requires that the authentication mechanism provided by the TOE shall be resistant against attack scenarios targeting the impersonation of authorized users. Justification related to T.Cloning: Security Objective Rationale O.Access-Control This objective requires that unauthorized users can not read any information that is restricted to the authorized subjects. The cryptographic keys used for the authentication are stored inside the TOE and are protected by this objective. This objective states that no keys used for authentication shall ever be output. O.Authentication This objective requires that users are authenticated before they can read any information that is restricted to authorized users. Justification related to A.Secure-Values: MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 18 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Security Objective Rationale OE.Secure-Values This objective is an immediate transformation of the assumption, therefore it covers the assumption. Justification related to A.Terminal-Support: Security Objective Rationale OE.Terminal-Support This objective is an immediate transformation of the assumption, therefore it covers the assumption. The TOE 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 TOE 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 authentication. This is assumed by the related assumption, therefore the assumption is covered. Justification related to P.Encryption: Security Objective Rationale O.Encryption This objective is an immediate transformation of the security policy, therefore it covers the security policy. Justification related to P.MAC: Security Objective Rationale O.MAC This objective is an immediate transformation of the security policy, therefore it covers the security policy. Justification related to P.No-Trace: Security Objective Rationale O.Access-Control This objective provides means to implement access control to data elements on the TOE in order to prevent tracing based on freely accessible data elements. O.Authentication This objective provides means to implement authentication on the TOE in order to prevent tracing based on freely accessible data elements. O.No-Trace This objective requires that the TOE shall provide an option to prevent the transfer of any information that is suitable for tracing an end-user by an unauthorized subject. This objective includes the UID. The justification of the additional policies and the additional assumptions show that they do not contradict the rationale already given in the Protection Profile [6] for the assumptions, policy and threats defined there. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 19 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 5 Extended Components Definition This Security Target does not define extended components. Note that the Protection Profile [6] defines extended security functional requirements FCS_RNG.1, FMT_LIM.1, FMT_LIM.2, FAU_SAS.1 and FDP_SDC.1 in chapter 5, which are included in this Security Target. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 20 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 6 Security Requirements This chapter defines the security requirements that shall be met by the TOE. These security requirements are composed of the security functional requirements and the security assurance requirements that the TOE must meet in order to achieve its security objectives. CC allows several operations to be performed on security requirements (on the component level); refinement, selection, assignment, and iteration are defined in section 8.1 of CC Part 1 [2]. These operations are used in the Protection Profile [6] and in this Security Target, respectively. The refinement operation is used to add details to requirements, and thus, further intensifies a requirement. The selection operation is used to select one or more options provided by the Protection Profile 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 as italic text. The iteration operation is used when a component is repeated with varying operations. 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. Whenever an element in the Protection Profile contains an operation that is left uncompleted, the Security Target has to complete that operation. 6.1 Security Functional Requirements 6.1.1 Security Functional Requirements from the Protection Profile 6.1.1.1 FAU_SAS.1 The TOE shall meet the requirement "Audit storage" as defined in the PP [6], and as specified below. FAU_SAS.1 Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery with the capability to store the Initialisation Data, Pre-personalisation Data, Customer-specific Data 1 in the non-volatile memory 2 . 1 [selection: the Initialisation Data, Pre-personalisation Data, [assignment: other data]] 2 [assignment: type of persistent memory] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 21 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 6.1.1.2 FCS_RNG.1/PTG2 The TOE shall meet the requirement "Random number generation (Class PTG.2)" as defined in the PP [6] according to [1] , and as specified below. FCS_RNG.1/PTG2 Random number generation (Class PTG.2) Hierarchical to: No other components. Dependencies: No dependencies. FCS_RNG.1.1/PTG2 The TSF shall provide a physical 3 random number generator that implements: 4 (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 5 . (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 non-tolerable 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 6 . The online test is suitable for detecting non- tolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time. FCS_RNG.1.2/PTG2 The TSF shall provide octets of bits 7 that meet: 3 [selection: physical, hybrid physical, hybrid deterministic] 4 [assignment: list of security capabilities] 5 [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] 6 [selection: externally, at regular intervals, continuously, applied upon specified internal events] 7 [selection: bits, octets of bits, numbers [assignment: format of the numbers]] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 22 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite (PTG.2.6) Test procedure A 8 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. 6.1.1.3 FCS_RNG.1/DRG3 The TOE shall meet the requirement "Random number generation (Class DRG.3)" as defined below according to [1]. FCS_RNG.1/DRG3 Random number generation (Class DRG.3) Hierarchical to: No other components. Dependencies: No dependencies. FCS_RNG.1.1/ DRG3 The TSF shall provide a deterministic 9 random number generator that implements: 10 (DRG.3.1) If initialized with a random seed using a PTRNG of class PTG.2 as random source 11 , the internal state of the RNG shall have at least 256 bit of entropy 12 . (DRG.3.2) The RNG provides forward secrecy. (DRG.3.3) The RNG provides backward secrecy even if the current internal state is known. FCS_RNG.1.2/ DRG3 The TSF shall provide random numbers that meet: (DRG.3.4) The RNG, initialized with a random seed using a PTRNG of class PTG.2 13 , generates output for which 14 2 48 strings of bit length 128 are mutually different with probability 15 at least 1 - 2 -24 . (DRG.3.5) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The 8 [assignment: additional standard test suites]. Assignment is empty as per Application Note 44 of the PP. 9 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] 10 [assignment: list of security capabilities] 11 [selection: using a PTRNG of class PTG.2 as random source, using a PTRNG of class PTG.3 as random source, using an NPTRNG of class NTG.1 [assignment: other requirements for seeding]] 12 [selection: have [assignment: amount of entropy], have [assignment: work factor], require [assignment: guess work]] 13 [assignment: requirements for seeding] 14 [assignment: number of strings] 15 [assignment: probability] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 23 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite random numbers must pass test procedure A and no additional test suites 16 . 6.1.1.4 FDP_SDC.1 The TOE shall meet the requirement "Stored data confidentiality" as defined in the PP [6], and as specified below. FDP_SDC.1 Stored data confidentiality Hierarchical to: No other components. Dependencies: No dependencies. FDP_SDC.1.1 The TSF shall ensure the confidentiality of the information of the user data while it is stored in the RAM and non-volatile memory 17 . 6.1.1.5 FDP_SDI.2 The TOE shall meet the requirement "Stored data integrity monitoring and action" as defined in the PP [6], and as specified below. FDP_SDI.2 Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring Dependencies: No dependencies. FDP_SDI.2.1 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: integrity check information associated with the data storied in memories 19 . FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall perform an error correction if possible or trigger a Security Reset if not 20 . 6.1.2 Security Functional Requirements regarding Access Control 6.1.2.1 MIFARE Access Control Policy The Security Function Policy (SFP) MIFARE Access Control Policy uses the definitions listed in this paragraph. The defined subjects are: 16 [assignment: additional test suites] 17 [assignment: memory area] 18 [assignment: integrity errors] 19 [assignment: user data attributes] 20 [assignment: action to be taken] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 24 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Subject Personaliser Personaliser Info The Personaliser is the subject that owns or has access to all cryptographic keys in order to provide them to the TOE. Note that all actions performed by the Personaliser are restricted to SL0 and that those actions do not require an active authentication. Subject CardAdmin Card Administrator Info The CardAdmin is the subject that owns or has access to the CardMasterKey. Subject CardManager Card Manager Info The CardManager is the subject that owns or has access to the CardConfigurationKey. Subject SecurityLevelManager Card Security Level Manager Info The SecurityLevelManager is the subject that owns or has access to the Level3SwitchKey. Subject SectorSecurityLevelManager Sector Security Level Manager Info The SectorSecurityLevelManager is the subject that owns or has access to the Level3SectorSwitchKey and one or more AESSectorKeys. Subject CardUser Card User Info The CardUser is the subject that owns or has access to one or more AESSectorKeys. Note that the CardUser does not necessarily need to know both AESSectorKeys.KeyA and AESSectorKeys.KeyB of a particular Sector. Subject OriginalityKeyUser Originality Key User Info The OriginalityKeyUser is the subject that owns or has access to one or more OriginalityKeys. Subject TransMACConfManager Transaction MAC Configuration Manager Info The TransMACConfManager is the subject that owns or has access to one or more TransMACConfKeys. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 25 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Subject Anybody Anybody Info Any subject that does not belong to one of the roles Personaliser, CardAdmin, CardManager, SecurityLevelManager, SectorSecurityLevelManager, CardUser, OriginalityKeyUser or TransMACConfManager, belongs to the role Anybody. This role includes the card holder (also referred to as end-user), and any other subject like an attacker for instance. The subjects belonging to Anybody do not possess any key and therefore are not able to perform any operation that is restricted to one of the roles which are explicitely excluded from the role Anybody. Subject Nobody Nobody Info Any subject that does not belong to one of the roles Personaliser, CardAdmin, CardManager, SecurityLevelManager, SectorSecurityLevelManager, CardUser, OriginalityKeyUser, TransMACConfManager or Anybody, belongs to the role Nobody. Due to the definition of Anybody, the set of all subjects belonging to the role Nobody is the empty set. Note that multiple subjects may have the same role, e.g. for every Sector there are two CardUser (identified by the respective AESSectorKeys.KeyA and AESSectorKeys.KeyB for this Sector). The assigned rights to the CardUsers can be different, which allows having more or less powerful CardUser. There are also more than one OriginalityKeyUser and SecurityLevelManager. The objects defined for the MIFARE Access Control Policy are: Object Block Block Info Data is organized in Blocks of 16 bytes, which are accessed as elementary data units. Several instances of a Block are grouped into Sectors. Operation Read Read data from a Block. Operation Write Write data to a Block. Object Sector Sector Info Each Sector consists of 4 or 16 Blocks. Object SectorTrailer Sector Trailer Info The security attribute SectorTrailer is a specific Block that contains the access conditions for the corresponding Sector. Operation Read Read the security attribute SectorTrailer. Operation Modify Modify the security attribute SectorTrailer. Object Value Value Info One specific type of data stored in a Block is called Value. Operation Increase Increase a Value. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 26 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Object Value Value Operation Decrease Decrease a Value. Operation Transfer Transer a Value. Operation Restore Restore a Value. Object MFPConfigurationBlock MFP Configuration Block Info The security attribute MFPConfigurationBlock. Operation Modify Modify the security attribute MFPConfigurationBlock. Object FieldConfigurationBlock Field Configuration Block Info The security attribute FieldConfigurationBlock. Operation Modify Modify the security attribute FieldConfigurationBlock. Object SectorSecurityLevel Sector Security Level Info The sector security level of a designated Sector of the TOE. Operation Switch Switch the SectorSecurityLevel. Object SecurityLevel Card Security Level Info The security attribute SecurityLevel of the TOE. Operation Switch Switch the SecurityLevel. Object CardMasterKey Card Master Key Info The key to manage keys and parameters for items of the TOE that do not require being changed in the field. Operation Change Change the CardMasterKey. Object CardConfigurationKey Card Configuration Key Info The key to manage keys and parameters for items of the TOE that may require being changed in the field. Operation Change Change the CardConfigurationKey. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 27 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Object Level3SwitchKey Level 3 Switch Key Info Key to change SecurityLevel from SL1 to SL3. Operation Change Change the Level3SwitchKey. Object Level3SectorSwitchKey Level 3 Sector Switch Key Info Key to switch dedicated Sectors from SectorSecurityLevel 1 to SectorSecurityLevel 3. Operation Change Change the Level3SectorSwitchKey. Object TransMACKey Transaction MAC Key Info Key to derive session keys that are used in the actual Transaction MAC computation. Note that there exists of four of these keys in total. Operation Change Change the TransMACKey. Object TransMACConfKey Transaction MAC Configuration Key Info Each TransMACKey is assigned a TransMACConfKey. An active authentication with the TransMACConfKey is required to enable the Transaction MAC feature for one or more dedicated Blocks. Operation Change Change the TransMACConfKey. Object TransMACConfBlock Transaction MAC Configuration Block Info Each TransMACKey is related with several TransMACConfBlocks. Operation Write Write data to TransMACConfBlock. Object AESSectorKeys AES Sector Keys Info The keys to manage access to Sectors. Since there are two keys for every Sector the keys are called AESSectorKeys.KeyA and AESSectorKeys.KeyB. Operation Change Change the AESSectorKeys. Attribute KeyA AES Sector key AESSectorKeys.KeyA. Attribute KeyB AES Sector key AESSectorKeys.KeyB. Object OriginalityKey Originality Key Info The key to check the originality of the TOE. Operation Change Change the OriginalityKey. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 28 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Note that subjects are authorised by cryptographic keys by appyling an authentication procedure. These keys are considered as authentication data and not as security attributes of the subjects. 6.1.2.2 FMT_SMR.1/MF The TOE shall meet the requirement "Security roles" as specified below. FMT_SMR.1/MF Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification FMT_SMR.1.1/MF The TSF shall maintain the roles Personaliser, CardAdmin, CardManager, SecurityLevelManager, SectorSecurityLevelManager, CardUser, OriginalityKeyUser, TransMACConfManager, Anybody and Nobody 21 . FMT_SMR.1.2/MF The TSF shall be able to associate users with roles. 6.1.2.3 FDP_ACC.1/MF The TOE shall meet the requirement "Subset access control" as specified below. FDP_ACC.1/MF Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/MF The TSF shall enforce the MIFARE Access Control Policy 22 on all subjects, objects, operations and attributes defined by the MIFARE Access Control Policy 23 . 6.1.2.4 FDP_ACF.1/MF The TOE shall meet the requirement "Security attribute based access control" as specified below. FDP_ACF.1/MF Security attribute based access control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control, FMT_MSA.3 Static attribute initialisation 21 [assignment: the authorised identified roles] 22 [assignment: access control SFP] 23 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 29 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite FDP_ACF.1.1/MF The TSF shall enforce the MIFARE Access Control Policy 24 to objects based on the following: all subjects, objects and attributes 25 . FDP_ACF.1.2/MF The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 26 1. In SL0 the Personaliser is allowed to perform Block.Write on all Blocks except Block 0. 2. In SL3 the CardUser is allowed to perform Block.Read and Block.Write for every Sector, if the access conditions in the corresponding SectorTrailer grants him this right. 3. In SL3 the CardUser is allowed to perform Value.Increase, Value.Decrease, Value.Transfer and Value.Restore for every Sector, if the access conditions in the corresponding SectorTrailer grants him this right. FDP_ACF.1.3/MF The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none 27 . FDP_ACF.1.4/MF The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 28 1. No one but Nobody is allowed to perform Block.Write on Block 0 (first Block of the first Sector). 2. The OriginalityKeyUser is not allowed to perform any operation on objects. 6.1.2.5 FMT_MSA.3/MF The TOE shall meet the requirement "Static attribute initialization" as specified below. FMT_MSA.3/MF Static attribute initialization Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes, FMT_SMR.1 Security roles 24 [assignment: access control SFP] 25 [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] 26 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 27 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 28 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 30 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite FMT_MSA.3.1/MF The TSF shall enforce the MIFARE Access Control Policy 29 to provide permissive 30 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/MF The TSF shall allow the no one but Nobody 31 to specify alternative initial values to override the default values when an object or information is created. 6.1.2.6 FMT_MSA.1/MF The TOE shall meet the requirement "Management of security attributes" as specified below. FMT_MSA.1/MF Management of security attributes Hierarchical to: No other components. 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 FMT_MSA.1.1/MF The TSF shall enforce the MIFARE Access Control Policy 32 to restrict the ability to modify 33 the security attributes MFPConfigurationBlock, FieldConfigurationBlock, SectorTrailer and SecurityLevel 34 to Personaliser, CardManager, CardAdmin, SecurityLevelManager and CardUser, respectively 35 . Refinement: The detailed management abilities are: 1. In SL0 the Personaliser is allowed to perform MFPConfigurationBlock.Modify. 2. In SL0 the Personaliser is allowed to perform FieldConfigurationBlock.Modify. 3. In SL0 the Personaliser is allowed to perform SectorTrailer.Modify. 4. In SL0 the Personaliser is allowed to perform SecurityLevel.Switch to switch the SecurityLevel to SL1 or SL3. 5. The CardAdmin is allowed to perform MFPConfigurationBlock.Modify. 6. The CardManager is allowed to perform FieldConfigurationBlock.Modify. 29 [assignment: access control SFP, information flow control SFP] 30 [selection, choose one of: restrictive, permissive, [assignment: other property]] 31 [assignment: the authorised identified roles] 32 [assignment: access control SFP(s), information flow control SFP(s)] 33 [selection: change_default, query, modify, delete, [assignment: other operations]] 34 [assignment: list of security attributes] 35 [assignment: the authorised identified roles] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 31 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 7. In SL1 the SecurityLevelManager is allowed to perform SecurityLevel.Switch to switch the SecurityLevel to SL3. 8. The CardUser is allowed to perform SectorTrailer.Read and SectorTrailer.Modify if the access conditions in the corresponding SectorTrailer grant him these rights. 6.1.2.7 FMT_MTD.1/MF The TOE shall meet the requirement "Management of TSF data" as specified below. FMT_MTD.1/MF Management of TSF data Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles, FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/MF The TSF shall restrict the ability to modify 36 the authentication data 37 to the Personaliser, CardAdmin, CardManager, SecurityLevelManager and CardUser. 38 . Refinement: The detailed management abilities are: 1. No one but Nobody is allowed to perform OriginalityKey.Change. 2. The Personaliser is allowed to perform CardMasterKey.Change. 3. The Personaliser is allowed to perform CardConfigurationKey.Change. 4. The Personaliser is allowed to perform Level3SwitchKey.Change. 5. The Personaliser is allowed to perform AESSectorKeys.Change. 6. The CardAdmin is allowed to perform CardMasterKey.Change. 7. The CardAdmin is allowed to perform Level3SwitchKey.Change. 8. The CardAdmin is allowed to perform Level3SectorSwitchKey.Change. 9. The CardAdmin is allowed to perform TransMACConfKey.Change. 10. The CardManager is allowed to perform CardConfigurationKey.Change. 11. The CardUser is allowed to perform AESSectorKeys.Change if the access conditions in the corresponding SectorTrailer grant him this right. 36 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 37 [assignment: list of TSF data] 38 [assignment: the authorised identified roles] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 32 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 12. The TransMACConfManager is allowed to perform TransMACKey.Change. 6.1.2.8 FMT_SMF.1/MF The TOE shall meet the requirement "Specification of Management Functions" as specified below. FMT_SMF.1/MF Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies. FMT_SMF.1.1/MF The TSF shall be capable of performing the following management functions: 39 • 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 SecurityLevel of the TOE or the SectorSecurityLevel of dedicated Sectors, DESELECT according to ISO 14443-3, explicit authentication reset; • Finishing the personalisation phase by explicit request of the Personaliser • Changing a security attribute • Selection and Deselection of the Virtual Card. 6.1.2.9 FDP_ITC.2/MF The TOE shall meet the requirement "Import of user data with security attributes" as specified below. FDP_ITC.2/MF Import of user data with security attributes Hierarchical to: No other components. 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 FDP_ITC.2.1/MF The TSF shall enforce the MIFARE Access Control Policy 40 when importing user data, controlled under the SFP, from outside of the TOE. 39 [assignment: list of management functions to be provided by the TSF] 40 [assignment: access control SFP(s) and/or information flow control SFP(s)] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 33 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite FDP_ITC.2.2/MF The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3/MF 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/MF 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/MF The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: no additional rules 41 . 6.1.2.10 Implications of the MIFARE Access Control Policy The MIFARE 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 usually does not belong to the group of authorised users (consisting of CardAdmin, CardManager, SecurityLevelManager, SectorSecurityLevelManager, CardUser and OriginalityKeyUser), but is regarded as Anybody by the TOE. This means that the TOE cannot determine if it is used by its intended end-user (in other words: it cannot determine if the current card holder is the owner of the card). • The Personaliser is very powerful, although the role is limited to SL0. The Personaliser is allowed to perform Block.Write on all Blocks and therefore change all data, all the keys (except the OriginalityKeys), and all SectorTrailers, MFPConfigurationBlocks and FieldConfigurationBlocks. • Switching of the SecurityLevel is an integral part of the TOE security. The TOE is switched from SL0 to SL1 or SL3 at the end of the personalisation phase. Afterwards the SecurityLevel of the TOE can be increased by the SecurityLevelManager, the SectorSecurityLevels of dedicated Sectors of the TOE can be increased by the SectorSecurityLevelManager. 6.1.3 Security Functional Requirements regarding Confidentialty, Authentication and Integrity 6.1.3.1 FCS_COP.1/MF-AES The TOE shall meet the requirement "Cryptographic Operation (AES)" as specified below. FCS_COP.1/MF- AES Cryptographic Operation (AES) Hierarchical to: No other components. 41 [assignment: additional importation control rules] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 34 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 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/MF- AES The TSF shall perform encryption and decryption and cipher based MAC for authentication and communication 42 in accordance with the specified cryptographic algorithm Advanced Encryption Standard AES in one of the following modes of operation: CBC, CMAC 43 and cryptographic key sizes 128 bits 44 that meet the following: 45 • FIPS PUB 197 [11] (AES) • NIST SP 800-38A [12] (CBC mode) • NIST SP 800-38B [13] (CMAC mode) Refinement: For the MIFARE Plus EV0 secure messaging the TOE uses the cryptographic algorithm for CBC according to NIST Special Publication 800-38B [13] (CBC mode) with the following modification: The TOE does not use an unpredictable IV instead it uses a constructed IV which is partially predictable. 6.1.3.2 FCS_CKM.1/MF The TOE shall meet the requirement "Cryptographic key generation" as specified below. FCS_CKM.1/MF Cryptographic key generation Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/MF The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm EV0 Session Key Generation and EV1 Session Key Generation 46 and specified cryptographic key sizes 128 bit 47 that meets the following: MF1P(H)x2 datasheet [7], Section 8.7.2.4 (EV0) and 8.7.2.5 (EV1) 48 . 42 [assignment: list of cryptographic operations] 43 [assignment: cryptographic algorithm] 44 [assignment: cryptographic key sizes] 45 [assignment: list of standards] 46 [assignment: cryptographic key generation algorithm] 47 [assignment: cryptographic key sizes] 48 [assignment: list of standards] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 35 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 6.1.3.3 FIA_UID.2/MF The TOE shall meet the requirement "User identification before any action" as specified below. FIA_UID.2/MF User identification before any action Hierarchical to: FIA_UID.1 Timing of identification Dependencies: No dependencies. FIA_UID.2.1/MF The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 6.1.3.4 FIA_UAU.2/MF The TOE shall meet the requirement "User authentication before any action" as specified below. FIA_UAU.2/MF User authentication before any action Hierarchical to: FIA_UAU.1 Timing of authentication Dependencies: FIA_UID.1 Timing of identification FIA_UAU.2.1/MF The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 6.1.3.5 FIA_UAU.3/MF The TOE shall meet the requirement "Unforgeable authentication" as specified below. FIA_UAU.3/MF Unforgeable authentication Hierarchical to: No other components Dependencies: No dependencies FIA_UAU.3.1/MF The TSF shall detect and prevent 49 use of authentication data that has been forged by any user of the TSF. FIA_UAU.3.2/MF The TSF shall detect and prevent 50 use of authentication data that has been copied from any other user of the TSF. 49 [selection: detect, prevent] 50 [selection: detect, prevent] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 36 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 6.1.3.6 FIA_UAU.5/MF The TOE shall meet the requirement "Multiple authentication mechanisms" as specified below. FIA_UAU.5/MF Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/MF The TSF shall provide 'none' and cryptographic authentication 51 to support user authentication. FIA_UAU.5.2/MF The TSF shall authenticate any user’s claimed identity according to the following rules: 52 • The 'none' authentication is performed with anyone who communicates with the TOE without issuing an explicit authentication request. The 'none' authentication implicitly and solely authenticates the Personaliser. • The cryptographic authentication is used in SL0 to authenticate the OriginalityKeyUser. • The cryptographic authentication is used in SL1 to authenticate the OriginalityKeyUser, the CardAdmin, the CardManager, the SecurityLevelManager, the SectorSecurityLevel- Manager and the CardUser. • The cryptographic authentication is used in SL3 to authenticate the OriginalityKeyUser, the CardAdmin, the CardManager, and the CardUser. 6.1.3.7 FTP_TRP.1/MF The TOE shall meet the requirement "Trusted path" as specified below. FTP_TRP.1/MF Trusted path Hierarchical to: No other components. Dependencies: No dependencies. FTP_TRP.1.1/MF The TSF shall provide a communication path between itself and remote 53 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, disclosure, or only modification 54 . 51 [assignment: list of multiple authentication mechanisms] 52 [assignment: rules describing how the multiple authentication mechanisms provide authentication] 53 [selection: remote, local] 54 [selection: modification, disclosure, [assignment: other types of integrity or confidentiality violation]] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 37 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite FTP_TRP.1.2/MF The TSF shall permit remote users 55 to initiate communication via the trusted path. FTP_TRP.1.3/MF The TSF shall require the use of the trusted path for authentication requests, confidentiality and/or integrity verification for data transfers based on the settings in the MFPConfigurationBlock and the SectorTrailers 56 . 6.1.3.8 FCS_CKM.4/MF The TOE shall meet the requirement "Cryptographic key destruction" as specified below. FCS_CKM.4/MF 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/MF The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method overwriting 57 that meets the following: none 58 . 6.1.3.9 FPT_TDC.1/MF The TOE shall meet the requirement "Inter-TSF basic TSF data consistency" as specified below. FPT_TDC.1/MF Inter-TSF basic TSF data consistency Hierarchical to: No other components. Dependencies: No dependencies. FPT_TDC.1.1/MF The TSF shall provide the capability to consistently interpret data Blocks 59 when shared between the TSF and another trusted IT product. FPT_TDC.1.2/MF The TSF shall use the rules: data Blocks can always be modified by the Block.Write operation. If a data Block is in the data Value format it can be modified by all dedicated Value- specific operations honouring the Value-specific boundaries. 55 [selection: the TSF, local users, remote users] 56 [selection: initial user authentication, [assignment: other services for which trusted path is required]] 57 [assignment: cryptographic key destruction method] 58 [assignment: list of standards] 59 [assignment: list of TSF data types] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 38 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite SectorTrailers must have a specific format 60 when interpreting the TSF data from another trusted IT product. 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 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 SectorTrailers the TOE enforces a specific format. 6.1.4 Security Functional Requirements regarding Robustness 6.1.4.1 FPT_RPL.1/MF The TOE shall meet the requirement "Replay detection" as specified below. FPT_RPL.1/MF Replay detection Hierarchical to: No other components. Dependencies: No dependencies. FPT_RPL.1.1/MF The TSF shall detect replay for the following entities: authentication requests, confidentiality and/or integrity verification for data transfers based on the settings in the MFPConfigurationBlock and the SectorTrailers 61 . FPT_RPL.1.2/MF The TSF shall perform rejection of the request 62 when replay is detected. 6.1.4.2 FPR_UNL.1/MF The TOE shall meet the requirement "Unlinkability" as specified below. FPR_UNL.1/MF Unlinkability Hierarchical to: No other components. Dependencies: No dependencies. FPR_UNL.1.1/MF The TSF shall ensure that unauthorised subjects other than the card holder 63 are unable to determine whether any operation of the TOE 64 were caused by the same user 65 . 60 [assignment: list of interpretation rules to be applied by the TSF] 61 [assignment: list of identified entities] 62 [assignment: list of specific actions] 63 [assignment: set of users and/or subjects] 64 [assignment: list of operations] 65 [selection: were caused by the same user, are related as follows[assignment: list of relations]] MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 39 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 6.2 Security Assurance Requirements The following table lists all security assurance components that are valid for this Security Target. Name Title ADV_ARC.1 Security architecture description ADV_FSP.5 Complete semi-formal functional specification with additional error information ADV_IMP.1 Implementation representation of the TSF ADV_INT.2 Well-structured internals ADV_TDS.4 Semiformal modular design AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMS.5 Development tools CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.2 Sufficiency of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.2 Compliance with implementation standards ASE_INT.1 ST introduction ASE_CCL.1 Conformance claims ASE_SPD.1 Security problem definition ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition ASE_REQ.2 Derived security requirements ASE_TSS.1 TOE summary specification (TSS) ATE_COV.2 Analysis of coverage ATE_DPT.3 Testing: modular design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA_VAN.5 Advanced methodical vulnerability analysis Table 15. Security Assurance Requirements 6.2.1 Refinements of the TOE Security Assurance Requirements In compliance to Application Note 23 in the PP, this Security Target has to conform to all refinements of the security assurance requirements in the PP. Because the refinements in the PP are defined for the security assurance components of EAL4 (augmented by ALC_DVS.2 and AVA_VAN.5), some refinements have to be applied to assurance components of the higher level EAL5 stated in the Security Target. Most of the security assurance components mentioned in the PP and in this Security Target have the same component level and therefore for these components the refinements from the PP are valid for this Security Target without change. The following MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 40 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite two subsections apply the refinements to ALC_CMS.5 and ADV_FSP.5, which are different between the PP and this Security Target. 6.2.1.1 Refinements Regarding ALC_CMS This Security Target requires a higher evaluation level for the CC family ALC_CMS, namely ALC_CMS.5 instead of ALC_CMS.4. The refinement of the Protection Profile 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 a further 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 original component ALC_CMS.4 can be found in section 6.2.1.3 of the Protection Profile and is not repeated here. 6.2.1.2 Refinements regarding ADV_FSP This Security Target requires a higher evaluation level for the CC family ADV_FSP, namely ADV_FSP.5 instead of ADV_FSP.4. The refinement of the Protection Profile regarding ADV_FSP.4 is concerned with 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 above items. The higher level ADV_FSP.5 requires a Functional Specification in a "semi-formal style" (ADV_FSP.5.2C). The component ADV_FSP.5 enlarges 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 and is not cited here. 6.3 Security Requirements Rationale 6.3.1 Rationale for the Security Functional Requirements Section 6.3.1 in the Protection Profile provides a rationale for the mapping between security functional requirements and security objectives defined in the Protection Profile. This rationale is not repeated here. This Security Target defines additional SFRs for the TOE. In addition security requirements for the environment are defined. The following table gives an overview, how the requirements are combined to meet the security objectives. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 41 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Name Title O.Access-Control FCS_CKM.4/MF FDP_ACC.1/MF FDP_ACF.1/MF FDP_ITC.2/MF FMT_MSA.1/MF FMT_MSA.3/MF FMT_MTD.1/MF FMT_SMF.1/MF FMT_SMR.1/MF O.Authentication FCS_COP.1/MF-AES FCS_CKM.1/MF FIA_UID.2/MF FIA_UAU.2/MF FIA_UAU.3/MF FIA_UAU.5/MF FMT_SMF.1/MF FPT_RPL.1/MF FTP_TRP.1/MF O.Encryption FCS_CKM.1/MF FCS_CKM.4/MF FCS_COP.1/MF-AES FTP_TRP.1/MF O.MAC FCS_CKM.1/MF FCS_CKM.4/MF FCS_COP.1/MF-AES FPT_RPL.1/MF FTP_TRP.1/MF O.Type-Consistency FPT_TDC.1/MF O.No-Trace FPR_UNL.1/MF Table 16. Security Functional Requirements mapping to Security Objectives Justification related to Access Control (O.Access-Control) The SFR FMT_SMR.1/MF defines the roles of the Access Control Policy. The SFR FDP_ACC.1/MF and FDP_ACF.1/MF define the rules and FMT_MSA.3/MF and FMT_MSA.1/MF the attributes that the access control is based on. FMT_MTD.1/MF provides the rules for the management of the authentication data. The management functions are defined by FMT_SMF.1/MF. Since the TOE stores data on behalf of the authorised subjects import of user data with security attributes is defined by FDP_ITC.2/ MF. 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 (i.e. an application is deleted). This is required by FCS_CKM.4/MF. These nine SFR together provide an access control mechanism as required by the objective O.Access-Control. Justification related to Authentication (O.Authentication) The SFR FCS_COP.1/MF-AES requires that the TOE provides the basic cryptographic algorithms that can be used to perform the authentication. The SFR FCS_CKM.1/ MF generates the session key used after the authentication. The SFR FIA_UID.2/ MF, FIA_UAU.2/MF and FIA_UAU.5/MF together define that users must be identified MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 42 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite and authenticated before any action. The SFR FIA_UAU.3/MF prevents that forged authentication data can be used. The "none" authentication of FIA_UAU.5/MF also ensures that a specific subject is identified and authenticated before an explicit authentication request is sent to the TOE. FMT_SMF.1/MF defines security management functions the TSF shall be capable to perform. FTP_TRP.1/MF requires a trusted communication path between the TOE and remote users, FTP_TRP.1.3/MF especially requires "authentication requests". Together with FPT_RPL.1/MF which requires a replay detection for these authentication requests the eight SFR fulfill the objective O.Authentication. Justification related to Confidential Communication (O.Encryption) The SFR FCS_COP.1/MF-AES requires that the TOE provides the basic cryptographic algorithm AES that can be used to protect the communication by encryption. FTP_TRP.1/ MF requires a trusted communication path between the TOE and remote users, FTP_TRP.1.3/MF especially requires "confidentiality and/or data integrity verification for data transfers protected with AES and based on a setting in the file attributes". The SFR FCS_CKM.1/MF generates the session key used for encryption. FCS_CKM.4/MF requires that cryptographic keys used for encryption have to be removed after usage. Justification related to Integrity-protected Communication (O.MAC) The SFR FCS_COP.1/MF-AES requires that the TOE provides the basic cryptographic algorithms that can be used to compute a MAC which can protect the integrity of the communication. FTP_TRP.1/MF requires a trusted communication path between the TOE and remote users, FTP_TRP.1.3/MF especially requires "confidentiality and/ or data integrity verification for data transfers on request of the file owner". The SFR FCS_CKM.1/MF generates the session key used for the calculation. FCS_CKM.4/MF requires that cryptographic keys used for MAC operations have to be removed after usage. FPT_RPL.1/MF requires a replay detection for these data transfers. Justification related to Data type consistency (O.Type-Consistency) The SFR FPT_TDC.1/MF requires the TOE to consistently interpret data files and values. The TOE will honor the respective file formats and boundaries (i.e. upper and lower limits, size limitations). This meets the objective O.Type-Consistency. Justification related to Preventing Traceability (O.No-Trace) The SFR FPR_UNL.1/MF requires that unauthorised subjects other than the card holder are unable to determine whether any operation of the TOE were caused by the same user. This meets the objective O.No-Trace. 6.3.2 Dependencies of Security Functional Requirements The dependencies listed in the Protection Profile are independent of the additional dependencies listed in the table below. The dependencies of the Protection Profile are fulfilled within the Protection Profile and at least one dependency is considered to be satisfied. The following discussion demonstrates how the SFR dependencies (defined by Part 2 of the Common Criteria [3]) satisfy the requirements specified in Section 6.1. The dependencies and their fullfilment are listed in the tables below: SFR Dependency Fullfilled in ST FAU_SAS.1 No dependencies. No dependency FCS_RNG.1/PTG2 No dependencies. No dependency Table 17. Dependencies of Security Functional Requirements (PP-0084) MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 43 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite SFR Dependency Fullfilled in ST FCS_RNG.1/DRG3 No dependencies. No dependency FDP_ITT.1 [FDP_ACC.1 Subset access control, or FDP_ IFC.1 Subset information flow control] Yes FDP_IFC.1 FDP_IFF.1 Simple security attributes See discussion in the PP FDP_SDC.1 No dependencies. No dependency FDP_SDI.2 No dependencies. No dependency FMT_LIM.1 FMT_LIM.2 Limited availability. Yes FMT_LIM.2 FMT_LIM.1 Limited capabilities. Yes FPT_FLS.1 No dependencies. No dependency FPT_ITT.1 No dependencies. No dependency FPT_PHP.3 No dependencies. No dependency FRU_FLT.2 FPT_FLS.1 Failure with preservation of secure state. Yes Table 17. Dependencies of Security Functional Requirements (PP-0084)...continued SFR Dependency Fullfilled in ST FCS_CKM.1/MF [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_ CKM.4 Cryptographic key destruction Yes, by FCS_COP.1/ MF-AES, FCS_CKM.4/ MF. FCS_CKM.4/MF [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] Yes, by FDP_ITC.2/ MF, FCS_CKM.1/MF. FCS_COP.1/MF-AES [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 Yes, by FDP_ITC.2/ MF, FCS_CKM.1/MF, FCS_CKM.4/MF. FDP_ACC.1/MF FDP_ACF.1 Security attribute based access control Yes, by FDP_ACF.1/ MF. FDP_ACF.1/MF FDP_ACC.1 Subset access control, FMT_ MSA.3 Static attribute initialisation Yes, by FDP_ACC.1/ MF. FDP_ITC.2/MF [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 Yes, by FDP_ACC.1/ MF, FTP_TRP.1/MF, FPT_TDC.1/MF. FIA_UID.2/MF No dependencies. No dependency FIA_UAU.2/MF FIA_UID.1 Timing of identification Yes, by FIA_UID.2/MF. FIA_UAU.3/MF No dependencies No dependency FIA_UAU.5/MF No dependencies. No dependency Table 18. Dependencies of Security Functional Requirements (Security Target) MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 44 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite SFR Dependency Fullfilled in ST FMT_MSA.1/MF [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 Yes, by FDP_ACC.1/ MF, FMT_SMR.1/MF, FMT_SMF.1/MF. FMT_MSA.3/MF FMT_MSA.1 Management of security attributes, FMT_SMR.1 Security roles Yes, by FMT_MSA.1/ MF, FMT_SMR.1/MF. FMT_MTD.1/MF FMT_SMR.1 Security roles, FMT_SMF.1 Specification of Management Functions Yes, by FMT_SMR.1/ MF, FMT_SMF.1/MF. FMT_SMF.1/MF No dependencies. No dependency FMT_SMR.1/MF FIA_UID.1 Timing of identification Yes, by FIA_UID.2/MF. FPR_UNL.1/MF No dependencies. No dependency FPT_RPL.1/MF No dependencies. No dependency FPT_TDC.1/MF No dependencies. No dependency FTP_TRP.1/MF No dependencies. No dependency Table 18. Dependencies of Security Functional Requirements (Security Target)...continued 6.3.3 Rationale for the Assurance Requirements The selection of assurance components is based on the underlying Protection Profile. The Security Target uses the same augmentations as the Protection Profile, but chooses a higher assurance level. The level EAL5 is chosen in order to meet assurance expectations of access control applications and automatic fare collection systems. Additionally, the requirement of the Protection Profile to choose at least EAL4 is fulfilled. The rationale for the augmentations is the same as in the Protection Profile. The assurance level EAL5 is an elaborated pre-defined level of the CC, part 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. Therefore, these components add additional assurance to EAL5, but the mutual support of the requirements is still guaranteed. 6.3.4 Security Requirements are Internally Consistent The discussion of security functional requirements and assurance components 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 TOE also show that the security functional and assurance requirements support each other and that there are no inconsistencies between these groups. 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 and the access control function used to implement the Access Control Policy. The security objectives defined in the Protection Profile can be seen as "low-level protection" objectives, while the additional security objectives defined in this Security Target are "high-level protection" objectives. For example, O.Encryption states that the communication can be protected by encryption. While this ensures the rather high-level goal that the communication can not be eavesdropped, the overall goal that the communication is confidential is ensured with the help of the Protection Profile MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 45 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite objective that prevent attacks on the key and the cryptographic implementation like probing or fault injection attacks. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 46 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 7 TOE Summary Specification 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 table below lists the TSF of the TOE. TSF portion Title Description TSF.Service Service functionality not related to MIFARE functionality This portion of the TSF comprises services like random number generation and provides mechanisms to store initialization, pre- personalization, and/or other data on the TOE. TSF.Protection General security measures to protect the TSF This portion of the TSF comprises physical and logical protection to avoid information leakage and detect fault injection. It defines resets in case an error or attack was detected. TSF.Control Operating conditions, memory and hardware access control This portion of the TSF controls the operating conditions. TSF.MIFARE MIFARE functionality This portion of the TSF comprises all MIFARE related security functionality such as cryptographic algorithms used by MIFARE, impements the MIFARE Access Control Policy and security functionality related to MIFARE confidentiality, authentication, integrity and robustness. Table 19. Portions of the TSF The TSF are described in more detail in the following sections and the relation to the security functional requirements is shown. 7.2 TOE Summary Specification Rationale 7.2.1 Mapping of Security Functional Requirements and TOE Security Functionality SFR TSF.Service TSF.Protection TSF.Control TSF.MIFARE Description Security Functional Requirements from the Protection Profile FRU_FLT.2 X Limited fault tolerance FPT_FLS.1 X Failure with preservation of secure state FMT_LIM.1 X Limited capabilities MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 47 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite SFR TSF.Service TSF.Protection TSF.Control TSF.MIFARE Description FMT_LIM.2 X Limited availability FAU_SAS.1 X Audit storage FDP_SDC.1 X Stored data confidentiality FDP_SDI.2 X Stored data integrity monitoring and action FPT_PHP.3 X Resistance to physical attack FDP_ITT.1 X Basic internal transfer protection FPT_ITT.1 X Basic internal TSF data transfer protection FDP_IFC.1 X Subset information flow control FCS_RNG.1/PTG2 X Random number generation (Class PTG.2) FCS_RNG.1/DRG3 X Random number generation (Class DRG.3) Security Functional Requirements regarding Access Control FDP_ACC.1/MF X Subset access control FDP_ACF.1/MF X Security attribute based access control FDP_ITC.2/MF X Import of user data with security attributes FMT_MSA.1/MF X Management of security attributes FMT_MSA.3/MF X Static attribute initialization FMT_MTD.1/MF X Management of TSF data FMT_SMF.1/MF X Specification of Management Functions FMT_SMR.1/MF X Security roles Security Functional Requirements regarding Confidentiality, Authentication and Integrity FCS_COP.1/MF-AES X Cryptographic Operation (AES) FCS_CKM.1/MF X Cryptographic key generation FCS_CKM.4/MF X Cryptographic key destruction FIA_UAU.2/MF X User authentication before any action FIA_UAU.3/MF X Unforgeable authentication FIA_UAU.5/MF X Multiple authentication mechanisms FIA_UID.2/MF X User identification before any action FPT_TDC.1/MF X Inter-TSF basic TSF data consistency FTP_TRP.1/MF X Trusted path Security Functional Requirements regarding Robustness FPR_UNL.1/MF X Unlinkability FPT_RPL.1/MF X Replay detection MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 48 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 7.2.2 TSF.Service TSF.Service provides the following functionality: TOE identification FAU_SAS.1 is implemented by a test function that allows to store identification and/or pre-personalization data (including a unique ID for each die) for the TOE in the FLASH at the end of the tests in Phase 3. Random Number Generation The TOE provides a hardware (physical) random number generator (RNG) according to PTG.2 as described in [1]. The physical RNG comprises a hardware test functionality to detect faults in the circuitry of the RNG (total failure test). Therefore this functionality meets FCS_RNG.1/PTG2. The TOE also provides a deterministic RNG according to DRG.3 as described in [1]. This functionality therefore meets FCS_RNG.1/DRG3. 7.2.3 TSF.Protection TSF.Protection addresses functionalities of the TOE which are used to protect the TSF, TSF data and user data from any kind of attack. Its functionality mainly addresses self- protection of the TSF. However, TSF.Protection also addresses non-bypassability as it implements logical protection to avoid information leakage. TSF.Protection provides the following functionality: Integrity protection of memories As required by FDP_SDI.2, TSF.Protection supports the integrity of the ROM, RAM and Flash. The Flash is able to perform error correction. The ROM, RAM and Flash provide parity protection. Furthermore, TSF.Protection also implements integrity protection during start-up. TSF.Protection supports all other SFRs because prevention of successful manipulation of security functionality is a pre-condition for the reliable work of all other functions. Protection against physical manipulations TSF.Protection protects the TOE against physical manipulation. In case a manipulation is detected, a reset is triggered to return to a secure state. Therefore, TSF.Protection implements FPT_PHP.3. The aspect of TSF.Protection is further supported by FPT_FLS.1 which controls the environmental conditions and triggers a reset in case these are out of bounds. Logical protection TSF.Protection prevents the reconstruction of TOE internal information that can be found by analysis of external measured signals like power or clock. Within the different components of the TOE dedicated functions are implemented to sufficiently limit or eliminate the information that might be contained in the shape and amplitude of signals or in the time between events. Logical protections implemented by TSF.Protection covers the SFRs FDP_ITT.1, FPT_ITT.1 and FDP_IFC.1. They cannot be influenced from outside the TOE. In addition, TSF.Protection encrypts contents stored in ROM, RAM and Flash memory with address-dependent keys and applies memory address scrambling. This ensures MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 49 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite the confidentiality of user data stored in ROM, RAM and Flash memory as required by FDP_SDC.1. Cryptographic co-processor and cryptographic library The cryptographic co-processor (AES) as well as the cryptographic library implements countermeasures against fault injection and information leakage. Another implemented mechanism to protect User Data from unwanted disclosure is an automatic clean-up of relevant registers after usage and before changing the TOE mode. Therefore, all FCS_COP.1 and FCS_CKM.4 iterations indirectly support TSF.Protection. 7.2.4 TSF.Control TSF.Control addresses those aspects the TSF controls, e.g., the operating conditions or access to specific memory addresses. Its functionality mainly addresses non- bypassability of the TSF. TSF.Control provides the following functionality. Control of operating conditions TSF.Control ensures the correct operation of the TOE hardware (functions offered by the micro-controller including the standard CPU, the crypto coprocessors, the memories, registers, I/O interfaces and the other system peripherals) during the execution of the IC Dedicated Support Software and Security IC Embedded Software. For this the TOE comprises filters for power supply and clock input. In addition, TSF.Control controls the allowed range of temperature, clock frequency, voltage and light. Mode control TSF.Control realizes the control within the TOE testing phases (phase 3 of the life-cycle) and afterwards. The life-cycle 'Wafer Test' is available for testing purposes in the phases before TOE delivery and disabled before the TOE is delivered from NXP to the customer. TSF.Control provides access to the IC Dedicated Test Software in the Super System Mode before TOE delivery or to the IC Dedicated Support Software and Security IC Embedded Software after TOE delivery. It assures that it is not possible to enable access to the IC Dedicated Test Software after TOE delivery. The test concept with specific hardware operations initiated by the test software cannot be used to read out directly any data stored in one of the memories of the TOE. Therefore the capabilities to abuse the test functions for compromising User Data or TSF data is very limited as required by FMT_LIM.1. At the end of the wafer test the access to the IC Dedicated Test Software is disabled. TSF.Control ensures that it is not possible to switch back and reuse the test functions again. In addition, the test functions of the IC Dedicated Test Software require a special sequence to execute a dedicated test routine. Therefore, TSF.Control limits the availability of the test functions as stated by FMT_LIM.2. 7.2.5 TSF.MIFARE TSF.MIFARE provides the following functionality: Authentication This functionality provides an authentication mechanism to separate authorised subjects from unauthorised subjects. The authentication of subjects is performed by a cryptographic challenge-response. The TOE supports the cryptographic algorithm AES according to FIPS PUB 197. A hardware random number generator according to AIS31, functionality class PTG.2, and a deterministic random number generator seeded by MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 50 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite the hardware random number generator (functionality DRG.3), are used to protect the authentication against attacks like e.g. replay. By this TSF.MIFARE meets FCS_RNG.1/ PTG2, FCS_RNG.1/DRG3 and FCS_COP.1/MF-AES. This functionality also identifies the user to be authenticated by the key identifier indicated in the authentication request. This meets FIA_UID.2/MF. The cryptographic authentication is used for the CardAdmin, CardManager, SecurityLevelManager, SectorSecurityLevelManager, CardUser and OriginalityKeyUser, for the Personaliser the ”none” authentication is used. Therefore FIA_UID.2/MF and FIA_UAU.5/MF are implemented. It also meets FMT_SMR.1/MF with the exception that the role ’Anybody’ can not be authenticated, since this role is solely managed by the access control. The authentication protocol requires the user to proof knowledge of a secret key by applying it on a freshly generated random challenge, generated to the TOE. This ensures that the authentication request itself cannot be forged or circumvented by attacks like replay or man-in-the-middle, therefore it meets FIA_UAU.3/MF and the relevant parts of FTP_TRP.1/MF and FPT_RPL.1/MF with respect to the authentication requests. Authentication of a user is initiated by an authentication request and the authentication state is reset if a select request is issued. Thereby these parts of FMT_SMF.1/MF are also implemented. Access Control This functionality provides an access control mechanism to the objects and security attributes that are part of the MIFARE Access Control Policy. The access control mechanism assigns CardUsers to 4 different groups of operations on Blocks. The operations are "Block.Read, Block.Write, Value.Increase, Value.Decrease, Value.Transfer and Value.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. CardUsers can also modify the SectorTrailer or the AESSectorKeys, if the access conditions allow this. Therefore the access control policy maintains the role CardUser as required by FMT_SMR.1/MF. Since this functionality also maintains the objects and Security Attributes as stated in the MIFARE Access Control Policy, it also implements FDP_ACC.1/MF, FDP_ACF.1/MF and FMT_MSA.1/MF. Management of authentication data is necessary to separate the roles, therefore it also implements FMT_MTD.1/MF. The primary use of the TOE is storage of data on behalf of the authorised users. The rules for data storage are defined by the MIFARE Access Control Policy. The storage of data is an import of data with security attributes, therefore FDP_ITC.2/MF is also implemented. The access control policy takes care that all Sectors are initialized with permissive default values in the SectorTrailer, this means the contained access conditions shall allow the CardUser to access all Blocks. Thereby it implements FMT_MSA.3/MF. If the card reaches the termination state the access control policy deletes at least one key randomly. This is done by choosing a key by random an overwriting it with random data. This implements FCS_CKM.4/MF. This functionality also controls access to the security attributes. Because it also controls selection and deselection operations, it implements part of FMT_SMF.1/MF. Finally the type consistency of the file types stored by the TOE is ensured. It ensures that Values can not over- or underflow. By this FPT_TDC.1/MF is implemented. Encryption MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 51 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite TSF.MIFARE provides a mechanism to protect the communication against eavesdropping by encryption. The encryption is requested by the CardUser. Encryption can also made mandatory on a block-group basis by setting an option in the SectorTrailer of a Sector. Thereby FDP_ACF.1/MF is implemented. The encryption algorithm is the same as the one used during authentication for the session, therefore FCS_COP.1/MF-AES is implemented. The SFR FCS_CKM.1/MF generates the session keys used during the encryption. The encryption for communication and the information to detect integrity violations implement FTP_TRP.1/MF with respect to the "confidentiality and/or data integrity verification for data transfers based on a setting in the MFPConfigurationBlock". Message Authentication Code This functionality adds data to the communication stream that enables the terminal to detect integrity violations, replay attacks or man-in-the-middle attacks. Vice-versa it verifies the data sent by the terminal and returns an error code if such an attack is detected. It uses the cryptographic algorithm 128-bit AES CMAC. Only the AES algorithm is supported, therefore it is bound to authentications with this algorithm. This functionality therefore implements FCS_COP.1/MF-AES. The SFR FCS_CKM.1/MF generates the session keys used during the calculation. If a MAC is added and over how many messages it is calculated is set by the CardAdmin in the MFPConfigurationBlock. Thereby FDP_ACF.1/MF is implemented. The detection mechanism covers all frames exchanged between the terminal and the card up to last frame with a MAC. Depending on the selected mode it can also detect what frame was injected/modified. By this FPT_RPL.1/MF is implemented. The information to detect integrity violations implement FTP_TRP.1/MF with respect to the "confidentiality and/or data integrity verification for data transfers based on a setting in the MFPConfigurationBlock". Transaction Message Authentication Code This functionality provides an option to the CardUser and the TransMACConfManager to prove the authenticity of committed transactions on the TOE. In order to do this a MAC is calculated over a committed transaction. As this feature supports the AES encryption algorithm, it implements FCS_COP.1/MF-AES. The information to detect integrity violations implements FTP_TRP.1/MF with respect to "confidentiality and/or integrity verification for data transfers". Therefore FTP_TRP.1/MF is also implemented. Preventing Traceabilty This functionality provides an option to use a random UID during ISO14443 anti-collision sequence. By this the card cannot be traced any more by simply retrieving its UID. The card specific information is protected and therefore FPR_UNL.1/MF is implemented. This functionality does not cover the data in the TOE date storage system. This data is protected by the MIFARE Access Control Policy. Note that the TOE does also support the virtual card selection mechanism by which one of multiple virtual cards stored on one physical item can be selected. Although the TOE does support only one virtual card the selection mechanism is implemented in a way that unauthorised subjects cannot determine which virtual card (indicated by the virtual card ID) is supported by the TOE. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 52 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 8 Bibliography 8 . 1 Evaluation documents [1] A proposal for: Functionality classes for random number generators, Wolfgang Killmann, T-Systems GEI GmbH, Werner Schindler, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.0, 18 September 2011. [2] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 5, CCMB-2017-04-001, April 2017. [3] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 5, CCMB-2017-04-002, April 2017. [4] Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 5, CCMB-2017-04-003, April 2017. [5] Common Methodology for Information Technology Security Evaluation, Evaluation methodology, Version 3.1, Revision 5, CCMB-2017-04-004, April 2017. [6] Security IC Platform Protection Profile with Augmentation Packages, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Version 1.0, 13 January 2014. 8 . 2 Developer documents [7] MF1P(H)x2, MIFARE Plus EV2, Product data sheet, DocStore number 522334, NXP Semiconductors, Revision 3.4, 29 August 2022. [8] MF1P(H)x2, MIFARE Plus EV2 Post Delivery Configuration, Preliminary data sheet addendum, DocStore number 598520, NXP Semiconductors, Revision 2.0, 6 March 2020. [9] MF1P(H)x2, Wafer and Delivery Specification, Product data sheet addendum, DocStore number 580932, NXP Semiconductors, Revision 3.2, 29 August 2022. [10] MF1P(H)x2, Information on Guidance and Operation, Guidance and Operation Manual, DocStore number 597512, NXP Semiconductors, Revision 1.2, 7 November 2022. 8 . 3 Standards [11] FIPS PUB 197: Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, US Department of Commerce/National Institute of Standards and Technology, 26 November 2001. [12] NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques, Morris Dworkin, National Institute of Standards and Technology, December 2001. [13] NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Morris Dworkin, National Institute of Standards and Technology, May 2005. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 53 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite 9 Legal information 9.1 Definitions Draft — A draft status on a document indicates that 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 in a draft version of a document and shall have no liability for the consequences of use of such information. 9.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. Customers are responsible for the design and operation of their applications and products using NXP Semiconductors products, and NXP Semiconductors accepts no liability for any assistance with applications or customer product design. It is customer’s sole responsibility to determine whether the NXP Semiconductors product is suitable and fit for the customer’s applications and products planned, as well as for the planned application and use of customer’s third party customer(s). Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products. NXP Semiconductors does not accept any liability related to any default, damage, costs or problem which is based on any weakness or default in the customer’s applications or products, or the application or use by customer’s third party customer(s). Customer is responsible for doing all necessary testing for the customer’s applications and products using NXP Semiconductors products in order to avoid a default of the applications and the products or of the application or use by customer’s third party customer(s). NXP does not accept any liability in this respect. Terms and conditions of commercial sale — NXP Semiconductors products are sold subject to the general terms and conditions of commercial sale, as published at http://www.nxp.com/profile/terms, unless otherwise agreed in a valid written individual agreement. In case an individual agreement is concluded only the terms and conditions of the respective agreement shall apply. NXP Semiconductors hereby expressly objects to applying the customer’s general terms and conditions with regard to the purchase of NXP Semiconductors products by customer. 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. Suitability for use in non-automotive qualified products — Unless this data sheet expressly states that this specific NXP Semiconductors product is automotive qualified, the product is not suitable for automotive use. It is neither qualified nor tested in accordance with automotive testing or application requirements. NXP Semiconductors accepts no liability for inclusion and/or use of non-automotive qualified products in automotive equipment or applications. In the event that customer uses the product for design-in and use in automotive applications to automotive specifications and standards, customer (a) shall use the product without NXP Semiconductors’ warranty of the product for such automotive applications, use and specifications, and (b) whenever customer uses the product for automotive applications beyond NXP Semiconductors’ specifications such use shall be solely at customer’s own risk, and (c) customer fully indemnifies NXP Semiconductors for any liability, damages or failed product claims resulting from customer design and use of the product for automotive applications beyond NXP Semiconductors’ standard warranty and NXP Semiconductors’ product specifications. Translations — A non-English (translated) version of a document, including the legal information in that document, is for reference only. The English version shall prevail in case of any discrepancy between the translated and English versions. Security — Customer understands that all NXP products may be subject to unidentified vulnerabilities or may support established security standards or specifications with known limitations. Customer is responsible for the design and operation of its applications and products throughout their lifecycles to reduce the effect of these vulnerabilities on customer’s applications and products. Customer’s responsibility also extends to other open and/or proprietary technologies supported by NXP products for use in customer’s applications. NXP accepts no liability for any vulnerability. Customer should regularly check security updates from NXP and follow up appropriately. Customer shall select products with security features that best meet rules, regulations, and standards of the intended application and make the ultimate design decisions regarding its products and is solely responsible for compliance with all legal, regulatory, and security related requirements concerning its products, regardless of any information or support that may be provided by NXP. NXP has a Product Security Incident Response Team (PSIRT) (reachable at PSIRT@nxp.com) that manages the investigation, reporting, and solution release to security vulnerabilities of NXP products. 9.3 Trademarks Notice: All referenced brands, product names, service names, and trademarks are the property of their respective owners. NXP — wordmark and logo are trademarks of NXP B.V. MIFARE — is a trademark of NXP B.V. MIFARE Plus — is a trademark of NXP B.V. MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 54 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Tables Tab. 1. TOE deliverables ...............................................4 Tab. 2. Variable definitions for commercial type names ................................................................4 Tab. 3. Threats defined in the Protection Profile (PP-0084) ........................................................ 11 Tab. 4. Additional threats defined in this Security Target ...............................................................12 Tab. 5. Organisational security policies defined in the Protection Profile (PP-0084) ......................12 Tab. 6. Additional organisational security policies defined in this Security Target .........................12 Tab. 7. Assumptions defined in the Protection Profile (PP-0084) .............................................13 Tab. 8. Additional assumptions defined in this Security Target ................................................ 13 Tab. 9. Security Objectives of the TOE (PP-0084) ...... 15 Tab. 10. Additional security objectives defined in this Security Target ................................................ 15 Tab. 11. Security Objectives for the Security IC Embedded Software (PP-0084) ...................... 16 Tab. 12. Security Objectives for the Operational Environment (PP-0084) ...................................16 Tab. 13. Additional security objectives for the operational environment defined in this Security Target ................................................ 17 Tab. 14. Security Problem Definition mapping to Security Objective ........................................... 18 Tab. 15. Security Assurance Requirements .................. 40 Tab. 16. Security Functional Requirements mapping to Security Objectives ..................................... 42 Tab. 17. Dependencies of Security Functional Requirements (PP-0084) .................................43 Tab. 18. Dependencies of Security Functional Requirements (Security Target) .......................44 Tab. 19. Portions of the TSF .........................................47 MF1P(H)x2 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved. Evaluation document Rev. 2.2 — 7 November 2022 PUBLIC 55 / 56 NXP Semiconductors MF1P(H)x2 Security Target Lite Contents 1 Introduction ......................................................... 3 1.1 ST Reference .................................................... 3 1.2 TOE Reference ..................................................3 1.3 TOE Overview ................................................... 3 1.3.1 Required non-TOE Hardware/Software/ Firmware ............................................................3 1.4 TOE Description ................................................ 3 1.4.1 Physical Scope of the TOE ............................... 3 1.4.1.1 Evaluated Configurations ...................................4 1.4.2 Logical Scope of the TOE ................................. 5 1.4.2.1 Hardware Description ........................................ 5 1.4.2.2 Software Description ..........................................5 1.4.2.3 Documentation ...................................................7 1.4.3 Life Cycle and Delivery of the TOE ................... 7 1.4.4 TOE Intended Usage .........................................8 1.4.5 Interface of the TOE ..........................................9 2 Conformance Claims ........................................ 10 2.1 CC Conformance Claim ...................................10 2.2 PP Claim ..........................................................10 2.3 Package Claim ................................................ 10 2.4 Conformance Claim Rationale .........................10 3 Security Problem Definition .............................11 3.1 Description of Assets .......................................11 3.2 Threats .............................................................11 3.3 Organisational Security Policies ...................... 12 3.4 Assumptions .................................................... 13 4 Security Objectives ...........................................15 4.1 Security Objectives for the TOE ...................... 15 4.2 Security Objectives for the Security IC Embedded Software ........................................ 16 4.3 Security Objectives for the Operational Environment .....................................................16 4.4 Security Objectives Rationale ..........................17 5 Extended Components Definition ....................20 6 Security Requirements .....................................21 6.1 Security Functional Requirements ...................21 6.1.1 Security Functional Requirements from the Protection Profile ............................................. 21 6.1.1.1 FAU_SAS.1 ......................................................21 6.1.1.2 FCS_RNG.1/PTG2 .......................................... 22 6.1.1.3 FCS_RNG.1/DRG3 ..........................................23 6.1.1.4 FDP_SDC.1 ..................................................... 24 6.1.1.5 FDP_SDI.2 .......................................................24 6.1.2 Security Functional Requirements regarding Access Control ................................ 24 6.1.2.1 MIFARE Access Control Policy ....................... 24 6.1.2.2 FMT_SMR.1/MF .............................................. 29 6.1.2.3 FDP_ACC.1/MF ...............................................29 6.1.2.4 FDP_ACF.1/MF ................................................29 6.1.2.5 FMT_MSA.3/MF ...............................................30 6.1.2.6 FMT_MSA.1/MF ...............................................31 6.1.2.7 FMT_MTD.1/MF ...............................................32 6.1.2.8 FMT_SMF.1/MF ............................................... 33 6.1.2.9 FDP_ITC.2/MF .................................................33 6.1.2.10 Implications of the MIFARE Access Control Policy ............................................................... 34 6.1.3 Security Functional Requirements regarding Confidentialty, Authentication and Integrity ............................................................ 34 6.1.3.1 FCS_COP.1/MF-AES .......................................34 6.1.3.2 FCS_CKM.1/MF ...............................................35 6.1.3.3 FIA_UID.2/MF ..................................................36 6.1.3.4 FIA_UAU.2/MF .................................................36 6.1.3.5 FIA_UAU.3/MF .................................................36 6.1.3.6 FIA_UAU.5/MF .................................................37 6.1.3.7 FTP_TRP.1/MF ................................................ 37 6.1.3.8 FCS_CKM.4/MF ...............................................38 6.1.3.9 FPT_TDC.1/MF ................................................38 6.1.4 Security Functional Requirements regarding Robustness ......................................39 6.1.4.1 FPT_RPL.1/MF ................................................39 6.1.4.2 FPR_UNL.1/MF ............................................... 39 6.2 Security Assurance Requirements ...................40 6.2.1 Refinements of the TOE Security Assurance Requirements ................................ 40 6.2.1.1 Refinements Regarding ALC_CMS ................. 41 6.2.1.2 Refinements regarding ADV_FSP ................... 41 6.3 Security Requirements Rationale .................... 41 6.3.1 Rationale for the Security Functional Requirements ...................................................41 6.3.2 Dependencies of Security Functional Requirements ...................................................43 6.3.3 Rationale for the Assurance Requirements ..... 45 6.3.4 Security Requirements are Internally Consistent ........................................................45 7 TOE Summary Specification ............................ 47 7.1 Portions of the TOE Security Functionality ...... 47 7.2 TOE Summary Specification Rationale ............47 7.2.1 Mapping of Security Functional Requirements and TOE Security Functionality .....................................................47 7.2.2 TSF.Service ......................................................49 7.2.3 TSF.Protection ................................................. 49 7.2.4 TSF.Control ......................................................50 7.2.5 TSF.MIFARE .................................................... 50 8 Bibliography ...................................................... 53 8.1 Evaluation documents ..................................... 53 8.2 Developer documents ......................................53 8.3 Standards .........................................................53 9 Legal information ..............................................54 Please be aware that important notices concerning this document and the product(s) described herein, have been included in section 'Legal information'. © NXP B.V. 2022. All rights reserved. For more information, please visit: http://www.nxp.com For sales office addresses, please send an email to: salesaddresses@nxp.com Date of release: 7 November 2022