ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 1/82 CRYPTOSMART CARD 5.0 SECURITY TARGET Document revision: 33 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 Ed. Date Author Designation / Modification 5.0-draft 2010-05-17 JKI SPD; security objectives and SPD-SO rationale 5.0.1-draft 2010-05-17 JKI Modification after RL and EL remarks 5.0.2 2010-10-13 JKI SFR/SAR definition; TSF definition; TOE description 5.0.3 2010-10-18 JKI ST is now composite with Smart Café Java Card ST. Impacted description; and some objective previously from environment are included as objectives for the TOE. 5.0.4 2010-11-17 JKI Platform change; Some SFR rewriting 5.0.5 2011-01-31 JKI Modification after ANSSI remarks 5.0.6 2011-03-24 JKI Release transmitted to CESTI 5.0.7 2011-05-19 JKI Correction after CESTI remarks 5.0.8 2011-06-24 JKI Correction of issues underlined by CESTI and about key management. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 2/82 TABLE OF CONTENT 1. SECURITY TARGET INTRODUCTION ..................................................................................................................... 5 1.1 SECURITY TARGET AND TOE IDENTIFICATION ..................................................................................................................5 1.2 CONFORMANCE CLAIMS ............................................................................................................................................5 1.3 CONVENTIONS.........................................................................................................................................................6 1.4 TERMINOLOGY ........................................................................................................................................................ 7 1.5 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 COMPOSITE TOE SCOPE..........................................................................................................................................21 3. SECURITY PROBLEM DEFINITION........................................................................................................................23 3.1 ASSETS TO PROTECT................................................................................................................................................23 3.2 ASSUMPTIONS....................................................................................................................................................... 25 3.3 THREATS ..............................................................................................................................................................26 3.4 OSP....................................................................................................................................................................28 4. SECURITY OBJECTIVES........................................................................................................................................30 4.1 SECURITY OBJECTIVES FOR THE TOE............................................................................................................................30 4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT .............................................................................................................32 5. SECURITY REQUIREMENTS .................................................................................................................................34 5.1 SECURITY FUNCTIONAL REQUIREMENTS......................................................................................................................35 5.2 TOE SECURITY ASSURANCE REQUIREMENTS..................................................................................................................53 6. GLOBAL TOE SPECIFICATION ..............................................................................................................................54 6.1 TOE SECURITY FUNCTIONS........................................................................................................................................54 6.2 TOE SECURITY ASSURANCE MEASURES ........................................................................................................................59 7. RATIONALES.......................................................................................................................................................64 7.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................................64 7.2 SECURITY REQUIREMENTS RATIONALE ........................................................................................................................69 7.3 GLOBAL TOE SPECIFICATION RATIONALE......................................................................................................................75 8. CONSISTENCY OF COMPOSITE PRODUCT SECURITY TARGET..............................................................................78 8.1 SEPARATION OF TSF...............................................................................................................................................78 8.2 COMPATIBILITY OF SAR...........................................................................................................................................78 8.3 COMPATIBILITY OF SFR...........................................................................................................................................79 8.4 COMPATIBILITY OF SECURITY OBJECTIVES ....................................................................................................................80 8.5 COMPATIBILITY OF SECURITY OBJECTIVES FOR THE ENVIRONMENT....................................................................................81 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 3/82 8.6 COMPATIBILITY OF THREATS .....................................................................................................................................81 8.7 COMPATIBILITY OF OSP ..........................................................................................................................................82 8.8 COMPATIBILITY OF ASSUMPTIONS..............................................................................................................................82 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 4/82 TABLE OF FIGURES Figure 1: Cryptosmart sample architecture ..................................................................................................... 11 Figure 2: Cryptosmart card life cycle............................................................................................................... 17 Figure 3: TOE scope........................................................................................................................................ 22 TABLES Table 1 : Cryptosmart card life states.............................................................................................................. 18 Table 2: Assets security needs........................................................................................................................ 25 Table 3: Function access rights....................................................................................................................... 41 Table 4: Cryptosmart card aimed assurance levels ........................................................................................ 53 Table 5: Tracing between security objectives and security problem definition ............................................... 64 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 5/82 1. SECURITY TARGET INTRODUCTION 1.1 SECURITY TARGET AND TOE IDENTIFICATION This document constitutes the Security Target (ST) of Cryptosmart card, version 5.0 developed by Ercom. • ST name: Cryptosmart card 5.0 – Security target • ST version: 5.0.8 • ST Date : July 10, 2012 • TOE identifier: Cryptosmart applet on Oberthur ID-ONE COSMO V7.0.1 • TOE version: 5.0 • TOE Developer : ERCOM This security target addresses a composite TOE evaluation in the sense of [CPESC] where: • The certified platform is the ID-ONE COSMO V7.0.1 OS Java Card (with optional code identified as 077121); • The application is the cryptosmart applet V5.0. The platform is identified as follows: Platform name ID-One Cosmo V7.0.1-n Standard Dual ID-One Cosmo V7.0.1-n Standard ID-One Cosmo V7.0.1-n Basic Dual Platform hardware identification 18 01 1F 18 01 1A 18 01 1B Optional code 077121 077121 077121 Platform IC reference version P5CD081 V1A P5CC081 V1A P5CD041 V1A 1.2 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", July 2009, Version 3.1 Revision 3 (CCMB-2009-07-001) • "Common Criteria for information Technology Security Evaluation, Part 2: Security Functional requirements", July 2009, Version 3.1 Revision 3 (CCMB-2009-07-002) • "Common Criteria for information Technology Security Evaluation, Part 3: Security Assurance requirements", July 2009, Version 3.1 Revision 3 (CCMB-2009-07-003) Conformance is claimed as follows: • Part 1: conformant • Part 2: conformant • Part 3: conformant to assurance level EAL4 augmented with ALC_DVS.2 and AVA_VAN.5 Conformity to a protection profile: This Security Target does not claim conformance with any Protection Profile. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 6/82 1.3 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 7/82 1.4 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 8/82 1.5 REFERENCES [CC3-p1] Common Criteria for Information Technology Security Evaluation part 1, version 3.1 Revision 3 [CC3-p2] Common Criteria for Information Technology Security Evaluation part 2, version 3.1 Revision 3 [CC3-p3] Common Criteria for Information Technology Security Evaluation part 3, version 3.1 Revision 3 [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 [IOC7 - ST] ID-ONE COSMO V7.0.1 TERPSICHORE Security Target FQR 110 5145 Issue 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 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 9/82 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 JavaCard 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-SHA256  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. 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: • 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 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 10/82 • 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 11/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 12/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 13/82 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; • 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 and local protection key obtention services are 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 14/82 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 allowing identity protection. 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. 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. Note: the TOE only performs operation with private key. Public key operation (RSA encryption) is performed by the host. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 15/82 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 10.000 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. This feature is excluded from the evaluated configuration. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 16/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 17/82 2.3.4 TOE LIFE CYCLE This part describes the different states of the TOE, with the corresponding possible transitions. Figure 2: Cryptosmart card life cycle Cryptosmart cards consist of a Cryptosmart Java applet installed on a Javacard platform compatible with Javacard 2.2.1 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 18/82 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. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 19/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 20/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 21/82 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 cryptosmart mutual 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 command to 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 COMPOSITE TOE SCOPE The TOE to be evaluated is composed of TOE part 1 and TOE part 2. TOE part 1 identifies the certified platform ID-ONE COSMO V7.0JavaCard OS. This TOE part includes software (the firmware, the Card Manager and the operating system) embedded on a microcontroller According to [IOC7-ST] compatible chips are: • NXP P5CD041V1A, • NXP P5CD081V1A, • NXP P5CC081V1A. ([IOC7-ST] also mentions NXP P5CD016V1A and NXP P5CD021V1A which are two configuration options present in the IC evaluation, but which are not used for the platform evaluation). It is a Java Card platform compliant with Java Card 2.2.1 and Visa GlobalPlatform 2.1.1. TOE part 2 identifies the cryptosmart applet v5.0. 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 platform must be either: • The ID-One Cosmo V7.0.1-n Standard on P5CC081 V1A component; • The ID-One Cosmo V7.0.1-n Standard Dual on P5CD081 V1A component; with the contactless interface deactivated • The ID-One Cosmo V7.0.1-n Basic Dual on P5CD041 V1A component; with the contactless interface deactivated A deactivated contactless interface can be identified by checking the “Interface lock” of the platform which second bit (masked by 0x02) must be set to 1. The TOE scope is represented Figure 3. [IOC7-ST] gives full details on TOE part 1 scope. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 22/82 Figure 3: TOE scope 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; • Administration service including downloading and installation of the applet; • Application isolation (Java Card Firewall); • 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.4.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 signature service and the local protection key obtention. The evaluated TOE also fixes TOE configuration choices. The TOE administrator must: • Set a minimal security code length between 4 and 8 to forbid usage of the TOE without security code; Moreover the TOE evaluation scope fixes some constraints on TOE usage: • In case of gateway card the DH parameter used for distant authentication must be renewed after each authentication by using the appropriate command; • Sensitive symmetric keys must have the signature usage attribute set to false. • Sensitive symmetric keys must have the “disable security check” attribute set to false. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 23/82 3. SECURITY PROBLEM DEFINITION 3.1 ASSETS TO PROTECT This section lists the assets which are security relevant for the TOE. 3.1.1 TOE PART 1 ASSETS For a detailed description of these assets refer to [IOC7-ST]. 3.1.2 TOE PART 2 ASSETS Assets for TOE part 2 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.3 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. Symmetric keys with identifier 0 and 1 may only be used to get local protection keys. As this feature is not part of the TOE these two keys are excluded from D.USER_STORED_KEYS 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.4 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 24/82 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.5 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 • 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_KEY) 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 applet (TOE part 2) loaded on the card (TOE part 1). ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 25/82 3.1.6 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. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 26/82 3.3 THREATS The threats listed below concern directly the TOE part 2. All the platform threats from [IOC7-ST] are also relevant to the composite security target. 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 27/82 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.ORIGINAL_DATA D.TOE_INTERNAL_DATA This security target also considers the following threats (some of them are taken from the platform security target [IOC7 - ST]): 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). 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_KEYS D.PLAINTEXT_DATA D.ORIGINAL_DATA D.USER_STORED_DATA T.INTEG_APPLI_CODE An attacker alters TOE part 2 code either by • executing an application on TOE part 1, or • when an application package is transmitted to the card for installation. This threat is a combination of two threats from [IOC7 - ST]: T.INTEG-APPLI-CODE and T.INTEG- APPLI-CODE.LOAD restricted to the sensitive asset D.APP_CODE. Impacted assets: D.APP_CODE ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 28/82 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 29/82 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. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 30/82 4. SECURITY OBJECTIVES 4.1 SECURITY OBJECTIVES FOR THE TOE This section defines the security objectives for the composite TOE. All the platform security objectives listed in [IOC7-ST] are considered as included into this composite security target. The objectives listed below are those specifically relevant for the cryptosmart applet (TOE part 2). 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. The security functions for authentication of users shall have strength “high”. 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 31/82 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 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 32/82 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 platform (defined in [IOC7 - ST]). These security objectives are recalled here for convenience: • O.SECURE-COMPARE: the TOE shall provide to applet a means to securely compare two byte arrays. • O.SCP.IC: the smart card platform (TOE part 1) shall possess IC security features (see #.SCP from [JCS-PP]). • O.CARD-MANAGEMENT: the card manager is in the scope of the TOE. IT shall control the access to card management functions such as the installation, update or deletion of applets. It shall also implement the card issuer's policy on the card. The card manager is an application with specific rights, which is responsible for the administration of the smart card. Typically the card manager shall be in charge of the life cycle of the whole card, as well as that of the installed applications (applets). The card manager should prevent that card content management (loading, installation, deletion) is carried out, for instance, at invalid states of the card or by non-authorized actors. It shall also enforce security policies established by the card issuer. • O.LOAD: the TOE shall ensure that the loading of a package into the card is safe. 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_APPLET_MANAGEMENT The cryptosmart applet (TOE part 2) shall be developed, generated, stored and injected on platform (TOE part 1) in an environment not accessible physically or remotely by an attacker. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 33/82 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 protocol it correctly verifies that the distant certificate is valid and bound to the expected distant user’s identity; and 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 34/82 5. SECURITY REQUIREMENTS This section defines the security requirements satisfied by the TOE. Each requirement has been extracted from version 3.1 of the Common Criteria, part 2 providing functional requirements and part 3 providing assurance requirements. 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.1.12. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 35/82 5.1 SECURITY FUNCTIONAL REQUIREMENTS 5.1.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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 36/82 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 require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Application note: the “FIA_UAU.5 Multiple authentication mechanisms” SFR handles the state transitions to VALIDATED_USER or RESUMED_USER states. Authentication mechanisms are available depending on current TOE state. They allow state transition: • 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.1.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: SPECIFICATION OF SECRETS (FIA_SOS) 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]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 37/82 5.1.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’s length requirements]. Application note: user security code must have a length comprised between 4 and 8 characters. In PERSONALIZATION state, the minimum security code length may have been set to a value greater than 4 by 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 38/82 5.1.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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 39/82 5.1.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. Each cryptosmart 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 40/82 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 0x08 Generate Kapdu 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 Store 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 41/82 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 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 42/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 43/82 5.1.5.1 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/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.1.6 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/AES • FCS_COP.1.1/EMAC ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 44/82 5.1.7 O.KEY_MANAGEMENT ENFORCING SFR 5.1.7.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/AES_MAC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [random generation] and specified cryptographic key sizes [128 bits and 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 45/82 5.1.7.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: [nothing]. 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]. Note: the SFR FCS_CKM.4.1/java only applies to keys stored in javacard Key objects. Cryptographic keys which are stored as arrays are only erased by zeroization 5.1.7.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_KEY corresponds to the D.USER_SIGNATURE_KEY asset • Ob.APDU_INITIALIZATION_KEY corresponds 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 46/82 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) 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; • 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 ]. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 47/82 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) 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]. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 48/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 49/82 5.1.8 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/AES_MAC) or imported inside the TOE. The FDP_ITC.1/keys dependency of FCS_COP.1 can’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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 50/82 5.1.9 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; • 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 51/82 5.1.10 O.SENSITIVE_MEMORY_ERASING ENFORCING 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 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 ]. Application note: this SFR handles objects explicitly managed by the Cryptosmart applet (TOE part 2). Information content of these resources may transit through temporary location being either • A transient byte buffer; in this case residual information protection is enforced by the SFR from the platform FDP_RIP.1/TRANSIENT • The APDU buffer; in this case residual information protection is enforced by the SFR from the platform FDP_RIP.1/APDU 5.1.11 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 52/82 5.1.12 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. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 53/82 5.2 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.2 and AVA_VAN.5. Table 4 summarizes the aimed assurance components. Assurance class Assurance component Level Description Development ADV_ARC 1 Security architecture description. ADV_FSP 4 Functional specification ADV_IMP 1 Implementation representation ADV_INT N.A. ADV_SPM N.A. ADV_TDS 3 TOE design Guidance documents AGD_OPE 1 Operational user guidance documentation 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 components definition ASE_INT 1 ST introduction ASE_OBJ 2 Security objectives ASE_REQ 2 Derived security requirements ASE_SPD 1 Security problem definition ASE_TSS 1 TOE summary specification Tests ATE_COV 2 Test coverage ATE_DPT 1 Test 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 54/82 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. 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. After a successful authentication by PUK code further usage of this PUK code will have no effect. The PUK code must be entered using the APDU encryption mechanism. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 55/82 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 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_AUTHENTICATION The TOE is able to conduct a session key negotiation phase with another card by using a SIGMA-I like protocol. This protocol allows the negotiation of a common secret with a perfect forward secrecy property and authenticates the distant card user. 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_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. 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). ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 56/82 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 57/82 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 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 58/82 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 59/82 6.2 TOE SECURITY ASSURANCE MEASURES 6.2.1 DEVELOPMENT SECURITY ARCHITECTURE (ADV_ARC) The developer shall provide a description of the security architecture of the Target of Evaluation (TOE) at a level of detail commensurate with the description of the SFR-enforcing abstractions described in the TOE design documents, including: • Describing the security domains maintained by the TSF consistently with the SFRs. • Describing how the TSF initialization process is secure. • Demonstrating that the TSF protects itself from tampering. • Demonstrating that the TSF prevents bypass of the SFR-enforcing functionality. This documentation will be provided as: [CSC-SA] Cryptosmart card : security architecture FUNCTIONAL SPECIFICATION (ADV_FSP) The developer shall provide a functional specification (FSP) that completely represents the TSF including: • Description of the purpose and method of use for all TSFI. • Identification and description of all parameters associated with each TSFI. • For each Security Functional Requirement (SFR)-enforcing TSFI, description of all actions associated with each TSFI. • For each SFR-enforcing TSFI, all direct error messages that may result from an invocation of each TSFI. • Summary of SFR-supporting and SFR-non-interfering actions associated with each TSFI. • Mapping of TSFIs to SFRs. This documentation will be provided as: [CSC-SSDD] Cryptosmart card : system/segment design document [CSC-AP] Cryptosmart card : Authentication protocol IMPLEMENTATION REPRESENTATION (ADV_IMP) The developer shall provide the following evidence: • The implementation representation for the entire TSF in the form used by the development personnel, to a level of detail such that the TSF can be generated without further design decisions. • Mapping demonstrating correspondence between the TOE design description and a sample of the implementation representation. This documentation will be provided as: [CSC-IMP] Cryptosmart card : Implementation ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 60/82 TOE DESIGN (ADV_TDS) The developer shall provide TOE design documentation that includes: • Description of the structure of the TOE in terms of subsystems. • Description of the TSF in terms of modules. • Identification and description of all TSF subsystems. • Description of interactions among all subsystems of the TSF. • Mapping from the subsystems of the TSF to the modules of the TSF. • Description of each SFR-enforcing module in terms of its purpose and interaction with other modules. • Description of each SFR-enforcing module in terms of its SFR-related interfaces, return values from those interfaces and interaction with and called interfaces to other modules. • Description of each SFR-supporting or SFR-non-interfering module in terms of its purpose and interaction with other modules. • Mapping of all behavior described in the TOE design to the TSFIs that invoke it. The documentation in terms of subsystem will be integrated into [CSC-SSDD]. The documentation in terms of modules will be provided as: [CSC-ID] Cryptosmart card : Internal Design 6.2.2 GUIDANCE (AGD) PREPARATIVE PROCEDURES (AGD_PRE) The developer shall provide customer documentation (e.g., user manuals) covering all activities needed to transform the delivered TOE into its evaluated configuration in the environment as described in the ST, including: • All steps necessary for secure acceptance of the delivered TOE in accordance with the developer’s delivery procedures. • All steps necessary for secure installation of the TOE and for secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. This documentation will be provided as: [CSC-AG] Cryptosmart card : Administrator guide ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 61/82 OPERATIONAL PROCEDURES (AGD_OPE) The developer shall provide customer documentation (e.g., user manuals) covering all activities needed during the operation of the TOE in its evaluated configuration, including for each user role: • The user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings; • How to use the available interfaces provided by the TOE in a secure manner; • Available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate; • For each type of security-relevant event relative to the user-accessible functions which need to be performed, including changing the security characteristics of entities under the control of the TSF; • Describe the security measures to be followed in order to fulfill the security objectives and the operational environment as described in the ST. • All possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operations. This documentation will be provided as: [CSC-UG] Cryptosmart card : user guide 6.2.3 LIFE-CYCLE SUPPORT (ALC) The documentation for the whole family will be provided as a single document: [CSC-LCD] Cryptosmart card : life cycle definition CONFIGURATION MANAGEMENT (ALC_CMC AND ALC_CMS) The developer shall provide the following evidence: • Evidence that the Target of Evaluation (TOE) is labeled with its unique reference. • Evidence that references to the TOE are consistent. • Unique identification of the configuration items. • A CM plan that describes how the CM system is used for the development of the TOE and the procedures used to accept modified or newly-created configuration items as part of the TOE. • Description of the method used to uniquely identify different versions of configuration items. • Evidence that the CM system provides automated measures to allow only authorized changes to the configuration items. • Evidence that the CM system supports production of the TOE by automated means. • Evidence that demonstrates that all configuration items are being maintained under the CM system and that the CM system is being operated in accordance with the CM plan. • Configuration lists identifying items maintained under configuration management, to include at a minimum: the TOE itself, the parts that comprise the TOE, the evaluation evidence required by the Security Assurance Requirements (SARs) in the ST, and the implementation representation. DELIVERY (ALC_DEL) The developer shall provide documentation of the developer process to: • Deliver the TOE or parts of the TOE to the consumer. • Maintain security when distributing versions of the TOE to the consumer. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 62/82 FLAW REMEDIATION (ALC_FLR) The developer shall provide flaw remediation procedure with: • Description of the procedures used to track all reported security flaws in each release of the TOE • Description of the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. Some documentation for this component will appear separately from [CSC-LCD]: [CSC-URG] Cryptosmart card : user remediation guidance DEVELOPMENT SECURITY (ALC_DVS) The developer shall provide development security documentation that describes all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. The development security documentation shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE. LIFE-CYCLE DEFINITION (ALC_LCD) The developer shall provide life-cycle definition documentation that describes the model used to develop and maintain the TOE. TOOLS AND TECHNIQUES (ALC_TAT) The developer shall provide documentation of development tools including: • Definition of each development tool used for implementation. • Documentation of each development tool that defines the meaning of all statements, conventions, and directives used in the implementation and unambiguously define the meaning of all implementation-dependent options. 6.2.4 TESTING (ATE) TEST COVERAGE (ATE_COV) The developer shall provide analysis of test coverage including demonstration of correspondence between tests identified in the test documentation and the TSFIs identified in the FSP showing that all TSFIs in the FSP have been tested. TESTING DEPTH (ATE_DPT) The developer shall provide analysis of testing depth including demonstration of correspondence of tests identified in the test documentation and the TSF subsystems and SFR-enforcing modules in the TOE design showing that: • All TSF subsystems in the TOE design have been tested. • The SFR-enforcing modules in the TOE design have been tested. The documentation for both ATE_COV and ATE_DPT will be provided as a single document: [CSC-TCA] Cryptosmart card : test coverage analysis ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 63/82 FUNCTIONAL TESTS (ATE_FUN) The developer shall provide test documentation consisting of: • Test plan – identifies the tests to be performed, describes the scenarios for performing each test including any ordering dependencies on the results of other tests. • Expected test results – describes the expected outputs from successful execution of the tests. • Actual test results – actual results, which are expected to be consistent with the expected test results. This documentation will be provided as: [CSC-TEST] Cryptosmart card : tests [CSC-TR] Cryptosmart card : test results 6.2.5 CLASS ASE: SECURITY TARGET EVALUATION The documentation for the whole family will be provided as a single document: [CSC-ST] Cryptosmart card : security target CONFORMANCE CLAIMS (ASE_CCL) The developer shall provide • A conformance claim; • A conformance claim rationale SECURITY PROBLEM DEFINITION (ASE_SPD) The developer shall provide a security problem definition which is required to demonstrate that the security problem intended to be addressed by the TOE and its operational environment, is clearly defined SECURITY OBJECTIVES (ASE_OBJ) Evaluation of the security objectives is required to demonstrate that the security objectives adequately and completely address the security problem definition. The developer shall provide: • A statement of security objectives • A security objectives rationale SECURITY REQUIREMENTS (ASE_REQ) The SFRs form a clear, unambiguous and well-defined description of the expected security behaviour of the TOE. The SARs form a clear, unambiguous and canonical description of the expected activities that will be undertaken to gain assurance in the TOE. The developer shall provide: • A statement of security requirements • A security requirements rationale TOE SUMMARY SPECIFICATION (ASE_TSS) Evaluation of the TOE summary specification is necessary to determine • Whether it is adequately described how the TOE meets its SFRs and protects itself against interference, logical tampering and bypass. • Whether the TOE summary specification is consistent with other narrative descriptions of the TOE. The developer shall provide a TOE summary specification. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 64/82 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 T.INTEG_APPLI_CODE 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 A.KEY_QUALITY A.SECURE_KEY_MANAGEMENT O.USER_AUTHENTICATION X X O.PUK_UNBLOCK X O.STRONG_SECCODE X O.LIMITED_AUTH_NUMBE R X X O.KEY_MANAGEMENT X X X O.STRONG_MUTUAL_AUT HENTICATION X O.PROTECT_SESSION_KE Y X X O.APDU_ENCRYPTION X X X X O.CRYPTOGRAPHIC_OPER ATION X X X X X X O.FUNCTION_ACCESS_CO NTROL X X X X X X O.WIPE X X O.SENSITIVE_ERASING X O.SECURE_COMPARE (platform) X O.SCP.IC (platform) X X X X O.CARD_MANAGEMENT (platform) X O.LOAD (platform) X OE.ADMIN X X X X OE.CARD_ADMIN_STATIO N X X X OE.KEY_GENERATOR X X OE.SECURE_APPLET_MAN AGEMENT X OE.SECURE_PERSONALIZ ATION X X X X OE.SECURE_KEY_MANAG EMENT X X OE.SECURE_SECCODE_E NTRY X OE.NON_TRIVIAL_SECCOD E X OE.HOST_CORRECT_BEH AVIOR 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 65/82 T.TOE_DATA_CORRUPTION This threat is covered by the following security objectives: • O.FUNCTION_ACCESS_CONTROL: ensures write access to assets 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 that modifications on outputted session keys will be detected; • O.APDU_ENCRYPTION: ensures that an attacker may not alter asset while imported in the TOE by the user; • The security objective of the platform O.SCP.IC: 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: ensures read access to assets 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 session keys are protected from disclosure; • O.APDU_ENCRYPTION: ensures that an attacker may not eavesdrop assets while imported in the TOE by the user; • The security objective of the platform O.SCP.IC: ensures an attacker may not have information on assets by physical means; • 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 knowledge of 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; • The security objective of the platform O.SECURE_COMPARE: ensures no leak exist while comparing data to stored key. This mainly applies for ephemeral code verification; • 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 66/82 T.PHYSICAL This threat is covered by the following security objectives: • The security objective of the platform O.SCP.IC from [IOC7 - ST], which covers the threat T.PHYSICAL from [IOC7 - ST]. 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 that RSA 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. T.INTEG_APPLI_CODE This threat is covered by the following security objectives: • OE.SECURE_APPLET_MANAGEMENT: ensures the integrity of loaded cryptosmart applet. • The security objective of the platform O.LOAD which ensures that the loading of a package into the card cannot harm the cryptosmart applet (TOE part 2) integrity; • The security objective of the platform O.CARD_MANAGEMENT ensures that access to card management functions such as the installation, update or deletion of applet is controlled by the platform • The security objective of the platform OE.VERIFICATION ensures the bytecode of packages has been verified before the loading. OSP.RGS_CRYPTO The objective O.CRYPTOGRAPHIC_OPERATION ensures that cryptographic 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; ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 67/82 • 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: • O.KEY_MANAGEMENT and O.FUNCTION_ACCESS_CONTROL which enable a strong security attributes based access control • The security objective of the platform O.SCP.IC which provides physical protection to stored keys 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 objective O.USER_AUTHENTICATION directly 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_NUMBER directly 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. 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 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 68/82 A.CONFIGURATION This assumption is covered by OE.CARD_ADMIN_STATION which ensures that assets injected in TOE are consistent. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 69/82 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.1 2 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 2 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 70/82 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. 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 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 71/82 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 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.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 7.2.3 RATIONALE O.USER_AUTHENTICATION is covered by: ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 72/82 • 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 to set 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; • 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/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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 73/82 O.KEY_MANAGEMENT is covered by: • FCS_CKM.1 which ensures user keys can be correctly generated by the TOE; • FDP_ITC.2/keys which 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.1/systemkey supports FCS_COP.1.1 by defining how wrapping which protect the session keys may be imported inside 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.WIPE are 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 74/82 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 75/82 7.3 GLOBAL TOE SPECIFICATION RATIONALE 7.3.1 MAPPING TOE SFRS TO TOE SECURITY FUNCTIONS 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_authentication SF.CR_key_derivation 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 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 FCS_CKM.1 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 FPT_TDC.1 X X FMT_MSA.1/keys X X FMT_MSA.2/keys X X FDP_ITC.1.1/systemkey X FTP_TRP.1 X FDP_RIP.1 X FMT_SMR.1 X FMT_SMF.1 X X ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 76/82 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_CODE SF.IA_EPHEMERAL_SECURITY_CODE SF.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) components are 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. FCS_COP.1 (Cryptographic operation) defines how the TOE shall perform cryptographic operation. This component is instantiated for: • Diffie-Hellman operation • AES operation • HMAC MAC operation • EMAC MAC operation • RSA signature • RSA encryption • Random generation. These requirements are met respectively by: • SF.CR_AUTHENTICATION • SF.CR_AES and SF.CR_KEY_DERIVATION • SF.CR_AUTHENTICATION ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 77/82 • 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 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_user which defines the management operation on user keys. The FDP_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. 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. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 78/82 8. CONSISTENCY OF COMPOSITE PRODUCT SECURITY TARGET 8.1 SEPARATION OF TSF The composite product offers the full security functionality of the platform: the application 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]. Therefore every TSF from the platform is required to counter these threats and is relevant for the composite product. No separation is necessary. 8.2 COMPATIBILITY OF SAR The following table summarizes the SAR for both the composite product and the platform, showing that every composite SAR is weaker than or equal to platform 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 ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 79/82 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) 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 Authentication codes (security code, ephemeral code and PUK codes) are stored as OwnerPIN objects. FIA_UAU.4 FIA_AFL.1/Pin The cryptosmart applet stores PUK code as OwnerPin objects with maximum authentication attempts defined to 1. FIA_SOS.1 None FIA_SOS.2 FCS_RNG.1/IC FCS_COP.1/AES These secrets are generated by the TOE using the internal random generator post-processed by AES using 128 bits key. The key size used is consistent with the platform SFR. FIA_AFL.1 FIA_AFL.1/Pin 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/IC FCS_COP.1/AES The applet only uses 128 and 256 bits AES keys which are consistent with the platform SFR. FCS_COP.1.1/HMAC FCS_COP.1/SHA The applet performs HMAC-SHA256 based on the SHA256 defined by this SFR. HMAC mode is implemented by the applet. FCS_COP.1.1/EMAC FCS_COP.1/AES 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 The applet only uses 2048 bits RSA keys which is consistent with the platform SFR. FCS_COP.1.1/RSA_enc FCS_COP.1/RSA The applet only uses 2048 bits RSA keys which is consistent with the platform SFR. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 80/82 Composite SFR Based on (platform SFR) Statement of compatibility FCS_COP.1.1/random FCS_RNG.1/IC FCS_COP.1/AES The applet generates random number by: - Generating a random buffer using the SecureRandom javacard object - Re-encrypting it with AES with 128 bits keys; which is consistent with the platform SFR FCS_CKM.2 FCS_CKM.2 User keys are imported then stored in javacard objects using the setKey() method. FCS_CKM.4 FCS_CKM.4 Keys are cleared by the applet first by zeroizing the key, then clearing it using the clearKey() method. FDP_ACC.2/keys None. FDP_ACF.1/keys None. FDP_ETC.1/keys None. FDP_ITC.2/keys None. FPT_TDC.1 None. FMT_MSA.1/keys None. FMT_MSA.2/keys None. FDP_ITC.1.1/systemkey None. FTP_TRP.1 FCS_COP.1/AES Trusted path protection is based on AES (for encryption and integrity) with 128 bits keys; which is consistent with the platform SFR FDP_RIP.1 FDP_RIP.1.1/KEYS Session keys are stored as javacard key objects and benefit from the FDP_RIP.1.1/KEYS SFR. FIA_UID.1 None FMT_SMR.1 None FMT_SMF.1 None 8.4 COMPATIBILITY OF SECURITY OBJECTIVES All the platform security objectives are relevant to the composite security target. The security objectives of the composite security target can be divided into security objectives corresponding to: • Platform only security objectives. (Some of them where explicitly included in this security target as they directly cover some threats considered in this security target). These are all security objectives from [IOC7-ST] • Applet-specific security objectives based on security objectives provided by the platform; • Applet-specific properties concerning access control of the cryptosmart applet functions and protection of the application data. Security objective Applet specific, based on platform Applet specific, ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 81/82 independent from platform O.USER_AUTHENTICATION O.PIN-MNGT (user security code and PUK are managed as platform Pin objects) O.SECURE_COMPARE (ephemeral security code are stored as array) O.PUK_UNBLOCK O.PIN-MNGT (PUK codes are managed as platform Pin objects) O.STRONG_SECCODE X O.LIMITED_AUTH_NUMBER O.PIN-MNGT (user security code and PUK are managed as platform Pin objects which manage the failure limit) O.FUNCTION_ACCESS_CONTROL X O.CRYPTOGRAPHIC_OPERATION O.CIPHER O.SCP.IC: cryptographic operation done by the applet use platform provided cryptographic functions. O.STRONG_MUTUAL_AUTHENTICATION O.CIPHER O.SCP.IC: cryptographic operation done by the applet use platform provided cryptographic functions. O.KEY_MANAGEMENT O.KEY-MNGT: user keys are managed as platform key object O.PROTECT_SESSION_KEY O.CIPHER: key wrapping is performed using platform provided cryptographic functions O.APDU_ENCRYPTION O.CIPHER: APDU encryption is performed using platform provided cryptographic functions O.SENSITIVE_MEMORY_ERASING O.KEY-MNGT: for user keys as the platform provides a method to clear keys. O.WIPE O.KEY-MNGT: for user keys as the platform provides a method to clear keys. 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, T.INTEG_APPLI_CODE); • Applet specific threats. The threats of the composite security target are not contradictory to the relevant threats of the platform security target. ERCOM - 6, rue Dewoitine - 78140 VELIZY - FRANCE Tél: +33 1 39 46 50 50 Fax: +33 1 39 46 25 25 Ed : 2010B/346 Ver. : 5.0.8 CryptoSmart card 5.0 July 13, 2012 Cryptosmart applet 5.0 - Security- target_public.docx Security Target 82/82 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: • 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.