DUKPT key derivation
Derive the IPEK from a BDK and KSN, walk the KSN counter to this transaction's key, and split it into PIN, MAC and data working keys — with the full derivation trail, so you can see the ANSI X9.24-1 (TDES) algorithm work step by step. Everything is hex, and nothing leaves your browser.
16 bytes / 32 hex characters (double-length TDES key).
10 bytes / 20 hex characters; the low 21 bits are the transaction counter.
Derived keys
Transaction counter: 0
IPEK
Initial PIN Encryption Key
Transaction key
This counter's derived key
PIN key
Transaction key, PIN variant
MAC key
Transaction key, MAC variant
Data key
Variant, re-encrypted under itself
Derivation trail
One non-reversible step per set bit of the counter, from the IPEK to the transaction key.
| Step | Counter bit | Key after step |
|---|
Counter is zero — the transaction key is the IPEK, with no derivation steps.
Use a derived key
Notes
- What are the BDK, KSN, IPEK and transaction key?
- The BDK (Base Derivation Key) is the secret held by the acquirer, shared across a fleet of devices. The KSN (Key Serial Number) identifies a device and carries a 21-bit transaction counter. The IPEK (Initial PIN Encryption Key) is derived once per device from the BDK and the device's initial KSN and injected at manufacture. Each transaction then derives a unique key by walking the IPEK forward through the KSN counter — that is the transaction (session) key.
- Why is it "derived unique key per transaction"?
- Every transaction uses a different key, and the derivation is one-way: a terminal can compute this transaction's key and the ones ahead of it, but never an earlier one. So capturing a device at counter 1000 does not expose the keys used for counters 1 to 999. The forward-only walk — the non-reversible key-generation step run once per set counter bit — is what gives that property.
- What are the PIN, MAC and data working keys?
- The transaction key is not used directly. It is split into purpose-specific working keys by XORing a variant constant: a PIN key for encrypting PIN blocks, a MAC key for message authentication, and a data key for field encryption. The data key is additionally encrypted under itself so it cannot be walked back to the transaction key. Keeping the purposes separate means a weakness in one use cannot leak another.
- Is this safe to use with real keys?
- It is correct — anchored to the canonical ANSI X9.24-1 example (IPEK 6AC292FAA1315B4D858AB3A3D7D5933A) — and runs entirely in your browser with no backend. But it is a teaching and debugging aid, not an HSM. Real BDKs never leave hardware security modules, and you should never paste production key material into any web page, this one included.
These are debugging aids, not certified reference implementations. If a tool disagrees with your specification, trust the specification.