Der LUKS-Header ist eine kritische Komponente jedes mit LUKS verschlüsselten Linux-Systems, da er alle Metadaten enthält, die zur Entschlüsselung der Daten erforderlich sind. Eine Beschädigung oder ein Verlust dieses Headers führt in der Regel zu einem vollständigen Ausfall des Systems beziehungsweise zum Verlust des Zugriffs auf die verschlüsselten Inhalte, selbst wenn die Daten physisch intakt sind. In diesem Artikel wird der Zweck, die Bedeutung und die praktische Handhabung von LUKS-Header-Backups beschrieben. Darüber hinaus wird das kontrollierte Wiederherstellen eines Headers in einem typischen Szenario erläutert, insbesondere im Kontext verschlüsselter Systempartitionen. Ziel ist es, ein Vorgehen zu dokumentieren, das sich sowohl für Testumgebungen als auch für den Ernstfall eignet und sich leicht nachvollziehen lässt.
Feststellen des Verschlüsselungszustands und Identifikation der Root-Partition
Bevor ein LUKS-Header gesichert oder wiederhergestellt werden kann, muss zunächst eindeutig festgestellt werden, welche Systempartition verschlüsselt ist und welches Blockdevice dieser Verschlüsselung zugrunde liegt. Dieser Schritt sollte auch bei bekannten oder frisch installierten Systemen nicht übersprungen werden, da spätere Wiederherstellungsmaßnahmen exakt auf das korrekte Device abzielen müssen. In diesem Abschnitt wird der aktuelle Zustand des Systems nachvollziehbar dokumentiert und die verschlüsselte Root-Partition eindeutig identifiziert.
Zur Identifikation des Root-Dateisystems und der darunterliegenden Blockgeräte wird zunächst die aktuelle Mount-Struktur analysiert:
$ lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME TYPE FSTYPE SIZE MOUNTPOIN
sda disk 20G
├─sda1 part vfat 953M /boot/efi
├─sda2 part ext4 1,8G /boot
└─sda3 part crypto_LUKS 17,3G
└─dm_crypt-0 crypt LVM2_member 17,3G
└─ubuntu--vg-ubuntu--lv lvm ext4 10G /
sr0 rom 1024MIn der vorliegenden Konfiguration zeigt die Ausgabe eine klassische Trennung von unverschlüsseltem Boot-Bereich und verschlüsseltem Systembereich. Die Partition sda1 enthält die EFI-Systempartition, sda2 das unverschlüsselte /boot. Die eigentliche Systempartition ist sda3, die als crypto_LUKS gekennzeichnet ist. Innerhalb dieses LUKS-Containers befindet sich ein LVM-Physical-Volume, aus dem wiederum das logische Volume für das Root-Dateisystem bereitgestellt wird.
Zur Bestätigung, welches Device aktuell als Root-Dateisystem gemountet ist, wird der Mountpunkt / explizit abgefragt:
$ findmnt /
TARGET
SOURCE FSTYPE OPTIONS
/ /dev/mapper/ubuntu--vg-ubuntu--lv ext4 rw,relatimeAus dieser Gerätehierarchie ergibt sich, dass sich der relevante LUKS-Header auf der Partition /dev/sda3 befindet. Alle Maßnahmen zur Sicherung oder Wiederherstellung des LUKS-Headers betreffen ausschließlich die Verschlüsselungsschicht auf Blockdevice-Ebene; das darauf aufbauende Root-Dateisystem ist davon logisch getrennt.
Sicherung des LUKS-Headers und Verifikation des Backups
Der LUKS-Header enthält sämtliche Metadaten, die für den Zugriff auf einen verschlüsselten Datenträger erforderlich sind. Dazu zählen unter anderem die verwendeten kryptografischen Parameter, die Keyslots sowie die eindeutige LUKS-UUID. Ein Verlust oder eine Beschädigung dieses Headers macht ein verschlüsseltes Volume in der Praxis unbrauchbar, selbst wenn alle Nutzdaten physisch noch vorhanden sind. Aus diesem Grund sollte vor jeglichen experimentellen oder administrativen Eingriffen ein vollständiges Header-Backup erstellt werden.
Das Backup des LUKS-Headers erfolgt mit cryptsetup direkt auf Blockdevice-Ebene. In der vorliegenden Konfiguration befindet sich der relevante Header auf der Partition /dev/sda3. Das Backup wird als eigenständige Datei abgelegt:
$ sudo cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file /root/luks-header.backupDieser Befehl liest den vollständigen LUKS-Header aus der Partition und speichert ihn in der Datei luks-header.backup. Die Größe dieser Datei ist vergleichsweise gering, da sie ausschließlich Metadaten enthält und keine Nutzdaten des verschlüsselten Volumes.
Nach dem Erstellen des Backups sollte dessen Inhalt unmittelbar verifiziert werden. Dabei geht es nicht um eine kryptografische Prüfung im engeren Sinne, sondern um die Bestätigung, dass das Backup konsistent ist und die erwarteten Metadaten enthält. Dazu kann der Header aus der Backup-Datei ausgelesen werden:
$ sudo cryptsetup luksDump /dev/sda3 --header-backup-file /root/luks-header.backup
LUKS header information
Version: 2
Epoch: 4
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: c418a47e-a90a-4f44-9b57-d2653a67ec19
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
---snip---Die Ausgabe zeigt unter anderem die LUKS-Version, die verwendeten Verschlüsselungsparameter sowie die LUKS-UUID des Containers. Diese UUID ist eine zentrale Identifikationsgröße und sollte dokumentiert werden, da sie später zur Plausibilitätsprüfung einer Wiederherstellung herangezogen werden kann.
Damit ist das Header-Backup erfolgreich erstellt und verifiziert. Es stellt den Referenzzustand dar, auf den im weiteren Verlauf gezielt zurückgegriffen wird, um einen beschädigten oder verlorenen LUKS-Header kontrolliert wiederherzustellen.
Gezielte Beschädigung des LUKS-Headers
Um das Verfahren zur Wiederherstellung eines LUKS-Headers nachvollziehbar darzustellen, wird im nächsten Schritt ein definierter Fehlerzustand erzeugt. Dazu wird der LUKS-Header der verschlüsselten Systempartition gezielt beschädigt. Die verschlüsselten Nutzdaten selbst bleiben dabei unverändert. Hierbei ist bekannt, auf welcher Partition sich der LUKS-Container befindet; in der hier betrachteten Testumgebung liegt dieser auf /dev/sda3.
Die folgenden Arbeiten werden aus einem Linux-Live-System heraus durchgeführt. Die betroffene Partition ist zu diesem Zeitpunkt weder entschlüsselt noch gemountet. Das zuvor erstellte LUKS-Header-Backup liegt extern vor und ist vom Zustand der Systemplatte unabhängig verfügbar.
Zunächst wird überprüft, dass das Ziel-Blockdevice vorhanden ist:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 156.1M 1 loop /rofs
loop1 7:1 0 138.1M 1 loop
loop2 7:2 0 661.9M 1 loop
loop3 7:3 0 254.6M 1 loop
loop4 7:4 0 156.1M 1 loop /media/minimal
loop5 7:5 0 138.1M 1 loop /media/full
loop6 7:6 0 49.3M 1 loop /snap/snapd/24792
loop7 7:7 0 73.9M 1 loop /snap/core22/2045
loop8 7:8 0 20.3M 1 loop /snap/subiquity/6806
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 953M 0 part
├─sda2 8:2 0 1.8G 0 part
└─sda3 8:3 0 17.3G 0 part
sr0 11:0 1 3.1G 0 rom /cdromDie Ausgabe zeigt die vorhandenen Blockdevices und bestätigt das Vorhandensein der Festplatte /dev/sda und der Partition /dev/sda3.
Anschließend werden ein paar Byte des Metadatenbereichs am Anfang der Partition gezielt überschrieben:
$ sudo dd if=/dev/zero of=/dev/sda3 bs=1M count=3
3+0 records in
3+0 records out
3145728 bytes (3.1 MB, 3.0 MiB) copied, 0.00462745 s, 680 MB/sNach Ausführung des Befehls ist der LUKS-Header nicht mehr konsistent. Eine Erkennung oder Öffnung des Containers ist nicht mehr möglich. Das System wird anschließend neu gestartet, um das resultierende Bootverhalten zu analysieren.
Das System versucht wiederholt, den verschlüsselten Datenträger anhand der konfigurierten UUID zu finden und zu öffnen. Da die für die Erkennung des LUKS-Containers erforderlichen Metadaten fehlen, ist dies nicht möglich. Eine Passphrase-Abfrage erfolgt nicht. Nach Ablauf der vorgesehenen Wartezeit wird das Root-Dateisystem als nicht verfügbar erkannt, und der Bootvorgang bricht ab.
Infolge dessen wird das erwartete logische Volume für das Root-Dateisystem nicht bereitgestellt. Das System wechselt in eine BusyBox-Shell innerhalb der initramfs-Umgebung. Ein Zugriff auf das installierte System ist in diesem Zustand nicht möglich.
Dieses Verhalten entspricht dem erwarteten Fehlerbild bei einem System mit unverschlüsseltem /boot und beschädigtem LUKS-Header der Root-Partition.
Vorbereitung der Wiederherstellung
Nach dem fehlgeschlagenen Bootvorgang wird das System erneut über ein Linux-Live-System gestartet. Das zuvor erstellte LUKS-Header-Backup wird in die Live-Umgebung übertragen und lokal verfügbar gemacht. Nach dem Start des Live-Systems wird überprüft, dass die Zielpartition vorhanden ist:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 156.1M 1 loop /rofs
loop1 7:1 0 138.1M 1 loop
loop2 7:2 0 661.9M 1 loop
loop3 7:3 0 254.6M 1 loop
loop4 7:4 0 156.1M 1 loop /media/minimal
loop5 7:5 0 138.1M 1 loop /media/full
loop6 7:6 0 73.9M 1 loop /snap/core22/2045
loop7 7:7 0 49.3M 1 loop /snap/snapd/24792
loop8 7:8 0 20.3M 1 loop /snap/subiquity/6806
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 953M 0 part
├─sda2 8:2 0 1.8G 0 part
└─sda3 8:3 0 17.3G 0 part
sr0 11:0 1 3.1G 0 rom /cdromDie Partition /dev/sda3 ist weiterhin vorhanden, enthält jedoch keine erkennbaren LUKS-Metadaten mehr. Der Container kann zu diesem Zeitpunkt weder identifiziert noch geöffnet werden.
Zusätzlich wird die Verfügbarkeit des Header-Backups geprüft:
$ ls -l /tmp/
total 16384
-rw------- 1 ubuntu-server ubuntu-server 16777216 Jan 31 17:50 luks-header.backup
Das LUKS-Header-Backup ist eine sicherheitskritische Datei. Im vorliegenden Testaufbau liegt es temporär im Besitz eines unprivilegierten Benutzers innerhalb eines Live-Systems. Dieser Umstand ist für den beschriebenen Wiederherstellungsvorgang unerheblich, da die Datei ausschließlich kurzfristig verwendet wird und nach Beenden des Live-Systems ohnehin verworfen wird. In produktiven Umgebungen sind LUKS-Header-Backups dauerhaft restriktiv zu schützen.
Verifikation des LUKS-Header-Backups
Vor der Wiederherstellung wird das LUKS-Header-Backup auf Konsistenz und Gültigkeit geprüft. Ziel dieses Schrittes ist es sicherzustellen, dass die Backup-Datei einen vollständig lesbaren LUKS-Header enthält und nicht beschädigt ist.
Da es sich bei dem Header-Backup um eine reguläre Datei handelt, kann sie nicht direkt als Blockdevice verwendet werden. Werkzeuge wie cryptsetup luksDump erwarten jedoch ein Blockdevice als Eingabe. Zur Überbrückung dieser Abstraktion wird die Backup-Datei daher temporär als Loopback-Device eingebunden:
$ sudo losetup --find --show /tmp/luks-header.backup
/dev/loop9Der Befehl erzeugt ein Loopback-Device und gibt dessen Gerätenamen aus.
Die im Backup enthaltenen Metadaten werden anschließend ausgelesen:
$ sudo cryptsetup luksDump /dev/loop9
LUKS header information
Version: 2
Epoch: 4
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: c418a47e-a90a-4f44-9b57-d2653a67ec19
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
---snip---Eine erfolgreiche Ausgabe bestätigt, dass das Backup als valider LUKS-Header interpretiert werden kann und die enthaltenen Metadaten konsistent vorliegen. Zudem ist ersichtlich, dass die im Header-Backup enthaltene LUKS-UUID mit der im zuvor beobachteten Bootfehler referenzierten UUID übereinstimmt.
Nach Abschluss der Prüfung wird das Loopback-Device wieder entfernt:
$ sudo losetup -d /dev/loop9Hinweis zur Identifikation der Zielpartition
Die Wiederherstellung eines LUKS-Headers erfordert die eindeutige Identifikation der betroffenen Partition. Das Restore-Verfahren überschreibt Metadaten auf Blockebene und ist nicht selbstvalidierend. Eine fehlerhafte Zuordnung führt unmittelbar zu Datenverlust.
In der hier beschriebenen Testumgebung ist bekannt, dass sich der beschädigte LUKS-Container auf der Partition /dev/sda3 befindet. Diese Information stammt aus der vorherigen Dokumentation des Systems und dem zugehörigen Header-Backup.
In Szenarien, in denen keine vollständige Kenntnis des ursprünglichen Partitionsschemas vorliegt, etwa im Rahmen einer forensischen Analyse oder eines Wiederherstellungsauftrags durch Dritte, ist besondere Sorgfalt erforderlich. Nach Zerstörung des LUKS-Headers kann der Container nicht mehr anhand von On-Disk-Metadaten identifiziert werden. Die Zuordnung zu einer Partition ist dann ausschließlich über externe Informationen möglich, beispielsweise durch vorhandene Header-Backups, frühere Systemdokumentation oder konsistente Kontextinformationen.
$ sudo parted /dev/sda unit MiB print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sda: 20480MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1.00MiB 954MiB 953MiB fat32 boot, esp
2 954MiB 2746MiB 1792MiB ext4
3 2746MiB 20479MiB 17733MiBDie Partition /dev/sda1 ist als fat32 formatiert und mit den Flags boot und esp versehen. Dies ist konsistent mit einer EFI-Systempartition und schließt sie als Ziel für einen LUKS-Container aus.
Die Partition /dev/sda2 ist als ext4 formatiert und weist eine Größe auf, die typisch für eine unverschlüsselte /boot-Partition ist. Auch diese Partition kommt daher nicht als Ziel für die Wiederherstellung eines LUKS-Headers in Betracht.
Die Partition /dev/sda3 weist keine Angabe eines Dateisystems auf. In Kombination mit ihrer Größe und Position im Partitionslayout ist sie die einzige Partition, die technisch als LUKS-Container in Frage kommt. Diese Einordnung wird durch die im Header-Backup enthaltenen Angaben zum Metadaten- und Datenbereich zusätzlich gestützt.
In komplexeren Systemen, etwa bei mehreren großen Datenpartitionen, verschachtelten Storage-Layouts oder nicht standardisierten Installationsschemata, kann eine weitergehende Analyse erforderlich sein. Solche Szenarien sind nicht Bestandteil dieser Dokumentation.
Wiederherstellung des LUKS-Headers
Nach Abschluss der Vorbereitungen wird der LUKS-Header aus dem verifizierten Backup auf die zuvor bestimmte Zielpartition zurückgeschrieben. Dieser Vorgang stellt die für die Erkennung und Öffnung des LUKS-Containers erforderlichen Metadaten wieder her:
$ sudo cryptsetup luksHeaderRestore /dev/sda3 --header-backup-file /tmp/luks-header.backup
WARNING!
========
Device /dev/sda3 does not contain LUKS2 header. Replacing header can destroy data on that device.
Are you sure? (Type 'yes' in capital letters): YESNach erfolgreicher Ausführung ist der LUKS-Header wieder auf dem Datenträger vorhanden. Die Partition kann erneut als LUKS-Container erkannt werden.
Verifikation der Wiederherstellung
Nach dem Zurückschreiben des LUKS-Headers wird überprüft, ob die Partition wieder als LUKS-Container erkannt wird und die Metadaten konsistent vorliegen.
Zunächst wird der Header ausgelesen:
$ sudo cryptsetup luksDump /dev/sda3
LUKS header information
Version: 2
Epoch: 4
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: c418a47e-a90a-4f44-9b57-d2653a67ec19
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
---snip---Eine erfolgreiche Ausgabe bestätigt, dass auf der Partition wieder ein LUKS-Header vorhanden ist und interpretiert werden kann. Insbesondere wird die im Header enthaltene UUID angezeigt, die mit der zuvor dokumentierten UUID übereinstimmen muss.
Anschließend wird geprüft, ob der Container geöffnet werden kann:
$ sudo cryptsetup luksOpen /dev/sda3 cryptroot
Enter passphrase for /dev/sda3:
Warning: keyslot operation could fail as it requires more than available memory.Diese Speicherwarnung bezieht sich auf die bei LUKS2 verwendete speicherintensive Schlüsselableitung (PBKDF, z. B. Argon2). Sie weist darauf hin, dass bei begrenzten Arbeitsspeicher des Live-Systems die Wiederherstellung fehlschlagen kann.
Die Ausgabe von lsblk zeigt ein neues Device-Mapper-Mapping unterhalb der Zielpartition:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 156.1M 1 loop /rofs
loop1 7:1 0 138.1M 1 loop
loop2 7:2 0 661.9M 1 loop
loop3 7:3 0 254.6M 1 loop
loop4 7:4 0 156.1M 1 loop /media/minimal
loop5 7:5 0 138.1M 1 loop /media/full
loop6 7:6 0 73.9M 1 loop /snap/core22/2045
loop7 7:7 0 49.3M 1 loop /snap/snapd/24792
loop8 7:8 0 20.3M 1 loop /snap/subiquity/6806
loop10 7:10 0 16M 0 loop
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 953M 0 part
├─sda2 8:2 0 1.8G 0 part
└─sda3 8:3 0 17.3G 0 part
└─cryptroot 252:0 0 17.3G 0 crypt
└─ubuntu--vg-ubuntu--lv 252:1 0 10G 0 lvm
sr0 11:0 1 3.1G 0 rom /cdrom/dev/mapper/cryptrootals entschlüsseltes Blockdevice- darunter das logische Volume
/dev/mapper/ubuntu--vg-ubuntu--lv
Damit ist bestätigt, dass:
- der LUKS-Header konsistent ist,
- die Passphrase akzeptiert wird,
- und die im Container enthaltenen LVM-Metadaten korrekt gelesen werden können.
Die Entschlüsselung des Containers ist damit erfolgreich abgeschlossen.
Systemstart nach erfolgreicher Wiederherstellung
Nach dem Neustart des Systems erfolgt der Bootvorgang ohne Abweichungen vom Normalzustand. Die Passphrase-Abfrage für die verschlüsselte Root-Partition erscheint wie vorgesehen. Nach Eingabe der korrekten Passphrase wird das Root-Dateisystem erfolgreich eingebunden und das System startet vollständig bis zum Login-Prompt.
Happy computing!
