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

Groups > comp.arch.embedded > #21407 > unrolled thread

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

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#21449

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...

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"]

[toc] | [prev] | [next] | [standalone]

#21450

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

[toc] | [prev] | [next] | [standalone]

#21455

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?

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

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.  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.

[toc] | [prev] | [next] | [standalone]

#21458

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!)]

[toc] | [prev] | [next] | [standalone]

#21461

On 7/23/2015 6:26 AM, Don Y wrote:
> 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.

That is based on the assumption that there are messages that can travel 
from the insecure bus to the secure bus.  Obviously that has to be 
prevented in all cases.


> 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).

Yes, I suppose a total idiot might design a secure system this way.  Or 
they would design it to preserve security.


>> 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???

Why would the ADAS need to *control* any of the units on the secure bus? 
  The ADAS might have commands to query devices on the secure bus, but 
if you allow control that is a way for hackers to get in.

How does the A/V unit get hacked?   Does it have a wireless connection? 
  If so, that is a problem and needs to be corrected.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21467

Am 23.07.2015 um 12:26 schrieb Don Y:

> 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.

Only if the node it's masquerading as is on the same bus as the 
compromised one.  And only if the firewall/gateway node is given no 
means to recognize the fact that there are now two data streams 
purporting to be from the same node.

> 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!

That error case is not a practically relevant one.  Gateways have enough 
work on their plate as-is.  They have to know which message they're 
supposed to receive on which bus, and which they're to echo/send, or 
they just couldn't handle the work load.  Otherwise they would flood 
each network with the traffic of every other one.

> Because the code is written to assume that traffic
> on bus #1 is legitimate, regardless of content (security vulnerability).

In practice, it's not.  Car network designers really aren't _that_ daft 
(presently publicised bad example case possibly excluded).

> 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

That's quite a small, old-fashioned layout by today's standards.  A 
current-model passenger car would have between twice and four times as 
many CAN ECUs as that, and putting drive train control units on the same 
CAN network as, say A/V or HVAC ones has gone out of fashion about a 
decade ago.

There are still some nodes that are so central that it would be hard to 
the point of impossible to isolate their security-sensitive functions 
from their other ones, e.g. the steering wheel group.  These days 
buttons and levers on and around the steering wheel (for very good 
reason, too) control a wild mix of systems, only some of which are 
critical (cruise control, driver assistance, control over what gets 
displayed in the combination display, blinkers, wipers, radio, 
telephone, ...).  And then there's the airbag sitting in the middle of 
all that.  And the meaning of buttons will change based on what the 
multimedia central display currently shows, or what options were ordered 
with the car.  Good luck trying to implement security isolation zones in 
_that_!

And then new legal requirements like "E-Call" practically require to 
break any isolation barriers between established critical systems and 
others like the multimedia/navigation/telephone ones that are by _huge_ 
popular demand about as architecturally open and as connected as a 
desktop PC, and consequently about as security conscious as those.

It's basically a miracle they largely managed to keep MS bloody Windows 
out of those boxes so far, and now they're supposed to perform 
survival-critical emergency tasks!  That's insanity, and I'm quite sure 
everybody involved knows it.

> 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?

For starters, the gateway itself knows that (because it should have been 
sending that message, not receiving it).  And it doesn't take much 
engineering to make such extra message trains recognizable.  About the 
simplest one is a rolling counter in the original messages.  That 
doesn't allow yet to detect which of two message streams is actually 
genuine, but it does allow detection that something's foul in the state 
of Denmark.

[toc] | [prev] | [next] | [standalone]

#21469

On 7/23/2015 3:38 PM, Hans-Bernhard Bröker wrote:
>
> There are still some nodes that are so central that it would be hard to
> the point of impossible to isolate their security-sensitive functions
> from their other ones, e.g. the steering wheel group.  These days
> buttons and levers on and around the steering wheel (for very good
> reason, too) control a wild mix of systems, only some of which are
> critical (cruise control, driver assistance, control over what gets
> displayed in the combination display, blinkers, wipers, radio,
> telephone, ...).  And then there's the airbag sitting in the middle of
> all that.  And the meaning of buttons will change based on what the
> multimedia central display currently shows, or what options were ordered
> with the car.  Good luck trying to implement security isolation zones in
> _that_!

So why would there be only one bus to the steering column?  My car has 
no CAN bus I'm pretty sure and has half those functions so that many 
wires.  Reducing this to two buses should be duck soup.

