High Availability Indirect Login Functions Prior to HSM Firmware 7.7

NOTE   In order to implement High Availability Recovery, the primary and secondary tokens must exist on separate systems.

The post-firmware-7.7.0 version of HA Indirect Login is at HA Indirect Login (firmware 7.7.0 and newer).

Overview of Indirect Login

Indirect Login (HA Login, not to be confused with the Luna Client-mediated HA feature) 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 existing pre-firmware-7.7.0 version of HA Login (v1), this is 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.

HA 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 in sections 4, 5 and 6 where the individual versions of the HA Login Protocol are defined.

HA Login Exchange:

The HA Login Exchanges 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. The specific APIs and their calling sequence are defined in sections 4, 5 and 6 where the individual versions of the HA Login Protocol are defined.

HA Login HSM and Partition Policies:

There are no HSM level policies related to the HA 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 Login Setup or an HA 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 section 7. Any additional restrictions put on the HA Login Public and Private Keys are defined in the protocol version specific sections in this document.

HA Indirect Login Protocol

The version of the HA Indirect Login Protocol discussed here is used by all HSMs running firmware version 6.0.0 and later, up to but not including firmware version 7.7.0. For post-firmware 7.7.0 implementation, see HA Indirect Login (firmware 7.7.0 and newer) .

Changes Made To the Earlier Protocol  

The prior protocol has been in use for many years. In that time it has received two major changes. This section describes both of those changes and explains how it affects the HA Login Protocol.

Support for the HA Login Public Key

Prior to firmware version 6.10.0, the firmware required that the HA Login Private Key be cloned to the secondary partition so that a role on the secondary partition can be initialized for HA Login. Firmware 6.10.0 was updated such that the HA Login Public key could be used to initialize a role on the secondary partition. This eliminated the need to first initialize the secondary partition with the same cloning domain as the primary so that the HA Login Private Key could be cloned. Now the HA Login Public key can be extracted and re-created on the secondary directly.

The public key based setup is typically used when the secondary should only be able to act as a secondary and should not be able to act as a primary. If both partitions should be able to act as the primary and secondary, then the HA Login Private Key based setup should be used.

Per-Partition SO

Firmware version 6.22.0 introduced the Per-Partition SO (PPSO) feature. This feature introduced a new partition type (PPSO partition) that supports its own security officer role, the Partition Security Officer (PSO), as well as a greater level of role separation between the Crypto-Officer and Crypto-User.

The existing role behavior was maintained and was available through the use of a Legacy pre-PPSO Partition. Non-PPSO partitions were deprecated in 7.x HSMs, but are mentioned here for anyone seeking to migrate from older Luna HSMs.

On a Legacy pre-PPSO Partition, 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 authenticated state will be restored by an HA Login exchange.

On a PPSO partition, only the Crypto-Officer can be setup for HA Login.

Cryptographic Primitives

The pre-7.7.0 HA Login Protocol makes use of the following cryptographic primitives for the purposes of key wrapping and key transport:

AES-256-ECB Encryption/Decryption

RSA-PKCS v1.5 Encryption/Decryption

During HA Login Setup, a random AES 256-bit is wrapped using RSA-PKCS v1.5.

The HA Login Exchange is essentially key transport operation that is used to transport wrapped key material from the secondary to the primary, and then wrapped key material sent back to the secondary from the primary.

The key-transport is performed using RSA-PKCS v1.5, and it transports the random AES 256-bit which was wrapped using RSA-PKCS v1.5 during HA Login Setup.

The key material sent back to the secondary from the primary is wrapped using AES-256-ECB.

Initialization functions

Initialization of tokens in a high-availability environment involves three steps:

1.The generation of an RSA login key pair (the public key of the pair may be discarded),

2.Cloning of the private key member to the User (and optionally to the SO) spaces of all tokens within that environment and,

3.Calling the CA_HAInit function on all tokens within that environment, in the context of the session owned by the User or SO.  

The first two steps are performed using ordinary key generate and cloning Cryptoki function calls. The CA_HAInit function is implemented as follows:

CA_HAInit()

CK_RV CK_ENTRY CA_HAInit(
CK_SESSION_HANDLE hSession, // Logged-in session of user
// who owns the Login key pair
CK_OBJECT_HANDLE hLoginPrivateKey // Handle to Login private key
);

Recovery Functions

The HA recovery mechanism requires the following commands and interface functions:

CA_HAGetMasterPublic()

Called on the primary token, CA_HAGetMasterPublic() retrieves the primary token's TWC (Token Wrapping Certificate) and returns it as a blob (octet string and length).  The format of this function is as follows:

CK_RV CK_ENTRY CA_HAGetMasterPublic(
CK_SLOT_ID slotId, // Slot number of the primary
// token
CK_BYTE_PTR pCertificate, // pointer to buffer to hold
//TWC certificate
CK_ULONG_PTR pulCertificateLen // pointer to value to hold
//TWC certificate length
);

