Special Considerations for Luna HSM Firmware 7.7.0 and Newer
This section describes some special considerations for customers that are updating to Luna HSM Firmware 7.7.0 or newer from Luna HSM Firmware 7.4.2 or older. Carefully read all of the information below and complete all procedures that are relevant to your deployment. Refer to the following sections for more information:
>Special Considerations for Updating to Luna HSM Firmware 7.7.0 or Newer
>Special Considerations for Operating Luna HSMs With Firmware 7.7.0 or Newer
>Migration Procedures for Luna HSM Firmware 7.7.0 and Newer
NOTE There are release-specific advisory notes for firmware versions released after Luna HSM Firmware 7.7.0. If you are updating to a firmware version newer than 7.7.0, refer to the release-specific advisory notes in addition to the information in this section.
Special Considerations for Updating to Luna HSM Firmware 7.7.0 or Newer
The following notices concern the firmware update process.
>Luna HSM Firmware 7.7.0 and Newer Require the Luna Network HSM 7 Reboot Patch
>Updating to Luna HSM Firmware 7.7.0 or Newer Will Take Longer Than Usual
Luna HSM Firmware 7.7.0 and Newer Require the Luna Network HSM 7 Reboot Patch
If you have a Luna Network HSM 7 that was shipped before December 2019, you must install the Luna Network HSM 7 Reboot Patch before updating to Luna Appliance Software 7.7.0 or newer. If this patch is not installed, the appliance software update will not proceed.
Updating to Luna HSM Firmware 7.7.0 or Newer Will Take Longer Than Usual
This update will take longer to complete than other firmware updates. If you have a small number of keys, expect the firmware update to take at least 15 minutes. For a large numbers of keys, the update and conversion could take as long as a few hours. Ensure that you can leave the update operation uninterrupted and take the following precautions:
>Use independent uninterruptible power supplies.
>Do not stop or restart the HSM during the update process.
>Do not interrupt the procedure even if the operation appears to have stalled.
Special Considerations for Operating Luna HSMs With Firmware 7.7.0 or Newer
The following notices concern the operation of Luna HSMs after they are updated to Luna HSM Firmware 7.7.0 or newer:
>Pre-Existing Partitions Converted to Version 0 Partitions
>Luna HSM Firmware 7.7.0 and Newer Require Updated PED Firmware
>Secure Trusted Channel Updated
>High Availability Groups Updated
>Luna HSM Firmware 7.7.0 and Newer Require Updated Luna Backup HSM 7 and Luna Backup HSM G5 Firmware
>Cloning Restrictions for Keys and Objects in Version 0 Partitions with New Attributes
>Key, Object, and Partition Creation Restricted When Partition Memory Allotment Exceeded
Pre-Existing Partitions Converted to Version 0 Partitions
After updating to Luna HSM Firmware 7.7.0 or newer, all pre-existing partitions are updated with Partition Policy 41: Enable Partition Version set to Version 0 (V0). V0 partitions have been designed to preserve as much compatibility as possible with your existing applications, while setting some necessary infrastructure for features introduced with Luna HSM Firmware 7.7.0 and newer, and future developments. For more information about V0 and V1 partitions, refer to the following sections:
>For information about the distinction between V0 and V1 partitions and how they affect the operation of Luna HSMs, refer to V0 and V1 Partitions.
>For information about converting partitions from V0 to V1 or V1 to V0, refer to Converting Partitions from V0 to V1 or V1 to V0.
NOTE Conversion of partitions from V0 to V1 is only relevant to customers that require any of the following:
>Common Criteria compliance.
>eIDAS compliance with support for the relevant Protection Profile (PP 419-221.5).
>Conformity with FIPS SP 800-131A (revised).
>Scalable Key Storage (SKS) functionality.
>Per-Key Authorization (PKA) functionality.
Luna HSM Firmware 7.7.0 and Newer Require Updated PED Firmware
Luna HSM Firmware 7.7.0 introduced new security communication protocols for compliance with current eIDAS, Common Criteria, and FIPS standards. You require one of the following minimum PED firmware versions, depending on your Luna PED hardware:
>USB-powered Luna PED: Luna PED Firmware 2.9.0 or newer. You can update firmware 2.8.x directly to version 2.9.0.
>Adapter-powered Luna PED: Luna PED Firmware 2.7.4 or newer. You can update firmware 2.6.x through 2.7.2 directly to version 2.7.4.
These Luna PED firmware versions are backwards-compatible with older Luna HSM firmware, but a Luna HSM with firmware 7.7.0 or newer will refuse connection to a Luna PED with older firmware (LUNA_RET_PED_UNSUPPORTED_PROTOCOL error).
CAUTION! You must update the firmware for at least one Luna PED before updating the Luna HSM firmware so that you can authenticate roles on the HSM during the update process.
PED Protocol Updated
Luna HSM Firmware 7.7.0 introduces a new PED protocol for securing local and remote PED connections. If you plan on operating multifactor quorum-authenticated HSMs after updating to Luna HSM Firmware 7.7.0, refer to the following sections before updating:
>Updated Luna PED Behavior Notes for information about updated Luna PEDs.
>Multifactor Quorum Authentication for information about using Luna PEDs with HSMs that contain V0 or V1 partitions.
After updating to Luna HSM Firmware 7.7.0 or newer, you must create a new orange key using a local PED connection or migrate any existing orange remote PED keys to use the new protocol. For the complete migration procedure, refer to Migrating Existing Orange Remote PED keys.
Secure Trusted Channel Updated
Luna HSM Firmware 7.7.0 and newer support an updated version of Secure Trusted Channel (STC). For more information about the newer version of STC, refer to Secure Trusted Channel. If you have been using STC with an older version of the Luna software/firmware, the update zeroizes old STC keys and your STC identities are no longer compatible with the updated version of STC. You must migrate your STC connections by following the procedure in Migrating STC Connections to Luna HSM Firmware 7.7.0 or Newer.
High Availability Groups Updated
Client-mediated High Availability (HA) and HA Indirect Login have been updated.
Client-Mediated High Availability
Luna HSM Firmware 7.7.0 and newer include changes to the Luna cloning protocol that HA groups use to duplicate cryptographic objects among their individual members. These changes constrain the ability to fully support HA groups combining 7.7.0+ and older firmware versions (see Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM, Password or Multifactor Quorum). The ability for HA to clone between mixed-generation member partitions improves with release 7.7.1. However, for best utility, all HSMs containing HA group members should be updated to firmware 7.7.0+ at the same time to allow the HA group to continue functioning normally. Follow the procedure described in Migrating a High Availability Partition Member to Luna HSM Firmware 7.7.0 or Newer to migrate your HA group members to firmware 7.7.0 or newer.
High Availability Indirect Login
If you are using HA Indirect Login with a pool of partitions, you must migrate to version 1.1 or version 2.0 of the protocol to continue using this feature. All partitions should be capable of, and using, the same version of HA Indirect Login (otherwise all members are not able to act as a primary) and must be migrated at the same time. For more information about this feature, refer High Availability Indirect Login. Follow the procedure described in Migrating to the Newer High Availability Indirect Login Protocol to migrate to the newer version(s) of this protocol.
Luna HSM Firmware 7.7.0 and Newer Require Updated Luna Backup HSM 7 and Luna Backup HSM G5 Firmware
If you plan to use a Luna Backup HSM G5 or Luna Backup HSM 7 as a production backup for a Luna HSM with Luna HSM Firmware 7.7.0 and newer, then you must update the firmware of the backup HSM to the following:
>Luna Backup HSM 7 requires minimum Luna Backup HSM 7 Firmware 7.7.1
>Luna Backup HSM G5 requires minimum Luna Backup HSM G5 Firmware 6.28.0
NOTE
>If you plan on operating a Luna HSM with Luna HSM Firmware 7.4.2 or older alongside a Luna HSM that has been updated to Luna HSM Firmware 7.7.0 or newer, and must use a backup HSM with both HSMs, then the firmware of the backup HSMs must not be updated to ensure compatibility with both HSMs.
>When the firmware of the backup HSM is not updated, you can only use it to restore cryptographic objects to the Luna HSM with firmware 7.7.0 or newer.
For more information about performing backup and restore operations on Luna HSMs with firmware 7.7.0 or newer, refer to Backup/Restore.
Cloning Restrictions for Keys and Objects in Version 0 Partitions with New Attributes
After an old partition is converted to V0, some keys and objects may have new attributes that are unrecognizable to Luna HSMs with firmware older than 7.7.0. These objects can only be cloned if the newer attributes are left at default value (unset). This allows them to be dropped by the older, receiving HSM. If a newer security-related attribute has been set, then the object is not cloned to an older HSM that is not aware of the attribute.
Key, Object, and Partition Creation Restricted When Partition Memory Allotment Exceeded
NOTE This special consideration only applies to exceedingly rare corner-cases such as the one mentioned below; the majority of Luna HSM customers will never encounter the mentioned alarm nor experience the behavior and constraints that accompany it.
For most scenarios, your HSM, applications, and partitions would behave after the firmware update just as they did before the firmware update. This is because partition memory allotments are doubled to easily accommodate the changes in most cases. For more information, refer to Memory.
Some exceedingly rare corner cases (such as having a partition completely filled with Triple-DES keys) could result in the combined object sizes exceeding the new licensed partition size. If this situation is detected during an update to Luna HSM Firmware 7.7.0 or newer, then the following occurs:
>The HSM posts an alarm (ALM 2027 - HSM storage exceeded to the logs; see HSM Alarm Codes).
>A message "HSM storage is currently over capacity" is shown in lunacm.
>The HSM continues the update operation to completion by stretching the partition beyond the new licensed partition size, for an affected partition.
After the update operation is completed, all the previously stored partition objects are still available for your application to use. However, you must note the following:
>You might not be able to create any additional keys/objects in that partition until you make room by removing some.
>While the partition has more objects than intended, or taking up more space than licensed, a message similar to the alarm code is included whenever you display HSM information, and stops appearing when the partition content is reduced to fit within the licensed limit.
>As long as a partition on the HSM is in that "storage exceeded" state, the HSM does not permit the creation of any more partitions. When you trim the contents to fit within the licensed partition size, additional partitions can be created, up to the number for which your HSM is licensed.
Migration Procedures for Luna HSM Firmware 7.7.0 and Newer
Follow the procedures below that are relevant to your deployment:
>Back Up Old Scalable Key Storage Master Keys
>Migrating Existing Orange Remote PED keys
>Migrating STC Connections to Luna HSM Firmware 7.7.0 or Newer
>Migrating a High Availability Partition Member to Luna HSM Firmware 7.7.0 or Newer
>Migrating to the Newer High Availability Indirect Login Protocol
Back Up Old Scalable Key Storage Master Keys
If you are attempting to migrate a Scalable Key Storage (SKS) Master Key (SMK) from a 5.x or 6.x partition to a Luna HSM with Luna HSM Firmware 7.7.0 or newer using a backup/restore procedure, Thales recommends one of the following:
>Back up your SMK(s) to a Luna Backup HSM G5 with firmware 6.25.0 to 6.25.9, to ensure compatibility with your older (6.x) client version.
>If you have already updated the Backup HSM to a firmware version newer than 6.25.9, update to Luna HSM Client 10.3.0 or newer before attempting the backup.
Once you have migrated your keys to the Luna HSM with firmware 7.7.0 or newer, the firmware of the backup HSMs must be updated for complete backup and restore functionality with the updated Luna HSM. For more information, refer to Luna HSM Firmware 7.7.0 and Newer Require Updated Luna Backup HSM 7 and Luna Backup HSM G5 Firmware.
Migrating Existing Orange Remote PED keys
To migrate existing orange key(s), use one of the following procedures:
>Migrating the Orange RPK(s) Using a Remote PED Connection
>Migrating the Orange RPK(s) Using a Local PED Connection
Prerequisites
>Ensure that you have a backup orange PED key (or M of N set). If you do not have backups, see Duplicating Existing PED keys for the procedure.
>Thales recommends migrating the full M of N set of orange keys at the same time. You must have the full set, and any existing duplicate sets, present at the time of migration. If you do not have all duplicate keysets present, they can be migrated at a later time using this same procedure, or you can create new duplicates from an already-migrated keyset.
>Depending on your Luna PED hardware, you require the following minimum firmware versions to authenticate with Luna HSM Firmware 7.7.0 (see Updating External Supply-Powered Luna PED Firmware):
•Luna PED Firmware 2.7.4 or newer for older Luna PED
•Luna PED Firmware 2.9.0 or newer for refreshed Luna PED
>The Luna Network HSM 7 firmware must be at minimum Luna HSM Firmware 7.7.0 (see Updating the Luna HSM Firmware).
>The migration process takes about one minute per key. If you are migrating many keys (multiple duplicate copies of M of N splits, for example) you may need to adjust the PED timeouts on your
For example, if you are migrating an M of N split of 3 keys, with one set of backups, Thales recommends using the following minimum timeout settings under the Luna section of the Luna HSM Client configuration file (see Configuration File Summary). Estimate your actual settings based on the number of keys you are migrating:
•PEDTimeout2 = 600000 (PED key interaction time)
•CommandTimeOutPedSet = 1220000 (Overall PED Operation timeout)
If you are using LunaSH to initiate the key migration, use the following commands to adjust the timeout settings:
lunash:> hsm ped timeout set -type pedk -seconds 600
lunash:> hsm ped timeout set -type pedo -seconds 1220
Migrating the Orange RPK(s) Using a Remote PED Connection
You can use your existing Remote PED connections to migrate your orange PED keys (see About Remote PED). This is useful if you have multiple remote PED servers used by different administrators, as they can each migrate their own orange key or M of N keyset. The migration process will begin the first time you attempt remote PED connection after updating to Luna HSM Firmware 7.7.0 or newer.
To migrate the orange RPK(s) using a remote Luna PED
1.Choose LunaSH or LunaCM to initiate the procedure:
•Connect to the appliance via SSH or a serial connection and log in to LunaSH as admin or a custom user with an admin role (see Logging In to LunaSH).
•Launch LunaCM on the Luna HSM Client workstation and set the active slot to a partition on the updated HSM.
lunacm:> slot set -slot <slotnum>
2.Ensure that you have the orange PED key(s) ready, and initiate a PED connection:
lunash:> hsm ped connect [-ip <ip_address>] [-port <number>]
lunacm:> ped connect [-ip <ip_address>] [-port <number>]
3.The remote Luna PED prompts you to insert an orange key. Insert the orange key and press Enter.
4.The Luna PED informs you that this PED key must be migrated, and that the existing RPV will be preserved. It prompts you to confirm that you want to migrate this key. Press Yes.
•If you are migrating a single orange key (M = 1 and N = 1), the migration process begins, and takes about a minute.
The Luna PED then asks if you wish to migrate another key in this keyset. If you have duplicate orange keys to migrate, press Yes and repeat steps 3-4 for each duplicate.
•If you are migrating an M of N keyset, you must present the required M keys to reconstruct the RPV before the migration process can begin. Repeat steps 3-4 until you reach M keys. The migration process begins on the Mth key, and takes about a minute.
The Luna PED then asks if you wish to migrate another key in this keyset. Press Yes and repeat steps 3-4 for each key until all N keys have been migrated, including the keys you presented to meet the M requirement.
If you have duplicate orange M of N keysets, repeat steps 3-4 for each key in each duplicate keyset.
Migrating the Orange RPK(s) Using a Local PED Connection
If it is possible to gather all your existing orange keys into one place, you can also migrate your orange keys for Luna HSM Firmware 7.7.0 using a Luna PED connected directly to the Luna Network HSM 7 (see Local PED Setup).
To migrate the orange RPK(s) using a locally-connected Luna PED
1.Connect to the appliance via SSH or a serial connection, and log in to LunaSH as admin or a custom user with an admin role (see Logging In to LunaSH).
2.Log in to the HSM.
lunash:> hsm login
3.Ensure that the Luna PED is in Local-USB mode (see Changing Modes).
4.Ensure that you have the orange PED key(s) ready. Proceed as if you were initializing the Remote PED vector.
lunash:> hsm ped vector init
5.The Luna PED prompts you to confirm that you want to use an existing keyset. Press Yes.
6.The Luna PED prompts you to insert an orange key. Insert the orange key and press Enter.
7.The Luna PED informs you that this PED key must be migrated, and that the existing RPV will be preserved. It prompts you to confirm that you want to migrate this key. Press Yes.
•If you are migrating a single orange key (M = 1 and N = 1), the migration process begins, and takes about a minute.
The Luna PED then asks if you wish to migrate another key in this keyset. If you have duplicate orange keys to migrate, press Yes and repeat steps 6-7 for each duplicate.
•If you are migrating an M of N keyset, you must present the required M keys to reconstruct the RPV before the migration process can begin. Repeat steps 6-7 until you reach M keys. The migration process begins on the Mth key, and takes about a minute.
The Luna PED then asks if you wish to migrate another key in this keyset. Press Yes and repeat steps 6-7 for each key until all N keys have been migrated.
If you have duplicate orange M of N keysets, repeat steps 6-7 for each key in each duplicate keyset.
Migrating STC Connections to Luna HSM Firmware 7.7.0 or Newer
The following migration procedure must be performed in part by the HSM SO, and by the Partition SO and Crypto Officer for each STC partition on the HSM.
CAUTION! Certain essential steps in this procedure are destructive; ensure that all STC partitions on the HSM are fully backed up to avoid losing your cryptographic objects.
Prerequisites
>[Multifactor Quorum-authenticated] You require access to a Luna PED, updated to a supported firmware version:
•Luna PED Firmware 2.7.4 or newer for older Luna PED
•Luna PED Firmware 2.9.0 or newer for refreshed Luna PED
See Updating External Supply-Powered Luna PED Firmware.
>Update all clients to Luna HSM Client 10.3.0 or newer (see Updating the Luna HSM Client Software).
>You require a Luna Backup HSM 7 or Luna Backup HSM G5 with the following firmware:
•Luna Backup HSM 7 Firmware 7.7.1 or newer (see Updating the Luna Backup HSM 7 Firmware)
•Luna Backup HSM G5 Firmware 6.28.0 or newer (see Updating the Luna Backup HSM G5 Firmware)
Earlier firmware versions can be used for migration purposes, but after this procedure, the above mentioned minimum Backup HSM firmware versions are required to back up and restore the updated partitions.
Disabling STC Connections
To disable STC connections on a Luna HSM with Luna HSM Firmware 7.4.2 or older
1.Crypto Officer for each STC partition: Back up all cryptographic objects (see Partition Backup and Restore).
2.Partition SO for each STC partition: Disable Partition policy 37: Force Secure Trusted Channel (see Setting Partition Policies Manually).
At this point in the procedure, all affected partitions have been zeroized and are available to the client using NTLS connections. Partition roles and credentials are preserved.
3.HSM SO: If you have STC enabled on the admin channel, disable it (see Disabling the STC Admin Channel).
4.HSM SO: Disable HSM policy 39: Allow Secure Trusted Channel (see Setting HSM Policies Manually).
5.HSM SO: Proceed with the appliance software update (see Updating the Luna Appliance Software).
6.HSM SO: Install the HSM firmware update (see Updating the Luna HSM Firmware).
Re-establishing STC Connections
To re-establish STC connections after updating to Luna HSM Firmware 7.7.0 or newer
1.Delete the STC client soft token (token.db) that was initialized for STC connections prior to updating to Luna HSM Firmware 7.7.0 or newer. For more information about the location of token.db, refer to the description of SoftTokenDir in Configuration File Summary.
2.Partition SO for each STC partition: Re-establish the STC connection for each client and partition. Since the partitions are already initialized, use the following procedure. You must re-create the STC client identity on each affected client:
•Converting Initialized NTLS Partitions to STC
If you have STC partitions that are being accessed by multiple clients, each client must re-create the STC client identity and re-establish connections using the following procedure:
•Connecting an Initialized STC Partition to Multiple Clients
3.Crypto Officer for each STC partition: You may now restore your cryptographic objects from backup see Partition Backup and Restore).
Migrating a High Availability Partition Member to Luna HSM Firmware 7.7.0 or Newer
The following procedure is performed by the HSM SO for each Luna Network HSM 7 and the Crypto Officer for the HA group members.
Prerequisites
>You must be aware of the guidelines for upgrading an HA member partition to any firmware version and adhere to them carefully. For more information, read Guidelines and Recommendations For Updating or Converting HA Member Partitions.
NOTE You must update/convert secondary partitions first and the primary partition last. If you do not adhere to this guideline, you may experience issues while updating/converting.
>You require admin-level access to the Luna Network HSM 7 appliance.
>If you would like to preserve the cryptographic materials of HA group members during the migration, back up the contents of the HA group members to a Luna Backup HSM capable of restoring objects to partitions with Luna HSM Firmware 7.7.0 or newer:
•Luna HSM Firmware 7.7.0 and Newer Require Updated Luna Backup HSM 7 and Luna Backup HSM G5 Firmware
To migrate an HA member partition to Luna HSM Firmware 7.7.0 or newer
1.Remove the HSM from the HA group.
lunacm:> hagroup removemember
2.Disable the client-partition connection.
•If you have established an NTLS connection, use an SSH or serial connection to log in to one of the Luna Network HSM 7 appliances containing an HA group member partition as admin (see Logging In to LunaSH) and turn off the NTLS service on the appliance.
lunash:> service stop ntls
•If you have established an STC connection, follow the steps in Disabling STC Connections.
3.Update the firmware of the HSM containing the partition. For more information, refer to Updating the Luna HSM Firmware.
4.Re-enable client-partition connectivity completing one of the following steps:
•If you have established an NTLS connection, use an SSH or serial connection to log in to one of the Luna Network HSM 7 appliances containing an HA group member partition as admin (see Logging In to LunaSH) and turn off the NTLS service on the appliance.
lunash:> service restart ntls
•If you are re-establishing an STC connection, refer to Re-establishing STC Connections.
5.Confirm that the connection has resumed running on the appliance.
lunash:> service status ntls
lunash:> service status stc
6.Add the HSM containing the partition back to the HA group.
lunacm:> hagroup addmember
The partition has now been restored as an HA group member. Repeat the procedure for each HA member partition to migrate the entire HA group.
TIP After migrating the HA group, you can proceed with the following optional steps:
1.On the client workstation that administers the HA group, stop all client applications.
2.Update to Luna HSM Client 10.3.0 or newer (see Updating the Luna HSM Client Software).
3.You may now restart your client applications.
If you plan to convert the partitions from V0 to V1, then the above steps are mandatory. For more information, refer to V0 and V1 Partitions and Converting an HA group member partition from V0 to V1.
Migrating to the Newer High Availability Indirect Login Protocol
Migration to the newer HA Indirect Login protocol can proceed at up to two levels after updating the firmware. You can
1.migrate to HA Indirect Login protocol V1.1 by reusing the HA Login data that was set up before the update, and then
2.migrate to HA Indirect Login protocol V2 by setting up partitions for HA Login v2.
To migrate to the newer HA Indirect Login protocol
1.Migrate to HA Indirect Login protocol V1.1.
a. Manually log in to one of the partitions in the pool.
b.Use HA Indirect Login v1.1 to bring all other partitions in the pool online.
NOTE At this point the migration could stop and the partitions left at V0. You might not wish to modify your application code. Or you might have dependencies on older versions of the other protocols (STC, Cloning). However to benefit from the new features of Luna HSM Firmware 7.7.0 and newer, if desired, then v2 HA Indirect Login must be setup by following the procedure below.
2.Migrate to HA Indirect Login protocol V2.
a.Update your existing application with the latest API and Library.
b.Generate a new HA Login Key-Pair on one partition in the pool, and then clone the HA Login Private key to all partitions in the pool.
c.Register v2 HA Login on all partitions in the pool using the new HA Indirect Login Private Key. This step replaces the existing HA Login registration data such that only v2 protocol can be used.
d.Set Partition Policy 41: Partition Version to V1.
From this point on, partitions in the pool will only accept v2 HA Indirect Login as a secondary.
While the first part of the migration requires some manual operations (such as firmware update and re-authenticating to one member of the pool), the rest of the migration can be fully automated by the managing software.
