Hardware Attacks lessons
Why study hardware attacks?
A lock leaks its PIN through timing, one digit at a time, until a constant-time check makes every guess take the same time.
The lock above never shows its PIN. Yet the time it takes to answer gives the PIN away, one digit at a time.
This is a hardware attack: it targets the physical device, not just its software. Anyone holding a device can time it, measure its power, probe its pins and read its chips.
This course shows how these attacks work, so you can see why each defence exists. Every device in it is made up.
A device's attack surface
The attack surface is every place an attacker could get in. On a board, that means ports, pins, chips and the wires between them.
Factories leave debug pins and test pads for loading and testing firmware. Even the supply chain, the route a device takes from the factory to you, is part of the attack surface.
A tour of a real single-board computer's ports and pins as a general example of an attack surface.
Practice: Find the way in
Tap the part of a made-up smart lock board that each question describes.
Side channels
A side channel is something a device gives away by accident while it works. Time, power use, radio noise and even sound can all leak secrets.
A timing attack measures how long an operation takes. The lock in section 1 compared digits one by one and stopped at the first wrong one.
With k possible characters and n positions, brute force needs up to k^{n} guesses. A timing attack needs at most k \times n, because it finds one position at a time.
The early-exit check runs on three guesses, and the stopwatch counts each digit it compares.
Practice: Count the guesses
Work out the most guesses brute force or a timing attack needs for a random code.
Power and electromagnetic leaks
A chip draws a little more current for some operations than for others. Recording that current over time gives a power trace.
Some encryption code does an extra step for every 1 bit of its key. That step shows in the trace, so a single trace can reveal the key: this is simple power analysis.
A power trace from a made-up chip is read operation by operation to recover its key bits.
Differential power analysis combines thousands of traces with statistics to find keys that hide in one trace. The same currents also leak as faint radio waves, which an electromagnetic probe can pick up without touching the chip.
Practice: Read the key from a trace
Set each key bit from a fresh power trace.
Defending against side channels
The fix for the leaky lock is a constant-time check. It compares every digit on every guess, and only answers at the end.
Masking mixes the secret with fresh random numbers each time it is used. The power trace then follows the random values, not the secret.
Random delays only slow an attacker down. With enough repeated measurements, the noise averages out and the leak returns.
Response times for three versions of the check: early exit, early exit with random delays, and constant time.
Practice: Make the check constant time
Drag code pieces into a comparison so it always checks every byte.
Fault injection
Fault injection makes a chip go wrong on purpose, at just the right moment. A chip that misbehaves for one instruction can skip a security check.
A voltage glitch pulls the power supply down for less than a millionth of a second. A clock glitch slips in one clock tick that is too short for the chip to finish its work.
Most glitches just crash the chip, so attackers repeat them with small timing changes. Lasers and electromagnetic pulses can cause faults too.
A made-up lock runs its PIN check three times: once normally, once glitched too early, and once glitched during the jump.
Practice: Time the glitch
Set the glitch delay so the dip lands on the instruction that matters.
Defending against faults
A brown-out detector watches the supply voltage and resets the chip if it dips too low. A clock monitor does the same for clock ticks that come too fast.
Code can defend itself too. It can check twice, add random delays so the right moment is hard to hit, and store "yes" as a long pattern of bits that one fault cannot fake.
The same glitch against a lock that checks twice, and against a chip with a brown-out detector.
Debug ports: UART, JTAG and SWD
Boards often keep the connections the factory used for testing. A UART is a simple serial port, and it often prints messages while the device starts up.
JTAG and SWD are debug interfaces. A debugger plugged into them can pause the processor and read or change its memory, firmware included.
In a finished product these should be locked. Many chips have a one-time fuse that turns debugging off for good.
Each debug connection on a made-up board, with its pins and what it gives away.
Reading firmware from a flash chip
Many devices keep their firmware on a separate flash chip. The processor reads it over SPI, a bus with a clock, a chip select and one data line each way.
A reader clipped onto the chip can send the same read command and copy all of it. Any passwords or keys stored in plain form get copied too.
The defence is to encrypt the flash with a key that never leaves the processor. A copy is then just random-looking bytes.
An SPI read pulls bytes off a flash chip, first stored plainly and then encrypted.
Practice: Match the interface
Match each board interface to its pins and what it is used for.
Locking down the board
Before a device ships, each way in should be closed or guarded. Hiding a port is not enough, because attackers can buy the same board and study it.
Turn off the serial console, or make it ask for a login. Lock the debug port with a fuse, encrypt the flash and only run signed firmware.
Each way into a made-up board is closed in turn.
Practice: Real fix or just hidden?
Sort fixes into real protection and ones that only hide the problem.
Secure boot and the chain of trust
An attacker who can rewrite the firmware can add a hidden backdoor. Secure boot stops this by checking the firmware before it runs.
With code signing, the maker signs each firmware image with a private key. The chip checks it with the matching public key, whose fingerprint is burned into fuses that cannot be changed.
Each stage checks the next before handing over, forming a chain of trust. A version counter in the fuses also refuses old, buggy firmware: this is rollback protection.
A boot chain checks a genuine image, a tampered one and an old one.
Practice: Will it boot?
Decide whether a secure boot chain runs or stops each firmware image.
Hardware trojans
A hardware trojan is a hidden, harmful change to a chip or board. It might leak a key, or switch the device off on command.
Most trojans wait for a trigger: a rare input that normal testing never sends. Until then the chip behaves perfectly.
A tiny logic trojan passes data through untouched until its rare trigger arrives.
Supply chain defences
A chip passes through many hands before it reaches a device. On the way, a part can be counterfeit, swapped or changed.
Buy parts from authorised sellers and inspect them, for example with X-rays. Many chips also hold a unique key, so they can prove they are genuine: this is attestation.
A chip's journey from design to device, with the risk and the check at each step.
Practice: Name the threat
Name the kind of hardware attack in each scene.
Tamper resistance
Physical defences come in three kinds. Tamper-evident seals show that a case was opened, and tamper-resistant coatings make the chips hard to reach.
Tamper-responsive devices fight back. Sensors such as a fine wire mesh notice an intrusion and wipe the keys at once.
Payment terminals and hardware security modules use all three. A stolen device should give up nothing.
An attacker opens a made-up payment terminal and meets each layer in turn.
Defence in depth
No single defence is perfect. Defence in depth layers several, so an attacker who beats one still meets the next.
Give each device its own keys, too. Then breaking one device does not unlock all the others.
Four attacks run through four layers of defence, then again with one layer missing.
Practice: Plan the defences
Pick a few defences that stop every attack on a made-up device.