Proving It Is You

17.0 What this chapter gives you#

1. You will be able to explain why the Application Cryptogram is a proof and the three bytes of tag 9F34 are only a claim, and why that difference is where every serious EMV attack has landed.
2. You will be able to walk a CVM List from the top for a given amount, terminal and currency, and say which rule wins and why nothing below it is ever read.
3. You will be able to decode a real tag 8E object byte by byte: amounts X and Y, the method codes, the condition codes and the continuation bit in byte 1.
4. You will be able to tell offline PIN from online PIN by their key hierarchy, block format, comparator, counter and liability, instead of calling both of them “PIN”.
5. You will be able to build an ISO 9564-1 format 0 PIN block by hand and say exactly which twelve PAN digits go into the PAN block.
6. You will be able to diagnose a 6985 on every VERIFY, a terminal that never prompts for a PIN, and an online PIN rejected across a whole estate.
7. You will be able to explain why three wrong guesses at a supermarket till lock the chip while the same card still works at a cash machine.
8. You will be able to say why the schemes could drop signature in 2018 without losing any evidence at all.
9. You will be able to explain why a phone pays for a £400 television at a reader that refuses a £120 plastic card.
10. You will be able to read a contactless trace kernel-aware, so that tag 9F66 does not decode as confident nonsense.

The previous chapter was about proving the card is real. This one is about proving you are.

They are different problems solved by different machinery, which is the first thing to get straight. The Application Cryptogram is eight bytes of mathematics that a chip and an issuer host compute independently and compare: either the bytes match or they do not. Cardholder verification has no such property. It produces three bytes, tag 9F34, and those three bytes are not a computation. They are a statement, written by the terminal, about what the terminal believes happened at the keypad. Nobody in the chain is obliged to check whether the statement is true, and for most of the last thirty years nobody did.

Once you see that cardholder verification is a claim rather than a proof, the rest follows: why the card publishes a wish list rather than a rule, why the terminal gets the casting vote, why signature survived for decades without anyone ever comparing two signatures, why the two great EMV attacks of 2010 and 2020 both struck this exact seam, and why the industry’s answer was not to fix the seam but to move verification onto a device the criminal does not have.

The plain version#

Imagine a members’ club with a door.

The club has a rule about identification, but it is not a single rule. It is a list, carried by every member, in order of preference. The first entry the doorman can actually perform, under the circumstances that apply tonight, is the one that gets used. Nothing further down the list is consulted.

A member’s card might read like this:

1. Ask the bank to check my four-digit number. Use this one only at cash machines.
2. Ask my own chip to check my four-digit number, sending it in a sealed envelope. Use this whenever the door can do it.
3. Ask my own chip to check my four-digit number, sent openly. Use this whenever the door can do it.
4. Take my signature. Use this whenever the door can do it.
5. Let me in with nothing. Use this only if it is not a cash transaction.

The doorman has his own list, much shorter: it says what he is equipped to do. Some doors have a keypad and some do not. Some have a sealed-envelope machine and some do not. Some can only take a signature.

The whole of cardholder verification is these two lists being walked down together, top to bottom, until they touch.

A worked example, in pounds#

You are buying £47.50 of groceries in a Leeds supermarket. Attended till, keypad, full capability. Your card’s list has two amounts written at the top of it, which the conditions can refer to: X is £30.00 and Y is £100.00. Neither matters here, because none of your card’s five rules happen to mention them, but they are there.

Walk the list.

Rule 1 says ask the bank, but only at an unattended cash machine. This is a supermarket till. The condition is not met, so the rule is not applicable. Move on. Note carefully: this is not a failure. The rule simply does not apply tonight.

Rule 2 says ask the chip, sealed, whenever the door can do it. Can this till do it? Yes: it has an encrypting keypad and knows how to seal a number for a chip. Condition met, method supported. This rule wins. The till stops walking. It asks you for four digits, seals them, hands them to the chip, and the chip says yes or no.

Rules 3, 4 and 5 are never read. The signature line is never reached. This is why two cards in the same shop, on the same day, for the same amount, can behave completely differently: they carry different lists.

Now change one thing. Suppose the till is old and cannot do the sealed-envelope trick. Rule 2 becomes inapplicable and rule 3 wins: same digits, same chip, but sent in the open, which is fine because the wire between keypad and chip is a few centimetres long and inside a tamper-resistant box.

Change one more thing. Suppose the till has no keypad, only a screen and a printer. Rules 2 and 3 both drop out and rule 4 wins: signature. And if the till cannot even print, rule 5 wins: you are let in with nothing at all, which sounds alarming until you remember it is exactly what happens every time you tap for a coffee.

Four ways to prove it, and a fifth#

There are, in the classical scheme, four families.

The chip checks the PIN. Your card stores your PIN. Not your bank: your card. The till sends the digits to the chip over the contacts, the chip compares them to what it holds, and answers. The bank is not involved and does not need to be, which is why this method exists: it works when the shop’s line to the bank is down, on an aeroplane, in a car park machine at three in the morning. It comes in two flavours, one where the digits travel in the open between keypad and chip and one where they are sealed with the chip’s own public key first.

The bank checks the PIN. The chip is not involved at all. The till locks your digits into a box that only the bank’s cryptographic hardware can open and sends it with the authorisation request. This is what happens at every cash machine and at most tills outside Europe.

Signature. The till prints a slip, you sign it, and somebody is theoretically supposed to compare it to the strip on the back of the card.

Nothing. The card and the terminal agree, in writing, that this transaction needs no verification.

And the fifth, which arrived with the phone: the device checks you. Your phone or watch takes your face, fingerprint or passcode, satisfies itself, and tells the till that verification has already been done. The till never sees anything. Nor, importantly, does the bank.

Three strikes#

The chip keeps a counter, usually starting at three. Every wrong PIN takes one off it; a correct PIN puts it back. At zero the chip refuses to check any more PINs, permanently, until the bank sends a specific instruction to reset it — which it can only do while you are online, which is why “put your card in a cash machine and try again” is genuinely useful advice.

The counter lives on the card, not on the account. Three wrong guesses at a supermarket till will lock the chip, and yet the same card will still work at a cash machine using the bank-checks-the-PIN route. Two counters, two places.

The box the PIN travels in#

Whenever a PIN moves anywhere, it moves inside a fixed-size scrambled box: sixteen hexadecimal characters, eight bytes, containing in order a digit saying which recipe was used, a digit saying how many digits the PIN has, the PIN itself, and filler.

For a PIN of 1234 the raw box is 2 4 1234 FFFFFFFFFF: recipe 2, four digits, one-two-three-four, ten Fs of padding. That is the box used when the chip does the checking, and it is deliberately dull.

For a PIN going to the bank the box is built differently, and this is the clever bit: the account number is mixed in before it is locked. Two people with the same PIN on two different cards produce completely different boxes, so an attacker who collects a million boxes cannot spot that a hundred thousand of them are 1234. The box for PIN 1234 on card 43219876543210987 is 0412AC89ABCDEF67, and on any other card it would be something else entirely.

The three-byte receipt#

When it is over, the till writes down three bytes: what method was used, under what condition, and did it work. 01 00 02 means “the chip checked a plaintext PIN, the condition was always, and it succeeded”. That is the whole record, and the only record.

Here is the sentence to carry to dinner: nothing in the system forces those three bytes to be true. The till writes them. The card does not check them. The bank receives them and, historically, believed them.

Where the plain version stops being true#

The list-walking picture is correct as far as it goes. Four things it hides matter enormously.

The card proposes; the terminal disposes; and nobody audits#

The CVM List is a preference, not an instruction. The terminal performs the walk, decides which rule was applicable, performs the method, and authors the result. The card contributes only the list.

Two consequences follow, and both have been exploited. First, if the terminal lies about the outcome, the card has no independent way of knowing. In the 2010 Cambridge attack (Murdoch, Drimer, Anderson and Bond, Chip and PIN is Broken, IEEE Symposium on Security and Privacy), a small device between card and terminal swallowed the VERIFY command and answered 9000 — success — on the card’s behalf. The terminal recorded a successful PIN. The card, never having been asked, recorded that no PIN had been performed. Both statements went to the issuer in the same message, and issuers were not comparing them.

Second, the result does often get bound into the cryptogram — tag 9F34 appears in most CDOL1s — and that binding creates a false sense of safety. The cryptogram authenticates the terminal’s claim. It does not make the claim true.

There is also a switch that turns the whole subject off. The Application Interchange Profile, tag 82, has a bit meaning “cardholder verification is supported”. If it is clear, the terminal does not walk the list at all, whatever the list says.

Offline PIN and online PIN are not two flavours of one thing#

Calling them both “PIN” hides that they share almost nothing.

