BitLocker-Laufwerkverschlüsselung in Windows 11 für OEMs

BitLocker-Laufwerkverschlüsselung bietet Schutz für Offlinedaten und das Betriebssystem, indem sichergestellt wird, dass das Laufwerk nicht manipuliert wird, während das Betriebssystem offline ist. BitLocker-Laufwerkverschlüsselung verwendet ein TPM, entweder ein eigenständiges oder Firmware, das die „Static Root of Trust Measurement“ wie von der Trusted Computing Group definiert unterstützt.

Automatischen Geräteverschlüsselung von BitLocker

Die automatische BitLocker-Geräteverschlüsselung verwendet die BitLocker-Laufwerkverschlüsselungstechnologie, um interne Laufwerke automatisch zu verschlüsseln, nachdem der Benutzer die Out-of-Box-Experience (OOBE) auf Geräten abgeschlossen hat, die die Hardwareanforderungen erfüllen.

Hinweis

Die automatische BitLocker-Geräteverschlüsselung wird während der Out-of-Box-Experience (OOBE) gestartet. Der Schutz ist jedoch nur aktiviert (scharfgestellt), nachdem sich Benutzer mit einem Microsoft-Konto oder einem Azure Active Directory-Konto angemeldet haben. Bis dahin ist der Schutz ausgesetzt und Daten sind nicht geschützt. Die automatische Geräteverschlüsselung von BitLocker ist nicht für lokale Konten aktiviert. In diesem Fall kann BitLocker mithilfe der BitLocker-Systemsteuerung manuell aktiviert werden.

Hardwareanforderungen für die automatische Geräteverschlüsselung von BitLocker

Hinweis

Ab Windows 11 Version 24H2 hat Microsoft die Hardwareanforderungen für die automatische Geräteverschlüsselung (Automatic Device Encryption, Auto-DE) in Windows reduziert:

• Auto-DE hängt nicht mehr von der Schnittstelle des Hardware-Sicherheitstests (Hardware Security Test Interface, HSTI)/dem modernen Standby-Modus ab.

• Auto-DE wird aktiviert, auch wenn nicht vertrauenswürdige DMA-Busse (Direct Memory Access)/Schnittstellen erkannt werden.

Dies bedeutet, dass OEMs dem Registrierungsschlüssel „AllowedBuses“ keine DMA-Schnittstellen hinzufügen müssen: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

Diese neuen, reduzierten Anforderungen werden automatisch in HLK-Tests widergespiegelt, und OEMs müssen keine weiteren Aktionen ausführen.

Die automatische Geräteverschlüsselung von BitLocker ist aktiviert, wenn:

• Das Gerät enthält ein TPM (Trusted Platform Module), entweder TPM 1.2 oder TPM 2.0.
• UEFI Secure Boot ist aktiviert. Weitere Informationen finden Sie unter Sicherer Start.
• UEFI Secure Boot ist aktiviert
• Die Plattform ist mit Modern Standby oder HSTI kompatibel (diese Anforderung wurde ab Windows 11 24H2 entfernt)
• Es sind keine nicht zulässigen DMA (Direct Memory Access)-Schnittstellen vorhanden (diese Anforderung wurde seit Windows 11 24H2 entfernt)

Die folgenden Tests müssen bestanden sein, bevor Windows 11 die automatische Geräteverschlüsselung von BitLocker aktiviert. Wenn Sie Hardware erstellen möchten, die diese Funktion unterstützt, müssen Sie überprüfen, ob Ihr Gerät diese Tests besteht.

