Expanding my CAN knowledge

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Expanding my CAN knowledge

Chuck Hackett
(try #2 - very strange.  When I create a message to the list from scratch it
doesn't work.  When I reply to a message it works ... oh well ...)

(try #3 - maybe messages can't have attachments so I moved the docs to my
DropBox.  When the message below references attachments, use the following
links:
    CurrentSettings.pdf ->
https://www.dropbox.com/s/a3hb5360rt3yhey/CurrentSettings.pdf?dl=0
    NewSettings_1_Mile.pdf ->
https://www.dropbox.com/s/cuudi05zlhx8lo4/NewSettings_1_Mile.pdf?dl=0
    NewSettings.pdf ->
https://www.dropbox.com/s/5nlj7bt182189ie/NewSettings.pdf?dl=0
)

First, thanks to John Dammeyer for helping me get 'reconnected' to the list.

For about seven years I have been working on a project to develop an
automatic signal system for the ride-on railroad hobby (mostly 1.5" scale
but also 1").  

My locomotive (1.5" scale, 7.5" gauge):
http://whitetrout.net/Chuck/images/8444%20Joan%20&%20Chuck%20at%20KC.jpg 

The system is based on distributed logic (no central PC).  The controllers
are distributed along the right-of-way and connected by a power bus (pair of
#16) and a data bus (CAT-5 cable).  The controllers detect the presence of a
train in a track segment by detecting the wheels shorting the two rails
together.

The controllers are my own design and manufacture (ATMega1284p with MCP2515
CAN ctlr and MCP2550 bus driver among other things).  Also, I have a 20k
resistor on the 'slope control' pin of the MCP2550 which limits the slew
rate to about 17 volts per usec.

The largest installation is my test installation at Central Pasco and Gulf
Railroad (http://www.cpgrr.org).  We have 19 controllers installed
controlling about 60 three-lamp(LED) signal heads and sampling about 100
tracks.  The entire system draws about 2A at 16VDC.

The current power/data bus length is approximately 3,500 to 4,000 feet (have
not measured it).

When I started I know nothing about CAN but I had done a lot of
communications software and I liked the multi-master capabilities along with
the automatic bus arbitration.  With the help of some examples and help from
this email list things have gone well so far.

Living in Florida (lightning capitol of the world) It has been a challenge
dealing with 4 wires >3,000 feet long along a railroad in the woods
connecting controllers which also have to be connected to 1,000's of feet of
aluminum rail in intimate contact with the ground.  Protecting the MCP2550
CAN driver has been the most challenging (should have mounted them in
sockets!) but I think I finally have a handle on it now.

All of the parameters to the MCP2515 (PSEG, SEG1, SEG2, etc.) were confusing
but, with the example code I got up and running.  As the bus length grew and
I started getting errors due to speed & cable length.  All I did was turn
down the bus speed (changed the clock source).

(finally) My issue: As I mentioned, the bus is now over 3,500 feet in length
and I'm getting situations (lost messages) where it 'smells' like
controllers at one end of the bus are causing errors at the other end -- or,
maybe I'm at the limit of the ability for the signal to get through
(resistance) as opposed to a 'length' issue.

I am currently running at 19,200 bps bus speed.  The parameters to the
MCP2515 are (remember, these came from example code and these numbers were
originally for a higher bit rate):

SJW = 4 TQ
BTLMODE = True
Sampling = once
PRSEG (propagation segment) = 5 TQ
PHSEG1 (Phase Segment 1) = 6 TQ
PHSEG2 (Phase Segment 2) = 4 TQ

I made up a spreadsheet to get more familiar with all the interactions.  See
attached "CurrentSettings.pdf" for details like TQ, etc.  Note that this
spreadsheet implies that, with those parameters, I should be able to cope
with a 4,012 foot bus length.

I don't know why they had SJW set to 4.  From my reading, when using xtals,
SJW of 1 should be good enough.  In some of my reading (MCP2515 datasheet
and AN754) it says that PS2 must be greater than SJW but in other readings
(can't find at the moment) it implied that PS2 had to be greater than ** or
equal ** to SJW.  Anyone have insight into this?

After some CAN literature study, I now know that this gives a 'sample point'
of 75%.  

Question: It is my understanding that a sample point of more like 85% is
more desirable, true?

Question: For "Long Slow" busses does it make any sense to change the
sampling from 1 to 3?  If not, when would one use a setting of three?

I did a trial of some settings that result in a sample point of 83% (See
"NewSettings.pdf"):

SJW = 1 TQ
BTLMODE = True
Sampling = once (as opposed to 3)
PRSEG (propagation segment) = 8 TQ
PHSEG1 (Phase Segment 1) = 1 TQ
PHSEG2 (Phase Segment 2) = 2 TQ

The new spreadsheet implies that I should be able to keep the bus rate at
19,200 but now cope with a length up to 9,056 feet.

In my application I will never need megabit speeds on the bus but I would
like to raise the bus speed above the current 19,200 bps to deal better with
some application issues but still be able to cope with a bus length of about
5,280 feet for a margin of safety.

The attached spreadsheet NewSettings_1_Mile.pdf suggests that I could run at
36,141 bps up to 5,347 feet and a sample point of 88.2.  Reasonable?

What other factors (other than ground differential) would come into play for
"Long Slow" busses?

In the past I have tried to look at the bus with a scope (difficult, because
it's outdoors away from power source) but difficult to tell anything because
signal levels vary due to the sender but I can't tell who the sender is
because this would take expensive equipment.  All I have access to is a
scope and the "Start Of Frame" pin on the MCP2515 which is set to indicate
when a "start of frame" is detected so this gives me a bit of a "trigger"
source for the scope.  Suggestions of how to look at the bus with a scope to
detect problems?  I know that there will be lots of ringing, etc. to wade
through.

Well, I think that's enough for this email.  Thanks for listening and thanks
in advance for any guidance you can give me.
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: Expanding my CAN knowledge

Chuck Hackett
I just tested access to the dropbox links in my message (first time I have
used dropbox links) and didn't realize that they request 'login' - sorry.
But note that, at the bottom, there is a link to "just view" which seems to
work without needing a dropbox account.
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck



--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Expanding my CAN knowledge

Isto Virtanen
Hello Chuck,
does this arrive?
I replied just to canlist@....
The original sending vector-one has never worked as meant, thus the "NOT" in the address.
Isto

Sent from my iPhone

On 18 Jul 2017, at 16.02, Chuck Hackett <[hidden email]> wrote:

I just tested access to the dropbox links in my message (first time I have
used dropbox links) and didn't realize that they request 'login' - sorry.
But note that, at the bottom, there is a link to "just view" which seems to
work without needing a dropbox account.
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck



--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
This e-mail is confidential and it is intended only for the addressees. Any review, dissemination, distribution, or copying of this message by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system. The sender does not accept liability for any errors or omissions in the contents of this message which may arise as a result of the e-mail transmission.
Reply | Threaded
Open this post in threaded view
|

CAN Bus Standard Vulnerability

SorasakListReader
In reply to this post by Chuck Hackett
Interesting:

Alert (ICS-ALERT-17-209-01)
CAN Bus Standard Vulnerability
https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01


Unpatchable Flaw Affects Most of Today's Modern Cars
https://www.bleepingcomputer.com/news/security/unpatchable-flaw-affects-most-of-todays-modern-cars/


The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard
http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: CAN Bus Standard Vulnerability

John Dammeyer
Seriously?  
Those groups are making noise like this is a critical issue that must be addressed.

Everyone who works with CAN bus knows that physical access to the bus means the network can be compromised.  Duh!

That's true for every type of communications protocol where you can either inject messages or intercept and rebroadcast.  And once doesn't need the OBD-II connector to do this.  For that matter the OBD-II CAN connection often doesn't even touch the real CAN buses used on a vehicle.  Assume a vehicle uses the Freescale 9S12 with 5 CAN bus channels.  One channel specifically to generate the OBD-II port, one for the instrument panel, one for engine to transmission, one to body electronics and I still have one left over.

So if you want to damage messages you have to hack into physical wiring for a specific bus and not just a connector.  Any car company dumb enough to put a system critical bus on the OBD-II connector will find themselves with a recall I'm sure.

Next to do this is relatively easy. Years ago I worked with a semiconductor company to develop what I called the CBMM or CAN Bus Message Marker.  It's express purpose (using an FPGA) was to park on the CAN bus and look for specific CAN IDs and then create an Error Flag of 6 dominant bits.  It also had an occurrence counter so we could do this more than one time so we could create bus warning, bus passive right up to bus off events.  The tool was use to verify that individual custom modules would properly hand a bus off situation.  We could target both transmitters of messages and the receivers.  This was at a time when CAN devices didn't provide access to the Rx and Tx error count registers.

Next tool was almost a decade later.   The CAN CRC is designed to work best with an 11 bit ID message size and still does with the 29 bit ID.  It's not an effective CRC for the longer messages that show up with CAN FD.  I've been out of that world long enough now that I don't know if they use a different CRC when sending FD size messages.  Back in 2000 when we used a custom CAN like protocol virtually identical to what CAN FD is now, IIRC we changed the CRC for the 2K sized messages that held Ethernet packets.  (We were sending MPG4 over power line)

For that project I had to break the CAN bus in a different way by exploiting the CRC vulnerability.  CAN handles single bit errors.  It can even handle multiple bit errors that are contiguous as in the type caused by noise.  The CRC cannot handle random errors across the entire message designed to corrupt only the data portion leaving the ID and CRC intact.  Done correctly the appropriate bits are changed so the CRC is correct but the data bytes have been changed.

But even that can't be done deterministically because you can only actively inject dominant bits on top of recessive bits and there's no way to know that if you change this bit this time that it will cause an error not detected by the higher level protocol.

Finally to really do damage one needs access to the firmware of a module to modify the code or even replace it internally with different hardware so it becomes a bridge and then the sky is the limit.  I don't know of too many MilCAN type products (tanks etc) that would allow someone to replace a module.  Someone in a dealer service department could do this with your car.  But they'd have to be really motivated to create a new module.

So let's not panic.  CAN bus requires physical access in a way that is far beyond the WiFi and Iot world.

My 2 cents.
John Dammeyer








> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of SorasakListReader
> Sent: August-19-17 4:37 AM
> To: [hidden email]
> Subject: [CANLIST] CAN Bus Standard Vulnerability
>
> Interesting:
>
> Alert (ICS-ALERT-17-209-01)
> CAN Bus Standard Vulnerability
> https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01
>
>
> Unpatchable Flaw Affects Most of Today's Modern Cars
> https://www.bleepingcomputer.com/news/security/unpatchable-flaw-affects-
> most-of-todays-modern-cars/
>
>
> The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard
> http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-
> hack/
>
>
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: CAN Bus Standard Vulnerability

Kees Zagers
Fully agree with John.

One or two years ago, we had a same kind of discussion on the LinkedIn
group.

I think we can be short about it. If a hack on the CANbus occurs, it can
mean two things:

1. The developer has made a remote control input and did not include a
correct "firewall". In my opinion it should include some kind of
hardware switch.

2. The "hacker" made changes in the embedded hardware. Always lock your
car.

Don't forget that CAN is a CONTROLLER Area Network. It simply replaces
hard wiring of all sensors and actuators by a simple 2-wire (3 with the
chassis included) system. It made the modern car much safer, however if
you put it in an IOT infrastructure you can get security problems. These
problems should be solved before data can reach the CANbus.

My extra cent.

Kees

John Dammeyer schreef op 19.08.2017 18:08:

> Seriously?
> Those groups are making noise like this is a critical issue that must
> be addressed.
>
> Everyone who works with CAN bus knows that physical access to the bus
> means the network can be compromised.  Duh!
>
> That's true for every type of communications protocol where you can
> either inject messages or intercept and rebroadcast.  And once doesn't
> need the OBD-II connector to do this.  For that matter the OBD-II CAN
> connection often doesn't even touch the real CAN buses used on a
> vehicle.  Assume a vehicle uses the Freescale 9S12 with 5 CAN bus
> channels.  One channel specifically to generate the OBD-II port, one
> for the instrument panel, one for engine to transmission, one to body
> electronics and I still have one left over.
>
> So if you want to damage messages you have to hack into physical
> wiring for a specific bus and not just a connector.  Any car company
> dumb enough to put a system critical bus on the OBD-II connector will
> find themselves with a recall I'm sure.
>
> Next to do this is relatively easy. Years ago I worked with a
> semiconductor company to develop what I called the CBMM or CAN Bus
> Message Marker.  It's express purpose (using an FPGA) was to park on
> the CAN bus and look for specific CAN IDs and then create an Error
> Flag of 6 dominant bits.  It also had an occurrence counter so we
> could do this more than one time so we could create bus warning, bus
> passive right up to bus off events.  The tool was use to verify that
> individual custom modules would properly hand a bus off situation.  We
> could target both transmitters of messages and the receivers.  This
> was at a time when CAN devices didn't provide access to the Rx and Tx
> error count registers.
>
> Next tool was almost a decade later.   The CAN CRC is designed to work
> best with an 11 bit ID message size and still does with the 29 bit ID.
>  It's not an effective CRC for the longer messages that show up with
> CAN FD.  I've been out of that world long enough now that I don't know
> if they use a different CRC when sending FD size messages.  Back in
> 2000 when we used a custom CAN like protocol virtually identical to
> what CAN FD is now, IIRC we changed the CRC for the 2K sized messages
> that held Ethernet packets.  (We were sending MPG4 over power line)
>
> For that project I had to break the CAN bus in a different way by
> exploiting the CRC vulnerability.  CAN handles single bit errors.  It
> can even handle multiple bit errors that are contiguous as in the type
> caused by noise.  The CRC cannot handle random errors across the
> entire message designed to corrupt only the data portion leaving the
> ID and CRC intact.  Done correctly the appropriate bits are changed so
> the CRC is correct but the data bytes have been changed.
>
> But even that can't be done deterministically because you can only
> actively inject dominant bits on top of recessive bits and there's no
> way to know that if you change this bit this time that it will cause
> an error not detected by the higher level protocol.
>
> Finally to really do damage one needs access to the firmware of a
> module to modify the code or even replace it internally with different
> hardware so it becomes a bridge and then the sky is the limit.  I
> don't know of too many MilCAN type products (tanks etc) that would
> allow someone to replace a module.  Someone in a dealer service
> department could do this with your car.  But they'd have to be really
> motivated to create a new module.
>
> So let's not panic.  CAN bus requires physical access in a way that is
> far beyond the WiFi and Iot world.
>
> My 2 cents.
> John Dammeyer
>
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of SorasakListReader
>> Sent: August-19-17 4:37 AM
>> To: [hidden email]
>> Subject: [CANLIST] CAN Bus Standard Vulnerability
>>
>> Interesting:
>>
>> Alert (ICS-ALERT-17-209-01)
>> CAN Bus Standard Vulnerability
>> https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01
>>
>>
>> Unpatchable Flaw Affects Most of Today's Modern Cars
>> https://www.bleepingcomputer.com/news/security/unpatchable-flaw-affects-
>> most-of-todays-modern-cars/
>>
>>
>> The Crisis of Connected Cars: When Vulnerabilities Affect the CAN
>> Standard
>> http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-
>> hack/
>>
>>
>> --
>> Archives and useful links: http://groups.yahoo.com/group/CANbus
>> Subscribe and unsubscribe at www.vector.com/canlist/
>> Report any problems to <[hidden email]>
>
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CAN Bus Standard Vulnerability

Lars-Berno Fredriksson
In reply to this post by John Dammeyer
Hi John,

This just  shows how sloppy the automotive industry is. When I designed
can systems, the system node generated an alert state if there were more
that one error frame in 10.000 messages. If there were more than one in
1000 messages, it went into a "safe critical" mode. The CAN feature of
error counters is only for non-safety and non-time critical systems.

The first step in time- (and safety-) critical system design is to
schedule every message that can be scheduled. Then you have a good start
for a dependable system. A bonus is that you have made it at least an
order of magnitude difficult to hack.

It is a shame that any car system could be hacked as showed! It shows
that the system designer should have had another job, e.g., as a teacher
in roman history.

Cheers,
Freddy

On 2017-08-19 18:08, John Dammeyer wrote:

> Seriously?
> Those groups are making noise like this is a critical issue that must be addressed.
>
> Everyone who works with CAN bus knows that physical access to the bus means the network can be compromised.  Duh!
>
> That's true for every type of communications protocol where you can either inject messages or intercept and rebroadcast.  And once doesn't need the OBD-II connector to do this.  For that matter the OBD-II CAN connection often doesn't even touch the real CAN buses used on a vehicle.  Assume a vehicle uses the Freescale 9S12 with 5 CAN bus channels.  One channel specifically to generate the OBD-II port, one for the instrument panel, one for engine to transmission, one to body electronics and I still have one left over.
>
> So if you want to damage messages you have to hack into physical wiring for a specific bus and not just a connector.  Any car company dumb enough to put a system critical bus on the OBD-II connector will find themselves with a recall I'm sure.
>
> Next to do this is relatively easy. Years ago I worked with a semiconductor company to develop what I called the CBMM or CAN Bus Message Marker.  It's express purpose (using an FPGA) was to park on the CAN bus and look for specific CAN IDs and then create an Error Flag of 6 dominant bits.  It also had an occurrence counter so we could do this more than one time so we could create bus warning, bus passive right up to bus off events.  The tool was use to verify that individual custom modules would properly hand a bus off situation.  We could target both transmitters of messages and the receivers.  This was at a time when CAN devices didn't provide access to the Rx and Tx error count registers.
>
> Next tool was almost a decade later.   The CAN CRC is designed to work best with an 11 bit ID message size and still does with the 29 bit ID.  It's not an effective CRC for the longer messages that show up with CAN FD.  I've been out of that world long enough now that I don't know if they use a different CRC when sending FD size messages.  Back in 2000 when we used a custom CAN like protocol virtually identical to what CAN FD is now, IIRC we changed the CRC for the 2K sized messages that held Ethernet packets.  (We were sending MPG4 over power line)
>
> For that project I had to break the CAN bus in a different way by exploiting the CRC vulnerability.  CAN handles single bit errors.  It can even handle multiple bit errors that are contiguous as in the type caused by noise.  The CRC cannot handle random errors across the entire message designed to corrupt only the data portion leaving the ID and CRC intact.  Done correctly the appropriate bits are changed so the CRC is correct but the data bytes have been changed.
>
> But even that can't be done deterministically because you can only actively inject dominant bits on top of recessive bits and there's no way to know that if you change this bit this time that it will cause an error not detected by the higher level protocol.
>
> Finally to really do damage one needs access to the firmware of a module to modify the code or even replace it internally with different hardware so it becomes a bridge and then the sky is the limit.  I don't know of too many MilCAN type products (tanks etc) that would allow someone to replace a module.  Someone in a dealer service department could do this with your car.  But they'd have to be really motivated to create a new module.
>
> So let's not panic.  CAN bus requires physical access in a way that is far beyond the WiFi and Iot world.
>
> My 2 cents.
> John Dammeyer
>
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of SorasakListReader
>> Sent: August-19-17 4:37 AM
>> To: [hidden email]
>> Subject: [CANLIST] CAN Bus Standard Vulnerability
>>
>> Interesting:
>>
>> Alert (ICS-ALERT-17-209-01)
>> CAN Bus Standard Vulnerability
>> https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01
>>
>>
>> Unpatchable Flaw Affects Most of Today's Modern Cars
>> https://www.bleepingcomputer.com/news/security/unpatchable-flaw-affects-
>> most-of-todays-modern-cars/
>>
>>
>> The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard
>> http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-
>> hack/
>>
>>
>> --
>> Archives and useful links: http://groups.yahoo.com/group/CANbus
>> Subscribe and unsubscribe at www.vector.com/canlist/
>> Report any problems to <[hidden email]>
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>


LBF.vcf (219 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: CAN Bus Standard Vulnerability

John Dammeyer
Hi Freddy,

You are so right!  Protocol is everything.

The authors didn't even mention the flaw in the CAN protocol that requires toggle messages to not be used since the target node may well miss the message and be error passive so it can't flag the message with a dominant error flag while others provide the ACK because they do receive the message.

And that's without any one doing something evil to the bus.

John Dammeyer


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Lars-Berno Fredriksson
> Sent: August-19-17 12:57 PM
> To: [hidden email]; [hidden email]
> Subject: Re: [CANLIST] CAN Bus Standard Vulnerability
>
> Hi John,
>
> This just� shows how sloppy the automotive industry is. When I designed
> can systems, the system node generated an alert state if there were more
> that one error frame in 10.000 messages. If there were more than one in
> 1000 messages, it went into a "safe critical" mode. The CAN feature of
> error counters is only for non-safety and non-time critical systems.
>
> The first step in time- (and safety-) critical system design is to
> schedule every message that can be scheduled. Then you have a good start
> for a dependable system. A bonus is that you have made it at least an
> order of magnitude difficult to hack.
>
> It is a shame that any car system could be hacked as showed! It shows
> that the system designer should have had another job, e.g., as a teacher
> in roman history.
>
> Cheers,
> Freddy
>
> On 2017-08-19 18:08, John Dammeyer wrote:
> > Seriously?
> > Those groups are making noise like this is a critical issue that must be
> addressed.
> >
> > Everyone who works with CAN bus knows that physical access to the bus
> means the network can be compromised.  Duh!
> >
> > That's true for every type of communications protocol where you can either
> inject messages or intercept and rebroadcast.  And once doesn't need the OBD-
> II connector to do this.  For that matter the OBD-II CAN connection often
> doesn't even touch the real CAN buses used on a vehicle.  Assume a vehicle uses
> the Freescale 9S12 with 5 CAN bus channels.  One channel specifically to
> generate the OBD-II port, one for the instrument panel, one for engine to
> transmission, one to body electronics and I still have one left over.
> >
> > So if you want to damage messages you have to hack into physical wiring for a
> specific bus and not just a connector.  Any car company dumb enough to put a
> system critical bus on the OBD-II connector will find themselves with a recall
> I'm sure.
> >
> > Next to do this is relatively easy. Years ago I worked with a semiconductor
> company to develop what I called the CBMM or CAN Bus Message Marker.  It's
> express purpose (using an FPGA) was to park on the CAN bus and look for
> specific CAN IDs and then create an Error Flag of 6 dominant bits.  It also had an
> occurrence counter so we could do this more than one time so we could create
> bus warning, bus passive right up to bus off events.  The tool was use to verify
> that individual custom modules would properly hand a bus off situation.  We
> could target both transmitters of messages and the receivers.  This was at a
> time when CAN devices didn't provide access to the Rx and Tx error count
> registers.
> >
> > Next tool was almost a decade later.   The CAN CRC is designed to work best
> with an 11 bit ID message size and still does with the 29 bit ID.  It's not an
> effective CRC for the longer messages that show up with CAN FD.  I've been out
> of that world long enough now that I don't know if they use a different CRC
> when sending FD size messages.  Back in 2000 when we used a custom CAN like
> protocol virtually identical to what CAN FD is now, IIRC we changed the CRC for
> the 2K sized messages that held Ethernet packets.  (We were sending MPG4
> over power line)
> >
> > For that project I had to break the CAN bus in a different way by exploiting the
> CRC vulnerability.  CAN handles single bit errors.  It can even handle multiple bit
> errors that are contiguous as in the type caused by noise.  The CRC cannot
> handle random errors across the entire message designed to corrupt only the
> data portion leaving the ID and CRC intact.  Done correctly the appropriate bits
> are changed so the CRC is correct but the data bytes have been changed.
> >
> > But even that can't be done deterministically because you can only actively
> inject dominant bits on top of recessive bits and there's no way to know that if
> you change this bit this time that it will cause an error not detected by the
> higher level protocol.
> >
> > Finally to really do damage one needs access to the firmware of a module to
> modify the code or even replace it internally with different hardware so it
> becomes a bridge and then the sky is the limit.  I don't know of too many
> MilCAN type products (tanks etc) that would allow someone to replace a
> module.  Someone in a dealer service department could do this with your car.
> But they'd have to be really motivated to create a new module.
> >
> > So let's not panic.  CAN bus requires physical access in a way that is far
> beyond the WiFi and Iot world.
> >
> > My 2 cents.
> > John Dammeyer
> >
> >
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:[hidden email]] On
> >> Behalf Of SorasakListReader
> >> Sent: August-19-17 4:37 AM
> >> To: [hidden email]
> >> Subject: [CANLIST] CAN Bus Standard Vulnerability
> >>
> >> Interesting:
> >>
> >> Alert (ICS-ALERT-17-209-01)
> >> CAN Bus Standard Vulnerability
> >> https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-209-01
> >>
> >>
> >> Unpatchable Flaw Affects Most of Today's Modern Cars
> >> https://www.bleepingcomputer.com/news/security/unpatchable-flaw-
> affects-
> >> most-of-todays-modern-cars/
> >>
> >>
> >> The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard
> >> http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-
> >> hack/
> >>
> >>
> >> --
> >> Archives and useful links: http://groups.yahoo.com/group/CANbus
> >> Subscribe and unsubscribe at www.vector.com/canlist/
> >> Report any problems to <[hidden email]>
> > --
> > Archives and useful links: http://groups.yahoo.com/group/CANbus
> > Subscribe and unsubscribe at www.vector.com/canlist/
> > Report any problems to <[hidden email]>


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CAN Bus Standard Vulnerability

Bram Kerkhof
In reply to this post by Lars-Berno Fredriksson
Hi Freddy,

Why would you assume that automotive controller units don't have such a "safe critical mode"? I'm pretty confident that the great majority (if not all) of automotive controller units have proper failsafe design if communication with other critical nodes in a vehicle ceases. Cars and trucks don't explode or go berserk when an inhabitant of the local fauna decides that those CAN cables in your engine bay are yummy; they'll indicate the problem and change to the most conservative operating envelope necessary for safe operation (i.e. "limp mode").

The CAN nodes are pretty robust, as are the networks. Safety critical nodes tend to be connected through multiple (redundant) networks to prevent a single point of failure. On top of that, I see a lot of designs already where the easily accessible OBD connection is routed through a gateway (VAG is an example), in which case there is no direct access to the safety critical nodes. Constructors that offer a telematics gateway have been struggling with the security implications from that -- IMHO a telematics control unit should never be connected directly to a drivetrain network, but only through a secondary gateway device that limits access appropriately.

So yeah, if you have access to the physical layer of the drivetrain network, you can probably force a vehicle into some kind of degraded mode. But that's not much different from snipping a couple of wires at random in the engine bay...

The only real issue I see is that people tend to connect anything to the OBD plug, and if that device is insecure (and I'm afraid a lot of them are...) this could cause issues on the CAN network if the OBD is directly connected to your primary drivetrain network. I think we'll see far more gateway-based designs, isolating the diagnostics network from the drivetrain network mitigating this attack vector.

Much ado about nothing, it seems.

cheers,
Bram
----- Oorspronkelijk bericht -----
Van: "Lars-Berno Fredriksson" <[hidden email]>
Aan: [hidden email], "canlist" <[hidden email]>
Verzonden: Zaterdag 19 augustus 2017 21:57:04
Onderwerp: Re: [CANLIST] CAN Bus Standard Vulnerability

Hi John,

This just  shows how sloppy the automotive industry is. When I designed
can systems, the system node generated an alert state if there were more
that one error frame in 10.000 messages. If there were more than one in
1000 messages, it went into a "safe critical" mode. The CAN feature of
error counters is only for non-safety and non-time critical systems.

The first step in time- (and safety-) critical system design is to
schedule every message that can be scheduled. Then you have a good start
for a dependable system. A bonus is that you have made it at least an
order of magnitude difficult to hack.

It is a shame that any car system could be hacked as showed! It shows
that the system designer should have had another job, e.g., as a teacher
in roman history.

Cheers,
Freddy
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: CAN Bus Standard Vulnerability

Lars-Berno Fredriksson
Hi Bram,

My reason for assuming is that the team demonstrated the vulnerability
on at least one car.
(Think their device should be used as a must pass test for any vehicle
intended to be used in public areas.)

My reason  for believe is further backed up by the fact that many cars
have a direct access to the control network via the OBDII connector. No
competent systems designer would allow that. Further, any unexpected
message should lead to an emergency state.

Instead of addressing bit fault injections as a CAN hazard, the team
should have been amazed that the control system still worked when they
they created such bursts of error frames. The intrusion of a bit error
injector in a CAN system is easily detected and should never lead to a
DoS problem.

Cheers,
Freddy

On 2017-08-21 14:23, [hidden email] wrote:

> Hi Freddy,
>
> Why would you assume that automotive controller units don't have such a "safe critical mode"? I'm pretty confident that the great majority (if not all) of automotive controller units have proper failsafe design if communication with other critical nodes in a vehicle ceases. Cars and trucks don't explode or go berserk when an inhabitant of the local fauna decides that those CAN cables in your engine bay are yummy; they'll indicate the problem and change to the most conservative operating envelope necessary for safe operation (i.e. "limp mode").
>
> The CAN nodes are pretty robust, as are the networks. Safety critical nodes tend to be connected through multiple (redundant) networks to prevent a single point of failure. On top of that, I see a lot of designs already where the easily accessible OBD connection is routed through a gateway (VAG is an example), in which case there is no direct access to the safety critical nodes. Constructors that offer a telematics gateway have been struggling with the security implications from that -- IMHO a telematics control unit should never be connected directly to a drivetrain network, but only through a secondary gateway device that limits access appropriately.
>
> So yeah, if you have access to the physical layer of the drivetrain network, you can probably force a vehicle into some kind of degraded mode. But that's not much different from snipping a couple of wires at random in the engine bay...
>
> The only real issue I see is that people tend to connect anything to the OBD plug, and if that device is insecure (and I'm afraid a lot of them are...) this could cause issues on the CAN network if the OBD is directly connected to your primary drivetrain network. I think we'll see far more gateway-based designs, isolating the diagnostics network from the drivetrain network mitigating this attack vector.
>
> Much ado about nothing, it seems.
>
> cheers,
> Bram
> ----- Oorspronkelijk bericht -----
> Van: "Lars-Berno Fredriksson" <[hidden email]>
> Aan: [hidden email], "canlist" <[hidden email]>
> Verzonden: Zaterdag 19 augustus 2017 21:57:04
> Onderwerp: Re: [CANLIST] CAN Bus Standard Vulnerability
>
> Hi John,
>
> This just  shows how sloppy the automotive industry is. When I designed
> can systems, the system node generated an alert state if there were more
> that one error frame in 10.000 messages. If there were more than one in
> 1000 messages, it went into a "safe critical" mode. The CAN feature of
> error counters is only for non-safety and non-time critical systems.
>
> The first step in time- (and safety-) critical system design is to
> schedule every message that can be scheduled. Then you have a good start
> for a dependable system. A bonus is that you have made it at least an
> order of magnitude difficult to hack.
>
> It is a shame that any car system could be hacked as showed! It shows
> that the system designer should have had another job, e.g., as a teacher
> in roman history.
>
> Cheers,
> Freddy
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[hidden email]>


LBF.vcf (219 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CAN Bus Standard Vulnerability

heikki saha
Hello,

What is often forgotten, is that CAN is "Controller Area Network", which typically mean:
- It's physical coverage is constrained
- It's functional coverage is constrained

In car applications, main CAN-networks are installed in the chassis area, into which the physical access is managed by locking system. Furthermore, the wiring harnesses are embedded into the structures and are not accessible without dismounting some mechanics. As Freddy wrote, the networks operate extremely well, even under heavy disturbance. Same cannot be said about wireless communication, into which moisture and metals have direct influence. And DoS is trivial, one can just transmit noise into the corresponding radio band and nothing works. That is quite often forgotten, when people are dreaming about wireless instrumentation as an easy way.

When we thing security, it is rather relative than absolute issue. So, with the "goo'old discrete wiring" -- where packet encoding and other safeguards do not exist, it is trivial to attach for numerous people with very basic skills in electrics. With CAN networking, there exist extensive set of various safeguards and only small number of people have enough skills to start learning the attack techniques. Majority of the attacks reported in the media have been based on exploiting poor or missing security functions in various wireless interfaces and gateways from them to CAN networks, for which there are commonly available SW in the internet and most smartphones and tabs may be used as a HW. It is absolutely true, what Freddy wrote -- designers "forgetting" the safety and dependability issues, should get a different job; alternatively their bosses who are too keen on "cost-aware design" and don't let their designer achieve reasonable quality...

When we consider overall risks, it is obvious that main focus should be directed to the wireless interfaces and related gateways, because they are accessible without physical access to the car. We can include mp3-files also into this category... After getting that ready it may make sense to improve the security in car internal CAN-networking (and other networks as well). One shall always remember, that each paper has two sides:
- in normal operation e.g. security protocol sounds nice
- there are clearly identifiable, potential problems
  + encryption requires computing power, which is still relatively expensive, when combined with high operating ambient temperature and other environmental requirements
  + fixed keys cannot be used, because there are mature mechanisms for breaking such
  + when dynamic keys become messed up for whatever reason, the car becomes practically useless until problem is solved
  + if there were a backdoor bypass mechanism, we fall back to the no security, when the backdoor becomes "public"

Personally I think, that rather than trying to design 100% criminal-proof systems, we should concentrate on maximizing the attack detection performance and clever notifying mechanisms, by which the criminals may be caught. Power-off or power reduction reaction in the case of attack works in cars too, because stop may be considered as a safe state.

BR,

-H


Heikki Saha, CTO
  M.Sc. Automation
  Dr.Tech. Electronics
TK Engineering Oy
Mail address:  P.O. box 810, FIN-65101 VAASA
Visit address: Yrittäjänkatu 17, FIN-65380 VAASA
+358 (0)50 588 6894
email: [hidden email]
skype: heikki.saha_tke

On Mon, Aug 21, 2017 at 7:46 PM, Lars-Berno Fredriksson <[hidden email]> wrote:
Hi Bram,

My reason for assuming is that the team demonstrated the vulnerability on at least one car.
(Think their device should be used as a must pass test for any vehicle intended to be used in public areas.)

My reason  for believe is further backed up by the fact that many cars have a direct access to the control network via the OBDII connector. No competent systems designer would allow that. Further, any unexpected message should lead to an emergency state.

Instead of addressing bit fault injections as a CAN hazard, the team should have been amazed that the control system still worked when they they created such bursts of error frames. The intrusion of a bit error injector in a CAN system is easily detected and should never lead to a DoS problem.

Cheers,
Freddy

On 2017-08-21 14:23, [hidden email] wrote:
Hi Freddy,

Why would you assume that automotive controller units don't have such a "safe critical mode"? I'm pretty confident that the great majority (if not all) of automotive controller units have proper failsafe design if communication with other critical nodes in a vehicle ceases. Cars and trucks don't explode or go berserk when an inhabitant of the local fauna decides that those CAN cables in your engine bay are yummy; they'll indicate the problem and change to the most conservative operating envelope necessary for safe operation (i.e. "limp mode").

The CAN nodes are pretty robust, as are the networks. Safety critical nodes tend to be connected through multiple (redundant) networks to prevent a single point of failure. On top of that, I see a lot of designs already where the easily accessible OBD connection is routed through a gateway (VAG is an example), in which case there is no direct access to the safety critical nodes. Constructors that offer a telematics gateway have been struggling with the security implications from that -- IMHO a telematics control unit should never be connected directly to a drivetrain network, but only through a secondary gateway device that limits access appropriately.

So yeah, if you have access to the physical layer of the drivetrain network, you can probably force a vehicle into some kind of degraded mode. But that's not much different from snipping a couple of wires at random in the engine bay...

The only real issue I see is that people tend to connect anything to the OBD plug, and if that device is insecure (and I'm afraid a lot of them are...) this could cause issues on the CAN network if the OBD is directly connected to your primary drivetrain network. I think we'll see far more gateway-based designs, isolating the diagnostics network from the drivetrain network mitigating this attack vector.

Much ado about nothing, it seems.

cheers,
Bram
----- Oorspronkelijk bericht -----
Van: "Lars-Berno Fredriksson" <[hidden email]>
Aan: [hidden email], "canlist" <[hidden email]>
Verzonden: Zaterdag 19 augustus 2017 21:57:04
Onderwerp: Re: [CANLIST] CAN Bus Standard Vulnerability

Hi John,

This just  shows how sloppy the automotive industry is. When I designed
can systems, the system node generated an alert state if there were more
that one error frame in 10.000 messages. If there were more than one in
1000 messages, it went into a "safe critical" mode. The CAN feature of
error counters is only for non-safety and non-time critical systems.

The first step in time- (and safety-) critical system design is to
schedule every message that can be scheduled. Then you have a good start
for a dependable system. A bonus is that you have made it at least an
order of magnitude difficult to hack.

It is a shame that any car system could be hacked as showed! It shows
that the system designer should have had another job, e.g., as a teacher
in roman history.

Cheers,
Freddy
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[hidden email]>