W3C home > Mailing lists > Public > public-automotive@w3.org > September 2016

Re: [Minutes] Auto WG 2016-09-06

From: Gavigan, Kevin <kgavigan@jaguarlandrover.com>
Date: Fri, 9 Sep 2016 09:26:12 +0100
Message-ID: <CAKaHsmd_bMA2iTDLJf_hmR-qGSHNpCjLfr4oR+-iC=bL_B+ZQg@mail.gmail.com>
To: Song Li <ls@newskysecurity.com>
Cc: Peter Winzell <Peter.Winzell@melcogot.com>, "Streif, Rudolf" <rstreif@jaguarlandrover.com>, T Guild <ted@w3.org>, public-automotive <public-automotive@w3.org>, Jeremiah Foster <jeremiah.foster@pelagicore.com>
Hi

*>> Suppose the passenger's phone needs to talk to the IVI server to get
vehicle data, it needs to know if it is talking to the real server, or the
server is some faked host via a malicious wifi.*

Completely agree, but just to mention, the WiFi client providing the in
vehicle WiFi may be implemented by a completely different component (ECU)
to the one providing In Vehicle Infotainment (IVI). Some OEMs may choose to
run the Web Socket Server on the IVI ECU, some may run it on another ECU
and network them together. Basically, I'm arguing that the problem of
making sure the client is really talking to the vehicle's WiFi is a very
valid and important point, but is a bigger / separate issue.

The vehicle and the device will need to have some means for authenticating
each other. This could for example, include displaying a code on the head
unit that is used as part of the process to 'register' the device and to
prove it's identity with a Security Authority trusted by other componets on
the vehicle.

In the security model in the WebSocket Server Spec, a device need only
present a token that has been issued by a trusted Security Authority.
Precisely how the Security Authority that is trusted by the vehicle, came
to trust the device is out of scope for the specification, as is how the
vehicle proves its identity to the Security Authority (or directly to the
device). I would suggest that for simplicity and to maintain 'Separation of
Concerns' it is helpful to continue with this approach.

Regards,

Kev

*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 9 September 2016 at 00:47, Song Li <ls@newskysecurity.com> wrote:

> Agreed, the server may choose to use different security mechanisms that
> they see fit when authenticating the client, and decide if service should
> be provided.
>
> From security's perspective, the authentication goes both ways - when
> server is contacted by a client, client needs to provide authentication
> token showing it should be served; and before this happens, the client,
> particularly a wireless client, such as the driver or passenger's phone via
> the vehicle's wifi, also needs to know it is talking to the right server.
> This is where server certificates come into play. Suppose the passenger's
> phone needs to talk to the IVI server to get vehicle data, it needs to know
> if it is talking to the real server, or the server is some faked host via a
> malicious wifi.
>
> I am not sure if such scenarios - wireless devices talking to vehicle
> server - are considered as OEM / Tier 1, or it is more of a 3rd party
> developers' area.
>
> Regards
>
> Song Li
>
> Co-founder and CTO
> NewSky Security <https://newskysecurity.com>
>
>
> On Thu, Sep 8, 2016 at 1:28 AM, Peter Winzell <Peter.Winzell@melcogot.com>
> wrote:
>
>>
>>
>> Hi Rudi!
>>
>>
>>
>> I completely agree with you on this. From the tier1 ones perspective it
>> is important to be able to have specifications that can be applied to
>> various OEMS and meet one specific OEM reqs.
>>
>>
>>
>> Br
>>
>> Peter W
>>
>> *From:* Streif, Rudolf [mailto:rstreif@jaguarlandrover.com]
>> *Sent:* Thursday, September 8, 2016 1:50 AM
>> *To:* T Guild
>> *Cc:* Song Li; public-automotive; Jeremiah Foster
>> *Subject:* Re: [Minutes] Auto WG 2016-09-06
>>
>>
>>
>> Although it's bad practice, I am just top-posting here as what I want to
>> convey is related but not directly in response to particular elements of
>> the discussion.
>>
>>
>>
>> As you know, JLR has been working on a universal services framework for
>> vehicle connectivity which is called Remote Vehicle Interaction (RVI) [1].
>> RVI is a GENIVI open-source project. RVI's three macro use cases are:
>>
>>    - SOTA
>>    - Remote Control
>>    - Vehicle Data
>>
>> RVI implements two-layer security [2]:
>>
>>    - Transport Security using TLS
>>
>>
>>    - All communication between RVI nodes is secured using TLS
>>
>>
>>    - Certificate-based Authentication and Authorization
>>
>>
>>    - For any entity to invoke a service the entity must present a JSON
>>       Web Token (JWT) that contains the requesting entities device certificate
>>       for authentication and a list of services the entity is allowed to invoke
>>       for authorization. The entire token is signed by the root certificate of
>>       the issuing entity (typically the OEM).
>>
>> The following diagram depicts how I envision a potential architecture of
>> interaction between the socket server and RVI.
>>
>>
>>
>> [image: Description: Inline image 1]
>>
>>
>>
>> In this architecture security is not handled by the Socket Server but by
>> an underlying layer. I think that makes very much sense as it can be left
>> to the implementing OEM or their Tier1 on what security mechanism to use.
>> The Socket Server only needs to be able to receive on pass on a security
>> token which is treated as an opaque data item. For RVI that would be the
>> RVI JWT. Other implementations can use a different format.
>>
>>
>>
>> I do not think that all OEM and Tier1 have to agree on the same security
>> mechanism. The OEM has to provide the security token anyway. Even if a web
>> application is developed universally to run on any IVI system that supports
>> the Socket Server, OEMs will want to authorize that application for their
>> vehicles. If an OEM does not want to use RVI but another system that
>> implements its own security schema that is perfectly fine and desirable.
>> And even if multiple OEMs use RVI that does by no means imply that they are
>> using the same JWT to authenticate/authorize web apps.
>>
>>
>>
>> In my opinion the Socket Server does not need to provide the security
>> mechanism nor does the W3C specification need specify the security
>> mechanism. It only needs to specify how security tokes are provided but not
>> what they are and what they contain.
>>
>>
>>
>> Best regards,
>>
>> Rudi
>>
>>
>>
>>
>>
>>
>>
>> [1] https://github.com/GENIVI/rvi_core
>>
>> [2] https://github.com/GENIVI/rvi_core/blob/develop/doc/rvi_protocol.md
>>
>>
>>
>> On Wed, Sep 7, 2016 at 11:23 AM, Ted Guild <ted@w3.org> wrote:
>>
>> Found the link I was looking for related to certs and CA in auto space:
>>
>> https://www.regulations.gov/document?D=NHTSA-2015-0060-0004
>>
>> Interesting and ambitious although a very different use case. They want
>> to have tons of short (or one time) use certs that can be verifiable
>> and disposable while retaining anonymity.
>>
>> On Tue, 2016-09-06 at 18:39 -0700, Song Li wrote:
>> > > > I missed the security part of the discussion - I would suggest we
>> > > > include certificate management in our security model. It should
>> > > cover
>> > > > (but not limited to):
>> > > > How to create certificates
>> > > > How to deploy certificates to in-vehicle servers
>> > > > How developers authenticate the server via certificates
>> > > > How to revoke and renew certificates
>> > >
>>
>> --
>> Ted Guild <ted@w3.org>
>> W3C Systems Team
>> http://www.w3.org
>>
>>
>>
>>
>>
>> --
>>
>> *Rudolf J Streif*
>>
>> System Architect - Open Source Initiative
>>
>> Open Source Technology Centre
>>
>>
>>
>> *M:* +1.619.631.5383
>>
>> *Email:*  rstreif@jaguarlandrover.com
>>
>>
>> [image: Description: Image removed by sender.]
>>
>> UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
>>
>> US: 1419 NW 14th Ave, Portland, OR 97209
>>
>> jaguar.com | landrover.com
>>
>> -------------------
>> Business Details:
>> Jaguar Land Rover Limited
>> Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
>>
>> Registered in England No: 1672070
>>
>>
>> This e-mail and any attachments contain confidential information for a
>> specific individual and purpose.  The information is private and privileged
>> and intended solely for the use of the individual to whom it is addressed.
>> If you are not the intended recipient, please e-mail us immediately.  We
>> apologise for any inconvenience caused but you are hereby notified that any
>> disclosure, copying or distribution or the taking of any action in reliance
>> on the information contained herein is strictly prohibited.
>>
>> This e-mail does not constitute an order for goods or services unless
>> accompanied by an official purchase order.
>>
>>
>>
>
>

image001.png
(image/png attachment: image001.png)

_WRD000.jpg
(image/jpeg attachment: _WRD000.jpg)

Received on Friday, 9 September 2016 08:27:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:00 UTC