SafeNet Luna SA Configuration 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 techpubs@safenet-inc.com

Luna SA Configuration Guide

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

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

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

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

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

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>]

{a|b|c} {<a>|<b>|<c>}

[a|b|c] [<a>|<b>|<c>]

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.

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.

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.

Table 1: Technical support contacts

Contact method Contact

Address SafeNet, Inc.

4690 Millennium Drive Belcamp, Maryland 21017 USA

Phone United States (800) 545-6608, (410) 931-7520

Australia and New Zealand +1 410-931-7520

China (86) 10 8851 9191

France 0825 341000

Germany 01803 7246269

India +1 410-931-7520

United Kingdom 0870 7529200, +1 410-931-7520

Web www.safenet-inc.com

Support and Downloads www.safenet-inc.com/support

Luna SA Configuration Guide

8

Contact method Contact

Provides access to the SafeNet Knowledge Base and quick downloads for various products.

PREFACE About the Configuration Guide

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

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

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

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

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

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

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

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

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

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

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

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

20

CHAPTER 1 Planning Your Configuration

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 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

Luna SA Configuration Guide

21

CHAPTER 1 Planning Your Configuration

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 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.

Luna SA Configuration Guide

22

CHAPTER 1 Planning Your Configuration

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

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.

Luna SA Configuration Guide

23

CHAPTER 1 Planning Your Configuration

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.

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.

Luna SA Configuration Guide

24

CHAPTER 1 Planning Your Configuration

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 SA Configuration Guide

25

CHAPTER 2

Configure the Luna Appliance for your Network

In this section, gather information and apply appropriate settings to replace factory default values, and have your LunaSA appliance recognized on your network.

Gather appliance network setting information

Before you begin, obtain the following information (see your network administrator for most of these items):

• New appliance admin Password

HSM Appliance Network Parameters

• the IP address assigned to this device (if you are using static IP, which is recommended)

• Hostname for the HSM appliance (registered with network DNS)

• domain name

• default gateway IP address

• DNS Name Server IP address(es)

• Search Domain name(s)

• device subnet mask

• Ethernet device (use eth0, which is the uppermost network jack on the HSM appliance back panel, closest to the

power supply, and is labeled 1 )

DNS Entries

• Ensure that you have configured your DNS Server(s) with the correct entries for the appliance and the client.

If you are using DHCP, then all references to the Client and the HSM appliance (as in Certificates) should use hostnames.

Client Requirements

• If you are using a client workstation with Linux or UNIX, then SSH (secure shell) and the scp utility, should be installed and ready to use (normally they are provided with the operating system).

• If you are using a Windows-based workstation, then the freeware PuTTY utility suite is supplied in our LunaClient Software, and is installed in c:\Program Files\SafeNet\LunaClient\putty.exe. The pscp utility is also included in LunaClient Software installer, and is required for this installation.

Go to "Recommended Network Characteristics" on page 27

Luna SA Configuration Guide

26

CHAPTER 2 Configure the Luna Appliance for your Network

Recommended Network Characteristics

Determine whether your network is configured optimally for use of Luna appliances.

Bandwidth and Latency Recommendation

Bandwidth

• Minimum supported: 10 Mb half duplex

• Recommended: at least 100 Mb full duplex - full Gigabit Ethernet is supported

Note: Ensure that your network switch is set to AUTO negotiation, as the Luna appliance

negotiates at AUTO. If your network switch is set to use other than automatic negotiation, there is a risk that the switch and the Luna appliance will settle on a much slower speed than is actually possible in your network conditions.

Network Latency

• Maximum supported: 500ms

• Recommended: 0.5ms

About Latency and Testing

Luna appliance client-server communication uses timeouts less than 30 seconds to determine failure scenarios. Thus the appliance does not tolerate network configurations or conditions that introduce a greater delay - problems can result, especially with HA configurations.

Here is a description of one common cause of such a situation, and what you can do about it.

When you disconnect the network cable between any Luna appliance and a switch, and then reconnect, traffic should resume immediately, but with certain network switch configurations it might take 30 seconds for traffic to resume.

The problem here is at the switch (and not the Luna appliance). See

http://www.cisco.com/warp/public/473/12.html#bkg for some descriptions of Cisco switches. If the switch is

configured to run the Spanning Tree Protocol on the port (which appears to be the default configuration, at least for Cisco switches), then there is a delay of about 30 seconds while it runs through a series of discovery commands and waits for responses. The switches can be configured to run in “PortFast” mode in which the Spanning Tree Protocol still runs on the port, but the port is placed directly into 'forwarding mode' and starts the traffic flowing immediately.

With the switch introducing a connection detection delay of 30 seconds or greater, transient network failures lasting only seconds are no longer tolerated. A simple test is to set up a ping stream and then disconnect and reconnect the network cable. The ping traffic should resume after a 1 or 2 second delay. A greater delay indicates that a switch in the network is not detecting the reconnection as quickly as is optimal. See the recommendations for network Bandwidth and Latency.

Go to "Power-up the HSM Appliance" on page 27 .

Power-up the HSM Appliance

Instructions on this page assume that the HSM appliance has been installed, including

• power connections [We suggest that each of the two power supplies be connected to an independent electrical source, and that at least one of those sources should be protected by UPS (uninterruptible power supply) and generator backup.],

