脅威リサーチ

車載コンピュータの脆弱性特定に便利な 4CAN ツール

TALOS Japan
2019年9月9日

エグゼクティブサマリー

最新の自動車には何百ものセンサーやメカニズムが搭載され、コンピュータとの通信を介して周囲の環境を把握する仕組みが備わっています。それらの部品や装置は運転者がリアルタイムで情報を得たり、車両をグローバルネットワークに繋ぐのに使われるだけではありません。測定データを使用した自動運転も可能です。一般的なコンピュータと同様、車載コンピュータはソフトウェアの脆弱性や物理的な不正アクセスなどの脅威の影響を受けやすく、車両の制御をリモートで奪われるおそれすらあります。これは WIRED と国防高等研究計画局（DARPA）が出資した研究チームによって最近実証されたとおりです。

Allied Market Research 社の見立てでは、全世界のコネクテッドカーの市場規模は 2025 年までに 2,250 億ドルを上回ると予測されています。シスコではこの新しいテクノロジーのセキュリティを強固なものとするため、自動車セキュリティを専任とする人材を集めています。カスタマーエクスペリエンスアセスメント & ペネトレーションチーム（CX APT）は NDS 社、Neohapsis 社、Portcullis 社の 3 社の買収により実現した専門家のグループです。世界中のお客様に各種のセキュリティアセスメントと攻撃に対するシミュレーションサービスを提供しています（詳細はこちらをご覧ください）。コネクテッドカーの構成要素に潜む脆弱性を特定することが CX APT の専門領域になります。

最近の取り組みでは、コネクテッドカーのセキュリティプラクティスによって、自動車のセキュリティを評価するための適切なツールが欠けていることが明らかになりました。最新の自動車に求められるコンピューティング要件を満たし、使いやすく手頃で入手しやすいものを追求していく中で、コネクテッドカー向けのセキュリティプラクティスを構築しました。「4CAN」と名付けたハードウェアツールは自動車のセキュリティを研究するすべての人に有益なものになるよう、ソフトウェアを付属してオープンソースとして公開しています。研究者や自動車メーカーに 4CAN を利用して車載コンピュータの潜在的な脆弱性に関するテストを実施してもらうことで、実際に車を動かす前に、車両と運転者の安全性が高まることを期待しています。

自動車ネットワークの概要

4CAN のハードウェアモジュール本体の仕組みに進む前に、まず自動車の基本から始めましょう。最新の自動車がその真価を発揮できるのは、何百ものセンサーとコンピュータからなるネットワークの相互通信があってこそです。車両と構成部品には Wi-Fi、Bluetooth、移動体通信のプロトコルが採用されていますが、車両ネットワークのバックボーンになるのは「CAN バス」とも呼ばれるコントローラエリアネットワーク（CAN）です。

CAN バスへの物理的なアクセスは、通常 ODB2 コネクタを介して行います。コネクタは運転席側のダッシュボード下部にあることが多いですが、サイドミラーや外側のライトを取り外してアクセスする場合もあります。CAN バスのセキュリティが侵害されると車両全体の制御が奪われるため、ペネトレーションテスターや悪意のある攻撃者が最重要攻撃目標とするのがこの CAN バスです。Wi-Fi や LTE などの周辺機器に対する攻撃は、多くの場合 CAN バスへのアクセスを手に入れることが最終目標になります。

CAN バスのバックグラウンド

車両の一般的な CAN バスを以下に示します。セキュリティを考慮した構成では、エアバッグやブレーキなどの重要性の高い装置の通信は、ラジオや室内灯などの重要性の低い装置とは別の CAN バス上で行われます。CAN バスにアクセスできるペネトレーションテスターや攻撃者は、安全に設定されていない車両を探して、サービスを分離するテストを行います。

CAN バスは 2 線式のマルチマスター方式によるシリアルバスです。CAN バスに接続される各デバイスは「ノード」または ECU（Electronic Control Unit）と呼ばれます。デバイスからメッセージ（CAN フレーム）が送信されると、メッセージは CAN バスにブロードキャストされてすべてのノードに届きます。2 つのノードが同時に CAN フレームをブロードキャストすると、すべての CAN フレームに含まれるノード識別子の一種である、一意のアービトレーション ID によってメッセージの優先順位が決定されます。アービトレーション ID の値が小さい CAN フレームの方が、値が大きい ID よりも優先されます。

