Echte Full Disk Encryption

[rhHeini]

Die klassische FDE wie auch ich sie verwende benötigt ein unverschlüsseltes /boot. Und die Verschlüsselung geht mit luks2.

Ich bin jetzt dabei mich mit einer vollständigen FDE mit verschlüsseltem Boot zu beschäftigen. Bei Arch ging das schon vor 4 Jahren als ich mich mal mit diesem OS beschäftigt habe. Aber wenn ich da die diversen HowTos lese scheint es so zu sein dass so etwas nur mit luks1 geht. grub scheint immer noch diverse Einschränkungen zu haben, kann zwar angeblich luks2 aber nicht argon2id als Keyableitung, sondern nur PBKDF2.

Hat schon mal jemand eine echte FDE mit Debian hinbekommen? Wenn ja, wie?

[tobo]

Hat schon mal jemand eine echte FDE mit Debian hinbekommen? Wenn ja, wie?

Echte FDE ist jetzt was für dich - a) komplett verschlüsselt oder b) komplett verschlüsselt mit LUKSv2? a) ja und b) nein.

[rhHeini]

Natürlich mit luks2. Jedenfalls für /.

Edith: Tut mir leid, dieses Dokument:

https://cryptsetup-team.pages.debian.ne ... -boot.html

ist fünf Jahre alt und für mich damit veraltet. Es redet davon /boot auf luks1 zu konvertieren.

[tobo]

Natürlich mit luks2. Jedenfalls für /.

Die Frage ist ja auch nicht / sondern separates /boot! a) ist /boot mit LUKSv1 und die restlichen Partitionen mit LUKSv2. Für b) wäre es notwendig, dass die Unterstüzung in Grub hinzugefügt wird, was noch nicht der Fall ist. Also ist das auch nicht Debian-abhängig.

[schorsch_76]

grub2.06 kann luks2 entschlüsseln.

https://cryptsetup-team.pages.debian.ne ... -boot.html

https://linuxnews.de/grub-2-06-endlich- ... stuetzung/

https://www.gnu.org/software/grub/manua ... ryptomount

[rhHeini]

Danke für die Links.

grub2.06 kann luks2 entschlüsseln.

https://cryptsetup-team.pages.debian.ne ... -boot.html

Hab ich auch schon gefunden. Der Artikel ist leider von 2019, 5 Jahre alt, von vor den Umstellung auf 2.06. Beschäftigt sich halt u.a. damit wie man luks2 zu luks1 konvertiert. Nicht das was ich will und suche. Müsste mal auf die heutige SW aktualisiert werden.

https://linuxnews.de/grub-2-06-endlich- ... stuetzung/

Ja die Ankündigung aber ohne Hilfe wie umzusetzen. Immerhin ein Link drin auf das grub-Manual, das kannte ich aber eh schon.

https://www.gnu.org/software/grub/manua ... ryptomount

Siehe oben.

Was mir fehlt sind konkrete Beispiele wie man so etwas macht. Ich tu mich mit den strohtrockenen Linux-Manuals immer schwer wenn da keine Beispiele für konkrete Anwendungsfälle drin sind und auch keine Fehlerbehebungen.

Ich hab noch ein Arch installiert vor ca. 3 Jahren auf dem Rechner was zwar nimmer bootet weil ich es nicht regelmässig auf Stand gehalten habe und dann irgendwann mit einem Update gescheitert bin, aber ich hab dann doch dran gedacht mal ein luksDump über die Partition zu machen. Und siehe da, Arch verwendet da Argon2i als Ableitung, nicht PBKDF2, aber auch nicht Argon2id was aktuelle Debian/Devuan-Installer einrichten.

[niemand]

Und siehe da, Arch verwendet da Argon2i als Ableitung, nicht PBKDF2, aber auch nicht Argon2id was aktuelle Debian/Devuan-Installer einrichten.

Arch nutzt, was der Installateur einrichtet. Wenn man bei der Installation die Defaults von cryptsetup nimmt, sieht’s Stand Anfang des Jahres (da hab ich ’nen neuen Laptop aufgesetzt) so aus:

Code: Alles auswählen

Keyslots:                        
  0: luks2                       
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain
        Cipher key: 512 bits
        PBKDF:      argon2id

[frankm78]