Luna SA Configuration Guide

27

CHAPTER 2 Configure the Luna Appliance for your Network

• connection to your network [gigabit or 100 megabit ethernet],and

• a null-modem serial connection between the HSM appliance's serial Console Port and your administration

computer or a terminal [recommended option - this is for convenience, during initial setup, so your administrative connection remains active when you assign new IPaddresses; later, you would need a local serial link if you ever need to log in to the Recover account].

The following instructions require the HSM appliance to be connected and running.

Power On Instructions for the Luna Appliance

On the back panel, ensure that the power supplies are connected and working - the green LED on each power supply should glow steadily .

If the appliance does not immediately begin to start up, press and release the START/STOP switch near the center of the back panel (marked with the symbol below). The HSM appliance begins to power up.

If the appliance was deliberately powered down, using the START/STOP switch or the "poweroff" command,

then it should remain off until you press the START/STOP switch. However, if power was removed while the system was on (either a power failure, or the power cable was disconnected - not good practice), then the system should restart without a button press. This behavior allows unattended resumption of activity after power interruption. [In most cases, it is assumed that this would never be needed, as you would install the appliance with its two power supplies connected to two completely separate, independent power sources, at least one of which would be batterybacked (uninterruptible power supply) and/or generator-backed.]

The “Network” LEDs glow or blink to indicate the exchange of traffic. The network LEDs do not illuminate if there is no network connection (check your network cable connections on the back panel and at hub or switch). Here is a summary.

Luna SA Configuration Guide

28

CHAPTER 2 Configure the Luna Appliance for your Network

Ethernet

State Indicated Indication

connector LED

NIC 1 (Right) Activity status Green (Blinking): NIC1 activity detected

Off: NIC1 is not active, or LAN cable has no connection

NIC 1 (Left) Speed range Orange: 1G

Green: 100M

Off: 10M/No connection

NIC 2 (Right) Activity status Green (Blinking): NIC2 activity detected

Off: NIC2 is not active, or LAN cable has no connection

NIC 2 (Left) Speed range Orange: 1G

Green: 100M

Off: 10M/No connection

The front-panel LCD (See "Front-panel Display" ) begins showing activity, then settles into the ongoing system status display, once the appliance has completed its boot-up and self-test activity.

Power Off

To power-off the HSM appliance locally, press and release the START/STOP switch. Do not hold it in. The HSM appliance then performs an orderly shutdown (that is, it closes the file system and shuts down services in proper order for the next startup). This takes approximately 30 seconds to complete. In the unlikely event that the system freezes and does not respond to a momentary “STOP” switch-press, then press and hold the START/STOP switch for five seconds. This is an override that forces immediate shutoff.

CAUTION: Never disconnect the power by pulling the power plug. Always use the START/STOP switch.

To switch off the HSM appliance from the lunash command line, use the command:

lunash:> sysconf appliance poweroff

Luna SA Configuration Guide

29

CHAPTER 2 Configure the Luna Appliance for your Network

Next, see "Open a Connection" on page 30.

Open a Connection

Perform your initial configuration via direct serial connection to the Luna appliance. Once network parameters are established, you can switch to an SSH session over your network.

Direct administration connection via serial terminal is the method for initial configuration for the following reasons:

• The specific IP address, randomly assigned to your Luna appliance by an automated testing harness during final

factory testing, is unknown.

• Configuring network settings via SSH, in addition to requiring the original IP address, necessarily involves losing

that connection when a new IPis set.

• A direct serial connection is the only route to log into the "recover" account, in case you ever lose the appliance's

admin password and need to reset. Therefore, you should verify, before you need it, that the connection works performing the appliance's network configuration is an ideal test.

• Similarly, if you ever need to issue the hsm factoryreset command, you must be connected through a local

serial console for that command to be accepted.

To open a connection

1. Connect a null-modem serial cable (supplied) between the serial port on the HSM appliance front panel and a dumb

terminal or a PC (for example a laptop) that will serve as the administration computer.

Note: A standard null-modem serial cable with DB9 connectors is included with the HSM appliance, as is a USB-to-serial adapter if needed. For security reasons, the USB port on the Luna SA appliance recognizes only SafeNet HSMs and peripheral devices - therefore it is prohibited from supporting general USB operations and thus does not accept a serial console link; the 9-pin serial connector must be used.

2. Use a terminal emulation package provided with your operating system. Set the Serial connection parameters:

– Serial port baud rate: 115200

– N,8,1 (no parity, 8 data-bits, one stop-bit)

– VT-100 terminal emulation

– hardware flow control selected.

3. When the connection is made, the HSM appliance login prompt appears. [DEFAULTHOSTNAME]lunash:> The

[DEFAULTHOSTNAME] is replaced by the new hostname that you assign to your HSM appliance, later in these instructions. The prompt changes the next time you start a secure command-line interface connection.

Note: You might need to press [ENTER] several times to initiate the session. You must log in within two minutes of opening an administration session, or the connection will time out.

Now that you have established a connection, go immediately to the next page to log in as “admin” and begin configuring.

Next, see "First Login & Changing Password" on page 31.

Luna SA Configuration Guide

30

SafeNet Luna SA Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual