Welche Software brauche ich für verschlüsselte Datenträger mit TPM?

systemd enthält seit Version 248 das Werkzeug „systemd-cryptenroll“ (in Debian verfügbar ab Version 12) für den Einsatz von TPM mit der Datenträger-Verschlüsselung LUKS Version 2 (im Folgenden kurz „LUKS“). Alternativ kann „Clevis“ nebst anderem ein TPM als Schlüsselspeicher für LUKS-Datenträger verwenden.

Mit diesen Werkzeugen kann ein unbeaufsichtigter Systemstart von einem LUKS-Datenträger realisiert werden. Ein solcher Datenträger lässt sich nur dann entschlüsseln, wenn er Zugriff auf das TPM hat, mit dem er verschlüsselt wurde (was natürlich Vor- und Nachteile hat), oder wenn ein alternativer LUKS-Slot zur Verfügung steht, der nicht vom TPM abhängig ist.

Obwohl Clevis prinzipiell gut funktioniert, ist das automatische Entsperren beim Systemstart nicht sonderlich zuverlässig; für manche Linux-Distributionen fehlt eine fertige Integration mit den vorhandenen Systemen für initiale RAM-Dateisysteme („initramfs“). Andererseits unterstützt „systemd-cryptenroll“ auf Debian 12 zwar das automatische Entsperren von zusätzlichen Datenträgern, nicht aber der Root-Partition, dies wiederum funktioniert auf Debian 12 mit den Paketen clevis-tpm2 und clevis-initramfs. Im Folgenden werden beide Verfahren gezeigt.

Es gibt fortgeschrittene - in diesem Artikel nicht behandelte - Szenarien, die nur „Clevis“ umsetzen kann, zum Beispiel wenn der Netzwerk-Sicherheitsdienst „Tang“ zum Einsatz kommt, oder wenn verschiedene Entsperr-Faktoren nach dem Algorithmus „Shamir Secret-Sharing“, „SSS“ zusammengefasst werden sollen.

Im Folgenden wird auch die Autorisierung von TPM, genauer gesagt das Sealing demonstriert: Es wird ein verschlüsselter Datenträger eingerichtet, der sich nicht mehr entschlüsseln lässt, wenn das System ohne SecureBoot gestartet wurde.

Für die folgenden Beispiele wurden auf Debian 12 diese Pakete installiert:

apt install clevis-luks clevis-tpm2 cryptsetup-bin mokutil

LUKS-Device mit Clevis und TPM entsperren

Das folgende Beispiel demonstriert den Einsatz der Software „Clevis“ als Entsperr-Mechanismus für ein Block-Device, das mit LUKS2 verschlüsselt wurde. Dabei wird gleichzeitig das „Sealing“ des mit TPM verschlüsselten LUKS-Schlüssels anhand eines Platform Configuration Registers (PCR) demonstriert, in diesem Fall PCR 7, das die Information enthält, ob UEFI SecureBoot derzeit aktiviert ist.

Mit „mokutil“ wird der aktuelle Status von UEFI SecureBoot ermittelt:

mokutil --sb-state

Die Ausgabe sollte lauten:

SecureBoot enabled

Achtung: Der LUKS-Schlüssel soll durch „Sealing“ mit dem aktuellen Wert des PCR 7 verknüpft werden. Um sicherzustellen, dass der LUKS-Schlüssel nur dann verfügbar ist, wenn SecureBoot aktiviert ist, muss es während der folgenden Prozedur aktiviert sein.

Als zu verschlüsselnder Datenträger wird ein Disk-Image verwendet; das folgende Kommando erzeugt ein mit Nullbytes beschriebenes, 1 Gigabyte großes Image test.img:

dd bs=1M count=1024 if=/dev/zero of=test.img

Auf dem Image wird LUKS-Verschlüsselung eingerichtet; dabei ist eine Passphrase zu setzen (zum Beispiel 1111):

cryptsetup luksFormat --type luks2 test.img

Das LUKS-Device wird geöffnet und das entschlüsselte Block-Device wird mit einem EXT4-Dateisystem ausgestattet:

cryptsetup open test.img test
mkfs.ext4 /dev/mapper/test
cryptsetup close test

Als nächstes muss die Belegung der PCR-Bänke auf dem TPM ermittelt werden. PCR-Werte sind mit einem Hash-Algorithmus verschlüsselt, der Standard sieht dabei vor, dass SHA-1, -256, -384 oder -512 zum Einsatz kommen können, gibt aber nicht vor, welchen der Algorithmen ein TPM konkret implementieren soll. Das folgende Kommando prüft deshalb, welche PCR-Bänke auf diesem System überhaupt bereitstehen:

tpm2_getcap pcrs

Die Ausgabe könnte wie folgt aussehen:

selected-pcrs:
   - sha1: [ ]
   - sha256: [ 0, 1, 2, 3, ..., 23 ]
   - sha384: [ ]
   - sha512: [ ]

