The Chip Is a Computer

14.0 What this chapter gives you#

1. You will be able to state precisely what separates a chip from a magnetic stripe: a stripe is a recording and a chip is a correspondent, so a stripe reader takes and a chip reader asks.
2. You will be able to read a terminal log and name each exchange in it, from application selection through GET PROCESSING OPTIONS and READ RECORD to GENERATE APPLICATION CRYPTOGRAM.
3. You will be able to decode a command by hand from its class, instruction and parameter bytes, and explain why the trailing 00 on almost every EMV command means “send me everything you have” rather than padding or a null argument.
4. You will be able to decode an Application File Locator four bytes at a time, recover the short file identifier from the top five bits, and build the matching READ RECORD parameter byte from it.
5. You will be able to explain why records with short file identifiers 1 to 10 have their template tag and length stripped before they feed the authentication hash while records from 11 to 30 go in whole, and why that defect reaches production so often.
6. You will be able to say what static, dynamic and combined data authentication each prove and each fail to prove — that the data was signed, that the card is present, and that the card, the decision and the transaction are one indivisible statement.
7. You will be able to fill in a Processing Options Data Object List correctly, applying padding and truncation rules that run one way for numeric formats and the other way for everything else.
8. You will be able to look at a GENERATE AC exchange in which the terminal asked for an offline approval and the card returned an online request, and explain why the card may always answer weaker than it was asked but never stronger.
9. You will be able to explain why reading a chip is not an attack, and why any reader obtaining the account number, expiry, name and usage rules from any card is working exactly as designed.
10. You will be able to say why “the chip killed cloning” is true of one attack and one only, and where the fraud went instead.

Hold a card with the contact plate facing you and you are looking at eight gold pads, five of which do anything. Behind them, embedded in a cavity milled into the plastic, is a die perhaps a couple of millimetres square containing a processor, some read-only memory holding a program, some non-volatile memory holding data and keys, and — on any card issued this century — hardware dedicated to arithmetic on numbers hundreds of digits long.

This is the fact most explanations of card payments skip. The magnetic stripe is a recording. The chip is a correspondent. A stripe reader takes; a chip reader asks. Everything that follows in this volume — the cryptogram, the decision to go online, the cardholder verification list, the contactless tap — follows from that one structural difference. It is also why counterfeit card fraud collapsed, and not because the chip is hard to read: reading a chip is trivial, and any developer with a fifteen-pound reader can pull a card number and expiry date off one in under a second. The chip works because there is a category of question it answers differently every time, and a category of secret it will never disclose however the question is phrased.

This chapter takes that conversation apart, command by command. By the end you should be able to read a terminal log, name each exchange, decode an Application File Locator by hand, and say precisely what static, dynamic and combined data authentication each prove and each fail to prove.

The plain version#

Imagine two ways of proving who you are at a door.

The first way: you hand over a photocopy of your passport. The doorman reads it, sees your name and your photograph, and lets you in. It works. It is also completely useless the moment somebody else gets hold of a photocopier, because a copy of a copy is indistinguishable from the original. That is the magnetic stripe. Everything on it is written down. Anyone who can read it can write it out again, and the new one works exactly as well as the old one.

The second way: there is no photocopy. There is a small clerk in a locked room behind a letterbox. You cannot see him and you cannot go in. You slide questions through on slips of paper and he slides answers back. He is helpful — he will tell you the account number, the expiry date, the name — but he will not, under any circumstances, tell you the secret he uses to sign his answers. And crucially, some of the questions you may ask are ones where the answer depends on the question. If you ask “what is 8,391 plus your secret?” and he replies with a number, that number is worthless to anybody who asks him something different tomorrow.

That is the chip.

The conversation, one line at a time#

Here is a real coffee. Four pounds twenty, a Tuesday morning, a card inserted into a countertop terminal. What follows is not a metaphor; it is the actual sequence, with the technical names given in brackets so that you can find them again in the second half of the chapter.

“What can you do?” The terminal has no idea what is in front of it. It might be a Visa debit card, a Mastercard credit card, a German girocard, or a transport card that is not a payment card at all. So it asks the chip for its directory of programs. The chip replies with a short list — say two entries, “Visa Credit” and “Visa Debit”, each with a priority number — and the terminal picks the highest-priority one it also supports. (Application selection, using the payment system directory.)

“Right. I want to talk to Visa Debit.” The terminal opens that program. The chip replies with a greeting that includes something surprising: a shopping list. It says, in effect, “before I will start a transaction, tell me nine things, in this exact order and at these exact sizes.” (SELECT of the application; the card returns a Processing Options Data Object List.)

“Here is your list.” The terminal fills it in: the amount is 000000000420, the country is 0826, the currency is 0826, today’s date, the type of transaction, a five-byte block of its own findings so far, and — this one matters — a fresh four-byte random number it has just generated and has never used before. (GET PROCESSING OPTIONS.)

The chip now knows a transaction has begun. It replies with two things: a two-byte summary of what it is capable of, and a map listing which of its internal files the terminal should read, which records in each, and how many of those records form the material to be authenticated. (Application Interchange Profile and Application File Locator.)

“Show me those files.” Out come the card number, the expiry date, the cardholder name, the country of issue, rules about what the card may be used for, and a bundle of certificates. (READ RECORD.)

