Verschlüsselte Festplatte komfortabel mit TPM entschlüsseln oder doch lieber mit Passwort?

Sicherheit
1

Auf meinem Arbeits-Laptop läuft Windows mit Full Disk Encryption (Bitlocker), welche „automatisch“ vom TPM entsperrt wird, sodass ich nach einem Neustart bis zum Login-Bildschirm booten kann und dort nur meine PIN eingeben muss.

Auf meinem Privat-Laptop läuft OpenSUSE, ebenfalls mit Full Disk Encryption (LUKS). Ich muss momentan zwei Passwörter eingeben - eins ganz am Anfang in Grub, und eins dann beim normalen Login-Bildschirm (SDDM). Da habe ich auch bewusst zwei verschiedene Passwörter gewählt um die Sicherheit zu erhöhen.

Nun scheint es aber jetzt auch unter Linux (oder spezifisch OpenSUSE, andere Distros konnten’s vielleicht schon vorher) möglich zu sein, die Festplatte via TPM zu entschlüsseln: https://en.opensuse.org/SDB:Encrypted_root_file_system#Unattended_boot_with_TPM_2.0

So wie ich das verstanden habe, bleibt das LUKS-Passwort auch weiterhin bestehen, und kann benutzt werden wenn der TPM-Schlüssel nicht funktioniert (z.B. nach Update von grub2 oder shim). Oder?

Ich frage ich aber, ob das Entsperren via TPM überhaupt ratsam ist. Ich meine, komfortabler ist es mit Sicherheit, wenn man nur ein Passwort eingeben muss. Und theoretisch ist man ja immer noch gegen typische Angriffe geschützt:

  • jemand stiehlt den Laptop → kann trotzdem nicht an die Daten ohne das normale Login-Passwort des Benutzers zu kennen (vorausgesetzt es gibt keinen Bug in SDDM/GDM/LightDM, der eine Umgehung des Passwortes ermöglicht).
  • jemand baut die Festplatte aus → kann nicht entschlüsselt werden, da die TPM fehlt, bzw man braucht trotzdem das normale LUKS-Passwort um es zu entschlüsseln

Gibt es denn dann konkrete Nachteile, wenn man das TPM benutzt? Vom Gefühl her kommt es mir unsicherer vor, aber ich kann keine richtigen Argumente dagegen finden.

2

Ein offensichtlicher Nachteil ist, dass du den verschlüsselten Datenträger dann wohl niemals an oder in einen anderen deiner Computer erfolgreich wirst anschliessen können. Nur für den Fall, dass „Computer kaputt, aber Datenträger noch ok“ und du die Daten dann woanders auslesen willst…

3

In dem Artikel steht:

Since the TPM PCRs are sensitive to changes, the key unsealing may fail after a boot component update, e.g. shim, grub2, or UEFI firmware. In such case, you can update the signature of the sealed key with

user $ sudo fdectl tpm-authorize

This command calculates the new PCRs and update the signature in the sealed key.

Das hatte ich so interpretiert, dass das alte Passwort immer noch geht, wie soll man sonst das System booten um diesen Befehl auszuführen? Aber wenn das nicht so ist, ist das wirklich ein gravierender Nachteil

4

Ich verstehe das so, dass du damit den Key im TPM aktualisieren kannst, wenn dein System nach einem Update nicht mehr booten will. Das sollte ja auch der Sinn eines TPM sein, dass dort der Key nicht auslesbar abgelegt ist. Ich habe mich bisher nur an normales LUKS mit Passwort auf meinem Laptop getraut.

5

Wenn Du das Passwort - das zum einrichten des TPM benötigt wird - nicht löscht. Dann stimmt das.

Du kannst auch noch weitere Passworte anlegen.

Bei einem TPM mit automatischer Entschlüsselung (ohne TPM-PIN), kann die Kommunikation mit den LUKS-Modul belauscht werden. Damit lässt sich das Passwort dann - wahrscheinlich - herausfinden.

Der Anmeldebildschirm von Linux ist keine große Hürde. Gegen versierte Angreifer wird ein solcher Schutz nicht lange halten.

6

Ich weiß nicht, wie das bei anderen Distributionen ist. Aber bei Mint kann man in Grub auch die Recovery Console auswählen. Bei einer automatisch entschlüsselten Platte hätte der Angreifer jetzt fast alles, denn für das was interessant ist, braucht er keine root-Rechte.

1 „Gefällt mir“
7

Mein Firmenrechner unter Win ist mit TPM, aber die Arbeits-Daten werden in eine Firmen-Nextcloud gesynct.
Privat unter Win habe ich das nicht und will eine Situation vermeiden, wie sie thomasmerz genannt hat.

8

Eine Zeit lang hab ich LUKS+TPM genutzt, bin davon aber wieder weg. Hauptgrund ist, dass ich jemanden gerne möglichst früh aufhalten möchte. LUKS ohne TPM bietet genau das - sozusagen einen zweiten (statischen) Faktor. Wenn jeder bis zum Anmeldebildschirm booten kann, bieten sich dadurch auch grundsätzlich immer mehr Möglichkeiten als vorher. Ich persönlich sehe bei der Verwendung vom TPM keinen Mehrwert, aber das muss man abwägen (Sicherheit vs. Komfort).

1 „Gefällt mir“
9

Wie ist das technisch umgesetzt? Das normale Userpasswort schützt keine Daten, das lässt sich problemlos umgehen. (Genauso wie es bei Windows auch ist.) Oder ist der Home-Bereich separat verschlüsselt?

So oder so sehe ich den Sinn aktuell nicht wirklich. Wenn jemand an die Daten ran will, nimmt er den ganzen Laptop mit.

Ich selbst setze noch ganz klassisch auf eine Plattenverschlüsselung mit LUKS und ein hinreichend langes Passwort.

10

Ich hatte ja oben schon geschrieben, dass man bei Mint, ich könnte mir auch bei Ubuntu vorstellen, im Grub unter Optionen den Recovery Mode anwählen kann. Hier hat man dann sogar die Möglichkeit eine root-Konsole aufzurufen. Tata ein sechser mit Zusatzzahl.
Wenn die Verschlüsselung automatisch authentifiziert wird, ist man so sofort an den Daten. Dagegen hilft nur das Setzen eines root-Passwortes.

11

Danke für die Antworten. TPM scheint also keine gute Idee zu sein, wenn es einem um die Sicherheit der Daten geht (z.B. im Extremfall bei Beschlagnahmung des Rechners durch die Polizei).

Der Zweck des Ganzen ist wohl eher sowas wie Remotezugriff auf einen Server nach Neustart oder unkomplizierte Full-Disk-Encryption ohne Extrapasswort wenn es nur um Diebstahlschutz geht (-> Bitlocker auf dem Arbeitslaptop).

12

Ich gebe für die Preboot Authentifizierung nur einmal ein starkes Passwort auf dem Linuxrechner für die LUKS Entschlüsselung und auf Windows für die Bitlocker Entschlüsselung (Bitlocker+PIN) ein und lasse mich dann gleich zum Benutzeraccount durchstarten.
Somit sehe ich keinen Nachteil auf dem Windowsrechner auch den TPM mitzunutzen.

1 „Gefällt mir“
13

Ich weiss nicht, ob ich das so richtig verstehe, dass du Linux und Windows im Dualboot auf ein und demselben Computer verwendest?! Mir ist da nur von einem Talk auf der GPN21 vom Leyrer hängengeblieben, dass man seinen SSH-Key zwar auch im TPM ablegen kann (was ich für eine generell gute Idee halte…), aber wenn man auch Windows im Dualoboot hat, dann bootet dann Windows nicht mehr. :bomb:

Ob das hier auch der Fall ist kann ich mangels Windows nicht sagen. Ich und sicher auch viele andere wären sehr interessiert den Status Quo dazu zu erfahren :slight_smile:

14

