|
Home > |
|---|
Gemalto SafeNet HSMs are hardware security modules designed to protect critical cryptographic keys and to accelerate sensitive cryptographic operations across a wide range of security applications. All SafeNet HSMs enable separation of roles by distinguishing between the HSM Security officer space (an administrative function) and the application Partition or User space, where client keys and objects are secured, and where client-invoked cryptographic operations take place. SafeNet HSMs fall into three categories:
•SafeNet PCI-E HSM is a card-type HSM that installs into the PCIe slot(s) of a host computer. Multiple SafeNet PCI-E HSMs can coexist in one host system. Each SafeNet PCI-E HSM supports one HSM partition.
•SafeNet USB HSM is a desktop HSM unit that connects locally to a host computer via USB interface. Multiple SafeNet USB HSMs can be linked via USB connection. Each SafeNet USB HSM supports one HSM partition.
•SafeNet Network HSM is a self-contained, network attached HSM appliance, containing an HSM card similar to SafeNet PCI-E HSM, and normally resides in an equipment rack in a server room (often of the "lights off", unattended variety), and is accessed remotely via secure administrative and client links. Each SafeNet Network HSM supports multiple HSM partitions, the number governed by purchased licenses.
An HSM is a Hardware Security Module. It has storage, cryptographic, and access-control functions, that allow cryptographic operations to be performed and segregated within a secure physical hardware boundary, while offloading such functions from the general-purpose pathways of the host or client. Here are basic elements common to SafeNet HSMs:
SafeNet HSMs can contain both volatile and non-volatile data.
• Non-volatile data includes identification parameters and data objects (such as keys and certificates) that you wish to store for long-term re-use. Those objects persist on the HSM until you explicitly destroy or overwrite them. Non-volatile objects are encrypted.
•Volatile data is any data that should not persist when it is not in use. Volatile (or session) data disappears when the HSM loses power, or when a session closes. Volatile data includes decrypted copies of non-volatile objects.
Keys and objects are stored under multiple layers of encryption (see HSM General Authentication Model), and are decrypted within the physical bounds of the HSM, only into volatile/session storage, and only while being used. Any event that removes power to the HSM instantly erases volatile objects.
SafeNet HSMs must be initialized before you can use them for the first time (or after an event that zeroizes the HSM, like too many consecutive failed login attempts on the Security Officer (SO) account).
Initialization establishes several HSM parameters, including identification and authentication of HSM Administrator or Security Officer (SO) and application Partition Crypto Officer and Crypto User who then have access to create and use HSM/Partition objects (keys, certificates, encrypted data, etc.).
Many applications from PKI and other cryptographic product vendors do not include the capability to initialize a SafeNet HSM, so SafeNet supplies the Lunacm utility program on all supported platforms, to perform that function and other maintenance functions.
Once a SafeNet HSM is initialized, no one can access it unless they provide the passwords or keys that unlock that specific HSM or Partition.
You can re-initialize a SafeNet HSM at any time (as SO). Re-initialization destroys all data on the HSM.
SafeNet HSMs are factory configured to be either:
•Password authenticated - uses typed text strings to access the HSM and authenticate to all roles on the HSM; advantage, greater convenience.
•PED authenticated - uses physical tokens, called PED Keys, mediated by a PIN Entry Device, or PED, to access the HSM and authenticate to all roles on the HSM; advantage, greater security.
An HSM in the field cannot be changed from Password-authenticated to PED-authenticated, or from PED-authenticated to Password-authenticated. The only exception is the SafeNet Backup HSM, which configures itself at the time of a backup operation, to match the authentication scheme of the HSM being backed up - the Backup HSM performs Backup and Restore only, and has no ability to perform cryptographic operations
SafeNet HSM architecture includes several elements that allow or enforce separation of roles and functions.
The HSM Administrator or Security Officer (SO) presides over administrative tasks and responsibilities that affect the entire HSM. Those tasks include:
•setting policies that control all aspects of the HSM
•creating separate spaces for everyday cryptographic operations by your client applications
•creating and managing other roles and major functions
One of those functions is to create a defined, virtual HSM within the HSM, called an application partition for client objects (keys, certificates, etc.) and cryptographic operations. Until recently, that application partition was created by the HSM SO (a.k.a. "Administrator"), and remained under the control of the HSM SO, who then delegated daily operations to a Partition Owner or Crypto Officer, who might, in turn delegate read-only operations to a Crypto User entity.
The SafeNet USB HSM and SafeNet PCI-E HSM products support one application partition, each.
The SafeNet Network HSM appliance product supports multiple application partitions per HSM, with appropriate licensing.
The approach described above (sometimes referred to as 'legacy-type' partition configuration in these documents), where any application partition is owned by the HSM SO, is still available for customers who are accustomed to it and wish to continue with that scheme.
Beginning with HSM firmware 6.22.0, with the Per-Partition SO capability applied, the HSM SO has the option to create an application partition with its own Security Officer. Once it is created, the partition is handed over completely to its new owner (the Partition SO) and the HSM SO has no further contact with it or control over it, except to delete it from the HSM at some future time if that becomes necessary.
The PPSO approach (see Ownership of Application Partitions) provides more emphatic separation of client cryptographic operations from overall HSM management. A PPSO partition is created empty. The Partition SO creates his/her own role by first initializing the application partition from within. The Partition SO fine-tunes the environment within the application partition by adjusting partition-specific policy settings, then creates the Crypto Officer role, and hands that responsibility to another person. This keeps management and operational tasks separate within the application partition, which in turn is untouched by the HSM SO.
This approach applies separately to multiple application partitions on an HSM that supports more than one application partition. Each such partition is private from the others, and from the HSM SO.
A role like HSM SO or Partition SO authenticates to the HSM or to a partition, gaining access to objects within by temporarily opening a layer of encryption until logout occurs, or the current session closes.
A cloning domain is a secret applied to an HSM or to an application partition, whereby secure copying of HSM or partition objects can take place only to/from another HSM or partition that has the same domain applied. If two containers have different cloning domains and a cloning operation is attempted, it simply fails when that decryption is attempted. The cloning domain governs backup-restore operations, and HA synchronization.
The MTK is an internal HSM key that encrypts almost every object on the HSM, and which is destroyed when a hardware tamper event (physical intrusion, or excursion beyond acceptable environmental parameters) or a software tamper event occurs. Two components of that key are kept in separate locations and can reconstitute the MTK to allow recovery from tamper. The SRK is an external holder for one of those components, that allows the bearer to control the manner and timing of official response to a tamper event.
The Remote PED vector is one of the few items not encrypted under the MTK, and allows the secure connection of a SafeNet PED device (see About Remote PED) to the HSM, from a remote location.
The Auditor is a role whose only purpose is to manage the HSM's audit logs, outside the control of any other entity.
Each of the above roles and functional secrets can be held by different persons in your organization, for the maximum separation of roles and activities with respect to the HSM. Alternatively, one person could be assigned more than one role (and given the authentication for each) if that conforms to your organization's security policy.
The product name "Luna" was taken from the name of the SafeNet moth, to conform with the originating company name "Chrysalis-ITS". The company name was derived from the hidden or secret existence of the moth as it developed within its cocoon, or the chrysalis. This was evocative of the hidden world of cryptography. Other moth names were considered for additional product lines, but the "Luna" brand very quickly achieved marketplace recognition and efforts were aligned under that brand.
After years of growing success with the SafeNet brand in the cryptographic marketplace, Chrysalis-ITS was acquired by SafeNet. Because the brand was well recognized and respected in the HSM marketplace, SafeNet maintained it.
Our SNMP MIB is still called CHRYSALIS.