ID-One Cosmo V7-a Smart Card Cryptographic Module FIPS 140-2 Security Policy Public Version Oberthur Technologies of America 4250 Pleasant Valley Road Chantilly, VA 20151-1221 - USA Document Number: SPV7-a.0-n Version 1 Revision Date: December 3, 2009 Copyright Oberthur Technologies 2009 This document may be reproduced only in its original entirety (without revision). Oberthur Technologies Doc Number: SP V7-a Change Record Revision Date Author Description of Change 1 Dec. 3, 2009 C. GOYET Public version Table 1 - Document Version History ID-One Cosmo V7-a Public Security Policy Page 2 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a CONTENTS 1  INTRODUCTION ................................................................................................................................................. 6  1.1  SCOPE ........................................................................................................................................................... 6  1.2  MODULE OVERVIEW ....................................................................................................................................... 6  1.3  MODULE IDENTIFICATION ................................................................................................................................ 7  2  SECURITY LEVEL .............................................................................................................................................. 9  3  CRYPTOGRAPHIC MODULE SPECIFICATION ............................................................................................... 9  3.1  OVERVIEW ..................................................................................................................................................... 9  3.2  CRYPTOGRAPHIC MODULE BOUNDARY .......................................................................................................... 10  3.3  MODULE HARDWARE .................................................................................................................................... 11  3.4  MODULE FIRMWARE ..................................................................................................................................... 11  3.5  MODULE FIRMWARE EXTENSIONS ................................................................................................................. 11  3.6  LOCKS CONFIGURATIONS ..............................................................................................................................12  3.7  ELECTRICAL PROFILE ................................................................................................................................... 12  3.8  FIPS MODE OF OPERATION .......................................................................................................................... 12  3.9  CRYPTOGRAPHIC ALGORITHMS ..................................................................................................................... 13  3.9.1  FIPS Approved Algorithms.................................................................................................................. 13  3.9.2  Cryptographic Padding ....................................................................................................................... 14  3.9.3  Random Number Generators ............................................................................................................. 14  3.9.4  Other Elliptic Curves ........................................................................................................................... 15  3.9.5  Elliptic Curve Diffie-Hellman ............................................................................................................... 15  3.9.6  Key Establishment .............................................................................................................................. 15  3.9.7  Other RSA keys .................................................................................................................................. 15  3.9.8  Global PIN ........................................................................................................................................... 15  3.9.9  Biometric Fingerprint On Card Verification ......................................................................................... 15  4  PORTS AND INTERFACES ............................................................................................................................. 16  4.1  PHYSICAL INTERFACES ................................................................................................................................. 16  4.1.1  Contact Mode ...................................................................................................................................... 16  4.1.2  Contactless Mode ............................................................................................................................... 17  4.2  LOGICAL INTERFACE ..................................................................................................................................... 17  5  ROLES & SERVICES ....................................................................................................................................... 18  5.1  ROLES ......................................................................................................................................................... 18  5.1.1  Concurrent Operators ......................................................................................................................... 18  5.2  ROLE IDENTIFICATION ................................................................................................................................... 19  5.3  ROLE AUTHENTICATION ................................................................................................................................ 19  5.3.1  Card Administrator and Application Provider Authentication .............................................................. 19  5.4  SERVICES .................................................................................................................................................... 20  5.4.1  Card Administrator Services ............................................................................................................... 20  5.4.2  Application Provider Services ............................................................................................................. 22  5.4.3  Public User Services ........................................................................................................................... 23  5.4.4  Delegated Management...................................................................................................................... 23  5.4.5  DAP Verification .................................................................................................................................. 24  5.4.6  Relationship between Roles, Services and CSP Access ................................................................... 25  6  CRITICAL SECURITY PARAMETERS ............................................................................................................ 26  6.1  CARD ADMINISTRATOR KEYS IN ISSUER SECURITY DOMAIN ............................................................................ 26  6.2  APPLICATION PROVIDER KEYS IN APPLICATION SECURITY DOMAINS ............................................................... 26  6.3  OTHER CSP ................................................................................................................................................ 27  6.3.1  DRNG Seed ........................................................................................................................................ 27  7  SELF TESTS ..................................................................................................................................................... 27  7.1  POWER ON SELF TESTS ................................................................................................................................ 27  ID-One Cosmo V7-a Public Security Policy Page 3 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 7.2  CONDITIONAL SELF-TESTS............................................................................................................................ 28  7.2.1  Key Pair-Wise Consistency Tests ....................................................................................................... 28  7.2.2  Continuous Random Number Generator test ..................................................................................... 28  7.2.3  CSP Integrity Test ............................................................................................................................... 28  7.2.4  Software Load Test ............................................................................................................................. 28  8  SECURITY RULES ........................................................................................................................................... 29  8.1  AUTHENTICATION SECURITY RULES............................................................................................................... 29  8.2  APPLICATION LIFE CYCLE SECURITY RULES................................................................................................... 29  8.3  ACCESS CONTROL SECURITY RULES............................................................................................................. 29  8.4  KEY MANAGEMENT SECURITY POLICY ........................................................................................................... 29  8.4.1  Cryptographic keys ............................................................................................................................. 29  8.4.2  Cryptographic key generation ............................................................................................................. 31  8.4.3  Cryptographic key entry ...................................................................................................................... 31  8.4.4  Cryptographic key storage .................................................................................................................. 31  8.4.5  Cryptographic Key Zeroization ........................................................................................................... 31  9  PHYSICAL SECURITY ..................................................................................................................................... 32  10  MITIGATION OF OTHER ATTACKS ............................................................................................................... 33  10.1  POWER ANALYSIS (SPA/DPA)...................................................................................................................... 33  10.2  TIMING ANALYSIS ......................................................................................................................................... 33  10.3  FAULT INDUCTION ......................................................................................................................................... 33  10.4  FLASH GUN .................................................................................................................................................. 34  10.5  ELECTROMAGNETIC ATTACKS ....................................................................................................................... 34  10.6  CARD TEARING............................................................................................................................................. 34  11  SECURITY POLICY CHECK LIST TABLES .................................................................................................... 35  11.1  ROLES AND REQUIRED IDENTIFICATION AND AUTHENTICATION ........................................................................ 35  11.2  STRENGTH OF AUTHENTICATION MECHANISMS .............................................................................................. 35  11.3  SERVICES AUTHORIZED FOR ROLES .............................................................................................................. 35  11.4  MITIGATION OF OTHER ATTACKS ................................................................................................................... 35  12  REFERENCES .................................................................................................................................................. 36  13  DEFINITIONS AND ACRONYMS ..................................................................................................................... 37  13.1  ACRONYMS .................................................................................................................................................. 37  ID-One Cosmo V7-a Public Security Policy Page 4 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a TABLES Table 1 - Document Version History..........................................................................................................2  Table 2 – Commercial product names.......................................................................................................8  Table 3 - Module Security Level Specification...........................................................................................9  Table 4: Firmware Extensions included in this validation ........................................................................11  Table 5: FIPS Approved Algorithms implemented in Current Module .....................................................14  Table 6: Physical Interface for contact mode ..........................................................................................16  Table 7: Transmission parameters for contact mode ..............................................................................16  Table 8: Module Ports and Interfaces......................................................................................................17  Table 9: Roles and required Identification and Authentication ................................................................18  Table 10: Card Administrator Services ....................................................................................................21  Table 11: Application Provider Services ..................................................................................................22  Table 12: Public User Services ...............................................................................................................23  Table 13: Relationship between Roles, Services and CSP Access ........................................................25  Table 14: CSP used ................................................................................................................................30  Table 15: CSP available only to loaded applets ......................................................................................30  Table 16: Roles and required Identification and Authentication ..............................................................35  Table 17: Strength of Authentication Mechanisms ..................................................................................35  Table 18: Services Authorized for Roles .................................................................................................35  Table 19: Mitigation of other attacks .......................................................................................................35  FIGURES Figure 1: Logical Block Diagram of the Oberthur ID-One Cosmo V7-a module ........................................8  Figure 2: Logical Block Diagram of the Oberthur ID-One Cosmo V7 module .........................................20  ID-One Cosmo V7-a Public Security Policy Page 5 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 1 Introduction 1.1 Scope This document defines the Security Policy for the Oberthur ID-One Cosmo V7-a cryptographic module. The module is validated to FIPS 140-2 Level 3. This document contains a description of the cryptographic module, its interfaces and services, the intended operators and the security rules enforced in the approved mode of operation. The ID-One Cosmo V7-a is part of the Oberthur family of cryptographic modules called ID-One Cosmo V7. Modules within this family share the same functionalities and the description of the ID-One Cosmo V7 in the remainder of this document applies to all versions including the “-a” subject to this validation. 1.2 Module Overview The module is a single chip Smart Card micro-controller containing an operating system that loads and runs applications written in Java™ programming language. The main purpose of the module is to provide a secure Smart Card chip Javacard™ platform with data storage and enhanced cryptographic processing capabilities specifically designed to fit the needs of government and enterprise personnel identification applications. Such applications would have to be loaded into the module to provide the business functionality, and the module has been designed to enable a re-validation to be performed in a short time and with the minimum possible risk whenever a FIPS 140-2 validated application is to be loaded into the module. However the validation described in this security policy is limited in scope to the cryptographic module with no loaded applications. The loading of an application voids the FIPS 140-2 validation of the module unless a new validation has been achieved with an extended scope that encompasses the loaded application. The module operating system includes a native implementation of Java Card™ (version 2.2.2) and Open Platform (version 2.1.1.A) specifications with full support for Delegated Management and DAP / Mandated DAP, that defines a secure infrastructure for post-issuance management of programmable platforms. Multiple applications loaded into the module can be securely separated by a firewall. High and low level services, inclusive of communications, memories management (both persistent and volatile), cryptographic algorithms and physical security are addressed. Java Card Services can be accessed by a loaded application using the Java Card™ Application Programming Interface (API). Global Platform Services are provided to an external operator through Security Domains and to a loaded application using the Global Platform API. The module state of the art security architecture benefits from Oberthur’s extensive expertise as a smart card world leader since the inception of smart cards in the late 70’s. It includes software and hardware countermeasures against the latest cryptographic attacks (both passive and active). ID-One Cosmo V7-a Public Security Policy Page 6 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a On-board cryptographic services include, and even exceed in some aspects, NSA SUITE-B cryptography with: • Advanced Encryption Standard (AES up to 256) for encryption/decryption (message confidentiality); • Secure Hash Algorithm (SHA up to 512) for message digest; (message integrity) • Elliptic-Curve Digital Signature Algorithm (ECDSA) with NIST Recommended Elliptic Curves over Prime Field GF(p) up to P-521 for digital signatures (non repudiation). • Elliptic-Curve Diffie-Hellman for key agreement (simplified key management); Additional cryptographic features include Triple DES (128 and 192) and RSA (up to 2048) with a true ANSI X9.31 on-board key generation, ISO 9796, ISO 9797, PKCS#1.5, OAEP, PSS, and FIPS 186-2 Random Number Generators. Card Holder Verification (CHV) services include a built-in on card fingerprint matching engine (Match- On-Card) using ISO/IEC 19794-2 for finger minutia data format. The built in management of Logical Channels allows the module to support multiple applications simultaneously, each with their own Security Domain. The Communication services support ISO/IEC 7816-3 extended length fields, allowing up to 32,767 bytes of data in each direction (In/Out) to be transmitted within a single APDU, as opposed to a maximum of 256 bytes with previous modules. Large files such as Photo ID or X509 certificates can now be read in a single APDU without requiring chaining. Depending on the configuration set during manufacturing, the module can communicate in contact mode and/or in contactless (RF) mode. To protect against skimming and eavesdropping attacks over the contactless interface, and to increase privacy protection of the card holder, all contactless activity with the module can be temporarily or permanently disabled (stealth mode) or restricted to prevent the leaking over the contactless interface of identifiable information. The module operates under multiple classes of voltages (Class A = 5V and Class B = 3V) making it the perfect cryptographic module for a new range of application using lower voltage portable readers. In addition to the security requirements from FIPS 140-2, the module has been independently tested to meet the requirements often asked in Common Criteria Certifications but not addressed by this FIPS 140-2 validation, such as: • Erase transient data on completion of operation execution. • Prevent unauthorized data leakage to non-volatile memory • Prevent data release (cryptographic keys, PINs), by physical/logical means. • Prevent unauthorized data storage, or data overwrite. • The card unlock function can only be performed by an authorized administrator. 1.3 Module Identification The ID-One Cosmo V7 cryptographic module is available in different memory sizes, with or without contactless interface. The memory size and contactless capabilities are adjusted during manufacturing to meet marketing requirements. ID-One Cosmo V7-a Public Security Policy Page 7 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a The following commercial products are available with the version “-a” described in this validation: Product Name Amount of Persistent Contactless Memory (EEPROM) Interface available to customers ID-One Cosmo V7 Basic 32k-> 50k No ID-One Cosmo V7 Standard 60k->80k No ID-One Cosmo V7 Standard Dual 60k->80k Yes ID-One Cosmo V7 Large Dual 128K and above Yes Table 2 – Commercial product names Please note that the above commercial products can be initialized during manufacturing with alternative modes of operation that are not necessarily compliant with FIPS 140-2 but may offer better performances. When required, the FIPS mode of operation MUST be specified at the time of purchasing. Information whether the module has been initialized in FIPS 140-2 mode of operation during manufacturing can be retrieved at any time using the GET DATA command. From 16k up to 128 Kbytes available EEPROM FAT applications Keys certificates Data ICAO LDS application Biometric Match-On-Card Key Generator Biometric API ROM Proprietary APIs to increase performances of ID Applications JAVA Card API 2.2.2 Global platform 2.1.1 JAVA Interpreter 2.2.2 DES/3DES/AES RSA(2048 /ECDSA(GFP) ECDH SHA T=CL T=0 / T=1 BIOS CPU Crypto cells (DES, RSA, ECC) Figure 1: Logical Block Diagram of the Oberthur ID-One Cosmo V7-a module ID-One Cosmo V7-a Public Security Policy Page 8 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 2 Security Level The cryptographic module meets the overall requirements applicable to Level 3 security of FIPS 140-2. Security Requirements Section Level Cryptographic Module Specification 3 Module Ports and Interfaces 3 Roles, Services and Authentication 3 Finite State Model 3 Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of Other Attacks 3 Table 3 - Module Security Level Specification 3 Cryptographic Module Specification 3.1 Overview The ID-One Cosmo V7 is a single chip implementation of a cryptographic module. The module comprises the following elements: 1. Secure Micro-Controller Integrated Circuit (Hardware) 2. Embedded Operating System (Firmware). 3. Common Open Platform Card Manager (Global Platform) 4. Applets (Applications) that are to be installed onto the module (outside the scope of this validation). The micro controller Integrated Circuit provides hardware resources like ROM, RAM, EEPROM, Main CPU and Cryptographic Co-Processors. ID-One Cosmo V7-a Public Security Policy Page 9 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a The Embedded Operating Systems provides the Basic Input/Output System (BIOS), the Javacard Virtual Machine version 2.2.2 with its Runtime Environment and Application Programming interface (API), Oberthur Additional cryptographic API, Biometric API, and fingerprint Match-On-Card. The Common Open Platform Card Manager (COP) provides external interfaces as well as internal API to allow for the mutual authentication of identities using strong cryptography with “off card application” or terminals that they might be connected to, and to secure subsequent communications. A special instance of the Common Open Platform Card Manager is called the Issuer Security Domain. The Issuer Security Domain (ISD) is the on card representative of the Card Issuer. It allows the Card Issuer to manage the applications on the card as well as the card life cycle. Other instances of the COP provide Supplementary Security Domains allowing application providers to separate their key spaces from the Card Administrator. The COP fully complies with the following specifications: • Global Platform o Global Platform 2.1.1 Card Implementation Requirements –March 2003 o Global Platform Card Specification - Version 2.1.1 – Mars, 2003 o Global Platform Card Specification Amendment A – February,2004 • Visa o Visa Open Platform Card Implementation Requirements Configuration 3 – Multiple Security Domains with DAP Capability October 2001 o Visa Global Platform 2.1.1 Card Implementation Requirements May 2003 In addition to the SCP01 and SCP02 Secure channel protocols defined in the above Global Platform Specifications, the COP implements a draft version of Global Platform Card Specification v 2.2 - Amendment D: Secure Channel Protocol 03 that increases the cryptographic strength of existing secure channel protocols SCP01 and SCP02 by replacing TDES with AES. In the scope of this document, there are no applets instantiated other than the Security Domain(s). (Issuer Security Domain and potentially Supplementary Security Domains) Instantiating another (security relevant) applet will require a re-validation and the issuance of a new certificate, even if the new applet itself has been already validated to FIPS 140-2 unto another module. 3.2 Cryptographic Module Boundary The cryptographic module boundary is the edge of the die. The module will typically be embedded into a plastic card body and connected to an ISO 7816-2 compliant contact plate and/or to an external antenna loop. The Cryptographic module boundary separates the chip from the card, contact plate, and external antenna loop. ID-One Cosmo V7-a Public Security Policy Page 10 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 3.3 Module Hardware The following hardware platforms may be used by the ID-One Cosmo V7-a cryptographic module to offer a wider range of EEPROM memory sizes: • For ID-One Cosmo Large, the module HW P/N is BF (with FW version 0801-070531) • For ID-One Cosmo Standard the module HW P/N is C0 and C3 (with FW version 0801-070541) • For ID-One Cosmo Basic the module HW P/N is CF (with FW version 0801-070551) Hardware module Part Number can be read from the Card Identification Data Object under the sub- element with tag ‘01’. 3.4 Module Firmware The module firmware (also called ROM code) is the module Operating System that is written in the micro-controller during chip manufacturing and cannot be subsequently changed. The firmware version supported by the module described in this security policy is: 0801 The module firmware version can be read from the Card Identification Data Object under the sub- element with tag ‘03’. The complete firmware identification is achieved by putting together the firmware version and the firmware extension below. 3.5 Module Firmware Extensions The functionality of the module operating system can be extended through the use of firmware extensions called optional code. Such optional code can be loaded only during manufacturing and cannot be subsequently removed or modified. Functionality that can be added through such firmware extension typically includes critical patches and service packs on the card Operating System. The ID-One Cosmo V7-a cryptographic module has been validated with the following firmware Extension(s): Firmware Firmware Note version Extensions 0801 070531 Generic Codop R1.0 on 0801 on ID-One Cosmo Large (Dual and non Dual) 0801 070541 Generic Codop R1.0 on 0801 on ID-One Cosmo Standard (Dual and non Dual) 0801 070551 Generic Codop R1.0 on 0801 on ID-One Cosmo Basic (Contact only) Table 4: Firmware Extensions included in this validation Module Firmware Extensions can be read from the Card Identification Data Object under the sub- element with tag ‘04’. ID-One Cosmo V7-a Public Security Policy Page 11 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 3.6 Locks Configurations The module includes several locks that can be set by Oberthur during the manufacturing phase to configure the module in a specific electrical configuration and meet customer requirements or export control regulations. Some of the locks could also be set by the Security Officer during the life of the module to activate/deactivate a contactless stealth mode, or to allow only non identifiable information to leak out of the contactless interface until the terminal can be authenticated to increase the privacy protection of the card (or e-Passport) holder. However, the locks that could have an impact on the FIPS mode of operation of the module are non reversible and always set during the manufacturing phase. 3.7 Electrical Profile The module can be configured during manufacturing to meet different customer requirements. Every module delivery is associated with a BAP (Batch Approval Process) document that identifies the module and its specific configuration (electrical profile).The BAP document is prepared by Oberthur Technical support staff after a discussion with the customer regarding their specific needs. The BAP provides identification information (hardware, firmware, firmware extensions, and locks configuration) and specifies if the electrical profile set the module in FIPS mode of operation when it leaves Oberthur factory. The BAP number can be retrieved from the Batch Identifier written in the card during production. 3.8 FIPS Mode of Operation Please make sure you specify at the time of ordering that you want the product to operate in FIPS 140-2 Approved mode as it may not be the default configuration from all Oberthur factories. Modules that are not configured in FIPS 140-2 Approved mode of operation during manufacturing offer better performances for short transactions such as physical access control as time consuming cryptographic Known Answer Test (KAT) are no longer performed systematically during the power-up initialization sequence but only prior to the first use of the algorithm (which may not always happen if not all algorithms are used during each session). The KAT can also be completely disabled during manufacturing for configuration where speed is more important than security, but the resulting module will not be in FIPS 140-2 Approved mode of operation. Once set during manufacturing, the FIPS mode of operation cannot be changed. Oberthur technical support staff is fully trained to discuss your needs in terms of level of security and mode of operation and can make sure the electrical profile prepared for you sets the module in a FIPS mode of operation. Modules in FIPS 140-2 Approved mode are listed as such in the BAP document associated with your delivery. Once set in FIPS mode during manufacturing, the module only provides a FIPS Approved mode of operation, comprising all the services described in section 5 below. The module will enter a FIPS Approved mode following a successful power up initialization. ID-One Cosmo V7-a Public Security Policy Page 12 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a It is possible at anytime during the life of the module to know if the module is in FIPS mode of operation by checking the value of the FIPS mode lock that can be read from the Card Identification Data Object under the sub-element with tag ‘05’ (FIPS Mode). If set to ‘01’, the module is in FIPS mode of operation. In addition Modules in FIPS mode have the Issuer Security Domain (ISD) in OP-SECURED state. 3.9 Cryptographic Algorithms The purpose of the cryptographic module is to provide a FIPS approved Javacard Chip Platform for applications that may in turn provide cryptographic services to end-user applications. A variety of algorithms are used in the module to provide cryptographic services. Some of these cryptographic services are made available only to applications via internal APIs. Since the module described in this security policy does not include any instantiated applications, some security services may not be available to any operator of the module. There are however listed in this section to inform applet developers of all cryptographic services built into the module. Please contact Oberthur for further information on these cryptographic services. 3.9.1 FIPS Approved Algorithms The following table list the cryptographic algorithms that have been validated on the ID One Cosmo V7- a module. Bits of CAVP Algorithm Key Size Modes Security Cert. # ECB and CBC in both Encryption and Decryption 128 bits 80 TDES 770 ECB and CBC in both Encryption and Decryption 192 bits 112 MAC Mode 128 bits 80 770, TDES MAC vendor 192 bits 112 MAC Mode affirmed 128, bits 128, AES ECB and CBC in both Encryption and Decryption 192 bits 192, 978 256 bits 256 80 SHA-1 112 SHA-224 128 SHA-256 Byte-oriented messages N/A 949 192 SHA-384 256 SHA-512 ID-One Cosmo V7-a Public Security Policy Page 13 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a FIPS 186-21 DRNG 555 GenKey (ANSI X9.31) Modulus sizes: SigGenPKCS1.5 with SHA-1, SHA-256, SHA-384 and SHA-512 1024 80 RSA SIgGenPSS with SHA-1, SHA-256, SHA-384 and SHA-512 to to 471 2048 112 SigVerPKCS1.5 with SHA-1, SHA-256, SHA-384 and SHA-512 in 32 bit increments SigVerPSS with SHA-1, SHA-256, SHA-384 and SHA-512 Key Pair Generation Curves: P-192, 80 SigGen with SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 P-224, 112 ECDSA 120 P-256, 128 P-384, 192 SigVer with SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 P-521 256 Table 5: FIPS Approved Algorithms implemented in Current Module Note that SHA-224, SHA-256, SHA-384, SHA 512, RSA Signature Generation, RSA key generation, and all ECDSA functionalities are only available through APIs to be called by loaded applications. They are not used by the current module. 3.9.2 Cryptographic Padding The ID One Cosmo V7 module has a native implementation of the following padding schemes to be used with the above cryptographic algorithms: • ISO/IEC 9796; Digital signature schemes giving message recovery. • ISO/IEC 9797, Message Authentication Codes (MACs). • PKCS#1 v2.1 signature and encryption schemes using RSA. • OAEP (Optimal Asymmetric Encryption Padding) for encryption. • PSS (Probabilistic Signature Scheme) for signature. These padding schemes are available from the module via internal APIs. 3.9.3 Random Number Generators The cryptographic module offers the services of a FIPS 140-2 approved DRNG (Deterministic Random Number Generator). See Table 5 The cryptographic module also offers the services of a hardware based NDRNG (Non Deterministic Random Number Generator), which can be used to generate a seed to feed the DRNG and increase its quality. 1 FIPS PUB 186-2 “Digital Signature Standard”, appendix 3.1 “Random Number Generation for the DSA”, section 3.4 ”Constructing the function G from the DES" updated with Change Notice 1 for General Purpose Random Number Generation. ID-One Cosmo V7-a Public Security Policy Page 14 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 3.9.4 Other Elliptic Curves Other Elliptic Curves using GF(P) with “f” from 160 to 521 are available to loaded applets through internal APIs. 3.9.5 Elliptic Curve Diffie-Hellman Elliptic curve secret value derivation primitive, Diffie-Hellman version, with or without cofactor multiplication, as per IEEE P1363 are available to loaded applets through internal APIs. 3.9.6 Key Establishment Key agreements services based on Diffie Helman and Diffie Helman Elliptic Curves are available to loaded applets through internal APIs. Key transport is performed by TDES or AES. TDES key establishment provides 80 bits of encryption strength and AES key establishment 128 bits of security. 3.9.7 Other RSA keys The The ID One Cosmo V7-a module makes available to loaded applets through internal API additional RSA key sizes that are not allowed by NIST. These have a modulus size from 64 to 992 by steps of 32 bits. It is the responsibility of the developer of the FIPS validated applet to ensure that these key sizes are not used in FIPS validated modules. 3.9.8 Global PIN The module supports the Global Platform PIN available to loaded application through the Global Platform API. It is not used by the cryptographic module is the configuration described in this security policy as no applet is loaded to exercise this functionality. 3.9.9 Biometric Fingerprint On Card Verification The module supports fingerprint match on card functionality through API. It is not used by the cryptographic module in the configuration described in this security policy as no applet is loaded to exercise this functionality. ID-One Cosmo V7-a Public Security Policy Page 15 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 4 Ports and Interfaces The ID-One Cosmo V7 supports two modes of operations: Contact mode and contactless mode. Contact communication is achieved through a physical connection to a smart card contact plate. Contactless communication is achieved through a physical connection to a loop antenna. Neither the contact plate nor the antenna is within the cryptographic boundaries of the module. The mode of operation is determined at power-up, depending on the interface (contact or contactless) that powers the module. It cannot be changed until the module is reset. 4.1 Physical Interfaces 4.1.1 Contact Mode In contact mode, the cryptographic module follows the standard ISO/IEC 7816 part 2 and 3 for physical and logical interfaces: Pin FIPS 140-2 Designation Description Vcc Power supply input Both Class A (5V) and Class B (3V) supported RST Control input External Reset Signal CLK Control input External Clock Signal (1 to 10Mhz) to transmit data over I/O line. Internally the card relies on an uninterrupted internal oscillator to drive the main processor and all cryptographic co-processors independently of the external clock. I/O Data input, Control input, See transmission parameters below Data output, Status output GND Ground Reference Voltage Table 6: Physical Interface for contact mode Transmission parameters The module supports two transmission half duplex oriented ISO protocols: T=0 and T=1. The data communication speed on the I/O line is defined by the Values of the clock rate conversion integer (Fi) and the baud rate adjustment integer (Di) agreed upon between the reader and the module during the power on sequence. The values supported by the module are as follows (see ISO 7816- 3:2006): DI F D FI I/O Communication Speed with External clock at 5MHz 372 1 13,440 bauds 1 1 372 2 26,881 bauds 1 2 372 4 53,763 bauds 1 3 372 12 161,290 bauds 1 8 512 8 78,125 bauds 9 4 512 16 156,250 bauds 9 5 512 32 312,500 bauds 9 6 512 64 9 7 625,000 bauds Table 7: Transmission parameters for contact mode ID-One Cosmo V7-a Public Security Policy Page 16 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a Up to 32,767 data bytes can be exchanged in each direction within a single command (using APDU with Extended Length Field). 4.1.2 Contactless Mode In contactless mode, the cryptographic module follows the standard ISO/IEC 14443 Type B, RF Interface for physical and logical interfaces: It uses only two electrical connections, LA and LB, which are physically different and distinct from the electrical connections used in contact mode. LA and LB are connected to an external antenna loop which provides power when in presence of a proximity RF field. Data input, control input, data output, status output are transmitted through the antenna using signal modulation as specified in ISO 14443. Depending on the configuration set during manufacturing, the supported bit-rates are: • 106 Kbits/s • 212 Kbits/s • 424 Kbits/s • 848 Kbits/s Up to 32,767 data bytes can be exchanged in each direction within a single command (using APDU with Extended Length Field). 4.2 Logical Interface The module functions as a slave processor to process and respond to the reader commands. The I/O ports2 of the module (either physical in contact mode or virtual in the case of RF transmission) provide the following logical interfaces: Logical Contact Mode Contactless Mode Interface (ISO 7816) (ISO 14443) Data Input: I/O Pin LA and LB (RF Modulation) Data Output: I/O Pin LA and LB (RF Modulation) Status Output: I/O Pin LA and LB (RF Modulation) Control Input: I/O, Clk and Reset Pins LA and LB (RF Modulation) Power Input VCC and GND LA and LB (RF Modulation) Table 8: Module Ports and Interfaces Synchronization timing controls, provided in part by the module clock input CLK in contact mode or the modulation on the carrier in contactless mode, manages the separation of these logical interfaces that use the same physical port. 2 Two ports due to contact and contactless mode of communications. ID-One Cosmo V7-a Public Security Policy Page 17 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 5 Roles & Services 5.1 Roles Cryptographic Officer Roles This role is responsible for managing the security configuration of the module. The CA authenticates to the module through a Global Platform (GP) mutual Card Administrator authentication protocol with the Issuer Security Domain (ISD). (CA) A successful authentication demonstrates the knowledge of the ISD Global Platform Keyset and establishes a GP Secure Channel Session to execute services allowed to the CA in a secure manner. (See Global Platform Specifications for more details) User Roles This role is responsible for managing the security configuration of a loaded application. The AP authenticates to the module through a Global Platform (GP) mutual Application Provider authentication protocol with the Application Security Domain (ASD). (AP) A successful authentication demonstrates the knowledge of the ASD Global Platform Keyset and establishes a GP Secure Channel Session to execute services allowed to the AP in a secure manner. (See Global Platform Specifications for more details) No Roles Public Operator This role is available to any operators without authentication. It can only (PO) access non security relevant services provided by the module. Maintenance Roles None The module does not support any maintenance role. Table 9: Roles and required Identification and Authentication 5.1.1 Concurrent Operators The cryptographic module offers multiple logical data in/out interface to external operators through the use of Logical Channels as defined by Global Platform. Logical Channels facilitate the possibility of the above external entities to communicate concurrently with multiple applications on the card, each within its own secure channel session. However only one communication session can be open per authenticated role. ID-One Cosmo V7-a Public Security Policy Page 18 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 5.2 Role Identification The cryptographic module performs identity based authentication using application identifier and cryptographic keys. The application identifier for the Card Administrator is the AID of the Issuer Security Domain (ISD). The application identifier for the Application Provider is the AID of the Application Security Domain (ASD). Within each application, a unique ID and version number are associated with each cryptographic keys to uniquely identify the off-card identity performing the authentication. See Global Platform Specifications for more details. 5.3 Role Authentication The cryptographic module supports identity based authentication of the Card Administrator and Application Provider using Global Platform EXTERNAL AUTHENTICATE function. This authentication mechanism has the following properties: • The probability is less than one in one million (<10-6) that a random authentication attempt succeeds. • During any one minute period, the probability is less than one in one hundred thousand (<10-5) that a random authentication attempt succeeds. This mechanism includes au audit log that tracks unsuccessful authentication together with a timing mechanism that introduces an exponential delay after a failed authentication before a new attempt can be accepted. This provides a strong protection against brute force attacks as no more than a few consecutive unsuccessful authentication attempts are possible within one minute. The authentication remains valid until one of the following conditions is initiated: • Selection of another application on the same logical channel • Unsuccessful authentication attempt • Card reset. (power-off) 5.3.1 Card Administrator and Application Provider Authentication The Card Administrator and Application Provider authenticate by opening a Global Platform Secure Channel Session with respectively the Issuer Security Domain and the Application Security Domain. This Secure Channel Session establishment involves three APDU commands as follows: ID-One Cosmo V7-a Public Security Policy Page 19 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a Figure 2: Logical Block Diagram of the Oberthur ID-One Cosmo V7 module 5.4 Services 5.4.1 Card Administrator Services The following table lists the services that the module make available to the Card Administrator. Authentication This command is used by the CA to initiate a Global Platform Secure INITIALIZE UPDATE Channel Session, setting the key set version and index. This command is used by the CA to open a Global Platform Secure Channel EXTERNAL Session with the Issuer Security Domain, in order to communicate in a secure AUTHENTICATE and confidential way. Card Content Management This command is used by the CA to add an application to the module. INSTALL This command is used by the CA to load the byte-code of a new application (executable load file). For the module to remain FIPS validated, this LOAD command shall not be used to load non FIPS approved executable code. This command is used by the CA to delete a uniquely identifiable object. The DELETE object may be an Application, a load file, or a key set. ID-One Cosmo V7-a Public Security Policy Page 20 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a This command is used by the CA to add or replace ISD keys. Keys are loaded protected by the double encryption of the global Platform Secure Channel and a KCV is included in the transmission to ensure integrity of the key loading operation. PUT KEY This command is also used by the CA to load RSA public keys such as the Token Verification Key or the DAP Verification Key. These keys are used for Delegated Management and DAP verification as specified by Global Platform. This command is used by the CA to transfer data to the module. It is also used to clear the audit log and to modify the contactless capabilities (activate/deactivate a contactless stealth mode, or to allow only non STORE DATA identifiable information to leak out of the contactless interface until the terminal can be authenticated) to increase the privacy protection of the user. This command is used by the CA to temporary lock an application, and to SET STATUS unlock it later on. It can also be used to terminate the crypto module. This command is used by the CA to retrieve identification and life cycle status information for all applications, executable load files, and security domains present in the module. It can also be used by the CA to verify that GET STATUS the module is still in the FIPS validated configuration and that only FIPS approved applications are available. Delegated Management gives the CA the possibility of empowering an AP DELEGATE the ability to initiate approved and pre-authorized Card Content changes MANAGEMENT (loading, installation, extradition or deletion) on his behalf. Public Commands This command is used for selecting an application (Card Manager, Security Domain or Applet Instance) on a specific logical channel. A successful SELECT selection logs out the role currently active on the same logical channel, if any. This command allows opening or closing a logical channel in the card. Up to MANAGE CHANNEL 4 logical channels may be open at a time. The GET DATA command is used to retrieve public data from the selected GET DATA application. No CSP can be read using this service. Table 10: Card Administrator Services ID-One Cosmo V7-a Public Security Policy Page 21 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 5.4.2 Application Provider Services The following table lists the services that the module make available to the Application Provider. Authentication This command is used by the AP to initiate a Global Platform Secure INITIALIZE UPDATE Channel Session, setting the key set version and index. This command is used by the AP to open a Global Platform Secure Channel EXTERNAL Session with the Application Security Domain, in order to communicate in a AUTHENTICATE secure and confidential way. Card Content Management DAP verification allows the module to check the CA signature on an application code being loaded and abort the loading if the signature is not DAP VERIFICATION verified. Such verification can be made mandatory or optional. The optional DAP functionality is allowed in the Approved mode. This command is used by the CA to delete a uniquely identifiable object. The DELETE object may be an Application, a load file, or a key set. This command is used by the CA to add or replace ISD keys. Keys are loaded protected by the double encryption of the global Platform Secure Channel PUT KEY and a KCV is included in the transmission to ensure integrity of the key loading operation. This command is used by the CA to transfer data to the module. STORE DATA This command is used by the CA to temporary lock one of its application, SET STATUS and to unlock it later on. This command is used by the CA to retrieve identification and life cycle status information for all applications, executable load files, and security GET STATUS domains present in the module. Public Commands This command is used for selecting an application (Card Manager, Security Domain or Applet Instance) on a specific logical channel. A successful SELECT selection logs out the role currently active on the same logical channel, if any. This command allows opening or closing a logical channel in the card. Up to MANAGE CHANNEL 4 logical channels may be open at a time. The GET DATA command is used to retrieve public data from the selected GET DATA application. No CSP can be read using this service. Table 11: Application Provider Services ID-One Cosmo V7-a Public Security Policy Page 22 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 5.4.3 Public User Services The following table lists the services that the module make available to without authentication (unauthenticated service). Public Commands This command is used for selecting an application on a specific logical channel. A successful selection logs out the role currently active on the same SELECT logical channel, if any. This command allows opening or closing a logical channel in the card. Up to MANAGE CHANNEL 4 logical channels may be open at a time. The GET DATA command is used to retrieve public data from the selected GET DATA application. No CSP can be read using this service. Table 12: Public User Services 5.4.4 Delegated Management The design of the module from Oberthur takes into account the possibility that the the Card Administrator (Card Issuer) may not necessarily want to manage all Card Content changes, especially when the Card Content does not belong to the Card Issuer. The concept of Delegated Management defined by Global Platform gives the Card Administrator the possibility of empowering Application Providers the ability to initiate approved and pre-authorized Card Content changes (loading, installation, extradition3 or deletion). This approval, which is central to the concept of Delegated Management, ensures that only Card Content changes that the Card Administrator has authorized will be accepted and processed by the module. This delegation of control in the Card Content changes gives the Application Provider more flexibility in managing its Application. The Security Domain with the delegated management privilege allows making: • Delegated loading (requires a pre-authorization) • Delegated installation (requires a pre-authorization) • Delegated extradition (requires a pre-authorization) • Delegated deletion (no pre-authorization required) The Delegated Management is based on the use of Token. A token is a cryptographic value provided by the Card Administrator as proof that a specific Delegated Management operation has been authorized. Delegated Management Tokens are RSA PKCS#1 signatures of one or more Delegated Management functions and a hash of associated data (loading application code, installing Applications and extraditing Applications) generated by the Card Issuer (Cryptographic Officer) outside of the crypto module and 3 Application Extradition allows an Application that is already associated with a Security Domain to be extradited and associated with another Security Domain ID-One Cosmo V7-a Public Security Policy Page 23 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a transmitted to a user with Delegated Management privilege. The public RSA key KTOKEN, associated with the Card Administrator token signature private RSA key, must be present in the Issuer Security Domain. When the Application Provider wants to perform the pre-authorized function, it appends to the function’s data transmitted through a secure channel with its Application Security Domain (ASD) the associated token. The ASD will then decrypt and verify the secure channel communication using its ASK. The function and its associated Token are then automatically transmitted to the Issuer Security Domain for token verification using the Card Administrator KTOKEN Public RSA key. If the signature is verified, the function is authorized to complete. Otherwise, it is aborted and cleared from memory. The Card Issuer's security policy may require the generation of Receipts for Delegated Management operations. A Receipt is a cryptographic value (TDES MAC on the receipt data) generated by the Issuer Security Domain KRECEIPT key to provide confirmation from the card that a successful card content management function has occurred through the delegated installation process. The Install Receipt is comprised of data related to the delegated card content management function including Card Unique Data generated by the Issuer Security Domain. The Issuer Security Domain also keeps track of a Confirmation Counter value that is incremented when generating each Receipt. See Global Platform Specification fur further details on Delegated Management. 5.4.5 DAP Verification If the Application Provider does not have a Security Domain capable of Delegated Management to load application code to the card, it may rely on the loading services of the Card Administrator and require a check of application code integrity and authenticity by the module before the application code is loaded. Likewise, a Controlling Authority may mandate a check of application code integrity and authenticity before the application code is loaded, installed and made available to the Cardholder by the Card Administrator or by an Application Provider with Delegated Management. The DAP Verification privilege for a Security Domain provides this service on behalf of an Applet Provider. The mandated DAP Verification privilege provides this service on behalf of a Controlling Authority. Loading of external code is optional. If non-validated firmware is loaded, the module is no longer FIPS validated. The way it works is as follows: The Applet Provider or Controlling Authority first computes a SHA-1 message digest of the application that is to be subsequently loaded into the module. it then uses his DAP RSA private key (matching the public key KDAP in the Security Domain) to sign the previously calculated hash. The result, called DAP, is sent to the personalization entity together with the application code itself. When the application must be loaded into the card, the Security Domain with DAP verification uses its DAP public key KDAP to check the DAP signature. The application code can be loaded into the module only if the verification succeeds. See Global Platform Specification fur further details on DAP verification. ID-One Cosmo V7-a Public Security Policy Page 24 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 5.4.6 Relationship between Roles, Services and CSP Access CSP involved Card Application CSP Public Roles/Services Administrator Provider Access Operator From (CA) (AP) type From CA AP INSTALL X CSK Execute LOAD X CSK Execute DELETE X X CSK ASK Execute CSK, CDK, ASK, Execute, PUT KEY X X KTOKEN, ADK Write KDAP STORE DATA X X CSK ASK Execute SET STATUS X X CSK ASK Execute GET STATUS X X CSK ASK Execute INITIALIZE UPDATE X X CDK, ADK, EXTERNAL AUTHENTICATE X X Execute CSK ASK CSK, KTOKEN, DELEGATE MANAGEMENT X Execute KRECEIPT DAP VERIFICATION X KDAP Execute SELECT X MANAGE CHANNEL X GET DATA X Table 13: Relationship between Roles, Services and CSP Access ID-One Cosmo V7-a Public Security Policy Page 25 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 6 Critical Security Parameters The following describes CSP that are available to an operator as a service from the ISD or ASD. There is no interface to retrieve any of these CSPs. 6.1 Card Administrator Keys in Issuer Security Domain 1. CDK: This CSP is a set of three Keys, called CDKENC CDKMAC and CDKKEK of 16 bytes each. Depending on the initialization of the Issuer Security Domain, these keys are Triple DES 128 or AES 128 keys. The first two, CDKENC and CDKMAC, are only used to derive Secure Channel session keys (CSKENC and CSKMAC) during the initiation of a Global Platform Secure Channel, and the last one, CDKKEK is used to encrypt CDK keys to be loaded into the Issuer Security Domain using the PUT KEY command. The process used to generate a unique CDK per cryptographic module takes place outside of the crypto module. The loading of a new CDK key is done with a PUT KEY command and is protected by a Global Platform Secure Messaging using another CDK. 2. CSK: Card Administrator Session Keyset: Set of two transient Keys (called CSKENC and CSKMAC) of 16 bytes each generated by diversification of the CDK as per Global Platform specifications [6] CSKENC is used for Secure Channel Encryption, and CSKMAC is used for Secure Channel MAC verification and to authenticate the operator. CSK keys are used with the same algorithm (Triple DES 128 or AES 128) as the CDK from which they derived. 3. KTOKEN: Key Token: Public RSA Key (1024 bits) used to verify the tokens included in Delegated Management commands that embed the signature of these commands as per Global Platform [6]. This key may or may not be loaded into the module. It is an added feature and is not intended to satisfy any of the FIPS 140-2 requirements for applet loading. 4. KRECEIPT: Key Receipt: Triple DES 128 Key used to compute a receipt on Delegated Management Commands as per Global Platform specifications [6]. This key may or may not be loaded into the module. It is an added feature and is not intended to satisfy any of the FIPS 140-2 requirements for applet loading. 6.2 Application Provider Keys in Application Security Domains 1. ADK: This CSP is a set of three Keys, called ADKENC ADKMAC and ADKKEK of 16 bytes each. Depending on the initialization of the Application Security Domain, these keys are Triple DES 128 or AES 128 keys. The first two, ADKENC and ADKMAC, are only used to derive Secure Channel session keys (ASKENC and ASKMAC) during the initiation of a Global Platform Secure Channel, and the last one, ADKKEK is used to encrypt ADK keys to be loaded into the Application Security Domain using the PUT KEY command. The process used to generate a unique ADK per cryptographic module takes place outside of the crypto module. ID-One Cosmo V7-a Public Security Policy Page 26 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a The loading of ADK keys set is done with a PUT KEY command and is protected by a Global Platform Secure Messaging using another ADK. 2. ASK: Applet Provider Session Keyset: Set of two transient Keys (called ASKENC and ASKMAC) of 16 bytes each generated by diversification of the ADK as per Global Platform specifications [6]. ASKENC is used for Secure Channel Authentication and optionally Encryption, and ASKMAC is used for Secure Channel MAC verification and to authenticate the operator. ASK keys are used with the same algorithm (Triple DES 128 or AES 128) as the ADK from which they derived. 3. KDAP: Key DAP: Public part of the Card Administrator RSA DAP Key (1024 bits) used verify the signature of a executable load file being loaded by the Application Provider. This key may or may not be loaded into the module. It is an added feature and is not intended to satisfy any of the FIPS 140-2 requirements for applet loading. This key is present only in Security Domain with DAP Verification. See Global Platform Specification for more information on the use of DAP. 6.3 Other CSP 6.3.1 DRNG Seed The seed used by the DRNG is a 20 byte value generated by the Hardware NDRNG. To get the best possible entropy, only 40 bytes are retrieved from the DRNG before it is re-seeded from the Hardware NDRNG. 7 Self Tests 7.1 Power on Self Tests Each time the module is powered by a reader (contact or contactless), a “reset” signal is sent from the reader to the module. The module then performs a series of GO/NO-GO tests to validate that the cryptographic module is in good working order before it answers subsequent card commands. The Power-up self-tests include: • System tests • EEPROM code integrity check • Cryptographic algorithm tests (KAT) o Random Generator o CRC Algorithms o SHA hashing algorithms (SHA-1, SHA 224, SHA 256, SHA 386, SHA 512) o TDES – Encryption and Decryption o AES Encryption and Decryption o RSA – Signature and Verification ID-One Cosmo V7-a Public Security Policy Page 27 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a o Elliptic Curves ECDSA – Signature and verification Additional tests to protect against new types of attacks such as SPA, DPA, “flash gun”, EMI etc, are also performed at this stage. The module does not respond to any commands while self-tests are being performed. If any of the above tests fail, the card returns an error status before entering an error state in which further commands are not processed. 7.2 Conditional Self-Tests 7.2.1 Key Pair-Wise Consistency Tests RSA Key generation: After generating an RSA key pair, the module performs a double pair-wise consistency check to validate that the newly generated key pair for both signature/verification and encryption/decryption. Elliptic Curve Key generation: In the current implementation, the pair-wise consistency check on newly generated ECC keys is under the responsibility of the application (applet) calling on the ECC Key generation API. 7.2.2 Continuous Random Number Generator test Continuous testing is performed on every output of the Random Number Generators. (Both Deterministic and Non Deterministic) RNGs. Additional statistical testing is also performed to ensure the highest possible quality of the generated random numbers. 7.2.3 CSP Integrity Test Each time a Critical Security Parameter is used, its integrity is checked. 7.2.4 Software Load Test Application loading follows the Global Platform specifications. At a minimum, a MAC of the executable load file is verified each time an applet is loaded onto the cryptographic module. ID-One Cosmo V7-a Public Security Policy Page 28 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 8 Security Rules This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-2 Level 3 module. 8.1 Authentication Security Rules The module implements identical authentication mechanisms for each of its roles. Each authentication mechanism includes verification of the knowledge of a secret shared between the module and the external operator, and for each restricted service, verification that the authentication security status is granted. Each of these secrets is referenced with a unique identifier that is used by the external operator to identify them: • For the Card administrator (CA), the secret is the CDK (see 6.1) and the identifier is a combination of the ISD AID (Application Identifier) and the key set ID within the ISD. • For the Application Provider (AP), the secret is the ADK (see 6.2) and the identifier is a combination of the ASD AID (Application Identifier) and the key set ID within the ASD. 8.2 Application Life Cycle Security Rules Application loading is one of the services provided by the module operating system that is restricted to the Card Administrator or the Application Provider: It can be performed only within a GP secure channel that provides authentication of the role and integrity of the application executable code (Applet) being loaded. The loading and installation of FIPS validated applications may occur before, during, or after card issuance. For the module to run in a validated FIPS 140-2 Level 3 mode of operation, all applets must be validated to the same level prior being loaded into the module. It is the responsibility of the Cryptographic Officer to insure that applets loaded post-validation have been FIPS 140-2 Level 3 validated. The module validation to FIPS is no longer valid once a non-validated applet is loaded. 8.3 Access Control Security Rules CDK and ADK Keys must be loaded through a secure channel session ensuring their integrity and confidentiality. 8.4 Key Management Security Policy 8.4.1 Cryptographic keys The module uses the following CSPs: ID-One Cosmo V7-a Public Security Policy Page 29 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a Key Name Type Length Strength (CSP) CDK DES TDES 128-bits 80-bits ADK DES CSK DES TDES Session Keys 128-bits 80-bits ASK DES CDK AES AES 128-bits 128-bits ADK AES CSK AES AES Session Keys 128-bits 128-bits ASK AES KDAP RSA Public Key 1024 bit 80-bits KTOKEN RSA Public Key 1024 bit 80-bits KRECEIPT TDES 128-bits 80-bits Table 14: CSP used In addition, the module supports a large range of FIPS-Approved or FIPS-Allowed symmetric and asymmetric keys available to loaded applets through Java API: Key Name Type Length Strength TDES TDES ECB and CBC 192-bits 112-bits Keys 128-bits 128-bits AES Keys AES ECB and CBC 192-bits 192-bits 256-bits 256-bits RSA 1024 to 80 to112 RSA Keys Signature & Verification» 2048 bits bits Key Wrapping & Unwrapping P-192, 192, 80 P-224, 224, 112 ECC Keys P-256, 256, 128 P-384, 384, 192 P-521 521 256 Table 15: CSP available only to loaded applets ID-One Cosmo V7-a Public Security Policy Page 30 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 8.4.2 Cryptographic key generation • TDES and AES Session key generation using FIPS186-2 approved DRNG for secure channel opening. • RSA key pair generations (up to 2048 bit key length) fully compliant with ANSI X9.31 and using a FIPS140-2 approved DRNG. Both standard RSA key and RSA Chinese Remainder Keys can be generated. • ECC key pair generations (on GF(P) curves with “f” up to 521) 8.4.3 Cryptographic key entry Keys shall always be input in encrypted format, using the Put Key command within a secure channel. During this process, the keys are encrypted using the Key Encryption Key and optionally the encryption session key of the secure channel. The secure channel session used must be such that the cryptographic strength of the encryption key is at least equal to the cryptographic strength of the key being loaded. Keys can never be output by the module. 8.4.4 Cryptographic key storage The Keys are structured to contain the following parameters: • Key set version • Key Index, which is the ID of the key, • Algo ID, which determines which algorithm to be used, • Integrity Mechanisms. 8.4.5 Cryptographic Key Zeroization Cryptographic keys stored in non volatile memory (CDK and ADK) can be zeroized by reloading another value using the PUT KEY command. ADK can also be zeroized by deleting the Application Security Domain that hosts the keys, using the DELETE command. Session cryptographic keys (CSK and ASK) are stored in volatile memory and are zeroized upon termination of the session, i.e. when the secure channel is closed or when the module is powered off. ID-One Cosmo V7-a Public Security Policy Page 31 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 9 Physical Security The Oberthur ID-One Cosmo V7 is a production quality single chip cryptographic module. It meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. It uses standard passivation techniques for the entire chip. The module has passed level 3 physical security testing for hardness, opacity and tamper evidence. ID-One Cosmo V7-a Public Security Policy Page 32 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 10 Mitigation of Other Attacks 10.1 Power Analysis (SPA/DPA) Power analysis attacks use information gathered from non-invasive measurements to crypto analyses and extract keys from tamper resistant devices. Simple Power Analysis (SPA) attacks use direct observation of a device’s power consumption. Because power consumption often varies significantly with computations performed by the crypto module, SPA observations can identify sensitive computational processes, reveal the presence of cryptographic sub- routines, and significantly accelerate reverse engineering. Differential Power Analysis (DPA) attacks use statistical analysis and error correction techniques to extract information leaked across multiple operations. This aggregation of data allows extremely small differences in power consumption to be isolated, including effects that are many orders of magnitude smaller than “noise”. The Oberthur ID-One Cosmo V7 cryptographic module has been designed to mitigate both Simple Power Analysis (SPA) and Differential Power Analysis (DPA). The module includes protections against SPA and DPA attacks for all embedded cryptographic algorithms involving secret elements. The chip protection level was evaluated against state-of-the art attacks (at the time of design). The cryptographic module mitigates Simple Power Analysis (SPA) and Differential Power Analysis (DPA) attacks using a combination of hardware and software design that makes differentiation of key values impractical by equalizing or scrambling current consumption of the card during algorithm cryptographic computation. Based on the algorithm used, the defense mechanisms vary, as the internal hardware implementations of these algorithms do not use the same underlying hardware. 10.2 Timing Analysis Timing attacks are non-invasive attacks that rely on the variation in computation time required for the microprocessor to perform its secret calculation. All cryptographic algorithms as well as Java Card API comparison functions offered by the chip are designed to be protected against Timing Analysis. This is done by enforcing the fact that any sensitive operation is achieved in a constant time regardless of the value of keys or data involved. 10.3 Fault Induction This type of attack is based on the theoretical possibility of flipping some random bits of the secret key, stored in RAM or EEPROM, before or during the computation done by the module (Bellcore attack). Another fault induction attack is to induce decoding error during the execution of one instruction. The Oberthur ID-One Cosmo V7 cryptographic module includes a combination of software and hardware protections in order for the chip not to operate in extreme conditions that may cause processing ID-One Cosmo V7-a Public Security Policy Page 33 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a errors that could lead to revealing the values of cryptographic keys or secret elements. Extreme Conditions refer to abnormal temperature, external power supply and external clock supply. In addition, every keys and PINs are protected by a signature that is checked prior to every use of the keys or PINS. See section 7.2 Conditional Self-Tests. 10.4 Flash Gun The Oberthur ID-One Cosmo V7 cryptographic module includes a combination of software and hardware protections in order to detect “Flash Gun” type of attacks and abort any current processing before becoming mute. 10.5 ElectroMagnetic Attacks The Oberthur ID-One Cosmo V7 cryptographic module includes a combination of software and hardware protections in order to detect “EMI” type of attacks and abort any current processing before becoming mute. 10.6 Card Tearing The Oberthur ID-One Cosmo V7 cryptographic module includes a combination of software and hardware protections in order to protect the card against damages potentially caused by a discontinued power (or RF for contactless) supply during an operation. Roll back mechanisms restore the card memory to a safe previous stable state during the next power-on sequence. ID-One Cosmo V7-a Public Security Policy Page 34 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 11 Security Policy Check List Tables 11.1 Roles and required Identification and Authentication Role Type of Authentication Authentication Data Card TDES or AES Authentication using GP Issuer Security Domain Key Set Administrator secure channel mutual authentication protocol (CDK) Application TDES or AES Authentication using GP Application Security Domain Key Provider secure channel mutual authentication protocol Set (ADK) Table 16: Roles and required Identification and Authentication 11.2 Strength of Authentication Mechanisms Authentication Strength of Mechanism Probability of Successful Random Attempt in 1 Mechanism Minute 280 8/280 TDES Authentication 2128 8/2128 AES Authentication Table 17: Strength of Authentication Mechanisms 11.3 Services Authorized for Roles Role Authorized Services Card Administrator Card Administrator Services are listed in section 5.4.1. Application Provider Application Provider Services are listed in section 5.4.2. Table 18: Services Authorized for Roles 11.4 Mitigation of Other Attacks Other Attacks Mitigation Mechanism Specific Limitations Simple Power Analysis Counter Measures against SPA N/A Differential Power Analysis Counter Measures against DPA N/A Timing Analysis Counter Measures against TA N/A Fault Induction Counter Measures against FI N/A Flash Gun Counter Measures against FG N/A Electro magnetic Interferences Counter Measures against EMI N/A Card Tearing Counter Measures against card tearing N/A Table 19: Mitigation of other attacks ID-One Cosmo V7-a Public Security Policy Page 35 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 12 References The Oberthur ID-One Cosmo V7 cryptographic module complies with the following specifications: [1] ISO/IEC 7816-3 – Information Technology – Identification Cards – Integrated Circuit(s) with Contacts – Part 3: Electronic Signals and Transmission Protocols, December 1997 – Amendment, June 2002. [2] ISO/IEC 7816-4 – Information Technology – Identification Cards – Integrated Circuit(s) with Contacts – Part 4: Interindustry Commands for Interchange, September 1995 – Amendment, December 1997. [3] ISO/IEC 7816-5 – Information Technology – Identification Cards – Integrated Circuit(s) with Contacts – Part 5: Numbering system and registration procedure for application identifiers, June 1994 - Amendment, December 1996. [4] ISO/IEC 14443-3 – Information Technology – Identification Cards – Contactless Integrated Circuit(s) Cards – Proximity Cards – Part 3: Initialization and Anti-collision, February 2001. [5] ISO/IEC 14443-4 – Information Technology – Identification Cards – Contactless Integrated Circuit(s) Cards – Proximity Cards – Part 4: Transmission Protocols, February 2001. [6] GlobalPlatform Card Specification, version 2.1.1, March 2003. [7] GlobalPlatform Card Specification, Amendment A, February 2004. [8] Visa Open Platform Card Implementation requirements 3 – Multiple Security Domains with DAP Capability, October 2001. [9] Visa GlobalPlatform 2.1.1 Card Implementation Requirements, May 2003. [10] JavaCard 2.2.2 Application Programming Interface, March 2006. [11] JavaCard 2.2.2 Run-time Environment Specification, March 2006. [12] JavaCard 2.2.2 Virtual Machine Specification, March 2006 [13] "Integrated Circuit Card Specifications for Payment Systems" – EMV 2000 Part 1: Electromechanical Characteristics, Logical Interface, and Transmission Protocols (version 3.0) Part 2: Data Elements and Commands (version 3.0) Part 3: Application Selection (version 3.0) Part 4: Security Aspects (Version 3.0) [14] " Biometric data interchange formats – part 2 – Finger minutiae data " ISO/IEC 19794-2 (2005) ID-One Cosmo V7-a Public Security Policy Page 36 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision Oberthur Technologies Doc Number: SP V7-a 13 Definitions and Acronyms 13.1 Acronyms Acronym Definition AES Advanced Encryption Standard AID Application Identifier AP Application Provider APDU Application Protocol Data Unit API Application Programming Interface ATR Answer To Reset (contact mode) ATS Answer to Select (contactless mode) BAP Batch Approval Process (First article validation from Production line) CBC Cipher Block Chaining CRC Cyclic Redundancy Check CSP Critical Security Parameter DES Data Encryption Standard DPA Differential Power Analysis DRNG Deterministic Random Number Generator ECC Elliptic Curve Cryptography ECB Electronic Code Book EEPROM Electrically Erasable and Programmable Read Only Memory EMI Electromagnetic Interference EMC Electromagnetic Compatibility ISO International Standard Organization JC Java Card ™ JCRE Java Card ™ Runtime Environment MAC Message Authentication Code NDRNG Non Deterministic Random Number Generator OP Open Platform PIN Personal Identification Number PKCS Public Key Cryptographic Standards RAM Random Access Memory ROM Read only Memory RSA Public key cryptographic algorithm invented by Rivest, Shamir and Adleman SHA Secure Hash Algorithm SPA Simple Power Analysis TDES Triple DES ID-One Cosmo V7-a Public Security Policy Page 37 / 37 © 2009 Oberthur Technologies This document may be reproduced only in its original entirety without revision