セキュリティで保護された MOR 実装Secure MOR implementation

まとめSummary

  • MorLock の動作、リビジョン2Behavior of MorLock, revision 2

最終更新日Last updated

  • 2020 年 8 月August 2020

適用対象Applies to

  • Windows 10Windows 10

  • Windows 10 の Credential Guard 機能をサポートする Oem および BIOS ベンダー。OEMs and BIOS vendors who want to support the Credential Guard feature of Windows 10.

公式の仕様Official specifications

概要Overview

このトピックでは、UEFI 変数 revision 2 の動作と使用法について説明し MemoryOverwriteRequestControlLock ます。This topic describes the behavior and usage for the MemoryOverwriteRequestControlLock UEFI variable, revision 2.

高度なメモリ攻撃を防ぐために、既存のシステム BIOS のセキュリティ対策 MemoryOverwriteRequestControl が改善され、新しい脅威から保護するためのロックがサポートされるようになりました。To prevent advanced memory attacks, the existing system BIOS security mitigation MemoryOverwriteRequestControl is improved to support locking to defend against new threats. 脅威モデルは、ホスト OS カーネルを敵対者として追加するために拡張されているため、カーネル特権レベルで実行されている ACPI および UEFI ランタイムサービスは信頼されていません。The threat model is expanded to include the host OS kernel as an adversary, thus ACPI and UEFI Runtime Services executing at kernel privilege level are not trusted. セキュアブート実装と同様に、MorLock は、ホスト OS カーネル (システム管理モード、TrustZone、BMC など) によって改ざんされる特権のあるファームウェア実行コンテキストに実装する必要があります。Similar to Secure Boot implementations, MorLock should be implemented in a privileged firmware execution context that cannot be tampered by the host OS kernel (for example, System Management Mode, TrustZone, BMC, and so on). このインターフェイスは UEFI 変数サービスに基づいて構築されています。これについては、UEFI 仕様バージョン2.5 で説明されています。 "Variable Services" という名前のセクション7.2 を参照してください。The interface is built upon UEFI variable services, which are described in the UEFI Specification version 2.5, Section 7.2 named "Variable Services".

Morlockと呼ばれるこの軽減策は、すべての新しいシステムに実装する必要があり、信頼されたプラットフォームモジュールを持つシステムに限定されるだけではありません。This mitigation, called MorLock, must be implemented on all new systems and not only limited to systems with Trusted Platform Modules. リビジョン2では、起動時のパフォーマンスの問題を軽減するために、新しい機能である ロック解除を追加します。特に、大規模なメモリシステムでは、Revision 2 adds a new capability, unlock, to mitigate boot performance concerns, especially on large memory systems.

_MOR bit 状態を設定するための ACPI DSM の制御方法に関するページ (「 PC クライアントの作業グループプラットフォームのリセット攻撃の緩和の仕様、バージョン 1.10 (PDF のダウンロード)」を参照) については、 _ 最新の BIOS 実装からこの dsm の方法を削除することをお勧めします。Regarding the ACPI _DSM control method for setting the MOR bit state (as described in Section 6 of PC Client Work Group Platform Reset Attack Mitigation Specification, Version 1.10 (PDF download)), we recommend removing this _DSM method from modern BIOS implementations. ただし、BIOS がこの DSM メソッドを実装する場合は、 _ MorLock の状態を尊重する必要があります。However, if a BIOS implements this _DSM method, it must respect the state of MorLock. キーがあるかどうかにかかわらず、MorLock がロックされている場合、この _ DSM メソッドは MOR を変更できず、"一般エラー" に対応する値1を返す必要があります。If the MorLock is locked, with or without a key, this _DSM method must fail to change MOR and return a value of 1 corresponding to "General Failure". MorLock リビジョン2のロックを解除するための ACPI メカニズムが定義されていません。No ACPI mechanism is defined to unlock MorLock revision 2.

Windows は、windows 7 以降、この DSM メソッドを直接呼び出していないの _ で、非推奨と見なされることに注意してください。Note that Windows has not directly invoked this _DSM method since Windows 7 and considers it deprecated. BIOS にindirectlyよっ _ ては、Windows が自動的にクリーンシャットダウンの実装として ACPI ポイントを呼び出すときに、この DSM メソッドが間接的に呼び出さ _ れます (「 PC クライアントの作業グループプラットフォームリセット攻撃の仕様、バージョン 1.10 (PDF ダウンロード)」のセクション2.3 を参照)。Some BIOS indirectly invokes this _DSM method when Windows invokes ACPI _PTS as an implementation of MOR Auto Detection of Clean Shutdown (as described in Section 2.3 of PC Client Work Group Platform Reset Attack Mitigation Specification, Version 1.10 (PDF download)).

この ACPI _ PTS での MOR 自動検出の実装はセキュリティ短さであるため、使用しないでください。This ACPI _PTS implementation of MOR Auto Detection is security deficient and should NOT be used.

MemoryOverwriteRequestControlLockMemoryOverwriteRequestControlLock

改善された軽減策を含む BIOS は、初期ブート時にこの UEFI 変数を作成します。BIOS containing the improved mitigation creates this UEFI variable during early boot:

VendorGuid:{BB983CCF-151D-40E1-A07B-4A17BE168292}VendorGuid: {BB983CCF-151D-40E1-A07B-4A17BE168292}

Name: MemoryOverwriteRequestControlLockName: MemoryOverwriteRequestControlLock

属性: NV + BS + RTAttributes: NV+BS+RT

データパラメーターのgetvariable値: 0x0 (ロック解除);0x1 (キーなしでロック);0x2 (キーでロック)GetVariable value in Data parameter: 0x0 (unlocked); 0x1 (locked without key); 0x2 (locked with key)

データパラメーターのsetvariable値: 0x0 (ロック解除);0x1 (ロック)SetVariable value in Data parameter: 0x0 (unlocked); 0x1 (locked)

SetVariable によるロックLocking with SetVariable

すべてのブートで、BIOS は MemoryOverwriteRequestControlLock ブートデバイス選択 (BDS) フェーズ (ドライバー unlocked # # # # 、SYSPREP # # # # 、ブート # # # # 、 * 回復 * 、...) の前に、0x00 (ロック解除を示す) の1バイト値に初期化します。On every boot, BIOS shall initialize MemoryOverwriteRequestControlLock to a single-byte value of 0x00 (indicating unlocked) before the Boot Device Selection (BDS) phase (DRIVER####, SYSPREP####, BOOT####, *RECOVERY*, …). MemoryOverwriteRequestControlLock(および) の場合 MemoryOverwriteRequestControl 、BIOS は変数と属性の削除を NV + BS + RT に固定する必要があります。For MemoryOverwriteRequestControlLock (and MemoryOverwriteRequestControl), BIOS shall prevent the deletion of the variable and attributes must be pinned to NV+BS+RT.

Setvariable MemoryOverwriteRequestControlLock が、 データで0以外の有効な値を渡すことによって最初に呼び出された場合、との両方のアクセスモード MemoryOverwriteRequestControlLock MemoryOverwriteRequestControl が読み取り専用に変更され、ロックされていることが示されます。When SetVariable for MemoryOverwriteRequestControlLock is first called by passing a valid non-zero value in Data, the access mode for both MemoryOverwriteRequestControlLock and MemoryOverwriteRequestControl is changed to read-only, indicating that they are locked.

Revision 1 の実装では、に対して1バイトの0x00 または0x01 のみを受け入れ MemoryOverwriteRequestControlLock ます。Revision 1 implementations only accept a single byte of 0x00 or 0x01 for MemoryOverwriteRequestControlLock.

さらに、リビジョン2では、共有シークレットキーを表す8バイトの値も受け入れられます。Revision 2 additionally accepts an 8-byte value that represents a shared secret key. Setvariableに他の値が指定されている場合は、status EFI INVALID パラメーターで呼び出しが失敗し _ _ ます。If any other value is specified in SetVariable, the call fails with status EFI_INVALID_PARAMETER. このキーを生成するには、トラステッドプラットフォームモジュールやハードウェアの乱数ジェネレーターなどの高品質のエントロピソースを使用します。To generate that key, use a high-quality entropy source such as the Trusted Platform Module or hardware random number generator.

キーを設定した後、呼び出し元とファームウェアの両方で、このキーのコピーを機密性の保護された場所 (IA32/X64 の場合は SMRAM、保護された記憶域を使用するサービスプロセッサなど) に保存する必要があります。After setting a key, both the caller and firmware should save copies of this key in a confidentiality-protected location, such as SMRAM on IA32/X64 or a service processor with protected storage.

システム状態の取得Getting the system state

リビジョン2では、 MemoryOverwriteRequestControlLock 変数と MemoryOverwriteRequestControl 変数がロックされている場合、(これらの変数の) setvariable の呼び出しは、最初に、定数時間アルゴリズムを使用して、登録されたキーに対してチェックされます。In Revision 2, when the MemoryOverwriteRequestControlLock and MemoryOverwriteRequestControl variables are locked, invocations of SetVariable (for those variables) are first checked against the registered key by using a constant-time algorithm. 両方のキーが存在し、一致する場合、変数はロック解除された状態に戻ります。If both keys are present and match, the variables transition back to an unlocked state. この最初の試行の後、またはキーが登録されていない場合、この変数を設定しようとすると、 _ _ ブルートフォース攻撃を防ぐために EFI アクセス拒否によって失敗します。After this first attempt or if no key is registered, subsequent attempts to set this variable fail with EFI_ACCESS_DENIED to prevent brute force attacks. その場合、システムの再起動は、変数のロックを解除する唯一の方法である必要があります。In that case, system reboot shall be the only way to unlock the variables.

オペレーティングシステムは、 MemoryOverwriteRequestControlLock getvariableを呼び出して、とその状態の存在を検出します。The operating system detects the presence of MemoryOverwriteRequestControlLock and its state by calling GetVariable. システムは、値を0x1 に設定して、の現在の値をロックでき MemoryOverwriteRequestControl MemoryOverwriteRequestControlLock ます。The system can then lock the current value of MemoryOverwriteRequestControl by setting the MemoryOverwriteRequestControlLock value to 0x1. または、シークレットデータがメモリから安全に消去された後で、今後、ロック解除を有効にするキーを指定することもできます。Alternatively, it may specify a key to enable unlocking in the future after secret data has been securely purged from memory.

に対して Getvariable を呼び出すと、ロック MemoryOverwriteRequestControlLock の解除、キーのないロック、またはキーの状態でロックされていることを示す0x0、0x1、または0x2 が返されます。Calling GetVariable for MemoryOverwriteRequestControlLock returns 0x0, 0x1, or 0x2 to indicate unlocked, locked without key, or locked with key states.

MemoryOverwriteRequestControlLockを設定しても、フラッシュはコミットされません (内部ロック状態を変更するだけです)。Setting MemoryOverwriteRequestControlLock does not commit to flash (just changes the internal lock state). 変数を取得すると、内部状態が返され、キーを公開しません。Getting the variable returns the internal state and never exposes the key.

オペレーティングシステムによる使用例:Example usage by the operating system:

if (gSecretsInMemory)
{
    char data = 0x11;
    SetVariable(MemoryOverwriteRequestControl, sizeof(data), &data);
}

// check presence
status = GetVariable(MemoryOverwriteRequestControlLock, &value);  

if (SUCCESS(status))
{
    // first attempt to lock and establish a key
    // note both MOR and MorLock are locked if successful

    GetRNG(8, keyPtr);
    status = SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);

    if (status != EFI_SUCCESS)
    {
        // fallback to revision 1 behavior
        char data = 0x01;
        status = SetVariable(MemoryOverwriteRequestControlLock, 1, &data);
        if (status != EFI_SUCCESS) { // log error, warn user }
    }
}
else
{
    // warn user about potentially unsafe system
}

// put secrets in memory

// … time passes …

// remove secrets from memory, flush caches

SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);

