|
Home > |
Appliance Administration Guide > Appliance Hardware Functions > 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.
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.
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.
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) |
|
| hsm srk enable | Move one split of the MTK out of the HSM, and onto a purple PED Key, so the MTK cannot be reconstituted until/unless the external split (SRK) is presented. |
| hsm srk transportMode enter | Delete the MTK so HSM contents cannot be decoded or used. |
| 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 |
| hsm srk transportMode recover | Present the correct purple PED Key when prompted by the PED; the SRV is read into the HSM, allowing the MTK to be reconstituted, and making the HSM contents available/usable once more. 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 (like hsm srk show) 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 srk show |
[myluna1] lunash:>hsm srk show Secure Recovery State flags:
================================ |
| view the logs |
The hsm.log shows events like: ERR: RTC: external tamper latched Many lines of logging occur when the HSM restarts, so it is necessary to specify more than the default 20 lines at the end of the log when you issue: syslog tail - logname hsm Try searching the last couple of hundred entries with: syslog tail -logname hsm -search tamper -e 200
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) lunash:> |
| hsm srk show | External Split Enabled ......... yes SRK resplit required ..............no Hardware Tampered .............yes Transport Mode ....................no |
| hsm login | not permitted: LUNA_RET_MTK_ZEROIZED |
| hsm srk transportMode recover |
Present the correct purple PED Key when prompted by the PED. THIS (above) IS HOW YOU RECOVER FROM A PHYSICAL TAMPER EVENT. |
| 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. |
|
|
|
| hsm srk transportMode enter | Delete the MTK so HSM contents cannot be decoded or used. |
| hsm srk show | External Split Enabled ......... Yes SRK resplit required ..............No Hardware Tampered .............No Transport Mode ....................Yes |
| 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. |
|
|
|
| hsm srk disable | If you already had the SRK split out to a purple PED Key, this command brings it back in, so that both splits of the MTK reside inside the HSM. |
| hsm srk show |
Confirm that SRK is no longer in use. hsm srk show
Command Result : 0 (Success) |
| open the fan bay to induce a tamper event | Nothing obvious happens, until the front-panel LCD text gets to the part of the sequence where it can display "HSM Error". |
| run an HSM command |
[myluna1] lunash:>hsm show Appliance Details: The HSM is no longer responsive. |
| reboot by pressing the Stop/Start switch or by "sysconf appliance reboot" |
Appliance stops. Appliance starts. |
| when appliance is back in operation, look at the hsm.log |
[myluna1] lunash:>syslog tail -logname hsm -search tamper -e 200 2010 Nov 9 14:50:34 myluna1 local6 err oamp[2239]: Command Result : 0 (Success) Command Result : 0 (Success)
The tamper event appears in the log, after the system reboots. |
|
run "hsm show" and "syslog tail " to search the hsm log for recent tamper events |
lunash:>hsm show Appliance Details:
HSM Details:
Partitions created on HSM:
FIPS 140-2 Operation:
HSM Storage Information:
Command Result : 0 (Success)
The HSM is back in operation, as it was before the tamper event. Both splits of the MTK were present on the HSM, so recombining them You are alerted that an event has happened by the HSM becoming You can confirm that the reason for the HSM problem was, in fact, [myluna1] lunash:>syslog tail -logname hsm -search tamper -e 200 2012 Nov 9 14:50:34 myluna1 local6 err oamp[2239]: ERR: RTC: external tamper latched
Command Result : 0 (Success) Command Result : 0 (Success)
The tamper event appears in the log after the system reboots.
|
| Carry on using the HSM and its partitions. | |
Here is an example of hsm.log file entries following a tamper event. We performed several tampers over the space of a few minutes.
[myluna1] lunash:>syslog tail -logname hsm -search tamper -e 200
2012 Nov 4 14:21:18 GA1 local6 err oamp[2240]: ERR: RTC: external tamper latched
2012 Nov 4 14:21:18 GA1 local6 info oamp[2240]: INFO: RTC: tamper timestamp = 222861 min (YYYY:MM:DD:hh:mm:ss = 0000:06:03:18:21:18.00)
2012 Nov 4 14:21:18 GA1 local6 info oamp[2240]: INFO: RTC: tamper circuits re-armed
2012 Nov 4 14:21:18 GA1 local6 err oamp[2240]: ERR: TVK was lost due to tamper
2012 Nov 4 14:21:18 GA1 local6 err oamp[2240]: ERR: MTK: security function was zeroized on previous tamper event and has not been restored yet
2012 Nov 4 14:36:28 GA1 local6 err oamp[2239]: ERR: RTC: tamper 2 signal
2012 Nov 4 14:36:28 GA1 local6 info oamp[2239]: INFO: RTC: tamper timestamp = 222881 min (YYYY:MM:DD:hh:mm:ss = 0000:06:03:18:41:00.00)
2012 Nov 4 14:36:28 GA1 local6 info oamp[2239]: INFO: RTC: tamper circuits re-armed
2012 Nov 4 14:36:28 GA1 local6 err oamp[2239]: ERR: TVK was lost due to tamper
2012 Nov 4 14:44:35 GA1 local6 err oamp[2245]: ERR: RTC: tamper 2 signal
2012 Nov 4 14:44:35 GA1 local6 info oamp[2245]: INFO: RTC: tamper timestamp = 222888 min (YYYY:MM:DD:hh:mm:ss = 0000:06:03:18:48:44.00)
2012 Nov 4 14:44:35 GA1 local6 info oamp[2245]: INFO: RTC: tamper circuits re-armed
2012 Nov 4 14:44:35 GA1 local6 err oamp[2245]: ERR: TVK was lost due to tamper
Command Result : 0 (Success)
[myluna1] lunash:>
As you can see, the search returns with several lines containing the keyword "tamper".
Note: if you run just 'syslog tail - logname hsm' without specifying a greater number of entries, the default is to show merely the last 20 lines of the file, which is usually insufficient to see if a tamper event has been recorded. Similarly, if you run 'syslog tail - logname hsm -search tamper', the search is run only on the default 'tail' sample. Not enough entries.
The Audit user is not able to view the hsm.log file.The audit user can view the audit logs which will contain similar event records, with different formatting.
To view a table that compares and contrasts various "deny access" events or actions that are sometimes confused, see Comparison of Destruction/Denial Actionsin the Administration Guide.
If you have a password-authenticated HSM, or if you have a PED-authenticated HSM that does not have the SRK stored externally, 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.
You can verify that the problem was actually a tamper by viewing the hsm.log.
If you have a PED-authenticated HSM that does have the SRK stored externally, then only one split of the MTK resides 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 looks for both splits and must prompt you to supply the missing one from the purple PED Key, in order to reconstitute the MTK and go on operating normally. That is the additional intervention needed from you.
You can verify that the problem was actually a tamper by viewing the hsm.log.