HA Indirect Login (firmware 7.7.0 and newer)

High Availability Options for Luna HSMs

Luna HSMs support two, non-overlapping approaches to High Availability:  

>client-mediated HA creation and management of HA groups, by means of the LunaCM hagroup commands, with preparation, management, and usage described at High-Availability Groups  (this is believed to be the majority of HA implementations among Luna HSM customers)

  versus

>extensions to the PKCS#11 API to allow interested customers to create and maintain High Availability programmatically.

That is, if you want the redundancy and performance of High Availability,

>you can do what many Luna HSM customers do and use LunaCM commands to declare and manage HA groups and their membership, while relying on the Luna Client library to carry out the day-to-day infrastructure and activity

or

>you can program your own complete HA environment, in full, or tie into (integrate with) suitable COTS High Availability solutions that provide a suitable Application Interface, using HA Indirect Login calls to handle common authentication among HSM partitions in groups.

The latter feature, notably in its updated form, from HSM firmware version 7.7.0 (and newer), is described in this section. (If, instead, you were looking for Client-mediated HA, see High-Availability Groups .

HA Indirect Login (firmware 7.7.0 and newer) Overview

High Availability Indirect Login (HA Login) allows a secondary partition to be configured to cache the authentication state for a user and for these cached credentials to be used to re-achieve an authenticated state using the HA Indirect Login exchange between the secondary partition and the primary partition. In the pre-existing versions of HA Indirect Login, this was achieved by caching the login credentials for a user.

HA Login can be viewed as two distinct steps; HA Login Setup and an HA Login exchange.

USAGE NOTE In a mostly unrelated connection,

>HSM application partitions that are created with default setting on a firmware 7.7.0 (or newer) HSM, or partitions that pre-existed and go through a firmware update to version 7.7.0 or newer, are Version Zero (a.k.a. V0), meaning that they are "backward compatible" and use cloning for replicating and archiving keys and objects, while

>HSM application partitions created on a f/w 7.7.0 (or newer) HSM with -version option set to 1, or updated from V0 by changing partition polity 41 to 1 are Version One (a.k.a. V1), and use cloning only

•inbound for migration purposes

•outbound/inbound for ongoing management of SMKs

and all other keys and objects are archived or "copied" to other HSMs or saved in external databases/file systems by means of Scalable Key Storage (SKS) .

HA Indirect Login Setup

HA Login Setup requires the generation of an RSA key-pair to be used as the HA Login Public and Private keys. HA Login Setup is then done by transferring some of the HA Login Public/Private key material to a secondary partition and calling the CA_HAInit() API as an authenticated role on the secondary partition.

The key material that needs to be transferred varies based on the version of the HSM being used. It may be the HA Login Private Key, the HA Login Public Key or a PKC chain for the HA Login Private Key. The specific key material required is defined later.

HA Indirect Login Exchange

The HA Login Exchange is the specific exchange of information between a primary partition and a secondary partition used to achieve an authenticated state on the secondary partition.

The exchange of information is performed using a set of PKCS#11 extensions that are dedicated to the HA Login Protocol.

HA Indirect Login HSM and Partition Policies

There are no HSM level policies related to the HA Indirect Login Protocol.

Each partition has a policy called ‘allow high availability recovery’. This policy must be enabled for any partition (primary or secondary) to take part in HA Indirect Login Setup or an HA Indirect Login Exchange.

HA Login Public and Private Keys

The HA Login Public and Private Keys are a standard user RSA key-pair on the partition. As such, it is possible for any authorised role on the primary partition to make use of the HA Login Public and Private Keys in the context of HA Login Setup and/or an HA Login exchange.

For the HA Login Public and Private Keys to be valid for use with the HA Login Protocol, they must have all of their key-usage attributes set to false. The required attribute templates are defined in later sections. Any additional restrictions put on the HA Login Public and Private Keys are defined in the protocol version specific sections in this document.

HSM Roles

The HSM supports many different roles which vary depending on which version of the product is being referenced and which types of partition is being discussed. The next two tables define which roles are supported on which versions and which roles support HA Login Setup.

Roles that can generate the HA Indirect Login public/private key-pair

    Roles
Firmware
Versions  		   HSM SO HSM Admin Audit PSO Crypto Officer Limited Crypto Officer Crypto User
< 6.22.0 (pre-PPSO) Yes N/A2 No N/A2 Yes1 N/A2 No
>= 6.22.0 < 7.7.0 Yes Yes No No Yes N/A2 No
>= 7.7.0 Yes Yes No No Yes Yes No

Roles that can be set up for HA Indirect Login

    Roles
Firmware
Versions  		   HSM SO HSM Admin Audit PSO Crypto Officer Limited Crypto Officer Crypto User
< 6.22.0 (pre-PPSO) Yes N/A2 No N/A2 Yes1 N/A2 Yes1
>= 6.22.0 < 7.7.0 Yes Yes No No Yes N/A2 No
>= 7.7.0 Yes Yes No No Yes Yes Yes

1 On pre-PPSO partitions (before Partition SO was introduced), the partition maintains only a single HA Login state. This means that the partition can be setup for HA Indirect Login for a single login only. For example, if the CO calls the CA_HAInit() API, then the HA Indirect Login state stores the role ID for the CO and the CO authentication state can be re-achieved using the HA Indirect Login Protocol. If the CU then decides to call the CA_HAInit() API, this overwrites the current HA Indirect Login state with the role ID for the CU. This means that the CO authentication state can no longer be re-achieved using the HA Indirect Login Protocol, an HA Indirect Login exchange with this partition will now achieve only the CU authentication state.

2 This role does not exist on this version.

TIP   Where you have an HA Indirect Login setup, your HSM is made accessible by other HSMs.

Adding a challenge secret to your role, that is unknown to other parties, does not prevent other parties from logging into your HSM.

Rather it prevent other parties from using your particular role without that extra credential.

To prevent other parties accessing your HSM, change the PIN.  

 

Setup HA Indirect Login

In this section, the abbreviations "V0" and "V1" refer to partition versions and infrastructure that come with HSM firmware version 7.7.0 (or newer), including the new cloning regime and SKS in V1. The distinctions between the V0 and V1 partition structures, and their behavior, are the reason for the existence of this page.

Separately, HA Indirect Login has existed for a long time and has gone through several iterations, where

>HA Indirect Login version 1.0 was introduced in an earlier-hardware HSM 6.x and continues through 7.x up-to-but-not-including-7.7;

>HA Indirect Login version 1.1 applies to HSM firmware 7.7.0 mainly as a bridge to version 2.0, and;

>HA Indirect Login version 2.0 is introduced with HSM firmware 7.7.0, to account for structural changes and modernization.

So you might be starting with version 2.0, or you might have migrated from older implementations and need to update.

To setup HA Indirect Login between primary partition and a secondary partition the following steps should be followed:

1.Login to the primary partition as the Crypto-Officer.  

2.Generate the HA Indirect Login Public/Private key pair.  

3.If a secondary should not act as primary, then request a PKC chain for the HA Login Private Key. Otherwise set up the HA Login private on secondary using cloning for V0 partition, or using SKS for V1 partition.  

4.Log into the secondary partition as the role you wish to setup for HA Indirect Login.

NOTE   As part of the firmware 7.7.0 (or newer) Indirect Login version, all roles on the HSM can be setup for HA Login on the secondary partition.

If firmware 7.7.0 (or newer) setup has already been established, then first revoke current HA Login credential and allowed primary roles. All sessions opened on this partition, except the current one, will be implicitly closed.

If HA Indirect Login version 1.1 setup has been done then no need to revoke. All sessions opened on this partition, except current one, will be implicitly closed.

5.If the secondary is not to be permitted to act as primary, then initialize the role on the secondary partition for HA Indirect Login by passing the PKC and allowed primary roles in to the CA_HAInitExtended() API; otherwise the handle of the private login key and allowed primary roles must be passed in. Primary roles, when logged in as primary, are allowed to log in on the secondary as the role currently logged in. It is possible to later update or change the allowed primary roles.

a.Allowed roles are Security Officer, Administrator, Crypto Officer, Crypto User and Limited Crypto Officer.  

b.Partition Officer and Auditor do not have access to any key, and therefore are not able to log in using HA Private Key, and thus cannot be valid primary roles.  

c.If an allowed role is updated with different roles then any opened session is closed except current one.

Step 5 can be repeated to add additional partitions to the HA Indirect Login group. To act as a primary partition, a partition requires a copy of the HA Login Private Key.

• For V0 partitions this would require cloning the HA Login Private Key to any additional partitions that need to act as a primary partition.

•For V1 partitions it would require SKS extracting the HA Login Private Key from the first partition and inserting to any additional partitions that need to act as a primary partition.

The figure below shows the version 2 HA Indirect Login Setup using the new APIs.

Perform HA Indirect Login Exchange

To perform an HA Indirect Login exchange, the following steps must be performed:

1.Login to the primary partition as a role on the partition that has access to the HA Login Private Key and can act as a primary in an HA Login Exchange.  

2.Call CA_HAGetMasterPublicData() on the primary, passing in the handle to the HA Login Private Key and retrieve the Master Public Data (public certificates required by the secondary).  

3.Call CA_HAGetLoginChallenge() on the secondary partition, passing in the role ID that is to be authenticated, the Master Public Data from the primary partition (the TWC of the primary and a PKC chain for the HA Login Private Key) and receive the challenge from the secondary partition.  

4.Call CA_HAAnswerLoginChallenge() on the primary passing in challenge received from the secondary partition along with the key handle of the HA Login Private Key and receive the challenge response.  

5.Call CA_HALogin on the secondary and pass in the challenge response received from the primary partition. Upon success the user is logged in on secondary partition.

HA Indirect Login Public and Private Key Templates

The HSM requires that the HSM Login Private Key and HA Login Public Key have a very restricted set of attribute values to prevent the keys from being abused. Every time the HSM makes use of an HA Login Public/Private Key, it verifies that its attributes match the templates defined below.

HA Login Private Key:

static struct { AttributeId Id; ATTR_VAL ExpVal; UInt32 Size; } attrTbl[] =
{
   // Object
   { CKA_CLASS,               { CKO_PRIVATE_KEY },  sizeof( ClassAttribute ) },

   // StorageClass
   { CKA_TOKEN,               { true },             sizeof( Boolean ) },
   { CKA_PRIVATE,             { true },             sizeof( Boolean ) },
   { CKA_MODIFIABLE,          { false },            sizeof( Boolean ) },

   // Key
   { CKA_KEY_TYPE,            { CKK_RSA },          sizeof( KeyTypeAttribute ) },
   { CKA_DERIVE,              { false },            sizeof( Boolean ) },
   { CKA_LOCAL,               { true },             sizeof( Boolean ) },

   // Private
   { CKA_SENSITIVE,           { true },             sizeof( Boolean ) },
   { CKA_DECRYPT,             { false },            sizeof( Boolean ) },
   { CKA_SIGN,                { false },            sizeof( Boolean ) },
   { CKA_SIGN_RECOVER,        { false },            sizeof( Boolean ) },
   { CKA_UNWRAP,              { false },            sizeof( Boolean ) },
   { CKA_EXTRACTABLE,         { false },            sizeof( Boolean ) },
   { CKA_NEVER_EXTRACTABLE,   { true },             sizeof( Boolean ) }
};

HA Login Public Key:

static struct { AttributeId Id; ATTR_VAL ExpVal; UInt32 Size; } attrTbl[] =
{
   // Object
   { CKA_CLASS,               { CKO_PUBLIC_KEY },   sizeof( ClassAttribute ) },

   // StorageClass
   { CKA_TOKEN,               { true },             sizeof( Boolean ) },
   { CKA_PRIVATE,             { true },             sizeof( Boolean ) },
   { CKA_MODIFIABLE,          { false },            sizeof( Boolean ) },

   // Key
   { CKA_KEY_TYPE,            { CKK_RSA },          sizeof( KeyTypeAttribute ) },
   { CKA_DERIVE,              { false },            sizeof( Boolean ) },

   // Private
   { CKA_ENCRYPT,             { false },            sizeof( Boolean ) },
   { CKA_VERIFY,              { false },            sizeof( Boolean ) },
   { CKA_VERIFY_RECOVER,      { false },            sizeof( Boolean ) },
   { CKA_WRAP,                { false },            sizeof( Boolean ) }
};

Use Cases

The HA Indirect Login feature is typically used in two ways, as follows.

Single Primary HSM with many Secondary HSMs

It is possible to setup a model where a single primary partition is able to HA Indirect Login to one or more secondary partitions. In this model, only the primary partition needs to be in possession of the HA Login Private Key.

This corresponds with the Crypto Command Center (CCC) use case, wherein one HSM acts as a root of trust and is able to HA Indirect Login to the HSM SO role on all other HSMs. This allows CCC to remotely administer the HSM.

Pool of HSMs that can act as the Primary

It is also possible to setup a pool of partitions such that they can all act as the primary in an HA Login exchange, to all other members in the pool. In this setup it is an application monitor the pool of partitions and, if any members goes down (for example, power loss, network outage), any other members that are still online can use the HA Login exchange to restore that member to an authenticated state without any user intervention. This is the original use case for the HA Indirect Login feature.

This model does not require the use of auto-activation in PED-authenticated HSMs, but the challenge secret must still be provided.

To set this up, each partition must have a copy of the HA Login Private Key and the desired role, and each partition must be initialized to use HA Indirect Login.

NOTE   The HA Login Private key must have the attribute CKA_NEVER_EXTRACTABLE set to TRUE which means that it must be transferred to the other HSMs using cloning if partition has V0 for Policy 41.

SKS is used for this purpose in V1 partitions. All partitions MUST be in the same cloning domain and the SMK secret should have previously been cloned to them.

Due to an incompatibility with the new cloning regime, when a partition is V0 (because you created it that way, or because a partition already existed when you updated to firmware 7.7.0 or newer), a Client library contemporaneous with firmware 7.7.0, or newer, is required if you wish to use the older HA Indirect Login APIs described elsewhere in this document.

Backward Compatibility

As described What are "pre-firmware 7.7.0", and V0, and V1 partitions?, and in the next section, among other sections dealing with firmware 7.7.0 (and newer), you might be dealing with newly created application partitions, or you might be migrating established, pre-existing partitions.

Any existing partition becomes a V0 partition when HSM firmware is updated to version 7.7.0 or newer, to preserve as much compatibility as possible with your existing applications, while setting some necessary infrastructure for firmware 7.7.0 features and future developments.

A newly created partition defaults to V0 and assumes the Luna use-case - just as with updated partitions, the purpose is to support older libraries and applications where needed.

A newly created partition can, optionally, be V1 for compliance and smooth operation in the eIDAS use-cases, or a V0 partition can be converted to V1 by changing policy 41.

The specifics of migration, in consideration of HA Indirect Login, are described in the next section and in Migration.

Firmware Update to Firmware Version 7.7.0 or Newer

After firmware update to firmware 7.7.0 (or newer), all pre-existing pre-7.7.0 partitions are updated with Partition policy 41 set to partition version zero (V0).

A V0 partition, as primary, supports HA Indirect Login protocol version 1, version 1.1, and version 2 (the most recent).
A V0 partition, as secondary, supports HA Indirect Login protocol version 1.1 and version 2.

The version 1.1 protocol support serves three purposes:

>It allows any HA Login state that was configured on these partitions pre-update to be used post-update. Customerd do not need to manually login and setup HA Login again. Customers that have written their own custom HA Login code might not not need to re-write their application if buffers used to transfer data from primary to secondary HSM during login process are large enough. They can continue to use the old HA Login APIs on these partitions.  

>It allows customers to continue to operate in FIPS approved mode after they update their HSM without setting up version 2 HA Login. Clients are not forced into non-FIPS mode during firmware update. The version 1 HA Indirect Login protocol was never FIPS compliant, whereas the version 1.1 protocol is compliant. The version 1.1 protocol re-uses the version 1 setup data where that is available.  

>It provides a gateway to migrate partitions to version 2 HA Indirect Login and then to partitions from V0 to V1 (policy 41) while maintaining HA Indirect Login functionality.

The HA Indirect Login version 2 protocol support on V0 partition allows interested customers to use version 1.1 protocol to access their partition to setup V2 protocol. They can then use V2 protocol, and eventually change policy 41 to convert the partition to V1. This migration can be fully automated.

A V1 partition ( policy 41) as primary supports all versions, but as secondary, supports only version 2 protocol, so prior to converting partitions from V0 to V1, you must perform setup of HA Indirect Login version 2 protocol. Otherwise, you will need to manually login to setup HA Indirect Login version 2 protocol.

API Compatibility for HA Indirect Login Setup

Primary

Secondary

Library

version1/version1.1 API For Setup

version2 API For Setup

Pre-Firmware 7.7

Firmware 7.7.0 Partition V0

Pre-7.7

Supported

APIs Not Available

Pre-Firmware 7.7

Firmware 7.7.0 Partition V0

7.7

Supported

Not Supported

Pre-Firmware 7.7

Firmware 7.7.0 Partition V1

Pre-7.7

Not Supported

APIs Not Available

Pre-Firmware 7.7

Firmware 7.7.0 Partition V1

7.7

Not Supported

Not Supported

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V0

Pre-7.7

Supported

APIs Not Available

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V0

7.7

Supported

Supported

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V1

Pre-7.7

Not Supported

APIs Not Available

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V1

7.7

Not Supported

Supported

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V0

Pre-7.7

Supported

APIs Not Available

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V0

7.7

Supported

Supported

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V1

Pre-7.7

Not Supported

APIs Not Available

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V1

7.7

Not Supported

Supported

NOTE   On a Legacy pre-PPSO Partition (meaning all 5.x firmware HSM partitions as well as all 6.x up to firmware 6.22 and then some post-6.22 partitions, optionally - 7.x HSMs are PPSO-only), when HA Login is setup, the Crypto-Officer or the Crypto-User is required to execute the command to setup HA Login. The role ID of the role that issues the command is stored in the partition so that when the HA Login exchange is performed, the same level of authentication as the role that setup HA Login is restored. The Legacy per-PPSO Partition only maintains one set of state information for HA Login. This means that at any time, the Crypto-Officer or the Crypto-User can re-issue the HA Login setup command to override which role’s authenticate state will be restored by an HA Login exchange.

On a PPSO partition, the Crypto-Officer and Crypto-User have a greater level of separation and as such the PPSO partition maintains HA Login state for both the Crypto-Officer and Crypto-User. However due to a quirk of the PPSO feature, only the Crypto-Officer can be setup for HA Login.

API Compatibility for HA Indirect Login Exchange

Primary

Secondary

Library

version1/version1.1 API For HA Login Exchange  

version2 API For HA Login Exchange  
Firmware 7.7.0 V0  

Pre-Firmware 7.7.0

Pre-Firmware 7.7.0

Not Supported  

APIs Not Available  
Firmware 7.7.0 V0   Pre-Firmware 7.7.0 Firmware 7.7.0 (or newer)

Supported  

Not Supported  
Firmware 7.7.0 V1   Pre-Firmware 7.7.0 Pre-Firmware 7.7.0

Not Supported  

APIs Not Available  
Firmware 7.7.0 V1   Pre-Firmware 7.7.0 Firmware 7.7.0 (or newer)  

Supported  

Not Supported  

Pre-Firmware 7.7

Firmware 7.7.0 Partition V0

Pre-Firmware 7.7

Supported

APIs Not Available  

Pre-Firmware 7.7

Firmware 7.7.0 Partition V0

Firmware 7.7

Supported

Not Supported  

Pre-Firmware 7.7

Firmware 7.7.0 Partition V1

Pre-Firmware 7.7

Not Supported

APIs Not Available

Pre-Firmware 7.7

Firmware 7.7.0 Partition V1

Firmware 7.7

Not Supported

Not Supported

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V0

Pre-Firmware 7.7

Supported

APIs Not Available

Firmware 7.7V0  

Firmware 7.7.0 Partition V0

Firmware 7.7

Supported

Supported

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V1

Pre-Firmware 7.7

Not Supported

APIs Not Available

Firmware 7.7.0 V0  

Firmware 7.7.0 Partition V1

Firmware 7.7

Not Supported

Supported

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V0

Pre-Firmware 7.7

Supported

APIs Not Available

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V0

Firmware 7.7

Supported

Supported

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V1

Pre-Firmware 7.7

Not Supported

APIs Not Available

Firmware 7.7.0 V1

Firmware 7.7.0 Partition V1

Firmware 7.7

Not Supported

Supported

Migration Paths for HA Indirect Login Users

This section explains how existing customers that use HA Indirect Login can migrate their environments to firmware 7.7.0 (or newer) and use either the v1.1 or v2 protocol.

Migration is addressed at multiple levels.

>Firmware update of the HSM and partitions have partition policy 41 Partition Version set to V0.

>Post update, reusing the HA Login data that was setup before the update as part of the V1.1 protocol

>Setting up partitions for HA Login v2

>Finalize migration by setting partition policy 41 Partition Version to V1

Migration Path for the Pool-of-Partitions Use Case

In the pool-of-partitions use case, all members of the pool should be capable of, and using, the same version of HA Indirect Login, otherwise all members are not able to act as a primary.

When migrating a pool of partitions, all partitions need to be migrated at the same time.

The migration process is the following:

1.For Luna Network HSM appliance, update the appliance software, or for a local Luna PCI HSM update the Client, to version 7.7.0 or newer.

2.Update the firmware on the pool of partitions to firmware 7.7.0 (or newer). As part of this update, the existing partitions become V0.

3. After the firmware update, manually log into one of the partitions in the pool, then use HA Indirect Login v1.1 to bring all other partitions in the pool online.

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 firmware version 7.7.0 and newer, if desired, then v2 HA Indirect Login must be setup and the migration process is the following:

4.Update your existing application with the latest API and Library.

5.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.

6.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.

7.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.