NXP JCOP 4 Security Target Lite v3.4 4
4 Security Problem Definition (ASE_SPD)
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.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 .
4.1.1 User Data
The code of the applets and libraries loaded on the card. To be protected from unauthorized modification.
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.
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 modifica- tion
Cryptographic keys owned by the applets. To be protected from unauthorized disclosure and modification.
Refinement of D.APP_KEYS of . Application Provider Se-curity Domains cryptographic keys 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 appropri-ate privileges. To be protected from unauthorized disclosure and modification.
Refinement of D.APP_KEYS of . Issuer Security Domain cryptographic keys needed to perform card management oper-ations on the card. To be protected from unauthorized disclosure and modification.
Refinement of D.APP_KEYS of . Verification Authority Se-curity Domain cryptographic keys needed to verify applications Mandated DAP signature. To be protected from unauthorized disclosure and modification.
The data of the card management environment, like for instance, the identifiers, the privileges, life cycle states. To be protected from unauthorized modification.
Any end-user’s PIN. To be protected from unauthorized disclo-sure and modification.
Tab. 4.1: User Data Assets
Private data of the API, like the contents of its private fields. To be protected from unauthorized disclosure and modification.
Cryptographic data used in runtime cryptographic computations, like a seed used to generate a key. To be protected from unau-thorized disclosure and modification.
The code of the Java Card System. To be protected from unau-thorized disclosure and modification.
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
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 modifi-cation.
A configuration that can be changed using the Configuration Mechanism.
The code of a Module. The code of a module might comprise Java code, native code, code of a native Library or a combina-tion of them. To be protected against unauthorized disclosure and modification. Further to be protected against unauthorized removal or presence forgery.
Private data of a Module, like the contents of its private fields. To be protected from unauthorized disclosure and modification.
The Attack Counter is incremented when a potential attack is de-tected. When the Attack Counter reaches its limit, the card goes into restricted mode.
Tab. 4.2: TSF Data Assets
T.CONFID-APPLI-DATA Confidentiality of Application Data
The attacker executes an application to disclose data belonging to another ap-plication. See SA.CONFID-APPLI-DATA for details. Directly threatened asset(s): D.APP_C_DATA, D.PIN and D.APP_KEYS.
T.CONFID-JCS-CODE Confidentiality of Java Card System Code
The attacker executes an application to disclose the Java Card System code. See SA.CONFID-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE and D.MODULE_CODE.
T.CONFID-JCS-DATA Confidentiality of Java Card System Data
The attacker executes an application to disclose data belonging to the Java Card System. See SA.CONFID-JCS-DATA for details. Directly threatened asset(s): D.API_DATA, D.SEC_DATA, D.JCS_DATA, D.CRYPTO and D.MODULE_CODE.
Integrity of Application Code
The attacker executes an application to alter (part of) its own code or another application’s code. See SA.INTEG-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE and D.MODULE_CODE.
Integrity of Application Code - Load
The attacker modifies (part of) its own or another application code when an appli-cation package is transmitted to the card for installation. See SA.INTEG-APPLI- CODEfor details. Directly threatened asset(s): D.APP_CODE.
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 S.APSD_KEYS. This threat is a refinement of the Threat T.INTEG-APPLI-DATA from .
Integrity of Application Data - Load
The attacker modifies (part of) the initialization data contained in an applica- tion package when the package is transmitted to the card for installation. See SA.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_DATA and D.APP_KEYS.
Integrity of Java Card System Code
The attacker executes an application to alter (part of) the Java Card System code. See SA.INTEG-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE and D.MODULE_CODE.
Integrity of Java Card System Data
The attacker executes an application to alter (part of) Java Card System or API data. See SA.INTEG-JCS-DATAfor details. Directly threatened asset(s): D.API_ DATA, D.SEC_DATA, D.JCS_DATA, D.CRYPTO and D.MODULE_DATA.
An applet or Module impersonates another application or Module, or even the Java Card RE, in order to gain illegal access to some resources of the card or with respect to the end user or the terminal. See SA.SID and SA.MODULAR- DESIGNfor details. Directly threatened asset(s): D.SEC_DATA (other assets may be jeopardized should this attack succeed, for instance, if the identity of the JCRE is usurped), D.PIN and D.APP_KEYS.
The attacker modifies the TOE’s attribution of a privileged role (e.g. default ap-plet and currently selected applet), which allows illegal impersonation of this role. See SA.SIDfor further details. Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should this attack succeed, depending on whose identity was forged).
4.2.4 Unauthorized Execution
T.EXE-CODE. Code Execution
T.EXE-CODE. Code Execution
T.NATIVE Native Code Execution
An applet executes a native method to bypass a TOE Security Function such as the firewall. See SA.NATIVE for details. Directly threatened asset(s): D.JCS_ DATA.
T.MODULE_EXECCode Execution of Modules
The attacker bypasses the presence check of a not present Module with TOE internal interface to execute arbitrary code. See SA.MODULAR-DESIGNand SA.MODULE-INVOCATIONfor details. Directly threatened asset(s): D.MODULE_ CODE.
4.2.5 Denial of Service
T.RESOURCES Consumption of Resources
An attacker prevents correct operation of the Java Card System through consump- tion of some resources of the card: RAM or NVRAM. See SA.RESOURCES for details. Directly threatened asset(s): D.JCS_DATA.
4.2.6 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 as- set 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 .
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 at- tacker repersonalizes the application). Directly threatened asset(s): D.APP_I_ DATA, D.APP_C_DATA, and D.CARD_MNGT_DATA.
T.OBJ-DELETION Object Deletion
The attacker keeps a reference to a garbage collected object in order to force the TOE to execute an unavailable method, to make it to crash, or to gain access to a memory containing data that is now being used by another application. See SA.OBJ-DELETION for further details. Directly threatened asset(s): D.APP_C_ DATA, D.APP_I_DATA and D.APP_KEYS.
T.PHYSICAL Physical Tampering
The attacker discloses or modifies the design of the TOE, its sensitive data or application code by physical (opposed to logical) tampering means. This threat in- cludes IC failure analysis, electrical probing, unexpected tearing, and Differential Power Analysis (DPA). That also includes the modification of the runtime execution of Java Card System or SCP software through alteration of the intended execution order of (set of) instructions through physical tampering techniques. This threat- ens all the identified assets. This threat refers to the point (7) of the security aspect SA.SCP, and all aspects related to confidentiality and integrity of code and data. Application note: If sensitive result is supported by the TOE, this threat covers the following sub- threat exploiting specifically the listed assets below:
•The attacker performs a physical manipulation to alter (part of) an applica-tion’s integrity-sensitive data. See SA.INTEG-APPLI-DATA-PHYS for details. Directly threatened asset(s): D.APP_I_DATA, D.PIN, and D.APP_KEYS.
4.2.9 Operating System
T.OS_OPERATE Incorrect Operating System Behavior
Modification of the correct OS behavior by unauthorized use of TOE or use of incorrect or unauthorized instructions or commands or sequence of commands, in order to obtain an unauthorized execution of the TOE code. An attacker may cause a malfunction of TSF or of the Smart Card embedded OS in order to (1) by- pass the security mechanisms (i.e. authentication or access control mechanisms) or (2) obtain unexpected result from the embedded OS behavior. Different kind of attack path may be used as:
1. Applying incorrect unexpected or unauthorized instructions, commands or command sequences,
2. Provoking insecure state by insertion of interrupt (reset), premature termina-tion of transaction or communication between IC and the reading device
Info:Any implementation flaw in the OS itself can be exploited with this attack path to lead to an unsecured state of the state machine of the OS. The attacker uses the available interfaces of the TOE. A user could have certain specified priv- ileges that allow loading of selected programs. Unauthorized programs, if allowed to be loaded, may include either the execution of legitimate programs not intended for use during normal operation (such as patches, filters, Trojan horses, etc.) or the unauthorized loading of programs specifically targeted at penetration or mod- ification of the security functions. Attempts to generate a non-secure state in the Smart Card may also be made through premature termination of transactions or communications between the IC and the card reading device, by insertion of in- terrupts, or by selecting related applications that may leave files open.
4.2.10 Random Numbers
T.RND &nnbsp; 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 pro- vided. 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 statis- tical 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.
4.2.11 Configuration Module
T.CONFIG Unauthorized configuration
The attacker tries to change configuration items without authorization. Directly threatened asset(s): D.CONFIG_ITEM.
4.2.12 Secure Box
T.SEC_BOX_BORDER SecureBox Border Infringement
An attacker may try to use malicious code placed in the Secure Box to modify the correct behavior of the Operating System (OS). With the aim to
1. disclose the Java Card System code,
2.disclose or alter applet code, disclose or alter Java Card System data, or disclose or alter applet data.
T.MODULE_REPLACEMENT Replacement of Module
An attacker loads a Module with functionality differing from a previously deleted Module to bypass TOE Security Functions. See SA.MODULAR-DESIGNfor de-tails. Directly threatened assets: D.JCS_DATA.
4.2.14 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.
4.3 Organisational Security Policies
This policy is upheld by the security objective of the environment OE.VERIFICATION which guarantees that all the bytecodes shall be verified at least once, before the loading, before the installation or before the execution in order to ensure that each bytecode is valid at execution time. This policy is also upheld by the security objective of the environment OE.CODE-EVIDENCE which ensures that evidences exist that the application code has been verified and not changed after verification, and by the security objective for the TOE O.LOAD which shall ensure that the loading of a package into the card is safe.
Identification of the TOE
An accurate identification must be established for the TOE. This requires that each instantiation of the TOE carries this identification.
Security Domain Keys Change
The Application Provider (AP) shall change its initial security domain keys (APSD) before any operation on its Security Domain.
Security domains can be dynamically created, deleted and blocked during usage phase in post-issuance mode.
Secure Box Border
Execution of untrusted native code shall be possible without any harm, manipula-tion, or influence on other parts of the TOE.
Note that the assumption A.DELETION is excluded. The Card Manager is part of the TOE and therefore the
assumption is no longer relevant.
A.APPLET Applets without Native Methods
Applets loaded post-issuance do not contain native methods. The Java Card spec- ification explicitly ”does not include support for native methods” () outside the API.
A.VERIFICATION Bytecode Verification
All the bytecodes are verified at least once, before the loading, before the installa- tion or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time.
A.USE_DIAG Usage of TOE’s Secure Communication Protocol by OE
It is assumed that the operational environment supports and uses the secure com- munication 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 disclo- sure of such information which is shared with the TOE but is not under the TOE control, may compromise the security of the TOE.
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:
1. the Security IC Embedded Software including specifications, implementation and related documentation,
2. pre-personalisation and personalisation data including specifications of for-mats and memory areas, test related data,
3. the User Data and related documentation, and
4. material for software development support as long as they are not under the control of the TOE Manufacturer.
The AP is a trusted actor that provides basic or secure applications. He is respon- sible for his security domain keys (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.
The VA is a trusted actor who is able to guarantee and check the digital signature attached to a basic or secure application.
Info: As a consequence, it guarantees the success of the application validation upon loading.
|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