Re: CAN Bus Standard Vulnerability

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: [email protected]
skype: heikki.saha_tke

On Mon, Aug 21, 2017 at 7:46 PM, Lars-Berno Fredriksson <[email protected]>
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, [email protected] 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" <[email protected]>
>> Aan: [email protected], "canlist" <[email protected]>
>> 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 <[email protected]>
>>
>
>