Provided by: manpages-de_4.23.1-1_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- 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
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.
systemd-cryptsetup operates on the device backing /var/ if no device is specified
explicitly, and no wipe operation is requested. (Note that in the typical case where /var/
is on the same file system as the root file system, this hence enrolls a key into the
backing device of the root file system.)
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, 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.
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, 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.
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.
--pkcs11-token-uri=URI
Enroll a PKCS#11 security token or smartcard (e.g. a YubiKey). Expects a PKCS#11 URI
that allows finding an X.509 certificate or a public key on the token. The URI must
also be suitable to find a related private key after changing the type of object in
it. Alternatively the special value "auto" may be specified, in order to automatically
determine the suitable URI if a single security token containing a single key pair is
plugged in. The special value "list" may be used to enumerate all suitable PKCS#11
tokens currently plugged in.
The PKCS#11 token must contain an RSA or EC key pair which will be used to unlock a
LUKS2 volume. For RSA, a randomly generated volume key is encrypted with a public key
in the token, and stored in the LUKS2 JSON token header area. To unlock a volume, the
stored encrypted volume key will be decrypted with a private key in the token. For
ECC, ECDH algorithm is used: we generate a pair of EC keys in the same EC group, then
derive a shared secret using the generated private key and the public key in the
token. The derived shared secret is used as a volume key. The generated public key is
stored in the LUKS2 JSON token header area. The generated private key is erased. To
unlock a volume, we derive the shared secret with the stored public key and a private
key in the token.
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 sich entscheiden könnte, nicht alle Algorithmen
zu unterstützen.
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.
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(1) 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.
--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.
-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.
--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.
CREDENTIALS
systemd-cryptenroll supports the service credentials logic as implemented by
ImportCredential=/LoadCredential=/SetCredential= (see systemd.exec(5) for details). The
following credentials are used when passed in:
cryptenroll.passphrase, cryptenroll.new-passphrase
May contain the passphrase to unlock the volume with/to newly enroll.
Hinzugefügt in Version 256.
cryptenroll.tpm2-pin, cryptenroll.new-tpm2-pin
May contain the TPM2 PIN to unlock the volume with/to newly enroll.
Hinzugefügt in Version 256.
cryptenroll.fido2-pin
If a FIDO2 token is enrolled this may contain the PIN of the token.
Hinzugefügt in Version 256.
cryptenroll.pkcs11-pin
If a PKCS#11 token is enrolled this may contain the PIN of the token.
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 ⟨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⟩.