Subject: [its] V2I security problems

From: Alison Chaiken <[email-masked]>
Date: Sun, 13 Oct 2013 23:27:49 -0700

This "Shuttle bus with J1939 air-conditioning" connects an insecure
CAN network with (typically at least) little security to the wider
Internet: "Via a wireless communication based on the J1939 protocol,
the individual HVAC systems are supervised by the climate control
center in the operator’s office."   The J1939 CAN-bus is exposed near
passengers on the shuttle-bus.     Looks like a rolling security
problem to me!

http://can-newsletter.org/engineering/applications/nr_shuttle-bus-with-j1939-air-conditioning_thermoking_131008/

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
It's a bug that cars were invented before computers.    -- Eric Schmidt

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 14 Oct 2013 09:50:34 +0200

Hi,

> http://can-newsletter.org/engineering/applications/nr_shuttle-bus-with-j1939-air-conditioning_thermoking_131008/

Yes, it is. Cryptographic integrity protection between all ECUs is IMHO
a must for all onboard traffic.

Regards,
 Roland

---

From: "Konstantin A. Khait" <[email-masked]>
Date: Mon, 14 Oct 2013 12:15:17 +0400

Hm... It is yet another reason why custom "...-based" protocols are evil [in automotive]. IEEE1609 assumes elliptic encription, which is very hard to attack (basically even harder than AES). But according to what we see, nobody in automotive really concerns about security.

-----

-----

Konstantin A. Khait

Componentality Oy

Tel: +358(0)465662016

+7(921)9005780

Skype: kostia.khait

E-Mail: [email-masked]

53100 Finland

Ratakatu 47

Lappeenranta

> center in the operator’s office." В  The J1939 CAN-bus is exposed near

> passengers on the shuttle-bus. В  В  Looks like a rolling security

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 14 Oct 2013 09:29:58 -0700

The issue is not what encryption technology is used -- that's a
discussion in the small.  What is at issue is the scope of the
encryption.  

If the CAN is encrypted ... is the data protected in the radio
network?  

The important objective is to secure the _data_ and to secure it
end-to-end.  Rendering the most important security attributes
(authenticity and confidentiality) irrelevant to whether the passengers
can touch it.  

What the internet does, that none of the wannabes do, is provide
end-to-end reliability over an infrastructure that we acknowledge to be
less than perfect.  That's what all the ACK/NAC, packet numbering and
the three-way handshake in TCP is about.   What we have not done (at
least not here) is apply the same principles to security -- we need
end-to-end security over an infrastructure that we acknowledge is less
than perfect.  

On Mon, 2013-10-14 at 12:15 +0400, Konstantin A. Khait wrote:
> Hm... It is yet another reason why custom "...-based" protocols are
> evil [in automotive]. IEEE1609 assumes elliptic encription, which is
> very hard to attack (basically even harder than AES). But according to
> what we see, nobody in automotive really concerns about security.
> 
> 
> -----
> 
> 
> 
> -----
> Konstantin A. Khait
> Componentality Oy
> Tel: +358(0)465662016
>        +7(921)9005780
> Skype: kostia.khait
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Alison Chaiken <[email-masked]>
Date: Mon, 14 Oct 2013 09:30:10 -0700

Kostia and Alexander, attached are the latest (still unfinished)
slides for Automotive Linux Summit on 10/25.    I am planning on using
your image from your AGL webinar and to favorably compare your
offering as (potentially) "the bluez of DSRC."    Please let me know
if you have corrections or comments.    I hope that I will see you in
Edinburgh!

---

From: "Konstantin A. Khait" <[email-masked]>
Date: Tue, 15 Oct 2013 00:06:13 +0400

No, no, no... I didn't mean that it is just an encryption issue. It is definitely strange that somebody simply propagates CAN to wireless communication area. Nobody took care of CAN security because it was designed as a wired bus for [in-particular] in-vehicle use. Moreover, it seems rather hard and expensive to make CAN secure, because encryption will affect the bus logic: either conflicts resolution approach or message priority.

It seems to me, the old school design of such things assumes a gateway between wireless portion and CAN bus which proceeds wireless commands and issues CAN messages. The set of commands is limited by required functions, so there's no way to provoke random CAN message. In this case wireless channel should be secured with using regular pre-shared or more probable public key approach and in-vehicle CAN remains unsecured.

