Tamper Events

SafeNet Luna PCIe HSMs detect hardware anomalies (such as card over-temperature) and physical events (such as card removal or chassis intrusion), and register them as tamper events. A tamper event is considered a security breach, and effectively locks the HSM.

If Policy 48: Do Controlled Tamper Recovery is enabled (the default), the HSM SO must clear the tamper condition before the HSM is reset, to return the HSM to normal operation (see HSM Capabilities and Policies). While the HSM is in the tamper condition, only the subset of LunaCM commands required to view the HSM status or clear the tamper condition are available. For PED-authenticated HSMs, the cached PED key data that allows activation is zeroized, and activation is disabled. When an HSM is in the tamper state, only the HSM SO is able to log in to the HSM.

You can enable Policy 40: Decommission on Tamper to decommission the HSM when a tamper event occurs, so that partitions and roles are deleted from the HSM. By default, Policy 40: Decommission on Tamper is disabled, and the contents of the HSM are not affected by the tamper event.

If both policies are disabled, the HSM sends a warning when a tamper event occurs but does not make partition data inaccessible. We do not recommend disabling both policies.

If both policies are enabled, the HSM SO role is deleted when a tamper event occurs, so you do not need to log in this role to clear the tamper condition.

There are several conditions that can result in a tamper event. The type of tamper event is indicated by the HSM Status field in the output of the LunaCM slot list command. The status also indicates whether the tamper event requires an HSM reset in addition to a tamper clear.

NOTE   A tamper event resets the HSM hardware, including the PCIe logic. This prevents the HSM from reporting any statuses, including the cause of the tamper condition. The only thing which is detected in this case is k7pf0: ALM0015: PCIe Link Failure. The HSM must be rebooted before the cause of the tamper event can be reported.

Tamper event Response
Chassis intrusion (requires chassis connector to card tamper header)

Halt the HSM. Deactivate activated partitions.

Decommission the HSM if policy 40: Decommission on Tamper is enabled.

Card removal

Halt the HSM. Deactivate activated partitions.

Decommission the HSM if policy 40: Decommission on Tamper is enabled.

Over/under temperature

Halt the HSM. Deactivate activated partitions.

Decommission the HSM if policy 40: Decommission on Tamper is enabled.

Warnings are logged for mild over/under temperature events. Warnings are self-clearing if the condition is resolved.

Over/under voltage

Halt the HSM. Deactivate activated partitions.

Decommission the HSM if policy 40: Decommission on Tamper is enabled.

Warnings are logged for mild over/under voltage events. Warnings are self-clearing if the condition is resolved.

Battery removal/depletion

Halt the HSM. Deactivate activated partitions.

Decommission the HSM.

Warnings are logged for low battery conditions.

Recovering from a Tamper Event

How you recover from a tamper event depends on how the following HSM policies are set. See HSM Capabilities and Policies for more information:

Policy 40: Decommission on tamper If enabled, the HSM is decommissioned when a tamper event occurs. You must clear the tamper condition before you can re-initialize the HSM SO, re-create your partitions, restore the partition contents from backup, and re-initialize the partition roles (Partition SO, Crypto Officer, and Crypto User, and Audit, as relevant).
Policy 48: Do Controlled Tamper Recovery If enabled, the tamper condition that halted the HSM must be cleared by the HSM SO (by issuing the tamper clear command), before the HSM can be reset to resume normal operations.

Activation and auto-activation is disabled on tamper

If you are using activation or auto-activation on your PED-authenticated partitions, it is disabled when a tamper is detected, or if any uncleared tamper conditions are detected on reboot. See Activation and Auto-activation on PED-Authenticated Partitions and Partition Capabilities and Policies for more information.

To recover from a tamper

1.View the output of the slot list command (displayed by default on login). The reason for the tamper is indicated by the HSM Status field. You can also use the hsm tampershow command to display the last tamper event.

NOTE   The slot list and hsm tampershow commands only show the last tamper event, even if several tampers have occurred. To view a complete list of the tamper events that have occurred on the HSM, use the lunadiag utility. See lunadiag in the Utilities Guide for more information.

2.Resolve the issue(s) that caused the tamper event.

3.If Policy 48: Do Controlled Tamper Recovery is enabled, clear the tamper condition. Otherwise, go to the next step:

lunacm:> hsm tamperclear

4.If the tamper message indicates that a reset is required, exit LunaCM and use the lunareset command to reset the HSM. See lunareset in the Utilities Reference Guide for more information:

lunareset <device>

5.Verify that all tampers have been cleared:

lunacm:> hsm tampershow

6.If the HSM was decommissioned as a result of the tamper, you must re-create your partitions, re-initialize the partition roles (Partition SO, Crypto Officer, and Crypto User, and Audit as relevant), and restore the partition contents from backup. See the following sections in the Configuration Guide .

a.To re-create your partitions, see Creating an Application Partition on the HSM.

b.Re-initialize the partition roles. See Creating an Application Partition on the HSM.

c.To restore the partition contents from backup, see Backup and Restore.

7.If the Policy 22: Allow Activation and/or Policy 23: Allow AutoActivation are enabled on your PED-authenticated partitions, the CO and CU (if enabled) must log in to reactivate those roles:

lunacm:> role login -name <role>