Provided by: manpages-de_4.13-4_all 
BEZEICHNUNG
systemd-cryptenroll - PKCS#11-, FIDO2-, TPM2-Token/-Geräte bei LUKS2-verschlüsselten Datenträgern
registrieren
ÜBERSICHT
systemd-cryptenroll [OPTIONEN…] [GERÄT]
BESCHREIBUNG
systemd-cryptenroll ist ein Werkzeug zum Registrieren von Hardware-Sicherheits-Token und -Geräten an
LUKS2-verschlüsselten Datenträgern, die dann zum Entsperren des Datenträgers während des Systemstarts
verwandt werden können. Es unterstützt insbesondere die Registrierung von Token und Anmeldedaten von
folgenden Typen:
1. PKCS#11-Sicherheits-Token und -Smartcards, die ein RSA-Schlüsselpaar transportieren (z.B.
verschiedene YubiKeys).
2. FIDO2-Sicherheits-Token, die die Erweiterung »hmac-secret« implementieren (die meisten
FIDO2-Schlüssel, einschließlich YubiKeys)
3. TPM2-Sicherheitsgeräte
4. Reguläre Passphrasen
5. Rettungsschlüssel. Diese entsprechen regulären Ausdrücken, werden allerdings zufällig auf dem
Computer erstellt und haben daher im Allgemeinen eine höhere Entropie als vom Benutzer ausgewählte
Passphrasen. Ihr Zeichensatz wurde entwickelt, um sicherzustellen, dass sie leicht einzutippen sind
und weiterhin eine hohe Entropie haben. Sie können von dem Bildschirm auch mittels eines QR-Codes
eingelesen werden. Rettungsschlüssel können zum Entsperren von LUKS2-Datenträgern verwandt werden,
wann immer Passphrasen akzeptiert werden. Sie sind dazu gedacht, in Kombination mit einem
registrierten Hardware-Sicherheits-Token als Rettungsoption verwandt zu werden, wenn der Token
verloren geht.
Das Werkzeug kann zusätzlich zum Aufzählen derzeit registrierter Sicherheits-Token und dem Löschen einer
Teilmenge von ihnen verwandt werden. Letzteres kann mit der Registrieraktion eines neuen
Sicherheits-Token kombiniert werden, um Registrierungen zu aktualisieren oder zu ersetzen.
Das Werkzeug unterstützt nur LUKS2-Datenträger, da es die Metainformationen des Tokens in dem
LUKS2-JSON-Token-Bereich speichert, der bei anderen Verschlüsselungsformaten nicht vorhanden ist.
EINSCHRÄNKUNGEN
Beachten Sie, dass es notwendig ist, wenn ein neuer Schlüssel von einer der fünf oben aufgeführten
unterstützten Typen registriert wird, zuerst eine Passphrase oder einen Wiederherstellungsschlüssel
bereitzustellen (d.h. einen der letzteren beiden Schlüsseltypen). Beispielsweise ist es derzeit nicht
möglich, ein Gerät mit einem FIDO2-Schlüssel zu entsperren, um einen neuen FIDO2-Schlüssel zu
registrieren. Um einen neuen FIDO2-Schlüssel zu registrieren, ist es daher notwendig, eine breits
registrierte Passphrase oder einen Wiederherstellungsschlüssel bereitzustellen. Falls daher in der
Zukunft ein Schlüsselwechsel gewünscht ist, wird im Allgemeinen empfohlen, TPM2-, FIDO2-,
PKCS#11-Schlüsselregistrierung mit derRegistrierung einer regulären Passphrase oder eines
Wiederherstellungsschlüssels zu kombinieren.
Beachten Sie auch, dass die Registrierung mehrerer FIDO2-Token derzeit nicht sehr nützlich ist, da beim
Entsperren systemd-cryptsetup nicht identifizieren kann, welcher Token derzeit eingesteckt ist und daher
nicht weiß, welche Authentifizierungsanfrage zu dem Gerät gesandt werden soll. Diese Beschränkung
betrifft Token nicht, die mit PKCS#11 registriert wurden, da Token dieser Art sofort (vor der
Authentifizierung) identifiziert werden können.
OPTIONEN
Die folgenden Optionen werden verstanden:
--password
Registriert ein reguläres Passwort/eine reguläre Passphrase. Dieser Befehl entspricht größtenteils
cryptsetup luksAddKey, allerdings in Kombination mit --wipe-slot= in einem Aufruf, siehe unten.
--recovery-key
Registriert einen Rettungsschlüssel. Rettungsschlüssel sind größtenteils identisch zu Passphrasen,
sind aber Computer-generiert statt durch Menschen ausgewählt und haben daher eine höhere garantierte
Entropie. Die Schlüssel verwenden einen Zeichensatz, der leicht einzugeben ist und vom Bildschirm
mittels eines QR-Codes eingelesen werden kann.
--pkcs11-token-uri=URI
Registriert einen PKCS#11-Sicherheits-Token oder eine Smartcard (z.B. einen YubiKey). Erwartet eine
PKCS#11-Smartcard-URI, die sich auf den Token bezieht. Alternativ kann der besondere Wert »auto«
angegeben werden, um automatisch die URI des aktuell eingesteckten Sicherheits-Tokens zu bestimmen
(davon darf es nur genau einen geben). Der besondere Wert »list« kann zum Aufzählen aller derzeit
eingesteckten geeigneten PKCS#11-Token verwandt werden. Der Sicherheits-Token muss ein
RSA-Schlüsselpaar enthalten, das zum Verschlüsseln des zufällig erstellten Schlüssels verwandt wird,
der zum Entsperren des LUKS2-Datenträgers eingesetzt wird. Der verschlüsselte Schlüssel wird dann in
dem LUKS2-JSON-Token-Kopfzeilenbereich gespeichert.
Um einen LUKS2-Datenträger mit einem registrierten PKCS#11-Sicherheits-Token zu entsperren, legen Sie
die Option pkcs11-uri= in der zutreffenden Zeile in /etc/crypttab fest:
meindatenträger /dev/sda1 - pkcs11-uri=auto
Siehe crypttab(5) für ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der
zugehörigen Zeile in /etc/crypttab.
--fido2-device=PFAD
Registriert einen FIDO2-Sicherheits-Token, der die Erweiterung »hmac-secret« implementiert (z.B.
einen YubiKey). Erwartet ein Hidraw-Gerät, das sich auf ein FIDO2-Gerät bezieht (z.B. /dev/hidraw1).
Alternativ kann der besondere Wert »auto« angegeben werden, um automatisch den Geräteknoten des
aktuell eingesteckten Sicherheits-Tokens zu bestimmen (davon darf es nur genau einen geben). Der
besondere Wert »list« kann zum Aufzählen aller derzeit eingesteckten geeigneten FIDO2-Token verwandt
werden. Beachten Sie, dass viele Hardware-Sicherheits-Token, die FIDO2 implementieren, ebenfalls den
älteren PKCS#11-Standard implementieren. Typischerweise sollte FIDO2 bevorzugt werden, da es leichter
zu verwenden und moderner ist.
Um einen LUKS2-Datenträger mit einem registrierten FIDO2-Sicherheits-Token zu entsperren, legen Sie
die Option fido2-device= in der zutreffenden Zeile in /etc/crypttab fest:
meindatenträger /dev/sda1 - fido2-device=auto
Siehe crypttab(5) für ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der
zugehörigen Zeile in /etc/crypttab.
--fido2-with-client-pin=LOGISCH
Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer eine PIN beim Entsperren
des Datenträgers eingeben muss (die FIDO2-Funktionalität »clientPin«). Standardmäßig »yes«. (Beachten
Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalität »clientPin«
überhaupt nicht unterstützt oder das Aktivieren oder Deaktivieren nicht erlaubt.)
--fido2-with-user-presence=LOGISCH
Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer seine Anwesenheit beim
Entsperren des Datenträgers nachweisen muss (die FIDO2-Funktionalität »up«). Standardmäßig »yes«.
(Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalität »up«
überhaupt nicht unterstützt oder das Aktivieren oder Deaktivieren nicht erlaubt.)
--fido2-with-user-verification=LOGISCH
Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer beim Entsperren des
Datenträgers überprüft werden muss (die FIDO2-Funktionalität »uv«). Standardmäßig »no«. (Beachten
Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalität »uv« überhaupt
nicht unterstützt oder das Aktivieren oder Deaktivieren nicht erlaubt.)
--tpm2-device=PFAD
Registriert einen TPM2-Sicherheits-Chip. Erwartet einen Geräteknotenpfad, der sich auf einen
TPM2-Chip bezieht (z.B. /dev/tpmrm0). Alternativ kann der besondere Wert »auto« angegeben werden, um
automatisch den Geräteknoten des aktuell ermittelten TPM2-Geräts zu bestimmen (davon darf es nur
genau einen geben). Der besondere Wert »list« kann zum Aufzählen aller derzeit eingesteckten
geeigneten TPM2-Chips verwandt werden.
Um einen LUKS2-Datenträger mit einem registrierten TPM2-Sicherheits-Chip zu entsperren, legen Sie die
Option tpm2-device= in der zutreffenden Zeile in /etc/crypttab fest:
meindatenträger /dev/sda1 - tpm2-device=auto
Siehe crypttab(5) für ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der
zugehörigen Zeile in /etc/crypttab.
Verwenden Sie --tpm2-pcrs= (siehe unten), um zu konfigurieren, an welchen TPM2-PCR-Index die
Registrierung angebunden werden soll.
--tpm2-pcrs= [PCR…]
Konfiguriert die TPM2 PCRs (Plattform-Konfigurationsregister), an die die mittels --tpm2-device=
erbetene Registrierung angebunden werden soll. Akzeptiert eine durch »+« getrennte Liste von
numerischen PCR-Indices im Bereich 0…23. Falls nicht verwandt, wird standardmäßig nur PCR 7 verwandt.
Falls eine leere Zeichenkette festgelegt ist, wird die Registrierung an überhaupt keine PCRs
gebunden. PCRs erlauben das Anbinden der Registrierung an bestimmte Softwareversionen und an den
Systemzustand, so dass der registrierte Entsperrschlüssel nur zugreifbar ist (kann »entsiegelt
werden«), falls die festgelegte vertrauenswürdige Software und/oder Konfiguration verwandt wird.
Tabelle 1. Gut-bekannte PCR-Definitionen
┌─────┬──────────────────────────────────────────────┐
│ PCR │ Erklärung │
├─────┼──────────────────────────────────────────────┤
│ 0 │ Ausführbarer Code der │
│ │ Kernsystem-Firmware; ändert sich bei │
│ │ Firmware-Aktualisierungen │
├─────┼──────────────────────────────────────────────┤
│ 1 │ Konfiguration der │
│ │ Kernsystem-Firmware-Daten/Rechner-Plattform; │
│ │ enthält typischerweise die Serien- │
│ │ und Modellnummer, ändert sich beim │
│ │ Austausch grundlegender │
│ │ Hardware-/CPU-/RAM-Komponenten │
├─────┼──────────────────────────────────────────────┤
│ 2 │ Erweiterter oder austauschbarer ausführbarer │
│ │ Code; einschließlich Options-ROMs und │
│ │ austauschbarer Hardware │
├─────┼──────────────────────────────────────────────┤
│ 3 │ Erweiterte oder austauschbare │
│ │ Firmware-Daten; einschließlich Informationen │
│ │ über austauschbare Hardware │
├─────┼──────────────────────────────────────────────┤
│ 4 │ Boot-Lader: ändert sich bei Änderungen am │
│ │ Systemstartprogramm. Das Shim-Projekt wird │
│ │ das PE-Programm, das es als nächstes in der │
│ │ Kette lädt, in dieses PCR einmessen. │
├─────┼──────────────────────────────────────────────┤
│ 5 │ GPT-/Partitionstabelle; ändert sich, wenn │
│ │ Partitionen hinzugefügt, verändert oder │
│ │ entfernt werden │
├─────┼──────────────────────────────────────────────┤
│ 6 │ Leistungszustandsereignisse; ändern sich │
│ │ beim Suspendieren/Schlafen des Systems │
├─────┼──────────────────────────────────────────────┤
│ 7 │ Sicherer Systemstartzustand; ändert sich, │
│ │ wenn der UEFI-SecureBoot-Modus │
│ │ aktiviert/deaktiviert wird oder sich │
│ │ Firmware-Zertifikate (PK, KEK, db, dbx, …) │
│ │ ändern. Das Shim-Projekt wird die meisten │
│ │ (nicht MOK-) Zertifikate und SBAT-Daten in │
│ │ dieses PCR einmessen. │
├─────┼──────────────────────────────────────────────┤
│ 8 │ sd-boot(7) misst die Kernelbefehlszeile in │
│ │ diesen PCR. │
├─────┼──────────────────────────────────────────────┤
│ 10 │ Das IMA-Projekt misst seinen Laufzeitzustand │
│ │ in dieses PCR. │
├─────┼──────────────────────────────────────────────┤
│ 14 │ Das Shim-Projekt misst seine │
│ │ »MOK«-Zertifikate und -Hashes in dieses PCR. │
└─────┴──────────────────────────────────────────────┘
Für die meisten Anwendungen sollte es ausreichen, sich gegen PCR 7 zu binden (und möglicherweise PCR
14, falls Shim/MOK gewünscht ist), da dies die Messung zuverlässiger Zertifikate (und möglicherweise
Hashes) einschließt, die zum Validieren aller Komponenten des Systemstartprozesses bis hin (und
einschließlich) des Betriebssystemkerns verwandt werden. Um Firmware- und
Betriebssystemaktualisierungen zu vereinfachen, ist es typischerweise nicht empfehlenswert, PCRs wie
0 und 2 in das Einbinden bei der Registrierung aufzunehmen, da der von ihnen abgedeckte Programm-Code
bereits indirekt über die in PCR 7 eingemessenen Zertifikate geschützt sein sollte. Prüfung über
diese Zertifikate ist typischerweise gegenüber der Validierung über direkte Messung zu bevorzugen, da
es im Zusammenhang mit Betriebssystem-/Firmware-Aktualisierungen weniger zerbrechlich ist: die
Messung ändert sich bei jeder Aktualisierung, aber Code-Signaturen werden sich wahrscheinlich auch
mit bereits existierenden Zertifikaten validieren.
--wipe-slot= [POSITION…]
Bereinigt einen oder mehrere LUKS2-Schlüsselpositionen. Akzeptiert eine Kommata-getrennte Liste von
numerischen Positionsindices oder die besondere Zeichenkette »all« (um alle Schlüsselpositionen zu
bereinigen), »empty« (um alle Schlüsselpositionen zu bereinigen, die mit einer leeren Passphrase
entsperrt sind), »password« (um alle Schlüsselpositionen zu bereinigen, die mit einer traditionellen
Passphrase entsperrt sind), »recovery« (um alle Schlüsselpositionen zu bereinigen, die mit einem
Wiederherstellungsschlüssel entsperrt sind), »pkcs11« (um alle Schlüsselpositionen zu bereinigen, die
mit einem PKCS#11-Token entsperrt sind), »fido2« (um alle Schlüsselpositionen zu bereinigen, die mit
einem Fido2-Token entsperrt sind), »tpm2« (um alle Schlüsselpositionen zu bereinigen, die mit einem
TPM2-Chip entsperrt sind) oder jede Kombination dieser Zeichenketten oder numerischen Indices,
wodurch dann alle Positionen, die auf einen davon passen, bereinigt werden. Als Vorsichtsmaßnahme
wird eine Aktion, die alle Positionen ohne Ausnahme bereinigt (so dass der Datenträger überhaupt
nicht mehr entsperrt werden kann, außer der Datenträger-Schlüssel ist bekannt), abgelehnt.
Dieser Schalter kann alleine verwandt werden. In diesem Fall wird nur die angefragte
Bereinigungsaktion ausgeführt. Er kann auch in Kombination mit einer der oben aufgeführten
Registrierungsoptionen verwandt werden. In diesem Fall wird zuerst die Registrierung abgeschlossen
und nur wenn das erfolgreich war, wird die Bereinigungsaktion ausgeführt — und die frisch
hinzugefügte Position wird immer von der Bereinigung ausgeschlossen. Die Kombination von
Registrierung und Positionsbereinigung kann daher zur Aktualisierung bestehender Registrierungen
verwandt werden:
systemd-cryptenroll /dev/sda1 --wipe-slot=tpm2 --tpm2-device=auto
Der obige Befehl wird den TPM2-Chip registrieren und dann alle vorher erstellten TPM2-Registrierungen
auf dem LUKS2-Datenträger bereinigen, wodurch nur die frisch erstellte verbleibt. Die Kombination von
Bereinigung und Registrierung kann auch zum Ersetzen der Registrierung von verschiedenen Typen
verwandt werden, beispielsweise zum Ändern einer PKCS#11-Registrierung auf eine FIDO2-Registrierung:
systemd-cryptenroll /dev/sda1 --wipe-slot=pkcs11 --fido2-device=auto
Oder zum Ersetzen eines registrierten leeren Passworts durch TPM2:
systemd-cryptenroll /dev/sda1 --wipe-slot=empty --tpm2-device=auto
-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.
--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.
EXIT-STATUS
Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.
SIEHE AUCH
systemd(1), systemd-cryptsetup@.service(8), crypttab(5), cryptsetup(8)
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
Mailingliste der Übersetzer.
systemd 250 SYSTEMD-CRYPTENROLL(1)