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

  • [アーティクル]

このドキュメントは、製造環境でセキュア ブート キーと証明書を作成および管理する方法を OEM と ODM に示すためのものです。 ここでは、プラットフォーム キー (PK)、セキュア ファームウェア更新キー、サード パーティ キー交換キー (KEK) の作成、格納、取得に関連する質問を取り上げています。

メモ

デバイスOEM、企業、および顧客は、Microsoftが推奨するPK、KEK、DB、およびDBXバイナリをMicrosoftのセキュアブートオープンソースリポジトリで見つけることができます。 バイナリは、ファームウェアに簡単に統合できるように、想定されるEDKII形式にフォーマットされています。

メモ

Microsoft Corporation KEK CA 2011 は 2026 年に期限切れになる予定で、すべての OEM は、新しい Microsoft Corporation KEK CA 2023 の更新プログラムを作成、署名、および Microsoft に提出する必要があります。 これにより、Microsoft は新しい Microsoft KEK CA を使用して市販デバイスを更新でき、システムは 2026 年以降も引き続き DB と DBX の更新プログラムを受け取ります。 説明書とテスト資料については、https://aka.ms/KEKUpdatePackage をご覧ください。

UEFI とセキュア ブートに関する Windows の要件については、Windows ハードウェア認定要件に関するページに記載されています。 このホワイト ペーパーでは、新しい要件は導入されておらず、公式の Windows プログラムを表すこともありません。 これは証明書の要件だけではないガイダンスとして、セキュア ブート キーの作成と管理の効率的で安全なプロセスの構築に役立つことを目的としています。 UEFI セキュア ブートは、実行を許可する前にコードを認証するための公開キー基盤の使用方法に基づいているため、これは重要です。

読者は、UEFI の基礎、セキュア ブートに関する基本的な知識 (UEFI の仕様の第 27 章)、PKI セキュリティ モデルを理解しているものとします。

Windows でセキュア ブートを検証する要件、テスト、ツールは、Windows ハードウェア認定キット (HCK) に関するページから今すぐ入手できます。 ただし、これらの HCK リソースは、Windows 展開のキーの作成と管理には対応していません。 このホワイト ペーパーでは、ファームウェアで使用されるキーの展開についてパートナーに説明するときに役立つリソースとして、キー管理を取り上げます。 これは規定的なガイダンスを目的としておらず、新しい要件は含まれていません。

このページでは:

  • 「1. セキュア ブート、Windows、キー管理」では、Windows とセキュア ブートに適用されるときの、ブート セキュリティおよび PKI アーキテクチャに関する情報を取り上げます。
  • 「2. キー管理ソリューション」では、パートナーがキー管理を設計し、自身のニーズに合ったソリューションを設計できるようにすることを目的としています。
  • 「3. まとめとリソース」では、付録、チェックリスト、API、その他の参考資料が記載されています。

このドキュメントは、顧客対応 PC、工場展開ツール、キー セキュリティのベスト プラクティスを開発する出発点として機能します。

1. セキュアブート、Windows、キー管理

UEFI (Unified Extensible Firmware Interface) 仕様では、セキュア ブートと呼ばれるファームウェア実行認証プロセスが定義されています。 業界標準として、セキュア ブートでは、プラットフォーム ファームウェアで証明書を管理する方法、ファームウェアを認証する方法、オペレーティング システムがこのプロセスとどのように連携するかを定義します。

セキュア ブートでは、公開キー基盤 (PKI) プロセスに基づいて、モジュールの実行が許可される前に、モジュールの認証を行います。 これらのモジュールには、ファームウェア ドライバー、オプション ROM、ディスク上の UEFI ドライバー、UEFI アプリケーション、または UEFI ブート ローダーを含めることができます。 セキュア ブートでは、実行前のイメージ認証を通じて、ルートキットなどのブート前のマルウェア攻撃のリスクを軽減します。 Microsoft では、Windows 8 以上で、トラスト ブート セキュリティ アーキテクチャの一部として UEFI セキュア ブートを利用して、顧客のプラットフォーム セキュリティを改善しています。 セキュア ブートは、Windows ハードウェアの互換性要件に定義されているように、Windows 8 以上のクライアント PC と Windows Server 2016 に必要です。

セキュア ブート プロセスは、次の説明と図 1 に示すように機能します。

  1. ファームウェア ブート コンポーネント: ファームウェアでは、OS ローダーが信頼されていることを確認します (Windows または別の信頼されたオペレーティングシステム)。
  2. Windows ブート コンポーネント: BootMgr、WinLoad、Windows カーネル スタートアップ。 Windows ブート コンポーネントでは、各コンポーネントの署名を確認します。 信頼されていないコンポーネントは読み込まれず、代わりにセキュア ブート修復がトリガーされます。
    • ウイルス対策およびマルウェア対策ソフトウェアの初期化: このソフトウェアでは、トラスト ブートに不可欠なドライバーであることを確認する Microsoft 発行の特別な署名があるかどうかが調べられ、ブート プロセスの早期に起動します。
    • ブートに不可欠なドライバーの初期化: WinLoad でのセキュア ブートの検証の一部として、ブートに不可欠なすべてのドライバーの署名があるかどうかが調べられます。
  3. 追加 OS の初期化
  4. Windows ログオン画面

プラットフォーム整合性アーキテクチャのイメージ

図 1: Windows トラスト ブート アーキテクチャ

UEFIセキュアブートの実装は、Windows 8.1で導入されたMicrosoftのトラステッドブートアーキテクチャの一部です。 マルウェアによる悪用が進化するにつれ、好まれる攻撃ベクトルとしてブート パスが対象になる傾向が強くなっています。 マルウェア対策製品を完全に読み込めないようにする悪意のあるソフトウェアは、マルウェア対策製品を無効にできるので、このクラスの攻撃を防ぐことは困難でした。 Windows トラスト ブート アーキテクチャと、セキュア ブートによる信頼のルートの確立により、オペレーティング システム自体を読み込む前に、署名され認定され "良いとわかっている" コードとブート ローダーしか実行できないようにすることで、ブート パスで実行する悪意のあるコードから顧客を保護します。

1.1 公開キー基盤 (PKI) とセキュア ブート

PKI は、システム内で真正性と信頼性を確立します。 セキュア ブートでは、次の 2 つの高いレベルの目的で PKI を活用します。

  1. ブート中に、初期ブート モジュールが実行に対して信頼されているかどうかを判断するため。
  2. サービス要求に対する要求に、セキュア ブート データベースの変更とプラットフォーム ファームウェアの更新プログラムが含まれていることを認証するため。

PKI は次の要素から構成されます。

  • デジタル証明書を発行する証明機関 (CA)。
  • CA からの証明書を要求しているユーザーの ID を検証する登録機関。
  • キーを格納し、インデックスを作成する中央ディレクトリ。
  • 証明書管理システム。

1.2 公開キーの暗号化

公開キーの暗号化では、公開キーと秘密キーと呼ばれる数学的に関連する暗号化キーのペアが使用されます。 一方のキーがわかっていても、他方のキーを計算することは簡単にはできません。 一方のキーを使用して情報を暗号化した場合、対応するキーだけがその情報を復号できます。 セキュア ブートでは、秘密キーを使用してコードにデジタル署名を行い、公開キーを使用してそのコードの署名を検証し、その真正性を証明します。 秘密キーが侵害された場合、対応する公開キーを持つシステムは安全でなくなります。 これによりブート キット攻撃が行われる可能性があり、秘密キーのセキュリティの確保を担うエンティティの評判が損なわれます。

セキュア ブートの公開キー システムには、次の要素があります。

  • 1.2.1 RSA 2048 暗号

    RSA-2048 は、非対称暗号アルゴリズムです。 RSA-2048 モジュールを未加工形式で格納するために必要な容量は、2048 ビットです。

  • 1.2.2 自己署名証明書

    証明書の公開キーに対応する秘密キーで署名された証明書は、自己署名証明書と呼ばれます。 ルート証明機関 (CA) の証明書は、このカテゴリに分類されます。

  • 1.2.3 証明機関

    証明機関 (CA) は、証明書のサブジェクトの ID を確認し、証明書に含まれる公開キーにその ID をバインドする署名入り証明書を発行します。 CA は、秘密キーを使用して証明書に署名します。 自己署名ルート CA 証明書で、すべての関係者に対して、対応する公開キーを発行します。

    セキュア ブートでは、証明機関 (CA) には OEM (またはその代理) と Microsoft が含まれます。 CA は、信頼のルートを形成するキー ペアを生成し、その秘密キーを使用して、許可されている初期ブート EFI モジュールやファームウェア サービス要求などの正当な操作に署名します。 対応する公開キーは、セキュア ブート対応 PC 上の UEFI ファームウェアに埋め込まれて出荷され、これらの操作を検証するために使用されます

    (セキュア ブート モデルに関連する、CA とキー交換の使用方法については、インターネットで簡単に入手できます)。

  • 1.2.4 公開キー

    公開プラットフォーム キーは PC 上に付属し、アクセス可能、つまり "公開" になります。 このドキュメントでは、"pub" というサフィックスを使用して公開キーを示します。 たとえば、PKpub は PK の公開キー部分を示します。

  • 1.2.5 秘密キー

    PKI が機能するには、秘密キーを安全に管理する必要があります。 これは、組織内の非常に信頼性の高い少数の個人しかアクセスできないようにし、強力なアクセス ポリシーの制限が適用された物理的に安全な場所に配置する必要があります。 このドキュメントでは、秘密キーを示すためにサフィックス "priv" を使用します。 たとえば、PKpriv は PK の秘密キー部分を示します。

  • 1.2.6 証明書

    デジタル証明書の主な用途は、署名されたデータの出所 (バイナリなど) を検証することです。証明書の一般的な使用方法としては、トランスポート層セキュリティ (TLS) または Secure Sockets Layer (SSL) を使用したインターネット メッセージ セキュリティがあります。 証明書を使用して署名データを検証すると、受信者はデータの配信元や、転送中に変更されたかどうかがわかります。

    大まかに言うと、デジタル証明書には通常、識別名 (DN)、公開キー、署名が含まれています。 DN は、証明書の公開キーに対応する秘密キーを保持するエンティティ (たとえば、会社) を識別します。 秘密キーを使用して証明書に署名し、証明書に署名を置くと、秘密キーが公開キーと結び付けられます。

    証明書には、他の種類のデータを含めることができます。 たとえば、X.509 証明書には、証明書の書式、証明書のシリアル番号、証明書の署名に使用されているアルゴリズム、証明書を発行した CA の名前、証明書を要求したエンティティの名前と公開キー、および CA の署名が含まれます。

  • 1.2.7 証明書のチェーン

    引用: 証明書のチェーン:

    root ca は自己署名されており、その他は root ca によって署名されています

    図 2: 3 つの証明書のチェーン

    ユーザー証明書は多くの場合、CA の秘密キーなど、別の秘密キーによって署名されます。 これにより、2 つの証明書のチェーンが構成されます。 ユーザー証明書が本物であることを検証する場合、その署名の検証が行われますが、これには証明書から CA の公開キーを得る必要があります。 ただし、CA の公開キーを使用するには、その前にそれを同封している CA 証明書を検証しておく必要があります。 CA 証明書は自己署名されているので、CA 公開キーを使用してこの証明書を検証します。

    ユーザー証明書をルート CA の秘密キーで署名する必要はありません。 CA の秘密キーで署名されている証明書を持つ中間証明機関の秘密キーで署名されている場合があります。 これは、ユーザー証明書、中間証明書、CA 証明書の 3 つの証明書のチェーンの例です。 ただし、複数の中間証明機関でチェーンが構成されることがあるので、証明書チェーンの長さはさまざまです。

1.3 セキュア ブート PKI の要件

