|
Home > |
|---|
Comparison Summary
Various operations on the Luna PCI-E HSM are intended to make HSM contents unavailable to potential intruders. The effect of those actions are summarized and contrasted in the following table.
| Event |
MTK is destroyed (inside a specialized integrated circuit called the 3120) HSM is unavailable, but |
KEK is destroyed HSM contents can |
|---|---|---|
|
- three bad HSM Adminstrator / SO login attempts - lunash:> hsm factoryReset |
NO | YES |
| - hardware tamper or - lunacm:> srk transport |
YES | NO |
| decommission (*) |
NO | YES |
(*) Decommission means electrically bridging the decommission header pins on the Luna PCI-E card - normally this would be used only if you installed the HSM in a server that brought the electrical connection of those pins out to an external momentary-contact switch (as is done on Luna SA).
In addition, another event/action that has a destructive component is HSM initialization, which can be of either the "soft" or "hard" variety. Init is soft if you have not performed an hsm factoryReset before hsm init. Init is hard if it is performed following hsm factoryReset. Effects of soft versus hard initializations are summarized below - either way, HSM and partition objects are gone:
| Condition/Effect |
Soft init |
Hard init |
|---|---|---|
| SO authentication required? | Yes | No |
| Can set new HSM label | Yes | Yes |
| Creates new SO identity | No | Yes |
| Creates new Domain | No | Yes |
| Destroys partitions | Yes | No (none exist to destroy) * |
| Destroys SO objects | Yes | No (none exist to destroy) * |
* hsm factoryReset was performed, and destroyed partitions and objects, before the hard init... otherwise, it could not be a hard init.