Summary of the content on the page No. 1
HP StorageWorks Secure Key Manager
(Hardware P/N AJ087B, Version 1.1; Firmware Version:1.1)
FIPS 140-2
Security Policy
Level 2 Validation
Document Version 0.7
December 4, 2008
© 2008 Hewlett-Packard Company
This document may be freely reproduced in its original entirety.
Summary of the content on the page No. 2
Security Policy, version 1.0 January 31, 2008 Table of Contents 1 INTRODUCTION ...............................................................................................................................................5 1.1 PURPOSE.........................................................................................................................................................5 1.2 REFERENCES..........................................................................................
Summary of the content on the page No. 3
Security Policy, version 1.0 January 31, 2008 Table of Figures FIGURE 1 – DEPLOYMENT ARCHITECTURE OF THE HP STORAGEWORKS SECURE KEY MANAGER ................................6 FIGURE 2 – BLOCK DIAGRAM OF SKM...........................................................................................................................7 FIGURE 3 – FRONT PANEL LEDS ....................................................................................................................................9 F
Summary of the content on the page No. 4
Security Policy, version 1.0 January 31, 2008 Table of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION...................................................................................................6 TABLE 2 – LOGICAL INTERFACE AND PHYSICAL PORTS MAPPING..................................................................................8 TABLE 3 – FRONT PANEL LED DEFINITIONS.............................................................................................................
Summary of the content on the page No. 5
Security Policy, version 1.0 January 31, 2008 1 Introduction 1.1 Purpose This document is a non-proprietary Cryptographic Module Security Policy for the HP StorageWorks Secure Key Manager (SKM) from Hewlett-Packard Company. Federal Information Processing Standards (FIPS) 140-2, Security Requirements for Cryptographic Modules, specifies the U.S. and Canadian Governments’ requirements for cryptographic modules. The following pages describe how HP’s SKM meets these requirements and how to u
Summary of the content on the page No. 6
Security Policy, version 1.0 January 31, 2008 2 HP StorageWorks Secure Key Manager 2.1 Overview HP provides a range of security products for banking, the Internet, and enterprise security applications. These products use encryption technology—often embedded in hardware—to safeguard sensitive data, such as financial transactions over private and public networks and to offload security processing from the server. The HP StorageWorks Secure Key Manager is a hardened server that provides sec
Summary of the content on the page No. 7
Security Policy, version 1.0 January 31, 2008 Section Section Title Level 10 Design Assurance 2 11 Mitigation of Other Attacks N/A The block diagram of the module is given in Figure 2 – Block Diagram of SKM. The cryptographic boundary is clearly shown in the figure. Figure 2 – Block Diagram of SKM In the FIPS mode of operation, the module implements the following Approved algorithms: • Advanced Encryption Standard (AES) encryption and decryption: 128, 192, and 256 bits, in Electroni
Summary of the content on the page No. 8
Security Policy, version 1.0 January 31, 2008 • Digital Signature Algorithm (DSA) PQG generation, key generation, signature generation, and signature verification: 1024 bits (certificate # 244) • ANSI X9.31 Appendix A.2.4 with 2-key 3DES Deterministic Random Number Generator (DRNG) (certificate # 375) • Diffie-Hellman key agreement (SP 800-56A, vendor affirmed; key establishment methodology provides 80 bits of encryption strength) In the FIPS mode of operation, the module implements the
Summary of the content on the page No. 9
Security Policy, version 1.0 January 31, 2008 Figure 3 – Front Panel LEDs Descriptions of the LEDs are given in Table 3 – Front Panel LED Definitions. Table 3 – Front Panel LED Definitions Item Description Status Green = System is on. Amber = System is shut down, but power is still applied. Power On/Standby button 1 Off = Power cord is not attached, power supply failure has and system power LED occurred, no power supplies are installed, facility power is not available, or disconne
Summary of the content on the page No. 10
Security Policy, version 1.0 January 31, 2008 Figure 4 – Rear Panel Components Descriptions of components on the rear panel are given in Table 4 – Rear Panel Components Descriptions. Table 4 – Rear Panel Components Descriptions Item Definition 1 PCI Express expansion slot 1 (Blocked) 2 PCI Express expansion slot 2 (Blocked) 3 Power supply bay 2 4 Power supply bay 1 5 NIC connector 1 (Ethernet) 6 NIC connector 2 (Ethernet) 7 Keyboard connector 8 Mouse connector 9 Video connector
Summary of the content on the page No. 11
Security Policy, version 1.0 January 31, 2008 Descriptions of LEDs on the rear panel are given in Table 5 – Rear Panel LED Definitions. Table 5 – Rear Panel LED Definitions Item Description Status Green = Activity exists. 10/100/1000 NIC 1 activity 1 Flashing green = Activity exists. LED Off = No activity exists. 10/100/1000 NIC 1 link Green = Link exists. 2 LED Off = No link exists. Green = Activity exists. 10/100/1000 NIC 2 activity 3 Flashing green = Activity exists. LED Off
Summary of the content on the page No. 12
Security Policy, version 1.0 January 31, 2008 Service Description Keys/CSPs Perform first-time Configure the module when it is used for the Crypto Officer (admin) password initialization first time – write; Kdsa public/private – write; Krsa private – write; Krsa private – write; Log signing RSA key – write; Log signature verification RSA key – write; KRsaPub – write; KRsaPriv – write. Upgrade firmware Upgrade firmware (firmware must be FIPS- Firmware upgrade key – read validated
Summary of the content on the page No. 13
Security Policy, version 1.0 January 31, 2008 Table 7 – User Services Service Description Keys/CSPs Authenticate to SKM Authenticate to SKM with a username and the User passwords – read associated password Generate key Generate a cryptographic key Client keys – write; PKEK – write. Modify key meta data Change the key owner or update/add/delete None the custom attributes Delete key Delete a cryptographic key Client keys – delete; PKEK – delete. Query key meta data Output key names
Summary of the content on the page No. 14
Security Policy, version 1.0 January 31, 2008 Service Description Keys/CSPs Zeroize all keys/CSPs Zeroize all keys/CSPs in the module All keys/CSPs – delete 2.4.4 Cluster Member Role The Cluster Member role is associated with other SKMs that can connect to this SKM and access cluster services. See Table 9 – Cluster Member Services. The keys and CSPs in the rightmost column correspond to the keys and CSPs introduced in Section 2.7.1. Table 9 – Cluster Member Services Service Description
Summary of the content on the page No. 15
Security Policy, version 1.0 January 31, 2008 -5 -8 in 60 seconds. Since 10 » 6×60 , the probability of a successful password attempt in 60 seconds is considerably -5 less than 10 . 2.4.6 Unauthenticated Services The following services do not require authentication: • SNMP statistics • FIPS status services • Health check services • Network Time Protocol (NTP) services • Initiation of self-tests by rebooting the SKM • Negotiation of the XML protocol version for communications with
Summary of the content on the page No. 16
Security Policy, version 1.0 January 31, 2008 Key Key Type Generation / Input Output Storage Zeroization Use DH 1024-bit Diffie- Generated by ANSI In In volatile Upon session Negotiate SSH public Hellman public X9.31 DRNG during plaintext memory termination Ks and SSH param parameters session initialization Khmac DH 1024-bit Diffie- Generated by ANSI Never In volatile Upon session Negotiate SSH private Hellman private X9.31 DRNG during memory termination Ks and SSH param parameters ses
Summary of the content on the page No. 17
Security Policy, version 1.0 January 31, 2008 Generation / Key Key Type Output Storage Zeroization Use Input KRsaPub Server RSA public Generated by In plaintext In non- At operator Client encrypts key (1024- or 2048- ANSI X9.31 a X509 volatile delete request Pre-MS. Client bit) DRNG during certificate. memory verifies server first-time signatures initialization KRsaPriv Server RSA private Generated by Never In non- At operator Server key (1024- or 2048- ANSI X9.31 volatile delete or
Summary of the content on the page No. 18
Security Policy, version 1.0 January 31, 2008 Generation / Key Key Type Output Storage Zeroization Use Input Client AES 128, 192 or Generated by Via TLS in Encrypted in Per client’s Encrypt key 256-bit AES ANSI X9.31 encrypted form non-volatile request or zeroize plaintexts/decrypt key DRNG (encrypted with memory request ciphertexts TLS Ks) per client’s request Client 3DES key Generated by Via TLS in Encrypted in Per client’s Encrypt 3DES key ANSI X9.31 encrypted form non-volatile re
Summary of the content on the page No. 19
Security Policy, version 1.0 January 31, 2008 Generation / Key Key Type Output Storage Zeroization Use Input Log signing 1024-bit RSA Generated by Never In non-volatile When new log Sign logs and keys public and ANSI X9.31 memory signing keys are verify signature private keys DRNG at first- generated on on logs time demand by initialization Crypto Officer ANSI X9.31 DRNG seed Generated by Never In non-volatile When module is Initialize ANSI DRNG non-Approved memory powered off X9.31
Summary of the content on the page No. 20
Security Policy, version 1.0 January 31, 2008 • Pairwise consistency test for new DSA keys • Pairwise consistency test for new RSA keys • Continuous random number generator test on ANSI X9.31 DRNG • Continuous random number generator test on non-Approved RNG • Firmware upgrade integrity test • Diffie-Hellman primitive test The module has two error states: a Soft Error state and a Fatal Error state. When one or more power-up self-tests fail, the module may enter either the Fatal Err
