NXP JCOP4.0 on P73N2M0 Secure Smart Card Controller Security Target Lite Rev. 1.3 – 2018-06-01 Evaluation documentation Evaluation Version Company Public NSCIB-CC-16-111441 Document Information Info Content Keywords ASE, JCOP, Common Criteria, EAL6 augmented Abstract This document contains information to fulfill the requirements of the Common Criteria component ASE (Security Target) for the Evalu- ation of the NXP JCOP4.0 on P73N2M0 Secure Smart Card Con- troller developed and provided by NXP Semiconductors, Business Unit Security & Connectivity, according to the Common Criteria for Information Technology Security Evaluation Version 3.1 at EAL6 augmented NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Rev Date Description 1.0 2018-03-23 Release Version 1.1 2018-04-23 Release Version upgrade to EAL6+ 1.2 2018-05-18 Fix Diagram reference in TOE Overview 1.3 2018-06-01 Update Bibliography Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 1 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 1 ST Introduction (ASE_INT) 1.1 ST Reference and TOE Reference Title NXP JCOP4.0 on P73N2M0 Secure Smart Card Controller Security Target ST Version Revision 1.3 TOE Version R1.00.1 Date 2018-06-01 Product Type Java Card TOE name NXP JCOP4.0 on P73N2M0 Secure Smart Card Controller Certification ID NSCIB-CC-16-111441 CC version Common Criteria for Information Technology Security Evaluation Version 3.1, Revision 4, September 2012 (Part 1 [3], Part 2 [4] and Part 3 [5]) Tab. 1.1: ST Reference and TOE reference 1.2 TOE Overview The TOE consists of the Micro Controller and a software stack which is stored on the Micro Controller and which can be executed by the Micro Controller. The software stack can be further split into the following components: • Firmware for booting and low level functionality of the Micro Controller, called MC FW. • Software for implementing cryptographic operations on the Micro Controller, called Security Software. • Software to update JCOP4 OS or UpdaterOS, called OS Update Component. • Software for implementing JCOP4 OS: – Software that implements low level functionality, called Native OS – Software that implements the Java Card Virtual Machine [35] and a Java Card Runtime Environment [34], called JCVM and JCRE. – Software that implements the Java Card Application Programming Interface [33], called JCAPI. – Software for implementing content management according to GlobalPlatform [22], called GP API. – Software that implements a proprietary programming interface, called Extension API. – Software that handles personalization and configuration, called Config Applet. – Software to run third party native code (Secure Box Native Lib), called Secure Box. – Software for implementing third party functionality, called Native Applications. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 2 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The TOE is also referred to as JCOP4. Whereas the JCOP4 OS consists of the software stack without the Security Software and the MC FW. The TOE uses one or more communication interfaces to communicate with its environment. The complete TOE is depicted in Figure 1.1. The elements are described in more detail in Section 1.3. Applets JCVM and JCRE TOE Border GP API Micro Controller Security Software OS Update Component Native OS JCAPI Extension API JCOP4 OS MF_CAD Config Applet Secure Box Secure Box Native Lib MC FW Certified HW Certified Security Software This certification Native Applications Fig. 1.1: Components of the TOE Figure 1.1 also shows applets and the Secure Box Native Library. The applets are small programs in Java language which can be executed by the TOE, but are not part of the TOE. The Config Applet has special privileges and is used to personalise and configure the TOE. The Secure Box Native Library provides native functions via Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 3 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public the Secure Box. Customer applets and the Secure Box Native Library are not part of the TOE. The Config Applet is part of the TOE. 1.2.1 Usage and Major Security Features of the TOE The usage of the TOE is focused on security critical applications in small form factors. One main usage scenario is the use in mobile phones, which can use the TOE to enable mobile payment or mobile ticketing with the phone based on the security of the TOE. The TOE provides a variety of security features. The hardware of the Micro Controller already protects against physical attacks by applying various sensors to detect manipulations and by processing data in ways which protect against leakage of data by side channel analysis. With the software stack the TOE provides many cryptographic primitives for encryption, decryption, signature generation, signature verification, key generation, secure man- agement of PINs and secure storage of confidential data (e.g. keys, PINs). Also the software stack implements several countermeasures to protect the TOE against attacks. The following list contains the features of this TOE: • Cryptographic algorithms and functionality: 1. 3DES for en-/decryption (CBC and ECB) and MAC generation and verification (2-key 3DES, 3-key 3DES, Retail-MAC, CMAC and CBC-MAC). 2. AES (Advanced Encryption Standard) for en-/decryption (GCM, CBC and ECB) and MAC generation and verification (CMAC, CBC-MAC). 3. RSA and RSA CRT for en-/decryption and signature generation and verification. 4. RSA and RSA CRT key generation. 5. SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 hash algorithm. 6. Secure SHA-1, Secure SHA-224, Secure SHA-256, Secure SHA-384, Secure SHA-512 hash algo- rithm. 7. HMAC 8. ECC over GF(p) for signature generation and verification (ECDSA). 9. ECC over GF(p) key generation for key agreement. 10. Random number generation according to class DRG.4 of AIS 20 [1] • Java Card 3.0.4 functionality: 1. Executing Java Card bytecodes. 2. Managing memory allocation of code and data of applets. 3. Enforcing access rules between applets and the JCRE. 4. Mapping of Java method calls to native implementations of e.g. cryptographic operation. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 4 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5. Garbage Collection fully implemented with complete memory reclamation incl. compactification. 6. Support for Extended Length APDUs. 7. Persistent Memory Management and Transaction Mechanism. • GlobalPlatform 2.2.1 functionality: 1. Loading of Java Card packages. 2. Instantiating applet instances. 3. Removing of Java packages. 4. Removing of applet instances. 5. Creating Supplementary Security Domains. 6. Associating applets to Security Domains. 7. Installation of keys. 8. Verification of signatures of signed applets. 9. CVM Management (Global PIN) fully implemented. 10. Secure Channel Protocol is supported. 11. Delegated Management, DAP (RSA 1024 and ECC 256). 12. Compliance to Secure Element configuration. • NXP Proprietary Functionality 1. Secure Box: Enables the TOE to run third party native code (Secure Box Native Lib) on the Micro Controller. 2. MIFARE Implementation accessible via Applets using the MIFARE4Mobile API. No security functional- ity is claimed for this functionality. 3. Config Applet: JCOP4 OS includes a Config Applet that can be used for configuration of the TOE. 4. OS Update Component: Proprietary functionality that can update JCOP4 OS or UpdaterOS. 5. Restricted Mode: In Restricted Mode only very limited functionality of the TOE is available such as, e.g.: reading logging information or resetting the Attack Counter. 6. Factory Reset: Delete all applets, packages, SDs and their related data listed on the Clear List. 7. Error Detection Code (EDC) API. 1.2.2 TOE Type The TOE is a Java Card with GP functionality. It can be used to load, install, instantiate and execute off-card verified Java Card applets. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 5 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 1.2.3 Required non-TOE Hardware/Software/Firmware Three groups of users shall be distinguished here. 1. The first group is the end-users group, which uses the TOE with one or more loaded applets in the final form factor as an embedded Secure Element. These users only require a communication device to be able to communicate with the TOE. The TOE supports 2 communication interfaces: (a) SWP or DWP supporting • Card Emulation Type A, Type B and Type F according to ETSI 102 622 [21]. • Wired Mode by using the APDUCard Gate according to ETSI 102 622 [29]. • Reader Mode Gate Type A and Type B according to ETSI 102 705 [28]. • Support for Low Power mode indication according to ETSI 102 705 [28]. (b) SPI over ISO 7816 T=1. 2. The second group of users are administrators of cards. They can configure the TOE by using the Config Applet or install additional applets. These users require the same equipment as end-users. 3. The third group of users develops Java Card applets and executes them on the TOE. These applet devel- opers need in addition to the communication device a set of tools for the development of applets. This set of tools can be obtained from the TOE vendor and comprises elements such as PC development environment, byte code verifier, compiler, linker and debugger. 1.3 TOE Description 1.3.1 TOE Components and Composite Certification The certification of this TOE is a composite certification. This means that for the certification of this TOE other certifications of components which are part of this TOE are re-used. In the following sections more detailed descriptions of the components of Figure 1.1 are provided. In the description it is also made clear whether a component is covered by a previous certification or whether it is covered in the certification of this TOE. 1.3.1.1 Micro Controller The Micro Controller is a secure smart card controller from NXP based on ARM architecture. The Micro Con- troller contains a co-processor for symmetric cipher, supporting AES and DES operations, and a co-processor for asymmetric algorithms. It contains volatile (RAM) memory and non-volatile Flash memory. The Micro Controller has been certified in a previous certification and the results are re-used for this certification. The exact reference to the previous certification is given in the following Table 1.2: Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 6 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Name NXP Secure Smart Card Controller P73N2M0B0.200 Certification ID ANSSI-2018/08 Tab. 1.2: Reference to Certified Micro Controller 1.3.1.2 IC Dedicated Software 1.3.1.2.1 MC FW (Micro Controller Firmware) The Micro Controller Firmware is used for testing of the Micro Controller at production, for booting of the Micro Controller after power-up or after reset, for configuration of communication devices. The MC FW has been certified in a previous certification. It has been certified together with the Micro Controller and the same references ([13]) as given for the Micro Controller also apply for the MC FW. 1.3.1.2.2 Security Software The Security Software is used by the IC Embedded Software and provides cryptographic functionality (CryptoLib) but also an interface for memory erasing and programming (Flash Services). The Security Software is certified in a previous certification and the results are re-used for this certification. The exact reference to the certification is given in the following Table: Name Security Software on P73N2M0B0.2C0 Certification ID ANSSI-CC-2018/19 Tab. 1.3: Reference to the Security Software 1.3.1.3 IC Embedded Software 1.3.1.3.1 JCOP4 OS JCOP4 OS consists of Native OS, JCVM, JCRE, GP framework, JCAPI, Extension API, Config Applet and Secure Box. JCVM, JCRE, JCAPI and GP framework are implemented according to the Java Card Specification and GlobalPlatform version listed below. JCVM, JCRE, and JCAPI version implemented in the TOE Version 3.0.4 Classic [35] [34] [33] Tab. 1.4: Java Card Specification Version Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 7 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Name Version Security Claimed GP Framework Version 2.2.1 [22] yes Amendment A, Confidential Card Content Management Version 1.0.1 [20] yes Amendment C, Contactless Services Version 1.1 [27] yes Amendment D, Secure Channel Protocol 03 Version 1.1.1 [30] yes Amendment E, Security Upgrade for Card Content Management Version 1.0.1 [31] yes Amendment F, Secure Channel Protocol 11 Version 1.0 [32] yes UICC Configuration Version 1.0.1 [23] no UICC Configuration - Contactless Extension Version 1.0 [26] no Secure Element Configuration Version 1.0 [25] no Tab. 1.5: Global Platform and Amendments JCOP4 OS components version can be identified by using the GET PLATFORM IDENTIFIER command (see UGM [10]). This command returns the card identification data, which includes the Hardware Type, JCOP Version, Build Number, Mask ID, a Patch ID and Non-Volatile Memory Size. The Platform ID is a data string that allows to identify the JCOP4 OS component. Table 1.8 in section 1.3.3 lists all possible values for the Platform ID that are valid for this TOE. 1.3.1.3.2 OS Update Component The OS Update Component can update JCOP4 OS and UpdaterOS and contains two main components: • OsSelector (no security claimed): After a hardware reset it provides the functionality to either boot Up- daterOS or JCOP4 OS. OsSelector also ensures that – only one OS is active (running) at a time. – at any time, at least one OS can be booted. – an invalid OS (e.g. partly flashed) can never be booted. • UpdaterOS: – it handles APDUs to write a new OS (either JCOP4 OS or UpdaterOS) to flash. – it verifies the integrity of the new OS before updating. – it decrypts the new OS before updating. – it checks if the new OS can be authenticated and checks if the update can be authorized. – it ensures that the activation and setting of the information that identifies the new OS is done atomically. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 8 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public – if the update fails the system stays in a secure state. The UpdaterOS is a standalone operating system that can only be active when JCOP4 OS is not active. Besides the capability to update JCOP4 OS, UpdaterOS is also capable to update itself. The UpdaterOS version can be queried by using a SELECT OS Update AID Command (see UGM [10]). UpdaterOS shares parts of the Native OS with JCOP4 OS, e.g.: communication interface, wrapper to Security Software (Flash Services and CryptoLib). The JIL document [11] is used as a reference for the OS Update component implementation. 1.3.1.3.3 Native Applications The Native Applications extend the available cryptographic algorithms for the Security Software. These Native Applications are proprietary implementations (e.g. FeliCa, OSCCA, Korean Seed) which make use of the Security Software’s security mechanisms. Native Applications are provided to JCOP4 OS via the Security Software. No security functionality claimed for Native Applications, it is an extension to the Crypto Lib. 1.3.2 TOE Life Cycle The life cycle for this Java Card is based on the general smart card life cycle defined in the Java Card Protection Profile - Open Configuration [9], see Figure 1.2. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 9 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public TOE Development TOE Delivery Phase 1 Security IC Embedded Software Development Phase 2 Security IC Development TOE Storage, pre-perso, testing Phase 3 Security IC Manufacturing Phase 4 Security IC Packaging TOE Storage, pre-perso, testing Phase 5 Composite Product Integration TOE Personalisation Phase 6 Personalisation TOE Final usage Phase 7 Operational Usage Fig. 1.2: TOE Life Cycle within Product Life Cycle Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 10 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Phase Name Description 1 Security IC Embedded Software Development The IC Embedded Software Developer is in charge of • smartcard embedded software development including the development of Java Card applets and • specification of IC pre-personalization requirements, though the actual data for IC pre-personalization comes from phase 4, 5, or 6. 2 Security IC Development The IC Developer • designs the IC, • develops IC Dedicated Software, • provides information, software or tools to the IC Embedded Software Developer, and • receives the embedded software from the developer, through trusted delivery and verification procedures. From the IC design, IC Dedicated Software and Smartcard Em- bedded Software, the IC Developer • constructs the smartcard IC database, necessary for the IC photomask fabrication. 3 Security IC Manufacturing The IC Manufacturer is responsible for • producing the IC through three main steps: IC manufactur- ing, IC testing, and IC pre-personalization. The IC Mask Manufacturer • generates the masks for the IC manufacturing based upon an output from the smarcard IC database. Configuration items may be changed/deleted. 4 Security IC Packaging The IC Packaging Manufacturer is responsible for • IC packaging and testing. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 11 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Phase Name Description 5 Composite Product Integration The Composite Product Manufacturer is responsible for the smartcard product finishing process. 6 Personalization The Personalizer is responsible for • smartcard (including applet) personalization and final tests. User Applets may be loaded onto the chip at the per- sonalization process and configuration items may be changed/deleted. The Config Applet can be used to set Config Items. 7 Operational Usage The Consumer (e.g. the Original Equipment Manufacturer) of Composite Product is responsible for • smartcard product delivery to the smartcard end-user, and the end of life process. • applets may be loaded onto the chip. • triggering an OS update. • allow Factory Reset. • Secure Box: running third party native code. • Config Applet: changing Config Items. • perform card content management according to Global Platform and Amendments specifications. Tab. 1.6: Life-cycle The evaluation process is limited to phases 1 to 5. User Applet development is outside the scope of this evaluation. Applets can be loaded into Flash memory. Applet loading into Flash memory can be done in phases 3, 4, 5, and 6. Applet loading in phase 7 is also allowed. This means post-issuance loading of applets can be done for a certified TOE. The certification is only valid for platforms that return the Platform Identifier as stated in Table 1.7. The delivery process from NXP to their customers (to phase 4 or phase 5 of the life cycle) guarantees, that the customer is aware of the exact versions of the different parts of the TOE as outlined above. TOE documentation is delivered in electronic form (encrypted according to defined mailing procedures). Note: Phases 1 to 3 are under the TOE developer scope of control. Therefore, the objectives for the environment related to phase 1 to 3 are covered by Assurance measures, which are materialized by documents, process and Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 12 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public procedures evaluated through the TOE evaluation process. During phases 4 to 7 the TOE is no more under the developer control. In this environment, the TOE protects itself with its own Security functions. But some additional usage recommendation must also be followed in order to ensure that the TOE is correctly and securely handled, and that shall be not damaged or comprised. This ST assumes (A.USE_DIAG, A.USE_KEYS) that users handle securely the TOE and related Objectives for the environment are defined (OE.USE_DIAG, OE.USE_KEYS). 1.3.3 TOE Identification The delivery comprises the following items: Type Name Version Product NXP JCOP4.0 on P73N2M0 Secure Smart Card Controller comprising the certified NXP Secure Smart Card Controller (P73N2M0B0.200) with cer- tified Security Firmware & Crypto Library loaded (P73N2M0B0.2C0) and including software (JCOP4 OS, Native Applications, OS Update Component) that is identified by Platform ID. see [13] and Table 1.8 Document User Guidance Manual [10] Document Common Criteria Requirements for PN8x products [6] Tab. 1.7: Delivery Items The TOE can be identified by the Platform ID. See Table 1.8. The Platform ID can be obtained by using the GET PLATFORM IDENTIFIER command (see UGM [10]). OS Product Commercial Name Platform ID JCOP4 OS JCOP4.0 on P73N2M0 J5O1M60121980100 Tab. 1.8: Product Identification The Platform ID has the following form: JxyeeeABCDEFmmpp The "J" is constant, the other letters are variables. For a detailed description of these variables, please see Table 1.9. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 13 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Variable Meaning Value Parameter Settings x Hardware Type 5 NFC hardware y JCOP OS Version O JCOP4.0 eee Non-Volatile Memory Size 1M6 1.6 MB ABCDEF Build Number in hexadecimal notation 012198 SVN revision that was used to build this particular JCOP4 OS mm Mask ID 01 Customer specific pp Patch ID 00 Reserved for future use. Tab. 1.9: Platform ID Format Additionally to the Platform Identifier the TOE can also be identified by its sequence number: 1. If UpdaterOS is active then the "SELECT OS Update AID" command will return the Current Sequence Number of UpdaterOS and the Reference Sequence Number. 2. If JCOP4 OS is active then the "Get OS Info" command will return the Current Sequence Number of JCOP4 OS (Final Sequence Number). 1.3.4 Evaluated Package Types The TOE is delivered in a plastic package combined with a communication chip. All (enabled) pins of the TOE are externally accessible. Any additional security provided by the plastic package is ignored for the security of the TOE and therefore the package type is not security relevant. Common Criteria requirements for the acceptance of this package type are detailed in [6]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 14 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 2 Conformance Claims (ASE_CCL) This chapter is divided into the following sections: "CC Conformance Claim", "Package Claim", "PP Claim", and "Conformance Claim Rationale". 2.1 CC Conformance Claim This Security Target claims to be conformant to version 3.1 of Common Criteria for Information Technology Secu- rity Evaluation according to • "Common Criteria for Information Technology Security Evaluation, Part 1, Version 3.1, Revision 4, Septem- ber 2012" [3] • "Common Criteria for Information Technology Security Evaluation, Part 2, Version 3.1, Revision 4, Septem- ber 2012" [4] • "Common Criteria for Information Technology Security Evaluation, Part 3, Version 3.1, Revision 4, Septem- ber 2012" [5] The following methodology will be used for the evaluation: • Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4" [7] This Security Target claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security Func- tional Requirements are defined in Chapter 6. 2.2 Package Claim This Security Target claims conformance to the assurance package EAL6 augmented. The augmentation to EAL6 is ASE_TSS.2 “TOE summary specification with architectural design summary”, and ALC_FLR.1 “Basic flaw remediation”. 2.3 PP Claim The Security Target claims demonstrable conformance to the Java Card Protection Profile - Open Configuration, Version 3.0, Certified by ANSSI, the French Certification Body May, 2012 [9]. The Java Card Protection Profile makes the use of Java Card RMI and "Management of External Memory (EXT-MEM)" from the group EMG op- tional. The TOE does not support Java Card RMI and "Management of External Memory (EXT-MEM)" from the group EMG. This ST is more restrictive than the PP [9] which chapter 2.4 provides a rationale for. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 15 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 2.4 Conformance Claim Rationale 2.4.1 TOE Type The TOE type as stated in Section 1.2 of this ST corresponds to the TOE type of the PP as stated in Section 1.2 of [9] namely a Java Card platform, implementing the Java Card Specification Version 3.0.4 [35, 34, 33]. This Security Target claims conformance to the following packages of security requirements out of those for Cryptographic Services defined in the Smartcard IC Platform Protection profile [15]. • Package "TDES" • Package "AES" 2.4.2 SPD Statement The SPD statement that is presented in Chapter 4 includes the threats as presented in the PP [9], but also includes additional threats. These threats are: • T.RND • T.CONFID-UPDATE-IMAGE.LOAD • T.INTEG-UPDATE-IMAGE.LOAD • T.UNAUTH-LOAD-UPDATE-IMAGE • T.INTERRUPT-OSU • T.CONFIG • T.COM_EXPLOIT • T.LIFE_CYCLE • T.UNAUTHORIZED_CARD_MNGT • T.INTEG-APPLI-DATA[REFINED] • T.SEC_BOX_BORDER • T.ATTACK-COUNTER • T.UDW_DEL • T.UDW_AUTH Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 16 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The threat T.RND is taken from the Security IC PP [15]. The threats T.CONFID-UPDATE-IMAGE.LOAD, T.INTEG-UPDATE-IMAGE.LOAD, T.UNAUTH-LOAD-UPDATE-IMAGE and T.INTERRUPT-OSU are included for the OS Update which is additional functionality the PP allows. The threat T.CONFIG is an additional threat to cover unauthorized modifications and read access of the configu- ration area in the TOE. It is an addition to the threats defined in the PP [9]. The threat T.ATTACK-COUNTER is included for the Restricted Mode which is additional functionality the PP allows. The threat T.COM_EXPLOIT is included to cover communication channels attacks and it is an addition to the threats in the PP [9]. The threat T.LIFE_CYCLE is included to cover content management attacks and it is an addition to the threats in the PP [9]. The threat T.UNAUTHORIZED_CARD_MNGT refines the threats T.INSTALL and T.DELETION from the PP [9]. The threat T.INTEG-APPLI-DATA[REFINED] refines the threat T.INTEG-APPLI-DATA in the PP [9]. The threat T.SEC_BOX_BORDER is included for Secure Box which is additional functionality the PP allows. The threat T.UDW_DEL is included for the Factory Reset which is additional functionality the PP allows. The threat T.UDW_AUTH is included for the Factory Reset which is additional functionality the PP allows. Note that the threat T.EXE-CODE-REMOTE is not included, since the TOE does not support Java Card RMI. The Java Card Protection Profile [9] makes the use of Java Card RMI optional. The SPD statement presented in Chapter 4, copies the OSP from the PP [9], and adds the following additional OSPs: • OSP.PROCESS-TOE • OSP.KEY-CHANGE • OSP.SECURITY-DOMAINS • OSP.QUOTAS • OSP.SECURE-BOX The OSP OSP.PROCESS-TOE is introduced for the pre-personalisation feature of the TOE and is an addition to the OSPs in PP [9]. The OSP OSP.KEY-CHANGE is introduced for the SD feature of the TOE and is an addition to the OSPs in PP [9]. The OSP OSP.SECURITY-DOMAINS is introduced for the SD feature of the TOE and is an addition to the OSPs in PP [9]. The OSP OSP.QUOTAS is introduced for the SD feature of the TOE and is an addition to the OSPs in PP [9]. The OSP.SECURE-BOX is introduced to allow execution of third party native code and is an addition to the OSPs in PP [9]. The SPD statement includes two of the three assumptions from the PP [9]. The assumption A.Deletion is ex- cluded. The Card Manager is part of the TOE and therefore the assumption is no longer relevant. Leaving out the assumption, makes the SPD of this ST more restrictive than the SPD in the PP [9]. As the Card Manager is part of the TOE, it is ensuring that the deletion of applets through the Card Manager is secure, instead of assuming that it is handled by the Card Manager in the environment of the TOE. Besides the assumptions from the PP [9], five additional assumptions are added: Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 17 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • A.PROCESS-SEC-IC • A.USE_DIAG • A.USE_KEYS • A.APPS-PROVIDER • A.VERIFICATION-AUTHORITY The assumption A.PROCESS-SEC-IC is taken from the underlying certified Micro Controller [13], which is com- pliant to the Security IC PP [15]. The assumptions A.USE_DIAG and A.USE_KEYS are included because the Card Manager is part of the TOE and no longer part of the environment. The assumptions A.APPS-PROVIDER and A.VERIFICATION-AUTHORITY are added because Security Domains from the GlobalPlatform Specification are introduced. All the applets and packages are signed by the APSD and the correctness is verified on the TOE by VASD before the package or applet is installed or loaded. A.APPS- PROVIDER and A.VERIFICATION-AUTHORITY are additions to PP [9] for card content management environ- ment. 2.4.3 Security Objectives Statement The statement of security objectives in the ST presented in Chapter 5 includes all security objectives as presented in the PP [9], but also includes a number of additional security objectives. These security objectives are: • OT.SEC_BOX_FW • OT.IDENTIFICATION • OT.RND • OT.CONFID-UPDATE-IMAGE.LOAD • OT.AUTH-LOAD-UPDATE-IMAGE • OT.SECURE_LOAD_ACODE • OT.SECURE_AC_ACTIVATION • OT.TOE_IDENTIFICATION • OT.CARD-CONFIGURATION • OT.ATTACK-COUNTER • OT.RESTRICTED-MODE Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 18 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • OT.DOMAIN-RIGHTS • OT.APPLI-AUTH • OT.COMM_AUTH • OT.COMM_INTEGRITY • OT.COMM_CONFIDENTIALITY The security objectives OT.IDENTIFICATION, OT.RND are part of the security objectives of the certified Micro Controller [13](see also Section 1.3.1.1) and Security Software [14](see also Section 1.3.1.2.2), which are also components of this composite certification. Therefore the security objective statement is equivalent to the PP [9] for these two security objectives. OT.IDENTIFICATION is also included for the pre-personalisation feature of the TOE, which is additional functionality the PP allows. The security objective OT.SEC_BOX_FW is related to the Secure Box, which is additional functionality the PP allows. The security objective OT.CONFID-UPDATE-IMAGE.LOAD, OT.AUTH-LOAD-UPDATE-IMAGE, OT.SECURE_LOAD_ ACODE, OT.SECURE_AC_ACTIVATION, OT.TOE_IDENTIFICATION are included for the OS Update which is ad- ditional functionality the PP allows. The security objectives OT.CARD-CONFIGURATION is included for the Con- fig Applet which is additional functionality the PP allows. The security objectives OT.ATTACK-COUNTER and OT.RESTRICTED-MODE are included for the restricted mode which is additional functionality the PP allows. The security objectives OT.DOMAIN-RIGHTS, OT.APPLI-AUTH, OT.COMM_AUTH, OT.COMM_INTEGRITY, OT.COMM_ CONFIDENTIALITY are objectives for the TOE as the GlobalPlatform API and the definitions for Secure Channel, Security Domains and Card Content Management are used from it. The ST contains OE.APPLET, OE.VERIFICATION and OE.CODE-EVIDENCE from Security Objectives for the Operational Environment from [9]. Additionally, some of the Security Objectives for the Operational Environment from [9] are listed as TOE Security Objectives in this ST: • OT.SCP.RECOVERY instead of OE.SCP.RECOVERY • OT.SCP.SUPPORT instead of OE.SCP.SUPPORT • OT.SCP.IC instead of OE.SCP.IC • OT.CARD-MANAGEMENT instead of OE.CARD-MANAGEMENT OT.SCP.RECOVERY, OT.SCP.SUPPORT, and OT.SCP.IC are objectives for the TOE as the Smart Card Platform belongs to the TOE for this evaluation. OT.CARD-MANAGEMENT is an objective for the TOE as the Card Manager belongs to the TOE for this evaluation. Moving objectives from the environment to the TOE, adds objectives to the TOE without changing the overall objectives. The statement of security objectives is therefore equivalent to the security objectives in the PP [9] to which conformance is claimed. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 19 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The security objectives O.INSTALL, O.LOAD, and O.DELETION from the PP [9] are not included since these functionality and objectives are covered by the refined OT.CARD-MANAGEMENT. Note that the objective O.REMOTE is not included, since the TOE does not support Java Card RMI. The Java Card Protection Profile makes the use of Java Card RMI optional. Note that the objective O.EXT-MEM is not included, since the TOE does not support "Management of External Memory (EXT-MEM)". The Java Card Protection Profile makes the use of "Management of External Memory (EXT-MEM)" optional. A part of the security objectives for the environment defined in the PP [9] has been included in this ST. The other part of security objectives for the environment, which is present in the PP [9], is used as part of the security objectives for the TOE in this ST. The ST also introduces eight additional security objectives for the environment. The additional objectives for the environment are: • OE.USE_DIAG • OE.USE_KEYS • OE.PROCESS_SEC_IC • OE.CONFID-UPDATE-IMAGE.CREATE • OE.APPS-PROVIDER • OE.VERIFICATION-AUTHORITY • OE.KEY-CHANGE • OE.SECURITY-DOMAINS • OE.QUOTAS The security objective for the environment OE.PROCESS_SEC_IC is from the hardware platform (Micro Controller [13]see also Section 1.3.1.1) that is part of this composite product evaluation. Therefore the statement of security objectives for the environment is equivalent to the statement in the Security IC PP [15]. OE.USE_KEYS and OE.USE_DIAG are included because the Card Manager is part of the TOE and not a security objective for the environment as in PP [9]. The security objective for the environment OE.CONFID-UPDATE-IMAGE.CREATE is to cover the confidentiality during creation and transmission phase of D.UPDATE_IMAGE and therfore partly covers the threats introduced by the update mechanism which is additional functionality. OE.APPS-PROVIDER and OE.VERIFICATION-AUTHORITY cover trusted actors which enable the creation, dis- tribution and verification of secure applications. OE.KEY-CHANGE covers the switch to trusted keys for the AP. OE.SECURITY-DOMAINS covers the management of security domains in the context of the GlobalPlatform Spec- ification. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 20 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The security objective for the environment OE.QUOTAS is to cover the limitation of allocated memory for the security domains, packages or applets during their life-cycle and therefore covers the OSP which is additional functionality. The statement of security objectives for the environment is therefore considered to be equivalent to the security objectives in the PP [9] to which conformance is claimed. 2.4.4 Security Functional Requirements Statement The Security Functional Requirements Statement copies most SFRs as defined in the PP [9], with the exception of a number of options. For the copied set of SFRs the ST is considered equivalent to the statement of SFRs in the PP [9]. Moreover as requested by the PP [9] the ST adds additional threats, objectives and SFRs to fully cover and describe additional security functionality implemented in the TOE. The TOE restricts remote access from the CAD to the services implemented by the applets on the card to none, and as a result the SFRs concerning Java Card RMI (FDP_ACF.1[JCRMI], SFRs FDP_IFC.1/JCRMI, FDP_ IFF.1/JCRMI, FMT_MSA.1/EXPORT, FMT_MSA.1/REM_REFS, FMT_MSA.3/JCRMI, FMT_SMF.1/JCRMI, FMT_ REV.1/JCRMI, and FMT_SMR.1/JCRMI) are not included in the ST. In the PP [9] the use of the Java Card RMI is optional. The TOE does not implement Java Card RMI. The TOE does not allow external memory access to the services implemented by the applets on the card, and as a result the SFRs concerning "Management of External Memory (EXT-MEM)" (FDP_ACC.1/EXT_MEM, FDP_ACF.1/EXT_MEM, FMT_MSA.1/EXT_MEM, FMT_MSA.3/EXT_MEM and FMT_SMF.1/EXT_MEM) are not included in the ST. In the PP [9] the use of the "Management of External Memory (EXT-MEM)" is optional. The TOE does not implement "Management of External Memory (EXT-MEM)". The SFR FDP_ITC.2/INSTALLER from the PP [9] is replaced by FDP_ITC.2[CCM] which enforces the Firewall access control policy and the Secure Channel Protocol information flow policy and which is more restrictive than the PACKAGE LOADING information flow control SFP from PP [9]. The set of SFRs that define the card content management mechanism CarG are partly replaced or refined and are considered to be equivalent or more restrictive because of the newly introduced SFPs: 1. Security Domain access control policy 2. Secure Channel Protocol information flow policy These SFPs provide a concrete and more restrictive implementation of the PACKAGE LOADING information flow control SFP from PP [9] by following the information flow policy defined by Global Platform specifications. The table below lists the SFRs from CarG of PP [9] and their corresponding refinements in this ST. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 21 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR from PP [9] Refinement FCO_NRO.2/CM FCO_NRO.2[SC] FDP_IFC.2/CM FDP_IFC.2[SC] FDP_IFF.1/CM FDP_IFF.1[SC] FDP_UIT.1/CM FDP_UIT.1[CCM] FIA_UID.1/CM FIA_UID.1[SC] FMT_MSA.1/CM FMT_MSA.1[SC] FMT_MSA.3/CM FMT_MSA.3[SC] FMT_SMF.1/CM FMT_SMF.1[SC] FMT_SMR.1/CM FMT_SMR.1[SD] FTP_ITC.1/CM FTP_ITC.1[SC] Tab. 2.1: CarG SFRs refinements The following SFRs realize refinements of SFRs from PP [9] and add functionality to the TOE making the Security Functional Requirements Statement more restrictive than the PP [9]: FDP_ROL.1[CCM] and FPT_FLS.1[CCM] realize additional security functionality for the card manager which is allowed by the PP [9]. The set of SFRs that define the security domains mechanism as specified by GlobalPlatform, realize refinements of SFRs from PP [9] (see above table 2.1) and additional security functionality which is allowed by the PP [9]. This set of SFRs comprise FDP_ACC.1[SD], FDP_ACF.1[SD], FMT_MSA.1[SD], FMT_MSA.3[SD], FMT_SMF.1[SD], and FMT_SMR.1[SD]. The set of SFRs that define the secure channel mechanism as specified by GlobalPlatform, realize refinements of SFRs from PP [9] (see above table 2.1) and additional security functionality which is allowed by the PP [9]. This set of SFRs comprise FCO_NRO.2[SC], FDP_IFC.2[SC], FDP_IFF.1[SC], FMT_MSA.1[SC], FMT_MSA.3[SC], FMT_SMF.1[SC], FIA_UID.1[SC], FIA_UAU.1[SC], FIA_UAU.4[SC], and FTP_ITC.1[SC]. The set of SFRs that define the Secure Box, realize additional security functionality which is allowed by the PP [9]. This set of SFRs comprise FDP_ACC.2[SecureBox], FDP_ACF.1[SecureBox], FMT_MSA.1[SecureBox], FMT_MSA.3[SecureBox], and FMT_SMF.1[SecureBox]. The SFRs FAU_SAS.1[SCP], FIA_AFL.1[PIN] and FCS_RNG.1 realize additional security functionality which is allowed by the PP [9]. The set of SFRs that define the Config Applet realize additional security functionality, which is allowed by the PP [9]. This set of SFRs comprise FDP_IFC.2[CFG], FDP_IFF.1[CFG], FIA_UID.1[CFG], FMT_MSA.1[CFG], FMT_ MSA.3[CFG], FMT_SMF.1[CFG], FMT_SMR.1[CFG] The set of SFRs that define the OS Update realize addi- tional security functionality, which is allowed by the PP [9]. This set of SFRs comprise FDP_IFC.2[OSU], FDP_ IFF.1[OSU], FMT_MSA.3[OSU], FMT_MSA.1[OSU], FMT_SMR.1[OSU], FMT_SMF.1[OSU], FIA_UID.1[OSU] FIA_ UAU.1[OSU], FIA_UAU.4[OSU] and FPT_FLS.1[OSU]. The set of SFRs that define the Restricted Mode realize additional security functionality, which is allowed by Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 22 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public the PP [9]. This set of SFRs comprise FDP_ACC.2[RM], FDP_ACF.1[RM], FMT_MSA.3[RM], FMT_MSA.1[RM], FMT_SMF.1[RM], FIA_UID.1[RM] and FIA_UAU.1[RM]. The set of SFRs that define the Factory Reset realize additional security functionality, which is allowed by the PP [9]. This set of SFRs comprise FDP_ACC.2[UDW], FDP_ACF.1[UDW], FMT_MSA.3[UDW], FMT_MSA.1[UDW], FDP_RIP.1[UDW] and FPT_FLS.1[UDW]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 23 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 3 Security Aspects This chapter describes the main security issues of the Java Card System and its environment addressed in this ST, called "security aspects", in a CC-independent way. In addition to this, the security aspects also give a semi- formal framework to express the CC security environment and objectives of the TOE. They can be instantiated as assumptions, threats, objectives (for the TOE and the environment) or organizational security policies. The description is based on [9]. 3.1 Confidentiality SA.CONFID-UPDATE-IMAGE Confidentiality of Update Image The update image must be kept confidential. This concerns the non disclosure of the update image in transit to the card. SA.CONFID-APPLI-DATA Confidentiality of Application Data Application data must be protected against unauthorized disclosure. This con- cerns logical attacks at runtime in order to gain read access to other application’s data. SA.CONFID-JCS-CODE Confidentiality of Java Card System Code Java Card System code must be protected against unauthorized disclosure. Knowl- edge of the Java Card System code may allow bypassing the TSF. This concerns logical attacks at runtime in order to gain a read access to executable code, typi- cally by executing an application that tries to read the memory area where a piece of Java Card System code is stored. SA.CONFID-JCS-DATA Confidentiality of Java Card System Data Java Card System data must be protected against unauthorized disclosure. This concerns logical attacks at runtime in order to gain a read access to Java Card System data. Java Card System data includes the data managed by the Java Card RE, the Java Card VM and the internal data of Java Card platform API classes as well. 3.2 Integrity SA.INTEG-UPDATE-IMAGE Integrity of Update Image The update image must be protected against unauthorized modification. This concerns the modification of the image in transit to the card. SA.INTEG-APPLI-CODE Integrity of Application Code Application code must be protected against unauthorized modification. This con- cerns logical attacks at runtime in order to gain write access to the memory zone Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 24 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public where executable code is stored. In post-issuance application loading, this threat also concerns the modification of application code in transit to the card. SA.INTEG-APPLI-DATA Integrity of Application Data Application data must be protected against unauthorized modification. This con- cerns logical attacks at runtime in order to gain unauthorized write access to ap- plication data. In post-issuance application loading, this threat also concerns the modification of application data contained in a package in transit to the card. For instance, a package contains the values to be used for initializing the static fields of the package. SA.INTEG-JCS-CODE Integrity of Java Card System Code Java Card System code must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to executable code. SA.INTEG-JCS-DATA Integrity of Java Card System Data Java Card System data must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to Java Card System data. Java Card System data includes the data managed by the Java Card RE, the Java Card VM and the internal data of Java Card API classes as well. 3.3 Unauthorized Executions SA.EXE-APPLI-CODE Execution of Application Code Application (byte)code must be protected against unauthorized execution. This concerns: 1. invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java programming language ([16]) 2. jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code 3. unauthorized execution of a remote method from the CAD (if the TOE pro- vides JCRMI functionality). SA.EXE-JCS-CODE Execution of Java Card System Code Java Card System bytecode must be protected against unauthorized execution. Java Card System bytecode includes any code of the Java Card RE or API. This concerns: 1. invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java programming language ([16]) Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 25 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 2. jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code. Note that execute access to native code of the Java Card System and applications is the concern of SA.NATIVE. SA.FIREWALL Firewall The Firewall shall ensure controlled sharing of class instances1 , and isolation of their data and code between packages (that is, controlled execution contexts) as well as between packages and the JCRE context. An applet shall not read, write, compare a piece of data belonging to an applet that is not in the same context, or execute one of the methods of an applet in another context without its authorization. SA.NATIVE Native Code Execution Because the execution of native code is outside of the JCS TSF scope, it must be secured so as to not provide ways to bypass the TSFs of the JCS. Loading of native code, which is as well outside those TSFs, is submitted to the same requirements. Should native software be privileged in this respect, exceptions to the policies must include a rationale for the new security framework they introduce. 3.4 Bytecode Verification SA.VERIFICATION Bytecode Verification Bytecode must be verified prior to being executed. Bytecode verification includes: 1. how well-formed CAP file is and the verification of the typing constraints on the bytecode, 2. binary compatibility with installed CAP files and the assurance that the ex- port files used to check the CAP file correspond to those that will be present on the card when loading occurs. 3.5 Card Management SA.CARD-MANAGEMENT Card Management 1. The card manager (CM) shall control the access to card management func- tions such as the installation, update or deletion of applets. 2. The card manager shall implement the card issuer’s policy on the card. SA.INSTALL Installation 1This concerns in particular the arrays, which are considered as instances of the Object class in the Java programming language. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 26 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 1. The TOE must be able to return to a safe and consistent state when the installation of a package or an applet fails or be cancelled (whatever the reasons). 2. Installing an applet must have no effect on the code and data of already installed applets. The installation procedure should not be used to bypass the TSFs. In short, it is an atomic operation, free of harmful effects on the state of the other applets. 3. The procedure of loading and installing a package shall ensure its integrity and authenticity. SA.SID Subject Identification 1. Users and subjects of the TOE must be identified. 2. The identity of sensitive users and subjects associated with administrative and privileged roles must be particularly protected; this concerns the Java Card RE, the applets registered on the card, and especially the default applet and the currently selected applet (and all other active applets in Java Card System). A change of identity, especially standing for an administrative role (like an applet impersonating the Java Card RE), is a severe violation of the SFR. Selection controls the access to any data exchange between the TOE and the CAD and therefore, must be protected as well. The loading of a package or any exchange of data through the APDU buffer (which can be accessed by any applet) can lead to disclosure of keys, application code or data, and so on. SA.OBJ-DELETION Object Deletion 1. Deallocation of objects should not introduce security holes in the form of references pointing to memory zones that are not longer in use, or have been reused for other purposes. Deletion of collection of objects should not be maliciously used to circumvent the TSFs. 2. Erasure, if deemed successful, shall ensure that the deleted class instance is no longer accessible. SA.DELETION Deletion 1. Deletion of installed applets (or packages) should not introduce security holes in the form of broken references to garbage collected code or data, nor should they alter integrity or confidentiality of remaining applets. The deletion procedure should not be maliciously used to bypass the TSFs. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 27 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 2. Erasure, if deemed successful, shall ensure that any data owned by the deleted applet is no longer accessible (shared objects shall either prevent deletion or be made inaccessible). A deleted applet cannot be selected or receive APDU commands. Package deletion shall make the code of the package no longer available for execution. 3. Power failure or other failures during the process shall be taken into account in the implementation so as to preserve the SFRs. This does not mandate, however, the process to be atomic. For instance, an interrupted deletion may result in the loss of user data, as long as it does not violate the SFRs. The deletion procedure and its characteristics (whether deletion is either physi- cal or logical, what happens if the deleted application was the default applet, the order to be observed on the deletion steps) are implementation-dependent. The only commitment is that deletion shall not jeopardize the TOE (or its assets) in case of failure (such as power shortage). Deletion of a single applet instance and deletion of a whole package are func- tionally different operations and may obey different security rules. For instance, specific packages can be declared to be undeletable (for instance, the Java Card API packages), or the dependency between installed packages may forbid the deletion (like a package using super classes or super interfaces declared in an- other package). 3.6 Services SA.ALARM Alarm The TOE shall provide appropriate feedback upon detection of a potential security violation. This particularly concerns the type errors detected by the bytecode verifier, the security exceptions thrown by the Java Card VM, or any other security- related event occurring during the execution of a TSF. SA.OPERATE Operate 1. The TOE must ensure continued correct operation of its security functions. 2. In case of failure during its operation, the TOE must also return to a well- defined valid state before the next service request. SA.RESOURCES Resources The TOE controls the availability of resources for the applications and enforces quotas and limitations in order to prevent unauthorized denial of service or mal- function of the TSFs. This concerns both execution (dynamic memory allocation) and installation (static memory allocation) of applications and packages. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 28 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SA.CIPHER Cipher The TOE shall provide a means to the applications for ciphering sensitive data, for instance, through a programming interface to low-level, highly secure crypto- graphic services. In particular, those services must support cryptographic algo- rithms consistent with cryptographic usage policies and standards. SA.KEY-MNGT Key Management The TOE shall provide a means to securely manage cryptographic keys. This includes: 1. Keys shall be generated in accordance with specified cryptographic key gen- eration algorithms and specified cryptographic key sizes, 2. Keys must be distributed in accordance with specified cryptographic key dis- tribution methods, 3. Keys must be initialized before being used, 4. Keys shall be destroyed in accordance with specified cryptographic key de- struction methods. SA.PIN-MNGT PIN Management The TOE shall provide a means to securely manage PIN objects. This includes: 1. Atomic update of PIN value and try counter, 2. No rollback on the PIN-checking function, 3. Keeping the PIN value (once initialized) secret (for instance, no clear-PIN- reading function), 4. Enhanced protection of PIN’s security attributes (state, try counter ...) in confidentiality and integrity. SA.SCP Smart Card Platform The smart card platform must be secure with respect to the SFRs. Then: 1. After a power loss, RF signal loss or sudden card removal prior to completion of some communication protocol, the SCP will allow the TOE on the next power up to either complete the interrupted operation or revert to a secure state. 2. It does not allow the SFRs to be bypassed or altered and does not allow access to other low-level functions than those made available by the pack- ages of the Java Card API. That includes the protection of its private data and code (against disclosure or modification) from the Java Card System. 3. It provides secure low-level cryptographic processing to the Java Card Sys- tem. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 29 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 4. It supports the needs for any update to a single persistent object or class field to be atomic, and possibly a low-level transaction mechanism. 5. It allows the Java Card System to store data in a ”persistent technology memory” or in volatile memory, depending on its needs (for instance, tran- sient objects must not be stored in non-volatile memory). The memory model is structured and allows for low-level control accesses (segmentation fault detection). 6. It safely transmits low-level exceptions to the TOE (arithmetic exceptions, checksum errors), when applicable. 7. Finally, it is required that the IC is designed in accordance with a well-defined set of policies and standards (for instance, those specified in [15]), and will be tamper resistant to actually prevent an attacker from extracting or altering security data (like cryptographic keys) by using commonly employed tech- niques (physical probing and sophisticated analysis of the chip). This espe- cially matters to the management (storage and operation) of cryptographic keys. SA.TRANSACTION Transaction The TOE must provide a means to execute a set of operations atomically. This mechanism must not jeopardise the execution of the user applications. The trans- action status at the beginning of an applet session must be closed (no pending updates). 3.7 Config Applet SA.CONFIG-APPLET Config Applet The Config Applet is a JCOP functionality which allows to: 1. Read and modify configuration items in the configuration area of the TOE, 2. Disable Access to configuration item. 3.8 OS Update SA.OSU OS Update The UpdaterOS allows to update JCOP4 OS and the UpdaterOS itself. It ensures that only valid updates can be installed on the TOE. 3.9 Restricted Mode SA.RM Restricted Mode If the Attack Counter reaches its limit the TOE goes into Restricted Mode. In this Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 30 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public mode it is possible to perform a limited set of functions, like authenticate against the ISD, reset the Attack Counter or read logging information. 3.10 Factory Reset SA.FS Factory Reset The Factory Reset deletes all user applets, packages, SDs and their related data if they are part of the Clear List. The TOE must ensure that the Factory Reset finishes executing even if it gets interrupted e.g. by a tearing event. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 31 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 4 Security Problem Definition (ASE_SPD) 4.1 Assets Assets are security-relevant elements to be directly protected by the TOE. Confidentiality of assets is always intended with respect to un-trusted people or software, as various parties are involved during the first stages of the smart card product life-cycle. Details concerning the threats are given in Section 4.2 hereafter. Assets have to be protected, some in terms of confidentiality and some in terms of integrity or both integrity and confidentiality. These assets might get compromised by the threats that the TOE is exposed to. The assets to be protected by the TOE are listed below. They are grouped according to whether it is data created by and for the user (User data) or data created by and for the TOE (TSF data). This definition of grouping is taken from Section 5.1 of [9]. 4.1.1 User Data D.APP_CODE The code of the applets and libraries loaded on the card. To be protected from unauthorized modification. D.APP_C_DATA Confidential sensitive data of the applications, like the data con- tained in an object, a static field of a package, a local variable of the currently executed method, or a position of the operand stack. To be protected from unauthorized disclosure. D.APP_I_DATA Integrity sensitive data of the applications, like the data contained in an object, a static field of a package, a local variable of the currently executed method, or a position of the operand stack. To be protected from unauthorized modification. D.APP_KEYS Cryptographic keys owned by the applets. To be protected from unauthorized disclosure and modification. D.PIN Any end-user’s PIN. To be protected from unauthorized disclo- sure and modification. D.APSD_KEYS Refinement of D.APP_KEYS of [9]. Application Provider Security Domains cryptographic keys needed to establish secure chan- nels with the AP. These keys can be used to load and install applications on the card if the Security Domain has the appro- priate privileges. To be protected from unauthorized disclosure and modification. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 32 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public D.ISD_KEYS Refinement of D.APP_KEYS of [9]. Issuer Security Domain cryp- tographic keys needed to perform card management operations on the card. To be protected from unauthorized disclosure and modification. D.VASD_KEYS Refinement of D.APP_KEYS of [9]. Verification Authority Security Domain cryptographic keys needed to verify applications Man- dated DAP signature. To be protected from unauthorized disclo- sure and modification. D.CARD_MNGT_DATA The data of the card management environment, like for instance, the identifiers, the privileges, life cycle states, the memory re- source quotas of applets and security domains. To be protected from unauthorized modification. Tab. 4.1: User Data Assets 4.1.2 TSF Data D.API_DATA Private data of the API, like the contents of its private fields. To be protected from unauthorized disclosure and modification. D.CRYPTO Cryptographic data used in runtime cryptographic computations, like a seed used to generate a key. To be protected from unau- thorized disclosure and modification. D.JCS_CODE The code of the Java Card System. To be protected from unau- thorized disclosure and modification. D.JCS_DATA The internal runtime data areas necessary for the execution of the JCVM, such as, for instance, the frame stack, the program counter, the class of an object, the length allocated for an array, any pointer used to chain data-structures. To be protected from unauthorized disclosure or modification. D.SEC_DATA The runtime security data of the JCRE, like, for instance, the AIDs used to identify the installed applets, the currently selected applet, the current context of execution and the owner of each object. To be protected from unauthorized disclosure and modifi- cation. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 33 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public D.UPDATE_IMAGE Can be an update for JCOP4 OS and UpdaterOS. It is sent to the TOE, received by the UpdaterOS. It includes executable code, configuration data, as well as a Sequence Number (Received Sequence Number) and Image Type. To be protected from unau- thorized disclosure and modification. It is decrypted using the Package Decryption Key and its signature is verified using the Verification Key. Is also referred to as Additional Code, see [11]. D.CONFIG_ITEM A configuration that can be changed using the Config Applet. D.ATTACK_COUNTER The Attack Counter is incremented when a potential attack is de- tected. When the Attack Counter reaches its limit, the card goes into restricted mode. D.TOE_IDENTIFIER Identification Data to identify the TOE. Tab. 4.2: TSF Data Assets 4.2 Threats 4.2.1 Confidentiality T.CONFID-APPLI-DATA Confidentiality of Application Data The attacker executes an application to disclose data belonging to another ap- plication. See SA.CONFID-APPLI-DATA for details. Directly threatened asset(s): D.APP_C_DATA, D.PIN and D.APP_KEYS. T.CONFID-JCS-CODE Confidentiality of Java Card System Code The attacker executes an application to disclose the Java Card System code. See SA.CONFID-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE. T.CONFID-JCS-DATA Confidentiality of Java Card System Data The attacker executes an application to disclose data belonging to the Java Card System. See SA.CONFID-JCS-DATA for details. Directly threatened asset(s): D.API_DATA, D.SEC_DATA, D.JCS_DATA and D.CRYPTO. 4.2.2 Integrity T.INTEG-APPLI-CODE Integrity of Application Code The attacker executes an application to alter (part of) its own code or another application’s code. See SA.INTEG-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 34 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public T.INTEG-APPLI-CODE.LOAD Integrity of Application Code - Load The attacker modifies (part of) its own or another application code when an appli- cation package is transmitted to the card for installation. See SA.INTEG-APPLI- CODE for details. Directly threatened asset(s): D.APP_CODE. T.INTEG-APPLI-DATA[REFINED] Integrity of Application Data The attacker executes an application to alter (part of) another application’s data. See SA.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_ DATA, D.PIN, D.APP_KEYS, D.ISD_KEYS, D.VASD_KEYS and S.APSD_KEYS. This threat is a refinement of the Threat T.INTEG-APPLI-DATA from [9]. T.INTEG-APPLI-DATA.LOAD Integrity of Application Data - Load The attacker modifies (part of) the initialization data contained in an applica- tion package when the package is transmitted to the card for installation. See SA.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_DATA and D.APP_KEYS. T.INTEG-JCS-CODE Integrity of Java Card System Code The attacker executes an application to alter (part of) the Java Card System code. See SA.INTEG-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE. T.INTEG-JCS-DATA Integrity of Java Card System Data The attacker executes an application to alter (part of) Java Card System or API data. See SA.INTEG-JCS-DATA for details. Directly threatened asset(s): D.API_ DATA, D.SEC_DATA, D.JCS_DATA and D.CRYPTO. 4.2.3 Identity Usurpation T.SID.1 Subject Identification 1 An applet impersonates another application, or even the Java Card RE, in order to gain illegal access to some resources of the card or with respect to the end user or the terminal. See SA.SID for details. Directly threatened asset(s): D.SEC_DATA (other assets may be jeopardized should this attack succeed, for instance, if the identity of the JCRE is usurped), D.PIN and D.APP_KEYS. T.SID.2 Subject Identification 2 The attacker modifies the TOE’s attribution of a privileged role (e.g. default ap- plet and currently selected applet), which allows illegal impersonation of this role. See SA.SID for further details. Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should this attack succeed, depending on whose identity was forged). Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 35 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 4.2.4 Unauthorized Execution T.EXE-CODE.1 Code Execution 1 An applet performs an unauthorized execution of a method. See SA.EXE-JCS- CODE and SA.EXE-APPLI-CODE for details. Directly threatened asset(s): D.APP_ CODE. T.EXE-CODE.2 Code Execution 2 An applet performs an execution of a method fragment or arbitrary data. See SA.EXE-JCS-CODE and SA.EXE-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE. T.NATIVE Native Code Execution An applet executes a native method to bypass a TOE Security Function such as the firewall. See SA.NATIVE for details. Directly threatened asset(s): D.JCS_ DATA. 4.2.5 Denial of Service T.RESOURCES Consumption of Resources An attacker prevents correct operation of the Java Card System through consump- tion of some resources of the card: RAM or NVRAM. See SA.RESOURCES for details. Directly threatened asset(s): D.JCS_DATA. 4.2.6 Card Management T.UNAUTHORIZED_CARD_MNGT Unauthorized Card Management The attacker performs unauthorized card management operations (for instance impersonates one of the actor represented on the card) in order to take benefit of the privileges or services granted to this actor on the card such as fraudulent: • load of a package file • installation of a package file • extradition of a package file or an applet • personalization of an applet or a Security Domain • deletion of a package file or an applet • privileges update of an applet or a Security Domain Directly threatened asset(s): D.ISD_KEYS, D.APSD_KEYS, D.APP_C_DATA, D.APP_ I_DATA, D.APP_CODE, D.SEC_DATA, and D.CARD_MNGT_DATA (any other as- set may be jeopardized should this attack succeed, depending on the virulence of the installed application). This security objective is a refinement of the Threats T.INSTALL and T.DELETION from [9]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 36 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public T.COM_EXPLOIT Communication Channel Remote Exploit An attacker remotely exploits the communication channels established between a third party and the TOE in order to modify or disclose confidential data. All assets are threatened. T.LIFE_CYCLE Life Cycle An attacker accesses to an application outside of its expected availability range thus violating irreversible life cycle phases of the application (for instance, an at- tacker repersonalizes the application). Directly threatened asset(s): D.APP_I_ DATA, D.APP_C_DATA, and D.CARD_MNGT_DATA. 4.2.7 Services T.OBJ-DELETION Object Deletion The attacker keeps a reference to a garbage collected object in order to force the TOE to execute an unavailable method, to make it to crash, or to gain access to a memory containing data that is now being used by another application. See SA.OBJ-DELETION for further details. Directly threatened asset(s): D.APP_C_ DATA, D.APP_I_DATA and D.APP_KEYS. 4.2.8 Miscellaneous T.PHYSICAL Physical Tampering The attacker discloses or modifies the design of the TOE, its sensitive data or application code by physical (opposed to logical) tampering means. This threat includes IC failure analysis, electrical probing, unexpected tearing, and DPA. That also includes the modification of the runtime execution of Java Card System or SCP software through alteration of the intended execution order of (set of) in- structions through physical tampering techniques. This threatens all the identified assets. This threat refers to the point (7) of the security aspect SA.SCP, and all aspects related to confidentiality and integrity of code and data. 4.2.9 Random Numbers T.RND Deficiency of Random Numbers An attacker may predict or obtain information about random numbers generated by the TOE for instance because of a lack of entropy of the random numbers pro- vided. An attacker may gather information about the produced random numbers which might be a problem because they may be used for instance to generate cryptographic keys. Here the attacker is expected to take advantage of statis- tical properties of the random numbers generated by the TOE without specific knowledge about the TOE’s generator. Malfunctions or premature ageing are also considered which may assist in getting information about random numbers. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 37 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 4.2.10 Config Applet T.CONFIG Unauthorized configuration The attacker tries to change configuration items without authorization. Directly threatened asset(s): D.CONFIG_ITEM. 4.2.11 OS Update T.CONFID-UPDATE-IMAGE.LOAD Confidentiality of Update Image - Load The attacker discloses (part of) the image used to update the TOE in the field while the image is transmitted to the card for installation. See SA.CONFID-UPDATE- IMAGE for details. Directly threatened asset(s): D.UPDATE_IMAGE, D.JCS_ CODE, and D.JCS_DATA. T.UNAUTH-LOAD-UPDATE-IMAGE Load unauthorized version of Update Image The attacker tries to upload an unauthorized Update Image. Directly threatened asset(s): D.JCS_CODE, D.JCS_DATA, D.UPDATE_IMAGE. T.INTEG-UPDATE-IMAGE.LOAD Integrity of Update Image - Load The attacker modifies (part of) the image used to update the TOE in the field while the image is transmitted to the card for installation. See SA.INTEG-UPDATE- IMAGE for details. Directly threatened asset(s): D.UPDATE_IMAGE, D.JCS_ CODE, and D.JCS_DATA T.INTERRUPT-OSU OS Update procedure interrupted The attacker tries to interrupt the OS Update procedure (Load Phase through ac- tivation of additional code) leaving the TOE in a partially functional state . Directly threatened asset(s): D.JCS_CODE, D.JCS_DATA, D.UPDATE_IMAGE, D.TOE_ IDENTIFIER. 4.2.12 Secure Box T.SEC_BOX_BORDER SecureBox Border Infringement An attacker may try to use malicious code placed in the Secure Box to modify the correct behavior of the OS. With the aim to 1. disclose the Java Card System code, 2. disclose or alter applet code, disclose or alter Java Card System data, or disclose or alter applet data. 4.2.13 Restricted Mode T.ATTACK-COUNTER Modification of the Attack Counter The attacker tries to modify the attack counter without authorization. Directly threatened asset: D.ATTACK_COUNTER. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 38 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 4.2.14 Factory Reset T.UDW_DEL User Data Available after Factory Reset An attacker tries to interrupt the deletion of packages, applets, Security Domains and their related Data during the Factory Reset process so that these objects are not deleted as intended. The data continues to be available on the TOE contrary to the user’s expectation and without his awareness. The attacker can use this data in a fraudulent way. Directly threatened assets: D.APP_C_DATA, D.APP_I_ DATA, D.APP_KEYS, D.PIN, D.APSD_KEYS. T.UDW_AUTH Triggering Factory Reset An attacker, i.e. a not authorized user for triggering the Factory Reset process, tries to start the Factory Reset process. Directly threatened assets: D.APP_C_ DATA, D.APP_I_DATA, D.APP_KEYS, D.PIN, D.APSD_KEYS. T.UDW_CL Unauthorized Clear List Modification An attacker, i.e. a not authorized user tries to modify the Clear List. An unintended modification of the Clear List can result in omitting deleting assets that become available to the attacker after Factory Reset process. Directly threatened assets: D.APP_C_DATA, D.APP_I_DATA, D.APP_KEYS, D.PIN, D.APSD_KEYS. 4.3 Organisational Security Policies OSP.VERIFICATION File Verification This policy shall ensure the consistency between the export files used in the veri- fication and those used for installing the verified file. The policy must also ensure that no modification of the file is performed in between its verification and the signing by the verification authority. See SA.VERIFICATION for details. If the application development guidance provided by the platform developer con- tains recommandations related to the isolation property of the platform, this policy shall also ensure that the verification authority checks that these recommanda- tions are applied in the application code OSP.PROCESS-TOE Identification of the TOE An accurate identification must be established for the TOE. This requires that each instantiation of the TOE carries this identification. OSP.KEY-CHANGE Security Domain Keys Change The AP shall change its initial security domain keys (APSD) before any operation on its Security Domain. OSP.SECURITY-DOMAINS Security Domains Security domains can be dynamically created, deleted and blocked during usage phase in post-issuance mode. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 39 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public OSP.QUOTAS Quotas for Security Domains, packages and applets Security domains, packages and applets may be subject to memory quotas during their life-cycle. OSP.SECURE-BOX Secure Box Border Execution of untrusted native code shall be possible without any harm, manipula- tion, or influence on other parts of the TOE. 4.4 Assumptions Note that the assumption A.DELETION is excluded. The Card Manager is part of the TOE and therefore the assumption is no longer relevant. A.APPLET Applets without Native Methods Applets loaded post-issuance do not contain native methods. The Java Card spec- ification explicitly ”does not include support for native methods” ([35]) outside the API. A.VERIFICATION Bytecode Verification All the bytecodes are verified at least once, before the loading, before the installa- tion or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time. A.USE_DIAG Usage of TOE’s Secure Communication Protocol by OE It is assumed that the operational environment supports and uses the secure com- munication protocols offered by the TOE. A.USE_KEYS Protected Storage of Keys Outside of TOE It is assumed that the keys which are stored outside the TOE and which are used for secure communication and authentication between Smart Card and terminals are protected for confidentiality and integrity in their own storage environment. This is especially true for D.APSD_KEYS, D.ISD_KEYS, and D.VASD_KEYS. Info: This is to assume that the keys used in terminals or systems are correctly protected for confidentiality and integrity in their own environment, as the disclo- sure of such information which is shared with the TOE but is not under the TOE control, may compromise the security of the TOE. A.PROCESS-SEC-IC Protection during Packaging, Finishing and Personalisation It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to delivery to the end consumer to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorised use). This means that the Phases after TOE Delivery are assumed to be protected appropriately. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 40 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The assets to be protected are: The information and material produced and/or processed by the Security IC Embedded Software Developer in Phase 1 and by the Composite Product Manufacturer can be grouped as follows: 1. the Security IC Embedded Software including specifications, implementation and related documentation, 2. pre-personalisation and personalisation data including specifications of for- mats and memory areas, test related data, 3. the User Data and related documentation, and 4. material for software development support as long as they are not under the control of the TOE Manufacturer. A.APPS-PROVIDER Application Provider The AP is a trusted actor that provides basic or secure applications. He is respon- sible for his security domain keys (D.APSD_KEYS). Info: An AP generally refers to the entity that issues the application. For instance it can be a financial institution for a payment application such as EMV or a transport operator for a transport application. A.VERIFICATION-AUTHORITY Verification Authority The VA is a trusted actor who is able to verify bytecode of an application loaded on the card, guarantee and generate the digital signature attached to an application and ensure that its public key for verifying the application signature is on the TOE. Info: As a consequence, it guarantees the success of the application validation upon loading. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 41 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5 Security Objectives 5.1 Security Objectives for the TOE 5.1.1 Identification OT.SID Subject Identification The TOE shall uniquely identify every subject (applet, or package) before granting it access to any service. 5.1.2 Execution OT.FIREWALL Firewall The TOE shall ensure controlled sharing of data containers owned by applets of dif- ferent packages or the JCRE and between applets and the TSFs. See SA.FIREWALL for details. OT.GLOBAL_ARRAYS_CONFID Confidentiality of Global Arrays The TOE shall ensure that the APDU buffer that is shared by all applications is always cleaned upon applet selection. The TOE shall ensure that the global byte array used for the invocation of the install method of the selected applet is always cleaned after the return from the install method. OT.GLOBAL_ARRAYS_INTEG Integrity of Global Arrays The TOE shall ensure that only the currently selected applications may have a write access to the APDU buffer and the global byte array used for the invocation of the install method of the selected applet. OT.NATIVE Native Code The only means that the Java Card VM shall provide for an application to execute native code is the invocation of a method of the Java Card API, or any additional API. See SA.NATIVE for details. OT.OPERATE Correct Operation The TOE must ensure continued correct operation of its security functions. See SA.OPERATE for details. OT.REALLOCATION Secure Re-Allocation The TOE shall ensure that the re-allocation of a memory block for the runtime areas of the Java Card VM does not disclose any information that was previously stored in that block. OT.RESOURCES Resources availability The TOE shall control the availability of resources for the applications. See SA.RESOURCES for details. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 42 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5.1.3 Services OT.ALARM Alarm The TOE shall provide appropriate feedback information upon detection of a potential security violation. See SA.ALARM for details. OT.CIPHER Cipher The TOE shall provide a means to cipher sensitive data for applications in a secure way. In particular, the TOE must support cryptographic algorithms consistent with cryptographic usage policies and standards. See SA.CIPHER for details. OT.KEY-MNGT Key Management The TOE shall provide a means to securely manage cryptographic keys. This con- cerns the correct generation, distribution, access and destruction of cryptographic keys. See SA.KEY-MNGT. OT.PIN-MNGT Pin Management The TOE shall provide a means to securely manage PIN objects. See SA.PIN-MNGT for details. AppNote: PIN objects may play key roles in the security architecture of client applica- tions. The way they are stored and managed in the memory of the smart card must be carefully considered, and this applies to the whole object rather than the sole value of the PIN. OT.TRANSACTION Transaction The TOE must provide a means to execute a set of operations atomically. See SA.TRANSACTION for details. 5.1.4 Object Deletion OT.OBJ-DELETION Object Deletion The TOE shall ensure the object deletion shall not break references to objects. See SA.OBJ-DELETION for further details. 5.1.5 Applet Management OT.APPLI-AUTH Application Authentication The card manager shall enforce the application security policies established by the card issuer by requiring application authentication during application loading on the card. This security objective is a refinement of the Security Objective O.LOAD from [9]. AppNote: Each application loaded onto the TOE has been signed by a VA. The VA will guarantee that the security policies established by the card issuer on applications are enforced. For example this authority (DAP) or a third party (Mandated DAP) can Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 43 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public be present on the TOE as a Security Domain whose role is to verify each signature at application loading. OT.DOMAIN-RIGHTS Domain Rights The Card issuer shall not get access or change personalized AP Security Domain keys which belong to the AP. Modification of a Security Domain keyset is restricted to the AP who owns the security domain. AppNote: APs have a set of keys that allows them to establish a secure channel be- tween them and the platform. These keys sets are not known by the TOE issuer. The security domain initial keys are changed before any operation on the SD (OE.KEY- CHANGE). OT.COMM_AUTH Communication Mutual Authentication The TOE shall authenticate the origin of the card management requests that the card receives, and authenticate itself to the remote actor. OT.COMM_INTEGRITY Communication Request Integrity The TOE shall verify the integrity of the card management requests that the card receives. OT.COMM_CONFIDENTIALITY Communication Request Confidentiality The TOE shall be able to process card management requests containing encrypted data. 5.1.6 Card Management OT.CARD-MANAGEMENT Card Management The TOE shall provide card management functionalities (loading, installation, extradi- tion, deletion of applications and GP registry updates) in charge of the life cycle of the whole device and installed applications (applets). The card manager, the application with specific rights responsible for the administration of the smart card, shall control the access to card management functions. It shall also implement the card issuer’s policy on card management. The Security Objective from [9] for the environment OE.CARD-MANAGEMENT is listed as TOE Security Objective OT.CARD-MANAGEMENT for the TOE as the Card Manager belongs to the TOE for this evaluation. This security objective is a refine- ment for the Security Objectives O.INSTALL, O.LOAD, and O.DELETION from [9]. Thus, the following objectives are also covered: • The TOE shall ensure that the installation of an applet performs as expected (See SA.INSTALL for details). • The TOE shall ensure that the loading of a package into the card is secure. • The TOE shall ensure that the deletion of a package from the TOE is secure. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 44 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public . AppNote: The card manager will be tightly connected in practice with the rest of the TOE, which in return shall very likely rely on the card manager for the effective enforcement of some of its security functions. The mechanism used to ensure au- thentication of the TOE issuer, that manages the TOE, or of the Service Providers owning a Security Domain with card management privileges is a secure channel. This channel will be used afterwards to protect commands exchanged with the TOE in confidentiality and integrity. The platform guarantees that only the ISD or the Ser- vice Providers owning a Security Domain with the appropriate privilege (Delegated Management) can manage the applications on the card associated with its Security Domain. This is done accordingly with the card issuer’s policy on card management. The actor performing the operation must beforehand authenticate with the Security Domain. In the case of Delegated Management, the card management command will be associated with an electronic signature (GlobalPlatform token) verified by the ISD before execution. The Security Objective from [9] for the environment OE.CARD-MANAGEMENT is listed as TOE Security Objective OT.CARD-MANAGEMENT for the TOE as the Card Manager belongs to the TOE for this evaluation. This security objective is a refine- ment for the Security Objectives O.INSTALL, O.LOAD, and O.DELETION from [9]. Thus, the following AppNote applicable to O.DELETION applies also: • Usurpation of identity resulting from a malicious installation of an applet on the card may also be the result of perturbing the communication channel linking the CAD and the card. Even if the CAD is placed in a secure environment, the attacker may try to capture, duplicate, permute or modify the packages sent to the card. He may also try to send one of its own applications as if it came from the card issuer. Thus, this objective is intended to ensure the integrity and authenticity of loaded CAP files. 5.1.7 Smart Card Platform OT.SCP.IC IC Physical Protection The SCP shall provide all IC security features against physical attacks. This security objective for the environment refers to the point (7) of the security aspect SA.SCP. AppNote: The Security Objectives from [9] for the environment OE.SCP.RECOVERY, OE.SCP.SUPPORT, and OE.SCP.IC are listed as TOE Security Objectives (OT.SCP.RECOVERY, OT.SCP.SUPPORT, and OT.SCP.IC) for the TOE in this section as the Smart Card Platform belongs to the TOE for this evaluation. OT.SCP.RECOVERY SCP Recovery If there is a loss of power, or if the smart card is withdrawn from the CAD while an operation is in progress, the SCP must allow the TOE to eventually complete the in- terrupted operation successfully, or recover to a consistent and secure state. This Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 45 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public security objective for the environment refers to the security aspect SA.SCP AppNote: The Security Objectives from [9] for the environment OE.SCP.RECOVERY, OE.SCP.SUPPORT, and OE.SCP.IC are listed as TOE Security Objectives (OT.SCP.RECOVERY, OT.SCP.SUPPORT, and OT.SCP.IC) for the TOE in this section as the Smart Card Platform belongs to the TOE for this evaluation. OT.SCP.SUPPORT SCP Support The SCP shall support the TSFs of the TOE. This security objective refers to the se- curity aspects 2, 3, 4 and 5 of SA.SCP AppNote: The Security Objectives from [9] for the environment OE.SCP.RECOVERY, OE.SCP.SUPPORT, and OE.SCP.IC are listed as TOE Security Objectives (OT.SCP.RECOVERY, OT.SCP.SUPPORT, and OT.SCP.IC) for the TOE in this section as the Smart Card Platform belongs to the TOE for this evaluation. OT.IDENTIFICATION TOE identification The TOE must provide means to store Initialization Data and Pre-personalization Data in its non-volatile memory. The Initialization Data (or parts of them) are used for TOE identification. 5.1.8 SecureBox OT.SEC_BOX_FW SecureBox firewall The TOE shall provide separation between the Secure Box native code and the Java Card System. The separation shall comprise software execution and data access. 5.1.9 Random Numbers OT.RND Quality of random numbers The TOE will ensure the cryptographic quality of random number generation. For instance random numbers shall not be predictable and shall have sufficient entropy. The TOE will ensure that no information about the produced random numbers is avail- able to an attacker since they might be used for instance to generate cryptographic keys. 5.1.10 OS Update Mechanism OT.CONFID-UPDATE-IMAGE.LO AD Confidentiality of Update Image - Load The TOE shall ensure that the encrypted image transferred to the device is not dis- closed during the installation. The keys used for decrypting the image shall be kept confidential. OT.AUTH-LOAD-UPDATE-IMAGE Authorization of Update Image - Load The TOE shall ensure that it is only possible to load an authorized image. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 46 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The following Security Objectives have been added to comply to JIL "Security requirements for post-delivery code loading" [11]. OT.SECURE_LOAD_ACODE Secure loading of the Additional Code The Loader of the Initial TOE shall check an evidence of authenticity and integrity of the loaded Additional Code. The Loader enforces that only the allowed version of the Additional Code can be loaded on the Initial TOE. The Loader shall forbid the loading of an Additional Code not intended to be assembled with the Initial TOE. During the Load Phase of an Additional Code, the TOE shall remain secure. OT.SECURE_AC_ACTIVATION Secure activation of the Additional Code Activation of the Additional Code and update of the Identification Data shall be per- formed at the same time in an Atomic way. All the operations needed for the code to be able to operate as in the Final TOE shall be completed before activation. If the Atomic Activation is successful, then the resulting product is the Final TOE, otherwise (in case of interruption or incident which prevents the forming of the Final TOE), the Initial TOE shall remain in its initial state or fail secure. OT.TOE_IDENTIFICATION Secure identification of the TOE The Identification Data identifies the Initial TOE and Additional Code. The TOE pro- vides means to store Identification Data in its non-volatile memory and guarantees the integrity of these data. After Atomic Activation of the Additional Code, the Identifi- cation Data of the Final TOE allows identifications of Initial TOE and Additional Code. The user shall be able to uniquely identify Initial TOE and Additional Code(s) which are embedded in the Final TOE. 5.1.11 Config Applet OT.CARD-CONFIGURATION Card Configuration The TOE shall ensure that the customer can only configure customer configuration items and that NXP can configure customer and NXP configuration items. Addition- ally, the customer can only disable the customer configuration and NXP can disable customer and NXP configuration. 5.1.12 Restricted Mode OT.ATTACK-COUNTER Attack Counter The TOE shall ensure that only the ISD can reset the Attack Counter. OT.RESTRICTED-MODE Restricted Mode The TOE shall ensure that in Restricted Mode all operations return an error except for the limited set of commands that are allowed by the TOE when in Restricted Mode. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 47 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5.1.13 Factory Reset OT.UDW_AUTH Triggering The TOE shall ensure that only authorized users can trigger the Factory Reset pro- cess. OT.UDW_CLEAR Clear List The TOE shall ensure that only authorized applications can modify the Clear List and that only contents included in the Clear List are deleted during the Factory reset: applets, packages, SDs and their related data. OT.UDW_ATOMIC Atomicity The TOE shall ensure that in the case that the Factory Reset process gets interrupted (e.g. tearing event) it must be resumed and concluded before processing further commands. 5.2 Security Objectives for the Operational Environment OE.APPLET Applet No applet loaded post-issuance shall contain native methods. OE.VERIFICATION Bytecode Verification All the bytecodes shall be verified at least once, before the loading, before the instal- lation or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time. See SA.VERIFICATION for details. Additionally, the applet shall follow all the recommendations, if any, mandated in the platform guidance for maintaining the isolation property of the platform. Application Note: Constraints to maintain the isolation property of the platform are provided by the plat- form developer in application development guidance. The constraints apply to all application code loaded in the platform. OE.CODE-EVIDENCE Code Evidence For application code loaded pre-issuance, evaluated technical measures implemented by the TOE or audited organizational measures must ensure that loaded application has not been changed since the code verifications required in OE.VERIFICATION. For application code loaded post-issuance and verified off-card according to the re- quirements of OE.VERIFICATION, the verification authority shall provide digital ev- idence to the TOE that the application code has not been modified after the code verification and that he is the actor who performed code verification. For application code loaded post-issuance and partially or entirely verified on-card, technical measures must ensure that the verification required in OE.VERIFICATION are performed. On-card bytecode verifier is out of the scope of this Protection Profile. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 48 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Application Note: For application code loaded post-issuance and verified off-card, the integrity and authenticity evidence can be achieved by electronic signature of the application code, after code verification, by the actor who performed verification. OE.APPS-PROVIDER Application Provider The AP shall be a trusted actor that provides applications. The AP is responsible for its security domain keys. OE.VERIFICATION-AUTHORITY Verification Authority The VA should be a trusted actor who is able to verify bytecode of an application loaded on the card, guarantee and generate the digital signature attached to an ap- plication and ensure that its public key for verifying the application signature is on the TOE. OE.KEY-CHANGE Security Domain Key Change The AP must change its security domain initial keys before any operation on it. OE.SECURITY-DOMAINS Security Domains Security domains can be dynamically created, deleted and blocked during usage phase in post-issuance mode. OE.QUOTAS Quotas for Security Domains, packages and Applets Security Domains, packages and applets may be subject to memory quotas during their life cycle. OE.USE_DIAG Secure TOE communication protocols Secure TOE communication protocols shall be supported and used by the environ- ment. OE.USE_KEYS Protection of OPE keys During the TOE usage, the terminal or system in interaction with the TOE, shall ensure the protection (integrity and confidentiality) of their own keys by operational means and/or procedures. OE.PROCESS_SEC_IC Protection during composite product manufacturing Security procedures shall be used after TOE Delivery up to delivery to the end- consumer to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unautho- rised use). This means that Phases after TOE Delivery up to the end of Phase 6 must be protected appropriately. OE.CONFID-UPDATE-IMAGE.CR EATE Confidentiality of Update Image - CREATE The off-card Update Image Creator ensures that the image is signed and transferred encrypted to the device and is not disclosed during the creation and transfer. The keys used for signing and encrypting the image are kept confidential. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 49 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5.3 Security Objectives Rationale In this section it is proven that the security objectives described in Chapter 4 can be traced for all aspects identified in the TOE-security environment and that they are suited to cover them. At least one security objective results from each assumption, OSP, and each threat. At least one threat, one OSP or assumption exists for each security objective. Security Problem Definition Security Objective T.CONFID-UPDATE-IMAGE.LOAD OT.CONFID-UPDATE-IMAGE.LOAD OE.CONFID-UPDATE-IMAGE.CREATE T.CONFID-APPLI-DATA OT.SID OT.FIREWALL OT.GLOBAL_ARRAYS_CONFID OT.OPERATE OT.REALLOCATION OT.ALARM OT.CIPHER OT.KEY-MNGT OT.PIN-MNGT OT.TRANSACTION OE.VERIFICATION OT.CARD-MANAGEMENT OT.SCP.RECOVERY OT.SCP.SUPPORT T.CONFID-JCS-CODE OT.NATIVE OE.VERIFICATION OT.CARD-MANAGEMENT T.CONFID-JCS-DATA OT.SID OT.FIREWALL OT.OPERATE OT.ALARM OE.VERIFICATION OT.CARD-MANAGEMENT OT.SCP.RECOVERY OT.SCP.SUPPORT T.INTEG-UPDATE-IMAGE.LOAD OT.SECURE_LOAD_ACODE T.INTEG-APPLI-CODE OT.NATIVE OE.VERIFICATION OT.CARD-MANAGEMENT OE.CODE-EVIDENCE T.INTEG-APPLI-CODE.LOAD OT.CARD-MANAGEMENT OE.CODE-EVIDENCE Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 50 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Security Problem Definition Security Objective OT.APPLI-AUTH T.INTEG-APPLI-DATA[REFINED] OT.SID OT.FIREWALL OT.GLOBAL_ARRAYS_INTEG OT.OPERATE OT.REALLOCATION OT.ALARM OT.CIPHER OT.KEY-MNGT OT.PIN-MNGT OT.TRANSACTION OE.VERIFICATION OT.CARD-MANAGEMENT OT.SCP.RECOVERY OT.SCP.SUPPORT OE.CODE-EVIDENCE OT.DOMAIN-RIGHTS T.INTEG-APPLI-DATA.LOAD OT.CARD-MANAGEMENT OE.CODE-EVIDENCE OT.APPLI-AUTH T.INTEG-JCS-CODE OT.NATIVE OE.VERIFICATION OT.CARD-MANAGEMENT OE.CODE-EVIDENCE T.INTEG-JCS-DATA OT.SID OT.FIREWALL OT.OPERATE OT.ALARM OE.VERIFICATION OT.CARD-MANAGEMENT OT.SCP.RECOVERY OT.SCP.SUPPORT OE.CODE-EVIDENCE T.SID.1 OT.SID OT.FIREWALL OT.GLOBAL_ARRAYS_CONFID OT.GLOBAL_ARRAYS_INTEG OT.CARD-MANAGEMENT T.SID.2 OT.SID OT.FIREWALL Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 51 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Security Problem Definition Security Objective OT.OPERATE OT.CARD-MANAGEMENT OT.SCP.RECOVERY OT.SCP.SUPPORT T.EXE-CODE.1 OT.FIREWALL OE.VERIFICATION T.EXE-CODE.2 OE.VERIFICATION T.NATIVE OT.NATIVE OE.APPLET OE.VERIFICATION T.RESOURCES OT.OPERATE OT.RESOURCES OT.CARD-MANAGEMENT OT.SCP.RECOVERY OT.SCP.SUPPORT T.UNAUTHORIZED_CARD_MNGT OT.CARD-MANAGEMENT OT.DOMAIN-RIGHTS OT.COMM_AUTH OT.COMM_INTEGRITY OT.APPLI-AUTH T.LIFE_CYCLE OT.CARD-MANAGEMENT OT.DOMAIN-RIGHTS T.COM_EXPLOIT OT.COMM_AUTH OT.COMM_INTEGRITY OT.COMM_CONFIDENTIALITY T.OBJ-DELETION OT.OBJ-DELETION T.UNAUTH-LOAD-UPDATE-IMAGE OT.SECURE_LOAD_ACODE OT.AUTH-LOAD-UPDATE-IMAGE T.INTERRUPT-OSU OT.SECURE_LOAD_ACODE OT.TOE_IDENTIFICATION OT.SECURE_AC_ACTIVATION T.CONFIG OT.CARD-CONFIGURATION T.ATTACK-COUNTER OT.ATTACK-COUNTER OT.RESTRICTED-MODE T.PHYSICAL OT.SCP.IC OT.RESTRICTED-MODE T.SEC_BOX_BORDER OT.SEC_BOX_FW T.RND OT.RND T.UDW_DEL OT.UDW_ATOMIC Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 52 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Security Problem Definition Security Objective OT.UDW_CLEAR T.UDW_CL OT.UDW_CLEAR T.UDW_AUTH OT.UDW_AUTH OSP.VERIFICATION OE.VERIFICATION OT.CARD-MANAGEMENT OE.CODE-EVIDENCE OT.APPLI-AUTH OSP.PROCESS-TOE OT.IDENTIFICATION OSP.KEY-CHANGE OE.KEY-CHANGE OSP.SECURITY-DOMAINS OE.SECURITY-DOMAINS OSP.QUOTAS OE.QUOTAS OSP.SECURE-BOX OT.SEC_BOX_FW A.APPLET OE.APPLET A.VERIFICATION OE.VERIFICATION OE.CODE-EVIDENCE A.USE_DIAG OE.USE_DIAG A.USE_KEYS OE.USE_KEYS A.PROCESS-SEC-IC OE.PROCESS_SEC_IC A.APPS-PROVIDER OE.APPS-PROVIDER A.VERIFICATION-AUTHORITY OE.VERIFICATION-AUTHORITY Tab. 5.1: SPDs of the TOE vs. Objectives 5.3.1 Threats 5.3.1.1 Confidentiality T.CONFID-UPDATE-IMAGE.LOAD Objective Rationale OT.CONFID-UPDATE- IMAGE.LOAD Counters the threat by ensuring the confidentiality of D.UPDATE_ IMAGE during installing it on the TOE. OE.CONFID-UPDATE- IMAGE.CREATE Counters the threat by ensuring that the D.UPDATE_IMAGE is not transfered in plain and that the keys are kept secret. T.CONFID-APPLI-DATA Objective Rationale OT.SID Counters this threat by providing correct identification of applets. OT.FIREWALL Counters this threat by providing the Java Card Virtual Machine Firewall as specified in [34]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 53 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.GLOBAL_ARRAYS_CONFID Counters this threat by preventing the disclosure of the informa- tion stored in the APDU buffer. OT.OPERATE Counters the threat by ensuring that the firewall, which is dynam- ically enforced, shall never stop operating. OT.REALLOCATION Counters this threat by preventing any attempt to read a piece of information that was previously used by an application but has been logically deleted. It states that any information that was formerly stored in a memory block shall be cleared before the block is reused. OT.ALARM Counters this threat by obtaining clear warning and error mes- sages from the firewall, which is a software tool automating crit- ical controls, so that the appropriate countermeasure can be taken. OT.CIPHER Contributes to counter this threat by protecting the data shared or information communicated between applets and the CAD using cryptographic functions. OT.KEY-MNGT Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen- sitive data. OT.PIN-MNGT Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen- sitive data. OT.TRANSACTION Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen- sitive data. OE.VERIFICATION Contributes to counter the threat by checking the bytecode. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. OT.SCP.RECOVERY Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. OT.SCP.SUPPORT Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. T.CONFID-JCS-CODE Objective Rationale OT.NATIVE Counters this threat by ensuring that no native applications can be run to modify a piece of code. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 54 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OE.VERIFICATION Contributes to counter the threat by checking the bytecode. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. T.CONFID-JCS-DATA Objective Rationale OT.SID Counters this threat by providing correct identification of applets. OT.FIREWALL Contributes to counter this threat by providing means of separat- ing data. OT.OPERATE Counters the threat by ensuring that the firewall, which is dynam- ically enforced, shall never stop operating. OT.ALARM Contributes to counter this threat by obtaining clear warning and error messages from the firewall, which is a software tool au- tomating critical controls, so that the appropriate countermeasure can be taken. OE.VERIFICATION Contributes to counter the threat by checking the bytecode. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. OT.SCP.RECOVERY Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. OT.SCP.SUPPORT Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. 5.3.1.2 Integrity T.INTEG-UPDATE-IMAGE.LOAD Objective Rationale OT.SECURE_LOAD_ACODE Counters the threat directly by ensuring the authenticity and in- tegrity of D.UPDATE_IMAGE. T.INTEG-APPLI-CODE Objective Rationale OT.NATIVE Counters this threat by ensuring that no native code can be run to modify a piece of code. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 55 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OE.VERIFICATION Contributes to counter the threat by checking the bytecode. Byte- code verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of these instruc- tions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. OE.CODE-EVIDENCE The objective OE.CODE-EVIDENCE contributes to counter this threat by ensuring that integrity and authenticity evidences exist for the application code loaded into the platform. T.INTEG-APPLI-CODE.LOAD Objective Rationale OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions such as the installation, update or dele- tion of applets. OE.CODE-EVIDENCE Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. OT.APPLI-AUTH Counters this threat by ensuring that the loading of packages is done securely and thus preserves the integrity of packages code. T.INTEG-APPLI-DATA[REFINED] Objective Rationale OT.SID Counters this threat by providing correct identification of applets. OT.FIREWALL Contributes to counter this threat by providing means of separat- ing data. OT.GLOBAL_ARRAYS_INTEG Counters this threat by ensuring the integrity of the information stored in the APDU buffer. Application data that is sent to the ap- plet as clear text arrives in the APDU buffer, which is a resource shared by all applications. OT.OPERATE Counters the threat by ensuring that the firewall, which is dynam- ically enforced, shall never stop operating. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 56 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.REALLOCATION Counters the threat by preventing any attempt to read a piece of information that was previously used by an application but has been logically deleted. It states that any information that was formerly stored in a memory block shall be cleared before the block is reused. OT.ALARM Contributes to counter this threat by obtaining clear warning and error messages from the firewall, which is a software tool au- tomating critical controls, so that the appropriate countermeasure can be taken. OT.CIPHER Contributes to counter this threat by protecting the data shared or information communicated between applets and the CAD using cryptographic functions. OT.KEY-MNGT Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data. OT.PIN-MNGT Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data. OT.TRANSACTION Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data. OE.VERIFICATION Contributes to counter the threat by checking the bytecode. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. OT.SCP.RECOVERY Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. OT.SCP.SUPPORT Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. OE.CODE-EVIDENCE Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. OT.DOMAIN-RIGHTS Contributes to counter this threat by ensuring that personaliza- tion of the application by its associated security domain is only performed by the authorized AP. T.INTEG-APPLI-DATA.LOAD Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 57 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions such as the installation, update or dele- tion of applets. OE.CODE-EVIDENCE Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. OT.APPLI-AUTH Counters this threat by ensuring that the loading of packages is done securely and thus preserves the integrity of packages code. T.INTEG-JCS-CODE Objective Rationale OT.NATIVE Counters this threat by ensuring that no native code can be run to modify a piece of code. OE.VERIFICATION Contributes to counter the threat by checking the bytecode. Byte- code verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of these instruc- tions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. OE.CODE-EVIDENCE Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. T.INTEG-JCS-DATA Objective Rationale OT.SID Counters this threat by providing correct identification of applets. OT.FIREWALL Contributes to counter this threat by providing means of separa- tion. OT.OPERATE Counters the threat by ensuring that the firewall shall never stop operating. OT.ALARM Contributes to counter this threat by obtaining clear warning and error messages from the firewall so that the appropriate counter- measure can be taken. OE.VERIFICATION Contributes to counter the threat by checking the bytecodes. OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 58 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.SCP.RECOVERY Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. OT.SCP.SUPPORT Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter. OE.CODE-EVIDENCE Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. 5.3.1.3 Identity Usurpation T.SID.1 Objective Rationale OT.SID Counters this threat by providing unique subject identification. OT.FIREWALL Counters the threat by providing separation of application data (like PINs). OT.GLOBAL_ARRAYS_CONFID Counters this threat by preventing the disclosure of the installa- tion parameters of an applet (like its name). These parameters are loaded into a global array that is also shared by all the ap- plications. The disclosure of those parameters could be used to impersonate the applet. OT.GLOBAL_ARRAYS_INTEG Counters this threat by preventing the disclosure of the installa- tion parameters of an applet (like its name). These parameters are loaded into a global array that is also shared by all the ap- plications. The disclosure of those parameters could be used to impersonate the applet. OT.CARD-MANAGEMENT Contributes to counter this threat by preventing usurpation of identity resulting from a malicious installation of an applet on the card. T.SID.2 Objective Rationale OT.SID Counters this threat by providing unique subject identification. OT.FIREWALL Contributes to counter this threat by providing means of separa- tion. OT.OPERATE Counters the threat by ensuring that the firewall shall never stop operating. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 59 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.CARD-MANAGEMENT Contributes to counter this threat by ensuring that installing an applet has no effect on the state of other applets and thus can’t change the TOE’s attribution of privileged roles. OT.SCP.RECOVERY Intended to support the OT.OPERATE and objectives of the TOE, thus indirectly related to the threats that these objectives con- tribute to counter. OT.SCP.SUPPORT Intended to support the OT.OPERATE and objectives of the TOE, thus indirectly related to the threats that these latter objectives contribute to counter. 5.3.1.4 Unauthorized Excecution T.EXE-CODE.1 Objective Rationale OT.FIREWALL Counters the threat by preventing the execution of non-shareable methods of a class instance by any subject apart from the class instance owner. OE.VERIFICATION Contributes to counter the threat by checking the bytecodes. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of these instruc- tions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code. T.EXE-CODE.2 Objective Rationale OE.VERIFICATION Contributes to counter the threat by checking the bytecodes. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. Especially the control flow confinement and the validity of the method references used in the bytecodes are guaranteed. T.NATIVE Objective Rationale OT.NATIVE Counters this threat by ensuring that a Java Card applet can only access native methods indirectly that is, through an API. OE.APPLET Contributes to counter this threat by ensuring that no native ap- plets shall be loaded in post-issuance. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 60 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OE.VERIFICATION Contributes to counter the threat by checking the bytecodes. Bytecode verification also prevents the program counter of an applet to jump into a piece of native code by confining the control flow to the currently executed method. 5.3.1.5 Denial of Service T.RESOURCES Objective Rationale OT.OPERATE Counters the threat by ensuring correct working order. OT.RESOURCES Counteres the threat directly by objectives on resource- management. OT.CARD-MANAGEMENT Counters this threat by controlling the consumption of resources during installation and other card management operations. OT.SCP.RECOVERY Intended to support the OT.OPERATE and OT.RESOURCES ob- jectives of the TOE, thus indirectly related to the threats that these objectives contribute to counter. OT.SCP.SUPPORT Intended to support the OT.OPERATE and OT.RESOURCES ob- jectives of the TOE, thus indirectly related to the threats that these objectives contribute to counter. 5.3.1.6 Card Management T.UNAUTHORIZED_CARD_MNGT Objective Rationale OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions such as the loading, installation, extradi- tion or deletion of applets. OT.DOMAIN-RIGHTS Contributes to counter this threat by restricting the modification of an AP security domain keyset to the AP who owns it. OT.COMM_AUTH Contributes to counter this threat by preventing unauthorized users from initiating a malicious card management operation. OT.COMM_INTEGRITY Contributes to counter this threat by protecting the integrity of the card management data while it is in transit to the TOE. OT.APPLI-AUTH Counters this threat by ensuring that the loading of a package is safe. T.COM_EXPLOIT Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 61 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.COMM_AUTH Contributes to counter this threat by preventing unauthorized users from initiating a malicious card management operation. OT.COMM_INTEGRITY Contributes to counter this threat by protecting the integrity of the card management data while it is in transit to the TOE OT.COMM_CONFIDENTIALITY Contributes to counter this threat by preventing from disclosing encrypted data transiting to the TOE T.LIFE_CYCLE Objective Rationale OT.CARD-MANAGEMENT Contributes to counter this threat by controlling the access to card management functions such as the loading, installation, extradi- tion or deletion of applets OT.DOMAIN-RIGHTS Contributes to counter this threat by restricting the use of an AP security domain keysets, and thus the management of the appli- cations related to this SD, to the AP who owns it 5.3.1.7 Services T.OBJ-DELETION Objective Rationale OT.OBJ-DELETION Counters this threat by ensuring that object deletion shall not break references to objects. 5.3.1.8 Miscellaneous T.PHYSICAL Objective Rationale OT.SCP.IC Counters phyiscal attacks. Physical protections rely on the un- derlying platform and are therefore an environmental issue. OT.RESTRICTED-MODE Contributes to counter the threat by ensuring that if the limit of the Attack Counter is reached only limited functionality is available. 5.3.1.9 Random Numbers T.RND Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 62 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.RND Counters the threat by ensuring the cryptographic quality of ran- dom number generation. For instance random numbers shall not be predictable and shall have sufficient entropy. Furthermore, the TOE ensures that no information about the produced random numbers is available to an attacker. 5.3.1.10 Config Applet T.CONFIG Objective Rationale OT.CARD-CONFIGURATION Counters the threat by ensuring that the customer can only read and write customer configuration items using the Customer Con- figuration Token and NXP can read and write configuration items using the NXP Configuration Token. If access is disabled config- uration items can not be read or written. 5.3.1.11 Secure Box T.SEC_BOX_BORDER Objective Rationale OT.SEC_BOX_FW Counters the threat by ensuring that the native code separated in the Secure Box and the data belonging to this native code is completely sealed off from the Java Card System. Due to the separation the native code in the Secure Box cannot harm the code and data outside the Secure Box 5.3.1.12 OS Update T.UNAUTH-LOAD-UPDATE-IMAGE Objective Rationale OT.SECURE_LOAD_ACODE Counters the threat directly by ensuring that only authorized (al- lowed version) images can be installed. OT.AUTH-LOAD-UPDATE-IMAGE Counters the threat directly by ensuring that only authorized (al- lowed version) images can be loaded. T.INTERRUPT-OSU Objective Rationale OT.SECURE_LOAD_ACODE Counters the threat directly by ensuring that the TOE remains in a secure state after interruption of the OS Update procedure (Load Phase). Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 63 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OT.TOE_IDENTIFICATION Counters the threat directly by ensuring that D.TOE_IDENTIFI- CATION is only updated after successful OS Update procedure. OT.SECURE_AC_ACTIVATION Counters the threat directly by ensuring that the update OS is only activated after successful (atomic) OS Update procedure. 5.3.1.13 Restricted Mode T.ATTACK-COUNTER Objective Rationale OT.ATTACK-COUNTER Counters the threat by ensuring that only the ISD can reset the Attack Counter. OT.RESTRICTED-MODE Counters the threat by ensuring that only the ISD can reset the Attack Counter. 5.3.1.14 Factory Reset T.UDW_DEL Objective Rationale OT.UDW_ATOMIC Counters the threat by ensuring that the Factory Reset process is finished when first APDU is received after TOE startup. OT.UDW_CLEAR Counter the threat by deleting all applets, packages, SDs and their associated data that are part of the Clear List. T.UDW_AUTH Objective Rationale OT.UDW_AUTH Counters the threat by ensuring that only authorized subjects can start the Factory Reset process. 5.3.2 Organisational Security Policies OSP.VERIFICATION Objective Rationale OE.VERIFICATION Enforces the OSP by guaranteeing that all the bytecodes shall be verified at least once, before the loading, before the installation or before the execution in order to ensure that each bytecode is valid at execution time. OT.CARD-MANAGEMENT Contributing to enforce the OSP by ensuring that the loading of a package into the card is safe. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 64 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OE.CODE-EVIDENCE This policy is enforced by the security objective of the environ- ment OE.CODE-EVIDENCE which ensures that evidences exist that the application code has been verified and not changed after verification. OT.APPLI-AUTH Contributing to enforce the OSP by ensuring that the loading of a package into the card is safe. OSP.PROCESS-TOE Objective Rationale OT.IDENTIFICATION Enforces this organisational security policy by ensuring that the TOE can be uniquely identified. OSP.KEY-CHANGE Objective Rationale OE.KEY-CHANGE Enforces the OSP by ensuring that the initial keys of the secu- rity domain are changed before any operation on them are per- formed. OSP.SECURITY-DOMAINS Objective Rationale OE.SECURITY-DOMAINS Enforces the OSP by dynamically create, delete, and block the security domain during usage phase in post-issuance mode. OSP.QUOTAS Objective Rationale OE.QUOTAS Enforces the OSP by applying memory quotas to security do- mains, packages and applets during their life-cycle OSP.SECURE-BOX Objective Rationale OT.SEC_BOX_FW Addresses directly this organizational security policy by ensuring that the native code and data in Secure Box is separated from the rest of the TOE. Due to this separation the native code in the Secure Box cannot harm the code and data outside the Secure Box. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 65 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5.3.3 Assumptions A.APPLET Objective Rationale OE.APPLET Upholds the assumption by ensuring that no applet loaded post- issuance shall contain native methods. A.VERIFICATION Objective Rationale OE.VERIFICATION Upholds the assumption by guaranteeing that all the bytecodes shall be verified at least once, before the loading, before the in- stallation or before the execution in order to ensure that each bytecode is valid at execution time. OE.CODE-EVIDENCE This assumption is also upheld by the security objective of the en- vironment OE.CODE-EVIDENCE which ensures that evidences exist that the application code has been verified and not changed after verification. A.USE_DIAG Objective Rationale OE.USE_DIAG Directly upholds this assumption. A.USE_KEYS Objective Rationale OE.USE_KEYS Directly upholds this assumption. A.PROCESS-SEC-IC Objective Rationale OE.PROCESS_SEC_IC Directly upholds this assumption. A.APPS-PROVIDER Objective Rationale OE.APPS-PROVIDER Directly upholds this assumption. A.VERIFICATION-AUTHORITY Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 66 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Objective Rationale OE.VERIFICATION-AUTHORITY Directly upholds this assumption. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 67 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 6 Extended Components Definition (ASE_ECD) 6.1 Definition of Family ”Generation of random numbers (FCS_RNG)” This section has been taken over from the certified (BSI-PP-0084-2014) Smartcard IC Platform Protection Profile [15]. 6.1.1 Family behavior This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes. Component leveling: Fig. 6.1: Random Number Generation FCS_RNG Generation of random numbers requires that random numbers meet a defined quality metric. Management: FCS_RNG.1 There are no management activities foreseen. Audit: FCS_RNG.1 There are no actions defined to be auditable. FCS_RNG.1 Random Number Generation. Hierarchical to: No other components. Dependencies No dependencies. FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] random number generator that implements: [assignment: list of security capabilities]. FCS_RNG.1.2 The TSF shall provide [selection: bits, octets of bits, numbers [assignment: format of the num- bers]] that meet [assignment: a defined quality metric]. Application Note: A physical random number generator (RNG) produces the random number by a noise source based on physical random processes. A non-physical true RNG uses a noise source based on non-physical random processes like human interaction (key strokes, mouse movement). A deterministic RNG uses an random seed to produce a pseudorandom output. A hybrid RNG combines the principles of physical and deterministic RNGs where a hybrid physical RNG produces at least the amount of entropy the RNG output may contain and the internal state of a hybrid deterministic RNG output contains fresh entropy but less than the output of RNG may contain. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 68 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 6.2 Definition of Family ”Audit Data Storage (FAU_SAS)” This section has been taken over from the certified (BSI-PP-0084-2014) Smartcard IC Platform Protection Profile [15]. To define the security functional requirements of the TOE an additional family (”Audit Data Storage (FAU_ SAS)”) of the Class ”Security audit (FAU)” is defined here. This family describes the functional requirements for the storage of audit data. It has a more general approach than FAU_GEN, because it does not necessarily require the data to be generated by the TOE itself and because it does not give specific details of the content of the audit records. 6.2.1 Family behavior This family defines functional requirements for the storage of audit data. Component leveling: Fig. 6.2: SAS Component FAU_SAS Requires the TOE to provide the possibility to store audit data. Management: FAU_SAS.1 There are no management activities foreseen. Audit: FAU_SAS.1 There are no actions defined to be auditable. FAU_SAS.1 Audit storage. Hierarchical to: No other components. Dependencies No dependencies. FAU_SAS.1.1 The TSF shall provide [assignment: list of subjects] with the capability to store [assignment: list of audit information] in the [assignment: type of persistent memory]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 69 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 7 Security Requirements (ASE_REQ) This section states the security functional requirements for the TOE. For readability requirements are arranged into groups taken from [9]. The permitted operations (assignment, iteration, selection and refinement) of the SFRs taken from Common Criteria [4] are printed in bold. Completed operations related to the PP are additionally marked within [ ] where assignments are additionally marked with the keyword "assignment". Group Description Core with Logical Channels (CoreG_LC) The CoreG_LC contains the requirements concerning the run- time environment of the Java Card System implementing logi- cal channels. This includes the firewall policy and the require- ments related to the Java Card API. Logical channels are a Java Card specification version 2.2 feature. This group is the union of requirements from the Core (CoreG) and the logical channels (LCG) groups defined in [18] (cf. Java Card System Protection Profile Collection [19]). Installation (InstG) The InstG contains the security requirements concerning the in- stallation of post-issuance applications. It does not address card management issues in the broad sense, but only those security aspects of the installation procedure that are related to applet execution. Applet deletion (ADELG) The ADELG contains the security requirements for erasing in- stalled applets from the card, a feature introduced in Java Card specification version 2.2. Remote Method Invocation (RMIG) The RMIG contains the security requirements for the remote method invocation feature, which provides a new protocol of com- munication between the terminal and the applets. This was intro- duced in Java Card specification version 2.2. Object deletion (ODELG) The ODELG contains the security requirements for the object deletion capability. This provides a safe memory recovering mechanism. This is a Java Card specification version 2.2 fea- ture. Secure carrier (CarG) The CarG group contains minimal requirements for secure down- loading of applications on the card. This group contains the se- curity requirements for preventing, in those configurations that do not support on-card static or dynamic bytecode verification, the installation of a package that has not been bytecode verified, or that has been modified after bytecode verification. External Memory (EMG) The EMG group contains security requirements for the manage- ment of external memory. Tab. 7.1: Requirement Groups Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 70 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Subjects are active components of the TOE that (essentially) act on the behalf of users. The users of the TOE include people or institutions (like the applet developer, the card issuer, the verification authority), hardware (like the CAD where the card is inserted or the PCD) and software components (like the application packages installed on the card). Some of the users may just be aliases for other users. For instance, the verification authority in charge of the bytecode verification of the applications may be just an alias for the card issuer. Subjects (prefixed with an "S") are described in the following table: Subject Description S.ADEL The applet deletion manager which also acts on behalf of the card issuer. It may be an applet ([34], §11), but its role asks anyway for a specific treatment from the security viewpoint. This subject is unique and is involved in the ADEL security policy. S.APPLET Any applet instance. S.Application Applet loaded pre-issuance onto TOE that triggeres the Factory Reset process and modifies the Clear List. S.CAD The CAD represents the actor that requests services by issuing commands to the card. It also plays the role of the off-card entity that communicates with the S.INSTALLER. S.FAR Applet loaded pre-issuance onto TOE that triggeres the Factory Reset process and modifies the Clear List. S.INSTALLER The installer is the on-card entity which acts on behalf of the card issuer. This subject is involved in the loading of packages and installation of applets. S.JCRE The runtime environment under which Java programs in a smart card are executed. S.JCVM The bytecode interpreter that enforces the firewall at runtime. S.LOCAL Operand stack of a JCVM frame, or local variable of a JCVM frame containing an object or an array of references. S.SD A GlobalPlatform Security Domain representing on the card a off- card entity. This entity can be the Issuer, an Application Provider, the Controlling Authority or the Verification Authority. S.MEMBER Any object’s field, static field or array position. S.SBNativeCode The third party native code executed via the Secure Box mecha- nism. S.PACKAGE A package is a namespace within the Java programming lan- guage that may contain classes and interfaces, and in the context of Java Card technology, it defines either a user library, or one or several applets. S.OSU OSU provides secure functionality to update the TOE operat- ing system with an image created by a trusted off-card entity (S.UpdateImageCreator) Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 71 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Subject Description S.UpdateImageCreator The off-card Update Image Creator ensures that the image is signed and transferred encrypted to the device and is not dis- closed during the creation and transfer. The keys used for signing and encrypting the image are kept confidential. S.Customer The subject that has the Customer Configuration Token. S.NXP The subject that has the NXP Configuration Token. S.ConfigurationMechanism On card entity which can read and write configuration items. Tab. 7.2: Subject Descriptions Objects (prefixed with an "O") are described in the following table: Objects Description O.APPLET Any installed applet, its code and data. O.CODE_PKG The code of a package, including all linking information. On the Java Card platform, a package is the installation unit. O.SB_Content The code and data elements of the native code library residing in the Secure Box. O.NON_SB_Content Any code and data elements not assigned to the native code li- brary residing in the Secure Box. O.SB_SFR The pool of Special Function Registers O.JAVAOBJECT Java class instance or array. It should be noticed that KEYS, PIN, arrays and applet instances are specific objects in the Java programming language. Tab. 7.3: Object Groups Information (prefixed with an "I") is described in the following table: Information Description I.DATA JCVM Reference Data: objectref addresses of APDU buffer, JCRE-owned instances of APDU class and byte array for install method. Tab. 7.4: Information Groups Security attributes linked to these subjects, objects and information are described in the following table: Security attributes Description Active Applets The set of the active applets’ AIDs. An active applet is an applet that is selected on at least one of the logical channels. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 72 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Security attributes Description Applet Selection Status ”Selected” or ”Deselected”. Applet’s Version Number The version number of an applet (package) indicated in the ex- port file. Attack Counter Attack Counter Context Package AID or ”Java Card RE ”. Currently Active Context Package AID or ”Java Card RE”. Current Sequence Number The current number of a valid OS installed on the TOE or current number of a OS update step during update process. Dependent Package AID Allows the retrieval of the Package AID and applet’s version num- ber. Final Sequence Number The sequence number which is reached after completing the up- date process. This is uniquely linked to the JCOP version of the final TOE. Image Type Type of D.UPDATE_IMAGE. Can be either Upgrade, Self Update or Downgrade. LC Selection Status Multiselectable, Non-multiselectable or ”None”. LifeTime CLEAR_ON_DESELECT or PERSISTENT. 1 . Owner The Owner of an object is either the applet instance that cre- ated the object or the package (library) where it has been de- fined (these latter objects can only be arrays that initialize static fields of the package). The owner of a remote object is the applet instance that created the object. Package AID The AID of each package indicated in the export file. Reference Sequence Num- ber Is the sequence number which the TOE has before the update process is started. This is uniquely linked to the JCOP version of the initial TOE. Registered Applets The set of AID of the applet instances registered on the card. Remote An object is Remote if it is an instance of a class that directly or indirectly implements the interface java.rmi.Remote. It applies only if the TOE provides JCRMI functionality. Resident Packages The set of AIDs of the packages already loaded on the card. Selected Applet Context Package AID or ”None”. Sharing Standards, SIO, Java Card RE Entry Point or global array. Static References Static fields of a package may contain references to objects. The Static References attribute records those references. Address Space Accessible memory portion. Verification Key Key to verify integrity of D.UPDATE_IMAGE. 1Transient objects of type CLEAR_ON_RESET behave like persistent objects in that they can be accessed only when the Currently Active Context is the object’s context. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 73 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Security attributes Description Decryption Key Key for decrypting D.UPDATE_IMAGE. Customer Configuration To- ken generation key The customer key to generate tokens for product configuration. NXP Configuration Token generation key The NXP key to generate tokens for product configuration. NXP Configuration Access The NXP Configuration Access can either be enabled or dis- abled. Customer Configuration Ac- cess The Customer Configuration Access can either be enabled or dis- abled. access privilege For each configuration item the access privilege attribute defines who (Customer and/or NXP) is allowed to read/write the item. Key Set Key Set for Secure Channel. Received Sequence Number Sequence number of the uploaded D.UPDATE_IMAGE. Security Level Secure Communication Security Level defined in Section 10.6 of [22]. Secure Channel Protocol Secure Channel Protocol version used. Session Key Secure Channel’s session key. Sequence Counter Secure Channel Session’s Sequence Counter. ICV Secure Channel Session’s ICV. CPU Mode The execution mode of the CPU. Can be either Application Priv- ileged Mode, Application Unprivileged Mode and Shared Mode. The modes Service Privileged and Service Unprivileged are re- served to the Security Software execution. MMU Segment Table Defines the memory areas which can be accessed for read- /write/execute. Special Function Registers Special Function Registers allow to set operation modes of func- tional blocks of the hardware. Card Life Cycle defined in Section 5.1.1 of [22]. Privileges defined in Section 6.6.1 of [22]. Life-cycle Status defined in Section 5.3.2 of [22]. Clear List The Factory Reset process deletes all applets, packages, SDs and their related data that are in the Clear List. Trigger Factory Reset Al- lowed AID Allows a S.Application to trigger the Factory Reset process if the AID is allowed to do so. The AIDs that are allowed to are defined pre issuance. Tab. 7.5: Security attribute description Operations (prefixed with "OP") are described in the following table. Each operation has parameters given be- tween brackets, among which there is the "accessed object", the first one, when applicable. Parameters may be Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 74 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public seen as security attributes that are under the control of the subject performing the operation. Operations Description OP.ARRAY_AC- CESS(O.JAVAOBJECT, field) Read/Write an array component. OP.CREATE(Sharing, Life- Time)(*) 2 Creation of an object (new or makeTransient call). OP.DELETE_AP- PLET(O.APPLET,...) Delete an installed applet and its objects, either logically or phys- ically. OP.DELETE_ PCKG(O.Code_PKG,...) Delete a package, either logically or physically. OP.DELETE_PCKG_AP- PLET(O.Code_PKG,...) Delete a package and its installed applets, either logically or physically. OP.INSTANCE_ FIELD(O.JAVAOBJECT, field) Read/Write a field of an instance of a class in the Java program- ming language. OP.INVK_VIR- TUAL(O.JAVAOBJECT, method, arg1,...) Invoke a virtual method (either on a class instance or an array object). OP.INVK_INTER- FACE(O.JAVAOBJECT, method, arg1,...) Invoke an interface method. OP.JAVA(...) Any access in the sense of [34], §6.2.8. It stands for one of the operations OP.ARRAY_ACCESS, OP.INSTANCE_ FIELD, OP.INVK_VIRTUAL, OP.INVK_INTERFACE, OP.THROW, OP.TYPE_ACCESS. OP.PUT(S1,S2,I) Transfer a piece of information I from S1 to S2. OP.THROW(O.JAVAOBJECT) Throwing of an object (athrow, see [34], §6.2.8.7). OP.TYPE_AC- CESS(O.JAVAOBJECT, class) Invoke checkcast or instanceof on an object in order to access to classes (standard or shareable interfaces objects). OP.SB_ACCESS Any read, write or execution access to a memory area. OP.SB_ACCESS_SFR Any read/write access to a Special Function Register. OP.READ_CONFIG_ITEM Reading a Config Item from the configuration area. OP.MODIFY_CONFIG_ ITEM Writing of a Config Item. OP.USE_CONFIG_ITEM Operational usage of Config Items by subjects inside the TOE. OP.TRIGGER_UPDATE APDU Command that initializes the OS Update procedure. 2For this operation, there is no accessed object. This rule enforces that shareable transient objects are not allowed. For instance, during the creation of an object, the JavaCardClass attribute’s value is chosen by the creator. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 75 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Operations Description Tab. 7.6: Operation Description 7.1 Security Functional Requirements 7.1.1 COREG_LC Security Functional Requirements The list of SFRs of this category are taken from [9]. 7.1.1.1 Firewall Policy FDP_ACC.2[FIREWALL] Complete access control (FIREWALL) Hierarchical-To FDP_ACC.1 Subset access control Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.2.1[FIREWALL] The TSF shall enforce the [assignment: FIREWALL access control SFP] on [assign- ment: S.PACKAGE, S.JCRE, S.JCVM, O.JAVAOBJECT] and all operations among sub- jects and objects covered by the SFP. Refinement: The operations involved in the policy are: • OP.CREATE(Sharing, LifeTime)(*), • OP.INVK_INTERFACE(O.JAVAOBJECT, method, arg1, ...), • OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...), • OP.JAVA(...), • OP.THROW(O.JAVAOBJECT), • OP.TYPE_ACCESS(O.JAVAOBJECT, class) FDP_ACC.2.2[FIREWALL] The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. AppNote It should be noticed that accessing array’s components of a static array, and more gener- ally fields and methods of static objects, is an access to the corresponding O.JAVAOBJECT. FDP_ACF.1[FIREWALL] Security attribute based access control (FIREWALL) Hierarchical-To No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 76 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_ACF.1.1[FIREWALL] The TSF shall enforce the [assignment: FIREWALL access control SFP] to objects based on the following [assignment: Subject/Object Security attributes S.PACKAGE LC Selection Status S.JCVM Active Applets, Currently Active Context S.JCRE Selected Applet Context O.JAVAOBJECT Sharing, Context, LifeTime ] FDP_ACF.1.2[FIREWALL] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: • R.JAVA.1 ([34], §6.2.8): S.PACKAGE may freely perform OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...), OP.INVK_ INTERFACE(O.JAVAOBJECT, method, arg1, ...), OP.THROW(O.JAVAOBJECT) or OP.TYPE_ACCESS(O.JAVAOBJECT, class) upon any O.JAVAOBJECT whose Shar- ing attribute has value ”JCRE entry point” or ”global array”. • R.JAVA.2 ([34], §6.2.8): S.PACKAGE may freely perform OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...), OP.INVK_ INTERFACE(O.JAVAOBJECT, method, arg1, ...) or OP.THROW(O.JAVAOBJECT) upon any O.JAVAOBJECT whose Sharing attribute has value ”Standard” and whose LifeTime attribute has value ”PERSISTENT” only if O.JAVAOBJECT’s Context at- tribute has the same value as the active context. • R.JAVA.3 ([34], §6.2.8.10): S.PACKAGE may perform OP.TYPE_ACCESS(O.JAVAOBJECT, class) upon an O.JAVAOBJECT whose Sharing attribute has value ”SIO” only if O.JAVAOBJECT is being cast into (checkcast) or is being verified as being an in- stance of (instanceof) an interface that extends the Shareable interface. • R.JAVA.4 ([34], §6.2.8.6): S.PACKAGE may perform OP.INVK_INTERFACE(O.JAVAOBJECT, method, arg1, ...) upon an O.JAVAOBJECT whose Sharing attribute has the value ”SIO”, and whose Context attribute has the value ”Package AID”, only if the invoked interface method extends the Shareable interface and one of the following condi- tions applies: a) The value of the attribute LC Selection Status of the package whose AID is ”Package AID” is ”Multiselectable”, b) The value of the attribute LC Selection Status of the package whose AID is ”Package AID” is ”Non-multiselectable”, and either ”Package AID” is the value of the currently selected applet or otherwise ”Package AID” does not occur in the attribute Active Applets. • R.JAVA.5: S.PACKAGE may perform OP.CREATE(Sharing, LifeTime)(*) only if the value of the Sharing parameter is ”Standard”. ] Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 77 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_ACF.1.3[FIREWALL] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: • The subject S.JCRE can freely perform OP.JAVA(...) and OP.CREATE(Sharing, Life- Time)(*), with the exception given in FDP_ACF.1.4[FIREWALL], provided it is the Currently Active Context. • The only means that the subject S.JCVM shall provide for an application to execute native code is the invocation of a Java Card API method (through OP.INVK_INTER- FACE(O.JAVAOBJECT, method, arg1, ...) or OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...)). ] FDP_ACF.1.4[FIREWALL] The TSF shall explicitly deny access of subjects to objects based on the following addi- tional rules: [assignment: • Any subject with OP.JAVA(...) upon an O.JAVAOBJECT whose LifeTime attribute has value ”CLEAR_ON_DESELECT” if O.JAVAOBJECT’s Context attribute is not the same as the Selected Applet Context. • Any subject attempting to create an object by the means of OP.CREATE(Sharing, LifeTime)(*) and a ”CLEAR_ON_DESELECT” LifeTime parameter if the active con- text is not the same as the Selected Applet Context. ] AppNote FDP_ACF.1.4[FIREWALL]: • The deletion of applets may render some O.JAVAOBJECT inaccessible, and the Java Card RE may be in charge of this aspect. This can be done, for instance, by ensuring that references to objects belonging to a deleted application are consid- ered as a null reference. In the case of an array type, fields are components of the array ([17], §2.14, §2.7.7), as well as the length; the only methods of an array object are those inherited from the Object class. The Sharing attribute defines four categories of objects: • Standard ones, whose both fields and methods are under the firewall policy, • Shareable interface Objects (SIO), which provide a secure mechanism for inter- applet communication, • JCRE entry points (Temporary or Permanent), who have freely accessible methods but protected fields, • Global arrays, having both unprotected fields (including components; refer to JavaC- ardClass discussion above) and methods. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 78 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public When a new object is created, it is associated with the Currently Active Context. But the object is owned by the applet instance within the Currently Active Context when the object is instantiated ([34], §6.1.3). An object is owned by an applet instance, by the JCRE or by the package library where it has been defined (these latter objects can only be arrays that initialize static fields of packages). ([34], Glossary) Selected Applet Context. The Java Card RE keeps track of the currently selected Java Card applet. Upon receiving a SELECT command with this applet’s AID, the Java Card RE makes this applet the Selected Applet Context. The Java Card RE sends all APDU commands to the Selected Applet Context. While the expression ”Selected Applet Context” refers to a specific installed applet, the relevant aspect to the policy is the context (package AID) of the selected applet. In this policy, the ”Selected Applet Context” is the AID of the selected package. ([34], §6.1.2.1) At any point in time, there is only one active context within the Java Card VM (this is called the Currently Active Context). It should be noticed that the invocation of static methods (or access to a static field) is not considered by this policy, as there are no firewall rules. They have no effect on the active context as well and the ”acting package” is not the one to which the static method belongs to in this case. It should be noticed that the Java Card platform, version 2.2.x and version 3 Classic Edition, introduces the possibility for an applet instance to be selected on multiple logical channels at the same time, or accepting other applets belonging to the same package being selected simultaneously. These applets are referred to as multiselectable applets. Applets that belong to a same package are either all multiselectable or not ([35], §2.2.5). Therefore, the selection mode can be regarded as an attribute of packages. No selection mode is defined for a library package. An applet instance will be considered an active applet instance if it is currently selected in at least one logical channel. An applet instance is the currently selected applet instance only if it is processing the current command. There can only be one currently selected applet instance at a given time. ([34], §4). FDP_IFC.1[JCVM] Subset information flow control (JCVM) Hierarchical-To No other components. Dependencies FDP_IFF.1 Simple security attributes FDP_IFC.1.1[JCVM] The TSF shall enforce the [assignment: JCVM information flow control SFP] on [as- signment: S.JCVM, S.LOCAL, S.MEMBER, I.DATA and OP.PUT(S1,S2,I)]. AppNote It should be noticed that references of temporary Java Card RE entry points, which cannot be stored in class variables, instance variables or array components, are transferred from Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 79 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public the internal memory of the Java Card RE (TSF data) to some stack through specific APIs (Java Card RE owned exceptions) or Java Card RE invoked methods (such as the process(APDU apdu)); these are causes of OP.PUT(S1,S2,I) operations as well. FDP_IFF.1[JCVM] Simple security attributes (JCVM) Hierarchical-To No other components. Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFF.1.1[JCVM] The TSF shall enforce the [assignment: JCVM information flow control SFP] based on the following types of subject and information security attributes [assignment: : Subject/Object Security attributes S.JCVM Currently Active Context ] FDP_IFF.1.2[JCVM] The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: • An operation OP.PUT(S1, S.MEMBER, I.DATA) is allowed if and only if the Cur- rently Active Context is ”Java Card RE”. • other OP.PUT operations are allowed regardless of the Currently Active Con- text’s value. ] FDP_IFF.1.3[JCVM] The TSF shall enforce [assignment: no additional information flow control SFP rules]. FDP_IFF.1.4[JCVM] The TSF shall explicitly authorise an information flow based on the following rules: [as- signment: none]. FDP_IFF.1.5[JCVM] The TSF shall explicitly deny an information flow based on the following rules: [assign- ment: none]. AppNote The storage of temporary Java Card RE-owned objects references is runtime-enforced ([34], §6.2.8.1-3). It should be noticed that this policy essentially applies to the execution of bytecode. Na- tive methods, the Java Card RE itself and possibly some API methods can be granted specific rights or limitations through the FDP_IFF.1.3[JCVM] to FDP_IFF.1.5[JCVM] ele- ments. The way the Java Card virtual machine manages the transfer of values on the stack and local variables (returned values, uncaught exceptions) from and to internal reg- isters is implementation dependent. For instance, a returned reference, depending on the implementation of the stack frame, may transit through an internal register prior to being pushed on the stack of the invoker. The returned bytecode would cause more than one OP.PUT operation under this scheme. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 80 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_RIP.1[OBJECTS] Subset residual information protection (OBJECTS) Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[OBJECTS] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: allocation of the resource to] the following objects: [as- signment: class instances and arrays]. AppNote The semantics of the Java programming language requires for any object field and array position to be initialized with default values when the resource is allocated [17], §2.5.1. FMT_MSA.1[JCRE] Management of security attributes (JCRE) 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[JCRE] The TSF shall enforce the [assignment: FIREWALL access control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: Selected Applet Context] to [assignment: S.JCRE]. AppNote The modification of the Selected Applet Context should be performed in accordance with the rules given in [34], §4 and [35], §3.4. FMT_MSA.1[JCVM] Management of security attributes (JCVM) 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[JCVM] The TSF shall enforce the [assignment: FIREWALL access control SFP and the JCVM information flow control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: Currently Active Context and Active Applets] to [as- signment: S.JCVM]. AppNote The modification of the Currently Active Context should be performed in accordance with the rules given in [34], §4 and [35], §3.4. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 81 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FMT_MSA.2[FIREWALL-JCVM] Secure security attributes (FIREWALL-JCVM) 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.2.1[FIREWALL-JCVM] The TSF shall ensure that only secure values are accepted for [assignment: all the security attributes of subjects and objects defined in the FIREWALL access control SFP and the JCVM information flow control SFP]. AppNote The following rules are given as examples only. For instance, the last two rules are motivated by the fact that the Java Card API defines only transient arrays factory methods. Future versions may allow the creation of transient objects belonging to arbitrary classes; such evolution will naturally change the range of ”secure values” for this component. • The Context attribute of an O.JAVAOBJECT must correspond to that of an installed applet or be ”Java Card RE”. • An O.JAVAOBJECT whose Sharing attribute is a Java Card RE entry point or a global array necessarily has ”Java Card RE” as the value for its Context security attribute. • An O.JAVAOBJECT whose Sharing attribute value is a global array necessarily has ”array of primitive type” as a JavaCardClass security attribute’s value. • Any O.JAVAOBJECT whose Sharing attribute value is not ”Standard” has a PERSISTENT- LifeTime attribute’s value. • Any O.JAVAOBJECT whose LifeTime attribute value is not PERSISTENT has an array type as JavaCardClass attribute’s value. FMT_MSA.3[FIREWALL] Static attribute initialisation (FIREWALL) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[FIREWALL] The TSF shall enforce the [assignment: FIREWALL access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[FIREWALLEditoriallyRefined] The TSF shall not allow [assignment: any role] to specify alternative initial values to override the default values when an object or information is created. AppNote FMT_MSA.3.1[FIREWALL] • Objects’ security attributes of the access control policy are created and initialized at the creation of the object or the subject. Afterwards, these attributes are no Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 82 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public longer mutable (FMT_MSA.1[JCRE]). At the creation of an object (OP.CREATE), the newly created object, assuming that the FIREWALL access control SFP permits the operation, gets its Lifetime and Sharing attributes from the parameters of the operation; on the contrary, its Context attribute has a default value, which is its creator’s Context attribute and AID respectively ([34], §6.1.3). There is one default value for the Selected Applet Context that is the default applet identifier’s Context, and one default value for the Currently Active Context that is ”Java Card RE”. • The knowledge of which reference corresponds to a temporary entry point object or a global array and which does not is solely available to the Java Card RE (and the Java Card virtual machine). FMT_MSA.3.2[FIREWALL Editorially Refined] • The intent is that none of the identified roles has privileges with regard to the default values of the security attributes. It should be noticed that creation of objects is an operation controlled by the FIREWALL access control SFP. The operation shall fail anyway if the created object would have had security attributes whose value violates FMT_MSA.2.1[FIREWALL-JCVM]. FMT_MSA.3[JCVM] Static attribute initialisation (JCVM) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[JCVM] The TSF shall enforce the [assignment: JCVM information flow control SFP] to pro- vide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[JCVM-EditoriallyRefined] The TSF shall not allow [assignment: any role] to specify alternative initial values to override the default values when an object or information is created. FMT_SMF.1 Specification of Management Functions Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [assign- ment: • modify the Currently Active Context, the Selected Applet Context and the Ac- tive Applets Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 83 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public ] FMT_SMR.1 Security roles Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1 The TSF shall maintain the roles: [assignment: • Java Card RE (JCRE), • Java Card VM (JCVM). ]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 7.1.1.2 Application Programming Interface The following SFRs are related to the Java Card API. The whole set of cryptographic algorithms is generally not implemented because of limited memory resources and/or limitations due to exportation. Therefore, the following requirements only apply to the implemented subset. It should be noticed that the execution of the additional native code is not within the TSF. Nevertheless, access to API native methods from the Java Card System is controlled by TSF because there is no difference between native and interpreted methods in their interface or invocation mechanism. FCS_CKM.1 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 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: JCOP RNG] and specified cryptographic key sizes [assignment: DES: LENGTH_DES3_2KEY, LENGTH_DES3_3KEY bit, RSA- CRT and RSA: LENGTH_RSA_2048, LENGTH_RSA_4096 bit and from 2016 bit to 4096 bit in 32 bit steps ECC: LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_ EC_FP_384, LENGTH_EC_FP_521 and from 224 bit to 528 bit in 1 bit steps AES: LENGTH_AES_128, LENGTH_AES_192, LENGTH_AES_256 bit] that meet the follow- ing: [assignment: [2]]. AppNote • The keys can be generated and diversified in accordance with [33] specification in class KeyBuilder. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 84 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • This component shall be instantiated according to the version of the Java Card API applying to the security target and the implemented algorithms ([33]). FCS_CKM.2 Cryptographic key distribution Hierarchical-To No other components. Dependencies [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [assignment: methods: set keys and components of DES, AES, RSA, RSA-CRT, ECC and secure messaging] that meets the following: [assign- ment: [33], [10]]. AppNote • The keys can be accessed as specified in [33] Key class and [10] for proprietary classes. • This component shall be instantiated according to the version of the Java Card API applying to the security target and the implemented algorithms [33] and [10] for proprietary classes. FCS_CKM.3 Cryptographic key access Hierarchical-To No other components. Dependencies [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.3.1 The TSF shall perform [assignment: management of DES, AES, RSA, RSA-CRT, ECC] in accordance with a specified cryptographic key access method [assignment: methods/commands defined in packages javacard.security of [33] and [10] for pro- prietary classes] that meets the following: [assignment: [33], [10]]. AppNote • The keys can be accessed as specified in [33] Key class and [10] for proprietary classes. • This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemented algorithms ([33]) and [10] for proprietary classes. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 85 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FCS_CKM.4 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 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: physically overwriting the keys in a random- ized manner] that meets the following: [assignment: none]. AppNote • The keys are reset as specified in [33] Key class, with the method clearKey(). Any access to a cleared key for ciphering or signing shall throw an exception. • This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemented algorithms ([33]). FCS_COP.1 Cryptographic operation Hierarchical-To No other components. Dependencies [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction. FCS_COP.1.1[GCM] The TSF shall perform [assignment: decryption and encryption] in accordance with a specified cryptographic algorithm [assignment: AES in GCM mode] and cryptographic key size [assignment: 128 bits] that meets the following: [assignment: FIPS 197 [8], NIST Special Publication 800-38D Recommendation for BlockCipher [12]]. FCS_COP.1.1[TripleDES] The TSF shall perform [assignment: data encryption and decryption] in accordance with a specified cryptographic algorithm [assignment: ALG_DES_CBC_ISO9797_M1, ALG_DES_CBC_ISO9797_M2, ALG_DES_CBC_NOPAD, ALG_DES_ECB_ISO9797_ M1, ALG_DES_ECB_ISO9797_M2, ALG_DES_ECB_NOPAD, ] and cryptographic key sizes [assignment: LENGTH_DES3_2KEY, LENGTH_DES3_3KEY bit] that meet the following: [assignment: for ALG_DES_ECB_ISO9797_M2 see Java Card API Spec [33], for the rest see both [33] and JCOPX API [10] ]. FCS_COP.1.1[AES] The TSF shall perform [assignment: data encryption and decryption] in accordance with a specified cryptographic algorithm [assignment: ALG_AES_BLOCK_128_CBC_ NOPAD, ALG_AES_BLOCK_128_CBC_NOPAD_STANDARD, ALG_AES_BLOCK_128_ ECB_NOPAD, ALG_AES_CBC_ISO9797_M1, ALG_AES_CBC_ISO9797_M2, ALG_ AES_CBC_ISO9797_M2_STANDARD, ALG_AES_ECB_ISO9797_M1, ALG_AES_ECB_ ISO9797_M2, ] and cryptographic key sizes [assignment: LENGTH_AES_128, LENGTH_ AES_192 and LENGTH_AES_256 bit] that meet the following: [assignment: for ALG_ AES_BLOCK_128_CBC_NOPAD_STANDARD,ALG_AES_CBC_ISO9797_M2_STANDARD see API specified in JCOPX [10], for the rest see Java Card API Spec [33]]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 86 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FCS_COP.1.1[RSACipher] The TSF shall perform [assignment: data encryption and decryption] in accordance with a specified cryptographic algorithm [assignment: ALG_RSA_NOPAD, ALG_RSA_ PKCS1, ALG_RSA_PKCS1_OAEP] and cryptographic key sizes [assignment: LENGTH_ RSA_2048, LENGTH_RSA_4096 and from 2016 bit to 4096 bit in 32 bit steps] that meet the following: [assignment: Java Card API Spec [33] and for the 32 bit step range see API specified in JCOPX [10]]. FCS_COP.1.1[ECDH_P1363] The TSF shall perform [assignment: Diffie-Hellman Key Agreement] in accordance with a specified cryptographic algorithm [assignment: ALG_EC_SVDP_DH, ALG_EC_ SVDP_DH_KDF, ALG_EC_SVDP_DH_PLAIN, ALG_EC_SVDP_DHC, ALG_EC_SVDP_ DHC_KDF, ALG_EC_SVDP_DHC_PLAIN, ALG_EC_SVDP_DH_PLAIN_XY] and cryp- tographic key sizes [assignment: LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_ EC_FP_384, LENGTH_EC_FP_521 and from 224 bit to 528 bit in 1 bit steps] that meet the following: [assignment: Java Card API Spec [33] and for ALG_EC_SVDP_ DH_PLAIN_XY or 1 bit step range key size see API specified in JCOPX [10]]. FCS_COP.1.1[DESMAC] The TSF shall perform [assignment: MAC generation and verification] in accordance with a specified cryptographic algorithm [assignment: Triple-DES in outer CBC for Mode: ALG_DES_MAC4_ISO9797_1_M2_ALG3, ALG_DES_MAC4_ISO9797_M2, ALG_ DES_MAC8_ISO9797_1_M1_ALG3, ALG_DES_MAC8_ISO9797_1_M2_ALG3, ALG_ DES_MAC8_ISO9797_M2, ALG_DES_MAC8_NOPAD, ALG_DES_MAC128_ISO9797_ 1_M2_ALG3 ] and cryptographic key sizes [assignment: LENGTH_DES3_2KEY, LENGTH_ DES3_3KEY] that meet the following: [assignment: Java Card API Spec [33]and JCOPX API[10] ]. FCS_COP.1.1[AESMAC] The TSF shall perform [assignment: 16 byte MAC generation and verification] in accordance with a specified cryptographic algorithm [assignment: AES in CBC Mode ALG_AES_MAC_128_NOPAD] and cryptographic key sizes [assignment: LENGTH_ AES_128, LENGTH_AES_192 and LENGTH_AES_256 bit] that meet the following: [assignment: Java Card API Spec [33]]. FCS_COP.1.1[RSASignaturePKCS1] The TSF shall perform [assignment: digital signature generation and verifica- tion] in accordance with a specified cryptographic algorithm [assignment:ALG_RSA_ SHA_224_PKCS1, ALG_RSA_SHA_224_PKCS1_PSS, ALG_RSA_SHA_256_PKCS1, ALG_RSA_SHA_256_PKCS1_PSS, ALG_RSA_SHA_384_PKCS1, ALG_RSA_SHA_ 384_PKCS1_PSS, ALG_RSA_SHA_512_PKCS1, ALG_RSA_SHA_512_PKCS1_PSS or SIG_CIPHER_RSA in combination with MessageDigest.ALG_SHA_256, MessageDi- gest.ALG_SHA_384, MessageDigest.ALG_SHA_512 and in combination with Ci- pher.PAD_PKCS1_OAEP] and cryptographic key sizes [assignment: LENGTH_RSA_ 2048, LENGTH_RSA_4096 and from 2016 bit to 4096 bit in 32 bit steps] that meet the following: [assignment: Java Card API Spec [33] and for the 32 bit step range see API specified in JCOPX [10]]. FCS_COP.1.1[ECSignature] The TSF shall perform [assignment: digital signature generation and verification] in accordance with a specified cryptographic algorithm [assignment: ALG_ECDSA_SHA_ 224, ALG_ECDSA_SHA_256, ALG_ECDSA_SHA_384, ALG_ECDSA_SHA_512 or SIG_ CIPHER_ECDSA in combination with MessageDigest.ALG_SHA_256 or MessageDi- Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 87 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public gest.ALG_SHA_384 or MessageDigest.ALG_SHA_512] and cryptographic key sizes [assignment: LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_EC_FP_384, LENGTH_EC_FP_521 and from 224 bit to 528 bit in 1 bit steps] that meet the follow- ing: [assignment: Java Card API Spec [33] and for 1 bit step range key size see API specified in JCOPX [10]]. FCS_COP.1.1[SHA] The TSF shall perform [assignment: secure hash computation] in accordance with a specified cryptographic algorithm [assignment: ALG_SHA3 , ALG_SHA_224, ALG_ SHA_256, ALG_SHA_384, ALG_SHA_512] and cryptographic key sizes [assignment: LENGTH_SHA, LENGTH_SHA_224, LENGTH_SHA_256, LENGTH_SHA_384, LENGTH_ SHA_512] that meet the following: [assignment: Java Card API Spec [33] and JCOPX API specified in [10] ] FCS_COP.1.1[AES_CMAC] The TSF shall perform [assignment: CMAC generation and verification] in accor- dance with a specified cryptographic algorithm [assignment: ALG_AES_CMAC16, SIG_ CIPHER_AES_CMAC16, ALG_AES_CMAC16_STANDARD, SIG_CIPHER_AES_MAC128] and cryptographic key sizes [assignment: LENGTH_AES_128, LENGTH_AES_192 and LENGTH_AES_256 bit] that meet the following: [assignment: see Java Card API Spec [33] for SIG_CIPHER_AES_MAC128 and for the other modes see the JCOPX API specified in [10] ]. FCS_COP.1.1[HMAC] The TSF shall perform [assignment: HMAC generation and verification] in accor- dance with a specified cryptographic algorithm [assignment: ALG_HMAC_SHA_256, ALG_HMAC_SHA_384, ALG_HMAC_SHA_512] and cryptographic key sizes [assign- ment: LENGTH_SHA_256, LENGTH_SHA_384 and LENGTH_SHA_512 bit] that meet the following: [assignment: see Java Card specification [33] and JCOPX API speci- fied in [10]]. FCS_COP.1.1[TDES_CMAC] The TSF shall perform [assignment: message authentication and verification] in ac- cordance with a specified cryptographic algorithm [assignment: ALG_DES_CMAC8, SIG_CIPHER_DES_CMAC8] and cryptographic key sizes [assignment: LENGTH_DES3_ 2KEY and LENGTH_DES3_3KEY bit ] that meet the following: [assignment: see API specified in JCOPX [10]]. FCS_COP.1.1[DAP] The TSF shall perform [assignment: verification of the DAP signature attached to Executable Load Applications] in accordance with a specified cryptographic algorithm [assignment: ALG_RSA_SHA_PKCS1, ALG_ECDSA_SHA_256] and cryptographic key sizes [assignment: LENGTH_RSA_1024, LENGTH_EC_FP_256] that meet the fol- lowing: [assignment: GP Spec [31]]. FDP_RIP.1[ABORT] Subset residual information protection (ABORT) 3Due to mathematical weakness only resistant against AVA_VAN.5 for temporary data (e.g. as used for generating session keys), but not if repeatedly applied to the same input data. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 88 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[ABORT] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: deallocation of the resource from] the following objects: [assignment: any reference to an object instance created during an aborted trans- action]. AppNote The events that provoke the de-allocation of a transient object are described in [34], §5.1. FDP_RIP.1[APDU] Subset residual information protection (APDU) Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[APDU] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: allocation of the resource to] the following objects: [as- signment: the APDU buffer]. AppNote The allocation of a resource to the APDU buffer is typically performed as the result of a call to the process() method of an applet. FDP_RIP.1[bArray] Subset residual information protection (bArray) Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[bArray] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: deallocation of the resource from] the following objects: [assignment: the bArray object]. AppNote A resource is allocated to the bArray object when a call to an applet’s install() method is performed. There is no conflict with FDP_ROL.1 here because of the bounds on the roll- back mechanism (FDP_ROL.1.2[FIREWALL]): the scope of the rollback does not extend outside the execution of the install() method, and the de-allocation occurs precisely right after the return of it. FDP_RIP.1[KEYS] Subset residual information protection (KEYS) Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 89 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[KEYS] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: deallocation of the resource from] the following objects: [assignment: the cryptographic buffer (D.CRYPTO)]. AppNote • The javacard.security and javacardx.crypto packages do provide secure interfaces to the cryptographic buffer in a transparent way. See javacard.security.KeyBuilder and Key interface of [33]. FDP_RIP.1[TRANSIENT] Subset residual information protection (TRANSIENT) Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[TRANSIENT] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: deallocation of the resource from] the following objects: [assignment: any transient object]. AppNote • The events that provoke the de-allocation of any transient object are described in [34], §5.1. • The clearing of CLEAR_ON_DESELECT objects is not necessarily performed when the owner of the objects is deselected. In the presence of multiselectable applet instances, CLEAR_ON_DESELECT memory segments may be attached to applets that are active in different logical channels. Multiselectable applet instances within a same package must share the transient memory segment if they are concurrently active ([34], §4.2.) FDP_ROL.1[FIREWALL] Basic rollback (FIREWALL) Hierarchical-To No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_ROL.1.1[FIREWALL] The TSF shall enforce [assignment: the FIREWALL access control SFP and the JCVM information flow control SFP] to permit the rollback of the [assignment: op- erations OP.JAVA(...) and OP.CREATE(Sharing, LifeTime)(*)] on the [assignment: object O.JAVAOBJECT. FDP_ROL.1.2[FIREWALL] The TSF shall permit operations to be rolled back within the [assignment: scope of a select(), deselect(), process(), install() or uninstall() call, notwithstanding the re- strictions given in [34], §7.7, within the bounds of the Commit Capacity ([34], §7.8), and those described in [33]]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 90 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public AppNote Transactions are a service offered by the APIs to applets. It is also used by some APIs to guarantee the atomicity of some operation. This mechanism is either implemented in Java Card platform or relies on the transaction mechanism offered by the underlying platform. Some operations of the API are not conditionally updated, as documented in [33] (see for instance, PIN-blocking, PIN-checking, update of Transient objects). 7.1.1.3 Card Security Management FAU_ARP.1 Security alarms Hierarchical-To No other components. Dependencies FAU_SAA.1 Potential violation analysis FAU_ARP.1.1 The TSF shall take [assignment: one of the following actions: • throw an exception, • lock the card session (after a predefined number of resetted sessions the card shall switch to Restricted Mode), • reinitialize the Java Card System and its data, • [assignment: response with error code to S.CAD] ] upon detection of a potential security violation. Refinement The ”potential security violation” stands for one of the following events: • CAP: CAP file inconsistency (response with error code to S.CAD), • LFC: applet life cycle inconsistency (throw an exception), • CHP: card tearing (unexpected removal of the Card out of the CAD) and power failure (reset the card session), • ABT: abort of a transaction in an unexpected context (throw an exception), • FWL: violation of the Firewall or JCVM SFPs (throw an exception), • RSC: unavailability of memory (throw an exception), • OFL: array overflow (throw an exception), • EDC: checksum mismatch of EDC arrays (throw an exception), • assignment: – CHP: Abnormal environmental condition (Frequency, Voltage, Temperature) (reset the card session), – Physical Tampering * CLC: Card Manager Life Cycle inconsistency (reset the card session), * CHP: General Fault Injection Detection (reset the card session) Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 91 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public – CHP: Memory defects (reset the card session), – CHP: Integrity protected persistent data inconsistency (reset the card ses- sion), – CHP: Integrity protected transient data inconsistency (reset the card ses- sion), – Memory Access Violation * CHP: Others (reset the card session) . 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 [assign- ment: integrity errors] on all objects, based on the following attributes: [assignment: integrity protected data]. FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: reset the card session for integrity errors ]. Refinement The following data elements have the user data attribute ”integrity protected data”: • D.APP_KEYs • D.PIN • D.TOE_IDENTIFIER AppNote • Although no such requirement is mandatory in the Java Card specification, at least an exception shall be raised upon integrity errors detection on cryptographic keys, PIN values and their associated security attributes. Even if all the objects cannot be monitored, cryptographic keys and PIN objects shall be considered with particular attention by ST authors as they play a key role in the overall security. • It is also recommended to monitor integrity errors in the code of the native applica- tions and Java Card applets. • For integrity sensitive application, their data shall be monitored (D.APP_I_DATA): applications may need to protect information against unexpected modifications, and explicitly control whether a piece of information has been changed between two accesses. For example, maintaining the integrity of an electronic purse’s balance is extremely important because this value represents real money. Its modification must be controlled, for illegal ones would denote an important failure of the payment system. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 92 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • A dedicated library could be implemented and made available to developers to achieve better security for specific objects, following the same pattern that already exists in cryptographic APIs, for instance. FPR_UNO.1 Unobservability Hierarchical-To No other components. Dependencies No dependencies. FPR_UNO.1.1 The TSF shall ensure that [assignment: all users] are unable to observe the operation [assignment: all operations] on [assignment: D.APP_KEYs, D.PIN] by [assignment: another user]. AppNote Although it is not required in [34] specifications, the non-observability of operations on sensitive information such as keys appears as impossible to circumvent in the smart card world. The precise list of operations and objects is left unspecified, but should at least concern secret keys and PIN codes when they exists on the card, as well as the cryptographic operations and comparisons performed on them. FPT_FLS.1 Failure with preservation of secure state Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: [as- signment: those associated to the potential security violations described in FAU_ ARP.1 ]. AppNote The Java Card RE Context is the Current context when the Java Card VM begins running after a card reset ([34], §6.2.3) or after a proximity card (PICC) activation sequence ([34]). Behavior of the TOE on power loss and reset is described in [34], §3.6 and §7.1. Behavior of the TOE on RF signal loss is described in [34], §3.6.1. FPT_TDC.1 Inter-TSF basic TSF data consistency Hierarchical-To No other components. Dependencies No dependencies. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 93 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [assignment: the CAP files, the bytecode and its data arguments] when shared between the TSF and another trusted IT product. FPT_TDC.1.2 The TSF shall use [assignment: • the rules defined in [35] specification • the API tokens defined in the export files of reference implementation • [assignment: none] ]. when interpreting the TSF data from another trusted IT product. AppNote Concerning the interpretation of data between the TOE and the underlying Java Card platform, it is assumed that the TOE is developed consistently with the SCP functions, including memory management, I/O functions and cryptographic functions. 7.1.1.4 AID Management FIA_ATD.1[AID] User attribute definition (AID) Hierarchical-To No other components. Dependencies No dependencies. FIA_ATD.1.1[AID] The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: • Package AID, • Applet’s Version Number, • Registered Applets, • Applet Selection Status ([34], §4.6) ]. Refinement ”Individual users” stands for applets. FIA_UID.2[AID] User identification before any action (AID) Hierarchical-To FIA_UID.1 Timing of identification Dependencies No dependencies. FIA_UID.2.1[AID] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 94 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public AppNote • By users here it must be understood the ones associated to the packages (or ap- plets) that act as subjects of policies. In the Java Card System, every action is always performed by an identified user interpreted here as the currently selected applet or the package that is the subject’s owner. Means of identification are pro- vided during the loading procedure of the package and the registration of applet instances. • The role Java Card RE defined in FMT_SMR.1 is attached to an IT security function rather than to a ”use” of the CC terminology. The Java Card RE does not ”identify” itself to the TOE, but it is part of it. FIA_USB.1[AID] User-subject binding (AID) Hierarchical-To No other components. Dependencies FIA_ATD.1 User attribute definition FIA_USB.1.1[AID] The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [assignment: Package AID]. FIA_USB.1.2[AID] The TSF shall enforce the following rules on the initial association of user security at- tributes with subjects acting on the behalf of users: [assignment: Each uploaded pack- age is associated with an unique Package AID]. FIA_USB.1.3[AID] The TSF shall enforce the following rules governing changes to the user security at- tributes associated with subjects acting on the behalf of users: [assignment: The ini- tially assigned Package AID is unchangeable]. AppNote The user is the applet and the subject is the S.PACKAGE. The subject security attribute Context shall hold the user security attribute Package AID. FMT_MTD.1[JCRE] Management of TSF data (JCRE) Hierarchical-To No other components. Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1[JCRE] The TSF shall restrict the ability to [selection: modify] the [assignment: list of regis- tered applets’ AIDs] to [assignment: S.JCRE]. AppNote • The installer and the Java Card RE manage other TSF data such as the applet life cycle or CAP files, but this management is implementation specific. Objects in the Java programming language may also try to query AIDs of installed applets through the lookupAID(...) API method. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 95 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • The installer, applet deletion manager or even the card manager may be granted the right to modify the list of registered applets’ AIDs in specific implementations (possibly needed for installation and deletion; see #.DELETION and #.INSTALL). FMT_MTD.3[JCRE] Secure TSF data (JCRE) Hierarchical-To No other components. Dependencies FMT_MTD.1 Management of TSF data FMT_MTD.3.1[JCRE] The TSF shall ensure that only secure values are accepted for [assignment: the regis- tered applet AIDs]. 7.1.2 INSTG Security Functional Requirements The list of SFRs of this category are taken from [9]. The SFR FDP_ITC.2[INSTALLER] has been refined and is now part of the card management SFRs (FDP_ITC.2[CCM]) in section 7.1.6. FMT_SMR.1[INSTALLER] Security roles (INSTALLER) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1[INSTALLER] The TSF shall maintain the roles: [assignment: Installer]. FMT_SMR.1.2[INSTALLER] The TSF shall be able to associate users with roles. FPT_FLS.1[INSTALLER] Failure with preservation of secure state (INSTALLER) Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1[INSTALLER] The TSF shall preserve a secure state when the following types of failures occur: [as- signment: the installer fails to load/install a package/applet as described in [34], §11.1.5 ]. AppNote The TOE may provide additional feedback information to the card manager in case of potential security violations (see FAU_ARP.1). Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 96 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FPT_RCV.3[INSTALLER] Automated recovery without undue loss (INSTALLER) Hierarchical-To FPT_RCV.2 Automated recovery Dependencies AGD_OPE.1 Operational user guidance FPT_RCV.3.1[INSTALLER] When automated recovery from [assignment: none] is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided. FPT_RCV.3.2[INSTALLER] For [assignment: a failure during load/installation of a package/applet and deletion of a package/applet/object], the TSF shall ensure the return of the TOE to a secure state using automated procedures. FPT_RCV.3.3[INSTALLER] The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding [assignment: 0%] for loss of TSF data or objects under the control of the TSF. FPT_RCV.3.4[INSTALLER] The TSF shall provide the capability to determine the objects that were or were not capa- ble of being recovered. AppNote FPT_RCV.3.1[Installer]: • This element is not within the scope of the Java Card specification, which only man- dates the behavior of the Java Card System in good working order. Further details on the ”maintenance mode” shall be provided in specific implementations. The fol- lowing is an excerpt from [4], p298: In this maintenance mode normal operation might be impossible or severely restricted, as otherwise insecure situations might occur. Typically, only authorised users should be allowed access to this mode but the real details of who can access this mode is a function of FMT: Security manage- ment. If FMT: Security management does not put any controls on who can access this mode, then it may be acceptable to allow any user to restore the system if the TOE enters such a state. However, in practice, this is probably not desirable as the user restoring the system has an opportunity to configure the TOE in such a way as to violate the SFRs. FPT_RCV.3.2[Installer]: • Should the installer fail during loading/installation of a package/applet, it has to revert to a ”consistent and secure state”. The Java Card RE has some clean up duties as well; see [34], §11.1.5 for possible scenarios. Precise behavior is left to implementers. This component shall include among the listed failures the deletion of a package/applet. See ([34], §11.3.4) for possible scenarios. Precise behavior is left to implementers. • Other events such as the unexpected tearing of the card, power loss, and so on, are partially handled by the underlying hardware platform (see [15]) and, from the TOE’s side, by events ”that clear transient objects” and transactional features. See FPT_ FLS.1.1, FDP_RIP.1[TRANSIENT], FDP_RIP.1[ABORT] and FDP_ROL.1[FIREWALL]. FPT_RCV.3.3[Installer]: Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 97 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • The quantification is implementation dependent, but some facts can be recalled here. First, the SCP ensures the atomicity of updates for fields and objects, and a power-failure during a transaction or the normal runtime does not create the loss of otherwise permanent data, in the sense that memory on a smart card is essentially persistent with this respect (EEPROM). Data stored on the RAM and subject to such failure is intended to have a limited lifetime anyway (runtime data on the stack, transient objects’ contents). According to this, the loss of data within the TSF scope should be limited to the same restrictions of the transaction mechanism. 7.1.3 ADELG Security Functional Requirements The list of SFRs of this category are taken from [9]. FDP_ACC.2[ADEL] Complete access control (ADEL) Hierarchical-To FDP_ACC.1 Subset access control Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.2.1[ADEL] The TSF shall enforce the [assignment: ADEL access control SFP] on [assignment: S.ADEL, S.JCRE, S.JCVM, O.JAVAOBJECT, O.APPLET and O.CODE_PKG] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2[ADEL] The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Refinement The operations involved in the policy are: • OP.DELETE_APPLET, • OP.DELETE_PCKG, • OP.DELETE_PCKG_APPLET. FDP_ACF.1[ADEL] Security attribute based access control (ADEL) Hierarchical-To No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1[ADEL] The TSF shall enforce the [assignment: ADEL access control SFP] to objects based on the following [assignment: Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 98 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Subject/Object Security Attributes S.JCVM Active Applets S.JCRE Selected Applet Context, Registered Applets, Resident Packages O.CODE_PKG Package AID, Dependent Package AID, Static References O.APPLET Applet Selection Status O.JAVAOBJECT Owner, Remote ] FDP_ACF.1.2[ADEL] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: In the context of this policy, an object O is reachable if and only one of the following conditions hold: 1. the owner of O is a registered applet instance A (O is reachable from A), 2. a static field of a resident package P contains a reference to O (O is reachable from P), 3. there exists a valid remote reference to O (O is remote reachable), 4. there exists an object O’ that is reachable according to either (1) or (2) or (3) above and O’ contains a reference to O (the reachability status of O is that of O’). The following access control rules determine when an operation among controlled sub- jects and objects is allowed by the policy: • R.JAVA.14 ([34], §11.3.4.2, Applet Instance Deletion): S.ADEL may perform OP.DELETE_ APPLET upon an O.APPLET only if, 1. S.ADEL is currently selected, 2. there is no instance in the context of O.APPLET that is active in any logical channel and 3. there is no O.JAVAOBJECT owned by O.APPLET such that either O.JAVAOBJECT is reachable from an applet instance distinct from O.APPLET, or O.JAVAOBJECT is reachable from a package P, or ([34], §8.5) O.JAVAOBJECT is remote reach- able. • R.JAVA.15 ([34], §11.3.4.2.1, Multiple Applet Instance Deletion): S.ADEL may per- form OP.DELETE_APPLET upon several O.APPLET only if, 1. S.ADEL is currently selected, 2. there is no instance of any of the O.APPLET being deleted that is active in any logical channel and 3. there is no O.JAVAOBJECT owned by any of the O.APPLET being deleted such that either O.JAVAOBJECT is reachable from an applet instance distinct from any of those O.APPLET, or O.JAVAOBJECT is reachable from a package P, or ([34], §8.5) O.JAVAOBJECT is remote reachable. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 99 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • R.JAVA.16 ([34], §11.3.4.3, Applet/Library Package Deletion): S.ADEL may perform OP.DELETE_PCKG upon an O.CODE_PKG only if, 1. S.ADEL is currently selected, 2. no reachable O.JAVAOBJECT, from a package distinct from O.CODE_PKG that is an instance of a class that belongs to O.CODE_PKG, exists on the card and 3. there is no resident package on the card that depends on O.CODE_PKG. • R.JAVA.17 ([34], §11.3.4.4, Applet Package and Contained Instances Deletion): S.ADEL may perform OP.DELETE_PCKG_APPLET upon an O.CODE_PKG only if, 1. S.ADEL is currently selected, 2. no reachable O.JAVAOBJECT, from a package distinct from O.CODE_PKG, which is an instance of a class that belongs to O.CODE_PKG exists on the card, 3. there is no package loaded on the card that depends on O.CODE_PKG, and 4. for every O.APPLET of those being deleted it holds that: (i) there is no instance in the context of O.APPLET that is active in any logical channel and (ii) there is no O.JAVAOBJECT owned by O.APPLET such that either O.JAVAOBJECT is reachable from an applet instance not being deleted, or O.JAVAOBJECT is reachable from a package not being deleted, or ([34], §8.5) O.JAVAOBJECT is remote reachable. ] FDP_ACF.1.3[ADEL] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4[ADEL-EditoriallyRefined] The TSF shall explicitly deny access of [assignment: any subject but S.ADEL to O.CODE_PKG or O.APPLET for the purpose of deleting them from the card]. AppNote FDP_ACF.1.2[ADEL]: • This policy introduces the notion of reachability, which provides a general means to describe objects that are referenced from a certain applet instance or package. • S.ADEL calls the ”uninstall” method of the applet instance to be deleted, if imple- mented by the applet, to inform it of the deletion request. The order in which these calls and the dependencies checks are performed are out of the scope of this pro- tection profile. FDP_RIP.1[ADEL] Subset residual information protection (ADEL) Hierarchical-To No other components. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 100 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Dependencies No dependencies. FDP_RIP.1.1[ADEL] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: deallocation of the resource from] the following objects: [assignment: applet instances and/or packages when one of the deletion opera- tions in FDP_ACC.2.1[ADEL] is performed on them]. AppNote Deleted freed resources (both code and data) may be reused, depending on the way they were deleted (logically or physically). Requirements on de-allocation during applet/pack- age deletion are described in [34], §11.3.4.1, §11.3.4.2 and §11.3.4.3. FMT_MSA.1[ADEL] Management of security attributes (ADEL) 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[ADEL] The TSF shall enforce the [assignment: ADEL access control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: Registered Applets and Resident Packages] to [assignment: S.JCRE]. FMT_MSA.3[ADEL] Static attribute initialisation (ADEL) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[ADEL] The TSF shall enforce the[assignment: ADEL access control SFP] to provide [selec- tion: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[ADEL] The TSF shall allow the [assignment: none], to specify alternative initial values to over- ride the default values when an object or information is created. FMT_SMF.1[ADEL] Specification of Management Functions (ADEL) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[ADEL] The TSF shall be capable of performing the following management functions: [assign- ment: modify the list of registered applets’ AIDs and the Resident Packages]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 101 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FMT_SMR.1[ADEL] Security roles (ADEL) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1[ADEL] The TSF shall maintain the roles: [assignment: applet deletion manager]. FMT_SMR.1.2[ADEL] The TSF shall be able to associate users with roles. FPT_FLS.1[ADEL] Failure with preservation of secure state (ADEL) Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1[ADEL] The TSF shall preserve a secure state when the following types of failures occur: [as- signment: the applet deletion manager fails to delete a package/applet as de- scribed in [34], §11.3.4. ] AppNote • The TOE may provide additional feedback information to the card manager in case of a potential security violation (see FAU_ARP.1). • The Package/applet instance deletion must be atomic. The ”secure state” referred to in the requirement must comply with Java Card specification ([34], §11.3.4.) 7.1.4 RMIG Security Functional Requirements Not used in this ST because RMI is optional in PP [9] and the TOE does not support RMI. 7.1.5 ODELG Security Functional Requirements The list of SFRs of this category are taken from [9]. FDP_RIP.1[ODEL] Subset residual information protection (ODEL) Hierarchical-To No other components. Dependencies No dependencies. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 102 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_RIP.1.1[ODEL] The TSF shall ensure that any previous information content of a resource is made unavail- able upon the [selection: deallocation of the resource from] the following objects: [as- signment: the objects owned by the context of an applet instance which triggered the execution of the method javacard.framework.JCSystem.requestObjectDeletion()]. AppNote • Freed data resources resulting from the invocation of the method javacard.framework.JCSystem.requestObjectDeletion() may be reused. Require- ments on de-allocation after the invocation of the method are described in [33]. • There is no conflict with FDP_ROL.1 here because of the bounds on the rollback mechanism: the execution of requestObjectDeletion() is not in the scope of the rollback because it must be performed in between APDU command processing, and therefore no transaction can be in progress. FPT_FLS.1[ODEL] Failure with preservation of secure state (ODEL) Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1[ODEL] The TSF shall preserve a secure state when the following types of failures occur: [as- signment: the object deletion functions fail to delete all the unreferenced objects owned by the applet that requested the execution of the method]. AppNote The TOE may provide additional feedback information to the card manager in case of potential security violation (see FAU_ARP.1). 7.1.6 CarG Security Functional Requirements The card management SFRs from the PP [9] are refined and replaced by the following SFRs. FDP_UIT.1[CCM] Data exchange integrity (CCM) 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] FDP_UIT.1.1[CCM] The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy and the Security Domain access control policy] to [selection: re- ceive] user data in a manner protected from [selection: modification, deletion, inser- tion and replay] errors. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 103 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_UIT.1.2[CCM] The TSF shall be able to determine on receipt of user data, whether [selection: modifi- cation, deletion, insertion, replay] has occurred. FDP_ROL.1[CCM] Basic rollback (CCM) Hierarchical-To No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_ROL.1.1[CCM] The TSF shall enforce [assignment: Security Domain access control policy] to per- mit the rollback of the [assignment: installation operation] on the [assignment: exe- cutable files and application instances]. FDP_ROL.1.2[CCM] The TSF shall permit operations to be rolled back within the [assignment: boundaries of available memory before the card content management function started]. FDP_ITC.2[CCM] Import of user data with security attributes (CCM) 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 ba- sic TSF data consistency FDP_ITC.2.1[CCM] The TSF shall enforce the [assignment: Security Domain access control policy and the Secure Channel Protocol information flow policy] when importing user data, con- trolled under the SFP, from outside of the TOE. FDP_ITC.2.2[CCM] The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3[CCM] 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[CCM] 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[CCM] The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [assignment: Package loading is allowed only if, for each dependent package, its AID attribute is equal to a resident package AID attribute, the major (minor) Version attribute associated to the dependent package is lesser than or equal to the major (minor) Version attribute associated to the resident package ([35], §4.5.2). ] AppNote This SFR also covers security functionality required by Amendment A of the GP specifi- cation [20], i.e. personalizing SDs and loading ciphered load files. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 104 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FPT_FLS.1[CCM] Failure with preservation of secure state (CCM) Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1[CCM] The TSF shall preserve a secure state when the following types of failures occur: [as- signment: the Security Domain fails to load/install an Executable File/application instance as described in [34], Section 11.1.5] FDP_ACC.1[SD] Subset access control (SD) Hierarchical-To No other components. Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.1.1[SD] The TSF shall enforce the [assignment: Security Domain access control policy] on: [assignment: • Subjects: S.INSTALLER, S.ADEL, S.CAD (from [9]) and S.SD • Objects: Delegation Token, DAP Block and Load File • Operations: GlobalPlatform’s card content management APDU commands and API methods] FDP_ACF.1[SD] Security attribute based access control (SD) Hierarchical-To No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1[SD] The TSF shall enforce the [assignment: Security Domain access control policy] to objects based on the following: [assignment: • Subjects: – S.INSTALLER, defined in [9] and represented by the GlobalPlatform En- vironment (OPEN) on the card, the Card Life Cycle attributes (defined in Section 5.1.1 of [22]) – S.ADEL, also defined in [9] and represented by the GlobalPlatform Envi- ronment (OPEN) on the card – S.SD receiving the Card Content Management commands (through AP- DUs or APIs) with a set of Privileges (defined in Section 6.6.1 of [22]), a Life-cycle Status (defined in Section 5.3.2 of [22]) and a Secure Commu- nication Security Level (defined in Section 10.6 of [22]) Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 105 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public – S.CAD, defined in [9], the off-card entity that communicates with the S.INSTALLER and S.ADEL through S.SD • Objects: – The Delegation Token, in case of Delegated Management operations, with the attributes Present or Not Present – The DAP Block, in case of application loading, with the attributes Present or Not Present – The Load File or Executable File, in case of application loading, installa- tion, extradition or registry update, with a set of intended privileges and its targeted associated SD AID. • Mapping subjects/objects to security attributes: – S.INSTALLER: Security Level, Card Life Cycle, Life-cycle Status, Privi- leges, Resident Packages, Registered Applets – S.ADEL: Active Applets, Static References, Card Life Cycle, Life-cycle Status, Privileges, Applet Selection Status, Security Level – S.SD: Privileges, Life-cycle Status, Security Level – S.CAD: Security Level] FDP_ACF.1.2[SD] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: Runtime behavior rules de- fined by GlobalPlatform for: • loading (Section 9.3.5 of [22]) • installation (Section 9.3.6 of [22]) • extradition (Section 9.4.1 of [22]) • registry update (Section 9.4.2 of [22]) • content removal (Section 9.5 of [22]).] FDP_ACF.1.3[SD] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4[SD] The TSF shall explicitly deny access of subjects to objects based on the following addi- tional rules: [assignment: when at least one of the rules defined by GlobalPlatform does not hold.] FMT_MSA.1[SD] Management of security attributes (SD) Hierarchical-To No other components. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 106 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 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[SD] The TSF shall enforce the [assignment: Security Domain access control policy] to restrict the ability to [assignment: modify] the security attributes [assignment: • Card Life Cycle, • Privileges, • Life-cycle Status, • Security Level.] to [assignment: the Security Domain and the application instance itself]. FMT_MSA.3[SD] Static attribute initialisation (SD) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[SD] The TSF shall enforce the [assignment: Security Domain access control policy] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[SD] The TSF shall allow the [assignment: Card Issuer or the Application Provider] to specify alternative initial values to override the default values when an object or informa- tion is created. Refinement Alternative initial values shall be at least as restrictive as the default values defined in FMT_MSA.3.1[SD]. FMT_SMF.1[SD] Specification of Management Functions (SD) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[SD] The TSF shall be capable of performing the following management functions: [assign- ment: • Management functions specified in GlobalPlatform specifications [GP]: – card locking (Section 9.6.3 of [22]) – application locking and unlocking (Section 9.6.2 of [22]) – card termination (Section 9.6.4 of [22]) Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 107 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public – card status interrogation (Section 9.6.6 of [22]) – application status interrogation (Section 9.6.5 of [22]).] FMT_SMR.1[SD] Security roles (SD) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1[SD] The TSF shall maintain the roles [assignment: ISD, SSD]. FMT_SMR.1.2[SD] The TSF shall be able to associate users with roles. FCO_NRO.2[SC] Enforced proof of origin (SC) Hierarchical-To FCO_NRO.1 Selective proof of origin. Dependencies FIA_UID.1 Timing of identification. FCO_NRO.2.1[SC] The TSF shall enforce the generation of evidence of origin for transmitted [assignment: Executable load files] at all times. FCO_NRO.2.2[SC] The TSF shall be able to relate the [assignment: DAP Block] of the originator of the information, and the [assignment: identity] of the information to which the evidence applies. FCO_NRO.2.3[SC] The TSF shall provide a capability to verify the evidence of origin of information to [se- lection: originator] given [assignment: at the time the Executable load files are received as no evidence is kept on the card for future verification]. AppNote FCO_NRO.2.1[SC]: • Upon reception of a new application package for installation, the card manager shall first check that it actually comes from the verification authority. The verification authority is the entity responsible for bytecode verification. FCO_NRO.2.3[SC]: • The exact limitations on the evidence of origin are implementation dependent. In most of the implementations, the card manager performs an immediate verifica- tion of the origin of the package using an electronic signature mechanism, and no evidence is kept on the card for future verifications. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 108 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_IFC.2[SC] Complete information flow control (SC) Hierarchical-To FDP_IFC.1 Subset information flow control Dependencies FDP_IFF.1 Simple security attributes FDP_IFC.2.1[SC] The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] on [assignment: • the subjects S.CAD and S.SD, involved in the exchange of messages between the TOE and the CAD through a potentially unsafe communication channel, • the information controlled by this policy are the card content management commands, including personalization commands, in the APDUs sent to the card and their associated responses returned to the CAD] and all operations that cause that information to flow to and from subjects covered by the SFP. FDP_IFC.2.2[SC] The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. FDP_IFF.1[SC] Simple security attributes (SC) Hierarchical-To No other components. Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFF.1.1[SC] The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] based on the following types of subject and information security at- tributes: [assignment: • Subjects: – S.SD receiving the Card Content Management commands (through AP- DUs or APIs). – S.CAD the off-card entity that communicates with the S.SD. • Information: – executable load file, in case of application loading; – applications or SD privileges, in case of application installation or reg- istry update; FDP_IFF.1.2[SC] The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: • Runtime behavior rules defined by GlobalPlatform for: – loading (Section 9.3.5 of [22]); Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 109 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public – installation (Section 9.3.6 of [22]); – extradition (Section 9.4.1 of [22]); – registry update (Section 9.4.2 of [22]); – content removal (Section 9.5 of [22]).] FDP_IFF.1.3[SC] The TSF shall enforce the [assignment: no additional information flow control SFP rules]. FDP_IFF.1.4[SC] The TSF shall explicitly authorise an information flow based on the following rules: [as- signment: none]. FDP_IFF.1.5[SC] The TSF shall explicitly deny an information flow based on the following rules: [assign- ment: • When none of the conditions listed in the element FDP_IFF.1.4 of this compo- nent hold and at least one of those listed in the element FDP_IFF.1.2 does not hold.] AppNote The subject S.SD can be the ISD or APSD. AppNote The on-card and the off-card subjects have security attributes such as MAC, Cryptogram, Challenge, Key Set, Static Keys, etc. FMT_MSA.1[SC] Management of security attributes (SC) 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[SC] The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] to restrict the ability to [selection: modify] the security attributes [as- signment: • Key Set, • Security Level, • Secure Channel Protocol, • Session Keys, • Sequence Counter, • ICV. to [assignment: the actor associated with the according security domain: • The Card Issuer for ISD, • The Application Provider for APSD.] Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 110 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public AppNote The key data used for setting up a secure channel is according to GP spec [22], Amend- ment D [30] and Amendmend F [32]. FMT_MSA.3[SC] Static attribute initialisation (SC) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[SC] The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[SC] The TSF shall allow the [assignment: Card Issuer, Application Provider] to specify alternative initial values to override the default values when an object or information is created. FMT_SMF.1[SC] Specification of Management Functions (SC) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[SC] The TSF shall be capable of performing the following management functions: [assign- ment: • Management functions specified in GlobalPlatform specifications [GP]: – loading (Section 9.3.5 of [22]) – installation (Section 9.3.6 of [22]) – extradition (Section 9.4.1 of [22]) – registry update (Section 9.4.2 of [22]) – content removal (Section 9.5 of [22]).] AppNote All management functions related to secure channel protocols shall be relevant. FIA_UID.1[SC] Timing of identification (SC) Hierarchical-To No other components. Dependencies No dependencies. FIA_UID.1.1[SC] The TSF shall allow [assignment: Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 111 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • application selection • initializing a secure channel with the card • requesting data that identifies the card or the Card Issuer] on behalf of the user to be performed before the user is identified. FIA_UID.1.2[SC] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. AppNote The GlobalPlatform TSF mediated actions listed in [GP] such as selecting an application, requesting data, initializing, etc. FIA_UAU.1[SC] Timing of authentication (SC) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FIA_UAU.1.1[SC] The TSF shall allow [assignment: the TSF mediated actions listed in FIA_UID.1[SC]] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2[SC] The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.4[SC] Single-use authentication mechanisms Hierarchical-To No other components. Dependencies No dependencies. FIA_UAU.4.1[SC] The TSF shall prevent reuse of authentication data related to [assignment: the authen- tication mechanism used to open a secure communication channel with the card.] FTP_ITC.1[SC] Inter-TSF trusted channel (SC) Hierarchical-To No other components. Dependencies No dependencies. FTP_ITC.1.1[SC] The TSF shall provide a communication channel between itself and another trusted IT that is logically distinct from other communication channels and provides assured identifi- cation of its end points and protection of the channel data from modification or disclosure. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 112 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FTP_ITC.1.2[SC] The TSF shall permit [selection: another trusted IT product] to initiate communication via the trusted channel. FTP_ITC.1.3[SC] The TSF shall initiate communication via the trusted channel for [assignment: all card management functions: • loading • installation • extradition • registry update • content removal • changing the Application Life Cycle or Card Life Cycle.] 7.1.7 Further Security Functional Requirements The SFRs in this section provide additional proprietary features. FAU_SAS.1[SCP] Audit Data Storage (SCP) Hierarchical-To No other components. Dependencies No other components. FAU_SAS.1.1[SCP] The TSF shall provide [assignment: test personnel before TOE Delivery] with the ca- pability to store the [assignment: Initialisation Data and/or Prepersonalisation Data and/or supplements of the Smartcard Embedded Software] in the [assignment: au- dit records]. FCS_RNG.1 Random Number Generation. Hierarchical-To No other components. Dependencies No dependencies FCS_RNG.1.1 The TSF shall provide a [selection: hybrid deterministic] random number generator that implements [assignment: • (DRG.4.1) The internal state of the RNG shall use PTRNG of class PTG.2 (as defined in [1]) as random source. • (DRG.4.2)The RNG provides forward secrecy (as defined in [1]). • (DRG.4.3) The RNG provides backward secrecy even if the current internal state is known (as defined in [1]). Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 113 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • (DRG.4.4) The RNG provides enhanced forward secrecy on demand (as defined in [1]). • (DRG.4.5) The internal state of the RNG is seeded by an PTRNG of class PTG.2 (as defined in [1]). ] FCS_RNG.1.2 The TSF shall provide [selection: random numbers] that meet [assignment: • (DRG.4.6) The RNG generates output for which 248 strings of bit length 128 are mutually different with probability at least 1 − 2−24 . • (DRG.4.7) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test pro- cedure A (as defined in [1]). ] AppNote This functionality is provided by the certified Security Software (FCS_RNG.1/HYB-DET), see [14] FIA_AFL.1[PIN] Basic Authentication Failure Handling (PIN) Hierarchical-To No other components. Dependencies FIA_UAU.1 Timing of authentication. FIA_AFL.1.1[PIN] The TSF shall detect when [selection: an administrator configurable positive integer within [1 and 127]] unsuccessful authentication attempts occur related to [assignment: any user authentication using D.PIN]. FIA_AFL.1.2[PIN] When the defined number of unsuccessful authentication attempts has been [selection: surpassed], the TSF shall [assignment: block the authentication with D.PIN]. AppNote The dependency with FIA_UAU.1 is not applicable. The TOE implements the firewall access control SFP, based on which access to the object implementing FIA_AFL.1[PIN] is organized. 7.1.8 SecureBox Security Functional Requirements The SFRs in this section provide additional proprietary features. FDP_ACC.2[SecureBox] Complete access control (SecureBox) Hierarchical-To FDP_ACC.1 Subset access control Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 114 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.2.1[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP] on [assign- ment: S.SBNativeCode, O.SB_Content, O.NON_SB_Content, O.SFR] and all opera- tions among subjects and objects covered by the SFP. FDP_ACC.2.2[SecureBox] The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Refinement The operations involved in this policy are: • OP.SB_ACCESS, • OP.SB_ACCESS_SFR. FDP_ACF.1[SecureBox] Security attribute based access control (SecureBox) Hierarchical-To No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP] to all objects based on the following: [assignment: S.SBNativeCode, O.SB_Content, O.NON_SB_ Content, O.SFR and the attributes CPU Mode, the MMU Segment Table, the Special Function Registers to configure the MMU segmentation and the Special Function Registers related to system management]. FDP_ACF.1.2[SecureBox] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: • Code assigned to S.SBNativeCode shall only be executed in CPU Mode Ap- plication Unprivileged Mode. • Code assigned to S.SBNativeCode shall only be able to perform OP.SB_AC- CESS to O.SB_Content . The memory area which belongs to O.SB_Content is controlled by the MMU Segment Table used by the Memory Management Unit. ]. FDP_ACF.1.3[SecureBox] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none] FDP_ACF.1.4[SecureBox] The TSF shall explicitly deny access of subjects to objects based on the following addi- tional rules: [assignment: • For S.SBNative Code it shall not be possible to perform OP.SB_ACCESS to O.NON_SB_Content. • For S.SBNative Code it shall not be possible to perform OP.SB_ACCESS_SFR to O.SFR. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 115 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public ]. FMT_MSA.1[SecureBox] Management of security attributes (SecureBox) 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[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: CPU Mode and the MMU Segment Table] to [assignment: S.JCRE]. FMT_MSA.3[SecureBox] Static attribute initialisation (SecureBox) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[SecureBox] The TSF shall allow the [assignment: S.JCRE] to specify alternative initial values to override the default values when an object or information is created. AppNote During the prepersonalisation of the TOE the initial restrictive values for the security at- tributes can be overwritten by the JCRE. AppNote The dependency to FMT_SMR.1 is fulfilled by FMT_SMR.1 . FMT_SMF.1[SecureBox] Specification of Management Functions (SecureBox) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[SecureBox] The TSF shall be capable of performing the following management functions: [assign- ment: • Switch the CPU Mode • Change the values in the MMU Segment Table to assign RAM and Flash areas to the Secure Box Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 116 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public ]. 7.1.9 Configuration Security Functional Requirements FDP_IFC.2[CFG] Complete information flow control (CFG) Hierarchical-To FDP_IFC.1 Subset information flow control Dependencies FDP_IFF.1 Simple security attributes FDP_IFC.2.1[CFG] The TSF shall enforce the [assignment: CONFIGURATION information flow con- trol SFP] on [assignment: S.Customer, S.NXP, S.ConfigurationMechanism, and D.CONFIG_ITEM] and all operations that cause that information to flow to and from sub- jects covered by the SFP. FDP_IFC.2.2[CFG] The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. FDP_IFF.1[CFG] Simple security attributes (CFG) Hierarchical-To No other components. Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFF.1.1[CFG] The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP] based on the following types of subject and information security attributes: [assign- ment: Subject/Information Security attributes S.Customer Customer Configuration Token S.NXP NXP Configuration Token S.ConfigurationMechanism NXP Configuration Access, Customer Configuration Access D.CONFIG_ITEM access privilege ]. FDP_IFF.1.2[CFG] The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: • Read and write operations of D.CONFIG_ITEM between S.ConfigurationMechanism and S.NXP shall only be possible when S.NXP is authenticated with its token using the NXP Configuration Token. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 117 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public • Read and write operations of D.CONFIG_ITEM between S.ConfigurationMechanism and S.Customer shall only be possible when S.Customer is authenticated with its token using the Customer Configuration Token and if access privi- lege allows it. • Enabling or disabling of NXP Configuration Access between S.ConfigurationMechanism and S.NXP shall only be possible when S.NXP is authenticated with its token using the NXP Configuration Token. ]. FDP_IFF.1.3[CFG] The TSF shall enforce the additional information flow control SFP rules [assignment: none]. FDP_IFF.1.4[CFG] The TSF shall explicitly authorise an information flow based on the following rules [as- signment: none]. FDP_IFF.1.5[CFG] The TSF shall explicitly deny an information flow based on the following rules [assign- ment: • If the NXP Configuration Access is disabled then nobody can read or write D.CONFIG_ITEM. • If the Customer Configuration Access is disabled then S.Customer can not read or write D.CONFIG_ITEM. ]. AppNote GlobalPlatform Framework authentication mechnism is used to authenticate the tokens. FIA_UID.1[CFG] Timing of identification (CFG) Hierarchical-To No other components. Dependencies No dependencies. FIA_UID.1.1[CFG] The TSF shall allow [assignment: to select the configuration applet] on behalf of the user to be performed before the user is identified. FIA_UID.1.2[CFG] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. FMT_MSA.1[CFG] Management of security attributes (CFG) Hierarchical-To No other components. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 118 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 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[CFG] The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: NXP Configuration Access and Customer Configuration Access] to [assignment: S.NXP and S.Customer] respectively. FMT_MSA.3[CFG] Static attribute initialisation (CFG) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[CFG] The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[CFG] The TSF shall allow the [assignment: nobody] to specify alternative initial values to override the default values when an object or information is created. FMT_SMF.1[CFG] Specification of Management Functions (CFG) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[CFG] The TSF shall be capable of performing the following management functions: [assign- ment: disable the NXP Configuration Access, disable the Customer Configuration Access.] FMT_SMR.1[CFG] Security roles (CFG) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1[CFG] The TSF shall maintain the roles [assignment: S.NXP and S.Customer]. FMT_SMR.1.2[CFG] The TSF shall be able to associate users with roles. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 119 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public AppNote The roles of the CONFIGURATION information flow control SFP are defined by the NXP Configuration Token and the Customer Configuration Token. 7.1.10 OS Update Security Functional Requirements The SFRs in this section provide JCOP proprietary features. FDP_IFC.2[OSU] Complete information flow control (OSU) Hierarchical-To FDP_IFC.1 Subset information flow control Dependencies FDP_IFF.1 Simple security attributes FDP_IFC.2.1[OSU] The TSF shall enforce the [assignment: OS Update information flow control SFP] on [assignment: S.OSU and D.UPDATE_IMAGE] and all operations that cause that information to flow to and from subjects covered by the SFP. FDP_IFC.2.2[OSU] The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. FDP_IFF.1[OSU] Simple security attributes (OSU) Hierarchical-To No other components. Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFF.1.1[OSU] The TSF shall enforce the [assignment: OS Update information flow control SFP] based on the following types of subject and information security attributes: [assignment: Subject/Information Security attributes S.OSU Current Sequence Number, Verification Key, Package De- cryption Key D.UPDATE_IMAGE Received Sequence Number, Image Type ] . FDP_IFF.1.2[OSU] The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: • S.OSU shall only accept D.UPDATE_IMAGE which signature can be verified with Verification Key. • S.OSU shall only accept D.UPDATE_IMAGE for the update process that can be decrypted with Package Decryption Key. ]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 120 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_IFF.1.3[OSU] The TSF shall enforce the additional information flow control SFP rules [assignment: S.OSU shall only authorize D.UPDATE_IMAGE for the update process if the follow- ing rules apply: • If Image Type equals Reset then Received Sequence Number shall equal Current Sequence Number. • If Image Type equals Upgrade then Received Sequence Number shall be higher than Current Sequence Number. ]. FDP_IFF.1.4[OSU] The TSF shall explicitly authorise an information flow based on the following rules [as- signment: none]. FDP_IFF.1.5[OSU] The TSF shall explicitly deny an information flow based on the following rules [assign- ment: none] . AppNote The on-card S.OSU role interacts with the off-card S.UpdateImageCreator via OSU com- mands. The D.UPDATE_IMAGE is split up into smaller chunks and transmitted as payload within the OSU Commands to the TOE. AppNote Decrypting the D.UPDATE_IMAGE with the Package Decryption Key prevents the autho- rization of the D.UPDATE_IMAGE for the update process on a not certified system. The Package Decryption Key is only available on a certified TOE. FMT_MSA.3[OSU] Static attribute initialisation (OSU) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[OSU] The TSF shall enforce the [assignment: OS Update information flow control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[OSU] The TSF shall allow the [assignment: S.OSU] specify alternative initial values to override the default values when an object or information is created. FMT_MSA.1[OSU] Management of security attributes (OSU) 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 Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 121 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FMT_MSA.1.1[OSU] The TSF shall enforce the [assignment: OS Update information flow control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: Current Sequence Number] to [assignment: S.OSU]. FMT_SMR.1[OSU] Security roles (OSU) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1[OSU] The TSF shall maintain the roles [assignment: S.OSU]. FMT_SMR.1.2[OSU] The TSF shall be able to associate users with roles. FMT_SMF.1[OSU] Specification of Management Functions (OSU) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[OSU] The TSF shall be capable of performing the following management functions: [assign- ment: • query Current Sequence Number • query Reference Sequence Number ] AppNote After the atomic activation of the additional code the Final Sequence Number is returned on querying the Current Sequence Number. FIA_UID.1[OSU] Timing of identification (OSU) Hierarchical-To No other components. Dependencies No dependencies. FIA_UID.1.1[OSU] The TSF shall allow [assignment: OP.TRIGGER_UPDATE] on behalf of the user to be performed before the user is identified. FIA_UID.1.2[OSU] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 122 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FIA_UAU.1[OSU] Timing of authentication (OSU) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FIA_UAU.1.1[OSU] The TSF shall allow [assignment: OP.TRIGGER_UPDATE] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2[OSU] The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.4[OSU] Single-use authentication mechanisms Hierarchical-To No other components. Dependencies No dependencies. FIA_UAU.4.1[OSU] The TSF shall prevent reuse of authentication data related to [assignment: the authen- tication mechanism used to load D.UPDATE_IMAGE.] FPT_FLS.1[OSU] Failure with preservation of secure state (OSU) Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1[OSU] The TSF shall preserve a secure state when the following types of failures occur: [as- signment: • Corrupted D.UPDATE_IMAGE is received • Unauthorized D.UPDATE_IMAGE is received. • The OS Update Process is interrupted. • The activation of the additional code failed. ]. 7.1.11 Restricted Mode Security Functional Requirements The SFRs in this section provide JCOP proprietary features. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 123 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_ACC.2[RM] Complete access control (Restricted Mode) Hierarchical-To FDP_ACC.1 Subset access control Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.2.1[RM] The TSF shall enforce the [assignment: Restricted Mode access control SFP] on [assignment: S.SD] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2[RM] The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACF.1[RM] Security attribute based access control (Restricted Mode) Hierarchical-To No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1[RM] The TSF shall enforce the [assignment: Restricted Mode access control SFP] to objects based on the following [assignment: Subject/Object Security attributes S.SD D.ATTACK_COUNTER ] FDP_ACF.1.2[RM] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: The D.ATTACK_COUNTER can be reset by ISD]. FDP_ACF.1.3[RM] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4[RM] The TSF shall explicitly deny access of subjects to objects based on the following ad- ditional rules: [assignment: Deny all operations on all objects if the D.ATTACK_ COUNTER has reached its limit (restricted mode), except for operations listed in FMT_SMF.1[RM]]. FMT_MSA.3[RM] Static attribute initialisation (Restricted Mode) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[RM] The TSF shall enforce the [assignment: Restricted Mode access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[RM] The TSF shall allow the [assignment: nobody] to specify alternative initial values to override the default values when an object or information is created. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 124 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FMT_MSA.1[RM] Management of security attributes (Restricted Mode) 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[RM] The TSF shall enforce the [assignment: Restricted Mode access control policy] to re- strict the ability to [selection: modify] the security attributes [assignment: D.ATTACK_ COUNTER] to [assignment: ISD]. FMT_SMF.1[RM] Specification of Management Functions (Restricted Mode) Hierarchical-To No other components. Dependencies No dependencies. FMT_SMF.1.1[RM] The TSF shall be capable of performing the following management functions: [assign- ment: • reset D.ATTACK_COUNTER. • select ISD. • authentication against the ISD. • initialize a Secure Channel with the card. • query the Serial Number (Unique ID for chip). • read Platform Identifier. • query the logging information. • read Secure Channel Sequence Counter. • read Current Sequence Number. ] FIA_UID.1[RM] Timing of identification (RM) Hierarchical-To No other components. Dependencies No dependencies. FIA_UID.1.1[RM] The TSF shall allow [assignment: • select ISD Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 125 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public ] on behalf of the user to be performed before the user is identified. FIA_UID.1.2[RM] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.1[RM] Timing of authentication (RM) Hierarchical-To No other components. Dependencies FIA_UID.1 Timing of identification FIA_UAU.1.1[RM] The TSF shall allow [assignment: • select ISD ] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2[RM] The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 7.1.12 Factory Reset The SFRs in this section provide JCOP proprietary features. FDP_ACC.2[UDW] Complete access control (Factory Reset) Hierarchical-To FDP_ACC.1 Subset access control Dependencies FDP_ACF.1 Security attribute based access control FDP_ACC.2.1[UDW] The TSF shall enforce the [assignment: Factory Reset access control SFP] on [as- signment: S.FAR, packages, applets, Security Domains and their related Data] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2[UDW] The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACF.1[UDW] Security attribute based access control (Factory Reset) Hierarchical-To No other components. Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 126 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FDP_ACF.1.1[UDW] The TSF shall enforce the [assignment: Factory Reset access control SFP] to objects based on the following [assignment: Subject/Object Security attributes S.FAR Trigger Factory Reset Allowed AID packages, applets, Security Do- mains and their related Data Clear List ] FDP_ACF.1.2[UDW] The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: • The S.FAR shall only delete packages, applets, Security Domains and their related Data that are listed in the Clear List. • The S.FAR shall only delete packages, applets, Security Domains and their related Data if it’s AID is equal to Trigger Factory Reset Allowed AID. ] FDP_ACF.1.3[UDW] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none]. FDP_ACF.1.4[UDW] The TSF shall explicitly deny access of subjects to objects based on the following addi- tional rules: [assignment: none]. FMT_MSA.3[UDW] Static attribute initialisation (Factory Reset) Hierarchical-To No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1[UDW] The TSF shall enforce the [assignment: Factory Reset access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2[UDW] The TSF shall allow the [assignment: nobody] to specify alternative initial values to override the default values when an object or information is created. FMT_MSA.1[UDW] Management of security attributes (Factory Reset) 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 Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 127 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public FMT_MSA.1.1[UDW] The TSF shall enforce the [assignment: Factory Reset access control policy] to re- strict the ability to [selection: modify] the security attributes [assignment: Clear List] to [assignment: SSD]. FDP_RIP.1[UDW] Subset residual information protection (UDW) Hierarchical-To No other components. Dependencies No dependencies. FDP_RIP.1.1[UDW] The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: deallocation of the resource from] the following objects: [assignment: all packages, applets, Security Domains and their related Data which are listed in the Clear List]. AppNote The deletion of the objects is referred to as Factory Reset process. FPT_FLS.1[UDW] Failure with preservation of secure state (UDW) Hierarchical-To No other components. Dependencies No dependencies. FPT_FLS.1.1[UDW] The TSF shall preserve a secure state when the following types of failures occur: [as- signment: the Factory Reset process fails to complete] AppNote The Factory Reset process must be atomic. 7.2 Security Assurance Requirements The assurance requirements of this evaluation are EAL6 augmented by ASE_TSS.2, and ALC_FLR.1. The as- surance requirements ensure, among others, the security of the TOE during its development and production. ADV_SPM.1 Formal TOE security policy model Hierarchical-To No other components. Dependencies ADV_FSP.4 Complete functional specification ADV_SPM.1.1D The developer shall provide a formal security policy model for the [assignment: FIRE- WALL access control SFP (FDP_ACC.2[FIREWALL])]. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 128 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 7.3 Security Requirements Rationale for the TOE 7.3.1 Identification OT.SID SFR Rationale FIA_UID.2[AID] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. Installation procedures ensure protection against forgery (the AID of an applet is under the control of the TSFs) or re-use of identities and is met by the SFR. FIA_USB.1[AID] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. Installation procedures ensure protection against forgery (the AID of an applet is under the control of the TSFs) or re-use of identities and is met by the SFR. FMT_MSA.1[JCRE] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.1[JCVM] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.1[ADEL] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.3[FIREWALL] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.3[JCVM] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.3[ADEL] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MTD.1[JCRE] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MTD.3[JCRE] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_SMF.1[ADEL] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FIA_ATD.1[AID] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FDP_ITC.2[CCM] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.1[SC] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. FMT_MSA.3[SC] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 129 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FMT_SMF.1[SC] Subjects’ identity is AID-based (applets, packages) and is met by the SFR. 7.3.2 Execution OT.FIREWALL SFR Rationale FDP_ACC.2[FIREWALL] The FIREWALL access control policy contributes to meet this objective. FDP_ACF.1[FIREWALL] The FIREWALL access control policy contributes to meet this objective. FDP_IFC.1[JCVM] The JCVM information flow control policy contributes to meet this objective. FDP_IFF.1[JCVM] The JCVM information flow control policy contributes to meet this objective. FMT_MSA.1[JCRE] Contributes indirectly to meet this objective. FMT_MSA.1[JCVM] Contributes indirectly to meet this objective. FMT_MSA.1[ADEL] Contributes indirectly to meet this objective. FMT_MSA.2[FIREWALL-JCVM] Contributes indirectly to meet this objective. FMT_MSA.3[FIREWALL] Contributes indirectly to meet this objective. FMT_MSA.3[JCVM] Contributes indirectly to meet this objective. FMT_MSA.3[ADEL] Contributes indirectly to meet this objective. FMT_MTD.1[JCRE] Contributes indirectly to meet this objective. FMT_MTD.3[JCRE] Contributes indirectly to meet this objective. FMT_SMF.1 Contributes indirectly to meet this objective. FMT_SMF.1[ADEL] Contributes indirectly to meet this objective. FMT_SMR.1 Contributes indirectly to meet this objective. FMT_SMR.1[INSTALLER] Contributes indirectly to meet this objective. FMT_SMR.1[ADEL] Contributes indirectly to meet this objective. FDP_ITC.2[CCM] Contributes indirectly to meet this objective. FMT_SMR.1[SD] Contributes indirectly to meet this objective. FMT_MSA.1[SC] Contributes indirectly to meet this objective. FMT_MSA.3[SC] Contributes indirectly to meet this objective. FMT_SMF.1[SC] Contributes indirectly to meet this objective. OT.GLOBAL_ARRAYS_CONFID Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 130 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FDP_IFC.1[JCVM] The JCVM information flow control policy meets the objec- tive by preventing an application from keeping a pointer to a shared buffer, which could be used to read its contents when the buffer is being used by another application. FDP_IFF.1[JCVM] The JCVM information flow control policy meets this ob- jective by preventing an application from keeping a pointer to a shared buffer, which could be used to read its con- tents when the buffer is being used by another application. FDP_RIP.1[OBJECTS] Contributes to meet the objective by protecting the ar- ray parameters of remotely invoked methods, which are global as well, through the general initialization of method parameters. FDP_RIP.1[ABORT] Contributes to meet the objective by protecting the ar- ray parameters of remotely invoked methods, which are global as well, through the general initialization of method parameters. FDP_RIP.1[APDU] Only arrays can be designated as global, and the only global arrays required in the Java Card API are the APDU buffer and the global byte array input parameter (bArray) to an applet’s install method. Contributes to meet this ob- jective by fulfilling the clearing requirement of these ar- rays. FDP_RIP.1[bArray] Only arrays can be designated as global, and the only global arrays required in the Java Card API are the APDU buffer and the global byte array input parameter (bArray) to an applet’s install method. Contributes to meet this ob- jective by fulfilling the clearing requirement of these ar- rays. FDP_RIP.1[KEYS] Contributes to meet the objective by protecting the array parameters of invoked methods, which are global as well, through the general initialization of method parameters. FDP_RIP.1[TRANSIENT] Contributes to meet the objective by protecting the array parameters of invoked methods, which are global as well, through the general initialization of method parameters. FDP_RIP.1[ADEL] Contributes to meet the objective by protecting the array parameters of invoked methods, which are global as well, through the general initialization of method parameters. FDP_RIP.1[ODEL] Contributes to meet the objective by protecting the array parameters of invoked methods, which are global as well, through the general initialization of method parameters. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 131 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public OT.GLOBAL_ARRAYS_INTEG SFR Rationale FDP_IFC.1[JCVM] Contributes to meet the objective by preventing an ap- plication from keeping a pointer to the APDU buffer of the card or to the global byte array of the applet’s install method. Such a pointer could be used to access and modify it when the buffer is being used by another ap- plication. FDP_IFF.1[JCVM] Contributes to meet the objective by preventing an ap- plication from keeping a pointer to the APDU buffer of the card or to the global byte array of the applet’s install method. Such a pointer could be used to access and modify it when the buffer is being used by another ap- plication. OT.NATIVE SFR Rationale FDP_ACF.1[FIREWALL] Covers this objective by ensuring that the only means to execute native code is the invocation of a Java Card API method. This objective mainly relies on the environmen- tal objective OE.APPLET, which uphold the assumption A.APPLET. OT.OPERATE SFR Rationale FAU_ARP.1 Contributes to meet this objective by detecting and block- ing various failures or security violations during usual working. FDP_ACC.2[FIREWALL] Contributes to meet this objective by protecting the TOE through the FIREWALL access control policy. FDP_ACF.1[FIREWALL] Contributes to meet this objective by protecting the TOE through the FIREWALL access control policy. FDP_ROL.1[FIREWALL] Contributes to meet this objective by providing support for cleanly abort applets’ installation, which belongs to the category security-critical parts and procedures protection. FIA_AFL.1[PIN] Contributes to meet the objective by protecting the au- thentication. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 132 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FIA_USB.1[AID] Contributes to meet this objective by controlling the com- munication with external users and their internal subjects to prevent alteration of TSF data. FPT_TDC.1 Contributes to meet this objective by protection in various ways against applets’ actions. FPT_RCV.3[INSTALLER] Contributes to meet this objective by providing safe recov- ery from failure, which belongs to the category of security- critical parts and procedures protection. FIA_ATD.1[AID] Contributes to meet this objective by controlling the com- munication with external users and their internal subjects to prevent alteration of TSF data. FPT_FLS.1 Contributes to meet this objective by detecting and block- ing various failures or security violations during usual working. FPT_FLS.1[INSTALLER] Contributes to meet this objective by detecting and block- ing various failures or security violations during usual working. FPT_FLS.1[ADEL] Contributes to meet this objective by detecting and block- ing various failures or security violations during usual working. FPT_FLS.1[ODEL] Contributes to meet this objective by detecting and block- ing various failures or security violations during usual working. FDP_ITC.2[CCM] Contributes to meet this objective by detecting and block- ing various failures or security violations during usual working. OT.REALLOCATION SFR Rationale FDP_RIP.1[OBJECTS] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. FDP_RIP.1[ABORT] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. FDP_RIP.1[APDU] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 133 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FDP_RIP.1[bArray] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. FDP_RIP.1[KEYS] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. FDP_RIP.1[TRANSIENT] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. FDP_RIP.1[ADEL] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. FDP_RIP.1[ODEL] Contributes to meet the objective by imposing that the contents of the re-allocated block shall always be cleared before delivering the block. OT.RESOURCES SFR Rationale FAU_ARP.1 Contributes to meet this objective by detecting stack- /memory overflows during execution of applications FDP_ROL.1[FIREWALL] Contributes to meet this objective by preventing that failed installations create memory leaks FMT_MTD.1[JCRE] Contributes to meet this objective since the TSF controls the memory management FMT_MTD.3[JCRE] Contributes to meet this objective since the TSF controls the memory management FMT_SMF.1 Contributes to meet this objective since the TSF controls the memory management FMT_SMF.1[ADEL] Contributes to meet this objective since the TSF controls the memory management FMT_SMR.1 Contributes to meet this objective since the TSF controls the memory management FMT_SMR.1[INSTALLER] Contributes to meet this objective since the TSF controls the memory management FMT_SMR.1[ADEL] Contributes to meet this objective since the TSF controls the memory management FPT_RCV.3[INSTALLER] Contributes to meet this objective by preventing that failed installations create memory leaks Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 134 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FPT_FLS.1 Contributes to meet this objective by detecting stack- /memory overflows during execution of applications FPT_FLS.1[INSTALLER] Contributes to meet this objective by detecting stack- /memory overflows during execution of applications FPT_FLS.1[ADEL] Contributes to meet this objective by detecting stack- /memory overflows during execution of applications FPT_FLS.1[ODEL] Contributes to meet this objective by detecting stack- /memory overflows during execution of applications FMT_SMR.1[SD] Contributes to meet this objective since the TSF controls the memory management FMT_SMF.1[SC] Contributes to meet this objective since the TSF controls the memory management 7.3.3 Services OT.ALARM SFR Rationale FAU_ARP.1 Contributes to meet this objective by defining TSF reac- tion upon detection of a potential security violation FPT_FLS.1 Contributes to meet the objective by providing the guar- antee that a secure state is preserved by the TSF when failures occur FPT_FLS.1[INSTALLER] Contributes to meet the objective by providing the guar- antee that a secure state is preserved by the TSF when failures occur FPT_FLS.1[ADEL] Contributes to meet the objective by providing the guar- antee that a secure state is preserved by the TSF when failures occur FPT_FLS.1[ODEL] Contributes to meet the objective by providing the guar- antee that a secure state is preserved by the TSF when failures occur OT.CIPHER SFR Rationale FCS_CKM.1 Covers the objective directly FCS_CKM.2 Covers the objective directly FCS_CKM.3 Covers the objective directly FCS_CKM.4 Covers the objective directly Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 135 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FCS_COP.1 Covers the objective directly FPR_UNO.1 Contributes to meet the objective by controlling the obser- vation of the cryptographic operations which may be used to disclose the keys OT.KEY-MNGT SFR Rationale FCS_CKM.1 Covers the objective directly FCS_CKM.2 Covers the objective directly FCS_CKM.3 Covers the objective directly FCS_CKM.4 Covers the objective directly FCS_COP.1 Covers the objective directly FDP_RIP.1[OBJECTS] Covers the objective directly FDP_RIP.1[ABORT] Covers the objective directly FDP_RIP.1[APDU] Covers the objective directly FDP_RIP.1[bArray] Covers the objective directly FDP_RIP.1[KEYS] Covers the objective directly FDP_RIP.1[TRANSIENT] Covers the objective directly FDP_RIP.1[ADEL] Covers the objective directly FDP_RIP.1[ODEL] Covers the objective directly FDP_SDI.2 Covers the objective directly FPR_UNO.1 Contributes to meet objective by controlling the observa- tion of the cryptographic operations which may be used to disclose the keys OT.PIN-MNGT SFR Rationale FDP_ACC.2[FIREWALL] Contributes to meet the objective by protecting the access to private and internal data of the objects FDP_ACF.1[FIREWALL] Contributes to meet the objective by protecting the access to private and internal data of the objects FDP_RIP.1[OBJECTS] Contributes to meet the objective FDP_RIP.1[ABORT] Contributes to meet the objective FDP_RIP.1[APDU] Contributes to meet the objective FDP_RIP.1[bArray] Contributes to meet the objective FDP_RIP.1[KEYS] Contributes to meet the objective FDP_RIP.1[TRANSIENT] Contributes to meet the objective FDP_RIP.1[ADEL] Contributes to meet the objective Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 136 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FDP_RIP.1[ODEL] Contributes to meet the objective FDP_ROL.1[FIREWALL] Contributes to meet the objective FDP_SDI.2 Contributes to meet the objective FPR_UNO.1 Contributes to meet the objective OT.TRANSACTION SFR Rationale FDP_RIP.1[OBJECTS] Covers the objective directly FDP_RIP.1[ABORT] Covers the objective directly FDP_RIP.1[APDU] Covers the objective directly FDP_RIP.1[bArray] Covers the objective directly FDP_RIP.1[KEYS] Covers the objective directly FDP_RIP.1[TRANSIENT] Covers the objective directly FDP_RIP.1[ADEL] Covers the objective directly FDP_RIP.1[ODEL] Covers the objective directly FDP_ROL.1[FIREWALL] Covers the objective directly 7.3.4 Object Deletion OT.OBJ-DELETION SFR Rationale FDP_RIP.1[ODEL] Contributes to meet the objective FPT_FLS.1[ODEL] Contributes to meet the objective 7.3.5 Applet Management OT.APPLI-AUTH SFR Rationale FCS_COP.1 Refinement: applies to FCS_COP.1[DAP]. Contributes to meet the security objective by ensuring that the loaded Executable Application is legitimate by specifying the al- gorithm to be used in order to verify the DAP signature of the Verification Authority. FDP_ROL.1[CCM] Contributes to meet this security objective by ensures that card management operations may be cleanly aborted. FPT_FLS.1[CCM] Contributes to meet the security objective by preserving a secure state when failures occur. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 137 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public OT.DOMAIN-RIGHTS SFR Rationale FDP_ACC.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FDP_ACF.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_MSA.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_MSA.3[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_SMF.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_SMR.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FTP_ITC.1[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FCO_NRO.2[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FDP_IFC.2[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FDP_IFF.1[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FMT_MSA.1[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 138 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FMT_MSA.3[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FMT_SMF.1[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FIA_UID.1[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FIA_UAU.1[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FIA_UAU.4[SC] Contributes to cover this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. OT.COMM_AUTH SFR Rationale FCS_COP.1 Contributes to meet the security objective by specifying secure cryptographic algorithm that shall be used to de- termine the origin of the card management commands. FMT_SMR.1[SD] Contributes to meet the security objective by specifying the authorized identified roles enabling to send and au- thenticate card management commands. FTP_ITC.1[SC] Contributes to meet the security objective by ensuring the origin of card administration commands. FDP_IFC.2[SC] Contributes to meet the security objective by specifying the authorized identified roles enabling to send and au- thenticate card management commands. FDP_IFF.1[SC] Contributes to meet the security objective by specifying the authorized identified roles enabling to send and au- thenticate card management commands. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 139 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FMT_MSA.1[SC] Contributes to meet the security objective by specifying security attributes enabling to authenticate card manage- ment requests. FMT_MSA.3[SC] Contributes to meet the security objective by specifying security attributes enabling to authenticate card manage- ment requests. FIA_UID.1[SC] Contributes to meet the security objective by specifying the actions that can be performed before authenticating the origin of the APDU commands that the TOE receives. FIA_UAU.1[SC] Contributes to meet the security objective by specifying the actions that can be performed before authenticating the origin of the APDU commands that the TOE receives. OT.COMM_INTEGRITY SFR Rationale FCS_COP.1 Contributes to meet the security objective by by specify- ing secure cryptographic algorithm that shall be used to ensure the integrity of the card management commands. FMT_SMR.1[SD] Contributes to cover this security objective by defining the roles enabling to send and authenticate the card manage- ment requests for which the integrity has to be ensured. FTP_ITC.1[SC] Contributes to meet the security objective by ensuring the integrity of card management commands. FDP_IFC.2[SC] Contributes to cover the security objective by enforcing the Secure Channel Protocol information flow control pol- icy to guarantee the integrity of administration requests. FDP_IFF.1[SC] Contributes to cover the security objective by enforcing the Secure Channel Protocol information flow control pol- icy to guarantee the integrity of administration requests. FMT_MSA.1[SC] Contributes to cover the security objective by specifying security attributes enabling to guarantee the integrity of card management requests. FMT_MSA.3[SC] Contributes to cover the security objective by specifying security attributes enabling to guarantee the integrity of card management requests. FMT_SMF.1[SC] Contributes to meet the security objective by specifying the actions activating the integrity check on the card man- agement commands. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 140 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public OT.COMM_CONFIDENTIALITY SFR Rationale FCS_COP.1 Contributes to meet this objective by specifying secure cryptographic algorithm that shall be used to ensure the confidentiality of the card management commands. FMT_SMR.1[SD] Contributes to cover the security objective by defining the roles enabling to send and authenticate the card manage- ment requests for which the confidentiality has to be en- sured. FTP_ITC.1[SC] Contributes to cover the security objective by ensuring the confidentiality of card management commands. FDP_IFC.2[SC] Contributes to cover the security objective by enforcing the Secure Channel Protocol information flow control pol- icy to guarantee the confidentiality of administration re- quests. FDP_IFF.1[SC] Contributes to cover the security objective by enforcing the Secure Channel Protocol information flow control pol- icy to guarantee the confidentiality of administration re- quests. FMT_MSA.1[SC] Contributes to cover the security objective by specifying security attributes enabling to guarantee the confidential- ity of card management requests by decrypting those re- quests and imposing management conditions on that at- tributes. FMT_MSA.3[SC] Contributes to cover the security objective by specifying security attributes enabling to guarantee the confidential- ity of card management requests by decrypting those re- quests and imposing management conditions on that at- tributes. FMT_SMF.1[SC] Contributes to cover the security objective by specifying the actions ensuring the confidentiality of the card man- agement commands. 7.3.6 Card Management OT.CARD-MANAGEMENT Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 141 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FDP_ACC.2[ADEL] Contributes to meet the objective by the ADEL access control policy which ensures the non-introduction of se- curity holes. The integrity and confidentiality of data that does not belong to the deleted applet or package is a by- product of this policy as well FDP_ACF.1[ADEL] Contributes to meet the objective by the ADEL access control policy which ensures the non-introduction of se- curity holes. The integrity and confidentiality of data that does not belong to the deleted applet or package is a by- product of this policy as well FDP_RIP.1[ADEL] Contributes to meet the objective by ensuring the non- accessibility of deleted data FMT_MSA.1[ADEL] Contributes to meet the objective by enforcing the ADEL access control SFP FMT_MSA.3[ADEL] Contributes to meet the objective by enforcing the ADEL access control SFP FMT_SMR.1[ADEL] Contributes to meet the objective by maintaing the role applet deletion manager FPT_RCV.3[INSTALLER] Contributes to meet the objective by protecting the TSFs against possible failures of the deletion procedures FPT_FLS.1[INSTALLER] Contributes to meet the objective by protecting the TSFs against possible failures of the installer FPT_FLS.1[ADEL] Contributes to meet the objective by protecting the TSFs against possible failures of the deletion procedures FDP_UIT.1[CCM] Contributes to meet the objective by enforcing the Secure Channel Protocol information flow control policy and the Security Domain access control policy which controls the integrity of the corresponding data FDP_ROL.1[CCM] Contributes to meet this security objective by ensures that card management operations may be cleanly aborted. FDP_ITC.2[CCM] Contributes to meet the security objective by enforcing the Firewall access control policy and the Secure Chan- nel Protocol information flow policy when importing card management data. FPT_FLS.1[CCM] Contributes to meet the security objective by preserving a secure state when failures occur. FDP_ACC.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 142 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FDP_ACF.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_MSA.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_MSA.3[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_SMF.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FMT_SMR.1[SD] Contributes to cover this security objective by enforcing a Security Domain access control policy (rules and restric- tions) that ensures a secure card content management. FTP_ITC.1[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FCO_NRO.2[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FDP_IFC.2[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FDP_IFF.1[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FMT_MSA.1[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FMT_MSA.3[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 143 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FMT_SMF.1[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FIA_UID.1[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FIA_UAU.1[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FIA_UAU.4[SC] Contributes to meet this security objective by enforcing Secure Channel Protocol information flow control policy that ensures the integrity and the authenticity of card man- agement operations. FMT_SMR.1[ADEL] 7.3.7 Smart Card Platform OT.SCP.IC SFR Rationale FAU_ARP.1 Contributes to the coverage of the objective by resetting the card session or terminating the card in case of physi- cal tampering. FPR_UNO.1 Contributes to the coverage of the objective by ensuring leakage resistant implementations of the unobservable operations OT.SCP.RECOVERY SFR Rationale FAU_ARP.1 Contributes to the coverage of the objective by ensuring reinitialization of the Java Card System and its data after card tearing and power failure FPT_FLS.1 Contributes to the coverage of the objective by preserving a secure state after failure OT.SCP.SUPPORT Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 144 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FCS_CKM.1 Contributes to meet the objective FCS_CKM.4 Contributes to meet the objective FCS_COP.1 Contributes to meet the objective FDP_ROL.1[FIREWALL] Contributes to meet the objective OT.IDENTIFICATION SFR Rationale FAU_SAS.1[SCP] Covers the objective.The Initialisation Data (or parts of them) are used for TOE identification 7.3.8 SecureBox OT.SEC_BOX_FW SFR Rationale FDP_ACC.2[SecureBox] Contributes to meet the objective by applying access con- trol rules. FDP_ACF.1[SecureBox] Contributes to meet the objective by applying access con- trol rules. FMT_MSA.3[SecureBox] Contributes to meet the objective by enforcing the Secure- Box access control SFP. FMT_MSA.1[SecureBox] Contributes to meet the objective by enforcing the Secure- Box access control SFP. FMT_SMF.1[SecureBox] Contributes to cover this security objective by enforcing the SecureBox access control policy which ensures a sep- aration of the Secure Box from the rest of the TOE. 7.3.9 Random Numbers OT.RND Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 145 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FCS_RNG.1 Covers the objective by providing random numbers of good quality by specifying class DRG.4 of AIS 20. It was chosen to define FCS_RNG.1 explicitly, because Part 2 of the Common Criteria does not contain generic secu- rity functional requirements for Random Number genera- tion. (Note that there are security functional requirements in Part 2 of the Common Criteria, which refer to random numbers. However, they define requirements only for the authentication context, which is only one of the possible applications of random numbers.) 7.3.10 Config Applet OT.CARD-CONFIGURATION SFR Rationale FDP_IFC.2[CFG] Contributes to meet the objective by controlling the ability to modify configuration items. FDP_IFF.1[CFG] Contributes to meet the objective by controlling the ability to modify configuration items. FMT_MSA.3[CFG] Contributes to meet the objective by controlling the ability to modify configuration items. FMT_MSA.1[CFG] Contributes to meet the objective by controlling the ability to modify configuration items. FMT_SMR.1[CFG] Contributes to meet the objective by controlling the ability to modify configuration items. FMT_SMF.1[CFG] Contributes to meet the objective by controlling the ability to modify configuration items. FIA_UID.1[CFG] Contributes to meet the objective by requiring identifica- tion before modifying configuration items. 7.3.11 OS Update Mechanism OT.CONFID-UPDATE-IMAGE.LOAD SFR Rationale FPR_UNO.1 Contributes to the coverage of the objective by ensuring the unobservability of the S.OSU decryption key FIA_UID.1[OSU] Contributes to the coverage of the objective by requiring identification. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 146 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FIA_UAU.1[OSU] Contributes to the coverage of the objective by requiring authentication. OT.AUTH-LOAD-UPDATE-IMAGE SFR Rationale FDP_IFC.2[OSU] Contributes to the coverage of the objective by applying the rules of the Information Flow Control policy. FDP_IFF.1[OSU] Contributes to the coverage of the objective by applying the rules of the Information Flow Control policy. FMT_MSA.3[OSU] Contributes to the coverage of the objective by enforcing restrictive default values for the attributes of the OS Up- date information flow control SFP. FMT_SMR.1[OSU] Contributes to the coverage of the objective by letting S.OSU handle the OS Update procedure. FIA_UID.1[OSU] Contributes to the objective by requiring identification of the authorized images. FIA_UAU.1[OSU] Contributes to the objective by requiring authentication of the authorized images. OT.SECURE_LOAD_ACODE SFR Rationale FDP_IFC.2[OSU] Contributes to the coverage of the objective by ensuring that only allowed versions of the D.UPDATE_IMAGE are accepted and by checking the evidence data of authentic- ity and integrity. FMT_SMR.1[OSU] Contributes to the coverage of the objective by letting S.OSU handle the OS Update procedure. FPT_FLS.1[OSU] Contributes to the coverage of the objective by ensuring a secure state after interruption of the OS Update procedure (Load Phase). FIA_UAU.4[OSU] Contributes to meet the objective by enforcing authenticity and integrity of D.UPDATE_IMAGE (i.e. Additional Code). OT.SECURE_AC_ACTIVATION Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 147 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale SFR Rationale FMT_MSA.1[OSU] Contributes to the coverage of the objective by allowing to modify the Current Sequence Number only after success- ful OS Update procedure. FMT_SMR.1[OSU] Contributes to the coverage of the objective by letting S.OSU handle the OS Update procedure. FMT_SMF.1[OSU] Contributes to the objective by providing information on the currently activated software (Current Sequence Num- ber). FPT_FLS.1[OSU] Contributes to the coverage of the objective by ensuring atomicity of the OS Update procedure (Load Phase). OT.TOE_IDENTIFICATION SFR Rationale FDP_SDI.2 Contributes to cover the objective by storing the identifi- cation data (D.TOE_IDENTIFICATION) in an integrity pro- tected store. FMT_SMF.1[OSU] Contributes to cover the objective by providing the ability to query the identification data (Current Sequence Num- ber, Reference Sequence Number, Final Sequence Num- ber) of the TOE. 7.3.12 Restricted Mode OT.ATTACK-COUNTER SFR Rationale FMT_SMR.1[SD] Contributes to cover the objective by defining the security role ISD. FMT_MSA.3[RM] Contributes to cover the objective by restricting the ini- tial value of the Attack Counter and allowing nobody to change the initial value. FMT_MSA.1[RM] Contributes to cover the objective by only allowing the ISD to modify the Attack Counter. FIA_UAU.1[RM] Contributes to cover the objective by requiring authentica- tion before resetting the Attack Counter. FIA_UID.1[RM] Contributes to cover the objective by requiring identifica- tion before resetting the Attack Counter. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 148 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public OT.RESTRICTED-MODE SFR Rationale FMT_SMR.1[SD] Contributes to cover the objective by defining the security role ISD. FDP_ACC.2[RM] Contributes to the coverage of the objective by defining the subject of the Restricted Mode access control SFP. FDP_ACF.1[RM] Contributes to cover the objective by controlling access to objects for all operations. FMT_SMF.1[RM] Contributes to cover the objective by defining the manage- ment functions of the restricted mode. FIA_UAU.1[RM] Contributes to cover the objective by requiring authentica- tion before resetting the Attack Counter. FIA_UID.1[RM] Contributes to cover the objective by requiring identifica- tion before resetting the Attack Counter. 7.3.13 Factory Reset OT.UDW_AUTH SFR Rationale FDP_ACC.2[UDW] Contributes to the coverage of the objective by defining the subjects, objects and operations of the Factory Reset access control SFP. FDP_ACF.1[UDW] Contributes to cover the objective by only allowing autho- rized applications to trigger the Factory Reset process. OT.UDW_CLEAR SFR Rationale FDP_RIP.1[UDW] Contributes to meet the objective by deleting applets, packages, SDs and their related data without residue. FDP_ACF.1[UDW] Contributes to cover the objective by controlling Clear List modification and data deletion. FMT_MSA.3[UDW] Contributes to cover the objective by restricting the initial value of the Clear List, Trigger Factory Reset Allowed AID and allowing nobody to change the initial value. FMT_MSA.1[UDW] Contributes to cover the objective by only allowing the S.FAR to modify the Clear List. OT.UDW_ATOMIC Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 149 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SFR Rationale FDP_RIP.1[UDW] Contributes to meet the objective by making sure that all data is deleted even if an interrupt occurs. FPT_FLS.1[UDW] Contributes to meet the objective by making the process atomic. 7.4 SFR Dependencies Requirements CC Dependencies Satisfied Dependen- cies FAU_ARP.1 FAU_SAA.1 Potential violation analysis see §7.3.3.1 of [9] FAU_SAS.1[SCP] No other components. FCO_NRO.2[SC] FIA_UID.1 Timing of identification. FIA_UID.1[SC] FCS_CKM.1 [FCS_CKM.2 Cryptographic key distri- bution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction see §7.3.3.1 of [9] FCS_CKM.2 [FDP_ITC.1 Import of user data with- out security attributes, or FDP_ITC.2 Import of user data with security at- tributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Crypto- graphic key destruction see §7.3.3.1 of [9] FCS_CKM.3 [FDP_ITC.1 Import of user data with- out security attributes, or FDP_ITC.2 Import of user data with security at- tributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Crypto- graphic key destruction see §7.3.3.1 of [9] FCS_CKM.4 [FDP_ITC.1 Import of user data with- out security attributes, or FDP_ITC.2 Import of user data with security at- tributes, or FCS_CKM.1 Cryptographic key generation] see §7.3.3.1 of [9] Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 150 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FCS_COP.1 [FDP_ITC.1 Import of user data with- out security attributes, or FDP_ITC.2 Import of user data with security at- tributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Crypto- graphic key destruction. see §7.3.3.1 of [9] FCS_RNG.1 No dependencies FDP_ACC.1[SD] FDP_ACF.1 Security attribute based access control FDP_ACF.1[SD] FDP_ACC.2[FIREWALL] FDP_ACF.1 Security attribute based access control see §7.3.3.1 of [9] FDP_ACC.2[ADEL] FDP_ACF.1 Security attribute based access control see §7.3.3.1 of [9] FDP_ACC.2[SecureBox] FDP_ACF.1 Security attribute based access control FDP_ ACF.1[SecureBox] FDP_ACC.2[RM] FDP_ACF.1 Security attribute based access control FDP_ACF.1[RM] FDP_ACC.2[UDW] FDP_ACF.1 Security attribute based access control FDP_ACF.1[UDW] FDP_ACF.1[FIREWALL] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisa- tion see §7.3.3.1 of [9] FDP_ACF.1[ADEL] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisa- tion see §7.3.3.1 of [9] FDP_ACF.1[SecureBox] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisa- tion FDP_ ACC.2[SecureBox] FMT_ MSA.3[SecureBox] FDP_ACF.1[SD] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisa- tion FDP_ACC.1[SD] FMT_MSA.3[SD] Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 151 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FDP_ACF.1[RM] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisa- tion FDP_ACC.2[RM] FMT_MSA.3[RM] FDP_ACF.1[UDW] FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisa- tion FDP_ACC.2[UDW] FDP_IFC.1[JCVM] FDP_IFF.1 Simple security attributes see §7.3.3.1 of [9] FDP_IFC.2[SC] FDP_IFF.1 Simple security attributes FDP_IFF.1[SC] FDP_IFC.2[OSU] FDP_IFF.1 Simple security attributes FDP_IFF.1[OSU] FDP_IFC.2[CFG] FDP_IFF.1 Simple security attributes FDP_IFF.1[CFG] FDP_IFF.1[JCVM] FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute ini- tialisation see §7.3.3.1 of [9] FDP_IFF.1[SC] FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute ini- tialisation FDP_IFC.2[SC] FMT_MSA.3[SC] FDP_IFF.1[OSU] FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute ini- tialisation FDP_IFC.2[OSU] FMT_MSA.3[OSU] FDP_IFF.1[CFG] FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute ini- tialisation FDP_IFC.2[CFG] FMT_MSA.3[CFG] FDP_ITC.2[CCM] [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_ACC.1[SD] FTP_ITC.1[SC] FDP_RIP.1[OBJECTS] No dependencies. FDP_RIP.1[ABORT] No dependencies. FDP_RIP.1[APDU] No dependencies. FDP_RIP.1[bArray] No dependencies. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 152 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FDP_RIP.1[KEYS] No dependencies. FDP_RIP.1[TRANSIENT] No dependencies. FDP_RIP.1[ADEL] No dependencies. FDP_RIP.1[ODEL] No dependencies. FDP_RIP.1[UDW] No dependencies. FDP_ROL.1[FIREWALL] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] see §7.3.3.1 of [9] FDP_ROL.1[CCM] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_ACC.1[SD] FDP_SDI.2 No dependencies. FDP_UIT.1[CCM] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_ACC.1[SD] FTP_ITC.1[SC] FIA_AFL.1[PIN] FIA_UAU.1 Timing of authentication. see AppNote in FIA_ AFL.1[PIN] FIA_ATD.1[AID] No dependencies. FIA_UID.1[SC] No dependencies. FIA_UID.1[OSU] No dependencies. FIA_UID.1[CFG] No dependencies. FIA_UID.1[RM] No dependencies. FIA_UID.2[AID] No dependencies. FIA_USB.1[AID] FIA_ATD.1 User attribute definition see §7.3.3.1 of [9] FIA_UAU.1[SC] FIA_UID.1 Timing of identification FIA_UID.1[SC] FIA_UAU.1[RM] FIA_UID.1 Timing of identification FIA_UID.1[RM] FIA_UAU.1[OSU] FIA_UID.1 Timing of identification FIA_UID.1[OSU] FIA_UAU.4[SC] No dependencies. FIA_UAU.4[OSU] No dependencies. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 153 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FMT_MSA.1[JCRE] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions see §7.3.3.1 of [9] FMT_MSA.1[JCVM] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions see §7.3.3.1 of [9] FMT_MSA.1[ADEL] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions see §7.3.3.1 of [9] FMT_MSA.1[SC] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_ACC.1[SD] FMT_SMR.1[SD] FMT_SMF.1[SC] FMT_MSA.1[SecureBox] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_ ACC.2[SecureBox] FMT_SMR.1 FMT_ SMF.1[SecureBox] FMT_MSA.1[OSU] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_IFC.2[OSU] FMT_SMR.1[OSU] FMT_SMF.1[OSU] Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 154 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FMT_MSA.1[CFG] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_IFC.2[CFG] FMT_SMR.1[CFG] FMT_SMF.1[CFG] FMT_MSA.1[SD] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_ACC.1[SD] FMT_SMR.1[SD] FMT_SMF.1[SD] FMT_MSA.1[RM] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_ACC.2[RM] FMT_SMR.1[SD] FMT_SMF.1[RM] FMT_MSA.1[UDW] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions FDP_ACC.2[UDW] FMT_SMR.1[SD] FMT_MSA.2[FIREWALL- JCVM] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Manage- ment Functions see §7.3.3.1 of [9] FMT_MSA.3[FIREWALL] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles see §7.3.3.1 of [9] FMT_MSA.3[JCVM] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles see §7.3.3.1 of [9] FMT_MSA.3[ADEL] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles see §7.3.3.1 of [9] FMT_MSA.3[SecureBox] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_ MSA.1[SecureBox] FMT_SMR.1 Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 155 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FMT_MSA.3[OSU] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.1[OSU] FMT_SMR.1[OSU] FMT_MSA.3[CFG] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.1[CFG] FMT_SMR.1[CFG] FMT_MSA.3[SD] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.1[SD] FMT_SMR.1[SD] FMT_MSA.3[SC] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.1[SC] FMT_SMR.1[SD] FMT_MSA.3[RM] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.1[RM] FMT_SMR.1[SD] FMT_MSA.3[UDW] FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.1[UDW] FMT_SMR.1[SD] FMT_MTD.1[JCRE] FMT_SMR.1 Security roles FMT_ SMF.1 Specification of Management Functions see §7.3.3.1 of [9] FMT_MTD.3[JCRE] FMT_MTD.1 Management of TSF data see §7.3.3.1 of [9] FMT_SMF.1 No dependencies. FMT_SMF.1[ADEL] No dependencies. FMT_SMF.1[SecureBox] No dependencies. FMT_SMF.1[OSU] No dependencies. FMT_SMF.1[CFG] No dependencies. FMT_SMF.1[SD] No dependencies. FMT_SMF.1[SC] No dependencies. FMT_SMF.1[RM] No dependencies. FMT_SMR.1 FIA_UID.1 Timing of identification see §7.3.3.1 of [9] FMT_SMR.1[INSTALLER] FIA_UID.1 Timing of identification see §7.3.3.1 of [9] FMT_SMR.1[ADEL] FIA_UID.1 Timing of identification see §7.3.3.1 of [9] FMT_SMR.1[OSU] FIA_UID.1 Timing of identification FIA_UID.1[OSU] Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 156 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Requirements CC Dependencies Satisfied Dependen- cies FMT_SMR.1[CFG] FIA_UID.1 Timing of identification FIA_UID.1[CFG] FMT_SMR.1[SD] FIA_UID.1 Timing of identification FIA_UID.1[SC] FPR_UNO.1 No dependencies. FPT_FLS.1 No dependencies. FPT_FLS.1[INSTALLER] No dependencies. FPT_FLS.1[ADEL] No dependencies. FPT_FLS.1[ODEL] No dependencies. FPT_FLS.1[OSU] No dependencies. FPT_FLS.1[CCM] No dependencies. FPT_FLS.1[UDW] No dependencies. FPT_TDC.1 No dependencies. FPT_RCV.3[INSTALLER] AGD_OPE.1 Operational user guid- ance see §7.3.3.1 of [9] FTP_ITC.1[SC] No dependencies. ADV_SPM.1 ADV_FSP.4 Complete functional spec- ification see §7.3.3.1 of [9] Tab. 7.44: SFRs Dependencies 7.4.1 Rationale for Exclusion of Dependencies The dependency FIA_UID.1 of FMT_SMR.1[INSTALLER] is unsupported. This ST does not require the iden- tification of the "installer" since it can be considered as part of the TSF. The dependency FIA_UID.1 of FMT_SMR.1[ADEL] is unsupported. This ST does not require the identification of the "deletion manager" since it can be considered as part of the TSF. The dependency FMT_SMF.1 of FMT_MSA.1[JCRE] is unsupported. The dependency between FMT_MSA.1[JCRE] and FMT_SMF.1 is not satisfied because no management functions are required for the Java Card RE. The dependency FAU_SAA.1 of FAU_ARP.1 is unsupported. The dependency of FAU_ARP.1 on FAU_SAA.1 assumes that a "potential security violation" generates an audit event. On the contrary, the events listed in FAU_ ARP.1 are self-contained (arithmetic exception, ill-formed bytecodes, access failure) and ask for a straightforward reaction of the TSFs on their occurrence at runtime. The JCVM or other components of the TOE detect these events during their usual working order. Thus, there is no mandatory audit recording in this ST. The dependency FIA_UAU.1 of FIA_AFL.1[PIN] is unsupported. The TOE implements the firewall access control SFP, based on which access to the object Implementing FIA_AFL.1[PIN] is organized. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 157 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public The dependency FMT_SMF.1 of FMT_MSA.1[UDW] is unsupported. The TOE does not implement any other management functions than modification of S.FAR which is already covered by FMT_MSA.1[UDW]. 7.5 Security Assurance Requirements Rationale The selection of assurance components is based on the underlying PP [9]. The Security Target uses the augmen- tations from the PP, chooses EAL6 and adds the components ASE_TSS.2 and ALC_FLR.1. The rationale for the augmentations is the same as in the PP. The assurance level EAL6 is an elaborated pre-defined level of the CC, part 3 [5]. The assurance components in an EAL level are chosen in a way that they build a mutually supportive and complete set of components. The additional requirements chosen for augmentation do not add any dependencies, which are not already fulfilled for the corresponding requirements contained in EAL6. Therefore, the components ASE_TSS.2 and ALC_FLR.1 add additional assurance to EAL6, but the mutual support of the requirements is still guaranteed. All components required for EAL6 are already met by the augmentations on the underlying hardware apart from SPM. As the SPM for this TOE is independent of the Hardware, then the requirements for EAL6 composition are met. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 158 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 8 TOE summary specification (ASE_TSS) 8.1 Introduction The Security Functions (SF) introduced in this section realize the SFRs of the TOE. See Table 8.1 for list of all Security Functions. Each SF consists of components spread over several TOE modules to provide a security functionality and fulfill SFRs. 8.2 Security Functionality Name Title SF.JCVM Java Card Virtual Machine SF.CONFIG Configuration Management SF.OPEN Card Content Management SF.CRYPTO Cryptographic Functionality SF.RNG Random Number Generator SF.DATA_STORAGE Secure Data Storage SF.OSU Operating System Update SF.UDW Factory Reset SF.OM Java Object Management SF.MM Memory Management SF.PIN PIN Management SF.PERS_MEM Persistent Memory Management SF.EDC Error Detection Code API SF.HW_EXC Hardware Exception Handling SF.RM Restricted Mode SF.PID Platform Identification SF.ACC_SBX Secure Box Tab. 8.1: Overview of Security Functionality SF.JCVM Java Card Virtual Machine SF.JCVM provides the Java Card Virtual Machine including byte code interpretation and the Java Card Firewall according to the specifications [34, 35]. This fulfills the SFRs FDP_IFC.1[JCVM], FDP_IFF.1[JCVM], FMT_SMF.1, FMT_SMR.1, FDP_ROL.1[FIREWALL], FDP_ACF.1[FIREWALL], FDP_ACC.2[FIREWALL] and FIA_UID.2[AID]. SF.JCVM supports FAU_ARP.1 and FPT_FLS.1 by throwing Java Exceptions according to these specifications. Additionally it supports these SFRs by verification of the integrity of used Java object headers. Security attributes in SF.JCVM are separated from user data and not accessible by applets Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 159 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public to fulfill FMT_MSA.1[JCRE] and FMT_MSA.1[JCVM]. All values for security attributes are ini- tialized and assigned by the system itself which fulfills FMT_MSA.2[FIREWALL-JCVM], FMT_ MSA.3[FIREWALL], and FMT_MSA.3[JCVM]. SF.JCVM ensures together with SF.PERS_MEM that the system is halted in case non existing Java objects could be referenced after an aborted transaction to fulfill FDP_RIP.1[ABORT]. SF.CONFIG Configuration Management SF.CONFIG provides means to store Initialization Data and Pre-personalization Data before TOE delivery FAU_SAS.1[SCP]. SF.CONFIG provides means to change configurations of the card. Some configurations can be changed by the customer and some can only be changed by NXP (FDP_IFC.2[CFG], FDP_ IFF.1[CFG], FMT_MSA.3[CFG], FMT_MSA.1[CFG], FMT_SMR.1[CFG], FMT_SMF.1[CFG], FIA_ UID.1[CFG]). SF.CONFIG supports FCS_COP.1 by configuring the behavior of cryptographic op- erations. Additionally, SF.CONFIG provides proprietary commands to select (FIA_UID.1[SC]) the OS up- date mechanism SF.OSU and to reset the OS to an initial state (FAU_ARP.1 and FPT_FLS.1). SF.OPEN Card Content Management SF.OPEN provides the card content management functionality according the GlobalPlatform Specification [22] and GlobalPlatform Amendments A [20], D [30], E [31] and F [32]. This sup- ports FCO_NRO.2[SC], FDP_ACC.1[SD], FDP_ACF.1[SD], FDP_UIT.1[CCM], FDP_IFF.1[SC], FDP_IFC.2[SC], FIA_UID.1[SC], FIA_UID.2[AID], FIA_USB.1[AID], FMT_MSA.1[SC], FMT_MSA.1[SD], FMT_MSA.3[SC], FMT_MSA.3[SD], FMT_SMF.1[ADEL], FMT_SMR.1[SD], FMT_SMF.1[SC], FMT_ SMF.1[SD], FTP_ITC.1[SC], FMT_MSA.3[ADEL], FMT_SMR.1[INSTALLER], FMT_SMR.1[ADEL], FDP_ITC.2[CCM], FDP_ROL.1[CCM], FIA_UAU.1[SC], FIA_UAU.4[SC], FTP_ITC.1[SC] and FCS_ COP.1 (for DAP verification). In addition to the GP specification, the Java Card Runtime Envi- ronment specification [34] is followed to support FDP_ACC.2[ADEL], FDP_ACF.1[ADEL], FMT_ MSA.3[SC], FMT_MSA.3[SD], FMT_MTD.1[JCRE], FMT_MTD.3[JCRE], FPT_FLS.1[INSTALLER], FDP_RIP.1[bArray], FDP_RIP.1[ADEL], FPT_TDC.1, FPT_FLS.1[ADEL], and FPT_FLS.1[CCM] for application loading, installation, and deletion. AID management is provided by SF.OPEN according to the GlobalPlatform Specification [22], the Java Card Runtime Environment Specification [34], and the Java Card API Specification [33] to support FIA_ATD.1[AID]. SF.OPEN is part of the TOE runtime environment and thus separated from other applications to fulfill FMT_MSA.1[ADEL]. It supports FAU_ARP.1 and FPT_FLS.1 by responding with error messages and fulfills FPT_RCV.3[INSTALLER] by inherent memory cleanup in case of aborted loading and installation. SF.CRYPTO Cryptographic Functionality Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 160 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SF.CRYPTO provides key creation, key management, key deletion and cryptographic function- ality. It provides the API in accordance to the Java Card API Specification [33] to fulfill FCS_ CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, and FCS_COP.1. Proprietary solutions (e.g., key lengths not supported by the Java Card API) are supported following the Java Card API. SF.CRYPTO uses SF.DATA_STORAGE to support FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FDP_RIP.1[KEYS], and FDP_SDI.2. The Security Software certified with the TOE hardware supports FCS_COP.1 and FPR_UNO.1. SF.RNG Random Number Generator SF.RNG provides secure random number generation to fulfill FCS_CKM.1 and FCS_RNG.1. Random numbers are generated by the Security Software certified with the TOE hardware. SF.RNG provides an API according to the Java Card API Specification [33] to generate random numbers according to FCS_RNG.1. SF.DATA_STORAGE Secure Data Storage SF.DATA_STORAGE provides a secure data storage for confidential data. It is used to store cryptographic keys (supports FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, and FCS_CKM.4) and to store PINs (supports FIA_AFL.1[PIN]). All data stored by SF.DATA_STORAGE is CRC32 integrity protected to fulfill FDP_SDI.2, FAU_ARP.1, and FPT_FLS.1. The stored data is AES encrypted to fulfill FPR_UNO.1. SF.OSU Operating System Update SF.OSU provides secure functionality to update the JCOP4 OS or UpdaterOS itself with an im- age created by a trusted off-card entity (FMT_SMR.1[OSU], FMT_SMF.1[OSU]). SF.OSU allows an authenticated OSU command (FIA_UAU.4[OSU]) to upload an integrity and confidentiality protected update image to update to another operating system version(FDP_IFC.2[OSU], FDP_ IFF.1[OSU]). User authentication is based on the verification of signed OSU commands to fulfill FIA_UAU.1[OSU] and FIA_UID.1[OSU]. Integrity protection of OSU commands uses ECDSA, SHA-256 and CRC verification to fulfill FDP_IFF.1[OSU]. Confidentiality of the update image is ensured by ECDH and AES encryption to fulfill FDP_IFF.1[OSU]. SF.OSU ensures that the system stays in a secure state in case of invalid or aborted update procedures to fulfill FPT_FLS.1[OSU] and ensures that the information identifying the currently running OS is modified and the updated code is activated only after successfull OS Update procedure FMT_MSA.3[OSU], FMT_MSA.1[OSU]. SF.UDW Factory Reset SF.UDW provides secure functionality to delete user related data such as applets, packages, SDs and their related data. All user applets, packages, SDs and their related data are deleted Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 161 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public if listed in the Clear List which is fulfilled by FDP_RIP.1[UDW]. The modification of the Clear List is controlled by FDP_ACC.2[UDW], FDP_ACF.1[UDW], FMT_MSA.3[UDW]FMT_MSA.1[UDW] and FMT_SMR.1[SD]. SF.UDW ensures that the Factory Reset process gets finished even in case it gets interrupted (e.g. by a tearing event.) which is supported by FPT_FLS.1[UDW]. SF.OM Java Object Management SF.OM provides the object management for Java objects which are processed by SF.JCVM. It provides object creation (FDP_RIP.1[OBJECTS]) and garbage collection according to the Java Card Runtime Environment Specification [34] to fulfill FDP_RIP.1[ODEL] and FPT_FLS.1[ODEL]. SF.OM throws an Java Exception in case an object cannot be created as requested due to too less available memory. This fulfills FAU_ARP.1 and FPT_FLS.1. SF.MM Memory Management SF.MM provides deletion of memory for transient arrays, global arrays, and logical channels according to the Java Card Runtime Environment Specification [34]. Thus, it fulfills FDP_ RIP.1[TRANSIENT] by granting access to and erasing of CLEAR_ON_RESET and CLEAR_ON_ DESELECT transient arrays. It supports FIA_ATD.1[AID] when using logical channels and it ful- fills FDP_RIP.1[APDU] and FDP_RIP.1[bArray] by clearing the APDU buffers for new incoming data and by clearing the bArray during application installation. SF.PIN PIN Management SF.PIN provides secure PIN management by using SF.DATA_STORAGE for PIN objects speci- fied in the Java Card API Specification [33] and the GlobalPlatform Specification [24]. Thus, it fulfills FDP_SDI.2, FIA_AFL.1[PIN], and FPR_UNO.1. SF.PERS_MEM Persistent Memory Management SF.PERS_MEM provides atomic write operations and transaction management according to the Java Card Runtime Environment Specification [34]. This supports FAU_ARP.1, FPT_FLS.1, and FDP_ROL.1[FIREWALL]. SF.PERS_MEM supports FDP_RIP.1[ABORT] together with SF.JCVM by halting the system in case of object creation in aborted transactions. Low level write routines to persistent memory in SF.PERS_MEM perform checks for defect mem- ory cells to fulfill FAU_ARP.1 and FPT_FLS.1. SF.EDC Error Detection Code API SF.EDC provides an Java API for user applications to perform high performing integrity checks based on a checksum on Java arrays [10]. The API throws a Java Exception in case the check- sum in invalid. This supports FAU_ARP.1 and FPT_FLS.1. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 162 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public SF.HW_EXC Hardware Exception Handling SF.HW_EXC provides software exception handler to react on unforeseen events captured by the hardware (hardware exceptions). SF.HW_EXC catches the hardware exceptions and ensures the system goes to a secure state to fulfill FAU_ARP.1 and FPT_FLS.1. SF.RM Restricted Mode SF.RM provides a restricted mode that is entered when the Attack Counter reaches its limit. In restricted mode only limited functionality is available. Only the issuer is able to reset the Attack Counter to leave the restricted mode. This supports FDP_ACC.2[RM], FDP_ACF.1[RM], FMT_ MSA.3[RM], FMT_MSA.1[RM], and FMT_SMF.1[RM]. SF.RM only allows a limited set of opera- tions to not identified and not authenticated users when in restricted mode. All other operations require identification and authentication(FIA_UID.1[RM], FIA_UAU.1[RM]). SF.PID Platform Identification SF.PID provides a platform identifier. For elements that can be identified see 1.9. This feature supports FAU_SAS.1.1[SCP] by using initialization data that is used for platform identification. SF.ACC_SBX Secure Box SF.ACC_SBX provides an environment to securely execute native code from third parties. SF.ACC_ SBX ensures that only program code and data contained in the secure box can be accessed from within this secure box and therefore cannot harm, manipulate, or influence other parts of the TOE. This fulfills the SFRs FDP_ACC.2[SecureBox], FDP_ACF.1[SecureBox] and FMT_ MSA.1[SecureBox]. Native code executed in the Secure Box is executed in Application Unprivileged Mode. Access to the CPU mode, memory outside the Secure Box, the MMU segment table, and Special Function Registers which allow configuration of the MMU and allow System Management is prohibited for code executed in the Secure Box to fulfill FDP_ACF.1[SecureBox]. The MMU segment table to configure the MMU is part of the Secure Box which fulfils FMT_ MSA.3[SecureBox]. This MMU segment table can be modified during the prepersonalization in accordance with FMT_MSA.3[SecureBox] to specify alternative settings for initially restrictive values for the MMU segment table. This supports FMT_SMF.1[SecureBox]. 8.3 Protection against Interference and Logical Tampering The protection of JCOP4 against Interference and Logical Tampering is implemented in software within the TOE and supported by the hardware of the micro controller. The software protection of the TOE makes use of software security services which allow to detect and react on manipulation of the TOE. Two types of reactions are used: If invalid data from outside the TOE is detected then it Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 163 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public is assumed that the TOE was used in a wrong way. This is indicated by an appropriate Status Word or Exception. Detected deviations from the physical operating conditions and inconsistencies of internal states and program flow however are considered to be an attack to the TOE. In such cases an internal Attack Counter is increased. Once the Attack Counter reaches the maximum value, the TOE will go into Restricted Mode. Typical software security mechanisms implemented in the TOE are e.g.: • Complex patterned values are used instead of boolean values which are sensible to tampering (only one bit needs to be changed to manipulate a false into a true). • Small random delays are inserted in the program flow to make successful physical interfering more difficult. • Secret information like Keys or PINs are stored encrypted in the TOE. The Masterkey to decrypt these is not accessible during normal operation. • Critical data is read after it has been written to non volatile memory. • Enhanced cryptographic support is based on the certified Security Software for DES, AES, ECC and RSA including protection against fault injection and random number generation. • Critical values (like PINs) are compared timing-invariant. This prevents from side channel attacks. A full list of software countermeasures is contained in ADV_ARC. Further protection against Tampering and Logical Interference is realized by the MMU implemented in hardware. The MMU is able to perform access control to all types of memory. The special function registers access can be restricted by the bridges between the CPU and the peripherals. JCOP4 defines several MMU contexts which restrict access to memory areas. The Master key is stored in specific coprocessor registers and blocked for reading/writing during JCOP operation. Additionally Interference and Logical Tampering is prevented by hardware security services. JCOP4 OS runs on a certified smart card HW platform which protects against bypass by physical and logical means such as: • cryptographic coprocessors (for symmetric and asymmetric cryptography) protected against DPA and DFA, • enhanced security sensors for clock frequency range, low and high temperature sensor, supply voltage sensors Single Fault Injection (SFI) attack detection, light sensors, and • encryption of data stored in persistent and transient memory. 8.4 Protection against Bypass of Security Related Actions JCOP4 prevents bypassing security related actions by several software counter measures. Different mechanisms are used depending on the software environment. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 164 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public Generally all input parameter are validated and in case of incorrect parameters the program flow is interrupted. Such event is indicated by an appropriate Status Word or Exception. This prevents the TOE from being attacked by undefined or unauthorized commands or data. Basic protection is contributed by implementation of following standards within the TOE: • Java Applets are separated from each other as defined in the Java Card specifications [33, 34, 35]. The separation is achieved by implementation of the firewall which prevents Applets to access data belonging to a different Java Card context. Sharing information between different contexts is possible by supervision of the well defined Java Card Firewall mechanism implemented in the TOE. • Access to security relevant Applications in the TOE (like Security Domains) is protected by the Secure Channel mechanism defined by Global platform [24]. The secure channel allows access to Applications only if the secret keys are known. Further protection implemented in JCOP4 prevents brute force attacks to the secret keys of the Secure Channel. The following mechanisms ensure that it is not possible to access information from the Java Layer without being authorized to do so. • Status informations like Life Cycle of Applets or the Authentication State of a Secure Channel are stored in complex patterned values which protects them from manipulation. • Correct order of Java Card Byte Code execution is ensured by the Virtual Machine which detects if Byte Code of a wrong context is executed. • Correct processing of Byte Codes is ensured by checking at the beginning and end of Byte Code execution that the same Byte Code is executed. Execution of native code in JCOP4 is protected by following mechanisms: • Critical execution paths of the TOE functionality are protected by program flow and call tree protection. This ensures that it is not possible to bypass security relevant checks and verifications. • Critical conditions are evaluated twice. This ensures that physical attacks on the compared values are detected during security relevant checks and verifications. • The true case in if-conditions leads to the less critical program flow or to an error case. This prevents attacks on the program flow during security relevant checks and verifications. • At the exit of critical loops it is checked that the whole loop was processed. This prevents from manipulation of the program flow and jumping out of the loop. • Critical parameters are check for consistency. This prevents from attacks with manipulated parameters. Further protection is achieved by using different buffers for APDUs in case more than one physical interface is supported. This prevents bypassing the state machine on one physical interface by the other interface. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 165 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 9 Contents 1 ST Introduction (ASE_INT) 2 1.1 ST Reference and TOE Reference . . . . . 2 1.2 TOE Overview . . . . . . . . . . . . . . . . 2 1.2.1 Usage and Major Security Features of the TOE . . . . . . . . . . . . . . . . . . . 4 1.2.2 TOE Type . . . . . . . . . . . . . . . . . . 5 1.2.3 Required non-TOE Hardware/Software/- Firmware . . . . . . . . . . . . . . . . . . 6 1.3 TOE Description . . . . . . . . . . . . . . . 6 1.3.1 TOE Components and Composite Certi- fication . . . . . . . . . . . . . . . . . . . 6 1.3.2 TOE Life Cycle . . . . . . . . . . . . . . . 9 1.3.3 TOE Identification . . . . . . . . . . . . . 13 1.3.4 Evaluated Package Types . . . . . . . . . 14 2 Conformance Claims (ASE_CCL) 15 2.1 CC Conformance Claim . . . . . . . . . . . 15 2.2 Package Claim . . . . . . . . . . . . . . . . 15 2.3 PP Claim . . . . . . . . . . . . . . . . . . . 15 2.4 Conformance Claim Rationale . . . . . . . 16 2.4.1 TOE Type . . . . . . . . . . . . . . . . . . 16 2.4.2 SPD Statement . . . . . . . . . . . . . . . 16 2.4.3 Security Objectives Statement . . . . . . 18 2.4.4 Security Functional Requirements State- ment . . . . . . . . . . . . . . . . . . . . . 21 3 Security Aspects 24 3.1 Confidentiality . . . . . . . . . . . . . . . . 24 3.2 Integrity . . . . . . . . . . . . . . . . . . . . 24 3.3 Unauthorized Executions . . . . . . . . . . 25 3.4 Bytecode Verification . . . . . . . . . . . . . 26 3.5 Card Management . . . . . . . . . . . . . . 26 3.6 Services . . . . . . . . . . . . . . . . . . . . 28 3.7 Config Applet . . . . . . . . . . . . . . . . . 30 3.8 OS Update . . . . . . . . . . . . . . . . . . 30 3.9 Restricted Mode . . . . . . . . . . . . . . . 30 3.10 Factory Reset . . . . . . . . . . . . . . . . . 31 4 Security Problem Definition (ASE_SPD) 32 4.1 Assets . . . . . . . . . . . . . . . . . . . . . 32 4.1.1 User Data . . . . . . . . . . . . . . . . . . 32 4.1.2 TSF Data . . . . . . . . . . . . . . . . . . 33 4.2 Threats . . . . . . . . . . . . . . . . . . . . 34 4.2.1 Confidentiality . . . . . . . . . . . . . . . 34 4.2.2 Integrity . . . . . . . . . . . . . . . . . . . 34 4.2.3 Identity Usurpation . . . . . . . . . . . . . 35 4.2.4 Unauthorized Execution . . . . . . . . . . 36 4.2.5 Denial of Service . . . . . . . . . . . . . . 36 4.2.6 Card Management . . . . . . . . . . . . . 36 4.2.7 Services . . . . . . . . . . . . . . . . . . 37 4.2.8 Miscellaneous . . . . . . . . . . . . . . . 37 4.2.9 Random Numbers . . . . . . . . . . . . . 37 4.2.10 Config Applet . . . . . . . . . . . . . . . . 38 4.2.11 OS Update . . . . . . . . . . . . . . . . . 38 4.2.12 Secure Box . . . . . . . . . . . . . . . . . 38 4.2.13 Restricted Mode . . . . . . . . . . . . . . 38 4.2.14 Factory Reset . . . . . . . . . . . . . . . 39 4.3 Organisational Security Policies . . . . . . 39 4.4 Assumptions . . . . . . . . . . . . . . . . . 40 Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 166 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 5 Security Objectives 42 5.1 Security Objectives for the TOE . . . . . . . 42 5.1.1 Identification . . . . . . . . . . . . . . . . 42 5.1.2 Execution . . . . . . . . . . . . . . . . . . 42 5.1.3 Services . . . . . . . . . . . . . . . . . . 43 5.1.4 Object Deletion . . . . . . . . . . . . . . . 43 5.1.5 Applet Management . . . . . . . . . . . . 43 5.1.6 Card Management . . . . . . . . . . . . . 44 5.1.7 Smart Card Platform . . . . . . . . . . . . 45 5.1.8 SecureBox . . . . . . . . . . . . . . . . . 46 5.1.9 Random Numbers . . . . . . . . . . . . . 46 5.1.10 OS Update Mechanism . . . . . . . . . . 46 5.1.11 Config Applet . . . . . . . . . . . . . . . . 47 5.1.12 Restricted Mode . . . . . . . . . . . . . . 47 5.1.13 Factory Reset . . . . . . . . . . . . . . . 48 5.2 Security Objectives for the Operational En- vironment . . . . . . . . . . . . . . . . . . . 48 5.3 Security Objectives Rationale . . . . . . . . 50 5.3.1 Threats . . . . . . . . . . . . . . . . . . . 53 5.3.2 Organisational Security Policies . . . . . 64 5.3.3 Assumptions . . . . . . . . . . . . . . . . 66 6 Extended Components Definition (ASE_ECD) 68 6.1 Definition of Family ”Generation of random numbers (FCS_RNG)” . . . . . . . . . . . . 68 6.1.1 Family behavior . . . . . . . . . . . . . . 68 6.2 Definition of Family ”Audit Data Storage (FAU_SAS)” . . . . . . . . . . . . . . . . . . 69 6.2.1 Family behavior . . . . . . . . . . . . . . 69 7 Security Requirements (ASE_REQ) 70 7.1 Security Functional Requirements . . . . . 76 7.1.1 COREG_LC Security Functional Re- quirements . . . . . . . . . . . . . . . . . 76 7.1.2 INSTG Security Functional Requirements 96 7.1.3 ADELG Security Functional Requirements 98 7.1.4 RMIG Security Functional Requirements 102 7.1.5 ODELG Security Functional Requirements102 7.1.6 CarG Security Functional Requirements . 103 7.1.7 Further Security Functional Requirements 113 7.1.8 SecureBox Security Functional Require- ments . . . . . . . . . . . . . . . . . . . . 114 7.1.9 Configuration Security Functional Re- quirements . . . . . . . . . . . . . . . . . 117 7.1.10 OS Update Security Functional Require- ments . . . . . . . . . . . . . . . . . . . . 120 7.1.11 Restricted Mode Security Functional Re- quirements . . . . . . . . . . . . . . . . . 123 7.1.12 Factory Reset . . . . . . . . . . . . . . . 126 7.2 Security Assurance Requirements . . . . . 128 7.3 Security Requirements Rationale for the TOE129 7.3.1 Identification . . . . . . . . . . . . . . . . 129 7.3.2 Execution . . . . . . . . . . . . . . . . . . 130 7.3.3 Services . . . . . . . . . . . . . . . . . . 135 7.3.4 Object Deletion . . . . . . . . . . . . . . . 137 7.3.5 Applet Management . . . . . . . . . . . . 137 7.3.6 Card Management . . . . . . . . . . . . . 141 7.3.7 Smart Card Platform . . . . . . . . . . . . 144 7.3.8 SecureBox . . . . . . . . . . . . . . . . . 145 7.3.9 Random Numbers . . . . . . . . . . . . . 145 7.3.10 Config Applet . . . . . . . . . . . . . . . . 146 7.3.11 OS Update Mechanism . . . . . . . . . . 146 7.3.12 Restricted Mode . . . . . . . . . . . . . . 148 7.3.13 Factory Reset . . . . . . . . . . . . . . . 149 Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 167 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 7.4 SFR Dependencies . . . . . . . . . . . . . 150 7.4.1 Rationale for Exclusion of Dependencies 157 7.5 Security Assurance Requirements Rationale158 8 TOE summary specification (ASE_TSS) 159 8.1 Introduction . . . . . . . . . . . . . . . . . . 159 8.2 Security Functionality . . . . . . . . . . . . 159 8.3 Protection against Interference and Logi- cal Tampering . . . . . . . . . . . . . . . . . 163 8.4 Protection against Bypass of Security Re- lated Actions . . . . . . . . . . . . . . . . . 164 9 Contents 166 10 Glossary 169 11 Acronyms 173 12 Bibliography 175 13 Legal information 178 13.1 Definitions . . . . . . . . . . . . . . . . . . . 178 13.2 Disclaimers . . . . . . . . . . . . . . . . . . 178 13.3 Licenses . . . . . . . . . . . . . . . . . . . 178 13.4 Patents . . . . . . . . . . . . . . . . . . . . 179 13.5 Trademarks . . . . . . . . . . . . . . . . . . 179 Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 168 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 10 Glossary Additional Code Code activated by the Atomic Activation on the Initial TOE to generate the final TOE. For in- stance, Additional Code could: correct flaws, add new functionalities, update the operating system. Also referred to as D.UPDATE_IMAGE. APDU buffer The APDU buffer is the buffer where the messages sent (received) by the card depart from (ar- rive to). The JCRE owns an APDU object (which is a JCRE Entry Point and an instance of the javac- ard.framework.APDU class) that encapsulates APDU messages in an internal byte array, called the APDU buffer. This object is made accessible to the currently selected applet when needed, but any permanent access (out-of selection-scope) is strictly prohibited for security reasons. applet deletion manager The on-card component that embodies the mechanisms necessary to delete an applet or library and its associated data on smart cards using Java Card technology. Atomic Activation The Loader guarantees at activation time that the loaded Additional Code is activated and that the Identification Data of the TOE is updated. This functionality is called Atomic Activation. If the Atomic Activation is successful, then the resulting product is the Final TOE, otherwise (in case of interruption or incident which prevents the forming of the Final TOE), the Initial TOE shall remain in its initial state or fail secure. context A context is an object-space partition associated to a package. Applets within the same Java technology- based package belong to the same context. The firewall is the boundary between contexts (see "current context"). current context The JCRE keeps track of the current Java Card System context (also called "the active context"). When a virtual method is invoked on an object, and a context switch is required and permitted, the current context is changed to correspond to the context of the applet that owns the object. When that method returns, the previous context is restored. Invocations of static methods have no effect on the current context. The current context and sharing status of an object together determine if access to an object is permissible. currently selected applet The applet has been selected for execution in the current session. The Java Card RE keeps track of the currently selected Java Card applet. Upon receiving a SELECT command from the CAD or PCD with this applet’s AID, the Java Card RE makes this applet the currently selected applet over the I/O interface that received the command. The Java Card RE sends all further APDU commands received over each interface to the currently selected applet on this interface ([34], Glossary). Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 169 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public default applet The applet that is selected after a card reset ([34], §4.1). Final TOE The Final TOE is generated from the Initial TOE and the Additional Code. It is the resulting product of the Atomic Activation of the Additional Code onto the Initial TOE.. Initial TOE The Initial TOE is the product on which the Additional Code is loaded and with the Loader as part of the embedded software. installer The installer is the on-card application responsible for the installation of applets on the card. It may per- form (or delegate) mandatory security checks according to the card issuer policy (for bytecode-verification, for instance), loads and link packages (CAP file(s)) on the card to a suitable form for the Java Card VM to execute the code they contain. It is a subsystem of what is usually called “card manager”; as such, it can be seen as the portion of the card manager that belongs to the TOE. The installer has an AID that uniquely identifies him, and may be implemented as a Java Card applet. However, it is granted specific privileges on an implementation-specific manner ([34], §10). interface A special kind of Java programming language class, which declares methods, but provides no imple- mentation for them. A class may be declared as being the implementation of an interface, and in this case must contain an implementation for each of the methods declared by the interface (See also shareable interface). Java Card RE The runtime environment under which Java programs in a smart card are executed. It is in charge of all the management features such as applet lifetime, applet isolation, object sharing, applet loading, applet initializing, transient objects, the transaction mechanism and so on. Java Card RE Entry Point An object owned by the Java Card RE context but accessible by any application. These methods are the gateways through which applets request privileged Java Card RE services: the instance methods associated to those objects may be invoked from any context, and when that occurs, a context switch to the Java Card RE context is performed. There are two categories of Java Card RE Entry Point Objects: Temporary ones and Permanent ones. As part of the firewall functionality, the Java Card RE detects and restricts attempts to store references to these objects. Java Card RMI Java Card Remote Method Invocation is the Java Card System version 2.2 and 3 Classic Edition mechanism enabling a client application running on the CAD platform to invoke a method on a remote object Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 170 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public on the card. Notice that in Java Card System, version 2.1.1, the only method that may be invoked from the CAD is the process method of the applet class and that in Java Card System, version 3 Classic Edition, this functionality is optional. Java Card System Java Card System includes the Java Card RE, the Java Card VM, the Java Card API and the installer. Java Card VM The embedded interpreter of bytecodes. The Java Card VM is the component that enforces separation between applications (firewall) and enables secure data sharing. Load Phase The Load Phase is starting at the beginning of the Additional Code loading and ending at the end of Atomic Activation. During the Load Phase, the Initial TOE shall be in a secure state.. Loader The Loader is the software developed by the Product Manufacturer. It is used to load and activate the Additional Code into the Product FLASH or EEPROM memory. The Loader is included in the embedded software and is considered as part of the Initial TOE. see also UpdaterOS. logical channel A logical link to an application on the card. A new feature of the Java Card System, version 2.2 and 3 Classic Edition, that enables the opening of simultaneous sessions with the card, one per logical channel. Commands issued to a specific logical channel are forwarded to the active applet on that logical channel. Java Card platform, version 2.2.2 and 3 Classic Edition, enables opening up to twenty logical channels over each I/O interface (contacted or contactless). MC FW Microcontroller Firmware. Firmware for booting and low level functionality of the Micro Controller. NVRAM Non-Volatile Random Access Memory, a type of memory that retains its contents when power is turned off. object deletion The Java Card System version 2.2 and 3 Classic Edition mechanism ensures that any unrefer- enced persistent (transient) object owned by the current context is deleted. The associated memory space is recovered for reuse prior to the next card reset. OS Update OS Update process/mechanism of JCOP4. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 171 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public package A package is a namespace within the Java programming language that may contain classes and inter- faces. A package defines either a user library, or one or more applet definitions. A package is divided in two sets of files: export files (which exclusively contain the public interface information for an entire package of classes, for external linking purposes; export files are not used directly in a Java Card virtual machine) and CAP files. Secure Box The Secure Box is a construct which allows to run non certified third party native code and ensures that this code cannot harm, influence or manipulate the JCOP operating system or any of the applets executed by the operating system. Secure Box Native Library The Secure Box Native Library is non certified third party native code running in the Secure Box. shareable interface An interface declaring a collection of methods that an applet accepts to share with other applets. These interface methods can be invoked from an applet in a context different from the context of the object implementing the methods, thus “traversing” the firewall. subject An active entity within the TOE that causes information to flow among objects or change the system’s status. It usually acts on the behalf of a user. Objects can be active and thus are also subjects of the TOE. transient object An object whose contents are not preserved across CAD sessions. The contents of these objects are cleared at the end of the current CAD session or when a card reset is performed. Writes to the fields of a transient object are not affected by transactions. UpdaterOS OS that implements the OS Update. user Any application interpretable by the Java Card RE. That also covers the packages. The associated sub- ject(s), if applicable, is (are) an object(s) belonging to the javacard.framework.applet class. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 172 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 11 Acronyms AID Application Identifier, an ISO-7816 data format used for unique identification of Java Card applications (and certain kinds of files in card file systems). The Java Card platform uses the AID data format to identify applets and packages. AIDs are administered by the International Standards Organization (ISO), so they can be used as unique identifiers. AIDs are also used in the security policies (see ’Context’ below): applets’ AIDs are related to the selection mechanisms, packages’ AIDs are used in the enforcement of the firewall. Note: although they serve different purposes, they share the same name space. AP Application Provider. applet The name is given to a Java Card technology-based user application. An applet is the basic piece of code that can be selected for execution from outside the card. Each applet on the card is uniquely identified by its AID. APSD Application Provider Security Domain. ARM Advanced RISC Machine. CAD Card Acceptance Device, or card reader. The device where the card is inserted, and which is used to communicate with the card. DFA Differential Fault Analysis, a side channel attack that induces faults into cryptographic implementations, to reveal their internal states.. DPA Differential Power Analysis is a form of side channel attack in which an attacker studies the power consump- tion of a cryptographic hardware device such as a smart card. GP GlobalPlatform. ICV Initial Chaining Vector. ISD Issuer Security Domain. JCOP4 Java Card OpenPlatform Version 4 is the TOE (short for NXP JCOP4.0 on P73N2M0 Secure Smart Card Controller). Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 173 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public JCOP4 OS Java Card OpenPlatform Operating System is the software stack without the MC FW. OS Operating System. OSP Organizational Security Policy. PCD Proximity Coupling Device. The PCD is a contactless card reader device. PICC Proximity Card. The PICC is a card with contactless capabilities. PP Protection Profile. RAM Random Access Memory, is a type of computer memory that can be accessed randomly. RNG Random Number Generator. SCP Smart Card Platform. It is comprised of the integrated circuit, the operating system and the dedicated software of the smart card. SD Security Domain. Security Software Certified Software that consists of Service Software and Crypto Library.. SFR Security Functional Requirement. SIO An object of a class implementing a shareable interface. SPD Security Problem Definition. SSD Supplementary Security Domain. VASD Verification Authority Security Domain. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 174 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 12 Bibliography [1] AIS20/31: A proposal for: Functionality classes for random number generators, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.0, September 18th, 2011. [2] Bundesamt für Sicherheit in der Informationstechnik, Technische Richtlinie - Kryptographische Verfahren: Empfehlungen und Schlüssellängen, 09. Januar 2013, BSI-TR02102. [3] Common Criteria for Information Technology Security Evaluation, Part 1 - Introduction and general model - Version 3.1 CCMB-2012-09-001, Revision 4, September 2012. [4] Common Criteria for Information Technology Security Evaluation, Part 2 - Security functional components, Version 3.1 CCMB-2012-09-002, Revision 4, September 2012. [5] Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-003. [6] Common Criteria Requirements for NXP PN8xy Products, Rev. 1.1, 14 Sept 2017. [7] Common Methodology for Information Technology Security Evaluation - Evaluation Methodology, Version 3.1 CCMB-2012-09-004, Revision 4, September 2012. [8] FIPS 197: ADVANCED ENCRYPTION MISC (AES). http://csrc.nist.gov/publications/fips/ fips197/fips-197.pdf. [9] Java Card Protection Profile - Open Configuration, Version 3.0 (May 2012 - certified ANSSI-PP-2010/03- M01), Published by Oracle, Inc. [10] JCOP 4 P73, User Guidance and Administrator Manual, Rev. 1.4 - 2017-08-24. [11] Joint Interpretation Library, Security requirements for post-delivery code loading, Draft Version 1.0, February 2016. [12] NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007. [13] NXP P73N2M0B0.200 Security Target, Rev. 1.1, 20 December 2017. [14] P73N2M0B0.2C0/2P0, Security Target, Rev. 1.2, 19 March 2018. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 175 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public [15] Security IC Platform Protection Profile, registered and certified by Bundesamt fuer Sicherheit in der Informa- tionstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Rev 1.0, 13 January 2014. [16] The Java Language Specification. Third Edition, May 2005. Gosling, Joy, Steele and Bracha. ISBN 0-321- 24678-0. [17] The Java Virtual Machine Specification. Lindholm, Yellin. ISBN 0-201-43294-3. [18] Java Card System MISC 2.2 Configuration Protection Profile, Version 1.0b, August 2003. [19] Java Card System Protection Profile Collection, Version 1.0b, August 2003. [20] Confidential Card Content Management, GlobalPlatform Card Specification v2.2 - Amendment A v1.0.1, January 2011. [21] ETSI TS 102 622 v11.0.0 Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host Controller Inter- face (HCI), 9 2011. [22] GlobalPlatform Card Specification 2.2.1, GPC_SPE_034, GlobalPlatform Inc., January 2011. [23] GlobalPlatform UICC Configuration v1.0.1, January 2011. [24] Contactless Services, GlobalPlatform Card Specification v 2.2 - Amendment C v1.0.1, February 2012. [25] GlobalPlatform Card Secure Element Configuration Version 1.0, October 2012. [26] GlobalPlatform UICC Configuration - Contactless Extension Version 1.0, February 2012. [27] Contactless Services, GlobalPlatform Card Specification v 2.2 - Amendment C v1.1, April 2013. [28] ETSI TS 102 705, v11.0.0, Smart Cards; UICC - Application Programming Interface for Java Card for Con- tactless Applications, 9 2013. [29] ETSI TS 102 622 v12.1.0 Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host Controller Inter- face (HCI), 10 2014. [30] GlobalPlatform Card Technology, Secure Channel Protocol 03, Card Specification v 2.2 - Amendment D v1.1.1, Juli 2014. [31] Security Upgrade for Card Content Management Card Specification v2.2 - Amendment E v1.0.1, July 2014. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 176 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public [32] GlobalPlatform Card Secure Channel Protocol 11 Card Specification v2.2 - Amendment F Version 1.0, May 2015. [33] Published by Oracle. Java Card 3 Platform, Application Programming Interface, Classic Edition, Version 3.0.4., September 2011. [34] Published by Oracle. Java Card 3 Platform, Runtime Environment Specification, Classic Edition, Version 3.0.4, E18985-01., September 2011. [35] Published by Oracle. Java Card 3 Platform, Virtual Machine Specification, Classic Edition, Version 3.0.4, E25256-01., September 2011. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 177 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 13 Legal information 13.1 Definitions Draft – The document is a draft version only. The content is still under internal review and subject to formal approval, which may result in modifications or addi- tions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included herein and shall have no liability for the consequences of use of such information. 13.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 com- pleteness of such information and shall have no liability for the consequences of use of such information. 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 re- placement 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 whatso- ever, 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 publi- cation hereof. Suitability for use – NXP Semiconductors products are not designed, autho- rized 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 Semi- conductors accepts 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 represen- tation 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, dam- age, 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 prod- ucts 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. 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. Evaluation products – This product is provided on an “as is” and “with all faults” basis for evaluation purposes only. NXP Semiconductors, its affiliates and their suppliers expressly disclaim all warranties, whether express, implied or statutory, including but not limited to the implied warranties of non-infringement, merchantability and fitness for a particular purpose. The entire risk as to the quality, or arising out of the use or performance, of this product remains with customer. In no event shall NXP Semiconductors, its affiliates or their suppliers be li- able to customer for any special, indirect, consequential, punitive or incidental damages (including without limitation damages for loss of business, business interruption, loss of use, loss of data or information, and the like) arising out the use of or inability to use the product, whether or not based on tort (including negligence), strict liability, breach of contract, breach of warranty or any other theory, even if advised of the possibility of such damages. Notwithstanding any damages that customer might incur for any reason whatso- ever (including without limitation, all damages referenced above and all direct or general damages), the entire liability of NXP Semiconductors, its affiliates and their suppliers and customer’s exclusive remedy for all of the foregoing shall be limited to actual damages incurred by customer based on reasonable reliance up to the greater of the amount actually paid by customer for the product or five dollars (US$5.00). The foregoing limitations, exclusions and disclaimers shall apply to the maximum extent permitted by applicable law, even if any remedy fails of its essential purpose. 13.3 Licenses ICs with DPA Countermeasures functionality NXP ICs containing functionality implementing countermeasures to Differential Power Analy- sis and Simple Power Analysis are produced and sold under applicable license from Cryp- tography Research, Inc. Evaluation Version ©NXP B.V. 2018. All rights reserved. Evaluation documentation Rev. 1.3 – 2018-06-01 178 of 179 NXP Semiconductors JCOP4.0 on P73N2M0 Security Target Lite Company Public 13.4 Patents Notice is herewith given that the subject device uses one or more of the follow- ing patents and that each of these patents may have corresponding patents in other jurisdictions. 13.5 Trademarks Notice: All referenced brands, product names, service names and trademarks are property of their respective owners. MIFARE – is a trademark of NXP B.V. Please be aware that important notices concerning this document and the prod- uct(s) described herein, have been included in the section ’Legal information’. ©NXP B.V. 2018. 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: 2018-06-01 Document identifier: NSCIB-CC-16-111441