User's Guide: Group Cryptographic Policy

1.0 Introduction

This article describes the Fortanix-Data-Security-Manager (DSM) Cryptographic Policy feature. It contains the information related to Fortanix DSM group-level cryptographic policies.

The Fortanix DSM supports cryptographic policies that can be set on accounts or groups to restrict what kind of keys can be created and the permitted operations. The policies are specified at the account or group-level.

2.0 Fortanix DSM Cryptographic Policy Structure

The Fortanix DSM Cryptographic policy defines how cryptographic keys are managed. It allows administrators to control key types, sizes, and operations to maintain security.

2.1 Allowed Keys

By default, all types of keys are selected in the policy, including AES, DES, DES3, RSA, EC, Tokenization, HMAC, SECRET, CERTIFICATE, OPAQUE, LMS, ML-KEM, ML-DSA, XMSS, BIP32, EC-KCDSA, KCDSA, SEED, ARIA, and BLS.

2.2 Key Sizes

The following key sizes are allowed for each key type:

• AES: 128, 192, or 256 bits

• DES3: 168 bits or 112 bits (for 2-key triple DES)

• HMAC: minimum 112 to 8192

• RSA: minimum 1024 to 8192 bits

• DSA: 2048 bits (subgroup size: 224, 256 bits) or 3072 bits (subgroup size: 256 bits)

• DES: 56 bits only

• EC: Supported curves include SecP192K1, SecP224K1, SecP256K1, NistP192, NistP224, NistP256, NistP384, NistP521, Gost256A, X25519, Ed25519, and X448.

• Tokenization: 128, 192, or 256 bits.

• ML-KEM: 512, 768, or 1024 bits.

• ML-DSA: 44, 65, or 87 bits.

• EC-KCDSA: Supported curve include SecP192K1, SecP224K1, SecP256K1, NistP192, NistP224, NistP256, NistP384, or NistP521 and hashing algorithm include SHA1, SHA224, SHA256, SHA384, or SHA512.

• KCDSA: Key size: 2048 bits and Subgroup size: 224 or 256 bits.

• SEED: 128 bits.

• ARIA: 128, 192, or 256 bits.

2.3 Key Operations

The following default key operations are allowed for each key type:

• AES/DES3: ENCRYPT, DECRYPT, WRAPKEY, UNWRAPKEY, DERIVEKEY, MACGENERATE, MACVERIFY, APPMANAGEABLE

• DSA: SIGN, VERIFY, APPMANAGEABLE, EXPORT

• RSA: SIGN, VERIFY, ENCRYPT, DECRYPT, WRAPKEY, UNWRAPKEY, APPMANAGEABLE

• EC: SIGN, VERIFY, APPMANAGEABLE, AGREEKEY

• DES: ENCRYPT, DECRYPT, WRAPKEY, UNWRAPKEY, DERIVEKEY, APPMANAGEABLE

• HMAC: DERIVEKEY, MACGENERATE, MACVERIFY, APPMANAGEABLE

• ML-KEM: ENCAPSULATE, DECAPSULATE, EXPORT, APPMANAGEABLE

• ML-DSA: SIGN, VERIFY, APPMANAGEABLE, EXPORT

• EC-KCDSA: SIGN, VERIFY, APPMANAGEABLE, EXPORT

• KCDSA: SIGN, VERIFY, APPMANAGEABLE, EXPORT

• SEED: ENCRYPT, DECRYPT, WRAPKEY, UNWRAPKEY, DERIVEKEY, EXPORT

• ARIA: ENCRYPT, DECRYPT, WRAPKEY, UNWRAPKEY, DERIVEKEY, MACGENERATE, MACVERIFY, APPMANAGEABLE, EXPORT  

• BLS: SIGN, VERIFY, APPMANAGEABLE, EXPORT

• Tokenization: TOKENIZE, DETOKENIZE, APPMANAGEABLE

• LMS: SIGN, VERIFY, APPMANAGEABLE

