DUKPT: a fresh key for every card payment at the counter

A PIN pad lives on a shop counter, in a taxi, or at an unattended fuel pump. It is the one piece of payment hardware an attacker can simply walk away with. Tamper-responsive hardware makes extracting a key hard, but the design has to assume that one day someone will succeed. If the device had encrypted every PIN under one long-lived key, that success would decrypt every PIN block it had ever sent, and anyone who had been recording its traffic would get them all.

Derived Unique Key Per Transaction (DUKPT, defined in ANSI X9.24) removes that payoff. Every transaction is encrypted under its own key, and the device erases each key once it has used it, keeping only keys for transactions that haven't happened yet. Those future keys can't be run backwards, so a key pulled out of a captured device decrypts nothing it sent earlier. Breaking one device also says nothing about any other device, because no two share a key.

The acquirer (or its processor) holds a single Base Derivation Key (BDK) inside its HSM. A key injection facility uses that BDK once per device to derive an initial key from the device's initial Key Serial Number (KSN), and loads only that initial key into the device, today normally as a TR-31 key block with key usage B1. The BDK itself never leaves an HSM, and the device never learns it.

From then on every message the device sends carries its current KSN in the clear: the identifier it was injected with plus a transaction counter. The host HSM needs nothing else. It takes the BDK named by the KSN, re-derives the initial key, follows the counter to that transaction's key, and decrypts or translates the PIN block. One BDK serves any number of devices, and the host stores no per-device key at all.

The host doesn't replay every earlier transaction to reach the current key. It walks the counter's set bits from most significant to least, applying one derivation step per bit. For counter 0x15 (binary 10101) that's three steps: set bit 0x10 and derive, set 0x04 and derive, set 0x01 and derive. The device spreads the same work over time: it keeps one future-key register per counter bit (21 for TDES, 32 for AES), and after each transaction fills in the keys the next counters will need.

To keep both sides bounded, a device never uses a counter with more than 10 one bits (TDES) or 16 (AES); it skips straight past them. So the host never needs more than 10 or 16 derivation steps, however old the device is. That rule also sets the device's lifetime: TDES DUKPT has 1,048,575 usable counters, AES DUKPT about 2.4 billion. When the counter runs out, the device must be re-injected.

TDES DUKPT (X9.24-1:2009, kept as an annex of X9.24-3:2017) builds everything from TDES: the initial key (IPEK) is two TDES encryptions under the BDK and under a masked copy of it, each counter step is a DES-based non-reversible key generation process, and the working keys for PIN, MAC, and data encryption are the transaction key XORed with fixed masks. It is still the most widely deployed scheme, but it is tied to a cipher that NIST has been retiring: 2-key TDES encryption has been disallowed since 2016, and SP 800-131A Rev. 2 disallowed the last remaining 3-key TDES encryption after 2023.

AES DUKPT (X9.24-3:2017) keeps the architecture and replaces the primitives. Every derivation is AES under the parent key of a 16-byte block that names the new key's usage, algorithm, and length, so PIN, MAC, and data keys are separated by the derivation itself rather than by XOR masks. The KSN grows to 12 bytes with a 32-bit counter, the BDK can be AES-128, -192, or -256, and an AES BDK can still issue 2- or 3-key TDES working keys for host links that haven't migrated yet. It pairs naturally with ISO 9564 PIN block format 4, the 16-byte AES PIN block.

Everything hangs on the BDK. Whoever holds it can derive every key of every device injected from it, past and future, so it lives only inside HSMs, is entered or exported only as key components or under TR-31/TR-34 protection, and acquirers split their estate across several BDKs (the KSN's key set identifier or BDK ID says which one) to limit what a single compromise would expose.

DUKPT protects the past from a compromised device, not the future: an attacker who extracts a device's current future keys can derive the keys for its remaining counters, until the device is re-injected. And the device-side guarantee depends on the PIN pad really erasing used keys, which is one reason PCI PTS certifies the hardware and PCI PIN Security governs how BDKs and initial keys are generated, injected, and stored.