Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #21450

Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway

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>

Show all headers | View raw


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


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