18: Fault injection

Fault injection breaks the assumption that

The hardware behaves as expected

Faults are injected by

Subjecting the target chip to adversarial conditions

Typical threat model for fault injection attacks

• Physical attacker

• Capable of tempering the underlying hardware

Use cases of fault injection

• Recovering cryptographic keys

• Bypassing firmware signature verification

• Unlocking locked functionality (software and hardware)

Clock glitching

• MCUs (and other components) may run from external clocks

• We can manipulate the target’s clock - mismatch between systems component

External clocks

• Synchronises operations across a system

• Assumed to be stable

Clock glitching example approaches

• Injecting single pulses

• Temporary overclocking

• Stretching clock cycles

Voltage fault injection

• Embedded devices require a constant voltage power supply, assumed to be stable

• Can temporarily over or under volt

Over or under volting

May corrupt data, skip instructions, and more

Voltage fault injection example approaches

• Programmable power supply

• Waveform generator

• Crowbar glitching

Electromagnetic Fault Injection (EMFI)

• Power supply is not the only way of receiving voltage

  • ICs are sensitive to electromagnetic interference

• Typical setup: attacker circuit creates EM via coil, EM field injects energy in victim circuit

• Allows to inject localised faults - position of probe is important and changes glitch behaviour

Laser Fault Injection

• Exposing a chip to high energy lasers can inject faults

• Traditionally very expensive but becoming more accessible

• Requires precise positioning:

  • Location (similar to EMFI)

  • Direction (frontside, backside, lateral)

Fault models: Categorisation

• Type

• Time

• Location

Fault categorisation: type

• What exactly goes wrong?

• Skipped/modified instructions, flipped bits, read all zero/all one, etc

Fault categorisation: time

• How long are things going wrong?

• Number of affected cycles/instructions

Fault categorisation: location

• Specific bit/byte/word/instruction or random position/width

• This is in relation to the target program, not the physical attack location

Arm (Fault Injection)

Setting the glitch generator in a ready state, waiting for the trigger

Glitch trigger

The signal to get ready and initiate the glitch process

Glitch delay

Time to wait between trigger signal and glitch

Glitch/pulse length

Duration for applying the glitch

EMFI Location

xyz coordinates for coil location

EMFI Pulse Strength

Intensity of EM field

Finding glitch parameters

• Start with controlled target - toy program with victim functionality and trigger signal

• Iteratively test delays/lengths - visualise results

• For localised glitches, create a fault heat map over coordinates

Detection of injection of fault

• Detection based

• Monitoring the system at runtime

• Example: glitch detector

Detection of faulty result

• Detection based

• Calculate result multiple times and verify correctness

Detection of unusual usuage patters

• Detection based

• Could use an error counter

Add randomisation in time domain

• Algorithmically based

• Makes attack more difficult

Verify validity of data before output

• Algorithmically based

• Relevant for attacks on cryptographic schemes

Defences can introduce

Additional weaknesses

Bellcore attack

• Classic example of differential fault analysis

• Attacks classic RSA and RSA-CRT signing

  • Requires multiple faulty signatures for classic RSA

  • Requires one for RSA-CRT

• Faults exponentiation in signature creation

  • Resulting in faulty signature, breaking cryptographic guarantees

Generic attack on keyed algorithms

• Traditional attack against cryptographic protocols

• Target: any encryption c=e_k(p)

• Steps, repeat for each bit i of k:

  • Get fault free ciphertext c

  • Get ciphertext c’ while faulting bit k

    • If c == c’: fault had no effect, bit i is 0

    • If c ≠ c’: fault had effect, bit is 1

Generic attack on keyed algorithms assumptions

• Attacker can repeatedly issue encryptions with controlled plaintext p

• Attacker can precisely target any bit of k with a “stuck-at-zero” fault (0 → 0, 1 → 0)

Glitching the Xbox 360

• Xbox 360 only runs signed firmware

  • Verified through bootloader chain

• Attack strategy:

  • Place unsigned firmware NAND flash

  • Glitch the memcmp used for comparing the NAND firmware’s SHA value

  • Allows to execute arbitrary code

NRF52 APP Product Bypass

• App project is a code readout protection mechanism

  • Disables JTAG access via hardware register in flash (UICR)

  • Reenabling JTAG deletes firmware in ROM

• Attack strategy:

  • During hardware bring up, glitch read from flash

  • Hardware believes APP protect is disabled

  • Connect debugger and dump firmware

  • Optional: reflash firmware without AppProtect