Document is uncontrolled when printed.
LEVEL 3 NON-PROPRIETARY SECURITY
POLICY FOR
Luna® PCI-e Cryptographic Module
(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-4126
REVISION LEVEL: 1
REVISION DATE: July 7, 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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page i of iv
PREFACE
This document deals only with operations and capabilities of the Luna® PCI-e Cryptographic
Module 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/company/contact.asp.
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:
U.S. (800) 533-3958
International +1 (410) 931-7500
SafeNet Technical Support:
U.S. (800) 545-6608
International +1 (410) 931-7520
SafeNet Customer Service:
U.S. (866) 251-4269
EMEA +44 (0) 1276 60 80 00
APAC 852 3157 7111
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page ii of iv
TABLE OF CONTENTS
Section Title Page
1. INTRODUCTION..................................................................................................................................... 1
1.1 Purpose............................................................................................................................................ 1
1.2 Scope ............................................................................................................................................... 1
1.3 Overview .......................................................................................................................................... 1
2. SECURITY POLICY MODEL INTRODUCTION..................................................................................... 2
2.1 Functional Overview......................................................................................................................... 2
2.2 Assets to be Protected ..................................................................................................................... 3
2.3 Operating Environment .................................................................................................................... 4
3. SECURITY POLICY MODEL DESCRIPTION........................................................................................ 4
3.1 Operational Policy ............................................................................................................................ 5
3.1.1 Module Capabilities................................................................................................................... 5
3.1.2 Partition Capabilities ................................................................................................................. 6
3.2 FIPS-Approved Mode..................................................................................................................... 13
3.3 Description of Operator, Subject and Object ................................................................................. 13
3.3.1 Operator.................................................................................................................................. 13
3.3.2 Roles....................................................................................................................................... 13
3.3.3 Account Data .......................................................................................................................... 14
3.3.4 Subject .................................................................................................................................... 15
3.3.5 Operator – Subject Binding..................................................................................................... 15
3.3.6 Object...................................................................................................................................... 15
3.3.7 Object Operations................................................................................................................... 15
3.4 Identification and Authentication .................................................................................................... 16
3.4.1 Authentication Data Generation and Entry ............................................................................. 16
3.4.2 Trusted Path ........................................................................................................................... 17
3.4.2.1. Remote PED Operation................................................................................................... 17
3.4.3 M of N Authentication.............................................................................................................. 18
3.4.4 Limits on Login Failures.......................................................................................................... 18
3.5 Access Control ............................................................................................................................... 18
3.5.1 Object Protection .................................................................................................................... 20
3.5.2 Object Re-use......................................................................................................................... 20
3.5.3 Privileged Functions................................................................................................................ 20
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page iii of iv
3.6 Cryptographic Material Management............................................................................................. 21
3.7 Cryptographic Operations .............................................................................................................. 22
3.8 Self-tests ........................................................................................................................................ 28
3.9 Firmware Security .......................................................................................................................... 29
3.10 Physical Security ........................................................................................................................ 29
3.10.1 Secure Recovery .................................................................................................................... 30
3.11 EMI / EMC .................................................................................................................................. 30
3.12 Fault Tolerance........................................................................................................................... 30
3.13 Mitigation of Other Attacks ......................................................................................................... 30
LIST OF TABLES
Table Title Page
Table 1-1. FIPS 140-2 Security Requirements.............................................................................................1
Table 3-1. Module Capabilities and Policies ................................................................................................7
Table 3-2. Partition Capabilities and Policies ...............................................................................................9
Table 3-3. Object Attributes Used in Access Control Policy Enforcement.................................................19
Table 3-4. Approved and Allowed Security Functions for SafeXcel 3120..................................................22
Table 3-5. Approved and Allowed Security Functions for SafeXcel 1746..................................................23
Table 3-6. Approved and Allowed Security Functions Firmware Implementation......................................24
Table 3-7 – Non-FIPS Approved Security Functions ..................................................................................27
Table 3-8. Module Self-Tests .....................................................................................................................28
Table A-1. Roles and Required Identification and Authentication................................................................1
Table A-2. Strengths of Authentication Mechanisms ...................................................................................1
Table A-3. Services Authorized for Roles ....................................................................................................1
Table A-4. Access Rights within Services ....................................................................................................2
Table A-5 Keys and Critical Security Parameters Used in the Module ........................................................3
LIST OF FIGURES
Figure Title Page
Figure 2-1. Luna PCI-e Cryptographic Module.............................................................................................3
Figure 2-2. Luna SA with PCI-e Installed .....................................................................................................3
LIST OF APPENDICES
Appendix Title Page
APPENDIX A. SECURITY POLICY CHECKLIST TABLES .....................................................................1
APPENDIX B. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS.................................................1
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page iv of iv
- THIS PAGE LEFT BLANK INTENTIONALLY -
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 1 of 30
1. INTRODUCTION
1.1 Purpose
This document describes the security policies enforced by SafeNet Inc.’s Luna® PCI-e cryptographic
module1.
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 Versions VBD-05-0100, VBD-05-0101, and VBD-05-01032 with
Firmware Versions 6.2.1 and 6.2.5.
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.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
1 Also known as the K6 or the cryptographic module.
2 From the perspectives of functionality and physical security, hardware versions VBD-05-0100, VBD-05-0101, and VBD-
05-0103 are equivalent.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 2 of 30
Table 1-1. FIPS 140-2 Security Requirements
Security Requirements Section Level
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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 3 of 30
Figure 2-1. Luna PCI-e Cryptographic Module
Figure 2-2. Luna SA with PCI-e Installed
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.
Cryptographic
Boundary
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 4 of 30
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.
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.
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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 5 of 30
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 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 settings3 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.
 Allow/disallow cloning.
 Allow/disallow masking4.
 Allow/disallow unmasking.
 Allow/disallow Korean algorithms5
3 The nomenclature used for these setting is based on PKCS#11.
4 A SafeNet term used to describe the encryption of a key for use only within a SafeNet cryptographic module.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 6 of 30
 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
 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)
