SafeNet Luna SA User manual

Luna SA
Configuration Guide

Document Information
Product Version 5.4.1
Document Part Number 007-011136-007
Release Date 04 July 2014
Revision History
Revision Date Reason
A 26 February 2014 Initial release.
B 17 April 2014 Updates to the SFF Backup feature.
C 04 July 2014 Solaris client support.
Trademarks
All intellectual property is protected by copyright. All trademarks and product names used or referred to are the
copyright of their respective owners. No part of this document may be reproduced, stored in a retrieval system or
transmitted in any form or by any means, electronic, mechanical, chemical, photocopy, recording or otherwise without
the prior written permission of SafeNet, Inc.
Disclaimer
SafeNet makes no representations or warranties with respect to the contents of this document and specifically
disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, SafeNet
reserves the right to revise this publication and to make changes from time to time in the content hereof without the
obligation upon SafeNet to notify any person or organization of any such revisions or changes.
We have attempted to make these documents complete, accurate, and useful, but we cannot guarantee them to be
perfect. When we discover errors or omissions, or they are brought to our attention, we endeavor to correct them in
succeeding releases of the product.
SafeNet invites constructive comments on the contents of this document. Send your comments, together with your
personal and/or company details to the address below.
Contact Method Contact Information
Mail SafeNet, Inc.
4690 Millennium Drive
Belcamp, Maryland 21017
USA
Email [e-mail]
Luna SA Configuration Guide
Rellease 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 2

CONTENTS
PREFACE About the Configuration Guide 6
Customer release notes 6
Audience 6
Document conventions 7
Notes 7
Cautions 7
Warnings 7
Command syntax and typeface conventions 7
Support Contacts 8
CHAPTER 1 Planning Your Configuration 10
Roles 10
Named Administrative Users and Their Assigned Roles 10
Implications of Backup and Restore of User Profiles 11
Security of Shell User Accounts 12
Crypto Officer & Crypto User 12
How the Roles are Invoked 14
Bad Login Attempts 15
Domain Planning 15
Luna PED Planning 16
What each PED prompt means 16
HSM Initialization and the Blue SOPED Key 17
HSM Cloning Domain and the Red Domain PED Key 18
Partition Owner/User and the black PED Key 18
Remote PED Orange PED Key (RPK) 19
Auditor 19
Secure Recovery Purple PED Key (SRK) 20
Other Considerations 20
Luna PED Planning 20
What each PED prompt means 21
HSM Initialization and the Blue SOPED Key 22
HSM Cloning Domain and the Red Domain PED Key 23
Partition Owner/User and the black PED Key 23
Remote PED Orange PED Key (RPK) 24
Auditor 24
Secure Recovery Purple PED Key (SRK) 24
Other Considerations 25
CHAPTER 2 Configure the Luna Appliance for your Network 26
Gather appliance network setting information 26
Client Requirements 26
Recommended Network Characteristics 27
Power-up the HSM Appliance 27
Luna SA Configuration Guide
Release 5.4.1 007-011136-007Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 3

Open a Connection 30
First Login & Changing Password 31
Set System Date and Time 33
Configure IP and Network Parameters 35
Make Your Network Connection 37
Generate a New HSM Server Certificate 39
CHAPTER 3 HSM Initialization 42
Initializing a Password-Authenticated HSM 44
Initializing a Password Authenticated HSM 44
Initializing a PED-Authenticated HSM 46
Recover the SRK 46
Re-split[see 'resplit' ] the SRK 48
Other Uses of the SRK 48
Initializing a PED-Authenticated HSM 48
Preparing to Initialize a Luna SA HSM [PED-version] 49
Why Initialize? 50
Start a Serial Terminal or SSHsession 51
Initialize the HSM 51
Initialization - some additional options and description 62
CHAPTER 4 HSM Capabilities and Policies 67
Set HSM Policies (Password Authentication) 67
Set HSM Policies - PED (Trusted Path) Authentication 69
CHAPTER 5 Creating a Partition on the HSM 72
Prepare to Create a Partition (Password Authenticated) 72
About HSM Partitions on the Initialized HSM 72
Create the Partition [PW] 73
Partition creation audit log entry 74
Next steps 74
Prepare to Create a Partition (PED Authenticated) 75
About HSM Partitions on the Initialized HSM 75
Create (Initialize) the Partition - PED Authenticated 76
Partition creation audit log entry 84
Record the Partition Client Password (PED-Auth HSMs) 85
CHAPTER 6 Partition Policies 88
Set Partition Policy 89
Policy setting example, Luna HSM with Password Authentication 90
Policy setting example, Luna HSM with PED Authentication 90
CHAPTER 7 Prepare the Client for Network Trust Link 91
Preparing the Client 91
Import a Server Cert 92
Prepare a Network Trust Link - Windows 93
Import HSM Appliance Server Certificate onto Client (Windows) 93
Register the HSM Server Certificate with the Client (Windows) 95
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 4

