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.
>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. |
Allow private key cloning (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. |
Allow private key wrapping (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
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. |
Allow private key unwrapping >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. |
Allow private key masking >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. |
Allow secret key cloning (destructive OFF-to-ON) >1 (default): Secret keys on the partition can be cloned to another partition. This is required for partition backup >0: Secret keys cannot be backed up |
5 |
Enable secret key wrapping Always 1. This capability allows secret keys to be encrypted (wrapped) and exported off the partition. |
Allow secret key wrapping (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. |
Allow secret key unwrapping >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. |
Allow secret key masking >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 fro multiple types of operation: •Encrypt/Decrypt •Sign/Verify •Wrap/Unwrap •Derive |
Allow multipurpose keys (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 |
Allow changing key attributes (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 PED-authenticated Luna Network HSM 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 PED key authentication attempts increment the counter. >0: Failed login attempts using either a PED key or a challenge secret will count towards a partition lockout. See Activation and Auto-activation on Multi-factor- (PED-) Authenticated Partitions and Logging In to the Application Partition for more information. |
16 |
Enable operation without RSA blinding Always 1. RSA blinding is a technique that introduces random elements into the signature process to prevent timing attacks on the RSA private key. Some security policies may require this technique, but it does affect performance. |
Operate without RSA blinding (destructive OFF-to-ON) >1 (default): The partition does not use RSA blinding. >0: The partition uses RSA blinding. Performance will be affected. |
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 |
Allow raw RSA operations (destructive OFF-to-ON) >1 (default): The partition allows operations using the RSA mechanism >0: Operations using |
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 and Auto-activation on Multi-factor- (PED-) Authenticated Partitions. >1: Always enabled on PED-authenticated HSMs. >0: Always disabled on password-authenticated HSMs. |
Allow activation >1: The black and/or gray PED key secrets can be encrypted and cached, so that only a keyboard-entered challenge secret is required to log in. >0 (default): PED keys 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 This capability allows the partition to remain activated for up to two hours if the Luna Network HSM loses power. See Activation and Auto-activation on Multi-factor- (PED-) Authenticated Partitions. >1: Always enabled on PED-authenticated HSMs. >0: Always disabled on password-authenticated HSMs. |
Allow auto-activation >1: Partition activation (see policy 22 above) is maintained after an HSM power loss of up to two hours. >0 (default): The partition is deactivated in the event of a power loss. When power is restored, the black and/or gray PED keys must be presented to re-activate the partition. |
25 |
Minimum PIN length Always 248 (7 characters). The absolute minimum length for a role password/challenge secret is 7 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 7, 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. |
Minimum PIN length 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: 248 (7 characters) |
26 |
Maximum PIN length Always 255. The absolute maximum length for a role password/challenge secret is 255 characters. |
Maximum PIN length 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. |
Allow private key unmasking >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. |
Allow secret key unmasking >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. |
Allow RSA PKCS mechanism (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 Secure Trusted Channel Always 1. This capability allows the partition to use STC for client access. NOTE The HSM SO must first enable STC by turning on HSM policy 39. |
Force Secure Trusted Channel (destructive ON-to-OFF) >1: If this policy is set, STC is used for all client access to this partition. You must first set up and register the STC identities (see Creating an STC Connection). >0 (default): NTLS is used by default for client access to this partition , but STC can be used if desired. |
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 newly created or upgraded firmware 7.7.0 (or newer) 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 (default 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 is visible for any partition at firmware version 7.7.0 or newer, and allows you to switch a partition between version V0 and V1. |
Partition Version (destructive ON-to-OFF) >1 : Version 1 (V1) partition supports all features of firmware 7.7.0 (or newer). •cloning is used/permitted only for SMKs •key objects are transferred using SKS •only HA Login version 2 is supported. >0 (default): Version 0 (V0) supports older API and your pre-existing applications (used with f/w < 7.7), enhanced by fixes and security updates of firmware 7.7.0 (or newer), but Per Key Authorization, SKS, and other V1-dependent features are not available. Pre-7.7.0 version of HA Login can be used (full use of v1.1 or version 2.0 , while v1.0 HA Login for use as primary only) |
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 and Partition Policy (23) Enable Auto-Activation are 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’.