Each high-profile hack of a car—whether it be a Jeep, Tesla, Nissan, or Mitsubishi vehicle—teaches us something about the design practices to avoid--and embrace--when developing connected products.

Brian Buntz

June 9, 2016

7 Min Read
Although car hacking is not a widespread problem now, cybersecurity of cars is bound to grow in importance.
iStock / djedzura

The Mitsubishi Outlander plug-in hybrid electric SUV won’t hit the U.S. market until the fall, but already the car is raising eyebrows after a British security expert named Ken Munro of Pen Test Partners managed to take control of many functions of the Outlander PHEV with a computer and a wireless antenna. Mitsubishi is working on a fix to the problem.

One of the main vulnerabilities of the car, reportedly the world's first 4×4 plug-in hybrid SUV, is its use of WiFi to enable users to perform functions like unlocking doors, adjusting the thermostat, and setting a timer for the plug-in charging with a corresponding app. Although a WiFi password is required for this, Munro said that it would be relatively easy to crack as there essentially is no other security between the phone and the WiFi access point. After performing a man-in-the-middle attack, Munro was able to assume control over the air conditioner, as well as the headlights, theft alarm, and other car functions.

According to David Miller, Chief Security Officer of cloud company Covisint (pictured), which was founded by a consortium of carmakers, several things can be learned from this hack. We’ve summarized his thoughts into five basic principles below.

1. Don’t Use WiFi to Control Car Functions

David-Miller_0.pngThe method by which the phone connects to the vehicle is the biggest architectural vulnerability. Mitsubishi installed a WiFi hotspot in the car just like you would have in your house. When you get close enough to your vehicle, your phone will pair with your vehicle. It's just like when you walk into your house, and it says: ‘Oh, look, WiFi.’ That is inherently insecure. I don’t care if you have a long SSID and password.

I can think of a lot of reasons why using WiFi in this way can cause problems—not all of which have to do with security. For example, say I parked in my driveway or garage. If my car is on, my phone now is competing between whether it connects to the WiFi in the house or car. You can only connect to one. Since my car doesn’t have Internet connectivity, then I can’t go online if I log into the car’s WiFi hotspot. You also could have the opposite scenario: You could be in your house and see your smartphone trying to connect to your vehicle. I also don’t know how it works if somebody brings a WiFi hotspot into the vehicle. This approach has inherent difficulties because it was not the way in which WiFi was designed to be used.

I bet you most people would end up turning this off because it would annoy them.

Just think about it: If your phone is set up to connect automatically and you go into a restaurant with really bad WiFi, the second you walk in you lose your Internet connection. So you turn off your WiFi and get back on 4G because it is faster. That scenario would play out every time you get close to your car.

2. Don’t Give Control of a Car (or Device) to Just Anyone Who Connects to It

Mitsubishi was assuming that the network is secure. This vehicle is a network endpoint, and the assumption was that, if you can get on the network, you must be okay. That is the fundamental flaw. The assumption should always be that the network is completely insecure and can easily be hacked and that you should, therefore, use another method to be get permissions.

In general, security vulnerabilities have less to do with how you connect and more to do with how you authenticate after you connect. In the Mitsubishi example, a security professional was able to control several functions after connecting to the network. But being on the network alone should give you no rights at all. When you connect to the car, you shouldn’t be able to do anything until you have proven who you are.

3. Don’t Make Authentication Too Easy

An easy fix for Mitsubishi would be to require users to go through a process to register their phone and then download some token that determines whether he or she has permission to start the car or perform other actions. After the phone pairs with the car, it could query the phone to say: “If you provide me with this token, the car would be set up to validate it.” At least then, only your phone could hack into it. If someone steals and unlocks your phone, that person could control your car but, on the other hand, they could accomplish the same thing by simply taking your keys.

The technical method of getting permissions can be tokens. It is like the ticket you get to go to the Super Bowl. When I walk up to the stadium, the guy who is behind the turnstile doesn’t recognize me. The fact that I got there doesn’t mean that I should be allowed in. The only thing that gets me in is this piece of paper with a hologram on it. I got that ticket in a whole different but secure way. In the case of computer security, the token is encrypted and signed using security developed to protect banking organizations.

We believe in this issue of a permissions/response model. Wherever an action occurs, you have to go out to a third party cloud service to ask authorization to be able to do something. You go out and say:”‘Is it OK for me to start the car?” And the cloud can authenticate or use your phone’s ID to make sure it is the right device and then hand you an action token that you present to the vehicle.

4. Don’t Panic about Car Hacking 

I think we shouldn’t freak out about the security of connected vehicles. It is not a doomsday scenario. Honestly, if you want to steal my car, I can think of at least 50 ways that are easier than trying to crack the network connection and doing all of the goofy things that I see these security experts do. A hammer is a hell of a lot cheaper than one of these devices that cracks passwords.

If the OEMs wanted to manufacture a vehicle that is 100% safe in a crash, they could, but it might cost $1 million. There is a tradeoff. I don’t think people like hearing about it, but that same tradeoff is made with security.

I guarantee you that the U.S. president’s limousine is not a connected vehicle. I bet you can’t remote start it or unlock it. That is because the president is a special case. Somebody would certainly work very hard to take control of the president’s motorcade. I am not as worried about the average person.

5. But Don’t Write Off Security Either

Just because hacking connected cars is not a widespread problem now doesn’t mean that cybersecurity should be ignored. We have to think about the future of these vehicles. They are going to be out there for years. And we have to be able to understand and talk about what the future of that is.

If you asked me about Internet security 20 years ago, I'd say that it really wasn’t a problem. When the Internet was first coming out, it was standard TCP/IP. It wasn’t built for things like Web banking. But the architecture that was created 20 years ago is the architecture we live with today. Many of the problems we have today on the Internet are because of the fact that the base infrastructure was never designed to be secure. The designers of TCP/IP believed that the Internet would be a connection between trusted endpoints. They thought it was going to be universities that were online. We have bolted things on top like SSL and other things on top of an inherently open network.

We are going to live with the architecture that is being built today in these vehicles for 20 or 30 years. And, in 20 or 30 years, when perhaps we have semi-autonomous vehicles that are driving around where people aren’t having to look at the road and where we transact business through our vehicles, we are going to find problems and find we are going to have to bolt security on top of that, too.

About the Author(s)

Brian Buntz

Brian is a veteran journalist with more than ten years’ experience covering an array of technologies including the Internet of Things, 3-D printing, and cybersecurity. Before coming to Penton and later Informa, he served as the editor-in-chief of UBM’s Qmed where he overhauled the brand’s news coverage and helped to grow the site’s traffic volume dramatically. He had previously held managing editor roles on the company’s medical device technology publications including European Medical Device Technology (EMDT) and Medical Device & Diagnostics Industry (MD+DI), and had served as editor-in-chief of Medical Product Manufacturing News (MPMN).

At UBM, Brian also worked closely with the company’s events group on speaker selection and direction and played an important role in cementing famed futurist Ray Kurzweil as a keynote speaker at the 2016 Medical Design & Manufacturing West event in Anaheim. An article of his was also prominently on kurzweilai.net, a website dedicated to Kurzweil’s ideas.

Multilingual, Brian has an M.A. degree in German from the University of Oklahoma.

Sign Up for the Newsletter
The most up-to-date news and insights into the latest emerging technologies ... delivered right to your inbox!

You May Also Like