Java Cards

NXP JCOP 4 Security Target Lite v3.4 6

2020-07-14 16:07:21 M&W SmartCard 1

5.3.

Threats








5.3.1.

Confidentiality







T.CONFID-APPLI-DATA

















Objective

Rationale







OT.SID

Counters this threat by providing correct identification of applets.







OT.FIREWALL

Counters this threat by providing the Java Card Virtual Machine Firewall as specified in [39].







OT.GLOBAL_ARRAYS_CONFID

Counters this threat by preventing the disclosure of the informa-tion stored in the APDU buffer.







OT.OPERATE

Counters the threat by ensuring that the firewall, which is dynam-ically enforced, shall never stop operating.







OT.REALLOCATION

Counters this threat by preventing any attempt to read a piece of information that was previously used by an application but has been logically deleted. It states that any information that was formerly stored in a memory block shall be cleared before the block is reused.







OT.ALARM

Counters this threat by obtaining clear warning and error mes-sages from the firewall, which is a software tool automating crit-ical controls, so that the appropriate countermeasure can be taken.







OT.CIPHER

Contributes to counter this threat by protecting the data shared or information communicated between applets and the CAD using cryptographic functions.







OT.KEY-MNGT

Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen- sitive data.







OT.PIN-MNGT

Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen-







OT.TRANSACTION

Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen- sitive data.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecode.







OT.EXT-MEM

Contributes to counter this threat by controlling the access to ex- ternal memory areas.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







OT.SCP.RECOVERY

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OT.SCP.SUPPORT

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OT.RNG

Counters this threat by providing appropriate management of keys, PIN’s which are particular cases of an application’s sen- sitive data.







T.CONFID-JCS-CODE


















Objective

Rationale







OT.NATIVE

Counters this threat by ensuring that no native applications can be run to modify a piece of code.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecode.







OT.EXT-MEM

Contributes to counter this threat by controlling the access to ex- ternal memory areas.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







T.CONFID-JCS-DATA


















Objective

Rationale







OT.SID

Counters this threat by providing correct identification of applets.







OT.FIREWALL

Contributes to counter this threat by providing means of separat- ing data.







OT.OPERATE

Counters the threat by ensuring that the firewall, which is dynam- ically enforced, shall never stop operating.







OT.ALARM

Contributes to counter this threat by obtaining clear warning and error messages from the firewall, which is a software tool au- tomating critical controls, so that the appropriate countermeasure can be taken.














OE.VERIFICATION

Contributes to counter the threat by checking the bytecode.







OT.EXT-MEM

Contributes to counter this threat by controlling the access to ex- ternal memory areas.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







OT.SCP.RECOVERY

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OT.SCP.SUPPORT

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OT.SID_MODULE

Counters this threat by providing correct identification of applets.







5.3.1.2 Integrity








T.INTEG-APPLI-CODE

















Objective

Rationale







OT.NATIVE

Counters this threat by ensuring that no native code can be run to modify a piece of code.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecode. Byte- code verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of these instruc- tions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code.














OT.EXT-MEM

Contributes to counter this threat by controlling the access to ex- ternal memory areas.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







OE.CODE-EVIDENCE

The objective OE.CODE-EVIDENCE contributes to counter this threat by ensuring that integrity and authenticity evidences exist for the application code loaded into the platform.







T.INTEG-APPLI-CODE.LOAD








OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions such as the installation, update or dele- tion of applets.







OE.CODE-EVIDENCE

Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity.







OT.APPLI-AUTH

Counters this threat by ensuring that the loading of packages is done securely and thus preserves the integrity of packages code.







T.INTEG-APPLI-DATA[REFINED]


















Objective

Rationale







OT.SID

Counters this threat by providing correct identification of applets.







OT.FIREWALL

Contributes to counter this threat by providing means of separat-ing data.







OT.GLOBAL_ARRAYS_INTEG

Counters this threat by ensuring the integrity of the information stored in the APDU buffer. Application data that is sent to the ap- plet as clear text arrives in the APDU buffer, which is a resource shared by all applications.














OT.OPERATE

Counters the threat by ensuring that the firewall, which is dynam- ically enforced, shall never stop operating.







OT.REALLOCATION

Counters the threat by preventing any attempt to read a piece of information that was previously used by an application but has been logically deleted. It states that any information that was formerly stored in a memory block shall be cleared before the block is reused.














OT.ALARM