Auf diesem System soll also der Zugriff auf PCR-Werte als SHA-256-Hashes erfolgen. Das folgende Kommando listet den Inhalt der SHA-256-Bank auf:

tpm2_pcrread sha256

Die Ausgabe könnte zum Beispiel so aussehen:

sha256:
   0 : 0xE21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93
   1 : 0x2BE879AA8EB9654D0515E644C2A7564D3127E51F358C54132C3240DF2B5EE8A4
   2 : 0xEF4823CE6CE1C1C8766BCDF3D836C574E7B66ECC727FE994C2C76C05EDF66682
...
   23: 0x0000000000000000000000000000000000000000000000000000000000000000

Um nur PCR 7 auszugeben, wird folgendes Kommando ausgeführt:

tpm2_pcrread sha256:7

Die Ausgabe sollte etwa so aussehen:

sha256:
   7 : 0xE21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93

Das folgende Kommando bestückt den nächsten freien LUKS-Slot mit einem neu generierten Schlüssel. Die Passphrase für den Schlüssel wird vom TPM nur preisgegeben, wenn sich der Wert von PCR 7 aus der SHA-256-Bank seit der Einrichtung nicht geändert hat:

clevis luks bind \
   -d test.img \
   tpm2 \
   '{ "pcr_bank":"sha256", "pcr_ids":"7"}'

Dieses Kommando fragt nach der Passphrase eines existierenden LUKS-Schlüssels, wie sie zuvor mit cryptsetup luksFormat ... festgelegt wurde (zum Beispiel 1111).

Wenn dieses Kommando erfolgreich ausgeführt wurde, kann ab da das Image test.img mit folgendem Kommando entsperrt werden, solange sich PCR 7 nicht ändert:

clevis luks unlock -d test.img

LUKS-Device mit Clevis-TPM-Zuordnung automatisch entsperren

Das folgende Beispiel zeigt, wie der Kryptocontainer in test.img während der „Late-Boot-Phase“ des initramfs mit Clevis und TPM automatisch entsperrt werden kann.

Es wird folgende zusätzliche Software installiert:

apt install clevis-initramfs

Der Startvorgang wird versuchen, jeden Kryptocontainer zu entsperren, der in der Datei /etc/crypttab aufgeführt ist. Das folgende Kommando ergänzt diese Datei um einen passenden Eintrag für das Test-Image (Achtung: Hier muss der absolute Dateiname des Images verwendet werden):

echo "test /root/test.img none" >> /etc/crypttab

Danach wird der Dienst aktiviert, der die LUKS-Passwortabfrage automatisieren wird:

systemctl enable clevis-luks-askpass.path

Zuletzt wird das initiale RAM-Dateisystem aktualisiert:

update-initrams -u -k all

Nach einem Reboot sollte test.img automatisch während der „Late-Boot-Phase“ des Startvorgangs entsperrt werden. Mit cryptsetup kann das anschließend geprüft werden:

cryptsetup status test

Die Ausgabe sollte wie folgt beginnen:

/dev/mapper/test is active and is in use.
   type: LUKS2
...

LUKS-Device mit systemd-cryptenroll und TPM entsperren

Das folgende Beispiel zeigt die Einrichtung desselben Disk-Images, das schon im letzten Beispiel verwendet wurde, wobei diesmal das automatische Entsperren mit „cryptsetup“, „systemd-cryptenroll“ und den Konfigurationsdateien /etc/crypttab und /etc/fstab so eingerichtet wird, das nach dem Systemstart das entsperrte EXT4-Dateisystem an einem Mountpoint eingehängt zur Verfügung steht.

Als erstes wird das LUKS-Device aus der vorangegangenen Übung wieder geschlossen, da als nächstes Änderungen an den LUKS-Schlüsseln vorgenommen werden sollen:

cryptsetup close test

Mit folgendem Aufruf wird die aktuelle Belegung der LUKS-Slots geprüft:

systemd-cryptenroll /root/test.img

Die Ausgabe sollte wie folgt lauten:

SLOT TYPE
   0 password
   1 other

In LUKS-Slot Nummer 0 ist also ein Passwort hinterlegt (zum Beispiel 1111), und Clevis hat im vorangegangenen Beispiel den Slot Nummer 1 belegt.

Mit folgendem Kommando werden Slot 1 und damit der LUKS-Schlüssel aus der letzten Übung mit Clevis verworfen (Achtung: Hier lohnt es sich, vorsichtig zu sein, und die Eingaben vor dem Absenden des Befehls genau zu prüfen - Löschen des falschen Slots kann dazu führen, dass die Daten nicht mehr entschlüsselt werden können):

systemd-cryptenroll \
   --wipe-slot 1 \
   test.img

