NXP JCOP 4 Security Target Lite v3.4 9

2020-07-14 16:10:18 M&W SmartCard 96

7.2.6 CarG Security Functional Requirements

The card management SFRs from the PP [13] are refined and replaced by the following SFRs.

FDP_UIT.1[CCM] Data exchange integrity (CCM)

Hierarchical-To No other components.

Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_

ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]

FDP_UIT.1.1[CCM]	The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy and the Security Domain access control policy] to [selection: re-ceive] user data in a manner protected from [selection: modification, deletion, inser-tion and replay] errors.

FDP_UIT.1.2[CCMRefined]	The TSF shall be able to determine on receipt of user data, whether [selection:modifi-cation, deletion, insertion, replay of some of the pieces of the application sent by the CAD] has occurred.

FDP_ROL.1[CCM] Basic rollback (CCM)

Hierarchical-To No other components.

Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

FDP_ROL.1.1[CCM] The TSF shall enforce [assignment: Security Domain access control policy] to per-

mit the rollback of the [assignment: installation operation] on the [assignment:exe-

cutable files and application instances].

FDP_ROL.1.2[CCM] The TSF shall permit operations to be rolled back within the [assignment:boundaries

of available memory before the card content management function started].

FDP_ITC.2[CCM] Import of user data with security attributes (CCM)

Hierarchical-To No other components.

Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_

ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FPT_TDC.1 Inter-TSF ba-

sic TSF data consistency

FDP_ITC.2.1[CCM] The TSF shall enforce the [assignment: Security Domain access control policy and

the Secure Channel Protocol information flow policy] when importing user data, con-

trolled under the SFP, from outside of the TOE.

FDP_ITC.2.2[CCM] The TSF shall use the security attributes associated with the imported user data.

FDP_ITC.2.3[CCM] The TSF shall ensure that the protocol used provides for the unambiguous association

between the security attributes and the user data received.

FDP_ITC.2.4[CCM] The TSF shall ensure that interpretation of the security attributes of the imported user

data is as intended by the source of the user data.

FDP_ITC.2.5[CCM] The TSF shall enforce the following rules when importing user data controlled under the

SFP from outside the TOE: [assignment:

Package loading is allowed only if, for each dependent package, its AID attribute

is equal to a resident package AID attribute, the major (minor) Version attribute

associated to the dependent package is lesser than or equal to the major (minor)

Version attribute associated to the resident package ([40], §4.5.2). ]

FPT_FLS.1[CCM] Failure with preservation of secure state (CCM)

Hierarchical-To No other components.

Dependencies No dependencies.

FPT_FLS.1.1[CCM] The TSF shall preserve a secure state when the following types of failures occur: [as-

signment:the Security Domain fails to load/install an Executable File/application

instance as described in [39], Section 11.1.5]

FDP_ACC.1[SD]	Subset access control (SD)
Hierarchical-To	No other components.
Dependencies	FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1[SD]	The TSF shall enforce the [assignment: Security Domain access control policy] on:
	[assignment:
	•	Subjects: S.INSTALLER, S.ADEL, S.CAD (from [13]) and S.SD
	•	Objects: Delegation Token, DAP Block and Load File
	• Operations:GlobalPlatform’s card content management APDU commands and API methods
		]

FDP_ACF.1[SD] Security attribute based access control (SD)

Hierarchical-To No other components.

Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

FDP_ACF.1.1[SD] The TSF shall enforce the [assignment: Security Domain access control policy] to

objects based on the following: [assignment:

•Subjects:

– S.INSTALLER, defined in [13] and represented by the GlobalPlatform En-vironment

(OPEN) on the card, the Card Life Cycle attributes (defined in Section 5.1.1 of [37])

		–	S.ADEL,also defined in [13] and represented by the GlobalPlatform Envi-ronment (OPEN) on the card

		– S.SD receiving the Card Content Management commands (through AP-
			DUs or APIs) with a set of Privileges (defined in Section 6.6.1 of [37]), a Life-cycle Status (definedin Section 5.3.2 of [37]) and a Secure Commu-nication Security Level(defined in Section 10.6 of [37])
		–	S.CAD,defined in [13], the off-card entity that communicates with the S.INSTALLER and S.ADEL through S.SD

	•	Objects:
		–	The Delegation Token, in case of Delegated Management operations, with the attributes Present or Not Present

		–	The DAP Block, in case of application loading, with the attributes Present or Not Present

		–	The Load File or Executable File, in case of application loading, installa-tion, extradition or registry update, with a set of intended privileges and its targeted associated SD AID.


	•	Mapping subjects/objects to security attributes:
		–	S.INSTALLER: Security Level, Card Life Cycle, Life-cycle Status, Privi- leges, Resident Packages, Registered Applets

		–	S.ADEL: Active Applets, Static References, Card Life Cycle, Life-cycle Status, Privileges, Applet Selection Status, Security Level

		–	S.SD: Privileges, Life-cycle Status, Security Level
		–	S.CAD: Security Level]
FDP_ACF.1.2[SD]	The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: Runtime behavior rules de-fined by GlobalPlatform for:

	•	loading (Section 9.3.5 of [37])
	•	installation (Section 9.3.6 of [37])
	•	extradition (Section 9.4.1 of [37])
	•	registry update (Section 9.4.2 of [37])
	•	content removal (Section 9.5 of [37]).]