Create a Client Certificate (Windows) 96
Export a Client Cert to an HSM Appliance (Windows) 99
Prepare a Network Trust Link - UNIX/Linux 102
Import HSM Appliance Server Certificate onto Client (UNIX) 102
Register the HSM Server Certificate with the Client (UNIX) 102
Register 103
Create a Client Certificate (UNIX) 103
Export a Client Cert to an HSM Appliance (UNIX) 104
Register the Client Certificate to an HSM Server 105
How Many Clients? 106
Register VM Clients 106
What's the Next Step? 106
CHAPTER 8 Assign a Client to an HSM Partition 107
Assign a Client to a Partition 107
Verify Your Setup 107
Client Connection Limits 108
Applications and Integrations 108
CHAPTER 9 Optional Configuration Tasks 109
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 5

PREFACE
About the Configuration Guide
This document provides step-by-step instructions for configuring your Luna HSM hardware, before you begin using it
with your application(s). The instructions are for a basic configuration. Additional configuration options are described in
"Optional Configuration Tasks" on page 109.
To ensure a trouble-free configuration, perform the following steps in the order indicated:
1. "Planning Your Configuration" on page 10
2. "Configure the Luna Appliance for your Network" on page 26
3. "HSM Initialization" on page 42
4. "HSM Capabilities and Policies" on page 67
5. "Creating a Partition on the HSM" on page 72
6. "Partition Policies" on page 88
7. "Prepare the Client for Network Trust Link" on page 91
8. "Assign a Client to an HSM Partition" on page 107
9. "Optional Configuration Tasks" on page 109
This preface also includes the following information about this document:
•"Customer release notes" on page 6
•"Audience" on page 6
•"Document conventions" on page 7
•"Support Contacts" on page 8
For information regarding the document status and revision history, see "Document Information" on page 2.
Customer release notes
The customer release notes (CRN) provide important information about this release that is not included in the customer
documentation. Read the CRN to fully understand the capabilities, limitations, and known issues for this release. You
can view or download the latest version of the CRN for this release at the following location:
•http://www.securedbysafenet.com/releasenotes/luna/crn_luna_hsm_5-4.pdf
Audience
This document is intended for personnel responsible for maintaining your organization's security infrastructure. This
includes Luna HSM users and security officers, key manager administrators, and network administrators.
All products manufactured and distributed by SafeNet, Inc. are designed to be installed, operated, and maintained by
personnel who have the knowledge, training, and qualifications required to safely perform the tasks assigned to them.
Luna SA Configuration Guide
Release 5.4.1 007-011136-007Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 6

PREFACE About the Configuration Guide
The information, processes, and procedures contained in this document are intended for use by trained and qualified
personnel only.
It is assumed that the users of this document are proficient with security concepts.
Document conventions
This document uses standard conventions for describing the user interface and for alerting you to important information.
Notes
Notes are used to alert you to important or helpful information. They use the following format:
Note: Take note. Contains important or helpful information.
Cautions
Cautions are used to alert you to important information that may help prevent unexpected results or data loss. They use
the following format:
CAUTION: Exercise caution. Contains important information that may help prevent
unexpected results or data loss.
Warnings
Warnings are used to alert you to the potential for catastrophic data loss or personal injury. They use the following
format:
WARNING! Be extremely careful and obey all safety and security measures. In this
situation you might do something that could result in catastrophic data loss or
personal injury.
Command syntax and typeface conventions
Format Convention
bold The bold attribute is used to indicate the following:
•Command-line commands and options (Type dir /p.)
•Button names (Click Save As.)
•Check box and radio button names (Select the Print Duplex check box.)
•Dialog box titles (On the Protect Document dialog box, click Yes.)
•Field names (User Name: Enter the name of the user.)
•Menu names (On the File menu, click Save.) (Click Menu > Go To > Folders.)
•User input (In the Date box, type April 1.)
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 7

PREFACE About the Configuration Guide
Format Convention
italics In type, the italic attribute is used for emphasis or to indicate a related document. (See the
Installation Guide for more information.)
<variable> In command descriptions, angle brackets represent variables. You must substitute a value for
command line arguments that are enclosed in angle brackets.
[optional]
[<optional>]
Represent optional keywords or <variables> in a command line description. Optionally enter the
keyword or <variable> that is enclosed in square brackets, if it is necessary or desirable to
complete the task.
{a|b|c}
{<a>|<b>|<c>}
Represent required alternate keywords or <variables> in a command line description. You must
choose one command line argument enclosed within the braces. Choices are separated by vertical
(OR) bars.
[a|b|c]
[<a>|<b>|<c>]
Represent optional alternate keywords or variables in a command line description. Choose one
command line argument enclosed within the braces, if desired. Choices are separated by vertical
(OR) bars.
Support Contacts
If you encounter a problem while installing, registering or operating this product, please ensure that you have read the
documentation. If you cannot resolve the issue, please contact your supplier or SafeNet support. SafeNet support
operates 24 hours a day, 7 days a week. Your level of access to this service is governed by the support plan
arrangements made between SafeNet and your organization. Please consult this support plan for further information
about your entitlements, including the hours when telephone support is available to you.
Contact method Contact
Address SafeNet, Inc.
4690 Millennium Drive
Belcamp, Maryland 21017
USA
Phone United States [phone], [phone]
Australia and New Zealand [phone]
China (86) 10 8851 9191
France 0825 341000
Germany 01803 7246269
India [phone]
United Kingdom 0870 7529200, [phone]
Web www.safenet-inc.com
Support and Downloads www.safenet-inc.com/support
Table 1: Technical support contacts
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 8

PREFACE About the Configuration Guide
Contact method Contact
Provides access to the SafeNet Knowledge Base and quick downloads for
various products.
Customer Technical Support
Portal
https://serviceportal.safenet-inc.com
Existing customers with a Customer Connection Center account, or a Service
Portal account, can log in to manage incidents, get the latest software upgrades,
and access the SafeNet Knowledge Base.
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 9

CHAPTER 1
Planning Your Configuration
Before initializing your HSM, we suggest taking a moment to consider the following available features and options.
Some would be inconvenient to change after your HSM is in service:
•"Roles" on page 10
•"Crypto Officer & Crypto User" on page 12
•"Domain Planning" on page 15
•"Luna PED Considerations" on page 1
•"Luna PED Planning" on page 20
Roles
Luna HSM products offer multiple identities, some mandatory, some optional, that you can invoke in different ways to
map to roles and functions in your organization. The following topics offer some aspects that you might wish to consider
before committing to an HSM configuration.
Named Administrative Users and Their Assigned Roles
By default, the appliance has
•one 'admin' user, with role "admin", always enabled, default password "PASSWORD"
•one 'operator' user, with role "operator", disabled until you enable, default password "PASSWORD"
•one 'monitor' user, with role "monitor", disabled until you enable, default password "PASSWORD"
Those three "built-in" accounts can be neither created nor destroyed, but 'admin' can enable or disable the other two as
needed.
You can leave that arrangement as-is, or you can create additional users with names of your own choice, and assign
them any of the roles (and the powers that go with those roles). The default password of any created user is
"PASSWORD" (yes, all uppercase).
Thus, you could choose to have:
•multiple admin-level users, each with a different name,
•multiple operator-level users (or none, if you prefer), again each with a different name, and
•multiple monitor-level users (or none, if you prefer), each with a different name.
Administrative users' names can be a single character or as many as 128 characters, chosen from letters a-z, or A-Z,
numbers 0-9, the dash, the dot, or the underscore. No spaces.
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._
As with any secure system, no two users (regardless of role) can have the same name.
Luna SA Configuration Guide
Release 5.4.1 007-011136-007Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 10

CHAPTER 1 Planning Your Configuration
Abilities or Privileges of Created Users
Named users empowered with the "admin" role can perform most actions that the original admin can perform.
User accounts granted the "operator" role have access to a reduced set of administrative commands.
User accounts granted the "monitor" role can take no actions on the appliance or HSM, and are restricted to commands
that view, list or show.
The commands available to the roles are listed in "User Accounts and Their Privileges".
Why Create Extra Administrative Users?
One reason for creating multiple named users would be for the purpose of distinguishing individual persons' activities in
the logs.
For example, a user named 'john' running the lunash 'syslog tail' command would show in the April 13 log as:
Apr 13 14:17:15 172 -lunash: Command: syslog tail : john : 172.20.10.133/3107
Command Result : 0 (Success)
Perhaps you have people performing similar functions at physically separate locations, or you might have staff
assigned to teams or shifts for 24-hour coverage. It could be valuable (or required by your security auditors) to know and
be able to show which specific person performed which actions on the system.
You might find other uses. Please let us know.
Implications of Backup and Restore of User Profiles
The commands "sysconf config backup" and "sysconf config restore" allow you to store a snapshot of the
administrative user database (the names and status of all named Luna Shell users) that can later be restored if desired.
CAUTION:
Restoring from backup restores the database of user profiles that existed before the backup
was made. This includes:
- the set of users that existed when the backup was made
- the passwords that users had at the time of the backup
- the enabled/disabled status of users, at the time of the backup.
This means that:
- you will lose any user accounts created since the backup,
- passwords of existing users could be reverted without their knowledge,
- enabled users might be disabled (therefor unable to perform their tasks)
- disabled users might be enabled (therefore re-granted access that was suspended) and
- any user accounts removed since that backup will be restored.
The first three could be administrative inconveniences. The fourth and fifth outcomes could be
serious security issues.
Your records should indicate when user-profile changes were made, and what those changes were, so any time that
you restore a backup, be sure to reconcile the changed statuses and inform anyone who is affected. For example, users
need to know to use their previous password, and to change it immediately.
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 11

