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

Re: Draft Specification for Service Based Approach Using WebSockets

From: Song Li <ls@newskysecurity.com>
Date: Thu, 9 Jun 2016 12:05:37 -0700
Message-ID: <CAJmxCGB+JagQqdBwYJ+sAaVOmPn7zmwGeLk009GNri_9VwdRKQ@mail.gmail.com>
To: "Gavigan, Kevin" <kgavigan@jaguarlandrover.com>
Cc: Junichi Hashimoto <xju-hashimoto@kddi.com>, Paul Boyes <Paul.Boyes@inrix.com>, Peter Winzell <Peter.Winzell@melcogot.com>, "Crofts, Adam" <acrofts1@jaguarlandrover.com>, public-automotive <public-automotive@w3.org>, Peter Virk <pvirk1@jaguarlandrover.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>
Hi Kevin,

MitM attack is one my favorite topics. Yes, deciding which cert. to trust
is critical. To solve this the client will need to have the infotain's cert
pre-installed and trusted. This is not more vulnerable than the regular
case where client talks to a CA to verify the cert, and provides more
flexibility for manufactures. There are more details on the attack and
defense scenarios, and how to update the cert upon expiration / breach,
which I don't think a single email can cover.

Regards

Song Li

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


On Thu, Jun 9, 2016 at 2:16 AM, Gavigan, Kevin <kgavigan@jaguarlandrover.com
> wrote:

> Hi Song,
>
> Thanks very much for the very helpful details.
>
> For a server with domain 'infotain', do you have any suggestions/advice on
> how to establish a WebSocket wss (TLS secure channel) between the on
> vehicle client and server?
>
> I'm thinking particularly about how to prevent a Man in the Middle attack
> between client and server and ensuring that the client is certain it is
> communicating with the infotain server on the vehicle. Would this be based
> on the server having an X.509 certificate for 'infotain'? If so would
> manufacturers share an 'infotain' certificate issued by a Certificate
> Authority (or have I misunderstood - always a possibility :-) ??
>
> Thanks and regards,
>
> Kevin
>
> *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 8 June 2016 at 19:02, Song Li <ls@newskysecurity.com> wrote:
>
>> Hi Kevin,
>>
>> Absolutely, I love to elaborate on this. I think it is a good idea to use
>> a well-known name for the server, so that all manufactures can use the same
>> name. While "localhost" is a well-known name, it is bound to the same
>> server (127.0.0.1), I think we can use a different name, say "infotain", so
>> that we have the flexibility of using a different ip in the future.
>>
>> For implementation details, lets assume manufactures are building their
>> servers / clients based on some existing OS, i.e. *nix or windows. All
>> those systems support hosts file as their first line of domain name
>> service. In hosts file, we can map "infotain" to 127.0.0.1, same as
>> localhost, this is consistent with today's draft spec. If, in the future,
>> for some reason, a manufacture choose to move the server to a different
>> machine than the client, a push update of hosts file will let the client
>> talk to the new server, no code update required. The client still talks to
>> "infotain:4343" but under the hood it is a different machine.
>>
>> In our spec we do not need to bind the server to a particular ip address,
>> I believe this is something up to the manufacture to decide. It is most
>> likely be some
>>
>> This setup will benefit development work as well. In most cases server
>> and client will have different development / release schedules. Say the
>> server team has a release candidate ServRC1 and deployed for testing, for
>> integration tests the client team can simply modify their hosts file so
>> that their code talks to ServRC1 instance. They don't have to install both
>> client and server on the same machine for the testing.
>>
>> Now back to Junichi's security concerns. Today when infotain is actually
>> localhost, we do not have the protection that we have when server and
>> client live on different machines. We need to make sure client cannot
>> access the sensitive resources of server. This requires client needs to run
>> from a user that's not root, and server's sensitive information such as
>> cert, credentials, cookies, etc are saved in places where client cannot
>> access.
>>
>> If in the future client and server are running on different machines, it
>> is a standard internet security scenario, where we restrict access to
>> server machine's resources by restricting ports, client ip, etc.
>>
>> Again feedback welcome.
>>
>> Regards
>>
>> Song Li
>>
>> Co-founder and CTO
>> NewSky Security <https://newskysecurity.com>
>>
>> On Wed, Jun 8, 2016 at 1:14 AM, Gavigan, Kevin <
>> kgavigan@jaguarlandrover.com> wrote:
>>
>>> Hi Song Li
>>>
>>> Thank you to you and Junichi for excellent and very helpful feedback
>>>
>>> I would be very grateful if you could expand on the points you made in
>>> your proposal - I have added a question in blue below.
>>>
>>>
>>>    1. Name the server machine differently from "localhost". -
>>>    Flexibility in long term evolution, can resolve the name to same machine or
>>>    different machine
>>>
>>> localhost is being used to enable clients running on the vehicle to
>>> connect to a server that is also running on the vehicle. This server (which
>>> may be implemented using e.g. node.js is acting as a gateway on that
>>> vehicle to vehicle signals. There may be other offboard clients, but they
>>> also have to obtain the IP address of the vehicle when it is connected to
>>> the internet, in addition to being able to address the server running on
>>> the vehicle.
>>>
>>> Instead of using localhost, are you proposing that each server
>>> implementer (vehicle manufacturer) should use a different domain name or ip
>>> address for the 'server' on the vehicles they manufacture (and this is made
>>> known to the client via documentation or a discovery mechanism) or is there
>>> a better mechanism?
>>>
>>> I would be very grateful if you could you please expand on how the
>>> alternative to using localhost would work?
>>>
>>> Thanks and regards,
>>>
>>> Kevin
>>>
>>> *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 8 June 2016 at 02:41, Song Li <ls@newskysecurity.com> wrote:
>>>
>>>> Hi Junichi,
>>>>
>>>> Thanks for pointing this out - yes, when the client is running on the
>>>> same machine as the server, it is a much higher risk if the client is
>>>> controlled by attackers, as you pointed out in your email, the attacker
>>>> will have access to the server's certificate, and other sensitive
>>>> information, from the file system.
>>>>
>>>> From security's perspective, and putting long-term system evolution
>>>> into consideration, I think the problem is "localhost". I am wondering if
>>>> the assumption that client and server are running on the same machine will
>>>> always be true. It may be the case today, a client is running on the same
>>>> computer as the server, but it may not be true in the future, and if it
>>>> does happen that client runs on a separate machine than the server, our
>>>> code should be able to call server. By binding the server to localhost,
>>>> this will not be possible.
>>>>
>>>> May I propose to give the server a different name? The server's name
>>>> can be resolved to the same machine as the client, as it is today, it can
>>>> also be resolved to a different machine in the future. On the security
>>>> side, the machine running the client should not name the path where the
>>>> server stores its sensitive information, i.e. certs, tokens, DB, etc. This
>>>> can be achieved with technologies such as virtual machine, or virtual path,
>>>> etc. A different name for the server will help this separation. As long as
>>>> the client, which is considered vulnerable and can be compromised, cannot
>>>> name the sensitive resources, i.e. cannot specify the resource's path, it
>>>> is considered safe from the client code and attacker.
>>>>
>>>> To summarize my proposal, we can:
>>>>
>>>>    1. Name the server machine differently from "localhost". -
>>>>    Flexibility in long term evolution, can resolve the name to same machine or
>>>>    different machine
>>>>    2. Prevent client code from naming sensitive resources of server.
>>>>    If client cannot name it, it cannot access it.
>>>>       1. Multiple technologies can be used to achieve the naming
>>>>       prevention, details to be discussed during implementation.
>>>>
>>>> Feedback welcome.
>>>>
>>>> Regards
>>>>
>>>> Song Li
>>>>
>>>> Co-founder and CTO
>>>> NewSky Security <https://newskysecurity.com>
>>>>
>>>> On Tue, Jun 7, 2016 at 5:53 PM, Junichi Hashimoto <
>>>> xju-hashimoto@kddi.com> wrote:
>>>>
>>>>> Hi Song,
>>>>>
>>>>> I think certificate type is a different topic but if your example
>>>>> solves my concern, please share the idea.
>>>>>
>>>>> In the draft[1], we see the following sample code:
>>>>>   var vehicle  = new WebSocket(“wss://localhost:4343”);
>>>>>
>>>>> To implement this, the local server has to keep a certificate which
>>>>> common name is 'localhost' and also keep the corresponding private key.
>>>>>
>>>>> Because this key is a part of the local server 'app', it is very hard
>>>>> to prevent attackers retrieving this key. This cause issues. e.g.,
>>>>>
>>>>> - Falsification of data
>>>>> - Man-in-the-middle between apps and the local server
>>>>>
>>>>> Additionally, the certificate and the key are valid on anywhere,
>>>>> anydevice. I don't think major providers allow such use.
>>>>>
>>>>> [1]
>>>>> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations
>>>>>
>>>>> Regards,
>>>>> Junichi
>>>>>
>>>>>
>>>>> On 2016/06/08 8:57, Song Li wrote:
>>>>>
>>>>>> Allow me to jump in for these questions.
>>>>>>
>>>>>> There are two types of ssl certificates: wild card and multi-domain.
>>>>>> If
>>>>>> example.com <http://example.com> is going to have a wild card
>>>>>> certificate, it will cover all example.com <http://example.com>
>>>>>> subdomains, such as www.example.com <http://www.example.com>
>>>>>> api.example.com <http://api.example.com>, etc. If admin of
>>>>>> example.com
>>>>>> <http://example.com> choose to use multi-domain certificates, the
>>>>>> certificates will cover a limited number of domains of example.com
>>>>>> <http://example.com>. Multiple domains can share the same
>>>>>> certificate in
>>>>>> both cases, they do not have to have different certificates, but they
>>>>>> can.
>>>>>>
>>>>>> Certificates are deployed to servers and they should not be shared
>>>>>> with
>>>>>> people who are not admins of the domains. Certificates are deployed on
>>>>>> the servers hosting the domain(s), and only public key portion of the
>>>>>> certificates will be sent over the wire. Things get more complicated
>>>>>> if
>>>>>> CDN is used to speed up content distribution, but can be solved using
>>>>>> multi-domain certificates. Clients, such as browsers / java code,
>>>>>> verifies the certificates before communicating with server for secured
>>>>>> content.
>>>>>>
>>>>>> Let me know if you need examples / implementation details. Our
>>>>>> company's
>>>>>> using a wild card certificated for our https://www.newskysecurity.com
>>>>>> domains.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Song Li
>>>>>>
>>>>>> Co-founder and CTO
>>>>>> NewSky Security <https://newskysecurity.com>
>>>>>>
>>>>>> On Tue, Jun 7, 2016 at 4:23 PM, Junichi Hashimoto
>>>>>> <xju-hashimoto@kddi.com <mailto:xju-hashimoto@kddi.com>> wrote:
>>>>>>
>>>>>>     Hi Kevin,
>>>>>>
>>>>>>     Implementers would like to know how to manage the certificates for
>>>>>>     https/wss connection in the server. For example, they would like
>>>>>> to
>>>>>>     know whether each server should have different certificates or
>>>>>> not,
>>>>>>     how the certificates should be kept securely, etc.
>>>>>>
>>>>>>     Junichi
>>>>>>
>>>>>>     On 2016/06/08 0:36, Gavigan, Kevin wrote:
>>>>>>
>>>>>>         Hi,
>>>>>>
>>>>>>         I've updated the Security section to include some general
>>>>>> points
>>>>>>         that
>>>>>>         apply to both WebSockets and RESTful web services:
>>>>>>
>>>>>>
>>>>>> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations
>>>>>>
>>>>>>         Kind regards,
>>>>>>
>>>>>>         Kevin
>>>>>>
>>>>>>         /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
>>>>>>         <mailto:kgavigan@jaguarlandrover.com>
>>>>>>         <mailto:kgavigan@jaguarlandrover.com
>>>>>>         <mailto:kgavigan@jaguarlandrover.com>>
>>>>>>
>>>>>>         /Office address:/
>>>>>>         GO03/057 • Building 523, Gaydon • Maildrop: (G03)/
>>>>>>         /Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35
>>>>>> 0RR
>>>>>>
>>>>>>         On 7 June 2016 at 14:18, Paul Boyes <Paul.Boyes@inrix.com
>>>>>>         <mailto:Paul.Boyes@inrix.com>
>>>>>>         <mailto:Paul.Boyes@inrix.com <mailto:Paul.Boyes@inrix.com>>>
>>>>>> wrote:
>>>>>>
>>>>>>             Excellent indeed.  I will look at this in detail later
>>>>>> today.
>>>>>>
>>>>>>             *Paul J. Boyes* | INRIX | Director of Telematics and
>>>>>> Standards -
>>>>>>             OpenCar  |  206-276-9675 <tel:206-276-9675> |
>>>>>>         paul.boyes@inrix.com <mailto:paul.boyes@inrix.com>
>>>>>>             <mailto:bryan@inrix.com <mailto:bryan@inrix.com>> |
>>>>>>         www.inrix.com <http://www.inrix.com>
>>>>>>
>>>>>>         <
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.inrix.com_&d=BQMFAg&c=QbuapHRvbn0JdC8vTVkPHg&r=PRAN7lum5Ra662QLho8LU3bhFjBvLXn3bBkFbW0Amjo&m=V5l0WXfOEJwhcE0JsN06mQ5SQhpXL-DuAuK3YcnTZoc&s=OqQVi_DcS5rv8or8hZdFvY0re6YF0Wl-_8okxrxOF0w&e=
>>>>>> >
>>>>>>
>>>>>>                 On Jun 7, 2016, at 3:56 AM, Peter Winzell
>>>>>>                 <Peter.Winzell@melcogot.com
>>>>>>             <mailto:Peter.Winzell@melcogot.com>
>>>>>>             <mailto:Peter.Winzell@melcogot.com
>>>>>>
>>>>>>             <mailto:Peter.Winzell@melcogot.com>>>
>>>>>>                 wrote:
>>>>>>
>>>>>>                 Excellent !____
>>>>>>                 I have just browsed through – Thank you for your hard
>>>>>>             work!!____
>>>>>>                 /pw____
>>>>>>                 __ __
>>>>>>                 *From:* Crofts, Adam
>>>>>>             [mailto:acrofts1@jaguarlandrover.com
>>>>>>             <mailto:acrofts1@jaguarlandrover.com>]
>>>>>>                 *Sent:* Monday, June 6, 2016 12:58 PM
>>>>>>                 *To:* public-automotive
>>>>>>                 *Cc:* Kevin Gavigan; Peter Virk; Lovene Bhatia
>>>>>>                 *Subject:* Draft Specification for Service Based
>>>>>>             Approach Using
>>>>>>                 WebSockets____
>>>>>>                 __ __
>>>>>>                 Hi All, ____
>>>>>>                 __ __
>>>>>>                 Kevin and I have drafted a specification for the
>>>>>> service
>>>>>>             based
>>>>>>                 approach using WebSockets, as discussed in Issue 81
>>>>>>                 <https://github.com/w3c/automotive/issues/81>. The
>>>>>> draft
>>>>>>             can be
>>>>>>                 found in the working group wiki here
>>>>>>
>>>>>>             <
>>>>>> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#WebSocket_2
>>>>>> >.____
>>>>>>                 __ __
>>>>>>                 The specification builds upon the approach raised by
>>>>>> Powell
>>>>>>                 Kinney, using a single WebSocket to send JSON data
>>>>>>             structures to
>>>>>>                 the server. The JSON structure specifies the desired
>>>>>> vehicle
>>>>>>                 signal specification (VSS) path, an action parameter
>>>>>> to
>>>>>>             specify
>>>>>>                 get, set, subscribe or unsubscribe as well as a number
>>>>>>             of optional
>>>>>>                 parameters.____
>>>>>>                 __ __
>>>>>>                 This specification allows:____
>>>>>>
>>>>>>                   * Use of the VSS, including wildcards and
>>>>>> indexing____
>>>>>>                   * GET/SET over WebSocket____
>>>>>>                   * SUBSCRIBE to receive change notifications,
>>>>>> allowing
>>>>>>             settable
>>>>>>                     change thresholds and upper/lower bounds____
>>>>>>                   * SUBSCRIBE to receive notifications at a given time
>>>>>>             interval.____
>>>>>>                   * UNSUBSCRIBE via a subscription handle____
>>>>>>                   * UNSUBSCRIBE from all notifications____
>>>>>>                   * Security tokens to be passed from the client to
>>>>>> the
>>>>>>             server,
>>>>>>                     such as OAuth 2.0____
>>>>>>
>>>>>>                 We'll go through this on the call on Tuesday night
>>>>>> and look
>>>>>>                 forward to hearing your thoughts.____
>>>>>>                 __ __
>>>>>>                 Kind regards, ____
>>>>>>                 __ __
>>>>>>                 Adam____
>>>>>>                 __ __
>>>>>>                 -- ____
>>>>>>                 *Adam C**rofts MEng (Hons) MIET*____
>>>>>>                 Connected Infotainment____
>>>>>>                 Vehicle Engineering____
>>>>>>                 Tel: +44 (0) 1926 921607
>>>>>>             <tel:%2B44%20%280%29%201926%20921607> | 87311607____
>>>>>>                 Mob: +44 (0) 7790 094350
>>>>>>             <tel:%2B44%20%280%29%207790%20094350>
>>>>>>
>>>>>>                 Desk: G03/054, Building 523, Gaydon____
>>>>>>                 Mail Drop: G/26/3, Building 523, Gaydon____
>>>>>>                 __ __
>>>>>>                 ____
>>>>>>                 __ __
>>>>>>                 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     <>------------------------------------------------<>
>>>>>>              au x HAKUTO  MOON CHALLENGE
>>>>>>                http://au-hakuto.jp/
>>>>>>        KDDI/au competing in the Google Lunar XPRIZE
>>>>>>        Providing communication technology support for
>>>>>>        the Japanese team - HAKUTO
>>>>>>     <>------------------------------------------------<>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> <>------------------------------------------------<>
>>>>>          au x HAKUTO  MOON CHALLENGE
>>>>>            http://au-hakuto.jp/
>>>>>    KDDI/au competing in the Google Lunar XPRIZE
>>>>>    Providing communication technology support for
>>>>>    the Japanese team - HAKUTO
>>>>> <>------------------------------------------------<>
>>>>>
>>>>
>>>>
>>>
>>
>
Received on Thursday, 9 June 2016 19:06:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:50 UTC