Arch Linux

GRUB cryptdevice Entschlüsselung via Keyfile?

DeusKult

Hallo,

Ich bin gerade beim Wechsel auf eine neues Gerät und versuche wie immer Grub mit verschlüsselter Boot Partition einzurichten.
Das Entsperren der /boot partition via keyfile funktioniert korrekt.
Beim Entsperren von der Disk mit root und swap brauche ich aber dennoch immer mein Passwort obwohl das Keyfile korrekt ist.

Meine Partitionen (entsprechen im Prinzip den Vorgaben des Arch Wiki):

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 200M 0 part
│ └─cryptboot 254:3 0 198M 0 crypt /boot
└─nvme0n1p3 259:3 0 476,2G 0 part
└─lvm 254:0 0 476,2G 0 crypt
├─vg0-swap 254:1 0 64G 0 lvm [SWAP]
└─vg0-root 254:2 0 412,2G 0 lvm /

blkid:

/dev/nvme0n1p1: UUID="702B-5CF3" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="ad68bb99-7101-4623-b3f3-a98e242bc522"
/dev/nvme0n1p2: UUID="50edd581-0b39-4ff0-acd3-d4c6d6227166" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="29b20931-4222-4075-9621-953b6e40d545"
/dev/nvme0n1p3: UUID="6916f41f-436a-4eb4-8851-a88c30a4b084" TYPE="crypto_LUKS" PARTLABEL="Linux LVM" PARTUUID="8368cff2-21b8-46bc-b164-3d776ab15df8"
/dev/mapper/lvm: UUID="r2U7Dv-YyaX-mrfA-L3hY-dHSF-5U2G-mSOtO9" TYPE="LVM2_member"
/dev/mapper/vg0-swap: UUID="b782b74b-5c34-4161-8fb8-f0588d28970c" TYPE="swap"
/dev/mapper/vg0-root: UUID="b268e2bd-2364-42f2-80cd-4582002a7d75" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/cryptboot: UUID="1acc5485-11a2-4a9f-ac89-1631b8070a33" BLOCK_SIZE="1024" TYPE="ext2"

/etc/mkinitcpio.conf Hooks & Files:

HOOKS=(base udev autodetect keyboard keymap modconf block encrypt lvm2 resume filesystems fsck)
FILES=(/crypto_keyfile.bin)

/etc/default/grub:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=6916f41f-436a-4eb4-8851-a88c30a4b084:lvm resume=/dev/mapper/vg0-swap"
GRUB_PRELOAD_MODULES="part_gpt part_msdos"
GRUB_ENABLE_CRYPTODISK=y

Das Keyfile /crypto_keyfile.bin funktioniert korrekt:

cryptsetup luksDump /dev/nvme0n1p3
LUKS header information for /dev/nvme0n1p3

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: c5 99 70 f0 75 31 a6 1e 49 7e 3c 74 5c d7 01 bc 0e 4e c7 2e
MK salt: 9e 3c 24 5c 15 8c fd 34 1c f3 c6 15 24 48 56 51
fe 30 4b b3 9e 95 9f 1c b1 2a a6 91 e5 08 b7 03
MK iterations: 116404
UUID: 6916f41f-436a-4eb4-8851-a88c30a4b084

Key Slot 0: ENABLED
Iterations: 1916956
Salt: 46 01 ae 6c 3d e2 ec 4d 36 29 46 9a 61 1e 6f e7
5d 91 1d 43 19 13 fd f2 c7 6f bb 10 9a 34 12 18
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 2036068
Salt: cf 2a 2b 50 9a e0 b8 65 4b df 85 2b e6 52 1f 82
81 fe 7a d2 d3 1b ab 61 ab f2 ab 88 4f 4b c8 dd
Key material offset: 512
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

cryptsetup --verbose open --key-file /crypto_keyfile.bin --test-passphrase /dev/nvme0n1p3
Schlüsselfach 1 entsperrt.
Befehl erfolgreich.

Das Keyfile ist im initramfs vorhanden:

zcat /boot/initramfs-5.4-x86_64.img | cpio -idmv
....
....
/crypto_keyfile.bin
....
....

und der Inhalt von /etc/crypttab:

cryptboot /dev/nvme0n1p2 /etc/key luks

Was ich bereits (erfolglos) getestet habe:
- FILES in mkinitcpio.conf in anderer Syntax angeben, also FILES=("/crypto_keyfile.bin") und FILES="/crypto_keyfile.bin"
- Cryptkey in GRUB explizit angeben:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=6916f41f-436a-4eb4-8851-a88c30a4b084:lvm cryptkey=rootfs:/crypto_keyfile.bin resume=/dev/mapper/vg0-swap"

- Neues Keyfile erstellen
- nvm1n0p3, lvm bzw. vg-0 in das crypttab eintragen.

Leider komme ich einfach nicht darauf warum es nicht klappt, inbesondere weil diese Config exakt so auf meinem alten Gerät ohne Probleme funktioniert?

frostschutz

Wie sieht die Meldung beim Booten genau aus?

Invalid keyfile. Reverting to passphrase.

A password is required to access the /dev/nvme0n1p3 volume:

Bei "Invalid keyfile" ist der Key im Initramfs doch falsch. Kommt die Meldung erst gar nicht, ist der Key doch nicht vorhanden.

Oder es wurde per Bootparameter ein anderer Dateiname fürs Keyfile angegeben.

Es gab in letzter Zeit auch ein paar Fälle wo nvme Device im Initramfs ganz gefehlt hat aber wenn die manuelle Eingabe funktioniert, dann ist das nicht dein Problem.

DeusKult

frostschutz schriebWie sieht die Meldung beim Booten genau aus?

Leider kommt gar kein Error.
Ich bekomme die Passwortabfrage für hd0.gpt2, gebe mein Passwort ein und direkt im Anschluss ist deine Passwortabfrage für hd0.gpt3 - Sobald ich die Partition entsperre funktioniert korrekt der grub boot ohne Fehler.
Es wirkt wie wenn nie probiert werden würde per Keyfile zu entschlüsseln.

frostschutz

Fehler den ich auch übersehe oder falsche/alte Datei geladen im Grub?

Im Grub Menü den Booteintrag editieren, die UUID verändern (so daß sie falsch ist), da solltest du dann auf der Initramfs Shell landen und schauen können ob /crypto_keyfile.bin existiert und ob --test-passphrase klappt.

DeusKult

Jetzt bin ich noch verwirrter als zuvor...

Zuerst wollte ich nur durch eingeben eines falschen Passwortes bei der Abfrage nach hd1.gpt3 in die grub rescue shell kommen.

Zu meiner Verwunderung spielt es absolut keine Rolle was ich eingebe, die Disk wird immer entsperrt (auch wenn dies sehr lange dauert - vermeintlich über das Key-file). Selbst ein einfaches Enter reicht aus und mein System bootet.

Daraufhin dachte ich das es evtl. ein Problem damit gibt das das Passwort im LUKS Key Slot 0 und der Key im Key-Slot 1 ist.
Deshalb habe ich das getauscht - dies brachte aber auch keine Veränderung.
-> Es wird immer ein Passwort abgefragt aber egal was ich eingebe es wird korrekt via Key-File entschlüsselt.

Daraufhin habe ich probiert bei der ersten Passwortabfrage für hd1.gpt2 das falsche Passwort einzugeben und bin so in die grub rescue shell gekommen. Hier habe ich dann versucht die gpt3 Disk manuell zu unlocken -> Wie erwartet wird hier ein korrektes Passwort benötigt da zu diesem Zeitpunkt das Initramfs noch nicht mit /crypto_keyfile.bin vorhanden ist.

Im Anschluss habe ich neu gestartet und wie von Frostschutz empfohlen die UUID meiner cryptodisk in /etc/default/grub verändert auf beliebige Zahlen.

Nach einem Grub Update habe ich neugestartet und ich hatte wieder die Situation das ich 2 Passwortabfragen hatte wobei die zweite jeden input akzeptiert und gp3 entsperrte.

Nach dem entsperren scheiterte der encrypt hook aber daran die nicht vorhandene UUID zu finden und ich landet nach mehreren Fehlern in einer rootfs shell.

Von hier aus konnte ich meine grub config leider nicht reparieren und musste via USB und chroot das System fixen.

frostschutz

Der Key Slot ist egal, das ändert nur die Zeit wie lange es zum aufsperren dauert. Es wird ein Keyslot nach dem anderen durchprobiert, der am häufigsten genutzte Key sollte daher in Keyslot 0 liegen (alternativ kann man den gewünschten Keyslot bei cryptsetup open auch angeben, aber das macht das Initramfs nicht).

