NXP JCOP 4 Security Target Lite v3.4 3
3 Security Aspects
This Chapter describes the main security issues of the Java Card System and its environment addressed in this ST, called "security aspects", in a CC-independent way. In addition to this, they also give a semi-formal framework to express the CC security environment and objectives of the TOE. They can be instantiated as assumptions, threats, objectives (for the TOE and the environment) or organizational security policies. The description is based on [13].
3.1 Confidentiality
SA.CONFID-APPLI-DATA Confidentiality of Application Data
Application data must be protected against unauthorized disclosure. This con-cerns logical attacks at runtime in order to gain read access to other application’s data.
SA.CONFID-JCS-CODE Confidentiality of Java Card System Code
Java Card System code must be protected against unauthorized disclosure. Knowl-edge of the Java Card System code may allow bypassing the TSF. This concerns logical attacks at runtime in order to gain a read access to executable code, typi-cally by executing an application that tries to read the memory area where a piece of Java Card System code is stored.
SA.CONFID-JCS-DATA Confidentiality of Java Card System Data
Java Card System data must be protected against unauthorized disclosure. This concerns logical attacks at runtime in order to gain a read access to Java Card System data. Java Card System data includes the data managed by the Java Card RE, the Java Card VM and the internal data of Java Card platform API classes as well.
3.2 Integrity
SA.INTEG-APPLI-CODE Integrity of Application Code
Application code must be protected against unauthorized modification. This con-cerns logical attacks at runtime in order to gain write access to the memory zone where executable code is stored. In post-issuance application loading, this threat also concerns the modification of application code in transit to the card.
SA.INTEG-APPLI-DATA Integrity of Application Data
Application data must be protected against unauthorized modification. This con-cerns logical attacks at runtime in order to gain unauthorized write access to ap-plication data. In post-issuance application loading, this threat also concerns the modification of application data contained in a package in transit to the card. For instance, a package contains the values to be used for initializing the static fields of the package.
SA.INTEG-APPLI-DATA-PHYS Integrity of Application Data (Sensitive Result)
Integrity-sensitive application data must be protected against unauthorized modi-fication by physical attacks.
SA.INTEG-JCS-CODE Integrity of Java Card System Code
Java Card System code must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to executable code.
SA.INTEG-JCS-DATA Integrity of Java Card System Data
Java Card System data must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to Java Card System data. Java Card System data includes the data managed by the Java Card RE, the Java Card VM and the internal data of Java Card API classes as well.
3.3 Unauthorized Executions
SA.EXE-APPLI-CODE Execution of Application Code
Application (byte)code must be protected against unauthorized execution. This concerns:
1.invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java programming language ([25])
2.jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code
3.unauthorized execution of a remote method from the CAD (if the TOE pro-vides JCRMI functionality).
SA.EXE-JCS-CODE &nbnbsp; Execution of Java Card System Code
Java Card System bytecode must be protected against unauthorized execution. Java Card System bytecode includes any code of the Java Card RE or API. This concerns:
1.invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java programming language ([25])
2.jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code. Note that execute access to native code of the Java Card System and applications is the concern of SA.NATIVE.
3.4 Bytecode Verification
SA.VERIFICATIONBytecode Verification
Bytecode must be verified prior to being executed. Bytecode verification includes:
1.how well-formed CAP file is and the verification of the typing constraints on the bytecode,
2.binary compatibility with installed CAP files and the assurance that the ex-port files used to check the CAP file correspond to those that will be present on the card when loading occurs.
3.5 Card Management
SA.CARD-MANAGEMENT Card Management
1.The card manager (CM) shall control the access to card management func-tions such as the installation, update or deletion of applets.
2.The card manager shall implement the card issuer’s policy on the card.
SA.INSTALL Installation
1.The TOE must be able to return to a safe and consistent state when the installation of a package or an applet fails or be cancelled (whatever the reasons).
1This concerns in particular the arrays, which are considered as instances of the Object class in the Java programming language.
2. | Installing an applet must have no effect on the code and data of already installed applets. The installation procedure should not be used to bypass the TSFs. In short, it is an atomic operation, free of harmful effects on the state of the other applets. | |
3. | The procedure of loading and installing a package shall ensure its integrity and authenticity. | |
SA.SID | Subject Identification | |
1. | Users and subjects of the TOE must be identified. | |
2. | The identity of sensitive users and subjects associated with administrative and privileged roles must be particularly protected; this concerns the Java Card RE, the applets registered on the card, and especially the default applet nd the currently selected applet (and all other active applets in Java Card System). A change of identity, especially standing for an administrative role (like an applet impersonating the Java Card RE), is a severe violation of the Security Functional Requirement (SFR). Selection controls the access to any data exchange between the TOE and the CAD and therefore, must be protected as well. The loading of a package or any exchange of data through the APDU buffer (which can be accessed by any applet) can lead to disclosure of keys, application code or data, and so on. | |
SA.OBJ-DELETION | Object Deletion | |
1. | Deallocation of objects should not introduce security holes in the form of references pointing to memory zones that are not longer in use, or have been reused for other purposes. Deletion of collection of objects should not be maliciously used to circumvent the TSFs. | |
2. | Erasure, if deemed successful, shall ensure that the deleted class instance is no longer accessible. | |
SA.DELETION | Deletion | |
1. | Deletion of installed applets (or packages) should not introduce security holes in the form of broken references to garbage collected code or data, nor should they alter integrity or confidentiality of remaining applets. The deletion procedure should not be maliciously used to bypass the TSFs. | |
2. | Erasure, if deemed successful, shall ensure that any data owned by the deleted applet is no longer accessible (shared objects shall either prevent deletion or be made inaccessible). A deleted applet cannot be selected or receive APDU commands. Package deletion shall make the code of the package no longer available for execution. | |
3. | Power failure or other failures during the process shall be taken into account in the implementation so as to preserve the SFRs. This does not mandate, however, the process to be atomic. For instance, an interrupted deletion may result in the loss of user data, as long as it does not violate the SFRs. | |
The deletion procedure and its characteristics (whether deletion is either physi-cal or logical, what happens if the deleted application was the default applet, the order to be observed on the deletion steps) are implementation-dependent. The only commitment is that deletion shall not jeopardize the TOE (or its assets) in case of failure (such as power shortage). Deletion of a single applet instance and deletion of a whole package are func- tionally different operations and may obey different security rules. For instance, specific packages can be declared to be undeletable (for instance, the Java Card API packages), or the dependency between installed packages may forbid the deletion (like a package using super classes or super interfaces declared in an- other package). | ||
3.6 Services
SA.ALARM Alarm
The TOE shall provide appropriate feedback upon detection of a potential security violation. This particularly concerns the type errors detected by the bytecode verifier, the security exceptions thrown by the Java Card VM, or any other security- related event occurring during the execution of a TSF.
SA.OPERATE Operate
1. The TOE must ensure continued correct operation of its security functions.
2. In case of failure during its operation, the TOE must also return to a well- defined valid state before the next service request.
SA.RESOURCES Resources
The TOE controls the availability of resources for the applications and enforces quotas and limitations in order to prevent unauthorized denial of service or mal- function of the TSFs. This concerns both execution (dynamic memory allocation) and installation (static memory allocation) of applications and packages.
SA.CIPHER Cipher
The TOE shall provide a means to the applications for ciphering sensitive data, for instance, through a programming interface to low-level, highly secure crypto-graphic services. In particular, those services must support cryptographic algo-rithms consistent with cryptographic usage policies and standards.
SA.KEY-MNGT | Key Management | |
The TOE shall provide a means to securely manage cryptographic keys. This includes: | ||
1. | Keys shall be generated in accordance with specified cryptographic key gen-eration algorithms and specified cryptographic key sizes, | |
2. | Keys must be distributed in accordance with specified cryptographic key dis- tribution methods, | |
3. | Keys must be initialized before being used, | |
4. | Keys shall be destroyed in accordance with specified cryptographic key de-struction methods. | |
SA.PIN-MNGT | PIN Management | |
The TOE shall provide a means to securely manage PIN objects. This includes: | ||
1. | Atomic update of PIN value and try counter, | |
2. | No rollback on the PIN-checking function, | |
3. | Keeping the PIN value (once initialized) secret (for instance, no clear-PIN-reading function), | |
4. | Enhanced protection of PIN’s security attributes (state, try counter ...) in confidentiality and integrity. | |
SA.SCP | Smart Card Platform | |
The smart card platform must be secure with respect to the SFRs. Then: | ||
1. | After a power loss, RF signal loss or sudden card removal prior to completion of some communication protocol, the SCP will allow the TOE on the next power up to either complete the interrupted operation or revert to a secure state. | |
2. | It does not allow the SFRs to be bypassed or altered and does not allow access to other low-level functions than those made available by the pack-ages of the Java Card API. That includes the protection of its private data and code (against disclosure or modification) from the Java Card System. | |
3. | It provides secure low-level cryptographic processing to the Java Card Sys-tem. | |
4. | It supports the needs for any update to a single persistent object or class field to be atomic, and possibly a low-level transaction mechanism. | |
5. | It allows the Java Card System to store data in a ”persistent technology memory” or in volatile memory, depending on its needs (for instance, tran-sient objects must not be stored in non-volatile memory). The memory model is structured and allows for low-level control accesses (segmentation fault detection). | |
6. | It safely transmits low-level exceptions to the TOE (arithmetic exceptions, checksum errors), when applicable. | |
7. | Finally, it is required that the IC is designed in accordance with a well-defined set of policies and standards (for instance, those specified in [24]), and will be tamper resistant to actually prevent an attacker from extracting or altering security data (like cryptographic keys) by using commonly employed tech- niques (physical probing and sophisticated analysis of the chip). This espe- cially matters to the management (storage and operation) of cryptographic keys. | |
SA.TRANSACTION Transaction
The TOE must provide a means to execute a set of operations atomically. This mechanism must not jeopardise the execution of the user applications. The trans-action status at the beginning of an applet session must be closed (no pending updates).
3.7 External Memory
SA.EXT-MNGT External Memory
The Extended Memory feature is an API-based mechanism to access the external memory outside the addressable Java Card VM space.
3.8 Configuration Module
SA.CONFIGURATION-MODULE Configuration Module
The Configuration Module is a JCOP functionality which allows to read and modify configuration items in the configuration area of the TOE.
3.9 Modular Design
SA.MODULAR-DESIGN Modular Design
The TOE might contain one or more Modules implementing particular functionality. The list of Modules present in the TOE must be retrievable. The Modules have an associated AID which allows to identify them. The AID is equivalent to the Package AID of JavaCard packages. Modules can only be deleted, re-loading of a previously deleted module or replacing a present module must not be possible.
Interfaces to a Module can be Public or TOE internal. Public Interfaces can directly be accessed by any Applet or via an APDU, TOE internal interfaces can only be accessed by the TOE itself, Applets use the corresponding JavaCard API [38].
SA.MODULE-INVOCATION Module Invocation
Invoking a module must be transparent to the user. If a Module has a TOE internal interface, is not present and is invoked by the user, the TOE must preserve a secure state by throwing an exception or returning an appropriate error status word to the CAD.
3.10 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.
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 | |||