5 Korean algorithms include SEED, ARIA, and KCDSA.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 7 of 30
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 masking6.
 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
Non-FIPS algorithms
available
Allow X X X
Enable SO can configure the policy to enable or disable the availability of non-
FIPS algorithms at the time the cryptographic module is initialized.
Disable
Disallow Disable
The cryptographic module must operate using FIPS-approved
algorithms only. Must be disabled in FIPS mode
Password
authentication
Allow
Enable SO can configure the policy to enable or disable the use of passwords
without trusted path for authentication.
Disable
Disallow X X X Disable
The cryptographic module must operate using the trusted path and
module-generated secrets for authentication.
Trusted path
authentication
Allow X X X
Enable SO can configure the policy to enable or disable the use of the trusted
path and module-generated secrets for authentication.
Disable
Disallow Disable
The cryptographic module must operate using passwords without
trusted path for authentication.7
6 Masking is performed using a FIPS-approved encryption algorithm with a key that is held only by the cryptographic
module.
7
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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 8 of 30
Description Capability CKE CL SNC Policy Comments
Remote PED
Operations
Allow X X X
Enable The cryptographic module can use Remote PED for Trusted Path
authentication.8
Allowed in Trusted Path authentication only.
Disable
Disallow Disable
The cryptographic module cannot use remote PED for Trusted Path
authentication.
Cloning
Allow X X
Enable SO can configure the policy to enable or disable the availability of the
cloning function for the cryptographic module as a whole.
Disable
Disallow X Disable The cryptographic module must operate without cloning.
Masking
Allow
Enable SO can configure the policy to enable or disable the availability of the
masking function for the cryptographic module as a whole.
Disable
Disallow X X X Disable The cryptographic module must operate without masking.
Unmasking
Allow X X X
Enable SO can configure the policy to enable or disable the availability of the
unmasking function for the cryptographic module as a whole.
Disable
Disallow Disable The cryptographic module must operate without unmasking.
Korean algorithms9
Allow
Enable SO can configure the policy to enable or disable the availability of
Korean algorithms for the cryptographic module as a whole.
Disable
Disallow X X X Disable The cryptographic module must operate without Korean algorithms.
Partition reset
Allow X X X
Enable SO can configure the policy to enable a partition to be reset if it is
locked as a result of exceeding the maximum number of failed login
attempts.
Disable
Disallow Disable
A partition cannot be reset and must be re-created as a result of
exceeding the maximum number of failed login attempts.
Network Replication
Allow X
Enable SO can configure the policy to enable the replication of the module’s
key material over the network to a second module.
Disable
Disallow X X Disable The module cannot be replicated over the network.
Force user PIN
change
Allow X X X
Enable This capability is set prior to shipment to the customer. If enabled, it
forces the user to change the PIN upon first login.
Disable
Disallow Disable The user is never forced to change PIN on first login.
External MTK split
storage
Allow X X X
Enable This capability is set prior to shipment to the customer. It allows the
use of external storage of the MTK split.
Disable
Disallow Disable External MTK split storage cannot be enabled for the module.
Acceleration
Allow X X X
Enable This capability is set prior to shipment to the customer. It allows the
use of the onboard crypto accelerator.
Disable
Disallow Disable Remote authentication cannot be enabled for the module.
HA CGX Mode
Allow
Enable This capability is set prior to shipment to the customer. It allows the
use of the HA CGX mode.
Disable
Disallow X X X Disable HA CGX mode cannot be enabled for the module.
8 Enabled in the Trusted Path configuration. Operator can connect the cryptographic module to a Remote PED using
Command Line Interface (CLI) commands.
9 Korean algorithms are only available upon customer request.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 9 of 30
Table 3-2. Partition Capabilities and Policies
Description Prerequisite Capability KE CL NC Policy Comments
Trusted Path operation
without a challenge
Trusted path
authentication
enabled
Allow X X X
Enable
SO can configure the policy to enable Trusted Path
login using the PED trusted path only, with no
challenge-response validation required. Must be
disabled if either activation or auto-activation is
enabled
Disable
Disallow Disable
Challenge-response validation required plus PED
trusted path login to access the partition.
User key management
capability10
Trusted path
authentication
enabled, Trusted Path
operation without a
challenge disabled
Allow X X X
Enable
SO can configure the policy to enable the normal
PKCS #11 user role to perform key management
functions. If enabled, the Crypto Officer key
management functions are available. If disabled, only
the Crypto User role functions are accessible.
Disable
Disallow Disable Only the Crypto User role functions are accessible.
Count failed challenge-
response validations
Trusted path
authentication
enabled
Allow X X X
Enable
SO can configure the policy to count failures of the
challenge-response validation against the maximum
login failures or not. Must be enabled if either
activation or auto-activation is enabled
Disable
Disallow Disable
Failures of the challenge-response validation are not
counted against the maximum login failures.
Activation
Trusted path
authentication
enabled
Allow X X X
Enable
SO can configure the policy to enable the
authentication data provided via the PED trusted path
to be cached in the module, allowing all subsequent
access to the partition, after the first login, to be done
on the basis of challenge-response validation alone.
Disable
Disallow Disable
PED trusted path authentication is required for every
access to the partition.
10
This 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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 10 of 30
Description Prerequisite Capability KE CL NC Policy Comments
Auto-activation
Trusted path
authentication
enabled
Allow X X X
Enable
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
authentication state after a re-start. This is intended
primarily to allow partitions to automatically re-start
operation when the appliance returns from a power
outage.
Disable
Disallow Disable Activation data cannot be externally cached.
High Availability N/A
Allow X X
Enable SO can configure the policy to enable the use of the
High Availability feature.
Disable
Disallow X Disable High Availability cannot be enabled.
Multipurpose keys N/A
Allow X X X
Enable SO can configure the policy to enable the use of keys
for more than one purpose, e.g., an RSA private key
could be used for digital signature and for decryption
for key transport purposes.
Disable
Disallow Disable Keys can only be used for a single purpose.
Change attributes N/A
Allow X X X
Enable SO can configure the policy to enable changing key
attributes.
Disable
Disallow Disable Key attributes cannot be changed.
Operate without RSA
blinding
N/A
Allow X X X
Enable
SO can configure the use of blinding mode for RSA
operations. Blinding mode is used to defeat timing
analysis attacks on RSA digital signature operations,
but it also imposes a significant performance penalty
on the signature operations.
Disable
Disallow Disable Blinding mode is not used for RSA operations.
Signing with non-local
keys
N/A
Allow X X X
Enable SO can configure the ability to sign with externally-
generated private keys that have been imported into
the partition.
Disable
Disallow Disable
Externally-generated private keys cannot be used for
signature operations.
Raw RSA operations N/A
Allow X X X
Enable SO can configure the ability to use raw (no padding)
format for RSA encrypt/decrypt operations for key
transport purposes.
Disable
Disallow Disable Raw RSA cannot be used.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 11 of 30
Description Prerequisite Capability KE CL NC Policy Comments
Private key wrapping N/A
Allow X
Enable SO can configure the ability to wrap private keys for
export.
Disable
Disallow X X Disable
Private keys cannot be wrapped and exported from
the partition.
Private key unwrapping N/A
Allow X X X
Enable SO can configure the ability to unwrap private keys
and import them into the partition.
Disable
Disallow Disable
Private keys cannot be unwrapped and imported into
the partition.
Secret key wrapping N/A
Allow X X X
Enable SO can configure the ability to wrap secret keys and
export them from the partition.
Disable
Disallow Disable
Secret keys cannot be wrapped and exported from
the partition.
Secret key unwrapping N/A
Allow X X X
Enable SO can configure the ability to unwrap secret keys
and import them into the partition.
Disable
Disallow Disable
Secret keys cannot be unwrapped and imported into
the partition.
Private key cloning
Cloning enabled,
Trusted path
authentication
enabled
Allow X
Enable SO can configure the ability to clone private keys from
one module and partition to another.
Disable
Disallow X X Disable Private keys cannot be cloned.
Secret key cloning
Cloning enabled,
Trusted path
authentication
enabled
Allow X X X
Enable SO can configure the ability to clone secret keys from
one module and partition to another.
Disable
Disallow Disable Secret keys cannot be cloned.
Private key masking Masking enabled
Allow
Enable SO can configure the ability to mask private keys for
storage outside the partition.
Disable
Disallow X X X Disable
Private keys cannot be masked for storage outside
the partition.
Secret key masking Masking enabled
Allow
Enable SO can configure the ability to mask secret keys for
storage outside the partition.
Disable
Disallow X X X Disable
Secret keys cannot be masked for storage outside the
partition.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 12 of 30
Description Prerequisite Capability KE CL NC Policy Comments
Private key unmasking
Secret key cloning
enabled
Allow X X X
Enable This setting allows unmasking of private keys.
Disable
Disallow Disable Private keys cannot be unmasked
Secret key unmasking
Secret key cloning
enabled
Allow X X X
Enable This setting allows unmasking of secret keys.
Disable
Disallow Disable Secret keys cannot be unmasked
Minimum / maximum
password length
User password
authentication
enabled
7-16 characters Configurable
The SO can configure the minimum password length
for Level 2 modules, but minimum length must always
be >= 7.
Number of failed Partition
User logins allowed
N/A
Minimum:1,
Maximum:10
Configurable
The SO can configure; default maximum value is 10.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 13 of 30
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 determine FIPS mode of operation by matching the displayed
capability and policy settings to those described in Sections 3.1 and 3.2.
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
In the Trusted Path Authentication configuration, the Luna cryptographic module supports the
following authenticated operator roles: The Security Officer11 (SO) at the module level plus
Partition Users12 (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.
11 Within the confines of the operational use of the Luna cryptographic module, the term “Security Officer” is equivalent to
the FIPS 140-2 term of “Crypto Officer”.
12 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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 14 of 30
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 Crypto Officer is the key management role for each partition and 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 Crypto Officer, Crypto User or Security Officer role before
identification and authentication;
 No identity can assume the Crypto Officer or Crypto User plus the Security Officer role.
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.
3.3.3 Account Data
The module maintains the following User (which can include both the Crypto Officer and Crypto User
role per Partition13) 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.
13
A Partition effectively represents an identity within the module.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 15 of 30
3.3.4 Subject
For 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
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;
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 16 of 30
 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 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.
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 token,
 Purple (MTK Recovery) iKey – for the storage of an external split that allows the MTK to be
restored after a tamper event.
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
TOE within the customer’s environment.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 17 of 30
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) iKey14 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 partition15, 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 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).
14 Or Black (User) PED key. Within this document the terms “iKey” and “PED” key are interchangeable unless otherwise
indicated.
15 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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 18 of 30
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 and a Partition User authentication 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.
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.
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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 19 of 30
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 Extractable16
. 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.
Table 3-3. Object Attributes Used in Access Control Policy Enforcement
Attribute Values Impact
PRIVATE
TRUE – Object is private to (owned by) the operator
identified as the Access Owner when the object is
created.
Object is only accessible to subjects (sessions)
bound to the operator identity that owns the object.
FALSE – Object is not private to one operator identity. Object is accessible to all subjects associated with
the partition in which the object is stored.
SENSITIVE
TRUE – Attribute values representing plaintext key
material are not permitted to exist (value encrypted).
Key material is stored in encrypted form.
FALSE – Attribute values representing plaintext data
are permitted to exist.
Plaintext data is stored with the object and is
accessible to all subjects otherwise permitted
access to the object.
MODIFIABLE
TRUE – The object’s attribute values may be
modified.
The object is “writeable” and its attribute values can
be changed during a copy or set attribute operation.
FALSE – The object’s values may not be modified. The object can only be read and only duplicate
copies can be made.
EXTRACTABLE
TRUE – Key material stored with the object may be
extracted from the Luna cryptographic module using
the Wrap operation.
The ability to extract a key permits sharing with
other crypto modules and archiving of key material.
FALSE – Key material stored with the object may not
be extracted from the Luna cryptographic module.
Keys must never leave a module’s control.
16
Extract 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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 20 of 30
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 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.
 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
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 21 of 30
 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-90 section 10.2.1.
(2) Cryptographic key generation in accordance with the following indicated standards:
a. RSA 1024-4096 bits key pairs in accordance with FIPS PUB 186-2.
b. TDES 112 bits and 168 bits (SP 800-67, ANSI X9.52).
c. AES 128, 192, 256 bits (FIPS PUB 197).
d. DSA 1024, 2048 and 3072 bit key pairs in accordance with FIPS PUB 186-3.
e. Elliptic Curve key pairs (curves in accordance with SP 800-57) in accordance with FIPS PUB
186-3.
f. Diffie-Hellman key pairs.
g. Key Derivation in accordance with NIST SP 800-108 (Counter & Feedback modes).
(3) Diffie-Hellman (2048-3072 bits) key establishment methodology provides between 112 and 128 bits of
encryption strength. 17
(4) EC Diffie-Hellman (ECDH) (curves in accordance with SP 800-57) key establishment in accordance
with NIST SP 800-56A.
(5) Encrypted key storage (using AES 256 bit encryption, see Section 3.5.1) and key access following
the PKCS #11 standard.
(6) 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.
17 Non-approved but allowed method in FIPS mode.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 22 of 30
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 that 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 HSM 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.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 (key wrap/unwrap) TDES 168 bits and AES 128, 192 and 256
bits in accordance with PKCS #11.
2. Symmetric encryption/decryption: TDES 112 bits and 168 bits (SP 800-67, ANSI X9.52).
3. Symmetric encryption/decryption: AES 128, 192, 256 bits (FIPS PUB 197).
4. Asymmetric key wrap/unwrap: RSA 1024 – 4096 (PKCS #1 V1.5 and OAEP)
5. Signature generation/verification (FIPS PUB 186-3): 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 (X9.31) with SHA-1, DSA 1024-3072
bits with SHA-1, SHA-224, SHA-256; ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, SHA-
512.
6. Signature generation/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-3).
8. Keyed hash generation HMAC using SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (FIPS PUB
198).
9. Message authentication TDES MAC (FIPS PUB 113) and CMAC (NIST SP 800-38B).
10. Deterministic Random Bit Generation (DRBG) (NIST SP 800-90 section 10.2.1)
Table 3-4. Approved and Allowed Security Functions for SafeXcel 3120
Approved and Allowed Security Functions Certificate No.
Symmetric Encryption/Decryption
AES: (ECB, CBC, GCM); Encrypt/Decrypt; Key Size = 128, 192, 256) 1743
Triple-DES: (ECB, CBC); Encrypt/Decrypt KO 1,2) 1130
Secure Hash Standard (SHS)
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Byte Only) 1531
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 23 of 30
Approved and Allowed Security Functions Certificate No.
Message Authentication Code
HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-
512
1021
Triple-DES MAC (Vendor Affirmed) 1130
Asymmetric
RSA:
FIPS186-2: ALG[ANSIX9.31]; KEYGEN(Y); SIG (gen); SIG (ver) (MOD: 1024,
1536, 2048, 3072, 4096 PubKey Values: 3, 17, 65537); ALG[RSASSA-
PKCS1_V1_5]; SIG(gen); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096);
ALG[RSASSA-PSS]; SIG(gen); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096)
865
DSA:
FIPS186-3: PQG(gen): [ (1024,160) SHA( 1 ); (2048, 224) SHA( 224 );
(2048,256)SHA( 256 ); (3072,256)SHA( 256 ); ]
KEYGEN: [ (1024,160); (2048,224); (2048,256) (3072,256) ]
SIG(gen): [ (1024,160) SHA( 1 ); (2048,224) SHA( 1 , 224 ); (2048,256) SHA( 1 ,
224 , 256 ); (3072,256) SHA( 1 , 224 , 256 ); ]
SIG(ver): [ (1024,160) SHA( 1 ); (2048,224) SHA( 1 , 224 ); (2048,256) SHA( 1 ,
224 , 256 ); (3072,256) SHA( 1 , 224 , 256 ); ]
545
ECDSA:
FIPS186-3: PKG: CURVES ( P-192; P-224; P-256; P-384) Testing Candidates
SIG(gen): CURVES ( P-192: (SHA-1); P-224: (SHA-1, 224) P-256: (SHA-1, 224,
256); P-384: (SHA-1, 224, 256, 384)
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)
230
Random Number Generation
NIST SP 800-90 DRBG (CTR) AES-256 114
Table 3-5. Approved and Allowed Security Functions for SafeXcel 1746
Approved and Allowed 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) 1137
Message Authentication Code
Triple-DES MAC (Vendor Affirmed) 1137
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 24 of 30
Approved and Allowed Security Functions Certificate No.
Asymmetric
DSA:
FIPS186-2: SIG(gen); SIG(ver) MOD (1024)
FIPS 186-3: SIG(gen): [ (1024,160) SHA( 1, 224, 256 ); (2048,224) SHA( 224 ,
256); (2048,256) SHA( 256 ); (3072,256) SHA( 256 ) ]
SIG(ver): [ (1024,160) SHA( 1, 224, 256 ); (2048,224) SHA( 224 , 256); ;
(2048,256) SHA( 256 ); (3072,256) SHA( 256 )]
548
ECDSA:
FIPS186-2: SIG(gen): 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)
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-3: SIG(gen): 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: K-283: (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)
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: K-283: (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)
233
Table 3-6. Approved and Allowed Security Functions Firmware Implementation
Approved and Allowed Security Functions Certificate No.
Symmetric Encryption/Decryption
AES: (ECB, CBC, OFB, CFB8, CFB128 GCM); Encrypt/Decrypt; Key Size = 128,
192, 256)
1750
Triple-DES: (ECB, CBC, OFB, CFB8, CFB64); Encrypt/Decrypt KO 1,2) 1134
Secure Hash Standard (SHS)
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Byte Only) 1537
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 25 of 30
Approved and Allowed Security Functions Certificate No.
Message Authentication Code
HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-
512
1027
Triple-DES MAC (Vendor Affirmed) 1134
CMAC (Key Sizes Tested: 128 192 256) 1750
Asymmetric
RSA:
FIPS186-2: [ANSIX9.31]; KEYGEN; SIG (gen); SIG (ver) (MOD: 1024, 1536, 2048,
3072, 4096 PubKey Values: 3, 17, 65,537 ); [RSASSA-PKCS1_V1_5]; SIG(gen);
SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096); SHA(1, 224, 256, 384, 512);
[RSASSA-PSS]; SIG(gen); SIG(ver); (MOD: 1024, 1536, 2048, 3072, 4096) SHA(1,
224, 256, 384, 512))
FIPS 186-3: [ANSIX9.31]; SIG(gen); SIG (ver) (MOD: 1024 SHA(1, 224, 256, 384,
512); 2048 SHA(1, 224, 256, 384, 512); 3072); SHA(1, 224, 256, 384, 512));
[RSASSA-PKCS1_V1_5]; SIG(gen); SIG(ver); (MOD: 1024 SHA(1, 224, 256, 384,
512); (2048 SHA(1, 224, 256, 384, 512); 3072; SHA(1, 224, 256, 384, 512);
ALG[RSASSA-PSS]; SIG(gen); SIG(ver); (MOD: 1024 SHA(1, 224, 256, 384, 512),
2048 SHA(1, 224, 256, 384, 512), 3072 SHA(1, 224, 256, 384, 512))
870
DSA:
FIPS186-2: KEYGEN(Y); SIG(gen); SIG(ver) MOD (1024)
FIPS186-3: ]
KEYGEN: [ (1024,160); (2048, 224); (2048,256); (3072,256) ]
SIG(gen): [ (1024,160) SHA( 1 ); (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 ) ]
546
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 26 of 30
Approved and Allowed Security Functions Certificate No.
ECDSA:
FIPS186-2: PKG: 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)
SIG(gen): 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)
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-3: PKG: CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283
K-409 K-571) Testing Candidates
SIG(gen): 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: K-283: (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)
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: K-283: (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)
231
Key Agreement Scheme
ECC: ( ASSURANCES )
SCHEMES [ Ephemeral Unified ( KARole(s): Initiator / Responder )
( EA: P-192 SHA1 SHA224 SHA256 SHA384 SHA512 ) ( EB: P-224
SHA224 SHA256 SHA384 SHA512 ) ( EC: P-256 SHA256 SHA384
SHA512 ) ( ED: P-384 SHA384 SHA512 ) ( EE: P-521 ) ]
[ OnePassDH ( No_KC: [N/A] ) ( KARole(s): Initiator / Responder ) ( EA: P-192
SHA1 SHA224 SHA256 SHA384 SHA512 CMAC ) ( EB: P-224 SHA224
SHA256 SHA384 SHA512 HMAC ) ( EC: P-256 SHA256 SHA384 SHA512
HMAC ) ( ED: P-384 SHA384 SHA512 HMAC ) ( EE: P-521 ) ]
23
Diffie-Hellman (key agreement; key establishment methodology provides between
112 and 128 bits of encryption strength.
Key Transport
RSA (key wrapping; key establishment methodology provides between 80 and 152
bits of encryption strength)
Key Derivation
NIST SP 800-108 (Counter Mode) (Vendor Affirmed)
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 27 of 30
Table 3-7 – Non-FIPS Approved Security Functions
Encrypt/Decrypt
 DES-ECB
 DES-CBC
 RC2-ECB
 RC2-CBC
 RC4
 RC5-ECB
 RC5-CBC
 CAST5-ECB
 CAST5-CBC
 RSA X-509
 SEED
 ARIA
Digest
 MD2
 MD5
 HAS-160
Sign/Verify
 AES MAC
 DES-MAC
 RC2-MAC
 RC5-MAC
 CAST5-MAC
 SSL3-MD5-MAC
 SSL3-SHA1-MAC
 KCDSA
Generate Key
 DES
 RC2
 RC4
 RC5
 CAST5
 SEED
 ARIA
 GENERIC-SECRET
 SSL PRE-MASTER
Generate Key Pair
 KCDSA
Wrap Symmetric Key Using Symmetric Algorithm
 RC2-ECB
 CAST5-ECB
Unwrap Symmetric Key With Symmetric Algorithm
 RC2-ECB
 CAST5-ECB
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 28 of 30
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-8. Module Self-Tests
Test When Performed Indicator
Boot loader performs a SHA-1 integrity check of the
firmware prior to firmware start
Power-on Module halt18
DRBG Instantiate Function Known Answer Test (KAT) Power-on Module halt
DRBG Generate Function KAT Power-on Module halt
DRBG Reseed Function KAT Power-on Module halt
DRBG Uninstantiate Function KAT Power-on Module halt
TDES Known Answer Test (KAT) Power-on/Request Module halt / Error - Halt19
SHA-1 KAT Power-on/Request Module halt / Error - Halt
SHA-224 KAT Power-on/Request Module halt / Error - Halt
SHA-256 KAT Power-on/Request Module halt / Error - Halt
SHA-384 KAT Power-on/Request Module halt / Error - Halt
SHA-512 KAT Power-on/Request Module halt / Error - Halt
HMAC SHA-1 KAT Power-on/Request Module halt / Error - Halt
HMAC SHA-224 KAT Power-on/Request Module halt / Error - Halt
HMAC SHA-256 KAT Power-on/Request Module halt / Error - Halt
HMAC SHA-384 KAT Power-on/Request Module halt / Error - Halt
HMAC SHA-512 KAT Power-on/Request Module halt / Error - Halt
RSA KAT Power-on/Request Module halt / Error - Halt
DSA KAT Power-on/Request Module halt / Error - Halt
Diffie-Hellman KAT Power-on/Request Module halt / Error - Halt
AES KAT Power-on/Request Module halt / Error - Halt
AES-GCM KAT Power-on/Request Module halt / Error - Halt
ECDH KAT Power-on/Request Module halt / Error - Halt
ECDSA KAT Power-on/Request Module halt / Error - Halt
KDF KAT Power-on/Request Module halt / Error - Halt
DRBG conditional tests Continuous Error - Halt
HRNG conditional tests Continuous Error - Halt
RSA – Pair-wise consistency test (asymmetric key pairs) On generation Error
DSA – Pair-wise consistency test (asymmetric key pairs) On generation Error
ECDSA – Pair-wise consistency test (asymmetric key
pairs)
On generation Error
Firmware load test (4096-bit RSA sig ver) On firmware update
load
Error – module will continue
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.
18
Details of the failure can be obtained from the dual-port following a module halt.
19 An error message is output, the cryptographic module halts, and data output is inhibited.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 29 of 30
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 software20 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. 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 (CSP) 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 also senses and responds to out-of-range temperature and 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.
20
External 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.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page 30 of 30
3.10.1 Secure Recovery
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 state21 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 signal22.
By responding to the signal a module can ensure that no sensitive data remains 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.
21
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.
22
This is external to the cryptographic boundary.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page A-1 of A-6
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
Crypto Officer Identity-based23
Level 3 – Authentication token (PED Key – one per user)
plus optional PED PIN, plus optional Challenge Secret
for the role24
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.
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
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
23
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.
24 If activation or auto-activation is enabled, challenge secret is required in FIPS mode.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page A-2 of A-6
Table A-4. Access Rights within Services
Service Cryptographic Keys and CSPs Role Type(s) of Access
Show Status25
N/A All N/A
Self-test N/A All N/A
Initialize Module Authentication data via trusted path SO Write – SO authentication data
Configure Module Policy Authentication data via trusted path SO Use26
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, asymmetric
key pairs
SO Write, Erase
Firmware Update MVK27
SO Use, Write (firmware only)
Key and Key Pair Generation Symmetric keys, asymmetric key pairs Crypto Officer Write
Symmetric Key Wrap/ Unwrap Symmetric with RSA
Symmetric with Symmetric ECB mode
Crypto Officer Use, Write
Asymmetric Key Wrap/ Unwrap Asymmetric with Symmetric CBC mode Crypto Officer Use, Write
Symmetric Key Mask/ Unmask Symmetric with AES 256 Crypto Officer Use, Write
Asymmetric Key Mask/
Unmask
Symmetric with AES 256 Crypto Officer Use, Write
Partition Backup / Restore Symmetric keys, asymmetric key pairs Crypto Officer Transfer28
Symmetric Encrypt/Decrypt Symmetric keys Crypto Officer,
Crypto User
Use
Asymmetric Signature RSA, DSA private keys Crypto Officer,
Crypto User
Use
Asymmetric Verification RSA, DSA public keys Crypto Officer,
Crypto User
Use
Store Data Object Non-cryptographic data Crypto Officer,
Crypto User,
Public User29
Write
Read Data Object Non-cryptographic data Crypto Officer,
Crypto User,
Public User30
Read
25
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.
26
Use means access to key material for use in performing a cryptographic operation. The key material is never
visible.
27 Public key value. See Table A-5 for its description.
28
Transfer means moving a key using the cloning protocol from one cryptographic module to another.
29 The Public User has access to Public Data Objects only.
30 The Public User has access to Public Data Objects only.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page A-3 of A-6
Table A-5 Keys and Critical Security Parameters Used in the Module
Key/CSP Name Description
Challenge Secret Used in Trusted Path Authentication configuration only. 16 character
random string generated by the cryptographic module and output via the
PED display when the user is created. It is input by the operator as the
authentication data for a client application login. Stored in flash
encrypted by the SGSK.
Random Challenge Used in Trusted Path Authentication configuration only. A one-time
random number generated by the cryptographic module and sent to the
calling application for each login. It is combined with the input
Challenge Secret to compute the one-time response that is returned to
the cryptographic module. Stored in RAM as plaintext.
Challenge Response A 20-byte value used for authentication in the challenge response
scheme. It is generated using the challenge secret and the one-time
random challenge value. Stored in RAM as plaintext.
SIM authorization values These user-supplied M of N secret values are used to authorize the
insertion of a masked key blob previously extracted using the SIM II
feature.
PED Key (or iKey) Authentication Data Used in Trusted Path Authentication configuration. A 48-byte random
value that is generated by the module when the SO or User is created.
It is written out to the serial memory device (PED Key or iKey) via the
Trusted Path. Stored on the PED Key or iKey as plaintext.
Optional PIN An optional PIN value used for authentication along with the PED key. It
must be a minimum of 4-bytes long
Cloning Domain Vector 48-byte value that is used to control a module’s ability to participate in
the cloning protocol. It is either generated by the module or imprinted
onto the module at the time the module is initialized. It is stored
encrypted (using the SGSK) in the module. The value is output from the
original module in the domain onto a PED Key or iKey to enable
initializing additional modules into the same domain.
User Storage Key (USK) 32-byte AES key that is randomly generated for each user on a Luna
cryptographic module. This key is used to encrypt all sensitive
attributes of all private objects owned by the user. Encrypted, as part of
the UAV, by the key taken from the PED key data.
Security Officer Master Key (SMK) The storage key for the SO; a 32-byte AES key that is randomly
generated for the SO on the module. This key is used to encrypt all
sensitive attributes of all private objects owned by the SO. The
USK/SMK is stored encrypted using an AES key, which is the first 32
bytes of the User/SO PED Key Authentication data (plus optional PIN).
Global Storage Key (GSK) 32-byte AES key that is the same for all users on a specific Luna
cryptographic module. It is used to encrypt permanent parameters
within the non-volatile memory area reserved for use by the module.
Encrypted, as part of the UAV, by the key taken from the PED key data.
Secondary Global Storage Key (SGSK) 32-byte AES key that is the same for all users on a specific Luna
cryptographic module. It is stored encrypted using USK and SMK. It is
used to encrypt non-permanent parameters (parameters re-generated
for every module initialization) within the non-volatile memory area
reserved for use by the module.
Token or Module Unwrapping Key (TUK) A 2048-bit RSA private key used in the cloning protocol. Stored in the
Param area; encrypted with the GSK.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page A-4 of A-6
Table A-5 Keys and Critical Security Parameters Used in the Module
Key/CSP Name Description
Token or Module Wrapping Certificate (TWC) Based on the Hardware Origin Certificate (HOC). The TWC is an X.509
certificate signed by the private key corresponding to the HOC. Used in
exchange of session encryption key as part of the handshake during the
cloning protocol. Stored as plaintext in the Param area.
U2 Key 24-byte TDES key used in conjunction with the auth code for a firmware
update to derive a key used to decrypt the firmware update image when
it is loaded into the module. Used for backwards compatibility purposes
with earlier firmware versions. Stored in the Param area.
Token or Module Variable Key (TVK) 32-byte AES key stored in a dedicated non-volatile RAM. It is used to
encrypt authentication data stored for auto-activation purposes. The
non-volatile RAM is actively zeroized in response to a tamper event.
Master Tamper Key (MTK) 32 byte AES key that is stored in battery-backed RAM. The MTK
encrypts all sensitive values and is erased in response to a tamper
event.
Key Encryption Key (KEK) 32 byte AES key that is stored in the module’s battery-backed RAM.
The KEK encrypts all sensitive values and is erased in response to a
decommission signal.
Masking Key AES 256-bit key stored in the Param area. It is generated on the
cryptographic module at initialization time. It is used during masking
operations. Encrypted using the SGSK.
Manufacturer’s Integrity Certificate (MIC) 4096-bit RSA public key certificate corresponding to the Manufacturer’s
Integrity Key (MIK) held at SafeNet. Used in verifying Hardware Origin
Certificates (HOCs), which are generated in response to a customer
function call to provide proof of hardware origin. Stored as plaintext in
flash.
Manufacturers Verification Key (MVK) 4096-bit Public key counterpart to the Manufacturer’s Signature Key
(MSK) held at SafeNet. Used to verify the digital signature on a
firmware update image. Stored in flash as plaintext.
Device Authentication Key (DAK) 2048-bit RSA private key used for a specific PKI implementation
requiring assurance that a key or a specific action originated within the
hardware crypto module. Encrypted using the GSK.
Hardware Origin Key (HOK) A 4096 bit RSA private key used to sign certificates for other device key
pairs, such as the TWC. It is generated at the time the device is
manufactured. Encrypted using the GSK and stored in the Param area.
Hardware Origin Certificate (HOC) The X.509 public key certificate corresponding to the HOK. It is signed
by the Manufacturer’s Integrity Key (MIK) at the time the device is
manufactured. Stored as plaintext in the Param area.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page A-5 of A-6
Table A-5 Keys and Critical Security Parameters Used in the Module
Key/CSP Name Description
Remote PED Vector (RPV) A randomly generated 256-bit secret, which must be shared between a
remote PED and a cryptographic module in order to establish a secure
communications channel between them.
Secure Recovery Vector (SRV) A split of the MTK that is written to one or more iKeys using the M of N
secret splitting scheme and used to recover the MTK after a tamper
event has been cleared.
DRBG Key 32 bytes AES key stored in the BBRAM of the internal security co-
processor. Used in the implementation of the NIST SP 800-90 CTR
(AES) DRBG.
DRBG Seed Random seed data drawn from the Hardware RBG in the security co-
processor and used to seed the implementation of the NIST SP 800-90
CTR (AES) DRBG.
DRBG V Part of the secret state of the approved DRBG. The value is stored in
the security co-processor as plaintext and is generated using the
methods described in SP800-90. It is zeroized during a tamper event.
DRBG Entropy Input The entropy value used to initialize the approved DRBG. The 48-byte
value is stored ephemerally in memory of the security co-processor.
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page A-6 of A-6
- THIS PAGE LEFT BLANK INTENTIONALLY -
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page B-1 of B-2
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
KES Key Export – SIM (a capability configuration used to allow the export of private
keys as wrapped objects and to securely transfer the symmetric wrapping key
between modules via a SIM [masked object] file).
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
CR-4126 Revision Level: 1
Document is Uncontrolled When Printed.
Page B-2 of B-2
Term Definition
PCI Peripheral Component Interconnect
PED PIN Entry Device
PIN Personal Identification Number
PKCS Public-Key Cryptography Standards
PRNG Pseudo-Random Number Generator
RA Registration Authority
RNG Random Number Generator
RPED Remote PED
RPK Remote PED Key
RPV Remote PED Vector
SA Server-Attached
SCU Secure Capability Update
SGSK Secondary Global Storage Key
SHS Secure Hash Standard
SIM Secure Information Management (a capability configuration used to allow the use
of SIM [masked object] files for secure backup and recovery).
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