SYSTEMD-CRYPTENROLL(1) systemd-cryptenroll SYSTEMD-CRYPTENROLL(1) BEZEICHNUNG systemd-cryptenroll - PKCS#11-, FIDO2-, TPM2-Token/-Gerate bei LUKS2-verschlusselten Datentragern registrieren UBERSICHT systemd-cryptenroll [OPTIONEN] [GERAT] BESCHREIBUNG systemd-cryptenroll ist ein Werkzeug zum Registrieren von Hardware-Sicherheits-Token und -Geraten an LUKS2-verschlusselten Datentragern, die dann zum Entsperren des Datentragers wahrend des Systemstarts verwandt werden konnen. Es unterstutzt insbesondere die Registrierung von Token und Anmeldedaten von folgenden Typen: 1. PKCS#11-Sicherheits-Token und -Smartcards, die ein RSA- oder EC-Schlusselpaar transportieren (z.B. verschiedene YubiKeys). 2. FIDO2-Sicherheits-Token, die die Erweiterung >>hmac-secret<< implementieren (die meisten FIDO2-Schlussel, einschliesslich YubiKeys) 3. TPM2-Sicherheitsgerate 4. Regulare Passphrasen 5. Rettungsschlussel. Diese entsprechen regularen Ausdrucken, werden allerdings zufallig auf dem Computer erstellt und haben daher im Allgemeinen eine hohere Entropie als vom Benutzer ausgewahlte Passphrasen. Ihr Zeichensatz wurde entwickelt, um sicherzustellen, dass sie leicht einzutippen sind und weiterhin eine hohe Entropie haben. Sie konnen von dem Bildschirm auch mittels eines QR-Codes eingelesen werden. Rettungsschlussel konnen zum Entsperren von LUKS2-Datentragern 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 zusatzlich zum Aufzahlen derzeit registrierter Sicherheits-Token und dem Bereinigen einer Teilmenge von ihnen verwandt werden. Letzteres kann mit der Registrieraktion eines neuen Sicherheits-Token kombiniert werden, um Registrierungen zu aktualisieren oder zu ersetzen. Das Werkzeug unterstutzt nur LUKS2-Datentrager, da es die Metainformationen des Tokens in dem LUKS2-JSON-Token-Bereich speichert, der bei anderen Verschlusselungsformaten nicht vorhanden ist. systemd-cryptsetup agiert auf Geraten, die /var/ zugrunde liegen, falls kein Gerat explizit angegeben wurde und die Bereinigungs-Aktion nicht erbeten wurde. (Beachten Sie, dass dies im typischen Fall, bei dem /var/ auf dem gleichen Dateisystem wie das Wurzeldateisystem ist, dies somit einen Schlussel in das dem Wurzeldateisystem zugrundeliegende Dateisystem registriert.) TPM2-PCRs und -Richtlinien PCRs ermoglichen das Binden von Verschlusselung von Geheimnissen an bestimmte Softwareversionen und den Systemzustand, so dass der registrierte Schlussel nur zugreifbar ist (>>entsiegelt<< werden kann), falls bestimmte, vertrauenswurdige Sofware oder Konfiguration verwandt wird. Solche Bindungen konnen mit der nachfolgend beschriebenen Option --tpm2-pcrs= erstellt werden. Geheimnisse konnen auch indirekt angebunden werden: eine signierte Richtlinie fur einen Zustand aus der Kombination einiger PCR-Werte wird bereitgestellt und das Geheimnis ist an den offentlichen Teil des Schlussels gebunden, der zur Signatur dieser Richtlinie verwandt wird. Dies bedeutet, das der Eigentumer eines Schlussel eine Reihe von signierten Richtlinien fur bestimmte Software-Versionen und Systemzustande erstellen kann, und dass das Geheimnis entschlusselt werden kann, solange der Maschinenzustand auf eine dieser Richtlinien passt. Beispielsweise konnte ein Lieferant fur jede Kernel+Initrd-Aktualisierung ein Richtlinie bereitstellen, wodurch es Benutzern ermoglicht wurde, Geheimnisse zu verschlusseln, so dass sie entschlusselt werden konnen, wenn eine der vom Lieferanten signierte Kombination von Kernel+Initrd ausgefuhrt wird. Solche Bindungen konnen mit den nachfolgend beschriebenen Optionen --tpm2-public-key=, --tpm2-public-key-pcrs=, --tpm2-signature= erstellt werden. Siehe die UAPI.7-Linux-TPM-PCR-Registratur[1] fur eine verbindliche Liste von PCRs und deren Aktualisierungsart. Die nachfolgende Tabelle enthalt eine Kurzreferenz, sie beschreibt insbesondere die von Systemd veranderten PCRs. Tabelle 1. Gut-bekannte PCR-Definitionen +----+---------------------+----------------------------------------------+ |PCR | Name | Erklarung | +----+---------------------+----------------------------------------------+ |0 | platform-code | Ausfuhrbarer Code der Kernsystem-Firmware; | | | | andert sich bei Firmware-Aktualisierungen | +----+---------------------+----------------------------------------------+ |1 | platform-config | Konfiguration der | | | | Kernsystem-Firmware-Daten/Rechner-Plattform; | | | | enthalt typischerweise die Serien- und | | | | Modellnummer, andert sich beim Austausch | | | | grundlegender Hardware-/CPU-/RAM-Komponenten | +----+---------------------+----------------------------------------------+ |2 | external-code | Erweiterter oder austauschbarer ausfuhrbarer | | | | Code; einschliesslich Options-ROMs und | | | | austauschbarer Hardware | +----+---------------------+----------------------------------------------+ |3 | external-config | Erweiterte oder austauschbare | | | | Firmware-Daten; einschliesslich | | | | Informationen uber austauschbare Hardware | +----+---------------------+----------------------------------------------+ |4 | boot-loader-code | Systemstartprogramm und zusatzliche Treiber; | | | | PE-Programm vom Systemstartprogramm | | | | aufgerufen; Anderungen 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; andert sich, wenn | | | | Partitionen hinzugefugt, verandert oder | | | | entfernt werden | +----+---------------------+----------------------------------------------+ |7 | secure-boot-policy | Sicherer Systemstartzustand; andert sich, | | | | wenn der UEFI-SecureBoot-Modus | | | | aktiviert/deaktiviert wird oder sich | | | | Firmware-Zertifikate (PK, KEK, db, dbx, ) | | | | andern. | +----+---------------------+----------------------------------------------+ |9 | kernel-initrd | Der Linux-Kernel misst alle Initrds, die er | | | | empfangt, 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, | | | | ausser Kraft setzt) und ladt die | | | | Zugangsberechtigungen in dieses PCR ein. | +----+---------------------+----------------------------------------------+ |13 | sysexts | systemd-stub(7) misst jedes | | | | systemd-sysext(8)-Abbild, das es an den | | | | gestarteten Kernel ubergibt, 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 | | | | Datentragerschlussel von aktivierten | | | | LUKS-Datentragern in diesen PCR. | | | | systemd-pcrmachine.service(8) misst die | | | | machine-id(5) in diesen PCR. | | | | systemd-pcrfs@.service(8) misst | | | | Einhangepunkte, Dateisystem-UUIDs, | | | | Bezeichnungen, Partitions-UUIDs der Wurzel | | | | -und /var/-Dateisysteme in diesen PCR. | +----+---------------------+----------------------------------------------+ |16 | debug | Fehlersuche | +----+---------------------+----------------------------------------------+ |23 | application-support | Unterstutzung von Anwendungen | +----+---------------------+----------------------------------------------+ Im allgemeinen sollten verschlusselte Datentrager an eine Kombination von PCR 7, 11 und 14 (falls Shim/MOK verwandt wird) gebunden werden. Damit Firmware und das Betriebssystem aktualisiert werden konnen, wird typischerweise nicht empfohlen, PCRs wie 0 und 2 zu verwenden, da der von ihnen abgedeckte Programm-Code bereits indirekt uber die in PCR 7 eingemessenen Zertifikate abgedeckt sein sollte. Prufung uber Zertifikats-Hashes ist typischerweise gegenuber der Validierung uber direkte Messung zu bevorzugen, da es im Zusammenhang mit Betriebssystem-/Firmware-Aktualisierungen weniger zerbrechlich ist: die Messung andert sich bei jeder Aktualisierung, aber Signaturen sollten unverandert bleiben. Siehe die UAPI.7-Linux-TPM-PCR-Registratur[1] fur eine weitere Besprechung. EINSCHRANKUNGEN Beachten Sie, dass es notwendig ist, wenn ein neuer Schlussel von einer der funf oben aufgefuhrten unterstutzten Typen registriert wird, zuerst eine Passphrase, einen Wiederherstellungsschlussel, einen FIDO2-Token oder einen TPM2-Schlussel bereitzustellen. Es wird derzeit nicht unterstutzt, ein Gerat mit einem PKCS#11-Schlussel zu entsperren, um einen neuen PKCS#11-Schlussel zu registrieren. Falls daher in der Zukunft einen Schlusseltausch gewunscht wird, wird im Allgemeinen empfohlen, immer eine Passphrase, einen Wiederherstellungsschlussel, einen FIDO2-Token oder einen TPM2-Schlussel zu registrieren. Beachten Sie auch, dass die Registrierung mehrerer FIDO2-Token derzeit eingeschrankt ist. Wenn mehrere FIDO2-Token registriert werden, wird systemd-cryptsetup Vorabanfragen durchfuhren, um zu ermitteln, welche der registrierten Token derzeit eingesteckt ist. Dies ist allerdings fur FIDO2-Token mit Benutzerprufung (UV, normalerweise uber Biometrie) nicht moglich. In diesem Fall wird es darauf zuruckfallen, der Reihe nach jeden registrierten Token auszuprobieren. Dadurch wird mehrmals um die Eingabe der PIN und der Benutzeruberprufung gebeten. Diese Einschrankung betrifft PKCS#11-Token nicht. KOMPATIBILITAT 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-Gerate registriert werden, regelmassig in neueren Versionen von Systemd aktualisiert. Immer, wenn dies passiert, werden die folgenden Kompatibilitatsgarantien erteilt: o Altere Registrierungen werden weiterhin unterstutzt und konnen mit neueren Versionen von systemd-cryptsetup@.service(8) entsperrt werden. o Das Gegenteil wird allerdings nicht garantiert: es konnte nicht moglich sein, einen Datentrager mit einer alteren 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 unterstutzt ist. Es konnte empfehlenswert sein, bestehende Registrierungen erneut zu registrieren, um von neuen Sicherheitsvorteilen zu profitieren, die zu Systemd hinzugefugt wurden. ENTSPERREN Die folgenden Optionen, die zum Entsperren des Gerats in Vorbereitung der Registrierungsaktionen verwandt werden konnen, werden verstanden: --unlock-key-file=PFAD Verwendet eine Datei statt ein aus der Standardeingabe gelesenes Passwort (eine Passphrase), um den Datentrager zu entsperren. Erwartet den PFAD zu der Datei, die Ihren Schlussel enthalt, um den Datentrager zu entsperren. Derzeit gibt es nichts wie --key-file-offset= oder --key-file-size=, daher darf diese Datei nur den vollstandigen Schlussel enthalten. Hinzugefugt in Version 252. --unlock-fido2-device=PFAD Ein FIDO2-Gerat anstelle eines aus der Standardeingabe gelesenen Passwortes/einer Passphrase zum Entsperren des Datentragers verwenden. Erwartet ein Hidraw-Gerat, das sich auf ein FIDO2-Gerat bezieht (z. B. /dev/hidraw1). Alternativ kann der besondere Wert >>auto<< angegeben werden, um automatisch den Gerateknoten des aktuell eingesteckten Sicherheits-Token zu bestimmen (davon darf es nur genau einen geben). Diese automatische Erkennung wird nicht unterstutzt, falls auch die Option --fido2-device= angegeben wird. Beachten Sie, dass derzeit FIDO2-Gerate, die ohne ein zugehorigen LUKS2-Token registriert wurden (d.h. --fido2-parameters-in-header=no), nicht zum Entsperren verwandt werden konnen. Hinzugefugt in Version 253. --unlock-tpm2-device=PFAD Ein TPM2-Gerat anstelle eines aus der Standardeingabe gelesenen Passwortes/einer Passphrase zum Entsperren des Datentragers verwenden. Erwartet ein Gerateknotepnpfad, der sich auf einen TPM2-Chip bezieht (z. B. /dev/tpmrm0). Alternativ kann der besondere Wert >>auto<< angegeben werden, um automatisch den Gerateknoten eines aktuell erkannten TPM2-Gerates zu bestimmen (davon darf es nur genau einen geben). Hinzugefugt in Version 256. EINFACHE REGISTRIERUNG Die folgenden Optionen, die zur Registrierung von Entsperrungen basierend auf einfacher Benutzereingabe verwandt werden konnen, werden verstanden: --password Registriert ein regulares Passwort/eine regulare Passphrase. Dieser Befehl entspricht grosstenteils cryptsetup luksAddKey, allerdings in Kombination mit --wipe-slot= in einem Aufruf, siehe unten. Hinzugefugt in Version 248. --recovery-key Registriert einen Rettungsschlussel. Rettungsschlussel sind grosstenteils identisch zu Passphrasen, sind aber Computer-generiert statt durch Menschen ausgewahlt und haben daher eine hohere garantierte Entropie. Die Schlussel verwenden einen Zeichensatz, der leicht einzugeben ist und vom Bildschirm mittels eines QR-Codes eingelesen werden kann. Hinzugefugt in Version 248. PKCS#11 ENROLLMENT Die folgende Option, die zur Registrierung von PKCS#11-Token verwandt werden kann, wird verstanden: --pkcs11-token-uri=URI Registriert einen PKCS#11-Sicherheits-Token oder eine Smartcard (z.B. einen YubiKey). Erwartet eine PKCS#11-URI, die das Finden eines X.509-Zertifikats oder eines offentlichen Schlussels auf dem Token ermoglicht. Die URI muss auch dazu geeignet sein, einen zugehorigen privaten Schlussel zu finden, nachdem der Typ des Objekts darauf geandert wurde. Alternativ kann der besondere Wert >>auto<< angegeben werden, um automatisch die geeignete URI zu bestimmen, falls ein einzelner Sicherheits-Token, der nur ein einzelnes Schlusselpaar enthalt, eingesteckt ist. Der besondere Wert >>list<< kann zum Aufzahlen aller derzeit eingesteckten geeigneten PKCS#11-Token verwandt werden. Der PKCS#11-Token muss ein RSA- oder EC-Schlusselpaar enthalten, das zum Entsperren eines LUKS2-Datentragers verwandt werden wird. Fur RSA wird ein zufallig erstellter Datentragerschlussel mit einem offentlichen Schlussel in dem Token verschlusselt und in dem Kopfbereich des LUKS2-JSON-Token gespeichert. Um einen Datentrager zu entsperren, wird der gespeicherte Datentragerschlussel mit dem privaten Schlussel in dem Token entschlusselt. Fur ECC wird der ECDH-Algorithmus verwandt: es wird ein Paar von EC-Schlusseln in der gleichen EC-Gruppe erstellt, dann ein gemeinsames Geheimnis mittels des erstellten privaten und offentlichen Schlussels im Token abgeleitet. Das abgeleitete gemeinsame Geheimnis wird als Datentragerschlussel verwandt. Der erstellte offentliche Schlussel wird in dem Kopfbereich des LUKS2-JSON-Token gespeichert. Der erstellte private Schlussel wird geloscht. Um einen Datentrager zu entsperren, wird das gemeinsame Geheimnis mit dem gespeicherten offentlichen Schlussel und einem privaten Schlussel im Token abgeleitet. Um einen LUKS2-Datentrager mit einem registrierten PKCS#11-Sicherheits-Token zu entsperren, legen Sie die Option pkcs11-uri= in der zutreffenden Zeile in /etc/crypttab fest: meindatentrager /dev/sda1 none pkcs11-uri=auto Siehe crypttab(5) fur ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der zugehorigen Zeile in /etc/crypttab. Hinzugefugt in Version 248. FIDO2 ENROLLMENT Die folgenden Optionen werden zum Registrieren von FIDO2-Token verstanden: --fido2-device=PFAD Registriert einen FIDO2-Sicherheits-Token, der die Erweiterung >>hmac-secret<< implementiert (z.B. einen YubiKey). Erwartet ein Hidraw-Gerat, das sich auf ein FIDO2-Gerat bezieht (z.B. /dev/hidraw1). Alternativ kann der besondere Wert >>auto<< angegeben werden, um automatisch den Gerateknoten des aktuell eingesteckten Sicherheits-Tokens zu bestimmen (davon darf es nur genau einen geben). Diese automatische Erkennung wird nicht unterstutzt, falls auch die Option --unlock-fido2-device= angegeben wird. Der besondere Wert >>list<< kann zum Aufzahlen aller derzeit eingesteckten geeigneten FIDO2-Token verwandt werden. Beachten Sie, dass viele Hardware-Sicherheits-Token, die FIDO2 implementieren, ebenfalls den alteren PKCS#11-Standard implementieren. Typischerweise sollte FIDO2 bevorzugt werden, da es leichter zu verwenden und moderner ist. Um einen LUKS2-Datentrager mit einem registrierten FIDO2-Sicherheits-Token zu entsperren, legen Sie die Option fido2-device= in der zutreffenden Zeile in /etc/crypttab fest: meindatentrager /dev/sda1 none fido2-device=auto Siehe crypttab(5) fur ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der zugehorigen Zeile in /etc/crypttab. Hinzugefugt in Version 248. --fido2-credential-algorithm=ZEICHENKETTE Gibt den bei der Erstellung von Zugangsberechtigungen zu verwendenden COSE-Algorithmus an. Der Vorgabewert ist >>es256<<. Unterstutzte Werte sind >>es256<<, >>s256<< und >>eddsa<<. >>es256<< bezeichnet ECDSA uber NIST P-256 mit SHA-256. >>rs256<< bezeichnet 2048-bit RSA mit PKCS#1.5-Auffullung und SHA-256. >>eddsa<< bezeichnet EDDSA uber Curve25519 mit SHA-512. Beachten Sie, dass Ihr Authentikator sich entscheiden konnte, nicht alle Algorithmen zu unterstutzen. Hinzugefugt in Version 251. --fido2-salt-file=PFAD Gibt bei der Registrierung von FIDO2-Sicherheits-Token den Pfad zu einer Datei oder einem AF_UNIX-Socket an, aus dem der Salt-Wert gelesen werden soll, der in der durch den FIDO2-Sicherheits-Token durchgefuhrten HMAC-Aktion verwandt werden soll. Falls diese Option nicht angegeben ist, wird der Salt zufallig erstellt. Hinzugefugt in Version 257. --fido2-parameters-in-header=LOGISCH Steuert bei der Registrierung eines FIDO2-Sicherheits-Token ob FIDO2-Parameter in dem LUKS2-Superblock gespeichert werden. Standardmassig >>yes<<. Falls auf >>no<< gsetzt, muss die Option fido2-cid= manuell in der entsprechenden /etc/crypttab-Zeile zusammen mit einer Schlusseldatei angegeben werden. Siehe crypttab(5) zu Details. Hinzugefugt in Version 257. --fido2-with-client-pin=LOGISCH Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer eine PIN beim Entsperren des Datentragers eingeben muss (die FIDO2-Funktionalitat >>clientPin<<). Standardmassig >>yes<<. (Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalitat >>clientPin<< uberhaupt nicht unterstutzt oder das Aktivieren oder Deaktivieren nicht erlaubt.) Hinzugefugt in Version 249. --fido2-with-user-presence=LOGISCH Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer seine Anwesenheit beim Entsperren des Datentragers nachweisen muss (die FIDO2-Funktionalitat >>up<<). Standardmassig >>yes<<. (Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalitat >>up<< uberhaupt nicht unterstutzt oder das Aktivieren oder Deaktivieren nicht erlaubt.) Hinzugefugt in Version 249. --fido2-with-user-verification=LOGISCH Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer beim Entsperren des Datentragers uberpruft werden muss (die FIDO2-Funktionalitat >>uv<<). Standardmassig >>no<<. (Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalitat >>uv<< uberhaupt nicht unterstutzt oder das Aktivieren oder Deaktivieren nicht erlaubt.) Hinzugefugt in Version 249. TPM2-REGISTRIERUNG Die folgenden Optionen, die zur Registrierung von TPM2-Geraten verwandt werden konnen, werden verstanden: --tpm2-device=PFAD Registriert einen TPM2-Sicherheits-Chip. Erwartet einen Gerateknotenpfad, der sich auf einen TPM2-Chip bezieht (z.B. /dev/tpmrm0). Alternativ kann der besondere Wert >>auto<< angegeben werden, um automatisch den Gerateknoten des aktuell ermittelten TPM2-Gerats zu bestimmen (davon darf es nur genau einen geben). Der besondere Wert >>list<< kann zum Aufzahlen aller derzeit eingesteckten geeigneten TPM2-Chips verwandt werden. Um einen LUKS2-Datentrager mit einem registrierten TPM2-Sicherheits-Chip zu entsperren, legen Sie die Option tpm2-device= in der zutreffenden Zeile in /etc/crypttab fest: meindatentrager /dev/sda1 none tpm2-device=auto Siehe crypttab(5) fur ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der zugehorigen Zeile in /etc/crypttab. Verwenden Sie --tpm2-pcrs= (siehe unten), um zu konfigurieren, an welchen TPM2-PCR-Index die Registrierung angebunden werden soll. Hinzugefugt in Version 248. --tpm2-device-key=PFAD Registriert einen TPM2-Sicherheitschip mittels seines offentlichen Schlussels. Erwartet einen Pfad, der sich auf den offentlichen TPM2-Schlussel im Format TPM2B_PUBLIC bezieht. Dies kann nicht mit --tpm2-device= verwandt werden, da es die gleiche Aktion durchfuhrt, aber ohne die Verbindung zum TPM2-Sicherheitschip; stattdessen wird die Registrierung mittels des bereitgestellten TPM2-Schlussels berechnet. Dies ist in Situationen nutzlich, bei denen der TPM2-Sicherheitschip zum Zeitpunkt der Registrierung nicht verfugbar ist. In den meisten Fallen sollte der Schlussel der Speicherwurzelschlussel (SRK) von einem lokalen TPM2-Sicherheits-Chip sein. Falls ein Schlussel aus einer anderen Referenz (nicht dem SRK) verwandt wird, mussen Sie seinen Referenzindex mittels --tpm2-seal-key-handle= angeben. Der Dienst systemd-tpm2-setup.service(8) schreibt wahrend des Systemstarts automatisch den SRK im korrekten Format nach /run/systemd/tpm2-srk-public-key.tpm2b_public. Alternativ konnen 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 Hinzugefugt in Version 255. --tpm2-seal-key-handle=REFERENZ Konfiguriert den fur das Versiegeln zu verwendenden Elternschlussel, wobei die TPM-Referenz (der Index) des Schlussel verwandt wird. Dies wird zum >>versiegeln<< (verschlusseln) eines Geheimnisses verwandt und muss spater dazu verwandt werden, das Geheimnis zu >>entsiegeln<< (entschlusseln). Erwartet eine hexadezimale 32-bit-Ganzzahl, der optional >>0x<< vorangestellt ist. Es sind alle Referenzindexwerte im dauerhaften (>>0x81000000<<->>0x81ffffff<<) oder fluchtigen (>>0x80000000<<->>0x80ffffff<<) Bereich zulassig. Da fluchtige Referenzen nach einem TPM-Zurucksetzen verloren gehen und wahrend einer TPM-Kontext-Umschaltung rausgeschrieben werden konnten, sollten sie nur in sehr speziellen Anwendungsfallen verwandt werden, z.B. zum Testen. Die Vorgabe ist der Referenzindex >>0x81000001<< des Speicherwurzelschlussels (SRK). Ein Wert 0 wird die Vorgabe verwenden. Fur die SRK-Referenz wird ein neuer Schlussel erstellt und in dem TPM gespeichert, falls dort noch keiner existiert und fur anderere Referenzen muss der Schlussel bereits im TPM am angegebenen Referenzindex existieren. Dies sollte nur geandert werden, wenn Sie genau wissen, was Sie machen. Hinzugefugt 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-Eintragen, wobei jeder Eintrag mit einem Namen oder einem numerischen Index im Bereich 023 beginnt, optional von einem >>:<< und einem Hash-Algorithmusnamen (der die PCR-Bank festlegt) gefolgt, optional gefolgt von einem >>=<< und Hashwert. Mehrere PCR-Eintrage werden durch >>+<< getrennt. Falls eine leere Zeichenkette festgelegt ist, wird die Registrierung an uberhaupt keine PCRs gebunden (dies ist auch die Vorgabe, falls diese Option nicht verwandt wird). Siehe die obige Tabelle fur eine Liste der verfugbaren 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. Hinzugefugt in Version 248. --tpm2-with-pin=LOGISCH Beim Registrieren eines TPM2-Gerates steuert dies, ob der Benutzer eine PIN beim Entsperren des Laufwerks zusatzlich zur PCR-Anbindung angeben muss, basierend auf der TPM2-Richtlinien-Authentifizierung. Standardmassig >>no<<. Obwohl es PIN heisst, konnen alle Zeichen verwandt werden, nicht nur Zahlen. Beachten Sie, dass eine inkorrekte PIN-Eingabe beim Entsperren den TPM-Worterbuch-Sperrmechanismus erhoht und Benutzer fur eine langere Zeit aussperren konnte, abhangig von seiner Konfiguration. Der Sperrmechanismus ist eine globale Eigenschaft des TPM, systemd-cryptenroll steuert oder konfiguriert den Sperrmechanismus nicht. Sie konnen die tpm2-tss-Werkzeuge zur Untersuchung oder Konfiguration des Worterbuch-Sperrmechanismus mit den Befehlen tpm2_getcap(1) bzw. tpm2_dictionarylockout(1) verwenden. Hinzugefugt in Version 251. --tpm2-public-key=PFAD, --tpm2-public-key-pcrs=PCR[+PCR], --tpm2-signature=PFAD Konfiguriert eine TPM2-signierte PCR-Richtlinie, an die Verschlusselung gebunden werden soll. Die Option --tpm2-public-key= akzeptiert einen Pfad zu einem PEM-kodierten offentlichen Schlussel, um daran die Verschlusselung 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, fur die eine PCR-Signatur bereitgestellt werden kann). Beachten Sie den Unterschied zwischen --tpm2-pcrs= und --tpm2-public-key-pcrs=: Ersterer bindet die Entschlusselung an die aktuellen, angegebenen PCR-Werte; Letzteres bindet die Entschlusselung an eine Gruppe von PCR-Werten, fur die eine Signatur durch den angegebenen offentlichen Schlussel bereitgestellt werden kann. Leztere ist daher in Szenarien nutzlicher, bei denen Software-Aktualisierungen moglich sein sollen, ohne Zugriff auf alle vorher verschlusselten LUKS2-Datentrager zu verlieren. Ahnlich wie bei --tpm2-pcrs= konnen 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 Uberprufung, ob der Datentrager in Abhangigkeit 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 Datentrager nicht verloren geht, falls ein offentlicher Schlussel registriert wird, fur den keine gultige Signatur fur den aktuellen PCR-Zustand verfugbar ist. Falls die bereitgestellte Signatur die Kombination aus aktuellem PCR-Zustand und offentlichen Schlussel nicht entsperrt, wird keine Position registriert und die Aktion wird fehlschlagen. Falls keine Signaturdatei angegeben ist oder gefunden wird, erfolgt keine solche Sicherheitsuberprufung. Hinzugefugt in Version 252. --tpm2-pcrlock=PFAD Konfiguriert eine TPM2-Pcrlock-Richtlinie, an die Verschlusselung angebunden werden soll. Erwartet einen Pfad zu einer Pcrlock-Richtliniendatei, wie sie vom Werkzeug systemd-pcrlock(8) erstellt wird. Falls ein TPM2-Gerat 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. Hinzugefugt in Version 255. WEITERE OPTIONEN Die folgenden zusatzlichen Optionen werden verstanden: --wipe-slot=POSITION[,POSITION] Bereinigt einen oder mehrere LUKS2-Schlusselpositionen. Akzeptiert eine Kommata-getrennte Liste von numerischen Positionsindices oder die besondere Zeichenkette >>all<< (um alle Schlusselpositionen zu bereinigen), >>empty<< (um alle Schlusselpositionen zu bereinigen, die mit einer leeren Passphrase entsperrt sind), >>password<< (um alle Schlusselpositionen zu bereinigen, die mit einer traditionellen Passphrase entsperrt sind), >>recovery<< (um alle Schlusselpositionen zu bereinigen, die mit einem Wiederherstellungsschlussel entsperrt sind), >>pkcs11<< (um alle Schlusselpositionen zu bereinigen, die mit einem PKCS#11-Token entsperrt sind), >>fido2<< (um alle Schlusselpositionen zu bereinigen, die mit einem Fido2-Token entsperrt sind), >>tpm2<< (um alle Schlusselpositionen 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 Vorsichtsmassnahme wird eine Aktion, die alle Positionen ohne Ausnahme bereinigt (so dass der Datentrager uberhaupt nicht mehr entsperrt werden kann, ausser der Datentrager-Schlussel ist bekannt), abgelehnt. Dieser Schalter kann alleine verwandt werden. In diesem Fall wird nur die angefragte Bereinigungsaktion ausgefuhrt. Er kann auch in Kombination mit einer der oben aufgefuhrten Registrierungsoptionen verwandt werden. In diesem Fall wird zuerst die Registrierung abgeschlossen und nur wenn das erfolgreich war, wird die Bereinigungsaktion ausgefuhrt -- und die frisch hinzugefugte 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 --unlock-tpm2-device=auto Der obige Befehl wird den TPM2-Chip registrieren und dann alle vorher erstellten TPM2-Registrierungen auf dem LUKS2-Datentrager 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 Andern 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 Hinzugefugt in Version 248. --list-devices Zeigt eine Liste von Kandiaten-Blockgeraten, auf denen dieser Befehl agieren konnte. Insbesondere zahlt dies Blockgerate auf, die derzeit vorhanden sind sowie einen LUKS-Superblock enthalten und zeigt ihren Gerateknotenpfad zusammen mit allen ihren Symlinks. Das Gerat muss die Erweiterung hmac-secret implementieren, um nutzbar zu sein. Hinzugefugt in Version 257. -h, --help Zeigt einen kurzen Hilfetext an und beendet das Programm. --version Zeigt eine kurze Versionszeichenkette an und beendet das Programm. --no-pager Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter. ZUGANGSBERECHTIGUNGEN systemd-cryptenroll unterstutzt die durch ImportCredential=/LoadCredential=/SetCredential= implementierte Dienste-Zugangsberechtigungslogik (siehe systemd.exec(5) zu Details). Die folgenden Zugangsberechtigungen werden unterstutzt, wenn sie hereingereicht werden: cryptenroll.passphrase, cryptenroll.new-passphrase Kann eine Passphrase zum Entsperren des Datentragers bzw. zum neuen Registrieren enthalten. Hinzugefugt in Version 256. cryptenroll.tpm2-pin, cryptenroll.new-tpm2-pin Kann eine TPM2-PIN zum Entsperren des Datentragers bzw. zum neuen Registrieren enthalten. Hinzugefugt in Version 256. cryptenroll.fido2-pin Falls ein FIDO2-Token registriert wird, kann diese die PIN des Tokens enthalten. Hinzugefugt in Version 256. cryptenroll.pkcs11-pin Falls ein PKCS#11-Token registriert wird, kann diese die PIN des Tokens enthalten. Hinzugefugt in Version 256. EXIT-STATUS Bei Erfolg wird 0 zuruckgegeben, 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. UAPI.7-Linux TPM-PCR-Registratur https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/ UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 260.1 SYSTEMD-CRYPTENROLL(1)