Electromagnetic Fault Injection

A Closer Look

Electromagnetic Fault Injection (EMFI) is a powerful method of inserting faults into embedded devices, but what does this give us? In this article, Colin dives into a little more detail of what sort of effects EMFI has on real devices, and expands upon a few previous articles to demonstrate some attacks on new devices.

This month I’m going to be covering electromagnetic fault injection (EMFI) in detail. I used EMFI as part of my May 2019 article (Circuit Cellar 346) which discussed how an attack against a USB stack could be used to leak sensitive data. I left the details of how EMFI works for a future article, and that future is now.

The general idea of fault injection is straightforward. We believe computers to execute code as we request, but that isn’t always the case. I want to give a quick overview for anyone new to my column this month on what fault injection means. Fault injection is a powerful attack because our security code typically includes something like Listing 1—in this example checking a firmware image has passed validation tests.

if (check() == 1){
load_firmware();
} else {
panic();
}

LISTING 1 – This C code is an example of validating some firmware image, which calls a routine check() to validate a signature.

Looking at an assembly version of this in Listing 2 should make it clear how easily this test could be bypassed if we had some magic powers. Assume we could skip instructions (cause them not to be executed) or corrupt values. Both of these powers would allow us to break the security assumptions. Bypassing instructions works because, for example, we could skip the branch instruction. But we could also skip the load of r0 with the comparison value (“1”), resulting in the function call return value compared with a previously loaded value of r0 (in this case it was previously loaded with “0”).

ldi r0, 0
ldi r0, 1
rcall check
cmp r4, r0
bne fail
rcall load_image
ret
fail:
rcall panic
ret

LISTING 2 – A synthetic disassembly example of Listing 1 (it’s not a real compiler output), but the idea is you can see various ways to bypass the check with fault injection.

Corrupting values in memory could allow us to change return values or flags. This can be powerful when specific “magic values” are being used, and if we corrupt those magic values the system may go into a less secure failsafe mode. This was used in bypassing the NXP Semiconductors LPC series microcontroller (MCU) read-out protection, which I walked you through in my September article (Circuit Cellar 338).

So, if fault injection is so useful, how can we perform it? One of the most powerful methods is the use of strong electromagnetic fields in a technique called electromagnetic fault injection (EMFI). Let me walk you through how this works.

HOW EMFI WORKS
The objective of EMFI is to ultimately inject a voltage onto the structure of the die itself. This can cause both persistent changes—such as bit flips in a register or SRAM—or temporary errors in reading voltage levels. With EMFI this is done with a quickly changing magnetic field. So, what we need is a method to generate the strong field. The device that generates this field is our EMFI tool.

The “business end” of these tools use some form of a coil in combination with a high permeability material, normally a ferrite. This ferrite is designed to concentrate the magnetic flux in a smaller area, making it possible to flip bits in part of the memory without crashing the entire device. A close-up of such a tip is given in Figure 1. Here the ferrite core is 1 mm in diameter.

A typical drive waveform for these tips is given in Figure 2. You’ll notice the coil is driven to high voltages (400 V) over a short period of time. This is done by using a capacitor bank, which is connected across the coil. A general block diagram of this is shown in Figure 3. Driving this coil requires a high-side switch to avoid keeping the output coil “hot” all the time. You can imagine it wouldn’t be very safe to have continuously connected high-voltage output. Driving this high-side switch to high voltages in very fast pulses is not a trivial problem to solve—remembering of course the MOSFET gate voltage cannot exceed the typical 20-30 V maximum rating on V_gs the entire time. Which might make you ask: Why is such a high voltage used?

“Nature, unfortunately, is perverse” is the answer to our question. To generate a voltage in the device under test, we need a fast-changing magnetic field, as Faraday’s law of induction would tell us. Generating a fast-changing magnetic field means we wish to go from one field strength to a much higher field strength.

This suggests nothing about voltage, but means we should go from a low current (off) to a high current (on). A relation between the inductance of the coil and the magnetic field strength also exists—a higher inductance would generate a stronger magnetic field flux. But a higher inductance resists the rapid change in current, and requires a higher rate of change of voltage. This forces us to use a higher final voltage. The result is a careful balancing act between reasonably achievable voltage pulse levels, rate of change of voltage that does not blow up the gate driver, the physical inductor size we can achieve, and useful flux density. In practice, this ends up being a voltage in the range of 50-700 V with typical inductor dimensions and material.

Using lower voltages requires careful attention to stray inductance in the design, and when using higher voltages, it becomes difficult to find easily available capacitors and MOSFETs (along with exceeding break-down limits of standard FR4). While this explains the reasoning behind the drive waveforms, how does changing characteristics of the waveform affect the results we are trying to achieve, which typically means incorrect values loaded into internal registers and placed on buses? To understand this, we need to do some experimentation.

GLITCHING SRAM TARGETS
The first experiment I’ll report on is around a large SRAM array. This is actually part of an open-source project I developed called Ballistic Gel, shown in Figure 4. This device has a large (32 Mb) SRAM chip. By downloading a pattern to the device, injecting a fault, and seeing where the pattern flipped bits, we can get an idea of the sort of effects that are possible. One interesting effect is also the coil wind direction. We could wind the coil in either direction. Here I’m using clockwise and counter-clockwise to refer to the wind direction looking into the coil. By the right-hand rule we know the magnetic field will have opposite polarity for these two situations.

