Verschlüsselte Volumes: BitLocker, FileVault und VeraCrypt

Die Verschlüsselung von Volumes und Containern ist auf vielen Laptops inzwischen Standard. Diese Lektion behandelt, wie Sie BitLocker-, FileVault-, LUKS- und VeraCrypt-Volumes in einem Abbild oder einer Triage-Erfassung erkennen, wie die Schlüssel von BitLocker hierarchisch aufgebaut sind, welche rechtmäßigen Schlüsselquellen und Zugriffsmöglichkeiten auf laufenden Systemen bestehen und wie Sie dokumentieren, was nicht untersucht werden konnte. Das Erraten von Passwörtern ist ein gesondertes Verfahren, das von der rechtlichen Befugnis abhängt und hier nicht behandelt wird.

Hindernis oder Anti-Forensik?

Verschlüsselung ist in der Regel legitim: Sie dient dem Schutz der Privatsphäre, wird durch Datenschutzrichtlinien vorgegeben oder von Betriebssystemen automatisch aktiviert. Behandeln Sie sie zunächst als Hindernis. Sie ist nur dann eine anti-forensische Handlung, wenn der Kontext diese Einordnung stützt, beispielsweise bei einem Container, der durch einen irreführenden Namen getarnt und im zeitlichen Umfeld des Vorfalls erstellt oder verwendet wurde, oder bei Software, die ausgeführt und anschließend entfernt wurde. Führen Sie diese Schlussfolgerung getrennt vom technischen Befund auf.

Verschlüsselte Volumes erkennen

BitLocker

Ein BitLocker-Volume behält einen unverschlüsselten Volume-Header bei, dessen OEM-Kennung an Offset 3 die 8-Byte-Zeichenfolge -FVE-FS- ist. Bei einem NTFS-Volume steht dort NTFS, gefolgt von vier Leerzeichen. Das Volume enthält außerdem drei Kopien des FVE-Metadatenblocks (Full Volume Encryption), die ebenfalls jeweils mit -FVE-FS- beginnen; sie enthalten die Verschlüsselungsmethode, die Schlüsselschutzvorrichtungen und die verschlüsselten Schlüssel. Windows 10 Version 1511 führte XTS-AES ein; frühere Versionen verwendeten AES-CBC. Auf Wechseldatenträgern können BitLocker To Go-Volumes, die FAT-formatiert waren, einen Header im FAT32-Stil mit der OEM-Kennung MSWIN4.1 aufweisen. Eine Suche nach -FVE-FS- auf dem Volume findet daher weiterhin die Metadatenblöcke.

Auf einem laufenden System meldet manage-bde -status für jedes Volume den Konvertierungsstatus, den verschlüsselten Prozentsatz, die Verschlüsselungsmethode, den Schutzstatus, den Sperrstatus und die Schlüsselschutzvorrichtungen. Der Ereignisprotokollkanal Microsoft-Windows-BitLocker/BitLocker Management (Datei Microsoft-Windows-BitLocker%4BitLocker Management.evtx) zeichnet Ereignisse auf, beispielsweise den Beginn der Verschlüsselung, das Hinzufügen oder Entfernen von Schlüsselschutzvorrichtungen und die Sicherung von Wiederherstellungsinformationen. Die Ereignis-IDs unterscheiden sich zwischen Windows-Versionen. Filtern Sie daher nach Kanal und lesen Sie den Meldungstext.

FileVault

Auf einem Mac schützt FileVault das APFS-Datenvolume. Ein APFS-Volume-Superblock ohne das Flag APFS_FS_UNENCRYPTED (0x1 in apfs_fs_flags) kennzeichnet ein verschlüsseltes Volume. Wie in Lektion 1.7 erläutert, verschlüsseln Macs mit T2-Chip oder Apple Silicon interne Datenträger immer hardwareseitig; FileVault ergänzt die Anforderung, dass die Anmeldedaten eines Benutzers den Schlüssel entsperren müssen. Auf einem laufenden System meldet fdesetup status: „FileVault ist aktiviert.“

