> EMV CHIP-AND-PIN
The idea in plain English: EMV is the global standard for chip-based payment cards — those gold contact pads you insert into a payment terminal. Before EMV, credit cards used a magnetic stripe containing fixed data that could be trivially copied (skimmed) by anyone with a $10 card reader. EMV replaced the static stripe with a microchip that generates a unique cryptogram for every transaction. Even if an attacker records the data from one payment, they cannot replay it because the next transaction uses a different session key derived from a counter that increments. The chip cryptographically proves it's the real card — not a clone — without ever revealing the secret master key stored deep inside the silicon.
Why this really exists: Before EMV, card-present fraud (someone steals your wallet, swipes your card at a store) was rampant. In the UK alone, counterfeit card fraud peaked at £185M in 2004. The three payment networks — Europay, Mastercard, and Visa — created EMV in 1994 as a unified standard. By 2005, Europe began the massive rollout of chip terminals. The US was late (liability shift in 2015) but now nearly every payment terminal worldwide supports EMV. The result: counterfeit card fraud dropped 70%+ in countries that fully adopted it. The chip itself (an ISO 7816 smart card) contains a tiny microcontroller with its own CPU, RAM, ROM, and cryptographically protected memory.
▸ How a Transaction Works (Simplified)
Every EMV transaction generates a unique cryptographic proof that the card is genuine. Here's the flow:
ICC Master Key (K_icc) — 16 or 32 bytes, never leaves the chip
Application Transaction Counter (ATC) — 16-bit counter starting at 0, increments each transaction
PAN (Primary Account Number) — your card number
===== TERMINAL DATA =====
Unpredictable Number (UN) — 4 random bytes generated by the terminal
Transaction Data: amount, currency, date, terminal country, etc.
===== STEP 1: GENERATE SESSION KEY =====
session_key = AES(K_icc, ATC || 0x00...0) # or 3DES variant
# The ATC ensures every transaction gets a DIFFERENT session key
===== STEP 2: COMPUTE ARQC =====
ARQC = AES(session_key, UN || Transaction_Data || ...)
# ARQC = Authorization Request Cryptogram (8 bytes)
# This is the "digital signature" for THIS transaction only
===== STEP 3: TERMINAL SENDS TO BANK =====
Terminal forwards: PAN, ATC, UN, Transaction_Data, ARQC
Bank (issuer) receives it and:
1. Looks up K_icc for this PAN
2. Derives the same session_key from ATC
3. Computes the expected ARQC
4. If computed ARQC == received ARQC → card is genuine ✓
===== STEP 4: BANK RESPONDS WITH ARPC =====
ARPC = AES(session_key, ARQC || Auth_Response_Code)
# ARPC = Authorization Response Cryptogram — proves the bank authorized this
Terminal checks ARPC. If valid → transaction approved ✓
💡 The magic is the Application Transaction Counter (ATC). Since it increments by 1 for every transaction, the same card data encrypted with the same master key always produces a different ARQC. A stolen ARQC from one transaction is useless for a second transaction because the ATC would be different.
▸ Why EMV Stops Card Cloning
Imagine an attacker installs a skimmer on a payment terminal. The skimmer records everything the chip sends: the PAN, ARQC, ATC, and the terminal's unpredictable number. Here's why this data is useless for cloning:
1. The attacker tries to use the cloned data at a different terminal
2. The new terminal sends a different Unpredictable Number (UN)
3. The bank computes the expected ARQC using the new UN — it won't match the recorded ARQC
4. The bank also sees the ATC value and expects the next counter value (ATC+1 or higher)
5. Transaction denied. The attacker cannot generate a valid ARQC because they don't have the ICC Master Key (K_icc) embedded in the chip
The chip contains a tamper-resistant secure element. Extracting K_icc requires physical decapping and electron microscope probing — orders of magnitude harder than swiping a magstripe. Even if one card is cracked, the K_icc is unique per card, so the other billion cards remain safe.
▸ EMV Cryptography in Detail
EMV supports two cryptographic algorithms depending on the card:
Session Key Derivation:
s_key = 3DES(K_icc, ATC || padding)
ARQC Generation:
ARQC = first 4 bytes of (3DES(s_key, data_block))
===== AES (modern cards, Session Key Derivation Method) =====
Session Key Derivation (EMVCo Book 2, Section 6.2):
s_key = AES(K_icc, ATC || 0x00 * 14)
ARQC Generation (EMVCo Book 2, Section 7.1):
data = UN || Amount || Currency || Date || Terminal_Country || ...
ARQC = AES(s_key, data)[0:8] # first 8 bytes
The ARQC is typically 8 bytes (64 bits). The ATC is 2 bytes (16 bits, 0–65535), and when it rolls over, many cards simply stop working — you need a new card. This is by design: the chip's crypto keys and counter are part of the secure element and cannot be reset.
▸ Simplified EMV Cryptogram in Python
import struct, os
# ===== Card-side data (simulated) =====
K_icc = bytes.fromhex("00112233445566778899AABBCCDDEEFF") # 16-byte master key
atc = 42 # Application Transaction Counter
pan = "4532015112830366"
# ===== Terminal-side data =====
unpredictable_number = os.urandom(4) # 4 random bytes
transaction_data = struct.pack(">I512", 2500, 840) # €25.00 in USD (840)
# In reality: amount, currency, date, terminal capability, etc.
# ===== Derive session key (simplified EMV method) =====
# EMV: s_key = AES(K_icc, ATC || 0x00*14)
atc_bytes = struct.pack(">H", atc) # 2 bytes, big-endian
s_key_input = atc_bytes + b"\\x00" * 14
session_key = AES.new(K_icc, AES.MODE_ECB).encrypt(s_key_input)
# ===== Generate ARQC =====
arqc_input = unpredictable_number + transaction_data
# Pad to block size if needed (AES block = 16 bytes)
arqc_input = arqc_input.ljust(16, b"\\x00")
arqc = AES.new(session_key, AES.MODE_ECB).encrypt(arqc_input)[:8]
print(f"ATC: {atc}")
print(f"UN: {unpredictable_number.hex()}")
print(f"ARQC: {arqc.hex()}")
# ===== Bank verification (same computation) =====
# Bank looks up K_icc by PAN, recomputes session_key and ARQC
expected_session_key = AES.new(K_icc, AES.MODE_ECB).encrypt(atc_bytes + b"\\x00" * 14)
expected_arqc = AES.new(expected_session_key, AES.MODE_ECB).encrypt(arqc_input)[:8]
if arqc == expected_arqc:
print("✓ Card verified — ARQC matches")
else:
print("✗ Card rejected — ARQC mismatch")
# ===== ARPC (issuer response) =====
auth_response = b"\\x00\\x00" # 00 00 = approved
arpc_input = arqc + auth_response
arpc = AES.new(session_key, AES.MODE_ECB).encrypt(arpc_input.ljust(16, b"\\x00"))[:8]
print(f"ARPC: {arpc.hex()}")
💡 This is a simplified educational example. Real EMV uses more complex session key derivation (multiple diversification steps), padding schemes, and transaction data hashing (including a Transaction Certificate). The full specification is thousands of pages (EMVCo Book 1–4).
▸ Known EMV Attacks & Weaknesses
EMV is not perfect. Several real-world attacks exist:
Pre-play attack (2013, Stadler et al.): A rogue terminal can record an ARQC and replay it to the bank before the legitimate transaction arrives. The bank sees the ATC and accepts the pre-played transaction. Requires a malicious terminal, but bypasses the "unique ATC" protection.
website attack (2015, "NFC website"): Two attackers use a phone near the victim's card and a second phone at a terminal, relaying the radio signals. The terminal thinks the card is present. The card thinks it's talking to a legitimate terminal. Mitigation: distance bounding protocols (not widely deployed).
No-PIN contactless limits: In many countries, contactless transactions under a threshold ($50–100) don't require PIN verification — meaning a stolen contactless card can be used for multiple small purchases without the PIN.
Offline PIN interception: Some implementations verify PIN offline against the chip. The chip stores a PIN offset; if the attacker can read the chip's memory (physical attack), they can extract the PIN.
💡 Despite these attacks, EMV remains exponentially more secure than magnetic stripe. The pre-play attack requires a malicious terminal (not a skimmer), and the website attack requires physical proximity to both victim and terminal. For everyday card usage, EMV prevents the most common fraud vectors.
▸ Real-World Applications
- Payment cards: Every Visa, Mastercard, Amex, Discover, UnionPay, and JCB chip card worldwide — over 10 billion cards
- ATM transactions: Every ATM withdrawal using a chip card generates an ARQC
- Contactless payments: Apple Pay, Google Pay, Samsung Pay all use EMV tokenization — a dynamic device-specific PAN replaces the real card number
- EMV tokenization: Instead of the real PAN, a token (Domain Restricted) is used, further limiting fraud if the terminal is compromised
- Online card verification: EMV 3-D Secure (SCA) is the online version — dynamic cryptograms for e-commerce transactions
▸ EMV's Cryptogram Family
| Cryptogram | Meaning | When |
|---|---|---|
| ARQC | Authorization Request Cryptogram | Online transaction — sent to issuer for authorization |
| ARPC | Authorization Response Cryptogram | Issuer's response approving/declining the transaction |
| TC | Transaction Certificate | Offline-approved transaction — proves card generated the cryptogram |
| AAC | Application Authentication Cryptogram | Transaction declined by card (e.g., card read error, exceeded offline limit) |
Each cryptogram type uses the same session key derivation but different data inputs, ensuring cryptograms for different purposes are always distinct.