UEFI で定義された信頼のルートは、プラットフォーム キーと、OEM または ODM がファームウェア コアに含めたすべてのキーで構成されます。 UEFI より前のセキュリティと信頼のルートは、UEFI セキュア ブート プロセスでは扱いませんが、代わりに、このホワイト ペーパーで参照されている米国国立標準技術研究所 (NIST) および Trusted Computing Group (TCG) の出版物で取り上げられています。

  • 1.3.1 セキュア ブートの要件

    セキュアブートを実装するには、次のパラメータを考慮する必要があります。

    • 顧客要件
    • Windows ハードウェア互換性の要件
    • キーの生成と管理の要件。

    ハードウェア セキュリティ モジュール (HSM) などのセキュア ブート キー管理用のハードウェアを選択し、政府や他の機関に出荷する PC に関する特別な要件を考慮し、最後にさまざまなセキュア ブート キーのライフ サイクルを作成、設定、管理するプロセスを検討する必要があります。

  • 1.3.2 セキュア ブート関連のキー

    セキュア ブートに使用されるキーは次のとおりです。

    pk、kek、db、dbx、ファームウェア キー、winrt キー

    図 3: セキュア ブートに関連したキー

    上の図 3 は、セキュア ブートを使用する PC の署名とキーを表しています。 プラットフォームは、OEM が製造時にファームウェアにインストールしたプラットフォーム キーを介してセキュリティで保護されます。 その他のキーは、ファームウェアの実行を許可または禁止するキーを格納したデータベースへのアクセスを保護するために、セキュア ブートで使用されます。

    認可されたデータベース (db) には、信頼されたファームウェア コンポーネントとオペレーティング システム ローダーを表す公開キーと証明書が含まれています。 許可されていない署名データベース (dbx) には、悪意のある脆弱なコンポーネントのハッシュと、侵害されたキーと証明書が含まれています。また、これらの悪意のあるコンポーネントの実行がブロックされます。 これらのポリシーの強さは、Authenticode と公開キー基盤 (PKI) を使用してファームウェアに署名する方法に基づいています。 PKI は、情報交換中に信頼を確立する証明書の作成、管理、取り消しを行うための十分に確立されたプロセスです。 PKI は、セキュア ブートのセキュリティ モデルの中核を担います。

    これらのキーの詳細を次に示します。

  • 1.3.3 プラットフォーム キー (PK)

    UEFI 2.3.1 Errata C のセクション 27.5.1 によると、プラットフォーム キーによって、プラットフォーム所有者とプラットフォーム ファームウェアの間に信頼関係が確立されます。 プラットフォーム所有者は、UEFI 2.3.1 Errata C のセクション 7.2.1 で指定されているように、キーの公開キー部分 (PKpub) をプラットフォーム ファームウェアに登録します。この手順により、プラットフォームはセットアップ モードからユーザー モードに移行します。 Microsoft では、プラットフォーム キーを、公開キー アルゴリズムが RSA、公開キーの長さが 2048 ビット、署名アルゴリズムが sha256RSA のタイプ EFI_CERT_X509_GUID にすることをお勧めします。 記憶域に問題がある場合、プラットフォームの所有者は、タイプ EFI_CERT_RSA2048_GUID を使用できます。 公開キーは、このドキュメントで前述したように署名を確認するために使用されます。 プラットフォーム所有者は、後でキーの秘密キー部分 (PKpriv) を使用できます。

    • プラットフォーム所有者を変更するには、セキュア ブートを無効にする UEFI 定義のセットアップ モードに、ファームウェアを設定する必要があります。 製造中にこれを行う必要がある場合にのみ、セットアップ モードに戻します。
    • デスクトップおよびサーバーデバイスの場合、OemはPKとそれに関連付けられている必要なPKIを管理するか、OEM用にMicrosoftが管理するPKを使用することができます。 Microsoftが管理するPKは、Microsoft HSMによって保護され、PKIのベストプラクティスの一部として管理されます。 これは、Windowsエコシステムの推奨されるPKです。

    1.3.3.1 プラットフォーム キーを登録するキー交換キー (KEK) を登録または更新するには

    プラットフォーム所有者は、UEFI 2.3.1 Errata C のセクション 7.2.1 で指定されているように UEFI ブート サービス SetVariable() を呼び出し、プラットフォームをリセットすることにより、プラットフォーム キーの公開キー部分 (PKpub) を登録します。 プラットフォームがセットアップ モードの場合、新しい PKpub に、それに対応する PKpriv で署名する必要があります。 プラットフォームがユーザー モードの場合、新しい PKpub に、現在の PKpriv で署名する必要があります。 PK が EFI_CERT_X509_GUID のタイプの場合、これは、PK 下で発行された任意の証明書の秘密キーではなく、即時の PKpriv で署名する必要があります。

    1.3.3.2 プラットフォーム キーのクリア

    プラットフォーム所有者は、変数サイズを 0 で UEFI ブート サービス SetVariable() を呼び出し、プラットフォームをリセットすることで、プラットフォーム キーの公開キー部分 (PKpub) をクリアします。 プラットフォームがセットアップ モードの場合は、空の変数を認証する必要はありません。 プラットフォームがユーザー モードの場合、空の変数に現在の PKpriv で署名する必要があります。詳細については、UEFI 仕様 2.3.1 Errata C の下のセクション 7.2 (変数サービス) を参照してください。 実稼働 PKpriv をパッケージの署名に使用してプラットフォームをリセットしないように強くお勧めします。リセットした場合、セキュア ブートをプログラムで無効にできるようになるためです。 これは主に実稼働前のテスト シナリオです。

    プラットフォーム キーはまた、セキュリティで保護されたプラットフォーム固有の方法を使用してクリアできます。 この場合、グローバル変数のセットアップ モードも 1 に更新する必要があります。

    image: pk はセットアップ モードまたはユーザー モードを決定します

    図 4: プラットフォーム キーの状態の図

    1.3.3.3 PK の世代

    UEFI の推奨事項に従って、公開キーは、PC での改ざんおよび削除に対して耐性のある不揮発性ストレージに格納する必要があります。 秘密キーはパートナーまたはOEMのセキュリティオフィスで安全に保持され、公開キーのみがプラットフォームに読み込まれます。 詳細については、セクション 2.2.1 および 2.3 を参照してください。

    Microsoftは、PK証明書の管理とセキュリティ保護の責任をなくすために、OEM向けにPKを提供しています。 PKはMicrosoft HSMによって保護され、Microsoft PKI操作の一部として管理されます。

    生成される PK の数は、プラットフォーム所有者 (OEM) の裁量に任されます。 これらのキーは次のようになります。

    1. PC ごとに 1 つ。 デバイスごとに 1 つの一意のキーを用意します。 これは、政府機関、金融機関、または高いセキュリティのニーズを持つその他のサーバーの顧客に必要になる可能性があります。 多数の PC に対して秘密キーと公開キーを生成するには、追加のストレージと暗号化処理能力が必要になります。 このため、将来、ファームウェアの更新プログラムをデバイスにプッシュするときに、対応する PK とデバイスをマッピングする複雑さが生じます。 HSM ベンダーに基づいて、多数のキーの管理に使用できる異なる HSM ソリューションがいくつかあります。 詳細については、HSM を使用したセキュア ブート キーの生成に関するページを参照してください。

    2. モデルごとに 1 つ。 PC モデルごとに 1 つのキーを用意します。 この場合のトレードオフは、キーが侵害されると、同じモデル内のすべてのマシンが脆弱になるということです。 Microsoft では、これをデスクトップ PC にお勧めします。

    3. 製品ラインごとに 1 つ。 キーが侵害された場合、製品ライン全体が脆弱になります。

    4. OEM ごとに 1 つ。 これはおそらく設定が最も簡単ですが、キーが侵害された場合、製造したすべての PC が脆弱になります。 製造現場での操作を高速化するために、PK や、場合によっては他のキーを事前に生成し、安全な場所に格納することができます。 これらを後で取得して、アセンブリ ラインで使用できます。 第 2 章と第 3 章に、詳細があります。

    1.3.3.4 PK のキー更新

    これは、PK が侵害された場合や、セキュリティ上の理由で独自の PK を登録することにした顧客の要件として必要になることがあります。

    キー更新は、PK を作成するために選択された方法に基づいて、モデルまたは PC のどちらかに対して実行できます。 より新しい PC はすべて、新しく作成された PK で署名されます。

    実稼働 PC で PK を更新するには、PK またはファームウェア更新パッケージを置き換える既存の PK で署名された変数の更新が必要です。 OEM は SetVariable() パッケージを作成し、PK を変更するだけの PowerShell などの単純なアプリケーションで配布することもできます。 ファームウェア更新パッケージは、セキュア ファームウェア更新キーによって署名され、ファームウェアによって検証されます。 ファームウェア更新を実行して PK を更新する場合は、KEK、db、dbx が確実に保持されるように注意を払う必要があります。

    すべての PC で、セキュア ファームウェア更新キーとして PK を使用しないことをお勧めします。 PKpriv が侵害された場合は、セキュア ファームウェア更新キーも同様に侵害されます (これらは同じなので)。 この場合、更新のプロセスも侵害されているので、新しい PKpub を登録する更新が可能でなくなる可能性があります。

    SOC PC では、セキュア ファームウェア更新キーとして PK を使用しないもう 1 つの理由があります。 これは、セキュア ファームウェア更新キーが、Windows ハードウェア認定要件を満たす PC 上のヒューズに完全に書き込まれるためです。

  • 1.3.4 キー交換キー (KEK) キー交換キーは、オペレーティング システムとプラットフォーム ファームウェアとの間に信頼関係を確立します。 各オペレーティング システム (および場合により、プラットフォーム ファームウェアと通信する必要がある各サード パーティ アプリケーション) は、公開キー (KEKpub) をプラットフォーム ファームウェアに登録します。

    1.3.4.1 キー交換キーの登録

    キー交換キーは、「1.4 署名データベース (db および dbx)」に記述されたとおり、署名データベースに格納されます。 署名データベースは、認証された UEFI 変数として格納されます。

    プラットフォーム所有者がキー交換キーを登録するには、UEFI 仕様 2.3.1 Errata C 下のセクション 7.2 (変数サービス) で指定されたとおりに、EFI_VARIABLE_APPEND_WRITE 属性セットと、新しいキーを含む Data パラメーターを使用して SetVariable() を呼び出すか、UEFI 仕様 2.3.1 Errata C 下のセクション 7.2 (変数サービス) で指定されたとおりに、GetVariable() を使用してデータベースを読み取り、新しいキー交換キーを既存のキーに追加し、EFI_VARIABLE_APPEND_WRITE 属性セットを使用せずに SetVariable()を使用してデータベースを書き込みます。

    プラットフォームがセットアップ モードの場合、署名データベース変数に署名する必要はありませんが、セクション 7.2.1 で認証済み変数に対して指定されているように、SetVariable() 呼び出しのパラメーターを準備する必要はあります。 プラットフォームがユーザー モードの場合、署名データベースを現在の PKpriv で署名する必要があります

    1.3.4.2 KEK のクリア

    KEK を "クリア" (削除) することもできます。 PK がプラットフォームにインストールされていない場合は、"clear" 要求に署名する必要がないことに注意してください。 署名されている場合は、KEK をクリアするには PK 署名パッケージが必要です。また、db または dbx のどちらかをクリアするには、KEK に存在する任意のエンティティによって署名されたパッケージが必要です。

    1.3.4.3 Microsoft KEK

    次の2つのMicrosoft KEK証明書は、dbxを更新して無効なイメージの失効を有効にするために必要です。また、新しいWindows署名済みイメージを準備するためにdbを更新する場合もあります。

  1. Microsoft Corporation KEK CA 2011

    • SHA-1 証明書ハッシュ: 31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30。
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    • Microsoft では、パートナーに証明書を提供しており、これは EFI_CERT_X509_GUID または EFI_CERT_RSA2048_GUID タイプの署名として追加できます。
    • Microsoft KEK 証明書は https://go.microsoft.com/fwlink/?LinkId=321185 からダウンロードできます。

  2. Microsoft Corporation KEK 2K CA 2023

    • SHA-1 証明書ハッシュ: 45 9a b6 fb 5e 28 4d 27 2d 5e 3e 6a bc 8e d6 63 82 9d 63 2b。
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    • Microsoft では、パートナーに証明書を提供しており、これは EFI_CERT_X509_GUID または EFI_CERT_RSA2048_GUID タイプの署名として追加できます。
    • Microsoft KEK 証明書は https://go.microsoft.com/fwlink/?linkid=2239775 からダウンロードできます。