LUKS

Linux Unified Key Setup beginnt an Offset 0 mit der 6-Byte-Magic-Signatur LUKS\xba\xbe (4C 55 4B 53 BA BE), gefolgt von einer 2-Byte-Versionsnummer: 1 oder 2. LUKS1 besitzt einen 592 Byte großen binären Header mit acht Schlüsselslots und verwendet PBKDF2. LUKS2 besitzt einen 4.096 Byte großen binären Header, gefolgt von JSON-Metadaten, eine zweite Header-Kopie mit der Magic-Signatur SKUL\xba\xbe, bis zu 32 Schlüsselslots und üblicherweise Argon2id als Standard. Jeder Schlüsselslot enthält den Volume-Schlüssel, verschlüsselt mit einer Passphrase oder einer Schlüsseldatei.

VeraCrypt und TrueCrypt

VeraCrypt, der Nachfolger von TrueCrypt (2014 eingestellt), schreibt keine Klartextsignatur. Der Header beginnt mit einem zufälligen 64-Byte-Salt; die Magic-Signatur VERA (oder TRUE) erscheint erst, nachdem der Header mit dem richtigen Passwort entschlüsselt wurde. Eine Containerdatei oder Partition sieht daher wie Zufallsdaten aus. Indikatoren sind:

• eine Shannon-Entropie nahe dem Maximum von 8 bits/byte über das gesamte Objekt hinweg;
• eine Größe, die ein Vielfaches von 512 Byte ist;
• keine erkennbare Dateisignatur, häufig mit einer Erweiterung oder einem Namen, der etwas anderes nahelegt.

Dies sind Indikatoren, keine Beweise: Überschriebener Speicherbereich (Lektion 7.1), zufällige Testdaten und andere Verschlüsselungswerkzeuge sehen genauso aus. Komprimierte Dateien weisen ebenfalls eine hohe Entropie auf, enthalten jedoch Header wie PK oder 7z. Die Systemverschlüsselung ist leichter zu erkennen, da der VeraCrypt-Bootloader den normalen Bootloader ersetzt (auf UEFI-Systemen unter \EFI\VeraCrypt\ auf der EFI-Systempartition).

Ein verstecktes Volume von VeraCrypt liegt im freien Speicherbereich eines äußeren Volumes, der mit Zufallsdaten gefüllt ist. Seine Existenz lässt sich daher anhand des Containers allein weder nachweisen noch ausschließen. Nur andere Artefakte, etwa LNK-Dateien mit Verweisen auf Pfade, die im geöffneten äußeren Volume nicht existieren, können diese Annahme stützen. Treffen Sie ohne solche Belege niemals eine Aussage in die eine oder andere Richtung.

Softwareartefakte

Wenn der Container nicht direkt identifiziert werden kann, lässt sich möglicherweise die Nutzung der Software nachweisen. Suchen Sie nach Prefetch-Dateien zu VERACRYPT.EXE und VERACRYPT FORMAT.EXE, nach Amcache- und BAM-Einträgen (Lektion 2.3) sowie nach dem Treiber %windir%\System32\drivers\veracrypt.sys (im portablen Modus nicht vorhanden). %APPDATA%\VeraCrypt\ enthält Configuration.xml (Einstellungen, einschließlich der Einstellungen zum automatischen Aushängen) und, nur wenn diese Funktionen verwendet wurden, Favorite Volumes.xml (gespeicherte Volumes und ihre Laufwerkbuchstaben) sowie History.xml (die letzten 20 Volume-Pfade; „Verlauf niemals speichern“ ist standardmäßig aktiviert). Eingehängte Volumes können Spuren von Laufwerkbuchstaben hinterlassen: einen Wert \DosDevices\Z: in MountedDevices, dessen Daten keinem bekannten Datenträger entsprechen, sowie LNK-Dateien und Sprunglisten (Lektion 2.4), deren Ziel-Volume-Seriennummer keinem bekannten Volume entspricht.

