Cryptosec 2048 Realia Technologies S.L. (Realsec) http://www.realsec.com/ FIPS 140-2 Level 3 Validation Non-Proprietary Security Policy © Copyright 2004 Realia Technologies S.L. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. INDEX 1 INTRODUCTION ............................................................................................................ 4 1.1 Purpose .................................................................................................................. 4 1.2 References ............................................................................................................. 4 1.3 Document Organization........................................................................................... 4 2 CRYPTOSEC 2048 ........................................................................................................ 5 2.1 Overview................................................................................................................. 5 2.2 Module Interfaces ................................................................................................... 6 2.3 Roles and Services ................................................................................................. 7 2.3.1 Crypto-Officer Role ............................................................................................. 7 2.3.2 User Role............................................................................................................ 8 2.3.3 Unauthenticated Services.................................................................................. 10 2.4 Finite State Machine Model ................................................................................... 10 2.5 Physical Security................................................................................................... 10 2.6 Operational Environment....................................................................................... 11 2.7 Key Management .................................................................................................. 11 2.7.1 Key Storage & Protection .................................................................................. 11 2.7.2 Key Generation ................................................................................................. 12 2.7.3 Key Import and Export....................................................................................... 12 2.7.4 Key Zeroization ................................................................................................. 13 2.7.5 Random Number Generator .............................................................................. 13 2.8 EMI/EMC .............................................................................................................. 13 2.9 SELF TESTING .................................................................................................... 13 2.10 DESIGN ASSURANCE ......................................................................................... 14 2.11 MITIGATION OF OTHER ATTACKS ..................................................................... 14 3 SECURE OPERATION OF THE CRYPTOSEC 2048.................................................... 15 3.1 Secure administration ........................................................................................... 15 3.1.1 Initialization ....................................................................................................... 15 3.1.2 Management ..................................................................................................... 15 3.1.3 Termination....................................................................................................... 16 3.2 Secure operation................................................................................................... 16 © 2004 Realia Technologies S.L. Page 2 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 4 FIPS 140-2 MODE OF OPERATION ............................................................................ 17 4.1 Security Functions ................................................................................................ 17 4.1.1 Approved Security Functions............................................................................. 17 4.1.2 Non-Approved Security Functions ..................................................................... 17 5 GLOSSARY OF TERMS............................................................................................... 19 © 2004 Realia Technologies S.L. Page 3 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 1 INTRODUCTION 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Cryptosec 2048 cryptographic accelerator from Realia Technologies S.L. This security policy describes how the Cryptosec 2048 meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 3 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 -- Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the NIST website at http://csrc.nist.gov/cryptval/. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: · The Realia Technologies S.L. website, http://www.realsec.com/, contains information on the full line of products from Realia Technologies S.L. · The NIST Validated Modules website, http://csrc.ncsl.nist.gov/cryptval/, contains contact information for answers to technical or sales-related questions for the module. · Technical or sales-related questions can also be sent to info@realsec.com. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: · Realia Technologies S.L. Vendor Evidence document. · Finite State Machine. · Module Source Code Listing. · Hardware Schematics. · Crypto Officer/User Guides. · Other supporting documentation as additional references. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Realia Technologies S.L. and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Realia Technologies S.L. © 2004 Realia Technologies S.L. Page 4 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2 CRYPTOSEC 2048 2.1 Overview The Cryptosec 2048 is a high-end PCI cryptographic accelerator card that provides cryptographic services and secure storage of cryptographic keys. The module is built to perform cryptographic processing and features a tamper-protective case to physically protect sensitive information contained within the card. The Cryptosec 2048 supports the following algorithms approved for use in a FIPS mode of operation: · RSA key generation, signature generation/verification, and key wrapping. · DES (only to be used in legacy systems) and TDES (2-key and 3-key) generation, encryption and decryption. In many cases below, the Security Policy refers to "DES" as the cryptographic services provided in FIPS PUB 46-3, that includes the DEA and TDEA, commonly referred to as DES and TDES. Unless explicitly stated, DES should imply both algorithms defined FIPS PUB 46-3. · SHA-1 hashing. The Cryptosec 2048 also supports the following algorithms for use in a non-FIPS mode of operation: · RSA encryption/decryption. · MD5 hashing. · RIPEMD hashing. The Cryptosec 2048 product design, development, test and production has satisfied the requirements to ensure a secure product. Security has been the focus of the development team, and the Cryptosec 2048 product has been designed from the ground up to incorporate security in all design and development steps. © 2004 Realia Technologies S.L. Page 5 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The Cryptosec 2048, Hardware Model 1.0, firmware version 01.04.0010 is tested to meet the FIPS 140-2 security requirements for the levels shown in the following table. The overall module is tested FIPS 140-2 Security Level 3. FIPS 140-2 Security Requirements Section Level 1. Cryptographic Module Specification 3 2. Module Ports and Interfaces 3 3. Roles, Services, and Authentication 3 4. Finite State Model 3 5. Physical Security 3 6. Operational Environment N/A 7. Cryptographic Key Management 3 8. EMI / EMC 3 9. Self Tests 3 10. Design Assurance 3 11. Mitigation of Other Attacks N/A Cryptosec 2048 is comprised of the module itself and the supplied software drivers outside module boundary to access the functionality of the product. A special serial cable is also included. 2.2 Module Interfaces The Cryptosec 2048 is classified as a multi-chip embedded module for FIPS 140-2 purposes. The FIPS 140-2 cryptographic boundary is defined by the perimeter of the protection covers. The battery system (battery clips, auxiliary battery connector), DB-15 power supply pin, power supply relay, the DB-15 connector and the buzzer are excluded from the security requirements of FIPS 140-2. The module is accessible only through well-defined interfaces. The physical interfaces of the Cryptosec 2048 are: PCI port, buzzer (unused, disabled by firmware), RS-232 port, I2C port (unused, disabled by firmware), DB-15 power supply pin and battery system. All of these physical interfaces are separated into logical interfaces defined by FIPS 140-2, as described in the following table: Module Physical Interface FIPS 140-2 Logical Interface PCI, RS-232 Data Input Interface PCI, RS-232 Data Output Interface PCI Control Input Interface PCI Status Output Interface PCI, battery system and DB-15 power supply pin Power Interface All sensitive information that is entered to the module in plaintext form (like authentication data, cryptographic key components and cryptographic key component check values) is entered through the RS-232 port. All sensitive information that leaves the module in plaintext form (like cryptographic key components and cryptographic key component check values) is output through the RS-232 port. A trusted VT-100 or VT-100-like system must be connected to that port. © 2004 Realia Technologies S.L. Page 6 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2.3 Roles and Services The Cryptosec 2048 performs identity-based authentication. Operators are identified by a username and authenticated by a password. The role of an operator is assigned when the operator is created. The strength of the authentication mechanism with 255 possible characters with repetition and 8 a minimum of a 8-character password is 1 in 17,878,103,347,812,890,625 (255 ). The module delays a replay for five seconds when an incorrect password is entered. After three incorrect entries the session is closed and must be reestablished. The status of the module can be viewed from two registers on the PCI bus. When using the supplied software drivers to access the module, the status is returned as the function call return value. The roles supported by the module are two: Superuser (or Crypto-Officer) and User. The Superuser is a normal User with administrative privileges. There are unauthenticated services that do not provide any security functionality, those services are available to all roles. 2.3.1 Crypto-Officer Role The following table summarizes the services available only to superusers: Type of Service Description Input Output CSP Access to CSP Initializes a new Create User User's ID, User's password Status User's password Write User Erases an existing Delete User Session ID and User's ID Status User Set time and Adjusts the Session ID and time and Status date module's RTC date info Session ID, number of Loads the work Work key Write Load work custodians, work key key. (Not used in Status key components, users' ID and FIPS mode) Users' password Read password Computes the Retrieve work key's CV Work key work key's Session ID Status and CV Read (Not used in FIPS CV mode) Checks work key Work key existence (Not Status and key Session ID Work key Read exists used in FIPS existence mode) Loads the Session ID, number of Back-up key Write Load back- module's back-up custodians, users' ID and Status up key Users' password Read key password Session ID, number of Back-up key Read Get back-up Retrieves the Status and back-up custodians, users' ID and key back-up key key components Users' password Read password Retrieve Computes the back-up Session ID Status and CV Back-up key Read back-up key's CV key's CV Every CSP apart Create back- Creat es a Status and Back-up Session ID form back-up key Read up module's back-up data and work key Every CSP apart Restore Restores a Session ID and Back-up Status form back-up key Write back-up module's back-up data and work key Reset Clears the Session ID Status Every CSP Lost firmware program memory Loads a license Session ID and License Load license Status file (Not used in data © 2004 Realia Technologies S.L. Page 7 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Type of Service Description Input Output CSP Access to CSP FIPS mode) Generates a Generate license information Status and license license info Session ID file (Not used in data file FIPS mode) 2.3.2 User Role The following table summarizes the services available to any User: Type of Service Description Input Output CSP Access to CSP Forces the execution Power-up Test Session ID Status of the power-up tests Logs an operator and Status and Session Create session Session ID==NULL User's password Read creates a session ID ID Close session Closes a session Session ID Status Session ID, public RSA key Generates a RSA key exponent and Status and key ID Private key Write generation pair modulus length RSA key Session ID, public Generates a RSA key generation and exponent and Status and key data pair and exports it no store modulus length RSA key Session ID, public Generates a RSA key generation, no exponent, modulus Status and ciphered pair and exports it in store and length and the key data VIS format cipher exporting key ID Performs a RSA Session ID, key ID, Status and RSA private Private key Read private encryption data encrypted data Performs a RSA Session ID, key ID, Status and RSA public public encryption data encrypted data Retrieves a public Get public key Session ID and key ID Status and key data key Retrieves a private Private key Read Get private key Session ID and key ID Status and key data key Transport key Read Private key Write Write private Session ID and key Loads a private key Status and key Id key data Transport key Read User's DES key Read Deletes a User's RSA Erase RSA key Session ID and key ID Status Private key Lost key Returns the User's Status and key ID List RSA keys Session ID Private key Read RSA key IDs list Get users Returns the users' ID Session ID Status and User info Sets a new User's Session ID and new Set password Status User's password Write password password Returns a 24-bit Random24 Session ID Status and data random number Get date and Reads the module's Status and RTC Session ID time RTC data Terminates a hash Status and hash Hash finish session and returns Session ID value the hash value © 2004 Realia Technologies S.L. Page 8 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Type of Service Description Input Output CSP Access to CSP Deletes a User's DES Delete DES key Session ID and key ID Status DES key Lost key Returns User's DES Status and key ID Get DES key ID key Ids and their Session ID DES key Read list and lengths length Session ID, key ID Get DES key Returns a User `s Status and key and number of DES key Read parts DES key in n parts components custodians Get DES key Returns a User's Session ID, DES key DES key Read Status and key data cipher DES key ciphered ID Transport key Read Get CV DES Computes a User's Session ID, DES key Status and CV DES key Read key DES key's CV ID Session ID, number of DES key Write Load DES key Loads a DES key in n custodians and users' Status and key ID parts parts Users' password Read ID and password Get CV Computes the Session ID Status and key's CV Transport key Read transport key transport key's CV Returns a User `s Get transport Session ID and Status and key transport key in n Transport key Read key number of custodians components parts Session ID, number of Load transport Loads the User's custodians and key Status Transport key Write key transport key components Performs the VISA Session ID, Derivation Derivation key Read Derivate DES key diversification key, Export key and Status key Export key Read algorithm derivation data Configures the Session ID and config BCHU config symmetric ciphering Status data and hashing unit Controls traffic to and Datab from the symmetric Session ID Status unit Generate DES Session ID and key Generates a DES key Status DES key Write key length Returns a User's Exported key Session ID, ciphering Read Get DES key DES key ciphered Status and ciphered key ID and exported ciphered with another User's key key ID Ciphering key Read DES key Returns the chain Status and chain IV values values of the active Session ID values DES operation Session ID, number of Similar to Load DES DES keys Write Load DES key custodians, keys' key parts, but with n Status and key IDs list parts lengths and users' ID keys Users' passwords Read and password Write private Imports a private key Session ID and key Transport key Read Status and key ID key CB2000® in CB2000® format info Private key Write Makes use of a card Use license emission item (Not Session ID Status used in FIPS mode) Reads the number of Read partial Status and number licenses ready to be Session ID counter of licenses used Read total Reads the number of Status and number Session ID counter licenses used of licenses Load DES key Loads a ciphered DES key Write Session ID Status and key ID cipher user's DES key Transport key Read Load DES key Loads a User's DES Session ID, ciphering Ciphering DES Status and key ID Read ciphered key ciphered with key ID and key data key © 2004 Realia Technologies S.L. Page 9 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Type of Service Description Input Output CSP Access to CSP another User's DES DES key Write key Recovers the symmetric ciphering Status and config Get OMR Session ID and hashing unit data configuration Recovers a User's Get DES key Session ID, key ID Status and export DES key ciphered DES key Read public and public key data with a public key Loads a DES key DES key Write Load DES key Session ID and public ciphered with a public Status and key ID private key Private key Read key Switches between Change mode FIPS and non-FIPS Session ID Status mode Session ID, key ID, Status, signature Performs a RSA hash data, hash RSA sign block length and Private key Read signature (partially) algorithm and signature block signature format Status, signature block length, Performs a RSA Session ID, public key signature block in RSA verify signature verification length, public key data clear, hash (partially) and signature block algorithm and signature format 2.3.3 Unauthenticated Services The following table shows the unauthenticated services: Type of Service Description Input Output CSP Access to CSP Status and the firmware version, in the form MM.mm.bbbb, Returns the firmware Session ID if any, else, where MM is the major Firmware Version version Session ID==NULL version number, mm is the minor version number and bbbb is the build number Get HSM Returns a unique 64-bit Session ID if any, else, Status and the Identification identification code Session ID==NULL identification code 2.4 Finite State Machine Model The Cryptosec 2048 is designed around a FSM which is detailed in a proprietary document. Parties interested in reviewing this document should contact Realia Technologies S.L. via the sources listed in the Introduction section of this document. 2.5 Physical Security The module provides tamper evidence and tamper response mechanisms. The metallic casing and the epoxy resin conform the tamper evidence mechanism. The tamper response is based on a zeroization circuitry. The metallic non-removable covers are made of 0.9mm steel and they cover both sides of the PCB. The space between them is completely filled with epoxy resin, making the module more protected. © 2004 Realia Technologies S.L. Page 10 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. A wire runs inside both sides of the module. In case the wire is cut or broken in any way, the main processor tamper response mechanism is launched. The internal 128 KB memory is actively erased. This memory contains the main processor firmware and the Master Firmware key. 2.6 Operational Environment This section does not apply. The Cryptosec 2048 does not provide a modifiable operational environment. 2.7 Key Management 2.7.1 Key Storage & Protection Secret Keys: The module can store up to 15000 general use DES and TDES (2-key and 3-key) keys. They are kept ciphered in the SRAM of the module. They are owned by their respective users. A User can have several keys. Secret keys can be exported and imported in several ways. They are also part of the back up. There are also some special secret keys, with specific purposes: · Backup key: it is a 3-key TDES. The back up file is encrypted/decrypted with this key. The Superuser can load and save this key. This is done by means of split knowledge key entry. It is stored in the internal processor memory. · Transport key: it is a 3-key TDES, used to import and export keys, although other keys can be used with this purpose. Each User has a transport key, and is able to administrate it on its own. They are stored in the SRAM memory, protected by the Master Firmware key. · Work key: it is a DES key, a TDES 2-key or a TDES 3-key. It is not used in FIPS mode. It is stored in the internal processor memory. · Master Firmware key: it is a TDES 3-key. It is used to cipher the SRAM protected contents. It is generated automatically by the module, and it is never exported or revealed in any way. It is stored in the internal processor memory. Private keys: The module can store up to 1000 RSA keys. Their modulus may vary in length from 512 to 2048 bits. Take into account that in FIPS mode, the minimum accepted modulus length is 1024 bits. They are kept, into a PKCS#1 structure, ciphered by the Master Firmware key in the SRAM of the module. They are owned by users. A User can have several keys. Private keys can be exported and imported in several ways. They are also part of the back up. The firmware protects the secret, private and public keys against unauthorized disclosure, unauthorized modification and unauthorized substitution requiring owner's authentication. No one, not even the owner, can modify a key, but only the owner can delete its keys. The administrators can erase users and other administrators, this implies the deletion of all the keys owned by that user. © 2004 Realia Technologies S.L. Page 11 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2.7.2 Key Generation The key generation algorithms differ from DES keys to RSA key pairs. In the DES key case, the process starts generating a random number of the specified length. This value is compared with weak keys and semi-weak keys, if they do not match, the number is accepted as a DES key. Note that the parity bits are not set, although they can be set when exporting the key. This is to keep compatibility with some PIN block management functions (not included in this firmware version). In the RSA key pair case, the process starts generating the prime numbers p and q, with length according to the specified modulus length. There are different possibilities regarding primality tests, they can be selected by the User. In FIPS mode, FIPS 186-2 specifications are followed. 2.7.3 Key Import and Export There are three methods to import a symmetric key: 1. Split knowledge. Each custodian of each component is authenticated (one by one) before typing its part of the key. The key component is entered along with a corresponding CV. The cryptographic module calculates a CV and compares it to the CV entered. If the values do not match, an error occurred during key entry and the key is rejected. The n components are needed to restore the key imported. The key is assigned to the owner of the session. 2. Ciphered with a DES key. The owner of the key is authenticated before giving its key, which is ciphered with the Transport Key of the owner or with other key owned by the User. 3. Ciphered with a RSA key pair. The User can import the DES key previously ciphered with a public key, if the User owns the key pair. There are three methods to export a symmetric key: 1. Split knowledge. Each custodian is authenticated (one by one) before getting its part of the key. The cryptographic module gives the CV of each part to be verified next time it was imported. 2. Ciphered with a DES key. The key is ciphered with the Transport Key of the owner. 3. Ciphered with a RSA key pair. The User can select a RSA key pair and export the DES key ciphered with the public part. RSA key pairs are exported or imported ciphered with the transport key in a PKCS#1 RSA Private structure. The public parts are exportable freely and in clear, in a PKCS#1 RSA Public structure. © 2004 Realia Technologies S.L. Page 12 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Although it is not an import/export mechanism, note that every key is saved and restored in the back-up process. 2.7.4 Key Zeroization If the physical security mechanisms are activated, the back-up key, the work key and the Master Firmware key are actively zeroized, together with the firmware and other processor's internal memory contents. The User information, the rest of the secret keys and the private keys are not erased but retained in encrypted format, but they are unusable, as the Master Firmware key is zeroized. The delete firmware command, followed by a reset, forces the activation of the process described in the former paragraph. Key deletion and user deletion processes include the zeroization of key and user information. 2.7.5 Random Number Generator The Cryptosec 2048 uses the FIPS approved RNG specified in FIPS 186-2 with change notice DSA-RNG using SHA-1 for generation of cryptographic keys and other purposes in FIPS mode. This RNG is seeded with the internal hardware-based RNG. In non FIPS mode, the module only uses the internal hardware-based RNG. A continuous test is performed on both. 2.8 EMI/EMC The module conforms to FCC Part 15 Class B requirements for home use. 2.9 SELF TESTING The Self-Tests that the module can perform are: · Power-Up Tests o Integrity of Firmware Test (CRC-32). o TDES KAT (3-key, 2-key, single key (DES)). o SHA-1, MD5, RIPEMD-128, RIPEMD-160 KAT. o RSA KAT. o RNG KAT (FIPS 186-2 RNG). · Conditional Tests o Pair-wise consistency Test (RSA). o Signature Generation/Verification Test (RSA). o Manual Key Entry Test. o Continuous RNG Test (applicable to the hardware-based RNG and also to the FIPS 186-2 RNG in FIPS mode). The events that can produce the conditions are as follows: © 2004 Realia Technologies S.L. Page 13 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. EVENT (E) or FUNCTION (F) CONDITION Power up (E) Firmware integrity test Power up (E) DES test Power up (E) Hash test Power up (E) RSA test RSA key generation (F) Pair wise consistence test RSA key generation no store(F) RSA key generation, no store and cipher (F) Write private key(F) RSA key generation (F) Sign verify test RSA key generation no store (F) RSA key generation, no store and cipher (F) Write private key (F) Load backup key (F) Manual key entrance test Load transport key (F) Load DES key parts (F) Load DES key list parts (F) Load work key (F) First time the firmware is loaded (E) Continuous RNG test Create session (F) RSA public (F) Get backup key (F) Get transport key (F) Get DES key parts (F) RSA key generation (F) RSA key generation no store (F) RSA key generation, no store and cipher (F) If a power-up self-test error has occurred, the module displays an appropriate indicator via the status output interface. The module must be reset to clear the error condition, and then can resume normal operation. If the Error continues (hard-error) to occur, the module must be returned to the manufacturer for repair or the firmware must be replaced. If a conditional error occurs, the module clears the soft-error and resumes normal operation. 2.10 DESIGN ASSURANCE Each release of the hardware is stored in a separate repository named by release number. Each hardware build is named, e.g.: v0.0, v0.1, v1.0, v1.1, v2.0, etc. The hardware version is shown on the space between the battery and the module's cover. It is also shown by means of the VT-100 terminal when the module is started. Each release of the firmware is stored in a separate repository named by release number. Each hardware build is named, e.g.: v00.00.0000, v00.01.0001, v01.00.0010, v01.01.0000, v02.00.0004, etc. The firmware version is shown invoking a specific command. As the hardware version, it is also shown by means of the VT-100 terminal when the module is started. User documentation is versioned like source. Each release of the documentation is stored in a separate repository named by release number. The documentation states the firmware version that it refers to. 2.11 MITIGATION OF OTHER ATTACKS The Cryptosec 2048 does not employ any technology that mitigates against other attacks. © 2004 Realia Technologies S.L. Page 14 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 3 SECURE OPERATION OF THE CRYPTOSEC 2048 3.1 Secure administration 3.1.1 Initialization When the module is received, the Superuser must check the module's case for evidence of tampering. Such indications include prying, bending, or cutting of the metal casing. After checking the module for evidence of tampering, the Superuser must connect the module to the PCI port on the computer to be used. The RS-232 connection must also be established, using the supplied cable, with a VT-100 terminal or equivalent. Although it is not mandatory, the Superuser should connect the supplied battery, in order to keep the module's contents in absence of PCI power supply. The installation CD contains all the setup files needed to access the Cryptosec 2048 module. The module is delivered in a blank state, this is, with no firmware loaded. It is necessary to load the firmware into the module. The firmware is supplied in a *.emb file. Once the firmware is loaded, the module resets and the CRC-32 check of the firmware is performed, along with other self-test. If they pass the module asks, through the RS-232 connection, for an unlock PIN. This value, with a length of 8 bytes, is sent to the client separately, and it is unique for that version of the firmware and that particular module. This unlock PIN is not retained in the module, and it is not needed after the firmware installation. When the unlock PIN is correctly typed, the module asks for the login and password of the first User. This User will have Superuser privileges. The module must have at least one User, and that User must be Superuser. Nevertheless, the User created at this point can be deleted in the future, provided that there is another Superuser already created. In other cases, the module will start the Superuser creation automatically. This implies that there can be as many superusers as needed, and all of them operate as administrators without distinction. 3.1.2 Management The module can be administered using the supplied managing User interface. This software allows the User to access all the functions supported by the module, and check the status of the module. Superuser and User guides are available from Realia Technologies S.L. The Superuser can create Users up to the limit of 1000 accounts, including both users and superusers. Each User should modify the initial password given by the Superuser. The passwords do not expire. As the users can create and load both RSA and DES keys, the Superuser should check how many keys each User owns, and define a policy regarding this subject. Superusers can delete a User, which deletes all of its keys, but can not directly delete keys of other users. It is compulsory to make a back-up before upgrading the firmware, as this operation erases the memory of the module. Once the upgrade is finished, the back-up should be restored. A back- up scheme should be established by the organization using the module. The Superuser is responsible for keeping track of the module and must routinely check the module for signs of physical tampering. If strange activity or damage to the case is apparent, the Superuser should take the module offline and investigate. The battery must be changed every two years. It can be done while the module is working. If it is done in absence of PCI power supply, the operation should not last more than a minute. © 2004 Realia Technologies S.L. Page 15 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 3.1.3 Termination When a module's usage has been completed, the module should be zeroized by the Superuser in order to wipe all sensitive data. This zeroization should be done by deleting the module's firmware, using the appropriate command, and taking apart the battery, if applicable. The module should then be stored in a secure location. 3.2 Secure operation The User behavior with respect to the secure operation of the module is mainly related to the secret of the password and the keys or keys components that the User custodies. The User should be careful not to provide private keys and secret keys to other parties. The User should also not provide the User password to anyone. © 2004 Realia Technologies S.L. Page 16 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 4 FIPS 140-2 MODE OF OPERATION FIPS 140-2 mode of operation is defined as a mode in which only FIPS allowed or approved security methods are used. Whether the module operates in a FIPS Approved Mode of Operation or not is selected by the User. This is done by invoking the change mode service. Any User can access the information regarding the FIPS or not FIPS state, its flag is part of the status of the module shown in the PCI port registers. Note that there are some services not available in FIPS mode: those related to work key and licensing. Refer to 2.3.1 Crypto-Officer Role and 2.3.2 User Role for details. 4.1 Security Functions 4.1.1 Approved Security Functions The following are the approved Security functions for FIPS 140-2 Mode of Operation: The approved cryptographic algorithms are: · FIPS 186-2 with change notice DSA-RNG using SHA-1. · SHA-1 bit oriented. · DES ECB. · DES CBC. · DES CFB64. · DES OFB64. · 2-key TDES ECB. · 2-key TDES CBC. · 2-key TDES CFB64. · 2-key TDES OFB64. · 3-key TDES ECB. · 3-key TDES CBC. · 3-key TDES CFB64. · 3-key TDES OFB64. · RSA signature generation/verification and key wrapping. Note that DES is only to be used in legacy systems. 4.1.2 Non-Approved Security Functions Non Approved Security Functions: · Hardware-based RNG. · RSA for general encryption/decryption. · MD5. · RIPEMD-160. · RIPEMD-128. The module's DES implementation includes a mechanism that can be used for calculating a DES-MAC: the module can output the appropriate DES blocks and an external application can used them to calculate the MAC value. Although the module does not implement the DES- MAC algorithm, it can be used for the calculation of the MAC. © 2004 Realia Technologies S.L. Page 17 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. As previously stated, the Cryptosec 2048 comes with the certified firmware revision compliant, tested and validated with FIPS 140-2. © 2004 Realia Technologies S.L. Page 18 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 5 GLOSSARY OF TERMS The following table lists the terms discussed in this security policy and their respective definitions: Term Definition DES Data Encryption Standard CB2000® Crypto Board 2000 CBC Cipher Block Chaining CD Compact Disk CFB64 Cipher FeedBack (64-bit feedback data) CRC Cyclic Redundancy Checksum CSP Critical Security Parameter CV Check Value CVV VISA Card-Verification Value DB-15 Sub D 15-pin connector DES Data Encryption Standard DSA Digital Signature Algorithm ECB Electronic Code Book EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communications Commission FIPS Federal Information Processing Standard FSM Finite State Machine I2C Inter-Integrated Circuit ID Identification MAC Message Authentication Code MD5 Message Digest 5 N/A Not Applicable NIST National Institute of Standards and Technology OFB64 Output Feedback (64-bit feedback data) PCB Printed Circuit Board PCI Peripheral Component Interconnect PIN Personal Identification Number PKCS Public Key Cryptographic Standard RIPEMD Race Integrity Primitives Evaluation Message Digest RNG Random Number Generator RS-232 Recommended Standard 232 RSA Rivest, Shamir and Adleman RTC Real Time Clock SAFER Secure And Fast Encryption Routine SHA-1 Secure Hash Algorithm SRAM Static Random Access Memory VIS VISA Information Source VT-100 DEC's Video Terminal 100 © 2004 Realia Technologies S.L. Page 19 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.