1.3.4.4 KEKDefaultプラットフォームベンダーは、KEKDefault変数にキー交換キーの既定のセットを提供する必要があります。 詳細については、UEFI 仕様セクション 27.3.3 を参照してください。

1.3.4.5 OEM/サード パーティ KEK - 複数の KEK の追加

お客様とプラットフォーム所有者は、独自のKEKを持つ必要はありません。 Windows RT 以外の PC では、追加の OEM または信頼できるサード パーティの db および dbx のコントロールを許可するために、OEM に KEK を追加できます。

  • 1.3.5 セキュア ブート ファームウェア更新キーセキュア ファームウェア更新キーは、ファームウェアを更新する必要がある場合に、これに署名するために使用されます。 このキーには、RSA-2048 の最小のキー強度が必要です。 すべてのファームウェア更新プログラムは、OEM、ODM や IBV (独立系 BIOS ベンダー) などの信頼できる代理人、または安全な署名サービスによって、安全に署名する必要があります。

    NIST の出版物 800-147 によると、フィールド ファームウェア更新では、次のガイドラインのすべての要素がサポートされている必要があります。

    ファームウェア フラッシュ ストアに対する更新はすべて作成者が署名する必要があります。

    ファームウェアでは、更新の署名を確認する必要があります。

  • 1.3.6 セキュア ファームウェア更新用のキーの作成

    公開キー部分は PC 上に存在するので、すべてのファームウェア更新プログラムに署名するために同じキーが使用されます。 セキュア ファームウェア更新キーにチェーンされるキーで、ファームウェア更新に署名することもできます。

    PK のように PC ごとに 1 つのキーがあることも、モデルごとに 1 つ、製品ラインごとに 1 つ存在することもあります。 PC ごとに 1 つのキーがある場合、これは、一意の更新パッケージを数百万個生成する必要があることを意味します。 リソースの可用性に基づいて、どの方法が適しているかを検討してください。 モデルまたは製品ラインごとに 1 つのキーを用意することはまずまずの妥協案になります。

    セキュアファームウェアアップデートの公開キー (またはスペースを節約するためのハッシュ) は、プラットフォーム上の保護されたストレージ (通常は保護されたフラッシュ (PC) またはワンタイムプログラマブルヒューズ (SOC) ) に保存されます。

    このキーのハッシュだけが格納されている場合 (領域を節約するため)、ファームウェア更新にはキーが含まれ、更新プロセスの第 1 段階では、更新の公開キーがプラットフォームに格納されているハッシュと一致することを確認します。

    カプセルは、再起動をまたいで、OS から UEFI 環境にデータを渡すことができる手段です。 Windows は、UEFI UpdateCapsule() を呼び出して、システムと PC のファームウェアの更新プログラムを配信します。 ExitBootServices() を呼び出す前の起動時に、Windows は、Windows ドライバー ストアで見つかった新しいファームウェア更新プログラムを UpdateCapsule() に渡します。 UEFI システム ファームウェアでは、このプロセスを使用して、システムと PC のファームウェアを更新できます。 この Windows のファームウェア サポートを利用することで、OEM は、システムと PC の両方のファームウェアの更新に、同じ共通形式とプロセスを使用できます。 ファームウェアでは、Windows の UEFI UpdateCapsule () をサポートするために、ACPI ESRT テーブルを実装する必要があります。

    Windows UEFI ファームウェア更新プラットフォームのサポートの実装の詳細については、Windows UEFI ファームウェア更新プラットフォームのドキュメントを参照してください。

    更新カプセルはメモリまたはディスクに配置できます。 Windows は、メモリ更新プログラムでサポートされます。

    1.3.6.1 カプセル (カプセルインメモリ)

    メモリ内更新カプセルが動作するためのイベントのフローを次に示します。

    1. カプセルが、OS のアプリケーションによってメモリに格納されます
    2. 保留中の更新プログラムについて BIOS に通知するように、メールボックス イベントが設定されます
    3. PC が再起動し、カプセル イメージと更新プログラムが BIOS によって実行されているか検証されます

  • 1.3.7 通常のファームウェア更新のワークフロー

    1. ファームウェア ドライバーをダウンロードしてインストールします。
    2. 再起動します。
    3. OS ローダーは、ファームウェアを検出して検証します。
    4. OS ローダーは、バイナリ BLOB を UEFI に渡します。
    5. UEFI はファームウェアの更新を実行します (このプロセスはシリコン ベンダーによって所有されます)。
    6. OS ローダーの検出が正常に完了しました。
    7. OS の起動が完了します。

1.4 署名データベース (db および dbx)

  • 1.4.1 許可された署名データベース (db)

    EFI _IMAGE_SECURITY_DATABASE db の内容により、読み込まれたイメージを検証するときに、どのイメージが信頼されるかが制御されます。 許可されたイメージを識別するために、データベースに複数の証明書、キー、ハッシュを格納できます。

    Windows OS Loaderをロードするには、次の2つの証明書をdbに含める必要があります。

  1. Microsoft Windows Production PCA 2011

    • SHA-1 証明書ハッシュ: 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d。
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    • Microsoft では、パートナーに証明書を提供しており、これは EFI_CERT_X509_GUID または EFI_CERT_RSA2048_GUID タイプの署名として追加できます。
    • Windows Production PCA 2011は、ここからダウンロードできます。 https://go.microsoft.com/fwlink/p/?linkid=321192.

  2. Windows UEFI CA 2023

    • SHA-1 証明書ハッシュ: 45 a0 fa 32 60 47 73 c8 24 33 c3 b7 d5 9e 74 66 b3 ac 0c 67。
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    • Microsoft では、パートナーに証明書を提供しており、これは EFI_CERT_X509_GUID または EFI_CERT_RSA2048_GUID タイプの署名として追加できます。
    • Windows UEFI CA 2023は、次の場所からダウンロードできます。https://go.microsoft.com/fwlink/?linkid=2239776.

