TR-31 & TR-34
The two foundational ANSI X9 standards for secure cryptographic key exchange between Hardware Security Modules. TR-31 defines the key block format that binds usage attributes to the key value. TR-34 defines the RSA-based protocol for distributing those key blocks from a Key Distribution Host to receiving devices without human key ceremonies.
The Problem These Standards Solve
Payment systems depend on symmetric cryptographic keys — for encrypting PINs, verifying MACs, generating EMV cryptograms. These keys must move between devices: from a bank HSM to an ATM, from an issuer to a card bureau, from a primary HSM to a backup. Doing this securely has historically required expensive physical ceremonies with multiple custodians carrying printed key components. TR-31 and TR-34 together make that process automated, auditable, and cryptographically enforced.
Key Block Format
Defines how a symmetric key is wrapped into a secure container called a key block. The key's usage, algorithm, and exportability are cryptographically bound to the encrypted key value — preventing a PIN key from being re-used as a MAC key, even if the same bytes appear in both.
- 16-character ASCII header describing key attributes
- Encrypted key payload (padded to block boundary)
- MAC authenticating the header + payload together
- Supported algorithms: DES/3DES (versions A–C) and AES (version D)
- Optional extension blocks for KCV, labels, certificate references
Key Transport Protocol
Defines the RSA-based protocol for securely delivering a TR-31 key block from a Key Distribution Host (KDH) to a Key Receiving Device (KRD). Uses X.509 certificates for mutual authentication and CMS envelopes for encryption and signing — no shared secrets required beforehand.
- 2-pass variant: KRD sends nonce; KDH responds with encrypted key
- 1-pass variant: KDH uses timestamp for batch key distribution
- RSA-OAEP encryption ensures only the KRD's HSM can decrypt the key
- RSA signature on the token proves the KDH identity
- CMS (RFC 5652) provides the signed + encrypted envelope format
How They Work Together
Key generated at KDH HSM
The bank or processor HSM generates a random symmetric key (e.g. 3DES PEK or AES IMK). The key never leaves the HSM in plaintext.
Key wrapped into TR-31 block
HSM builds a TR-31 key block header specifying key usage (P0), algorithm (T=3DES), mode (E=encrypt), exportability (N). The key is encrypted and MACed with the KBPK.
TR-34 CTKDH token created
KDH wraps the TR-31 block in a CMS EnvelopedData, encrypted with the KRD's RSA public key. The EnvelopedData is then signed (CMS SignedData) by the KDH's RSA private key. The nonce from the KRD is included to prevent replay.
Token delivered to KRD
CTKDH is transmitted over TLS. The KRD verifies the KDH's signature using the trusted CA certificate, decrypts the EnvelopedData with its own RSA private key, and loads the TR-31 block.
KCV verified & key loaded
KRD computes a Key Check Value (KCV = Encrypt(Key, 0x0000…)[0:3]) and compares it to the expected value. If they match, the key is installed in the KRD's secure boundary and is ready for use.
PCI HSM Requirements
PCI HSM (Hardware Security Module) security requirements mandate that all cryptographic keys exchanged between HSMs must use a format that cryptographically binds key usage attributes to the key value. TR-31 satisfies this requirement. Legacy "KEK-encrypted" key exchange — where the key is encrypted without binding its purpose — is prohibited under PCI HSM v3.0+. TR-34 satisfies the additional requirement for automated, auditable key transport without manual key components.
Standard Versions
| Standard | Full Name | Current Version | Scope |
|---|---|---|---|
| TR-31 | Interoperable Secure Key Exchange Key Block Specification | ANSI X9.143-2022 | Key block container format for wrapping and authenticating symmetric keys |
| TR-34 | Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques | ANSI X9.143-2022 (combined) | RSA-based protocol for transporting TR-31 key blocks between HSMs |