Vehicle APIsのセキュリティーとプライバシー Security and Privacy Consideration on Vehicle APIs
Unofficial Draft,
hit 't' to toggle language
Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
この文書はW3C Vehicle APIs (Vehicle Information Access API 及び Vehicle Data Specification) を実装・運用するにあたって留意すべきセキュリティーとプライバシーについて述べたものである。 この文書ではVehivle APIを備えたIVI (In-Vehicle Infotainment system) を想定して、典型的な構成、参照すべき勧告、プライバシー保護について示し、 またAPIの利用を特定のコンテンツ提供者に制限するためのベストプラクティスについて述べる。
This document describes security and privacy consideration for implementing and utilizing the Vehicle APIs (Vehicle Information Access API and Vehicle Data Specification). This document imagines an IVI (In-Vehicle Infotainment system), presents typical architectures, recommendation to be referred and privacy protection. It also describes best practices of restricting API use for specific developers.
This document is a NOTE made available by the W3 Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has had any editorial control in it preparation, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by the NOTE.
このドキュメントに関する議論はpublic-auto-privacy-security@w3.orgで行われる。
Public mailing list public-auto-privacy-security@w3.org is preferred for discussion of this NOTE.
Vehicle APIsは乗用車のIVI (In-Vehicle Infortainment System)に実装されることを想定して策定されている。 その実装にあたってはPC上のブラウザとは異なり下記の点に留意されなくてはならない。
Vehicle APIs are supposed to be implemented on an IVI (In-Vehicle Infotainment System) for passenger automobiles. Compared to browsers on desktop PCs, particular attention should be given to following points.
上記の目的のためには、ランタイムのみならずIVIの周辺環境も注意深く設計される必要がある。 そのためこの文書ではIVIのアーキテクチャ、IVIとCAN（Car Area Network）との接続のなされ方についても述べ、 サーバサイドのセキュリティや、緊急時におけるプライバシの取り扱いなどにも触れる。
To satisfy these purposes, web-runtime and as well as its environment should also be designed carefully. Therefor this document describes architectures of IVI and connection among IVI and CAN (Car Area Network), and refers to server-side security and privacy on emergent situation.
この文書はVehicle APIsに周辺のセキュリティー・プライバシーのトピックを扱うが、 その他の部分について、IVIの開発者は別の適切な文書を参照することを勧める。
This document is on security and privacy topic around Vehicle APIs. As for other topics, IVI developers are encouraged to refer appropriate specifications:
Conformance requirements are expressed with a combination of descriptive assertions and [RFC2119] terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [RFC2119] However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
本文書ではIVIがインターネットとCANの両方にアクセス可能な場所に設置されていると想定する。 CANとIVI、IVIとInternetの間は適切に分離され、何らかのフィルタが設置されるべきである。
We suppose that IVI is located where it can have access to Internet and CAN. Both CAN/IVI and IVI/Internet are appropriately separated and there should be certain filters at each intermediate.
CAN - (X) - IVI - (Y)- Internet
(X) CAN-IVI間のフィルタはIVIからCANに異常なシグナルが混入することを防止し、 CANからIVIに不要な情報を送出しないようにしなくてはならない。
(X) A filter between CAN and IVI must prevent abnormal signals from entering into CAN and pass minimal necessary information from CAN to IVI.
(Y) IVIとInternetに設置するフィルタは、IVIを不正なアクセスから守り、 Internet上の有害なコンテンツがIVIに持ち込まれることを防止する。 これには様々なレイヤ・機能のものが考えられ、IVIの一部として実装することがふさわしい物もある。
(Y) A filter between IVI and Internet protects IVI from unauthorized accesses and deters malware infection. There are several approaches among layers and functions. Some of them might be appropriate to be implemented as a part of IVI rather than as an external filter.
フィルタを通過し、不正なコードが内部に混入した場合に備え、IVIは下記の機能を持つことを検討すべきである。
In a case that a malicious code come into inside of IVI by passing those filters, IVI should be considered to have following architecture/functionality.
IVIはこれまで個々のプラットフォーム上で開発されてきており、 Vehicle APIを取り込んだIVIはスマートフォンに見られるように、 ネイティブアプリとWebアプリをサポートすると考えられ、 Webアプリにもブラウザで動作するものと、Runtimeを内包した形態のものが考えられる。
IVI has been developed on many platforms so far. As seen in smartphone world, IVI with Vehicle API will support both native application and Web Application. There are two type of web application; one is working on a browser and another contains web-runtime inside of the app.
OS = BrowserApplication(Runtime) = WebContent OS = NativeApplication (Runtime, WebContent)
Vehicle APIsを含むW3C規格は、双方のモデルに含まれるWebContentとRuntimeの関係を重視し、 正しいコンテンツがRuntimeの機能を正しく利用できることを要請する。 IVIの安全性を考える場合は、RuntimeとOSとの関係がより重視される必要がある。 その際の観点は下記の通りである。
W3C specs including the Vehicle APIs attach much value on the relationship between WebContent and runtime in both models and require that an authorized content should have access runtime functions. While, considering IVI security, the relationship between runtime and operating system should be more taken care. Here are points***.
Vehicle Information Access APIが定めるget/set/subscribeのうち、setをサポートする場合、リソース競合の観点から 慎重な設計が求められる。現在のSpecはデータポイントのロック機構をサポートしないため、 少なくとも、「setを行うことのできるContentがIVI上でたかだか一つであること」を保証し無くてはならない。 そうでない場合、一つのデータポイントに対し相反する2つの入力が与えられたり、 2つののデータポイントを同時に操作するべき時に片方しか操作できないといった問題が生じうる。
Vehicle Information Access API defines get/set/subscribe. It requires careful design from the point of the resource race if an implementation supports the set method. Current spec doesn't support lock mechanism of data-point. Therefor system must ensure that at most only one content exists at the same time which is able to access set-methods. Otherwise one data-point may receive more than two contradict input. Or a content may set only one data-point even when the content need to change more than two data-point all together.
以下に挙げるSecurty関連勧告は開発者がセキュリティを検討する上で、 核となる技術であり、Vehicle APIsを実装するUser-Agentはこれらも実装を必須とすべきである。
Followings are fundamental recommendation for considering web security, User-Agent which implements Vehicle APIs must implement them as well.
開発者は上記を有効に利用するとともに、一般的なWebセキュリティ技術も取り入れることで、 悪意のあるコードがIVIにもたらされないよう留意する。 そのような技術には下記のものがある。
Service provider should utilize above recommendation efficiently and incorporate general techniques of web security so that malicious code cannot be executed in IVI. Following techniques are such examples.
WebのSecuiryを有効に保つには、セキュリティホールが見つかった際に速やかなアップデートを行うことが必要である。 [CVE] は幅広くWebRuntimeあるいはOSに脆弱性を報告している。 IVIの開発者はそれらの情報をもとに、 OSを含めたアップデート方法を予め検討しておくべきである。 脆弱性の深刻度を定量化するには [CVSS] を利用してもよい。
Once a security hole is reported, system must be updated as soon as possible to keep it secure. [CVE] continuously announces vulnerabilities of various OS and web-runtime. In several layer such as web-runtime, libraries or OS, IVI should be designed to be promptly updatable. [CVSS] could be a help to quantify vulnerability impact.
Vehicle APIsから取得できる情報は、ドラーバーや車の所有者と容易に関連付けることができ、 そのため"個人情報"に当たると考えられる。それらの情報はプライバシー保護の対象として 扱われるべきであるが、その方法は個人や、その時の状況、その地方の条例によって変わる。
Vehicle data and its location data in specification of W3C are considered as “personal data” because a driver or owner of a vehicle is easily identifiable by correlating with information from other sources. Therefore, these vehicle data and its location data should be treated as object information for privacy protection. However, privacy protection may differ by individual, by situation, and by local regulation.
サービス提供者は、VehicleAPIによって得た情報をIVIの外へ送出しようとする場合、 ユーザのプライバシーを保護しなくてはならない。 具体的に下記に対応して、ユーザのpreferenceに沿った運用を行わなくてはならない。 Service provider must protect end-user's privacy when they send out location or information from Vehicle APIs. Followings should be proceeded and information has to be treated in complying with user preferences.
一つの車両は複数のドライバーに利用され、一人のドライバーは複数の車両を利用すると考えられる。 サービス提供者は、そのような状況を踏まえ、ある人のデータやプリファレンスが 別のユーザから閲覧できないようにする必要がある。
An individual may drive a car owned by others. An individual may drive multiple cars. Service provider take this situation into consider and should manage one's preference so that others cannot see the preference.
[DNT] はWeb Applicationに対し自己のトラッキングを行わないように要求するための HTTP ヘッダについての勧告であり、広くサポートされている。 車両では交通事故等、生命・財産の危機に瀕することがあり、 その場合は一時的にDNT機能をOFFにすることも検討すべきである。
The Do Not Track ([DNT]) is the proposed HTTP header field that requests that a web application disable either its tracking or cross-site user tracking of an individual user. In view of peculiarity of Automobile, in the event of emergencies to protect the vital interests and property (vehicle) of an individual, temporal deactivation of DNT function may be required.
WebAPIの利用はオリジン単位で管理され、ユーザの意思に基づき許諾されてきた。 API実装者はその考え方にしたがって、Vehicle APIの利用に際してユーザに何らかの選択肢を与えるべきである。
To access to some kind of Web API, each [ORIGIN] need permission which is granted by User Agent on behalf of end user. Implementer should keep this manner and provide option that end-user can present their preference.
Vehilcle APIは詳細なインターフェースを提供するため、実装者の視点で開示が望ましくないものも含まれる。 そのようなデータポイントについては、APIの定義にそって提供を行わないこともできる。 更に進んで、ユーザを保護するという観点から、特定の組織や、許諾を与えたコンテンツにのみAPIの利用を 認めたい場合が考えられる。そのためのいくつかの選択肢を示す。
Vehicle APIs defines interfaces for details data and some of them could be not preferable to be public from the perspective of implementers. Spec allows implementer not to expose these data-points. Moreover, an implementer may considers users benefit and would like to expose some of data-points only to certain organizations or authorized contents. Here are some best practice to realize such access control.