Linux and automotive computing security

Posted Oct 10, 2012 21:55 UTC (Wed) by rgmoore (✭ supporter ✭, #75)
In reply to: Linux and automotive computing security by drag
Parent article: Linux and automotive computing security

This topic is touched on in the article. The problem is that many non-critical systems need information from the critical systems in order to function properly and/or safely. For example, automatic door locking depends on knowing something about the state of the car- different makers choose to lock when the engine is started, the car is put in gear, or when it exceeds a threshold speed- to operate properly. OTOH, the locks need to be connected to insecure systems that take remote information, like the keyless entry or remote assistance systems. So the locks now need to communicate with both the critical driving systems and the communications systems. Putting an air gap in place will disable some useful feature of the car.

You can't even fix the problem with one-way information flow between critical and non-critical components, because there are valid reasons for wanting to send information the other way. Many security features require sending information from the outside world to the engine computer. For example, my car has a feature that disables the ignition if the doors are locked using the keyless entry system. That's a very desirable feature, but it means giving control over the engine to a system that has to talk to the outside world.

to post comments

Linux and automotive computing security

Posted Oct 10, 2012 22:44 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Air gap doesn't mean complete absence of any communication. For example, a door lock system can passively listen to CAN bus for speed information messages (the design of CAN makes this easy).

So far I haven't seen an example where you really need complex two-way communication between a critical system and non-critical stuff.

Linux and automotive computing security

Posted Oct 11, 2012 14:52 UTC (Thu) by ortalo (guest, #4654) [Link]

A fireman with its phone wants the engine to stop (GSM -> engine).
Is that a better idea?

Anyway, I *agree* with you: first, why not try to do something good with an air gap. Once manufacturers will have demonstrated their ability to design something correct with an air gap, maybe they could be allowed to try to adress more complex configurations.

But you know, that was the way certification authorities approached the issue for airplanes and, apparently, the "non-critical -> critical" issue came back on the table within 2-3 years.
It seems civilian users want to do that. (Maybe users really are the most annoying vulnerability after all...)

Linux and automotive computing security

Posted Oct 10, 2012 22:53 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> You can't even fix the problem with one-way information flow between critical and non-critical components, because there are valid reasons for wanting to send information the other way.

You could combine one-way information flow with a default-deny firewall on the opposite direction, with very strict format checks. If implemented properly, only a few exact packets would be able to pass, with a result similar to a bundle of discrete wires. (It would be a set of rules somewhat like: allow only the exact packet 010203x4, with x being only 1, 2, or 3.)

Of course, that adds cost, power, and space usage, since the firewall would have to be a separate discrete component, and you would need one for each device straddling separate integrity domains. You also lose flexibility, since you would have to replace the firewall component if you need to add more functionality in the direction it filters.