Re: [its] V2I security problems

"Konstantin A. Khait" <khait@componentality.com> Mon, 14 October 2013 20:06 UTC

Date: Tue, 15 Oct 2013 00:06:13 +0400
From: "Konstantin A. Khait" <khait@componentality.com>
Organization: Componentality Oy
Message-ID: <1351916964.20131015000613@componentality.com>
To: Rex Buddenberg <buddenbergr@gmail.com>
In-Reply-To: <1381768198.8469.88.camel@localhost>
References: <CAFfskNxSZjvYx-nmCmtD9dFVhsFn=PuMF=AoR0bz10JzqwFJ3A@mail.gmail.com> <1791874414.20131014121517@componentality.com> <1381768198.8469.88.camel@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------55217157BDCF9"
Cc: Alexander Pinaev <apinaev@gmail.com>, Alison Chaiken <alison@she-devel.com>, "its@ietf.org" <its@ietf.org>
Subject: Re: [its] V2I security problems
Precedence: list

Re: [its] V2I security problems 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
E-Mail: khait@componentality.com
53100 Finland
Ratakatu 47
Lappeenranta

> 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
>> E-Mail: khait@componentality.com
>> 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
>> > 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/
>>
>> В
>> _______________________________________________
>> its mailing list
>> its@ietf.org
>> https://www.ietf.org/mailman/listinfo/its
>>

> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

Attachment: Celebrity-X001.png

[its] V2I security problems Alison Chaiken
Re: [its] V2I security problems Bless, Roland (TM)
Re: [its] V2I security problems Konstantin A. Khait
Re: [its] V2I security problems Rex Buddenberg
Re: [its] V2I security problems Alison Chaiken
Re: [its] V2I security problems Konstantin A. Khait
Re: [its] V2I security problems Rex Buddenberg
Re: [its] V2I security problems Konstantin A. Khait
Re: [its] V2I security problems Alexander Pinaev
Re: [its] V2I security problems Alexandru Petrescu

Re: [its] V2I security problems

Attachment: Celebrity-X001.png