Debian 12 Testing, TPM, Dracut und verschlüsseltem LVM

[schorsch_76]

Über soetwas in der Art hab ich letztens was gelesen. Da würde aber der Schlüssel aus dem Tpm per Pin ausgelesen und damit das Laufwerk entschlüsselt....

Wenn da die Disk in einem anderen Rechner steckt, lässt sie sich nicht mehr entschlüsseln...

https://glentomkowiak.medium.com/luks-w ... f867cad9a1

Bzw.

https://curius.de/2022/02/verschluessel ... ntsperren/

Selber habe ich damit leider keine Erfahrungen...

Unter Debian gibt es auch noch tpm2-initramfs-tool

[teklord]

Theoretisch kannst du bei TPM ohne PiN den hash aus dem RAM auslesen, wenn du das RAM einfrierst und dann Byte für Byte durchsuchst. Laborbedingungen!

Bei FDE geht es ähnlich, angeblich aber schneller...

Bei FDE kannst du dir auch einen Speicher dump ziehen, was wesentlich einfacher ist...unter laborbedingungen.


Das mit den Laborbedingungen ist halt das Ding bei uns.
Es würde sich für einige Angreifer lohnen...

[schorsch_76]

Ich such gerade den Artikel finde ihn momentan nicht ....

EDIT: Arch Wiki
https://wiki.archlinux.org/title/Truste ... orm_Module

Note: As of systemd 251 it is now possible to require a PIN to be entered in addition to the TPM state being correct. Simply add the option --tpm2-with-pin=yes to the command above and enter the PIN when prompted.

Bookworm hat 252.

Code: Alles auswählen

apt-cache policy systemd
systemd:
  Installiert:           252.6-1
  Installationskandidat: 252.6-1

Und wurde hier angekündigt
https://0pointer.net/blog/unlocking-luk ... d-248.html

Installier gerade eine VM und versuch das mal. Interessiert mich auch

[schorsch_76]

Ich habe gerade ein frisches Debian 12 amd64 in einer VM (mit TPM2) installiert.

Mit der initramfs hab ich es nicht zum laufen bekommen aber mit dracut.

Schlüssel in der TPM erzeugen mit Pin

Code: Alles auswählen

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-with-pin=yes /dev/vda3
sudo systemd-cryptenroll --recovery-key /dev/vda3

(Hier den Key fotografieren mit QR Reader)

Code: Alles auswählen

sudo apt install dracut tpm2-tools

in der /etc/dracut.conf

Code: Alles auswählen

add_dracutmodules+=" tpm2-tss systemd-ask-password crypt "

(wichtig die Leerzeichen zwischen den "")

In der /etc/default/grub

Code: Alles auswählen

GRUB_CMDLINE_LINUX="rd.auto rd.lvm=1 rd.luks=1"

Dieser Kernelparameter kann sicher auch mit systemd-boot hinzugefügt werden.

Code: Alles auswählen

sudo dracut -f
sudo update-grub

crypttab wird hier nicht gebraucht.

[cosinus]

Über soetwas in der Art hab ich letztens was gelesen. Da würde aber der Schlüssel aus dem Tpm per Pin ausgelesen und damit das Laufwerk entschlüsselt....

Von solchen Ansätzen hab ich auch schon öfter gelesen. Das Disk-Passwort aber was ich meine ist das hier --> ATA Security Feature Set
Also ein Passwort auf Hardware-Ebene wenn man so will. Wie kann das umgangen werden?

Im Intelforum fragte das auch jemand mal, und ob man zumindest eine so geschützte SSD resetten kann, so dass sie keine Daten mehr hat und wie neu eine neue Disk nutzbar ist. Kurz: ein Dieb kann mit so einer gesicherten SSD nichts anfangen...

[schorsch_76]

Hier ist die gesamte Forderung erfüllt. Pin für den Tpm Schlüssel, OK, noch ein recovery Schlüssel, kann auch weg und man kann noch das initiale Passwort entfernen.

Zusätzlich könnte man bei den Anforderungen nach dem Speicherdump noch den Kernel Lockdown machen und Secureboot.

[teklord]

Danke!


Mega, es läuft!




Dank euch!

[MSfree]

Also ein Passwort auf Hardware-Ebene wenn man so will. Wie kann das umgangen werden?

Da das nur den Zugriff beschränkt, Daten aber dennoch unverschlüsselt auf der Platte/SSD landen, kann man am Controller ansetzen. Dazu ist allerdings entsprechende Laborausrüstung und ggfls. sogar entlöten des Controllers und ersetzen mit einem neuen notwendig. Das ist also nichts, was der einfache Dieb machen könnte.

Wenn der Wert des Platteninhalts, wie oben erwähnt, aber hoch genug ist, und man es mit Industriespionage oder Geheimdiensten zu tun hat, fällt das Konzept der einfachen Zuganssperre in sich zusammen.

[cosinus]

Da das nur den Zugriff beschränkt, Daten aber dennoch unverschlüsselt auf der Platte/SSD landen, kann man am Controller ansetzen.

Das ist m.W. nicht möglich, da der Schlüssel nicht im Controller gespeichert wird. Ein Tausch des Controllers würde also nix bringen.
Angeblich hat es mal irgendein Datenrettungsunternehmen geschafft so ein Passwort zu umgehen, aber es wurde nicht gesagt wie das ging (es fehlt also der beweis) und IIRC ging das auch nicht bei jeder Disk. Und das ist auch schon eingie Jahre her.

[schorsch_76]

Danke!


Mega, es läuft!




Dank euch!

Kannst du bitte noch mit [gelöst] markieren? Danke!

[MSfree]

Das ist m.W. nicht möglich, da der Schlüssel nicht im Controller gespeichert wird. Ein Tausch des Controllers würde also nix bringen.

Wie gesagt, für Otto-Normalverbraucher ist das völlig unmöglich. Man kann aber einen Controller einlöten, der das Passwort schlicht ignoriert und trotz gesetztem Passwort auf die Daten zugreift.

Es gibt ja auch genug gefälschte USB-Sticks, bei denen der Controller/die Firmware so manipuliert ist, daß sich ein 4GB Stick als 1TB Stick ausgibt. Genauso ist eine maipulierte Firmware/ein maipulierter Controler möglich, der das Passwort ignoriert. Wenn das schützenswerte Gut genug Gewinn verspricht, fällt der Aufwand zum Knacken nicht mehr in Gewicht.

[cosinus]

Wie gesagt, für Otto-Normalverbraucher ist das völlig unmöglich. Man kann aber einen Controller einlöten, der das Passwort schlicht ignoriert und trotz gesetztem Passwort auf die Daten zugreift.

Wie muss man sich das denn vorstellen?
Woher bekommt man diesen Controller? Und wie kann man den so manipulieren, dass das klappt? Hast du da Beispiele für?
Kommt mir alles sehr weit hergeholt vor...