On this page:
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.). SKS does not impose any restrictions on where or how you store encrypted blobs; although constraints like record-size might come into play depending on the type of storage in your implementation. The repository might have each record/object encrypted with a unique key. Examples of applications might include Remote Signing identities (Common Criteria PP 419221-5 use case). The salient points, for SKS, are that:
>Encryption and decryption of objects must take place in the cryptographic module.
>More individual object-encryption keys are needed by the application than can be accommodated by the internal capacity of any cryptographic module.
>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 must have originated within the assurance boundary (a.k.a. security perimeter of the cryptographic module (HSM)) and are only ever decrypted within the assurance boundary.
>An object can be inserted into any cryptographic module (HSM) version that supports the same version of SKS and supports the same attributes that the original HSM supports for that object.
NOTE Objects extracted from a current-version HSM can be inserted into older version HSMs with known vulnerabilities -- for security reasons, this should be avoided; as a best practice, keep your appliance software and crypto-module firmware up-to-date.
>Objects extracted from an HSM with Functionality Modules disabled cannot be inserted into an HSM with FMs enabled (including via backup/restore operations) - security rules prevent moving keys from a more-secure to a less-secure environment.
How does SKS work?
A key is created in an HSM partition at the direction of an application.
It might be intended as an ID for purposes of 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 (perhaps customer-identifying records, perhaps medical records, perhaps supply-chain information, or other uses that require privacy and controlled access).
>Each record-encrypting key, or ID key, when not in immediate use inside a cryptographic module, is itself encrypted for extraction by an extraction/insertion key derived (in compliance with NIST SP800-108) from a master encryption key that never leaves the HSM; this is the SKS Master Key, or SMK.
>From the application's perspective, the data record, or the key/cert-as-ID, emerges from the HSM uniquely encrypted as a secure SKS blob (binary large object up to 64KB) that remains within the HSM's security and access perimeter, so it can be safely stored anywhere.
>The operations that an application might perform are:
•creating an identity or a record or data object
•acquiring a suitable key (SKS key) for encrypting that record or data object by either
–requesting a new object-encryption key (new SKS key) to be generated by the HSM,
or
–providing an already existing object-encryption-key (SKS key) for the HSM to use
•encrypting that ID or object with the new SKS key, (or with the pre-existing, supplied SKS key, which must first be inserted and decrypted for use by the HSM)
•storing the encrypted record or key within the repository
•retrieving the encrypted record or key at a later time (when called by the application)
•inserting/decrypting the SKS blob into the HSM, using the SKS Master Key (SMK)
•using the decrypted key
–to sign or seal documents or transactions in the case of RSS, or
–to further decrypt a database record for reading or editing and then re-encrypting the record if it changed and sending the re-encrypted changed record back to storage
•deleting / destroying the material from the HSM (cryptographic module), 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 the storage and availability of the SKS object in the repository of choice (database, file system, directory, NAS, cloud, etc.).
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). However, a practical workflow involving large numbers of keys or sensitive data objects, 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 numbers far greater than the capacity of any cryptographic module. However, we cannot anticipate all use-cases, and the onboard storage option exists.
To summarize, the options for SKS blobs (SMK-encrypted keys and objects) include:
>Storage of limited numbers of keys and objects encrypted within the cryptographic module;
>Storage of a larger, but still limited number of keys and objects encrypted within a backup HSM;
>Storage of a still larger number of encrypted keys and objects within the file system of the host
>Storage of a virtually unlimited number of encrypted keys and objects across databases or networked file systems.
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.
Limitation and scalability
Because the SKS objects are stored external to the cryptographic module (but must be individually inserted back into the crypto module before use), there is no capacity limitation from an HSM perspective. The only scalability limitation would be based upon the number of SKS operations to be performed simultaneously (that is, SKS object creation/extract/insert, and resulting cryptographic operations).
In a Luna HSM at firmware 7.7.0 or newer, partitions are either V0 or V1.
>In V0 partitions, keys and objects are handled generally as in previous versions, depending on the type of crypto module configuration (cloning, key extraction, etc.); cloning of objects, such as for backup, HA, etc., is performed as you and your applications have always done, using Luna HSMs. All copying of keys and objects is done between application partitions or Backup partitions that share a security/cloning domain
>In V1 partitions, SKS is used. Other than for some SMK management operations, the copying and moving operations for partition objects/keys/etc., have been kept as similar to historic handling as practical. Thus, while the cloning commands are used, only the SMK is ever cloned in the Luna-traditional sense.
Cloning operations (like Backup, and like HA-group synchronization) for V1 partitions use cloning for the SMK, but also seamlessly invoke SKS to transfer or extract/insert keys and objects as blobs encrypted by the SMK. Thus, encrypted keys/objects can be copied securely to another partition or a Backup HSM, if the quantity/storage usage is within the capacity of the receiving partition.
Recall that partitions are created with default sizes, but you can specify to use up to all remaining space in the cryptographic module and you could store a number of keys/objects as SKS blobs within such a partition, but for large quantities, it is expected that you would store them encrypted in the HSM appliance's file system or external database, while maintaining them within the cryptographic module's security boundary.
