System Behavior with Hardware Tamper Events
The SafeNet appliance uses the Master Tamper Key (a key on the HSM that encrypts everything on the HSM) to deal with both hardware (physical) tamper events and Secure Transport Mode.
Tampering with the Appliance
Hardware tamper events are detectable events that imply intrusion into the appliance interior.
One such event is removal of the lid (top cover). The lid is secured by anti-tamper screws, so any event that lifts that lid is likely to be a serious intrusion.
Another event that is considered tampering is opening of the bay containing the ventilation fans.
You can use the thumbscrew to access the mesh air filter in front of the fans, without disturbing the system. However, if you open the fan-retaining panel behind that, which requires a Torx #8 screwdriver, then the system registers a tamper.
Therefore, cleaning of the filter is encouraged, especially if you work in a dusty environment, but fan module removal and replacement are discouraged unless you have good reason to suspect that a fan module is faulty. See Power Supply and Fan Maintenance for more information.
Decommission
The red "Decommission" button recessed behind the back panel is not a tamper switch. Its purpose is different. See HSM Emergency Decommission Button for a description.
What Happens When You Tamper - Including Opening the Fan Bay
The following sequence illustrates how a tamper event affects the HSM and your use of it. You do not need to perform all these steps. Many are included for illustrative purposes and to emphasize the state of the appliance and of the enclosed HSM at each stage.
| Action | Result/State |
|---|---|
|
First, we place the HSM in its basic operational condition (we reset only to have a clean starting point for this illustration). |
|
| hsm factoryReset | Starting point |
| hsm initialize | Basic setup of HSM |
|
Next, we illustrate a software "tamper" (destroying the MTK by setting the HSM into Transport Mode) |
|
| stm transport | Enable Secure Transport Mode. |
| hsm show | Basic HSM info remains undisturbed. |
| partition list | None have been created since initialization, above. |
| partition create | Attempt to create a partition - doesn't work; must be logged in as SO. |
| hsm login | No, can't do that either: LUNA_RET_MTK_ZEROIZED |
| stm recover | Log in to the HSM and HSM SO and recover from Secure Transport Mode. Also, the PED presents the Transport Mode verification string. |
| hsm login | This time, it works. |
| partition create |
Partition is created. |
| partition list | Confirm that the created partition is there - you have confirmed that you have successfully set Secure Transport Mode, then recovered from it. The HSM is unusable while in STM, but is fully restored to its previous state when you recover from STM. |
|
Now, we illustrate a hardware tamper (by physically interfering with the appliance as an intruder might do) |
|
| open the fan bay (with a Torx #8 screwdriver) | The HSM stops responding as the vkd (HSM driver) times out [the command-line prompt is still available until you issue a command that attempts to access the HSM, at which point the driver goes into time-out] - the entire system stops responding for approximately ten minutes (you can wait it out, or you can reboot) - the system has detected a tamper event |
|
(system resumes) run sysconf appliance reboot or press the restart [Stop/Start] switch on the back panel |
(If you wait until the system becomes responsive on its own, issue sysconf appliance reboot; if you simply restart with the switch, that's the same thing, but faster.) |
| when the system is back up, run hsm show |
Check for HSM Tampered: Yes or No |
| view the logs |
The audit log shows events like: lunash:>audit log tail -f hsm_150073_00000001.log 133098,13/01/28 14:39:37,S/N 150073 HSM with S/N 150073 logged the following internal event: LOG: resync(0x0000002e) 133099,13/01/28 14:47:15,S/N 150073 HSM with S/N 150073 logged the following internal event: TVK was corrupted.(0x00000027) 133100,13/01/28 14:47:15,S/N 150073 HSM with S/N 150073 logged the following internal event: Existing Auto-Activation data won't work(0x00000029) 133101,13/01/28 14:47:15,S/N 150073 HSM with S/N 150073 logged the following internal event: Generating new TVK...passed(0x0000002a) 133102,13/01/28 14:47:15,S/N 150073 HSM with S/N 150073 logged the following internal event: RESTART(0x0000002f) 133103,13/01/28 14:47:35,S/N 150073 HSM with S/N 150073 logged the following internal event: LOG: resync(0x0000002e) Command Result : 0 (Success) |
| hsm tamper show | WARNING - Tamper(s) Detected |
| hsm login | not permitted: LUNA_RET_MTK_ZEROIZED |
| hsm tamper clear |
Clear the HSM tamper. The HSM SO must be logged in to issue this command. |
| hsm login | This time, it works. |
| partition list | Confirm that the pre-existing partition is present. |
| partition showContents | Confirm that any pre-existing partition contents are there. |
|
|
|
| stm transport | Enter Secure Transport Mode. |
| hsm tamper show | lunash:>hsm tamper show No active tampers. Command Result : 0 (Success) |
| Open the appliance lid, or open the fan bay (opening the lid would damage the chassis and void your warranty, this is for example purposes only) |
The HSM stops responding when you enter an HSM command, or it gives an error message (any of several, depending on what it was doing at the time) and then stops responding. |
Summary of Your Responses to Tamper Events
If you have a password-authenticated HSM, or if you have a PED-authenticated HSM, then both splits of the MTK reside always on the HSM.
The MTK is destroyed by a tamper event, and the HSM becomes unresponsive. When you react to this by rebooting the appliance, the HSM has both splits available and can immediately reconstitute the MTK and go on operating normally, without further intervention from you.