Offline PIN travels a few centimetres over the card contacts, is protected either not at all or by the card’s own RSA or elliptic-curve public key, is compared by the chip, is counted by the chip, and is never seen by the issuer. Online PIN travels thousands of kilometres, is protected by symmetric keys shared between terminal, acquirer, switch and issuer, is compared inside a hardware security module in a data centre, is counted by the issuer’s host, and is never seen by the card.

Different PIN block formats, different key hierarchies, different failure modes, different counters, and in most markets different liability. A terminal estate can support one and not the other; an issuer can permit one and not the other. Treating them as interchangeable is the commonest conceptual error in this area.

The list barely applies to the transaction you actually did today#

Amounts X and Y are expressed in the application currency, and conditions '06' through '09' are explicitly conditioned on the transaction being in that currency. Present a sterling-denominated card at a euro-denominated terminal and every amount-based rule silently evaporates. That is not an edge case; it is every foreign holiday.

More fundamentally, most cardholder verification decisions in a modern economy are contactless, and contactless decisions are dominated not by tag 8E but by limits configured in the reader and by kernel-specific data objects. When your card asks for a PIN after a run of taps, that decision came from counters inside the card application and from reader limits, not from the walk described above.

Signature did not die of insecurity. It died of pointlessness#

The protocol’s definition of a successful signature CVM is not “the signatures matched”, nor even “a signature was obtained”. It is, effectively, “the terminal is capable of handling signature”. The capability bit is set, the condition is met, the method is deemed performed, and the result byte is set to successful. There is no comparison step anywhere in EMV, because comparison is a human act the specification cannot describe.

Signature was therefore always a null CVM dressed as a real one, and what killed it was the schemes noticing that it created queues, receipts and disputes while providing no evidence. Note the mirror-image error too: “No CVM required” is not the absence of security. It is a deliberate, listed, cryptogram-covered choice by the issuer, appropriate below a threshold the issuer picked.

The technical version#

The objects involved#

The relevant Application Interchange Profile bits, from EMV 4.4 Book 3 Annex C1, are byte 1 bit 5 (0x10), “Cardholder verification is supported”, and byte 1 bit 2 (0x02), “On device cardholder verification is supported”. That second bit was reserved for the contactless specifications in EMV 4.3 and only became a named contact-specification bit in 4.4. Byte 2 carries 0x80 “Contactless EMV mode supported”, 0x40 “Mobile phone”, 0x20 “Contactless transaction” and 0x01 “Relay Resistance Protocol supported”.

The CVM List, tag ‘8E’#

The value field is a fixed eight-byte header followed by a variable number of two-byte Cardholder Verification Rules:

Both amounts are binary integers in the minor units of the application currency, with the decimal point implied by the Application Currency Exponent, tag 9F44. A list is always at least ten bytes and always an even length; anything else is malformed.

CV Rule byte 1 carries the method in bits 6 to 1, a continuation flag in bit 7, and a reserved bit 8. Bit 7 set means apply the succeeding CV Rule if this CVM is unsuccessful; bit 7 clear means fail cardholder verification if this CVM is unsuccessful. The method codes, from EMV 4.4 Book 3 Annex C3 Table 43:

The biometric codes '06' to '0F' are an EMV 4.4 addition. In 4.3 that whole range was reserved. If your parser labels '08' as RFU, it is a 4.3 parser.

CV Rule byte 2 is the condition:

Only condition '03' explicitly tests terminal support, but the terminal must skip any rule whose method it cannot perform regardless, so '03' is the condition you will see on almost every rule that is not amount- or environment-specific.

Decoding a real list#

Take this object:

8E 12 00 00 0B B8 00 00 27 10 42 01 44 03 41 03 5E 03 1F 02

Eighteen bytes of value: eight of header, ten of rules.

Amount X is 00000BB8 = 3000, which with a sterling application currency and exponent 2 is £30.00. Amount Y is 00002710 = 10000, or £100.00.

Now give the terminal a Terminal Capabilities of E0 F8 C8. Byte 1 E0 is manual key entry, magnetic stripe and IC with contacts. Byte 3 C8 is SDA, DDA and CDA. Byte 2, the CVM capability field, is F8:

F8 sets the top five: all four classical methods plus no-CVM, and no biometrics. Bits b3, b2 and b1 are EMV 4.4 definitions; in 4.3 they were RFU.