FDP_ACF.1.3[SD]	The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none].

FDP_ACF.1.4[SD]	The TSF shall explicitly deny access of subjects to objects based on the following addi-tional rules: [assignment: when at least one of the rules defined by GlobalPlatform does not hold.]

FMT_MSA.1[SD]	Management of security attributes (SD)
Hierarchical-To	No other components.
Dependencies	[FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1[SD]	The TSF shall enforce the [assignment: Security Domain access control policy] to restrict the ability to [assignment: modify] the security attributes [assignment:

	•	Card Life Cycle,
	•	Privileges,
	•	Life-cycle Status,
	•	Security Level.]
	to [assignment: the Security Domain and the application instance itself].

FMT_MSA.3[SD] Static attribute initialisation (SD)

Hierarchical-To No other components.

Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

FMT_MSA.3.1[SD] The TSF shall enforce the [assignment: Security Domain access control policy] to provide

[selection: restrictive] default values for security attributes that are used to enforce the SFP.

FMT_MSA.3.2[SD] The TSF shall allow the [assignment: Card Issuer or the Application Provider] to

specify alternative initial values to override the default values when an object or informa-

tion is created.

Refinement Alternative initial values shall be at least as restrictive as the default values defined inFMT_MSA.3.1[SD].

FMT_SMF.1[SD] Specification of Management Functions (SD)

Hierarchical-To No other components

.Dependencies No dependencies.

FMT_SMF.1.1[SD] The TSF shall be capable of performing the following management functions:[assign-ment:

•Management functions specified in GlobalPlatform specifications [GP]:

– card locking (Section 9.6.3 of [37])

– application locking and unlocking (Section 9.6.2 of [37])

– card termination (Section 9.6.4 of [37])

– card status interrogation (Section 9.6.6 of [37])

– application status interrogation (Section 9.6.5 of [37]).]

FMT_SMR.1[SD] Security roles (SD)

Hierarchical-To No other components.

Dependencies FIA_UID.1 Timing of identification

FMT_SMR.1.1[SD] The TSF shall maintain the roles [assignment: ISD, SSD].

FMT_SMR.1.2[SD] The TSF shall be able to associate users with roles.

FCO_NRO.2[SC] Enforced proof of origin (SC)

Hierarchical-To FCO_NRO.1 Selective proof of origin

.Dependencies FIA_UID.1 Timing of identification.

FCO_NRO.2.1[SC] The TSF shall enforce the generation of evidence of origin for transmitted[assignment:

Executable load files] at all times.

FCO_NRO.2.2[SC] The TSF shall be able to relate the [assignment: DAP Block] of the originator of the information,

and the [assignment: identity] of the information to which the evidence applies.

FCO_NRO.2.3[SC] The TSF shall provide a capability to verify the evidence of origin of information to [selection:

originator] given [assignment: at the time the Executable load files are received as no

evidence is kept on the card for future verification].

AppNote FCO_NRO.2.1[SC]:

•Upon reception of a new application package for installation, the card manager shall first check that it actually comes from the verification authority. The verification authority is the entity responsible for bytecode verification.

FCO_NRO.2.3[SC]:

•The exact limitations on the evidence of origin are implementation dependent. In most of the implementations, the card manager performs an immediate verification of the origin of the package using an electronic signature mechanism, and no evidence is kept on the card for future verifications.

FDP_IFC.2[SC]	Complete information flow control (SC)
Hierarchical-To	FDP_IFC.1 Subset information flow control
Dependencies	FDP_IFF.1 Simple security attributes
FDP_IFC.2.1[SC]	The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] on [assignment:

	•	the subjects S.CAD and S.SD, involved in the exchange of messages between the TOE and the CAD through a potentially unsafe communication channel,

	•	the information controlled by this policy are the card content management commands, including personalization commands, in the APDUs sent to the card and their associated responses returned to the CAD]

	and all operations that cause that information to flow to and from subjects covered by the SFP.
FDP_IFC.2.2[SC]	The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP.

FDP_IFF.1[SC] Simple security attributes (SC)

Hierarchical-To No other components.

Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation

FDP_IFF.1.1[SC] The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy]

based on the following types of subject and information security attributes:[assignment:

•Subjects:

– S.SD receiving the Card Content Management commands (through APDUs or APIs).

– S.CAD the off-card entity that communicates with the S.SD.

•Information:

– executable load file, in case of application loading;

– applications or SD privileges, in case of application installation or registry update;

– personalization keys and/or certificates, in case of application or SD personalization.]

FDP_IFF.1.2[SC] The TSF shall permit an information flow between a controlled subject and controlled

information via a controlled operation if the following rules hold: [assignment:

•Runtime behavior rules defined by GlobalPlatform for:

	– loading (Section 9.3.5 of [37]);
	– installation (Section 9.3.6 of [37]);
	– extradition (Section 9.4.1 of [37]);
	– registry update (Section 9.4.2 of [37]);
	– content removal (Section 9.5 of [37]).]

FDP_IFF.1.3[SC]	The TSF shall enforce the [assignment: no additional information flow control SFP rules].

