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

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

Arie van der Hoeven、アーキテクト、OEM のコンサルティングariev@microsoft.comArie van der Hoeven, Architect, OEM Consulting, ariev@microsoft.com

このドキュメントによりガイド Oem とセキュア ブート キーの作成と管理の Odm、製造環境で証明書。This document helps guide OEMs and ODMs in creation and management of the Secure Boot keys and certificates in a manufacturing environment. 作成、ストレージ、およびプラットフォーム キー (Pk)、セキュア ファームウェア更新キー、およびサード パーティのキー交換キー (Kek) の取得に関連する質問に対応します。It addresses questions related to creation, storage and retrieval of Platform Keys (PKs), secure firmware update keys, and third party Key Exchange Keys (KEKs).

注: これらの手順は、PC の Oem に固有ではありません。Note: These steps are not specific to PC OEMs. 企業と顧客では、セキュア ブートをサポートするために、サーバーを構成するのに手順を使用できますも。Enterprises and customers can also use these steps to configure their servers to support Secure Boot.

UEFI、セキュア ブートの Windows の要件が記載されて、 Windows ハードウェア認定要件します。Windows requirements for UEFI and Secure Boot can be found in the Windows Hardware Certification Requirements. このホワイト ペーパーは、新しい要件を導入または公式の Windows プログラムを表すはできません。This paper does not introduce new requirements or represent an official Windows program. 認定の要件を作成およびセキュリティで保護された Boot キーを管理するための効率的かつ安全なプロセスの構築を支援するために超えるガイダンスと想定されます。It is intended as guidance beyond certification requirements, to assist in building efficient and secure processes for creating and managing Secure Boot Keys. UEFI セキュア ブートは実行を許可する前にコードを認証する公開キー基盤の使用量に基づいているために、このことが重要です。This is important because UEFI Secure Boot is based on the usage of Public Key Infrastructure to authenticate code before allowed to execute.

リーダーが UEFI、セキュア ブートの詳細については基本の基礎について理解が必要です (の第 27 章、 UEFI 仕様)、および PKI のセキュリティ モデル。The reader is expected to know the fundamentals of UEFI, basic understanding of Secure Boot (Chapter 27 of the UEFI specification), and PKI security model.

要件、テスト、および Windows でのセキュア ブートの検証ツールはで現在利用可能なWindows ハードウェア認定キット (HCK)します。Requirements, tests, and tools validating Secure Boot on Windows are available today through the Windows Hardware Certification Kit (HCK). ただし、これらの HCK リソースでは、Windows の展開のキーの作成と管理はアドレスされません。However, these HCK resources do not address creation and management of keys for Windows deployments. このホワイト ペーパーでは、ファームウェアによって使用されるキーの展開の手順ガイドのパートナーを支援するリソースとしてのキーの管理を説明します。This paper addresses key management as a resource to help guide partners through deployment of the keys used by the firmware. 規範的なガイダンスとしてではありませんし、新しい条件をすべては含まれません。It is not intended as prescriptive guidance and does not include any new requirements.

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

このドキュメントはお客様の開発の開始点として機能 Pc、工場出荷時の展開ツールおよびキーのセキュリティのベスト プラクティスを準備します。This document serves as a starting point in developing customer ready PCs, factory deployment tools and key security best practices.

1.セキュア ブート、Windows、およびキー管理1. Secure Boot, Windows and Key Management

UEFI (Unified Extensible Firmware Interface) 仕様には、セキュア ブートと呼ばれる、ファームウェアの実行の認証のプロセスが定義されています。The UEFI (Unified Extensible Firmware Interface) specification defines a firmware execution authentication process called Secure Boot. 業界標準としてセキュア ブートはプラットフォームのファームウェアが証明書を管理する方法を定義、ファームウェア、およびこのプロセスで、オペレーティング システムのインターフェイスを認証します。As an industry standard, Secure Boot defines how platform firmware manages certificates, authenticates firmware, and how the operating system interfaces with this process.

セキュア ブートは、実行を許可する前に、モジュールを認証する公開キー基盤 (PKI) のプロセスに基づいています。Secure Boot is based on the Public Key Infrastructure (PKI) process to authenticate modules before they are allowed to execute. これらのモジュールには、ファームウェア ドライバー、オプション Rom、ディスク、UEFI アプリケーション、または UEFI ブート ローダーに UEFI ドライバーを含めることができます。These modules can include firmware drivers, option ROMs, UEFI drivers on disk, UEFI applications, or UEFI boot loaders. イメージの認証の実行前に、使用は、セキュア ブートは、ルートキットなどのプレブート マルウェア攻撃のリスクを軽減します。Through image authentication before execution, Secure Boot reduces the risk of pre-boot malware attacks such as rootkits. UEFI セキュア ブートで Windows 8 以降では、マイクロソフトのお客様のプラットフォームのセキュリティを向上させるために、トラスト ブート セキュリティ アーキテクチャの一部として。Microsoft relies on UEFI Secure Boot in Windows 8 and above as part of its Trusted Boot security architecture to improve platform security for our customers. セキュア ブートは、Windows ハードウェア互換性要件に定義された必要なは、Windows 8 用のクライアント Pc の場合は、上部とおよび Windows Server 2016 用です。Secure Boot is required for Windows 8 and above client PCs, and for Windows Server 2016 as defined in the Windows Hardware Compatibility Requirements.

セキュア ブート プロセスでは、次のように、図 1 に示すように機能します。The Secure Boot process works as follows and as shown in Figure 1:

  1. ファームウェア ブート コンポーネント: ファームウェアでは、OS ローダーが信頼されていることを確認 (Windows または別の信頼されているオペレーティング システムです)。Firmware Boot Components: The firmware verifies the OS loader is trusted (Windows or another trusted operating system.)

  2. Windows では、コンポーネントをブートします。BootMgr、WinLoad、Windows カーネルを起動します。Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows ブート コンポーネントは、各コンポーネントの署名を確認します。Windows boot components verify the signature on each component. 信頼されていないコンポーネントは読み込まれませんされ、代わりに、セキュア ブートの修復にトリガーされます。Any non-trusted components will not be loaded and instead will trigger Secure Boot remediation.

    • ウイルス対策およびマルウェア対策ソフトウェアの初期化: このソフトウェアは、トラスト ブートの重要なドライバーの可能性の確認マイクロソフトによって発行された特殊な署名がチェックされ、ブート プロセスの早い段階で起動されます。Antivirus and Antimalware Software initialization: This software is checked for a special signature issued by Microsoft verifying that it is a trusted boot critical driver, and will launch early in the boot process.

    • 重要なドライバーの初期化を起動します。 WinLoad でセキュア ブート、検証の一部として、すべての起動に不可欠なドライバーの署名が確認されます。Boot Critical Driver initialization: The signatures on all Boot-critical drivers are checked as part of Secure Boot verification in WinLoad.

  3. その他の OS の初期化Additional OS Initialization

  4. Windows ログオン画面Windows Logon Screen

プラットフォーム整合性のアーキテクチャの画像

図 1: 信頼された Boot アーキテクチャの WindowsFigure 1: Windows Trusted Boot Architecture

UEFI セキュア ブートの実装には、Microsoft の信頼されたブート アーキテクチャ、Windows 8.1 で導入されたの一部です。Implementation of UEFI Secure Boot is part of Microsoft’s Trusted Boot Architecture, introduced in Windows 8.1. マルウェア攻撃の進化におけるトレンドには、優先攻撃ベクターとしてブート パスが対象とします。A growing trend in the evolution of malware exploits is targeting the boot path as a preferred attack vector. この種の攻撃が困難を防ぐため、マルウェア対策製品は全体を読み込むようにする悪意のあるソフトウェアによって無効にすることができますされました。This class of attack has been difficult to guard against, since antimalware products can be disabled by malicious software that prevents them from loading entirely. Windows トラスト ブート アーキテクチャとそのセキュア ブートと信頼関係のルートを確立、顧客はコードのみ署名済み、認定された「既知の良い」ことを確認して、ブート パスで実行される悪意のあるコードから保護し、ブート ローダーは、前に実行できる、オペレーティング システム自体を読み込みます。With Windows Trusted Boot architecture and its establishment of a root of trust with Secure Boot, the customer is protected from malicious code executing in the boot path by ensuring that only signed, certified “known good” code and boot loaders can execute before the operating system itself loads.

1.1 の公開キー基盤 (PKI) とセキュリティで保護された Boot1.1 Public-Key Infrastructure (PKI) and Secure Boot

PKI は、信頼性と、システムで信頼を確立します。The PKI establishes authenticity and trust in a system. 2 つの高度な用途は、ブート活用して PKI をセキュリティで保護します。Secure Boot leverages PKI for two high-level purposes:

  1. 初期ブート モジュールの実行に対して信頼されているかどうかを判断する起動中During boot to determine if early boot modules are trusted for execution.

  2. 認証するためには、要求を処理する要求には、プラットフォーム ファームウェアにセキュア ブート データベースと更新プログラムの変更が含まれます。To authenticate requests to service requests include modification of Secure Boot databases and updates to platform firmware.

PKI は、で構成されます。A PKI consists of:

  • デジタル証明書を発行する証明書機関 (CA)。A certificate authority (CA) that issues the digital certificates.

  • 登録機関の CA から証明書を要求しているユーザーの id を確認します。A registration authority which verifies the identity of users requesting a certificate from the CA.

  • 格納して、インデックス キー内の中央ディレクトリ。A central directory in which to store and index keys.

  • 証明書の管理システムです。A certificate management system.

1.2 公開キーの暗号化1.2 Public Key Cryptography

公開キーの暗号化は、パブリックおよびプライベート キーと呼ばれる、数学的に関連する暗号化キーのペアを使用します。Public key cryptography uses a pair of mathematically related cryptographic keys, known as the public and private key. キーのいずれかをわかっている場合、もう一方が簡単に計算できません。If you know one of the keys, you cannot easily calculate what the other one is. 情報を暗号化する 1 つのキーを使用する場合のみに対応するキーはその情報を暗号化解除できます。If one key is used to encrypt information, then only the corresponding key can decrypt that information. セキュア ブートでは、コードにデジタル署名、秘密キーを使用し、信頼性を証明するためにそのコードに署名を検証する公開キーを使用します。For Secure Boot, the private key is used to digitally sign code and the public key is used to verify the signature on that code to prove its authenticity. 秘密キーが侵害された場合、対応する公開キーでシステムにセキュリティで保護されたはなくなりました。If a private key is compromised, then systems with corresponding public keys are no longer secure. これは、キットの攻撃を起動する可能性があり、秘密キーのセキュリティを確保を担う組織の評判が破損します。This can lead to boot kit attacks and will damage the reputation of the entity responsible for ensuring the security of the private key.