For a £47.50 attended purchase in sterling with Terminal Type '22' (operational control: merchant; environment: attended, offline with online capability), the walk goes: rule 1 skipped, condition not met; rule 2 applicable and supported, so offline enciphered PIN is performed and the walk stops. If the PIN matches, the terminal writes CVM Results 44 03 02. Note that byte 1 carries the entire CV Rule byte 1 that was applied, continuation bit included: 44, not 04.

The VERIFY command and offline plaintext PIN#

Offline PIN is carried by the ISO/IEC 7816-4 VERIFY command: class '00', instruction '20', P1 '00'. P2 is the qualifier of the reference data, and EMV assigns two values: '80' for plaintext PIN and '88' for enciphered PIN. A complete plaintext VERIFY for PIN 1234 is:

00 20 00 80 08 24 12 34 FF FF FF FF FF

Lc is 08 and the data is an ISO 9564-1 format 2 PIN block: control field '2', length nibble '4', the four PIN digits, then 'F' padding to eight bytes. Format 2 exists precisely for this case. ISO describes it as being for local use with offline systems only, and it deliberately contains no account number: the card already knows its own PAN, and there is no benefit in diversifying a block that never leaves the reader.

Status words matter here more than usual:

6985 is by far the commonest complaint from engineers writing their first EMV client, and it almost always means one of two things: the command sequence is wrong — VERIFY may be issued any time after Read Application Data and before terminal action analysis completes, not before GET PROCESSING OPTIONS — or the card does not support plaintext offline PIN and you should be sending '88'.

Read the PIN Try Counter before attempting VERIFY, with GET DATA:

80 CA 9F 17 00

If it returns zero, EMV requires the terminal not to attempt offline PIN, to set “PIN Try Limit exceeded” in the TVR, and to treat the method as unsuccessful — which, because bit 7 of the rule is usually set, sends the walk to the next rule rather than failing outright. Resetting the counter requires the issuer script command PIN CHANGE/UNBLOCK, instruction '24' under the proprietary class, delivered after online authorisation.

Offline enciphered PIN#

The RSA form works as follows. The terminal issues GET CHALLENGE, class '00', instruction '84', P1 and P2 both '00', and the card returns an eight-byte unpredictable number. The terminal then assembles a block for encipherment:

N(IC) is the byte length of the modulus of the key used, so the assembled block is exactly one RSA block. The key is the ICC PIN Encipherment Public Key, recovered from the certificate in tag 9F2D with the exponent in 9F2E and, where the modulus does not fit in the certificate, the remainder in 9F2F. If the card carries no separate encipherment key, the ICC Public Key from 9F46, 9F47 and 9F48 is used instead. The result goes in the data field of VERIFY with P2 '88' and Lc equal to N(IC). The card decrypts, checks that the recovered header is '7F', checks that the recovered unpredictable number equals the one it issued, and only then parses the PIN block.

That unpredictable number is the entire replay defence. Without it, a recording of one enciphered VERIFY would work forever.

EMV 4.4 adds an elliptic-curve form, Offline Data Encipherment, signalled by Terminal Capabilities byte 2 bit 1. It has no random pad, because the ECC construction supplies its own freshness. EMVCo’s worked example (document EMV-SWG-NJ24r95, version 1.0a, December 2022) gives the plaintext for PIN 1234 as:

Data Header               7F
PIN block (ISO format 2)  24 12 34 FF FF FF FF FF
ICC Unpredictable Number  4B 61 72 6D 65 6C 69 74

The terminal generates an ephemeral P-256 key pair, does Diffie-Hellman against the card’s public key, derives four AES keys via CMAC and AES, encrypts in counter mode under K1, MACs under K2 with CMAC truncated to eight bytes, and sends the ephemeral public key’s x-coordinate concatenated with the ciphertext. The card repeats the derivation with its private key, verifies the MAC, decrypts, checks the trailing unpredictable number and the leading '7F', and — in EMVCo’s own words — parses the eight bytes following the header as an ISO-2 PIN block.

Online PIN and PIN block formats#

Online PIN never touches the card. It is captured on a PCI PTS POI approved device, formatted into a PIN block, encrypted under a key shared with the acquirer, and carried in the authorisation message. Between capture and the issuer’s hardware security module it is translated — decrypted and re-encrypted under the next zone’s key — inside HSMs at each hop, and must never exist in the clear outside a secure cryptographic device. That is the substance of the PCI PIN Security Requirements, currently version 3.1 (March 2021), and of the PCI PTS POI Modular Security Requirements, currently version 7.0.

