Share via

ファームウェア攻撃面の縮小 (FASR)

  • [アーティクル]

2019 年 10 月、Microsoft は OEM および Silicon のパートナーと密接に協力して、セキュリティで保護されたコア PC を発表しました。 これらのデバイスは、デバイス、ID、データのセキュリティ強化に役立つ、高度な統合のハードウェア、ファームウェア、ソフトウェアを備えています。 セキュリティで保護されたコア PC の主要なセキュリティを支えるもののひとつには、デバイスのファームウェア保護の提供があります。 この柱を満たすために必要なハードウェア ベースの基本的な機能は、Dynamic Root of Trust for Measurement (D-RTM) です。ただし、現在のところ、D-RTM を提供するデバイスは多くはありません。これは、この機能をサポートするために基になるチップセットへの依存によるもので、すべての Windows デバイスに対して高いセキュリティ要件を引き上げて維持するというコミットメントを妨げることになります。

D-RTM を使用しないデバイスを含め、すべての Windows デバイスのセキュリティ体制を強化するためにできることがまだ多くあります。 このギャップを埋めるため、Microsoft は、OEM を活用するためにより高度な柔軟性を提供する一連のオープンソースの SMM セキュリティ強化を開発することで、UEFI ファームウェアにメモリ保護が適用されない互換性の問題を克服するためのパートナーとの協力を始めています。

このファームウェア セキュリティへのコミットメントを反映するために、セキュリティで保護されたコア PC のファームウェア保護要件をデバイスが確実に満たすことができる新しいアプローチを特定しました。

FASR の概要

ハードウェア ベースの D-RTM 機能がないセキュリティ保護のコア PC の場合、攻撃対象領域を縮小し、オペレーティング システムで証明できるファームウェア コンポーネントの小さなセットを定義する必要があります。 このアプローチは、ファームウェア攻撃対象の縮小 (FASR) と呼ばれます。 FASR ベースのファームウェアを異なるベンダーの PC 間でスケーリングするには、ファームウェア ブート プロセスに対する新しいアプローチを定義する必要がありました。

FASR では、2 つのブート パスがサポートされています。

  1. 認定ブート パス:

    • Microsoft によって信頼、署名、および統合されたコードのみを実行できます。

    • ブート パスの改ざんは、オペレーティング システムによって検出できます。

    下図は、認定ブート パス上の FASR S-RTM ブート フローを示しています。 このブート パスは、予期しないプラットフォーム ファームウェア コードの実行を防止するために役立ちます。 ただし、これはカスタム ブート パスによって提供されるプラットフォーム固有のデータを使用します。 下図は、認定ブート パスの FASR ブート フローを示しています。

    F A S R boot flow on certified boot path

  2. カスタム ブート パス: すべてのプラットフォーム ファームウェア コードを実行できます。 特定の OEM / プラットフォームに固有のブートクリティカルな情報は、カスタム ブート パス上のデータに変換され、認定ブート パスによって使用されてそのブート パスでシステムを適切に構成します。 下図は、カスタム ブート パスの FASR ブート フローを示しています。

    F A S R boot flow on custom boot path

    セキュリティで保護されたコアの PC コンプライアンスが有効になっている FASR デバイスは、ファームウェアの起動プロセスの早い段階でブートがカスタム ブート パスに切り替わる原因となるイベントが発生しない限り、デフォルトで認定ブート パスに設定されます。 このようなイベントの例には、ファームウェアの更新、ユーザーによるファームウェア UI の要求、ユーザーによるセキュリティで保護されたコアの PC を無効にする選択（つまり、再有効化されるまで常時カスタム ブート パスで起動）などがあります。

    カスタム ブートは、FASR 対応デバイス上のプラットフォーム ファームウェアでサポートされているオペレーティング システムまたはサード パーティ製ソフトウェアを起動するために使用できますが、Windows では、カスタム ブート パス上の起動は、セキュリティで保護されたコアの PC に準拠しているとは認識されないことに留意してください。

FASR の背後にあるセキュリティのテクノロジーについての理解を深めるために、Windows ブート プロセスの概要を簡単に説明させてください。

Windowsブート プロセス

信頼のルート

最新の PC における初期ファームウェアの実行は、コードの初期セットが他のコードを読み込み、ブートの進行に合わせて機能レベルが拡張されるブート プロセスに従います。 各コード セットは、信頼チェーンを形成する次のコードのセットを検証します。 UEFI ファームウェアが制御を取得すると、ソフトウェア署名を検証するセキュア ブート基準に従って、オペレーティング システムへの信頼チェーンを続行します。 続いて、Windows ブート ローダーは、信頼されたブートを使用して信頼のチェーンを続行します。これにより、読み込まれる前に、スタートアップ プロセス内の他のすべての OS コンポーネントが検証されます。

