The last module secured the online world — connections and websites. But trillions of dollars move through a different piece of hardware: the payment card, tapped or inserted at physical terminals billions of times a day. That little chip is a tiny computer running real cryptography, and it solved a problem that nearly broke card payments — cloning. You will tap a simulated chip and watch it produce a different unforgeable code for every transaction, then try to replay a stolen one and watch it fail. You will see why your phone and the shops you buy from never actually hold your real card number, thanks to tokenization. This is the mostly invisible cryptography of everyday money — built from the very same primitives, applied to plastic and silicon.
For decades, payment cards carried their data on a magnetic stripe — the brown or black band on the back. The stripe holds static information: your card number, expiry, and a few other fields, written once and read the same way every time. That simplicity was its fatal flaw. The data a terminal reads to approve a payment is exactly the data sitting on the stripe — so anyone who can read the stripe once has everything needed to make payments forever.
This enabled an entire criminal industry called skimming. A thief attaches a hidden reader to an ATM or terminal, or swipes your card through a pocket device; it copies the stripe's static data; and from that copy they manufacture a cloned card that works identically to yours, because the cloned stripe carries the same numbers. The genuine card and the clone are indistinguishable to a terminal, because the only thing proving the card is the static data, and static data can be perfectly copied. The card had no way to prove it was the real card and not a replica.
The root problem is one you can now name precisely from earlier modules: the magnetic stripe relies on a static secret that must be revealed in full on every use. Anything you have to show completely, every single time, to prove yourself, can be captured and replayed. It is the worst possible design for authentication — like a password you must shout aloud to everyone in the room each time you log in. The fix had to make the card prove itself without ever revealing the secret that makes it genuine, and prove itself differently every time so that capturing one transaction tells an attacker nothing about the next. That fix is the chip.
A magnetic stripe holds static data that is read in full on every transaction, so copying it once (skimming) produces a perfect clone. The card cannot prove it is the genuine card rather than a replica, because the only thing proving it is data that can be perfectly copied. Authentication that requires revealing the whole secret every time is fundamentally breakable — which is exactly what the chip was built to fix.
The little gold square on a modern card — the EMV chip (named for Europay, Mastercard, and Visa, who defined the standard) — is not a storage band but a tiny, tamper-resistant computer. Crucially, it holds a secret key that it never reveals, not to the terminal, not to the merchant, not even to you. The chip can use the key to perform cryptography, but it will not export it. This single property changes everything.
Here is what the chip does on each payment. The terminal sends it the transaction details — the amount, the date, a random challenge number, and so on. The chip combines those details with its secret key and a transaction counter that ticks up every time, and produces a unique code called a cryptogram (technically an Application Cryptogram). This cryptogram proves two things at once: that the card holds the genuine secret key (because only the real key produces a cryptogram the bank will accept), and that this is a fresh, specific transaction (because the amount, counter, and random number are baked in). The bank, which shares the secret key, can check the cryptogram is correct — without the key ever having traveled.
Now see why this defeats cloning. The cryptogram is different for every transaction, because the counter and the random challenge change each time. An attacker who somehow captures one transaction's cryptogram has captured a code that is useless for any other transaction — it was bound to that specific amount, counter, and challenge, none of which will recur. There is no longer a static secret to copy; the thing that proves the card is a fresh cryptographic computation that the secret key performs but never discloses. Copying what you can see (the cryptogram) gains you nothing, because what makes the card genuine (the key) is never shown. This is dynamic authentication, and it is why chip cards crushed the counterfeit-card fraud that magnetic stripes enabled.
The EMV chip holds a secret key it never exports, and on each payment produces a unique cryptogram from the transaction details, a counter, and a random challenge. The bank (which shares the key) verifies the cryptogram without the key ever traveling. Because every cryptogram is bound to one specific transaction, capturing one is useless for any other — so the card cannot be cloned by copying what a terminal sees.
See dynamic authentication for yourself. On the left is the old magnetic stripe: tap it as many times as you like and it shows the same static data every time — copy it once and you have it all. On the right is the chip: each tap produces a fresh cryptogram (a real SHA-256 computation over the secret key, amount, an incrementing counter, and a random challenge). Tap the chip a few times and watch every cryptogram come out completely different.
The contrast is the whole point. The stripe log is identical line after line — a skimmer copies one and clones your card. The chip log is different every single time, because each cryptogram is bound to a counter and a random challenge that never recur. Now try the attack that breaks the stripe and watch it fail against the chip: capture a chip cryptogram and try to replay it on a later transaction.
Tap the chip above a few times first. Then an attacker captures the most recent cryptogram and tries to submit it again for a new payment. The bank tracks the counter — a stale cryptogram is rejected.
The replay fails because the bank remembers the highest transaction counter it has seen from your card, and a replayed cryptogram carries an old counter the bank has already passed. A genuine fresh transaction always has a higher counter; a replay always has a stale one. So even an attacker who perfectly captures a cryptogram in transit cannot reuse it — the dynamic, one-time nature of each code makes capture worthless. This is the precise opposite of the stripe, where capture was the whole attack.
A card transaction actually needs to answer two separate security questions, and EMV uses different cryptography for each. It is worth separating them, because they map neatly onto primitives you already know.
The first question is "is this a genuine card?" — card authentication. The cryptogram from the last sections answers it, and it typically uses symmetric cryptography (Module 03): the card and the issuing bank share a secret key, the card produces the cryptogram with it, and the bank verifies with the same key. But there is also a clever use of public-key cryptography here, and it is a direct callback to Module 06. So that a terminal can check a card even while briefly offline — unable to ask the bank — the card also carries a small certificate chain: the payment scheme acts as a root certificate authority, signing the issuing bank's key, which signs the card's data. The terminal, holding the scheme's public key, can verify this chain and confirm the card's data is authentic, exactly as your browser verifies a website's certificate. The same PKI idea, embedded in plastic.
The second question is "is this the genuine cardholder?" — cardholder verification. A real card in a thief's hands should still be stopped. This is the job of the PIN (or, increasingly, a fingerprint or face check on your phone). The PIN proves the person, where the cryptogram proves the card. The two are independent and complementary: the cryptogram stops a cloned card with the right PIN; the PIN stops a genuine card in the wrong hands. Good security needs both — something the card is (the genuine chip) and something the cardholder knows (the PIN). Modern "chip and PIN" combines them, which is why it was so much harder to defeat than a stripe-and-signature card, where the card was copyable and the signature barely checked.
Every payment answers two questions: is the card genuine (the cryptogram — symmetric crypto, plus a certificate chain for offline checks, echoing Module 06's PKI), and is this the genuine cardholder (the PIN or biometric). The cryptogram proves the card; the PIN proves the person. They are complementary — one stops clones, the other stops stolen cards — and chip-and-PIN needs both.
The chip solved card-present fraud at the terminal. But more and more payments happen with no physical card at all — in apps, online, and through phone wallets — and there the old danger returns: if your real card number (the PAN, primary account number) is typed into apps, sent to merchants, and stored in their databases, then every one of those databases becomes a target, and every breach leaks reusable card numbers. The answer is tokenization, and it is the reason your phone can pay without ever exposing your actual card.
The idea: replace the real card number with a token — a stand-in number that works like a card number in one specific context but is useless outside it. When you add a card to a phone wallet, your real PAN is sent once to a secure token service (run by the card networks), which issues a token bound to that specific device. From then on, your phone stores and transmits only the token, never the real number. The merchant receives only the token. The mapping from token back to your real PAN lives solely in the secured token vault; the merchant, the app, and even your phone's general storage never hold the real thing. If a token is bound tightly enough to a context — this device, sometimes this merchant — then a token captured elsewhere simply does not work.
See it concretely. The same real card produces a different token for each merchant or device. A token stolen from one merchant's breached database is worthless at another, because it was bound to the first context. Try it:
Your real card number is tokenized separately for each merchant. The merchant only ever sees the token. Then an attacker steals a token from one merchant and tries to use it at another.
Two card numbers for the same card, neither of them the real one, each useless where it was not issued — and the real PAN never left the vault. That is why a breach of a tokenized merchant leaks only tokens, which are far less valuable than card numbers, and why tapping your phone is in some ways safer than handing over a physical card: the merchant never touches your real number. Tokenization does for card-not-present payments what the chip did for card-present ones — it removes the static, reusable secret from the places it can be stolen.
All of this rests on keys — the card's secret key, the issuer's keys, the token vault's keys — and a chain is only as strong as how those keys are protected. If an attacker could steal the issuer's master keys, they could mint valid cryptograms at will and the whole edifice would fall. So the keys at the heart of the payment system live in specialized hardware vaults called hardware security modules (HSMs).
An HSM is a hardened, tamper-resistant device whose defining property echoes the chip on your card: it performs cryptographic operations with keys that never leave it in usable form. The keys are generated inside, used inside, and never exported; the HSM accepts requests ("verify this cryptogram," "sign this") and returns answers, but will not hand over the keys themselves. They are built to resist physical attack — many will destroy their stored keys if tampered with, drilled, or frozen — and they enforce strict controls on who can ask for what. Banks, card networks, and payment processors run HSMs as the root of their key security; the trillions flowing through card rails ultimately depend on these boxes keeping their secrets.
Notice the pattern repeating at every level. The card chip uses a key it never reveals. The phone's secure element guards the token's key it never reveals. The bank's HSM holds master keys it never reveals. The entire system is built on the same principle you first met in symmetric encryption and public keys: cryptography lets you prove and use a secret without disclosing it, and security comes from confining the secret to a place that performs operations but never surrenders the key. From the gold square in your wallet to the steel box in a bank's data center, it is one idea applied at every scale.
Hardware security modules (HSMs) are tamper-resistant vaults that perform cryptographic operations with keys that never leave them in usable form — generated, used, and guarded inside, often self-destructing if physically attacked. Banks and card networks anchor their key security in HSMs. The principle repeats at every scale — card chip, phone secure element, bank HSM — all confining a secret to hardware that uses it but never reveals it.
In the evenhanded spirit of the course, it is worth being precise about what this cryptography did and did not solve. The chip was a genuine triumph: where chip-and-PIN was adopted, counterfeit card fraud fell dramatically. Cloning a card by skimming a stripe went from easy to effectively impossible, and the in-person fraud that plagued the magnetic-stripe era collapsed. The cryptography worked exactly as designed.
But fraud is not destroyed by good security; it is displaced to wherever the defenses are weakest. As chips locked down card-present fraud, criminals shifted to card-not-present fraud — online and phone transactions, where for a long time there was no chip to demand a cryptogram and a stolen card number could still be typed in. This is exactly the gap tokenization and other online measures (one-time passcodes, 3-D Secure prompts, behavioral checks) have been racing to close, with real but incomplete success. The lesson is a recurring one in security: hardening one channel pushes attackers to another, so the contest is continuous, not won once.
And there is a deeper, humbling point that connects to the previous module. The strongest cryptography defends the technical channel, but it cannot defend against a cardholder being tricked. If a scammer convinces you to read out a one-time code, approve a payment, or move money yourself, no cryptogram or token is violated — the system did exactly what it was told by a properly authenticated user. Social engineering and authorized-push-payment fraud have grown precisely because the cryptography around cards became so hard to break that deceiving the human is now the easier path. It is the same truth as the compromised certificate authority in Module 06: the mathematics is rarely the weak link; the human and institutional system around it is. Honest security means saying so plainly — the chip is brilliant, and it moved the battle rather than ending it.
Step back and see how far the track has come. The four primitives — hash, symmetric encryption, public-key cryptography, and digital signatures — have now been assembled into the two great security systems of conventional finance: PKI and TLS securing the online world (Module 06), and EMV and tokenization securing the card world (this module). In both, cryptography protects a system that still has banks, card networks, and certificate authorities at its center — trusted institutions that issue keys, vouch for identities, verify cryptograms, and can reverse mistakes. The cryptography secures the relationships within that trusted structure.
Now the track turns to something genuinely different. What if you used these same primitives not to secure a system run by trusted institutions, but to build a system with no central institution at all — where no bank issues the keys, no authority vouches for identities, and no one can reverse a transaction? That is the question the Bitcoin and blockchain modules answer. The very same tools you now understand — hashing for tamper-evidence, public-key cryptography and digital signatures for control of funds — get rearranged into a structure where trust comes not from an institution but from the math and the network itself. The banking innovation track called this "being your own bank" and deferred the mechanics to here.
The next module begins that build. It takes the public and private keys you met in Module 04 and shows how they become a Bitcoin address and the means to control money with no account and no bank — how a digital signature (Module 05) authorizes a payment that no institution approves, and what it really means for your private key to be your money. From there, the blockchain, mining, and consensus. The primitives stay the same; what changes is that the trusted center disappears.
Six questions on card-payment cryptography — why the stripe failed, how the chip's dynamic authentication works, the two questions every payment answers, tokenization, HSMs, and the honest limits. The questions test the concepts you just saw in action.