“Prove you are not a photocopy.” The terminal has a card scheme’s public key burned into it. The certificates chain back to that key: the scheme signed a certificate for the issuing bank, and the bank signed one for this chip. The terminal walks the chain, then throws the chip a challenge — a number it has just invented — and asks it to sign. Only this chip can produce the right signature, because only this chip holds the matching private key, and that key has never left the silicon.

“Here is the transaction. What is your verdict?” The terminal hands over the amount, the currency, the date, its own risk findings and another unpredictable number. The chip runs its own checks — how many transactions it has approved offline since it last spoke to its bank, whether the amount exceeds its limit — and produces a cryptogram computed from the transaction with a secret key it shares with the issuing bank. It also says what that cryptogram means: approved offline, declined offline, or ask the bank. (GENERATE APPLICATION CRYPTOGRAM.)

For a four-pound-twenty coffee most cards say “ask the bank”, and the cryptogram goes off into the network. That journey is Volume III; what the cryptogram is and what key computes it is chapter 15.

The one thing the clerk will never do#

Every command listed above is a question. There is no command in the whole specification that says “give me your private key”, and none that says “give me the secret you share with your bank”. The chip will sign things with those keys all day long. It will not disclose them.

That is not a policy, and not a setting an issuer can get wrong. No instruction in the instruction set would cause the chip to output them, and the program sits in read-only memory laid down at manufacture. To get the keys you would have to attack the silicon: decapsulate the die and either probe it or infer the key from variations in the power it draws while computing. Those attacks exist, and they are why chips are certified before a scheme will let them be issued. But they cost money, take equipment and destroy the card. Photocopiers do not.

Why the counter matters#

One more detail worth carrying to dinner. The chip holds a counter that goes up by one every time a transaction starts and never goes down. It is two bytes wide, so it counts to 65,535, and every cryptogram includes the current value.

This is the quiet killer of replay. Suppose somebody records a complete, valid conversation — every question, every answer, cryptogram included — and plays it back tomorrow. The recorded cryptogram carries counter value 137, but the real card has been used eleven more times since, so the bank has seen 148. A counter that repeats or goes backwards is a card being replayed, and the issuer can see it in the message. The bank does not have to guess whether the transaction is genuine. It can check.

Where the plain version stops being true#

The chip is not a computer in the sense you are picturing#

It has no clock, no battery and no power of its own. It is parasitic on the terminal, which supplies voltage on one contact and a clock on another; the chip computes only while both are present. Pull the card out mid-transaction and it does not “notice” — it simply stops existing until somebody powers it again. It has no idea whether the last transaction was four seconds ago or four years ago, it must ask the terminal for the date, and it cannot tell whether the terminal is lying.

Nor can the chip start anything. It has no way to say “excuse me” through the letterbox. It receives a command, computes, returns a response, and waits. This is why “the card decides whether to approve the transaction” is a useful but misleading simplification: the terminal decides what question to ask, and the card can only choose among the answers to that question — and, as we will see, it may return an answer weaker than the one requested but never a stronger one.

Offline authentication proves the card is genuine, not that the terminal is#

The certificate chain runs one way. The chip proves itself to the terminal; nothing in the ordinary transaction flow requires the terminal to prove anything to the chip, and there is no practical way it could, because a terminal is a commodity device in a shop and the chip cannot check a revocation list or even know today’s date.

The consequence surprises people: reading a chip is not an attack. Any reader may power any card, run selection, GET PROCESSING OPTIONS and READ RECORD, and obtain the primary account number, the expiry date, the cardholder name and the card’s usage rules. Contactless cards will do this over the air. That is by design — those are the fields a merchant needs. The security does not come from hiding them. It comes from the fact that having them does not let you produce a cryptogram.

“The chip killed cloning” is true of one attack and one only#

It killed the counterfeiting of magnetic stripes for use at chip-reading terminals. It did nothing about card-not-present fraud, and the fraud did not stop; it moved. UK Finance’s twenty-year retrospective, published on 14 February 2026, records a 95 per cent reduction in losses to counterfeit card fraud over the two decades since Chip and PIN replaced signature — and in the same breath records £215 million lost to remote purchase fraud in the first half of 2025 alone.

There is a second qualification. For years a great many cards described as “chip cards” performed only static data authentication, which is a photocopy again — a photocopy with a genuine signature on it. The signature verifies; it is simply not fresh, because the signed material is identical on every transaction, and a device that has recorded it once can present it again. Whether a given card does this is an issuer decision, and the later sections explain exactly what the difference costs.

There is not one conversation; there are several specifications#

The dialogue above is the contact interface, governed by the four EMV books. Contactless runs a related but distinct process, with its own entry-point specification and a family of kernel specifications, one per scheme, each with its own command sequence, data elements and decision logic. A Visa tap and a Mastercard tap do not execute the same steps. Treating “EMV” as a single protocol is the commonest error in engineering documentation about cards.

The technical version#

What EMV actually is, and what it sits on#

EMV is not a standard in its own right. It is a profile of the ISO/IEC 7816 series for integrated circuit cards. The current release, version 4.4, dated October 2022, comprises four books:

