|
Home > |
|---|
Beginning with firmware 6.22.0, SafeNet HSMs support two modes of ownership of an application partition in the HSM.
•The application partition is entirely owned and controlled by its own Security Officer.
•The HSM SO can create or delete application partitions, but has no ability to see or touch contents.
•The uninitialized partition can be handed off to a person who is not associated with the HSM SO, and who can create the Partition SO identity without assistance from the HSM SO. On a Password-authenticated HSM, this means that the Partition SO can set and manage a partition SO secret that is not known by the HSM SO. On a PED-authenticated HSM, it means that the Partition SO can authenticate to the application with a blue PED Key that is completely unrelated to the blue PED Key used by the HSM SO.
•Only the application Partition SO can create the Crypto Officer. On a Password-authenticated HSM, this is an administrative role with its own text-string secret, but that secret must also be shared with any application that performs creative and destructive crypto operations. On a PED-authenticated HSM, the Crypto Officer authenticates with a black PED Key, and provides a text-string secret that is used by any application that performs creative and destructive crypto operations (like keygen, deletion of keys, etc.).
•Only the Crypto Officer can create the Crypto User. On a Password-authenticated HSM, this is an administrative role with its own text-string secret, but that secret must also be shared with any application that performs read-only crypto operations. On a PED-authenticated HSM, the Crypto User authenticates with a gray PED Key, and provides a text-string secret that is used by any application that performs read-only crypto operations (like sign/verify).
•The application partition's Security Officer is the Security Officer of the HSM (also called the HSM Administrator).
•The HSM SO can create or delete application partitions, and can see the objects in the application partition.
•The HSM SO creates the Crypto Officer (also known as the Partition Owner or User).
•The HSM SO creates the Crypto User, if desired.
The Legacy option is the default, and is the way SafeNet HSMs have worked in the past. This option applies for new, and for upgraded HSMs until you install firmware 6.22.0 or newer, and install the PPSO Capability Update. That is, if you do not update the HSM firmware, and do not also install the PPSO Capability Update, then your HSM works as previously.
The PPSO functionality requires new "role" commands in Lunacm. Those commands are not visible if the HSM firmware version is earlier than 6.22.0. Some of those commands are visible if you update the firmware to version 6.22.0 or newer, but most do not become functional until you also apply the PPSO Capability Update.
The PPSO feature is very useful if you have need of it, but is not for everyone.
Note: Terminology note -- "Partitions" refer to virtual HSMs within the physical HSM; "slots" refer to PCKS#11 cryptographic slots. SafeNet Shell (lunash) on the SafeNet Network HSM considers application partitions as partitions when they are created, and as partitions when they are used. The client-side lunacm (on computers running SafeNet HSM Client software) considers application partitions as partitions when they are created, and as slots when they are managed and when they are used by customer applications. The terminology might switch back and forth depending on which point of view is indicated, but they are all HSM partitions - logically and cryptographically insulated, and generally independent (with some caveats), virtual HSMs.
•PPSO is a building block to support multi-tenant HSM services, where, for example, multiple PKCS#11 slots can be used and managed by different organizations accessing one SafeNet Network HSM.
•Separation of roles is enhanced by separating management of application partitions from management of the overall HSM.
•Secure logging is done at the whole HSM level. Currently, there is no per-slot audit logging ability.
•The PPSO capability is applied at the whole HSM level. Only policies (not capabilities) can be changed on a per-slot (per-partition) basis. For example, you cannot mix Password-authenticated (a.k.a. FIPS2) and PED-authenticated (a.k.a. FIPS3) partitions/slots on the same SafeNet Network HSM.
•RPED (Remote PED) applies to the whole HSM. All partition owners/slot-holders share the same RPV (Remote PED Vector, or orange PED Key). If one slot owner changes the RPV, all other slot owners are no longer able to make the Remote PED connection.
•Most HSM commands are parallelized, which means that PED operations on one partition do not interfere with crypto operations on any other partition on the same HSM. As well, operations on the same partition tend not to interfere. Some exceptions exist, such as Delete operations, which must lock objects while the operation occurs.
•The Partition SO cannot be added to any pre-existing slots. A customer who has created the maximum number of partitions afforded by the currently applied license must either delete some partitions or purchase a larger license CUF (Capability Update File or Secure Package).
•The ability to create partitions with their own SOs (PPSO) adds some overhead to partition structure. Because the partition overhead is part of the user storage space, customer might need to shrink the storage usage per partition (by deleting some objects) in order to upgrade to firmware 6.22.0 or newer.
•The Audit role is destroyed by factory reset. The HSM administrator (or HSM SO) can issue the factoryReset . This means that the auditor is at the mercy of HSM SO even though he is supposed to audit the HSM SO activities as well.
•All partitions, pre-existing or new, will have HSM generated serial numbers once the HSM is upgraded to firmware 6.22.0 (or newer). Customer's existing applications or administrative tools/procedures might need to be adjusted accordingly.
•Slot enumeration changes (see Slot Numbering and Behavior).