Preventing Car Hacks (Part 2): Six-Point Checklist of System Design Techniques
In part 1 of this blog series, I addressed eight common vulnerabilities and explained 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 today’s post, I’ll provide a six-point checklist of system design techniques to help prevent hacking.
1. Compartmentalize—Simply put, isolated systems prevent hacking. When you separate a car’s entertainment and auxiliary systems from essential systems such as braking and steering, hackers cannot use the entertainment system as an attack surface (entry point). Compartmentalization has long been standard operating procedure in Network Operations Centers (NOCs). Monitoring systems that are enabled for only one-way communication, such as by deliberately breaking transmit pins on cable connectors, cannot fall prey to hacker tricks such as removing NOC log files in order to hide their activity. Likewise, smart car designers must enforce the separation of essential and non-essential systems.
2. Segment network traffic—Although it’s tempting to think that securing the network services and allowing connections only to trusted services will provide all the protection a car’s systems need, you should take the pessimistic view that eventually, they could be compromised. Therefore, it’s critical to practice defensive design techniques to segment network traffic so that every system is isolated. For example, by segmenting a car’s hot spot network from its infotainment system, you ensure that even if one system is breached, the other systems continue to operate safely, as intended.
3. Firewall the car’s network—At first glance, it seems that the firewall that protect wireless carriers’ networks should serve to protect a car from receiving unauthorized communications. After all, if you’ve protected the car’s port through which it receives all communications, what more is there to worry about? Unfortunately, a lot.
Stingray devices enable anyone—from small, local sheriff’s offices to large intelligence agencies, as well as independent hackers bent on mischief—to set up a simulated cell phone tower that closely mimics a legitimate wireless carrier’s cell tower. The stingray forces phones, and by extension cars’ apps themselves, to connect and communicate as if to the expected device make—the car company that is (not an OEM that supplied the actual chip). The results could be as “benign” as monitoring a car’s location or as serious as taking control of the vehicle.
The most effective preventative measure you can take is to firewall the car’s systems so that nothing on the Internet can talk to the car. When you allow communications only with the device maker, you’ve added a strong, broad layer of defense against well-known and zero-day exploits.
4. Prevent timing attacks—When you use strong cryptographic algorithms with sufficiently large hashes, it’s very difficult and computing-intensive for hackers to break the crypto by brute force. But what is often overlooked when designing in security is the ease with which timing attacks can be performed by using flaws in signature verifications and integrity checks. By timing when a device’s code detects an unexpected value, an attacker can simply repeat-and-iterate to reveal how close to correct an outright guess for something such as a password is. To mitigate the risk of timing attacks, you can use either a fixed processing time (which must therefore be equal to the processing time for the longest execution path) or add a random delay to all execution paths.
5. Cryptographically pair the car and app—To ensure that presumably-secured messages between a car and its app are actually being transmitted over the same channel, it’s not enough that the car and app simply authenticate with a service. Instead, you should employ cryptographic pairing between the car and app, which applies another layer of protection during the authentication’s exchange of the shared secret. This ensures that the message is legitimate and that it should be exchanged between the car and app. Mocana NanoCrypto™ provides a rich selection of cryptographic technologies, and FIPS 140-2 level 1 government-certified binaries for many popular platforms.
6. Cryptographic pairing, part 2—On the face of it, it may not seem that a lack of cryptographic pairing is such a big problem. However, the auto industry has already seen hacks such as using devices to capture key fob entry codes to be used at a later time to unlock a vehicle, and tracking cars through wireless tire-pressure sensors. Such vulnerabilities can easily be exploited for even further harm, such as sending incorrect sensor information and thereby causing the car to take inappropriate action that could cause a crash. Mocana NanoCrypto™ can help prevent such hacks.
When you combine good system design techniques with code that’s designed to prevent common classes of vulnerabilities (as I discussed in part 1 of this series), you’ve effectively prevented many, many car hacks. Please add your comments, and stay tuned for part 3!
If you need more motivation to get started on this...watch this video to get inspired!