User: Password:
|
|
Subscribe / Log in / New account

Linux and automotive computing security

Linux and automotive computing security

Posted Oct 10, 2012 19:25 UTC (Wed) by fuhchee (guest, #40059)
Parent article: Linux and automotive computing security

"ultimately trace back to the insecure design of CAN bus."

On the other hand, if the CAN bus traffic was secured to some extent, the subsystem manufacturers might become even more blase about buffer overflows and logic errors. After all, no more hostile traffic would be expected.


(Log in to post comments)

Linux and automotive computing security

Posted Oct 10, 2012 19:59 UTC (Wed) by drag (subscriber, #31333) [Link]

"Airspace firewall" will always be infinitely more effective then any other sort of scheme with a networked system. There simply is no comparison.

It's idiotic to wire up any sort of entertainment system or any non-essential system with engine management or braking system.

Linux and automotive computing security

Posted Oct 10, 2012 20:26 UTC (Wed) by jimparis (subscriber, #38647) [Link]

Idiotic? But your entertainment system is the screen where the rear-view backup camera gets displayed. You need the computer controlling the transmission to be able to tell the computer controlling the entertainment system to start displaying the camera feed. Now they're wired up. And I think you'll find that by the time you hit every use case (safety interlocks that prevent changing GPS coordinates while the car is driving, vehicular speed being to augment the GPS in tunnels, etc) you'll find that just about everything gets connected somehow.

Linux and automotive computing security

Posted Oct 10, 2012 21:26 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

"Back in my days" (tm) we'd just have placed a purely electric connection, i.e. "short these two wires if the reverse gear is engaged". No need for complex digital interface.

Linux and automotive computing security

Posted Oct 10, 2012 23:36 UTC (Wed) by martinfick (subscriber, #4455) [Link]

"Back in my day", people looked behind their cars before putting the car in reverse. I was shocked to be recently hit standing still in a parking lot by someone relying on their reverse warning and not bothering to look; the warning never went off.

I could not help but think of the modern Battlestar Galactica series when reading this article, I am now fairly convinced that I simly don't want such a network in my vehicle. If the authorities mandate it, I will just stick with my used cars for as long as I can (luckily 90s galvanizing makes that more of a possibility). I don't own a vehicle made this melenium and I don't plan to, they simply are less safe and full of BS that no one needs. Everytime I rent a car I am shocked at how poor the visibility is due to the large air bag filled columns pushed too far forward impeeding the view out the side of the windshield making a left turn a high risk acitvity (for me and anyone nearby). It's sad, but soon it will be mandated that we all drive tanks with nothing but a 7 inch screen to view the outside chaos of dead pedestrians left in our wake, and the media will brag about how much safer modern cars are than ever. :(

Linux and automotive computing security

Posted Oct 10, 2012 23:44 UTC (Wed) by jimparis (subscriber, #38647) [Link]

> "Back in my day", people looked behind their cars before putting the car in reverse. I was shocked to be recently hit standing still in a parking lot by someone relying on their reverse warning and not bothering to look; the warning never went off.

I was referring to the rear-view cameras, which are kind of a necessity on some cars these days due to poor visibility... (see below)

> they simply are less safe and full of BS that no one needs. Everytime I rent a car I am shocked at how poor the visibility is due to the large air bag filled columns pushed too far forward

I think many of the visibility problems stem from pushing to get better gas mileage. Vertical spaces like windows keep getting smaller. Accordingly, some of the technological "improvements" like rear-view cameras are to try to counteract those problems. It's not (necessarily) just some cranky designer having a bad day.

Linux and automotive computing security

Posted Oct 11, 2012 3:39 UTC (Thu) by ncm (subscriber, #165) [Link]

According to report from inside the automotive industry, what drives the trend to reduced visibility is the desire by female buyers (who now have a predominant influence on new-car purchase decisions) to feel less "exposed". In other words, car makers are making everyone, including buyers, less safe so as to be perceived by buyers as safer.

Linux and automotive computing security

Posted Oct 16, 2012 12:18 UTC (Tue) by wookey (subscriber, #5501) [Link]

Reduced visibility due to thicker A pillars is due to more stringent crash testing/requirements. 'NCAP tests' in Europe. And a god NCAP rating really does help sell cars. But it also makes them heavier and harder to see out of. The steadily improving motor vehicle injury stats have been coming at the expense of those outside (pedestrians, cyclists, motorcyclists) for some time now. At least in Europe TPTB have finally understood that trying to improve the numbers by simply discouraging those other modes is counter-productive in so many other ways (obesity, congestion, noise, expense and general public realm issues), but rowing back from 50 years of 'the car is king' thinking and development is hard to do. Visibility, crash ratings and excessive tech in cars are just small parts of a much wider issue.

I've been holding on to my 1997 pre-ECU vehicle for a while now, despite its relative inefficiency, hoping to get something with free software in it so I had a least a chance of keeping some control over quality. It looks like it'll have to last at least a few more years before I can actually buy anything I might consider acceptable. But there are at least signs of useful progress in this sphere.

Linux and automotive computing security

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

That's too late.
Even if you can avoid the security/safety issue in your car (which I doubt you will be able to), you will not be able to avoid it in the next place where embedded (computer) systems (security) will raise concerns (tubes, trains, planes, houses, nuclear industry, chemical industry, ... put your favourite risk here ...). It's even possible that the automotive industry is not specifically "in advance" on this topic...

The problem is taking seriously into account computer security. I had hoped in the 90s that maybe this could be done before computing invaded everything. It seems I was wrong. [1] So now, what do we do to change that state of fact (before even your old no-computer car really gets unusable)?
Switching to Linux may be an improvement.

But note that if I had the choice now, I would switch to OpenBSD. Not because of the technical quality, but because of the design target.
(Unless Linus and other developpers of the kernel clearly upgrade the priority for security of course.)

PS: Another practical idea but intended for cars manufacturers: offer brand new cars to all linux kernel developers. Now. And for BSDs devs too (come on, that business is not *so* in crisis). Let's remember them that was what Digital did 20 years ago to get Linux on its Alpha CPU.

[1] In the meantime, in my opinion, security only seriously expanded to the gaming industry and to some extent the media/telco. industry. What an irony!

Linux and automotive computing security

Posted Oct 19, 2012 12:53 UTC (Fri) by JEFFREY (guest, #79095) [Link]

"You don't want [CAN bus] in [your] vehicle."

You'd really shudder to know that CAN bus is also used in SCADA/DCS systems that operate dangerous boilers, refineries, and power plants.

Linux and automotive computing security

Posted Oct 19, 2012 13:59 UTC (Fri) by Jonno (subscriber, #49613) [Link]

CAN itself is no worse than Ethernet, except for speed and packet length limitations. On the contrary, it offers several benefits over plain ethernet, such as built-in QoS and a much lower cost to deploy.

The difference is that there are several standard abstraction layers built on top of ethernet which provides additional features, including some security features. Unfortunately these abstraction layers are way to complex to run on the 20 kHz, 8 bit system with 64 kB RAM you typically see in a sensor, leaving you the options of raw ethernet, raw CAN, or raw RS-232 for connectivity.

When given those choices, using CAN is usually a pretty good option, you just have to remember its limitations and design your application protocol with security in mind, as you wont "inherit" any from the underlying protocol, like you do with TCP/IP. (Though that is probably true anyway, as the security features of TCP/IP are quite limited).

Linux and automotive computing security

Posted Oct 15, 2012 14:14 UTC (Mon) by drag (subscriber, #31333) [Link]

> Idiotic?

Yes.

> But your entertainment system is the screen where the rear-view backup camera gets displayed.

Personally I have learned to turn my head.

> You need the computer controlling the transmission to be able to tell the computer controlling the entertainment system to start displaying the camera feed.

You can have data that goes one way.

For example it's very common in industrial applications dealing with potentially high voltage to use 'light connectors' to join disparate electrical systems. Basically you just have some infrared transmitters on one side and a infrared sensor on another and thus you can transfer information without a direct electrical connection.

So it's very possible to have a properly functioning gauges and other devices without the ability for any attacker, no matter how determined or skilled, to use your entertainment system to subvert your automobile remotely.

> And I think you'll find that by the time you hit every use case (safety interlocks that prevent changing GPS coordinates while the car is driving,

Idiotic safety controls. If I had something like that on my car I would just turn the GPS off and use my cell phone and google maps, or other equivalent. I don't need anti-features in my car. Driving is hard enough without having to fight my car for control.

> vehicular speed being to augment the GPS in tunnels, etc) you'll find that just about everything gets connected somehow.

Only if it is designed by moronic engineers.

Linux and automotive computing security

Posted Oct 15, 2012 14:18 UTC (Mon) by fuhchee (guest, #40059) [Link]

"... optical isolation ..."
"So it's very possible [to do one-way communication]"

The second does not follow from the first. The need for two-way communication comes from application requirements, and can be implemented at the physical level with wires, wireless, two unidirectional optical isolators, whatever.

Linux and automotive computing security

Posted Oct 15, 2012 16:37 UTC (Mon) by bronson (subscriber, #4806) [Link]

> Personally I have learned to turn my head.

Check out the new 2012/2013 models. Crash and fuel economy requirements have made deck heights very high and D-pillars very wide. Rearward visibility is suffering mightily.

Linux and automotive computing security

Posted Oct 16, 2012 8:54 UTC (Tue) by njwhite (guest, #51848) [Link]

>> And I think you'll find that by the time you hit every use case (safety interlocks that prevent changing GPS coordinates while the car is driving,
> Idiotic safety controls. If I had something like that on my car I would just turn the GPS off and use my cell phone and google maps, or other equivalent. I don't need anti-features in my car. Driving is hard enough without having to fight my car for control.

I quite agree. I don't know why people want this sort of thing in their cars. Indeed this article in general just made me not want to ever get a car built in the last 10 years. Of all activities, something as dangerous as driving is something I would be least comfortable reducing my control over. Is the only option for those of us who value control in driving now kit cars and antiques?

Linux and automotive computing security

Posted Oct 18, 2012 18:12 UTC (Thu) by TRauMa (guest, #16483) [Link]

Dont worry so much, all these driving helpers are a transient state anyway. Soon you'll just enter your car and relax while it will do all the driving, and even if you would be tempted to drive yourself it would be a bad idea because most lanes on the highway will be closed to human drivers due to security reasons.

Linux and automotive computing security

Posted Oct 10, 2012 21:55 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

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.

Linux and automotive computing security

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

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 (subscriber, #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.

Linux and automotive computing security

Posted Oct 10, 2012 20:33 UTC (Wed) by dashesy (guest, #74652) [Link]

I do not understand why not think of CAN bus as the wire, it is data that needs protection not the wire.

Linux and automotive computing security

Posted Oct 10, 2012 20:58 UTC (Wed) by dlang (subscriber, #313) [Link]

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.

Linux and automotive computing security

Posted Oct 10, 2012 21:07 UTC (Wed) by fuhchee (guest, #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 (subscriber, #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 (guest, #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?
(/me puts on tinfoil hat back on)

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.

funny - thanks

Posted Oct 11, 2012 5:03 UTC (Thu) by ds2horner (subscriber, #13438) [Link]

funny - thanks

funny - thanks

Posted Oct 16, 2012 17:55 UTC (Tue) by Baylink (guest, #755) [Link]

That's not apples and lemons, that's apples and antifreeze.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds