Vulnerabilities / Threats

4/5/2016
11:15 AM
Craig Smith
Craig Smith
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

How to Hack Your Own Car

As vehicles become more software-driven, car manufacturers are keeping the inner workings of electronics systems more secretive. Here's one way to maintain security updates and still preserve your 'freedom to tinker.'

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.

Image Source: Craig Smith
Image Source: Craig Smith

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:

 

Interop 2016 Las VegasFind 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.

Craig Smith is the author of The Car Hacker's Handbook. He runs Theia Labs, a research firm that focuses on security auditing and building hardware and software prototypes. He has worked for several auto manufacturers and provided them with his public research. He is also a ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
zombieCraig
50%
50%
zombieCraig,
User Rank: Author
4/6/2016 | 12:51:45 PM
Re: Why hack stock?
It will affect diagnostic equipment.  It will not affect the OBD port itself.  However there is a lot of discussion about changing the OBD port for other reasons.  For instance, the only reason OBD-II is a standard is emmissions testing.  All the other things we have done with it are not mandated standards and can be changed at any time.  There is a growing concern about 3rd party OBD dongles being plugged into vehicles that open up the attack surface allowing cellular links direct access to your vehicle bus.  OBD ports may change a bit but not because of encryption.

A lot of the diagnostic service codes (DSCs) that are generated by things like the gas cap will also go to "the cloud" and you will be able to view them on your cell phone or they will be sent directly to the dealer.  They will still be local to the vehicle as well and you will still need a way to direclty access it but queriering DSCs doesn't require the modification of firmware, so they would still function even on updated encrypted systems.
theb0x
50%
50%
theb0x,
User Rank: Ninja
4/6/2016 | 11:56:50 AM
Re: Why hack stock?
Do you think this will change the OBD interface? If that is the case all automotive technicians would need to replace most if not all of their diagnostic equipment. I see this having a negative impact within the industry.

As it is right now on a modern vehicle a diagnostic code must be obtained just to determine that the gas cap is loose.
zombieCraig
50%
50%
zombieCraig,
User Rank: Author
4/5/2016 | 7:39:46 PM
Re: Why hack stock?
You are thinking of the work that has been done now. When all communication on the vehicle is encrypted, those none stock replacements will have to be more than just the ECU but every module that utilizes encryption. Soon, if we don't address the issue the only option will be stock.
theb0x
50%
50%
theb0x,
User Rank: Ninja
4/5/2016 | 7:36:01 PM
Why hack stock?
I don't really see the benefit of hacking a stock ECU when an aftermarket one has no limits to it's functionality. There is nothing to reverse engineer.
What We Talk About When We Talk About Risk
Jack Jones, Chairman, FAIR Institute,  7/11/2018
Ticketmaster Breach Part of Massive Payment Card Hacking Campaign
Jai Vijayan, Freelance writer,  7/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14072
PUBLISHED: 2018-07-15
libsixel 1.8.1 has a memory leak in sixel_decoder_decode in decoder.c, image_buffer_resize in fromsixel.c, and sixel_decode_raw in fromsixel.c.
CVE-2018-14073
PUBLISHED: 2018-07-15
libsixel 1.8.1 has a memory leak in sixel_allocator_new in allocator.c.
CVE-2018-14068
PUBLISHED: 2018-07-15
An issue was discovered in SRCMS V2.3.1. There is a CSRF vulnerability that can add an admin account via admin.php?m=Admin&c=manager&a=add.
CVE-2018-14069
PUBLISHED: 2018-07-15
An issue was discovered in SRCMS V2.3.1. There is a CSRF vulnerability that can add a user account via admin.php?m=Admin&c=member&a=add.
CVE-2018-14066
PUBLISHED: 2018-07-15
The content://wappush content provider in com.android.provider.telephony, as found in some custom ROMs for Android phones, allows SQL injection. One consequence is that an application without the READ_SMS permission can read SMS messages. This affects Infinix X571 phones, as well as various Lenovo p...