Hit 't' to change languages.

この文書はW3C Vehicle APIs (Vehicle Information Access API, Vehicle Data Specification, Vehicle Information Service 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, Vehicle Data Specification, and Vehicle Information Service Specification). This document supposes an IVI (In-Vehicle Infotainment system), and presents a typical architecture, recommendation to be referred and privacy protection. It also describes best practices for restricting API use to specific developers or application

なお、本項は網羅的なリスク評価を行うものではないことに留意する。 その代わり、特に注意が必要な点について議論する。

This document does not provide a comprehensive risk assessment for IVI with Vehicle APIs. Instead of that, this document discusses points that required special attention.

はじめに Introduction

Automotive WG は乗用車の IVI (In-Vehicle Infotainment System) への実装を想定して、 Vehicle Access API, Vehicle Data Specification, Vehicle Information Service Specification を策定した。 これらのAPIは車に直接アクセスするインターフェースではないが、表現がくどい 間接的にセンサーデーターを取得したり 制御のリクエストを行ったりする方法を規定している。 PC向けではないこれらのAPIに特有の課題を調査・検討するために Security & Privacy タスクフォースが 設置された。 この文書はそのタスクフォースの成果をまとめたものである。

For the use on passenger car's IVI (In-Vehicle Infotainment System), Automotive WG published three specifications: Vehicle Access API, Vehicle Data Specification, and Vehicle Information Service Specification. These APIs are not a direct interface that accesses car system but an indirect interface that obtains sensor data or changing values by sending requests. In ordered to investigate domain specific issues that may be caused by these non PC-oriented APIs, Security and Privacy Task Force was formed under the working group and business group. This document reports the result of the task force's study.

車にとって最も大切なことは利用者の安全であり、Vehicle APIsやそれが実装されたIVIが この安全性を損ねるものであってはならない。 そのため、この文書はAPIの実装にかぎらず、IVIの構成自体にも言及することになった。 2節ではタスクフォースが収集したAPIのユースケースと懸念点を列挙する。 3節ではIVIの構成や、置かれる環境、Webランタイムとアプリケーションの関係についてモデルを示す。 4節では標準的に利用されていて、車向けのIVIにも導入すべき基礎的なWebのセキュリティー技術について述べる。 5節では最初に抽出した課題への対処方針を示す。 6節にはwebと車、セキュリティとプライバシーに関連して現在取り組まれている活動を紹介する。

Primary concern of automakers is the safety of passengers. Vehicle APIs or IVI that implements the APIs should not compromise safety. Hence, this document focuses on not only API implementation but also IVI design. Document structure is as follows: Section 2 lists up API use cases and concerns that the task force has collected. Before discussing each concern, section 3 provides a model architecture of IVI, IVI environment and composition of the web runtime and applications. And section 4 introduces fundamental web security technologies which are commonly supported on today's browser and should be supported on IVI as well. Then section 5 extracts requirements from the use cases and shows strategies to tackle them. Finally, section 6 gives an overview of on-going activities that are taken for web, automotive, security and privacy.

この文章は、セキュリティーとプライバシー上の懸念について取り扱い、解決の方向を提示する。 一方でリスクの評価を提供したり、この文書に従うことで問題が解決することを保証したりするものではない。 詳細なリスクの評価は実装者に委ねられており、不明な場合は安全な側に倒すことを推奨する。 また、IVIのハードウェア要件や、全体の設計を提供することも行わない。 そういった観点では、以下に示す規格を参照することを勧める。

This document focuses on security and privacy concerns and provides strategies to tackle them. It does not provide a certain risk assessment or endorses that conformance to this document solves thease concerns. Implementer should perform a precise risk assessment and must err on the side of caution. Also this document does not provide hardware requirements nor an entire design of IVI. For these purpose, we recommend to refer more general specifications:

文書規約 Document Conventions

TODO: Mark up

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]]

APIのユースケース Use cases of APIs

Automotive WGではVehicle APIsの策定の仮定で、将来的な拡張を含めどのようなユースケースが想定され、 また懸念される事項が何であるか調査を行った。下記はそのリストである。

On the process of Vehicle APIs formulation, Automotive WG has investigated use cases and concerns that would be brought by current APIs or the future revisions. Following is the summarized item list.

これらのアイテムはコネクティッドカーに対する自由な期待に基づくものであり 規格としての要求事項を定めるものではない。 また API 規格が各項目の実現性を保証するものでもないことに注意する。

