V for Vortex hat geschrieben:
▶ System_verschlüsseln
Wenn man es per Keyfile auf einem USB-Stick macht, sollte man nicht dessen /dev-Namen nehmen (der sich ändern kann), sondern seine UUID. Dazu darf er dann natürlich nicht mit FAT formatiert sein, da FAT keine UUID hat.
- Wenn ich meine fat-formatierte usb-sticks mit blkid untersuche, haben die alle eine UUID, auch wenn die recht kurz ist. Und sie ist jedesmal anders. Woher kommt das?
- Statt UUID kann er aber sehr wohl /dev-namen nehme. Ich schlage /dev/disk/by-id/.... vor.
- keyfile nützt ja gerade nix - das geht ja erstmal nur unverschlüsselt, wie karl_k richtig schreibt. Und woher sollte cryptsetup wissen, dass es erst irgend einen Stick mounten muss, um an das keyfile zu kommen?
Es ist Handarbeit nötig. Hier eine kurze Anleitung - es wurde ja schon häufiger angefragt und nie beantwortet.
(Ich gehe davon aus, dass ihr euer System per Alternate-CD verschlüsselt habt, mit den Default-Optionen.
Es gibt (noch) eine Boot-Partition und /dev/sda5 ist euer verschlüsseltes LVM. Es wird aber wahrscheinlich auch mit der Anleitung aus dem Wiki funktionieren. Statt /dev/sda5 müsst ihr dann euer Root-Partition nehmen und die Befehle entsprechend anpassen.)
Die Schwierigkeit ist also Folgende: cryptsetup unterstützt von Hause aus nur Passwörter oder unverschlüsselte Keyfiles. Er soll aber beides nötig sein: keyfile und Passwort. Mit der debian spezifischen crypttab-Datei ist das möglich. Es gibt dort eine 'keyscript'-Option. Dort kann man ein Script eintragen, dass die Entschlüsselung des keyfiles übernimmt und an cryptsetup weiterreicht.
1) keyfile erstellen
Zuerst muss also ein normales keyfile für cryptsetup erstellt werden:
$ mkdir /etc/keys 2>/dev/null
$ dd if=/dev/urandom bs=128 count=1 of=/etc/keys/root
$ chown root:root /etc/keys/root
$ chmod 400 /etc/keys/root
$ cryptsetup luksAddKey /dev/sda5 /etc/keys/root
Jetzt wir das keyfile mit gpg symmetrisch verschlüsselt. Das bietet sich ja dafür an und bietet ausgefeilte Optionen zum Schutz vor Dictonary-Attacken:
$ gpg -c --cipher-algo AES256 --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 65011712 --force-mdc --digest-algo SHA512 -z 9 --compress-algo bzip2 /etc/keys/root
$ chown root:root /etc/keys/root.gpg
$ chmod 400 /etc/keys/root.gpg
/etc/keys/root.gpg müsst ihr jetzt auf euren USB-Stick kopieren (in das Root-Verzeichnis)
2) Keyscript erstellen
Jetzt erstellen wir ein keyscript (/etc/keys/mykeyscript.sh), dass während des Boot-Vorganges ausgeführt werden soll:
#!/bin/sh
STICK=/dev/disk/by-id/XXXXXX
FSTYPE=VFAT
slumber=150
while [ $slumber -gt 0 ] && [ ! -e "$STICK" ]; do
/bin/sleep 0.1
slumber=$(( $slumber - 1 ))
done
if ! mount -t $FSTYPE -r $STICK /mystick ; then
echo ''
exit 1
fi
# Wenn usplash läuft, kann usplash_write benutzt werden, um das Passwort per Pipe einzulesen
if [ -p /dev/.initramfs/usplash_outfifo ] && [ -x /sbin/usplash_write ]; then
usplash_write "INPUTQUIET Enter password to unlock $1: "
PASS="$(cat /dev/.initramfs/usplash_outfifo)"
else # das System wurde ohne usplash gestartet - Passwort mit read einlesen
echo "Bitte geben Sie ihr Passwort ein:" >&2
stty_orig=`stty -g </dev/console`
stty -echo </dev/console
read PASS </dev/console
stty $stty_orig </dev/console
fi
echo "$PASS" | /usr/bin/gpg -d --no-tty --no-options --passphrase-fd 0 --quiet --decrypt /mystick/${1}
umount /mystick
script sichern, und ausführbar machen
$ chown root:root /etc/keys/mykeyscript.sh
$ chmod 700 /etc/keys/mykeyscript.sh
Lediglich der Name des keyfiles wird als Parameter übergeben. Die zweite Zeile müsst ihr also per Hand anpassen. Die Adresse des USB-Sticks ( /dev/disk/by-id/XXXXXX ) und das darauf verwendete Dateisystem müsst euren Einstellungen gemäß ändern. Es ist wirklich nötig, dass ihr das Dateisystem explizit angebt, auch wenn ihr euch das im normalen Betrieb sparen könnt.
Falls ihr das Skript weiter ausbauen wollt, hier noch ein paar Hinweise:
- gpg kann das Passwort an dieser Stelle nicht selbst einlesen und muss zur Zusammenarbeit überredet werden. (z.B. mit 'no-tty' - dieser switch wird von der aktuellen manpage verschwiegen,....)
- dash kennt kein 'read -s' - daher muss man auch hier tricksen (z.B. mit stty,...),....
- der Stick muss auf jeden Fall ausgehängt ("ungemountet") werden, sonst bootet das System nicht.
So. An diesem Punkt empfehle ich euch ein Backup der Boot-Partition zu machen. Ihr müsst wissen, wie ihr das per Live-CD wieder einspielt. Sollte euer System das nächste mal nämlich nicht starten, müsst ihre von eurer alten Boot-Partition starten, alle folgende Änderungen zurücknehmen und eine neue initiale Ramdisk erstellen (update-initramfs -u ).
3) crypttab anpassen
Jetzt muss in der crypttab eingetragen werden, dass in Zukunft das keyfile und unser script zum Entschlüsseln verwendet werden soll.
alter Eintrag:
sda5_crypt /dev/disk/by-uuid/8ad4235b-c1a7-4842-b1f9-5db445f615cc none luks
neuer Eintrag (natürlich entsprechend eueren Systemeinstellungen anpassen):
sda5_crypt /dev/disk/by-uuid/8ad4235b-c1a7-4842-b1f9-5db445f615cc root.gpg luks,keyscript=/etc/keys/mykeyscript.sh
4)Hook - Script
Ein hook-script sorgt dafür, dass gpg und Co. in die initiale Ramdisk kopiert werden:
/etc/initramfs-tools/hooks/myhook
#!/bin/sh
PREREQ=''
prereqs()
{
echo "$PREREQ"
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
/bin/mkdir -p ${DESTDIR}/bin
/bin/mkdir -p ${DESTDIR}/usr/bin
/bin/mkdir -p ${DESTDIR}/mystick
/bin/mkdir -p ${DESTDIR}/.gnupg
touch ${DESTDIR}/.gnupg/pubring.gpg
touch ${DESTDIR}/.gnupg/secring.gpg
copy_exec /usr/bin/gpg /usr/bin
copy_exec /bin/stty /bin
Auch dieses script muss ausführbar gemacht werden:
$ chown root:root /etc/initramfs-tools/hooks/myhook
$ chmod 700 /etc/initramfs-tools/hooks/myhook
5) FAT auf eurem Stick....
Und ein letzter Punkt muss beachtet werden. Euer USB-Stick ist wahrscheinlich mit fat oder ähnlichem formatiert und der Kernel unterstützt dieses Dateisystem nur, wenn entsprechende Module vorhanden sind. Man muss also sicherstellen, dass die Module während des frühen Bootvorangens zugänglich sind. Dies erreicht man durch entsprechende Einträge in /etc/initramfs-tools/modules
# andere Einträge ..
# ...
# neu:
vfat
fat
nls_cp437
nls_iso8859_1
Welche Einträge genau nötig sind, hängt aber von dem Dateisystem des Sticks und der dort verwendeten Codierung ab. Möglicherweise sind bei eurem Stick andere Einträge nötig.
(Einfach mal ein Blick auf die Ausgabe von 'lsmod' werfen, wenn ihr gerade euren Stick gemountet habt, und nach Einträgen suchen, die nach *fat* oder *nls_* aussehen. Per google findet ihr dann raus, ob diese Module auch wirklich etwas damit zu tun haben,... )
So, jetzt der entscheidende Befehl, um die ganzen Änderungen zu aktivieren:
$ update-initramfs -u # erstellt eine neue, initiale Ramdisk
und jetzt euer System neustarten (der Stick muss eingesteckt sein, sonst wird das natürlich nix,....)
6) Altes luks Passwort entfernen
Wenn alles funktioniert hat, könnt ihr jetzt das alte Passwort eures luks-device zurücksetzen.
Momentan gibt es ja zwei Möglichkeiten euer System zu starten: Mit dem alten Luks-Passwort oder dem gpg-verschlüsseten keyfile und dem GPG-Passwort. Beim normalen Sysemstart funktioniert nur letzteres, von Live-CD aber beide.
$ cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: c9 9e ae 04 1d bc 89 2e 16 a5 d2 e4 05 24 7b da b4 85 bc 1c
MK salt: 24 fa 2b 89 c7 6e a5 ff 32 c7 9c bf 5f 49 fe dc
e8 50 30 d2 67 f5 e7 f2 2f ef 13 7e 0d 9d 62 52
MK iterations: 10
UUID: 8ad4235b-c1a7-4842-b1f9-5db445f615cc
Key Slot 0: ENABLED
Iterations: 425182
Salt: 4f 4b a3 6a 3f 42 62 6d 1e 48 a3 4a 6c fb 5d af
38 2a c9 68 09 46 8a 25 6d 99 de b4 b9 be 1e ac
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 414331
Salt: 74 e1 15 ce 87 0a ce 5d 59 0c 18 7c 8d 0f af 2d
c8 bc 13 7f ce 36 18 6d a4 c1 8f 0b 5b 49 ae 29
Key material offset: 264
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
Zwei Key Slots sind aktiv. 0 und 1. 0 ist wohl der ältere (es sei denn, ihr habt schon öfters mit luksAddKey und luksDelKey rumgespielt,...) - er wird gelöscht:
cryptsetup luksDelKey /dev/sda5 0 --key-file /etc/keys/root
jetzt ist das Passwort weg:
$ cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: c9 9e ae 04 1d bc 89 2e 16 a5 d2 e4 05 24 7b da b4 85 bc 1c
MK salt: 24 fa 2b 89 c7 6e a5 ff 32 c7 9c bf 5f 49 fe dc
e8 50 30 d2 67 f5 e7 f2 2f ef 13 7e 0d 9d 62 52
MK iterations: 10
UUID: 8ad4235b-c1a7-4842-b1f9-5db445f615cc
Key Slot 0: DISABLED
Key Slot 1: ENABLED
Iterations: 414331
Salt: 74 e1 15 ce 87 0a ce 5d 59 0c 18 7c 8d 0f af 2d
c8 bc 13 7f ce 36 18 6d a4 c1 8f 0b 5b 49 ae 29
Key material offset: 264
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
Tata! Euer keyfile sollte ihr gut sichern. Ein Backup auf einem weiteren Medium ist empfehlenswert.
7) Boot-Partition auf den gleichen (oder einen anderen) USB-Stick auslagern
Nein, dazu habe ich jetzt keine Lust mehr; genug geschrieben. Vielleicht morgen, vielleicht auch gar nicht,...
Alle Angaben ohne Gewähr. Wer scheiße baut, hat Pech gehabt. Ich hafte für nix 😉
[Skripte geändert]