本サイトは、快適にご利用いただくためにクッキー（Cookie）を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
現在、世界各国で自動運転車の開発が盛んに行われています。
自動運転車は、人間が運転操作を行わなくとも自動で走行できる自動車と定義されており、カメラやレーダー、GPSなどのセンサー類や、高精細の地図情報を配信するクラウドサービス、また、他車両と通信を行うネットワークサービスなどを組み合わせることで、自律的な走行を実現しています。また、より完全な自律走行を実現するために、道路標識や歩行者などの認識や、運転操作の意思決定をディープラーニング・モデルで行う自動運転車も開発が進んでいます。
このように、自動運転車には「繋がる」「自律走行」という、従来の自動車にはなかった新たな性質が加わっています。しかし、これと同時に、センサー類やクラウドサービス連携に対する攻撃や、ディープラーニング・モデルに対する攻撃といった、従来の自動車にはなかった新たな攻撃経路も生まれています。
そこで、本連載は「自動運転車セキュリティ入門」と題し、主にディープラーニング・モデルを採用した自動運転車に対する攻撃手法と防御手法を幅広く・分かり易く取り上げていきます。本連載を読むことで、自動運転車セキュリティの全体像が俯瞰できるようになるでしょう。
なお、本連載は、2021年4月10日に公開された論文「Deep Learning-Based Autonomous Driving Systems: A Survey of Attacks and Defenses」をベースにしています。ただし、本連載では単に論文を和訳するのではなく、内容を分かりやすく噛み砕き、また、弊社の知見／見解を盛り込んだ内容としています。また、論文中で引用される文献はほとんどが英語ですが、本連載では可能な限り日本語の文献を引用するようにしています。
本連載が、皆さまの自動運転車セキュリティの理解の一助になれば幸いです。
連載一覧
「自動運転車セキュリティ入門」は全５回のブログで構成されています。
今後、以下のタイトルで順次掲載していく予定です。
- 第１回：自動運転車・セキュリティの概要（公開済み）
- 第２回：センサー・カメラに対する物理的攻撃（公開済み）
- 第３回：クラウド連携に対するサイバー攻撃 (今回)
- 第４回：意思決定モデルに対する敵対的攻撃 - 回避攻撃 -
- 第５回：意思決定モデルに対する敵対的攻撃 - 汚染攻撃 -
第２回までは公開済みです。
ご興味がございましたら読んでいただけると幸いです。
はじめに
本ブログは第3回「クラウド連携に対するサイバー攻撃」です。
本ブログでは、自動運転車に関連するクラウドサービスに対する攻撃手法と防御手法を解説していきます。
それでは、本編に入っていきましょう。
自動運転車に関連するクラウドサービスとは
さて、自動運転車で使用されるクラウドサービスとは何を指しているのでしょうか。
自動運転車のプロセスとアーキテクチャを表した以下の図では、HD Map/V2X（Vehicle to Everything）/OTA（Over-the-Air）をクラウドサービスとして定義しています。
自動運転車のアーキテクチャ（再掲）
（出典：Deep Learning-Based Autonomous Driving Systems）
これらのクラウドサービスは、自動運転車に必要なデータを保管・配信するために使用され、Sensing layerやPerception layerなど各レイヤーで必要なデータを提供するものです。加えて、Sensing layerやPerception layerがクラウドサービスと接続するネットワークもクラウドサービスとして取り扱います。
Sensing layerでは、LiDARやその他のセンサーを使用し、HD Mapを構築するために必要なデータをV2X経由でクラウドサービスに送信します。また、カメラなど他の自動運転車のリアルタイムの生データや画像データなども、V2X経由でクラウドにアップロードし、HD Mapを最新の状態にするために利用されます。
Perception layerでは、使用されるディープラーニング・モデルを、まずシミュレーション環境であるクラウド上で学習します。これらのモデルを検証した後、OTAアップデートを提供し、自動運転車のソフトウェアとディープラーニング・モデルをリモートからアップグレードします。
HD Map（High-Definition Map）
HD Mapは高精細な3次元地図データのことで、自動運転車を提供する企業がLiDARやその他のセンサーを使用し、道路の車線や標識、障害物（中央分離帯など）などの重要な情報を収集して作成するデジタル地図です。
また、他の自動運転車のリアルタイムの生データや画像データなどは、V2X経由でクラウド上にアップロードされ、HD Mapを最新の状態に保つために活用されます。これにより、HD Mapは同じ道路を走行する周囲の自動車など、より関連性の高いリアルタイムの情報を自動運転車に提供することができます。自動運転車はこれらのデータを利用して周辺環境をより正確に把握し、走行経路を計画したりすることができるようになります。
日本でもダイナミック基盤株式会社が2023年度には主要国道を加えた約8万kmに、2024年度には主要地方道を含めた約13万kmにまでカバー範囲を広げる計画の発表を行いました。
HD Mapの一例
（出典：Baidu Apollo HD Map, UN-GGIM）
V2X（Vehicle to Everything / Vehicle to X）
自動車からクラウドなどの外部システムへ接続することを意味しており、接続先によって呼称が変わってきます。V2Xはその総称です。例えば自動車同士であればV2V（Vehicle to Vehicle）、自動車と歩行者であればV2P（Vehicle to People）、自動車とインフラであればV2I（Vehicle to Infrastructure）、自動車とネットワークであればV2N（Vehicle to Network）といった形で呼ばれます。自動運転車では自動車単体では感知できない情報もあるため、周辺の情報と組み合わせた情報の提供/活用、安全性やドライバーの快適性などに利用されます。
V2V（Vehicle to Vehicle）
自動車と自動車間で直接通信することで、車車間通信と呼ばれます。例えば、周辺の自動車と位置情報や速度情報といった情報を送受信することで、出会い頭の事故を未然に警告したり、前方の自動車の減速/加速情報を送受信することでスムーズなクルーズコントロールを提供したりすることが可能となります。
例えば、トヨタではITS Connectと呼ばれる機能を提供しており、対応車種では、先行車との通信により、先行車の加速・減速情報をリアルタイムで取得していち早く自動車を操作、車間距離や速度の変化を抑える「通信利用型レーダークルーズコントロール」や緊急走行中の緊急車両が近づくと、警報を鳴らしながらおおよその方向、距離、進行方向を表示する「緊急車両存在通知」、交差点などで停車している際、左右から近づいてくる自動車を感知し、ドライバーが発車しようとした場合に警報を鳴らし注意喚起を行う「出会い頭注意喚起」などの機能が提供されています。
V2V通信の利用例
（出典：トヨタ トヨタの最新技術 | 安全技術 | ITS Connect | トヨタ自動車WEBサイト (toyota.jp)）
V2P（Vehicle to People）
自動車と歩行者間の通信のことで、歩行者の保有しているスマートフォンと通信することで歩行者の安全確保などを行うことを目的としています。例えば、車載のセンサーだけでは、物陰から急に飛び出す人を検知し対応することは困難であるため、歩行者の保有するスマートフォンの通信機能を使って、GPSによる位置情報や速度、進行情報などの情報を取得して組み合わせることで、事故などを回避できる可能性があります。
例えば、ホンダは次のようなV2Pのシナリオを紹介しています。
歩行者が道路を横断する際、車の位置と速度、歩行者の位置と速度からドライバーにはブレーキの警告を、歩行者のスマートフォンには周囲に気をつけるよう警告を表示します。
また、物陰からの急な飛び出しや駐車場からのバックでの出庫時にも同様の警告を行い、ドライバー、歩行者ともに事故を回避する行動を選択できるようになります。
V2P通信の利用例
（出典：Honda Demonstrates Advanced V2P and V2M Safety Technologies）
ホンダやゼネラルモーターズなどは本分野に関する研究を進めています。歩行者の保有するスマートフォンと通信するためには、スマートフォン側での対応も必要となりますし、プライバシーの問題をどうやって考えていくかなどの議論が必要となる分野です。
V2I（Vehicle to Infrastructure）
自動車と道路インフラ間の通信のことで、路車間通信と呼ばれます。信号機や車線、道路標識などの路側機と通信を行うことで、路側機が周囲の情報を把握し、対象の車に情報を送信することで、注意喚起などを行うことが可能となります。他のV2Xと同様に自動車と路側機でも対応が必要で、各地で実証実験が盛んに行われています。
また、普及済みのV2IとしてはETCがあります。ETC 2.0では高速インターチェンジの出入り情報だけではなく、経路情報や加速度データ、車載器IDなどのデータを収集し、集められたデータは道路施策に役立てられています。
V2Iの利用例
（出典：ETC2.0の機能）
V2Iの利用例
（出典：ETC2.0で道路がもっと賢く使える）
V2N（Vehicle to Network）
自動車のネットワーク通信のことです。カーナビや飲食店などのレコメンド機能といったマルチメディア機能や自動車の状態管理、故障の予兆検知、制御用のファームウェアのアップデートなどの車両管理など利用用途は多岐にわたります。
2021 年 4 月 27 日には、より安全で快適なコネクティッドサービスの早期提供に向け、通信システムの共通化を推進するとして、スズキ、SUBARU、ダイハツ、トヨタ、マツダが次世代車載通信機の技術仕様の共同開発に合意したニュースをリリースしました。
V2Nの利用例
（出典：コネクティッドサービス運用のイメージ図）
OTA（Over-The-Air）
OTAは無線通信を経由してデータを送受信することで、ソフトウェアやファームウェアの更新やディープラーニング・モデルのアップデートなどで利用されています。特に、自動運転車では複数のディープラーニング・モデルが採用されており、これらの学習はクラウド上で行われ、検証されるとOTA経由でアップデートを行い、最新のモデルにアップグレードされます。また、コネクテッドカーもこのOTA技術を利用しており、自動車の電子制御ユニットであるEUCのアップデートなどにも活用されています。
攻撃手法
ここからは、攻撃手法を見ていきましょう。
自動車基準調和世界フォーラム（WP29)では脅威に関連する脆弱性や攻撃方法のリストをまとめて公開しています。この表は世界各国の自動車業界関係者およびセキュリティ専門家が協議し、作成した、車両を取り巻く環境を考慮した脅威の一覧です。
以下に表を示します。
UN Regulation No. 155 - Cyber security and cyber security management system Annex 5 List of threats and corresponding mitigations
Part A. Vulnerability or attack method related to the threats
|
脆弱性/脅威の大項目と中項目の説明 |
脆弱性や攻撃方法の例 |
|||
|
4.3.1 自動車に繋がるバックエンドサーバに関する脅威 |
1 |
自動車への攻撃やデータ抜き取り |
1.1 |
スタッフによる権限の濫用（インサイダー攻撃） |
|
1.2 |
サーバに対する不正なインターネットアクセス（バックドアやパッチの当たってないシステムの脆弱性、SQLインジェクションなど） |
|||
|
1.3 |
サーバに対する物理的なアクセス（USBやサーバに繋がるメディアなど） |
|||
|
2 |
バックエンドサーバの停止により、自動車の運転に影響を与えること |
2.1 |
バックエンドのサーバへの攻撃によって、自動車との連携や提供サービスができなくなるなどバックエンドへのサーバへの攻撃による機能停止 |
|
|
3 |
自動車関連のデータの紛失や漏洩（データの侵害） |
3.1 |
スタッフによる権限の濫用（インサイダー攻撃） |
|
|
3.2 |
クラウド上での情報消失。第三者のクラウドサービスが保管しているデータが攻撃や事故によって消失する可能性。 |
|||
|
3.3 |
サーバに対する不正なインターネットアクセス（バックドアやパッチの当たってないシステムの脆弱性、SQLインジェクションなど） |
|||
|
3.4 |
サーバに対する物理的なアクセス（USBやサーバに繋がるメディアなど） |
|||
|
3.5 |
意図しないデータ共有による情報侵害（管理者のミスなど） |
|||
|
4.3.2 通信経路に関する脅威 |
4 |
自動車が受信するメッセージやデータの偽装 |
4.1 |
なりすましによるメッセージの偽装（隊列走行中の802.11p、GNSSメッセージなど） |
|
4.2 |
シビル攻撃（多数の自動車が走行している可能ようになりすます） |
|||
|
5 |
自動車に搭載されているコード/データに対する不正な操作、削除、その他の修正を行うために使用される通信チャネル |
5.1 |
通信チャンネルへのコードインジェクション。改ざんされたソフトウェアのバイナリをインジェクションされる可能性 |
|
|
5.2 |
自動車が持つデータやコードを操作できる通信チャンネル |
|||
|
5.3 |
自動車が持つデータやコードの書き換えができる通信チャンネル |
|||
|
5.4 |
自動車が持つデータやコードの削除ができる通信チャンネル |
|||
|
5.5 |
自動車が持つデータやコードの導入ができる通信チャンネル（データコードの書き込み） |
|||
|
6 |
信頼されていない/信用できないメッセージの受け入れやセッションハイジャック/リプレイ攻撃に脆弱な通信チャンネル |
6.1 |
信頼されていない/信用できないソースからの情報受け入れ |
|
|
6.2 |
中間者攻撃/セッションハイジャック |
|||
|
6.3 |
リプレイ攻撃。通信ゲートウェイに対する攻撃では、ECUのソフトウェアやゲートウェイのファームウェアをダウングレードさせることが可能 |
|||
|
7 |
通信の盗聴や、機密ファイル/フォルダへの不正アクセスなどによる情報開示 |
7.1 |
情報の傍受/妨害電波/通信の監視 |
|
|
7.2 |
ファイルやデータへの不正アクセス |
|||
|
8 |
自動車の機能を停止させる通信チャンネルを利用したサービス妨害攻撃（DoS） |
8.1 |
大量のゴミデータを自動車の情報システムに送信され、正常なサービス提供ができなくなる |
|
|
8.2 |
ブラックホール攻撃。自動車間の通信を妨害するため自動車間のメッセージを遮断 |
|||
|
9 |
権限を持たないユーザが自動車システムにアクセスする権限を得ること |
9.1 |
権限の持たないユーザによるアクセス。特権ユーザ(root)によるアクセスなど |
|
|
10 |
通信メディアに組み込まれたウィルスが自動車システムに感染する |
10.1 |
通信メディに組み込まれたウィルスが自動車システムに感染する |
|
|
11 |
V2Xや診断メッセージなど自動車の受信するメッセージや自動車内で送信されるメッセージに悪意のあるコンテンツが含まれていた場合 |
11.1 |
悪意のある内部（CANなど）メッセージ |
|
|
11.2 |
インフラから自動車(V2I)や自動車から自動車(V2V)のような悪意のあるV2Xメッセージ（CAM、DENMなど） |
|||
|
11.3 |
悪意のある診断メッセージ |
|||
|
11.4 |
OEMやコンポーネント/システム/機能などからの悪意のあるメッセージ |
|||
|
4.3.3アップデート方法に関する脅威 |
12 |
更新手順の悪用や侵害 |
12.1 |
OTAアップデート手順に対するハッキング。システムアップデートプログラムやファームウェアの改ざんも含む |
|
12.2 |
ローカル/物理的なソフトウェアアップデート手順に対するハッキング。システムアップデートプログラムやファームウェアの改ざんも含む |
|||
|
12.3 |
アップデート処理は正常だが、ソフトウェア自体を操作（破損している）されている |
|||
|
12.4 |
無効なアップデートを行うために必要なソフトウェアプロバイダの暗号化キーの侵害 |
|||
|
13 |
正常なアップデートの阻害 |
13.1 |
ネットワークやアップデートサーバへのサービス妨害攻撃（DoS）により、重要なソフトウェアのアップデートや特定機能の利用を阻止する |
|
|
4.3.4意図しない人の行動がサーバ攻撃を助長する |
15 |
一般ユーザが無意識のうちにサイバー攻撃に巻き込まれる |
15.1 |
無実の被害者（オーナーやオペレータ、メンテナスエンジニアなど）が騙され、意図せずマルウェアを実行したり攻撃を可能にしてしまう |
|
15.2 |
事前に定義されているセキュリティ手順が守られていない |
|||
|
4.3.5 自動車の接続と外部接続に関する脅威 |
16 |
遠隔操作を可能にするシステム、テレマティクス、短距離無線通信を使用するシステムなど自動車機能の接続を操作することで、サイバー攻撃が可能になる |
16.1 |
リモートキー、イモビライザー、充電パイルのようなシステムを遠隔で操作するための機能の操作 |
|
16.2 |
繊細な商品の温度計の操作、貨物ドアの遠隔操作による解錠など自動車テレマティクスの操作 |
|||
|
16.3 |
短距離無線システムやセンサーとの干渉 |
|||
|
17 |
エンターテインメント・アプリケーションなど、ホストされているサードパーティのソフトウェアへの攻撃 |
17.1 |
破損したアプリケーションやソフトウェアのセキュリティが低いアプリケーションが自動車システムへの攻撃方法として利用される |
|
|
18 |
USBポートやOBDポートなどの外部インターフェースに接続されたデバイスへの攻撃 |
18.1 |
USBなどの外部インターフェースがコードインジェクションなどの攻撃のポイントになる |
|
|
18.2 |
自動車システムに接続されたウィルスに感染したメディア |
|||
|
18.3 |
自動車パラメータの操作（直接的または間接的）など、攻撃を容易にするための診断アクセス（OBDポートへのドングルなど） |
|||
|
4.3.6 自動車データ/コードへの脅威 |
19 |
自動車データ/コードの抽出 |
19.1 |
自動車システムから著作権や所有権のあるソフトウェアを抜き取ること（製品の違法コピー） |
|
19.2 |
個人ID、支払い口座情報、アドレス帳情報、位置情報、自動車の電子IDなど、所有者のプライバシー情報への不正アクセス |
|||
|
19.3 |
暗証番号の抽出 |
|||
|
20 |
自動車データ/コードの操作 |
20.1 |
自動車の電子IDの違法/不正な変更 |
|
|
20.2 |
ユーザが料金システムとの通信時に別のIDを表示した場合のようなID詐称 |
|||
|
20.3 |
ODRトラッカーのデータや走行回数などのメッセージのハッキング/改ざん/ブロックといった、モニタリングシステムを回避する行為 |
|||
|
20.4 |
自動車の走行データ（走行距離、走行速度、走行方向など）を改ざんするためのデータ操作 |
|||
|
20.5 |
システムの診断データの不正な変更 |
|||
|
21 |
自動車データ/コードの削除 |
21.1 |
システムのイベントログの不正な削除・操作 |
|
|
22 |
マルウェアの導入 |
22.1 |
悪意のあるソフトウェアを導入、または悪意のあるソフトウェアの動作 |
|
|
23 |
新しいソフトウェアの導入や既存のソフトウェアの上書き |
23.1 |
自動車制御システムや情報システムのソフトウェアの製作 |
|
|
24 |
システムやオペレーションの中断 |
24.1 |
CANバスのフラッディングによる内部ネットワークへの侵入や、大量のメッセージによるECUの故障を誘発させるなどのサービス妨害攻撃（DoS） |
|
|
25 |
自動車のパラメータを操作する |
25.1 |
ブレーキデータやエアバッグの展開閾値など、自動車の主要機能の設定パラメータを不正にアクセスして改ざんする行為 |
|
|
25.2 |
充電電圧、充電電力、バッテリー温度などの充電パラメータを不正にアクセスして改ざんする行為 |
|||
|
4.3.7 十分に保護または強化されていない場合に悪用される可能性のある潜在的な脆弱性 |
26 |
暗号化技術が危険にさらされているか、十分に適用されていない可能性 |
26.1 |
有効期限が長く短い暗号化キーにより、暗号化が破られる可能性 |
|
26.2 |
機密性の高いシステムを保護するための暗号化アルゴリズムの不十分な使用 |
|||
|
26.3 |
すでにまたは間もなく廃止される暗号化アルゴリズムの利用 |
|||
|
27 |
部品または消耗品から自動車が攻撃される可能性 |
27.1 |
攻撃可能な設計、または攻撃を阻止するための設計基準を満たしていないハードウェアまたはソフトウェア |
|
|
28 |
ソフトウェアまたはハードウェアの脆弱性 |
28.1 |
ソフトウェアのバグ。 ソフトウェアのバグの存在が、潜在的な悪用可能な脆弱性の基礎となる可能性。これは、既知の不良コード/バグが存在しないことを確認し、未知の不良コード/バグが存在するリスクを軽減するためのソフトウェアがテストされていない場合に特に当てはまる。 |
|
|
28.2 |
ECUへのアクセスや、攻撃者がより高い特権を取得するために開発関連機能（デバッグポート、JTAGポート、マイクロプロセッサ、開発証明書、開発者パスワードなど）が利用される |
|||
|
29 |
脆弱性を含むネットワーク設計 |
29.1 |
余分なポートが開いている |
|
|
29.2 |
ネットワークの分離を回避して制御権を得る。 具体的な例として、保護されていないゲートウェイまたはアクセスポイント（トラックトレーラー用のゲートウェイなど）を使用し、他のネットワークセグメントにアクセス。任意のCANバスメッセージ送信により悪意のある行為を実行する事などがあげられる |
|||
|
31 |
意図しないデータ転送が発生する可能性 |
31.1 |
自動車の所有者が変わった際に、個人情報が漏洩する可能性（例えば、中古車として売却されたり、新しい利用者にユーザが変わった場合） |
|
|
32 |
32.1 |
電子ハードウェアの操作（例： 中間者攻撃を可能にするために車両に追加された未承認のハードウェア。 許可されたハードウェア（センサーなど）から無許可のハードウェアへの交換。 センサーによって収集された情報の操作（例：磁石を利用しギアボックスに接続されているホールセンサーを改ざんするなど） |
||
このように、各脅威（バックエンドのサーバに関する脅威、通信経路に関する脅威、アップデートプロセスに関わる脅威、外部接続に関わる脅威、潜在的な脆弱性に対する脅威など）に紐づく脆弱性や攻撃手法（インサイダーによる不正行為や通信の遮断・傍受、シビル攻撃やリプレイ攻撃、ファームウェアの改ざんやマルウェアの注入など）が多く存在していることが分かっていただけたかと思います。自動運転車の場合、安全な走行を行うためには自身の車両位置を特定できることが必要となるため、GPSによる位置情報やHD Mapによる地図情報が特に重要です。また、自動運転車やコネクテッドカーでは、遠隔からの攻撃だけではなく、近接からの攻撃も想定する必要があります。実際に実証された攻撃手法や研究事例を以下にいくつか紹介します。
シビル攻撃（Sybil attack）
クラウドサービス（ナビシステム）に対する攻撃の例として、シビル攻撃が挙げられています。この攻撃はクラウドサービス自体に対する攻撃で遠隔から攻撃を行うことが可能です。コンピュータセキュリティにおけるシビル攻撃は、偽のIDを複数生成し、複数の偽のIDからリクエストを送信することで、結果に偏りを生じさせ、システム全体の計算結果（例えばレピュテーション）に影響を与える攻撃です。
Meital Ben Sinai氏らの論文では、著名なソーシャル・ナビゲーション・アプリケーションであるWAZEに対してシビル攻撃を行い、交通渋滞の偽装や経路選択に大きな影響を与えることを実証しました。
- Exploiting Social Navigation(arxiv.org)
当時のWAZEは端末にアプリケーションをインストールして起動するだけで、周囲のユーザや交通情報を閲覧したり、さまざまな道路障害を報告して近くのユーザに影響を与えたり、経路や交通情報に影響を与えたりすることができる（利用にあたって登録やユーザ検証が行われていない）状態であったため、エミュレータでWAZEを起動し、「運転開始」ボタンをクリックするスクリプトを実行するだけで、「Bot Driver(偽ドライバー)」を自動生成することが可能な状態でした。WAZEのアプリケーションの説明で、「高いレベルほどレポートがより大きな影響力を持つようになる（つまり、ユーザは運転や障害物の報告などのフィードバックを行うことでユーザの評価があがり、報告の信頼性が高いと判断され影響力が強くなる）」という仕様を逆手に取って、Bot Driverに訓練（正しいフィードバックを複数実施する）を施しています。訓練後、送信するメッセージやGPS情報を意図的に改ざんする攻撃を行います。
調査の結果、WAZEではルートにおける現在の平均速度が以前に取得している速度情報に比べてかなり低い場合に渋滞と判断するものと判明したため、実験では、最初に以前に取得している速度情報より早い速度であろう時速70キロからスタートし、時速15キロ、8キロ、2キロと徐々に速度を落としてエリア内を移動させることで、渋滞のシミュレーションを成功させています。
攻撃によって発生した渋滞の様子（赤の太線が渋滞を示している）
（出典：Exploiting Social Navigation）
攻撃前に示していた最短経路(a)が攻撃による渋滞により最短経路が変更された図(b)
（出典：Exploiting Social Navigation）
OTA経由の攻撃
クラウドサービス（ナビシステム）に対する攻撃の例として、OTAを狙った攻撃も挙げられています。ファームウェアの更新手順などの不備やOTA経由でのアクセスを通じて攻撃を行います。
＜OBD-IIポートを経由した攻撃＞
Ian Foster氏らは遠隔の攻撃者がOBD-IIポートを経由し任意の遠隔操作が可能になることを実証しました。この攻撃はクラウドサービスと接続するネットワークを介した攻撃で遠隔から攻撃を行うことが可能です。
OBD（on-board diagnosis）は自動車に取り付けられた自己診断機能で、故障箇所や故障内容の解析、車速やGPS、燃費などの情報も読み取ることが可能です。このOBDポートを介して接続されるTCU（telematics control unit）の検証を行い、ローカルからの攻撃、リモートからの攻撃の実証をしました。
ローカルからの攻撃では、WebサービスやTelnetサービス、SSHサービスが稼働していることを確認し、Webインターフェースにアクセスすることで機器のパラメータやステータスの確認のほか、SMSメッセージを送信するインターフェースが用意されていることを確認しました。また、NAND型フラッシュメモリからデータを抽出した結果、SSHに接続するためのシステム管理者の秘密鍵を特定し、システム管理者のシェルを取得することに成功しています。また、この秘密鍵は機器固有ではなく共通のもので、同じ秘密鍵で他のTCUにログインができる状態でした。
リモートからの攻撃では、WebサービスやTelnetサービス、SSHサービスがインターネット接続可能なIPアドレスにバインドされており、IPアドレスがわかっていれば接続ができる状態でした。ただし、一般的にはキャリアグレードNATによって直接アクセスすることができない状態でしたが、本調査の結果、1500台ほどアクセスが可能な機器が確認されました。
別のアプローチとして、SMSベースの攻撃を提案しています。ローカルの攻撃でも確認できた、SMSメッセージを送信するインターフェースでは、SMSを介して、機器のパラメータやステータスの確認、GPSの位置などのセンサー・ステータス情報の取得やリモートアップデートの開始の指示が行えます。サーバへのアクセスには、認証が必要ですが、全デバイスで同じ秘密鍵と公開鍵のペアであること、アップデートのバイナリは暗号化が施されておらず、任意のコードに入れ替えることが可能なこと、任意のアップデートサーバを指定できることから、不正なアップデートサーバに対してアップデート指示が出せる状態でした。
SMSを利用したリモートからの攻撃シーケンス
（出典：Fast and Vulnerable: A Story of Telematic Failures）
＜WiFiを経由した攻撃＞
Sen Nie氏らはWi-Fi接続をきっかけに複数の脆弱性を組み合わせてシステム管理者権限を取得した後、Tesla Model Sを遠隔操作することに成功しています。この攻撃はクラウドサービスと接続するネットワークを介した攻撃で近接から攻撃を行うことが可能です。
Teslaの自動車はTeslaが運営するアクセスポイントに自動的に接続する仕様になっており、そのSSIDとパスワードはすべて共通かつ簡単なパスワードでした。そのため、攻撃者は偽のアクセスポイントを設置し、被害者をアクセスポイントに誘導できる状態となっていました。また、Tesla の自動車が搭載しているWebブラウザ（QtCarBrowser）には古いバージョンのWebKitが使用されており、任意のコードが実行できる脆弱性が存在していました。この脆弱性によりブラウザ権限のユーザを取得することが可能でした。その後、Linuxカーネルの権限昇格の脆弱性を使用し、システム管理者のシェルを取得することに成功しています。システム管理者のシェルを取得後は、CANへアクセスするため、OTA経由のファームウェアアップデート機能を利用し、コントローラのファームウェアの書き換えを行いっています。ファームウェアの書き換えを防ぐためのコード署名などの対策は施されていなかったため、攻撃者が指定するファームウェアに書き換えることが可能で、遠隔から自動車を操作することが可能となりました。
遠隔操作を行っている様子
（出典：Car Hacking Research: Remote Attack Tesla Motors by Keen Security Lab）
防御手法
ここからは、クラウドサービスに対する攻撃の防御手法を見ていきましょう。
自動車基準調和世界フォーラム（WP29)では脅威に関連する脆弱性や攻撃方法のリストには対策や攻撃を緩和するためのリストも併せて公開されています。
UN Regulation No. 155 - Cyber security and cyber security management system Annex 5 List of threats and corresponding mitigations
Part B. Mitigations to the threats intended for vehicles
Table B1 Mitigation to the threats which are related to "Vehicle communication channels"
|
脆弱性/脅威の説明 |
緩和策 |
||
|
4.1 |
なりすましによるメッセージの偽装（隊列走行中の802.11p、GNSSメッセージなど） |
M10 |
受信したメッセージの真正性と完全性を検証する |
|
4.2 |
シビル攻撃（多数の自動車が走行している可能ようになりすます） |
M11 |
暗号鍵の保存にセキュリティ管理が行われていること（例：ハードウェアセキュリティモジュールの使用） |
|
5.1 |
通信チャンネルへのコードインジェクション。例えば、改ざんされたソフトウェアのバイナリをインジェクションされる可能性。 |
M10 M6 |
受信したメッセージの真正性と完全性を検証する リスクを最小限に抑えるために、設計によりセキュリティを実装する |
|
5.2 |
自動車が持つデータやコードを操作できる通信チャンネル |
M7
|
システムのデータ/コードを保護するために、アクセス制御技術と設計を適用する
|
|
5.3 |
自動車が持つデータやコードの書き換えができる通信チャンネル |
||
|
5.4 21.1 |
自動車が持つデータやコードの削除ができる通信チャンネル |
||
|
5.5 |
自動車が持つデータやコードの導入ができる通信チャンネル（データコードの書き込み） |
||
|
6.1 |
信頼されていない/信用できないソースからの情報受け入れ |
M10 |
受信したメッセージの真正性と完全性を検証する |
|
6.2 |
中間者攻撃/セッションハイジャック |
M10 |
受信したメッセージの真正性と完全性を検証する |
|
6.3 |
リプレイ攻撃。 例えば、通信ゲートウェイに対する攻撃では、ECUのソフトウェアやゲートウェイのファームウェアをダウングレードさせることが可能。 |
||
|
7.1 |
情報の傍受/妨害電波/通信の監視 |
M12 |
自動車との間で送受信される機密データを保護すること |
|
7.2 |
ファイルやデータへの不正アクセス |
M8 |
システム設計とアクセス制御により、権限のない人が個人データやシステムの重要データにアクセスできないようにします。セキュリティ・コントロールの例は、OWASP に記載されています |
|
8.1 |
大量のゴミデータを自動車の情報システムに送信され、正常なサービス提供ができなくなる。 |
M13 |
サービス妨害攻撃（DoS）を検知し、回復するための対策が講じられていること |
|
8.2 |
ブラックホール攻撃。自動車間の通信を妨害するため自動車間のメッセージを遮断します。 |
M13 |
サービス妨害攻撃（DoS）を検知し、回復するための対策が講じられていること |
|
9.1 |
権限の持たないユーザによるアクセス。特権ユーザ(root)によるアクセスなど。 |
M9 |
不正アクセスを防止・検出するための措置を講じること |
|
10.1 |
通信メディアに組み込まれたウィルスが自動車システムに感染する |
M14 |
組み込み型のウィルス/マルウェアからシステムを保護するための対策を検討する必要がある。 |
|
11.1 |
悪意のある内部メッセージ（CANなど） |
M15 |
悪意のある内部メッセージや活動を検出するための対策を検討する必要がある |
|
11.2 |
インフラから自動車(V2I)や自動車から自動車(V2V)のような悪意のあるV2Xメッセージ（CAM、DENMなど） |
M10 |
受信したメッセージの真正性と完全性を検証する |
|
11.3 |
悪意のある診断メッセージ |
||
|
11.4 |
OEMやコンポーネント/システム/機能などからの悪意のある独自メッセージ |
||
Table B2 Mitigations to the threats which are related to "Update process"
|
12.1 |
OTAアップデート手順に対するハッキング。システムアップデートプログラムやファームウェアの改ざんも含む |
M16 |
安全なソフトウェア更新手順を採用すること |
|
12.2 |
ローカル/物理的なソフトウェアアップデート手順に対するハッキング。システムアップデートプログラムやファームウェアの改ざんも含む |
||
|
12.3 |
アップデート処理は正常だが、ソフトウェア自体が操作（破損している）されている |
||
|
12.4 |
無効なアップデートを行うために必要なソフトウェアプロバイダの暗号化キーの侵害 |
M11 |
暗号鍵の保管にセキュリティ管理を実施すること |
|
13.1 |
ネットワークやアップデートサーバへのサービス妨害攻撃（DoS）により、重要なソフトウェアのアップデートや特定機能の利用を阻止する。 |
M3 |
バックエンドシステムにもセキュリティ・コントロールを適用すること。バックエンドサーバがサービスの提供に不可欠である場合、システム停止時の回復手段があること。セキュリティ・コントロールの例は、OWASP に記載されています。 |
Table B3 Mitigations to the threats which are related to "Unintended human actions facilitating a cyber attack"
|
15.1 |
無実の被害者（オーナーやオペレータ、メンテナスエンジニアなど）が騙され、意図せずマルウェアを実行したり攻撃を可能にしてしまう |
M18 |
最小限のアクセス権限の原則に基づき、ユーザの役割およびアクセス権限を定義し、制御するための方策を実施すること。 |
|
15.2 |
事前に定義されている手順が守られていない |
M19 |
組織は、セキュリティ機能の管理に関連する行動やアクセスの記録を含む、セキュリティ手順が定義され、遵守されることを保証しなければならない |
Table B4 Mitigation to the threats which are related to "external connectivity and connections"
|
16.1 |
リモートキー、イモビライザー、充電パイルのようなシステムを遠隔で操作するための機能の操作 |
M20 |
リモートアクセスが可能なシステムには、セキュリティ管理を適用すること |
|
16.2 |
繊細な商品の温度計の操作、貨物ドアの遠隔操作による解錠など自動車テレマティクスの操作 |
||
|
16.3 |
短距離無線システムやセンサーとの干渉 |
||
|
17.1 |
破損したアプリケーションやソフトウェアのセキュリティが低いアプリケーションが自動車システムへの攻撃方法として利用される |
M21 |
ソフトウェアは、セキュリティ評価を受け、認証され、完全性が保護されていること。車両に搭載されることが意図されている、または予測されるサードパーティ製ソフトウェアのリスクを最小限に抑えるために、セキュリティ管理を行うこと。 |
|
18.1 |
USBなどの外部インターフェースがコードインジェクションなどの攻撃のポイントとなる。 |
M22 |
外部インターフェースにセキュリティ管理を適用すること |
|
18.2 |
自動車システムに接続されたウィルスに感染したメディア |
||
|
18.3 |
自動車パラメータの操作（直接的または間接的）など、攻撃を容易にするための診断アクセス（OBDポートへのドングルなど） |
M22 |
外部インターフェースにセキュリティ管理を適用すること |
Table B5 Mitigations to the threats which are related to "Potential targets of, or motivations for, an attack"
|
19.1 |
自動車システムから著作権や所有権のあるソフトウェアを抜き取ること（製品の違法コピー） |
M7 |
システムのデータ／コードを保護するために、アクセス制御の技術と設計を適用すること。セキュリティ・コントロールの例は OWASP にあります |
|
19.2 |
個人のID、支払い口座情報、アドレス帳情報、位置情報、自動車の電子IDなど、所有者のプライバシー情報への不正アクセス |
M8 |
システム設計とアクセス制御により、権限のない人が個人データやシステムの重要データにアクセスできないようにします。セキュリティ・コントロールの例は OWASP に記載されています |
|
19.3 |
暗証番号の抽出 |
M11 |
暗号鍵を保管するためのセキュリティ管理が実施されていること（例：セキュリティモジュール |
|
20.1 |
自動車の電子IDの違法/不正な変更 |
M7 |
システムのデータ／コードを保護するために、アクセス制御の技術と設計を適用すること。セキュリティ・コントロールの例は OWASP にあります |
|
20.2 |
ユーザが料金システムとの通信時に別のIDを表示した場合のようなID詐称 |
||
|
20.3 |
ODRトラッカーのデータや走行回数などのメッセージのハッキング/改ざん/ブロックといった、モニタリングシステムを回避する行為 |
M7 |
システムのデータ/コードを保護するために、アクセス制御の技術と設計を適用すること。セキュリティ・コントロールの例は OWASP に記載されています。センサーや送信されたデータに対するデータ操作攻撃は、異なる情報源からのデータを相関させることで軽減することができる |
|
20.4 |
自動車の走行データ（走行距離、走行速度、走行方向など）を改ざんするためのデータ操作 |
||
|
20.5 |
システムの診断データの不正な変更 |
||
|
21.1 |
システムのイベントログの不正な削除・操作 |
M7 |
システムのデータ／コードを保護するために、アクセス制御の技術と設計を適用すること。セキュリティ・コントロールの例は、OWASP に記載されています |
|
22.2 |
悪意のあるソフトウェアまたは悪意のあるソフトウェア活動の導入 |
M7 |
システムのデータ／コードを保護するために、アクセス制御の技術と設計を適用すること。セキュリティ・コントロールの例は、OWASP に記載されています |
|
23.1 |
自動車制御システムや情報システムのソフトウェアの製作 |
||
|
24.1 |
CANバスのフラッディングによる内部ネットワークへの侵入や、高頻度のメッセージングによるECUの故障の誘発などのサービス妨害攻撃（DoS） |
M13 |
サービス妨害攻撃（DoS）を検知し、回復するための対策が講じられていること |
|
25.1 |
ブレーキデータやエアバッグの展開閾値など、自動車の主要機能の設定パラメータを不正にアクセスして改ざんする行為 |
M7 |
システムのデータ／コードを保護するために、アクセス制御の技術と設計を適用すること。セキュリティ・コントロールの例は OWASP にあります |
|
25.2 |
充電電圧、充電電力、バッテリー温度などの充電パラメータを不正にアクセスして改ざんする行為 |
Table B6 Mitigations to the threats which are related to "Potential vulnerabilities that could be exploited if not sufficiently protected or hardened"
|
26.1 |
短い暗号化キーと長期間の有効性の組み合わせにより、暗号化が破られる可能性 |
M23 |
ソフトウェアおよびハードウェア開発のためのサイバーセキュリティのベスト・プラクティスに従うこと |
|
26.2 |
機密性の高いシステムを保護するための暗号化アルゴリズムの不十分な使用 |
||
|
26.3 |
すでにまたは間もなく廃止される暗号化アルゴリズムの利用 |
||
|
27.1 |
攻撃可能な設計、または攻撃を阻止するための設計基準を満たしていないハードウェアまたはソフトウェア |
M23 |
ソフトウェアおよびハードウェア開発のためのサイバーセキュリティのベスト・プラクティスに従うこと |
|
28.1 |
ソフトウェアのバグ。 ソフトウェアのバグの存在が、潜在的な悪用可能な脆弱性の基礎となる可能性。 これは、既知の不良コード/バグが存在しないことを確認し、未知の不良コード/バグが存在するリスクを軽減するためのソフトウェアがテストされていない場合に特に当てはまる。 |
M23 |
ソフトウェアおよびハードウェア開発のためのサイバーセキュリティのベスト・プラクティスに従うこと 十分なカバー率のサイバーセキュリティ・テスト |
|
28.2 |
ECUへのアクセスや、攻撃者がより高い特権を取得するために開発関連機能（デバッグポート、JTAGポート、マイクロプロセッサ、開発証明書、開発者パスワードなど）が利用される |
||
|
29.1 |
余分なポートが開いている |
||
|
29.2 |
制御を取得するためのネットワーク分離の回避。 具体的な例として、保護されていないゲートウェイまたはアクセスポイント（トラックトレーラーゲートウェイなど）を使用し、他のネットワークセグメントにアクセス。任意のCANバスメッセージ送信により悪意のある行為を実行する事などがあげられる。 |
M23 |
ソフトウェアおよびハードウェアの開発に関するサイバーセキュリティのベストプラクティスに従うこと。システム設計とシステム統合のためのサイバーセキュリティのベストプラクティスに従うこと。 |
Table B7 Mitigations to the threats which are related to "Data loss / data breach from vehicle"
|
31.1 |
情報漏えい。車がユーザを変更する事により、個人データが漏洩する可能性（例えば、中古車として売却されたり、新しい利用者にユーザが変わった場合） |
M24 |
個人データを保存する際には、データの完全性および機密性を保護するためのベスト・プラクティスに従うものとします。 |
Table B8 Mitigations to the threats which are related to "Physical manipulation of systems to enable an attack"
|
32.1 |
中間者攻撃を可能とするため、自動車に未承認のハードウェアを追加してハードウェアの操作 |
M9 |
不正アクセスを防止・検出するための措置を講じること |
UN Regulation No. 155 - Cyber security and cyber security management system Annex 5 List of threats and corresponding mitigations
Part C. Mitigations to the threats outside of vehicles
Table C1 Mitigations to the threats which are related to "Back-end servers"
|
1.1 & 3.1 |
スタッフによる権限の濫用（インサイダー攻撃） |
M1 |
バックエンドシステムにセキュリティ・コントロールを適用し、インサイダー攻撃のリスクを最小限に抑える |
|
1.2 & 3.3 |
サーバに対する不正なインターネットアクセス（バックドアやパッチの当たってないシステムの脆弱性、SQLインジェクションなど） |
M2 |
不正なアクセスを最小限に抑えるために、バックエンドシステムにセキュリティ・コントロールを適用します。セキュリティ・コントロールの例は OWASP にあります |
|
1.3 & 3.4 |
サーバに対する物理的なアクセス（USBやサーバに繋がるメディアなど） |
M8 |
システム設計とアクセス制御により、権限のない人が個人データやシステムの重要データにアクセスできないようにする |
|
2.1 |
バックエンドのサーバへの攻撃によって、自動車との連携や提供サービスができなくなるなどバックエンドへのサーバへの攻撃による機能停止 |
M3 |
バックエンドシステムにはセキュリティ・コントロールが適用される。バックエンドサーバがサービスの提供に不可欠な場合、システムが停止した場合の回復手段があります。セキュリティ・コントロールの例は OWASP にあります |
|
3.2 |
クラウド上での情報消失。第三者のクラウドサービスが保管しているデータが攻撃や事故によって消失する可能性 |
M4 |
セキュリティ・コントロールは、クラウド・コンピューティングに関連するリスクを最小化するために適用されます。セキュリティ・コントロールの例は、OWASP および NCSC のクラウド・コンピューティング・ガイダンスに記載されています |
|
3.5 |
意図しないデータ共有による情報侵害（管理者のミスなど） |
M5 |
セキュリティ・コントロールは、データの漏洩を防ぐためにバックエンドシステムに適用されます。セキュリティ・コントロールの例は、OWASP に記載されています |
Table C2 Mitigations to the threats which are related to "Unintended human actions"
|
15.1 |
無実の被害者（オーナーやオペレータ、メンテナスエンジニアなど）が騙され、意図せずマルウェアを実行したり攻撃を可能にしてしまう。 |
M18 |
最小限のアクセス権限の原則に基づき、ユーザの役割およびアクセス権限を定義し、制御するための方策を実施すること |
|
15.2 |
事前に定義されている手順が守られていない |
M19 |
組織は、セキュリティ機能の管理に関連する行動やアクセスの記録を含む、セキュリティ手順が定義され、遵守されることを保証しなければならない。 |
Table C3 Mitigations to the threats which are related to "Physical loss of data loss"
|
30.1 |
第三者による被害 交通事故や盗難などの物理的な損傷により、機密データが失われたり損なわれたりする可能性があります |
M24 |
個人データを保存する際には、データの完全性および機密性を保護するためのベストプラク ティスに従わなければならない。ISO/SC27/WG5 の 30.2 DRM（デジタル著作権管理）からの損失がセキュリティ・コントロールの例として挙げられる |
|
30.2 |
ISO/SC27/WG5のコンフリクトで見つかったDRM(デジタル著作権管理)による損失。DRMの問題でユーザーデータが削除される可能性がある |
||
|
30.3 |
IT機器の綻びにより機密データの整合性が失われ、潜在的な問題が発生する可能性があります（鍵が改ざんされた場合など） |
それでは、先程紹介した攻撃手法に対する防御手法を具体的に見てみましょう。
シビル攻撃（Sybil attack）
シビル攻撃（Sybil attack）はID作成にコストをかけさせることでIDを大量に作られることを予防できます。自動運転車の場合においては、外部と通信するためのインターフェースを持つことになるため、サービスプロバイダーが持つ情報（通信キャリアが発行するIDや電話番号、位置情報など）を含めることで、攻撃を緩和できる可能性があります。
Meital Ben Sinai氏らが実証したWAZEの場合、IDの作成時の検証が行われていないため、低コストでIDの作成（Bot Driverの作成）が可能でしたが、サービス登録時に電話番号を取得し検証することで、攻撃者は有効な電話番号を持たなければIDが作成できないため、攻撃を行うためのコスト（攻撃に必要な数だけ契約を行い、電話番号を取得する）が増加し、攻撃を受けにくくすることができます。
また、キャリアが提供するユーザの位置情報を検証することで攻撃を緩和する方法も併せて提案しています。これは、通信時に接続するキャリアの基地局（アンテナ）の位置とユーザから送られてくるGPS情報を照合し、ズレがないかを確認することで、偽装されたリクエストかの判断を行います。この対策まで行うことで、仮に攻撃者が大量の電話番号を取得した場合でも、位置情報の偽装が難しいため、攻撃を受けにくくすることができます。
別のアプローチとして、ユーザの行動を分析することで、人間とBot Driverを区別する方式も示されています。単純な手法としてはIPアドレスの検証です。同一IPからの複数ユーザのアクセスを監視し、ブロックするというものです。自動運転車の場合には、３G/4G/5G回線からの通信である可能性が高いため、これらのIPアドレスからのレポートが他のIPアドレス帯からのレポートよりも質が高いものとして扱うことで、攻撃を成功させにくくできます。攻撃者は、３G/4G/5G回線を用意して攻撃することは可能ですが、回線準備のコストをかけさせることで、攻撃の機会を減らすことができます。
また、ユーザの移動や報告パターンなどを分析することで攻撃を検知、対応を行うことができます。例えば、質の悪いBot Driverの場合であれば、行動パターンが同じになったり、人間のドライバーとの違いを分析・比較して、Bot Driverを炙り出したりすることができます。このロジックは内部のロジックとなるため、追加の機材や通信が不要です。ただし、人間と入念に訓練されたBot Driverを見分けることは難しく、攻撃されないためには、ロジックのメンテナンスとアップグレードが重要となります。
OBD-IIポートを経由した攻撃
Ian Foster氏らが実証した遠隔の攻撃者がOBD-IIポートを経由し任意の遠隔操作では、次のような対策を挙げています。
1つ目の対策として、アップデート時に関する認証に関するものです。本論文の実証では、全デバイスで同じ秘密鍵と公開鍵が用いられており、秘密鍵と公開鍵を抽出可能な状態でした。アップデートサーバにはこの秘密鍵でアクセスできる状態でしたが、フィンガープリントの検証などアップデートサーバが正しいものであるかの検証が行われず、更には、ダウンロードしたアップデートが正しいものであるか検証していませんでした。このため、接続サーバが正しいものであるか（例えばSSL pinningなど）の検証やダウンロードするアップデートにコード署名をつけるといった対策を提案しています。
2つ目の対策は、SMS認証に関するものです。SMSの送信元を制限する機能がありましたが、電話番号の詐称が行えるため、認証としては不十分な状態でした。このため、SMSによるリモート管理を完全に無効にするか、SMSに加えて他の認証形式を使用することを提案しています。
3つ目の対策は、鍵やパスワードの管理に関するものです。本論文の実証では、全デバイスで同じ秘密鍵と公開鍵が含まれている状況でしたが、本来、秘密鍵はデバイス上に保存しておく必要はありませんし、何かしらの理由で秘密鍵を保持する必要がある場合でもデバイスごと異なる鍵を持つ必要があります。また、パスワードに関してもMD5でハッシュ化しただけで用意に解析が行える状態でした。組み込み機器ではユーザ（攻撃者）がデバイスを解析できる前提となるため、パスワードの強度や管理方法はとても重要です。
4つ目の対策は、管理インターフェースに関するものです。本論文の実証では、インターネット上からデバッグ用の管理インターフェース（WebやSSH/Telnetなど）へのアクセスが可能な状態でした。本来これらの管理インターフェースへのアクセスは誰でもアクセスできる状態にすべきではありません。また、管理インターフェースにアクセスする際の認証が存在しない点も問題として指摘しています。デバッグ用の管理インターフェースへの許可が必要である場合には、デバイスごと異なる認証を行い、認証をバイパスされない対策が重要です。
5つ目の対策は、アップデートサーバに関するものです。本論文の実証では、アップデートサーバがデフォルトで設定されていますが、そのドメインが未登録の状態であったと指摘しています。攻撃者がそのドメインを取得することで、アップデート要求したデバイスを乗っ取ることができる可能性があるため、製品で使用されたドメインの維持していくことが必要であると提案しています。
WiFiを経由した攻撃
Tesla Model Sへの脆弱性対応では、次の3つの対応を行っています。
1つ目はWebブラウザのセキュリティ強化です。Tesla の自動車が搭載しているWebブラウザ（QtCarBrowser）に任意のコード実行が可能な脆弱性が存在していましたが、AppArmorとiptablesによる制限のため、Webブラウザ権限のアカウントでは単独では悪用が困難なものでした。直接悪用が困難な脆弱性であったとしても、複数の脆弱性を組み合わせることで、攻撃が成功する可能性があるため、脆弱性への対応を怠ってはいけません。
2つ目の対応は、Linux Kernelのセキュリティに関する対応です。当初Tesla Model SではLinux 2.6.36を使用しており、このバージョンに存在する有名な脆弱性を自身で全て修正しています。バージョンアップが困難な場合には自身で対応する必要がありますが、修正にはかなりの労力がかかります。その後Tesla Model SではLinux 4.4.35にバージョンを変更しており、このバージョンには攻撃を緩和するための機能が実装されており、これらの機能を有効にすることで攻撃を難しくすることができます。
3つ目の対応は、コード署名です。Tesla Model Sを操作するためファームウェアを書き換えが成功しており、この書き換えを防ぐためコード署名の対応を行っています。ただし、ECUの演算能力は低く、署名を検証することが難しいため、独自の検証方法を実装しています。
いくつか事例を取り上げて防御手法を見てきました。
クラウドサービスにおける対策は自動運転車固有の対策ではなく、従来のセキュリティ対策と同じものが大半です。クラウドのサーバにおいては、パッチマネジメントやアクセス制御が重要になりますし、リアルタイムに攻撃を防御/緩和/検知するため、WAF/IPSなどの攻撃に対する防御機器やセキュリティ監視も重要です。クラウドのサーバ上で動作するアプリケーションにおいては、セキュリティを考慮した設計、セキュアコーディングが被害を抑える対策になります。加えて、手元に製品が存在し解析が行えることを前提としておく必要がある点に注意が必要です。クラウドサービスへのAPIのリクエストを取得したり、解析したり、鍵情報の吸い出したりなどIoT機器と同じく、攻撃者が情報を集める手段が充実しています。反対に防御側のデバイスリソース（CPU/メモリなど）は限られているため、複雑な暗号化などの対応が難しい状況にありますし、１つ１つの部品やデバイスにセキュリティ機能を搭載することはそれだけコストが上がることになるため、現実的には厳しい状況です。更には、OTAアップデートが普及し始めていますが、アップデート方法が限られているためパッチの適用が難しいことも認識しておく必要があるでしょう。ここで紹介した攻撃手法や防御手法は一例でシステム固有の対策も含むため、自身のシステムに合わせて対策を行っていくことが必要です。
最後に
本ブログでは、自動運転車に関連するクラウドサービスに対する攻撃手法と防御手法を紹介しました。
クラウドサービスは攻撃者の標的になりやすく、自動運転車の場合、攻撃の影響が大きくなる傾向にあります。クラウドサービスへの攻撃は従来のコネクテッドカーでも同様の脅威があることを認識しつつ、自動運転車への影響を考慮する必要があります。また、自動車で使用されるデバイス類は攻撃者の手元に存在し、解析することができるため、クラウドサービスに接続するデバイス類のデータの取扱にも注意を払う必要があります。レベル５のように高度に自動化された自動運転車になるほど、クラウドサービスに対する防御は重要になってくるでしょう。
本ブログはこれで終了となります。
次回は「第4回：意思決定モデルに対する敵対的攻撃 - 回避攻撃 -」となります。
AIセキュリティのトレーニング
弊社は株式会社ChillStackと共同で、AIの開発・提供・利用を安全に行うためのトレーニングを提供しています。
本トレーニングでは、ディープラーニング・モデルに対する様々な攻撃手法（汚染攻撃・回避攻撃など）とその対策を、ハンズオントレーニングとeラーニングを通じて理解することができます。
本トレーニングの詳細やお問い合わせにつきましては、弊社窓口、または、AIディフェンス研究所をご覧ください。
最後までご覧いただき、誠にありがとうございました。
以上
おすすめ記事
