The Cryptogram

15.0 What this chapter gives you#

1. You will be able to explain why a criminal holding a perfect byte-for-byte record of everything a card said last Tuesday cannot use that record to buy anything on Wednesday.
2. You will be able to say why the Application Cryptogram is a message authentication code and not a signature, and why the terminal that carries it cannot check a single bit of it.
3. You will be able to name the three cryptogram types and explain why a refusal is sealed as carefully as an approval.
4. You will be able to walk the three-level key hierarchy from an issuer master key, through a card-unique key derived with the account number and sequence number, to a session key derived with the transaction counter.
5. You will be able to assemble the byte string a cryptogram is computed over, pad it correctly, and explain why the mandatory '80' byte is appended even when the message is already a multiple of eight.
6. You will be able to read an Issuer Application Data field, pull out the Derivation Key Index, the Cryptogram Version Number and the Card Verification Results, and say why that version byte is the most load-bearing byte in the whole message.
7. You will be able to distinguish the two Authorisation Response Cryptogram methods and explain how the issuer’s approval travels inside a MAC so that nobody in the chain can flip it.
8. You will be able to state precisely what a valid cryptogram proves and what it does not — not that a cardholder was present, not that a PIN was entered, not that the amount displayed matched the amount authenticated, and not which merchant was involved.
9. You will be able to give an honest account of the transaction counter: it makes replay detectable rather than impossible, and real issuer hosts apply a window rather than a hard ceiling for defensible reasons.
10. You will be able to diagnose a failing cryptogram from the pattern of which cards fail, knowing that the mathematics has not failed in the field and the byte strings fed to it fail constantly.

Every chapter of this volume so far has described something the card has. A number embossed on the front. A stripe with three tracks. A printed code on the signature panel. A chip that runs a program and answers questions. All of it is data, and all data can be copied.

This chapter is about the one thing on the card that cannot be copied, because it does not exist until the moment of the transaction and it is never the same twice. It is eight bytes long. It is called the Application Cryptogram, and it is the reason that a criminal holding a perfect byte-for-byte record of everything your card said last Tuesday cannot use that record to buy anything on Wednesday.

It is also the single most misunderstood object in payments. People who work with cards every day will tell you the chip “signs” the transaction, which is not quite what happens; that the cryptogram proves the cardholder was present, which it does not; or that the terminal checks it, which it emphatically cannot. Getting this right matters more than getting any other detail in this volume right, because when a cryptogram fails there is no diagnostic. The issuer’s host sees a mismatch between sixteen hexadecimal characters it computed and sixteen it received, and it has no way of telling you which of the eleven inputs was wrong. Engineers lose weeks to this. The purpose of this chapter is that you should not.

The plain version#

Imagine you and your bank have agreed on a secret recipe.

The recipe is not a password and it is not a code word. It is a method: a way of taking any piece of writing, stirring it through a fixed sequence of steps, and producing sixteen characters of gibberish at the end. The stirring is designed so that changing anything at all in the writing — one digit, one letter, a single space — changes every one of the sixteen output characters completely and unpredictably. There is no way to work backwards from the gibberish to the writing, and no way to produce the right gibberish for a given piece of writing unless you know the recipe.

You keep the recipe. The bank keeps the recipe. Nobody else has it.

Now you go to buy a coffee.

What gets written down#

The till writes out a short statement of exactly what is about to happen. Not a description in words — a fixed list of facts, always the same facts in always the same order, because both you and the bank need to write out the identical statement or the gibberish will not match.

The statement for a coffee in Leeds on 17 August 2026 says:

• The amount is four pounds twenty.
• There is no cashback.
• The till is in the United Kingdom.
• The till’s own safety checks found one thing worth mentioning: this purchase is above the amount the shop is allowed to approve on its own.
• The money is pounds sterling.
• The date is the seventeenth of August.
• This is a purchase, not a refund and not a cash withdrawal.
• Here is a number the till just made up on the spot: 9A1BC3D4. It has never used it before and will never use it again.

Then the card adds two facts of its own:

• Here is what I am capable of doing.
• This is the sixty-first time I have ever been used.

The card stirs that whole statement through the recipe and produces sixteen characters: 733084432BA24DAE.

Why those last two facts are the clever part#

The till’s made-up number is there to defeat the eavesdropper. Suppose somebody has been recording everything your card says. They have last Tuesday’s sixteen characters. To reuse them they would need today’s statement to be identical to Tuesday’s — but today’s till invented a different number, so it is not identical, so Tuesday’s gibberish is wrong. It is refused.

The card’s own count is there to defeat something subtler: the shop itself. A dishonest shop could take a genuine statement and a genuine set of sixteen characters and send the pair to the bank twice, hoping to be paid twice. But the card counts every single use, and the count is inside the statement. The bank sees that use number sixty-one has already been paid for. The second copy is refused.

The count also does something else, which is quieter and more important. The recipe changes every time the count changes. It is not literally one fixed recipe; it is a family of recipes, and the count picks which member of the family is used today. So even if somebody somehow worked out the exact recipe used for purchase sixty-one, it would tell them nothing at all about purchase sixty-two.

Three possible answers#

When the till hands the statement to the card, it is not just asking for a signature. It is asking a question, and the card gets to answer it. There are three answers, and each comes with its own set of sixteen characters.

The card can say yes, on my own authority — I know this cardholder, the amount is small, I have not been used much lately, go ahead without asking the bank. This answer is called a Transaction Certificate.

The card can say ask the bank — this needs a decision I am not entitled to make. This answer is called an Authorisation Request Cryptogram. The sixteen characters travel across the world to the bank, which recomputes them and compares.

The card can say no. This answer is called an Application Authentication Cryptogram, and — this is the part people find odd — it still comes with sixteen characters. The refusal is sealed too, so that nobody downstream can quietly turn a refusal into an approval.

And here is a detail worth carrying to dinner: the till asks for one of these three, and the card is allowed to give a worse answer than the one requested. A till can ask for “yes, on your own authority” and be told “ask the bank”. It can ask for “ask the bank” and be told “no”. It can never be told something better than it asked for. The terminal proposes; the card disposes.

The bank answers with a seal of its own#

The bank recomputes the sixteen characters from its own copy of the recipe. They match. The bank checks the balance and decides to approve.

Now the bank has a problem. If it just sends back the word “approved”, anybody in the chain — the shop’s till, the shop’s software, the phone line — could invent that word. So the bank does the same trick in reverse. It takes the card’s sixteen characters, mixes in its answer, stirs the result through the shared recipe, and sends back its own short scramble.

The card receives it, does the same calculation, and if the two agree the card knows something quite specific: the bank itself, and nobody in between, said yes to this exact transaction. Only then will it act on instructions from the bank — reset a PIN counter, clear its offline spending allowance, or in the extreme case block itself.

That is the whole mechanism. Two seals, one from the card and one from the bank, over a statement that both of them wrote out identically, using a recipe that changes on every use.

Where the plain version stops being true#

The recipe picture gets you to the right conclusion, and it hides four things that matter enormously in practice.

It is not a signature, and the terminal cannot check it#

The word “sign” implies that anyone can verify and only one party can produce. That is asymmetric cryptography, and the Application Cryptogram is not that. It is a Message Authentication Code computed with a symmetric key. Card and issuer hold the same secret. Anybody who can verify a cryptogram can also forge one.

This has an immediate practical consequence that surprises people: the terminal cannot verify the cryptogram at all. It has no key and never will. When a terminal receives eight bytes back from a GENERATE AC command it has no idea whether they are correct, random, or fabricated. It copies them into the authorisation message and forwards them. Everything the terminal does to satisfy itself that the card is genuine — static, dynamic and combined data authentication — is a separate mechanism using public keys, which was Chapter 4’s subject. The cryptogram is not part of it.

Because the key is symmetric, the security of the whole scheme rests on the key never leaving tamper-resistant hardware at either end: a chip on one side, a hardware security module on the other. A single issuer master key extracted from a poorly managed host is not one compromised card. It is every card in that key’s range, forever.

There is no such thing as “the data the card signs”#

The plain version implies a fixed list. There is not one. EMV Book 2 section 8.1.1 gives a table of ten elements and calls it the “recommended minimum set”. It is a recommendation. What is actually included, and in what order, is fixed by the application’s Cryptogram Version Number, which is a scheme-proprietary value published in Visa’s, Mastercard’s, Amex’s, JCB’s and UnionPay’s own specifications and not in EMV’s.

Two cards from the same issuer with different Cryptogram Version Numbers compute cryptograms over different byte strings. An issuer host that assumes one layout for all its cards will silently fail on the others. This is, by a wide margin, the most common cause of “the cryptogram does not verify and we cannot work out why”.

It says nothing about the cardholder, the merchant, or what you agreed to#

A valid ARQC proves that a chip holding the correct key participated in a transaction with those exact parameters. It proves nothing else.

It does not prove the cardholder was present. It does not prove a PIN was entered — cardholder verification is reported separately, in the Cardholder Verification Method Results and in the card’s own Card Verification Results, and an attacker who can suppress the PIN check can still obtain a perfectly valid cryptogram. It does not prove the amount displayed to the customer matches the amount in the command; it authenticates the amount the terminal supplied. And it does not identify the merchant: neither the merchant identifier nor the terminal identifier is in the recommended minimum set.

The counter only stops replay if somebody checks it#

The Application Transaction Counter makes replay detectable. It does not make it impossible. Detection requires the issuer to remember the highest counter value it has seen for that card and refuse anything at or below it.

