NXP JCOP 4 Security Target Lite v3.4 2

2       Conformance Claims (ASE_CCL)

This Chapter is divided into the following sections: "CC Conformance Claim", "Package Claim", "PP Claim", and "Conformance Claim Rationale".

2.1   CC Conformance Claim

This Security Target claims to be conformant to version 3.1 of Common Criteria for Information Technology Secu-rity Evaluation according to

•"Common Criteria for Information Technology Security Evaluation, Part 1, Version 3.1, Revision 5, April 2017" [2]

•"Common Criteria for Information Technology Security Evaluation, Part 2, Version 3.1, Revision 5, April 2017" [3]

•"Common Criteria for Information Technology Security Evaluation, Part 3, Version 3.1, Revision 5, April 2017" [4]

The following methodology will be used for the evaluation:

•Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 5, April 2017" [6]

This Security Target claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security Func-tional Requirements are defined in Chapter 6.

2.2   Package Claim

This Security Target claims conformance to the assurance package EAL6. The augmentation to EAL6 is ASE_ TSS.2 “TOE summary specification with architectural design summary” and ALC_FLR.1 “Basic flaw remediation”.

2.3   PP Claim

The Security Target claims demonstrable conformance to the Java Card System - Open Configuration Protection Profile, December 2017, Version 3.0.5 [13], certified by Bundesamt für Sicherheit in der Informationstechnik (BSI, BSI-CC-PP-0099-2017). The Java Card Protection Profile makes the use of Java Card RMI optional. The TOE does not support Java Card RMI. This ST is more restrictive than the PP [13] which Chapter 2.4 provides a rational for. The TOE implements the feature "Management of External Memory (EXT-MEM)" from the group EMG that the Java Card Protection Profile makes optional.

2.4 Conformance Claim Rationale

2.4.1TOE Type

The TOE type as stated in Section 1.2 of this ST corresponds to the TOE type of the PP as stated in Section 2.1 of [13] namely a Java Card platform, implementing the Java Card Specification Version 3.0.5 [40, 39, 38].

2.4.2 SPD Statement

2.4.2.1 Threats

The Security Problem Definition (SPD) statement that is presented in Chapter 4 includes the threats as presented in the PP [13], but also includes additional threats. These threats are:

• T.OS_OPERATE

•T.RND

• T.COM_EXPLOIT

• T.LIFE_CYCLE

• T.UNAUTHORIZED_CARD_MNGT

• T.INTEG-APPLI-DATA[REFINED]

•T.CONFIG

• T.SEC_BOX_BORDER

• T.MODULE_EXEC

• T.MODULE_REPLACEMENT

The threat T.OS_OPERATE is an additional threat added to cover incorrect operating system behavior, it is an addition to the threats in the PP [13].

The threat T.RND is taken from the Security IC PP [24].

The threat T.COM_EXPLOIT is included to cover communication channels attacks and it is an addition to the threats in the PP [13].

The threat T.LIFE_CYCLE is included to cover content management attacks and it is an addition to the threats in the PP [13].

The threat T.UNAUTHORIZED_CARD_MNGT refines the threats T.INSTALL and T.DELETION from the Security IC PP [24].

The threat T.INTEG-APPLI-DATA[REFINED]refines the threat T.INTEG-APPLI-DATA in the Security IC PP [24]. The threat T.CONFIG is an additional threat to cover unauthorized modifications and read access of the configu-ration area in the TOE. It is an addition to the threats defined in the PP [13].

The threat T.ATTACK-COUNTERis included for reset of the attack counter which is additional functionality the PP [13] allows.

The threat T.SEC_BOX_BORDERis included for the Secure Box which is additional functionality the PP [13] allows.

The threats T.MODULE_EXECand T.MODULE_REPLACEMENTare included for the Modular Design which is additional functionality the PP [13] allows. Furthermore some threats from the PP [13] are refined to cover ad-ditional assets from the Modular Design. This comprises threats T.CONFID-JCS-CODE, T.CONFID-JCS-DATA, T.INTEG-APPLI-CODE, T.INTEG-JCS-CODE, T.INTEG-JCS-DATA,and T.SID.1.

Note that the threat T.EXE-CODE-REMOTE is not included, since the TOE does not support Java Card RMI. The Java Card Protection Profile [13] makes the use of Java Card RMI optional.

2.4.2.2 Organizational Security Policies

The SPD statement presented in Chapter 4, copies the OSP from the PP [13], and adds following additional OSPs:

•OSP.PROCESS-TOE

•OSP.KEY-CHANGE

•OSP.SECURITY-DOMAINS

•OSP.SECURE-BOX

The Organizational Security Policy (OSP) OSP.PROCESS-TOE is introduced for the pre-personalisation feature of the TOE and is an addition to the OSPs in PP [13]. This OSP is copied from the Security IC PP [24].

The OSP OSP.KEY-CHANGEis introduced for the Security Domain (SD) feature of the TOE and is an addition to the OSPs in PP [13].

The OSP OSP.SECURITY-DOMAINS is introduced for the SD feature of the TOE and is an addition to the OSPs in PP [13].

The OSP.SECURE-BOXis introduced to allow execution of third party native code and is an addition to the OSPs in PP [13].

2.4.2.3Assumptions

The SPD statement includes two of the three assumptions from the PP [13]. The assumption A.Deletion is excluded. The Card Manager is part of the TOE and therefore the assumption is no longer relevant. Leaving out the assumption, makes the SPD of this ST more restrictive than the SPD in the PP [13]. As the Card Manager is part of the TOE, it is ensuring that the deletion of applets through the Card Manager is secure, instead of assuming that it is handled by the Card Manager in the environment of the TOE.

Besides the assumptions from the PP [13], following additional assumptions are added:

•A.PROCESS-SEC-IC

• A.USE_DIAG

• A.USE_KEYS

•A.APPS-PROVIDER

•A.VERIFICATION-AUTHORITY

The assumption A.PROCESS-SEC-ICis taken from the underlying certified Micro Controller [20], which is com-pliant to the Security IC PP [24].

The assumptions A.USE_DIAGand A.USE_KEYSare included because the Card Manager is part of the TOE and no longer part of the environment.

The assumptions A.APPS-PROVIDERand A.VERIFICATION-AUTHORITYare added because Security Domains from the GlobalPlatform Specification are introduced. All the applets and packages are signed by the Application Provider Security Domain (APSD) and the correctness is verified on the TOE by Verification Authority Security Domain (VASD) before the package or applet is installed or loaded. A.APPS-PROVIDER and A.VERIFICATION- AUTHORITYareadditions to PP [13] for card content management environment.

2.4.3Security Objectives Statement

The statement of security objectives in the ST presented in Chapter 5 includes all security objectives as presented in the PP [13], but also includes a number of additional security objectives. These security objectives are:

•OT.IDENTIFICATION

•OT.DOMAIN-RIGHTS

•OT.APPLI-AUTH

• OT.COMM_AUTH

• OT.COMM_INTEGRITY

• OT.COMM_CONFIDENTIALITY

•OT.CARD-CONFIGURATION

• OT.SEC_BOX_FW

• OT.SID_MODULE

The security objective OT.IDENTIFICATIONis part of the security objectives of the certified Micro Controller [20] (see also Section 1.3.1.1) and Crypto Lib [20] (see also Section 1.3.1.2.2), which are also components of this composite certification. Therefore the security objective statement is equivalent to the PP [13] for these two se-curity objectives. OT.IDENTIFICATIONis also included for the pre-personalisation feature of the TOE, which is additional functionality the PP allows.

The security objectives OT.DOMAIN-RIGHTS, OT.APPLI-AUTH, OT.COMM_AUTH, OT.COMM_INTEGRITY, OT.COMM_ CONFIDENTIALITYareobjectives for the TOE as the GlobalPlatform API and the definitions for Secure Channel,Security Domains and Card Content Management are used from it.

The security objective OT.CARD-CONFIGURATION is related to the configuration of the TOE via the Configuration Module, which is additional functionality the PP [13] allows.

The security objective OT.SEC_BOX_FW is related to the Secure Box, which is additional functionality the PP allows.

The security objective OT.SID_MODULE is related to the Modular Design of the TOE, which is additional func-tionality the PP [13] allows.

