The Black Hat conference always brings up interesting and current research within the device security industry. Jasper van Woudenberg attended the latest conference, where the research by Lennert Wouters caught his attention.
Lennert Wouters of the Computer Security and Industrial Cryptography research group (COSIC) studied the security of the Starlink User Terminal. After some printed circuit board (PCB)-level reverse engineering, he found a serial port and observed various bootloaders, U-boot, and Linux running on the device. However, there was no obvious way to gain further access: The boot images were signed, U-boot did not take serial input, and the development login was disabled.
These are all the standard practices to be expected from an embedded system that has to resist logical attacks. The question is whether it can also resist fault injection (FI) attacks.
Lennert opted for voltage fault injection (VFI) first, using ChipWhisperer Lite. This device uses the crowbar glitching technique, which momentarily shorts voltage at the common collector (VCC) and ground. The downside is that it is only able to target a specific time, not a specific location on the die. However, electromagnetic fault injection (EMFI), laser fault, or body-bias injection (BBI) require positioning over the chip, which presents some physical challenges for the XYZ stage, because the PCB is very large.
With VFI, he managed to fault a shell script that determines whether a device is in developer mode or not, giving shell access. The problem is that it had a low success rate and needed to fully boot (12 seconds) for each fault attempt. To solve this, Lennert aimed the VFI at the Trusted Firmware A (TF-A) bootloader. He found that with two glitches in BL1, he could bypass firmware signature verification and load arbitrary BL2 code.
So far, the story follows a very similar process to what we do in our device vulnerability testing. Next, Lennert took it one step further by creating Modchip — a fitted custom PCB to inject the fault and load the attacker firmware. The Modchip can be easily soldered to Starlink, and automates the entire FI process, giving the attacker “automatic root” on their Starlink Terminal.
Another interesting note is the use of FI simulation to simulate single and double instruction skips, based on the Unicorn Engine. This is the same approach we utilize in Keysight FiSim. Lennert noted that although he could find double instruction skips that caused the same effect as on the hardware, the actual fault there was likely different. This aligns with ongoing Keysight internal research, where instruction-skip simulators are compared to netlist-based simulators.
One corollary from the research is that the TF-A BL1 is vulnerable to fault injection. This means that not only Starlink is vulnerable, but potentially all devices using TF-A without additional FI countermeasures. This aligns with the TF-A documentation, which talks about FI countermeasures in software and states “At the moment TF-A doesn’t implement such mitigations.” Interestingly, for TF-M there is some ongoing work in hardening against FI.
For more information on how to implement software countermeasures, see our white paper Secure Application Programming in the Presence of Side Channel Attacks, or contact Keysight for countermeasure validation.