🏟️ 👨🏼‍🎓 👼🏻 シュレディンガートラステッドブート。 Intelブートガード 👩🏿‍🔧 🧕🏾 🛀🏻

低レベルに下げて、x86互換コンピュータープラットフォームのファームウェアのセキュリティについて話すことを再度提案します。今回、調査の主な要素は、Intel Boot Guard（Intel BIOS Guardと混同しないでください！）、信頼できるBIOSブート用のハードウェアでサポートされたテクノロジーであり、コンピューターシステムベンダーは生産段階で永続的にオンまたはオフにできます。さて、私たちはすでに研究の秘theを知っています。リバースエンジニアリングによってこの技術の実装を薄くカットし、そのアーキテクチャを記述し、文書化されていない詳細で埋め、攻撃ベクトルで味付けして混ぜ合わせます。長年にわたり、いくつかのベンダーの生産におけるクローンの間違いにより、潜在的な攻撃者がこのテクノロジーを使用して、システム内で（プログラマーでさえ）削除できない隠されたルートキットを作成できるという話に火を付けましょう。

ちなみに、この記事はZeroNights 2016会議とDefCon Russiaの第29回会議のレポート「Guardian of rootkits ：Intel BootGuard」に基づいています（両方のプレゼンテーションはこちらです）。

Intel 64アーキテクチャを備えたコンピュータープラットフォームのファームウェア

まず、質問に答えましょう。Intel64アーキテクチャを備えた最新のコンピュータープラットフォームのファームウェアは何ですか？もちろん、UEFI BIOS。しかし、そのような答えは正確ではありません。このアーキテクチャのデスクトップ（ラップトップ）バージョンを示す図面を見てみましょう。

基礎はたくさんあります：

メインコアに加えて、グラフィックコア（すべてのモデルではない）とメモリコントローラー（IMC、統合メモリコントローラー）を備えたプロセッサー（CPU、中央処理装置）。
チップセット（PCH、プラットフォームコントローラーハブ）。周辺機器とやり取りし、サブシステムを管理するためのさまざまなコントローラーが含まれています。その中でも悪名高いIntel Management Engine（ME）は、ファームウェア（Intel MEファームウェア）も備えています。

上記に加えて、ラップトップには、電源サブシステム、タッチパッド、キーボード、Fnキー（画面の明るさ、音量、キーボードのバックライトなど）の操作を担当する統合コントローラー（ACPI EC、高度な制御および電源インターフェイス組み込みコントローラー）が必要です。）など。また、彼は自分のファームウェアも持っています。

したがって、上記のファームウェアの組み合わせは、共有SPIフラッシュメモリに格納されているコンピュータープラットフォームのファームウェア（システムファームウェア）です。このメモリのユーザーがどこにいるのか混乱しないように、このメモリの内容は次の領域に分割されます（図を参照）。

UEFI BIOS;
ACPI ECファームウェア（Skylakeプロセッサマイクロアーキテクチャ（2015）から別の領域が登場しましたが、実際の使用例はまだ見ていません。そのため、組み込みコントローラーのファームウェアはUEFI BIOSの一部です）。
Intel MEファームウェア。
組み込みGbEネットワークアダプター（ギガビットイーサネット）の構成（MACアドレスなど）。
フラッシュ記述子（フラッシュ記述子）-フラッシュメモリのメイン領域。他の領域へのポインターと、それらへのアクセス許可が含まれます。

領域へのアクセスの差別化は（指定された許可に従って）SPIマスターバス（このメモリへのアクセスに使用されるチップセットに組み込まれたSPIコントローラー）によって処理されます。 Intelが（セキュリティ上の理由で）推奨値にアクセス許可を設定している場合、SPIフラッシュメモリの各ユーザーは自分の地域のみにフルアクセス（読み取り/書き込み）できます。そして、残りは読み取り専用またはアクセス不能です。既知の事実：多くのシステムでは、CPUはUEFI BIOSおよびGbEへのフルアクセス、フラッシュ記述子への読み取りアクセスのみを持ち、Intel ME領域へのアクセスはまったくありません。なぜ多くはあるが、まったくないのか？推奨されるのはオプションです。記事で詳しく説明します。

コンピュータプラットフォームのファームウェアを変更から保護するためのメカニズム

明らかに、コンピュータープラットフォームのファームウェアは、侵害の可能性から保護する必要があります。これにより、潜在的な攻撃者がそのプラットフォームに足を踏み入れ（OSの更新/再インストールに耐える）、最も特権的なモードでコードを実行できるようになります。もちろん、フラッシュメモリのSPI領域へのアクセスを制限するだけでは十分ではありません。したがって、ファームウェアを変更から保護するために、各実行環境に固有のさまざまなメカニズムが使用されます。