Using one UI for both secure and insecure functions is problematic and 
should not be done.


> And then new legal requirements like "E-Call" practically require to
> break any isolation barriers between established critical systems and
> others like the multimedia/navigation/telephone ones that are by _huge_
> popular demand about as architecturally open and as connected as a
> desktop PC, and consequently about as security conscious as those.

Why would any of that have to connect to the secure systems?  If it is 
needed to send a command to not allow the car to start or even to shut 
it down, that command would need a protocol that can not be duplicated, 
a secure protocol through a secure control point.


> It's basically a miracle they largely managed to keep MS bloody Windows
> out of those boxes so far, and now they're supposed to perform
> survival-critical emergency tasks!  That's insanity, and I'm quite sure
> everybody involved knows it.

Really?  What critical emergency tasks are handled by the cell phone 
interface in a car?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21474

Am 23.07.2015 um 22:36 schrieb rickman:
> On 7/23/2015 3:38 PM, Hans-Bernhard Bröker wrote:

>> There are still some nodes that are so central that it would be hard to
>> the point of impossible to isolate their security-sensitive functions
>> from their other ones, e.g. the steering wheel group.  These days
>> buttons and levers on and around the steering wheel (for very good
>> reason, too) control a wild mix of systems, only some of which are
>> critical (cruise control, driver assistance, control over what gets
>> displayed in the combination display, blinkers, wipers, radio,
>> telephone, ...).  And then there's the airbag sitting in the middle of
>> all that.  And the meaning of buttons will change based on what the
>> multimedia central display currently shows, or what options were ordered
>> with the car.  Good luck trying to implement security isolation zones in
>> _that_!
>
> So why would there be only one bus to the steering column?

Because the electric pass-through mechanism from fixed to rotated 
assembly is brittle enough with just a few wires.  Adding wires makes it 
worse.

> Using one UI for both secure and insecure functions is problematic and
> should not be done.

That assumes the distinction is just two-fold.  So: is the navigation 
system's next-turn indicator to be secure or not?  Or the indication 
motor temperature gauge?  Or the one for outside temperature?

How much place would you need in the central behind-the-wheel 
combination display to be able to reserve a dedicated area (and isolated 
hardware to control it!) per security level?  There's only that much 
space available...

It's really not that simple. Automotive security involves not just data 
security.  Some of it is safety-oriented UI design.  E.g. all those user 
input devices are on and around the steering wheel for a reason: not 
because their function is safety-critical, but because it's 
safety-critical that the driver should keep his hands on the wheel, 
which _is_ safety-critical.

And then there's that other unholy beast, called "the market", which 
flat-out _demands_ that of course it must be possible to navigate the 
entire 6000-entry MP3 collection while driving, and without taking the 
hands off the wheel.  So now you "have to" put multi-purpose navigation 
buttons on the wheel, and a free-text display behind it that can show 
full ID3 tags, or people and magazines will laugh at your "prehistoric" 
infotainment system.

>> And then new legal requirements like "E-Call" practically require to
>> break any isolation barriers between established critical systems and
>> others like the multimedia/navigation/telephone ones that are by _huge_
>> popular demand about as architecturally open and as connected as a
>> desktop PC, and consequently about as security conscious as those.
>
> Why would any of that have to connect to the secure systems?

Because it's the secure systems that diagnose a crash. eCall, in case 
you missed it, is an upcoming government requirement to implement an 
Automated Crash Response via cell-phone emergency calls, coupled with 
GPS and manual interaction.  Basically, OnStar by law.

[toc] | [prev] | [next] | [standalone]

#21497

On 7/23/2015 5:56 PM, Hans-Bernhard Bröker wrote:
> Am 23.07.2015 um 22:36 schrieb rickman:
>> On 7/23/2015 3:38 PM, Hans-Bernhard Bröker wrote:
>
>>> There are still some nodes that are so central that it would be hard to
>>> the point of impossible to isolate their security-sensitive functions
>>> from their other ones, e.g. the steering wheel group.  These days
>>> buttons and levers on and around the steering wheel (for very good
>>> reason, too) control a wild mix of systems, only some of which are
>>> critical (cruise control, driver assistance, control over what gets
>>> displayed in the combination display, blinkers, wipers, radio,
>>> telephone, ...).  And then there's the airbag sitting in the middle of
>>> all that.  And the meaning of buttons will change based on what the
>>> multimedia central display currently shows, or what options were ordered
>>> with the car.  Good luck trying to implement security isolation zones in
>>> _that_!
>>
>> So why would there be only one bus to the steering column?
>
> Because the electric pass-through mechanism from fixed to rotated
> assembly is brittle enough with just a few wires.  Adding wires makes it
> worse.