Schlüsselarchitektur von BitLocker

BitLocker verwendet drei Ebenen. Die Sektoren werden mit dem FVEK (Full Volume Encryption Key, Schlüssel zur vollständigen Volume-Verschlüsselung) verschlüsselt. Der FVEK wird in den Metadaten gespeichert, verschlüsselt mit dem VMK (Volume Master Key, Volume-Hauptschlüssel). Der VMK wird mehrfach gespeichert, jeweils einmal mit jeder Schlüsselschutzvorrichtung verschlüsselt. Das Hinzufügen oder Entfernen einer Schlüsselschutzvorrichtung fügt lediglich eine verschlüsselte Kopie des VMK hinzu oder entfernt sie; die Daten werden nicht erneut verschlüsselt.

Zu den Schlüsselschutzvorrichtungen gehören Nur TPM (das Trusted Platform Module gibt den VMK frei, wenn die gemessene Startkette unverändert ist), TPM + PIN, TPM + Startschlüssel, ein Passwort (typisch für Daten- und Wechseldatenträger), eine Startschlüssel- oder Wiederherstellungsschlüsseldatei (.BEK), das Wiederherstellungskennwort und die automatische Entsperrung (ein Datenlaufwerk wird automatisch geöffnet, sobald das Betriebssystem-Volume entsperrt ist). Jede Schlüsselschutzvorrichtung besitzt eine GUID als Schlüssel-ID; der Wiederherstellungsbildschirm zeigt deren Anfang an, sodass ein aufgefundenes Kennwort dem richtigen Volume zugeordnet werden kann.

Das Wiederherstellungskennwort hat 48 Ziffern in acht Gruppen zu je sechs Ziffern. Jede Gruppe codiert 16 Bit, multipliziert mit 11. Daher ist jede gültige Gruppe durch 11 teilbar und höchstens 65.535 × 11 = 720.885 groß; acht Gruppen ergeben den 128-Bit-Schlüssel. Dies ist eine Formatprüfung, kein Nachweis dafür, dass ein Wert zu einem Volume gehört.

Ein Wiederherstellungskennwort kann rechtmäßig an folgenden Orten gespeichert sein:

• im Microsoft-Konto des Benutzers auf dessen Seite für Wiederherstellungsschlüssel;
• in Active Directory als msFVE-RecoveryInformation-Objekte unter dem Computerobjekt (Attribut msFVE-RecoveryPassword) oder in Entra ID am Geräteobjekt;
• in Verwaltungsdatenbanken von MBAM oder Intune;
• auf einem Ausdruck, in einer Textdatei oder auf einem USB-Laufwerk, vom Benutzer gespeichert.

Viele Windows 11-Geräte aktivieren die Geräteverschlüsselung automatisch und sichern den Schlüssel bei der Anmeldung im Microsoft-Konto oder im Geschäftskonto. Wenn BitLocker ausgesetzt ist, wird der VMK mit einem unverschlüsselten „Klarschlüssel“ gespeichert: Das Volume bleibt verschlüsselt, kann aber mit jedem kompatiblen Werkzeug gelesen werden.

Rechtmäßige Zugriffswege