Book 3 section 1.3 states the relationship precisely: “This specification is based on the ISO/IEC 7816 series of standards and should be read in conjunction with those standards. However, if any of the provisions or definitions in this specification differ from those standards, the provisions herein shall take precedence.” Version 4.4 also incorporates two consequential Specification Bulletins: no. 175, on Application Selection Registered Proprietary Data, and no. 243, which introduced Extended Data Authentication and Offline Data Encipherment. The Level 1 electrical and transport requirements now live in a separate document, the EMV Contact Interface Specification, cited by Book 3 as a normative reference.

Chapter 11 covered the physical layer: the ISO/IEC 7816-2 contact assignment, the 5 V supply, the 1 to 5 MHz clock, the answer to reset, and the protocols T=0 and T=1. This chapter starts one layer up.

The APDU: the shape of every question and every answer#

Book 3 Figure 1 gives the command APDU as a mandatory four-byte header followed by a conditional body:

CLA  INS  P1  P2  [Lc]  [Data]  [Le]

and Figure 2 gives the response as a conditional body followed by a mandatory two-byte trailer:

[Data]  SW1  SW2

Lc is the number of bytes in the command data field; Le is the maximum expected back. Book 3 is unambiguous about one convention that trips up newcomers: “When Le is present and contains the value zero, the maximum number of available data bytes (up to 256) is expected. When required in a command message, Le shall always be set to ‘00’.” The trailing 00 on almost every EMV command is therefore neither padding nor a null argument. It means “send me everything you have”.

ISO/IEC 7816-4 defines four cases by whether data flows in each direction — case 1 neither, case 2 response only, case 3 command only, case 4 both — and EMV inherits them. Under T=0 they do not map cleanly onto single exchanges, which is why logs contain apparent duplicates: a card may answer 61 xx, meaning “executed, xx bytes waiting, fetch them with GET RESPONSE”, or 6C xx, meaning “your Le was wrong, the correct value is xx”. Book 1 Annex A works through all four cases and both procedure bytes. A library that ignores 6C xx passes every test in the lab and fails intermittently in the field.

Book 3 Table 2 assigns the most significant nibble of the class byte: '0' is an inter-industry command defined by ISO/IEC 7816, '8' is a command proprietary to EMV, and any other value is out of scope. The least significant nibble carries secure messaging and logical channel indications, again per 7816-4. So 00 A4 is ISO’s SELECT used as EMV requires; 80 A8 is an EMV-only command no general-purpose smart card would recognise.

Book 3 Table 3 gives the complete instruction set for financial transaction:

That is the entire vocabulary: thirteen commands, of which a normal purchase uses five or six. The status bytes are the other half of the protocol. Those worth memorising:

6A82 is not an error in the ordinary sense: it is how a card says “I do not have that application”, and it is the expected response during selection.

The Application Identifier#

An application is addressed by name, and the name is an Application Identifier. Its structure comes from ISO/IEC 7816-5: a Registered Application Provider Identifier of exactly five bytes, allocated by a registration authority, optionally followed by a Proprietary Application Identifier Extension of up to eleven bytes chosen freely by the provider. The AID is therefore 5 to 16 bytes long. On the card it is tag 4F, or the Dedicated File name, tag 84; in the terminal’s configuration it is tag 9F06.

The RID identifies the scheme; everything after it is the scheme’s own business — product, region, common debit variant. A working set:

Note the leading conventions — A0 for internationally registered providers, D2 for nationally registered ones — and note that the lengths differ. A terminal that assumes seven bytes fails on UnionPay and girocard, and that is a real and recurring defect.

Application selection#

Selection begins with a directory. On contact the entry point is the Payment System Environment, a Directory Definition File named with the fourteen ASCII characters 1PAY.SYS.DDF01 — on the wire:

31 50 41 59 2E 53 59 53 2E 44 44 46 30 31

On contactless it is the Proximity Payment System Environment, 2PAY.SYS.DDF01, differing by one byte:

32 50 41 59 2E 53 59 53 2E 44 44 46 30 31

The terminal selects it by name per Book 1 Table 40: P1, the reference control parameter (Table 41), is '04' for selection by DF name, and P2, the selection options parameter (Table 42), is '00' for the first or only occurrence — '02' requests the next occurrence, which is how a terminal enumerates multiple applications sharing a partial AID.

A real trace, from a published analysis of a Visa contactless transaction:

C: 00 A4 04 00 0E 325041592E5359532E4444463031 00
R: 6F 37
     84 0E 325041592E5359532E4444463031
     A5 25
       BF0C 22
         61 20
           4F 07 A0000000031010
           50 0B 5669736120437265646974
           87 01 01
           BF63 04 DF20 01 80
   9000

Read that structure carefully; it recurs everywhere. 6F is the File Control Information template; 84 the Dedicated File name, echoing what was selected; A5 the FCI Proprietary Template; BF0C the FCI Issuer Discretionary Data, where Book 3 section 5.1 requires any additional data element in a SELECT response to sit. 61 is a Directory Entry, holding 4F the ADF name, 50 the Application Label (5669736120437265646974 is ASCII “Visa Credit”) and 87 the Application Priority Indicator.

On the contact interface the PSE works slightly differently: the FCI Proprietary Template contains tag 88, the short file identifier of the directory elementary file, and the terminal issues READ RECORD against that SFI to walk the directory. Book 1 Table 46 gives the Payment System Directory Record Format and Table 47 the ADF Directory Entry Format.

If the PSE is absent the card returns 6A82 and the terminal falls back to trying each AID in its own list, one SELECT at a time, per Book 1 section 12.3.3. Against each it holds an Application Selection Indicator saying whether the card’s AID must match exactly, including length, or only up to the length of the terminal’s — which is how a terminal holding the seven-byte Visa AID matches a card personalised with a longer, product-specific one. Book 1 section 12.4 governs final selection from the candidate list using the Application Priority Indicator, with cardholder confirmation where required.

Selecting the application itself returns a richer FCI:

C: 00 A4 04 00 07 A0000000031010 00
R: 6F 46
     84 07 A0000000031010
     A5 3B
       50 0B 5669736120437265646974
       87 01 01
       9F38 18 9F6604 9F0206 9F0306 9F1A02 9505
               5F2A02 9A03 9C01 9F3704
       5F2D 02 656E
       BF0C 08 9F5A 05 ...
   9000

5F2D is the Language Preference, 656E being ASCII “en”, 9F5A the Application Program Identifier, and 9F38 the Processing Options Data Object List — the shopping list from the plain version, made concrete.

Data Object Lists: the card programs the terminal#

A DOL is a concatenation of two-part entries, each a one- or two-byte tag followed by a one-byte length. It is not TLV data; it is a template telling the terminal what to concatenate, in what order, at what size. Book 3 section 5.4 explains why: to minimise processing in the card the constructed field carries no tags, so the card must know the layout in advance.

The PDOL above decodes to:

Thirty-three bytes. Book 3 section 5.4 also gives the rules every implementation gets wrong at least once:

If a tag in the DOL is unknown or names a constructed object, the terminal supplies that many hexadecimal zero bytes; likewise if the object is known but absent or inapplicable. If the DOL length is shorter than the actual data, the terminal truncates the leftmost bytes for numeric (n) format and the rightmost for everything else. If longer, it pads with leading zeroes for numeric, trailing 'FF's for compressed numeric, trailing zeroes otherwise. Numeric goes one way and everything else the other; reversing that produces a cryptogram that fails at the issuer with no useful diagnostic.

The same mechanism appears three more times: CDOL1 (tag 8C) and CDOL2 (tag 8D) for GENERATE AC, the Transaction Certificate Data Object List for TC hashing, and the Dynamic Data Authentication Data Object List (tag 9F49) for INTERNAL AUTHENTICATE.

GET PROCESSING OPTIONS#

Book 3 section 6.5.8, Table 18:

The PDOL data is wrapped in a command template with tag '83'; if the card published no PDOL, the terminal sends the empty template 83 00. For a £4.20 purchase in the United Kingdom on 17 August 2026, filling in the PDOL above:

80 A8 00 00 23
   83 21
      36C04000        Terminal Transaction Qualifiers
      000000000420    Amount, Authorised          (£4.20)
      000000000000    Amount, Other
      0826            Terminal Country Code       (GB)
      0000000000      Terminal Verification Results
      0826            Transaction Currency Code   (GBP)
      260817          Transaction Date            (YYMMDD)
      00              Transaction Type            (purchase)
      7A19C4B2        Unpredictable Number
   00

Lc is '23', thirty-five bytes: two for the tag and length of the '83' template plus thirty-three of data. The amount is numeric format, two digits to the byte, right-justified with leading zeroes — 420 minor units, not 4.20. Chapter 9 explained why no floating point number ever touches this field.

The response comes back in one of two formats. Format 1 is a primitive object with tag '80' whose value is the Application Interchange Profile followed immediately by the Application File Locator, with no internal tags — you must know the first two bytes are the AIP and the rest the AFL. Format 2 is a constructed object with tag '77' containing ordinary TLV, AIP as '82' and AFL as '94'. Both are legal and both are deployed. From the same real trace:

R: 77 52
     82 02 0000                    Application Interchange Profile
     94 04 10040400                Application File Locator
     57 13 ...                     Track 2 Equivalent Data (PAN masked in source)
     5F20 02 202F                  Cardholder Name
     5F34 01 00                    PAN Sequence Number
     9F10 07 06010A03A00000        Issuer Application Data
     9F26 08 1EB2BF209002EFD3      Application Cryptogram
     9F27 01 80                    Cryptogram Information Data (ARQC)
     9F36 02 0089                  Application Transaction Counter (137)
     9F6C 02 0280                  Card Transaction Qualifiers
     9F6E 04 20700000              Form Factor Indicator
   9000

That is a Visa contactless card, and it makes the earlier point concrete: this is not the contact flow. The card returned the cryptogram inside the GET PROCESSING OPTIONS response, before any GENERATE AC exists, because Visa’s contactless kernel compresses the exchange to keep the tap under a few hundred milliseconds. Note too that the AIP is '0000'; the cardholder-verification signalling here rides in the Card Transaction Qualifiers, tag 9F6C — precisely the field the published PIN-bypass attack against this kernel manipulates.

The Application Interchange Profile#

Tag 82, two bytes. Byte 1:

Byte 2 carries, among reserved bits, b8 for EMV mode and b1 for Relay Resistance Protocol support. Book 3 Annex C1, Table 41, is normative.

The Application File Locator#

Tag 94, always a multiple of four bytes, read four at a time:

The AFL in the trace is 10 04 04 00: one group. Byte 1 is 0x10, 00010000 in binary; shift right three and you get 00010, SFI 2. Records 4 to 4, so a single record. Zero records feed offline data authentication.

READ RECORD#

Book 1 section 11.2 and Book 3 section 6.5.11. The command is 00 B2, with P1 the record number and P2 the reference control parameter, in which the five most significant bits are the SFI and the three least significant are 100 — that is, P2 = (SFI << 3) | 4. For SFI 2, record 4:

C: 00 B2 04 14 00
R: 70 1A
     5A 08 ...                PAN (masked in source)
     5F28 02 ...              Issuer Country Code
     5F24 03 220731           Application Expiration Date
     9F07 02 C280             Application Usage Control
   9000

0x14 is 00010100: SFI 2, control bits 100. The response is always wrapped in the READ RECORD Response Message Template, tag 70. Short file identifiers are allocated by Book 3 Table 1:

That boundary is not cosmetic; it is the most commonly mis-implemented rule in offline data authentication. Files with SFI 1 to 10 hold only data the card does not itself interpret, and when their records feed the authentication hash, the tag 70 and its length byte are stripped and only the value is used. For SFI 11 to 30 the entire record goes in, tag and length included. Get that wrong and every card with issuer-specific files fails offline authentication while every card inside the standard range passes — a defect that reaches production regularly, because test cards tend to use low SFIs.

Note also that a card may answer READ RECORD with 6C xx if the terminal’s Le was wrong, and the terminal must reissue with Le = xx.

The rest of the vocabulary#

GET DATA (80 CA, P1 P2 carrying the tag of the wanted object, Book 3 section 6.5.7) retrieves single primitive objects living outside the file structure. Book 3 Table 32 lists them: the Application Transaction Counter (9F36), Last Online ATC Register (9F13), PIN Try Counter (9F17) and Log Format (9F4F).

GET CHALLENGE (00 84 00 00 00) asks the card for an eight-byte unpredictable number of its own, used when the card’s CDOL demands an ICC Dynamic Number.

VERIFY (00 20 00 P2) submits an offline PIN. Book 3 Table 24 codes P2 as the qualifier of reference data: '80' plaintext, '88' enciphered, with Table 25 giving the plaintext block format. Failure returns 63 Cx, x being the tries left; at zero the application blocks. Chapter 17 covers cardholder verification in full.

INTERNAL AUTHENTICATE (00 88 00 00 Lc Data 00) submits authentication-related data — in practice the terminal’s unpredictable number, laid out according to the DDOL — and returns the card’s signature over it.

GENERATE APPLICATION CRYPTOGRAM (80 AE P1 00 Lc Data 00) is the decision command. P1, the reference control parameter, is coded by Book 3 Table 12:

with b5 set to request a CDA signature and the rest RFU. So P1 = '00' asks the card to decline, '40' to approve offline, '80' to go online, and '90' to go online with a combined signature.

The response comes in the same two flavours as GET PROCESSING OPTIONS. Format 1, tag '80', is Cryptogram Information Data, Application Transaction Counter, Application Cryptogram and optionally Issuer Application Data, concatenated without tags. Format 2, tag '77', is TLV, with 9F27, 9F36 and 9F26 mandatory and 9F10 optional. The Cryptogram Information Data is coded by Book 3 Table 15:

with b6 and b5 for payment system-specific cryptograms, b4 indicating whether an advice message is required, and b3 to b1 a reason code: 000 no information given, 001 service not allowed, 010 PIN Try Limit exceeded, 011 issuer authentication failed.

A complete GENERATE AC exchange from a published contact-interface trace, the card’s CDOL1 being 9F0206 9F0306 9505 5F2A02 9A03 9C01 9F3704 9F4C08 9F4502:

C: 00 84 00 00 00
R: 8D51F46C9F405F71 9000            GET CHALLENGE returns ICC Dynamic Number

C: 80 AE 40 00 25
     000000000001          Amount, Authorised
     000000000000          Amount, Other
     0000000000            Terminal Verification Results
     0978                  Transaction Currency Code (EUR)
     090730                Transaction Date
     21                    Transaction Type
     2C764F65              Unpredictable Number
     8D51F46C9F405F71      ICC Dynamic Number
     D179                  Data Authentication Code
   00
R: 77 1E
     9F27 01 80                    ARQC
     9F36 02 0213                  ATC = 531
     9F26 08 2DF3833C61855BEA      Application Cryptogram
     9F10 07 06842300310208        Issuer Application Data
   9000

Read the two decisive values together. The terminal set P1 = '40', asking for a Transaction Certificate — offline approval. The card returned Cryptogram Information Data '80', an ARQC. The card overrode the terminal and forced the transaction online. That is card action analysis in one exchange: the terminal proposes, the card disposes, and the card may always return something weaker than requested but never something stronger.

Finally, APPLICATION BLOCK, APPLICATION UNBLOCK, CARD BLOCK and PIN CHANGE/UNBLOCK are the issuer script commands. The terminal never issues them on its own initiative; they arrive from the issuer inside the authorisation response and the terminal relays them. This is how a bank resets a PIN try counter on a card sitting in a wallet three thousand miles away.

Offline data authentication#

Everything above establishes what the card says. Offline data authentication establishes whether to believe it, without going online.

The certificate chain#

The terminal is loaded with the scheme’s Certification Authority public keys, one or more per RID, each identified by a Certification Authority Public Key Index which the card supplies in tag 8F. The terminal takes the first five bytes of the AID as the RID and, with the RID and the index, looks up the right CA public key in its own table.

The card carries an Issuer Public Key Certificate (tag 90), an Issuer Public Key Remainder (tag 92) where the key is too long to fit inside it, and an Issuer Public Key Exponent (tag 9F32). The certificate is recovered with the CA public key using the message-recovery signature scheme of ISO/IEC 9796-2, and out comes a structure beginning '6A' and ending 'BC':

The terminal checks the header, format byte and trailer, recomputes and compares the hash over the recovered fields concatenated with the remainder and the exponent, checks the issuer identifier against the leading PAN digits, and checks the expiry. Only then does it hold a trusted issuer public key.

The key sizes are bounded. EMV Book 2 states that terminals “shall support keys up to 1984 bits (248 bytes) in length”, and its Annex D1 sets the hierarchy: the Issuer Public Key length may be equal to or less than the CA Public Key length up to that 248-byte maximum, and the ICC Public Key and ICC PIN Encipherment Public Key lengths may be equal to or less than the Issuer Public Key length. Keys shrink as you go down the chain; they never grow.

Static Data Authentication#

SDA uses the issuer key only. The card carries Signed Static Application Data in tag 93, produced at personalisation by signing a hash of the card’s static data with the issuer’s private key. Recovery with the issuer public key yields:

The authentication input is the concatenation of the records the AFL marked for authentication, assembled with the SFI rule described earlier, followed — where a Static Data Authentication Tag List (tag 9F4A) is present — by the values of the objects it names. On success the terminal extracts the two-byte Data Authentication Code and stores it as tag 9F45, which is why 9F45 appears in CDOL1: the card wants proof that the terminal really performed SDA.

What SDA proves: this card’s static data was signed by an issuer whose certificate chains to the scheme. What it does not prove: that the card in the slot is the card the data came from. Every byte involved is fixed at personalisation; record it once and you can present it again on any device that speaks the protocol. SDA defeats a forger who alters the data. It does not defeat one who copies it wholesale.

Dynamic Data Authentication#

DDA adds a key pair belonging to the individual chip. The card carries an ICC Public Key Certificate (tag 9F46) signed by the issuer, plus the ICC Public Key Exponent (9F47) and Remainder (9F48). The recovered certificate has Certificate Format '04' and carries the full Application PAN in ten bytes, right-padded with 'F', rather than the issuer identifier of the '02' format.

Having verified the ICC public key, the terminal issues INTERNAL AUTHENTICATE carrying an unpredictable number of its own choosing. The card signs with its private key and returns Signed Dynamic Application Data, tag 9F4B, which recovers to:

The hash covers, among other things, the terminal’s unpredictable number. That is the whole improvement: the signature is fresh, so a recording is useless, and producing it requires a private key that has never been transmitted. This is the point at which cloning stops being an economic proposition.

What standalone DDA does not do is bind the signature to the transaction. The card proves it is genuine; separately, it produces a cryptogram over the amount. A device sitting between card and terminal can let the authentication succeed and still interfere with the decision, because the two are not cryptographically joined.

Combined DDA/Application Cryptogram Generation#

CDA joins them. Instead of a separate INTERNAL AUTHENTICATE, the terminal sets bit b5 of the GENERATE AC reference control parameter and the card returns the Signed Dynamic Application Data (9F4B) in the GENERATE AC response, alongside 9F27, 9F36 and 9F10. The ICC Dynamic Data inside that signature includes the Application Cryptogram itself and a hash over the transaction data, so one signature covers the card’s identity, its decision and the transaction it applies to. Substituting any of the three invalidates all of them.

The terminal records the outcome in the Terminal Verification Results, tag 95, five bytes, whose first byte is:

Those bits are then matched against the Issuer Action Codes and Terminal Action Codes to decide whether to approve, decline or go online. That is chapter 16.

Extended Data Authentication#

Version 4.4 adds a fourth option. Specification Bulletin no. 243 introduced Extended Data Authentication and Offline Data Encipherment, built on elliptic curve cryptography rather than RSA: Book 3’s abbreviation list now carries XDA, ECC and EC-SDSA for the Elliptic Curve Schnorr Digital Signature Algorithm, and Table 31 gives the data required for XDA alongside Table 29 for SDA and Table 30 for DDA and CDA.

The motive is arithmetic, not fashion. EMVCo’s explanation is that in 2010 NIST announced it would not support EMV’s longest RSA key length, 1984 bits, after 2030; longer keys mean longer computation, and a tap has a hard time budget. ECC reaches comparable strength at a fraction of the size. RSA key lengths remain under annual review.

Why the chip killed stripe cloning#

Put the two technologies side by side and the asymmetry is total.

A magnetic stripe is a fixed pattern of magnetised particles encoding a fixed string of characters. The information required to make a working duplicate is exactly the information required to use the original, which is a way of saying the stripe has no secret at all. A skimmer read the tracks and a fifty-pound encoder wrote them to a blank. The counterfeit was not a good imitation of the card; it was the card, in every sense the acquiring system could test.

A chip has a secret and never says it. No command in Book 3 Table 3 outputs a private key or a shared symmetric key. The most complete possible read — every SELECT, every READ RECORD against every record named in every AFL, every GET DATA — yields the PAN, the expiry, the name, the certificates and the counters. It yields a card that can answer questions about itself. It does not yield one that can sign a fresh unpredictable number under DDA, nor one that can compute an Application Cryptogram over a new amount, because both need key material no command will disclose.

Three further locks sit in the same door. The Application Transaction Counter makes replay visible to the issuer, because values that repeat or go backwards are detectable in the authorisation message. The unpredictable number makes replay useless to the terminal, because the challenge changes every time. And, as chapter 13 set out, the chip’s Track 2 Equivalent Data (tag 57) is conventionally personalised with a different card verification value from the physical stripe’s, so lifting that record onto a blank produces a stripe that fails verification at the issuer.

The result is in the fraud statistics. UK counterfeit card fraud losses were £129.7 million in 2004, up 17 per cent on £110.6 million in 2003, just as migration began: the Northampton trial ran in 2003, national rollout followed, and on 14 February 2006 signature ceased to be accepted for in-store chip card purchases. UK Finance’s twentieth-anniversary assessment, published on that date in 2026, records a 95 per cent reduction in counterfeit card fraud losses over the intervening two decades. Chip and PIN now accounts for 30 per cent of UK card payments by value, averaging £93 a transaction against £17 for a contactless tap.

Three qualifications belong with that number. SDA-only cards were never protected in the way the summary implies, and a large installed base of them persisted for years. Magnetic stripe fallback — a terminal accepting the stripe when the chip fails to read — reopened the door wherever permitted, which is why schemes have progressively closed it. And the fraud did not vanish; it moved to the channel where no chip is present. That is Volume V.

The chip in one paragraph#

An EMV chip is an ISO/IEC 7816 smart card running a payment application addressed by a 5-to-16-byte Application Identifier, speaking APDUs of the form CLA-INS-P1-P2-Lc-Data-Le and answering with data plus a two-byte status word. The terminal selects a directory (1PAY.SYS.DDF01 on contact, 2PAY.SYS.DDF01 on contactless), builds a candidate list, selects an application, learns from the PDOL what transaction data the card requires, sends it in GET PROCESSING OPTIONS, gets back a capability profile and a file map, reads the named records, verifies the certificate chain up to a scheme public key it already holds, challenges the card to sign something fresh, and asks for a verdict with GENERATE AC. Static data authentication proves the data was signed; dynamic proves the card is present; combined proves the card, the decision and the transaction are one indivisible statement. Through all of it no instruction exists that will make the chip disclose its keys — which is why a card that answers questions cannot be photocopied, and a card that merely presents data always could.

14.98 Common wrong ideas#

Wrong: The chip is a small computer with a clock and power of its own. Right: It is parasitic on the terminal for both voltage and clock and computes only while both are present, it cannot start anything, and it must ask the terminal for the date without any way of telling whether the terminal is lying.

Wrong: The card decides whether to approve the transaction. Right: The terminal decides which question to ask and the card may only choose among the answers to that question, and it may return an answer weaker than the one requested but never a stronger one.

Wrong: Reading data off a chip is an attack, so a contactless card that gives up an account number over the air is broken. Right: Any reader may power any card and obtain the account number, expiry, cardholder name and usage rules; the security does not come from hiding those fields but from the fact that holding them does not let you produce a cryptogram.

Wrong: Offline data authentication proves the card and the terminal to each other. Right: The certificate chain runs one way only, and nothing in the ordinary flow requires the terminal to prove anything, because a terminal is a commodity device and the chip cannot check a revocation list or even know today’s date.

Wrong: Any card with a chip cannot be cloned. Right: A card performing only static data authentication carries a genuine signature over material identical on every transaction, so a device that recorded it once can present it again; freshness arrives only with dynamic authentication.

Wrong: “EMV” is a single protocol, so a Visa tap and a Mastercard tap run the same steps. Right: Contact runs the four EMV books while contactless runs an entry-point specification and a family of per-scheme kernels with their own commands, data elements and decision logic, and treating EMV as one protocol is the commonest error in engineering documentation about cards.

Wrong: A 6A82 in a trace is an error. Right: It is how a card says “I do not have that application”, it is the expected response during selection, and it is what sends the terminal into trying each Application Identifier from its own list one at a time.

Wrong: Application Identifiers are seven bytes long. Right: An identifier is a five-byte registered provider identifier plus up to eleven bytes of proprietary extension, so lengths run from 5 to 16, and a terminal that assumes seven fails on UnionPay and girocard.

Wrong: A library that handles 9000 and 61 xx has covered the protocol. Right: A card may also answer 6C xx, meaning the expected-length byte was wrong and xx is the correct value, and an implementation that ignores it passes every test in the lab and fails intermittently in the field.

