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

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



-Lasse

On 7/22/2015 4: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.
>
> http://www.autosec.org/pubs/cars-oakland2010.pdf

I think it would be very easy to provide security between the safety 
functions and the rest of the automotive systems.  Use separate buses. 
There are *very* few military systems that support multiple levels of 
security on the same hardware... for a good reason.  They don't feel 
software can provide the level of security required unless it is very 
carefully implemented which is something they don't feel they can do for 
networking in general.  I know of one system  that was approved for 
multiple levels of security over a common network, but that took several 
years to develop and was a closed system.

Why can't they just use a separate CAN bus for the safety related gear 
from the bus they use for the infotainment and climate controls, etc? 
The outside world could connect to the core automotive functions by 
wires or if wireless is needed they can use a separate wireless 
connection with high security or at least separate the two levels of 
security with a robust firewall.

-- 

Rick

On 7/22/2015 6: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

I expect the problem is that the ECU receives commands from the gas 
pedal over the bus or maybe there is an overall monitor that can shut 
down essential functions.  Perhaps there is an anti-theft feature built 
in that works over the bus?  Clearly they have the ability to control 
various functions by the bus rather than run many pounds of wire all 
through the car.  I guess some wires are more important than others.

I will have to say it is hard to imagine a valid use case for shutting 
down the steering or the brakes.

-- 

Rick

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!

Den torsdag den 23. juli 2015 kl. 00.49.01 UTC+2 skrev rickman:
> On 7/22/2015 4: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.
> >
> > http://www.autosec.org/pubs/cars-oakland2010.pdf
> 
> I think it would be very easy to provide security between the safety 
> functions and the rest of the automotive systems.  Use separate buses. 
> There are *very* few military systems that support multiple levels of 
> security on the same hardware... for a good reason.  They don't feel 
> software can provide the level of security required unless it is very 
> carefully implemented which is something they don't feel they can do for 
> networking in general.  I know of one system  that was approved for 
> multiple levels of security over a common network, but that took several 
> years to develop and was a closed system.
> 
> Why can't they just use a separate CAN bus for the safety related gear 
> from the bus they use for the infotainment and climate controls, etc? 
> The outside world could connect to the core automotive functions by 
> wires or if wireless is needed they can use a separate wireless 
> connection with high security or at least separate the two levels of 
> security with a robust firewall.
> 

From what I've heard from people that work with this stuff that is how 
it is normally done, many separate busses access between them controlled
centrally and you would have physically open and reprogram hardware to 
bypass that  

I don't know how Chrysler screwed it up


-Lasse

On 7/22/2015 7:59 PM, Don Y wrote:
>
> 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!

If you can block access between various ports, it is *not* a single 
physical network but rather a collection of interconnected networks with 
firewalls of some type between them.

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

Yes, if that security is done in hardware.  Obviously if it is done in 
software it is rather much easier to retrofit.

-- 

Rick

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

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

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.

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