- From: Song Li <ls@newskysecurity.com>
- Date: Thu, 9 Jun 2016 12:05:37 -0700
- 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>
- Message-ID: <CAJmxCGB+JagQqdBwYJ+sAaVOmPn7zmwGeLk009GNri_9VwdRKQ@mail.gmail.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