Digital car

Security Highlight: Tesla Hacks and Device Security

KU Leuven’s security research group on Computer Security and Industrial Cryptography (COSIC) has a strong track record in studying Tesla security, and demonstrated attacks on a Model S in 2018 and 2019. Now they’ve done it again, applying some new techniques to break a Model X using 2 design flaws, both exploiting a lack of authentication. The first flaw concerns key fob software updates. In order to get a car unlock code from a key fob, the researchers first patched the key fob with an unauthenticated firmware update. The acquired unlock code gives access to the car but is not sufficient to drive it. For this, they exploited a second vulnerability: the apparent lack of authentication when pairing another key fob to the car. After performing this through an unauthenticated maintenance procedure with a spare key fob, they succeeded in driving the car.

One could argue that this is yet another attack on a car lock, which only underlines that the automotive industry is still not up to date with modern-day security. But there’s also something more interesting is at play here: the adversarial use of a trusted hardware security feature (secure enclave) in a broken platform.

In this attack, it was possible to generate a valid unlock code even after the unauthorized firmware update, because the overwritten firmware left the secure enclave in the chip untouched. The secure enclave still had its keys and cryptographic implementations available to generate valid security codes. However, the firmware update did change the crypto protocol, allowing the unlock code to be sent without meeting verification conditions. Here, we can guess that the original firmware would verify the car’s authenticity before sending the unlock code. The researchers have proven that separating the security logic from the crypto implementation is risky and that the entire crypto protocol should have been implemented in the secure enclave. This is an important lesson that may also apply in alternative situations, such as mobile phones that keep their crypto implementation in a Trusted Execution Environment (TEE). Attackers may be inspired by this attack and apply the concepts elsewhere.

For this specific case, a solution is underway as Tesla is updating its system. In more general terms, developers should reconsider their system’s security when it relies partly on hardware security. The key question here is: Would different software in the “normal world” be able to degrade the strength of the “secure world”? In other words: would a compromised application or operating system (OS) be able to abuse the security features of a TEE (or other secure enclaves) to break the solution? While a well-designed and implemented solution would resist such attacks, it is an important question to ask and evaluate.

If you have any questions, contact us at [email protected].

limit
3