Provided by: manpages-de_4.27.0-1_all bug

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- oder EC-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 Bereinigen
       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.

       systemd-cryptsetup agiert auf Geräten, die /var/ zugrunde liegen, falls kein Gerät explizit angegeben
       wurde und die Bereinigungs-Aktion nicht erbeten wurde. (Beachten Sie, dass dies im typischen Fall, bei
       dem /var/ auf dem gleichen Dateisystem wie das Wurzeldateisystem ist, dies somit einen Schlüssel in das
       dem Wurzeldateisystem zugrundeliegende Dateisystem registriert.)

   TPM2-PCRs und -Richtlinien
       PCRs ermöglichen das Binden von Verschlüsselung von Geheimnissen an bestimmte Softwareversionen und den
       Systemzustand, so dass der registrierte Schlüssel nur zugreifbar ist (»entsiegelt« werden kann), falls
       bestimmte, vertrauenswürdige Sofware oder Konfiguration verwandt wird. Solche Bindungen können mit der
       nachfolgend beschriebenen Option --tpm2-pcrs= erstellt werden.

       Geheimnisse können auch indirekt angebunden werden: eine signierte Richtlinie für einen Zustand aus der
       Kombination einiger PCR-Werte wird bereitgestellt und das Geheimnis ist an den öffentlichen Teil des
       Schlüssels gebunden, der zur Signatur dieser Richtlinie verwandt wird. Dies bedeutet, das der Eigentümer
       eines Schlüssel eine Reihe von signierten Richtlinien für bestimmte Software-Versionen und Systemzustände
       erstellen kann, und dass das Geheimnis entschlüsselt werden kann, solange der Maschinenzustand auf eine
       dieser Richtlinien passt. Beispielsweise könnte ein Lieferant für jede Kernel+Initrd-Aktualisierung ein
       Richtlinie bereitstellen, wodurch es Benutzern ermöglicht würde, Geheimnisse zu verschlüsseln, so dass
       sie entschlüsselt werden können, wenn eine der vom Lieferanten signierte Kombination von Kernel+Initrd
       ausgeführt wird. Solche Bindungen können mit den nachfolgend beschriebenen Optionen --tpm2-public-key=,
       --tpm2-public-key-pcrs=, --tpm2-signature= erstellt werden.

       Siehe die Linux-TPM-PCR-Registratur[1] für eine verbindliche Liste von PCRs und deren Aktualisierungsart.
       Die nachfolgende Tabelle enthält eine Kurzreferenz, sie beschreibt insbesondere die von Systemd
       veränderten PCRs.

       Tabelle 1. Gut-bekannte PCR-Definitionen
       ┌─────┬─────────────────────┬──────────────────────────────────────────────┐
       │ PCRNameErklärung                                    │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 0   │ platform-code       │ Ausführbarer Code der                        │
       │     │                     │ Kernsystem-Firmware; ändert                  │
       │     │                     │ sich bei                                     │
       │     │                     │ Firmware-Aktualisierungen                    │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 1   │ platform-config     │ Konfiguration der                            │
       │     │                     │ Kernsystem-Firmware-Daten/Rechner-Plattform; │
       │     │                     │ enthält typischerweise die                   │
       │     │                     │ Serien- und Modellnummer,                    │
       │     │                     │ ändert sich beim Austausch                   │
       │     │                     │ grundlegender                                │
       │     │                     │ Hardware-/CPU-/RAM-Komponenten               │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 2   │ external-code       │ Erweiterter oder austauschbarer ausführbarer │
       │     │                     │ Code; einschließlich Options-ROMs und        │
       │     │                     │ austauschbarer Hardware                      │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 3   │ external-config     │ Erweiterte oder austauschbare                │
       │     │                     │ Firmware-Daten; einschließlich Informationen │
       │     │                     │ über austauschbare Hardware                  │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 4   │ boot-loader-code    │ Systemstartprogramm und zusätzliche Treiber; │
       │     │                     │ PE-Programm vom Systemstartprogramm          │
       │     │                     │ aufgerufen; Änderungen an                    │
       │     │                     │ Systemstart-Aktualisierungen. sd-stub(7)     │
       │     │                     │ misst vom ESP eingelesene                    │
       │     │                     │ Systemerweiterungs-Abbilder hier auch ein    │
       │     │                     │ (siehe systemd-sysext(8)).                   │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 5   │ boot-loader-config  │ GPT-/Partitionstabelle; ändert sich, wenn    │
       │     │                     │ Partitionen hinzugefügt, verändert oder      │
       │     │                     │ entfernt werden                              │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 7   │ secure-boot-policy  │ Sicherer Systemstartzustand; ändert sich,    │
       │     │                     │ wenn der UEFI-SecureBoot-Modus               │
       │     │                     │ aktiviert/deaktiviert wird oder sich         │
       │     │                     │ Firmware-Zertifikate (PK, KEK, db, dbx, …)   │
       │     │                     │ ändern.                                      │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 9   │ kernel-initrd       │ Der Linux-Kernel misst alle Initrds, die er  │
       │     │                     │ empfängt, in dieses PCR.                     │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 10  │ ima                 │ Das IMA-Projekt misst seinen Laufzeitzustand │
       │     │                     │ in dieses PCR.                               │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 11  │ kernel-boot         │ systemd-stub(7) misst das ELF-Kernelabbild,  │
       │     │                     │ die eingebettete Initrd und andere           │
       │     │                     │ Nutzlastdaten des PE-Abbildes, in das sie    │
       │     │                     │ abgelegt sind, in diesen PCR.                │
       │     │                     │ systemd-pcrphase.service(8) misst            │
       │     │                     │ Systemstartphasen-Zeichenketten in diesen    │
       │     │                     │ PCR zu verschiedenen Meilensteinen im        │
       │     │                     │ Systemstartprozess.                          │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 12  │ kernel-config       │ systemd-boot(7) misst die Kernelbefehlszeile │
       │     │                     │ in dieses PCR. systemd-stub(7) misst jede    │
       │     │                     │ 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.     │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 13  │ sysexts             │ systemd-stub(7) misst jedes                  │
       │     │                     │ systemd-sysext(8)-Abbild, das es an den      │
       │     │                     │ gestarteten Kernel übergibt, in diesen PCR.  │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 14  │ shim-policy         │ Das Shim-Projekt misst seine                 │
       │     │                     │ »MOK«-Zertifikate und -Hashes in dieses PCR. │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 15  │ system-identity     │ systemd-cryptsetup(8) misst optional den     │
       │     │                     │ Datenträgerschlüssel von aktivierten         │
       │     │                     │ LUKS-Datenträgern in diesen PCR.             │
       │     │                     │ systemd-pcrmachine.service(8) misst die      │
       │     │                     │ machine-id(5) in diesen PCR.                 │
       │     │                     │ systemd-pcrfs@.service(8) misst              │
       │     │                     │ Einhängepunkte, Dateisystem-UUIDs,           │
       │     │                     │ Bezeichnungen, Partitions-UUIDs der Wurzel   │
       │     │                     │ -und /var/-Dateisysteme in diesen PCR.       │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 16  │ debug               │ Fehlersuche                                  │
       ├─────┼─────────────────────┼──────────────────────────────────────────────┤
       │ 23  │ application-support │ Unterstützung von Anwendungen                │
       └─────┴─────────────────────┴──────────────────────────────────────────────┘

       Im allgemeinen sollten verschlüsselte Datenträger an eine Kombination von PCR 7, 11 und 14 (falls
       Shim/MOK verwandt wird) gebunden werden. Damit Firmware und das Betriebssystem aktualisiert werden
       können, wird typischerweise nicht empfohlen, PCRs wie 0 und 2 zu verwenden, da der von ihnen abgedeckte
       Programm-Code bereits indirekt über die in PCR 7 eingemessenen Zertifikate abgedeckt sein sollte. Prüfung
       über Zertifikats-Hashes 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 Signaturen sollten unverändert bleiben. Siehe die
       Linux-TPM-PCR-Registratur[1] für eine weitere Besprechung.

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, einen Wiederherstellungsschlüssel, einen
       FIDO2-Token oder einen TPM2-Schlüssel bereitzustellen. Es wird derzeit nicht unterstützt, ein Gerät mit
       einem PKCS#11-Schlüssel zu entsperren, um einen neuen PKCS#11-Schlüssel zu registrieren. Falls daher in
       der Zukunft einen Schlüsseltausch gewünscht wird, wird im Allgemeinen empfohlen, immer eine Passphrase,
       einen Wiederherstellungsschlüssel, einen FIDO2-Token oder einen TPM2-Schlüssel zu registrieren.

       Beachten Sie auch, dass die Registrierung mehrerer FIDO2-Token derzeit eingeschränkt ist. Wenn mehrere
       FIDO2-Token registriert werden, wird systemd-cryptsetup Vorabanfragen durchführen, um zu ermitteln,
       welche der registrierten Token derzeit eingesteckt ist. Dies ist allerdings für FIDO2-Token mit
       Benutzerprüfung (UV, normalerweise über Biometrie) nicht möglich. In diesem Fall wird es darauf
       zurückfallen, der Reihe nach jeden registrierten Token auszuprobieren. Dadurch wird mehrmals um die
       Eingabe der PIN und der Benutzerüberprüfung gebeten. Diese Einschränkung betrifft PKCS#11-Token nicht.

