Home >

Appliance Administration Guide > Appliance Hardware Functions > System Behavior with Hardware Tamper Events

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)

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: ================================
External split enabled:...yes 
SRK resplit required:.... no 
Hardware tampered:........yes
Transport mode:..........                                no

Command Result : 0 (Success) [myluna1] lunash:>

view the logs

The hsm.log shows events like:

ERR: RTC: external tamper latched
and
TVK was lost due to tamper
and
RTC: tamper 2 signal
and
ERR: MTK: security function was zeroized for unknown reason

These are all indications from various modules that a tamper event has occurred. They are visible after the system is restarted - the tamper event itself occurs too quickly to be recorded at the time, so it is noted when the HSM goes through its start-up sequence after system reboot.

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   


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)

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.
The SRV is read into the HSM, allowing the MTK to be reconstituted,
and making the HSM contents available/usable once more.
Because this was a physical tamper, and not a deliberate setting of Transport Mode,
the PED does NOT present the Transport Mode verification string.

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.


Next, we illustrate what happens when a physical tamper occurs while the HSM is already in Secure Transport Mode

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.
   


What if you have disabled external storage of one of the MTK splits (the SRK), and a tamper occurs?

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
Secure Recovery State flags: ===============================
External split enabled: .......no
SRK resplit required: .........no
Hardware tampered: ..........no
Transport mode: ............... no

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:
 ==================
 Software Version: 5.1.0-25
Error: Unable to communicate with HSM.
Please run 'hsm supportInfo' and contact customer support.

Command Result : 65535 (Luna Shell execution)
[myluna1] lunash:>

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]:
  ERR: RTC: external tamper latched
2010 Nov 9 14:50:34 myluna1 local6 info oamp[2239]:
  INFO: RTC: tamper timestamp = 230143 min
  (YYYY:MM:DD:hh:mm:ss = 0000:06:08:19:43:28.00)
2012 Nov 9 14:50:34 myluna1 local6 info oamp[2239]:
  INFO: RTC: tamper circuits re-armed 2012 Nov 9 14:50:34
  myluna1 local6 err oamp[2239]: ERR: TVK was lost due to tamper

Command Result : 0 (Success)
[myluna1] lunash:>hsm srk show
Secure Recovery State flags:
=================================
External split enabled: .. no
 SRK resplit required: .... no
 Hardware tampered: ........no
 Transport mode: .......... no

Command Result : 0 (Success)
[myluna1] lunash:>

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:
==================
Software Version: 5.1.0-25

HSM Details:
============
HSM Label: myhsm
Serial #: 700027
Firmware: 6.2.1
Hardware Model: Luna K6
Authentication Method: PED keys
HSM Admin login status: Not Logged In
HSM Admin login attempts left: 3 before HSM zeroization!
RPV Initialized: No
Manually Zeroized: No

Partitions created on HSM:
==========================
Partition: 700027008, Name: mypar1

FIPS 140-2 Operation:
=====================
The HSM is NOT in FIPS 140-2 approved operation mode.

HSM Storage Information:
========================
Maximum HSM Storage Space (Bytes): 2097152
Space In Use (Bytes): 104857
Free Space Left (Bytes): 1992295

Command Result : 0 (Success)
[myluna1] lunash:>

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
to reconstitute the MTK was automatic when the HSM was reset.
No action is required to re-instate the HSM from the tamper.

You are alerted that an event has happened by the HSM becoming
unresponsive, forcing you to restart.

You can confirm that the reason for the HSM problem was, in fact,
a tamper event, by looking at the log.

[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
2010 Nov 9 14:50:34 myluna1 local6 info oamp[2239]: INFO: RTC: tamper timestamp = 230143 min (YYYY:MM:DD:hh:mm:ss = 0000:06:08:19:43:28.00)
2012 Nov 9 14:50:34 myluna1 local6 info oamp[2239]: INFO: RTC: tamper circuits re-armed 2012 Nov 9 14:50:34 myluna1 local6 err oamp[2239]: ERR: TVK was lost due to tamper

Command Result : 0 (Success)
[myluna1] lunash:>hsm srk show
Secure Recovery State flags:
=================================
External split enabled: .. no
SRK resplit required: .... no
Hardware tampered: ........no
Transport mode: .......... no

Command Result : 0 (Success)
[myluna1] lunash:>

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.

Summary of Your Responses to Tamper Events

With No SRK

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.

With SRK on Purple PED Key

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.