On this page:
>Cloning the SKS Master Key (SMK)
The SKS feature beginning with Luna HSM Firmware 7.7.0 (and newer) uses the same API as previous SKS versions, to retain backward compatibility; your applications that used older SKS should still work. However, the new structure for SKS was developed in conjunction with an updated cloning protocol and other features of Luna HSM Firmware 7.7.0 associated with V1 partitions, and you (or a regulatory regime under which your organization operates) might see benefit in migrating existing SKS secrets to the newer form.
For purposes of migration, the SKS Master Key (SMK) is cloned to a target partition - this is the only use for the cloning protocol in V1 partitions. Objects encrypted by the SMK (that is, SKS blobs) are generally expected to be stored external to the crypto module in a repository via SKS extract operation (SIMextract API call) from the partition and later SKS insert operation (SIMinsert API call) when needed. If blobs are small enough or few enough in number, such objects could be replicated to other members in an HA group, or to keyrings in a cluster, or stored on a Backup HSM if desired, but as data objects only.
Off-board storage is assumed to be the primary method of storing such blobs (and not storage inside a general purpose crypto module or a backup HSM).
Cloning the SKS Master Key (SMK)
No changes to the existing older SKS host API are necessary for the cloning of the earlier and the newer SMKs. The choice is based on the formatting of the incoming SMK Secret.
NOTE If a remote partition is involved (Network HSM) on either side of the SMK cloning operation, the HSM that contains the remote partition must have Network Replication enabled. See HSM Capabilities and Policies "Policy 16 - Allow network replication".
The following table shows possible migration paths for existing SMKs -- the leftmost column is possible sources, while the heading row across the top lists possible destinations, and the intersecting table cells are the possible result for each source-to-destination scenario.
|
|
|
|
|
|
|
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FW6 SKS appliance | FW6 SMKs | FW6 SMKs | FW6 SMKs | No SMK support on target | Target has FM cert only | FW6 SMKs | ||||||||||||||
| FW6 SKS G5 Backup (6.25) | FW6 SMKs | FW6 SMKs | FW6 SMKs | No SMK support on target | Target has FM cert only | FW6 SMKs | ||||||||||||||
| FW7.7 eIDAS G5 Backup (6.28) | FW6 SMKs | FW6 SMKs | All SMKs (cloning protocol used by V1 partitions) | No SMK support on source/target | All SMKs (cloning protocol used by V1 partitions) | All SMKs (cloning protocol used by V1 partitions) | ||||||||||||||
| FW<7.7 HSM | No SMK support on source | No SMK support on source | No SMK support on source | No SMK support on target | No SMK support on source | No SMK support on source | ||||||||||||||
| FW7.7 FM HSM | Source has FM cert only | Source has FM cert only | All SMKs (cloning protocol used by V1 partitions) | No SMK support on target | All SMKs (cloning protocol used by V1 partitions) | All SMKs (FW7.7-Primary -> FW7.7-FM, FW7.7-Rollover dropped) (V1 partition) | ||||||||||||||
| FW7.7 Non-FM SKS HSM | Required cloning protocol not on target | Required cloning protocol not on target | All SMKs (cloning protocol used by V1 partitions) | No SMK support on target | Blocked by V1 cloning protocol | All SMKs (cloning protocol used by V1 partitions) |
( FW>=7.7 means Luna HSM Firmware 7.7.0 or newer)
To migrate an older SMK
To move/copy an SMK from one of the supported source configurations to one of the supported targets
1.If the source and target are crypto partitions, clone the SMK secrets between partitions with the partition smkclone lunacm command.
2.If the target is a Luna Backup HSM clone to the Backup HSM with the partition archive backup lunacm command.
3.If the source is a Luna Backup HSM, clone from the Backup HSM with the partition archive restore lunacm command.
Only some combinations of source and target are supported. Reasons for a path to not be supported are summarized in the table.
SCENARIO 1:
0. You have a pre-existing 7.7.0 SMK, and a bunch of extracted blobs (encrypted with that SMK) in a repository, all of which you want to preserve, and to which you want to add 6.x SMK and SKS blobs after migrating them.
1.Backup the modern 7.7.0 SMK to a partition on a firmware 6.28.0 or 7.7.0 Backup HSM (partition archive backup).
2.Backup the 6.x or 4.x SMK (partition archive backup).
3.Restore the 6.x SMK onto a V1 partition (partition archive restore). This puts it in the Primary SMK slot of that partition, overwriting any SMK that was there.
4.Perform partition smkrollover -start on the V1 partition. This moves the 6.x SMK into the Rollover slot of the partition and generates a new Primary SMK.
5.Restore the production 7.7.0 SMK that you backed-up earlier (partition archive restore). This overwrites the newly-generated Primary, but the Rollover partition still has the 6.x SMK.
6.Insert one of your 6.x SKS blobs. The HSM tests it and knows to use the Rollover SMK to perform the SKS insert operation.
7.Extract the key/crypto-object as a new blob - the HSM allows only the Primary (the one you just got back from archive) to perform the extraction.
8.Repeat for all your old-style blobs to get them all encrypted with the new SMK for storage in your repository.
9.Perform partition smkrollover -end which deletes the old SMK from the Rollover slot of the V1 partition.
SCENARIO 2:
You have 6.x SMK and SKS blobs. You want to migrate the older blobs to use in a new V1 partition (7.7). So, no 7.7.0 SMK and blobs currently exist that need conserving.
1.1. Backup the 6.x (to partition on 6.28.0 or 7.7.0 Backup HSM) with partition archive backup command.
2.Create a new V1 partition (partition create), initialize it (partition init), log in as CO (role login -name co) etc., but you don't care about the generated 7.7.0 SMK.
3.Restore the 6.x SMK onto the V1 partition (partition archive restore). This puts it in the Primary SMK slot of that partition, overwriting any SMK that was there.
4. Perform partition smkrollover -start on the V1 partition. This moves the 6.x SMK into the Rollover slot of the partition and generates a new Primary SMK.
5.Insert one of your 6.x SKS blobs. The HSM tests it and knows to use the Rollover SMK to perform the SIMinsert operation.
6. Extract the blob - the HSM allows only the Primary (recently generated) to do the extraction.
7.Repeat for all your old-style blobs to get them all encrypted with the new SMK for storage in your repository.
8.Perform partition smkrollover -end which deletes the old SMK from the Rollover slot of the V1 partition.
SKS Blob Migration
With no modifications to the pre-existing host API for offboard key storage (SKS), the version number for the mechanism used is prepended to the SKS blobs and employed to select the correct mechanism to insert the blob back into the HSM.
HSMs are allowed to extract key blobs using only the latest and greatest SMK secret and mechanism available to them. Incoming older blobs with older SMK secrets and mechanisms are accepted, provided that the HSM f/w supports them.
NOTE Migration from older HSMs, that used possibly outdated encrypting keys/mechanisms should not present a problem, since older blobs would be inserted only. The same material would then be extracted using newer or unrestricted key types or sizes.
The following table shows options for SKS blob insertion into a partition, Protocol and Key Import/Export vs External Storage. The leftmost column is possible sources, while the heading row across the top lists possible destinations, and the intersecting table cells are the possible result for each source-to-destination scenario.
| FW6 SKS appliance | FW7.7.0 Non-FM HSM (V0 Partition) | FW7.7.0 FM HSM (V0 Partition) | FW7.7.0 Non-FM HSM (V1 Partition) | FW7.7.0 FM HSM (V1 Partition) | |
|---|---|---|---|---|---|
| FW6 SKS appliance | Using FW6 SMK (V1 partition cloning protocol) Import/Export | No SKS Support on source/target | No SKS Support on source/target | Using FW6 SMK (V0 partition cloning protocol) Import/Export | No FW6 SMKs on Target |
| FW7.7.0 Non-FM HSM (V0 Partition) | No FW7.7.0-Primary SMK on Target | No SKS Support on source/target | No SKS Support on source/target | No SKS Support on source | No identical FW7.7.0-Primary SMK on Target |
| FW7.7.0 FM HSM (V0 Partition) | No FW7.7.0-FM SMK on Target | No SKS Support on source/target | No SKS Support on source/target | No SKS Support on source | No SKS Support on source |
| FW7.7.0 Non-FM HSM (V1 Partition) | No FW7.7.0-Primary SMK on Target | No SKS Support on source/target | No SKS Support on source/target | Using FW7.7.0-Primary SMK (V1 partition cloning protocol) External Storage | No identical FW7.7.0-Primary SMK on Target |
| FW7.7.0 FM HSM (V1 Partition) | No FW7.7.0-FM SMK on Target | No SKS Support on source/target | No SKS Support on source/target | Using FW7.7.0-FM SMK (V1 partition cloning protocol) External Storage | Using FW7.7.0-Primary SMK (V1 partition cloning protocol) External Storage |
To migrate an older SKS blob:
To insert an SKS blob, for any of the supported scenarios (table above),
1.Insert with the SIMinsert operation as you always have.
The CKDemo Utility, command 106, demonstrates the action - see OFFBOARD KEY STORAGE Menu Functions.
