UEFI の検証オプションの ROM のガイダンスUEFI Validation Option ROM Guidance

Vishal Manan、アーキテクト、コンサルティング、OEM vmanan@microsoft.comVishal Manan, Architect, OEM Consulting, vmanan@microsoft.com

Jeremiah Cox, Sr. 氏 SDET、Windows Security & Identity チーム jerecox@microsoft.comJeremiah Cox, Sr. SDET, Windows Security & Identity Team, jerecox@microsoft.com

Tony Lin、TW WIN プランのエコシステムのサービス エンジニア、エンジニア リング tolin@microsoft.comTony Lin, Engineering Service Engineer, TW-WIN Plan Ecosystem, tolin@microsoft.com

バージョン 1.3Version 1.3

このドキュメントは、Oem および Odm 検証ファームウェアが信頼のセキュア ブートのチェーンの一部として、オプション ROM の署名を確認します。This document helps OEMs and ODMs validate that their firmware checks the signatures of its option ROM as part of the Secure Boot chain of trust.

このガイドでは、UEFI、セキュア ブート (章 1、2、13、20、UEFI 仕様の 27)、および PKI のセキュリティ モデルの詳細について基本的なの基本を理解することを前提としています。This guide assumes you know the fundamentals of UEFI, basic understanding of Secure Boot (Chapters 1, 2, 13, 20 and 27 of the UEFI specification), and PKI security model.

このページの内容。On this page:

概要Introduction

オプション Rom (OpROMs) は、ファームウェア プラットフォーム初期化中に PC BIOS で実行します。Option ROMs (or OpROMs) are firmware run by the PC BIOS during platform initialization. システム ボード上に存在することができますが、プラグイン カードに通常格納されます。They are usually stored on a plug-in card, though they can reside on the system board.

オプション Rom を通常必要とするデバイスは、ビデオ カード、ネットワーク アダプター、および RAID モジュールの記憶装置ドライバーがします。Devices that typically require option ROMs are video cards, network adapters, and storage drivers for RAID modules. 通常、これらのオプションの Rom は、PC にファームウェアのドライバーを提供します。These option ROMs also typically provide firmware drivers to the PC.

さまざまな種類のファームウェア ドライバー、従来の PC で、開いているファームウェアは、EFI オプション Rom などが含まれます。They include a variety of types of firmware drivers, including legacy PC-AT, Open Firmware, and EFI option ROMs. ファームウェアのドライバーの例には、ビデオ カード、イーサネット アダプターの場合、PXE ブート ドライバー、RAID コント ローラー上の記憶装置ドライバーにビデオの BIOS が含まれます。Examples of firmware drivers include Video BIOS on video cards, PXE boot drivers for Ethernet adapters, and storage drivers on RAID controllers. これらのデバイスには、オプション Rom のファームウェア ドライバーを提供する通常があります。These devices typically have Option ROMs that provide firmware drivers.

Unified Extensible Firmware Interface (UEFI) のレガシ モード オプション Rom サポートしています。The Unified Extensible Firmware Interface (UEFI) has support for Legacy mode option ROMs.

(現時点で 2.3.1 Errata C – セクション 2.5.1.2) 最新の UEFI 仕様に従って ISA (レガシ) オプション Rom は、UEFI 仕様の一部ではありません。As per latest UEFI specification (currently at 2.3.1 Errata C – section 2.5.1.2), ISA (legacy) option ROMs are not a part of the UEFI Specification. この説明のためには、PCI ベース UEFI と互換性のあるオプション Rom のみが考慮されます。For the purposes of this discussion, only PCI-based UEFI-compatible option ROMs will be considered.

PC のファームウェアでデバイスのファームウェアを埋め込むことができないときに、オプション Rom を使用できます。Option ROMs can be used when it's not be possible to embed a device's firmware in the PC firmware. オプションの ROM は、ドライバーを実行、ときに、IHV は、ドライバーを利用し、ドライバーとデバイスを 1 か所に保持できます。When the option ROM carries the driver, the IHV can leverage that driver, and keep the driver and device in one place.

このドキュメントでは、オプション Rom を検証する必要がある理由について説明し、いくつかのテクニックの方法を示しています。This document talks about why you need to validate option ROMs and shows some techniques of doing it.

UEFI BIOS と従来の BIOS をサポートしています。Supporting both UEFI BIOS and Legacy BIOS

多くの製造元は、オプション Rom とファームウェアのさまざまな種類の Pc が追加するデバイスを作成します。Many manufacturers create devices that include option ROMs and firmware for many types of PCs. 一般的な combos は次のとおりです。Common combos include:

  • レガシ ROM のみLegacy ROM Only

  • UEFI ネイティブ OpROMUEFI Native OpROM

  • レガシ ROM + UEFI EBC OpROMLegacy ROM + UEFI EBC OpROM

  • レガシ ROM + x64 UEFI OpROMLegacy ROM + UEFI x64 OpROM

  • レガシ ROM + UEFI x64 UEFI IA32Legacy ROM + UEFI x64 + UEFI IA32

  • レガシ ROM + x64 UEFI + UEFI IA32 UEFI EBC OpROMLegacy ROM + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

UEFI BIOS では、読み込むでき、互換性サポート モジュール (CSM) が有効にすると、従来のファームウェア ドライバーを実行することができます。UEFI BIOS can load and execute legacy firmware drivers when a Compatibility Support Module (CSM) is enabled. セキュア ブートが有効にすると互換性サポート モジュールおよびレガシ Rom の実行が禁止されている従来のファームウェア ドライバーでは、認証をサポートしていないために注意してください。BIOS 構成では、オプション ROM 形式は、従来の ROM に設定されている場合、デバイスのレガシ ROM が常に使用されます。Note that when Secure Boot is enabled, execution of the Compatibility Support Module and legacy ROMs is prohibited because legacy firmware drivers do not support authentication.If the Option ROM format in the BIOS configuration is set to legacy ROM, it will always use the legacy ROM on the device.

オプション ROM 形式に設定されている場合UEFI 互換性のある、1 つが存在し、1 つの場合は、レガシ ROM でない場合、新しい EFI ROM が使用されます。If the Option ROM format is set to UEFI Compatible, it will use the newer EFI ROM if one is present and the legacy ROM if one is not.

UEFI ドライバーは、新しいファームウェア レベルのセキュリティの機能の多くも UEFI ブート シーケンスを有効にするために必要です。UEFI drivers are necessary for many of the new firmware level security features as well as to enable UEFI boot sequences. たとえば、非 UEFI の互換性のあるストレージ コント ローラーに関連付けられている光ディスクから Windows をインストールするときは使用できませんセキュア ブートが有効にすると、システムが UEFI モードで起動します。For example, installing Windows from an optical disk which is attached to a non-UEFI compatible storage controller is not possible when a system is booting in UEFI mode when Secure Boot is enabled.

1.UEFI およびオプションの Rom1. UEFI and Option ROMs

uefi ドライバーに関する考慮事項のダイアグラム

図 2:UEFI ドライバーのセキュリティの考慮事項、ソース:UEFI 2.3.1 Errata CFigure 2: UEFI Driver Security Consideration, Source: UEFI 2.3.1 Errata C

次のテキストは、UEFI 2.3.1 Errata C で開始されますが、パートナーからの洞察には変更されています。The following text originated in UEFI 2.3.1 Errata C, but has since been modified with insights from partners:

UEFI のユーザー プロファイルの詳細数なセキュリティ関連の権限をそれがユーザーの Identity Manager ユーザーの資格情報プロバイダーとその実行環境が信頼されていることが重要です。Since the UEFI user profile details a number of security-related privileges, it is important that the User Identity Manager and User Credential Providers and the environment in which they execute are trusted.

たとえば、次のようなアニメーションや効果を作成できます。This includes:

  • これらのドライバーが格納されているストレージ領域を保護します。Protecting the storage area where these drivers are stored.

  • これらのドライバーを選択するための手段を保護します。Protecting the means by which these drivers are selected.

  • 未確認のドライバーからこれらのドライバーの実行環境を保護します。Protecting the execution environment of these drivers from unverified drivers.

  • まだ使用されているときに、これらのドライバーで使用するデータ構造を承認されていないドライバーが破損していない必要があります。The data structures used by these drivers should not be corrupted by unauthorized drivers while they are still being used.

コンポーネントのようなユーザー Identity Manager、ユーザーの資格情報のドライバーとドライバーがおそらく安全な場所にある天井などのプラットフォーム用のポリシーによって信頼されている、また書込みフラッシュ ドライブ。Components like User Identity Manager, the User Credential drivers and on board drivers maybe located in a secure location like write-protected flash drive which is trusted by platform policy.

その他のいくつかのドライバーに配置すること、保護されていない記憶域の場所は、オプション Rom などのハード ドライブのパーティションと、簡単に置き換えることができます。Some other drivers may reside on an unprotected storage locations like option ROMs or a hard drive partition and may be easily replaced. これらのドライバーを検証する必要があります。These drivers must be verified.

たとえば、既定のプラットフォームのポリシーできる必要がありますが正常にドライバーをドライバー内で検証## # #ユーザーか、または読み込みのオプションは、これらのドライバーを処理する前に識別する必要があります。For example, either the default platform policy must successfully be able to verify drivers listed in the Driver#### load options, or else the user must be identified prior to processing these drivers. それ以外の場合、ドライバーの実行を遅延する必要があります。Otherwise, the driver execution should be deferred. かどうか、ユーザー プロファイルが変更された後続の呼び出しを特定の () または動的の認証を使用ドライバー# # # #オプションは再び処理されない可能性があります。If the user profile is changed through a subsequent call to Identify () or through dynamic authentication, the Driver#### options may not be processed again.

ユーザー プロファイル データベースを終了するには、保護するかどうかに基づいて別の UEFI シグナル イベントを使用します。The user profile database is closed using different UEFI signal events based on whether it can be protected.

UEFI ドライバーおよび UEFI オプション Rom には、ブート パスでのデバイス向けのみ実行されます。UEFI Drivers & UEFI option ROMs will only be executed for devices in the boot path.

PCI の仕様では、同じデバイスに複数のオプションの ROM イメージを使用できます。PCI spec allows multiple option ROM images on the same device. これらのオプションの ROM は、レガシ x86 & UEFI 可能性があります。These option ROMS could be Legacy x86 & UEFI. UEFI ファームウェアは、オプション ROM を選択するためのプラットフォームのポリシーを設定します。UEFI firmware sets platform policy for picking the option ROM. 省略可能なアダプターの ROM の独自のデバイスのコントロールとして実行することができます。That can make the optional adapter's ROM execute as its own control device.

ファームウェアでは、BDS および DXE フェーズ中に署名を検証します。The firmware verifies signatures during BDS and DXE phases. イベントの順序は次のとおりです。The sequence of events is as follows:

  1. PCI と派生のバスを初期化します。Initialize PCI and derivative Buses

  2. オプション Rom の PCI デバイスをプローブします。Probe PCI Devices for option ROMs

  3. メモリ内で見つかったオプション Rom がマップされています。Found option ROMs are mapped in memory

  4. Rom に UEFI ドライバーをロードする DXE フェーズDXE phase loads any UEFI drivers in ROMs

UEFI オプション Rom は、メモリ内でどの場所でもかまいません。UEFI option ROMs can be anywhere in memory. 既定では、デバイスの管理カードの ROM をできるようにします。The default is to let the ROM on the card manage the device. UEFI 許可の制御ポリシーをどのようなオプションの ROM が EFI を使用してどのようなデバイスを制御するためのプラットフォーム_プラットフォーム_ドライバー_をオーバーライドします。UEFI allows platform to control policy around what option ROM controls what device using EFI_PLATFORM_DRIVER_OVERRIDE. UEFI では、オプション Rom 構成インターフェイスを登録をサポートします。UEFI supports option ROMs to register a configuration interface.

セキュア ブートが有効になっている pc では、オプション ROM ドライバーは、署名されていないまたは未検証された場合にセキュリティ脅威をもたらします。On a PC with Secure Boot enabled, option ROM drivers pose a security threat if they are not signed or not validated. オプション Rom の署名の検証は、WHCK 要件です。Signature validation for option ROMs is a WHCK requirement. 同じことが、更新プログラムをインストールする前に検証することを確認する、オプション Rom の処理中に当てはまります。The same is true while servicing option ROMs to make sure that the update is validated prior to installation.

Windows ハードウェア互換性プログラムの仕様書、およびポリシーに関するバージョン 1809:From the Windows Hardware Compatibility Program specifications and policies version 1809:

  1. ファームウェアのコードの整合性チェック署名します。Signed Firmware Code Integrity Check. ファームウェアが読み取り専用か、セキュリティで保護されたファームウェア更新プロセスによって保護されている、OEM がインストールされているように、上記で定義された思われる保護されています。Firmware that is installed by the OEM and is either read-only or protected by a secure firmware update process, as defined above, may be considered protected. システムは sha-256 で最小の RSA 2048 を使用してに、すべてのコンポーネントの保護されていないファームウェア、UEFI ドライバー、および UEFI アプリケーションが署名することを確認 (MD5 と sha-1 は禁止されています)、ことを確認し、UEFI アプリケーションおよびこれらに従って署名されていないドライバー要件の実行に失敗 (これは許容可能な署名アルゴリズムの既定のポリシーです)。Systems shall verify that all unprotected firmware components, UEFI drivers, and UEFI applications are signed using minimum RSA-2048 with SHA-256 (MD5 and SHA-1 are prohibited), and verify that UEFI applications and drivers that are not signed as per these requirements will fail to run (this is the default policy for acceptable signature algorithms). 場合は、イメージの署名では、承認済みのデータベースでが見つからないか、禁止されているデータベースに存在しますが、イメージを起動する必要があり、代わりに、それに関する情報は、イメージの実行情報の表に配置されるものとします。If an images signature is not found in the authorized database, or is found in the forbidden database, the image must not be started, and instead, information about it shall be placed in the Image Execution Information Table.

