[Gnuk-users] Is the FST-01 vulnerable to fault injection?

Josh Datko jbdatko at gmail.com
Fri Aug 18 22:31:33 UTC 2017


Hi, Josh here, I was one of the presenters of that talk and long-time
lurker.

So that article starts off talking about our presentation but there's
one line in there that makes a transition:

> Here we demonstrate how the hack works without even needing “fault
injection”.

Then as you say, they go into describing a unrelated attack that
recovers the key via SRAM data reminiscence because well, I think most
MCUs don't wipe SRAM on a soft-reset.

I am confident that the STM32F205 (sorry for the slide mistake) is
vulnerable to fault attacks. This shouldn't be that surprising actually
as most generic MCU are. Generic MCUs are not security devices and they
hardly include power analysis and/or glitching protection.

AFAIK you use the STM32F103? It wouldn't surprise me that this MCU is
also vulnerable to fault injection. But there's two parts to this
attack: inserting the fault and causing an exploit. Just like if you
write bad C code that is vulnerable to stack overflows, it may not be
exploitable due to other protections.

What we did is took the F205 and ran the basic glitch attacks from
here: https://wiki.newae.com/Tutorial_A2_Introduction_to_Glitch_Attacks
_(including_Glitch_Explorer) using the ChipWhisperer.

What we could do was: 

- Modify stack variables to unexpected values at run time without
causing a reset or detection
- Break out of a while(1) loop
- Cause non-linear code jumps from code that should have execute when a
PIN check was false to something else (basically jump over things).

We tried to glitch a flash erase with no luck as we wanted to see if we
prevent flash sectors from completely erasing.

Whether this attack is exploitable on your device comes down to 1.) Do
you consider hardware attacks in scope in your threat model and 2.) do
you have any code that is security critical that would fail if jumped
over.

Josh




More information about the gnuk-users mailing list