Note that the items come from free expectation for connected car and does not define requirements. Also API specifications does not guarantee that each item is feasible.

  1. 1.(48) 不正侵入の通知 車両が不正に侵入された場合運転者または所有者にそれが知らされること。 Intrusion Alert Driver/Owner wants to be alerted if their car is intruded.
  2. 1.(50) 排他的な操作 運転中他の利用者はログインも車の制御も出来ないこと。 Exclusive Control During the driving, prevent other users from login and controlling the vehicle.
  3. --4.(04)-- データ改ざん防止 保険サービスを行うため、車両から得られるデータは改ざんされていてはいけない。 Anti-tampered Data As an insurer, I need to be sure that probe data is not tampered.
  4. 認証されたデバイス ADASのようなシステムは認証されたオンボードのセンサ、外部ソースのデータを受理する。 Authorized Device High-reliability system, such as Advanced Driver Assistance System (ADAS) Controller, accepts input from authorized onboard sensors or authorized external source(s)
  5. --4.(12)-- 仮想的な同乗 ドライバーはドライブを仮想の同乗者と楽しみたい Virtual Trip Driver and/or passenger(s) in car want to share journey with virtual passenger(s) that are not in car
  6. !--4.(52)-- ホームセキュリティとの連携 車両のセンサー、カメラを家庭のセキュリティアラームシステムへの入力として利用できる。 Home Security Sensors and cameras in the car are included in the set of sensors providing input to customer (and e.g. neighbours) home security alarm. To do this the vehicle and home alarm system will need to mutually authenticate so that home alarm trusts inputs and customer's vehicle only provides input to alarm system(s) selected by the customer. Normally just their own system, but e.g. in future, a neighbourhood watch group could agree to share external sensor / camera data
  7. !--4.(53)-- シームレスなデータ利用 ユーザーの所有する音楽、動画などのデーターは車、クラウドどこにあるとかかわらずシームレスに利用できる Seamless Data Use Media (including photos, videos, music (subject to DRM licensing)) is seamlessly shared between all of the user's devices including their car and with offline cloud storage e.g., User's Dropbox, OneDrive etc account. User can seamlessly view and play their content on any device including their car. Requires that each device or service that the user has content stored on can securely share the user's content. To do this, either the device or the identity of the user logged in on the device or service will need to be verified before content can safely and securely be shared between devices. If content is to be seamlessly downloaded from cloud storage, may need to obtain and use security token (e.g. OAUTH2) to access user's content.
  8. -4.(55)-- 公共交通情報システムとの連携 ************ Public Traffic System*** Vehicle suspension sensors, front facing cameras etc can detect damage to road surface (potholes, broken manholes, broken drain covers etc) and communicate location and details of damage to other vehicles and to the local authority responsible for repairing roads. Vehicle needs to prove its identity to other vehicles and to local authority service so that input can be trusted.
  9. 2.(11) ADASは安全上重要な機能を制御することがある。 Set for Critical Control Advanced Driver Assistance System (ADAS) Controller sets safety critical controls when driving vehicle
  10. 2.(16) ****** Set for HVAC IVI system shows the status of various climate control equipments as GUI and lets a user control it via touch screen. (Even set API is not recommended)
  11. 2.(17) 車外からの窓の開閉 *** Remote Window Control A user uses his smart devices to remotely check whether side windows of his parked car are closed or not, and to send a request to the car for closing it if opened.
  12. 2.(18) 車外からの空調設定 *** Remote HVAC Control A user uses his smart devices to start his car remotely, and turns heaters on to warm up the car inside before getting in the car.
  13. 2.(25) 車外からのドアロック *** Remote Door Lock Driver would like to remotely lock/unlock vehicle.
  14. 2.(28) 車外からのシート設定 *** Remote Seats Configuration Driver would like to configure seat settings remotely.
  15. 2.(32) 車外からの設定 *** Set from Cloud Service Automaker only wants to allow remote settings via cloud not by direct connection.
  16. 2.(49) Setの単一ソース *** Exclusive set One "Set" API is only allowed to accept input from one source at one moment
  17. 3.(03) アプリケーション審査 *** Application Audit As an OEM, I don't permit any application to use Vehicle APIs without my check.
  18. 3.(09) 信頼できる第三者期間 *** Trusted 3rd Parties Ability to query registry of trusted 3rd parties, retrieve identification mechanisms
  19. 3.(24) 運転履歴の取得 *** Drive Event Log 3rd party would like to see log of driving events
  20. 3.(27) 所有者への報告 *** Report to Owner Vehicle owner subscribes to 3rd party monitoring of vehicle data and trouble codes to ensure vehicle is running in good health
  21. 3.(29) Applicationが利用できるAPIの差 *** API Limitation*** Automaker has access to all data elements including elements such as those relating to vehicle quality or operating data whereas application developer only has access to subset.
  22. 3.(45) 窓の自動開閉 *** Automated Window Operation Service monitors weather and checks if windows are open, they are closed.
  23. 3.(51) Logの参照権限**** *** Permission for Log History An application can only access the log created by itself
  24. 6.(35) ドライバー認識 *** Identification of Driver Current driver is identified.
  25. 6.(36) 同乗者の認識 *** Identification of Passengers Family is travelling in vehicle and all passengers are identified.
  26. 6.(38) 料金の支払い*** Toll Payment Driving across toll bridge or parking at a charged space, the responsible party is identified and payment from their account is made.
  27. 6.(56) 個人に基礎をおいたサービス *** Personal Basis Services IVI apps such as recommendation, reservation, shopping, pay-per-use service, etc., should operate in a personal basis, which means that apps and its API have to be changed by driver/user.
  28. 6.(60) 個人情報の保護 *** Protection for Personal Data E-commerce from the dashboard for drivers’ purchases of fast food, gas, etc. has been available. Cars become hackers' and rogue mechanics’ target for identity theft (credit card numbers, home address, e-mail information and all the other personal details).
  29. 5.(57) 取り扱いに注意が必要な場所 *** Sensitive Location Consumer has some locations he/she does not want other people to know. (Home, religious site, specialized hospital, secret 3rd place, etc.)
  30. 5.(58) ユーザーによるAPIの制御 *** API Control by User Consumer has less right of choice for data elements, rectification and erasure of data.
  31. 5.(06) データ送出先の指定 *** Destination of Personal Data I am willing to provide vehicle data for traffic monitoring, but does not want a police officer to know my destination and the exact speed of my car.
  32. 5.(08) データ流動の調整 *** Data Granularity control As a user, I'd like to apply different data granularity depending on whom to send the data.
  33. 5.(01) 個人情報の削除 *** Removing Personal Data As a user, I'd like to remove any private data from the car when I leave.
  34. 5.(15) DNTによる追跡拒否 *** Do Not Track for Vehicle When I turn DO-NO-TRACK on, I expect any of my activities are not monitored nor recorded
  35. 5.(05) DNTの例外 *** Exception for Do Not Track I usually set "Do Not Track", but help me immediately after the accident.
  36. 5.(19) 情報提供の事前合意 *** Prior consent for data use If users agree to provide vehicle information to the weather station, many cars can be used to get weather information such as amounts of rain and ambient temperatures.
  37. 5.(21) 事故のための記録 *** Record for accident IVI records the scene before and after an accident (for insurance or testimony)
  38. 5.(23) ドライバによるログの確認 *** Log Transparency Driver would like to see log of ADAS/driving events
  39. 5.(39) 車両情報の警告 *** Alert for Car Condition Customer is alerted to low tire pressure, repair locations are recommended.
  40. 5.(40) 緊急連絡 *** Emergency** Emergency responder is called to accident, vehicle reports who is in the car and can report if there are existing medical conditions

