Java Cards

NXP JCOP 4 Security Target Lite v3.4 5

2020-07-14 16:06:31 M&W SmartCard 2

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.

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.

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 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

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.EXT-MEM

OT.CARD-MANAGEMENT

OT.SCP.RECOVERY

OT.SCP.SUPPORT

OT.RNG

T.CONFID-JCS-CODE

OT.NATIVE


OE.VERIFICATION


OT.EXT-MEM

OT.CARD-MANAGEMENT

T.CONFID-JCS-DATA

OT.SID


OT.FIREWALL

OT.OPERATE

OT.ALARM

OE.VERIFICATION

OT.EXT-MEM

OT.CARD-MANAGEMENT

OT.SCP.RECOVERY

OT.SCP.SUPPORT

OT.SID_MODULE

T.INTEG-APPLI-CODE

OT.NATIVE


OE.VERIFICATION

OT.EXT-MEM

OT.CARD-MANAGEMENT

OE.CODE-EVIDENCE

T.INTEG-APPLI-CODE.LOAD

OT.CARD-MANAGEMENT


OE.CODE-EVIDENCE

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

OT.RNG

T.INTEG-APPLI-DATA.LOAD

OT.CARD-MANAGEMENT


OE.CODE-EVIDENCE

OT.APPLI-AUTH

T.INTEG-JCS-CODE

OT.NATIVE


OE.VERIFICATION

OT.EXT-MEM

OT.CARD-MANAGEMENT

OE.CODE-EVIDENCE

T.INTEG-JCS-DATA

OT.SID


OT.FIREWALL

OT.OPERATE

OT.ALARM

OE.VERIFICATION

OT.EXT-MEM

OT.CARD-MANAGEMENT

OT.SCP.RECOVERY

OT.SCP.SUPPORT

OE.CODE-EVIDENCE

OT.SID_MODULE

T.SID.1

OT.SID


OT.FIREWALL

OT.GLOBAL_ARRAYS_CONFID

OT.GLOBAL_ARRAYS_INTEG

OT.CARD-MANAGEMENT

OT.SID_MODULE

T.SID.2

OT.SID


OT.FIREWALL

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.MODULE_EXEC

OT.OPERATE


OT.ALARM

OE.APPLET

OT.SCP.SUPPORT

OT.SID_MODULE

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.CONFIG

OT.CARD-CONFIGURATION

T.ATTACK-COUNTER

OT.ATTACK-COUNTER


OT.RESTRICTED-MODE

T.PHYSICAL

OT.SCP.IC


OT.RESTRICTED-MODE

OT.SENSITIVE_RESULTS_INTEG

T.OS_OPERATE

OT.OPERATE

T.SEC_BOX_BORDER

OT.SEC_BOX_FW

T.RND

OT.RND

T.MODULE_REPLACEMENT

OT.OPERATE


OE.APPLET

OT.SCP.SUPPORT

OT.SID_MODULE

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.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

9    Contents

1 ST Introduction (ASE_INT)

1.1 ST Reference and TOE Reference

1.2 TOE Overview


1.2.1 Usage and Major Security Features of the TOE

1.2.2 TOE Type

1.2.3 Required non-TOE Hardware/Software/Firmware

1.3 TOE Description


1.3.1 TOE Components and Composite Certi fication

1.3.2 Optional TOE Functionality

1.3.3 TOE Life Cycle

1.3.4 TOE Identification

1.3.5 Evaluated Package Types


2 Conformance Claims (ASE_CCL)


2.1 CC Conformance Claim

2.2 Package Claim

2.3 PP Claim

2.4 Conformance Claim Rationale


2.4.1 TOE Type

2.4.2 SPD Statement

2.4.3 Security Objectives Statement

2.4.4 Security Functional Requirements State ment

3 Security Aspects


3.1 Confidentiality

3.2 Integrity

3.3 Unauthorized Executions

3.4 Bytecode Verification

3.5 Card Management

3.6 Services

3.7 External Memory

3.8 Configuration Module

3.9 Modular Design

3.10 Restricted Mode

4 Security Problem Definition (ASE_SPD)


4.1 Assets


4.1.1 User Data

