Provided by: manpages-de_4.15.0-9_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-credential-algorithm=ZEICHENKETTE
Gibt den bei der Erstellung von Zugangsberechtigungen zu verwendenen COSE-Algorithmus
an. Der Vorgabewert ist »es256«. Unterstützte Werte sind »es256«, »s256« und »eddsa«.
»es256« bezeichnet ECDSA über NIST P-256 mit SHA-256. »rs256« bezeichnet 2048-bit RSA
mit PKCS#1.5-Auffüllung und SHA-256. »eddsa« bezeichnet EDDSA über Curve25519 mit
SHA-512.
Beachten Sie, dass Ihr Authentikator nicht alle Algorithmen unterstützen könnte.
--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 │ Systemstartprogramm und zusätzliche Treiber; │
│ │ Änderungen an Systemstart-Aktualisierungen. │
│ │ Das Shim-Projekt wird das PE-Programm, das │
│ │ es in Folge lädt, in dieses PCR einmessen. │
│ │ Falls der Linux-Kernel als UEFI-PE-Programm │
│ │ aufgerufen wird, wird es hier auch │
│ │ eingemessen. sd-stub(7) misst vom ESP │
│ │ eingelesene Systemerweiterungs-Abbilder hier │
│ │ auch ein (siehe systemd-sysext(8)). │
├────┼──────────────────────────────────────────────┤
│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. │
├────┼──────────────────────────────────────────────┤
│9 │ Der Linux-Kernel misst alle anfänglichen │
│ │ RAM-Dateisysteme, die es empfängt, in dieses │
│ │ PCR. │
├────┼──────────────────────────────────────────────┤
│10 │ Das IMA-Projekt misst seinen Laufzeitzustand │
│ │ in dieses PCR. │
├────┼──────────────────────────────────────────────┤
│12 │ systemd-boot(7) misst die angegebene │
│ │ Kernelbefehlszeile in dieses PCR. │
│ │ systemd-stub(7) misst die manuell angegebene │
│ │ Kernelbefehlszeile ein (d.h. eine │
│ │ Kernelbefehlszeile, die in dem vereinigten │
│ │ PE-Abbild eingebettet ist, außer Kraft │
│ │ setzt) und lädt die Zugangsberechtigungen in │
│ │ dieses PCR ein. (Beachten Sie, dass die │
│ │ Kernelbefehlszeile zweimal eingemessen │
│ │ werden könnte, wenn sytemd-boot und │
│ │ systemd-stub in Kombination verwandt │
│ │ werden!) │
├────┼──────────────────────────────────────────────┤
│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.
--tpm2-with-pin=LOGISCH
Beim Registrieren eines TPM2-Gerätes steuert dies, ob der Benutzer eine PIN beim
Entsperren des Laufwerks zusätzlich zur PCR-Anbindung angeben muss, basierend auf der
TPM2-Richtlinien-Authentifizierung. Standardmäßig »no«. Obwohl es PIN heißt, können
alle Zeichen verwandt werden, nicht nur Zahlen.
Beachten Sie, dass eine inkorrekte PIN-Eingabe beim Entsperren den
TPM-Wörterbuch-Sperrmechanismus erhöht und Benutzer für eine längere Zeit aussperren
könnte, abhängig von seiner Konfiguration. Der Sperrmechanismus ist eine globale
Eigenschaft des TPM, systemd-cryptenroll steuert oder konfiguriert den
Sperrmechanismus nicht. Sie können die tpm2-tss-Werkzeuge zur Untersuchung oder
Konfiguration des Wörterbuch-Sperrmechanismus mit den Befehlen tpm2_getcap(1) bzw.
tpm2_dictionarylockout(1) verwenden.
--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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.