NXP JCOP 4 Security Target Lite v3.4

Document Information

ST Introduction (ASE_INT)

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 (MC FW) like writing to flash memory. This includes software for implementing cryptographic operations, called Crypto Library.

•Software for implementing a Java Card Virtual Machine [40], a Java Card Runtime Environment [39] and a Java Card Application Programming Interface [38], called JCVM, JCRE and JCAPI.

•Software for implementing content management according to GlobalPlatform [37], called GlobalPlatform (GP) Framework.

•Software for executing native libraries, called Secure Box.

The TOE is also referred to as JCOP 4 P71. The JCOP 4 Operating System (JCOP4 OS) consists of the software stack without the Crypto Library (Crypto Lib) and without the Micro Controller Firmware (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.

Fig. 1.1: Components of the TOE

Figure 1.1 shows the components of the TOE. The TOE is a composite product on top of CC certified Hardware, Firmware and Crypto Library. Part of the TOE are the JCVM, JCRE, JCAPI and the GP Framework. Also included is optional functionality and the Secure Box mechanism. The Secure Box Native Librarys provide native functions for untrusted third parties and are not part of the TOE.

The figure shows Java Card applets which are small programs in Java language that can be executed by the TOE, but are not 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 of so called smart cards. Examples of such cards are banking cards or electronic drivers’ licenses. The TOE can also be used in an electronic passport. Another usage scenario is device authentication, where the TOE can be used to prove the authenticity or originality of a device like an accessory for a gaming console.

The TOE provides a variety of security features. The hardware of the Micro Controller already protects against logical and 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 and decryption of data but also for signing and signature verification. Also the software stack contains security features to protect against attacks.

The following list contains the features of this TOE:

•4 different communication protocols:

1.ISO 7816 T=1,

2.ISO 7816 T=0,

3.ISO 14443 T=CL,

4.I2C Slave².

•Cryptographic algorithms and functionality:

1.Data Encryption Standard with 3 keys (3DES) for en-/decryption (CBC and ECB) and MAC generation and verification (Retail-MAC, CMAC and CBC-MAC).

2.Advanced Encryption Standard (AES) for en-/decryption (CBC, ECB and counter mode) and MAC generation and verification (CMAC, CBC-MAC).

3.Rivest Shamir Adleman asymmetric algorithm (RSA) and RSA CRT for en-/decryption and signature generation and verification.

4.RSA and RSA Chinese Remainder Theorem (CRT) key generation¹.

5.Elliptic Curve Cryptography (ECC) over GF(p) for signature generation and verification (ECDSA)¹.

6.ECC over GF(p) key generation¹.

7.Random number generation according to class DRG.3 or DRG.4 of AIS 20 [41].

8.Diffie-Hellman with ECDH and modular exponentiation¹.

9.SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 hash algorithm.

¹Optional functionality

²Only for Configuration Secure Authentication, see Chapter 1.3.1.3.2

10.Following cryptographic algorithms are part of the TOE but without claims for security functional re-quirements:

(a)KoreanSEED¹,

(b)AES in Counter with CBC-MAC mode (AES CCM)^{1 2},

(c)Keyed-Hash Message Authentication Code (HMAC)^{1 2},

(d)HMAC based Key Derivation Function (HKDF) [32] ^{1 2},

(e)Elliptic Curve Direct Anonymous Attestation (ECDAA) [27] ^{1 2},

(f)Elliptic curve cryptography based on Edwards and Montgomery curves^{1 2},

•Java Card functionality:

1.Executing the Java byte codes which are generated from the Java compiler when Java source code is compiled.

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.

5.Support for Extended Length APDUs.

6.Garbage Collection with memory reclamation and compaction.

7.Persistent Memory Management and Transaction Mechanism.

•GlobalPlatform functionality:

1.Loading of Java packages.

2.Instantiating applet instances.

3.Removing of Java packages.

4.Removing of applet instances.

5.Issuer Security Domain (ISD), Supplementary Security Domain (SSD).

6.Creating SSDs.

7.Associating applets to Security Domains.

8.Installation of keys.

9.Verification of signatures of signed applets.

10.Verification of signatures for commands.

11.CVM Management (Global PIN).

¹Optional functionality

²Only for Configuration Secure Authentication, see Chapter 1.3.1.3.2

12.Secure Channel Protocol (SCP01, SCP02 andSCP03).

13.Delegated Management, Data Authentication Pattern (DAP).

14.Post-issuance installation and deletion of applets and packages.

15.Compliance to several GP configurations.

•NXP Proprietary Functionality

1.Proprietary secure messaging accelerator interface for applets which are used for electronic passport as defined by ICAO or electronic driver license¹.

2.Secure Box¹.

3.Java Card API for data encryption via PUF [22].

1.2.2 TOE Type

The TOE is a Java Card with a GP Framework. It can be used to load and execute off-card verified Java Card applets.

1.2.3Required non-TOE Hardware/Software/Firmware

Three groups of users shall be distinguished here.

The first group is the end-users group, which uses the TOE with one or more loaded applets in the final form factor like a banking card or an electronic passport. These users only require a communication device to be able to communicate with the TOE. The communication protocol of the TOE is standardized in either ISO7816 [31] (T=1, T=0), ISO14443 [10] (T=CL), or UM10204 [28] (I2C Slave, only for Configuration Secure Authentication).

The second group of users are administrators of cards. They want to configure the card by using the Configu-ration Module, to install additional applets and to configure and personalise these applets. These users require the same equipment as end-users.

The third group of users wants to develop Java Card applets and execute 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 toolscan 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. The following sections provide a more detailed description of the components of Figure 1.1.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.

¹Optional functionality

1.3.1.1 Micro Controller

The Micro Controller is a secure smart card controller from NXP’s SmartMX3 family. The Micro Controller contains a co-processor for symmetric cryptographic operations, supporting DES and AES, as well as an accelerator for asymmetric cryptographic algorithms. The Micro Controller further contains a physical random number generator. The supported memory technologies are volatile (Random Access Memory (RAM)) and non-volatile (Read Only Memory (ROM) and FLASH) memory.

Access to all memory types is controlled by a Memory Management Unit (MMU) which allows to separate and restrict access to parts of the 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:

1.3.1.2 Security 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 and for writing data to volatile and non-volatile memory.

The MC FW has been certified together with the Micro Controller and the same references ([20]) as given for the Micro Controller also apply for the MC FW.

1.3.1.2.2   Crypto Library

The Crypto Library provides implementations for symmetric and asymmetric cryptographic operations, hashing, the generation of hybrid deterministic and hybrid physical random numbers and further tools like secure copy and compare. Some of the cryptographic algorithms offered by the Crypto Lib are not certified, see 1.3.1.4.

The symmetric cryptographic operations comprise the algorithms 3DES, AES and KoreanSEED. These algorithms use the symmetric co-processor of the Micro Controller.

The supported asymmetric cryptographic operations are ECC and RSA. These algorithms use the Public Key Crypto Coprocessor (PKCC) of the Micro Controller for the cryptographic operations.

The Crypto Library has been certified together with the Micro Controller and the same references ([20])as given for the Micro Controller also apply.

1.3.1.3Security IC Embedded Software

1.3.1.3.1   JCOP 4 P71

JCOP 4 OS consists of JCVM, JCRE, JCAPI and GP framework. It is implemented according to the Java Card Specification and GlobalPlatform version listed below. Additionally it consists of a proprietary API, which is de-scribed in the UGM [14], [15].

Tab. 1.3: Java Card Specification Version

Tab. 1.4: GlobalPlatform Version

The JCOP 4 OS component can be identified by using the IDENTIFY APDU command (see UGM [14], [15]). This command returns the card identification data, which includes a Platform ID, a Patch ID and other information that allows to identify the content in ROM, FLASH and loaded patches (if any). The Platform ID is a data string that allows to identify the JCOP 4 OS component.

The TOE also includes a Configuration Module (see 1.3.2) which is used for personalisation and configuration of the TOE. It must be deleted after the personalisation is finished (end of Phase 6 ”Personalisation”) by using the DELETE APDU command. Once the Configuration Module is deleted, it is no longer possible to configure the TOE.

The TOE contains further functionality for integrity protection of user data via an EDC, for counting detected attacks by an attack counter, going into a mode of restricted functionality in case too many attacks have been detected, encryption of user data via PUF [22] and optional functionality as described in 1.3.2.

1.3.1.3.2   TOE Configurations

The TOE is available in two configurations, of which the first configuration has two versions:

Tab. 1.5: JCOP configurations and versions

All three versions offer the same common functionality. The version of Configuration Secure Authentication offers additional functionality for I2C Slave protocol, timer functionality, and following cryptographic algorithms:AES CCM, HMAC, HKDF, ECDAA, elliptic curve cryptography based on Edwards and Montgomery curves. Config-uration Secure Authentication does not implement the Mifare host interface, therefore the Security Functional Requirements of EMG group are not applicable for this configuration.

All three versions are covered by this Security Target, they can be differentiated by the response data of the IDENTIFY command (see UGM [14], [15]).

1.3.1.4 Excluded functionality

All Secure Box Native Libraries are not not part of the TOE. No security functional requirements are claimed on KoreanSEED, AES CCM, HMAC, HKDF, ECDAA, elliptic curve cryptography based on Edwards and Montgomery curvesand FIPS self-tests, they are TSF non-interfering.

1.3.2 Optional TOE Functionality

Some dedicated functionality of the TOE can be removed in order to free up memory.

Following functionality is optional:

•RSA key generation,

•Elliptic curve cryptographic functionality,

•Accelerator for integrated mapping of the PACE protocol,

•Korean Seed cryptographic functionality,

•eGov accelerators,

•TOE self-tests according to FIPS 140-2 [8],

•PIV secure messaging as defined by NIST.SP800-73-4 [18],

•SecureBox,

•TOE Configuration Module: The TOE Configuration Module has to be deleted at the end of life cycle phase 6 [14], [15],

•AES CCM as defined in the Java Card AEADCipher API [38], HMAC and HKDF cryptographic functionality as defined in the Java Card API [38] and the UGM [14], [15]. Timer functionality as defined in the UGM [14], [15]. This functionality is available only in Configuration Secure Authentication of the TOE.

•ECDAA [27] and elliptic curve cryptography based on Edwards and Montgomery curves. This functionality is available only in Configuration Secure Authentication of the TOE.

•I2C slave protocol and T = 1 over I2C. This functionality is available only in Configuration Secure Authenti-cation of the TOE.

1.3.3TOE 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 [13], see Figure 1.2.

Fig. 1.2: TOE Life Cycle within Product Life Cycle

Tab. 1.6: Life-cycle

The evaluation process is limited to phases 1 to 5. User Applet development is outside the scope of this evalua-tion. Applets can be loaded into FLASH 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 Configuration Module is loaded into FLASH and has special privileges to personalize and configure the TOE. Before life cycle Phase 7 "Operational Use" the Configuration Module is deleted and hence it is ensured that its functionality cannot be used after wards. It is possible to load patch code into FLASH in phases 3, 4, 5, and 6. The certification is only valid for the ROM code having the Platform Identifiers and the Patch IDs (if applicable) 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 and 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 procedures must also be followed in order to ensure that the TOE is correctly and securely handled, and 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.4 TOE Identification

1.3.4.1 TOE Delivery

The delivery comprises the following items:

1.3.4.2 TOE Identification

The TOE can be identified by using the Platform ID, the FLASH ID and the Patch ID. The IDENTIFY command and the identification output for this TOE are described in detail in the UGM ([14], [15]). The IDENTIFY command also returns information about presence of optional functionality and allows to identify the TOE Configuration.

JCOP 4 P71 v4.7 R1.00.4, JCOP 4 P71 v4.7 R1.01.4 and JCOP 4 SE050 v4.7 R2.00.11 are friendly names for

¹The TOE is delivered as wafer or module. The TOE can be collected at NXP site or is being shipped to the customer. See [14], [15] for details.

²included in the Micro Controller

³via NXP DocStore [21]

the TOE which are unique amongst all JCOP variants at NXP.

1.3.5 Evaluated Package Types

A number of package types are supported for this TOE. All package types, which are covered by the certification of the used hardware (see [20]), are also allowed to be used in combination with each product of this TOE.

The package types do not influence the security functionality of the TOE. They only define which pads are con-nected in the package and for what purpose and in which environment the chip can be used. Note that the security of the TOE is not dependent on which pad is connected or not - the connections just define how the product can be used. If the TOE is delivered as wafer the customer can choose the connection on his own.

9    Contents