次の方法で共有

TPM キーの構成証明

作成者: Justin Turner、Windows グループ、シニア サポート エスカレーション エンジニア、

Note

この内容は Microsoft カスタマー サポート エンジニアによって作成され、TechNet が通常提供しているトピックよりも詳細な Windows Server 2012 R2 の機能やソリューションの技術的説明を求めている、経験豊かな管理者とシステム設計者を対象としています。 ただし、TechNet と同様の編集過程は実施されていないため、言語によっては通常より洗練されていない文章が見られる場合があります。

概要

TPM で保護されたキーのサポートは Windows 8 以降に存在していますが、証明書要求者の秘密キーがトラステッド プラットフォーム モジュール (TPM) によって実際に保護されていることを CA が暗号化の観点から構成証明するメカニズムはありませんでした。 この更新により、CA は、その構成証明を実行し、発行された証明書にその構成証明を反映することができます。

注意

この記事では、証明書テンプレートの概念に読者が精通していることを前提としています (詳細については、「証明書テンプレート」を参照してください)。 また、証明書テンプレートに基づいて証明書を発行するためにエンタープライズ CA を構成する方法に読者が精通していることも前提としています (詳細については、「チェックリスト: 証明書の発行と管理を行うために CA を構成する」を参照してください)。

用語

相談 定義
EK 保証キー。 これは TPM 内に含まれる非対称キーです (製造時に挿入されます)。 EK は各 TPM を一意的に識別できます。 EK を変更または削除することはできません。
EKpub EK の公開キーを意味します。
EKPriv EK の秘密キーを意味します。
EKCert EK 証明書。 TPM 製造元が発行した EKPub の証明書。 すべての TPM に EKCert があるわけではありません。
TPM トラステッド プラットフォーム モジュール。 TPM は、ハードウェア ベースでセキュリティ関連の機能を提供するように設計されています。 TPM チップは、暗号化操作を実行するように設計されたセキュアな暗号プロセッサです。 このチップには、改ざんに強い複数の物理セキュリティ メカニズムが搭載されており、悪意のあるソフトウェアが TPM のセキュリティ機能を破ることはできません。

背景

Windows 8 以降、トラステッド プラットフォーム モジュール (TPM) を使用して、証明書の秘密キーを保護できます。 Microsoft プラットフォーム暗号化プロバイダーのキー記憶域プロバイダー (KSP) により、この機能が有効になります。 実装には、次の 2 つの懸念事項がありました。

  • キーが TPM によって実際に保護されているという保証はありませんでした (ローカル管理者の資格情報を使用してソフトウェア KSP を TPM KSP として簡単に偽装できます)。

  • エンタープライズが発行した証明書を保護できる TPM のリストを制限できませんでした (環境内の証明書を取得するために使用できるデバイスの種類を PKI 管理者が制御する必要がある場合)。

TPM キーの構成証明

TPM キーの構成証明は、証明書を要求するエンティティの機能であり、証明書要求内の RSA キーが、CA が信頼する TPM によって保護されていることを、CA に対して暗号化の観点から証明します。 TPM 信頼モデルの詳細については、この記事の後半の「デプロイの概要」セクションで説明します。

TPM キーの構成証明が重要な理由

TPM で構成証明されたキーを持つユーザー証明書は、エクスポート不可、ハンマリング対策、TPM によって提供されるキーの分離に基づいて、セキュリティが強化されています。

TPM キーの構成証明を使用すると、新しい管理パラダイムが可能になります。管理者は、ユーザーが会社のリソース (VPN やワイヤレス アクセス ポイントなど) にアクセスするために使用できる一連のデバイスを定義し、それらにアクセスするために他のデバイスを使用できないことを確実に保証することができます。 この新しいアクセス制御パラダイムが強力であるのは、それが "ハードウェアにバインドされた" ユーザー ID に結び付いていて、ソフトウェア ベースの資格情報よりも確実であるためです。

TPM キーの構成証明の動作方法

