Document is uncontrolled when printed.
LEVEL 3 NON-PROPRIETARY SECURITY POLICY FOR
SafeNet PCIe Hardware Security Module and
SafeNet PCIe Hardware Security Module for
SafeNet Network HSM
(Used as a Standalone Device that includes configurations Cloning [CL] and Key
Export [CKE]; and as an Embedded Device in SafeNet Network HSM that
includes configurations Cloning [CL], Signing No Cloning [SNC], and Key Export
[CKE])
DOCUMENT NUMBER: 002-010961-001
REVISION LEVEL: F
REVISION DATE: June 21, 2018
SECURITY LEVEL: Non-proprietary
© Copyright 2018 Gemalto
ALL RIGHTS RESERVED
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Gemalto 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 Gemalto in this
document is believed to be accurate and reliable. However, no responsibility is assumed by Gemalto for its use, or for any infringements of
patents or other rights of third parties resulting from its use.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 2 of 55
PREFACE
This document deals only with operations and capabilities of the SafeNet PCIe Hardware Security
Module and SafeNet PCIe Hardware Security Module for SafeNet Network HSM in the technical terms of
a FIPS 140-2 Hardware Security Module security policy. More information is available on the SafeNet
PCIe and other Gemalto products from the following sources:
• The SafeNet internet site contains information on the SafeNet Hardware Security Modules and
other SafeNet-branded security products at https://safenet.gemalto.com/.
• The Gemalto internet site contains information on the full line of Gemalto security products at
http://www.gemalto.com/.
1. For answers to technical or sales related questions please refer to the contacts listed below or
on the Gemalto internet site at https://safenet.gemalto.com/contact-us/ .
Gemalto Contact Information for SafeNet-Branded Products:
Headquarters 4690 Millennium Drive
Belcamp, MD 21017
Telephone: 410-931-7500
TTY Users: 800-735-2258
Fax: 410-931-7524
Canada 20 Colonnade Road
Suite 200
Ottawa, Ontario
K2E 7M6
Telephone: +1 613 723 5077
Fax: +1 613 723 5079
Sales: 800-533-3958
Technical Support:
U.S. 800-545-6608
International 410-931-7520
Customer Service:
U.S. 866-251-4269
EMEA +44 (0) 1276 60 80 00
APAC 852 3157 7111
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 3 of 55
TABLE OF CONTENTS
Section Title Page
1. INTRODUCTION...........................................................................................................................6
1.1 Purpose..................................................................................................................................... 6
1.2 Scope ........................................................................................................................................ 6
1.3 Overview................................................................................................................................... 6
2. SECURITY POLICY MODEL INTRODUCTION ...................................................................................7
2.1 Functional Overview.................................................................................................................. 7
2.2 Assets to be Protected............................................................................................................... 9
2.3 Operating Environment............................................................................................................. 9
3. SECURITY POLICY MODEL DESCRIPTION .....................................................................................10
3.1 Operational Policy ................................................................................................................... 10
Module Capabilities.......................................................................................................... 11
Partition Capabilities ........................................................................................................ 12
3.2 FIPS-Approved Mode............................................................................................................... 20
3.3 Description of Operator, Subject and Object............................................................................ 20
Operator .......................................................................................................................... 20
Roles ................................................................................................................................ 21
Account Data.................................................................................................................... 22
Subject ............................................................................................................................. 23
Operator – Subject Binding............................................................................................... 23
Object .............................................................................................................................. 23
Object Operations ............................................................................................................ 24
3.4 Identification and Authentication ............................................................................................ 24
Authentication Data Generation and Entry ....................................................................... 24
Trusted Path..................................................................................................................... 25
3.4.2.1. Remote PED Operation.............................................................................................. 26
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 4 of 55
Secure Messaging............................................................................................................. 26
M of N Authentication...................................................................................................... 27
Limits on Login Failures..................................................................................................... 27
3.5 Access Control......................................................................................................................... 28
Object Protection ............................................................................................................. 30
Object Re-use................................................................................................................... 30
Privileged Functions.......................................................................................................... 30
3.6 Cryptographic Material Management...................................................................................... 31
Key Cloning....................................................................................................................... 32
Key Mask/Unmask............................................................................................................ 33
Key Wrap/Unwrap............................................................................................................ 33
3.7 Cryptographic Operations........................................................................................................ 34
3.8 Self-tests ................................................................................................................................. 39
3.9 Firmware Security ................................................................................................................... 40
3.10 Physical Security............................................................................................................... 40
Secure Recovery............................................................................................................... 41
3.11 EMI / EMC ........................................................................................................................ 41
3.12 Fault Tolerance................................................................................................................. 42
3.13 Mitigation of Other Attacks .............................................................................................. 42
APPENDIX A. SECURITY POLICY CHECKLIST TABLES............................................................................. 43
APPENDIX B. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS ........................................................ 54
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 5 of 55
LIST OF TABLES
Table Title Page
Table 1-1. FIPS 140-2 Security Requirements .......................................................................................... 6
Table 3-1. Module Capabilities and Policies .......................................................................................... 13
Table 3-2. Partition Capabilities and Policies......................................................................................... 16
Table 3-3. Object Attributes Used in Access Control Policy Enforcement............................................... 29
Table 3-4. Approved Security Functions for SafeXcel 3120.................................................................... 34
Table 3-5. Approved and Allowed Security Functions for SafeXcel 1746................................................ 35
Table 3-6. Approved Security Functions for Firmware Implementation................................................. 36
Table 3-7. Allowed Security Functions for Firmware Implementation.................................................... 37
Table 3-8. Non-FIPS Approved Security Functions................................................................................. 37
Table 3-9. Module Self-Tests................................................................................................................. 39
Table A-1. Roles and Required Identification and Authentication.......................................................... 43
Table A-2. Strengths of Authentication Mechanisms............................................................................. 43
Table A-3. Services Authorized for Roles............................................................................................... 44
Table A-4. Access Rights within Services ............................................................................................... 45
Table A-5. Keys and Critical Security Parameters................................................................................... 48
LIST OF FIGURES
Figure Title Page
Figure 2-1. SafeNet PCIe Hardware Security Module............................................................................... 8
Figure 2-2. SafeNet Network HSM (with SafeNet PCIe Installed), SafeNet PED and iKeys......................... 8
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 6 of 55
1. INTRODUCTION
1.1 Purpose
This document describes the security policies enforced by Gemalto’s SafeNet PCIe Hardware Security
Module1
and SafeNet PCIe Hardware Security Module for SafeNet Network HSM.
The SafeNet PCIe Hardware Security 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 SafeNet Network HSM, which includes the following configurations:
o Cloning [CL],
o Signing No Cloning [SNC], and
o Key Export [CKE]
This document applies to Hardware Version VBD-05, Version Code 0100; Hardware Version VBD-05,
Version Code 0101; Hardware Version VBD-05, Version Code 0102; and Hardware Version VBD-05,
Version Code 01032 3
with Firmware Version 6.24.6 and 6.24.7.
1.2 Scope
The security policies described in this document apply to the Trusted Path Authentication (Level 3)
configuration of the SafeNet PCIe Hardware Security Module only and do not include any security policy
that may be enforced by the host appliance or server.
1.3 Overview
The Hardware Security 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
Hardware Security Module Specification 3
1 Also known as the K6 Hardware Security Module or the Luna PCI-E Hardware Security Module.
2
The Hardware Version may also be displayed as VBD-05-0100, VBD-05-0101, VBD-05-0102, or VBD-05-0103. Both types of
displays represent the equivalent Hardware Versions of the SafeNet PCIe Hardware Security Module.
3 From the perspectives of functionality and physical security, Hardware Version VBD-05, Version Code 0100 (or VBD-05-0100);
Hardware Version VBD-05, Version Code 0101 (or VBD-05-0101); Hardware Version VBD-05, Version Code 0102 (or VBD-05-
0102); and Hardware Version VBD-05, Version Code 0103 (or VBD-05-0103) are equivalent.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 7 of 55
Security Requirements Section Level
Hardware Security 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
Hardware Security Module Security Policy 3
2. SECURITY POLICY MODEL INTRODUCTION
2.1 Functional Overview
The SafeNet PCIe Hardware Security 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 PCIe card. Figure 2-1 depicts the SafeNet
PCIe Hardware Security Module and Figure 2-2 depicts the SafeNet Network HSM appliance, with the
SafeNet PCIe module installed, as well as the PED and iKeys used for authentication.
The module may be purchased as either a FIPS Level 2 or FIPS Level 3 module. The end user can
configure the modules to operate in either FIPS mode of operation or non-FIPS mode of operation.
Configuration in FIPS mode of operation enforces the use of FIPS-approved algorithms only. For the FIPS
Level 3 module the use of trusted path authentication is enforced. The module's FIPS mode can be
changed by policy; changing this policy is destructive and will zeroize 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-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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 8 of 55
This Security Policy is specifically written for the SafeNet PCIe Hardware Security Module in a Trusted
Path Authentication (FIPS Level 3) configuration.
Figure 2-1. SafeNet PCIe Hardware Security Module
Figure 2-2. SafeNet Network HSM (with SafeNet PCIe Installed), SafeNet PED and iKeys
Cryptographic
Boundary
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 9 of 55
2.2 Assets to be Protected
The module is designed to protect the following assets:
1. User-generated private keys,
2. User-generated secret keys,
3. Cryptographic services, and
4. Module security critical parameters.
2.3 Operating Environment
The module is assumed to operate as a key management and cryptographic processing card within a
security appliance that may operate in a TCP/IP network environment. The host appliance may be used
in an internal network environment when key management security is a primary requirement. It may
also be deployed in environments where it is used primarily as a cryptographic accelerator, in which
case it will often be connected to external networks. It is assumed that the appliance includes an
internal host computer that runs a suitably secured operating system, with an interface for use by locally
connected or remote administrators and an interface to provide access to the module’s cryptographic
functions by application services running on the host computer. It is also assumed that only known
versions of the application services are permitted to run on the internal host computer of the appliance.
It is assumed that trained and trustworthy administrators are responsible for the initial configuration
and ongoing maintenance of the appliance and the cryptographic module.
It is assumed that physical access to the cryptographic module will be controlled, and that connections
will be controlled either by accessing the module via a direct local connection or by accessing it via
remote connections controlled by the host operating system and application service.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 10 of 55
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 Hardware Security 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.
3.1 Operational Policy
The module employs the concept of the Operational Policy to control the overall behaviour of the
module and each of the partitions within. At each level, either the module or the partition is assigned a
fixed set of “capabilities” that govern the allowed behaviour of the module or individual partition. The
Security Officer (SO) or Partition Security Officer (PSO) 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
“enable domestic mechanisms & key sizes” does not have a corresponding configurable policy element.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 11 of 55
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 settings4
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.
Module Capabilities
The following is the set of capabilities supported at the module level:
• Allow/disallow password authentication (disallowed in Trusted Path configuration)
• Allow/disallow trusted path authentication (allowed and must be enabled in Level 3
configuration)
• Allow/disallow masking5
• Allow/disallow cloning
• Allow/disallow non-FIPS algorithms
• Allow/disallow SO reset of partition PIN6
• Allow/disallow network replication
• Allow/disallow remote authentication
• Allow/disallow forcing change of User authentication data
• Allow/disallow offboard storage
• Allow/disallow partition groups
• Allow/disallow Remote PED (RPED) operations
• Allow/disallow external Master Tamper Key (MTK) split storage
4
The nomenclature used for these setting is based on PKCS#11.
5
A Gemalto term used to describe the encryption of a key for use only within a SafeNet Hardware Security Module.
6 In this instance PIN is used to represent a Personal Identification Number or a password.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 12 of 55
• Allow/disallow Acceleration
• Allow/disallow unmasking
• Allow/disallow FW5 compatibility mode
• Maximum number of partitions
• Allow/disallow ECIES support
• Allow/disallow force single domain
• Allow/disallow unified PED key
• Allow/disallow M of N
• Allow/disallow small form factor backup/restore
• Allow/disallow Secure Trusted Channel
• Allow/disallow decommission on tamper
• Allow/disallow partition re-initialize
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/PSO 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 (Ignore failed challenge responses).
• Allow/disallow activation.
• Allow/disallow automatic activation (auto-activation).
• Allow/disallow High Availability (HA) recovery.
• 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 partitions is locked out/cleared. The
default is 10 for user partition logins and Partition SO logins; SO/PSO can configure it to be
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 13 of 55
1<N>10. The default is 3 for SO logins; SO can configure it to be 1 ≤ N ≤ 3.
• Minimum/maximum PIN length (configurable 7 to 255)
• Allow/disallow remote authentication
• Allow/disallow RSA PKCS mechanism
• Allow/disallow CBC-PAD (un)wrap keys of any size
• Allow/disallow private key SFF backup/restore
• Allow/disallow secret key SFF backup/restore
• Allow/disallow Force Secure Trusted Channel
The following capabilities are configurable only if the corresponding capability/policy is allowed and
enabled at the module level:
• Allow/disallow private key cloning.
• Allow/disallow secret key cloning.
• Allow/disallow private key masking7
.
• Allow/disallow secret key masking.
• Allow/disallow private key unmasking.
• Allow/disallow secret key unmasking.
The following tables summarize the module and partition capabilities, showing typical capability settings
for SafeNet PCIe Hardware Security Modules used in the following configurations:
• SafeNet PCIe product configurations:
o Key Export (CKE), and
o Cloning (CL); and
• SafeNet Network HSM 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.
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
7 Key masking is a SafeNet product feature that provides encrypted key output. Key masking provides AES 256-bit encryption
employing additional proprietary obfuscation, which does not provide additional security. Within the terms of FIPS 140-2 and
supporting Implementation Guidance, this capability is a form of “key wrapping”.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 14 of 55
Description Capability CKE CL SNC Policy Comments
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 The trusted path authentication is set by the
Level 3 configuration to enable (true) and
cannot be changed by the user.
Disable
Disallow Disable
The cryptographic module must operate using
passwords without trusted path for
authentication.8
Remote PED Operations
Allow X X X
Enable The cryptographic module can use Remote PED
for Trusted Path authentication.9 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 X
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 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.
SO reset of partition PIN
Allow X X X
Enable SO can configure the policy to enable a partition
PIN 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 reset the partition PIN and
must be re-created as a result of exceeding the
maximum number of failed login attempts.
8
One and only one means of authentication (“user password” or “trusted path”) must be enabled by the policy. Therefore, one
of the authentication capabilities must be allowed and, if one of the capabilities is disallowed or the policy setting disabled,
then the policy setting for the other must be enabled.
9 Enabled in the Trusted Path configuration. Operator can connect the Hardware Security Module to a Remote PED using
Command Line Interface (CLI) commands.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 15 of 55
Description Capability CKE CL SNC Policy Comments
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.
Partition groups
Allow
Enable This capability is set prior to shipment to the
customer. It allows the use of partition groups.
Disable
Disallow X X X Disable
Partition groups cannot be enabled for the
module.
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.
FW5 compatibility mode
Allow
Enable Allows the use of the FW5 compatibility mode.
The compatibility mode allows the cryptographic
module to use the legacy Token Wrapping
Certificate (TWC) to communicate with the
installed base of legacy units in the field.
Disable
Disallow X X X Disallow
FW5 compatibility mode cannot be enabled for
the module.
Maximum number of partitions N X X X N
This capability is set prior to shipment to the
customer. The default number of partitions
allowed (N) is 1. For the three configurations
shown here, the default is 20.
Remote Authentication
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows remote
authentication.
Disable
Disallow Disallow
Remote Authentication cannot be enabled for
the module.
Portable masking key
(was Offboard Storage)
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows the use of the
portable masking key (offboard storage).
Disable
Disallow Disallow
Use of the portable masking key (offboard
storage) cannot be enabled for the module.
ECIES Support
Allow
Enable This capability is set prior to shipment to the
customer. If enabled it allows support for ECIES.
Disable
Disallow X X X Disallow
ECIES support cannot be enabled for the
module.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 16 of 55
Description Capability CKE CL SNC Policy Comments
Force Single Domain
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows the forcing of a
single domain for a module.
Disable
Disallow Disallow The module cannot force a single domain.
Unified PED Key
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows the creation and
use of a unified PED key.
Disable
Disallow Disallow
Unified PED key cannot be enabled for the
module.
M of N
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows the use of M of N
keys. If disabled, M and N are set to 1.
Disable
Disallow Disallow M of N cannot be enabled for the module.
Small Form Factor Backup / Restore
Allow
Enable This capability is set prior to shipment to the
customer. If enabled it allows the use of small
form factor backup and restore.
Disable
Disallow X X X Disallow
Small form factor backup/restore cannot be
enabled for the module.
Secure Trusted Channel
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows the use of the
secure trusted channel.
Disable
Disallow Disallow
Secure trusted channel cannot be enabled for
the module.
Decommission on Tamper
Allow
Enable This capability is set prior to shipment to the
customer. If enabled it allows decommission on
tamper.
Disable
Disallow X X X Disallow
Decommission on tamper cannot be enabled for
the module.
Partition Re-initialize
Allow X X X
Enable This capability is set prior to shipment to the
customer. If enabled it allows a partition to be
re-initialized.
Disable
Disallow Disallow
Partition re-initialize cannot be enabled for the
module.
Table 3-2. Partition Capabilities and Policies
Description Prerequisite Capability CKE CL SNC Policy Comments
User key
management
Trusted path
authentication
enabled, Trusted
Path operation
without a
Allow X X X
Enable
SO/PSO 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
Disable
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 17 of 55
Description Prerequisite Capability CKE CL SNC Policy Comments
capability10 challenge disabled functions are accessible.
Disallow Disable
Only the Crypto User role functions are
accessible.
Count failed
challenge-response
validations (Ignore
failed challenge
responses)
Trusted path
authentication
enabled
Allow X X X
Enable SO/PSO 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/PSO 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 X X
Enable
SO/PSO 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
Recovery
N/A
Allow X X X
Enable SO/PSO can configure the policy to
enable the use of the High Availability
recovery feature.
Disable
Disallow Disable
High Availability recovery cannot be
enabled.
Multipurpose keys N/A
Allow X X X
Enable SO/PSO 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.
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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 18 of 55
Description Prerequisite Capability CKE CL SNC Policy Comments
Change attributes N/A
Allow X X X
Enable SO/PSO 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/PSO 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/PSO 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/PSO 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.
Private key
wrapping
N/A
Allow X
Enable SO/PSO 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/PSO 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/PSO 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/PSO 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/PSO 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
Allow X
Enable SO/PSO can configure the ability to
clone secret keys from one module and
partition to another.
Disable
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 19 of 55
Description Prerequisite Capability CKE CL SNC Policy Comments
enabled Disallow X X Disable Secret keys cannot be cloned.
Private key masking Masking enabled
Allow X
Enable SO/PSO can configure the ability to
mask private keys for storage outside
the partition.
Disable
Disallow X X Disable
Private keys cannot be masked for
storage outside the partition.
Secret key masking Masking enabled
Allow X
Enable SO/PSO can configure the ability to
mask secret keys for storage outside the
partition.
Disable
Disallow X X Disable
Secret keys cannot be masked for
storage outside the partition.
Private key
unmasking
Unmasking
enabled
Allow X X X
Enable SO/PSO can configure the ability to
unmask private keys.
Disable
Disallow Disable Private keys cannot be unmasked
Secret key
unmasking
Unmasking
enabled
Allow X X X
Enable SO/PSO can configure the ability to
unmask secret keys.
Disable
Disallow Disable Secret keys cannot be unmasked
Minimum /
maximum password
length
User password
authentication
enabled
7-255
characters
Configur
able
The SO/PSO 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 for user
and PSO,
3 for SO
Configur
able
The SO can configure max failed SO
logins; default maximum value is 3. The
SO/PSO can configure max failed user
and PSO logins; default maximum is 10.
RSA signing without
confirmation
N/A
Allow X X X
Enable SO/PSO 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.
Remote
Authentication
Remote
authentication
enabled
Allow X X X
Enable SO/PSO can configure the ability to
allow remote authentication.
Disable
Disallow Disable
Remote authentication cannot be
enabled.
RSA PKCS
Mechanism
N/A
Allow X X X
Enable SO/PSO can configure the ability to
allow the use of RSA PKCS mechanisms.
Disable
Disallow Disable
RSA PKCS Mechanism cannot be
enabled.
CBC-PAD (Un)Wrap
Keys of Any Size
N/A
Allow X X X
Enable SO/PSO can configure the ability to
allow the wrapping/ unwrapping using
CBC-PAD for keys of any size.
Disable
Disallow Disable CBC-PAD (un)wrap cannot be enabled.
Private Key SFF
Backup/Restore
SFF backup/
restore enabled
Allow
Enable SO/PSO can configure the ability to
backup/restore private keys using SFF.
Disable
Disallow X X X Disable
SFF backup/restore of private keys
cannot be enabled.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 20 of 55
Description Prerequisite Capability CKE CL SNC Policy Comments
Secret Key SFF
Backup/Restore
SFF backup/
restore enabled
Allow
Enable SO/PSO can configure the ability to
backup/restore secret keys using SFF.
Disable
Disallow X X X Disable
SFF backup/restore of secret keys
cannot be enabled.
Secure Trusted
Channel
STC enabled
Allow X X X
Enable SO/PSO can configure the ability to use
a Secure Trusted Channel.
Disable
Disallow Disable
Secure Trusted Channel cannot be
enabled.
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),
• “Count failed challenge – response validations” must be enabled if activation or auto-
activation is enabled, and
• Raw RSA operations can only be used for key transport in FIPS mode
If the SO selects policy options (i.e., enables “Non FIPS Algorithms Available”) that would place a module
in a mode of operation that is not approved, a warning is displayed and the SO is prompted to confirm
the selection. The SO can confirm that the cryptographic module is in FIPS mode by utilizing the “hsm
showinfo” command. With this command, the following message will be displayed, “This HSM is in FIPS
140-2 approved operation mode”.
In accordance to NIST guidance, operators are responsible for insuring that a single Triple-DES key shall
not be used to encrypt more than 216
64-bit data blocks.
3.3 Description of Operator, Subject and Object
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
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 21 of 55
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.
Roles
In the Trusted Path Authentication configuration, the SafeNet Hardware Security Module supports the
following authenticated operator roles: The Security Officer (SO) and Audit Officer11
at the module
level, plus the Partition Security Officer (if applicable12
), Crypto Officer and Crypto User13
for each
Partition. There is an additional Admin Partition in which the SO can optionally enable an authenticated
Admin User role. The Hardware Security Module also supports one unauthenticated operator role, the
Public User, primarily to permit access to status information and diagnostics before authentication.
The SO is a privileged role, which exists only at the module level, whose primary purpose is to initially
configure a module for operation and to perform security administration tasks such as partition
creation.
The Admin User is a privileged role which exists only for the Admin Partition, and is the key
management role for the admin partition.
The Audit Officer is a privileged role, which exists only at the module level to initialize, configure, and
manage secure audit logging. Only the Audit Officer can initialize, configure, and manage the secure
audit logging feature. This allows for a separation of duties between an Audit Officer and the other roles
(e.g. SO, Crypto Officer, and Crypto User) that the Audit Officer is auditing – preventing administrative
and user personnel from tampering with the log files and preventing the Audit Officer from performing
administrative tasks or from accessing keys.
The Partition Security Officer is a privileged role, which exists only at the partition level to manage the
partition policies and roles.
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.
11 Within the confines of the operational use of the SafeNet Hardware Security Module, the FIPS 140-2 term “Crypto Officer”
encompasses the SafeNet Hardware Security Module roles of “Security Officer”, “Audit Officer”, and “Partition Security
Officer”.
12
SafeNet HSMs support two modes of ownership of an application partition. 1) Partition Security Officer (PSO) - The
application partition is entirely owned and controlled by its own Security Officer (SO). 2) Legacy application partition - The
Security Officer of the HSM is also the Security Officer of the application’s partition.
13
Within the confines of the operational use of the SafeNet Hardware Security Module, the FIPS 140-2 term of “User”
encompasses the SafeNet Hardware Security Module roles of “Crypto Officer”, “Crypto User”, and "Admin User", which are
collectively called the Partition Users.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 22 of 55
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 Admin User, Audit Officer, Crypto Officer, Crypto User,
Partition Security Officer or Security Officer role before identification and authentication;
• No identity can assume more than one authenticated role at the same time, e.g. Crypto
Officer or Crypto User plus the Security Officer role, or Audit Officer plus Security Officer.
The CO can create the Crypto User role by creating a challenge value for the Crypto User. In the case of
a partition that supports the Crypto Officer and Crypto User roles, the Security Officer can limit access to
only the Crypto User role by disabling the “User Key Management” (see Table 3-1) policy.
For additional information regarding roles and authorized services, please refer to Table A-1 and Table
A-3.
Account Data
The module maintains the following User (which can include both the Crypto Officer and Crypto User
role per Partition14
) and SO/PSO account data:
• Partition ID.
• Partition encrypted authentication data (checkword).
• Partition authentication challenge secret (one for each role, as applicable).
• Partition locked flag.
An authenticated User is referred to as a Partition User. The ability to manipulate the account data is
restricted to the SO, PSO and the Partition User. The specific restrictions are as described below:
1. Only the Security Officer role can create and delete the following security attributes:
• Partition ID.
• Checkword.
2. If “SO can reset partition PIN” 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 Partition SO can modify the following security attribute:
• Checkword for Partition SO
14 A Partition effectively represents an identity within the module.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 23 of 55
5. Only the Security Officer role can change the default value, query, modify and delete the
following security attribute:
• Checkword for Security Officer.
Subject
For the purposes of this security policy, the subject is defined to be a module session. The session
provides a logical means of mapping between applications connecting to a module and the processing of
commands within a module. Each session is tracked by the Session ID, the Partition ID and the Access
ID, which is a unique ID associated with the application’s connection. It is possible to have multiple
open sessions with a module associated with the same Access ID/Partition ID combination. It is also
possible for a module to have sessions opened for more than one Partition ID or have multiple Access
IDs with sessions opened on a module. Applications running on remote host systems that require data
and cryptographic services from a module must first connect via the communications service within the
appliance, which will establish the unique Access ID for the connection and then allow the application to
open a session with one of the partitions within a module. A local application (e.g., command line
administration interface) will open a session directly with the appropriate partition within a module
without invoking the communications service.
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.
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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 24 of 55
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;
• 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
Authentication Data Generation and Entry
The module requires that Partition Users, Partition SOs 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
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 25 of 55
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 SafeNet PED:
• Orange (RPV) iKey – for the storage of the Remote PED Vector (RPV),
• Blue (SO) iKey – for the storage of SO or Partition SO authentication data,
• Black (User) iKey – for the storage of User authentication data,
• Red (Domain) iKey – for the storage of the cloning domain data, used to control the ability
to clone from a cryptographic module to a backup module,
• Purple (MTK Recovery) iKey – for the storage of an external split that allows the MTK to be
restored after a tamper event,
• White (Audit Officer) iKey – for the storage of Audit Officer authentication data.
Any iKey, once data has been written to it, is an Identification and Authentication device and must be
safeguarded accordingly by the administrative or operations staff responsible for the operation of the
module within the customer’s environment.
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 Hardware
Security Module either directly over a physical wire or remotely over a secure network connection. The
primary form of authentication data used during Activation is the 48-byte value that is randomly
generated by a module and stored on the Black (User) iKey15
via the trusted path. The data on the iKey
must then be entered into a module via the trusted path as part of each Activation process. Once
Activation has been performed, the user’s Partition data is ready for use within a module. Access to key
material and cryptographic services, however, is not allowed until the second stage of authentication,
“User Login”, has been performed. This typically requires the input of a partition’s challenge secret as
part of a login operation. However, for SO authentication, Partition SO authentication and for user
authentication when the settings of the Partition Policy disable the use of challenge/response
authentication for login to a partition16
, the presentation of the iKey data (i.e., equivalent to Activation)
is all that is required to complete authentication.
15
Or Black (User) PED key. Within this document the terms “iKey” and “PED” key are interchangeable unless otherwise
indicated.
16
Challenge/response authentication might, for example, be disabled in a case where both a Hardware Security 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 Hardware Security Module via the PED.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 26 of 55
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 Hardware Security 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).
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.
Secure Messaging
Each partition can individually be configured to use a secure messaging feature called Secure Trusted
Channel (STC). An STC channel is a cryptographic tunnel established between a partition and a
host/client application. The STC channel is designed to provide both confidentiality and integrity on all
ICD commands that are sent to the partition.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 27 of 55
STC for a partition can be configured by registering one or more host/client RSA public keys with a
partition. Once configured, the partition will reject any ICD commands17
that are not delivered to the
module through an STC channel. An STC channel is established by using the partition STC public key and
a registered client RSA key to exchange ephemeral DH public keys (SP800-56B Key Transport), which are
in turn used to derive (SP800-56A key agreement) tunnel encryption, decryption and HMAC keys.
M of N Authentication
The SafeNet Hardware Security 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 SafeNet Hardware Security 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 Hardware Security 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.
Limits on Login Failures
The module also implements a maximum login attempts policy. The policy differs for an SO
authentication data search, a Partition SO authentication data search, a Partition User authentication
data search, or an Audit Officer data search.
In the case of an SO authentication data search:
• If ”m” consecutive SO logon attempts fail, a module is zeroized. “m” is set at the time the
Hardware Security Module is initialized, and can be modified by the SO. The valid range is 1-
3.
In the case of a Partition SO authentication data search:
• If “p” consecutive Partition SO logon attempts fail, the partition is zeroized. “p” is set at the
time the partition is initialized and can be modified by the PSO. The valid range is 1-10.
In the case of a Partition User authentication data search, one of two responses will occur, depending on
the partition policy:
17 Status commands and commands required to setup an STC channel are allowed to pass outside of the STC tunnel.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 28 of 55
1. If “SO reset of partition PIN” is Allowed and Enabled, then if “n” consecutive operator logon
attempts fail, the module locks the Partition User. “n” is set at the time the partition is
initialized and can be modified by the SO/PSO. The valid range is 1-10. . The SO/PSO must
unlock the partition in order for the Partition User to resume operation.
2. If “SO reset of partition PIN” is not Allowed or not Enabled, then if “n” consecutive Partition
User logon attempts fail, the module will erase/zeroize the partition. The SO/PSO must re-
create/initialize the partition. Any objects stored in the partition, including private and
secret keys, are permanently erased.
In the case of an Audit Officer data search:
• If three consecutive Audit Officer logon attempts fail, the Audit Officer account will be
locked for 60 seconds. After the 60 second lockout timeout, the Audit Officer may attempt
to logon to the module again.
3.5 Access Control
The Access Control Policy is the main security function policy enforced by a module. It governs the
rights of a subject to perform privileged functions and to access objects stored in a module. It covers
the object operations detailed in section 3.3.7.
A subject’s access to objects stored in a module is mediated on the basis of the following subject and
object attributes:
• Subject attributes:
o Session ID
o Access ID and Partition ID associated with session
o Session authentication state (binding to authenticated Partition identity and role)
• Object attributes:
o Owner. A Private object is owned by the Partition User associated with the subject
that produces it. Ownership is enforced via internal key management.
o Private. If True, the object is Private. If False, the object is Public.
o Sensitive. If True, object is Sensitive. If False, object is Non-Sensitive.
o Extractable18
. 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.
18 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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 29 of 55
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.
Private key and secret key objects are always created as Sensitive, Private objects. Sensitive objects are
encrypted using the partition’s secret key to prevent their values from ever being exposed to external
entities. Private objects 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 SafeNet 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 SafeNet cryptographic module.
Keys must never leave a module’s control.
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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 30 of 55
• 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.
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 four different keys – each having a separate
protection role. The four keys used to protect sensitive object values are the following:
• User Storage Key (USK) – this key is created when the User, PSO or SO is created/initialized.
It is used to encrypt all sensitive attributes of all private objects owned by the User/PSO/SO.
• Partition Storage Key (PSK) – this key is created by the Hardware Security Module when a
partition is created/initialized. It is unique per-partition and is used to encrypt all CSP that
are shared by all roles of a given partition.
• 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.
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.
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 policies
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 31 of 55
• Configuring the partition policies for partitions without a Partition SO role
• Firmware update
The module shall restrict the performance of the following functions to the Partition SO role for a
partition only:
• Configuring the partition policies for the partition with the Partition SO role
3.6 Cryptographic Material Management
Cryptographic material (key) management functions protect the confidentiality of key material
throughout its life-cycle. The FIPS PUB 140-2 approved key management functions provided by the
module are the following:
1. Deterministic Random Bit Generation (DRBG) in accordance with NIST SP 800-90A section
10.2.1.
2. Cryptographic key generation in accordance with the following indicated standards:
a. RSA 2048-4096 bits key pairs in accordance with FIPS PUB 186-2, FIPS PUB 186-4
and ANSI X9.31.
b. Triple-DES 168 bits (SP 800-67).
c. AES 128, 192, 256 bits (FIPS PUB 197).
d. DSA 2048 and 3072 bit key pairs in accordance with FIPS PUB 186-4.
e. Elliptic Curve key pairs (curves in accordance with SP 800-57) in accordance with
FIPS PUB 186-4.
f. Diffie-Hellman key pairs.
g. Key Derivation in accordance with NIST SP 800-108 (Counter mode).
Symmetric cryptographic keys are generated by the direct unmodified output of the
module’s NIST SP 800-90A DRBG. The DRBG output is also used as a seed for asymmetric
key generation.
3. Diffie-Hellman (2048 bits) (key agreement; key establishment methodology provides 112
bits of encryption strength.19
)
4. EC Diffie-Hellman (ECDH) (curves in accordance with SP 800-57) key establishment in
accordance with NIST SP 800-56A.
5. Symmetric key unwrap: Triple-DES 168 bits and AES 128, 192 and 256 bits in accordance
with PKCS #11 (key transport provides 112 bits of security strength with Triple-DES and
19 Non-Approved but allowed method in FIPS mode.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 32 of 55
between 128 and 256 bits of security strength with AES). Symmetric key wrapping is
supported via SP 800-38F AES key wrap mode.
6. Asymmetric key wrap / unwrap: RSA 2048 – 4096 (PKCS #1 V1.5 and OAEP) (key transport
provides between 112 and 152 bits of security strength).
7. Encrypted key storage (using AES 256 bit encryption, see Section 3.5.1) and key access
following the PKCS #11 standard.
8. Destruction of cryptographic keys is performed in one of three ways as described below in
accordance with the PKCS #11 and FIPS PUB 140-2 standards:
a. An object on a SafeNet 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 SafeNet cryptographic module’s general secret key until
such time as its memory locations (flash or RAM) are re-allocated for additional data
on a SafeNet cryptographic module, at which time they are purged and zeroized
before re-allocation.
b. Objects on a SafeNet 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 SafeNet cryptographic module are zeroized.
c. Objects on a SafeNet cryptographic module that are destroyed through C_InitToken
(the SO-accessible command to initialize a SafeNet cryptographic module available
through the API) are zeroized, along with the rest of the flash memory being used by
the SO and Partition Users.
Keys are always stored as secret key or private key objects with the Sensitive attribute set. The key
value is, therefore, stored in encrypted form using the owning Partition User’s Storage Key (USK) and the
Master Tamper Key (MTK) stored in the battery-backed RAM. Access to keys is never provided directly
to a calling application. A handle to a particular key is returned 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 module level) or Derive operation under the control of the Access
Control Policy. Any externally-set attributes of keys imported in this way are ignored by a module and
their attributes are set by a module to values required by the Access Control Policy.
Key Cloning
Key cloning is a SafeNet product feature that uses a one-time, 256-bit AES key as a session key to
encrypt an object being transferred from one SafeNet module to another. Objects transferred using the
cloning protocol may be keys, user data, or module data. The AES session encrypting key is obtained by
combining the 48 byte cloning domain value (randomly generated by the module) with random one-
time data generated by source and target modules and exchanged using RSA 4096-based transport.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 33 of 55
Key Mask/Unmask
Key masking is a SafeNet product feature that uses a 256-bit AES key, which is unique to the module, to
encrypt a key object for output in a way that ensures the key can only be imported, by unmasking, into
the module from which it originally came or one that has been initialized to contain the same “master”
key for the module. The key mask operation takes a key handle as input and uses the module’s
validated AES implementation to create the masked key output.
The key unmask operation takes a masked (encrypted) key object as input, performs the necessary
decryptions inside the module and returns a handle to the imported key.
Note that for both mask and unmask operations, the user (or calling application acting on the user’s
behalf) never has access to the actual key values – only handles assigned to the key objects in the
module.
Key Wrap/Unwrap
The key wrap operation encrypts a key value for output, using either an RSA public key (only if wrapping
a symmetric key) or a symmetric key (KTS) to wrap either another symmetric key or an asymmetric
private key.
The unwrap operation takes as input an encrypted key value and a handle to the key that was originally
used to do the wrapping. It decrypts the key value, stores it in the module as a key object, and returns
the handle to the imported key.
Note that for both wrap and unwrap operations, the user (or calling application acting on the user’s
behalf) never has access to the actual key values – only handles assigned to the key objects in the
module.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 34 of 55
3.7 Cryptographic Operations
Because of its generic nature, the module’s cryptographic co-processor and firmware support a wide
range of cryptographic algorithms and mechanisms. The approved cryptographic functions and
algorithms that are relevant to the FIPS 140-2 validation are the following:
1. Symmetric encryption/decryption: Triple-DES 168 bits (SP 800-67).
2. Symmetric encryption/decryption: AES 128, 192, 256 bits (FIPS PUB 197).
3. Signature generation (FIPS PUB 186-4): RSA 2048-3072 bits (PKCS #1 V1.5) with SHA-1, SHA-
224, SHA-256, SHA-384, SHA-512, RSA 2048-3072 bits (PSS) with SHA-1, SHA-224, SHA-256,
SHA-384, SHA-512, RSA 2048-3072 bits (ANSI X9.31) with SHA-1, SHA-224, SHA-256, SHA-
384 and SHA-512; DSA 2048-3072 bits with SHA-224, SHA-256, SHA-384 and SHA-512;
ECDSA with SHA-224, SHA-256, SHA-384, SHA-512.
4. Signature verification (FIPS PUB 186-4): RSA 1024-3072 bits (PKCS #1 V1.5) with SHA-1, SHA-
224, SHA-256, SHA-384, SHA-512, RSA 1024-3072 bits (PSS) with SHA-1, SHA-224, SHA-256,
SHA-384, SHA-512, RSA 1024-3072 bits (ANSI X9.31) with SHA-1, SHA-224, SHA-256, SHA-
384 and SHA-512; DSA 1024-3072 bits with SHA-1, SHA-224, SHA-256, SHA-384 and SHA-
512; ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512.
5. Signature generation (FIPS PUB 186-2): RSA 4096 bits with SHA-224, SHA-256, SHA-384 and
SHA-512.
6. Signature verification (FIPS PUB 186-2): RSA 1024-4096 bits with SHA-1, SHA-224, SHA-256,
SHA-384, SHA-512.
7. Hash generation SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (FIPS PUB 180-4).
8. Keyed hash generation HMAC using SHA-120, SHA-224, SHA-256, SHA-384, SHA-512
(FIPS PUB 198-1).
9. Message authentication Triple-DES MAC (FIPS PUB 113) and CMAC (NIST SP 800-38B).
10. Deterministic Random Bit Generation (DRBG) (NIST SP 800-90A section 10.2.1)
Table 3-4. Approved Security Functions for SafeXcel 3120
20 Only keys of 112 bits or greater are allowed in FIPS mode when using HMAC-SHA-1.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 35 of 55
Approved Security Functions Certificate No.
Symmetric Encryption/Decryption
AES: (ECB, CBC, GCM21); Encrypt/Decrypt; Key Size = 128, 192, 256) #4849
Triple-DES: (ECB, CBC); Encrypt/Decrypt KO 1) #2552
Hashing
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Byte Only) #3988
Message Authentication Code
HMAC-SHA-122, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 #3306
Triple-DES MAC (based on Certificate No. #2552) Vendor Affirmed
Asymmetric
RSA:
FIPS186-2: Signature Generation, Signature Verification
FIPS186-4: Key Generation, Signature Generation, Signature Verification
#2691
DSA:
FIPS186-4: PQG Generation, Key Generation, Signature Generation, Signature Verification
#1298
ECDSA:
FIPS186-4: Key Generation, Signature Generation, Signature Verification
#1242
Random Number Generation
NIST SP 800-90A DRBG (CTR) AES-256 #1704
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, GCM21
); Encrypt/Decrypt; Key Size = 128, 192, 256) #4960
Triple-DES: (ECB, CBC, CFB8); Encrypt/Decrypt KO 1) #2573
21
The module generates IVs internally using the Approved DRBG which are at least 96-bits in length.
22 Only keys of 112 bits or greater are allowed in FIPS mode when using HMAC-SHA-1.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 36 of 55
Approved and Allowed Security Functions Certificate No.
Message Authentication Code
Triple-DES MAC (based on Certificate No. #2573) Vendor Affirmed
Asymmetric
DSA:
FIPS186-4: Key Generation, Signature Generation, Signature Verification
#1317
ECDSA:
FIPS186-4: Key Generation, Signature Generation, Signature Verification
#1281
Table 3-6. Approved Security Functions for Firmware Implementation
Approved Security Functions Certificate No.
Symmetric Encryption/Decryption
AES: (ECB, CBC, OFB, CFB8, CFB128, CTR, GCM21, KW) #5021
Triple-DES: (ECB, CBC, OFB, CFB8, CFB64, CTR) #2588
Hashing
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (Byte Only) #4080
Message Authentication Code
HMAC-SHA-123
, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 #3335
Triple-DES MAC (based on Certificate No. #2588) Vendor Affirmed
Triple-DES CMAC #2588
AES CMAC (Key Sizes Tested: 128 192 256) #5021
Asymmetric
RSA:
FIPS186-2: Signature Verification
FIPS186-4: Key Generation, Signature Generation, Signature Verification
#2706
DSA:
FIPS186-4: PQG Generation, Key Generation, Signature Generation, Signature Verification
#1316
23 Only keys of 112 bits or greater are allowed in FIPS mode when using HMAC-SHA-1.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 37 of 55
Approved Security Functions Certificate No.
ECDSA:
FIPS186-4: Key Generation, Signature Generation, Signature Verification
#1280
CVL:
FIPS186-4: Signature Generation Component
#1565
Key Agreement Scheme
ECC:
Ephemeral Unified ( KARole(s): Initiator / Responder )
OnePassDH ( KARole(s): Initiator / Responder )
#155
Key Derivation
NIST SP 800-108 (Counter Mode) #165
Key Transport
KTS (AES Cert. #5021; key establishment methodology provides between 128 and 256 bits of encryption
strength)
#5021
Table 3-7. Allowed Security Functions for Firmware Implementation
Allowed Security Functions
Key Agreement
Diffie-Hellman (key agreement; key establishment methodology provides 112 or 128 bits of encryption strength)
EC Diffie-Hellman (key agreement; key establishment methodology provides between 112 and 256 bits of encryption strength)
Key Transport
RSA (key wrapping; key establishment methodology provides between 112 and 152 bits of encryption strength)
AES (key unwrapping; key establishment methodology provides between 128 and 256 bits of encryption strength)
Triple-DES (key unwrapping; key establishment methodology provides 112 bits of encryption strength)
Entropy Source
Hardware Random Number Generator (free-running local oscillators)
Non-FIPS Approved security functions are not available for use when the module has been configured to
operate in FIPS-approved mode, see Section 3.2.
Table 3-8. Non-FIPS Approved Security Functions
Non-FIPS Approved Security Functions
Symmetric Encryption/Decryption
DES
Triple-DES (2-Key)
RC2
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 38 of 55
RC4
RC5
CAST5
SEED
ARIA
Hashing
MD2
MD5
HAS-160
Message Authentication Code
AES MAC (non-compliant)
DES-MAC
RC2-MAC
RC5-MAC
CAST5-MAC
SSL3-MD5-MAC24
SSL3-SHA1-MAC25
HMAC (Certs. #3306 and #3335 – non-compliant less than 112 bits of encryption strength)
Asymmetric
KCDSA
RSA X-509
RSA (Cert. #2691 and #2706 – non compliant less than 112 bits of encryption strength)
DSA (Certs. #1298, #1316 and #1317 – non-compliant less than 112 bits of encryption strength)
ECDSA (Certs. #1242, #1280 and #1281 – non-compliant less than 112 bits of encryption strength)
Generate Key
DES
RC2
RC4
RC5
CAST5
SEED
ARIA
GENERIC-SECRET
SSL PRE-MASTER26
Key Agreement
ECC (non-compliant less than 112 bits of encryption strength)
Diffie-Hellman (key agreement; key establishment methodology; non-compliant less than 112 bits)
24 Used by the TLS protocol. TLS has not been reviewed or tested by the CAVP or the CMVP.
25
Used by the TLS protocol. TLS has not been reviewed or tested by the CAVP or the CMVP.
26 Used by the TLS protocol. TLS has not been reviewed or tested by the CAVP or the CMVP.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 39 of 55
Key Transport
RSA (key wrapping; key establishment methodology; non-compliant less than 112 bits of encryption strength)
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. The
module also performs conditional self-tests in accordance with FIPS 140-2, section 4.9.2.
Table 3-9. Module Self-Tests
Test When Performed Where Performed Indicator
Boot loader performs a SHA-1 integrity check of the
firmware prior to firmware start
Power-on Firmware Module halt27
ECDSA integrity check of the binary running on the
hardware.
Power-on Hardware Module halt
DRBG Instantiate Function Known Answer Test (KAT) Power-on Hardware Module halt
DRBG Generate Function KAT Power-on Hardware Module halt
DRBG Reseed Function KAT Power-on Hardware Module halt
DRBG Uninstantiate Function KAT Power-on Hardware Module halt
Triple-DES KATs (e / d) Power-on/Request Firmware / Hardware Module halt / Error - Halt28
SHA-1 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
SHA-224 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
SHA-256 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
SHA-384 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
SHA-512 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
HMAC SHA-1 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
HMAC SHA-224 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
HMAC SHA-256 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
HMAC SHA-384 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
HMAC SHA-512 KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
RSA sig-gen KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
RSA sig-ver KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
DSA sig-gen KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
DSA sig-ver KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
Diffie-Hellman KAT Power-on/Request Firmware Module halt / Error - Halt
AES KATs (e /d) Power-on/Request Firmware / Hardware Module halt / Error - Halt
AES-GCM KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
27
Details of the failure can be obtained from the dual-port following a module halt.
28 An error message is output, the Hardware Security Module halts, and data output is inhibited.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 40 of 55
Test When Performed Where Performed Indicator
ECDH KAT Power-on/Request Firmware Module halt / Error - Halt
ECDSA sig-gen KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
ECDSA sig-ver KAT Power-on/Request Firmware / Hardware Module halt / Error - Halt
KDF KAT Power-on/Request Firmware Module halt / Error - Halt
DRBG conditional tests Continuous Firmware / Hardware Error - Halt
HRNG conditional tests Continuous Firmware / Hardware Error - Halt
RSA – Pair-wise consistency test (asymmetric key pairs) On generation Firmware / Hardware Error
DSA – Pair-wise consistency test (asymmetric key pairs) On generation Firmware / Hardware Error
ECDSA – Pair-wise consistency test (asymmetric key
pairs)
On generation Firmware / Hardware Error
Firmware load test (4096-bit RSA sig ver) On firmware update
load
Firmware 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.
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 software29
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 SafeNet Hardware Security Module is a multi-chip embedded module as defined by FIPS PUB 140-2
section 4.5. The module is enclosed in a strong metal enclosure that provides tamper-evidence. Any
tampering that might compromise a module’s security is detectable by visual inspection of the physical
integrity of a module. The Security Officer should perform a visual inspection of the module at regular
29 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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 41 of 55
intervals. If physical tamper is discovered, the Security Officer should remove the module from service
and follow corporate security guidelines. Within the metal enclosure, a hard opaque epoxy covers the
circuitry of the cryptographic module. Attempts to remove this epoxy will cause sufficient damage to
the cryptographic module so that it is rendered inoperable.
The module’s enclosure is opaque to resist visual inspection of the device design, physical probing of the
device and attempts to access sensitive data on individual components of the device.
The plaintext Critical Security Parameters (CSPs) stored inside the module are the Master Tamper Key
(MTK), the Key Encryption Key (KEK) and the Token/Module Variable Key (TVK), which is used to
implement the auto-activation feature. The MTK, KEK and TVK are stored in battery-backed RAM. The
MTK and TVK are erased in the event of a tamper detection – either from the external tamper signal or
removal of the card from the PCI-Express slot. The KEK is erased when a decommission signal is
received.
The module is designed to operate between 0° and 65° Celsius, and to sense and respond to out-of-
range temperature conditions. The module also senses and responds to out-of-range voltage
conditions. In the event that the module senses an out-of-range temperature or voltage, it will clear all
working memory and halt operations. It can be reset and placed back into operation when proper
operating conditions have been restored.
The epoxy hardness was tested at room temperature and at the high and low temperatures which
would cause the active tamper (0° to 65° Celsius).
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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 42 of 55
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 state30
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 signal31
.
By responding to the signal a module can ensure that no sensitive data remain even if a determined
attack defeats the external physical security protection measures. There are two sources for a potential
tamper signal. The first is circuitry to detect the removal of a module from a PCI-Express slot. By
responding to this external signal, the module ensures that all plaintext sensitive data are cleared if a
module is removed from its slot. The second source is used only in the instance of an appliance
installation. In that case, the signal would come from tamper detection circuitry that detects opening of
the appliance cover. By responding to this external signal, the module ensures that all plaintext
sensitive data are cleared if the appliance cover is opened.
30 A secure state is one in which either a SafeNet 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
SafeNet Hardware Security Module.
31 This is external to the cryptographic boundary.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 43 of 55
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
Admin User Identity-based Level 3 – Authentication token (PED Key – one per module)
plus optional PED PIN
Audit Officer Identity-based Level 3 – Authentication token (PED Key – one per module)
plus optional PED PIN
Partition Security Officer Identity-based Level 3 – Authentication token (PED Key – one per partition
with a PSO) plus optional PED PIN
Crypto Officer Identity-based32
Level 3 – Authentication token (PED Key – one per user) plus
optional PED PIN, plus optional Challenge Secret for the role33
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 1 to 3 for SO and
configurable from 1 to 10 (default 10) for partition SOs and 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 1 to 3for SO and configurable from 1 to 10 (default 10) for
partition SOs and users, this ensures the FIPS 140-2 required
thresholds can never be reached.
32 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.
33 If activation or auto-activation is enabled, challenge secret is required in FIPS mode.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 44 of 55
All services listed in Table A-3 can be accessed in FIPS and non-FIPS mode. The services listed in Table
A-3 use the security functions listed in Table 3-4, Table 3-5, Table 3-6, and Table 3-7. When the module
is operating in FIPS-approved mode as described in Section 3.2, the Non-FIPS Approved Security
Functions in Table 3-7 are disabled and cannot be used for these services. The non-Approved functions
in Table 3-7 can only be accessed through the services when the module is in non-FIPS Approved mode.
Table A-3. Services Authorized for Roles
Role Authorized Services
Security Officer Show Status, Self-test, Initialize Module, Configure Module Policy, Create Partition, Initialize Partition,
Configure Partition Policy, Initialize Role, Reset Role Authentication Data, Change Role Authentication
Data,, Zeroize Module, Zeroize Partition, Delete Partition, Firmware Update, Configuration Update,
Generate Random Data, Key Generation, Key Pair Generation, Symmetric Key Wrap/Unwrap, Asymmetric
Key Unwrap, Symmetric Key Mask/Unmask, Symmetric Encrypt/Decrypt, Asymmetric
Signature/Verification, Store Data Object, Read Data Object, Partition Backup and Restore
Admin User Show Status, Self-test, Change Role Authentication Data, Zeroize Module, Zeroize Partition, Generate
Random Data, , Key Pair Generation, Symmetric Encrypt/Decrypt, Asymmetric Signature/Verification,
Symmetric Key Wrap/Unwrap, Asymmetric Key Wrap/Unwrap, Symmetric & Asymmetric Key
Mask/Unmask, Store Data Object, Read Data Object
Audit Officer Show Status, Self-test, Change Role Authentication Data, Zeroize Module, Zeroize Partition, Generate
Random Data, Initialize and Configure Secure Audit Logging, Change Audit Officer’s Password, Verify Secure
Audit Log Files, Import and Export Secure Audit Log Files, Synchronize Module Clock with the Clock of the
Host System, Import and Export the Wrapped Secure Audit Logging Key, Show Secure Audit Log Status
Partition Security Officer Show Status, Self-test, Initialize Partition, Configure Partition Policy, Initialize Role, Reset Role
Authentication Data, Change Role Authentication Data, Zeroize Module, Zzeroize Partition, Generate
Random Data
Crypto Officer Show Status, Self-test, Initialize Role, Reset Role Authentication Data, Change Role Authentication Data,
Zeroize Module, Zeroize Partition, Generate Random Data, Key Generation, Key Pair Generation,
Symmetric Encrypt/Decrypt, Asymmetric Signature/Verification, Symmetric Key Wrap/Unwrap, 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, Change Role Authentication Data, Zeroize Module, Zeroize Partition, Generate
Random Data, Symmetric Encrypt/Decrypt, Asymmetric Signature/Verification, Store Data Object, Read
Data Object
Public User Show Status, Self-test, Zeroize Module, Zeroize Partition, Store Public Data Object, Read Public Data Object
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 45 of 55
Table A-4. Access Rights within Services
Service Cryptographic Keys and CSPs Role Type(s) of Access
Show Status34
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 Use35
Create Partition Authentication data via trusted path SO Write – User authentication
data
Initialize Partition Authentication data via trusted path SO, PSO Write – PSO authentication
data
Configure Partition Policy Authentication data via trusted path SO, PSO Use
Initialize Role Authentication data via trusted path SO, PSO, Crypto Officer Write – User/PSO
authentication data
Reset Role Authentication Data Authentication data via trusted path SO, PSO, Crypto Officer Write – User/PSO
authentication data
Change Role Authentication Data Authentication data via trusted path SO, PSO, Crypto
Officer, Crypto User,
Audit Officer, Admin
User
Use, Write – User/PSO
authentication data
Zeroize Module N/A All Erase
Zeroize Partition N/A All Erase
Delete Partition Authentication data via trusted path SO Erase
Firmware Update MVK36
SO Use, Write (firmware only)
Configuration Update Authentication data via trusted path SO Use, Erase
Generate Random data N/A SO, PSO, Crypto
Officer, Crypto User,
Audit Officer, Admin
User
Use
34 Show status is provided by invoking the “hsm show” command from the administrative interface. It will display identifying
information about the module such as label, serial number, firmware version, etc. The “hsm capability list” command indicates
whether the module is in FIPS-approved mode.
35
Use means access to key material for use in performing a cryptographic operation. The key material is never visible.
36 Public key value. See Table A-5 for its description.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 46 of 55
Service Cryptographic Keys and CSPs Role Type(s) of Access
Key Generation Symmetric keys SO, Crypto Officer,
Admin User
Write
Key Pair Generation Asymmetric key pairs SO, Crypto Officer,
Admin User
Write
Symmetric Key Wrap / Unwrap Symmetric with RSA
Symmetric with Symmetric Key Wrap mode37
SO, Crypto Officer,
Admin User
Use, Write
Asymmetric Key Wrap / Unwrap Asymmetric with Symmetric Key Wrap mode38
SO, Crypto Officer,
Admin User
Use, Write
Symmetric Key Mask / Unmask Symmetric with AES 256 SO, Crypto Officer,
Admin User
Use, Write
Asymmetric Key Mask / Unmask Symmetric with AES 256 SO, Crypto Officer,
Admin User
Use, Write
Partition Backup / Restore Symmetric keys, asymmetric key pairs SO, Crypto Officer Transfer39
Symmetric Encrypt / Decrypt Symmetric keys SO, Crypto Officer,
Crypto User, Admin
User
Use
Asymmetric Signature RSA, DSA private keys SO, Crypto Officer,
Crypto User, Admin
User
Use
Asymmetric Verification RSA, DSA public keys SO, Crypto Officer,
Crypto User, Admin
User
Use
Store Data Object Non-cryptographic data SO, Crypto Officer,
Crypto User,
Public User40
, Admin
User
Write
Read Data Object Non-cryptographic data SO, Crypto Officer,
Crypto User,
Public User41
, Admin
User
Read
Initialize Secure Audit Logging Symmetric keys Audit Officer Write
37
That is, the keys used during Symmetric Key Wrap/ Unwrap operations are a symmetric key wrapping key and the
(symmetric or asymmetric) key which is being wrapped.
38
That is, the keys used during Asymmetric Key Wrap / Unwrap operations are an asymmetric key wrapping key and the
symmetric key which is being wrapped.
39 Transfer means moving a key using the cloning protocol from one Hardware Security Module to another.
40
The Public User has access to Public Data Objects only.
41 The Public User has access to Public Data Objects only.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 47 of 55
Service Cryptographic Keys and CSPs Role Type(s) of Access
Change Audit Officer’s Password Authentication Data via trusted path Audit Officer Read, Write
Configure Secure Audit Logging N/A Audit Officer Read, Write
Synchronize Module’s clock with
the Host system’s clock
N/A Audit Officer Write
Verify, Import, and Export secure
audit log files
N/A Audit Officer Read
Show secure audit log status N/A Audit Officer Read
Import and Export the Wrapped
Secure Audit Logging Key
Symmetric keys Audit Officer Write, Read
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 48 of 55
Table A-5. Keys and Critical Security Parameters
Keys and CSPs CSP Type Generation Input / Output Storage Destruction Description
Challenge Secret 16 character data string AES-CTR DRBG
Output via direct
connection to PED
Flash memory
encrypted with PSK
N/A
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.
Random Challenge One-time random number AES-CTR DRBG
Output to host using ICD
communication path
Working RAM in
plaintext
Power Cycle
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.
Challenge Response 20-byte value N/A
Input from host using ICD
communication path
Working RAM in
plaintext
Power Cycle
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.
PED42
Key (or iKey)
Authentication Data
48-byte random value AES-CTR DRBG
Input / Output via direct
connection to PED
Flash memory
encrypted
N/A
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) via the Trusted
Path.
Optional PIN PIN N/A
Input on the PED via
secure channel. PED
does not input or output
the PIN.
Not stored On module N/A
An optional PIN value used for
authentication along with the PED key. It
must be a minimum of 4-bytes long
42 Within this document the terms “PED” key and “iKey” are interchangeable unless otherwise indicated.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 49 of 55
Keys and CSPs CSP Type Generation Input / Output Storage Destruction Description
Cloning Domain Vector 48-Byte value AES-CTR DRBG
Output via direct
connection to PED
Flash Memory
encrypted with PSK
N/A
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. The value is
output from the original module in the
domain onto a PED key to enable initializing
additional modules into the same domain.
User Storage Key (USK) AES-256 AES-CTR DRBG Not Input or Output
Flash memory
encrypted
N/A
This key is used to encrypt all sensitive
attributes of all private objects owned by the
user. Encrypted, as part of the partition
data, by the key taken from the PED key
data.
Partition Storage Key (PSK) AES-256 AES-CTR-DRBG Not Input or Output
Flash memory
encrypted
N/A
The storage key for the SO/user partition.
This key is used to encrypt the key data for
the SO/user partitions. Encrypted as part of
the SO/user partition data by the SO/user
storage key (USK).
Global Storage Key (GSK) AES-256 AES-CTR DRBG Not Input or Output
Flash memory
encrypted
N/A
32-byte AES key that is the same for all users
on a specific SafeNet 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 partition data, by the SO/User
partition storage key (PSK).
Token or Module
Unwrapping Key (TUK)
RSA-2048 bit private key ANSI X9.31 Not Input or Output
Flash memory
encrypted with GSK
N/A
A 2048-bit RSA private key used in the
cloning protocol.
Token or Module
Wrapping Certificate
(TWC)
RSA-2048 public/private
certificate
Loaded at
Manufacturing
Public Key Output in
Plaintext
Flash memory
plaintext
N/A
Used in exchange of session encryption key
as part of the handshake during the cloning
protocol.
U2 Key 3-Key Triple-DES AES-CTR DRBG Not Input or Output
Flash memory
encrypted with GSK
N/A
24-byte Triple-DES 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.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 50 of 55
Keys and CSPs CSP Type Generation Input / Output Storage Destruction Description
Token or Module Variable
Key (TVK)
AES-256 AES-CTR DRBG Not Input or Output
Tamperable BBRAM in
plaintext
Zeroized as part of a
tamper event
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) AES-256 AES-CTR DRBG Not Input or Output
Tamperable BBRAM in
plaintext
Zeroized as part of a
tamper event
The MTK encrypts all sensitive values
Key Encryption Key (KEK) AES-256 AES-CTR DRBG Output Encrypted
Tamperable BBRAM in
plaintext
Zeroized as part of a
decommission signal
The KEK encrypts all sensitive values and is
zeroized in response to a decommission
signal.
Masking Key AES-256 AES-CTR DRBG Not Input or Output
Flash memory
encrypted with PSK
N/A
AES 256-bit key used during masking
operations. Stored encrypted using the PSK.
Manufacturer’s Integrity
Certificate (MIC)
RSA-4096 public key
certificate
Loaded at
manufacturing
Not Input or Output
Flash memory in
plaintext
N/A
Used in verifying Hardware Origin
Certificates (HOCs), which are generated in
response to a customer function call to
provide proof of hardware origin.
Manufacturer’s
Verification Key (MVK)
RSA-1024 public key
Loaded at
manufacturing
Not Input or Output
Flash memory in
plaintext
N/A
1024-bit public key counterpart to the
Manufacturer’s Signature Key (MSK) held at
SafeNet. Used for key migration support for
legacy HSMs.
Device Authentication Key
(DAK)
RSA 2048 bit private key ANSI X9.31 Not Input or Output
Flash memory
encrypted with GSK
N/A
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.
Device Authentication
Certificate (DAC)
RSA 2048 public key
certificate
Loaded at
manufacturing
Certificate Output in
Plaintext
Working RAM in
plaintext
N/A
The X.509 public key certificate
corresponding to the DAK. It is signed by the
HOK. Used for a specific PKI implementation
requiring assurance that a key or a specific
action originated within the hardware crypto
module.
Hardware Origin Key (HOK) RSA 4096 bit private key ANSI X9.31 Not Input or Output
Flash memory
encrypted with GSK
N/A
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.
Hardware Origin
Certificate (HOC)
RSA-4096 public key
certificate
Loaded at
manufacturing
Not Input or Output
Flash memory in
plaintext
N/A
The X.509 public key certificate
corresponding to the HOK. It is signed by
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 51 of 55
Keys and CSPs CSP Type Generation Input / Output Storage Destruction Description
the Manufacturer’s Integrity Key (MIK) at the
time the device is manufactured.
ECC Manufacturing
Integrity Certificate
(ECC MIC)
ECC P-384 public
certificate
Loaded at
manufacturing
Certificate Output in
Plaintext
Flash memory
plaintext
N/A
The X.509 public key certificate
corresponding to the ECC Manufacturing
Integrity Key (ECC MIK). It is self-signed.
ECC Hardware Origin Key
(ECC HOK)
ECC P-384 private key FIPS 186-4 Not Input or Output
Flash memory
encrypted with GSK
N/A
ECC P-384 private key used to sign other
device keys and used for a specific PKI
implementation requiring assurance that a
key or a specific action originated within the
hardware crypto module.
ECC Hardware Origin
Certificate (ECC HOC)
ECC P-384 public
certificate
FIPS 186-4
Certificate Output in
Plaintext
Flash memory
plaintext
N/A
The X.509 public key certificate
corresponding to the ECC HOK. It is signed by
the ECC Manufacturing Integrity Key (ECC
MIK). It is used for a specific PKI
implementation requiring assurance that a
key or a specific action originated within the
hardware crypto module.
ECC Device Authentication
Key (ECC DAK)
ECC P-384 private key FIPS 186-4 Not Input or Output
Flash memory
encrypted with GSK
N/A ECC P-384 private key.
ECC Device Authentication
certificate (ECC DAC)
ECC P-384 public
certificate
Loaded at
manufacturing
Certificate Output in
Plaintext
Flash memory
plaintext
N/A
The X.509public key certificate
corresponding to the ECC DAK. It is signed by
the ECC HOK.
Remote PED Vector (RPV) 256-bit secret value AES-CTR DRBG
Input / Output via direct
connection to PED
Flash memory in
plaintext
Zeroized via ICD
command
A randomly generated 256-bit secret, which
must be shared between a remote PED and
a cryptographic module in order to establish
a secure communication channel between
them.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 52 of 55
Keys and CSPs CSP Type Generation Input / Output Storage Destruction Description
Secure Recovery Vector
(SRV)
Split of AES-256 MTK AES-CTR DRBG Split output in plaintext
Flash memory
encrypted with GSK
N/A
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 AES-256
Hardware Random
Source
Not Input or Output
Tamperable BBRAM in
plaintext
Zeroized as part of a
tamper event
32 bytes AES key stored in the BBRAM of the
internal security co-processor. Used in the
implementation of the NIST SP 800-90A CTR
(AES) DRBG.
DRBG Seed 384 bits
Hardware Random
Source
Not Input or Output
Tamperable BBRAM in
plaintext
Zeroized as part of a
tamper event
Random seed data drawn from the
Hardware RBG in the security co-processor
and used to seed the implementation of the
NIST SP 800-90A CTR (AES) DRBG.
DRBG V 128 bits
H/W Random
Source
Not Input or Output
Tamperable BBRAM in
plaintext
Zeroized as part of a
tamper event
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 NIST SP 800-90A.
DRBG Entropy Input 384 bits
H/W Random
Source
Not Input or Output
Tamperable BBRAM in
plaintext
Zeroized as part of a
tamper event
The entropy value used to initialize the
approved DRBG. The 48-byte value is stored
ephemerally in memory of the security co-
processor.
Secure Audit Logging Key
(SALK)
256 bit HMAC AES-CTR DRBG Input / Output encrypted
Flash memory in
plaintext and
encrypted with SADK
N/A
A 256-bit key used to verify data integrity
and authentication of the log messages.
Saved in the parameter area of Flash
memory.
Secure Audit Domain Key
(SADK)
AES-256 KW AES-CTR DRBG Input / Output encrypted
Flash Memory
encrypted with USK
N/A
A 256-bit key that is used to wrap/unwrap
the SALK when it is exported / imported
from / to the module.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 53 of 55
Keys and CSPs CSP Type Generation Input / Output Storage Destruction Description
Partition STC Private Key 2048-bit private key AES-CTR DRBG Not Input or Output Flash memory
encrypted with GSK
Zeroized via ICD
command
A 2048-bit RSA private key used in the STC
protocol.
Partition STC Public Key 2048-bit public key AES-CTR DRBG Output in Plaintext Flash memory in
plaintext
Zeroized via ICD
command
A 2048-bit RSA public key used in the STC
protocol.
Partition STC Client/Host
Public Keys
2048-bit public key N/A Public Key Input in
Plaintext
Flash memory in
plaintext
Zeroized via ICD
command
A 2048-bit RSA public key used in the STC
protocol.
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 54 of 55
APPENDIX B. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS
Term Definition
ANSI American National Standards Institute
CA Certification Authority
CKE Key Export with RA
CL Cloning (a capability configuration used to allow the secure transfer of key
objects from one module to another for backup and restore and object
replication purposes).
CLI Command Line Interface
CO Crypto Officer
CRC Cyclic Redundancy Check
CRT Chinese Remainder Theorem
CSP Critical Security Parameter
CU Crypto User
DAK Device Authentication Key
DH Diffie Hellman
DRBG Deterministic Random Bit Generator
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie Hellman
FIPS Federal Information Processing Standard
GSK Global Storage Key
HA High Assurance
HOC Hardware Origin Certificate
HOK Hardware Origin Key
HRNG Hardware Random Number Generator
HSM Hardware Security Module
KAT Known Answer Test
KDF Key Derivation Function
KEK Key Encryption Key
MAC Message Authentication Code
Masking A SafeNet term to describe the encryption of a key for use only within a
SafeNet Hardware Security Module.
MIC Manufacturer’s Integrity Certificate
MIK Manufacturer’s Integrity Key
002-010961-001
Revision Level: F
www.gemalto.com Document is Uncontrolled When Printed. Page 55 of 55
Term Definition
MSK Manufacturer’s Signature Key
MTK Master Tamper Key
MVK Manufacturers Verification Key
PCI Peripheral Component Interconnect
PED PIN Entry Device
PIN Personal Identification Number
PKCS Public-Key Cryptography Standards
PRNG Pseudo-Random Number Generator
PSK Partition Storage Key
PSO Partition Security Officer
PSS Probabilistic Signature Scheme
RA Registration Authority
RNG Random Number Generator
RPED Remote PED
RPK Remote PED Key
RPV Remote PED Vector
SA Server-Attached
SADK Security Audit Domain Key
SALK Security Audit Logging Key
SCU Secure Capability Update
SGSK Secondary Global Storage Key
SFF Small Form Factor
SHS Secure Hash Standard
SMK Security Officer’s Master Key
SNC Signing No Cloning
SO Security Officer
SRK Secure Recovery Key
STC Secure Trusted Channel
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