セキュア ブートの公開キー システムで、次のものがあります。In a Secure Boot public key system you have the following:

  • 1.2.1 RSA 2048 の暗号化1.2.1 RSA 2048 Encryption

    RSA 2048 は、非対称暗号化アルゴリズムです。RSA-2048 is an asymmetric cryptographic algorithm. 未加工の形式で RSA 2048 を剰余を格納するために必要な領域は、2048 ビットです。The space needed to store an RSA-2048 modulus in raw form is 2048 bits.

  • 1.2.2 自己署名証明書1.2.2 Self-signed certificate

    証明書の公開キーと一致する秘密キーによって署名された証明書は、自己署名証明書と呼ばれます。A certificate signed by the private key that matches the public key of the certificate is known as a self-signed certificate. ルート証明機関 (CA) 証明書は、このカテゴリに分類されます。Root certification authority (CA) certificates fall into this category.

  • 1.2.3 証明機関1.2.3 Certification Authority

    証明機関 (CA) の問題は、証明書のサブジェクトの id を確認し、その id を証明書に含まれている公開キーにバインドする証明書を署名します。The certification authority (CA) issues signed certificates that affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate. CA の秘密キーを使用して証明書に署名します。The CA signs the certificate by using its private key. 自己署名ルート CA 証明書ですべての関係者に対応する公開キーを発行します。It issues the corresponding public key to all interested parties in a self-signed root CA certificate.

    セキュア ブートの場合、証明機関 (Ca) は、OEM (またはその代理人) と Microsoft。In Secure Boot, Certification Authorities (CAs) include the OEM (or their delegates) and Microsoft. Ca は、信頼のルートを形成し、秘密キーを使用して署名など、初期ブート EFI モジュールおよびファームウェアの要求の処理を許可される操作に正当なキーのペアを生成します。The CAs generate the key pairs that form the root of trust and then use the private keys to sign legitimate operations such as allowed early boot EFI modules and firmware servicing requests. 対応する公開キーは、セキュア ブートが有効な Pc の UEFI ファームウェアに埋め込まれた出荷し、これらの操作を確認するために使用します。The corresponding public keys are shipped embedded into the UEFI firmware on Secure Boot-enabled PCs and are used to verify these operations.

    (Ca、およびキー交換の使用状況の詳細については、セキュア ブートのモデルに関連しているインターネット上にすぐに使用できる)。(More information on usage of CAs and key exchanges is readily available on the internet which relates to the Secure Boot model.)

  • 1.2.4 公開キー1.2.4 Public Key

    パブリック プラットフォーム キーは、PC に付属しています、アクセスできるか、"public"です。The public Platform Key ships on the PC and is accessible or “public”. このドキュメントでは、公開キーを示すために、"pub"サフィックスを使用します。In this document we will use the suffix “pub” to denote public key. たとえば、PKpub は PK の公開の半分を表しますFor example, PKpub denotes the public half of the PK.

  • 1.2.5 秘密キー1.2.5 Private Key

    秘密キーを操作するための PKI を安全に管理する必要があります。For PKI to work the private key needs to be securely managed. 組織で信頼性の高い少数のユーザーにアクセスできる必要があり、強力なアクセス ポリシーの制限を物理的に安全な場所に配置します。It should be accessible to a few highly trusted individuals in an organization and located in a physically secure location with strong access policy restrictions in place. このドキュメントでは、秘密キーを示すために、"priv"サフィックスを使用します。In this document we will use the suffix “priv” to denote private key. たとえば、PKpriv には、PK の半分にプライベートことを示します。For example, the PKpriv indicates private half of the PK.

  • 1.2.6 証明書1.2.6 Certificates

    デジタル証明書の主な用途では、バイナリなどなどの署名付きデータの配信元を確認します。証明書の一般的な用途は、トランスポート層セキュリティ (TLS) または Secure Sockets Layer (SSL) を使用してインターネット メッセージ セキュリティのためです。The primary use for digital certificates is to verify the origin of signed data, such as binaries etc. A common use of certificates is for internet message security using Transport Layer Security (TLS) or Secure Sockets Layer (SSL). 証明書で署名されたデータにより、データの出所を知って受信者と、転送中に変更されているかどうかを検証しています。Verifying the signed data with a certificate lets the recipient know the origin of the data and if it has been altered in transit.

    デジタル証明書を一般に含まれています、大まかに言えば、識別名 (DN)、公開キー、および署名で。A digital certificate in general contains, at a high level, a distinguished name (DN), a public key, and a signature. DN は、企業の証明書の公開キーと一致する秘密キーを保持する----エンティティを識別します。The DN identifies an entity -- a company, for example -- that holds the private key that matches the public key of the certificate. 証明書を秘密キーで署名と証明書の署名を配置するには、公開キーに秘密キーが結び付いています。Signing the certificate with a private key and placing the signature in the certificate ties the private key to the public key.

    証明書は、いくつかその他の種類のデータを含めることができます。Certificates can contain some other types of data. たとえば、X.509 証明書には、証明書、証明書、証明書、証明書を要求したエンティティの公開キーと名前、証明書を発行した CA の名前の署名に使用されるアルゴリズムのシリアル番号の形式が含まれます。、および CA の署名。For example, an X.509 certificate includes the format of the certificate, the serial number of the certificate, the algorithm used to sign the certificate, the name of the CA that issued the certificate, the name and public key of the entity requesting the certificate, and the CA's signature.

  • 1.2.7 証明書のチェーン1.2.7 Chaining certificates

    差出人:証明書のチェーン:From: Certificate chains:

    ルート ca が自己署名ルート ca によって署名された他のユーザー

    図 2:3-証明書チェーンFigure 2: Three-certificate chain

    ユーザー証明書は CA の秘密キーなどの別の秘密キーによって多くの場合、署名されます。User certificates are often signed by a different private key, such as a private key of the CA. これは、2 つの証明書チェーンを構成します。This constitutes a two-certificate chain. ユーザー証明書が本物であることの確認には、その証明書から、CA の公開キーが必要ですが、署名を検証する必要があります。Verifying that a user certificate is genuine involves verifying its signature, which requires the public key of the CA, from its certificate. 外側の CA 証明書を確認する必要が、CA の公開キーを使用することができます。But before the public key of the CA can be used, the enclosing CA certificate needs to be verified. CA 証明書は自己署名であるために、CA 公開キーを使用して、証明書を確認します。Because the CA certificate is self-signed, the CA public key is used to verify the certificate.

    ユーザー証明書は必要なルート CA の秘密キーによって署名されていません。A user certificate need not be signed by the private key of the root CA. 証明書を所有が CA の秘密キーによって署名された仲介者の秘密キーによって署名ことでした。It could be signed by the private key of an intermediary whose certificate is signed by the private key of the CA. これは、3 つの証明書チェーンのインスタンス: ユーザー証明書、中間証明書と CA 証明書。This is an instance of a three-certificate chain: user certificate, intermediary certificate, and CA certificate. 任意の長さの証明書チェーンができるように、1 つ以上の中継ぎ局は、チェーンの一部にできます。But more than one intermediary can be part of the chain, so certificate chains can be of any length.

1.3 をセキュリティで保護のブート PKI の要件1.3 Secure Boot PKI requirements

