Scalable Key Storage
Scalable Key Storage (SKS) is virtually unlimited secure storage and handling of your sensitive keys.
By default, Luna HSMs have always stored keys in the HSM hardware. SKS expands the HSM's assurance boundary to a securely encrypted database, allowing you to store many more keys than would be possible in HSM hardware. All V1 partitions use SKS (see V0 and V1 Partitions). With SKS, keys generated on the application partition are encrypted with an SKS Master Key (SMK), securely extracted to a database for storage, and inserted back onto the partition to perform cryptographic operations. When a unique key encrypts data, the key and data can be stored as an encrypted binary large object (blob), up to 64 KB in size, that can be decrypted only on the partition. Luna HSM Client provides an SKS API so that your applications can use V1 partitions to work with SKS objects.
This section contains the following information about SKS:
The SKS Model
Various models exist for handling large numbers of sensitive keys and objects:
>Wrap-off/wrap-on: Keys and objects can have unknown, uncontrolled origin, outside the assurance boundary. They can be accessed outside the HSM, made available and used externally, in potentially unsafe environments. It is possible to strip security attributes from keys.
>SKS extract/insert: The history of keys and objects is known, controlled, and auditable. They remain within the security and access envelope of the HSM. The master key never exists outside a Luna HSM, and all extracted keys and objects must be inserted back into the HSM at time of decryption and use. Keys always retain their attributes.
In an SKS model, in compliance with relevant standards, an application maintains thousands or millions of encrypted objects as records in a repository (such as a database, file system, cloud storage, etc). The repository might have each record/object encrypted with a unique key. Examples of applications include Remote Signing identities (Common Criteria PP 419221-5 use case). The SKS model provides the following assurances:
>encryption and decryption of objects take place within the HSM
>more individual object-encryption keys are needed by the application than can be accommodated by the internal capacity of any HSM
>records or objects, and the keys that encrypt them, do not exist in-the-clear - both the record (data object, ID, etc.) and its encrypting key are stored in encrypted form
>keys that encrypt objects or signatures originate within the assurance boundary and are only ever decrypted within the assurance boundary
>objects extracted from a current-version HSM cannot be inserted into older version HSMs with known vulnerabilities
A key is created in an HSM partition at the direction of an application. It might be intended as an ID for signing documents and verifying by private persons, or for sealing of documents and records by organizations. It might be intended to encrypt records stored in an external database (customer-identifying records, medical records, supply-chain information, or other information that requires privacy and controlled access). Each key is encrypted for extraction by an extraction/insertion key, derived (in compliance with NIST SP800-108) from the SKS Master Key (SMK), a master encryption key that never leaves the HSM partition. From the application's perspective, the data record or key is extracted from the partiton uniquely encrypted as a secure SKS blob, which can be securely stored anywhere.
Because the SKS objects are stored outside the HSM and individually inserted back into the HSM partition for use, there is no capacity limitation. The only limitation on scalability is the number of SKS operations that can be performed simultaneously (SKS object creation/extract/insert, and resulting cryptographic operations).
An application might use the SKS API to perform any of the following actions:
>create an identity or a record or data object
>acquire a suitable key for encrypting that record or data object, by:
•request a new object-encryption key be generated by the HSM
•provide an already existing object-encryption-key for the HSM to use
>encrypt that ID or object with the new SKS key, or the pre-existing SKS key, which must first be inserted and decrypted for use by the HSM
>store the encrypted record or key within the repository
>retrieve the encrypted record or key
>insert/decrypt the SKS blob into the HSM, using the SKS Master Key (SMK)
>use the decrypted key to:
•sign or seal documents or transactions in the case of RSS
•further decrypt a database record for reading or editing, re-encrypt the record if it changed, and send the re-encrypted record back to storage
>delete / destroy the material from the HSM, once it is not needed (the encrypted SKS blob still exists in the external repository, for the next time it is required)
The application is responsible for storing the SKS object in the repository of choice (database, file system, directory, NAS, cloud, etc.) and retrieving it.
It is possible to create data objects to store any kind of data in an HSM partition, SKS blobs included (which is essentially what is done if you choose to archive SKS objects in a Backup HSM), but that is not the ideal workflow. Instead, a practical workflow is assumed to include backing up SMKs, but not SKS blobs, since the latter are already securely encrypted and can be stored anywhere that is reasonably secure, and in quantity far greater than the capacity of any HSM. However, we cannot anticipate all use-cases, so the onboard storage option exists.
Optionally, such as in the case of Trust Service Providers, during the SKS object creation process, authentication can be added such that a password must be provided before the keys in an SKS object can be used. SKS objects use 256-bit AES-GCM encryption for confidentiality and integrity protection. SHA-512 is also used for further integrity protection. The cryptographic mechanisms employed by SKS comply with the FIPS 140-2 and PP 419221-5 standards (Secure External Scalable Key Storage Extensions). The SKS mechanism complies with the per-key authorization requirements of Common Criteria PP 419221-5 (Per-Key Authorization).
When to use SKS
Use SKS when you need to handle greater numbers of keys and objects than can be stored within the HSM, and you want to employ methods more secure than wrap-off / wrap-on. SKS is required to comply with a regulatory regime like eIDAS.
Any application where large numbers of very sensitive keys or records must be protected with the highest possible security, while remaining available and accessible to authorized users and applications, is a candidate for the Luna HSM with Scalable Key Storage.
A general use case for SKS is storing encrypted keys in external databases.
1.Generate keys inside the HSM
2.Using the SIMExtract API, extract the encrypted keys and store them in external databases and delete the original keys inside the HSM.
3.Insert individual encrypted keys back into the HSM when you need to use them for cryptographic operations inside the HSM.
One example might be the creation and use of electronic signatures (for natural persons) or electronic seals (for organizations) for remote signing (RSS). The signatures or seal key materials are created within the HSM, extracted (not wrapped) in strongly encrypted form that preserves attributes, and stored in a repository. When they are needed, they are found in the repository by the managing system, inserted into the HSM for decryption by a master key that never resides outside an HSM, then used for signing or sealing respectively, and discarded from the HSM (the encrypted versions remain stored in the repository for the next time they are needed).
Another example might be a database of customers, with their contact and shipping information, credit-card information, history of purchases, current/recent browse interests on your commerce site, etc. All of that is likely to be sensitive information protected by regulations and by your own published privacy policies. In this case, the primary concern is privacy of data.
A third example might be a government database of land ownership, including detailed and official property descriptions, current ownership with identifying details, history of title transfers, subdivisions, legal rulings and encumbrances (such as rights of way and covenants), liens, and so on. In this case, the data is meant to be publicly viewable, but its integrity against unauthorized change is paramount.
SKS Master Key Types
Each SKS-capable partition supports four unique SMKs, each with its own location and limitations within the partition:
>Primary SMK: Generated on a V0 or V1 partition at creation, or replaced with a primary SMK from another partition using lunacm:> partition smkclone. The Primary SMK is used for object extraction and insertion operations.
>Rollover SMK: When you generate a new primary SMK, the old primary is referred to as the rollover SMK, and temporarily stored in its own location on the partition. This allows all SKS blobs that were encrypted/extracted with the old SMK to be brought back into the partition, decrypted, and re-encrypted with the new primary SMK. When the rollover operation is complete, the rollover SMK is deleted and only the new primary SMK remains. See Changing the SMK.
>FM SMK: This SMK is not used on the Luna USB HSM 7.
>Firmware 6 SMK: This SMK is imported from a Luna HSM using firmware version 6.x, for the purposes of migrating SKS blobs from a legacy Luna 6 HSM. After the migrated blobs are inserted and decrypted, the cryptographic objects are encrypted with the primary SMK and extracted as Luna 7 SKS blobs. Whenever a partition is on the receiving end of a partition smkclone operation, any contents of the primary and non-primary locations from the source partition overwrite their equivalent locations in the target partition.
High Availability and SKS
SKS supports high availability configurations similar to the Luna HSM cloning model (see High-Availability Groups), with some minor differences. High availability and load balancing is implemented in the Luna HSM Client software and is completely transparent to the application, in that the application is configured to use a virtual slot and not a physical slot on the HSM.
In HA groups using SKS, lunacm:> hagroup addmember clones the SMK from the primary HA member to each additional member as it is added.
One difference, from cloning HSMs in HA configuration is that, for SKS HA, the hagroup addmember command clones the SMK from the initial SKS application partition to all other group member partitions as they are added. Thereafter, your application deals with the HA virtual slot, and HA operation is automatic.
NOTE V1 partitions: If you add an application partition with an existing SMK to an HA group, the primary member's SMK overwrites the existing SMK of the joining partition.
If a partition's SMK has ever been used to encrypt important SKS objects, save a backup of the SMK before adding that partition to any HA group.
To perform a cryptographic operation, the application calls the SKS API to import an SKS blob into the HSM. In an HA group with HA synchronization enabled, Luna HSM Client replicates the imported blob to all member partitions by performing sksExtract on the source partition and sksInsert on the target partition, combined into a single operation and repeated for each HA group member. When the application requests a cryptographic operation from the HA virtual slot, Luna HSM Client load-balances requests among the group member partitions. The SKS operation succeeds because all partitions in the HA group have a copy of the imported SKS object.
NOTE HA failover is not supported in the case of member failure during a SIMInsert, SIMExtract, or SIMMultisign operation.
TIP If your primary use-case is to insert a key and use it for one signing operation, consider using the multisign API for better HA group performance. This allows you to use the key on only one HA member partition, and prevent unnecessary replication to the other members. If this will be the main function of your HA group, disable HA synchronization to prevent keys from being unnecessarily cloned to other members.
If inserted keys are likely to be used for multiple load-balanced operations, then the overhead of replicating to all members is unavoidable and would be minimal in that context.
Backup/Restore and SKS
For most SKS implementations, only the SKS Master Key (SMK) is stored on the application partition. Cryptographic objects are stored as blobs in a database, encrypted by the SMK. Therefore, backup operations performed on a V1 partition include the SMK only by default. If you decide to store persistent SKS blobs on the partition, these are included in backup/restore operations, unless you include the -smkonly option. SKS backup and restore procedures are the same as standard backup/restore (see Partition Backup and Restore).
Using SKS
This section describes prerequisites for using SKS on a Luna USB HSM 7 application partition, and provides example workflows using the API and the ckdemo utility.
Prerequisites
>You require at least one initialized V1 application partition available as a slot in LunaCM (see Initializing the Application Partition).
>The Crypto Officer role must be initialized (see Initializing the Crypto Officer Role). The SMK is created when the CO logs in to the partition for the first time.
NOTE For security reasons, the SMK is not visible in the output of commands that show objects on an HSM partition (lunacm:> partition contents).
>Back up the SMK to a Luna Backup HSM (see Partition Backup and Restore). This is highly recommended, since the loss of the SMK for any reason results in all cryptographic objects encrypted by the SMK becoming unrecoverable.
Using SKS with the PKCS#11 API
Authorization forms currently supported are none, and password.
Export a key from a partition as an SMK-encrypted blob, using SIMExtract function. You can extract all key objects within a given partition by specifying an empty list on the input. Otherwise, specify only individual objects that you wish to extract at one time.
SIM_AUTH_FORMS = (CKA_SIM_NO_AUTHORIZATION, CKA_SIM_PASSWORD) CK_RV CA_SIMExtract(CK_ULONG handleCount, CK_ULONG *handleList, CK_ULONG authForm, CK_ULONG authDataCount, CK_ULONG subsetRequired, CK_BYTE **authDataList, CK_BOOL deleteAfterExtract, CK_ULONG *pBlobSize, CK_BYTE *pBlob );
Import a previously extracted blob, using the SIMInsert function
CK_RV SIMInsert( CK_ULONG blobSize, CK_BYTE *pBlob, CK_ULONG authForm, CK_ULONG authDataCount, CK_BYTE **authDataList, CK_ULONG *pHandleListSize, CK_ULONG *pHandleList );
Refer to the SDK Guide (Secure External Scalable Key Storage Extensions).
Workflow Example Using ckdemo
This example uses the ckdemo utility to guide you through a possible SKS workflow.
1.Start by running ckdemo and executing:
a.Open Session (1) to the slot
b.Login (3) as Crypto Officer. Enter the partition password.
2.Generate an AES key using Simple Generate Key (45) and note the object handle for the generated key.
3. Execute SIMExtract (105).
a.Enter the object handle for Enter handle of object to add to blob.
b.Enter 0 to end the list.
c.Enter 1 for Enter authentication form.
d.Enter 1 for number of authorization secrets (N value).
e.Enter 1 for Enter subset size required for key use (M value).
f.Enter a password.
g.Enter 1 for Delete after extract.
h.The masked key is saved to blobfile.sim.
4.List all of the objects in the partition by running Find object (26) with option All Standard Objects (6).
5.Execute SIMInsert (106).
a.Enter blobfile.sim for Enter filename with object to insert.
b.Enter 1 for Enter authentication form.
c.Enter 1 for Enter number of authorization secrets to be provided.
d.Enter the password that was entered in the previous step.
6.List all of the objects in the partition by running Find object (26) with option All Standard Objects (6). The key that was extracted should now be present in the partition.
NOTE The example above uses the password authentication form. Other authentication forms can be used.
Using the Provided Java Sample
As a prerequisite, ensure that the LunaProvider.jar and libLunaAPI.so has been installed to your JDK.
1.Navigate to the directory that contains the java sample:
cd JavaSample
2.In the SIMExtractInsert.java, modify the slot and hsmPass variables appropriately.
3.Compile the sample using javac:
javac SIMExtractInsert.java
4.Run the sample using java.
Changing the SMK
Your organization may have mandatory rollover schedules that govern the lifetime of important keys. Therefore, it may be necessary to change the SMK after a set time. Follow the procedure below to change the SMK on a partition or HA group.
CAUTION! SMK rollover is a disruptive process and can result in significant down-time. Plan it appropriately before you continue.
If you create a new SMK on the partition, every blob in the database encrypted by the old SMK must be inserted to the partition, decrypted, the objects re-encrypted with the new SMK and extracted as a new blob, and stored back in the database. Luna USB HSM 7 stores both the new SMK and the old SMK simultaneously until this process is complete, and the old SMK is then deleted.
Prerequisites
>Stop all applications using the partition or HA group.
>Dismantle the HA group by removing all but the primary member, or delete the HA group.
NOTE For HA environments, if you perform SMK rollover on a member, then the new SMK must be cloned to all members. However, database / repository update for rollover should be done by directly addressing the primary physical member, and not using the virtual slot (to avoid the performance penalty when keys inserted to the virtual slot during rollover would be propagated to all members before the re-extraction).
>Ensure that you have access to all databases, repositories, and backups where blobs encrypted by the old SMK are stored.
To roll over the SMK
1.In LunaCM, log in to the partition as Crypto Officer.
lunacm:> role login -role co
2.Initiate the rollover procedure by creating a new SMK on the partition.
lunacm:> partition smkrollover -start
The new SMK is stored in the Primary SMK location on the partition (see SKS Master Key Types). The old SMK is moved to the Rollover SMK location.
3.[Optional] Display the primary and rollover SMK OUIDs.
lunacm:> partition showinfo
Partition SMK OUIDs:
SMK-FW4: Not Initialized
SMK-FW6: Not Initialized
SMK-FW7-FM: Not Initialized
SMK-FW7-Rollover: 1e0000000e000001111e0800
SMK-FW7-Primary: 1f0000000e000009999e0800
4.Perform SMK rollover by retrieving each of your encrypted blobs from the database, inserting it into the partition, and re-extracting it once it has been encrypted with the new SMK.
a.Insert blobs using the SIMInsert API and the rollover SMK (the former primary SMK).
b.After each blob is inserted, extract it again to external storage. The extract action is performed with SIMExtract, using the new primary SMK.
5.When all blobs have been retrieved, inserted, and re-extracted, end the rollover procedure by deleting the rollover SMK.
CAUTION! Ensure that you have re-encrypted all your key material before ending the rollover procedure. When the rollover SMK is deleted, any blobs it encrypted are unrecoverable.
lunacm:> partition smkrollover -end
6.If you are using the partition as the primary in an HA group, you can recreate it now. The new SMK is cloned to each member as you add it to the group.
lunacm:> hagroup addmember {-serialnumber <serialnum> | -slot <slotnumber>} -group <label> -password <password>