一般に、攻撃者は、システムを保護するためのセキュリティ機能とロックが有効になる前に、ブート プロセスのできるだけ早い段階で制御を取得することを模索します。 システムがリセットされたら、実行したコードの初期セットを信頼として固定する必要があります。 この早期コード検証を実行する役割を果たすハードウェア検証テクノロジーは、信頼のルートと呼ばれます。 細かい詳細はハードウェア ベンダーによって異なりますが、すべての信頼のルートは通常、SOC 内の不変のハードウェアまたは ROM にルートしています。

メジャー ブート

信頼のルートに固定されたセキュリティ保護のブートは、すべてのファームウェアのデジタル署名が確実に検証されるようにします。ただし、実行されたファームウェアを正確に記録しておくことも推奨されます。 Windows ハードウェア互換性プログラムでは、すべての Windows 10 および Windows 11 PC にトラステッド プラットフォーム モジュール (TPM) と呼ばれるチップが含まれている必要があります。 TPM には、プラットフォーム構成レジスタ (PCR) と呼ばれるメモリの場所が含まれています。 各 PCR には、非揮発性ストレージ デバイスのファームウェア コード (SPI フラッシュなど)、PCI デバイスからのオプション ROM、OS ブートローダーなど、ブート時に読み込まれたコードの種類やデータのハッシュが含まれています。 PCR に格納できる値のサイズは、サポートされるハッシュ アルゴリズムのダイジェスト サイズによって決定されます。 たとえば、SHA-1 PCR では 20 バイトを格納でき、SHA-2 PCR では 32 バイトを格納できます。 同じハッシュ アルゴリズムに関連付けられている複数の PCR は、バンクと呼ばれます。 TCG PC クライアント TPM プロファイル仕様では、24 台のレジスタを持つ少なくとも 1 つの PCR バンクを含めることを定義しています。

TPM がある場合、各ファームウェア コンポーネントは、新しいコードとデータがブート プロセスに読み込まれると、適切な PCR を更新または拡張することもできます。 拡張プロセスは、入力として新しいコードまたはデータ引数と連結された現在の PCR 値を使用して、ハッシュ アルゴリズムからの出力として PCR 値を更新します。 その結果、起動プロセス後に PCR を検査して、実行した内容を特定できます。 これにより、オペレーティング システム内のソフトウェアは、ブート プロセスが以前のブートと異なるかを知ることができます。 セキュリティに影響を受けやすい環境では、予期しないファームウェア コードの実行を検出するために、特定の PCR で予想されるコード測定の正確なセットをオペレーティング システムに通知できます。 バンク内の最初の 16 個の PCR は TPM 全体をリセットすることによってのみリセットできるため、これらは信頼され、重要な測定値を TPM に格納するために推奨される場所です。

測定のための信頼のルート

信頼のルートの役割と計測されたブートの使用方法を理解できたので、TPM に測定チェーンを報告するための信頼のルートを確立するための 2 つの一般的な方法 (静的と動的) について説明します。

S-RTM (Static Root of Trust for Measurement) は、システム リセット時に信頼を確立し、ブート プロセス全体を通じて信頼を維持することを求めます。 ブート プロセスのいずれかの時点で信頼が侵害された場合、システムがリセットされるまで回復できません。 下図は、認定ブート パスでの S-RTM の使用方法を示しています。

static root of trust measurement

これに対し、Dynamic Root of Trust for Measurement (D-RTM) は、初期チップセット初期化ファームウェア コードのごく一部とブート中に動的に信頼を再確立するために使用されるハードウェア エージェントのみを信頼します。 システムは信頼されていないファームウェア コードを初期起動できますが、起動直後に、すべての CPU を制御し、既知の計測されたパスを強制的にダウンさせることで、信頼できる状態に戻ります。 下図は、従来の D-RTM フローの概要を示しています。

dynamic root of trust measurement

S-RTM と D-RTM 間にはトレードオフがあります。 S-RTM には特別なハードウェア機能は必要ありませんが、ブート全体で実行されるコードをより適切に考慮するためのソフトウェアが必要です。 D-RTM には特別なハードウェア機能が必要ですが、システムの存続期間中にソフトウェアを動的に信頼された状態に起動できます。

Windows のセキュリティで保護されたコア PC では、Secure Launch で D-RTM を使用して、多くのシステム製造元がファームウェアに独自の機能とエクスペリエンスを実装できる柔軟性を実現すると同時に、セキュリティで保護されたオペレーティング システム環境をホストするために許容される信頼と測定状態にシステムを確実に到達させることができます。 D-RTM 起動イベントは、セキュリティで保護されたカーネルを読み込む前に、不明な環境から信頼を再確立するために使用されます。 下図は、既知のシステム環境を再確立するための D-RTM 起動イベントを示しています。

D R T M launch event to re-establish a known system environment

以前は、システムのセキュリティ状態を確認するための特別なハードウェア機能への依存関係がなかったため、S-RTM をより多くのデバイスに実装できましたが、オペレーティング システムには S-RTM を使用して特定の Windows デバイスで報告された測定値を信頼できることを確認するための信頼性の高い方法がありませんでした。

ファームウェアのセキュリティ強化

OS ブート パスのファームウェア コンポーネントを最小限に抑える

S-RTM 計測を信頼する 1 つの方法は、実行できるファームウェア コンポーネントを最小限のセットに減少することです。 S-RTM を使用するすべてのデバイスが同じファームウェア コンポーネントのセットを使用している場合、オペレーティング システムは、既知および信頼されたコンポーネントに対して期待される PCR 値のセットを 1 つだけ信頼することのみが必要です。 この SRTM ベースのアプローチでは、ブート ファームウェアのセットに Windows によって構成証明できる Microsoft 署名付きソフトウェアのみが含まれていることが確認される場合、デバイスがセキュリテイで保護されたコア PC のファームウェア保護要件を満たしていると見なすことができます。 これらのファームウェア コンポーネントと通常の PC ブートのファームウェア コンポーネントの違いをより深く理解するために、起動プロセスの前後を見ていきましょう。

最新の PC ファームウェアが提供する柔軟性と豊富な機能セットにより、オペレーティング システムの前に実行されるコードは攻撃対象領域を増加する結果を産み出します。 下図は、従来の S-RTM ブート フローの例を示しています。

traditional S R T M boot flow

起動時のファームウェアの主要な任務は、次のように大幅に簡略化できます。

  • プラットフォーム固有: 特定のプラットフォーム ハードウェア設計のみで適用される機能。

  • プラットフォーム固有ではない: 業界標準であり、他のハードウェアに共通する機能。

最新のファームウェアの比較的小さなサブセットは、通常の場合、プラットフォーム固有です。 メモリの割り当て、ファームウェア ドライバーのディスパッチ、イベントの処理などの一般的なタスクを実行するファームウェア インフラストラクチャ コードの多くは、すべて (またはほとんど) の UEFI ベースのシステム間で同じものです。 これらのタスクのファームウェア バイナリ ドライバーは、PC 間で再利用できます。 さらに、業界標準のハードウェア仕様とインターフェイスにより、一般的なファームウェア ドライバーでハード ディスク、USB コントローラー、およびその他の周辺機器を初期化できます。 このハードウェアのファームウェア バイナリ ドライバーも、PC 間で再利用できます。 つまり、PC を一般的なファームウェア ドライバーのごく最小限のセットで起動することができます。

起動時に読み込まれるファームウェア ドライバーのセットを減らすことで、他の利点につながることがあります。

  • 起動時間の向上

  • 更新プログラムに対するベンダー調整の軽減

  • バグの露出削減

  • 攻撃対象領域の減少

FASR ブート パスの検証とセキュリティで保護されたコアのコンプライアンス

FASR システムがセキュリティで保護されたコアのPCのファームウェア保護要件を満たすには、認定ブート パスで起動している必要があります。 FASR ファームウェアは、認定パス上のモジュール ブート シーケンスの予想される PCR 値を含む FASR マニフェスト (TPM で計測) と呼ばれる Microsoft 署名済みマニフェストをオペレーティング システムに提供することで、これを容易にします。 これは、認定パスで発生した実際のブート シーケンスと比較できます。 これらの測定値が一致する場合、システムはセキュア コア PC プログラムのファームウェア保護要件を満たしていると見なされます。 想定される認定ブート パス シーケンスから逸脱することは、オペレーティング システムが検出する TPM のプラットフォーム構成レジスタ (PCR) の予期しない計測につながります。

さらに、Windows は、署名された FASR マニフェストが現在の起動時に記録された測定値に対して検証に成功した場合にのみ、ハイパーバイザーで保護されたシークレットを解放します。 認定ブート パスまたはカプセル更新プログラムで FASR マニフェストが存在せず、署名の検証が失敗するか、PCR の不一致が発生する場合、VSM シークレットは解除または移行されません。

FASR ファームウェアがメモリ保護と SMM に対処する方法

最小限の機能セットがある 1 つの Microsoft 署名バイナリが定義されたので、Microsoft がパートナーと協力して市場に投入する基本的でありながら欠落しているファームウェア セキュリティ保護を含めることができます。 認定ブート パスは、少なくとも次の要件を満たしている必要があります。

  1. コードは NULL/ページ 0 に読み取り / 書き込みを行わないこと

  2. イメージ コードとデータ セクションが分離されていること

  3. 画像セクションがページ (4 KB) の境界に配置されること

  4. データはデータ メモリ型にのみに割り当てられ、コードはコード メモリ型に割り当てられること

  5. コード イメージは、UEFI バイナリとして配布されるコードから読み込まれないこと (指定されたディスパッチャーのみ)

  6. コードは、ページ割り当て近くのガード ページを使用して、割り当てられたメモリ バッファーの境界内に留まること

  7. スタック オーバーフローを検出できること

  8. コードはスタックから実行されないこと

  9. /NXCOMPAT DLL 特性は、NX 保護を有効にするように設定されていること

サード パーティのオプション ROM、UEFI アプリケーション、UEFI ドライバーは、多くの場合、この一連の要件に対してビルドまたは検証されていません。 そのため、認定ブート パスでは実行されません。 カスタム ブート パスは必要に応じて、必要な保護レベルを下げることを選択できますが、そのブート パスはオペレーティング システムによってセキュリティで保護されたコア PC に準拠しているとは見なされません。

システム管理モード (SMM)

SMM は、x86 アーキテクチャの特殊なプロセッサ オペレーティング モードです。 SMM 環境で実行されるコードはオペレーティング システムに対して不透明であり、通常はホスト プロセッサ上の任意のソフトウェアの最高の特権レベル (「リング -2」とも呼ばれる) で実行されるため、システム セキュリティに固有の課題が生まれます。 SMM は、エントリ時に、ページ テーブル、割り込みディスパッチ テーブル (IDT)、およびその他のシステム構造を設定することによって、独自の環境を構成します。 したがって、SMM は、仮想化ベースのセキュリティ (VBS) を通じて有効になっている OS 保護を侵害または回避するために、悪意のあるコードによって利用される可能性がある重大な攻撃対象領域となります。 SMM がもたらす危険性を軽減するために、SMM の機能は概念的に次のように SMM コア インフラストラクチャと SMM ドライバに分割できます。

  • SMM コア: アーキテクチャとインフラストラクチャの責任を実行するすべての SMM 実装に共通するコード

  • SMM ドライバ: SMM でプラットフォーム固有のタスクを実行するために記述されたコード

SMM ライフサイクルの重要な瞬間をいくつか示します。

  1. SMM 基盤 (またはコア) が確立されたとき - SMM 初期プログラムロード (IPL)

  2. SMM ドライバが読み込まれるとき - SMM ドライバ ディスパッチと呼ばれます

  3. システム管理割り込み (SMI) を介して SMM へのエントリが行なわれたとき

SMM 初期プログラム ロード (IPL)

CPU には、SMM コードに高い特権を付与し、保護するのに役立つ特別な機能があります。 たとえば、ソフトウェアまたはハードウェア イベントを介して SMM を入力するメカニズムが定義され、SMM から戻るために CPU 命令が使用され、SMM のアクセスとロックの構成を制御するためにいくつかのレジスタが定義されます。 これらの制御レジスタの多くは、SMM コードとデータが格納されるメモリー領域 (システム管理 RAM または SMRAM と呼ばれる) へのアクセスを制限するために、SMM IPL コードによって構成されます。

SMRAM 領域はメイン メモリ (DRAM) 内にあるため、ブート中に DRAM が有効になるまでは確立できません。 DRAM を有効にする手順は Silicon ベンダーによって異なりますが、メモリを使用できるようになる前に、CPU LLC キャッシュ (DRAM を初期化するコードを含む) から直接数メガバイトのコードメイン実行できます。

FASR ファームウェアは、他のほとんどのシステムよりも前のブート時に SMM IPL ポイントを取り込みます。 これにより、攻撃者がこのプロセスを弱体化させ、SMM を設定する前にシステムを制御する機会が減少します。 FASR ファームウェアで SMM に対して行われたこの事項やその他の機能強化について理解を深めるために、ファームウェアのブート プロセスの詳細を確認する必要があります。

