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

Groups > comp.arch.embedded > #21458

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

Show all headers | View raw

On 7/23/2015 1:49 AM, Robert Wessel wrote:
> On Wed, 22 Jul 2015 23:20:33 -0400, rickman <gnuarm@gmail.com> wrote:
>
>> 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.
>
> There are/will be inevitable points of intersection.  Things like the
> primary display will need to be attached to both the entertainment
> system and the more critical car functions.  The engine and nav system
> will need to send messages to the main display and audio system, the
> main display will configure drive system parameters ("teenager mode",
> for example).  What about the need for your car's crash safety system
> to chat with the cellular radio in the case of a crash?

Exactly.  Even if a "compromised" node does not have direct *physical*
access to a "special" bus, the fact that the compromised node can
effortlessly masquerade as ANY node on the bus(ses) to which it has
direct contact means any other gateway/bridge nodes *will* propagate
forged messages that it generates *to* that "other bus" AS IF the
messages were created by the genuine node instead.

This also assumes those gateway nodes are smart enough to recognize
*specific* traffic on "bus #1" as only legitimate *on* bus #1.  I.e.,
if a node on bus #1 forges a message that a node on bus #2 would
normally generate, the gateway *may* be naive enough to transport the
message across the protection domain even though it was detected on
the "wrong" bus!  Because the code is written to assume that traffic
on bus #1 is legitimate, regardless of content (security vulnerability).

> And no, demanding separate displays and whatnot will never fly.

Looking at a factory service manual for a Nissan Murano (we're in the
market for a new vehicle so I've been reading a lot of service manuals)
shows one or two CAN busses (depends on whether or not the vehicle has
the Advanced Driver Assistance System (ADAS) installed -- gizmo that acts
as a proxy for the driver).  The *first* CAN bus always has the following
nodes:
- Engine Control Module
- Antilock Brake System
- Tranny Control Module
- Steering Angle Sensor
- All Wheel Drive Control Unit
- Automatic Backdoor Control Module
- Combination Meter (this is a display)
- Power Steering Control Module
- Audio / Visual Control Unit
- HVAC Control
- Body Control Module
- Intelligent Power Distribution Module

When the ADAS is present, it resides on a separate CAN bus along with the
Driver Seat Control Unit and a Gateway Module (to the first bus).

So, hack any of these modules -- regardless of how "critical" they
are for the vehicle to "operate as a means of transportation" -- and
you can effectively masquerade as *any* of the other nodes on the
same physical bus.  And, potentially, as any node on the "other"
bus as well!  I.e., if the A/V Unit is hacked and emits a message
that *should* have originated from the ADAS *via* the gateway,
how can any node on the first bus know that it was NOT propagated
to the bus by the gateway?  How does any node know that it was
not generated *by* the ADAS???

> So it's not ever going to be quite a simple matter of hard physical
> separation between the critical and non-critical systems.  More likely
> a node serving a firewall/gateway function between otherwise
> segregated systems makes sense.

See above.  Physical separation/isolation doesn't buy you anything.
The (e.g., CAN) protocols don't authenticate the sender/recipient.
You have to layer an additional protocol on top of it to even
*begin* to address these issues.  And, why would you do so -- *if*
your design attitude is that "connection to the bus indicates your
authority to *use* that bus"??

The recent alleged airliner hacks took advantage of this "design
naivite" -- "if we see a command on the network that tells us
to fly sideways, we'll assume it was generated by <whatever>
would legitimately create such a command; NOT some guy sitting
in the coach cabin hacking into the in-flight ENTERTAINMENT
SYSTEM!"

> Rather than trying to implement
> security in hundreds of different nodes (maintained by a similar
> number of teams generally not communicating well with each other),
> concentrate (most) of it in the firewall node.

And a "firewall" can be any sort of packet filtering mechanism that
may, in fact reside anywhere in the network.  E.g., a VPN effectively
gives you a secure tunnel (which may or may not be encrypted).

This is why I took the action of embedding authentication protocols
in my network fabric (which is physically secure).  So, you can subvert
any node that you can gain access to (physically, etc.) and ONLY
forge the transactions in which the compromised node could legitimately
participate!

E.g., in my world, the A/V Unit would never be able to generate the
"Transmission is in Park" message (well, it *could*... but the fabric
would never route that message to anything that would recognize it *as*
the "Transmission is in Park" message and act on it as if true!)
Instead, you'd be able to claim the user is calling for the "Rear
Window Defogger" to be active; or the "ACbrrr Active" signal; etc.
(i.e., the signals that the A/V Unit *does* legitimately emit on
that vehicle!)

[In my case, this assumes you have also cracked the rolling encryption
keys to even *generate* CURRENTLY RECOGNIZABLE forms of those messages!
If you appear to be spewing jibberish (bad keys), then your node is
intentionally and deliberately cut off from the rest of the system;
it's either malfunctioning or has been compromised!  (Imagine a VPN for
each virtual communication path in the system, enforced in the *fabric*
itself!)]

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