以上の様に Vehicle APIs への期待は IVI への期待であり、 寄せられた懸念に対してはユーザーエージェントのみならず、 IVIのシステム全体として対策を検討する必要があることがわかった。 以下ではまず、議論の前提として想定するモデルアーキテクチャを定め、 セキュアなWebサービスを構成するために標準的に利用されている他のW3C勧告について概観する。 Requirementsという言葉、５章の位置づけに触れる。 その上で、ユースケースを整理して得られた課題について対処方針を検討する。

As described above, the expectations are not limited to Web APIs and the concerns should be treated in IVI system rather than API implementation. In the rest of this document, we provide a model architecture of IVI first and introduce fundamental W3C recommendations that supports web securities. Then we discuss issues that are derived from above list.

モデルアーキテクチャ Model Architecture

この節ではAPIが想定する抽象的なアーキテクチャを示す。 より詳細なモデルは例えば[[GENIVI]]や[[AGL]]が提供している。AGLの方のモデル図

This section provides a model architecture that Vehicle APIs expect. The readers could refer [[GENIVI]] or [[AGL]] for more precise architecture.

まず、IVIは図1のように、 インターネットとCAN(Car Area Network）の双方にアクセス可能な環境に置かれる。 通常、アプリケーションはインターネットから得られ、IVI上で実行される。 アプリケーションはVehicle APIsを通して車両の情報を取得する。 アプリケーションはこれ以外の方法で車両の情報にアクセスすることはできない。

Fig. 1 shows that an IVI is located where it has access to both the internet and CAN (car area network). Typically, a web application is downloaded from the internet and executed on the IVI. The application obtains car information via Vehicle APIs and it does not have any other way to access car information.

CAN - (X) - IVI - (Y)- Internet
IVIの置かれる環境 Environment around IVI

IVIは、ベースとなるOSとその上でWebアプリケーションを動作させるWebランタイムからなる。 Service specの実装では更にローカルサーバーが置かれる。 この文書ではhtml/js/cssの記述に基づいてUIを提供し、プラットフォームに リクエストを送るモジュールをWebランタイムと呼ぶ。

An IVI consists of an operating system and a web runtime that executes web applications. Vehicle Information Service specification requires a local server as well. Web runtime in this document stands for a module that provides UI and sends requests to OS according to a given html/js/css description.

アプリケーションには図2のような幾つかの形態が考えられる。

Fig. 2 shows possible application types.

Normal content
インターネット上のコンテンツがダウンロードされ、ブラウザ上で実行される形式。 Browser (User agent) downloads contents from the internet and executes them.
Webview based
コンテンツがWebviewを利用する形で予めアプリケーションと一体となって配布される形式。 Application uses webview to execute web contents, which is a part of application in most cases.
Native App
OSがサポートするネイティブのアプリとして提供される形式。 Application is provided in a platform native format.

アプリケーションの形式 Three application types

Webviewベースのアプリケーションは、 APIを利用するコードが予めデータとして一つのパッケージに収められている点に特色がある。 Webviewベースの場合、マーケット（アプリケーション配布のシステム）での審査などを活用し、 APIの悪意ある利用をある程度防ぐことができる。 コードが全てアセットとされているわけではないので修正が必要

Webview type applications could have web contents that utilize Vehicle APIs in its package as a part of asset data. For this type of application, the market operator (i.e., the application distributer) could review application and reject them if they contain malicious codes.

Vehicle APIs は車の情報を提供する２つのインターフェースを提供する。 DOM API である Vehicle Information Access API は Normal content と Webview base 形式のアプリケーションに車両情報へのアクセスを提供する。

Vehicle APIs provide car information in two ways. Vehicle Information Access API, a DOM API, provides an interface for Normal Content and Webview type applications.

実装者が Webruntime だけでなく、IVI そのものも開発する場合、 ネイティブアプリケーションにも同様の車両情報を提供したいと考えるかもしれない。 その場合はVehicle Service Specを実装することが望ましい。

If one is web runtime implementer and develops IVI as well, he/she hopes to provide car information in the same manner for all types of application. In this case, Vehicle Service Specification is preferable to be implemented.

標準的なWebセキュリティー技術の利用 Common Web Security Techniques

以下に挙げるセキュリティー関連勧告は開発者がセキュリティーを検討する上で核となる技術であり、 Vehicle APIsを実装するユーザーエージェントはこれらも必ず実装をしなくてはならない。

Followings are fundamental W3C recommendation for considering web security. User-Agent which implements Vehicle APIs must implement them as well.

開発者は上記を有効に利用するとともに、一般的なサーバーサイドのセキュリティー技術も取り入れることで、 悪意のあるコードがIVIにもたらされないよう留意する。 そのような技術には下記のものがある。

Service provider should utilize above recommendations efficiently and incorporate general techniques of web security so that malicious code cannot be executed in IVI. Example techniques are as follows.

課題と対処方針 Vehicle Specific Requirements and Strategies

2節であげたユースケースと課題は多岐にわたり、レベルも様々である。 その中で共通して見えてくる車に特有の課題は、システムとデータの健全性をどのように確保するか、 APIの利用を誰が、どのように制限するべきか、データの所有者の権利をどのように守るか といったものである。 この節ではこれらの課題に絞って、その対策方法を検討する。 5.1の中身を少し移動する。

Use cases and concerns listed up on section 2 are vary in both domain and level. We derive three common requirements from them; (1)how to keep health of system and data, (2)how and who restricts API usage and (3)what is the standard policy to protect data owner's right. This section focuses on these topics and discuss strategies for them.

システムとデータの健全性確保 System and Data Health

前章で標準的なWebのセキュリティー技術を概観したが、 その正しさはベースとなるプラットフォームに依存する。 この章ではWebランタイムの周辺に目を向け、必要なセキュリティー対策について検討する。

The previous section introduced basic web security technologies. The technologies relies on the integrity of the base platform. This section focuses on the environment where web runtime runs and discusses its security requirements.

外部のネットワークに接続するIVIには外部からの不正アクセスや、意図しないマルウェアの混入など、 PCと同等の脅威が存在する。 これらの脅威に対しては事前の対策とアップデートが重要である。 proactiveが今ひとつ

IVI is connected to networks and there are the same kinds of threats that exist on PCs such as unauthorized accesses or malware intrusions. To protect system from these threats, proactive protection and system update are effective.

事前の対策としては IVIの諸機能を独立したセグメントとして設計し、 不必要なアクセス経路を物理的・論理的に遮断すべきである。 Vehicle Information Service Specification のように、 リクエストを処理するステップを複数に階層分けすることも攻撃を困難にする。 不十分

As for proactive protection, IVI system should be designed as a set of independent modules to prohibit unnecessary accesses in both of physical and logical ways. Vehicle Information Service Specification has a model architecture where a request is passed from application to car through several modules. This multi step architecture makes it harder for a malicious code.

システムの健全性を保つためにアップデートは不可欠である。 セキュリティーホールが見つかった際に速やかなアップデートを行うべきである。 [[CVE]] は幅広くWebruntimeあるいはOSに脆弱性を報告している。 IVIの開発者はそれらの情報をもとに、 OSを含めたアップデート方法を予め検討しておくべきである。 脆弱性の深刻度を定量化するには [[CVSS]] を利用してもよい。

System update is critically important to keep system safe from attacks. Once a security hole is found, system should be updated as soon as possible. [[CVE]] continuously announces vulnerabilities of various OS and web browsers. In several layers such as web runtime, libraries or OS, IVI should be designed to be promptly updatable. The more serious vulnerabilities should be given priority to be fixed. [[CVSS]] helps to quantify vulnerability impact.

ファームウェア・ソフトウェアのアップデートはシステムの健全性を維持する上で不可欠であるが、 アップデート機構そのものが脆弱性となるケースもしばしば見られる。 ISOは特に車載ソフトウェアのアップデートに関してプロトコルを規定しており、 これを参照して定期的なアップデートを行うべきである。

The process of system update itself often has vulnerabilities and has been attacked. ISO will define an update protocol (x.itsec-1) for software that works on car soon. The protocol could be utilized for system update for IVI as well.

ハードウェアによるセキュリティー向上も利用できる。 [TPM]]はプログラムの署名を改竄が困難な形で実現するもので、 システムの健全性をチェックするために利用することができる。