@thomasmerz
Da habe ich mich missverständlich ausgedrückt. Linux und Windows laufen auf zwei getrennten Rechnern.
Ich meinte es im Zusammenhang, dass ich schon Leute erlebt habe, die meinten, dass eine Bitlockerverschlüsselung zu umständlich sei und wenn man den TPM (ohne Passworteingabe) und das Benutzerkontokennwort zur Anmeldung an Windows nimmt, Bitlocker nicht die volle Sicherheit bietet, da dann nur das Benutzerkennwort geknackt werden muss. Ich hatte dann darauf hingewiesen doch Bitlocker + PIN zu nutzen und sich die extra Windowsanmeldung zu sparen. Dann sehe ich auch kein Sicherheitsrisiko den TPM mitzunutzen, da er mit einer PIN geschützt ist.
Früher war die Bitlockerbenutzung mit PIN etwas umständlich einzurichten, was dann mit Windows 10 geändert wurde.

Dazu kann ich nichts sagen, nur dass es andere wohl schon mit Erfolg versucht haben. Scheint etwas Gefrickel zu sein.
https://bbs.archlinux.org/viewtopic.php?id=273365 oder https://www.reddit.com/r/archlinux/comments/cox3jw/dualboot_windows_enterprise_bitlocker_tpm_secure/

15

Ich meinte es im Zusammenhang, dass ich schon Leute erlebt habe, die meinten, dass eine Bitlockerverschlüsselung zu umständlich sei und wenn man den TPM (ohne Passworteingabe) und das Benutzerkontokennwort zur Anmeldung an Windows nimmt, Bitlocker nicht die volle Sicherheit bietet, da dann nur das Benutzerkennwort geknackt werden muss.

Aber bei Bitlocker „ersetzt“ dann doch die PIN das Passwort, oder? Ist es nicht genau so sicher wie vorher - man muss nur eine Sache (PIN bzw Passwort) kennen um reinzukommen?

16

Wenn wir nicht aneinander vorbei reden, hast du Recht, nur dass die PIN nicht das Passwort ersetzt, sondern mit Beidem das Gleiche gemeint ist. Vor Windows 10 bedeutete PIN nur eine nummerische Eingabe und die erweiterte PIN ein Passwort mit beliebige Zeichen, was man aber erst über die Gruppenrichtlinien einstellen musste, sonst wurde Bitlocker standardmäßig bei Benutzung eines TPM ohne zusätzliche PIN/Passworteingabe eingerichtet, also ohne Preboot Authentifizierung.
Bei Windows 10 Pro wird nun standardmäßig bei der Bitlockereinrichtung ein Kennwort gefordert, was der Funktion TPM+(erweiteter) PIN entspricht, also mit Preboot Authentifizierung.
Schaust du in den Gruppenrichtlinien (wo du auch den TPM deaktivieren kannst) ist weiterhin von der PIN die Rede. Hier kannst du als Alternative zur PIN auch einen Systemstartschlüssel auf USB Stick festlegen oder als zusätzlichen Schutz den Systemstartschlüssel + die PIN erforderlich machen.

Bei Eingabe des Passwortes musst du nur beachten, dass nachher beim Starten des Rechners bei der Passworteingabe das englische Tastaturlayout gilt. Das heißt, willst du beim Rechnerstart das Bitlockerpasswort yz eingeben, musst du vorher bei der Bitlockereinrichting auf deinem deutschen Tastaurlayout als Passwort zy festgelegt haben.

Wo du nun den 48 stelligen Wiederherstellungsschlüssel speicherst, bleibt bei Windows 10 Pro dir überlassen, USB-Stick, Textdatei oder Microsoftcloud.

Ob sich bei Windows 11 etwas geändert hat weiß ich nicht.

https://www.windowspro.de/wolfgang-sommergut/bitlocker-key-pin-absichern
oder
https://www.heise.de/ratgeber/Windows-Festplatten-mit-Bordmitteln-verschluesseln-4572663.html

17

Du hast eine /boot Partition als eigene LUKS1||2 mit pbkdf Partition eingerichtet.
Aufgrund der inhärenten Schwäche des pbkdf Algorithmus gegen Attacken mit viel Rechenleistung sollte die /boot LUKS Partition mit

cryptsetup luksChangeKey --pbkdf-force-iterations „your personal small-prime-number“ /dev/sdX1

gesichert sein.
Der Standardwert für die Runden ist meist keine Primzahl und optimiert auf ein schnelles „Booterlebnis“. Die Nutzung von Primzahlen dort kostet keine ms mehr!
Das übliche /boot unverschlüsselt zu lassen - und dann mit LUKS2 /root und /home zu verschlüsseln ist imho ein Security Witz.
Wobei wir bei der Abwehr von evil maid Angriffen wären…
Imho ist es keine gute Idee ein LUKS /boot automatisch per - tpm spendiertem - LUKS Key entschlüsseln zu lassen. Somit ist /boot für halbwegs versierte Angreifer offen - und das was Dir ein entsprechender Angreifer auf /boot hinterlassen würde - wäre ein keylogger, der deine LUKS Passphrase Eingaben nach hause schicken würde…
Daher sollte bei fde - neben einem anderen Passphrase für /boot und dem Rest auch noch - beim boot von /root aus eine Identitätscheck über /boot laufen, der im Zweifelsfall bei einem Identitätsfehler in /boot das aktuelle /root LUKS password löscht und das System sofort anhält. (Du hast vorher ein zweites /root LUKS Passphrase eingerichtet für diesen Fall.)
Auch den Gedanke sich die Eingabe des /root LUKS Passphrase zu sparen in dem man das aus dem tpm holt ist gefährlich, da ich mit vorstellen kann, dass ein evil maid Angriff (z.B. auf Deinem polizeilich um 5:00 sicher gestellten Laptop) u.U. von einem anderen eingebauten Datenträger booten - und dann /root einbinden könnte.
Mein persönliches FDE Sicherheitsempfinden ist z.Zt. so, dass ich mich dazu durchringe 2 separate Passphrases für das Booten zu nutzen (1 * /boot und 1 * /root) und die restlichen Partitionen für weitere VGs mit auf /root eingebundenen Keys per crypttab - meiner Faulheit folgend automatisch - entschlüssele.

Apropos Faulheit:

$ cat small-prime.sh
#! /bin/bash
END=300001
for ((i=200001;i<=END;((i+=2)))); do
    y=$(factor $i | wc -w)
    if [ $y = 2 ]
    then
     echo $i
    fi
done

Die Werte 300001 und 200001 sollten nach Ansicht des original vom Setupscript eingetragen Wertes in die LUKS /boot partition angepasst werden (hängt von der Rechenpower deines Schlepptop ab (Mein neuer Rechner ist bei ~ 5000000 Runden.).).
Einfach eine willkürlich von Dir ausgewählte Primzahl von Bildschirm fischen und den cryptsetup luksChangeKey damit füttern. (Vorsicht diese Vorgehen formatiert die LUKS Partition grundlegend neu…). U.U. quadriert das den Aufwand der Angreifer um den LUKS1 /boot Key zu brechen - ohne dein „Booterlebnis“ unnötig zu verlängern…

18

Benutze einfach LUKS mit Passwort. Bei meiner Distri wird per default die gesamte Platte verschlüsselt also auch /boot und GRUB macht das mit dem Passwort auf, wobei das bei mir eh egal wäre. Bei meinem Grund der Verschlüsselung spielen High-Level-Attackers mit heimlich installierten Trojanern oder viel Rechenleistung sowieso keine Rolle sondern dass jemand normales durch Diebstahl oder andere Umstände in den Besitz meiner Hardware kommt und mangels Passwort meine Daten dann von selber löscht um die Hardware für sich nutzbar zu machen.

1 „Gefällt mir“
19

Ist schon etwas länger her, dass ich Ubuntu 20 LTS installiert und mit LUKS (ohne die Bootpartition) verschlüsselt habe. Scheint aber automatisch argon2i zum Zuge gekommen zu sein.

Wenn ich es richtig verstehe, willst du unbedingt Boot verschlüsseln als Indentitätscheck. Da Grub aber nur mit PBKDF2 entschlüsselt, versuchst du dies mit den von dir beschriebenen Primzahlen sicherer zu machen, ohne die Bootzeit in die Länge zu ziehen. Zwei Passwörter brauchst du dann wegen PBKDF2 bei Boot und argon2i bei der Rootpartition?
Woher hast du oder wie kommst du auf das Script?

Im Allgemeinen wird doch auch gesagt, dass mit einem sicheren Passwort (20 wirkliche zufällige Zeichen) auch PBKDF2 ausreichend sicher ist.
https://www.heise.de/news/Alte-LUKS-Container-unsicher-Ein-kleiner-Update-Ratgeber-8981054.html

