Scalable Key Storage (SKS)

What is Scalable Key Storage?

Scalable Key Storage (or SKS) is virtually unlimited secure storage and handling of your sensitive keys.

By default, keys have resided in HSM hardware for Luna HSMs. This remains true, by default, with the introduction of HSM firmware 7.7.0. However, firmware 7.7.0 (and newer) adds key export flexibility to expand the Luna HSM's assurance boundary, to encompass much greater numbers of keys than the internal capacity of an HSM.

Keys secure anywhere, the SKS eIDAS model

Beginning with firmware 7.7.0, all partitions created with the Version 1 (V1) option use Scalable Key Storage (SKS). When a partition is created, it is given a unique SKS Master Key (SMK). SMKs can be cloned from partition to partition, within or across HSMs, or to-and-from Backup HSMs. Other keys and crypto objects are not cloned (for backup/restore, HA, etc.) and instead are encrypted by the SMK for extraction / insertion operations. Again, this applies to V1 partitions. ( See What are "pre-firmware 7.7.0", and V0, and V1 partitions? )

SKS is based upon a model where keys generated on the HSM are securely extracted as encrypted SKS objects and inserted back into the HSM when cryptographic operations are to be performed with those keys. Similarly, when a unique key encrypts data, the data and the key can be stored as an encrypted binary large object (blob) up to 64KB in size, that can be decrypted only within the HSM. This means that any applications that interact with the HSM must be ‘SKS aware’ and use the SKS API functions to work with SKS objects.

If the HSM is upgraded from an earlier HSM firmware version to firmware 7.7.0 or newer, then any existing partitions become version zero (V0). Similarly, if you create a new partition on a firmware 7.7.0 (or newer) HSM, with the default "-version 0" option, it becomes a V0 partition. A V0 partition retains compatibility with older partitions and applications that rely on cloning (secure copying/moving of objects between HSMs or HSM partitions or Backup HSMs, also known as Keys Always in Hardware) while benefiting from fixes and security updates that come with the new firmware, but with no access to the newer eIDAS-mandated features.

If you create a new partition in an HSM with firmware 7.7.0 or newer, and select the V1 option ("-version 1"), then the new partition is version one (V1) and gets a unique SMK and uses SKS (rather than cloning) to replicate keys for HA or to Backup and Restore. The partition also engages Per Key Authorization and other eIDAS related features, but is incompatible with V0. You can also update a V0 partition to V1 while retaining existing objects, but not the direction.

NOTE If you have updated an HSM, with existing partitions, from pre-7.7.0 firmware to firmware 7.7.0 or newer, then

>your existing partitions become version zero (V0),

>your content is preserved,

>your applications function with those partitions as they always did, and

>HA replication and backup/restore operations are accomplished with cloning.

When creating new partitions on an upgraded HSM, the default is to invoke V0 as well, and such new partitions will work just like your old partitions with your applications and processes. These will enjoy the fixes and security updates that come with the newer firmware, but will not have access to the features that require V1.

You do not need anything on the pages in this SKS section until you

•convert an existing V0 partition to V1 or

•create new version one (V1) partitions

which will be using the new cloning protocol and Scalable Key Storage (SKS).

Here is what you will find in the pages of this section:

What is Scalable Key Storage?

When to use SKS (Use Cases)

The SKS model - how it works

•How does SKS work?

•Limitation and scalability

Characteristics of the SKS Implementation

•Characteristics and Implementation Notes