Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #21450
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway |
| Date | 2015-07-22 23:20 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <mopmf8$s70$1@dont-email.me> (permalink) |
| References | <mom6g4$i05$1@dont-email.me> <c94af3b6-01e5-4bbd-bf2c-f2f4b1e50e03@googlegroups.com> <momgml$1hi$1@speranza.aioe.org> <2b477b24-3685-41cb-977f-9832e6803b98@googlegroups.com> <mopkn7$jik$1@speranza.aioe.org> |
On 7/22/2015 10:49 PM, Don Y wrote: > On 7/22/2015 3:30 PM, lasselangwadtchristensen@gmail.com wrote: >> Den onsdag den 22. juli 2015 kl. 00.22.18 UTC+2 skrev Don Y: >>> On 7/21/2015 2:35 PM, Ian Yellowley wrote: >>> >>>> I wonder why there should be any connection between these networks, I >>>> can see consolidation of steering, suspension and braking info for >>>> stability but the rest??? There would seem to be huge differences in >>>> required bandwidth, latency and reliability so is there a cost >>>> saving? I >>>> was involved in the design of steer by wire systems many years ago and >>>> the extent to which we went to provide reliability, multiple layers of >>>> redundancy and isolation from other systems were fairly extreme. This >>>> was in a University lab...I would expect at least that from a >>>> commercial >>>> product. >>> >>> From the (limited) exposure I've had to automotive control systems, >>> there >>> doesn't seem to be a cohesive, integrated "system design" at work. >>> Instead, there are all these little islands of control that are hacked >>> together and "integrated" after-the-fact. >>> >>> [Often, individual subsystems are farmed out to third parties. E.g., >>> you >>> can bet that the auto manufacturer doesn't design the navigation system, >>> entertainment system, security system -- perhaps not even the engine >>> control system itself!] >>> >>> E.g., why would the ECU need to talk to anything other than the >>> *engine*? >>> "Ah, but we can tell the air conditioning compressor to disengage >>> when we >>> are calling for extra demand from the engine! So, let the *engine* tell >>> the air conditioner to 'pause' -- instead of having some higher level of >>> integration impose those rules. Likewise, let the tranny controller >>> tell >>> the door locks to engage when the vehicle is put in gear (or, when the >>> wheels attain a certain speed). >> >> afaiu from a guy I know that works a lot with car electronics as in >> building >> ECUs, gearbox controllers and integrating them with the different >> system in >> a number of different cars, most of the systems are stand alone and >> mostly >> listen to each other, i.e. the ECU does nothing but run the engine and >> broadcast what it is doing, ditto for all the other systems >> >> so if the doorlocks see the tranny broadcasting a speed over x it can >> decide to lock the doors, if the AC see the engine broadcast a load >> over x >> it can decide to pause, if the ECU see the ABS module broadcast >> wheelspeeds >> that indicate wheelspin it can turn down the power >> >> I guess it is similar to the unix philosophy, do one thing and do it well > > Modern cars are more highly (functionally) integrated. > > There is little inherent in the protocols that directly supports > authentication. E.g., a node has no *proof* that a message/datum > actually originated from a node that is *intended* to source messages > of that type. So, the "radio link" -- once hacked -- can *forge* a > message indicating the engine speed is X or the shift lever has been > placed in 'R' or... Only if the radio link has access to the bus for the engine and transmission. It is a simple matter to maintain adequate separation between the core functions and the peripheral functions. > You have to consider any node in the system (modern vehicles have > *many* nodes!) as potentially being compromised. Once compromised, > how reliable are your protocol-based security measures? Can I hack > the door locks (body controller) and get a beachhead there? Or, > the entertainment system? Or... > > The security model seems to be one of "don't expect anything *foreign* > or adversarial *inside* the vehicle". Sort of like most businesses > try to keep adversaries *out* of their "intranets" but, do little > to protect against an adversary that's already *inside* the firewall > (e.g., a PC that becomes infected from a virus transported across > the protection domain on a thumb drive!) > > If, instead, you treat each interaction as a secure communication, > then you don't care where (physical node or bus) the communication > originated -- it self-authenticates. > > Imagine lots of VPN's inside the box -- even a VPN *mesh*! An > adversary can break physical security but still be locked out because > it doesn't have the credentials for the VPN's of interest. > > Finally, if you encode rules in the fabric itself (not really possible > with the distributed nature of CAN), then you can ensure any infiltration > is limited to mimicking the functionality that it has supplanted. E.g., > your door lock system can send and receive only messages associated with > door locks -- not braking functions, entertainment system functions, > environmental controls, etc. > > So, you limit the "damage" to the subsystem that has been compromised > and nothing more -- you can masquerade ONLY as the subsystem that > you've hacked and can't do anything more than that subsystem could do, > > [This is where the lack of authentication leaves most systems vulnerable > in unnecessarily cascaded "faults"] Or you say, screw the authentication and only allow external access to non critical functions by hardware separation. -- Rick
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Semi-OT: Hackers Remotely Kill a Jeep on the Highway Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-07-21 19:28 +0000
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 13:00 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Clifford Heath <no.spam@please.net> - 2015-07-21 21:49 +1000
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 18:55 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway DJ Delorie <dj@delorie.com> - 2015-07-21 20:37 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 18:47 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Ian Yellowley <iany99@gmail.com> - 2015-07-21 14:35 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 15:22 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Ian Yellowley <iany99@gmail.com> - 2015-07-22 13:42 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 18:48 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway lasselangwadtchristensen@gmail.com - 2015-07-22 17:33 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-07-24 16:51 +0000
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:23 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-24 11:22 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-24 21:49 +0200
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway hamilton <hamilton@nothere.com> - 2015-07-24 12:45 -0600
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-22 16:59 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 21:30 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway lasselangwadtchristensen@gmail.com - 2015-07-22 15:30 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 18:53 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-22 19:49 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 23:20 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Robert Wessel <robertwessel2@yahoo.com> - 2015-07-23 03:49 -0500
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-23 03:26 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-23 12:09 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-23 21:38 +0200
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-23 16:36 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-23 23:56 +0200
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-24 13:25 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-23 11:32 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Ed Prochak <edprochak@gmail.com> - 2015-07-21 20:00 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 00:57 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Mel Wilson <mwilson@the-wire.com> - 2015-07-26 15:06 +0000
csiph-web