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

Thanks for clarifying this Kevin - it is always good to know scope of the
discussion.

Regards

Song Li

Co-founder and CTO
NewSky Security <https://newskysecurity.com>


On Fri, Sep 9, 2016 at 1:26 AM, Gavigan, Kevin <kgavigan@jaguarlandrover.com
> wrote:

> 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.
>>>
>>>
>>>
>>
>>
>