On this page:
•Characteristics and Implementation Notes
Characteristics of the SKS Implementation
>The SKS feature is implemented at the application partition level; this differs from the older SKS protocol that was applied HSM-wide.
>The SKS mechanism complies with the per-key authorization requirements of Common Criteria PP 419221-5 (Per-Key Authorization).
>The cryptographic mechanisms employed by SKS comply with the FIPS 140-2 and PP 419221-5 standards (Secure External Scalable Key Storage Extensions).
>A migration path is available for customers using the Luna HSM firmware 6 SKS protocol, such that existing customer applications continue to work against the SKS implementation.
>For certification requirements and/or security best practices, the following are not allowed:
•The SKS implementation prevents objects that are extracted from an HSM with firmware 7.x being inserted into an older version of the HSM that might have known vulnerabilities.
•The SKS implementation prevents objects that are extracted from an HSM that has Functionality Modules (FMs) disabled, from being inserted into an HSM that has FMs enabled (or ever had FMs enabled) - doing so via a backup HSM is also prevented.
Functional Notes
SKS supports the following functionality:
>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.
>You have the option to impose/require two possible authentication methods when extracting key objects:
•None (no extra authentication data)
•Password (MofN supported)
>The AES-GCM algorithm is used for encryption of objects during the creation of SKS blobs (extraction from the partition) or decryption upon insertion of an external SKS blob into the partition.
>You can see, and practice, examples of such usage in the ckdemo utility :
•OFFBOARD KEY STORAGE Menu Functions
SMK Locations in a Partition
Each SKS-capable partition supports several types of SMK, each with its own location and limitations within the partition.
The Primary SMK, generated at partition initialization time, or replaced via partition smkclone command from another partition, resides in the Primary SMK location in the partition, and is used for extraction and insertion operations. Only the firmware 7.x primary SMK can be used for extraction. No path is allowed for extraction to older-version HSMs and partitions.
The Rollover SMK location holds the replaced primary, when partition smkrollover start command creates a new primary SMK. The rollover SMK is retained while SMK rollover is taking place, to allow all SKS blobs that were encrypted/extracted with the old SMK to be brought back into the HSM partition so that they can be re-extracted with the new primary SMK. When partition smkrollover end signals the completion of the rollover operation, the rollover SMK is deleted and the new Primary SMK remains.
The FM SMK location is specifically for transfer from an FM-enabled partition to an FM-never-enabled partition. That is, a partition smkclone command from an FM-enabled HSM partition places the source Primary SMK into the FM SMK location of the target partition. This ensures that key material can be transferred from FM-enabled partitions to FM-never-enabled partitions. It is not permitted to move key material from FM-never-enabled partition to FM-enabled partition, because a Functionality Module could extract in plain text. Similarly, there is no FM SMK rollover location.
The Firmware 6 SMK location can contain an SMK from a firmware 6.x HSM (if one has been cloned in) for the purpose of inserting SKS blobs that were extracted from a firmware 6.x partition. After insertion of such older blobs, the key material is extracted as a new firmware 7 SKS blob, encrypted via the partition's primary SMK. 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.