CAN バスは、電気的には差動信号を使用することでノイズや電波干渉を低減しています。差動信号には CAN-HI と CAN-LO の 2 つの信号があります。この信号は互いに逆向きに流れます。また、このバスは 120 オームというバス固有の特性インピーダンスを持っています。CAN-in-the-Middle を実行する場合は、120 オームの抵抗で終端する必要があります。以下は Wikipedia の画像です。CAN バスの詳細については、Wikipedia の概要をご覧ください。

複数のノードを持つ単一の CAN バス

自動車用ネットワークの最も単純な実装形態は、単一の CAN バスを使用するものです。以下の図は 3 つのノードがある CAN バスの例です。接続されているすべてのノードに、CAN バスに発行されたすべての CAN メッセージが表示されます。重要なノードとそうでないノードを切り離せるような機能はありません。

単一のゲートウェイを持つ複数の CAN バス

車両用の構成としては複数の CAN バスと、CAN バス間のアクセスを調停するための単一のゲートウェイを組み合わせたものが一般的です。ゲートウェイはファイアウォールとして機能し、CAN ID をチェックすることでメッセージを通過させてよいか否かを判断できます。このようにして重要度の高い ECU をそうでない ECU から切り離すことができます。

Talos でのテストに使用している車両には 4 つの CAN バスが内蔵されていて、そのすべてがゲートウェイに接続されています。そのアーキテクチャは次のようなものです。

バス上の各 ECU のセキュリティは、部分的にはトラフィックを分離するゲートウェイの機能に依存しています。このゲートウェイのテストでは、別系統の CAN バスを通ることを許可されているメッセージの送信と検索を行います。4 つのバスで構成されるシステムでは、ペネトレーションテスターが 4 つのバスに同時にアクセスできる必要があります。

既存のソリューション

CAN バスのテストが可能なデバイスは複数あります。そのデバイスのほとんどに MCP2515 CAN コントローラが採用されています。このコントローラはマイクロコントローラや MCP2551 CAN トランシーバ、NXP TJA1050 CAN トランシーバと接続するためのシリアルペリフェラルインターフェイス（SPI）を備え、物理 CAN バス上で電気信号の生成と受信を行います。次の表は、今現在市場で入手できるハッキングソリューションの一部について説明したものです。

各デバイスにはそれぞれに長所と短所がありますが、使いやすく、4 つのバスにアクセスでき、手頃な価格で利用できるというニーズを完全に満たすものはありませんでした。現在手に入るデバイスが、私たちのニーズに合致している点を以下の表にまとめています。

互換性のあるデバイスがないため、私たちは自らこの問題の解決に乗り出しました。この解決策へと踏み切ったのは、技術的な観点から次のようにしたいという思いがあったためです。

Raspberry Pi と互換性があること
120 オームのバス終端抵抗を簡単に有効化/無効化できること
SocketCAN のネイティブサポートにより Linux との統合が容易であること
安価であること

Talos のソリューション

私たちはこのソリューションを「4CAN」と名付け、次の目標を念頭に設計しました。

内部の CAN バス通信に適用される通信ポリシーを検証する。
コンポーネントに対するファジング（ランダム化したペイロードの送信）により脆弱性を特定する。
車両の制御/操作に使用できる CAN コマンドを検索する。
テスト環境の設定を単純化し、全体の整理と同期を図る。

設計

4CAN の設計を担当したのは CX APT のメンバーである George Tarnovsky です。Raspberry Pi には 5 つのハードウェア SPI チャネルが搭載されているため、SPI を介して Pi とのインターフェイスに使用できる MCP2515 CAN コントローラを採用しています。ジャンパやはんだブリッジではなく 4 ポートの DIP スイッチを増設することで、120 オームのバス終端抵抗を簡単に実現しています。MCP2551 CAN トランシーバは、CAN トランシーバとして使用しています。

大まかな設計については以下の図を参照してください。細部を確認されたい場合は、こちらをご覧ください。

PCB のレイアウト

なるべく互換性を持たせるために、Raspberry Pi HAT の仕様にできるだけ準拠していることを目指しました。HAT の仕様ではハードウェアの寸法に制限があるため、すべての部品を基板上に収めようと思えば創意工夫を凝らす必要があります。EEPROM は積んでおらず、カメラコネクタ用の安全装置も残していないため、モジュールは HAT の仕様どおりではありません。カメラを拡張する予定がないこと、EEPROM を使用しないことから意図的にこのような設計にしています。