2.問題の説明2. Problem statement

一部のセキュア ブートが有効な UEFI BIOS、五郎 Core を含むビルドが既定ではなく認証オプション Rom の UEFI セキュア ブートの開発時に署名付きの UEFI オプション Rom が利用できなかったため。Some builds of Secure Boot-enabled UEFI BIOS, including Tiano Core, did not by default authenticate UEFI option ROMs because signed UEFI option ROMs were not available during Secure Boot development. これは、UEFI のセキュア ブート攻撃画面/脆弱を公開します。This exposes an attack surface/vulnerability in UEFI Secure Boot.

2.1.2.1. 脆弱性Vulnerability

この脆弱性がまだ EDK II、2013 年 8 月の時点で UDK2010 内に存在します。This vulnerability was still present in EDK II and UDK2010 as of August 2013. ソースの管理者が、問題を認識し、バグをファイリングします。The source maintainers are aware of the issue and a bug is filed. EDK II と UDK2010 から派生した任意のファームウェアでは、オプション ROM の検証を管理する方法を確認してください。Any firmware derived from EDK II and UDK2010 should verify how Option ROM verification is managed. オプションの ROM の検証の動作が PCD 値によって制御されるPcdOptionRomImageVerificationPolicyEDK II SecurityPkg パッケージ。Option ROM verification behavior is controlled by a PCD value PcdOptionRomImageVerificationPolicy in the EDK II SecurityPkg package.

TianoCore 脆弱性のソース コードは SecurityPkg\SecurityPkg.dec ファイル。The source code for the TianoCore vulnerability is SecurityPkg\SecurityPkg.dec file:

## Pcd for OptionRom.
  #  Image verification policy settings:
  #  ALWAYS_EXECUTE                         0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

既定値 (0x00) は常に_EXECUTE で、正しく実行されない署名されたドライバーの検証オプション Rom のアドインの周辺機器について。The default value (0x00) is ALWAYS_EXECUTE, which does not properly perform verification of signed drivers in Option ROMs for add-in peripherals. これは UEFI セキュア ブート機能を実装する任意のシステムの最適な値ではありません。This is not an ideal value for any system implementing UEFI Secure Boot functionality.

値 (最適なセキュリティ) をお勧めします。 DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)Recommended Value (Best Security): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

値 (最適な柔軟性) をお勧めします。 QUERY_USER_ON_SECURITY_VIOLATION (0x05)Recommended Value (Best Flexibility): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

EDK II & UDK2010 では、適切なコーディング方法は、プラットフォーム ファームウェアの PCD 値を変更するのに、オーバーライドのメカニズムを使用します。In EDK II & UDK2010, proper coding practice uses an override mechanism to modify PCD values for platform firmware. 値ではそのため、PcdOptionRomImageVerificationPolicyで変更しないでくださいSecurityPkg\SecurityPkg.decします。Therefore, the value for PcdOptionRomImageVerificationPolicy should not be changed in SecurityPkg\SecurityPkg.dec. プラットフォームの DSC ファイルでは上書き値を設定する必要があります。The override value should be set in the platform’s DSC file. 例が Nt32Pkg を使用して次に示す\Nt32Pkg.dsc:An example is shown below using Nt32Pkg\Nt32Pkg.dsc:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

PCD オーバーライドは、下に配置する必要があります、 [PcdsFixedAtBuild] DSC ファイルのセクション。The PCD override should be placed under the [PcdsFixedAtBuild] section of the DSC file. パラメーターをオーバーライドするための正確なメカニズムは、BIOS ベンダー ツールによって異なる場合があります。The exact mechanism for overriding parameters may differ depending on BIOS vendor tools.

  ベンダー BIOS から UEFI をセキュリティで保護のブート BIOS の初期の実装では、この脆弱性があります。Note   This vulnerability may exist in early implementations of UEFI Secure Boot BIOS from independent BIOS vendors. お使いのバージョンが低下するかどうかを決定する、BIOS ベンダーに問い合わせてください。Contact your BIOS vendor to determine if your version may be impacted.

3.ユーザーが影響を受けますか。3. Who is affected?

セキュア ブートを実装し、UEFI オプションの ROM ドライバーが署名されていないが UEFI PC。A UEFI PC which implements Secure Boot and has a UEFI option ROM driver which is not signed. さらに、既存のカードの操作を取得する互換性のためのファームウェアには、オプション Rom しないことを確認するセキュリティの脆弱性があります。Furthermore, the firmware for compatibility to get the existing cards working may have a security vulnerability which doesn’t verify option ROMs.