• XMSS: SIGN, VERIFY, APPMANAGEABLE

When setting a Cryptographic Policy, users can restrict the key operations allowed for a group. By default, all operations are permitted.

3.0 Managing Group-Level Cryptographic Policy

You can create, edit, and delete the Cryptographic policy at the group-level to apply security settings across the entire account.

3.1 Creating a Policy

A group-level Cryptographic policy defines which types of security objects can be added to the group and sets restrictions on key parameters such as size, curve, padding, and permissions.

Perform the following steps to add a group-level Cryptographic policy:

1. Navigate to the Groups menu item in the DSM UI left navigation panel. You can either create a new group or click the existing group from the list.

   

2. In the INFO tab in the group detailed view, click ADD POLICY in the Cryptographic policy section.

   

3. In the Allowed object types for the account section, select the key types that you want to allow for this group.

4. In the Allowed key sizes section, add the required allowed key size(s) for the keys.

5. In the Handling existing non-compliant keys section, select the required radio button to handle the existing non-compliant keys. For more information, refer to Section 4.0: Policy Enforcement.

6. Click RESTRICT KEY OPERATIONS to select the permitted key operations that will be allowed for the keys.

7. In the Audit Log section, enable the toggle button to store the detailed audit logs for all the groups in the account.

8. Click SAVE POLICY to save the policy settings.

   

NOTE

• If a Cryptographic policy was set at the account-level before the group-level, then the account-level Cryptographic policy takes precedence over a group-level Cryptographic policy.

• A Cryptographic policy set at the account-level can be narrowed for each group in the account to further restrict security object parameters.

In this example, some of the key types and key operations are unavailable when creating a Cryptographic policy at the group-level. This is because an account-level Cryptographic policy was applied before the group-level policy.

If a group already contains keys that are not compliant with the Cryptographic policy being added, an error message is displayed in the policy section as seen below.

The groups with a cryptographic policy applied will be indicated by an icon in the group’s table view.

3.2 Editing or Deleting a Policy

Perform the following steps to edit or delete a group-level Cryptographic policy:

1. Navigate to the Groups menu item in the DSM left navigation panel to go to the detailed view of a group.

2. In the INFO tab, under the Cryptographic policy section, click EDIT POLICY.

   

3. On the redirected page, you can make the required updates. Click SAVE POLICY to keep the changes.

4. Click DELETE POLICY to delete the Cryptographic policy.

   

NOTE

If an account-level Cryptographic policy was set, then the account Cryptographic policy rules will still be applicable for the group, even after deleting the group Cryptographic policy.

4.0 Policy Enforcement

• All new keys will be allowed/denied based on the Cryptographic policy rules.

• Any existing keys that are not compliant with the policy will still exist in the group. However, these keys will be marked separately as policy-violating keys. For these keys the following conditions are applicable:

  • Cryptographic Operations that are classified as “protect operations” will not be allowed: For example: Sign, Encrypt, Wrapkey, Derivekey, MacGenerate, AgreeKey.

  • Cryptographic Operations which are classified as “process operations” will still be allowed: For example: Verify, Decrypt, UnwrapKey, MacVerify.

If a group contains keys that are not compliant with the policy being added, an error message is displayed where the key can either be grandfathered, forbidden, or partially grandfathered. When a Cryptographic policy is created at an account or group-level, there are three options provided to handle non-compliant keys. These options are detailed in the section Handling existing non-compliant keys:

1. Forbid to use: Forbid any use of non-compliant objects. If this option is selected, you are forbidden from using the non-compliant keys for any operation.

2. Accept: Accept non-compliant objects even though they violate the current policy. If this option is selected, you may continue to use existing non-compliant keys, but you may not generate or import new non-compliant objects.

3. Limit usage: Restrict non-compliant objects so that they may only be used for “process operations” such as Decrypt, Unwrap, Verify, and MacVerify operations. The “protect operations” such as Encrypt, Wrap, Sign, and Mac are forbidden.