The ST contains OE.APPLET, OE.VERIFICATION and OE.CODE-EVIDENCEfrom Security Objectives for the Operational Environment from [13]. Additionally, some of the Security Objectives for the Operational Environment from [13] are listed as TOE Security Objectives in this ST:

• OT.SCP.RECOVERY insteadof OE.SCP.RECOVERY

• OT.SCP.SUPPORT insteadof OE.SCP.SUPPORT

• OT.SCP.IC insteadof OE.SCP.IC

•OT.CARD-MANAGEMENT instead of OE.CARD-MANAGEMENT

OT.SCP.RECOVERY, OT.SCP.SUPPORT,and OT.SCP.ICareobjectives for the TOE as the Smart Card Platformbelongs to the TOE for this evaluation. OT.CARD-MANAGEMENTis an objective for the TOE as the Card Man-ager belongs to the TOE for this evaluation. Moving objectives from the environment to the TOE adds objectives to the TOE without changing the overall objectives. The statement of security objectives is therefore equivalent to the security objectives in the PP [13] to which conformance is claimed.

The security objective O.EXT-MEM from the optional EMG group of the PP [13] is included as OT.EXT-MEM.

The security objectives O.INSTALL, O.LOAD, and O.DELETION from the PP [13] are not included since these functionality and objectives are covered by the refined OT.CARD-MANAGEMENT.

Note that the objective O.REMOTE is not included, since the TOE does not support Java Card RMI. The Java Card Protection Profile makes the use of Java Card RMI optional.

A part of the security objectives for the environment defined in the PP [13] has been included in this ST. The other part of security objectives for the environment, which is present in the PP [13], is used as part of the security objectives for the TOE in this ST. The ST also introduces following additional security objectives for the environment:

• OE.PROCESS_SEC_IC

• OE.USE_DIAG

• OE.USE_KEYS

•OE.APPS-PROVIDER

•OE.VERIFICATION-AUTHORITY

•OE.KEY-CHANGE

•OE.SECURITY-DOMAINS

The security objective for the environment OE.PROCESS_SEC_IC is from the hardware platform (Micro Con-troller [20] see also Section 1.3.1.1) that is part of this composite product evaluation. Therefore the statement of security objectives for the environment is equivalent to the statement in the Security IC PP [24].

OE.USE_KEYS and OE.USE_DIAGareincluded because the Card Manager is part of the TOE and not a securityobjective for the environment as in PP [13].

OE.APPS-PROVIDER and OE.VERIFICATION-AUTHORITYcovertrusted actors which enable the creation, dis-tribution and verification of secure applications.

OE.KEY-CHANGE coversthe switch to trusted keys for the AP.

OE.SECURITY-DOMAINScoversthe management of security domains in the context of the GlobalPlatform Spec-ification.

The statement of security objectives for the environment is therefore considered to be equivalent to the security objectives in the PP [13] to which conformance is claimed.

2.4.4 Security Functional Requirements Statement

The statement of security functional requirements copies most SFRs as defined in the PP [13], with the exception of a number of options. For the copied set of SFRs the ST is considered equivalent to the statement of SFRs in the PP [13]. Moreover as requested by the PP [13] the ST adds additional threats, objectives and SFRs to fully cover and describe additional security functionality implemented in the TOE.

The TOE does not implement Java Card RMI, therefore this ST restricts remote access from the CAD to the services implemented by the applets on the card to none. As a result the SFRs concerning Java Card RMI (FDP_ACF.1/JCRMI, SFRs FDP_IFC.1/JCRMI, FDP_IFF.1/JCRMI, FMT_MSA.1/EXPORT, FMT_MSA.1/REM_ REFS, FMT_MSA.3/JCRMI, FMT_SMF.1/JCRMI, FMT_REV.1/JCRMI, and FMT_SMR.1/JCRMI) are not included in the ST. In the PP [13] the use of the Java Card RMI is optional.

The SFR FDP_ITC.2/INSTALLER from the PP [13] is replaced by FDP_ITC.2[CCM]which enforces the Security Domain access control policy and the Secure Channel Protocol information flow policy and which are more re-strictive than the PACKAGE LOADING information flow control SFP from PP [13].

