TR-31 symmetric key management

The format of a TR-31 key block is defined in ASC X9 TR 31-2018: Interoperable Secure Key Exchange Block Specification.

The provided information is an extension of Managing AES, DES, and HMAC cryptographic keys. Refer to this topic for additional information on symmetric keys, including DES control vectors.

This topic describes the interchange of symmetric keys and other sensitive data between a CCA device and any other device that together share an external TR-31 key block (symmetric-key exchange key). The format of this TR-31 key block is defined in ASC X9 TR 31-2018: Interoperable Secure Key Exchange Block Specification. ASC X9 only defines the wrapping and unwrapping of DES and TDES keys using a DES key-encrypting key. Beginning with Release 5.4, the TR-31 key block supports the AES Key Derivation Binding Method 2017 Edition (method "D") as defined in ISO 20038. Method "D" supports the wrapping and unwrapping of AES, DES, and TDES keys using an AES key-encrypting key and, beginning with Release 5.6, supports the wrapping and unwrapping of HMAC keys using an AES key-encrypting key.

The TR-31 key block is a format defined by the ANS Standards Committee to support interchange of symmetric keys in a secure manner and with key attributes included in the exchanged data. At the beginning of every TR-31 key block is a header consisting of a required portion possibly followed by an optional portion. The format of the required portion along with the values that CCA supports are shown in TR-31 key block header. As you can see from this table, offset 0 is a one-byte key block version ID field, also called a method, offset 5 is a two-byte key usage field which maps to the CCA key type, offset 7 is a one-byte algorithm field for the key being protected, offset 8 is a one-byte mode of use field which maps to CCA key usage, and offset 11 is a one-byte exportability field. These fields are referenced later in this topic.

TR-31 is a Technical Report. This is different from a standard, which is a mandatory set of rules that must be followed. A Technical Report is not mandatory, but provides guidance to those who are using the standards. In this case, TR-31 is a companion to the standard X9.24-1, which defines requirements for key management performed using symmetric key techniques. TR-31 shows a method that complies with the various requirements that are defined in X9.24-1, and because no other specific method has been defined by the standards committee, the TR-31 method is becoming the apparent standard through which financial organizations will exchange keys.

Prior to TR-31, there were problems with the interchange of symmetric keys. In the banking environment, it is very important that each symmetric key have a specific set of attributes attached to it, specifying such things as the cryptographic operations for which that key can be used. CCA implements these attributes in the form of the control vector (CV), but other vendors implement attributes in their own proprietary ways. Thus, if you are exchanging keys between CCA systems, you can securely pass the attributes using CCA functions and data structures. If, however, that same key were sent to a non-CCA system, there would be no secure way to do that. This is because the two cryptographic architectures have no common key format that could be used to pass both the key and its attributes. As a result, the normal approach has been to strip the attributes and send just the encrypted key, then attach attributes again at the receiving end.

The above scenario has major security problems because it allows an insider to obtain the key without its designated attributes. The insider can then attach other attributes to it, thereby compromising the security of the system. For example, assume the exchanged key is a key-encrypting key (KEK). The attributes of a KEK should restrict its use to key management functions that are designed to prevent exposure of the keys that the KEK is used to encrypt. If that KEK is transmitted without any attributes, an attacker on the inside can turn the key into a type used for data decryption. Such a key can then be used to decipher all of the keys that were previously protected using the KEK. It is clearly very desirable to have a way of exchanging keys that prevents this modification of the attributes. TR-31 provides such a method.

The TR-31 key block has a set of defined key attributes. These attributes are securely bound to the key so that they can be transported together between any two systems that both understand the TR-31 format. This is much of the reason for its gain in popularity.

Beginning with Release 5.4, a block cipher AES method is added as the wrapping cipher algorithm for protecting the TR-31 key block, as defined by ISO 20038. This method is identified by key block version ID value "D" (X'44'), and can protect an AES, DES, or TDES key.

Beginning with Release 5.6, a block cipher AES method is added as the wrapping cipher algorithm for protecting the TR-31 key block, as defined by ISO 20038 or ASC X9 TR 31-2018. This method is identified by key block version ID value "D" (X'44'), and can protect an HMAC key.

Not surprisingly, TR-31 uses some key attributes that are different from those in the CCA symmetric key-token. In some cases, there is a one-to-one correspondence between TR-31 attributes and CCA attributes. For these cases, conversion is simple and straightforward. In other cases, the correspondence is one-to-many or many-to-one, and the application program must provide information to help the CCA verbs decide how to perform the translation between CCA and TR-31 attributes. There are also CCA attributes that simply cannot be represented using TR-31. CCA keys with those attributes are not eligible for conversion to TR-31 format.