CHAPTER 1 Planning Your Configuration
Note: While the "built-in" 'admin', 'operator', and 'monitor' accounts are not deleted or added by
a restore operation (those accounts are permanent), both their enabled/disabled status and their
passwords are changed to whatever prevailed at the time the backup was originally taken.
Security of Shell User Accounts
In most cases anticipated by the design and target markets for Luna SA, both the Luna SA appliance and any
computers that make network connections for administrative purposes, would reside inside your organization's secure
premises, behind well-maintained firewalls. Site-to-site connections would be undertaken via VPN. Therefore, attacks
on the shell account(s) would normally not be an issue.
However, if your application requires placing the Luna appliance in an exposed position (the DMZ and beyond), then
please see "About Connection Security" in the Overview document for some additional thoughts.
Crypto Officer & Crypto User
An available security layer is required in some security and authentication schemes, as follows:
For those who need the additional distinction, the Partition Owner role (black PED Key) can optionally be subdivided
into two further roles:
- Crypto Officer
- Crypto User
In the past, and continuing, the separation of roles on the Luna HSM follows the standard Cryptoki model:
• appliance admin
This is the basic administrative access to the a Luna HSM appliance. When you connect via ssh (putty.exe or other
ssh utility), the Luna HSM presents the "login as:" prompt. The only ID that is accepted is "admin".
You must be logged in as the appliance "admin" before you can access further authentication layers such as HSM
Admin, Partition Owner, Crypto Officer.
The appliance "admin" performs network administration and some other functions that do not require the additional
authentication. Therefore, by controlling access to passwords (for a Luna HSM with Password Authentication) or to
PED Keys (for a Luna HSM with Trusted Path Authentication), you can compartmentalize the various
administrative and security roles.
• HSM Admin
HSM Admin has control of the HSM within the a Luna HSM appliance. To access HSM Admin functions, you must
first be logged in as appliance admin.
In addition to all the other appliance functions, a user who has authenticated with the HSM Admin password (for a
Luna HSM with Password Authentication) or the HSM Admin (blue) PED Key (for a Luna HSM with Trusted Path
Authentication) can:
–create and delete Partitions,
–create and delete Partition Owners (black PED Key holders on a Luna HSM with Trusted Path Authentication
only),
–backup and restore the HSM,
–change HSM Policies, etc.
• HSM Partition Owner (or User)
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 12

CHAPTER 1 Planning Your Configuration
HSM Partition Owner has control of one or more Partitions (virtual HSMs) within the Luna HSM appliance. To
access HSM Partition Owner functions, you must first be logged in as appliance admin.
In addition to all the other appliance functions, a user who has authenticated with the HSM Partition Owner (black)
PED Key (for a Luna HSM with Trusted Path Authentication) can:
–modify partition policies
–activate a partition for use by Clients
–backup and restore Partition contents
Note: Both a Luna HSM with Password Authentication and a Luna HSM with Trusted Path
Authentication have at least two layers of access control for an HSM Partition:
- the appliance admin login
- the Partition authentication
Note: Luna HSM with PED (Trusted Path) Authentication, splits the Partition access into
two layers. The HSM Partition Owner (a concept that exists only for a Luna HSM with PED
Authentication) first authenticates to the Partition with the appropriate black PED Key, then
activates the Partition for Clients. Thereafter, each Client must further authenticate with the
Partition Password (generated by Luna PED when the Partition is created).
Note: For Luna HSM with Password Authentication, the Partition Password is the only
layer of authentication to a Partition. Therefore, any Client with that password has access to
the Partition. What prevents a Client from manipulating objects on the Partition and performing
Partition administration activities is the need to access the lunash command shell.
Note: Therefore, in both access-control models, a Client with the Password can connect and
perform object generation and deletion, and can use objects (sign, verify, encrypt, decrypt), but
they cannot perform Partition management operations unless they can also login to Luna Shell
(lunash) as admin.
• Client
A Client is a "working" or "production" user of one or more Luna SA HSM Partitions, that connects from a client
computer (one that has set up NTLS by exchanging certificates and registering with the Luna SA). If a Client can
provide the Partition Password, it can generate, delete, and use cryptographic objects (keys and certificates) on the
Partition, as long as the Partition is prepared to accept the connection.
In the case of Luna SA with Password Authentication (assuming the HSM Partition has been previously created
with the Password), the appliance simply needs to be powered on.
In the case of Luna SA with Trusted Path Authentication (assuming the HSM Partition has been previously created
and the Client given the Partition Password), the Partition must also be activated by the Partition Owner. That is, a
Client, even with the proper Password cannot access a Luna SA HSM Partition unless that Partition has been
placed in "activated" state by the HSM Partition Owner (using the black PED Key).
That authentication model continues unaffected, for those who prefer it. However an optional, enhanced Cryptoki model
is also available, to separate the Partition Owner or Partition User role into a read-write entity and a separate read-only
entity:
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 13

CHAPTER 1 Planning Your Configuration
• appliance admin
(Same as appliance admin description above. No change.)
• HSM Admin
(Same as HSM Admin description above. No change.)
• Crypto Officer (full Read-Write access)
(same capabilities as HSM Partition Owner and Client in the default model)
As above for HSM Partition Owner, except that two separate Passwords can now (optionally) be associated with
the black PED Key. In both cases, the black PED Key must be presented, and the administrator at the lunash
command-line can:
–modify partition policies
–activate a partition for use by Clients
–backup and restore Partition contents
The Partition Password is presented when a Client application needs to use the Partition. In this model, there are
two Passwords. The Crypto Officer Partition Password allows the Client to perform any crypto-graphic operation,
both manipulation (generation, deletion, wrap/unwrap), and use (encrypt/decrypt, sign/verify).
The other password is used (along with the black PED Key) for the Crypto User. This is set by the HSM Admin
when the Partition is created.
In operation, the Crypto Officer would log in at the management interface prompt for Partition maintenance tasks,
and/or
a Client application could connect to a registered Partition (authenticating with the Crypto Officer Password) in
order to generate and manipulate cryptographic objects in the Partition.
• Crypto User (or restricted Client user - Read-only)
If the Partition has been readied for access by the black PED Key, a Client can connect with a Client application,
authenticating with the Crypto User Password (a challenge secret, generated on command by the Luna PED,
similar to the Crypto Officer or Partition Owner Password that is generated on the Luna PED when a Partition is
created).
The Crypto User Client can then make use of cryptographic materials already in the Partition (signing, verifying,
encrypting, decrypting), but cannot manipulate those objects (no generating or deleting or wrapping/unwrapping).
This distinction differs from the old model, with just the one Partition Password, where Client users could not be
restricted from generating and deleting keys and certificates.
Either model can be used. If you work in an environment that mandates the Crypto Officer / Crypto User distinction, it is
available. If you have no need of the additional password, or if you have legacy applications that use the standard
Cryptoki roles, then simply do not activate the Crypto Officer / Crypto User roles.
How the Roles are Invoked
By default, the Crypto User role does not exist, and so the black PED Key owner is HSM Partition Owner. You create a
Crypto User (the restricted Client user) with the "partition createUser" command.
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 14

CHAPTER 1 Planning Your Configuration
Bad Login Attempts
By default, both the Crypto Officer and the Crypto user can make 10 consecutive failed login attempts before invoking
consequences. That is, the two bad-authentication counters are independent of each other.
Submissions of incorrect Partition Passwords (or Crypto Officer and Crypto User Passwords) are not counted as
incorrect black PED Key attempts.
Note: The Luna HSM must actually receive some information before it logs a failed attempt, so
if you merely forget to insert a PED Key, or provide a wrong-color key, then that is not logged as
a failed attempt. When you successfully login, the bad-attempt counter is reset to zero.
Domain Planning
Password authenticated HSMs have text-string cloning domains for the HSM SOspace and for any partitions that are
created on the HSM. HSM and Partition domains are typed at the command line of the host computer, when required.
PED authenticated HSMs have cloning domains in the form of encrypted secrets on red PED Keys, for the HSM
SOspace and for any partitions that are created on the HSM. The following characteristics are common to domains on
all Luna HSMs.
•The HSM SO-space domain can be created at the HSM (therefore unique) at HSM init time, or it can be imported,
meaning that it is shared with one-or-more other HSMs.
•The HSM partition domain can be created at the HSM (therefore unique) at partition creation time, or it can be
imported, meaning that it is shared with one-or-more other HSM partitions.
•The partition domain can be the same as the HSM SO domain or different.
•The partition domain can be the same as the domain of another partition on the same HSM (for HSMs that support
multiple partitions) or different.
For PED authenticated HSMs, the domain secret for the SOspace or for a partition can be a single red PED Key, or it
can be split (by the MofN feature) over several red keys, which are then distributed among trusted personnel such that
no single person is able to provide the cloning domain without oversight from other trusted personnel.
In scenarios where multiple HSM partitions are in use, it can be useful to segregate those partitions according to
department or business unit, or according to function groups within your organization. This ensures that personnel in a
given group are able to clone or backup/restore only the contents of partitions sharing the domain for which they are
responsible. Other functional groups, even with access to the same Luna HSM hardware have cloning or
backup/restore access to their own domain partitions, but not to those of the first group... and vice-versa.
For Password authenticated HSMs, that sort of segregation is maintained entirely by procedure and by trust, as you
rely on personnel not to share the domain text strings, just as you rely on them not to share other passwords.
For PED authenticated HSMs, the segregation is maintained by physical and procedural control of the relevant PED
Keys that each group is allowed to handle.
It can pay to pre-plan how you will divide and assign access to HSM SOspace and Partitions. Cloning Domain is one
aspect of such access. There is rarely much call to store objects on the SOspace, so the SOfunction is normally
purely administrative oversight, and the decisions are straightforward. Each SO takes care of just her/his own HSM, or
each SOcan have oversight of multiple HSMs.
Partition access can also be straightforward, if you have no particular need to segregate access by groups or by
functions or by geography or other descriptors. But, because partitions contain the working keys, certificates, and
objects that are used in your business, it is more likely that some scheme must be devised and maintained to control
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 15

