TPM, PIN, Passwörter, SID: BitLocker Key Protectors verwalten

BitLocker verschlüsselt den FVEK seinerseits mit dem Volume Master Key (VMK) und legt beide auf dem verschlüsselten Laufwerk ab, und zwar in einem Bereich des Volume-Headers, der unverschlüsselt bleibt. Andernfalls würde sich BitLocker selbst aussperren.

Protectors schützen den Volume Master Key

Um an den FVEK zu gelangen, benötigt man also den VMK. Dieser sollte daher ebenfalls vor unautorisiertem Zugriff geschützt sein. Für diese Aufgabe verwendet BitLocker die folgenden Protectors:

• TPM
• TPM mit PIN
• TPM mit Startup-Key
• TPM mit PIN und Startup-Key
• Passwort
• Wiederherstellungspasswort
• Externer Recovery Key
• Zertifikat für Wiederherstellungsagenten oder Network Unlock
• Auto Unlock und Active-Directory-Benutzer bzw. -Gruppe

Jeder Protector erhält eine eigene Kopie des VMK, den er mit seinen eigenen Mitteln verschlüsselt.

TPM, PIN und Startschlüssel

Die Kombination aus TPM, PIN oder Startschlüssel ist ausschließlich für das Betriebs­system­laufwerk vorgesehen. Standardmäßig nutzt BitLocker nur das TPM, so dass der Rechner ohne Benutzereingriff entsperrt wird.

Das TPM verschlüsselt den MVK mit seinem Public Key und entschlüsselt ihn beim Hochfahren des Rechners mit seinem Private Key. Zusätzlich untersucht es die Integrität des Systems mit Hilfe der in den Platform Configuration Register (PCR) gespeicherten Parameter. Nur wenn der Rechner diese Prüfung besteht, gibt das TPM den VMK frei.

Ergänzt man die TPM-Authentifizierung um eine PIN oder einen Startschlüssel, dann muss der VMK auch von diesen Mechanismen erfolgreich entschlüsselt werden, bevor er zugänglich ist.

Wiederherstellungsschlüssel

Schlägt das Entsperren über den konfigurierten Protector fehl, etwa weil sich die Hardware verändert oder der Benutzer die PIN vergessen hat, dann benötigt man eine alternative Option, um an den VMK zu gelangen.

Aus diesem Grund generiert BitLocker bei seiner Aktivierung per Voreinstellung ein 48-stelliges numerisches Recovery Password. Dieses könnte man theoretisch auch als einzigen Protector verwenden und bei jedem Booten des Rechners eingeben, aber dies ist nicht praktikabel.

Wenn der Wieder­herstellungs­schlüssel in die Hände eines Angreifers gerät, dann kann er im Recovery Mode alleine damit das Laufwerk entsperren. Daher ist eine sichere Aufbewahrung des Keys ausschließlich für den Notfall essentiell. Ist der Rechner Mitglied in einer Domäne, dann kann man dafür das Active Directory als Speicher nutzen.

Passwörter

Während die Kombination aus TPM und PIN das beste Verhältnis aus Sicherheit und Benutzerkomfort bietet, gilt für ein Passwort das Gegenteil. Es sorgt für den schwächsten Schutz und seine Verwendung ist zudem nicht komfortabel, wenn es die nötige Komplexität hat. Diese kann man per Gruppen­richtlinie vorgeben.

BitLocker lässt zudem beliebig viele Fehlversuche zu, was die Möglichkeit für Brute-Force-Attacken eröffnet. Aus diesem Grund ist ein Passwort per Voreinstellung als Protector für Systemlaufwerke nicht zulässig, wenn nicht zusätzlich ein TPM konfiguriert wurde.

Externer Key

BitLocker kennt zwei Arten von Schlüsseln, die auf USB-Laufwerken gespeichert werden, nämlich den Startup Key und den Recovery Key. Ersterer lässt sich mit einem TPM kombinieren oder auf alten PCs ohne TPM alleine einsetzen. Der Wieder­herstellungs­schlüssel dient hingegen für den Notfall.

Technisch scheint es keinen großen Unterschied zwischen beiden zu geben, denn der Hilfetext von manage-bde beschreibt SaveExternalKey, den gemeinsamen Parameter für beide Typen, folgendermaßen:

Diese externen Schlüsseldateien können als Systemstart- oder Wieder­herstellungs­schlüssel verwendet werden.

Auto Unlock und SID-Protector

Beide Mechanismen vereinfachen den Zugang zu Datenlaufwerken, weil sie Benutzern die Eingabe eines Passworts ersparen. Sie sind jedoch an bestimmte Bedingungen geknüpft.

