General guidelines for updating or converting of HA member partitions

For full HA functionality, all members of a working HA group should be identical in firmware version and partition type. For best results, the Client library, that enables HA among several HSM, should be the most current available.

>Expect HA functionality (with some caveats) when members have been updated, but not during firmware update to version 7.7.0 (or newer) or during conversion of member partitions from V0 to V1.

>The kind of HA discussed here, is mediated by the Client library. If you are updating firmware from pre-7.7.0 to version 7.7.0 (or newer), while continuing to use a Client version earlier than 10.3.0, then as your HA group members are converted (by the firmware update) into V0 partitions, note these HA considerations:   

•A V0 partition on an appliance with HSM firmware 7.7.0 (or newer) can be added to an existing HA group that already has HA members made up of partitions from HSM with pre-version-7.7.0 firmware .

–ha addMember command functions as expected.

–When cloning objects from HSM firmware earlier than 7.7.0 into V0 partition, the size of the object increases.

•ha createGroup functions as expected using V0 partition.

•ha deleteGroup functions as expected on a HA group containing V0 partition.

•A V0 partition on an appliance with HSM firmware 7.7.0 (or newer) can be removed from an existing HA group.

–ha removeMember command functions as expected.

•A V0 partition on an appliance with HSM firmware 7.7.0 (or newer) can be added as a standby member of an existing HA group.

–ha addStandby command functions as expected.

•After a V0 partition on an appliance with HSM firmware 7.7.0 (or newer) is added as a member of an existing HA group, it can be synchronized with other members of the HA group.

–ha syncrhonize command functions as expected.

–As described in ha addMember section above, synchronization from partition in pre-7.7.0-firmware HSM to V0 partition may fail due to storage limitation.

•When V0 partition in a HA group becomes a primary partition, synchronization with other members on a pre-7.7.0-firmware HSM is not supported.

•V1 partition can be added to an existing HA group that already has HA members made up of partitions from a pre-7.7.0-firmware HSM. However, when V1 partition becomes the primary member of the HA group, synchronization with remaining member of the HA group will no longer function.

>Cloning of keys and objects can proceed only from a lower-security environment (in this context, pre-7.7.0) to a higher-security environment (firmware 7.7.0 or newer), but not in the other direction.

>Members of HA groups must all be at the same level. Perform an update from pre-7.7.0 firmware to 7.7.0 (or newer) - which invokes conversion of partitions to V0 as an effect of the update - while the partition is not a member of an HA group.

>An HA group with V1 partitions must have all members at V1 and all members sharing the same SMK.

>A V1 partition cannot be a member of more than one HA group unless both groups have the same SMK.

>An HA group with V0 partitions should have all members at V0; the new, more secure cloning protocol, and changes to key attributes mean that attempting to mix pre-firmware-7.7.0 partitions with V0 partitions is not recommended and would not work as expected.

>If a member of an existing HA group is added to a different HA group with a different SMK, the new member takes on the SMK of the new HA group and ceases to function properly in its original group (and should be removed).

>Converting a partition from V0 to V1 preserves contents, and should be done while the partition is not in an HA group.

>Converting a partition from V1 to V0 is destructive, so the partition cannot remain an HA member.

>Similarly, cloning of keys and objects can proceed from partitions of an HSM that has had Functionality Modules enabled into partitions that have never had Functionality Modules enabled, but not in the other direction. Again, firmware updates should take place outside of HA groups.

Avoid direct access to individual HA group members when securing with STC

This is best ensured by having HAonly setting turned ON, in the configuration file, so that only the HA virtual slot is visible and all requests and responses are handled transparently by the HA system ( see Configuration File Summary ). If you cannot avoid directly accessing an individual HA member slot, then be sure to log out of it before your application attempts to use the HA virtual slot. This is especially important when STC is invoked ( see Client-Partition Connections ).

Each HSM keeps track of any appid registered against a remote connection, and rejects any attempt to create a new session with different appID from the same client. That is, only one access ID is permitted per STC channel. If a client opens a session directly to an individual HA member partition, then an ID is assigned. If the client next attempts operation via the HA virtual slot, then as part of that process, random appids are assigned to each member partition for the open channel, but one of those member partitions already has the earlier ID, so the HSM responds with CKR_ACCESS_ID_ALREADY_EXISTS and the operation fails.

Log out of any individual member slot, before invoking the HA slot, to avoid this problem.