Layered Encryption

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 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

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 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 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.

Scalable Key Storage (SKS)   

Beginning at firmware 7.7.0, the concept and feature of Scalable Key Storage is introduced. Where, prior to 7.7.0 all application partitions were of one type, now partitions are either:

>version zero (V0) partitions that continue to support the cloning model described above (also referred to as "Keys in Hardware"), and

>version one (V1) partitions that support cloning only for the SKS Master Key (SMK), while all other backup/restore and HA operations involve keys and objects being exported and imported as encrypted binary large objects (blobs), while otherwise remaining securely encrypted in external storage.

The SMK secures all stored keys and objects within the security envelope of the HSM, even when they reside in offboard storage because,

>the keys and objects are securely encrypted with the SMK, when not in use inside the HSM, and

>the SMK is secured by the traditional "keys in hardware" cloning/security domain, and can be copied only to another HSM or partition that shares the specific cloning/security domain.

The cloning (or security) domain is set by the partition SO and does not change for the life of the partition.

The choice of partition type:

•V0 (traditional cloning for protected movement of keys and objects), or

•V1 (enables PKA and SKS features and uses cloning only for the SMK)

is made by the HSM SO at partition creation.

HA replication and synchronization, that traditionally used cloning, transparently use a combination of SMK cloning and SKS extract/insert operations when V1 partitions are involved.