HSM Documentation

VERSION 1.0 | 27TH SEPTEMBER 2020

Contents
Contents................................................................................................................................................2
1 EXECUTIVE SUMMARY...............................................................................................................4
2 HSM INITIALIZATION.................................................................................................................4
2.1 INITIALIZATION.......................................................................................................................4

2.2 PED Setup in HSM INITIALIZATION.........................................................................................6

2.3 Imprinting the Blue HSM SO PED Key........................................................................................7

2.4 Imprinting the Red Cloning Domain PED Key.............................................................................9

2.5 New, reuse, and overwrite options..........................................................................................10

3 PED AUTHENTICATION............................................................................................................12
3.1 PED Key Types and Roles..........................................................................................................13

3.2 SHARED KEY SECRET.................................................................................................................15

3.3 Domain PED Keys......................................................................................................................15

3.4 PED PIN.....................................................................................................................................16

3.5 M of N Split Secrets..................................................................................................................16

3.6 Activated Partitions and M of N...............................................................................................17

3.7 Remote PED..............................................................................................................................17

4 PARTITIONS...............................................................................................................................19
4.1 The Administrative Partition....................................................................................................20

4.2 Application Partitions...............................................................................................................20

4.3 Creating Partition.....................................................................................................................20

4.4 Partition Initialization...............................................................................................................21

4.4.1 Initializing Partition.....................................................................................................21

4.4.2 Change PO password to make it usable......................................................................21

 4.4.3 Initialize the Crypto Officer role..................................................................................22

4.4.4 Change Crypto Officer password to make it usable....................................................22

4.5 Activation and Auto-activation on PED-Authenticated Partitions...........................................23

4.5.1 Enabling Activation on a Partition..............................................................................23

4.5.2 Enabling Auto-activation.............................................................................................25

5 HIGH-AVAILABILITY GROUPS..................................................................................................25
5.1 Prerequisites.............................................................................................................................25

5.1.1 HSMs............................................................................................................................26

5.1.2 Partitions.....................................................................................................................26
5.2 To set up an HA group..............................................................................................................26

5.3 Configuring HA Auto-Recovery.................................................................................................29

5.4 HA Only Mode..........................................................................................................................30

5.5 HSM DR.....................................................................................................................................31

6 AUDIT LOG.................................................................................................................................32
6.1 Audit Logging Features.............................................................................................................33

6.2 Configure Audit Loging.............................................................................................................34

6.2.1 Configure NTP..............................................................................................................34

6.2.2 Enable audit user.........................................................................................................34

6.2.3 Configuration...............................................................................................................34

6.2.4 Log Rotation.................................................................................................................35

6.2.5 To copy files off the appliance.....................................................................................35

7 CAVEAT.......................................................................................................................................36
7.1 How to use lunacm...................................................................................................................36
1 EXECUTIVE SUMMARY
HSM is a secure memory device to store vital data objects – cryptographic Private/secret keys. It
basically is a hardware designed to detect attack and respond by deleting keys. Dedicated hardware
provides high-performance cryptographic processing engine.
HSMs provide a secure storage and processing environment for keys that protect data or signing
transactions. They can hold 1000s of keys and secure many applications on many servers. HSMs can
also hold the Master Key that secures an unlimited number of external keys.
This document gives a base for setting up HSM and Partitions to be used by application.
In this documentation, few terms are referred as below,
HSM Security Officer: HSM SO
Application Partition Officer: HSM PO
Lunacm: This refers to commands run through lunacm client
Lunash: This refers to commands run through lunash (ssh)

2 HSM INITIALIZATION

2.1 INITIALIZATION

Initialization prepares a new HSM for use, or an existing HSM for reuse, as follows. You must
initialize the HSM before you can generate or store objects, allow clients to connect, or perform
cryptographic operations

Hsm init sets the following:

HSM Label The label is a string of up to 32 characters that

identifies this HSM unit uniquely. A labeling
convention that conveys some information
relating to business, departmental or network
function of the individual HSM is commonly
used. Labels cannot contain a leading space.

HSM SO credentials For PED-authenticated HSMs, you create a new

HSM SO (blue) PED key(set) or re-use an
existing key(set) from an HSM you want to
share credentials with.

Cloning domain for the HSM Admin partition The cloning domain is a shared identifier that
makes cloning possible among a group of HSM
partitions. It specifies the security domain
 (group of HSM partitions) within which the
HSM Admin partition can share cryptographic
objects though cloning, backup/restore, or in
high availability configurations. Note that the
HSM Admin partition cloning domain is
independent of the cloning domain specified
when creating application partitions on the
HSM.

For PED-authenticated HSMs, you create a new

Domain (red) PED key(set) or re-use an existing
key(set) from an HSM you want to be able to
clone with.

Please note re-initializing the HSM forces the deletion of all partitions and objects on the
HSM.

1. If Secure Transport Mode is set, you must unlock the HSM before proceeding. New SafeNet
Luna HSMs are shipped from the factory in Secure Transport Mode (STM). STM allows you to
verify whether or not an HSM has been tampered while it is not in possession, such as when
it is shipped to another location, or placed into storage. To recover HSM from Secure
Transport Mode, proceed as follows:
a. As part of the delivery process for new HSM, should have received an email from
Thales Client Services, containing two 16-digit strings, as follows. You will need both
of these strings to recover the HSM from STM:
i. Random User String: XXXX-XXXX-XXXX-XXXX
ii. Verification String: XXXX-XXXX-XXXX-XXXX
b. Ensure that you have the Random User String and Verification String that were
emailed for new HSM.
c. Enter the following command to recover from STM, specifying the Random User
String that was emailed to you for your new HSM

Lunash:> hsm stm recover -randomuserstring <XXXX-XXXX-XXXX-XXXX>

