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

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

Jeremiah Cox、シニア SDET、Windows セキュリティ & ID チームjerecox@microsoft.com

Tony Lin、エンジニアリング サービス エンジニア、TW-WIN Plan Ecosystemtolin@microsoft.com

第 1.3 版

このドキュメントは、自社のファームウェアがセキュア ブートの信頼チェーンの一部としてそのオプション ROM の署名を確認することを OEM と ODM が検証するのに役立ちます。

このガイドでは、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 とファームウェアを搭載したデバイスを製造しています。一般的な組み合わせを以下に挙げます。

  • レガシ 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

UEFI ドライバーに関する考慮事項の図

図表 2: UEFI ドライバーのセキュリティ上の考慮事項 (出典: UEFI 2.3.1 Errata C)

出典: UEFI 2.3.1 Errata C のセクション 31.1.4

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

これは次のような意味です。

  • これらのドライバーが格納されているストレージ領域が保護されています。

  • これらのドライバーを選択する手段が保護されています。

  • これらのドライバーの実行環境が未検証のドライバーから保護されています。

  • これらのドライバーが使用するデータ構造が、まだ使用中に、許可されていないドライバーによって破壊されることはありません。

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

その他のドライバーは、オプション ROM やハード ディスク パーティションのように保護されていない保存場所に存在していて、簡単に交換できる可能性があります。このようなドライバーは検証する必要があります。

たとえば、既定のプラットフォーム ポリシーが Driver#### 読み込みオプションに挙げられたドライバーの検証に成功するか、または、これらのドライバーを処理する前にユーザーが識別される必要があります。そうでない場合、ドライバーの実行は先送りされます。その後の Identify () の呼び出し、または、動的認証により、ユーザー プロファイルが変更された場合、Driver#### オプションが再び処理されない可能性があります。

ユーザー プロファイル データベースは、保護できるかどうかに基づいて、異なる UEFI シグナル イベントを使用して閉じられます。

UEFI ドライバーと UEFI オプション ROM は、ブート パスにあるデバイス用のものだけが実行されます。

PCI 仕様では、同じデバイスに複数のオプション ROM イメージを格納できます。このようなオプション ROM はレガシ x86 と UEFI の組み合わせとすることもできます。UEFI ファームウェアは、オプション ROM を選択するプラットフォーム ポリシーを設定します。これによりオプション アダプターの ROM を独自のコントロール デバイスとして実行できます。

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

  1. PCI バスと派生バスを初期化する

  2. PCI デバイスをプローブしてオプション ROM を探す

  3. 見つけたオプション ROM をメモリにマッピングする

  4. DXE フェーズで ROM にある UEFI ドライバーをすべて読み込む

UEFI オプション ROM はメモリ内のどこにでも配置できます。既定では、カード上の ROM にデバイスの管理を任せます。UEFI では、どのオプション ROM がどのデバイスを制御するかというポリシーを EFI_PLATFORM_DRIVER_OVERRIDE を使用してプラットフォームが制御できます。UEFI ではオプション ROM による構成インターフェイスの登録をサポートします。

セキュア ブートが有効な PC では、署名または検証されていないオプション ROM ドライバーはセキュリティ上の脅威になります。オプション ROM の署名検証は WHCK の要件です。オプション ROM の保守作業時にインストール前に更新プログラムを検証するときにも、同じことが当てはまります。

UEFI 2.3.1 Eratta C 仕様からの抜粋

9. 必須事項。署名されたファームウェア コードの整合性チェック。OEM によってインストールされたファームウェアは、前の定義に従い安全なファームウェア更新プロセスで保護されているか読み取り専用である場合、保護されていると見なすことができます。システムは、保護されていないすべてのファームウェア コンポーネント、UEFI ドライバー、UEFI アプリケーションが最小限の RSA-2048/SHA-256 (MD5 と SHA-1 は禁止されています) を使って署名されているかどうかを検証するものとします。また、これらの要件どおりに署名されていない UEFI アプリケーションおよびドライバーは、実行に失敗するものとします (これは、許容できる署名アルゴリズムの既定ポリシーです)。イメージの署名が、承認されたデータベースにない場合や、許可されていないデータベースにある場合は、イメージは起動しないでください。代わりに、その情報を Image Execution Information Table に記録するものとします。11. 必須事項。すべてのブート アプリとブート ローダーの署名を検証すること。電源投入時に、プラットフォームは、ブート ファームウェアの実行を開始し、アルゴリズムに従って公開キーの暗号化を使い、Windows ブート マネージャーまでのブート シーケンス内のすべてのイメージの署名を検証するものとします。

2. 問題の説明

セキュア ブート対応の UEFI BIOS のうち一部のビルドは、Tiano Core も含めて、既定では UEFI オプション ROM を認証しませんでした。セキュア ブートの開発時に署名された 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 ベンダーのツールによって異なる場合があります。

  

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

 

3. 影響が及ぶ範囲

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

ノート PC、ネットブック、ウルトラブック、タブレットのほとんどは影響を受けません。オプション ROM は通常、PCI/e、ISA、およびその派生物 (ExpressCard、miniPCI、CardBus、PCCard、LPC、ThunderBolt など) のバックプレーン バス上に存在しています。ノート PC がそのどれも公開していない場合、その危険性は大幅に減少します。さらに、オンボード ノート PC コンポーネント用の UEFI ドライバーはコア BIOS ファームウェアに統合されており、別のオプション ROM 上にはありません。したがってほとんどのノート PC はリスクにさらされていません。また、レガシのオプション ROM が無効になっていると、UEFI は PCI-方式のオプション ROM だけをサポートするように見えます。

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

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

セキュア ブート プラットフォームがプラットフォームに永続的に接続されていないデバイスのオプション ROM をサポートし、そのようなオプション ROM の認証機能をサポートする場合、「Network Protocols - UDP and MTFTP」で説明されたオプション ROM 検証方法と、UEFI 仕様 2.3.1 Errata C セクション 7.2 で説明された認証済み EFI 変数もサポートする必要があります。

4. テスト方法

ファームウェアを開発中で、それが Tiano Core に基づいている場合は、セクション 2.1 で言及した脆弱性がないかチェックしてください。別の IBV のファームウェアを使っている場合は、製造元にお問い合わせください。または、以下で述べるように自分でテストすることもできます。

次のものが必要です。

  • UEFI ファームウェアを搭載したテスト対象の PC

  • テスト対象の PC に装着するオプション ROM を搭載した PCI デバイス (ビデオ カードなど)

  • セキュア ブートが有効であること

テスト手順は以下のとおりです。

  1. テスト対象の PC に UEFI オプション ROM を搭載した 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 ファームウェアが正しく実装されている場合、UEFI オプション ROM ドライバーは読み込まれません。オプション ROM が存在するため、ファームウェアが証明書用に "Db" をチェックするためです。"Db" が NULL であるため、UEFI ドライバーの読み込みは失敗します。たとえば、ビデオ カードを使ってテストしている場合、画面に何も表示されないことが確認できます。

    • ファームウェアが正しく実装されていない場合、UEFI ドライバーはオプション ROM から読み込まれます。ファームウェアが "Db" の署名をチェックしないためです。たとえば、ビデオ カードを使ってテストしている場合、オプション ROM カードに接続したモニターに何かが表示されることが確認できます。

  

UEFI オプション ROM ドライバーが署名済みかどうかは関係ありません。DB が null で SB が有効であると、オプション ROM は読み込まれません (PK と KEK は登録されます)。

 

WHCK で入手できる、PK と KEK を生成するサンプル スクリプトを参照してください。スクリプトは http://go.microsoft.com/fwlink/?LinkId=321292 からダウンロードできます。付録 B にサンプル スクリプトと詳細が記載されています。

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

5. 修正方法

上記のテストが失敗する場合、IBV と協力して必要なバージョンを入手し、オプション ROM を検証するように設定します。ファームウェアがテストに合格することを確認します。出荷済み PC の場合、セキュア ファームウェア更新を実施する必要があります。NIST publication 800-147 または「Windows 8.1 セキュア ブート キーの作成と管理のガイダンス」をご覧ください。

セキュア ファームウェア更新のために PC をテストし、Windows HCK を (認証ツールではなく) テスト ツールとして活用することができます。

5.1. ドライバーの署名

UEFI オプション ROM に未署名のドライバーが格納されている可能性がある場合は、その修正方法について以下を読み進めてください。

オプション ROM ドライバーをそれぞれ個別に署名します。こうすると PCI オプション ROM のフォーマットが壊れます。必要なのは、組み合わせたオプション ROM を作成する前に UEFI ドライバーに署名することだけです。

UEFI ドライバーを OpROM に挿入する前に、UEFI イメージに署名して、それを UEFI シェルでセキュア ブートの有効/無効を切り替えてテストします (ドライバー ファイルの読み込みとアンロード)。組み合わせたオプション ROM に署名済みのドライバーを格納します。

IHV に Microsoft SysDev センターの話をして、SysDev センター経由で利用できるサービスを使って UEFI オプション ROM に署名してもらうこともできます。

5.2. 更新プログラムの検証

上記のテストを実行して、脆弱性が存在しないことを検証します。HCK テストを使って、機能が退化していないことを確認します。

6. 参考資料

付録 A: 未署名のオプション ROM ドライバーを使う別のテスト手法

この手法では、IHV からツールを入手して UEFI オプション ROM ドライバーに署名します。

次のものが必要です。

  • UEFI ファームウェアを搭載したテスト対象の PC

  • テスト対象の PC に装着する未署名のオプション ROM ドライバーを搭載した PCI デバイス (ビデオ カードなど)

  • セキュア ブートが有効であること

  • オプション ROM ドライバーが署名済みかどうか不明である場合に、オプション ROM ドライバーの署名を検出するオプション IHV ツール

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

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

付録 B: NULL db によってセキュア ブートを有効にするスクリプト

現在のセキュア ブート変数セット (PK と KEK) を使用することも、このテストのためにテスト用の変数を生成することもできます。

以下は、テスト用の PK と KEK を生成して、Db を NULL に設定するときに実行する手順です。セキュア ブートが有効になっていないことを確認してください。そうでない場合、以下の手順は署名済みの UEFI bin ファイルを必要とします。

  

セキュア ブート変数の Db、KEK、PK を逆順に設定して、UEFI bin ファイルに署名しなくても済むようにします。

 

この手順に先立って、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 を生成する

    これには、自分の PK を使うことも、WHCK のスクリプト (http://go.microsoft.com/fwlink/?LinkId=321292) を利用することもできます。

    サンプルを次に示します。

    # 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 のスクリプトを利用できます。独自のテスト用 KEK を生成する代わりに、http://go.microsoft.com/fwlink/?LinkId=321292 の Fabrikam_PK_SigList.bin を使うこともできます。

    サンプルを次に示します。

    # 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 に設定することです。

      

    唯一存在する KEK CA が Fabrikam Test KEK CA である場合 (つまり Windows KEK CA がない場合)、PC が 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 カードを差し込んでテストする

    テストはファームウェアが正しいかどうかに応じて成功または失敗します。たとえば、次のようになります。

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

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

関連トピック

Windows セキュア ブート キーの作成と管理のガイダンス
セキュア ブートの概要
Windows UEFI ファームウェア更新プラットフォームの機能の検証

 

 

表示: