| |||||||||||||
Linux and automotive computing securityLinux and automotive computing securityPosted Oct 10, 2012 20:58 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: Linux and automotive computing security by dashesy Parent article: Linux and automotive computing security
The protocol over the wire matters as well.
Since the CAN bus includes the over-the-wire protocol as well as the electrical requriements, the fact that it doesn't even have the concept of sender ID is a major problem.
Yes, everything could add it's own authentication in the messages, but that is just layering another protocol on top of CAN, and getting all vendors to agree to it would not be trivial.
Switching to a different network protocol (say IP) would then enable a LOT of standard authentication, firewalling, etc tools to be used. Yes, mistakes can still be made, but given standard tools they are less likely.
One thing to remember is that when the CAN bus was created, it took a rather expensive system to run an IP stack. Nowdays this can be done on very cheap hardware.
(Log in to post comments)
Linux and automotive computing security Posted Oct 10, 2012 21:07 UTC (Wed) by fuhchee (subscriber, #40059) [Link]
"Since the CAN bus includes the over-the-wire protocol as well as the electrical requriements, the fact that it doesn't even have the concept of sender ID is a major problem."
Intra-computer buses like PCI get by without that.
Linux and automotive computing security Posted Oct 10, 2012 21:12 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> Intra-computer buses like PCI get by without that.
and how much security do you have on a PCI bus protecting you from a rouge card?
basically none.
(although, PCI actually does have a slot ID, so the main system can do some source validation. This is actually used with some virtualization systems, but answering the question in the spirit asked, rather than being picky about the particular bus used as an example)
the problem is that the CAN bus is not within a computer, it's connecting many different computers together to form the car's overall network. Not all of the devices on the network should be equally trusted.
Linux and automotive computing security Posted Oct 10, 2012 21:29 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
So cars need an airgapped CAN bus, inaccessible from 'untrusted' sources. Duh.
I shudder to think that my car's tire pressure sensors would use IPv6 to talk to the central computer. That's just... inelegant.
Linux and automotive computing security Posted Oct 12, 2012 13:34 UTC (Fri) by peter-b (subscriber, #66996) [Link]
I assume it would seriously upset you to learn that subsystems within the Falcon 9 launch vehicle use TCP/IP to talk to each other, then...
Linux and automotive computing security Posted Oct 12, 2012 15:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, that's surely insane. Though not as insane because rockets don't usually have cell modems connected to their critical infrastructure.
Linux and automotive computing security Posted Oct 12, 2012 17:21 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] OTOH, security researchers have successfully hacked a car's computer system through the tire pressure sensors, which displays a certain inelegance in the current system. The tire pressure sensors are actually an especially vulnerable point, because the only mechanically elegant way of transmitting information between the wheels and the rest of the car with some kind of wireless communications.
Linux and automotive computing security Posted Oct 12, 2012 22:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
So how is it going to be better if tire sensors now have TCP/IP stack with OpenSSL for PKI implementation?
The car-local network is a postcard example for a local airgapped network. It makes no sense to try to make every component secure, it's much better to have a secure perimeter where any external data input is treated as potentially malicious.
Tire-sensors and the law Posted Oct 13, 2012 2:29 UTC (Sat) by Max.Hyre (subscriber, #1054) [Link] My understanding (i.e., I'm too lazy to look it up right now) is that the law mandates these radio transmitters for tire sensors, and actually prohibits doing it by comparing wheel rotation rates. Of course, using sensors already in place (for ABS &c.) would markedly reduce the attack surface. I've always wondered whether this was done so that all new cars are now trackable remotely for some small-ish value of remote.Now who would want that?
Linux and automotive computing security Posted Oct 14, 2012 21:57 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] I think I've actually described it wrong; the problem is not with the tire pressure sensors, per se, but with the receiver. The designers seem to have treated the pressure sensor and receiver as a unit that was entirely inside the car, rather than treating the signal from the pressure sensors as an untrusted input. Researchers were able to crack the receiver by sending a spoof signal. I think this is a good example of the drawback of relying on perimeter security; it's brittle. If you fail to consider one source of potentially malicious data (or consider it but fail to secure it adequately), the whole system falls apart. I think you'd be much better off with some kind of defense in depth so that a single security failure doesn't bring down the whole system. Otherwise, you're left with a car that can be hacked because the designers didn't think that somebody might spoof the signals from the wireless tire pressure sensors. Maybe a full encrypted and authenticated TCP/IP stack is overkill, and a better CAN implementation can provide an adequate level of protection. But basing everything, including the internal message bus, on a standardized platform that's known to have good security seems like a big step forward.
Linux and automotive computing security Posted Oct 15, 2012 1:36 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
What kind of security can a bus provide? CAN is as simple as it gets for its purposes - it's a very simple broadcast-only shared-media bus with prioritized messages.
If you try to replace it with Ethernet then you'll get loads of problems, starting with a requirement to have point-to-point connections between endpoints and switches and then moving on to DoS protection and priority-based transmission.
And security guarantees won't get any better - Ethernet does not guarantee anything.
Linux and automotive computing security Posted Oct 10, 2012 21:18 UTC (Wed) by smurf (subscriber, #17840) [Link]
Different problem space. Don't compare apples with lemons.
|
|||||||||||||