To check system health is not easy because the checker itself might be tampered. Dedicated hardware helps to do it securely. [[TPM]] realizes highly anti-tampered electric sign and improves integrity of report that a car would send to a cloud server.

不正侵入への対策 Protection against Intrusion and Attack

Webアプリケーションは、ローカルのファイルにアクセス出来ないなど、ネイティブアプリケーションに 比べて強い制限を受けており、システムへの攻撃が比較的困難である。 一方でWeb runtime自体が大きく複雑なため、API実装やプラグイン・モジュールにメモリ破壊などの問題が しばしばあり、それらの脆弱性をついたウイルス感染などがあった。

Generally, the capability of web application is restricted; for instance it does not have access to local files. It is difficult for a web application to attack a system compared to a native application. On the other hand, web runtime itself is a huge and complicated software and it has had vulnerabilities such as implementation bugs or memory corruption on its plug-in.

問題のあるアプリケーションを取得しないようにするためには アプリの入手元を信頼の置けるサイトに限定することが考えられれる。 例えば[[!SafeBrowsing]]はブラックリスト方式で マルウェアを配布したり、フィッシング目的のサイトのURLへアクセスを試みると警告を出す。

To prevent downloading a malicious application, system could filter URL from where code is provided. For instance, [[SafeBrowsing]] provides a blacklist filter that covers hosts that distribute malwares or that are suspected as phishing sites.

