SDV時代における車の変化
運転者が直接触れるカーナビからエンジンやステアリングの制御といった車両の制御に関わる機器に至るまで、様々な電子機器(ECU:Electric Control Unit)が車両には搭載されています。これらのECUの中にはWi-Fiやモバイル回線を利用してインターネット経由でサーバーと通信し、機能の追加やソフトウェアのアップデートを行い最新の状態に保つようになるものも出てきています。
この近年のECUにおける高性能化・多機能化は、SDV(Software Defined Vehicle)[i]と呼ばれている流れの一部と考えることができ、複数の個別の機能を持ったECUの組み合わせで車両の電子プラットフォームを構成するのではなく、小数の高性能なハードウェアを用いてソフトウェアによって機能の追加更新をしていくということが特徴の一つであると言えます。
このように欲しい機能の追加であったり、セキュリティアップデートや機能更新のためのソフトウェア更新であったりといったものは、スマートフォンが身近になった現在においては特に目新しい機能ではないように思えます。実際、カーナビではスマートフォンでも利用されているAndroid OS(厳密にはAndroid OSを元に車載機器用にカスタマイズが施されたAndroid Automotive OS)を搭載したものも数多く出てきています。
ただし、ここでスマートフォンとカーナビ等のECUとで勝手が違ってくる点としては、車両に接続されている機器であるかどうかという点です。もしもECUが悪意のある攻撃者により侵害されてしまうと車両の制御にまで影響が出てしまい、人命に関わる事態にまで発展する可能性も考えられます。
このとき、攻撃を防ぐために脆弱性が作りこまれないようにしていくということも重要ではありますが、あらゆる脆弱性が存在しない完璧なソフトウェアというものは考えにくいです。また、サードパーティー製のソフトウェアをユーザーがインストールできるようになることも考慮すると、出荷後に悪意あるソフトウェアが導入されてしまう可能性も否定できません。
そのため、何らかの方法にて攻撃者からのECUの侵害を許してしまった場合にも、その攻撃の影響ができる限り小さくなるようにするということが現実的な対策の一つとなります。そこで出てくるのがソフトウェアの実行環境分離という考え方です。
ここでは実行環境分離の手法について、いくつかの例を挙げつつ、セキュリティ上どのような点を考慮する必要があるのかを見ていきます。
ソフトウェアの実行環境分離
ソフトウェアの実行環境分離とは、ソフトウェアが実行時に利用するリソース(CPU、メモリ、ストレージ、ネットワーク、その他デバイス等)を論理的に分離するということを指します。環境を分離することにより攻撃を受けた際にもその影響を最小限に抑えることが可能になります。
例として、攻撃者が仕込んだ悪意あるサードパーティー製のソフトウェア(以後ソフトウェアA)と車両を制御するソフトウェア(以後ソフトウェアB)とが同じ環境で実行される場合を考えてみます。仮にそれらの実行環境間で適切にソフトウェアのメモリが分離されていないとします。
このときソフトウェアAが何かしらの脆弱性を突き権限昇格ができてしまうと、ソフトウェアBのメモリにアクセスし、内容の改ざんや機微情報の窃取をされてしまう恐れがあります。また、ネットワークの分離が適切に出来ていないとすると、ソフトウェアAからソフトウェアBに対して任意の通信を発生させ、ネットワーク経由の攻撃が可能となります。
このようにソフトウェアBに対しての攻撃が成立してしまうと、車両制御の機能が悪用され車両の操作が奪われてしまう可能性があります。そのため、機能の重要度やリスクに応じて互いに不要なアクセスが出来なくなるように実行環境を分離したいという要求が出てきます。
また、実行環境分離といってもそれを実現するための技術は複数存在します。車載機器に利用されるものとして考えられるものをいくつか挙げると、VM(Virtual Machine、仮想マシン)やコンテナ、ARM TrustZoneに代表されるようなTEE(Trusted Execution Environment)等が挙げられます。
ただし、これらの技術を使うだけでソフトウェアの実行環境を適切に分離できるわけではありません。一つには、実行環境を分離したいユースケースに対して、十分なセキュリティ担保ができない分離技術を選択しているケースが考えられます。また他にも、セキュリティ上必要な設定や構成が適切でないまま利用してしまい、十分に実行環境の分離ができていないケースも考えられます。
そのため、選択する分離技術については分離したい対象機能等によってリスクを計算することで、どれだけセキュリティ的に強固な分離技術を用いるかを選択する必要がありますし、分離する方法が決まれば、その分離技術によって仕組みや実装も当然異なるので取るべきセキュリティ対策もそれぞれに異なります。ここではいくつかの技術を例として、その分離技術の特徴と、利用する際に検討すべき脅威を確認したいと思います。
ソフトウェア実行環境分離技術に対する脅威
ソフトウェア実行環境分離を達成する手法
VM
VMとは仮想マシンの名の通りOS(カーネル)のレベルでマシンを仮想化し動かしたものを言います。この時VMはハイパーバイザーと呼ばれるソフトウェアにてCPUやメモリ、デバイス等の仮想化を含めた管理を行い、ゲスト環境からホスト環境や他のゲスト環境に対して直接影響を及ぼすことができないように分離し管理します。
VMによる分離はセキュリティ的には比較的強固な分離方法となっており、一つのゲスト環境のOSが侵害されたとしても直ちに他のゲスト環境のOSに影響を及ぼすことはありません。しかしVMによる分離を行えば全ての攻撃を防げるかというとそういうわけではなく、ハイパーバイザーは様々なリソースの仮想化やVMの管理を行うため非常に多機能であり、そのため攻撃界面となる箇所も多くなります。
どこかに脆弱性が存在すると、ゲスト環境からホスト環境や他のゲスト環境に対して攻撃が可能となることもあり、そのような攻撃のことをVMエスケープと呼ぶことがあります。また、VMにて利用するOSやデータ等が含まれたイメージと呼ばれるファイルがホスト環境上に存在するため、そのイメージが改ざんされてしまうとゲスト環境の挙動が操作されることに繋がります。
そのため、ゲスト環境からホスト環境等の外部へのアクセスに対しては適切なフィルタリングや権限の制限を行うなどのセキュリティ対策を取る必要があります。
VMによるソフトウェア実行環境分離
コンテナ
Dockerを代表とするようなコンテナ技術もソフトウェア実行環境分離の手法として考えることが可能です。コンテナでは同じOS上で名前空間(USER名前空間、PID名前空間等)やリソース、及び権限等を分離することで環境の分離を行います。
VMではOSごと仮想化及び分離されていたのに対して、コンテナでは単一のOS上で動作するためその分のオーバーヘッドがなくなる分軽量に動作します。一方でゲスト環境の一つのOSが攻撃者によって侵害されたときを考えると、VMを利用しているのであれば他の環境に影響は出ませんが、コンテナを利用している場合は他の全てのコンテナとホスト環境も同じOSを利用しているため全体に影響が及びます。
このことからコンテナによる分離はVMによる分離よりもセキュリティ的には多少強度が下がることになります。なお、従来はコンテナを管理するプロセスをrootで動かすことが一般的でした。しかし近年では最小権限の原則を踏襲していると見なせるroot権限の不要な(rootlessな)コンテナ製品も増えてきています。
コンテナによるソフトウェア実行環境分離
TEE
TEE(Trusted Execution Environment)とは、実行環境分離技術の一つであり、ソフトウェアの実行環境をセキュアワールドとノーマルワールドと呼ばれる環境に分け、機密情報等をセキュアワールドでのみ扱うことで強固なセキュリティを担保する技術です。
様々なTEEの実装が考案されていますが、車両に関わる領域にて現時点で利用されているものはほぼARM TrustZoneのみであると言っても差し支えないでしょう。
TrustZoneにおけるセキュアワールドの分離にはハードウェア(ARMアーキテクチャのCPU)によるサポートを利用しつつ、専用のOS(OP-TEE、Trusty等)を動かすことで達成されます。TrustZoneの利用例として有名なものにはAndroidで暗号鍵の管理しているkeystoreシステム等が挙げられます。
この分離技術はハードウェアによる支援を受けており、セキュアワールドとノーマルワールドが厳密に分離されています。とはいえ完全に外部と遮断されているというわけではないため、適切にセキュリティ対策を入れていく必要はありますが、これまでのVMやコンテナと比較して最もセキュリティ的に堅牢であり、秘密鍵や個人情報といったような機密性の高い情報を扱うユースケースでの利用が考えられます。
ただし、いくら堅牢とはいえその代わりとして利用に制限もあり、全ての実行環境分離にこの方法を用いることは現実的ではありません。なぜならTEE環境においては、脆弱性を作り込まないことがもっとも重要となるからです。
一般的にソフトウェアは多機能になるほど脆弱性の混入する余地が増えるため、なるべくコード量を抑えシンプルに保つ必要があります。このためTEE環境のOSには最低限の機能しかなく、ノーマルワールドで実行される処理の多くはセキュアワールドへの移植が困難となります。
TrustZone(ARM Cortex-A)によるソフトウェア実行環境分離%E3%81%AB%E3%82%88%E3%82%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%AE%9F%E8%A1%8C%E7%92%B0%E5%A2%83%E5%88%86%E9%9B%A2.png?width=733&height=396&name=TrustZone(ARM%20Cortex-A)%E3%81%AB%E3%82%88%E3%82%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%AE%9F%E8%A1%8C%E7%92%B0%E5%A2%83%E5%88%86%E9%9B%A2.png)
実行環境分離との関わり方
これらの分離技術は近年のSDVの流れに乗って、複数のECUの機能が統合されたECUの登場や、サードパーティー製のソフトウェアの導入といったものに対応していく中で非常に力強い味方となってくれることが期待されています。しかし、これまでECUで多く利用されてきたものでないということもあり、その扱い方には十分に留意する必要があり今後の課題となってくるのではないかと考えられます。
ECUに関わる標準化等を推進しているJASPARからも、実行環境分離を利用する際のセキュリティ機能要件定義書[ii]なども公開されているということもあり、分離をする必要のあるユースケースから適切な分離技術を判断し、その上で十分にセキュリティ対策も取り入れることで、実行環境分離という技術を最大限活用することができると考えられます。
[i] スマホのようにソフトウェアアップデートによって車両機能や性能を更新できる自動車
[ii] ソフトウェア分離技術を用いた車載セキュリティ機能要件定義書Ver.1.01
(https://www.jaspar.jp/standard_documents/detail_disclosure/704)