1. TPM: Das Gerät muss ein TPM mit PCR 7-Unterstützung enthalten. Siehe System.Fundamentals.TPM20.TPM20.

   • Wenn die Anwesenheit erweiterbarer Karten dazu führt, dass OROM-UEFI-Treibern während des Starts von UEFI BIOS geladen werden, verwendet BitLocker keine PCR7-Bindung.
   • Wenn Sie ein Gerät ausführen, das nicht an PCR7 gebunden ist und Bitlocker aktiviert ist, bestehen keine Sicherheitsnachteile, da BitLocker weiterhin sicher ist, wenn ein reguläres UEFI-PCR-Profil (0,2.4.11) verwendet wird.
   • Aller zusätzlicher CA-Hash (sogar Windows Prod CA) vor dem endgültigen bootmgr von Windows Prod CA sorgt dafür, dass BitLocker PCR7 nicht verwendet. Es ist nicht wichtig, ob der oder die zusätzlichen Hashes aus UEFI CA (auch als Microsoft-Drittanbieter-CA bezeichnet) oder aus einer anderen CA stammen.

2. Sicherer Start: UEFI Secure Boot ist aktiviert. Siehe System.Fundamentals.Firmware.UEFISecureBoot.

3. Modern Standby-Anforderungen oder HSTI-Validierung. (seit Windows 11 24H2 entfernt)
   Diese Anforderung wird durch eine der folgenden Möglichkeiten erfüllt:

   • Die Modern Standby-Anforderungen sind implementiert. Dazu gehören Anforderungen für UEFI Secure Boot und Schutz vor nicht autorisiertem DMA.
   • Ab Windows 10, Version, 1703, kann diese Anforderung über den HSTI-Test erfüllt werden:
     1. Der Platform Secure Boot-Selbsttest (oder zusätzliche Selbsttests wie in der Registrierung konfiguriert) müssen von HSTI als implementiert gemeldet und zugelassen werden.
     2. Mit Ausnahme von Thunderbolt muss HSTI keine nicht zulässigen DMA-Busse melden.
     3. Wenn Thunderbolt vorhanden ist, muss HSTI melden, dass Thunderbolt sicher konfiguriert ist (Sicherheitsstufe muss SL1 – „Benutzerberechtigung“ oder höher sein).

4. Sie müssen über 250 MB freien Speicherplatz zusätzlich zu allem, was Sie hochfahren, verfügen (und Windows wiederherstellen, falls Sie WinRE in der Systempartition platzieren). Weitere Informationen finden Sie unter System- und Hilfsprogrammpartitionen.

Wenn die oben aufgeführten Anforderungen erfüllt sind, unterstützt das System die automatische Geräteverschlüsselung von BitLocker. Diese Funktionalität ist in Windows 10, Version 1703 oder später verfügbar. Hier erfahren Sie, wie Sie Systeminformationen überprüfen.

1. Klicken Sie auf Start und geben Sie Systeminformationen ein
2. Klicken Sie mit der rechten Maustaste auf die Systeminformationen-App und klicken Sie Als Administrator öffnen. Lassen Sie zu, dass die App Änderungen an Ihrem Gerät vornehmen kann, indem Sie auf Ja klicken. Einige Geräte erfordern möglicherweise erhöhte Berechtigungen, um die Verschlüsselungseinstellungen anzuzeigen.
3. In der Systemzusammenfassung finden Sie die Unterstützung von Geräteverschlüsselung. Der Wert gibt an, ob das Gerät verschlüsselt ist, und falls nicht, die Gründe, warum Verschlüsselung deaktiviert ist.

Nicht zulässige DMA-fähige Busse/Geräte

Dieser Systeminformationsstatus in der Geräteverschlüsselungsunterstützung bedeutet, dass Windows mindestens einen potenziellen externen DMA-fähigen Bus oder ein Gerät erkannt hat, die eine DMA-Bedrohung darstellen können.

Um dieses Problem zu beheben, wenden Sie sich an die IHV(s), um festzustellen, ob dieses Gerät keine externen DMA-Ports aufweist. Wenn von den IHVs bestätigt wird, dass der Bus oder das Gerät nur über interne DMA verfügt, kann der OEM sie zur Positivliste hinzufügen.

Zum Hinzufügen eines Busses oder Geräts zur Positivliste müssen Sie einem Registrierungsschlüssel einen Wert hinzufügen. Dazu müssen Sie zuerst den Registrierungsschlüssel AllowedBuses übernehmen. Folgen Sie diesen Schritten:

1. Navigieren Sie zum Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses.

2. Klicken Sie mit der rechten Maustaste auf den Registrierungsschlüssel, und wählen Sie Berechtigungen… aus.

3. Klicken Sie auf Erweitert, klicken Sie auf den Link Ändern im Feld Besitzer, geben Sie Ihren Benutzerkontonamen ein, klicken Sie auf „Namen überprüfen“ und dann dreimal auf OK, um alle Berechtigungsdialogfelder zu schließen.

4. Klicken Sie mit der rechten Maustaste auf den Registrierungsschlüssel, und wählen Sie Berechtigungen… erneut aus.

5. Klicken Sie auf die Schaltfläche Hinzufügen..., fügen Sie Ihr Benutzerkonto hinzu, klicken Sie auf „Namen überprüfen“, und klicken Sie dann auf OK. Aktivieren Sie dann das Kontrollkästchen unter „Vollsteuerung zulassen“. Klicken Sie dann auf „OK“.

Fügen Sie dann unter dem Schlüssel AllowedBuses Zeichenfolgen (REG_SZ) von Name/Wert-Paaren für jeden gekennzeichneten DMA-fähigen Bus hinzu, der als sicher erachtet wird:

• Schlüssel: Anzeigename des Geräts /Beschreibung
• Wert: PCI\VEN_ID&DEV_ID.

Stellen Sie sicher, dass die IDs mit der Ausgabe aus dem HLK-Test übereinstimmen. Wenn Sie z. B. über ein sicheres Gerät verfügen, das den Anzeigenamen „Contoso PCI Express Root Port“, die Hersteller-ID 1022 und die Geräte-ID 157C hat, erstellen Sie einen Registrierungseintrag mit dem Namen Contoso PCI Express Root Port als REG_SZ Datentyp in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

Wobei der Wert = "PCI\VEN_1022&DEV_157C"

Hinweis: Dieser Registrierungsschlüssel wird ab Windows 11 24H2 ignoriert.

BitLocker-Laufwerkverschlüsselung – Partitionslayout

Die BitLocker-Laufwerkverschlüsselung verwendet eine Systempartition, die von der Windows-Partition getrennt ist. Die BitLocker-Systempartition muss die folgenden Anforderungen erfüllen.

• Die BitLocker-Systempartition ist als aktive Partition konfiguriert.
• Die BitLocker-Systempartition darf nicht verschlüsselt sein.
• Die BitLocker-Systempartition muss mindestens 250 MB freien Speicherplatz aufweisen, deutlich mehr als der Speicherplatz, der von erforderlichen Dateien verwendet wird. Diese zusätzliche Systempartition kann verwendet werden, um Windows Recovery Environment (RE) und OEM-Tools (bereitgestellt durch den OEM) zu hosten, solange die Partition weiterhin die Speicherplatzanforderung von 250 MB erfüllt.

Weitere Informationen finden Sie unter System- und Hilfsprogrammpartitionen und unter Festplatten und Partitionen.

Automatischen Geräteverschlüsselung von BitLocker

OEMs können die Geräteverschlüsselung deaktivieren und stattdessen ihre eigene Verschlüsselungstechnologie auf einem Gerät implementieren. Um die automatische BitLocker-Geräteverschlüsselung zu deaktivieren, können Sie eine Unattend-Datei verwenden und PreventDeviceEncryption auf „True“ festlegen.

Alternativ können Sie den Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker aktualisieren:

Wert: PreventDeviceEncryption gleich True (1).

Es wird nicht empfohlen, diesen Registrierungsschlüssel auf Geräten mit Abruffunktion festzulegen.“

Problembehandlung bei BitLocker HLK-Tests

Empfohlene Voraussetzungen

Triage ist viel einfacher, wenn Sie die folgenden Informationen über das Gerät unter Test kennen:

1. TPM-Spezifikation (z. B. 1.2, 2.0)
2. BitLocker PCR-Profil (z. B. 7, 11 oder 0, 2, 4, 11)
3. Ob der Computer nicht AOAC oder AOAC ist (z. B. Surface-Geräte sind AOAC-Computer)

Diese Informationen werden empfohlen, sind aber nicht erforderlich, um Triagen durchzuführen.

BitLocker HLK-Probleme beziehen sich in der Regel auf eine der folgenden Probleme: Falschinterpretieren von Testergebnissen, oder PCR7-Bindungsprobleme.

Falschinterpretieren von Testergebnissen

Ein HLK-Test besteht aus mehreren Testschritten. Einige Testschritte können fehlschlagen, ohne sich auf Erfolg/Fehlschlagen des Gesamttests auszuwirken. Weitere Informationen zum Interpretieren der Ergebnisseite finden Sie hier. Wenn einige Testschritte fehlgeschlagen sind, aber der Gesamttest bestanden ist (wie durch ein grünes Häkchen neben dem Testnamen angegeben), beenden Sie hier. Der Test wurde erfolgreich ausgeführt und es ist keine weitere Aktion erforderlich.

Triaging-Schritte:

1. Bestätigen Sie, dass Sie den richtigen Test auf dem Computer ausführen. Klicken Sie mit der rechten Maustaste auf einen beliebigen Schritt der fehlgeschlagenen Tests > Infrastruktur > Gatherer-Protokolle > und suchen Sie in RUNTIMEBLOCK.xml nach dem Element IsAOAC. Wenn IsAOAC = true ist und Sie einen Nicht-AOAC-Test ausführen, ignorieren Sie den Fehler und führen Sie diesen Test nicht auf dem Computer aus. Wenden Sie sich bei Bedarf an das Microsoft-Support Team, um eine Errata für das Weitergeben der Wiedergabeliste zu erhalten.

   

2. Ermitteln Sie, ob ein Filter auf den Test angewendet wird. HLK kann automatisch einen Filter für einen falsch zugeordneten Test vorschlagen. Ein Filter wird als grünes Häkchen in einem Kreis neben einem Testschritt angezeigt. (Beachten Sie, dass einige Filter möglicherweise zeigen, dass die nachfolgenden Testschritte fehlgeschlagen oder abgebrochen wurden.) Untersuchen Sie die erweiterten Informationen zum Filter, indem Sie den Testschritt mit dem speziellen Symbol erweitern. Wenn der Filter dazu aufruft, den Testfehler zu ignorieren, beenden Sie hier.

PCR7-Probleme

Ein häufiges BitLocker-Problem, das für die beiden PCR7-Tests spezifisch ist, ist ein Fehler bei der Bindung an PCR7.

Triaging-Schritte:

1. Suchen Sie die Fehlermeldung in den HLK-Protokollen. Erweitern Sie den fehlgeschlagenen Testschritt und überprüfen Sie das Te.wtl-Protokoll. (Sie können auch auf dieses Protokoll zugreifen, indem Sie mit der rechten Maustaste auf einen Testschritt > Vorgangsprotokolle > Te.wtl klicken) Führen Sie die folgenden Triageschritte aus, wenn dieser Fehler angezeigt wird:

   

2. Führen Sie msinfo32 als Administrator aus und überprüfen Sie die Konfiguration von Sicherer-Start-Status/PCR7. Der Test sollte mit sicherem Start ausgeführt werden. Wenn die PCR7-Bindung nicht unterstützt wird, führen Sie stattdessen den entsprechenden Legacy PCR HLK-Test aus. Wenn die PCR7-Bindung nicht möglich ist, fahren Sie mit den Triageschritten fort.