d. You are presented with a verification string. If the verification string matches the
original verification string emailed to you for your new HSM, the HSM has not been
tampered, and can be safely deployed. If the verification string does not match the
original verification string emailed to you for your new HSM, the HSM has been
tampered while in STM. If the verification strings do not match, contact Thales
Technical Support immediately.
e. Enter proceed to recover from STM (regardless of whether the strings match or not),
or enter quit to remain in STM.
 2. If you are initializing a PED-authenticated HSM, have the Luna PED connected and ready (via
USB, in Local PED-USBmode). If your PED is not in USB mode, see "ChangingModes" onpage
205 in the HSM AdministrationGuide.
3. Log into LunaSH as the appliance administrator 'admin'. You can use a serial terminal
window or SSH connection.
4. Run the hsm init command, specifying a label for your SafeNet Luna Network HSM: lunash:>
hsm init -label <label>
5. Respond to the prompts to complete the initialization process, you are prompted to attend
to the PED to create a new HSM SO (blue) PED key for this HSM, re-use an HSM SO PED key
from an existing HSM so that you can also use it to log in to this HSM, or overwrite an
existing key with a new PED secret for use with this HSM. You are also prompted to create,
re-use, or overwrite the Domain (red) PED key. You can create MofN keysets and duplicate
keys as required. Details are in next section.

2.2 PED Setup in HSM INITIALIZATION

1. When you issue the hsm init command, the HSM passes control to the Luna PED, and the
command line (lunash:>) directs you to attend to the PED prompts.
2. A"default" login is performed, just to get started (you don't need to supply any authentication
for this step).
3. Luna PED asks: "Do you wish to reuse an existing keyset?". If the answer is No, the HSM creates a
new secret which will reside on both the HSM and the key (or keys) that is (or are) about to be
imprinted. If the answer is Yes, then the HSM does not create a new secret and instead waits for
one to be presented via the PED.
4. Luna PED requests a blue PED key. It could be blank to begin with, or it could have a valid secret
from another HSM (a secret that you wish to preserve), or it could have a secret that is no longer
useful.
5. Luna PED checks the key you provide. If the PED key is not blank, and your answer to "...reuse an
existing keyset" was Yes, then Luna PED proceeds to copy the secret from the PED key to the
HSM.
6. If the key is not blank, and your answer to "...reuse an existing keyset" was No, then the PED
inquires if you wish to overwrite its contents with a new HSM secret. If the current content of
the key is of no value, you say Yes. If the current content of the key is a valid secret from another
HSM (or if you did not expect the key to hold any data) you can remove it from the PED and
replace it with a blank key or a key containing non-useful data, before you answer Yes to the
'overwrite' question.
7. Assuming that you are using a new secret, and not reusing an existing one, Luna PED asks if you
wish to split the new HSM secret. It does this by asking for values of "M" and "N". You set those
values to "1" and "1" respectively, unless you require MofN split-secret, multi-person access
control for your HSM (See "Mof N Split Secrets" onpage 202 for details).
8. Luna PED asks if you wish to use a PED PIN (an additional secret; see "PED KeyManagement" on
page 229 for more info).
9. If you just press Enter (effectively saying 'no' to the PED PIN option), then the secret generated
by the HSM is imprinted on the PED key, that same secret is retained as-is on the HSM, and the
same secret becomes the piece needed to unlock the Security Officer/HSM Admin account on
the HSM.
10. If you press some digits on the PED keypad (saying 'yes' to the PED PIN option), then the PED
combines the HSM-generated secret with your PED PIN and feeds the combined data blob to the
HSM. The HSM throws away the original secret and takes on the new, combined secret as its
SO/HSM Admin secret.
11. The PED key contains the original HSM-generated secret, but also contains the flag that tells the
PED whether to demand a PED PIN (which is either no digits, or a set of digits that you supplied,
and must supply at all future uses of that PED key).
12. Luna PED gives you the option to create some duplicates of this imprinted key. You should make
at least one duplicate for backup purposes. Make additional duplicates if your security policy
permits, and your procedures require them.
13. Next, Luna PED requests a red Domain PED key. The HSM provides a cloning Domain secret and
the PED gives you the option to imprint the secret from the HSM, or to use a domain that might
already be on the key. You choose appropriately. If you are imprinting a new Domain secret, you
have the same opportunities to split the secret, and to apply a PED PIN "modifier" to the secret.
Again, you are given the option to create duplicates of the key.
14. At this point, the HSM is initialized and Luna PED passes control back to LunaSH.

2.3 Imprinting the Blue HSM SO PED Key

1. Decide if you want to reuse a keyset.

1. Decide if you wanttoreuse a keyset.

a. If you say No (on the PED keypad), then you are indicating there is nothing of value on
your PED keys to preserve, or you are using blank keys.
b. If you say Yes, you indicate that you have a PED key (or set of PED keys) from another
HSM and you wish your current/new HSM to share the authentication with that other
HSM. Authentication will be read from the PED key that you present and imprinted onto
the current HSM
2. Set MofN.
 a. Setting M and N to 1 means that the authentication is not to be split, and only a single
PED key will be necessary when the authentication is called for in future. Input 1 for
each prompt if you do not want to use MofN.
b. Setting M and N to larger than 1 means that the authentication is split into N different
splits, of which quantity M of them must be presented each time you are required to
authenticate. MofN allows you to enforce multi-person access control - no single person
can access the HSM without cooperation of other holders.
3. Insert your blank key or the key you wish to overwrite.

Insert a blue HSM Admin/SO PED key and press Enter.

a. Yes: If the PED should overwrite the PED key with a new SO authentication. If you
overwrite a PED key that contains authentication secret for another HSM, then this PED
key will no longer be able to access the other HSM, only the new HSM that you are
currently initializing with a new, unique authentication secret .
b. No: If you have changed your mind or inserted the wrong PED key.
4. For any situation other than reusing a keyset, Luna PED now prompts for you to set a PED PIN.
For multifactor authentication security, the physical PED key is "something you have." You can
choose to associate that with "something you know," in the form of a multi-digit PIN code that
must always be supplied along with the PED key for all future HSM access attempts.
 Type a numeric password on the PED keypad, if you wish. Otherwise, just press Enter twice to
indicate that no PED PIN is desired.

5. Decide if you want to duplicate your keyset.

a. Yes: Present one or more blank keys, all of which will be imprinted with exact copies of
the current PED key's authentication.
b. No: Do not make any copies.

NOTE: You should always have backups of your imprinted PED keys, to guard against loss or
damage.

2.4 Imprinting the Red Cloning Domain PED Key

