ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 1/92 CRYPTOSMART CARD 5.1 PUBLIC SECURITY TARGET Document revision: 67 Author Validation Approval Julien Kowalski Eric Laubacher Engineering. Réseaux. Communications. 6, rue Dewoitine - 78140 VELIZY - FRANCE Phone: 01 39 46 50 50 Fax : 01 39 46 25 25 International phone: +33 1 39 46 50 50 International fax: +33 1 39 46 25 25 Web : www.ercom.fr email : info@ercom.fr Ver. Date Author Designation / Modification 5.1-draft 2014-12-11 JKI Initial version based on 5.0 security target 5.1 2015-05-21 JKI Included remarks from AF (Oberthur) 5.1.1 2016-01-12 JKI Modification after Evaluator and AF remarks 5.1.2 2016-05-31 JKI Modification after Evaluator remarks ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 2/92 TABLE OF CONTENT 1. SECURITY TARGET INTRODUCTION ..................................................................................................................... 5 1.1 FOREWORD ............................................................................................................................................................5 1.2 SECURITY TARGET AND TOE IDENTIFICATION ..................................................................................................................5 1.3 CONFORMANCE CLAIMS ............................................................................................................................................5 1.4 CONVENTIONS.........................................................................................................................................................6 1.5 TERMINOLOGY ........................................................................................................................................................7 1.6 REFERENCES ...........................................................................................................................................................8 2. TOE DESCRIPTION ............................................................................................................................................... 9 2.1 TOE OVERVIEW.......................................................................................................................................................9 2.2 TOE SAMPLE USAGE: THE CRYPTOSMART SYSTEM ..........................................................................................................9 2.3 TOE DESCRIPTION..................................................................................................................................................12 2.4 INTEGRATION IN JCS LIFE CYCLE ................................................................................................................................21 2.5 COMPOSITE TOE SCOPE..........................................................................................................................................21 3. SECURITY PROBLEM DEFINITION........................................................................................................................24 3.1 ASSETS TO PROTECT................................................................................................................................................24 3.2 ASSUMPTIONS.......................................................................................................................................................25 3.3 THREATS ..............................................................................................................................................................27 3.4 OSP....................................................................................................................................................................29 4. SECURITY OBJECTIVES........................................................................................................................................31 4.1 SECURITY OBJECTIVES FOR THE TOE............................................................................................................................31 4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT .............................................................................................................33 5. SECURITY REQUIREMENTS .................................................................................................................................35 5.1 EXTENDED FAMILY..................................................................................................................................................35 5.2 SECURITY FUNCTIONAL REQUIREMENTS......................................................................................................................36 5.3 TOE SECURITY ASSURANCE REQUIREMENTS..................................................................................................................57 6. GLOBAL TOE SPECIFICATION ..............................................................................................................................58 6.1 TOE SECURITY FUNCTIONS........................................................................................................................................58 7. RATIONALES.......................................................................................................................................................63 7.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................................63 7.2 SECURITY REQUIREMENTS RATIONALE ........................................................................................................................68 7.3 GLOBAL TOE SPECIFICATION RATIONALE......................................................................................................................74 8. CONSISTENCY OF COMPOSITE PRODUCT SECURITY TARGET..............................................................................81 8.1 SEPARATION OF TSF...............................................................................................................................................81 8.2 COMPATIBILITY OF SAR...........................................................................................................................................81 8.3 COMPATIBILITY OF SFR...........................................................................................................................................82 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 3/92 8.4 COMPATIBILITY OF SECURITY OBJECTIVES ....................................................................................................................85 8.5 COMPATIBILITY OF SECURITY OBJECTIVES FOR THE ENVIRONMENT....................................................................................91 8.6 COMPATIBILITY OF THREATS .....................................................................................................................................91 8.7 COMPATIBILITY OF OSP ..........................................................................................................................................91 8.8 COMPATIBILITY OF ASSUMPTIONS..............................................................................................................................92 8.9 COMPATIBILITY WITH [ANSSI-NOTE-10]..................................................................................................................92 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 4/92 TABLE OF FIGURES Figure 1: Cryptosmart sample architecture ..................................................................................................... 11 Figure 2: Cryptosmart card life cycle ............................................................................................................... 17 Figure 3: JCS life cycle.................................................................................................................................... 21 Figure 4: TOE scope........................................................................................................................................ 22 TABLES Table 1 : Cryptosmart card life states.............................................................................................................. 18 Table 2: Assets security needs........................................................................................................................ 25 Table 3: Function access rights....................................................................................................................... 42 Table 4: Cryptosmart card aimed assurance levels ........................................................................................ 57 Table 5: Tracing between security objectives and security problem definition ............................................... 63 Table 6: SFR dependencies ............................................................................................................................ 69 Table 7: security requirements / objectives consistency matrix ...................................................................... 71 Table 8: Mapping toe sfrs to toe security functions ......................................................................................... 77 Table 9: SAR compatibility............................................................................................................................... 81 Table 10: SFR compatibility............................................................................................................................. 85 Table 11: Compatibility of security objectives.................................................................................................. 86 Table 12: Mapping of platform's security objectives to platform's SFR........................................................... 91 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 5/92 1. SECURITY TARGET INTRODUCTION 1.1 FOREWORD For convenience and ease of reuse of previous evaluation results (ANSSI-CC-2012/71), this security target is redacted as if the TOE was a composite TOE between the Cryptosmart applet and the underlying javacard platform. However this platform has not been evaluated on its own. In order to fulfill every assurance requirements complementary elements will be provided either as specific section in this ST or dedicated documents. 1.2 SECURITY TARGET AND TOE IDENTIFICATION This document constitutes the Security Target (ST) of the Cryptosmart card, version 5.1 developed by Ercom.  ST name: Cryptosmart card 5.1 – Security target  ST version: 5.1.2  ST Date : November 7, 2016  TOE identifier: Cryptosmart applet 5.1 on Oberthur ID-ONE COSMO V7.0.1-R2  TOE version: 5.1  TOE Developer : ERCOM& Oberthur Technologies  Evaluation sponsor : ERCOM This security target addresses a composite TOE evaluation in the sense of [CPESC] where:  The certified platform IC is an NXP Secure Smart Card Controllers P5Cx081  The Java Card platform is the ID-ONE COSMO V7.0.1 – R2OS;  The application is the Cryptosmart applet V5.1. The platform is identified as follows: Platform name ID-One Cosmo V7.0.1-n R2.0 (Standard and Standard Dual) Platform software identification Javacard platform mask = “7101” Platform IC reference version P5CC081, P5CD081 Reference of the CC certificates of the underlying IC BSI-DSZ-CC-0857-V2-2015 1.3 CONFORMANCE CLAIMS This Security Target claims conformance to CC version 3.1 with the following documents:  "Common Criteria for information Technology Security Evaluation, Part 1: Introduction and general model", September 2012, Version 3.1 Revision 4 (CCMB-2012-09-001)  "Common Criteria for information Technology Security Evaluation, Part 2: Security Functional requirements", September 2012, Version 3.1 Revision 4 (CCMB-2012-09-002)  "Common Criteria for information Technology Security Evaluation, Part 3: Security Assurance requirements", September 2012, Version 3.1 Revision 4 (CCMB-2012-09-003) Conformance is claimed as follows:  Part 2: extended with the FPT_EMSEC. All the other Security requirements have been drawn fromthe catalogue of requirements in Part 2  Part 3: conformant.The chosen Evaluation Assurance Level is EAL4 augmented with ALC_DVS.2and AVA_VAN.5 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 6/92 Conformity to a protection profile: This Security Target does not claim conformance with any Protection Profile. 1.4 CONVENTIONS APDU Application Protocol Data Unit CA Certificate Authority DH Diffie-Hellman ERCOM ERCOM S.A. IA Identification and Authentication PP Protection Profile SFP Security Function Policy ST Security Target TOE Target of Evaluation – called CC for system being evaluated TSC TSF Scope of Control TSF TOE Security Functions TSP TOE Security Policy ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 7/92 1.5 TERMINOLOGY Card admin station Device for managing a fleet of Cryptosmart cards. Administrator Person authorized to access the administration station and manage the fleet of Cryptosmart cards. The administrator is the user of the applet before it is delivered to the final user. Authentication Service ensuring the identity of a card. Certificate Identity data and public key of a user signed by the private key of the certification authority. Card personalization This is the process where an administrator injects or generates the cryptographic keys inside the Cryptosmart card. The name certification comes from the fact a user certificate shall be imported inside the smartcard during this process. Clone card Device having the capacity to substitute for a legitimate card, in particular to authenticate itself and generate a valid session key. CRL Certificate Revocation List. List of certificates that are no longer authorized. Cryptosmart card Smartcard incorporating the Cryptosmart applet Host Represents the module managing communications with the smartcard. By extension it may be viewed as the device embedding the Cryptosmart card. Local attacker Third party person trying to corrupt or recover sensitive data by accessing a Cryptosmart card directly without knowing the security code. This may be a legitimate user of a card of the same family as the TOE. The legitimate user of the TOE and the administrator are excluded from this definition. Some data shall not be modified or recovered even knowing the TOE security code. In this case even the legitimate user may be considered as an attacker against these data. MAC Message Authentication Code, a message sealing and integrity verification mechanism with secret key. Masquerade Action aimed at deceiving a correspondent about his real identity. Online attacker Third party person trying to corrupt or recover sensitive data by intercepting and/or modifying the flows between equipment using Cryptosmart cards. The online attacker may possess lost or stolen cards of the same family as the TOE and knowing their Security Code. It may also be a legitimate user of another card of the same family as the TOE. The legitimate TOE user, the legitimate user of the card with which the TOE has to establish a session and the PKI administrator1 are excluded from this definition. Reset Re-initialization of the smartcard volatile memory. Session key 256-bit key generated by the Cryptosmart card at each Cryptosmart authentication protocol run. This key is provided to the host under a wrapped form. It is derived by the Cryptosmart card into keys transmitted to the host. These keys protect the flows exchanged between hosts. User Person carrying a user type Cryptosmart card and knowing his security code 1 As a dishonest PKI administrator may issue any certificates he may impersonate any other user. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 8/92 1.6 REFERENCES [CC3-p1] Common Criteria for information Technology Security Evaluation, Part 1: Introduction and general model", September 2012, Version 3.1 Revision 4 (CCMB-2012-09-001) [CC3-p2] Common Criteria for information Technology Security Evaluation, Part 2: Security Functional requirements", September 2012, Version 3.1 Revision 4 (CCMB-2012-09- 002) [CC3-p3] Common Criteria for information Technology Security Evaluation, Part 3: Security Assurance requirements", September 2012, Version 3.1 Revision 4 (CCMB-2012-09- 003) [CPESC] Composite product evaluation for Smart Card and similar devices version 1.1 revision 1 [JCAPI] "Java Card 2.2.2 - API" Application Programming Interfaces Version 2.2.2 March, 2006, Sun Microsystems [JCS-PP] Java Card™ System Protection Profile Collection Version 1.0b, SUN microsystem [IC_ST] NXP Secure Smart Card Controllers P5CD016/021/041/051 and P5Cx081 V1A/ V1A(s) – security target lite; rev 1.9, June 3, 2013 [IOC7 - ST] ID-ONE COSMO V7.0.1TERPSICHORE Security Target FQR 110 5145Issue 4. [ANSSI-CC- 2012/30] Rapport de certification ANSSI-CC-2012/30 Carte à puce ID-ONE Cosmo V7.0.1-n, avec correctif 077121, masque sur composants NXP P5CD081 V1A (Standard Dual), P5CC081 V1A (Standard) et P5CD041 V1A (Basic Dual) [PP CM] Cryptographic modules, security level “enhanced”. BSI-CC-PP-0045 [RGS_ANSSI] Référentiel Général de Sécurité Version 1.0 – ANSSI (http://www.ssi.gouv.fr/site_article38.html) [CRYPTO_ANSSI] RGS – Annex B1. Mécanismes cryptographiques : Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques [KEY_ANSSI] RGS – Annex B2. Gestion des clés cryptographiques : Règles et recommandations concernant la gestion des clés utilisées dans des mécanismes cryptographiques [ANSSI-NOTE-10] Note d’application - certification de produits ouverts de type carte a puce. Note 4758/ANSSI/SDE/PSS/CCN du 05 novembre 2014. ANSSI. [CSMART_USER_ GUIDE] Cryptosmart Card 5.1 Developer's guide [FIPS PUB 197] Federal InformationProcessing Standards Publication 197, Specification for theADVANCED ENCRYPTION STANDARD (AES), November 26, 2001 [FIPS PUB 180-4] FIPS PUB 180-4 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION Secure Hash Standard (SHS),August2015 [FIPS PUB 198-1] FIPS PUB 198-1 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, The Keyed-Hash Message Authentication Code (HMAC), July 2008 [PKCS#1 v2.1] PKCS #1 v2.1: RSA Cryptography Standard, RSA LaboratoriesJune 14, 2002 [PKCS#3] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories Technical Note, Version 1.4, Revised November 1, 1993 Note: The underlying javacard platform has not been evaluated on its own and therefore does not have any security target. However, the underlying javacard platform fulfils the same SFRs, TSFs as [IOC7 - ST] Therefore, the security target of this javacard platform can be considered ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 9/92 2. TOE DESCRIPTION 2.1 TOE OVERVIEW The TOE consists of a Javacard applet developed by Ercom running on a smartcard running the Oberthur ID- ONE COSMO V7.0.1-R2Javacard OS on NXP chip. The TOE has three main usages:  Provide the ability to authenticate a distant Cryptosmart card and negotiate a shared key with it;  Act as a cryptographic processor, by providing cryptographic function which are: o User authentication by using a security code o Secure key storage, either for 256 bits symmetric keys or 2048 bits RSA keys o Key export to host interface, either for 256 bits symmetric keys or 2048 bits RSA keys o A subset of PKCS#11 functionalities. The smartcard offers in device cryptography. This allows performing cryptographic computation without exposing the secret key. Operations supported by the TOE are:  Symmetric encryption and decryption using AES-256 .  Symmetric MAC generation and verification using HMAC-SHA2562  RSA-2048 decryption using PKCS#1.5 and PKCS#1.5-OAEP padding schemes  RSA-2048 signature using PKCS#1.5 padding scheme with no hash function (which allows the usage of any hash function: digest shall be performed by the host) o 2048 bits RSA key generation o 256 bits symmetric key generation o Management of the extractable property for RSA and symmetric keys o Management of the key usage property for symmetric keys o “Local encryption key” obtention by deriving internal keys o Random Number generation  Provide a secure storage area. The PKCS#11 C interfaces to smartcard functionalities is provided by the card driver which translates PKCS#11 C functions calls into smartcard commands. This driver is out of the scope of the evaluation and is not required to use the TOE. The smartcard PKCS#11 functionalities are called by extension PKCS#11 functions in this document. 2.2 TOE SAMPLE USAGE: THE CRYPTOSMART SYSTEM This section presents a Cryptosmart card usage example. Ercom has developed a product family called Cryptosmart for mobile and nomadism security. It protects any kind of devices (mobile, laptops, fixed phones, vehicles) on any kind of networks (mobile, wireless, wireline, satellite) for any kind of applications (mail, voice, SMS, video, business applications). In all cases, it always uses a Cryptosmart card. The Cryptosmart system consists in: 2This functionality is outside evaluated scope ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 10/92  A Cryptosmart Gateway which interconnects external devices with the enterprise/customer IT center for data communications via a VPN and for encrypted-clear calls ; it also provides routing and SIP functionalities for secure end-to-end VOIP calls between two devices.  Cryptosmart PC Suite and Cryptosmart Mobile Suite : it provides protection of the devices, protection of the data flows, and protection of voice calls  Cryptosmart Card (the TOE) providing strong authentication and key management functions for both the Cryptosmart Gateway and the devices ;  Cryptosmart CardAdminStation for administration and management of Cryptosmart Cards. The Cryptosmart Card acts as a root of trust for the Cryptosmart system by  protecting essential secrets which allow user authentication,  managing cryptographic keys which allow the protection of user’s sensitive data and communications. For example, thanks to the use of the Cryptosmart Card (TOE), Cryptosmart Mobile Suite provides the following security features for PDA/Smart phones:  Strong authentication  Voice encryption  SMS protection  VPN  Local device encryption  Network firewall The secure communications provided by the Cryptosmart solution protect the user’s sensitive data in confidentiality, integrity and authenticity. The following diagram presents an example of architecture with Cryptosmart Mobile Suite, Cryptosmart PC Suite, Cryptosmart Gateway, and Cryptosmart CardAdminStation. Thus, users can:  Get access to their professional mail securely  Get access to their intranet securely  Get access to the internet via a proxy and thus benefit from the already established policy of their organization in terms of internet access  Make secure end-to-end calls  Call any anyone in their organization while securing the outside path of the communication thanks to the PBX interconnection  Send secure SMS ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 11/92 Main location LAN Cryptosmart Gateway Mail server Proxy Intranet PBX/iPBX Cryptosmart Mobile Cryptosmart PC Fixed phone IP 2G/3G Cryptosmart CardAdminStation Cards Gateway admin Cards PKI Figure 1: Cryptosmart sample architecture Mobile devices are by definition easily lost or theft. Usage of the TOE in this system allows a secure storage of user secrets which are never directly stored on the mobile device.  User data remain protected in case of theft by an attacker as protection keys are stored by the smartcard and using the Cryptosmart card requires a security code;  The most sensitive cryptographic keys never appear on the host device: cryptographic operation involving them are performed in card;  The device does not become a threat for the customer system as data required for authentication remain in the smartcard, not accessible to the attacker. The attacker may not enter the customer system by authenticating as the user he compromised. Usage of the TOE in the Gateway for authentication purposes provides the following advantages in case of Gateway compromise:  The attacker may not authenticate as a valid Gateway as authentication private keys are stored by the card and are not extractable;  The Cryptosmart authentication protocol involves symmetric secrets as a second security layer over the asymmetric one. Smartcard usage allows protecting these secrets. Otherwise they would have been stored readable on the Gateway. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 12/92 2.3 TOE DESCRIPTION 2.3.1 USAGE OF THE TOE The Cryptosmart card is delivered to customers in a state in which no key is installed. An administrator is in charge of personalizing it for each user. Card personalization is done by using a software tool called card admin station provided by Ercom which exists in two versions:  A command line version allowing automation of the personalization process;  A graphical version allowing card by card personalization. The personalization process consists in providing to the smartcard its cryptographic keys and certificates. Cryptographic keys may either be  Generated inside the smartcard allowing an extremely secure configuration as these keys may never be extracted outside the smartcard;  Imported inside the smartcard. This latter case reaches the same security as the first if the customer’s information system stores imported keys in a secure way. It allows a more flexible management of the cards: a card containing the same keys can be generated. It allows card replacement without interrupting the services offered by the smartcard. Card personalization requires usage of an external PKI to generate the user certificate on which distant user authentication relies. As other keys, the corresponding private key may be either generated internally to the smartcard or externally by customer’s PKI. During card personalization, the administrator also:  Sets a minimal security code length and a default code. The TOE user can change this code. This minimal security length for security codes must be comprised between 4 and 8, or be 0 to avoid usage of a user security code. This must be set at card creation, and a user won’t be able to reduce the initial code length.  Asks for PUK code creation: the TOE generates 15 PUK codes and exports them. PUK codes may never be exported afterward. PUK codes have a length of 8 digits.  Generates and injects a recycle code.  Inject cryptographic keys inside the smartcard which are: o The family key which is a key shared by every card of a family. (note: an administrator may administrate several families); o The wrapping key. The wrapping key may also be generated internally to the smartcard. o The local encryption master keys. o The APDU encryption initialization key o The user authentication key and corresponding certificate (used in Cryptosmart authentication protocol)  Sets the card type (user card or gateway card) PUK codes are used for unlocking the smartcard in case the user blocks his card by entering wrong security codes. The family key is derived into an identity protection key used during Cryptosmart authentication protocol run. The wrapping key is a key divided into an encryption key and an integrity key. These key are used to export keys negotiated by the Cryptosmart authentication protocol to the host while protected from disclosure and modification. The local encryption key is a key which may never be extracted from the TOE but may be derived into several keys. Those derived keys are exported to the host. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 13/92 The card type defines user cards and gateway card. Gateway cards have the same functionalities as user cards but are optimized to be used on a server. This is useful in the case if the TOE is used in standalone appliances where cryptographic operation shall be performed without user interaction. A specific command ends the personalization process: from now the card only allows key generation or import for PKCS#11 functions. The keys injected by the administrator (APDU encryption initialization key and user authentication key) can neither be changed by the user nor be reached directly by the user (he may only use them). The card is in a state where it can be delivered to the user. When a user receives its smartcard he should change the default security code set by the administrator. He may use any functionality of the smartcard described hereafter. The user may block his smartcard by entering a wrong security code several times (only 2 successive failures are authorized. The third failure blocks the card). The card can be unblocked by entering a PUK code (which has been generated during the personalization process). The card status contains the current PUK code number to use. To unblock the card the user shall enter this precise PUK code (entering another PUK code even generated by the TOE during personalization will not unblock the card and count as failure). After 10 unsuccessful PUK code entries the whole content of the card but the recycle code is wiped. The card may only be recycled. Once entered successfully a PUK code unblock the card and cannot be used again (the current PUK code number is increased). If the user blocks the card and no PUK code are available the card content is wiped. The user unlocks the card by entering his security code. He may explicitly lock the smartcard by logging off. Once the smartcard unlocked the user may use any functionality described § 2.1. As the user certificate has a limited validity date, the smartcard has the same validity date. At this date the user shall receive a new smartcard. Continuity of cryptographic services which do not involve this certificate is ensured by personalizing both cards with the same keyset. The old card shall then be recycled by using the recycle code. Card recycling erases any data contained in the card and returns it in the same state as it was at the time of delivery to customer. This card may be re- personalized for another user. 2.3.2 TOE FUNCTIONALITIES This part describes the services that the TOE offers to its users. These services are:  User authentication;  Cryptosmart authentication protocol run;  Cryptosmart “stateless” authentication protocol run;  Signature generation (both symmetric and asymmetric);  Encryption (AES) and decryption (AES and RSA);  External key storage;  Key generation;  Local protection key obtention  User data storage  Key or user data export. The TOE offers also an interface for the host to get TOE status which contains the current card state, the serial number, current security code entry failures and other information about the TOE. Note:the symmetric signature generation servicesare not included in the TOE. USER AUTHENTICATION Each TOE user possesses a 4 to 8 digits security code. The TOE authenticates its user by confronting the security code given by the user to the value it stores. A successful authentication unlocks the card functionalities and allows the user to perform cryptographic operations. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 14/92 After 3 security code entry failures the TOE is locked in a “BLOCKED” state and may only be unblocked by a correct PUK code entry or erased and reset by a correct recycle code entry. PUK codes also allow authenticating the user. Anyway PUK code entry is forbidden in any state other than BLOCKED. SECURITY CODE CHANGE The TOE allows the user to change its security code. This can only be done if the user has previously authenticated himself to the TOE. Security code choice is free to the user with the only limitation that its length shall be comprised between the lower bound set by the administrator and 8. KEY NEGOTIATION (CRYPTOSMART AUTHENTICATION) To establish a secure channel between two devices hosting a Cryptosmart card, the smartcard performs:  The mutual authentication of both components.  The negotiation of a session key which will be derived into cryptographic parameters and keys. The authentication of the distant user is based on standard X.509 certificates. This key negotiation is based on a DH based security proven authentication protocol. The Cryptosmart card provides two implementations of the authentication protocol: One is statefull for being used in a connected mode, the other one is stateless for being used in an asynchronous mode. Keys negotiated during the authentication protocol are exported under a wrapped form: protected both in confidentiality and integrity. They must be derived to get keys shared between both devices. The Cryptosmart card wrapping method in version 5.1 is different from the 5.0 version. A compatibility mode is provided. This mode shall be deactivated for being in the evaluated configuration. KEY PROTECTION The TOE offers keys storage capabilities for external application (Cryptosmart suite, S/MIME application, third party local encryption software, etc.) and for PKCS#11 purposes. A user may generate cryptographic key through the Cryptosmart card. He can store cryptographic keys inside the smartcard. The TOE protects these keys by conditioning their access to the user authentication. Keys stored may be either RSA keys with a 2048 bits length or 256 bits symmetric keys. Both types of keys may be extractable or not. A user can never have access to the value of non extractable keys. He can only use them to perform cryptographic operation. Symmetric keys have a key usage attribute which defines if the key may be used for encryption, signature or both usages. KEY DERIVATION Key derivation is performed inside the smartcard. This allows the master session key (negotiated during the authentication protocol) to remain unexposed even to the legitimate user. The derivation process also derives a fresh key from the input, returned under a wrapped form. RSA SIGNATURE The TOE allows the user to sign buffers using RSA with a PKCS#1.5 padding scheme. The signature private key is one of the RSA keys stored internally. Note: the TOE only performs operation with private key. Public key operation (RSA signature verification) is performed by the host. RSA DECRYPTION The TOE allows the user to decrypt buffers using RSA with a PKCS#1.5 or OAEP padding scheme. The signature private key is one of the RSA keys stored internally. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 15/92 Note: the TOE only performs operation with private key. Public key operation (RSA encryption) is performed by the host. HMAC-SHA256 SIGNATURE/ VERIFICATION The TOE allows the user to sign buffers or verify buffer signature using SHA256 in HMAC mode. The signature key is one of the symmetric keys stored internally. This feature is excluded from the evaluated configuration. AES ENCRYPTION / DECRYPTION The TOE allows buffer encryption or decryption using AES in ECB or CBC mode. The key is one of the symmetric keys stored internally. By default symmetric keys have a “disable security check” attribute set to false: each symmetric key is limited to perform 150 block operation (encryption and decryption). This check can be disabled at key creation. Remark: RSA, AES and HMAC operation offer PKCS#11 functionalities. The related key management is provided by the TOE. A user can generate, import cryptographic keys, set their extractable attribute. An administrator can also generate or import cryptographic keys and set their extractable attributes during the certification process. In this case the user will be able to manage these keys just as if they were imported by him. LOCAL PROTECTION KEYS OBTENTION The TOE has 2 “local protection master keys”, which are not extractable. The TOE allows deriving these keys for the user to obtain 256 bits keys which may be used for local protection. RANDOM NUMBER GENERATION The TOE allows random number generation using the card processor true random generator which is post- processed by a cryptographic deterministic random number generator. WIPE ORDER The TOE allows the user to send it a wipe command. This command erases every secret contained inside the TOE: the TOE has the same content as when it was delivered to the customer. The only commands allowed in this state are to get the card status and to recycle the card, to be able to reuse it. 2.3.3 TOE ADDITIONAL FEATURES This part describes some features of the TOE independent from user actions. APDU ENCRYPTION Because an attacker has the possibility to listen to the communication channel between the TOE and the host, the TOE implements an encryption mechanism which protects this channel. All sensitive command and associated answer is sent encrypted. Security code entries, PUK unlock commands, and every other command sent when the user has authenticated to the TOE is sent protected in confidentiality. The encryption mechanism provides the following protection to communication between the TOE and the host:  Protection in confidentiality through AES encryption;  Protection in integrity through symmetric signature (retail AES-CBC mac, also called EMAC): any command modified by an attacker is detected and rejected;  Protection against replay: an attacker can’t replay an encrypted command he previously intercepted. POWER CONSUMPTION MANAGEMENT The TOE implements functions to efficiently manage power consumption. The TOE is a smartcard which must be powered on to perform its operations. If unpowered, the user shall re-authenticate to be able to use it. The TOE implements an ephemeral security code mechanism to manage these re-authentications. Once the user is authenticated, the TOE generates an ephemeral security code at random and sends it to the host. This ephemeral security code is managed by the TOE driver on the host. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 16/92 The TOE driver uses it to automatically re-authenticate the user after a TOE power off. The user has no action to perform by himself: the loss of power becomes transparent. When the host device is locked by the user, the driver erases the ephemeral security code from its memory forbidding its compromise by an attacker. If authentication using this ephemeral code fails, the TOE erases the ephemeral code it stores and returns with error. “LIGHT” UNLOCK When the host device has been locked, some software shall be able to perform cryptographic operations in background. To handle this case the TOE has a special state called RESUMED_USER. In this state the user has a limited access to the TOE. Some PKCS #11 operations are forbidden: each key has a user defined “useable in resumed” attribute. If this attribute is set to false, any command using the corresponding key is forbidden (as if the TOE was locked). The TOE may reach the RESUMED_USER after a power loss by sending a dedicated correctly encrypted command. The fact that this command is correctly encrypted implicitly authenticates the user as:  The symmetric signature of the APDU encryption mechanism proves that the driver possesses the correct encryption key  The driver may possess the correct encryption key if and only if the user already successfully authenticated to the TOE. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 17/92 2.3.4 TOE LIFE CYCLE This part describes the different states of the TOE, with the corresponding possible transitions. Customer Smard card Manufacturer Ercom NOT_INSTALLED UNVALIDATED_USER BLOCKED_USER VALIDATED_USER RESUMABLE Serial number Security code OK Security code Blocked Resume OK PUK OK PERSONALIZATION User key injection Power off Card recycle PRE-PERSONALIZATION Applet installation RESUMED_USER Log off Power off Security code OK WIPED PUK code blocked Wipe order Ephemeral security code OK Delivery to customer Figure 2: Cryptosmart card life cycle Cryptosmart cards consist of a Cryptosmart Java applet installed on a Javacard platform compatible with Javacard 2.2.2 and Global Platform 2.2. Cryptosmart cards can be in one of the states described in Figure 1. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 18/92 Life Cycle State Comment NOT_INSTALLED Card delivered by the card manufacturer to ERCOM. This state is never seen by the end customer. PRE-PERSONALIZATION Card with Cryptosmart applet loaded. PERSONALIZATION Card with Cryptosmart applet and serial number loaded. This is the way the card is initially provided to the customer. UNVALIDATED_USER Card state when the card contains its keys. The card is not Security Code unlocked. VALIDATED_USER Card unlocked with validated Security Code or ephemeral security code. RESUMABLE Card after a card reset from a validated user state RESUMED_USER Card after a successful resume command from RESUMABLE state BLOCKED_USER Card blocked after repeated Security Code errors. WIPED Card with every keys erased Table 1 : Cryptosmart card life states NOT_INSTALLED AND PRE-PERSONALIZATION These states are the smartcard states through which the TOE passes before being delivered to the user. During these states Ercom:  Inserts the applet inside the card;  Inserts the card serial number;  Configures card functionalities;  Inserts delivery information;  Deactivates the javacard Card Manager to forbid any subsequent applet loading or erasing. At the end of this phase the TOE is delivered to the customer. PERSONALIZATION The Cryptosmart card is in this state when delivered to the customer. This state allows card personalization i.e.:  User key pair generation or import  User symmetric key generation or import  User certificate import  PUK codes generation  Family key insertion  Recycle code insertion  Security code and its properties insertion Only a subset of the functions of the TOE is accessible in this state. Personalization operations can be performed using the card-admin station which also allows management of the cards. Once every user keys have been inserted, the card may get into the UNVALIDATED_USER state. This state transition is explicitly ordered by a call to the function “create card”. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 19/92 UNVALIDATED_USER The smartcard is in this state when no security code has been successfully entered inside one session. This state allows access only to the functions:  Get card information;  Initialize the APDU encryption;  User authentication;  Wipe the card;  Card recycle. Once the security code has been successfully entered, the card shall get into the VALIDATED_USER state. If the maximum security code entry attempt has been reached, the card shall get into the BLOCKED_USER state. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. A wipe order turns the card into a WIPED state. VALIDATED_USER In this state, every user function is accessible. The VALIDATED_USER state corresponds to the operational state: a fully personalized card, with the user security code successfully entered. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. After a log off, the card gets into an UNVALIDATED_USER state. After a card reset (power off), the card gets into a RESUMABLE state if allowed by configuration. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. A wipe order turns the card into a WIPED state. RESUMABLE This state allows every one of the following actions and no other:  Get card information  Enter the security code  Wipe the card;  Resume command  Log off Once the security code has been successfully entered, the card shall get into the VALIDATED_USER state. If the resume command is successful and contains the ephemeral security code, the card shall get into the VALIDATED_USER state. After too many unsuccessful security code entries, the card shall get into a BLOCKED_USER state. If the resume command is successful without the ephemeral security code, the card shall get into the RESUMED_USER state. If the resume command is unsuccessful, the card shall get into the UNVALIDATED_USER state. After a log off command, the card must get into the UNVALIDATED_USER state. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. A wipe order turns the card into a WIPED state. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 20/92 RESUMED_USER The smartcard is in this state when a successful resume without ephemeral security command has been sent to the card from the RESUMABLE state. This state allows only a restricted usage of the TOE:  The authentication protocol and the derivation function are accessible  Usage of the Cryptosmart card as a cryptographic token is allowed, but the usage of some keys in this state may be forbidden by the user Once the security code has been successfully entered, the card shall get into the VALIDATED_USER state. After too many unsuccessful security code entries, the card shall get into a BLOCKED_USER state. After a log off command the card must get into the UNVALIDATED_USER state. After a card reset, the card shall get into a RESUMABLE state. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. A wipe order turns the card into a WIPED state. BLOCKED_USER The card is in this state once the maximum security code entry has been reached. The card shall refuse any command except a PUK code entry or commands to get the card status. This state allows every one of the following actions, and no other:  Get card information  Enter PUK code After a successful PUK code entry, the card shall get into a VALIDATED_USER state. After 10 successive wrong PUK code entries, the card shall get into a WIPED state. If no PUK code is available the card shall immediately get into a WIPED state. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. A wipe order turns the card into a WIPED state. WIPED The card is in this state once the PUK code entry maximum attempts number has been reached; or the card has received a “wipe” order. The card shall refuse any command except a recycle or a get card status command. In this state every customer secret has been erased except the recycle key. After a successful recycle code entry, the card shall get into a PERSONALIZATION state. 2.3.5 TOE USER The TOE possesses two users. They are identified implicitly depending on TOE state The card administrator is the TOE user while it is in PERSONALIZATION or WIPED states. He performs card personalization actions. In WIPED state the card administrator may recycle the card (using the recycle key). As in these states the commands require no authentication the administrator shall operate the card in a secure environment. The second user is the “local user”. He is the TOE user while it is in UNVALIDATED_USER, VALIDATED_USER, RESUMABLE, RESUMED_USER, or BLOCKED states. 2.3.6 USER CARDS AND GATEWAY CARDS The Cryptosmart card can be personalized into two card types: user cards and gateway cards. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 21/92 Gateway cards are Cryptosmart card intended to be used in a server and may be used heavily. For these reasons, gateway cards differ from user cards by the possibility to reuse the private Diffie-Hellman parameter for Cryptosmartmutual authentication protocol run. Otherwise the card would only offer a limited number of authentications as only a limited write number in EEPROM are allowed. The host has to reset this parameter for the card to use a new one. In the scope of this evaluation we assert that the host sends a commandto renew the private DH parameter after each authentication protocol run. The administrator has also the possibility to set a 0 length security code for Gateway cards. In the scope of this evaluation we assert this is not the case. 2.4 INTEGRATION IN JCS LIFE CYCLE [JCS-PP] describes the life cycle of a javacard system (JCS) as follows: JCS Development Phase 1 Security IC Embedded Software Development Phase 2 Security IC Development Phase 3 Security IC Manufacturing Phase 4 Security IC packaging Phase 5 Composite Product Integration Phase 6 Personalisation Phase 7 Operational Usage JCS Storage, pre-perso, testing JCS Storage, pre-perso, testing JCS Final usage JCS Personalisation JCS Delivery Figure 3: JCS life cycle Phase 1 to phase 5 are performed as described in [IOC7 - ST]. Personalization in phase 6 is decomposed into two parts:  One is performed by Oberthur concerning the personalization of the javacard platform. At the end of this part the card is delivered to Ercom and is inTOE’s NOT_INSTALLED state  One is performed by Ercom by installing the Cryptosmart applet and performing pre-personalization operations. This corresponds to PRE-PERSONALIZATION state of the TOE The delivery point is at the end of phase 6. Phase 7 corresponds to other subsequent states (PERSONALIZATION, UNVALIDATED_USER, VALIDATED_USER, RESUMABLE, RESUMED_USER, BLOCKED_USER and WIPED) of the TOE. 2.5 COMPOSITE TOE SCOPE The TOE to be evaluated is composed of TOE part 1 and TOE part 2. TOE part 1 identifies the platform ID-ONE COSMO V7.0.1 R2 javacard OS on the certified IC. This TOE part includes software (the firmware, the Card Manager and the operating system) embedded on a microcontroller According to [IC_ST] compatible chips are: ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 22/92  NXP P5CD081V1A,  NXP P5CC081V1A. [IC_ST] also mentions NXP P5CD016/021/041/051 which are configuration options present in the IC evaluation, but which are not used for the javacard platform. TOE part 1 is a javacard platform compliant with Java Card 2.2.2and Visa GlobalPlatform 2.2. TOE part 2 identifies the Cryptosmart applet v5.1. This applet is a Java Card application which enables the previously described features. The TOE communicates with a terminal device (for example a PC with a card reader) by APDU messages compliant with the ISO/IEC 7816-4 standard. This terminal device is identified as “the host” in this document. APDU messages may only be transmitted using the contact interface in the evaluated configuration. This means that the contactless interface on the platform must be deactivated. Composite TOE TOE part 1 TOE part 2 P5CD081 V1A or P5CC081 V1A hardware ID-ONE COSMO V7.0.1 R2 javacard OS – Embedded software Cryptosmart applet v5.1 The TOE scope is represented Figure 4. [IOC7-ST] gives full details on TOE part 1 scope. TOE scope TOE part 1 scope P5CD081 V1A or P5CC081 V1A hardware BIOS Resident application Java Card Virtual Machine APIs : Java Card, GP, OP SD TOE part 2 scope Cryptosmart Applet v5.1 CM Figure 4: TOE scope SD and CM are not part of the TOE as CM is deactivated before delivery to customers. The TOE part 1 provides the following services used by TOE part 2:  Security code management and user authentication through the PIN object;  Cryptography services including symmetric encryption and decryption, RSA encryption and decryption, RSA signature and verification and generation of random data;  Physical protection of stored data ensuring their confidentiality and integrity. The TOE part 2 provides the services which will be used by the Cryptosmart user. These services were previously described § 2.2. 2.5.1 TOE PART 2 SCOPE OF EVALUATION The scope of evaluation encompasses all the security features offered by TOE part 2 with the exception of the symmetric and RSA signature service. The evaluated TOE also fixes TOE configuration choices and some constraints on TOE usage which are described in the TOE user guide ([CSMART_USER_GUIDE]). ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 23/92 TOE configuration is performed by Ercom during the PRE-PERSONALIZATION state, where it initializes the internal random generator; inserts the product serial number and creates files which may be used by the customer. The evaluation scope includes any such configuration. In terms of life cycle the evaluated configuration includes every state starting from PERSONALIZATION. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 24/92 3. SECURITY PROBLEM DEFINITION 3.1 ASSETS TO PROTECT This section lists the assets which are security relevant for the TOE. Assets for the TOE are divided into three categories:  Primary assets which are user data from IT environment which shall be protected using the security functions offered by the TOE. This intended protection is addressed by organizational security policies;  Secondary assets which are needed by the TOE to offer its security services. We divide secondary assets into: o User assets: these are data created by or for the user. o TSF assets: these are data created by the TOE or for the TOE internal usage.. 3.1.1 PRIMARY ASSETS D.PLAINTEXT_DATA These are user data which need protection in confidentiality. TOE user uses the TOE to protect them in confidentiality. D.USER_STORED_KEYS These are the RSA or symmetric keys stored by the user inside the TOE. Each of the key is stored with their attributes. The asset includes both the key and attributes. D.USER_STORED_DATA The TOE allows the user to store raw data. This asset represents these data, such as the user certificate. 3.1.2 USER ASSETS D.SESSION_KEYS These are the keys negotiated during the Cryptosmart authentication protocol. These keys are derived into keys which will be used by external application (the Cryptosmart suite for instance). These keys are present in plaintext inside the TOE (when managed by the Cryptosmart applet) or in wrapped form when outside the TOE. D.USER_SIGNATURE_KEY This is the RSA signature key used during the authentication protocol. This key is the private RSA key which public key is contained in the user certificate. It is not extractable. D.USER_AUTH_CODE These are the codes allowing getting the TOE in a VALIDATED_USER state. Authentication codes are:  the security code of the user: it allows to login successfully to the TOE (a TOE state change from UNVALIDATED_USER to VALIDATED_USER);  the PUK codes: it allows to unblock the TOE (a TOE state change from BLOCKED_USER to VALIDATED_USER)  the ephemeral security code: it allows a TOE state change from RESUMABLE to VALIDATED_USER  the recycle code: it allows a TOE state change from any state to PERSONALIZATION 3.1.3 TSF DATA D.TOE_INTERNAL_DATA Internal data are the keys which impact only internal behavior of the TOE. Some of them are inserted in the PERSONALIZATION state. These keys are:  The keys derived from the family key ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 25/92  The wrapping key (includes both encryption and MAC keys)  The APDU initialization key which is an RSA encryption key used to initialize the APDU encryption mechanism. It allows the TOE to exchange APDU encryption keys (D.APDU_KEYS) with the host Some others are generated and stored inside the TOE. These are:  The RNG internal state. D.TOE_INTERNAL_INFORMATION Internal information is data used by the TOE with no need of confidentiality but which shall not be modified. This information is needed for a proper behavior of the TOE and are:  The card state.  The card flags giving information on already performed security initialization function.  The commercial version number of the applet.  The applet source code release identifier.  The build version of the applet.  The applet compilation date.  The card serial number.  The remaining number of times an incorrect Security Code that can be presented before the card is blocked.  The number identifying the current PUK code.  The number of times an incorrect PUK code can be presented before the card is blocked. D.APDU_KEYS These are the APDU encryption and APDU integrity keys. D.APP_CODE The code of the TOE, (TOE part 1 and TOE part 2) 3.1.4 SECURITY NEEDS Asset Confidentiality Integrity Availability D.PLAINTEXT_DATA Yes No No D.USER_STORED_KEYS Yes Yes No D.USER_STORED_DATA Yes Yes No D.SESSION_KEYS Yes Yes No D.USER_SIGNATURE_KEY Yes Yes No D.USER_AUTH_CODE Yes Yes No D.TOE_INTERNAL_DATA Yes Yes No D.TOE_INTERNAL_INFORMATION No Yes No D.APDU_KEYS Yes Yes No D.APP_CODE No Yes No Table 2: Assets security needs 3.2 ASSUMPTIONS A.TRUSTED_ADMIN The smartcard administrator is not careless, willfully negligent or hostile and does not voluntarily disclose data he inserted in the TOE during configuration. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 26/92 A.TRAINED_ADMIN The smartcard administrator is correctly trained to the TOE usage. A.CONFIGURATION The TOE is correctly configured while in PERSONALIZATION state. Configuration is considered correct if:  The signature private key matches the public key contained in the user certificate.  The administrator has correctly set the required security code length. A.KEY_QUALITY Keys generated outside the TOE are of appropriate quality. Appropriate quality may be reached by following the ANSSI rules for key generation from [KEY_ANSSI]. A.SECURE_KEY_MANAGEMENT Some keys are generated outside the TOE and may be stored by the administrator (to recreate a card for the same user). An attacker may not have knowledge of these keys during their generation, transmission to the administrator or by accessing their backup. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 27/92 3.3 THREATS The following threats are adapted from the [PP CM] protection profile: T.TOE_DATA_CORRUPTION A local or distant attacker can modify the user keys, user data or TSF data stored or in use inside the TOE. This may for instance allow the attacker to replace user key by keys he knows or weaken targeted keys. A consequence of this threat is leading to attacks defeating OSP.SYMMETRIC_ENCRYPTION Impacted assets: every identified asset except D.PLAINTEXT_DATA T.TOE_DATA_COMPROMISE A local or distant attacker can obtain the user keys, user data or TSF data stored or in use inside the TOE. A consequence of this threat is leading to attacks defeating OSP.SYMMETRIC_ENCRYPTION Impacted assets: every identified asset except D.PLAINTEXT_DATA T.ABUSE_FUNC An attacker with high attack potential may use TOE functions intended for installation or configuration of the TOE which shall not be used for operational cryptographic keys or user data in order  to disclose or manipulate user data or keys, or  to enable attacks against the integrity or confidentiality of user data or keys by: o manipulating (explore, bypass, deactivate or change) security features or functions of the TOE or o disclosing or manipulating TSF Data.  to enable attacks against the integrity of TOE part 2 code (D.APP_CODE) Impacted assets: every identified asset T.PHYSICAL The attacker discloses or modifies the design of the TOE, its sensitive data or application code by physical (opposed to logical) tampering means. This threat includes failure analysis, electrical probing, unexpected tearing, and DP analysis. This threat is taken from [IOC7 - ST]: the IC must be designed in accordance with a well-defined set of policies and standards (likely specified in another protection profile), and will be tamper resistant to actually prevent an attacker from extracting or altering security data (like cryptographic keys) by using commonly employed techniques (physical probing and sophisticated analysis of the chip). This especially matters to the management (storage and operation) of cryptographic keys. It also refers to all the security aspects related to confidentiality and integrity of code and data. Impacted assets: every identified asset. T.MASQUERADE An attacker with high attack potential may masquerade as an authorized data source or receiver to perform operations that will be attributed to the authorized user or may gain undetected access to cryptographic module causing potential violations of integrity or confidentiality of the user data, the user keys or the TSF data. For instance the attacker can have access or modify the user security code or PUK codes, in order to get illegitimate access to the TOE. Impacted asset: D.USER_AUTH_CODE D.USER_STORED_KEYS D.USER_STORED_DATA D.PLAINTEXT_DATA D.TOE_INTERNAL_DATA This security target also considers the following threats: T.KEY_DERIVE A local or distant attacker with high attack potential is able to compute private key from publicly available data (for instance compute an RSA private key from the corresponding public key, or perform a brute force attack on a symmetric key from known plaintext). ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 28/92 Impacted assets: D.USER_SIGNATURE_KEY D.USER_STORED_KEYS T.INTERFACE_EAVESDROP A local attacker with high attack potential can act on the TOE interfaces in order to  get knowledge of user data or user keys, or  modify user data or user keys when transmitted to the TOE. Impacted assets: D.USER_AUTH_CODE D.USER_STORED_KEYSD.PLAINTEXT_DATA D.USER_STORED_DATA ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 29/92 3.4 OSP This part describes the organizational security policies the TOE shall conform to. We divide these OSP into 3 categories the directives and rules the TOE shall follow; the security policies that TOE usage allows to cover; and OSP which allow reaching the aimed security level. 3.4.1 DIRECTIVES AND RULES OSP.RGS_CRYPTO Cryptographic mechanisms conform to rules and recommendation from [CRYPTO_ANSSI]. Keys are generated with mechanisms conformant to rules and recommendation from [KEY_ANSSI]. 3.4.2 IT SECURITY POLICY OSP.MUTUAL_AUTHENTICATION The TOE shall allow to authenticate remote users and to negotiate a shared secret key. The TOE shall forbid an attacker with high attack potential to cause the TOE to run successfully the Cryptosmart authentication protocol by forging or replaying authentication packets. (The attacker’s goal is to be falsely authenticated by the TOE which could lead to the possibility of man in the middle attacks) OSP.KEY_STORAGE The TOE shall allow storage of cryptographic keys in such a way they are protected from modification or disclosure. OSP.SYMMETRIC_ENCRYPTION The TOE shall allow protecting the confidentiality of information represented by user data which may get known by an attacker using a symmetric encryption algorithm. OSP.RSA_PRIVATE_KEY_OPERATION The TOE shall allow performing the following operation using an RSA private key:  RSA signature with PKCS#1.5 padding  RSA decryption with PKCS#1.5 or PKCS#1.5-OAEP padding 3.4.3 SECURITY ENSURING OSP OSP.LOCAL_AUTHENTICATION Users must be authenticated prior to accessing any controlled TOE resources with the exception of read access to public objects. After a pre-defined authentication failures number, access to controlled resources shall be blocked. Authentication may be performed by:  User entered security code verification;  PUK code verification (only if the TOE is in BLOCKED state)  Automatic authentication by the driver using an ephemeral security code which must have been generated by the TOE;  Implicit authentication by proof of knowledge of secrets for the secure communication channel with the TOE. This last case allows only a limited usage of the TOE. OSP.PUK_UNBLOCK User can unblock access to TOE controlled resources by using a PUK code. Any PUK code may only be used once. After a pre-defined PUK entry failures sensitive data shall be wiped. OSP.DATA_WIPE The TOE provides a way to wipe controlled sensitive assets. OSP.ACCESS_CONTROL The TOE must limit the extent of each user’s abilities to use the TOE functions in accordance with the current TOE authentication state. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 30/92 OSP.TOE_AUDIT The TOE provides an interface to the hosted application, which allows peeking in its internal state. Moreover the TOE informs the host of occurred security events in order for the host to record them in a security journal. Reported security events shall include:  User authentication failure  Mutual authentication and session key establishment faults  Cryptographic errors ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 31/92 4. SECURITY OBJECTIVES 4.1 SECURITY OBJECTIVES FOR THE TOE This section defines the security objectives for the composite TOE. They are satisfied either by technical countermeasure implemented by the Cryptosmart applet, by the platform or by a combination of the two. O.USER_AUTHENTICATION The TOE shall authenticate the user before providing access to any controlled resources with the exception of read access to card state or APDU encryption initialization. Authentication shall be performed by:  User entered security code verification;  PUK code verification (only if the TOE is in BLOCKED state)  Automatic authentication by the driver using an ephemeral security code which must have been generated by the TOE;  Implicit authentication by proof of knowledge of secrets for the secure communication channel with the TOE. This last case allows only a limited usage of the TOE. This objective does not apply to TOE administrator which may only use the TOE in PERSONALIZATION state. O.PUK_UNBLOCK When in BLOCKED state the TOE shall allow the user to unblock it by usage of a PUK code. PUK codes must have been generated by the TOE. Each PUK code may only be successfully used once. O.STRONG_SECCODE The TOE shall restrict the choice of the user security code according to administrator defined minimum length. The TOE shall restrict PUK codes and ephemeral security codes to TOE generated secrets. O.LIMITED_AUTH_NUMBER The TOE shall go in BLOCKED state after 3 successive failed security code entries. The TOE shall go in WIPED state after 10 failed PUK code entries. The TOE shall manage only 15 PUK codes. When the card is blocked and no PUK codes are available the TOE shall go in WIPED state. O.FUNCTION_ACCESS_CONTROL The TOE shall restrict the access to its services, depending on the TOE state and the services explicitly assigned to this state. Assignment of services to state shall be done by default and may not be changed. O.CRYPTOGRAPHIC_OPERATION The TOE shall ensure the cryptographic quality of random number generation.For instance random numbers shall not be predictable and shall have sufficient entropy. The TOE shall perform valid AES encryption and decryption, MAC signature, RSA signature and decryption. O.STRONG_MUTUAL_AUTHENTICATION The TOE shall provide cryptographic functions to authenticate remote users and to negotiate a shared secret key. The TOE shall make impossible for an online attacker to get knowledge of the session key negotiated with the remote card whose identifier is furnished by the TOE, even if he later acquires knowledge of ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 32/92 the private RSA keys of both cards and if he has intercepted all the flows between cards of the same family before and after the session. An online attacker must be unable to cause the TOE to run successfully the authentication protocol without a valid certificate (even without getting knowledge of the negotiated key). O.KEY_MANAGEMENT The TOE shall provide a means to securely manage and store user keys (D.USER_STORED_KEYS and D.USER_SIGNATURE_KEY). This concerns the correct generation, access and destruction of cryptographic keys. This includes:  Keys shall be generated in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes;  The TOE shall be able to import and store user keys;  User keys shall be associated with security attributes. Assignment of security attribute to a key shall be done by explicit action of the TOE administrator or TOE user or by default.  User may only change security attributes to more restrictive values  The TOE shall restrict the access to the user keys according to their security attributes and the TOE state.  Keys shall be destroyed in accordance with specified cryptographic key destruction methods. O.PROTECT_SESSION_KEY The TOE shall make impossible for an attacker to recover session keys (D.SESSION_KEYS) when stored by the host. The TOE shall make impossible for an attacker to modify session keys when stored by the host without detection. O.APDU_ENCRYPTION The TOE shall provide an encryption mechanism to protect the confidentiality and integrity of commands to and responses from the TOE. The TOE shall encrypt every response when in VALIDATED_USER, RESUMABLE or RESUMED_USER state if the command was sent encrypted with the exception of mutual authentication packets. In VALIDATED_USER, RESUMABLE or RESUMED_USER state every command sent in plaintext shall be refused; with the exception of read access to card state or APDU encryption initialization. O.SENSITIVE_MEMORY_ERASING The TOE shall erase by zeroization sensitive assets that are not currently in use:  session key after usage;  security code when card is blocked;  ephemeral security code on ephemeral security code entry error;  PUK code after usage O.WIPE The TOE shall be able to wipe every personalization data (except the recycle key) and user keys. Wipe shall be initiated:  On user request, or  When the PUK codes tries limits is reached, or  When the TOE has no available PUK code and the security code tries limit has been reached. SECURITY OBJECTIVES FROM THE PLATFORM Some threats defined in this security target are covered totally or partially by security objectives from the javacard platform. These security objectives are: O.EMSEC The TOE shall control the production of intelligible emanations within specified limits ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 33/92 O.TAMPER_DETECTION The TOE provides system features that detect physical tampering of a system component, and use those features to limit security breaches O.TAMPER_RESISTANCE The TOE prevents or resists physical tampering with specified system devices and components. 4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT OE.ADMIN The card administrator shall not be careless, willfully negligent, or hostile, and shall follow the instructions provided by the administrator documentation. OE.CARD_ADMIN_STATION The card admin station must check the consistency of data injected inside the TOE in PERSONALIZATION state. OE.KEY_GENERATOR The keys injected inside the TOE must have been generated by a key generator which mechanisms conform to rules and recommendation from [KEY_ANSSI]. OE.SECURE_PERSONALIZATION The TOE personalization (injection of user keys, user certificate, recycle key and family key) must be performed in an environment not accessible physically or remotely by an attacker. OE.SECURE_KEY_MANAGEMENT Externally generated TOE sensitive data (such as user keys, user certificate, family key, recycle key, etc.) must be transmitted to the card administrator in a secure way, and stored in an environment not accessible physically or remotely by an attacker. OE.SECURE_SECCODE_ENTRY The user enters or changes his security code only in a safe environment, with no one able to see the security code. In case of compromising suspicion, the user changes its code immediately. OE.NON_TRIVIAL_SECCODE The user security code shall be non-guessable (i.e. different from “0000”, “1234” or analog values). The TOE administrator shall have set a strictly positive minimal length for the user security code. OE.HOST_CORRECT_BEHAVIOR The host behaves as expected. In particular:  while running the Cryptosmart authentication protocols it correctly verifies that the distant certificate is valid and bound to the expected distant user’s identity;  while running the stateless Cryptosmart authentication protocol it correctly manages the exported TOE state  it does not leak the APDU encryption key. Moreover the host shall detect and inform the user when the APDU encryption initialization key has changed. OE.HOST_AUDIT The host records in a security journal occurred security events such as:  User authentication failure  Mutual authentication and session key establishment faults  Cryptographic errors This journal is generated from error codes returned by the TOE. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 34/92 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 35/92 5. SECURITY REQUIREMENTS This section defines the security requirements satisfied by the TOE. The SFR are grouped under the security objective they cover. First are presented the SFR directly enforcing the security objective, then the dependencies of these SFR. SFR which are dependencies for several other SFRs are grouped together § 5.2.13. 5.1 EXTENDED FAMILY 5.1.1 DEFINITION OF FPT_EMSEC The sensitive family FPT_EMSEC (TOE Emanation) of the Class FPT (Protection of the TSF) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against the TOE and other secret data where the attack is based on external observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This family describes the functional requirements for the limitation of intelligible emanations which are not directly addressed by any other component of CC part 2. The family “TOE Emanation (FPT_EMSEC)” is specified as follows. Family behaviour This family defines requirements to mitigate intelligible emanations. Component levelling: FPT_EMSEC TOE emanation 1 FPT_EMSEC.1 TOE emanation has two constituents: FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF data or user data. FPT_EMSEC.1.2 Interface Emanation requires to not emit interface emanation enabling access to TSF data or user data. Management: FPT_EMSEC.1 There are no management activities foreseen. Audit: FPT_EMSEC.1 There are no actions defined to be auditable. FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 36/92 5.2 SECURITY FUNCTIONAL REQUIREMENTS 5.2.1 O.USER_AUTHENTICATION ENFORCING SFR USER ATTRIBUTE DEFINITION (FIA_ATD) FIA_ATD.1 User attribute definition Hierarchical to: No other components. Dependencies: No dependencies. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users:[  security code;  security code failed entries counter;  user security code block flag;  PUK code number;  PUK code failed entries counter;  authenticated state (not authenticated, authenticated or light authenticated) ;  ephemeral security code; ]. USER AUTHENTICATION (FIA_UAU) FIA_UAU.1 Timing of authentication Hierarchical to: No other components. Dependencies:  FIA_UID.1 Timing of identification FIA_UAU.1.1 The TSF shall allow [  Get card information;  Enter the security code;  Card recycling;  Card wiping;  Initializing the APDU encryption key;  Renew the APDU encryption IV;  Usage of the TOE if it is in the PRE-PERSONALIZATION state  Usage of the TOE if it is in the PERSONALIZATION state ] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 37/92 FIA_UAU.5 Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1 The TSF shall provide [  Authentication through security code presentation  Authentication through ephemeral security code presentation  Authentication through PUK code presentation  Light authentication by successful usage of the trusted channel with the resume command ] to support user authentication FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the[current TOE state and expected TOE state after authentication :  From UNVALIDATED_USER, RESUMABLE or RESUMED_USER to VALIDATED_USER state by using “Authentication through security code presentation”  From RESUMABLE to VALIDATED_USER state by using “Authentication through ephemeral security code presentation”  From BLOCKED to VALIDATED_USER state by using “Authentication through PUK code presentation”  From RESUMABLE to RESUMED_USER state by using “Light authentication by successful usage of the trusted channel with the resume command” ]. 5.2.2 O.PUK_UNBLOCK ENFORCING SFR This objective is handled by the “FIA_UAU.5 Multiple authentication mechanisms”: the TOE is unblocked by authentication by PUK codes. This last SFR ensures PUK codes may only be used once: USER AUTHENTICATION (FIA_UAU) FIA_UAU.4 Single-use authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [authentication through PUK code presentation]. 5.2.3 O.STRONG_SECCODE ENFORCING SFR SPECIFICATION OF SECRETS (FIA_SOS) FIA_SOS.1 Verification of secrets Hierarchical to: No other components. Dependencies: No dependencies. FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [secret’slength requirements]. Application note: user security code must have a length comprised between 4 and 8 characters. In PERSONALIZATIONstate, the minimum security code length may have been set to a value greater than 4 by ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 38/92 the administrator. The security code may have a 0 length. This last case is explicitly excluded from the evaluation. FIA_SOS.2 TSF Generation of secrets Hierarchical to: No other components. Dependencies: No dependencies. FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet [indistinguishability from random and length requirement]. FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for [  Authentication through ephemeral security code presentation  Authentication through PUK code presentation ]. Application note:  The length requirement for ephemeral security code is fixed to 8 bytes and may not be changed.  The length requirement for PUK code is fixed to 8 digits and may not be changed ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 39/92 5.2.4 O.LIMITED_AUTH_NUMBER ENFORCING SFR AUTHENTICATION FAILURES (FIA_AFL) FIA_AFL.1 Authentication failure handling Hierarchical to: No other components. Dependencies:  FIA_UAU.1 Timing of authentication FIA_AFL.1.1/userSC The TSF shall detect when [3] unsuccessful authentication attempts occur related to [user authentication by security code]. FIA_AFL.1.2/userSC When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [  turn the TOE to the BLOCKED state if a PUK code is available  turn the TOE to the WIPED state if no PUK code are available ]. FIA_AFL.1.1/ephSC The TSF shall detect when [1] unsuccessful authentication attempts occur related to [user authentication by ephemeral security code]. FIA_AFL.1.2/ephSC When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [wipe the stored ephemeral security code]. FIA_AFL.1.1/PUK The TSF shall detect when [10] unsuccessful authentication attempts occur related to [user authentication by PUK code]. FIA_AFL.1.2/PUK When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [turn the TOE to the WIPED state]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 40/92 5.2.5 O.FUNCTION_ACCESS_CONTROL ENFORCING SFR The TOE checks access rights for every command based on its current state. This part aims at defining the SFP which has this effect. ACCESS CONTROL POLICY (FDP_ACC) FDP_ACC.2/access Complete access control Hierarchical to:  FDP_ACC.1 Subset access control Dependencies:  FDP_ACF.1 Security attribute based access control FDP_ACC.2.1/access The TSF shall enforce the [SFP_OPERATION_ACCESS_CONTROL access control SFP] on [ subject: local user, administrator; objects:TOE part 2] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2/access 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. The subject (the local user or administrator) operates (sends a command) an object (the Cryptosmart applet, i.e. TOE part 2). There is only one possible operation between TOE part 2 and the local user or administrator which is sending a command as an APDU. EachCryptosmart command possesses an attribute per TOE state which is a Boolean representing its authorization for this state. This SFP aims at verifying whether the operation is authorized or not based on the command function identifier and the TOE state. ACCESS CONTROL FUNCTIONS (FDP_ACF) FDP_ACF.1/access Security attribute based access control Hierarchical to: No other components. Dependencies:  FDP_ACC.1 Subset access control  FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/access The TSF shall enforce the [SFP_OPERATION_ACCESS_CONTROL access control SFP] to objects based on the following: [the TOE state and related operation authorization]. FDP_ACF.1.2/access The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [the authorization attribute for the command is set to true for the current TOE state, as stated in Table 3]. FDP_ACF.1.3/access The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [none]. FDP_ACF.1.4/access The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [none]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 41/92 Function identifier Function PP P UU VU R RU B W 0x00 Security code verification X X X X 0x01 Authentication start X X 0x02 Incoming authentication packet processing X X 0x03 Recall X X X X X X X X 0x04 Certificate decoding result transmission X X 0x05 Authentication reset X X 0x06 Key derivation X X 0x07 Continue X X X X X X X X 0x20 Generate Kapdu X X X 0x09 Renew APDU encryption IV X X X 0x0A Resume X 0x0B Log off X X X X X X 0x0C Wipe card X X X X X X 0x0D Enumerate RSA keys X X X 0x0E Import external RSA key X X 0x0F Generate RSA key X X 0x10 Private RSA key export X X 0x11 Delete RSA key X X 0x12 RSA key attributes change X X 0x13 RSA public key export X X X 0x14 Buffer RSA decryption X X X 0x15 Buffer RSA signing without hash X X X 0x16 Renew DH value X 0x17 Get status X X X X X X X X 0x18 Enumerate symmetric keys X X X 0x19 Generate symmetric key X X 0x1A Import symmetric key X X 0x1B Delete symmetric key X X 0x1C Symmetric encryption (AES) X X X 0x1D Symmetric signature (HMAC-SHA256) X X X ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 42/92 Function identifier Function PP P UU VU R RU B W 0x1E Get local encryption key X X 0x1F Symmetric key export X X 0x20 Generate Kapdu X X 0x21 Symmetric key attribute change X X 0x22 Renew ephemeral security code X 0x24 Stateless authentication start X X 0x25 Stateless authentication get certificate keys X X 0x26 Stateless authentication sign X X 0x27 Stateless authentication verify X X 0x28 Fuse CC flag X X X X 0xE0 Create file X 0xE2 Write file X X X X X X X X 0xE3 Read file X X X X X X X X 0xEA Security code change X 0xFA Card recycle X X X X X X X 0xFB Create card X Function identifier Function PP P UU VU R RU B W Table 3: Function access rights This table uses the abbreviation:  PP as PRE-PERSONALIZATION  P as PERSONALIZATION  UU as UNVALIDATED_USER  VU as VALIDATED_USER  R as RESUMABLE  RU as RESUMED_USER  B as BLOCKED  W as WIPED ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 43/92 MANAGEMENT OF SECURITY ATTRIBUTES (FMT_MSA) The security attributes for this policy are fixed and may not be changed: FMT_MSA.3/access Static attribute initialization Hierarchical to: No other components. Dependencies:  FMT_MSA.1 Management of security attributes  FMT_SMR.1 Security roles FMT_MSA.3.1/access The TSF shall enforce the [SFP_OPERATION_ACCESS_CONTROL access control SFP] to provide [fixed] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/access The TSF shall allow the [none] to specify alternative initial values to override the default values when an object or information is created. The “fixed” property for file access authorization means these default values were fixed at compilation time by the applet developer, and may not be changed. FMT_MSA.1/access Management of security attributes 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/access The TSF shall enforce the [SFP_OPERATION_ACCESS_CONTROL access control SFP] to restrict the ability to [modify] the security attributes [state authorization] to [none]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 44/92 5.2.6 O.CRYPTOGRAPHIC_OPERATION ENFORCING SFR CRYPTOGRAPHIC OPERATION (FCS_COP) FCS_COP.1 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/AES The TSF shall perform[Encryption and decryption] in accordance with a specified cryptographic algorithm [AES] and cryptographic key sizes [256 and 128 bits] that meet the following: [FIPS PUB 197] FCS_COP.1.1/SHA256 The TSF shall perform[MessageDigest computation]in accordance with a specified cryptographic algorithm [SHA256] and cryptographic key sizes [none] that meet the following: [FIPS PUB 180-4] FCS_COP.1.1/HMAC The TSF shall perform[MAC generation and verification]in accordance with a specified cryptographic algorithm [HMAC-SHA256] and cryptographic key sizes [256 and 128 bits] that meet the following: [FIPS PUB 198-1] FCS_COP.1.1/EMAC The TSF shall perform[MAC generation and verification]in accordance with a specified cryptographic algorithm [Retailed AES CBC-MAC] and cryptographic key sizes [256 bits] that meet the following: [none] FCS_COP.1.1/RSA_sig The TSF shall perform[signature] in accordance with a specified cryptographic algorithm [RSA] and cryptographic key sizes [2048 bits] that meet the following: [PKCS #1 v2.1] FCS_COP.1.1/RSA_enc The TSF shall perform[decryption] in accordance with a specified cryptographic algorithm [RSA] and cryptographic key sizes [2048 bits] that meet the following: [PKCS #1 v2.1] FCS_COP.1.1/random The TSF shall perform[random number generation] in accordance with a specified cryptographic algorithm [True random generator post-processed with AES] and cryptographic key sizes [128 bits] that meet the following: [none] FCS_COP.1.1/DH The TSF shall perform[key agreement] in accordance with a specified cryptographic algorithm [Diffie-Hellman] and cryptographic key sizes [2048 bits] that meet the following: [PKCS #3] 5.2.7 O.STRONG_MUTUAL_AUTHENTICATION ENFORCING SFR The mutual authentication is performed using the Cryptosmart authentication protocol. This protocol is based on the following SFR:  FCS_COP.1.1/random  FCS_COP.1.1/DH  FCS_COP.1.1/RSA_sig  FCS_COP.1.1/HMAC  FCS_COP.1.1/SHA256  FCS_COP.1.1/AES  FCS_COP.1.1/EMAC ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 45/92 5.2.8 O.KEY_MANAGEMENT ENFORCING SFR 5.2.8.1 KEY GENERATION AND IMPORT CRYPTOGRAPHIC KEY MANAGEMENT (FCS_CKM) FCS_CKM.1 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/RSA The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [Javacard API RSA key pair generation] and specified cryptographic key sizes [2048 bits] that meet the following: [none]. FCS_CKM.1.1/random The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [random generation] and specified cryptographic key sizes [128 bits and256 bits] that meet the following: [none]. FCS_CKM.1.1/local_prot The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [hash with constant] and specified cryptographic key sizes [256 bits] that meet the following: [none]. IMPORT FROM OUTSIDE OF THE TOE (FDP_ITC) FDP_ITC.2/keys Import of user data with security attributes 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 basic TSF data consistency FDP_ITC.2.1/keys The TSF shall enforce the [SFP_KEY_ACCESS_CONTROL access control SFP] when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2/keys The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3/keys 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/keys 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/keys The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [none]. Application note: When the administrator imports user keys in the TOE, there is no usage of any trusted path as the security of the communication link is ensured by the environment. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 46/92 5.2.8.2 KEY DESTRUCTION CRYPTOGRAPHIC KEY MANAGEMENT (FCS_CKM) FCS_CKM.4 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/zero The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [zeroization] that meets the following: [none]. FCS_CKM.4.1/java The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [The keys are reset in accordance with [JCAPI] in class Key with the method clearKey()] that meets the following: [JCAPI]. Application note: The SFR FCS_CKM.4.1/java only applies to keys stored in javacard Key objects.The SFR FCS_CKM.4.1/zero applies to keys stored as arrays. 5.2.8.3 SECURITY ATTRIBUTES AND ACCESS CONTROL This section defines a SFP on Ob.USER_STORED_KEYS, Ob.USER_SIGNATURE_KEY and Ob.APDU_INITIALIZATION_KEY objects. These objects are defined as:  Ob.USER_STORED_KEYS corresponds to the D.USER_STORED_KEYS asset  Ob.USER_SIGNATURE_KEYcorresponds to the D.USER_SIGNATURE_KEY asset  Ob.APDU_INITIALIZATION_KEYcorresponds to the APDU initialization key which is part of the D.TOE_INTERNAL_DATA asset These objects have the following attributes considered in this SFP:  Key identifier  Key type (symmetric or RSA)  Useable in resume flag  The “encryption” key usage flag  The “sign” key usage flag  Extractable flag  The “disable security checks” flag  A usage counter Note: for asymmetric keys the key usage, “disable security checks” flags and usage counter are ignored (cf. FDP_ACF.1/keys)and are therefore not implemented. The possible operations on these objects are:  Generation;  Deletion;  Import inside the TOE  Export from the TOE  Encrypt or decrypt  Sign ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 47/92 ACCESS CONTROL POLICY (FDP_ACC) FDP_ACC.2/keys Complete access control Hierarchical to:  FDP_ACC.1 Subset access control Dependencies:  FDP_ACF.1 Security attribute based access control FDP_ACC.2.1/keys The TSF shall enforce the [SFP_KEY_ACCESS_CONTROL access control SFP] on [ subject: local user, administrator; objects:Ob.USER_STORED_KEYS, Ob.USER_SIGNATURE_KEY and Ob.APDU_INITIALIZATION_KEY] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2/keys 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. ACCESS CONTROL FUNCTIONS (FDP_ACF) ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 48/92 FDP_ACF.1/keys Security attribute based access control Hierarchical to: No other components. Dependencies:  FDP_ACC.1 Subset access control  FMT_MSA.3 Static attribute initialization FDP_ACF.1.1/keys The TSF shall enforce the [SFP_KEY_ACCESS_CONTROL access control SFP] to objects based on the following: [TOE state and object attribute]. FDP_ACF.1.2/keys The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [  Generation or import operation are allowed only if no object with same identifier and key type already exists;  Export operation is always denied if the extractable attribute is set to false;  Any operation is always denied if the TOE is in RESUMED_USER state and the “usable in resumed” attribute is set to false;  Local protection key obtention is authorized only if the key type is symmetric and the key identifier attribute is 0 or 1  The encrypt or decrypt operation is authorized only if o The key type is asymmetric and the key identifier attribute is different from 0 or 1, or o The key type is symmetric and the “encryption” key usage attribute is set to true  The sign operation is authorized only if o The key type is asymmetric and the key identifier attribute is different from 0 or 1, or o The key type is symmetric and the “sign” key usage attribute is set to true ] FDP_ACF.1.3/keys The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [none]. FDP_ACF.1.4/keys The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [  The encrypt or decrypt operation is refused if the “disable security checks” key attribute is set to false and the usage counter as reached 10.000 ]. EXPORT FROM THE TOE (FDP_ETC) FDP_ETC.1/keys Export of user data without security attributes Hierarchical to: No other components. Dependencies:  [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_ETC.1.1/keys The TSF shall enforce the [SFP_KEY_ACCESS_CONTROL access control SFP] when exporting user data, controlled under the SFP(s), outside of the TOE. FDP_ETC.1.2/keys The TSF shall export the user data without the user data's associated security attributes MANAGEMENT OF SECURITY ATTRIBUTES (FMT_MSA) ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 49/92 FMT_MSA.1/keys Management of security attributes 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/keys The TSF shall enforce the [SFP_OPERATION_ACCESS_CONTROL access control SFP] to restrict the ability to [modify] the security attributes [Useable in resume, Extractable, “encryption” and “sign” key usage] to [user, administrator]. FMT_MSA.2/keys Secure security attributes Hierarchical to: No other components. Dependencies:  [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]  FMT_MSA.1 Management of security attributes  FMT_SMR.1 Security roles FMT_MSA.2/keys The TSF shall ensure that only secure values are accepted for [Extractable, usable in resumed, “encryption” and “sign” key usage attributes]. Application note: This SFR applies:  On key creation: o For keys with identifier 0 or 1 only fixed values are accepted, i.e. the “extractable”, “encryption” and “sign” key usage attributes must be set to false, and the “usable in resumed” must be set to false for key with identifier 0 and to true for key with identifier 1;  On attribute change: a user shall not be able to change security attributes to less restrictive ones. He cannot change any flags from false to true. It shall be impossible to allow an object to be exported when export was previously forbidden, or to allow performing previously forbidden operation. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 50/92 INTER-TSF TSF DATA CONSISTENCY (FPT_TDC) FPT_TDC.1 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 [  User key attributes ] when shared between the TSF and another trusted IT product. FPT_TDC.1.2 The TSF shall use [  The user key attribute is defined as two bytes: the first represent the key identifier, the second is formed as follows: o Bit number starts at 0 o Bit 1 is 1 if the extractable attribute is true, 0 otherwise o Bit 3 is 1 if the useable in resumed attribute is true, 0 otherwise o Bit 4 is 1 if the encryption attribute is true, 0 otherwise o Bit 5 is 1 if the signature attribute is true, 0 otherwise o Bit 6 is 1 if security checks are disabled, 0 otherwise ] when interpreting the TSF data from another trusted IT product. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 51/92 5.2.9 O.PROTECT_SESSION_KEY ENFORCING SFR Session key are outputted symmetrically wrapped. This is based on already defined SFR FCS_COP.1.1/AES and FCS_COP.1.1/EMAC. Wrapping keys may be either generated internally (FCS_CKM.1.1/random) or imported inside the TOE. The FDP_ITC.2/keys dependency of FCS_COP.1can’t apply as SFP_KEY_ACCESS_CONTROL do not apply to wrapping keys. The following SFR allows fulfilling the dependency for wrapping key import: IMPORT FROM OUTSIDE OF THE TOE (FDP_ITC) FDP_ITC.1/systemkey Import of user data without security attributes Hierarchical to: No other components. Dependencies:  [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]  FMT_MSA.3 Static attribute initialization FDP_ITC.1.1/systemkey The TSF shall enforce the [SFP_OPERATION_ACCESS_CONTROL access control SFPs] when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.1.2/systemkey The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3/systemkey The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [none]. The dependency FMT_MSA.3 will not be fulfilled as the TOE does not define security attribute for wrapping keys: their usage is fully controlled by SFP_OPERATION_ACCESS_CONTROL which provides access control on the functions involving the wrapping key. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 52/92 5.2.10 O.APDU_ENCRYPTION ENFORCING SFR TRUSTED PATH (FTP_TRP) FTP_TRP.1 Trusted path Hierarchical to: No other components. Dependencies: No dependencies. FTP_TRP.1.1 The TSF shall provide a communication path between itself and [local] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from [modification, disclosure and replay]. FTP_TRP.1.2 The TSF shall permit [local users] to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for [  user authentication by security code entry;  card resume command;  Renew APDU encryptionkey  PUK code unlock;  any command and TOE response in VALIDATED_USER, RESUMABLE or RESUMED_USER state, except o get status command o card recycle o Authentication packets transmission (but their responses for the host will be encrypted) o Log off o Wipe order o Continue or recall commands depending on initial command encryption o APDU encryption IV renewal ]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 53/92 5.2.11 O.SENSITIVE_MEMORY_ERASINGENFORCING SFR RESIDUAL INFORMATION PROTECTION (FDP_RIP) FDP_RIP.1 Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1.1/applet The TSF shall ensure that any previous information content of a resource is made unavailable upon the [deallocation of the resource from] the following objects: [  session key  security code  ephemeral code  PUK code ]. FDP_RIP.1.1/APDU The TSF shall ensure that any previous information content of a resource is made unavailable upon the [allocation of the resource to] the following objects: [the APDU Buffer]. FDP_RIP.1.1/TRANSIENT The TSF shall ensure that any previous information content of a resource is made unavailable upon the [deallocation of the resource from] the following objects: [any transient object]. 5.2.12 O.WIPE ENFORCING SFR The wipe action is managed by already defined FCS_CKM.4.1/zero, FCS_CKM.4.1/java and FDP_RIP.1:  User keys are erased using FCS_CKM.4.1/java;  Personalization data are respectively erased by: o Security codes are erased using FDP_RIP.1; o Keys derived from the family key by FCS_CKM.4.1/java o Wrapping keys by FCS_CKM.4.1/java; o Local protection master keys by FCS_CKM.4.1/java Wipe can be initiated:  On user request.  When the PUK codes tries limits is reached, which is handled by FIA_AFL.1/PUK  When the TOE has no available PUK code and the security code tries limit has been reached which is handled by FIA_AFL.1/userSC ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 54/92 5.2.13 O.EMSEC ENFORCING SFR TOE EMANATION (FPT_EMSEC) FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMSEC.1.1 The TOE shall not emit [side channel emission] in excess of [limits specified by the state-of-the-art attacks on smart card IC] enabling access to [D.SESSION_KEYS, D.USER_SIGNATURE_KEY, D.USER_AUTH_CODE, D.TOE_INTERNAL_DATA and D.APDU_KEYS] and [D.USER_STORED_KEYS]. FPT_EMSEC.1.2 The TSF shall ensure [all users] are unable to use the following interface [external contacts emanations] to gain access to [D.SESSION_KEYS, D.USER_SIGNATURE_KEY, D.USER_AUTH_CODE, D.TOE_INTERNAL_DATA and D.APDU_KEYS] and [D.USER_STORED_KEYS]. 5.2.14 O.TAMPER_DETECTION ENFORCING SFR TSF PHYSICAL PROTECTION (FPT_PHP) FPT_PHP.1 Passive detection of physical attack Hierarchical to: No other components. Dependencies: No dependencies. FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred. TSF SELF TEST (FPT_TST) FPT_TST.1 TSF testing Hierarchical to: No other components. Dependencies: No dependencies. FPT_TST.1.1 The TSF shall run a suite of self-tests [during initial start-up and periodically during normal operation] to demonstrate the correct operation of [the TSF]. FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of [TSF data]. FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of [TSF executable code]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 55/92 5.2.15 O.TAMPER_RESISTANCE ENFORCING SFR FAIL SECURE (FPT_FLS) FPT_FLS.1 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: [  those associated to the potential security violations described in FAU_ARP.1 of the underlying javacard open platform,  the object deletion functions fail to delete all the unreferenced objects owned by the applet that requested the execution of the method,  1. Invalid reference exception; 2. Code or data integrity failure; 3. Power loss while processing. 4. worm on or dead EEPROM, full security area, false CRC For each problem the TOE sends a specific exception status or doesn't start]. Application note: Potential security violation described in FAU_ARP.1 are recalled here as described in [IOC7-ST] for convenience:  CAP file inconsistency  Typing error in the operands of a bytecode  Applet life cycle inconsistency  Card tearing (unexpected removal of the Card out of the CAD) and power failure  Abortion of a transaction in an unexpected context (see abortTransaction(), [JCAPI] and [JCRE], §7.6.2)  Violation of the Firewall or JCVM SFPs  Unavailability of resources  Array overflow  Other runtime errors related to applet's failure (like uncaught exceptions) TSF PHYSICAL PROTECTION (FPT_PHP) FPT_PHP.3 Resistance to physical attack Hierarchical to: No other components. Dependencies: No dependencies. FPT_PHP.3.1 The TSF shall resist [changing operational conditions every times: the frequency of the external clock, power supply, and temperature] to the [chip elements] by responding automatically such that the SFRs are always enforced 5.2.16 GENERIC DEPENDENCIES SFR This section groups SFR which are dependencies for different other SFRs. USER IDENTIFICATION (FIA_UID) Application note: as the TOE is single user, user authentication provides identification. Therefore the FIA_UID dependency does not need to be fulfilled. SECURITY MANAGEMENT ROLES (FMT_SMR) FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies:  FIA_UID.1 Timing of identification FMT_SMR.1.1 The TSF shall maintain the roles [local user, administrator]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 56/92 SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF) FMT_SMF.1 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: [  key attribute change;  security code minimum length setting;  TOE personalization (import of cryptographic keys)]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 57/92 5.3 TOE SECURITY ASSURANCE REQUIREMENTS The evaluation target must comply with parts 2 and 3 of the Common Criteria version 3.1 for the EAL4 level, augmented with ALC_DVS.2and AVA_VAN.5. Table 4summarizes the aimed assurance components. Assurance class Assurance component Level Description Development ADV_ARC 1 Security architecture. ADV_FSP 4 Functional specification ADV_IMP 1 Implementation representation ADV_INT N.A. TSF internals ADV_SPM N.A. Security policy modelling ADV_TDS 3 TOE design Guidance documents AGD_OPE 1 Operational user guidance AGD_PRE 1 Preparative procedure Life-cycle support ALC_CMC 4 Configuration Management (CM) Capabilities ALC_CMS 4 CM scope ALC_DEL 1 Delivery ALC_DVS 2 Development security ALC_FLR N.A. Flaw remediation ALC_LCD 1 Life cycle definition ALC_TAT 1 Tools and techniques Security target evaluation ASE_CCL 1 Conformance claims ASE_ECD 1 Extended component definition ASE_INT 1 ST introduction ASE_OBJ 2 Security objectives ASE_REQ 2 Security requirements ASE_SPD 1 Security problem definition ASE_TSS 1 TOE summary specification Tests ATE_COV 2 Coverage ATE_DPT 1 Depth ATE_FUN 1 Functional tests ATE_IND 2 Independent testing Vulnerability assessment AVA_VAN 5 Vulnerability analysis Table 4: Cryptosmart card aimed assurance levels ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 58/92 6. GLOBAL TOE SPECIFICATION This chapter provides the TOE summary specification, a high‐level definition of the security functions claimed to meet the functional and assurance requirements. 6.1 TOE SECURITY FUNCTIONS The TOE security functions include the following:  Identification and authentication (IA): this family includes all functions related to identification and authentication of users and administrators;  Cryptography (CR): this family includes all cryptography related functions;  Protection and filtering (PR): this family includes all functions related to protecting user data;  Security management (GS): this family includes all functions related to managing security policies.  Platform provided security functions (PTF): this family includes all functions entirely managed by the underlying platform. 6.1.1 IDENTIFICATION AND AUTHENTICATION (IA) SF.IA_ROLES The TOE maintains two roles:  The administrator which is the TOE user while in PERSONALIZATION and WIPED states  The local user which is the TOE user while in UNVALIDATED_USER, VALIDATED_USER, RESUMABLE, RESUMED_USER and BLOCKED states. SF.IA_AUTH_PARAMETER The TOE shall maintain the following elements related to its user:  The user security code;  The corresponding failed entries counter;  The user ephemeral security code;  The TOE state which includes the security code validation flag and the light unlock validation flag.  15 PUK codes  The current authorized PUK code SF.IA_SECURITY_CODE The TOE is able to authenticate the local user by a security code. This security code is composed of numeric characters and has a maximum size of 8 characters. After 3 successive failed attempts, the TOE turns into a BLOCKED state. The administrator may fix a minimum length requirement, which is set to 4 by default. The security code must be transmitted to the TOE using the APDU encryption mechanism. SF.IA_PUK_CODE The TOE is able to authenticate the local user by a PUK code. This method of authentication is only available if the TOE is in the BLOCKED state. After 10 failed attempts authentication by PUK code is disabled. The TOE must be recycled. PUK codes are composed of 8 (random) numeric characters generated by the TOE. Already used PUK codes will be refused. The PUK code must be entered using the APDU encryption mechanism. SF.IA_EPHEMERAL_SECURITY_CODE The TOE is able to authenticate the local user by an ephemeral security code. This ephemeral security code is composed of numeric characters and has a size of 8 characters. It is generated by the TOE ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 59/92 after a successful authentication by security code or PUK code. This security code is re-generated after successive successful re-authentication with the security code or at user request. Using a wrong ephemeral security code shall cause the TOE to erase the stored (right) ephemeral security code, which disables this authentication mechanism. Ephemeral security code is composed of 8 (random) numeric characters generated by the TOE when the user has authenticated using his security code or a PUK code.. The ephemeral security code must be entered using the APDU encryption mechanism. SF.IA_LIGHT_AUTH The TOE is able to implicitly authenticate the user by successfully sending a correctly formatted resume command using the APDU encryption mechanism, with a null buffer as ephemeral security code argument. Usage of the APDU encryption mechanism proves knowledge of the 128 bits APDU encryption key. After such light authentication the TOE turns into a RESUMED_USER state which allows limited usage of the TOE. This kind of authentication is only authorized after a successful security code authentication in case of card loss of power. 6.1.2 CRYPTOGRAPHY (CR) SF.CR_STATEFULL_AUTHENTICATION The TOE is able to conduct a session key negotiation phase with another card by using a SIGMA-R like protocol. This protocol allows the negotiation of a common secret with a perfect forward secrecy property and authenticates the distant card user. Unpowering the card does cause the protocol to abort. Once the distant card user has been authenticated and the session key has been generated it is transmitted to the local user under a wrapped form and erased from memory. SF.CR_STATELESS_AUTHENTICATION The TOE is able to conduct a session key negotiation phase with another card by using a SIGMA like protocol. This protocol allows the negotiation of a common secret with a perfect forward secrecy property and authenticates the distant card user.Unpowering the card does not cause the protocol to abort. Once the distant card user has been authenticated and the session key has been generated it is transmitted to the local user under a wrapped form and erased from memory SF.CR_KEY_DERIVATION The TOE is able to derive a cryptographic key into several other keys using a cryptographic key derivation mechanism. Once the derivation succeeded the initial key is updated, transmitted to the local user under a wrapped form with the derived keys (in clear) and every key is erased from memory. SF.CR_LOCAL_PROTECTION_KEY The TOE is able to derive a cryptographic key into several other keys using a cryptographic key derivation mechanism. Once the derivation succeeded the TOE outputs the obtained key to the TOE user. SF.CR_RSA_ENCRYPT The TOE is able to decrypt data using the RSA algorithm with PKCS#1.5 or PKCS#1.5-OAEP padding and 2048 bits keys. SF.CR_RSA_SIGN The TOE is able to sign data using the RSA algorithm with 2048 bits keys and PKCS#1.5 padding without use of any digest algorithm. SF.CR_AES The TOE is able to encrypt and decrypt data using the AES algorithm using 128 or 256 bits keys. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 60/92 SF.CR_MAC The TOE is able to perform MAC using HMAC-SHA256 and 128 or 256 bits keys. The TOE is able to perform MAC using AES in retail CBC MAC mode (EMAC) and 256 bits keys (2*128). SF.CR_RNG The TOE is able to generate random numbers using the platform secure random generator post processed using AES with 128 bits keys. SF.CR_KEY_GENERATION The TOE is able to generate cryptographic keys using the following methods:  RSA keys are generated using the built in javacard generator  Symmetric keys are generated using the TOE random number generator SF.CR_KEY_DESTRUCTION The TOE destroys cryptographic keys by clearing them in memory. 6.1.3 PROTECTION AND FILTERING (PR) SF.PR_ACCESS_RIGHTS The TOE is able to perform access control for each command sent by the user. This is done by confronting the TOE state to:  The command access rights. Access control ensures the local user is authenticated before performing any action except:  Get card information;  Enter the security code;  Card recycling;  Card wiping;  Initializing the APDU encryption key;  Renew the APDU encryption IV; The administrator is not required to be authenticated (the administrator may only use the TOE while in PERSONALIZATION state, and security is ensured by the environment in this state). The command access rights are fixed in TOE code and may not be changed. SF.PR_KEY_ACCESS_CONTROL The TOE is able to perform access control for user keys. This is done by confronting the TOE state to:  The “extractable” and “useable in resumed” key attributes Key identifier, key type, extractable and useable in resumed flags attributes must be set by the user at asset creation. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 61/92 SF.PR_RESIDUAL_WIPE The TOE erases sensitive data when not needed any more (changed security code, after PUK code usage, etc.). SF.PR_APDU The TOE offers a trusted channel where every command sent to the TOE in VALIDATED_USER and RESUMED_USER state can be AES encrypted and AES based MAC sealed using TOE generated keys. Usage of this trusted channel is required for:  initial user authentication;  any command and TOE response in VALIDATED_USER, or RESUMED_USER state, except o response with a “distant card” order or transmission of an authentication packet; o get status command o APDU encryption keys renewal  the “resume” command in RESUMABLE state 6.1.4 SECURITY MANAGEMENT (GS) SF.GS_ADMIN An administrator can perform the following administration operation:  Set the minimum security code length requirements  Set the default user security code  Create the PUK code within the TOE and get them  Import a recycle key  Import the SMS wrapping key  Import, export or generate RSA keys (within the limits of the access control policy)  Import, export or generate symmetric keys (within the limits of the access control policy)  Delete RSA or symmetric keys (within the limits of the access control policy)  Change user key attributes (within the limits of the access control policy) An administrator may not change access rights to TOE functions. Data are imported with security attributes: in case of symmetric or RSA keys attributes are specified by the administrator during their import; other data attributes are statically set when imported. SF.GS_USER A user can perform the following administration operation:  Change its security code  Import, export or generate RSA keys (within the limits of the access control policy)  Import, export or generate symmetric keys (within the limits of the access control policy)  Delete RSA or symmetric keys (within the limits of the access control policy)  Change user key attributes (within the limits of the access control policy) A user may not change access rights to TOE functions. Data are imported with security attributes: symmetric or RSA keys attributes are specified by the user during their import. 6.1.5 PLATFORM PROVIDED SECURITY FUNCTIONS (PTF) SF.PTF_SAFESTATE_MGT This security function performs the following operations:  Monitoring the integrity of the TOE and the TSF data by performing selftests  Ensuring the TOE returns in a safe state when an unexpected event occurs (loss of power, tearing): allsensitive data are erased and the TOE returns in a restrictive and secure state. In case a major error is detected, the security function destroys the TOE. SF.PTF_PHYS This security function ensures ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 62/92  The TOE detects physical manipulation (I/O manipulation, EM perturbation, temperature perturbation) and takes countermeasures.  The TOE is protected against probing and that there is no information leakage that might be used to reconstruct sensitive data In case a major error is detected, the security function destroys the TOE. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 63/92 7. RATIONALES 7.1 SECURITY OBJECTIVES RATIONALE T.TOE_DATA_CORRUPTION T.TOE_DATA_COMPROMISE T.ABUSE_FUNC T.PHYSICAL T.MASQUERADE T.KEY_DERIVE T.INTERFACE_EAVESDROP OSP.RGS_CRYPTO OSP.MUTUAL_AUTHENTICATION OSP.KEY_STORAGE OSP.SYMMETRIC_ENCRYPTION OSP.SYMMETRIC_INTEGRITY OSP.RSA_PRIVATE_KEY_OPERATION OSP.LOCAL_AUTHENTICATION OSP.PUK_UNBLOCK OSP.DATA_WIPE OSP.ACCESS_CONTROL OSP.TOE_AUDIT A.TRUSTED_ADMIN A.TRAINED_ADMIN A.CONFIGURATION O.USER_AUTHENTICATION X X O.PUK_UNBLOCK X O.STRONG_SECCODE X O.LIMITED_AUTH_NUMBER X X O.KEY_MANAGEMENT X X X O.STRONG_MUTUAL_AUTHENTICATION X O.PROTECT_SESSION_KEY X X O.APDU_ENCRYPTION X X X X O.CRYPTOGRAPHIC_OPERATION X X X X X X O.FUNCTION_ACCESS_CONTROL X X X X X X O.WIPE X X O.SENSITIVE_MEMORY_ERASING X O.EMSEC X X X O.TAMPER_DETECTION X X O.TAMPER_RESISTANCE X X X X OE.ADMIN X X X X OE.CARD_ADMIN_STATION X X X OE.KEY_GENERATOR X OE.SECURE_PERSONALIZATION X X X OE.SECURE_KEY_MANAGEMENT X X OE.SECURE_SECCODE_ENTRY X OE.NON_TRIVIAL_SECCODE X OE.HOST_CORRECT_BEHAVIOR X X X OE.HOST_AUDIT X Table 5: Tracing between security objectives and security problem definition ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 64/92 T.TOE_DATA_CORRUPTION This threat is covered by the following security objectives:  O.FUNCTION_ACCESS_CONTROL: ensureswrite access toassets is controlled by the TOE. An attacker may not directly modify them as he must be authenticated to get access to TOE controlled assets;  O.PROTECT_SESSION_KEY: ensures thatmodifications on outputted sessionkeys will be detected;  O.APDU_ENCRYPTION: ensures that an attacker may not alter asset while imported in the TOE by the user;  O.TAMPER_RESISTANCE: ensures an attacker may not modify assets by physical means;  OE.SECURE_PERSONALIZATION: ensures the personalization environment is secure. An attacker may not alter asset while imported in the TOE by the admin;  OE.SECURE_KEY_MANAGEMENT: ensures the key are managed in a secure way while out of TOE scope. An attacker may not alter asset while transmitted from key generator to admin; or alter their stored value;  OE.ADMIN: ensure that the attacker may not be the admin, nor can he corrupt the admin to alter assets;  OE.CARD_ADMIN_STATION: ensures that the assets injected in TOE are consistent (the private key and certificate are correctly related). T.TOE_DATA_COMPROMISE This threat is covered by the following security objectives:  O.FUNCTION_ACCESS_CONTROL: ensuresread access toassets is controlled by the TOE. An attacker may not directly get them as he must be authenticated to get access to TOE controlled assets;  O.PROTECT_SESSION_KEY: ensures outputted sessionkeys are protected from disclosure;  O.APDU_ENCRYPTION: ensures that an attacker may not eavesdrop assets while imported in the TOE by the user;  O.SENSITIVE_MEMORY_ERASING: ensures that an attacker may not recover previously erased sensitive data  O.TAMPER_RESISTANCE: ensures an attacker may not have information on assets by physical means;  O.EMSEC: ensures an attacker may not have information on assets by side channel analysis;  OE.SECURE_PERSONALIZATION: ensures the personalization environment is secure. An attacker may not have knowledge of asset while imported in the TOE by the admin;  OE.SECURE_KEY_MANAGEMENT: ensures the key are managed in a secure way while out of TOE scope. An attacker may not have knowledgeof assets while transmitted from key generator to admin; or while stored for backup;  OE.ADMIN: ensure that the attacker may not be the admin, nor can he corrupt the admin to get assets;  OE.SECURE_SECCODE_ENTRY: ensures that the user security code is not compromised by an attacker while entered;  OE.HOST_CORRECT_BEHAVIOR: ensures that the APDU encryption initialization key is trusted. When changed the user is informed and is in measure to refuse to enter his security code if he did not change his Cryptosmart card.  OE.NON_TRIVIAL_SECCODE: ensures that the user security code is not guessable by an attacker T.ABUSE_FUNC This threat is covered by the following security objectives:  O.FUNCTION_ACCESS_CONTROL: ensures that access to TOE function is controlled by the TOE. Functions for personalization may not be abused as they are only accessible in PERSONALIZATION state, and OE.SECURE_PERSONALIZATION ensures the attacker may not use the TOE. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 65/92 T.PHYSICAL This threat is covered by the following security objectives:  O.TAMPER_DETECTION: ensures that a physical attack is detected (and then appropriate measure can be taken);  O.TAMPER_RESISTANCE: ensures an attacker may not have information on assets by physical means;  O.EMSEC: ensures an attacker may not have information on assets by side channel analysis; T.MASQUERADE This threat is covered by the following security objectives:  O.USER_AUTHENTICATION which states that authorized data sources must be authenticated preventing than attacker to impersonate a legitimate user;  O.APDU_ENCRYPTION which links every command to a previous successful authentication. An attacker may not send commands to the TOE by getting control of the communication link after the user has authenticated to the TOE;  O.KEY_MANAGEMENT and O.FUNCTION_ACCESS_CONTROL which define security attributes based access control. This restricts access to keys according to TOE state and key security attributes (the TOE state is related to the fact that the user is authenticated, and how he had authenticated). T.KEY_DERIVE This threat is covered by the following security objectives:  O.CRYPTOGRAPHIC_OPERATION and OE.KEY_GENERATOR ensure that generated keys have sufficient entropy generated by the TOE or not. The attacker may not bruteforce them.  O.CRYPTOGRAPHIC_OPERATION ensures thatRSA keys are generated using a cryptographically correct algorithm. This prevents the attacker to mount a mathematical attack on these keys. T.INTERFACE_EAVESDROP O.APDU_ENCRYPTION directly covers this threat by protecting the confidentiality of data transmitted by the user to the TOE and reciprocally. OE.HOST_CORRECT_BEHAVIOR covers this threat by ensuring that the APDU encryption initialization key is trusted. When changed the user is informed and is in measure to refuse to enter his security code if he did not change his Cryptosmart card. This avoids the possibility of man in the middle when APDU encryption is initialized. OSP.RGS_CRYPTO The objective O.CRYPTOGRAPHIC_OPERATION ensures thatcryptographic algorithms and key generation algorithms conform to the RGS. OSP.MUTUAL_AUTHENTICATION This OSP is covered by the following security objectives:  O.STRONG_MUTUAL_AUTHENTICATION which directly cover the OSP by providing the possibility for the user to run an authentication protocol;  OE.HOST_CORRECT_BEHAVIOR which ensures that the certificate verification is performed correctly.  OE.CARD_ADMIN_STATION which ensures that assets injected in TOE are consistent (private key and certificate): users are authenticated using the certificate related to the private key used in protocol. (this only allows the protocol to successfully run. Otherwise it would always fail at certificate or signature verification) OSP.KEY_STORAGE This OSP is covered by the following security objectives: ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 66/92  O.KEY_MANAGEMENT and O.FUNCTION_ACCESS_CONTROLwhich enable a strong security attributes based access control  The security objectivesfrom the platform O.TAMPER_DETECTION and O.TAMPER_RESISTANCE which providesphysical protection to stored keys  The security objective from the platform O.EMSEC which ensures keys may not be recovered by side channel analysis OSP.SYMMETRIC_ENCRYPTION The objective O.CRYPTOGRAPHIC_OPERATION directly covers this OSP. OSP.SYMMETRIC_INTEGRITY The objective O.CRYPTOGRAPHIC_OPERATION directly covers this OSP. OSP.RSA_PRIVATE_KEY_OPERATION The objective O.CRYPTOGRAPHIC_OPERATION directly covers this OSP. OSP.LOCAL_AUTHENTICATION The objectiveO.USER_AUTHENTICATIONdirectly answers to the first part of the OSP (the user must be authenticated before performing sensitive action) The objective O.STRONG_SECCODE ensures an attacker may not guess the security code, allowing to falsely authenticating to the TOE The objective O.LIMITED_AUTH_NUMBERdirectly answers to the second part of the OSP concerning authentication error handling. OSP.PUK_UNBLOCK The objective O.PUK_UNBLOCK provides the ability to unblock the TOE The objective O.CRYPTOGRAPHIC_OPERATION ensures an attacker may not guess PUK code as they are TOE generated The objectives O.LIMITED_AUTH_NUMBER and O.WIPE directly answer to the second part of the OSP concerning PUK authentication error handling. OSP.DATA_WIPE The objective O. WIPE directly covers this OSP. OSP.ACCESS_CONTROL The objective O.FUNCTION_ACCESS_CONTROL covers this OSP by providing function access control. The objective O.KEY_MANAGEMENT strengthens the coverage of this OSP for user keys by providing a second level of access control for user keys. OSP.TOE_AUDIT This OSP is directly covered by the objective on the environment OE.HOST_AUDIT A.TRUSTED_ADMIN This assumption is directly covered by the objective on the environment OE.ADMIN A.TRAINED_ADMIN This assumption is directly covered by the objective on the environment OE.ADMIN A.CONFIGURATION This assumption is covered by OE.CARD_ADMIN_STATION which ensures that assets injected in TOE are consistent. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 67/92 A.KEY_QUALITY This assumption is directly covered by the objective on the environment OE.KEY_GENERATOR A.SECURE_KEY_MANAGEMENT This assumption is directly covered by the objective on the environment OE.SECURE_KEY_MANAGEMENT ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 68/92 7.2 SECURITY REQUIREMENTS RATIONALE 7.2.1 STUDY OF DEPENDENCIES The following table summarizes the dependencies of the security requirement components and justifies their satisfaction or non-satisfaction. Component Dependencies Satisfaction FIA_ATD.1 No dependencies. FIA_UAU.1 FIA_UID.1 Not fulfilled (justified) FIA_UAU.5 No dependencies. FIA_UAU.4 No dependencies. FIA_SOS.1 No dependencies. FIA_SOS.2 No dependencies. FIA_AFL.1 FIA_UAU.13 FIA_UAU.1 FDP_ACC.2/access FDP_ACF.1 FDP_ACF.1/access FDP_ACF.1/access FDP_ACC.1 FDP_ACC.2/access FMT_MSA.3 FMT_MSA.3/access FMT_MSA.3/access FMT_MSA.1 FMT_MSA.1/access FMT_SMR.1 FMT_SMR.1 FMT_MSA.1/access FDP_ACC.1 or FDP_IFC.1 FDP_ACC.2/access FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FCS_COP.1 FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 FCS_CKM.1 FDP_ITC.1/systemkey FCS_CKM.4 FCS_CKM.4 FCS_CKM.1 FCS_CKM.2 or FCS_COP.1 FCS_COP.1 FCS_CKM.4 FCS_CKM.4 FCS_CKM.4 FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 FDP_ITC.1/systemkey FCS_CKM.1 FDP_ACC.2/keys FDP_ACF.1 FDP_ACF.1/keys FDP_ACF.1/keys FDP_ACC.1 FDP_ACC.2/keys FMT_MSA.3 Not fulfilled (justified) FDP_ETC.1/keys FDP_ACC.1 or FDP_IFC.1 FDP_ACC.2/keys FDP_ITC.2/keys FDP_ACC.1 or FDP_IFC.1 FDP_ACC.2/keys FTP_ITC.1 or FTP_TRP.1 FTP_TRP.1 3 This SFR satisfies the dependency requirement for each FIA_AFL.1 instantiation (FIA_AFL.1/userSC, FIA_AFL.1/ephSC and FIA_AFL.1/PUK) ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 69/92 FPT_TDC.1 FPT_TDC.1 FMT_MSA.1/keys FDP_ACC.1 or FDP_IFC.1 FDP_ACC.2/keys FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FMT_MSA.2/keys FDP_ACC.1 or FDP_IFC.1 FDP_ACC.2/keys FMT_MSA.1 FMT_MSA.1/keys FMT_SMR.1 FMT_SMR.1 FPT_TDC.1 No dependencies FDP_ITC.1/systemkey FDP_ACC.1 or FDP_IFC.1 FDP_ACC.2/access FMT_MSA.3 Not fulfilled (justified) FTP_TRP.1 No dependencies. FDP_RIP.1 No dependencies. FMT_SMR.1 FIA_UID.1. FIA_UAU.1 FMT_SMF.1 No dependencies. FPT_EMSEC.1 No dependencies. FPT_FLS.1 No dependencies. FPT_PHP.1 No dependencies. FPT_PHP.3 No dependencies. FPT_TST.1 No dependencies. Table 6: SFR dependencies UNRESOLVED DEPENDENCIES JUSTIFICATION FIA_UAU.1  FIA_UID.1: the TOE is single user, user authentication provides identification. Therefore the FIA_UID dependency does not need to be fulfilled FMT_SMR.1  FIA_UID.1: the TOE is single user, user authentication provides identification. Therefore the FIA_UID dependency is replaced by FIA_UAU.1 FDP_ACF.1/keys  FMT_MSA.3: access control to operation involving keys is based on key attributes. These attribute are not set statically but are set and managed by the user (FDP_ITC.2/keys and FMT_MSA.1/keys).Nevertheless only secure attribute may be set for keys with identifier 0 and 1 or when changing the initial attributes of a key (FMT_MSA.2/keys). FDP_ITC.1/systemkey  FMT_MSA.3: the TOE does not define security attribute for wrapping keys. Their usage is fully controlled by SFP_OPERATION_ACCESS_CONTROL which provides access control on the functions involving the wrapping key ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 70/92 7.2.2 SECURITY REQUIREMENTS / OBJECTIVES CONSISTENCY MATRIX O.USER_AUTHENTICATION O.PUK_UNBLOCK O.STRONG_SECCODE O.LIMITED_AUTH_NUMBER O.FUNCTION_ACCESS_CONTROL O.CRYPTOGRAPHIC_OPERATION O.STRONG_MUTUAL_AUTHENTICATION O.KEY_MANAGEMENT O.PROTECT_SESSION_KEY O.APDU_ENCRYPTION O.SENSITIVE_MEMORY_ERASING O.WIPE O.EMSEC O.TAMPER_DETECTION O.TAMPER_RESISTANCE FIA_ATD.1 X X FIA_UAU.1 X FIA_UAU.5 X X FIA_UAU.4 X FIA_SOS.1 X FIA_SOS.2 X FIA_AFL.1 X FDP_ACC.2/access X FDP_ACF.1/access X FMT_MSA.3/access X FMT_MSA.1/access X FCS_COP.1 X X X FCS_CKM.1 X FCS_CKM.4 X X X FDP_ACC.2/keys X FDP_ACF.1/keys X FMT_MSA.1/keys X FMT_MSA.2/keys X FPT_TDC.1 X FDP_ETC.1/keys X FDP_ITC.2/keys X FDP_ITC.1/systemkey X FTP_TRP.1 X X FDP_RIP.1 X X FMT_SMR.1 X X X FMT_SMF.1 X X X FPT_EMSEC.1 X FPT_FLS.1 X FPT_PHP.1 X ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 71/92 O.USER_AUTHENTICATION O.PUK_UNBLOCK O.STRONG_SECCODE O.LIMITED_AUTH_NUMBER O.FUNCTION_ACCESS_CONTROL O.CRYPTOGRAPHIC_OPERATION O.STRONG_MUTUAL_AUTHENTICATION O.KEY_MANAGEMENT O.PROTECT_SESSION_KEY O.APDU_ENCRYPTION O.SENSITIVE_MEMORY_ERASING O.WIPE O.EMSEC O.TAMPER_DETECTION O.TAMPER_RESISTANCE FPT_PHP.3 X FPT_TST.1 X Table 7: security requirements / objectives consistency matrix 7.2.3 RATIONALE O.USER_AUTHENTICATION is covered by:  FIA_ATD.1 which defines the authentication attributes for the local user (security code, ephemeral security code and validation flag and counter);  FIA_UAU.1 which defines the commands an unauthenticated user may perform;  FIA_UAU.5 which defines the different ways to authenticate an user : o Through its security code; o Through an ephemeral security code if the TOE is in a RESUMABLE state; o Through a PUK code if the TOE is in a BLOCKED state; o Implicitly by ability to use the host-card trusted path if the TOE is in a RESUMABLE state.  FTP_TRP.1 which defines a trusted path between the TOE and the local user. Successful usage of this trusted channel in RESUMABLE state implicitly authenticates the user by proof of knowledge of the protection keys. O.PUK_UNBLOCK is covered by:  FIA_ATD.1 which defines the authentication attributes for the local user, in particular the TOE state;  FIA_UAU.5 which defines how to unblock the TOE: the user is authenticated by using PUK code, which turns the TOE from BLOCKED to VALIDATED_USER state;  FIA_UAU.4 which ensures each PUK code may only be used once. O.STRONG_SECCODE is covered by:  FIA_SOS.1 which ensures the user security code has the required length property;  FIA_SOS.2 which ensures that PUK codes and ephemeral code are correctly generated by the TOE  FMT_SMF.1 which allows the administrator toset a minimum security code length  Correct management of security features (FMT_SMR.1 and FMT_SMF.1) O.LIMITED_AUTH_NUMBER is covered by:  FIA_AFL.1 which defines the maximum possible failures for each authentication method and the TOE behavior when this maximum tries has been reached. O.FUNCTION_ACCESS_CONTROL is covered by:  The SFP_OPERATION_ACCESS_CONTROL access control SFP (FDP_ACC.2/access and FDP_ACF.1/access) which ensure every command passed to the TOE follows the access control policy; ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 72/92  FMT_MSA.3/access which sets the default values for each command access right;  FMT_MSA.1/access which ensures no one can change access rights;  Correct management of security features (FMT_SMR.1 and FMT_SMF.1) O.CRYPTOGRAPHIC_OPERATION is covered by:  FCS_COP.1 which defines the cryptographic algorithms the TOE shall support; O.STRONG_MUTUAL_AUTHENTICATION is covered by:  FCS_COP.1.1/random  FCS_COP.1.1/DH  FCS_COP.1.1/RSA_sig  FCS_COP.1.1/SHA256  FCS_COP.1.1/HMAC  FCS_COP.1.1/AES  FCS_COP.1.1/EMAC The mutual authentication is performed using the Cryptosmart authentication protocol. This protocol is based on the listed SFR. O.KEY_MANAGEMENT is covered by:  FCS_CKM.1 which ensures user keys can be correctly generated by the TOE;  FDP_ITC.2/keyswhich ensures user keys may be imported to the TOE;  FCS_CKM.4 which ensure secure keys destruction of user keys;  The SFP_KEY_ACCESS_CONTROL ensures the security of key management, in particular: o FDP_ACC.2/keys and FDP_ACF.1/keys defines the access control to user keys; o FMT_MSA.1/keys and FMT_MSA.2/keys focus on security attribute management by users o FDP_ETC.1/keys defining conditions under which keys may be exported from the TOE; o FDP_ITC.2/keys defining conditions under which keys may be imported inside the TOE;  FPT_TDC.1 which ensures imported security attribute are correctly interpreted  Correct management of security features (FMT_SMR.1 and FMT_SMF.1) O.PROTECT_SESSION_KEY is covered by:  FCS_COP.1.1/AES and FCS_COP.1.1/EMAC which ensure correct protection of session keys when stored outside the TOE;  FDP_ITC.1/systemkey supports FCS_COP.1.1 by defining how wrapping which protect the session keys may be imported inside the TOE.  FCS_CKM1.1/random supports FCS_COP.1.1 by defining how wrapping keys can generated by the TOE. O.APDU_ENCRYPTION is covered by:  FTP_TRP.1 which ensure the usage of a trusted path, protected both in confidentiality and integrity, for sending command to the TOE and getting its responses. O.SENSITIVE_MEMORY_ERASING and O.WIPEare both covered by:  FDP_RIP.1 which ensures non keys sensitive data are erased when no more needed;  FCS_CKM.4 which ensure the correct destruction of keys. O.EMSEC is covered by:  FPT_EMSEC.1 which ensures that no side channel allow an attacker to access sensitive data O.TAMPER_DETECTION is covered by:  FPT_TST.1 which ensures tamper attacks consequences can be detected  FPT_PHP.1 which ensures detection of physical tampering ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 73/92 O.TAMPER_RESISTANCE is covered by:  FPT_PHP.3 which ensures that an attacker may not access sensitive data by changing physical operational environment;  FPT_FLS.1 which ensures that the TOE remains in a secure state once an error which may be caused by tampering occurs ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 74/92 7.2.4 SAR RATIONAL The aimed assurance level for this security target is EAL4 augmented with ALC_DVS.2 and AVA_VAN.5. This level has been chosen to be as close as possible the French “qualification renforcée” package. (which also includes ADV_IMP.2 and ALC_FLR.3 which can’t be claimed as these component are not met by the platform). The ALC_DVS.2 component has no dependencies. The AVA_VAN.5 component has for dependencies:  ADV_ARC.1 Security architecture description  ADV_FSP.4 Complete functional specification  ADV_TDS.3 Basic modular design  ADV_IMP.1 Implementation representation of the TSF  AGD_OPE.1 Operational user guidance  AGD_PRE.1 Preparative procedures  ATE_DPT.1 Testing: basic design Which are all included in the EAL4 package.Therefore every requirement for the chosen SAR is fulfilled. 7.3 GLOBAL TOE SPECIFICATION RATIONALE ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 75/92 7.3.1 MAPPING TOE SFRS TO TOE SECURITY FUNCTIONS ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 76/92 SF.IA_roles SF.IA_auth_parameter SF.IA_security_code SF.IA_PUK_code SF.IA_ephemeral_security_code SF.IA_light_auth SF.CR_statefull_authentication SF.CR_stateless_authentication SF.CR_key_derivation SF.CR_local_protection_key SF.CR_RSA_encrypt SF.CR_RSA_sign SF.CR_AES SF.CR_MAC SF_CR_key_generation SF.CR_rng SF.CR_key_destruction SF.PR_access_rights SF.PR_Key_access_control SF.PR_Residual_wipe SF.PR_apdu SF.GS_admin SF.GS_user SF.PTF_SAFESTATE_MGT SF.PTF_PHYS FIA_ATD.1 X FIA_UAU.1 X FIA_UAU.5 X X X X FIA_UAU.4 X FIA_SOS.1 X FIA_SOS.2 X X X FIA_AFL.1 X X X FDP_ACC.2/access X FDP_ACF.1/access X FMT_MSA.3/access X FMT_MSA.1/access X FCS_COP.1 X X X X X X X X FCS_CKM.1 X X FCS_CKM.4 X FDP_ACC.2/keys X FDP_ACF.1/keys X FDP_ETC.1/keys X X FDP_ITC.2/keys X X ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 77/92 SF.IA_roles SF.IA_auth_parameter SF.IA_security_code SF.IA_PUK_code SF.IA_ephemeral_security_code SF.IA_light_auth SF.CR_statefull_authentication SF.CR_stateless_authentication SF.CR_key_derivation SF.CR_local_protection_key SF.CR_RSA_encrypt SF.CR_RSA_sign SF.CR_AES SF.CR_MAC SF_CR_key_generation SF.CR_rng SF.CR_key_destruction SF.PR_access_rights SF.PR_Key_access_control SF.PR_Residual_wipe SF.PR_apdu SF.GS_admin SF.GS_user SF.PTF_SAFESTATE_MGT SF.PTF_PHYS FPT_TDC.1 X X FMT_MSA.1/keys X X FMT_MSA.2/keys X X FDP_ITC.1/systemkey X FTP_TRP.1 X FDP_RIP.1 X FMT_SMR.1 X FMT_SMF.1 X X FPT_EMSEC.1 X FPT_FLS.1 X FPT_PHP.1 X FPT_PHP.3 X FPT_TST.1 X Table 8: Mapping toe sfrs to toe security functions ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 78/92 7.3.2 RATIONALE This section describes how the TOE security functions described in TOE summary specification meet each SFR. FIA_ATD.1 (User attribute definition) describes the list of attributes belonging to users. This component is met by SF.IA_AUTH_PARAMETER which defines the user related elements maintained by the TOE. FIA_UAU.1 (Timing of authentication) describes the functions the TOE may perform without having the user authenticated. This component is met by SF.PR_ACCESS_RIGHTS which defines these actions. FIA_UAU.5 (Multiple authentication mechanisms) describes the different available authentication types. This component is met by SF.IA_SECURITY_CODE SF.IA_PUK_CODESF.IA_EPHEMERAL_SECURITY_CODESF.IA_LIGHT_AUTH which each defines an individual authentication type supported by the TOE. FIA_SOS.1 (Verification of secrets) requires a mechanism to verify secrets length. This component is met by SF.IA_SECURITY_CODE which defines the required secret length. FIA_SOS.2 (Generation of secrets) describes the methods the TOE shall use to generate secrets and the authentication method which require generated secrets usage. This component is met by SF.IA_PUK_CODE and SF.IA_EPHEMERAL_SECURITY_CODE which specify that they must use TOE generated secrets and SF.CR_RNG which defines the generation method of secrets. FIA_AFL.1 (Authentication failure handling) describes how the TOE shall react on authentication failure. The authentication mechanism descriptions SF.IA_SECURITY_CODE SF.IA_PUK_CODE SF.IA_EPHEMERAL_SECURITY_CODE each describe how to handle authentication failure. The FDP_ACC.2/access (Complete access control)and FDP_ACF.2/access (Security attributes based access control) componentsare met by SF.PR_ACCESS RIGHTS which defines the access control method to sensitive assets. FMT_MSA.3/access (Static attributes initialization) defines how attributes used for FDP_ACF.2/access are initialized. SF.PR_ACCESS RIGHTS defines this initialization. FMT_MSA.1/access (Management of security attributes) requires that attributes used for FDP_ACF.2/access may not be changed. SF.PR_ACCESS RIGHTS meets this requirement by explicitly stating this. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 79/92 FCS_COP.1 (Cryptographic operation) defines how the TOE shall perform cryptographic operation. This component is instantiated for:  Diffie-Hellman operation  AES operation  SHA256 message digest operation  HMAC MAC operation  EMAC MAC operation  RSA signature  RSA encryption  Random generation These requirements are met respectively by:  SF.CR_STATEFULL_AUTHENTICATION and SF.CR_STATELESS_AUTHENTICATION  SF.CR_AES and SF.CR_KEY_DERIVATION  SF.CR_STATEFULL_AUTHENTICATION and SF.CR_STATELESS_AUTHENTICATION and SF.CR_LOCAL_PROTECTION_KEY  SF.CR_MAC, SF.CR_STATEFULL_AUTHENTICATION andSF.CR_STATELESS_AUTHENTICATION  SF.CR_MAC and SF.CR_KEY_DERIVATION  SF.CR_RSA_SIGN  SF.CR_RSA_ENCRYPT  SF.CR_RNG Which each define the cryptographic functions of the TOE. FCS_CKM.1 (Cryptographic key generation) defines how the TOE shall generate RSA and symmetric keys. This is directly met by SF.CR_KEY_GENERATION. FCS_CKM.4 (Cryptographic key destruction): This component is met by SF.CR_KEY_DESTRUCTION which describes key destruction. The FDP_ACC.2/keys (Complete access control) component is met by SF.PR_KEY_ACCESS_CONTROL which defines the access control method to user keys. The FDP_ACF.2/keys (Security attributes based access control) component is met by SF.PR_KEY_ACCESS_CONTROL which defines the access control method to user keys. The FDP_ETC.1/keys (Export of user data without security attributes) component is met by SF.GS_admin and SF.GS_userwhich defines the management operation on user keys. TheFDP_ITC.2/keys (Import of user data with security attributes) component is met by SF.GS_admin and SF.GS_user which defines the management operation on user keys. The FPT_TDC.1 (Inter-TSF basic TSF data consistency) component is met by SF.GS_admin and SF.GS_user which defines the management operation on user keys. FMT_MSA.1/keys (Management of security attributes) defines how and by whom attributes used for FDP_ACF.2/keys may be changed. SF.GS_ADMIN and SF.GS_USER meet this requirement by defining management possibilities respectively for the administrator and the user. FMT_MSA.2/keys (Secure security attributes) defines the attribute management limitations. This requirement is met by SF.GS_ADMIN and SF.GS_USER which state these limitations. FDP_ITC.1/systemkey (Import of user data without security attributes) is met by SF.GS_ADMIN which specifies how administrator keys are imported. FTP_TRP.1 (Trusted path) requires usage of a protected channel (in confidentiality, integrity and against replay) for passing commands to the TOE. It also defines the commands for which this channel is not necessary. This is met by SF.PR_APDU which defines such a trusted channel. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 80/92 FDP_RIP.1 (Residual Information Protection): This component is met by SF.PR_RESIDUAL_WIPE which describes destruction of sensitive elements (which are not cryptographic keys). FMT_SMR.1 (Security roles) describes the roles of TOE users. This component is met by SF.IA_ROLES which defines these roles. FMT_SMF.1 (Specification of Management Functions): This component is met by SF.GS_ADMIN and SF.GS_USER which describe the management functions the administrator or the user may perform. FPT_EMSEC.1: this component is met by SF.PTF_PHYS which ensures that there is no information leakage allowing retrieving sensitive data. FPT_FLS.1 (Failure with preservation of secure state):this component is met by SF.PTF_SAFESTATE_MGT which ensures that in case of major error an attacker may not have access to sensitive data (destruction of the TOE). FPT_TST.1 (TSF testing):this component is met by SF.PTF_SAFESTATE_MGT which monitors the integrity of the TOE and the TSF data by performing selftests. FPT_PHP.1 (Passive detection of physical attack):this component is met by SF.PTF_PHYS which ensures detection of physical tampering or detection of errors which are consequences of a physical tampering FPT_PHP.3 (Resistance to physical attack): this component is met by SF.PTF_PHYS which ensures that the TOE takes countermeasures against physical manipulation. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 81/92 8. CONSISTENCY OF COMPOSITE PRODUCT SECURITY TARGET 8.1 SEPARATION OF TSF The composite product is an applet loaded on the platform. The platform offers protection to the applet and its sensitive data against all relevant threat from [IOC7 - ST]. 8.2 COMPATIBILITY OF SAR The following table summarizes the SAR for both the composite product and the platform, showing that every platform SAR is greaterthan or equal tocomposite SAR. Assurance class Assurance component Platform Level Composite Level Development ADV_ARC 1 1 ADV_FSP 5 4 ADV_IMP 1 1 ADV_INT 2 N.A. ADV_TDS 4 3 Guidance documents AGD_OPE 1 1 AGD_PRE 1 1 Life-cycle support ALC_CMC 4 4 ALC_CMS 5 4 ALC_DEL 1 1 ALC_DVS 2 2 ALC_LCD 1 1 ALC_TAT 2 1 Security target evaluation ASE_CCL 1 1 ASE_ECD 1 1 ASE_INT 1 1 ASE_OBJ 2 2 ASE_REQ 2 2 ASE_SPD 1 1 ASE_TSS 1 1 Tests ATE_COV 2 2 ATE_DPT 3 1 ATE_FUN 1 1 ATE_IND 2 2 Vulnerability assessment AVA_VAN 5 5 Table 9: SAR compatibility ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 82/92 8.3 COMPATIBILITY OF SFR As TSF, every platform SFR is relevant to the composite security target. Nevertheless some application SFRs are based on platform SFR. This section aims at identifying these dependencies and verifying that operations performed by composite SFR on platform SFR are appropriate. Composite SFR Based on (platform SFR) Fully (F) or Partially (P) Statement of compatibility FIA_ATD.1 None User attributes are only related to the Cryptosmart applet FIA_UAU.1 None Timing of authentication is only related to the Cryptosmart applet FIA_UAU.5 FIA_AFL.1/Pin (P) FMT_MTD.1/Pin (P) Authentication codes (security code, ephemeral code and PUK codes) are stored as OwnerPIN objects. FIA_UAU.4 FIA_AFL.1/Pin (P) FMT_MTD.1/Pin (P) The Cryptosmart applet stores PUK code as OwnerPin objects with maximum authentication attempts defined to 1. FIA_SOS.1 None FIA_SOS.2 None. These secrets are generated by the TOE using the applet’s internal random generator. FIA_AFL.1 FIA_AFL.1/Pin (F) The applet bases security code and PUK code management on OwnerPin objects. The maximum unsuccessfull authentication failure is considered reached if the OwnerPin object is blocked. FDP_ACC.2/access None. The SFP_OPERATION_ACCESS_CONTROL policy is entirely managed by the Cryptosmart applet. FDP_ACF.1/access None. FMT_MSA.3/access None. FMT_MSA.1/access None. FCS_COP.1.1/AES FCS_COP.1/AES (P) The applet only uses 128 and 256 bits AES keys which are consistent with the platform SFR. FCS_COP.1/SHA256 FCS_COP.1/SHA (F) The applet directly uses the applet’s sha256 implementation using javacard API FCS_COP.1.1/HMAC FCS_COP.1/SHA (P) FCS_COP.1/AES (P) The applet performs HMAC-SHA256 based on the SHA256 defined by this SFR. HMAC mode is implemented by the applet. The applet uses AES signature verification for implementing signature verification as array comparison ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 83/92 Composite SFR Based on (platform SFR) Fully (F) or Partially (P) Statement of compatibility FCS_COP.1.1/EMAC FCS_COP.1/AES (P) The applet performs EMAC (retail cbc- mac) based on AES with 128 bits keys which is consistent with the platform SFR. FCS_COP.1.1/RSA_sig FCS_COP.1/RSA (P) The applet only uses 2048 bits RSA keys (in CRT form) for signature operation, which is consistent with the platform SFR. FCS_COP.1.1/RSA_enc FCS_COP.1/RSA (P) The applet only uses 2048 bits RSA keys (in CRT form) for decryption operation, which is consistent with the platform SFR. FCS_COP.1.1/random FCS_RNG.1/IC_SOFT (P) FCS_COP.1/AES (P) The applet generates random number by: - Generating a random buffer using the SecureRandom javacard object - Postprocessing it using an AES based DRBG FCS_COP.1.1/DH FCS_COP.1/RSA (P) The applet only uses 2048 bits modulus which is consistent with the platform SFR. Diffie-Hellman computations rely on FCS_COP.1/RSA in SFM mode. FCS_CKM.1.1/RSA FCS CKM.1.1 / RSA (F) FCS_CKM.1.1/random None. These keys (symmetric keys and DH private keys) are generated at random using the applet generator. FCS_CKM.1.1/local_prot FCS_COP.1/SHA (P) The applet performs the key generation based on the SHA256 defined by this SFR. FCS_CKM.4 FCS_CKM.4 (F) for keys values stored in a key object in NVM FDP_RIP.1.1/KEYS (F) for keys values stored in the cryptographic buffer. FDP_RIP.1.1/APDU (F) and FDP_RIP.1.1/TRANSIENT (F) for key values stored in volatile memory Keys stored as javacard objects are cleared using the clearKey() method. Cryptographic keys which are stored as arrays are erased by zeroization FDP_ACC.2/keys None. FDP_ACF.1/keys None. FDP_ETC.1/keys None. FDP_ITC.2/keys FCS_CKM.2 (P) User keys are imported then stored in javacard objects using the setKey() method. FPT_TDC.1 None. FMT_MSA.1/keys None. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 84/92 Composite SFR Based on (platform SFR) Fully (F) or Partially (P) Statement of compatibility FMT_MSA.2/keys None. FDP_ITC.1.1/systemkey None. FTP_TRP.1 None. Trusted path protection is based on composite SFRs FCS_COP.1.1/AES, FCS_COP.1.1/EMAC for confidentiality and integrity protection and FCS_COP.1.1/RSA_enc for key establishment. FDP_RIP.1 FCS_CKM.4 (F) and FDP_RIP.1.1/KEYS (F) for keys values stored in the cryptographic buffer. FDP_RIP.1.1/APDU (F) and FDP_RIP.1.1/TRANSIENT (F) for key values stored in volatile memory Session keys are stored as javacard key objects and benefit from the FCS_CKM.4 and FDP_RIP.1.1/KEYS SFR. Keys may transit through temporary location and are then erased either through FDP_RIP.1.1/APDU or FDP_RIP.1.1/TRANSIENT. FMT_SMR.1 None FMT_SMF.1 None FPT_FLS.1 Fully supported by the platform SFRs : FAU_ARP (F)  FAU_ARP.1/JCS;  FAU_ARP.1.1/IC; FPR_RCV (F)  FPT_RCV.3/SCP;  FPT_RCV.4/SCP; FPT_FLS (F)  FPT_FLS.1/JCS;  FPT_FLS.1/SCP; FRU_RSA (F)  FRU_RSA.1.1/Installer; FDP_ROL (F)  FDP_ROL.1/FIREWALL; FRU_FLT (F)  FRU_FLT.1/SCP; FDP_RIP (F)  FDP_RIP.1/APDU;  FDP_RIP.1.1/KEYS;  FDP_RIP.1/TRANSIENT;  FDP_RIP.1/IC; This SFR is implemented on platform side only and is independent from the Cryptosmart applet. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 85/92 Composite SFR Based on (platform SFR) Fully (F) or Partially (P) Statement of compatibility FPT_PHP.1 Fully supported by the platform SFR FPT_PHP.3/SCP (F) This SFR is implemented on platform side only and is independent from the Cryptosmart applet. FPT_PHP.3 Fully supported by the platform SFRsFPT_PHP.3/SCP (F) This SFR is implemented on platform side only and is independent from the Cryptosmart applet. FPT_TST.1 Fully supported by the platform SFRs : FPT_TST.1/RESET (F) FPT_TST.1/FIRST_USED (F) FDP_SDI.2 (F) This SFR is implemented on platform side only and is independent from the Cryptosmart applet. FPT_EMSEC.1 Fully supported by the platform SFRs : FPR_UNO.1(F) FPR_UNO.1/USE_KEY(F) FPR_UNO.1/applet (F) FPR_UNO.1/IC (F) This SFR is implemented on platform side only and is independent from the Cryptosmart applet. Table 10: SFR compatibility 8.4 COMPATIBILITY OF SECURITY OBJECTIVES Only a subset of the platform security objectives (as described in [IOC7-ST])is relevant to the composite security target. The security objectives of the composite security target can be divided into security objectives corresponding to:  Security objectives provided by the underlying javacard platform;  Security objectives provided by the composite TOE, fulfilled by the combination of the applet and the underlying javacard platform The table below lists the security objectives provided by the composite TOE and for each of them gives the security objectives from the platform it relies on. Security objectives of the composite TOE Rely on the following objectives from the underlying platform, either Fully (F) or Partly (P) O.USER_AUTHENTICATION O.PIN-MNGT (user security code and PUK are managed as platform Pin objects) (F) O.PUK_UNBLOCK O.PIN-MNGT (PUK codes are managed as platform Pin objects) (F) O.STRONG_SECCODE None. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 86/92 Security objectives of the composite TOE Rely on the following objectives from the underlying platform, either Fully (F) or Partly (P) O.LIMITED_AUTH_NUMBER O.PIN-MNGT (user security code and PUK are managed as platform Pin objects which manage the failure limit) (P) O.FUNCTION_ACCESS_CONTROL None. O.CRYPTOGRAPHIC_OPERATION O.CIPHER,: cryptographic operation done by the applet use platform provided cryptographic functions. (P) O.STRONG_MUTUAL_AUTHENTICATION O.CIPHER: cryptographic operation done by the applet use platform provided cryptographic functions. (P) O.KEY_MANAGEMENT O.KEY-MNGT: user keys are managed as platform key object (P) O.PROTECT_SESSION_KEY O.CIPHER: key wrapping is performed using platform provided cryptographic functions O.KEY-MNGT (P) O.APDU_ENCRYPTION O.CIPHER: APDU encryption is performed using platform provided cryptographic functions (P) O.SENSITIVE_MEMORY_ERASING O.KEY-MNGT: for user keys as the platform provides a method to clear keys. O.REALLOCATION (P) O.WIPE O.KEY-MNGT: for user keys as the platform provides a method to clear keys. (P) O.EMSEC O.SECURE_COMPARE O.CIPHER O.PIN-MNGT (F) O.TAMPER_DETECTION O.RESOURCES O.ALARM (F) O.TAMPER_RESISTANCE O.OPERATE O.TRANSACTION O.SCP.RECOVERY O.SCP.SUPPORT O.SCP.IC (F) Table 11: Compatibility of security objectives The table below lists, (1) the security objective fulfilled by the underlying javacard platform, (2) and for each of them:  The list of all the corresponding SFRs according to [IOC7 - ST] ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 87/92  The SFR that shall be discarded, taken into account the fact that(1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running  The SFR that shall be discarded, taken into account the fact that the applet does not create nor delete any object after the point of delivery ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 88/92 Objective from the underlying platform Corresponding SFRs O.OPERATE FPT_RVM.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FPT_SEP.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FPT_TDC.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FDP_ACC.2(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FDP_ACF.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FPT_FLS.1 FAU_ARP.1 FPT_TST.1 FPT_AMT.1 (SCPG) FPT_RCV.3 FDP_ROL.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FDP_ITC.2(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FIA_ATD.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FIA_USB.1 (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 89/92 Objective from the underlying platform Corresponding SFRs O.RESSOURCES FAU_ARP.1 FRU_RSA.1 (not for the number of packages) FPT_FLS.1 FDP_ROL.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FPT_RCV.3(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FMT_MTD.1 (only the component FMT_MTD.1/PIN as (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FMT_MTD.3(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FMT_SMR.1 (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FPT_RVM.1 (SCPG) (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) O.REALLOCATION FDP_RIP.1 FDP_IFC.2/BCV (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FDP_IFF.2/BCV (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) O.ALARM FPT_FLS.1 FAU_ARP.1 O.TRANSACTION FDP_ROL.1 FDP_RIP.1 FDP_RIP.1.1/ABORT (As the applet does not perform any object allocation after the point of delivery) ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 90/92 Objective from the underlying platform Corresponding SFRs O.CIPHER FCS_CKM.1(only for the algorithm used by the composite TOE) FCS_CKM.2 FCS_CKM.3 (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FCS_CKM.4 FCS_COP.1 (only for the algorithm used by the composite TOE) FPR_UNO.1 O.PIN-MNGT FDP_RIP.1 FPR_UNO.1 FDP_ROL.1 FDP_SDI.2 FDP_ACC.2(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FDP_ACF.1(As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) O.KEY-MNGT FCS_CKM.1 FCS_CKM.2 FCS_CKM.3 FCS_CKM.4 FCS_COP.1 FPR_UNO.1 FDP_RIP.1 FDP_SDI.2 O.SECURE_COMPARE FPR_UNO O.SCP_RECOVERY FPT_RCV.3 (SCPG) FPT_FLS.1 FPT_RCV.3 (Only FPT_RCV.3/SCP as (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FRU_FLT.1 (SCPG) ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 91/92 Objective from the underlying platform Corresponding SFRs O.SCP.SUPPORT FPT_RCV.3 (SCPG) FPT_RCV.4 (SCPG) FPT_SEP.1 (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) FPT_AMT.1 FPT_RCV.3 (SCPG) FPT_RCV.4 (SCPG) FPT_RVM.1 (SCPG) (As (1) the javacard platform is not opened, (2) the applet is loaded and installed before the point of delivery, and (3) there are no other applet running) O.SCP.IC FPT_PHP.3/SCP FPT_PHP.3/IC FCS_RNG.1/IC FCS_RNG.1/IC_SOFT Table 12: Mapping of platform's security objectives to platform's SFR 8.5 COMPATIBILITY OF SECURITY OBJECTIVES FOR THE ENVIRONMENT The significant security objectives for the environment of the platform security target are not contradictory to those of the composite security target. Platform security objectives for the environment concern applet content and loading on the smartcard. The objectives for the environment of the composite TOE include those of the platform, and objectives concerning:  The Cryptosmart applet development, generation and storage  The environment for pre-personalization;  The environment for personalization;  The host behavior;  Usage constraints. Therefore these objectives are independent and do not contradict themselves. 8.6 COMPATIBILITY OF THREATS All the platform threats are relevant to the composite security target. The threats of the composite security target can be divided into threats corresponding to:  The platform specific threats;  Refinements of platform threat to applet specific assets (T.PHYSICAL);  Applet specific threats. The threats of the composite security target are not contradictory to the relevant threats of the platform security target. 8.7 COMPATIBILITY OF OSP The platform has only one OSP (OSP.VERIFICATION) concerning bytecode verification before execution on the platform. The OSPs from this ST only apply on the composite TOE once the Cryptosmart applet is loaded; and concern: ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Ed : 2010B/346 Ver. : 5.1.2 Cryptosmart card 5.1 November 7, 2016 Cryptosmart applet 5.1 - Public Security- target.docm Public Security Target 92/92  Directives the composite TOE must follow;  Service the composite TOE must offer;  Security rules the composite TOE must implement. The OSP of the composite security target are independent and not contradictory to the relevant OSPs of the platform security target. 8.8 COMPATIBILITY OF ASSUMPTIONS The platform assumptions only concern applet content and loading on the smartcard. Assumptions for the composite TOE concern correct TOE administration security (reliability of the administrator, generation and management of cryptographic keys). Those two types of assumptions are independent and are not contradictory. 8.9 COMPATIBILITY WITH [ANSSI-NOTE-10] After the delivery point the objectives OE1 and OE2 are not relevant for the TOE as the TOE is in closed configuration (the Card Manager is deactivated): no more applet can be loaded and the applet cannot be deleted. The platform security target [IOC7-ST] defines the security objectives for its environment OE.VERIFICATION and OE.APPLET for fulfilling OE1 and OE2 from [ANSSI-NOTE-10]. As a matter of fact, OE1 and OE2 only apply to the development phase of the TOE, before the point of delivery. OE1 is fulfilled as (1) the Cryptosmart applet is designed not to contain any native code, and (2) its bytecode is verified before the applet being loaded onto the platform. The security objectiveOE2 from [ANSSI-NOTE-10] is also fulfilled by organizational measure as the ALC_DVS.2assurance class ensures the integrity of the applet loaded onto the platform.