The formats are defined by ISO 9564-1. The first nibble of the block identifies the format.

Formats 0 to 3 are eight bytes, matching the 64-bit block size of TDEA. Format 4 is sixteen, matching AES.

Format 0 is worth building by hand once. For PIN 1234 and PAN 43219876543210987:

PIN block   0 4 1 2 3 4 F F F F F F F F F F
PAN block   0 0 0 0 9 8 7 6 5 4 3 2 1 0 9 8
XOR         0 4 1 2 A C 8 9 A B C D E F 6 7

The PAN block is four zero nibbles followed by the twelve rightmost PAN digits excluding the check digit. Getting that exclusion wrong is a classic bug: it produces a block that decrypts to garbage at the issuer and a 55 invalid-PIN response for every cardholder on the estate.

Format 4 is a different animal. The PIN block is 4 | length | PIN | fill digits A | sixteen random nibbles, making 32 nibbles. The PAN block is a length indicator ('0' to '7', meaning PAN length 12 to 19), the PAN, and zero padding, also 32 nibbles. The PIN block is encrypted with AES, the result XORed with the PAN block, and that encrypted with AES again. For PIN 1234 on PAN 432198765432109870 the clear PIN block begins 44 12 34 AA AA AA AA AA and the PAN block is 64321987654321098700000000000000. Migration has been slow enough that PCI SSC published a dedicated information supplement on implementing it and suspended its own compliance dates.

How the issuer actually checks#

The issuer’s HSM decrypts the PIN block, extracts the PIN, and compares it. It does not store the PIN. There are two dominant methods, both older than EMV by decades.

IBM 3624 with offset. The HSM encrypts validation data — conventionally the PAN, padded to sixteen characters with a chosen pad character — under a PIN verification key, takes the leftmost four hexadecimal digits of the result, and maps them through a decimalisation table to produce the natural PIN. Because a natural PIN cannot be chosen by the cardholder, an offset is stored: the digit-by-digit modulo-10 difference between the chosen PIN and the natural PIN. At verification the HSM recomputes the natural PIN, applies the offset, and compares. The decimalisation table is a parameter, and a well-known family of attacks in the early 2000s exploited HSM APIs that let an attacker supply a degenerate one.

Visa PVV. A Transformed Security Parameter is built from the eleven rightmost PAN digits excluding the check digit, a single-digit PIN Verification Key Indicator in the range 0 to 6, and the four PIN digits: sixteen digits, eight bytes. That is encrypted under the PIN verification key pair and the result scanned left to right for decimal digits; if four are not found, the scan repeats over the remaining digits with ten subtracted. The four-digit PIN Verification Value is stored on the account.

Neither scheme stores a PIN and neither can recover one. Both store a four-digit residue, which is why an issuer can tell you your PIN is wrong but genuinely cannot tell you what it is.

The CVM Results, tag ‘9F34’#

Three bytes, defined in EMV 4.4 Book 4 Annex A4 Table 33.

Value '3F' in byte 1 is the interesting asymmetry. In a CV Rule it is explicitly “not available for use”; in CVM Results it is the legitimate way of saying nothing was done. A parser sharing one lookup table between rules and results will reject valid CVM Results.

EMVCo’s own ECC worked example carries 9F34 as CDOL1 data with the value 01 00 02: plaintext PIN verified by the ICC, condition Always, successful.

The Terminal Verification Results, byte 3#

The whole of TVR byte 3 is cardholder verification. Under EMV 4.4:

Bit 3 was named “Online PIN entered” in EMV 4.3 and renamed “Online CVM captured” in 4.4 to accommodate online biometrics. The name changed; the bit did not. An unrecognised CVM code sets bit 7 and the method is treated as unsuccessful, which is how a card personalised with a scheme-proprietary code fares on a terminal that has never heard of it.

These bits are what issuer and terminal action codes actually test. An Issuer Action Code – Denial with byte 3 bit 8 set means “decline anything where cardholder verification failed”, and that is where the CVM decision becomes a financial outcome.

Contactless: a different machine wearing the same words#

The contactless world is not the contact world with an aerial. EMV Contactless Book B defines an Entry Point that selects a kernel, and Books C-1 through C-7 define kernels 1 to 7, each belonging to a payment system. Kernel 2 is Mastercard’s; kernel 3 is Visa’s. Book C-8, Kernel 8, was published by EMVCo in October 2022 as a common kernel licensable on the same royalty-free terms as the contact specification, with elliptic-curve card authentication and explicit support for biometric and mobile cardholder verification methods.