Wenn dein Key ein Zufallserzeugnis ist mit mehr als 128bit Entropie, dann kannst du theoretisch auch auf den Bruteforce-Schutz von LUKS verzichten und den Iter-Count für diesen Key auf 0 stellen.

Damit kannst du dann beim Bootprozess ~2 Sekunden einsparen, falls du Wert auf sowas legst.

Aber das ist ein Thema mit dem man sich auseinandersetzen kann, wenn alles andere funktioniert und da verstehe ich leider nicht, was bei dir passiert.

Du kannst das Debugging vom Initramfs hochfahren, z.B. /lib/initcpio/hooks/encrypt nach /etc/initcpio/hooks/encrypt kopieren und dort ein set -x hineinsetzen für Debugausgaben der Shell, oder eigene Debugmeldungen einbauen.

Ich vermute immer noch daß du irgendwie vom falschen Gerät / die falsche Datei bootest aber ist sehr schwierig einzuschätzen von der Ferne. Viel Glück.

PS: das /crypto_keyfile.bin nutze ich selbst auf einem Server, der sich damit selbst entschlüsselt, und das tut einwandfrei, also kanns am Hook selbst eigentlich nicht liegen... *kopfkratz*

Wenn du die Ursache findest :-) lass es uns wissen was los war

PPS:

Im Anschluss habe ich neu gestartet und wie von Frostschutz empfohlen die UUID meiner cryptodisk in /etc/default/grub verändert auf beliebige Zahlen.

Hier dachte ich nebenbei eher daran das im Grub Menü zu editieren. Der Grub hat ja einen Editor mit dem du die Parameter live ändern kannst, und beim nächsten Reboot ist es dann wieder normal. So kannst du auch verschiedene Dinge durchprobieren ohne jedesmal wieder zurück über LiveCD/Chroot gehen zu müssen.

DeusKult

frostschutz schrieb Du kannst das Debugging vom Initramfs hochfahren, z.B. /lib/initcpio/hooks/encrypt nach /etc/initcpio/hooks/encrypt kopieren und dort ein set -x hineinsetzen für Debugausgaben der Shell, oder eigene Debugmeldungen einbauen.

Hätte ich probiert und danach das initramfs neu erstellt sowie grub neu installiert.
Leider kommt der output des encrypt hooks aber erst NACH den beiden Passwort abfragen.

ebenso habe ich probiert via

GRUB_CMDLINE_LINUX_DEFAULT="rd.debug debug ......."

mehr Informationen zu bekommen aber hier ist es das selbe das ich erst nach den 2 Passwort abfragen mehr debugging Output bekomme.

Bis dato habe ich leider noch keine Möglichkeit gefunden mir mehr Informationen zu besorgen was genau passiert während ich die 2 Passwörter eingeben muss.

frostschutz

Ah so. Dann hab ich dich irgendwie falsch verstanden.

Also wenn die Passwortabfrage *nicht* `A password is required to access the /dev/nvme0n1p3 volume:` ist.

Sondern du da Passwörter für hd0.* eingibst. Dann ist das ganz alleine Grub. Dann hast du im Initramfs und mit dem ganzen Rest gar kein Problem. Das hat dann auch nichts mit dem Hook oder Kernelparametern zu tun, sondern Grub selber.

Wenn /boot verschlüsselt ist dann muss Grub ja nach dem Passwort für /boot fragen. Das Passwort für / root sollte da nicht notwendig sein, wenn das auch gefragt wird dann ist das was bei Grub falsch konfiguriert.

Da kanns schlimmstenfalls sein daß du nochmal ein grub-install machen musst damit gecheckt wird daß nur /boot notwendig ist oder irgendwas anderes ist verquer mit der Config selbst daß da doch auch unbeteiligte Devices durchsucht werden.

z.B. der search-Befehl von Grub will ja alle Partitionen durchgehen. Evtl. sucht Grub so auch nach UUIDs und läuft dann in den Crypt Container rein.

Kommt dann drauf an was in grub.cfg steht

Gerry_Ghetto

Ich verstehe dein Setup nicht.
Du hast einen LUKS-Container für /boot und einen LUKS-Container für den Rest? Für mich sieht es jedenfalls so aus.

DeusKult schrieb Das Entsperren der /boot partition via keyfile funktioniert korrekt.