UEFI による信頼のルートはプラットフォーム キーと OEM または ODM の任意のキーがファームウェアのコアに含まれています。The UEFI-defined root of trust consists of the Platform Key and any keys an OEM or ODM includes in the firmware core. プレ UEFI のセキュリティと信頼のルートでは取り上げません UEFI セキュア ブートのプロセスによって、代わりにこのホワイト ペーパーで参照されているパブリケーションの National Institute of Standards Technology (NIST) と Trusted Computing Group (TCG)。Pre-UEFI security and a root of trust are not addressed by the UEFI Secure Boot process, but instead by National Institute of Standards and Technology (NIST), and Trusted Computing Group (TCG) publications referenced in this paper.

  • 1.3.1 セキュリティで保護された Boot 要件1.3.1 Secure Boot requirements

    セキュア ブートを実装するための次のパラメーターを検討する必要があります。You’ll need to consider the following parameters for implementing Secure Boot:

    • お客様の要件Customer requirements

    • Windows ハードウェアの互換性の要件Windows Hardware Compatibility requirements

    • キーの生成と管理の要件。Key generation and management requirements.

    ハードウェア セキュリティ モジュール (Hsm) などのセキュア ブート キー管理のハードウェアを選択するには、政府機関およびその他の政府機関と最後に作成、および管理のライフ サイクルのプロセスに発送する Pc で特別な要件を考慮する必要があります。さまざまなセキュア ブート キー。You would need to pick hardware for Secure Boot key management like Hardware Security Modules (HSMs), consider special requirements on PCs to ship to governments and other agencies and finally the process of creating, populating and managing the life cycle of various Secure Boot keys.

  • 1.3.2 セキュア ブートに関連するキー1.3.2 Secure Boot related keys

    セキュア ブートに使用されるキーは、次に示します。The keys used for Secure Boot are below:

    pk、kek、db、dbx、およびファームウェアのキーの winrt キー

    図 3:セキュア ブートに関連するキーFigure 3: Keys related to Secure Boot

    上の図 3 は、署名とセキュア ブートの PC でのキーを表します。Figure 3 above represents the signatures and keys in a PC with Secure Boot. プラットフォームは、製造時に、OEM がファームウェアをインストールするプラットフォーム キーによって保護されます。The platform is secured through a platform key that the OEM installs in firmware during manufacturing. その他のキーは、ファームウェアの実行を許可または拒否するキーを格納するデータベースへのアクセスを保護するセキュア ブートによって使用されます。Other keys are used by Secure Boot to protect access to databases that store keys to allow or disallow execution of firmware.

    承認されたデータベース (db) には、公開キーとの信頼されたファームウェア コンポーネントとオペレーティング システム ローダーを表す証明書が含まれています。The authorized database (db) contains public keys and certificates that represent trusted firmware components and operating system loaders. 許可されていない署名データベース (dbx) 悪意のある脆弱なコンポーネントのハッシュが含まれていますだけでなく、悪意のあるコンポーネントのキーと証明書、およびブロックの実行を侵害されました。The forbidden signature database (dbx) contains hashes of malicious and vulnerable components as well as compromised keys and certificates and blocks execution of those malicious components. これらのポリシーの強度は、Authenticode と公開キー基盤 (PKI) を使用してファームウェアの署名に基づいています。The strength of these policies is based on signing firmware using Authenticode and Public Key Infrastructure (PKI). PKI は、既に確立されているプロセスの作成、管理、および情報の交換中に信頼関係を確立する証明書の取り消しです。PKI is a well-established process for creating, managing, and revoking certificates that establish trust during information exchange. PKI はセキュア ブートのセキュリティ モデルの中核です。PKI is at the core of the security model for Secure Boot.

    詳細については、これらのキーを次に示します。Below are more details on these keys.

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

    プラットフォーム キーは、UEFI 2.3.1 Errata c セクション 27.5.1 に従ってプラットフォーム所有者と、プラットフォーム ファームウェア間の信頼関係を確立します。As per section 27.5.1 of the UEFI 2.3.1 Errata C, the platform key establishes a trust relationship between the platform owner and the platform firmware. プラットフォームの所有者で指定されているプラットフォームのファームウェアをキー (PKpub) のパブリックの半分を対象として登録UEFI 2.3.1 Errata C のセクション 7.2.1します。この手順では、セットアップ モードからユーザー モードにプラットフォームを移動します。The platform owner enrolls the public half of the key (PKpub) into the platform firmware as specified in Section 7.2.1 of the UEFI 2.3.1 Errata C. This step moves the platform into user mode from setup mode. 型プラットフォーム キーであることをお勧めします。 EFI_CERT_X509_GUID公開キー アルゴリズム、RSA 2048 ビット、および署名アルゴリズム sha256RSA の公開キーの長さにします。Microsoft recommends that the Platform Key be of type EFI_CERT_X509_GUID with public key algorithm RSA, public key length of 2048 bits, and signature algorithm sha256RSA. プラットフォームの所有者が型を使用できますEFI_CERT_RSA2048_GUID記憶域スペースが重要である場合。The platform owner may use type EFI_CERT_RSA2048_GUID if storage space is a concern. 公開キーは、このドキュメントで前述したように、署名の確認に使用されます。Public keys are used to check signatures as described earlier in this document. プラットフォームの所有者は、秘密キー (PKpriv) の半分を後で使用できます。The platform owner can later use the private half of the key (PKpriv):

    • プラットフォームの所有権を変更するに定義されている UEFI ファームウェアを配置する必要がありますセットアップ モードセキュア ブートを無効にします。To change platform ownership you must put the firmware into UEFI defined setup mode which disables Secure Boot. 製造中にこれを実行する必要がある場合にのみセットアップ モードに戻します。Revert to setup mode only if there is a need to do this during manufacturing.

    • デスクトップ PC は、Oem は PK と関連付けられているために必要な PKI を管理します。For desktop PC, OEMs manage PK and necessary PKI associated with it. サーバーでは、既定では、Oem は PK と必要な PKI を管理します。For Servers, OEMs by default manage PK and necessary PKI. 企業のお客様またはお客様のサーバーもカスタマイズできます PK、信頼関係の OEM の PK をそれ自体に UEFI セキュア ブート ファームウェア内で信頼をロックダウンする独自のカスタムの PK に置き換えます。Enterprise customers or Server customers can also customize PK, replacing the OEM-trusted PK with a custom-proprietary PK to lock down the trust in UEFI Secure Boot firmware to itself.

    1.3.3.1 への登録または更新を変更する Key Exchange Key (KEK) プラットフォーム キーを登録します。1.3.3.1 To enroll or update a Key Exchange Key (KEK) Enrolling the Platform Key

    プラットフォームの所有者は、プラットフォーム キーのパブリックの半分を登録 (PKpub) で指定したセクション 7.2.1 UEFI 2.3.1 の仕様の正誤表 C のとして、UEFI ブート サービス SetVariable() を呼び出し、プラットフォームをリセットしています。The platform owner enrolls the public half of the Platform Key (PKpub) by calling the UEFI Boot Service SetVariable() as specified in Section 7.2.1 of UEFI Spec 2.3.1 errata C, and resetting the platform. モードのセットアップし、新しいプラットフォームがある場合PKpubで署名されているものとそのPKpriv対応します。If the platform is in setup mode, then the new PKpub shall be signed with its PKpriv counterpart. ユーザー モードでは、その後、新しいプラットフォームがある場合PKpub現在で署名する必要がありますPKprivします。If the platform is in user mode, then the new PKpub must be signed with the current PKpriv. 型の場合は、PK EFI_CERT_X509_GUID、これは、すぐで署名する必要がありますPKprivPK で発行された任意の証明書の秘密キーではありませんIf the PK is of type EFI_CERT_X509_GUID, then this must be signed by the immediate PKpriv, not a private key of any certificate issued under the PK.

    1.3.3.2 プラットフォーム キーをクリアします。1.3.3.2 Clearing the Platform Key

    プラットフォームの所有者がプラットフォーム キーのパブリックの半分をクリアします (PKpub) で変数のサイズが 0 の UEFI ブート Ser¬vice SetVariable() を呼び出し、プラットフォームをリセットします。The platform owner clears the public half of the Platform Key (PKpub) by calling the UEFI Boot Ser¬vice SetVariable() with a variable size of 0 and resetting the platform. プラットフォームは、セットアップ モードでは、認証する空の変数は必要ありません。If the platform is in setup mode, then the empty variable does not need to be authenticated. プラットフォームがユーザー モードであるかどうかは、空の変数は、現在で署名する必要がありますPKpriv; セクション 7.2 (変数サービス) の下に表示UEFI 仕様2.3.1 Errata C 詳細についてはします。If the platform is in user mode, then the empty variable must be signed with the current PKpriv; see Section 7.2(Variable Services) under UEFI specification 2.3.1 Errata C for details. 運用 PKpriv をこれにより、セキュア ブートをプログラムで無効にするために、プラットフォームをリセットするためのパッケージの署名に使用しないことを強くお勧めします。It is strongly recommended that the production PKpriv never be used to sign a package to reset the platform since this allows Secure Boot to be disabled programmatically. これは、実稼働前テスト シナリオでは主にです。This is primarily a pre-production test scenario.

    プラットフォーム キーは、セキュリティで保護されたプラットフォームに固有のメソッドを使用してもクリア可能性があります。The platform key may also be cleared using a secure platform-specific method. この場合は、グローバル変数のセットアップ モードは 1 にも更新する必要があります。In this case, the global variable Setup Mode must also be updated to 1.

    イメージ: pk セットアップ モードまたはユーザー モードの決定

    図 4:プラットフォーム キーの状態ダイアグラムFigure 4: Platform Key State diagram

    1.3.3.3 PK の生成1.3.3.3 PK generation

    UEFI の推奨事項に従って公開キーは改ざんできる非揮発性ストレージに保存され、PC の削除に対する抵抗力である必要があります。As per UEFI recommendations, the public key must be stored in non-volatile storage which is tamper and delete resistant on the PC. 秘密キーはパートナーまたは OEM のセキュリティの Office でセキュリティで保護された状態を維持し、プラットフォーム上に公開キーのみが読み込まれます。The Private keys stay secure at Partner or in the OEM’s Security Office and only the public key is loaded onto the platform. セクション 2.2.1 および 2.3 の詳細については、します。There are more details under section 2.2.1 and 2.3.

    生成された主キーの数は、プラットフォーム所有者 (OEM) の判断でです。The number of PK generated is at the discretion of the Platform owner (OEM). これらのキーになります。These keys could be:

    1. PC ごとに 1 つします。One per PC. デバイスごとに 1 つの一意のキーを持ちます。Having one unique key for each device. 政府機関、金融機関、または高度なセキュリティ ニーズを持つ他のサーバーのお客様に必要な場合があります。This may be required for government agencies, financial institutions, or other server customers with high-security needs. 追加のストレージと暗号化の処理能力を多数の Pc のプライベートおよびパブリック キーを生成する必要があります。It may require additional storage and crypto processing power to generate private and public keys for large numbers of PCs. 今後、デバイスにファームウェアの更新プログラムをプッシュするとき、対応する PK でマッピングのデバイスの複雑さが追加されます。This adds the complexity of mapping devices with their corresponding PK when pushing out firmware updates to the devices in the future. いくつか方法が異なります HSM 多数の HSM の製造元に基づくキーの管理に使用します。There are a few different HSM solutions available to manage large number of keys based on the HSM vendor. 詳細については、セキュリティで保護された Boot キーの生成を使用して HSM の追加を参照してください。For more info, see Secure Boot Key Generation Using HSM.

    2. モデルごとに 1 つします。One per model. PC モデルごとに 1 つのキーを持ちます。Having one key per PC model. その代わりここでは、キーが侵害された場合、同じモデル内のすべてのマシンがある脆弱性のあります。The tradeoff here is that if a key is compromised all the machines within the same model would be vulnerable. これは、デスクトップ Pc に Microsoft が推奨されます。This is recommended by Microsoft for desktop PCs.

    3. 製品ラインごとに 1 つします。One per product line. キーが侵害された場合、製品全体の行は脆弱になります。If a key is compromised a whole product line would be vulnerable.

    4. OEM ごとに 1 つします。One per OEM. これは、キーが侵害された場合、設定する最も簡単なすべての PC を製造するが脆弱性のあるでしょうです。While this may be the simplest to set up, if the key is compromised, every PC you manufacture would be vulnerable. 工場フロアの操作をスピードアップするためには、PK とその他のキーを事前生成され、安全な場所に格納されているでした。To speed up operation on the factory floor, the PK and potentially other keys could be pre-generated and stored in a safe location. これらでした後で取得され、組み立てラインで使用します。These could be later retrieved and used in the assembly line. 章 2 および 3 の詳細があります。Chapters 2 and 3 have more details.

    1.3.3.4 キー、主キーの更新1.3.3.4 Rekeying the PK

    これで必要となる主キーが侵害された場合、または要件として顧客のセキュリティ上の理由から、独自の PK. を登録する必要があります。This may be needed if the PK gets compromised or as a requirement by a customer that for security reasons may decide to enroll their own PK.

    モデルまたは PC PK. を作成するどのような方法が選択されているに基づいてのいずれかが行われるキーの更新Rekeying could be done either for a model or PC based on what method was selected to create PK. 新しいすべての Pc が新しく作成された PK にサインインします。All the newer PCs will get signed with the newly created PK.

    実稼働 PC の PK を更新すると、更新するか、変数を主キーまたはファームウェアの更新プログラム パッケージを置き換える既存の PK で署名が必要です。Updating the PK on a production PC would require either a variable update signed with the existing PK that replaces the PK or a firmware update package. OEM の SetVariable() パッケージを作成し、PK を変更するだけですが、PowerShell などの単純なアプリケーションと共に配布することもAn OEM could also create a SetVariable() package and distribute that with a simple application such as PowerShell that just changes the PK. ファームウェアの更新プログラム パッケージは、セキュリティで保護されたファームウェアの更新キーによって署名され、ファームウェアによって検証は。The firmware update package would be signed by the secure firmware update key and verified by firmware. ファームウェアの更新を更新、PK を行う場合注意する必要があります、KEK は db では、ことを確認し、dbx が保持されます。If doing a firmware update to update the PK, care should be taken to ensure the KEK, db, and dbx are preserved.

    すべての Pc で勧め使用しないように、PK セキュア ファームウェア更新のキーとして。On all PCs, it is recommended to not use the PK as the secure firmware update key. 場合、PKpriv が侵害されたしがセキュア ファームウェア更新のキー (ためそれらは同じですです)。If the PKpriv is compromised then so is the secure firmware update key (since they are the same). ここで新しい PKpub の登録を更新できない可能性がありますの更新プロセスが侵害されてもあるためです。In this case the update to enroll a new PKpub might not be possible since the process of updating has also been compromised.

    Soc の Pc では、PK セキュア ファームウェア更新のキーとして使用する別の理由です。On SOCs PCs, there is another reason to not use the PK as the secure firmware update key. Windows ハードウェア認定要件を満たす Pc でヒューズをセキュリティで保護されたファームウェア更新のキーが完全にだけなのですねためにです。This is because the secure firmware update key is permanently burnt into fuses on PCs that meet Windows Hardware Certification requirements.

  • 1.3.4 Key Exchange Key (KEK)キー交換キーは、オペレーティング システムとプラットフォーム ハードウェア間の信頼関係を確立します。1.3.4 Key Exchange Key (KEK)Key exchange keys establish a trust relationship between the operating system and the platform firmware. 各オペレーティング システム (および場合によっては、各プラットフォームのファームウェアと通信する必要があるサード パーティ アプリケーション) は、公開キーを登録 (KEKpub)、プラットフォーム ファームウェアにします。Each operating system (and potentially, each 3rd party application which need to communicate with platform firmware) enrolls a public key (KEKpub) into the platform firmware.

    1.3.4.1 キー交換キーを登録します。1.3.4.1 Enrolling Key Exchange Keys

    」の説明に従って、キー交換キーが署名データベースに格納されます1.4 の署名データベース (Db と Dbx)します。Key exchange keys are stored in a signature database as described in 1.4 Signature Databases (Db and Dbx). 署名データベースは、認証済みの UEFI 変数として格納されます。The signature database is stored as an authenticated UEFI variable.

    プラットフォームの所有者に指定したセクション 7.2 (変数サービス) としての下でいずれかの呼び出し元 SetVariable() キー交換キーを登録するUEFI 仕様2.3.1 Errata C.、efi を搭載した_変数_追加_書き込み属性を設定し、新しいキーを含む、データのパラメーターで指定されたセクションとして SetVariable () を使用してデータベースを作成し、や GetVariable() を使用してデータベースを読み取ることによって、既存のキーへの新しいキー交換のキーを追加します。7.2 (変数サービス) UEFI 仕様せず、EFI 2.3.1 Errata C_変数_追加_書き込み属性を設定します。The platform owner enrolls the key exchange keys by either calling SetVariable() as specified in Section 7.2(Variable Services) under UEFI specification 2.3.1 Errata C. with the EFI_VARIABLE_APPEND_WRITE attribute set and the Data parameter containing the new key(s), or by reading the database using GetVariable(), appending the new key exchange key to the existing keys and then writing the database using SetVariable()as specified in Section 7.2(Variable Services) under UEFI specification 2.3.1 Errata C without the EFI_VARIABLE_APPEND_WRITE attribute set.

    プラットフォームがセットアップ モードでは、署名データベース変数に署名する必要はありませんが、として SetVariable() 呼び出しへのパラメーターを準備する必要がありますも 7.2.1 のセクションでは認証済みの変数に指定しました。If the platform is in setup mode, the signature database variable does not need to be signed but the parameters to the SetVariable() call shall still be prepared as specified for authenticated variables in Section 7.2.1. プラットフォームがユーザー モードである場合は、署名データベースが現在 PKpriv と署名している必要があります。If the platform is in user mode, the signature database must be signed with the current PKpriv

    1.3.4.2 KEK をクリアします。1.3.4.2 Clearing the KEK

    行うことが「クリア」(削除)、KEK します。It is possible to “clear” (delete) the KEK. プラットフォーム主キーがインストールされていない場合は、要求の"clear"必要はないことに署名するに注意してください。Note that if the PK is not installed on the platform, “clear” requests are not required to be signed. 署名されている場合、KEK をクリアする PK で署名されたパッケージと db や dbx のいずれかをクリアするが必要です、KEK に存在するすべてのエンティティによって署名されたパッケージ。If they are signed, then to clear the KEK requires a PK-signed package, and to clear either db or dbx requires a package signed by any entity present in the KEK.

    1.3.4.3 Microsoft KEK1.3.4.3 Microsoft KEK

    dbx を更新して問題のあるイメージの失効を有効にするには、Microsoft KEK が必要となります。また、署名された新しい Windows イメージの準備をするために db を更新する場合にも Microsoft KEK が必要です。The Microsoft KEK is required to enable revocation of bad images by updating the dbx and potentially for updating db to prepare for newer Windows signed images.

    次の値を持つ、KEK データベースには、Microsoft Corporation KEK CA 2011 を含めます。Include the Microsoft Corporation KEK CA 2011 in the KEK database, with the following values:

    • 証明書の sha-1 ハッシュ:31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30します。SHA-1 cert hash: 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}します。SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.

    • Microsoft は、証明書をパートナーに提供し、追加すると、 EFI_CERT_X509_GUIDまたはEFI_CERT_RSA2048_GUID型シグネチャ。Microsoft will provide the certificate to partners and it can be added either as an EFI_CERT_X509_GUID or an EFI_CERT_RSA2048_GUID type signature.

    Microsoft KEK 証明書をからダウンロードできます:https://go.microsoft.com/fwlink/?LinkId=321185します。The Microsoft KEK certificate can be downloaded from: https://go.microsoft.com/fwlink/?LinkId=321185.

    1.3.4.4 KEKDefaultプラットフォーム ベンダーが KEKDefault 変数にキー交換キーの既定のセットを提供します。1.3.4.4 KEKDefault The platform vendor may provide a default set of Key Exchange Keys in the KEKDefault variable. 参照してくださいUEFI 仕様27.3.3 詳細セクションします。Please reference UEFI specification section 27.3.3 for more information.

    1.3.4.5 OEM]、[サード パーティの KEK - 複数の KEK を追加します。1.3.4.5 OEM/3rd party KEK - adding multiple KEK

    顧客とプラットフォームの所有者は、独自の KEK を使用する必要はありません。Customers and Platform Owners don’t need to have their own KEK. 非-Windows RT Pc、OEM は OEM または信頼されたを許可する追加の Kek を必要がありますは db と dbx のサード パーティ製のコントロール。On non-Windows RT PCs the OEM may have additional KEKs to allow additional OEM or a trusted 3rd party control of the db and dbx.

  • 1.3.5 セキュリティで保護のブート ファームウェア更新キー安全なファームウェアの更新キーは、更新する必要があるときに、ファームウェアを署名に使用されます。1.3.5 Secure Boot firmware update keyThe Secure firmware update key is used to sign the firmware when it needs to be updated. このキーには RSA 2048 の最小キーの強さが必要です。This key has to have a minimum key strength of RSA-2048. すべてのファームウェアの更新プログラムは、OEM、ODM IBV (独立した BIOS ベンダー) など、信頼されているデリゲートやセキュリティで保護された署名サービスによって安全に署名する必要があります。All firmware updates must be signed securely by the OEM, their trusted delegate such as the ODM or IBV (Independent BIOS Vendor), or by a secure signing service.

    に従ってNIST 文書の 800 147 フィールドのファームウェア更新ガイドラインのすべての要素をサポートする必要があります。As per NIST publication 800-147 Field Firmware Update must support all elements of guidelines:

    ファームウェアのフラッシュ ストアへの更新プログラムは、作成者によって署名する必要があります。Any update to the firmware flash store must be signed by creator.

    ファームウェアでは、更新プログラムの署名を確認する必要があります。Firmware must check signature of the update.

  • 1.3.6 ファームウェアの更新プログラムをセキュリティで保護されたキーのの作成1.3.6 Creation of keys for Secure Firmware Update

    同じキーは、以降、PC 上半分はパブリックのファームウェアの更新プログラムをすべての署名に使用されます。The same key will be used to sign all firmware updates since the public half will be residing on the PC. 可能性がありますもファームウェアの更新のキーで署名キーを更新するファームウェアのセキュリティで保護するには、どのチェーン。You could also sign the firmware update with a key which chains to Secure Firmware update key.

    PK のような PC ごとの 1 つのキーまたはモデルごとに 1 つ、または製品ラインごとに 1 つの可能性があります。There could be one key per PC like PK or one per model or one per product line. 何百万もの一意の更新パッケージを生成する必要があることを意味している PC ごとの 1 つのキーがある場合。If there is one key per PC that would mean that millions of unique update packages will need to be generated. ご検討くださいどのような方法で使用するリソースの可用性に基づきます。Please consider based on resource availability what method would work for you. モデルまたは製品ラインごとのキーは、妥当な結果です。Having a key per model or product line is a good compromise.

    セキュリティで保護されたファームウェアの更新プログラムの公開キー (または領域を節約するには、そのハッシュ) が格納されます – プラットフォームでいくつかの保護された記憶域で一般的に保護されているフラッシュ (PC) または (SOC) のうちの 1 回プログラミング ヒューズします。The Secure Firmware Update public key (or its hash to save space) would be stored in some protected storage on the platform – generally protected flash (PC) or one-time-programmable fuses (SOC).

    場合のみ (スペースを節約する) をこのキーのハッシュが格納されている、し、ファームウェアの更新は、キーを含めること、更新プロセスの最初のステージを確認、更新プログラムの公開キーは、プラットフォームに格納されているハッシュと一致します。If only the hash of this key is stored (to save space), then the firmware update will include the key, and the first stage of the update process will be verifying that the public key in the update matches the hash stored on the platform.

    カプセルは、これによって、OS にデータを渡す UEFI 環境、再起動の間で手段です。Capsules are a means by which the OS can pass data to UEFI environment across a reboot. Windows では、システムと PC のファームウェアの更新プログラムを配信する UEFI UpdateCapsule() を呼び出します。Windows calls the UEFI UpdateCapsule() to deliver system and PC firmware updates. 起動時に ExitBootServices () を呼び出す前に、Windows は UpdateCapsule() に Windows のドライバー ストアにある新しいファームウェア更新プログラムに渡されます。At boot time prior to calling ExitBootServices(),Windows will pass in any new firmware updates found in the Windows Driver Store into UpdateCapsule(). UEFI システム ファームウェアでは、このプロセスを使用して、システムと PC のファームウェアを更新します。UEFI system firmware can use this process to update system and PC firmware. この Windows ファームウェアのサポートを活用することで、OEM は、同じ一般的な形式と両方のシステム用のファームウェアと PC のファームウェアを更新するためのプロセスで利用できます。By leveraging this Windows firmware support an OEM can rely on the same common format and process for updating firmware for both system and PC firmware. ファームウェアは、UEFI UpdateCapsule() の Windows をサポートするために、ACPI ESRT テーブルを実装する必要があります。Firmware must implement the ACPI ESRT table in order to support UEFI UpdateCapsule() for Windows.

    詳細については、Windows の UEFI ファームウェア更新プラットフォームのサポートを実装するのには、次のドキュメントを参照してください。Windows の UEFI ファームウェア更新プラットフォームです。For details on implementing support for the Windows UEFI Firmware Update Platform consult the following documentation: Windows UEFI Firmware Update Platform.

    メモリまたはディスクに、更新カプセルを指定できます。Update capsules can be in memory or on the disk. Windows では、メモリの更新プログラムでサポートされています。Windows supports in memory updates.

    1.3.6.1 capsule (Capsule のメモリ)1.3.6.1 Capsule (Capsule-in-Memory)

    作業のメモリ内更新カプセルのイベントのフローを次に示します。Following is the flow of events for an In-memory update capsule to work.

    1. Capsule は OS 内のアプリケーションでメモリに格納されます。A capsule is put in memory by an application in the OS

    2. メールボックスのイベントが保留中の更新の BIOS を通知するために設定します。Mailbox event is set to inform BIOS of pending update

    3. PC の再起動、capsule イメージと更新プログラムが、BIOS で実行されることを確認します。PC reboots, verifies the capsule image and update is performed by the BIOS

  • 1.3.7 一般的なファームウェアの更新プログラムのワークフロー1.3.7 Workflow of a typical firmware update

    1. ダウンロードして、ファームウェア ドライバーをインストールします。Download and install the firmware driver.

    2. 再起動します。Reboot.

    3. OS ローダーでは、検出し、ファームウェアのことを確認します。OS Loader detects and verifies the firmware.

    4. バイナリの blob は、OS ローダーは、UEFI に渡します。OS Loader passes a binary blob to UEFI.

    5. UEFI は、ファームウェアの更新プログラム (このプロセスは、シリコン ベンダーによって所有されている) を実行します。UEFI performs the firmware update (This process is owned by the silicon vendor).

    6. OS ローダーの検出が正常に完了します。OS Loader detection completes successfully.

    7. OS の起動を完了します。OS finishes booting.

1.4 署名データベース (Db と Dbx)1.4 Signature Databases (Db and Dbx)

  • 1.4.1 許可されている署名データベース (db)1.4.1 Allowed Signature database (db)

    EFI の内容_イメージ_セキュリティ_データベースの db が読み込まれるイメージを検証するときにどのようなイメージが信頼されてを制御します。The contents of the EFI _IMAGE_SECURITY_DATABASE db control what images are trusted when verifying loaded images. 許可されたイメージを識別するために、データベースに複数の証明書、キー、ハッシュを格納できます。The database may contain multiple certificates, keys, and hashes in order to identify allowed images.

    Microsoft Windows 運用 PCA 2011の sha-1 証明書ハッシュと58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8ddb では、Windows OS ローダーで読み込むを許可するために含める必要があります。The Microsoft Windows Production PCA 2011 with a SHA-1 Cert Hash of 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d must be included in db in order to allow the Windows OS Loader to load. Windows の CA は、ここからダウンロードできます:https://go.microsoft.com/fwlink/p/?linkid=321192します。The Windows CA can be downloaded from here: https://go.microsoft.com/fwlink/p/?linkid=321192.

    非-Windows RT Pc OEM 検討など、 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します。On non-Windows RT PCs the OEM should consider including the Microsoft Corporation UEFI CA 2011 with a SHA-1 Certificate Hash of 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3. UEFI を署名ドライバーとアプリケーションでこの証明書により、UEFI ドライバーおよびサード パーティからのアプリケーションのユーザーの追加の手順を必要とせず、PC 上で実行します。Signing UEFI drivers and applications with this certificate will allow UEFI drivers and applications from 3rd parties to run on the PC without requiring additional steps for the user. UEFI CA は、ここからダウンロードできます:https://go.microsoft.com/fwlink/p/?linkid=321194します。The UEFI CA can be downloaded from here: https://go.microsoft.com/fwlink/p/?linkid=321194.

    非-Windows RT Pc、OEM もがその他の項目、db の他のオペレーティング システムまたは OEM が承認した UEFI ドライバーまたはアプリを許可するでも、これらのイメージは何らかの方法で、PC のセキュリティを損なっていない必要があります。On non-Windows RT PCs the OEM may also have additional items in the db to allow other operating systems or OEM-approved UEFI drivers or apps, but these images must not compromise the security of the PC in any way.

  • 1.4.2 DbDefault:プラットフォーム ベンダーは、dbDefault 変数に署名データベースのエントリの既定のセットを提供することがあります。1.4.2 DbDefault: The platform vendor may provide a default set of entries for the Signature Database in the dbDefault variable. 詳細については、UEFI 仕様の 27.5.3」セクションを参照してください。For more information see section 27.5.3 in the UEFI specification.

  • 1.4.3 禁止された署名データベース (dbx)1.4.3 Forbidden Signature Database (dbx)

    内容EFI_イメージ_署名_DATABASE1イメージが実行されないようにする必要があります db と、一致した結果を確認する前にイメージを検証するときに、dbx をチェックする必要があります。The contents of EFI_IMAGE_SIGNATURE_DATABASE1 dbx must be checked when verifying images before checking db and any matches must prevent the image from executing. 許可されていないイメージを識別するために、データベースに複数の証明書、キー、ハッシュを格納できます。The database may contain multiple certificates, keys, and hashes in order to identify forbidden images. Windows ハードウェア認定の要件の状態の sha-256 ハッシュなどの値をダミーいずれかのように、dbx が存在する必要がある0Microsoft では、dbx の更新を提供が開始されるまで、安全なプレース ホルダーとして使用される可能性があります。The Windows Hardware Certification Requirements state that a dbx must be present, so any dummy value, such as the SHA-256 hash of 0, may be used as a safe placeholder until such time as Microsoft begins delivering dbx updates. ここをクリックしてMicrosoft から最新の UEFI 失効リストをダウンロードします。Click Here to download the latest UEFI revocation list from Microsoft.

  • 1.4.4 DbxDefault:プラットフォーム ベンダーは、dbxDefault 変数に署名データベースのエントリの既定のセットを提供することがあります。1.4.4 DbxDefault: The platform vendor may provide a default set of entries for the Signature Database in the dbxDefault variable. 詳細については、UEFI 仕様の 27.5.3」セクションを参照してください。For more information see section 27.5.3 in the UEFI specification.

1.5 すべての Pc でセキュア ブートに必要なキー1.5 Keys Required for Secure Boot on all PCs

キー/DB 名Key/db Name 変数Variable 所有者Owner 説明Notes

PKpubPKpub

PKPK

OEMOEM

PK – 1 の場合のみです。PK – 1 only. RSA 2048 以上の強度する必要があります。Must be RSA 2048 or stronger.

Microsoft Corporation KEK CA 2011Microsoft Corporation KEK CA 2011

KEKKEK

マイクロソフトMicrosoft

Db と dbx の更新プログラムを使用できます。Allows updates to db and dbx:

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

Microsoft Windows Production CA 2011Microsoft Windows Production CA 2011

dbdb

マイクロソフトMicrosoft

この CA 署名データベース (db) では、Windows ブート: https://go.microsoft.com/fwlink/?LinkId=321192します。This CA in the Signature Database (db) allows Windows to boot: https://go.microsoft.com/fwlink/?LinkId=321192.

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

dbxdbx

マイクロソフトMicrosoft

既知の不適切なキー、Ca、または Microsoft からのイメージの一覧List of known bad Keys, CAs or images from Microsoft

ファームウェア更新のキーをセキュリティで保護します。Secure firmware update key

OEMOEM

推奨事項は、PK は異なるこのキーにするにはRecommendation is to have this key be different from PK

表 1:セキュア ブートに必要なキー/dbTable 1: Keys/db needed for Secure Boot

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

以下は特定のメトリック比較に使用します。Below are given some of the metrics we used for comparison.

2.1 メトリックの使用2.1 Metrics used

次のメトリックでは、要件に基づいて HSM PC を選択するのに役立つUEFI 仕様2.3.1 Errata C とニーズです。The following metrics can help you select a HSM PC based on the requirements of UEFI specification 2.3.1 Errata C and your needs.

公開キー基盤 (PKI) に関連Public Key Infrastructure (PKI) related

  • RSA 2048 以上をサポートしますか。Does it support RSA 2048 or higher? - UEFI 仕様2.3.1 Errata C が RSA 2048 以上にするキーをお勧めします。- The UEFI specification 2.3.1 Errata C recommends the keys to be RSA-2048 or better.

  • キーと署名を生成する機能があるでしょうか。Does it have the ability to generate keys and sign?

  • 数のキーに保存できますか。How many keys can it store? HSM または接続されているサーバーにキーに保存しているでしょうか。Does it store keys on HSM or an attached server?

  • 認証キーの取得方法です。Authentication method for key retrieval.

    一部の Pc では、キーの取得に存在する複数の認証エンティティをサポートします。Some PCs support multiple authentication entities to be present for key retrieval.

価格設定Pricing

  • 価格設定とは何ですか。What is the price point? Hsm は、1,500 ドルから利用可能な機能によって 70,000 ドルの価格の範囲です。HSMs can range in price from $1,500 to $70,000 depending on available features.

製造環境Manufacturing environment

  • 工場のフロアでの操作の速度です。Speed of operation on factory floor. 暗号化プロセッサは、キーの作成とアクセスを高速化できます。Crypto processors can speed up key creation and access.

  • セットアップ、展開、保守の容易さ。Ease of setup, deployment, maintenance.

  • スキルセットとトレーニングが必要ですか。Skillset and training required?

  • ネットワーク アクセスのバックアップと高可用性Network access for backup and High Availability

標準およびコンプライアンスStandards and Compliance

  • FIPS 準拠のレベルはありますか。What level of FIPS compliance does it have? タンパーですか。Is it tamper resistant?

  • たとえば、MS crypto Api を他の標準のサポートします。Support for other standards, for example, MS crypto APIs.

  • 政府機関およびその他の機関の要件を満たすには?Does it meet government and other agency requirements?

信頼性とディザスター リカバリーReliability and disaster recovery

  • キーのバックアップを許可しますが、か。Does it allow for Key Backup?

    バックアップを格納する両方のオンサイト CA コンピューターと HSM とオフサイトの場所にまたはよりも、別の物理的な場所は、安全な場所にします。Backups can be stored both onsite in a safe location that is a different physical location than the CA computer and HSM and /or at an offsite location.

  • 呼び出しが許可できる高可用性ディザスター リカバリーのでしょうか。Does it allow for High Availability for disaster recovery?

2.2 キー管理オプション2.2 Key Management Options

  • 2.2.1 ハードウェア セキュリティ モジュール (HSM)2.2.1 Hardware Security Module (HSM)

    上記の条件に基づくこれはおそらく適切かつ最も安全なソリューションです。Based on the above criteria this is probably the most suitable and secure solution. ほとんどの HSM は、FIPS 140-2 レベル 3 の準拠があります。Most HSM have FIPS 140-2 level 3 compliance. FIPS 140-2 レベル 3 の準拠は厳密に認証とキーがないエクスポートまたは HSM からインポートされたことが必要です。FIPS 140-2 level 3 compliance is strict on authentication and requires that keys are not exported or imported from the HSM.

    キー記憶域の複数の方法をサポートしています。They support multiple ways of key storage. HSM に接続されているサーバー上または HSM 自体のローカルに保存できます。They could be stored either locally on the HSM itself or on the server attached to the HSM. キーを暗号化して格納されているサーバーでは、多数のキーを格納する必要がありますソリューションをお勧めします。On the server the keys are encrypted and stored and is preferable for solutions which requires lots of keys to be stored.

    暗号化モジュールのセキュリティ ポリシーは、改ざんシール、ロック、改ざんの応答と zeroization スイッチなどの暗号化モジュールに実装されている物理的なセキュリティ メカニズムをなど、物理的なセキュリティ ポリシーを指定し、アラームです。The cryptographic module security policy shall specify a physical security policy, including physical security mechanisms that are implemented in a cryptographic module such as, tamper-evident seals, locks, tamper response and zeroization switches, and alarms. オペレーターによって改ざんシールの定期的な検査や改ざんの応答と zeroization スイッチのテストなど、物理的なセキュリティが維持されていることを確認するために必要なアクションを指定することもできます。It also allows specifying actions required by the operator(s) to ensure that physical security is maintained such as periodic inspection of tamper-evident seals or testing of tamper response and zeroization switches.

    2.2.1.1 ネットワーク HSM2.2.1.1 Network HSM

    このソリューションは、セキュリティ、標準、キーの生成、格納および取得への準拠の観点からは、そのクラスで最高です。This solution is the best in its class in terms of security, adherence to standards, key generation, storage and retrieval. これらの Pc のほとんどは、高可用性をサポートしており、キーをバックアップする機能があります。Most of these PCs support high availability and have ability to backup keys.

    これらの製品のコストは、数万ドル提供される追加のサービスに基づくので指定できます。The costs of these products can be in tens of thousands of dollars based on the extra services they offer.

    2.2.1.2 スタンドアロン HSM2.2.1.2 Standalone HSM

    これらは、スタンドアロン サーバーでうまく機能します。These work great with standalone servers. 1 つは、Microsoft CAPI と CNG または HSM でサポートされているその他のセキュリティで保護された API を使用できます。One can use Microsoft CAPI and CNG or any other secure API supported by HSM. これらの Hsm は、さまざまな USB や PCMCIA、PCIe バスをサポートしているフォーム ファクターで提供されます。These HSMs come in variety of form factors supporting USB, PCIe and PCMCIA buses.

    必要に応じて、キーのバックアップと高可用性をサポートしています。They optionally support key backup and high availability.

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

    公開キー暗号化は、困難になるし、新しいどのおそらくの暗号化の概念の理解が必要です。Public Key cryptography can be challenging and require understanding of cryptographic concepts which maybe new. 取得のセキュア ブートと製造環境で動作する支援でしたカスタム ソリューション プロバイダーがあります。There are custom solution providers who could help with the getting Secure Boot to work in the manufacturing environment.

    これには、製造環境での作業をセキュリティで保護のブート PKI を取得するには、BIOS のベンダー、HSM の企業と PKI のコンサルティング会社から提供されるカスタム ソリューションの種類があります。There are varieties of custom solutions offered by BIOS vendors, HSM companies and PKI consulting companies to get Secure Boot PKI working in the manufacturing environment.

    プロバイダーの一部は、以下に示します。Some of the providers are listed below:

    2.2.2.1 BIOS ベンダー2.2.2.1 BIOS vendors

    カスタム ソリューションを提供できる可能性のあるいくつかの BIOS のベンダーがあります。There are some BIOS vendors which may be able to provide custom solutions.

    2.2.2.2 HSM ベンダー2.2.2.2 HSM vendors

    一部の HSM ベンダーは、カスタム コンサルティングを提供することができます。Some HSM vendors may be able to provide custom consulting. 詳細については、をセキュリティで保護のブート キーの生成とを使用して HSM の署名 (例)を参照してください。For more info, see Secure Boot Key Generation and Signing Using HSM (Example).

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

    トラステッド プラットフォーム モジュール (TPM) は、暗号化に使用される暗号化キーを格納するマザーボード上のハードウェア チップです。A Trusted Platform Module (TPM) is a hardware chip on the motherboard that stores cryptographic keys used for encryption. 多くのコンピューターには、TPM が含まれますが、PC にそれも含まれていない場合は、1 つを追加できないはありません。Many computers include a TPM, but if the PC doesn’t include it, it is not feasible to add one. 有効にすると、トラステッド プラットフォーム モジュール Microsoft BitLocker 機能などのセキュリティで保護されたすべてのディスク暗号化の製品を使用できます。Once enabled, the Trusted Platform Module can help secure full disk encryption products such as Microsoft BitLocker capabilities. ハード ドライブがロックされている、またはシールされている PC には、システムの検証または認証プロセスが完了するまで保持します。It keeps hard drives locked, or sealed, until the PC completes a system verification or authentication process.

    TPM は生成、保存、および暗号化と復号化プロセスで使用されるキーを保護します。The TPM can generate, store, and protect keys used in the encryption and decryption process.

    Tpm の欠点は、暗号化を高速プロセッサ、製造環境での処理を高速化が必要がありますいないことです。The drawbacks of TPMs are that it may not have fast crypto processors to speed up processing in the manufacturing environment. いない多数のキーの格納に適しています。They also are not suitable for storing large number of keys. バックアップと高可用性と FIPS 140-2 レベル 3 に標準準拠を利用できない可能性があります。Backup and high availability and standards compliance to FIPS 140-2 level 3 may not be available.

  • 2.2.4 スマート カード2.2.4 Smart Cards

    スマート カードは、生成し、キーを格納します。A smart card can generate and store keys. HSM をサポートするなどの認証と改ざんの文章校正、一部の機能を共有する操作を行いますが、多くのキー記憶域またはバックアップが含まれていません。They do share some features which HSM support like authentication and tamper proofing, but they don’t include much key storage or backup. 手動介入を必要とされ、自動化とパフォーマンスが低い可能性がありますとして運用環境での使用に適していない場合があります。They require manual intervention and may not be suitable for automation and use in production environment as the performance maybe low.

    スマート カードの欠点は、Tpm に似ています。The drawbacks of Smart cards are similar to TPMs. 暗号化を高速プロセッサ、製造環境での処理を高速化する必要はありません。They may not have fast crypto processors to speed up processing in the manufacturing environment. いない多数のキーの格納に適しています。They also are not suitable for storing large number of keys. バックアップと高可用性と FIPS 140-2 レベル 3 に標準準拠を利用できない可能性があります。Backup and high availability and standards compliance to FIPS 140-2 level 3 may not be available.

  • 2.2.5 拡張された検証証明書2.2.5 Extended Validation Certificate

    EV 証明書は、高保証証明書の秘密キーを持つは、ハードウェア トークンに格納されます。EV Certificates are high assurance certificates whose private keys are stored in hardware tokens. これより強力なキー管理プラクティスの確立に役立ちます。This helps establish stronger key management practices. EV 証明書には、スマート カードとして同じの欠点があります。EV certificates have the same drawbacks as Smart cards.

  • 2.2.6 ソフトウェア中心のアプローチ (推奨されません)2.2.6 Software-centric approaches (NOT RECOMMENDED)

    キー管理のためには、crypto Api を使用します。Use crypto APIs for key management. 暗号化されたハード ドライブ上のキー コンテナーにキーを格納する可能性があり、可能な追加のサンド ボックス化とセキュリティのための仮想マシンを使用します。This may involve storing a key in a key container on an encrypted hard drive and possible for additional sandboxing and security use a Virtual machine.

    これらのソリューションでは、HSM を使用する場合ほど安全でないし、高い攻撃ベクトルを公開します。These solutions are not as secure as using an HSM and expose a higher attack vector.

    2.2.6.1 Makecert (推奨されません)2.2.6.1 Makecert (NOT RECOMMENDED)

    Makecert は Microsoft ツールは、キーの生成について次のように使用されることができます。Makecert is a Microsoft tool and can be used as follows for key generation. 攻撃対象領域を最小限に抑えるかどうかを確認する「エア ギャップ」する必要があります、PC。To make sure that the attack surface is minimized you may need to “air gap” the PC. 上、PKpriv をされている PC をネットワークに接続されていない必要があります。The PC that has the PKpriv on should not be connected to the network. セキュリティで保護された場所にある必要があり、理想的にする必要があります以上を使用して実際の HSM でない場合に、スマート カード リーダー。It should be in a secure location and ideally should at least use a smart card reader if not a real HSM.

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

    詳細については、証明書作成ツール (Makecert.exe)を参照してください。For more info, see Certificate Creation Tool (Makecert.exe).

    このソリューションは推奨されません。This solution is not recommended.

2.3 HSM キーの生成およびセキュア ブート キーの保存2.3 HSM Key generation and storage for Secure Boot keys

  • 2.3.1 の秘密キーを格納します。2.3.1 Storing Private keys

    RSA 2048 キーごとに必要な領域は、2048 ビットです。The space requirement for each RSA-2048 key is 2048 bits. キーのストレージの実際の場所は、選択したソリューションによって異なります。The actual location of the storage of the keys depends on the solution chosen. HSM は、キーを格納する優れた方法です。HSM are a good way of storing keys.

    工場フロアの Pc の物理的な場所は、安全なケージのような制限付きユーザーのアクセス権を持つ保護された領域をする必要があります。The physical location of the PCs on the factory floor would need to be a protected area with limited user access like a secure cage.

    要件に応じてこれらのキーでしたも格納するさまざまな地理的場所に、または別の場所にバックアップします。Depending on your requirements these keys could also be stored in a diverse geographical location or backed up in a different location.

    キーの再発行の要件のこれらのキーが異なる場合があります、顧客に基づいて (キー更新のガイドラインの連邦政府のブリッジ証明機関の付録 A を参照してください)。The rekeying requirements for these keys could vary based on the customer (see Appendix A for Federal bridge certificate authority rekeying guidelines).

    これらは、1 年あたり 1 回実行できます。These could be done once per year. 30 年間 (キーの再発行要件など。) に応じて、これらのキーにアクセスする必要があります。You may need to have access to these keys for up to 30 years (depending on the rekeying requirements etc.).

  • 2.3.2 秘密キーの取得2.3.2 Retrieving the private Keys

    キーは、多くの理由で取得する必要があります。The keys may need to be retrieved for many reasons.

    1. 主キーが侵害されているため、更新された PK を発行する、または政府に準拠する取得/その他する必要がありますの規制機関。The PK may need to be retrieved to issue an updated PK due to it being compromised or to adhere to government /other agency regulations.

    2. KEKpri は db と dbx の更新に使用されます。KEKpri will be used to update the db and dbx.

    3. セキュア ファームウェア更新キー – pri 新しい更新プログラムの署名に使用されます。Secure firmware update key –pri will be used to sign newer updates.

  • 2.3.3 認証2.3.3 Authentication

    に従って FIPS 140-2 認証へのアクセスのレベルに基づきます。As per FIPS 140-2 authentication is based on level of access.

    レベル 2Level 2

    セキュリティ レベル 2 暗号化モジュールが特定のロールを想定し、対応する一連のサービスを実行するオペレーターの承認を認証する最小値、ロール ベースの認証が必要です。Security Level 2 requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services.

    レベル 3Level 3

    セキュリティ レベル 3 のセキュリティ レベル 2 に指定されたロール ベースの認証メカニズムによって提供されるセキュリティの強化、id ベースの認証メカニズムが必要です。Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2. 暗号化モジュールは、オペレーターの id を認証し、特定のロールを想定し、対応する一連のサービスを実行する特定の演算子が許可されていることを確認します。A cryptographic module authenticates the identity of an operator and verifies that the identified operator is authorized to assume a specific role and perform a corresponding set of services.

    Pc などの HSM のサポートのセキュリティ レベル 3 では、id に基づく"k m 認証"が必要です。PCs like HSM’s support Security Level 3, which requires identity-based “k of m authentication”. つまり、k エンティティ アクセス権が付与 hsm トークンを使用して、特定の時点に少なくとも k、m トークンからは、HSM から秘密キーにアクセスする機能への認証用に存在する必要があります。This means k entities are given access to the HSM with a token but at a given point at least k out of the m tokens need to be present for authentication to work to get access to private keys from HSM.

    たとえば、3/5 がある HSM にアクセスするトークンを認証する必要があります。For example, you could have 3 out of 5 tokens should be authenticated to access HSM. これらのメンバーは、セキュリティ責任者、トランザクションの承認者および経営陣からのメンバーになります。Those members could be the security officers, transaction authorizer and/or members from Executive Management.

    HSM トークンHSM Tokens

    存在するトークンを必要とする HSM にポリシーがある可能性があります。You could have a policy on the HSM which require the token to be present:

    • ローカルLocally

    • リモートでRemotely

    • 構成を自動化するにはConfigured to be automated

    をお勧めのトークンとトークン パスワードごとの組み合わせを使用してください。As a good practice, please use a combination of token and per token password.

2.4 には、ブートおよびサード パーティの署名がセキュリティで保護します。2.4 Secure Boot and 3rd party signing

  • 2.4.1 UEFI ドライバーの署名2.4.1 UEFI driver signing

    UEFI ドライバーでは、CA や、ドキュメントで説明するように、db 内のキーで署名する必要があります。 または、db に含めるドライバー イメージのハッシュします。UEFI Drivers must be signed by a CA or key in the db as described elsewhere in the document, or have the hash of the driver image included in db. Microsoft が UEFI ドライバーの署名と同様、WHQL ドライバーの署名を使用してサービスにサービスを提供する、 Microsoft Corporation UEFI CA 2011します。Microsoft will be providing a UEFI driver signing service similar to the WHQL driver signing service using the Microsoft Corporation UEFI CA 2011. これによって署名されたすべてのドライバーは、Microsoft UEFI CA を含むすべての Pc でシームレスに実行されます。Any drivers signed by this will run seamlessly on any PCs that include the Microsoft UEFI CA. OEM を信頼済みのドライバーに署名し、db に OEM CA を追加、または、db に、ドライバーのハッシュを含めることもできます。It is also possible for an OEM to sign trusted drivers and include the OEM CA in the db, or to include hashes of the drivers in the db. すべてのケースで UEFI ドライバー (オプション ROM) は本が db では、信頼されていない場合に実行されません。In all cases a UEFI driver (Option ROM) shall not execute if it is not trusted in the db.

    システム ファームウェア イメージに含まれているすべてのドライバーは、再検証する必要はありません。Any drivers that are included in the system firmware image do not need to be re-verified. 全体的なシステム イメージの一部であるドライバーは、PC で信頼されているための十分な保証を提供します。Being part of the overall system image provides sufficient assurance that the driver is trusted on the PC.

    マイクロソフトは、これにより、UEFI ドライバーに署名する必要のあるユーザーに使用できます。Microsoft has this made available to anyone who wants to sign UEFI drivers. この証明書は、Windows HCK のセキュア ブート テストの一部です。This certificate is part of the Windows HCK Secure Boot tests. 次の [ブログ] ((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) UEFI CA 署名ポリシーと更新プログラムの詳細を参照します。Follow [this blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) to read more about UEFI CA signing policy and updates.

  • 2.4.2 ブート ローダー2.4.2 Boot loaders

    Microsoft UEFI は、ドライバーの署名証明書を他の Os の署名に使用することができます。The Microsoft UEFI driver signing certificate can be used for signing other OSs. たとえば、Fedora の Linux のブート ローダーによって署名されます。For example, Fedora’s Linux boot loader will be signed by it.

    このソリューションでは、Db のキーに追加する以上の証明書を必要ありません。This solution doesn’t require any more certificates to be added to the key Db. だけでなくコスト効率に優れた、すべての Linux ディストリビューションを使用できます。In addition to being cost effective, it can be used for any Linux distribution. このソリューションで使用するため、ハードウェアのさまざまな場合に便利ですが、Windows をサポートする任意のハードウェア。This solution would work for any hardware which supports Windows so it is useful for a wide range of hardware.

    UEFI CA は、ここからダウンロードできます:https://go.microsoft.com/fwlink/p/?LinkID=321194します。The UEFI-CA can be downloaded from here: https://go.microsoft.com/fwlink/p/?LinkID=321194. 次のリンクがある Windows HCK の UEFI の署名と送信の詳細について。The following links have more information on Windows HCK UEFI signing and submission:

3.まとめとリソース3. Summary and Resources

このセクションでは、上記のセクションをまとめ、ステップ バイ ステップ アプローチを表示します。This section intends to summarize the above sections and show a step by step approach:

  1. セキュリティで保護された CA の確立または安全に生成し、キーを格納するパートナーを識別します。Establish a secure CA or identify a partner to securely generate and store keys

    サード パーティのソリューションを使用していない: 場合If you are not using a 3rd party solution:

    1. インストールし、HSM のサーバーで、HSM のソフトウェアを構成します。Install and configure the HSM software on the HSM server. インストール手順については、HSM のリファレンス マニュアルを確認します。Check your HSM reference manual for installation instructions. サーバーは、スタンドアロンまたはネットワーク HSM には接続か。The server will either be connected to a standalone or network HSM.

      HSM の構成の詳細については、「2.2.1 2.3 と付録 C を参照してください。For info about HSM configuration, see Section 2.2.1, 2.3 and Appendix C.

      ほとんどの Hsm は、FIPS 140-2 レベル 2 および 3 のコンプライアンスを提供します。Most HSMs offer FIPS 140-2 level 2 and 3 compliance. レベル 2 または 3 レベルのコンプライアンスのいずれかの HSM を構成します。Configure the HSM for either level 2 or level 3 compliance. レベル 3 の準拠は、認証とキーのアクセスをより厳密な要件を備え、そのためより安全です。Level 3 compliance has stricter requirements around authentication and key access and hence is more secure. レベル 3 をお勧めします。Level 3 is recommended.

    2. 高可用性、バックアップ、および認証の HSM を構成します。Configure HSM for High Availability, Backup and Authentication. HSM のリファレンス マニュアルを確認します。Check your HSM reference manual.

      HSM プロバイダーのガイドラインをに従って高可用性とバックアップの HSM を設定します。Follow HSM provider guidelines on setting up HSM for High Availability and backup.

      また、ネットワーク Hsm で通常のトラフィックを分離する複数のネットワーク ポートがあります。サーバーを通常の運用環境のネットワークから別のネットワークにネットワーク Hsm との通信を許可します。Also, Network HSMs typically have multiple network ports to segregate traffic; allowing a server to communicate with network HSMs on a network separate from the regular production network.

      セキュリティ チームの一員であるメンバーが識別されたチーム 1 回は、割り当てられているトークン。Once team members who are part of the security team have been identified and tokens assigned to them. HSM ハードウェア k、m の認証をセットアップする必要があります。You will need to setup HSM hardware for k-of-m authentication.

    3. 起動キーを保護し、証明書の事前生成します。Secure Boot Keys and certificate pre-generation. 1.3 ~ 1.5 にセクションを参照してください。See Sections 1.3 to 1.5

      HSM の Api を使用して、事前に生成する (事前に生成)、PK とファームウェアの更新キーと証明書。Use HSM APIs to pre-generate (generate in advance) the PK and Firmware Update Key and certificates.

      必須 - PK (1 1 つのモデルでをお勧めします)、Microsoft KEK、Db、DbxNOTE ファームウェアの更新キー (1 つのモデルは推奨 1)。Microsoft KEK、db と dbx、OEM が生成する必要はなく、完全を期すのため記載されています。(省略可能) - OEM、サード パーティの KEK db、dbx および OEM Db にいる他のキー。Required - PK (recommend 1 per model), Firmware Update key (recommend 1 per model), Microsoft KEK, Db, DbxNOTE: The Microsoft KEK, db, and dbx don’t have to be generated by the OEM and are mentioned for completeness.Optional - OEM/3rd party KEK db, dbx and any other keys which would go into OEM Db.

  2. PC に Windows イメージを適用します。Apply a Windows image to the PC.

  3. Microsoft db と dbx インストールします。Install Microsoft db and dbx. 1.3.6 を参照してくださいと付録 B-セキュリティで保護された Boot Apiします。See Section 1.3.6 and Appendix B – Secure Boot APIs.

    1. インストール、 Microsoft Windows 運用 PCA 2011 db にします。Install the Microsoft Windows Production PCA 2011 into db.

    2. Microsoft で提供されていない場合は、空の dbx をインストールします。Install an empty dbx if Microsoft does not provide one. Windows が自動的に更新 DBX Windows Update から最新の DBX を最初の再起動にします。Windows will automatically update DBX to the latest DBX through Windows Update on first reboot.

    注:Note
    Windows HCK のテストの一部または BIOS のベンダーによって提供されるメソッドを使用して、PowerShell コマンドレットを使用します。Use PowerShell cmdlets which are part of the Windows HCK tests or use methods provided by BIOS vendor.

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

    Microsoft KEK を UEFI KEK データベースにインストールします。Install Microsoft KEK into the UEFI KEK database

    注意Caution
    Windows HCK のテストの一部または BIOS のベンダーによって提供されるメソッドを使用して、PowerShell コマンドレットを使用します。Use PowerShell cmdlets which are part of the Windows HCK tests or use methods provided by BIOS vendor.

  5. 省略可能-OEM サード パーティのセキュリティで保護のブート コンポーネント/ します。Optional step - OEM/3rd party secure boot components. セクション 1.3.4 および 1.4 を参照してください。See Section 1.3.4 and 1.4.

    1. OEM を作成する必要がある場合を識別する]、[サード パーティの KEK、db と dbx。Identify if you have need for creating a OEM/3rd party KEK, db and dbx.

    2. OEM の署名]、[サード パーティ db と dbx OEM でサード パーティの KEK(generated earlier) HSM API を使用して。Sign OEM/3rd party db and dbx with OEM/3rd party KEK(generated earlier) using HSM API.

    3. OEM のインストール]、[サード パーティの KEK、db と dbx します。Install OEM/3rd party KEK, db and dbx.

  6. UEFI ドライバー署名– 2.4 を参照してください。UEFI driver signing – See Section 2.4.

    アドイン カードまたはその他の UEFI ドライバー/アプリ/ブートローダーをサポートしている場合は、インストールMicrosoft Corporation UEFI CA 2011 UEFI db にします。If supporting add-in cards or other UEFI drivers/apps/bootloaders, install Microsoft Corporation UEFI CA 2011 into UEFI db.

  7. セキュア ブート ファームウェアの更新キー -1.3.5 を参照してください。Secure boot firmware update key - See Section 1.3.5.

    1. 非 Windows RT Pc の場合のみ:セキュア ファームウェア更新プログラムの公開キーまたは領域を節約するには、そのハッシュをインストールします。Non-Windows RT PCs only: Install the Secure firmware update public key or its hash to save space.

    2. SoC のみでは、たとえば、違う方法、セキュリティで保護されたファームウェア更新のキーを書き込む必要があります。 パブリック クラウドまたはそのハッシュ。On SoC only, you may need to do something different, for example, burn Secure firmware update key: public or its hash.

  8. セキュア ブートを有効にするします。Enabling Secure Boot. 参照してください付録 B-セキュリティで保護された Boot Apiします。See Appendix B – Secure Boot APIs.

    1. OEM または ODM PKpub のインストール (証明書は、次の推奨、ただしキーは問題ありません) に UEFI PKInstall the OEM/ODM PKpub (certificate preferred, but key is okay) into the UEFI PK.

    2. セキュリティで保護された Boot API を使用して、PK を登録します。Enroll the PK using Secure Boot API. PC は、セキュア ブートのようになりました有効にする必要があります。The PC should be now enabled for Secure Boot.

    注:Note
    最後に、MS KEK、db に PK をインストールする場合は、dbx を署名する必要はありません – SignerInfo 含める必要がありません。If you install the PK at the end, the MS KEK, db, dbx don’t need to be signed – no SignerInfo must be present. これは、ショートカットです。This is a shortcut.

  9. セキュア ブートのテスト:Windows HCK のテストの手順に従って、独自のテストを実行します。Testing Secure Boot: Execute any proprietary tests and Windows HCK tests as per instructions. 参照してください付録 B-セキュリティで保護された Boot Apiします。See Appendix B – Secure Boot APIs.

  10. 出荷プラットフォーム:PKpriv は、おそらく今後使用すること、安全に保管します。Ship platform: The PKpriv will likely never be used again, keep it safe.

  11. サービス:将来のファームウェアの更新プログラムは、署名サービスを使用してファームウェアの更新プログラムをセキュリティで保護された"private"キーを持つ安全に署名されます。Servicing: Future firmware updates are securely signed with the Secure Firmware Update “private” key using the signing service.

3.1 リソース3.1 Resources

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

Windows HCK の送信-https://go.microsoft.com/fwlink/p/?linkid=321287Windows HCK Submission -https://go.microsoft.com/fwlink/p/?linkid=321287

製造業のための付録 A: セキュリティで保護された Boot PKI のチェックリストAppendix A – Secure Boot PKI checklist for manufacturing

高レベルのチェックリストは以下がで非-Windows RT Pc のセキュア ブートを有効にするために必要な手順を要約します。Below is a high-level checklist summarizing the steps needed for enabling Secure Boot on non-Windows RT PCs.

セキュア ブートのセットアップSetting up Secure Boot

  1. セキュリティ戦略の定義 (脅威を特定を主体的および対応戦略の定義) に従ってセクション 4 では、ホワイト ペーパー。Define security strategy (identify threats, define proactive and reactive strategy) as per the white paper in section 4.

  2. セクション 4 では、ホワイト ペーパーに従ってセキュリティ チームを特定します。Identify security team as per the white paper in section 4.

  3. セキュリティで保護された CA を確立するか、安全に生成し、キーを格納する (ソリューションを推奨) パートナーを特定します。Establish a secure CA or identify a partner (recommended solution) to securely generate and store keys.

  4. どの程度の頻度をするキーの更新キーのポリシーを特定します。Identify policy for how frequently you will be rekeying keys. これによって異なります政府機関や他の政府機関など、お客様の特別な要件があるかどうか。This may depend on if you have any special customer requirements like governments or other agencies.

  5. セキュリティ保護のブート キーが侵害された場合にコンティンジェンシー計画があります。Have a contingency plan in case the Secure Boot Key is compromised.

  6. 数 PK、およびその他のキーの識別は次のように 1.3.3 および 1.5 のセクションに従って生成します。Identify how many PK and other keys will you be generating as per section 1.3.3 and 1.5.

    これについては、顧客ベースのキー記憶域ソリューション、Pc のセキュリティに基づきます。This will be based on customer base, key storage solution and security of PCs.

    サード パーティを使用して、キー管理のための推奨されるソリューションを使用している場合は、手順 7. ~ 8. をスキップできます。You can skip steps 7-8 if you are using the recommended solution of using a 3rd party for key management.

  7. キーの管理サーバーとのハードウェアを調達します。Procure server and hardware for key management. – ネットワークまたはスタンドアロン HSM セクション 2.2.1 ごと。– network or standalone HSM per section 2.2.1. 高可用性のためのいくつかの Hsm とキーをバックアップする戦略が必要になるかどうか検討してください。Consider whether you will need one or several HSMs for high availability and your key back up strategy.

  8. HSM で認証の認証トークンを持っている、少なくとも 3 ~ 4 のチーム メンバーを識別します。Identify at least 3-4 team members who will have an authentication token for authentication on HSM.

  9. セキュア ブートに関連するキーと証明書を事前に生成するのにには、HSM またはサード パーティを使用します。Use HSM or 3rd party to pre-generate Secure Boot-related keys and certificates. キーは、PC の種類によって異なります。SoC、Windows RT または Windows 以外の RT.The keys will depend on the PC type: SoC, Windows RT or non-Windows RT. 詳細については、1.5 から 1.3 のセクションを参照してください。For more info, see Sections 1.3 through 1.5.

  10. ファームウェアを適切なキーに設定します。Populate the firmware with the appropriate keys.

  11. セキュア ブートを有効にするセキュリティ保護のブート プラットフォーム キーを登録します。Enroll the Secure Boot Platform Key to enable Secure Boot. 詳細については、付録 B を参照してください。See Appendix B for more details.

  12. セキュア ブートの HCK テストの手順に従って、独自のテストを実行します。Execute any proprietary tests and HCK Secure Boot tests as per instructions. 詳細については、付録 B を参照してください。See Appendix B for more details.

  13. PC を出荷します。Ship the PC. PKpriv は、おそらく今後使用すること、安全に保管します。The PKpriv will likely never be used again, keep it safe.

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

ファームウェア、UEFI コンポーネントの更新、セキュア ブート キーの侵害またはセキュア ブート キーの定期的なキーの更新の修正などのいくつかの理由を更新する必要があります。You may need to update firmware for several reasons such as updating an UEFI component or fixing Secure Boot key compromise or periodic rekeying of Secure Boot keys.

詳細については、セクション 1.3.5 と 1.3.6 のセクションを参照してください。For more info, see Section 1.3.5 and section 1.3.6.

付録 B-セキュリティで保護された Boot ApiAppendix B – Secure Boot APIs

  1. ブート API のセキュリティ保護します。Secure Boot API

    次の Api は UEFI またはセキュア ブートに関連します。The following APIs are related to UEFI/Secure Boot:

    1. GetFirmwareEnvironmentVariableEx:指定したファームウェアの環境変数の値を取得します。GetFirmwareEnvironmentVariableEx: Retrieves the value of the specified firmware environment variable.

    2. SetFirmwareEnvironmentVariableEx:指定したファームウェアの環境変数の値を設定します。SetFirmwareEnvironmentVariableEx: Sets the value of the specified firmware environment variable.

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

  2. PK を設定Setting PK

    セキュア ブートを有効にするには、セット SecureBootUEFI コマンドレットを使用します。Use the Set-SecureBootUEFI cmdlet to turn on Secure Boot. コードは、PK を設定した後は、セキュア ブートのシステムの適用は次回の再起動まで効果をなりません。After your code sets the PK, system enforcement of Secure Boot does not take effect until the next reboot. GetFirmwareEnvironmentVariableEx() または PowerShell コマンドレット、再起動する前に、コードから呼び出す可能性があります。セキュア ブート データベースの内容を確認するには、get SecureBootUEFI します。Prior to the reboot, your code could call GetFirmwareEnvironmentVariableEx() or the PowerShell cmdlet: Get-SecureBootUEFI to confirm the contents of the Secure Boot databases.

  3. 検証Verification

    Msinfo32.exe または PowerShell コマンドレットを使用すると、セキュア ブート変数の状態を確認します。You can use Msinfo32.exe or PowerShell cmdlets to check Secure Boot variable state. WMI インターフェイスはありません。There is no WMI interface. だれかが、署名が正しくない起動可能な USB スティック (たとえばから、Windows HCK セキュリティで保護された Boot 手動ロゴ テスト) を挿入し、起動に失敗したことを確認することでテストすることもできます。You could also test by having someone insert an incorrectly-signed bootable USB stick (for example, from the Windows HCK Secure Boot Manual Logo Test) and verify that it fails to boot.

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

    • Confirm-SecureBootUEFI:UEFI セキュア ブート"ON"、True または False ですか。Confirm-SecureBootUEFI: Is UEFI Secure Boot “ON”, True or False?

      SetupMode 0 を = = (& a) (& a) SecureBoot 1 = =SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI:セキュア ブートの UEFI 変数を設定または追加認証Set-SecureBootUEFI: Set or Append authenticated SecureBoot UEFI variables

    • Get-SecureBootUEFI:認証されたセキュア ブートの UEFI 変数の値を取得します。Get-SecureBootUEFI: Get authenticated SecureBoot UEFI variable values

    • Format-SecureBootUEFI:EFI を作成します_署名_一覧 & EFI_変数_認証_2 シリアル化。Format-SecureBootUEFI: Creates EFI_SIGNATURE_LISTs & EFI_VARIABLE_AUTHENTICATION_2 serializations

  5. Windows HCK とセキュリティで保護された Boot 手順Windows HCK and Secure Boot Instructions

    システムに、次の手順は適用テストと非クラス ドライバー PC をテストします。The following steps apply to system tests and non-class driver PC tests.

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

      BIOS の設定を入力し、セキュア ブートを無効にします。Enter your BIOS configuration and disable Secure Boot.

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

    3. すべての次を除く、Windows HCK テストを実行します。Run all of the Windows HCK tests, except for the following:

      • PCR 使用したテストの BitLocker TPM および回復パスワード[7]BitLocker TPM and Recovery password tests with PCR[7]

      • セキュア ブートと ARM の Pc の BitLocker TPM および回復パスワードのテストBitLocker TPM and Recovery password tests for ARM PCs with Secure Boot

      • セキュア ブート ロゴ テストSecure Boot Logo Test

      • セキュア ブート ロゴの手動テストSecure Boot Manual Logo Test

    4. BIOS の設定を入力しますをセキュリティで保護のブートを有効にする、セキュア ブートを既定の構成を復元します。Enter your BIOS configuration, enable Secure Boot, and restore Secure Boot to the Default configuration.

    5. 次の BitLocker とセキュア ブートのテストを実行します。Run the following BitLocker and Secure Boot tests:

      • PCR 使用したテストの BitLocker TPM および回復パスワード[7]BitLocker TPM and Recovery password tests with PCR[7]

      • セキュア ブートと ARM の Pc の BitLocker TPM および回復パスワードのテストBitLocker TPM and Recovery password tests for ARM PCs with Secure Boot

      • セキュリティで保護のブート ロゴ テスト (自動)Secure Boot Logo Test (automated)

    6. BIOS の設定を入力し、セキュア ブート構成をクリアします。Enter the BIOS configuration and clear the Secure Boot configuration. PK、およびその他のキーを削除することによって、セットアップ モードに PC を復元します。This restores the PC to Setup Mode by deleting PK and other keys.

      注:Note
      クリアのサポートは、x86 または x64 Pc に必要です。Support for clearing is required for x86/x64 PCs.

    7. セキュア ブート ロゴの手動テストを実行します。Run the Secure Boot Manual Logo Test.

      注:Note
      セキュア ブートは、Windows HCK の署名または VeriSign ドライバーを非-Windows RT Pc が必要です。Secure Boot requires Windows HCK signed or VeriSign drivers on non-Windows RT PCs

  6. Windows HCK をセキュリティで保護ブート ロゴ テスト (自動)Windows HCK Secure Boot Logo Test (automated)

    このテストは、適切な既定のセキュリティで保護のブート構成を確認します。This test will check for proper out-of-box Secure Boot configuration. たとえば、次のようなアニメーションや効果を作成できます。This includes:

    • セキュア ブートが有効になっているとします。Secure Boot is Enabled.

    • PK はテスト PK. 既知ではありません。The PK is not a known, test PK.

    • KEK には、運用環境 Microsoft KEK にはが含まれます。KEK contains the production Microsoft KEK.

    • db には、運用環境 Windows の CA にはが含まれています。db contains the production Windows CA.

    • dbx が存在します。dbx present.

    • 1 kB の多数の変数は、作成/削除されます。Many 1kB variables are created/deleted.

    • 32 kB 変数は、作成/削除します。A 32kB variable is created/deleted.

  7. Windows HCK のセキュア ブートの手動テスト フォルダー レイアウトWindows HCK Secure Boot manual test folder layout

    Windows HCK をセキュリティで保護のブートの手動ロゴ テスト フォルダーのレイアウトを以下に示します。The Windows HCK Secure Boot Manual Logo test folder layout is described below:

    • “\Test” 次のフォルダーがあります。“\Test” folder has the following:

      • 製造とサービスのテストManufacturing and Servicing Test

      • プログラムで有効にするセキュア ブート テストの構成Programmatically Enable Secure Boot in test configuration

      • サービスのテストServicing Tests

      • Db に証明書を追加する、関数を確認します。Append a cert to db, verify function

      • ハッシュを dbx を追加、関数を確認します。Append a hash to dbx, verify function

      • Dbx を証明書を追加する、関数を確認します。Append a cert to dbx, verify function

      • Dbx を 600 以上のハッシュを追加、サイズを確認します。Append 600+ hashes to dbx, verify size

      • 主キーをプログラムで変更します。Programmatically change the PK

    • “\Generate” フォルダーには、次を表示するスクリプトがあります。“\Generate” folder has scripts which show the following:

      • テスト証明書の作成方法How test certificates were created

      • テスト証明書と秘密キーが含まれていますThe test certificates and private keys are included

      • すべてのテストの作成方法How all of the tests were created

      • オンにする証明書と署名済みパッケージにハッシュTurning certificates and hashes into signed packages

      • この自分で実行したり、独自の証明書に置き換えてください。You can run this yourself, substitute your own certificates

    • “\certs” フォルダーには、すべての Windows を起動する必要がある証明書があります。“\certs” folder has all of the certificates you need to boot Windows:

      注:Note
      使用する方法を使用しないしてください"ManualTests\生成\TestCerts"キーおよび証明書を生成します。Please don’t use the methodology used in “ManualTests\generate\TestCerts” to generate keys and certificates. これは、Windows HCK テスト目的でのみです。This is meant for Windows HCK test purposes only. これには、非常に安全では非推奨であるディスクに格納されているキーが使用されます。It uses keys which are stored on disk which is very insecure and not recommended. これは、運用環境で使用するためのものではありません。This is not meant for use in a production environment.

-   `“ManualTests\example\OutOfBox”` folder has scripts which you can leverage for installation of Secure Boot on production PCs.

    The “ManualTests\\generate\\tests\\subcreate\_outofbox\_example.ps1” demonstrates how these examples were generated and have “TODO” sections when a partner can substitute their PK and other metadata.
  1. Windows HCK の UEFI の署名と送信Windows HCK UEFI signing and submission

    次のリンクがある詳細については。The following links have more information:

付録 C – 連邦ブリッジ証明機関証明書ポリシー保証のマッピングAppendix C – Federal Bridge Certification Authority Certificate Policy Assurance Mappings

  1. 基本的ですRudimentary

    このレベルは、最下位の程度の個人の身元に関する保証を提供します。This level provides the lowest degree of assurance concerning identity of the individual. このレベルの主な機能の 1 つは、署名されている情報へのデータの整合性を提供します。One of the primary functions of this level is to provide data integrity to the information being signed. このレベルは、関連する環境の悪意のあるアクティビティのリスクが低いと見なされます。This level is relevant to environments in which the risk of malicious activity is considered to be low. 認証を必要とするトランザクションには適していませんと機密性を必要とするトランザクションを一般的には不十分ですが、高い水準の保証を持つ証明書は使用できません、後者に使用できます。It is not suitable for transactions requiring authentication, and is generally insufficient for transactions requiring confidentiality, but may be used for the latter where certificates having higher levels of assurance are unavailable.

  2. 基本的なBasic

    このレベルは、基本的なレベルの保証に関連するデータの侵害のリスクと結果があるが主要な有意性のないと見なされますの環境を提供します。This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to be of major significance. これには、悪意のあるアクセスが発生する可能性が高くない個人情報へのアクセスがあります。This may include access to private information where the likelihood of malicious access is not high. 前提にこのセキュリティ レベルでユーザーが悪意のある可能性がありますいないこと。It is assumed at this security level that users are not likely to be malicious.

  3. [中]Medium

    このレベルは、データの侵害のリスクと結果が中程度の環境に関連します。This level is relevant to environments where risks and consequences of data compromise are moderate. トランザクションや不正行為、または個人情報に関連するアクセスのリスクは大幅な通貨の値を持つ悪意のあるアクセスの可能性が大幅な場合があります。This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.

  4. High

    このレベルは、データへの脅威が高、または、セキュリティ サービスの障害の影響が高い使用に適してします。This level is appropriate for use where the threats to data are high, or the consequences of the failure of security services are high. これには、非常に高い価値のトランザクションまたは高レベルの不正行為のリスクを含めることができます。This may include very high value transactions or high levels of fraud risk.

関連トピックRelated topics

ブート キーの生成および署名の HSM (例) を使用してセキュリティで保護します。Secure Boot Key Generation and Signing Using HSM (Example)

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

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