Wrong: Dynamic data authentication protects the transaction. Right: Standalone dynamic authentication proves the card is genuine without binding the signature to the amount, so a device between card and terminal can let it succeed and still interfere with the decision; only combined generation joins identity, decision and transaction into one signature.

14.99 Chapter summary in 20 lines#

1. Behind the eight gold pads on a card, five of which do anything, sits a die a couple of millimetres square holding a processor, a program in read-only memory, non-volatile memory for data and keys, and hardware for arithmetic on very long numbers.
2. The structural difference from a magnetic stripe is that a stripe is a recording while a chip is a correspondent, so everything else in card security follows from the fact that a chip answers rather than presents.
3. Reading a chip is trivial and deliberate, because the account number, expiry, cardholder name and usage rules are exactly the fields a merchant needs.
4. What the chip will never do is disclose its private key or the symmetric key it shares with its issuer, because no instruction in the set would output them and the program sits in read-only memory laid down at manufacture.
5. EMV is not a standard in its own right but a profile of the ISO/IEC 7816 series, currently version 4.4 of October 2022 in four books, whose provisions take precedence wherever they differ from those standards.
6. Every exchange is a command of class, instruction and two parameter bytes with an optional body, answered with optional data and a mandatory two-byte status word.
7. The whole vocabulary is thirteen commands, of which an ordinary purchase uses five or six, and the status words carry as much of the protocol as the commands do.
8. An application is addressed by an Application Identifier of 5 to 16 bytes, and terminals that assume a fixed length break on real cards from real schemes.
9. Selection begins with a directory, 1PAY.SYS.DDF01 on contact and 2PAY.SYS.DDF01 on contactless, differing by one byte, and falls back to trying each identifier in turn when the directory is absent.
10. Selecting the application returns a Processing Options Data Object List, the card telling the terminal exactly what to concatenate, in what order and at what size, with no tags, so that the card is spared the work of parsing.
11. The Data Object List padding and truncation rules are asymmetric between numeric and non-numeric formats, and reversing them yields a well-formed command whose cryptogram fails at the issuer with no useful diagnostic.
12. GET PROCESSING OPTIONS returns an Application Interchange Profile saying what the card can do and an Application File Locator saying which records to read and how many of them feed offline data authentication.
13. READ RECORD retrieves those records, and the rule that low short file identifiers have their template tag and length stripped from the authentication input while high ones do not is the most commonly mis-implemented rule in the area.
14. Offline data authentication starts from a scheme public key already held in the terminal, walks a certificate chain through the issuer, and only then trusts anything the card says about itself.
15. Static data authentication proves that fixed data was signed by an issuer whose certificate chains to the scheme, which defeats a forger who alters the data and not one who copies it wholesale.
16. Dynamic data authentication adds a key pair belonging to the individual chip, which signs a number the terminal has just invented, so the signature is fresh and a recording is worthless.
17. Combined generation puts the cryptogram and a hash of the transaction inside that signature, so substituting any one of identity, decision or transaction invalidates all three.
18. Version 4.4 adds Extended Data Authentication on elliptic curves, because NIST will not support EMV’s 1984-bit RSA after 2030 and a tap has a hard time budget.
19. GENERATE APPLICATION CRYPTOGRAM is the decision command, and a published trace in which the terminal asked for an offline approval and the card returned an online request is card action analysis in a single exchange.
20. The chip destroyed counterfeit stripe fraud — a 95 per cent reduction in the United Kingdom across two decades — because no command discloses a key, the transaction counter makes replay visible to the issuer and the unpredictable number makes it useless to the terminal, but the fraud did not vanish so much as move to the channel where no chip is present.

Chapter sources: EMV Integrated Circuit Card Specifications for Payment Systems v4.4 (October 2022), Book 3 — sections 1.3, 5.1, 5.3, 5.4, 6.1–6.3, 6.5, 9, 10.3, Tables 1–4, 10–18, 21–25, 29–32, 41, 46 and Figures 1, 2, 4, 5; EMV Book 1 v4.3 (November 2011), sections 10–12 and Tables 38–48; EMV Book 2, sections 5 and 6, 10.2.5.2 and Annex D1, for the certificate and signature formats and the 1984-bit bound; EMVCo Specification Bulletin no. 243 and EMVCo’s FAQ “EMV Chip Specifications To Support Elliptic Curve Cryptography” (28 October 2021); EMV Contactless Specifications, Entry Point, section 3.3.1, for PPSE selection; ISO/IEC 7816-4 sections 5.3–5.4, ISO/IEC 7816-5 for RID and PIX, ETSI TS 101 220 for the 5-byte RID plus 11-byte PIX, ISO/IEC 9796-2 for the signature scheme. Traces from Basin, Sasse and Toro-Pozo, “The EMV Standard: Break, Fix, Verify”, IEEE Symposium on Security and Privacy 2021, Appendix B, and the CardContact OpenSCDP EMV tutorial. Status words and AIDs cross-checked against EFTlab’s references. Fraud figures from UK Finance, “20 years of change in payments — from Chip and PIN to mobiles” (14 February 2026), and APACS 2004 figures as reported by Pinsent Masons. Every hex trace printed here was re-parsed by hand against its stated lengths.