This topic describes what to do if you wish to invoke Secure Transport Mode (STM) on a local Luna SA HSM, when shipping the appliance:
This page applies to PED Authenticated HSMs only. It does not apply to Password Authenticated HSMs.
As well, you could use STM for securely storing the HSM, where "transport" would take place simply into, and later out of, your warehouse or vault. However, you would also need to manage separate secure storage and handling of the imprinted purple PED Key (SRK) for that HSM until it was time to recover the HSM and return it to service.
Perform backups of your partitions before you continue with Secure Transport Mode procedure ( "Backup your HSM Partition Locally" ).
This section describes the procedure if you are performing all the actions locally - that is, if your Luna PED is connected directly to the Luna SA appliance when you invoke STM.
This procedure performs a new split of the HSM's master key and creates a new external split (SRV) to be
.Have available:
Perform the SRK enable operation, and enter Secure Transport Mode now:
(* For simplicity, this procedure assumes that you choose Mvalue and Nvalue as "1" in order to have a single imprinted purple key. You can choose other values for M and N, to split the SRV across multiple purple PED Keys. Similarly, you are also given the opportunity to make a copy of the purple SRK - or of the MofN group of purple PED Keys if you elected to use MofN. Your choices in these matters are dictated by convenience and by your security policies.)
At the new location, unpack the appliance and connect it to power, network, and PED.
You should also have available the PED Keys for that HSM, including the purple PED Key (*) that you received by separate shipment, as well as the verification string.
You can now use the HSM's blue PED Key to log in and administer the HSM, and black PED Keys to activate partitions for clients to access.
(*If you invoked MofN when creating the SRK, you must provide quantity M of the purple keys containing the SRV splits.)
This section describes the same procedure if SRK was previously enabled, and you wish to re-use the existing purple PED Key. This might be the case if you know that the most recent re-split of the master key was performed by your organization.
Have available:
Perform the SRK enable operation, and enter Secure Transport Mode now:
(* For simplicity, this procedure assumes that you choose Mvalue and Nvalue as "1" in order to have a single imprinted purple key. You can choose other values for M and N, to split the SRV across multiple purple PED Keys. Similarly, you are also given the opportunity to make a copy of the purple SRK - or of the MofN group of purple PED Keys if you elected to use MofN. Your choices in these matters are dictated by convenience and by your security policies.)
Re-split?
You do not need to re-split if you have recently created a new purple PED Key for this HSM (as happens when you hsm srk enable), or if you have maintained rigorous records and are confident that your purple PED Key has not been compromised.
To be absolutely sure, we recommend that you perform a re-split before placing the HSM in Secure Transport Mode, unless your procedures require that you use an existing purple PED Key.
Number of purple keys
The basic procedures above suggest that you need either one or two purple PED Keys.
However, choices that you can make while interacting with the Luna PED could require several additional purple keys.
Copies?
During every imprinting transaction, the PED asks if you wish to copy the inserted PED Key. Therefore, ensure that you have enough spare/blank keys ready for the number of copies that you expect to make (examples: alternate key holder, on-site stored back-up, off-site back-up/escrow).
MofN?
At the beginning of an imprinting operation, the PED asks for values of "M" and "N". This is for "MofN" split-secret multi-user (or multi-part) authentication, explained elsewhere in this manual ( "About M of N" ). If you input "1" for both "M" and "N", then MofN is not in operation, and only the single (in this case purple) PED Key is needed to carry the authentication secret. But if you specify numbers higher than "1", then the PED splits the secret and imprints the splits onto quantity N different keys. Later, any operation that calls for that secret will need quantity M of those splits to be re-united (presented to the PED upon demand). Thus you must have quantity "N" spare/blank keys ready if you intend to invoke MofN.
Copies and MofN?
Furthermore, you might wish to combine the two scenarios above - in most situations it is prudent to have a backup of any authentication device, against loss or damage. If that is your policy, and if you intend to invoke MofN, then you will need enough spare/blank keys to make at least two full MofN sets of the SRK (purple PED Key(s)). In that case, be careful not to mix the copy sets. If you chose MofN as 3 of 5, then the 5 keys get 5 different splits of the purple-key secret. When you later need to present the secret, you need 3 different splits. If the sets are accidentally mixed, you could have three key holders standing at the PED, but with two of their keys being duplicate splits - the PED refuses to accept what it sees as the same key twice when recreating an MofN secret. To avoid the possibility of inadvertently mixing copies and originals, one option is to simply choose a small "M" and a large "N", and not make copies. For example, if you chose M=3 and N=15, you could arbitrarily select three groups of five splits and use them as though the split was "3 of 5". That is, you could distribute 5 of the 15 splits to operations personnel, so that any three of them could authenticate to the HSM. You could keep another 5 of the 15 splits in on-site lockup as on-site backup, and you could keep the third group of 5 of the 15 splits as your off-site backup. In that case, you avoid the possibility of accidentally mixing copied smaller groups, which could result in two or three of the same split in one group - which the PED would reject.
View a table that compares and contrasts various "deny access" events or actions that are sometimes confused ( "Comparison of destruction/denial actions" ).