4.1.2 TSF Data

4.2 Threats


4.2.1 Confidentiality

4.2.2 Integrity

4.2.3 Identity Usurpation

4.2.4 Unauthorized Execution

4.2.5 Denial of Service

4.2.6 Card Management

4.2.7 Services

4.2.8 Miscellaneous

4.2.9 Operating System

4.2.10 Random Numbers

4.2.11 Configuration Module

4.2.12 Secure Box

4.2.13 Module replacement

4.2.14 Restricted Mode

4.3 Organisational Security Policies

4.4 Assumptions

5 Security Objectives


5.1 Security Objectives for the TOE


5.1.1 Identification

5.1.2 Execution

5.1.3 Services

5.1.4 Object Deletion

5.1.5 Applet Management

5.1.6 External Memory

5.1.7 Card Management

5.1.8 Smart Card Platform

5.1.9 Secure Box

5.1.10 Random Numbers

5.1.11 Configuration Module

5.1.12 Restricted Mode

5.2 Security Objectives for the Operational Environment

5.3 Security Objectives Rationale


5.3.1 Threats

5.3.2 Organisational Security Policies

5.3.3 Assumptions


6 Extended Components Definition (ASE_ECD)


6.1 Definition of Family ”Audit Data Storage (FAU_SAS)”

6.2 Definition of Family ”TOE emanation (FPT_EMSEC)”

7 Security Requirements (ASE_REQ)


7.1 Definitions


7.1.1 Groups

7.1.2 Subjects

7.1.3 Objects

7.1.4 Informations

7.1.5 Security Attributes

7.1.6 Operations

7.2 Security Functional Requirements


7.2.1 COREG_LC Security Functional Requirements

7.2.2 INSTG Security Functional Requirements

7.2.3 ADELG Security Functional Requirements

7.2.4 RMIG Security Functional Requirements

7.2.5 ODELG Security Functional Requirements

7.2.6 CarG Security Functional Requirements .

7.2.7 EMG Security Functional Requirements .

7.2.8 ConfG Security Functional Requirements

7.2.9 SecBoxG Security Functional Requirements

7.2.10 ModDesG Security Functional Requirements

7.2.11 RMG Security Functional Requirements .

7.2.12 Further Security Functional Requirements

7.3 Security Assurance Requirements

7.4 Security Requirements Rationale for the TOE


7.4.1 Identification

7.4.2 Execution

7.4.3 Services

7.4.4 Object Deletion

7.4.5 Applet Management

7.4.6 External Memory

7.4.7 Card Management

7.4.8 Smart Card Platform

7.4.9 Random Numbers

7.4.10 Configuration Module

7.4.11 Secure Box

7.4.12 Restricted Mode

7.5 SFR Dependencies


7.5.1 Rationale for Exclusion of Dependencies


7.6 Security Assurance Requirements Rationale

8 TOE summary specification (ASE_TSS)


8.1 Introduction

8.2 Security Functionality

8.3 Protection against Interference and Logical Tampering

8.4 Protection against Bypass of Security Related Actions

9 Contents

10 Glossary

11 Acronyms

12 Bibliography

13 Legal information


13.1 Definitions

13.2 Disclaimers

13.3 Licenses

13.4 Patents

13.5 Trademarks

Java Card is an open standard from Sun Microsystems for a smart card developmentplatform. Smart cards created using the Java Card platform have Java applets stored on them. The applets can be added to or changed after the card is issued.

There are two basic types of smart cards. The memory smart card is the familiar removable memory device; it usually features read and write capabilities and perhaps security features. The more complex version, the processor smart card, is a very small and extremely portable computing device that could be carried in your wallet. Java-based smart cards belong to the latter category. They store data on an integrated microprocessor chip. Applets are loaded into the memory of the microprocessor and run by the Java Virtual Machine. Similarly to MULTOS, another smart card development technology, Java Card enables multiple application programs to be installed and coexist independently. Individual applets are protected by a firewall to preserve their integrity and prevent tampering. Applications can be updated dynamically.

In the United States, the Department of Defense, Visa, and American Express are among the organizations creating Java Card-based applications.


Home
Product
News
Contact us