Activation on Multifactor Quorum-Authenticated Partitions
A multifactor quorum-authenticated partition requires an iKey each time a role (Partition SO, Crypto Officer, Crypto User) logs in. For some use cases, such as key vaulting, this physical key requirement is desirable. For many applications, however, it is impractical to require the full authentication procedure every time.
For these use cases, the Partition SO can activate the partition and set a secondary password referred to as a challenge secret. When a partition is activated, the HSM caches the Crypto Officer and Crypto User secrets upon first login, and subsequent logins require the challenge secret only. The iKey secret remains cached until the role is explicitly deactivated or the HSM loses power due to a reboot or power outage.
Activation does not provide much advantage for clients that log in to the partition and remain logged in. It is an indispensable advantage in cases where the client application repeatedly logs in to perform a task, and then logs out or closes the cryptographic session after the task is completed.
Tamper events and activation
When a tamper event occurs, or if an uncleared tamper event is detected on reboot, the cached iKey data is zeroized, and activation is disabled. See Tamper Events and Partition Capabilities and Policies for more information.
This section contains instructions for the following procedures:
>Enabling Activation on a Partition
Enabling Activation on a Partition
The Partition SO can enable activation on a partition by setting partition policy 22: Allow activation to 1 (on). This setting enables activation for the Crypto Officer and Crypto User roles. When partition policy 22 is enabled, the Partition SO can set an initial challenge secret for the Crypto Officer.
Prerequisites
>The partition must be initialized (see Initializing the Application Partition).
To enable activation on a partition
1.Log in to the partition as Partition SO (see Logging In to the Application Partition).
lunacm:> role login -name po
2.Enable partition policy 22.
lunacm:> partition changepolicy -policy 22 -value 1
Activating a Role
After enabling partition policy 22, activate the CO or CU roles on the partition. You must set a challenge password for each role you want to activate. The Partition SO must set the initial challenge secret for the Crypto Officer, who must set it for the Crypto User. The role becomes activated the first time the user logs in to the partition.
Prerequisites
>Partition policy 22: Allow activation must be enabled on the partition (see Enabling Activation on a Partition).
>The role you wish to activate must be initialized on the partition (see Initializing the Crypto Officer and Crypto User Roles).
To activate a role
1.Log in to the partition using the appropriate role (see Logging In to the Application Partition):
•If you are activating the Crypto Officer role, log in as Partition SO.
•If you are activating the Crypto User role, log in as Crypto Officer.
lunacm:> role login -name <role>
2.Set an initial challenge secret for the role you wish to activate. The length of the challenge secret is configurable by the Partition SO (see Partition Capabilities and Policies).
In LunaCM, passwords abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 !@#$%^&*()-_=+[]{}\|/;:',.<>?`~
Double quotation marks (") are problematic and should not be used within passwords.
Spaces are allowed; to specify a password with spaces using the -password or -newpw option of a command, enclose the password in double quotation marks.
lunacm:> role createchallenge -name <role>
NOTE Activation requires that a challenge secret is set for the specified role. If the role does not have a challenge secret, you are prompted for the iKey, regardless of the policy setting.
3.Log out of the partition.
lunacm:> role logout
4.Provide the initial challenge secret to the designated CO or CU by secure means. The iKey secret is cached when they log in for the first time. The CO or CU can store the black or gray iKey in a safe place. The cached iKey secret allows their application(s) to open and close sessions and perform operations within those sessions.
NOTE If HSM policy 21: Force user PIN change after set/reset is enabled (this is the default setting), the CO or CU must change the challenge secret before any other actions are permitted. See Changing a Role Credential.
Deactivating a Role
An activated role on a partition remains activated until it is explicitly deactivated, or the HSM loses power due to a reboot or power outage. This deletes the cached authentication secret for the role.
Prerequisites
>You must be authorized to deactivate the role. The CO and CU can manually deactivate their own or each other's roles. The Partition SO can deactivate both the CO and CU roles.
To deactivate a role on a partition
1.Log in to the partition with the appropriate role (see Logging In to the Application Partition).
lunacm:> role login -name <role>
2.Specify the role you wish to deactivate.
lunacm:> role deactivate -name <role>
This deletes the cached authentication credential for the role. The next time the role logs in, the credential is re-cached.
3. If you wish to disable activation entirely, so that credentials are not re-cached at the next login, the Partition SO can disable partition policy 22: Allow activation.
lunacm:> partition changepolicy -policy 22 -value 0