Das automatische Entsperren setzt voraus, dass das Systemlaufwerk ebenfalls mit BitLocker geschützt ist. Den Key, mit dem der VMK des Datenlaufwerks verschlüsselt wird, legt Windows nämlich in der Registry ab. Ein ungeschütztes Systemlaufwerk wäre dafür ein schlechter Speicherort.

Der Protector ADAccountOrGroup (auch SID genannt) entsperrt ein Datenlaufwerk automatisch, wenn die dafür konfigurierten Gruppen oder Benutzer aus dem Active Directory angemeldet sind.

Jeder andere User, der sich auf dem Rechner einloggt, erhält keinen automatischen Zugang zum betreffenden Datenträger.

Recovery Agent

Wieder­herstellungs­agenten eignen sich ebenfalls nur für Daten-, aber nicht für Systemlaufwerke. Letztere lassen sich damit nur dann entsperren, wenn man den Rechner von einem anderen Datenträger bootet und wie ein Datenlaufwerk anspricht.

Das Zertifikat für Wieder­herstellungs­agenten muss im lokalen Store jedes Rechners gespeichert werden, auf dem man ein Laufwerk entsperren möchte. Daher eignet sich diese Technik beispielsweise sehr gut, wenn der Helpdesk verschlüsselte USB-Sticks von Mitarbeitern entgegennimmt, die das Passwort dafür vergessen haben.

Network Unlock

Die Authentifizierung mit TPM und PIN erfordert physischen Zugriff auf den Rechner, wenn er hochfährt oder aus dem Ruhezustand aufwacht. Dies kann ein Hindernis für das Remote-Management sein, bei dem PCs über Wake-on-LAN starten. Für diesen Fall bietet Microsoft die BitLocker Netzwerk­entsperrung.

Das Hinzufügen eines Protectors ist hier nur ein kleiner Teil der Konfiguration. Man benötigt dafür ein spezielles Zertifikat, die Windows Deployment Services und einen DHCP-Server.

Protectors verwalten

Microsoft sieht für das Management der Key Protectors ein Zusammenspiel von Gruppenrichtlinien und PowerShell bzw. manage-bde vor. Für alle drei Typen von Datenträgern existiert die GPO-Einstellung Festlegen, wie BitLocker-geschützte Laufwerke wiederhergestellt werden können.

Dort kann man Recovery Agents, Wieder­herstellungs­passwörter und externe Recovery Keys zulassen, erzwingen oder verbieten.

Für Betriebs­systemlaufwerke existieren zusätzlich die Einstellungen Netzwerkentsperrung beim Start zulassen sowie Zusätzliche Authentifizierung beim Start anfordern.

Die erste bezieht sich auf den Network Unlock und die zweite behandelt solche Protectors, die BitLocker für Daten- und Wechsellaufwerke nicht unterstützt. Dies betrifft die Kombinationen aus TPM, PIN und Startup-Schlüssel.

Die in den Gruppenrichtlinien vorgenommenen Einstellungen bestimmen das Verhalten des Assistenten zum Aktivieren von BitLocker, den man in der Systemsteuerung findet. Abhängig von den konfigurierten Richtlinien bietet er die blockierten Protectors nicht mehr an oder fordert umgekehrt das Festlegen einer PIN oder eines Passworts, wenn diese genutzt werden müssen.

Die Gruppenrichtlinien unterbinden auch das Anlegen von nicht zulässigen Protectors, wenn Benutzer dafür PowerShell oder manage-bde verwenden wollen. Die Group Policies berücksichtigen allerdings nicht alle Protectors, so dass man etwa Auto Unlock oder SID-Protectors damit nicht verhindern kann.

Protector hinzufügen

Bevorzugt man manage-bde für diese Aufgabe, dann sieht ein Aufruf so aus:

manage-bde -protectors -add <Laufwerk:> -<Protector>

Für <Protector> sind zulässig:

• RecoveryPassword oder -rp
• RecoveryKey oder -rk
• StartupKey oder -sk
• Certificate oder -cert
• TPMAndPIN oder -tp
• TPMAndStartupKey oder -tsk
• TPMAndPINAndStartupKey oder -tpsk
• tpm
• Password oder -pw
• ADAccountOrGroup oder -sid

Zum Beispiel würde das folgende Kommando einen Wiederher­stellungs­schlüssel für Laufwerk c: erzeugen:

manage-bde -protectors -add c: -RecoveryPassword

Der 48-stellige Key wird dabei automatisch generiert und auf der Konsole angezeigt. Hingegen muss man ein Passwort interaktiv eingeben, das Gleiche gilt für die PIN.

Wenn man den Parameter ComputerName bzw. cn angibt, dann kann man Protectors auch remote auf anderen PCs verwalten.

Um sich zu überzeugen, welche Protectors für c: existieren, ruft man manage-bde so auf:

manage-bde -status c:

Key Protectors mit PowerShell erstellen

In PowerShell ist das Cmdlet Add-BitLockerKeyProtector für diese Aufgabe zuständig.

Man kann ihm Passwörter und PINs als Secure String an die entsprechenden Parameter übergeben, andernfalls werden sie interaktiv abgefragt:

$pin = Read-Host -AsSecureString -Prompt "PIN eingeben: "

Add-BitLockerKeyProtector -MountPoint c: -TpmAndPinProtector -Pin $pin

Wie man sieht, sind die Namen für die Protectors über die verschiedenen Tools hinweg nicht konsistent. Die Parameter für manage-bde und Add-BitLockerKeyProtector heißen anders, und bei den WMI-Funktionen muss man sich nochmal umstellen.

Das Cmdlet unterstützt den Parameter ComputerName nicht, so dass man für das Management entfernter PCs eine Remote-Session starten müsste.

Um zu prüfen, welche Protectors konfiguriert sind, bietet sich ein solcher Aufruf an:

Get-BitLockerVolume -MountPoint "c:" |
select -ExpandProperty KeyProtector

Protectors mit WMI hinzufügen

Will man für diese Aufgabe die WMI-Klasse Win32_EncryptableVolume verwenden, dann benötigt man in PowerShell das Cmdlet Get-WmiObject, weil viele Methoden in Get-CimInstance nicht zur Verfügung stehen.

Die obigen Beispiele würde man für einen Remote-PC hiermit so umsetzen:

$bl = Get-WmiObject -Namespace "Root\cimv2\security\MicrosoftVolumeEncryption" `
-ClassName Win32_EncryptableVolume -Filter 'DriveLetter="c:"' `
-ComputerName win11-vm1-l1

# 48-stellingen Recovery Key einrichten

$bl.ProtectKeyWithNumericalPassword()

# TPM mit PIN, den Wert für die PIN als String mitgeben

$bl.ProtectKeyWithTPMAndPIN("TPMundPIN", "", "123456")

Die Funktion ProtectKeyWith­NumericalPassword() generiert zwar das Wieder­herstellungs­pass­wort, gibt es aber nicht aus. Dieses muss man daher separat in Erfahrung bringen, wobei man dazu die ID das Protectors benötigt, die man beim Anlegen angezeigt bekommt:

$bl.GetKeyProtectorNumericalPassword("{6A9BD3E2-373C-4898-9227-A805D38667FE}")

Abschließend kann man mit

$bl.GetKeyProtectors() | select -ExpandProperty VolumeKeyProtectorID

die konfigurierten Protectors anzeigen, wobei man hiermit nur deren ID erhält. Über diese Funktion kann man dann den Typ ermitteln:

$bl.GetKeyProtectorType("{2DDEA952-4CA9-4683-9AA5-62C0CFEC6EBE}")

Das Ergebnis ist numerisch, seine Bedeutung kann man in der Dokumentation nachsehen.

Protector entfernen

Wenn man schließlich Protectors von einem Laufwerk entfernen möchte, dann lässt sich das so erledigen:

Remove-BitLockerKeyProtector -MountPoint "c:" `
-KeyProtectorId "{6A2DEFC2-2348-4A5B-9337-F3E2B33B5943}"

Die ID des Protectors kann man der Ausgabe von Get-BitLockerVolume entnehmen:

Get-BitLockerVolume -MountPoint c:

Bevorzugt man für das Löschen manage-bde.exe, dann sieht der Befehl so aus:

manage-bde -protectors -delete C: -id {6A2DEFC2-2348-4A5B-9337-F3E2B33B5943}

Alternativ kann man alle Key Protectors eines Typs so entfernen:

manage-bde -protectors -delete c: -Type RecoveryPassword

Zusammenfassung

Die Key Protectors stellen ein zentrales Konzept von BitLocker dar und Admins sind damit regelmäßig konfrontiert, wenn Benutzer ihre Rechner nicht entsperren können. Allerdings sollten diese Schutz­mechanismen nicht erst die Aufmerksamkeit der Systemverwaltung bekommen, wenn Probleme auftreten.

Vielmehr gehört es zu einer guten Planung des BitLocker-Einsatzes, sich vorab Gedanken darüber zu machen, wie man den VMK schützen möchte. Auf Betriebs­system­laufwerken fällt diese Entscheidung meistens zugunsten von TPM plus PIN aus.

Für Datenlaufwerke und Wechseldatenträger gibt es eine Reihe von Optionen, bei deren Wahl die Anforderungen der jeweiligen Umgebung entscheidend sind. Einige davon lassen sich per Gruppen­richtlinien vorgeben, die Verwaltung erfolgt dann in der Regel über PowerShell oder manage-bde.