KOMPATIBILITÄT

       Die Sicherheitstechnik innerhalb von Systemd und der allgemeinen Industrie entwickelt sich immer weiter.
       Um die besten Sicherheitsgarantien bereitzustellen, wird die Art und Weise, wie TPM2-, FIDO2-,
       PKCS#11-Geräte registriert werden, regelmäßig in neueren Versionen von Systemd aktualisiert. Immer, wenn
       dies passiert, werden die folgenden Kompatibilitätsgarantien erteilt:

       •   Ältere Registrierungen werden weiterhin unterstützt und können mit neueren Versionen von
           systemd-cryptsetup@.service(8) entsperrt werden.

       •   Das Gegenteil wird allerdings nicht garantiert: es könnte nicht möglich sein, einen Datenträger mit
           einer älteren Version von systemd-cryptsetup(8) zu entsperren, dessen Registrierung mit einer neueren
           Version von systemd-cryptenroll erfolgte.

       Mit diesem Wissen wird im Allgemeinen empfohlen, passende Versionen von systemd-cryptenroll und
       systemd-cryptsetup zu verwenden, da dies am besten getestet und unterstützt ist.

       Es könnte empfehlenswert sein, bestehende Registrierungen erneut zu registrieren, um von neuen
       Sicherheitsvorteilen zu profitieren, die zu Systemd hinzugefügt wurden.

