Hardware security

2026-07-13T00:00:00.000Z · complete

No homework for this session — confirmed with the instructor. The lecture is theoretical and historical, with no VM lab, so this page documents the conceptual framework of the talk for reference and for the course site.

Sessions 3, 4, and 5 moved progressively lower in the stack — memory, microarchitecture, operating system — always assuming the attacker is a software process. Session 6 (Human Security) broke that assumption from the other end: the entry point is a person. This lecture, with Jean-Jacques Quisquater — a pioneer of smart-card cryptography since the 1980s at Philips and UCLouvain — breaks the assumption from the very bottom: what happens when the attacker doesn’t target the algorithm or the software, but the physical chip that executes them?

The throughline of the lecture is that the software/hardware boundary is blurrier than it looks (is an FPGA hardware, or software loaded onto hardware? what about a USB key?), and that a cryptographically “perfect” system on paper can break completely if its physical implementation leaks information — through execution time, power draw, electromagnetic emission, or deliberately induced faults. Quisquater ties this to real Cold War espionage cases (GUNMAN, TEMPEST) that are, in essence, the same side-channel attacks studied today at conferences like CHES.

Part A — Research: Hardware Security

Based on the class lecture by Jean-Jacques Quisquater (Professor of Cryptography, UCLouvain — 20 years; 20 prior years at Philips Research; co-author of the first ISO digital-signature standards; ~250 papers in cryptography and security) [1]

Where does software end and hardware begin?

The lecture opens with examples showing the distinction is fuzzier than the course has assumed so far:

The Ledger phishing case is the lecture’s central example: attackers combined a data leak (real customer addresses) with counterfeit or tampered hardware mimicking the original device — a reminder that a physical cryptowallet’s security depends as much on its supply chain and distribution as on the chip itself.

Homomorphic encryption: do we still need secure hardware?

One conceptual alternative to securing hardware is not trusting it at all: homomorphic encryption lets you operate on encrypted data without ever decrypting it — the database never sees the plaintext, not even during computation.

• Original concept: Rivest, Adleman, and Dertouzos (1978) — the same RSA duo, long before it was practical.
• First (partially) practical scheme: Gentry, Smart, and Vercauteren (2009).
• Real cost: long computations that require dedicated coprocessors, data expansion (up to ~60× the original size), and very large keys — which is why IBM, Microsoft, Google, and Zama keep investing in making it viable [8].
• Model: the user encrypts the query with their own key (e), sends it to a database that only ever stores E(database) and computes over the ciphertext, and returns e(answer) — only the user holding key d can decrypt it. The database never sees the query or the answer in the clear.
• But: “attacks exist” — it’s not a silver bullet, and it doesn’t remove the need to think about hardware security for the keys, the coprocessors, and the rest of the system.

Old stories that are still today’s model

Quisquater builds the historical half of the lecture around four references that remain, still, live conceptual framework:

The Trojan Horse (c. 1260–1180 BCE) — not just a myth: it’s the first recorded conceptual backdoor, a problem hardware security has never stopped facing.

Auguste Kerckhoffs’s six principles (1883, La Cryptographie Militaire**)** — the same principle from the OS Security session, in its original formulation [4]:

1. The system must be practically, if not mathematically, undecipherable.
2. It should not require secrecy, and it should not be a problem if it falls into enemy hands.
3. Its key must be communicable and retainable without written notes, and changeable at the correspondents’ will.
4. It must be applicable to telegraphic correspondence.
5. It must be portable, and its use must not require several people.
6. It must be easy to use, requiring neither mental strain nor knowledge of a long series of rules.

Shannon reformulated principle two as: “the enemy knows the system.” The lecture adds a modern twist: today’s threat model assumes “the enemy generates the key, the algorithm, the protocol, and has access to the system (software, hardware, …)” — a far more powerful adversary than the one from 1883, and exactly the one that motivates the side-channel and fault attacks that occupy the rest of the lecture [1].

