Partition Capabilities and Policies
An application partition can be configured to provide a range of different functions. The Partition Security Officer can customize this functionality using partition policies. This configuration is governed by the following settings:
>Partition Capabilities are features of partition functionality that are inherited from the parent HSM policies (see HSM Capabilities and Policies). The HSM SO can configure HSM policies to allow or disallow partition capabilities. Some capabilities have corresponding modifiable partition policies.
>Partition Policies are configurable settings that allow the Partition Security Officer to modify the function of their corresponding capabilities.
The table below describes all partition capabilities, their corresponding policies, and the results of changing their settings. This section contains the following procedures:
>Setting Partition Policies Manually
>Setting Partition Policies Using a Template
Destructive Policies
As a security measure, changing some partition policies forces deletion of all cryptographic objects on the partition. These policies are listed as destructive in the table below. Some policy changes are destructive in either direction (OFF-to-ON and ON-to-OFF), while others are destructive only in the direction resulting in lowered partition security.
Use lunacm:> partition showpolicies -verbose to check whether the policy you want to enable/disable is destructive.
|
# |
Partition Capability | Partition Policy |
|---|---|---|
|
0 |
Enable private key cloning Always 1. This capability allows private keys to be cloned to another Luna HSM partition (required for backup. NOTE The HSM SO can disable cloning for all partitions on the HSM by turning off HSM policy 7 (see HSM Capabilities and Policies). In this case, cloning is not possible on the partition, regardless of this capability/policy's setting. |
Destructive OFF-to-ON >1 (default): The partition is capable of cloning private keys to another partition. This policy must be enabled to back up partitions or create HA groups. Public keys and objects can always be cloned, regardless of this policy's setting. >0: Private keys can never be cloned to another application partition. Partition policies 0 and 1 may not be set to 1 (ON) at the same time. NOTE Key attributes can be set modifiable, and a key can then be set with (for example) attribute -extractable (see cmu generatekeypair), but Partition Policies overrule object attributes; Cloning ON and Private Key Wrapping OFF would prevent export despite the attribute settings. |
|
1 |
Enable private key wrapping Always 1. This capability allows private keys to be encrypted (wrapped) and exported off the partition. |
Destructive OFF-to-ON >1: Private keys may be wrapped and saved to an encrypted file off the partition. Public keys and objects can always be wrapped and exported, regardless of this policy's setting. >0 (default): Private keys can never be wrapped and exported off the partition. Partition policies 0 and 1 may not be set to 1 (ON) at the same time. NOTE Key attributes can be set modifiable, and a key can then be set with (for example) attribute -extractable (see cmu generatekeypair), but Partition Policies overrule object attributes; Cloning ON and Private Key Wrapping OFF would prevent export despite the attribute settings. |
|
2 |
Enable private key unwrapping Always 1. This capability allows wrapped private keys to be imported to the partition. |
>1 (default): Private keys can be unwrapped and stored on the partition. >0: Private keys cannot be unwrapped onto the partition. |
|
3 |
Enable private key masking Private keys can be masked off the partition. |
>1 (default for V1 partitions): Private keys can be masked off the partition. >0 (default for V0 partitions): Private keys cannot be masked off the partition. |
|
4 |
Enable secret key cloning Always 1. This capability allows secret keys to be cloned to another Luna HSM partition (required for backup). NOTE The HSM SO can disable cloning for all partitions on the HSM by turning off HSM policy 7 (see HSM Capabilities and Policies). In this case, cloning is not possible on the partition, regardless of this capability/policy's setting. |
Destructive OFF-to-ON >1 (default): Secret keys on the partition can be cloned to another partition. This is required for partition backup and HA groups. >0: Secret keys cannot be backed up, and will not be cloned to other HA group members. |
|
5 |
Enable secret key wrapping Always 1. This capability allows secret keys to be encrypted (wrapped) and exported off the partition. |
Destructive OFF-to-ON >1 (default): Secret keys can be wrapped and saved to an encrypted file off the partition. >0: Secret keys can never be wrapped and exported off the partition. |
|
6 |
Enable secret key unwrapping Always 1. This capability allows wrapped secret keys to be imported to the partition. |
>1 (default): Secret keys can be unwrapped and stored on the partition. >0: Secret keys cannot be unwrapped onto the partition. |
|
7 |
Enable secret key masking Enable masking secret keys off the partition. |
>1 (default for V1 partitions): Secret keys can be masked and stored off the partition. >0 (default for V0 partitions): Secret keys cannot be masked off the partition. |
|
10 |
Enable multipurpose keys Always 1. This capability allows keys that are created or unwrapped on the partition to have more than one of the following attributes enabled (set to 1), and can therefore be used for multiple types of operation: •Encrypt/Decrypt •Sign/Verify •Wrap/Unwrap •Derive |
Destructive OFF-to-ON >1 (default): Keys that are created or unwrapped on the partition may be used for multiple operations. >0: Keys that are created or unwrapped on the partition may have only one of the affected attributes enabled. Thales recommends that you create keys with only the attributes required for their intended purpose. Disabling this policy enforces this rule on the partition. NOTE This policy does not affect Diffie-Hellman keys, which are always created with only Derive set to 1. |
|
11 |
Enable changing key attributes Always 1. This capability allows the Crypto Officer to modify the following non-sensitive attributes of keys on the partition, changing key functions: >CKA_ENCRYPT >CKA_DECRYPT >CKA_WRAP >CKA_UNWRAP >CKA_SIGN >CKA_SIGN_RECOVER >CKA_VERIFY >CKA_VERIFY_RECOVER >CKA_DERIVE >CKA_EXTRACTABLE |
Destructive OFF-to-ON >1 (default): The Crypto Officer can modify the non-sensitive attributes of keys on the partition. >0: Keys created on the partition cannot be modified. |
|
15 |
Allow failed challenge responses Always 1. This capability/policy applies to multifactor quorum-authenticated Luna USB HSM 7 only. It determines whether failed login attempts using a challenge secret count towards a partition lockout. |
Ignore failed challenge responses Destructive OFF-to-ON >1 (default): Failed challenge secret login attempts are not counted towards a partition lockout. Only failed iKey authentication attempts increment the counter. >0: Failed login attempts using either an iKey or a challenge secret will count towards a partition lockout. See Activation on Multifactor Quorum-Authenticated Partitions and Logging In to the Application Partition for more information. |
|
16 |
Enable operation without RSA blinding Always 1. This is always disabled on Luna USB HSM 7. |
>Always 1: The partition does not use RSA blinding. This policy cannot be changed. |
|
17 |
Enable signing with non-local keys Always 1. Keys generated on the HSM have the attribute CKA_LOCAL=1. Keys that are imported (unwrapped) to the HSM have CKA_LOCAL=0. These attributes are maintained if keys are backed up or cloned to another HSM partition. |
Allow signing with non-local keys >1 (default): Only keys with attribute CKA_LOCAL=1 can be used to sign data on the partition. >0: Keys with attribute CKA_LOCAL=0 can be used for signing, and their trust history is not assured. |
|
18 |
Enable raw RSA operations Always 1. This capability enables the RSA mechanism CKM_RSA_X_509 on the partition, which allows weak signatures and weak encryption. |
Destructive OFF-to-ON >1 (default): The partition allows operations using the RSA mechanism CKM_RSA_X_509. >0: Operations using CKM_RSA_X_509 are blocked on the partition. |
|
20 |
Max failed user logins allowed Displays the maximum number of failed partition login attempts (10) before the partition is locked out (see Logging In to the Application Partition). |
Max failed user logins allowed The Partition SO can lower the effective number of failed logins below the maximum if desired. Default: 10 |
|
21 |
Enable high availability recovery Always 1. This capability enables the RecoveryLogin feature on the partition. This feature allows other HA group members to restore the login state of the partiton in the event of a power outage or other such deactivation. |
Allow high availability recovery >1 (default): RecoveryLogin is enabled on the partition. This feature must be configured in advance (see role recoveryinit and role recoverylogin). >0: RecoveryLogin is disabled on the partition. |
|
22 |
Enable activation This capability allows the partition to be activated. See Activation on Multifactor Quorum-Authenticated Partitions. >1: Always enabled on multifactor quorum-authenticated HSMs. >0: Always disabled on password-authenticated HSMs. |
>1: The black and/or gray iKey secrets can be encrypted and cached, so that only a keyboard-entered challenge secret is required to log in. >0 (default): iKeys must be presented at each login, whether via LunaCM or a client application. This policy is overridden and activation is disabled if a tamper event occurs, or if an uncleared tamper event is detected on reboot. See Tamper Events for more information. |
|
23 |
Enable auto-activation Always 0. Not supported on Luna USB HSM 7. |
N/A |
|
25 |
Minimum PIN length Always 247 (8 characters). The absolute minimum length for a role password/challenge secret is 8 characters. This is displayed as a value subtracted from 255. The reason for this inversion is that a policy can only be set to a value equal to or lower than the value set by its capability. If the absolute minimum length was set to 8, the Partition SO would be able to set the preferred minimum to 2, a less-secure policy. The Partition SO may only change the minimum length to increase security by forcing stronger passwords. |
The Partition SO can choose to increase the effective minimum length of a role password/challenge secret by setting this policy. The policy value is determined as follows: Subtract the desired minimum length from 255 (the absolute maximum length), and set policy 25 to that value. 255 - (desired length) = (policy value) For example, to set the minimum length to 10 characters, set the value of this policy to 245: 255 - 10 = 245 Default: 247 (8 characters) |
|
26 |
Maximum PIN length Always 255. The absolute maximum length for a role password/challenge secret is 255 characters. |
The effective maximum role password/challenge secret length may be changed by the Partition SO. It must always be greater than or equal to the effective minimum length, determined by the formula described in policy 25 (above). Default: 255 |
|
28 |
Enable Key Management Functions Always 1. This capability allows cryptographic objects to be created or deleted on the partition. |
Allow Key Management Functions Destructive OFF-to-ON >1 (default): The Crypto Officer can manage (create/delete) objects on the partition. The Crypto User is restricted to read-only operations. >0: Partition objects are read-only for both the CO and CU roles. |
|
29 |
Enable RSA signing without confirmation Always 1. This capability governs the HSM's internal signing verification. |
Perform RSA signing without confirmation Destructive OFF-to-ON >1 (default): No internal signing verification is performed. >0: The HSM performs an internal verification of signing operations to validate the signature. This has a performance impact on signature operations. |
|
31 |
Enable private key unmasking Always 1. Private keys can be unmasked onto the partition. |
>1 (default for V1 partitions): Private keys can be unmasked onto the partition (meaning they also can be migrated from legacy Luna HSMs that used SIM). >0 (default for V0 partitions): Private keys cannot be unmasked onto the partition (meaning that migration of private keys from legacy HSMs using SIM is also not possible). |
|
32 |
Enable secret key unmasking Enable unmasking of a secret key onto the partition. |
>1 (default for V1 partitions): Secret keys can be masked and stored onto the partition. >0 (default for V0 partitions): Secret keys cannot be masked onto the partition. |
|
33 |
Enable RSA PKCS mechanism Always 1. The mechanism CKM_RSA_PKCS has known weaknesses, which you can address in your applications. If you are not prepared to address these issues, you can choose to disable the mechanism entirely. |
Destructive OFF-to-ON >1 (default): CKM_RSA_PKCS is enabled on the partition. >0: CKM_RSA_PKCS is disabled on the partition. |
|
34 |
Enable CBC-PAD (un)wrap keys of any size Always 1. There are known vulnerabilities using small keys wrapped/unwrapped with CBC_PAD mechanisms (and with small keys in general). You can choose to enforce a size restriction so that small weak keys cannot be unwrapped onto the partition. The following mechanisms are affected: |
Allow CBC-PAD (un)wrap keys of any size >1 (default): All keys can be wrapped or unwrapped using CBC_PAD mechanisms. >0: Small keys cannot be wrapped or unwrapped using CBC_PAD mechanisms. |
|
37 |
Enable enforcing Secure Trusted Channel Always 0. Not applicable to Luna USB HSM 7. |
N/A |
|
39 |
Enable Start/End Date Attributes Always 1. This capability allows you to enforce the CKA_START_DATE and CKA_END_DATE attributes of partition objects. |
Allow Start/End Date Attributes Destructive ON-to-OFF >1: CKA_START_DATE and CKA_END_DATE attributes are enforced for all partition objects. >0 (default): These attributes can be set for partition objects, but their values are ignored. |
| 40 |
Enable Per-Key Authorization Data Both assigned and unassigned secret keys (symmetric or private) are given per-key authorization attributes in the form of CKA_AUTH_DATA, in any partition. For V0 partitions, PKA is ignored and applications can use the pre-existing APIs as before. For V1 partitions it is actively used, for eIDAS compliance with newer API. |
Require Per-Key Authorization Data >1 (default for V1 partitions): Per-Key Authorization is on by default, but can be turned off for performance. >0 (only setting for V0 partitions): Per-Key Authorization is off by default, and cannot be turned on - V0 partitions do not allow policy changes that would require new clients. |
| 41 |
Enable Partition Version Always 1. This capability allows you to switch a partition between version V0 and V1. |
Destructive ON-to-OFF >1 : Version 1 (V1) partition supports all features of Luna HSM Firmware 7.7.0 (or newer). •cloning is used/permitted only for SMKs •key objects are transferred using SKS >0 (default): Version 0 (V0) supports older API and your pre-existing applications, enhanced by fixes and security updates, but Per-Key Authorization, SKS, and other V1-dependent features are not available. |
| 42 |
Enable CPv1 This capability allows the partition to use the cloning protocol required for cloning/HA with Luna partitions with firmware older than 7.7.2, or Luna Cloud HSM services. |
Destructive OFF-to-ON >1 (default for V0 partitions created when the HSM is in non-FIPS mode): Cryptographic objects on the partition can be cloned to Luna partitions with firmware older than 7.7.2, or to Luna Cloud HSM services. >0: (only setting for V1 partitions or V0 partitions in FIPS mode): Cryptographic objects on the partition can be cloned only to other partitions with firmware 7.7.2 or newer, with the same FIPS settings. Luna Backup HSM 7 Firmware 7.7.1 cannot restore keys to a partition with CPv1 enabled if they were backed up from a partition with CPv1 disabled. This limitation is restricted to the backup HSM -- you can still use direct slot-to-slot cloning (see Cloning Objects to Another Application Partition). |
| 43 |
Enable Non-FIPS Algorithms This capability allows the use of algorithms that are not compliant with FIPS, within the current partition. Requires that HSM policy 12 be set to ON (the HSM is in non-FIPS mode). |
Destructive OFF-to-ON >1: (default for new partitions where HSM policy 12 is set to 1): Non-FIPS-compliant algorithms can be used by the partition. >0: (only setting for partitions where HSM policy 12 is set to 0): Non-FIPS-compliant algorithms cannot be used by the partition. |
A number of partition capabilities are linked to the corresponding HSM capabilities and policies including:
> Partition Policy (0) Enable private key cloning is dependent on HSM Policy (7) Allow cloning;
>Partition Policy (3) Enable private key masking is dependent on HSM Policy (6) Allow Masking;
>Partition Policy (4) Enable secret key cloning is dependent on HSM Policy (7) Allow cloning;
>Partition Policy (7) Enable secret key masking is dependent on HSM Policy (6) Allow Masking;
>Partition Policy (22) Enable Activation is dependent on HSM Policy (1) Allow PED-based authentication;
>Partition Policy (31) Enable private key unmasking is dependent on HSM Policy (6) Allow Masking; and
>Partition Policy (32) Enable secret key unmasking is dependent on HSM Policy (6) Allow Masking.
In addition – the following dependencies within the partition level policies are observed:
>Partition Policy (7) Allow cloning cannot be enabled at the same time as Partition Policy (1) Allow private key wrapping;
>Partition Policy (1) Allow private key wrapping cannot be enabled at the same time as either one of the policies, Partition Policy (0) Enable private key cloning, Partition Policy (3) Allow private key masking, Partition Policy (31) Enable private key unmasking;
>Partition Policy (23) Allow Activation is dependent on Partition Policy (22) Allow Activation being enabled;
>Partition Policies related to ‘Masking’ (3, 7, 31 and 32) can only be enabled when Partition Policy (41) Partition Version is ‘0’; and
>Partition Policy (41) Partition Version cannot be set to ‘1’ at the same time as either Partition Policy (40) Enable Per-Key Authorisation Data or any of the Partition Policies covering key masking (3, 7, 31 and 32).
>Partition Policy (40) Enable Per-Key Authorisation Data is enabled by default but is disabled if Partition Policy (41) Partition Version is set to ‘0’.
