Are Connected Cars And Security-By-Design Incompatible?

GoogleCarDrive

Cars with internet access are part of the drive(!) towards self-driving cars

I have just finished a series of articles about (internet-)connected cars and autonomous (selfdriving) cars which will be published in an upcoming issue of the Danish IT-magazine Prosabladet.
As usual after a long period of research, interviews and writing I have too much material and feel an urge to offload a bit. So here goes…

What struck me most about connected cars is the inherent vulnerabilities in a car’s Controller Area Network (CAN).
(Don’t worry, I had no idea either what CAN was before I started my research, so hang on.)

CAN is a network that connects all the different Electronic Control Units (ECU) that control most aspects of a modern car; engine, transmission, brakes, locks, lights, aircon, airbag and so on.

The ECU’s are connected via the CAN so that they can communicate with each other. That is quite handy if you for instance would like to shut off the fuel pump after an accident in order to avoid a fire.
If the airbags are deployed, the airbag-ECU will tell the engine-ECU:
“”Hey, we had an accident, please shut off the fuel pump.”
This is a Good Idea.

The CAN is designed in such a way so that the engine-ECU doesn’t know who is asking for the fuel pump to be shut offand the engine-ECU isn’t bothered about asking. For efficiency reasons this is still a good idea; when you don’t have to ask who is making the request you can shut off the fuel pump much quicker.

This is not such a good idea when we are now in the year 2016 and we have connected different things to the CAN; things that can be accessed from the internet.
Suddenly it is a Bad Idea just to obey whoever is asking us to shut off the fuel pump or de-activate the brakes or give more throttle or …

To get an idea about what the consequences are, watch this video:

The hackers used a vulnerability in the Jeep’s Uconnect system to get access to CAN and this vulnerability has been patched since then. So don’t worry if you have a Jeep Cherokee or another car with the Uconnect system. The Uconnect vulnerability has been removed and you should be safe.

What has not been removed is the inherent vulnerabilities in the underlying CAN.
For my Prosabladet-articles I spoke, amongst others, to one of the most experienced security researchers/hackers when it comes to embedded systems and car security, Karl Koscher.

He and his colleague, Ian Foster, describes how CAN works in details and the inherent vulnerabilities in their excellent paper “Exploring Controller Area Networks” from December last year.

The CAN was originally designed in the 1980’s so we can’t really blame the CAN-designers for a bad design. Internet-connected cars was not something you would think about in the 1980’s or at the beginning of the 1990’s when CAN was revised and released in a version 2.

The thing is, at the moment we are connecting a lot of internet-connected devices directly/indirectly to the CAN via On-Board Diagnostics (OBD)-dongles, head unit systems as Uconnect and mobile apps. Some by car manufacturers, some by third parties such as insurance companies. Karl Koscher suggested that all the entry points should be hardened and made more secure in adition to a mandated security-by-design approach for all  development in the car industry.

But does CAN really fit into a security-by-design approach?