URLをフィルタするだけでなく、問題のあるコードを除去することも必要であれば、 ローカルにProxyサーバを置いてサニタイズ処理を行わせることもできる。 Proxyサーバを利用することのメリットはWebランタイムには変更を加える必要がない点である。

Removing malicious code at client side will be a solution if the public filter does not know yet that a site is a malicious one. A local proxy server can be used for such sanitizing task. Because the local server is independent from other applications or modules, the server can be updated without changing web runtime.

車に対しては直接的な不正アクセスの事例も幾つか報告されている。 これらの事例では車に備え付けの無線LANアクセスポイントへの不正ログイン、 偽装された基地局への誘導、 クラウドサーバーへの不正なログインなどが行われている。 IVIのセキュリティはそれらへの依存が少ない形で構成されることが必要である。

There are several security researches that successfully attack car systems from remote. In these studies, vulnerabilities of modules around IVI become first step of the attacks. These modules include wireless access points equipped on car, faked cellular station and cloud servers that authentication have a problem. IVI security should be designed to have less dependency on these modules.

不正アクセスに対する防衛策としては不必要にサービスを開示しないことが基本である。 例えば Vehicle Information Service Specification は Web サーバとして振る舞うが、 IVIの外からのアクセスを想定しないのであれば、受け付けるリクエストをIVI内部からのものに 限定すべきである。 Vehicle Information Service Specification の場合は、Webサーバに適用されるセキュリティー対策を 利用すべきである。アクセストークンの利用などがその一例であり、詳細は同Specのセキュリティー Consideration を参照のこと。上とまとめるか

To prevent unauthorized access, system should expose services only if they are necessary. E.g., Vehicle Information Service Specification defines a local web server but only clients on the same machine need to have access to the server. Therefor the firewall of IVI should reject packets that come from outside. For the VIS implementation, other server side security technologies can be applied as well, The specification describes details.