ラップトップ、ノートブック、ultrabook、およびタブレット: ほとんどには影響しませんします。Laptops, netbooks, ultrabooks, & tablets: most are not affected. PCI/e、ISA、およびその派生物などのバック プレーンのバスには、オプション Rom がある通常 (ExpressCard、ミニ Pci、CardBus、pc カード、LPC ThunderBolt など)。Option ROMs are typically present on backplane buses such as PCI/e, ISA, and their derivatives (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt etc). ラップトップがある公開されるこれらのいずれも、攻撃対象領域は大幅に減少します。If a laptop has none of these exposed, then its attack surface is greatly reduced. さらに、コンポーネントは個別のオプションの ROM 上に存在しない、コア BIOS ファームウェアのボリュームに統合されて、オンボード ラップトップ用の可能性が高い UEFI ドライバーがMoreover, it is likely UEFI drivers for onboard laptop components are integrated into the core BIOS firmware volume, not located on a separate option ROM. そのためほとんどのラップトップには危険にさらさできません。Thus most laptops are not at risk. また、Rom のレガシー オプションを無効にすると、よう UEFI には、PCI ベース オプション Rom のみがサポートされます。Also, when Legacy option ROMs are disabled, it looks like UEFI only supports PCI-based option ROMs.

ただし、デスクトップ、マザーボード、または UEFI BIOS があり、セキュア ブートを実装するサーバーがあれば、そのするが影響可能性があります。However, if you have a desktop, motherboard or a server which has a UEFI BIOS and implement Secure Boot, you may be affected. サーバーの専用 RAID コント ローラー、または SATA、FC など、またはイーサネット PCIe ネットワークの追加の記憶域コント ローラーでは、オプション Rom がカードにあります。On a server’s dedicated RAID controller, or add-in storage controller for SATA, FC etc. or Ethernet PCIe network cards may have option ROMs. アドインのコント ローラー サーバー上のさまざまな機能のサポートは一般的なため、これは、サーバーの領域に特に適用されます。Add-in controllers supporting a wide array of functionality on servers are common so this especially applies to the server space.

これは、クラス 2 と 3 クラスの両方の 32 ビットおよび 64 ビット Pc に可能性があります。This can potentially affect 32-bit and 64-bit PCs, both class 2 and class 3.

セキュア ブート、プラットフォーム サポートしないプラットフォームに接続されているデバイスから、オプション Rom かどうかと、オプション Rom を認証する機能をサポートしているネットワーク プロトコルで説明されているオプションの ROM 検証メソッドをサポートする必要があります: UDP および MTFTPおよび UEFI 2.3.1 に定義されている認証済みの EFI 変数の正誤表 C セクション 7.2 します。If a Secure Boot platform supports option ROMs from devices not permanently attached to the platform and it supports the ability to authenticate those option ROMs, then it must support the option ROM validation methods described in Network Protocols — UDP and MTFTP and the authenticated EFI variables described in UEFI specification 2.3.1 Errata C Section 7.2.

4.これをテストする方法でしょうか。4. How to test for it?

五郎 Core に基づいて、ファームウェアを開発している場合は、セクション 2.1 で説明されている脆弱性の確認してください。If you are developing the firmware and it is based on Tiano Core please check for vulnerability mentioned in the section 2.1. 使用する場合別 IBV のファームウェアくださいチェックにします。If you are using another IBV’s firmware please check with them. または、テストを行うことが、自分で次のようです。Or you could do the test it yourself as mentioned below.

以下が必要。You will need the following:

  • UEFI ファームウェアでテスト対象の PCPC under test with UEFI firmware

  • (ビデオ カード) などのテスト対象の PC で、オプション ROM の PCI デバイスPCI device with Option ROM on the PC under test (like a video card)

  • セキュア ブートが有効になっていることを確認します。Make sure Secure Boot is enabled

