Keys

Keys are similar to SafeNet KeySecure Classic keys, with a few differences. Keys can be created, modified, imported, exported, and deleted. Keys can be symmetric or asymmetric, variable sizes, and can be constrained to particular usages.

Supported Elliptic curve (ec) curves (size is defined by the curve): brainpoolP224r1, brainpoolP224t1, brainpoolP256r1, brainpoolP256t1, brainpoolP384r1, brainpoolP384t1, brainpoolP512r1, brainpoolP512t1, prime256v1, secp224k1, secp224r1, secp256k1, secp384r1, secp521r1

Some of these curves have multiple names chosen by different standards organizations, as described in RFC 4492, although CipherTrust Manager only supports the names listed above.

To create a key

Key can be created using the GUI, KSCTL, or API.

To create a key using KSCTL, execute the command:

$ ksctl keys create –alg AES --name “testAESkey”

The response looks like:

{
  "id": "f0c2b40017dca0cdbbda90e2d224d0dcb4488ec412e156a594af3bc11a879b1a",
  "uri": "kylo:kylo:vault:keys:testaeskey-v0",
  "account": "kylo:kylo:admin:accounts:kylo",
  "application": "ncryptify:gemalto:admin:apps:kylo",
  "devAccount": "ncryptify:gemalto:admin:accounts:gemalto",
  "createdAt": "2018-04-23T17:57:15.899060389Z",
  "name": "testAESkey",
  "updatedAt": "2018-04-23T17:57:15.899060389Z",
  "usage": "blob",
  "usageMask": 12,
  "meta": {
    "ownerId": "local|ee328ec6-f37b-4e9c-85be-8867120b6b79"
  },
  "algorithm": "AES",
  "size": 256,
  "format": "raw",
  "unexportable": false,
  "undeletable": false,
  "defaultIV": "3ddc71eea888f8ec554b63759f371af9",
  "objectType": "Symmetric Key",
  "activationDate": "2018-04-23T17:57:15.886182496Z",
  "state": "Active"
}

Setting Key Permissions

Keys can be granted permissions to perform operations such as read, encrypt, and decrypt data. You can set key permissons on the RAW tab of the Key Metadata section. This can be done when creating new keys or when modifying existing keys.

Key permissions can be set using the GUI, KSCTL, or API.

To set key permissions using the GUI

When creating a key

To set key permissions when creating a key:

1. Log on to the CipherTrust Manager console as administrator.

2. Open the Keys & Access Management application.

3. Click Create a New Key.

4. Specify required details.

5. Under the Key Metadata section, click the Raw tab.

6. In the Key Metadata text box, specify key permissions in the"permissions": {} parameter. Sample settings are given below:

   "ownerId": "local|81f34b79-e3c4-4391-a4c9-4bdd85b13f98",
       "permissions": {
         "UseKey": [
           "stars"
         ],
         "ReadKey": [
           "stars"
         ],
         "DecryptWithKey": [
           "stars"
         ],
         "EncryptWithKey": [
           "stars"
         ],
       "customAttributes": [
             {
               "name": "color",
               "value": "blue"
             }
           ],
       }
   

Refer to the "Keys" section in the API playground for details on permissions.

1. Click Create.

When modifying a key

To set key permissions when modifying a key:

1. Log on to the CipherTrust Manager console as administrator.

2. Open the Keys & Access Management application.

3. Under Key name and aliases, click the key name link. The key details are displayed.

4. Click the action button. A shortcut menu appears.

5. Click Edit. The Edit <Key Name> page is displayed.

6. Under the Key Metadata section, click the Raw tab.

7. In the Key Metadata text box, specify key permissons in the "permissions": {} parameter. Sample settings are given below:

   "ownerId": "local|81f34b79-e3c4-4391-a4c9-4bdd85b13f98",
       "permissions": {
         "UseKey": [
           "stars"
         ],
         "ReadKey": [
           "stars"
         ],
         "DecryptWithKey": [
           "stars"
         ],
         "EncryptWithKey": [
           "stars"
         ],
       "customAttributes": [
             {
               "name": "color",
               "value": "blue"
             }
           ],
       }
   

   Refer to the "Keys" section in the API playground for details on permissions.

