図1:現代の自動車のインタフェース
攻撃の影響を受ける可能性があるのはインフォテインメントシステムだけではありません。AIや自動運転システムはリアルタイムで収集したデータに基づいて判断を行い、その判断は重要なシステムに影響を与え、車両や道路利用者に重大な損害を与える可能性があります。自動運転システム搭載車だけではなく現代ではブレーキペダルやハンドルなど重要なシステムの多くが電子制御されています。
自動車企業はそのリスクを認識していますが、ではどのようにしてサイバーセキュリティ、リスクアセスメント、分析を適切に実施できるのでしょうか。脆弱性を発見された場合、どうすれば被害を最小限に抑えることができるのでしょうか？
あなたのソフトウェアに脆弱性は(おそらく)存在する
自動車に搭載されているソフトウェアの総コードサイズはどんどん大きくなっています。例えば、自動車のコードサイズは飛行機のソフトウェアの約10倍になります。図2は、さまざまなアプリケーションにおけるソフトウェアの規模(行数)を示しています。
このように規模が膨れ上がっている理由として挙げられるのは、自動車ソフトウェアにおける新しい技術への需要が増加しているからです。
当初は、グラフィックスが魅力的なインフォテインメントシステムや、AndroidやLinuxなどのスマートフォンのOSを採用し、開発サイクルの高速化や既存のライブラリの再利用を図ってきました。しかし、残念なことに、これらのOSは根本的に自動車のセキュリティや安全性の要求に対応できるように設計されていないという問題があります。これら汎用OSの脆弱性は頻繁に発見されており、中には深刻な問題を引き起こす可能性のあるものも存在します。
ソフトウェアの複雑さは他の問題も引き起こします。総コードサイズが大きすぎる為、各コンポーネントのメンテナンスにそれぞれの専門知識が必要になってきます。そのため、OEMやTier1企業は各モジュールの開発をサードパーティ企業に頼る必要があります。脆弱性が発見された場合はどうなるでしょうか。多くの場合、原因を特定する為に、複数の企業が書いたソフトウェアを追跡する必要があります。開発者は、複数のモジュールからなるソースコードの出所やコード変更履歴を追跡する方法を確立しなければいけません。
ほとんどの車には、LTEやWi-Fi、Bluetoothなど、他のデバイスを接続するための複数のネットワークインタフェースが搭載されています。将来的には、車両間接続や信号機との接続など、より多くのネットワークインタフェースが追加されることになるでしょう。
IEEEなどで定義されているネットワーク層はどれも単純ではなく、ほとんどのプロトコルが複雑で、一からソフトウェアスタックを構築するのは難しく、現実的でないでしょう。自動車メーカーは、開発時間を短縮するためにEthernet、TCP/IPなどのプロトコルスタックにサードパーティ製のライブラリを使用する必要があります。ライブラリの中にオープンソースのものが含まれる場合、何千人もの人の手が入っていることもあるでしょう。このようなオープンソースソフトウェアのコードは「現状のまま(As-Is)」で提供されます。そして、基本的なことを忘れてはいけません。それは、安全性を重視する必要がある自動車のようなアプリケーションのために設計されたものではないということです。企業は、ソフトウェアライブラリのリスクを評価し、リスクを軽減する方法を計画、実施する必要があります。
そういった把握しきれないソフトウェアの不具合を解決し、新機能を追加するために、OTA(Over the air)アップデートは多くのモデルでサポートされているか、またはサポートされる予定です。OTAは車両に多くのメリットをもたらしますが、プログラムを書き換えるというリスクがありますので、設計プロセスと更新プロセスは慎重に行わなければなりません。
以上のような理由により肥大化した、膨大な量のソフトウェアコードにありうるすべての脆弱性を未然に防ぐことはできるのでしょうか？ 非常に難しいと言えるでしょう。
ハッキング手法
過去10年間で、安全性に重大な影響を及ぼす深刻な脆弱性が多数報告されています。一番脆弱な領域からシステムに侵入することが、最終的に重要なシステムへの入り口にたどり着くための一般的な方法です。
現代の車内ネットワークには、BluetoothやWi-Fi、LTEなど、車載システムに接続されているインタフェースが多数存在しています。
通常、攻撃者は、インフォテインメントシステムがLinuxやAndroidなどの汎用OSを実行している場合、バッファオーバーランなどに代表される情報ハブ内のエクスプロイトのいずれかを使用します。
彼らはまずシステムへのアクセスを得た後に、いくつかの悪意のあるソフトウェアを実行して起動することによって、CANバスまたはFlexrayやLINなどの類似のバスプロトコルへのアクセスを試みます。CANバスは、自動車で使用される一般的なプロトコルであり、接続されているデバイスは、エンジンセンサー、ブレーキ、トランスミッションなどの安全性が重要となるものです。CANバスは車載システムのセキュリティが課題となる前に仕様が策定されました。CANバスの信号はスニッフィングすることができるので、1台でも車をテスト用途で所有していれば、プロトコルは個別に分析することができます。
図3に示すように、典型的な攻撃は二つの段階に分けることができます。第一段階はインフォテインメントシステムへの攻撃であり、第二段階は車両バスプロセッサへの攻撃です。
自動車メーカーは、それを防ぐためにいくつかのファイアウォールを設置し、システム間の隔離を行うことで、システム全体への侵入を防ぎ、システムのセキュリティを高めることができますが、そのリスクは適切に評価する必要があります。
ISO / SAE 21434の必要性
脆弱性のほとんどは優れたソフトウェア及びワークフローの設計によって防ぐことができます。重要なシステム障害を最小限に抑えるにはどうすればよいのでしょうか？
過去には、自動車のサイバーセキュリティに関する規格は存在しませんでした。多くのソフトウェアが組み合わされ、その中にはサードパーティ製のものもあれば、LinuxやAndroidのようなオープンソース製のものもあります。開発者は、すでに述べたように、すべての部品をリストアップし、コードを追跡し、各モジュールを評価する必要があります。しかしそれはメーカーごとの判断で行われており、どのようにするかを説明する基準がありませんでした。
また、脆弱性が露呈した場合に企業がどのように対処するかについても、標準的な方法がありませんでした。脆弱性が露呈した場合、多くの場合その企業による何かしらのアクションが必要となります。脆弱性が露呈した場合、企業は顧客とのコミュニケーションと情報伝達を行い、問題を修正し、その修正策を展開する必要があります。さらに重要なことは、事前に起こりうる脆弱性のシナリオをチェックし、それらの問題から最も重要でクリティカルなモジュールを保護する必要があるということです。
その目標を達成するための最善の方法とは何でしょうか？
ご存知のように、ISO 26262は機能安全のために確立された規格です。この規格では、ソフトウェアを非常に慎重に評価することが求められています。しかしながら、OTAアップデートのようなソフトウェア自身のライフサイクルは考慮されていません。ISO26262は安全規格として非常に重要ですが、セキュリティの規格ではありません。
ISO 21434は、自動車のサイバーセキュリティに関するフレームワークであり、Green Hills SoftwareのINTEGRITYリアルタイム オペレーティング システム(RTOS)でサポートされているセキュリティ規格の1つです。世界中のさまざまな政府がUNECE WP.29 (UNECE World Forum for Harmonization of Vehicle Regulations)の自動車用サイバーセキュリティ管理システム(CSMS)の要求事項を法制化する中、その重要性はますます高まっており、ISO 21434はUNECE WP.29 CSMSの要求事項を実践するための関連規格となります。
このフレームワークは、そのサイバーセキュリティ管理をコンセプトから本番運用まで網羅し、サイバーセキュリティの共通言語(Common Language)を定義しています。この規格は、自動車を開発する上で何が問題になりうるのか、企業はどのようにサイバーセキュリティ部門を組織し、何をチェックし、どのように問題に対処するのかを理解するのを手助けします。また組織と企業の間で混乱なくコミュニケーションをとるためには、同じ用語を使うことが重要となるので、サイバーセキュリティのリスクで使われる用語も定義しています。例えば、アセット(Asset)とは、サイバーセキュリティの特性の1つであり、被害の対象となりえるもの、と定義されています。
ISO 21434はサイバーセキュリティ部門の組織化にも役立ちます。サイバーセキュリティには、運用と脆弱性開示のすべてを網羅したポリシーを必要としています。また、このポリシーによって、何がサイバーセキュリティ部門の責任範囲となるのかを定義します。
ISO 21434は、意図的に特定の技術、特定の方法、システムへの言及を避けています。その一方で、ライフサイクルマネジメントについてより多くのことをカバーしています。
製品には開発からテスト、量産、運用までを含んだライフサイクルがあります。従来のソフトウェア安全管理は量産後のことはあまり考えられていませんでした。開発が終わって認証されれば、そのコードは凍結されてしまうからです。一方、ライフサイクルマネジメントは、生産後も含めたより広い範囲をカバーしています。具体的には、規格の中ではVモデルが参照されており、開発者が開発サイクルの中でサイバーセキュリティ評価をどのように適用するかが記述されています。また、運用・保守もライフサイクルの一部であるとされています。各ライフサイクルでは、リスクアセスメントを実施しなければならなりません。
サイバーセキュリティを進める上で、リスク評価は重要です。ISO 21434では、アセット(用語として定義された意味でのアセットとなります)の特定、脅威のシナリオ、リスクの評価を行うためのガイダンスを提供しています。先に述べたように、アセットとは脅威から守るべきものです。例えば、利用者の個人情報、ブレーキシステム、電動ミラー、カメラなどの安全上重要な機能などがアセットといえます。それぞれのアセットには、何らかの脅威のシナリオがあり、その結果として損害が発生する可能性があります。
リスク評価の例として、車両システムに侵入する方法にはどのようなものがあるでしょうか？ その方法を実行するには遠隔操作によって可能なのか、あるいは攻撃者は車両に非常に近い場所にいる必要があるのか、それとも物理的に車両に触れる必要があるのでしょうか？ 難易度によりリスクも変化します。
安全性に直結するアセットもあれば、そうでないアセットもあります。攻撃者がインフォテインメントシステムからユーザーの個人情報を盗んだとしましょう。これは大きな問題ではありますが、自動車走行における安全上の問題にはなりません。電動ミラーが動かなくなった場合はどうでしょうか？ 車両の動作に影響がありますが、即事故につながるような重大な故障ではない可能性があります。ブレーキシステムが作動しなくなった場合はどうでしょうか？ これは重大な故障であり、運転者あるいは他者が重傷を負う可能性があります。このように、ISO21434はリスクアセスメントを整理し、影響評価などのツールを提供しています。
最高の製品はベストプラクティスから生まれる
製品ライフサイクルの管理を容易にするためには、適切なツールを使用することが重要です。Green Hills Softwareは、INTEGRITY RTOSとしてISO/SAE 21434とUNECE WP.29に対応してきました。OEMとそのティア1サプライヤーから信頼されているINTEGRITY RTOSは、強固なパーティショニング・アーキテクチャで構築されており、組み込み開発者はセキュリティ、安全性、信頼性、パフォーマンスに関する要求を満たすことができます。
また、INTEGRITYはハードウェアメモリ保護機能を使用して、組み込みアプリケーションを分離して保護することも可能です。セキュアなパーティションは、OSとユーザータスクを保護することを保証します。Linuxのような汎用OSに比べて分離が明確であり、通常カーネルで一括管理されているリソースも分離されています。例えば、ヒープが分離されているため、あるアプリケーションでのメモリリークが他のアドレス空間に影響を与えることはありません。アプリケーション間の干渉が最小限に抑えられているため、リスク評価が容易になり、リスクの軽減や優先順位をつけるための選択肢がより多くなります。
OSに限ったことではありませんが、開発ツールはサイバーセキュリティのための安全・安心なシステムを構築するための重要な要素です。
ISO 21434では、MISRA(Motor Industry Software Reliability Association)のC言語がリスクを軽減するために役立つことなど、いくつかのコーディングガイドラインに言及しています。MISRAは、C言語の曖昧さや一般的な言語の間違いの影響を受けやすいために避けるべき側面を特定するために設計されています。例えば、次のコードを見てみましょう。
if (flag && (total=num++)コードの本来の意図は、"total = num++"ではなく、"total == num++"であると思われます。プログラマは"="の文字を1つ入れ忘れています。その結果、コードはプログラマの意図した通りには実行されません。プログラマが間違いに気づいて「=」を「==」に変更したとしても、「num」は増えるのでしょうか？ フラグがfalseの場合、"num"は増加しないので、答えは「増えるときもあれば増えない時もある」です。MISRAのガイドは、このようなミスを減らすのに役立ちます。
MISRA Cはソフトウェア開発者のためのガイドラインではありますが、コンパイラの仕様書ではありません。そのため、開発者が自分で検査を行う必要がある場合には、コストがかかることになります。そのため、一部のステップを自動化し、一貫して実施する必要があります。
INTEGRITYシリーズの中で、INTEGRITY-178はEAL 6+ High Robustnessを取得しています。共通基準 EALはEvaluation Assurance Levelの略で、National Information Assurance Partnership (NIAP)によって認定されています。WindowsやLinuxなどの他のOSではEAL 4+が認定されていますが、これは「システムのセキュリティを破ろうとする不注意やカジュアルな試み」を意味しています。EAL 6+は「巧妙で資金力のある攻撃者からの防御を提供する高い堅牢性のシステム」と表現されています。
OSがセキュアであっても、自動車メーカーはコストを最小限に抑えるために、LinuxやAndroid、WindowsなどのゲストOS上で動作することが多いサードパーティ製やオープンソースのライブラリを使用する必要があります。このリスクを軽減するために、INTEGRITYはネイティブで動作するコードを隔離し、ゲストOSが必要な場合には安全な仮想環境をINTEGRITY Multivisorが提供し、ゲストOSへのセキュリティ侵害がシステム内で動作する他のソフトウェアに影響を与えないようにしています。
先ほど話した重要システムへの一般的な侵入方法を考えてみましょう。ハッカーは、主要なOSにあるエクスプロイトの1つを利用します。Androidのようなハブシステムに侵入すると、最終的にはCANバスを介して安全性に関わるコンポーネントにたどり着こうとします。あるいは、パスワードや鍵などの重要な情報を盗み出そうとします。
INTEGRITYでは、物理信号とデバイスドライバ間のすべてのデータを監視/フィルタリングする仮想デバイスドライバを提供することができます。これにより、ゲストOSが侵入された場合でも、ハードウェアを分離することなく最悪の事態を防ぐことができます。
図4に示すように、INTEGRITY RTOSの信頼されたリアルタイムと分離パーティションアーキテクチャは、ミッションクリティカルなリアルタイムソフトウェア機能と並んで、複数の任意のゲスト操作システムを実行することができます。
アプリケーションとゲストOSは、厳密なアクセス制御モデルに従って、1つまたは複数のコアにまたがって効率的にスケジュールされ、互いに効率的に通信し、GPUやEthernetなどのシステム周辺機器を共有することができます。
分離されたアーキテクチャを使用することで、INTEGRITYはパーティション間の明確な分離を提供することができます。もし限られたモジュールだけが車両バスインタフェースと接続されているとすれば、1つのハードウェア内にもかかわらずシステム分離と高セキュリティを実現しています。
まとめ
外部デジタルインタフェースの数が増加し、さまざまなソフトウェアアプリケーションやオペレーティングシステムが使用されている現代の自動車は、ハッカーにとって大きな攻撃対象となっています。脆弱性を特定して対策を講じたとしても、システムを更新して大規模に安全に修正プログラムをインストールすることは非常に困難です。
2021年に発行が予定されている ISO/SAE 21434規格は、自動車のサイバーセキュリティに特化したフレームワークを提供します。ISO 21434は、(現在、世界中で採用されつつある)UNECE WP.29 CSMS要求事項を実行に移すために重要となります。そのため、自動車アプリケーションで使用される組込みシステムを開発する際には、ISO 21434をサポートするRTOSと互換性のある開発ツール群を使用して、セキュリティを確保することが不可欠となるでしょう。
