Comparison of Destruction/Denial Actions
Various operations on the SafeNet Luna Network HSM are intended to make HSM contents unavailable to potential intruders. The effect of those actions are summarized and contrasted in the following table, along with notes on how to recognize and how to recover from each scenario.
Scenario 1: MTK is destroyed, HSM is unavailable, but use/access can be recovered after reboot (See Note 1)
Scenario 2: KEK is destroyed (Real-Time Clock and NVRAM), HSM contents cannot be recovered without restore from backup See Note 2)
Scenario 3: Appliance admin password reset
| Event |
Scen. 1 |
Scen. 2 | Scen. 3 | How to discover (See Note 3) |
How to recover |
|---|---|---|---|---|---|
|
>Three bad SO login attempts >
>
>Any change to a destructive policy >Firmware rollback (See Note 4) |
NO | YES | NO |
>Log entry >"HSM IS ZEROIZED" in HSM Details (from hsm show command) |
Restore HSM objects from Backup |
|
Log in to SafeNet Luna Network HSM "recover" account (local serial connection) |
NO | NO | YES | Log entry shows login by "recover" | Log into appliance as admin, using the reset password "PASSWORD" and change to a secure password |
|
Hardware tamper >Undervoltage or overvoltage during operation >Under-temperature or over-temperature during operation >Chassis interference (such as cover, fans, etc.) Software (command-initiated) tamper >lunash:> hsm stm transport |
YES | NO | NO |
Parse logs for text like "tamper", "TVK was corrupted", or "Generating new TVK", indicating that a tamper event was logged. Example: RTC: external tamper latched/ MTK: security function was zeroized on previous tamper event and has not been restored yet Also, keywords in logs like: "HSM internal error", "device error" SafeNet Luna Network HSM appliance front panel flashes error 30. |
Reboot [See Note 1] |
|
Decommission >Pressing the Decommission button on the back of the appliance |
NO | YES | NO |
Look for log entry like: RTC: tamper 2 signal/Zeroizing HSM after decommission...LOG(INFO): POWER-UP LOG DUMP END |
Restore HSM objects from Backup |
|
Note 1: MTK is an independent layer of encryption on HSM contents, to manage tamper and Secure Transport Mode. A destroyed MTK is recovered on next reboot. If MTK cannot be recovered, only restoring from backup onto a new or re-manufactured HSM can retrieve your keys and HSM data. Note 2: KEK is an HSM-wide encryption layer that encrypts all HSM objects, excluding only MTK, RPK, a wrapping key, and a couple of keys used for legacy support. A destroyed KEK cannot be recovered. If the KEK is destroyed, only restoring from backup can retrieve your keys and HSM data. Note 3: To check the health of a remote HSM, script a frequent login to the HSM host and execution of a subset of HSM commands. If a command fails, check the logs for an indication of the cause. Note 4: These actions all create a situation where hsm init is required, or strongly recommended before the HSM is used again. |
|||||
In addition, another event/action that has a destructive component is HSM initialization. See HSM Initialization.