3. Untersuchen Sie die Fehlerprotokolle. Klicken Sie mit der rechten Maustaste auf die Testaufgabe > Weitere Dateien. In der Regel ist das PcR7-Bindungsproblem ein Ergebnis falscher Maßeinheiten in PCR7.

   1. Ereignisprotokolle: Das Microsoft-BitLocker-Management-Protokoll enthält wertvolle Fehlerinformationen darüber, warum PCR7 nicht verwendet werden kann. Der BitLocker HLK-Test sollte nur auf einem Computer ausgeführt werden, auf dem BitLocker installiert ist. Ereignisprotokolle werden auf dem Computer überprüft, auf dem sie generiert werden.
   2. Protokolle für gemessenen Start. Diese finden Sie auch unter C:\Windows\Logs\MeasuredBoot

4. Analysieren Sie das Protokoll für gemessenen Start mithilfe von TBSLogGenerator.exe oder etwas Gleichwertigem. Auf dem HLK-Controller ist TBSLogGenerator.exe unter dem HLK-Testverzeichnis gefunden, in dem Sie HLK installiert haben, z. B. unter C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\amd64\nttest\BASETEST\ngscb\TBSLogGenerator.exe."

   1. TBSLogGenerator.exe -lf < Pfad zum Protokoll für gemessenen Start>> OutputLog.txt
   2. Suchen Sie in OutputLog.txt nach „PCR[07]“ und untersuchen Sie die Messungen, die in der Reihenfolge aufgeführt sind. Die Ausgabe sollte etwa wie folgt aussehen:

BitLocker erwartet bestimmte statische Root-of-Trust-Messungen in PCR7, und jede Variation in diesen Messungen verbietet häufig die Bindung an PCR7. Die folgenden Werte sollten in PCR7 gemessen werden (nacheinander und ohne zusätzliche Messungen dazwischen):

• Die Inhalte der SecureBoot-Variable
• Die Inhalte der PK-Variable
• Die Inhalte der PK-Variable
• Die Inhalte der EFI_IMAGE_SECURITY_DATABASE-Variable (DB)
• Die Inhalte der EFI_IMAGE_SECURITY_DATABASE1-Variable (DB)
• (optional, aber häufig EV_SEPARATOR)
• Einträge in EFI_IMAGE_SECURITY_DATABASE, die verwendet werden, um EFI-Treiber oder EFI-Startanwendungen im Startpfad zu validieren. BitLocker erwartet hier nur einen Eintrag.

Häufige Probleme mit dem gemessenen Startprotokoll:

• UEFI-Debugmodus ist eingeschaltet
• Fehlende PK- oder KEK-Variablen: PK/KEK-Messung verfügt über keine Daten (z. B. 4 Bytes an Nullen)
• Nicht vertrauenswürdiger UEFI CA-Unterzeichner

Einige gemessene Startprobleme, z. B. die Ausführung mit dem UEFI-Debugmodus, können vom Tester behoben werden. Andere Probleme erfordern möglicherweise eine Errata, in diesem Fall sollten Sie sich an das Microsoft-Support Team wenden, um Anleitung zu erhalten.

Anwenden von Firmwareupdates auf Geräte

Zusätzlich zur Ausführung von HLK-Tests müssen OEMs Firmwareupdates mit aktiviertem BitLocker testen. Um zu verhindern, dass Geräte die Wiederherstellung unnötig starten, befolgen Sie diese Richtlinien, um Firmwareupdates anzuwenden:

1. Halten Sie BitLocker (erforderlich für Geräte, die an PCR[07] gebunden sind) nur an, wenn das Firmwareupdate die Richtlinie für den sicheren Start ändert
2. Anwenden des Updates
3. Neustart des Geräts
4. Fortsetzen von BitLocker

Das Firmwareupdate sollte vom Gerät verlangen, Bitlocker nur für kurze Zeit anzuhalten, und das Gerät sollte so schnell wie möglich neu starten. BitLocker kann direkt vor dem Heruntergefahren programmgesteuert angehalten werden, indem Sie die Methode DisableKeyProtectors in Windows Management Instrumentation (WMI) verwenden.

Zugehörige Themen

• Windows 10-Sicherheitsfeatures und -anforderungen für OEMs