You snipped the part of my post that you should have read.


>> Using one UI for both secure and insecure functions is problematic and
>> should not be done.
>
> That assumes the distinction is just two-fold.  So: is the navigation
> system's next-turn indicator to be secure or not?  Or the indication
> motor temperature gauge?  Or the one for outside temperature?
>
> How much place would you need in the central behind-the-wheel
> combination display to be able to reserve a dedicated area (and isolated
> hardware to control it!) per security level?  There's only that much
> space available...
>
> It's really not that simple. Automotive security involves not just data
> security.  Some of it is safety-oriented UI design.  E.g. all those user
> input devices are on and around the steering wheel for a reason: not
> because their function is safety-critical, but because it's
> safety-critical that the driver should keep his hands on the wheel,
> which _is_ safety-critical.
>
> And then there's that other unholy beast, called "the market", which
> flat-out _demands_ that of course it must be possible to navigate the
> entire 6000-entry MP3 collection while driving, and without taking the
> hands off the wheel.  So now you "have to" put multi-purpose navigation
> buttons on the wheel, and a free-text display behind it that can show
> full ID3 tags, or people and magazines will laugh at your "prehistoric"
> infotainment system.

Nothing you have mentioned nullifies the need for isolation of the 
communications function of secure and insecure operations.

I have worked on military radios which solve exactly the same type of 
problems.  So clearly it is doable.  Their requirements are for as near 
absolute security as possible so that it impacts price.  But that can 
easily be mitigated by not focusing on attacks through the manufacturing 
channels (yes, the military worries about back doors built into 
commercial chips) and accepting commercial levels of security rather 
than state secret levels.  That is, being as secure as credit card 
processing rather than NATO communications.


>>> And then new legal requirements like "E-Call" practically require to
>>> break any isolation barriers between established critical systems and
>>> others like the multimedia/navigation/telephone ones that are by _huge_
>>> popular demand about as architecturally open and as connected as a
>>> desktop PC, and consequently about as security conscious as those.
>>
>> Why would any of that have to connect to the secure systems?
>
> Because it's the secure systems that diagnose a crash. eCall, in case
> you missed it, is an upcoming government requirement to implement an
> Automated Crash Response via cell-phone emergency calls, coupled with
> GPS and manual interaction.  Basically, OnStar by law.

None of that requires that the comms capability have any *controlling* 
access to the safety systems.  Don't make easy problems hard.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21460

On 7/23/2015 4: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?
>
> And no, demanding separate displays and whatnot will never fly.

Why not?  If that is what safety requires, that is how it will be done. 
  That is why the brakes are split into two circuits.  It doesn't 
require "two" displays.  It only requires that the engine speed and car 
speed are reported through separate electronics in the display.  I know 
my car does that anyway... because it costs less.


> 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.  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.

If you need security,  you do what it takes for security.  Two buses are 
not a problem.  Yes, it's that simple.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21421

On Tuesday, July 21, 2015 at 3:29:40 PM UTC-4, Rob Gaddi wrote:
> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
> 
> "Uconnect, an Internet-connected computer feature in hundreds of 
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle's 
> entertainment and navigation, enables phone calls, and even offers a Wi-Fi 
> hot spot. And thanks to one vulnerable element, which Miller and Valasek 
> won't identify until their Black Hat talk, Uconnect's cellular connection 
> also lets anyone who knows the car's IP address gain access from anywhere 
> in the country."
> 
> Since they've so conveniently networked the entertainment system together 
> with the steering, brakes, and transmission, an exploit into the former 
> is an exploit into the latter.
> 
> So the discussion topic for all of us engineers is: whose job should it 
> be to stop this sort of nonsense from occurring.  Ideally there'd be some 
> sort of government standards dictating what security measures need to be 
> taken, but practically government's understanding of technology 
> occasionally covers the toaster.  Is it each of our jobs to call stop the 
> presses when we something so blatantly stupid, and refuse at the expense 
> of our jobs to work on a security flawed project?
> 
> -- 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

