When would it be appropriate 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. You would also use it when needed 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. The SKS method - in contrast with merely wrapping-off/unwrapping-on - is needed when the HSM must be the assurance boundary for the keys. If it is permissible for the key material to originate outside the assurance boundary, or to reside outside the assurance boundary, then the extra security of SKS is not required.
A general use case for SKS is storing encrypted keys in external databases.
>Generate keys inside the cryptographic module.
>Using the SIMExtract API, extract the encrypted keys and store them in external databases and delete the original keys inside the cryptographic module.
>Insert individual encrypted keys back into the HSM when you need to use them for cryptographic operations inside the cryptographic module.
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.
Security consideration
Various models exist in the industry for handling of huge numbers of sensitive keys and objects. An important consideration is the manner in which the keys and objects are handled.
| Method | Security |
|---|---|
| Wrap-off/wrap-on |
Keys and objects can have unknown, uncontrolled origin, potentially outside the assurance boundary. Keys and objects can potentially be accessed outside the HSM, made available and used externally, in potentially unsafe environments. . Keys can have security attributes stripped. |
| SKS extract/insert |
The history of keys and objects is known, controlled, auditable. Keys and objects remain within the security and access perimeter 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 retain their attributes. |
