次の方法で共有

OEM 向け Windows 11 での BitLocker ドライブ暗号化

BitLocker ドライブ暗号化は、オペレーティング システムがオフラインの間にドライブが改ざんされないようにすることで、オフライン データとオペレーティング システムを保護します。 BitLocker ドライブ暗号化では、 Trusted Computing Group で定義されているように、信頼度の測定の静的なルートをサポートする TPM (ディスクリートまたはファームウェア) を使用します。

BitLocker 自動デバイス暗号化

BitLocker 自動デバイス暗号化は、ハードウェア要件を満たしたデバイスで Out Of Box EXPERIENCE (OOBE) を完了した後に、BitLocker ドライブ暗号化テクノロジを使用して内部ドライブを自動的に暗号化します。

注

BitLocker の自動デバイス暗号化は、最初の実行エクスペリエンス (OOBE) の間に開始されます。 ただし、保護はユーザーが Microsoft アカウントまたは Azure Active Directory アカウントを使用してサインインインした後でのみ有効になります。 それまでは保護が中断され、データは保護されません。 BitLocker 自動デバイス暗号化はローカル アカウントでは有効になっていません。その場合、Bitlocker コントロール パネルを使用して BitLocker を手動で有効にすることができます。

BitLocker 自動デバイス暗号化のハードウェア要件

注

Windows 11 バージョン 24H2 以降、Microsoft は Windows の自動デバイス暗号化 (Auto-DE) のハードウェア要件を緩和しています。

  • Auto-DEはもはやハードウェアセキュリティテストインターフェース（HSTI）またはモダンスタンバイに依存していません。
  • 信頼されていないダイレクト メモリ アクセス (DMA) バス/インターフェイスが検出された場合でも、自動 DE が有効になる

つまり、OEM は AllowedBuses レジストリ キーに DMA インターフェイスを追加する必要はありません。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

新しい削減された要件は HLK テストに自動的に反映され、OEM からそれ以上のアクションは必要ありません。

この変更は、Windows IoT エディションには適用されません。

BitLocker 自動デバイス暗号化は、次の場合に有効になります。

  • デバイスに TPM (トラステッド プラットフォーム モジュール) (TPM 1.2 または TPM 2.0) が含まれている場合。
  • UEFI セキュア ブートが有効になっている場合。 詳細については、「セキュア ブート」を参照してください。
  • プラットフォームのセキュア ブートが有効になっている場合。
  • プラットフォームがモダン スタンバイまたは HSTI 準拠 (この要件は Windows 11 24H2 以降で削除されています)
  • 許可されていないダイレクト メモリ アクセス (DMA) インターフェイスはありません (この要件は Windows 11 24H2 以降で削除されています)

次のテストは、Windows 11 で BitLocker 自動デバイス暗号化を有効にする前に合格する必要があります。 この機能をサポートするハードウェアを作成する場合は、デバイスがこれらのテストに合格したことを確認する必要があります。

  1. TPM: デバイスに PCR 7 対応の TPM が搭載されている必要があります。 「System.Fundamentals.TPM20.TPM20」を参照してください。

    • 拡張可能なカードの存在により、起動時にUEFI BIOSによってOROM UEFIドライバーが読み込まれる場合、BitLockerはPCR7バインドを使用しません。
    • PCR7にバインドされていないデバイスを実行していて、Bitlockerが有効になっている場合、通常のUEFI PCRプロファイル(0、2、4、11)を使用してもBitLockerはセキュリティで保護されているため、セキュリティ上の問題はありません。
    • 最終的な bootmgr の前に余分な CA ハッシュ (たとえ Windows プロダクト CA であっても) がある場合、BitLocker は PCR7 の使用を選択できなくなります。 余分なハッシュがUEFI CA (別名MicrosoftサードパーティCA)またはその他のCAからのものであるかどうかは関係ありません。

  2. セキュア ブート: UEFI セキュア ブートが有効になっている必要があります。 「System.Fundamentals.Firmware.UEFISecureBoot」を参照してください。

  3. モダン スタンバイの要件または HSTI の検証。 (Windows 11 24H2 以降で削除済み)
    この要件は、次のいずれかによって満たすことができます。

    • モダンスタンバイの要件が実装されています。 これには、UEFI セキュア ブートの要件と、未承認の DMA からの保護に関する要件が含まれます。
    • Windows 10 のバージョン 1703 以降では、HSTI テストで次の要件を満たしていること。
      1. レジストリで構成されたプラットフォームのセキュア ブートの自己テスト（または追加の自己テスト）は、HSTI により実装され、合格したと報告されなければなりません。
      2. Thunderbolt を除き、HSTI は未許可の DMA バスを報告してはならない。
      3. Thunderboltが存在する場合、HSTIはThunderboltが安全に構成されていることを報告する必要があります (セキュリティレベルはSL1– 「ユーザー認証」 以上である必要があります) 。

  4. 起動時に何よりも大切なのは、250 MB の空き領域を確保しておくことです (システム パーティションに WinRE を配置する場合は Windows を復元します)。 詳しくは、 「システムパーティションとユーティリティパーティション」をご覧ください。

