NXP JCOP 4 Security Target Lite v3.4 6

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

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.

Java Cards

NXP JCOP 4 Security Target Lite v3.4 6

Service & News

Java Cards

NXP JCOP 4 Security Target Lite v3.4 6

Service & News

Recommended content