LEVEL 3 NON-PROPRIETARY SECURITY POLICY FOR Lunaź PCI-E Cryptographic Module and Lunaź PCI-E Cryptographic Module for Lunaź SA (Used as a Standalone Device that includes configurations Cloning [CL] and Key Export [CKE]; and as an Embedded Device in Lunaź SA that includes configurations Cloning [CL], Signing No Cloning [SNC], and Key Export [CKE]) DOCUMENT NUMBER: CR-3397 REVISION LEVEL: 21 REVISION DATE: November 16, 2015 SECURITY LEVEL: Non-proprietary © Copyright 2011-2015 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-3397 Revision Level: 21 PREFACE This document deals only with operations and capabilities of the Lunaź PCI-E Cryptographic Module and Lunaź PCI-E Cryptographic Module for Lunaź SA in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the Luna PCI-E 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. For answers to technical or sales related questions please refer to the contacts listed below or on the SafeNet internet site at http://www.safenet-inc.com/contact-us/. SafeNet Contact Information: SafeNet, Inc. (Corporate Headquarters) 4690 Millennium Drive Belcamp, MD 21017 Telephone: 410-931-7500 TTY Users: 800-735-2258 Fax: 410-931-7524 SafeNet Canada, Inc. 20 Colonnade Road Suite 200 Ottawa, Ontario K2E 7M6 Telephone: +1 613 723 5077 Fax: +1 613 723 5079 SafeNet Sales: 800-533-3958 SafeNet Technical Support: U.S. 800-545-6608 International 410-931-7520 SafeNet Customer Service: U.S. 866-251-4269 EMEA +44 (0) 1276 60 80 00 APAC 852 3157 7111 Document is Uncontrolled When Printed. Page 2 of 46 CR-3397 Revision Level: 21 TABLE OF CONTENTS Section Title Page 1. INTRODUCTION ..................................................................................................................................... 6 1.1 Purpose ............................................................................................................................................ 6 1.2 Scope ............................................................................................................................................... 6 1.3 Overview .......................................................................................................................................... 7 2. SECURITY POLICY MODEL INTRODUCTION ..................................................................................... 7 2.1 Functional Overview ......................................................................................................................... 7 2.2 Assets to be Protected ..................................................................................................................... 9 2.3 Operating Environment .................................................................................................................... 9 3. SECURITY POLICY MODEL DESCRIPTION ........................................................................................ 9 3.1 Operational Policy .......................................................................................................................... 10 3.1.1 Module Capabilities................................................................................................................. 10 3.1.2 Partition Capabilities ............................................................................................................... 11 3.2 FIPS-Approved Mode ..................................................................................................................... 18 3.3 Description of Operator, Subject and Object ................................................................................. 18 3.3.1 Operator .................................................................................................................................. 18 3.3.2 Roles ....................................................................................................................................... 18 3.3.3 Account Data .......................................................................................................................... 19 3.3.4 Subject .................................................................................................................................... 20 3.3.5 Operator ­ Subject Binding ..................................................................................................... 20 3.3.6 Object ...................................................................................................................................... 20 3.3.7 Object Operations ................................................................................................................... 21 3.4 Identification and Authentication .................................................................................................... 21 3.4.1 Authentication Data Generation and Entry ............................................................................. 21 3.4.2 Trusted Path ........................................................................................................................... 22 3.4.2.1. Remote PED Operation ................................................................................................... 22 3.4.3 M of N Authentication.............................................................................................................. 23 3.4.4 Limits on Login Failures .......................................................................................................... 23 3.5 Access Control ............................................................................................................................... 24 3.5.1 Object Protection .................................................................................................................... 25 3.5.2 Object Re-use ......................................................................................................................... 26 3.5.3 Privileged Functions................................................................................................................ 26 3.6 Cryptographic Material Management ............................................................................................. 26 Document is Uncontrolled When Printed. Page 3 of 46 CR-3397 Revision Level: 21 3.6.1 Key Cloning ............................................................................................................................. 27 3.6.2 Key Mask / Unmask ................................................................................................................ 27 3.6.3 Key Wrap / Unwrap ................................................................................................................. 28 3.7 Cryptographic Operations .............................................................................................................. 28 3.8 Self-tests ........................................................................................................................................ 35 3.9 Firmware Security .......................................................................................................................... 36 3.10 Physical Security ........................................................................................................................ 36 3.10.1 Secure Recovery .................................................................................................................... 36 3.11 EMI / EMC .................................................................................................................................. 37 3.12 Fault Tolerance ........................................................................................................................... 37 3.13 Mitigation of Other Attacks ......................................................................................................... 37 LIST OF TABLES Table Title Page Table 1-1. FIPS 140-2 Security Requirements ............................................................................................. 7 Table 3-1. Module Capabilities and Policies .............................................................................................. 12 Table 3-2. Partition Capabilities and Policies ............................................................................................. 14 Table 3-3. Object Attributes Used in Access Control Policy Enforcement ................................................. 25 Table 3-4. Approved Security Functions for SafeXcel 3120 ...................................................................... 29 Table 3-5. Approved Security Functions for SafeXcel 1746 ...................................................................... 30 Table 3-6. Approved Security Functions Firmware Implementation .......................................................... 31 Table 3-7. Allowed Security Function for the Firmware Implementation .................................................... 32 Table 3-8. Non-FIPS Approved Security Functions ................................................................................... 33 Table 3-9. Module Self-Tests ..................................................................................................................... 35 Table A-1. Roles and Required Identification and Authentication .............................................................. 38 Table A-2. Strengths of Authentication Mechanisms ................................................................................. 38 Table A-3. Services Authorized for Roles .................................................................................................. 39 Table A-4. Access Rights within Services .................................................................................................. 39 Table A-5 Keys and Critical Security Parameters Used in the Module ...................................................... 41 Document is Uncontrolled When Printed. Page 4 of 46 CR-3397 Revision Level: 21 LIST OF FIGURES Figure Title Page Figure 2-1. Luna PCI-E Cryptographic Module ............................................................................................ 8 Figure 2-2. Luna SA (with PCI-E Installed), Luna PED and iKeys ............................................................... 8 LIST OF APPENDICES Appendix Title Page APPENDIX A. SECURITY POLICY CHECKLIST TABLES ................................................................... 38 APPENDIX B. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS ............................................... 45 Document is Uncontrolled When Printed. Page 5 of 46 CR-3397 Revision Level: 21 1. INTRODUCTION 1.1 Purpose This document describes the security policies enforced by SafeNet Inc.'s Lunaź PCI-E Cryptographic Module and Lunaź PCI-E Cryptographic Module for Lunaź SA1. The Luna PCI-E cryptographic module can be used as follows: A standalone device, which includes the following configurations: o Cloning [CL]; and o Key Export [CKE]; or An embedded device in Lunaź SA, which includes the following configurations: o Cloning [CL], o Signing No Cloning [SNC], and o Key Export [CKE]) This document applies to Hardware Version VBD-05, Version Code 0100; Hardware Version VBD-05, Version Code 0101; Hardware Version VBD-05, Version Code 0102; and Hardware Version VBD-05, Version Code 01032 3 with Firmware Versions 6.10.4, 6.10.7, and 6.10.9. 1.2 Scope The security policies described in this document apply to the Trusted Path Authentication (Level 3) configuration of the Luna PCI-E cryptographic module only and do not include any security policy that may be enforced by the host appliance or server. 1 Also known as the K6 or the cryptographic module. 2 The Hardware Version may also be displayed as VBD-05-0100, VBD-05-0101, VBD-05-0102, or VBD-05-0103. Both types of displays represent the equivalent Hardware Versions of the Luna PCI-E cryptographic module. 3 From the perspectives of functionality and physical security, Hardware Version VBD-05, Version Code 0100 (or VBD-05-0100); Hardware Version VBD-05, Version Code 0101 (or VBD-05-0101); Hardware Version VBD-05, Version Code 0102 (or VBD-05-0102); and Hardware Version VBD-05, Version Code 0103 (or VBD-05-0103) are equivalent. Document is Uncontrolled When Printed. Page 6 of 46 CR-3397 Revision Level: 21 1.3 Overview The cryptographic module meets all level 3 requirements for FIPS 140-2 as summarized in Table 1-1. Table 1-1. FIPS 140-2 Security Requirements Security Requirements Section Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles and Services and Authentication 3 Finite State Machine Model 3 Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of Other Attacks 3 Cryptographic Module Security Policy 3 2. SECURITY POLICY MODEL INTRODUCTION 2.1 Functional Overview The Luna PCI-E cryptographic module is a multi-chip embedded hardware cryptographic module in the form of a PCI-Express card that typically resides within a custom computing or secure communications appliance. The cryptographic module is contained in its own secure enclosure that provides physical resistance to tampering. The cryptographic boundary of the module is defined to encompass all components inside the secure enclosure on the PCI-E card. Figure 2-1 depicts the Luna PCI-E cryptographic module and Figure 2-2 depicts the Luna SA appliance, with the Luna PCI-E module installed, showing the PED and iKeys used for authentication. A module may be explicitly configured to operate in either FIPS Level 2 or FIPS Level 3 mode, or in a non-FIPS mode of operation. Configuration in either FIPS mode enforces the use of FIPS-approved algorithms only. Configuration in FIPS Level 3 mode also enforces the use of trusted path authentication. Note that selection of FIPS mode occurs at initialization of the cryptographic module, and cannot be changed during normal operation without zeroizing the module's non-volatile memory. A cryptographic module is accessed directly (i.e., electrically) via either the Trusted Path PIN Entry Device (PED) serial interface or via the PCI-Express communications interface. A module provides secure key generation and storage for symmetric keys and asymmetric key pairs along with symmetric and asymmetric cryptographic services. Access to key material and cryptographic services for users and user application software is provided through the PKCS #11 programming interface. A module may host multiple user definitions or "partitions" that are cryptographically separated and are presented as "virtual tokens" to user applications. Each partition must be separately authenticated in order to make it available for use. This Security Policy is specifically written for the Luna PCI-E cryptographic module in a Trusted Path Authentication (FIPS Level 3) configuration. Document is Uncontrolled When Printed. Page 7 of 46 CR-3397 Revision Level: 21 Cryptographic Boundary Figure 2-1. Luna PCI-E Cryptographic Module Figure 2-2. Luna SA (with PCI-E Installed), Luna PED and iKeys Document is Uncontrolled When Printed. Page 8 of 46 CR-3397 Revision Level: 21 2.2 Assets to be Protected The module is designed to protect the following assets: 1. User-generated private keys, 2. User-generated secret keys, 3. Cryptographic services, and 4. Module security critical parameters. 2.3 Operating Environment The module is assumed to operate as a key management and cryptographic processing card within a security appliance that may operate in a TCP/IP network environment. The host appliance may be used in an internal network environment when key management security is a primary requirement. It may also be deployed in environments where it is used primarily as a cryptographic accelerator, in which case it will often be connected to external networks. It is assumed that the appliance includes an internal host computer that runs a suitably secured operating system, with an interface for use by locally connected or remote administrators and an interface to provide access to the module's cryptographic functions by application services running on the host computer. It is also assumed that only known versions of the application services are permitted to run on the internal host computer of the appliance. It is assumed that trained and trustworthy administrators are responsible for the initial configuration and ongoing maintenance of the appliance and the cryptographic module. It is assumed that physical access to the cryptographic module will be controlled, and that connections will be controlled either by accessing the module via a direct local connection or by accessing it via remote connections controlled by the host operating system and application service. The cryptographic module is designed to operate between 0 and 60 degrees Celsius. 3. SECURITY POLICY MODEL DESCRIPTION This section provides a narrative description of the security policy enforced by the module in its most general form. It is intended both to state the security policy enforced by the module and to give the reader an overall understanding of the security behaviour of the module. The detailed functional specification for the module is provided elsewhere. The security behaviour of the cryptographic module is governed by the following security policies: Operational Policy Identification and Authentication Policy Access Control Policy Cryptographic Material Management Policy Firmware Security Policy Physical Security Policy These policies complement each other to provide assurance that cryptographic material is securely managed throughout its life cycle and that access to other data and functions provided by the product is properly controlled. Configurable parameters that determine many of the variable aspects of the module's behaviour are specified by the higher level Operational Policy implemented at two levels: the cryptographic module as a whole and the individual partition. This is described in section 3.1. Document is Uncontrolled When Printed. Page 9 of 46 CR-3397 Revision Level: 21 The Identification and Authentication policy is crucial for security enforcement and it is described in section 3.4. The access control policy is the main security functional policy enforced by the module and is described in section 3.5, which also describes the supporting object re-use policy. Cryptographic Material Management is described in section 3.6. Firmware security, physical security and fault tolerance are described in sections 3.8 through 3.12. 3.1 Operational Policy The module employs the concept of the Operational Policy to control the overall behaviour of the module and each of the partitions within. At each level, either the module or the partition is assigned a fixed set of "capabilities" that govern the allowed behaviour of the module or individual partition. The Security Officer (SO) establishes the Operational Policy by enabling/disabling or refining the corresponding policy elements to equate to or to be more restrictive than the pre-assigned capabilities. The set of configurable policy elements is a proper subset of the corresponding capability set. That is, not all elements of the capability set can be refined. Which of the capability set elements have corresponding policy set elements is pre-determined based on the "personality" of the partition or manufacturing restrictions placed on the module. For example, the module capability setting for "domestic algorithms and key sizes available" does not have a corresponding configurable policy element. There are also several fixed settings that do not have corresponding capability set elements. These are elements of the cryptographic module's behaviour that are truly fixed and, therefore, are not subject to configuration by the SO. The specific settings 4 are the following: Allow/disallow non-sensitive secret keys ­ fixed as disallow. Allow/disallow non-sensitive private keys ­ fixed as disallow. Allow/disallow non-private secret keys ­ fixed as disallow. Allow/disallow non-private private keys ­ fixed as disallow. Allow/disallow secret key creation through the create objects interface ­ fixed as disallow. Allow/disallow private key creation through the create objects interface ­ fixed as disallow. Further, policy set elements can only refine capability set elements to more restrictive values. Even if an element of the policy set exists to refine an element of the capability set, it may not be possible to assign the policy set element to a value other than that held by the capability set element. Specifically, if a capability set element is set to allow, the corresponding policy element may be set to either enable or disable. However, if a capability set element is set to disallow, the corresponding policy element can only be set to disable. Thus, an SO cannot use policy refinement to lift a restriction set in a capability definition. 3.1.1 Module Capabilities The following is the set of capabilities supported at the module level: Allow/disallow non-FIPS algorithms available. Allow/disallow trusted path authentication (allowed and must be enabled in Level 3 configuration). Allow/disallow partition groups. 4 The nomenclature used for these setting is based on PKCS#11. Document is Uncontrolled When Printed. Page 10 of 46 CR-3397 Revision Level: 21 Allow/disallow cloning. Allow/disallow masking5. Allow/disallow unmasking. Allow/disallow Korean algorithms6 Allow/disallow SO reset of partition PIN. Allow/disallow network replication (set to disallow). Allow/disallow forcing change of User authentication data. Allow/disallow Remote PED (RPED) operations. Allow/disallow external Master Tamper Key (MTK) split storage Allow/disallow Acceleration Allow/disallow High Assurance (HA) mode CGX 3.1.2 Partition Capabilities The following is the set of capabilities supported at the partition level. All capability elements described as "allow/disallow some functionality" are Boolean values where false (or "0") equates to disallow the functionality and true (or "1") equates to allow the functionality. The remainder of the elements are integer values of the indicated number of bits. Allow/disallow changing of certain key attributes once a key has been created. Allow/disallow user key management capability. (This would be disabled by the SO at the policy level to prevent any key management activity in the partition, even by a user in the Crypto Officer role. This could be used, for example, at a CA once the root signing key pair has been generated and backed up, if appropriate, to lock down the partition for signing use only.) Allow/disallow incrementing of failed login attempt counter on failed challenge response validation. Allow/disallow Level 3 operation without a challenge Allow/disallow activation. Allow/disallow automatic activation. Allow/disallow High Availability. Allow/disallow multipurpose keys. Allow/disallow operation without RSA blinding. Allow/disallow signing operations with non-local keys. Allow/disallow raw RSA operations. Allow/disallow private key wrapping Allow/disallow private key unwrapping. Allow/disallow secret key wrapping Allow/disallow secret key unwrapping 5 A SafeNet term used to describe the encryption of a key for use only within a SafeNet cryptographic module. 6 Korean algorithms include SEED, ARIA, and KCDSA. Document is Uncontrolled When Printed. Page 11 of 46 CR-3397 Revision Level: 21 Allow/disallow RSA signing without confirmation Number of failed Partition User logins allowed before partition is locked out/cleared (default is 10; SO can configure it to be 3 <= N <= 10) The following capabilities are configurable only if the corresponding capability/policy is allowed and enabled at the module level: Allow/disallow private key cloning. Allow/disallow secret key cloning. Allow/disallow private key masking7. Allow/disallow secret key masking. Allow/disallow private key unmasking. Allow/disallow secret key unmasking. The following tables summarize the module and partition capabilities, showing typical capability settings for Luna PCI-E cryptographic modules used in the following configurations: Luna PCI-E product configurations: o Key Export (CKE), and o Cloning (CL); and Luna SA product configurations: o Key Export (CKE), o Cloning (CL), and o Signing No Cloning (SNC). An X indicates the default capability setting for each configuration of the module. Greyed-out rows indicate that the corresponding capability setting is not used as a default for any module configuration. Table 3-1. Module Capabilities and Policies Description Capability CKE CL SNC Policy Comments Enable SO can configure the policy to enable or disable the Allow X X X availability of non-FIPS algorithms at the time the Non-FIPS Disable cryptographic module is initialized. algorithms available The cryptographic module must operate using FIPS-approved Disallow Disable algorithms only. Must be disabled in FIPS mode Enable SO can configure the policy to enable or disable the use of Allow Password Disable passwords without trusted path for authentication. authentication The cryptographic module must operate using the trusted path Disallow X X X Disable and module-generated secrets for authentication. Enable SO can configure the policy to enable or disable the use of the Allow X X X Trusted path Disable trusted path and module-generated secrets for authentication. authentication The cryptographic module must operate using passwords Disallow Disable without trusted path for authentication.8 7 Masking is performed using a FIPS-approved encryption algorithm with a key that is held only by the cryptographic module. 8 One and only one means of authentication ("user password" or "trusted path") must be enabled by the policy. Therefore, one of the authentication capabilities must be allowed and, if one of the capabilities is disallowed or the policy setting disabled, then the policy setting for the other must be enabled. Document is Uncontrolled When Printed. Page 12 of 46 CR-3397 Revision Level: 21 Description Capability CKE CL SNC Policy Comments Enable The cryptographic module can use Remote PED for Trusted Allow X X X Path authentication.9 Allowed in Trusted Path authentication Remote PED Disable only. Operations The cryptographic module cannot use remote PED for Trusted Disallow Disable Path authentication. Enable SO can configure the policy to enable or disable the Allow X X availability of the cloning function for the cryptographic module Cloning Disable as a whole. Disallow X Disable The cryptographic module must operate without cloning. Enable SO can configure the policy to enable or disable the Allow availability of the masking function for the cryptographic Masking Disable module as a whole. Disallow X X X Disable The cryptographic module must operate without masking. Enable SO can configure the policy to enable or disable the Allow X X X availability of the unmasking function for the cryptographic Unmasking Disable module as a whole. Disallow Disable The cryptographic module must operate without unmasking. Enable SO can configure the policy to enable or disable the Allow availability of Korean algorithms for the cryptographic module Disable as a whole. Korean algorithms10 The cryptographic module must operate without Korean Disallow X X X Disable algorithms. Enable SO can configure the policy to enable a partition to be reset if Allow X X X it is locked as a result of exceeding the maximum number of Disable failed login attempts. Partition reset A partition cannot be reset and must be re-created as a result Disallow Disable of exceeding the maximum number of failed login attempts. Enable SO can configure the policy to enable the replication of the Allow X Network Replication Disable module's key material over the network to a second module. Disallow X X Disable The module cannot be replicated over the network. Enable This capability is set prior to shipment to the customer. If Force user PIN Allow X X X Disable enabled, it forces the user to change the PIN upon first login. change Disallow Disable The user is never forced to change PIN on first login. Enable This capability is set prior to shipment to the customer. It External MTK split Allow X X X Disable allows the use of external storage of the MTK split. storage Disallow Disable External MTK split storage cannot be enabled for the module. Enable This capability is set prior to shipment to the customer. It Allow X X X Acceleration Disable allows the use of the onboard crypto accelerator. Disallow Disable Remote authentication cannot be enabled for the module. Enable This capability is set prior to shipment to the customer. It Allow HA CGX Mode Disable allows the use of the HA CGX mode. Disallow X X X Disable HA CGX mode cannot be enabled for the module. 9 Enabled in the Trusted Path configuration. Operator can connect the cryptographic module to a Remote PED using Command Line Interface (CLI) commands. 10 Korean algorithms are only available upon customer request. Document is Uncontrolled When Printed. Page 13 of 46 CR-3397 Revision Level: 21 Table 3-2. Partition Capabilities and Policies Description Prerequisite Capability KE CL NC Policy Comments SO can configure the policy to enable Trusted Path Enable login using the PED trusted path only, with no Trusted path Allow X X X challenge-response validation required. Must be Trusted Path operation disabled if either activation or auto-activation is authentication without a challenge Disable enabled enabled Challenge-response validation required plus PED Disallow Disable trusted path login to access the partition. SO can configure the policy to enable the normal Trusted path PKCS #11 user role to perform key management authentication Enable functions. If enabled, the Crypto Officer key User key management Allow X X X enabled, Trusted Path management functions are available. If disabled, only capability11 the Crypto User role functions are accessible. operation without a challenge disabled Disable Disallow Disable Only the Crypto User role functions are accessible. SO can configure the policy to count failures of the Enable challenge-response validation against the maximum Trusted path Allow X X X login failures or not. Must be enabled if either Count failed challenge- activation or auto-activation is enabled authentication response validations Disable enabled Failures of the challenge-response validation are not Disallow Disable counted against the maximum login failures. SO can configure the policy to enable the authentication data provided via the PED trusted path Enable to be cached in the module, allowing all subsequent Trusted path Allow X X X access to the partition, after the first login, to be done Activation authentication on the basis of challenge-response validation alone. enabled Disable PED trusted path authentication is required for every Disallow Disable access to the partition. 11This capability/policy is intended to offer customers a greater level of control over key management functions. By disabling the policy, the Security Officer places the partition into a state in which the key material is locked down and can only be used by connected applications, i.e., only Crypto User access is possible. Document is Uncontrolled When Printed. Page 14 of 46 CR-3397 Revision Level: 21 Description Prerequisite Capability KE CL NC Policy Comments SO can configure the policy to enable the activation data to be stored on the appliance server in encrypted form, allowing the partition to resume its Trusted path Enable authentication state after a re-start. This is intended Allow X X X Auto-activation authentication primarily to allow partitions to automatically re-start enabled operation when the appliance returns from a power outage. Disable Disallow Disable Activation data cannot be externally cached. Enable SO can configure the policy to enable the use of the Allow X X High Availability feature. High Availability N/A Disable Disallow X Disable High Availability cannot be enabled. Enable SO can configure the policy to enable the use of keys for more than one purpose, e.g., an RSA private key Allow X X X Multipurpose keys N/A Disable could be used for digital signature and for decryption for key transport purposes. Disallow Disable Keys can only be used for a single purpose. Enable SO can configure the policy to enable changing key Allow X X X attributes. Change attributes N/A Disable Disallow Disable Key attributes cannot be changed. SO can configure the use of blinding mode for RSA operations. Blinding mode is used to defeat timing Enable analysis attacks on RSA digital signature operations, Operate without RSA Allow X X X N/A but it also imposes a significant performance penalty blinding on the signature operations. Disable Disallow Disable Blinding mode is not used for RSA operations. Enable SO can configure the ability to sign with externally- Allow X X X generated private keys that have been imported into Signing with non-local Disable the partition. N/A keys Externally-generated private keys cannot be used for Disallow Disable signature operations. Enable SO can configure the ability to use raw (no padding) Allow X X X format for RSA encrypt/decrypt operations for key Raw RSA operations N/A Disable transport purposes. Disallow Disable Raw RSA cannot be used. Document is Uncontrolled When Printed. Page 15 of 46 CR-3397 Revision Level: 21 Description Prerequisite Capability KE CL NC Policy Comments Enable SO can configure the ability to wrap private keys for Allow X export. Disable Private key wrapping N/A Private keys cannot be wrapped and exported from Disallow X X Disable the partition. Enable SO can configure the ability to unwrap private keys Allow X X X and import them into the partition. Disable Private key unwrapping N/A Private keys cannot be unwrapped and imported into Disallow Disable the partition. Enable SO can configure the ability to wrap secret keys and Allow X X X export them from the partition. Disable Secret key wrapping N/A Secret keys cannot be wrapped and exported from Disallow Disable the partition. Enable SO can configure the ability to unwrap secret keys Allow X X X and import them into the partition. Disable Secret key unwrapping N/A Secret keys cannot be unwrapped and imported into Disallow Disable the partition. Cloning enabled, Enable SO can configure the ability to clone private keys from Trusted path Allow X one module and partition to another. Private key cloning Disable authentication enabled Disallow X X Disable Private keys cannot be cloned. Cloning enabled, Enable SO can configure the ability to clone secret keys from Trusted path Allow X X X one module and partition to another. Secret key cloning Disable authentication enabled Disallow Disable Secret keys cannot be cloned. Enable SO can configure the ability to mask private keys for Allow storage outside the partition. Disable Private key masking Masking enabled Private keys cannot be masked for storage outside Disallow X X X Disable the partition. Enable SO can configure the ability to mask secret keys for Allow storage outside the partition. Disable Secret key masking Masking enabled Secret keys cannot be masked for storage outside the Disallow X X X Disable partition. Document is Uncontrolled When Printed. Page 16 of 46 CR-3397 Revision Level: 21 Description Prerequisite Capability KE CL NC Policy Comments Enable This setting allows unmasking of private keys. Secret key cloning Allow X X X Private key unmasking Disable enabled Disallow Disable Private keys cannot be unmasked Enable This setting allows unmasking of secret keys. Secret key cloning Allow X X X Secret key unmasking Disable enabled Disallow Disable Secret keys cannot be unmasked User password The SO can configure the minimum password length Minimum / maximum authentication 7-16 characters Configurable for Level 2 modules, but minimum length must always password length enabled be >= 7. Number of failed Partition Minimum:1, The SO can configure; default maximum value is 10. N/A Configurable User logins allowed Maximum:10 Document is Uncontrolled When Printed. Page 17 of 46 CR-3397 Revision Level: 21 3.2 FIPS-Approved Mode The SO controls operation of a module in FIPS-approved mode, as defined by FIPS PUB 140- 2, by enabling or disabling the appropriate Module Policy settings (assuming each is allowed at the Module Capability level). To operate in FIPS-approved mode, the following policy settings are required: "Non-FIPS Algorithms Available" must be disabled. Additionally, for operation at FIPS Level 3: "Trusted path authentication" must be enabled (implies that password authentication is disallowed or disabled), and "Trusted Path operation without a challenge" must be disabled if activation or auto- activation is enabled. "Count failed challenge ­ response validations" must be enabled if activation or auto-activation is enabled. Raw RSA operations can only be used for key transport in FIPS mode The policy settings for "Trusted path authentication" may also be configured in the case where "Non-FIPS Algorithms Available" has been enabled. If the SO selects policy options (i.e., enables "Non-FIPS Algorithms Available") that would place a module in a mode of operation that is not approved, a warning is displayed and the SO is prompted to confirm the selection. The SO can confirm that the cryptographic module is in FIPS mode by utilizing the "hsm showinfo" command. With this command, the following message will be displayed, "The HSM is in FIPS 140-2 approved operation mode". 3.3 Description of Operator, Subject and Object 3.3.1 Operator An operator is defined as an entity that acts to perform an operation on a module. An operator may be directly mapped to a responsible individual or organization, or it may be mapped to a composite of a responsible individual or organization plus an agent (application program) acting on behalf of the responsible individual or organization. In the case of a Certification Authority (CA), for example, the organization may empower one individual or a small group of individuals acting together to operate a cryptographic module as part of the company's service. The operator might be that individual or group, particularly if they are interacting with a module locally. The operator might also be the composite of the individual or group, who might still be present locally to a module (particularly for activation purposes, see section 3.4.2), plus the CA application running on a network-attached host computer. 3.3.2 Roles Document is Uncontrolled When Printed. Page 18 of 46 CR-3397 Revision Level: 21 In the Trusted Path Authentication configuration, the Luna cryptographic module supports the following authenticated operator roles: the Security Officer (SO) and Audit Officer12 at the module level plus Partition Users13 (also known by sub-roles ­ Crypto Officer and Crypto User) for each Partition. The cryptographic module also supports one unauthenticated operator role, the Public User, primarily to permit access to status information and diagnostics before authentication. The SO is a privileged role, which exists only at the module level, whose primary purpose is to initially configure a module for operation and to perform security administration tasks such as partition creation. The Audit Officer is a privileged role, which exists only at the module level to initialize, configure, and manage secure audit logging. Only the Audit Officer can initialize, configure and manage the secure audit logging feature. This allows for a separation of duties between an Audit Officer and the other roles (e.g., SO, crypto officer, and crypto user) that the Audit Officer is auditing ­ preventing administrative and user personnel from tampering with the log files and preventing the Audit Officer from performing administrative tasks or from accessing keys. The Crypto Officer is the key management role for each partition. The Crypto User is an optional read-only role that limits the operator to performing cryptographic operations only. For an operator to assume any role other than Public User, the operator must be identified and authenticated. The following conditions must hold in order to assume one of the authenticated roles: No operator can assume the Audit Officer, Crypto Officer, Crypto User or Security Officer role before identification and authentication; No identity can assume more than one authenticated role at the same time, e.g., Crypto Officer or Crypto User, plus the Security Officer role, or Audit Officer, plus Security Officer. The SO can create the Crypto User role by creating a challenge value for the Crypto User. In the case of a partition that supports the Crypto Officer and Crypto User roles, the Security Officer can limit access to only the Crypto User role by disabling the "User Key Management" (see Table 3-1) policy. For additional information regarding roles and authorized services, please refer to Table A-1 and Table A-3. 3.3.3 Account Data 12 Within the confines of the operational use of the Luna cryptographic module, the FIPS 140-2 term of "Crypto Officer" encompasses the Luna cryptographic module roles of "Security Officer" and "Audit Officer". 13 Within the confines of the operational use of the Luna cryptographic module, the FIPS 140-2 term of "User" encompasses the Luna cryptographic module roles of "crypto user" and "crypto officer", which are collectively called the Partition Users. Document is Uncontrolled When Printed. Page 19 of 46 CR-3397 Revision Level: 21 The module maintains the following User (which can include both the Crypto Officer and Crypto User role per Partition14) and SO account data: Partition ID or SO ID number. Partition User encrypted or SO encrypted authentication data (checkword). Partition User authentication challenge secret (one for each role, as applicable). Partition User locked out flag. An authenticated User is referred to as a Partition User. The ability to manipulate the account data is restricted to the SO and the Partition User. The specific restrictions are as described below: 1. Only the Security Officer role can create (initialize) and delete the following security attributes: o Partition ID. o Checkword. 2. If Partition reset is allowed and enabled, the SO role only can modify the following security attribute: o Locked out flag for Partition User. 3. Only the Partition User can modify the following security attribute: o Checkword for Partition User. 4. Only the Security Officer role can change the default value, query, modify and delete the following security attribute: o Checkword for Security Officer. 3.3.4 Subject For the purposes of this security policy, the subject is defined to be a module session. The session provides a logical means of mapping between applications connecting to a module and the processing of commands within a module. Each session is tracked by the Session ID, the Partition ID and the Access ID, which is a unique ID associated with the application's connection. It is possible to have multiple open sessions with a module associated with the same Access ID/Partition ID combination. It is also possible for a module to have sessions opened for more than one Partition ID or have multiple Access IDs with sessions opened on a module. Applications running on remote host systems that require data and cryptographic services from a module must first connect via the communications service within the appliance, which will establish the unique Access ID for the connection and then allow the application to open a session with one of the partitions within a module. A local application (e.g., command line administration interface) will open a session directly with the appropriate partition within a module without invoking the communications service. 3.3.5 Operator ­ Subject Binding An operator must access a partition through a session. A session is opened with a partition in an unauthenticated state and the operator must be authenticated before any access to cryptographic functions and Private objects within the partition can be granted. Once the operator is successfully identified and authenticated, the session state becomes authenticated and is bound to the Partition User represented by the Partition ID, in the Crypto Officer or Crypto User role. Any other sessions opened with the same Access ID/Partition ID combination will share the same authentication state and be bound to the same Partition User. 3.3.6 Object 14 A Partition effectively represents an identity within the module. Document is Uncontrolled When Printed. Page 20 of 46 CR-3397 Revision Level: 21 An object is defined to be any formatted data held in volatile or non-volatile memory on behalf of an operator. For the purposes of this security policy, the objects of primary concern are private (asymmetric) keys and secret (symmetric) keys. 3.3.7 Object Operations Object operations may only be performed by a Partition User. The operations that may be performed are limited by the role (Crypto Officer or Crypto User) associated with the user's login state, see section 3.5. New objects can be made in several ways. The following list identifies operations that produce new objects: o Create, o Copy, o Generate, o Unwrapping, o Derive. Existing objects can be modified and deleted. The values of a subset of attributes can be changed through a modification operation. Objects can be deleted through a destruction operation. Constant operations do not cause creation, modification or deletion of an object. These constant operations include: Query an object's size; Query the size of an attribute; Query the value of an attribute; Use the value of an attribute in a cryptographic operation; Search for objects based on matching attributes; Cloning an object; Wrapping an object; and Masking and unmasking an object. Secret keys and private keys are always maintained as Sensitive objects and, therefore, they are permanently stored with the key value encrypted to protect its confidentiality. Key objects held in volatile memory do not have their key values encrypted, but they are subject to active zeroization in the event of a module reset or in response to a tamper event. For additional information about the clearing of sensitive data, see Section 3.13. Operators are not given direct access to key values for any purpose. 3.4 Identification and Authentication 3.4.1 Authentication Data Generation and Entry The module requires that Partition Users, the Audit Officer and the SO be authenticated by proving knowledge of a secret shared by the operator and the module. A module configured for Trusted Path Authentication must be initialized using the PED to define the SO authentication data. For Trusted Path Authentication, a module generates the authentication secret as a 48-byte random value and, optionally for a Partition User, an authentication challenge secret. The authentication secret(s) are provided to the operator via a physically separate trusted path, described in sub-section 3.4.2, and must be entered by the operator via the trusted path and via a logically separate trusted channel (in the case of the response based on the challenge secret) during the login process. If a Partition is created with Crypto Officer and Crypto User roles, a separate challenge secret is generated for each role. Document is Uncontrolled When Printed. Page 21 of 46 CR-3397 Revision Level: 21 The following types of iKey are used with the Lunaź PED: Orange (RPV) iKey ­ for the storage of the Remote PED Vector (RPV), Blue (SO) iKey ­ for the storage of SO authentication data, Black (User) iKey ­ for the storage of User authentication data, Red (Domain) iKey ­ for the storage of the cloning domain data, used to control the ability to clone from a cryptographic module to a backup module, Purple (MTK Recovery) iKey ­ for the storage of an external split that allows the MTK to be restored after a tamper event. White (Audit Officer) iKey ­ for the storage of Audit Officer authentication data Any iKey, once data has been written to it, is an Identification and Authentication device and must be safeguarded accordingly by the administrative or operations staff responsible for the operation of the module within the customer's environment. 3.4.2 Trusted Path In Trusted Path mode, user authentication is, by default, a two-stage process. The first stage is termed "Activation" and is performed using a trusted path device (PED) which connects to the cryptographic module either directly over a physical wire or remotely over a secure network connection. The primary form of authentication data used during Activation is the 48-byte value that is randomly generated by a module and stored on the Black (User) iKey15 via the trusted path. The data on the iKey must then be entered into a module via the trusted path as part of each Activation process. Once Activation has been performed, the user's Partition data is ready for use within a module. Access to key material and cryptographic services, however, is not allowed until the second stage of authentication, "User Login", has been performed. This typically requires the input of a partition's challenge secret as part of a login operation. However, for SO authentication and for user authentication when the settings of the Partition Policy disable the use of challenge/response authentication for login to a partition 16, the presentation of the iKey data (i.e., equivalent to Activation) is all that is required to complete authentication. The default Partition Policy enables the use of challenge/response authentication for the "User Login" stage. The authentication challenge secret (or secrets if the Crypto Officer and Crypto User roles are used) for the partition is generated by the module as a 75-bit value that is displayed as a 16-character alphanumeric string on the visual display of the trusted path device. The challenge secret is then provided, via a secure out-of-band means, to each external entity authorized to connect to the partition and is used by the external entity to form the response to a random one-time challenge from a module. The encrypted one-time response is returned to the cryptographic module where it is verified to confirm the "User Login". Thus, when the challenge secret is required, both the trusted path Activation and the successful completion of the challenge/response process by the external entity is required to authenticate to a partition and have access to its cryptographic material and functions. 3.4.2.1. Remote PED Operation The user has the option of operating the PED in the conventional manner (i.e., locally 15 Or Black (User) PED key. Within this document the terms "iKey" and "PED" key are interchangeable unless otherwise indicated. 16 Challenge/response authentication might, for example, be disabled in a case where both a cryptographic module and the attached application server are located within a physically secured environment and the user is required to always be physically present to start the application and authenticate to a cryptographic module via the PED. Document is Uncontrolled When Printed. Page 22 of 46 CR-3397 Revision Level: 21 connected to the cryptographic module) or remotely, connected to a management workstation via USB. Remote PED operation extends the physical trusted path connection by the use of a protocol that authenticates both the remote PED and the module and establishes a one-time AES key to encrypt the communications between the module and the Remote PED. Once secure communications have been established, all interactions between the cryptographic module, PED, and iKeys are performed in exactly the same way as they would be when locally connected. The logical path between the module and the Remote PED is secured in the manner described below. At the time it is initialized, the module generates a random 256-bit secret, known as the Remote PED Vector (RPV), stores it in its secure parameters area, and writes it to the "Orange" iKey, also known as the Remote PED Key (RPK). To establish the secure connection, the RPK must be inserted into the PED. The PED extracts the RPV, and the PED and the cryptographic module then participate in an ephemeral Diffie- Hellman key agreement session. The derived shared secret is then XORed with the RPV to produce the key to be used for the session. An exchange of encrypted random nonces is performed to authenticate both ends of the transmission. All traffic between the PED and the cryptographic module is encrypted using AES 256. 3.4.3 M of N Authentication The Luna cryptographic module supports the use of an M of N secret sharing authentication scheme for each of the module roles. M of N authentication provides the capability to enforce multi-person integrity over the functions associated with each role. The M of N capability is based on Shamir's threshold scheme. The Luna cryptographic module splits the randomly-generated authentication data into "N" pieces, known as splits, and stores each split on an iKey. Any "M" of these "N" splits must be transmitted to the Luna cryptographic module by inserting the corresponding iKeys into the Luna PED in order to reconstruct the original secret. When the M of N set is distributed to recipients outside the module, the split data is contained in M of N vectors. A vector may contain one or more splits depending on the weight assigned at the time of generation. For example, in the case of a three-of-five activation setting, it may be desired for A to receive the equivalent of two splits whereas B, C and D only receive one each for a total of five. 3.4.4 Limits on Login Failures The module also implements a maximum login attempts policy. The policy differs for an SO authentication data search, a Partition User authentication data search, or an Audit Officer data search. In the case of an SO authentication data search: If three (3) consecutive SO logon attempts fail, a module is zeroized. In the case of a Partition User authentication data search, one of two responses will occur, depending on the partition policy: 1. If "Partition reset" is Allowed and Enabled, then if "n" ("n" is set by the SO at the time the cryptographic module is initialized) consecutive operator logon attempts fail, the module flags the event in the Partition User's account data, locks the Partition User and clears the volatile memory space. The SO must unlock the partition in order for the Partition User to resume operation. Document is Uncontrolled When Printed. Page 23 of 46 CR-3397 Revision Level: 21 2. If "Partition reset" is not Allowed or not Enabled, then if "n" consecutive Partition User logon attempts via the physical trusted path fail, the module will erase the partition. The SO must delete and re-create the partition. Any objects stored in the partition, including private and secret keys, are permanently erased. In the case of an Audit Officer data search: If three consecutive Audit Officer logon attempts fail, the Audit Officer account will be locked for 60 seconds. After the 60 second lockout timeout, the Audit Officer may attempt to logon to the module again. 3.5 Access Control The Access Control Policy is the main security function policy enforced by a module. It governs the rights of a subject to perform privileged functions and to access objects stored in a module. It covers the object operations detailed in section 3.3.7. A subject's access to objects stored in a module is mediated on the basis of the following subject and object attributes: Subject attributes: o Session ID o Access ID and Partition ID associated with session o Session authentication state (binding to authenticated Partition identity and role) Object attributes: o Owner. A Private object is owned by the Partition User associated with the subject that produces it. Ownership is enforced via internal key management. o Private. If True, the object is Private. If False, the object is Public. o Sensitive. If True, object is Sensitive. If False, object is Non-Sensitive. o Extractable17. If True, object may be extracted. If False, object may not be extracted. o Modifiable. If True, object may be modified. If False, object may not be modified. Objects are labelled with a number corresponding to their partition and are only accessible by a subject associated with the owning Partition ID. Only generic data and certificate objects can be non-sensitive. Sensitive objects are encrypted using the partition's secret key to prevent their values from ever being exposed to external entities. Key objects are always created as Sensitive objects and can only be used for cryptographic operations by a logged in Partition User. Key objects that are marked as extractable may be exported from a module using the Wrap operation if allowed and enabled in the partition's policy set. Table 3-3 summarizes the object attributes used in Access Control Policy enforcement. 17Extract means to remove the key from the control of the module. This is typically done using the Wrap operation, but the Mask operation is also considered to perform an extraction when cloning is enabled for the container. Document is Uncontrolled When Printed. Page 24 of 46 CR-3397 Revision Level: 21 Table 3-3. Object Attributes Used in Access Control Policy Enforcement Attribute Values Impact TRUE ­ Object is private to (owned by) the Object is only accessible to subjects (sessions) operator identified as the Access Owner when the bound to the operator identity that owns the PRIVATE object is created. object. FALSE ­ Object is not private to one operator Object is accessible to all subjects associated identity. with the partition in which the object is stored. TRUE ­ Attribute values representing plaintext key Key material is stored in encrypted form. material are not permitted to exist (value encrypted). SENSITIVE FALSE ­ Attribute values representing plaintext Plaintext data is stored with the object and is data are permitted to exist. accessible to all subjects otherwise permitted access to the object. TRUE ­ The object's attribute values may be The object is "writeable" and its attribute values modified. can be changed during a copy or set attribute MODIFIABLE operation. FALSE ­ The object's values may not be modified. The object can only be read and only duplicate copies can be made. TRUE ­ Key material stored with the object may be The ability to extract a key permits sharing with extracted from the Luna cryptographic module other crypto modules and archiving of key using the Wrap operation. material. EXTRACTABLE FALSE ­ Key material stored with the object may Keys must never leave a module's control. not be extracted from the Luna cryptographic module. The module does not allow any granularity of access other than owner or non-owner (i.e., a Private object cannot be accessible by two Partition Users and restricted to other Partition Users). Ownership of a Private object gives the owner access to the object through the allowed operations but does not allow the owner to assign a subset of rights to other operators. Allowed operations are those permitted by the cryptographic module and Partition Capability and Policy settings. The policy is summarized by the following statements: A subject may perform an allowed operation on an object if the object is in the partition with which the subject is associated and one of the following two conditions holds: 1. The object is a "Public" object, i.e., the PRIVATE attribute is FALSE, or 2. The subject is bound to the Partition User that owns the object. Allowed operations are those permitted by the object attribute definitions within the following constraints: 1. A Partition User in the Crypto User role has access to only the User operations, and 2. The restrictions imposed by the cryptographic module and Partition Capability and Policy settings. 3.5.1 Object Protection The module cryptographically protects the values of sensitive objects stored in its internal flash memory. Sensitive values are protected using AES 256 bit encryption with three different keys ­ each having a separate protection role. The three keys used to protect sensitive object values are the following: User Storage Key (USK) / Security Officer Master Key (SMK) ­ this key is created by the cryptographic module when the User or SO is created. It is used to maintain cryptographic separation between users' keys. Document is Uncontrolled When Printed. Page 25 of 46 CR-3397 Revision Level: 21 Master Tamper Key (MTK) ­ this key is securely stored in the battery-backed RAM. It encrypts keys as they are generated to ensure that they can only be used by the co- processor itself or with authorization from it. Key Encryption Key (KEK) ­ this key is stored in battery-backed RAM in the module. It also encrypts all sensitive object values and is used to provide the "decommissioning" feature. The KEK is erased in response to an external decommission signal. This provides the capability to prevent access to sensitive objects in the event that the module has become unresponsive or has lost access to primary power. 3.5.2 Object Re-use The access control policy is supported by an object re-use policy. The object re-use policy requires that the resources allocated to an object be cleared of their information content before they are re-allocated to a different object. 3.5.3 Privileged Functions The module shall restrict the performance of the following functions to the SO role only: Module initialization Partition creation and deletion Configuring the module and partition policies Module zeroization Firmware update 3.6 Cryptographic Material Management Cryptographic material (key) management functions protect the confidentiality of key material throughout its life-cycle. The FIPS PUB 140-2 approved key management functions provided by the module are the following: (1) Deterministic Random Bit Generation (DRBG) in accordance with NIST SP 800-90A section 10.2.1. (2) Cryptographic key generation in accordance with the following indicated standards: a. RSA 2048-4096 bits key pairs in accordance with FIPS PUB 186-2, FIPS PUB 186-4 and ANSI X9.31. b. Triple-DES 112 bits18 and 168 bits (SP 800-67). c. AES 128, 192, 256 bits (FIPS PUB 197). d. DSA 2048 and 3072 bit key pairs in accordance with FIPS PUB 186-2 and FIPS PUB 186- 4. e. Elliptic Curve key pairs (curves in accordance with SP 800-57) in accordance with FIPS PUB 186-2 and FIPS PUB 186-4. f. Diffie-Hellman key pairs. g. Key Derivation in accordance with NIST SP 800-108 (Counter mode). 18 To use the two-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 SP 800-131A for restriction information regarding its use until December 31, 2015. Document is Uncontrolled When Printed. Page 26 of 46 CR-3397 Revision Level: 21 (3) Diffie-Hellman (2048 bits) (key agreement; key establishment methodology provides 112 bits of encryption strength). 19 (4) EC Diffie-Hellman (ECDH) (curves in accordance with SP 800-57) key establishment in accordance with NIST SP 800-56A. (5) Symmetric key wrap / unwrap: Triple-DES 168 bits and AES 128, 192, and 256 bits in accordance with PKCS #11 (key transport provides 112 bits of security strength with Triple- DES and between 128 and 256 bits of security strength with AES). (6) Asymmetric key wrap / unwrap: RSA 2048 ­ 4096 (PKCS #1 V1.5 and OAEP) (key transport provides between 112 and 152 bits of security strength). (7) Encrypted key storage (using AES 256 bit encryption, see Section 3.5.1) and key access following the PKCS #11 standard. (8) Destruction of cryptographic keys is performed in one of three ways as described below in accordance with the PKCS #11 and FIPS PUB 140-2 standards: a. An object on a Luna cryptographic module that is destroyed using the PKCS #11 function C_DestroyObject is marked invalid and remains encrypted with the Partition User's key or a Luna cryptographic module's general secret key until such time as its memory locations (flash or RAM) are re-allocated for additional data on a Luna cryptographic module, at which time they are purged and zeroized before re-allocation. b. Objects on a Luna cryptographic module that are destroyed as a result of authentication failure are zeroized (all flash blocks in the Partition User's memory turned to 1's). If it is an SO authentication failure, all flash blocks used for key and data storage on a Luna cryptographic module are zeroized. c. Objects on a Luna cryptographic module that are destroyed through C_InitToken (the SO- accessible command to initialize a Luna cryptographic module available through the API) are zeroized, along with the rest of the flash memory being used by the SO and Partition Users. Keys are always stored as secret key or private key objects with the Sensitive attribute set. The key value is, therefore, stored in encrypted form using the owning Partition User's Storage Key (USK) and the Master Tamper Key (MTK) stored in the battery-backed RAM. Access to keys is never provided directly to a calling application. A handle to a particular key is returned which can be used by the application in subsequent calls to perform cryptographic operations. Private key and secret key objects may be imported into a module using the Unwrap, Unmask (if cloning and unmasking are enabled at the module level) or Derive operation under the control of the Access Control Policy. Any externally-set attributes of keys imported in this way are ignored by a module and their attributes are set by a module to values required by the Access Control Policy. 3.6.1 Key Cloning Key cloning is a Luna product feature that uses a one-time, 3-key Triple-DES key as a session key to encrypt an object being transferred from one Luna module to another. Objects transferred using the cloning protocol may be keys, user data, or module data. The Triple-DES session encrypting key is obtained by combining the 24 byte cloning domain value (randomly generated by the module) with random one-time data generated by source and target modules and exchanged using RSA 4096-based transport. 3.6.2 Key Mask / Unmask Key masking is a Luna product feature that uses a 256-bit AES key, which is unique to the module, to encrypt a key object for output in a way that ensures the key can only be imported, by 19 Non-approved but allowed method in FIPS mode. Document is Uncontrolled When Printed. Page 27 of 46 CR-3397 Revision Level: 21 unmasking, into the module from which it originally came or one that has been initialized to contain the same "master" key for the module. The key mask operation takes a key handle as input and uses the module's validated AES implementation to create the masked key output. The key unmask operation takes a masked (encrypted) key object as input, performs the necessary decryptions inside the module and returns a handle to the imported key. Note that for both mask and unmask operations, the user (or calling application acting on the user's behalf) never has access to the actual key values ­ only handles assigned to the key objects in the module. 3.6.3 Key Wrap / Unwrap The key wrap operation encrypts a key value for output, using either an RSA public key (only if wrapping a symmetric key) or a symmetric key to wrap either another symmetric key or an asymmetric private key. The unwrap operation takes as input an encrypted key value and a handle to the key that was originally used to do the wrapping. It decrypts the key value, stores it in the module as a key object and returns the handle to the imported key. Note that for both wrap and unwrap operations, the user (or calling application acting on the user's behalf) never has access to the actual key values ­ only handles assigned to the key objects in the module. 3.7 Cryptographic Operations Because of its generic nature, the module's cryptographic co-processor and firmware support a wide range of cryptographic algorithms and mechanisms. The approved cryptographic functions and algorithms that are relevant to the FIPS 140-2 validation are the following: 1. Symmetric encryption/decryption: Triple-DES 112 bits20 and 168 bits (SP 800-67). 2. Symmetric encryption/decryption: AES 128, 192, 256 bits (FIPS PUB 197). 3. Signature generation (FIPS PUB 186-4): RSA 2048-3072 bits (PKCS #1 V1.5) with SHA- 224, SHA-256, SHA-384, SHA-512, RSA 2048-3072 bits (PSS) with SHA-224, SHA-256, SHA-384, SHA-512, RSA 2048-3072 bits (ANSI X9.31) with SHA-224, SHA-256, SHA-384 and SHA-512; DSA 2048-3072 bits with SHA-224, SHA-256; ECDSA with SHA-224, SHA- 256, SHA-384, SHA-512. 4. Signature verification (FIPS PUB 186-4): RSA 1024-3072 bits (PKCS #1 V1.5) with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, RSA 1024-3072 bits (PSS) with SHA-1, SHA- 224, SHA-256, SHA-384, SHA-512, RSA 1024-3072 bits (ANSI X9.31) with SHA-1, SHA- 224, SHA-256, SHA-384 and SHA-512; DSA 1024-3072 bits with SHA-1, SHA-224, SHA- 256; ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512. 5. Signature generation (FIPS PUB 186-2): RSA 2048-4096 bits with SHA-224, SHA-256, SHA-384, SHA-512. 6. Signature verification (FIPS PUB 186-2): RSA 1024-4096 bits with SHA-1, SHA-224, SHA- 256, SHA-384, SHA-512; DSA 1024 bits with SHA-1. 7. Hash generation SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (FIPS PUB 180-4). 20 To use the two-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 SP 800-131A for restriction information regarding its use until December 31, 2015. Document is Uncontrolled When Printed. Page 28 of 46 CR-3397 Revision Level: 21 8. Keyed hash generation HMAC using SHA-121, SHA-224, SHA-256, SHA-384, SHA-512 (FIPS PUB 198-1). 9. Message authentication Triple-DES MAC (FIPS PUB 113) and CMAC (NIST SP 800-38B). 10. Deterministic Random Bit Generation (DRBG) (NIST SP 800-90A section 10.2.1) Table 3-4. Approved Security Functions for SafeXcel 3120 Approved Security Functions Certificate No. Symmetric Encryption/Decryption AES: (ECB, CBC, GCM); Encrypt/Decrypt; Key Size = 128, 192, 256) 2664 Triple-DES: (ECB, CBC); Encrypt/Decrypt KO 1,2) 22 1598 Hashing SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Byte Only) 2237 Message Authentication Code HMAC-SHA-123, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 1655 Triple-DES MAC (based on Certificate No. 1598) Vendor Affirmed Asymmetric RSA: FIPS186-2: ALG[ANSIX9.31]; KEYGEN(Y); (MOD: 2048, 3072, 4096 PubKey Values: 3, 17, 65537); SIG (gen); (MOD: 2048, 3072, 4096); SIG (ver) (MOD: 1024, 1536, 2048, 3072, 4096); ALG[RSASSA- 1369 PKCS1_V1_5]; SIG(gen); (MOD: 2048, 3072, 4096); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096); ALG[RSASSA-PSS]; SIG(gen) (MOD: 2048, 3072, 4096); SIG (ver) (MOD: 1024, 1536, 2048, 3072, 4096) DSA: FIPS186-4: PQG(gen): [ (2048, 224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ); ] KEYGEN: [ (2048,224); (2048,256) (3072,256) ] 804 SIG(gen): [ (2048,224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ); ] SIG(ver): [ (1024,160) SHA( 1 ); (2048,224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ); ] ECDSA: FIPS186-4: PKG: CURVES ( P-224; P-256; P-384) Testing Candidates SIG(gen): CURVES ( P-224: (SHA-224) P-256: (SHA-224, 256); P-384: (SHA-224, 256, 384) 461 SIG(ver): CURVES ( P-192: (SHA-1); P-224: (SHA-1, 224); P-256: (SHA-1, 224, 256) P-384: (SHA-1, 224, 256, 384) Random Number Generation NIST SP 800-90A DRBG (CTR) AES-256 428 21 Only keys of 112 bits or greater are allowed in FIPS mode when using HMAC-SHA-1. 22 To use the two-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 SP 800-131A for restriction information regarding its use until December 31, 2015. 23 Only keys of 112 bits or greater are allowed in FIPS mode when using HMAC-SHA-1. Document is Uncontrolled When Printed. Page 29 of 46 CR-3397 Revision Level: 21 Table 3-5. Approved Security Functions for SafeXcel 1746 Approved Security Functions Certificate No. Symmetric Encryption/Decryption AES: (ECB, CBC, CFB8); Encrypt/Decrypt; Key Size = 128, 192, 256) 1756 Triple-DES: (ECB, CBC, CFB8); Encrypt/Decrypt KO 1, 2) 24 1137 Message Authentication Code Triple-DES MAC (based on Certificate No. 1137) Vendor Affirmed Asymmetric DSA: FIPS186-2: SIG(ver) MOD (1024) 807 FIPS 186-4: SIG(gen): [ (2048,224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ) ] SIG(ver): [ (1024,160) SHA( 1 ); (2048,224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 )] ECDSA: FIPS186-2: SIG(ver): CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 B-571) FIPS186-4: PKG: CURVES( P-224 P-256 P-384 P-521 K-233 K-283 K-409 K-571 B-233 B-283 B-409 B- 571) Testing Candidates SIG(gen): CURVES( P-224: (SHA-224, 256, 384, 512) P-256: (SHA-224, 256, 384, 512) P-384: (SHA-224, 256, 384, 512) P-521: (SHA-224, 256, 384, 512) K-233: (SHA-224, 256, 384, 512) K-283: (SHA-224, 256, 384, 512) K-409: (SHA-224, 256, 384, 512) 463 K-571: (SHA-224, 256, 384, 512) B-233 (SHA-224, 256, 384, 512) B-283: (SHA-224, 256, 384, 512) B- 409: (SHA-224, 256, 384, 512) B-571: (SHA-224, 256, 384, 512) SIG(ver): CURVES( P-192: (SHA-1, 224, 256, 384, 512) P-224: (SHA-1, 224, 256, 384, 512) P-256: (SHA-1, 224, 256, 384, 512) P-384: (SHA-1, 224, 256, 384, 512) P-521: (SHA-1, 224, 256, 384, 512) K- 163: (SHA-1, 224, 256, 384, 512) K-233: (SHA-1, 224, 256, 384, 512) K-283: (SHA-1, 224, 256, 384, 512) K-409: (SHA-1, 224, 256, 384, 512) K-571: (SHA-1, 224, 256, 384, 512) B-163: (SHA-1, 224, 256, 384, 512) B-233 (SHA-1, 224, 256, 384, 512) B-283: (SHA-1, 224, 256, 384, 512) B-409: (SHA-1, 224, 256, 384, 512) B-571: (SHA-1, 224, 256, 384, 512) 24 To use the two-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 SP 800-131A for restriction information regarding its use until December 31, 2015. Document is Uncontrolled When Printed. Page 30 of 46 CR-3397 Revision Level: 21 Table 3-6. Approved Security Functions Firmware Implementation Approved Security Functions Certificate No. Symmetric Encryption/Decryption AES: (ECB, CBC, OFB, CFB8, CFB128 GCM); Encrypt/Decrypt; Key Size = 128, 192, 256) 2667 Triple-DES: (ECB, CBC, OFB, CFB8, CFB64); Encrypt/Decrypt KO 1,2) 25 1599 Hashing SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Byte Only) 2240 Message Authentication Code HMAC-SHA-126, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 1658 Triple-DES MAC (based on Certificate No. 1599) Vendor Affirmed AES CMAC (Key Sizes Tested: 128 192 256) 2667 Asymmetric RSA: FIPS186-2: [ANSIX9.31]; KEY(gen) (MOD: 2048, 3072, 4096 PubKey Values: 3, 17, 65,537 ); SIG (gen) ) (MOD: 2048, 3072, 4096); SIG (ver) (MOD: 1024, 1536, 2048, 3072, 4096); [RSASSA-PKCS1_V1_5]; SIG(gen) (MOD: 2048, 3072, 4096); SHA(224, 256, 384, 512); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096); SHA(1, 224, 256, 384, 512); [RSASSA-PSS]; SIG(gen) (MOD: 2048, 3072, 4096); SHA(224, 256, 384, 512); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096) SHA(1, 224, 256, 384, 512)) FIPS 186-4: 1371 [ANSIX9.31]; KEY(gen): (MOD: 2048, 3072); SIG(gen) (MOD: 2048 SHA(224, 256, 384, 512); 3072); SHA(224, 256, 384, 512) ; SIG (ver) (MOD: 1024 SHA(1, 256, 384, 512); 2048 SHA(1, 224, 256, 384, 512); 3072); SHA(1, 224, 256, 384, 512)); [RSASSA-PKCS1_V1_5]; SIG(gen) (MOD: 2048 SHA(224, 256, 384, 512); 3072); SHA(224, 256, 384, 512); SIG(ver); (MOD: 1024 SHA(1, 256, 384, 512); (2048 SHA(1, 224, 256, 384, 512); 3072; SHA(1, 224, 256, 384, 512); ALG[RSASSA-PSS]; SIG(gen) (MOD: 2048 SHA(224, 256, 384, 512); 3072); SHA(224, 256, 384, 512); SIG(ver); (MOD: 1024 SHA(1, 224, 256, 384, 512), 2048 SHA(1, 224, 256, 384, 512), 3072 SHA(1, 224, 256, 384, 512)) DSA: FIPS186-2: SIG(ver) MOD (1024) FIPS186-4: 806 KEYGEN: [ (2048, 224); (2048,256); (3072,256) ] SIG(gen): [ (2048, 224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ) ] SIG(ver): [ (1024,160) SHA( 1 ); (2048, 224) SHA( 224 ); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ) ] 25 To use the two-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 SP 800-131A for restriction information regarding its use until December 31, 2015. 26 Only keys of 112 bits or greater are allowed in FIPS mode when using HMAC-SHA-1. Document is Uncontrolled When Printed. Page 31 of 46 CR-3397 Revision Level: 21 Approved Security Functions Certificate No. ECDSA: FIPS186-2: PKG: CURVES( P-224 P-256 P-384 P-521 K-233 K-283 K-409 K-571 B-233 B-283 B-409 B- 571) SIG(ver): CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 B-571) FIPS186-4: PKG: CURVES( P-224 P-256 P-384 P-521 K-233 K-283 K-409 K-571 B-233 B-283 B-409 B- 571) Testing Candidates SIG(gen): CURVES( P-224: (SHA-224, 256, 384, 512) P-256: (SHA-224, 256, 384, 512) P-384: (SHA-224, 256, 384, 512) P-521: (SHA-224, 256, 384, 512) 462 K-233: (SHA-224, 256, 384, 512) K-283: (SHA-224, 256, 384, 512) K-409: (SHA-224, 256, 384, 512) K-571: (SHA-224, 256, 384, 512) B-233 (SHA-224, 256, 384, 512) B-283: (SHA-224, 256, 384, 512) B-409: (SHA-224, 256, 384, 512) B-571: (SHA-224, 256, 384, 512) SIG(ver): CURVES( P-192: (SHA-1, 224, 256, 384, 512) P-224: (SHA-1, 224, 256, 384, 512) P-256: (SHA- 1, 224, 256, 384, 512) P-384: (SHA-1, 224, 256, 384, 512) P-521: (SHA-1, 224, 256, 384, 512) K-163: (SHA-1, 224, 256, 384, 512) K-233: (SHA-1, 224, 256, 384, 512) K-283: (SHA-1, 224, 256, 384, 512) K-409: (SHA-1, 224, 256, 384, 512) K-571: (SHA-1, 224, 256, 384, 512) B-163: (SHA-1, 224, 256, 384, 512) B-233 (SHA-1, 224, 256, 384, 512) B-283: (SHA-1, 224, 256, 384, 512) B-409: (SHA-1, 224, 256, 384, 512) B-571: (SHA-1, 224, 256, 384, 512) Key Agreement Scheme ECC: ( ASSURANCES ) SCHEMES [ Ephemeral Unified ( KARole(s): Initiator / Responder ) ( ( EB: P-224 SHA224 SHA256 SHA384 SHA512 ) ( EC: P-256 SHA256 SHA384 SHA512 ) ( ED: P-384 SHA384 SHA512 ) ( EE: P-521 ) ] 43 [ OnePassDH ( No_KC: [N/A] ) ( KARole(s): Initiator / Responder ) ( EB: P-224 SHA224 SHA256 SHA384 SHA512 HMAC ) ( EC: P-256 SHA256 SHA384 SHA512 HMAC ) ( ED: P-384 SHA384 SHA512 HMAC ) ( EE: P-521 ) ] Key Based Key Derivation Functions (KBKDF) NIST SP 800-108 (Counter Mode) 14 Table 3-7. Allowed Security Function for the Firmware Implementation Allowed Security Functions Key Agreement Diffie-Hellman (key agreement; key establishment methodology provides 112 bits of encryption strength). Key Transport RSA (key wrapping; key establishment methodology provides between 112 and 152 bits of encryption strength) AES (key wrapping; key establishment methodology provides between 128 and 256 bits of encryption strength) Triple-DES (key wrapping; key establishment methodology provides 112 bits of encryption strength) Non-FIPS Approved security functions are not available for use when the module has been configured to operate in FIPS-approved mode, see section 3.2. Document is Uncontrolled When Printed. Page 32 of 46 CR-3397 Revision Level: 21 Table 3-8. Non-FIPS Approved Security Functions Non-FIPS Approved Security Functions Symmetric Encryption/Decryption DES RC2 RC4 RC5 CAST5 SEED ARIA Hashing MD2 MD5 HAS-160 Message Authentication Code AES MAC (non-compliant) DES-MAC RC2-MAC RC5-MAC CAST5-MAC SSL3-MD5-MAC27 SSL3-SHA1-MAC28 HMAC (Cert #1658, Cert #1655 ­ non-compliant less than 112 bits of encryption strength) Asymmetric KCDSA 27 Used by the TLS protocol. TLS has not been reviewed or tested by the CAVP or the CMVP. 28 Used by the TLS protocol. TLS has not been reviewed or tested by the CAVP or the CMVP. Document is Uncontrolled When Printed. Page 33 of 46 CR-3397 Revision Level: 21 RSA X-509 RSA (Cert #1369, Cert #1371 ­ non compliant less than 112 bits of encryption strength) DSA (Cert #804, Cert #806, Cert #807 ­ non-compliant less than 112 bits of encryption strength) ECDSA (Cert #461, Cert #462, Cert #463 ­ non-compliant less than 112 bits of encryption strength) Generate Key DES RC2 RC4 RC5 CAST5 SEED ARIA GENERIC-SECRET SSL PRE-MASTER29 Key Agreement ECC (non-compliant less than 112 bits of encryption strength) Diffie-Hellman (key agreement; key establishment methodology; non-compliant less than 112 bits) Key Transport RSA (key wrapping; key establishment methodology; non-compliant less than 112 bits of encryption strength) Entropy Source Hardware Random Number Generator (free-running local oscillators) 29 Used by the TLS protocol. TLS has not been reviewed or tested by the CAVP or the CMVP. Document is Uncontrolled When Printed. Page 34 of 46 CR-3397 Revision Level: 21 3.8 Self-tests The module provides self-tests on power-up and on request to confirm the firmware integrity, and to check the random number generator and each of the implemented cryptographic algorithms. Table 3-9. Module Self-Tests Test When Performed Where Performed Indicator Boot loader performs a SHA-1 integrity check of Power-on Firmware Module halt30 the firmware prior to firmware start ECDSA integrity check of the binary running on the Power-on Hardware Module Halt hardware DRBG Instantiate Function Known Answer Test Power-on Hardware Module halt (KAT) DRBG Generate Function KAT Power-on Hardware Module halt DRBG Reseed Function KAT Power-on Hardware Module halt DRBG Uninstantiate Function KAT Power-on Hardware Module halt Triple-DES KATs (e / d) Power-on/Request Firmware / Hardware Module halt / Error - Halt31 SHA-1 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt SHA-224 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt SHA-256 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt SHA-384 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt SHA-512 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt HMAC SHA-1 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt HMAC SHA-224 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt HMAC SHA-256 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt HMAC SHA-384 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt HMAC SHA-512 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt RSA sig-gen KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt RSA sig-ver KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt DSA sig-gen KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt DSA sig-ver KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt Diffie-Hellman KAT Power-on/Request Firmware Module halt / Error - Halt AES KATs (e / d) Power-on/Request Firmware / Hardware Module halt / Error - Halt AES-GCM KAT (e / d) Power-on/Request Firmware / Hardware Module halt / Error - Halt ECDH KAT Power-on/Request Firmware Module halt / Error - Halt ECDSA sig-gen KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt ECDSA sig-ver KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt KDF KAT Power-on/Request Firmware Module halt / Error - Halt DRBG conditional tests Continuous Firmware / Hardware Error - Halt HRNG conditional tests Continuous Firmware / Hardware Error - Halt RSA ­ Pair-wise consistency test (asymmetric key On generation Firmware / Hardware Error pairs) DSA ­ Pair-wise consistency test (asymmetric key On generation Firmware / Hardware Error pairs) ECDSA ­ Pair-wise consistency test (asymmetric On generation Firmware / Hardware Error key pairs) 30 Details of the failure can be obtained from the dual-port following a module halt. 31 An error message is output, the cryptographic module halts, and data output is inhibited. Document is Uncontrolled When Printed. Page 35 of 46 CR-3397 Revision Level: 21 Test When Performed Where Performed Indicator Firmware load test (4096-bit RSA sig ver) On firmware Firmware Error ­ module will continue update load with existing firmware While the module is running Power-On Self Tests (POST) all interfaces are disabled until the successful completion of the self-tests. 3.9 Firmware Security The Firmware Security Policy assumes that any firmware images loaded in conformance with the policy have been verified by SafeNet to ensure that the firmware will function correctly. The policy applies to initial firmware loading and subsequent firmware updates. The module shall not allow external software32 to be loaded inside its boundary. Only properly formatted firmware may be loaded. The communication of initial or updated firmware to a target module shall be initiated by a SafeNet module dedicated to that function. Firmware shall be digitally signed using the SafeNet Manufacturing signature key and encrypted using a secret key that can be derived (based on an internally held secret key) by the receiving module for decryption. RSA (4096 bits) PKCS #1 V1.5 with SHA-256 is used as the approved signature method. The unencrypted firmware must not be visible outside a module before, during and after the loading operation. The Boot Loader shall provide an integrity check to ensure the integrity of the firmware and to ensure the integrity of any permanent security-critical data stored within a cryptographic module. 3.10 Physical Security The Luna cryptographic module is a multi-chip embedded module as defined by FIPS PUB 140-2 section 4.5. The module is enclosed in a strong metal enclosure that provides tamper-evidence. Any tampering that might compromise a module's security is detectable by visual inspection of the physical integrity of a module. The Security Officer should perform a visual inspection of the module at regular intervals. Within the metal enclosure, a hard opaque epoxy covers the circuitry of the cryptographic module. Attempts to remove this epoxy will cause sufficient damage to the cryptographic module so that it is rendered inoperable. The module's enclosure is opaque to resist visual inspection of the device design, physical probing of the device and attempts to access sensitive data on individual components of the device. The plaintext Critical Security Parameters (CSPs) stored inside the module are the Master Tamper Key (MTK), the Key Encryption Key (KEK) and the Token/Module Variable Key (TVK), which is used to implement the auto-activation feature. The MTK, KEK and TVK are stored in battery- backed RAM. The MTK and TVK are erased in the event of a tamper detection ­ either from the external tamper signal or removal of the card from the PCI-Express slot. The KEK is erased when a decommission signal is received. The module is designed to operate between 0 and 65 degrees Celsius, and to sense and respond to out-of-range temperature conditions. The module also senses and responds to out-of-range voltage conditions. In the event that the module senses an out-of-range temperature or voltage, it will clear all working memory and halt operations. It can be reset and placed back into operation when proper operating conditions have been restored. The epoxy hardness was tested at room temperature and at the high and low temperatures which would cause the active tamper (0 to 65 degrees Celsius). 3.10.1 Secure Recovery 32External software means any form of executable code that has been generated by anyone other than SafeNet and has not been properly formatted and signed as a legitimate SafeNet firmware image. Document is Uncontrolled When Printed. Page 36 of 46 CR-3397 Revision Level: 21 When the MTK is created, two splits are also created ­ one split is held within the battery-backed RAM and the other is passed to the module firmware. The module's split can then be written out to iKey (Purple Key) tokens, using the M of N feature. These iKeys are known as Secure Recovery Keys (SRKs). If a tamper event occurs, it is possible to return the module to operation, after ensuring the tamper condition has been cleared, by recovering the MTK from the internal split and the value(s) stored on the external SRK iKey token(s). The Secure Recovery feature can also be used to enable secure shipment of the module. This is done by invoking a cryptographic module command that deliberately erases the MTK and flags the operation as being a "secure transport" operation, rather than an actual tamper event. This ensures that the module's sensitive objects are cryptographically protected and the module cannot be used in a malicious fashion while it is en route to its destination. At the receiving site, the module can be put into operation using the Secure Recovery feature. 3.11 EMI / EMC The module conforms to FCC Part 15 Class B requirements for home use. 3.12 Fault Tolerance If power is lost to a module for whatever reason, the module shall, at a minimum, maintain itself in a state that it can be placed back into operation when power is restored without compromise of its functionality or permanently stored data. A module shall maintain its secure state33 in the event of data input / output failures. When data input / output capability is restored the module will resume operation in the state it was prior to the input / output failure. 3.13 Mitigation of Other Attacks Timing attacks are mitigated directly by a module through the use of hardware accelerator chips for modular exponentiation operations. The use of hardware acceleration ensures that all RSA signature operations complete in very nearly the same time, therefore making the analysis of timing differences irrelevant. RSA blinding may also be selected as an option to mitigate this type of attack. The cryptographic module provides a connection to allow it to receive an external tamper event signal34. By responding to the signal a module can ensure that no sensitive data remain even if a determined attack defeats the external physical security protection measures. There are two sources for a potential tamper signal. The first is circuitry to detect the removal of a module from a PCI-Express slot. By responding to this external signal, the module ensures that all plaintext sensitive data are cleared if a module is removed from its slot. The second source is used only in the instance of an appliance installation. In that case, the signal would come from tamper detection circuitry that detects opening of the appliance cover. By responding to this external signal, the module ensures that all plaintext sensitive data are cleared if the appliance cover is opened. 33 A secure state is one in which either a Luna cryptographic module is operational and its security policy enforcement is functioning correctly, or it is not operational and all sensitive material is stored in a cryptographically protected form on a Luna cryptographic module. 34 This is external to the cryptographic boundary. Document is Uncontrolled When Printed. Page 37 of 46 CR-3397 Revision Level: 21 APPENDIX A. SECURITY POLICY CHECKLIST TABLES Table A-1. Roles and Required Identification and Authentication Role Type of Authentication Authentication Data Security Officer Identity-based Level 3 ­ Authentication token (PED Key ­ one per module) plus optional PED PIN Audit Officer Identity-based Level 3 ­ Authentication token (PED Key ­ one per module) plus optional PED PIN Crypto Officer Identity-based35 Level 3 ­ Authentication token (PED Key ­ one per user) plus optional PED PIN, plus optional Challenge Secret for the role36 Crypto User Identity-based Level 3 ­ Authentication token (PED Key ­ one per user) plus optional PED PIN, plus optional Challenge Secret for the role Public User Not required N/A Table A-2. Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism PED Key (Level 3) plus PIN 48 byte random authentication data stored on PED key plus PIN entered via PED key pad (minimum 4 bytes). It is obvious that the probability of guessing the authentication data in a single attempt is 1 in 2384. With login failure thresholds of 3 for SO and configurable from 1 to 10 (default 10) for users, this ensures the FIPS 140-2 required thresholds can never be reached. Challenge Secret (Level 3) Default 16 character random string (minimum 7 character string). The probability of guessing the challenge secret in a single attempt is 1 in 627 (approximately 3.5 x 1012). With login failure thresholds of 3 for SO and configurable from 1 to 10 (default 10) for users, this ensures the FIPS 140-2 required thresholds can never be reached. All services listed in Table A-3 can be accessed in FIPS and non-FIPS mode. The services listed in Table A-3 use the security functions listed in Table 3-4, Table 3-5, Table 3-6, Table 3-7, and Table 3- 8. When the module is operating in FIPS-approved mode as described in Section 3.2, the Non-FIPS Approved Security Functions in Table 3-8 are disabled and cannot be used for these services. The non-Approved functions in Table 3-8 can only be accessed through the services when the module is in non-FIPS Approved mode. 35 The Crypto Officer and Crypto User both apply to the same partition, i.e., identity. They are distinguished by different challenge values representing the two different roles. 36 If activation or auto-activation is enabled, challenge secret is required in FIPS mode. Document is Uncontrolled When Printed. Page 38 of 46 CR-3397 Revision Level: 21 Table A-3. Services Authorized for Roles Role Authorized Services Security Officer Show Status, Self-test, Initialize Module, Configure Module Policy, Create Partition, Configure Partition Policy, Zeroize, Firmware Update Audit Officer Show Status, Initialize and Configure Secure Audit Logging, Change Audit Officer's Password, Verify Secure Audit Log Files, Import and Export Secure Audit Log Files, Synchronize Module Clock with the Clock of the Host System, Import and Export the Wrapped Secure Audit Logging Key, Show Secure Audit Log Status. Crypto Officer Show Status, Self-test, Key and Key Pair Generation, Symmetric Encrypt/Decrypt, Asymmetric Signature/Verification, Symmetric & Asymmetric Key Wrap/Unwrap, Symmetric & Asymmetric Key Mask/Unmask, Store Data Object, Read Data Object, Partition Backup and Restore Crypto User Show Status, Self-test, Symmetric Encrypt/Decrypt, Asymmetric Signature/Verification, Store Data Object, Read Data Object Public User Show Status, Self-test, Store Public Data Object, Read Public Data Object Table A-4. Access Rights within Services Service Cryptographic Keys and CSPs Role Type(s) of Access 37 Show Status N/A All N/A Self-test N/A SO N/A Crypto Officer Crypto User Public User Initialize Module Authentication data via trusted path SO Write ­ SO authentication data Configure Module Policy Authentication data via trusted path SO Use38 Create Partition Authentication data via trusted path SO Write ­ User authentication data Configure Partition Policy Authentication data via trusted path SO Use Zeroize Authentication data, symmetric keys, SO Write, Erase asymmetric key pairs Firmware Update MVK39 SO Use, Write (firmware only) Key and Key Pair Symmetric keys, asymmetric key pairs Crypto Officer Write Generation Symmetric Key Wrap/ Symmetric with RSA Crypto Officer Use, Write Unwrap Symmetric with Symmetric ECB mode40 Asymmetric Key Wrap/ Asymmetric with Symmetric CBC mode41 Crypto Officer Use, Write Unwrap Symmetric Key Mask/ Symmetric with AES 256 Crypto Officer Use, Write Unmask Asymmetric Key Mask/ Symmetric with AES 256 Crypto Officer Use, Write 37 Show status is provided by invoking the "hsm showinfo" command from the administrative interface. It will display identifying information about the module such as label, serial number, firmware version, etc., and state whether the module is in FIPS-approved mode. 38 Use means access to key material for use in performing a cryptographic operation. The key material is never visible. 39 Public key value. See Table A-5 for its description. 40 That is, the keys used during Symmetric Key Wrap/ Unwrap operations are a symmetric key wrapping key and the (symmetric or asymmetric) key which is being wrapped. 41 That is, the keys used during Asymmetric Key Wrap / Unwrap operations are an asymmetric key wrapping key and the symmetric key which is being wrapped. Document is Uncontrolled When Printed. Page 39 of 46 CR-3397 Revision Level: 21 Table A-4. Access Rights within Services Service Cryptographic Keys and CSPs Role Type(s) of Access Unmask Partition Backup / Restore Symmetric keys, asymmetric key pairs Crypto Officer Transfer42 Symmetric Symmetric keys Crypto Officer, Use Encrypt/Decrypt Crypto User Asymmetric Signature RSA, DSA private keys Crypto Officer, Use Crypto User Asymmetric Verification RSA, DSA public keys Crypto Officer, Use Crypto User Store Data Object Non-cryptographic data Crypto Officer, Write Crypto User, Public User43 Read Data Object Non-cryptographic data Crypto Officer, Read Crypto User, Public User44 Initialize Secure Audit Symmetric keys Audit Officer Write Logging Change Audit Officer's Authentication Data via trusted path Audit Officer Read, Write Password Configure Secure Audit N/A Audit Officer Read, Write Logging Synchronize Module's N/A Audit Officer Write clock with the Host system's clock Verify, Import, and Export N/A Audit Officer Read secure audit log files Show secure audit log N/A Audit Officer Read status Import and Export the Symmetric keys Audit Officer Write, Read Wrapped Secure Audit Logging Key 42 Transfer means moving a key using the cloning protocol from one cryptographic module to another. 43 The Public User has access to Public Data Objects only. 44 The Public User has access to Public Data Objects only. Document is Uncontrolled When Printed. Page 40 of 46 CR-3397 Revision Level: 21 Table A-5 Keys and Critical Security Parameters Used in the Module Keys and CSPS CSP Type Generation Input / Output Storage Destruction Description Used in Trusted Path Authentication configuration only. 16 character random string Output via direct Flash memory 16 character data AES-CTR generated by the cryptographic module and Challenge Secret connection to encrypted with N/A string DRBG output via the PED display when the user is PED SGSK created. It is input by the operator as the authentication data for a client application login. Used in Trusted Path Authentication configuration only. A one-time random number Output to host generated by the cryptographic module and sent One-time random AES-CTR using ICD Working RAM in Random Challenge Power Cycle to the calling application for each login. It is number DRBG communication plaintext combined with the input Challenge Secret to path compute the one-time response that is returned to the cryptographic module. Input from host A 20-byte value used for authentication in the using ICD Working RAM in challenge response scheme. It is generated Challenge Response 20-byte value N/A Power Cycle communication plaintext using the challenge secret and the one-time path random challenge value. Used in Trusted Path Authentication Input / Output via configuration. A 48-byte random value that is PED45 Key (or iKey) 48-byte random AES-CTR Flash memory direct connection N/A generated by the module when the SO or User is Authentication Data value DRBG encrypted to PED created. It is written out to the serial memory device (PED key) via the Trusted Path. Input on the PED via secure An optional PIN value used for authentication Not stored On Optional PIN PIN N/A channel. PED N/A along with the PED key. It must be a minimum module does not input or of 4-bytes long output the PIN. 48-byte value that is used to control a module's ability to participate in the cloning protocol. It is Output via direct Flash Memory either generated by the module or imprinted onto AES-CTR Cloning Domain Vector 48-Byte value connection to encrypted with N/A the module at the time the module is initialized. DRBG PED USK The value is output from the original module in the domain onto a PED key to enable initializing additional modules into the same domain. This key is used to encrypt all sensitive attributes User Storage Key AES-CTR Not Input or Flash memory of all private objects owned by the user. AES-256 N/A (USK) DRBG Output encrypted Encrypted, as part of the UAV, by the key taken from the PED key data. 45 Within this document the terms "PED" key and "iKey" are interchangeable unless otherwise indicated. Document is Uncontrolled When Printed. Page 41 of 46 CR-3397 Revision Level: 21 Table A-5 Keys and Critical Security Parameters Used in the Module Keys and CSPS CSP Type Generation Input / Output Storage Destruction Description The storage key for the SO. This key is used to encrypt all sensitive attributes of all private Security Officer Master AES-CTR Not Input or Flash memory objects owned by the SO. The USK/SMK is AES-256 N/A Key (SMK) DRBG Output encrypted stored encrypted using an AES key, which is the first 32 bytes of the User/SO PED key Authentication data (plus optional PIN). 32-byte AES key that is the same for all users on a specific Luna cryptographic module. It is used Global Storage Key AES-CTR Not Input or Flash memory to encrypt permanent parameters within the non- AES-256 N/A (GSK) DRBG Output encrypted volatile memory area reserved for use by the module. Encrypted, as part of the UAV, by the key taken from the PED key data. Flash memory It is used to encrypt non-permanent parameters Secondary Global AES-CTR Not Input or AES-256 encrypted with N/A (parameters re-generated for every module Storage Key (SGSK) DRBG Output USKs and SMK initialization). Flash memory Token or Module RSA-2048 bit private Not Input or A 2048-bit RSA private key used in the cloning ANSI X9.31 encrypted with N/A Unwrapping Key (TUK) key Output protocol. GSK Token or Module RSA-2048 Public Key Used in exchange of session encryption key as Loaded at Flash memory Wrapping Certificate public/private Output in N/A part of the handshake during the cloning Manufacturing plaintext (TWC) certificate Plaintext protocol. 24-byte Triple-DES key used in conjunction with the auth code for a firmware update to derive a Flash memory AES-CTR Not Input or key used to decrypt the firmware update image U2 Key 3-Key Triple-DES encrypted with N/A DRBG Output when it is loaded into the module. Used for GSK backwards compatibility purposes with earlier firmware versions. It is used to encrypt authentication data stored Token or Module AES-CTR Not Input or Tamperable Zeroized as part of a for auto-activation purposes. The non-volatile AES-256 Variable Key (TVK) DRBG Output BBRAM in plaintext tamper event RAM is actively zeroized in response to a tamper event. Master Tamper Key AES-CTR Not Input or Tamperable Zeroized as part of a AES-256 The MTK encrypts all sensitive values (MTK) DRBG Output BBRAM in plaintext tamper event Key Encryption Key AES-CTR Output Tamperable Zeroized as part of a The KEK encrypts all sensitive values and is AES-256 (KEK) DRBG Encrypted BBRAM in plaintext decommission signal zeroized in response to a decommission signal. Flash memory AES-CTR Not Input or AES 256-bit key used during masking Masking Key AES-256 encrypted with N/A DRBG Output operations. Stored encrypted using the SGSK. SGSK Used in verifying Hardware Origin Certificates Manufacturer's Integrity RSA-4096 public Loaded at Not Input or Flash memory in (HOCs), which are generated in response to a N/A Certificate (MIC) key certificate manufacturing Output plaintext customer function call to provide proof of hardware origin. Document is Uncontrolled When Printed. Page 42 of 46 CR-3397 Revision Level: 21 Table A-5 Keys and Critical Security Parameters Used in the Module Keys and CSPS CSP Type Generation Input / Output Storage Destruction Description 1024-bit public key counterpart to the Manufacturers RSA-1024 public Loaded at Not Input or Flash memory in N/A Manufacturer's Signature Key (MSK) held at Verification Key (MVK) key manufacturing Output plaintext SafeNet. Used for key migration support for legacy HSMs. 2048-bit RSA private key used for a specific PKI Flash memory Device Authentication RSA 2048 bit private Not Input or implementation requiring assurance that a key or ANSI X9.31 encrypted with N/A Key (DAK) key Output a specific action originated within the hardware GSK crypto module. A 4096 bit RSA private key used to sign Flash memory Hardware Origin Key RSA 4096 bit private Not Input or certificates for other device key pairs, such as ANSI X9.31 encrypted with N/A (HOK) key Output the TWC. It is generated at the time the device GSK is manufactured. Document is Uncontrolled When Printed. Page 43 of 46 CR-3397 Revision Level: 21 Table A-5 Keys and Critical Security Parameters Used in the Module Keys and CSPS CSP Type Generation Input / Output Storage Destruction Description The X.509 public key certificate corresponding to Hardware Origin RSA-4096 public Loaded at Not Input or Flash memory in the HOK. It is signed by the Manufacturer's N/A Certificate (HOC) key certificate manufacturing Output plaintext Integrity Key (MIK) at the time the device is manufactured. A randomly generated 256-bit secret, which Input / Output via Remote PED Vector AES-CTR Flash memory in Zeroized via ICD must be shared between a remote PED and a 256-bit secret value direct connection (RPV) DRBG plaintext command cryptographic module in order to establish a to PED secure communication channel between them. A split of the MTK that is written to one or more Flash memory Secure Recovery Split of AES-256 AES-CTR Split output in iKeys using the M of N secret splitting scheme encrypted with N/A Vector (SRV) MTK DRBG plaintext and used to recover the MTK after a tamper GSK event has been cleared. 32 bytes AES key stored in the BBRAM of the Hardware Not Input or Tamperable Zeroized as part of a internal security co-processor. Used in the DRBG Key AES-256 Random Output BBRAM in plaintext tamper event implementation of the NIST SP 800-90A CTR Source (AES) DRBG. Random seed data drawn from the Hardware Hardware Not Input or Tamperable Zeroized as part of a RBG in the security co-processor and used to DRBG Seed 384 bits Random Output BBRAM in plaintext tamper event seed the implementation of the NIST SP 800- Source 90A CTR (AES) DRBG. Part of the secret state of the approved DRBG. H/W Random Not Input or Tamperable Zeroized as part of a The value is stored in the security co-processor DRBG V 128 bits Source Output BBRAM in plaintext tamper event as plaintext and is generated using the methods described in NIST SP 800-90A. The entropy value used to initialize the approved H/W Random Not Input or Tamperable Zeroized as part of a DRBG Entropy Input 384 bits DRBG. The 48-byte value is stored ephemerally Source Output BBRAM in plaintext tamper event in memory of the security co-processor. Flash memory in Secure Audit Logging A 256-bit key used to verify data integrity and AES-CTR Input / Output plaintext and Key (SALK) 256 bit HMAC N/A authentication of the log messages. Saved in the DRBG encrypted encrypted with parameter area of Flash memory. SADK Flash Memory A 256-bit key that is used to wrap/unwrap the Secure Audit Domain AES-CTR Input / Output AES-256 encrypted with N/A SALK when it is exported / imported from / to the Key (SADK) DRBG encrypted USK module. Document is Uncontrolled When Printed. Page 44 of 46 CR-3397 Revision Level: 21 APPENDIX B. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS Term Definition ANSI American National Standards Institute CA Certification Authority Chrysalis-ITS Former name of SafeNet Canada, Inc. CKE Key Export with RA CL Cloning (a capability configuration used to allow the secure transfer of key objects from one module to another for backup and restore and object replication purposes). CLI Command Line Interface CO Crypto Officer CRC Cyclic Redundancy Check CRT Chinese Remainder Theorem CSP Critical Security Parameter CU Crypto User DAK Device Authentication Key DH Diffie Hellman DRBG Deterministic Random Bit Generator ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie Hellman FIPS Federal Information Processing Standard GSK Global Storage Key HA High Assurance HOC Hardware Origin Certificate HOK Hardware Origin Key HRNG Hardware Random Number Generator HSM Hardware Security Module KAT Known Answer Test KDF Key Derivation Function KEK Key Encryption Key MAC Message Authentication Code Masking A SafeNet term to describe the encryption of a key for use only within a SafeNet cryptographic module. MIC Manufacturer's Integrity Certificate MIK Manufacturer's Integrity Key MSK Manufacturer's Signature Key MTK Master Tamper Key MVK Manufacturers Verification Key PCI Peripheral Component Interconnect PED PIN Entry Device PIN Personal Identification Number PKCS Public-Key Cryptography Standards PRNG Pseudo-Random Number Generator Document is Uncontrolled When Printed. Page 45 of 46 CR-3397 Revision Level: 21 Term Definition RA Registration Authority RNG Random Number Generator RPED Remote PED RPK Remote PED Key RPV Remote PED Vector SA Server-Attached SADK Secure Audit Domain Key SALK Secure Audit Logging Key SCU Secure Capability Update SGSK Secondary Global Storage Key SHS Secure Hash Standard SMK Security Officer's Master Key SNC Signing No Cloning SO Security Officer SRK Secure Recovery Key TUK Token or Module Unwrapping Key TVK Token or Module Variable Key TWC Token or Module Wrapping Certificate TWK Token or Module Wrapping Key USK User's Storage Key Document is Uncontrolled When Printed. Page 46 of 46