Automotive security and safety

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

The security of the software that runs in vehicles is a hot-button issue at the moment. At SCALE 14x, automotive-software engineer Alison Chaiken provided an insider look at the issue, including how software-development issues interact with regulatory agencies—and not always for the better.

Chaiken started off by explaining that she has been working on automotive software for the past several years (most recently at Mentor Graphics), but that the security landscape for automotive is so fast-changing that it is almost all she can do to keep up with the news. That is because the regulators (at the state and federal level) are busy trying to catch up with the security problems that the car manufacturers have wrought—while also making an effort to get ahead of the problem for autonomous vehicles.

Up until now, those regulators have had a decidedly mixed impact on automotive-software security. Chaiken cited the US National Highway Traffic Safety Administration (NHTSA) requirement that in-vehicle infotainment (IVI) head units show a rear-camera view, complete with lane overlays, two seconds after boot. This is a remarkably difficult metric to meet, and was rather arbitrary. Had the rule been three seconds instead of two, automotive-software makers could have saved countless hours and costs that could have been spent on safety and security issues instead.

The bad news

Automotive security has three main problem areas, she said: bad legacy designs, an unclear privacy situation, and the chilling effects of "digital rights management" (DRM). The insecure software found in many older cars is rife with security vulnerabilities, but it is a mistake to think that the industry's shift toward Linux is an automatic fix. In 2015, Charlie Miller and Chris Valasek found "five-ish" exploits in Jeep Cherokees. The most appalling was that anyone with a Sprint phone could get in range of a cell tower, scan for IP addresses in the range used by Jeep, and find D-Bus listening for connections on port 6667.

To make matters worse, Jeep did not build in an over-the-air update system, so the only way these vehicles could be patched is by downloading a new firmware image onto a USB stick and plugging it into the car. Hopefully into one's own car, although Chaiken noted that the company web site asked users for no authentication or even an assertion of ownership before allowing them to download a firmware image. The images on the site, she said, were virtually identical to the ones reverse engineered by Miller and Valasek, and the cars do not perform authentication, either. Nevertheless, at least open-source projects like GENIVI and Automotive Grade Linux allow people to participate and allow the security-conscious to read the source code; the same cannot be said of most legacy OSes running in cars, such as QNX.

"On the other hand, Linus [Torvalds] can't solve everything," she said, particularly where privacy is concerned. Many automotive systems seem to be designed with a "one user per device" model in mind that was copied over wholesale from mobile phones, but surely does not apply. What happens when you pair your phone with a rental car, she asked, or leave your car overnight with a mechanic? No one would leave their smartphone or laptop overnight with a repair shop, but automotive computer systems are poised to collect just as much personal information as either of those devices. Chaiken has asked carmakers how they plan to reset or blank out the personal data they collect, and received vacant stares in reply.

The security and privacy concerns are important enough in their own right, but they get more complex when government regulators get involved. She cited two examples. First, NHTSA rules in 2012 required telematics "black boxes" to record 14 specific vehicle data streams that could be used to help determine the cause of an accident. But the regulation failed to state that the data could only be used for accident service, and drivers found themselves being monitored around the clock and denied warranty coverage if a sensor reading suggested that they had, for example, exceeded a "safe" engine speed. The Electronic Frontier Foundation (EFF) filed a complaint, although it has yet to succeed at having the rules amended or replaced.

The second example is the still-ongoing exploration of driver drowsiness detection. If would certainly save lives if cars would trigger alarms when a drowsy driver nodded off, but making such a feature possible likely requires capturing a constant video stream—which has serious privacy risks.

It is easy to dismiss such privacy concerns now, Chaiken said, but that is only because of the old adage that "the best way to avoid being attacked is to be poor and boring." And right now, there are few real-world car exploits being seen because cars do not yet store payment information. Thieves have always stolen radios out of cars; once those dash units also include personal information and credit card numbers, she said, you can expect the thieves to be right behind. She noted that Visa recently announced a "connected car" initiative, and urged developers to resist the temptation to store payment data in vehicles.

The good news

Despite all the doom and gloom, Chaiken also shared what she regards as promising news on several fronts. The first is that NHTSA is preparing its rules on vehicle-to-vehicle (V2V) networking, and is using public-key encryption (PKE) to secure it. PKE will make it drastically harder for an attacker to spoof an emergency vehicle, but it has beneficial side effects, too. For example, the scheme uses short-lived keys, which protects against replays, but also makes it hard to track a single vehicle over a long period of time.

Another welcome change is the increased use of virtualization. Future car systems will not boot directly into Linux or QNX, but into a hypervisor. That will enable better separation of functionality, making it harder, for instance, for an attacker to get to the engine-control unit via the IVI unit. And automakers have already begun implementing watchdog timers to reboot stalled virtual machines, which will also make attacks more difficult.

There has also been a shift away from outdated network buses like Controller Area Network (CAN) to more robust alternatives like Ethernet Audio Video Bridging (AVB). And although Chaiken did not go into depth on the problems of DRM in the "bad news" section of the talk (referring the audience, instead, to Cory Doctorow's thorough keynote on the topic), she cited the automotive exemption to the Digital Millennium Copyright Act's DRM provision as an important win by the EFF.

Finally, she said, it is important to remember that big carmakers are no longer the sole creators of vehicles. There are several new start-ups, most notably OSVehicle (OSV) and Local Motors that are working on making a home-made, "white box" car. OSV, she said, wants to be the Gateway Computer of the automotive market. Whoever succeeds at that task, consumers will win.

In closing, Chaiken cautioned that the push to make cars more high tech can all too easily make them less safe. The regulations are still being written—even today, the California Department of Transportation is debating autonomous vehicle regulations. "If we keep getting rules about boot speed instead of about security," she said, "then we're not heading for a good place." Nevertheless, there is now a lot of open-source code involved in the process, so the security lessons understood by the Linux community all apply to this new problem space.