一般に、TPM キーの構成証明は、次の基本動作に基づいています。

  1. すべての TPM は、製造元によって焼き付けられた、"保証キー" (EK) と呼ばれる一意の非対称キーと共に出荷されます。 このキーの公開部分を EKPub、関連付けられている秘密キーを EKPriv と呼びます。 一部の TPM チップには、EKPub のために製造元によって発行された EK 証明書もあります。 この証明書を EKCert と呼びます。

  2. CA は、EKPub または EKCert のいずれかを使用して TPM 内で信頼を確立します。

  3. ユーザーは、証明書が要求されている RSA キーが EKPub に暗号化の観点から関連していることと、ユーザーが EKpriv を所有していることを、CA に対して証明します。

  4. CA は、特別な発行ポリシー OID を持つ証明書を発行して、キーが TPM によって保護されていることの構成証明を示します。

デプロイの概要

このデプロイでは、Windows Server 2012 R2 エンタープライズ CA が設定されていることを前提としています。 また、クライアント (Windows 8.1) は、証明書テンプレートを使用してそのエンタープライズ CA に対して登録するように構成されています。

TPM キーの構成証明をデプロイするには、次の 3 つの手順があります。

  1. TPM 信頼モデルを計画する: 最初の手順では、使用する TPM 信頼モデルを決定します。 これを行うために、3 つの方法がサポートされています。

    • ユーザー資格情報に基づいた信頼: エンタープライズ CA は、証明書要求の一部として、ユーザーが提供する EKPub を信頼します。ユーザーのドメイン資格情報以外の検証は実行されません。

    • EKCert に基づいた信頼: エンタープライズ CA は、証明書要求の一部として提供される EKCert チェーンを、管理者が管理する "許容される EK 証明書チェーン" のリストに対して検証します。 許容されるチェーンは、製造元ごとに定義され、発行元の CA 上の 2 つのカスタム証明書ストア (中間用に 1 つ、ルート CA 証明書用に 1 つのストア) を介して表されます。 この信頼モードは、特定の製造元からのすべての TPM が信頼されることを意味します。 このモードでは、環境で使用されている TPM に EKCert が含まれている必要があることに注意してください。

    • EKPub に基づいた信頼: エンタープライズ CA は、証明書要求の一部として提供される EKPub が、管理者が管理する許可済み EKPub のリストに出現することを検証します。 このリストは、複数のファイルから成るディレクトリとして表されます。このディレクトリ内の各ファイルの名前は、許可済み EKPub の SHA-2 ハッシュです。 このオプションは最高の保証レベルを提供しますが、各デバイスが個別に識別されるので、より多くの管理作業が必要です。 この信頼モデルでは、TPM の EKPub が EKPub の許可済みリストに追加されているデバイスにのみ、TPM で構成証明された証明書への登録が許可されます。

    使用される方法に応じて、CA は、発行された証明書に対して、異なる発行ポリシー OID を適用します。 発行ポリシー OID の詳細については、この記事の「証明書テンプレートを構成する」セクションの発行ポリシー OID に関する表を参照してください。

    TPM 信頼モデルの組み合わせを選択できることに注意してください。 この場合、CA はすべての構成証明方法を受け入れ、発行ポリシー OID には、成功したすべての構成証明方法が反映されます。

  2. 証明書テンプレートを構成する: 証明書テンプレートの構成については、この記事の「デプロイの詳細」セクションで説明します。 この記事では、この証明書テンプレートをエンタープライズ CA に割り当てる方法や、登録アクセス権をユーザーのグループに付与する方法については説明しません。 詳細については、「チェックリスト: 証明書の発行と管理を行うために CA を構成する」を参照してください。

  3. TPM 信頼モデルの CA を構成する

    1. ユーザー資格情報に基づいた信頼: 特定の構成は必要ありません。

    2. EKCert に基づいた信頼: 管理者は、TPM 製造元から EKCert チェーン証明書を取得し、TPM キーの構成証明を実行する CA 上で、管理者によって作成された 2 つの新しい証明書ストアにそれらをインポートする必要があります。 詳細については、この記事の「CA の構成」セクションを参照してください。

    3. EKPub に基づいた信頼: 管理者は、TPM で構成証明された証明書を必要とする各デバイスの EKPub を取得し、許可済み EKPub のリストにそれらを追加する必要があります。 詳細については、この記事の「CA の構成」セクションを参照してください。

    注意

    • この機能には Windows 8.1/Windows Server 2012 R2 が必要です。
    • サード パーティのスマート カード KSP の TPM キーの構成証明はサポートされていません。 Microsoft プラットフォーム暗号化プロバイダーの KSP を使用する必要があります。
    • TPM キーの構成証明は、RSA キーに対してのみ機能します。
    • スタンドアロン CA では、TPM キーの構成証明はサポートされていません。
    • TPM キーの構成証明では、非永続的な証明書処理はサポートされていません。