Ich weiß nicht, ob das deinen Ansprüchen für FDE entspricht, aber schon seit ungefähr 10 Jahren habe ich alle Partitionen auf meinen Laptops vollständig mit luks2 aes-xts-plain 512 Bit verschlüsselt. Das einzige Unverschlüsselte bleibt grub2, das lädt dann die verschlüsselte Boot-Partition über Passwort und in der Initram sind Keys für root, home und weitere Datenspeicher hinterlegt. So muss ich dann nur einmal das Passwort für das Laden von Boot eingeben (gut, hab auch noch ein Bios-Lock, aber das ist separat) , alles andere wird bis zum OS automatisch geladen.

Keine Ahnung, ob das noch zeitgemäß ist, aber Keys liegen unter /etc/keys, ein Script unter /usr/share/initramfs-tools/hooks/ bindet die in die initram ein und geladen wird dann alles, wenn ich mich richtig erinnere, über ein weiteres Skript in der crypptab. Kann gerne detaillierter darauf eingehen, falls dich der Ansatz interessiert.

[TRex]

Ich weiß nicht, ob das deinen Ansprüchen für FDE entspricht

Ich bin jetzt dabei mich mit einer vollständigen FDE mit verschlüsseltem Boot zu beschäftigen.

Leute, ihr müsst die Beiträge auch lesen...

[tobo]

Das ist offensichtlich nicht das Problem hier:

Das einzige Unverschlüsselte bleibt grub2, das lädt dann die verschlüsselte Boot-Partition[...]

[TRex]

Argh. Sorry.

[tobo]

Vielleicht gibt's ja zu diesem freischwebenden Grub noch weitergehende Informationen?

[Livingston]

Und wenn wir schon mal dabei sind... Wie kriege ich denn den UEFI-Krempel-Blob-Kram unter /boot/efi/ verschlüsselt? Wie, was, geht nicht?
Ach immerhin, es gibt ja das absolut wasserdichte Secure-Boot. Dann ist ja alles ok

[rhHeini]

Arch nutzt, was der Installateur einrichtet. Wenn man bei der Installation die Defaults von cryptsetup nimmt, sieht’s Stand Anfang des Jahres (da hab ich ’nen neuen Laptop aufgesetzt) so aus:

Code: Alles auswählen

Keyslots:                        
  0: luks2                       
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain
        Cipher key: 512 bits
        PBKDF:      argon2id

Nun, meine Arch_installation ist halt rund 3 Jahre alt, wundert mich nicht das eine neuere Installation da im Details was neueres verwendet (dieses Argon2id).

Und ich hab in meinen Aufzeichnungen nachgesehen, ich habe da nichts explizit umkonfiguriert, alles Defaults was die Verschlüsselung angeht. Und das hat auf Anhieb funktioniert. Und das steht im Gegensatz zu den hier angeführten Dokumenten, und selbst dem Englischen Arch-Wiki, wo ich das auch nochmal nachgelesen habe.

[cosinus]

Die klassische FDE wie auch ich sie verwende benötigt ein unverschlüsseltes /boot. Und die Verschlüsselung geht mit luks2.

Da ihr euch alle immer irgendwie nur auf LUKS stürzt: wie wärs denn mit Absicherung der Disk über ein Passwort übers BIOS?

[niemand]

Nun, meine Arch_installation ist halt rund 3 Jahre alt, wundert mich nicht das eine neuere Installation da im Details was neueres verwendet (dieses Argon2id).

Wie geschrieben: Arch nutzt das, was der Installateur bei der Installation eingerichtet hat. Hat er nichts eingerichtet, dann wird die Default-Konfiguration des Upstreams genutzt – da ist nix Arch-Spezifisches bei, wie etwa bei Debian, wo die Maintainer auch mal einen Tarball vom Upstream in viele kleine Pakete zerlegen, und die Konfiguration z.T. erheblich von der Default-Config des Upstreams abweicht.

Bei Arch ging das schon vor 4 Jahren als ich mich mal mit diesem OS beschäftigt habe.

Allerdings kannst du bei diesem Punkt dein Debian genauso wie ein Arch einrichten, wenn dir so sein sollte. Wenn es über den Installer und manuell eingerichtete Partitionen nicht funktionieren sollte, dann bleibt immer noch debootstrap als Option, womit sich ein Debian-Grundsystem im Grunde fast wie ein Arch via pacstrap installieren lässt.

Eine weitere Option wäre, zunächst das System normal verschlüsselt, also ohne verschlüsseltes /boot, zu installieren, und die Verschlüsselung der Boot-Partition im Anschluss vorzunehmen.

[tobo]

Eine weitere Option wäre, zunächst das System normal verschlüsselt, also ohne verschlüsseltes /boot, zu installieren, und die Verschlüsselung der Boot-Partition im Anschluss vorzunehmen.

Und ich dachte, das sei der "normale" Weg. Ich kenn' das gar nicht anders...

[frankm78]

Vielleicht gibt's ja zu diesem freischwebenden Grub noch weitergehende Informationen?

Grub liegt wahlweise auf dem MBR (Bios) oder in einer kleinen 100 MB EFI FAT32 (UEFI) Partition, enthält aber ausschließlich den Bootloader.

Eine weitere Option wäre, zunächst das System normal verschlüsselt, also ohne verschlüsseltes /boot, zu installieren, und die Verschlüsselung der Boot-Partition im Anschluss vorzunehmen.

Installiere immer zuerst das System, dann wird das mit fsarchiver gesichert, Partitionen verschlüsselt und anschließend manuell angepasst. Den Debian-Installer hab ich für Verschlüsselung noch nie benutzt, der macht mit mehr Probleme, als er Lösungen anbietet....

Da ihr euch alle immer irgendwie nur auf LUKS stürzt: wie wärs denn mit Absicherung der Disk über ein Passwort übers BIOS?

Anderer Ansatz auf Hardware-Ebene. Habe ich allerdings wenig Erfahrung mit - da ich aber diverse meiner eigenen Festplatten, die in einem alten RAID-System hier lagen, später mit einem überall veröffentlichten Master-Passwort entschlüsseln konnte, stehe ich dem eher skeptisch gegenüber. Ist zugegeben aber auch etwa 10 Jahre her...

[rhHeini]

Ich stecke fest. Folgendes in einer VBox-VM aufgesetzt:

32G GPT, P1 8Mib ohne Filesystem mit bios_grub-Flag, P2 der Rest.
12.5 netinstall, Expert-Mode, manuelle Partitionierung, das P2 als luks-Container eingerichtet, dadrin ein LVM mit 4 GiB für Swap und der Rest für / mit ext4. Ohne Spiegel.
grub-install scheitert beim ersten Versuch, wie in diesem Debian-Dokument beschrieben GRUB_ENABLE_CRYPTODISK=y in /target/etc/default grub eingetragen, der zweite Versuch funzt.
Erster Boot endet in "Invalid passphrase". Rescue-Mode gebootet und die Ableitung auf pbkdf2 umkonfiguriert: erneuter Boot akzeptiert jetzt das gesetzte Password.
sources.list auf Netzwerk umeditiert, apt update und apt upgrade.
In der VM überspringe ich erst mal die automatische Entschlüsselung von grub/boot.
Versuch die zweimalige Passwordeingabe laut Anleitung zu umgehen. Key generiert, dem Container zugewiesen, crypttab umeditiert auf das Schema "root_crypt UUID=… /etc/keys/root.key luks,discard,key-slot=n". Das update-initramfs gibt mir die Warning aus: "Skipping root-target root_crypt: uses a key-file"
Boote ich trotzdem, komme ich zwar über grub hinweg, ende aber in der initramfs-Konsole, Fehler: "Gave up waiting for root device"

Das verwendete Schema hab ich schon oft problemlos benutzt. Warum funzt das in diesem Falle nicht?

[tobo]

Vielleicht gibt's ja zu diesem freischwebenden Grub noch weitergehende Informationen?

Grub liegt wahlweise auf dem MBR (Bios) oder in einer kleinen 100 MB EFI FAT32 (UEFI) Partition, enthält aber ausschließlich den Bootloader.

Auf was du hinaus willst, ist mir bekannt - siehe Link in der ersten Antwort. Allerdings liegt nur der Stage1 von Grub2 im MBR. Das sind ~400 Bytes. Der Rest liegt womöglich teilweise direkt dahinter (post-MBR; Stage1.5) und der komplette Rest (~10MB) liegt dann verschlüsselt in /boot. Der unverschlüsselte Teil von Grub2 beträgt also <1% - ich würde somit nicht behaupten, dass Grub2 unverschlüselt ist.

[rhHeini]

