Key Management, CADP for C PKCS#11
Every encryption system depends on its keys to make it both unique and reversible. Poor key management is one of the most common causes of an unauthorized hack.
Manual key management was the original solution, but many of today’s systems have too much traffic and complexity to make this approach possible any longer. When secured data needs to be available at any time, and when it also needs to be protected as it moves across the network, automated key management is essential.
The CipherTrust Data Security Platform, which includes the CipherTrust Manager and the CADP for C PKCS#11 library, ensures that an overarching security policy is enforced throughout the network, resulting in lower cost and reduced risk of security loopholes.
Note
In this section, the CADP for PKCS#11 library is also referred to as CADP for C PKCS#11.
Key Headers
The CADP for C PKCS#11 provides optional header content for its generated ciphertext output. Generating ciphertext with headers allows each key to be formally versioned, and it also prevents the need for trial-and-error data decryption due to a lack of a unique identifier for any given key.
CADP for C PKCS#11 offers four header formats, three of which are based on the Data Protection Manager (DPM) format from RSA. The header format variants available are:
CipherTrust (Default)
DPM Version 1.5
DPM Version 2.1
DPM Version 2.7
Note
Keys created within the CipherTrust Manager GUI have no DPM attributes.
CipherTrust
The CipherTrust header format is the default for applications running in the CipherTrust mode. In the Vormetric Application Encryption (VAE) legacy mode (LegacyVAE), the CipherTrust header is omitted. Upon encryption, the first three bytes of the ciphertext represent the version number of the key, which was used to encrypt the plaintext. The only way to override this header format is to specify a different header.
Note
In LegacyVAE mode, the CADP for C PKCS#11 library is binary compatible with Legacy VAE while in CipherTrust mode, it is not. For more information on the differences between these modes, refer to Appendix A, Mapping of VAE Compatibility Mode and CipherTrust Mode APIs within the CADP for C PKCS#11 API Guide.
Note
The SafeNet/Ingrian header was renamed to CipherTrust.
DPM Version 1.5
Version 1.5 of the DPM header contains three elements, beginning with the header ID, followed by a null byte, and an Initialization Vector (IV), respectively. The following figure shows the bit layout of this header.
DPM Version 2.1
Version 2.1 of the DPM header contains a minimum of 12 elements, beginning with a fixed ASCII string, followed by a null byte, a length field, the string “UUID,” another null byte, a second length field, the UUID itself, other optional fields, a length field, the string “CSUM,” another null byte, a second length field, and finally the checksum. The following figure shows the bit layout of this header.
DPM Version 2.7
Version 2.7 of the DPM header is identical to version 2.1, except that (a) the UUID is replaced by a 32-byte MUID, and the string “UUID” is replaced by the string “MUID.” The following figure shows the bit layout of this header.
Headers in the API
The C_EncryptInit method in the CADP for C PKCS#11 API has bits that can force the key to use one of the supported header types or no header at all. Similarly the C_DecryptInit method must include the correct header used (if any) in its input parameters. For C_EncryptInit, the bits that can be ORed to the encryption method value are one of the following:
CKM_THALES_V27HDR 0x04000000CKM_THALES_V21HDR 0x02000000CKM_THALES_V15HDR 0x01000000
If a version 1.5 header is used, the value of:
CKM_THALES_BASE64 0x08000000
can also be ORed with the method to indicate that the whole output (header and ciphertext) should be BASE64-encoded.
If one of these modifiers is used, the following bit must also be ORed with the method:
CKM_VENDOR_DEFINED (0x80000000)
For C_DecryptInit, the value which can be ORed to the method value is:
CKM_THALES_ALLHDR 0x07000000
and optionally:
CKM_THALES_BASE64 0x08000000
If CKM_THALES_BASE64 is set, the header and the ciphertext after the header will be BASE64-decoded first.
The following table shows which header formats are compatible with which encryption methods for C_Encrypt and C_Decrypt. Note that C_EncryptUpdate, C_EncryptFinal, C_DecryptUpdate, and C_DecryptFinal have no header support for this release.
| Function | Header Format | ECB Method | CBC Method | CBC-PAD Method | CTR Method | FPE Method | FF1 Method |
|---|---|---|---|---|---|---|---|
| C_Encrypt and C_Decrypt | SafeNet | Yes | Yes | Yes | Yes | No | No |
| V 1.5 | No | Yes | Yes | No | No | No | |
| V 1.5 Base-64 | No | Yes | Yes | No | No | No | |
| V 2.1 | Yes | Yes | Yes | Yes | No | No | |
| V 2.7 | Yes | Yes | Yes | Yes | No | No |
Versioning
In CADP for C PKCS#11, a key’s version refers to one of the three RSA headers, each of which is a different version of a similar format. Once a key has been created to support versioning, the API can append any or none of these headings to a given cipher text.
Functions that decrypt the data must know which key version to expect.
Note
For rotating a key, or setting the lifespan of a key, you need to enable the Scheduler for CipherTrust Manager. For more details, refer to the Scheduler section.
Opaque Objects
Opaque objects are used to securely store data on Ciphertrust Manager. The size ranges from 1 to 8192 bytes. By default, when created through the PKCS#11 API, this object is exportable so it can be accessible from the API. The opaque objects can be used for any desired HMAC key size to perform signing and verification using HMAC-SHA mechanisms. For this to work, the opaque object must be exportable and such operations are not available in remote mode on the Ciphertrust manager.
