Cryptoflex 8K Security Policy ­ Version 1.2 Security Policy For SchlumbergerSema Cryptoflex 8K Smart Card Public Version 1.2 -1- Cryptoflex 8K Security Policy ­ Version 1.2 Table of Contents 1 SCOPE OF DOCUMENT ....................................................................................................................................3 2 INTRODUCTION..................................................................................................................................................3 3 SECURITY LEVEL...............................................................................................................................................3 3.1 CRYPTOGRAPHIC M ODULE SPECIFICATION......................................................................................................3 3.2 M ODULE INTERFACES..........................................................................................................................................4 3.2.1 Physical Interface description................................................................................................................4 3.2.2 Electrical specifications...........................................................................................................................4 3.2.3 Logical INterface Description................................................................................................................5 3.2.4 Roles & Services.......................................................................................................................................5 3.2.5 Finite State Machine................................................................................................................................6 3.2.6 Physical Security.......................................................................................................................................6 3.2.7 Software Security ......................................................................................................................................7 3.2.8 Operating System Security......................................................................................................................7 3.2.9 Key Management ......................................................................................................................................7 3.2.10 Cryptographic Algorithms.......................................................................................................................8 3.2.11 EMI/EMC ...................................................................................................................................................8 3.2.12 Self-Tests ....................................................................................................................................................8 4 ROLES AND SERVICES ....................................................................................................................................8 4.1 SERVICES ...............................................................................................................................................................9 5 SECURITY RULES ............................................................................................................................................ 10 6 DEFINITION OF SECURITY RELEVANT DATA ITEMS ................................................................. 11 6.1 DEFINITION OF SRDI M ODES OF A CCESS.......................................................................................................12 6.2 SERVICE TO SRDI A CCESS OPERATION RELATIONSHIP ...............................................................................14 -2- Cryptoflex 8K Security Policy ­ Version 1.2 1 Scope of Document This document defines the Security Policy for the Cryptoflex 8K smart card. Included is a description of the basic security requirements for the Cryptoflex card and a qualitative description of how each security requirement is achieved. 2 Introduction The Cryptoflex 8K smart card is an ISO/IEC 7816 compliant smart card which supports a command set aimed at allowing the mutual authentication of identities with "card acceptance devices" (and PCs or other terminals that they might be connected to) using strong cryptography. Specifically, the TDES algorithm is used within authentication commands used between the card 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 card. It should be particularly noted that the Cryptoflex 8K card is not used as an encryption engine by the external (to the card) systems which may utilize the card. 3 Security Level The Cryptoflex 8K smart card (cryptographic module) meets the overall requirements applicable to Level 2 security of FIPS 140-1. The individual security requirements specified for FIPS 140-1 meet the level specifications indicated in the following table. Security Requirements Section Level Cryptographic Module 2 Module Interfaces 2 Roles and Services 2 Finite State Machine 2 Physical Security 2 Software Security 2 Operating System Security N/A Key Management 2 Cryptographic Algorithms 2 EMI/EMC 2 Self Test 2 3.1 Cryptographic Module Specification Cryptoflex is a single chip implementation of a cryptographic module. -3- Cryptoflex 8K Security Policy ­ Version 1.2 Cryptoflex is an ID-1 class card which adheres to the various ISO/IEC specifications for ICC based identification cards. The "cryptographic boundary" for the Cryptoflex card vis- à-vis the FIPS140-1 certification is the "module edge". The module is comprised of the chip (ICC), the contact faceplate, and the micro-electronic connectors between the chip and the contact pad. The module is constructed so as to provide the tamper resistance and the tamper evidence required in the FIPS 140-1 level 2 certification is to be met. The Cryptoflex chip is comprised of the following elements: STMicroelectronics ST19CF68 8 bit microcontroller Systems software and cryptographic software installed in ROM as part of the chip manufacturing process. This hard mask is designated: M64LC21_ST_68_01_02 This hard mask identification number can be retrieved from the card using a standard command. Power-up self-test software installed in EEPROM as part of the card pre-personalization operation. Key and PIN storage in EEPROM as part of the card personalization operation. 3.2 Module Interfaces The electrical and physical interfaces to the Cryptoflex chip, as a cryptographic module, are comprised of the 8-electrical contacts from the face of the module to the chip. These contacts conform to the following specifications: 3.2.1 PHYSICAL INTERFACE DESCRIPTION The Cryptoflex module supports eight contacts which lead to pins on the chip. Only five of these are used. The position of these contacts comply with ISO/IEC 7816-2. Minimum contact surface area: 1.7mm * 2.0 mm Contact dimensions are those of a standard credit card compliant with ISO/IEC 7816-1: Dimension Value Length 85.5mm Width 54.0mm Thickness 0.80mm 3.2.2 ELECTRICAL SPECIFICATIONS Specific electrical functions of the contacts: Contact Function C1 Vcc supply voltage 3V or 5V +/- 0.5V C2 RST (Reset) -4- Cryptoflex 8K Security Policy ­ Version 1.2 C3 CLK (Clock) C4 RFU C5 GND (Ground) C6 Not used C7 I/O bi-directional line C8 RFU ICC supply current: Y MAX: 50 mA at 5MHz Y TYP: 5 mA at 5MHz Module structure and ICC electrical contacts defined by ISO/IEC 7816-1&2. Electrical signaling between the "card acceptance device" (CAD) and the module defined by ISO/IEC 7816-3. Module security and key access command set defined by ISO/IEC 7816-4. CAD to module communication protocols defined by ISO/IEC 7816-3 & 4. 3.2.3 LOGICAL INTERFACE DESCRIPTION Once electrical (physical) contact and data link layer contact is established between the module and the CAD, the module functions as a "slave" processor to implement and respond to the CAD's "master" commands. The module has a well defined command set to which it responds. Access to specific commands is limited by the establishment of Access Conditions based on knowledge of keys stored in the module. 3.2.4 ROLES & SERVICES Two roles control the Cryptoflex module throughout its lifetime: the Cryptographic Officer and the User. The general capabilities of these roles are as follows: Cryptographic officer: - is established in control of the card during the manufacturing process - controls definition of module file structure - defines default PIN - defines PIN-reset PIN - controls key loading - controls card issuance to User User: - is established in control of the card by the Cryptographic Officer -5- Cryptoflex 8K Security Policy ­ Version 1.2 - controls PINs - uses the keys (to authenticate identity) on the card The Cryptographic Officer is identified through possession of the Master Transport Key (MTK) for the Cryptoflex module. This key is required to enable creation of the Master File of the file system. The access conditions limiting the file creation activity are established as part of the manufacturing process, as is the definition of the MTK. The User is identified through possession of the Application Access Key (AAK). This key is a PIN code which is established by the Cryptographic Officer during the personalization of the module prior to issuing the card to the User's possession. With knowledge of the AAK, a new AAK can be defined by the User. 3.2.5 FINITE STATE MACHINE The Cryptoflex module is compliant with the ISO/IEC 7816-3,4 specifications. This means that the card communicates via Application Protocol Data Unit packets transferred from the CAD to the module, followed by a response APDU from the module back to the CAD. Within this protocol, the module functions as a pure, finite state machine. The Finite State Model for the Cryptoflex card is published as a separate document. 3.2.6 PHYSICAL SECURITY The physical security of the Cryptoflex module is designed to meet FIPS 140-1 level 2 requirements. From the time of its manufacture, the module is in possession of the Cryptographic Officer until it is ultimately issued to the User. From that point, the module is in the physical possession of the User. To attack the cryptographic information contained in the module, that is to attempt to compromise this information, requires physical access to the module. To eavesdrop on normal activities of the module, while it is still in possession of either the Cryptographic Officer or of the User, will be demonstrated to be difficult or impossible due to the protocols and security mechanisms protecting access to the module's information and services. To eavesdrop on the module through extraordinary means requires physical possession of the module. In this event, the absence of the module will be detected by either the Cryptographic Officer or the User and the capabilities of the module within a larger systems context can be disabled. If the module is attacked through physical means, the attack will be evident due to the disturbance of the packaging of the module. The ICC is embedded within an epoxy coating which is extremely difficult to penetrate without leaving evidence of the attack. Further, the packaging itself is resistant to penetration.. -6- Cryptoflex 8K Security Policy ­ Version 1.2 3.2.7 SOFTWARE SECURITY The system software for the Cryptoflex module is a hard mask; that is, the system software is stored in ROM during the manufacturing process for the ICC which is inserted into the card. Once manufactured, it is impossible to alter the ROM code. Software security of the Cryptoflex module is strictly controlled by: Master Transport Key protection for all EEPROM storage, including creation of the Master File for the on-card file system. PIN access control for all files (keys) Protocol control, with PIN access control, for command access. 3.2.8 OPERATING SYSTEM SECURITY This section is not applicable to this certification due to the fact that no applets or source code may be loaded onto the module after completion of the manufacturing process. 3.2.9 KEY MANAGEMENT Secret keys to be used with the TDES algorithm are generated off-card as part of the card personalization operation. These keys are encrypted and then loaded onto the card during personalization. TDES, ECB mode is used to encrypt/decrypt the secret keys. Off-card key generation Encrypted key loading onto card PIN access control to key files. All of the key information is stored in special files (i.e. files with well defined names) associated with the on-card file system. These keys are then used to establish identities which are used to fulfill access conditions placed on various commands which the card can execute. Key management is largely rooted in the establishment of the root of the file system during card manufacture. A Master Transport Key is installed as an elementary file within the Master File (root) file of the card's file system. All commands are then given an access condition (by the CREATE FILE command used to create the MTK file that requires knowledge of the MTK before any command on the card can be executed. The MTK is known only to the Cryptographic Officer who controls the card after it leaves the manufacturing facility. All other files, including key files, which are stored on the card require an action by the Cryptographic Officer who may, in the course of establishing a more complex file structure on the card, allocate privileges to the User role. Thus, all key management derives from knowledge of the MTK. All keys can be zeroized. -7- Cryptoflex 8K Security Policy ­ Version 1.2 3.2.10 CRYPTOGRAPHIC ALGORITHMS The purpose of the Cryptoflex card is to provide a portable token for use in storing a variety of keys and for providing a secure computing platform to enhance cryptographic services. The keys represent the identity of the roles involved in controlling the card: first, the identity of the Cryptographic Officer and then of the User. The TDES algorithm, a FIPS-140.1 certified algorithm, is used in the Cryptoflex card to provide identity authentication services. None of the encryption or decryption algorithms are used for encryption or decryption information other than to establish identities through the encryption or decryption of challenge (essentially random numbers) values. Random number generation is done on the card only for the purpose of generating random challenges (nonces) to be used in the authentication of identity. 3.2.11 EMI/EMC The Cryptoflex 8K module has been tested to meet the EMI/EMC requirements specified by FCC Part 15, Subpart J, Class A. 3.2.12 SELF-TESTS The Cryptoflex module performs the required set of self-tests at power-up time. When the Cryptoflex card is inserted into a CAD, once power is applied to the card (contact) interface, a "Reset" signal is sent from the CAD to the module. A series of GO/NO-GO tests are then performed by the card before it responds (as specified by ISO/IEC 7816) with an Answer To Reset (ATR) packet of information. These tests include: EEPROM soft- mask CRC test RAM cleared at Reset Algorithm (kno wn answer) tests for: · TDES Encryption and Decryption · SHA-1 Hashing If any of these tests fail, the card will respond with an ATR and a status indication of self- test error. Then, the card will go mute. No data of any type is transmitted from the card to the CAD while the self-tests are being performed. 4 Roles and Services The Cryptoflex 8K module defines two distinct roles that are supported by the on-card cryptographic system: the Cryptographic Officer and the Cardholder (User). The -8- Cryptoflex 8K Security Policy ­ Version 1.2 Cryptographic Officer is established in control of the card during the manufacturing process and this role is authenticated to the card by knowledge of a key set, generally referred to as the Master Transport Key (MTK). The Cardholder (User) role is authenticated by knowledge of a PIN. Cryptoflex cards that are to be deployed are prepared in a batch operation called pre- personalization. This operation specifically includes installing the basic file structure on the card and establishing the access conditions for this file structure. Establishing the file structure first requires creating a Master File on the card. System software establishes the access condition that knowledge of the MTK is required to create the Master File; hence, this is an operation which can only be performed by the Cryptographic Officer. The basic file system typically has specific files allocated for holding keys. These files are created with associated files which contain PIN codes. During pre-personalization, a generic PIN code is created on the card; e.g. the character string `00000000'. At this time, there are no actual keys present on the card and card security is still maintained by physical possession of the card by the Cryptographic Officer. During the personalization operation in which each card is personalized for an individual cardholder, keys are generated in the off-card environment and loaded onto the card (into thepre-existing key files) under control of the Cryptographic Officer. When the Cryptographic Officer installs the file structure on the card and establishes the generic PIN, a "PIN reset PIN" may also be established. Knowledge of this PIN is retained by the Cryptographic Officer. If a mute card is presented to the Cryptographic Officer, it may be "rehabilitated" through knowledge of the "PIN reset PIN". The Cryptoflex module insures the authentication of off-card entities and provides them with cryptographic services according to their role. 4.1 Services Role/Authentication SERVICE Any Cryptographic Cardholder Method vs Services DESCRIPTION Role Officer PIN CHANGE_CHV Change PIN on card X DECREASE Decrease a value in a X file record. GET AC KEYS Retrieve a specific X access control key from card GET RESPONSE Retrieve additional X information from a command INCREASE Increase a value in a X file record. INVALIDATE Set state of a file to X INVALID; blocks access to file for most commands -9- Cryptoflex 8K Security Policy ­ Version 1.2 LOGOUT AC Cancel current access X control status REHABILITATE Reset status of X INVALID file so it can be accessed. UNBLOCK CHV Reset the invalid X attempts counter for a PIN file VERIFY CHV Prove knowledge of a X specific PIN VERIFY KEY Prove knowledge of a X specific KEY EXTERNAL Authenticate the X identity of the off-card AUTHENTICATE host computer GET Get a nonce to use for X subsequent identity CHALLENGE authentication command INTERNAL Authenticate the card X to the off-card host AUTHENTICATE RSA SIGNATURE NON-FIPS MODE X SHA-1 Perform hash for a X portion of a byte string INTERMEDIATE SHA-1 LAST Perform final hash X operation for a byte string CREATE FILE Create a new file on X the card CREATE Create a new record X within a file on the RECORD card DELETE FILE Delete a file from the X card DIR NEXT Get a directory of the X files on a card READ BINARY Read a byte string from X a file on the card READ RECORD Read a record from a X file on the card SEEK Look for specific X contents in a file SELECT Point at a new file X UPDATE BINARY Write a byte string into X a file UPDATE Write a record into a X file RECORD MASK TRACK X UPDATE KEY Load an encrypted key X into the card ENCIPHERED 5 Security Rules The Cryptoflex module implements the security commands which are generically defined in the ISO/IEC 7816-4 specification and which are defined in detail in the Cryptoflex -10- Cryptoflex 8K Security Policy ­ Version 1.2 Technical Specification. The gist of this security architecture is defined in terms of a file structure implemented on the module. The file structure is rooted in a Master File which is a "dedicated" or "directory" file; that is, it may contain other dedicated files or elementary files (leaf nodes in the file structure tree). Every dedicated file can have a set of specially named elementary files associated with it (contained by it). These special files can contain a variety of keys. Special commands are used to store values in these key files and other special commands are used to allow an off-card entity to confirm, to the card OS, that it (the off-card entity) knows the key values stored on the card. By doing this, the off-card entity can establish an identity known to the card. This identity (i.e. knowledge of the keys) can then be impressed on other commands as a necessary condition for the command to be executed. The security infrastructure is established at the time that the Master Files is first created on the card. This is done during the manufacturing process while the card still resides in a secure environment. When the Master File is created, the very same command (which creates the Master File) also creates a key file within the Master File and stores the Master Transport Key value in this file. Knowledge of this MTK is then established as a required condition on all commands which can further access or manipulate the file structure. Thus, once the MTK is established, knowledge of it establishes the identity of the Cryptographic Officer; and, only the Cryptographic Officer can access the initial files on the card or can create an additional file structure on the card. To establish the card file structure, knowledge of the MTK is required. To allow the Cryptoflex card to perform an Internal Authentication command, during which the card demonstrates its knowledge of a shared secret (key) with the off- card host, the Cardholder may need to authorize the operation by entering a PIN. The key values are entered into the key files using the UPDATE KEY ENC command. With this command, the key is encrypted as it crosses the wire from the terminal to the card. Access Conditions are established with respect to a file or a section of a file structure. The value of the Access Conditions is stored in RAM. Thus, if power is removed from the card, the RAM is erased and all existing Access Conditions are lost. This prevents the establishment of Access Conditions from surviving across a power-down of the card. 6 Definition of Security Relevant Data Items The Cryptoflex smart card includes two classes of Security Relevant Data Items (SRDIs): Personal Identification Numbers (PINs) Authentication Keys (TDES) -11- Cryptoflex 8K Security Policy ­ Version 1.2 Each of these SRDIs has a specific purpose within the smart card and within the environment of a smart card inserted into a system encompassing a card acceptance device (aka smart card reader or terminal): PINs are comprised of a string of 8 or less numbers which can be attached to files or to file structures on a smart card. By proving knowledge of a particular PIN through a VERIFY CHV command, the CHV access condition can be satisfied. Once this condition is satisfied, then commands which have had their access limited by a CHV access condition can be invoked. CHV stands for cardholder verification, and the CHV access condition is usually used to limit access to specific commands only to the bearer of the card. To preserve the overall security of a system, the PIN should be entered through a keypad which is connected to the card in a secure manner; i.e. such that the PIN characters can not be intercepted. Authentication Keys are keys for encryption algorithms which can be related to files or file structures. Through this relationship, access to the files or file structures (actually to the commands through which the files or file structures are accessed and manipulated) can be limited by requiring knowledge of the keys. This limit is established by placing an access condition on a command which says in effect, if you want to execute this command relative to this file, then you must have already proven that you know this key which applies to this file. For the Cryptoflex 8K card, the FIPS approved mode of operations allows only the TDES algorithm to be used in authenticating knowledge of an Authentication Key; use of the RSA algorithm for this purpose places the card in a non- FIPS approved mode. Authentication Keys and PINs are attached to files or file structures by placing them in specially named files within directories. If one then wants to access a file, it is possible to search up the file tree for the first occurrence of a directory file which contains either (or both) of these special files which contain Authentication Keys of PINs. There are seven of these special files which may be found within a directory (i.e. a Dedicated File): Type Data Field File ID File Level Key Files CHV1 0000 (Relevant) CHV2 0100 (Relevant) EF Key INT 0001 (Relevant) EF Key EXT 0011 (Relevant) ATR File EF ATR 2F01 Root 6.1 Definition of SRDI Modes of Access The PIN and Authentication Key values are stored in Elementary Files on the Cryptoflex smart card. The values are introduced into the files and manipulated once there by using a set of file access commands: SELECT UPDATE BIN -12- Cryptoflex 8K Security Policy ­ Version 1.2 UPDATE REC UPDATE KEY ENC READ BIN READ REC SEEK INCREASE DECREASE DIR NEXT GET RESPONSE The PIN and Authentication Key files are initially created with a CREATE FILE command. With this command, the access conditions on the key files can be specified by the same command that creates the file (i.e. the CREATE FILE command). Separate access conditions can be placed on all of the commands noted above. For the PIN and Authentication Key files, typically the only commands which will be allowed are SELECT and UPDATE KEY ENC. The PIN and Authentication Key SRDIs are actually used by the following commands: VERIFY KEY VERIFY CHV CHANGE CHV UNBLOCK CHV GET CHALLENGE INTERNAL AUTH EXTERNAL AUTH INVALIDATE REHABILITATE Of these, the two cryptographic services are provided by the INTERNAL AUTH and the EXTERNAL AUTH commands. Only the TDES algorithm can be used within these commands to authenticate identities; that is, only TDES can be used in the FIPS approved mode for the Cryptoflex 8K card. -13- Cryptoflex 8K Security Policy ­ Version 1.2 6.2 Service to SRDI Access Operation Relationship The following services are provided to the User and the Cryptographic Officer Role Cryptographic Officer roles. UPDATE KEY ENC EXTERNAL AUTH GET CHALLENGE INTERNAL AUTH These various REHABILITATE UNBLOCK CHV services make use CHANGE CHV CREATE FILE INVALIDATE VERIFY CHV SELECT FILE VERIFY KEY of the indicated access User Role mechanisms on the SRDIs..Service Load MTK X X X Load User Key X X X Load User PIN X X Modify User PIN X X X X X X Modify User Key X X X X X Verify User X X X X Verify Crypto X X X X Officer Authenticate Card X X X Authenticate X X X X Terminal The keys through whic h identities are established are accessed through the indicated commands in the above table. The CHANGE CHV command is used to establish the value of the PIN used to authenticate the cardholder to the card. The UPDATE KEY ENC command is used to establish the value of the keys accessed by the INTERNAL AUTH and the EXTERNAL AUTH commands. The UPDATE KEY ENC command is used to "zeroize" the key file. -14-