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.
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 NOTE The HSM SO can disable cloning for all partitions on the HSM by turning off HSM policy 7: Allow cloning. In this case, cloning is not possible on the partition, regardless of this capability/policy's setting. See also Cloning vs Key Management. |
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 Enabling or disabling this policy requires Luna HSM Firmware 7.1.0 or newer. 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 |
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. This applies to V0 partitions only; V1 partitions cannot enable this policy. >0
Partition policies 0 and 1 may not be set to 1 (ON) at the same time. NOTE Enabling or disabling this policy requires Luna HSM Firmware 7.1.0 or newer. 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 |
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 |
Private keys can be masked off the partition. |
Not destructive >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 |
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: Allow cloning. In this case, cloning is not possible on the partition, regardless of this capability/policy's setting. 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 masking secret keys off the partition. |
Not destructive >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. |
|
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 Network 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 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 on Multifactor Quorum-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. |
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 |
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 |
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 Not destructive >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 PED-authenticated HSMs. >0: Always disabled on password-authenticated HSMs. |
Not destructive >1: The black and/or gray PED keysecrets 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 7 loses power. See Activation on Multifactor Quorum-Authenticated Partitions. >1: Always enabled on multifactor quorum-authenticated HSMs. >0: Always disabled on password-authenticated HSMs. |
Not destructive >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 >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: |
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. NOTE If you are using Luna HSM Firmware 7.4.2 or older, the HSM SO must first enable STC by turning on HSM policy 39: Allow Secure Trusted Channel. This is not required using Luna HSM Firmware 7.7.0 or newer; STC is always enabled. |
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 Luna HSM 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 Not destructive >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 Luna HSM Firmware 7.7.0 or newer, and 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 •only HA Login version 2 is supported. >0 (default): Version 0 (V0) supports older API and your pre-existing applications (used with Luna HSM Firmware 7.7.0), enhanced by fixes and security updates of Luna HSM 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) |
| 42 |
Enable CPv1 This capability is visible for any partition at Luna HSM Firmware 7.7.1 or newer, and allows the partition to use the cloning protocol needed for HA with older partitions. |
Destructive OFF-to-ON For V0 partitions created while the HSM is at Luna HSM Firmware 7.7.1 or newer. This policy was added in order to reintroduce CPv1 ability for cloning keys from Luna on-premises HSM to Luna Cloud HSM, or to other on-premises HSMs with lower firmware versions. When the HSM is in non-FIPS mode (where HSM policy 12 is set to ON) >1: Cloning (CPv1) can be used by the partition for key objects. >0 (default): Cloning (CPv1) is not allowed by the partition for key objects. When the HSM is in FIPS mode (where HSM policy 12 is set to OFF), this policy setting cannot be changed. Cloning (CPv1) is not allowed, by the partition, for key objects. Therefore, cloning can use only CPv3 if it is available on both source and target. For Luna HSM Firmware 7.7.0 V0 partitions, "Allow CPv1" is OFF after firmware update from version 7.7.0 to Luna HSM Firmware 7.7.1 or newer. For pre-7.7.0 firmware partitions, CPv1 is turned ON after update (to firmware version 7.7.1 or newer), if the HSM is not in FIPS mode, OFF if the HSM is in FIPS mode. To back up objects from a partition with firmware older than Luna HSM Firmware 7.7.0 and restore them to a V0 partition with CPv1 allowed, you require Luna Backup HSM 7 Firmware 7.7.2 or newer. Enabling CPv1 disables CPv3 and CPv4. |
| 43 |
This capability is visible for any partition at Luna HSM Firmware 7.7.1 or newer, and allows the use of algorithms that are FIPS non-compliant, within the current partition. Requires that HSM policy 12 be set to ON (that is, with policy 12 ON for the HSM, the overall HSM allows non-FIPS algorithms, so you can then choose to allow or disallow non-FIPS mode per individual partition on that HSM by using this partition policy 43). |
Destructive OFF-to-ON For V0 partitions created while the HSM is at Luna HSM Firmware 7.7.1 or newer When the HSM is in non-FIPS mode (where HSM policy 12 is set to ON) >1 (default): Non-FIPS-compliant algorithms can be used by the partition. >0: Non-FIPS-compliant algorithms are not permitted. When the HSM is in FIPS mode (where HSM policy 12 is set to OFF), this policy setting cannot be changed; non-FIPS-compliant algorithms are not permitted on any partition on the HSM. For Luna HSM Firmware 7.7.0 V0 partitions, "Allow non-FIPS" is OFF after firmware update from version 7.7.0 to Luna HSM Firmware 7.7.1 or newer. |
| 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. This capability is ON by default, so that the associated policy can always be modified. |
Allow Extended Domain Management Not destructive This policy controls the ability of a partition to support more than one cloning/security domain, which further allows multifactor quorum-authenticated and password-authenticated partitions to interoperate. >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. This policy is non-destructive of partition contents when switched from OFF-to-ON or from ON-to-OFF. The destructiveness for either transition can be adjusted by the use of Partition Policy Template at partition initialization time. 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. 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. |
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
>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’.
>Partition Policy (42) Allow CPv1 requires that HSM Policy (12) Allow non-FIPS algorithms is ON, and Partition Policy (43) Allow non-FIPS algorithms is on, setting the partition to FIPS non-approved mode.
NOTE With the HSM in FIPS mode then, at partition level:
>cloning (CPV1) is not allowed, and
>FIPS mode cannot be turned off per partition.
This is to prevent keys/objects in a more secure container from being transferred to a less-secure container.
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.