UEFI ファームウェアでのプラットフォーム初期化 (PI) ブート

最新の PC ファームウェアは、多くの仕様で構築されています。 UEFI 仕様では、Windows などの UEFI 準拠オペレーティング システムとデバイス上のファームウェアの間のインターフェイスを定義します。 プラットフォーム初期化 (PI) 仕様と呼ばれる別の仕様では、ファームウェア ドライバーの構築方法を定義し、ブート プロセス自体を詳しく設定します。 大まかに言えば、UEFI 仕様は、1 つの Windows イメージが非常に多くの異なるデバイスで動作することを可能にする標準化の 1 つと考えることができ、そして PI 仕様は、さまざまなハードウェア ベンダーのファームウェア イメージを連携させる標準化の 1 つと考えることができます。 両方の仕様は UEFI フォーラムによって管理されます。

PI 仕様は、ブート フェーズおよびブート フェーズに書き込まれるドライバを定義します。 ファームウェアの起動中、各フェーズは次のフェーズに移行し、ほとんどの場合には移行前のフェーズのドライバは使用されなくなり、重要なデータのみが次のフェーズに渡されるため、ブート プロセスを続行できます。 このブート アプローチをまとめると次のようになります。

  1. SEC – CPU リセット ベクターで制御を取得し、アセンブリから C コードに移行して PEI を読み込む

  2. PEI – DXE を読み込んで DRAM を初期化するシステム状態を初期化する

  3. DXE – システムの再メイン初期化を実行する。これには、BDS がオペレーティング システムを読み込む必要があるサポートの提供が含まれます

  4. BDS – 現在のブートへのブート オプションを検出し (OS ブート ローダーなど)、そのオプションの起動を試みる

  5. OS – オペレーティング システム カーネル

SMM 初期プログラム・ロード (IPL) の保護

従来の UEFI PI 仕様準拠ファームウェアは、DXE ブート フェーズで SMM IPL を読み込みます。 FASR ファームウェアは、PEI ブート フェーズで SMM IPL を読み込みます。 システムのトラステッド コンピューティング ベース (TCB) は、ハードウェア、ファームウェア、ソフトウェアなど、システムを保護する保護メカニズムの総合セットです。 SMM IPL を DXE から PEI に移行することで、DXE フェーズ全体 (PEI よりもはるかに大きく、より豊富な環境) が TCB から除外されます。 下図は、UEFI ブート プロセスで前に移動した SMM IPL を示しています。

S M M I P L moved earlier in UE F I boot process

PEI および DXE コードはリング 0 で実行され、オペレーティング システムに保持されません (少しの例外あり)。 SMM コードはリング 0 (およびハイパーバイザー) よりもはるかに高い特権で実行されてオペレーティング システムに保持されるため、DXE の脆弱性が SMM の確立に影響を与えず、システム全体の攻撃対象領域が減少します。 さらに、SMM は起動プロセスの早い段階で起動されるため、SMM の保護に役立つロック ビットを起動の早い段階で有効にして、攻撃者が SMM を侵害する隙を最小限に抑えることができます。

SMM ドライバ ディスパッチ プロセスの保護

PI 仕様では、従来の MM とスタンドアロン MM による 2 つの SMM モードが定義されています。 従来の MM は、業界の UEFI ファームウェアの大部分を構成する PI 準拠ファームウェアで使用されていた SMM ソフトウェア モデルに相当します。 スタンドアロン MM は、従来のモデルを見直して SMM 環境のセキュリティを向上し、長年にわたって移植とセキュリティ上の数多くの課題を引き起こしてきたこれまでの MM 実装における一般的なミスを防止する比較的新しいモードです。

FASR ファームウェアはスタンドアロン MM モードでのみ動作します。 これにより、FASR ファームウェアは、SMM でのソフトウェア実行に対する規範的なアプローチを行ないます。 現在の SMM ベースの脆弱性の多くは、スタンドアロン MM で削除できる従来の MM の SMM コードで許可されている不適切なプラクティスによるものです。 大まかに言えば、これは従来の MM モデルで SMM ドライバーが 2 回ディスパッチされていたことが原因です。1 回はリング 0 の DXE ディスパッチャーにより、もう 1 回は SMM の SMM ディスパッチャーによるものです。 これにより、DXE 環境で実行されるドライバ コードにとって、エントリ ポイントが戻った後にアクセスしてはならない SMRAM 外部のリソースへのポインターをキャッシュする十分な機会が得られることになります。 SMM コードに依存して SMM 外部のコードを呼び出す攻撃は、「SMM コールアウト攻撃」とよく呼ばれます。