Contributes to counter this threat by obtaining clear warning and error messages from the firewall, which is a software tool au- tomating critical controls, so that the appropriate countermeasure can be taken.














OT.CIPHER

Contributes to counter this threat by protecting the data shared or information communicated between applets and the CAD using cryptographic functions.







OT.KEY-MNGT

Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data.







OT.PIN-MNGT

Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data.







OT.TRANSACTION

Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecode.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







OT.SCP.RECOVERY

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.














OT.SCP.SUPPORT

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.














OE.CODE-EVIDENCE

Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity.














OT.DOMAIN-RIGHTS

Contributes to counter this threat by ensuring that personaliza- tion of the application by its associated security domain is only performed by the authorized AP.














OT.RNG

Counters this threat by providing appropriate management of keys, PINs which are particular cases of an application’s sen- sitive data.







T.INTEG-APPLI-DATA.LOAD


















Objective

Rationale







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions such as the installation, update or dele- tion of applets.







OE.CODE-EVIDENCE

Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity.







OT.APPLI-AUTH

Counters this threat by ensuring that the loading of packages is done securely and thus preserves the integrity of packages code.







T.INTEG-JCS-CODE


















Objective

Rationale







OT.NATIVE

Counters this threat by ensuring that no native code can be run to modify a piece of code.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecode. Byte- code verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility.  As none of these instruc- tions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code.














OT.EXT-MEM

Contributes to counter this threat by controlling the access to ex- ternal memory areas.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







OE.CODE-EVIDENCE

Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity.







T.INTEG-JCS-DATA


















Objective

Rationale







OT.SID

Counters this threat by providing correct identification of applets.







OT.FIREWALL

Contributes to counter this threat by providing means of separa- tion.







OT.OPERATE

Counters the threat by ensuring that the firewall shall never stop operating.







OT.ALARM

Contributes to counter this threat by obtaining clear warning and error messages from the firewall so that the appropriate counter- measure can be taken.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecodes.







OT.EXT-MEM

Contributes to counter this threat by controlling the access to ex- ternal memory areas.







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions.







OT.SCP.RECOVERY

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OT.SCP.SUPPORT

Intended to support the OT.OPERATE and OT.ALARMobjectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OE.CODE-EVIDENCE

Contributes to counter this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. Counters this threat by providing correct identification of applets.














OT.SID_MODULE







5.3.1.3Identity Usurpation








T.SID.


















Objective

Rationale







OT.SID

Counters this threat by providing unique subject identification.







OT.FIREWALL

Counters the threat by providing separation of application data (like PINs).







OT.GLOBAL_ARRAYS_CONFID

Counters this threat by preventing the disclosure of the installa- tion parameters of an applet (like its name). These parameters are loaded into a global array that is also shared by all the ap- plications. The disclosure of those parameters could be used to impersonate the applet.














OT.GLOBAL_ARRAYS_INTEG

Counters this threat by preventing the disclosure of the installa- tion parameters of an applet (like its name). These parameters are loaded into a global array that is also shared by all the ap- plications. The disclosure of those parameters could be used to impersonate the applet.














OT.CARD-MANAGEMENT

Contributes to counter this threat by preventing usurpation of identity resulting from a malicious installation of an applet on the card.







OT.SID_MODULE

Counters this threat by providing unique subject identification.







T.SID.


















Objective

Rationale







OT.SID

Counters this threat by providing unique subject identification.







OT.FIREWALL

Contributes to counter this threat by providing means of separa- tion.







OT.OPERATE

Counters the threat by ensuring that the firewall shall never stop operating.







OT.CARD-MANAGEMENT

Contributes to counter this threat by ensuring that installing an applet has no effect on the state of other applets and thus can’t change the TOE’s attribution of privileged roles.







OT.SCP.RECOVERY

Intended to support the OT.OPERATE and objectives of the TOE, thus indirectly related to the threats that these objectives con- tribute to counter.







OT.SCP.SUPPORT

Intended to support the OT.OPERATE and objectives of the TOE, thus indirectly related to the threats that these latter objectives contribute to counter.







5.3.1.4 Unauthorized Excecution








T.EXE-CODE.


















Objective

Rationale







OT.FIREWALL

Counters the threat by preventing the execution of non-shareable methods of a class instance by any subject apart from the class instance owner.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecodes. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of these instruc- tions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code.














T.EXE-CODE.


















Objective

Rationale







OE.VERIFICATION

