Activation and Auto-activation on Multi-factor- (PED-) Authenticated Partitions
A multi-factor-authenticated partition (also known as PED-authenticated) requires a PED key each time a role (Partition SO, Crypto Officer, Limited 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 PED interaction 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 Limited Crypto Officer and Crypto User PED secrets upon first login, and subsequent logins require the challenge secret only. The PED key 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.
Auto-activation
Auto-activation allows PED key credentials to remain cached even in the event of a reboot or a brief power outage (up to 2 hours).
Tamper events and activation/auto-activation
When a tamper event occurs, or if an uncleared tamper event is detected on reboot, the cached PED key data is zeroized, and activation/auto-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 Limited 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 an 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 LCO or CU roles on the partition. You must set a PED 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 Limited Crypto Officer or 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 or Limited Crypto Officer 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 option, 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 PED key, 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 PED secret is cached when they log in for the first time. The CO or CU can store the black or gray PED key in a safe place. The cached PED 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 Partition Role Credential.
NOTE The PED screen prompts for a Black PED Key for any of "User", "Crypto Officer", "Limited Crypo Officer", "Crypto User". The PED is not aware that the key you present has a black or a gray sticker on it. The colored stickers are visual identifiers for your convenience in keeping track of your PED Keys. You differentiate by how you label, and how you use, a given physical key that the PED sees as "black" (once it has been imprinted with a secret).
Enabling Auto-activation
Auto-activation allows PED key credentials to be cached even in the event of a reboot or a brief power outage (up to 2 hours). Clients can re-connect and continue using the application partition without needing to re-authenticate using a PED key.
The Partition SO can enable auto-activation on a partition by setting partition policy 23: Allow auto-activation.
Prerequisites
>Partition policy 22: Allow activation must be enabled on the partition (see Enabling Activation on a Partition).
To enable auto-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 23.
lunacm:> partition changepolicy -policy 23 -value 1
Auto-activation takes effect for each affected role (CO and/or CU) the next time the role is authenticated.
3.[Optional] For optimal reliability, the Luna Network HSM admin or operator can set the appliance to reboot automatically if it fails to complete a normal shutdown. Log in to LunaSH to change this setting.
lunash:> sysconf appliance rebootonpanic enable
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 (with auto-activation disabled). This deletes the cached PED 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
4.If partition policy 22 is disabled, auto-activation is also disabled (even though partition policy 23: Allow auto-activation is set to 1). When partition policy 22 is enabled again, auto-activation resumes. To turn off auto-activation, you must disable partition policy 23.
lunacm:> partition changepolicy -policy 23 -value 0
