How to Hack Your Own Car

Car hacking continues to be a popular news trend -- so much so that hackaday.com named 2015 the “Year of the Car Hacks” -- and the interest does not seem to be slowing down in 2016. Just last month we heard of thieves successfully using keyless entry system hacks on 24 different car models, around the same time the FBI issued its first public safety warnings on malicious car hacks threats.

When an attack like this is made public, auto manufacturers are generally faced with three options: a full recall of the affected vehicles, a mail-out of USB disks loaded with updates, or over-the air (OTA) patches. Manufacturers tend to prefer the OTA option as the least costly (and least conspicuous) of the three. However, OTA updates have their own security risks, and without proper checks in place they can allow a path for attackers to inject malicious data.

In order for OTA updates to be performed securely and effectively, a PKI infrastructure must be in place to encrypt and sign the update packages. When done in conjunction with PKI, OTA updates provide an efficient way to apply patches to an entire fleet of vehicles quickly and quietly. That’s great! But here’s the problem with implementing PKI with vehicles: it makes it extremely difficult for consumers to manage their own software updates.

Freedom to tinker

The fact is, many vehicle owners want to feel that they can do what they want with their cars; if they’d wanted to lease a vehicle they would have signed a leasing agreement. There is a long history of owners “hacking” their cars, going back to the time before vehicles were primarily run off of software, and when home vehicle modifications and Mom & Pop repair shops were on every street corner. We love customizing our vehicles. But as vehicles become more electronic, manufacturers are keeping the workings of the electronic side ever more secret in order to keep their “competitive advantage.” This means that if you want to modify or add a component and have it integrate with the vehicle, you need to be able to reverse-engineer the vehicle network and/or the firmware.

Personally, I feel this extra hurdle is unnecessary and will exclude a lot of people who don’t have the skills or tools. Fortunately, with the adoption of the Class 21 DMCA Exemption ruling last fall, it is now legal to post information online and collaborate on the inner workings of your vehicle without threat of suit. This is great news for digital rights advocates. But when you consider the move to implement a PKI key system for updating firmware, the question remains: How do you implement a private/public key system and still allow people to make modifications? Can you preserve the right to tinker and still maintain a secure update process?

This is one of the new challenges facing the auto industry. People feel very strongly about being able to modify their vehicles, or at the very least buy third-party parts or visit non-manufacturer repair shops to get better deals on repairs. But if there is a lockout on unsigned changes, will these options become virtually impossible?  

Implementing PKI securely

Let’s start with a normal PKI update as an example. The vehicle is in an idle state (perhaps charging at night) and is notified of a software update. The vehicle fetches the update, checks the signature, verifies via a secure bootloader that the update is signed by the manufacturer, and then updates itself. What we want to avoid is a hacker sending unsigned code to the system, but at the same time we as owners want to be able to send unsigned (or at least not signed by the manufacturer) updates and modifications.  

One method to allow this would be to include a physical override switch. If the switch were difficult enough to get to -- for example, someone would need to be able to access the inside of the car to switch it, say, physically on the ECU unit under the glovebox -- then setting this switch to allow unsigned code would provide little security risk while allowing you to make your own modifications. When the vehicle receives an update from you that wasn’t signed by the manufacturer it would check to ensure the switch had been set before allowing you to upload your custom update.

It’s important to note, though, that once you upload code via this switch, you could not go back! The vehicle would mark itself as “tainted” in the secure bootloader so that your warranty is voided. If you then sold the vehicle it would be easy to verify that the vehicle’s firmware has been modified. This is the equivalent of a Void Warranty sticker and uses the same methodology Google used on the original Chromebooks.  

This is just one potential method, and these update systems have yet to be developed, but here’s hoping that as the auto industry reviews newer, safer ways to manage vehicles, they don’t forget about the right to tinker.

Related Content:

Find out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Click here for pricing information and to register.