Contributes to counter the threat by checking the bytecodes. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. Especially the control flow confinement and the validity of the method references used in the bytecodes are guaranteed.














T.NATIVE


















Objective

Rationale







OT.NATIVE

Counters this threat by ensuring that a Java Card applet can only access native methods indirectly that is, through an API.







OE.APPLET

Contributes to counter this threat by ensuring that no native ap- plets shall be loaded in post-issuance.







OE.VERIFICATION

Contributes to counter the threat by checking the bytecodes. Bytecode verification also prevents the program counter of an applet to jump into a piece of native code by confining the control flow to the currently executed method.














T.MODULE_EXEC









Objective

Rationale







OT.OPERATE

Counters the threat by ensuring correct working order.







OT.ALARM

Counters this threat by obtaining clear warning and error mes- sages when the TOE internal interface of a ”not present” Module shall be invoked.







OE.APPLET

Contributes to counter this threat by ensuring that no native ap- plets shall be loaded in post-issuance.







OT.SCP.SUPPORT

Intended to support the OT.OPERATE and OT.ALARM objectives of the TOE, thus indirectly related to the threats that these objec- tives contribute to counter.







OT.SID_MODULE

Counters this threat by providing correct identification of Modules.







5.3.1.

Denial of Service








T.RESOURCES


















Objective

Rationale







OT.OPERATE

Counters the threat by ensuring correct working order.







OT.RESOURCES

Counteres ; the threat directly by objectives on resource- management.







OT.CARD-MANAGEMENT

Counters this threat by controlling the consumption of resources during installation and other card management operations.







OT.SCP.RECOVERY

Intended to support the OT.OPERATE and OT.RESOURCESob- jectives of the TOE, thus indirectly related to the threats that these objectives contribute to counter.







OT.SCP.SUPPORT

Intended to support the OT.OPERATE and OT.RESOURCESob- jectives of the TOE, thus indirectly related to the threats that these objectives contribute to counter.







5.3.1.

Card Management








T.UNAUTHORIZED_CARD_MNGT

















Objective

Rationale







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions such as the loading, installation, extradi- tion or deletion of applets.







OT.DOMAIN-RIGHTS

Contributes to counter this threat by restricting the modification of an AP security domain keyset to the AP who owns it.







OT.COMM_AUTH

Contributes to counter this threat by preventing unauthorized users from initiating a malicious card management operation.







OT.COMM_INTEGRITY

Contributes to counter this threat by protecting the integrity of the card management data while it is in transit to the TOE.







OT.APPLI-AUTH

Counters this threat by ensuring that the loading of a package is safe.







T.COM_EXPLOIT









Objective

Rationale







OT.COMM_AUTH

Contributes to counter this threat by preventing unauthorized users from initiating a malicious card management operation.







OT.COMM_INTEGRITY

Contributes to counter this threat by protecting the integrity of the card management data while it is in transit to the TOE







OT.COMM_CONFIDENTIALITY

Contributes to counter this threat by preventing from disclosing encrypted data transiting to the TOE







T.LIFE_CYCLE









Objective

Rationale







OT.CARD-MANAGEMENT

Contributes to counter this threat by controlling the access to card management functions such as the loading, installation, extradi- tion or deletion of applets







OT.DOMAIN-RIGHTS

Contributes to counter this threat by restricting the use of an AP security domain keysets, and thus the management of the appli- cations related to this SD, to the AP who owns it







5.3.1.

Services








T.OBJ-DELETION


















Objective

Rationale







OT.OBJ-DELETION

Counters this threat by ensuring that object deletion shall not break references to objects.







5.3.1.

Miscellaneous








T.PHYSICAL


















Objective

Rationale







OT.SCP.IC

Counters phyiscal attacks. Physical protections rely on the un- derlying platform and are therefore an environmental issue.







OT.RESTRICTED-MODE

Contributes to counter the threat by ensuring that if the limit of the Attack Counter is reached only limited functionality is available.







OT.SENSITIVE_RESULTS_INTEG

If the sensitive result is supported by the TOE, this threat is partially covered by the security objective OT.SENSITIVE_RE- SULTS_INTEG which ensures that sensitive results are protected against unauthorized modification by physical attacks.














5.3.1.

Operating System

T.OS_OPERATE



Objective

Rationale

OT.OPERATE

Contributes to counter the threat by ensuring the correct continu- ation of operation of the TOE’s logical security functions. Security mechanisms have to be implemented to avoid fraudulent usage of the TOE, usage of certain memory regions, or usage of in- correct or unauthorized instructions or commands or sequence of commands. The security mechanisms must be designed to always put the TOE in a known and secure state.