フィルタを通過し、不正なコードが内部に混入した場合に備え、IVIは下記の機能を持つことを検討すべきである。

In case that a malicious code comes into inside of IVI by passing those filters and executed, IVI should have a functionality that detects abnormal behaviors of application and terminates it.

データの完全性 Data Integrity

車から得られる情報は、例えば保険の参考にするなど金銭的な価値を生む可能性がある。 そのようなケースでは悪意を持ったコードが外部から混入しなくとも、 ユーザーがデータがデータを偽装しようとするインセンティブが働く。 あるいは、車から得られる情報が道路の混雑状況などの公共目的に利用されるようになった場合、 いたずら目的のデータがアップロードされる可能性もある。

Data integrity is necessary for some kind of services. ADAS works appropriately based on correct data. An insurance company may make better offer for safer drivers. Public traffic information should not broadcast misinformation. There are incentives to falsify data for monetary value or mischief on these services.

こういった偽装行為を行うためにはIVIに自由にアクセスできる必要がある。 スマートフォンの例を参考にすれば、そのような行為を完全に防ぐことは困難であるといえる。

The previous section discussed protection against attack from outside. But data might be tampered by a malicious end user as well. In the domain of smart phones, OEM tries to keep user away from core functionalities of a device. However it is very hard to prevent attack from user entirely.

Vehicle APIsはプラットフォームが提供するデータが偽装されるケースに対し現在のところ、解決策を持っていない。 このような課題は他のWeb規格との整合性を保ちつつ、今後検討されることが望まれる。 アプリケーション・サービスの提供者はこのような状況を考慮したうえで、取得したデータの取り扱いを 検討しなくてはならない。

Vehicle APIs currently have no solution for the case that data from platform is possibly tampered. This issues will be focused in the future by having consistency with other W3C recommendations. Service providers should take this possibility into consideration and decides how to treat obtained data.

APIの可用性 API Availability

通常DOM APIは実装者が開示したものを、開発者が使用する形式が標準的である。 デスクトップ向けのブラウザでは現在時刻やユーザーの入力、 ページのスクロールなどを開発者は自由に利用できる。 この様な無制限のAPI利用は利用者に不便をもたらしたり、プライバシー上の懸念があったりすることなどを理由に GPS情報の取得など一部のAPIはユーザーのパーミッションを設けられている。

For most DOM APIs, implementers provide an API implementation and developers utilize it with no limitation. Hence developers have access to current time, user input events and page scroll without any permission. This unlimited use can cause user inconvenience or privacy risk, so some API, such as Geo-location API, requires user's permissions.

この他、近年のブラウザでは頻発するポップアップ表示などが検知された際に、 ユーザーに表示を停止するか否か問い合わせることがある。 頻度の高いAPIリクエストには悪意がある場合とプログラム上のバグの両方の可能性があるが、 いずれにせよこれらを検知してユーザーに確認するか、自動的に停止することが望ましい。

Today, some browser detects abnormal call of API, such as alert popup, and asks user whether to stop subsequent requests. Frequent API call is strongly suspected as malicious behavior but there is a small possibility that it is an intentional behavior.

****

For Vehicle APIs, to ask user about each behavior is distant idea. There are more than hundred data points and most users would feel difficulty to answer the question properly. Therefore implementer should consider API limitation on behalf of users.

Set メソッド Set Method

Vehicle Data Specificationは多数のデータポイントを定義し、 Vehicle Information Access APIは各データポイントに対し値を変更するset, 現在値を取得するget, 及び値を継続的に取得するsubscribeメソッドを定義している。

Vehicle Data Specification defines data points and Vehicle Information Access API provides 'set' to modify the data, 'get' to obtain current value and 'subscribe' for continuous report.

幾つかのデータポイントについてはsetがそもそも相応しくない。例えば 燃料種別(FuelType)や車の姿勢(Gyro)などは変更できるものではない。 エンジンスピード(EnglineSpeed)や走行距離(distanceSinceTotal)など 安全上、あるいはメンテナンス上変更すべきでないものも存在する。 これらに対するSetの呼び出しはinvalid_operationとして処理されるべきである。

For some data points, 'set' is meaningless. Fuel type or gyro could not be changed in nature. There is another type of data points that the value should not be modifiable because of safety or maintain purpose. Engine speed and distance-since-total name? are categorized into this type. 'Set' for these data points should be failed with 'invalid_operation' error.

Setインターフェースは空調など、いわゆるHVACへの利用を想定して提供されている。 実装者は安全性を検討した上で、これらへのアクセスをinvalid_operationとすることもできる。

'Set' interfaces is mainly expected to be used for non critical data points such as HVAC system. With having safety consideration, implementer may or may not implement 'set' for HVAC.

