But every microcontroller on the network doesn't have to listen to messages from the others.
The real problem is that the designers of CANBUS never dreamed of a day when rogue nodes could show up on the network and start broadcasting messages they should not be broadcasting. Automotive embedded systems were closed loops and, aside from perhaps a diagnostic tool in the garage while parked, not susceptible to spoofing messages.
I wouldn't even blame the designers of CAN-bus. The crazy thing is that GM/Chrysler allow media devices and general computers on the CAN-bus without a firewall.
It's easy to say that the architecture is flawed, but that's no excuse at all. The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus.
It's the same as blaming the insecure architecture of the internet when your password gets snooped, when you should have just used a secure tunnel.
The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus.
Unfortunately CAN is not as complex as an IP packet. It's essentially a one-wire serial bus with collision detection. Even RS-232 lets you clip the TX line so that a device could listen but not send. You would need to clip the TX before the CAN transceiver, and that's something nobody typically does.
I'm suggesting there would be a hardware device that sits between any device and the CAN-bus. It would simply decode incoming messages, and filter not allowed messages, recode the rest and put them on the bus. I bet you could program an Arduino Nano to do this (as an illustration that it's a fix that shouldn't require more than a few dollars, obviously it'd have to be rugged, robust and reliable for GM/Chrysler to do it).
The simplest method is to encode an authentication scheme using digital signatures for each device in the bus, and burn an approved transmitter list into each device such that specific messages have to be signed by a specific MCUs authentication key or it is ignored. Then simply don't add internet-connected hardware to the approved senders list for any high-risk messages. You can then compromise the car at will but none of the other CAN devices will process acceleration messages unless you happen to own an internet-connected accelerator.
Digital signatures are (a) not simple --- the cost and complexity of implementing and verifying them might be as bad as that of switching to a different phy/mac and (b) particularly tricky to do in microcontroller parts.
Some controllers already do some similar things, more like shared secrets though. It's common in the brakes. There is some sequence of commands that have to be sent first otherwise later commands will be ignored. The problem is that 1) you can wire in a scope and watch 2) just try every possibility or 3) use the diagnostic/test messages instead that accomplish the same without all of that.
There are devices like this in use, i worked with automotive and we used a device like this to attach certified third party factory installed add-ons, they also translated vendor specific quirks in the protocol so that both sides would understand each other better. In essence the third party was kindof trusted but to be on the safe side we firewalled them to only allow a list of white listed commands, more like an API. Not having this kind of barrier for internet attached devices is inexcusable.
Maybe I don't understand the difficulty. This is a standard services problem that standard software architecture practices would solve. You just need a gateway sitting in front of the CAN bus and any externally exposed services must go through the gateway. Only "safe" services or commands are exposed in this case. Maybe an entire service here, maybe a specific info command to an essential driving service there. The gateway inspects all incoming requests from these external services. All internal commands continue talking through the bus directly. Problem solved.
Yes, a gateway is a common solution. Or having two busses (one for engine control and the second for aux functions like HVAC, radio, lighting etc) with a system to pass critical messages between the two.
But it's cheaper to use a single bus and just slap everything on there. Or in the case of something like OnStar, realize you can add extra capabilities through firmware and not fully think about the impact when your radio can send unfiltered messages to your ECM.
You do have that gateway, it's likely the radio too. That thing has the most complicated and feature-full code of anything in the car and humans make mistakes when writing even simple software.
The real problem is that the designers of CANBUS never dreamed of a day when rogue nodes could show up on the network and start broadcasting messages they should not be broadcasting. Automotive embedded systems were closed loops and, aside from perhaps a diagnostic tool in the garage while parked, not susceptible to spoofing messages.