# Practical, Low-Cost Fault Injection Attacks on Personal Smart Devices
## 3 Results
### Bcm2837  
The coiled wire was placed 1.1 cm above the chip. The transient fault produced caused the device to reach one of three states: the device does not respond and requires manual reboot; the device may compute a correct signature, and it appears that nothing else is affected; finally, the device may return a faulty signature. In our experiments, the device indeed printed a faulty signature, as shown in Figure 3.  
The privileged signing service is using the default PyCrypto library to perform signing of a message with a private key that is hard-coded in the program. It is important to note that we are using a popular library implementation of the cryptographic primitives and did not implement our own variant. Because the attacker has full user-land control, it is assumed that they are able to utilize all cores of the system and monopolize execution time. This eases the precise timing requirement, as when the spark gap bridges, the cores will be very likely to operate on the user's code.  
In order to learn which areas of the chip are most susceptible to EMFIs, we created the following experiment setup: a central PC was connected to the DUT and was capable of starting and stopping the RSA-CRT program; we recall that the PC acts as a regular user-land attacker but is still able to make the privileged program perform an RSA-CRT operation by using its exposed API. The PC was connected to the EM fault injector as well, to activate its control circuit, that is, to activate it, causing it to start producing EM pulses. Lastly, the PC was connected to an XYZ stage, which controlled the location of the Raspberry Pi and was able to move it in precise increments. This setup is described in Figure 4.  
We started the cartography process by dividing the surface of the chip into a \(5\times 5\) grid. For each point, we activated the EM fault injector, which generated a pulse. As soon as it did, we checked if the device was still operating by checking its sanity outputs to the console, and if not, we checked if the DUT had printed a faulty signature, or had crashed.  
Figure 3: Output of the Raspberry Pi while running a repetitive RSA-CRT-Sign operation from the PyCrypto library. For testing purposes, the program prints every second a _“sanity”_ message indicating the device is still alive and has not crashed.  
After aggregating the results of 19 experiment runs as described above, we created a heat map of the vulnerable points, based on the amount of successful faults we were able to receive for each point in the \(5\times 5\) grid. It is important to note that the point at \((2,3)\) has a success rate of 19 out of 19 attempts, as described in Figure 5, which means that when the coiled wire was placed around that area, a faulty signature was returned to the attacker and the device did not crash, with a success rate of 100%. We assume this is because that is the location of the CPU cores within the SoC which are under heavy usage during the operation. The heat map, overlaid with a photograph of the chip, is shown in Figure 6.  
After determining the most susceptible area that will increase the likelihood of a successful glitch, we ran the experiment an additional 400 times to test that specific point, out of which 258 caused the device to crash, 7 were unaffected and the faulty signature was leaked 135 times.  
Figure 4: Cartography setup. A PC is connected to the XYZ stage’s arm to be able to move the magnetic coil across the surface of the chip, connected via serial interface to the DUT and connected to the EM fault injector to activate it.  
Figure 5: Heat map of vulnerable points after running the experiment 19 times, using a \(5\times 5\) grid. Each cell value represents the number of times a successful faulty signature was returned from the program while the DUT itself continued execution and did not crash.