Windowsのみを起動するようにロックダウンされているシステムを除き、OEMは、サードパーティ製のUEFIドライバーやアプリケーションをユーザーが追加の手順を実行せずにPCで実行できるように、Microsoftサードパーティ製のUEFI Caを含めることを検討する必要があります。

  1. Microsoft Corporation UEFI CA 2011

    • SHA-1 証明書ハッシュ: 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3。
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    • Microsoft では、パートナーに証明書を提供しており、これは EFI_CERT_X509_GUID または EFI_CERT_RSA2048_GUID タイプの署名として追加できます。
    • Microsoft Corporation UEFI CA 2011は以下からダウンロードできます。https://go.microsoft.com/fwlink/p/?linkid=321194.

  2. Microsoft UEFI CA 2023

    • SHA-1 証明書ハッシュ: b5 ee b4 a6 70 60 48 07 3f 0e d2 96 e7 f5 80 a7 90 b5 9e aa。
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    • Microsoft では、パートナーに証明書を提供しており、これは EFI_CERT_X509_GUID または EFI_CERT_RSA2048_GUID タイプの署名として追加できます。
    • Microsoft UEFI CA 2023は、次の場所からダウンロードできます。https://go.microsoft.com/fwlink/?linkid=2239872.

  • 1.4.2 DbDefault: プラットフォームベンダーは、dbDefault変数に署名データベースのエントリの既定のセットを提供する必要があります。 詳細については、UEFI 仕様のセクション 27.5.3 を参照してください。

  • 1.4.3 許可されていない署名データベース (dbx)

    db を確認する前にイメージを検証するときは、EFI_IMAGE_SIGNATURE_DATABASE1 dbx の内容を確認する必要があり、どの一致でもイメージが実行されないようにする必要があります。 許可されていないイメージを識別するために、データベースに複数の証明書、キー、ハッシュを格納できます。 Windows ハードウェア認定要件では、dbx が存在する必要があることが示されているため、0 の SHA-256 ハッシュなどのダミー値は、Microsoft が dbx 更新プログラムの配信を開始するまでの間、安全なプレースホルダーとして使用できます。 ここをクリックして、Microsoft から最新の UEFI 失効リストをダウンロードします。

  • 1.4.4 DbxDefault: プラットフォーム ベンダーは、dbxDefault 変数に署名データセットのエントリの既定のセットを提供することができます。 詳細については、UEFI 仕様のセクション 27.5.3 を参照してください。

1.5 すべての PC でのセキュア ブートに必要なキー

メモ

デバイスOEM、企業、および顧客は、Microsoftが推奨するPK、KEK、DB、およびDBXバイナリをMicrosoftのセキュアブートオープンソースリポジトリで見つけることができます。 バイナリは、ファームウェアに簡単に統合できるように、想定されるEDKII形式にフォーマットされています。

キー/DB 名 変数 Owner メモ

PKpub

PK

OEM

PK – 1のみ。 RSA 2048 以上である必要があります。

https://go.microsoft.com/fwlink/?linkid=2255361

Microsoft Corporation KEK CA 2011

Microsoft Corporation KEK 2K CA 2023

KEK

Microsoft

db と dbx の更新を許可します。

https://go.microsoft.com/fwlink/p/?linkid=321185

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Microsoft Windows Production CA 2011

Windows UEFI CA 2023

db

Microsoft

署名データベース (db) のこのCAは、Windowsの起動を許可します。 https://go.microsoft.com/fwlink/?LinkId=321192

https://go.microsoft.com/fwlink/p/?linkid=2239776.

許可されていない署名データベース

dbx

Microsoft

Microsoft からの既知の不適切なキー、CA、またはイメージの一覧

セキュア ファームウェア更新キー

OEM

このキーを PK とは別のものにすることをお勧めします

表 1: セキュア ブートに必要なキー/db

2. キー管理ソリューション

以下に、比較に使用したメトリックの一部を示します。

2.1 使用されるメトリック

次のメトリックは、UEFI 仕様 2.3.1 Errata C の要件と自身のニーズに基づいて、HSM PC を選択する場合に役立ちます。

  • RSA 2048 以上をサポートしていますか? - UEFI 仕様 2.3.1 Errata C では、キーを RSA-2048 以上にすることを勧めています。
  • キーを生成して署名する機能はありますか?
  • 格納できるキーの数はどれくらいですか? HSM または接続されているサーバーにキーが格納されますか?
  • キー取得の認証方法。 一部の PC では、キーの取得に複数の認証エンティティが存在できます。

価格

  • 価格ポイントはどのようになっていますか? HSM の価格は、利用可能な機能に応じて、1,500 ドルから 70,000 ドルに及びます。

製造環境

  • 製造現場での操作速度。 暗号化プロセッサを使用すると、キーの作成とアクセスを高速化できます。
  • セットアップ、デプロイ、メンテナンスの容易さ。
  • スキルセットとトレーニングが必要ですか?
  • バックアップと高可用性のためのネットワーク アクセス

標準と遵守状況

  • 障害どのレベルの FIPS 準拠を満たしていますか? 改ざんに対する耐性はありますか?
  • 他の標準 (MS 暗号化 API など) のサポート。
  • 政府機関や他の機関の要件を満たしていますか?

可用性とディザスター リカバリー

  • キー のバックアップは許可されますか?

    バックアップは、CA コンピューターおよび HSM とは異なる物理的な場所である安全な場所でオンサイトで格納することも、オフサイトの場所に格納することも、あるいはその両方に格納することもできます。

  • ディザスター リカバリーに高可用性は可能ですか?