Real issuer hosts are much less strict than that, and for defensible reasons: authorisations arrive out of order, offline transactions consume counter values that never reach the host at all, reversals and pre-authorisations complicate the sequence, and a card used at an unattended terminal may burn counter values with no corresponding message. Most hosts therefore apply a window rather than a hard ceiling, and some check nothing at all. A gap in the counter is evidence of offline activity, not of fraud; a repeat is evidence of something wrong, but not necessarily of an attack.

The technical version#

The three cryptogram types#

The terminal requests a cryptogram with the GENERATE APPLICATION CRYPTOGRAM command — class '80', instruction 'AE', P2 '00' — and states which type it wants in P1, the reference control parameter. The top two bits carry the request; bit 5 additionally asks the card to return a combined dynamic signature.

The card replies with the cryptogram and with a single byte, the Cryptogram Information Data, tag 9F27, stating which type it actually generated. The top two bits use the same encoding as P1. Bits b6 and b5 flag a payment-system-specific cryptogram, bit b4 indicates that an advice message is required, and bits b3 to b1 carry a reason or advice code: 000 no information given, 001 service not allowed, 010 PIN Try Limit exceeded, 011 issuer authentication failed.

The industry is not consistent about 1 1 in the Cryptogram Information Data. Older editions of Book 3, and a good deal of kernel documentation still in circulation, label it AAR — Application Authorisation Referral, the card asking for a voice referral. Referral processing does not appear in EMV 4.3 Book 2 at all, current terminal specifications do not implement it, and current tag references treat the value as reserved. Treat any card that returns it as broken rather than as requesting a referral.

The response arrives in one of two shapes. Format 1, template tag '80', is a primitive object: Cryptogram Information Data, then Application Transaction Counter, then Application Cryptogram, then optionally Issuer Application Data, concatenated with no tags and no lengths. Format 2, template tag '77', is TLV-encoded, with 9F27, 9F36 and 9F26 mandatory and 9F10 optional. A Common Core Definitions application must use format 2 and must include a 32-byte 9F10.

The key hierarchy#

Three levels, and everything else in this chapter depends on keeping them straight.

At the top sits the Issuer Master Key for Application Cryptograms, IMK-AC. One per issuer per key range, held in the issuer’s hardware security module, never in a card. Under two-key Triple DES it is 128 bits; the AES option supports 128, 192 and 256.

From it, at personalisation, the issuer derives one ICC Application Cryptogram Master Key, MK-AC, per card. EMV Book 2 Annex A1.4 gives three optional methods, all taking the Application PAN and the PAN Sequence Number as input:

None of the three is mandatory; Book 2 says so explicitly. Issuers may adopt another method, and some do.

From MK-AC, at transaction time, both card and issuer derive a session key, SK-AC. Book 2 Annex A1.3.1 specifies the Common Session Key option. The diversification value R for Application Cryptogram and ARPC generation is the two-byte Application Transaction Counter followed by n−2 bytes of '00'. Where the key is longer than the block — Triple DES with a 128-bit key, or AES with 192 or 256 bits — two blocks are built from R:

F1 = R with byte 3 replaced by 'F0'
F2 = R with byte 3 replaced by '0F'
SK = leftmost k bits of { ALG(MK)[F1] || ALG(MK)[F2] }

Where key and block are the same size — AES-128 — the derivation collapses to SK := AES(MK)[R]. The same session key is used for every command in a single transaction, which is why the second GENERATE AC does not need a fresh derivation.

Not every application uses this. Visa Cryptogram Version 10 performs no session key derivation at all: the card master key is the cryptogram key. Visa CVN 18 and CVN 22, and Mastercard CVN 14 and CVN 15, use the Common Session Key method above. Mastercard CVN 12 and CVN 13 use an older Mastercard derivation that folds the terminal’s Unpredictable Number into the session key as well as the counter.

A worked derivation#

Take an issuer master key of 0123456789ABCDEFFEDCBA9876543210 — a test key, not a real one — a PAN of 4111111111111111 and a PAN Sequence Number of 01.

Option A concatenates them to 411111111111111101, eighteen digits, and takes the rightmost sixteen:

Y      = 1111111111111101
MK_AC  = A768CE9E1551FDE3A45B4C7C3DE9DC52

The card is on its sixty-first use, so the Application Transaction Counter is 003D. The diversification value and the two derivation blocks are:

R      = 003D000000000000
F1     = 003DF00000000000
F2     = 003D0F0000000000
SK_AC  = C471A83E37AEF3FE5D4CEF548575DD9C

Everything from here uses SK_AC and nothing else. MK_AC is not touched again until the next transaction.

What goes into the MAC#

