Oberthur ID-One Cosmo 128 v5.5 D FIPS 140-2 Level 3 Security Policy Public Version Version 1.1 June 11, 2008 Oberthur Card Systems 4250 Pleasant Valley Road Chantilly, VA 20151-1221 USA +1 (703) 263-0100 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy Version Control Table 1 shows the version history of this Security Policy. Version - Date Description V1.0 ­ Nov 28, 2007 Initial Release V1.1 ­ May 8, 2008 Firmware number update V 1.2 ­ June 11 2008 Firmware number update Table 1 - Document Version History June 11, 2008 Version 1.1 Page 2 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy TABLE OF CONTENTS 1 INTRODUCTION .................................................................................................................................................5 2 MODULE OVERVIEW ........................................................................................................................................5 2.1 PRODUCT OVERVIEW ......................................................................................................................................5 2.2 COMMON CRITERIA PROTECTION MECHANISMS ...............................................................................................6 2.3 CRYPTOGRAPHIC ALGORITHMS .......................................................................................................................7 2.3.1 Standard cryptographic Algorithms.......................................................................................................7 2.3.2 Additional Cryptographic Algorithms.....................................................................................................9 2.4 PRODUCT FORM FACTORS ............................................................................................................................10 2.5 PRODUCT TERMINOLOGY ..............................................................................................................................11 3 SECURITY LEVEL............................................................................................................................................11 4 CRYPTOGRAPHIC MODULE SPECIFICATIONS...........................................................................................12 4.1 TARGET OF VALIDATION ................................................................................................................................12 4.2 MODULE HARDWARE ....................................................................................................................................13 4.3 MODULE FIRMWARE .....................................................................................................................................13 4.4 MODULE FIRMWARE EXTENSIONS .................................................................................................................14 4.5 LOCKS CONFIGURATION ................................................................................................................................14 4.6 MODULE IDENTIFICATION ..............................................................................................................................14 4.7 FIPS APPROVED SECURITY FUNCTIONS ........................................................................................................15 5 PORTS AND INTERFACES .............................................................................................................................16 5.1 PHYSICAL PORT: SMART CARD CONTACT PLATE ...........................................................................................16 5.1.1 Interface Physical Specifications ........................................................................................................16 5.1.2 Interface Electrical Specifications .......................................................................................................16 5.1.3 Condition of use ..................................................................................................................................17 5.2 PHYSICAL PORT: CONTACTLESS MODE .........................................................................................................18 5.2.1 Interface Physical Specifications ........................................................................................................18 5.2.2 Interface Electrical Specifications .......................................................................................................19 5.2.3 Condition of use ..................................................................................................................................19 5.3 LOGICAL INTERFACE DESCRIPTION ................................................................................................................20 5.3.1 APDU Commands...............................................................................................................................21 5.3.2 API Interface .......................................................................................................................................21 6 ROLES & SERVICES .......................................................................................................................................22 6.1 ROLES .........................................................................................................................................................22 6.1.1 Cryptographic Officer Role..................................................................................................................22 6.1.2 User Roles ..........................................................................................................................................22 6.1.3 Identity based Authentication..............................................................................................................22 6.1.4 Logical Channels ................................................................................................................................23 6.2 SERVICES ....................................................................................................................................................23 6.2.1 Cryptographic Officer Services ...........................................................................................................23 6.2.2 User Services......................................................................................................................................24 6.2.3 No Role ...............................................................................................................................................25 6.2.4 Relationship between Roles, Services and CSP Access ...................................................................26 7 CRYPTOGRAPHIC KEY MANAGEMENT .......................................................................................................27 7.1 GLOBAL PIN ................................................................................................................................................27 7.2 CRYPTOGRAPHIC KEYS .................................................................................................................................27 7.2.1 Initial Issuer Transport Key .................................................................................................................27 7.2.2 Crypto-Officer keys in Card Manager .................................................................................................28 7.2.3 User/Applet Provider Keys in Security Domains ................................................................................28 June 11, 2008 Version 1.1 Page 3 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 7.2.4 Keys Exchange ...................................................................................................................................29 7.2.5 Key Loading ........................................................................................................................................29 7.2.6 EEPROM encryption Key....................................................................................................................30 8 CARD CRYPTOGRAPHIC FUNCTIONS .........................................................................................................30 8.1.1 Random Number Generators .............................................................................................................31 8.1.2 Delegated Management......................................................................................................................31 8.1.3 DAP Verification..................................................................................................................................32 9 SELF TESTS.....................................................................................................................................................33 9.1 POWER UP SELF TESTS................................................................................................................................33 9.2 CONDITIONAL TESTS.....................................................................................................................................34 9.3 KEY LOAD TESTS: ........................................................................................................................................34 10 FINITE STATE MACHINE ................................................................................................................................35 11 PHYSICAL SECURITY .....................................................................................................................................35 12 EMI/EMC ...........................................................................................................................................................36 13 OPERATIONAL ENVIRONMENT.....................................................................................................................36 14 SECURITY RULES ...........................................................................................................................................36 14.1 APPROVED MODE OF OPERATION ..................................................................................................................36 14.2 IDENTIFICATION & AUTHENTICATION SECURITY RULES ...................................................................................37 14.2.1 User Identification and Authentication ................................................................................................37 14.2.2 Cryptographic Officer Identification & Authentication .........................................................................37 14.3 APPLET LOADING SECURITY RULES ...............................................................................................................37 14.4 KEY MANAGEMENT SECURITY POLICY ...........................................................................................................38 14.4.1 Cryptographic key generation.............................................................................................................38 14.4.2 Cryptographic key entry ......................................................................................................................38 14.4.3 Cryptographic key storage ..................................................................................................................38 14.4.4 Key Destruction...................................................................................................................................38 15 MITIGATION OF OTHER ATTACKS POLICY.................................................................................................40 15.1 POWER ANALYSIS (SPA/DPA)......................................................................................................................40 15.2 TIMING ANALYSIS .........................................................................................................................................40 15.3 FAULT INDUCTION .........................................................................................................................................40 15.4 FLASH GUN ..................................................................................................................................................41 15.5 ELECTROMAGNETIC ATTACKS .......................................................................................................................41 16 SECURITY POLICY CHECK LIST TABLES....................................................................................................42 16.1 ROLES AND REQUIRED IDENTIFICATION AND AUTHENTICATION ........................................................................42 16.2 STRENGTH OF AUTHENTICATION MECHANISMS ..............................................................................................42 16.3 SERVICES AUTHORIZED FOR ROLES ..............................................................................................................42 16.4 MITIGATION OF OTHER ATTACKS ...................................................................................................................42 17 APPLICABLE DOCUMENTS ...........................................................................................................................44 18 DEFINITIONS AND ACRONYMS.....................................................................................................................46 18.1 DEFINITIONS.................................................................................................................................................46 18.1.1 Card Manager .....................................................................................................................................46 18.1.2 Security Domains................................................................................................................................46 18.1.3 Applets ................................................................................................................................................46 18.2 ACRONYMS ..................................................................................................................................................47 June 11, 2008 Version 1.1 Page 4 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 1 Introduction This document defines the Security Policy for the Oberthur Card Systems ID-One Cosmo 128 v5.5 D Java Card platform submitted for validation in accordance with FIPS 140-2 Level 3 security requirements. Included are, a description of the security requirements of the module, and a qualitative description of how each security requirement is achieved. In particular, this security policy specifies the security rules under which the cryptographic module must operate. 2 Module Overview 2.1 Product Overview The ID-One Cosmo 128 v5.5 D Java Card platform, hereafter referred to as the module, is a single chip multi-application Smart Card micro-controller, with two communication interfaces (contact ISO 7816, and Contactless ISO 14443) that provides secure data storage and processing capabilities specifically designed for identity and government market needs. 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). The module loads and runs applications written in JavaTM programming language and includes a native implementation of Java CardTM 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 programmable platforms. Its micro-controller provides the loaded applications with all the low-level services such as memory management, I/O control, cryptographic algorithms and physical security. This new generation Oberthur Smart Card programmable module offers a highly secure architecture with state of the art on board cryptographic services that include in some aspect and even exceed NSA SUITE-B cryptography for Top Secret classified information with Advanced Encryption Standard (AES 256) for symmetric encryption; Secure Hash Algorithm (SHA up to 512) for message digest; Elliptic-Curve Diffie-Hellman (ECDH compatible mode) for key agreement and Digital Signature Algorithm (ECDSA with up to 384-bit prime modulus) for digital signatures. Additional cryptographic features for legacy systems 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 a FIPS 186-2 Random Number Generators. Additional features include biometric extensions as defined by the Java Card Forum and a built-in on card fingerprint matching engine using standard ISO 19794-2 for finger minutia data format. June 11, 2008 Version 1.1 Page 5 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy The built in management of Logical Channels allows the platform to support multiple applications simultaneously, each with their own Security Domain. To complement the large memory size of this new module, ADPU management has been upgraded to include support for extended length fields, removing limitations of previous generation cards to a payload per APDU of 256 bytes max. With this new generation module, a single APDU can transmit up to 32767 bytes of data in each direction (In/Out). Photo ID, a fingerprint images and X509 certificates can now be read in a single APDU without requiring chaining. The ID-One Cosmo 128 v5.5 D Chip Platform combines the advantages of the Java programming language and cryptographic services with those of a dual interface micro module. The same security level can be achieved with both contact (ISO 7816) and contactless (ISO 14443) interfaces thanks to carefully designed hardware and software features. And to protect against skimming, two security firewalls have been implemented, the first one allows application developers to disable contactless access for sensitive operations within their application (applet instance), and the second one allows card issuer to temporarily or permanently disable all contactless activity at the card level or to restrict contactless activity to prevent the leaking over the contactless interface of identifiable information. This greatly improves the privacy protection of the card holder. All the above services can be accessed by the applets instantiated from code loaded onto the chip EEPROM or ROM using the Java CardTM Application Programming Interface (API). The Card Manager provides the Open Platform services that are both internal (accessible by applet instances) and external services (accessible by external or non-chip applications). In addition, whether embedded into a plastic card, or into an electronic passport, the ID-One Cosmo 128 v5.5 D Chip Platform hardware module provides tamper-resistance and tamper evidence features that meet FIPS 140-2 Level 3 physical requirements. The module requires a lower voltage than traditional smart cards to operate making it the perfect cryptographic module for a new range of application using lower voltage portable readers. The cryptographic module operates under either 5 Volt power supply (ISO 7816-3 Class A) or 3 Volt power supply (ISO 7816-3 Class B). The module is available with one or two communication interfaces (ISO 7816 for contact and ISO 14443 for contactless). 2.2 Common Criteria Protection Mechanisms In addition to the security requirements from FIPS 140, the module has been independently tested to meet the requirements often asked in Common Criteria Certification, such as: · Erase transient data on completion of operation execution. · Prevent unauthorised data leakage to non-volatile memory · Prevent data release (cryptographic keys, PINs), by physical/logical means. · Prevent unauthorised data storage, or data overwrite. · The card unlock function can only be performed by an authorised administrator. June 11, 2008 Version 1.1 Page 6 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 2.3 Cryptographic Algorithms The following cryptographic services are provided by the ID-One Cosmo 128 v5.5 D Java Card API. 2.3.1 Standard cryptographic Algorithms The implementation of the following algorithms is fully compliant with JavaCard specifications: Cryptography Characteristics Key size Remarks Single DES (Key size 56) is Encrypt/decrypt operations 112/ disabled during module Triple DES ECB/CBC modes 168 bits manufacturing when the module FIPS 46-3 compliant has to run in FIPS mode The following key sizes can be enabled during module Signature/verification 1024/ manufacturing when the module operations 1280/ does not have to run in FIPS mode: RSA CRT/SFM modes 1536/ 512/576/640/704/768/832/896/960/ Key generation 1792/ 1088/1152/1216/ ANSI X9.31 compliant 2048 bits 1344/1408/1472/ 1600/1664/1728/ 1856/1920/1984 bits GF(p) algorithm 192/ Elliptic Curve with key size 160 Signature/verification Elliptic Curves 224/ can be enabled during module operations ALG_ECDSA_SHA 256/ manufacturing when the module Key generation 384 bits does not have to run in FIPS mode IEEE P1363-2000 compliant Elliptic Curves DH 192/ Elliptic Curve with key size 160 (Diffie-Hellman) key agreement algorithms 224/ can be enabled during module ALG_EC_SVDP_DH, IEEE P1363-2000 compliant 256/ manufacturing when the module ALG_EC_SVDP_DHC 384 bits does not have to run in FIPS mode 128/ Encrypt/decrypt operations AES 192/ ECB/CBC modes 256 bits RNG Base on HW True Random ALG_PSEUDO_RANDOM, Number Generator ALG_SECURE_RANDOM FIPS 186-2 compliant ALG_SHA, ALG_SHA_256, Message Digest operations SHA-1 SPA resistant ALG_SHA_384, ALG_SHA_512 June 11, 2008 Version 1.1 Page 7 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy In addition, the following classes are supported: ALG_AES_MAC_128_NOPAD ALG_DES_MAC4_NOPAD ALG_DES_MAC8_NOPAD ALG_DES_MAC4_ISO9797_M1 ALG_DES_MAC8_ISO9797_M1 ALG_DES_MAC4_ISO9797_M2 Class Signature ALG_DES_MAC8_ISO9797_M2 ALG_DES_MAC4_ISO9797_1_M2_ALG3 ALG_DES_MAC8_ISO9797_1_M2_ALG3 ALG_ECDSA_SHA ALG_RSA_SHA_ISO9796 ALG_RSA_SHA_PKCS1 ALG_RSA_SHA_PKCS1_PSS ALG_AES_BLOCK_128_CBC_NOPAD ALG_AES_BLOCK_128_ECB_NOPAD ALG_DES_CBC_NOPAD ALG_DES_CBC_ISO9797_M1 ALG_DES_CBC_ISO9797_M2 Class Cipher ALG_DES_ECB_NOPAD ALG_DES_ECB_ISO9797_M1 ALG_DES_ECB_ISO9797_M2 ALG_RSA_NOPAD ALG_RSA_PKCS1 ALG_RSA_PKCS1_OAEP Note: the DES function in the above table is actually a Triple DES. June 11, 2008 Version 1.1 Page 8 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 2.3.2 Additional Cryptographic Algorithms The following algorithms are not part of JavaCard Specifications and therefore use an Oberthur Proprietary implementation: Cryptography Characteristics ALG_SHA_224 (0x08) ALG_SHA_CHAIN (0x81) Message Digest operations ALG_SHA2_CHAIN (0x82) Elliptic Curves ALG_ECDSA_SHA224(0x21) Elliptic Curves ALG_ECDSA_SHA256(0x22) Elliptic Curves ALG_ECDSA_SHA384(0x23) GF(p) algorithm ALG_ECDSA_SHA_LDS (0x25) Signature/verification operations ALG_ECDSA_SHA256_LDS(0x26) ALG_ECDSA_SHA384_LDS(0x27) Diffie-Hellman KEYAGREEMENT_ALGO_RSA(0x81) Diffie-Hellman ALG_EC_SVDP_DH_GK (0x82) Key Agreement Operations Diffie-Hellman ALG_EC_SVDP_DHC_GK (0x83) Non-Deterministic Random Number Generator (NDRNG) Hardware Seed Generation for the Deterministic RNG Oberthur proprietary key generation algorithm Key Generation for non FIPS approved encryptions Please be aware that in this FIPS configuration, there are no applets to exercise cryptography besides the Security Domains. As a result the only available service which utilizes the RSA algorithm is one that uses a 1024 bit RSA public key for DAP verification, and no services use AES, ECDH, ECDSA, or Triple DES with on card formatting. June 11, 2008 Version 1.1 Page 9 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 2.4 Product Form Factors The module is designed to be encased in a hard opaque resin which can be embedded into different form factors such as a plastic card, an Electronic Passport, or any other support to produce the ID-One Cosmo 128 v5.5 D Java Card Chip Platform, on which FIPS 140-2 Level 3 validated applets may be loaded and instantiated at post issuance. The photo, Figure # 1, shows an example of the module in its opaque resin. Figure 1 The module, after encapsulation into its opaque tamper resistant resin, can be embedded into different form factors, such as a smart card, a token, or a paper document. The following figures show a few examples of various form factors available from Oberthur. Figure 4: Figure 2: Module embedded in the Module embedded into a cover of an e-Passport PIV Dual Interface Smart Card June 11, 2008 Version 1.1 Page 10 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 2.5 Product Terminology In the remaining of this document, the cryptographic module described above will be referred indifferently as ID-One Cosmo 128 v5.5 D or as module, regardless of whether the form factor is a actually a smart card module, a full ID-1 smart card, an e-Passport book cover or any other form factor Oberthur may come up with to answer specific market needs. 3 Security Level The Oberthur ID-One Cosmo 128 v5.5 D 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 NA Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of Other Attacks 3 Table 2 - Module Security Level Specification June 11, 2008 Version 1.1 Page 11 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 4 Cryptographic Module Specifications The cryptographic module supports a command-set aimed at allowing the mutual authentication of identities using strong cryptography with "card acceptance devices" or terminals that they might be connected to. Specifically, the TDES algorithm is used within authentication commands between the cryptographic module and the "card acceptance device" environment for strong authentication of identities. Establishment of identities using these commands is then used to fulfill "access conditions" which limit the ability of the external world to access information and/or commands on the module. The Oberthur Card Systems ID-One Cosmo 128 v5.5 D is a single chip implementation of a cryptographic module. The module comprises the following elements: · Secure micro controller Integrated Circuit with: o A 32 bit crypto coprocessor optimized for public key cryptographic calculations (ECC and RSA) o A Triple DES (Data Encryption Standard) Co-Processor o An AES (Advanced Encryption Standard) Co-Processor o High reliability 144 KB EEPROM for both customer applications and Operating System data o System firmware, consisting of the operating system installed in Read Only Memory (ROM) o Firmware extension (Optional Code) loaded in EEPROM to fine tune OS capabilities · Applets (Applications) that are to be installed onto the module. · Critical Security Parameters stored in EEPROM as part of the Chip Platform personalization operation. 4.1 Target of Validation This document addresses the submission for validation of the module in accordance with FIPS 140-2 Level 3 standard. The module submitted for validation consists of the ID-One Cosmo 128 v5.5 D Chip Platform without any instantiated applet other than the Card Manager (CM) and built-in Security Domains (SD). This validation is aimed at the Systems software, virtual machine, and Card Manager/Security Domains applets without any other instantiated applets. Instantiating a (security relevant) applet will require a re-validation and the issuance of a new certificate, even if the applet itself was validated to FIPS 140-2. In the scope of this document, the cryptographic module is a single chip Integrated Circuit with its embedded firmware. It is designed to be encased in a hard opaque resin which can be embedded into different form factors such as a plastic card, an Electronic Passport, or any other support to produce the June 11, 2008 Version 1.1 Page 12 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy ID-One Cosmo 128 v5.5 D Java Card Chip Platform, on which FIPS 140-2 Level 3 validated applets may be loaded and instantiated at post issuance. The "Cryptographic Boundary" for the ID-One Cosmo 128 v5.5 D module vis-à-vis the FIPS 140-2 validation is the "module edge". The module is the encapsulated chip and is constructed to provide tamper resistance and tamper evidence required in the FIPS 140-2 physical Level 3 validation. The following diagram shows the actual module cryptographic boundaries. Connection Wires IC Epoxy glue Contact Plate, or antenna connection Figure 6 The red dotted line shows the module cryptographic boundary. The epoxy glue and the support on which the crypto module is glued (contact plate or antenna) are not part of the crypto module boundary. 4.2 Module Hardware The Integrated Circuit used for the ID-One Cosmo 128 v5.5 D is identified by its Hardware Part Number B0. Part number B0 comes in different customizations depending on the communication interface(s) needed by the end customer (i.e. ISO 7816 contact and/or ISO 14443 Contactless). This Security Policy applies to the above listed hardware part number, regardless of the communication interfaces that have been activated. Module hardware Part Number can be read from the Card Identification Data Object under tag 04. 4.3 Module Firmware The firmware (hard mask) is the ROM code that is written in the micro-controller during manufacturing and cannot be subsequently changed. The firmware version of the ID-One Cosmo 128 v5.5 D is F310. The complete firmware identification is achieved by putting together the firmware version and the firmware extension below. June 11, 2008 Version 1.1 Page 13 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 4.4 Module Firmware Extensions The functionality of the module operating system can be extended through the use of firmware extensions called optional codes. Such optional codes can be loaded in the EEPROM only during manufacturing and cannot be subsequently removed or modified. Examples of functionality that can be added through such firmware extension include critical patches on the card OS as well as support for additional cryptographic algorithms, additional biometric match on card algorithms, etc. This document addresses the submission for validation of the module with the following firmware Extension(s): Firmware Extension Note 067733 Generic Codop R3.0 Table 3: Firmware Extension(s) included in this validation 4.5 Locks configuration The module includes several locks that can be set by Oberthur during the manufacturing phase to configure the module in a specific electrical configuration to meet customer requirements (e.g. FIPS 140-2, FIPS 140-3, CC, etc). 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. 4.6 Module Identification Every module delivery is associated with a BAP document that identifies the module and its specific configuration (electrical profile).That BAP document that is prepared by Oberthur Technical support staff after discussing with the customer of its specific needs. The BAP provides identification information (hardware, firmware, and firmware extension, and locks configuration) and specifies if the electrical profile set the module in FIPS mode of operation when it leaves Oberthur factory. Please make sure you specify at the time of ordering that you want the product to be validated to FIPS 140-2 as it may not be the default configuration from all Oberthur factories. (Modules in non FIPS mode of operation are usually faster and may be preferred by some customers). 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 validated mode are listed as such in the BAP document associated with your delivery. June 11, 2008 Version 1.1 Page 14 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 4.7 FIPS Approved Security Functions The following table gives the security functions that have been FIPS certified on the ID One Cosmo 128 v5.5 D. Security Function Details FIPS Certification # 2 Key Triple DES (128) ECB and CBC in both 606 Encryption and Decryption 3 Key Triple DES (192) ECB and CBC in both 606 Encryption and Decryption AES 128 ECB and CBC in both Encryption and Decryption AES 192 ECB and CBC in both 657 Encryption and Decryption AES 256 ECB and CBC in both Encryption and Decryption SHA-1 SHA-224 & SHA-256 Byte-oriented messages 688 SHA-384 & SHA-512 RNG FIPS 186-2 377 GenKey 9.31 SigGenPKCS1.5 RSA SIgGenPSS 304 (Modulus sizes: 1024, 1536 and 2048) SigVerPKCS1.5 SigVerPSS Key Pair Generation ECDSA SigGen 70 (P192, P-224, P-256, P-384) SigVer June 11, 2008 Version 1.1 Page 15 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 5 Ports and Interfaces The integrated circuit used in the module is a single chip that supports both a contact and a contactless communication interface. Contact communication is achieved through a physical connection to a smart card contact plate. Contactless communication is achieved through physical connection to an antenna. Neither the contact plate, nor the antenna, are within the cryptographic boundaries of the module. The following sections, describe each of these three communication interfaces. 5.1 Physical Port: Smart Card Contact Plate 5.1.1 Interface Physical Specifications In this contact mode, communication to and from the cryptographic module is done through an ISO/IEC 7816-21 smart card contact plate (also called printed circuit) that provides the electrical connection required by ISO/IEC 7816-32. Five electric wires connect the module to the printed circuit, and from there, to the outside world. The printed circuit itself is outside of the module cryptographic boundaries and mentioned here only for illustration purposes. 5.1.2 Interface Electrical Specifications The following picture shows an example of the contact plate and the location were the five electrical connections from the module are wire bonded to the contact plate. VCC GND RST CLK I/O (Bi-directional) Figure 7: Example of an ISO 7816-2 compliant contact plate used to provide ISO 7816-3 electrical communications with the cryptographic module 1 ISO/IEC 7816 Part 2: Identification Cards -- Integrated Circuit Cards with contacts -- Dimensions and location of the contacts (Second Edition ­ 2007) 2 ISO/IEC 7816 Part 3: Identification Cards -- Integrated Circuit Cards with contacts -- Electrical interface and transmission protocols (Third Edition ­ 2006) June 11, 2008 Version 1.1 Page 16 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy The 5 electrical signals transmitted to the module through the contact mode wires coming from the contact plate are the following: · VCC: Supply Voltage Power supply input. (1.62V to 5.5V) · GND: Ground (reference voltage) · RST: External reset signal from the interface device (card read / write device) · CLK: External clock (1MHz to 10MHz). This clock is just for data transmission as both processor and coprocessors are driven independently by an internal oscillator at a much higher frequency. · I/O: Input or output for serial data to / from the processor These 5 electronic signals are in full compliance with ISO/IEC 7816-3 standard. 5.1.3 Condition of use 5.1.3.1 Power Supply The Oberthur PIV EP card operates in both ISO 7816-3 class A and class B. This opens new ranges of application using lower voltage portable readers. Class A requires a power supply voltage between 4.5 Volt and 5.5 Volt. Class B requires a power supply voltage between 2.7 Volt and 3.3 Volt. 5.1.3.2 Frequency The card supports an external clock Frequency from 1MHz to 10MHz 5.1.3.3 Speed The card support communication speed up to 625,000 bits/sec in contact mode with an external clock of only 5Mhz as per the latest (2006) edition of ISO 7816-3. Values of the clock rate conversion integer (Fi) and the baud rate adjustment integer (Di) supported by the module are as follows: FI F DI D Maximum communication speed 1 372 1 1 13,440 bauds at 5Mhz and 9,600 bauds at 3.576MHz 1 372 2 2 26,881 bauds at 5Mhz 1 372 3 4 53,763 bauds at 5Mhz 1 372 8 12 161,290 bauds at 5Mhz 9 512 4 8 78,125 bauds at 5Mhz 9 512 5 16 156,250 bauds at 5Mhz 9 512 6 32 312,500 bauds at 5Mhz 9 512 7 64 625,000 bauds at 5Mhz June 11, 2008 Version 1.1 Page 17 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 5.1.3.4 Transmission protocol The transmission protocol complies with ISO/IEC 7816-3:2006 with full support for extended length APDU. Depending on the electrical profile defined in the BAP, the module can be configured in manufacturing to support any of the following ISO/IEC 7816-3 transmission protocols: · Character oriented transmission protocols (T=0) only · Block oriented transmission protocols (T=1) only · Both T=0 and T=1 However, From an APDU-TPDU management level, the Block oriented transmission (T=1) is the only one that behaves identically on all three interfaces. Therefore if the module is to be used also in contactless mode, it is recommended to disable T=0 and develop only in T=1 to allow the middleware to be fully transparent to the communication ports being used. Characters can be exchanged in direct convention (Z level corresponds to a logical 1 and LSB is sent first) or in inverse convention (Z level corresponds to a logical 0 and LSB is sent first). The Oberthur ID-One Cosmo 128 v5.5 D supports the Protocol and Parameter Selection to select a new protocol type or change transmission baud rate. Up to32767 data bytes can be exchanged in each direction within a single command (using APDU with Extended Length Field). 5.2 Physical Port: Contactless Mode In contactless mode, the cryptographic module follows the standard ISO/IEC 14443 RF Interface 5.2.1 Interface Physical Specifications In this mode, the module uses only two electrical connections, LA and LB, to close the loop of an external antenna, as illustrated in the following picture. The two electrical connections LA and LB, used in contactless mode are physically different and distinct from the electrical connections used in contact mode. The antenna is not within the cryptographic boundary of the module. LA LB June 11, 2008 Version 1.1 Page 18 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy Figure 8: Example of connection of the cryptographic module to the antenna for a contactless mode. 5.2.2 Interface Electrical Specifications Power and data are transmitted to the module from the antenna using a modulation signal at 13.56 MHz. The Proximity coupling device (reader) produces an energizing RF field that couples to the Proximity Mounted Chip Assembly (ID-One Cosmo 128 v5.5 D module) to transfer power. Data communication is achieved through a modulation of the energizing RF field, using amplitude shift keying (ASK) type of modulation. The module operates independently of the external clock applied on the interfaces. The main processor and all cryptographic co-processors are driven independently of the external clock by an uninterrupted internal oscillator. During contactless communications, an on-chip capacitor provides all power to the internal oscillator. A low frequency sensor monitors the external frequency applied to the interfaces. If the frequency is out of the specified range, the chip is reset. RF signal and Power interface are fully compliant with 14443-23 An anti-collision mechanism compliant with 14443 is provided by the interface to insure trouble free communication with the cryptographic module, and to protect from interference due to the presence of multiple modules or readers within the communication range. Initialization and anti-collision that define start of communication and card select are fully compliant with ISO/IEC 14443 part 3 The transmission protocol that defines data exchange between reader and cards is fully compliant with ISO/IEC 14443 part 4. The contactless communication range of the Oberthur PIV EP card is about 10 cm. More information on this interface can be found in the above-mentioned ISO/IEC standards. 5.2.3 Condition of use 5.2.3.1 Operating Field The operating field depends on the form factor of the final product in which the module is embedded. When the module is embedded into an ISO 7810 ID-1 Oberthur contactless smart card, the card can operate under a field between 1.5 A/m to 7.5 A/m rms 3 ISO/IEC 14443 part 2: Radio frequency power and signal interface for contactless integrated circuit cards ­ Proximity cards. June 11, 2008 Version 1.1 Page 19 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 5.2.3.2 Frequency The module nominal frequency for contactless communication is 13.56 MHz 5.2.3.3 Speed The supported bit rates of the Oberthur ID-One Cosmo 128 v5.5 D are: · 106 Kbits/s · 212 Kbits/s · 424 Kbits/s · 847 Kbits/s 5.2.3.4 Transmission protocol Communications with the module in contactless mode is based on a fully standardized (ISO/IEC 14443), half-duplex transmission protocol, called T=CL. From an APDU-TPDU translation level, this protocol is similar to the T=1 Block transmission protocol used in the contact mode. Up to32767 data bytes can be exchanged in each direction within a single command (using APDU with Extended Length Field). 5.3 Logical Interface Description Once communication is established between the reader and the platform, the platform functions as a "slave" processor to implement and respond to the reader commands. The platform adheres to a well- defined set of state transitions. Within each state, a specific set of commands is accessible. The I/O ports4 of the platform (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 Data Output: I/O Pin LA and LB Status Output: I/O Pin LA and LB Control Input: I/O, Clk and Reset Pins LA and LB Power Input VCC and GND LA and LB 4 Two ports due to contact and contactless mode of communications. June 11, 2008 Version 1.1 Page 20 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy Synchronization timing controls, provided in part by the platform CLK clock input 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. 5.3.1 APDU Commands The data exchange protocol between the cryptographic module and the outside world follows ISO/IEC 7816-4 standard. The cryptographic module acts as a slave device, receiving and executing APDU commands from the host. An application protocol data unit is either a command APDU or a response APDU. A step in application protocol consists of transmitting a command APDU, processing it in the receiving entity and returning the response APDU. This pair of APDUs is called a command-response pair. A command APDU consists of a mandatory header of four bytes denoted CLA INS P1 P2, followed by a conditional body of variable length. Command header Command body CLA INS P1 P2 [Lc field] [Data field] [Le field] A response APDU consists of a conditional body of variable length followed by a mandatory trailer of two bytes denoted SW1 SW2 and encoding the status of the receiving entity after processing the command. Response body Response trailer [Data field] SW1 SW2 5.3.2 API Interface The Oberthur module provides trusted applets with internal services through its APIs. The cryptographic module performs the requested services according to its roles and services Security Policy. June 11, 2008 Version 1.1 Page 21 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 6 Roles & Services 6.1 Roles The module defines two distinct roles that are supported by the internal cryptographic system: the Card Security Controller (CSC) and the Applet Provider (AP). 6.1.1 Cryptographic Officer Role · Card Security Controller (CSC) Role: This role is responsible for managing the security configuration of the card manager and security domains. The CSC role authenticates to the cryptographic module by demonstrating to the Card Manager application that he possesses the knowledge of a Global Platform (GP) secure channel TDES key set stored within the Security Domain. By successfully executing the OP secure channel mutual authentication protocol, the CSC role establishes a secure channel to the Security Domain and executes services allowed to the CSC role in a secure manner. 6.1.2 User Roles · Applet Provider (AP) Role ­ The Applet Provider is the applet developer that uses the Java API, available on the module. The developer is regarded as an internal user to the platform. The cryptographic services provided by the module are delivered through the use of well-documented APIs. An applet can have a dedicated security domain instance (Applet Provider Security Domain), or may rely on the Card Manager Security Domain. 6.1.3 Identity based Authentication - Identification. The operator identifies him/herself by selecting the application and a key set associated with the application. The application of the Cryptographic Officer is the Card manager. The application of the applet providers is their own applet. The selection of the application is done by a SELECT command. The selection of the key set is done through the INITIALIZE UPDATE command. (The same command that will be used to start the authentication that follows the identification.) - Authentication. The operator authenticates him/herself using a mutual authentication comprising two commands INITIALIZE UPDATE and EXTERNAL AUTHENTICATION. During this mutual authentication, the operator has to encrypt a message sent by the card, proving knowledge of the TDES key set that was referenced during the identification. Each INITIALIZE UPDATE must be immediately followed by a successful EXTERNAL AUTHENTICATE command. Otherwise, the event is recorded in the card Audit Log and the next Initialize Update performed on the same key set will be exponentially slowed down to discourage attacks. This provides a strong protection against brute force attacks as no more than a few consecutive unsuccessful authentication attempts are possible within one minute. June 11, 2008 Version 1.1 Page 22 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy The authentication remains valid until the next Identification phase (SELECT command) or until an unsuccessful authentication or a card reset (power-off) has been initiated. Please refer to section 16.2 "Strength of Authentication Mechanisms" for information on the strength of authentication. 6.1.4 Logical Channels The module provides full support for Logical Secure Channels as defined by GP2.1.1. Secure channel protocol is used to establish a secure communication channel between the module and an external entity during an Application Session. Logical Channels facilitate the possibility of more than one of the above external entities to communicate concurrently with multiple applications on the card, each within its own logical secure environment. 6.2 Services 6.2.1 Cryptographic Officer Services Several services are made available to an authenticated Cryptographic Officer (CSC) only. They are primarily used to manage Security Domains, allow the creation of additional applications (applet instances of already FIPS approved executable byte code present in the card) and/or allow the loading of applets into the card. · INSTALL: this APDU is used to add an application from an executable byte code already present in the module. · LOAD: this APDU is used to load the byte-code of a new application. For the module to remains in FIPS mode, this command shall not be used to load non FIPS approved executable code. · DELETE: this APDU is used by the CSC role to delete an application from the cryptographic module. Load File (package) or an applet (applet instance). · PUT TDES KEY: this APDU is used to add or replace security domain key sets (TDES). 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 PUBLIC KEY: this APDU is used 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. · STORE DATA: This command is used by the CSC to clear the audit log and load Data Objects at the platform level. It is also used to modify the contactless capabilities (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 user. June 11, 2008 Version 1.1 Page 23 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy · SET STATUS: This APDU is used by the CSC to temporary lock an application, and to unlock it later on. It can also be used to terminate the crypto module. · GET STATUS: this APDU is used to get the life cycle state of the cryptographic module or the life cycle state of an application. It can also be used by the CSC to verify that the module is still in FIPS Mode and that only FIPS approved applications are instantiated. · INITIALIZE UPDATE: this APDU is used by the CSC to exchange with the crypto module data needed to establish the session keys and initiate a GP Secure Channel with a given Security Domain in the crypto module. · EXTERNAL AUTHENTICATE: this APDU is used by the CSC to authenticate to the crypto module and to finalize the establishment of the GP Secure Channel by providing the level of security required for all subsequent commands within the Secure Channel. A previous and successful execution of the INITIALIZE UPDATE command is required prior to processing this command. · DELEGATE MANAGEMENT: Delegated Management gives a CSC the possibility of empowering another CSC the ability to initiate approved and pre-authorized Card Content changes (loading, installation, extradition or deletion) on his behalf. · PIN CHANGE/UNBLOCK: The Pin Change/Unblock instruction is used to change the value of the Global PIN or to unblock the current Global PIN. The command is used with Secure Messaging in the context of a Secure Channel; its level of security must so match the security level of the current Secure Channel. · All Services under "No Role" 6.2.2 User Services The following services (commands) are made available to an authenticated User: · PUT TDES KEY: this APDU is used to add or replace security domain key sets (TDES). 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. · STORE DATA: This command is used to load Data Objects in the selected application. · SET STATUS: This APDU is used to temporary lock an application, and unlock it later on. It can also be used to terminate the application. · GET STATUS: this APDU is used to get the life cycle state of an application. · INITIALIZE UPDATE: this APDU is used to exchange with the crypto module data needed to establish the session keys and initiate a GP Secure Channel with a given Security Domain in the crypto module. · EXTERNAL AUTHENTICATE: this APDU is used to authenticate to the crypto module and to finalize the establishment of the GP Secure Channel by providing the level of security required for June 11, 2008 Version 1.1 Page 24 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy all subsequent commands within the Secure Channel. A previous and successful execution of the INITIALIZE UPDATE command is required prior to processing this command. · DAP VERIFICATION: DAP verification allows an Applet Provider (User) to own a Security Domain which can be requested to check application code integrity and authenticity before the application code is loaded by the Card Security Controller (Crypto-Officer) or any entity other than the Applet Provider itself. More details on how DAP verification works can be found in the product manual. · All Services under "No Role" 6.2.3 No Role The following services are available without authentication · MANAGE CHANNEL: This command allows the terminal to open or close a logical channel in the card. Up to 4 logical channels may be open at a time. · GET DATA: The GET DATA command is used to retrieve a non protected data object available from the selected application. Example of data retrievable includes Identification Data, configuration data, Issuer Identification Number, Card Image number, Audit log, and a few others described in the module programmer's guide. · SELECT: This command is used for selecting an application (Card Manager, Security Domain or Applet Instance). The Card Manager may be selected either for the loading of an application executable code (Load File) or for activating an application by instantiation of it's previously loaded executable code. · ENVELOPE: This command transmits [part of] either a command APDU or a BER-TLV data object that otherwise could not be transmitted by the available transmission protocol. See examples in ISO/IEC 7816-3. June 11, 2008 Version 1.1 Page 25 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 6.2.4 Relationship between Roles, Services and CSP Access CSP5 involved No CSP Roles/Services CSC AP Role Access type From CSC From AP INSTALL X CSK Execute LOAD X CSK Execute DELETE X CSK Execute Execute, PUT TDES KEY X X CSK, CDK ASK, ADK Write CSK, KTOKEN, Execute, PUT PUBLIC KEY X KDAP Write 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 EXTERNAL AUTHENTICATE X X CDK, CSK ADK, ASK Execute CSK, KTOKEN, DELEGATE MANAGEMENT X Execute KRECEIPT Write and PIN CHANGE/UNBLOCK X PIN, CSK Execute DAP VERIFICATION X KDAP Execute MANAGE CHANNEL X GET DATA X SELECT X ENVELOPE X 5 See Section 7 for further CSP pointer details. June 11, 2008 Version 1.1 Page 26 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 7 Cryptographic Key Management The cryptographic module handles various keys and a PIN · Global PIN · Card Manager and Security Domain Keys 7.1 Global PIN The Global PIN (Personal Identification Number) supported by the ID-One Cosmo 128 v5.5 D can be a sequence from 6 to 254 digits, or a passphrase of 127 characters max (any characters that could be coded in hexa on one byte). It may be used through a standard GP 2.1.1 API to authenticate the future Cardholder to the module with a probability of false authentication of less than 1/1,000,000. By successfully entering a PIN sequence, a cardholder can prove knowledge of a shared secret (the PIN) and thereby authenticate to the module. The Cryptographic Officer has the capability to unlock a cryptographic module that has been locked after reaching a predefined number of consecutive errors on PIN verification. However, PIN setting and verification are available only through API to be called by an applet. Until such applet gets FIPS 140-2 validated, the Global PIN feature cannot be used. 7.2 Cryptographic Keys The ID-One Cosmo 128 v5.5 D in FIPS mode (i.e. in Card Manager OP-Secured) includes the following keys that conform to Global Platform Specifications v2.1.1: 7.2.1 Initial Issuer Transport Key 1. KDC: Initial Issuer Key set: Set of three Triple DES Keys (called KDCENC KDCMAC and KDCKEK) of 16 bytes each. The first two, KDCENC and KDCMAC, are only used to generate Secure Channel session keys during the initiation of a Global Platform Secure Channel, and the last one, KDCKEK is used as a key transport key within a secure channel. The process used to generate a unique KDC per cryptographic module takes place outside of the crypto module. 2. KSC: Initial Issuer Session Transport Keyset: Set of two transient Triple DES Keys (called KSCENC KSCMAC) of 16 bytes each. KSCENC is used for Secure Channel Encryption, and KSCMAC is used for Secure Channel MAC verification. KDCENC and KDCMAC are used to derive KSCENC and KSCMAC keys that are used to authenticate the secure sessions with the card Manager. June 11, 2008 Version 1.1 Page 27 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy KDCKEK does not derive any keys but is used directly to wrap the CO CDK key set and the User ADK key set when they are entered into the module for the first time. As a result this Triple DES KDC can only be used to wrap/unwrap other Triple DES keys of the same size. 7.2.2 Crypto-Officer keys in Card Manager 1. CDK: Crypto-Officer Keyset: Set of three Triple DES Keys (called CDKENC CDKMAC and CDKKEK) of 16 bytes each. 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 as a key transport key within the secure channel to wrap only other Triple DES keys of the same size. The process used to generate a unique CDK per cryptographic module takes place outside of the crypto module. 2. CSK: Crypto-Officer Session Keyset: Set of two transient Triple DES Keys (called CSKENC and CSKMAC) of 16 bytes each. CSKENC is used for Secure Channel Encryption, and CSKMAC is used for Secure Channel MAC verification. 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. 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 Key (16 bytes) used to compute a receipt on Delegated Management Commands. See Delegated Management in section 8.1.2. 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. 7.2.3 User/Applet Provider Keys in Security Domains 1. ADK: Applet Provider Keyset: Set of three Triple DES Keys (called ADKENC ADKMAC and ADKKEK) of 16 bytes each. 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 as a key transport key within the secure channel to wrap only other Triple DES keys of the same size. This keyset is present in both type of Security Domain, Security Domain with Delegated Management, and Security Domain with DAP Verification. The process used to generate a unique ADK per cryptographic module takes place in the cryptographic HSM outside of the crypto module. 2. ASK: Applet Provider Session Keyset: Set of two transient Triple DES Keys (called ASKENC and ASKMAC) of 16 bytes each. ASKENC is used for Secure Channel Authentication and optionally Encryption, and ASKMAC is used for Secure Channel MAC verification. 3. KDAP: Key DAP: Public RSA Key (1024 bits) used to verify the DAP on an application code to be loaded into the module and authorize or not its loading. (See section 8.1.3 on DAP verification). This key may or may not be loaded into the module. It is an added feature and is not intended to June 11, 2008 Version 1.1 Page 28 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy satisfy any of the FIPS 140-2 requirements for applet loading. This key is present only in Security Domain with DAP Verification. More information on how this key is used can be found in section 8.1.3 DAP Verification. 7.2.4 Keys Exchange The following key exchange takes place with the Cryptographic Officer and with the User/Applet provider prior to the module being initialized by Oberthur. The values of the root secrets used to retrieve a module unique CDK, (with optionally KRECEIPT) and ADK are securely exchanged between Oberthur production HSM and respectively the Cryptographic Officer HSM and the User/applet provider HSM using a well defined and highly secure key ceremony described in a separate document. The values of the RSA public Keys KTOKEN and KDAP, are provided respectively by the Cryptographic Officer and the User/applet provider using a method that guarantees the integrity but not necessarily the confidentiality of the transmission. In this FIPS configuration, the CSK and the ASK are the only keys that are not loaded but generated automatically by the module whenever needed. The keys are generated via the Open Platform Card Specification Secure Session Key Generation Process that was approved by NIST/CSE during the first Java based smart card validation. All Java-based smart cards use this process to generate session keys. 7.2.5 Key Loading During the card manufacturing and initialization process, an initial set of Open Platform Keys called KDC is securely loaded into the Card Manager (Crypto-Officer) Security Domain. This key set is generated by a derivation process using a master secret key called KMC and card specific information such as chip serial number. The KDC keyset is used to open a Secure Channel that will protect the loading of the initial value of Crypto-Officer and User Keys (except for the transient session keys ASK and CSK that are not loaded but generated automatically by the module whenever needed). Crypto-Officer and User Key Loading is done using an authentication followed by a PUT3KEY or PUT PUBLIC KEY command depending on the type of key being loaded. Keys are valid until replaced Both the Crypto-Officer and the User/Applet provider can replace their own keys at anytime during the active life of the module or whenever they feel a key may be compromised. This is done using an authentication with the current keyset (CDK or ADK) followed by a Put Key command with "Key update" as parameter. Depending on the key to replace, the PutKey command is actually a PUT3KEY or a PUT PUBLIC KEY command. The new value is loaded into the card encrypted with the old key- set value using the TDES algorithm. June 11, 2008 Version 1.1 Page 29 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 7.2.6 EEPROM encryption Key Security relevant data stored in the EEPROM like cryptographic keys and PINs are automatically encrypted using DES algorithm with a unique secret key generated by the module using an Oberthur proprietary6 key generation algorithm. In addition all EEPROM cells regardless of their content, are encrypted using a low level routine of the chip to protect against direct reading of the cells content. This mechanism is outside of the scope of this security policy. 8 Card Cryptographic Functions The purpose of the cryptographic module is to provide a FIPS approved platform for applets that may in turn provide cryptographic services to end-user applications. The keys represent the identity of the roles involved in controlling the module. A variety of FIPS 140-2 validated algorithms are used in the ID-One Cosmo 128 v5.5 D to provide cryptographic services. (see section 4.7 FIPS Approved Security Functions) Some of these cryptographic services are made available only to applets and through Java APIs. Since the module described in this security policy does not include any instantiated applets other than the Card Manager and Security Domains, security services not used by either the Card Manager or by the Security Domain are not available to any of the current operator of the module. The following describes cryptographic functions that are available to an operator as a service from the Card Manager or a Security Domain. · 2 Key TDES, (128): The TDES (CBC mode) algorithm is used: · For authenticating the Crypto-Officer (EXTERNAL AUTH command) · For encrypting data flow from the off module to the on-module environment. The reverse direction is not encrypted; i.e. the status words returned in response to an APDU are not encrypted. · As a TDES MAC to authenticate the originator and to the verification the integrity of the message. TDES is also used to sign receipts from Delegated Management. · RSA (1024 up to 2048 bit keys)7: RSA functions are provided as services to Card Manager (see Delegated Management below) and to Security domain (see section 8.1.3 DAP Verification below) 6 This is not a FIPS approved implementation 7 In this FIPS configuration, without an application (applet) loaded, the only available service which utilizes the RSA algorithm is one that uses an RSA public key for DAP verification (see section 10.2.3, DAP VERIFICATION). As a result, the use of RSA for encryption, decryption, key wrapping and unwrapping, is not available in this module. June 11, 2008 Version 1.1 Page 30 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 8.1.1 Random Number Generators The cryptographic module offers the services of a FIPS 140-2 approved DRNG (Deterministic Random Number Generator). The random generation algorithm has been certified to be compliant with the FIPS PUB 186-2 standard. 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. 8.1.2 Delegated Management The design of the Oberthur ID-One Cosmo 128 v5.5 D module takes into account the possibility that the Card Issuer (Cryptographic Officer) 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 Issuer the possibility of empowering partnered Applet Providers the ability to initiate approved and pre-authorized Card Content changes (loading, installation, extradition8 or deletion). This approval, which is central to the concept of Delegated Management, ensures that only Card Content changes that the Card Issuer (Cryptographic Officer) has authorized will be accepted and processed by the module. This delegation of control in the Card Content changes gives the Applet 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 a Card Issuer (Cryptographic Officer) as proof that a specific Delegated Management operation has been authorized. Delegated Management Tokens are RSA PKCS1 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 transmitted to a user with Delegated Management privilege. The public RSA key KTOKEN, associated with the Crypto-Officer token signature private RSA key, must be present in the Card Manager. When the User wants to perform the pre-authorized function, it appends to the function's data transmitted through a secure channel with its Security Domain inside the ID-One Cosmo 128 v5.5 D platform the associated token. The User security domain will then decrypt and verify the secure channel communication using its ASK. The function and its associated Token are then automatically 8 Application Extradition allows an Application that is already associated with a Security Domain to be extradited and associated with another Security Domain June 11, 2008 Version 1.1 Page 31 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy transmitted to the Crypto-Officer Card Manager for token verification using the Card Manager KTOKEN Public RSA key. If the signature is verified, the function is authorized to complete. Otherwise, it is aborted and cleared for memory. The Card Issuer's security policy may require the generation of Receipts for Delegated Management operations. A Receipt is a cryptographic value (Triple DES signature on the receipt data) generated by the Card Manager 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 Card Manager. The card manager also keeps track of a Confirmation Counter value that is incremented when generating each Receipt. The receipt is computed by the Card Manager using the KRECEIPT, an ICV of binary zeroes and the signature method described in Global Platform 2.1.1, Appendix B.1.2.2 - Single DES Plus Final Triple DES MAC. 8.1.3 DAP Verification If the Applet 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 Issuer (Cryptographic Officer) and require a check of application code integrity and authenticity before the application code is loaded by the Crypto-Officer. 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 crypto-Officer or by a User with Delegated Management. The DAP Verification privilege for a User 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. The way it works is as follows: The user first computes a SHA-1 message digest of the application that is to be subsequently loaded into the module. He then uses his DAP RSA private key (matching the public key KDAP in the user 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 User 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. June 11, 2008 Version 1.1 Page 32 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 9 Self Tests 9.1 Power Up 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: · EEPROM integrity check using CRC16 algorithm for: o System Data o Optional codes (firmware extensions), if any o Uploaded application packages (Executable Load files), if any · Cryptographic Known Answer Tests for o Triple DES ­ Encryption and decryption in CBC and ECB mode o AES ­ Encryption and decryption in CBC mode o SHA1 Hashing o SHA 256 Hashing o SHA 512 Hashing o RSA signature generation and signature verification o RSA Key wrapping and unwrapping o ECDSA signature generation and signature verification o Deterministic Random Number Generator (DRNG) · Critical Function Tests o CRC-16 KAT o RAM functional test o Sensor bit test o Audit log scan o Resident applet life cycle Additional tests to protect against new types of attacks such as SPA, DPA, "flash gun", EMI etc, are also performed at this stage. June 11, 2008 Version 1.1 Page 33 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy The module does not respond to any commands while self-tests are being performed. If any of the above tests fail, the card will enter an error state in which further APDU's are not processed. Depending on the test that fails, the module may return an error status before becoming mute. More details about all the power-up self-tests and their implementation are provided in a separate confidential document. 9.2 Conditional Tests RSA Key generation: After generating an RSA key pair, the module performs a double pair wise consistency check to validate that the generated key pair is correct for both signature/verification and encryption/decryption. Description of the implementation of this test is provided in a separate document. Elliptic Curve Key generation: After generating an ECC key pair, the module performs a pair wise consistency check to validate that the generated key pair is correct for signature and verification. Description of the implementation of this test is provided in a separate document. Random Number Generators: Continuous testing is performed on every output of the Random Number Generators. (Both Deterministic and Non Deterministic) RNGs. Other statistical testing is also performed to ensure the highest possible quality of the generated random numbers. Detailed description of the module Random Number Generator and associated tests is provided in a separate document (IRS). Credentials: Keys and PINs: Each time a credential is used, whether a TDES, or RSA key or a PIN, its integrity is checked by an EDC. Description of the implementation of these checks is provided in a separate document. Software (Applet) load tests: A TDES128 CBC MAC on the applet executable load file is verified each time an applet is loaded onto the cryptographic module since applet loading always takes place within a Secure Channel. An optional DAP verification can also made. The algorithm used is RSA1024 signature verification. If TDES MAC or DAP verification fails, the package load is terminated and the module built-in garbage collector cleans the EEPROM of any traces of the aborted download. Description of the implementation of this test is provided in Global Platform 2.1.1 Specifications. 9.3 Key Load Tests: · Symmetrical Keys (TDES) are transmitted encrypted together with a KCV (Key Check Value) that is checked by the module to verify correct decryption of the key. The KCV is the first 3 bytes of the cryptogram generated when encrypting 8 bytes of `00' with the symmetrical key. June 11, 2008 Version 1.1 Page 34 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 10 Finite State Machine The Open Platform Card Manager manages the states of the Java Card platform and applets life cycle. The cryptographic platform has its Card Manager in OP-Secured phase when issued to a user. The Finite State Machine diagrams applicable to the module are provided as a separate document. 11 Physical Security The Oberthur ID-One Cosmo 128 v5.5 D is a single chip cryptographic module. It is designed to meet FIPS 140-2 Level 3 requirements for physical security. The module is a production quality IC. It meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. It uses standard passivation techniques for the entire chip. In addition to the passivation material, a hard, opaque epoxy, that is resistant to commonly available solvents, is used to encapsulate the module into an opaque support. The chip is usually in possession of the Card Security Controller or of the Applet Provider, or of the Card Holder. In order to physically attack the module, an attacker will have to take possession of the module and use extraordinary means such as electronic probe or electronic microscope. As the chip module is covered with a hard, tamper-evident resin, that resin must be removed to attempt any physical attack on the chip. In this event, the absence of the chip is easily detected by its owner. Once the chip has been attacked through extraordinarily physical means, the attack leaves permanent evidence and is consequently detected by the owner. In addition to the above passivation material, the following active features available in the module provide increased protection against physical attacks: · Low / high supply voltage sensor · Low / high clock frequency sensor · Low / high temperature sensor · Light sensor · Single fault injection (SFI) attack detection · Programmable "Card Disable" feature June 11, 2008 Version 1.1 Page 35 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 12 EMI/EMC The cryptographic module meets the Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) requirements specified by United States Standards 47 CFR Part 15, Subpart B: "Unintentional Radiators, Digital Devices, Class B". It is also in compliance with the electromagnetic compatibility requirements defined in European Standard EN 55022, Class B: "Limits and Methods of Measurement of Radio Interference Characteristics of Information Technology Equipment." 13 Operational Environment During the manufacturing process, any applet executable load file can be loaded into the ID-One Cosmo 128 v5.5 D Java Card platform, but those files remain dead code until activated through an instantiation process, and only trusted (FIPS validated) applets can be instantiated. After completion of the manufacturing process (including pre-issuance), when the chip has reached its normal Operating Life Cycle State (Card Manager in Secured State), it is the responsibility of the Cryptographic Officer to insure that only FIPS validated instances are created. The FIPS 140-2 Area 6 Operational Environment requirements are therefore not applicable. 14 Security Rules 14.1 Approved mode of Operation The ID-One Cosmo 128 v5.5 D described in this security policy does not include any non-FIPS validated applet instances. As such, the cryptographic module is always in an approved mode of operation. The security services described in this document can be used to load any kind of applets into the ID-One Cosmo 128 v5.5 D Java Card Chip Platform. However, it is the responsibility of the Cryptographic Officer to insure that only FIPS validated instances are created. The FIPS approved mode of operation for the validation described in this Security Policy starts from the instantiation of the Card Manager and Security Domains and ends with the instantiation of any non- FIPS validated applets. The Cryptographic Officer can determine whether the card is still in FIPS mode by authenticating to the Card Manager and issuing a Get Status command to list all the applications instances currently installed in the card. However, with Java card, an application can be given any AID (application Identifier) during instantiation, regardless of the identity of the underneath executable load file. To prevent a non FIPS approved applet to be instantiated and given the AID of an approved applet, Oberthur has implemented a special Get Status command that returns not only the AID given to the June 11, 2008 Version 1.1 Page 36 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy applet instance, but also, and more important, the AID and version number of the underlying executable load file. The Cryptographic Officer can then at any time check that only FIPS approved executable load files have been instantiated. 14.2 Identification & Authentication Security Rules The module implements specific methods for identifying and authenticating the different roles. The implementation consists of the binding of an Identity-based Access Control Rule to each service. 14.2.1 User Identification and Authentication The operator who wishes to authenticate into the User/Applet Provider role must first identify him/herself by providing both an application identifier and a Key Set ID. The authentication is then done by proving the possession of the particular keyset identified in the identification phase. This Key Set is composed of 3 TDES keys. One key is used to encrypt the command data, one key to authenticate the user, and the third key is used to encrypt keys transported within the APDU command. This is the same process as the Crypto-Officer authentication (Initialize Update & External Authenticate commands) but it uses the TDES keys of the Applet Provider Security Domains. 14.2.2 Cryptographic Officer Identification & Authentication The operator that wishes to authenticate into the Cryptographic Officer Provider role must first identify him/herself by providing both information to uniquely select the Card Manager, and a Key Set ID. The authentication is then done by proving the possession of the particular keyset identified in the identification phase. This Key Set is composed of 3 TDES keys. One key is used to encrypt the command data, one key to authenticate the user, and the third key is used to encrypt keys transported within the APDU command. This is the same process as the User authentication (Initialize Update & External Authenticate commands). 14.3 Applet Loading Security Rules Applets can only be loaded through a secure channel; i.e. they pass from the off-module to the on- module environment in a MACed form. An additional applet encryption is also available as an option. To activate that option, the Cryptographic Officer would have to request the encryption option when opening the secure channel with the module. In the ID-One Cosmo 128 v5.5 D platform, the applet is always loaded by the Card Issuer (Cryptographic Officer). The optional mechanism designated as "DAP" in GP 2.1.1 enables the applet provider to check, independently of the Card Issuer (Cryptographic Officer), that his applet has been correctly loaded. This check is done by verifying a RSA PKCS #1 signature on the Hash of the applet code being loaded. This process is described in detail in the GP 2.1.1 document. See section 17 Applicable Documents. For the ID-One Cosmo 128 v5.5 D to run in a validated FIPS 140-2 Level 3 mode of operation, all applet instances must be validated to the same level. Although any applet can be loaded during post June 11, 2008 Version 1.1 Page 37 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy issuance, it is the responsibility of the Cryptographic Officer to insure that only FIPS 140-2 Level 3 validated instances are created. Instantiation of non-validated applets within the FIPS 140-2 validated cryptographic module, or instantiation of a FIPS 140-2 validated applet with a different security level, will invalidate the original validation. FIPS 140-2 Level 3 validated applets may be loaded and instantiated at post issuance. 14.4 Key Management Security Policy 14.4.1 Cryptographic key generation TDES Session key derivation for Secure Channel Opening, conforming to Open Platform Card Specification v2.1 (SCP01) using FIPS186-2 approved ANSI X9.31 DRNG. 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. This cryptographic service is made available through Java APIs only. 14.4.2 Cryptographic key entry Keys shall always be input in encrypted format, using the Put Key (TDES or Public) 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. Keys can never be output by the module. 14.4.3 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. The cryptographic key storage integrity mechanism is described in a separate confidential document called Self Test Description. 14.4.4 Key Destruction The ID-One Cosmo 128 v5.5 D destroys cryptographic keys by reloading another key-set with the same version number for Crypto-Officer/Card Security Controller Keys and User/Applet Provider Keys, using the PUT TDES KEY or PUT PUBLIC KEY command. June 11, 2008 Version 1.1 Page 38 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy User/Applet Provider Keys can also be zeroized by deleting the Security Domain that hosts the keys, using the DELETE command. Closing of the secure channel has also the effect of zeroizing the associated session keys stored in RAM memory. Key zeroization is achieved by the Oberthur Garbage Collector that overwrites with binary zeros the deleted key value in its memory zone (whether in RAM or in EEPROM). June 11, 2008 Version 1.1 Page 39 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 15 Mitigation of Other Attacks Policy 15.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 PIV EP card 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. 15.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. 15.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. June 11, 2008 Version 1.1 Page 40 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy The Oberthur PIV EP card includes a combination of software and hardware protections in order for the chip not to operate in extreme conditions that may cause processing 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 9.2 Conditional Tests 15.4 Flash Gun The Oberthur PIV EP card 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. 15.5 ElectroMagnetic Attacks The Oberthur PIV EP card includes a combination of software and hardware protections in order to detect "EMI" type of attacks and abort any current processing before becoming mute. June 11, 2008 Version 1.1 Page 41 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 16 Security Policy Check List Tables 16.1 Roles and required Identification and Authentication Role Type of Authentication Authentication Data Crypto-Officer/Card TDES Authentication TDES Keys (Crypto-Officer Security Domain) Security Controller (CSC) User/Applet TDES Authentication TDES Keys (User/Applet Provider Security Domain) Provider (AP) 16.2 Strength of Authentication Mechanisms Authentication Mechanism Strength of Mechanism TDES Authentication The strength of the authentication mechanism is equal to or greater than 80 bits. Therefore the probability that a random authentication attempt succeeds is less than 1 in 1,000,000. RSA Authentication The strength of the authentication mechanism is equal to or greater than 80 bits. Therefore the probability that a random authentication attempt succeeds is less than 1 in 1,000,000 16.3 Services Authorized for Roles Role Authorized Services Crypto-Officer/Card All Crypto-Officer Services are listed in section 6.2. Security Controller (CSC) User/Applet Provider (AP) All User/Applet Provider Services are listed in section 6.2. 16.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 June 11, 2008 Version 1.1 Page 42 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 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 June 11, 2008 Version 1.1 Page 43 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 17 Applicable Documents · "Java Card 2.2.2 - API" Application Programming Interfaces Version 2.2.2 March, 2006, Sun Microsystems · "Java Card 2.2.2 ­ JCRE " Runtime Environment Specification Version 2.2.2 March, 2006, Sun Microsystems · "Java Card 2.2.2 - Virtual Machine Specifications" Version 2.2.2 March, 2006, Sun Microsystems · "Global Platform 2.1.1" Card Specification v2. 1, 01 Mars 2003 · ISO/IEC 7816-3 (2006) Identification cards - "Integrated circuit(s) cards with contacts - Part 3 Electronic signal and transmission protocols." · ISO/IEC 7816-4 (2005) Identification cards - "Integrated circuit(s) cards with contacts - Part 4: Inter industry commands for interchange." · ISO/IEC 7816-5 (2004) Identification cards - "Numbering system and registration procedure for application identifiers" · EMV 2000 "Integrated Circuit Card Specifications for Payment Systems" o Part 1: Electromechanical Characteristics, Logical Interface, and Transmission Protocols (version 3.0) o Part 2: Data Elements and Commands (version 3.0) o Part 3: Application Selection (version 3.0) o Part 4: Security Aspects (Version 3.0) · "Java Card 2.2 Biometry API proposal " Javadoc version (4-4-02) on JCF web site · ISO/IEC 14443-3 (2001-02-01) "Identification cards ­ Contactless integrated circuit(s) cards ­ Proximity cards ­ Part 3: Initialization and anticollision" · ISO/IEC 14443-4 (2001-02-01) "Identification cards ­ Contactless integrated circuit(s) cards ­ Proximity cards ­ Part 4: Transmission protocol" · [FIPS140-2] National Institute of Standards and Technology, FIPS 140 -2 standard. · [FIPS140-2A] National Institute of Standards and Technology, FIPS 140 -2 Annex A: Approved Security Functions. · [FIPS140-2B] National Institute of Standards and Technology, FIPS 140 -2 Annex B: Approved Protection Profiles, June 11, 2008 Version 1.1 Page 44 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy · [FIPS140-2C] National Institute of Standards and Technology, FIPS 140 -2 Annex C: Approved Random Number Generators · [FIPS140-2D] National Institute of Standards and Technology, FIPS 140 -2 Annex D: Approved Key Establishment Techniques · [DES] National Institute of Standards and Technology, Data Encryption Standard, Federal Information Processing Standards Publication 46-3, October 25, 1999. · [DES Modes] National Institute of Standards and Technology, DES Modes of Operation, Federal Information Processing Standards Publication 81, December 2, 1980. June 11, 2008 Version 1.1 Page 45 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy 18 Definitions and Acronyms 18.1 Definitions 18.1.1 Card Manager The Card Manager, also called Issuer Security Domain, is the on-card representative of the Card Issuer (Cryptographic Officer). It is the most privileged entity of the cryptographic module as it is the only entity that performs Card Content management without having been explicitly delegated previously. Privileges of the Card Manager include but are not limited to card locking, card termination, CVM (Card Holder Verification Method) management, and multiple selections (through logical channels). The Issuer Security Domain shall have the following set of privileges clearly identifying its functionality (i.e. a Security Domain with card lock, card terminate and CVM management privileges and possibly the Default Selected privilege) in addition to its implied unrestricted Card Content management privilege. If the card supports Supplementary Logical Channels, the Issuer Security Domain shall also have the multiple selection privilege. 18.1.2 Security Domains Security Domains allow a number of distinct identities to be established on the ID-One Cosmo 128 v5.5 D platform. These are identities that control access to the various applets stored on the module. A Security Domain represents the identity of an application (applet) operator. 18.1.3 Applets "Applets" are applications that can be executed on the Chip Platform. They come in two parts; the applet executable code, which defines all the functions that could be executed on the Chip Platform, and the Applet Instance, that provides the environment (i.e. variables) and an interface to the functions present in the applet executable code. An applet can have several instances, each with its own variables, but all sharing the same functionality as defined in the underlying executable code. The Applet Instance is the mandatory communication path between the applet Executable Module and the outside world. In order for an application to be activated and provide its high level services to the outside world, two prerequisites must have been fulfilled: 1. The Applet Executable Load File, that contains the actual Java code (Executable Module) of the application, must be present on the Chip Platform. This can be achieved by physically downloading the load file into the Chip Platform EEPROM, or by activating a pre-loaded Executable Load File present in ROM. 2. At least one applet instance of the executable module must have been created. The services described in this Security Policy allow the security officer to load and unload (delete) any applets. This allows the loading of executable load files, which can take up to 30 seconds depending of June 11, 2008 Version 1.1 Page 46 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy the size of the file, to take place during pre-issuance. Until the time they are instantiated, the executable load files can be considered as "dead code". The actual applet activation, which is done through instantiation, takes only a few milliseconds and could take place in post issuance, under the control of the Security Officer, and after the applet has been FIPS 140-2 validated. For the cryptographic module to be correctly operated according to this Security Policy, applets instantiated into the Chip Platform must be validated to FIPS 140-2. 18.2 Acronyms · AES Advanced Encryption Standard · AID Application Identifier · AP Applet Provider · APDU Application Protocol Data Unit · API Application Programming Interface · ATR Answer To Reset (contact mode) · ATS Answer to Select (contactless mode) · API Application Programming Interface · BAP Batch Approval Process (First article validation from Production line) · CBC Cipher Block Chaining · CRC Cyclic Redundancy Check · CSP Cryptographic Security Parameter · DAP Data Authentication Pattern · DES Data Encryption Standard · DPA Differential Power Analysis · DM Delegated Management · DRNG Deterministic Random Number Generator · ECB Electronic Code Book · EEPROM Electrically Erasable and Programmable Read Only Memory · EMI Electromagnetic Interference · EMC Electromagnetic Compatibility · HCL Hardware Compatibility List · ICAO International Civil Aviation Organization · ISO International Standard Organization June 11, 2008 Version 1.1 Page 47 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision Oberthur ID-One Cosmo128 v5.5 D Security Policy · JC Java Card TM · JCRE Java Card TM 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 · TLV Tag Length Value · WHQL Microsoft Windows Hardware Quality Lab June 11, 2008 Version 1.1 Page 48 / 48 © 2007 Oberthur Card Systems Inc. This document may be reproduced only in its original entirety without revision