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 1 of 2  [1] 2  Next page →

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

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.

[toc] | [next] | [standalone]

#21408

On 7/21/2015 12: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.

There's nothing uncommon about this sort of practice.  How many companies
have their "public presence" tied, somehow, to their *private* intranets?
"For convenience".

In the late 70's I designed a (LORAN-C) autopilot for use on maritime vessels.
Like today's GPS's, you could specify a *destination* (lat-lon) -- instead of
just a "heading".  This immediately suggests avenues for abuse:  go below
deck and work on <whatever>, take a nap, etc.  "Who's minding the ship??"

I suggested tying the autopilot to an alarm/annunciator that would alert
(annoy) the vessel's captain when a destination was reached (otherwise,
the boat would overshoot the destination -- as the autopilot only had
control of rudder -- and then "loop back", repeatedly).

Boss said, "The *first* thing the captain is going to do is cut the
wires to that annunciator...".  So, instead of being touted as the
world's first "consumer" closed loop autopilot, it would be remembered
as "that annoying, nagging beast".

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

I think the only legislative solution is to mandate public disclosures of
these sorts of things.  No "gag orders" in litigation/settlements, etc.
I.e., you can keep settlement terms, amount$, etc. quiet -- but can't suppress
the technical findings that come to light.

Sadly, the rest is up to "good engineering"...

Unfortunately, I don't think many folks have the skillsets, mindsets or
*motivation* to look at vulnerabilities in their products (witness how
wildly enthusiatic -- NOT! -- most folks are about writing formal
specificaations, comprehensive testing/documentation, etc).  Boss doesn't
care about those ("We'll worry about it later") so your efforts are
likely to be seen as "obstructionist".

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

#21414

On 22/07/15 06:00, Don Y wrote:
> On 7/21/2015 12:28 PM, Rob Gaddi wrote:
>> "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."

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

> I think the only legislative solution is to mandate public disclosures of
> these sorts of things.

Perhaps, but please observe the actual behaviour of your government over 
the last decade. This indicates that their response is likely to be to 
focus on declaring war on hackers and security engineers, with massive 
enforcement and penalties for looking for, discovering or exposing such 
vulnerabilities. To say nothing of utilising them... The DMCA comes to 
mind as a precursor... fix the symptom not the cause.

> Sadly, the rest is up to "good engineering"...

Too hard. Engineers are human, all too human, and their bosses are lizards.

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

#21420

On 7/21/2015 4:49 AM, Clifford Heath wrote:
> On 22/07/15 06:00, Don Y wrote:
>> On 7/21/2015 12:28 PM, Rob Gaddi wrote:
>>> "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."
>
>>> 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.
>
>> I think the only legislative solution is to mandate public disclosures of
>> these sorts of things.
>
> Perhaps, but please observe the actual behaviour of your government over the
> last decade. This indicates that their response is likely to be to focus on
> declaring war on hackers and security engineers, with massive enforcement and
> penalties for looking for, discovering or exposing such vulnerabilities. To say
> nothing of utilising them... The DMCA comes to mind as a precursor... fix the
> symptom not the cause.

Don't mistake my suggestion as an indication of what I think *will*
happen.  Rather, what I think is the "best compromise" between all the
stakeholders.

Businesses won't want to be legislated into more regulations.
Other groups would claim "The Market" will (magically!) solve
all these problems (gleefully ignoring the costs incurred -- by
OTHERS -- along the way).

OTOH, its hard to argue against *disclosure*.  You can wrap it in
as many "alleged" and "suspected" qualifiers as you want.  But,
exposing flaws instead of burying them in some lawsuit "settlement"
seems the best compromise mechanism for driving solutions to the
problems.

"Obscurity" just allows problems to linger.

Publicly disclose a vulnerability and you can bet your ass folks
will rush to plug the holes quickly -- instead of just letting it
sit in litigation for years, "as is".

>> Sadly, the rest is up to "good engineering"...
>
> Too hard. Engineers are human, all too human, and their bosses are lizards.

Despite being a cynic, I have more faith in folks.  All my boss/client
can do to force me to "let go" of a project is to take it away from me,
unfinished.  He's still stuck with getting it finished, afterwards!
If I'm good at my craft, he risks exposing a shoddy product to a market
that can then judge him, publicly (with $$$, or -$$$ as the case may be!).

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

#21416

Don Y <this@is.not.me.com> writes:
> Boss said, "The *first* thing the captain is going to do is cut the
> wires to that annunciator...".  So, instead of being touted as the
> world's first "consumer" closed loop autopilot, it would be remembered
> as "that annoying, nagging beast".