ENTSPERREN

       Die folgenden Optionen, die zum Entsperren des Geräts in Vorbereitung der Registrierungsaktionen verwandt
       werden können, werden verstanden:

       --unlock-key-file=PFAD
           Verwendet eine Datei statt ein aus der Standardeingabe gelesenes Passwort (eine Passphrase), um den
           Datenträger zu entsperren. Erwartet den PFAD zu der Datei, die Ihren Schlüssel enthält, um den
           Datenträger zu entsperren. Derzeit gibt es nichts wie --key-file-offset= oder --key-file-size=, daher
           darf diese Datei nur den vollständigen Schlüssel enthalten.

           Hinzugefügt in Version 252.

       --unlock-fido2-device=PFAD
           Ein FIDO2-Gerät anstelle eines aus der Standardeingabe gelesenen Passwortes/einer Passphrase zum
           Entsperren des Datenträgers verwenden. 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-Token zu bestimmen (davon darf es
           nur genau einen geben). Diese automatische Erkennung wird nicht unterstützt, falls auch die Option
           --fido2-device= angegeben wird. Beachten Sie, dass derzeit FIDO2-Geräte, die ohne ein zugehörigen
           LUKS2-Token registriert wurden (d.h. --fido2-parameters-in-header=no), nicht zum Entsperren verwandt
           werden können.

           Hinzugefügt in Version 253.

       --unlock-tpm2-device=PFAD
           Ein TPM2-Gerät anstelle eines aus der Standardeingabe gelesenen Passwortes/einer Passphrase zum
           Entsperren des Datenträgers verwenden. Erwartet ein Geräteknotepnpfad, der sich auf einen TPM2-Chip
           bezieht (z. B. /dev/tpmrm0). Alternativ kann der besondere Wert »auto« angegeben werden, um
           automatisch den Geräteknoten eines aktuell erkannten TPM2-Gerätes zu bestimmen (davon darf es nur
           genau einen geben).

           Hinzugefügt in Version 256.

EINFACHE REGISTRIERUNG

       Die folgenden Optionen, die zur Registrierung von Entsperrungen basierend auf einfacher Benutzereingabe
       verwandt werden können, 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.

           Hinzugefügt in Version 248.

       --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.

           Hinzugefügt in Version 248.

PKCS#11 ENROLLMENT

       Die folgende Option, die zur Registrierung von PKCS#11-Token verwandt werden kann, wird verstanden:

       --pkcs11-token-uri=URI
           Registriert einen PKCS#11-Sicherheits-Token oder eine Smartcard (z.B. einen YubiKey). Erwartet eine
           PKCS#11-URI, die das Finden eines X.509-Zertifikats oder eines öffentlichen Schlüssels auf dem Token
           ermöglicht. Die URI muss auch dazu geeignet sein, einen zugehörigen privaten Schlüssel zu finden,
           nachdem der Typ des Objekts darauf geändert wurde. Alternativ kann der besondere Wert »auto«
           angegeben werden, um automatisch die geeignete URI zu bestimmen, falls ein einzelner
           Sicherheits-Token, der nur ein einzelnes Schlüsselpaar enthält, eingesteckt ist. Der besondere Wert
           »list« kann zum Aufzählen aller derzeit eingesteckten geeigneten PKCS#11-Token verwandt werden.

           Der PKCS#11-Token muss ein RSA- oder EC-Schlüsselpaar enthalten, das zum Entsperren eines
           LUKS2-Datenträgers verwandt werden wird. Für RSA wird ein zufällig erstellter Datenträgerschlüssel
           mit einem öffentlichen Schlüssel in dem Token verschlüsselt und in dem Kopfbereich des
           LUKS2-JSON-Token gespeichert. Um einen Datenträger zu entsperren, wird der gespeicherte
           Datenträgerschlüssel mit dem privaten Schlüssel in dem Token entschlüsselt. Für ECC wird der
           ECDH-Algorithmus verwandt: es wird ein Paar von EC-Schlüsseln in der gleichen EC-Gruppe erstellt,
           dann ein gemeinsames Geheimnis mittels des erstellten privaten und öffentlichen Schlüssels im Token
           abgeleitet. Das abgeleitete gemeinsame Geheimnis wird als Datenträgerschlüssel verwandt. Der
           erstellte öffentliche Schlüssel wird in dem Kopfbereich des LUKS2-JSON-Token gespeichert. Der
           erstellte private Schlüssel wird gelöscht. Um einen Datenträger zu entsperren, wird das gemeinsame
           Geheimnis mit dem gespeicherten öffentlichen Schlüssel und einem privaten Schlüssel im Token
           abgeleitet.

           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.

           Hinzugefügt in Version 248.

FIDO2 ENROLLMENT

       Die folgenden Optionen werden zum Registrieren von FIDO2-Token verstanden:

       --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). Diese
           automatische Erkennung wird nicht unterstützt, falls auch die Option --unlock-fido2-device= angegeben
           wird. 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.

           Hinzugefügt in Version 248.

       --fido2-credential-algorithm=ZEICHENKETTE
           Gibt den bei der Erstellung von Zugangsberechtigungen zu verwendenden 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 sich entscheiden könnte, nicht alle Algorithmen zu unterstützen.

           Hinzugefügt in Version 251.

       --fido2-salt-file=PFAD
           Gibt bei der Registrierung von FIDO2-Sicherheits-Token den Pfad zu einer Datei oder einem
           AF_UNIX-Socket an, aus dem der Salt-Wert gelesen werden soll, der in der durch den
           FIDO2-Sicherheits-Token durchgeführten HMAC-Aktion verwandt werden soll. Falls diese Option nicht
           angegeben ist, wird der Salt zufällig erstellt.

           Hinzugefügt in Version 257.

       --fido2-parameters-in-header=LOGISCH
           Steuert bei der Registrierung eines FIDO2-Sicherheits-Token ob FIDO2-Parameter in dem
           LUKS2-Superblock gespeichert werden. Standardmäßig »yes«. Falls auf »no« gsetzt, muss die Option
           fido2-cid= manuell in der entsprechenden /etc/crypttab-Zeile zusammen mit einer Schlüsseldatei
           angegeben werden. Siehe crypttab(5) zu Details.

           Hinzugefügt in Version 257.

       --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.)

           Hinzugefügt in Version 249.

       --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.)

           Hinzugefügt in Version 249.

       --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.)

           Hinzugefügt in Version 249.

TPM2-REGISTRIERUNG

       Die folgenden Optionen, die zur Registrierung von TPM2-Geräten verwandt werden können, werden verstanden:

       --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.

           Hinzugefügt in Version 248.

       --tpm2-device-key=PFAD
           Registriert einen TPM2-Sicherheitschip mittels seines öffentlichen Schlüssels. Erwartet einen Pfad,
           der sich auf den öffentlichen TPM2-Schlüssel im Format TPM2B_PUBLIC bezieht. Dies kann nicht mit
           --tpm2-device= verwandt werden, da es die gleiche Aktion durchführt, aber ohne die Verbindung zum
           TPM2-Sicherheitschip; stattdessen wird die Registrierung mittels des bereitgestellten TPM2-Schlüssels
           berechnet. Dies ist in Situationen nützlich, bei denen der TPM2-Sicherheitschip zum Zeitpunkt der
           Registrierung nicht verfügbar ist.

           In den meisten Fällen sollte der Schlüssel der Speicherwurzelschlüssel (SRK) von einem lokalen
           TPM2-Sicherheits-Chip sein. Falls ein Schlüssel aus einer anderen Referenz (nicht dem SRK) verwandt
           wird, müssen Sie seinen Referenzindex mittels --tpm2-seal-key-handle= angeben.

           Der Dienst systemd-tpm2-setup.service(8) schreibt während des Systemstarts automatisch den SRK im
           korrekten Format nach /run/systemd/tpm2-srk-public-key.tpm2b_public.

           Alternativ können Sie systemd-analyze srk verwenden, um den SRK explizit aus dem
           TPM2-Sicherheits-Chip abzurufen. Siehe systemd-analyze(1) zu Details. Beispiel:

               systemd-analyze srk > srk.tpm2b_public

           Hinzugefügt in Version 255.

       --tpm2-seal-key-handle=REFERENZ
           Konfiguriert den für das Versiegeln zu verwendenden Elternschlüssel, wobei die TPM-Referenz (der
           Index) des Schlüssel verwandt wird. Dies wird zum »versiegeln« (verschlüsseln) eines Geheimnisses
           verwandt und muss später dazu verwandt werden, das Geheimnis zu »entsiegeln« (entschlüsseln).
           Erwartet eine hexadezimale 32-bit-Ganzzahl, der optional »0x« vorangestellt ist. Es sind alle
           Referenzindexwerte im dauerhaften (»0x81000000«-»0x81ffffff«) oder flüchtigen
           (»0x80000000«-»0x80ffffff«) Bereich zulässig. Da flüchtige Referenzen nach einem TPM-Zurücksetzen
           verloren gehen und während einer TPM-Kontext-Umschaltung rausgeschrieben werden könnten, sollten sie
           nur in sehr speziellen Anwendungsfällen verwandt werden, z.B. zum Testen.

           Die Vorgabe ist der Referenzindex »0x81000001« des Speicherwurzelschlüssels (SRK). Ein Wert 0 wird
           die Vorgabe verwenden. Für die SRK-Referenz wird ein neuer Schlüssel erstellt und in dem TPM
           gespeichert, falls dort noch keiner existiert und für anderere Referenzen muss der Schlüssel bereits
           im TPM am angegebenen Referenzindex existieren.

           Dies sollte nur geändert werden, wenn Sie genau wissen, was Sie machen.

           Hinzugefügt in Version 255.

       --tpm2-pcrs=PCR[+PCR…]
           Konfiguriert die TPM2 PCRs (Plattform-Konfigurationsregister), an wann die Registratur mittels
           --tpm2-device= erbeten wird. Akzeptiert eine Liste von PCR-Einträgen, wobei jeder Eintrag mit einem
           Namen oder einem numerischen Index im Bereich 0…23 beginnt, optional von einem »:« und einem
           Hash-Algorithmusnamen (der die PCR-Bank festlegt) gefolgt, optional gefolgt von einem »=« und
           Hashwert. Mehrere PCR-Einträge werden durch »+« getrennt. Falls nicht angegeben ist die Vorgabe nur
           PCR 7. Falls eine leere Zeichenkette festgelegt ist, wird die Registrierung an überhaupt keine PCRs
           gebunden. Siehe die obige Tabelle für eine Liste der verfügbaren PCRs.

           Beispiel: --tpm2-pcrs=boot-loader-code+platform-config+boot-loader-config gibt an, dass die
           PCR-Register 4, 1 und 5 verwandt werden sollen.

           Beispiel: --tpm2-pcrs=7:sha256 gibt an, dass PCR-Register 7 von der Bank SHA256 verwandt werden soll.

           Beispiel: --tpm2-pcrs=4:sha1=3a3f780f11a4b49969fcaa80cd6e3957c33b2275 spezifiziert, dass PCR-Register
           4 von der SHA1-Bank verwandt werden soll und dass anstelle des Lesens des aktuellen PCR-Werts ein
           Hash-Wert von 3a3f780f11a4b49969fcaa80cd6e3957c33b2275 verwandt werden wird.

           Hinzugefügt in Version 248.

       --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.

           Hinzugefügt in Version 251.

       --tpm2-public-key=PFAD, --tpm2-public-key-pcrs=PCR[+PCR…], --tpm2-signature=PFAD
           Konfiguriert eine TPM2-signierte PCR-Richtlinie, an die Verschlüsselung gebunden werden soll. Die
           Option --tpm2-public-key= akzeptiert einen Pfad zu einem PEM-kodierten öffentlichen Schlüssel, um
           daran die Verschlüsselung zu binden. Falls dies nicht explizit angegeben ist, aber eine Datei
           tpm2-pcr-public-key.pem in einem der Verzeichnisse /etc/systemd/, /run/systemd/, /usr/lib/systemd/
           (in dieser Reihenfolge durchsucht) existiert, wird diese automatisch verwandt. Die Option
           --tpm2-public-key-pcrs= akzeptiert eine Liste von TPM2-PCR-Indices, an die angebunden wird (gleiche
           Syntax wie die oben beschriebene --tpm2-pcrs=). Falls nicht angegeben ist die Vorgabe 11 (d.h. dies
           bindet die Richtlinie an alle vereinigten Kernelabbilder, für die eine PCR-Signatur bereitgestellt
           werden kann).

           Beachten Sie den Unterschied zwischen --tpm2-pcrs= und --tpm2-public-key-pcrs=: Ersterer bindet die
           Entschlüsselung an die aktuellen, angegebenen PCR-Werte; Letzteres bindet die Entschlüsselung an eine
           Gruppe von PCR-Werten, für die eine Signatur durch den angegebenen öffentlichen Schlüssel
           bereitgestellt werden kann. Leztere ist daher in Szenarien nützlicher, bei denen
           Software-Aktualisierungen möglich sein sollen, ohne Zugriff auf alle vorher verschlüsselten
           LUKS2-Datenträger zu verlieren. Ähnlich wie bei --tpm2-pcrs= können in der obigen Tabelle definierte
           Namen auch zur Festlegung der Register verwandt werden, beispielsweise
           --tpm2-public-key-pcrs=boot-loader-code+system-identity.

           Die Option --tpm2-signature= akzeptiert einen Pfad zu einer TPM2-PCR-Signaturdatei, wie sie vom
           Werkzeug systemd-measure(1) erstellt wurde. Falls dies nicht explizit angegeben ist, wird nach einer
           geeigneten Signaturdatei tpm2-pcr-signature.json in /etc/systemd/, /run/systemd/, /usr/lib/systemd/
           (in dieser Reihenfolge) gesucht und diese verwandt. Falls eine Signaturdatei angegeben oder gefunden
           wird, wird diese zur Überprüfung, ob der Datenträger in Abhängigkeit des aktuellen PCR-Zustandes
           damit entsperrt werden kann, verwandt, bevor eine neue Position auf Platte geschrieben wird. Dies ist
           als Sicherheitsnetz gedacht, um sicherzustellen, dass der Zugriff auf einen Datenträger nicht
           verloren geht, falls ein öffentlicher Schlüssel registriert wird, für den keine gültige Signatur für
           den aktuellen PCR-Zustand verfügbar ist. Falls die bereitgestellte Signatur die Kombination aus
           aktuellem PCR-Zustand und öffentlichen Schlüssel nicht entsperrt, wird keine Position registriert und
           die Aktion wird fehlschlagen. Falls keine Signaturdatei angegeben ist oder gefunden wird, erfolgt
           keine solche Sicherheitsüberprüfung.

           Hinzugefügt in Version 252.

       --tpm2-pcrlock=PFAD
           Konfiguriert eine TPM2-Pcrlock-Richtlinie, an die Verschlüsselung angebunden werden soll. Erwartet
           einen Pfad zu einer Pcrlock-Richtliniendatei, wie sie vom Werkzeug systemd-pcrlock(8) erstellt wird.
           Falls ein TPM2-Gerät registriert ist und diese Option nicht verwandt wird, aber eine Datei
           pcrlock.json in /run/systemd/ oder /var/lib/systemd/ gefunden wird, wird diese automatisch verwandt.
           Durch Zuweisen einer leeren Zeichenkette schalten Sie dieses Verhalten aus.

           Hinzugefügt in Version 255.

