LUKS (dm-crypt) ist die Standardverschlüsselungsmethode. Dank systemd ist es seit Kurzem ein vollständig mit LUKS verschlüsseltes Linux-Betriebssystem mittels FIDO2 oder TPM zu entsperren. Das kann in Kombination mit anderen Schutzmechanismen Sinn ergeben.
TPM und ein modernes Sicherheitskonzept
Die Sicherheit von Linux (Sicherheit im Sinne des Schutzes der Daten vor unbefugte Einsichtnahme) ist ziemlich einfach aufgestellt. Mach eine Vollverschlüsselung und entsperre beim Hochfahren den Container und gut ist. Was mit den Daten im Standby oder bei der Benutzerabmeldung passiert, ist damit ebenso wenig klar wie Themen wie eine vollständige verifizierte Bootkette. Linux hinkt hier hinter Systemen wie Android oder Windows 11 hinterher.
Das Thema ist aber inzwischen auf der Agenda und ein wichtiger Baustein hier ist das Trusted Platform Module (TPM). Natürlich gehört dazu viel mehr, als hier jetzt aufgezeigt werden kann, aber man profitiert bereits von wichtigen Vorarbeiten wie systemd-cryptenroll.
Eine automatische Entsperrung des LUKS-Systemcontainers mittels TPM macht natürlich keinen Sinn, wenn es der einzige Schutzmechanismus ist. Ein Angreifer benötigt dann nur das Gerät, um an alle Daten zu kommen. Wenn man aber z. B. seine Benutzerdaten mittels systemd-homed verschlüsselt hat und diese bereits geschützt sind, geht es um andere Angriffsszenarien. Zum Beispiel ein sogenannter „Evil Maid“-Angriff, bei dem das Speichermedium entwendet oder ein Systemabbild erstellt wurde. Angriffe auf ein verschlüsseltes System lassen sich schließlich viel leichter mit einem solchen Abbild durchführen.
Hier kommt TPM ins Spiel, denn während die Vollverschlüsselung im Normalbetrieb nicht weiter auffällt, scheitert der Startvorgang, sobald das Speichermedium in einer anderen Hardware steckt oder – und das ist der zweite relevante Punkte – sofern jemand am Secure Boot zugange war. Was natürlich voraussetzt, dass Secure Boot aktiviert ist. Das ist leider dank einer verbreiteten Unart bei Linux oft nicht der Fall, obwohl alle ernst zunehmenden Linux-Distributionen Secure Boot unterstützen.
LUKS mit TPM entsperren am Beispiel von openSUSE
LUKS mit TPM zu entsperren ist gegenwärtig noch experimentell und sollte nur von Personen mit tiefer gehenden Linux-Kenntnissen umgesetzt werden.
Die folgende Anleitung basiert auf openSUSE Tumbleweed, weil die SUSE-Entwickler hier bereits erste relevante Vorarbeiten geleistet haben. Sie lässt sich mit Sicherheit auch auf andere moderne Linux-Distributionen übertragen.
Das relevante Werkzeug systemd-cryptenroll kann nur mit LUKS2-Containern umgehen. OpenSUSE legt bei der Installation aber immer noch einen LUKS1-Container an. Deshalb muss in einem ersten Schritt dieser LUKS konvertiert werden. Das ist einfach und klappt zuverlässig. Einfach mit einem Live-Medium starten und mit folgendem Befehl den LUKS-Container konvertieren:
# cryptsetup convert /dev/<laufwerk> --type luks2 Code-Sprache: HTML, XML (xml)Konzeptionell bedingt funktioniert die Methode aktuell nur, wenn eine unverschlüsselte Boot-Partition zum Einsatz kommt. Das war bis vor Kurzem noch völliger Standard, inzwischen kann man aber LUKS-Container auch in GRUB entschlüsseln. Wegen der erheblichen Verzögerung nutze ich das jedoch nicht, weshalb das für mich keine Einschränkung ist.
Mein Partitionsszenario sieht wie folgt aus:
:~> sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 476,9G 0 disk
├─nvme0n1p1 259:1 0 300M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1G 0 part /boot
└─nvme0n1p3 259:3 0 475,6G 0 part
└─cr_nvme-SAMSUNG_MZVLQ512HALU-000H1_S4UHNF0NA02912-part3
254:0 0 475,6G 0 crypt
├─vg--system-lv--system 254:1 0 20G 0 lvm /var
│ /usr/local
│ /srv
│ /root
│ /opt
│ /
└─vg--system-lv--benutzerdaten 254:2 0 455,6G 0 lvm /home/gheim
/home
Code-Sprache: JavaScript (javascript)Nun installiert man noch die TPM-Tools:
$ sudo zypper install tpm2.0-toolsAnschließend rollt man mittels systemd-cryptennroll TPM aus:
Die Verwendung von PCR 7 schützt nicht vor Änderungen an der /boot-Partition. Dadurch kann ein Angreifer eine modifizierte initrd booten und auf die entschlüsselten Daten zugreifen! Um auch diese in den Schutz einzubeziehen, benötigt man PCRs 2, 4, 8 und 9. Dabei müsste man nach jeder Kernel- und Bootloader-Aktualisierung sowie nach jedem Neuaufbau der initrd den Schlüssel neu hinterlegen. Das ist aktuell noch nicht praktikabel und deshalb empfehle ich hier PCR 7. Zukünftig wird das hoffentlich besser werden, das ganze Konzept ist momentan noch work in progress.
Folgende PCR Definitionen stehen theoretisch zur Verfügung:
| PCR | Erklärung |
| 0 | Core system firmware executable code; changes on firmware updates |
| 1 | Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements |
| 2 | Extended or pluggable executable code; includes option ROMs on pluggable hardware |
| 3 | Extended or pluggable firmware data; includes information about pluggable hardware |
| 4 | Boot loader; changes on boot loader updates |
| 5 | GPT/Partition table; changes when the partitions are added, modified or removed |
| 6 | Power state events; changes on system suspend/sleep |
| 7 | Secure boot state; changes when UEFI SecureBoot mode is enabled/disabled |
| 8 | sd-boot measures the kernel command line in this PCR. |
$ sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3 ##Laufwerknamen anpassenCode-Sprache: PHP (php)Danach muss man noch die /etc/crypttab modifizieren. Dort dürfte nur eine Zeile hinterlegt sein (ansonsten die entsprechende Systempartition wählen). Dort am Ende Folgendes eintragen: tpm2-device=auto. Das Ergebnis müsste in etwa wie folgt aussehen:
cr_nvme-... UUID=b7d... none x-initrd.attach,tpm2-device=autoNun muss noch initrd neu generiert werden:
§ sudo dracut -fNach einem Neustart sollte nun keine Passwortabfrage beim Bootvorgang erscheinen und man direkt beim Loginbildschirm landen, wo man den verschlüsselten systemd-homed-Account anmeldet, um seine Daten zu entsperren.
Nacharbeiten und alternative Möglichkeiten
Das LUKS-Volume kann bei einem Problem mit TPM (was in diesem experimentellen Stadium nicht ausgeschlossen werden kann) immer noch mit den zusätzlich hinterlegten Passwörtern entsperrt werden. TPM belegt einfach einen Keyslot in LUKS. Wenn man sich vollständig auf TPM verlassen möchte, muss man die entsprechenden anderen Keys entfernen. Alternativ kann man auch einen langen und besonders sicheren Schlüssel als Wiederherstellungsschlüssel hinterlegen, was ich sowieso empfehle.
Alternativ lässt sich das Prozedere auch mit einem FIDO2-Stick anstelle von TPM durchführen, was vor allem Sinn macht, wenn man kein separat verschlüsseltes Home-Verzeichnis hat und stattdessen einen zweiten Faktor zur Authentifizierung des LUKS-Containers einziehen möchte. Dadurch verschiebt sich das Schutzkonzept, weshalb das nicht hier im Artikel behandelt wird. In dem hier behandelten Kontext wäre ein FIDO2-Stick eher als Schutzmaßnahme für systemd-homed geeignet – was selbstredend auch unterstützt wird. Das Vorgehen unterscheidet sich nur in wenigen Punkten vom hier geschilderten Szenario und kann dem openSUSE-Wiki entnommen werden.
Zusammengefasst
Angesichts der noch sehr jungen Werkzeuge und eher rudimentären Vorarbeiten der Distribution, funktioniert das Ganze bereits sehr gut. Die systemd-Entwickler haben einmal mehr bewiesen, was für gute Werkzeuge sie den Linux-Anwendern zur Verfügung stellen und damit alte, unzureichende und unnötig komplexe Lösungen überflüssig machen.
Die aktuelle Entwicklung ist ein Übergangsstadium hin zu einer verifizierten Kette vom Systemstart bis zum Login des Anwenders, bei der Signierung und Verschlüsselung ineinandergreifen und nur jene Teile verschlüsselt sind, die es auch sein müssen.
Danke Gerrit für den mal wieder sehr interessanten Artikel.
Ich habe eine off topic Frage:
Gerade spiele ich etwas mit openSUSE herum (nutze im Alltag Ubuntu/ Linux Mint). Ich muss sagen, es gefällt mir ganz gut.
Nur musste ich von KDE zu Gnome wechseln. KDE ertrage ich einfach nicht. Ist sicher Geschmackssache und mir ist klar, dass andere das anders sehen.
Meine Frage ist nun: Gibt es die Möglichkeit eines Dark Mode (wie z.B. bei Ubuntu)?
Firefox und Thunderbird bringen ja einen eigenen mit, aber bei Libre Office wird es schon schwierig. Ich hätte gerne einen systemweiten Dark Mode. Weißt Du, ob etwas in die Richtung kommen soll?
Deinen Artikeln entnehme ich, dass Du openSUSe einsetzt. Welchen Desktop bevorzugst Du? Gibt es dafür Gründe?
Vielen Dank schon mal.
Abgesehen davon, dass ich diese „Dark Modes“ für eine Modeerscheinung halte, in die viel zu viel Arbeitskraft fließt… 😉 Das ist doch keine Frage der Distribution, sondern der Desktopumgebung. Sowohl KDE Plasma als auch GNOME haben dunkle Colorschemes. Bei GNOME ist da inzwischen auch etwas standardisiert worden in Gtk, um das übergreifend nutzbar zu machen. Das kann man unter jeder Distribution aktivieren. Alte Gammelsoftware wie LibreOffice wird das natürlich nicht so schnell komplett und bugfrei unterstützen, sollte aber die Gtk-Themes halbwegs gut darstellen. Ebenso Firefox und Thunderbird.
Ich arbeite mit Pantheon Shell und KDE Plasma.
Mag schon sein, dass Dark Modes eine Modeerscheinung sind, aber ich finde es angenehmer für die Augen, daher nutze ich diese gerne.
Mit ist schon klar, dass es keine Frage der Disto ist, sondern der Desktopumgebung. Dennoch kann ich dies bei Gnome/Ubuntu einfach in den Einstellungen/Darstellung auswählen. Bei Gnome/openSUSE ist das leider nicht der Falll.
Da Du dich offensichtlich viel mir openSUSE beschäftigst, dachte ich, Du kennst vielleicht einen einfachen Weg. Wollte Dir nicht auf die Füße treten;)
Du bist mir nicht auf die Füße getreten 😉 Da ich GNOME nicht nutze, kann ich nicht sagen, wo man da einen Schalter umlegen kann/muss.
Hallo Gerrit,
ich beschäftige mich gerade mit LUKS und TMP da ich meine Proxmox Hypervisor verschlüsseln will und zwecks High Availibility und automatischen Neustart nach Stromausfall macht hier natürlich eine Lösung die eine Benutzeraktion nach dem Booten benötigt keinen Sinn. Dabei ist mir jedoch dieser Abschnitt in deinem Text aufgefallen :
„Eine automatische Entsperrung des LUKS-Systemcontainers mittels TPM macht natürlich keinen Sinn, wenn es der einzige Schutzmechanismus ist. Ein Angreifer benötigt dann nur das Gerät, um an alle Daten zu kommen.“
Wie ist das zu verstehen? Mein Verständnis war das dies nur nach einem Erfolgreichen Angriff auf das TPM Modul möglich ist. Andernfalls lassen sich die Dateien auf dem Speicher nicht Entschlüsseln da der Verschlüsselungskey aus dem TPM Modul nicht bekannt ist. Das Gerät starten, gibt zwar prinzipiell Zugriff auf unverschlüsselte Daten, jedoch wird hier der Angreifer meistens mit einer Login Aufforderung begrüßt, wenn er hier die Zugangsdaten nicht kennt kommt er hier doch nicht weiter?
Das booten eines anderen Systems um die unbekannten Login Daten zu umgehen, macht auch keinen Sinn da das TPM Modul dies erkennt und keine Entschlüsselung der Daten ermöglicht.
Welche Angriffsvektor übersehe ich hier, mal angenommen es würden PCRs 2, 4, 7, 8 und 9 genutzt?
Das ist soweit korrekt. Ein erfolgreicher Angriff auf das TPM-Modul ist unwahrscheinlich. Die Verknüpfung von LUKS mit TPM schützt also vor der Entfernung des Speichermediums (mit all den Folgen für leichtere Angriffsmöglichkeiten). Hat der Angreifer aber Zugriff auf das gesamte Gerät, startet das System natürlich normal und der Angreifer kommt bis zur Loginmaske. Was soweit ja intendiert ist. Hier ist dann die Frage, wie die Daten dann weiter geschützt sind. Z.B. ein separat verschlüsseltes Home-Verzeichnis, das an den Login gebunden ist oder verschlüsselte Partitionen, die beim Login entschlüsselt werde. Denn der Linux-Login ist ja im Prinzip nur Kosmetik, normalerweise liegen die Daten dann schon offen.
Ich habe auf die schnelle keine Möglichkeit gefunden den Linux Login zu umgehen, die nicht von einem LUKS + TPM Verschlüsselten System verhindert wird. Zumindest wenn TPM kein Boot im RecoveryMode zulässt, was es nicht tun sollte. Testen konnte ich das aber noch nicht. Mir geht es ja nicht darum die Daten vor versierten Sicherheitsspezialisten oder Geheimdiensten zu verbergen, sondern nur zu verhindern das bei einem Einbruch in die eigene Wohnung die Daten auf dem Gerät mit einem 5 Minuten Video Tutorial ausgelesen werden können und ich glaube dafür reicht mir diese Lösung aus. Kernel und Bootloader Updates werde ich dann ersteinmal aussetzen müssen bis dieses Problem gelöst ist, aber da das System nicht vom Internet aus ereichbar ist sollte das auch erstmal kein großes Problem sein.
Unter Windows verhindert Secure Boot eine OS Modifikation, die den Login Screen umgeht während die Festplatte entschlüsselt ist. Ist das bei Linux anders?
Natürlich hilft das nichts gegen mit Mikroskop und entsprechendem Lötkolben ans TPM ranzugehen oder das RAM einzufrieren bis man es in eine Angriffsmaschine eingebaut hat, aber wie der Vor-Poster sagt sind das nicht die Angriffszenarien für die Allgemeinheit.