Dear Readers,
Anyone integrating a payment card reader runs into the same wall early: the reader hands back a block of ciphertext, and nothing in it looks like track data. This post explains why that happens, what you need in order to decrypt it, and where a free browser-based tool can save you writing the key-derivation code yourself.
The tool in question is the Encrypt/Decrypt Tool published by ID TECH, a reader manufacturer. It is ID TECH’s tool, not Ambimat’s, and it is free to use. It is a single-page HTML application with native JavaScript implementations of AES, Triple DES, DUKPT key derivation, SHA hashing and HMAC. Because everything runs in the page with no server-side component, you can download the file and read the logic in your browser’s developer tools — which is worth doing before you trust any tool with key material.
Why reader output is not simply “encrypted track data”
In almost every card-present deployment the reader does not encrypt with one fixed key. It uses a different key for every transaction, derived under DUKPT (Derived Unique Key Per Transaction), the scheme defined in ANSI X9.24. The point is containment: a key recovered from one captured transaction cannot be used to read any other transaction, and cannot be worked backwards to the key the reader started with.
The mechanics matter when you are debugging an integration:
- The reader is injected at manufacture with an Initial PIN Encryption Key (IPEK), itself derived from a Base Derivation Key (BDK) held by the acquirer or key-injection facility.
- Each read increments a transaction counter. That counter travels inside the Key Serial Number (KSN).
- The KSN is not a secret. It is transmitted in the clear alongside the ciphertext, because the receiving party needs it to re-derive the same one-time key.
- Key derivation is one-way. The KSN plus the BDK produce the transaction key; the transaction key produces nothing useful in reverse.
- Derivation is also variant-specific — a PIN key, a data key and a MAC key are derived separately from the same inputs. Using the wrong variant is one of the most common reasons a “correct” decryption returns noise.
What you need in hand before you can decrypt anything
Three things, and there is no way round any of them: the KSN for that specific transaction, the BDK the reader’s IPEK was derived from, and the encrypted data block itself. Development and test readers are usually injected with a published test BDK so that engineers can work without production key material; production readers are not, and the production BDK stays inside the key-injection facility and the acquirer’s HSM. If you are being asked to decrypt live transaction data on a laptop, something has gone wrong upstream of the code.
Decryption is unforgiving. A single incorrect bit anywhere in the derived key produces unrecognisable output rather than a partial result, so “the output is garbage” tells you the key is wrong, not that it is nearly right. Work back through the KSN, the BDK and the key variant in that order.
Where this sits in a reader integration
Encryption of this kind is a property of the reader and its key injection, not of the host application. The host receives ciphertext and a KSN, and forwards both; the decrypt normally happens at the processor or in an HSM, and the tooling above exists so that an engineer can reproduce that step on the bench while building and testing. Confirm early in a project which party holds the BDK, whether the reader is P2PE-injected, and what the acquirer expects to receive — those three answers determine most of the integration.
References:-
Encrypt/Decrypt Tool and the Parsomatic and UDemo utilities are products of ID TECH and are documented in the ID TECH knowledge base. Ambimat is not affiliated with ID TECH and does not supply these tools.
Tools for Payment Device Integration: Encrypt/Decrypt Tool — ID TECH knowledge base