Security in Operation
This section addresses actions and settings with security-related implications.
>Security Effects of Administrative Actions
Refer also to Security of Your Partition Challenge.
Tamper Events
Luna PCIe HSM 7 detects hardware anomalies (such as card over-temperature)
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
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 lunacm:> slot list. 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 |
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
To recover from a tamper
1.View the output of lunacm:> slot list (displayed by default on login). The reason for the tamper is indicated by the HSM Status field. You can also use lunacm:> hsm tampershow 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.
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 utility to reset the HSM.
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. Refer to the following procedures:
a.To re-create your partitions, see Creating or Deleting an Application Partition.
b.Re-initialize the partition roles. See Initializing an Application Partition.
c.To restore the partition contents from backup, see Partition Backup and Restore.
7.If the Policy 22: Allow Activation and/or Policy 23: Allow AutoActivation are enabled on your multifactor quorum-authenticated partitions, the CO and CU (if enabled) must log in to reactivate those roles:
lunacm:> role login -name <role>
Security Effects of Administrative Actions
Actions that you take, in the course of administering your Luna HSM, can have effects, including destruction, on the roles, the spaces, and the contents of your HSM and its application partition(s). It is important to be aware of such consequences before taking action.
Overt Security Actions
Some actions in the administration of the HSM, or of an application partition, are explicitly intended to adjust specific security aspects of the HSM or partition. Examples are:
>Changing a password
>Modifying a policy to make a password or other attribute more stringent than the original setting
Those are discussed in their own sections.
Actions with Security- and Content-Affecting Outcomes
Other administrative events have security repercussions as included effects of the primary action, which could have other intent. Some examples are:
>HSM factory reset
>HSM zeroization
>Change of a destructive policy
>HSM initialization
>HSM firmware rollback
>Application partition initialization
This table lists some major administrative actions that can be performed on the HSM, and compares relevant security-related effects. Use the information in this table to help decide if your contemplated action is appropriate in current circumstances, or if additional preparation (such as backup of partition content, collection of audit data) would be prudent before continuing.
Factory Reset HSM
| Domain | Destroyed |
| HSM SO Role | Destroyed |
| Partition SO Role | Destroyed |
| Auditor Role | Destroyed |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | HSM/Destroyed |
| HSM Policies | Reset |
| RPV | Destroyed |
|
Messaging |
You are about to factory reset the HSM. All contents of the HSM will be destroyed. HSM policies will be reset and the remote PED vector will be erased. |
Zeroize HSM
| Domain | Destroyed |
| HSM SO Role | Destroyed |
| Partition SO Role | Destroyed |
| Auditor Role | Unchanged |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | HSM/Destroyed |
| HSM Policies | Unchanged |
| RPV | Unchanged |
|
Messaging |
You are about to zeroize the HSM. All contents of the HSM will be destroyed. HSM policies, remote PED vector and Auditor left unchanged. |
Change Destructive HSM Policy
| Domain | Unchanged |
| HSM SO Role | Unchanged |
| Partition SO Role | Destroyed |
| Auditor Role | Unchanged |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | HSM/Destroyed |
| HSM Policies | Unchanged except for new policy |
| RPV | Unchanged |
|
Messaging |
You are about to change a destructive HSM policy. All partitions of the HSM will be destroyed. |
HSM Initialize When Zeroized (hard init)
| Domain | Destroyed |
| HSM SO Role | Destroyed |
| Partition SO Role | Destroyed |
| Auditor Role | Unchanged |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | HSM/Destroyed |
| HSM Policies | Unchanged |
| RPV | Unchanged |
|
Messaging |
You are about to initialize the HSM. All contents of the HSM will be destroyed. |
HSM Initialize From Non-Zeroized State (soft init)
| Domain | Unchanged |
| HSM SO Role | Unchanged |
| Partition SO Role | Destroyed |
| Auditor Role | Unchanged |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | HSM/Destroyed |
| HSM Policies | Unchanged |
| RPV | Unchanged |
|
Messaging |
You are about to initialize the HSM that is already initialized. All partitions of the HSM will be destroyed. You are required to provide the current SO password. |
HSM Firmware Rollback
| Domain | Destroyed |
| HSM SO Role | Destroyed |
| Partition SO Role | Destroyed |
| Auditor Role | Destroyed |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | HSM/Destroyed |
| HSM Policies | Unchanged |
| RPV | Unchanged |
|
Messaging |
WARNING: This operation will rollback your HSM to the previous firmware version !!! (1) This is a destructive operation. (2) You will lose all your partitions. (3) You may lose some capabilities. (4) You must re-initialize the HSM. (5) If the PED use is remote, you must re-connect it. |
Partition Initialize When Zeroized (hard init)
| Domain | Unchanged |
| HSM SO Role | Unchanged |
| Partition SO Role | Destroyed |
| Auditor Role | Unchanged |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | Partition/Destroyed |
| HSM Policies | Unchanged |
| RPV | Unchanged |
|
Messaging |
You are about to initialize the partition. All contents of the partition will be destroyed. |
Partition Initialize From Non-Zeroized State (soft init)
| Domain | Unchanged |
| HSM SO Role | Unchanged |
| Partition SO Role | Destroyed |
| Auditor Role | Unchanged |
| Partition Roles | Destroyed |
| HSM or Partition/Contents | Partition/Destroyed |
| HSM Policies | Unchanged |
| RPV | Unchanged |
|
Messaging |
You are about to initialize the partition that is already initialized. All contents of the partition will be destroyed. You are required to provide the current Partition SO password. |
Elsewhere
Certain other actions can sometimes cause collateral changes to the HSM, like firmware update. They usually do not affect contents, unless a partition is full and the action changes the size of partitions or changes the amount of space-per-partition that is taken by overhead/infrastructure. These are discussed elsewhere.
