Key block formats, explained

September 2026 · 9 minute read

Every key that moves through a payment system rides inside an envelope. The envelope says what the key is, what it's allowed to do, and proves nobody tampered with it on the way. That envelope is called a key block, and it's one of the least talked-about, most load-bearing pieces of payment security.

The problem key blocks solve

Before key blocks, keys travelled as plain encrypted bytes, with no attached metadata. A key was just a key. Nothing in the data said whether it was meant for PIN encryption, for MAC generation, or for something else entirely, and nothing stopped someone from taking a key meant for one job and quietly using it for another.

The industry's first fix was key variants: XOR a fixed, publicly known value into a key to mark its purpose. It worked, but it was fragile. Because the variant values were predictable, an attacker who could manipulate ciphertext could sometimes trick a system into using a key for the wrong purpose, a class of attack that shows up again and again in old HSM security reviews.

Mohamed Atalla's answer, in the 1990s, was to stop treating the key's purpose as an assumption and start treating it as data. Bind the key's usage, algorithm, and permissions to the key itself, cryptographically, so tampering with either one breaks the whole envelope. That idea became the Atalla Key Block, and nearly every format since has been a refinement of it.

Anatomy of a key block

Strip away the branding and every key block format is doing the same three jobs, just with different amounts of polish.

That third part is the whole point. The MAC is computed over both the header and the encrypted key together, which cryptographically welds them into one unit. Change the header from "PIN encryption only" to "data encryption," even by a single bit, and the MAC no longer checks out. The key block is rejected before anyone gets to misuse it. That's the entire security upgrade over key variants in one sentence: usage stopped being an assumption and became a tamper-evident fact.

The format family

Once the idea existed, everyone built their own version of it. Some stayed close to the original; some diverged into proprietary territory. Here's the field, at a glance.

Notice the split. Atalla, TR-31, Thales and ISO 20038 all assume the two sides already share a secret key-encrypting key, and they use it to wrap the new key. TR-34 solves a different problem: how do you load a key into a brand-new ATM that has never talked to your HSM before and shares nothing with it yet? For that, you need asymmetric cryptography to bootstrap the very first secret, and TR-34 is where RSA earns its keep in this story.

How TR-34 bootstraps trust

TR-34 gives the two ends formal names: the KDH, key distribution host, which is your HSM in a controlled environment, and the KRD, key receiving device, typically an ATM or POS terminal fresh out of the box.

This is the same public-key logic from the RSA explainer, just aimed at a narrower job: get one symmetric key safely from an HSM into a terminal that has no prior relationship with it, over a channel you don't necessarily trust. Once that first key lands, every key after it can travel the simpler, symmetric way, wrapped in TR-31 or a Thales key block instead.

Where key blocks live in a transaction

Key blocks aren't something a cardholder ever sees, but they're doing quiet work at nearly every hop behind the scenes.

1. CeremonyA key is born inside an HSM during a key ceremony, formatted into a key block the moment it's generated, and never exists in the clear outside that hardware.
2. LoadingNew terminals get their first key via TR-34 remote key loading, no technician typing in key components by hand.
3. In transitKeys shipped between an issuer's HSM and an acquirer's HSM, or across a payment network's key-exchange service, travel wrapped in TR-31 or a vendor-specific equivalent.
4. At restKeys sitting inside a key management system's database are stored as key blocks too, not just protected in transit.
5. TranslationWhen a switch re-encrypts a PIN block from one zone key to another, it unwraps one key block and rewraps the result in a fresh one, at high volume, many times a second.

Why this actually matters

PCI's PIN Security Requirement 18-3 doesn't suggest key blocks, it mandates them: encrypted symmetric keys must be managed in structures called key blocks, with key usage cryptographically bound to the key. The rollout ran in three phases, internal HSM connections and storage from mid-2019, external networks from 2023, and full coverage across merchant hosts, POS and ATMs from 2025. If you touch PINs anywhere in your stack, key blocks aren't optional architecture, they're a compliance floor.

The reason regulators care this much comes back to that XOR-based key variant weakness. A key block turns "please trust that this key is only used for X" into "the hardware mathematically cannot use this key for anything other than X." That's the difference between a policy and a guarantee.

What changes with post-quantum and AI

Every key block header today has a field for the key's algorithm, and today that field says things like TDES, AES or RSA. Post-quantum algorithms like ML-KEM and ML-DSA don't fit neatly into those slots yet. Standards bodies haven't finished defining how a key block header should describe a lattice-based key, what its exportability rules look like, or how the MAC computation should adapt to different key sizes. That's unfinished work, not a solved problem, and it's exactly the kind of thing that determines whether a payment network can migrate smoothly or ends up bolting on a parallel system.

The AI angle is closer than it looks. In the whitepaper on agentic commerce, the open question was where an AI agent's signing key actually lives, how it's provisioned, rotated and revoked at scale. A key block is precisely the envelope built to answer that question for every other key in payments: usage cryptographically bound to the key, tamper-evident, standardised enough to move between systems. As agents start needing their own scoped, short-lived credentials issued and rotated automatically, the field is likely to lean on key block-style structures rather than invent something new. The format that quietly solved "how do we stop a key from being used for the wrong thing" in 1990s ATMs may end up solving the same problem for autonomous agents thirty-five years later.