展開の詳細

証明書テンプレートの構成

TPM キーの構成証明用に証明書テンプレートを構成するには、次の構成手順を実行します。

  1. [互換性] タブ

    [互換性設定] セクション:

    • [証明機関] として [Windows Server 2012 R2] が選択されていることを確認します。

    • [証明書の受信者] として [Windows 8.1 / Windows Server 2012 R2] が選択されていることを確認します。

    [証明書の受信者] の一覧が強調表示されているスクリーンショット。

  2. [暗号化] タブ

    [プロバイダー カテゴリ] として [キー ストレージ プロバイダー] が選択され、[アルゴリズム名] として [RSA] が選択されていることを確認します。 [Requests must use one of the following providers] (要求は次のプロバイダーのいずれかを使用する必要がある) が選択され、[プロバイダー] で [Microsoft プラットフォーム暗号化プロバイダー] オプションが選択されていることを確認します。

    [プロバイダー カテゴリ] と [アルゴリズム名] の一覧が強調表示されているスクリーンショット。

  3. [キーの構成証明] タブ

    これは Windows Server 2012 R2 の新しいタブです。

    [キーの構成証明] タブを示すスクリーンショット。

    3 つのオプションから構成証明モードを選択します。

    構成証明のモードを示すスクリーンショット。

    • なし: キーの構成証明を使用してはならないことを意味します

    • 必須 (クライアントが対応している場合): TPM キーの構成証明をサポートしていないデバイス上のユーザーが、その証明書への登録を続行することを許可します。 構成証明を実行できるユーザーは、特別な発行ポリシー OID で区別されます。 一部のデバイスでは、キーの構成証明をサポートしていない古い TPM があるか、デバイスに TPM がまったくないために、構成証明を実行できない場合があります。

    • 必須: クライアントは、TPM キーの構成証明を実行する "必要があります"。そうしないと、証明書要求は失敗します。

    次に、TPM 信頼モデルを選択します。 ここでも次の 3 つのオプションがあります。

    TPM 信頼モデルを示すスクリーンショット。

    • ユーザー資格情報: 認証ユーザーは、ドメイン資格情報を指定して、有効な TPM を保証できます。

    • 保証証明書: デバイスの EKCert は、管理者が管理する TPM 中間 CA 証明書から、管理者が管理するルート CA 証明書を通じて検証される必要があります。 このオプションを選択する場合は、この記事の「CA の構成」セクションの説明に従って、発行元の CA で EKCA と EKRoot の証明書ストアを設定する必要があります。

    • 保証キー: デバイスの EKPub は、PKI 管理者が管理するリストに出現する必要があります。 このオプションは最高の保証レベルを提供しますが、より多くの管理作業が必要です。 このオプションを選択する場合は、この記事の「CA の構成」セクションの説明に従って、発行元の CA で EKPub リストを設定する必要があります。

    最後に、発行された証明書に表示する発行ポリシーを決定します。 既定では、次の表に示すように、それぞれの実施の種類には、関連付けられたオブジェクト識別子 (OID) があり、その実施の種類が渡されると証明書に挿入されます。 実施方法の組み合わせを選択できることに注意してください。 この場合、CA はすべての構成証明方法を受け入れ、発行ポリシー OID には、成功したすべての構成証明方法が反映されます。

    発行ポリシー OID

    OID キーの構成証明の種類 説明 保証レベル
    1.3.6.1.4.1.311.21.30 EK "EK 検証済み": 管理者が管理する EK のリスト用 高
    1.3.6.1.4.1.311.21.31 保証証明書 "EK 証明書検証済み": EK 証明書チェーンが検証された場合 Medium
    1.3.6.1.4.1.311.21.32 ユーザーの資格情報 "使用時に EK 信頼済み": ユーザーが構成証明した EK 用 低

    [Include Issuance Policies] (発行ポリシーを含める) が選択されている場合 (既定の構成) は、発行された証明書に OID が挿入されます。

    TPM キーの構成証明

    ヒント

    証明書に OID が存在するようにする使用法の 1 つは、特定のデバイスのみに、VPN またはワイヤレス ネットワークへのアクセスを制限する場合です。 たとえば、証明書に OID 1.3.6.1.4.1.311.21.30 が存在する場合に、アクセス ポリシーによって接続 (または別の VLAN へのアクセス) が許可されることがあります。 これにより、TPM EK が EKPUB リストに存在するデバイスのみに、アクセスを制限できます。