1. To begin imprinting a Cloning Domain (red PED key), you must first log into the HSM. Insert
your blue SO PED key.

1. Decide if you wanttoreuse a keyset.

a. No: If this is your first SafeNet Luna HSM, or if this HSM will not be cloning objects
with other HSMs that are already initialized
b. Yes: If you have another HSM and wish that HSM and the current HSM to share their
cloning Domain.
 2. Set MofN.
3. Insert your blank key or the key you wish to overwrite.
4. Optionally set a PED PIN.
5. Decide if you want to duplicate your keyset.

Once you stop duplicating the Domain key, or you indicate that you do not wish to make any
duplicates, Luna PED goes back to "Awaiting command...". LunaSH says:

Command Result : No Error

2.5 New, reuse, and overwrite options

The table below summarizes the steps involving Luna PED immediately after you invoke the
command hsm init. The steps in the table are in the order in which they appear as PED prompts,
descending down the column.

The first column is the simplest, and most like what you would encounter the very first time you
initialize, using "fresh from the carton" PED keys.

The next two columns of the table show some differences if you are using previously-imprinted PED
keys, choosing either to reuse what is found on the key (imprint it on your new HSM) or, to
overwrite what is found and generate a new secret to be imprinted on both the PED key and the
HSM.

New PED Keys Existing PED Keys (Reuse) Existing PED Keys (Overwrite)

SLOT 01 SLOT 01
SLOT 01

SETTING SO PIN... SETTING SO PIN...

SETTING SO PIN... Would
you like to reuse an existing
Would you like to reuse an existing Would you like to reuse an existing
keyset? (Y/N)
keyset? (Y/N) keyset? (Y/N)

No
No Yes

SLOT 01 SLOT 01 Slot 01

SETTING SO PIN... SETTING SO PIN... SETTING SO PIN...

Insert a SO / HSM Admin PED Key Press Insert a SO / HSM Admin PED Key Press Insert a SO / HSM Admin PED
ENTER. ENTER. Key

Press ENTER.

This PED Key is blank. ****Warning!**** ****Warning!****

Overwrite? (YES/NO) This PED Key is forSO / HSM Admin This PED Key is forSO / HSM

Yes Overwrite? (YES/NO) Admin

No Overwrite? (YES/NO)

Yes

Entera new PED PIN

Entera new PED PIN Entera new PED PIN

Confirm new PED PIN

Confirm new PED PIN Confirm new PED PIN

> Press Enter forno PED PIN

> Press Enter forno PED PIN > Press Enter forno PED PIN
> Input 4-16 digits on the PED
> Input 4-16 digits on the PED keypad > Input 4-16 digits on the PED keypad
keypad

Are you duplicating this keyset? Are you duplicating this keyset?
Are you duplicating this keyset? YES/NO
YES/NO YES/NO

> Yes: duplicate. This option can be

> Yes: duplicate. This option can be > Yes: duplicate. This option can
looped foras many duplicates as
looped foras many duplicates as be looped foras many duplicates
you need
you need as you need

> No: do not duplicate

> No: do not duplicate > No: do not duplicate

Login SO / HSM Admin... Login SO / HSM Admin.. Login SO / HSM Admin..

Insert a SO/ HSM Admin PED Key Insert a SO/ HSM Admin PED Key Insert a SO/ HSM Admin PED

Press ENTER Press ENTER Key

Press ENTER

SETTING DOMAIN... SETTING DOMAIN... SETTING DOMAIN... Would

 Would you like to reuse an existing Would you like to reuse an existing
you like to reuse an existing
keyset? (Y/N) keyset? (Y/N)
keyset? (Y/N)

> Yes (unless you have good reason > Yes: make this HSM part of an
> Yes: make this HSM part of an
to create a new domain) existing domain
existing domain

> No: create a new domain forthis

> No: create a new domain for this
HSM
HSM

3 PED AUTHENTICATION

The SafeNet Luna PIN Entry Device (Luna PED) provides PIN entry and secret authentication to a
SafeNet Luna HSM that requires Trusted Path Authentication. The requirement for PED or password
authentication is configured at the factory, according to the HSM model you selected at time of
purchase.

The Luna PED and PED keys are the only means of accessing the PED-authenticated HSM's
administrative functions. They represent the first part of the SafeNet Luna Network HSM with
Trusted Path Authentication's two-part, FIPS140-2 level 3-compliant Client authentication. They
prevent key-logging exploits on workstations connected to the host HSM, because authentication is
delivered directly from the hand-held PED to the HSM via the independent, trusted-path interface.
No password is entered via computer keyboard.

The PED Authentication architecture consists of the following components:

1. SafeNet Luna PED: a PIN Entry Device with a local or remote connection to the HSM. The PED
reads authentication secrets from PED keys on behalf of an HSM or partition.
2. Authentication secrets: Cryptographic secrets generated by the HSM and stored on PED keys.
These secrets serve as login credentials for the various roles on the HSM. They can be shared
among roles, HSMs, and partitions according to your security scheme.
3. PED Keys: physical USB-connected devices that contain authentication secrets, created by the
HSM. PED Keys have the following custom authentication features:
a. Shared Secrets: PED keys of the same type can be reused or shared among HSMs or
partitions, allowing domain sharing (necessary for HA and backup configurations),
legacy-style Security Officer authentication, and other custom configurations.
b. PED PINs: optional PINs associated with specific PED keys, set by the owner of the PED
key at the time of creation. PED PINs offer an extra layer of security for PED keys which
could be lost or stolen.
 c. M of N Split Key Scheme: optional configuration which allows a role to split its
authentication secret across multiple PED keys, and require a minimum number of those
keys for authentication. This scheme can be customized to be as simple or complex as
your organization's security policy dictates.

3.1 PED Key Types and Roles

Lifecycle PED Key PED Secret Function

HSM Administration Blue HSM Security Authenticates the HSM SO role. The HSM SO
Officer(HSM SO) manages provisioning activities and security
secret policies for the HSM:

> HSM initialization

> Partition creation and assignment to clients

> HSM policy management

Mandatory

Red HSM Domain or Cryptographically defines the set of HSMs that can
participate in cloning for backup.
Key Cloning Vector
Mandatory

Orange Remote PED Establishes a connection to a Remote PED server.

Vector Optional

Partition Blue Partition Security Authenticates the Partition SO role. The PO

Officer(PO)secret manages provisioning activities and security
Administration policies for the partition: > Partition
initialization

> Crypto Officer/Crypto User role setting

> Partition policy management

 NOTE: If you want the HSM SO to also perform
Partition SO duties, you can use the same blue key to
initialize both roles.

Mandatory

Red Partition Domain or Cryptographically defines the set of partitions that

Key Cloning Vector can participate in cloning for backup or high
availability.

Mandatory

Partition Operation Black Crypto Officer(CO) Authenticates the Crypto Officer role. The CO can
secret perform both cryptographic services and key
management functions on keys within the partition.

Mandatory

Gray Crypto User(CU) Authenticates the Crypto User role. The CU is a

secret read-only role that can perform cryptographic
services using keys already existing within the
partition.

NOTE: If administrative separation is not important,

you can use a single black key to initialize the Crypto
Officer and Crypto User roles and still have two
separate challenge secrets to distinguish read write
and read-only role privileges.

Optional

HSM Auditing White Audit User(AU) Authenticates the Audit Use rrole, responsible for
secret audit log management. This role has no access to
other HSM services.

Optional

3.2 SHARED KEY SECRET

The Luna PED identifies the type of authentication secret on an inserted PED key, and secrets of the
same type (color designation) can be used interchangeably. During the key creation process, you
have the option of reusing an authentication secret from an existing key rather than have the HSM
create a new one. This means that you can use the same PED key(s) to authenticate multiple HSMs
or partitions. This is useful for:

1. legacy-style authentication schemes, where the HSM SO also functions as the owner of
application partitions. This is achieved by using the same blue PED key to initialize the HSM
and some or all of the partitions on the HSM.
2. allowing a single HSM SO to manage multiple HSMs, or a single Partition SO to manage
multiple partitions
3. ensuring that HSMs/partitions share a cloning domain
4. allowing a read-write Crypto Officer role and a read-only Crypto User role to be managed by
the same user
5. It is not necessary for partitions in an HAgroup to share the same blue Partition SO key. Only
the red cloning domain key must be identical between HAgroup members.

NOTE: Using a single PED key secret to authenticate multiple roles, HSMs, or partitions is less secure
than giving each its own PED key.

3.3 Domain PED Keys

A red domain PED key holds the key-cloning vector (the domain identifier) that allows key cloning
between HSMs and partitions, and is therefore the PED key most commonly shared between HSMs
or partitions. Cloning is a secure method of copying cryptographic objects between HSMs and
partitions, required for backup/restore and within HAgroups. It ensures that keys copied between
HSMs or partitions are:

1. strongly encrypted
2. copied only between HSMs and partitions that share a cloning domain.

NOTE: An HSM or partition can be a member of only one domain, decided at initialization. A domain
can only be changed by re-initializing the HSM. Partition domains may not be changed after
initialization.

3.4 PED PIN

The Luna PED allows the holder of a PED key to set a numeric PIN, 4-48 characters long, to be
associated with that PED key. This PIN must then be entered on the PED keypad for all future
authentication. The PED PIN provides two-factor authentication and ensures security in case a key is
lost or stolen. If you forget your PED PIN, it is the same as losing the PED key entirely; you cannot
authenticate the role.
PED PINs can be set only at the time of key creation, and can be changed only by changing the secret
on the PED key. Duplicate keys made at the time of creation can have different PED PINs, allowing
multiple people access to the role. Copies made later are true copies with the same PED PIN,
intended as backups for one person. Duplicates of the PED key all have the same PED PIN.

If you are using an M of N configuration, each member of the M of N keyset may set a different PED
PIN.

CAUTION! Forgetting a PED PIN is equivalent to losing the key entirely; you can no longer
authenticate the role, domain, or RPV.

3.5 M of N Split Secrets

The Luna PED can split an authentication secret among multiple PED keys (up to 16), and require a
minimum number of the split keys to authenticate the role. This provides a customizable layer of
security by requiring multiple trusted people to be present for authentication.

For example, you could decide (or your security policy could dictate) that at least three trusted
people must be present for changes to the HSM policies or for client partition assignments. To
accommodate illness, vacations, business travel, or any other reasons that a key-holder might not be
present at the HSM site, it is advisable to split the authentication secret between more than three
people. If you decide on a five-key split, you would specify M of N for the HSM SO role to be 3 of 5.

In this scenario, the HSM SO authentication secret is split among five blue PED keys, and at least
three of those keys must be presented to the Luna PED to log in as HSM SO.

This feature can be used to customize the level of security and oversight for all actions requiring PED
authentication. You can elect to apply an M of N split-secret scheme to all roles and secrets, some of
them, or none of them. If you do choose to use M of N, you can set different M and N values for
each role or secret. Please note the following recommendations:

1. M = N is not recommended; if one of the key holders is unavailable, you cannot authenticate
the role.
2. M = 1 is not recommended; it is no more secure than if there were no splits of the secret - a
single person can unlock the role without oversight. If you want multiple people to have
access to the role, it is simpler to create multiple copies of the PED key.

NOTE Using an M of N split secret can greatly increase the number of PED keys you require. Ensure
that you have enough blank or rewritable PED keys on hand before you begin backing up your M of
N scheme.
3.6 Activated Partitions and M of N

For security reasons, the HSM and its servers are often kept in a locked facility, and accessed under
specific circumstances, directly or by secure remote channel. To accommodate these security
requirements, the Crypto Officer and Crypto User roles can be Activated (to use a secondary, alpha-
numeric login credential to authenticate), allowing applications to perform cryptographic functions
without having to present a black or gray PED key. In this case, if the HSM is rebooted for
maintenance or loses power due to an outage, the cached PED secret is erased and the role must be
reactivated (by logging in the role via LunaCM and presenting the requisite M number of PED keys)
before normal operations can resume.

3.7 Remote PED

A Remote PED connection allows you to access PED-authenticated HSMs that are kept in a secure
data center or other remote location where physical access is restricted or inconvenient.

This requires a Remote PED server, Remote PED key and a client that needs access to HSM. The
Remote PED server currently only be made a Windows host with USB sockets. These USB sockets will
be used as PED key sockets for authentication.

