[kazinator]

The fact that a dashboard system that controls your radio or AC has access to cut your transmission is also a hardware configuration issue. Accessories should be physically secured from ignition and drive train. The internet connected features of the car, in turn, should be severed from both of these. It should not be physically possible to turn on the wipers from the embedded processor that receives packets on the IP address of the car.

[stonogo]

Read up on CAN-BUS. The entire industry is moving to one-wire protocols to reduce the labrynthine copper network that prevailed in the past. If you can put your transmissions diagnostic information on the radio's nice big LCD, why wouldn't you?

Some would say "this, this is why", but those people are not responsible for selling and maintaining millions of vehicles.

[pavel_lishin]

> If you can put your transmissions diagnostic information on the radio's nice big LCD, why wouldn't you?

Surely there's a way to make this information read-only. I can see information about my engine on my dashboard via the speedometer and tachometer; it would be ludicrous if I could kill my engine by grabbing the little needles and cranking them down to zero.

[AlexandrB]

> Surely there's a way to make this information read-only.

There absolutely is a way. Just off the top of my head you could relay the information from the high-sec CAN bus to a low-sec one with a micro-controller. So the low-sec bus can only receive messages from the high-sec one.

Not enabling firmware loading over CAN on the relay is a must as well for obvious reasons, but the key is the code on the relay microcontroller can be kept very simple (easier to audit/secure).

[romaniv]

Isn't that what the hacked car already doing? I don't know about Jeep specifically, but most cars have several CAN busses and some micro-controller passing messages from high-speed control network to low-speed infotainment network.

Problem is, most automotive engineers are clueless about security and most "hackers" are clueless about automotive hardware, software and protocols. There is no dialog.

I wish articles like these posted at least some specifics. A lot of these hacks in the past were completely impractical. Yes, yes, they had shown some interesting possibilities, but it was disingenuous to present them as real-life attacks (which many media outlets did).

[adamgravitis]

For sures. The ECEs are very much complicit too. Perhaps this is a ECE<->software team communication or power problem? ECEs invent the systems architecture and some poor chap has to attempt to secure the thing? Or maybe the software guys have no avenue to push back against bad systems-level design.

[cameldrv]

And what are we going to do for self-driving cars? These are almost certainly going to rely heavily on internet access to perform basic driving functions. Figuring out how to make complex systems like these be secure in a trustworthy way is going to be a huge challenge as more and more critical devices are connected to the Internet.

[leereeves]

No way a self driving car can rely on Internet access to "perform basic driving functions". Lag and connection failures would kill people.

They might need Internet access for updates, in which case, there should be a physical switch that connects the net and disables the engine.

[philipw]

An air gap is hardly a solution for traffic information the route planner HAS to talk to the computer responsible for getting from A to B. In the same way that firewalls are no longer particularly relevant, air gaps appear to be flawed now too, the only way to solve any security issue is better code quality..

[leereeves]

It's not perfect, but an air gap can help reduce the attack surface and interval.

Better code quality is important too, of course.

I agree with cameldrv that it's going to be a challenge.

[Animats]

"And what are we going to do for self-driving cars? These are almost certainly going to rely heavily on internet access to perform basic driving functions."

Actually, no. Google's Urmson has spoken at "connected vehicle" conferences and indicated they don't need car to car communication.

[uxp]

Agreed. The key word here is "basic". Maps have been and can be downloaded, and algorithms to get to point B from A have been embedded for a decade at least. It's only the newer devices (phones) that have managed to push that all server-side. Real-time data like traffic conditions or weather hazards can be added as supplementary data through secure channels, but the entire system does not require an internet connection to work.

Thinking that "basic driving functions" will need to rely _heavily_ on internet access is thinking wrongly.

[beat]

Which is the primary and most valid criticism of self-driving cars.

[ben_bai]

That's why they test on this car. Because the CAN buses are all connected without "firewalls".

[ethbro]

It's almost like someone designed a network protocol without thinking about security. First time for everything, I guess...

[sitkack]

I immediately thought of an unlocked firmware update (or boot over CAN) in some entertainment computer component that can then spoof other subsystems. The security model in modern cars is broken, esp with regard to control and data.