CA の構成

  1. 発行元の CA で EKCA と EKROOT の証明書ストアを設定する

    テンプレート設定に [保証証明書] を選択した場合は、次の構成手順を実行します。

    1. Windows PowerShell を使用して、TPM キーの構成証明を実行する証明機関 (CA) サーバー上に 2 つの新しい証明書ストアを作成します。

    2. エンタープライズ環境で許可する中間とルートの CA 証明書を製造元から取得します。 それらの証明書は、必要に応じて、以前に作成した証明書ストア (EKCA と EKROOT) にインポートする必要があります。

    次の Windows PowerShell スクリプトは、これらの両方の手順を実行します。 次の例では、TPM 製造元の Fabrikam がルート証明書 FabrikamRoot.cer と発行元の CA 証明書 Fabrikamca.cer を提供しています。

    PS C:>\cd cert:
PS Cert:\>cd .\\LocalMachine
PS Cert:\LocalMachine> new-item EKROOT
PS Cert:\ LocalMachine> new-item EKCA
PS Cert:\EKCA\copy FabrikamCa.cer .\EKCA
PS Cert:\EKROOT\copy FabrikamRoot.cer .\EKROOT

  2. 構成証明の種類として EK を使用している場合は EKPUB リストを設定する

    テンプレート設定で [保証キー] を選択した場合、次の構成手順では、発行元の CA で、許可済み EK の SHA-2 ハッシュ用にそれぞれ名前が付けられた 0 バイトのファイルを含むフォルダーを作成して構成します。 このフォルダーは、TPM キーで構成証明された証明書を取得できるデバイスの "許可リスト" として機能します。 構成証明済み証明書を必要とするデバイスごとに EKPUB を手動で追加する必要があります。このため、TPM キーで構成証明された証明書を取得する権限を持つデバイスの保証がエンタープライズに提供されます。 このモードの CA を構成するには、次の 2 つの手順が必要です。

    1. EndorsementKeyListDirectories レジストリ エントリを作成する: Certutil コマンドライン ツールを使用して、次の表に示すように、信頼された EKpub が定義されるフォルダーの場所を構成します。

      Operation コマンド構文
      フォルダーの場所を追加する certutil.exe -setreg CA\EndorsementKeyListDirectories +"<フォルダー>"
      フォルダーの場所を削除する certutil.exe -setreg CA\EndorsementKeyListDirectories -"<フォルダー>"

      certutil コマンドの EndorsementKeyListDirectories は、次の表に示すレジストリ設定です。

      値の名前 種類 データ
      EndorsementKeyListDirectories REG_MULTI_SZ <EKPUB 許可リストへの LOCAL または UNC パス>

      例:

      \\blueCA.contoso.com\ekpub

      \\bluecluster1.contoso.com\ekpub

      D:\ekpub

      HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA の校正された名前>

      EndorsementKeyListDirectories には、UNC またはローカル ファイル システムのパスのリストが含まれます。各パスは、CA が読み取りアクセス権を持つフォルダーを指します。 各フォルダーには 0 個以上の許可リスト エントリが含まれます。各エントリは、信頼された EKpub の SHA-2 ハッシュである名前を持つファイルであり、ファイル拡張子はありません。 このレジストリ キー構成を作成または編集するには、既存の CA レジストリ構成設定と同様に、CA を再起動する必要があります。 ただし、構成設定への編集はすぐに有効になります。CA を再起動する必要はありません。

      重要

      承認された管理者のみが読み取り/書き込みアクセス権を持つようにアクセス許可を構成することで、リスト内のフォルダーを改ざんや未承認のアクセスから保護します。 CA のコンピューター アカウントには読み取りアクセス権のみが必要です。

    2. EKPUB リストを設定する: 次の Windows PowerShell コマンドレットを使用して、各デバイスで Windows PowerShell を使用して TPM EK の公開キー ハッシュを取得してから、この公開キー ハッシュを CA に送信し、EKPubList フォルダーに格納します。

      PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256
