NXP JCOP 4 Security Target Lite v3.4 12
8 TOE summary specification (ASE_TSS)
8.1 Introduction
The Security Functions (SF) introduced in this section realize the SFRs of the TOE. See Table 8.1 for list of all Security Functions. Each SF consists of components spread over several TOE components to provide a security functionality and fulfill SFRs.
8.2 Security Functionality
Name | Title | ||
SF.JCVM | Java Card Virtual Machine | ||
SF.CONFIG | Configuration Management | ||
SF.OPEN | Card Content Management | ||
SF.CRYPTO | Cryptographic Functionality | ||
SF.RNG | Random Number Generator | ||
Secure Data Storage | |||
SF.PUF | User Data Protection using PUF | ||
External Memory | |||
SF.OM | Java Object Management | ||
SF.MM | Memory Management | ||
SF.PIN | PIN Management | ||
Persistent Memory Management | |||
SF.EDC | Error Detection Code API | ||
Hardware Exception Handling | |||
SF.RM | Restricted Mode | ||
SF.PID | Platform Identification | ||
No Side-Channel | |||
Secure Box | |||
Module Invocation | |||
Sensitive Result | |||
Tab. 8.1: Overview of Security Functionality | |||
SF.JCVM | Java Card Virtual Machine | ||
SF.JCVMprovides the Java Card Virtual Machine including byte code interpretation and the Java Card Firewall according to the specifications [39,40]. 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.1and 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 ini-tialized and assigned by the system itself which fulfills FMT_MSA.2[FIREWALL-JCVM], FMT_ MSA.3[FIREWALL], and FMT_MSA.3[JCVM]. n SF.JCVMensures together with SF.PERS_MEMthat the system is halted in case non existing nJava 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.CONFIGsupports FCS_COP.1 by configuring the behavior of cryptographic op-erations.
SF.OPEN Card Content Management
SF.OPEN provides the card content management functionality according the GlobalPlatform Specification [37]. This supports FCO_NRO.2[SC], FDP_ACC.1[SD], FDP_ACF.1[SD], FDP_ UIT.1[CCM], FDP_IFC.2[SC], 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], and FTP_ITC.1[SC]. In addition to the GP specification, the Java Card Runtime Environment specification [39] 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]nfor application loading, installation, and deletion.
AID management is provided by SF.OPEN according to the GlobalPlatform Specification [37], the Java Card Runtime Environment Specification [39], and the Java Card API Specification [38] 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.1by responding with error mes-sages according to the GlobalPlatform mapping guidelines [33] 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 function-ality. It provides the API in accordance to the Java Card API Specification [38] to fulfill FCS_ CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, and FCS_COP.1. Proprietary solutions (e.g.,key lengths not supported by the Java Card API) are supported following the Java Card API.
SF.CRYPTO uses SF.DATA_STORAGE to support FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FDP_RIP.1[KEYS], and FDP_SDI.2[DATA]. The Crypto Lib certified with the TOE hardware supports FCS_COP.1 and FPR_UNO.1.
SF.RNG Random Number Generator
SF.RNG provides secure random number generation to fulfill FCS_CKM.1 and FCS_RNG.1. Random numbers are generated by the Crypto Lib certified with the TOE hardware. SF.RNG provides an API according to the Java Card API Specification [38] to generate random numbers according to FCS_RNG.1.
SF.DATA_STORAGE Secure Data Storage
SF.DATA_STORAGE provides a secure data storage for confidential data. It is used to store cryptographic keys (supports FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, and FCS_CKM.4) and to store PINs (supports FIA_AFL.1[PIN]). All data stored by SF.DATA_STORAGE is CRC32 integrity protected to fulfill FDP_SDI.2[DATA], FAU_ARP.1, and FPT_FLS.1. The stored data is AES encrypted to fulfill FPR_UNO.1.
SF.PUF User Data Protection using PUF
SF.PUF implements a mechanism to seal/unseal the user data stored in shared memory against unintended disclosure. SF.PUF encrypts/decrypts the user data with a cryptographic key which is derived from the PUF data and stored directly in the hardware. SF.PUF calculates a MAC as a PUF authentication value. SF.PUF serves to seal/unseal the user data stored in the memory. The user data stored in the memory can be encrypted/decrypted using the PUF block. A MAC (message authentication code) can be calculated as a PUF authentication value. Hence, the user data can be sealed within the TOE and can be solely unsealed by the TOE. The crypto-graphic key for sealing/unsealing of the user data is generated with the help of a key derivation function based on the PUF block and the Random Number Generator (RNG). The PUF block provides the PUF data to the key derivation function and thereby the cryptographic key is derived. If the TOE is powered off, the PUF data is not available from the PUF block. Therefore SF.PUF is suitable to meet FCS_CKM.1.1[PUF] and FCS_CKM.4.1[PUF]. The encryption/decryption of user data and the calculation of a MAC as a PUF authentication value are performed within the AES coprocessor. Therefore SF.PUF is suitable to meet FCS_COP.1.1[PUF_AES] and FCS_ COP.1.1[PUF_MAC]. Note that the RNG is used only once after the TOE is powered up.
SF.EXT_MEM External Memory
SF.EXT_MEM provides mechanisms to access memory subsystems which are not directly ad-dressable by the Java Card runtime environment (Java Card RE) on the Java Card platform. The API is according to the Java Card API Specification [38] and implements the rules given in the EXTERNAL MEMORY access control SFP and thus fulfills FDP_ACC.1[EXT-MEM], FDP_ ACF.1[EXT-MEM], FMT_MSA.1[EXT-MEM], FMT_MSA.3[EXT-MEM], and FMT_SMF.1[EXT-MEM].
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 [39] 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 [39]. 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], FDP_RIP.1[bArray] and FDP_RIP.1[GlobalArray_Refined]by clear-ing the APDU buffers for new incoming data, by clearing the bArray during application installation and preventing applications to keep a pointer to global arrays.
SF.PIN PIN Management
SF.PIN provides secure PIN management by using SF.DATA_STORAGE for PIN objects speci-fied in the Java Card API Specification [38] and the GlobalPlatform Specification [35]. Thus, it fulfills FDP_SDI.2[DATA], FIA_AFL.1[PIN], and FPR_UNO.1.
SF.PERS_MEM Persistent Memory Management
SF.PERS_MEM provides atomic write operations and transaction management according to theJava Card Runtime Environment Specification [39]. 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_MEMperform checks for defect mem-ory cells to fulfill FAU_ARP.1 and FPT_FLS.1.
SF.EDC Error Detection Code API
SF.EDC provides an Java API for user applications to perform high performing integrity checks based on a checksum on Java arrays [14], [15]. The API throws a Java Exception in case the checksum in invalid. This supports FAU_ARP.1and 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.1and 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.RMonly allows a limited set of opera-tions to not identified and not authenticated users when in restricted mode. All other operations require identification and authentication (FIA_UID.1[RM], FIA_UAU.1[RM]).
SF.PID Platform Identification
SF.PID provides a platform identifier. This platform identifier is generated during the card image generation. The platform identifier contains IDs for:
• NVM content (stored during romizing)
• Patch Level (stored during romizing, can be changed during personalization if patch is loaded)
• ROM code (stored during romizing)
• ROM code checksum (stored during romizing or during first TOE boot).
It identifies unambiguously the NVM and ROM part of the TOE. 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 con-sumption (measurable at e.g. electrical contacts) or timing (measurable at e.g. electrical con-tacts) 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.1and FPT_EMSEC.1).
SF.ACC_SBX Secure Box
SF.ACC_SBXprovides an environment to securely execute non-certified native code from third parties. SF.ACC_SBXensures that only program code and data contained in the secure box can be accessed from within this secure box and therefore cannot harm, manipulate, or influence other parts of the TOE. This fulfills the SFRs FDP_ACC.2[SecureBox], FDP_ACF.1[SecureBox] and FMT_MSA.1[SecureBox].
Native code executed in the Secure Box is executed in User Mode. Access to the CPU mode, memory outside the Secure Box, the MMU segment table, and Special Function Registers which allow configuration of the MMU and allow System Management is prohibited for code executed in the Secure Box to fulfill FDP_ACF.1[SecureBox].
The MMU segment table to configure the MMU is part of the Secure Box which fulfils FMT_ MSA.3[SecureBox]. This MMU segment table can be modified during the prepersonalization in accordance with FMT_MSA.3[SecureBox]to specify alternative settings for initially restrictive values for the MMU segment table. This supports FMT_SMF.1[SecureBox].
SF.MOD_INVOC Module Invocation
SF.MOD_INVOClimits the invocation of code inside a Module to such Modules whose secu-rity attribute Module Presence has the restrictive default value ”present”. This fulfils the FMT_ SMF.1[MODULAR-DESIGN], FMT_SMR.1[MODULAR-DESIGN], FMT_MSA.3[MODULAR-DESIGN] and FIA_UID.1[MODULAR-DESIGN]. Limiting the invocation to defined subjects S.APPLET, S.SD and S.JCRE fulfils the FDP_IFC.1[MODULAR-DESIGN] and FDP_IFF.1[MODULAR-DESIGN]. Throwing an exception in cases where the security attribute Module Presence has the value ”not present” fulfils FPT_FLS.1[MODULAR-DESIGN]. Deletion of a module may only be performed by S.ADEL which fulfils FMT_MSA.1[MODULAR-DESIGN]. The Modules are identified by their associated unique AIDs, which fulfils FIA_ATD.1[MODULAR-DESIGN] and FIA_ USB.1[MODULAR-DESIGN].
SF.SENS_RES Sensitive Result
SF.SENS_RESensures that sensitive methods of the Java Card API store their results so that
callers of these methods can assert their return values. If such a method returns abnormally
with an exception then the stored result is tagged as Unassigned and any subsequent assertion
of the result will fail. This fulfills FDP_SDI.2[SENSITIVE_RESULT].
8.3 Protection against Interference and Logical Tampering
The protection of JCOP 4 P71 against Interference and Logical Tampering is implemented in software within the TOE and supported by the hardware of the micro controller.
The software protection of the TOE makes use of software security services which allow to detect and react on manipulation of the TOE. Two types of reactions are used: If invalid data from outside the TOE is detected then it 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 terminate itself.
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 Crypto Lib for DES, AES, RSA, ECC and random number generation.
•Critical values (like PINs) are compared timing-invariant. This prevents from side channel attacks.
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 and the special functions registers depending on the current operation.
JCOP 4 P71 defines several MMU contexts which restrict access to card internal resources. The standard context used for normal operation has no access to the cryptographic coprocessor. The context for cryptographic opera-tion has no access to the communication interfaces. One special context has write access to the Master Key in the TOE. Afterwards the Master Keys can only be read, but only from a dedicated context which is used to decrypt keys stored in the secure data store. In all other contexts the Master Key is not accessible.
Additionally Interference and Logical Tampering is prevented by hardware security services. JCOP 4 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 Dif-ferential Fault Analysis (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
JCOP 4 P71 prevents bypassing security related actions by several software counter measures. Different mech-anism 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:
•Java Applets are separated from each other as defined in the Java Card specifications [38, 39, 40]. The separation is achieved by implementation of the firewall which prevents Applets to access data belonging to a different Java Card context. Information sharing 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 GlobalPlatform [35]. The secure channel allows access to Applications only if the secret keys are known. Further protection implemented in JCOP 4 P71 prevent brute force attacks on the secret keys of the Secure Channel.
The following mechanisms ensure that it is not possible to access information from the Java Layer without being authorized to do so.
•Status informations like Life Cycle of Applets or the Authentication State of a Secure Channel are stored in complex patterned values which protects them from manipulation.
•Correct order of Java Card Byte Code execution is ensured by the Virtual Machine which detects if Byte Code of a wrong context is executed.
•Correct processing of Byte Codes is ensured by checking at the beginning and end of Byte Code execution that the same Byte Code is executed.
Execution of native code in JCOP 4 P71 is protected by following mechanisms:
•Critical execution paths of the TOE functionality are protected by program flow and call tree protection. This ensures that it is not possible to bypass security relevant checks and verifications.
•Critical conditions are evaluated twice. This ensures that physical attacks on the compared values are detected during security relevant checks and verifications.
•The true case in if-conditions leads to the less critical program flow or to an error case. This prevents attacks on the program flow during security relevant checks and verifications.
•At the exit of critical loops it is checked that the whole loop was processed. This prevents from manipulation of the program flow and jumping out of the loop.
•Critical parameters are checked for consistency. This prevents from attacks with manipulated parameters.
10 Glossary
AID ApplicationIdentifier, an ISO-7816 data format used for unique identification of Java Card applications (andcertain kinds of files in card file systems). The Java Card platform uses the AID data format to identify applets and packages. AIDs are administered by the International Standards Organization (ISO), so they can be used as unique identifiers.
AIDs are also used in the security policies (see ’Context’ below): applets’ AIDs are related to the selection mechanisms, packages’ AIDs are used in the enforcement of the firewall. Note:although they serve different purposes, they share the same name space.
APDU buffer The APDU buffer is the buffer where the messages sent (received) by the card depart from (ar-rive to). The JCRE owns an APDU object (which is a JCRE Entry Point and an instance of the javac-ard.framework.APDU class) that encapsulates APDU messages in an internal byte array, called the APDU buffer. This object is made accessible to the currently selected applet when needed, but any permanent access (out-of selection-scope) is strictly prohibited for security reasons.
applet The name is given to a Java Card technology-based user application. An applet is the basic piece of codethat can be selected for execution from outside the card. Each applet on the card is uniquely identified by its AID.
applet deletion manager The on-card component that embodies the mechanisms necessary to delete an appletor library and its associated data on smart cards using Java Card technology..
context A context is an object-space partition associated to a package. Applets within the same Java technology-based package belong to the same context. The firewall is the boundary between contexts (see "current context").
current context The JCRE keeps track of the current Java Card System context (also called "the active context").When a virtual method is invoked on an object, and a context switch is required and permitted, the current context is changed to correspond to the context of the applet that owns the object. When that method returns, the previous context is restored. Invocations of static methods have no effect on the current context. The current context and sharing status of an object together determine if access to an object is permissible.
currently selected applet The applet has been selected for execution in the current session. The Java Card REkeeps track of the currently selected Java Card applet. Upon receiving a SELECT command from the CAD or PCD with this applet’s AID, the Java Card RE makes this applet the currently selected applet over the I/O interface that received the command. The Java Card RE sends all further APDU commands received over each interface to the currently selected applet on this interface ([39], Glossary).
default applet The applet that is selected after a card reset ([39], §4.1).
installer The installer is the on-card application responsible for the installation of applets on the card. It may per-form (or delegate) mandatory security checks according to the card issuer policy (for bytecode-verification, for instance), loads and link packages (CAP file(s)) on the card to a suitable form for the Java Card VM to execute the code they contain. It is a subsystem of what is usually called “card manager”; as such, it can be seen as the portion of the card manager that belongs to the TOE.
The installer has an AID that uniquely identifies him, and may be implemented as a Java Card applet. However, it is granted specific privileges on an implementation-specific manner ([39], §10).
interface A special kind of Java programming language class, which declares methods, but provides no imple-mentation for them. A class may be declared as being the implementation of an interface, and in this case must contain an implementation for each of the methods declared by the interface (See also shareable interface).
Java Card RE The runtime environment under which Java programs in a smart card are executed. It is in chargeof all the management features such as applet lifetime, applet isolation, object sharing, applet loading, applet initializing, transient objects, the transaction mechanism and so on.
Java Card RE Entry Point An object owned by the Java Card RE context but accessible by any application.These methods are the gateways through which applets request privileged Java Card RE services: the instance methods associated to those objects may be invoked from any context, and when that occurs, a context switch to the Java Card RE context is performed.
There are two categories of Java Card RE Entry Point Objects: Temporary ones and Permanent ones. As part of the firewall functionality, the Java Card RE detects and restricts attempts to store references to these objects.
Java Card RMI Java Card Remote Method Invocation is the Java Card System version 2.2 and 3 Classic Editionmechanism enabling a client application running on the CAD platform to invoke a method on a remote object on the card. Notice that in Java Card System, version 2.1.1, the only method that may be invoked from the CAD is the process method of the applet class and that in Java Card System, version 3 Classic Edition, this functionality is optional.
Java Card System Java Card System includes the Java Card RE, the Java Card VM, the Java Card API and the installer.
Java Card VM The embedded interpreter of bytecodes. The Java Card VM is the component that enforcesseparation between applications (firewall) and enables secure data sharing.
logical channel A logical link to an application on the card. A new feature of the Java Card System, version2.2 and 3 Classic Edition, that enables the opening of simultaneous sessions with the card, one per logical channel. Commands issued to a specific logical channel are forwarded to the active applet on that logical channel. Java Card platform, version 2.2.2 and 3 Classic Edition, enables opening up to twenty logical channels over each I/O interface (contacted or contactless).
NVRAM Non-Volatile Random Access Memory, a type of memory that retains its contents when power is turned off.
object deletion The Java Card System version 2.2 and 3 Classic Edition mechanism ensures that any unrefer-enced persistent (transient) object owned by the current context is deleted. The associated memory space is recovered for reuse prior to the next card reset.
PCD Proximity Coupling Device. The PCD is a contactless card reader device.
PICC Proximity Card. The PICC is a card with contactless capabilities.
Secure Box The Secure Box is a construct which allows to run non certified third party native code and ensuresthat this code cannot harm, influence or manipulate the JCOP operating system or any of the applets executed by the operating system.
Secure Box Native Library The Secure Box Native Library is non certified third party native code running in the Secure Box.
shareable interface An interface declaring a collection of methods that an applet accepts to share with otherapplets. These interface methods can be invoked from an applet in a context different from the context of the object implementing the methods, thus “traversing” the firewall.
SCP Smart Card Platform. It is comprised of the integrated circuit, the operating system and the dedicatedsoftware of the smart card.
SD Security Domain.
SFR Security Functional Requirement.
SPD Security Problem Definition.
SSD Supplementary Security Domain.
VASD Verification Authority Security Domain.
12 Bibliography
[1]Bundesamt für Sicherheit in der Informationstechnik, Technische Richtlinie - Kryptographische Verfahren: Empfehlungen und Schlüssellängen, 09. Januar 2013, BSI-TR02102.
[2]Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, April 2017, Version 3.1, Revision 5, CCMB-2017-04-001.
[3]Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, April 2017, Version 3.1, Revision 5, CCMB-2017-04-002.
[4]Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, April 2017, Version 3.1, Revision 5, CCMB-2017-04-003.
[5]Common Criteria Protection Profile, Machine Readable Travel Document with ICAO Application, Basic Ac-cess Control, registered and certified by Bundesamt fuer Sicherheit in der Informationstechnik (BSI) under the reference BSI-CC-PP-0055, Rev 1.10, 25 March 2009.
[6]Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, April 2017, Version 3.1, Revision 5, CCMB-2017-04-004.
[7]FIPS 197: ADVANCED ENCRYPTION MISC (AES).
[8]FIPS PUB 140-2: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, Security Re-quirements for Cryptographic Modules, National Institute of Standards and Technology, 2001 May 25.
[9]ICAO, TECHNICAL REPORT, Supplemental Access Control for Machine Readable Travel Documents, Ver-sion 1.1, 15 April 2014.
[10]ISO/IEC 14443 Proximity Cards - Part 4: Transmission protocol - ISO/IEC 14443-2:2008.
[11]ISO/IEC 14888-3:2006 Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms.
[12]ISO/IEC 9797-1:1999 Information technology Security techniques Message Authentication Codes (MACs) Part 1: Mechanisms using a block cipher, 1999.
[13]Java Card System - Open Configuration Protection Profile, December 2017, Version 3.0.5, Published by Oracle, Inc.
[14]JCOP 4 P71, User manual for JCOP 4 P71, Rev. 3.7, DocNo 469537, 20190528, NXP Semiconductors.
[15]JCOP 4 SE050, User manual for JCOP 4 SE050, Rev. 1.2, DocNo 500312, 20190531, NXP Semiconductors.
[16]NIST Special Publication 800-38A Recommendation for BlockCipher Modes of Operation.
[17]NIST Special Publication 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Dis-crete Logarithm Cryptography.
[18]NIST Special Publication 800-73-4 Interfaces for Personal Identity Verification - Part 2: PIV Card Application Card Command Interface.
[19]NXP Secure Smart Card Controller N7121, Preliminary data sheet, V2.0, 2018-08-31.
[20]NXP Secure Smart Card Controller N7121 with IC Dedicated Software and Crypto Library, Security Target, Rev. 1.4, 2018-11-30, BSI-DSZ-CC-1040.
[21]NXP Semiconductors, https://www.docstore.nxp.com.
[22]PUF Key derivation function specification, NXP Semiconductors, BUID, 2014.
[23]SE050 Family, Data Sheet, V0.1, 2018-04-03.
[24]Security IC Platform Protection Profile, registered and certified by Bundesamt fuer Sicherheit in der Informa-tionstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Rev 1.0, 13 January 2014.
[25]The Java Language Specification. Third Edition, May 2005. Gosling, Joy, Steele and Bracha. ISBN 0-321-24678-0.
[26]The Java Virtual Machine Specification. Lindholm, Yellin. ISBN 0-201-43294-3.
[27]TPM Rev. 2.0: Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.07- March 2014.
[28]UM10204, I2C-bus specification and user manual, Rev. 6, 4 April 2014, available at http://www.nxp.com/documents/user_manual/UM10204.pdf.
[29]Java Card System MISC 2.2 Configuration Protection Profile, Version 1.0b, August 2003.
[30]Java Card System Protection Profile Collection, Version 1.0b, August 2003.
[31]ISO 7816-3: Part 3:Cards with contacts - Electrical interface and transmission protocols , Nov 2006.
[32]RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010.
[33]GlobalPlatform Card Mapping Guidelines of Existing GP v2.1.1 Implementation on v2.2.1, January 2011.
[34]Security Upgrade for Card Content Management Card Specification v2.2 - Amendment E v1.0, November 2011.
[35]Contactless Services, GlobalPlatform Card Specification v 2.2 - Amendment C v1.0.1, February 2012.
[36]GlobalPlatform Card Technology, Secure Channel Protocol ’03’, Card Specification v 2.2 - Amendment D v1.1.1, July 2014.
[37]GlobalPlatform Card Specification 2.3, GPC_SPE_034, GlobalPlatform Inc., October 2015.
[38]Published by Oracle. Java Card 3 Platform, Application Programming Interface, Classic Edition, Version 3.0.5., May 2015.
[39]Published by Oracle. Java Card 3 Platform, Runtime Environment Specification, Classic Edition, Version 3.0.5., May 2015.
[40]Published by Oracle. Java Card 3 Platform, Virtual Machine Specification, Classic Edition, Version 3.0.5., May 2015.
[41]Bundesamt fuer Sicherheit in der Informationstechnik. Anwendungshinweise und Interpretationen zum Schema, AIS 20:Funktionalitaetsklassen und Evaluationsmethodologie fuer deterministische Zufallszahlen-generatoren, Version 2.1, 2.12.2011.
13 Legal information
13.1 Definitions
Draft – The document is a draft version only. The content is still under internalreview and subject to formal approval, which may result in modifications or addi-tions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included herein and shall have no liability for the consequences of use of such information.
13.2 Disclaimers
Limited warranty and liability – Information in this document is believed tobe accurate and reliable. However, NXP Semiconductors does not give any representations or warranties, expressed or implied, as to the accuracy or com-pleteness of such information and shall have no liability for the consequences of use of such information.
In no event shall NXP Semiconductors be liable for any indirect, incidental, punitive, special or consequential damages (including - without limitation - lost profits, lost savings, business interruption, costs related to the removal or re-placement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory.
Notwithstanding any damages that customer might incur for any reason whatso-ever, NXP Semiconductors’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors.
Right to make changes – NXP Semiconductors reserves the right to makechanges to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publi-cation hereof.
Suitability for use – NXP Semiconductors products are not designed, autho-rized or warranted to be suitable for use in life support, life-critical or safety-critical systems or equipment, nor in applications where failure or malfunction of an NXP Semiconductors product can reasonably be expected to result in personal injury, death or severe property or environmental damage. NXP Semi-conductors accepts no liability for inclusion and/or use of NXP Semiconductors products in such equipment or applications and therefore such inclusion and/or use is at the customer’s own risk.
Applications – Applications that are described herein for any of these productsare for illustrative purposes only. NXP Semiconductors makes no represen-tation or warranty that such applications will be suitable for the specified use without further testing or modification.
Customers are responsible for the design and operation of their applications and products using NXP Semiconductors products, and NXP Semiconductors accepts no liability for any assistance with applications or customer product design. It is customer’s sole responsibility to determine whether the NXP Semiconductors product is suitable and fit for the customer’s applications and products planned, as well as for the planned application and use of customer’s third party customer(s). Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products.
NXP Semiconductors does not accept any liability related to any default, dam-age, costs or problem which is based on any weakness or default in the customer’s applications or products, or the application or use by customer’s third party customer(s). Customer is responsible for doing all necessary testing for the customer’s applications and products using NXP Semiconductors prod-ucts in order to avoid a default of the applications and the products or of the application or use by customer’s third party customer(s). NXP does not accept any liability in this respect.
Export control – This document as well as the item(s) described herein may besubject to export control regulations. Export might require a prior authorization from competent authorities.
Evaluation products – This product is provided on an “as is” and “with allfaults” basis for evaluation purposes only. NXP Semiconductors, its affiliates and their suppliers expressly disclaim all warranties, whether express, implied or statutory, including but not limited to the implied warranties of non-infringement, merchantability and fitness for a particular purpose. The entire risk as to the quality, or arising out of the use or performance, of this product remains with customer.
In no event shall NXP Semiconductors, its affiliates or their suppliers be li-able to customer for any special, indirect, consequential, punitive or incidental damages (including without limitation damages for loss of business, business interruption, loss of use, loss of data or information, and the like) arising out the use of or inability to use the product, whether or not based on tort (including negligence), strict liability, breach of contract, breach of warranty or any other theory, even if advised of the possibility of such damages.
Notwithstanding any damages that customer might incur for any reason whatso-ever (including without limitation, all damages referenced above and all direct or general damages), the entire liability of NXP Semiconductors, its affiliates and their suppliers and customer’s exclusive remedy for all of the foregoing shall be limited to actual damages incurred by customer based on reasonable reliance up to the greater of the amount actually paid by customer for the product or five dollars (US$5.00). The foregoing limitations, exclusions and disclaimers shall apply to the maximum extent permitted by applicable law, even if any remedy fails of its essential purpose.
13.3 Licenses
ICs with DPA Countermeasures functionality
NXP ICs containing functionality implementing countermeasures to Differential Power Analy-sis and Simple Power Analysis are produced and sold under applicable license from Cryp-tography Research, Inc.
13.4 Patents
Notice is herewith given that the subject device uses one or more of the follow-ing patents and that each of these patents may have corresponding patents in other jurisdictions.
13.5 Trademarks
Notice: All referenced brands, product names, service names and trademarks are property of their respective owners.
MIFARE – is a trademark of NXP B.V.
Please be aware that important notices concerning this document and the prod-uct(s) described herein, have been included in the section ’Legal information’.
©NXP B.V. 2019. 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: 2019-06-0
Document identifier: NSCIB-CC-180
9 Contents
| 1 ST Introduction (ASE_INT) | |||
| 1.2.3 Required non-TOE Hardware/Software/Firmware | |||
2 Conformance Claims (ASE_CCL) | |||
3 Security Aspects | |||
4 Security Problem Definition (ASE_SPD) | |||
6 Extended Components Definition (ASE_ECD) | |||
7 Security Requirements (ASE_REQ) | |||
8 TOE summary specification (ASE_TSS) | |||
13 Legal information | |||