This would be on topic at comp.risks
Probably is there already.

ed

[toc] | [prev] | [next] | [standalone]

#21424

On 7/21/2015 3:28 PM, Rob Gaddi wrote:
> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
>
> "Uconnect, an Internet-connected computer feature in hundreds of
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle’s
> entertainment and navigation, enables phone calls, and even offers a Wi-Fi
> hot spot. And thanks to one vulnerable element, which Miller and Valasek
> won’t identify until their Black Hat talk, Uconnect’s cellular connection
> also lets anyone who knows the car’s IP address gain access from anywhere
> in the country."
>
> Since they've so conveniently networked the entertainment system together
> with the steering, brakes, and transmission, an exploit into the former
> is an exploit into the latter.
>
> So the discussion topic for all of us engineers is: whose job should it
> be to stop this sort of nonsense from occurring.  Ideally there'd be some
> sort of government standards dictating what security measures need to be
> taken, but practically government's understanding of technology
> occasionally covers the toaster.  Is it each of our jobs to call stop the
> presses when we something so blatantly stupid, and refuse at the expense
> of our jobs to work on a security flawed project?

No need for government standards on the technology.  The existing tort 
law has as much or more effect on auto makers.  They will perform all 
sorts of gyrations to minimize the impact of mistakes via law suits.  If 
the government sets mandates on the technology auto makers will use that 
as their defense to say they performed due diligence.  Whey users ask 
why the system has other types of problems such as lacking features or 
poor performance, the auto makers will point to the government standards 
saying they limit what they are allowed to do.

Instead the government should make it easier to hold auto makers 
accountable for their mistakes.  I haven't driven any of the fancy newer 
cars, but I would be willing to bet the first time you use the "smart" 
systems to have to click an OK on the user agreement that has two 
portions which are not in the consumer's best interest.  The first is a 
limitation of liability which attempts to prevent law suits, but is not 
perfect.  The other is a requirement of the user to indemnify the auto 
maker making it impossible to ever collect on a liability claim if the 
user does manage to win a suit.  Both of these provisions should be 
outlawed by federal law.

History has shown that auto makers try to use federal standards to limit 
their liability.  We can prevent this by proactive measures in 
electronic technology liability law.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21543

On Tue, 21 Jul 2015 19:28:05 +0000, Rob Gaddi wrote:

> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
> 
> "Uconnect, an Internet-connected computer feature in hundreds of
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the
> vehicle’s entertainment and navigation, enables phone calls, and even
> offers a Wi-Fi hot spot. [ ... ] So the discussion topic for all of us 
> engineers is: whose job should it
> be to stop this sort of nonsense from occurring.  Ideally there'd be
> some sort of government standards dictating what security measures need
> to be taken, but practically government's understanding of technology
> occasionally covers the toaster.  Is it each of our jobs to call stop
> the presses when we something so blatantly stupid, and refuse at the
> expense of our jobs to work on a security flawed project?

Here it is.  So you could start your car from your smart phone, etc.  
(comp.risks): 
==================================
Date: Tue, 21 Jul 2015 13:03:21 -0700 From: Lauren Weinstein
<lauren@vortex.com>
Subject: Fiat Chrysler "connected car" bug lets hackers take over Jeep
remotely

http://arstechnica.com/security/2015/07/fiat-chrysler-connected-car-bug-
lets-hackers-take-over-jeep-remotely/

  Uconnect, a "connected car" system sold in a number of vehicles produced
  by Fiat Chrysler for the US market, uses the Sprint cellular network to
  connect to the Internet and allows owners to interact with their vehicle
  over their smartphone--performing tasks like remote engine start,
  obtaining the location of the vehicle via GPS, and activating anti-theft
  features. But vulnerabilities in Uconnect, which Fiat Chrysler has
  issued a patch for, made it possible for an attacker to scan Sprint's
  cellular network for Uconnect-equipped vehicles, obtaining their
  location and vehicle identification information.  Miller and Valasek
  demonstrated that they could then attack the systems within the car via
  the IP address of the vehicle, allowing them to turn the engine of the
  car off, turn the brakes on or off, remotely activate the windshield
  wipers, and take control of the vehicle's information display and
  entertainment system. Miller and Valasek also found that they could take
  remote control of the steering of their test vehicle, the aforementioned
  Jeep Cherokee--but only while it was in reverse.

Thinking about what hackers will do to *autonomous* vehicles.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web