Ich stecke fest. Folgendes in einer VBox-VM aufgesetzt:

.....

Das verwendete Schema hab ich schon oft problemlos benutzt. Warum funzt das in diesem Falle nicht?

Das Problem habe ich gelöst: war eigene Doofheit. Habe bisher Keyfiles immer nur für nachträglich einzuhängende Devices verwendet, nie für das root. Hab mich drauf verlassen das ich bisher keine weiteren Optionen benötigt habe, und es bei meiner Arch-Installation auch ohne ging.
Da muss tatsächlich eine Option in der /etc/cryptsetup-initramfs/conf-hook scharf geschaltet werden, ohne den glob KEYFILE_PATTERN="/etc/keys/*.key" wird der Key nicht in die initrd übernommen. Steht da richtig im Debian-Dokument drin.
Wie bin ich drauf gekommen? Nun, Lesen bildet. Manpages von cryptsetup, crypttab, die Arch- und Debian-Howto nochmals geflöht, und dann auch mal auf meinem Rechner in /etc abgetaucht und die Dateien aus dem Debian-HowTo gesucht und aufgemacht.

[rhHeini]

Die klassische FDE wie auch ich sie verwende benötigt ein unverschlüsseltes /boot. Und die Verschlüsselung geht mit luks2.

Da ihr euch alle immer irgendwie nur auf LUKS stürzt: wie wärs denn mit Absicherung der Disk über ein Passwort übers BIOS?

Geht eh am Thema vorbei.

Zusätzlich: dem Ansatz vertraue ich in keinster Weise. Dazu haben sich zu viele Akteure auf dem Markt mit grossen Versprechungen hervorgetan und bei Tests komplett und gründlich versagt.

[rhHeini]

@frankm78: Dein Post hat mich motiviert mich durchzubeissen, und ich hab jetzt eine VM mit Bookworm am laufen, eine verschlüsselte /-Partition inklusive /boot, ein PW für grub als Eingabe notwendig, startet dann den Rest=Desktop automatisch ohne weitere PW-Abfrage. Vielen Dank für Deinen Beitrag.

Und ich hab einen älteren PC im Keller benutzt um das Ganze auch mal mit Devuan Daedalus auszuprobieren und zu dokumentieren. Läuft auch, zusätzlich ein gesplittetes und verschlüsseltes /home (statische Daten (alles was Bilder, Dokumente, Downloads ... entspricht) und dynamische Daten (der Desktop, alle .-Dateien) in getrennten Partitionen) aufgesetzt mit automatischer Entschlüsselung gegen einen USB-Stick. Ohne den Stick geht gar nichts, grub startet dann ist aus.

Die letzte Herausforderung für mich ist jetzt auch den grub gegen so einem Key vom USB-Stick zu automatisieren. Dazu wurde mehrfach der folgende Abschnitt 17.4.18 cryptomount aus dem grub-Manual gepostet:
https://www.gnu.org/software/grub/manua ... ryptomount
Wenn ich das lese kommen mir auf Anhieb 2 Fragen in den Sinn:
1.) Ist das nicht ein Kommanda auf der grub-Konsole? Oder kann man das in /etc/default/grub spezifizieren?
2.) Wie adressiere ich eineindeutig so einen USB-Stick als Quelle in grub?

[cosinus]

Zusätzlich: dem Ansatz vertraue ich in keinster Weise. Dazu haben sich zu viele Akteure auf dem Markt mit grossen Versprechungen hervorgetan und bei Tests komplett und gründlich versagt.

Nein, es geht nicht am Thema vorbei, es ist eine Alternative. Aber hier im DFDE wollt ihr immer eine 200%-Lösung auch wenn die einfache Lösung, nämlich das Disk-Passwort, in den allermeisten Fällen schon ausreicht. Vllt mal dran denken, dass nicht hinter jedem der Mossad her ist.

[tobo]

@frankm78: Dein Post hat mich motiviert mich durchzubeissen, und ich hab jetzt eine VM mit Bookworm am laufen, eine verschlüsselte /-Partition inklusive /boot, ein PW für grub als Eingabe notwendig, startet dann den Rest=Desktop automatisch ohne weitere PW-Abfrage. Vielen Dank für Deinen Beitrag.

Und was genau war jetzt das Neue für dich in dem Beitrag? Die Keyfiles, damit man nur ein Passwort eingeben muss?