Creating advanced driver-assistance systems (ADAS) and self-driving cars is a substantial technical challenge. Securing these designs is also challenging, but security hardware can make this task much easier—if it works.
Typically, the root of trust starts in hardware with keys that must be protected and security hardware that provides secure boot support. ARM’s TrustZone is one implementation that provides this support. TrustZone technology is at the center of ARM’’s security message, so compromising this system would have a significant impact on automotive security.
On that front, researchers at Columbia University succeeded in attacking a security-oblivious design of a TrustZone-based ARM system-on-chip (SoC) implementation by compromising the Dynamic Voltage and Frequency Scaling (DVFS) support (Fig. 1). Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo presented their paper, CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management, at the 26th USENIX Security Symposium in Vancouver, BC, Canada.
1. Columbia University researchers were able to use the Dynamic Voltage and Frequency Scaling (DVFS) support to induce bit-level faults due to overclocking.
With the DVFS, the operating system is able to vary the speed and performance of the processing cores to optimize power utilization. Reducing the performance or stopping cores can significantly extend the battery life of a system. As it turns out, twiddling the DVFS in ways it wasn’t intended can cause errors to occur that could be used to compromise the security system.
Essentially, the approach changes bits in the system indirectly because of how DVFS works. The DVFS design was done independently of the security implementation, since timing or voltage errors should not, in theory, affect the security support. TrustZone is designed to prevent a variety of other types of attacks.
Nailing Down CLKSCREW
The CLKSCREW attack isn’t necessarily easy, especially when implemented using software. For example, an attack must be implemented such that the code under attack is modified, but not the attacking code. Likewise, the attack should not perturb other software like the operating system. This type of attack requires very precise timing to induce a fault in the desired code (Fig. 2).
2. The steps for compromising the system include (1) clearing residual states, (2) and (3) profiling for an anchor, (4) pre-fault delaying, and (5) and (6) delivering the fault.
In the CLKSCREW attack, the voltage regulators are pushed beyond the operating limits. Another way to mitigate this type of attack would be to implement different power domains for the security and system. Other hardware and software methods can prevent this type of attack, so it’s unlikely that this specific mechanism can be exploited in automotive systems at this point.
The researchers pushed the attack to the level of plausibility. Additional work could be done to improve the types of possible attacks as well as defenses. The challenge is that mitigating such an attack on existing hardware can be difficult, but would be significantly easier for new designs. Hardening the power-management system software will help, because most applications will not have direct access to power-management hardware.
On the other hand, the attack methodology highlights the importance of security design and implementation, especially since this attack could be done without physical access to the device. It also means that modular design tools may require additional review of how components are related to the security system, even indirectly.
The challenge for automotive designs is that implementations must be designed to last for decades. Software issues can be addressed with over-the-air (OTA) updates. However, hardware issues will likely require hardware replacement, which is expensive and leaves a system open to attack until the change is made.