Layered Encryption
SafeNet Luna HSMs do not keep any objects in the clear. All objects are encrypted by multiple layers, and are fully decrypted in temporary (volatile) memory only when needed.
Hierarchy of Protection
One general storage key (GSK), for the HSM, protects general storage objects that might be needed by various roles. A separate user storage key (USK), for each role, protects the contents of the partition accessed by that role. The hierarchy of protection, depicted in HSM Layered Encryption, applies to each individual role. The USK for each role on the HSM encrypts objects that are owned by that role, ensuring that each person sees and touches only what belongs to them. Every SafeNet Luna HSM has a master tamper key (MTK) that strongly encrypts each object generated and stored within the HSM.
The key encryption key (KEK) further encrypts every key being used to ensure that your keys are never shown in plaintext.
Three-Layer Authentication Model
The SafeNet Luna Network HSM, and access to data stored on the Cryptographic Engine contained within it, is protected by a number of different means to provide in-depth security. The SafeNet Luna Network HSM’s three-layer authentication model includes separate HSM partition authentication, 2-way network authentication, and process level application authentication to respectively control administrative, client, and application access. This three-layer model, coupled with multi-level user authentication policies, integrated FIPS 140-2 Level 3-validated Cryptographic Engine, and secure software and hardware design, allows the SafeNet Luna Network HSM to offer the same high degree of security and performance as traditional HSMs without sacrificing the flexibility of a network-attached device.
Figure 1: HSM Layered Encryption
When the HSM is powered on, all stored objects are still tightly encrypted. When an object is decrypted for use, the decrypted version exists in volatile memory, only while being used, and only while the HSM has power.
1.KEK is unique to each HSM, and encrypts everything that is encrypted by the PinKey.
2.During login, KEK and PinKey decryptions are performed.
•For password-authenticated HSMs, the PinKey is the HSM SO password (or Partition SO, or CO or CU or Auditor, depending on who is logging in).
•For PED-authenticated HSMs, the PinKey is the secret retrieved from the correct blue SO PED key (or black or gray or white, depending on who is logging in).
At this point, objects are partially decrypted, but still under further levels of encryption (see next steps).
3.GSK encrypts all general-storage objects, while USK encrypts all security and user objects for the role logged into the HSM. Objects are decrypted (into volatile memory) individually when needed.
4.At the lowest level, MTK encrypts all objects.
5.Some objects are fully decrypted in volatile memory only when in use. Others, including ECDSA with NIST Prime curves, AES, DES3, and RSA keys remain MTK-encrypted. Once decrypted and accessible, objects inside the HSM can be used. If power is lost or a tamper occurs, all temporarily decrypted objects instantly evaporate, and stored objects remain tightly encrypted as always.
The in-depth application of multiple layers of security at all levels of the interface to SafeNet Luna HSMs and their internal HSMs provides a high degree of confidence that cryptographic material within the HSM will not be compromised. Customers with extremely demanding security requirements can enhance the already strong security of SafeNet Luna HSMs by choosing appropriate installation, HSM configuration, and policy options.
Cloning Domain or Security Domain
Every HSM or partition is part of a security domain, set at initialization time. This is also called a cloning domain, because objects under such a domain can be securly copied (cloned) only to other HSMs or partitions that share that exact domain.
Multiple HSMs or partitions can be set to be part of the same cloning domain or different ones. Key material cannot leave its cloning domain, so if an attacker were to try to copy your cryptographic material to a device that does not share a cloning domain with your HSM or partition, they would be unsuccessful. Using cloning domains ensures that key material can travel only between trusted and authorized devices. This adds a strong layer of defense against attackers.
NOTE The security or cloning domain is not the lowest encryption level, so a cloning operation does not provide access to Crypto material.
Operations that use cloning are limited to backup, restore and synchronizing the HSMs in HA groups ( among HSMs that share the same domain). Only the backup operation imposes a source-partition domain on the target partition within the Backup HSM; the restore operation and the HA synchronization both require that the source and target HSMs or partitions must already have matching domains.
