- From: Gavigan, Kevin <kgavigan@jaguarlandrover.com>
- Date: Fri, 10 Jun 2016 15:26:46 +0100
- To: Song Li <ls@newskysecurity.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: <CAKaHsmeKyKaC_DCjaFnWD9JqTRLhDKVEuLQwj=5+7HEX7q-VLg@mail.gmail.com>
Hi Song, Thanks very much once again, your input was very helpful. Regards and best wishes 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 10 June 2016 at 15:00, Song Li <ls@newskysecurity.com> wrote: > Hi Kevin, > > Thank you so much for the nice write up, yes this covers the essential > elements of my suggestion. As you mentioned, the success of the > communication being secure depends on proper implementation of the client / > server, i.e. client should always check the cert and if not trusted, client > should refuse further communication with server. On the SOTA side, > manufactures may choose to push and invalidate a cert any time as response > to a security incidence, i.e. cert breach. > > Thanks again. > > Regards > > Song Li > > Co-founder and CTO > NewSky Security <https://newskysecurity.com> > > On Fri, Jun 10, 2016 at 4:24 AM, Gavigan, Kevin < > kgavigan@jaguarlandrover.com> wrote: > >> Hi Song, >> >> Thanks once again for your helpful response and I completely agree that >> issues like software over the air (SOTA) renewal of certificates is a big >> topic, more than a single email could cover. >> >> *>> To solve this the client will need to have the infotain's cert >> pre-installed and trusted.* >> >> Just to check I understand the part we have discussed so far, is the >> proposal: >> >> i) the W3C specification would define that a client on the vehicle >> connects to a server on the same vehicle using e.g. infotain:4343 >> >> ii) On the vehicle, the etc\hosts file would be configured to map >> infotain to 127.0.0.1 >> >> iii) Each manufacturer that is implementing a server would create their >> own self-signed-certificate with a common name (CN) of 'infotain' and >> import details for the self-signed-cert into the cert store used by clients >> on that vehicle e.g. the OpenSSL ca-bundle.crt file. >> >> iv) Client could then try to connect to infotain:4343 which would resolve >> to the App Server running on the vehicle on 127.0.0.1 port 4343 and client >> could verify the servers self signed cert; they then perform the TLS >> handshake to create an SSL tunnel. >> >> v) Client and server have a HTTPS connection (so RESTful web service >> could use this) or client can request that server moves to WebSocket >> protocol (over wss). >> >> So in this scheme, all communication between client and server (which >> could include details of user tokens), is encrypted (which is good of >> course as it prevents details being logged accidentally by a poor >> implementation or sniffed using e.g. Wireshark) but if an attacker had >> root access on the vehicle, they could still circumvent the security and >> install a MITM, but if they have root access the game is pretty much up >> anyway? >> >> I would be very grateful if you could confirm whether this is what you >> were suggesting >> >> Thanks and best wishes, >> >> 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 9 June 2016 at 20:05, Song Li <ls@newskysecurity.com> wrote: >> >>> 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 Friday, 10 June 2016 14:27:38 UTC