Operation GUNMAN (U.S. Embassy, Moscow, 1984) — the NSA discovered that IBM Selectric typewriters in the embassy had been compromised for 8 years: an implant captured keystrokes and transmitted them by radio frequency. The discovery was only made public decades later (an NSA report, and later a book) [9].

TEMPEST — the program (and today, the standard) for protecting against information leakage via electromagnetic emanation; the classic countermeasure is the Faraday cage.

Side-channel attacks: the full taxonomy

A chip needs power, reset, clock, and an I/O connection — each of those lines is a potential source of leaked information: timing, data flow, power consumption, electromagnetic emission, temperature.

Chronology (per the lecture): 1986 PIN broken by a timing attack · 1992 TNO links power consumption to executed code (Philips reaches the same finding independently) · 1995 BellCore invents Differential Fault Analysis and Kocher invents the timing attack · 1997 Kocher invents Differential Power Analysis (DPA) · 1998 Gemplus invents Voltage Manipulation · 2000 Quisquater–Samyde implement Electromagnetic Analysis (EMA).

Timing attacks. For RSA-style algorithms using square-and-multiply, the time each modular multiplication takes depends on whether the key bit is 0 or 1 — with Montgomery multiplication, some messages take c0 + cER and others just c0, depending on whether an optional extra reduction occurs. With enough input/output pairs and statistical treatment, this correlation reveals the secret key bit by bit. Countermeasure: make execution time independent of the key (constant-time execution) — the same principle Session 4’s Part A covered for cache timing.

Power analysis (SPA/DPA) and electromagnetic analysis (EMA/DEMA). An oscilloscope connected to the chip — or a contactless inductive probe for EMA — captures the consumption/emission trace during execution. In SPA, patterns visible to the naked eye in the trace (e.g. RSA’s square-and-multiply loop) already give away the key’s bit sequence. A notable point from the lecture: EMA produces noisier measurements but with sharper peaks than power analysis — some “bad instructions” (e.g. a bit-test on 6805 processors) leak far more through EM than through power, even in designs that already have DPA countermeasures in place.

Fault attacks — the CRT-RSA case. This is, to me, the single most elegant result in the whole lecture. When RSA is implemented with the Chinese Remainder Theorem (CRT) for efficiency, the signature S = m^d mod N is computed as S = a·Sp + b·Sq, combining partial results modulo p and modulo q. If an attacker induces a physical fault (clock glitch, light, radiation) that corrupts only one of the two branches — say, the q branch — then:

• S^e ≡ m (mod p) still holds (the fault-free branch)
• S^e ≢ m (mod q) (the faulted branch)

This means p divides (S^e − m) but q does not — and since N = p·q, computing gcd(S^e − m, N) factors N directly, recovering the private key from a single faulty signature (if the public key is known) or two (if it isn’t) (Joye, Lenstra, Quisquater, Journal of Cryptology, 1999) [2]. It’s a result that turned the efficiency of a mathematical optimization (CRT) into the exact surface of the attack.

Sign a message, glitch the mod-q branch, then run the same gcd an attacker would — on the classic textbook-size RSA example, computed live, no library involved:

A later development, now used as a standard chip test, is the differential fault attack (DFA) against substitution-permutation networks like AES — with a realistic fault model (random bytes, not individual bits), it breaks AES-128 with just 2 faulty ciphertexts, if the fault lands between the second-to-last and last MixColumn (work that received the CHES 2023 Test of Time Award) [3].

Smart cards: the platform where all this was first tested

Quisquater presents the smart card as the historical “laboratory” of hardware security — a chip that is, literally, a complete computer with no peripherals: CPU, ROM (holding the OS and self-tests), RAM, (E)EPROM/flash (cryptographic keys, PIN, biometric profiles, applications), coprocessors for DES/RSA/ECC, sensors, an internal firewall, and only six external lines (Vcc, Reset, Clock, Gnd, Vpp, I/O).

Historical milestones cited: first inventors at IBM (1968, USA), Japan, and Germany · Roland Moreno (France) pushes the correct version in 1974 · Michel Ugon and Louis Guillou as the technical inventors (~1977) · first single-chip security card with a secret-key cryptographic algorithm in 1981 · first DES in 1985 (TRASEC, Belgium) · first RSA coprocessor in 1989 (CORSAIR, Philips) · first 32-bit RISC in 1997 · first JavaCard in 1997 (Schlumberger).

Attacker taxonomy (IBM):

Countermeasures

An important nuance the lecture flags: adding a CRC check introduces, by definition, a transistor that decides “correct/incorrect” — and that decision point itself can become the new target of an attack (e.g. via FPGA) if it isn’t protected too.

Air-gapped protection as the upper limit. A device physically disconnected from the outside world — the extreme example being a computer that only outputs to paper/QR and only receives via scanning. The nGRAVE wallet uses exactly this model: input and output exclusively through QR codes, with no electrical or wireless connection to the outside whatsoever [7].

Post-quantum and closing

The lecture points out that post-quantum cryptography solves none of this: side-channel and fault attacks work just as well against post-quantum implementations, and much more dedicated research is still needed for this new generation of algorithms.

Quisquater’s closing line, verbatim:

“Security is never complete. No winner.”

Reflection

My day-to-day work — FastAPI/Django backends, Postgres/Mongo/Firestore databases — doesn’t involve designing chips or smart cards, but this lecture changes something concrete in how I think about a system’s chain of trust: any secret that “lives” in hardware — a YubiKey, a cloud HSM, a TPM, or even a phone’s secure enclave used for 2FA — inherits exactly this class of risk, and it’s a risk no software layer above it can compensate for. If I recommend hardware keys (FIDO2/WebAuthn) tomorrow to protect the AI lab’s administrative access, it’s worth remembering that “it’s hardware” isn’t a synonym for “it’s immune” — the right question is which class of attacker (I, II, or III, in IBM’s taxonomy) that specific device is actually designed to resist.

The CRT-RSA case also leaves a lesson that translates directly to software: an optimization that looks purely about efficiency (CRT to speed up RSA) turned out to be exactly the surface a physically capable attacker could exploit. It’s worth asking the same question of my own systems — is some performance optimization (caching, batching, short-circuit evaluation) unintentionally creating an observable information channel, a response-time difference between a valid and an invalid login, say — the software equivalent of a timing attack?

Finally, the homomorphic-encryption framing is the piece that connects most directly to my database stack. Postgres/Mongo/Firestore all assume today that the server sees plaintext data. It’s worth mapping, at least as a thought experiment, which queries in a real system — evaluating sensitive student data, for instance — could benefit from a model where the server never sees the decrypted value, even though today’s cost (compute, ~60× data expansion) makes it impractical for most real cases right now.

Tools & references

1. Jean-Jacques Quisquater (UCLouvain), “Hardware Security” — lecture slides · Fab Futures Cybersecurity 2026 · 13 Jul 2026
2. Joye, M., Lenstra, A. & Quisquater, J.-J. (1999). Chinese Remaindering Based Cryptosystems in the Presence of Faults. Journal of Cryptology, 12(4), 241–245.
3. Piret, G. & Quisquater, J.-J. — differential fault attack against AES/Khazad · CHES 2023 Test of Time Award
4. Auguste Kerckhoffs, “La Cryptographie Militaire” · Journal des Sciences Militaires, January 1883
5. BadUSB · Wikipedia
6. Field-programmable gate array · Wikipedia
7. nGRAVE — air-gapped, QR-only cryptowallet
8. Introduction to Homomorphic Encryption · Zama
9. Operation GUNMAN (U.S. Embassy, Moscow, 1984) — IBM Selectric bug · Crypto Museum