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

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

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

このドキュメントは、OEM と ODM が製造環境でセキュア ブート キーと証明書を作り、管理する際の指針として役立ちます。プラットフォーム キー (PK)、セキュア ファームウェア更新キー、サード パーティのキー交換キー (KEK) の作成、保管、取得に関連した疑問に答えています。

UEFI とセキュア ブートに関する Windows の要件は、Windows ハードウェア認定の要件に関するページと、Windows Connect や MSDN などから入手できるドキュメントに記載されています。このホワイト ペーパーは、新しい要件を示すものではなく、公式な Windows プログラムでもありません。証明書の要件を超えたガイダンスとして、セキュア ブート キーを作成し管理する効率的で安全なプロセスの構築を支援することを目的としています。これが重要なのは、UEFI セキュア ブートでは、公開キー基盤 (PKI) を使ってコードを認証した後、実行を許可するためです。

読者は、UEFI の基礎、セキュア ブートの基本的な知識 (UEFI 仕様の第 27 章)、および PKI セキュリティ モデルについて理解していることが期待されます。

Windows セキュア ブートを検証するための要件、テスト、ツールは、現在、Windows ハードウェア認定キット (HCK) から入手できます。ただし、これらの HCK リソースは、Windows を展開するためのキーの作成と管理には対応していません。このホワイト ペーパーでは、キー管理について説明し、ファームウェアで使用するキーの展開に関する情報をパートナーに提供します。これは規範を示すガイダンスではなく、新しい要件は一切含みません。

このページの内容

このドキュメントは、顧客向け PC、工場展開ツール、キー セキュリティのベスト プラクティスを開発する出発点として使うことができます。

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

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

セキュア ブートでは、公開キー基盤 (PKI) プロセスに基づいてモジュールを認証した後、実行を許可します。このモジュールには、ファームウェア ドライバー、オプション ROM、ディスク上の UEFI アプリケーション、UEFI アプリ、UEFI ブート ローダーなどがあります。実行前にイメージを認証するセキュア ブートによって、ルートキットのようなマルウェアにブート前に攻撃されるリスクが減ります。Microsoft では、Windows 10、Windows 8.1、Windows 8 において、トラスト ブート セキュリティ アーキテクチャの一部として UEFI セキュア ブートを利用し、お客様のためにプラットフォームのセキュリティを高めています。セキュア ブートは、Windows ハードウェア認定の要件で定義されているように、Windows 10、Windows 8.1、Windows 8 に対応するクライアント PC の必須要件です。

セキュア ブートのプロセスは次のとおりです。図 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 に証明書を要求するユーザーの身元を確認する登録機関。

  • キーを格納してインデックスを作る中央ディレクトリ。

  • 証明書管理システム。

1.2 公開キーの暗号化