20

Ist schon etwas länger her, dass ich Ubuntu 20 LTS installiert und mit LUKS (ohne die Bootpartition) verschlüsselt habe. Scheint aber automatisch argon2i zum Zuge gekommen zu sein.

Das letzte Linux bei dem man mit Bordmitteln /boot verschlüsseln durfte (Klick & Fertig) war imho SUSE 7.3… Danach war das technisch zu schwierig - um es allen Linuxern einfach so zur Verfügung zu stellen …

Calamares & Co. „können“ das heute alle nicht mehr. Auch systemd macht es nicht leichter…

Nach den politischen - komme ich nun zu den technischen Fakten. grub2 kann nicht von LUKS Partitionen booten, die argon2(i) einsetzen. Daher ist ein downgrade auf PBKDF2 angezeigt.

https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

ist eine nette Seite, die Möglichkeiten aufzeigt ein FDE System aufzusetzen.

Wenn ich es richtig verstehe, willst du unbedingt Boot verschlüsseln als Indentitätscheck.

Nein nicht ganz … :smiley: Ich will /boot verschlüsseln damit man mir nicht /root entschlüsseln kann.

Wenn Du /boot unverschlüsselt auf deinem kurzzeitig unbeaufsichtigten Rechner hast, dann kann wirklich jeder „Wirtschaftsinformatiker FH“ in Staatsdiensten - den Rechner in ein paar Minuten (per evil maid Angriff auf den Inhalt von /boot) - den Rechner mit ein paar Keylogger Beigaben versehen, die deine Verschlüsselungsbemühungen ad absudum führen.

Ja genauso mache ich das. Zudem gehe ich noch einen Schritt weiter und probiere größere Zahlen - um einfach noch mehr Aufwand in die bute force Knackaktionen zu bringen.

Ja. Zum Einen mache ich das Entschlüsseln von /boot teuer - und zum Anderen lege ich keinen root key nach /boot und gebe damit die Verschlüsselung des Rechners nach Knacken der /boot Partition auf - sondern nutze ein anderes Passphrase um /root (und andere verschlüsselte Dateisysteme) zu schützen.

Das Script habe ich mir selbst gebastelt. Es basiert auf /usr/bin/factor, das in den core utils enthalten ist.
Es wäre viel besser der Maintainer der LUKS Pakete würde die Rundenzahl per rand() Funktion aus einer Liste der von factor aussortierten Primzahlen fischen - als ziemlich gut faktorisierbare Zahlen zu nutzen - aber das ist möglicherweise - ebenso wie das standardmäßige offen lassen von /boot eine politische Entscheidung…

Jein! Ja, wenn Du eine hinreichende Zyklenanzahl hast und ein lang genuges Passphrase. Nur 20 Zeichen reine Entropie merke ich mir nicht sonderlich gut. Daher ist mein Passphrase eher länger, weil es weniger zufällig ist.
Zudem ist m.E. die Verwendung von zufällig individuell ausgewählten Primzahlen in der Kryptographie - wo möglich - immer der Verwendung von faktorisierbaren Zahlen vorzuziehen. Zumal (wie mein stümperhaftes script zeigt) der Aufwand so etwas zu nutzen - sich in sehr übersichtlichen Grenzen hält.

Der zusätzliche billige Identitätscheck in eine frühen Phase des Bootprozesses auf die Integrität von /boot ist der Tatsache geschuldet, dass Zweifel an den Unknackbarkeit von LUKS1 durchaus ernst zu nehemen sind - und auf Cloudsystemen durchaus große Schlüssel mit allerlei Tricks (gegen die u.U. auch kleine Primzahlen hilfreich sein können) und brutaler Rechenpower linear skalieren niedergerungen werden können. (Per evil maid Angriff können die Anzahl der Runden - und der Hash des Schlüssels ausgelesen werden.)
Daher ist im (für den Angreifer teuren - aber nicht unmöglichen) Fall eines Angriffs auf deine /boot Partition, ein automatisiertes Löschen der kompromitierten Schlüssel (für /root) auf dem System - und eine automatische Außerbetriebnahme des Rechners angezeigt. (luksRemoveKey ist dein Freund.)