2.2 キー管理オプション

  • 2.2.1 ハードウェア セキュリティ モデル (HSM)

    上記の条件に基づくと、これがおそらく最も適した安全なソリューションです。 ほとんどの HSM では、FIPS 140-2 レベル 3 準拠を満たしています。 FIPS 140-2 レベル 3 準拠は、認証に厳しく、キーが HSM からエクスポートまたはインポートされないことが要求されます。

    キー ストレージの複数の方法がサポートされています。 これらは、HSM 自体にローカルに格納することも、HSM に接続されているサーバーに格納することもできます。 サーバーでは、キーが暗号化されて格納されており、多くのキーを格納する必要があるソリューションに最適です。

    暗号化モジュール セキュリティ ポリシーでは、不正開封防止シール、ロック、タンパ レスポンスとゼロ化スイッチ、アラームなど、暗号化モジュールに実装されている物理的セキュリティ メカニズムを含む、物理的セキュリティ ポリシーを指定する必要があります。 また、これは、不正開封防止シールの定期的検査やタンパ レスポンスとゼロ化スイッチのテストなど、物理的セキュリティを維持できるようにするためにオペレーターが必要とするアクションも指定できるようにします。

    • 2.2.1.1 ネットワーク型 HSM

      このソリューションは、セキュリティ、標準への準拠、キーの生成、ストレージ、取得の観点から、クラス最高です。 これらの PC のほとんどで高可用性がサポートされ、キーをバックアップする機能が用意されています。

      これらの製品のコストは、提供される追加のサービスに基づいて数万ドルになる可能性があります。

    • 2.2.1.2 スタンドアロン HSM

      これらはスタンドアロン サーバーで適切に機能します。 Microsoft CAPI と CNG、または HSM でサポートされているその他のセキュリティで保護された API を使用できます。 これらの HSM には、USB、PCIe、PCMCIA バスをサポートするさまざまなフォーム ファクターがあります。

      これらは必要に応じて、キーのバックアップと高可用性をサポートします。

  • 2.2.2 カスタム ソリューション プロバイダー

    公開キー暗号化は難易度が高い可能性があり、おそらく新しいものである暗号化の概念を理解する必要があります。 セキュア ブートを製造環境で機能させる場合に役立つカスタム ソリューション プロバイダーが存在します。

    製造環境でセキュア ブート PKI を機能させるために、BIOS ベンダー、HSM 企業、PKI コンサルティング会社から提供されるさまざまなカスタム ソリューションがあります。

    このプロバイダーの一部を以下に示します。

    • 2.2.2.1 BIOS ベンダー

      カスタム ソリューションを提供できる BIOS ベンダーがいくつかあります。

    • 2.2.2.2 HSM ベンダー

      一部の HSM ベンダーは、カスタム コンサルティングを提供できます。 詳細については、「HSM を使用したセキュア ブート キーの生成と署名 (例)」を参照してください。

  • 2.2.3 トラステッド プラットフォーム モジュール (TPM)

    トラステッド プラットフォーム モジュール (TPM) は、暗号化に使用される暗号化キーを格納する、マザーボード上のハードウェア チップです。 多くのコンピューターにはTPMが搭載されていますが、PCに搭載されていない場合は、追加することはできません。 有効にすると、トラステッド プラットフォーム モジュールは、Microsoft BitLocker 機能などのディスク全体の暗号化製品をセキュリティで保護できます。 PC がシステムの検証または認証プロセスを完了するまで、ハード ドライブはロックまたはシールされたままにされます。

    TPM では、暗号化と復号化のプロセスで使用されるキーを生成、格納、保護できます。

    TPM の欠点は、製造環境での処理を高速化する高速暗号化プロセッサがない場合がある点です。 また、多数のキーを格納する場合にも適していません。 バックアップと高可用性、および FIPS 140-2 レベル 3 への標準準拠は利用できないことがあります。

  • 2.2.4 スマート カード

    スマート カードでは、キーを生成して格納できます。 認証や改ざん防止など、HSMがサポートするいくつかの機能を共有していますが、キーストレージやバックアップはあまり含まれていません。 これらには、手動での介入が必要であり、パフォーマンスが低下する可能性があるので、自動化や実稼働環境での使用には適していない可能性があります。

    スマート カードの欠点は TPM に似ています。 これらには、製造環境での処理を高速化する高速暗号化プロセッサがない場合があります。 また、多数のキーを格納する場合にも適していません。 バックアップと高可用性、および FIPS 140-2 レベル 3 への標準準拠は利用できないことがあります。

  • 2.2.5 Extended Validation 証明書

    EV 証明書は、ハードウェア トークンに格納されているプライベート キーを含んだ高アシュアランス証明書です。 これを使用すると、より強力なキー管理方法を確立できます。 EV 証明書には、スマート カードと同じ欠点があります。

  • 2.2.6 ソフトウェア中心のアプローチ (非推奨)

    キー管理には暗号化 API を使用します。 これには、暗号化されたハード ドライブのキー コンテナーにキーを格納することが含まれる場合があり、追加のサンドボックス化とセキュリティに仮想マシンを使用する可能性もあります。

    これらのソリューションは、HSM を使用するほど安全ではなく、より高い攻撃ベクトルをさらすことになります。

    2.2.6.1 Makecert (非推奨)

    Makecert は Microsoft ツールであり、キーの生成に次のように使用できます。 攻撃対象領域を最小限に抑えるために、PC を "エア ギャップ" で隔離する必要があります。 PKpriv がオンになっている PC をネットワークに接続でしないでください。 これは、セキュリティで保護された場所に配置する必要があり、実際の HSM ではない場合は、理想的には少なくともスマート カード リーダーを使用する必要があります。

    makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r

    詳細については、「Makecert.exe (証明書作成ツール)」を参照してください。

    このソリューションはお勧めできません。

2.3 セキュア ブート キーの HSM キーの生成とストレージ

  • 2.3.1 秘密キーの格納

    RSA-2048 キーごとに必要な領域は 2048 ビットです。 キーのストレージの実際の場所は、選択したソリューションによって異なります。 HSM は、キーを格納する優れた方法です。

    製造現場での PC の物理的な場所は、セキュリティで保護されたケージのようにユーザーのアクセスが限られた保護領域にする必要があります。

    要件に応じて、これらのキーをさまざまな地理的な場所に格納したり、別の場所にバックアップしたりすることもできます。

    これらのキーのキー更新の要件は、顧客に応じて異なることがあります (連邦ブリッジ証明機関のキー更新のガイドラインについては、「付録 A」を参照してください)。

    これらは、1 年に 1 回実行できます。 これらのキーには、(キー更新の要件などに応じて) 最大 30 年間アクセスできる必要があります。

  • 2.3.2 プライベート キーの取得

    多くの理由から、キーを取得することが必要になる場合があります。

    1. 侵害されたことが原因で更新された PK を発行するため、または政府機関やその他の機関の規制に準拠するために、PK を取得する必要が生じることがあります。
    2. KEKpri は、db と dbx を更新するために使用されます。
    3. セキュアファームウェアアップデートキー–priは新しいアップデートの署名に使用されます。

  • 2.3.3 認証

    FIPS 140-2 によると、認証はアクセスのレベルに基づいています。

    Level 2 (レベル 2)

    セキュリティ レベル 2 では、少なくともロールベースの認証が必要です。ここでは、特定のロールを担い、対応する一連のサービスを実行する権限がオペレーターにあるかを暗号化モジュールで認証します。

    Level 3 (レベル 3)

    セキュリティ レベル 3 では、ID ベースの認証メカニズムが必要です。これにより、セキュリティ レベル 2 で指定されたロールベースの認証メカニズムで得られるセキュリティが強化されます。 暗号化モジュールは、オペレーターの ID を認証して、識別されたオペレーターに特定のロールを担い、対応する一連のサービスを実行する権限があることを確認します。

    HSMのようなPCは、IDベースの 「k of m認証」 を必要とするセキュリティレベル3をサポートしています。 これは、トークンを持つ HSM へのアクセス権が k 個のエンティティに付与されるが、所定のポイントでは、秘密キーへのアクセス権を HSM から取得するときに認証が機能するには、m 個のうち少なくとも k 個のトークンが存在する必要があるということを意味します。

    たとえば、5 個のうち 3 個のトークンを持っていると HSM へのアクセスが認証されるというようにすることもできます。 これらのメンバーは、セキュリティ担当者、トランザクション認可者、経営陣のメンバーから構成されます。

    HSM トークン

    次のようにトークンが存在することを必要とするポリシーを HSM で設定することもできます。

    • ローカルで

    • リモートで

    • 自動化するように構成

    適切な方法としては、トークンとトークンごとのパスワードの組み合わせを使用してください。

2.4 セキュア ブートとサード パーティ署名

  • 2.4.1 UEFI ドライバーの署名

    このドキュメントの他の箇所で説明されているように、UEFI ドライバーは、db 内の CA またはキーで署名されているか、db に含まれているドライバー イメージのハッシュを含んでいる必要があります。 Microsoft は、Microsoft Corporation UEFI CA 2011 を使用して、WHQL ドライバー署名サービスに似た UEFI ドライバー署名サービスを提供しています。 これによって署名されたドライバーはすべて、Microsoft UEFI CA を含んだあらゆる PC でシームレスに動作します。 また、OEM が信頼できるドライバーに署名し、データベースに OEM CA を含めることも、データベースにドライバーのハッシュを含めることもできます。 どのような場合でも、UEFI ドライバー (オプション ROM) は、データベース内で信頼されていない場合、実行されません。

    システム ファームウェア イメージに含まれているドライバーはすべて、再検証する必要はありません。 システム イメージ全体に参加することで、ドライバーが PC 上で信頼されているという十分な保証が得られます。

    Microsoft では、UEFI ドライバーの署名を希望するすべてのユーザーがこれを利用できるようにしています。 この証明書は、Windows HCK セキュア ブート テストの一部です。 [このブログ](https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) に従って、UEFI CA の署名ポリシーと更新プログラムの詳細を確認してください。

  • 2.4.2 ブート ローダー

    Microsoft UEFI ドライバー署名証明書は、他の OS に署名するために使用できます。 たとえば、FedoraのLinuxブートローダーはこのブートローダーによって署名されます。

    このソリューションでは、これ以上証明書をキーDbに追加する必要はありません。 コスト効率に優れていることに加え、どの Linux ディストリビューションでも使用できます。 このソリューションは、Windows をサポートするどのハードウェアにも機能するので、幅広いハードウェアで役立ちます。

    CuUEFI-CArl は https://go.microsoft.com/fwlink/p/?LinkID=321194 からダウンロードできます。 Windows HCK UEFI の署名と送信の詳細については、次のリンクを参照してください。