• Das laufende, entsperrte System. Sichern Sie den Arbeitsspeicher und erstellen Sie anschließend ein logisches Abbild des entsperrten Volumes (ein physisches Abbild kopiert lediglich den Geheimtext). Dokumentieren Sie manage-bde -status und die IDs der Schlüsselschutzvorrichtungen.
• Schlüssel im Arbeitsspeicher. Solange ein Volume entsperrt oder eingehängt ist, befindet sich der FVEK oder der VeraCrypt-Hauptschlüssel im RAM. Werkzeuge zur Arbeitsspeicheranalyse, darunter Community-Plugins für Volatility und kommerzielle Softwarepakete, können diese Schlüssel auffinden. Open-Source-BitLocker-Bibliotheken können anschließend ein Abbild mit dem gewonnenen Schlüssel entschlüsseln. Auch Ruhezustandsdateien und Absturzabbilder können sie enthalten (Lektion 5.4), auf einem verschlüsselten C: jedoch erst, nachdem C: entsperrt wurde.
• Nur TPM auf dem ursprünglichen Rechner. Das Starten des ursprünglichen Computers entsperrt das Volume ohne ein Geheimnis, obwohl die Windows-Anmeldung die Sitzung weiterhin schützt. Ein aus diesem Rechner entnommenes Laufwerk benötigt ein Wiederherstellungskennwort.
• Hinterlegte Schlüssel. Fordern Sie Wiederherstellungskennwörter unter Angabe der Schlüssel-ID im Rahmen des rechtlich vorgesehenen Verfahrens bei der Organisation oder dem Anbieter an.
• Der Eigentümer. Es ist möglich, nach einem Passwort zu fragen; der rechtliche Rahmen unterscheidet sich je nach Land.
• FileVault: ein Benutzerpasswort, der persönliche Wiederherstellungsschlüssel (24 Zeichen in sechs Gruppen zu je vier Zeichen), ein institutioneller Wiederherstellungsschlüssel oder eine MDM-Hinterlegung oder der laufende, entsperrte Mac.
• VeraCrypt und LUKS: das Passwort oder die Schlüsseldatei oder der Schlüssel im Arbeitsspeicher, solange das Volume eingehängt ist; erstellen Sie ein Abbild des zugeordneten Volumes, solange es geöffnet ist.

Zeit ist entscheidend. Ein eingehängtes Volume geht beim Herunterfahren verloren, und VeraCrypt kann so konfiguriert werden, dass es Volumes bei der Abmeldung, beim Sperren der Sitzung, beim Start des Bildschirmschoners, beim Wechsel in den Energiesparmodus oder nach einem Zeitraum ohne Lese- und Schreibzugriffe aushängt. Triage-Entscheidungen (Lektion 5.1) bestimmen häufig, ob verschlüsselte Daten überhaupt jemals gelesen werden können.

Durchgerechnetes Beispiel: ein Laptop im Standby-Modus

Ein Windows 11-Laptop wird im Standby-Modus mit gesperrtem Bildschirm sichergestellt. Die Triage zeigt BitLocker mit einer Nur-TPM-Schlüsselschutzvorrichtung auf C: und auf D: eine Datei D:\backup\photos.bin ohne bekannten Header. Auf dem System befinden sich VeraCrypt-Prefetch-Dateien und eine LNK-Datei, die auf Z:\clients\list.xlsx auf einem Volume verweist, dessen Seriennummer sonst nirgends auftaucht.

Reihenfolge. Schließen Sie das Ladegerät an, fotografieren Sie den Bildschirm und verhindern Sie den Wechsel in den Ruhezustand. Eine Live-Erfassung erfordert eine authentifizierte Sitzung. Beschaffen Sie daher auf rechtmäßigem Weg Anmeldedaten vom Eigentümer oder von der Organisation. Anschließend:

1. Zuerst der Arbeitsspeicher. Er kann den VeraCrypt-Hauptschlüssel und den BitLocker-FVEK enthalten.
2. Danach Z:, falls noch eingehängt. Fotografieren Sie das VeraCrypt-Fenster, das den Pfad der eingehängten Datei und den Volume-Typ anzeigt, und erstellen Sie ein logisches Abbild von Z:. Für diese Daten gibt es keinen anderen Zugriffsweg, und ein Aushängen wegen Inaktivität könnte das Volume schließen, während Sie an C: arbeiten.
3. Zuletzt C:. Dokumentieren Sie manage-bde -status und die IDs der Schlüsselschutzvorrichtungen und erstellen Sie dann ein logisches Abbild von C:. Für C: gibt es Ausweichmöglichkeiten: das TPM auf dem ursprünglichen Rechner und ein gegebenenfalls hinterlegtes Wiederherstellungskennwort.

