[billforsternz]

Unfortunately you are casually proposing to trash untold billions, probably trillions of dollars worth of existing automotive engineering infrastructure with that comment. As any system is decomposed into components you can and must reach a level where inter-component communication is dumb, unquestioning, immediate. Obviously by the time you reach transistors (or pistons) that's how it works. CAN is not as fundamental to cars as pistons (or wheels if you prefer electric cars I suppose) but it's not that far removed. It was developed decades ago, at a time when this kind of hacking was strictly science fiction.

I don't think it's necessary to throw away everything (as near as makes no difference) to address this problem. Real air gaps, real read-only circuitry etc. (as described in other comments) could do the job.

[dsuth]

I disagree; it's not necessary to throw everything away, but an improvement should, and must be made. Existing protocols can be extended to include security (and have, see Safety CIP for an example).

Any form of engineered design is unlikely to go backwards in terms of the functionality and flexibility that things like bus communications bring, but awareness of these new attack vectors needs to be included in the base design.

This is the path that industrial control systems are taking in light of attacks such as Stuxnet, I expect that the automotive guys (who are usually ahead of the game in terms of systems engineering) will follow suit.

Edit: The problem I have with people proposing air gaps and read-only circuitry, is that they just don't work in real applications. If there is a business case against it, such as the service these jeeps were offering, then air gaps and hardwired circuitry solutions will be overridden by that business case. Further than that, as can be seen with things like the Lenovo hardware fiasco, manufacturers cannot be trusted to abide by the rules (such as: air gaps are now mandatory), when there is a benefit for them to act otherwise. As Chrysler now has the ability to remote into their cars, they are very unlikely to remove this ability 'merely' due to safety concerns.

It's far safer on the whole to offer secure methods of achieving the existing or proposed functionality, than to try and walk backwards and make things harder and more costly to implement, for lesser functionality.

[Too]

The nature of a bus-network makes it very hard to do verification that the sender is in fact who he claims to be. Only solution i can see that really works is if the true sender "breaks the bus" when it detects a malicious sender is using it's source address, as is done when you get ID-collisions, CAN itself does not have a concept of source but many protocols implemented on top of CAN does. In practice this could be very complicated though because often devices deliberately pretend to be other devices due to compatibility with legacy devices.

The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option. Establishing encrypted connections also comes with a safety risk if they fail, current architectures are designed to allow glitches in the physical connections and recover instantly once the connection is back. Really, many ECUs are designed to fail in every possible way, you can even pull the power of an ECU and plug it back in while driving and your car will keep going without you even noticing it(dont try this at home). You don't want to waste a second with encryption handshaking on a 100hz signal just because you lost a sequence number somewhere. And knowing the complexity and lack of quality in encryption libraries(openssl anyone?), adding more complexity would just introduce even more risk.

[paulmd]

> And knowing the complexity and lack of quality in encryption libraries(openssl anyone?), adding more complexity would just introduce even more risk.

What you're saying here is fundamentally that because OpenSSL has bugs that everyone should be using HTTP instead. That opinion puts you in the minority of the technical world, to say the least.

> Only solution i can see that really works is if the true sender "breaks the bus" when it detects a malicious sender is using it's source address, as is done when you get ID-collisions

This is a solution that requires perfect implementation from every component. As long as this is actually a specified behavior, written down somewhere that you have to implement to mark your part as "CAN2-compliant", that would be OK, but I doubt that's going to happen.

In general, though, I oppose requiring every node on a network operate perfectly to maintain security.

> The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option.

So don't include a signature in every message. Nobody does that in the computer world, you authenticate a session. There's still no reason for the head unit to be opening up a session with the brakes, and the brakes should reject such a connection attempt.

I realize that this isn't possible with the architecture of the CAN bus, but the CAN bus is just not suitable for nodes which are connected to the internet and broadcast wifi hotspots. The failure case of a CAN bus attack is just not appropriate - once you're on, that's it, you can do anything. There's going to have to be some changes, and the sooner we accept that fact the sooner we can start working on a solution. If we need a network with a cleaner electrical source and more bandwidth, that can no longer be driven with 8-bit micros on an unfiltered alternator, well, that's the price of having nice things. We'll have to buy the $1 part instead of the $.30 part to get the power windows onto the network. When you're connected to the internet, blind trust is not an option.

Within a year or two we'd see micros with onboard crypto accelerators anyway, and we'd be back to the $0.30 parts.

[dsuth]

Thanks for that comment. I have some more reading to do on CAN bus, and admittedly I come from an industry where the default is generally to turn things off in unsafe or uncertain conditions, which simplifies the protocol significantly. That doesn't help when your car is doing 100km/hr on a freeway though...

[paulmd]

We call this "dumb, unquestioning" layer the "link layer" (layer 2) in the 7-layer model.

The thing is, nobody lets their computer act based on arbitrary packets coming in from the internet. We at LEAST make them take place in the context of a TCP session (layer 5). More likely you'd require node authentication (a function of the application layer, layer 7).

I have real doubts that manufacturers can/will implement airgaps and read-only circuitry properly. Jeep tried, and now they're doing a recall. Auto companies are only starting to realize that they are actually in the business of computer security now, and it will be years before there's been enough of these recalls for them to come to terms with the magnitude of this task. The fact that they are still operating on the walled-garden concept - inside of which all messages are taken on face value - is ample evidence of this.

Real airgaps imply a severe degradation of functionality from what both consumers and auto companies have come to expect. The days of your entertainment unit being able to control anything in your car will be gone, as will things like over-the-air firmware updates, remote door unlocks, etc. This is just not going to happen in a feature-driven world. And all it takes is for someone to leave one firmware-flash bit unset and the entire thing is worthless. Expecting that airgaps and read-only circuitry will be implemented, and implemented perfectly, every time, is wildly unrealistic, and with that security model the failure case is brutal. Once they're into the garden, they're in.

Burying your head in the sand or bawling about the cost of the fix is pointless. Cars are now connected to the internet and broadcast wifi networks, they can no longer blindly trust messages on their internal networks. That's the thing auto companies have to fundamentally come to grips with, regarding them now being in the business of computer security. If you want cars to be on the internet, validating signing for messages, firmware updates, etc is not optional, regardless of what you would prefer. We need UEFI for car hardware, and we need messages authenticated on a session level. The brakes need to be able to realize that there's no valid reason for the head unit to be sending them commands.

[billforsternz]

I think CAN maps better to layer 1. You can and do blindly trust messaging at layer 1. In any piece of engineering there exists an abstraction level below which there is no security. Software people are prone to forget this because everything they do is virtual. But it's not turtles all the way down, there is no such thing as a secure transistor.