FDP_IFF.1.4[SC]	The TSF shall explicitly authorise an information flow based on the following rules: [assignment: none].

FDP_IFF.1.5[SC]	The TSF shall explicitly deny an information flow based on the following rules: [assignment:

	•	When none of the conditions listed in the element FDP_IFF.1.4 of this component hold and at least one of those listed in the element FDP_IFF.1.2 does not hold.]

AppNote	The subject S.SD can be the ISD or APSD.
AppNote	The on-card and the off-card subjects have security attributes such as MAC, Cryptogram, Challenge, Key Set, Static Keys, etc.

FMT_MSA.1[SC]	Management of security attributes (SC)
Hierarchical-To	No other components.
Dependencies	[FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1[SC]	The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] to restrict the ability to [selection: modify] the security attributes [assignment:

	•	Key Set,
	•	Security Level,
	•	Secure Channel Protocol,
	•	Session Keys,
	•	Sequence Counter,
	•	ICV.
	to [assignment: the actor associated with the according security domain:
	•	The Card Issuer for ISD,
	•	The Application Provider for APSD.]

FMT_MSA.3[SC]	Static attribute initialisation (SC)
Hierarchical-To	No other components.
Dependencies	FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles
FMT_MSA.3.1[SC]	The TSF shall enforce the [assignment: Secure Channel Protocol information flow control policy] to provide[selection: restrictive] default values for security attributes that are used to enforce the SFP.

FMT_MSA.3.2[SC]	The TSF shall allow the [assignment: Card Issuer, Application Provider] to specify alternative initial values to override the default values when an object or information is created.

FMT_SMF.1[SC]	Specification of Management Functions (SC)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FMT_SMF.1.1[SC]	The TSF shall be capable of performing the following management functions: [assignment:

	• Management functions specified in GlobalPlatform specifications [GP]:
	–	loading (Section 9.3.5 of [37])
	–	installation (Section 9.3.6 of [37])
	–	extradition (Section 9.4.1 of [37])
	–	registry update (Section 9.4.2 of [37])
	–	content removal (Section 9.5 of [37]).]
AppNote	All management functions related to secure channel protocols shall be relevant.

FIA_UID.1[SC] Timing of identification (SC)

Hierarchical-To No other components.

Dependencies No dependencies.

FIA_UID.1.1[SC] The TSF shall allow [assignment:

•application selection

•initializing a secure channel with the card

•requesting data that identifies the card or the Card Issuer]

on behalf of the user to be performed before the user is identified.

FIA_UID.1.2[SC] The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.

FIA_UAU.1[SC] Timing of authentication (SC)

Hierarchical-To No other components.

Dependencies FIA_UID.1 Timing of identification

FIA_UAU.1.1[SC] The TSF shall allow [assignment: the TSF mediated actions listed in FIA_UID.1[SC]]

on behalf of the user to be performed before the user is authenticated.

FIA_UAU.1.2[SC] The TSF shall require each user to be successfully authenticated before allowing any

other TSF-mediated actions on behalf of that user.

FIA_UAU.4[SC] Single-use authentication mechanisms

Hierarchical-To No other components.

Dependencies No dependencies.

FIA_UAU.4.1[SC] The TSF shall prevent reuse of authentication data related to [assignment:the authen-

tication mechanism used to open a secure communication channel with the card.]

FTP_ITC.1[SC] Inter-TSF trusted channel (SC)

Hierarchical-To No other components.

Dependencies No dependencies.

FTP_ITC.1.1[SC] The TSF shall provide a communication channel between itself and another trusted IT

that is logically distinct from other communication channels and provides assured identifi-

cation of its end points and protection of the channel data from modification or disclosure.

FTP_ITC.1.2[SCRefined] The TSF shall permit the CAD placed in the card issuer secured environment to

initiate communication via the trusted channel.

FTP_ITC.1.3[SC] The TSF shall initiate communication via the trusted channel for [assignment:all card

management functions:

•loading

•installation

•extradition

•registry update

•content removal

•changing the Application Life Cycle or Card Life Cycle.]

7.2.7 EMG Security Functional Requirements

The list of SFRs of this category are taken from the PP [13].

This functionality is not available in Configuration Secure Authentication, hence the SFRs are not applicable to this configuration.

FDP_ACC.1[EXT-MEM] Subset access control (EXT-MEM)

Hierarchical-To No other components.

Dependencies FDP_ACF.1 Security attribute based access control

FDP_ACC.1.1[EXT-MEM] The TSF shall enforce the [assignment: EXTERNAL MEMORY access control SFP] on

[assignment:subject S.APPLET, object O.EXT_MEM_INSTANCE, and operations

OP.CREATE_EXT_MEM_INSTANCE, OP.READ_EXT_MEM and OP.WRITE_EXT_MEM].

FDP_ACF.1[EXT-MEM]	Security attribute based access control (EXT-MEM)
Hierarchical-To	No other components.
Dependencies	FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1[EXT-MEM]	The TSF shall enforce the [assignment:EXTERNAL MEMORY access control SFP] to objects based on the following:[assignment:

	Object	Security attribute	]
	O.EXT_MEM_INSTANCE	Address Space.
FDP_ACF.1.2[EXT-MEM]	The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment:

	•R.JAVA.20:Any subject S.APPLET that performs OP.CREATE_EXT_MEM_INSTANCE obtains an object O.EXT_MEM_INSTANCEthat addresses a memory space differ-ent from that of the Java Card System.
	• R.JAVA.21: Any subject S.APPLET may perform OP.READ_EXT_MEM (O.EXT_MEM_INSTANCE, address) provided the address belongs to the space of the O.EXT_MEM_INSTANCE.
	• R.JAVA.22: Any subject S.APPLET may perform OP.WRITE_EXT_MEM (O.EXT_MEM_INSTANCE, address) provided the address belongs to the space of the O.EXT_MEM_INSTANCE.
	]
FDP_ACF.1.3[EXT-MEM]	The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none].
FDP_ACF.1.4[EXT-MEM]	The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: none].
AppNote	The actual mechanism for creating an instance of external memory is implementation dependent. This rule only states that the accessible address space must not interfere with that of the Java Card System. The creation and the access to an external memory instance fall in the scope of the Firewall rules.

FMT_MSA.1[EXT-MEM]	Management of security attributes (EXT-MEM)
Hierarchical-To	No other components.
Dependencies	[FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1[EXT-MEM]	The TSF shall enforce the [assignment: EXTERNAL MEMORY access control SFP] to restrict the ability to [assignment: set up] the security attributes [assignment: Address Space]to[assignment: S.JCRE].

FMT_MSA.3[EXT-MEM]	Static attribute initialisation (EXT-MEM)
Hierarchical-To	No other components.
Dependencies	FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles
FMT_MSA.3.1[EXT-MEM]	The TSF shall enforce the [assignment: EXTERNAL MEMORY access control SFP] to provide [assignment: no] default values for security attributes that are used to enforce the SFP.

FMT_MSA.3.2[EXT-MEM]	The TSF shall allow the [assignment: S.JCRE] to specify alternative initial values to override the default values when an object or information is created.
AppNote	Upon creation of an external memory instance, the Java Card RE gets the address space mvalue for the newly created object. This is implementation-dependent.

FMT_SMF.1[EXT-MEM]	Specification of Management Functions (EXT-MEM)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FMT_SMF.1.1[EXT-MEM]	The TSF shall be capable of performing the following management functions: [assignment: set up the Address Space security attribute].

7.2.8 ConfG Security Functional Requirements

The list of SFRs of this category define additional requirements related to the configuration of the TOE.

FDP_IFC.2[CFG] &nbnbsp; Complete information flow control (CFG)

Hierarchical-To FDP_IFC.1 Subset information flow control

Dependencies FDP_IFF.1 Simple security attributes

FDP_IFC.2.1[CFG] The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP] on

[assignment: S.Customer, S.NXP, S.ConfigurationMechanism, and D.CONFIG_ITEM]

and all operations that cause that information to flow to and from subjects covered by the SFP.

FDP_IFC.2.2[CFG] The TSF shall ensure that all operations that cause any information in the TOE to flow to

and from any subject in the TOE are covered by an information flow control SFP.

FDP_IFF.1[CFG] Simple security attributes (CFG)

Hierarchical-To No other components.

Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation

FDP_IFF.1.1[CFG] The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP]

