NXP JCOP 4 Security Target Lite v3.4 5
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.
OT.SID_MODULE Subject Identification of Modules
The TOE shall uniquely identify every Module 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 cleared 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 cleared after the return from the install method.
OT.GLOBAL_ARRAYS_INTEG Integrity of Global Arrays
The TOE shall ensure that no application can store a reference to the APDU buffer, a global byte array created by the user through makeGlobalArray method and the byte array used for 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. | |
OT.SENSITIVE_RESULTS_INTEG | Sensitive Result |
The TOE shall ensure that the sensitive results (com.nxp.id.jcopx.security.SensitiveResultX) of sensitive operations executed by applications through the Java Card API are pro- tected in integrity specifically against physical attacks. | |
5.1.3Services | |
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.RNG | Random Numbers Generation |
The TOE shall ensure the cryptographic quality of random number generation. For in- stance random numbers shall not be predictable and shall have sufficient entropy. The TOE shall 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. | |
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 (including the PIN try limit, PIN try counter and states). If the PIN try limit is reached, no further PIN authentication must be allowed. See SA.PIN-MNGTfor 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. For instance, the try limit and the try counter’s value are as sensitive as that of the PIN and the TOE must restrict their modification only to authorized applications such as the card manager. | |
OT.TRANSACTION | Transaction |
The TOE must provide a means to execute a set of operations atomically. See SA.TRANSACTION for details. |
OT.KEY-MNGT, OT.PIN-MNGT, OT.TRANSACTION, OT.RNGand OT.CIPHER are actually provided to appletsin the form of Java Card APIs. Vendor-specific libraries can also be present on the card and made available to applets; those may be built on top of the Java Card API or independently. These proprietary libraries will be evaluated together with the TOE.
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 [13].
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 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 External Memory | |
OT.EXT-MEM | External Memory |
The TOE shall provide controlled access means to the external memory and ensure that the external memory does not address Java Card System memory (containing User Data and TSF Data). |
5.1.7 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 [13] 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 refinement for the Security Objectives O.INSTALL, O.LOAD, and O.DELETION from [13]. Thus, the following objectives are also covered:
•The TOE shall ensure that the installation of an applet performs as expected (See SA.INSTALLfor 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. .
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 [13] for the environment OE.CARD-MANAGEMENT is listed as TOE Security Objective OT.CARD-MANAGEMENTfor the TOE as the Card Manager belongs to the TOE for this evaluation. This security objective is a refinement for the Security Objectives O.INSTALL, O.LOAD, and O.DELETION from [13]. 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.8 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 [13] 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 security objective for the environment refers to the security aspect SA.SCP AppNote: The Security Objectives from [13] 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 [13] 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.9 Secure Box
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.10 Random Numbers
OT.RND Quality of random numbers
The TOE shall ensure the cryptographic quality of random number generation. For in- stance random numbers shall not be predictable and shall have sufficient entropy. The TOE shall 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.11 Configuration Module
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.
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.
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. 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. | |
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 meansand/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 manufacturingand 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 mustbe protected appropriately. |
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 |
OT.SID | |
OT.FIREWALL | |
OT.OPERATE | |
OT.REALLOCATION | |
OT.ALARM | |
OT.CIPHER | |
OT.TRANSACTION | |
OE.VERIFICATION | |
OT.SCP.RECOVERY | |
OT.SCP.SUPPORT | |
OT.RNG | |
OT.NATIVE | |
OE.VERIFICATION | |
OT.SID | |
OT.FIREWALL | |
OT.OPERATE | |
OT.ALARM | |
OE.VERIFICATION | |
OT.SCP.RECOVERY | |
OT.SCP.SUPPORT | |
OT.NATIVE | |
OE.VERIFICATION | |
OT.SID | |
OT.FIREWALL | |
OT.OPERATE | |
OT.REALLOCATION | |
OT.ALARM | |
OT.CIPHER | |
OT.TRANSACTION | |
OE.VERIFICATION | |
OT.SCP.RECOVERY | |
OT.SCP.SUPPORT | |
OT.RNG | |
OT.NATIVE | |
OE.VERIFICATION | |
OT.SID | |
OT.FIREWALL | |
OT.OPERATE | |
OT.ALARM | |
OE.VERIFICATION | |
OT.SCP.RECOVERY | |
OT.SCP.SUPPORT | |
T.SID.1 | OT.SID |
OT.FIREWALL | |
T.SID.2 | OT.SID |
OT.FIREWALL | |
OT.OPERATE | |
OT.SCP.RECOVERY | |
OT.SCP.SUPPORT | |
OT.FIREWALL | |
OE.VERIFICATION | |
OE.VERIFICATION | |
T.NATIVE | OT.NATIVE |
OE.APPLET | |
OE.VERIFICATION | |
OT.OPERATE | |
OT.ALARM | |
OE.APPLET | |
OT.SCP.SUPPORT | |
OT.OPERATE | |
OT.RESOURCES | |
OT.SCP.RECOVERY | |
OT.SCP.SUPPORT | |
T.CONFIG | |
T.PHYSICAL | OT.SCP.IC |
OT.OPERATE | |
T.RND | OT.RND |
OT.OPERATE | |
OE.APPLET | |
OT.SCP.SUPPORT | |
OSP.VERIFICATION | OE.VERIFICATION |
OT.IDENTIFICATION | |
A.APPLET | OE.APPLET |
A.VERIFICATION | OE.VERIFICATION |
Tab. 5.1: SPDs of the TOE vs. Objectives
9 Contents
1 ST Introduction (ASE_INT) | |||
1.2.3 Required non-TOE Hardware/Software/Firmware | |||
2 Conformance Claims (ASE_CCL) | |||
3 Security Aspects | |||
4 Security Problem Definition (ASE_SPD) | |||
6 Extended Components Definition (ASE_ECD) | |||
7 Security Requirements (ASE_REQ) | |||
8 TOE summary specification (ASE_TSS) | |||
13 Legal information | |||