Ich möchte die Root-Partition verschlüsseln und den Schlüssel mit TPM schützen. Schließlich möchte ich den Verschlüsselungsschlüssel an den Status der TPM-Register binden. Ich habe Fedora Workstation 38 eingerichtet. Während des Setup-Assistenten habe ich das Kontrollkästchen zum Verschlüsseln des Laufwerks aktiviert und eine Wiederherstellungsphrase eingegeben. Dies hat wie erwartet funktioniert. Während der Startphase wurde ich zur Eingabe einer Passphrase zum Entsperren des LUKS-Schlüssels aufgefordert. Unten sehen Sie die Ausgabe von lsblk -pf.
lsblk -pf
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
/dev/sr0
/dev/zram0 [SWAP]
/dev/vda
├─/dev/vda1
├─/dev/vda2 ext4 1.0 b8d2cbbf-0f44-4487-bccf-74d9365ec383 647M 27% /boot
└─/dev/vda3 crypto_LUKS 2 08ab0fc7-5a6b-421c-be8a-d6171761a3e6
└─/dev/mapper/luks-08ab0fc7-5a6b-421c-be8a-d6171761a3e6
btrfs fedora_localhost-live 09d81602-3093-4a76-8c56-d9562197cdb9 13.2G 27% /home
Als nächstes habe ich TPM registriert:
sudo systemd-cryptenroll --tpm2-device=auto /dev/vda3
New TPM2 token enrolled as key slot 1.
An diesem Punkt habe ich zwei Schlüsselslots: 0 – Passwort und 1 – TPM.
Als nächstes habe ich Folgendes aktualisiert /etc/crypttab:
luks-08ab0fc7-5a6b-421c-be8a-d6171761a3e6 UUID=08ab0fc7-5a6b-421c-be8a-d6171761a3e6 - tpm2-device=auto
Als nächstes habe ich systemd neu geladen systemctl daemon-reload, unten ist die aktualisierte Servicedatei.
sudo systemctl cat systemd-cryptsetup@luks\\x2d08ab0fc7\\x2d5a6b\\x2d421c\\x2dbe8a\\x2dd6171761a3e6.service
[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:[email protected](8)
SourcePath=/etc/crypttab
DefaultDependencies=no
IgnoreOnIsolate=true
After=cryptsetup-pre.target systemd-udevd-kernel.socket
Before=blockdev@dev-mapper-%i.target
Wants=blockdev@dev-mapper-%i.target
Conflicts=umount.target
Before=cryptsetup.target
BindsTo=dev-disk-by\x2duuid-08ab0fc7\x2d5a6b\x2d421c\x2dbe8a\x2dd6171761a3e6.device
After=dev-disk-by\x2duuid-08ab0fc7\x2d5a6b\x2d421c\x2dbe8a\x2dd6171761a3e6.device
Before=umount.target
[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
OOMScoreAdjust=500
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'luks-08ab0fc7-5a6b-421c-be8a-d6171761a3e6' '/dev/disk/by-uuid/08ab0fc7-5a6b-421c-be8a-d6171761a3e6' '-' 'tpm2-device=auto'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach 'luks-08ab0fc7-5a6b-421c-be8a-d6171761a3e6'
Ich habe mein System neugestartet und es war alles in Ordnung; ich habe trotzdem – wie erwartet – mein Passwort eingegeben.
Als nächstes habe ich das Passwort gelöscht:
sudo systemd-cryptenroll --wipe-slot=password /dev/vda3
wiped slot 0.
Beim Neustart tritt der folgende Fehler auf (Entschuldigung für den Screenshot).
Als ich den Dienst systemd-cryptsetup@luks.. untersuchte (nach dem Booten im Rettungsmodus), bemerkte ich, dass er ExecStartkeine TPM-Patameter mehr hatte:
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'luks-08ab0fc7-5a6b-421c-be8a-d6171761a3e6' '/dev/disk/by-uuid/08ab0fc7-5a6b-421c-be8a-d6171761a3e6' '' ''
Der systemctl statusDienst erzeugte die folgende Fehlermeldung: systemd-cryptsetup[630]; No passphrase or recovery key registered.
`
Ich habe das Problem gefunden, danke @u1686_grawity
Ich musste einen Schritt hinzufügen – dracut -fnachdem ein TPM-Steckplatz hinzugefügt wurde – dieser (glaube ich) hat den TSS-Treiber früh im Startvorgang geladen.
Antwort1
Ich habe das Problem gefunden, danke @u1686_grawity
Ich musste einen Schritt hinzufügen – dracut -fnachdem ein TPM-Steckplatz hinzugefügt wurde – dieser (glaube ich) hat den TSS-Treiber früh im Startvorgang geladen.