My dad was chief on a tugboat.  Once they tried to tie a computer to his
engine, and he made them cut the wires to the engine - and leave the
annunciator.

He did *not* want a computer in charge of his boat, ever.

He *did* want the computer yelling at him if something might be going
wrong.

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

#21419

On 7/21/2015 5:37 PM, DJ Delorie wrote:
>
> Don Y <this@is.not.me.com> writes:
>> Boss said, "The *first* thing the captain is going to do is cut the
>> wires to that annunciator...".  So, instead of being touted as the
>> world's first "consumer" closed loop autopilot, it would be remembered
>> as "that annoying, nagging beast".
>
> My dad was chief on a tugboat.  Once they tried to tie a computer to his
> engine, and he made them cut the wires to the engine - and leave the
> annunciator.

Then, he wouldn't be the sort who would even *consider* buying such
a device -- as its whole purpose was to *steer* the vessel.  (silly
to have an annunciator that tells him when *he* has piloted the
vessel to *his* desired destination!  :> )

OTOH, thousands of "small operators" (e.g., lobstermen) setting out
to open sea each day could easily be seen to treat the autopilot as an
"unpaid hand" -- i.e., it pilots the boat while they ready the pots,
nets, lines, etc.  Before leaving port, key in the lat-lon's of the
planned drops for your pots (or, locations of previously dropped pots),
set the throttle and go!  *Knowing* that it will effectively stop
(circle?) when it reaches it's destination can leave them free to do
the other things that their "free" eyes and arms can now manage.

> He did *not* want a computer in charge of his boat, ever.
>
> He *did* want the computer yelling at him if something might be going
> wrong.
>

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

#21411

On Tuesday, 21 July 2015 11:29:40 UTC-8, 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.

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.

Ian

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

#21412

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.

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

#21441

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

Ian

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

#21444

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

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

#21447

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

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

#21493

On Wed, 22 Jul 2015 17:33:06 -0700, lasselangwadtchristensen wrote:

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

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

If I had to guess?  Someone decided they could save something on the 
order of $5 per car by just running one network, and someone else 
approved it.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#21495

Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
> If I had to guess?  Someone decided they could save something on the 
> order of $5 per car by just running one network, and someone else 
> approved it.

An awful lot of these failures come from thinking (erroneously) that
nobody would bother carrying out a given type of attack, rather than the
attack itself being too subtle for the defender to conceive of.

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

#21500

On 7/24/2015 10:23 AM, Paul Rubin wrote:
> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
>> If I had to guess?  Someone decided they could save something on the
>> order of $5 per car by just running one network, and someone else
>> approved it.
>
> An awful lot of these failures come from thinking (erroneously) that
> nobody would bother carrying out a given type of attack, rather than the
> attack itself being too subtle for the defender to conceive of.

+42

"We don't need to reinforce the doors to the cockpit and provide
DURABLE locks.  think of all the fuel that would be consumed transporting
those extra few pounds back and forth and back and forth across the
country day in and day out!  Who the hell would bother disturbing the
flight crew??  That would be just plain SILLY!  At the very least, the
offender would be scolded and ordered back to their seat.  And, probably
face a HEAP of trouble when the aircraft *lands*! ...  Huh?  What's
that?  You mean the offender doesn't INTEND for it to land???  WTF??"

In my case, why "protect" the network drops in my guest bedroom from
accessing/hacking my automation system?  Do I trust folks enough to
invite them into my home -- but *distrust* them and want to protect
myself from THEIR malicious hacks?

This stupidly ignores the possibility that their *laptop* may initiate
an attack based on malware already contained on it (or, attempt to
connect to other machines in my home that don't normally "see the
outside world") *or* malware that infects them during their visit!
"They" (my houseguests) may have no role in the event -- other than
plugging the laptop into the network connector!

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

#21507

Am 24.07.2015 um 20:22 schrieb Don Y:

> "We don't need to reinforce the doors to the cockpit and provide
> DURABLE locks.

I'll have to ask you to refrain from using that particular argument.

Earlier this year in the Alps, 150 people, including an entire class 
from a school not to far from here, died in a plane crash _enabled_ by 
exactly those: reinforced door and a durable lock to the cockpit.  The 
reason was that the cockpit door prevented all attempts to stop a 
suicidal co-pilot from taking down the plane and everyone on board.

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

#21502

>>
>> I don't know how Chrysler screwed it up
>>

Management:  You guys need to get these new features working, STOP 
working on things that don't sell cars !

Engineers:  If we don't fix these bugs, someone might be able to hack 
our hardware !

Management:  Don't worry about hackers, they are not that smart.

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

#21446

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!

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

#21448

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

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

#21443

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

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

#21445

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web