Java Cards

NXP JCOP 4 Security Target Lite v3.4 3

2020-07-14 16:05:17 M&W SmartCard 1

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.

SA.FIREWALL

Firewall


The Firewall shall ensure controlled sharing of class instances1, and isolation of their data and code between packages (that is, controlled execution contexts) as well as between packages and the JCRE context. An applet shall not read, write, compare a piece of data belonging to an applet that is not in the same context, or execute one of the methods of an applet in another context without its authorization.

SA.NATIVE

Native Code Execution


Because the execution of native code is outside of the JCS TSF scope, it must be secured so as to not provide ways to bypass the TSFs of the JCS. Loading of native code, which is as well outside those TSFs, is submitted to the same requirements. Should native software be privileged in this respect, exceptions to the policies must include a rationale for the new security framework they introduce.

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.1 ST Reference and TOE Reference

1.2 TOE Overview


1.2.1 Usage and Major Security Features of the TOE

1.2.2 TOE Type

1.2.3 Required non-TOE Hardware/Software/Firmware

1.3 TOE Description


1.3.1 TOE Components and Composite Certi fication

1.3.2 Optional TOE Functionality

1.3.3 TOE Life Cycle

1.3.4 TOE Identification

1.3.5 Evaluated Package Types


2 Conformance Claims (ASE_CCL)


2.1 CC Conformance Claim

2.2 Package Claim

2.3 PP Claim

2.4 Conformance Claim Rationale


2.4.1 TOE Type

2.4.2 SPD Statement

2.4.3 Security Objectives Statement

2.4.4 Security Functional Requirements State ment

3 Security Aspects


3.1 Confidentiality

3.2 Integrity

3.3 Unauthorized Executions

3.4 Bytecode Verification

3.5 Card Management

3.6 Services

3.7 External Memory

3.8 Configuration Module

3.9 Modular Design

3.10 Restricted Mode

4 Security Problem Definition (ASE_SPD)


4.1 Assets


4.1.1 User Data

4.1.2 TSF Data

4.2 Threats


4.2.1 Confidentiality

4.2.2 Integrity

4.2.3 Identity Usurpation

4.2.4 Unauthorized Execution

4.2.5 Denial of Service

4.2.6 Card Management

4.2.7 Services

4.2.8 Miscellaneous

4.2.9 Operating System

4.2.10 Random Numbers

4.2.11 Configuration Module

4.2.12 Secure Box

4.2.13 Module replacement

4.2.14 Restricted Mode

4.3 Organisational Security Policies

4.4 Assumptions

5 Security Objectives


5.1 Security Objectives for the TOE


5.1.1 Identification

5.1.2 Execution

5.1.3 Services

5.1.4 Object Deletion

5.1.5 Applet Management

5.1.6 External Memory

5.1.7 Card Management

5.1.8 Smart Card Platform

5.1.9 Secure Box

5.1.10 Random Numbers

5.1.11 Configuration Module

5.1.12 Restricted Mode

5.2 Security Objectives for the Operational Environment

5.3 Security Objectives Rationale


5.3.1 Threats

5.3.2 Organisational Security Policies

5.3.3 Assumptions


6 Extended Components Definition (ASE_ECD)


6.1 Definition of Family ”Audit Data Storage (FAU_SAS)”

6.2 Definition of Family ”TOE emanation (FPT_EMSEC)”

7 Security Requirements (ASE_REQ)


7.1 Definitions


7.1.1 Groups

7.1.2 Subjects

7.1.3 Objects

7.1.4 Informations

7.1.5 Security Attributes

7.1.6 Operations

7.2 Security Functional Requirements


7.2.1 COREG_LC Security Functional Requirements

7.2.2 INSTG Security Functional Requirements

7.2.3 ADELG Security Functional Requirements

7.2.4 RMIG Security Functional Requirements

7.2.5 ODELG Security Functional Requirements

7.2.6 CarG Security Functional Requirements .

7.2.7 EMG Security Functional Requirements .

7.2.8 ConfG Security Functional Requirements

7.2.9 SecBoxG Security Functional Requirements

7.2.10 ModDesG Security Functional Requirements

7.2.11 RMG Security Functional Requirements .

7.2.12 Further Security Functional Requirements

7.3 Security Assurance Requirements

7.4 Security Requirements Rationale for the TOE


7.4.1 Identification

7.4.2 Execution

7.4.3 Services

7.4.4 Object Deletion

7.4.5 Applet Management

7.4.6 External Memory

7.4.7 Card Management

7.4.8 Smart Card Platform

7.4.9 Random Numbers

7.4.10 Configuration Module

7.4.11 Secure Box

7.4.12 Restricted Mode

7.5 SFR Dependencies


7.5.1 Rationale for Exclusion of Dependencies


7.6 Security Assurance Requirements Rationale

8 TOE summary specification (ASE_TSS)


8.1 Introduction

8.2 Security Functionality

8.3 Protection against Interference and Logical Tampering

8.4 Protection against Bypass of Security Related Actions

9 Contents

10 Glossary

11 Acronyms

12 Bibliography

13 Legal information


13.1 Definitions

13.2 Disclaimers

13.3 Licenses

13.4 Patents

13.5 Trademarks

Java Card is an open standard from Sun Microsystems for a smart card developmentplatform. Smart cards created using the Java Card platform have Java applets stored on them. The applets can be added to or changed after the card is issued.

There are two basic types of smart cards. The memory smart card is the familiar removable memory device; it usually features read and write capabilities and perhaps security features. The more complex version, the processor smart card, is a very small and extremely portable computing device that could be carried in your wallet. Java-based smart cards belong to the latter category. They store data on an integrated microprocessor chip. Applets are loaded into the memory of the microprocessor and run by the Java Virtual Machine. Similarly to MULTOS, another smart card development technology, Java Card enables multiple application programs to be installed and coexist independently. Individual applets are protected by a firewall to preserve their integrity and prevent tampering. Applications can be updated dynamically.

In the United States, the Department of Defense, Visa, and American Express are among the organizations creating Java Card-based applications.


Home
Product
News
Contact us