5.3.1.

Random Numbers

T.RND







Objective

Rationale

OT.RND

Counters the threat by ensuring the cryptographic quality of ran- dom number generation. For instance random numbers shall not be predictable and shall have sufficient entropy. Furthermore, the TOE ensures that no information about the produced random numbers is available to an attacker.


5.3.1.1

Configuration Module

T.CONFIG






Objective

Rationale

OT.CARD-CONFIGURATION

Counters the threat by ensuring that the customer can only read and write customer configuration items using the Customer Con- Figuration Token and NXP can read and write configuration items using the NXP Configuration Token. If access is disabled config- uration items can not be read or written.


5.3.1.2

Module replacement

T.MODULE_REPLACEMENT



Objective

Rationale

OT.OPERATE

Counters the threat by ensuring correct working order.

OE.APPLET

Contributes to counter this threat by ensuring that no native ap-plets shall be loaded in post-issuance.

OT.SCP.SUPPORT

Intended to support the OT.OPERATE objective of the TOE, thusindirectly related to the threats that these objectives contribute tocounter.


OT.SID_MODULE

Counters this threat by providing correct identification of Modules.

5.3.1.1

Restricted Mode





Objective

Rationale

OT.ATTACK-COUNTER

Counters the threat by ensuring that the Attack Counter can onlybe modified according to specified rules.

OT.RESTRICTED-MODE

Counters the threat by ensuring that the Attack Counter can onlybe modified according to the specified conditions.

5.3.

Organisational Security Policies

OSP.VERIFICATION






Objective

Rationale

OE.VERIFICATION

Enforces the OSP by guaranteeing that all the bytecodes shall beverified at least once, before the loading, before the installationor before the execution in order to ensure that each bytecode isvalid at execution time.

OT.CARD-MANAGEMENT

Contributing to enforce the OSP by ensuring that the loading of apackage into the card is safe.

OE.CODE-EVIDENCE

This policy is enforced by the security objective of the environ-ment OE.CODE-EVIDENCE which ensures that evidences existthat the application code has been verified and not changed afterverification.

OT.APPLI-AUTH

Contributing to enforce the OSP by ensuring that the loading of apackage into the card is safe.

OSP.PROCESS-TOE






Objective

Rationale

OT.IDENTIFICATION

Enforces this organisational security policy by ensuring that theTOE can be uniquely identified.


OSP.KEY-CHANGE

Objective

Rationale

OE.KEY-CHANGE

Enforces the OSP by ensuring that the initial keys of the secu- rity domain are changed before any operation on them are per- formed.

OSP.SECURITY-DOMAINS

Objective

Rationale

OE.SECURITY-DOMAINS

Enforces the OSP by dynamically create, delete, and block the security domain during usage phase in post-issuance mode.

OSP.SECURE-BOX

Objective

Rationale

OT.SEC_BOX_FW

Addresses directly this organizational security policy by ensuring that the native code and data in Secure Box is separated from the rest of the TOE. Due to this separation the native code in the Secure Box cannot harm the code and data outside the Secure Box.

5.3.3 Assumptions

A.APPLET

Objective

Rationale

OE.APPLET

Upholds the assumption by ensuring that no applet loaded post- issuance shall contain native methods.

A.VERIFICATION

Objective

Rationale

OE.VERIFICATION

Upholds the assumption by guaranteeing that all the bytecodes shall be verified at least once, before the loading, before the in- stallation or before the execution in order to ensure that each bytecode is valid at execution time.

OE.CODE-EVIDENCE

This assumption is also upheld by the security objective of the en- vironment OE.CODE-EVIDENCE which ensures that evidences exist that the application code has been verified and not changed after verification.

A.USE_DIAG

Objective

Rationale

OE.USE_DIAG

Directly upholds this assumption.

A.USE_KEYS

Objective

Rationale

OE.USE_KEYS

Directly upholds this assumption.

A.PROCESS-SEC-IC

Objective

Rationale

OE.PROCESS_SEC_IC

Directly upholds this assumption.

A.APPS-PROVIDER

Objective

Rationale

OE.APPS-PROVIDER

Directly upholds this assumption.

A.VERIFICATION-AUTHORITY

Objective

Rationale

OE.VERIFICATION-AUTHORITY

Directly upholds this assumption.

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