How the Cambridge chip and PIN attack works

Cambridge University researchers have uncovered a major security flaw in chip and PIN, the UK's standard payment card system.

Chip and PIN uses a smartcard with a processor and memory to verify its own identity and that of its owner to a terminal belonging to a merchant. It is based on the EMV — Europay, MasterCard, Visa — protocol, and has been adopted practically universally within the UK for most retail card-based transactions.

The card itself runs part of the protocol on an embedded secure processor, meaning that certain secrets never leave it and are not readable from outside, no matter what.

In use, a chip-and-PIN transaction is started when the cardholder puts their card into a terminal. After verifying the card, the terminal asks for a short personal identification number, and when it receives a valid PIN, the transaction takes place.

There is no need for the card to leave the holder's control, making it very hard for dishonest merchant staff to steal details; and the PIN need be known to nobody but the holder, rendering a lost or stolen card of no use — unless EMV is itself vulnerable.

There are three stages to an EMV transaction: card authentication, cardholder verification and transaction authorisation.

Card authentication
Card authentication starts when the card is put into the terminal. The terminal asks the card for a list of applications it can support — there can be many different applications, with different keys, on one card. The terminal then selects an appropriate application and tells the card which options it wants to run.

Following that, the terminal reads the card details from the chip, which include account numbers, expiry date and information such as which methods of cardholder verification the card supports. There are also various digital signatures available from the card, depending on which variant of the protocol is in use.

Once the card has provided verifiable signed records and appropriate capabilities, the terminal is satisfied with its authenticity, and attention turns to the cardholder.

Cardholder verification
Cardholder verification starts with the card and the terminal negotiating what sort of verification is appropriate. Depending on a number of factors, including the size and nature of the transaction, the terminal picks one method from the Cardholder Verification Method (CVM) list previously provided by the card.

The CVM also specifies what should happen if verification fails: whether the transaction should be aborted or another method tried.

Most cards examined by Cambridge University security researchers in a hacking experiment had only three verification options: PIN, signature or no authentication. In theory, a terminal can tell the merchant to check the signature if the PIN fails; in practice, most failed PIN verifications terminate the transaction.

If PIN is chosen, the terminal asks the cardholder to enter the number. This is sent to the card, which compares it to its internal (and never revealed) PIN.

A match, and the card returns the hexadecimal code 0x9000. A failure, and the card returns 0x63Cn, where 'n' is the number of further attempts possible before the card locks up. However, the terminal does not authenticate that the response itself actually comes from the card it thinks it is talking to.

Transaction authorisation
Transaction authorisation follows. Here, the terminal asks the card to encrypt the transaction details, using various bits of data supplied by the terminal itself. The card can reject the transaction, or it can allow it — in which case, it generates a cryptogram that is sent to the financial institution.

After various checks on the card's validity, the likelihood of the transaction being fraudulent and there being enough credit available for the transaction, the institution sends back a response code telling the terminal and card what to do next, plus another cryptogram. These are sent via the terminal to the card, which checks them for validity.

The terminal then tells the card and the card issuer that the transaction is authorised, and keeps a copy of the transaction. At this point, it normally prints a receipt too, with details of the transaction and the verification method.

The Cambridge researchers' man-in-the-middle attack takes advantage of the fact that the real card does not know which form of verification succeeded, just that the terminal does not think that a PIN verification failed. The terminal does not know that the real card never received a PIN to verify, because the fake card in the middle issued an 0x9000 success code.

The terminal reports success; the real card assumes that was due to a non-PIN verification. Although the card may then report to the terminal that the verification was not via PIN, this is in a format that is not specified in the standard, so the terminal cannot tell.