EMV · ISO 7816 · ISO 14443

Cryptogram—every tap

Your card isn't a memory stick with a number on it. It's a tiny computer that refuses to repeat itself. Insert it below and watch the keys move.

VCCGND RSTI/O CLKVPP
~8 kBRAM on the card
0times a cryptogram repeats
3keys in play
Who holds what

Four parties,
one secret each

Nobody in this chain trusts anybody else's word. Trust comes from what each party can prove with key material the others can't read.

The card · ICC

A sealed co‑processor

A chip running a payment applet. Its keys were loaded at personalisation and can never be read back out — only used.

MKAC symmetricICC RSA private keyoffline PINATC counter
The terminal · POS

A sceptical interviewer

Holds no card secrets at all. It knows the scheme CA public keys, asks questions, measures risk, and passes signed answers upstream.

Scheme CA public keysfloor & CVM limitsterminal risk rules
Acquirer + scheme

The postal service

Routes the authorisation by BIN and carries the chip data in field 55. Normally it cannot check the cryptogram — it has no keys. Only in stand‑in does the scheme hold a copy.

routing tablesDE55 passthroughSTIP keys (if enabled)
The issuer · HSM

The only other key holder

A tamper‑responsive box holding the Issuer Master Key. From it, it can re‑derive your exact card key and re‑compute your exact cryptogram.

IMKACARPC generationPIN verification
Three key systems

Symmetric, asymmetric, and a PIN

EMV runs two completely separate cryptosystems at once, for two different threats.

01

Symmetric — proves the card is present

A three‑step key ladder ends in a MAC over the transaction data: the ARQC. Only a chip holding the right key can produce it, and it changes every single time because the counter moves.

IMKAC → MKcard = f(IMK, PAN‖PSN) → SK = f(MK, ATC) → ARQC = MACSK(data)
02

Asymmetric — proves it offline, instantly

The terminal can't call anyone mid‑transaction on a plane or a bus. So it verifies an RSA certificate chain rooted in a scheme CA key baked into the terminal, then challenges the card to sign a fresh random number.

Scheme CA PK → Issuer PK cert (90) → ICC PK cert (9F46) → SDAD (9F4B)
03

The PIN — proves it's you, not the card

Offline PIN is enciphered with the card's own public key and checked by the chip; the terminal never learns it. Online PIN instead travels as a PIN block under acquirer working keys, re‑enciphered at every HSM hop.

PIN block ‖ random ‖ ICC data → RSAICC‑PK → VERIFY (00 20 00 88)
Live simulation

Make a payment

Twelve steps, end to end. The cryptograms below are really computed in your browser with AES‑128 CBC‑MAC over EMV‑shaped data — change the amount and they change; tamper with the message and the issuer's recomputation genuinely fails.

POS · TID 20041971idle
£42.50GBP · 826
£0.50contactless limit £100£300.00
Scope of the guarantee

What a cryptogram
does and doesn't prove

✓ Proven
  • The real chip was there. Only it holds MKAC, and it never leaves the die.
  • This exact transaction. Amount, currency, date, terminal country and the terminal's random number are all inside the MAC.
  • Freshness. The ATC increments once per transaction; a replayed ARQC arrives with a stale counter and is rejected.
  • The issuer answered. The ARPC comes back and the chip itself verifies it — a fake "approved" from the network doesn't fool the card.
✗ Not proven
  • That your card number is secret. The PAN and expiry are read in the clear — which is why skimmed data still fuels card‑not‑present fraud.
  • That the cardholder consented, unless a CVM ran. "No CVM" contactless relies on limits, not proof.
  • That the terminal is honest. A crooked terminal can lie about its own risk checks; the issuer sees the TVR but can't audit the shop.
  • Distance. A relay attack forwards genuine APDUs over a network in real time — which is why timing bounds exist in newer contactless kernels.
Decoder ring

The acronyms

ARQCAuthorisation Request Cryptogram — the card's MAC asking to go online.
TCTransaction Certificate — the cryptogram of an approved transaction, kept for clearing.
AACApplication Authentication Cryptogram — the cryptogram of a decline.
ARPCAuthorisation Response Cryptogram — the issuer's signed reply, checked by the chip.
ATCApplication Transaction Counter — increments every transaction; kills replay.
CDACombined Data Authentication — the card RSA‑signs the cryptogram and the transaction data together.
TVRTerminal Verification Results — 5 bytes of "what went wrong" flags.
CDOLCard Risk Management Data Object List — the card telling the terminal exactly what to feed it.
IADIssuer Application Data — the card's private note to its issuer, including the CVR.
DE55The ISO 8583 field that carries all of this chip data across the network.