そのため、Intel MEファームウェアは整合性と信頼性の制御のために署名され、ME UMAメモリにロードされるたびにMEコントローラによってチェックされます。この検証プロセスは、Intel MEサブシステムに関する記事の 1つですでに検討されています。

原則として、ACPI ECファームウェアは整合性のみがチェックされます。ただし、このバイナリはUEFI BIOSに含まれているという事実により、ほとんどの場合UEFI BIOSが使用するのと同じ保護メカニズムが適用されます。それらについてお話します。

これらのメカニズムは2つのカテゴリに分類できます。

UEFI BIOS書き込み保護

SPIフラッシュ書き込み保護ジャンパーの内容の物理的保護。
チップセットのPRxレジスタを使用したCPUのアドレス空間でのUEFI BIOS領域の投影の保護。
ブロッキングは、チップセットレジスタのBIOS_WE / BLEおよびSMM_BWPビットを設定して、対応するSMI割り込みを生成および処理することにより、UEFI BIOSへの書き込みを試みます。
この保護のより高度なバージョンは、Intel BIOS Guard（PFAT）です。

これらのメカニズムに加えて、ベンダーは独自のセキュリティ対策を開発および適用できます（たとえば、UEFI BIOSアップデートでカプセルに署名する）。

特定のシステム（ベンダーによって異なります）では、上記の保護メカニズムのすべてが適用されるわけではなく、まったく適用されない可能性がありますが、脆弱に実装される可能性があることに注意してください。この記事では、これらのメカニズムとその実装の状況について詳しく説明しています。興味のある方は、 CodeRush UEFI BIOSセキュリティ記事の全シリーズを読むことをお勧めします。

UEFI BIOS認証

信頼できるブートテクノロジーについて話すとき、最初に頭に浮かぶのはセキュアブートです。ただし、外部（UEFI BIOSに関して）のコンポーネント（ドライバー、ブートローダーなど）を認証するように設計されており、ファームウェア自体は認証しません。

そのため、Bay Trailマイクロアーキテクチャ（2012）を搭載したSoCのIntelは、前述のセキュアブートテクノロジとは関係のない、ハードウェアの切断不可能なセキュアブート（検証済みブート）を実装しました。後で（2013）、このメカニズムは改良され、Haswellマイクロアーキテクチャを備えたデスクトップ向けIntel Boot Guardという名前でリリースされました。

Intel Boot Guardについて説明する前に、Intel 64ランタイムを取り上げます。これらは、組み合わせて、この信頼できるブートテクノロジーの信頼の根です。

Intel CPU

Capは、プロセッサがIntel 64アーキテクチャのメインランタイムであることを示唆しています。次の要素を持っていると、そのようになります。

マイクロコードROM-マイクロコードを保存するための不揮発性、書き換え不可のメモリ。マイクロコードは、最も単純な命令でのプロセッサ命令システムの実装であると考えられています。マイクロコードにもバグが発生します。したがって、BIOSでは、マイクロコードの更新を含むバイナリを見つけることができます（ROMは上書きできないため、ブート時にスーパーインポーズされます）。これらのバイナリのコンテンツは暗号化され、分析を大幅に複雑にします（したがって、マイクロコードの特定のコンテンツは開発者だけが知っています）。署名されて、整合性と信頼性を制御します。
マイクロコード更新の内容を解読するためのAESキー。
マイクロコード更新の署名をチェックするRSA公開キーハッシュ。
RSA公開キーハッシュ。これは、CPUがBIOSの実行を開始する前（hiマイクロコード）または何らかのイベントが発生した場合の操作中に実行できるIntelが開発したACM（認証コードモジュール）コードモジュールの署名をチェックします。

Intel ME

このサブシステムについては、ブログで2つのブログ記事が取り上げられました。この実行可能環境は、チップセットに組み込まれたマイクロコントローラーに基づいており、システム内で最も隠されており特権があることを思い出してください。

機密性にもかかわらず、Intel MEは次のような理由から信頼の根源でもあります。

ME ROM-インテルMEファームウェアの署名をチェックするRSA公開キーのSHA256ハッシュと同様に、開始コードを含む不揮発性、書き換え不可能なメモリ（更新方法は提供されません）。
機密情報を保存するAESキー。
チップセットに統合されたヒューズセット（FPF、フィールドプログラマブルヒューズ）にアクセスして、コンピューターシステムのベンダーが指定したものを含むいくつかの情報を永続的に保存します。

Intel Boot Guard 1.x

