[論文レビュー] Taking a Look into Execute-Only Memory
この論文は、複数の参加者によるマイコン開発を想定したハードウェアベースのファームウェア保護機構である実行専用メモリ(XOM)が、根本的に不安全であることを示している。著者らは、CPU状態やSRAMといった共有ハードウェアリソースを悪用することで、サイドチャnel分析とガジェットベースのコード抽出を用いた自動的手法を開発し、NXP や Texas Instruments を含む複数のベンダーのデバイスに対して実用的な攻撃を成功させた。
The development process of microcontroller firmware often involves multiple parties. In such a scenario, the Intellectual Property (IP) is not protected against adversarial developers which have unrestricted access to the firmware binary. For this reason, microcontroller manufacturers integrate eXecute-Only Memory (XOM) which shall prevent an unauthorized read-out of third-party firmware during development. The concept allows execution of code but disallows any read access to it. Our security analysis shows that this concept is insufficient for firmware protection due to the use of shared resources such as the CPU and SRAM. We present a method to infer instructions from observed state transitions in shared hardware. We demonstrate our method via an automatic recovery of protected firmware. We successfully performed experiments on devices from different manufacturers to confirm the practicability of our attack. Our research also reveals implementation flaws in some of the analyzed devices which enables an adversary to bypass the read-out restrictions. Altogether, the paper shows the insufficient security of the XOM concept as well as several implementations.
研究の動機と目的
- 物理的および特権アクセスを持つ攻撃者に対する敵対的開発者を防ぐために、実行専用メモリ(XOM)が保護メカニズムとして有効であるかを評価すること。
- CPUレジスタやSRAMといった共有ハードウェアリソースのサイドチャnel分析によって、XOM保護ファームウェアが回復可能かどうかを調査すること。
- 観察可能な状態遷移とコードガジェットの悪用を用いて、XOM保護ファームウェアを自動回復する手法を開発・検証すること。
- XOM対応マイコンの実装上の欠陥を同定・悪用し、読み出し制限を回避すること。
- 複数参加者による埋め込み開発におけるファームウェアセキュリティに与える広範な影響を評価し、TEEのような強力な隔離メカニズムの導入を提言すること。
提案手法
- 著者らは、制御された実行環境下でXOM保護マイコンの挙動を分析し、命令実行中のCPUレジスタ状態とSRAM内容を観測することで、秘密のコードを推定した。
- CMSIS などのライブラリに既存のコードパターンを活用して、制御されたメモリアクセスを可能にする「ガジェット」(特定の命令列)を同定・利用した。
- 命令レベルの遷移を検出するためのタイミングベースのサイドチャnel攻撃を適用し、観察可能な状態変化からコードの再構築を可能にした。
- 割り込み駆動の実行を用いて、XOM保護領域における状態遷移をトリガーし、観測する手法を自動化した。
- NXP Kinetis や Texas Instruments MSP432P4 などの複数のマイコンプラットフォームで、カスタムガジェットを構築・実行することで、保護されたコードの抽出を実証した。
- コード抽出を加速するために、Data Watch and Trace(DWT)コンponents などのデバッグ・トレース機能の分析を活用し、回復プロセスを強化した。
実験結果
リサーチクエスチョン
- RQ1共有ハードウェア状態遷移のサイドチャnel分析によって、XOM保護ファームウェアは回復可能か?
- RQ2XOM保護メモリへの不正アクセスを可能にする特定の命令列(ガジェット)は何か?(ハードウェアによる読み出し保護にもかかわらず)
- RQ3XOM対応マイコンの実装上の欠陥は、意図された読み出し制限を回避可能か?
- RQ4異なるマイコンアーキテクチャーやベンダー間で、自動コード回復がどの程度達成可能か?
- RQ5実世界の埋め込みシステムにおいて、このような攻撃の実用的制限と成功確率は何か?
主な発見
- XOMの概念自体が根本的に不安全である。なぜなら、共有CPUおよびSRAMリソースを通じたサイドチャnel漏洩を完全に隔離しないからである。
- NXP Kinetis デバイスでは、1つの非ロード命令に続くロード命令をガジェットとして用いることで、XOM保護ファームウェアを成功裏に回復した。
- MSP432P4 デバイスでは、2命令のガジェット(ストア後にロード)を用いてXOM領域をアンロックし、コードを抽出した。これは、アンロックメカニズムの再ロック挙動における脆弱性を悪用した。
- 複数のデバイスで、コード終了後にアクセスが早期にロックされるなど、XOM保護を回避可能な実装上の欠陥を発見した。
- 回復プロセスは自動化され、複数のベンダーおよびアーキテクチャで実証され、現実の攻撃条件下でも完全なファームウェア抽出が可能であることを示した。
- 本研究の結論として、XOM単体では複数参加者開発におけるファームウェア保護に不十分であり、適切なセキュリティを確保するには、TEEのようなハードウェアバックド隔離メカニズムが必要である。
より良い研究を、今すぐ始めましょう
論文設計から論文執筆まで、研究時間を劇的に削減しましょう。
クレジットカード登録不要
このレビューはAIが作成し、人間の編集者が確認しました。