Cryptoflex 8K Security Policy – Version 1.2
-1-
Security Policy
For
SchlumbergerSema Cryptoflex 8K
Smart Card
Public Version 1.2
Cryptoflex 8K Security Policy – Version 1.2
-2-
Table of Contents
1 SCOPE OF DOCUMENT ....................................................................................................................................3
2 INTRODUCTION..................................................................................................................................................3
3 SECURITY LEVEL...............................................................................................................................................3
3.1 CRYPTOGRAPHIC MODULE SPECIFICATION......................................................................................................3
3.2 MODULE 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 MODES OF ACCESS.......................................................................................................12
6.2 SERVICE TO SRDI ACCESS OPERATION RELATIONSHIP...............................................................................14
Cryptoflex 8K Security Policy – Version 1.2
-3-
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.
Cryptoflex 8K Security Policy – Version 1.2
-4-
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)
Cryptoflex 8K Security Policy – Version 1.2
-5-
C3 CLK (Clock)
C4 RFU
C5 GND (Ground)
C6 Not used
C7 I/O bi-directional line
C8 RFU
ICC supply current:
Ÿ MAX: 50 mA at 5MHz
Ÿ 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
Cryptoflex 8K Security Policy – Version 1.2
-6-
- 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..
Cryptoflex 8K Security Policy – Version 1.2
-7-
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.
Cryptoflex 8K Security Policy – Version 1.2
-8-
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 (known 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
Cryptoflex 8K Security Policy – Version 1.2
-9-
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
Method vs Services
SERVICE
DESCRIPTION
Any
Role
Cryptographic
Officer
Cardholder
PIN
CHANGE_CHV Change PIN on card X
DECREASE Decrease a value in a
file record.
X
GET AC KEYS Retrieve a specific
access control key
from card
X
GET RESPONSE Retrieve additional
information from a
command
X
INCREASE Increase a value in a
file record.
X
INVALIDATE Set state of a file to
INVALID; blocks
access to file for most
commands
X
Cryptoflex 8K Security Policy – Version 1.2
-10-
LOGOUT AC Cancel current access
control status
X
REHABILITATE Reset status of
INVALID file so it can
be accessed.
X
UNBLOCK CHV Reset the invalid
attempts counter for a
PIN file
X
VERIFY CHV Prove knowledge of a
specific PIN
X
VERIFY KEY Prove knowledge of a
specific KEY
X
EXTERNAL
AUTHENTICATE
Authenticate the
identity of the off-card
host computer
X
GET
CHALLENGE
Get a nonce to use for
subsequent identity
authentication
command
X
INTERNAL
AUTHENTICATE
Authenticate the card
to the off-card host
X
RSA SIGNATURE NON-FIPS MODE X
SHA-1
INTERMEDIATE
Perform hash for a
portion of a byte string
X
SHA-1 LAST Perform final hash
operation for a byte
string
X
CREATE FILE Create a new file on
the card
X
CREATE
RECORD
Create a new record
within a file on the
card
X
DELETE FILE Delete a file from the
card
X
DIR NEXT Get a directory of the
files on a card
X
READ BINARY Read a byte string from
a file on the card
X
READ RECORD Read a record from a
file on the card
X
SEEK Look for specific
contents in a file
X
SELECT Point at a new file X
UPDATE BINARY Write a byte string into
a file
X
UPDATE
RECORD
Write a record into a
file
X
MASK TRACK X
UPDATE KEY
ENCIPHERED
Load an encrypted key
into the card
X
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
Cryptoflex 8K Security Policy – Version 1.2
-11-
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)
Cryptoflex 8K Security Policy – Version 1.2
-12-
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
Cryptoflex 8K Security Policy – Version 1.2
-13-
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.
Cryptoflex 8K Security Policy – Version 1.2
-14-
6.2 Service to SRDI Access Operation Relationship
The following
services are
provided to the
User and the
Cryptographic
Officer roles.
These various
services make use
of the indicated
access
mechanisms on
the
SRDIs..Service
CREATE
FILE
SELECT
FILE
UPDATE
KEY
ENC
VERIFY
KEY
VERIFY
CHV
CHANGE
CHV
UNBLOCK
CHV
GET
CHALLENGE
INTERNAL
AUTH
EXTERNAL
AUTH
INVALIDATE
REHABILITATE
User
Role
Cryptographic
Officer
Role
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
Officer
X X X X
Authenticate Card X X X
Authenticate
Terminal
X X X X
The keys through which 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.