Kann man schlecht sagen, da du nur die Ausgabe zeigst, bei der du den LUKS-Container mit dem Wurzelverzeichnis entsperrst.

Mit welchem Keyfile versuchst du den LUKS-Container mit /boot zu entsperren? Benutzt du das gleiche Keyfile für beide LUKS-Container?

Meinem Verständnis nach müsste der LUKS-Container mit /boot von GRUB mittels Passphrase oder einem separaten Keyfile, das vielleicht auf einem USB-Stick liegt, geöffnet werden.
Anschliessend lädt Grub das initramfs, das dann mit dem Keyfile im initramfs den LUKS-Container mit dem Wurzelverzeichnis öffnet. Dann müsste das System aber den LUKS-Container mit /boot nochmals öffnen, weil er ja nur von GRUB geöffnet wurde.

DeusKult schriebMeine Partitionen (entsprechen im Prinzip den Vorgaben des Arch Wiki)

Ja, aber nur im Prinzip. Im verlinkten Wiki hast du nur eine ESP und einen LUKS-Container, der alles enthält. Da ist keine separate /boot-Partition in einem separaten LUKS-Container. Und ich sehe den Sinn dahinter nicht, weswegen man bei diesem Setup eine separate /boot-Partition brauchen würde.

Bei meinem Setup habe ich eine unverschlüsselte ESP (/boot/efi) und einen LUKS-Container mit LVM, der eine Swap und Archlinux enthält. Das funktioniert bis jetzt einwandfrei.

DeusKult

frostschutz schrieb
z.B. der search-Befehl von Grub will ja alle Partitionen durchgehen. Evtl. sucht Grub so auch nach UUIDs und läuft dann in den Crypt Container rein.

Kommt dann drauf an was in grub.cfg steht

grub.cfg war der entscheidende Hinweis zur Lösung!
Der Fehler war simpel aber erklärt im Nachhinein die "Symptome".

Und zwar war im 00-Header Bereich der Grub.cfg der Part welcher den cryptomount regelt doppelt vorhanden also grob:

....
insmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u 6916f41f436a4eb48851a88c30a4b084
set root='lvmid/PR48Wt-34KN-mOQB-BbFy-DgrQ-VN3E-UTwZeC/2CPwuV-7vJI-bI4K-4InD-LI>
if [ x$feature_platform_search_hint = xy ]; then
.....
nsmod gcry_sha256
insmod lvm
insmod ext2
cryptomount -u 6916f41f436a4eb48851a88c30a4b084
set root='lvmid/PR48Wt-34KN-mOQB-BbFy-DgrQ-VN3E-UTwZeC/2CPwuV-7vJI-bI4K-4InD-LI>
if [ x$feature_platform_search_hint = xy ]; then
.....

Ich verstehe noch nicht ganz wie das passieren konnte da ich die grub.cfg eigentlich auch merhfach neu erstellt habe aber nachdem ich grub einmal komplett entfernt habe und neu installiert habe sowie in /etc/default/grub nur das nötigste eingefügt habe, ist der Eintrag jetzt korrekt nur mehr einmal vorhanden.

Das erklärt auch warum ich beim zweiten mal kein Passwort mehr zum entsperren gebraucht habe aber trotzdem der Prompt zur Eingabe kam -> das Laufwerk war bereits unlocked!

Danke vielmals für den Denkanstoß!

Gerry_Ghetto schriebIch verstehe dein Setup nicht.
Du hast einen LUKS-Container für /boot und einen LUKS-Container für den Rest? Für mich sieht es jedenfalls so aus.

Das habe ich evtl etwas missverständlich beschrieben.

Ich habe 3 Partitionen auf nvme0n1:
nvme0n1p1 - unverschlüsselte ESP - gemountet unter /boot/efi
nvme0n1p2 - LUKS Boot Partition - gemountet unter /boot
nvme0n1p3 - LUKS on LVM - Enthält unter vg0-root den root und vg0-swap die Swap Partition

Die erste Eingabe des PW entsperrt die Boot Partition auf nvme0n1p2 welche wiederum dann per Keyfile nvme0n1p3 als cryptodisk entsperrt.

"/boot per keyfile entsperren" bezieht sich auf meinen Crypttab welcher einen Key für die Boot Partition hinterlegt hat und so beim Boot "entsperrt" und unter root gemounted wird.