Linux and automotive computing security

Posted Oct 12, 2012 7:39 UTC (Fri) by PinguTS (guest, #87177)
Parent article: Linux and automotive computing security

Sorry, but this article shows, that the author has no glue about embedded network design. He basically suggest to trade robustness and reliability for security.

The funniest thing is, when he writes: "CAN bus needs to be replaced; working with a standard IP stack, instead, means not having to reinvent the wheel."

Because what has he written? If you are familiar with networks, then you know CAN is like Ethernet. So what does he has written? "Ethernet needs to be replaced; working with a standard IP stack, instead, means not having to reinvent the wheel."

Ethernet also has no security designed in. I don't know about any Data Link Layer Protocol that has security designed in. Because security is not part of the Data Link Layer functions. Security is part of the network layer and the session layer.

That is the same for IP. Also IP has no security designed in. The security is added by the higher layers on top of IP. Like where is security in FTP, Telnet, HTTP, SMTP, POP3, SNMP, and so on. It is always added afterwards.

Then, the first paper from 2010 describes common knowledge. Because what does the paper describes? It describes, that you can make a firmware download and as such modify the behavior of an ECU. Actually, it does not matter what type of network I run or what type of OS runs on the ECU. If the authentication protocol is weak, then I can download anything. Anybody in the security knows, that authentication shall not depend on the underlying network protocol or the operating system. So, where is the connection between the two?
Especially authentication is hard in any embedded network. Think about XBox360, PS3 and so on. You have to put the keys somewhere into the devices itself, which always means there are some ways to extract those keys.

The second paper has also some not so precise descriptions. Like if written the brakes can be disabled remotely, then it means that breaking without electronics is impossible. WRONG. Thats why no current car has brake-by-wire implemented (except some prototypes). A mechanical backup is always required, because the worst case scenario is, that the power system fails and then the brakes have to work. FULLSTOP. That is a requirement in the US and in Europe (maybe no so much in India or China, I don't know).
What you loose is brake support. OK, I think most of the people will not anymore be able to brake a car without brake support. But that is a different story.

I could go on and go on.

to post comments

Linux and automotive computing security

Posted Oct 12, 2012 10:05 UTC (Fri) by ortalo (guest, #4654) [Link]

Well I understand your position (really). However, I do not agree.
Personnally, I do not want to trade robustness and reliability for security. I want robustness, reliability *and* security.

However, the level of open and verifiable guarantees that security necessitates is apparently something that manufacturers are not ready to offer. That they are not willing to offer. As a security professional, this makes me untrustworthy (and not only about security, but also about robustness and reliability by the way). And I know too that overcoming management lack of interest and lack of funding for security is hard, so...

I'll certainly concede you that it is my job to be doubtful. But I do not think I am paranoid here. And I am pretty sure that things could be done *much* better in this area.

Linux and automotive computing security

Posted Oct 12, 2012 11:44 UTC (Fri) by gnb (subscriber, #5132) [Link]

"CAN bus needs to be replaced; working with a standard IP stack, instead, means not having to reinvent the wheel."

I don't think that's as silly as you're claiming: yes, taken literally that's mixing up layers, but I'd say the author is making the point that CAN is not a suitable layer 2 for running IP over (you could probably make it work, but it'd have to be pretty horrible given the frame length limits) so to use an IP stack you'd need to replace CAN.

Linux and automotive computing security

Posted Oct 12, 2012 20:25 UTC (Fri) by ggreen199 (subscriber, #53396) [Link] (3 responses)

One thing missed on the discussion of replacing CAN with ethernet, is that CAN is priority based. You can prove which message is going to get on the bus at a given time (Because of the priority-based message id's), which you can't do on ethernet. If you were to look at the design of ARINC 664 (real time ethernet IP/TCP on aircraft), you would see that this is not trivial to solve. For critical systems on the car, it is not a slam dunk to replace CAN with ethernet.

Linux and automotive computing security

Posted Oct 12, 2012 21:05 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

> You can prove which message is going to get on the bus at a given time (Because of the priority-based message id's)

except for the tiny detail that the priority of the messages is a software thing, so it can be forged.

besides, an easy work-around for needing priority to 'prove' what message will go on a buss first is to just over-provision the network speed to a ridiculous amount. if you were to put in gig-ethernet, the priority is really unlikely to matter as the delay to wait just isn't significant.

Linux and automotive computing security

Posted Oct 12, 2012 21:15 UTC (Fri) by ggreen199 (subscriber, #53396) [Link]

Well of course a rogue box can forge the id but that is the security aspect, the safety aspect is that the priority is hardware determined. Two different things.

And of course you can over-provision the network, except when you are already pushing the limits. If you are near the limit, how do you prove which goes on the bus? This isn't theoretical, we had this very problem (on ethernet, not CAN). So where CAN does what you need, I stand by my comment it is not a slam-dunk to replace it. Just putting in ethernet doesn't prove you will meet your real-time milestone when you HAVE to.

Linux and automotive computing security

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

Not according to other comments in this thread, which suggest that Canbus transceivers can be provisioned on a board which are *physically incapable* of generating high-priority addresses.