Das folgende Kommando richtet einen neuen LUKS-Schlüssel im nächsten freien Slot an; dabei wird wie im vorangegangenen Beispiel ein „Sealing“ des Schlüssels an PCR 7 (SHA-256-Hash des derzeitigen Status von SecureBoot) eingerichtet:

systemd-cryptenroll \
   --tpm2-device /dev/tpmrm0 \
   --tpm2-pcrs 7 \
   test.img

Falls nicht schon geschehen, wird der Kryptocontainer in der Datei /etc/crypttab eingetragen:

echo "test /root/test.img none" >> /etc/crypttab

Um das vom Device-Mapper bereitgestellte Dateisystem automatisch am Mountpoint /mnt/test bereitzustellen, soll ein entsprechender Eintrag in /etc/fstab hinzugefügt werden. Um unabhängig von der Bezeichnung test zu sein, kann dabei auch die UUID des geöffneten Kryptocontainer verwendet werden.

Das folgende Kommando entsperrt das verschlüsselte Dateisystem auf test.img und stellt es als Device /dev/mapper/test bereit:

cryptsetup open test.img test

Das folgende Kommando ermittelt die UUID des entsperrten Dateisystems und speichert sie in der Variablen „uuid“ ab:

uuid=$(lsblk -o UUID /dev/mapper/test -n)

Schließlich wird ein Eintrag für das EXT4-Dateisystem der Datei /etc/fstab hinzugefügt:

echo "UUID=$uuid /mnt/test ext4 defaults 0 0" >> /etc/fstab

Nun kann das System neu gestartet werden. Nach dem Reboot sollte der Kryptocontainer automatisch entsperrt und das Dateisystem an /mnt/test eingehängt sein:

df -h /mnt/test

Die Ausgabe sollte etwa so aussehen:

Filesystem               Size     Used    Avail   Use%     Mounted on
/dev/mapper/test         974M     24K     908M    1%       /mnt/test

Wenn im UEFI-Setup der Status von SecureBoot geändert wird, dann wird das automatische Entsperren nicht funktionieren; beim Systemstart wird stattdessen nach einer Passphrase gefragt.

Zusammenfassung und Fazit

TPMs haben einige grundsätzliche Probleme, die auch die besten Bibliotheken und Werkzeuge nicht beheben können. Vielleicht das gravierendste ist der „Blackbox-Charakter“: Zuweilen treten im TPM selbst Sicherheitslücken auf, die - geschickt und an der richtigen Stelle ausgenutzt - die Integrität des Systems gefährden können. Die Hersteller der TPMs und der von ihnen abgesicherten „Plattformen“ gehen nicht immer angemessen mit solchen Zwischenfällen um.

Trotzdem können TPMs als Hardware-basierte Sicherheitsmodule die Möglichkeiten der IT-Sicherheit bereichern und einige Szenarien möglich machen, die vorher nur schwer durch- oder umzusetzen waren. Als Beispiel sei hier das im Vergleich zu einer dateibasierten Speicherung deutlich erhöhte Schutzniveau privater kryptografischer Schlüssel genannt.

Ist das TPM die perfekte Lösung für alle Aufgaben des Speicherns von Schlüsseln und Zertifikaten? Das wohl eher nicht: Die starke Bindung an das TPM kann in vielen Situationen ein unverhältnismäßiger Nachteil gegenüber anderen Lösungen sein. Bestimmte Schlüssel sind nur auf exakt den Computern verfügbar, auf denen sie generiert wurden, Backups von Disk-Images sind nutzlos, und Transfers von Images auf andere Computer funktionieren nicht, es sei denn, es wurden „Fallback-Schlüssel“ für den Not- oder Bedarfsfall eingerichtet – wobei sich dann die Frage stellt, wo solche „Hintertür-Schlüssel“ gespeichert werden und wer sie verwalten soll.

Mit dem gezeigten Einsatz von „Sealing“ können Datenträger nur noch durch den Computer entschlüsselt werden, auf dem sie verschlüsselt wurden. Wenn dabei ausschließlich der Schlüssel in TPM (und kein weiterer Faktor) genutzt wird, kann das im regulären Betrieb automatisch und somit sehr komfortabel geschehen. Ein Angreifer, der den gesamten Computer (zum Beispiel einen Laptop) entwendet, kann diese Daten dann aber unter Umständen genauso einfach entschlüsseln wie reguläre Benutzer des Systems; er muss den Computer dafür lediglich einschalten.

Kann TPM mit Linux benutzt werden? Aus den gezeigten Beispielen geht hervor, dass mit aktuellen Versionen der benötigten Software-Pakete, mit etwas Übung und sorgfältig angepassten Konfigurationen und Prozeduren durchaus nützliche Funktionen für die Verwaltung kryptografischer Schlüssel umgesetzt werden können. Eine der größten Schwierigkeiten beim Umgang mit TPM auf Linux ist die uneinheitliche und stellenweise mangelhafte Dokumentation; hier muss Frustrationstoleranz mitgebracht werden.