based on the following types of subject and information security attributes: [assignment:

	Subject/Information	Security attributes
	S.Customer	Customer Configuration Token
	S.NXP	NXP Configuration Token
	S.ConfigurationMechanism	NXP Configuration Access, Customer Configuration
		Access
	D.CONFIG_ITEM	Access privilege

FDP_IFF.1.2[CFG] The TSF shall permit an information flow between a controlled subject and controlled

information via a controlled operation if the following rules hold: [assignment:

•Read and write operations of D.CONFIG_ITEM between S.ConfigurationMechanism and S.NXP shall only be possible when S.NXP is authenticated with its token using the NXP Configuration Token.

•Read and write operations of D.CONFIG_ITEM between S.ConfigurationMechanism mand S.Customershall only be possible when S.Customer is authenticated with its token using the Customer Configuration Token and if access privilege allowsit.

•Enabling or disabling of NXP Configuration Accessbetween S.ConfigurationMechanism

and S.NXP shall only be possible when S.NXP is authenticated with its token

using the NXP Configuration Token.

FDP_IFF.1.3[CFG]The TSF shall enforce the additional information flow control SFP rules [assignment: none].

FDP_IFF.1.4[CFG] The TSF shall explicitly authorise an information flow based on the following rules [as-signment: none].

FDP_IFF.1.5[CFG] The TSF shall explicitly deny an information flow based on the following rules [assign-ment:

•If the NXP Configuration Access is disabled then nobody can read or write D.CONFIG_ITEM.

•If the Customer Configuration Accessis disabled then S.Customercan not read or write D.CONFIG_ITEM.

FMT_MSA.3[CFG] Static attribute initialisation (CFG)

Hierarchical-To No other components.

Dependencies	FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles
FMT_MSA.3.1[CFG]	The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP] to provide [selection:restrictive] default values for security attributes that are used to enforce the SFP.

FMT_MSA.3.2[CFG]	The TSF shall allow the [assignment: nobody] to specify alternative initial values to override the default values when an object or information is created.
FMT_MSA.1[CFG]	Management of security attributes (CFG)
Hierarchical-To	No other components.
Dependencies	[FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1[CFG]	The TSF shall enforce the [assignment: CONFIGURATION information flow control SFP] to restrict the ability to[selection: modify] the security attributes [assignment: NXP Configuration Access and Customer Configuration Access]to[assignment: none].

FMT_SMR.1[CFG]	Security roles (CFG)
Hierarchical-To	No other components.
Dependencies	FIA_UID.1 Timing of identification
FMT_SMR.1.1[CFG]	The TSF shall maintain the roles [assignment: S.NXP and S.Customer].
FMT_SMR.1.2[CFG]	The TSF shall be able to associate users with roles.
AppNote	The roles of the CONFIGURATION information flow control SFP are defined by the NXP Configuration Token and the Customer Configuration Token.
FMT_SMF.1[CFG]	Specification of Management Functions (CFG)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FMT_SMF.1.1[CFG]	The TSF shall be capable of performing the following management functions: [assignment: none.]
FIA_UID.1[CFG]	Timing of identification (CFG)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FIA_UID.1.1[CFG]	The TSF shall allow [assignment: to select the ISD] on behalf of the user to be performed before the user is identified.
FIA_UID.1.2[CFG]	The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.

7.2.9 SecBoxG Security Functional Requirements

The SFRs in this section provide additional requirements to separate the native code executed in the Secure Box environment from the rest of the TOE.

FDP_ACC.2[SecureBox] Complete access control (SecureBox)

Hierarchical-To FDP_ACC.1 Subset access control

Dependencies FDP_ACF.1 Security attribute based access control

FDP_ACC.2.1[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP]on [assignment:

S.SBNativeCode, O.SB_Content, O.NON_SB_Content, O.SB_SFR, O.NON_

SB_SFR]and all operations among subjects and objects covered by the SFP.

FDP_ACC.2.2[SecureBox] The TSF shall ensure that all operations between any subject controlled by the TSF and

any object controlled by the TSF are covered by an access control SFP.

Refinement The operations involved in this policy are:

• OP.SB_ACCESS,

• OP.SB_ACCESS_SFR.

FDP_ACF.1[SecureBox] Security attribute based access control (SecureBox)

Hierarchical-To No other components.

Dependencies FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

FDP_ACF.1.1[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP]to all objects

based on the following: [assignment: S.SBNativeCode, O.SB_Content, O.NON_SB_

Content, O.SB_SFR, O.NON_SB_SFR andthe attributes CPU Mode,the MMU Seg-

Ment Table andthe Special Function Registersrelatedto system management].

FDP_ACF.1.2[SecureBox] The TSF shall enforce the following rules to determine if an operation among controlled

subjects and controlled objects is allowed: [assignment:

	•	Code assigned to S.SBNativeCode is only executed in CPU ModeUser Mode.
	•	Code assigned to S.SBNativeCode is only able to perform OP.SB_ACCESSto O.SB_Content.The ROM, FLASH, and RAM which belongs to O.SB_Content is controlled by the MMU Segment Table used by the Memory Management Unit.

	•	Code assigned to S.SBNativeCode is able to perform OP.SB_ACCESS_SFRto O.SB_SFR.
	].
FDP_ACF.1.3[SecureBox]	The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: none]
FDP_ACF.1.4[SecureBox]	The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment:
	•	For S.SBNative Code it is not possible to perform OP.SB_ACCESS to O.NON_ SB_Content.

•For S.SBNative Code it is not possible to perform OP.SB_ACCESS_SFR to O.NON_SB_SFR.

FMT_MSA.1[SecureBox] Management of security attributes (SecureBox)

Hierarchical-To No other components.

Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_

SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1[SecureBox] The TSF shall enforce the [assignment: SecureBox access control SFP]to restrict the

ability to [selection: modify] the security attributes [assignment: CPU Modeand the

MMU Segment Table]to[assignment: S.JCRE].

AppNote The dependency with FMT_SMR.1 is not applicable. Only S.JCRE is allowed to modify

security attributes for the Secure Box before S.SBNativeCode is executed.

FMT_MSA.3[SecureBox] Static attribute initialisation (SecureBox)

Hierarchical-To No other components.

Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

FMT_MSA.3.1[SecureBox]	The TSF shall enforce the [assignment: SecureBox access control SFP]to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP.

FMT_MSA.3.2[SecureBox]	The TSF shall allow the [assignment: S.JCRE] to specify alternative initial values to override the default values when an object or information is created.

AppNote	The dependency with FMT_SMR.1 is not applicable. The TOE does not allow to specify alternative initial values for the security attributes of the Secure Box.

FMT_SMF.1[SecureBox]	Specification of Management Functions (SecureBox)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FMT_SMF.1.1[SecureBox]	The TSF shall be capable of performing the following management functions: [assignment:

	•	Switch the CPU Mode
	•	Change the values in the MMU Segment Table to assign RAM to the Secure Box
	•	Change the values in the MMU Segment Table to assign FLASH to the Secure Box

7.2.10 ModDesG Security Functional Requirements

The list of SFRs of this category define additional requirements related to the Modular Design of the TOE.

FDP_IFC.1[MODULAR-DESIGN] Subset information flow control (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies FDP_IFF.1 Simple security attributes

FDP_IFC.1.1[MODULAR-DESIGN] The TSF shall enforce the [assignment: modular design information flow con-trol SFP] on [assignment: S.APPLET, S.SD, S.JCRE, I.MODULE_INVOCATION and OP.INVOKE_MODULE].

FDP_IFF.1[MODULAR-DESIGN] Simple security attributes (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies FDP_IFC.1 Subset information flow control, FMT_MSA.3 Static attribute initialisation

FDP_IFF.1.1[MODULAR-DESIGN] The TSF shall enforce the [assignment: modular design information flow control SFP] based on the following types of subject and information security attributes: [as-signment: S.APPLET, S.SD, S.JCRE and I.MODULE_INVOCATIONwith the security attribute Module Presence of the invoked O.CODE_MODULE]

FDP_IFF.1.2[MODULAR-DESIGN] The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment:Operation

OP.INVOKE_MODULE isallowed for S.APPLET, S.SDand S.JCRE on I.MODULE_ INVOCATION ifthe security attribute Module Presence ofthe invoked O.CODE_ MODULE hasthe value ”present”].

FDP_IFF.1.3[MODULAR-DESIGN] The TSF shall enforce the additional information flow control SFP rules [assignment:none].FDP_IFF.1.4[MODULAR-DESIGN] The TSF shall explicitly authorise an information flow based on the following rules

[assignment:none].

FDP_IFF.1.5[MODULAR-DESIGN] The TSF shall explicitly deny an information flow based on the following rules [as-

signment: prevent access to O.CODE_MODULEif the security attribute Module Presence hasthe value ”not present”].

FIA_ATD.1[MODULAR-DESIGN] User attribute definition (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies No dependencies.

FIA_ATD.1.1[MODULAR-DESIGN] The TSF shall maintain the following list of security attributes belonging to individual users: [assignment:

• Module Presence,

• Package AID

Refinement ”Individual users” stands for Modules.

FIA_USB.1[MODULAR-DESIGN] User-subject binding (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies FIA_ATD.1 User attribute definition

FIA_USB.1.1[MODULAR-DESIGN]		The TSF shall associate the following user security attributes with subjects acting on
	the behalf of that user: [assignment: Package AID].
FIA_USB.1.2[MODULAR-DESIGN]		The TSF shall enforce the following rules on the initial association of user security
	attributes with subjects acting on the behalf of users: [assignment:Each Module is
	associated with an unique Package AID].
FIA_USB.1.3[MODULAR-DESIGN]		The TSF shall enforce the following rules governing changes to the user security at-
	tributes associated with subjects acting on the behalf of users: [assignment:The Pack-
	Age AIDofa Module is unchangeable].
AppNote	The user is a Module and the subjects are the S.APPLET, S.SD and S.JCRE.

FMT_MSA.1[MODULAR-DESIGN] Management of security attributes (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control], FMT_

SMR.1 Security roles, FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1[MODULAR-DESIGN] The TSF shall enforce the [assignment: ADEL access control SFP and modular design information flow control SFP] to restrict the ability to [selection:modify] thesecurity attributes [assignment: Module Presence of O.CODE_MODULE] to [assign-ment: S.ADEL].

FMT_MSA.3[MODULAR-DESIGN] Static attribute initialisation (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies FMT_MSA.1 Management of security attributes, FMT_SMR.1 Security roles

FMT_MSA.3.1[MODULAR-DESIGN] The TSF shall enforce the [assignment: modular design information flow control SFP] to provide [selection: restrictive] default values for security attributes that are usedto enforce the SFP.

FMT_MSA.3.2[MODULAR-DESIGN] The TSF shall allow [assignment: none] to specify alternative initial values to over-ride the default values when an object or information is created.

Hierarchical-To	No other components.
Dependencies	No dependencies.

FMT_SMF.1.1[MODULAR-DESIGN] The TSF shall be capable of performing the following management functions: [as-

signment:modify the list of Resident Modules].

FMT_SMR.1[MODULAR-DESIGN] Security roles (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies FIA_UID.1 Timing of identification

FMT_SMR.1.1[MODULAR-DESIGN] The TSF shall maintain the roles: [assignment: Module Invoker]. FMT_SMR.1.2[MODULAR-DESIGN] The TSF shall be able to associate users with roles.

FPT_FLS.1[MODULAR-DESIGN] Failure with preservation of secure state (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies No dependencies.FPT_FLS.1.1[MODULAR-DESIGN] The TSF shall preserve a secure state when the following types of failures occur:

[assignment: OP.INVOKE_MODULE is performed on a TOE internal interface of O.CODE_MODULE wherethe security attribute Module Presence hasthe value ”not

present”].

AppNote A secure state is being preserved by throwing an exception or sending an error status word to the CAD.

FIA_UID.1[MODULAR-DESIGN] Timing of identification (MODULAR-DESIGN)

Hierarchical-To No other components.

Dependencies No dependencies.FIA_UID.1.1[MODULAR-DESIGN] The TSF shall allow [assignment:

•direct invokation of Modules with public interface and the security attribute Module Presence havingthe value ’present’,

•invokation of Modules via JavaCard API with TOE internal interface and the security attribute Module Presence having the value ’present’

] on behalf of the user to be performed before the user is identified.

FIA_UID.1.2[MODULAR-DESIGN] The TSF shall require each user to be successfully identified before allowing any other

TSF-mediated actions on behalf of that user.

7.2.11 RMG Security Functional Requirements

The list of SFRs of this category define additional requirements related to restriction of TOE functionality when the attack counter expired.

FDP_ACC.2[RM] Complete access control (Restricted Mode)

Hierarchical-To FDP_ACC.1 Subset access control

Dependencies FDP_ACF.1 Security attribute based access control

FDP_ACC.2.1[RM] The TSF shall enforce the [assignment: Restricted Mode access control SFP] on

[assignment: S.SD] and all operations among subjects and objects covered by the SFP

FDP_ACC.2.2[RM] The TSF shall ensure that all operations between any subject controlled by the TSF and

any object controlled by the TSF are covered by an access control SFP.

FDP_ACF.1[RM]	Security attribute based access control (Restricted Mode)
Hierarchical-To	No other components.
Dependencies	FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1[RM]	The TSF shall enforce the [assignment:Restricted Mode access control SFP] to objects based on the following [assignment:
	Subject/Object	Security attributes	]
	S.SD	D.ATTACK_COUNTER

FDP_ACF.1.2[RM]	The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: The D.ATTACK_COUNTER can be reset by ISD].

FDP_ACF.1.3[RM]	The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment:none].
FDP_ACF.1.4[RM]	The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: Deny all operations on all objects if the D.ATTACK_COUNTERhasreached its limit (restricted mode), except for operations listed in FMT_SMF.1[RM]].

FMT_MSA.3[RM]	Static attribute initialisation (Restricted Mode)
Hierarchical-To	No other components.
Dependencies	FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles
FMT_MSA.3.1[RM]	The TSF shall enforce the [assignment: Restricted Mode access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP.

FMT_MSA.3.2[RM]	The TSF shall allow the [assignment: nobody] to specify alternative initial values to override the default values when an object or information is created.

FMT_MSA.1[RM] Management of security attributes (Restricted Mode)

Hierarchical-To No other components.

Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_

SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1[RM] The TSF shall enforce the [assignment: Restricted Mode access control policy] to re-

strict the ability to [selection: modify] the security attributes [assignment: D.ATTACK_

COUNTER]to[assignment: ISD].

FMT_SMF.1[RM]	Specification of Management Functions (Restricted Mode)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FMT_SMF.1.1[RM]	The TSF shall be capable of performing the following management functions: [assignment:

	•	select ISD,
	•	authenticate against the ISD,
	•	initialize a Secure Channel with the ISD,
	• reset D.ATTACK_COUNTER,
	•	identify the card,
	• read CPLC data,
	•	query the debug logging information.
FIA_UID.1[RM]	Timing of identification (RM)
Hierarchical-To	No other components.
Dependencies	No dependencies.
FIA_UID.1.1[RM]	The TSF shall allow [assignment:
	•	select ISD,
	•	identify the card,
	•	query the debug logging information.
	] on behalf of the user to be performed before the user is identified.
FIA_UID.1.2[RM]	The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user.
FIA_UAU.1[RM]	Timing of authentication (RM)
Hierarchical-To	No other components.
Dependencies	FIA_UID.1 Timing of identification
FIA_UAU.1.1[RM]	The TSF shall allow [assignment:
	•	select ISD,
	•	identify the card,
	•	query the debug logging information.
	] on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2[RM]	The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.

7.2.12 Further Security Functional Requirements

The SFRs in this section provide additional proprietary features not covered by the PP [13].

FAU_SAS.1[SCP] Audit Data Storage (SCP)

Hierarchical-To	No other components.
Dependencies	No other components.
FAU_SAS.1.1[SCP]	The TSF shall provide [assignment: test personnel before TOE Delivery] with the capability to store the [assignment: Initialisation Data and/or Prepersonalisation Data and/or supplements of the Smartcard Embedded Software] in the [assignment: audit records].

FCS_RNG.	Quality metric for random numbers
Hierarchical-To	No other components.
Dependencies	No dependencies
FCS_RNG.1.1	The TSF shall provide a [selection: deterministic] random number generator that implements [assignment:

	• (DRG.3.1) If initialized with a random seed using a PTRNG of class PTG.2 (as defined in [41]) as random source, the internal state of the RNG shall have at least 256 bit of entropy.
	•	(DRG.3.2) The RNG provides forward secrecy (as defined in [41]).
	•	(DRG.3.3) The RNG provides enhanced backward secrecy even if the current inter-
		nal state is known (as defined in [41])
	]
FCS_RNG.1.2	The TSF shall provide [selection: octets of bits] that meet [assignment:
	• (DRG.3.4) The RNG, initialized with a random seed using a PTRNG of class PTG.2 (as defined in [41]) as random source, generates output for which for AES-mode 2⁴⁸ and for TDEA-mode 2³⁵ strings of bit length 128 are mutually different with probability at least 1 2 ²⁴.
	•	(DRG.3.5) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A (as defined in [41])


	]
AppNote	This functionality is provided by the certified Crypto Lib, see [20]
FCS_RNG.1[HDT]	Quality metric for random numbers
Hierarchical-To	No other components.
Dependencies	No dependencies
FCS_RNG.1.1[HDT]	The TSF shall provide a [selection: hybrid deterministic] random number generator that implements [assignment:

	• (DRG.4.1) The internal state of the RNG shall use PTRNG of class PTG.2 (as defined in [41]) as random source.
	•	(DRG.4.2)The RNG provides forward secrecy (as defined in [41]).
	•	(DRG.4.3) The RNG provides backward secrecy even if the current internal state is known (as defined in [41]).
	• (DRG.4.4) The RNG provides enhanced forward secrecy on demand (as defined in [41]).
	• (DRG.4.5) The internal state of the RNG is seeded by an PTRNG of class PTG.2 (as defined in [41]).
	]
FCS_RNG.1.2[HDT]	The TSF shall provide [selection: random numbers] that meet [assignment:
	• (DRG.4.6) The RNG generates output for which for AES-mode 2⁴⁸ and for TDEAmode 2³⁵ strings of bit length 128 are mutually different with probability at least 1 2 ²⁴.
	•	(DRG.4.7) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test pro- cedure A (as defined in [41]).


	]
AppNote	This functionality is provided by the certified Crypto Lib, see [20]
FIA_AFL.1[PIN]	Basic Authentication Failure Handling (PIN)
Hierarchical-To	No other components.
Dependencies	FIA_UAU.1 Timing of authentication.
FIA_AFL.1.1[PIN]	The TSF shall detect when [selection: an administrator configurable positive integer within [1 and 127]] unsuccessful authentication attempts occur related to [assignment: any user authentication using D.PIN].

FIA_AFL.1.2[PIN]	When the defined number of unsuccessful authentication attempts has been[selection: surpassed], the TSF shall [assignment:block the authentication with D.PIN].

AppNote		The dependency with FIA_UAU.1 is not applicable. The TOE implements the firewall access control SFP, based on which access to the object implementing FIA_AFL.1[PIN] is organized.

FPT_EMSEC.		TOE emanation
Hierarchical-To		No other components.
Dependencies		No dependencies.
FPT_EMSEC.1.1		The TOE shall not emit [assignment: variations in power consumption or timing during command execution] in excess of[assignment: non-useful information] enabling access to [assignment: TSF data: D.CRYPTO] and [assignment:User data: D.PIN, D.APP_KEYs].

FPT_EMSEC.1.2		The TSF shall ensure [assignment: that unauthorized users] are unable to use the following interface [assignment: electrical contacts or Radio Frequency (RF) field] to gain access to [assignment: TSF data: D.CRYPTO] and [assignment:User data: D.PIN, D.APP_KEYs].

FPT_PHP.		Resistance to physical attack
Hierarchical-To		No other components.
Dependencies		No dependencies.
FPT_PHP.3.1		The TSF shall resist [assignment: physical manipulation and physical probing] to the [assignment: TSF] by responding automatically such that the SFRs are always enforced.

Refinement		The TSF will implement appropriate mechanisms to continuously counter physical manipulation and physical probing. Due to the nature of these attacks (especially manipulation) the TSF can by no means detect attacks on all of its elements. Therefore, permanent protection against these attacks is required ensuring that security functional requirements are enforced. Hence, ”automatic response” means here (i) assuming that there might be an attack at any time and (ii) countermeasures are provided at any time.

AppNote		This SFR is taken from the certified Security IC Platform Protection Profile [24].
FCS_CKM.		Cryptographic key distribution
Hierarchical-To		No other components.
Dependencies	[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of userdata with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4Cryptographic key destruction

FCS_CKM.2.1	The TSF shall distribute cryptographic keys in accordance with a specified cryptographickey distribution method [assignment: methods: set keys and components of DES, AES, RSA, RSA-CRT, ECC and secure messaging] that meets the following: [assignment: [38], [14], [15]].

AppNote	• The keys can be accessed as specified in [38] Key class and [14], [15] for proprietary classes.
	•	This component shall be instantiated according to the version of the Java Card API applying to the security target and the implemented algorithms [38] and [14], [15] for proprietary classes.

AppNote	•	FCS_CKM.2 for ECC keys is applicable only if the corresponding Module for the cryptographic operation is present in the TOE.

FCS_CKM.	Cryptographic key access
Hierarchical-To	No other components.
Dependencies	[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of userdata with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4Cryptographic key destruction

FCS_CKM.3.1	The TSF shall perform [assignment:management of DES, AES, RSA, RSA-CRT, ECC, Diffie-Hellman and EC Diffie-Hellman] in accordance with a specified cryptographic key access method [assignment: methods/commands defined in packages javacard.security of [38] and [14], [15] for proprietary classes] that meets the following: [assignment: [38], [14], [15]].

AppNote	• The keys can be accessed as specified in [38] Key class and [14], [15] for proprietary classes.
	•	This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemented algorithms ([38]) and [14], [15] for proprietary classes.

AppNote	•	FCS_CKM.3 for ECC keys is applicable only if the corresponding Module for the cryptographic operation is present in the TOE.

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 9

Service & News

Java Cards

NXP JCOP 4 Security Target Lite v3.4 9

Service & News

Recommended content