- From: Song Li <ls@newskysecurity.com>
- Date: Fri, 10 Jun 2016 07:00:07 -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: <CAJmxCGCKf-8bgjNFG-=aDnKdAB1ExK15iTpc0LQKCHBEqyC8xw@mail.gmail.com>
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:00:38 UTC