SMM へのエントリの保護

データは「通信バッファー」と呼ばれる構造体を介して SMI ハンドラーに渡されます。 SMI ハンドラーは、データがそのエントリ ポイントの特定の要件を満たしているかを検証する役割を担います。 Windows SMM セキュリティ軽減テーブル (WSMT) は、オペレーティング システムの仮想化ベースのセキュリティチェック脅威を軽減するために使用される 1 つのメカニズムです。 Microsoft は、通信バッファーの検証を改善するために、TianoCore プロジェクトにコードを提供しました。 これら 2 つの手法を活用することに加えて、FASR コードでは厳密なメモリ アクセス保護も実装されているため、SMM コードは明示的に許可されたメモリ範囲にのみアクセスできます。

管理モード スーパーバイザー (MM スーパーバイザー)

SMM コア コードは一般的であり、システム間の変更を最小限に抑えて共有されます。 SMM がもたらす攻撃対象領域は、SMM 環境に特権の分離を導入することで大幅に減少できます。 そのため、FASR ファームウェアには、スタンドアロン MM で実行される SMM スーパーバイザーが含まれています。 これにより、作成時から適用される特権レベルを持つ最小限の TCB を持つ明確に定義された SMM 環境になります。 MM スーパーバイザーは、IO ポート アクセス、モデル固有レジスタ (MSR) アクセス、MMIO アクセス、CPU セーブステート アクセス、および SMM 環境で許可された命令に制限を設けます。 SMM スーパーバイザー ポリシーは、制限するハードウェア リソースの正確な詳細を構成するために使用され、この正確な詳細はシリコン生成ごとの変更の対象となります。

このポリシーは最近、SMM スーパーバイザーの外部のコードで使用できるハードウェア リソースを大幅に削減するデフォルト拒否アプローチに移行しました。 このスーパーバイザーは、最新の PC では一般的に見られないハードウェア機能にハードウェア依存なしで動作します。

FASR で使用される MM スーパーバイザーはオープンソースであり、Project Mu MM スーパーバイザー リポジトリから使用できます。

セキュリティで保護されたコア PC 要件に対する FASR システムのコンプライアンス

下図では、セキュリティで保護されたコア PC の幅広いセキュリティの柱または目標、および認定パスで起動する FASR システムでセキュリティで保護されたコア PC の要件を達成する方法を示しています。

セキュリティの利点 セキュリティで保護されたコア PC のセキュリティ機能
ハードウェアに裏付けされる Root of Trust を作成する セキュア ブート
トラステッド プラットフォーム モジュール 2.0
直接メモリ アクセス (DMA) 保護
ファームウェアレベルの攻撃に対する防御 (以下の注釈を参照) システム ガード セキュア ローンチ (D-RTM) または S-RTM (FASR FW)
システム管理モード (SMM) 分離または MM スーパーバイザー付きスタンドアロン MM (FASR FW)
検証されていないコードの実行から OS を保護する メモリ整合性 (別称 HVCI)
高度な ID の検証と保護を提供する Windows Hello
デバイスの紛失や盗難に備えて重要なデータを保護する BitLocker 暗号化

システムに D-RTM をサポートするための高度なセキュリティ機能がない場合は、S-RTM とスタンドアロン MM と MM Supervisor の組み合わせを使用してファームウェアの保護要件を満たすことができます。どちらも FASR ファームウェアによって提供されます。

まとめ

これらは、現在業界全体で普及しているファームウェア攻撃の増加に対処するために Microsoft が行った投資の一部です。 これらの変更にオープンソースのコードを使用することで、Microsoft はパートナーがこれらのセキュリティ上の利点の一部を活用できるよう支援しています。これにより、より膨大なエコシステムと業界全体に大きなメリットがもたらされます。

セキュリティで保護されたコア PC イニシアチブの主な目標は、お客様が Windows PC で使用できる最も高度なセキュリティ機能に確実にアクセスできるようにすることです。 これらのファームウェアの変更の一部により、その目標の実現に向けて一歩近づき、セキュリティで保護されたコア PC のファームウェア保護要件がこの包含を反映するように更新されました。 セキュリティで保護されたコア PC の 詳細については、こちらを参照してください。