Home >

Electromagnetic Fault Injection Made Easy with PicoEMP

Colin O'Flynn - Watch Now - Duration: 33:21

Electromagnetic Fault Injection Made Easy with PicoEMP
Colin O'Flynn
Electromagnetic Fault Injection (EMFI) is a powerful method of injecting "faults" into devices, which can be used for both security and safety evaluations. Various platforms for EMFI exist (including the ChipSHOUTER tool Colin has designed), but they are often overkill when it comes to performing basic work or trying to get started with EMFI. This talk introduces the PicoEMP, a low-cost EMFI tool Colin designed and released as open-source hardware. Coverage of the theory behind EMFI along with how to build your own PicoEMP will be covered, including some recent examples of real-world usage.
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

GillianM
Score: 0 | 2 months ago | 1 reply

Hello Colin,
Thank you for your talk! I'm posting as a follow-up to the Q&A session to see if you are able to send links to articles/sites with ideas on how us firmware developers can be on the defense to such attacks.

Colin_OFlynnSpeaker
Score: 1 | 2 months ago | 1 reply

Hi Gillian,
These types of attacks are typically looking for "fault injection mitigation" strategies. Basic strategies are relatively well-known, Jasper & I have a few in Chapter 14 of our book too for example. You can find a few examples in the Trusted Firmware-M bootloader I mentioned - a short overview is at https://www.trustedfirmware.org/docs/TF-M_fault_injection_mitigation.pdf, but if you look into their code base there is more examples there. More advanced countermeasures can sometimes take advantage of hardware features. There is a whole area of research around "code flow integrity" - some of this is protecting against code flow changes due to software injection, but some of it protects hardware injection too. This can be anything from pointer integrity to validating things like the cycle count is what you expect at a certain point in time. For many of these protections you could bypass them with multiple glitches, but the reality is that most systems still have no protection. So if you're putting a little bit of thought into this & making life a little hardware, you are probably way ahead of most other designs out there.

On more serious devices you can have glitch detectors too. Basically the glitches happen due to either timing violations (the timing violations often caused by voltage perturbations), or directly flipping bits in static registers. Glitch detectors are just the same sort of digital circuits but they simply sit there confirming there is no invalid value loaded (checking for static bit flipped, invalid value loaded into a shifter, etc). They may also look for the actual signal inserting the glitch (such as a bright pulse of light that should never exist on the chip surface, or a strong EM wave). The hardware detectors are less common in generic micros but some have them as part of a security subsystem - the EFR32MG21A/B from Silicon Labs has glitch detectors in the trusted 'secure element' subsystem. If you attempt to insert a glitch during certain operations (such as any crypto operation) the subsystem will return an error.

On firmware you can do some minor glitch detection too. If you have very sensitive operations, you can for example add some long for() loops around them that simply increment a variable, and at the end of the loop you confirm the variable has the expected value. Someone trying to insert glitches into your sensitive operation are likely to accidently hit your "mine". Reacting to this error can be tricky though - if an attacker can try forever to hit the right spot, you're still vulnerable. But if you can slow them down (maybe you just reboot, and the reboot process takes some time) or even erase sensitive data they are much more effective.

Of course anything with firmware be careful of the compiler - I really love godbolt.org or testing these sorts of things quickly. Hopefully the above gives you some ideas of what is out there - there is no "easy" solution I know of yet, it still tends to be a lot of tuning for specific devices or use-cases it seems.

GillianM
Score: 0 | 2 months ago | no reply

It is great to know all these strategies. Thank you for the detailed answer!

Mark_Tuma
Score: 0 | 2 months ago | 1 reply

Hi Colin,
That was a really interesting talk, thank you. When you do an attack is it right to assume that all sorts of things are going wrong on the chip and you just happen to get lucky with e.g. the RSA demo producing what you want? Or can you target specific peripherals or chip components based on where you place the probe?
Thanks,

Colin_OFlynnSpeaker
Score: 0 | 2 months ago | no reply

One use-case for EMFI is just "see what goes wrong" - in a lot of designs this may include for example some failsafe mode that cannot be externally triggered (there is a paper called BadFET showing this - https://www.usenix.org/system/files/conference/woot17/woot17-paper-cui.pdf). My demo on the RSA one is a "cheat" as it sits there in a loop doing RSA signatures (normally you wouldn't do that). In reality you would need to trigger on the location of the RSA - this isn't as hard as it sounds, since RSA is so slow this glitch can be easily applied.

But more realistic use-cases always need a careful test of the trigger conditions. My example of the car ECU one was bypassing a password check which required me to figure out when the password check is happening. This isn't as difficult as it sounds since you often have lots of external information (when I sent the password, when it responds, if I can see power usage differences). You can see this example at https://colinoflynn.com/2020/11/bam-bam-on-reliability-of-emfi-for-in-situ-automotive-ecu-attacks/.

The other link in the comment above to Lennert's example also shows using EMFI with specific timing. So sometimes it can be as easy as triggering some invalid mode, but most of the time it requires a lot of effort to get there.

Erwin
Score: 0 | 2 months ago | 1 reply

Awesome presentation!
I didn't have the time so far to check out all the resources you mentioned in your presentation but is this PicoEMP more or less an academic approach to show the technical possibility to do EMFI or ist it ment for real application testing. I was involved in some ChipCard OS development some years ago and remember that our crypto experts had much more expensive tools for hardening our hardware and software against such attacks. So is it nowadays possible to achieve this goal with hardware like PicoEMP?

Colin_OFlynnSpeaker
Score: 0 | 2 months ago | no reply

The primary goal of it is for educational, including research and evaluating your own designs against FI. But even with some effort one can push it towards more real-world usage - Lennert Wouters' demo that I mention in the presentation shows using PicoEMP on an (unhardened) microcontroller to circumvent the security settings (https://github.com/KULeuven-COSIC/SimpleLink-FI/blob/main/notebooks/5_ChipSHOUTER-PicoEMP.ipynb for direct link).

Colin_OFlynnSpeaker
Score: 0 | 2 months ago | no reply

Let me know if you've got any questions - I'll be doing a live/video Q&A on April 25th at 13:30 Eastern, see https://www.embeddedonlineconference.com/meeting/Live_Discussion_Electromagnetic_Fault_Injection_Made_Easy_with_PicoEMP to attend.!

OUR SPONSORS