Comparison of Destruction/Denial Actions

Various operations on the Thales Luna 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.

Event

Event	MTK is destroyed HSM is unavailable, but use/access can be recovered after reboot (See Note 1)	Reset appliance admin password	How to discover (See Note 3)	How to recover
- three bad SO login attempts or - lunash:> hsm zeroize (for Thales Luna Network HSM), lunacm:> hsm zeroize (for Thales Luna PCIe HSM and Thales Luna USB HSM) or - lunash:> hsm factoryReset (for Thales Luna Network HSM), lunacm:> hsm factoryreset (for Thales Luna PCIe HSM and Thales Luna USB HSM) or - any change to a destructive policy or - firmware rollback (See Note 4)	NO	NO	hsm.log entry or "Zeroized: Yes" in HSM Information (from hsm show command)	Restore HSM objects from Backup
hardware tamper - undervoltage or overvoltage during operation or - under-temperature or over-temperature during operation or - chassis interference (such as cover, fans, etc.) OR software (command-initiated) tamper - lunash:> hsm srk transportMode enter or - lunacm:> srk transport	YES	NO	Best practice - have external MTK split on SRK (purple PED Key), which forces administrative intervention to recover from tamper. Otherwise, parse hsm.log 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 hsm.log like: "HSM internal error", "device error" Thales Luna Network HSM appliance front panel flashes error 30.	Reboot [See Note 1]
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 no external split (SRK) of the recovery vector exists (that is, if both portions of the recovery key are available inside the HSM). A destroyed MTK can be recovered if one of the recovery components has been moved outside the HSM onto a secure recovery key (SRK), and that SRK can be presented via Thales Luna PED at the next HSM 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: If an external SRV exists, and you wish to stop using it (having no need for Secure Transport Mode, and no need for enforced administrative response in case of a tamper event), you must bring the external SRV back into the HSM with srk disable command. You may not simply destroy or overwrite the purple PED Key without first ensuring that the HSM is in possession of all the MTK recovery components. 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.

MTK is destroyed
HSM is unavailable,
but use/access
can be recovered
after reboot
(See Note 1)

Reset appliance
admin password

How to discover
(See Note 3)

How to recover

- three bad SO login attempts
or
- lunash:> hsm zeroize (for Thales Luna Network HSM),
lunacm:> hsm zeroize (for Thales Luna PCIe HSM and Thales Luna USB HSM)
or
- lunash:> hsm factoryReset (for Thales Luna Network HSM),
lunacm:> hsm factoryreset (for Thales Luna PCIe HSM and Thales Luna USB HSM)
or
- any change to a destructive policy
or
- firmware rollback
(See Note 4)

hsm.log entry

or
"Zeroized: Yes" in HSM Information (from hsm show command)

Restore HSM objects from Backup

hardware tamper
- undervoltage or overvoltage during operation
or
- under-temperature or over-temperature
during operation
or
- chassis interference (such as cover, fans, etc.)

OR

software (command-initiated) tamper

- lunash:> hsm srk transportMode enter
or
- lunacm:> srk transport

YES

Best practice - have external MTK split on SRK (purple PED Key), which forces administrative intervention to recover from tamper.
Otherwise, parse hsm.log 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 hsm.log like:
"HSM internal error", "device error"

Thales Luna Network HSM appliance front panel flashes error 30.

Reboot
[See Note 1]

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 no external split (SRK) of the recovery vector exists (that is, if both portions of the recovery key are available inside the HSM).
A destroyed MTK can be recovered if one of the recovery components has been moved outside the HSM onto a secure recovery key (SRK), and that SRK can be presented via Thales Luna PED at the next HSM 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: If an external SRV exists, and you wish to stop using it (having no need for Secure Transport Mode, and no need for enforced administrative response in case of a tamper event), you must bring the external SRV back into the HSM with srk disable command. You may not simply destroy or overwrite the purple PED Key without first ensuring that the HSM is in possession of all the MTK recovery components.

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, which can be of either the "soft" or "hard" variety.

•HSM init is soft if you have not performed an hsm factoryReset before hsm init.

•HSM init is hard if it is performed following hsm factoryReset.

Either way, HSM and partition objects are gone, so only a restore from backup can bring them back. Effects of soft versus hard initializations are summarized below :

Condition/Effect	Soft init	Hard init
SO authentication required?	Yes	No
Can set new HSM label	Yes	Yes
Creates new SO identity	No	Yes
Creates new Domain	No	Yes
Destroys partitions	Yes	No (none exist to destroy) *
Destroys SO objects	Yes	No (none exist to destroy) *

* hsm factoryReset was performed, and destroyed partitions and objects, before the hard init... otherwise, it could not be a hard init.