LEVEL 3 SECURITY POLICY FOR ProtectServer Gold (PSG) DOCUMENT NUMBER: CR-2505 AUTHOR: B. Franklin / C. Brych DEPARTMENT: Engineering LOCATION OF ISSUE: Ottawa DATE ORIGINATED: September 7, 2007 REVISION LEVEL: 37 REVISION DATE: February 26, 2014 SUPERSESSION DATA: CR-2505, Revision 36 SECURITY LEVEL: Non-Proprietary © Copyright 2007-2014 SafeNet, Inc. ALL RIGHTS RESERVED This document may be freely reproduced and distributed whole and intact including this copyright notice. SafeNet, Inc. reserves the right to make changes in the product or its specifications mentioned in this publication without notice. Accordingly, the reader is cautioned to verify that information in this publication is current before placing orders. The information furnished by SafeNet, Inc. in this document is believed to be accurate and reliable. However, no responsibility is assumed by SafeNet, Inc. for its use, or for any infringements of patents or other rights of third parties resulting from its use. Document is uncontrolled when printed. CR-2505 Revision Level: 37 TABLE OF CONTENTS Section Title Page 1.  INTRODUCTION ..................................................................................................................................... 4  1.1  Purpose ............................................................................................................................................ 4  1.2  References ....................................................................................................................................... 4  1.3  Terminology ..................................................................................................................................... 5  1.4  Document Organization ................................................................................................................... 5  2.  THE PSG CARD ..................................................................................................................................... 6  2.1  Cryptographic Module Specification ................................................................................................ 6  2.2  Cryptographic Module Ports and Interfaces..................................................................................... 7  2.3  Roles, Services, and Authentication ................................................................................................ 8  2.3.1  Services for Authorized Roles .................................................................................................. 9  2.3.2  Administrator Security Officer ................................................................................................... 9  2.3.3  Administrator ............................................................................................................................. 9  2.3.4  Token SO ................................................................................................................................ 10  2.3.5  Token User ............................................................................................................................. 10  2.3.6  Unauthenticated Operators ..................................................................................................... 11  2.4  Physical Security ............................................................................................................................ 11  2.5  Operational Environment ............................................................................................................... 11  2.6  Cryptographic Key Management ................................................................................................... 11  2.6.1  Key Generation ....................................................................................................................... 11  2.6.2  Key Access / Storage.............................................................................................................. 11  2.6.3  Security Functions .................................................................................................................. 14  2.7  Self-Tests ....................................................................................................................................... 16  2.7.1  Power-Up Self-Tests ............................................................................................................... 16  2.7.2  Conditional Self-Tests ............................................................................................................. 17  2.8  Mitigation of Other Attacks ............................................................................................................. 17  3.  FIPS APPROVED MODE OF OPERATION ......................................................................................... 18  3.1  Description ..................................................................................................................................... 18  3.2  Invoking Approved Mode of Operation .......................................................................................... 18  3.3  Mode of Operation Indicator........................................................................................................... 18  3.4  Invoking Mode of Operation Indicator ............................................................................................ 18  4.  DESIGN ASSURANCE ......................................................................................................................... 19  4.1  Distribution and Delivery of Module ............................................................................................... 19  Document is Uncontrolled When Printed. Page 2 of 21 CR-2505 Revision Level: 37 LIST OF TABLES Table Title Page Table 2-1 FIPS 140-2 Security Levels .......................................................................................................... 7  Table 2-2 FIPS 140-2 Logical Interfaces ...................................................................................................... 8  Table 2-3 Roles and Required Identification and Authentication ................................................................. 8  Table 2-4 Available Services ........................................................................................................................ 9  Table 2-5 List of Keys Stored in Module .................................................................................................... 13  Table 2-6 Access to Keys for Authorized Services .................................................................................... 13  Table 2-7 FIPS Approved and Allowed Security Functions .......................................................................15  Table 2-8 Non-Approved Security Functions ............................................................................................. 15  Table 2-9 Summary of Key Derive Mechanisms ........................................................................................ 16  Table 2-10 Power-up Self-Tests ................................................................................................................. 17  Table 2-11 Conditional Self-Tests .............................................................................................................. 17  LIST OF FIGURES Figure Title Page Figure 2-1 The PSG ..................................................................................................................................... 6  LIST OF APPENDICES Appendix Title Page APPENDIX A.  ACRONYMS AND ABBREVIATIONS ............................................................................ 20  Document is Uncontrolled When Printed. Page 3 of 21 CR-2505 Revision Level: 37 1. INTRODUCTION 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the ProtectServer Gold (PSG). This security policy describes how the PSG meets the security requirements of FIPS 140-2 and how to operate the PSG in a secure FIPS 140-2 mode. This policy was prepared as a part of the Level 3 FIPS 140-2 validation of the PSG. 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 web site at http://csrc.nist.gov/groups/STM/cmvp/index.html 1.2 References This document deals only with operations and capabilities of the PSG in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the PSG and other SafeNet products from the following sources:  The SafeNet internet site contains information on the full line of security products at http://www.safenet-inc.com/products/data-protection/.  For answers to technical or sales related questions please refer to the contacts listed on the SafeNet internet site at http://www.safenet-inc.com/company/contact.asp. SafeNet Contact Information: 4690 Millennium Drive SafeNet, Inc. (Corporate Headquarters) Belcamp, MD 21017 Telephone: 410-931-7500 TTY Users: 800-735-2258 Fax: 410-931-7524 20 Colonnade Road SafeNet Canada, Inc. Suite 200 Ottawa, Ontario K2E 7M6 Telephone: 613 723 5077 Fax: 613 723 5078 SafeNet Sales: (800) 533-3958 U.S. (410) 931-7500 International SafeNet Technical Support: (800) 545-6608 U.S. (410) 931-7520 International SafeNet Customer Service: (866) 251-4269 U.S. +44 (0) 1276 60 80 00 EMEA 852 3157 7111 APAC Document is Uncontrolled When Printed. Page 4 of 21 CR-2505 Revision Level: 37 1.3 Terminology In this document the SafeNet ProtectServer Gold card is referred to as the PSG, the adapter, or the module. 1.4 Document Organization This document provides an overview of the PSG and explains the secure configuration and operation of the module. This introduction section is followed by Section 2, which details the general features and functionality of the PSG. Section 3 specifically addresses the required configuration for the FIPS mode of operation. Document is Uncontrolled When Printed. Page 5 of 21 CR-2505 Revision Level: 37 2. THE PSG CARD 2.1 Cryptographic Module Specification The SafeNet PSG is a high-end intelligent PCI adapter card that provides a wide range of cryptographic functions using firmware and dedicated hardware processors. This document refers specifically to PSG hardware revisions B2, B3, B4 and Model PSG-01 Version Code 0101 running firmware version 3.20.01. Cryptographic Boundary Figure 2-1 The PSG The module, running SafeNet’s Cprov firmware, implements the Cryptoki cryptographic API as defined by RSA Data Security. While certain Cryptoki features are not supported, the module does provide a comprehensive compliance to the PKCS#11 standard as well as vendor-specific extensions. The cryptographic boundary for this module encapsulates the majority of the adapter card. An opaque, metal cover surrounds the card to provide tamper-protection and to establish the cryptographic boundary. This boundary encapsulates the Data Ciphering Processor (DCP), embedded processor, SDRAM memory chips, and the Real Time Clock (RTC). Document is Uncontrolled When Printed. Page 6 of 21 CR-2505 Revision Level: 37 The module provides key management (e.g., generation, storage, deletion, and backup), an extensive suite of cryptographic mechanisms, and process management including separation between operators. The PSG also features non-volatile tamper protected memory for key storage, a hardware random number generator, and an RTC. The PSG is classified as a multi-chip embedded processor for FIPS 140-2 purposes. The FIPS 140-2 cryptographic boundary is defined by the perimeter of the protection covers. The battery, battery isolation link, and external alarm input link are excluded from the FIPS 140-2 security requirements. The PSG meets all level 3 requirements for FIPS 140-2 as summarized in Table 2-1. Section Section title Level 1 Cryptographic Module Specification 3 2 Cryptographic Module Ports and Interfaces 3 3 Roles, Services, and Authentication 3 4 Finite State Machine 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 Table 2-1 FIPS 140-2 Security Levels 2.2 Cryptographic Module Ports and Interfaces The PSG has the following physical interfaces:  A standard PCI bus interfacing to the motherboard of the host machine  Two asynchronous RS232 serial connectors  A battery isolation connector  An external alarm input connector. The PSG provides a tightly secured cryptographic element. All requests for services sent to the adapter over the PCI bus or the serial ports are captured by the adapter’s processor, which controls the level of access to the on-board cryptographic services and the keys. The adapter’s processor also responds to PKCS #11 commands, ensuring that during FIPS operation only authenticated users receive cryptographic services. Document is Uncontrolled When Printed. Page 7 of 21 CR-2505 Revision Level: 37 The module’s physical interfaces are separated into the logical interfaces, defined by FIPS 140-2, and described in Table 2-2: FIPS 140-2 Logical Interfaces Adapter Physical Interfaces Data Input Interface PCI Bus, Serial ports Data Output Interface PCI Bus, Serial ports Control Input Interface PCI Bus, External tamper input Status Output Interface PCI Bus Power Interface PCI Bus, External battery link Table 2-2 FIPS 140-2 Logical Interfaces 2.3 Roles, Services, and Authentication The PSG supports identity-based authentication of its operator. Operators are identified by a token name and PIN. The different roles and required authentication are shown in Table 2-3. Role Type of authentication Authentication Data Admin SO Identity Based Operator Unique PIN Administrator Identity Based Operator Unique PIN Token SO Identity Based Operator Unique PIN Token User Identity Based Operator Unique PIN Table 2-3 Roles and Required Identification and Authentication The PSG supports three types of Tokens: one Administration Token, multiple Cprov Tokens and one or more Smart Card Tokens. All Tokens have two operators: a Security Officer (SO) and a User. For the Administration Token, the Admin SO is the Security Officer and the Administrator is the User. For all other Tokens, the Security Officer is the Token SO and the Token User is the User. The operator explicitly selects a role when logging in by selecting a PKCS#11 Token and nominating either User or SO Role. The adapter provides restricted services to an operator based on the role to which the operator authenticated. There is only one operator assigned to each role. The Admin SO, Admin and Token SO perform FIPS 140-2 Crypto Officer roles while the Token User performs a FIPS 140-2 User role. The PSG enforces an absolute minimum PIN length of 4 characters. The module allows the PIN character to be any value but the software typically used with the module restricts the dictionary to the ANSI C character set. This character set provides for 92 visible characters which, with a 4 character PIN, provides a probability of less than one in 1,000,000 that a random PIN attempt (e.g., guess) will succeed (actual probability is approximately 1/71,600,000). The module is protected from brute force PIN attacks by imposing an increasing delay for every failed PIN attempt after the first three failed attempts. The initial delay is 5 seconds and increases by an additional 5 seconds for each subsequent failed attempt, e.g., 3 fails causes a 5 second delay; 4 fails causes a 10 second delay; 5 fails causes a 15 second delay; etc. Document is Uncontrolled When Printed. Page 8 of 21 CR-2505 Revision Level: 37 2.3.1 Services for Authorized Roles Table 2-4 lists the services related to each authorized role within the adapter: Role Services Admin SO Initialize Administrator Token User PIN Admin Manage Adapter and Admin Token Token SO Manage Token Token User Use Token and manage token keys Unauthenticated operator Unauthenticated services Table 2-4 Available Services 2.3.2 Administrator Security Officer The primary role of the Administrator Security Officer (ASO) is to introduce the Administrator to the system. The ASO is able to set the initial Administrator PIN value but is not able to change the administration PIN after it is initialized. The ASO can perform the following actions:  Set the initial Administrator PIN value (may not change it later).  Set the CKA_TRUSTED attribute on a Public object in the Admin Token.  Set the CKA_EXPORT attribute on a Public object in the Admin Token.  Manage Host Interface Master Keys  Exercise cryptographic services with Public objects  Create, destroy, import, export, generate, and derive1 Public objects  May change his/her own PIN  Read the Hardware Event Log  May modify Monotonic Counter object 2.3.3 Administrator The Administrator is responsible for the overall security management of the adapter. Token Security Officers and Slots are controlled by the Administrator. The following actions are available to the Administrator:  Set or Change RTC value  Read the Hardware Event Log  Purge a full Hardware Event Log  Configure the Transport Mode feature  Specify the Security Policy of the adapter  Create new Cprov Slots/Tokens and specify their Labels, SO PINs, and minimum PIN Length  Initialize smart cards and specify their Labels and SO PINs  Destroy individual Cprov Slots/Tokens 1 Key Derive operations are listed in Table 2-99. Document is Uncontrolled When Printed. Page 9 of 21 CR-2505 Revision Level: 37  Erase all adapter Secure Memory including all PINs and User Keys (zeroize the module)  Perform Firmware Upgrade Operation  Manage Host Interface Master Keys  Exercise cryptographic services with Public objects on Admin Token  Exercise cryptographic services with Private objects on Admin Token  Create, destroy, import, export, generate, and derive Public objects on Admin Token  Create, destroy, import, export, generate, and derive Private objects on Admin Token  May change his/her own PIN  May revoke Authentication 2.3.4 Token SO The Token SO is responsible for granting and revoking ownership of the token. If the Token does not have a User PIN, the Token SO should initialize it by assigning the Label and User PIN. The token SO may also revoke the Token User’s privileges (and possibly reassign the token to another operator) but only by destroying all the key material of the original operator first. The following actions are available to the Token SO:  Set the initial User PIN value (may not change it later)  Reset (re-initialize) the Token (destroys all keys and User PIN on the Token) and set a new Label  Set the CKA_TRUSTED attribute on a Public object in his or her Token  Set the CKA_EXPORT attribute on a Public object in his or her Token  Exercise cryptographic services with Public objects in his or her Token  Create, destroy, import, export, generate, and derive Public objects in his or her Token  May change his/her own PIN  May modify Monotonic Counter object 2.3.5 Token User Token users may manage and use private and public keys on their own tokens. The following actions are available to the Token User:  Exercise cryptographic services with Public objects in his or her Token  Exercise cryptographic services with Private objects in his or her Token  Create, destroy, import, export, generate, derive Public objects in his or her Token  Create, destroy, import, export, generate, and derive Private objects in his or her Token  May change his/her own PIN Document is Uncontrolled When Printed. Page 10 of 21 CR-2505 Revision Level: 37 2.3.6 Unauthenticated Operators Certain services are available to operators who have not (yet) authenticated to the adapter:  Exercise status querying services  Authenticate to a Token  Force session terminate, restart adapter by setting the doorbell register on the hardware. The doorbell register is a memory map to the PCI bus. The host application can force a restart by writing a certain value to the register through the PSG device driver. The transparent PCI chip will then generate a bus cycle restart which in turn will restart the adapter. All of the services available to the Unauthenticated Operators are also available to all authenticated operators. 2.4 Physical Security The adapter provides tamper evidence and tamper response mechanisms. The non-removable metal casing provides a strong tamper evident enclosure. The Administrator should perform routine visual inspection of the module for evidence of tamper such as scratches. The module is actively protected through a combination of tamper switches, a light sensor, and a voltage monitor. The PSG protection can also be activated by removal of the adapter from the host machine or via an external alarm input capability. In the event of a tamper the PSG enters a Tamper state in which all processing is halted and the secure memory is erased. 2.5 Operational Environment This section does not apply. The PSG does not provide a modifiable operational environment. 2.6 Cryptographic Key Management The PSG is a general-purpose cryptographic management device and thus securely administers both cryptographic keys and other critical security parameters (CSPs) such as passwords. 2.6.1 Key Generation The PSG Module supports the generation of DSA, RSA, ECDSA (also known as ECC), and DH public and private keys. The module also supports the generation of three-key Triple-DES keys as well as AES 128 bit, 192 bit, and 256 bit keys. The module implements the FIPS approved PRNG specified in FIPS 186-2 x-Original using SHA-1 that is used for generating random values required for key generation. The PRNG is seeded from the HRNG on the Pijnenburg crypto chip. 2.6.2 Key Access / Storage All keys except module specific keys are stored as plaintext token objects in secure memory (battery-backed RAM), and the module prevents physical access to this RAM through the physical security mechanisms discussed in section 2.4. Logical access to keys and other CSPs is restricted to authenticated operators with valid permissions. Any key input to the module is done so over a TRIPLE-DES encrypted trusted channel, or by components through a dedicated port and the module only allows keys to be output if they are wrapped using a FIPS approved algorithm. The following table outlines all the keys stored by the module. Document is Uncontrolled When Printed. Page 11 of 21 CR-2505 Revision Level: 37 Keys and CSP’s CSP Type Generation Input/Output Storage Destruction Mechanism Use Firmware upgrade 2048-bit RSA FIPS 186-2 RNG Not input/output Plaintext in Flash None To verify the signature attached to a Certificate “Not a CSP” new firmware image. Default Administrative 4 character PIN N/A Not input/output Plaintext in Flash Replaced as part of the For initial authentication to the module. Token SO PIN initialization process Replaced after the module is initialized. D-H Key Agreement 2048-4096 bit Private Component Public key Working memory Power cycle, tamper, or To establish an encrypted channel Modulus Size4 Keys Generated Via exported as part between an operator and the module. C_DestroyObject() API FIPS 186-2 RNG; of key Public Value agreement Computed via Diffie-Hellman DH Shared Secret Key 192-bit Triple-DES Established via DH Not input/output Working memory Power cycle, tamper, or Protects data between an operator and the module. Triple-DES is used to C_DestroyObject() API protect the secure channel established using DH. ECDH (P521)5 EC-DH Key Agreement Private Public key Working memory Power cycle, tamper, or To establish a session key for the use Keys Component exported as part of client applications. C_DestroyObject() API Generated Via of key FIPS 186-2 RNG; agreement Public Value Computed via Diffie-Hellman Message HMAC-SHA-1 Established via DH Not Working memory Power cycle, tamper, or Provide data authentication of Authentication Key (20-byte key) Input/Output encrypted data between an operator C_DestroyObject() API and the module. RSA Public/Private 2048 – 4096 bit ANSI X9.31 Public key Working memory Power cycle, tamper, or Key wrapping as part of a TLS key RSA4 Keys exported as part establishment protocol or other client C_DestroyObject() API of key application use. agreement Input encrypted2 Operating PINs 4 – 32 character PIN N/A Secure memory Tamper or All users’ PINs – Admin Token SO, Encrypted with MMK Admin Token User, Token SOs, and C_DestroyObject() API Token users used to authenticate to the module. Encrypted3 or Token Keys 128/192/256-bit AES FIPS 186-2 RNG Secure memory Tamper or User-created keys for use by user or 128/192-bit Triple- split knowledge encrypted with MMK applications C_DestroyObject() API DES 2 PINs encrypted using Triple-DES 3 Token Keys encrypted using AES or Triple-DES Application Keys 4 Key sizes compliant with NIST SP 800-131A, key sizes < 2048 bits are non-compliant 5 Key sizes compliant with NIST SP 800-131A, key curves < 224 bits are non-compliant Document is Uncontrolled When Printed. Page 12 of 17 CR-2505 Revision Level: 37 Keys and CSP’s CSP Type Generation Input/Output Storage Destruction Mechanism Use Application Keys 128/192/256-bit AES FIPS 186-2 RNG Output Secure memory Tamper or Used by client applications or to wrap or 128/192-bit Triple- encrypted encrypted with MMK Token Keys output from the module. C_DestroyObject() API DES RNG Seed Key Seed Key H/W RNG Not input/output Not permanently Power cycle or tamper Used as part of the RNG process. stored, working memory only Module Master Key 3-key 192-bit Triple- FIPS 186-2 RNG Not input/output Tamper responsive Tamper or Zeroize Used to encrypt contents of secure DES memory in NVRAM command memory of RTC (ctconf –x) Table 2-5 List of Keys Stored in Module The following table outlines the access that “Authorized Services” (see Table 2-4) have to the keys listed in Table 2-5. Here ‘R’ stands for “Read”, ‘W’ stands for “Write”, X stands for “Execute” and “Z” stands for “Zeroize”. FW Upgrade Default Admin Token DH Operating Token Keys Token Keys PRNG Cert SO PIN Parameters PINs (Public) (Private) Seed Key Initialization - - X WX - - - Administrator SO WX WX WXZ WXZ RWXZ WRXZ - Administrator - - X WXZ - - - Token SO - - X X - - - Token User - - X X XZ XZ XW Unauthenticated Operators - - - X - - - Table 2-6 Access to Keys for Authorized Services Please note that the FW Upgrade Cert is never zeroized because it is a public key. The Default Admin Token SO PIN is never zeroized because it’s a pre-initialization value. The PRNG Seed Key is zeroized when a tamper event is detected or overwritten when the module is restarted. All other CSPs/Keys identified in Table 2-6 are zeroized by a call to the C_DestroyObject() API by the respective role or through a tamper event. Document is Uncontrolled When Printed. Page 13 of 17 CR-2505 Revision Level: 37 2.6.3 Security Functions The PSG supports a wide variety of security functions. FIPS 140-2 requires that only FIPS Approved algorithms be used whenever there is an applicable FIPS standard. The following table lists the PSG approved and allowed security functions. In the FIPS mode of operation only these security functions are available.  Functions that are appended with a C have been certified through the Cryptographic Algorithm Validation Program (CAVP) for use in the FIPS mode of operation.  Functions that are appended with an A are allowed by the Cryptographic Module Validation Program (CMVP) to be used in the FIPS mode of operation. Symmetric Encryption/Decryption FW 3.20.01 C AES : (ECB); Encrypt/Decrypt; Key Size = 128, 192, 256) Cert. 2605 Triple-DESC: (TECB, TOFB); Encrypt/Decrypt; KO 1,2)6 Cert. 1570 Secure Hash Standard (SHS) SHA-1C, SHA-224C, SHA-256C, SHA-384C, SHA-512C (Byte Only) Cert. 2189 Message Authentication Code HMAC-SHA-1C, HMAC-SHA-224C, HMAC-SHA-256C, HMAC-SHA-384C, HMAC-SHA-512C Cert. 1613 C Triple-DES MAC (Vendor Affirmed) Cert. 1570 Asymmetric RSAC: FIPS186-2: [ANSIX9.31]; KEYGEN; SIG (gen); (MOD: 2048, 3072, 4096 with SHA (224, 256, 384, 512); SIG (ver) (MOD: 1024, 1536, 2048, 3072, 4096 with SHA(1, 224, 256, 384, 512) PubKey Values: 3, 17, 65,537 ); Cert. 13327 [RSASSA-PKCS1_V1_5]; SIG(gen); (MOD 2048, 3072, 4096) with SHA(224, 256, 384, 512); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096) with SHA(1, 224, 256, 384, 512) DSAC: FIPS186-2: PQG(ver) MOD(1024); SIG(ver) MOD (1024); Cert. 7908 ECDSAC: FIPS186-2: PKG: CURVES( P-224, P-256, P-384, P-521) SIG(gen): CURVES( P-224, P-256, P-384, P- Cert. 4499 521) SIG(ver): CURVES( P-192, P-224, P-256, P-384, P-521) Random Number Generation FIPS 186-2C [ (x-Original); (SHA-1) ] Cert.1233 Key Agreement Scheme Diffie-HellmanA (key establishment methodology provides between 112 and 150 bits of encryption strength; non- compliant less than 112-bits of encryption strength) EC-DHA – only NIST Recommended Curves (key establishment methodology provides between 112 and 256 bits of encryption strength, non-compliant less than 112 bits of encryption strength) 6 To use the 2-Key Triple-DES Algorithm to encrypt data or wrap keys in an Approved mode of operation, the module operator shall ensure that the same two-key Triple-DES key is not used for encrypting data (or wrapping keys) with more than 220 plaintext data (or plaintext keys). Please refer to Section 2 of NIST SP 800-131A for restriction information regarding its use until December 31, 2015. 7 Please note that the following are no longer approved for use in FIPS mode: FIPS186-2: ALG[ANSIX9.31]: Key(gen)(MOD: 1024, 1536 PubKey Values: 3, 17, 65537); ALG[RSASSA-PKCS1_V1_5]: SIG(gen): 1024, 1536 using SHA-1, SHA-224 , SHA-256, SHA-384, SHA-512 and 2048, 3072, 4096 using SHA-1. 8 Please note that the following are no longer approved for use in FIPS mode: FIPS186-2: PQG(gen) MOD(1024); KEYGEN(Y) MOD(1024); SIG(gen) MOD(1024). 9 Please note that the following are no longer approved for use in FIPS mode: FIPS186-2: PKG: CURVES( P-192 ); SIG(gen): CURVES( P-192) and ( P-224 P-256 P-384 P-521 using SHA-1). Document is Uncontrolled When Printed. Page 14 of 21 CR-2505 Revision Level: 37 Key Transport RSAA ENCRYPT/DECRYPT (key wrapping; key establishment methodology provides between 112 and 150 bits of encryption strength, non-compliant less than 112 bits of encryption strength) AESA (key wrapping; key establishment methodology provides 128, 192 or 256 bits of encryption strength) Triple-DESA (key wrapping; key establishment methodology provides 112 bits of encryption strength, non-compliant less than 112 bits of encryption strength) Table 2-7 FIPS Approved and Allowed Security Functions The following table lists the PSG Non-Approved security functions. When the PSG is in the FIPS mode of operation these functions are not available. Non-Approved Security Functions DES (ECB, CBC, OFB64) DES MAC AES MAC CAST 128 (ECB, CBC) CAST MAC IDEA 128 (ECB, CBC) IDEA MAC RC2 (ECB, CBC) RC2 MAC SEED 128 (ECB,CBC) SEED MAC MD2 MD5 MD5 HMAC RC4 (ECB) RIPEMD-128, RIPEMD-160 RMD128 HMAC, RMD160 HMAC ECIES ARIA 128, 192, 256 Table 2-8 Non-Approved Security Functions Document is Uncontrolled When Printed. Page 15 of 21 CR-2505 Revision Level: 37 MECHANISMS FOR SPLIT KNOWLEDGE DISABLED/NON-ALLOWED ENTRY/OUTPUT OF KEY DERIVATION METHODS (Not Allowed in FIPS Mode) (Allowed in FIPS Mode) CKM_CONCATENATE_BASE_AND_KEY CKM_DES3_DERIVE_CBC _DERIVE CKM_XOR_BASE_AND_DATA CKM_DES3_DERIVE_ECB CKM_XOR_BASE_AND_KEY CKM_DH_PKCS_DERIVE CKM_EXTRACT_KEY_FROM_KEY CKM_ECDH1_DERIVE CKM_SECRET_SHARE_WITH_ATTRIBUTES CKM _SHAxxx_KEY_DERIVATION CKM_SSL3_KEY_AND_MAC_DERIVE CKM_SSL3_MASTER_KEY Table 2-9 Summary of Key Derive Mechanisms 2.7 Self-Tests The PSG Module performs a number of power-up and conditional self-tests to ensure proper operation. 2.7.1 Power-Up Self-Tests When the module is initially powered-on, it executes a battery of power-up self-tests. If any of the power-up self-tests fail, the module will enter an error state and prohibit an operator from exercising the module’s cryptographic functionality. Table 2-10 lists the power-up self-tests: FIPS 140-2 Test Function Required SDRAM Tests the module’s volatile working memory by performing a No connectivity test SRAM Tests the module’s static RAM by performing a connectivity No test Secure Memory File System Initializes and checks the module’s secure memory file system Yes Integrity Flash Boot Block Verifies a checksum over the module’s personalization data in Yes ROM RTC Connectivity Verifies that the CPU can connect to the UART device No RNG KAT Performs a known answer test for RNG operations. Yes Symmetric Cipher KATs Performs known answer encrypt/decrypt tests for AES, Triple- AES and Triple-DES DES, CAST, IDEA, RC2, DES, and RC4. MAC Performs known answer tests for CAST MAC, IDEA MAC, Triple-DES MAC and RC2 MAC, DES MAC and Triple-DES MAC. HMAC-SHA-1, HMAC KATs Performs known answer tests for MD5 HMAC, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC- HMAC-SHA-256, SHA-512, RMD128 HMAC and RMD160 HMAC. HMAC-SHA-384, HMAC-SHA-512 Asymmetric Cipher KATs Performs known answer tests for RSA operations. Yes Asymmetric Key Derive KATs Performs known answer tests for ECDH1 Derive No Asymmetric Pairwise Performs a pairwise consistency test on a DH key pair Yes Consistency Test Asymmetric Sign/Verify KAT Known answer signature generation/verification tests for RSA, RSA, DSA, ECDSA DSA and ECDSA. Document is Uncontrolled When Printed. Page 16 of 21 CR-2505 Revision Level: 37 FIPS 140-2 Test Function Required Message Digest KATs Verifies known message/hash pairs for MD2, MD5, RMD128, SHA-1 RMD 160, SHA-1, SHA-224, SHA-256, SHA-384 and SHA- SHA-224, 512. SHA-256, SHA-384, SHA-512 Software/Firmware Integrity Ensures that the software/firmware on the module has not Yes been modified / damaged by calculating a SHA-1 hash over all software/firmware components and comparing the digest to a known good result. Statistical RNG Performs a Statistical Chi Square test of 2500 bytes of random (Legacy) data Table 2-10 Power-up Self-Tests 2.7.2 Conditional Self-Tests The module performs conditional self-tests as outlined in Table 2-11. FIPS 140-2 Test Function Required Pairwise Runs a pairwise consistency check each time the module DSA, RSA, Consistency generates a DSA, RSA, ECC, or DH public/private key pair. ECC Continuous HW Performs the FIPS 140-2 required continuous RNG check Yes RNG each time the module’s Hardware RNG is used to produce random data. Continuous Performs the FIPS 140-2 required continuous RNG check Yes PRNG each time the module’s PRNG is used to produce random data. Checks that firmware is digitally signed before it can be Firmware Load Yes loaded. Note: Following a successful verification, all keys and CSPs will be zeroized. After the zeroization, the PSG will automatically transition to a non-FIPS mode and will require reconfiguration to return to FIPS mode. Table 2-11 Conditional Self-Tests 2.8 Mitigation of Other Attacks The PSG does not employ any technology specifically intended to mitigate against other attacks. Document is Uncontrolled When Printed. Page 17 of 21 CR-2505 Revision Level: 37 3. FIPS APPROVED MODE OF OPERATION 3.1 Description The PSG allows its administrators the choice of employing a wide range of security technologies. To comply with FIPS mode of operation the PSG must be configured in a secure manner. This includes:  Operation with only FIPS approved algorithms as listed in Table 2-8;  Not permitting the export of clear keys;  Locking the security mode to prevent circumvention of the mode setting;  Not permitting PINs to be used in clear;  Not permitting changes to the PSG firmware without first clearing all protected keys and CSPs; and  Providing authentication and session management security. This Security Policy describes a particular PSG firmware and hardware. The PSG firmware can be replaced (with a firmware upgrade operation) or extended (by loading Functionality Modules [FMs]). The operator should ensure that the firmware and hardware of the PSG are validated configurations. The PSG checks that new firmware is digitally signed before it can be loaded. Following a successful verification all keys and CSPs will be zeroized. After the zeroization, the PSG will automatically transition to a non-FIPS mode and will require reconfiguration to return to FIPS mode. 3.2 Invoking Approved Mode of Operation An operator may easily place the PSG in “FIPS mode” by simply running the administrative CTCONF -fF command from the remote management facility. Once this command is executed the PSG will reject all requests for non-FIPS algorithms or configurations. Please note that the operator has to be logged in as an Administrator to invoke the FIPS mode of operation. 3.3 Mode of Operation Indicator Running the display status command from a remote management facility will return a status displaying the current PSG operating mode. 3.4 Invoking Mode of Operation Indicator An operator may easily view the current PSG mode of operation by simply running the administrative CTCONF –v command from the remote management facility. Once this command is executed the PSG will respond with full details of the adapter configuration. The configuration details include details of the firmware loaded and a listing of the adapter security mode flags one of which indicates that the module is in the FIPS mode of operation. Document is Uncontrolled When Printed. Page 18 of 21 CR-2505 Revision Level: 37 4. DESIGN ASSURANCE 4.1 Distribution and Delivery of Module The module is shipped in an anti-static shipping envelope that is sealed with a SafeNet security sticker and placed inside a SafeNet shipping box. The user should inspect the product shipping boxes to make sure they have not been tampered with or damaged upon receiving the modules, which could indicate a security compromise. Document is Uncontrolled When Printed. Page 19 of 21 CR-2505 Revision Level: 37 APPENDIX A. ACRONYMS AND ABBREVIATIONS Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface ATSO Administrative Token Security Operator ATU Administrative Token User CA Certificate Authority CPU Central Processing Unit CSP Critical Security Parameter DES Data Encryption Standard DH Diffie-Hellman DSA Digital Signature Algorithm FIPS Federal Information Processing Standard HRNG Hardware Random Number Generator IDEA International Data Encryption Algorithm KAT Known Answer Test LCD Liquid Crystal Display LED Light Emitting Diode MAC Message Authentication Code MD2 Message Digest Algorithm 2 MD5 Message Digest Algorithm 5 MD5 HMAC MD5 Hashed Message Authentication Code NIST National Institute of Standards and Technology NO Normal Operator PSG ProtectServer Gold PIN Personal Identification Number PKI Public Key Infrastructure PRNG Pseudo Random Number Generator RAM Random Access Memory RC2 Rivest’s Code 2 RC4 Rivest’s Code 4 RNG Random Number Generator RoHS Restriction on Hazardous Substances ROM Read Only Memory RSA Rivest, Shamir and Adleman RWXZ Read, Write, Execute, Zero Document is Uncontrolled When Printed. Page 20 of 21 CR-2505 Revision Level: 37 Acronym Definition SDRAM Synchronous Dynamic Random Access Memory SHA Secure Hash Algorithm SO Security Operator SRAM Static Random Access Memory TDES Triple Data Encryption Standard USB Universal Serial Bus USO User Security Operator VGA Video Graphics Array Document is Uncontrolled When Printed. Page 21 of 21