わたしたちの戦いは、血肉に対するものではなく、もろもろの支配と、権威と、やみの世の主権者、また天上にいる悪の霊に対する戦いである。ーーエペソ人への手紙 6:12
最初の章：預言者の到来
技術の神が誕生して以来、フリーソフトウェア／ファームウェア／ハードウェアのコミュニティは数多くの敵と対峙してきましたが、Intel ME（Management Engine）は最も隠密な敵の一つとして存在しています。Intel MEは、x86プラットフォームのチップセット（PCH）内に組み込まれた、独立した完全なソフトウェア・ハードウェアシステムです。2006年にx86チップセットへ統合（AMT 2.0）されて以来、鋭い監視の目が注がれてきました。
2009年のBlackhatカンファレンスでは、ITL（Invisible Things Lab）のRafal Wojtczuk氏とAlexander Tereshkin氏が、特定のDMAメモリを注入することでAMT/MEの脆弱性を悪用できることを公開しました。これが、Ring -3ルートキットの可能性が初めて明らかになった瞬間でした。当時はIntelがTPM/TXTを強く推進していた時期でもあり、ITLは技術的評価の観点からセキュリティコミュニティに重要な情報を提供しました。Ring 0より下層のセキュリティ研究領域において、ITLはまるで預言者のような存在でした。彼らの継続的な発見は、その後のフリーファームウェアコミュニティにとって重要な参考資料となっています。
注：特権レベルの階層を分かりやすく示すため、ITLはオペレーティングシステムのカーネルをRing 0、ハイパーバイザーをRing -1（VM層の永続性はRing 0に直接対応）、UEFI/SMMをRing -2（通常、Ring 0のページテーブル分離やRing -1のシャドウページテーブル、EPT、チップセットIOMMU/Vt-dの標準的な防御はRing -2にはほとんど無効）、そしてIntel MEをRing -3と位置付けています。
影の刃の誕生
2009年以降、研究者たちはIntel MEの特定コードモジュール、特にAMTに着目し、様々な技術的観点から精力的に解析を続けてきました。その結果、脆弱性や潜在的なセキュリティリスクが次々と発見されました。しかし、これらの発見は長期間にわたり業界から大きな注目を集めることはありませんでした。この分野に積極的に取り組んでいたのは、オープンファームウェアコミュニティ内のごく一部のハッカーだけでした。残念ながら、詳細な技術評価や包括的な防御戦略は依然として不足していました。
しかし2014年、Patrick Stewinの論文が「DAGGER」と呼ばれるルートキットに光を当てました。このDAGGERはキーロガーとして周辺機器の形で機能し、テストのために2009年ITLで発見された脆弱性を利用していました。特筆すべきは、DAGGER（＝影の刃）がh4rdenedzer0による「Hardening the COREs」スキームの中で、ファームウェアセキュリティの礎となったことです。
影を狩りの追跡
2016年まで、フリー／オープンファームウェアコミュニティの主流アプローチは、Intel MEのすべてのコードモジュールとデータを完全に削除することでした。しかし、広範な研究とテストの結果、重大な課題が明らかになりました。Core 2世代のチップセットではMEの消去が成功しましたが、Nehalem／Westmere以降のチップセットでは、MEコードモジュールを削除すると30分後にマシンが自動的にシャットダウンしてしまいました（それでも30分ごとに再起動する不便さを受け入れた少数のユーザーもいましたが -_-）。この問題は長年コミュニティの悩みの種となっていました。
2016年9月、Trammell HudsonはME領域の最初の4KBを削除してもシャットダウンが発生しないことを発見しました。その直後、FTPRパーティションだけを残し他のコードモジュールを削除することで、x230のシャットダウンを防げることも判明しました。この進展を受けて、Nicola CornaとFederico Amedeo Izzoが2016年11月にツールを開発し、大部分のコードモジュールを効果的に削除し、FPTRパーティション付きのFPTを作成できるようになりました。これは現在のme_cleanerの前身となるものです。テスト段階ではh4rdenedzer0がほぼすべてのラウンドに積極的に参加し、同時期にメンバーの一人がロシアで開催されたセミナーにも出席しました。その調査により、Intel ME上で動作する一部のアプリケーションが、フリーファームウェアコミュニティや企業の既存運用環境に深刻な脅威をもたらしていることが判明しました。この認識が、h4rdenedzer0を中心に、より多くのセキュリティ専門家やフリーソフトウェアコミュニティのメンバーがIntel MEとの戦いに参加するきっかけとなりました。
複数のx86デバイスでNicolaとFedericoのツールの実行に成功した後、h4rdenedzer0は両作者に連絡を取り、コードをGitHubに公開することを提案しました。また、より多くの個人や企業がコミュニティに参加し、テストやリバースエンジニアリングに取り組むよう呼びかけました。その後、このツールは正式に「me_cleaner」と命名されました。
この期間、h4rdenedzer0はさまざまなモデルで広範なテストを行い、その調査結果を積極的に公開しました。コミュニティのさらなる参加を促進するため、標準化された操作ドキュメントもリリースされ、同月中にIT業界からの注目やメディア報道を集めました。
1か月後の2016年12月、ハンブルクで開催された欧州最大のハッカー会議「33C3」において、フリー／オープンファームウェアコミュニティ主催のcorebootワークショップが開かれ、数百人の参加者が持ち込んだモデルでのテストに成功しました。この一連の出来事がきっかけとなり、2017年にはIntel MEをめぐるコミュニティ活動がさらに活発化していきました。
全面戦争
フリーソフトウェアコミュニティからの関心が高まる中、Intel MEへの注目も急速に集まりました。この動きは、リバースエンジニアリング分野で高い実力を持つロシアのセキュリティ研究者たちの関心も引き寄せました。2017年3月、Dmitry SklyarovはIntel MEのリバースエンジニアリングに関する詳細を公開し、最新バージョンのIntel MEの構造についてより深い理解が得られるようになりました。それ以前に私たちは、2015年のSkylake世代x86プロセッサの大きな特徴であるSGXに注目していました。SGXはMEの複数の機能に依存して実現されており、ARC*/Sparcの性能問題に加え、MEv11でx86 CPUが採用された大きな要因と考えられます。Dmitryの解析により、MEv11上で動作するOSは従来のARC*アーキテクチャで使われていたThreadXではなく、MINIXをベースにしたカスタムシステムであることが判明しました。
当時、me_cleanerはSkylake以降のプロセッサで十分なテストが行われておらず、さらなるコードモジュールの調整が必要でした。そのため、h4rdenedzer0のメンバーがme_cleanerのメンテナーにテスト機材購入費として2,600ユーロを寄付しました。数か月に及ぶバグ修正と厳格なテストの結果、me_cleanerはMEv11およびMEv12（Skylake/Kabylake/Cannonlake）のクリーン作業を達成しました。Skylake以降のプラットフォームでは、MEの実装は主にRBE、KERNEL、SYSLIB、BUPの各モジュールのみが残されています。
2017年8月、Mark ErmolovとMaxim Goryachyはリバースエンジニアリングによって、NSAが防御目的で利用していたMEの隠しキルスイッチを発見しました。彼らは、MEを完全に無効化できることを明らかにしました。このキルスイッチ（HAP、ARCベースのMEや旧世代ではAltMeDisable、ICH_MeDisable、MCH_MeDisable、MCH_AltMeDisableなどが相当）は、記述子のPCHSTRP0フィールドに隠されています（旧バージョンでは該当ビットの位置が異なります。詳細はme_cleanerのソースコードを参照）。このビットは公式ドキュメントには記載されていません。興味深いことに、HAPは「High Assurance Platform」の略で、NSAが次世代セキュリティ防御システム構築のために推進したプロジェクトです。NSAのマシンではHAPビットが有効化され（MEはBringUPの初期化後に無効化）、世界中の大多数のx86マシンではMEがデフォルトで稼働しているため、MEはバックドアまたは「バックドアの共犯者」として基幹インフラに重大なリスクをもたらしていることを意味します。
高いセキュリティが求められる業務においては、主CPU上のOSカーネルの安全性が確保できないため、コア業務を外部CPU上のOSに移しても根本的な解決にはならず、新たなリスクや監査不可能な問題が生じます。Linuxカーネルも脆弱性があるものの、オープンソースであり公開監査が可能です。一方で、ME関連のソフトウェアやハードウェアはほとんどの人にとって非公開であり、x86プラットフォームにおける監査性の問題は依然として解決されていません。
2017年11月、Googleのエンジニアはドイツで開催された欧州corebootカンファレンスにおいて重要な発表を行いました。彼らは、Intel MEおよびオープンソースでないUEFIファームウェアの実装を重要な業務用マシンから排除する方針を示しました。この決定は、Intel MEに関連するリスク評価の結果に対するGoogleの懸念に基づくものでした。
2017年12月には、ロシアのセキュリティ研究者がBlackhat EUで注目すべきデモンストレーションを行いました。彼らはBringUP（BUP）フェーズにおけるIntel MEの「無動作」を公開し、それが特定の攻撃チェーンを可能にすることを示しました。現時点で、Intelが意図的にこの脆弱性を残したという決定的な証拠はありません。HAPを有効にしても、この脆弱性は防御できません。カーネルおよびファームウェアレベルでの対策が必要です。サーバーにおいては、この脆弱性とSA-00075（AMTの脆弱性）を組み合わせることで、2015年から2017年に製造されたマシンをリモートで標的にすることが可能です。この脆弱性は、2009年にITLのファームウェアセキュリティの先駆者たちがパラダイムシフトの基礎を築いて以来、新たな時代の到来を示しています。これは、Ring-3レベルにおける攻撃と防御のコスト効率時代の幕開けでもあります。
2018年6月、ロシアのセキュリティ研究者はIDLMコードモジュールの解析中にさらなる発見をしました（詳細はIDLMコードモジュール解析ドキュメント参照）。特に、Intelは一部のMEコードモジュールのセキュリティを重視していた一方で、IDLMのような高リスクモジュールには無頓着であることが明らかになりました。ロシアのセキュリティ研究者は、この無頓着さがIntelによる意図的なものかもしれないと推測しています。多くのME関連コードモジュールでも同様の傾向が見られます。
解決策は？
高セキュリティ環境では、MEシステムおよびその上で動作するアプリケーションの利用を避けることが推奨されます。しかし、金融や通信などの業界では、x86プラットフォームの短期間での全面的な置き換えは非常に困難です。それでも、各企業は自社の業務の重要度や優先度を評価し、MEモジュールの削除を検討することができます。
長期的な観点では、2つの重要なポイントがあります。第一に、マイクロコードやMEを含むファームウェアの監査性の欠如は、x86プラットフォームにおける大きな障壁となっています。Intelがこの問題を包括的に解決する可能性は低いと考えられます。一方で、チップ業界全体はRISC-Vのようなオープン命令セットCPUアーキテクチャの登場により、「3.0」と呼ばれる新時代を迎えつつあります（2023年時点の更新：RISC-Vにも監査性の課題は残っています）。この流れによって、チップやファームウェアの監査性問題は徐々に解消されていくでしょう。本当の意味でハードウェアとファームウェアの自由を実現するには、ハードウェアとファームウェアの両方が監査可能であることが不可欠です。
ME情報
2006年～2014年：
- ノートパソコンおよびデスクトップでは、Arc*プロセッサー上でThreadXオペレーティングシステムを実行する標準的なME実装が採用されていました。
- Nehalem/Westmereシリーズ以降、MEを完全に削除することはできなくなりました。
- 組み込み機器では、Sparcプロセッサー上で動作するTXEが使用されており、オペレーティングシステムは不明なRTOSです。
- サーバーでは、Arc*プロセッサー上でThreadXオペレーティングシステムを実行するSPSが採用されていました。
2015年～現在：
- x86プロセッサー上で動作するMinix 3をベースにしたカスタムOSが採用されています。