isSettablle?
Yes -> isHVAC?
Yes -> isSafe?
Yes -> implement
setメソッドの提供判定 Decision flow to provide set

setをサポートする場合、リソース競合を起こさないよう慎重な設計が求められる。 例えば Vehicle APIを利用するアプリケーションA, Bが同時に動作する場合を考える。 アプリAが温度をあげようとし、アプリBが温度を下げようとすると矛盾が生じる。 また、アプリAが雨を検知し窓とサンルーフを閉じようとした場合に、 アプリBが窓の操作をロックしていると、一貫性のある動作を提供できなくなる。

'Set' implementation needs resource lock mechanism not to cause race conditions. Imagine that two applications A and B work at a time, and app A tries to heat up a room while B tries to cool down. Or imagine, application A senses rain and tries to close window and sunroof. Application A should be given both of control or none of them. Otherwise the consequent result will be unexpected.

アクセスコントロールのベストプラクティス Best Practice for Access Control

WebAPIの利用はオリジン単位で管理され、ユーザーの意思に基づき許諾されてきた。 API実装者はその考え方にしたがって、Vehicle APIsの利用に際してユーザーに何らかの選択肢を与えるべきである。

To have access with some kind of API, each [[!ORIGIN]] need permission which is granted by end user. Implementer should keep this manner for Vehicle APIs as well and provide option that end-user can present their preference.

Vehicle APIは詳細なインターフェースを提供するため、 実装者の視点で開示が望ましくないものも含まれる。 そのようなデータポイントについては、APIの定義にそって提供を行わないこともできる。 更に進んで、ユーザーを保護するという観点から、 特定の組織や、許諾を与えたコンテンツにのみAPIの利用を 認めたい場合が考えられる。そのためのいくつかの選択肢を示す。

Some of data points defined by Vehicle Data Specification might not be preferable to be public from the perspective of implementers. Specification allows implementer not to expose these data points. Also, considering user's benefit, an implementer would like to expose some of data points only to certain 3rd parties or authorized contents. Here is best practices to realize such access control.

  1. runtimeは実行中のWebContentsのオリジンを知ることができる。Vehicle APIsにアクセスが試みられた際、内部に持つホワイトリスト と突合し、予め認められたオリジンにのみAPIの利用を許可することができる。
  2. Web runtime is able to recognize the origin of web contents. It could allow the origin to access the API only if the origin is listed in a given white list.
  3. LocalにProxyサーバーを設けて外部との通信を経由させ、 問題があると判断されたVehicle APIsの呼び出しをサニタイズすることができる。
  4. IVI could have a web proxy for code sanitization. This proxy could also remove certain call of APIs.
  5. APIがポリフィルとして実装され、 それがローカルのWebサーバと通信する場合、そのWebサーバは [[!OAuth]] で利用されるHTTPヘッダを使ってリクエストをフィルタすることができる。
  6. If the API is implemented as a polyfill of requests for a local web server, the web server could filter requests by [[!OAuth]] or [[!CORS]] framework.
  7. IVIがネイティブアプリケーションをサポートするのであれば Native OSのパーミッションモデル、 Native OSでのマーケットシステムを利用することにより、 APIの利用を制限することができる。
  8. If IVI supports native application, permission model of native OS and a market system for the OS could be utilized to reject suspicious applications. (The native operating system should have a permission to have access with vehicle information)

データーに対するユーザーの権利 User's right for their data

Vehicle APIsから取得できる情報は、ドラーバーや車の所有者と容易に関連付けることができ、 そのため"個人情報"に当たると考えられる。それらの情報はプライバシー保護の対象として 扱われるべきであるが、その方法は個人や、その時の状況、その地方の条例によって変わる。

Vehicle data and its location data are considered as "personal data" because a driver or the owner of a vehicle is easily identifiable by correlating with information from other sources. Therefore, these data should be treated as object information for privacy protection. However, the way of privacy protection may differ by individual, by situation, and by local regulation.

サービス提供者は、Vehicle APIsによって得た情報をIVIの外へ送出しようとする場合、 ユーザーのプライバシーを保護しなくてはならない。 具体的には下記の項目について、ユーザーの希望に沿った運用を行わなくてはならない。

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.

ユーザエージェントは、あるサイトから得られたアプリケーションが Vehicle Access Information API***で 車両情報を要求した場合、ユーザーに許諾を求めるべきである。 この許諾結果は保存してもよいが、ユーザーが希望するときには 不許諾に変更するユーザーインターフェースを 持たなくてはならない。

User agent should ask user's permission when an application tries to use Information Access API. The answer could be stored for future API use by the same origin but user agent should provide UI to change the preference.

DNTとその例外 DNT and its Exception