CA_HAGetLoginChallenge()

Called on the secondary token, CA_HAGetLoginChallenge() accepts the TWC blob and returns the secondary token's login challenge blob.  The format of this command is as follows:

CK_RV CK_ENTRY CA_HAGetLoginChallenge(
CK_SESSION_HANDLE hSession, // Public session
CK_USER_TYPE userType, // User type - SO or USER
CK_BYTE_PTR pCertificate, // TWC certificate retrieved
// from primary
CK_ULONG ulCertificateLen, // TWC certificate length
CK_BYTE_PTR pChallengeBlob, // pointer to buffer to hold
// challenge blob
CK_ULONG_PTR pulChallengeBlobLen // pointer to value to hold
// challenge blob length
);

CA_HAAnswerLoginChallenge()

Called on the primary token, CA_HAAnswerLoginChallenge() accepts the login challenge blob and returns the encrypted SO or User PIN, as appropriate.

CK_RV CK_ENTRY CA_HAAnswerLoginChallenge(
CK_SESSION_HANDLE hSession, // Session of the Login Private
// key owner
CK_OBJECT_HANDLE hLoginPrivateKey, // object handle to login key
CK_BYTE_PTR pChallengeBlob, // pointer to buffer containing
// challenge blob
CK_ULONG ulChallengeBlobLen, // length of challenge blob
CK_BYTE_PTR pEncryptedPin, // pointer to buffer holding
// encrypted PIN
CK_ULONG_PTR pulEncryptedPinLen // pointer to value holding
// encrypted PIN length
);

CA_HALogin()

Called on the secondary token, CA_HALogin() accepts the encrypted PIN and logs the secondary token in. If the second-ary token requires MofN authentication, an MofN challenge blob is returned.  If no MofN authentication is required, a zero-length blob is returned. The format of this function is as follows:

CK_RV CK_ENTRY CA_HALogin(
CK_SESSION_HANDLE hSession, // Same public session opened
// in CA_HAGetLoginChallenge, 
//above
CK_BYTE_PTR pEncryptedPin, // pointer to buffer holding
// encrypted PIN
CK_ULONG ulEncryptedPinLen,  //  length of encrypted PIN
CK_BYTE_PTR pMofNBlob, // pointer to buffer to hold
// MofN blob
CK_ULONG_PTR pulMofNBlobLen // pointer to value to hold the
// length of MofN blob
);

If the call is successful, then the session now becomes a pri-vate session owned by the User or SO (as appropriate).

CA_AnswerMofNChallenge()

Called on the primary token, CA_AnswerMofNChallenge() accepts the MofN challenge blob and returns the primary token's masked MofN secret.  The format of this function is as follows:

CK_RV CK_ENTRY CA_HAAnswerMofNChallenge(
CK_SESSION_HANDLE hSession, // Private session
CK_BYTE_PTR pMofNBlob, // passed in MofN blob
CK_ULONG ulMofNBlobLen, // length of MofN blob
CK_BYTE_PTR pMofNSecretBlob, // pointer to buffer to hold
// MofN secret blob
CK_ULONG_PTR pulMofNSecretBlobLen//pointer to value that holds
// the MofN secret blob len
);

CA_HAActivateMofN()

Called on the secondary token, CA_HAActivateMofN() accepts the masked MofN secret and performs MofN authentication.  The resulting MofN secret is checked against the CRC stored in the MofN PARAM structure.

CK_RV CK_ENTRY CA_HAActivateMofN(
CK_SESSION_HANDLE hSession, // The now-private session from
// successful CA_HALogin call
CK_BYTE_PTR pMofNSecretBlob, // pointer to MofN secret 
// blob that is passed in
CK_ULONG ulMofNSecretBlobLen // length of MofN secret blob
);

It is expected that the recovery functions will be executed in the proper sequence and as part of an atomic operation.  Nonetheless, the recovery operation may be restarted at any time due to an error.  Restarting the recovery operation resets the state condition of the secondary token, and any data that has been stored or generated on the token is discarded.

Login Key Attributes

The login keys must possess the following attributes to function properly in a HA recovery scenario:

// Object
CKA_CLASS = CKO_PRIVATE_KEY,
// StorageClass
CKA_TOKEN = True,
CKA_PRIVATE = True,
CKA_MODIFIABLE = False,
// Key
CKA_KEY_TYPE = CKK_RSA,
CKA_DERIVE = False,
CKA_LOCAL = True,
// Private
CKA_SENSITIVE = True,
CKA_DECRYPT = False,
CKA_SIGN = False,
CKA_SIGN_RECOVER = False,
CKA_UNWRAP = False,
CKA_EXTRACTABLE = False

Control of HA Functionality

Refer to for the mechanisms by which the SO can control availability of the HA functionality.