8. Click Update.

Versioned Keys

KeySecure Classic

A KeySecure Classic versioned key is a key that maintains a single set of key metadata but contains multiple sets of key data. Each set of key data belongs to a unique version of the key.

A KeySecure Classic crypto operation using a versioned key prepends a header containing key version information to the resulting ciphertext. A crypto operation using an unversioned key does not prepend the ciphertext with this header.

CipherTrust Manager

The CipherTrust Manager handling of versioned keys depends on the interface used and the setting of key flag (versionedKey). For backward compatibility with KeySecure Classic, when the NAE-XLM interface is used and if the key flag (versionedKey = true), the key is handled as a versioned key and the crypto operation prepends a header to the resulting ciphertext. When the REST interface is used, crypto operations always produce the kind of ciphertext that KeySecure Classic produces when using unversioned keys, that is, produce unadorned ciphertext with no header.

Similarly, if you perform the inverse crypto operations on the ciphertext encrypted using a versioned key (e.g. decrypt, verify...), the operation must be done via the NAE-XML interface, since the REST interface does not handle these header bytes.

To maintain backward compatibility with KeySecure Classic, when you create a key through the NAE-XML interface with the <Versioned/> element present, CipherTrust Manager server adds a flag to the key (versionedKey = true), indicating that when the key is used via the NAE-XML interface, the key should behave like a legacy NAE-XML versioned key (i.e. the produced ciphertext results that contain the legacy header bytes). This internal flag is only honored when the key is used via the NAE-XML interface; the flag has no effect on REST interface interactions.

Key States (KMIP and REST)

A key can be in any of the following states at any given time:

• Pre-Active: The key exists, but should not be used for any cryptographic purpose.

• Active: The key can be used for any cryptographic purpose.

• Deactivated: The key should not be used for cryptographic operations such as encryption, signing, wrapping, MACing, and deriving. The key should only be used for decryption, signature verification, unwrapping, and MAC verification.

• Compromised: The key should not be used for cryptographic operations such as encryption, signing, wrapping, MACing, and deriving. The key should only be used for decryption, signature verification, unwrapping, and MAC verification.

• Destroyed: The key should not be used for any cryptographic purpose.

• Destroyed Compromised: The key should not be used for any cryptographic purpose. Its compromised status should be retained for audit or security purposes.

Effects of Negative Actions on Keys

When you delete, destroy, revoke, or archive a key, the following happens:

• Delete: The key is deleted from the database altogether, including the key metadata and key material.

  Note

  • Only CTE Administrators (users of the CTE Admins group) can delete the CTE keys.
  • An in-use CTE key cannot be deleted. Before you delete a CTE key, make sure that no key rule is using the key.

• Destroy: The key material is deleted from the database, while the key metadata is kept.

• Revoke: The key state is set to "Revoked". The key material is available on the server, which:

  • Can be used only for decryption, signature verification, unwrapping, and MAC verification.

  • Cannot be used for encryption, signing, wrapping, MACing, and deriving etc.

• Archive: The key state is set to "Archived". The key cannot be used for any cryptographic operations. Later the key can be recovered and used or modified, as required.

Key States (NAE)

The NAE Interface supports the following Key States.

Pre-operational (Pre-active)

In this state the key is created but has not yet been used for any crypto operation.

Operational (Active)

In this state the key can be used for both protection and process, i.e. Encrypt and Decrypt, sign and signV.

Post-operational (Restricted/Retired)

In this state the key can be used for process only and not for protection, for example:

• When in Restricted state,

  • the key can be used to decrypt but not to encrypt,

  • the key can be used to signV but not to sign.

• When in Retired state,

  • the key cannot be used for any crypto operation (i.e. no encrypt, decrypt, sign or signv).

It is possible to move the key back to Operational (Active) state if required. The reason for transitioning between the Operational (Active) state and the Post-operational (Restricted) should be recorded.

Destroyed (Wiped)

In this state the key bytes are deleted but meta data is preserved for audit purposes. Changing a key's state to Destroyed (Wiped) requires manual intervention and cannot be done via key-rotation/key-retention.