見つけられる中でも最小クラスの部品を用いることで基板の使用面積を切り詰め、すべての部品を基板表面に取り付けています。USB-UART の接続に関してのみ、例外的にそのような部品は採用していません。全部品を自分で追加するのではなく、あらかじめすべての回路が組み込まれた既製品の基板を使用しています。この基板が 4CAN の上位層になります。抵抗をまとめて詰め込むことで部品点数をさらに減らし、4 つ別々の抵抗を扱うよりも設置面積を抑えることに成功しています。4 つの CAN コントローラすべてに別々の水晶発振器を使用するのではなく、1 つだけ使ってコントローラを駆動しています。こうすることで各コンポーネントは同時並行ではなくシリアル方式で連続的にクロックを受信するため、クロックスキューが生じます。クロックスキューの影響を抑えるため、クロックラインは可能な限り短くしました。さらに、コストを抑えるために 2 層からなる PCB 設計を採用しています。構造上ルート設計は制限されますが、層が多い基板と比べてコストを格段に抑えることができます。また標準的な 40 ピンの GPIO ヘッダーを追加して、残りの GPIO を使用できるように工夫しています。

最終的なレイアウトは以下のようになりました。

4CAN の使用前と使用後の比較

使用前

4 つある CAN バスを同時にテストするには、CAN デバイスが 3 台必要になります。そこで 3 チャネルを利用可能な TT3201 CAN Cape 2 基を Beaglebone に接続し、CanBerryDual 1 基を Raspberry Pi に接続します。さらにテスト車両をリモートで制御するために、もう 1 つ別の Raspberry Pi を用意します。この構成では任意の CAN チャネル 2 つを組み合わせ、そのチャネル間で CAN フレームの送信をテストできます。この設定でも動作はしますが、必要な配線が多いため接続をたどったり集約のテストをしたりするのが難しく、多少扱いにくい構成と言えます。

使用後

4CAN を使用するとテスト環境のセットアップが非常にシンプルになり、4 つのチャネルを Raspberry Pi 1 つで同時にテストでき、なおかつ 4CAN は 40 ピンの GPIO ヘッダー全体が露出しているため、これを使ってテスト車両をリモートで制御できます。

4CAN を使えば何かとシンプルになることは、物理的なテスト環境を見れば一目瞭然です。

4CAN を使用する前

4CAN を使用した場合

用途

4CAN が Raspberry Pi と通信するには、4 つある SPI チャネルを有効にして、特定の GPIO ピンと接続するように Pi を設定する必要があります。また Pi の Linux カーネルには SocketCAN などのドライバを追加する必要があります。SocketCAN を導入すると CAN デバイスドライバをネットワークインターフェイスとして実装できます。ユーザスペースの観点から can-utils があります。このユーティリティには、SocketCAN ドライバを読み込んで CAN トラフィックの盗聴や CAN メッセージの送信、キャプチャした CAN トラフィックの再生が可能になるほか、CAN ゲートウェイを実装して CAN-in-the-Middle が容易になるなど、さまざまなメリットがあります。

CAN-in-the-Middle

ECU がメッセージの送受信を行っているかを確認したり、処理中の CAN トラフィックを変更したりするには、4CAN を CAN バスと ECU の間に挟む構成にします。こうすることでトラフィックのキャプチャや変更、CAN-in-the-Middle（CITM）攻撃を実行できます。can-util の「cangw」コマンドと、Talos が提供しているスクリプトを組み合わせることで、必要となるブリッジを実現できます。

CAN 相互の通信のスニッフィング

4CAN では、ある CAN バスに既知のペイロードを持つ CAN メッセージを送信し、別の CAN バスで同じメッセージが表示されるかを確認することで CAN 同士でやりとりされる通信をテストできます。この方法なら CAN ゲートウェイでメッセージのフィルタリングや変更が行われているどうかといったことや、それらの挙動について知ることができます。Talos で行ったテストでは、同じメッセージの CAN ID が、バスが変わると異なる場合があることを確認しています。「transcan」のテストに便利なスクリプトを提供していますので、ぜひご活用ください。

ツールの公開

4CAN は GitHub で入手できます。

本稿は 2019年8月22日に Talos Group のブログに投稿された「ew 4CAN tool helps identify vulnerabilities in on-board car computers 」の抄訳です。

コメントを書く