Initializing the Remote PED Vector (RPV) and Creating the Orange PED Key

1. login as HSM SO. lunash:>hsm login

2. Ensure that you have the orange PED key(s) ready. Initialize the RPV.

lunash:>hsm ped vector init

If you are sure that you wish to initialize remote PED vector (RPV), then enter
'proceed', otherwise type 'quit'.

> proceed

Proceeding...

Luna PED operation required to initialize remote PED key vector - use orange PED
key(s).

3. Attend to the Luna PED and respond to the on-screen prompts.

 a. If you have an orange PED key with an existing RPV that you wish to use for this HSM,
press Yes.
b. If you are creating a new RPV, press No.

Continue following the prompts for PED PIN, M of N, and duplication options.

Perform Operations using Remote PED

1. Download and install Luna Client in Windows

2. Start PED server from cmd <pedserver mode start –ip <IP of System>>
3. Connect/Disconnect to PED server from HSM shell
ssh to hsm and run this

lunash:>hsm ped connect -ip <PED SERVER IP> -port 1503

Command Result : No Error

Issue any command that requires authentication.

lunash:>hsm login

You’ll be prompted to insert Orange key and then HSM SO (Blue) key
To disconnect run this:

lunash:>hsm ped
disconnect

If you are sure that you wish to disconnect, then enter 'proceed',
otherwise type 'quit'. > proceed

Proceeding...
 Command Result : 0 (Success)

4. Connect/Disconnect to PED server from HSM Lunacm

Launch LunaCM on the client. ./lunacm

Initiate the Remote PED connection.
lunacm:> ped connect -ip <PEDserver_IP>

Command Result : No Error

Issue the first command that requires authentication

lunacm:>role login -name po

You’ll be prompted for Orange key and then Blue key.

To disconnect run this:

lunacm:>ped disconnect

If you are sure that you wish to disconnect, then enter 'proceed',
otherwise type 'quit'. > proceed

Proceeding...

Command Result : 0 (Success)

4 PARTITIONS

HSM Partitions are independent logical HSMs that reside within the HSM, or attached to, your host
computer or appliance. Each HSM Partition has its own data, access controls, security policies, and
separate administration access, independent from other HSM partitions. HSM Partitions are
analogous to 'safe deposit boxes' that reside within a bank's 'vault'. The HSM (vault) itself offers an
extremely high level of security for all the contents inside. Each partition (safe deposit box) within
the HSM also has its own security and access controls, so that even though the HSM security officer
(bank manager) has access to the vault, they still cannot open the individual partitions (safe deposit
boxes), because only the owner of the partition (safe deposit box) holds the key that opens it. HSMs
have two types of partitions:

4.1 The Administrative Partition

 Each HSM has a single administrative partition, which is created when the HSM is initialized. The
administrative partition is owned by the HSM security officer (SO). This partition is used by the
HSM SO and Auditor roles and is not normally used to store cryptographic objects.

4.2 Application Partitions

Application partitions are used to store the cryptographic objects used by your applications.
Application partitions have their own partition SO, distinct from the HSM SO.

The HSM SO is responsible for initializing the HSM, setting the HSM-wide policies, and creating
empty application partitions. After the HSM SO creates the partition, complete control of the
application partition is handed off to the partition SO. The HSM SO has no oversight over application
partitions and can do nothing with them except delete them, if required.

The partition SO is responsible for setting the partition policies and for creating the Crypto Officer
and optional Crypto User roles, who use the partition for cryptographic operations. Application
partitions can be assigned to a single client, or multiple clients can be assigned to, and share, a single
application partition.

Use hsm show command to see:

 Total HSM storage

 Current memory usage
 Current number of partitions
 Maximum number of partitions allowed.

Use partition list commandto see:

 All current application partitions

 Total storage allotted to each
 Total used and available storage on each partition

4.3 Creating Partition

1. ssh to HSM
lunash:> hsm login *Continue to plug HSM SO PED (BLUE)
lunash:> partition create -par <name of partition>

2. To list partition is created, lunash:> partition list

Partition is not usable just by creating it, below operations make partition usable.
4.4 Partition Initialization

Partition initialization creates Partition Officer PO (Blue Key) and Cloning Domain (Red
Key).

4.4.1 Initializing Partition

lunacm:>par init -label <any label>
 
You are about to initialize the partition.
All partition objects will be destroyed.
 
Are you sure you wish to continue?
 
Type 'proceed' to continue, or 'quit' to quit now -> proceed
 
Please attend to the PED.

Respond to Luna PED prompts...

Command Result : No Error

Partiiton officer PO needs to change its PED key before it become usable

lunacm:> role login –n po

Note: All PED operations prompted above will be same as initializing HSM. You can use same blue
keys for HSM SO and Partition Officer PO but for better security use different keys for different
partitions and HSM SO.

4.4.2 Change PO password to make it usable

1. First, login as Partition SO.

lunacm:>role login -name Partition SO

Please attend to the PED.

Respond to Luna PED prompts...

Command Result : No Error

2. Now change its password

lunacm:> role changepw –n po

Please attend to the PED.
 Respond to Luna PED prompts...

Command Result : No Error

4.4.3 Initialize the Crypto Officer role

The SO of the application partition can now assign the first operational role within the new
partition. Have a black Crypto Officer PED key ready.

3. First, login as Partition SO. You can also use the shortcut Partition Officer

lunacm:>role login -name po

Please attend to the PED.

Respond to Luna PED prompts...

Command Result : No Error

4. Initialize the Crypto Officer role. You can also use the shortcut co.

lunacm:> role init -name co

Please attend to the PED.

Respond to Luna PED prompts...

Command Result : No Error

5. Logout from CO Role

lunacm:> role logout
4.4.4 Change Crypto Officer password to make it usable

6. First, login as Partition Crypto Officer.

lunacm:>role login -name co

Please attend to the PED.

Respond to Luna PED prompts...

Command Result : No Error

7. Now change its password

lunacm:> role changepw –n co

Please attend to the PED.

Respond to Luna PED prompts...

 Command Result : No Error

4.5 Activation and Auto-activation on PED-Authenticated Partitions

