Every Luna HSM has a Master Tamper Key (MTK) that strongly encrypts all sensitive data generated and stored within the HSM. While the master tamper key remains valid, the HSM uses it to decrypt HSM contents in order to perform cryptographic operations. The master tamper key is unique for each HSM.
When the master tamper key is created, two splits of that secret are stored in separate locations within the HSM.
A tamper event erases the HSM's master tamper key, making the HSM unusable and its contents inaccessible.That is, all contents remain encrypted and the HSM cannot use the master tamper key to decrypt them while the master tamper key does not exist.
The master tamper key can be reconstituted from the two splits for resumption of HSM operation.
The scenarios are:
a) the two splits remain inside the HSM, and the HSM can use them to immediately recover the master key
b) one of the splits remains inside the HSM, but the other is moved out to an external device; the HSM cannot recover the HSM's master key until the external split is re-introduced into the HSM via the PED.
The MTK is NOT, in any sense, any kind of "device master key". Its purpose is to implement the tamper behavior and the related Secure Transport Mode. If someone managed to get the MTK for an HSM, they have nothing really usable. All HSM contents are further encrypted by additional layers of authentication and other strong encryption, as described elsewhere in these documents.
"Purple PED Keys, Tamper, and Secure Transport" for additional information about purple key handling and unique properties.
If a tamper event occurs, the event is logged and the HSM stops responding. A restart is required in order to resume. The master key is reconstituted from its component splits and re-validated, making the HSM usable again. The event is recorded in the log.
The intent is to make you aware that a tamper has occurred (the log gets an entry, and the HSM waits for a restart) but not to cause ongoing inconvenience.
That scenario applies to Password-authenticated HSMs, as well as to PED-authenticated HSMs that do not have the purple SRK option invoked - both splits of the master key remain inside the HSM.
[myluna] lunash:>hsm srk show
| Secure Recovery State flags: =============================== |
|
| External split enabled: | no |
| SRK resplit required: | no |
| Hardware tampered: | no |
| Transport mode: | no |
Command Result : 0 (Success)
[myluna] lunash:>
Some operational environments require more rigorous response to a tamper event. Your operational and security policy might require that, in addition to logging a tamper event, the HSM must stop performing until you take authoritative action to confirm your acknowledgement and clear the tamper before operations can resume.
PED-authenticated HSMs have the option to store a split of the master key, called the Secure Recovery Vector (SRV) outside of the HSM on a physical device, the Secure Recovery Key (SRK). The situation is , but one split of the master key is imprinted onto a purple PED Key (or Keys, if you choose M of N), the SRK, and not inside the HSM. In that case, the master key component stored inside the HSM is insufficient to reconstitute the master key without the portion stored externally on the purple key(s).
[myluna] lunash:>hsm srk show
| Secure Recovery State flags: =============================== |
|
| External split enabled: | yes |
| SRK resplit required: | no |
| Hardware tampered: | no |
| Transport mode: | no |
Command Result : 0 (Success)
[myluna] lunash:>
Where the purple PED Key has been invoked, a tamper event invalidates the master key, but the HSM cannot immediately re-validate because not enough splits are available. You must invoke the Luna Shell command hsm srk transportMode recover, and present the purple PED Key (or Keys) when prompted. The PED reads the purple key(s) and provides the missing piece ( the SRV) to the HSM. The HSM combines the provided external component with the internal component and reconstitutes and validates the master key. You can resume using the HSM with no loss of crypto objects.
If SRK is enabled (meaning a split of the MTK has been moved off of the HSM, onto a purple PED Key), and you have lost or destroyed the purple PED Key, then you cannot bring the HSM back from tamper or Secure Transport Mode. Your only option is to return the HSM to SafeNet for re-manufacturing.
However, you CAN run hsm factoryReset (from a local console connection), if your security policies require active destruction of HSM objects before it leaves your possession.
When the HSM is returned to you, after re-manufacture, it has a new MTK as if it was a new HSM, so even a copy of the old purple PED Key would be of no use to an unauthorized person. You can freshly initialize the re-manufactured HSM using your existing Domain PED Key, so that you can recover objects from one of your backups onto the re-manufactured HSM.
If your practice is:
a) to configure and prepare your HSMs at a central location before shipping them out to remote locations in your organization,
or
b) to configure and prepare your HSMs at a central location before shipping them out to your customers,
then you can invoke an enhanced security option for shipping.
By switching on Secure Transport Mode (STM), you effectively create a controlled tamper event. The HSM can be shipped in a condition that is completely unusable by anyone who might intercept it if they are not in possession of the unique SRK for that HSM. At the destination, the purple PED Key is used to reconstitute the Secure Recovery Vector, and the MTK is recovered. Your recipient begins using the HSM, with your loaded keys and certificates intact, secure in the knowledge that the HSM has not been attacked in transit.
[myluna] lunash:>hsm srk show
| Secure Recovery State flags: =============================== |
|
| External split enabled: | yes |
| SRK resplit required: | no |
| Hardware tampered: | no |
| Transport mode: | yes |
Command Result : 0 (Success)
[myluna] lunash:>
As a service for customers who request it, SafeNet can invoke Secure Transport Mode at our factory. Your HSM is shipped in anti-tamper packaging via a trusted courier. Meanwhile, the unique purple key is shipped via a separate channel, so that the two are never available together in transit. As a further precaution, we send you the verification code via yet another path. In this way, you enjoy the maximum possible assurance that your HSM has not been attacked between our facility and yours.
Similarly, if your organization ships HSMs to your customers, you can offer them the same service, with new unique purple (SRK) keys generated at each stage, if desired.
In the event that a Luna HSM appliance has been shipped to you, in Secure Transport Mode, and you have recovered from Transport Mode, OR you have decided to invoke Transport Mode to store or ship your HSM, you might wish to generate a unique, new SRK split onto a purple PED Key. That is, the existing MTK is split in two again (different splits than previous) and one new split replaces the internally stored component while the other new split us stored on a new purple PED Key (or keys).
Use the Luna Shell command hsm srk keys resplit and have a different purple key ready for imprinting.
The existing SRK is needed to validate the operation, but the HSM will not overwrite that purple key with the new split. This is a safety measure, in case the operation was interrupted before completion. If that happens, the old SRK remains valid and the HSM can still be used while you begin the re-split operation again. Once the re-split is successful, with a new SRK on a new purple key, the old purple key is of no further interest because its .
For example, when we (SafeNet) ship an appliance in Secure Transport Mode, we make just the one purple key that we ship to you, unless requested otherwise by you. We think that we are trustworthy, but your security auditors might be required by policy or regulation to assume otherwise. For this reason, you can perform hsm srk keys resplit as soon as you receive your HSM, and it would not matter if we had kept additional copies of your purple key. They would be rendered useless by the re-splitting operation on your HSM.
Similarly, your customers can do the same once they receive an HSM in Secure Tranport Mode from you.
If your application requires that you ship securely, but retain control of the HSM appliances, you can use the Remote PED option to retain all PED Keys (including the purple) and use them from your location when operating the remotely located HSM.
You can perform a re-splitting operation only if the HSM's master key is currently valid. That is, for security reasons, you cannot generate a new split and new purple key while an HSM is tampered and not recovered, or while an HSM is in Secure Transport Mode and not recovered. This prevents anyone not in possession of the correct purple PED Key from circumventing the HSM "lock-out" due to tamper or to STM.
If the purple SRK is lost, and you do not have a backup of it, then you must obtain an RMA and return the HSM to SafeNet for re-manufacture; any objects that existed on the HSM are lost, unless you have backups. For Luna SA, some customers might prefer the additional assurance of pressing the red factory reset button on the back of the appliance, before shipping. For Luna PCI-E, the equivalent action is shorting/shunting the two pins of the reset header (Tamper 2) on the HSM card, near the battery.
If SRK has been enabled (one of the HSM's master key splits has been moved to an external purple PED Key), you can choose to disable the feature.
To do so, you must provide the appropriate purple SRK(s) when you run the command hsm srk disable, so that the external split can be read back into a secure internal location.
From that point on, the HSM behaves in the same way as a password-authenticated HSM with respect to tamper events:
a) a real tamper event is merely noted in the log and does not hamper HSM operation (beyond requiring restart and re-login)
b) Secure Transport Mode is not possible (until SRK is re-enabled).
View a table that compares and contrasts various "deny access" events or actions that are sometimes confused - "Comparison of destruction/denial actions".