Figure 5 shows a graph of voltage the capacitor was charged to for the pulse compared to number of bits that flipped after injection the fault. You’ll notice that a higher voltage causes more bits to flip compared to a lower voltage. I’ve also mapped bits that flipped from 1 to 0 (a bit reset) and flipped from 0 to 1 (a bit set). We can compare the effect of the coil wind direction by looking at Figure 6. This is the same coil, but with the opposite wind direction. You’ll notice there was a noticeable shift in the number of bit resets, presumably the opposite polarity voltage is being injected into the chip itself.

This simple SRAM array can be used to better understand the effect of tip sizes, construction and pulse shape. Because this can also be valuable for comparing various injection methods and devices, I’ve released this as an open-source project. You might find this base useful for playing with other arrays—image sensors and FPGAs are two similar targets that come to mind. Now, with our knowledge of the possible glitchable devices, let’s move to the final target.

GLITCHING MCUS
The normal real objective is to glitch an MCU, and not just a static SRAM array. Doing this requires us to understand the timing of where to insert the glitch, which is often our first problem. In reality, this isn’t as difficult a problem as you’d imagine. If you were attempting to glitch the loading of boot values (including what actions are taken for various fuse bytes), you might simply use the reset line being released as the starting point for your attack. This exact type of timing is what I covered in the LPC attack in my September 2018 article (Circuit Cellar 338). Using the reset line of an MCU is an excellent source of timing. That’s because the boot code often has very predictable timing compared to other options.

Another source of timing can be communication interfaces. I covered using a more advanced attack against USB in my May 2019 article (Circuit Cellar 346). I also mentioned that a “future project” would assist you with these attacks, and I’m happy to report that has now reached a beta status. If you’re interested in using USB for timing fault injection attacks, I encourage you to check out my “PhyWhisperer-USB” project. A link to it on Github is provided on Circuit Cellar’s article materials webpage. This is now a fully open-source (including PCB, FPGA, firmware so on) device capable of being used to trigger glitches from the USB stack.

Besides the attack on the hardware wallet I demonstrated in my May 2019 article, what else can you do with USB triggering and EMFI? In this case you can often read huge segments of memory from the MCU. Another demonstration of the tool attacked the code in Listing 3, which comes from the “SoloKeys,” an open-source FIDO2 hardware authentication token. Once again, I’m corrupting the MIN() comparison, such that it incorrectly uses the large user-supplied value req->wLength to decide how much data to return. Since req->wLength is a 16-bit unsigned integer, I can return up to 64 KB of data following the variable USBD_HID_Desc.

else if(req->wValue >> 8 == HID_DESCRIPTOR_TYPE)
{
pbuf = USBD_HID_Desc;
len = MIN(USB_HID_DESC_SIZ, req->wLength);
}

LISTING 3 – This source code for process USB HID messages comes from SoloKeys github repository.

Looking at part of the listing file from Listing 4, you can see that the variable USBD_HID_Desc is followed in memory by several very sensitive values (signing and other keys). Of course, several unimportant memory values are present too, so I’ve only shown you the interesting ones. But the interesting ones are within the area of memory we can easily dump with EMFI and a USB trigger.

The result of this is that the private key in use is dumped, allowing me to clone the token without physically damaging the device. The token could be returned to a user without them realizing someone else could potentially have access to their account.

.data.USBD_HID_Desc
0x200000bc 0x9 lib/usbd/usbd_hid.o
*fill* 0x200000c5 0x3
//Several removed lines
.bss._key.8357
0x20001ae8 0x20 src/crypto.o
.bss._key_len 0x20001b08 0x4 src/crypto.o
.bss._signing_key
0x20001b0c 0x4 src/crypto.o
.bss.master_secret
0x20001b10 0x40 src/crypto.o
.bss.privkey.8369
0x20001b50 0x20 src/crypto.o
.bss.sha256_ctx
0x20001b70 0x70 src/crypto.o
.bss.transport_secret
0x20001be0 0x20 src/crypto.o

LISTING 4 – This map file shows location in memory of a USB descriptor we can read beyond to get interesting private keys out of memory.

PROTECT THYSELF
So how do you protect yourself? The most difficult problem is if you are trying to simply “fix” problems in vendor supplied parts, such as the glitching the LPC MCU series I demonstrated in my September 2018 article. If an attacker is capable of reading the entire flash memory, it is difficult to keep secrets from them. But some of the faults result in “read past end of memory” type errors. These you can easily prevent with good code practice. In particular, enabling the Memory Protection Unit (MPU) can build ‘barriers’ around your sensitive data. In many cases, you can turn the MPU on to block any access to your sensitive data by marking the entire section as invalid. Accessing your sensitive data requires an “unlock” routine to mark the data as valid again, putting another barrier in the way of an attacker.

But it’s hard to protect yourself without understanding the threat itself. For this reason, I encourage you to experiment with fault injection. You can perform many of these attacks with my open-source ChipWhisperer hardware, which now has many updated tutorials on performing fault injection for breaking both secure code and cryptographic implementations. You can also go “all-out” if you wish to experiment with the EMFI by using the ChipSHOUTER, and now you can even use the open-source PhyWhisperer-USB to perform triggering from USB traffic.

Additional materials from the author are available at:
www.circuitcellar.com/article-materials

RESOURCES
NewE Technology | www.newae.com
NXP Semiconductors | www.nxp.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • SEPTEMBER 2019 #350 – Get a PDF of the issue

Sponsor this Article