上記の要件を満たしている場合、システム情報にシステムが BitLocker 自動デバイス暗号化をサポートしていることが表示されます。 この機能は Windows 10 のバージョン 1703 以降で使用できます。 システム情報を確認する方法を次に示します。

  1. [スタート] をクリックし、「システム情報」と入力します。
  2. システム情報アプリを右クリックし、[管理者として開く] をクリックします。 [はい] をクリックして、アプリがデバイスに変更を加えることを許可します。 一部のデバイスでは、暗号化設定を表示するために高度な権限が必要になる場合があります。
  3. システムの概要については、「デバイスの暗号化のサポート」を参照してください。 デバイスが暗号化されている場合は値が表示され、暗号化されていない場合は、無効になっている理由が表示されます。

許可されていない DMA 対応バス/デバイスが検出されました

デバイスの暗号化サポートでのこのシステム情報の状態は、DMA が脅威にさらされる可能性のある DMA 対応の外部バスまたはデバイスが Windows で少なくとも 1 つ検出されたことを意味します。

この問題を解決するには、IHV に問い合わせて、このデバイスに外部 DMA ポートがないかどうかを確認します。 バスまたはデバイスに内部 DMA しかないことが IHV によって確認された場合、OEM はこれを許可リストに追加できます。

許可リストにバスまたはデバイスを追加するには、レジストリ キーに値を追加する必要があります。 これを行うには、まず、AllowedBuses レジストリ キーの所有権を取得する必要があります。 次のステップを実行します。

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBusesレジストリキーに移動します。

  2. レジストリ キーを右クリックし、[アクセス許可] をクリックします。

  3. [詳細設定] をクリックし、[所有者] フィールドの [変更] リンクをクリックして、ユーザー アカウント名を入力します。次に、[名前の確認] をクリックし、[OK] を 3 回クリックしてすべてのアクセス許可ダイアログを閉じます。

  4. レジストリ キーを右クリックし、[アクセス許可] を再度クリックします。

  5. [追加...]ボタンをクリックし、ユーザーアカウントを追加して、 [名前の確認] 、 [OK] の順にクリックし、 [フルコントロールを許可] の下のチェックボックスをオンにします。 次に、 [OK] をクリックします

次に、AllowedBuses キーの下で、安全であると判断されたフラグ付き DMA 対応バスごとに文字列 (REG_SZ) の名前と値のペアを追加します。

  • キー: デバイスのわかりやすい名前 /説明
  • 値: PCI\VEN_ID&DEV_ID

ID が HLK テストの出力と一致していることを確認します。 たとえば、「Contoso PCI Expressルートポート」、ベンダーID 1022、デバイスID 157Cというフレンドリ名を持つ安全なデバイスがある場合は、Contoso PCI Expressルートポートという名前のレジストリエントリをREG_SZデータ型として作成します。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

ここで、値は "PCI\VEN_1022&DEV_157C" となります。

注: このレジストリ キーは Windows 11 24H2 以降では無視されます。

BitLocker ドライブ暗号化パーティション レイアウト

BitLocker ドライブ暗号化では、Windows パーティションとは別のシステム パーティションを使用します。 BitLocker システム パーティションは、次の要件を満たしている必要があります。

  • BitLocker システム パーティションは、アクティブ パーティションとして構成されます。
  • BitLocker システム パーティションは暗号化しないでください。
  • BitLocker システム パーティションには 250 MB 以上の空き領域が必要です。また、必要なファイルで使用されている領域よりも多くの領域が必要です。 この追加のシステム パーティションを使用して、Windows Recovery Environment (RE) と OEM ツール (OEM が提供) をホストすることができます。ただし、パーティションが 250 MB の空き領域の要件を満たしている必要があります。

詳細については、 「システムパーティションとユーティリティパーティション」および「ハードドライブとパーティション」を参照してください。

BitLocker 自動デバイス暗号化の無効化

OEM はデバイスの暗号化を無効にし、代わりに独自の暗号化テクノロジをデバイスに実装することもできます。 このシナリオの外部で暗号化を無効にすることは、Windows 11 のライセンス要件に違反しており、Windows 11 の "既定で安全" の原則に反しているため、禁止されています。 BitLocker 自動デバイス暗号化を無効にするには、無人セットアップ ファイルを使用して PreventDeviceEncryption を True に設定します。

または、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLockerレジストリキーを更新することもできます。

値: PreventDeviceEncryptionがTrue (1) 。

リコール機能を備えたデバイスで、このレジストリ キーを設定することはお勧めしません。"

BitLocker HLKテストのトラブルシューティング

テスト対象のデバイスに関する次の情報がわかっている場合、トリアージははるかに簡単になります。

  1. TPM仕様(例:1.2、2.0)
  2. BitLocker PCRプロファイル(例:7、11または0、2、4、11)
  3. そのマシンが非 AOAC または AOAC であるか (Surface デバイスは AOAC マシン、など)

この情報は推奨されますが、トリアージを実行するために必要ではありません。

BitLocker HLKの問題は、通常、テスト結果の解釈の誤り、またはPCR7バインドの問題のいずれかに関連しています。

テスト結果の解釈の誤り

HLKテストは、複数のテストステップで構成されます。 一部のテストステップは、テスト全体の成功/失敗に影響を与えずに失敗する場合があります。 結果ページの解釈の詳細については、こちらを参照してください。 一部のテストステップが失敗したが、全体的なテストに成功した場合 (テスト名の横に緑色のチェックマークが付いている場合) は、ここで停止します。 テストは正常に実行され、お客様側で必要な操作はこれ以上ありません。

トリアージ手順:

  1. コンピューターに対して適切なテストを実行していることを確認します。 失敗したテストの任意のステップを右クリック > [インフラストラクチャ] > [Gatherer ログ] > RUNTIMEBLOCK.xml の中で IsAOAC 項目を確認します。 IsAOAC=trueで、非AOACテストを実行している場合は、エラーを無視し、コンピューターに対してこのテストを実行しないでください。 必要に応じて、再生リストを渡すための正誤表については、Microsoftサポートチームにお問い合わせください。

    失敗したテストのスクリーンショット。項目 Is A O A C が選択されています。

  2. テストにフィルターが適用されているかどうかを確認します。 HLKは、正しくマップされていないテストのフィルターを自動的に提案する場合があります。 フィルターは、テストステップの横にある円の中に緑色のチェックマークとして表示されます。 (一部のフィルターでは、後続のテストステップが失敗したか取り消されたことが示される場合があることに注意してください。)特別なアイコンを使用してテストステップを展開し、フィルターに関する拡張情報を確認します。 フィルターによってテストの失敗を無視するように指示された場合は、ここで停止します。

フィルターのスクリーンショット

PCR7 の問題

2つのPCR7テストに固有の一般的なBitLockerの問題は、PCR7へのバインドに失敗したことです。

トリアージ手順:

  1. HLKログでエラーメッセージを検索します。 失敗したテスト ステップを展開し、Te.wtl ログを調べます。 (このログには、テストステップ>を右クリックしてアクセスすることもできますタスクログ>Te.wtl)このエラーが表示された場合は、トリアージの手順に従います。

    H L K ログのエラー メッセージのスクリーンショット。

  2. 管理者としてmsinfo32を実行し、セキュアブート状態/PCR7構成を確認します。 テストは、セキュアブートで実行する必要があります。 PCR7バインドがサポートされていない場合は、代わりに適切なレガシPCR HLKテストを実行します。 PCR7バインドが不可能な場合は、トリアージの手順に従います。

  3. エラーログを確認します。 テストタスク> [追加ファイル] を右クリックします。 通常、PCR7のバインドの問題は、PCR7の測定値が正しくないことが原因です。

    1. イベント ログ。 Microsoft-BitLocker-Managementログには、PCR7を使用できない理由に関する貴重なエラー情報が含まれています。 BitLocker HLKテストは、BitLockerがインストールされているコンピューターでのみ実行する必要があります。 イベントログは、それらを生成するコンピューターで確認する必要があります。
    2. メジャー ブート ログ。 これらは、C:\Windows\Logs\MeasuredBootにもあります。

  4. TBSLogGenerator.exeまたは同等のものを使用して、測定されたブートログを解析します。 HLKコントローラーでは、TBSLogGenerator.exeは、HLKがインストールされているHLKテストディレクトリの下にあります。たとえば、C:\Program Files (x86) \Windows Kits\10\Hardware Lab Kit\Tests\amd\nttest\BASETEST\ngscb\TBSLogGenerator.exe"のようになります。

    1. TBSLogGenerator.exe-lf<測定されたブートログへのパス>>OutputLog.txt
    2. OutputLog.txtで「PCR [07]」を検索し、測定値を順番に確認します。 最初の測定値は次のようになります。

Output Log dot t x t の測定値リストのスクリーンショット。

BitLocker では、PCR7 において特定の信頼性測定の静的ルートが想定されており、これらの測定値に変動があると PCR7 へのバインドが禁止されることがよくあります。 次の値は、PCR7に(順番に、そして間に余分な測定なしで)測定する必要があります。

  • SecureBoot 変数の内容
  • PK 変数の内容
  • KEK 変数の内容
  • EFI_IMAGE_SECURITY_DATABASE変数 (DB) の内容
  • EFI_IMAGE_SECURITY_DATABASE1変数 (DBX) の内容
  • (省略可能ですが、一般的な EV_SEPARATOR)
  • ブートパスでEFIドライバーまたはEFIブートアプリケーションを検証するために使用されるEFI_IMAGE_SECURITY_DATABASE内のエントリ。 BitLockerでは、ここで1つのエントリのみが想定されています。

測定されたブートログに関する一般的な問題:

  • UEFIデバッグモードがオン
  • PKまたはKEK変数が不足しています。PK/KEK測定にデータがありません(例えば4バイトの0)
  • 信頼されていないUEFI CA署名者

UEFIデバッグモードでの実行など、一部の測定されたブートの問題は、テスト担当者によって解決される場合があります。 その他の問題では、正誤表が必要になる場合があります。その場合は、Microsoftサポートチームに連絡してガイダンスを参照してください。

デバイスへのファームウェア更新プログラムの適用

HLK テストの実行に加え、OEM では BitLocker を有効にした状態でファームウェアの更新をテストする必要があります。 デバイスが不必要に回復を開始しないようにするには、次のガイドラインに従ってファームウェアの更新プログラムを適用します。

  1. BitLocker を中断します (PCR [07] にバインドされているデバイスでは、ファームウェアの更新によってセキュア ブート ポリシーが変更された場合のみ必要)
  2. 更新プログラムを適用する
  3. デバイスを再起動します
  4. BitLocker を再開します

ファームウェアの更新では、デバイスで Bitlocker を短時間だけ中断し、できるだけ早く再起動する必要があります。 BitLocker は、Windows Management Instrumentation (WMI) の DisableKeyProtectors メソッド を使用して、シャットダウンする直前にプログラムによって中断できます。