Document is uncontrolled when printed.
LEVEL 3 NON-PROPRIETARY SECURITY POLICY
FOR
Luna® PCI Cryptographic Module
(including configurations IS and RSS)
DOCUMENT NUMBER: CR-2333
AUTHOR: Terry Fletcher
DEPARTMENT: Engineering
LOCATION OF ISSUE: Ottawa
DATE ORIGINATED: January 30, 2007
REVISION LEVEL: 22
REVISION DATE: December 15, 2011
SUPERSESSION DATA: CR-2333, Revision 21 dated October 14, 2011
SECURITY LEVEL: Non-proprietary
© Copyright 2007-2011 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-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page i of iii
PREFACE
This document deals only with operations and capabilities of the Luna® PCI Cryptographic Module in the
technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the
Luna PCI® 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-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page ii of iii
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 .................................................................................................................... 3
3. SECURITY POLICY MODEL DESCRIPTION........................................................................................ 4
3.1. Operational Policy............................................................................................................................ 4
3.1.1. Module Capabilities................................................................................................................... 5
3.1.2. Partition Capabilities ................................................................................................................. 5
3.2. FIPS-Approved Mode..................................................................................................................... 10
3.3. Description of Operator, Subject and Object ................................................................................. 10
3.3.1. Operator.................................................................................................................................. 10
3.3.2. Roles....................................................................................................................................... 10
3.3.3. Account Data .......................................................................................................................... 11
3.3.4. Subject.................................................................................................................................... 12
3.3.5. Operator – Subject Binding..................................................................................................... 12
3.3.6. Object...................................................................................................................................... 12
3.3.7. Object Operations................................................................................................................... 12
3.4. Identification and Authentication.................................................................................................... 13
3.4.1. Authentication Data Generation and Entry ............................................................................. 13
3.4.2. Trusted Path ........................................................................................................................... 13
3.4.2.1. Remote PED Operation................................................................................................... 13
3.4.3. M of N Authentication.............................................................................................................. 14
3.4.4. Limits on Login Failures.......................................................................................................... 14
3.5. Access Control............................................................................................................................... 14
3.5.1. Object Re-use......................................................................................................................... 16
3.5.2. Privileged Functions................................................................................................................ 16
3.6. Cryptographic Material Management............................................................................................. 16
3.7. Cryptographic Operations .............................................................................................................. 17
3.8. Self-tests ........................................................................................................................................ 18
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page iii of iii
3.9. Firmware Security .......................................................................................................................... 18
3.10. Physical Security ........................................................................................................................ 19
3.11. EMI/EMC .................................................................................................................................... 19
3.12. Fault Tolerance........................................................................................................................... 19
3.13. Mitigation of Other Attacks ......................................................................................................... 19
LIST OF TABLES
Table Title Page
Table 1-1. FIPS 140-2 Security Requirements.............................................................................................1
Figure 2-1. Luna PCI Cryptographic Module................................................................................................3
Table 3-1 Module Capabilities and Policies .................................................................................................6
Table 3-2 Partition Capabilities and Policies................................................................................................7
Table 3-3 Object Attributes Used in Access Control Policy Enforcement..................................................15
Table 3-4. Algorithm Validation Certificates ...............................................................................................18
Table 3-5. Module Self-Tests .....................................................................................................................18
Table B-1 Roles and Required Identification and Authentication.................................................................1
Table B-2 Strengths of Authentication Mechanisms ....................................................................................1
Table B-3 Services Authorized for Roles .....................................................................................................1
Table B-4 Access Rights within Services.....................................................................................................2
Table B-5 Keys and Critical Security Parameters Used by the Module.......................................................3
LIST OF FIGURES
Figure Title Page
Figure 2-1. Luna PCI Cryptographic Module................................................................................................3
LIST OF APPENDICES
Appendix Title Page
APPENDIX A. CRYPTOGRAPHIC ALGORITHMS SUPPORT...............................................................1
APPENDIX B. SECURITY POLICY CHECKLIST TABLES .....................................................................1
APPENDIX C. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS.................................................1
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 1 of 20
1. INTRODUCTION
1.1. Purpose
This document describes the security policies enforced by SafeNet Inc.’s Luna® PCI Cryptographic
Module1
.
This document applies to Hardware Version VBD-03-0100 and Firmware Versions 5.2.7 and 5.2.8.
1.2. Scope
The security policies described in this document apply to the Trusted Path Authentication (Level 3)
configurations of the Luna® PCI 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
Cryptographic Key Management 3
EMI/EMC 3
Self-Tests 3
Design Assurance 3
Mitigation of Other Attacks 3
Cryptographic Module Security Policy 3
1
Also known as the K5.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 2 of 20
2. SECURITY POLICY MODEL INTRODUCTION
2.1. Functional Overview
The Luna® PCI Cryptographic Module is a multi-chip embedded hardware cryptographic module in
the form of a PCI card that resides within a secure communications appliance. It 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 card.
Figure 2-1 depicts the Luna PCI cryptographic module.
The module may be explicitly configured to operate in either FIPS Level 3 mode, or in a non-FIPS
mode of operation. Configuration in 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 HSM, and cannot be changed during normal
operation without zeroizing the module’s non-volatile memory.
The cryptographic module is accessed directly (i.e., electrically) via either the Trusted Path PIN Entry
Device (PED) serial interface or via the PCI communications interface. The 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 indirectly through the host appliance. It provides the ability to
manage multiple user definitions and concurrent authentication states. The software on the host that
provides the connections to the module presents a logical view of “virtual tokens” or “partitions” 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 Cryptographic Module in a Trusted Path
Authentication (FIPS Level 3) configuration.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 3 of 20
Figure 2-1. Luna PCI Cryptographic Module
2.2. Assets to be Protected
The module is designed to protect the following assets:
1. User-generated private keys,
2. User-generated secret keys,
3. Cryptographic services, and
4. Module security critical parameters.
2.3. Operating Environment
The module is assumed to operate as a key management and cryptographic processing card within a
security appliance that may operate in a TCP/IP network environment. The host appliance may be
used in an internal network environment when key management security is a primary requirement. It
may also be deployed in environments where it is used primarily as a cryptographic accelerator, in
which case it will often be connected to external networks. It is assumed that the appliance includes
an internal host computer that runs a suitably secured operating system, with an interface for use by
locally connected or remote administrators and an interface to provide access to the module’s
cryptographic functions by application services running on the host computer. It is also assumed that
only known versions of the application services are permitted to run on the internal host computer of
the appliance.
It is assumed that trained and trustworthy administrators are responsible for the initial configuration
and ongoing maintenance of the appliance and the cryptographic module.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 4 of 20
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 behavior of the module. The detailed functional
specification for the module is provided elsewhere.
The security behavior 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 behavior 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.
3.1. Operational Policy
The module employs the concept of the Operational Policy to control the overall behavior 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 behavior 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.
There are also several fixed settings that do not have corresponding capability set elements. These
are elements of the cryptographic module’s behavior that are truly fixed and, therefore, are not
subject to configuration by the SO. The specific settings 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.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 5 of 20
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:
• Module is FIPS validated
• Allow/disallow forcing PIN change.
• Allow/disallow non-FIPS algorithms available.
• Allow/disallow Remote Authentication.
• Allow/disallow cloning.
• Allow/disallow partition groups
• Allow/disallow password authentication. (Disallowed in Level 3 configuration)
• Allow/disallow trusted path authentication. (Allowed in Level 3 configuration)
• Allow/disallow Remote PED operations.
• Allow/disallow masking2
.
• Allow/disallow off-board storage.
• Allow/disallow SO reset of partition PIN.
• Allow/disallow ECC mechanisms.
• Allow/disallow Korean algorithms.
• Number of failed SO logins allowed before the HSM is zeroized (set to 3, configurable up
to 10).
• Allow/disallow network replication (default is disallow).
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 zero) equates to disallow the
functionality and true (or one) equates to allow the functionality. The remainder of the elements are integer
values of the indicated number of bits.
• Allow/disallow Level 3 operation without a challenge.
• Allow/disallow changing of certain key attributes once a key has been created.
• Allow/disallow incrementing of failed login attempt counter on failed challenge response
validation.
• Allow/disallow High Availability (HA).
• Allow/disallow user key management capability.
• Allow/disallow multipurpose keys.
• Allow/disallow operation without RSA blinding.
• Allow/disallow signing operations with non-local keys.
• Allow/disallow private key unwrapping.
2
Masking is performed using a FIPS-approved algorithm.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 6 of 20
• Allow/disallow raw RSA operations (only used for RSA-based key transport purposes).
• Allow/disallow Remote Authentication
• Allow/disallow RSA signing without confirmation
• Allow/disallow secret key unwrapping.
• Allow/disallow secret key wrapping
• Allow/disallow activation.
• Allow/disallow automatic activation.
• Minimum password length must be >=7.
• Number of failed Partition User logins allowed before partition is locked out/cleared. (The
maximum value is 15; the default is 15.)
The following tables summarize the module and partition capabilities, showing the typical capability
settings for Luna PCI cryptographic modules configured as IS or RSS. An X indicates a default
capability setting.
Table 3-1 Module Capabilities and Policies
Description Capability IS /
RSS
Policy Comments
Non-FIPS algorithms
available
Allow X
Enable SO can configure the policy to enable or disable the
availability of non-FIPS algorithms at the time the HSM is
initialized.
Disable
Disallow Disable
The HSM 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 Disable
The HSM must operate using the trusted path and module-
generated secrets for authentication.
Trusted path
authentication
Allow 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 HSM must operate using passwords without trusted
path for authentication.
3
Partition groups
Allow X
Enable SO can configure the policy to enable or disable groups of
partitions, such that members of a group share the same
PED authentication data and configuration options.
Disable
Disallow Disable The module cannot have groups of partitions.
Cloning
Allow X
Enable SO can configure the policy to enable or disable the
availability of the cloning function for the HSM as a whole.
Disable
Disallow Disable The HSM must operate without cloning.
Masking
Allow X
Enable SO can configure the policy to enable or disable the
availability of the masking function for the HSM as a whole.
Disable
Disallow Disable The HSM must operate without masking.
Off-board Storage
Allow X
Enable Off-board storage is used for backup purposes in this
Luna® PCI Cryptographic Module configuration. The SO
can enable or disable the use of off-board storage.
Disable
Disallow Disable Off-board storage is not allowed.
ECC mechanisms
available
Allow X
Enable This capability is set prior to shipment to the customer. It
controls the availability of ECC mechanisms.
Disable
Disallow Disable ECC mechanisms are not available.
3
One and only one means of authentication (“user password” or “trusted path”) must be enabled by the policy.
Therefore, either one or both 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-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 7 of 20
Description Capability IS /
RSS
Policy Comments
Partition reset
Allow 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
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 Disable The module cannot be replicated over the network.
Force user PIN change
Allow X
Enable This capability is set prior to shipment to the customer. If
enabled, it forces the user to change PIN upon first login.
Disable
Disallow Disable The user is never forced to change PIN on first login.
Remote authentication
Allow X
Enable This capability is set prior to shipment to the customer. It
allows the use of remote authentication.
Disable
Disallow Disable Remote authentication cannot be enabled for the module.
Remote PED operations
Allow
X Enable This capability is set prior to shipment to the customer. It
allows the use of Remote PED operations. The SO can
configure according to the local policy.
Disable
Disallow Disable
Remote PED operations cannot be enabled for the
module.
Table 3-2 Partition Capabilities and Policies
Description Prerequisite Capability IS /
RSS
Policy Comments
Level 3 operation
without a challenge
Trusted path
authentication
enabled
Allow X
Enable SO can configure the policy to enable
Level 3 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
capability
4
Trusted path
authentication
enabled, Level 3
operation
without a
challenge
disabled
Allow 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
Enable SO can configure the policy to count
failures of the challenge-response
validation against the maximum login
failures. 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.
4
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-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 8 of 20
Description Prerequisite Capability IS /
RSS
Policy Comments
Activation
Trusted path
authentication
enabled
Allow 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.
Auto-activation
Trusted path
authentication
enabled
Allow X
Enable SO can configure the policy to enable
the activation data to be stored 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 cached.
High Availability N/A
Allow X
Enable SO can configure the policy to enable
the use of the High Availability
feature.
Disable
Disallow Disable High Availability cannot be enabled.
Multipurpose keys N/A
Allow 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.
Disable
Disallow Disable
Keys can only be used for a single
purpose.
Change attributes N/A
Allow 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
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
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
Enable SO can configure the ability to use
raw (no padding) format for RSA
operations.
Disable
Disallow Disable Raw RSA cannot be used.
Private key wrapping N/A
Allow
Enable SO can configure the ability to wrap
private keys for export.
Disable
Disallow X Disable
Private keys cannot be wrapped and
exported from the partition.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 9 of 20
Description Prerequisite Capability IS /
RSS
Policy Comments
Private key
unwrapping
N/A
Allow 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
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
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
Enable SO can configure the ability to clone
private keys from one partition to
another.
Disable
Disallow X Disable Private keys cannot be cloned.
Secret key cloning
Cloning
enabled,
Trusted path
authentication
enabled
Allow
Enable SO can configure the ability to clone
secret keys from one partition to
another.
Disable
Disallow X Disable Secret keys cannot be cloned.
Private key masking
Masking
enabled
Allow X
Enable SO can configure the ability to mask
private keys for storage outside the
partition.
Disable
Disallow Disable
Private keys cannot be masked for
storage outside the partition.
Secret key masking
Masking
enabled
Allow X
Enable SO can configure the ability to mask
secret keys for storage outside the
partition.
Disable
Disallow Disable
Secret keys cannot be masked for
storage outside the partition.
Remote
Authentication
Remote
Authentication
enabled at the
module level
Allow X
Enable SO can configure the ability to use
remote authentication for the
partition.
Disable
Disallow Disable
Remote authentication cannot be
used with the partition.
Minimum password
length
User password
authentication
enabled
7-16
characters
Configurable
Minimum password length must
always be >= 7.
Number of failed
Partition User logins
allowed
N/A 15 Configurable
The SO can configure. Default is 15;
maximum value is 15.
RSA signature
confirmation
N/A
Allow X
Enable SO can configure internal RSA
signature verification in the module
before returning the signature to the
caller.
Disable
Disallow Disable
Internal RSA signature verification
cannot be turned on.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 10 of 20
3.2. FIPS-Approved Mode
The SO controls operation of the 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),
ƒ “Level 3 operation without a challenge” must be disabled if activation or auto-
activation is enabled, and
ƒ “Count failed challenge – response validations” must be enabled if activation or auto-
activation is enabled.
ƒ Raw RSA operations must 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 the
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 the 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 the cryptographic module as part
of the company’s service. The operator might be that individual or group, particularly if they are
interacting with the module locally. The operator might also be the composite of the individual or
group, who might still be present locally to the 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
The Luna® PCI Cryptographic Module supports three authenticated operator roles: Crypto User and
Crypto Officer for each partition (collectively called the Partition Users), plus the Security Officer at
the module level. It also supports one unauthenticated operator role, the Public User, primarily to
permit access to status information and diagnostics before authentication.
The SO is a privileged role, which exists only at the module level, whose primary purpose is to initially
configure the 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.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 11 of 20
The Luna® PCI Cryptographic Module can be configured to support many individual key containers
within one group partition. For such key containers only the Crypto Officer role is applicable.
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 either 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 Partition User (which can include both the Crypto Officer and
Crypto User role for the partition5
) 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.
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:
• Partition ID.
• Checkword.
2. If Partition reset is allowed and enabled, the SO role only can modify the following security
attribute:
• Locked out flag for Partition User.
3. Only the Partition User can modify the following security attribute:
• Checkword for Partition User.
4. Only the Security Officer role can change the default value, query, modify and delete the
following security attribute:
• Checkword for Security Officer.
5
A Partition effectively represents an identity within the module.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 12 of 20
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 the module and the
processing of commands within the 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 the module associated with the same Access ID/Partition ID
combination. It is also possible for the module to have sessions opened for more than one Partition
ID or have multiple Access IDs with sessions opened on the module. Applications running on remote
host systems that require data and cryptographic services from the 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 the
module. A local application (e.g., command line administration interface) will open a session directly
with the appropriate partition within the 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:
• Create,
• Copy,
• Generate,
• Unwrapping,
• Derive.
Existing objects can be modified and deleted. The values of a subset of attributes can be changed
through a modification operation. Objects can be deleted through a destruction operation. Constant
operations do not cause creation, modification or deletion of an object. These constant operations
include:
• Query an object’s size;
• Query the size of an attribute;
• Query the value of an attribute;
• Use the value of an attribute in a cryptographic operation;
• Search for objects based on matching attributes;
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 13 of 20
• 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. 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 generates the authentication secret as a 48-byte random value and, if Activation is
enabled for the partition, as a challenge secret for the Partition User, identified to the module by the
Partition ID number as described in section 3.3.3. The authentication secret(s) are provided to the
operator via a physically separate trusted path, described in 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.
When a Group Partition is used, the password for each individual key container6
(only the Crypto
Officer role applies to key containers within a Group Partition) is established by the user when the key
container is initialized. The password is used by the login process in the same challenge-response
scheme as the one used for partition authentication.
3.4.2. Trusted Path
User authentication is a two-stage process. The first stage is termed “Activation” and is performed
using the Luna PED. Activation requires the transmission to the cryptographic module of the Black
iKey data combined with the optional PIN through the trusted path. Once Activation has been
performed, the partition data is ready for use within the cryptographic module. Access to key material
and cryptographic services, however, is not allowed until the second stage of authentication,
equivalent to “User Login”, has been performed. This typically requires the input of a partition’s
challenge secret as part of a login operation. The challenge secret is combined with a random one-
time challenge from the module to form the response. The encrypted one-time response is returned
to the cryptographic module where it is verified to confirm the “User Login”.
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 partition7
, the presentation of the
iKey data (i.e., equivalent to Activation) is all that is required to complete authentication.
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 HSM) 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 HSM and establishes a one-time AES key to encrypt the communications
between the HSM and the remote PED. Once secure communications have been established, all
interactions between the HSM, PED and iKeys are performed in exactly the same way as they would
be when locally connected.
The logical path between the HSM and the remote PED is secured in the manner described below.
6
In this case, the key container or “sub-partition” represents an identity within the module.
7
Challenge/response authentication might, for example, be disabled in a case where both the cryptographic module and the attached
application server are located within a physically secured environment and the user is always required to be physically present to start
the application and authenticate to the cryptographic module via the PED.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 14 of 20
At the time it is initialized, the HSM generates a random 256 bit secret known as the Remote PED
Vector (RPV), stores it in its secure parameters area and writes it to the “Orange” iKey, also known as
the Remote PED Key (RPK).
To establish the secure connection, the RPK must be inserted into the PED. The PED extracts the
RPV, and the PED and the HSM 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 HSM is encrypted using AES 256.
3.4.3. M of N Authentication
The Luna PCI cryptographic module supports the use of an M of N secret sharing authentication
scheme. M of N authentication provides the capability to enforce multi-person integrity over SO
operations and activation of each partition.
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. Each
vector carries the identifier of the M of N set to which it belongs.
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)8
consecutive SO logon attempts fail, the 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
HSM 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 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 the module. It governs the
rights of a subject to perform privileged functions and to access objects stored in the module. It
covers the object operations detailed in section 3.3.7.
A subject’s access to objects stored in the module is mediated on the basis of the following subject
and object attributes:
8
Configurable to a maximum of 10; default is 3.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 15 of 20
• 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 Extractable9
. 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 labeled 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 the 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® PCI
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 the module’s
control.
9
Extract means to remove the key from the control of the module. This is typically done using the Wrap operation.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 16 of 20
The module does not allow any granularity of access other than owner or non-owner (i.e., a Private
object is only accessible by one Partition User. It 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 HSM 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 HSM and Partition Capability and Policy settings.
3.5.1. 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.2. Privileged Functions
The module shall restrict the performance of the following functions to the SO role only:
• Module initialization
• Partition creation and deletion
• Configuring the module and partition policies
• Module zeroization
• Firmware update
3.6. Cryptographic Material Management
Cryptographic material (key) management functions protect the confidentiality of key material
throughout its life-cycle. The FIPS PUB 140-2 approved key management functions provided by the
module are the following:
(1) Pseudo random number generation in accordance with ANSI X9.31, Appendix A2.4.
(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, 168 bits (FIPS PUB 46-3, ANSI X9.52).
c. AES 128, 192, 256 bits (FIPS PUB 197).
d. DSA 1024 bits key pairs in accordance with FIPS PUB 186-2.
(3) Secure key storage and key access following the PKCS #11 standard.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 17 of 20
(4) 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 the Luna® PCI Cryptographic Module is destroyed using the PKCS #11
function C_DestroyObject is marked invalid and its attributes are zeroized (all bits set
to zero). The object memory location (flash or RAM) remains occupied by the
zeroized object until such time as it is re-allocated for additional data on the Luna®
PCI Cryptographic Module.
b. Objects on the Luna® PCI 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 the Luna® PCI Cryptographic Module are zeroized.
c. Objects on the Luna® PCI Cryptographic Module that are destroyed through
C_InitToken (the SO-accessible command to initialize the Luna® PCI Cryptographic
Module available through the API) are zeroized, along with the rest of the flash
memory being used by the SO and Partition Users.
Keys are always stored as secret key or private key objects with the Sensitive attribute set. The key
value is, therefore, stored in encrypted form using the owning Partition User’s secret key. 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 the module using the Unwrap, Unmask (if
enabled at the HSM and partition 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 the module and their
attributes are set by the module to values required by the Access Control Policy.
3.7. Cryptographic Operations
Because of its generic nature, the module firmware supports 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 (wrap/unwrap): TDES 112, 168 bits (FIPS PUB 46-3,
ANSI X9.52).
(2) Symmetric encryption/decryption (wrap/unwrap): AES 128, 192, 256 bits (FIPS PUB
197).
(3) Asymmetric key wrap/unwrap: RSA 1024-4096 (PKCS #1 V1.5)
(4) Signature generation/verification: RSA 1024-4096 bits (PKCS #1 V1.5) with SHA-1, SHA-
224, SHA-256, SHA-384, SHA-512 (FIPS PUB 180-2), RSA 1024-4096 bits (PSS) with
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (FIPS PUB 180-2), RSA 1024-4096 bits
(X9.31) with SHA-1, DSA 1024 bits (FIPS PUB 186-2) with SHA-1, ECDSA (ANSI X9.62)
with SHA-1.
(5) Hash generation SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (FIPS PUB 180-2).
(6) Keyed hash generation HMAC using SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
(FIPS PUB 198).
(7) Message authentication TDES MAC (FIPS PUB 113)
(8) Random number generation (ANSI X9.31 A2.4).
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 18 of 20
Algorithm Validation Certificates
AES (Certificate #510, Certificate #1737, Certificate #1738)
DSA (Certificate #542, Certificate #543)
ECDSA (Certificate #228, Certificate #229) – Only NIST
Recommended Curves
HMAC: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
(Certificate #1014, Certificate #1015)
RNG (Certificate #925, Certificate #926)
RSA (Certificate #860, Certificate #861)
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Certificate #1522,
Certificate #1523)
TDES (Certificate #520, Certificate #1126, Certificate #1127)
TDES MAC (Vendor Affirmed; Certificate #520)
Table 3-4. Algorithm Validation Certificates
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.
Test When Performed Indicator
Firmware CRC by boot block prior to firmware start Power-on Module halt
10
Firmware SHA-1 Power-on Module halt
Known-Answer Tests (KATs) for all approved functions
(Section 3.7)
Power-on / Request Module halt / Error -
Halt
Approved RNG continuous tests Continuous Error - Halt
Non-approved (hardware) RNG continuous 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 On firmware update
load
Error – module will
continue with
existing firmware
Table 3-5. Module Self-Tests
3.9. Firmware Security
The Firmware Security Policy assumes that any firmware images loaded in conformance with the
policy have been verified by SafeNet to ensure that the firmware will function correctly. The policy
applies to initial firmware loading and subsequent firmware updates.
10
Details of the failure can be obtained from the dual-port following a module halt.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 19 of 20
The module shall not allow external software11
to be loaded inside its boundary. Only properly
formatted firmware may be loaded. The communication of initial or updated firmware to a target
module is 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 may be derived
by the receiving module for decryption. The unencrypted firmware must not be visible outside the
module before, during and after the loading operation.
The firmware shall provide mechanisms to ensure its own integrity and to ensure the integrity of any
permanent security-critical data stored within the module. RSA (4096 bits) PKCS #1 V1.5 with SHA-1
is used as the approved signature method.
3.10. Physical Security
The Luna® PCI Cryptographic Module is a multi-chip embedded module as defined by FIPS PUB
140-2 section 4.5. It is enclosed in a strong enclosure that provides tamper-evidence. Any tampering
that might compromise the module’s security is detectable by visual inspection of the physical
integrity of the module. The enclosure covers are bonded to the circuit card assembly and any
attempt to remove either of the covers will result in significant damage to the card, rendering the
module 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 only plaintext Critical Security Parameter (CSP) stored inside the module is the Token Variable
Key (TVK), which is used to implement the auto-activation feature. If that feature is used, the TVK is
stored in battery-backed RAM, which is zeroized in the event of a tamper detection – either from the
external tamper signal or removal of the card from the PCI slot.
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 the 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.
The module shall maintain its secure state12
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 the 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.
11
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.
12
A secure state is one in which either the Luna PCI 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 the Luna PCI
cryptographic module.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page 20 of 20
- THIS PAGE LEFT BLANK INTENTIONALLY -
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page A-1 of A-2
APPENDIX A. CRYPTOGRAPHIC ALGORITHMS SUPPORT
FIPS-approved or FIPS-allowed algorithms are shown in bold lettering.
Random Number Generation
• ANSI X9.31 Appendix A, para 2.4 (uses non-approved HRNG as source of seed data)
Encrypt/Decrypt:
• TDES-ECB
• TDES-CBC
• AES-ECB
• AES-CBC
• DES-ECB
• DES-CBC
• RC2-ECB
• RC2-CBC
• RC4
• RC5-ECB
• RC5-CBC
• CAST5-ECB
• CAST5-CBC
• RSA X-509
• SEED
Digest:
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512
• MD2
• MD5
• HAS-160
Sign/Verify:
• RSA-1024-4096 X9.31
• RSA-1024-4096 PKCS #1 V1.5
• RSA-1024-4096 PSS with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
• DSA 1024
• ECDSA
• TDES-MAC
• HMAC-SHA1
• HMAC-SHA-224
• HMAC-SHA-256
• HMAC-SHA-384
• HMAC-SHA-512
• AES MAC
• DES-MAC
• RC2-MAC
• RC5-MAC
• CAST5-MAC
• HAS-160 MAC
• SSL3-MD5-MAC
• SSL3-SHA1-MAC
• KCDSA
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page A-2 of A-2
Generate Key:
• 2Key TDES
• 3Key TDES
• AES 128, 192, 256 bits
• DES
• RC2
• RC4
• RC5
• CAST5
• SEED
• GENERIC-SECRET
• SSL PRE-MASTER
Generate Key Pair:
• RSA-1024 – 4096 X9.31 and PKCS #1
• DSA-1024
• ECDSA (NIST curves)
• DH-1024 - provides 80-bits of encryption strength
• KCDSA
Wrap Symmetric Key Using Symmetric Algorithm:
• TDES-ECB
• AES ECB
• RC2-ECB
• CAST5-ECB
Wrap Symmetric Key Using Asymmetric Algorithm:
• RSA-1024 - provides 80-bits of encryption strength
• RSA-2048 - provides 112-bits of encryption strength
• RSA 4096 - provides 150-bits of encryption strength
Wrap Asymmetric Key Using Symmetric Algorithm:
• TDES-CBC
• AES-CBC
Unwrap Symmetric Key With Symmetric Algorithm:
• TDES-ECB
• AES ECB
• RC2-ECB
• CAST5-ECB
Unwrap Symmetric Key With Asymmetric Algorithm:
• RSA-1024
• RSA-2048
• RSA-4096
Unwrap Asymmetric Key With Symmetric Algorithm:
• TDES-CBC
• AES-CBC
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page B-1 of B-6
APPENDIX B. SECURITY POLICY CHECKLIST TABLES
Table B-1 Roles and Required Identification and Authentication
Role Type of Authentication Authentication Data
Security Officer Identity-based Level 3 – Authentication token (iKey – one or optional split key)
plus optional PED PIN
Crypto Officer Identity-based
13
Level 3 – Authentication token (iKey – one or optional split key)
plus optional PED PIN, plus optional Challenge Secret for the
role
14
Crypto User Identity-based Level 3 – Authentication token (iKey – one or optional split key)
plus optional PED PIN, plus optional Challenge Secret for the
role
Public User Not required N/A
Table B-2 Strengths of Authentication Mechanisms
Authentication Mechanism Strength of Mechanism
iKey (Level 3) plus PIN 48 byte random authentication data stored on iKey plus PIN entered
via PED key pad (if PED PIN is used, minimum length is4 digits)
Challenge Secret (Level 3) 75 random bits represented as 16 character string
Table B-3 Services Authorized for Roles
Role Authorized Services
Security Officer Show Status, Self-test, Zeroize Module, Initialize Module, Configure Module Policy, Create Partition,
Configure Partition Policy, Firmware Update, HSM Backup and Restore
Crypto Officer Show Status, Self-test, Key and Key Pair Generation, Symmetric Encrypt/Decrypt, Asymmetric
Signature/Verification, Symmetric & Asymmetric Key Wrap/Unwrap, 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
13
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.
14
If activation or auto-activation is enabled, challenge secret is required in FIPS mode
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page B-2 of B-6
Table B-4 Access Rights within Services
Service Cryptographic Keys and CSPs Role Type(s) of Access
Show Status
15
N/A All N/A
Self-test N/A All N/A
Initialize Module Authentication data via trusted path SO Write – SO authentication data
Firmware Update MVK
16
SO Use, Write (firmware only)
Configure Module Policy Authentication data via trusted path SO Use
17
Create Partition Authentication data via trusted path SO Write – User authentication
data
Configure Partition Policy Authentication data via trusted path SO Use
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
Backup / Restore Symmetric keys, asymmetric key pairs Crypto Officer Transfer
18
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 User
19
Write
Read Data Object Non-cryptographic data Crypto Officer,
Crypto User,
Public User
18
Read
Zeroize Authentication data, symmetric keys, asymmetric
key pairs
SO Write, Erase
15
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.
16
Public key value. See Table B-5 for description.
17
Use means access to key material for use in performing a cryptographic operation. The key material is never visible.
18
Transfer means moving a key using the cloning protocol from one crypto module to another.
19
The Public User has access to Public Data Objects only.
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page B-3 of B-6
Table B-5 Keys and Critical Security Parameters Used by the Module
Key Name Description Zeroization Mechanism
Challenge Secret Used in Trusted Path Authentication (Level 3)
configuration only. 16 character random string
generated by the HSM 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 using the SGSK.
N/A
Random challenge Used in Trusted Path Authentication (Level 3)
configuration only. A one-time random number
generated by the HSM 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 HSM. Temporarily held in RAM
as plaintext.
Power-cycle
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. Temporarily held in RAM as plaintext.
Power-cycle
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. Temporarily held in
RAM as plaintext.
Power-cycle
RNG Seed Value (V) The 64 bit intermediate value of the X9.31 Annex A2.4
TDES-based PRNG algorithm. It is used as one of the
initial seed values for the algorithm. It is stored in flash
encrypted with the GSK.
N/A
RNG Key Value (*K) The double-length TDES key used for the X9.31 Annex
A2.4 TDES-based PRNG algorithm. It is used as one
of the initial seed values for the algorithm. It is stored in
flash encrypted with the GSK.
N/A
iKey Authentication Data Used in Trusted Path Authentication (Level 3)
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
(iKey) via the Trusted Path. Authentication data may
be split onto multiple iKeys using the M of N secret
splitting scheme. Stored on the iKey as plaintext.
N/A
Optional PIN An optional PIN value used for authentication along
with the iKey. It must be a minimum of 4-bytes long.
N/A
Cloning Domain Vector 24-byte value that is used to control a module’s ability
to participate in the cloning protocol and used in the
derivation of the masking key. 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 one or more iKeys
(the M of N scheme can be used) to enable initializing
additional modules into the same domain.
N/A
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page B-4 of B-6
Table B-5 Keys and Critical Security Parameters Used by the Module
Key Name Description Zeroization Mechanism
User Storage Key (USK) 32-byte AES key that is randomly generated for each
user on a Luna PCI configured for use in the Luna®
PCI Cryptographic Module. Encrypted, as part of the
UAV, by the key taken from the PED key data. This
key is used to encrypt all sensitive attributes of all
private objects owned by the user.
N/A
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.
Encrypted, as part of the SOV, by the key taken from
the PED key data. This key is used to encrypt all
sensitive attributes of all private objects owned by the
SO.
N/A
Global Storage Key (GSK) 256 bit 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. Stored
encrypted with the USK and SMK.
N/A
Secondary Global Storage
Key (SGSK)
256 bit AES key that is the same for all users on a
specific Luna cryptographic module. 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. Stored encrypted using USK and SMK.
N/A
Token or Module Wrapping
Key (TWK)
A 1024-bit RSA private key used in the cloning
protocol. Stored in the Param area; encrypted with the
GSK.
N/A
Token or Module Wrapping
Certificate (TWC)
An X.509 public key certificate signed by the HOK,
corresponding to the TWK and used in exchange of
session encryption key as part of the handshake during
the cloning protocol. Stored as plaintext in the Param
area.
N/A
U 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; encrypted with the GSK.
N/A
Token or Module Variable
Key (TVK)
32-byte AES key used to encrypt authentication data
stored for auto-activation purposes. Stored as plaintext
in dedicated non-volatile RAM.
NVRAM is actively
zeroized in response to
a tamper event.
Masking Key AES 256-bit keys derived on the HSM individually for
every user partition and for SO. SO’s key is derived on
the HSM at initialization time. Partitions’ masking keys
are derived during partition creation. The keys are used
for masking operations. Stored in flash; encrypted with
the SGSK.
N/A
Manufacturer’s Integrity
Certificate (MIC)
4096 bit RSA public key certificate corresponding to the
Manufacturer’ 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.
N/A
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page B-5 of B-6
Table B-5 Keys and Critical Security Parameters Used by the Module
Key Name Description Zeroization Mechanism
Manufacturer’s 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.
N/A
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. Stored in flash encrypted with the GSK.
N/A
Device Encryption Key
(DEK)
One-time AES 256 bit key used to encrypt Remote
PED communications. Temporarily held in RAM as
plaintext.
Power-cycle
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.
N/A
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.
N/A
Remote PED Vector (RPV) 256 bit random secret that is generated at the time the
module is initialized and then used in the derivation of
the DEK. Stored on iKey as plaintext. Encrypted using
the SGSK and stored in the Param area.
N/A
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page B-6 of B-6
- THIS PAGE LEFT BLANK INTENTIONALLY -
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page C-1 of C-2
APPENDIX C. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS
Term Definition
CA Certification Authority
Chrysalis-ITS Former name of SafeNet Canada, Inc.
CRT Chinese Remainder Theorem
CSP Critical Security Parameter
DAK Device Authentication Key
DEK Device Encryption Key
ECC Elliptic Curve Cryptography
FIPS Federal Information Processing Standard
GSK Global Storage Key
HA High Availability
HOC Hardware Origin Certificate
HRNG Hardware Random Number Generator
HSM Hardware Security Module
KAT Known Answer Test
MIC Manufacturer’s Integrity Certificate
MIK Manufacturer’s Integrity Key
MSK Manufacturer’s Signature Key
MVK Manufacturer’s Verification Key
PCI Peripheral Component Interconnect
PED PIN Entry Device
RA Registration Authority
RPK Remote PED Key
RPV Remote PED Vector
SCU Secure Capability Update
SGSK Secondary Global Storage Key
SIM Secure Information Management
SMK Security Officer’s Master Key
SO Security Officer
TVK Token or Module Variable Key
TWC Token or Module Wrapping Certificate
TWK Token or Module Wrapping Key
USK User’s Storage Key
CR-2333 Revision Level: 22
Document is Uncontrolled When Printed.
Page C-2 of C-2
- THIS PAGE LEFT BLANK INTENTIONALLY -