3. まとめとリソース

このセクションでは、上記のセクションをまとめ、段階的なアプローチを示します。

  1. セキュリティで保護された CA を確立したり、キーを安全に生成および格納します

    サード パーティ製のソリューションを使用していない場合:

    1. HSM サーバーで HSM ソフトウェアをインストールし、構成します。 インストール手順については、HSM リファレンス マニュアルを参照してください。 サーバーは、スタンドアロンまたはネットワークの HSM に接続されます。

      HSM 構成の詳細については、セクション 2.2.1、2.3、付録 C を参照してください。

      ほとんどの HSM では、FIPS 140-2 レベル 2 および 3 準拠が提供されます。 レベル 2 またはレベル 3 準拠に対応するように HSM を構成します。 レベル 3 準拠は、認証およびキー アクセスに関するさらに厳しい要件があるので、より安全です。 レベル 3 がお勧めです。

    2. 高可用性、バックアップ、認証用に HSM を構成します。 HSM リファレンス マニュアルを確認してください。

      高可用性とバックアップのための HSM のセットアップについて、HSM プロバイダー ガイドラインに従います。

      また、ネットワーク HSM には通常、トラフィックを分離するために複数のネットワーク ポートがあるので、通常の実稼働ネットワークとは別のネットワークでネットワーク HSM と通信できます。

      セキュリティ チームの一員であるチーム メンバーが特定され、トークンが割り当てられた後、 k-of-m 認証用に HSM ハードウェアをセットアップする必要があります。

    3. セキュア ブート キーと証明書の事前生成。 セクション 1.3 から 1.5 を参照してください

      HSM API を使用して、PK、ファームウェア更新キー、証明書を事前に生成します。

      必須-PK (モデルごとに1つを推奨) 、ファームウェア更新キー (モデルごとに1つを推奨) 、Microsoft KEK、Db、Dbx注: Microsoft KEK、db、dbxはOEMによって生成される必要はなく、完全性のために記載されています。オプション-OEM/サードパーティのKEK db、dbx、およびOEM Dbに含まれるその他のキー。

  2. Windows イメージを PC に適用します。

  3. Microsoft db および dbx をインストールします。 「セクション1.3.6」 および 「付録B–セキュアブートAPI」 を参照してください。

    1. Microsoft Windows Production PCA 2011 を db にインストールします。

    2. Microsoft から提供されていない場合は、空の dbx をインストールします。 Windows では、最初の再起動時に Windows Update を通じて、DBX が最新の DBX に自動的に更新されます。

    メモ

    Windows HCK テストの一部である PowerShell コマンドレットを使用するか、BIOS ベンダーによって提供されるメソッドを使用します。

  4. Microsoft KEK をインストールします。 セクション 1.3.3 を参照してください。

    UEFI KEK データベースに Microsoft KEK をインストールします

    注意

    Windows HCK テストの一部である PowerShell コマンドレットを使用するか、BIOS ベンダーによって提供されるメソッドを使用します。

  5. 省略可能な手順 - OEM/サード パーティ セキュア ブート コンポーネント。 セクション 1.3.4 および 1.4 を参照してください。

    1. OEM/サード パーティ KEK、db、dbx を作成する必要があるかどうかを特定します。

    2. HSM API を使用して、OEM/サード パーティ KEK (前に生成) で OEM/サード パーティの db および dbx に署名します。

    3. OEM/サード パーティ KEK、db、dbx をインストールします。

  6. UEFIドライバの署名–セクション2.4を参照してください。

    アドイン カードまたはその他の UEFI ドライバー/アプリ/ブートローダーをサポートしている場合は、Microsoft Corporation UEFI CA 2011 を UEFI db にインストールします。

  7. セキュア ブート ファームウェア更新キー - セクション 1.3.5 を参照してください。

    1. Windows RT 以外の PC のみ: セキュア ファームウェア更新の公開キーまたはそのハッシュをインストールして、領域を節約します。

    2. SoC の場合のみ、セキュア ファームウェア更新キー (公開またはそのハッシュ) の書き込みなど、何か他のことを行う必要があることがあります。

  8. セキュア ブートの有効化。 「付録B–セキュアブートAPI」 を参照してください。

    1. UEFI PK に OEM/ODM PKpub (証明書がお勧めですが、キーでも構いません) をインストールします。

    2. セキュア ブート API を使用して PK を登録します。 これで、PC のセキュア ブートが有効になります。

    メモ

    最後にPKをインストールする場合、MS KEK、db、dbxに署名する必要はありません–SignerInfoが存在する必要はありません。 これはショートカットです。

  9. セキュア ブートのテスト: 手順に従って、独自のテストと Windows HCK テストを実行します。 「付録B–セキュアブートAPI」 を参照してください。

  10. 出荷プラットフォーム: PKpriv はおそらく二度と使用されないので、安全に保管してください。

  11. サービス: 将来のファームウェア更新プログラムは、署名サービスを使用して、セキュア ファームウェア更新の "秘密" キーで安全に署名されます。

3.1 リソース

セキュリティ戦略に関するホワイト ペーパー - https://go.microsoft.com/fwlink/p/?linkid=321288

Windows HCK の提出 - https://go.microsoft.com/fwlink/p/?linkid=321287

付録A–製造用セキュアブートPKIチェックリスト

以下は、Windows RT 以外の PC でセキュア ブートを有効にするために必要な手順を要約した概要のチェックリストです。

セキュア ブートのセットアップ

  1. セクション 4 のホワイト ペーパーに従って、セキュリティ戦略 (脅威の特定、事前対応および事後対応戦略の定義) を定義します。

  2. セクション 4 のホワイト ペーパーに従って、セキュリティ チームを特定します。

  3. セキュリティで保護された CA を確立するか、パートナーを特定して (推奨のソリューション)、キーを安全に生成および格納します。

  4. キーの更新頻度を示すポリシーを特定します。 これは、政府機関やその他の機関などの特殊な顧客の要件があるかどうかに応じて異なります。

  5. セキュア ブート キーが侵害された場合に備えて、コンティンジェンシー計画を立てます。

  6. セクション 1.3.3 と 1.5 に従って生成する PK とその他のキーの数を特定します。

    これは、顧客数、キー ストレージ ソリューション、PC のセキュリティに基づきます。

    キー管理にサード パーティを使用する推奨のソリューションを使用している場合は、手順 7 から 8 を省略できます。

  7. キー管理用のサーバーとハードウェアを調達します。 – セクション2.2.1ごとのネットワークまたはスタンドアロンHSM。 高可用性とキー バックアップ戦略に、1 つまたは複数の HSM が必要かどうかを検討してください。

  8. HSM での認証用の認証トークンを持つ少なくとも 3 から 4 人のチーム メンバーを特定します。

  9. HSM またはサード パーティを使用して、セキュア ブート関連のキーと証明書を事前に生成します。 キーは、PC のタイプ (SoC、Windows RT、Windows RT 以外) に応じて異なります。 詳細については、セクション 1.3 から 1.5 を参照してください。

  10. ファームウェアに適切なキーを入力します。

  11. セキュア ブート プラットフォーム キーを登録して、セキュアブートを有効にします。 詳細については、付録 B を参照してください。

  12. 手順に従って、独自のテストと HCK セキュア ブート テストを実行します。 詳細については、付録 B を参照してください。

  13. PC を出荷します。 PKpriv はおそらく二度と使用されないので、安全に保管してください。

サービス (ファームウェアの更新)

UEFI コンポーネントの更新、セキュア ブート キーの侵害の修正、セキュア ブート キーの定期的なキー更新など、いくつかの理由でファームウェアの更新が必要になる場合があります。

詳細については、セクション 1.3.5 とセクション 1.3.6 を参照してください。

付録B–セキュアブートAPI

  1. セキュア ブート API

    UEFI/セキュア ブートに関連する API は次のとおりです。

    1. GetFirmwareEnvironmentVariableEx: 指定されたファームウェア環境変数の値を取得します。

    2. SetFirmwareEnvironmentVariableEx: 指定されたファームウェア環境変数の値を取得します。

    3. GetFirmwareType: ファームウェアの種類を取得します。

  2. PK の設定

    Set-SecureBootUEFI コマンドレットを使用して、セキュア ブートをオンにします。 コードで PK を設定した後、セキュア ブートのシステム強制は、次回の再起動まで有効になりません。 再起動する前に、コードで GetFirmwareEnvironmentVariableEx() または PowerShell コマンドレット (Get-SecureBootUEFI) を呼び出して、セキュア ブート データベースの内容を確認できます。

  3. 確認

    Msinfo32.exe または PowerShell コマンドレットを使用して、セキュア ブート変数の状態を確認できます。 WMI インターフェイスはありません。 また、(たとえば、Windows HCK セキュア ブート手動ロゴ テストの) 正しく署名されていない起動可能な USB スティックを誰かに挿入してもらってテストし、起動できないことを確認することもできます。

  4. セキュア ブート Powershell コマンドレット

    • Confirm-SecureBootUEFI: UEFI セキュア ブートは "ON" ですか (True または False)?

      SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI: 認証済みの SecureBoot UEFI 変数を設定または追加します

    • Get-SecureBootUEFI: 認証済みの SecureBoot UEFI 変数を取得します

    • Format-SecureBootUEFI: EFI_SIGNATURE_LISTs & EFI_VARIABLE_AUTHENTICATION_2 シリアル化を作成します

  5. Windows HCK およびセキュア ブートの手順

    次の手順は、システム テストと非クラス ドライバー PC テストに適用されます。

    1. セキュア ブート保護を無効にします。

      BIOS 構成を入力し、セキュア ブートを無効にします。

    2. HCK Client ソフトウェアをインストールします。

    3. 次の場合を除き、すべての Windows HCK テストを実行します。

      • PCR[7] を使用した BitLocker TPM および回復パスワードのテスト
      • セキュアブートを使用したArm PcのBitLocker TPMと回復パスワードテスト
      • セキュア ブート ロゴ テスト
      • セキュア ブート手動ロゴ テスト

    4. BIOS 構成を入力し、セキュア ブートを有効にして、セキュア ブートを既定の構成に復元します。

    5. 次の BitLocker とセキュア ブート テストを実行します。

      • PCR[7] を使用した BitLocker TPM および回復パスワードのテスト
      • セキュアブートを使用したArm PcのBitLocker TPMと回復パスワードテスト
      • セキュア ブート ロゴ テスト (自動)

    6. BIOS 構成を入力し、セキュア ブート構成をクリアします。 これにより、PK およびその他のキーを削除することによって、PC がセットアップ モードに復元されます。

      メモ

      X86/x64 PC では、クリアのサポートが必要です。

    7. セキュア ブート手動ロゴ テストを実行します。

      メモ

      セキュア ブートでは、Windows RT 以外の PC で Windows HCK 署名付きドライバーまたは VeriSign ドライバーが必要です

  6. Windows HCK セキュア ブート ロゴ テスト (自動)

    このテストでは、購入時のセキュア ブート構成が適切かどうかを確認します。 これには、次のものが含まれます。

    • セキュア ブートが有効になっている。
    • PK が既知のテスト PK ではない。
    • KEK に、実稼働 Microsoft KEK が含まれている。
    • db に、実稼働 Windows CA が含まれている。
    • dbx が存在する。
    • 多くの 1 KB 変数が作成または削除される。
    • 32 KB 変数が作成または削除される。

  7. Windows HCK セキュア ブート手動テスト フォルダー レイアウト

    Windows HCK セキュア ブート手動ロゴ テスト フォルダーのレイアウトを次に示します。

    • "\Test" フォルダーには次の内容が含まれます。

      • 製造とサービスのテスト
      • テスト構成でのプログラムによるセキュア ブートの有効化
      • サービス テスト
      • db に証明書を追加し、機能を確認する
      • dbx にハッシュを追加し、機能を確認する
      • dbx に証明書を追加し、機能を確認する
      • dbx に 600 以上のハッシュを追加し、サイズを確認する
      • プログラムによって PK を変更する

    • "\Generate" フォルダーには次の内容を表示するスクリプトが含まれます。

      • テスト証明書を作成した方法

      • テスト証明書と秘密キーが含まれていること

      • すべてのテストを作成した方法

      • 証明書とハッシュからの署名されたパッケージの作成

      • これを自分で実行し、自身の証明書に置き換えることができる

    • "\certs" フォルダーには、Windows の起動に必要なすべての証明書が含まれています。

      メモ

      "ManualTests\generate\TestCerts"で使用されている方法を使用してキーと証明書を生成しないでください。 これは、Windows HCK テストのみを目的としています。 ディスクに格納されているキーを使用するので、安全性が非常に低く、お勧めしません。 これは、実稼働環境で使用するものではありません。

  • "ManualTests\example\OutOfBox" フォルダーには、実稼働 PC にセキュア ブートをインストールするときに活用できるスクリプトが含まれています。

    "ManualTests\generate\tests\subcreate_outofbox_example.ps1" には、これらの例が生成された方法が示されており、パートナーが PK やその他のメタデータを置き換えられるときの "TODO" セクションがあります。

  1. Windows HCK UEFI の署名と送信

    次のリンクは詳細を示します。

付録C–連邦ブリッジ証明機関証明書ポリシー保証マッピング

  1. 初歩的

    このレベルでは、個人の ID に関して確実性が最も低くなります。 このレベルの主な機能の 1 つは、署名されている情報にデータ整合性をもたらすことです。 このレベルは、悪意のあるアクティビティのリスクが低いと思われる環境に適切です。 これは、認証を必要とするトランザクションには適しておらず、一般に機密性を必要とするトランザクションには不十分ですが、その場合であっても、より高いレベルのアシュアランスを持つ証明書が使用できないときに使用できます。

  2. 基本

    このレベルでは、データ侵害のリスクと影響はあるが、大きな重大さがあるとは考えられない環境に適した基本的なレベルの保証が提供されます。 これには、悪意のあるアクセスの可能性が高くない個人情報へのアクセスが含まれる場合があります。 このセキュリティ レベルでは、ユーザーが悪意を持つ可能性が低いと考えられています。

  3. 中

    このレベルは、データ侵害のリスクと影響が中程度である環境に適しています。 これには、不正行為によるかなりの金額のリスクのあるトランザクションや、悪意のあるアクセスの可能性が高い個人情報へのアクセスを含むトランザクションが含まれる可能性があります。

  4. 高

    このレベルは、データに対する脅威が高い場合や、セキュリティ サービスが失敗したときの影響が大きい場合に適しています。 これには、トランザクションの価値が非常に高い場合や、不正行為のリスクのレベルが高い場合が含まれる可能性があります。

HSM を使ったセキュア ブート キーの生成と署名 (例)

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

セキュア ブートの概要