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 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 must have originated within the assurance boundary (a.k.a. security perimeter of the HSM) 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
>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), but that is not the envisioned general 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 numbers 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. See Per-Key Authorization.
Limitation and scalability
Because the SKS objects are stored external to the cryptographic module (but must be individually inserted back into the HSM 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).