Book 2 section 8.1.1 gives the recommended minimum set. Eight elements come from the terminal, two from the card:

For a Common Core Definitions application with Cryptogram Version '5' or '6', Book 2 replaces that table with a mandatory eleven-element list in a fixed order — the ten above, in exactly that order, followed by the Issuer Application Data. Every real scheme implementation does something equivalent: it appends the card’s own Card Verification Results, which live inside the Issuer Application Data, to the end of the terminal’s eight elements and the card’s two.

The terminal does not choose which elements to send. The card publishes CDOL1, tag 8C, a Card Risk Management Data Object List naming the tags and lengths the terminal must concatenate into the first GENERATE AC command, and CDOL2, tag 8D, for the second. The terminal fills the template in the order given. The Data Object List padding and truncation rules of Book 3 section 5.4 apply in full, and they are asymmetric: numeric-format elements are truncated from the left and padded with leading zeroes, everything else is truncated from the right and padded with trailing zeroes, and compressed numeric is padded with trailing 'FF's. Getting that backwards produces a well-formed command that yields a cryptogram nobody can verify.

Here is the actual byte string for our £4.20 coffee, purchased in the United Kingdom on 17 August 2026 at a terminal whose floor limit the amount exceeds:

Three of those values deserve a sentence each. The amounts are numeric format, twelve digits packed as six bytes, so £4.20 is 000000000420 and not four hundred and twenty of anything — the currency’s minor-unit exponent is not in the string, which is why the Transaction Currency Code has to be. The Terminal Verification Results byte 4 has bit 8 set, which is “transaction exceeds floor limit”: that single bit is the reason the terminal asked for an ARQC rather than a TC. And the Application Interchange Profile byte 1 bit 3 is set, meaning “issuer authentication is supported” — the card will accept an EXTERNAL AUTHENTICATE command later.

Concatenated, that is thirty-seven bytes:

000000000420 000000000000 0826 0000008000 0826 260817 00
9A1BC3D4 1D00 003D 03A00000

The MAC algorithm#

Book 2 Annex A1.2.1 specifies the computation for an 8-byte block cipher. It is ISO/IEC 9797-1 with the message padded according to ISO/IEC 7816-4, which the specification notes is equivalent to padding method 2 of ISO/IEC 9797-1: append a mandatory '80' byte, then the smallest number of '00' bytes that brings the length to a multiple of eight. The '80' is mandatory even when the message is already a multiple of eight. Our thirty-seven bytes become forty:

...9F36 003D  03A00000  80 0000

Split into five 8-byte blocks X1..X5. The session key is treated as a left half KSL and a right half KSR. Chain the blocks in CBC mode using single DES with KSL only, starting from an initial value of eight zero bytes:

Hi := ALG(KSL)[ Xi XOR Hi-1 ],  for i = 1..B,  H0 = '0000000000000000'

Then apply the output transformation. Book 2 permits either ISO/IEC 9797-1 Algorithm 1, which is simply HB+1 := HB, or Algorithm 3:

HB+1 := ALG(KSL)[ ALG-1(KSR)[ HB ] ]

Algorithm 3 — encrypt with the left half, decrypt with the right, encrypt with the left again, applied only to the final chaining value — is what every deployed scheme uses, and it is what Book 2 mandates for the Common Core Definitions Cryptogram Version '5'. It is the construction the banking world calls the Retail MAC or the ANSI X9.19 MAC. The Application Cryptogram is the s most significant bytes of HB+1 with s = 8, so the whole of it.

For our example:

ARQC = 733084432BA24DAE

Eight bytes. Sixty-four bits. An attacker with no key guesses correctly about once in eighteen quintillion attempts, and the issuer will have declined and blocked the card long before that.

The AES option, Annex A1.2.2, is a different construction: ISO/IEC 9797-1:2011 Algorithm 5, which is CMAC, over 16-byte blocks, with the two CMAC subkeys K1 and K2 derived from the session key and the constant '10000111'. Padding is added only when the message is not already a multiple of sixteen, and the final block is masked with K1 when no padding was added and K2 when it was. Cryptogram Version '6' of the Common Core Definitions mandates AES CMAC with s = 8, and requires Option C master key derivation to go with it. Cryptogram Version '5' mandates Triple DES, Algorithm 3, and Option B.

The Application Transaction Counter#

Tag 9F36, two bytes, binary, maintained entirely by the card. The terminal cannot write it and the issuer cannot reset it. It increments once per transaction — in practice on the first GENERATE AC, or on GET PROCESSING OPTIONS in some contactless kernels — and it does not decrement.

Two bytes means the counter tops out at FFFF, 65,535. What a card does on reaching that ceiling is application-defined rather than specified by EMV; the counter is not permitted to be reused, so an application that reaches it has reached the end of its life. At a hundred transactions a month a card would need fifty-four years to get there, so it is not a practical constraint for a payment card, though it is a real one for some transit and stored-value applications.

The counter does three jobs at once, and they are worth separating.

It diversifies the session key. This is its cryptographic job and it is the reason it appears in R. Every transaction uses a different key, so a compromise of one transaction’s key compromises exactly one transaction.

It is inside the signed data, as one of the ten recommended minimum elements. So it cannot be tampered with in flight, and its value binds the cryptogram to a specific position in the card’s lifetime.

It is visible to terminal risk management. The terminal reads it directly with GET DATA — 80 CA 9F 36 00 — along with the Last Online Application Transaction Counter Register, tag 9F13, which records the counter value at the last transaction that actually went online. The difference between the two is the number of transactions the card has completed offline since it last spoke to its issuer. The terminal compares that difference against the card’s Lower Consecutive Offline Limit, tag 9F14, and Upper Consecutive Offline Limit, tag 9F23, and sets the corresponding Terminal Verification Results bits, which are what force the transaction online. Velocity checking is exactly this subtraction and nothing more.

At the issuer, the counter is the replay control. The honest statement of what it gives you is: an ARQC arriving with a counter value already seen for that card is either a duplicate or a forgery, and an ARQC arriving with a counter far above the last one seen indicates offline activity the issuer has not been told about. Both are signals. Neither is proof. The gap between “counter arrived out of sequence” and “fraud” is filled by the issuer’s own risk rules, not by cryptography.

Issuer Application Data#

Tag 9F10, up to 32 bytes, described by EMV only as “proprietary application data for transmission to the issuer in an online transaction”. EMV does not define its contents. The schemes do, and this is where an issuer host learns how to verify the cryptogram it has just been handed.

The Visa VIS layout, for Cryptogram Version Numbers 10 and 18, is:

A real one, taken from a Visa test transaction, is 9F10 07 06 00 0C 03A01000: length indicator '06', derivation key index '00', Cryptogram Version Number '0C' — decimal 12, one of Visa’s issuer-proprietary versions — and a four-byte Card Verification Results of 03A01000, whose leading '03' is itself a length byte.

The Mastercard M/Chip 4 layout is different in both order and size:

A real one: 9F10 12 02 12 A0000F240000 0000 00000000000000FF.

A Common Core Definitions application always returns exactly 32 bytes, beginning with a length indicator and a Common Core Identifier whose high nibble is the IAD Format Code and whose low nibble is the Cryptogram Version. The remaining layout is given in Book 3’s CCD annex.

Three things in that structure carry the whole weight of interoperability.

The Derivation Key Index tells the issuer host which of its master keys to load. Issuers rotate master keys across BIN ranges and over time; without the index the host would have to try them all.

The Cryptogram Version Number tells the host which algorithm to run — which master key derivation option, whether to derive a session key at all, which elements to concatenate and in what order, and which ARPC method the card expects. It is the single most load-bearing byte in the message.

The Card Verification Results are the card’s own account of what happened. They report whether offline data authentication was performed and how it ended, whether offline PIN verification succeeded, whether the PIN Try Limit was exceeded, whether the offline counters were exceeded, how the previous transaction ended, and whether issuer authentication succeeded last time. The bit layouts are scheme-proprietary and are not published in EMV. Together with the Terminal Verification Results, the Card Verification Results are the two halves of the story: the terminal’s version and the card’s version of the same transaction, arriving in the same message, and sometimes disagreeing in ways that are extremely informative.

Verification at the issuer#

The cryptogram and its companions travel to the issuer inside the ISO 8583 authorisation request, in data element 55, as a TLV list — 9F26 the cryptogram, 9F27 the Cryptogram Information Data, 9F36 the counter, 9F10 the Issuer Application Data, 9F37 the Unpredictable Number, 95 the Terminal Verification Results, 82 the Application Interchange Profile, and the rest. Volume III takes that message apart field by field.

The issuer host does six things, and all the cryptographic ones happen inside a hardware security module:

1. Parse 9F10. Read the Derivation Key Index and the Cryptogram Version Number.
2. Select the issuer master key identified by the index, as a key token the host itself cannot read.
3. Derive MK-AC from the PAN and PAN Sequence Number using the option the Cryptogram Version requires.
4. Derive SK-AC from the Application Transaction Counter, unless the version says not to.
5. Reassemble the message: the same elements, in the same order, with the same lengths, that the card used. The host is reconstructing the terminal’s work from the fields in the authorisation message, and any element it takes from the wrong place — the clearing amount rather than the authorised amount, its own date rather than the terminal’s — produces a mismatch.
6. Compute the MAC and compare with the received 9F26.

If they match, the card is genuine and the transaction data is intact. If they do not, the host has learned only that. Book 2 attaches a recommendation at this point that is easy to skip and important: an ARPC should only be returned if ARQC verification succeeded, and if an issuer insists on returning one anyway, it must not compute it from the ARQC it received from the network.

The ARPC and issuer authentication#

The issuer’s reply carries an Authorisation Response Cryptogram, and Book 2 section 8.2 defines two methods. Both use the same session key SK-AC that verified the ARQC.

Method 1 produces an 8-byte ARPC from the ARQC and the 2-byte Authorisation Response Code, tag 8A, which is the ISO 8583 response code carried as two alphanumeric characters:

X    := ARC || '00' '00' '00' '00' '00' '00'
Y    := ARQC XOR X
ARPC := DES3(SK_AC)[Y]

For our transaction, with an ARC of 3030 — the two ASCII characters 0 and 0, meaning approved:

ARQC = 733084432BA24DAE
X    = 3030000000000000
ARPC = 735C24FD87F1BF0E

The card verifies by deciphering the ARPC under SK-AC and XORing the result with its own ARQC; if what falls out is the ARC followed by six zero bytes, the issuer is authenticated.

Method 2 produces a 4-byte ARPC and carries far more information back to the card. Instead of a response code it uses a 4-byte binary Card Status Update and up to 8 bytes of Proprietary Authentication Data:

Y    := ARQC || CSU || Proprietary Authentication Data
ARPC := MAC(SK_AC)[Y], ISO/IEC 9797-1 Algorithm 3, s = 4

with the Issuer Authentication Data then formed as ARPC || CSU || Proprietary Authentication Data. Whether the proprietary data is included at all is governed by the “Proprietary Authentication Data Included” bit in the Card Status Update itself; if that bit is zero, the field is zero bytes long and, as Book 2 warns explicitly, anything sent in it is not protected by issuer authentication and the card should ignore it.

For our transaction, with a Card Status Update of 00800000:

ARPC = 8F793CCC
Issuer Authentication Data = 8F793CCC 00800000

The Card Status Update is where the issuer reaches into the card, and its coding is published rather than proprietary: section C8 of Book 3’s Common Core Definitions annex sets it out in Table CCD 11, for cryptogram versions '5' and '6'. The second byte carries the instructions: bit 8 “Issuer Approves Online Transaction”, bit 7 “Card Block”, bit 6 “Application Block”, bit 5 “Update PIN Try Counter”, bit 4 “Set Go Online on Next Transaction”, bit 3 “CSU Created by Proxy for the Issuer”, and bits 2 and 1 together the “Update Counters” instruction, which tells the card to leave its offline counters alone, set them to the upper offline limits, reset them to zero, or add this transaction to them. When bit 5 is set, the new PIN try count is taken from bits 4 to 1 of the first byte, whose top bit is the Proprietary Authentication Data Included flag; the third byte is reserved and the fourth is issuer-discretionary, defaulting to zero.

Note what bit 8 of byte 2 means. Under Method 2 the issuer’s approval is inside the MAC. A card that verifies the ARPC and finds that bit clear will return an AAC and decline, no matter what the terminal was told. Under Method 1 the equivalent information is the ARC, also inside the calculation. Either way, the approval decision cannot be flipped in transit — which is precisely the class of attack that unauthenticated response codes leave open.

The Issuer Authentication Data reaches the card as tag 91, 8 to 16 bytes, and there are two routes for it. If the Application Interchange Profile has byte 1 bit 3 set — “issuer authentication is supported” — the terminal sends an EXTERNAL AUTHENTICATE command:

It may be sent only once per transaction; a second attempt returns 6985. Whatever the outcome, the terminal sets byte 1 bit 5 of the Transaction Status Information, “issuer authentication was performed”. If issuer authentication fails, byte 5 bit 7 of the Terminal Verification Results is set, and the card’s CDOL2 will pull that byte into the second GENERATE AC, so the failure is itself covered by the second cryptogram.

If that Application Interchange Profile bit is not set, there is no EXTERNAL AUTHENTICATE. The issuer’s data must instead be named in CDOL2 as tags 91 and 8A, and reaches the card as part of the second GENERATE AC command. Mastercard M/Chip 4 takes the EXTERNAL AUTHENTICATE route; Visa VIS 1.4.x takes the second-GENERATE-AC route. An issuer host that assumes one of these for a portfolio containing both will find that half its script processing silently never executes.

The second GENERATE AC#

Whatever happened online, the transaction is not finished until the terminal asks the card once more, using CDOL2, for a completion cryptogram. The terminal requests a TC if the issuer approved and it is willing to complete, or an AAC if not. The card performs its own second round of risk management, and again may only respond with something equal to or weaker than what was asked. The commonest surprise in this step is a card that returns an AAC after an approved authorisation: almost always the card failed to verify the ARPC, or verified it and found the approval bit clear.

