SMK Rollover

Mandated rollover schedules might place limits on the allowable lifetimes of important keys, like the SMK. Toward this end, the partition smkrollover command generates a new SMK and allows you to re-encrypt your SKS blobs with a new SMK.

However, if a new SMK is created - such as in the SMK rollover operation - then every blob that has been encrypted with the old SMK must be inserted, its contained keys/objects re-encrypted with the new SMK and extracted as a new blob, and this must be accomplished for all such externally stored blobs, during the smkrollover -start to smkrollover -end interval. Any blobs for which the encrypting SMK no longer exists can no longer be decrypted.

To rollover the current SMK

If you wish to perform SMK rollover, please realize that it is a disruptive process and a major one. Hence, plan it appropriately by scheduling a down-time and then follow this three-step procedure:

1.Dismantle the HA group.

2.Perform SMK Rollover.

a.Begin with partition smkrollover -start

the original SMK is moved to the Rollover area, and

a new SMK is created and placed in the Primary SMK area of the current HSM.

b.Retrieve every blob from your repository, one at a time, insert it into the HSM partition - the insert action is performed with SIMInsert API using the former-primary-now-rollover SMK.

c.After each key or object is inserted, extract it again to external storage - the extract action is performed with SIMExtract using the new Primary SMK.

d.When all blobs have been retrieved (from repository, database, backup HSM, etc), inserted and re-extracted, then perform partition smkrollover -end one time, to delete the previous SMK from the rollover slot, to conclude the rollover operation.

3.Re-create the HA group, cloning the new SMK to each HSM that will become a member of the recreated HA group, and resume operations.

You can generate a new SMK and immediately discard the old one with partition smkrollover -start -end command. Do this only if you know that no blobs exist that are encrypted with the old SMK, otherwise they will be orphaned.

NOTE   For HA environments, if you perform SMK rollover on a member, then the new SMK must be cloned to all members. However, database / repository update for rollover should be done by directly addressing the primary physical member, and not using the virtual slot (to avoid the performance penalty when keys inserted to the virtual slot during rollover would be propagated to all members before the re-extraction).