What I meant, "old school design" is nothing if it is not an industry standard. It should be a common approach how to send functional data over the air and this standard must include a security method. So, it shall be like wireless MOST bus where each functional block has limited set of methods and properties predefined in the corresponded standard. MOST is unsecured (because it is again in-vehicle technology), but it is just an example. Wireless method should be based on something common (I'd say 802.11) and use corresponded security provisioning approaches.

Thanks,

Kostia

-----

-----

Konstantin A. Khait

Componentality Oy

Tel: +358(0)465662016

+7(921)9005780

Skype: kostia.khait

53100 Finland

Ratakatu 47

Lappeenranta

> discussion in the small. В What is at issue is the scope of the

> encryption. В

> network? В

> end-to-end. В Rendering the most important security attributes

> can touch it. В

> less than perfect. В That's what all the ACK/NAC, packet numbering and

> the three-way handshake in TCP is about. В  What we have not done (at

> than perfect. В

>> В  В  В  В +7(921)9005780

>> > center in the operator’s office." В В The J1939 CAN-bus is exposed

>> near

>> > passengers on the shuttle-bus. В В В В Looks like a rolling security

>> В

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 14 Oct 2013 13:16:31 -0700

On Tue, 2013-10-15 at 00:06 +0400, Konstantin A. Khait wrote:
> It is definitely strange that somebody simply propagates CAN to
> wireless communication area.

Konstantin,  the picture that Allison fingered does exactly that --
there is definitely a gateway and the data is definitely exported.

> assumes a gateway between wireless portion and CAN bus
> 
In general, gateways are bad, routers are good.  Because the gateway is
a point where any security measures that might exist on one side of the
gate are necessarily stripped off -- the data is unprotected within the
gateway.  This limits the scope of the security.  

>  "old school design" is nothing if it is not an industry standard. It
> should be a common approach how to send functional data over the air
> and this standard must include a security method.
> 
First there are >1 set of industry standards out there.  And they
overlap/conflict.  Something we've flogged on this newsgroup before.  

Second, a good deal of the standards either fail to include security as
a requirement (look at the debacles with WiFi over the years) or they do
it wrong.  In general, there is little value to security at layers 1 and
2.  Slightly more at layer three.  The payoff is when you treat security
properly at layers 6/7.  

I don't know much about CAN per se, but I can easily accept your
assertion that trying to 'secure the bus' would be a bad idea.  We have
buckets of failed security efforts in Department of Defense (no, you
don't want the recitation;-) where we tried to secure a network segment,
not the data.  

b

---

From: "Konstantin A. Khait" <[email-masked]>
Date: Tue, 15 Oct 2013 00:29:23 +0400

We should live in the real world. In the real world the set of CAN messages is unchangeable. It is what we had in vehicles from the past epoch and none of automotive companies will change it for many years because it is working, because it is a core functionality (wireless is just an extension) and because it is mission critical i.e. very conservative. Therefore "end to end security" here ends where CAN starts. With no options. Second thing. Developers want API. Customers want 'technology'. I.e. API + library or something comparable. They want to put data to some socket at one end and get it from the pipe at another end. And let 'experts' taking care of security, reliability etc. At the end of the days, car manufacturers are just assembly plants, it is not their business to take care of all these 'funny IT things'. And it is also can't be changed. Therefore you can't have a secure router here and you can't have data level security. Not because it is architecturally bad, but because it is out of the existing industrial reality.

Moreover. You can have open and public wireless data transfer standard. You can't have open and public gateway implementation. We may want it... but OEMs will have it secured for next couple geological epochs at least. They may accept something open in IVI, which is not mission critical (after years of debates and with a lot of conditions and claims), but definitely not in body electronics, engine control etc.

-----

-----

Konstantin A. Khait

Componentality Oy

Tel: +358(0)465662016

+7(921)9005780

Skype: kostia.khait

53100 Finland

Ratakatu 47

Lappeenranta

> Konstantin, В the picture that Allison fingered does exactly that --

> In general, gateways are bad, routers are good. В Because the gateway is

> gateway. В This limits the scope of the security. В

>> В "old school design" is nothing if it is not an industry standard. It

First there are >>1 set of industry standards out there. В And they

> overlap/conflict. В Something we've flogged on this newsgroup before. В

> it wrong. В In general, there is little value to security at layers 1 and

> 2. В Slightly more at layer three. В The payoff is when you treat security

> properly at layers 6/7. В

> assertion that trying to 'secure the bus' would be a bad idea. В We have

> not the data. В

---

From: Alexander Pinaev <[email-masked]>
Date: Tue, 15 Oct 2013 12:33:50 +0400

CAN to wireless gateway is a gift which makes vulnerable CAN easily
exploitable without a cable connection. Not sure if they are concerned if
their system protected properly.

On Tue, Oct 15, 2013 at 12:06 AM, Konstantin A. Khait <
[email-masked]> wrote:

>  No, no, no... I didn't mean that it is just an encryption issue. It is
> definitely strange that somebody simply propagates CAN to wireless
> communication area. Nobody took care of CAN security because it was
> designed as a wired bus for [in-particular] in-vehicle use. Moreover, it
> seems rather hard and expensive to make CAN secure, because encryption will
> affect the bus logic: either conflicts resolution approach or message
> priority.
> It seems to me, the old school design of such things assumes a gateway
> between wireless portion and CAN bus which proceeds wireless commands and
> issues CAN messages. The set of commands is limited by required functions,
> so there's no way to provoke random CAN message. In this case wireless
> channel should be secured with using regular pre-shared or more probable
> public key approach and in-vehicle CAN remains unsecured.
> What I meant, "old school design" is nothing if it is not an industry
> standard. It should be a common approach how to send functional data over
> the air and this standard must include a security method. So, it shall be
> like wireless MOST bus where each functional block has limited set of
> methods and properties predefined in the corresponded standard. MOST is
> unsecured (because it is again in-vehicle technology), but it is just an
> example. Wireless method should be based on something common (I'd say
> 802.11) and use corresponded security provisioning approaches.
>
> Thanks,
> Kostia
>
> -----
>
>
>
> -----
> Konstantin A. Khait
> Componentality Oy
> Tel: +358(0)465662016
>        +7(921)9005780
> Skype: kostia.khait
> >> > center in the operator's office." В В The J1939 CAN-bus is exposed
> >> near

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Oct 2013 10:02:36 +0200

Le 15/10/2013 10:33, Alexander Pinaev a écrit :
> exploitable without a cable connection. Not sure if they are
> concerned if their system protected properly.

I have just noticed an early prototype in which the vehicle's
'username/password' (the vehicle is a 'user') communicated over CAN for
electrical charge billing would be relayed over the air - in clear.

This should be protected.

The protection - e.g. hashing the password - is known practice to those
inclined to security, but is additional hurdle to getting things done to
those inclined to early communications.

I think in the domain of vehicular communications we are at an early
stage where security expertise is very much needed.

Yours,

Alex

>
>
> On Tue, Oct 15, 2013 at 12:06 AM, Konstantin A. Khait
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> No, no, no... I didn't mean that it is just an encryption issue. It
> is definitely strange that somebody simply propagates CAN to wireless
> designed as a wired bus for [in-particular] in-vehicle use. Moreover,
> it seems rather hard and expensive to make CAN secure, because
> encryption will affect the bus logic: either conflicts resolution
> approach or message priority. It seems to me, the old school design
> of such things assumes a gateway between wireless portion and CAN bus
> which proceeds wireless commands and issues CAN messages. The set of
> commands is limited by required functions, so there's no way to
> provoke random CAN message. In this case wireless channel should be
> secured with using regular pre-shared or more probable public key
> approach and in-vehicle CAN remains unsecured. What I meant, "old
> school design" is nothing if it is not an industry standard. It
> and this standard must include a security method. So, it shall be
> methods and properties predefined in the corresponded standard. MOST
> is unsecured (because it is again in-vehicle technology), but it is
> just an example. Wireless method should be based on something common
> (I'd say 802.11) and use corresponded security provisioning
> approaches.
>
> Thanks, Kostia
>
> -----
>
>
>
> ----- Konstantin A. Khait Componentality Oy Tel: +358(0)465662016
> +7(921)9005780 Skype: kostia.khait E-Mail: [email-masked]
> <mailto:[email-masked]> 53100 Finland Ratakatu 47
> Lappeenranta
>
>
>> (authenticity and confidentiality) irrelevant to whether the
>> passengers can touch it. В
>
>
>> end-to-end reliability over an infrastructure that we acknowledge
>> to be less than perfect. В That's what all the ACK/NAC, packet
>> numbering and the three-way handshake in TCP is about. В  What we
>> have not done (at
>
>> least not here) is apply the same principles to security -- we
>> need end-to-end security over an infrastructure that we acknowledge
>> is less than perfect. В
>
>
>
>
>>> Hm... It is yet another reason why custom "...-based" protocols
>>> are evil [in automotive]. IEEE1609 assumes elliptic encription,
>>> which is very hard to attack (basically even harder than AES).
>>> But according to what we see, nobody in automotive really
>>> concerns about security.
>>>
>>>
>>> -----
>>>
>>>
>>>
>>> ----- Konstantin A. Khait Componentality Oy Tel:
>>> +358(0)465662016 В  В  В  В +7(921)9005780
>
>>> Skype: kostia.khait E-Mail:[email-masked]
>>> <mailto:[email-masked]> 53100 Finland Ratakatu 47
>>> Lappeenranta
>>>
>>>
>>>> This "Shuttle bus with J1939 air-conditioning" connects an
>>>> insecure CAN network with (typically at least) little security
>>>> to the wider Internet: "Via a wireless communication based on
>>>> the J1939 protocol, the individual HVAC systems are supervised
>>>> by the climate control center in the operator’s office." В В
>>>> The J1939 CAN-bus is exposed
>>> near
>>> _______________________________________________ its mailing list
>>> [email-masked] <mailto:[email-masked]>
>> _______________________________________________ its mailing list
>> [email-masked] <mailto:[email-masked]>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>