CHAPTER 1 Planning Your Configuration
who can do what with each HSM partition. Also, as mentioned previously, you might wish to spread out and reinforce
responsibility by using MofN to ensure that administrative partition access can never be achieved by a single person
operating alone. These considerations require that you plan how access controls are to be implemented and tracked,
because the decisions must be made before you create the partitions.
Have your naming conventions and allotments planned out ahead of HSM initialization and partition creation, including
a well-thought-out map of who should control cloning domain access for HSM SO spaces and for Partitions.
Luna PED Planning
Plan your PED Key options and choices before you begin the actions that will invoke PED Keys.
The various PED Keys contain secrets that are created by an HSM, and are imprinted on the PED Key at the time that
a triggering action is called - for example,both the HSM and a blue SO PED Key are imprinted with the HSM SO secret
at the time the HSM is initialized. With the exception of the purple SRK PED Key, all of the other PED Key types can
take a newly-created secret that is unique in the world at the time the HSM creates it.
Optionally, the PED dialog allows you to present a key with an existing secret (of the appropriate type for the current
action) that was previously created by this HSM or by some other HSM. In that second case, the secret from the key is
imprinted on the HSM, and that key can now unlock its function (example: allow the SO to log in) on both the previous
HSM and the current HSM. This can be repeated for any number of HSMs that you wish accessible by the one secret.
What each PED prompt means
Some questions/prompts from the PED when any key/access secret is first invoked are:
Reuse - do you wish to have the current HSM generate this secret, and imprint it on the PED Key (the "No" or do not
reuse option), or do you wish to accept a secret (of the correct type) from the currently inserted PED Key, and imprint
that secret onto the current HSM, making that secret common for this HSM and any others that recognize the same
PED Key (the "Yes" or do reuse option)?
The decision is: do you wish this HSM to be accessed by the same secret that accesses this function/role on one or
more other HSMs? Or do you wish this HSM to have a new, unique secret that is recognized by no previous HSM.
Sometimes, it is advantageous to have a single secret for a group of HSMs managed by a single person. Sometimes,
security or operational rules require that each HSM must have a different secret (for the role being configured).
The option to reuse an existing secret applies only within the same type of secret, so for example you cannot tell a
partition to accept a secret from a blue SO PED Key. At partition creation, a partition must be imprinted either with a
unique new key that also goes on a PED Key, or with a secret from an already-imprinted black PED Key.
The only exception, among the various PED Keys is the purple SRK PED Key, each of which is unique to its own
HSM. No HSM can accept an SRV (the secret on the SRK) from outside. Each HSM creates its own.
M of N - do you wish to split the current secret over quantity N same-color PED Keys, such that quantity M of them will
always be needed to assemble the full secret and authenticate that role? You invoke M of N by providing the M value
and the N value using the PED Keypad, when prompted. You refuse M of N by setting the M value and the N value both
to "1". M of N is the more secure choice, when you require multiple persons to be present (with their splits of the role
secret) in order to access that role and perform its functions. No M of N is the more convenient choice, as only one
secret-carrying key must be carried and tracked, per role.
Overwrite - during create/initialize/imprint events, when the PED has received answers to its preliminary questions, it
prompts you to insert a key and press [Enter] on the keypad. This is the first point at which it actually looks at the
inserted key. The PED then tells you what is on the inserted key (could be blank, could be any of several authentication
secrets) and asks if you wish to overwrite. This is an opportunity to reconsider the key that you have inserted, before
something irreversible happens. You can say "No" (don't overwrite what was found ), remove the key, and go back to
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 16

CHAPTER 1 Planning Your Configuration
being prompted to insert a key. If you say "Yes" to overwrite what the PED just told you is on this inserted key, the PED
gives you another chance to reconsider: "WARNING*** Are you sure...". The PEDis very thorough about making sure
that you do not accidentally overwrite a useful authentication secret.
PED PIN - At the point where it has been decided that you are not reusing key content, and you are or are not splitting
the new secret across multiple keys, and that you are absolutely certain that you wish to write a new secret on the
inserted key, the PED prompts you to type a PED PIN. The PED is about to write onto the key a secret that was just
generated by the HSM. If you simply press [Enter] on the PED keypad, without typing any digits, you are providing no
PED PIN, and the secret that goes onto the key is the secret as provided by the HSM. If you type any digits, before
pressing [Enter] (minimum of 4 digits), then the typed digits (the new PED PIN) are XOR'd with the secret from the
HSM, before the combined secret goes onto the PED Key. This means that the secret on the PED Key is not identical
to the secret from the HSM, so in future you must always type those PED PIN digits to reverse the XOR and present
the HSM with the secret it is expecting. With a PED PINapplied, the secret for that role is now two-factor - something
you have (the version of the secret that is imprinted on the key) and something you know (the secret that you type in, to
be XOR'd with the contained secret), to make the final secret that unlocks the HSM.
At this point, the key is imprinted. Now the PED inquires if you wish to duplicate the key you just made.
Duplicate - in general, you should always have duplicate keys for each role (or duplicate M of N sets, per role, if you
chose to invoke the M of N split), so that you can have at least one off-site backup, and probably an on-site standby or
backup set as well. Your security and operational policies will dictate how many sets you need. When the PED prompts
to inquire if you wish to duplicate the current PEDKey, you should be ready with the knowledge if you already have
enough copies of that secret or if you need to make more. The more you make, the more you must track. But you must
have enough to satisfy your organization's operational and security protocols.
The above paragraphs explain the meanings of each of the prompts that you would see from Luna PED while
performing an action (like initialization) that imprints PED Keys with secrets. The following sections discuss some
implications of the above choices for specific roles (PED Key colors).
HSM Initialization and the Blue SOPED Key
The first action that invokes Luna PED (which must be connected, as described in the Luna PED option section of the
hardware setup chapter) is HSM initialization.
When you initialize, you are creating an SO (security officer) identity and space on the HSM. In most cases, this is an
administrative position and the only keys or objects that are ever stored there are system keys, not user keys. The SO
sets policy for the overall HSM, and creates partitions.
When creating an access secret for the SO, you are creating a secret for an administrator who sets up the HSM and
then rarely is needed thereafter. You might have a single person who has the job of overseeing several HSMs, in which
case, only the first HSM creates a secret to imprint on a blue PED Key. The second, and all future HSMs to be
administered by that person (or role/job in your organization) would accept that secret from a provided blue PED Key,
rather than creating their own unique SO PED Keys. In that situation, you would choose to "Reuse an existing keyset"
when initializing every HSM after the first one.
Alternatively, you might have a very compartmentalized organization where a separate individual must have
administrative authority over each HSM, so in that case you would use blank blue keys each time you initialized a new
HSM, and each HSM would imprint its own uniquely generated SO secret onto a unique blue key. As well, you would
have the opportunity to apply PED PINs to any or all of the unique SO PED Keys.
Each person who is to act as SO for an HSM must be able to access the appropriate blue PED Key when needed.
Either they carry it with them, or they sign it out when they are using it and sign it back into a secure lockup. If PED
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 17

CHAPTER 1 Planning Your Configuration
PINs are in use, then each SO and each SO backup/alternate personnel must know the PED PIN(s) for every HSMin
their charge.
If your organization enforces a policy of password changes at certain intervals, or at events like firings and personnel
turnover, then you have options and requirements - you might need to change the secret on the PED Key (hsm
changePw command) or you might satisfy the password-changing requirement by simply changing the PEDPIN.
Furthermore, when you initialize an HSM with a new secret, you have the opportunity to split that secret using the M of
N feature. In this way, you ensure that a certain minimum number of personnel must be present with their blue PED
Keys whenever the SO must log in. While making that choice, you should choose "M"to be the smallest number that
satisfies the requirement. Similarly, "N" should be large enough to ensure that you have enough "spare" qualified SO
split holders that you can assemble a quorum even when some holders are unavailable (such as for business travel,
vacations, illness). Just as with a single, non-split SO secret, you can apply PED PINs to each blue key in an M of N
set. Consider, before you do, how complicated your administration and key-handling/key-update procedures could
become.
Before you begin the HSM init process, have your blue PEDKeys ready, either with an existing SO secret to reuse, or
blank (or outdated secret) to be overwritten by a unique new SO secret generated by the HSM. At the same time, you
must also have appropriate red PED Keys ready, because assigning/creating a cloning domain for the HSM is part of
the HSM init process. See the next section, below.
HSM Cloning Domain and the Red Domain PED Key
All the points, options, decisions listed above for the SO key apply equally to the Cloning domain key, with two
exceptions.
First, you MUST apply the same red key Cloning Domain secret to every HSM that is to :
•clone objects to/from each other
•participate in an HA group (synchronization uses cloning
•backup/restore.
By maintaining close control of the red PED Key, you control to which other HSMs the current HSM can clone.
Second, unlike the case of the blue SO PED Key secret and the black Partition Owner/User PEDKey secret, there is
no provision to reset or change a Cloning Domain. An HSM domain is part of an HSM until it is initialized. An HSM
Partition domain is part of an HSM partition for the life of that partition. Objects that are created in an HSM with a
particular domain can be cloned only to another HSM having the same domain.
Before you begin the HSM init process, have your red PEDKeys ready, either with an existing cloning domain secret to
reuse, or blank (or outdated secret) to be overwritten by a unique cloning domain secret generated by the HSM.
Partition Owner/User and the black PED Key
All the points listed above for the SO key apply equally to the black PED Key when an HSM partition is created.
The black PED Key Partition Owner/User secret secures the HSM partition to which it is applied, and all contents of the
partition.
The black PEDKey for a partition (or a group of partitions) :
•allows the holder to log in as the Partition Owner/User to perform administrative tasks on the partition
•set the partition "open for business" by Activating the partition - when a partition is activated, applications can
present the partition challenge secret and make use of the partition
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 18

CHAPTER 1 Planning Your Configuration
When a partition is created, after the black PED Key is imprinted, you are prompted to provide a domain for the new
partition.
At your option, your partition can:
•take on the same Cloning Domain (red PED Key) asthe HSM in which it resides
•take on a new, unique Cloning Domain, generated by the HSM at partition creation (no other partition can share
objects with this partition or be configured in HA with this partition, until the newly created domain is shared),
•take on a cloning domain (from an existing, imprinted red PED Key) that already holds the domain secret for another
partition - this is how you allow the new partition to accept objects from a Backup HSM or to be part of an HA group)
This is how you control which partitions (on the same or different HSMs) share a domain.
Regardless of whether the HSM (SO space) and the partition share a domain, it is not possible to copy/clone objects
between the two. A shared domain between partitions allows you to clone between/among those partitions, and to
make such partitions members of an HA group. All members of an HAgroup must share a common cloning domain.
On an HSM that supports multiple partitions, all partitions could have the same domain, or all could have different
domains, or some combination could be in effect.
Before you begin the HSM init process, have your black PEDKeys ready, either with an existing Partition Owner or
User secret to reuse, or blank (or outdated secret) to be overwritten by a unique new partition Owner secret generated
by the HSM. At the same time, you must also have appropriate red PED Keys ready, because assigning/creating a
cloning domain for the partition is part of the partition creation process. See the previous section, above.
Remote PED Orange PED Key (RPK)
This key is not tied to a fundamental activity like initializing an HSM or creating a partition. Instead, if you don't expect
to use the Remote PED option, you never need to create an orange PEDKey.
If you do have a Remote capable Luna PED, and want to use it for remote authentication, rather than always having the
PED locally connected to the HSM, then the HSM and the PED that is remotely hosted must share a Remote PED
Vector (RPV). The RPV is generated by the HSM when you instruct it to set a PEDvector and imprinted onto an orange
PEDKey, or it is accepted from an existing Remote PED Key and imprinted onto the HSM.
When you invoke "ped vector set" or similar command, to create/imprint a Remote PED Vector, the PED prompt
sequence is similar to the sequence for the blue or black PED keys, with the same questions/choices for you to make
about "reuse" (or a fresh, new secret), about M of N, about duplicates, etc.
Before you begin the PED vector init process, have your orange PEDKeys ready, either with an existing RPV secret to
reuse, or blank (or outdated secret) to be overwritten by a unique new RPV secret generated by the HSM. The first time
you set an RPV for an HSM, the PEDmust be locally connected. After that, you can take the orange PEDKey (and
your other PED Keys for that HSM) to any host anywhere that has PedServer running and has a remote-capable Luna
PED attached.
Auditor
The Audit role is completely separate from other roles on the HSM. It is optional for operation of the HSM, but might be
mandatory according to your security regime. The Audit role can be created at any time, and does not require that the
HSM already be initialized.
When you invoke audit init, to create/imprint an Audit role secret, the PED prompt sequence is similar to the sequence
for the blue or black PED keys, with the same questions/choices for you to make about "reuse" (or a fresh, new secret),
about M of N, about duplicates, etc.
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 19

CHAPTER 1 Planning Your Configuration
Before you begin the Audit init process, have your white PEDKeys ready, either with an existing Auditor secret to
reuse, or blank (or outdated secret) to be overwritten by a unique new Auditor secret generated by the HSM.
Secure Recovery Purple PED Key (SRK)
The Secure Recovery Vector is imprinted onto a purple Secure Recovery Key, only if you have invoked SRK. The
Master Tamper Key and the recovery components (one of which can be brought outside the HSM and kept on a purple
PED Key) are explained elsewhere. What you need to know is that there is no need to create a purple PED Key unless
you :
•need to enforce acknowledgment of tamper events by your personnel, before returning the HSM to service, or
•wish to invoke Secure Transport Mode.
When you invoke SRK, to remove one of the MTK recovery secret splits from the HSM and imprint it onto a purple PED
Key, the PED prompt sequence DOESNOT include a "reuse" option. The purple PEDKey is the only one that is unique
to its HSM and cannot be reused. The secret is generated within the HSM and goes onto a purple PED Key (or several,
if you choose M of N), but there is no ability for the HSM to accept an already imprinted purple key secret that came
from another HSM. SRKs are always unique. That is, you can make as many copies as you wish, but they will work
with only one HSM in the world.
Other than that, the PED prompt sequence is similar to the sequence for the blue or black PED keys, with the same
questions/choices for you to make about M of N, about duplicates, etc.
Before you begin the SRK process, have your purple PEDKeys ready, either a blank key, or outdated secret, to be
overwritten by a unique new Secure Recovery Vector generated by the HSM.
Other Considerations
In each case, have your materials and notes about your previously-made decisions on hand before you launch a
command that invokes key creation or imprinting.
Predetermine which of your personnel will have access to which PED Keys, how many people should be required to
perform a given authentication action, whether they will carry their PED Key(s), or will need to retrieve them from a
secure lockup for each occasion that they are used, how many backup sets you expect to maintain.
Keep in mind that backups are good, but each backup set must be updated if the operational or master set is changed
for any reason.
If your security policies do not require periodic changes to PED Key secrets (possible for any of the other PED Keys,
but effectively impossible for red domain PEDKeys), and if your physical and procedural security is strong enough,
then it is quite possible to just create the set(s) of PED Keys that you need, and then not need to touch them again for
years.
By contrast, if your policies demand periodic change, or if you think you might be forced to change PEDKey secrets
due to personnel departures or other events, then have a clear plan in place about how you will deal with such situations
before you create your various PED Key sets.
Luna PED Planning
Plan your PED Key options and choices before you begin the actions that will invoke PED Keys.
The various PED Keys contain secrets that are created by an HSM, and are imprinted on the PED Key at the time that
a triggering action is called - for example,both the HSM and a blue SO PED Key are imprinted with the HSM SO secret
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc.All rights reserved. 20