Because the session key is derived from the Application Transaction Counter, and the counter does not increment between the two commands, both cryptograms in a transaction use the same SK-AC. They differ because the data differs — CDOL2 typically adds the Authorisation Response Code and the updated Card Verification Results.

A TC is not a courtesy. It is the evidence the acquirer presents in clearing that the transaction completed as authorised, and it is what an issuer asks for when a disputed transaction is being reconstructed. Schemes have been steadily tightening the requirement that the cryptogram appear in the clearing message and not only in the authorisation.

Combined data authentication#

There is one arrangement in which the cryptogram and the public-key world do meet. Under Combined DDA/Application Cryptogram Generation — CDA — the card does not return the cryptogram in clear. It returns tag 9F4B, Signed Dynamic Application Data, an RSA signature computed over data that includes the cryptogram itself.

For a Common Core Definitions application supporting CDA, the response to GENERATE AC for a TC or an ARQC contains exactly four objects: 9F27 the Cryptogram Information Data, 9F36 the counter, 9F4B the signature, and 9F10 the 32-byte Issuer Application Data. Tag 9F26 is absent — the cryptogram is inside the signature. The leftmost bytes of the signed ICC Dynamic Data are the ICC Dynamic Number and its length, then the Cryptogram Information Data, then the 8-byte TC or ARQC, then a 20-byte Transaction Data Hash Code covering everything exchanged in the transaction. The signed data format byte is '05', the recovered header is '6A', the trailer is 'BC', and the padding pattern is 'BB'. A card that responds with an AAC does not sign; it returns 9F26 in the clear, and the terminal declines.

CDA closes a specific hole: without it, an attacker sitting between card and terminal can let a genuine card generate a genuine ARQC and then alter the plaintext response, or substitute the card’s answer to the second GENERATE AC. With it, altering anything invalidates a signature the terminal can check, because the terminal holds the certificate chain. This is the one place where the terminal’s opinion of the cryptogram counts for something.

Failure modes#

When a cryptogram does not verify, the issuer host learns nothing except that it did not verify. In practice the cause is almost always one of a short list, and it is worth having the list to hand.

Every one of those is a data-assembly error, not a cryptographic one. The mathematics in this chapter has not failed in the field. The byte strings fed to it fail constantly.

The cryptogram in one paragraph#

At personalisation, the issuer derives a card-unique key from its master key and the card’s PAN. At transaction time, the card derives a use-unique session key from that card key and its own transaction counter, and computes an eight-byte Retail MAC over a fixed list of terminal-supplied and card-supplied facts — amount, currency, date, country, the terminal’s random number, the card’s counter and its own results. The type of cryptogram it returns is its verdict: TC to approve, ARQC to ask, AAC to refuse. The terminal cannot check any of it and merely forwards it. The issuer repeats the whole derivation from the PAN, the counter and the Cryptogram Version Number in the Issuer Application Data, and compares. If it approves, it computes a second cryptogram over its own answer so the card can be certain the answer is genuine, and only then will the card act on what the issuer says. Nothing in that chain is a secret the card gives away, which is why recording it is worthless, and why the eight bytes at the centre of it are the strongest single thing on the card.

15.98 Common wrong ideas#

Wrong: The chip signs the transaction. Right: It computes a message authentication code with a symmetric key the issuer also holds, so anybody who can verify a cryptogram can also forge one, which is why that key must never leave tamper-resistant hardware at either end.

Wrong: The terminal checks the cryptogram before forwarding it. Right: The terminal has no key and never will, so when eight bytes come back from GENERATE AC it has no idea whether they are correct, random or fabricated, and it merely copies them into the authorisation message.

Wrong: A valid cryptogram proves the cardholder was present and entered a PIN. Right: It proves that a chip holding the correct key participated in a transaction with those exact parameters and nothing else; cardholder verification is reported separately, and an attacker who suppresses the PIN check can still obtain a perfectly valid cryptogram.

Wrong: There is a fixed list of data the card computes the cryptogram over. Right: Book 2 offers a recommended minimum set of ten elements, and what is actually included and in what order is fixed by the scheme-proprietary Cryptogram Version Number, which is by a wide margin the commonest cause of unexplained verification failures.

Wrong: The transaction counter makes replay impossible. Right: It makes replay detectable, and only if the issuer checks; hosts apply windows rather than hard ceilings because authorisations arrive out of order and offline transactions consume counter values that never reach the host at all.

Wrong: A cryptogram that fails to verify indicates a cryptographic problem. Right: In practice every failure is a data-assembly error — the wrong master key, an unhandled cryptogram version, an omitted cashback amount, a currency converted to major units, or Data Object List padding applied the wrong way round.

Wrong: A decline is just a decline, so it needs no cryptogram. Right: The refusal is sealed too, precisely so that nobody downstream can quietly turn a refusal into an approval.

