A smart card performing RSA gets the arithmetic right every time, until you drop its supply voltage for a few dozen nanoseconds at exactly the wrong moment. Then it produces a signature that is almost correct. Almost correct is enough to factor the modulus and recover the private key.
Most cryptographic attacks in the literature assume the machine works. The attacker sees inputs, outputs, maybe timing or power draw, and reasons from there. Fault injection abandons that assumption. The attacker perturbs the hardware while it computes, on purpose, and treats the resulting garbage as data.
This is the mirror image of the side-channel attacks most developers have heard of. Side channels are passive: measure and infer. Fault attacks are active: interfere and infer. The distinction matters because the standard defence against one is no defence at all against the other.
The 1997 result that opened the field
Boneh, DeMillo and Lipton published a paper on checking cryptographic protocols for faults that has been shaping secure hardware design ever since. Their target was RSA signing implemented with the Chinese Remainder Theorem, which nearly every implementation uses because it is roughly four times faster than the direct computation.
CRT signing splits the work. Instead of computing m^d mod N directly, the device computes the signature separately modulo the two secret primes p and q, then recombines the halves. The two halves are independent, which is where the trouble starts.
Suppose an attacker induces a fault during the computation of the q half only, and the device releases the result anyway. The faulty signature s' is still correct modulo p and wrong modulo q. So s'^e - m is divisible by p and not by q, which means:
gcd(s'^e - m mod N, N) = p
One faulty signature, one greatest common divisor, and the modulus is factored.
No key search, no lattice, no clever number theory beyond a GCD that a laptop computes instantly. The private key falls out of a single corrupted output. Symmetric ciphers turned out to be vulnerable too: Biham and Shamir introduced differential fault analysis the same year, recovering DES keys by comparing correct and faulty ciphertexts.
How you actually make a chip get it wrong
The injection techniques form a ladder of cost and precision.
- Clock glitching. Shorten a single clock cycle so a flip-flop samples a value before the combinational logic feeding it has settled. Cheap, applies only to devices with an external clock line.
- Voltage glitching. Drop or spike the supply rail for a very short window. Also cheap, and effective against microcontrollers where the attacker controls the board.
- Electromagnetic pulse injection. A small coil over the packaged die induces currents locally. No decapsulation required, and it gives spatial selectivity that voltage glitching does not.
- Optical injection. Skorobogatov and Anderson demonstrated in 2002 that a decapsulated chip under a microscope, illuminated with a camera flash through a pinhole aperture, could have individual SRAM bits set or cleared at will. Modern versions use lasers with sub-micron positioning.
- Temperature and body biasing. Slower, less precise, occasionally sufficient.
Attacks against AES illustrate the precision available. In the Piret and Quisquater model, a single byte fault injected into the state between the eighth and ninth rounds propagates through the remaining MixColumns operations in a pattern that constrains the final round key severely. Published results recover that key from a small handful of faulty ciphertexts, in some formulations as few as two.
Why constant-time code does not help
Writing branch-free, data-independent code closes timing and cache channels. It does nothing about fault injection, because the attack does not observe your execution, it changes it. Constant-time discipline and fault resistance are separate engineering problems with separate countermeasures.
Skipping an instruction is often easier than corrupting data
Differential fault analysis gets the attention because the mathematics is elegant. In practice, a large share of real attacks target control flow instead.
A PIN comparison ends in a conditional branch. A secure boot chain ends in a signature check whose result is a single bit. A retry counter is decremented before the attempt, specifically so that pulling power mid-attempt does not grant free guesses. Each of these is one instruction that an attacker would like to see not execute. Glitching during an instruction fetch can turn it into a no-op, and then the comparison that was supposed to fail simply does not happen.
The 2018 wallet.fail research demonstrated the pattern end to end on a popular hardware wallet: glitch the microcontroller during its read-out protection check, downgrade the protection level, and dump the SRAM contents including the recovery seed. The cryptography in that device was fine. The chip was the weak point, and the chip was in the attacker's hands.
Faults without physical access
Two developments moved this class of attack out of the lab and onto shared infrastructure.
Rowhammer showed that repeatedly activating DRAM rows flips bits in adjacent rows. Researchers used this to corrupt an RSA public modulus held in a co-hosted virtual machine's page cache, producing a modulus that was easy to factor and therefore a signature check the attacker could satisfy. The attacker never touched the hardware. They ran memory-access patterns.
Plundervolt went further, using the documented processor interface for undervolting. Software with sufficient privilege could lower the core voltage enough to induce computation errors inside an SGX enclave, extracting AES keys and producing faulty RSA-CRT signatures from code the enclave was supposed to protect from exactly that privilege level. Intel's response was microcode that disables the interface and reflects that state in remote attestation, which is the correct fix and also an admission that the interface was a fault-injection primitive.
Countermeasures and what they cost
| Defence | What it stops | Cost |
|---|---|---|
| Verify before release | The Bellcore attack specifically. Recompute s^e mod N and compare against the message before emitting the signature. |
Small. The public exponent is tiny, so verification is cheap next to signing. |
| Redundant computation | Single faults in the data path, if the results are compared and mismatches suppressed. | Roughly double the work, or double the silicon. |
| Infective computation | Turns a usable differential into random output, so the attacker learns nothing from the faulty result. | Modest, but the constructions are subtle and several published schemes were later broken. |
| Redundant control flow | Instruction skipping. Duplicated branches, flow counters, and no security decision resting on one bit. | Code complexity, and a compiler that will happily optimise your redundancy away. |
| Hardware sensors | Detects out-of-range voltage, clock frequency, temperature or light and halts the device. | Die area and design effort. Standard on certified secure elements. |
| Randomised timing | Makes hitting the right cycle a guessing game rather than a repeatable trigger. | Cheap, and it raises attacker effort rather than removing the primitive. |
Every one of these assumes a single fault per execution. An attacker who can land two faults can target the verification step itself, which is why high-assurance evaluation schemes explicitly consider multi-fault adversaries and why real secure elements combine several of these layers rather than picking one.
When this is in your threat model
Fault injection needs either physical possession of the device or code execution on the same machine. That bounds it. If your adversary can do neither, the attacks above are not your problem and you should spend the effort elsewhere.
It becomes your problem when the device is designed to resist its own holder. Payment cards, transit tickets, DRM systems, game consoles, OpenPGP smartcards, hardware wallets and phone secure enclaves all fall into that category, and it is the reason certification schemes for those products test glitching in a laboratory rather than trusting the datasheet. It is also the reason a hardware security module in a locked rack is a different security proposition from the same cryptography running on a card in a stranger's pocket.
For everyone else, the useful takeaway is narrower. If you write code that runs on a device your adversary might hold, then verifying your own output before releasing it, and never letting one comparison instruction stand between an attacker and a secret, are cheap habits. The attack does not need to beat your cryptography. It needs your hardware to stumble once, and it only has to work on one of the many devices your adversary can buy.
Originally published at havenmessenger.com