Die Datei. Ihre Größe beträgt 4.294.967.296 Byte = 4 GiB = 2^32 Byte = 8.388.608 × 512, ein exaktes Vielfaches von 512. Ihre über 1 MiB große Blöcke gemittelte Entropie beträgt 7,9998 bits/byte. Dies entspricht dem Wert, den Zufallsdaten bei dieser Blockgröße ergeben (die Verzerrung bei kleinen Stichproben hält ihn knapp unter 8). Zusammen mit Belegen für die Ausführung von VeraCrypt lautet die korrekte Aussage: photos.bin ist mit einem verschlüsselten Container, etwa einem VeraCrypt-Dateicontainer, vereinbar; dies ist nicht bewiesen. Wenn die Datei später rechtmäßig geöffnet wird und die Volume-Seriennummer ihres Dateisystems mit der in der LNK-Datei übereinstimmt, stellt dies eine Verbindung zu Z: her.

Prüfung des Wiederherstellungskennworts. Ein für diese Lektion erstelltes gültiges Beispiel lautet 403425-176198-692373-264044-664609-429165-106161-702482. Erste Gruppe: 403.425 ÷ 11 = 36.675 ohne Rest (11 × 36.675 = 403.425), und 36.675 liegt unter 65.536. Ein Übertragungsfehler wie 403.426 ergibt den Rest 1 und besteht die Prüfung nicht.

Berichterstattung

Geben Sie an, dass ein Volume verschlüsselt ist und mit welcher Technologie; wie es identifiziert wurde (Signatur und Offset, Metadaten, Entropiemessung und Blockgröße, Softwareartefakte); nach welchen Schlüsseln aus welchen Quellen und mit welchem Ergebnis gesucht wurde, einschließlich der Schlüssel-IDs; was am laufenden System erfasst wurde und wann (UTC); und was nicht untersucht werden konnte. Halten Sie Schlussfolgerungen zur Absicht davon getrennt. ISO/IEC 27037 verlangt, dass jede Maßnahme am laufenden System begründet und dokumentiert wird.

Prüfungsschwerpunkt: Rechnen Sie damit, BitLocker anhand von -FVE-FS- an Offset 3 erkennen, die Ebenen FVEK, VMK und Schlüsselschutzvorrichtungen erläutern und Gruppen von Wiederherstellungskennwörtern auf Teilbarkeit durch 11 prüfen zu müssen. Szenariofragen prüfen voraussichtlich die Erfassungsreihenfolge auf einem laufenden System mit einem eingehängten Container sowie die sorgfältige Formulierung, dass eine Datei mit hoher Entropie ohne Header mit einem verschlüsselten Container vereinbar ist, diesen aber nicht beweist.

Kernpunkte

• BitLocker zeigt -FVE-FS- an Offset 3 und in seinen FVE-Metadatenblöcken; LUKS beginnt mit LUKS\xba\xbe; VeraCrypt besitzt keine Klartextsignatur.
• Hohe Entropie, eine durch 512 teilbare Größe und ein fehlender Header weisen auf einen möglichen Container hin, beweisen ihn aber nicht; versteckte Volumes lassen sich anhand des Containers allein weder nachweisen noch ausschließen.
• Sektoren werden mit dem FVEK verschlüsselt, der FVEK mit dem VMK und der VMK mit jeder Schlüsselschutzvorrichtung.
• Ein Wiederherstellungskennwort besteht aus acht sechsstelligen Gruppen, die jeweils durch 11 teilbar sind; ordnen Sie es anhand der Schlüssel-ID zu.
• Sichern Sie den Arbeitsspeicher und erstellen Sie logische Abbilder, solange Volumes entsperrt sind. Priorisieren Sie dabei das, wofür keine andere Schlüsselquelle verfügbar ist.
• Dokumentieren Sie die Verschlüsselung, ihre Identifizierung, die geprüften Schlüsselquellen und die nicht untersuchten Inhalte.