NXP JCOP 4 Security Target Lite v3.4 8
7.2 Security Functional Requirements
This section defines the security functional requirements for the TOE. The permitted operations (assignment, iteration, selection and refinement) of the SFRs taken from Common Criteria [3] are printed in bold. Completed operations related to the PP [13] are additionally marked within [ ] where assignments are marked with the keyword "assignment".
7.2.1 COREG_LC Security Functional Requirements
The list of SFRs of this category are taken from the PP [13].
7.2.1.1 Firewall Policy
FDP_ACC.2[FIREWALL] Complete access control (FIREWALL)
Hierarchical-To FDP_ACC.1 Subset access controlDependencies FDP_ACF.1 Security attribute based access controlFDP_ACC.2.1[FIREWALL] The TSF shall enforce the [assignment: FIREWALL access control SFP]on [assign-
ment: S.PACKAGE, S.JCRE, S.JCVM, O.JAVAOBJECT] and all operations among sub-
jects and objects covered by the SFP.
Refinement: The operations involved in the policy are:
• OP.CREATE(Sharing, LifeTime)(*),
• OP.INVK_INTERFACE(O.JAVAOBJECT, method, arg1, ...),
• OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...),
• OP.JAVA(...),
• OP.TYPE_ACCESS(O.JAVAOBJECT, class),
• OP.ARRAY_LENGTH(O.JAVAOBJECT, field),
• OP.ARRAY_AASTORE(O.JAVAOBJECT, field).FDP_ACC.2.2[FIREWALL] 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.AppNote It should be noticed that accessing array’s components of a static array, and more gener-
ally fields and methods of static objects, is an access to the corresponding O.JAVAOBJECT.
– OP.ARRAY_ACCESS
– OP.INSTANCE_FIELD
– OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...)
– OP.INVK_INTERFACE(O.JAVAOBJECT, method, arg1, ...)
upon any O.JAVAOBJECTwhose Sharing attribute has value ”Standard” and whose
LifeTime attribute has value ”PERSISTENT” only if O.JAVAOBJECT’s Contextat-
tribute has the same value as the active context.
•R.JAVA.3 ([39], §6.2.8.10): S.PACKAGE may perform
– OP.TYPE_ACCESS(O.JAVAOBJECT, class)
upon an O.JAVAOBJECTwhose Sharing attribute has value ”SIO” only if O.JAVAOBJECT
FDP_ACF.1[FIREWALL] | Security attribute based access control (FIREWALL) | ||
Hierarchical-To | No other components. | ||
Dependencies | FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation | ||
FDP_ACF.1.1[FIREWALL] | The TSF shall enforce the [assignment:FIREWALL access control SFP] to objects based on the following [assignment: | ||
Subject/Object | Security attributes | ||
S.PACKAGE | |||
S.JCVM | |||
S.JCRE | |||
O.JAVAOBJECT | |||
FDP_ACF.1.2[FIREWALL] | The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: | ||
• | R.JAVA.1 ([39], §6.2.8): S.PACKAGE may freely perform | ||
upon any O.JAVAOBJECT whose Sharing attribute has value ”JCRE entry point” or ”global array”. | |||
• | R.JAVA.2 ([39], §6.2.8): S.PACKAGE may freely perform | ||
is being cast into (checkcast) or is being verified as being an instance of (instanceof) an interface that extends the Shareable interface.
•R.JAVA.4 ([39], §6.2.8.6): S.PACKAGE may perform
– OP.INVK_INTERFACE(O.JAVAOBJECT, method, arg1, ...)
upon an O.JAVAOBJECTwhose Sharing attribute has the value ”SIO”, and whose Context attribute has the value ”Package AID”, only if the invoked interface methodextends the Shareable interface and one of the following conditions applies:
a) The value of the attribute LC Selection Status of the package whose AID is”Package AID” is ”Multiselectable”,
b) The value of the attribute LC Selection Status of the package whose AID is”Package AID” is ”Non-multiselectable”, and either ”Package AID” is the value of the currently selected applet or otherwise ”Package AID” does not occur in the attribute Active Applets.
•R.JAVA.5: S.PACKAGEmay perform
– OP.CREATE(Sharing, LifeTime)(*)
upon O.JAVAOBJECTonly if the value of the Sharing parameter is ”Standard” or ”SIO”.
•R.JAVA.6 ([39], §6.2.8.10): S.PACKAGE may freely perform
– OP.ARRAY_ACCESS(O.JAVAOBJECT, field)
– OP.ARRAY_LENGTH(O.JAVAOBJECT, field)
upon any O.JAVAOBJECTwhose Sharing attribute has value ”global array”.FDP_ACF.1.3[FIREWALL] The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment:
•The subject S.JCRE can freely perform OP.JAVA(...)and OP.CREATE(Sharing, Life- Time)(*), with the exception given in FDP_ACF.1.4[FIREWALL], provided it is the Currently Active Context.
•The only means that the subject S.JCVM shall provide for an application to execute native code is the invocation of a Java Card API method (through
– OP.INVK_INTERFACE(O.JAVAOBJECT, method, arg1, ...)
– OP.INVK_VIRTUAL(O.JAVAOBJECT, method, arg1, ...)) ]
FDP_ACF.1.4[FIREWALL] The TSF shall explicitly deny access of subjects to objects based on the following addi-tional rules: [assignment:
•Any subject with OP.JAVA(...)upon an O.JAVAOBJECTwhose LifeTimeattribute has value ”CLEAR_ON_DESELECT” if O.JAVAOBJECT’s Context attribute is not the same as the Selected Applet Context.
•Any subject attempting to create an object by the means of OP.CREATE(Sharing, LifeTime)(*) and a ”CLEAR_ON_DESELECT” LifeTime parameter if the active con-text is not the same as the Selected Applet Context.
• S.PACKAGE performing OP.ARRAY_AASTORE(O.JAVAOBJECT, field)of the ref-erence of an O.JAVAOBJECT whose Sharing attribute has value ”global array” or ”Temporary JCRE entry point”.
• S.PACKAGE performing OP.PUTFIELD or OP.PUTSTATIC of the reference of an O.JAVAOBJECT whose Sharing ttribute has value ”global array” or ”Temporary JCRE entry point”. ]
AppNote FDP_ACF.1.4[FIREWALL]
•The deletion of applets may render some O.JAVAOBJECT inaccessible, and the Java Card RE may be in charge of his aspect. This can be done, for instance, by ensuring that references to objects belonging to a deleted application are onsid-ered as a null reference.
In the case of an array type, fields are components of the array ([26], §2.14, §2.7.7), as well as the length; the only methods of an array object are those inherited from the Object class.
The Sharing attribute defines four categories of objects:
•Standard ones, whose both fields and methods are under the firewall policy,
•Shareable interface Objects (SIO), which provide a secure mechanism for inter-applet communication,
•JCRE entry points (Temporary or Permanent), who have freely accessible methods but protected fields,
•Global arrays, having both unprotected fields (including components; refer to JavaC-ardClass discussion above) and methods.
When a new object is created, it is associated with the Currently Active Context. But the object is owned by the applet instance within the Currently Active Context when the object is instantiated ([39], §6.1.3). An object is owned by an applet instance, by the JCRE or by the package library where it has been defined (these latter objects can only be arrays that initialize static fields of packages).
([39], Glossary) Selected Applet Context. The Java Card RE keeps track of the currently selected Java Card applet. Upon receiving a SELECT command with this applet’s AID, the Java Card RE makes this applet the Selected Applet Context. The Java Card RE sends all APDU commands to the Selected Applet Context.
While the expression ”Selected Applet Context” refers to a specific installed applet, the relevant aspect to the policy is the context (package AID) of the selected applet. In this policy, the ”Selected Applet Context” is the AID of the selected package.
([39], §6.1.2.1) At any point in time, there is only one active context within the Java Card VM (this is called the Currently Active Context).
It should be noticed that the invocation of static methods (or access to a static field) is not considered by this policy, as there are no firewall rules. They have no effect on the active context as well and the ”acting package” is not the one to which the static method belongs to in this case.
It should be noticed that the Java Card platform, version 2.2.x and version 3 Classic Edition, introduces the possibility for an applet instance to be selected on multiple logical channels at the same time, or accepting other applets belonging to the same package being selected simultaneously. These applets are referred to as multiselectable applets. Applets that belong to a same package are either all multiselectable or not ([40], §2.2.5). Therefore, the selection mode can be regarded as an attribute of packages. No selection mode is defined for a library package.
An applet instance will be considered an active applet instance if it is currently selected in at least one logical channel. An applet instance is the currently selected applet instance only if it is processing the current command. There can only be one currently selected applet instance at a given time. ([39], §4).
FDP_IFC.1[JCVM] Subset information flow control (JCVM)
Hierarchical-To No other components.Dependencies FDP_IFF.1 Simple security attributesFDP_IFC.1.1[JCVM] The TSF shall enforce the [assignment: JCVM information flow control SFP] on [as-
signment: S.JCVM, S.LOCAL, S.MEMBER, I.DATA and OP.PUT(S1,S2,I)].
AppNote | It should be noticed that references of temporary Java Card RE entry points, which cannot be stored in class variables, instance variables or array components, are transferred from the internal memory of the Java Card RE (TSF data) to some stack through specific APIs (Java Card RE owned exceptions) or Java Card RE invoked methods (such as the process(APDU apdu)); these are causes of OP.PUT(S1,S2,I) operations as well. | |||
FDP_IFF.1[JCVM] | Simple security attributes (JCVM) | |||
Hierarchical-To | No other components. | |||
Dependencies | FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation | |||
FDP_IFF.1.1[JCVM] | The TSF shall enforce the [assignment:JCVM information flow control SFP] based on the following types of subject and information security attributes [assignment: : | |||
Subject/Object | Security attributes | ] | ||
S.JCVM | ||||
FDP_IFF.1.2[JCVM] | The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: | |||
• | An operation OP.PUT(S1, S.MEMBER, I.DATA) is allowed if and only if the Cur- rently Active Context is ”Java Card RE”. | |||
• | other OP.PUToperations are allowed regardless of the Currently Active Con-text’s value.] | |||
FDP_IFF.1.3[JCVM] | The TSF shall enforce [assignment: no additional information flow control SFP rules]. | |||
FDP_IFF.1.4[JCVM] | The TSF shall explicitly authorise an information flow based on the following rules: [as-signment: none]. | |||
FDP_IFF.1.5[JCVM] | The TSF shall explicitly deny an information flow based on the following rules: [assign-ment: none]. | |||
AppNote | The storage of temporary Java Card RE-owned objects references is runtime-enforced ([39], §6.2.8.1-3). It should be noticed that this policy essentially applies to the execution of bytecode. Na-tive methods, the Java Card RE itself and possibly some API methods can be grantedspecific rights or limitations through the FDP_IFF.1.3[JCVM]to FDP_IFF.1.5[JCVM]ele-ments. The way the Java Card virtual machine manages the transfer of values on thestack and local variables (returned values, uncaught exceptions) from and to internal reg-isters is implementation dependent. For instance, a returned reference, depending onthe implementation of the stack frame, may transit through an internal register prior tobeing pushed on the stack of the invoker. The returned bytecode would cause more thanone OP.PUT operation under this scheme. | |||
Subset residual information protection (OBJECTS) | |
Hierarchical-To | No other components. |
Dependencies | No dependencies. |
FDP_RIP.1.1[OBJECTS] | The TSF shall ensure that any previous information content of a resource is made un- available upon the [selection: allocation of the resource to] the following objects: [as- signment: class instances and arrays]. |
AppNote | The semantics of the Java programming language requires for any object field and array position to be initialized with default values when the resource is allocated [26], §2.5.1. |
FMT_MSA.1[JCRE] | Management of security attributes (JCRE) |
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[JCRE] | The TSF shall enforce the [assignment: FIREWALL access control SFP]to restrict the ability to [selection: modify] the security attributes [assignment: Selected Applet |
AppNote | The modification of the Selected Applet Context should be performed in accordance with the rules given in [39], §4 and [40], §3.4. |
FMT_MSA.1[JCVM] | Management of security attributes (JCVM) |
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[JCVM] | The TSF shall enforce the [assignment: FIREWALL access control SFP and the JCVM information flow control SFP] to restrict the ability to [selection: modify] the security attributes [assignment: Currently Active Context and Active Applets] to [as- signment: S.JCVM]. |
AppNote | The modification of the Currently Active Context should be performed in accordance with the rules given in [39], §4 and [40], §3.4. |
FMT_MSA.2[FIREWALL-JCVM] Secure security attributes (FIREWALL-JCVM)
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.2.1[FIREWALL-JCVM] The TSF shall ensure that only secure values are accepted for [assignment:all the security attributes of subjects and objects defined in the FIREWALL access control SFP and the JCVM information flow control SFP].
AppNote The following rules are given as examples only. For instance, the last two rules are
motivated by the fact that the Java Card API defines only transient arrays factory methods.
Future versions may allow the creation of transient objects belonging to arbitrary classes;
such evolution will naturally change the range of ”secure values” for this component.
•The Context attribute of an O.JAVAOBJECT must correspond to that of an installed applet or be ”Java Card RE”.
•An O.JAVAOBJECT whose Sharing attribute is a Java Card RE entry point or a global array necessarily has ”Java Card RE” as the value for its Context security attribute.
•An O.JAVAOBJECT whose Sharing attribute value is a global array necessarily has
”array of primitive type” as a JavaCardClass security attribute’s value.
•Any O.JAVAOBJECT whose Sharing attribute value is not ”Standard” has a PERSISTENT-
LifeTime attribute’s value.
•Any O.JAVAOBJECT whose LifeTime attribute value is not PERSISTENT has an
array type as JavaCardClass attribute’s value.
FMT_MSA.3[FIREWALL] Static attribute initialisation (FIREWALL)
Hierarchical-To No other components.
Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles
FMT_MSA.3.1[FIREWALL] The TSF shall enforce the [assignment: FIREWALL access control SFP]to provide
[selection:restrictive] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2[FIREWALL] The TSF shall not allow the [assignment: none] to specify alternative initial values to
override the default values when an object or information is created.
AppNote FMT_MSA.3.1[FIREWALL]
•Objects’ security attributes of the access control policy are created and initialized at the creation of the object or the subject. Afterwards, these attributes are no longer mutable (FMT_MSA.1[JCRE]). At the creation of an object (OP.CREATE), the newly created object, assuming that the FIREWALL access control SFP permits the operation, gets its Lifetime and Sharing attributes from the parameters of the operation; on the contrary, its Context attribute has a default value, which is its creator’s Context attribute and AID respectively ([39], §6.1.3). There is one default value for the Selected Applet Context that is the default applet identifier’s Context, and one default value for the Currently Active Context that is ”Java Card RE”.
•The knowledge of which reference corresponds to a temporary entry point object or a global array and which does not is solely available to the Java Card RE (and the Java Card virtual machine).
•The intent is that none of the identified roles has privileges with regard to the default values of the security attributes. It should be noticed that creation of objects is an operation controlled by the FIREWALL access control SFP. The operation shall fail anyway if the created object would have had security attributes whose value violates FMT_MSA.2.1[FIREWALL-JCVM].
FMT_MSA.3[JCVM] Static attribute initialisation (JCVM)
Hierarchical-To No other components.
Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles
FMT_MSA.3.1[JCVM] The TSF shall enforce the [assignment: JCVM information flow control SFP] to pro-vide
[selection: restrictive] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2[JCVM] The TSF shall not allow the [assignment: none] to specify alternative initial values to
override the default values when an object or information is created.
FMT_SMF. Specification of Management Functions
Hierarchical-To No other components
.Dependencies No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:[assign-ment:
•modify the Currently Active Context, the Selected Applet Context and the Ac- Tive Applets
FMT_SMR. | Security roles | |
Hierarchical-To | No other components. | |
Dependencies | FIA_UID.1 Timing of identification | |
FMT_SMR.1.1 | The TSF shall maintain the roles: [assignment: | |
• | Java Card RE (JCRE), | |
• | Java Card VM (JCVM). ]. | |
FMT_SMR.1.2 | The TSF shall be able to associate users with roles. | |
7.2.1.2 Application Programming Interface
The following SFRs are related to the Java Card API.
The whole set of cryptographic algorithms is generally not implemented because of limited memory resources and/or limitations due to exportation. Therefore, the following requirements only apply to the implemented subset.
It should be noticed that the execution of the additional native code is not within the TSF. Nevertheless, access to API native methods from the Java Card System is controlled by TSF because there is no difference between native and interpreted methods in their interface or invocation mechanism.
FCS_CKM. Cryptographic key generation
Hierarchical-To No other components.
Dependencies [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm [assignment: JCOP RNG] and specified cryptographic key
sizes[assignment: DES: 112, 168 bit AES: 128, 192, 256 bit RSA: 512, 736, 768, 896,
1024, 1280, 1536, 1984, 2048, 4096 bit and from 2000 bit to 4096 bit in one bit steps
ECC:160, 192, 224, 256, 384, 512, 521 bit] that meet the following: [assignment: [1]].
FCS_CKM.1.1[PUF] The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm [assignment: key derivation function based on PUF] and
specified cryptographic key sizes [assignment:128 bits] that meet the following: [as-signment: [22]].
AppNote | • | The keys can be generated and diversified in accordance with [38] specification inclasses KeyPair (at least Session key generation) and RandomData. |
• | This component shall be instantiated according to the version of the Java Card APIapplying to the security target and the implemented algorithms ([38]). | |
Remark: This application note doesn’t apply to FCS_CKM.1.1[PUF]. | ||
AppNote | • FCS_CKM.1for RSA or ECC keys is applicable only if the corresponding Modulefor the cryptographic operation is present in the TOE. | |
FCS_CKM. | Cryptographic key destruction | |
Hierarchical-To | No other components. | |
Dependencies | [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] | |
FCS_CKM.4.1 | The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: physically overwriting the keys in a random-ized manner] that meets the following: [assignment: none]. | |
FCS_CKM.4.1[PUF] | The TSF shall destroy cryptographic keys derived by PUF block in accordance with a specified cryptographic key destruction method [assignment: flushing of key regis-ters] that meets the following:[assignment: none]. | |
AppNote | • | The keys are reset as specified in [38] Key class, with the method clearKey(). Anyaccess to a cleared key for ciphering or signing shall throw an exception. |
• | This component shall be instantiated according to the version of the Java Card APIapplicable to the security target and the implemented algorithms ([38]). | |
Remark: This application note doesn’t apply to FCS_CKM.4.1[PUF]. | ||
AppNote | • | FCS_CKM.4 for ECC keys is applicable only if the corresponding Module for thecryptographic operation is present in the TOE. |
Following iterations of FCS_COP.1 use constants as defined in Java Card API Spec [38] and in JCOPX [14], [15] where appropriate.
FCS_COP. Cryptographic operation
Hierarchical-To No other components.
Dependencies [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user
data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4
Cryptographic key destruction.
FCS_COP.1.1[PUF_AES] | The TSF shall perform [assignment: decryption and encryption] in accordance with a specified cryptographic algorithm [assignment: AES in CBC mode]and cryptographic key size [assignment: 128 bits] that meets the following: [assignment:FIPS 197 [7], NIST Special Publication 800-38A Recommendation for BlockCipher [16]]. |
FCS_COP.1.1[PUF_MAC] | The TSF shall perform [assignment: CBC-MAC used for calculation of a PUF authen- tication] in accordance with a specified cryptographic algorithm [assignment: AES in CBC-MAC] and cryptographic key size[assignment: 128 bit] that meet the following:[assignment: FIPS 197 [7], NIST Special Publication 800-38A Recommendation for BlockCipher [16] and ISO/IEC 9797-1:1999 Information technology Security tech- niques Message Authentication Codes (MACs) Part 1: Mechanisms using a block cipher [12]]. |
FCS_COP.1.1[TripleDES] | The TSF shall perform [assignment: data encryption and decryption]in accordance with a specified cryptographic algorithm [assignment:ALG_DES_CBC_ISO9797_M1, ALG_DES_ CBC_ISO9797_M2, ALG_DES_CBC_NOPAD, ALG_DES_ECB_ISO9797_M1, ALG_DES_ECB_ISO9797_M2, ALG_DES_ECB_NOPAD] and cryptographic key sizes [assignment: LENGTH_DES3_2KEY, LENGTH_DES3_3KEY bit] that meet the following: [assignment: Java Card API Spec [38]]. |
FCS_COP.1.1[AES] | The TSF shall perform [assignment: data encryption and decryption]in accordance with a specified cryptographic algorithm [assignment:ALG_AES_BLOCK_128_CBC_ NOPAD, ALG_AES_BLOCK_128_CBC_NOPAD_STANDARD, ALG_AES_BLOCK_128_ECB_NOPAD, ALG_AES_CBC_ISO9797_M1, ALG_AES_CBC_ISO9797_M2, ALG_AES_CBC_ISO9797_M2_STANDARD, ALG_AES_ECB_ISO9797_M1, ALG_AES_ECB_ISO9797_M2, ALG_AES_CTR] and cryptographic key sizes [assignment: LENGTH_ AES_128, LENGTH_AES_192 and LENGTH_AES_256 bit] that meet the following:[assignment: Java Card API Spec [38] and API specified in JCOPX [14], [15]]. |
FCS_COP.1.1[RSACipher] | The TSF shall perform [assignment: data encryption and decryption]in accordance with a specified cryptographic algorithm [assignment: ALG_RSA_NOPAD, ALG_RSA_ PKCS1, ALG_RSA_PKCS1_OAEP] and cryptographic key sizes [assignment: LENGTH_ RSA_2048, LENGTH_RSA_4096 and from 2000 bit to 4096 bit in one bit steps] that meet the following: [assignment: Java Card API Spec [38] and for the one bit step range see API specified in JCOPX [14], [15]]. |
FCS_COP.1.1 [ECDHPACEKeyAgreement] | The TSF shall perform [assignment: ECDH PACE key agreement] in ac-cordance with a specified cryptographic algorithm [assignment: Generic Mapping, In-tegrated Mapping] and cryptographic key sizes [assignment:LENGTH_EC_FP_160, LENGTH_EC_FP_192, LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_EC_FP_320, LENGTH_EC_FP_384, LENGTH_EC_FP_521 and from 160 bit to 521 bit in 1 bit steps] that meet the following: [assignment: ICAO SAC [9] and JCOPX [14], [15]]. |
FCS_COP.1.1[PIV] | The TSF shall perform [assignment: key establishment protocol for the PIV Card Application] in accordance with a specified cryptographic algorithm[assignment: One-Pass Diffie-Hellman, C(1e, 1s, ECC CDH) Scheme from [SP800-56A] [17] in a man-ner that is based on a simplified profile of OPACITY with Zero Key Management [ANSI504-1]] and cryptographic key sizes [assignment:LENGTH_EC_FP_160, LENGTH_EC_FP_192, LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_EC_FP_320, LENGTH_EC_FP_384, LENGTH_EC_FP_521 and from 160 bit to 521 bit in 1 bit steps] that meet the following: [assignment: NIST Special Publication 800-73-4[18] and JCOPX [14], [15]]. |
The TSF shall perform [assignment: Diffie-Hellman Key Agreement]in accordance with a specified cryptographic algorithm [assignment: ALG_EC_SVDP_DH, ALG_EC_SVDP_DH_KDF, ALG_EC_SVDP_DH_PLAIN, ALG_EC_SVDP_DHC, ALG_EC_SVDP_DHC_KDF, ALG_EC_SVDP_DHC_PLAIN, ALG_EC_SVDP_DH_PLAIN_XY] and cryp-tographic key sizes [assignment: LENGTH_EC_FP_160, LENGTH_EC_FP_192, LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_EC_FP_320, LENGTH_EC_FP_384, LENGTH_EC_FP_521 and from 160 bit to 521 bit in 1 bit steps] that meet the following: [assign-ment: Java Card API Spec [38]] and JCOPX API [14], [15]]. | |
FCS_COP.1.1[DESMAC] | The TSF shall perform [assignment: MAC generation and verification]in accordance with a specified cryptographic algorithm [assignment: Triple-DES in outer CBC for Mode ALG_DES_MAC4_ISO9797_1_M1_ALG3, ALG_DES_MAC4_ISO9797_1_M2_ALG3,ALG_DES_MAC4_ISO9797_M1, ALG_DES_MAC4_ISO9797_M2, ALG_DES_MAC8_ISO9797_1_M1_ALG3, ALG_DES_MAC8_ISO9797_1_M2_ALG3, ALG_DES_MAC8_ISO9797_M1, ALG_DES_MAC8_ISO9797_M2, ALG_DES_MAC8_NOPAD] and cryp-tographic key sizes [assignment: LENGTH_DES3_2KEY, LENGTH_DES3_3KEY]that meet the following: [assignment: Java Card API Spec [38]]. |
FCS_COP.1.1[AESMAC] | The TSF shall perform [assignment: 16 byte MAC generation and verification] in accordance with a specified cryptographic algorithm [assignment: AES in CBC ModeALG_AES_MAC_128_NOPAD, ALG_AES_MAC_128_ISO9797_1_M2_ALG3] and cryp-tographic key sizes [assignment: LENGTH_AES_128, LENGTH_AES_192 and LENGTH_AES_256 bit] that meet the following: [assignment: Java Card API Spec [38]]. |
FCS_COP.1.1 [RSASignaturePKCS1] | The TSF shall perform [assignment: digital signature generation and verifica-tion] in accordance with a specified cryptographic algorithm [assignment:ALG_RSA_SHA_224_PKCS1, ALG_RSA_SHA_224_PKCS1_PSS, ALG_RSA_SHA_256_PKCS1, ALG_RSA_SHA_256_PKCS1_PSS, ALG_RSA_SHA_384_PKCS1, ALG_RSA_SHA_384_PKCS1_PSS, ALG_RSA_SHA_512_PKCS1, ALG_RSA_SHA_512_PKCS1_PSS,ALG_RSA_SHA_ISO9796, ALG_RSA_SHA_256_ISO9796 or SIG_CIPHER_RSA in combination with MessageDigest.ALG_SHA_256, MessageDigest.ALG_SHA_384, MessageDigest.ALG_SHA_512 and in combination with Cipher.PAD_PKCS1_OAEP] and cryptographic key sizes [assignment: LENGTH_RSA_2048, LENGTH_RSA_4096 and from 2000 bit to 4096 bit in one bit steps] that meet the following: [assignment: Java Card API Spec [38] and for the one bit step range see API specified in JCOPX [14], [15]]. |
FCS_COP.1.1[ECSignature] | The TSF shall perform [assignment: digital signature generation and verification] in accordance with a specified cryptographic algorithm [assignment:ALG_ECDSA_SHA_224, ALG_ECDSA_SHA_256, ALG_ECDSA_SHA_384, ALG_ECDSA_SHA_512 or SIG_CIPHER_ECDSA in combination with MessageDigest.ALG_SHA_224, MessageDi-gest.ALG_SHA_256, MessageDigest.ALG_SHA_384 or MessageDigest.ALG_SHA_512] and cryptographic key sizes [assignment:LENGTH_EC_FP_160, LENGTH_EC_FP_192, LENGTH_EC_FP_224, LENGTH_EC_FP_256, LENGTH_EC_FP_320, LENGTH_EC_FP_384, LENGTH_EC_FP_521 and from 160 bit to 521 bit in 1 bit steps] that meet the following: [assignment: Java Card API Spec [38]and JCOPX API [14], [15]]. |
FCS_COP.1.1[ECAdd] The TSF shall perform [assignment: secure point addition] in accordance with a speci-
fied cryptographic algorithm [assignment: ECC over GF(p)] and cryptographic key sizes
[assignment:LENGTH_EC_FP_160, LENGTH_EC_FP_192, LENGTH_EC_FP_224,
LENGTH_EC_FP_256, LENGTH_EC_FP_320, LENGTH_EC_FP_384, LENGTH_EC_
FP_521 and and from 160 bit to 521 bit in 1 bit steps] that meet the following: [as-
signment:ISO/IEC 14888-3, Annex C [11]].
FCS_COP.1.1[SHA] The TSF shall perform [assignment: secure hash computation] in accordance with a specified
cryptographic algorithm [assignment: ALG_SHA3, ALG_SHA_224, ALG_SHA_256,
ALG_SHA_512] and cryptographic key sizes [assignment: ALG_SHA_384, LENGTH_SHA_224,
LENGTH_SHA_256, LENGTH_SHA_384, LENGTH_SHA_512] that meet the following:
[assignment: Java Card API Spec [38] and JCOPX [14], [15]].
FCS_COP.1.1[AES_CMAC] The TSF shall perform [assignment: CMAC generation and verification]in accor-dance with
a specified cryptographic algorithm [assignment: ALG_AES_CMAC8, ALG_AES_CMAC16,
ALG_AES_CMAC16_STANDARD, ALG_AES_CMAC_128] and cryp-tographic key sizes
[assignment: LENGTH_AES_128, LENGTH_AES_192 and LENGTH_the following:
[assignment: see Java Card API Spec [38] and JCOPX [14], [15]].
FCS_COP.1.1[DAP] The TSF shall perform [assignment: verification of the DAP signature attached to
Executable Load Applications] in accordance with a specified cryptographic algorithm
[assignment:ALG_ECDSA_SHA_256 and ALG_RSA_SHA_PKCS1] and cryptographic
key sizes [assignment: LENGTH_EC_FP_256 and LENGTH_RSA_1024 respectively]
that meet the following: [assignment: GP Spec [34]].
AppNote FCS_COP.1.1[ECDHPACEKeyAgreement], FCS_COP.1.1[PIV], FCS_COP.1.1[ECDH_P1363],
FCS_COP.1.1[ECSignature], FCS_COP.1.1[ECAdd] or FCS_COP.1.1[DAP] (for ECC) are applicable
only if the corresponding Module for the cryptographic operation is present in the TOE.
AppNote For resistance against attackers with High Attack Potential, the user should always refer to
the guidance given by the Certification Body in the juristiction. The website www.keylength.com
provides a good reference to recommended keylengths.
3Due to mathematical weakness only resistant against AVA_VAN.5 for temporary data (e.g. as used for generating session keys), but not if repeatedly applied to the same input data.
FDP_RIP.1[ABORT] Subset residual information protection (ABORT)
Hierarchical-To | No other components. |
Dependencies | No dependencies. |
FDP_RIP.1.1[ABORT] | The TSF shall ensure that any previous information content of a resource is made un-available upon the [selection: deallocation of the resource from]the following objects: [assignment: any reference to an object instance created during an aborted trans- action]. |
AppNote | The events that provoke the de-allocation of a transient object are described in [39], §5.1. |
FDP_RIP.1[APDU] Subset residual information protection (APDU)
Hierarchical-To No other components.
Dependencies No dependencies
.FDP_RIP.1.1[APDU] The TSF shall ensure that any previous information content of a resource is made un-
available upon the [selection: allocation of the resource to] the following objects: [as-
signment:the APDU buffer].
AppNote The allocation of a resource to the APDU buffer is typically performed as the result of a
call to the process() method of an applet.
FDP_RIP.1[GlobalArray_Refined] Subset residual information protection (Global Array)
Hierarchical-To No other components.
Dependencies No dependencies.
FDP_RIP.1.1[GlobalArray_Refined] The TSF shall ensure that any previous information content of a resource is made unavailable upon [selection: deallocation of the resource from] the applet as a result of returning from the process method to the following objects: [assignment: a user Global Array]
.AppNote An array resource is allocated when a call to the API method JCSystem.makeGlobalArray is performed.
The Global Array is created as a transient JCRE Entry Point Object ensur-ing that reference to it cannot
be retained by any application. On return from the method which called JCSystem.makeGlobalArray,
the array is no longer available to any applet and is deleted and the memory in use by the array is cleared
and reclaimed in the next object deletion cycle.
FDP_RIP.1[bArray] | Subset residual information protection (bArray) |
Hierarchical-To | No other components. |
Dependencies | No dependencies. |
FDP_RIP.1.1[bArray] | The TSF shall ensure that any previous information content of a resource is made un-available upon the [selection: deallocation of the resource from]the following objects:[assignment: the bArray object]. |
AppNote | A resource is allocated to the bArray object when a call to an applet’s install() method is performed. There is no conflict with FDP_ROL.1 here because of the bounds on the roll-back mechanism (FDP_ROL.1.2[FIREWALL]): the scope of the rollback does not extend outside the execution of the install() method, and the de-allocation occurs precisely right after the return of it. |
FDP_RIP.1[KEYS] | Subset residual information protection (KEYS) |
Hierarchical-To | No other components. |
Dependencies | No dependencies. |
FDP_RIP.1.1[KEYS] | The TSF shall ensure that any previous information content of a resource is made un-available upon the [selection: deallocation of the resource from]the following objects: [assignment: the cryptographic buffer (D.CRYPTO)]. |
AppNote | • The javacard.security and javacardx.crypto packages do provide secure interfaces to the cryptographic buffer in a transparent way. See javacard.security.KeyBuilder and Key interface of [38]. |
FDP_RIP.1[TRANSIENT] | Subset residual information protection (TRANSIENT) |
Hierarchical-To | No other components. |
Dependencies | No dependencies. |
FDP_RIP.1.1[TRANSIENT] | The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: deallocation of the resource from]the following objects: [assignment: any transient object]. |
AppNote | • The events that provoke the de-allocation of any transient object are described in [39], §5.1. |
• The clearing of CLEAR_ON_DESELECT objects is not necessarily performed when the owner of the objects is deselected. In the presence of multiselectable applet instances, CLEAR_ON_DESELECT memory segments may be attached to applets that are active in different logical channels. Multiselectable applet instances within a same package must share the transient memory segment if they are concurrently active ([39], §4.2.) |
FDP_ROL.1[FIREWALL] Basic rollback (FIREWALL)
Hierarchical-To No other components.
Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]
FDP_ROL.1.1[FIREWALL] The TSF shall enforce [assignment: the FIREWALL access control SFP and the JCVM
information flow control SFP] to permit the rollback of the [assignment: op-erations
OP.JAVA(...)and OP.CREATE(Sharing, LifeTime)(*)] on the [assignment:
object O.JAVAOBJECT.
FDP_ROL.1.2[FIREWALL] The TSF shall permit operations to be rolled back within the [assignment:scope of a select(),
deselect(), process(), install() or uninstall() call, notwithstanding the re-strictions
given in [39], §7.7, within the bounds of the Commit Capacity ([39], §7.8),and those
described in [38]].
AppNote Transactions are a service offered by the APIs to applets. It is also used by some APIs to guarantee
the atomicity of some operation. This mechanism is either implemented in Java Card platform or
relies on the transaction mechanism offered by the underlying platform. Some operations of the API
are not conditionally updated, as documented in [38] (see for instance, PIN-blocking, PIN-checking,
update of Transient objects).
7.2.1.3 Card Security Management
FAU_ARP. | Security alarms | |
Hierarchical-To | No other components. | |
Dependencies | FAU_SAA.1 Potential violation analysis | |
FAU_ARP.1.1 | The TSF shall take [assignment: one of the following actions: | |
• | throw an exception, | |
• | lock the card session, | |
• | reinitialize the Java Card System and its data, | |
• | [assignment: response with error code to S.CAD] | |
] upon detection of a potential security violation. | ||
Refinement | The ”potential security violation” stands for one of the following events: | |
•CAP: CAP file inconsistency (response with error code to S.CAD),
•typing error in the operands of a bytecode (only possible in BCV),
•LFC: applet life cycle inconsistency (throw an exception),
•CHP: card tearing (unexpected removal of the Card out of the CAD) and power failure (reinitialize the Java Card System),
•ABT: abort of a transaction in an unexpected context (throw an exception),
•FWL: violation of the Firewall or JCVM SFPs (throw an exception),
•RSC: unavailability of resources (throw an exception),
•OFL: array overflow (throw an exception),
•assignment:
– EDC: checksum mismatch of EDC arrays (throw an exception),
– MOD: functionality of a not present Module is invoked (throw an exception, response with error code to S.CAD),
– SRE: violation of Sensitive Result integrity errors (throw an exception),
– CHP: Abnormal environmental condition (Frequency, Voltage, Temperature)
(reinitialize the Java Card System),
– Physical Tampering
CLC: Card Manager Life Cycle inconsistency (throw an exception),
CHP: General Fault Injection Detection (reinitialize the Java Card Sys-tem)
– CHP: FLASH defects (reinitialize the Java Card System),
– CHP: Integrity protected persistent data inconsistency (reinitialize the Java Card System),
– CHP: Integrity protected transient data inconsistency (reinitialize the Java Card System),
– Memory Access Violation
CHP: Others (reinitialize the Java Card System)
AppNote • The developer shall provide the exhaustive list of actual potential security violations
the TOE reacts to. For instance, other runtime errors related to applet’s failure like
uncaught exceptions.
•The bytecode verification defines a large set of rules used to detect a ”potential security violation”. The actual monitoring of these ”events” within the TOE only makes sense when the bytecode verification is performed on-card.
•Depending on the context of use and the required security level, there are cases, where the card manager and the TOE must work in cooperation to detect and appropriately react in case of potential security violation. This behavior must be described in this component. It shall detail the nature of the feedback informa-tion provided to the card manager (like the identity of the offending application) and the conditions under which the feedback will occur (any occurrence of the java.lang.SecurityException exception).
•The ”resetting of the card session” may not appear in the policy of the card man-ager. Such measure should only be taken in case of severe violation detection; the same holds for the re-initialization of the Java Card System. Moreover, the resetting should occur when ”clean” re-initialization seems to be impossible.
•The resetting may be implemented at the level of the Java Card System as a denial of service (through some systematic ”fatal error” message or return value) that lasts up to the next ”RESET” event, without affecting other components of the card (such as the card manager). Finally, because the installation of applets is a sensitive
process, security alerts in this case should also be carefully considered herein.
AppNote • The action ”reinitialize the Java Card System and its data” is supported by the TOE.
The Java Card System is reinitialized by performing a reset. Additionally the in-ternal Attack Counter may be updated before the reset depending on the detected abnormal event.
•The action ”lock the card session” which is assigned in the PP [13] is not supported by the TOE. Instead the action ”reinitialize the Java Card System and its data” is executed which is a more strict reaction.
•No particular action is taken for the potential security violation ”card tearing” since this is a normal operating condition.
FDP_SDI.2[DATA] Stored data integrity monitoring and action
Hierarchical-To FDP_SDI.1 Stored data integrity monitoring
Dependencies No dependencies
.FDP_SDI.2.1[DATA] The TSF shall monitor user data stored in containers controlled by the TSF for [assign-
ment:integrity errors] on all objects, based on the following attributes: [assignment:
integrity protected data].
FDP_SDI.2.2[DATA] Upon detection of a data integrity error, the TSF shall [assignment:perform the action
defined in FAU_ARP.1].RefinementThe following data elements have the user data attribute ”integrity protected data”:
• | D.APP_KEYs | |
• | D.PIN | |
AppNote | • | Although no such requirement is mandatory in the Java Card specification, at least an exception shall be raised upon integrity errors detection on cryptographic keys, PIN values and their associated security attributes. Even if all the objects cannot be monitored, cryptographic keys and PIN objects shall be considered with particular attention by ST authors as they play a key role in the overall security. |
•It is also recommended to monitor integrity errors in the code of the native applica-tions and Java Card applets.
•For integrity sensitive application, their data shall be monitored (D.APP_I_DATA): applications may need to protect information against unexpected modifications, and explicitly control whether a piece of information has been changed between two accesses. For example, maintaining the integrity of an electronic purse’s balance is extremely important because this value represents real money. Its modification must be controlled, for illegal ones would denote an important failure of the payment system.
•A dedicated library could be implemented and made available to developers to achieve better security for specific objects, following the same pattern that already exists in cryptographic APIs, for instance.
FDP_SDI.2[SENSITIVE_RESULT] Stored data integrity monitoring and action (Sensitive Result)
Hierarchical-To FDP_SDI.1 Stored data integrity monitoring
Dependencies No dependencies.
FDP_SDI.2.1[SENSITIVE_RESULT] The TSF shall monitor user data stored in containers controlled by the TSF for [as-signment:integrity errors] on all objects, based on the following attributes:[assign-ment: sensitive API result stored in the com.nxp.id.jcopx.security.SensitiveResultX class].
FDP_SDI.2.2[SENSITIVE_RESULT] Upon detection of a data integrity error, the TSF shall [assignment: throw an ex-ception].
FPR_UNO. Unobservability
Hierarchical-To No other components.
Dependencies No dependencies
.FPR_UNO.1.1 The TSF shall ensure that [assignment: all users] are unable to observe the operation
[assignment:all operations] on [assignment: D.APP_KEYs, D.PIN, D.Crypto] by
[assignment:another user].
AppNote | Although it is not required in [39] specifications, the non-observability of operations on sensitive information such as keys appears as impossible to circumvent in the smart card world. The precise list of operations and objects is left unspecified, but should at least concern secret keys and PIN codes when they exists on the card, as well as the cryptographic operations and comparisons performed on them. | |
FPT_FLS. | Failure with preservation of secure state | |
Hierarchical-To | No other components. | |
Dependencies | No dependencies. | |
FPT_FLS.1.1 | The TSF shall preserve a secure state when the following types of failures occur: [as- signment: those associated to the potential security violations described in FAU_ ARP.1]. | |
AppNote | The Java Card RE Context is the Current context when the Java Card VM begins running after a card reset ([39], §6.2.3) or after a proximity card (PICC) activation sequence ([39]). Behavior of the TOE on power loss and reset is described in [39], §3.6 and §7.1. Behavior of the TOE on RF signal loss is described in [39], §3.6.1. | |
FPT_TDC. | Inter-TSF basic TSF data consistency | |
Hierarchical-To | No other components. | |
Dependencies | No dependencies. | |
FPT_TDC.1.1 | The TSF shall provide the capability to consistently interpret [assignment:the CAP files, the bytecode and its data arguments] when shared between the TSF and another trusted IT product. | |
FPT_TDC.1.2 | The TSF shall use [assignment: | |
• | the rules defined in [40] specification, | |
• | the API tokens defined in the export files of reference implementation, | |
• | [assignment: | |
– the ISO 7816-6 rules, | ||
– the EMV specification ] | ||
] when interpreting the TSF data from another trusted IT product. | ||
AppNote | Concerning the interpretation of data between the TOE and the underlying Java Card platform, it is assumed that the TOE is developed consistently with the Smart Card Plat- form. It is comprised of the integrated circuit, the operating system and the dedicated software of the smart card (SCP) functions, including memory management, I/O func-tions and cryptographic functions. | |
7.2.1.4 AID Management | ||
FIA_ATD.1[AID] | User attribute definition (AID) | |
Hierarchical-To | No other components. | |
Dependencies | No dependencies. | |
FIA_ATD.1.1[AID] | The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: | |
• | ||
• | ||
• | ||
• | Applet Selection Status ([39], §4.6) | |
]. | ||
Refinement | ”Individual users” stands for applets. | |
FIA_UID.2[AID] | User identification before any action (AID) | |
Hierarchical-To | FIA_UID.1 Timing of identification | |
Dependencies | No dependencies. | |
FIA_UID.2.1[AID] | The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. | |
AppNote | • | By users here it must be understood the ones associated to the packages (or ap- plets) that act as subjects of policies. In the Java Card System, every action is always performed by an identified user interpreted here as the currently selected applet or the package that is the subject’s owner. Means of identification are pro- vided during the loading procedure of the package and the registration of applet instances. |
• | The role Java Card RE defined in FMT_SMR.1 is attached to an IT security function rather than to a ”use” of the CC terminology. The Java Card RE does not ”identify” itself to the TOE, but it is part of it. | |
FIA_USB.1[AID] | User-subject binding (AID) | |
Hierarchical-To | No other components. | |
Dependencies | FIA_ATD.1 User attribute definition | |
FIA_USB.1.1[AID] | 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[AID] | The TSF shall enforce the following rules on the initial association of user security at-tributes with subjects acting on the behalf of users: [assignment:Each uploaded pack-age is associated with an unique Package AID]. | |
FIA_USB.1.3[AID] | 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 ini-tially assigned Package AID is unchangeable]. | |
AppNote | The user is the applet and the subject is the S.PACKAGE. The subject security attribute Contextshall hold the user security attribute Package AID. | |
FMT_MTD.1[JCRE] | Management of TSF data (JCRE) | |
Hierarchical-To | No other components. | |
Dependencies | FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions | |
FMT_MTD.1.1[JCRE] | The TSF shall restrict the ability to [selection: modify] the [assignment:list of regis- tered applets’ AIDs] to [assignment: S.JCRE]. | |
AppNote | • | The installer and the Java Card RE manage other TSF data such as the applet life cycle or CAP files, but this management is implementation specific. Objects in the Java programming language may also try to query AIDs of installed applets through the lookupAID(...) API method. |
• | The installer, applet deletion manager or even the card manager may be granted the right to modify the list of registered applets’ AIDs in specific implementations (pos-sibly needed for installation and deletion; see SA.DELETION and SA.INSTALL). | |
FMT_MTD.3[JCRE] | Secure TSF data (JCRE) | |
Hierarchical-To | No other components. | |
Dependencies | FMT_MTD.1 Management of TSF data | |
FMT_MTD.3.1[JCRE] | The TSF shall ensure that only secure values are accepted for [assignment:the regis-tered applet AIDs]. | |
7.2.2 INSTG Security Functional Requirements
The list of SFRs of this category are taken from the PP [13]. The SFR FDP_ITC.2[INSTALLER] has been refined and is now part of the card management SFRs (FDP_ITC.2[CCM]) in Section 7.2.6.
FMT_SMR.1[INSTALLER] Security roles (INSTALLER)
Hierarchical-To No other components
Dependencies FIA_UID.1 Timing of identification
FMT_SMR.1.1[INSTALLER] The TSF shall maintain the roles: [assignment: Installer].
FMT_SMR.1.2[INSTALLER]  nbsp; The TSF shall be able to associate users with roles.
FPT_FLS.1[INSTALLER] Failure with preservation of secure state (INSTALLER)
Hierarchical-To No other components.
Dependencies No dependencies.
FPT_FLS.1.1[INSTALLER] The TSF shall preserve a secure state when the following types of failures occur: [as-signment:
the installer fails to load/install a package/applet as described in [39], §11.1.5].
AppNote The TOE may provide additional feedback information to the card manager in case of
potential security violations (see FAU_ARP.1).
FPT_RCV.3[INSTALLER] Automated recovery without undue loss (INSTALLER)
Hierarchical-To FPT_RCV.2 Automated recovery
Dependencies AGD_OPE.1 Operational user guidance
FPT_RCV.3.1[INSTALLER] When automated recovery from [assignment: none] is not possible, the TSF shall enter
a maintenance mode where the ability to return to a secure state is provided.
FPT_RCV.3.2[INSTALLER] For [assignment: a failure during load/installation of a package/applet and deletion
of a package/applet/object], the TSF shall ensure the return of the TOE to a secure
state using automated procedures.
FPT_RCV.3.3[INSTALLER] The functions provided by the TSF to recover from failure or service discontinuity shall
ensure that the secure initial state is restored without exceeding [assignment: 0%]for
loss of TSF data or objects under the control of the TSF.
FPT_RCV.3.4[INSTALLER] The TSF shall provide the capability to determine the objects that were or were not capa-
ble of being recovered.
AppNote FPT_RCV.3.1[Installer]:
•This element is not within the scope of the Java Card specification, which only man-dates the behavior of the Java Card System in good working order. Further details on the ”maintenance mode” shall be provided in specific implementations. The fol-lowing is an excerpt from [3], p298: In this maintenance mode normal operation might be impossible or severely restricted, as otherwise insecure situations might occur. Typically, only authorised users should be allowed access to this mode but the real details of who can access this mode is a function of FMT: Security manage-ment. If FMT: Security management does not put any controls on who can access this mode, then it may be acceptable to allow any user to restore the system if the TOE enters such a state. However, in practice, this is probably not desirable as the user restoring the system has an opportunity to configure the TOE in such a way as to violate the SFRs.
FPT_RCV.3.2[Installer]:
•Should the installer fail during loading/installation of a package/applet, it has to revert to a ”consistent and secure state”. The Java Card RE has some clean up duties as well; see [39], §11.1.5 for possible scenarios. Precise behavior is left to implementers. This component shall include among the listed failures the deletion of a package/applet. See ([39], §11.3.4) for possible scenarios. Precise behavior is left to implementers.
•Other events such as the unexpected tearing of the card, power loss, and so on, are partially handled by the underlying hardware platform (see [24]) and, from the TOE’s side, by events ”that clear transient objects” and transactional features. See FPT_ FLS.1.1, FDP_RIP.1[TRANSIENT], FDP_RIP.1[ABORT] and FDP_ROL.1[FIREWALL].
FPT_RCV.3.3[Installer]:
•The quantification is implementation dependent, but some facts can be recalled here. First, the SCP ensures the atomicity of updates for fields and objects, and a power-failure during a transaction or the normal runtime does not create the loss of otherwise permanent data, in the sense that memory on a smart card is essentially persistent with this respect (FLASH). Data stored on the RAM and subject to such failure is intended to have a limited lifetime anyway (runtime data on the stack, transient objects’ contents). According to this, the loss of data within the TSF scope should be limited to the same restrictions of the transaction mechanism.
7.2.3 ADELG Security Functional Requirements
The list of SFRs of this category are taken from the PP [13].
FDP_ACC.2[ADEL] | Complete access control (ADEL) | |
Hierarchical-To | FDP_ACC.1 Subset access control | |
Dependencies | FDP_ACF.1 Security attribute based access control | |
FDP_ACC.2.1[ADEL] | The TSF shall enforce the [assignment:ADEL access control SFP] on [assignment: S.ADEL, S.JCRE, S.JCVM, O.JAVAOBJECT, O.APPLET, O.CODE_PKG and O.CODE_ MODULE]and all operations among subjects and objects covered by the SFP. | |
FDP_ACC.2.2[ADEL] | 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 the policy are: | |
• OP.DELETE_APPLET, | ||
• OP.DELETE_MODULE. | ||
FDP_ACF.1[ADEL] | Security attribute based access control (ADEL) | |
Hierarchical-To | No other components. | |
Dependencies | FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation | |
FDP_ACF.1.1[ADEL] | The TSF shall enforce the [assignment:ADEL access control SFP] to objects based on the following [assignment: | |
Subject/Object | Security Attributes | |
S.JCVM | ||
S.JCRE | Selected Applet Context, Registered Applets, Resident Packages, Resident Modules | |
O.APPLET | ||
O.JAVAOBJECT | Owner | |
] | ||
FDP_ACF.1.2[ADEL] | The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: | |
In the context of this policy, an object O is reachable if and only one of the following conditions hold:
1.the owner of O is a registered applet instance A (O is reachable from A),
2.a static field of a resident package P contains a reference to O (O is reachable from P),
3.a static field of a resident Module M contains a reference to O (O is reachable from M),
4.there exists a valid remote reference to O (O is remote reachable),
5. there exists an object O’ that is reachable according to either (1) or (2) or (3) above and O’ contains a reference to O (the reachability status of O is that of O’).
The following access control rules determine when an operation among controlled sub-jects and objects is allowed by the policy:
•R.JAVA.14 ([39], §11.3.4.1, Applet Instance Deletion): S.ADEL may perform OP.DELETE_ APPLET upon an O.APPLET only if,
1. S.ADELis currently selected,
2.there is no instance in the context of O.APPLET that is active in any logical channel and
3.there is no O.JAVAOBJECT owned by O.APPLETsuch that either O.JAVAOBJECT is reachable from an applet instance distinct from O.APPLET, or O.JAVAOBJECT is reachable from a package P or Module M, or ([39], §8.5) O.JAVAOBJECT is remote reachable.
•R.JAVA.15 ([39], §11.3.4.1, Multiple Applet Instance Deletion): S.ADEL may per-form OP.DELETE_APPLETupon several O.APPLETonly if,
1. S.ADELis currently selected,
2.there is no instance of any of the O.APPLET being deleted that is active in any logical channel and
3.there is no O.JAVAOBJECT owned by any of the O.APPLETbeing deleted such that either O.JAVAOBJECT is reachable from an applet instance distinct from any of those O.APPLET, or O.JAVAOBJECT is reachable from a package P or Module M, or ([39], §8.5) O.JAVAOBJECTis remote reachable.
•R.JAVA.16 ([39], §11.3.4.2, Applet/Library Package Deletion): S.ADEL may perform OP.DELETE_PCKG(O.CODE_PKG, ...)upon an O.CODE_PKG only if,
1. S.ADELis currently selected,
2.no reachable O.JAVAOBJECT, from a package or Module distinct from O.CODE_ PKG that is an instance of a class that belongs to O.CODE_PKG, exists on the card and
3.there is no resident package or resident Module on the card that depends on O.CODE_MODULE.
}
•R.JAVA.17 ([39], §11.3.4.3, Applet Package and Contained Instances Deletion): S.ADELmay perform OP.DELETE_PCKG_APPLET(O.CODE_PKG, ...)upon an O.CODE_PKG only if,
1. | S.ADELis currently selected, | |
2. | no reachable O.JAVAOBJECT, from a package or Module distinct from O.CODE_ PKG, which is an instance of a class that belongs to O.CODE_PKG exists on the card, | |
3. | there is no package or Module loaded on the card that depends on O.CODE_ PKG, and | |
4. | for every O.APPLETof those being deleted it holds that: (i) there is no instance in the context of O.APPLET that is active in any logical channel and (ii) there is no O.JAVAOBJECTowned by O.APPLETsuch that either O.JAVAOBJECT is reachable from an applet instance not being deleted, or O.JAVAOBJECTis reachable from a package or Module not being deleted, or ([39], §8.5) O.JAVAOBJECT is remote reachable. | |
• Module deletion: If a Module contains Java code then S.ADEL may perform OP.DELETE_ MODULEupon a Module only if the following rules are satisfied: | ||
1. | R.JAVA.14, if the Module contains an Applet Instance O.APPLET, | |
2. | R.JAVA.15, if the Module contains Multiple Applet Instances of O.APPLET, | |
3. | R.JAVA.16, if the Module contains an Applet/Library Package O.CODE_PKG and | |
4. | R.JAVA.17, if the Module contains an Applet Package O.CODE_PKG and Con-tained Instances O.APPLET. | |
] | ||
FDP_ACF.1.3[ADEL] | The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: deletion of O.CODE_MODULE witha TOE internal interface is allowed even if other Resident Packages or other Resident Modules depend on it]. | |
FDP_ACF.1.4[ADEL] | The TSF shall explicitly deny access of subjects to objects based on the following addi-tional rules: any subject but S.ADEL to O.CODE_PKG, O.APPLET or O.CODE_MODULE for the purpose of deleting them from the card. | |
AppNote FDP_ACF.1.2[ADEL]:
•This policy introduces the notion of reachability, which provides a general means to describe objects that are referenced from a certain applet instance or package.
• S.ADEL calls the ”uninstall” method of the applet instance to be deleted, if imple-mented by the applet, to inform it of the deletion request. The order in which these calls and the dependencies checks are performed are out of the scope of this pro-tection profile.
FDP_RIP.1[ADEL] | Subset residual information protection (ADEL) |
Hierarchical-To | No other components. |
Dependencies | No dependencies. |
FDP_RIP.1.1[ADEL] | The TSF shall ensure that any previous information content of a resource is made un-available upon the [selection: deallocation of the resource from]the following objects: [assignment: applet instances and/or packages and/or Modules when one of the deletion operations in FDP_ACC.2.1[ADEL] is performed on them]. |
AppNote | Deleted freed resources (both code and data) may be reused, depending on the way they were deleted (logically or physically). Requirements on de-allocation during applet/pack-age deletion are described in [39], §11.3.4.1, §11.3.4.2 and §11.3.4.3. |
FMT_MSA.1[ADEL] | Management of security attributes (ADEL) |
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[ADEL] | The TSF shall enforce the [assignment: ADEL access control SFP]to restrict the ability to [selection: modify] the security attributes [assignment: Registered Applets and Resident Packages] to[assignment: S.JCRE]. |
FMT_MSA.3[ADEL] | Static attribute initialisation (ADEL) |
Hierarchical-To | No other components. |
Dependencies | FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles |
FMT_MSA.3.1[ADEL] | The TSF shall enforce the[assignment: ADEL access control SFP] to provide [selec-tion: restrictive] default values for security attributes that are used to enforce the SFP. |
FMT_MSA.3.2[ADEL] | The TSF shall allow the [assignment: none], to specify alternative initial values to over-ride the default values when an object or information is created. |
FMT_SMF.1[ADEL] | Specification of Management Functions (ADEL) |
Hierarchical-To | No other components. |
No dependencies. | |
FMT_SMF.1.1[ADEL] | The TSF shall be capable of performing the following management functions: [assign-ment: modify the list of registered applets’ AIDs, the Resident Packages and Resi-dent Modules]. |
FMT_SMR.1[ADEL] Security roles (ADEL)
Hierarchical-To No other components.
Dependencies FIA_UID.1 Timing of identification
FMT_SMR.1.1[ADEL] The TSF shall maintain the roles: [assignment: applet deletion manager].
FMT_SMR.1.2[ADEL] The TSF shall be able to associate users with roles.
FPT_FLS.1[ADEL] Failure with preservation of secure state (ADEL)
Hierarchical-To No other components.
Dependencies No dependencies.
FPT_FLS.1.1[ADEL] The TSF shall preserve a secure state when the following types of failures occur: [as-signment:
the applet deletion manager fails to delete a package/applet as de-scribed in [39],
§11.3.4 or it fails to delete a Module.]
AppNote • The TOE may provide additional feedback information to the card manager in case of
a potential security violation (see FAU_ARP.1).
•The Package/applet instance/Module deletion must be atomic. The ”secure state” referred to in the requirement must comply with Java Card specification ([39], §11.3.4.)
7.2.4 RMIG Security Functional Requirements
Not used in this ST because RMI is optional in the PP [13] and the TOE does not support RMI.
7.2.5 ODELG Security Functional Requirements
The list of SFRs of this category are taken from the PP [13].
FDP_RIP.1[ODEL] Subset residual information protection (ODEL)
Hierarchical-To | No other components. | |
Dependencies | No dependencies. | |
FDP_RIP.1.1[ODEL] | The TSF shall ensure that any previous information content of a resource is made unavail-able upon the [selection: deallocation of the resource from] the following objects: [as-signment: the objects owned by the context of an applet instance which triggered the execution of the method javacard.framework.JCSystem.requestObjectDeletion()]. | |
AppNote | • | Freed data resources resulting from the invocation of the methodjavacard.framework.JCSystem.requestObjectDeletion() may be reused. Require-ments on de-allocation after the invocation of the method are described in [38]. |
• | There is no conflict with FDP_ROL.1 here because of the bounds on the rollback mechanism: the execution of requestObjectDeletion() is not in the scope of the rollback because it must be performed in between APDU command processing, and therefore no transaction can be in progress. | |
FPT_FLS.1[ODEL] | Failure with preservation of secure state (ODEL) | |
Hierarchical-To | No other components. | |
Dependencies | No dependencies. | |
FPT_FLS.1.1[ODEL] | The TSF shall preserve a secure state when the following types of failures occur: [as-signment: the object deletion functions fail to delete all the unreferenced objects owned by the applet that requested the execution of the method]. | |
AppNote | The TOE may provide additional feedback information to the card manager in case of potential security violation (see FAU_ARP.1). | |
9 Contents
| 1 ST Introduction (ASE_INT) | |||
| 1.2.3 Required non-TOE Hardware/Software/Firmware | |||
2 Conformance Claims (ASE_CCL) | |||
3 Security Aspects | |||
4 Security Problem Definition (ASE_SPD) | |||
6 Extended Components Definition (ASE_ECD) | |||
7 Security Requirements (ASE_REQ) | |||
8 TOE summary specification (ASE_TSS) | |||
13 Legal information | |||