MorLock の実装フローMorLock implementation flow

これらのフローチャートは、実装の予想される動作を示しています。These flowcharts show the expected behavior of your implementation:

初期化Initialization

morlock の初期化

SetVariable フローSetVariable flow

morlock プログラミングフロー

SetVariable のロック解除状態フローUnlocked state flow for SetVariable

morlock のロック解除フロー

SetVariable のロック状態フローLocked state flow for SetVariable

morlock ロックフロー

GetVariable の FlowFlow for GetVariable

morlock getvariable

関連項目See also

SoC プラットフォーム上のすべての Windows エディションに適用される UEFI 要件UEFI requirements that apply to all Windows editions on SoC platforms

PC クライアントの作業グループプラットフォームのリセット攻撃の緩和の仕様、バージョン 1.10 (PDF のダウンロード)PC Client Work Group Platform Reset Attack Mitigation Specification, Version 1.10 (PDF download)

コールド攻撃 (およびその他の脅威) からの BitLocker の保護Protecting BitLocker from Cold Attacks (and other threats)

EDKII での UEFI TPM2 サポートを使用した BIOS に関するツアーA Tour Beyond BIOS with the UEFI TPM2 Support in EDKII

Credential Guard によるドメインの派生資格情報の保護Protect derived domain credentials with Credential Guard

UEFI 仕様UEFI Specifications