UEFI 検証オプション ROM ガイダンス

バージョン 1.3

このドキュメントでは、OEM と ODM は、ファームウェアがセキュア ブート チェーンの一部としてオプション ROM の署名チェックを検証する上で役立ちます。

このガイドでは、UEFI の基礎、セキュア ブートに関する基本的な知識 (UEFI 仕様のチャプター 1、2、13、20、27)、および PKI のセキュリティ モデルを理解していることを前提としています。

はじめに

オプション ROM (OpROM) は、プラットフォームの初期化中に PC BIOS によって実行されるファームウェアです。 通常はプラグイン カードに格納されますが、システム ボードに配置することもできます。

通常、オプション ROM が必要なデバイスは、ビデオ カード、ネットワーク アダプター、および RAID モジュール用のストレージ ドライバーです。 また、これらのオプション ROM によって通常、ファームウェア ドライバーも PC にインストールされます。

このドライバーには、従来の PC-AT、Open Firmware、EFI オプション ROM など、さまざまな種類のファームウェア ドライバーが含まれます。 ファームウェア ドライバーの例としては、ビデオ カードのビデオ BIOS、イーサネット アダプターの PXE ブート ドライバー、RAID コントローラー上のストレージ ドライバーなどがあります。 これらのデバイスには通常、ファームウェア ドライバーを提供するオプション ROM が付属しています。

Unified Extensible Firmware Interface (UEFI) では、レガシ モードのオプション ROM がサポートされています。

最新の UEFI 仕様 (現時点では、2.3.1 Errata C - セクション 2.5.1.2) に従って、ISA (レガシ) オプション ROM は UEFI 仕様に含まれていません。 この説明では、PCI ベースの UEFI 互換オプション ROM のみが考慮されます。

オプション ROM は、PC ファームウェアにデバイスのファームウェアを埋め込むことができない場合に使用できます。 オプション ROM にドライバーが付属している場合、IHV はそのドライバーを利用して、ドライバーとデバイスを 1 か所に保持できます。

このドキュメントでは、オプション ROM を検証する必要がある理由と、検証方法について説明します。

UEFI BIOS とレガシ BIOS の両方をサポート

多くの製造元は、さまざまな種類の PC 用にオプション ROM とファームウェアを含むデバイスを作成します。 一般的な combos には次のようなものがあります。

• レガシ ROM のみ
• UEFI ネイティブ OpROM
• レガシ ROM + UEFI EBC OpROM
• レガシ ROM + UEFI x64 OpROM
• レガシ ROM + UEFI x64 + UEFI IA32
• レガシ ROM + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

互換性サポート モジュール (CSM) が有効になっている場合、UEFI BIOS は、レガシ ファームウェア ドライバーを読み込んで実行できます。 セキュア ブートが有効になっている場合は、レガシ ファームウェア ドライバーで認証がサポートされていないため、互換性サポート モジュールとレガシ ROM の実行は禁止されています。BIOS 構成のオプション ROM 形式がレガシ ROM に設定されている場合は、常にレガシ ROM がデバイス上で使用されます。

オプション ROM の形式が UEFI 互換 に設定されている場合は、それよりも新しい EFI ROM があればそれが使用され、ない場合はレガシ ROM が使用されます。

UEFI ドライバーは、ファームウェア レベルの新しいセキュリティ機能の多くと、UEFI ブート シーケンスの有効化に必要です。 たとえば、セキュア ブートが有効になっているときにシステムを UEFI モードで起動した場合、UEFI と互換性のないストレージ コントローラーに接続されている光学ディスクから Windows をインストールすることはできません。

1. UEFI およびオプション ROM

図 2: UEFI ドライバーのセキュリティに関する考慮事項、ソース: UEFI 2.3.1 Errata C

次の文章は UEFI 2.3.1 Errata C に掲載されたものですが、パートナーからの情報をもとに修正されています。

UEFI ユーザー プロファイルには、セキュリティ関連のさまざまな特権が詳細に記載されているため、ユーザー ID マネージャーとユーザー資格情報プロバイダー、およびそれらが実行される環境が信頼されていることが重要です。

これには、次のものが含まれます。

• これらのドライバーが格納されている記憶域を保護します。
• これらのドライバーを選択する方法を保護します。
• 検証されていないドライバーからこれらのドライバーの実行環境を保護します。
• これらのドライバーによって使用されているデータ構造は、まだ使用されている間は、未承認のドライバーによって破損しないようにしてください。

ユーザー ID マネージャー、ユーザー資格情報ドライバー、およびボード ドライバーなどのコンポーネントは、プラットフォーム ポリシーによって信頼されている書き込み禁止フラッシュ ドライブなどの安全な場所に配置されている可能性があります。

一部の他のドライバーは、オプション ROM やハード ドライブのパーティションなど、保護されていない保存場所に存在する可能性があるため、簡単に置き換えることができます。 これらのドライバーを確認する必要があります。

たとえば、既定のプラットフォーム ポリシーでは、Driver#### 読み込みオプションに記載されているドライバーを正常に検証する必要があります。または、これらのドライバーを処理する前にユーザーを識別する必要があります。 それ以外の場合は、ドライバーの実行を延期する必要があります。 その後、Identify () の呼び出し、または動的認証を使用してユーザー プロファイルを変更すると、Driver#### オプションが再度処理されない可能性があります。

ユーザー プロファイル データベースは、保護の可否に基づき、別の UEFI シグナル イベントを使用して閉じられます。

UEFI ドライバーおよび UEFI オプション ROM は、ブート パス内のデバイスに対してのみ実行されます。

PCI の仕様上、同一デバイス上でオプション ROM の複数のイメージを使用できます。 このオプション ROM には、レガシ x86 と UEFI などがあります。 UEFI ファームウェアは、オプション ROM を選択するためのプラットフォーム ポリシーを設定します。 これにより、オプションのアダプターの ROM を独自のコントロール デバイスとして実行できるようになります。

このファームウェアは、BDS および DXE フェーズ中に署名を検証します。 イベントの順序は次のとおりです。

1. PCI および派生バスの初期化
2. オプション ROM のための PCI デバイスのプローブ
3. 検出したオプション ROM のメモリへのマッピング
4. DXE フェーズで ROM のすべての UEFI ドライバーの読み込み

UEFI のオプション ROM は、メモリ内の任意の場所に配置できます。 既定では、カードの ROM でデバイスを管理できます。 UEFI では、EFI_PLATFORM_DRIVER_OVERRIDE を使用して、制御するオプション ROM とデバイスに関するポリシーをプラットフォームで制御できます。 UEFI は、構成インターフェイスを登録するためのオプション ROM をサポートしています。

セキュア ブートが有効になっている PC では、オプション ROM のドライバーが署名されていない場合や検証されていない場合に、セキュリティ上の脅威が発生します。 オプション ROM の署名の検証は、Windows ハードウェア認定キット (WHCK) の要件です。 インストール前に更新プログラムが検証されていることを確認するために、オプション ROM を使用する場合も同様です。

Windows ハードウェア互換性プログラムの仕様とポリシー バージョン 1809

10. 署名されていないファームウェアのコード整合性チェック OEM によってインストールされ、読み取り専用であるか、前述のように、セキュリティで保護されたファームウェア更新プロセスによって保護されているファームウェアは、保護されているとみなされる可能性があります。 システムは、保護されていないすべてのファームウェア コンポーネント、UEFI ドライバー、および UEFI アプリケーションが、最低でも RSA-2048 と SHA-256 (MD5 および SHA-1 は禁止されている) を使用して署名されていることを確認し、これらの要件に従って署名されていない UEFI アプリケーションやドライバーは実行できないことを確認します (これは、許容される署名アルゴリズムの規定ポリシーです)。 承認されたデータベースにイメージの署名が見つからない場合、または禁止されたデータベースに含まれている場合、そのイメージは起動せずにイメージの実行情報テーブルに配置する必要があります。

2. 問題の説明

セキュア ブートが有効になっている UEFI BIOS の一部のビルド (Tiano Core を含む) は、署名済みの UEFI オプションがセキュア ブートの開発中に使用できなかったため、既定で UEFI オプション ROM を認証できませんでした。 これにより、UEFI セキュア ブートでの攻撃または脆弱性が公開されます。

2.1. 脆弱性

この脆弱性は、2013 年 8 月時点の EDK II および UDK2010 にも存在しています。 ソースのメンテナが問題を認識しており、バグが報告されています。 EDK II および UDK2010 から派生したファームウェアでは、オプション ROM の検証の管理方法を確認する必要があります。 オプション ROM の検証動作は、EDK II SecurityPkg パッケージの PCD 値 PcdOptionRomImageVerificationPolicy によって制御されます。

TianoCore の脆弱性のソースコードは、SecurityPkg\SecurityPkg.dec ファイルです。

## 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) は ALWAYS_EXECUTE です。この場合、アドインの周辺機器のオプション ROM で署名されたドライバーの検証は正しく実行されません。 これは、UEFI セキュア ブート機能を実装しているシステムには最適な値ではありません。

推奨値 (最適なセキュリティ): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

推奨値 (最適な柔軟性): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

EDK II および UDK2010 では、適切なコーディング方法として、上書きメカニズムを使用してプラットフォーム ファームウェアの PCD 値を変更します。 そのため、PcdOptionRomImageVerificationPolicy の値は SecurityPkg\SecurityPkg.dec で変更できません。 オーバーライド値はプラットフォームの DSC ファイルで設定する必要があります。 Nt32Pkg\Nt32Pkg.dsc を使用した例を次に示します。

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

PCD のオーバーライド値は、DSC ファイルの [PcdsFixedAtBuild] セクションの下に配置する必要があります。 パラメーターを上書きするための正確なメカニズムは、BIOS ベンダー ツールによって異なる場合があります。

Note

この脆弱性は、独立した BIOS ベンダーからの UEFI セキュア ブート BIOS の初期実装に存在する可能性があります。 お使いのバージョンが影響を受ける可能性があるかどうかを判断するには、BIOS ベンダーに問い合わせてください。

3. 影響を受けるユーザー

セキュア ブートを実装する UEFI PC で、署名されていない UEFI オプション ROM ドライバーがあります。 さらに、既存のカードを機能させるようにする互換性のためのファームウェアには、オプション ROM を検証しないというセキュリティ上の脆弱性がある可能性があります。

ノート PC、ネットブック、Ultrabook、タブレット: ほとんどの場合、影響はありません。 通常、オプション ROM は、PCI/e、ISA、その派生物 (ExpressCard、miniPCI、CardBus、PCCard、LPC、ThunderBolt など) のバックプレーン バスに存在します。 ノート PC でこれらのいずれも公開されていない場合は、攻撃を受ける可能性が大幅に減少します。 さらに、オンボードのラップトップ コンポーネント用の UEFI ドライバーは、コア BIOS ファームウェア ボリュームに統合されている可能性があります。これは、独立したオプション ROM には存在しません。 そのため、ほとんどのノート PC は危険に晒されることはありません。 また、レガシ オプション ROM が無効になっている場合、UEFI では PCI ベースのオプション ROM のみがサポートされます。

ただし、UEFI BIOS を搭載し、セキュア ブートを実装しているデスクトップやマザーボード、サーバーが使用している場合は、影響を受ける可能性があります。 サーバーの専用 RAID コントローラーや、SATA、FC などのアドイン ストレージ コントローラー、イーサネット PCIe ネットワーク カードには、オプション ROM が搭載されている場合があります。 サーバー上のさまざまな機能をサポートするアドイン コントローラーが一般的であるため、これは特にサーバーの領域に適用されます。

これにより、クラス 2 とクラス 3 の両方で、32 ビットと 64 ビットの PC に影響を与える可能性があります。

セキュア ブート プラットフォームが、プラットフォームに永続的に接続されていないデバイスのオプション ROM をサポートしており、それらのオプション ROM を認証する機能をサポートしている場合は、「ネットワーク プロトコル - UDP および MTFTP」に記載されているオプション ROM の検証方法と、「UEFI 仕様 2.3.1 Errata C セクション 7.2」に記載されている認証済みの EFI 変数をサポートする必要があります。

4. テスト方法

ファームウェアを開発していて、Tiano Core に基づいている場合は、セクション2.1 で説明されている脆弱性を確認してください。 他の IBV のファームウェアを使っている場合は、製造元に確認してください。 以下に記載されているように自分でテストすることもできます。

以下のものが必要になります。

• UEFI ファームウェア搭載のテスト用 PC
• テスト用 PC にオプション ROM が搭載された PCI デバイス (ビデオ カードなど)
• セキュア ブートが有効

テストの手順:

1. UEFI オプション ROM を使用して、テスト用 PC に UEFI アドオン PCI カードを挿入します。

   テストに PCI ビデオ カードを使用している場合は、外部モニターを接続します。

2. 次の設定を使用してセキュア ブートを有効にします。

   • PK: PK または自己署名テスト PK
   • KEK: MS KEK、PK 署名 Fabrikam テスト KEK、またはその他の KEK
   • DB: NULL (これは NULL である必要があります)。
   • DBX: NULL
   • SecureBoot: UEFI 変数は true に設定してください

3. PC を再起動します

4. 次のような結果が予想されます。

   • UEFI ファームウェアが正しく実装されている場合、オプション ROM が存在するとファームウェアが証明書の "Db" を確認するため、UEFI オプション ROM ドライバーは読み込まれません。 "Db" が NULL であるため、UEFI ドライバーは読み込みに失敗します。 たとえば、ビデオ カードを使用してテストする場合は、ディスプレイに何も表示されないことが分かります。
   • ファームウェアが正しく実装されていない場合、ファームウェアは "Db" の署名を確認しないため、UEFI ドライバーはオプション ROM から読み込まれます。 たとえば、テスト用のビデオ カードを使用している場合は、オプション ROM カードに接続されているモニターが表示されていることが分かります。

   ![メモ] UEFI オプション ROM ドライバーが署名されているかどうかにかかわらず、DB が null で SB が有効になっている場合 (PK と KEK が登録されている場合)、オプション ROM は読み込まれません。

PK と KEK の生成については、WHCK にあるサンプル スクリプトを参照してください。 付録 B には、サンプル スクリプトと詳細が記載されています。

付録 A を参照の上、別の方法で上記のテストを実行することもできます。 この方法では、DB を Null に設定する必要はありませんが、IHV の未署名の UEFI オプション ROM ドライバーが必要です。

5. 修正方法

上記のテストに失敗した場合は、IBV と連携して必要なバージョンを取得し、オプション ROM が検証されるように構成します。 ファームウェアがテストに合格していることを確認します。 出荷済みの PC の場合は、セキュリティで保護されたファームウェアの更新を行う必要があります。 「NIST の出版物 800-147」および「Windows 8.1 セキュア ブート キーの作成と管理のガイダンス」を参照してください。

PC をテストし、セキュリティで保護されたファームウェア更新プログラムをテストするためのテスト ツール (認証ツールではない) として Windows HCK を利用することができます。

5.1. ドライバーへの署名

UEFI オプション ROM に署名されていないドライバーがある場合は、その修正方法について以下を参照してください。

各オプション ROM ドライバーに個別に署名します。 これにより、PCI オプション ROM のフォーマットが解除されます。 デバイスの統合オプションを作成する前に、UEFI ドライバーに署名する必要があります。

UEFI ドライバーを OpROM に挿入する前に、UEFI イメージに署名し、UEFI シェル (ドライバー ファイルの読み込み/アンロード) でセキュア ブートのオン、オフを切り替えてテストします。 次に、署名されたドライバーを結合したオプション ROM に配置します。

UEFI オプション ROM に署名してもらうために、SysDev センターのサービスを利用して、IHV を Microsoft SysDev センターに誘導することができます。

5.2. 更新の検証

前述のテストを実行して、脆弱性が存在しないことを確認します。 HCK テストを使用して、機能的な回帰がないことを確認します。

6. リソース

• UEFI プラットフォーム初期化の仕様、ボリューム 5 基準、1.2.1 Errata A: https://go.microsoft.com/fwlink/p/?linkid=220187
• UEFI 2.3.1 仕様からの関連情報:
• 2.5.1: レガシ オプション ROM の問題
• 10: プロトコル - UEFI ドライバー モデル
• 13.4.2: PCI オプション ROM
• 20: EFI バイト コード仮想マシン
• 28: HII の概要
• 29: HII プロトコル
• 30: HII の構成処理とブラウザー プロトコル
• UEFI フォーラムのラーニング センター
• UEFI IHV resources @ intel.com
• 他のUEFI 開発者からのサポートを受けるには、TianoCore edk2-devel メーリング リストを使用します。
• TechNet: エンタープライズ セキュリティ向けベストプラクティス: セキュリティ戦略
• UEFI 仕様 Errata C
• Trusted Computing Group
• Tianocore UEFI 開発キット
• UEFI ファームウェア
• Intel Press: Beyond BIOS 2nd Edition
• セキュア ブート キーの作成と管理のガイダンス
• Windows UEFI ファームウェア更新プラットフォームの機能の検証

付録 A: 署名されていないオプション ROM ドライバーを使用する別の方法

この方法では、IHV からツールを取得して、UEFI オプション ROM ドライバーが署名されていることを確認する必要があります。

以下のものが必要になります。

• UEFI ファームウェア搭載のテスト用 PC
• テスト用 PC に接続されている未署名のオプション ROM ドライバーを使用している PCI デバイス (ビデオ カードなど)
• セキュア ブートが有効
• オプション ROM ドライバーで署名を検出するオプション IHV ツール (オプション ROM ドライバーが署名済みかどうかが明らかでない場合)

ファームウェアが正しく実装され、オプション ROM が署名されていない場合、カードはファームウェアによるチェックに失敗し、ドライバーに読み込まれません。 PC は、EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND のようなエラー コードを報告します。 ビデオ カードを使用している場合は、オプション ROM ドライバーが読み込まれないため、PC に黒い画面が表示される場合があります。

ファームウェアが正しく実装されていない場合、このテストは成功します。

付録 B: NULL db でセキュア ブートを有効化するためのスクリプト

セキュリティで保護されたブート変数 (PK と KEK) の現在のセットを使用するか、テスト用のテスト変数を生成できます。

テスト PK、KEK を生成し、Db を NULL に設定する手順を次に示します。 セキュア ブートが有効になっていないことを確認します。それ以外の場合、これらの手順では署名された UEFI bin ファイルが必要です。

Note

UEFI bin ファイルに署名する必要がないように、セキュア ブート変数 (Db、KEK、PK) を逆の順序で設定します。

この手順の前に、PC がセットアップ モードである必要があります。

1. KEK 証明書と PK 証明書の作成

   この手順を実行するには、Windows SDK で使用できる makecert.exe ツールが必要です。

   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 を生成するスクリプト

   以下ではサンプルを提供します。

   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 を使用する

   このために、独自の OEM KEK または WHCK のスクリプトを利用できます。

   以下ではサンプルを提供します。

   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 を設定する

   このスクリプトではまず、Db を Null に設定します。

   Note

   Fabrikam Test KEK CA が存在する唯一の KEK CA である (つまり、Windows KEK CA が存在しない) 場合、PC は Windows RE で起動する可能性があることに注意してください。

   スクリプトを実行する前に、"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 カードをプラグインしてテストする

   テストは、ファームウェアの正確性に基づき、合格または失敗します。 次に例を示します。

   ファームウェアのオプション ROM が正しく実装されており、テストにビデオ カードを使用している場合は、接続されているモニターに表示されません。

   ただし、正しくないファームウェアを使用している場合は、ビデオ カードの出力がディスプレイに表示されます。

関連トピック

Windows セキュア ブート キーの作成と管理のガイダンス

セキュア ブートの概要

Windows UEFI ファームウェア更新プラットフォームの機能の検証