[[!DNT]] はWeb Applicationに対し自己のトラッキングを行わないように要求するための HTTP ヘッダについての勧告であり、広くサポートされている。 車両では交通事故等、生命・財産の危機に瀕することがあり、 その場合は一時的にDNT機能をOFFにすることを検討すべきである。

The Do Not Track ([[!DNT]]) is the proposed HTTP header field that requests that a web application disables 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 of an individual, temporal deactivation of DNT function may be required.

DNTを含め、緊急時におけるプライバシーの保護の例外は、暗黙裡に認められるものではない。 タスクフォースに提供されたアンケート結果からは、たとえ緊急時であっても 自己のプライバシー情報の開示したくないとする意見が一定数いることがわかっている。 サービス提供者は緊急時のデーターの取り扱いについて明示的にユーザーの許諾を得ておくべきである。

Including DNT, exceptions for privacy protection is not implicitly allowed. A questionnaire performed by a contributer of task force shows that there are non-negligible number of people do not want to provide their privacy information even if they are facing an emergent situation. Service provider should have explicit consent for use of private data in advance.

複数の運転者と利用者 Multi Drivers/Users

一台の車には複数の運転者が想定される。それらの運転手は家族であるかもしれないし、職務上の同僚かもしれない。 IVIは、個人向けに設定される情報がある場合には、それら複数の運転者それぞれのプライバシーが守られるよう配慮すべきである。 個人毎に切り替えられるべき情報の例を以下に示す。

A driver would have number of cars and a car would have multi number of drivers. For the latter case, the drivers could be one's family or could be one's collogues. IVI, therefore, should keep their personal data and preference in secret not to be seen from other drivers Personal information includes followings:

  1. 訪れた場所、通過した道路、同乗者の数などの走行に関する情報。 Trip information such as places visited, roads taken, number of passengers
  2. フォームに入力したパスワード、索語等のデータ Password or serched word inputted on forms
  3. クレジットカード等の金銭的なデータ Payment data such as credit card number
  4. 閲覧履歴 Visited site information
  5. Cookie, IndexDBなどのサイトデータ Site data, such as Cookies, Indexed DB

上記を実現するためにはIVIがユーザー認証とログイン処理を行う必要がある。 OSレベルで対応することが自然であるが、Webランタイムが対応しても差し支えない。

To use different profiles for different users, IVI has to implement user authentication and login. It is natural that operating system provides this functionality but web runtime also could be the provider. In any implementation, this profile change should be transparent from applications.

一方でサービス提供者は、一台の端末を複数のユーザーが共有することを想定するべきである。 ユーザーの識別にはアカウント・パスワードが用いられてきたが、IVIのUIとしては好ましくない。 [[!FIDO]] のような方法で安全性と利便性の両立をはかるべきだろう。

On the other hand, service provider should take into consideration that an IVI will be shared with multi user. For the purpose of user authentication, "account and password" have been used but that is not friendly for drivers. [[!FIDO]] allows service providers to realize convenient authentication.

同一のユーザーであっても、利用される状況が異なることが考えられる。 家族のドライビングと職務上の移動ではふさわしいコンテンツが異なる可能性がある。 アプリはこのような、状況変化を想定し、個人の趣味嗜好に基づくコンテンツを提示する場合には 利用者の意図を確認するようなUIを提供すべきである。

User would use a service in deferent situation. Appropriate contents for driving with family would be different from moving with collogues. Service provider should consider this possibility and should be careful to display contents based on one's preference.

ドライバーが車の所有者とは限らないケースがある。例えば会社が所有する車であったり、レンタカーとして提供される場合が考えられる。 このようなケースではIVIの管理者権限は所有者に与えられ、運転者が操作できるべきではない。 所有者にのみ認められるべき権限の例を以下に示す。

A driver might be different from the car owner. The car could be owned by a company or could be shared with friends. In these case administrative operation should be permitted to the owner and drivers should be kept away from the operation. Here is faculties which should be allowed only for owners.

  1. ユーザーの追加と削除 Adding user, deleting user
  2. アプリケーションの追加と削除 Adding application, deleting application

原則としてドライバーのプライバシーに関わる情報は、所有者であっても許可無く開示されるべきではない。 ユーザーの利便性を考慮して開示を行う場合には、IVIはドライバーが情報を入力する際にその旨を通告すべきである。

In principle, even the owner should not be able to see other driver's personal data without their consent. If an IVI needs to exposes these data for the purpose of user's benefit, the IVI should ask user in advance.

関連する勧告候補 Related Work

Usecaseにあり、5章にない幾つかの課題は Vehicle APIsの新しいバージョンあるいは、下記のグループ等とのより一般的なSpecによって規定される可能性がある。

Unsolved issues that is listed at section 2 and not treated at section 5 would be focused by next Vehicle APIs, or by other new specification under collaborative work with following groups.