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
NOTE Regarding Capabilities and Policies - as a general rule, when firmware is updated, a given policy retains whatever value it had (default or your setting), before the update. Some firmware versions introduce new capabilities with their accompanying policies. The listed default setting of a policy is the expected setting
•if the Capability and Policy was not in existence,
or
•if the Policy was not changed,
before a firmware update.
Rolling back the HSM firmware or resetting the HSM to factory conditions restores that version's default settings for all policies.
Applying a non-default policy setting should be [re-]done after updating firmware from factory settings.
TIP The Partition Policy Template (PPT) feature is not intended as a way to reconfigure application partitions that are already initialized.
It is for the consistent, orderly setup of a new partition or partitions, or of a previously existing partition that has been zeroized.
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 7 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 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 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 Destructive OFF-to-ON >1 (default): All keys can be wrapped or unwrapped using CBC_PAD mechanisms. >0: Only keys that are a multiple of 64 bits (8 bytes) can 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 public, private, and secret partition objects for encrypt, sign, and wrap operations. |
Allow Start/End Date Attributes Destructive ON-to-OFF >1: CKA_START_DATE and CKA_END_DATE attributes are enforced for all public, private, and secret partition objects for encrypt, sign, and wrap operation. >0 (default): These attributes can be set, but their values are ignored. |
| 44 |
Enable Extended Domain Management This capability is visible for any partition at Luna HSM Firmware 7.8.0 or newer, and allows multifactor quorum-authenticated HSMs to inter-operate with password-authenticated HSMs -- which also allows multifactor quorum-authenticated HSMs to inter-operate with Luna Cloud HSM services. |
Allow Extended Domain Management Not destructive >1 : Partition cloning/security domains, in addition to the original, can be specified and accessed by the partition. >0 (default): For newly created partitions, the policy is off, and only the primary/native domain is available. For partitions that existed prior to upgrading to Luna HSM Firmware 7.8.0 or newer, the policy is off. This ensures that continuity of existing applications and processes requires no change due to firmware update. Changes come into play only when you set this policy to ON. When enabled, this policy provides the ability to specify the source of a partition's domain and the ability to have more than one domain on a partition. See the lunacm commands partition domainlist, partition domainadd, partition domaindelete, and partition domainchangelabel. When the policy is turned OFF, all domains except the primary domain are deleted, which also happens if you roll back to a firmware version that doesn't support multiple domains. This policy is non-destructive of partition contents when switched from OFF-to-ON or from ON-to-OFF, with that one exception of the non-primary domains. The destructiveness for either transition can be adjusted by the use of Partition Policy Template (PPT) at partition initialization time, but going from ON to OFF still loses any non-primary domains, while other aspects/contents of a partition can remain intact. |
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.