公開キーの暗号化では、公開キーおよび秘密キーと呼ばれる数学的に関連した暗号化キーのペアを使います。キーのどちらかを知っていても、もう片方を簡単に計算することはできません。片方のキーを情報の暗号化に使った場合、対応するキーだけがその情報を復号できます。セキュア ブートの場合、秘密キーはコードにデジタル署名をするために使い、公開キーはそのコードの署名を確認してその信頼性を証明するために使います。秘密キーが侵害された場合、対応する公開キーを使っているシステムはもはや安全ではありません。これはブート キット攻撃につながり、秘密キーの安全性を保証するエンティティの評判がダメージを受けます。

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

  • 1.2.1 RSA 2048 暗号化

    RSA-2048 は非対称暗号アルゴリズムです。RSA-2048 絶対値を生の形で格納するのに必要な領域は 2048 ビットです。

  • 1.2.2 自己署名証明書

    証明書の公開キーに合致する秘密キーによって署名された証明書は、自己署名証明書と呼ばれます。ルート証明機関 (CA) の証明書はこのカテゴリに属します。

  • 1.2.3 証明機関

    証明機関 (CA) は、証明書の主体の身元を確認し、証明書に格納された公開キーにその身元を結び付ける署名済み証明書を発行します。CA は証明書の秘密キーを使って証明書に署名します。そして、自己署名ルート CA 証明書ですべての関係者に該当する公開キーを発行します。

    セキュア ブートの場合、証明機関 (CA) には OEM (またはその委任先) と Microsoft を含みます。CA は、信頼のルートを形成するキー ペアを生成し、秘密キーを使って、許可された初期ブート EFI モジュールやリクエストを処理するファームウェアのような正当な操作に署名します。該当する公開キーはセキュア ブート対応の PC 上の UEFI ファームウェアに組み込まれて出荷され、このような操作を検証するために使われます。

    (CA とキー交換の使用法の詳細については、セキュア ブート モデル関連のインターネット サイトで容易に入手できます)

  • 1.2.4 公開キー

    公開プラットフォーム キーは PC に搭載して出荷され、アクセス可能 (つまり "public") です。このドキュメントでは、公開キーを示すために "pub" という接尾辞を使います。たとえば、PKpub は PK の片方の公開キーを指します。

  • 1.2.5 秘密キー

    PKI が機能するには、秘密キーを安全に管理する必要があります。組織内の非常に信頼できる数名の個人だけがアクセスでき、強力なアクセス制限ポリシーが適用された物理的に安全な場所に配置する必要があります。このドキュメントでは、秘密キーを示すために "priv" という接尾辞を使います。たとえば、PKpriv は PK の片方の秘密キーを指します。

  • 1.2.6 証明書

    デジタル証明書の主な用途は、バイナリなどの署名されたデータの出所を確認することです。証明書の一般的な用途は、Transport Layer Security (TLS) や Secure Sockets Layer (SSL) を使ったインターネット メッセージのセキュリティです。証明書を使って署名されたデータを検証すると、受取人がデータの出所、および、途中で変更されたかを知ることができます。

    デジタル証明書は、一般に、高い水準で識別名 (DN)、公開キー、署名を含みます。DN は、証明書の公開キーに合致する秘密キーを保持するエンティティ、たとえば会社を識別します。秘密キーを使って証明書に署名し、証明書に署名を格納すると、秘密キーが公開キーに結び付けられます。

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

  • 1.2.7 証明書のチェーン

    出典: 証明書チェーンに関するページ

    ルート CA は自己署名され、その他はルート 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 HCK の要件

    • キーの生成と管理の要件

    ハードウェア セキュリティ モジュール (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 で指定されているように、PK の公開キー (PKpub) をプラットフォーム ファームウェアに登録します。この手順によりプラットフォームはセットアップ モードからユーザー モードに移行します。Microsoft は、プラットフォーム キーについて、種類は EFI_CERT_X509_GUID、公開キー アルゴリズムは RSA、公開キー長は 2048 ビット、署名アルゴリズムは sha256RSA とすることを推奨しています。プラットフォーム所有者は、ストレージ容量に懸念がある場合、種類を EFI_CERT_RSA2048_GUID にしてもかまいません。公開キーは、先に述べたように署名をチェックするときに使用されます。プラットフォーム所有者は後で PK の秘密キー (PKpriv) を使用できます。

    • プラットフォームの所有者を変更するには、ファームウェアを UEFI で定義されたセットアップ モードにする必要があります。このモードではセキュア ブートは無効になります。セットアップ モードに戻すのは、製造時に必要になった場合のみにすることをお勧めします。

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

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

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

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

    プラットフォーム キーはプラットフォーム固有の安全な方法を使ってクリアすることもできます。この場合、グローバル変数の SetupMode も 1 に更新する必要があります。

    画像: PK によるセットアップ モードとユーザー モードの決定

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

    1.3.3.3 PK の生成

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

    生成する PK の数はプラットフォーム所有者 (OEM) の裁量に任されています。以下が考えられます。

    1. PC ごとに 1 つ。これは政府機関や金融機関など高度なセキュリティを必要とする顧客の場合に必要となる可能性があります。大量の PC 用に秘密キーと公開キーを生成するために、追加のストレージと暗号処理能力が必要になる可能性もあります。HSM ベンダーに基づいて大量のキーを管理する HSM ソリューションもいくつかあります。詳しくは、「HSM を使ったセキュア ブート キーの生成」をご覧ください。

    2. モデルごとに 1 つ。この場合のトレードオフは、キーが侵害されると、同じモデルのすべてのコンピューターが脆弱になるということです。

    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 キー交換キー (KEK) の登録

    キー交換キーは、「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 (変数サービス) で指定されているように、EFI_VARIABLE_APPEND_WRITE 属性を設定せずに GetVariable() を使ってデータベースを読み取り、新しいキー交換キーを既存のキーに追加して、SetVariable() を使ってデータベースに書き込みキー交換キーを登録します。

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

    1.3.4.2 KEK のクリア

    KEK は "クリア" (削除) することができます。PK がプラットフォームにインストールされていない場合、"クリア" 要求に署名する必要はありません。クリア要求が署名されている場合、KEK をクリアするには PK 署名されたパッケージが必要であり、db または dbx をクリアするには、KEK に存在するエンティティによって署名されたパッケージが必要です。

    1.3.4.3 Microsoft KEK

    dbx を更新して問題のあるイメージの失効を有効にするには、Microsoft KEK が必要となります。また、署名された新しい Windows イメージを準備するために db を更新する場合にも Microsoft KEK が必要です。

    KEK データベースに 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 証明書は http://go.microsoft.com/fwlink/?LinkId=321185 からダウンロードできます。

    1.3.4.4 KEKDefault プラットフォーム ベンダーは、KEKDefault 変数のキー交換キーの既定のセットを提供することができます。詳しくは、UEFI 仕様のセクション 27.3.3 をご覧ください。

    1.3.4.5 Windows RT 以外の PC での OEM またはサード パーティ KEK

    パートナーは独自の KEK を持つ必要はありません。Windows RT 以外の PC では、OEM は追加の KEK を使って、別の OEM または信頼されたサード パーティに db と dbx のコントロールを許可することもできます。

    その場合、KEK の秘密キーを安全な場所に保管する必要があります。公開キーは UEFI で定義された PC 上の KEK データベースにあります。UEFI の推奨事項によれば、公開キーは、PC 上の改ざんと削除に対して強い非揮発性ストレージに保管する必要があります。

  • 1.3.5 セキュア ブート ファームウェア更新キー セキュア ファームウェア更新キーは、ファームウェアを更新する必要があるときにファームウェアに署名するために使われます。このキーは RSA-2048 の最小キー長にする必要があります。すべてのファームウェア更新は、OEM、または、ODM や IBV (独立系 BIOS ベンダー) のような信頼された委任先、または、セキュア署名サービスによって安全に署名されている必要があります。

    NIST publication 800-147 によれば、フィールド ファームウェア更新はガイドラインのすべての要素をサポートする必要があります。

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

    ファームウェアは更新の署名をチェックする必要があります。

    セキュア ブート対応のコネクト スタンバイ PC に関する Windows 要件によれば、ブートするたびに署名を検証する必要があります。キーは、1 回だけプログラム可能な不変のストレージに格納する必要があります。このキーが侵害された場合、PC は永続的に侵害されます。コネクト スタンバイ PC 以外の場合、署名は更新時に検証する必要があり、キーは 1 回だけプログラム可能なストレージではなく、保護されたストレージに格納してもかまいません。保護されたストレージは、認証されたメカニズムによってのみフィールド更新が可能です。

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

    PC に公開キーが記録されているため、同じ秘密キーを使ってすべてのファームウェア更新に署名します。セキュア ファームウェア更新キーにチェーンするキーを使って、ファームウェア更新に署名することもできます。

    PK と同様に、PC ごとに 1 つのキー、モデルごとに 1 つのキー、または製品系列ごとに 1 つのキーにすることができます。PC ごとに 1 つのキーにした場合、数百万個の重複しない更新パッケージを生成する必要が生じます。どの方法が適しているか、利用できるリソースに基づいて検討してください。モデルごと、または製品系列ごとに 1 つのキーとするのが、適切な妥協策です。

    セキュア ファームウェア更新の公開キー (または容量節約のためにそのハッシュ) はプラットフォーム上の保護されたストレージ、一般には保護されたフラッシュ (PC) または 1 回だけプログラム可能な回路 (SOC) に格納されます。

    このキーのハッシュだけを格納する場合 (容量を節約するため)、ファームウェア更新にはキーを含み、更新プロセスの最初の段階で、更新の公開キーがプラットフォームに格納されたハッシュに合致するか検証されます。

    カプセルは、再起動時に 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 ローダーで読み込めるようにするために、SHA-1 証明書ハッシュ "58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d" を含む Microsoft Windows Production PCA 2011 を db に含める必要があります。Windows CA は、http://go.microsoft.com/fwlink/p/?linkid=321192 からダウンロードできます。

    Windows RT 以外の PC の場合、OEM は SHA-1 証明書ハッシュが "46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3" の Microsoft Corporation UEFI CA 2011 を含めることを検討する必要があります。UEFI ドライバーとアプリケーションにこの証明書を使って署名すると、ユーザーが追加の手順を踏むことなく、サード パーティの UEFI ドライバーとアプリケーションを PC 上で実行できます。UEFI CA は、http://go.microsoft.com/fwlink/p/?linkid=321194 からダウンロードできます。

    Windows RT 以外の PC の場合、OEM は db に項目を追加して、他のオペレーティング システムまたは OEM が承認した UEFI ドライバーまたはアプリを許可することもできますが、どのような形であれこれらのイメージによって PC のセキュリティが侵害されることがあってはなりません。

  • 1.4.2 DbDefault プラットフォーム ベンダーは、dbDefault 変数の署名データベース エントリの既定のセットを提供することができます。詳しくは、UEFI 仕様のセクション 27.5.3 をご覧ください。

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

    イメージを検証するときは、db を確認する前に、EFI_IMAGE_SIGNATURE_DATABASE1 dbx の内容を確認し、許可されていないイメージがコンピューターで実行されないようにする必要があります。許可されていないイメージを識別するために、データベースに複数の証明書、キー、ハッシュを格納できます。Windows ハードウェア認定の要件では、dbx が存在している必要があるとされているため、Microsoft が dbx 更新の配布を開始するときまで、"0" の SHA-256 ハッシュのようなダミー値を安全なプレースホルダーとして使うことができます。

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

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

キー/DB 名変数所有者メモ

PKpub

PK

OEM

PK - 1 つのみ。RSA 2048 またはそれ以上の強度にする必要があります。

Microsoft Corporation KEK CA 2011

KEK

Microsoft

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

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

Microsoft Windows Production CA 2011

db

Microsoft

署名データベース (db) にあるこの CA は Windows のブートを許可します: http://go.microsoft.com/fwlink/?LinkId=321192

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

dbx

Microsoft

Microsoft が提供する、既知の問題のあるキー、CA、またはイメージのリスト。

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

OEM

このキーは PK と同じにしないことをお勧めします。

 

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

  • 1.5.1 Windows RT 以外の PC で推奨されるキー

    キー/DB 名変数所有者メモ

    Microsoft UEFI ドライバー署名 CA

    db

    Microsoft

    DevCenter プログラム経由で署名されたサード パーティ UEFI ドライバーとアプリのための Microsoft 署名者です: http://go.microsoft.com/fwlink/?LinkId=321194

     

    表 2: Windows RT 以外のセキュア ブート キー

    1.5.2 セキュア ブートの PKI ワークフロー

    キーを生成します。

    1. 必要に応じて、PK、セキュア ファームウェア更新キーなどのキーを作ります。

    2. PC のキーを変更する必要が生じた場合、または、元のキーが失われた場合に備えて、PK のバックアップを作ります。

    3. PowerShell スクリプトまたは BIOS ベンダーのファームウェア メソッドを使って、MS KEK、db、および空の dbx を (特に指定がない限り) インストールします。

    4. 事前に生成した SecureFirmwareUpdateKey-public またはハッシュ (容量節約のため) を使ってファームウェアを更新します。

    5. PowerShell スクリプトまたは BIOS ベンダーのファームウェアを使って、UEFI 変数 PK に署名してインストールします。

    6. Windows HCK セキュア ブート テストも含めて、テストを実行します。たとえば、ChipSec を使ってプラットフォーム コンポーネントのセキュリティを分析します。

    7. PowerShell の SecureBoot コマンドレット (Confirm-SecureBootUEFIGet-SecureBootUEFI など) を使って、セキュア ブート変数の状態を確認します。

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

以下は比較のために使ったメトリック (評価尺度) の一部です。

2.1 使ったメトリック

以下のメトリックは、UEFI 仕様 2.3.1 Errata C とニーズに基づいて HSM PC を選ぶときに役立ちます。

公開キー基盤 (PKI) 関連

  • 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 はほとんどが高可用性をサポートし、キーをバックアップする機能があります。

    製品のコストは、提供される別サービスに応じて 1 万ドル単位になります。

    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 ソフトウェアを中心とした手法 (非推奨)

    キー管理のために暗号 API を使います。暗号化されたハード ディスク上のキー コンテナーにキーを保管することや、追加のサンドボックス化、セキュリティのための仮想マシンの利用も可能です。

    このソリューションは HSM ほど安全ではなく、攻撃の糸口となる弱点も増えています。

    2.2.5.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 回実行することができます。場合によっては、これらのキーに最大 30 年間アクセスできる必要があります (キー更新の要件に左右されます)。

  • 2.3.2 秘密キーの取得

    キーの取得が必要になる理由はいくつもあります。

    1. PK が侵害されたため、または、政府などの機関の規制に従うために、更新された PK を発行することを目的として PK を取得する必要があります。

    2. KEKpri は db と dbx を更新するために使われます。

    3. セキュア ファームウェア更新の秘密キーは、新しい更新に署名するために使われます。

  • 2.3.3 WPA 認証

    FIPS 140-2 によれば、認証はアクセス レベルに基づいて実施されます。

    レベル 2

    セキュリティ レベル 2 では、最低限でも、役割ベースの認証を必要とし、特定の役割を演じて該当するサービス セットを実行するオペレーターを暗号化モジュールが認証します。

    レベル 3

    セキュリティ レベル 3 では、ID ベースの認証メカニズムを必要とし、セキュリティ レベル 2 で指定された役割ベースの認証メカニズムによるセキュリティを強化します。暗号化モジュールはオペレーターの ID を認証し、識別されたオペレーターが特定の役割を演じて、該当するサービス セットを実行する権限があるか検証します。

    HSM のような PC はセキュリティ レベル 3 をサポートし、ID ベースの "k of m 認証" を必要とします。つまり、k 個のエンティティに対してトークン付きで HSM へのアクセスが許可されますが、認証が成功して HSM の秘密キーにアクセスするには、所定の時点で m 個のトークンのうち少なくとも k 個が存在している必要があります。

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

    HSM トークン

    トークンを必要とする HSM 上でポリシーを持つことができます。

    • ローカルに

    • リモートに

    • 自動化が構成された状態で

    優れた慣行として、トークンとトークンごとのパスワードの組み合わせを使ってください。

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

  • 2.4.1 UEFI ドライバーの署名

    UEFI ドライバーはこのドキュメントの別の場所で説明したように CA または db のキーによって署名する必要があります。または、ドライバー イメージのハッシュを db に含める必要があります。Microsoft は、WHQL ドライバー署名サービスと類似した UEFI ドライバー署名サービスを Microsoft Corporation UEFI CA 2011 を使って提供します。これによって署名されたドライバーは、Microsoft UEFI CA のある任意の PC 上でシームレスに実行できます。OEM が信頼されたドライバーに署名して OEM CA を db に含めたり、ドライバーのハッシュを db に含めることもできます。いずれの場合でも、db で信頼されていない場合、UEFI ドライバー (オプション ROM) は実行されません。

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

    このサービスは UEFI ドライバーの署名を望む人はだれでも利用できます。この証明書は Windows HCK セキュア ブート テストの一部です。

  • 2.4.2 ブート ローダー

    Microsoft UEFI ドライバー署名証明書は他の OS を署名するのにも使われます。たとえば、Fedora の Linux ブート ローダーに署名できます。

    このソリューションは、キー Db に証明書を追加する必要がありません。費用対効果が高いほかに、どの Linux ディストリビューションに対しても使うことができます。このソリューションは、Windows をサポートするどのハードウェアでも機能するため、広範なハードウェアで利用できます。

    UEFI-CA は、http://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 と通信できます。

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

    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 HCK テストの一部である PowerShell コマンドレットを使うか、BIOS ベンダーの用意した方法を使います。

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

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

    注意  

    Windows HCK テストの一部である PowerShell コマンドレットを使うか、BIOS ベンダーの用意した方法を使います。

     
  5. 任意の手順 - OEM/サード パーティのセキュア ブート コンポーネント。セクション 1.3.4 と 1.4 を参照してください。

    1. OEM/サード パーティの KEK、db、dbx を作成する必要があるか見極めます。

    2. OEM/サード パーティの db と dbx を OEM/サード パーティの KEK (先に生成済み) と HSM API を使って署名します。

    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. OEM/ODM PKpub (証明書の方が望ましいですが、キーでもかまいません) を UEFI PK にインストールします。

    2. セキュア ブート API を使って PK を登録します。これで PC がセキュア ブート対応になりました。

      

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

     
  9. セキュア ブートのテスト: 独自テストと Windows HCK テストを指示に従って実行します。「付録 B - セキュア ブート API」をご覧ください。

  10. プラットフォームの出荷: PKpriv が再び使われる可能性はありません。安全な場所に保管してください。

  11. サービスの提供: 将来のファームウェア更新は、セキュア ファームウェア更新の "秘密" キーと署名サービスを使って安全に署名されます。

3.1 リソース

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

Windows HCK 提出: http://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 を使います。高可用性とキーのバックアップ戦略のために 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

    次の API が UEFI またはセキュア ブートに関連しています。

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

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

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

  2. PK の設定

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

  3. 検証

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

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

    • Confirm-SecureBootUEFI: UEFI セキュア ブートが有効かどうかを確認します。

      SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI: 認証された SecureBoot UEFI 変数を設定または追加します。

    • Get-SecureBootUEFI: 認証された SecureBoot UEFI 変数の値を取得します。

    • Format-SecureBootUEFI: EFI_SIGNATURE_LIST と 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 変数が作成または削除されているか。

    • 1 つの 32 KB 変数が作成または削除されているか。

  7. Windows HCK セキュア ブートの手動テスト フォルダーの配置

    Windows HCK セキュア ブートの手動ロゴ テスト フォルダーの配置は次のようになっています。

    • “\Test” フォルダーの内容は次のとおりです。

      • 製造と保守作業のテスト

      • テスト構成でセキュア ブートをプログラムから有効にする

      • 保守作業のテスト

      • 証明書を db に追加して機能を確認する

      • ハッシュを dbx に追加して機能を確認する

      • 証明書を dbx に追加して機能を確認する

      • 600 個超のハッシュを dbx に追加してサイズを確認する

      • プログラムから PK を変更する

    • “\Generate” フォルダーには、次の方法を示すスクリプトが格納されています。

      • テスト証明書の作成方法

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

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

      • 証明書とハッシュを署名されたパッケージにする方法

      • これは自分で実行して独自の証明書に置き換えることが可能

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

        

      ManualTests\generate\TestCerts で使われている方法を使ってキーと証明書を作らないでください。これは Windows HCK のテストだけを目的としています。ディスクに保管されているキーを使うため、非常にセキュリティが低く、お勧めできません。これは、運用環境での使用を目的としたものではありません。

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

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

  8. Windows HCK UEFI 署名と提出に関するページ

    詳しくは、次のリンク先をご覧ください。

付録 C - 連邦ブリッジ証明機関の証明書ポリシーの各保証レベル

  1. Rudimentary (初歩)

    このレベルは、個人の ID に関する最低限の保証を提供します。このレベルの主な役割の 1 つは、署名する情報のデータ整合性を確保することです。このレベルは、悪意のあるアクティビティのリスクが低いと考えられる環境に関するものです。認証が必要なトランザクションには適していません。機密性が必要なトランザクションには通常十分ではありません。ただし、保証のレベルが高い証明書を利用できない場合は後者にも使うことができます。

  2. Basic (基本)

    このレベルは、データ侵害のリスクと影響が存在するが、重要性がそれほど大きいとは考えられない環境に関連する、基本的なレベルの保証を提供します。これには、悪意のあるアクセスの可能性が高くない個人情報へのアクセスが含まれる可能性があります。このセキュリティ レベルでは、悪意のあるユーザーがいないと思われることが前提となります。

  3. Medium (中)

    このレベルは、データ侵害のリスクと影響が中程度である環境に関するものです。これには、大きな金銭的価値や詐欺のリスクがあるトランザクション、悪意のあるアクセスの可能性が高い個人情報へのアクセスが必要なトランザクションが含まれる可能性があります。

  4. High (高)

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

関連トピック

HSM を使ったセキュア ブート キーの生成と署名 (例)
UEFI 検証オプション ROM 検証ガイダンス
セキュア ブートの概要

 

 

表示: