A different key for every card, derived from one issuer secret
An issuer doesn't generate and separately store a unique key for every card it issues — with millions of cards in circulation, managing that key inventory would be its own massive liability. Instead, every card's ICC Master Key is derived from a single Issuer Master Key plus that card's own PAN and PAN Sequence Number, using a diversification method (commonly "Option A", built on 3DES). The issuer only ever needs to protect one master key inside its HSM; it can always reconstruct any individual card's key on demand from data the card itself supplies, but no one without that master key can derive one card's key from another's.
A session key for every transaction, not every card
Even a card-unique key would be dangerous to use directly, transaction after transaction — enough cryptograms generated under one key eventually leaks structure. So each transaction derives a fresh Session Key from the card's ICC Master Key and the Application Transaction Counter (ATC), a number the chip increments by one every time it's used. Because the ATC never repeats for a given card, no two transactions ever use the same session key — the same one-use-per-operation principle covered generally in the key derivation functions module, applied here with a bespoke 3DES-based scheme rather than HKDF or PBKDF2.
Practice
A card's ATC is currently 0042. If it's used for 5 more transactions, each incrementing the ATC by 1, what will the ATC be after the 5th transaction — and does the session key derived from ATC 0042 ever repeat?
ARQC: the card's proof that it's genuine
During the transaction, the terminal assembles a data block describing it — amount, currency, date, terminal risk data, the ATC — and sends it to the chip. The chip computes the Authorization Request Cryptogram (ARQC) as a MAC over that data using the session key: not an encryption of the data, but a keyed one-way fingerprint that only a chip holding the genuine session key could have produced, exactly the MAC concept the hash functions and signatures module covers generally. That ARQC travels with the authorization request all the way to the issuer.
One chip transaction, start to finish
- 1
Terminal sends transaction data + ATC to the chip
Amount, currency, date, terminal risk data.
- 2
Chip derives its session key and computes the ARQC
A MAC over the transaction data — proof this specific card produced this specific request.
- 3
ARQC travels to the issuer's HSM via the acquirer and network
The same HSM boundary that handles PIN translation typically validates cryptograms too.
- 4
Issuer HSM re-derives the identical session key and recomputes the ARQC
It knows the issuer master key, the card's PAN/PSN, and the ATC — everything needed to reproduce the chip's own computation independently.
- 5
Issuer HSM computes the ARPC and returns it in the authorization response
The card's proof that the approval genuinely came from its issuer, not an intercepted or forged response.
ARPC: proving the approval itself isn't forged
An ARQC alone only authenticates the card to the issuer — it does nothing to stop an attacker from injecting a fake "approved" response into the transaction. The issuer's HSM closes that gap by computing an Authorization Response Cryptogram (ARPC), typically the ARQC itself encrypted (or MAC'd) together with the actual authorization response code, using the same session key. The chip, which has that session key too, independently verifies the ARPC before accepting the approval — so a network intermediary that isn't the genuine issuer simply cannot produce a response the card will accept, regardless of what authorization code it tries to inject.
Practice
An attacker who has intercepted a transaction on the network (but doesn't hold the issuer's keys) tries to inject a fake "approved" ARPC before the real issuer responds. Will the card accept it?
Why this doesn't need the issuer online for every offline-capable card
Not every chip transaction reaches the issuer — offline-capable cards can approve small transactions using Static or Dynamic Data Authentication (SDA/DDA), asymmetric-key mechanisms closer to a digital signature (covered generally in the hash functions and signatures and RSA modules) that let the terminal itself verify the chip is genuine without a live network round trip. ARQC/ARPC is specifically the online path: whenever a transaction does reach the issuer, this cryptogram exchange is what happens, and it's this exact mechanism a payment HSM performs on the issuer's behalf at the volumes a card network actually runs at.