The tag collision problem. The most dangerous fact in contactless decoding is that the same tag means different things in different kernels. Tag 9F66 is the Terminal Transaction Qualifiers for Entry Point and for kernels 3, 6 and 7, but kernel 2 defines 9F66 as PUNATC(Track2). Tag 9F6B is the Card CVM Limit in kernel 3 and Track 2 Data in kernel 2. Tag 9F6E is the Form Factor Indicator in kernel 3, Third Party Data in kernel 2 and Enhanced Contactless Reader Capabilities in kernel 4. A decoder that does not know which kernel produced the trace will produce confident nonsense.

Kernel 3, the Visa model. The reader supplies Terminal Transaction Qualifiers, tag 9F66, four bytes, usually through the PDOL:

The card replies with Card Transaction Qualifiers, tag 9F6C, two bytes:

That is the whole contactless CVM negotiation for Visa: two bits, one saying “ask for a PIN”, one saying “the device already did it”. The CVM List is not consulted.

Kernel 2, the Mastercard model. Here reader configuration drives the decision. Three tags matter, all six-byte numeric amounts:

The kernel instantiates a single working Reader Contactless Transaction Limit from DF8125 if the card indicates on-device cardholder verification is supported and from DF8124 otherwise — which is exactly why a phone can pay for a £400 television at a reader that will refuse a £120 plastic card. Separately, if the amount reaches DF8126, the kernel instantiates the CVM capability field of Terminal Capabilities with “CVM Required”, forcing a method to be selected.

The card’s own counters do the rest: consecutive-transaction and cumulative-amount counters live in the card application, not the terminal, and when they trip the card asks for verification. That is why the PIN prompt appears at an apparently random shop.

Consumer Device CVM#

CDCVM is what happens when the phone, watch or laptop verifies you and the terminal takes its word. EMVCo defines it as authentication performed on the consumer’s own device: passcode, password, pattern, or a biometric such as fingerprint, iris, voice or facial recognition.

Mechanically, in kernel 3 the device sets Card Transaction Qualifiers byte 2 bit 8, “Consumer Device CVM Performed”, and the reader stops asking. In kernel 2 the device signals on-device CVM support and the reader promotes itself to the higher limit. In both cases the terminal performs no verification whatsoever.

The security consequence is precisely stated by EMVCo’s own CDCVM task force chair: unlike an online PIN, a CDCVM cannot be seen by the issuer. The issuer receives an assertion that some unspecified mechanism, on some unspecified device, from some unspecified manufacturer, succeeded. Hence three pieces of EMVCo scaffolding: the EMV CDCVM Security Requirements, a Security Evaluation Process for software-based mobile payment, and an EMV CDCVM Solution ID and Database assigning each registered solution a short identifier plus metadata — name, provider, type, operating system — so an issuer can at least know which CDCVM it is being asked to trust. EMVCo has also worked with GlobalPlatform on the Secure Element Broker Interface and with the FIDO Alliance since 2016 so that FIDO’s biometric certification covers EMVCo’s performance requirements.

The regulatory position is more generous than the technical one. Under the PSD2 regulatory technical standards, Commission Delegated Regulation (EU) 2018/389, Article 11 permits contactless payments without strong customer authentication where the individual amount does not exceed EUR 50, the cumulative amount since the last strong authentication does not exceed EUR 150, or the number of consecutive contactless transactions since the last strong authentication does not exceed five. CDCVM satisfies strong customer authentication in its own right, which is why digital wallets have never been subject to those caps.

In the United Kingdom the corresponding caps were £100 per transaction and £300 cumulative, in force from 15 October 2021. From 19 March 2026 the Financial Conduct Authority removed both, allowing firms with sufficiently strong fraud controls to set their own limits or none at all; in practice the major banks retained £100 when the rules changed, and raising it also requires changes at acceptance terminals and in the industry rules that govern them. Mobile wallets were never inside that regime.

The death of signature, precisely#

Mastercard announced in October 2017 that from April 2018 merchants in the United States and Canada would no longer be required to obtain a cardholder signature for in-store credit and debit transactions, and confirmed in 2018 that from April 2019 issuers globally would no longer be required to include a signature panel on Mastercard products. Visa, American Express and Discover made comparable changes for North America over the same period.

