Decru DataFort TM SAN SEP v2.0 HW PN/Rev: 60-000191/A, 60-000337/A FW PN: dcch2_4_2_10_secure SW PN: 27.8 Security Policy August 27, 2007 DocID: 15231-r4-9 Copyright 2007, Decru, Inc. May be reproduced in its entirety. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 2 of 33 Changes: Revision Change Description r4-6 Section 3.3.8 reworded rule 15p r4-7 Sec 3.3, Table 3.3 Recover Recovery Policy Key - added RO.SSEK r4-7 Sec 3.3, Table 3.3 Secret Share Recover Policy Key ­ added RO.SSEK and removed SEP.PK r4-7 Sec 3.3, Table 3.3 OTP ­ added RO.SSAK r4-7 Sec 3.8 rule 12b replaced System user with operator r4-8 Sec 3.3 Enter CLU.AKS -- deleted SEP.PK r4-8 Sec 3.3 Enter Data Domain Key -- deleted SEP.PK r4-8 Sec 3.3 Enter Master Key -- changed SEP.SKS to Sys.SKS r4-8 Sec 3.3 Enter Sys.AKS -- changed SEP.SKS to Sys.SKS r4-8 Sec 3.3 Output CLU.AKS -- deleted SEP.PK r4-8 Sec 3.3 Output Master key -- changed SEP.ModDK to SEP.IK and SEP.SKS to Sys.SKS r4-8 Sec 3.3 Receive CLU.AKS -- Added SEP.PK r4-8 Sec 3.3 Zeroize: updated to specify whether all CSPs, or only those in RAM are to be destroyed. r4-8 Sec 3.7changed strength of ECCDH from 260 bits to 256 bits r4-8 Sec 3.8 Capitalization of roles r4-9 Sec 1.2.1 updated 'SEP as certified' to 'SEP as validated' r4-9 Sec 3.8 rule 16. Added ­ In which case, cryptographic operations stop during the error state. r4-9 Sec 3.3 updated Enter Recovery Key Set to include SEP.ModDK r4-9 Sec 3.3 updated Tamper Notification to include SEP.BK, SEP.IK, SEP.PK, Sys.AKS. r4-9 Reviewed all of the questions. Non-typo fixes consisted of rewording the references to the sys.SKS channel, to clarify the CSP accesses and provide a more uniform description. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 3 of 33 Table of Contents 1 Introduction..................................................................................................................... 5 1.1 Purpose of the Crypto Module................................................................................................................ 5 1.2 Physical Embodiment............................................................................................................................ 6 2 Identification and Authentication Policy......................................................................... 10 2.1 The System User Identity..................................................................................................................... 10 2.2 Cluster Officer Identity......................................................................................................................... 11 2.3 Decru Identity....................................................................................................................................... 11 2.4 Strength of Authentication.................................................................................................................. 12 3 Access Control Policy...................................................................................................... 13 3.1 Roles..................................................................................................................................................... 13 3.2 Services and role access rights............................................................................................................. 15 3.3 Keys and CSP Access Rights................................................................................................................ 20 3.4 CSPs..................................................................................................................................................... 23 3.5 Public Keys and public nonces............................................................................................................ 25 3.6 FIPS Approved Crypto Algorithm Engines......................................................................................... 25 3.7 Non-approved Crypto Algorithm Engines.......................................................................................... 26 3.8 Security Rules...................................................................................................................................... 27 4 Physical Security............................................................................................................ 30 5 Mitigation of Other Attacks............................................................................................. 31 6 Definitions and Acronyms............................................................................................... 31 7 References...................................................................................................................... 33 Decru DataFortTM SEP Security Policy 15231-r4-9 Page 4 of 33 Index of Tables Table 1.1: Interface Classification..................................................................................................................... 8 Table 1.2: Security Level................................................................................................................................... 8 Table 2.1: Roles and Required Identification and Authentication................................................................. 10 Table 2.2: Strengths of Authentication Mechanisms...................................................................................... 12 Table 3.1: Roles................................................................................................................................................ 13 Table 3.2: Services Authorized for Roles........................................................................................................ 15 Table 3.3: Access Rights within Services........................................................................................................ 20 Table 3.4: Cryptographic Keys and CSPs....................................................................................................... 23 Table 3.5: Public Keys and Nonces................................................................................................................. 25 Table 3.6: Approved cryptographic algorithm implementations................................................................... 25 Table 3.7: Non-Approved Algorithms............................................................................................................ 26 Table 4.1: Inspection/Testing of physical security mechanisms................................................................... 30 Table 5.1: Mitigation of other attacks............................................................................................................. 31 Decru DataFortTM SEP Security Policy 15231-r4-9 Page 5 of 33 1 INTRODUCTION The Decru DataFortTM SAN SEP v2.0 is a multi-chip embedded module that is the main cryptographic service provider for Decru DataFort storage encryption product. Decru DataFort is an appliance that intercepts data sent between a client machine and storage device; DataFort transparently encrypts data sent to storage, and decrypts data served to the client. Software running on the DataFort platform manages encrypted keys, performs client authentication, access control, and requests cryptographic services from the SEP. 1.1 Purpose of the Crypto Module The purpose of the SEP is to support the security functional requirements of the Decru DataFort. These are summarized below: · Encrypt/decrypt client data using a hardware AES-256 ECB engine. · Generate keys from an Approved FIPS 186-2 change notice 1 Appendix 3.1 Deterministic RNG system that includes a commercial "true" random number generator for seeding. · Establish keys using commercially available key establishment protocols as allowed by FIPS PUB 140-2 Annex D. · The SEP physically protects plaintext cryptographic keys and CSPs with FIPS 140-2 level 3 physical security requirements. · The DataFort platform contains a chassis intrusion detector that can force SEP zeroization (c.f. "Tamper Notification" service). · Authentication and role enforcement, allowing the platform ("System User") to escalate or de- escalate privileges depending on the amount of key material provided to it. In particular, key access rights are restricted, depending on the role that the platform is in. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 6 of 33 1.2 Physical Embodiment The SEP is embedded into the Decru Crypto Card (DCC) and the SEP cryptographic boundary is defined as the outer perimeter of the potted portion of the printed circuit board. The DCC is a PCI Card conformant to the PCI bus 2.0 and PCI-X standards. The DCC also contains additional (non cryptographic) hardware components that are outside of the physically contiguous cryptographic boundary. These components serve as custom add ons for the DataFort platform (for example, battery backed RAM) outside of the cryptographic boundary. Figure 1 and Figure 2 depict the primary and secondary sides of the DCC including the SEP cryptographic module. The SEP is the potted portion of the card included within the (superimposed) dotted red border. Note that the DCC contains other components that are outside of the cryptographic boundary. Figure 1: DCC (including SEP module) primary side Figure 2: DCC (including SEP module) secondary side Decru DataFortTM SEP Security Policy 15231-r4-9 Page 7 of 33 1.2.1 Crypto Module Configuration The SEP as validated has the following configuration: HW PN/Rev: 60-000191/A 60-000337/A FW PN: dcch2_4_2_10_secure SW PN: 27.8 The module is labeled with its configuration in two ways: · The HW PN/Rev is visible from a label attached to the module. Moreover, the HW PN/Rev, FW PN, and SW PN are reported by the module on every boot via the status output interface. · DataFort platform administrators can issue the "sys ver" CLI command to obtain all part numbers, or they can obtain this information from the WebUI as well. Please consult the Decru DataFort Administration Guide for more information about administrative interfaces. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 8 of 33 1.2.2 Ports and Interfaces The following table maps the module's physical ports to the FIPS interface classification. Table 1.1: Interface Classification Physical Port(s) FIPS Interface(s) PCI Status Output, Control Input, Data Input, Data Output Power PCI-X Data Input/Output DDR bus Data Input, Data Output LCD line Data Input, Data Output Tamper line Control Input I2C Control Input, Data Output LED bus Data Output TestPoint bus Control Input, Status Output Voltage bus Control Input Backup power Power Security Level The SEP meets the overall requirements applicable to Level 3 security of FIPS PUB 140-2. The following table lists the compliance level of each section: Table 1.2: Security Level Security Requirements Section Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Decru DataFortTM SEP Security Policy 15231-r4-9 Page 9 of 33 Security Requirements Section Level Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of other attacks N/A Decru DataFortTM SEP Security Policy 15231-r4-9 Page 10 of 33 2 IDENTIFICATION AND AUTHENTICATION POLICY The SEP supports five authenticated operator roles, listed in Table 2.1. Table 2.1: Roles and Required Identification and Authentication Type of Identity Role Authentication Data Authentication System User User Identity-based Message authentication key (20 octet Identity operator HMAC-SHA-1) used in an AKEP2 Primary authentication protocol Cryptographic Officer Recovery Identity-based Message authentication key (20 octet Officer operator HMAC-SHA-1) used in an AKEP2 authentication protocol AND secret share key RO.SSAK(32 octet AES- 256) used in an OTP (one time password) protocol. Cluster Cluster Officer Identity-based Message authentication key (20 octet Officer operator HMAC-SHA-1) used in an AKEP2 Identity authentication protocol Decru Upgrade Identity-based ECC-521 ECDSA signature verification Identity Firmware operator key, authentication AND the ECDSA signature (using SHA-512) of a firmware upgrade package 2.1 The System User Identity The System User corresponds to the entity controlling the DataFort platform in which the DCC (with embedded module) is inserted. The System User assumes the roles of User, Primary Cryptographic Officer, and Recovery Officer. There may be only a single System User per module with each role corresponding to an escalation of privileges. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 11 of 33 When the module first boots, no operators are authenticated. The System User must authenticate to the module via an AKEP2 protocol. Successful authentication places this operator into the Primary Cryptographic Officer role and also establishes a secure channel to the SEP. The System User is considered to be in the Primary Crypto Officer role as long as the secure channel is open (i.e. The session key material is in the module). While the secure channel is open, the System User may elect to escalate privileges to the Recovery Officer Role by completing the OTP (One Time Password) service, or the System User may elect to reduce privileges by assuming the User role (accomplished by closing the secure channel). 2.2 Cluster Officer Identity The SEP supports up to 31 Cluster Officers. Each Cluster Officer is identified by a unique ID and an HMAC-SHA-1 authentication key. Cluster officer authentication is through the commercially available AKEP2 protocol. Cluster Officers are remote operators of the module, and correspond to remote SEPs with which the module may share bulk encryption keys. The module supports only a single concurrent Cluster Officer login. Successful authentication of a second Cluster Officer automatically logs out the previous Cluster Officer. When a Cluster Officer is logged into the module, the module is in a state of two concurrent operators (System User and Cluster Officer). The module differentiates between the remote and local operator by providing distinct services to each, issued through separate interfaces. Cluster Officer services are provided through a secure channel with the Cluster Officer encrypted with the platform key . Cluster Officers may not log into the module unless the platform is in authenticated state (i.e. the System User is in one of the three authenticated roles.) If the System user logs out of the module, any remote Cluster Officer is also logged out by the module. 2.3 Decru Identity The Decru identity is authorized to assume the Upgrade Firmware Role. Decru's identity is bound to an ECC-521 key pair, used for ECDSA signatures. The verification key is embedded in the module, and the Decru identity is authenticated via an ECDSA signature verification process, which is part of the upgrade service. Requesting the upgrade service places the SEP in a special state, during which no other authenticated users may access the module. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 12 of 33 2.4 Strength of Authentication Table 2.2 summarizes the strengths of the authentication and authorization protocols. Table 2.2: Strengths of Authentication Mechanisms Mechanism Strength of Mechanism AKEP2 The odds of successful random authentication are 1 in 2^80. The odds of successful authentication after multiple random attempts in one minute are less than one in 2^66. AKEP2 + OTP The odds of successful random authorization attempts are less than 1 in 2^256. The odds of successful authorization after multiple random attempts in one minute are less than one in 2^242. Firmware signature verification The odds of a successful random authentication is less (SHA-512/ECDSA) than 1 in 2^256. The odds of successful authentication after multiple random attempts in one minute are less than 1 in 2^253. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 13 of 33 3 ACCESS CONTROL POLICY 3.1 Roles Table 3.1: Roles Role Description Recovery Officer Role The main services available to the Recovery Officer role are: · request that key data be backed up and exported via a secret sharing process · Load (previously backed up) key material into the module · Load Cluster Officer authentication key material into the module · establish a key transfer channel, or "link" corresponding to a specially typed Domain Key (Link Domain Key). This key may be used to wrap and unwrap shareable Cryptainer Keys, allowing, for example, two SEPs to share a specific Cryptainer Key, without being in a cluster (and consequently sharing all Cryptainer Keys.) Primary Cryptographic The Primary Cryptographic Officer manages one type of wrapping key (the Officer Role "Domain Keys") used to protect client data encryption keys ("Cryptainer Keys".) The Primary Cryptographic Officer may load and unload Domain Keys, and request that the module generate Master Keys. Additionally, the Primary Cryptographic Officer may create and delete Cluster Officer accounts by requesting the "add/remove Cluster Officer" service. The Primary Cryptographic Officer may directly access RNG output, and load authentication key data into the module. Finally, the Primary Cryptographic Officer may perform all services available to the user and to the unauthenticated platform user. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 14 of 33 Role Description User Role The user may load and store key context items, request that the module generate key context items, and encrypt/decrypt client data. A key context is the set of parameters required to encrypt and decrypt client data. It consists of a data encryption key ("Cryptainer Key"), and non-security relevant items (a block identifier, and two R-strings). The module stores a single key context at any time. Therefore the user is allowed to load and store key context items into the module, and then load data into the module, requesting encryption/decryption with the current key context. The user does not have access to plaintext Cryptainer Keys, nor to R- strings. These are loaded and stored in encrypted form. A wrapping key and an unwrapping key must first be loaded by a cryptographic officer. Cluster Officer Role The Cluster Officer may authenticate to the module and agree on a Cluster Key (this is a shared wrapping key). Authentication and key agreement is combined into a single service. Upgrade Firmware Role The Decru identity can perform the Upgrade service. The Upgrade service consists of loading a new firmware package into the SEP, which verifies the ECDSA signature on the package (external load test.) Authentication and firmware replacement are combined into a single service. This service ends in a mandatory reboot. No other cryptographic operations may be performed during the execution of this service. Unauthenticated System The unauthenticated system user represents the platform prior to User Role authentication (the untrusted platform). In practice, this role is accessed via the DataFort platform as part of its power on configuration of the module. Unauthenticated System User Role services do not disclose, modify, substitute CSPs or use Approved security functions. Services are made available prior to authentication for the following reasons: · The platform must configure the SEP during the module's power on process in order to communicate with the module (for example, the platform must assign memory addresses to the module's registers, exercise physical interfaces, and set an interrupt policy for the device.) · It is desirable to have a facility to zeroize key material in both the platform and the embedded module in any state. This is because the Decru platform features a chassis intrusion detector that may issue a tamper alert even when the module is in a low power state (in which no user is authenticated.) Decru DataFortTM SEP Security Policy 15231-r4-9 Page 15 of 33 3.2 Services and role access rights Table 3.2 gives a high level description of all services provided by the module and lists the roles allowed to invoke each service. Because the module is controlled by a low level driver interface, most services encapsulate a set of commands. The following abbreviations are used for roles: U ­ Unauthenticated System User role RO ­ Recovery Officer role AU ­ User role ClO ­ Cluster Officer role CrO ­ Primary Cryptographic Officer role FU ­ Firmware Upgrade role Table 3.2: Services Authorized for Roles U AU CrO RO ClO FU Service Name Service Description X X X Authenticate Performs an AKEP2 protocol with the System User operator. This service may also be used to re-authenticate the System User in order to transition from User role to Primary Cryptographic Officer role. X X X Configure module This service is performed every boot, and sets the register address spaces, interrupt policy, latency settings, and other PCI bus configuration parameters X X X Logout all users zeroizes all CSPs in the module's RAM, and logs out all users X X X Perform power on Performed automatically as a result of self-tests booting the device. X X X Read/write to The operator may read from any flash flash address, and may write to allowed flash addresses. X X X Read/write to The module provides a battery-backed, SDRAM physically protected RAM store for the platform's use. The platform may access this store at any time ­ no cryptographic processing occurs through this interface. X X X Reset Allows the operator to reset a user-specified number of the module's internal states to their initial value. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 16 of 33 U AU CrO RO ClO FU Service Name Service Description X X X Show status This service corresponds to a suite of commands which return the module's status: · the value of the module's internal state machines · PCI status register values X X X Tamper The operator may issue a tamper alert to the Notification SEP with this service. The alert results in a zeroization and logout of all operators. X X X Zeroize The operator may specify whether all CSPs, or only those in RAM are to be destroyed. X X X Authenticate Performs an AKEP2 protocol with the Cluster Officer Cluster Identity. The service may only be invoked by one of the three authenticated System User roles. Note that Cluster Officer authentication is revoked if the System User transitions to the unauthenticated role. X X Decrypt data The module imports ciphertext client data from the operator, and decrypts the data with the AES-256 ECB using the currently loaded key context. The module outputs the plaintext. X X Disable user Suspends user data encryption and services decryption. X X Encrypt data The module imports plaintext client data from the operator, and encrypts the data with the AES-256 ECB using the currently loaded key context. The module outputs the ciphertext. X X Enter Data The operator loads an encrypted Data Domain Key Domain Key into the module. The Data Domain Key may only be used for encrypting Key Context items. X X Enter Key Context The module loads key context item(s) into item the Key Unit. The Cryptainer Key must be wrapped with a Data Domain Key. X X Enter Link Key The operator loads an encrypted link key into the module, allowing the module to output exportable Cryptainer Keys by wrapping them with the link key. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 17 of 33 U AU CrO RO ClO FU Service Name Service Description X X Fill SEP FIFO The platform must ensure that the SEP has sufficient PRNG input stored in its FIFO. No data is output and no keys are created as a result of this service. X X Generate Key The operator specifies the item(s) to be Context item generated. X X Output Data The module output an encrypted Data Domain Key Domain Key that is used to encrypt Cryptainer Keys or Link Keys. X X Output Key The module exports the current key Context item (encrypted) context item(s) to the operator. The operator specifies which entries are to be exported. The wrapping key must be loaded into the unit as a result of an "Enter Data Domain Key" or "Receive Data Domain Key from Cluster Officer" service invocation. X X Output Link Key The module outputs an encrypted key used to wrap exportable Cryptainer Keys. X Assume user role This command restricts the operator's privileges to only those available to the user or to the unauthenticated system user. If user services have not been enabled, then the operator is logged out of the unit. X Enable user This command enables user data encryption services and decryption. X Establish Platform The module establishes a platform key via Key the ECCDH protocol. X Enter CLU.AKS The operator loads the encrypted authentication data for Cluster Officers into the module, effectively signifying that the module may attempt to authenticate to the corresponding Cluster Officer user. X Enter Master Key The operator loads the Master Key encrypted with the Ignition Key into the module, through the secure channel. X Enter Module The operator loads the Module Domain Key Domain Key encrypted with the Recovery Policy Key into the unit. The Module Domain Key is used to encrypt module secrets, such as secret share keys. X Enter Recovery The operator loads the Recovery Policy Key Policy Key encrypted with the Master Key into the module. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 18 of 33 U AU CrO RO ClO FU Service Name Service Description X Enter Sys.AKS The operator enters new authentication key data into the module for use in authenticating the System User. The old AKS values are no longer used. X Establish Ignition The module establishes an ignition key and Key blade key via the ECCDH protocol. X Generate Domain The module generates a Domain Key Key (consisting of an encryption and HMAC component) together with an ID and type information. X Generate Initial The module generates initial authentication CLU.AKS key data for the AKEP2 protocol to be run with a Cluster Officer. X Generate Master The module generates a Master Key. If the Key Ignition Key and blade key are not already in the module, they are generated as a result of this command. No data is output. X Generate Recovery The module generates a Recovery Policy Policy Key Key, with the policy specified by the operator. The policies determine which interfaces may be used to import the key during a secret recovery operation. X Output CLU.AKS The module outputs an encrypted Cluster Officer authentication Key Set. X Output Master The module sends a Master Key to the Key operator through the secure channel. The key is wrapped with the SEP's ignition key. X Output Module The module outputs an encrypted Module Domain Key Domain Key that is used to encrypt module secrets. X Output random The module exports PRNG output to the value System User through the established secure channel encrypted with the Platform Key. X Output Recovery The module outputs an encrypted Recovery Policy Key Policy Key to the operator. X Receive CLU.AKS The module receives a CLU.AKS replacement from a Cluster Officer, through the channel with the officer encrypted with the Platform Key. X Secret Share The module subdivides an internally stored Recovery Policy Recovery Policy Key into secret shares with a Key specified recovery threshold, encrypts the shares, and exports them to the operator. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 19 of 33 U AU CrO RO ClO FU Service Name Service Description X Send CLU.AKS The module sends the CLU.AKS key to a Cluster Officer by encrypting it with the Platform Key. X Set Crypto Shred The operator specifies the type of CSPs that Mode are zeroized as part of the tamper notification service. X Set Quorum The operator specifies the requirements for a Requirements quorum (secret recovery threshold). X Enter Recovery The operator loads the encrypted Recovery Key Set Key set into the module. Two interfaces are available for this key load: the recovery key set may be encrypted with the SEP.PK and loaded through a channel based on Sys.SKS, or the recovery key set may be encrypted and authenticated with the SEP.ModDK. X Assume Crypto Transitions the System User from Recovery Officer role Officer role to Primary Cryptographic Officer role. X Establish Link Key The module performs an ECCDH key agreement protocol with data supplied by the operator to establish a link key. X OTP The module attempts to authenticate the operator (in Primary Cryptographic Officer role) with a One Time Password protocol. Successful completion of the OTP protocol places the operator in Recovery Officer role. X Recover Recovery The operator loads secret shares containing Policy Key the Recovery Policy Key into the SEP. The shares are encrypted with secret share key RO.SSEK. The module reconstructs the Recovery Policy Key. X Receive Data The module imports the Data Domain Key Domain Key from with a Cluster Officer, encrypted with the Cluster Officer Platform Key. Data Domain Key is used to encrypt client data, not module secrets. X Receive Module The module imports the Module Domain Domain Key from Key encrypted with Platform Key from a Cluster Officer Cluster Officer. X Send Data The module sends the Data Domain Key Domain Key to encrypted with Platform Key to a Cluster Cluster Officer Officer. X Send Module The module sends the Module Domain Key Domain Key to encrypted with the Platform Key to a Cluster Cluster Officer Officer. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 20 of 33 U AU CrO RO ClO FU Service Name Service Description X Upgrade Loads new firmware into the module. This service includes performing the external load test. 3.3 Keys and CSP Access Rights Table 3.3 defines the relationship between services and CSP accesses. The following access mode abbreviations are used: READ ­ the item is read by the service WRITE ­ the item is written or updated by the service (including zeroization) EXECUTE ­ the item is used as part of a cryptographic function by the service Table 3.3: Access Rights within Services Service Description Keys and CSPs Access Type(s) Assume Crypto Clear the OTP nonce OTP.N W Officer role Assume User role Logout the System User by clearing the Sys.SKS W System User session key set. Authenticate Cluster Clu.AKS is used for authentication of the Clu.AKS E Officer Cluster Officer and establishment of the Clu.SKS (session key set). AKEP2.DH1 is AKEP2.DH1 WE an ephemeral parameter to the Clu.SKS W operation. Authenticate System Sys.AKS is used for authentication of the Sys.AKS E User System User and establishment of the Sys.SKS (session key set). AKEP2.DH1 is AKEP2.DH1 WE an ephemeral parameter to the Sys.SKS W operation. Decrypt data User data is decrypted with SEP.CK SEP.CK E Encrypt data User data is encrypted with SEP.CK SEP.CK E Establish Platform SEP.PK is established based on SEP.ECCDHSecret E Key SEP.ECCDHSecret SEP.PK W Enter CLU.AKS Clu.AKS is verified and decrypted with SEP.ModDK E SEP.ModDK Clu.AKS W Decru DataFortTM SEP Security Policy 15231-r4-9 Page 21 of 33 Service Description Keys and CSPs Access Type(s) Enter Data Domain SEP.DataDK is verified and decrypted SEP.RPK E Key with SEP.RPK SEP.DataDK W Enter Key Context SEP.CK is verified and decrypted with SEP.DataDK E item SEP.DataDK SEP.CK W Enter Link Key SEP.LK is verified and decrypted with SEP.ModDK E SEP.ModDK SEP.LK W Enter Master Key SEP.MK is verified and decrypted with SEP.IK E SEP.IK. This service is executed through Sys.SKS E the Sys.SKS channel. SEP.MK W Enter Module SEP.ModDK is verified and decrypted SEP.RPK E Domain Key with SEP.RPK SEP.ModDK W Enter Recovery SEP.RPK is verified and decrypted with SEP.MK E Policy Key SEP.MK SEP.RPK W Enter Sys.AKS SEP.AKS is decrypted with SEP.PK. This SEP.PK E service is executed through the Sys.SKS Sys.SKS E channel. Sys.AKS W Establish Ignition SEP.IK is established based on SEP.ECCDHSecret E Key SEP.ECCDHSecret SEP.BK E SEP.IK W Establish Link Key Link key is established based on SEP.ECCDHSecret E SEP.ECCDHSecret SEP.BK E SEP.LK W Generate Data Generation from PRNG output SEP.DataDK W Domain Key Generate Initial Generation from PRNG output Clu.AKS W CLU.AKS Generate Key Context Generation from PRNG output SEP.CK W item Generate Master Key Generation from PRNG output SEP.MK W SEP.IK W Generate Module Generation from PRNG output SEP.ModDK W Domain Key Generate Recovery Generation from PRNG output SEP.RPK W Policy Key Logout all users Zeroize all runtime CSPs (see Table 3.4) All run-time CSPs W Decru DataFortTM SEP Security Policy 15231-r4-9 Page 22 of 33 Service Description Keys and CSPs Access Type(s) OTP Run One Time Password protocol. The OTP.N RWE RO.SSAK key is used to encrypt the RO.SSAK E challenge. The response data to this service is sent through the Sys.SKS Sys.SKS E channel. Output CLU.AKS Clu.AKS is encrypted and authenticated Clu.AKS R with SEP.ModDK SEP.ModDK E Output Data Domain SEP.DataDK is encrypted and SEP.RPK E Key authenticated with SEP.RPK SEP.DataDK R Output Key Context SEP.CK is encrypted and authenticated SEP.DataDK E item with SEP.DataDK SEP.CK R Output Link Key SEP.LK is encrypted and authenticated SEP.ModDK E with SEP.ModDK SEP.LK R Output Master Key SEP.MK is encrypted and authenticated SEP.IK E with SEP.IK, and output through the Sys.SKS E Sys.SKS channel. SEP.MK R Output Module SEP.ModDK is encrypted and signed SEP.RPK E Domain Key with SEP.RPK SEP.ModDK R Output random value PRNG output is output via the Sys.SKS Sys.SKS E channel. Output Recovery SEP.RPK is encrypted and signed with SEP.MK E Policy Key SEP.MK SEP.RPK R Receive CLU.AKS Clu.AKS is decrypted with the SEP.PK. Clu.SKS E The service is executed through the SEP.PK E Clu.SKS channel. Clu.AKS W Receive Data Domain SEP.DataDK is decrypted with the Clu.SKS E Key from Cluster SEP.PK. The service is executed through SEP.PK E Officer the Clu.SKS channel. SEP.DataDK W Receive Module SEP.ModDK is decrypted with the Clu.SKS E Domain Key from SEP.PK. The service is executed through SEP.PK E Cluster Officer the Clu.SKS channel. SEP.ModDK W Recover Recovery SEP.RPK is entered into the module RO.SSEK E Policy Key encrypted with RO.SSEK. SEP.RPK W Secret Share SEP.RPK is encrypted with RO.SSEK RO.SSEK E Recovery Policy Key SEP.RPK R Decru DataFortTM SEP Security Policy 15231-r4-9 Page 23 of 33 Service Description Keys and CSPs Access Type(s) Send CLU.AKS Clu.AKS is encrypted with the SEP.PK, Clu.SKS E and exported. This service is executed SEP.PK E through the Clu.SKS channel. Clu.AKS R Enter Recovery Key Loads, RO.SSEK and RO.SSAK, and SEP.PK R Set decrypts with the SEP.PK, executed Sys.SKS E through the Sys.SKS channel, or loads RO.SSEK and RO.SSAK decrypted and SEP.ModDK E verified with SEP.ModDK. RO.SSEK W RO.SSAK W Send Data Domain SEP.DataDK is encrypted with SEP.PK, Clu.SKS E Key to Cluster Officer and output through the Clu.SKS channel. SEP.PK E SEP.DataDK R Send Module Domain SEP.ModDK is encrypted with SEP.PK, Clu.SKS E Key to Cluster Officer and output through the Clu.SKS channel. SEP.PK E SEP.ModDK R Tamper Notification If crypto shred policy set to 2 or 3, * W zeroize all runtime CSPs (see Table 3.4). If crypto shred policy set to 1, zeroize all CSPs, except Decru.IDK, SEP.BK, SEP.IK, SEP.PK, Sys.AKS. Upgrade Decru signature on upgrade code Decru.pubKey E verified with Decru.pubKey Zeroize The operator may specify whether all * W CSPs, or only those in RAM are to be destroyed. 3.4 CSPs The following keys, cryptographic key components and other critical security parameters are contained in the module. Each CSP is assigned a row in Table 3.4. The following interpretation applies to the persistence column: persistent ­ the key/CSP persists until explicit zeroization runtime ­ the key/CSP persists until explicit zeroization or power-cycle ephemeral ­ the key/CSP is used for a single algorithm instance only (e.g. nonces) Decru DataFortTM SEP Security Policy 15231-r4-9 Page 24 of 33 Table 3.4: Cryptographic Keys and CSPs CSP Symbol CSP Name Lifetime Type Decru.IDK Decru Initial persistent Authentication key (20 octets), Derivation Key Key derivation key (60 octets) SEP.PK SEP Platform Key runtime AES-256, HMAC-SHA-256 SEP.IK SEP Ignition Key persistent AES-256, HMAC-SHA-256 SEP.BK SEP Blade Key persistent AES-256, HMAC-SHA-256 Sys.AKS System User persistent authentication key (20 octets), Authentication Key Set Key derivation key (60 bytes) Sys.SKS System User Session runtime AES-256, HMAC-SHA-1 Key Set 1 byte channel sequence number Clu.AKS Cluster User runtime HMAC-SHA-256 (40 octets), Authentication Key Set Key derivation key (40 octets) Clu.SKS Cluster User Session runtime AES-256, HMAC-SHA-256, Key Set 1 byte channel sequence number SEP.MK SEP Master Key runtime AES-256 (32 octets) HMAC-SHA-256 (32 octets) SEP.RPK SEP Recovery Policy runtime AES-256 (32 octets) Key HMAC-SHA-256 (32 octets) RO.SSEK Recovery Secret Share runtime AES-256 (32 octets) Encryption Key HMAC-SHA-1 (20 octets) RO.SSAK Recovery Secret Share runtime AES-256 (32 octets) Authorization Key HMAC-SHA-1 (20 octets) SEP.ModDK SEP Module Domain runtime AES-256 (32 octets) Key HMAC-SHA-256 (32 octets) SEP.DataDK SEP Data Domain Key runtime AES-256 (32 octets) HMAC-SHA-512 (32 octets) SEP.CK SEP Cryptainer Key runtime AES-256 (32 octets) HMAC-SHA-512 (32 octets) SEP.LK SEP Link Key runtime AES-256 (32 octets) HMAC-SHA-512 (32 octets) AKEP2.EDC AKEP2 Ephemeral ephemeral 20 octet key derivation component Derivation Key Component AKEP2.DH1 AKEP2 Diffie-Hellman ephemeral Diffie-Hellman private value used for group private key exponentiation (128 octets) SEP.ECCDHSecret ECC Diffie-Hellman ephemeral ECC-521 private key secret key OTP.N One Time Password ephemeral AES-256 (32 octets) (OTP) nonce HMAC-SHA-1 (20 octets) Decru DataFortTM SEP Security Policy 15231-r4-9 Page 25 of 33 3.5 Public Keys and public nonces The following table lists public keys and public nonces. Table 3.5: Public Keys and Nonces CSP Symbol CSP Name Lifetime Type Decru.PubKey Decru Public Key persistent ECC521 ECDSA verification public key AKEP2.N1 AKEP2 initiator ephemeral 20 octet nonce (when used with Sys.AKS) AKEP2.N2 /receiver nonce 32 octet nonce (when used with Clu.AKS) 3.6 FIPS Approved Crypto Algorithm Engines All approved crypto algorithm engines are assumed to implement critical security functions. Table 3.6: Approved cryptographic algorithm implementations Algorithm References Certificate(s) Implementation SHA-1 FIPS PUB 180-2 Cert #192 SHA-256 FIPS PUB 180-2 Cert #223 SHA-512 FIPS PUB 180-2 Cert #511 HMAC-SHA-1 FIPS PUB 198, uses SHA-1, Cert #192 Cert #210 HMAC-SHA-256 FIPS PUB 198, uses SHA-256, Cert #223 Cert #211 HMAC-SHA-512 FIPS PUB 198, uses SHA-512, Cert #511 Cert #212 AES-256-CBC FIPS PUB 197 Cert #446 AES-256-ECB FIPS PUB 197 Cert #445 ECDSA FIPS PUB 186-2, change notice 1, Appendix 6. Cert #35 PRNG FIPS PUB 186-2, change notice 1, Appendix 3.1. Cert #232 Decru DataFortTM SEP Security Policy 15231-r4-9 Page 26 of 33 3.7 Non-approved Crypto Algorithm Engines The following non-approved crypto algorithms and protocols are in the SEP Table 3.7: Non-Approved Algorithms Algorithm Comments Implementation TRNG Hardware random number generator. Only used as a seeding mechanism for the Approved RNG and never used to generate keys directly. AKEP2 protocol Authentication and Key agreement protocol, conformant to AKEP2. The protocol makes use of a SHA-1 based publicly known non- reversible function conformant to ANSI X9.63 and Diffie-Hellman conformant to ANSI X9.42-2003. The module only relies on this protocol for authentication, it does not use the protocol for key agreement. ECCDH ECC Diffie-Hellman key agreement protocol conformant to ANSI X9.63. The protocol makes use of the SHA-256 based key derivation function conformant to ANSI X9.63. The ECCDH protocol provides 256 bits of strength. This is a commercially available key agreement protocol as allowed under FIPS PUB 140-2 Annex D. Secret Sharing/ A threshold split knowledge scheme as defined in HAC. The scheme is Secret Recovery not relied upon to protect CSPs, as the output shares are encrypted prior to export with an approved security function (AES-256). KDF1 A supporting function for the AKEP2 protocol, conformant to to ANSI X9.63, and based on SHA-1. KDF2 A supporting function for the ECCDH protocol, conformant to to ANSI X9.63, and based on SHA-256. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 27 of 33 3.8 Security Rules This section describes the security rules that the module must enforce. The rules are structured according to FIPS PUB 140-2; the security rules enforce the module's conformance to each of the FIPS PUB requirements. The cryptographic module design corresponds to the following security rules: 1. The cryptographic module shall only support a FIPS mode of operation. The cryptographic module returns its version number through a status command to indicate the approved mode. 2. The SEP shall provide for six roles: Unauthenticated System User, User, upgrade firmware, Cluster Officer, Primary Cryptographic Officer, and Recovery Officer. For purposes of the standard, the last three roles are considered crypto officer roles. 3. The SEP shall support multiple operators that may each assume the Cluster Officer role. Only a single operator (the System User) may assume the User, Cryptographic Officer, and Recovery Officer roles. 4. The SEP shall provide for identity-based authentication. The module shall also provide for zeroization as an unauthenticated service, and other unauthenticated services that do not disclose, modify, or substitute CSPs or use Approved security functions. 5. The module shall track successful authentication by means of an internal state machine. This state machine controls which services may be performed by the module. The state machine is reset on power off, or as a result of a logout command. 6. The module's error states shall consist of soft and hard errors. On encountering soft errors, the module shall note the error and automatically exit the error state after rejecting the data that has been input or is being processed. On encountering a hard error, the module shall disable interfaces used for cryptographic processing, disable the relevant cryptographic engine, issue an error, and discard any data that has been processed during the error state. 7. The module shall not support a bypass or maintenance state. 8. The module shall generate CSPs from the output of a FIPS approved PRNG. This PRNG shall be continuously reseeded by a TRNG. Both the TRNG and the PRNG shall undergo a continuous RNG self-test (see Rule #16). 9. All CSPs and public keys within the module shall be protected by the physical security of the device. No CSP shall be output from or entered into the module in plaintext. 10. Only the System User may enter keys into the module. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 28 of 33 11. The module shall distinguish between module and user secrets: module secrets are defined as any of the following: a. authentication data associated to one of the supported roles b. session keys between the module and a user of the module c. secret share keys d. platform key e. any key in the key hierarchy that encrypts/signs one of the CSPs listed previously in a,b,c. user secrets are defined as any of the following: f. Encryption and signature Cryptainer Keys g. Those Domain Keys that are used to encrypt and sign Cryptainer Keys. 12. Module secrets may only be loaded into or out of the module when the operator is in one of the following roles: a. Primary Cryptographic Officer role b. Upgrade Firmware Role c. Recovery Officer role 13. The module shall distinguish between the key material it makes available to the System User in Primary Cryptographic Officer role and Recovery Officer role: a. In Primary Cryptographic Officer role, the module shall enforce a "black box" CSP access policy in which keys are not accessible to the System User in plaintext, given the key material exchanged by two parties (System User in Primary Cryptographic Officer role, SEP). b. In Recovery Officer role, the module shall export keys in a hierarchy, at the top of which are secret share keys, that are accessible to the System User in Recovery Officer role (as this user provided the secret share keys to the module). 14. All CSPs except for · authentication data between the module and the System User · The SEP's Ignition Key package · The upgrade firmware public key, Decru.PubKey shall be stored only in RAM and shall be zeroized as a result of the logout all users service. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 29 of 33 15. On power on, the SEP shall perform the following self-tests a. AES-256 KATs b. SHA-1 KAT c. SHA-256 KAT d. SHA-512 KAT e. KDF1 KAT f. HMAC-SHA-1 KAT g. KDF2 KAT h. HMAC-SHA-256 KAT i. HMAC-SHA-512 KAT j. Diffie-Hellman KAT k. ECCDH KAT l. ECDSA (signature verification only), SHA-512 KAT hash verification with Decru.PubKey m. PRNG KAT, in which the PRNG is initialized with a fixed seed value and internal state and the output of the PRNG is compared against a stored value. n. Software/firmware integrity tests o. Test to see if a tamper notice has been issued from the platform p. SHA-1 attached to keys stored in the EPROM shall be verified during the module's power on self-tests. 16. Subsequent to power on, both the TRNG and the PRNG shall perform the continuous RNG test. The TRNG shall store and compare 8 octets for the continuous test, and the PRNG shall store and compare 40 octets. Should a test fail, the module shall enter an error state during which no cryptographic operations can be performed, notify the operator of the error by writing to a status register, abandon all buffered RNG bits, and then exit the error state. 17. The module shall include an upgrade service, whereby new firmware is loaded into the SEP. In this case, the module shall perform an external load test, computing the SHA-512 hash of the entire upgrade package. The result of the hash shall be compared with the ECDSA signed hash provided by the Decru. If the signature is verified, and if the signed hash matches the hash computed by the module, then the module shall boot from the new firmware on subsequent power on. The cryptographic module shall not support the loading or execution of non-trusted code. Loading of any code that is properly signed with ECDSA, but not validated will invalidate the FIPS 140-2 validation. As such, the area 6 operational environment requirements are not applicable. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 30 of 33 18. Unless key material is loaded into the module through the secure channel from the System User, the module shall not contain sufficient key material to perform the encrypt data or decrypt data service. In particular, Cryptainer Keys may not be compromised as a result of compromising the physical security of a powered off module. 19. Prior to initialization, the module shall allow only the System User to authenticate using ephemeral and default key material. During this session, the only allowed services are: a. services available to the unauthenticated user b. Output random value (in order to reseed the PRNG of the System User) c. Enter Sys.AKS (in order to change to a local AKS). d. Fill SEP FIFO Thereafter, the System User must shut down the session and re-authenticate with the new AKS in order to access the full set of services. Prior to the AKS change, Cluster Officers and Recovery Officers may not authenticate to the module. 4 PHYSICAL SECURITY The SEP is protected with a hard, opaque tamper evident epoxy coating. With high probability, removal of this coating will destroy the underlying circuitry. Table 4.1: Inspection/Testing of physical security mechanisms Physical Recommended Inspection/Test Guidance Details Security Frequency of Mechanisms Inspection/Test Hard opaque Upon installation of device Thoroughly inspect the cryptographic module for tamper evident within the host system. any signs of tamper including scratches, gouges and epoxy. other suspicious marks on the potting. The device is to be physically destroyed in the event that tamper evidence is noted. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 31 of 33 5 MITIGATION OF OTHER ATTACKS No claims are made about the mitigation of other attacks outside of the scope of FIPS 140-2. Table 5.1: Mitigation of other attacks Other Attacks Mitigation Mechanism Specific Limitations N/A N/A N/A 6 DEFINITIONS AND ACRONYMS AKEP2 Authentication and Key Exchange Protocol, (version) 2. The module uses AKEP2 for authentication, it does not use AKEP2 for key agreement. Authentication Key A key derivation key, together with an authentication key. The authentication Set (AKS) key is used in an AKEP2 protocol, and on success, the key derivation key is used to derive a session key set. This module only uses AKEP2 for authentication, it does not use AKEP2 for key agreement. Client Refers to an initiator device in a network storage protocol such as NFS. client data Data belonging to a client (that may be stored on a remote server). cluster A set of DataFort appliances that share data encryption keys in order to provide failover and load balancing. Cryptainer Key The key package used to encrypt and sign client data DataFort The DataFort platform, with the DCC inserted. The DataFort platform is marketed as a hardware encryption and authenticated device. The SEP is the primary cryptographic service provider for the DataFort. DataFort platform Also called "platform". A computer (CPU, memory, motherboard) in which the DCC may be inserted. There is a unique platform per SEP. The platform serves as the primary SEP operator ("System User"). DCC Decru Crypto Card ­ a PCI card that houses the SEP together with non cryptographic components such as DDRAM, a battery charger, etc. Domain Key A key package used to encrypt and sign CSPs such as Cryptainer Keys. Decru DataFortTM SEP Security Policy 15231-r4-9 Page 32 of 33 Ignition Key A key package used to encrypt and sign the Master Key prior to exporting it to the System User. Link Key A key package that is used to encrypt and sign certain exportable Cryptainer Keys. Master Key A key package used to encrypt and sign Recovery Policy Keys. Platform The section of the DataFort appliance that is outside of the SEP. quorum The minimum number of secret shares required to reconstitute the secret that is being shared. Sometimes referred to as a threshold. Recovery Officer A System User role that is allowed to recover key material, establish link keys, and establish trust between Cluster Officers. Recovery Policy Key A key package used to encrypt and sign Domain Keys. secret share key A key package used to encrypt and sign certain Recovery Policy Keys. SEP Storage Encryption Processor. The SEP is a multi-chip embedded module whose primary purpose is hardware encryption of data. Session Key Set A wrapping key, together with an initial chaining value System User Refers to the host machine i.e. DataFort platform. Wrapping Key A key consisting of an encryption and an HMAC signature component (i.e. two distinct keys) Decru DataFortTM SEP Security Policy 15231-r4-9 Page 33 of 33 7 REFERENCES AKEP2 M. Bellare and P. Rogaway. Entity Authentication and Key Distribution. Advances in Cryptology - CRYPTO 93, Lecture Notes in Computer Science Vol. 773, D. Stinson, ed., Springer-Verlag, 1994. Available at http://www.cs.ucsd.edu/users/mihir/papers/key-distribution.html ANSI X9.42 ANSI X9.42-2003. Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography. 2003. Section 7.5.1. ANSI X9.63 ANSI X9.63-2001. Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography. 2001. Section 5.6.3. FIPS PUB 140-2 Security Requirements for Cryptographic Modules, 2001 May 25, Change Notice 4, 2002 Dec 03. FIPS PUB 180-2 Secure Hash Standard (SHS), 2002 August FIPS PUB 186-2 Digital Signature Standard (DSS), 2000 January 27. Change Notice 1, 2001 October 5. FIPS PUB 197 Advanced Encryption Standard (AES), 2001 November 26 FIPS PUB 198 The Keyed-Hash Message Authentication Code (HMAC), 2002 March HAC Handbook of Applied Cryptography. Alfred J. Menezes, Paul C. Van Oorschot, Scott A. Vanston. CRC Press, August 2001. Section 12.7.2.