This chapter describes how to migrate your keys and configuration from a Luna HSM 5.x or 6.x partition to a Luna HSM 7.x partition by using one of three methods; backup and restore, cloning, or cloning using a temporary HA group:
>Luna Network HSM 5.x/6.x to Luna Network HSM 7
>Luna USB HSM 6.x to Luna Network HSM 7
>Luna PCIe HSM 5.x/6.x to Luna Network HSM 7
>Moving from Pre-7.7.0 to Firmware 7.7.0 or Newer
Refer also to the chapter on Key Cloning, particularly Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM, Password or Multifactor Quorum.
This document guides you through several migration scenarios consisting of older and newer Luna HSMs, using each applicable migration method. Before migrating, preconditions are provided for each scenario that must be met. There are specific user roles that are identified for performing the migration. In addition, both authentication methods (password and PED-authenticated) are supported.
Supported Luna HSMs
This document describes key migration for these Luna HSMs:
> Luna Network HSM, version 5.x or 6.x to 7.x
>Luna USB HSM, version 5.x or 6.x to 7.x
>Luna PCIe HSM, version 5.x or 6.x to 7.x
TIP When cloning objects:
•by direct clone command, or
•by backup/restore, or
•by synchronization in an HA group)
...between 5.x or 6.x HSMs and 7.x HSMs, the common domain between the HSMs must be the designated primary domain on any HSM that is at firmware version 7.8.0 or newer.
This is because the cloning protocol on HSMs prior to firmware 7.8.0 is unaware of the ability to have multiple domains and therefore the older HSM can interact with only the primary domain on the firmware 7.8.0+ HSM. So, if the domain of the old HSM exists on the firmware 7.8.0-and-newer HSM, set that domain to be Primary before cloning.
Order of operations
As indicated below, a variety of migration methods and paths are possible, and in your own situation, you might be performing different parts of an overall migration strategy at different times over some period. We advise to think carefully about the order in which actions are performed, and this section is a quick summary of considerations that might apply in your situation.
>If you have the older Luna HSMs and are using the older Luna Backup HSM G5, then maintain that Backup HSM at firmware older than Luna Backup HSM G5 Firmware 6.26.0. Firmware 6.26.0 and above will work only with Luna HSMs 7.x. By keeping the pre-6.26.0 Backup firmware, initially, you maintain the option to make new backups from your older HSMs if that need arises before your 5.x or 6.x HSMs are decommissioned.
>Until you are ready to advance further, maintain your new 7.x HSMs at firmware older than Luna HSM Firmware 7.7.0 (Luna HSM Firmware 7.4.2is recommended) - with Luna Backup HSM G5 Firmware 6.26.0, you can backup Luna 7.x HSMs up to Luna HSM Firmware 7.4.2 which benefits from many fixes and improvements / features compared to prior 7.x versions.
>In the case of multifactor quorum-authenticated HSMs, the Luna PED must be at minimum Luna PED Firmware 2.7.1.
>Assuming that everything goes well in your migration from HSMs version 5.x or 6.x to new version 7.x HSMs, you can then upgrade the Luna Backup HSM G5 and Luna PED to their latest firmware versions, and also upgrade the new Luna 7.x HSMs to the target Luna HSM Firmware 7.7.0 or newer.
>These are the eventual target versions for all components:
•Luna PED Firmware 2.9.0 or newer (for the USB-powered PED) or Luna PED Firmware 2.7.4 or newer (for the adapter-powered PED) are the minimum required to support Luna HSMs at firmware 7.7.x
•Luna Backup HSM G5 Firmware 6.28.0 or newer, which is needed to support backup of Luna HSMs at firmware 7.7.x, and is compatible with Luna HSM Client 10.3.0.
•Luna HSM Client 10.3.0 or newer is needed to support Luna HSMs at Luna HSM Firmware 7.7.0 or newer
Refer to Luna HSM Firmware Releases to find the latest FIPS and CC evaluated versions and to the NIST and Common Criteria sites for completed and in-progress applications).
Migration methods
The three migration methods used in this guide are:
>Backup and restore
The backup and restore method uses the LunaCM partition archive backup command to backup key material on an HSM (5.x or 6.x) partition and the Restore command to then restore this material to an HSM 7.x partition.
>Cloning
The cloning method uses the LunaCM partition clone command to clone from an HSM (5.x or 6.x) partition to an HSM 7.x partition. It is also referred to as slot-to slot cloning.
>Cloning using an HA group
The HA group method uses the LunaCM ha synchronize command on members of a temporary HA group consisting of a 5.x or 6.x HSM and a 7.x HSM, set up solely for the purpose of migration. After migration, this group should be removed since the members are not using the same software version.
All three methods invoke the cloning protocols, behind the commands that you specifically issue. This table is a quick summary of the options and cloning protocols that are available for migration from various source levels, up to, and including Luna HSM Firmware 7.8.0 (or newer) and client Luna HSM Client 10.5.0 (or newer), with the cloned objects going to targets that are at Luna HSM Firmware 7.8.0 (depending on settings at the target).
| Source slot | Source cloning protocol | Destination cloning protocol (firmware 7.8.0) |
Cloning protocol used |
|---|---|---|---|
| Firmware version < 7.7.0 | CPv1 | CPv1, CPv3, CPv4 | CPv1 |
| Firmware version = 7.7.0 | CPv3 | CPv1 (disabled here by partition policy 42), CPv3 , CPv4 (not matched at source) |
CPv3 |
| CPv3 | CPv1 (enabled here by partition policy 42), CPv3 (disabled because CPv1 enabled), CPv4 (not matched at source) |
N/A | |
| Firmware version > 7.7.0 < 7.8.0 | CPv1-out, CPv3 | CPv1 (enabled by partition policy 42), CPv3 (disabled because CPv1 enabled), CPv4 (not matched at source) |
CPv1 |
| CPv1-out, CPv3 | CPv1 (disabled by partition policy 42), CPv3 (enabled because CPv1 disabled), CPv4 (not matched at source) |
CPv3 | |
| Firmware version = 7.8.0 | CPv1-out, CPv3, CPv4 | CPv1 (enabled by partition policy 42), CPv3, CPv4 (these are disabled if CPv1 ensabled) |
CPv1 |
| CPv1-out, CPv3, CPv4 | CPv1 (not enabled by partition policy 42), CPv3, CPv4 (these are enabled if CPv1 disabled) |
CPv4 (if both slots have at least one CPv4 cipher-suite in common), otherwise CPv3, unless CPv3 cipher-suite is also disabled, then N/A |
Preconditions
Each migration procedure in this document is prefaced by a "Preconditions" section that specifies the hardware and software requirements along with any assumptions the procedure is using to perform the migration steps. Examples are a 5.x or 6.x HSM, a 7.x HSM, 5.x, 6.x or 7.x client software, user roles and the slot #s used in the procedure.
Roles required for migration
The following partition roles are needed to migrate key material:
>Partition Security Officer. The partition security officer role is needed to perform LunaCM HA operations and to create the Crypto Officer role.
>Partition Crypto Officer. The partition Crypto Officer role is needed to perform LunaCM backup/restore and cloning operations.
NOTE When logging in to a partition, be mindful of whether you’re working with pre-PPSO or PPSO firmware. Use the partition login command if your HSM has pre-PPSO firmware (version 6.21.2 and earlier). Use the role login command if your HSM has PPSO firmware (version 6.22.0 and later). Also, with PPSO firmware 6.22.0 and later (up to but not including firmware 7.x), be careful with user names; that is, type Crypto Officer in full (is case sensitive) and not the abbreviation co.
In firmware version release 7.x, partition login name requirements allow for abbreviations. That is, you can log in using po for Partition Security Officer or co for Crypto Officer.