The set of SFRs that define the card content management mechanism CarG are partly replaced or refined and are considered to be equivalent or more restrictive because of the newly introduced SFPs:

1.Security Domain access control policy,

2.Secure Channel Protocol information flow policy

provide a concrete and more restrictive implementation of the PACKAGE LOADING information flow control SFP from PP [13].

The table below lists the SFRs from CarG of PP [13] and their corresponding refinements in this ST.

Tab. 2.1: CarG SFRs refinements

The following SFRs realize refinements of SFRs from PP [13] and add functionality to the TOE making the state-ment of security requirements more restrictive than the PP [13]:

FDP_ROL.1[CCM] and FPT_FLS.1[CCM]realizeadditional security functionality for the card manager which isallowed by the PP [13].

The set of SFRs that define the security domains mechanism as specified by GlobalPlatform, realize refine-ments of SFRs from PP [13] (see above table 2.1) and additional security functionality which is allowed by the PP [13]. This set of SFRs comprise FDP_ACC.1[SD], FDP_ACF.1[SD], FMT_MSA.1[SD], FMT_MSA.3[SD], FMT_ SMF.1[SD],and FMT_SMR.1[SD].

The set of SFRs that define the secure channel mechanism as specified by GlobalPlatform, realize refinements of SFRs from PP [13] (see above table 2.1) and additional security functionality which is allowed by the PP [13]. This set of SFRs comprise FCO_NRO.2[SC], FDP_IFC.2[SC], FDP_IFF.1[SC], FMT_MSA.1[SC], FMT_MSA.3[SC], FMT_SMF.1[SC], FIA_UID.1[SC], FIA_UAU.1[SC], FIA_UAU.4[SC],and FTP_ITC.1[SC].

The set of SFRs that define the Configuration Module realize additional security functionality, which is allowed by the PP [13]. This set of SFRs comprise FDP_IFC.2[CFG], FDP_IFF.1[CFG], FIA_UID.1[CFG], FMT_MSA.1[CFG], FMT_MSA.3[CFG], FMT_SMF.1[CFG]and FMT_SMR.1[CFG].

The set of SFRs that define the Secure Box, realize additional security functionality which is allowed by the Protection Profile (PP) [13]. This set of SFRs comprise FDP_ACC.2[SecureBox], FDP_ACF.1[SecureBox], FMT_ MSA.1[SecureBox], FMT_MSA.3[SecureBox],and FMT_SMF.1[SecureBox].

The set of SFRs that define the Modular Design realize additional security functionality, which is allowed by the PP [13]. This set of SFRs comprise FDP_IFC.1[MODULAR-DESIGN], FDP_IFF.1[MODULAR-DESIGN],FIA_

ATD.1[MODULAR-DESIGN], FIA_USB.1[MODULAR-DESIGN], FMT_MSA.1[MODULAR-DESIGN], FMT_MSA.3[MODULAR

DESIGN], FMT_SMF.1[MODULAR-DESIGN], FMT_SMR.1[MODULAR-DESIGN],and FPT_FLS.1[MODULAR-

DESIGN].

Some SFRs from the PP [13] are refined to cover deletion of Modules. This makes the SFRs more restric-tive which is allowed by the PP [13]. This set of SFRs comprise FDP_ACC.2[ADEL], FDP_ACF.1[ADEL], FMT_ SMF.1[ADEL],and FPT_FLS.1[ADEL].

The set of SFRs that define the Restricted Mode realize additional security functionality, which is allowed by the PP [13]. This set of SFRs comprise FDP_ACC.2[RM], FDP_ACF.1[RM], FMT_MSA.3[RM], FMT_MSA.1[RM], FMT_SMF.1[RM], FIA_UID.1[RM]and FIA_UAU.1[RM].

The SFRs FAU_SAS.1[SCP], FIA_AFL.1[PIN], FPT_EMSEC.1 and FPT_PHP.3realize additional security func-tionality which is allowed by the PP [13]. The SFRs FCS_CKM.2 and FCS_CKM.3realize security functionality required by the Java Card API [38] which is allowed by the PP [13].

9    Contents