テストの手順:Steps for testing:

  1. 挿入する UEFI では、テスト対象の PC に UEFI オプション ROM PCI カードに追加します。Insert a UEFI add on PCI card with UEFI Option ROM to the PC under test.

    PCI のビデオ カードのテストを使用している場合フックアップ外部を監視します。If you are using a PCI video card for testing, hookup an external monitor.

  2. 次の設定でセキュア ブートを有効にします。Enable Secure Boot with the settings below:

    • 主キー:PK、自己署名テスト PKPK: Your PK or self-signed Test PK

    • KEK:KEK または別の KEK を MS KEK、Fabrikam の PK で署名されたテストします。KEK: MS KEK, PK-signed Fabrikam test KEK or another KEK

    • DB:NULL: DB: NULL. (NULL をあるこの必要があります)。(This must be NULL.)

    • DBX:NULL: DBX: NULL.

    • セキュア ブート:UEFI 変数を設定する必要がありますを true にSecureBoot: The UEFI variable should be set to true

  3. PC を再起動しますReboot the PC

  4. 次の結果が想定されます。Expect the following result:

    • UEFI ファームウェアが正しく実装されて UEFI オプション ROM ドライバーはないため、オプションの ROM の存在により、ファームウェアの"Db"証明書を確認してくださいに読み込みます。If the UEFI firmware is implemented correctly, the UEFI option ROM driver wouldn’t load since the presence of an option ROM will make the firmware check the “Db” for a certificate. "Db"が NULL であるために、UEFI ドライバーの読み込みが失敗します。Since the “Db” is NULL the UEFI driver will fail to load. たとえばをテストするビデオ カードを使用する場合は、何も表示されるディスプレイに表示されます。For example, if you are using the video card to test, you will see that nothing shows up on display.

    • ファームウェアが正しく実装されていない場合は、"Db"の署名のファームウェアは確認されないためオプション ROM から UEFI ドライバーが読み込まれます。If the firmware isn’t implemented correctly, UEFI driver will load from the option ROM since the firmware doesn’t check for signatures in “Db”. たとえば、テストのビデオ カードを使用する場合に、オプション ROM カードに接続されているモニターのディスプレイが持つことが表示されます。For example, if you are using the video card for test, you will see that the monitor hooked to the option ROM card will have display.

  か UEFI オプション ROM のドライバーが署名されていてもかまいませんが、DB が null で、SB が有効になっているときに、オプション ROM は読み込まれません (PK と KEK は登録されます)。Note   It doesn’t matter if the UEFI option ROM driver is signed or not, the option ROM will not load when DB is null and SB is enabled (PK and KEK are enrolled).

PK と KEK を生成するための WHCK で利用可能なサンプル スクリプトを参照してください。Please refer to sample scripts available in the WHCK for generating the PK and KEK. スクリプトは、こちらからダウンロードできます:https://go.microsoft.com/fwlink/?LinkId=321292します。You can download the scripts from here: https://go.microsoft.com/fwlink/?LinkId=321292 . 付録 B には、サンプル スクリプトと詳細があります。Appendix B has sample scripts and more details.

上記のテストを実行するための別の方法については、付録 A を参照することもできます。You can also reference Appendix A for another approach to performing the above test. この方法は、DB を Null に設定する必要はありませんが、IHV から UEFI 署名のないオプション ROM ドライバーを必要があります。This approach doesn’t require setting the DB to Null but needs an unsigned UEFI option ROM driver from the IHV.

5.その修正方法5. How to fix it

上記のテストに失敗した場合、IBV を必要なバージョンを取得し、オプション Rom を検証するように構成を使用します。If the above test fails, work with your IBV to acquire the necessary versions and configure them to validate option ROMs. ファームウェア テストに合格することを確認します。Make sure that the firmware passes the test. Pc が提供されているはセキュリティで保護されたファームウェアを更新する必要があります。For PCs which have shipped you will need to do a secure firmware update. 参照してくださいNIST publication 800-147参照やWindows 8.1 セキュリティで保護された Boot キーの作成と管理のガイダンスします。Please refer to NIST publication 800-147 and/or see Windows 8.1 Secure Boot Key Creation and Management Guidance.

PC をテストし、セキュリティで保護されたファームウェアの更新プログラムをテストするため、テスト ツール (認定ツールではない) として Windows HCK を活用できます。You can test the PC and leverage Windows HCK as a test tool (not a certification tool) for testing the secure firmware update.

5.1.5.1. ドライバーの署名Signing the driver

検索する場合にその修正方法で以下をご覧ください UEFI オプション Rom 上のドライバーが署名されていない可能性があります。In case you find that you may have unsigned drivers on UEFI option ROMs please read below on how to fix that.

各オプションの ROM ドライバーを個別にサインインします。Sign each option ROM driver individually. PCI オプション ROM の形式が中断します。That will break the format of the PCI Option ROM. 結合オプション ROM を作成する前に UEFI ドライバーの署名にのみ必要があります。You only need to sign the UEFI driver before creating the combined Option ROM.

OpROM で UEFI ドライバーを挿入する前に UEFI イメージの署名し、セキュリティで保護された Boot ON & OFF で UEFI シェル (読み込み/アンロード、ドライバー ファイル) を使用してテストします。Before inserting the UEFI driver in the OpROM, sign the UEFI image and test it with Secure Boot ON & OFF at the UEFI Shell (load/unload the driver file). 結合オプション ROM に署名されたドライバーを配置します。Then put the signed driver into the combined option ROM.

Rom の署名 SysDev センターで利用できるサービスを通じて、UEFI オプションを取得する Microsoft SysDev センターに、IHV を指示することができます。You can direct your IHV to Microsoft SysDev center to get their UEFI option ROMs signed through a service available through SysDev center.