It could be dropped so cleanly because it was never verified in the protocol. CVM code '1E' under condition '03' asks only whether the terminal supports signature; if the capability bit is set, the method is applicable, the terminal obtains the signature and reports success. There is no field for a comparison, no field for its result, and no obligation on anyone to perform one. Removing signature removed a receipt, a queue and a dispute category. It removed no evidence, because there was none.

What the attacks actually taught#

Three pieces of work define the state of understanding.

Chip and PIN is Broken (Murdoch, Drimer, Anderson and Bond, IEEE S&P 2010) inserted a wedge between card and terminal that intercepted VERIFY and returned 9000 without forwarding it. The terminal recorded a successful offline PIN in 9F34. The card, never asked, recorded in its own Card Verification Results that offline PIN verification had not been performed. Both went to the issuer in the same authorisation message. Issuers comparing the terminal’s claim with the card’s own account would have caught it; most did not.

The EMV Standard: Break, Fix, Verify (Basin, Sasse and Toro-Pozo, IEEE S&P 2021) did the same to contactless. A man-in-the-middle Android application modified the Card Transaction Qualifiers in flight: clearing byte 1 bit 8, so the terminal no longer believed online PIN was required, and setting byte 2 bit 8, so it believed the Consumer Device CVM had been performed. Demonstrated on real terminals with Visa Credit, Visa Electron and V Pay cards. The CTQ is not integrity-protected, which is the whole of the vulnerability.

Card Brand Mixup (same authors, USENIX Security 2021) made a Mastercard card behave as a Visa transaction so that the Visa PIN bypass applied. It was demonstrated on Mastercard credit, Mastercard debit and Maestro cards, including a transaction above 400 US dollars. Mastercard’s response was to check at authorisation that the Application Identifier is consistent with the card brand.

In every case the cryptogram was valid and the card genuine. What failed was that the record of who was standing there is authored by one party rather than agreed between two, and is not cryptographically bound to the act it describes.

A short field guide to failures#

The chapter in one paragraph#

The card carries an ordered wish list, tag 8E, of ways it will accept being satisfied that you are you, with two amounts and a condition attached to each entry. The terminal walks that list from the top, skipping entries whose condition is unmet or whose method it cannot perform, and stops at the first one it can do. If the method is offline PIN, the digits go to the chip in an ISO 9564-1 format 2 block inside a VERIFY command and the chip answers, decrementing its own try counter on failure. If the method is online PIN, the digits never touch the chip; they go into a format 0 or format 4 block, encrypted under keys shared with the acquirer, and are checked in a hardware security module against a stored offset or PIN verification value. If the method is signature, nothing is verified at all. Whatever happens, the terminal writes three bytes — method, condition, outcome — and forwards them. Contactless replaces the walk with reader limits and two bits in a kernel-specific object, and the phone replaces the whole exercise with a face the terminal cannot see and the issuer cannot verify. The eight bytes of the cryptogram are proof. These three bytes are testimony. Every serious attack on EMV in the last two decades has been an attack on the difference.

17.98 Common wrong ideas#

Wrong: the card decides how you are verified. Right: the card publishes an ordered preference in tag 8E; the terminal performs the walk, decides which rule was applicable, performs the method and authors the result.

Wrong: because tag 9F34 is bound into the cryptogram, its contents must be true. Right: the cryptogram authenticates the terminal’s claim without making the claim true, which is exactly what the 2010 Cambridge wedge exploited.

Wrong: offline PIN and online PIN are two flavours of one thing. Right: they share almost nothing — different block formats, different key hierarchies, different comparators, different counters and in most markets different liability.

Wrong: three wrong PINs lock the account. Right: the try counter lives on the card, so the chip refuses further offline PIN checks while the same card still works at a cash machine on the online route.

Wrong: signature was dropped because it was insecure. Right: code '1E' under condition '03' asks only whether the terminal supports signature; there is no comparison step anywhere in EMV, so removing it removed a queue and a receipt but no evidence.

Wrong: “No CVM required” is the absence of security. Right: it is a deliberate, listed, condition-bound and cryptogram-covered choice by the issuer, appropriate below a threshold the issuer picked.

Wrong: the amounts X and Y govern your spending wherever you are. Right: conditions '06' to '09' only apply when the transaction is in the application currency, so every amount-based rule silently evaporates on a foreign holiday.

Wrong: the PIN prompt after a run of taps came from walking the CVM List. Right: it came from counters inside the card application and from limits configured in the reader; kernel 3 settles the question with two bits and kernel 2 with DF8124, DF8125 and DF8126.

