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

Groups > comp.arch.embedded > #21446

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

Show all headers | View raw

On 7/22/2015 1:42 PM, Ian Yellowley wrote:
> On Tuesday, 21 July 2015 14:22:18 UTC-8, Don Y  wrote:
>> 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).
>>
>> Too many protection domains routinely crossed due to the method of
>> implementation.  So, how can you ever hope to retrofit "security" and
>> "reliability" after-the-fact?  It's almost inherent in CAN that you have a
>> somewhat "flat" architecture.
>
> Yes there are possibilities to do "neat things" at the expense of overall
> security. This stuff worried me enough to go back to the literature. The
> following paper seems to address a lot of the issues as well as explaining
> the typical method of interfacing between the various networks and the
> weaknesses of these approaches.

I think the programming model is something akin to having tons of
"globals" -- and the assumption that nodes won't access things that
they *shouldn't*... but, are free to access things that they *should*!

[This is apparently true of networked systems on modern aircraft!]

E.g., you can buy collision avoidance/mitigation systems that "watch"
the road/pedestrians/bicyclists and brake in the event that you *fail*
to do so!  Likewise, cruise control systems that will automatically
throttle back the "setpoint" if you creep up on the car in front of you
(of course, cruise control itself has to talk to the engine as your
proxy!).

Some cars offer an economy driving mode that does things like
drop out the ACbrrr compressor when you accelerate.  Others allow
the responsiveness of the steering to vary with speed as well as
"driver preference".

So, you've got all these little "hooks" poking at various settings,
controls, sensors, etc. in the "system" (vehicle) with nothing really
deciding "who" *should* see "what".

In my design of the automation system, here, I opted for wired comms
for everything (because even encrypted wireless traffic can be victimized
in DoS attacks!), encryption and, essentially, a dynamically reconfigured
"one port firewall" on each and every port serviced by the network
switch.  So, if <something> manages to get access to a particular
network drop (e.g., the weather station on the roof or the "convenience
port" on the front porch), the only traffic that will be accepted by that
port ON THE NETWORK SWITCH is the traffic that it is *expected* to
generate.

For example, the weather station never tries to visit google.com.
Or, download files.  Or...  So, any traffic on that port attempting
to do those things is blocked and the port is shut down.

As such, you could spend a night in our guest bedroom and freely access
The Internet from any of the convenience ports located in that room.
But, you won't be able to access any of the other automation devices
in the house -- no matter how hard you try (you'd need *physical*
access to the network switch to bypass its security).

So, you can have a single *physical* network that is partitioned
into different logical security domains.  E.g., the security camera
at the front door can deliver streaming video to your laptop in
the guest bedroom (if I so permit) but *nothing* to/from the weather
station node on the roof.  Nor any commands to (e.g.) unlock the
front door!

You have to think about these things *before* implementation.
retrofitting security is hard and expensive!

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