WEITERE OPTIONEN

       Die folgenden zusätzlichen Optionen werden verstanden:

       --wipe-slot=POSITION[,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

           Hinzugefügt in Version 248.

       --list-devices
           Zeigt eine Liste von Kandiaten-Blockgeräten, auf denen dieser Befehl agieren könnte. Insbesondere
           zählt dies Blockgeräte auf, die derzeit vorhanden sind sowie einen LUKS-Superblock enthalten und
           zeigt ihren Geräteknotenpfad zusammen mit allen ihren Symlinks. Das Gerät muss die Erweiterung
           hmac-secret implementieren, um nutzbar zu sein.

           Hinzugefügt in Version 257.

       -h, --help
           Zeigt einen kurzen Hilfetext an und beendet das Programm.

       --version
           Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

       --no-pager
           Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.

ZUGANGSBERECHTIGUNGEN

       systemd-cryptenroll unterstützt die durch ImportCredential=/LoadCredential=/SetCredential= implementierte
       Dienste-Zugangsberechtigungslogik (siehe systemd.exec(5) zu Details). Die folgenden Zugangsberechtigungen
       werden unterstützt, wenn sie hereingereicht werden:

       cryptenroll.passphrase, cryptenroll.new-passphrase
           Kann eine Passphrase zum Entsperren des Datenträgers bzw. zum neuen Registrieren enthalten.

           Hinzugefügt in Version 256.

       cryptenroll.tpm2-pin, cryptenroll.new-tpm2-pin
           Kann eine TPM2-PIN zum Entsperren des Datenträgers bzw. zum neuen Registrieren enthalten.

           Hinzugefügt in Version 256.

       cryptenroll.fido2-pin
           Falls ein FIDO2-Token registriert wird, kann diese die PIN des Tokens enthalten.

           Hinzugefügt in Version 256.

       cryptenroll.pkcs11-pin
           Falls ein PKCS#11-Token registriert wird, kann diese die PIN des Tokens enthalten.

           Hinzugefügt in Version 256.

EXIT-STATUS

       Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.

BEISPIELE

       crypttab(5) und systemd-measure(1) enthalten verschiedene Beispiele des Einsatzes von
       systemd-cryptenroll.

SIEHE AUCH

       systemd(1), systemd-cryptsetup@.service(8), crypttab(5), cryptsetup(8), systemd-measure(1)

ANMERKUNGEN

        1. Linux TPM-PCR-Registratur
           https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/

Ü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: debian-l10n-german@lists.debian.org.

systemd 257.6                                                                             SYSTEMD-CRYPTENROLL(1)