Wrong: a value of '3F' in tag 9F34 byte 1 is invalid. Right: '3F' is “not available for use” in a CV Rule but is the legitimate way of saying “CVM not performed” in CVM Results, and a parser sharing one table between the two will reject valid data.

Wrong: Consumer Device CVM gives the issuer what an online PIN gives it. Right: a CDCVM cannot be seen by the issuer, which receives only an assertion — hence EMVCo’s security requirements, evaluation process and solution database so an issuer at least knows which mechanism it is trusting.

17.99 Chapter summary in 20 lines#

1. Proving the card is genuine and proving the cardholder is entitled are separate problems solved by different machinery.
2. The Application Cryptogram is eight bytes computed independently by chip and issuer and compared; cardholder verification produces three bytes of terminal-authored testimony in tag 9F34.
3. The card carries an ordered wish list, the CVM List at tag 8E, of the ways it will accept being satisfied that you are you.
4. That list opens with two amounts, X and Y, in the minor units of the application currency, followed by two-byte rules pairing a method with a condition.
5. The terminal walks the list from the top, skipping any rule whose condition is unmet or whose method it cannot perform, and stops at the first one it can do.
6. Nothing below the winning rule is ever read, which is why two cards in the same shop for the same amount can behave completely differently.
7. Byte 1 of a rule carries the method and a continuation bit deciding whether failure moves to the next rule or fails cardholder verification outright.
8. There are four classical families — offline PIN checked by the chip, online PIN checked by the issuer, signature, and no CVM — plus the biometric codes added in EMV 4.4 and, in practice, the device.
9. Offline PIN travels a few centimetres in an ISO 9564-1 format 2 block inside a VERIFY command and is compared by the chip against a counter the chip itself keeps.
10. Online PIN never touches the chip: it goes into a format 0 or format 4 block, is translated inside HSMs at every hop, and is checked in the issuer’s own hardware security module.
11. Issuers store no PIN at all, only an IBM 3624 offset or a Visa PIN Verification Value, which is why they can tell you the PIN is wrong but genuinely cannot tell you what it is.
12. The PIN Try Counter lives on the card rather than the account, and only an issuer script delivered after online authorisation can reset it.
13. Enciphered offline PIN binds the card’s own unpredictable number into the encrypted block, and that number is the entire replay defence.
14. Signature was never verified anywhere in the protocol: success is declared on terminal capability alone, so it was always a null CVM dressed as a real one.
15. That is why it could be dropped from 2018 onwards so cleanly — removing it removed a receipt, a queue and a dispute category, and no evidence.
16. Whatever happens, the terminal writes down the rule applied, the condition applied and the outcome, and nothing in the system forces those three bytes to be true.
17. The 2010 Cambridge wedge answered VERIFY on the card’s behalf and the 2021 contactless work rewrote the Card Transaction Qualifiers in flight; in both the cryptogram was valid and the card genuine.
18. Contactless replaces the walk entirely, with reader limits in kernel 2 and two bits of a kernel-specific object in kernel 3.
19. Consumer Device CVM moves verification onto a device the terminal cannot see and the issuer cannot verify, which is why wallets were never inside the contactless caps.
20. Every serious attack on EMV in two decades has been an attack on the gap between eight bytes that are proof and three bytes that are only testimony.

Sources: EMV ICC Specifications for Payment Systems v4.4, Book 3 sections 6.5 and 10.5 and Annexes C1 and C3, Book 4 Annexes A1 and A4, and Book 2 on PIN encipherment; EMV Contactless Books B, C-2, C-3 and C-8; EMVCo document EMV-SWG-NJ24r95 v1.0a, December 2022, for the ECC worked examples; EMVCo on CDCVM, October 2020; ISO 9564-1:2017 and ISO/IEC 7816-4; PCI PIN Security Requirements v3.1 and PCI PTS POI v7.0; Commission Delegated Regulation (EU) 2018/389 Article 11; FCA and UK Finance contactless guidance, March 2026; Mastercard newsroom, 2017 and 2018; Murdoch, Drimer, Anderson and Bond (IEEE S&P 2010) and Basin, Sasse and Toro-Pozo (IEEE S&P 2021, USENIX Security 2021). Bit tables cross-checked against openemv/emv-utils, lumag/emv-tools, CardContact OpenSCDP and emvlab.org.