Preventing Car Hacks (Part 1)

Preventing Car Hacks (Part 1)How can you be sure that your smart car, with all its fabulous features, isn’t the victim of a publicly-disclosed white hat hack? Or even worse, a black hat hacker who causes real harm to life and limb?

In this blog series, I’ll draw from my many years of security work with safety critical devices, and share some key strategies for increasing the security of a car’s system and for preventing car hacks.

  • In today’s post (part 1 of the series), I’ll discuss specific vulnerabilities and explain how to use our Mocana Security of Things Platform to easily secure a car and prevent the sort of exploits that make headline news.
  • In part 2, I’ll present specific design goals that are critical to building hardened systems that are resistant to hacking.
  • Part 3 continues the theme of designing in security. Hacks are made possible by code vulnerabilities, but by paying close attention to how you design, build, and test the code, and physically secure devices, you can minimize the potential for exploits. 

So now on to today’s topics! Here’s an eight-point checklist of vulnerabilities to guard against.

1. Secure the crypto foundation—All cryptography relies on a strong random number generator (RNG) seed. If you have a weak seed, it’s an easy matter to defeat any and all measures you might otherwise take to ensure security. In addition to using a strong RNG, you should protect the device's private keys by using hardware, such as a TPM (Trusted Platform Module) or other secure hardware elements. Mocana crypto products provide a secure RNG seed, although as with all software solutions, the time to generate the seed can be a performance concern. You can replace or strengthen Mocana's software RNG with a hardware seed. And to secure the private key, be sure that it is neither exportable from the hardware nor loaded into the hardware. In the world of car security, this means that the private key should be generated inside the car and be immutable. All the Mocana Security of Things Platform products that use public key encryption are TPM/TPM-like friendly.

2. Secure the boot process—To prevent tampering, you must strongly protect devices’ boot processes. So for all of a car’s devices that have flash or reprogrammable storage, be sure to use a strong digital signature algorithm, such as ECDSA P-521. Perhaps even more important than the signature algorithm is the hash algorithm, which is the weak link in the signature. Because ECDSA P-521 supports multiple hash algorithms, an effective strategy can be to use ECDSA P-521 to sign two non-overlapping hash signatures. Mocana NanoBoot™ provides all the tools and firmware source code you need to perform secure pre-boot verification on your connected devices.

3. Secure all network services—This is such a vital concept that perhaps it belongs at the top of the list: secure every communications system between the vehicle and the outside world. There are numerous, real-world examples of devastating hacks to mobile systems. To avoid falling prey to such an attack, assume that links are unsecure, that data can be stolen, and that the communication scheme can be altered; and build in appropriate countermeasures. Keep the communication connection simple and secure. Allow only the strongest security for data in transit, such as AES-GCM. And omit all unnecessary “security features,” such as the TLS heartbeat that lead to the Heartbleed Bug. Mocana NanoSSL™ helps defeat eavesdropping on wired or wireless connections and can be used to deliver secured software packages from and to authenticated endpoints. You can further enhance security by incorporating Mocana NanoSec™, which is an IPsec/IKE solution for resource-constrained environments, and for when you need a FIPS-certified cryptographic engine.

4. Employ mutual authentication—In addition to securing the actual data that is transmitted to and from a smart car through the authorized cloud services, it’s important that the smart car and cloud services use strong, certificate-based, mutual authentication. When both the server and client authenticate themselves to the other party, both parties can be sure that they know with whom they are communicating. With this added layer of security, services-to-car authentication prevents attackers from successfully impersonating a wireless carrier; and car-to-services authentication prevents attackers from impersonating a smart car in order to reverse engineer the cloud service with the intention of gaining a foothold that could be used to attack an entire fleet of cars. Mocana NanoCert™ Client lets you automate the certificate provisioning during manufacturing, periodically update the smart car in the field, and revoke certificates anytime.

5. Prevent replay attacks—Although a replay attack might be amusing and harmless, such as changing the radio station, replay attacks could seriously compromise safety, such as issuing commands to open the doors while a car is moving. Other potential replay attacks are downgrading a system’s firmware or transmitting outdated map data. Simply signing and securing messages isn’t enough. You must employ countermeasures such as using session tokens or timestamps, limiting session times, and denying concurrent logins to a car’s system. The combination of Mocana NanoBoot™, Mocana NanoUpdate™, and Mocana NanoCrypto™ provides extensive protection against replay attacks.

6. Ensure data integrity—It’s not enough to simply secure network services. You must also make sure that the data that’s received has not been tampered with. For example, if a car receives mapping data from Google, you must ensure that the data is actually coming from Google. Data certification and verification is key, and multiple layers of defense, such as signing the map data to ensure that it is really safe and true map data, provide added security that is especially important in the case of self-driving cars. If there is a failure in one layer, the next layer can recover and prevent a system compromise. Mocana NanoCrypto™ provides a rich selection of cryptographic technologies, and FIPS 140-2 level 1 government-certified binaries for many popular platforms. Pair it with Mocana NanoUpdate™ to ensure data integrity during updates.

7. Prevent runtime tampering—With car systems receiving data while in operation (Google and Apple are coming to our dashboards!), it’s imperative that the operating systems are appropriately hardened to prevent runtime tampering. For example, Mocana offers a stronger version of Android, KeyROM™. KeyROM has strong compartmentalization, and further extends the security of Android SE. Additionally, Mocana offers fine grain control flow integrity (CFI) to prevent arbitrary code execution. Building in such security ensures that smart cars cannot be hacked and that they are safe and secure.  Mocana NanoDefender™ protects against zero-day attacks by learning an application’s call flow, monitoring that call flow during runtime, and stopping application execution if an unexpected system call or function call occurs.

8. Deliver updates securely—Although it’s said that only two things in life are certain (death and taxes), updates should be added to that list! USB thumb drives are convenient, inexpensive update delivery systems. But to ensure security, the data on the drive must be digitally signed in a secure, future-proof manner, the same way you’ve (presumably) secured the boot process. The solution to the recent Jeep hacking was to deliver a firmware update on a USB thumb drive, which should put security experts on the alert. If designers take an optimistic view and don’t implement the strongest security, updates can be just as problematic as the issues they’re meant to solve. But I know it’s possible to provide secure provisioning and updating via USB thumb drive. I hold patent # 8,214,885, “Managing network components using USB keys,” which proves the feasibility of using this inexpensive update delivery mechanism in a secure fashion. Mocana NanoUpdate™ enables automatic, secure delivery of messages and firmware images to field devices.

 

By actively working to prevent common classes of vulnerabilities, you’re well on the way to preventing car hacks. Please add your comments, and read on to part 2 of this series!