Smart Cards Cyberflex Access e-gate 32K FIPS140-2 Level 3 Cryptographic Module Security Policy June-03 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 1 / 1 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards Table of Contents 1. INTRODUCTION.....................................................................................................................................3 2. OVERVIEW.............................................................................................................................................3 3. SECURITY LEVEL.................................................................................................................................4 4. CRYPTOGRAPHIC MODULE SPECIFICATION ..................................................................................4 4.1 MODULE INTERFACES .........................................................................................................................5 4.1.1 Physical Interface description....................................................................................................5 4.1.2 Electrical specifications.............................................................................................................5 4.1.3 Logical Interface Description.....................................................................................................6 5. ROLES & SERVICES.............................................................................................................................6 5.1.1 Roles..........................................................................................................................................6 5.1.2 Services.....................................................................................................................................7 5.1.3 Critical Security Parameters:...................................................................................................12 6. SECURITY RULES...............................................................................................................................12 6.1.1 Identification & Authentication Security Rules ........................................................................12 6.1.2 Applet Loading Security Rules ................................................................................................13 6.1.3 Access Control Security Rules................................................................................................13 6.1.4 Physical Security Rules...........................................................................................................13 6.1.5 Key Management Security Policy............................................................................................13 6.1.6 Mitigation of attacks Security Policy........................................................................................13 7. SECURITY POLICY CHECK LIST TABLES.......................................................................................13 7.1 ROLES & R EQUIRED A UTHENTICATION .............................................................................................13 7.2 STRENGTH OF AUTHENTICATION MECHANISMS .................................................................................13 7.3 S ERVICES AUTHORIZED FOR ROLES .................................................................................................13 7.4 ACCESS R IGHTS WITHIN S ERVICES ...................................................................................................13 7.5 MITIGATION OF OTHER A TTACKS ......................................................................................................13 8. REFERENCES......................................................................................................................................13 9. ACRONYMS.........................................................................................................................................13 June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 2 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 1. INTRODUCTION This document defines the Security Policy for the Cyberflex Access e-gate 32K cryptographic module. The cryptographic module is an IC with its embedded firmware, designed to be put on a plastic card to produce the Cyberflex Access e-gate 32K smart card as shown in figure 1. The cryptographic module is submitted for validation, in accordance with FIPS140 -2 Level 3 standard. Included is a description of the security requirements for the Cyberflex Access e-gate 32K cryptographic 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. Figure 1 2. OVERVIEW The Cyberflex Access e-gate 32K cryptographic module from Schlumberger contains a microprocessor and EEPROM to provide processing capability and memory for storing instructions and data. The cryptographic module loads and runs applets written in the Java programming language. The product can be used to store and update account information, personal data, and even monetary value. The cards are ideal for secure Internet access, purchases, portable digital telephones, and for benefit programs and health care applications. Cyberflex Access e-gate 32K cryptographic module brings new services, as well as increased security, portability, and convenience, to computer applications. The Cyberflex Access e-gate 32K cryptographic module combines the advantages of the Java programming language and cryptographic services with those of the micro module. Cyberflex Access security comes from both software and hardware. Data integrity and security are provided through cryptographic services, Java Card TM features, and the Systems Software. In addition, the Cyberflex Access e-gate 32K module hardware provides tamper-resistance and tamper-evidence features, that meet FIPS140-2 Level 3 physical requirements. The Cyberflex Access e-gate 32K contains an imp lementation of the Java Card TM specification (JC) Version 2.1.1 and of the Open Platform (OP) Version 2.0.1' specification, which defines a secure infrastructure for post-issuance programmable smart cards. The JC specification defines Java Card TM Application Programming Interface (API), that can be used by applet developers to take advantage of the various on-board cryptographic services. The Cyberflex Access e-gate 32K cryptographic module is a "post-issuance programmable" cryptographic module. It includes a virtual machine interpreter that allows programs (applets) written in Java to be loaded onto the Cyberflex Access e-gate 32K module and placed into execution. The OP specification defines a life cycle for OP compliant smart cards. State June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 3 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards transitions between states of the life cycle involve well-defined sequences of operations. Once applets are loaded and the Cyberflex Access e-gate 32K module is initialized, external applications communicate with Cyberflex Access e-gate 32K through a secure channel that is established as part of the Cyberflex Access e-gate 32K module's initialization process when it is inserted into a Card Acceptance Device (CAD), or card reader. The Secure channel is established by the Cryptographic Officer with the Open Platform Card Man ager application on the Cyberflex Access e-gate 32K module. Through the Card Manager, a secure communication pathway can be established with any of the applets on the Cyberflex Access e-gate 32K module. Each applet can provide additional "command services" which can be accessed by external applications. Applets loaded post validation must also be validated to FIPS140-2 in order to keep valid the Cyberflex Access e-gate 32K cryptographic module validation. If an applet, which is not FIPS validated, is loaded on this module, the module loses its FIPS validation. 3. S ECURITY L EVEL The Cyberflex Access e-gate 32K cryptographic module is designed and implemented to meet the Level 3 requirements of FIPS140-2. The cryptographic module enforces FIPS mode of operation at any time. The individual security requirements specified for FIPS 140-2 meet the level specifications indicated in the following table. Security Requirements Section Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self Tests 3 Design Assurance 3 Mitigation of other attacks 3 4. C RYPTOGRAPHIC MODULE SPECIFICATION The Cyberflex Access e-gate 32K cryptographic module supports a command set aimed at allowing the mutual authentication of identities using strong cryptography with "card acceptance devices" in ISO or USB mode (and PCs or other 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 to authenticate 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 Cyberflex Access e-gate 32K module . This validation effort will be aimed at the Systems software, virtual machine, and Card Manager application without any applets. If applets are added to this Cyberflex Access e-gate 32K module, then these additional applets will need to go through a separate validation and will need to be FIPS 140-2 validated. Consequently, the Cyberflex Acce ss e-gate 32K cryptographic module together with the approved applets will still be FIPS140 -2 validated. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 4 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards Cyberflex Access e-gate 32K module adheres to the various ISO/IEC specifications for Integrated Circuit Chip (ICC) based identification cards. The "cryptographic boundary" for the Cyberflex Access e-gate 32K module vis-à-vis the FIPS 140-2 validation is the "module edge". The module is comprised of the chip (ICC), the contact faceplate, and the micro -electronic connectors between the chip and contact pad. Cyberflex Access e-gate 32K is a single chip implementation of a cryptographic module. The Cyberflex Access e-gate 32K chip is comprised of the following elements: · STMicroelectronics ST19 XT34, 8 bit micro controller, System software is installed in Read Only Memory (ROM) as part of the chip manufacturing process (known as Hard mask) and in Electrically Erasable, Programmable Read Only Memory (EEPROM) for system options and additional customized software (known as soft mask). The software is then designated: Hard Mask n°2 Version 02; Soft Mask n°3 Version 01. Note that in the smart card world, Hard Mask refers to software stored in ROM; in other guises, this might be referred to as "firmware". These hard mask and soft mask identification numbers are returned in the Answer To Reset (ATR) character string following the issuing of a RESET signal to the Cyberflex Access e-gate 32K module (ATR is: 3B 75 94 00 00 62 02 02 03 01). · Applets that are to be loaded on Cyberflex Access e-gate 32K module (not part of the present validation), · Critical Security Parameters stored in EEPROM as part of the Cyberflex Access e-gate 32K module personalization operation. 4.1 M ODULE INTERFACES The electrical and physical interface of the cryptographic module, is comprised of the 8-electrical contacts from the surface of the module to the chip. These contacts conform to the following specifications. 4.1.1 Physical Interface description The Cyberflex Access e-gate 32K cryptographic module supports eight contacts that lead to pins on the chip. Only seven of these are used. The location of the contacts complies with ISO/IEC 7816-2 standard. Minimum contact surface area is 1.7mm * 2.0 mm. Contact dimensions are standard credit card compliant as per ISO/IEC 7816-1 standard: Dimension Value Length 85.5mm Width 54.0mm Thickness 0.80mm 4.1.2 Electrical specifications 4.1.2.1 Specific electrical functions of the contacts: Contact Function C1 Vcc supply voltage 3 to 5V +/- 0.5V Vbus supply voltage (USB mode) C2 RST (Reset) C3 CLK (Clock) C4 D+ (USB Signal) C5 GND (Ground) C6 Not used C7 I/O bi-directional line C8 D- (USB Signal) June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 5 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 4.1.2.2 ICC supply current: Maximum value: 10 mA at 5MHz (3mA type), short time peak value according to ISO 7816-3. The communication between the card reader and the Cyberflex Access e-gate 32K cryptographic module is based either on a standardized, half-duplex character transmission, ISO 7816 protocol, or on USB 1.1 protocol. Both ISO protocols T=0 and T=1 are supported. 4.1.3 Logical Interface Description Once electrical (physical) contact and data link layer contact is established between the Cyberflex Access e-gate 32K module and the card reader, the Cyberflex Access e-gate 32K module functions as a "slave" processor to implement and respond to the card reader commands. The Cyberflex Access e-gate 32K module adheres to a well-defined set of state transitions. Within each state, a specific set of commands is accessible. The details of these commands are listed hereafter. This Cyberflex Access e-gate 32K module also provides an additional set of on-module services through the Java Card TM APIs. These additional services are described in section 5.1.2.4 . 5. ROLES & SERVICES 5.1.1 Roles The Cyberflex Access e-gate 32K cryptographic module defines two distinct roles that are supported by the internal cryptographic system: the Cryptographic Officer and the User. - Cryptographic Officer: This role is the on module security controller. The Cryptographic Officer establishes his identity on the Cyberflex Access e-gate 32K module by demonstrating to the Card Manager application that he possesses the knowledge of a TDES key set stored within the Card Manager. By successfully executing a series of commands, the Cryptographic Officer establishes a secure channel to the Card Manager; estab lishment of this channel includes mutual authentication of identities between the Cryptographic Officer and the Card Manager. Once established, authorization (on the Cyberflex Access e-gate 32K module) to information and services is granted by the Card Manager. The Card Manager Security Domain corresponds to the Card Issuer Security Domain. - User/Applet provider: the Applet Provider is the applet developer that uses the Java API, provided on the Cyberflex Access e-gate 32K module. He is regarded as an internal user to the Card. The cryptographic services provided by the Cyberflex Access e-gate 32K module are delivered through the use of appropriate APIs. An applet has its own Security Domain (Applet Provider Security Domain). Identity based Authentication - Identification. The operator identifies himself by selecting his application and the key set inside the application. The application of Cryptographic Officer is the Card manager. The application of the applet provider is his own applet. The selection of the application is done by a SELECT command. The selection of the key set is done in the INITIALIZE UPDATE, the first command of the two commands that open the Secure Channel. - Authentication. The operator authenticates himself using a mutual authentication co mprising 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 which was referenced during the identification. Notes: 1. The CardHolder is the end user of the Cyberflex Access e-gate 32K module (when applets are loaded), who is responsible for insuring the ownership of his Cyberflex Access e-gate 32K module. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 6 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards The CardHolder will then be authenticated by verification of a PIN. Dedicated services are prepared on the Cyberflex Access e-gate 32K module to manage the CardHolder PIN (GlobalPIN). 2. The applets that will be downloaded onto the Cyberflex Access e-gate 32K module may define other distinct roles that will be part of the applets validation, including the Cardholder, who is responsible for insuring the ownership of his Cyberflex Access e-gate 32K module and for not communicating his PIN. The Card Holder will then be authenticated by verification of a PIN. The Card Manager is t e controlling application on the Cyberflex Access e-gate 32K module. It is h invoked following every Cyberflex Access e-gate 32K module reset and initialization operation. 5.1.2 Services 5.1.2.1 Crypto Officer Administrative Services One command set is supported by the Crypto Officer, and is, in fact, used only by the Crypto Officer to allow for the administration of the Security Domains and to load applets onto the Cyberflex Access e- gate 32K module. This command set includes the following commands: · INSTALL (CO): installing an application or a Security Domain requires the invocation of several different on -module functions. The INSTALL command is used to instruct a Security Domain or the Card Manager as to which installation step it shall perform during an application installation process. · LOAD (CO): this command is used to load the byte-codes of the Load File (package) defined in the previously issued INSTALL command. · DELETE (CO): this command is used by the Crypto Officer to delete a Load File (package) or an Application (applet instance). · PIN CHANGE / UNBLOCK (CO): this command is used by the Crypto Officer to store, replace or unblock the Global PIN (Card Holder PIN). Applets loaded onto the Cyberflex Access e-gate 32K module must be FIPS 140-2 validated. Applets are loaded inside a Secure Channel established by the Crypto Officer with the Card Manager during the Identification/authentication process. The applet is divided in a series of blocks that fit in a LOAD command. The loading is made of a series of LOAD co mmands, each one transmitting a block, encrypted and followed by a TDESMAC with the TDES key set selected by the Crypto Officer during the identification process. The TDESMAC ensures the correct transmission of each block of the applet, therefore ensuring the correct transmission of the whole applet. Additionally (and optionally) a mechanism called "OP DAP" enables the applet provider to check, independently of the Issuer, that his applet has been correctly loaded. This check is done by an EDC on the applet. This EDC is made of a series of DES, ended by a TDES. All the DES and TDES operations use the applet provider `s keys, loaded in his Security Domain. 5.1.2.2 Crypto Officer & User services Commands that are available for both the Crypto Officer & the User are the following commands: · EXTERNAL AUTHENTICATE: this command is used by the Cyberflex Access e-gate 32K module to authenticate the host, to establish the Secure Channel, and to determine 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. · GET DATA: the GET DATA command is used to retrieve a single data object. This command is available outside of a Secure Channel (no security condition). However, if issued within a Secure Channel, it must follow the same security level as defined in EXTERNAL AUTH. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 7 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards · GET STATUS : if the Card Manager is the current application, this command is used to retrieve Card Manager information according to a given search criteria. · GET RESPONSE this command is restricted to T = 0 ISO protocol for an incoming command : which have data to send back. That data is received with the GET RESPONSE command sent immediately after the command it is related to. · INITIALIZE UPDATE: this command is used to initiate a Secure Channel with the Card Manager or a Security Domain. Cyberflex Access e-gate 32K module and host session data are exchanged, and session keys are generated by the Cyberflex Access e-gate 32K module upon completion of this command. However, the Secure Channel is not considered open until completion of a successful EXTERNAL AUTHENTICATE command that must immediately follow the INITIALIZE UPDATE command. · PUT DATA : this command is used to store or replace one tagged data object provided in the command data field. · PUT KEY: this command is used to add or replace Security Domain key sets. · SELECT: this command is used for selecting an application(Card Manager, Security Domain or Applet). The Card Manager may be selected either for the loading of a Load File or for installing a previously loaded application (or Security Domain). · PRNG Statistical Test: this command is used to execute the FIPS140 -2 approved statistical tests for randomness on the PRNG . · SET STATUS (CO & User): this command is used to modify the life cycle state of the Cyberflex Access e-gate 32K module or the life cycle state of an application. All commands except (Select, Initialize update, External Authentication and Get Data) need a secured channel to be executed. During the secure channel opening, the command access condition is specified (`CLEAR','MAC','MAC+ENC') and an access control is done on received commands. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 8 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 5.1.2.3 Relationship between Roles & Services Roles/Services Crypto -Officer User/Applet Providers Unauthenticated (Card Manager (Applet Provider (Any role) Security Domain) Security Domain) INSTALL X LOAD X DELETE X EXTERNAL X X AUTHENTICATE GET DATA X GET STATUS X GET RESPONSE X INITIALISE UPDATE X X PIN X CHANGE/UNBLOCK PUT DATA X X PUT KEY X X SELECT X PRNG Statistical X X X TEST SET STATUS X X 5.1.2.4 Applets Services Applets that are developed and downloaded onto the Cyberflex Access e-gate 32K module shall use the Cyberflex Access e-gate 32K Ja va APIs. These APIs are only available to applets. So they are not accessible before an applet is loaded. These APIs are listed in the product technical specifications detailed as a separate proprietary document. Among them, the ones that contain cryptographic services are the following: - Key Generation/Exchange: - RSA key pair generation: this API generates a pair of RSA keys using ANSI X9.31 approved method. - Key exchange: RSA algorithm API supports key wrapping/unwrapping. - Message Digest: - SHA-1: this API performs a SHA -1 Message Digest. - Random Numbers Generation: - Secure Random Generation: this API generates a random data, using ANSI X9.31 FIPS140-2 approved method (Deterministic RNG). - Signature and Verification: - RSA SHA-1 PKCS1 mode. - Origin authentication and Data integrity verification: - DES/TDES: these APIs offer DES or TDES MAC in CBC mode with various padding (no padding, ISO9797 M1 and M2). - Bulk Encryption/Decryption: - DES/TDES: these APIs offer DES/TDES CBC or ECB mode using various padding (no padding, ISO9797 M1 and M2). June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 9 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards These algorithms shall be use only in a FIPS approved mode of operation. This will be checked during the applet's FIPS 140-2 validation. We recall that only FIPS 140-2 validated applet shall be loaded on the Cyberflex Access e-gate 32K module. The OP specification defines also various OP APIs that may be used by the applets and that provide the same services as the Card Manager Commands (such as secure channel opening). In particular, the Global PIN may be implemented by the applets thr ough the use of a dedicated API. 5.1.2.5 Relationship between Roles and APIs services Roles/Services Crypto -Officer Applet Providers/User (Card Manager (Applet Provider Security Domain) Security Domain) RSA Key generation X X SHA-1 X X Secure Random Generation X X DES/TDES MAC X X Signature and Verification RSA SHA-1 PKCS1 X X Signature and Verification DES/TDES X X Encryption/Decryption RSA PKCS1 X X Key wrapping The APIs are dedicated to applets. The Crypto-Officer can use these APIs if he owns an applet and only through this applet. 5.1.2.6 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 Cyberflex Access e-gate 32K module. A variety of FIPS 140-2 validated algorithms are used in the Cyberflex Access e-gate 32K cryptographic module to provide cryptographic services; these include: · DES: · DES is used together with TDES as an EDC. It enables the Applet Provider to verify the correct loading of the applet. The algorithm is a series of DES terminated by a TDES as described in OP 2.0.1'. · DES functions are also provided as services to applets, through Java APIs. They shall be used only for legacy systems. · TDES, (2 keys TDES): · 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 TDESMAC to authenticate the originator and to the verification the integrity of the message · TDES is also used together with DES as an EDC (cf. DES). · TDES functions are also provided as services to applets, through Java APIs. · SHA-1: · The SHA-1 function is only provided as a service through Java APIs to applets. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 10 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards · RSA PKCS1 (512, 768, 1024 bit keys): · RSA functions are only provided as services to applets, through Java APIs. The applet shall use RSA only for "key wrapping" or "signature". This will be checked during the applet's FIPS validation. DES, TDES, RSA and SHA -1 algorithms are provided as services to applets that may be loaded onto the Access e-gate 32K module. These algorithms shall be use only in a FIPS approved mode of operation. This will be checked during the applet's validation. 5.1.2.7 RNG The cryptographic module offers the services of a FIPS approved PRNG using ANSI X9.31 standard. 5.1.2.8 Self Tests 5.1.2.8.1 Power Up Self Tests The Cyberflex Access e-gate 32K cryptographic module performs the required set of self-tests at power- up time. When the Cyberflex Access e-gate 32K module is inserted into a reader, once power is applied to the module's electrical (con tact) interface, a "Reset" signal is sent from the reader to the Cyberflex Access e-gate 32K module. The Cyberflex Access e-gate 32K module then performs a series of GO/NO- GO tests before it responds (as specified by ISO/IEC 7816) with an Answer To Reset (ATR) packet of information. These tests include: · RAM functional test & clearing at Reset, · HRNG functional test, · EEPROM Firmware integrity check, · Algorithm (known answer) tests for: · CRC16, · DES (ECB & CBC mode encrypt/decrypt), · TDES (ECB & CBC mode encrypt/decrypt), · SHA-1 Hashing, · RSA PKCS1 sign and verify. If any of these tests fail, the Cyberflex Access e-gate 32K module will respond with an ATR and a status indication of self-test error. Then, the Cyberflex Access e-gate 32K module will go mute. No data of any type is transmitted from the Cyberflex Access e-gate 32K module to the reader while the self-tests are being performed. 5.1.2.8.2 Conditional Tests RSA Key generation: A pair wise consistency check is performed during key generation. Random Number Generator: HRNG: A 16 bits continuous testing is performed during each use of the Hardware non deterministic RNG. The HRNG is used to generate seed values to feed the PRNG. PRNG: A 16 bits continuous testing is performed during each use of the FIPS140-2 approved deterministic RNG. Software/Firmware load test A TDES CBC MAC is verified each time an applet is loaded onto the Cyberflex Access e-gate 32K module. An optional "OP DAP" verification is made. This is an EDC that enables the Applet Provider Security Domain to check that the applet has been correctly loaded. The algorithm uses DES for the first n-1 blocks and a TDES for the last block. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 11 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 5.1.3 Critical Security Parameters: 5.1.3.1 Cryptographic Keys : The Cyberflex Access e-gate 32K cryptographic module includes the following keys: 1. Initialization Key, K init used only for the first Card Manager key-set loading, 2. Crypto Officer (Card Manager) Security Domain keys, 3. TDES Session keys (keys derived from Crypto Officer keys set(s)) And in addition, applets Security Domain keys sets. 4. TDES Applet Provider Security Domain keys used for OP authentication 5. TDES Applet Session keys (keys derived from Applet Provider Security Domain keys set(s)) 6. "OP DAP" TDES key. This key is used as an EDC that enables the applet provider to check, independently of the Issuer, that his applet has been correctly loaded. The keys 1 & 2 are put in Crypto -officer Security Domain key sets, using the Put Key command. The keys 3 & 5 are temporary keys stored in RAM. The keys 6 are put in the Applet Provider Security Domains, using the Put Key command. A Security Domain key set is structured in such a way as to contain three types of TDES keys: · Kenc, auth used to derive session keys for Crypto Officer authentication and encrypted mode of the secure channel, · K mac, used to derive session key for MAC mode of the secure channel, · Kkek used to encrypt keys, to be imported into the platform. For DAP, only one key is necessary, it is the first key of the key set. Security Domains allow a number of distinct identities to be established on the Cyberflex Access e-gate 32K module. These are identities that control access to the various applets stored on the Cyberflex Access e-gate 32K module. A Security Domain represents the identity of an application (applet) operator. 5.1.3.2 Other CSPs The Cyberflex Access e-gate 32K cryptographic module includes another type of CSP: · A Global Personal Identification Number (PIN), The Global PIN is 7-12 character (numeric) strings that may be used (through a dedicated OP API) to authenticate the future Cardholder to the Cyberflex Access e-gate 32K module. That is, by successfully entering a PIN sequence, a cardholder can prove knowledge of a shared secret (the PIN) and thereby authenticate to the Cyberflex Access e-gate 32K module. 6. S ECURITY RULES 6.1.1 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. 6.1.1.1 User Identification and Authentication · User/Applet Provider Authentication : The User/Applet Provider must prove the possession of the Applet Key Set composed of 3 TDES keys. Two keys are used to encrypt, authenticate and check the integrity of the command data. A 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. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 12 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 6.1.1.2 Cryptographic Officer Identification &Authentication · Crypto Officer Authentication : The Cryptographic Officer must prove the possession of the Card Manager Key Set composed of 3 TDES keys. Two keys are used to encrypt, authenticate and check the integrity of the command data. A 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). 6.1.2 Applet Loading Security Rules Only applets validated to FIPS 140-1 or 140-2 shall be loaded onto the Cyberflex Access e-gate 32K cryptographic module. Applets can only be loaded through a secure channel; i.e. they pass from the off module to the on-module environment in an encrypted and MACed form. 6.1.2.1 "OP DAP" In the Cyberflex Access e-gate 32K module, the applet is always loaded by the Issuer (Cryptographic Officer). The optional mechanism designated as "DAP" in OP 2.0.1' enables the applet provider to check, independently of the Issuer (Cryptographic Officer), that his applet has been correctly loaded. This check is done by an EDC on the applet. This EDC is an algorithm using DES for the first n-1 blocks and a TDES for the last block. All the DES and TDES operations use an applet provider`s TDES key, loaded in his Security Domain. This process is described in detail in the CO / User Guidance document. 6.1.3 Access Control Security Rules · Keys must be loaded through a secure channel. Consequently, keys are always loaded in the encrypted form. · Global PIN is set through a secure channel. Consequently, Global PIN is always input in the encrypted form. 6.1.4 Physical Security Rules The physical security of the Cyberflex Access e -gate 32K cryptographic module is designed to meet FIPS 140-2 level 3 requirements. A hard opaque epoxy is used to encapsulate the module to meet level 3 requirements. Once it is manufactured, the Cyberflex Access e -gate 32K module belongs to the Cryptographic Officer until it is ultimately issued to the end user. 6.1.5 Key Management Security Policy 6.1.5.1 Cryptographic key generation -TDES Session key derivation for Secure Channel Opening, conforming to Open Platform Card Specification v2.0.1' using FIPS140-2 approved ANSI X9.31 PRNG. - RSA key pair generation using FIPS140-2 approved ANSI X9.31 PRNG. 6.1.5.2 Cryptographic key entry/output Keys shall always be input in encrypted format, using the Put Key command within a secure channel. During this process, the keys are double encrypted (using the Session Key and the K kek Key). 6.1.5.3 Cryptographic key storage The Keys are structured to contai the following parameters: n · Key id, which is the Id of the key, · Algo Id, which determines which algorithm to be used, June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 13 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards · Integrity Mechanisms. 6.1.5.4 Cryptographic key destruction The Cyberflex Access e-gate 32K module destroys cryptographic keys by reloading another key-set for Crypto Officer keys, Security Domains Applets Keys, or closing of secure channel for session keys. Key Management Details can be found in a specific proprietary document. The keys loaded for "OP DAP" cannot be updated. To delete an "OP DAP" key, the Security Domain containing the key must be deleted. This operation deletes all the keys contained in the Security Domain. 6.1.6 Mitigation of attacks Security Policy Cyberflex Access e-gate 32K cryptographic module has been designed to mitigate the following attacks: · Simple Power Analysis, · Differential Power Analysis. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 14 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 7. S ECURITY P OLICY CHECK LIST TABLES 7.1 ROLES & R EQUIRED AUTHENTICATION Role Type of authentication Authentication data Crypto Officer TDES authentication TDES keys (Crypto Officer Security Domain) User/Applet Provider TDES authentication TDES keys (Applet Provider Security Domain) 7.2 STRENGTH OF AUTHENTICATION M ECHANISMS Authentication Mechanism Strength of Mechanism TDES authentication High 7.3 SERVICES AUTHORIZED FOR R OLES Role Authorized Services Crypto Officer CO Administrative Services as listed in Section 5.1.2.1. CO & User Services as listed in Section 5.1.2.2. User/Applet Provider CO & User Services as listed in Section 5.1.2.2. APIs as listed in Section 5.1.2.4. June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 15 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 7.4 ACCESS R IGHTS WITHIN S ERVICES CSP Service Role Types of Access TDES CO Master Keys PUT KEY command Crypto Officer Write TDES CO Master Keys INITIALIZE UPDATE & Crypto Officer Read & Execute EXTERNAL AUTH TDES CO Master Key: K KEK PUT KEY command Crypto Officer Read & Execute (encryption of the loaded Key) TDES CO Session Keys INITIALIZE UPDATE & Crypto Officer Create EXTERNAL AUTH TDES CO Session Key: K enc Message encryption Crypto Officer Read & Execute TDES CO Session Key: K mac Message integrity Crypto Officer Read & Execute TDES User Master Keys PUT KEY command User Write TDES User Master Keys INITIALIZE UPDATE & User Read & Execute EXTERNAL AUTH TDES User Master Key: K KEK Key encryption (when loading User Read & Execute a key) TDES User Session Keys INITIALIZE UPDATE & User Create EXTERNAL AUTH TDES User Session Key: K enc Message encryption User Read & Execute TDES User Session Key: K mac Message integrity User Read & Execute "OP DAP" TDES Key PUT KEY command User Write "OP DAP" TDES Key EDC by Applet Provider User Read & Execute Security Domain Global PIN PIN CHANGE command Crypto Officer Write 7.5 M ITIGATION 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 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 16 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision). Smart Cards 8. R EFERENCES [JVM] Java Card TM 2.1 Virtual Machine Specification v1.1 - june 1999, Sun Microsystems [JCAPI] Java Card TM 2.1 Application Programming Interface, Sun Microsystems [JCDG] Java Card TMapplet developer's guide [JCRE] Java Card TM 2.1 Runtime Environment (JCRE) Specification, Sun Microsystems [VOPS] Open Platform Card Specification, v2.0.1' - april 2000 [VOPI] Visa Open Platform Card Implementation Specification - march 1999, Visa International [X9.31] American Bankers Association, Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (rDSA), ANSI X9.31-1998, Washington, D.C., 1998. [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, [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. [DSS] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2, January 27, 2000. 9. A CRONYMS Acronyms Definitions AP Application Provider ATR Answer To Reset API Application Programming Interface CBC Cipher Block Chaining DES Data Encryption Standard ECB Electronic Code Book EEPROM Electrically Erasable and Programmable Read Only Memory JCRE Java Card TM Runtime Environment MAC Message Authentication Code OP Open Platform PIN Personal Identification Number RAM Random Access Memory ROM Read only Memory USB Universal Serial Bus June 2003 Cyberflex Access 32K e-gate Security Policy Revision: 1.4 Page : 17 / 17 Copyright Schlumberger Systèmes SA ­ 2003. This document may be reproduced only in its original entirety (without revision).