By Jason Yuan (Engineer, Automotive)
10年以上にわたり、OTA（Over-The-Air）アップデートは車両のライフサイクルを通じてその機能を安全に、そして最新の状態に維持するために欠かせないものとなっています。OTAは、フリート規模で修正プログラムを効率的に配信する手段です。しかし、車両の安全性を維持するためのものにもかかわらず、攻撃対象も拡大しています。
この記事では、リサーチャーが車載インフォテインメント（IVI）システム用の正規のAndroid OTAアップデートを解読し、コードベース全体を公開してサイレント・ペイロード・インジェクションの可能性を示した最近の投稿事例(※中国語サイト) を検証します。このプロセスを理解することは、検証制御を強化し、アップデートが侵害された場合の実際の影響範囲を評価するのに役立ちます。
安全なOTAアップデートが重要な理由
OTAアップデートは、インフォテインメントからパワートレインに至る電子制御ユニット（ECU）へのリモートパッチを可能にし、自動車メーカー（OEM）が車両ソフトウェアを維持・強化する方法を変革しました。OTA配信は、リコールコストを大幅に削減し、機能展開を加速し、UN-R156やISO 24089のような進化する規制の要件に応えます。OTAアップデートへの依存が高まるにつれ、OEMは、すべてのアップデートが確実に配信され、完全性が検証され、安全にロールバックできることを保証しなければなりません。そのためには、ハードウェアクリティカルなサブシステムと同等のエンジニアリングの厳密さとテスト規律でアップデートチャネルを扱う必要があります。
攻撃の連鎖
この投稿を行ったリサーチャーは、完全なシステムアップデートを行うことなく、OTAパッケージから目的のAPK（Android package kit）ファイルを直接抽出したいと考えていました。しかし、OTAパッケージをダウンロードしたところ、それが暗号化されていることにすぐ気づきました。そこで、復号化メカニズムがアップデータ自体に組み込まれているに違いないと推測し、オンボードのアップデートアプリをリバースエンジニアリングする作戦に出ました。
アプリをリバースエンジニアリングしたところ、リサーチャーは、静的トークンと埋め込みシードという2つのハードコードされた値を組み合わせて、アップデートパッケージの解読に必要なAES（Advanced Encryption Standard）キーと初期化ベクトル（IV）を生成するネイティブ関数を発見しました。
AndroidのネイティブライブラリをエミュレートするオープンソースのフレームワークであるUnidbgでこの鍵生成ルーチンをエミュレートすることで、リサーチャーはコアペイロードのロックを解除するために必要な暗号化パラメータを正確に復元しました。そこから、標準的なsparseimageとAPKツールを使う事で、アプリケーションの完全なソースコードが暴露されました。
この攻撃を可能にした重大な原因は、復号化ロジックと定数がバイナリに直接ハードコードされており、難読化処理が施されていなかったという設計上の欠陥でした。この欠陥は、ダウンロードされたアップデートのロックを解除する鍵を攻撃者に与えてしまいます。
図1. OTAアップデートの解読に使用された攻撃チェーン
この攻撃の軽減策としてOEMが取れる方策は、アップデートバイナリからハードコードされた秘密情報を削除し、鍵の導出を安全なハードウェアモジュールに移行し、重要なアップデータ・コンポーネントにコードの難読化または暗号化を採用して、リバース・エンジニアに対するハードルを上げることです。
フリート全体への影響
攻撃者がOTAパッケージをソースコードに変換すると、パワートレインのロジックからテレマティクス通信に至るまで、コアシステム機能を即座に把握することができます。例えば、ソフトウェアスタック全体に非純正ソフトウェアが混入可能になってしまうことにより、改造されたIVIアプリケーションや遠隔監視やリモート操作に関わる重要な車載モジュールを介してセンサーデータの改ざんなどのハッキングが可能になります。多くのOEMは、複数のプラットフォームや年式にまたがって同じアップデート方式を再利用しているため、単一の OTAパッケージを侵害すれば、脆弱性は瞬く間にフリート全体に広がり、ひとつの侵害がエクスプロイト（脆弱性悪用）の連鎖反応に変わる可能性があります。
安全なOTAアップデートの鍵
ここでの教訓は、OTAアップデートを避けるべきだということではありません。リモートアップデートがなければ、現代のコンプライアンス目標を達成することは不可能です。むしろ、すべてのビルドやアップデートは、偽造不可能な信頼の連鎖を通過させるべきで、車両内の各システム（つまり各ECU）が実行時にもこの信頼を検証し、強化するようでなければなりません。
OEMは、アップデートの整合性をリアルタイムで監視するために継続的な遠隔測定を実施し、サードパーティのコンポーネントと暗号化の完全性を検証するために包括的なソフトウェアインベントリ（ソースコード管理）を維持し、アップデートパイプライン全体の頻繁な攻撃的テストを実施する必要があります。車両セキュリティ・オペレーション・センター（VSOC）に整合性アラートとテスト結果を統合することで、改ざんを迅速に特定して是正し、車両のライフサイクル全体を通じて車両ソフトウェアを安全に保つことができます。
車両のSDV（ソフトウェア・デファインド・ビークル）化が進むにつれて、OTAアップデートは車両のセキュリティにとってより重要になると同時に、攻撃者にとってもターゲットとしてより魅力的なものとなっていきます。開発から配備に至るまで、OTAエコシステムのあらゆる層を強化することは、現在および将来の脅威から車両を保護するために不可欠なものとなっていくでしょう。
