Avoiding the Risky Ride: 10 Must Haves for Self-driving Cybersecurity

Innovation Blog | October 15, 2018

A malicious agent doesn’t need to dictate an autonomous car’s position to create havoc. They only need to influence the autonomous vehicle’s piloting system through its many sensor inputs to make decisions that a human driver wouldn’t – whether that’s steering into lanes full of traffic, driving through crowded intersections, or purposefully diverting traffic into (or away from) selected locations. Autonomous car hackers could flood a controller with meaningless random data from imaginary sensors. They could feed an empty roadway video signal to compromised cameras. They could interfere with V2X signals so that “green lights” are broadcast to all directions in an intersection. Or they could fool traffic into navigating around false road closures. While a car’s multiple collision avoidance measures may be able to minimize some attempts to subvert the car’s route, at a minimum a successful hack would still cause traffic snarls and fender benders. And highly virulent or impactful attacks could allow a malevolent entity to temporarily shut down a transportation grid and halt the heartbeat of a city.

What to do? While cybersecurity is a mindset and a never-ending discipline, we’ve put together our top ten checklist of things that every autonomous vehicle builder must consider when securing their next generation products, especially those modules that affect steering, braking or motion of the vehicle.

1. Hardware security. Modern CPUs used in autonomous automotive designs have hardware-accelerated cryptography engines and a facility for hardware-secure key storage. Use them. Configuring your system to take advantage of hardware crypto and key storage shouldn’t be a herculean effort. But it is very easy to overlook since software-implemented default mechanisms will work out of the box. Just remember to double-check that you’re using the hardware when you can – the superior performance and security is well worth the effort.
2. Secure boot. Similarly, your hardware should have secure boot capability and if you’re not taking advantage of it you’re making it unnecessarily easy for hackers. A secure boot can drive some low-level architectural decisions but it’s a definitive must-have to ensure that the system executes only authenticated firmware images. This is something that a capable OS vendor should be able to help you design and implement.
3. Encrypt data at rest. You know what bits of data in your system are sensitive – keys, customer data, passwords, logins – just make sure you treat them that way. Data “at rest” (that is, stored for later use) must always be encrypted and decrypted at point of use. Don’t forget to zero-fill any buffers that contained sensitive data before releasing them back to the system. And please use provable encryption standards like AES, Triple DES, or Blowfish/Twofish to secure that data – XORing your data with a disguise pattern is really asking for trouble.
4. Remove backdoors. It’s easy and helpful to build software with backdoors that really help your development team, hidden features that assist your testing and validation efforts, and secret codes or logs that aid your customer support staff. But all of these risk putting insightful internal data and valuable new tools into the hands of the bad guys. The simple joy of developer bypasses or secret Easter eggs will compromise your product. Don’t hide unneeded features, and if you’ve got multiple levels of features, enable them through a securely authenticated and encrypted mechanism.
5. Validate all input. Every developer knows they need to validate program inputs, right? Yes, of course. But unfortunately SQL injection attacks still exist. Embedded engineers tend to be pretty rigorous in validating user inputs but there are still many blind spots in what developers consider to be inputs worthy of validation. Assume that anything the program relies on – even private configuration files, remote APIs, and protected database fields – are filled by keyboard-wielding monkeys.
6. Don’t mishandle credentials. Credential breaches can be one of the most damaging results of a successful hack. On the in-vehicle systems, don’t store credentials in plaintext without appropriate security in place, don’t store credentials temporarily, and consider whether credentials even need to be stored at all. All of these precautions especially apply for any back-end services that your autonomous car may rely on. Assume that the code in your cloud service is talking to malicious and compromised vehicles, and guardedly protect credentials everywhere they are used.
7. Securely update software. Over-the-air updates are a valuable tool for automakers to update cars and even more indispensable for autonomous vehicles. They’re also a necessary part of cybersecurity vigilance, allowing patches to be deployed, and older vulnerable libraries to be updated. But they’re designed to do exactly what hackers dream of doing – replacing existing components of a running system with new ones. Make sure that your OTA software provider is using strict security protocols, that your updates are signed and authenticated, and that all security measures that can be enabled, are.
8. Remove debug assist. Discovering and reproducing bugs encountered in the field is tremendously difficult. Unfortunately, the tools needed to uncover those bugs fly in the face of cybersecurity best practice and create a hacker’s paradise. Don’t leave ssh or ftp on the system, don’t leave any programmer utilities on the disk image, and remove any hidden features from code and configuration files. You may need all those things for development builds, but make sure your production builds are airtight and locked down.
9. Update or remove components. Open source libraries offer lots of functionality, embedded operating systems are chock full of features, and pre-built packages exist to simplify building and configuring software. But these time-saving tools often leave behind remnants – unused components that either nobody knows what they do, or that everyone’s afraid to remove in case they might be needed one day. Those unused modules are just waiting for hackers to misuse them. Cleaning out your closet isn’t fun but it feels great once you’re done – and similarly, you need to perform an audit of all the software installed on your system. Be ruthless in removing things that aren’t needed. And if a component is needed, aggressively update it to the latest, most secure version that has fixed all known vulnerabilities. Don’t let the convenience of “leaving things alone that aren’t broken” be the reason hackers break into your cars.
10. Remove unused access. Similar to the above comment about removing unused components, there are often unused ports, protocols, and accounts on a system that are leftovers from development or things negated by newer developments. Get rid of everything that a properly running system doesn’t need. Don’t forget hardware in this purge. Unless your device actually uses Ethernet and USB during run-time, don’t leave those connectors populated on the board. Disable any USB to JTAG interfaces at a hardware level and remove JTAG pins or any other specialized debug connectors. If an interface isn’t needed, it shouldn’t be found on any shipping hardware.

While that wraps our top 10 checklist for basic security requirements for autonomous cars, there’s a lot more to automotive cybersecurity than a single blog can cover. I’ll be talking about these items and more during my talk “A Risky Ride? Cybersecurity for AVs” at ADAS & Autonomous Vehicles 2018, Tuesday October 16. Please drop by if you’d like to chat about this blog or anything else cybersecurity related.

Jacek Spiewla Sr Manager, User Experience

Jacek holds a Master’s in Human-Computer Interaction from the University of Michigan, and has a deep background in speech/audio processing technology, as well as voice user interface design. He is responsible for strategic planning activities and coordinating UX projects.