PS C:>$b=new-item $a.PublicKeyHash -ItemType file

トラブルシューティング

証明書テンプレートでキーの構成証明フィールドを使用できない

テンプレート設定が構成証明の要件を満たしていない場合、キーの構成証明フィールドは使用できません。 一般的な理由は次のとおりです。

  1. 互換性設定が正しく構成されていません。 次のように構成されていることを確認します。

    1. 証明機関: Windows Server 2012 R2

    2. 証明書の受信者: Windows 8.1/Windows Server 2012 R2

  2. 暗号化設定が正しく構成されていません。 次のように構成されていることを確認します。

    1. プロバイダーのカテゴリ: キー ストレージ プロバイダー

    2. アルゴリズム名: RSA

    3. プロバイダー: Microsoft プラットフォーム暗号化プロバイダー

  3. 要求処理設定が正しく構成されていません。 次のように構成されていることを確認します。

    1. [秘密キーのエクスポートを許可する] オプションは選択できません。

    2. [サブジェクトの秘密キーをアーカイブする] オプションは選択できません。

構成証明用の TPM デバイスの検証

Windows PowerShell コマンドレット Confirm-CAEndorsementKeyInfo を使用して、特定の TPM デバイスが CA による構成証明に対して信頼されていることを検証します。 次の 2 つのオプションがあります。1 つは EKCert を検証するため、もう 1 つは EKPub を検証するためです。 コマンドレットは、ローカルに CA 上で、または Windows PowerShell リモート処理を使用してリモート CA 上で実行されます。

  1. EKPub で信頼を検証するには、次の 2 つの手順を実行します。

    1. クライアント コンピューターから EKPub を抽出する: EKPub は、Get-TpmEndorsementKeyInfo を使用してクライアント コンピューターから抽出できます。 管理者特権のコマンド プロンプトから、以下を実行します。

      PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256

    2. CA コンピューター上の EKCert で信頼を検証する: 抽出された文字列 (EKPub の SHA-2 ハッシュ) をサーバーに (メールなどを使用して) コピーし、Confirm-CAEndorsementKeyInfo コマンドレットに渡します。 このパラメーターは 64 文字である必要があることに注意してください。

      Confirm-CAEndorsementKeyInfo [-PublicKeyHash] <string>

  2. EKCert で信頼を検証するには、次の 2 つの手順を実行します。

    1. クライアント コンピューターから EKCert を抽出する: EKCert は、Get-TpmEndorsementKeyInfo を使用してクライアント コンピューターから抽出できます。 管理者特権のコマンド プロンプトから、以下を実行します。

      PS C:>\$a=Get-TpmEndorsementKeyInfo
PS C:>\$a.manufacturerCertificates|Export-Certificate -filepath c:\myEkcert.cer

    2. CA コンピューター上の EKCert で信頼を検証する: 抽出された EKCert (EkCert.cer) を CA に (メールや xcopy などを使用して) コピーします。 たとえば、証明書ファイルを CA サーバー上の "c:\diagnose" フォルダーにコピーする場合は、以下を実行して検証を完了します。

      PS C:>new-object System.Security.Cryptography.X509Certificates.X509Certificate2 "c:\diagnose\myEKcert.cer" | Confirm-CAEndorsementKeyInfo

参照

トラステッド プラットフォーム モジュール テクノロジの概要外部リソース: トラステッド プラットフォーム モジュール