5.2.5.2. 更新プログラムの検証Validation of update

この脆弱性が存在しないことを確認する上で説明したするテストを実行します。Run the test you mentioned above to verify that the vulnerability does not exist. HCK テストを使用して、回帰の機能がないことを確認します。Use the HCK tests to ensure that there are no functional regressions.

6.参考資料6. Resources

付録 a:符号なしのオプションの ROM のドライバーを使用してテストする別の方法Appendix A: Alternate approach to testing using unsigned option ROM drivers

このアプローチは、UEFI オプション ROM のドライバーが署名されているかどうかを確認する IHV からツールに依存します。This approach relies on getting tools from IHV to make sure that the UEFI option ROM driver is signed.

以下が必要。You will need the following:

  • UEFI ファームウェアでテスト対象の PCPC under test with UEFI firmware

  • (ビデオ カード) などのテスト対象の PC に接続されている、符号なしのオプションの ROM ドライバーを使用した PCI デバイスPCI device with an unsigned Option ROM driver attached to the PC under test (like a Video card)

  • セキュア ブートが有効になっていることを確認します。Make sure Secure Boot is enabled

  • オプションの IHV ツールか、オプション ROM ドライバーが署名されているは明らかでない場合は、オプション ROM ドライバーの署名を検出するにはOption IHV tools to detect signature on option ROM driver if it isn’t apparent that the option ROM driver is signed or not

ファームウェアが正しく実装されていて、オプション ROM が署名されていない場合、カードをファームウェアでのチェックに失敗し、カードのドライバーを読み込めません。If the firmware is implemented correctly, and the option ROM is unsigned the card should fail the check by firmware and not load the driver on the card. PC がなど、エラー コードを報告する必要がありますEFI_イメージ_実行_AUTH_SIG_FOUNDします。The PC should report an error code such as EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND. ビデオ カードを使用している場合は、オプション ROM ドライバーが読み込まれませんでしたので、PC は黒い画面だけを示しています。 表示があります。In case you are using a video card, you may see that the PC shows just a black screen since the option ROM driver didn’t load.

ファームウェアが正しく実装されていない場合は、このテストは有効です。If the firmware is implemented incorrectly, this test would work.

付録 b:NULL の db を使用したセキュア ブートを有効にするためのスクリプトAppendix B: Scripts for enabling Secure Boot with NULL db

セキュア ブートの変数 (PK と KEK) の現在のセットを使用するかこれをテストするためのテストを生成できます。You can either use your current set of Secure Boot variables (PK and KEK) or generate test ones for testing this.

テスト PK、KEK と Db を NULL に設定を生成する手順は次のとおり使用されます。Below are steps used to generate the test PK, KEK and setting Db to NULL. セキュア ブートが有効にしない;それ以外の場合これらの手順では、UEFI bin ファイルの署名が必要です。Make sure that Secure Boot is not enabled; otherwise these steps would require signed UEFI bin files.

  セキュア ブートの変数を設定します – Db、KEK と PK、UEFI に署名する必要はないため、逆の順序では、ファイルをビン分割します。Note   We set the Secure Boot variable – Db, KEK and PK in reverse order so we don’t have to sign the UEFI bin files.

この手順の前に、PC は、セットアップ モードである必要があります。Prior to this step the PC should be in setup mode.

  1. KEK と PK の証明書を作成します。Create KEK and PK certificates

    この手順で、makecert.exe ツールで使用できる、 Windows SDKします。This step requires the makecert.exe tool available in the Windows SDK.

    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer
    
  2. テスト PK を生成するスクリプトScript to generate test PK

    独自の PK を使用するか、この、WHCK からスクリプトを活用 https://go.microsoft.com/fwlink/?LinkId=321292You can either use your own PK or leverage the scripts from the WHCK for this https://go.microsoft.com/fwlink/?LinkId=321292

    サンプルを以下に示します。A sample is provided below.

    # this scripts demonstrates how to format the Platform key 
    # NOTE The PK is actually set in the Enable_OEM_SecureBoot.ps1 script 
    Import-Module secureboot
    $d = (pwd).Path
    
    ###############################################################################
    # Complete the following parameters
    ###############################################################################
    
    $certname = "TestPK"
    # TODO change this path to where you have the PK.cer file 
    # This is where you plugin the certificate generated by the HSM 
    $certpath = $d + "\" + $certname + ".cer"
    
    # Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database. 
    # Agents might include the operating PC or an OEM-supplied driver or application. 
    # Agents may examine this field to understand whether they should manage the signature or not.
    # TODO replace with OEM SignatureOwner GUID.
    # You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
    $sigowner = "55555555-5555-5555-5555-555555555555"
    
    $var = "PK"
    $efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
    $append = $false
    
    ###############################################################################
    # Everything else is calculated
    ###############################################################################
    
    # Workaround relative path bug
    # TODO substitute OEM with your OEM name 
    $siglist =  $certname + "_SigList.bin"
    $serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
    $signature = $serialization + ".p7"
    
    $appendstring = "set_" 
    $attribute = "0x27"
    $example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin" 
    
    Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z  -AppendWrite:$append
    
    # OutputFilePath - Specifies the name of the file created that contains the contents of what is set. 
    # If this parameter is specified, then the content are not actually set, just stored into this file.
    # Please note if -OutputFilePath is provided the PK is not set like in this case. The master script sets it at the end.
    
    # Time - you can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.
    
    Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist  -OutputFilePath $example -AppendWrite:$append
    
  3. 生成 KEK をテストまたは独自の OEM KEK を使用Generate test KEK or use your own OEM KEK

    これは、独自の OEM KEK や、WHCK からスクリプトを活用できます。You can leverage your own OEM KEK or scripts from the WHCK for this. Fabrikam を使用することもできます。_PK_から SigList.bin https://go.microsoft.com/fwlink/?LinkId=321292 KEK 独自テストを生成する代わりにします。You can also use the Fabrikam_PK_SigList.bin from https://go.microsoft.com/fwlink/?LinkId=321292 instead of generating your own test KEK.

    サンプルを以下に示します。A sample is provided below.

    # script to add option OEM KEK
    Import-Module secureboot
    $d = (pwd).Path
    
    ###############################################################################
    # Complete the following parameters
    ###############################################################################
    
    $certname = "Fabrikam_Test_KEK_CA"
    # TODO change this path to where you have the PK.cer file 
    # This is where you plugin the certificate generated by the HSM 
    $certpath = $d + "\" + $certname + ".cer"
    
    # TODO change this path to where you have the OEM_KEK.cer file 
    # Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database. 
    # Agents might include the operating system or an OEM-supplied driver or application. 
    # Agents may examine this field to understand whether they should manage the signature or not.
    # TODO replace with OEM SignatureOwner GUID.
    # You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
    
    $sigowner = "00000000-0000-0000-0000-000000000000"
    
    $var = "KEK"
    $efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
    $append = $false
    
    ###############################################################################
    # Everything else is calculated
    ###############################################################################
    
    $siglist = $certname + "_SigList.bin"
    $serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
    $signature = $serialization + ".p7"
    if ($append -eq $false) 
    { 
        $appendstring = "set_" 
        $attribute = "0x27"
    } else 
    {   
        $appendstring = "append_" 
        $attribute = "0x67"
    }
    $example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin" 
    
    Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append 
    
    # -Time You can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.
    
    Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append
    
  4. Db は Null に設定し、KEK と PK を設定Set Db to Null and set KEK and PK

    このスクリプトでは、まずは、データベースを Null に設定されます。The first thing this script does is set the Db to Null.

      保持してください。 に注意してください Fabrikam テスト KEK CA が存在する唯一の KEK CA の場合 (つまり、Windows KEK CA がありません)、PC 起動できますが Windows RE にします。Note   Please keep in mind if the Fabrikam Test KEK CA is the only KEK CA present (meaning there is no Windows KEK CA), the PC may boot into Windows RE.

    # Prior to script execution, run "Set-ExecutionPolicy Bypass -Force"
    
    Import-Module secureboot
    try 
    {
        Write-Host "Deleting db..."
        Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
    }
    catch
    {
    }
    Write-Host "Setting Fabrikam KEK..."
    Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin  -Name KEK
    
    Write-Host "Setting self-signed Test PK..."
    Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin  -Name PK
    
    Write-Host "`n... operation complete.  `nSetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, and that SecureBoot changes to 1."
    
  5. オプションの ROM カードに接続し、テストPlug in the option ROM card and test

    テストする必要があります成功 またはファームウェアの正確性に基づいて失敗します。The test should either pass or fail based on firmware correctness. 次に、例を示します。For example:

    ファームウェアでは、オプション ROM が正しく実装をテストするためのビデオ カードを使用している場合はが必要ない添付のモニターに表示です。If the option ROM in the firmware is implemented correctly, and you are using a video card for testing, then there should be no display to the attached monitor.

    ただし、不適切なファームウェアを使用している場合は、ビデオ カードをディスプレイに出力がする必要がありますです。However, if you are using incorrect firmware, the video card should have output on the display.

関連トピックRelated topics

Windows のセキュア ブート キーの作成と管理のガイダンスWindows Secure Boot Key Creation and Management Guidance

セキュア ブートの概要Secure Boot Overview

Windows の UEFI ファームウェア更新プラットフォーム機能を検証していますValidating Windows UEFI Firmware Update Platform Functionality