← Payment Reference GuidesKey Management Standards

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.

ANSI X9.143PCI HSMHSM Key ExchangeRSA-OAEPCMS / ASN.1

Key Management in Practice

TR-31 and TR-34 solve the transport problem, but key management is a lifecycle — from generation through rotation to destruction. This section covers how these standards fit into a real HSM key management operation.

Common Use Cases

🏧

ATM PIN Encryption Key Loading

An acquirer distributes Zone PIN Keys (ZPK / PEK) to ATMs during initial deployment and on annual rotation. The KRD (EPP) uses 2-pass TR-34 to receive the key from the acquirer's HSM. Key usage P0, algorithm 3DES, exportability N.

P0 T E 00 N — PIN key, 3DES, encrypt-only, non-exportable

💳

EMV Issuer Master Key Delivery

An issuer sends Issuer Master Keys (IMK-AC, IMK-SM, IMK-DN) to a card bureau HSM for EMV personalisation. TR-34 2-pass delivers each IMK individually. Key usage E0/E1/E4, algorithm AES-128.

E0 A B 00 N — EMV ARQC MK, AES, both derive+verify, non-exportable

🔄

Batch Key Rotation (POS Estate)

A processor rotates working keys across 50,000 POS terminals annually. 1-pass TR-34 allows the processor to pre-generate all encrypted tokens offline and deliver via terminal management system without each terminal initiating a request.

K0 A B 00 E — KEK, AES, both, exportable — for re-wrapping subsequent keys

🏦

HSM Disaster Recovery

A backup HSM must be loaded with production working keys. TR-34 2-pass from primary to backup HSM avoids any plaintext key exposure. Each working key is delivered as a separate TR-34 session; KCVs are cross-checked.

Multiple key usages — all non-exportable; KCVs verified after each load

🏭

DUKPT BDK Injection

A Base Derivation Key (BDK) is delivered to an injection HSM so it can inject IPEKs into POS terminals during manufacturing. Key usage B0, algorithm 3DES or AES, mode X (derivation only).

B0 T X 00 S — BDK, 3DES, derive-only, sensitive

💡

CVK Delivery for Card Personalisation

A Card Verification Key (CVK) is delivered from an issuer to a card bureau so they can compute CVV/CVC values during card printing. Key usage C0, algorithm 3DES, mode G (generate only).

C0 T G 00 N — CVK, 3DES, MAC-generate only, non-exportable

Key Check Value (KCV)

After loading a key, the receiving party computes a KCV to verify the correct key was received. The KCV does not reveal the key but provides a short fingerprint that both parties can compare.

3DES KCV
Encrypt 8 zero bytes with the 3DES key in ECB mode. Take the first 3 bytes of the result.

KCV = 3DES-ECB_Key(0x0000000000000000)[0:3]

AES KCV
Encrypt 16 zero bytes with the AES key in ECB mode. Take the first 3 bytes (or first 5 bytes for CMAC-based KCV).

KCV = AES-ECB_Key(0x00000000000000000000000000000000)[0:3]

Certificate Lifecycle

Phase	KDH Action	KRD Action
Enrolment	Generate RSA key-pair in HSM. Submit CSR to CA. Install CertKDH.	Generate RSA key-pair in HSM (manufacture time). Submit CSR. Install CertKRD.
Trust establishment	Install CA root certificate as trust anchor.	Install CA root certificate as trust anchor. May pre-load CertKDH for 1-pass.
Key exchange	Receive/validate CertKRD. Build and sign CTKDH token.	Send CertKRD + RKRD (2-pass). Validate CertKDH on receipt.
Rotation	Before cert expiry, re-enrol. Distribute new CertKDH to all KRDs.	Before cert expiry, re-enrol. New CTKRD sent in next 2-pass handshake.
Revocation	CRL or OCSP used. Tampered HSM certificate revoked immediately.	Tampered KRD triggers self-erase + certificate revocation. Key exchange halted.