NXP JCOP 6.2 on SN220 Secure
Element
Security Target Lite
Rev. 1.8 — 24 November 2022 Product evaluation document
NSCIB-CC-0428888 PUBLIC
Document information
Information Content
Keywords Common Criteria, Security Target, NXP JCOP 6.2 on SN220 Secure Element
Abstract This document contains information to fulfill the requirements of the Common
Criteria component ASE (Security Target) for the Evaluation of the NXP
JCOP 6.2 on SN220 Secure Element developed and provided by NXP
Semiconductors, Business Unit Security and Connectivity, according to the
Common Criteria for Information Technology Security Evaluation Version 3.1
at EAL5 augmented.
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Revision History
Rev. Date Description
1.0 2021-09-21 First Release.
1.1 2022-03-03 Add Configuration R1.02.1
Recertification Iterations of Security Target, adding Confirg R2.01.1 and switching to Java Card PP v3.1
1.7 2022-11-08 Align with ST release v1.7
1.8 2022-11-24 Align with ST Release v1.8
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 2 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
1 ST Introduction (ASE_INT)
1.1 ST Reference and TOE Reference
ST Title JCOP 6.2 on SN220 Secure Element Security Target Lite
ST version Revision 1.8
TOE version R1.01.1, R1.02.1, R1.02.1-1
R2.01.1
Product Type Secure Element and Software Stack
TOE name NXP JCOP 6.2 on SN220 Secure Element
CC Version Common Criteria for Information Technology Security Evaluation Version
3.1, Revision 5, April 2017 (Part 1 [1], Part 2 [2] and Part 3 [3])
Table 1. ST Reference and TOE Reference
1.2 TOE Overview
1.2.1 TOE Type
The TOE type is software deployed on a certified hardware platform (including hardware,
firmware and crypto library), called the micro-controller. The TOE software stack,
JCOP 6.2, is a patchable Java Card with GP functionality. It can be used to load, install,
instantiate and execute off-card verified Java Card applets.
The software stack creates 2 separate domains, see Figure 1, to provide a converged
product consisting of a familiar Java Card Secure Element domain (eSE) and an eUICC
domain providing eUICC functionality in accordance with the GSMA Specification
[43] and external ISO-7816 connectivity. The eUICC domain at the platform level is
underpinned by the same Java Card and Global Platform technology as the eSE domain,
but is dedicated to the eUICC application.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 3 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Figure 1. JCOP 6.2 Domains and Communication Interfaces
The eSE domain is externally accessible via SPI or by the System mailbox, which is
connected to an Integrated NFC controller supporting Type A,B and F contactless
communications. The dedicated eUICC Domain is directly accessible by the ISO-7816
interface.
The eUICC part is a UICC embedded in a consumer device and may be in a removable
form factor or otherwise. It connects to a given mobile network, by means of its currently
enabled MNO profile.
The TOE domains and communication interfaces are depicted in Figure 1 and the
constituent software components are described in more detail in Section 1.3.
Note: care should be taken to discern the concept of eSE and eUICC domains which
are notional concepts to distinguish the eUICC application, accessible by ISO-7816
communications channels, from the familiar Java Card Open platform, accessible via
the system mailbox and NFC controller or SPI Interfaces. The use of the term domain in
this context is distinct from the definition of domain as per GlobalPlatform [29], which are
instantiated and found within the notional domains, such as the ISD in the eSE Domain.
The NFC controller and system mailbox are not within the scope of the evaluation.
Both of the Domains, eSE and eUICC, are running on the Embedded Secure Element
cpu of the micro-controller.
The main interface to the eSE domain is provided by the System Mailbox, which is
connected to an embedded NFC Controller. All eSE communications must support HCI
protocol. The integrated NFC controller provides up to 4 gates for external users to
communicate with the TOE supporting Card Emulation Mode Type A, Type B and Type F
as well as a wired Interface using APDUCard Gate.
The TOE also supports SPI communication directly with the eSE domain and ISO 7816
communication directly with the eUICC domain.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 4 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
1.2.1.1 TOE Configurations
The SN220 certification includes the Hardware IC platform, IC dedicated firmware
and Crypto library, and is certified in 2 different configurations, C13 and C37. See
SectionSection 1.3.2.
Secure Element Configuration Alternative name
SN220 B0.1 C13 SN220.C13
SN220 B0.1 C37 SN220.C37
Table 2. SN220 configurations
Product Versions are defined by a combination of the Hardware variant and the Software
revision, this is detailed in the table below, which defines all of the versions in scope of
this certification.:
Version JCOP 6.2
Revision
SN220 Config eUICC Plugin Patch ID
V1 R1.01.1 C13 1.6.016 00
V2 R1.02.1 C13 1.6.019 00
V2-1 R1.02.1-1 C13 1.6.019 01.00
V3 R2.01.1 C37 n/a 00
Table 3. Product configurations
1.2.2 TOE usage and major features
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 management 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.
TOE features are cumulatively developed from the previous version:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 5 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
1.2.2.1 R1.01.1 Features
• Cryptographic algorithms and functionality:
– 3DES for en-/decryption (CBC and ECB) and MAC generation and verification (2-key
3DES, 3-key 3DES, Retail-MAC, CMAC and CBC-MAC).
– AES (Advanced Encryption Standard) for en-/decryption (GCM, CBC and ECB) and
MAC generation and verification (CMAC, CBC-MAC).
– RSA and RSA CRT for en-/decryption and signature generation and verification.
– RSA and RSA CRT key generation.
– SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 hash algorithm.
– Secure SHA-1, Secure SHA-224, Secure SHA-256, Secure SHA-384, Secure
SHA-512 hash algorithm.
– HMAC
– ECC over GF(p) for signature generation and verification (ECDSA).
– ECC over GF(p) key generation for key agreement.
– Random number generation according to class DRG.3 of AIS 20 [49]
• Java Card functionality:
– Executing Java Card bytecodes.
– Managing memory allocation of code and data of applets.
– Enforcing access rules between applets and the JCRE.
– Mapping of Java method calls to native implementations of e.g. cryptographic
operation.
– Garbage Collection fully implemented with complete memory reclamation including
compactification.
– Support for Extended Length APDUs.
– Persistent Memory Management and Transaction Mechanism.
• GlobalPlatform Card Specification functionality including Amendments A,B,C,D,E,F,H
and I and is compliant with the Common Implementation Configuration.
– Loading of Java Card packages.
– Instantiating applet instances.
– Java package deletion.
– Java applet instance deletion.
– Creating Supplementary Security Domains.
– Associating applets to Security Domains.
– Installation of keys.
– Verification of signatures of signed applets.
– CVM Management (Global PIN) fully implemented.
– Secure Channel Protocol is supported.
– Delegated Management, DAP (RSA 1024 and ECC 256).
– Compliance to Secure Element configuration.
• GSMA ’Remote SIM Provisioning Architecture for consumer Devices’, version 2.2.1
[41] and v2.2.2 [42]
• Cryptographic Service Provider features, [46]
• NXP Proprietary Functionality:
– Felica functionality accessible via Applets using the Felica API - no security
functionality is claimed for this functionality.
– Config Applet: JCOP OS includes a Config Applet that can be used for configuration
of the TOE.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 6 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
– OS Update Component: Proprietary functionality that can update JCOP OS or
UpdaterOS.
– 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.
– Error Detection Code (EDC) API.
1.2.2.2 R1.02.1
The Release includes an updated eUICC Plugin to version 1.6.019.
1.2.2.3 R1.02.1-1
An MNO specific patch for eUICC is made available
1.2.2.4 R2 Features
R2.01.1 is deployed on an updated revision of the Hardware B0.1 (SN220.C37).
The RSP compliance is updated to version 2.2.2 [42] and the Java Card API is updated
to fully support Javacard version 3.1 [26], [28] and [27]
Array Views, API Extensibility and Static Resources are introduced as mandatory
features in version 3.1 of Java Card Specifications and are therefore built into R2.01.1 as
well as a subset of the optional Augmentation packages identified in the Java Card PP [6]
• SensitiveResult
• Monotonic Counters
• Cryptographic Certificate Management
• Key Derivation Functions
• System Time
The Security Objectives and SFRs for these listed features are applicable only to R2.x
1.2.3 TOE components
The JCOP 6.2 software stack can be further split several components. These are
illustrated for R1.x products in Figure 2 whilst Figure 3 illustrates the internal impact of
the removal of the eUICC plugin support for direct integration in R2.x, with no effect on
the provided external interfaces.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 7 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
1.2.3.1 JCOP 6.2 R1.x Interfaces
Figure 2. JCOP 6.2 R1.x Domains and Internal Interfaces
Figure 2 shows the components of the JCOP 6.2 R1.x O/S including the extension APIs
for MiFare, Felica, eUICC and CSP. It also shows the Config Applet which has special
privileges and is used to personalise and configure the TOE. The eUICC APIs provide
access to NXP proprietary functions and a broker API which forwards eSIM/SIM/UICC/
ISIM commands to an eUICC plugin library.
1.2.3.2 JCOP 6.2 R2.x Interfaces
JCOP 6.2 R2.x fully integrates the eUICC functionality, removing the overhead of the
broker layer and tying the eUICC functionality directly to the JCOP Release version,
which differs from R1, where an independent, uniquely identifiable Plugin was able to be
replaced without affecting the JCOP PID. This is shown in Figure 3.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 8 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Figure 3. JCOP 6.2 R2.x Domains and Internal Interfaces
1.2.3.3 JCOP component
The base of the product is composed of:
• Firmware for booting and low level functionality of the Secure Element, called MC FW -
included in the hardware certification.
• Software for implementing cryptographic operations on the Secure Element, called
Security Software - included in the hardware certification.
• Software for implementing the JCOP OS:
– Software that implements low level functionality, called Native OS.
– Software that implements the Java Card Virtual Machine, called JCVM
– Software that implements the Java Card Runtime Environment, called JCRE
– Software that implements the Java Card Application Programming Interface, called
JCAPI.
– Software for implementing content management according to GlobalPlatform Card
Specification, called GP.
– Software that implements a proprietary programming interface, called Extension API.
– Software that handles personalization and configuration, called Config Applet.
– Software that implements the API and functionality for MiFare - no security claims are
made on MiFare.
– Software that implements the API and functionality for Felica - no security claims are
made on Felica.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 9 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
– Software that implements NXP Proprietary API for eUICC implementations, called
eUICC API.
– Other APIs (e.g. OSCCA, UAI) for wich no security claims are made.
• Software to update the JCOP OS or UpdaterOS, called OS Update Component.
1.2.3.4 eUICC component
The eUICC component implements the GSMA RSP architecture following [41] and [42]
specifications.
JCOP 6.2
Release
RSP
Specification
R1.01.1 v2.2.1 [41]
R1.02.1 v2.2.1 [41]
R2.01.1 v2.2.2 [42]
Table 4. JCOP RSP Version
Compliance
It is composed of:
• The Application Layer: privileged applications, such as Security Domains, providing
the remote provisioning and administration functionality - the notion of Security Domain
follows the definition given by [35]
– An ISD-R, including LPA Services, providing life-cycle management of profiles;
– ECASD providing secure storage of credentials and security functions for key
establishment and eUICC authentication;
– ISD-P security domains, each one hosting a unique profile.
• The Platform Layer: a set of functions providing support to the Application Layer:
– A Telecom Framework providing network authentication algorithms;
– A Profile Package Interpreter translating Profile Package data into an installed Profile;
– And a Profile Policy Enabler which comprises Profile Policy verification and
enforcement functions.
• Software that allows forwarding of SIM/UICC/USIM/ISIM API calls to a Plugin
component, called Broker API (JCOP 6.2 R1 specific).
JCOP 6.2 R2.x fully integrates the functionality provided via a software plugin component
in R1.x. This reduces the overhead of the socket but removes the unique identification of
the plugin component.
1.2.3.5 CSP component
The CSP JavaCard extension implements a Cryptographic Service Provider (CSP)
following [46] specifications.
1.2.3.6 TOE Java packages
1.2.3.6.1 External APIs
The TOE presents the following API versions with Global Scope (G) or restricted to one
or other of the available Domains (eSE or eUICC).
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 10 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Package Scope R1 Version R2 version
api-broker G 1.0 1.0
api-bsi-csp eSE 0.2 0.2
api-crs-datastore eSE 1.1 1.1
api-cupmobile-commerce eSE 1.0 1.0
api-factory-reset-application eSE 1.3 1.3
api-felica eSE 1.3 1.3
api-globalplatform G 1.6 1.7
api-globalplatform-contactless G 1.3 1.3
api-globalplatform-upgrade G 1.1 1.1
api-javacard G 3.0.5u1R1 3.1.0u3
api-loader-service G 2.0 2.0
api-mifare4mobile eSE 2.1 2.1
api-mtps eSE 1.0 1.0
api-sim-ts143019 eUICC 05.06.00p 05.06.00p
api-uicc-hci-ts102705 eUICC 11.00.00p0 13.00.00p0
api-uicc-isim-ts131133 eUICC 14.00.00p0 14.00.00p0
api-uicc-ts102241 eUICC 13.00.00p0
R1
16.02.00p0
api-uicc-usim-ts131130 eUICC 15.03.00p0 15.03.00p0
api-visa-broker eSE 1.0 1.0
Table 5. Java Card External APIs
1.2.3.6.2 Java packages
The core package versions and scope are detailed below.
Package Scope R1 Version R2 version
com.felicanetworks.javacard.crypto.twopassauth eSE 1.0 1.0
com.nxp.id.jcop.globalplatform G 2.2 2.2
com.nxp.id.jcopx.accelerator G 1.4 1.4
com.nxp.id.jcopx.authority G 1.4 1.4
com.nxp.id.jcopx.blob eUICC 6.0 removed
com.nxp.id.jcopx.egovaccelerators G 1.1 1.1
com.nxp.id.jcopx.iar G 1.0 1.0
com.nxp.id.jcopx.m4mext G 1.0 1.0
com.nxp.id.jcopx.math G 1.1 1.1
com.nxp.id.jcopx.mifare.mifaredesfire eSE 2.0 2.0
com.nxp.id.jcopx.mifare.mifareplus eSE 2.0 2.0
com.nxp.id.jcopx.oscca G 1.9 1.9
Table 6. Java Package Versions
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 11 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Package Scope R1 Version R2 version
com.nxp.id.jcopx.security G 1.28 1.28
com.nxp.id.jcopx.strongbox G n/a 1.0
com.nxp.id.jcopx.uicc.auth eUICC 6.0 removed
com.nxp.id.jcopx.uicc.globalplatform eUICC 6.0 removed
com.nxp.id.jcopx.uicc.interfacebroker eUICC 6.0 removed
com.nxp.id.jcopx.uicc.interfacebroker.sim eUICC 6.0 removed
com.nxp.id.jcopx.uicc.interfacebroker.uicc eUICC 6.0 removed
com.nxp.id.jcopx.uicc.system eUICC 6.0 removed
com.nxp.id.jcopx.uicc.toolkit eUICC 6.0 removed
com.nxp.id.jcopx.util G 1.24 1.26
com.sec.mobile.fra eSE 1.3 1.3
com.sony.javacard.crypto eSE 1.2 1.2
com.sony.javacard.crypto.a4 eSE 1.0 1.0
com.sony.javacard.crypto.a5 eSE 1.0 1.0
com.sony.javacard.crypto.a6 eSE 1.0 1.0
com.sony.javacard.crypto.advance eSE 1.0 1.0
com.sony.javacard.crypto.advance.e3 eSE 1.0 1.0
com.sony.javacard.crypto.advance.e4 eSE 1.0 1.0
de.bsi.csp eSE 0.2 0.2
java.io G 1.0 1.0
java.lang G 1.0 1.0
javacard.framework G 1.6 1.8
javacard.security G 1.6 1.7
javacardx.apdu G 1.0 1.0
javacardx.crypto G 1.6 1.7
javacardx.framework.util.intx G 1.0 1.1
javacardx.security G 1.0 1.0
org.globalplatform G 1.6 1.7
org.globalplatform.contactless G 1.3 1.3
org.globalplatform.upgrade G 1.1 1.1
org.mifare4mobile.hostinterface eSE 2.1 2.1
org.mifare4mobile.parser eSE 1.0 1.0
org.mifare4mobile.userverifier eSE 1.0 1.0
org.mifare4mobile.walletInterface eSE 2.1 2.1
sim.access eUICC 2.2 2.2
sim.toolkit eUICC 2.6 2.6
uicc.access eUICC 1.2 1.2
Table 6. Java Package Versions...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 12 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Package Scope R1 Version R2 version
uicc.access.bertlvfile eUICC 1.0 1.0
uicc.access.fileadministration eUICC 1.0 1.0
uicc.hci.framework eUICC 1.2 1.3
uicc.hci.services.cardemulation eUICC 1.0 1.0
uicc.hci.services.cltobserver eUICC n/a 1.0
uicc.hci.services.connectivity eUICC 1.0 1.0
uicc.hci.services.readermode eUICC 1.0 1.1
uicc.isim.access eUICC 1.1 1.1
uicc.services.highupdatearray eUICC 1.0 1.0
uicc.system eUICC 1.1 1.2
uicc.toolkit eUICC 1.10 1.12
uicc.usim.access eUICC 1.4 1.4
uicc.usim.geolocation eUICC 2.0 2.0
uicc.usim.suci eUICC 1.0 1.0
uicc.usim.toolkit eUICC 1.9 1.9
Table 6. Java Package Versions...continued
Additional packages related to the R2 features are listed below
Package Scope R2 version
javacardx.framework.time G 1.0
javacardx.security.cert G 1.0
javacardx.security.derivation G 1.0
javacardx.security.util G 1.0
Table 7. Optional Augmentation Java Packages for R2
1.2.4 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 as an embedded Secure Element. These users only
require a communication device to be able to communicate with the TOE. The eSE
domain of the TOE communicates via the Secure Mail Box, which is connected to the
Integrated NFC controller and also supports an SPI interface with the NFC controller.
The NFC controller facilitates contactless or wired interfaces supporting:
– Card Emulation Type A, Type B and Type F according to ETSI 102 622 [47].
– Wired Mode by using the APDUCard Gate according to ETSI 102 622 [47].
The wired interface is expected to be connected to an applications processor.
The eUICC domain of the TOE communicates directly via the ISO-7816 interface or via
a Virtual ISO over SPI.
• 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.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 13 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• The third group of users develops Java Card applets and executes them on the TOE.
These applet developers 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 scope
The TOE scope covers the following components:
• The certified certified NXP SN220 Secure Element and Crypto LibrarySecure.
• The JavaCard platform in open configuration.
• The eUICC implementation in composition with the certified certified NXP SN220
Secure Element and Crypto LibrarySecure
• The CSP JavaCard extension.
The NFC controller and the system mailbox are not in the scope of the evaluation.
The TOE can be in two configurations: with access to eUICC component or not,
depending on whether the ISO-7816 interface is enabled; both configuration are in the
scope of the evaluation.
The TOE is deployed on certified variants of the SN220 Secure Element, which are
SN220 B0.1 C13 and SN220 B0.1 C37.
The CSP extended package is active in all configurations.
1.3.2 TOE Composition
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 product
components of 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.2.1 Micro-Controller component details
The Micro Controller is a secure element from NXP based on ARM architecture. The
Micro Controller 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 product design is based on smart card
technology and is interchangeably referred to as a secure element or smart card product.
The Micro Controller has been certified in a previous certification and the results are re-
used for this certification.
Two micro-controller configurations are certified with the life cycle extended to cover two
manufacturing sites, namely GF1 and SMIC.
The exact reference to the certified micro-controller confirguations are given in Table 8
and Table 9:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 14 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Hardware
Commercial Name
NXP SN220 Series Secure Element with Crypto Library
Certified HW Version SN220_SE B0.1 C13
Certification ID NSCIB CC-21-0258298
Shortened Identifier SN220.C13
Security Target
Reference
[22]
Table 8. Reference to Certified Micro Controller for R1.x products
Hardware
Commercial Name
NXP SN220 Series Secure Element with Crypto Library
Certified HW Version SN220_SE B0.1 C37
Certification ID NSCIB CC-21-0258298
Shortened Identifier SN220.C37
Security Target
Reference
[22]
Table 9. Reference to Certified Micro Controller for R2.x products
1.3.2.1.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,
The MC FW, referred to as 'IC Dedicated Support Software', has been certified together
with the Micro Controller and carries the same references ([22]) as given for the Micro
Controller.
1.3.2.1.2 Security Software
The Security Software provided by the IC Embedded Software provides a cryptographic
library (CryptoLib) and security services software, which includes Flash memory services
as well as utility functinoality for other services such as resource management, patch
handling, service and system configurations functionality. This Security Software is
included in the hardware certification [22].
1.3.2.2 JCOP component details
1.3.2.2.1 JCOP6.2 OS
The JCOP OS consists of Native OS, JCVM, JCRE, GP framework, JCAPI, Extension
API and Config Applet. JCVM, JCRE, JCAPI and GP framework are implemented
according to the Java Card Specification and GlobalPlatform version listed below.
JCRE Version 3.0.5 Classic Edition [25]
JCVM Version 3.0.5 Classic Edition [24]
JCAPI Version 3.0.5 Classic Edition [23]
Table 10. Java Card v3.05 Specifications
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 15 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
JCRE Version 3.1 Classic Edition [28]
JCVM Version 3.1 Classic Edition [27]
JCAPI Version 3.1 Classic Edition [26]
Table 11. Java Card v3.1 Specifications
Name Version Security
Claimed
eSE
domain
GP Framework Version 2.3 [29] yes yes
Amendment A, Confidential Card
Content Management
Version 1.1 [31] yes yes
Amendment B, Remote Application
Management over HTTP
Version 1.1.3 [32] yes no
Amendment C, Contactless Services Version 1.1 [34] yes yes
Amendment D, Secure Channel Protocol
’03’
Version 1.1.1 [35] yes yes
Amendment E, Security Upgrade for
CCM
Version 1.0.1 [36] yes yes
Amendment F, Secure Channel Protocol
’11’
Version 1.1 [37] yes yes
Amendment H, Executable Load File
Upgrade
Version 1.1 [38] no yes
Amendment I, Secure Element
Management Service (SEMS)
Version 1.0 [39] no yes
Common Implementation Configuration Version 2.0 [40] no yes
UICC Configuration Version 1.0.1 [44] no yes
UICC Configuration - Contactless
Extension
Version 1.0 [45] no yes
Table 12. Global Platform Specifications and Amendments
JCOP components version can be identified by using the GET PLATFORM IDENTIFIER
command. 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 identifes the JCOP OS component
1.3.2.2.2 Native Applications
The Native Applications extend the available cryptographic algorithms for the Security
Software. These Native Applications are proprietary implementations (e.g. Felica) which
make use of the Security Software’s security mechanisms. Native Applications are
provided to JCOP OS via the Security Software. No security functionality claimed for
Native Applications, it is an extension to the Crypto Lib.
1.3.2.2.3 OS Update Component
The OS Update Component can update the JCOP OS and the Updater OS. It contains
two main components:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 16 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• OsSelector (no security claimed): After a hardware reset it provides the functionality to
either boot UpdaterOS or JCOP 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 JCOP 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.
– if the update fails the system stays in a secure state.
The UpdaterOS is a standalone operating system that can only be active when JCOP6.2
OS is not active. Besides the capability to update JCOP6.2 OS, UpdaterOS is also
capable of updating itself. The UpdaterOS version can be queried by using a SELECT
OS Update AID Command (see UGM [11] ). UpdaterOS shares parts of the Native OS
with JCOP6.2 OS, e.g.: communication interface, wrapper to Security Software (Flash
Services and CryptoLib).
1.3.2.3 eUICC component details
The eUICC component provides interpretation of the Telecom commands defined in ETSI
TS 102 222, ETSI TS 102 221, ETSI TS 131 102, ETSI TS 131 103, 3GPP2 C.S00065-0,
and all the support of CAT API (defined in ETSI TS 143 019, ETSI TS 102 241, ETSI
TS 131 130). The eUICC component is only available in the eUICC Domain and uses
Security and Cryptographic Services provided by the JCOP platform.
1.3.2.4 CSP component details
The CSP component is a JavaCard package extension exposing a Java Card CSP API
to other JavaCard applications.
It implements a platform architecture defined in the CSP PP i.e. users are other
applications running on top of the JCOP platform. The JCOP platform provides the
required secure execution environment while the CSP JavaCard package provides the
secure services implementation.
Registered AID E804007F00070308
Version 0.2
Table 13. CSP Application Identification
1.3.3 TOE Life Cycle
1.3.3.1 TOE Life Cycle
The life cycle for this TOE is based on the general smart card life cycle defined in the
Java Card Protection Profile - Open Configuration [6], but also considers the life-cycle
presented by the GSMA Embedded UICC for Consumer Devices Protection Profile [8],
both of which are mapped to the lifecycle presented in BSI-PP-0084 [5], see Figure 4.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 17 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
The JCOP lifecycle is fully described in table1.8, whilst the eUICC application lifecycle is
covered in table 1.9 in Section 1.4.2.1.
Figure 4. TOE Life Cycle within Product Life Cycle
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 18 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 Embedded 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 manufacturing, 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.
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 personalization process
and configuration items may be changed/
deleted. The Config Applet can be used to set
Configuration Items.
Table 14. Life-cycle
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 19 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Phase Name Description
7 Operational Usage The Personalizer 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.
• Config Applet: changing Config Items.
• perform card content management according
to Global Platform and Amendments
specifications.
Table 14. Life-cycle...continued
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 16. 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 procedures evaluated
through the TOE evaluation process. During phases 4 to 7 the TOE is no more under the
Evaluation Version 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.2 eUICC specific life-cycle
The eUICC life-cycle is composed of the following stages as described by GSMA -
Embedded UICC for Consumer Devices Protection Profile [8]:
Phase Description
a Development corresponds to the first two stages of the IC development;
b Storage, pre-personalisation and test cover the stages related to manufacturing
and packaging of the IC;
• TOE Delivery [optional]: At this phase the delivery of the TOE to the customer
of the eUICC manufacturer could happen, if the TOE is already self-protected;
c eUICC platform storage, pre-personalization, test covers the stage of the
embedding of software products onto the eUICC;
• TOE Delivery [optional]: At this phase the delivery of the TOE to the customer
of the eUICC manufacturer could happen, if the TOE is already self-protected;
Table 15. eUICC lifecycle stages and Delivery Options
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 20 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Phase Description
d eUICC personalization covers the insertion of provisioning Profiles and
Operational Profiles onto the eUICC;
• TOE Delivery [optional]: At this phase the delivery of the TOE to the customer
of the eUICC manufacturer happens at the latest;
e operational usage of the TOE covers the following steps:
• eUICC integration onto the Device is performed by the Device Manufacturer.
The Device Manufacturer and/or the eUICC Manufacturer also register the
eUICC in a given SM-DS;
• The eUICC is then used to provide connectivity to the Device end-user.
The eUICC may be provisioned again, at post-issuance, using the remote
provisioning infrastructure.
Table 15. eUICC lifecycle stages and Delivery Options...continued
The eUICC product will be delivered at the end of Phase c.
1.3.3.3 CSP specific life-cycle
The CSP life-cycle follows the JCOP life cycle in compliance with the CSP PP [9]
1.3.4 TOE delivery information
1.3.4.1 Delivery method
The TOE is shipped to the customer by NXP as embedded firmware on the certified
Hardware Platform. The available documentation can be downloaded by customers in
PDF format directly from the NXP DocStore.
1.3.4.2 Delivery form factor
The only commercially available package type is "Wafer Level Chip Scale
Package" (WLCSP). This package is a thin fine-pitch ball grid array package. All
(enabled) pins of the TOE are externally accessible. Any additional security provided by
the package is ignored for the security of the TOE and therefore the package type is not
security relevant.
1.3.4.3 Delivery content
The delivery comprises the TOE and an associated set of UGM documentation (note:
each TOE revision has it's own specific set of UGM documents and it follows naturally
that where mention is made of reference to the UGM or addendum, the user should
ensure that they are referencing the correctly associated document):
Type Name Version
Product NXP JCOP 6.2 on SN220 Secure Element including software
(JCOP OS, native applications and OS Update Component) that
is identified by Platform ID.
see Table 19
Document NXP JCOP 6.2 R1.01.1, User Guidance Manual, Rev. 1.7,
2022-09-30
[11] (pdf)
Document NXP JCOP 6.2 R1.01.1, AMD I SEMS Application User Manual
Addendum, Rev. 1.0, 2021-06-16
[12] (pdf)
Table 16. JCOP6.2 R1.01.1 Delivery Items
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 21 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Type Name Version
Document NXP. JCOP 6.2 R1.01.1, CSP User Manual Addendum, Rev.
1.0, 2021-06-16
see [15] (pdf)
Document NXP. JCOP 6.2 R1.01.1, eUICC Profile Package Interpreter
Guide, Rev. 1.1, 2021-07-30
see [13] (pdf)
Table 16. JCOP6.2 R1.01.1 Delivery Items...continued
Type Name Version
Product NXP JCOP 6.2 on SN220 Secure Element including software
(JCOP OS, native applications and OS Update Component) that
is identified by Platform ID.
see Table 19
Document NXP JCOP 6.2 R1.02.1, User Guidance Manual, Rev. 1.2,
2022-09-30
[16] (pdf)
Document NXP JCOP 6.2 R1.02.1, AMD I SEMS Application User Manual
Addendum, Rev. 1.1, 2022-03-03
[17] (pdf)
Document NXP. JCOP 6.2 R1.02.1, CSP User Manual Addendum, Rev.
1.1, 2022-03-03
see [18] (pdf)
Document NXP. JCOP 6.2 R1 eUICC Profile Package Interpreter Guide,
Rev. 1.2, 2022-02-03
see [14] (pdf)
Table 17. JCOP6.2 R1.02.1 Delivery Items
The delivery items for R1.02.1-1 are the same as for R1.02.1. All Patch information is
included in the UGM [16].
Type Name Version
Product NXP JCOP 6.2 on SN220 Secure Element including software
(JCOP OS, native applications and OS Update Component) that
is identified by Platform ID.
see Table 19
Document NXP JCOP 6.2 R2.01.1, User Guidance Manual, Rev. 1.2,
2022-09-30
[19] (pdf)
Document NXP JCOP 6.2 R2.01.1, AMD I SEMS Application User Manual
Addendum, Rev. 1.0, 2022-08-05
[20] (pdf)
Document NXP. JCOP 6.2 R2.01.1, CSP User Manual Addendum, Rev.
1.0, 2022-08-05
see [21] (pdf)
Table 18. JCOP6.2 R2.01.1 Delivery Items
1.4 TOE Identification
The TOE platform can be identified by the JCOP Platform ID, and for R1 products only
the eUICC plugin ID, which is specific to the eUICC Domain. (see Table 19).
• The Platform ID can be obtained by using the GET PLATFORM IDENTIFIER
command .
• The eUICC plugin ID can be obtained, on R1.x products, by using the GET EUICC
PLUGIN VERSION command.
• The patch information is given by the GET VERSION QUERY command, returned in
the R-APDU as TLV data.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 22 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
JCOP6.2
Revision
Component Identifier
PID N5D2M003245A0600
R1.01.1
eUICC plugin
version
1.6.016
PID N5D2M00372520600
R1.02.1
eUICC plugin
version
1.6.019
PID N5D2M00372520600
eUICC plugin
version
1.6.019
R1.02.1-1
patch version 01.00
PID N5D2M003D0430600
R2.01.1
eUICC plugin
version
Not applicable for JCOP 6.2 R2.01.1
Table 19. Product Identification
The Platform ID (PID) has the following form:
Nabcccxxxxxxyyzz
The "N" is constant, the other letters are variables. For a detailed description of these
variables, please see Table 20.
Variable Meaning Value Parameter Settings
a Hardware Type 5 NFC hardware
b JCOP OS Version D JCOP6.2
ccc Non-Volatile Memory Size 2M0 2.0MB
ABCDEF Build Number (hexadecimal) 029E7D svn revision number - specific to
each release
yy Mask ID 06 Mask 6
zz RFU 00 -
Table 20. Platform ID Format (example R2.01.1)
2 Conformance Claims
2.1 CC Conformance Claim
This Security Target claims to be conformant to the Common Criteria version 3.1:
• Common Criteria for Information Technology Security Evaluation, Part 1: Introduction
and general model, Version 3.1, Revision 5, CCMB-2017-04-001, April 2017 [1].
• Common Criteria for Information Technology Security Evaluation, Part 2: Security
functional components, Version 3.1, Revision 5, CCMB-2017-04-002, April 2017 [2].
• Common Criteria for Information Technology Security Evaluation, Part 3: Security
assurance components, Version 3.1, Revision 5, CCMB-2017-04-003, April 2017 [3].
For the evaluation the following methodology will be used:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 23 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• Common Methodology for Information Technology Security Evaluation, Evaluation
methodology, Version 3.1, Revision 5, CCMB-2017-04-004, April 2017 [4].
This Security Target claims to be CC Part 2 extended and CC Part 3 conformant. The
extended Security Functional Requirements are defined in Chapter Section 6.
2.2 CC Package Claim
This Security Target claims conformance to the assurance package EAL5 augmented.
The augmentation to EAL5 is AVA_VAN.5 “Advanced methodical vulnerability analysis”,
ALC_DVS.2 “Sufficiency of security measures”, 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 v3.1 [6], which replaces Java Card Protection Profile - Open
Configuration v3.0.5 [7].
2.3.1 Note on New Features
Array Views, API Extensibility and Static Resources are introduced as mandatory
features in version 3.1 of Java Card Specifications. Java Card systems that are compliant
with previous versions of Java Card Specifications may not provide these features.
Therefore, the TOE shall only provide these features when the Java Card System is
compliant with version 3.1.x of Java Card Specifications.
Table A3-3 of Appendix 3 in the PP [6] clarifies that the Security Objectives for the TOE
related to ArrayView features may be excluded from products with a v3.0.5 configuration.
JCOP 6.2
Release
Java Card
API Version
Compliance
R1.01.1 3.0.5
R1.02.1 3.0.5
R2.01.1 3.1
Table 21. Java Card API Version
Compliance
The Java Card Protection Profile [6] provides a number of optional augmentation
packages. No packages are claimed for JCOP 6.2 R1 products.
Table 22maps the optional packages claimed by JCOP 6.2 R2.01.1
Augmentation Package Claimed by
JCOP 6.2 R2
Biometric Templates N
JCRMI N
Extended Memory N
SensitiveArray N
SensitiveResult Y
Table 22. Optional Augmentation Packages
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 24 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Augmentation Package Claimed by
JCOP 6.2 R2
Monotonic Counters Y
Cryptographic Certificate Management Y
Key Derivation Functions Y
System Time Y
Table 22. Optional Augmentation Packages...continued
This ST is more restrictive than the PP which Section 2.4 provides a rationale for.
The Security Target claims also demonstrable conformance to the eUICC for Consumer
Devices Protection Profile (Base-PP only)[8].
The Security Target claims also strict conformance to the Cryptographic Service Provider
Protection Profile [9].
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 [6] namely:
• A Java Card platform, implementing the Java Card Specifications [27], [28] and [26].
• An eUICC co-existing application, also underpinned by the Java Card and Global
Platform Technologies, but accessible via separate, independent communications
channels.
• An extended JavaCard package implementing the CSP specifications [46].
2.4.2 SPD Statement
2.4.2.1 JCOP
2.4.2.1.1 JCOP threats
The SPD statement that is presented in Section 4 includes the threats as presented in
the PPs [6] and [8], but also includes additional and refined threats. These threats are:
T.INTEG-APPLI-DATA[REFINED]
T.UNAUTHORIZED_CARD_MNGT
T.COM_EXPLOIT
T.LIFE_CYCLE
T.RND
T.CONFIG
T.CONFID-UPDATE-IMAGE.LOAD
T.UNAUTH-LOAD-UPDATE-IMAGE
Table 23. Java Card Additional
Threats
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 25 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
T.INTEG-UPDATE-IMAGE.LOAD
T.INTERRUPT-OSU
T.ATTACK-COUNTER
Table 23. Java Card Additional
Threats...continued
The threat T.INTEG-APPLI-DATA[REFINED] refines the threat T.INTEG-APPLI-DATA in
the PP [6].
The threat T.UNAUTHORIZED_CARD_MNGT refines the threats T.INSTALL and
T.DELETION from the PP [6].
The threat T.COM_EXPLOIT is included to cover communication channels attacks and it
is an addition to the threats in the PP [6].
The threat T.LIFE_CYCLE is included to cover content management attacks and it is an
addition to the threats in the PP [6].
The threat T.RND is taken from the Security IC PP [5].
The threat T.CONFIG is an additional threat to cover unauthorized modifications and read
access of the configuration area in the TOE. It is an addition to the threats defined in the
PP [6].
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.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 [6].
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 [6] makes the use of Java Card
RMI optional.
2.4.2.1.2 JCOP OSP
The SPD statement presented in Section 4, copies the OSP from the PP [6], and adds
the following additional OSPs:
• OSP.PROCESS-TOE
• OSP.KEY-CHANGE
• OSP.SECURITY-DOMAINS
The OSP OSP.PROCESS-TOE is introduced for the pre-personalisation feature of
the TOE and is an addition to the OSPs in PP [6]. The OSP OSP.KEY-CHANGE is
introduced for the SD feature of the TOE and is an addition to the OSPs in PP [6]. The
OSP OSP.SECURITY-DOMAINS is introduced for the SD feature of the TOE and is an
addition to the OSPs in PP [6].
The SPD statement includes two of the three assumptions from the PP [6]. The
assumption A.Deletion is excluded. 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 [6]. As the Card Manager is part of the TOE,
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 26 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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.
2.4.2.1.3 JCOP Assumptions
Besides the assumptions from the PP [6], five additional assumptions are added:
• 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 [22], which is compliant to the Security IC PP [5].
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 [6] for card content management
environment.
2.4.2.2 eUICC
The Security Problem Definition of the eUICC component is the same as in eUICC PP
[8], no item have been added, removed or modified.
2.4.2.3 CSP
The Security Problem Definition of the CSP component is the same as in CSP PP [9], no
item have been added, removed or modified.
2.4.3 Security Objectives Statement
2.4.3.1 JCOP
The statement of security objectives in the ST presented in Section 5 includes all security
objectives as presented in the PP [6], but also includes a number of additional security
objectives. These security objectives are:
• 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
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 27 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• 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 [5] (see also Section 1.3.2.1) which are also components
of this composite certification. Therefore the security objective statement is equivalent to
the PP [6] 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.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 additional
functionality the PP allows. The security objectives OT.CARD-CONFIGURATION is
included for the Config 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 [6]. Additionally, some of the
Security Objectives for the Operational Environment from [6] 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 [6] to which conformance is
claimed.
The security objectives OT.INSTALL, OT.LOAD, and OT.DELETION from the PP [6]
are not included since these functionality and objectives are covered by the refined
OT.CARD-MANAGEMENT.
Note that the objective OT.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 OT.EXT-MEM is not included, since the TOE does not support
"Extended Memory (EXT-MEM)". The Java Card Protection Profile makes the use of
"Extended Memory (EXT-MEM)" optional.
A part of the security objectives for the environment defined in the PP [6] has been
included in this ST. The other part of security objectives for the environment, which is
present in the PP [6], is used as part of the security objectives for the TOE in this ST. The
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 28 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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
The security objective for the environment OE.PROCESS_SEC_IC is from the hardware
platform (Micro Controller [5], see also Section 1.3.2.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 [5].
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 [6].
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, distribution 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 Specification.
The statement of security objectives for the environment is therefore considered to be
equivalent to the security objectives in the PP [6] to which conformance is claimed.
2.4.3.2 eUICC
The Security Objectives for the TOE and its environment of the eUICC component is the
same as in the eUICC PP [8] with some exclusions due to the overlap with the JCOP
objectives defined in [6]:
• OE.IC.SUPPORT from eUICC PP [8] refines the objective OE.SCP.SUPPORT from the
Java Card PP [6] with its own specific needs; it is then directly met by the coverage of
the JCOP objective OE.SCP.SUPPORT.
• OE.IC.RECOVERY from eUICC PP [8] refines the objective OE.SCP.RECOVERY from
the Java Card PP [6] with its own specific needs; it is then directly met by the coverage
of the JCOP objective OE.SCP.RECOVERY.
• OE.RE.PPE-PPI from eUICC PP [8] is a request on the Runtime Environment and
is met by the JCOP component objectives related to the threats T.DELETION and
T.INSTALL defined in [6].
• OE.RE.SECURE-COMM from eUICC PP [8] is a request on the Runtime Environment
and is met by the JCOP component objectives OT.FIREWALL and those related to the
threats T.CONFID-APPLI-DATA and T.INTEG-APPLI-DATA defined in [6].
• OE.RE.API from eUICC PP [8] is a request on the Runtime Environment and is met
by the JCOP component objectives related to the threats T.CONFID-JCS-CODE,
T.INTEG-JCS-CODE, T.CONFID-JCS-DATA and T.INTEG-JCS-DATA defined in [6].
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 29 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• OE.RE.DATA-CONFIDENTIALITY from eUICC PP [8] is a request on the Runtime
Environment and is met by the JCOP component objectives related to the threat
T.CONFID-APPLI-DATA defined in [6].
• OE.RE.DATA-INTEGRITY from eUICC PP [8] is a request on the Runtime Environment
and is met by the JCOP component objectives related to the threats T.INTEG-APPLI-
DATA, T.INTEG-APPLI-DATA.LOAD, T.INTEG-APPLI-CODE, T.INTEG-APPLI-
CODE.LOAD defined in [6].
• OE.RE.CODE-EXE from eUICC PP [8] is a request on the Runtime Environment and is
met by the JCOP component objectives related to the threats T.EXE-CODE.1, T.EXE-
CODE.2 and T.NATIVE defined in [6].
• OE.RE.IDENTITY from eUICC PP [8] is a request on the Runtime Environment and
is met by the JCOP component objectives related to the threats T.SID.1 and T.SID.2
defined in [6].
• OE.IC.PROOF_OF_IDENTITY from eUICC PP [8] is a request on the IC component
and is met as described in Section 1.3.2.1.
2.4.3.3 CSP
The Security Objectives for the TOE and its environment of the CSP component is the
same as in the CSP PP [9] with following exclusions due to the overlap with the JCOP
objectives defined in [6]:
• OE.SecComm from CSP PP [9] is a request on the Runtime Environment and is met
by the JCOP component objectives OT.FIREWALL and those related to the threats
T.CONFID-APPLI-DATA and T.INTEG-APPLI-DATA defined in [6].
2.4.4 Security Functional Requirements Statement
2.4.4.1 JCOP
The Security Functional Requirements Statement copies most SFRs as defined in the
Java Card PP [6], with a few exceptions. For the copied set of SFRs the ST is considered
equivalent to the statement of SFRs in the PP. Moreover as requested by the PP, the
ST adds additional threats, objectives and SFRs to fully cover and describe additional
security functionality implemented in the TOE.
The SFR FDP_ITC.2/INSTALLER from the PP [6] 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 [6].
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:
• Security Domain access control policy
• 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 [6] by following the information flow
policy defined by Global latform specifications. The table below lists the SFRs from CarG
of PP [6] and their corresponding refinements in this ST.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 30 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR from PP [6] 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]
Table 24. CarG SFRs refinements
The following SFRs realize refinements of SFRs from PP [6] and add functionality to the
TOE making the Security Functional Requirements Statement more restrictive than the
PP [6]:
FDP_ROL.1[CCM], FPT_FLS.1[CCM] and FPT_PHP.3 realize additional security
functionality for the card manager which is allowed by the PP [6].
The set of SFRs that define the security domains mechanism as specified by
GlobalPlatform, realize refinements of SFRs from PP [6] (see above Table 24) and
additional security functionality which is allowed by the PP [6]. 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 [6] (see above Table 24) and
additional security functionality which is allowed by the PP [6]. 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 SFRs FAU_SAS.1[SCP] and FIA_AFL.1[PIN] realize additional security functionality
which is allowed by the PP [6].
The set of SFRs that define the Config Applet realize additional security functionality,
which is allowed by the PP [6]. 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 additional security functionality, which is allowed by the PP [6]. 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 the PP [6]. 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].
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 31 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
2.4.4.1.1 Optional Augmentation Packages
The PP [6] defines a number of Optional Augmentation Packages. Those are not
implemented in R1.x products but those which are implemented implemented in JCOP
6.2 R2.x products are detailed in.
Package SFRs
Sensitive Result FDP_SDI.2/RESULT Integrity_Sensitive_Result
Monotonic Counter FDP_SDI.2/MONOTONIC_COUNTER
Cryptographic
Certificate
Management
FDP_SDI.2/CRT_MNGT, FCS_COP.1/CRT_MNGT Certificate
Management
Key Derivation FCS_CKM.5/KDF Key Derivation Function
System Time FPT_STM.1/SYS_TIME
Table 25. Optional Augmentation Packages
2.4.4.2 eUICC
The Security Functional Requirements for the eUICC component are the same as in
eUICC PP [8], none have been added, removed or modified.
2.4.4.3 CSP
The Security Functional Requirements for the CSP component are the same as in CSP
PP [9] with some exclusions due to the overlap with the Java Card PP [6]:
• Common cryptographic SFRs: SFRs FCS_RNG.1 and FCS_CKM.4
• Common self-protection requirements: FPT_PHP.3
The confidentiality of stored data by encryption mechanism is handled at the hardware
level as described in [22]; SFRs FDP_SDC.1 and related SFRs FCS_CKM.1[SDEK] and
FCS_COP.1[SDE] are then also excluded due to this overlap.
In SFR FTP_TST.1, the requirements that a test suite has to be run "at the request of the
authorised user" is not implemented by the issuance of a dedicated command; however,
at the execution of any command invoked by users, regular integrity checks by are
performed by the underlying JavaCard platform and hardware platform (memory integrity
verification, control flow, etc.).
In SFR FDP_ACF.1.2[UCP], the statement "Version Number of the Update Code
Package is equal or higher than the Version Number of the TSF" is hanlded by a
requirement into the UGM [15]
The following SFRs names are extended with the "[CSP]" iterations to identify them as
part of the CSP component: FIA_AFL.1, FIA_ATD.1, FIA_UID.1, FIA_UAU.1, FIA_UAU.5,
FIA_UAU.6, FIA_USB.1, FMT_MOF.1, FMT_SMF.1, FMT_SMR.1, FMT_MSA.2,
FMT_MTD.3, FMT_SAE, FPT_FLS.1, FTP_ITC.1, FPT_TST.1, FRU_FLT.2
In remaining SFRs, any item related to the following mechanisms are not supported (as
authorized by the CSP PP [9] ):
• Clustering
• Time service
• Time stamps
• Audit
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 32 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Concerning the SFRs dependency, only the following differences exist:
• FCS_COP.1[VDSUCP]: the import of UCP signature verification key is done during
manufacturing.
• FCS_COP.1.1[DecUCP]: the import of UCP decryption key is done during
manufacturing.
3 Security Aspects
All of the Security Aspects described in Chapter 4 and the selected Optional
Augmentation packages of the Java Card PP [6] apply to this ST. This chapter describes
only the Security Aspects which describe additional Security Features claimed for the
TOE.
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.
Table 26.
3.2 Integrity
SA.INTEG-UPDATE-I
MAGE
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.
Table 27.
3.3 Config Applet
SA.CONFIG-APPLET Config Applet
The Config Applet is a JCOP functionality which allows to:
• Read and modify configuration items in the configuration area of the
TOE,
• Disable Access to configuration item.
Table 28.
3.4 OS Update
SA.OSU OS Update
The UpdaterOS updates the JCOP OS and the UpdaterOS itself. It
ensures that only valid updates can be installed on the TOE.
Table 29.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 33 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
3.5 Restricted Mode
SA.RM Restricted Mode
If the Attack Counter reaches its limit the TOE goes into Restricted
Mode. In this mode it is possible to perform a limited set of functions, like
authenticate against the ISD, reset the Attack Counter or read logging
information.
Table 30.
4 Security Problem Definition (ASE_SPD)
This Security Problem Definition lists the assets, threats, organisational security policies
and assumptions from the Protection Profiles. In this Security Target, each of the cited
PPs are addressed as individual components.
Component Protection
Profile
JCOP [6]
eUICC [8]
CSP [9]
4.1 JCOP
4.1.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.1.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 [6].
4.1.1.1 User Data
User Data assets defined in Section 5.1.1 of [6] are given here as a reminder.
D.APP_CODE The code of the applets and libraries loaded on the card. To be
protected from unauthorized modification.
D.APP_C_DATA Confidentiality - 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 disclosure.
D.APP_I_DATA Integrity sensitive data of the applications, like the data contained
in an object and the PIN security attributes (PIN Try limit, PIN Try
counter and State). To be protected from unauthorized modification.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 34 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 disclosure
and modification.
Assets refined by this security target are given below:
D.APSD_KEYS Refinement of D.APP_KEYS of [6]. Application Provider Security
Domains cryptographic keys are needed to establish secure channels
with the AP. These keys can be used to load and install applications
on the card if the Security Domain has the appropriate privileges. To
be protected from unauthorized disclosure and modification.
D.ISD_KEYS Refinement of D.APP_KEYS of [6]. Issuer Security Domain
cryptographic keys are 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 [6]. Verification Authority Security
Domain cryptographic keys needed to verify applications Mandated
DAP signature. To be protected from unauthorized disclosure and
modification.
D.CARD_MNGT_DATA The data of the card management environment, like for instance,
the identifiers, the privileges, life cycle states. To be protected from
unauthorized modification.
4.1.1.2 TSF Data
TSF data defined in Section 5.1.2 of [6] are given here as a reminder.
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 unauthorized
disclosure and modification.
D.JCS_CODE The code of the Java Card System. To be protected from unauthorized
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 modification.
Additionally defined TSF data categories for this Security Target are given below
D.CONFIG_ITEM A configuration that can be changed using the Configuration Mechanism.
D.MODULE_CODE The code of a Module. The code of a module might comprise Java code,
native code, code of a native Library or a combination of them. To be
protected against unauthorized disclosure and modification. Further to be
protected against unauthorized removal or presence forgery.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 35 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
D.MODULE_DATA Private data of a Module, like the contents of its private fields. To be
protected from unauthorized disclosure and modification.
D.UPDATE_IMAGE Can be an update for JCOP6.2 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 unauthorized 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 [10].
D.TOE_IDENTIFIER Identification data specific to the TOE
4.1.2 JCOP Threats
The Security Problem Definition for the JCOP component of the TOE adds and refines
items regarding the Security Problem Definition described in the JavaCard PP [6]. The
threats are listed in Table 31 as a reminder.
Threat Refined
T.CONFID-APPLI-DATA -
T.CONFID-JCS-CODE -
T.CONFID-JCS-DATA -
T.INTEG-APPLI-CODE -
T.INTEG-APPLI-CODE.LOAD -
T.INTEG-APPLI-DATA [REFINED]
T.INTEG-JCS-CODE -
T.CONFID-APPLI-DATA -
T.INTEG-JCS-DATA -
T.SID.1 -
T.SID.2 -
T.CONFID-APPLI-DATA -
T.EXE-CODE.1 -
T.EXE-CODE.2 -
T.NATIVE -
T.RESOURCES -
T.DELETION -
T.INSTALL -
T.OBJ-DELETION -
T.PHYSICAL -
Table 31. Threats defined in Java Card PP
The following sections define only the refined and additional threats relative to the Java
Card PP [6]
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 36 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
4.1.2.1 Integrity
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 D.APSD_KEYS. This threat is a
refinement of the Threat T.INTEG-APPLI-DATA from [6].
Table 32.
4.1.2.2 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 asset 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 [6].
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 attacker repersonalizes the application). Directly threatened
asset(s): D.APP_I_DATA, D.APP_C_DATA, and D.CARD_MNGT_DATA.
Table 33.
4.1.2.3 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 provided. 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 statistical 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.
Table 34.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 37 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
4.1.2.4 Config Applet
T.CONFIG Unauthorized configuration
The attacker tries to change configuration items without authorization.
Directly threatened asset(s): D.CONFIG_ITEM.
Table 35.
4.1.2.5 OS Update
T.CONFID-UPDATE-I
MAGE.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-UP
DATE-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-IM
AGE.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 activation 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.
Table 36.
4.1.2.6 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.
Table 37.
4.1.3 JCOP related Organisational Security Policies
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-DOM
AINS
Security Domains
Security domains can be dynamically created, deleted and blocked
during usage phase in post-issuance mode.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 38 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
4.1.4 JCOP related Assumptions
A.USE_DIAG Usage of TOE’s Secure Communication Protocol by OE
It is assumed that the operational environment supports and uses the
secure communication 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 disclosure 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. 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:
• the Security IC Embedded Software including specifications,
implementation and related documentation,
• pre-personalisation and personalisation data including specifications of
formats and memory areas, test related data,
• the User Data and related documentation, and
• 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 responsible 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-AU
THORITY
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.
4.2 eUICC
The Securiity Problem Definition for the JCOP component of the TOE is strictly compliant
with the Security Problem Definition described in the eUICC PP [8].
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 39 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
4.3 CSP
The Securiity Problem Definition for the JCOP component of the TOE is strictly compliant
with the Security Problem Definition described in the CSP PP [9].
5 Security objectives
5.1 Security Objectives for the TOE
This security target refines the prefix from O to OT for TOE Security Objectives, to
distinguish from OE for Environmental Security Objectives.
5.1.1 JCOP
The Security Objectives for the TOE defined in Section 6 of the Java Card Protection
Profile [6], which are also applicable for [7] are listed in Table 38 and apply entirely to this
Security Target.
Security Objective
OT.SID
OT.FIREWALL
OT.GLOBAL_ARRAYS_CONFID
OT.GLOBAL_ARRAYS_INTEG
OT.NATIVE
OT.OPERATE
OT.REALLOCATION
OT.RESOURCES
OT.ALARM
OT.CIPHER
OT.RNG
OT.KEY-MNGT
OT.TRANSACTION
OT.OBJ-DELETION
OT.DELETION
OT.LOAD
OT.INSTALL
Table 38. Security Objectives
for the TOE shared by all
configurations
The Security objectives in Table 39 relate only to Java Card 3.1 products and are defined
in [6].
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 40 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Security Objective
OT.ARRAY_VIEWS_CONFID
OT.ARRAY_VIEWS_INTEG
Table 39. Additional Security
Objectives for Java Card
v3.1
5.1.1.1 Package Sensitive
Defined in Appendix 2, Section 6 of the Java Card PP[6]
• OT.SENSITIVE_RESULTS_INTEG
5.1.1.2 Package Monotonic Counter
Defined in Appendix 2, Section 7 of the Java Card PP[6]
• OT.CRT-MNGT
5.1.1.3 Cryptographic Certificate Management
Defined in Appendix 2, Section 8 of the Java Card PP[6], there are no additional secuity
objectives, but OT.CIPHER and OT.KEY-MNGT are relevant.
5.1.1.4 Package Key Derivation Functions (KDF)
Defined in Appendix 2, Section 9 of the Java Card PP[6], there are no additional secuity
objectives, but OT.CIPHER and OT.KEY-MNGT are relevant.
5.1.1.5 Package System Time
Defined in Appendix 2, Section 10 of the Java Card PP[6], there are no additional secuity
objectives, but OT.OPERATE and OT.RESOURCE are relevant.
The following sections describe only additional and refined items.
5.1.1.6 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 [6]
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.
Table 40.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 41 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 interrupted 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 [6] 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 security aspects 2, 3, 4 and 5 of SA.SCP
AppNote: The Security Objectives from [6] 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.
Table 40. ...continued
5.1.1.7 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 available to an attacker since
they might be used for instance to generate cryptographic keys.
Table 41.
5.1.1.8 OS Update Mechanism
OT.CONFID-UPDATE-
IMAGE.LOAD
Confidentiality of Update Image - Load
The TOE shall ensure that the encrypted image transferred to the device
is not disclosed during the installation. The keys used for decrypting the
image shall be kept confidential.
OT.AUTH-LOAD-UPD
ATE-IMAGE
Authorization of Update Image - Load
The TOE shall ensure that it is only possible to load an authorized
image.
Table 42.
The following Security Objectives have been added to comply to JIL "Security
requirements for post-delivery code loading" [10].
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 42 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 performed 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 provides 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 Identification 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.
Table 43.
5.1.1.9 Config Applet
OT.CARD-CONFIGUR
ATION
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. Additionally, the customer can only disable the
customer configuration and NXP can disable customer and NXP
configuration.
Table 44.
5.1.1.10 Restricted Mode
OT.ATTACK-COUNT
ER
Attack Counter
The TOE shall ensure that the Attack Counter can only be reset by the
ISD or by application of an ECC signed token.
OT.RESTRICTED-MO
DE
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.
Table 45.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 43 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
5.1.1.11 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 OT.LOAD from [6].
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 between 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.
Table 46.
5.1.2 eUICC
The Security Objectives for the eUICC component of the TOE is strictly compliant with
the Security Objectives for the TOE described in the eUICC PP [8].
5.1.3 CSP
The Security Objectives for the CSP component of the TOE is strictly compliant with the
Security Objectives for the TOE described in the CSP PP [9].
5.2 Security Objectives for the Environment
5.2.1 JCOP
The Security Objectives for the environment of the JCOP component of the TOE adds
items regarding the Security Objectives for the Environment described in Section 6.2 of
the Java Card PP [6].
OE.CAP_FILE
Table 47. Security Objectives for the Environment of the Java Card PP
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 44 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
OE.CARD-MANAGEMENT
OE.SCP.IC
OE.SCP.RECOVERY
OE.SCP.SUPPORT
OE.VERIFICATION
OE.CODE-EVIDENCE
Table 47. Security Objectives for the Environment of the Java Card PP...continued
The following sections described only additional and refined items.
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-AUTHOR
ITY
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 application 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 Secure TOE
communication protocols shall be supported and used by the
environment.
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
unauthorised use). This means that Phases after TOE Delivery
up to the end of Phase 6 must be protected appropriately.
OE.CONFID-UPDATE-IMAGE
.CREATE
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.
Table 48. Additional Security Objectives for the Environment
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 45 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
5.2.2 eUICC
The Security Objectives for the Environment of the eUICC component are the same
as the Security Objectives for the Environment described in the eUICC PP [8] with the
exclusions justified in Section 2.4.3.2.
5.2.3 CSP
The Security Objectives for the Environment of the CSP component are the same as
Security Objectives for the Environment described in the CSP PP [9] with the exclusion
justified in Section 2.4.3.3.
5.3 Security Objectives Rationales
5.3.1 JCOP
The following rationales of Security Objectives for the JCOP component only covers
the modifications regarding the Java Card PP [6] due to additions and refinements in
Security Problem Definition and Security Objectives.
5.3.1.1 Threats
5.3.1.1.1 Confidentiality
5.3.1.1.1.1 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.
Table 49.
5.3.1.1.2 Integrity
5.3.1.1.2.1 T.INTEG-UPDATE-IMAGE.LOAD
Objective Rationale
OT.SECURE_LOAD_
ACODE
Counters the threat directly by ensuring the authenticity and integrity of
D.UPDATE_IMAGE.
Table 50.
5.3.1.1.2.2 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 separating data.
Table 51.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 46 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Objective Rationale
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 applet 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 dynamically
enforced, shall never stop operating.
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 automating 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 sensitive data.
OT.PIN-MNGT Counters this threat by providing appropriate management of keys, PINs
which are particular cases of an application’s sensitive data.
OT.TRANSACTION Counters this threat by providing appropriate management of keys, PINs
which are particular cases of an application’s sensitive data.
OT.CARD-MANAGEM
ENT
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 objectives 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 objectives 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 personalization of the
application by its associated security domain is only performed by the
authorized AP.
OE.VERIFICATION Contributes to counter the threat by checking the bytecode.
Table 51. ...continued
5.3.1.1.3 Card Management
5.3.1.1.3.1 T.UNAUTHORIZED_CARD_MNGT
Objective Rationale
OT.CARD-MANAGEM
ENT
Contributes to counter this threat by controlling the access to card
management functions such as the loading, installation, extradition or
deletion of applets.
Table 52.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 47 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Objective Rationale
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.
Table 52. ...continued
5.3.1.1.3.2 T.COM_EXPLOIT
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.
Table 53.
5.3.1.1.3.3 T.LIFE_CYCLE
Objective Rationale
OT.CARD-MANAGEM
ENT
Contributes to counter this threat by controlling the access to card
management functions such as the loading, installation, extradition 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 applications related to
this SD, to the AP who owns it.
Table 54.
5.3.1.1.4 Random Numbers
5.3.1.1.4.1 T.RND
Objective Rationale
OT.RND Counters the threat by ensuring the cryptographic quality of random
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.
Table 55.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 48 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
5.3.1.1.5 Config Applet
5.3.1.1.5.1 T.CONFIG
Objective Rationale
OT.CARD-CONFIGUR
ATION
Counters the threat by ensuring that the customer can only read and
write customer configuration items using the Customer Configuration
Token and NXP can read and write configuration items using the NXP
Configuration Token generation key. If access is disabled configuration
items can not be read or written.
Table 56.
5.3.1.1.6 OS Update
5.3.1.1.6.1 T.UNAUTH-LOAD-UPDATE-IMAGE
Objective Rationale
OT.SECURE_LOAD_
ACODE
Counters the threat directly by ensuring that only authorized (allowed
version) images can be installed.
OT.AUTH-LOAD-UPD
ATE-IMAGE
Counters the threat directly by ensuring that only authorized (allowed
version) images can be loaded.
Table 57.
5.3.1.1.6.2 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).
OT.TOE_
IDENTIFICATION
Counters the threat directly by ensuring that D.TOE_IDENTIFICATION 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.
Table 58.
5.3.1.1.7 Restricted Mode
5.3.1.1.7.1 T.ATTACK-COUNTER
Objective Rationale
OT.ATTACK-COUNTE
R
Counters the threat by ensuring that only the ISD can reset the Attack
Counter.
OT.RESTRICTED-MO
DE
Counters the threat by ensuring that only the ISD can reset the Attack
Counter.
Table 59.
5.3.1.1.8 Miscellaneous
5.3.1.1.8.1 T.PHYSICAL
The rationale for T.PHYSICAL given in the Java Card PP [6] is augmented with the JCOP
Security Objective for Restricted Mode.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 49 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Objective Rationale
OT.SCP.IC Counters phyiscal attacks. Physical protections rely on the underlying
platform and are therefore an environmental issue.
OT.RESTRICTED-MO
DE
Contributes to counter the threat by ensuring that if the limit of the Attack
Counter is reached only limited functionality is available.
Table 60.
5.3.1.2 Assumptions
5.3.1.2.1 A.USE_DIAG
Objective Rationale
OE.USE_DIAG Directly upholds this assumption.
Table 61.
5.3.1.2.2 A.USE_KEYS
Objective Rationale
OE.USE_KEYS Directly upholds this assumption.
Table 62.
5.3.1.2.3 A.PROCESS-SEC-IC
Objective Rationale
OE.PROCESS_SEC_
IC
Directly upholds this assumption.
Table 63.
5.3.1.2.4 A.APPS-PROVIDER
Objective Rationale
OE.APPS-PROVIDER Directly upholds this assumption.
Table 64.
5.3.1.2.5 A.VERIFICATION-AUTHORITY
Objective Rationale
OE.VERIFICATION-A
UTHORITY
Directly upholds this assumption.
Table 65.
5.3.1.3 Organizational Security Policies
5.3.1.3.1 OSP.PROCESS-TOE
Objective Rationale
OT.IDENTIFICATION Enforces this organisational security policy by ensuring that the TOE can
be uniquely identified.
Table 66.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 50 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
5.3.1.3.2 OSP.KEY-CHANGE
Objective Rationale
OE.KEY-CHANGE Enforces the OSP by ensuring that the initial keys of the security domain
are changed before any operation on them are performed.
Table 67.
5.3.1.3.3 OSP.SECURITY-DOMAINS
Objective Rationale
OE.SECURITY-DOMA
INS
Enforces the OSP by dynamically create, delete, and block the security
domain during usage phase in post-issuance mode.
Table 68.
5.3.2 eUICC
The rationales of applicable Security Objectives for the eUICC component and for its
Environment are strictly the same in the eUICC PP [8].
5.3.3 CSP
The rationales of applicable Security Objectives for the CSP component and its
environment are strictly the same in the CSP PP [9].
6 Extended Components Definition
6.1 JCOP
Following extended components have been taken with no modification from the claimed
Java Card PP [6]:
• FCS_RNG.
• FCS_CKM.5
Additionally, the following extended components have been taken with no modification
from the Smartcard IC Platform PP [5]:
• FAU_SAS.1
6.2 eUICC
Following extended components have been taken with no modification from the claimed
eUICC PP [8]:
• FIA_API, FPT_EMS (renamed FPT_EMSEC) and FCS_RNG.
6.3 CSP
Following extended components have been taken with no modification from the claimed
CSP PP [9]:
• FCS_RNG, FCS_CKM.5, FIA_API, FPT_TCT, FPT_TIT, FPT_ISA, FPT_ESA,
FDP_SDC.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 51 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7 Security Requirements (ASE_REQ)
7.1 Security Functional Requirements
7.1.1 JCOP
The Security Functional Requirements for the JCOP component of the TOE implements
all SFRs of the the Java Card PP [6]; however some are refined and some are added
(see Conformance Claim Rationale).
In the following, only modified or added items regarding the Java Card PP [6] are
described.
7.1.1.1 SFRs content items definitions
Additional groups used for readability purposes are defined:
Group Description
Configuration SFRs related to NXP Proprietary product configuration feature.
OS UPdate SFRs related to NXP Proprietary OS Update feature
Restricted Mode SFRs related to NXP Proprietary Restricted Mode.
Table 69. Requirement Groups
Additional subjects acting on behalf of TOE users are defined:
Subjects Descriptions
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.OSU OSU provides secure functionality to update the TOE operating
system with an image created by a trusted off-card entity
(S.UpdateImageCreator)
S.UpdateImageCreator 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.
S.Customer The subject that has the Customer Configuration Token.
S.NXP The subject that has the NXP Configuration Token generation key.
S.ConfigurationMecha
nism
On card entity which can read and write configuration items.
Table 70. Java Card Subject Descriptions
No additional objects are defined.
Additional security attributes linked to subjects, objects and information are defined:
Security attributes Description
Attack Counter Attack Counter
Table 71. Security attribute description
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 52 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Security attributes Description
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.
Final Sequence
Number
The sequence number which is reached after completing the update
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.
Reference Sequence
Number
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.
Address Space Accessible memory portion.
Verification Key Key to verify integrity of D.UPDATE_IMAGE.
Decryption Key Key for decrypting D.UPDATE_IMAGE.
Customer
Configuration Token
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.
Attack Counter Token
Key
The key to generate tokens for Attack Counter Reset.
NXP Configuration
Access
The NXP Configuration Access can either be enabled or disabled.
Customer
Configuration Access
The Customer Configuration Access can either be enabled or disabled.
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 [29].
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 Privileged
Mode, Application Unprivileged Mode and Shared Mode. The modes
Service Privileged and Service Unprivileged are reserved 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 functional
blocks of the hardware.
Card Life Cycle Defined in Section 5.1.1 of [29].
Privileges Defined in Section 6.6.1 of [29].
Table 71. Security attribute description...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 53 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Security attributes Description
Life-cycle Status Defined in Section 5.3.2 of v.
Table 71. Security attribute description...continued
Additional operations are defined:
Operations Description
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.
Table 72. Operation Description
7.1.1.2 COREG_LC Security Functional Requirements
The list of SFRs of this category are taken from [6].
7.1.1.2.1 Firewall policy
The following table provides the assignments and/or selections of related SFRs taken
from the Java Card PP [6]:
SFR ID Selection / Assignment text Selection / Assignment value
FDP_IFF.1.3/
JCVM
[assignment: additional
information flow control SFP
rules]
no additional information flow control SFP rules
FDP_IFF.1.4/
JCVM
[assignment: rules, based
on security attributes, that
explicitly authorise information
flows]
none
FDP_IFF.1.5/
JCVM
[assignment: rules, based
on security attributes, that
explicitly authorise information
flows]
none
Table 73.
7.1.1.2.2 Application Programming Interface
The following table (Table 74) provides the assignments and/or selections of related
SFRs taken from the Java Card PP [6]:
SFR ID Selection / Assignment text Selection / Assignment value
FCS_CKM.1.1/ [assignment: cryptographic key
generation algorithm]
JCOP RNG
Table 74. API SFRs
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 54 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: cryptographic key
sizes]
DES: Key lengths - LENGTH_DES3_2KEY,
LENGTH_DES3_3KEY bit, AES: Key lengths
- LENGTH_AES_128, LENGTH_AES_192,
LENGTH_AES_256 bit RSA-CRT and RSA:
Any length that is a multiple of 32 from 512 to
2048 bits, ECC: Key lengths - Any length from
128 to 528 bits
[assignment: list of standards] [48]
[assignment: cryptographic key
destruction method]
physically overwriting the keys in a randomized
manner]
FCS_CKM.4.1/
[assignment: list of standards] none
[assignment: list of
cryptographic operations]
decryption and encryption
[assignment: cryptographic
algorithm]
AES in GCM mode
[assignment: cryptographic key
sizes]
128 bits
FCS_COP.1.1
[GCM]
[assignment: list of standards] FIPS 197 [50], Recommendation for
BlockCipher [57]
[assignment: list of
cryptographic operations]
decryption and encryption
[assignment: cryptographic
algorithm]
• 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
• ALG_DES_CBC_PKCS5
• ALG_DES_ECB_PKCS5
[assignment: cryptographic key
sizes]
LENGTH_DES3_2KEY, LENGTH_DES3_
3KEY]
FCS_COP.1.1
[TripleDES]
[assignment: list of standards] for ALG_DES_ECB_ISO9797_M2 see Java
Card API Spec [26], for the rest see both [26]
and JCOPX API [11]
[assignment: list of
cryptographic operations]
decryption and encryption
[assignment: cryptographic
algorithm]
• ALG_AES_BLOCK_128_CBC_NOPAD
• ALG_AES_BLOCK_128_CBC_NOPAD_
STANDARD
• ALG_AES_BLOCK_128_ECB_NOPAD
• ALG_AES_CBC_ISO9797_M2
• ALG_AES_CBC_ISO9797_M2_STANDARD
• ALG_AES_ECB_ISO9797_M2
• ALG_AES_CBC_PKCS5
• ALG_AES_ECB_PKCS5
FCS_COP.1.1
[AES]
[assignment: cryptographic key
sizes]
LENGTH_AES_128, LENGTH_AES_192 and
LENGTH_AES_256
Table 74. API SFRs...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 55 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: list of standards] for ALG_AES_BLOCK_128_CBC_NOPAD_see
API specified in JCOPX [11], for the rest see
Java Card API Spec [26]
[assignment: list of
cryptographic operations]
decryption and encryption
[assignment: cryptographic
algorithm]
• ALG_RSA_NOPAD
• ALG_RSA_PKCS1
• ALG_RSA_PKCS1_OAEP
[assignment: cryptographic key
sizes]
any key length that is amultiple of 32 between
512 and 2048 bits
FCS_COP.1.1
[RSACipher]
[assignment: list of standards] Java Card API Spec [26] and for the 32 bit step
range see API specified in JCOPX [11]
[assignment: list of
cryptographic operations]
Diffie-Hellman Key Agreement
[assignment: cryptographic
algorithm]
• 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
[assignment: cryptographic key
sizes]
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]
FCS_COP.1.1
[ECDH_
P1363]
[assignment: list of standards] Java Card API Spec [26] and for
ALG_EC_SVDP_DH_PLAIN_or 1 bit step range
key size see API specified in JCOPX [11]]
[assignment: list of
cryptographic operations]
MAC generation and verification
[assignment: cryptographic
algorithm]
Triple-DES in outer CBC for Mode:
• ALG_DES_MAC4_ISO9797_1_M1_ALG3
• ALG_DES_MAC4_ISO9797_1_M2_ALG3
• ALG_DES_MAC4_ISO9797_M1
• ALG_DES_MAC4_ISO9797_M2
• ALG_DES_MAC8_ISO9797_1_M1_ALG3
• ALG_DES_MAC8_ISO9797_1_M2_ALG3
• ALG_DES_MAC8_ISO9797_M1
• ALG_DES_MAC8_ISO9797_M2
• ALG_DES_MAC8_NOPAD
• ALG_DES_MAC4_PKCS5
• ALG_DES_MAC8_PKCS5
[assignment: cryptographic key
sizes]
LENGTH_DES3_2KEY, LENGTH_DES3_3KEY
FCS_COP.1.1
[DESMAC]
[assignment: list of standards] Java Card API Spec [26] and JCOPX API [11]
Table 74. API SFRs...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 56 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: list of
cryptographic operations]
digital signature generation and verification
[assignment: cryptographic
algorithm]
• 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
• ALG_RSA_SHA_512_PKCS1
• ALG_RSA_SHA_512_PKCS1_PSS
• SIG_CIPHER_RSA in combination
with MessageDigest.ALG_SHA_256,
MessageDigest.ALG_MessageDigest.ALG_
SHA_512 and in combination with
Cipher.PAD_PKCS1_OAEP
[assignment: cryptographic key
sizes]
any key length that is a multiple of 32 between
512 and 2048 bits
FCS_COP.1.1
[RSASignature-
PKCS1]
[assignment: list of standards] Java Card API Spec [26] and for the 32 bit step
range see API specified in JCOPX [11]
[assignment: list of
cryptographic operations]
digital signature generation and verification
[assignment: cryptographic
algorithm]
• ALG_ECDSA_SHA_224
• ALG_ECDSA_SHA_256
• ALG_ECDSA_SHA_384
• ALG_ECDSA_SHA_512
• SIG_CIPHER_ECDSA in combination
with MessageDigest.ALG_SHA_256
or MessageDigest.ALG_SHA_384 or
MessageDigest.ALG_SHA_512
[assignment: cryptographic key
sizes]
LENGTH_EC_FP_128,LENGTH_EC_FP_160,
LENGTH_EC_FP_192, LENGTH_EC_FP_224,
LENGTH_EC_FP_256, LENGTH_EC_FP_384,
LENGTH_EC_FP_521 and from 128 bit to 528
bit in 1 bit steps
FCS_COP.1.1
[ECSignature]
[assignment: list of standards] Java Card API Spec [26] and for 1 bit step
range key size see API specified in JCOPX [11]
[assignment: list of
cryptographic operations]
secure hash computation
[assignment: cryptographic
algorithm]
• ALG_SHA
[1]
• ALG_SHA_224
• ALG_SHA_256
• ALG_SHA_384
• ALG_SHA_512
FCS_COP.1.1
[SHA]
[assignment: cryptographic key
sizes]
• LENGTH_SHA
• LENGTH_SHA_224
• LENGTH_SHA_256
• LENGTH_SHA_384
• LENGTH_SHA_512
Table 74. API SFRs...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 57 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: list of standards] Java Card API Spec [26], FIPS 180-4[51] FIPS
202-2015[53]
[assignment: list of
cryptographic operations]
CMAC generation and verification
[assignment: cryptographic
algorithm]
• ALG_AES_CMAC16
• SIG_CIPHER_AES_CMAC16
• ALG_AES_CMAC16_STANDARD
[assignment: cryptographic key
sizes]
LENGTH_AES_128, LENGTH_AES_192 and
LENGTH_AES_256 bit
FCS_COP.1.1
[AES_CMAC]
[assignment: list of standards] assignment: see Java Card API Spec [26] and
the JCOPX API specified in [11]
[assignment: list of
cryptographic operations]
HMAC generation and verification
[assignment: cryptographic
algorithm]
• ALG_HMAC_SHA_256
• ALG_HMAC_SHA_384
• ALG_HMAC_SHA_512
[assignment: cryptographic key
sizes]
LENGTH_SHA_256,LENGTH_SHA_384 and
LENGTH_SHA_512 bit
FCS_COP.1.1
[HMAC]
[assignment: list of standards] Java Card specification [26] and JCOPX API
[11]
[assignment: list of
cryptographic operations]
message authentication and verification
[assignment: cryptographic
algorithm]
• ALG_DES_CMAC8
• SIG_CIPHER_DES_CMAC8
[assignment: cryptographic key
sizes]
LENGTH_DES3_2KEY and LENGTH_DES3_
3KEY bit
FCS_COP.1.1
[TDES_CMAC]
[assignment: list of standards] see API specified in JCOPX [11]
[assignment: list of
cryptographic operations]
verification of the DAP signature attached to
Executable Load Applications
[assignment: cryptographic
algorithm]
• ALG_RSA_SHA_PKCS1
• ALG_ECDSA_SHA_256
[assignment: cryptographic key
sizes]
LENGTH_RSA_1024, LENGTH_EC_FP_256
FCS_COP.1.1
[DAP]
[assignment: list of standards] GP Spec [36] and JCOPX API [11]
Table 74. API SFRs...continued
[1] Due 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.
Table 38 provides the assignments and/or selections of related SFRs taken from the Java
Card PP [6] which are applicable only for JCOP 6.2 R2.x configuration
SFR ID Selection / Assignment text Selection / Assignment value
FCS_COP.1.1
[AES_XTS]
[assignment: list of
cryptographic operations]
decryption and encryption
Table 75. SFRs applicable from JCOP 6.2 R2
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 58 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: cryptographic
algorithm]
• ALG_AES_XTS
[assignment: cryptographic key
sizes]
LENGTH_AES_256 LENGTH_AES_512
[assignment: list of standards] [26]
Table 75. SFRs applicable from JCOP 6.2 R2...continued
Table 39provides the assignments and/or selections of related SFRs taken from the Java
Card PP [6] which are applicable for the supported optional augmentation packages.
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: list of
cryptographic operations]
verification of X.509 Certificate
[assignment: cryptographic
algorithm]
• RSASSA_PSS with the digest
– SHA1_HASH
– SHA224_HASH
– SHA256_HASH
– SHA384_HASH
– SHA512_HASH
• PKSC#1 V1.5 with the digest
– ALG_MD5
– SHA1_HASH
– SHA224_HASH
– SHA256_HASH
– SHA384_HASH
– SHA512_HASH
• ECDSA with the digest
– SHA1_HASH
– SHA224_HASH
– SHA256_HASH
– SHA384_HASH
– SHA512_HASH
[assignment: cryptographic key
sizes]
for RSA see FCS_COP.1.1[RSASignature-
PKCS1], for ECDSA see FCS_
COP.1.1[ECSignature]
FCS_COP.1.1/
CRT_MNGT
[assignment: list of standards] [26], [61]
[assignment: key type] AESKey, DESKey, HMACKey and
GenericSecretKey
[assignment: input parameters] KDFCounterModeSpec, KDFIcaoMrtdSpec,
KDFAnsiX963Spec, KDFHmacSpec
[assignment: cryptographic key
derivation algorithm]
• ALG_KDF_COUNTER_MODE
• ALG_KDF_ICAO_MRTD
• ALG_KDF_ANSI_X9_63
• ALG_KDF_HKDF
[assignment: cryptographic key
sizes]
output length according to algorithm
specification, limited to 896 bytes by JCOP
FCS_CKM.5.1/
KDF
[assignment: list of standards] [26]
Table 76. Augmentation Package SFRs
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 59 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.1.1.2.3 Card_security_management
The following table provides the assignments and/or selections of related SFRs taken
from the Java Card PP [6]:
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: list of other
actions]
response with error code to S.CAD
FAU_ARP.1.1
Refinement [assignment: list of
other runtime errors]
none
[assignment: integrity errors] integrity errors
FDP_SDI.2.1
[DATA]
[assignment: user data
attributes]
integrity protected data
Application Note - The following data elements
have the user data attribute ”integrity protected
data”:
• D.APP_KEYs
• D.PIN
• D.TOE_IDENTIFIER
FDP_SDI.2.2
[DATA]
[assignment: action to be
taken]
reset the card session for integrity errors
[assignment: list of users and/
or subjects]
all users
[assignment: list of operations] all operations
[assignment: list of objects] D.APP_KEYs, D.PIN
FPR_UNO.1.1
[assignment: list of protected
users and/or subjects].
another user
FPT_TDC.1.2 [assignment: list of
interpretation rules to be
applied by the TSF]
none
Table 77.
7.1.1.2.4 AID Management
The following table provides the assignments and/or selections of related SFRs taken
from the Java Card PP [6]:
SFR ID Selection / Assignment text Selection / Assignment value
FIA_
USB.1.1[AID]
[assignment: list of user
security attributes]
[1]
Package AID
FIA_
USB.1.2[AID]
[assignment: rules for the initial
association of attributes]
each uploaded package is associated with an
unique Package AID
FIA_
USB.1.3[AID]
[assignment: rules for the
changing of attributes]
the initially assigned Package AID is
unchangeable
Table 78.
[1] assignment completed in Java Card PP and no refinement claimed here
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 60 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.1.1.3 INSTG Security Functional Requirements
The following table provides the assignments and/or selections of related SFRs taken
from the Java Card PP [6]:
Note that the SFR FDP_ITC.2[INSTALLER] has been refined and is now part of the card
management SFRs (FDP_ITC.2[CCM]).
SFR ID Selection / Assignment text Selection / Assignment value
FPT_RCV.3.1
[Installer]
[assignment: list of failures/
service discontinuities]
none
FPT_RCV.3.2
[Installer]
[assignment: list of failures/
service discontinuities]
a failure during load/installation of a package/
applet and deletion of a package/applet/object
FPT_RCV.3.3
[Installer]
[assignment: quantification] 0%
Table 79.
7.1.1.4 ADELG Security Functional Requirements
No assignments nor selections are needed for this group of SFRs defined the Java Card
PP [6].
7.1.1.5 RMIG Security Functional Requirements
Not used in this ST because RMI is optional in PP [6] and the TOE does not support RMI.
7.1.1.6 ODELG Security Functional Requirements
No assignments nor selections are needed for this group of SFRs defined the Java Card
PP [6].
7.1.1.7 CarG Security Functional Requirements
The card management SFRs from the PP [6] are refined by, replaced by and/or
completed with the following SFRs.
FDP_UIT.1 [CCM]
(refines FDP_UIT.1/
CM)
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:receive] user data
in a manner protected from [selection:modification, deletion,
insertion and replay] errors.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 61 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
FDP_UIT.1.2 [CCM] The TSF shall be able to determine on receipt of user data,
whether [selection: modification, deletion, insertion, replay]
has occurred.
FDP_ROL.1 [CCM]
(added)
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 permit the rollback of the [assignment:
installation operation] on the [assignment: executable 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]
(replaces
FDP_ITC.2/
INSTALLER)
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 basic 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, controlled
under the SFP, from outside of the TOE.
FDP_ITC.2.2 [CCM] The TSF shall ignore any 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.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 62 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 ([24], §4.5.2).].
Application Note This SFR also covers security functionality required by
Amendment A of the GP specification [30], i.e. personalizing SDs
and loading ciphered load files.
FPT_FLS.1 [CCM]
(added)
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: [assignment: the Security Domain fails
to load/install an Executable File/application instance as
described in [25], Section 11.1.5].
FDP_ACC.1 [SD]
(added)
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 [6]) 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)
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 63 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
(added)
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 [6] and represented by the
GlobalPlatform Environment (OPEN) on the card, the
Card Life Cycle attributes (defined in Section 5.1.1 of [29])
– S.ADEL, also defined in [6] and represented by the
GlobalPlatform Environment (OPEN) on the card
– S.SD receiving the Card Content Management commands
(through APDUs or APIs) with a set of Privileges (defined
in Section 6.6.1 of [29]), a Life-cycle Status (defined
in Section 5.3.2 of [29]) and a Secure Communication
Security Level (defined in Section 10.6 of [29])
– S.CAD, defined in [6], 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, installation, 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, Privileges, 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 defined by
GlobalPlatform for:
• loading (Section 9.3.5 of [29])
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 64 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• installation (Section 9.3.6 of [29])
• extradition (Section 9.4.1 of [29])
• registry update (Section 9.4.2 of [29])
• content removal (Section 9.5 of [29])
]
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 additional rules:[assignment: when at least one
of the rules defined by GlobalPlatform does not hold]
Application Note FDP_ACF.1.2
[SD]
• 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 implemented 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 protection
profile.
FMT_MSA.1 [SD]
(added)
Management of security attributes (SD)
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 [SD] The TSF shall enforce the [assignment: Security Domain
access control policy] to restrict the ability to [selection:
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]
(added)
Static attribute initialisation (SD)
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 65 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 [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 information is
created.
FMT_SMF.1 [SD]
(refines FMT_SMF.1/
CM)
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: [assignment:
• Management functions specified in GlobalPlatform
specifications [GP]:
– card locking (Section 9.6.3 of [29])
– application locking and unlocking (Section 9.6.2 of [29])
– card termination (Section 9.6.4 of [29])
– card status interrogation (Section 9.6.6 of [29])
– application status interrogation (Section 9.6.5 of [29])
].
FMT_SMR.1 [SD]
(refines
FMT_SMR.1/CM)
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.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 66 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
FCO_NRO.2 [SC]
(refines
FCO_NRO.2/CM)
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 [selection: originator] given [assignment:
at the time the Executable load files are received as no
evidence is kept on the card for future verification].
Application Note 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 verification of the origin
of the package using an electronic signature mechanism, and
no evidence is kept on the card for future verifications.
FDP_IFC.2 [SC]
(refines FDP_IFC.2/
CM)
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,
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 67 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• 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
• [assignment: none]
] 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]
(refines FDP_IFF.1/
CM)
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 attributes
[assignment: :
• Subjects:
– S.SD receiving the Card Content Management commands
(through APDUs 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 registry update;
– personalization keys and/or certificates, in case of
application or SD personalization.
• [assignment: none]
]
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:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 68 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• Runtime behavior rules defined by GlobalPlatform for:
– loading (Section 9.3.5 of [29]);
– installation (Section 9.3.6 of [29]);
– extradition (Section 9.4.1 of [29]);
– registry update (Section 9.4.2 of [29]);
– content removal (Section 9.5 of [29])
]
FDP_IFF.1.3 [SC] The TSF shall enforce the [assignment: none]
FDP_IFF.1.4 [SC] The TSF shall explicitly authorise an information flow based on
the following rules: [assignment:none]
FDP_IFF.1.5 [SC] The TSF shall explicitly deny an information flow based on the
following rules: [assignment:
• When none of the conditions listed in the element
FDP_IFF.1.4 of this component hold and at least one of
those listed in the element FDP_IFF.1.2 does not hold
].
Application note The subject S.SD can be the ISD or APSD.
Application note 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]
(refines
FMT_MSA.1/CM)
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 [assignment:
• Key Set,
• Security Level,
• Secure Channel Protocol,
• Session Keys,
• Sequence Counter,
• ICV.
] to [assignment: the actor associated with the according
security domain:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 69 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• The Card Issuer for ISD,
• The Application Provider for APSD
].
Application note The key data used for setting up a secure channel is according to
GP spec [29], Amendment D [35] and Amendmend F [37].
FMT_MSA.3 [SC]
(refines
FMT_MSA.3/CM)
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
[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]
(refines FMT_SMF.1/
CM)
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: [assignment:
• Management functions specified in GlobalPlatform
specifications [GP]:
– loading (Section 9.3.5 of [29])
– installation (Section 9.3.6 of [29])
– extradition (Section 9.4.1 of [29])
– registry update (Section 9.4.2 of [29])
– content removal (Section 9.5 of [29])
].
Application note All management functions related to secure channel protocols
shall be relevant.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 70 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
FIA_UID.1 [SC]
(refines FIA_UID.1/
CM)
Timing of Identification (SC)
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1 [SC] The TSF shall allow [assignment:
• 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.
Application Note The GlobalPlatform TSF mediated actions listed in [GP] such as
selecting an application, requesting data, initializing, etc.
FIA_UAU.1 [SC]
(added)
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]
(added)
Single-use authentication mechanisms (SC)
Hierarchical to: No other components.
Dependencies: No dependencies.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 71 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
FIA_UAU.4.1 [SC] The TSF shall prevent reuse of authentication data related to
[assignment: the authentication mechanism used to open a
secure communication channel with the card]
FTP_ITC.1 [SC]
(refines FTP_ITC.1/
CM)
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 product that is logically distinct from other
communication channels and provides assured identification of its
end points and protection of the channel data from modification or
disclosure.
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 including:
• loading;
• installation;
• extradition;
• registry update;
• content removal;
• changing the Application Life Cycle or Card Life Cycle;
• SD personalization.
].
7.1.1.8 EMG Security Functional Requirements
Not used in this ST because EMG is optional in PP [6] and the TOE does not support
EMG.
7.1.1.9 Proprietary Security Functional Requirements
The SFRs in this section provide JCOP additional proprietary features related SFRs.
FAU_SAS.1 [SCP]
(added)
Audit Data Storage (SCP)
Hierarchical to: No other components.
Dependencies: No other components.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 72 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
FAU_SAS.1.1 [SCP] The TSF shall provide [assignment: test personnel before
TOE Delivery] with the capability to store the [assignment:
Initialisation Data and/or Prepersonalisation Data and/or
supplements of the Smartcard Embedded Software] in the
[assignment: audit records].
FCS_RNG.1
(added)
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.3.1) If initialized with a random seed using a PTRNG
of class PTG.2 (as defined in [49]) as random source, the
internal state of the RNG shall have at least 256 bit of
entropy.
• (DRG.3.2) The RNG provides forward secrecy (as defined in
[49]).
• (DRG.3.3) The RNG provides enhanced backward secrecy
even if the current internal state is known (as defined in
[49])
].
FCS_RNG.1.2 The TSF shall provide [selection: random numbers] that meet
[assignment: a defined quality metric]
• (DRG.3.4) The RNG, initialized with a random seed using
a PTRNG of class PTG.2 (as defined in [49]) as random
source, generates output for which for AES-mode 248 and
for TDEA-mode 235 strings of bit length 128 are mutually
different with probability at least 1-2^24
• (DRG.3.5) Statistical test suites cannot practically
distinguish the random numbers from output sequences
of an ideal RNG. The random numbers must pass test
procedure A (as defined in [49]).
].
Application Note This functionality is provided by the certified Security Software,
see [22]
FIA_AFL.1 [PIN]
(added)
Basic Authentication Failure Handling (PIN)
Hierarchical to: No other components.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 73 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Dependencies: FIA_UID.1 Timing of identification
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].
Application Note 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.
FPT_EMSEC.1
(added)
TOE Emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMSEC.1.1 The TOE shall ensure [assignment: variations in power
consumption or timing during command execution] is
unable to use the following interface [assignment: non-
useful information] to gain access to [assignment: TSF
data: D.CRYPTO] and [assignment: User data: D.PIN,
D.APP_KEYs].
FPT_EMSEC.1.2 The TOE shall ensure [assignment: that unauthorized
users] is unable to use the following interface [assignment:
electrical contacts or RF field] to gain access to [assignment:
TSF data D.CRYPTO] and [assignment: User data D.PIN,
D.APP_KEYS].
FPT_PHP.3
(added)
Resistance to physical attack
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PHP.3.1 The TSF shall resist [assignment: physical manipulation and
physical probing] to the [assignment: TSF] by responding
automatically such that the SFRs are always enforced.
Refinement The TSF will implement appropriate mechanisms to continuously
counter physical manipulation and physical probing. Due to the
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 74 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
nature of these attacks (especially manipulation) the TSF can
by no means detect attacks on all of its elements. Therefore,
permanent protection against these attacks is required ensuring
that security functional requirements are enforced. Hence,
”automatic response” means here (i) assuming that there might
be an attack at any time and (ii) countermeasures are provided at
any time.
Application Note This SFR is taken from the certified Security IC Platform
Protection Profile [5].
7.1.1.10 Configuration Security Functional Requirements
FDP_IFC.2 [CFG]
(added)
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 control SFP] on [assignment: S.Customer,
S.NXP, S.ConfigurationMechanism, and D.CONFIG_ITEM].
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]
(added)
Simple security attributes
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 [assignment:
• S.Customer: security attributes Customer Configuration
Token
• S.NXP: security attributes NXP Configuration Token
generation key
• S.ConfigurationMechanism: security attributes NXP
Configuration Access, Customer Configuration Access
• D.CONFIG_ITEM: security attributes access privilege
].
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 75 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 generation key.
• 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
privilege 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 generation key.
].
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: [assignment: none]
FDP_IFF.1.5 [CFG] The TSF shall explicitly deny an information flow based on the
following rules: [assignment:
• 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.
].
Application note GlobalPlatform Framework authentication mechnism is used to
authenticate the tokens.
FIA_UID.1 [CFG]
(added)
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
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 76 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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]
(added)
Management of security attributes (CFG)
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 [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].
FMT_MSA.3 [CFG]
(added)
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 [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]
(added)
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: [assignment: disable the NXP
Configuration Access, disable the Customer Configuration
Access]
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 77 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
FMT_SMR.1 [CFG]
(added)
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.
Application note The roles of the CONFIGURATION information flow control SFP
are defined by the NXP Configuration Token generation key and
the Customer Configuration Token.
7.1.1.11 OS update Security Functional Requirements
The SFRs in this section provide JCOP OS Update proprietary features related SFRs.
FDP_IFC.2 [OSU]
(added)
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].
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]
(added)
Simple security attributes
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:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 78 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• S.OSU: security attributes Current Sequence Number,
Verification Key, Package Decryption Key
• D.UPDATE_IMAGE: security attributes 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.
].
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 following
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.
• If Image Type equals Downgrade then Received Sequence
Number shall be lower than Current Sequence Number.
].
FDP_IFF.1.4 [OSU] The TSF shall explicitly authorise an information flow based on
the following rules: [assignment: none]
FDP_IFF.1.5[OSU] The TSF shall explicitly deny an information flow based on the
following rules: [assignment: D.Update_image which is not
included in the pre-loaded OS Update plan]
Application note The on-card S.OSU role interacts with the off-card
S.UpdateImageCreator via OSU commands. The
D.UPDATE_IMAGE is split up into smaller chunks and
transmitted as payload within the OSU Commands to the TOE.
Application note Decrypting the D.UPDATE_IMAGE with the Package Decryption
Key prevents the authorization 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]
(added)
Static attribute initialisation (OSU)
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 79 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 [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] to specify
alternative initial values to override the default values when an
object or information is created.
FMT_MSA.1 [OSU]
(added)
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
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]
(added)
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]
(added)
Specification of Management Functions (OSU)
Hierarchical to: No other components.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 80 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Dependencies: No dependencies.
FMT_SMF.1.1 [OSU] The TSF shall be capable of performing the following
management functions: [assignment:
• query Current Sequence Number
• query Reference Sequence Number
].
Application note After the atomic activation of the additional code the Final
Sequence Number is returned on querying the Current Sequence
Number.
FIA_UID.1 [OSU]
(added)
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.
FIA_UAU.1 [OSU]
(added)
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]
(added)
Single-use authentication mechanisms (OSU)
Hierarchical to: No other components.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 81 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Dependencies: No dependencies.
FIA_UAU.4.1[OSU] The TSF shall prevent reuse of authentication data related to
[assignment: the authentication mechanism used to load
D.UPDATE_IMAGE]
FPT_FLS.1 [OSU]
(added)
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: [assignment:
• 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.1.12 Restricted Mode Security Functional Requirements
The SFRs in this section provide JCOP Restricted Mode proprietary features related
SFRs.
FDP_ACC.2 [RM]
(added)
Complete access control (RM)
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, S.ACAdmin] 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]
(added)
Security attribute based access control (RM)
Hierarchical to: No other components.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 82 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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:
• S.SD: security attributes D.ATTACK_COUNTER
• S.ACAdmin: security attributes 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 S.ACAdmin or by the 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 additional 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]].
Application Note FDP_ACF.1.2[RM]:
• 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.RM calls the ”uninstall” method of the applet instance to be
deleted, if implemented 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 protection
profile.
FMT_MSA.3 [RM]
(added)
Static attribute initialisation (RM)
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 [restrictive] default values for
security attributes that are used to enforce the SFP.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 83 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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.
FMT_MSA.1 [RM]
(added)
Management of security attributes (RM)
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] to restrict the ability to [selection: modify] the
security attributes [assignment: D.ATTACK_COUNTER] to
[assignment: ISD, S.ACAdmin].
FMT_SMF.1 [RM]
(added)
Specification of Management Functions (RM)
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 [RM] The TSF shall be capable of performing the following
management functions: [assignment:
• 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.
].
Application note After the atomic activation of the additional code the Final
Sequence Number is returned on querying the Current Sequence
Number.
FIA_UID.1 [RM]
(added)
Timing of Identification (RM)
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 84 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1 [RM] The TSF shall allow [assignment:
• authenticate to ISD
• identify the card
• query the debug logging information
• send Restricted Mode Unlock Request
• read some of the sensitive data (see [11], section 4.1)
• store some of the sensitive data in eUICC domain (see [11],
section 4.1)
] 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]
(added)
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:
• authenticate to ISD
• identify the card
• query the debug logging information
• send Restricted Mode Unlock Request
• read some of the sensitive data (see [11], section 4.1)
• store some of the sensitive data in eUICC domain (see [11],
section 4.1)
] 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.2 eUICC
The Security Functional Requirements for the eUICC component of the TOE are defined
in strict compliance with the Security Problem Definition described in the eUICC PP [8].
The following table provides the selection and assignments for SFRs:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 85 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
FIA_UID.1.1
[EXT]
[assignment: list of additional
TSF mediated actions]
no additional TSF mediated actions
FIA_UAU.1.1
[EXT]
[assignment: list of additional
TSF mediated actions]
no additional TSF mediated actions
FIA_UID.1.1
[MNO-SD]
[assignment: list of TSF-
mediated actions]
• application selection
• requesting data that identifies the eUICC
FDP_IFF.1.3
[SCP]
[assignment: additional
information flow control SFP
rules]
no additional information flow control SFP rules
FDP_IFF.1.4
[SCP]
[assignment: rules, based
on security attributes, that
explicitly authorise information
flows]
none
FTP_ITC.1.3
[SCP]
[assignment: list of functions
for which a trusted channel is
required]
The TSF shall permit the SM-DP+ to open a
SCP-SGP22 secure channel to transmit the
following operations:
• ES8+.InitialiseSecureChannel
• ES8+.ConfigureISDP
• ES8+.StoreMetadata
• ES8+.ReplaceSessionKeys
• ES8+.LoadProfileElements
The TSF shall permit the remote OTA
Platform to open a SCP80 or SCP81 secure
channel to transmit the following operation:
ES6.UpdateMetadata.
FDP_ITC.2.5
[SCP]
[assignment: additional
importation control rules]
none
FPT_TDC.1.2
[SCP]
[assignment: list of
interpretation rules to be
applied by the TSF]
the rules defined in GSMA SGP.22 Specification
[41], [42]
[assignment: cryptographic key
distribution method]
set keys and components of DES, AES, RSA,
RSA-CRT, EC, secure messaging and Network
Authentication Algorithms EC
FCS_CKM.2.1
[SCP-MNO]
[assignment: list of standards] [26], [11]
[assignment: cryptographic key
destruction method]
physically overwriting the keys in a randomized
manner
FCS_CKM.4.1
[SCP-SCM]
[assignment: list of standards] none
[assignment: cryptographic key
destruction method]
physically overwriting the keys in a randomized
manner
FCS_CKM.4.1
[SCP-MNO]
[assignment: list of standards] none
Table 80.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 86 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
FDP_ACF.1.3
[ISDR]
[assignment: rules, based
on security attributes, that
explicitly authorise access of
subjects to objects]
ISDR shall perform the following operations:
• ES8+.ConfigureISDP (Create and configure
profile)
• ES8+.StoreMetadata (Store profile metadata)
• ES10c.EnableProfile (Enable profile)
• ES10c.DisableProfile (Disable profile)
• ES10c.DeleteProfile (Delete profile)
• ES10c.eUICCMemoryReset (Perform a
Memory reset)
based on Profile ”state” and profile policy rules
”PPR”
FDP_ACF.1.4
[ISDR]
[assignment: rules, based
on security attributes, that
explicitly deny access of
subjects to objects]
when any of the defined rules by SGP.22
Specification [41], [42], related to Profile ”state”
and profile policy rules ”PPR” do not hold
FDP_ACC.1.1
[ECASD]
[assignment: additional list
of subjects, objects, and
operations between subjects
and objects covered by the
SFP]
• additional operations defined by the interfaces
ES8+ (SM-DP+ – eUICC), and ES10x (LPA –
eUICC)
• creation of an eUICC signature on material
provided by an ISD-R
FDP_ACF.1.1
[ECASD]
[assignment: additional list of
subjects and objects controlled
under the indicated SFP, and
for each, the SFP-relevant
security attributes, or named
groups of SFP-relevant security
attributes]
none
FDP_ACF.1.2
[ECASD]
[assignment: additional rules
governing access among
controlled subjects and
controlled objects using
controlled operations on
controlled objects]
Rules defined in section 2.4.of GSMA SGP.22
Specification [41], [42]
FDP_ACF.1.3
[ECASD]
[assignment: rules, based
on security attributes, that
explicitly authorise access of
subjects to objects]
none
FDP_ACF.1.4
[ECASD]
[assignment: rules, based
on security attributes, that
explicitly deny access of
subjects to objects]
none
FDP_IFF.1.3
[Platform-
Services]
[assignment: additional
information flow control SFP
rules]
no additional information flow control SFP rules
FDP_IFF.1.4
[Platform-
Services]
[assignment: rules, based
on security attributes, that
explicitly authorise information
flows]
none
Table 80. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 87 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
FDP_IFF.1.5
[Platform-
Services]
[assignment: rules, based
on security attributes, that
explicitly deny information
flows]
• when none of the conditions listed in the
element FDP_IFF.1.4 of this component.
• Hold and at least one of those listed in the
element FDP_IFF.1.2 does not hold.
FPT_FLS.1.1
[Platform-
Services]
[assignment: other type of
failure]
none
[assignment: types of
emissions]
variations in power consumption or timing
during command execution
FPT_
EMSEC.1.1
[eUICC]
[assignment: specified limits] non-useful information
[assignment: type of users] that unauthorized users
FPT_
EMSEC.1.2
[eUICC]
[assignment: type of
connection]
electrical contacts or RF field
FMT_SMF.1
[eUICC]
[assignment: list of
management functions to be
provided by the TSF]
Profile Management functions specified in
GSMA SGP.22 [41], [42]
[assignment: cryptographic key
distribution method]
set keys and components of DES, AES, RSA,
RSA-CRT, EC, secure messaging and Network
Authentication Algorithms EC
FCS_CKM.2.1
[Mobile_
network]
[assignment: list of standards] [26], [11]
FCS_COP.1.1
[Mobile_
network]
[selection: other algorithm, no
other algorithm]
other algorithms (USIM_TEST and CDMA)
[assignment: cryptographic key
destruction method]
physically overwriting the keys in a randomized
manner
FCS_CKM.4.1
[Mobile_
network]
[assignment: list of standards] none
Table 80. ...continued
7.1.3 CSP
The Security Functional Requirements for the CSP component of the TOE are defined in
strict compliance with the Security Problem Definition described in the CSP PP [9].
The following table provides the selection and assignments for SFRs:
SFR ID Selection / Assignment text Selection / Assignment value
FDP_ACC.1.1
[KM]
(1) [selection: Administrator,
Crypto-Officer]
Administrator
FMT_MSA.1.1
[KM]
(1) [selection: Administrator,
Crypto-Officer]
(4) [selection: Administrator,
Crypto-Officer]
(5) [selection: Administrator,
Crypto-Officer, Key Owner]
Administrator
Administrator
Administrator, Key Owner
FMT_MSA.3.2
[KM]
[selection: Administrator,
Crypto-Officer]
Administrator
Table 81.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 88 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
FMT_MTD.1.1
[KM]
(1) [selection: Administrator,
Crypto-Officer, Key Owner]]
(2) [selection: Administrator,
Crypto-Officer]
(3) [selection: Administrator,
Crypto-Officer, Key Owner]
(4) [selection: Administrator,
Crypto-Officer, Key Owner]
Administrator, Key Owner
Administrator
Administrator, Key Owner
Administrator, Key Owner
FMT_MTD.1.1
[RK]
(1) [selection: Administrator,
Crypto-Officer]
(2) [selection: Administrator,
Crypto-Officer]
Administrator
Administrator
FCS_CKM.1.1
[AES]
[selection: 256 bits, no other
key size]
256 bits
[assignment: input parameters] derivation data
FCS_CKM.5.1
[AES]
[selection: 256 bits, no other
key size]
256 bits
[selection: elliptic curves in the
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
[selection: key size in the table
2 ([9])]
• 256-bit
• 384-bit
• 521-bit
• 256-bit
• 384-bit
• 521-bit
FCS_CKM.1.1
[ECC]
[selection: standards in the
table 2 ([9])]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.4 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.5 [FIPS PUB
186-4]
[assignment: input parameters] derivation data
FCS_CKM.5.1
[ECC]
[selection: elliptic curves in
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 89 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[assignment: KDF] CSP KDF
[selection: key size in the table
2 ([9])]
• 256-bit
• 384-bit
• 521-bit
• 256-bit
• 384-bit
• 521-bit
[selection: standards in the
table 2 ([9])]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.4 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.5 [FIPS PUB
186-4]
FCS_CKM.1.1
[RSA]
[assignment: cryptographic key
sizes]
from 2000 bit, up to 4096 bit in 8 bit steps
[selection: AES-256, none
other]
AES-256
[selection: elliptic curves in
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
[selection: DH group in table 3
([9])]
• 256-bit random ECP group
• 384-bit random ECP group
• 521-bit random ECP group
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
[assignment: key derivation
function]
ANSI X9.63 key derivation function
FCS_CKM.5.1
[ECDHE]
[selection:256 bits, none other] 256-bit
FCS_CKM.1.1
[ECKA-EG]
[selection: elliptic curves in
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 90 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[selection: key size in the table
2 ([9])]
• 256-bit
• 384-bit
• 521-bit
• 256-bit
• 384-bit
• 521-bit
[selection: standards in the
table 2 ([9])]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.4 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.5 [FIPS PUB
186-4]
[selection: AES-256, none
other]
AES-256
[selection: elliptic curves in
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
FCS_CKM.5.1
[ECKA-EG]
[selection:256 bits, none other] 256 bits
[selection: AES-256, none
other]
AES-256
FCS_CKM.1.1
[AES_RSA]
[selection:256 bits, none other] 256 bits
[selection: AES-256, none
other]
AES-256
FCS_CKM.5.1
[AES_RSA]
[selection:256 bits, none other] 256 bits
[selection: KW, KWP] KWP
FCS_COP.1.1
[KW]
[selection:256 bits, none other] 256 bits
[selection: KW, KWP] KWP
FCS_COP.1.1
[KU]
[selection:256 bits, none other] 256 bits
FPT_ISA.1.5
[CK]
(2) [assignment: additional
importation control rules]
none
FPT_ESA.1.4
[CK]
[assignment: additional
exportation control rules]
none
[selection: AES-256, no other
algorithm]
AES-256
FCS_COP.1.1
[ED]
[selection: CRT, OFB, CFB, no
other]
CRT, OFB, CFB
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 91 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[selection: 256 bits, no other
key size]
256 bits
[selection: FCS_CKM.1/ECKA-
EG, FCS_CKM.1/AES_RSA,
FCS_CKM.5/ECDHE]
FCS_CKM.1/ECKA-EG, FCS_CKM.1/AES_
RSA
[selection: AES-256, none
other]
AES-256
[selection: CBC [54], CCM [56],
GCM [57]]
CBC [54], CCM [56], GCM [57]
[selection: CMAC [55], GMAC
[57], HMAC [58]]
CMAC [55], GMAC [57], HMAC [58]
FCS_COP.1.1
[HEM]
[selection: 256 bits, no other
key size]
256 bits
[selection: FCS_CKM.5/
ECDHE, FCS_CKM.5/ECKA-
EG, FCS_CKM.5/AES_RSA]
FCS_CKM.5/ECKA-EG, FCS_CKM.5/AES_
RSA
[selection: CMAC [55], GCM
[57], HMAC [58]]
CMAC [55], GCM [57], HMAC [58]
[selection: AES-256, none
other]
AES-256
[selection: CBC [54], CCM [56],
GMAC [57]]
CBC [54], CCM [56], GMAC [57]
FCS_COP.1.1
[HDM]
[assignment: cryptographic key
sizes]
256 bits
[selection: AES-256, none
other]
AES-256
[selection: GMAC [57], no
other]
GMAC [57]
FCS_COP.1.1
[MAC]
[selection: 256 bits, no other
key size]
256 bits
[selection: HMAC-SHA-1,
HMAC-SHA384, no other]
HMAC-SHA-1, HMAC-SHA384
FCS_COP.1.1
[HMAC]
[assignment: cryptographic key
sizes]
from 128 bit to 896 bit in 8 bit steps
[selection: elliptic curves in the
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
FCS_COP.1.1
[CDS-ECDSA]
[selection: key size in the table
2 ([9])]
• 256-bit
• 384-bit
• 521-bit
• 256-bit
• 384-bit
• 521-bit
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 92 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
[selection: standards in the
table 2 ([9])]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.4 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.5 [FIPS PUB
186-4]
[selection: elliptic curves in the
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
[selection: key size in the table
2 ([9])]
• 256-bit
• 384-bit
• 521-bit
• 256-bit
• 384-bit
• 521-bit
FCS_COP.1.1
[VDS-ECDSA]
[selection: standards in the
table 2 ([9])]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• RFC5639 [RFC5639], TR-03111, section
4.1.3 [TR-03111]
• FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.4 [FIPS PUB
186-4]
• FIPS PUB 186-4 B.4 and D.1.2.5 [FIPS PUB
186-4]
FCS_COP.1.1
[CDS-RSA]
[assignment: cryptographic key
sizes]
2000 bit up to 4096 bit in 8 bit steps
FCS_COP.1.1
[VDS-RSA]
[assignment: cryptographic key
sizes]
2000 bit up to 4096 bit in 8 bit steps
FDP_DAU.2.1
[Sig]
[selection: FCS_COP.1/CDS-
RSA, FCS_COP.1/CDS-
ECDSA]
FCS_COP.1/CDS-RSA, FCS_COP.1/CDS-
ECDSA
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 93 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
FDP_DAU.2.1
[Att]
[selection: FCS_COP.1/
CDS-RSA, FCS_COP.1/
CDS-ECDSA, ECDAA
according to [selection:
[59][60]], [assignment: other
cryptographic authentication
mechanism]]
FCS_COP.1/CDS-RSA, FCS_COP.1/CDS-
ECDSA according to respectively RSA and
ECDSA digital signature mechanisms
[selection: logically separated
from other communication
channels, using physical
separated ports]
logically separated from other communication
channels
[selection: Authentication
of TOE and remote entity
according to the case in table
4] ([9])
• FIA_API.1/PACE, FIA_UAU.5.1 (2)
• FIA_API.1/CA, FIA_UAU.5.1 (4) or (5), and
(6)
[assignment: according to the
case in table 4] ([9])
• modfication, disclosure
• modfication, disclosure
FTP_ITC.1.1
[CSP]
[selection: cryptographic
operation according to the case
in table 4] ([9])
• FCS_COP.1/TCM
• FCS_COP.1/TCE
[selection: elliptic curves in the
table 2 ([9])]
• brainpoolP256r1
• brainpoolP384r1
• brainpoolP521r1
• Curve P-256
• Curve P-384
• Curve P-521
FCS_CKM.1.1
[PACE]
[selection: 128 bits, 192 bits,
256 bits]
128 bits, 192 bits, 256 bits
FCS_CKM.1.1
[TCAP]
[selection: 128 bits, 192 bits,
256 bits]
128 bits, 192 bits, 256 bits
[selection: CBC [54], CCM [56],
GCM [57]]
CBC [54], CCM [56], GCM [57]
FCS_COP.1.1
[TCE]
[selection: 128 bits, 192 bits,
256 bits]
128 bits, 192 bits, 256 bits
[selection: CMAC [55], GMAC
[57]]
CMAC [55], GMAC [57]
FCS_COP.1.1
[TCM]
[selection: 128 bits, 192 bits,
256 bits]
128 bits, 192 bits, 256 bits
(1) [selection: Administrator,
User Administrator]
User Administrator
(2) [selection: Administrator,
User Administrator]
User Administrator
(4) [selection: Administrator,
User Administrator]
User Administrator
(5) [assignment: time frame] time frame chosen by the User Administrator
FMT_MTD.1.1
[RAD]
(5) [selection: Administrator,
User Administrator]
User Administrator
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 94 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
(6) [selection: Unidentified user,
Unauthenticated user]
Unauthenticated user
(6) [selection: Administrator,
User Administrator]
User Administrator
[selection: [assignment:
positive integer
number]number], an
[selection: Administrator, User
Administrator] configurable
positive integer within
[assignment: range of
acceptable values]]
Administrator configurable positive integer
within a range of values determined by this
administrator
FIA_AFL.1.1
[CSP]
[assignment: list of
authentication events]
consecutive failed authentication attempt
[assignment: met, surpassed] met
FIA_AFL.1.2
[CSP]
[assignment: list of actions] explicitly delete the password
FMT_SAE.1.1
[CSP]
[selection: Administrator, User
Administrator]
User Administrator
FIA_UID.1.1
[CSP]
(3) [assignment: list of other
TSF-mediated actions]
none
(3) [selection: a role, a set of
role]
a role
FIA_UAU.1.1
[CSP]
(4) [assignment: list of other
TSF-mediated actions]
none
FIA_UAU.5.2
[CSP]
(7) [assignment: additional
rules]
none
FIA_UAU.6.1
[CSP]
(4) [assignment: list of other
conditions under which re-
authentication is required]
none
(1) [selection: Administrator,
Crypto-Officer]
Administrator
FDP_ACC.1.1
[Oper]
(1) [assignment: other roles] none
(1) [selection: Administrator,
Crypto-Officer]
Administrator
FDP_ACF.1.1
[Oper]
(1) [assignment: other roles] None
(1) [selection: Administrator,
Crypto-Officer]
Administrator
FDP_ACF.1.2
[Oper]
(3) [assignment: other rules
governing access among
controlled subjects and
controlled objects using
controlled operations on
controlled objects]
none
FDP_ACF.1.3
[Oper]
(1 - Table 5) [selection:
Administrator, Crypto-Officer,
Key Owner]
Administrator, Key Owner
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 95 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
(1 - Table 5) [selection:
Administrator, Crypto-Officer,
Key Owner]
Administrator, Key Owner
(2) [assignment: additional
rules, based on security
attributes, that explicitly
authorise access of subjects to
objects]
none
FDP_ACF.1.4
[Oper]
(3) [assignment: additional
rules, based on security
attributes, that explicitly deny
access of subjects to objects]
none
FMT_SMF.1.1
[CSP]
(4) [assignment: additional
list of security management
functions to be provided by the
TSF]
none
[selection: Administrator,
Crypto-Officer, User
Administrator, Update Agent]
Administrator, User Administrator, Update Agent
FMT_SMR.1.1
[CSP]
[selection: [assignment: other
roles], no other roles]
no other roles
FMT_MSA.2.1
[CSP]
(4) [assignment: additional
security attributes]
none
(1) [selection: Administrator,
User Administrator]
User Administrator
(2) [selection: Administrator,
User Administrator]
User Administrator
(3) [selection: Administrator,
User Administrator]
User Administrator
FMT_MOF.1.1
[CSP]
(4) [selection: Administrator,
User Administrator]
User Administrator
FDP_SDC.1.1
[CSP]
[assignment: memory area] NVM
FPT_TST.1.1
[CSP]
[assignment: parts of TSF] the TSF
[assignment: cryptographic
algorithm]
ECDSA with NIST P-256, Brainpool P256r1
[assignment: cryptographic key
sizes]
256 bits
FCS_COP.1.1
[VDSUCP]
[assignment: list of standards] FIPS 186-4 [52]
[assignment: cryptographic
algorithm]
AES-128 in CBC mode
[assignment: cryptographic key
sizes]
128 bits
FCS_COP.1.1
[DecUCP]
[assignment: list of standards] [54]
Table 81. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 96 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR ID Selection / Assignment text Selection / Assignment value
FDP_ACC.1.1
[UCP]
[selection: Administrator,
Update Agent]
Update Agent
FDP_ACF.1.1
[UCP]
[selection: Administrator,
Update Agent]
Update Agent
(1) [selection: Administrator,
Update Agent]
Update Agent
(2) [selection: Administrator,
Update Agent]
Update Agent
FDP_ACF.1.2
[UCP]
(2) (b) the Version Number
of the Update Code Package
is equal or higher than the
Version Number of the TSF
This statement is covered by a requirement into
the UGM [15]
FDP_ACF.1.3
[UCP]
[assignment: rules, based
on security attributes, that
explicitly authorise access of
subjects to objects]
None
FDP_ACF.1.4
[UCP]
[assignment: rules, based
on security attributes, that
explicitly deny access of
subjects to objects]
None
Table 81. ...continued
7.2 Security Assurance Requirements
The assurance requirements of this evaluation are EAL5 augmented by AVA_VAN.5,
ALC_DVS.2, ASE_TSS.2, and ALC_FLR.1. This applies to all PP claimed in Section 2.3.
The assurance requirements ensure, among others, the security of the TOE during its
development and production.
7.3 Security Functional Requirements Dependencies
7.3.1 JCOP
Requirements CC Dependencies Satisfied dependencies
FDP_ACC.1[SD] FDP_ACF.1 Security attribute
based access control
FDP_ACF.1[SD]
FDP_ACC.2[RM] FDP_ACF.1 Security attribute
based access control
FDP_ACF.1[RM]
FDP_ACF.1[SD] FDP_ACC.1 Subset access
control FMT_MSA.3 Static
attribute initialisation
FDP_ACC.1[SD]
FMT_MSA.3[SD]
FDP_ACF.1[RM] FDP_ACC.1 Subset access
control FMT_MSA.3 Static
attribute initialisation
FDP_ACC.2[RM]
FMT_MSA.3[RM]
Table 82.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 97 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Requirements CC Dependencies Satisfied dependencies
FDP_ROL.1[CCM] [FDP_ACC.1 Subset access
control, or FDP_IFC.1 Subset
information flow control]
FDP_ACC.1[SD]
FIA_AFL.1[PIN] FIA_UAU.1 Timing of
authentication
see AppNote in FIA_
AFL.1[PIN]
FIA_UID.1[OSU] No dependencies
FIA_UID.1[CFG] No dependencies
FIA_UID.1[RM] No dependencies
FIA_UAU.1[SC] A_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
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
Management Functions
FDP_IFC.2[OSU]
FMT_SMR.1[OSU]
FMT_SMF.1[OSU]
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
Management 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
Management 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
Management Functions
FDP_ACC.2[RM]
FMT_SMR.1[SD]
FMT_SMF.1[RM]
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[OSU]
FMT_SMR.1[OSU]
Table 82. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 98 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Requirements CC Dependencies Satisfied dependencies
FMT_MSA.3[SD] FMT_MSA.1 Management of
security attributes FMT_SMR.1
Security roles
FMT_MSA.1[OSU]
FMT_SMR.1[OSU]
FMT_MSA.3[RM] FMT_MSA.1 Management of
security attributes FMT_SMR.1
Security roles
FMT_MSA.1[OSU]
FMT_SMR.1[OSU]
FMT_SMF.1[OSU] No dependencies
FMT_SMF.1[CFG] No dependencies
FMT_SMF.1[SD] No dependencies
FMT_SMF.1[RM] No dependencies
FMT_SMR.1[OSU] FIA_UID.1 Timing of
identification
FIA_UID.1[OSU]
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]
FPT_EMSEC.1 No dependencies
FPT_FLS.1[OSU] No dependencies
FPT_FLS.1[CCM] No dependencies
FPT_PHP.3 No dependencies
Table 82. ...continued
7.3.1.1 JCOP Rationale for Exclusion of Dependencies
The dependency FIA_UID.1 of FMT_SMR.1[INSTALLER] is unsupported. This ST
does not require the identification 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.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 99 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.3.2 eUICC
The Security Functional Requirements dependencies for the eUICC component are
strictly the same in the eUICC PP [8].
7.3.3 CSP
The Security Functional Requirements dependencies for the the CSP component are the
same in the CSP PP [9] with only the following differences:
• FCS_COP.1[VDSUCP]: the import of UCP signature verification key is done during
manufacturing.
• FCS_COP.1.1[DecUCP]: the import of UCP decryption key is done during
manufacturing.
7.4 Security Requirements Rationales
7.4.1 Security Assurance Requirements Rationale
The selection of assurance components is based on the following underlying PPs:
• JavaCard [6]
• eUICC [8]
• CSP [9]
The Security Target uses the augmentations from the PP, chooses EAL5 and adds the
components AVA_VAN.5 ALC_DVS.2, ASE_TSS.2 and ALC_FLR.1
The rationale for the augmentations is the same as in the PP.
The assurance level EAL5 is an elaborated pre-defined level of the CC, part 3 [3]. The
assurance components in an EAL level are chosen in a way that they build a mutually
supportive and complete set of components. The additional requirements chosen for
augmentation do not add any dependencies, which are not already fulfilled for the
corresponding requirements contained in EAL5. Therefore, the components AVA_VAN.5,
ALC_DVS.2, ASE_TSS.2 and ALC_FLR.1 and ALC_FLR.1 add additional assurance to
EAL5, but the mutual support of the requirements is still guaranteed.
7.4.2 Security Functional Requirements Rationales
7.4.2.1 JCOP
The following rationales of Security Functional Requirements for the JCOP component
only covers the modifications regarding the Java Card PP [6] due to additions and
refinements in Security Functional Requirements and Security Objectives.
7.4.2.1.1 Execution
7.4.2.1.1.1 OT.OPERATE
SFR Rationale
FIA_AFL.1[PIN] Contributes to meet the objective by protecting the authentication.
Table 83.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 100 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.4.2.1.2 Applet Management
7.4.2.1.2.1 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 algorithm 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.
Table 84.
7.4.2.1.2.2 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 restrictions) 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 restrictions) 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 restrictions) 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 restrictions) 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 restrictions) 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 restrictions) 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 management 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 management 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 management 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 management operations.
Table 85.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 101 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR Rationale
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 management operations.
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 management 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 management 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 management 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 management 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 management operations.
Table 85. ...continued
7.4.2.1.2.3 OT.COMM_AUTH
SFR Rationale
FCS_COP.1 Contributes to meet the security objective by specifying secure
cryptographic algorithm that shall be used to determine 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 authenticate 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 authenticate card management
commands.
FDP_IFF.1[SC] Contributes to meet the security objective by specifying the authorized
identified roles enabling to send and authenticate card management
commands.
FMT_MSA.1[SC] Contributes to meet the security objective by specifying security
attributes enabling to authenticate card management requests.
FMT_MSA.3[SC] Contributes to meet the security objective by specifying security
attributes enabling to authenticate card management 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.
Table 86.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 102 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.4.2.1.2.4 OT.COMM_INTEGRITY
SFR Rationale
FCS_COP.1 Contributes to meet the security objective by by specifying 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 management 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 policy 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 policy 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 management commands.
Table 87.
7.4.2.1.2.5 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 management requests for which the
confidentiality has to be ensured.
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 policy to guarantee the
confidentiality of administration requests.
FDP_IFF.1[SC] Contributes to cover the security objective by enforcing the Secure
Channel Protocol information flow control policy to guarantee the
confidentiality of administration requests.
FMT_MSA.1[SC] Contributes to cover the security objective by specifying security
attributes enabling to guarantee the confidentiality of card management
requests by decrypting those requests and imposing management
conditions on that attributes.
Table 88.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 103 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR Rationale
FMT_MSA.3[SC] Contributes to cover the security objective by specifying security
attributes enabling to guarantee the confidentiality of card management
requests by decrypting those requests and imposing management
conditions on that attributes.
FMT_SMF.1[SC] Contributes to cover the security objective by specifying the actions
ensuring the confidentiality of the card management commands.
Table 88. ...continued
7.4.2.1.3 Card Management
7.4.2.1.3.1 OT.CARD-MANAGEMENT
SFR Rationale
FDP_ACC.2[ADEL] Contributes to meet the objective by the ADEL access control policy
which ensures the non-introduction of security 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 security 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 Channel 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.
Table 89.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 104 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR Rationale
FDP_ACC.1[SD] Contributes to cover this security objective by enforcing a Security
Domain access control policy (rules and restrictions) 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 restrictions) 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 restrictions) 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 restrictions) 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 restrictions) 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 restrictions) 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 management 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 management 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 management 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 management 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 management 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 management operations.
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 management 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 management 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 management 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 management operations.
Table 89. ...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 105 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.4.2.1.4 Smart Card Platform
7.4.2.1.4.1 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 physical tampering.
FPR_UNO.1 Contributes to the coverage of the objective by ensuring leakage
resistant implementations of the unobservable operations.
FPT_EMSEC.1 Contributes to meet the objective.
FPT_PHP.3 Contributes to the coverage of the objective by preventing bypassing,
deactivation or changing of other security features.
7.4.2.1.4.2 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.
7.4.2.1.4.3 OT.SCP.SUPPORT
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.
7.4.2.1.4.4 OT.IDENTIFICATION
SFR Rationale
FAU_SAS.1[SCP] Covers the objective.The Initialisation Data (or parts of them) are used
for TOE identification
7.4.2.1.5 Config Applet
7.4.2.1.5.1 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.
Table 90.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 106 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR Rationale
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 identification before
modifying configuration items.
Table 90. ...continued
7.4.2.1.6 OS Update
7.4.2.1.6.1 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.
FIA_UAU.1[OSU] Contributes to the coverage of the objective by requiring authentication.
Table 91.
7.4.2.1.6.2 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 Update 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.
Table 92.
7.4.2.1.6.3 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 authenticity and integrity.
Table 93.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 107 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SFR Rationale
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).
Table 93. ...continued
7.4.2.1.6.4 OT.SECURE_AC_ACTIVATION
SFR Rationale
FMT_MSA.1[OSU] Contributes to the coverage of the objective by allowing to modify the
Current Sequence Number only after successful 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 Number).
FPT_FLS.1[OSU] Contributes to the coverage of the objective by ensuring atomicity of the
OS Update procedure (Load Phase).
Table 94.
7.4.2.1.6.5 OT.TOE_IDENTIFICATION
SFR Rationale
FDP_SDI.2 Contributes to cover the objective by storing the identification data
(D.TOE_IDENTIFICATION) in an integrity protected store.
FMT_SMF.1[OSU] Contributes to cover the objective by providing the ability to query the
identification data (Current Sequence Number, Reference Sequence
Number, Final Sequence Number) of the TOE.
Table 95.
7.4.2.1.7 Restricted Mode
7.4.2.1.7.1 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 initial 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 authentication before
resetting the Attack Counter.
FIA_UID.1[RM] Contributes to cover the objective by requiring identification before
resetting the Attack Counter.
Table 96.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 108 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.4.2.1.7.2 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 management functions
of the restricted mode.
FIA_UAU.1[RM] Contributes to cover the objective by requiring authentication before
resetting the Attack Counter.
FIA_UID.1[RM] Contributes to cover the objective by requiring identification before
resetting the Attack Counter.
Table 97.
7.4.2.1.8 Optional Augmentation packages
The rationales for the augmentation packages are exactly as defined in the PP [6].
None of the packages are applicable to R1.x products. The packages applicable to R2.x
products are detailed below.
7.4.2.1.8.1 Augmentation Packages for R2.x
Optional Augmentation Package
Sensitive Result
Monotonic Counters
Cryptographic Certification Management
Key Derivation Functions
System Time
Table 98.
7.4.2.2 eUICC
The rationale of Security Functional Requirements for the the eUICC component is
strictly the same as in the eUICC PP [8].
7.4.2.3 CSP
The rationale of Security Functional Requirements for the CSP component is strictly the
same as in the CSP PP [9].
8 TOE summary specification (ASE_TSS)
8.1 Introduction
The Security Functions (SF) introduced in this section realize the SFRs of the TOE and
are classed according to the TOE components they belong to, JCOP (Table 99) , eUICC
(Table 101) and CSP(Table 102) .
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 109 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
8.2 Security Functionality
8.2.1 JCOP
The common Security Functionality is detailed in Table 99 whilst additional functionality
which fulfills the requirements for the implemented optional augmentation packages is
detailed in Table 100.
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 [24] and [25]. 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 to fulfill FMT_MSA.1[JCRE] and FMT_
MSA.1[JCVM]. All values for security attributes are initialized and
assigned by the system itself which fulfills FMT_MSA.2[FIREWALL-
JCVM], FMT_MSA.3[FIREWALL], and FMT_MSA.3[JCVM].
The full Java Card implementation is then controlled by this mechanism
including GlobalPlatform GlobalPlatform Amendments A [31], B [32], C
[34], D [35], E [36], F [37], H [38] and I [39].
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 operations.
Additionally, SF.CONFIG provides proprietary commands to select (FIA_
UID.1[SC]) the OS update mechanism SF.OSU and to reset the OS to an
initial state (FAU_ARP.1 and FPT_FLS.1).
Table 99. Security Functionality for JCOP
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 110 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SF.OPEN Card Content Management
SF.OPEN provides the card content management functionality
according the GlobalPlatform Specification [29] and GlobalPlatform
Amendments A [31], B [32], C [34], D [35], E [36] and F [37]. This
supports 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 Environment
specification [25] 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 [29], the Java Card Runtime Environment
Specification [25], and the Java Card API Specification [26] 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
SF.CRYPTO provides key creation, key management, key deletion and
cryptographic functionality. It provides the API in accordance to the
Java Card API Specification [26] to fulfill FCS_CKM.1, 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.4, FDP_RIP.1[KEYS], and FDP_SDI.2[DATA]. The Security
Software certified with the TOE hardware supports FCS_COP.1 and
FPR_UNO.1.
This TSF enforces protection of Key material during cryptographic
functions processing and Key Generation, against state-of-the-art
attacks, including IC power consumption analysis (FPT_EMSEC.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 [26] 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 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[DATA], FAU_ARP.1, and FPT_FLS.1. The stored data is
AES encrypted to fulfill FPR_UNO.1.
Table 99. Security Functionality for JCOP...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 111 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SF.OSU Operating System Update
SF.OSU provides secure functionality to update the JCOP6.2 OS
or UpdaterOS itself with an image 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].
CSP requirements are covered as well:
• Access control and transfer conditions FDP_ITC.2[UCP], FPT_
TDC.1[UCP], FDP_ACC.1[UCP] and FDP_ACF.1[UCP] are covered
as FDP_IFC.2[OSU], FDP_IFF.1[OSU], FIA_UID.1[OSU], FIA_
UAU.1[OSU] and FIA_UAU.4[OSU] as those ones cover same
requirements on package reception handling: authenticity verification,
decryption, version (sequence number in the current product).
• FCS_COP.1[VDSUCP] and FCS_COP.1[DecUCP] requirements are
covered by the ECDH and ECDSA for signature verification, and by
AES encryption.
• FDP_RIP.1[UCP] is covered as FDP_RIP.1[TRANSIENT]
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 [25] 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 [25]. 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 fulfills 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 specified in the Java Card API Specification [26] and
the GlobalPlatform Specification [33]. Thus, it fulfills FDP_SDI.2[DATA],
FIA_AFL.1[PIN], and FPR_UNO.1.
Table 99. Security Functionality for JCOP...continued
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 112 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SF.PERS_MEM Persistent Memory Management
SF.PERS_MEM provides atomic write operations and transaction
management according to the Java Card Runtime Environment
Specification [25]. 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 memory 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 [11].
The API throws a Java Exception in case the checksum in invalid. This
supports FAU_ARP.1 and FPT_FLS.1.
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, to ensure the system goes to a secure
state to fulfill FAU_ARP.1 and FPT_FLS.1, as well as to increase the
attack counter in order to resist physical manipulation and probing to
fulfill FPT_PHP.3.
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 operations 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.8. This feature supports FAU_SAS.1.1[SCP] by using initialization
data that is used for platform identification.
SF.SMG_NSC No Side-Channel
The TSF ensures that during command execution there are no usable
variations in power consumption (measurable at e.g. electrical contacts)
or timing (measurable at e.g. electrical contacts) that might disclose
cryptographic keys or PINs. All functions of SF.CRYPTO except for SHA
are resistant to side-channel attacks (e.g. timing attack, SPA, DPA, DFA,
EMA, DEMA) (see FPR_UNO.1 and FPT_EMSEC.1).
Table 99. Security Functionality for JCOP...continued
SF.SENSITIVE_
RESULT
Sensitive Result
provides methods for asserting results of sensitive functions. FDP_SDI.2/
RESULT Integrity_Sensitive_Result
SF.COUNTER MONOTONIC COUNTER
provides methods for creating a counter that can only be increased,
never decreased. FDP_SDI.2/MONOTONIC_COUNTER ensures an
exception is thrown in the case of an integrity error on the counter object.
Table 100. Security Functionality for R2.x Augmentation Packages
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 113 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SF.COUNTER Monotonic counter
provides methods for creating a counter that can only be increased,
never decreased.
SF.CERT_MNGT Cryptographic Certificate Management
provides secure management of public key certificates from the
javacardx.security.cert package of the Java Card platform. FCS_COP.1/
CRT_MNGT Certificate Management ensures the verification of a
certificate and FDP_SDI.2.1/CRT_MNGT ensures an exception is thrown
on the detection of any data integrity errors.
SF.KEY_DERIVATION Cryptographic Key Derivation
provides secure management of public key certificates from the
javacardx.security.cert package of the Java Card platform. FCS_CKM.5/
KDF Key Derivation Function ensures the derivation algorithms are
correctly implemented.
SF.TIME System Time
provides methods for handling system time, suitable for timestamps or
for estimating intervals between events. FPT_STM.1/SYS_TIME ensures
the system shall be able to provide reliable time stamps.
Table 100. Security Functionality for R2.x Augmentation Packages...continued
8.2.2 eUICC
SF.CRYPTO_eUICC eUICC specific cryptographic algorithms
This TSF provides key creation, key management, key deletion
and cryptographic functionality specific to the eUICC component.
It provides the API in accordance to eUICC specification
[41], [42] to fulfill FCS_CKM.1[SCP-SM], FCS_CKM.2[SCP-
MNO], FCS_CKM.2[Mobile_network], FCS_CKM.4[SCP-SM],
FCS_CKM.4[SCP-MNO], FCS_CKM.4[Mobile_network], and
FCS_COP.1[Mobile_network].
This TSF also enforces protection of key material during cryptographic
functions processing and key Generation, against state-of-the-art
attacks, including IC power consumption analysis (FPT_EMSEC.1).
SF.ACCESS_eUICC eUICC features access protection
This TSF handles the access to eUICC features by external or local
users. It based on JavaCard and GlobalPlatform features to implement
the different flow controls (FDP_IFC.1[SCP], FDP_IFF.1[SCP],
FDP_IFC.1[Platform_services], FDP_IFF.1[Platform_services],
FPT_FLS.1[Platform_services]), access control (FDP_ACC.1[ISDR],
FDP_ACF.1[ISDR], FDP_ACC.1[ECASD], FDP_ACF.1[ECASD])
and related dependencies (FMT_MSA.1[PLATFORM_DATA],
FMT_MSA.1[PPR], FMT_MSA.1[CERT_KEYS], FMT_SMF.1[eUICC],
FMT_SMR.1[eUICC], FMT_MSA.1[RAT], FMT_MSA.3[eUICC]), as
well as the conditions realization granting the access: identification/
authentication of users (FIA_UID.1[EXT], FIA_UAU.1[EXT],
FIA_UAU.4[EXT], FIA_USB.1[EXT], FIA_UID.1[MNO-SD],
FIA_USB.1[MNO-SD], FIA_ATD.1[eUICC], FIA_API.1[eUICC]) and
the different trusted channels establishment (FTP_ITC.1[SCP],
FDP_ITC.2[SCP], FPT_TDC.1[SCP], FDP_UCT.1[SCP],
FDP_UIT.1[SCP]) in compliance with [41] [42] .
Table 101. Security Functionality for eUICC
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 114 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
SF.SELF-
PROTECTION_eUICC
eUICC specific self-protections
This TSF extends the scope of self-protections features provided by the
JavaCard platform to the eUICC component needs (FDP_SDI.1[eUICC],
FDP_RIP.1[eUICC], FPT_FLS.1[eUICC]).
Table 101. Security Functionality for eUICC...continued
8.2.3 CSP
SF.CRYPTO_CSP CSP specific cryptography
This TSF provides key creation, key management, key deletion and
cryptographic functionality specific to the CSP component. It provides the
API in accordance to CSP specification [46] to fulfill FCS_CKM.1[AES],
FCS_CKM.5[AES], FCS_CKM.1[ECC], FCS_CKM.5[ECC],
FCS_CKM.1[RSA], FCS_CKM.5[ECDHE], FCS_CKM.1[ECKA-EG],
FCS_CKM.5[ECKA-EG], FCS_CKM.1[AES-RSA], FCS_CKM.5[AES-
RSA], FCS_COP.1[Hash], FCS_COP.1[KW], FCS_COP.1[KU],
FCS_COP.1[ED], FCS_COP.1[HEM], FCS_COP.1[HDM],
FCS_COP.1[MAC], FCS_COP.1[HMAC], FCS_COP.1[CDS-ECDSA],
FCS_COP.1[VDS-ECDSA], FCS_COP.1[CDS-RSA], FCS_COP.1[VDS-
RSA], FCS_COP.1[TCE], FCS_COP.1[TCM], FCS_CKM.1[PACE],
FCS_CKM.1[TCAP]. All those are implemented in the JCOP platform.
The specific storage of keys requested by FDP_SDC.1[CSP] is covered
by AES encryption implemented provided by the JCOP platform.
SF.ACCESS_CSP CSP access protection features
This TSF handles the access to CSP features by external or local users.
It bases on JavaCard and GlobalPlatform features to implement different
access control (FDP_ACC.1[Oper], FDP_ACF.1[Oper], DP_ACC.1[KM])
and the conditions realization granting the access: identification/
authentication of users (FIA_ATD.1[CSP], FIA_AFL.1[CSP], FIA_
USB.1[CSP], FIA_UID.1[CSP], FIA_UAU.1[CSP], FIA_UAU.5[CSP],
FIA_UAU.6[CSP], FIA_API.1[CA], FIA_API.1[PACE]) and trusted
channels establishment (FTP_ITC.1[CSP]).
Related security attributes and data are also based on JavaCard
features (FMT_SMF.1[CSP], FMT_SMR.1[CSP], FMT_MOF.1[CSP],
FMT_MSA.1[KM], FMT_MSA.2[CSP], FMT_MSA.3[KM], FMT_
MTD.1[KM], FMT_MTD.1[RAD], FMT_MTD.1[RK], FMT_MTD.3[CSP],
FMT_SAE.1[CSP])
SF.SERVICES_CSP CSP other services
This TSF handles other services as generation of data validity evidences
(FDP_DAU.2[Att], FDP_DAU.2[Sig]), exchanges of cryptographic keys
(FPT_TDC.1[CK], FPT_TCT.1[CK], FPT_TIT.1[CK], FPT_ISA.1[CK],
FPT_ESA.1[CK]), exchanges of certificates (FPT_TDC.1[Cert]), FPT_
TIT.1[Cert], FPT_ISA.1[Cert]) and exchanges of user data (FDP_
ETC.1[CSP], FDP_ETC.2[CSP], FDP_ITC.2[UD]).
SF.SELF-
PROTECTION_CSP
CSP specific self-protections
This TSF extends the scope of self-protections features provided by the
JavaCard platform to the CSP component needs (FPT_FLS.1[CSP],
FRU_FLT.2[CSP]).
Table 102. Security Functionality for CSP
8.3 Protection against Interference and Logical Tampering
The protection of JCOP6.2 against Interference and Logical Tampering is implemented in
software within the TOE and supported by the hardware of the micro controller.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 115 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
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 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.
JCOP6.2 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. JCOP6.2 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
JCOP6.2 prevents bypassing security related actions by several software counter
measures. Different mechanisms are used depending on the software environment.
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:
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 116 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
• Java Applets are separated from each other as defined in the Java Card specifications
[26], [27] and [28]. 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 [33]. The secure
channel allows access to Applications only if the secret keys are known. Further
protection implemented in JCOP6.2 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.
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.
9 Bibliography
9 . 1 Evaluation documents
[1] Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and general model, Version 3.1, Revision 5, CCMB-2017-04-001, April
2017.
[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security
functional components, Version 3.1, Revision 5, CCMB-2017-04-002, April 2017.
[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security
assurance components, Version 3.1, Revision 5, CCMB-2017-04-003, April 2017.
[4] Common Methodology for Information Technology Security Evaluation, Evaluation
methodology, Version 3.1, Revision 5, CCMB-2017-04-004, April 2017.
[5] Security IC Platform Protection Profile with Augmentation Packages, Registered
and Certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under
the reference BSI-CC-PP-0084-2014, Version 1.0, 13 January 2014.
[6] Published by Oracle. Java card protection profile - open configuration, version 3.1
(April 2020), published by oracle, inc. (BSI-CC-PP-0099-v2-2020)
[7] Published by Oracle. Java card protection profile - open configuration, version 3.0.5
(dec 2017), published by oracle, inc. (BSI-CC-PP-0099-2017)
[8] GSMA SGP.25 Embedded UICC for Consumer Devices, GSMA Association, 05
June 2018 (BSI-CC-PP-0100-2018).
[9] BSI. Common Criteria Protection Profile Cryptographic Service Provider, 19
February 2019 (BSI-CC-PP-0104).
[10] Joint Interpretation Library. Joint Interpretation Library, Security requirements for
post-delivery code loading, Draft Version 1.0, February 2016.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 117 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
9 . 2 Developer documents
[11] NXP JCOP 6.2 R1.01.1, User Guidance Manual, Rev. 1.7, 2022-09-30.
[12] NXP JCOP 6.2 R1.01.1, AMD I SEMS Application User Manual Addendum, Rev.
1.0, 2021-06-16.
[13] NXP. JCOP 6.2 R1.01.1, eUICC Profile Package Interpreter Guide, Rev. 1.1,
2021-07-30.
[14] NXP. JCOP 6.2 R1 eUICC Profile Package Interpreter Guide, Rev. 1.2, 2022-02-03.
[15] NXP. JCOP 6.2 R1.01.1, CSP User Manual Addendum, Rev. 1.0, 2021-06-16.
[16] NXP JCOP 6.2 R1.02.1, User Guidance Manual, Rev. 1.2, 2022-09-30.
[17] NXP JCOP 6.2 R1.02.1, AMD I SEMS Application User Manual Addendum, Rev.
1.1, 2022-03-03.
[18] NXP. JCOP 6.2 R1.02.1, CSP User Manual Addendum, Rev. 1.1, 2022-03-03.
[19] NXP JCOP 6.2 R2.01.1, User Guidance Manual, Rev. 1.2, 2022-09-30.
[20] NXP JCOP 6.2 R2.01.1, AMD I SEMS Application User Manual Addendum, Rev.
1.0, 2022-08-05.
[21] NXP. JCOP 6.2 R2.01.1, CSP User Manual Addendum, Rev. 1.0, 2022-08-05.
[22] NXP. SN220 Series - Secure Element with Crypto Library, Security Target, NXP
Semiconductors, Revision 1.5, 29 Sep 2022.
9 . 3 Standards
[23] Published by Oracle. Java Card 3 Platform, Application Programming Interface,
Classic Edition, Version 3.0 up to 3.0.5.
[24] Published by Oracle. Java Card 3 Platform, Virtual Machine Specification, Classic
Edition, Version 3.0 up to 3.0.5.
[25] Published by Oracle. Java Card 3 Platform, Runtime Environment Specification,
Classic Edition, Version 3.0 up to 3.0.5.
[26] Published by Oracle. Java CardPlatform, versions 3.0 up to 3.1, Application
Programming Interface, Classic Edition, Version 3.1, Feb 2021.
[27] Published by Oracle. Java CardPlatform, versions 3.0 up to 3.1, Virtual Machine
Specification, Classic Edition, Version 3.1, Feb 2021.
[28] Published by Oracle. Java CardPlatform, versions 3.0 up to 3.1, Runtime
Environment Specification, Classic Edition, Version 3.1, Feb 2021.
[29] GlobalPlatform. GlobalPlatform Card Specification 2.3.1, GPC_SPE_034,
GlobalPlatform Inc., Mar 2018.
[30] GlobalPlatform. Confidential Card Content Management, GlobalPlatform Card
Specification v2.2 - Amendment A v1.0.1, January 2011.
[31] GlobalPlatform. Confidential Card Content Management - Amendment A v1.1, Nov
2015.
[32] GlobalPlatform. Remote Application Management over HTTP - Amendment B
v1.1.3, May 2015.
[33] GlobalPlatform. Contactless Services, GlobalPlatform Card Specification v 2.2 -
Amendment C v1.0.1, February 2012.
[34] GlobalPlatform. Contactless Services - Amendment C v1.1, April 2013.
[35] GlobalPlatform. GlobalPlatform Card Technology Secure Channel Protocol ’03’ -
Amendment D v1.1, January 2011.
[36] GlobalPlatform. Security Upgrade for Card Content Management - Amendment E
v1.1, November 2016.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 118 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
[37] GlobalPlatform. GlobalPlatform Card Secure Channel Protocol ’11’ - Amendment F
Version 1.1, September 2017.
[38] GlobalPlatform. GlobalPlatform Technology Executable Load File Upgrade - Version
1.1, March 2018.
[39] GlobalPlatform. GlobalPlatform Technology Secure Element Management Service -
Version 1.0, March.
[40] GlobalPlatform. GlobalPlatform common Implementation Configuration - Version
2.0, December 2015.
[41] GSMA. SGP.22 Remote SIM Provisioning (RSP) Technical Specification, version
2.2.1, GSMA Association, December 2018.
[42] GSMA. SGP.22 Remote SIM Provisioning (RSP) Technical Specification, version
2.2.2, GSMA Association, June 2020.
[43] GSMA. SGP.02 Remote Provisioning Architecture for Embedded UICC Technical
Specification, version 3.2; 27 June 2017.
[44] GlobalPlatform. GlobalPlatform UICC Configuration v1.0.1, January 2011.
[45] GlobalPlatform. GlobalPlatform UICC Configuration - Contactless Extension Version
1.0, February 2012.
[46] BSI. CSP-API Definition, 5 November 2018.
[47] ETSI. ETSI TS 102 622 v12.1.0 Smart Cards; UICC - Contactless Front-end (CLF)
Interface; Host Controller Interface (HCI), 10 2014.
[48] Bundesamt für Sicherheit in der Informationstechnik, Technische Richtlinie -
Kryptographische Verfahren: Empfehlungen und Schlüssellängen, 09. Januar 2013,
BSI-TR02102.
[49] Bundesamt fuer Sicherheit in der Informationstechnik. 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.
[50] FIPS PUB 197: Advanced Encryption Standard (AES), Federal Information
Processing Standards Publication 197, US Department of Commerce/National
Institute of Standards and Technology, 26 November 2001.
[51] FIPS PUB 180-4: Secure Hash Standard (SHS) Publication 180-4, US Department
of Commerce/National Institute of Standards and Technology, August 2015.
[52] FIPS PUB 186-4: Digital Signature Standard (DSS), US Department of Commerce/
National Institute of Standards and Technology, 2013.
[53] FIPS PUB 202-2015: SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions, Federal Information Processing Standards Publication, August
2015.
[54] NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods
and Techniques, National Institute of Standards and Technology, December 2001.
[55] NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication, Morris Dworkin, National Institute of Standards and
Technology, May 2005.
[56] NIST SP 800-38C: Recommendation for Block Cipher Modes of Operation: the
CCM Mode for Authentication and Confidentiality, National Institute of Standards
and Technology, May 2005.
[57] National Institute of Standards and USA Technology. NIST Special Publication
800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter
Mode (GCM) and GMAC, November 2007.
[58] RFC 2104: HMAC: Keyed-Hashing for Message Authentication, Request For
Comments, February 1997
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 119 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
[59] Trusted Platform Module Library, Part 1: Architecture, Family “2.0”, Level 00,
Revision 01.38, September 2016.
[60] ECDAAFIDO Alliance, Alliance Proposed Standard FIDO ECDAA Algorithm,
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-ecdaa-algorithm-v1.2-
ps-20170411.html, April 2017.
[61] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 120 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
10 Legal information
10.1 Definitions
Draft — A draft status on a document indicates that the content is still
under internal review and subject to formal approval, which may result
in modifications or additions. NXP Semiconductors does not give any
representations or warranties as to the accuracy or completeness of
information included in a draft version of a document and shall have no
liability for the consequences of use of such information.
10.2 Disclaimers
Limited warranty and liability — Information in this document is believed
to be accurate and reliable. However, NXP Semiconductors does not give
any representations or warranties, expressed or implied, as to the accuracy
or completeness of such information and shall have no liability for the
consequences of use of such information. NXP Semiconductors takes no
responsibility for the content in this document if provided by an information
source outside of NXP Semiconductors.
In no event shall NXP Semiconductors be liable for any indirect, incidental,
punitive, special or consequential damages (including - without limitation -
lost profits, lost savings, business interruption, costs related to the removal
or replacement of any products or rework charges) whether or not such
damages are based on tort (including negligence), warranty, breach of
contract or any other legal theory.
Notwithstanding any damages that customer might incur for any reason
whatsoever, NXP Semiconductors’ aggregate and cumulative liability
towards customer for the products described herein shall be limited in
accordance with the Terms and conditions of commercial sale of NXP
Semiconductors.
Right to make changes — NXP Semiconductors reserves the right to
make changes to information published in this document, including without
limitation specifications and product descriptions, at any time and without
notice. This document supersedes and replaces all information supplied prior
to the publication hereof.
Suitability for use — NXP Semiconductors products are not designed,
authorized or warranted to be suitable for use in life support, life-critical or
safety-critical systems or equipment, nor in applications where failure or
malfunction of an NXP Semiconductors product can reasonably be expected
to result in personal injury, death or severe property or environmental
damage. NXP Semiconductors and its suppliers accept no liability for
inclusion and/or use of NXP Semiconductors products in such equipment or
applications and therefore such inclusion and/or use is at the customer’s own
risk.
Applications — Applications that are described herein for any of these
products are for illustrative purposes only. NXP Semiconductors makes no
representation or warranty that such applications will be suitable for the
specified use without further testing or modification.
Customers are responsible for the design and operation of their
applications and products using NXP Semiconductors products, and NXP
Semiconductors accepts no liability for any assistance with applications or
customer product design. It is customer’s sole responsibility to determine
whether the NXP Semiconductors product is suitable and fit for the
customer’s applications and products planned, as well as for the planned
application and use of customer’s third party customer(s). Customers should
provide appropriate design and operating safeguards to minimize the risks
associated with their applications and products.
NXP Semiconductors does not accept any liability related to any default,
damage, costs or problem which is based on any weakness or default
in the customer’s applications or products, or the application or use by
customer’s third party customer(s). Customer is responsible for doing all
necessary testing for the customer’s applications and products using NXP
Semiconductors products in order to avoid a default of the applications
and the products or of the application or use by customer’s third party
customer(s). NXP does not accept any liability in this respect.
Limiting values — Stress above one or more limiting values (as defined in
the Absolute Maximum Ratings System of IEC 60134) will cause permanent
damage to the device. Limiting values are stress ratings only and (proper)
operation of the device at these or any other conditions above those
given in the Recommended operating conditions section (if present) or the
Characteristics sections of this document is not warranted. Constant or
repeated exposure to limiting values will permanently and irreversibly affect
the quality and reliability of the device.
Terms and conditions of commercial sale — NXP Semiconductors
products are sold subject to the general terms and conditions of commercial
sale, as published at http://www.nxp.com/profile/terms, unless otherwise
agreed in a valid written individual agreement. In case an individual
agreement is concluded only the terms and conditions of the respective
agreement shall apply. NXP Semiconductors hereby expressly objects to
applying the customer’s general terms and conditions with regard to the
purchase of NXP Semiconductors products by customer.
No offer to sell or license — Nothing in this document may be interpreted
or construed as an offer to sell products that is open for acceptance or
the grant, conveyance or implication of any license under any copyrights,
patents or other industrial or intellectual property rights.
Export control — This document as well as the item(s) described herein
may be subject to export control regulations. Export might require a prior
authorization from competent authorities.
Suitability for use in non-automotive qualified products — Unless
this data sheet expressly states that this specific NXP Semiconductors
product is automotive qualified, the product is not suitable for automotive
use. It is neither qualified nor tested in accordance with automotive testing
or application requirements. NXP Semiconductors accepts no liability for
inclusion and/or use of non-automotive qualified products in automotive
equipment or applications.
In the event that customer uses the product for design-in and use in
automotive applications to automotive specifications and standards,
customer (a) shall use the product without NXP Semiconductors’ warranty
of the product for such automotive applications, use and specifications, and
(b) whenever customer uses the product for automotive applications beyond
NXP Semiconductors’ specifications such use shall be solely at customer’s
own risk, and (c) customer fully indemnifies NXP Semiconductors for any
liability, damages or failed product claims resulting from customer design and
use of the product for automotive applications beyond NXP Semiconductors’
standard warranty and NXP Semiconductors’ product specifications.
Translations — A non-English (translated) version of a document, including
the legal information in that document, is for reference only. The English
version shall prevail in case of any discrepancy between the translated and
English versions.
Security — Customer understands that all NXP products may be subject to
unidentified vulnerabilities or may support established security standards or
specifications with known limitations. Customer is responsible for the design
and operation of its applications and products throughout their lifecycles
to reduce the effect of these vulnerabilities on customer’s applications
and products. Customer’s responsibility also extends to other open and/or
proprietary technologies supported by NXP products for use in customer’s
applications. NXP accepts no liability for any vulnerability. Customer should
regularly check security updates from NXP and follow up appropriately.
Customer shall select products with security features that best meet rules,
regulations, and standards of the intended application and make the
ultimate design decisions regarding its products and is solely responsible
for compliance with all legal, regulatory, and security related requirements
concerning its products, regardless of any information or support that may be
provided by NXP.
NXP has a Product Security Incident Response Team (PSIRT) (reachable
at PSIRT@nxp.com) that manages the investigation, reporting, and solution
release to security vulnerabilities of NXP products.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 121 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
10.3 Trademarks
Notice: All referenced brands, product names, service names, and
trademarks are the property of their respective owners.
NXP — wordmark and logo are trademarks of NXP B.V.
DESFire — is a trademark of NXP B.V.
MIFARE — is a trademark of NXP B.V.
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 122 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Tables
Tab. 1. ST Reference and TOE Reference ................... 3
Tab. 2. SN220 configurations ........................................5
Tab. 3. Product configurations .......................................5
Tab. 4. JCOP RSP Version Compliance ..................... 10
Tab. 5. Java Card External APIs .................................11
Tab. 6. Java Package Versions ...................................11
Tab. 7. Optional Augmentation Java Packages for
R2 ....................................................................13
Tab. 8. Reference to Certified Micro Controller for
R1.x products ..................................................15
Tab. 9. Reference to Certified Micro Controller for
R2.x products ..................................................15
Tab. 10. Java Card v3.05 Specifications .......................15
Tab. 11. Java Card v3.1 Specifications .........................16
Tab. 12. Global Platform Specifications and
Amendments ................................................... 16
Tab. 13. CSP Application Identification ......................... 17
Tab. 14. Life-cycle ......................................................... 19
Tab. 15. eUICC lifecycle stages and Delivery
Options ............................................................ 20
Tab. 16. JCOP6.2 R1.01.1 Delivery Items .................... 21
Tab. 17. JCOP6.2 R1.02.1 Delivery Items .................... 22
Tab. 18. JCOP6.2 R2.01.1 Delivery Items .................... 22
Tab. 19. Product Identification .......................................23
Tab. 20. Platform ID Format (example R2.01.1) ............23
Tab. 21. Java Card API Version Compliance ................ 24
Tab. 22. Optional Augmentation Packages ................... 24
Tab. 23. Java Card Additional Threats ..........................25
Tab. 24. CarG SFRs refinements ..................................31
Tab. 25. Optional Augmentation Packages ................... 32
Tab. 26. ..........................................................................33
Tab. 27. ..........................................................................33
Tab. 28. ..........................................................................33
Tab. 29. ..........................................................................33
Tab. 30. ..........................................................................34
Tab. 31. Threats defined in Java Card PP .................... 36
Tab. 32. ..........................................................................37
Tab. 33. ..........................................................................37
Tab. 34. ..........................................................................37
Tab. 35. ..........................................................................38
Tab. 36. ..........................................................................38
Tab. 37. ..........................................................................38
Tab. 38. Security Objectives for the TOE shared by
all configurations ............................................. 40
Tab. 39. Additional Security Objectives for Java
Card v3.1 .........................................................41
Tab. 40. ..........................................................................41
Tab. 41. ..........................................................................42
Tab. 42. ..........................................................................42
Tab. 43. ..........................................................................43
Tab. 44. ..........................................................................43
Tab. 45. ..........................................................................43
Tab. 46. ..........................................................................44
Tab. 47. Security Objectives for the Environment of
the Java Card PP ........................................... 44
Tab. 48. Additional Security Objectives for the
Environment .................................................... 45
Tab. 49. ..........................................................................46
Tab. 50. ..........................................................................46
Tab. 51. ..........................................................................46
Tab. 52. ..........................................................................47
Tab. 53. ..........................................................................48
Tab. 54. ..........................................................................48
Tab. 55. ..........................................................................48
Tab. 56. ..........................................................................49
Tab. 57. ..........................................................................49
Tab. 58. ..........................................................................49
Tab. 59. ..........................................................................49
Tab. 60. ..........................................................................50
Tab. 61. ..........................................................................50
Tab. 62. ..........................................................................50
Tab. 63. ..........................................................................50
Tab. 64. ..........................................................................50
Tab. 65. ..........................................................................50
Tab. 66. ..........................................................................50
Tab. 67. ..........................................................................51
Tab. 68. ..........................................................................51
Tab. 69. Requirement Groups .......................................52
Tab. 70. Java Card Subject Descriptions ...................... 52
Tab. 71. Security attribute description ...........................52
Tab. 72. Operation Description ......................................54
Tab. 73. ..........................................................................54
Tab. 74. API SFRs ........................................................ 54
Tab. 75. SFRs applicable from JCOP 6.2 R2 ................58
Tab. 76. Augmentation Package SFRs ......................... 59
Tab. 77. ..........................................................................60
Tab. 78. ..........................................................................60
Tab. 79. ..........................................................................61
Tab. 80. ..........................................................................86
Tab. 81. ..........................................................................88
Tab. 82. ..........................................................................97
Tab. 83. ........................................................................100
Tab. 84. ........................................................................101
Tab. 85. ........................................................................101
Tab. 86. ........................................................................102
Tab. 87. ........................................................................103
Tab. 88. ........................................................................103
Tab. 89. ........................................................................104
Tab. 90. ........................................................................106
Tab. 91. ........................................................................107
Tab. 92. ........................................................................107
Tab. 93. ........................................................................107
Tab. 94. ........................................................................108
Tab. 95. ........................................................................108
Tab. 96. ........................................................................108
Tab. 97. ........................................................................109
Tab. 98. ........................................................................109
Tab. 99. Security Functionality for JCOP .................... 110
Tab. 100. Security Functionality for R2.x
Augmentation Packages ............................... 113
Tab. 101. Security Functionality for eUICC ................... 114
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 123 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Tab. 102. Security Functionality for CSP .......................115
Figures
Fig. 1. JCOP 6.2 Domains and Communication
Interfaces ...........................................................4
Fig. 2. JCOP 6.2 R1.x Domains and Internal
Interfaces ...........................................................8
Fig. 3. JCOP 6.2 R2.x Domains and Internal
Interfaces ...........................................................9
Fig. 4. TOE Life Cycle within Product Life Cycle ........ 18
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 124 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
Contents
1 ST Introduction (ASE_INT) .................................3
1.1 ST Reference and TOE Reference ....................3
1.2 TOE Overview ................................................... 3
1.2.1 TOE Type .......................................................... 3
1.2.1.1 TOE Configurations ........................................... 5
1.2.2 TOE usage and major features ......................... 5
1.2.2.1 R1.01.1 Features ...............................................6
1.2.2.2 R1.02.1 .............................................................. 7
1.2.2.3 R1.02.1-1 ........................................................... 7
1.2.2.4 R2 Features .......................................................7
1.2.3 TOE components ...............................................7
1.2.3.1 JCOP 6.2 R1.x Interfaces ..................................8
1.2.3.2 JCOP 6.2 R2.x Interfaces ..................................8
1.2.3.3 JCOP component .............................................. 9
1.2.3.4 eUICC component ........................................... 10
1.2.3.5 CSP component .............................................. 10
1.2.3.6 TOE Java packages ........................................ 10
1.2.4 Non-TOE Hardware/Software/Firmware .......... 13
1.3 TOE Description .............................................. 14
1.3.1 TOE scope .......................................................14
1.3.2 TOE Composition ............................................ 14
1.3.2.1 Micro-Controller component details ................. 14
1.3.2.2 JCOP component details .................................15
1.3.2.3 eUICC component details ................................17
1.3.2.4 CSP component details ...................................17
1.3.3 TOE Life Cycle ................................................ 17
1.3.3.1 TOE Life Cycle ................................................ 17
1.3.3.2 eUICC specific life-cycle ..................................20
1.3.3.3 CSP specific life-cycle ..................................... 21
1.3.4 TOE delivery information ................................. 21
1.3.4.1 Delivery method ...............................................21
1.3.4.2 Delivery form factor ......................................... 21
1.3.4.3 Delivery content ...............................................21
1.4 TOE Identification ............................................ 22
2 Conformance Claims ........................................ 23
2.1 CC Conformance Claim ...................................23
2.2 CC Package Claim .......................................... 24
2.3 PP Claim ..........................................................24
2.3.1 Note on New Features .................................... 24
2.4 Conformance Claim Rationale .........................25
2.4.1 TOE Type ........................................................ 25
2.4.2 SPD Statement ................................................25
2.4.2.1 JCOP ............................................................... 25
2.4.2.2 eUICC .............................................................. 27
2.4.2.3 CSP ..................................................................27
2.4.3 Security Objectives Statement .........................27
2.4.3.1 JCOP ............................................................... 27
2.4.3.2 eUICC .............................................................. 29
2.4.3.3 CSP ..................................................................30
2.4.4 Security Functional Requirements
Statement .........................................................30
2.4.4.1 JCOP ............................................................... 30
2.4.4.2 eUICC .............................................................. 32
2.4.4.3 CSP ..................................................................32
3 Security Aspects ...............................................33
3.1 Confidentiality .................................................. 33
3.2 Integrity ............................................................ 33
3.3 Config Applet ...................................................33
3.4 OS Update .......................................................33
3.5 Restricted Mode .............................................. 34
4 Security Problem Definition (ASE_SPD) ......... 34
4.1 JCOP ............................................................... 34
4.1.1 Assets .............................................................. 34
4.1.1.1 User Data ........................................................ 34
4.1.1.2 TSF Data ......................................................... 35
4.1.2 JCOP Threats ..................................................36
4.1.2.1 Integrity ............................................................ 37
4.1.2.2 Card Management ...........................................37
4.1.2.3 Random Numbers ............................................37
4.1.2.4 Config Applet ...................................................38
4.1.2.5 OS Update .......................................................38
4.1.2.6 Restricted Mode .............................................. 38
4.1.3 JCOP related Organisational Security
Policies .............................................................38
4.1.4 JCOP related Assumptions ..............................39
4.2 eUICC .............................................................. 39
4.3 CSP ..................................................................40
5 Security objectives ........................................... 40
5.1 Security Objectives for the TOE ...................... 40
5.1.1 JCOP ............................................................... 40
5.1.1.1 Package Sensitive ........................................... 41
5.1.1.2 Package Monotonic Counter ........................... 41
5.1.1.3 Cryptographic Certificate Management ........... 41
5.1.1.4 Package Key Derivation Functions (KDF) ........41
5.1.1.5 Package System Time .....................................41
5.1.1.6 Smart Card Platform ........................................41
5.1.1.7 Random Numbers ............................................42
5.1.1.8 OS Update Mechanism ................................... 42
5.1.1.9 Config Applet ...................................................43
5.1.1.10 Restricted Mode .............................................. 43
5.1.1.11 Applet Management .........................................44
5.1.2 eUICC .............................................................. 44
5.1.3 CSP ..................................................................44
5.2 Security Objectives for the Environment ..........44
5.2.1 JCOP ............................................................... 44
5.2.2 eUICC .............................................................. 46
5.2.3 CSP ..................................................................46
5.3 Security Objectives Rationales ........................46
5.3.1 JCOP ............................................................... 46
5.3.1.1 Threats .............................................................46
5.3.1.2 Assumptions .................................................... 50
5.3.1.3 Organizational Security Policies ...................... 50
5.3.2 eUICC .............................................................. 51
5.3.3 CSP ..................................................................51
6 Extended Components Definition ....................51
6.1 JCOP ............................................................... 51
6.2 eUICC .............................................................. 51
6.3 CSP ..................................................................51
7 Security Requirements (ASE_REQ) .................52
7.1 Security Functional Requirements ...................52
7.1.1 JCOP ............................................................... 52
7.1.1.1 SFRs content items definitions ........................ 52
ST-JCOP62-01 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2022. All rights reserved.
Product evaluation document Rev. 1.8 — 24 November 2022
PUBLIC 125 / 126
NXP Semiconductors NXP JCOP 6.2 on SN220 Secure Element
Security Target Lite
7.1.1.2 COREG_LC Security Functional
Requirements ...................................................54
7.1.1.3 INSTG Security Functional Requirements ....... 61
7.1.1.4 ADELG Security Functional Requirements ......61
7.1.1.5 RMIG Security Functional Requirements .........61
7.1.1.6 ODELG Security Functional Requirements ......61
7.1.1.7 CarG Security Functional Requirements ......... 61
7.1.1.8 EMG Security Functional Requirements ..........72
7.1.1.9 Proprietary Security Functional
Requirements ...................................................72
7.1.1.10 Configuration Security Functional
Requirements ...................................................75
7.1.1.11 OS update Security Functional
Requirements ...................................................78
7.1.1.12 Restricted Mode Security Functional
Requirements ...................................................82
7.1.2 eUICC .............................................................. 85
7.1.3 CSP ..................................................................88
7.2 Security Assurance Requirements ...................97
7.3 Security Functional Requirements
Dependencies ..................................................97
7.3.1 JCOP ............................................................... 97
7.3.1.1 JCOP Rationale for Exclusion of
Dependencies ..................................................99
7.3.2 eUICC ............................................................ 100
7.3.3 CSP ................................................................100
7.4 Security Requirements Rationales .................100
7.4.1 Security Assurance Requirements
Rationale ........................................................100
7.4.2 Security Functional Requirements
Rationales ......................................................100
7.4.2.1 JCOP ............................................................. 100
7.4.2.2 eUICC ............................................................ 109
7.4.2.3 CSP ................................................................109
8 TOE summary specification (ASE_TSS) ....... 109
8.1 Introduction .................................................... 109
8.2 Security Functionality .....................................110
8.2.1 JCOP ............................................................. 110
8.2.2 eUICC ............................................................ 114
8.2.3 CSP ................................................................115
8.3 Protection against Interference and Logical
Tampering ...................................................... 115
8.4 Protection against Bypass of Security
Related Actions ............................................. 116
9 Bibliography .................................................... 117
9.1 Evaluation documents ................................... 117
9.2 Developer documents ....................................118
9.3 Standards .......................................................118
10 Legal information ............................................121
Please be aware that important notices concerning this document and the product(s)
described herein, have been included in section 'Legal information'.
© NXP B.V. 2022. All rights reserved.
For more information, please visit: http://www.nxp.com
For sales office addresses, please send an email to: salesaddresses@nxp.com
Date of release: 24 November 2022
Document identifier: ST-JCOP62-01