Provided by: manpages-de_4.21.0-2_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.
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
┌─────┬─────────────────────┬──────────────────────────────────────────────┐
│ PCR │ Name │ Erklä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 oder neuer
bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
Mailingliste der Übersetzer.
systemd 255 SYSTEMD-CRYPTENROLL(1)