CryptoServer CS Security Policy Document Version 2.0.6 Document No. 2004-0007 Utimaco Safeware AG 27th June 2007 Copyright Utimaco Safeware AG 2007. May be reproduced only in its original entirety [without revision]. Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 TABLE OF CONTENTS 1. MODULE OVERVIEW .........................................................................................................................................3 2. SECURITY LEVEL................................................................................................................................................6 3. MODES OF OPERATION.....................................................................................................................................7 APPROVED MODE OF OPERATION ...............................................................................................................................7 NON-FIPS MODE OF OPERATION ................................................................................................................................8 SECURE MESSAGING FOR SECURE COMMUNICATION WITH THE CRYPTOSERVER .......................................................9 4. PORTS AND INTERFACES ...............................................................................................................................10 5. IDENTIFICATION AND AUTHENTICATION POLICY...............................................................................11 ASSUMPTION OF ROLES ............................................................................................................................................11 6. ACCESS CONTROL POLICY............................................................................................................................13 ROLES AND SERVICES ..............................................................................................................................................13 UNAUTHENTICATED SERVICES ................................................................................................................................15 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS)......................................................................................15 DEFINITION OF PUBLIC KEYS:..................................................................................................................................16 DEFINITION OF CSPS MODES OF ACCESS ................................................................................................................16 7. OPERATIONAL ENVIRONMENT....................................................................................................................20 8. SECURITY RULES ..............................................................................................................................................21 9. PHYSICAL SECURITY POLICY ......................................................................................................................23 PHYSICAL SECURITY MECHANISMS .........................................................................................................................23 10. MITIGATION OF OTHER ATTACKS POLICY...........................................................................................24 11. REFERENCES ....................................................................................................................................................25 12. DEFINITIONS AND ACRONYMS...................................................................................................................25 Page 2 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 1. Module Overview The CryptoServer CS is an encapsulated, protected security module which is realized as multi- chip embedded cryptographic module in the sense of FIPS 140-2 (Hardware P/N CryptoServer CS, Version 2.0.2.0; Firmware Version 2.0.0.1). Its realization meets FIPS 140-2 overall level 3 requirements, with level 4 requirements in section "Physical Security". The primary purpose for this module is to provide secure cryptographic services like encryption or decryption (for various cryptographic algorithms like Triple-DES, RSA and AES), hashing, signing and verification of data (RSA, ECDSA), random number generation, on-board secure key generation, key storage and further key management functions in a tamper-protected environment. In FIPS mode, the module offers a general purpose API with FIPS Approved algorithms for the above mentioned cryptographic services, as well as an administrative interface. A Secure Messaging concept protects the communication to and from the module by message encryption and MAC authentication. If not in FIPS mode, the CryptoServer's flexible software architecture allows its usage in nearly all proprietary environments where cryptographic services and highest security are required: for instance in archiving systems and payment systems, it can serve as a signature server, time stamp and as a generator for PINs, cryptographic keys or random numbers. The CryptoServer offers hardware based as well as deterministic random number generation in FIPS mode and non-FIPS mode. In FIPS mode, the hardware based RNG is only used to seed the Approved DRNG. The CryptoServer CS is encased in a hard opaque commercial grade metal case which contains a tamper response envelope around the module: All hardware components of the cryptographic module (including the Central Processing Unit, all memory chips, Real Time Clock and hardware noise generator for random number generation) are located on a printed circuit board and encapsulated by metal shells, a special tamper detection envelope (which is a special foil bearing a flexible printed circuit with a serpentine geometric pattern of conductors) and potting material. The cryptographic boundary of the module is defined by the outer metal case on five of the six sides of the module and the epoxy surface on the sixth side of the module. Figure 1 below shows views of the cryptographic boundary from the top and the side. Page 3 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 plastic fortifier isolation copper foil contacts A1 plastic fortified Flex A topside CryptoServer A 30 B1 plastic fortified Flex B topside B 30 C1 plastic fortified Flex C topside utimaco C 30 safeware Figure 1 ­ CryptoServer CS (the dashed line indicates the cryptographic boundary) To enable communication with a host, this encapsulated cryptographic module is mounted on a carrier card which supports a PCI interface and two serial interfaces (RS232). The connection between the cryptographic module and the carrier card is done by the three ribbon cables shown in figure 1. The following picture shows the cryptographic module CryptoServer CS mounted on a PCI carrier card: Page 4 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Figure 2 ­ CryptoServer CS mounted on the PCI carrier card Page 5 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 2. Security Level The cryptographic module meets the overall requirements applicable to Level 3 security of FIPS 140-2. In the section "Physical Security" level 4 (+ EFP) is reached. Table 1 - Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 3 Module Ports and Interfaces 3 Roles, Services and Authentication 3 Finite State Model 3 Physical Security 4 + EFP Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of Other Attacks 3 Page 6 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 3. Modes of Operation Approved mode of operation The cryptographic module supports the following FIPS Approved algorithms: · RSA with variable key sizes (minimum 1024 bit key length) for o Sign/Verify o Verify (SMOS RSA) (see RSA Validation Certificates No. 196 and 204) · ECDSA with ECDSA keys on dedicated elliptic curves (curves P-192, P-224, P-256, P- 384, P-521 as specified and recommended in FIPS 186-2) for o Sign/Verify (see ECDSA Validation Certificate No. 44) · Triple-DES (TDES) for o Data Encryption/Decryption o Key Wrapping/Unwrapping (i. e. Key Encryption/Decryption) (see Triple DES Modes of Operation Validation Certificate No. 492) · AES for o Data Encryption/Decryption o Key Wrapping/Unwrapping (i. e. Key Encryption/Decryption) (see Advanced Encryption Standard Validation Certificate No. 479) · SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 for hashing (see Secure Hash Standard Validation Certificates No. 547) · TDES-MAC (vendor affirmed, based on FIPS Approved Triple-DES core algorithm, see Validation Certificate No. 492) The Single-DES algorithm is not supported in FIPS-mode. Furthermore the CryptoServer CS in FIPS mode offers key generation services: · RSA key pair generation · ECDSA key pair generation · Triple-DES key generation · AES key generation For random value generation and generation of all cryptographic keys, the CryptoServer CS relies on an implemented deterministic random number generator (DRNG) that is compliant with Page 7 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 FIPS 186-2, Appendix 3.1, with 24 bytes seed and based on SHA-1 as transition function (see [FIPS186-2]). This DRNG is FIPS Approved, see Random Number Generator Validation Certificate No. 259. The CryptoServer CS also implements and uses the following non-FIPS Approved algorithms: · NDRNG ­ used to generate the seed value and seed key for the Approved DRNG; based on a hardware noise source · RSA Key Wrapping/Unwrapping (key establishment methodology provides 80 bits of encryption strength) · Diffie-Hellman for key agreement (key establishment methodology provides 80 bits of encryption strength) ­ commercially available protocol [PKCS #3] for key establishment; see below for the Secure Messaging concept The CryptoServer CS may be configured for FIPS mode by loading all FIPS certified firmware into a module that is in delivery state and performing a power cycle as described in the CryptoServer's Administrator's Guide for CryptoServer CS in FIPS Mode [CSAdmGuide]. If this has been performed successfully, the module's internally stored FIPS mode indicator flag is set. The user can observe if the cryptographic module is running in FIPS vs. non-FIPS mode via execution of the "GetState" service where the FIPS mode indicator will be displayed. Non-FIPS mode of operation Any firmware that has not been certified for FIPS140-2, loaded into the module while the module is in delivery state, will not set the module's internally stored FIPS mode indicator flag. This flag will indicate to the user of the module that the module is running in non-FIPS mode when the user requests the "GetState" service. For example, non-FIPS firmware can be loaded into the module while the module is in delivery state that could provide one or more of the following non-FIPS algorithms: · IDEA · Safer · RSA for public key cipher of bulk data · MD5, MDC-2 or RIPEMD-160 for hashing · Single DES · Retail-TDES MAC · AES MAC (Cert. #479; non-compliant) · Key generation with True Random Number Generator (based on a physical noise source) · PIN generation / PIN verification (e. g. VISA/MasterCard) Page 8 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Secure Messaging for secure communication with the CryptoServer The CryptoServer CS implements a Secure Messaging concept which enables any operator to secure his communication with the CryptoServer over the PCI interface, even from a remote host. With Secure Messaging, commands sent to the CryptoServer and answer data received from the CryptoServer may be encrypted and integrity-protected/signed with a TDES MAC. In FIPS mode, Secure Messaging has to be performed for every sensitive command, i. e. for every command that is only available for authenticated users. To do Secure Messaging, the operator has to open a (Secure Messaging) Session. For a Session, a 16 bytes TDES session key will be negotiated between CryptoServer and host via Diffie- Hellmann algorithm as key establishment technique (according to [PKCS#3]; for generation of its random value needed for the key agreement, the CryptoServer will use its deterministic random number generator). The CryptoServer can simultaneously manage multiple Sessions (with multiple operators): Each Session manages its own session key, which is identified by a session ID. All commands using the same session ID and the same session key are said to belong to one session. In this way a secure channel will be established between the CryptoServer and the host application. Page 9 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 4. Ports and Interfaces The CryptoServer CS is connected to the outside world using three ribbon cables: Flex A, B and C, each consisting of 30 signal lines (see figure 1). The device provides three physical ports on these ribbon cables: 1) Power input (including operational power input and backup power input). 2) An external bus which is used for data input, data output, control input and status output. 3) An External Erase input, which can be used to zeroize all secret information inside the module. To enable communication with a host, the encapsulated cryptographic module is mounted on a carrier card which supports a PCI interface and two serial interfaces (RS232). The carrier card maps the external bus of the module to the PCI and serial interfaces. All requests for services are sent over the PCI interface. The first serial interface is used for status output only. The second serial interface is not used in FIPS mode. The input and output of all Critical Security Parameters (CSPs) will be done over the services that are offered over the PCI interface. In particular, CSPs will be entered and output only in an encrypted form: All command and answer data (except for status requests) to and from the CryptoServer will be encrypted and MAC protected by the Secure Messaging layer, see previous subsection Secure Messaging for secure communication with the CryptoServer. Additionally, all secret or private keys can only be imported or exported in a wrapped form, i. e. encrypted (via the services Import Key and Export Key, see section 6 Roles and Services). Page 10 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 5. Identification and Authentication Policy Assumption of roles The CryptoServer cryptographic module supports two distinct operator roles: Cryptographic User and Administrator role (called User Role respectively Crypto Officer Role in [FIPS140-2]). Additionally a Public User is allowed to perform any non-sensitive services like requesting status information without prior authentication. The cryptographic module enforces the separation of roles using identity-based operator authentication. Two authentication methods are supported by the module: Password authentication and RSA signature authentication. For password based authentication the operator must enter a user name and his password to log in. The user name is an alphanumeric string of up to 8 characters. The password is a binary string of 16 bytes (which may contain an alphanumeric string), a minimum of 6 bytes must be different from zero or blank. To prevent the password from being eavesdropped the SHA-1 hash value calculated over the password and a random challenge will be sent to the CryptoServer. For RSA signature based authentication the user sends a RSA signed command containing his user name to authenticate to the cryptographic module. Upon correct authentication, the role is selected based on the user name of the operator. During authentication a session key is negotiated which is used to secure subsequent service requests of the operator (see the description of the Secure Messaging concept, page 9). Since the session key (and session ID) is stored in volatile memory, all information about the authentication and session will be lost if the module is powered down. The CryptoServer CS supports multiple simultaneous operators, each using his own session key for message authentication of the service requests. This ensures the separation of the authorized roles and services performed by each operator. At the end of a session, the operator may log-out, or, after 15 minutes of inactivity, the session key will be invalidated inside the cryptographic module. Table 2 ­ Roles and Required Identification and Authentication Role Type of Authentication Authentication Data Cryptographic User Identity-based operator User Name and Password (called User in authentication or [FIPS140-2]) User Name and RSA Signature Administrator Identity-based operator User Name and Password (called Crypto Officer authentication or in [FIPS140-2]) User Name and RSA Signature Page 11 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Table 3 ­ Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism Username and Password The probability that a random attempt will succeed or (6 characters password chosen out of 94 a false acceptance will occur is 1/689,869,781,056 printable ASCII characters) which is less than 1/1,000,000. Due to a correctional delay of 40 milliseconds for every non-successful authentication (s. t. there is a maximal limit of 1500 non-successful authentications per minute), the probability of successfully authenticating to the module within one minute is (less than) 1/459,913,187 which is less than 1/100,000. RSA Signature The probability that a random attempt will succeed or (1024 bit key) a false acceptance will occur is approximately 2-80 (according to SP800-57-Part1 page 67) which is less than 1/1,000,000. Due to a correctional delay of 40 milliseconds for every non-successful authentication (s. t. there is a maximal limit of 1500 non-successful authentications per minute), the probability of successfully authenticating to the module within one minute is less than 2-70 which is less than 1/100,000. Page 12 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 6. Access Control Policy Roles and Services Table 4 ­ Services Authorized for Roles Role Authorized Services Cryptographic · Change Cryptographic User's Password or Key: This service will User: change the password or RSA public key which is used for the Cryptographic User's authentication. This role provides all cryptographic · Get Session Key: This service generates a new session key for secure services, i. e. communication to the module. services for management and · Crypt Data: This service encrypts or decrypts data using a TDES or usage of private, AES key in CBC or ECB mode. public and secret keys, hashing · Calculate MAC: This service calculates a TDES-MAC over given data. services and random number · Sign Data: This service generates a RSA or ECDSA signature. generation. · Verify Signature: This service verifies a RSA or ECDSA signature. · Calculate Hash: This service calculates a SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash value over given data. · Generate Random Number: This service generates a random number using the DRNG. · Generate TDES key: This service generates a TDES key (16 or 24 bytes) using the DRNG. In FIPS mode this service will not generate Single-DES keys. · Generate AES key: This service generates an AES key using the DRNG. · Generate RSA key: This service generates a RSA key using the DRNG. · Generate ECDSA key: This service generates an ECDSA key using the DRNG. · Export Key: This service outputs a wrapped key (i. e. encrypted with a Key Encryption Key). · Import Key: This service imports a wrapped key (i. e. encrypted with a Page 13 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Role Authorized Services Key Encryption Key) into the cryptographic module. · Export Public Key: This service outputs the public part of a RSA or ECDSA key. · Import Clear Key: This service imports the public part of a RSA or ECDSA key. · List Keys: This service outputs a list of all keys stored inside the cryptographic module. · Delete Key: This service deletes a key from the module. Administrator: · Add Operator: This service will add a Cryptographic User or Administrator to the cryptographic module. This role provides all services · Delete Operator: This service will delete a Cryptographic User or necessary for Administrator from the cryptographic module. firmware and user management. · Load File: This service loads files. If a file with the same file name is currently loaded, the current file will be replaced. This command is usually used to load and replace firmware modules. If the file is a firmware module, the old file will only be replaced if the version of the new module is higher or equal to the old module version and if the RSA signature over the firmware module is verified. (Note: Loading non-FIPS-validated software or firmware onto the cryptographic module will cause the module to no longer be FIPS-validated.) · Delete File: This service is used to delete files. · Set Clock: This service allows the Administrator to set the internal clock on the module. · Change Administrator's Password or Key: This service will change the password or RSA public key which is used for the Administrator's authentication. · Get Session Key: This service generates a new session key for secure communication to the module. Page 14 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Unauthenticated Services Furthermore, the CryptoServer CS supports the following unauthenticated services, i. e. services which are available to any operator: · Show Status (or Get State): This service provides the current status of the cryptographic module, including the FIPS mode indicator. · Get Time: Read the current time out of the internal Real Time Clock of the module. · List Files: Retrieve a list of all files stored in the flash file system of the module. · List Active Modules: List all currently active firmware modules. · List Operators: Read a list of all Cryptographic Users and Administrators. · End Session: Terminate a (Secure Messaging) session by invalidating the respective session key. · Get Log File: Read a log file. · Get Memory Info: Return statistical information regarding the file system usage. · Echo: Communication test (echo input data). · Get Challenge: Generate and output a challenge (8 bytes random value) for usage of the challenge/response mechanism with the next authenticated command. · Initiate Self Tests: At any time the execution of the self-tests required by FIPS 140-2 can be forced by performing a reset or power-cycle of the module. During self-test execution no further command processing is possible. · Zeroize: Zeroize the cryptographic module including all firmware, data and critical security parameters. In particular all CSPs that are not wrapped by the Master Key will be zeroized. This service will be executed if an external erase input is given. If the module is in a FIPS error state, only unauthenticated services are available that only output status information and do not perform any cryptographic functions. Definition of Critical Security Parameters (CSPs) The following are CSPs contained in the module: · Master Key (TDES 24 bytes) KCS2 · Session Key (volatile storage only) · Seed for Deterministic Random Number Generator (DRNG) (volatile storage only) Page 15 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 The following CSPs are stored within the cryptographic module encrypted with the Master Key KCS2 (TDES): (Note: These non-volatile CSPs are not subject to the zeroization requirement since they are stored encrypted using TDES.) · RSA Private Sign Key · RSA Private Key Decryption Key · ECDSA Private Sign Key · TDES Key Encryption Key · AES Key Encryption Key · TDES Data En-/Decryption or MAC Key · AES Data En-/Decryption Key · Administrator Password (for authentication) · Cryptographic User Password (for authentication) Definition of Public Keys: The following are the public keys contained in the module: · Production Key (RSA 1024 bit) KProd_pub · Module Signature Key (RSA 1024 bit) KMdl-Sig_pub · Initialization Key(RSA 1024 bit) KInit_pub · RSA Public Verify Key · RSA Public Key Encryption Key · ECDSA Public Verify Key · Administrator's Public RSA Authentication Key · Cryptographic User's Public RSA Authentication Key Definition of CSPs Modes of Access Table 5 defines the relationship between the different module services and access to CSPs. The types of access (e. g. Use/Write/Update) are given in the right column. The following types of access are possible: · Write: The CSP is created (newly written). · Update: The value of the CSP will be replaced by a new value. Page 16 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 · Use: The value of the CSP is used for some cryptographic calculation. · Export (wrapped): The CSP will be wrapped by some key encryption key and exported from the cryptographic module. · Export: The key will be exported from the cryptographic module (only possible for public RSA or ECDSA keys). · Delete: The CSP will be invalidated. The two left columns indicate for which Role the respective service is available. Table 5 ­ CSP Access Rights within Roles & Services Role Service Cryptographic Keys and CSPs Access Type of Access Operation Admini- Crypto- strator graphic User X Crypt Data TDES or AES Data En-/Decryption Key Use X Calculate TDES MAC Key Use MAC X Sign Data RSA Private Sign Key or ECDSA Private Use Sign Key X Verify RSA Public Verify Key or ECDSA Public Use Signature Verify Key X Calculate --- --- Hash X Generate Seed for DRNG Use and Update Random Number X Generate 1) Seed for DRNG Use and Update TDES Key 2) TDES Data En-/Decryption, MAC or Write Key Encryption Key X Generate 1) Seed for DRNG Use and Update AES Key 2) AES Data En-/Decryption or Key Write Encryption Key X Generate 1) Seed for DRNG Use and Update RSA Key 2) RSA Signing or Key Decryption Key Write Page 17 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Role Service Cryptographic Keys and CSPs Access Type of Access Operation Admini- Crypto- strator graphic User X Generate 1) Seed for DRNG Use and Update ECDSA Key 2) ECDSA Signing Key Write X Export Key 1) TDES Data En-/Decryption or MAC Export from Key or module TDES Key Encryption Key or (wrapped, i. e. AES Data En-/Decryption Key or encrypted with a AES Key Encryption Key or Key Encryption RSA Private Signing Key or Key) RSA Public Verifying Key or RSA Public Key Encryption Key or RSA Private Key Decryption Key or ECDSA Private Signing Key or ECDSA Public Verifying Key 2) TDES Key Encryption Key or Use AES Key Encryption Key or RSA Public Key Encryption Key 3) Seed for DRNG Use and Update (only if wrapping is performed by RSA key) X Import Key 1) TDES Data En-/Decryption or MAC Write or Update Key or TDES Key Encryption Key AES Data En-/Decryption Key or AES Key Encryption Key or RSA Private Signing Key or RSA Public Verifying Key or RSA Public Key Encryption Key or RSA Private Key Decryption Key or ECDSA Private Signing Key or ECDSA Public Verifying Key 2) TDES Key Encryption Key or Use AES Key Encryption Key or RSA Public Key Encryption Key X Export RSA Public Key Encryption Key or Export Public Key RSA Public Verifying Key or ECDSA Public Verifying Key Page 18 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Role Service Cryptographic Keys and CSPs Access Type of Access Operation Admini- Crypto- strator graphic User X Import Clear RSA Public Key Encryption Key or Write or Update Key RSA Public Verifying Key or ECDSA Public Verifying Key X List Keys --- --- X Delete Key TDES Data En-/Decryption or MAC Key Delete or TDES Key Encryption Key or AES Data En-/Decryption Key or AES Key Encryption Key or RSA Private Signing Key or RSA Public Verifying Key or RSA Public Key Encryption Key or RSA Private Key Decryption Key or ECDSA Private Signing Key or ECDSA Public Verifying Key X Load File 1) Public Module Signature Key Use 2) Public Initialization Key Use X Delete File --- --- X Set Clock --- --- X Add Public RSA Authentication Key or Write Operator Password of operator X Delete Public RSA Authentication Key or Delete Operator Password of operator X X Change Public RSA Authentication Key or Update Operator's Password of operator Key or Password X X Get Session 1) Seed for DRNG Use and Update Key 2) Session Key Write 3) Public Initialization Key or Use Public RSA Authentication Key or Password of operator X X End Session Session Key Delete Page 19 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 Role Service Cryptographic Keys and CSPs Access Type of Access Operation Admini- Crypto- strator graphic User X any command Public RSA Authentication Key or Use authentication Password of Cryptographic User performed by Cryptographic User X any command Public Initialization Key or Use authentication Public RSA Authentication Key or performed by Password of Administrator Administrator X X any command Session Key Use using Secure Messaging 7. Operational Environment The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because the Cryptographic Module does not contain a modifiable operational environment. Page 20 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 8. Security Rules The cryptographic module's design corresponds to the cryptographic module's security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-2 Level 3 module. 1. The cryptographic module provides two distinct operator roles. These are the Cryptographic User role and the Administrator role. 2. The cryptographic module provides identity-based authentication. 3. No access to any cryptographic services is permitted until the operator has been authenticated by the module into the "Cryptographic User" or "Administrator" role. 4. The cryptographic module performs the following tests: a) Power up Self-Tests: i) Cryptographic Algorithm Tests: (1) TDES Known Answer Test (2) TDES-MAC Known Answer Test (3) AES Known Answer Test (4) SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 Known Answer Tests (5) RSA Known Answer Tests (sign/verify and encrypt/decrypt) (6) RSA Verify Known Answer Test (SMOS RSA) (7) ECDSA Pair-wise Consistency Test (sign/verify) (8) DRNG Known Answer Test ii) Software/Firmware Integrity Test (CRC (32 bit) for boot loader program code, RSA signature verification for firmware) iii) Critical Functions Tests (1) SDRAM Test (2) Master Key Integrity Test (3) Temperature Test b) Conditional Self-Tests: i) Continuous Random Number Generator (RNG) Test ­ performed on NDRNG and DRNG ii) RSA Key Pair-wise Consistency Test (sign/verify and encrypt/decrypt) for RSA key generation iii) ECDSA Key Pair-wise Consistency Test (sign/verify) for ECDSA key generation Page 21 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 iv) Software/Firmware Load Test (via RSA signature verification) 5. At any time the operator is capable of commanding the module to perform the power-up self- test. 6. Prior to each use, the DRNG and the hardware based NDRNG is tested using the conditional test specified in FIPS 140-2 §4.9.2. 7. Data output is inhibited during key generation, self-tests, zeroization, and error states. 8. The module does not allow the export of a RSA private key or a ECDSA private key wrapped with a RSA public key encryption key. 9. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 10. The module supports concurrent operators. This section documents the security rules imposed by the vendor: 1. The module zeroizes all plaintext CSPs within maximal 4 milliseconds after any attack or alarm (see section 9 below). 2. If the cryptographic module remains inactive in any valid role for a maximum period of 15 minutes, the module automatically logs off the operator. 3. The module offers the possibility to protect command and answer data on their way to and from the module via a Secure Messaging mechanism. This mechanism encrypts and integrity protects the data with TDES encrypting algorithm respectively MAC. In FIPS mode, the usage of secure messaging is mandatory. 4. The module implements a Challenge-Response mechanism to prevent the replay of older authenticated messages. 5. The module prohibits the export of plaintext cryptographic keys or other CSPs. 6. The module supports an attribute "Exportable" for every stored private or secret cryptographic key. The module allows the (wrapped) export of a key only if this attribute is set. 7. The module supports an attribute "Key Encryption Key" for every stored cryptographic key. If this attribute is set, the module allows the key to be used to wrap other keys (for export) but not to be used for data encryption or signing. If this attribute is not set, the module allows the key to be used for data encryption or signing, but not to be used to wrap other keys (for export). In FIPS mode, RSA keys cannot be used for bulk data encryption. 8. The module restricts the usage of ECDSA keys exclusively to signature generation/verification. Encryption/decryption with ECDSA keys will not be offered; in particular the attribute "Key Encryption Key" cannot be set for ECDSA keys. Page 22 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 9. Physical Security Policy Physical Security Mechanisms The CryptoServer CS multi-chip embedded cryptographic module is encapsulated with a hard, opaque, tamper-evident potting coating. This coating consists of an inner metal housing surrounded by a special tamper-detection foil and potting material, and all this encased in an outer metal housing. The CryptoServer module with its tamper-evident enclosure (the coating) implements the following physical security mechanisms: · Active tamper response and zeroization circuitry. · Module is entirely encapsulated by a security foil (tamper sensor) that detects all physical and chemical attacks. · Temperature sensors that activate a tamper response if the module is outside the defined temperature range of ­14°C to 66°C. · Voltage sensors that monitor the power supply of the module and activate a tamper response if the power input is outside the defined range. · Tamper response and zeroization circuitry is active while module is in standby mode (powered down). · Zeroization is done within less than 4 milliseconds after tamper detection. · Module stops operation if it is outside the operational temperature range of 5°C to 58°C. · Regularly invert all bits of the clear text CSPs to avoid "burn in" of information into SRAM cells. To ensure physical security of the cryptographic module, no extra action has to be performed. For a module in FIPS mode, the above listed physical security mechanisms function autonomously and under any circumstances. To ensure functionality, the module must be periodically inspected for tamper evidence. Page 23 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 10. Mitigation of Other Attacks Policy The module has been designed to mitigate Simple and Differential Power Analysis (SPA/DPA) and Timing Analysis. Table 6 ­ Mitigation of Other Attacks Other Attacks Mitigation Mechanism SPA/DPA SPA/DPA attacks are mitigated by use of hardware components assembled into a special design of the power management circuit, such that it is not feasible to monitor current consumption to determine the value of an algorithm's key. Current consumption of the module does not depend on the value of cryptographic keys. Timing Analysis It is not feasible to determine the value of an algorithm's keys by measuring the execution time of a cryptographic operation. TDES and AES operations are executed in fixed time. The input data to a private RSA operation is randomized by use of a blinding technique, so that the input parameters of the RSA algorithm are not known by the operator. For that reason it is not possible to calculate the bits of a private key by the amount of time required by the private RSA operation. The CryptoServer's ability to mitigate effectively SPA/DPA attacks was successfully tested by the evaluator T-Systems in the context of the CryptoServer's ZKA (Zentraler Kreditausschuss) validation process. Page 24 Utimaco Safeware AG CryptoServer CS Security Policy Version 2.0.6 11. References Title/Company [CSAdmGuide] CryptoServer CS - Administrator's Guide for CryptoServer in FIPS-Mode, Doc. no 2004-0002 / Utimaco Safeware AG [FIPS140-2] FIPS PUB 140-2, Security Requirements for Cryptographic Modules / National Institute of Standards and Technology (NIST), May 2001 [FIPS186-2] FIPS PUB 186-2: Digital Signature Standard (DSS) / National Institute of Standards and Technology (NIST), January 2000 [PKCS#1] PKCS#1: RSA Encryption Standard v2.1, 14th June 2002 / RSA Laboratories, http://www.rsasecurity.com/rsalabs/pkcs [PKCS#3] PKCS#3: Diffie-Hellman Key Agreement Standard v1.4, 1st November 1993 / RSA Laboratories, http://www.rsasecurity.com/rsalabs/pkcs 12. Definitions and Acronyms CSP Critical Security Parameter DES Data Encryption Standard DRNG Deterministic Random Number Generator NDRNG Non-deterministic Random Number Generator RNG Random Number Generator SPA/DPA Simple Power Analysis / Differential Power Analysis TDES Triple-DES (with key size 16 or 24 bytes) ZKA Zentraler Kreditausschuss, the umbrella association of the German credit services sector Page 25