Justin Cappos is a professor in the Computer Science and Engineering department at New York University, where his research addresses problems in security, systems, software update systems, and virtualization. His research philosophy focuses on solving real world security problems in practice, with software such as Docker, git, Python, and most Linux distributions using his research advances. The practical impact of his work is why Cappos was named to Popular Science’s Brilliant 10 list in 2013. In this interview, he explores how updates and other security processes are unique to the automotive world.
Question: Vehicles are becoming more and more like computers on wheels. That trend means someone will have to update their firmware: the vehicle’s owner, the automaker, or vendors of the telematics systems in the vehicle. How do you see the automotive firmware-update model evolving over the next decade or so?
Cappos: Today, OEMs such as Ford are driving the process of how and when updates are provided. That makes a lot of sense because they’re the ones that create the specifications for the components in the car to ensure that all of those work together. They go to the different vendors and specify things such as how the part from one supplier will communicate over a network with a part from another vendor to cause something to happen correctly.
But fleet owners, such as rental car companies, also want some level of control over updates. They don’t want their vehicles being compromised if, say, someone figures out how to hack a certain model that they own.
Question: Many fleet owners and consumers use aftermarket telematics products for applications such as tracking their vehicles’ locations in real time and getting insurance premiums based on their driving habits. How does the addition of aftermarket products affect security?
Cappos: It certainly complicates the process. Now you have an environment where there are multiple parties that need to be able to interact with, and trust, one another. But if one of those devices doesn’t have appropriate security—and that’s often the case—then it could become a back door for hackers to get into the vehicle’s other stock and aftermarket systems. For example, something you install via the onboard diagnostics (OBD) port to track your teenager’s driving could wind up enabling a hacker to deploy the airbag at highway speeds.
Question: There are two main ways to update a vehicle’s firmware: wirelessly (for example, cellular, Wi-Fi, Bluetooth) and via the OBD port. What are the security risks with each? And are some types more secure than others?
Cappos: One thing to worry about is man-in-the-middle attacks, where a hacker tampers with or blocks updates. Those are easier to do via wireless, because using the OBD port requires physical access to the vehicle.
That’s also why wireless, particularly cellular, would be the way to go for mass-scale attacks. The hacker could reach a lot of vehicles remotely and even simultaneously. Certainly, as cars get more connected, then it becomes more and more possible for an adversary with fewer and fewer resources to cause massive damage, disruption and even loss of life.
Question: Consumers and businesses typically replace their computers, servers, smartphones, and other IT gear after three to five years. But their cars and trucks often are still on the road for decades. How does that longevity affect cybersecurity? For example, if a telematics vendor stops providing updates for a product that’s five years old, wouldn’t the vehicles using that product become increasingly vulnerable for the rest of their lifespan as hackers develop exploits?
Cappos: Absolutely. This is a big problem in the automotive space. It’s a big problem in lots of other spaces too, such as medical devices and the Internet of Things. Without regulations or other mechanisms to address this, I don’t know how this is going to get better.
Everybody wants to sell you the latest car or latest truck. If they can get you to buy a newer car sooner, then of course that’s a good thing for them from a business standpoint. So how do you incentivize them to spend money and have substantial teams that are doing things like providing security updates for components that are out of date. And what do you do when a vendor goes out of business?
One potential solution is to have laws requiring the components’ source code to be open source. Another is to require vendors to provide updates and other support for some long period of time. Those are the kinds of things that would have to happen from a regulatory standpoint, but I don’t know when or if they will.
Question: Typically, enterprises and consumers don’t update firmware, because they fear it will break something, such as an application’s ability to work with other applications. Because a break could be deadly or expensive in the case of a vehicle, does the automotive industry need some sort of framework where vendors can test their updates to ensure that they won’t cause problems with other vendors’ systems?
Cappos: Yes, that’s a big problem with computers. It’s based on very flawed logic, because only once in a blue moon does something actually break. The odds of getting hacked are much higher.
I believe this will be less of a problem in the automotive world because as I mentioned earlier, the OEMs coordinate so many things. Here’s an analogy: Android and Windows have an inherent challenge when it comes to updates because there’s such a diversity of hardware, drivers and so on. That’s not the case with the iPhone and Macs because Apple controls the entire hardware and software ecosystem. So in that respect, automakers are like Apple.
