Provided by: manpages-de_4.21.0-2_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-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.

   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 oder einen FIDO2-Token bereitzustellen. Es wird derzeit nicht
       unterstützt, ein Gerät mit einem TPM2/PKCS#11-Schlüssel zu entsperren, um einen neuen
       TPM2/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 oder einen FIDO2-Token zu registrieren.

       Beachten Sie auch, dass die Registrierung mehrerer FIDO2-Token derzeit eingeschränkt ist.
       Wenn mehrere FIDO2-Token registriert werden, wird systemd-cryptseup 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.

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.

           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.

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

           Hinzugefügt in Version 253.

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

           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 nicht alle Algorithmen unterstützen könnte.

           Hinzugefügt in Version 251.

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

           The key, in most cases, should be the Storage Root Key (SRK) from a local TPM2
           security chip. If a key from a different handle (not the SRK) is used, you must
           specify its handle index using --tpm2-seal-key-handle=.

           The systemd-tpm2-setup.service(8)  service writes the SRK to
           /run/systemd/tpm2-srk-public-key.tpm2b_public automatically during boot, in the
           correct format.

           Alternatively, you may use systemd-analyze srk to retrieve the SRK from the TPM2
           security chip explicitly. See systemd-analyze(1)  for details. Example:

               systemd-analyze srk > srk.tpm2b_public

           Hinzugefügt in Version 255.

       --tpm2-seal-key-handle=HANDLE
           Configures which parent key to use for sealing, using the TPM handle (index) of the
           key. This is used to "seal" (encrypt) a secret and must be used later to "unseal"
           (decrypt) the secret. Expects a hexadecimal 32bit integer, optionally prefixed with
           "0x". Allowable values are any handle index in the persistent
           ("0x81000000"-"0x81ffffff") or transient ("0x80000000"-"0x80ffffff") ranges. Since
           transient handles are lost after a TPM reset, and may be flushed during TPM context
           switching, they should not be used except for very specific use cases, e.g. testing.

           The default is the Storage Root Key (SRK) handle index "0x81000001". A value of 0 will
           use the default. For the SRK handle, a new key will be created and stored in the TPM
           if one does not already exist; for any other handle, the key must already exist in the
           TPM at the specified handle index.

           This should not be changed unless you know what you are doing.

           Hinzugefügt in Version 255.

       --tpm2-pcrs= [PCR…]
           Configures the TPM2 PCRs (Platform Configuration Registers) to bind to when enrollment
           is requested via --tpm2-device=. Takes a list of PCR entries, where each entry starts
           with a name or numeric index in the range 0...23, optionally followed by ":" and a
           hash algorithm name (specifying the PCR bank), optionally followed by "=" and a hash
           digest value. Multiple PCR entries are separated by "+". If not specified, the default
           is to use PCR 7 only. If an empty string is specified, binds the enrollment to no PCRs
           at all. See the table above for a list of available 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.

           Example: --tpm2-pcrs=4:sha1=3a3f780f11a4b49969fcaa80cd6e3957c33b2275 specifies that
           PCR register 4 from the SHA1 bank should be used, and a hash digest value of
           3a3f780f11a4b49969fcaa80cd6e3957c33b2275 will be used instead of reading the current
           PCR value.

           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…], --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]
           Configures a TPM2 pcrlock policy to bind encryption to. Expects a path to a pcrlock
           policy file as generated by the systemd-pcrlock(1)  tool. If a TPM2 device is enrolled
           and this option is not used but a file pcrlock.json is found in /run/systemd/ or
           /var/lib/systemd/ it is automatically used. Assign an empty string to turn this
           behaviour off.

           Hinzugefügt in Version 255.

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

           Hinzugefügt in Version 248.

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

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