Wrong: A terminal that requests an offline approval and receives one has been obeyed. Right: The terminal proposes and the card disposes, returning the requested type or a more restrictive one and never a less restrictive one, so a request to approve offline may come back as an online request or an outright refusal.

Wrong: One session key derivation rule covers an issuer’s whole portfolio. Right: Visa Cryptogram Version 10 derives no session key at all and uses the card master key directly, Visa 18 and 22 and Mastercard 14 and 15 use the common session key method, and Mastercard 12 and 13 fold the terminal’s unpredictable number into the derivation as well.

Wrong: Once the issuer approves, the transaction is finished. Right: The terminal must ask the card once more using the second data object list, and a card that failed to verify the response cryptogram, or verified it and found the approval bit clear in the Card Status Update, will refuse after an approved authorisation.

15.99 Chapter summary in 20 lines#

1. Everything else on a card is data and all data can be copied, but the Application Cryptogram cannot, because it does not exist until the moment of the transaction and is never the same twice.
2. It is eight bytes long and it is a message authentication code computed with a key the card and the issuer share, not a signature anybody can verify.
3. Because the key is symmetric, the terminal cannot check the cryptogram at all and simply forwards eight bytes whose correctness it has no way of assessing.
4. The security of the whole scheme therefore rests on that key never leaving tamper-resistant hardware, since a single master key extracted from a badly managed host compromises every card in its range forever.
5. Three keys stand in a hierarchy: an issuer master key, a card-unique key derived from it with the account number and sequence number, and a session key derived from that with the card’s own transaction counter.
6. Book 2 gives three master key derivation options and mandates none of them, and which one a card uses is announced by the scheme’s Cryptogram Version Number rather than by EMV.
7. The session key changes with every transaction because the counter does, so compromising one transaction’s key compromises exactly one transaction.
8. The data covered by the MAC is a fixed concatenation of eight facts supplied by the terminal, two supplied by the card, and in every real implementation the card’s own Card Verification Results as well.
9. The terminal does not choose those elements: the card publishes two Card Risk Management Data Object Lists and the terminal fills them in the order given, under padding rules that run one way for numeric formats and the other for everything else.
10. The computation is CBC chaining under the left half of the session key followed by an encrypt-decrypt-encrypt on the final block, the construction the banking world calls the Retail MAC, with an AES option for newer cryptogram versions.
11. The type of cryptogram returned is the card’s verdict: a Transaction Certificate approves offline, an Authorisation Request Cryptogram asks the issuer, and an Application Authentication Cryptogram refuses.
12. The terminal requests a type and the card may return that type or a more restrictive one, never a less restrictive one.
13. The transaction counter does three jobs at once: it diversifies the session key, it sits inside the signed data, and it is visible to terminal risk management as the gap from the Last Online ATC Register.
14. What the counter honestly gives an issuer is a signal and not a proof, since a repeated value means duplicate or forgery and a large jump means unreported offline activity, and the distance from signal to fraud is covered by risk rules.
15. The Issuer Application Data is where the host learns how to verify what it has been handed, carrying the Derivation Key Index, the Cryptogram Version Number and the Card Verification Results in scheme-specific layouts.
16. The Cryptogram Version Number is the single most load-bearing byte in the message, because it decides the derivation option, whether a session key exists, which elements are concatenated and which response method the card expects.
17. The issuer parses that field, loads the master key by index, derives the card key and session key, reassembles the terminal’s byte string from the authorisation message and compares — and a mismatch tells it nothing except that there was a mismatch.
18. The issuer replies with its own cryptogram under one of two methods, so that its approval sits inside a MAC and cannot be flipped in transit, which is exactly the attack that unauthenticated response codes leave open.
19. Under combined data authentication the cryptogram is not returned in the clear at all but inside an RSA signature the terminal can check, the one place where the terminal’s opinion of the cryptogram counts for anything.
20. When a cryptogram fails, the cause is almost always a data-assembly error rather than a cryptographic one, because the mathematics in this chapter has not failed in the field and the byte strings fed to it fail constantly.

Sources: EMV Integrated Circuit Card Specifications for Payment Systems, Book 2 (Security and Key Management) v4.3, sections 8.1–8.3 and Annexes A1.2, A1.3, A1.4 and the Common Core Definitions part; EMV Book 3 (Application Specification) v4.3, sections 5.4, 6.5.5 and 6.5.7 and the Data Elements Dictionary; ISO/IEC 9797-1 and ISO/IEC 7816-4; EMVCo tag references at emvlab.org; AWS Payment Cryptography and IBM z/OS ICSF documentation for scheme cryptogram version behaviour; CardContact OpenSCDP EMV traces. Worked figures were computed from the Book 2 algorithms using the stated test key and are reproducible.