A PED-authenticated partition requires a PED key each time a role (Partition SO, Crypto
Officer, Crypto User) logs in. For some use cases, such as key vaulting, this physical key
requirement is desirable. For many applications, however, it is impractical to require the full
PED interaction every time.

For these use cases, the Partition SO can activate the partition and set a secondary password
referred to as a challenge secret. When a partition is activated, the HSM caches the Crypto
Officer and Crypto User PED secrets upon first login, and subsequent logins require the
challenge secret only. The PED key secret remains cached until the role is explicitly
deactivated or the HSM loses power due to a reboot or power outage.

Activation does not provide much advantage for clients that log in to the partition and remain
logged in. It is an indispensable advantage in cases where the client application repeatedly
logs in to perform a task, and then logs out or closes the cryptographic session after the task
is completed.

Auto-activation

Auto-activation allows PED key credentials to remain cached even in the event of a reboot or
a brief power outage (up to 2 hours).

4.5.1 Enabling Activation on a Partition

The Partition SO can enable activation on a partition by setting partition policy 22: Allow
activation to 1 (on). This setting enables activation for both the Crypto Officer and Crypto
User roles. When partition policy 22 is enabled, the Partition SO can set an initial challenge
secret for the Crypto Officer.

Prerequisites: The partition must be initialized.

To enable activation on a partition

1. Log in to the partition as Partition SO.

lunacm:>role login -name po

2. Enable partition policy 22: Allow activation

lunacm:>partition changepolicy -policy 22 -value 1

Activating a Role

After enabling partition policy 22, activate the CO role on the partition. You must set a PED
challenge password to activate. The role will become activated the first time the user logs in
to the partition.

Prerequisites

 Partition policy 22: Allow activation must be enabled on the partition.

 The role you wish to activate must be initialized on the partition.

To activate a role

1. Login as PO

lunacm:>role login -name po

2. Set an initial challenge secret for the role you wish to activate. The length of the
challenge secret is configurable by the Partition SO. The default range is 7-255
characters.

lunacm:>role createchallenge -name co

You will be prompted for the PED key and Secret to create.

3. Log out of the partition.

lunacm:>role logout

4. Provide the initial challenge secret to the designated CO secure means. The PED secret
will be cached when they log in for the first time. The CO can store the black PED key in
a safe place. The cached PED secret allows their application(s) to open and close sessions
and perform operations within those sessions.

5. Before CO can interact with application, secret must be changed

Luncacm:> role login –n co

lunacm:>role changepw –n co –oldpw <old secret> -newpw <new secret>

Note: This secret will be used by applications to perform crypto operations.

4.5.2 Enabling Auto-activation

Auto-activation allows PED key credentials to be cached even in the event of a reboot or a
brief power outage (up to 2 hours). Clients can re-connect and continue using the application
partition without needing to re-authenticate using a PED key.

The Partition SO can enable auto-activation on a partition by setting partition policy 23:
Allow auto-activation.

Prerequisites: Partition policy 22: Allow activation must be enabled on the partition.

To enable auto-activation on a partition

Log in to the partition as Partition SO

lunacm:>role login -name po

Enable partition policy 23: Allow activation

lunacm:>partition changepolicy -policy 23 -value 1

Auto-activation will take effect for CO the next it is authenticated.

5 HIGH-AVAILABILITY GROUPS

SafeNet Luna HSMs can provide scalability and redundancy for cryptographic applications
that are critical to your organization. For applications that require continuous, uninterruptible
uptime, the SafeNet Luna HSM Client allows you to combine application partitions on
multiple HSMs into a single logical group, known as a High-Availability (HA) group.

5.1 Prerequisites

HA groups are set up in LunaCM by the Crypto Officer. Before the CO can perform this
setup, however, all HSMs and member partitions must meet the following prerequisites,
completed by the HSM and Partition Security Officers.

5.1.1 HSMs

 The HSM SO must ensure that all HSMs containing HA group member partitions
meet the following prerequisites:
  All HSMs must be the same hardware type (a mix of Network and PCIe HSMs is not
supported) and use the same authentication method (Password/PED).

 All HSMs must have the same firmware version installed.

 All must be installed in the same host server that will create the HA group.

5.1.2 Partitions

The Partition SO must ensure that all partitions in an HA group meet the following
prerequisites:

 All partitions must be visible in LunaCM on the host workstation.

 All partitions must be initialized with the same cloning domain (Red Key):

 Partition policies must be consistent across all member partitions.

 The Crypto Officer role on each partition must be initialized with the same CO
credential (Black PED key).

 PED-authenticated partitions must have partition policies 22: Allow activation and
23: Allow auto-activation set to 1. All partitions must be activated and have auto-
activation enabled, so that they can retain their login state after failure/recovery. Each
partition must have the same activation challenge secret.

5.2 To set up an HA group

1. Create a new HA group, specifying the following information

 The group label (do not call the group "HA")

 The Serial number OR the slot number of the first member partition

 The Crypto Officer challenge secret for the partition

lunacm:>hagroup creategroup -label <label> {-slot <slotnum> | -serialnumber

<serialnum>}

lunacm:> hagroup creategroup -label myHAgroup -slot 0

 
Enter the password: ********
 
 New group with label "myHAgroup" created with group number
1154438865287.
Group configuration is:
 
HA Group Label: myHAgroup
HA Group Number: 1154438865287
HA Group Slot ID: Not Available
Synchronization: enabled
Group Members: 154438865287
Needs sync: no
Standby Members: <none>
 
 
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
 
 
Command Result : No Error

LunaCM generates a serial number for the HA group (by adding a "1" before the partition
serial number), assigns it a virtual slot number, and automatically restarts.

lunacm (64-bit) v7.3.0. Copyright (c) 2018 SafeNet. All rights reserved.
 
 
Available HSMs:
 
Slot Id -> 0
Label -> par0
Serial Number -> 154438865287
Model -> LunaSA 7.3.0
Firmware Version -> 7.3.0
Configuration -> Luna User Partition With SO (PW) Key
Export With Cloning Mode
Slot Description -> Net Token Slot
 
Slot Id -> 1
Label -> par1
Serial Number -> 1238700701509
Model -> LunaSA 7.3.0
Firmware Version -> 7.3.0
Configuration -> Luna User Partition With SO (PW) Key
Export With Cloning Mode
Slot Description -> Net Token Slot
 
Slot Id -> 5
HSM Label -> myHAgroup
HSM Serial Number -> 1154438865287
HSM Model -> LunaVirtual
HSM Firmware Version -> 7.3.0
HSM Configuration -> Luna Virtual HSM (PW) Key Export With
Cloning Mode
 HSM Status -> N/A - HA Group
 
 
Current Slot Id: 0

2. Add another partition to the HA group, specifying either the slot or the serial number. If
the new member contains cryptographic objects, you are prompted to decide whether to
replicate the objects within the HA group, or delete them.

lunacm:>hagroup addmember -group <grouplabel> {-slot <slotnum> | -serialnumber

<serialnum>}

lunacm:> hagroup addmember -group myHAgroup -slot 1

 
 
Enter the password: ********
 
 
Warning: There are objects currently on the new member.
Do you wish to propagate these objects within the HA
group, or remove them?
 
Type 'copy' to keep and propagate the existing
objects, 'remove' to remove them before continuing,
or 'quit' to stop adding this new group member.
> copy
 
Member 1238700701509 successfully added to group myHAgroup. New
group
configuration is:
 
HA Group Label: myHAgroup
HA Group Number: 1154438865287
HA Group Slot ID: 5
Synchronization: enabled
Group Members: 154438865287, 1238700701509
Needs sync: no
Standby Members: <none>
 
 
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
1 1238700701509 par1 alive
 
 
Please use the command "ha synchronize" when you are ready
to replicate data between all members of the HA group.
(If you have additional members to add, you may wish to wait
until you have added them before synchronizing to save time by
avoiding multiple synchronizations.)
 
Command Result : No Error
 Repeat this step for each additional HA group member.

3. If you are adding member partitions that already have cryptographic objects stored on
them, initiate a manual synchronization. You can tell whether this step is required by
checking the line Needs Sync : yes/no in the HA group output. This will also confirm
that the HA group is functioning correctly.

lunacm:>hagroup synchronize -group <grouplabel>

5.3 Configuring HA Auto-Recovery

When auto-recovery is enabled, SafeNet Luna HSM Client performs periodic recovery
attempts when it detects a member failure. HA auto-recovery is disabled by default for new
HA groups. To enable it, you must set a maximum number of recovery attempts. You can
also set the frequency of recovery attempts, and the auto-recovery mode (activeBasic or
activeEnhanced). These settings will apply to all HA groups configured on the client.

To configure HA auto-recovery

1. Set the desired number of recovery attempts by specifying the retry count as follows. This
will enable auto-recovery:

 Set a value of 0 to disable HA auto-recovery

 Set a value of -1 for unlimited retries

 Set any specific number of retries from 1 to 500

lunacm:> hagroup retry -count <retries>

lunacm:> hagroup retry -count -1

 
HA Auto Recovery Count has been set to -1
 
Command Result : No Error

2. [Optional] Set the desired frequency of recovery attempts by specifying the time in
seconds. The acceptable range is 60-1200 seconds (default: 60).

lunacm:> hagroup interval -interval <seconds>

lunacm:> hagroup interval -interval 120

 
HA Auto Recovery Interval has been set to 120 seconds.
 
Command Result : No Error
3. [Optional] Set the auto-recovery mode.The default is activeBasic.

lunacm:> hagroup recoverymode -mode {activeBasic | activeEnhanced}

lunacm:> hagroup recoverymode -mode activeEnhanced

 
HA Auto Recovery Mode has been set to activeEnhanced mode.
 
Command Result : No Error

4. [Optional] Check that auto-recovery has been enabled (hagroup listgroups). You are
prompted for the Crypto Officer password/challenge secret.

lunacm:> hagroup listgroups

lunacm:> hagroup listgroups

 
If you would like to see synchronization data for group
myHAgroup,
please enter the password for the group members. Sync info
not available in HA Only mode.
 
Enter the password: ********
 
HA auto recovery: enabled
HA recovery mode: activeEnhanced
Maximum auto recovery retry: infinite
Auto recovery poll interval: 120 seconds
HA logging: disabled
Only Show HA Slots: no

activeBasic - uses a separate Active Recovery Thread to perform background checks of HA

member presence and runs synchronization if a member fails/leaves and then returns to
availability; attempts to reconnect with the members if all members were simultaneously
unavailable. Does not restore existing sessions. Network HSM appliances do not have to
restart, login is manual.

activeEnhanced - works like activeBasic, but additionally restores all sessions and their
login states.

5.4 HA Only Mode

If an HA group member partition fails and is recovered, all visible slot numbers can change,
including the HA group virtual slots. This can cause applications to direct operations to the
wrong slot. If a physical slot in the HA group receives a direct request, the results will not be
replicated on the other partitions in the group. When HA Only mode is enabled, the HA
virtual slots are not affected by partition slot changes. Thales recommends enabling HA Only
mode on all clients running HA groups.

To enable HA Only mode

lunacm:> hagroup haonly -enable

lunacm:> hagroup haonly -enable

 
"HA Only" has been enabled.
 
Command Result : No Error

[Optional] Since LunaCM still displays the partitions, you can check the status of HA Only
mode at any time.

lunacm:> hagroup haonly -show

lunacm:> hagroup haonly -show

 
This system is configured to show only HA slots. (HA Only is
enabled)
 
 
Command Result : No Error

5.5 HSM DR

HSMs can be connected to application in different datacenter to provide DR. Standby members do not
perform any cryptographic operations unless all active members have failed (see Standby Members
for details). They are useful as a last resort against loss of application service.

Prerequisites

The partition you want to designate as a standby member must already be a member of the
HA group. The Crypto Officer must perform this procedure.

To set an HA group member to standby

Check the serial number of the member you wish to set to standby mode.

lunacm:> hagroup listgroups

lunacm:> hagroup listgroups

 
If you would like to see synchronization data for group myHAgroup,
 please enter the password for the group members. Sync info
not available in HA Only mode.
 
Enter the password: ********
 
 
HA auto recovery: disabled
HA recovery mode: activeBasic
Maximum auto recovery retry: 0
Auto recovery poll interval: 60 seconds
HA logging: disabled
Only Show HA Slots: no
 
HA Group Label: myHAgroup
HA Group Number: 11238700701509
HA Group Slot ID: 5
Synchronization: enabled
Group Members: 154438865287, 1238700701509
Needs sync: no
Standby Members: <none>
 
 
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
1 1238700701509 par1 alive
2 2855496365544 par2 alive
 
 
Command Result : No Error

Set the desired member to standby mode by specifying the serial number.

lunacm:> hagroup addstandby -group <label> -serialnumber <member_serialnum>

lunacm:> hagroup addstandby -group myHAgroup -serialnumber 2855496365544

 
The member 2855496365544 was successfully added to the standby list
for the HA Group myHAgroup.
 
 
Command Result : No Error
6 AUDIT LOG

Each event that occurs on the HSM can be recorded in the HSM event log, allowing you to audit your
HSM usage. The HSM event log is viewable and configurable only by the audit user role. This audit
role is disabled by default and must be explicitly enabled.

6.1 Audit Logging Features

The following list summarizes the functionality of the audit logging feature:

 Log entries originate from the SafeNet Luna Network HSM - the feature is implemented via HSM
firmware (rather than in the library) for maximum security.

 Log origin is assured.

 Logs and individual records can be validated by any SafeNet Luna Network HSM that is a
member of the same domain.

 Audit Logging can be performed on password-authenticated (FIPS 140-2 level 2) and PED-
authenticated (FIPS 140-2 level 3) configurations, but these configurations may not validate each
other's logs - see the "same domain" requirement, above.

 Each entry includes the following (No Multitenancy):

o When the event occurred

o Who initiated the event (the authenticated entity)

o What the event was

o The result of the logging event (success, error, etc.)

 Multiple categories of audit logging are supported, configured by the audit role.

 Audit management is a separate role - the role creation does not require the presence or co-
operation of the SafeNet Luna Network HSM SO.

 The category of audit logging is configurable by (and only by) the audit role.

 Audit log integrity is ensured against the following:

o Truncation - erasing part of a log record

o Modification - modifying a log record

o Deletion - erasing of the entire log record

o Addition - writing of a fake log record

 Log origin is assured.

 The following critical events are logged unconditionally, regardless of the state of the audit role
(initialized or not):

o Tamper

o Decommission

o Zeroization

o SO creation

o Audit role creation

6.2 Configure Audit Loging

6.2.1 Configure NTP

lunash:>sysconf timezone set <IANA Format>
lunash:>sysconf ntp enable
lunash:>sysconf ntp addserver <NTPserver>
lunash:>sysconf ntp status
6.2.2 Enable audit user
Log in to LunaSH as an admin-level user, and enable the audit user. The audit user is necessary to
access and work with logs through the LunaSH interface. It is restricted from administrative
functions:
lunash:> user enable -username audit
Initialize the audit role on the HSM. This enables logging for all subsequent actions performed by the
SO and partition user(s):
lunash:> audit init
you are referred to Luna PED, which prompts you for the domain (red PED key) and Audit
authentication (white PED key).

Now that the audit role exists on the HSM, you can configure the auditing function. However, before
you can configure audit logging you must log into the HSM as the audit role:
lunash:> audit login
On PED-authenticated HSMs, you are referred to Luna PED, which prompts for the white PED key for
the audit role.

NOTE You are now logged into the appliance as the audit user and into the HSM (within the
appliance) as the audit role. Both are required. The audit commands, including HSM login as the
audit role do not appear if you are logged in as any other named appliance-level user.
6.2.3 Configuration
Configure audit logging to specify what you want to log. You can specify the level of audit
appropriate for needs of the organization’s policy and the nature of the application(s) using the
HSM:
lunash:> audit config -parameter event -value <event_value>
Note: “all” can be configured to log everything the HSM does. This might be useful in some
circumstances, but will quickly fill up log files.

6.2.4 Log Rotation

Lunash:> audit config -parameter rotation -value <h,d,w,m,n>
h: Hourly

d: Day

w: Week

m: Monthly

n: None

6.2.5 To copy files off the appliance

Create an archive of the logs that are ready to archive:
lunash:> audit log list
lunash:> audit log tarlogs
View a list of the log files currently saved on the appliance:
lunash:>my file list
For this example, assume that the list includes a file named audit.tgz.

On the computer where you wish to capture and store the log files, use scp (Linux) or pscp
(Windows) to transfer the file from the appliance:
/usr/safenet/lunaclient/log:>scp audit@hsm:audit.tgz
mylunsa1_audit_2020-09-26.tgz .
Provide the audit user's credentials when prompted. This copies the identified file from the remote
SafeNet Luna Network HSM's file system (in the audit account) and stores the copy on your local
computer file system with a useful name.

You can view and parse the plain-text portion of the file.

Note: Execute the audit log tarlogs LunaSH command regularly to archive the audit logs and transfer
them to a separate machine for long term storage. Also, execute the audit log clear LunaSH
command regularly to free up the audit log disk space on SafeNet Luna Network HSM.
7 CAVEAT

7.1 How to use lunacm

To use lunacm, NTLS connection must establish between client and HSM.

1 Download and Install luna client

2 Navigate to your Luna Client directory,

”for example: cd /usr/safenet/lunaclient/bin”

3 Generate Client Certificate and scp it to HSM

./vtl createcert –n [CLIENT IPADDR]

scp ..\cert\client\[CLIENT IP ADDR].pem admin@hsm:

4 Get HSM Certificate and add HSM server in client.

scp admin@[LUNA SA IPADDR]:server.pem
 vtl addserver –n [LUNA SA IPADDR] –c server.pem

5 Add Client in HSM and Assign a Partition so lunacm commands may run
SSH to the Luna SA and login as the admin
Run ‘client register –client [NAME] –ip [CLIENT IPADDR]’ to allow access from the client to
the HSM

Run ‘client assignpartition –client [NAME] –partition <partition name>’ to associate the
client with the partition

Run ‘client show –client [NAME]’ to verify the client was created successfully

6 Verify connection using vtl from client directory.

./vtl verify