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.
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
Some destructiveness settings can be customized using a partition policy template to initialize the partition. Refer to Editing a Partition Policy Template for details. All destructiveness information on this page reflects the default settings for each policy.
Use lunacm:> partition showpolicies -verbose to check whether the policy you want to enable/disable is destructive.
Policy descriptions and settings
|
# |
Partition Capability | Partition Policy |
|---|---|---|
|
0 |
Always 1. This capability allows private keys to be cloned to another Luna HSM partition (required for backup. See also Cloning vs Key Management. |
Destructive OFF-to-ON >1: The partition is capable of cloning private keys to and from a Luna Network HSM version 6.x. Public keys and objects can always be cloned. >0: Private keys can never be cloned to another application partition. |
|
2 |
Always 1. This capability allows wrapped private keys to be imported to the partition. |
Not destructive >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 Always 0. SIM has been deprecated on Luna Cloud HSM. |
Allow private key masking Always 0. |
|
4 |
Always 1. This capability allows secret keys to be cloned to another Luna HSM partition (required for backup). See also Cloning vs Key Management. |
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 |
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 |
Always 1. This capability allows wrapped secret keys to be imported to the partition. |
Not destructive >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 Always 0. SIM has been deprecated on Luna Cloud HSM. |
Allow secret key masking Always 0. |
|
9 |
Enable DigestKey Always 1. Enable the C_DigestKey function to hash a symmetric key and return the hash to the calling application. The hashing is a subset of steps performed in many HASH/HMAC-based KDFs. The HSM firmware checks the policy every time LUNA_DIGEST_KEY is called, and returns LUNA_RET_OPERATION_RESTRICTED if the policy is off. Only FIPS-compliant hashes are allowed, so the state of the policy does not affect overall FIPS compliance. NOTE DigestKey can allow replication of Key Derive Functions externally, permitting some keys to be derived outside the HSM. Requires Luna HSM Firmware 7.8.0 or newer. |
Destructive OFF-to-ON >1 : Key Derive Functions can be performed using DigestKey >0 (default): Key Derive Functions cannot use DigestKey. |
|
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 |
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 Cloud HSM only. It determines whether failed login attempts using a challenge secret count towards a partition lockout. This capability/policy is not applicable to Luna Cloud HSM. |
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. |
|
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. |
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 Not destructive >1 (default): Keys with attribute CKA_LOCAL=0 can be used for signing and their trust history is not assured. >0: Only keys with attribute CKA_LOCAL=1 can be used to sign data on the partition. |
|
18 |
Enable raw RSA operations Always 1. This capability enables the RSA mechanism CKM_RSA_X_509 on the partition, which allows 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. |
Max failed user logins allowed Not destructive 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 partition in the event of a power outage or other such deactivation. |
Allow high availability recovery This policy is not applicable to Luna Cloud HSM. |
|
22 |
Enable activation |
This policy is not applicable to Luna Cloud HSM. |
|
23 |
Enable auto-activation |
This policy is not applicable to Luna Cloud HSM. |
|
25 |
Minimum PIN length >Luna HSM Firmware 7.7.2 and newer: Always 247 (8 characters). >Luna HSM Firmware 7.7.1 and older: Always 248 (7 characters). The absolute minimum length for a role password/challenge secret. 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. |
Not destructive 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: >Luna HSM Firmware 7.7.2 and newer: 247 (8 characters). >Luna HSM Firmware 7.7.1 and older: 248 (7 characters). |
|
26 |
Maximum PIN length Always 255. The absolute maximum length for a role password/challenge secret is 255 characters. |
Not destructive 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, deleted, generated, derived, modified on the partition. See also Cloning vs Key Management. |
Allow Key Management Functions Destructive OFF-to-ON >1 (default): The Crypto Officer can manage (create/delete, etc.) 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 |
Always 1. Private keys can be unmasked onto the partition. |
Not destructive >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 unmasking of a secret key onto the partition. |
Not destructive >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 |
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: >CKM_AES_CBC_PAD >CKM_AES_CBC_PAD_IPSEC >CKM_AES_KWP >CKM_ARIA_CBC_PAD >CKM_ARIA_L_CBC_PAD >CKM_CAST3_CBC_PAD >CKM_CAST5_CBC_PAD >CKM_DES_CBC_PAD >CKM_DES3_CBC_PAD >CKM_DES3_CBC_PAD_IPSEC >CKM_RC2_CBC_PAD >CKM_RC5_CBC_PAD >CKM_SEED_CBC_PAD |
Allow CBC-PAD (un)wrap keys of any size Not destructive >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. |
Destructive ON-to-OFF This policy is not applicable to Luna Cloud HSM. |
|
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. |
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 Auto-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
Cloning vs Key Management
TIP Security Note -Cloning policies (0 and 4) permit or deny the ability to securely copy keys and objects into and out of a partition.
The Key Management Functions policy (28) controls the ability to create, delete, generate, derive, or modify cryptographic objects in the current partition.
These controls are independent of each other. With Key Management functions denied, you can still clone objects in and out of partitions where Cloning policy is allowed. Thus HA (high availability) operation can clone keys into a partition that disallows Key Management functions (creation, deletion, etc.). Cloning a key or object into a partition is not considered creation - the key or object already existed within the security / cloning domain that encompasses the partition.
Ultimately the security administrators define where keys can exist by controlling distribution of the security / cloning domain, and by defining policies around those keys.
Additionally, key owners can choose to make their keys non-modifiable and non-extractable, if those options are indicated by your use-case.