小さな免責事項。この記事で使用しているインテルブートガードテクノロジーのバージョン番号は条件付きであり、インテルの内部ドキュメントで使用されている番号付けとは無関係かもしれません。また、ここで紹介するこのテクノロジの実装に関する情報はリバースエンジニアリング中に取得されたものであり、Intelブートガードの仕様と比較すると不正確な場合があります。

そのため、Intel Boot Guard（BG）は、ハードウェアでサポートされるUEFI BIOS認証テクノロジーです。本[Platform Embedded Security Technology Revealed]、Integrityを使用したブート、またはブートなしの章の彼女の短い説明から判断すると、信頼できるブートチェーンとして機能します。そして、最初のリンクはCPU内のブートコード（マイクロコード）です。これは、RESETイベントによってトリガーされます（BIOSのRESETベクトルと混同しないでください！）。 CPUはSPIフラッシュメモリで、Intelが開発および署名したコードモジュール（Intel BGスタートアップACM）を見つけてキャッシュにロードし、検証します（CPUにはACM署名を検証する公開キーハッシュがあることが既に確認されています）。

このコードモジュールは、UEFI BIOSの小さな開始部分-初期ブートブロック（IBB）の検証を担当します。これには、UEFI BIOSの主要部分を検証する機能が含まれます。したがって、Intel BGでは、OSを起動する前にBIOSの信頼性を検証できます（セキュアブートテクノロジーの監視下で実行できます）。

Intel BGテクノロジーは、2つの動作モードを提供します（さらに、一方が他方に干渉しません。つまり、システムで両方のモードを有効にしたり、両方をオフにしたりできます）。

測定されたブーツ

測定ブート（MB）モードでは、各ブート可能コンポーネント（CPUブートROMから開始）は、TPM（Trusted Platform Module）の機能を使用して次のコンポーネントを「測定」します。最新ではない人のために、私たちは説明します。

TPMにはPCR（プラットフォーム構成レジスタ）があり、ハッシュ演算の結果は次の式に従って書き込まれます。

測 定 （ デ ー タ ） ： P C R = ハ ッ シ ュ （ P C R | ハ ッ シ ュ （ デ ー タ ） ）

$測定（データ）：PCR =ハッシュ（PCR |ハッシュ（データ））$

つまり現在のPCR値は前の値に依存しますが、これらのレジスタはRESETシステムでのみゼロにリセットされます。

したがって、MBモードでは、ある時点で、PCRは「測定」されたコードまたはデータの一意の（ハッシュ操作の制限内での）識別子を反映します。 PCR値は、一部のデータの暗号化操作で使用できます（TPM_Seal）。その後、読み込みの結果としてPCR値が変更されていない場合（つまり、「測定された」コンポーネントが変更されていない場合）のみ、復号化（TPM_Unseal）が可能になります。

検証済みブート

UEFI BIOSを変更したい人にとって最悪なのは、検証済みブート（VB）モードです。このモードでは、各ブートコンポーネントが次の整合性と信頼性を暗号で確認します。検証エラーの場合、次のいずれかが発生します。

1分から30分までのタイムアウトによるシャットダウン（ユーザーがコンピューターが読み込まれていない理由を理解し、可能であればBIOSを復元しようとする時間を確保するため）;
即時のシャットダウン（ユーザーが理解する時間がないように、さらにはそうするため）;
まっすぐな顔で作業を続けます（より重要なことがあるため安全でない場合）。

アクションの選択は、構成済みのIntel BG構成（つまり、いわゆる施行ポリシー）に依存します。これは、コンピュータープラットフォームのベンダーが特別に設計されたストレージ-チップセットヒューズ（FPF）に永続的に書き込みます。この点については、後で詳しく説明します。

構成に加えて、ベンダーは2つのRSA 2048キーを生成し、2つのデータ構造を作成します（図を参照）。

ベンダールートキーマニフェスト（KEYM、OEMルートキーマニフェスト）。このマニフェストのセキュリティバージョン番号（SVN）、次のマニフェストの公開キーのSHA256ハッシュ、RSA公開キー（ベンダールートキーの公開部分）を入れて、この署名を検証しますマニフェストと署名自体;
IBBマニフェスト（IBBM、初期ブートブロックマニフェスト）。このマニフェストのSVN、SHA256 IBBハッシュ、このマニフェストの署名を検証する公開キー、および署名自体を配置します。

OEMルートキーのSHA256公開キーハッシュは、Intel BG構成と同様に、チップセットヒューズ（FPF）に永続的に記録されます。 Intel BG構成にこのテクノロジーが含まれている場合、システム上のこの時点からBIOSを更新する（つまり、これらのマニフェストを再カウントできる）ことができるのは、OEMルートキーのプライベート部分の所有者のみです。ベンダー。

写真を見ると、そのような長い検証チェーンの必要性についてすぐに疑念が生じます。1つのマニフェストを使用することが可能でした。なぜそれを複雑にしますか？

実際、インテルはベンダーに、異なる製品ラインとルートとして異なるIBBキーを使用する機会を提供しています。 IBBキーの秘密部分がリークされると（2番目のマニフェストが署名される）、インシデントは1つの製品ラインのみに影響し、ベンダーが新しいペアを生成し、次のBIOSアップデートで再カウントされたマニフェストを含めるまでのみです。

ただし、ルートキー（最初のマニフェストが署名される）が侵害された場合、置き換えることはできません。失効手順は提供されません。このキーの公開部分のハッシュは、FPFで一度だけプログラムされます。

Intelブートガードの構成

次に、Intel BGの構成とその作成プロセスについて説明します。 Intel System Tool Kit（STK）のFlash Image ToolユーティリティのGUIで対応するタブを見ると、Intel BG構成にはベンダーのルートキーの公開部分のハッシュ、いくつかのあいまいな値などが含まれていることがわかります。 Intel BGプロファイル。

このプロファイルの構造：

typedef struct BG_PROFILE { unsigned long Force_Boot_Guard_ACM : 1; unsigned long Verified_Boot : 1; unsigned long Measured_Boot : 1; unsigned long Protect_BIOS_Environment : 1; unsigned long Enforcement_Policy : 2; // 00b – do nothing // 01b – shutdown with timeout // 11b – immediate shutdown unsigned long : 26; };

一般的に、Intel BGの構成-本質は非常に柔軟です。たとえば、Force_Boot_Guard_ACMフラグを検討してください。削除するときに、SPIフラッシュメモリ上のBGスタートアップACMモジュールが見つからない場合、信頼できるブートはありません。信頼されません。

前述のとおり、VBモードの施行ポリシーは、検証エラーが発生した場合に、信頼できないダウンロードが発生するように構成できることを既に書きました。

ベンダーの裁量でそのようなものを残す...

ユーティリティGUIは、次の「既製」プロファイルを提供します。

数	モード	説明
0	No_FVME	Intel BGテクノロジーオフ
1	Ve	VBモードが有効、タイムアウトシャットダウン
2	VME	両方のモードが有効（VBおよびMB）、タイムアウトシャットダウン
3	VM	システムをオフにすることなく、両方のモードがオンになっています
4	Fve	VBモードがオン、即時シャットダウン
5	Fvme	両方のモードが含まれ、即時シャットダウン

既に述べたように、Intel BG構成はチップセットフュージョン（FPF）のシステムベンダーによって一度だけ書き留められる必要があります-チップセット内の小さな（未検証レポートによると256バイトのみ）ハードウェア情報ストレージはIntel生産施設の外部でプログラムできます（したがって、 フィールドプログラマブルヒューズです）。

次の理由により、構成の保存に最適です。

データを格納するための1回限りのプログラム可能な領域があります（Intel BG構成が書き込まれる場所）。
Intel MEのみがそれを読み取り、プログラムできます。

そのため、特定のシステムでIntel BGテクノロジーを構成するために、ベンダーは生産中に次のことを行います。

Flash Image Tool（Intel STKから）を使用して、Intel MEリージョン（FPFのいわゆる一時ミラー）内の変数の形でIntel BGの指定された構成でファームウェアイメージを作成します。
フラッシュプログラミングツール（Intel STK製）を使用して、このイメージをシステムのSPIフラッシュメモリに書き込み、いわゆる製造モード（この場合、対応するコマンドはIntel MEに送信されます）。

これらの操作の結果として、Intel MEはMEリージョンのFPFのミラーから指定された値にFPFをコミットし、SPIフラッシュ記述子の権限をIntelが推奨する値に設定し（記事の冒頭で説明）、RESETシステムを実行します。

インテルブートガードの実装分析

特定の例を使用してこのテクノロジーの実装を分析するために、インテルBGテクノロジーの兆候について次のシステムをチェックしました。

システム	ご注意
ギガバイトGA-H170-D3H	Skylake、サポートがあります
ギガバイトGA-Q170-D3H	Skylake、サポートがあります
ギガバイトGA-B150-HD3	Skylake、サポートがあります
MSI H170A Gaming Pro	Skylake、サポートなし
Lenovo ThinkPad 460	Skylake、サポートがあり、技術が含まれています
Lenovo Yoga 2 Pro	ハスウェル、サポートなし
レノボU330p	ハスウェル、サポートなし

「サポート」とは、Intel BGスタートアップACMモジュール、上記のマニフェスト、およびBIOS内の対応するコードの存在を意味します。分析のための実装。

例として、ダウンロード元をご覧ください。ギガバイトGA-H170-D3H（バージョンF4）用のベンダーサイトイメージSPIフラッシュメモリ。

Intel CPUブートROM

まず、Intel BGテクノロジーが有効になっている場合のプロセッサーの動作について説明しましょう。

復号化されたマイクロコードのサンプルが見つからなかったため、以下で説明するアクションの実装方法（マイクロコードまたはハードウェア）は未解決の問題です。それにもかかわらず、最新のIntelプロセッサがこれらのアクションを実行できるという事実は事実です。

RESET状態を終了した後、プロセッサは（フラッシュメモリの内容が既にマップされているアドレス空間で）FITテーブル（ファームウェアインターフェイステーブル）を見つけます。それを見つけるのは簡単です、それへのポインターはFFFF FFC0hで書かれています。

この例では、このアドレスにFFD6 9500hの値があります。このアドレスに目を向けると、プロセッサはFITテーブルを確認し、その内容はレコードに分割されます。最初のエントリは、次の構造のヘッダーです。

 typedef struct FIT_HEADER { char Tag[8]; // '_FIT_ ' unsigned long NumEntries; // including FIT header entry unsigned short Version; // 1.0 unsigned char EntryType; // 0 unsigned char Checksum; };

理由は不明ですが、チェックサムはこれらのテーブルで常に計算されるとはほど遠いです（フィールドはゼロのままです）。

残りのエントリは、BIOSが実行される前にペアリング/実行する必要があるさまざまなバイナリを示します。従来のRESET-vector（FFFF FFF0h）に切り替える前。そのような各レコードの構造は次のとおりです。

 typedef struct FIT_ENTRY { unsigned long BaseAddress; unsigned long : 32; unsigned long Size; unsigned short Version; // 1.0 unsigned char EntryType; unsigned char Checksum; };

EntryTypeフィールドは、このレコードが指すブロックのタイプを示します。私たちはいくつかのタイプを知っています：

 enum FIT_ENTRY_TYPES { FIT_HEADER = 0, MICROCODE_UPDATE, BG_ACM, BIOS_INIT = 7, TPM_POLICY, BIOS_POLICY, TXT_POLICY, BG_KEYM, BG_IBBM };

エントリの1つがIntel BGスタートアップACM binarの場所を指していることは明らかです。このbinarのヘッダー構造は、Intelが開発したコードモジュール（ACM、マイクロコードの更新、Intel MEコードセクションなど）に典型的です。

 typedef struct BG_ACM_HEADER { unsigned short ModuleType; // 2 unsigned short ModuleSubType; // 3 unsigned long HeaderLength; // in dwords unsigned long : 32; unsigned long : 32; unsigned long ModuleVendor; // 8086h unsigned long Date; // in BCD format unsigned long TotalSize; // in dwords unsigned long unknown1[6]; unsigned long EntryPoint; unsigned long unknown2[16]; unsigned long RsaKeySize; // in dwords unsigned long ScratchSize; // in dwords unsigned char RsaPubMod[256]; unsigned long RsaPubExp; unsigned char RsaSig[256]; };

プロセッサはこのバイナリをキャッシュにロードし、検証して起動します。

Intel BGスタートアップACM

このACMの動作を分析した結果、次のことを行っていることが明らかになりました。

Intel MEからチップセットヒューズ（FPF）に記録されたIntel BGの構成を受け取ります。
KEYMおよびIBBMマニフェストを見つけ、それらを検証します。

これらのマニフェストを見つけるために、ACMはFITテーブルも使用します。このテーブルでは、2種類のレコードが割り当てられて構造データを示します（上記のFIT_ENTRY_TYPESを参照）。

マニフェストについて説明しましょう。最初のマニフェストの構造には、いくつかのあいまいな定数、2番目のマニフェストからの公開キーのハッシュ、およびネストされた構造の形式の署名を持つ公開OEMルートキーがあります。

 typedef struct KEY_MANIFEST { char Tag[8]; // '__KEYM__' unsigned char : 8; // 10h unsigned char : 8; // 10h unsigned char : 8; // 0 unsigned char : 8; // 1 unsigned short : 16; // 0Bh unsigned short : 16; // 20h == hash size? unsigned char IbbmKeyHash[32]; // SHA256 of an IBBM public key BG_RSA_ENTRY OemRootKey; }; typedef struct BG_RSA_ENTRY { unsigned char : 8; // 10h unsigned short : 16; // 1 unsigned char : 8; // 10h unsigned short RsaPubKeySize; // 800h unsigned long RsaPubExp; unsigned char RsaPubKey[256]; unsigned short : 16; // 14 unsigned char : 8; // 10h unsigned short RsaSigSize; // 800h unsigned short : 16; // 0Bh unsigned char RsaSig[256]; };

OEMルートキーの公開キーを確認するには、その時点でIntel MEから既に受信しているSHA256ヒューズハッシュを使用します。

2番目のマニフェストに進みましょう。次の3つの構造で構成されます。

 typedef struct IBB_MANIFEST { ACBP Acbp; // Boot policies IBBS Ibbs; // IBB description IBB_DESCRIPTORS[]; PMSG Pmsg; // IBBM signature };

最初の-いくつかの定数：

 typedef struct ACBP { char Tag[8]; // '__ACBP__' unsigned char : 8; // 10h unsigned char : 8; // 1 unsigned char : 8; // 10h unsigned char : 8; // 0 unsigned short : 16; // x & F0h = 0 unsigned short : 16; // 0 < x <= 400h };

2番目は、SHA256 IBBハッシュと、IBBの内容を記述する記述子の数（つまり、ハッシュの考慮元）です。

 typedef struct IBBS { char Tag[8]; // '__IBBS__' unsigned char : 8; // 10h unsigned char : 8; // 0 unsigned char : 8; // 0 unsigned char : 8; // x <= 0Fh unsigned long : 32; // x & FFFFFFF8h = 0 unsigned long Unknown[20]; unsigned short : 16; // 0Bh unsigned short : 16; // 20h == hash size ? unsigned char IbbHash[32]; // SHA256 of an IBB unsigned char NumIbbDescriptors; };

IBB記述子は、この構造に従います。それらのコンテンツの形式は次のとおりです。

 typedef struct IBB_DESCRIPTOR { unsigned long : 32; unsigned long BaseAddress; unsigned long Size; };

簡単です。各記述子には、IBBチャンクのアドレス/サイズが含まれています。したがって、これらの記述子が指すブロックの連結（記述子自体の順序）はIBBです。また、原則として、IBBはすべてのSECおよびPEIフェーズモジュールの組み合わせです。

2番目のマニフェストは、IBB公開キー（最初のマニフェストからのSHA256ハッシュで検証）とこのマニフェストの署名を含む構造によって完成します。

 typedef struct PMSG { char Tag[8]; // '__PMSG__' unsigned char : 8; // 10h BG_RSA_ENTRY IbbKey; };

したがって、UEFI BIOSの開始前でも、プロセッサはACMを起動し、フェーズコードSECおよびPEIを使用してセクションの内容の信頼性を検証します。次に、プロセッサはACMを終了し、RESETベクトルを介してBIOSの実行を開始します。

検証済みのPEIパーティションには、残りのBIOS（DXEコード）をチェックするモジュールが含まれている必要があります。このモジュールはすでにIBV（独立BIOSベンダー）またはシステムベンダー自身によって開発されています。なぜならレノボとギガバイトのシステムのみが自由に使用でき、Intel BGをサポートしている場合のみ、これらのシステムから抽出されたコードを検討してください。

UEFI BIOSモジュールLenovoVerifiedBootPei

Lenovoの場合、これはLenovoが開発したLenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D}モジュールであることが判明しました。

彼の仕事は、DXEのハッシュテーブルを（GUIDで）検索し、DXEを検証することです。

 if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME) { if (!FindHashTable()) return EFI_NOT_FOUND; if (!VerifyDxe()) return EFI_SECURITY_VIOLATION; }

ハッシュテーブル{389CC6F2-1EA8-467B-AB8A-78E769AE2A15}の形式は次のとおりです。

 typedef struct HASH_TABLE { char Tag[8]; // '$HASHTBL' unsigned long NumDxeDescriptors; DXE_DESCRIPTORS[]; };

 typedef struct DXE_DESCRIPTOR { unsigned char BlockHash[32]; // SHA256 unsigned long Offset; unsigned long Size; };

UEFI BIOSモジュールBootGuardPei

Gigabyteの場合、AMIによって開発されたBootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066}モジュールであることが判明したため、Intel BGをサポートするAMI BIOSに存在します。

操作アルゴリズムは多少異なりますが、同じものになります。

 int bootMode = EFI_PEI_SERVICES->GetBootMode(); if (bootMode != BOOT_ON_S3_RESUME && bootMode != BOOT_ON_FLASH_UPDATE && bootMode != BOOT_IN_RECOVERY_MODE) { HOB* h = CreateHob(); if (!FindHashTable()) return EFI_NOT_FOUND; WriteHob(&h, VerifyDxe()); return h; }

探しているハッシュテーブル{389CC6F2-1EA8-467B-AB8A-78E769AE2A15}の形式は次のとおりです。

 typedef HASH_TABLE DXE_DESCRIPTORS[]; typedef struct DXE_DESCRIPTOR { unsigned char BlockHash[32]; // SHA256 unsigned long BaseAddress; unsigned long Size; };

Intel Boot Guard 2.x

Apollo Lakeマイクロアーキテクチャを備えたIntel SoCベースの新しいシステムであるASRock J4205-ITで見つかったIntel Boot Guardのもう1つの実装について簡単に説明します。

このバージョンはSoCでのみ使用されますが（Kaby Lakeプロセッサのマイクロアーキテクチャを備えた新しいシステムは引き続きIntel Boot Guard 1.xを使用します）、Intel SoC上のプラットフォーム向けに新しいバージョンのアーキテクチャを検討することは大きな関心事です。：

BIOSおよびIntel MEリージョン（またはIntel SoCの用語によるとIntel TXE）は、1つのIFWIリージョンになりました。
プラットフォームでIntel BGが有効になっていても、FIT、KEYM、IBBMなどの構造はフラッシュメモリで見つかりませんでした。
TXEおよびISHコア（x86）に加えて、3番目のコアがチップセットに追加されました（これもARCです）-PMC（電源管理コントローラー）。電源サブシステムのパフォーマンスの確保とパフォーマンスの監視に関連しています。

新しいIFWIリージョンのコンテンツは、次のモジュールのコレクションです。

オフセット	名	説明
0000 2000h	SMIP	ベンダーによって署名されたプラットフォーム構成
0000 6000h	RBEP	Intelが署名したIntel TXEファームウェアコードセクション、x86
0001 0000h	PMCP	Intelによって署名されたIntel PMCファームウェアコードセクション、ARC
0002 0000h	FTPR	Intelが署名したIntel TXEファームウェアコードセクション、x86
0007 B000h	UCOD	Intelによって署名されたCPUのファームウェアアップデート
0008 0000h	IBBP	UEFI BIOS、SEC / PEIフェーズ、x86、ベンダーにより署名
0021 8000h	ISHC	ベンダーによって署名されたIntel ISHファームウェアコードセクション、x86
0025 8000h	NFTP	Intelが署名したIntel TXEファームウェアコードセクション、x86
0036 1000時間	IUNP	不明です
0038 1000時間	Obbp	UEFI BIOS、DXEフェーズ、x86、署名なし

TXEファームウェアの分析中に、RESETの後、TXEはCPUのアドレススペースの基本的な内容（FIT、ACM、RESETベクターなど）を準備するまで、プロセッサをこの状態に保つことが明らかになりました。さらに、TXEはこのデータをSRAMに配置した後、一時的にプロセッサにアクセスを許可し、RESETから「解放」します。

ルートキットガード

さて、ホットに移りましょう。 SPIフラッシュ記述子の多くのシステムでは、SPIフラッシュメモリのすべてのユーザーが任意の領域を読み書きできるように、SPIフラッシュメモリの領域にアクセスする権限が書き込まれていることがわかりました。つまりまさか。

（Intel STKの）MEinfoユーティリティで確認したところ、これらのシステムの製造モードが閉じられていないことがわかりました。したがって、チップセットヒューズ（FPF）は未定義の状態のままになりました。はい、Intel BGはこのような場合にオンにもオフにもなりません。

次のシステムについて話します（Intel BGおよび記事で後述するものについては、Haswellプロセッサマイクロアーキテクチャ以上のシステムについて話します）。

すべてのギガバイト製品。
すべてのMSI製品
21のLenovoラップトップモデルと4つのLenovoサーバーモデル。

もちろん、これらのベンダーとIntelに発見を報告しました。

適切な応答は、問題を認識し、パッチをリリースした レノボからのみ来ました。

Gigabyteはこの脆弱性に関する情報を受け入れたようですが、それについてはまったくコメントしていません。

（暗号化されたセキュリティアドバイザリを送信するために） MSIとの通信は、公開PGPキーを送信するというリクエストにより完全に停止しました。彼らは「彼らは機器のメーカーであり、PGP鍵は生産しない」と述べた。

しかし、ポイントに近い。ヒューズは未定義の状態のままなので、ユーザー（または攻撃者）は自分でそれらをプログラムできます（最も難しいのはIntel STKを見つけることです）。これを行うには、次の手順を実行します。

1. Windows OSを起動します（一般に、目的のOS向けにIntel STKの類似物を開発する場合は、Linuxの下から以下の手順を実行することもできます）。 MEinfoユーティリティを使用して、このシステムでヒューズがプログラムされていないことを確認してください。

2.フラッシュプログラミングツールを使用して、フラッシュメモリの内容を読み取ります。

3. UEFI BIOSを編集するための任意の手段を使用して読み取りイメージを開き、必要な変更（たとえばルートキットの実装）を行い、ME領域で既存のKEYMおよびIBBM構造を作成/編集します。

RSAキーの公開部分が写真で強調表示されており、そのハッシュはIntel BG構成の残りの部分と共にチップセットヒューズにプログラムされます。

4. Flash Image Toolを使用して、新しいファームウェアイメージを組み立てます（Intel BG構成を指定）。

5.フラッシュプログラミングツールを使用して新しいイメージをフラッシュメモリに書き込みます。MEinfoで、ME領域にIntel BG構成が含まれるようになります。

6.フラッシュプログラミングツールを使用して、製造モードを閉じます。

7.システムが再起動し、MEinfoを使用してFPFがプログラムされていることを確認できます。

これらの手順により、このシステムでIntel BG が永続的に有効になります。アクションを元に戻すことはできません。つまり、次のことを意味します。

ルートキーのプライベート部分の所有者（つまり、Intel BGをオンにしたもの）のみが、このシステムのUEFI BIOSを更新できます。
たとえば、プログラマーを使用して元のファームウェアをこのシステムに戻すと、（検証エラーの場合の施行ポリシーの結果として）起動することさえありません。
このようなUEFI BIOSを取り除くには、チップセットを「クリーン」にプログラムされたFPFに交換する必要があります（つまり、自動車の費用で赤外線はんだ付けステーションにアクセスできる場合はチップセットを再はんだ付けするか、マザーボードを交換するだけです）。

そのようなルートキットができることを理解するには、UEFI BIOS環境でコードを実行できるようにするものを評価する必要があります。最も特権的なプロセッサモードであるSMMについて考えてみましょう。このようなルートキットには、次のプロパティがあります。

OSと並行して実行します（タイマーによってトリガーされるSMI割り込みを生成するようにワークアウトを構成できます）。
SMMモードであることのすべての利点（RAMおよびハードウェアリソースのコンテンツへのフルアクセス、OSからの機密性）があります。
ルートキットプログラムコードは、SMMモードで起動すると暗号化および復号化できます。暗号化のキーとして、SMMモードでのみ使用可能なデータを使用できます。たとえば、SMRAMのアドレスのセットからのハッシュ。このキーを取得するには、SMMにアクセスする必要があります。そして、これには2つの方法があります。 SMMコードでRCEを見つけて実行するか、SMMモジュールをBIOSに追加します。これはブートガードをオンにしたため不可能です。

したがって、この脆弱性により、攻撃者は次のことができます。

システム内に目的が不明な、隠された、取り外しできないルートキットを作成します。
Intel SoC内のチップセットコアの1つ、つまりIntel ISHでコードを実行します（写真をよく見てください）。

Intel ISHサブシステムの機能はまだ調査されていませんが、Intel MEに対する興味深い攻撃ベクトルのようです。

結論

この調査では、Intel Boot Guardテクノロジーの技術的な説明が提供されました。 Intelのセキュリティオブオブスキュリティモデルの秘密は2つ未満です。
システムに削除できないルートキットを作成できる攻撃シナリオが表示されます。
最新のIntelプロセッサは、BIOSが動作を開始する前であっても多くの独自コードを実行できることがわかりました。
Intel 64アーキテクチャを備えたプラットフォームは、フリーソフトウェアの実行に適さなくなりつつあります。ハードウェア検証、独自技術およびサブシステムの増加（SoCチップセットの3つのコア：x86 ME、x86 ISHおよびARC PMC）。

緩和策

製造モードを意図的に開いたままにするベンダーは、必ず閉じてください。これまでのところ、目だけが閉じられており、新しいKaby Lakeシステムはこれを示しています。

ユーザーは、-closemnfパラメーターを指定してFlashプログラミングツールを実行することにより、システムでIntel BGをオフにすることができます（これは、説明した脆弱性の影響を受けます）。まず、MEリージョンのIntel BGの構成がFPFでのプログラミング後にこのテクノロジーを正確にオフにすることを（MEinfoを使用して）確認する必要があります。

シュレディンガートラステッドブート。 Intelブートガード