Scroll to navigation

SYSTEMD-CRYPTENROLL(1) systemd-cryptenroll SYSTEMD-CRYPTENROLL(1)

BEZEICHNUNG

systemd-cryptenroll - PKCS#11-, FIDO2-, TPM2-Token/-Geräte bei LUKS2-verschlüsselten Datenträgern registrieren

ÜBERSICHT

systemd-cryptenroll [OPTIONEN…] [GERÄT]

BESCHREIBUNG

systemd-cryptenroll ist ein Werkzeug zum Registrieren von Hardware-Sicherheits-Token und -Geräten an LUKS2-verschlüsselten Datenträgern, die dann zum Entsperren des Datenträgers während des Systemstarts verwandt werden können. Es unterstützt insbesondere die Registrierung von Token und Anmeldedaten von folgenden Typen:

1.PKCS#11-Sicherheits-Token und -Smartcards, die ein RSA- oder EC-Schlüsselpaar transportieren (z.B. verschiedene YubiKeys).

2.FIDO2-Sicherheits-Token, die die Erweiterung »hmac-secret« implementieren (die meisten FIDO2-Schlüssel, einschließlich YubiKeys)

3.TPM2-Sicherheitsgeräte

4.Reguläre Passphrasen

5.Rettungsschlüssel. Diese entsprechen regulären Ausdrücken, werden allerdings zufällig auf dem Computer erstellt und haben daher im Allgemeinen eine höhere Entropie als vom Benutzer ausgewählte Passphrasen. Ihr Zeichensatz wurde entwickelt, um sicherzustellen, dass sie leicht einzutippen sind und weiterhin eine hohe Entropie haben. Sie können von dem Bildschirm auch mittels eines QR-Codes eingelesen werden. Rettungsschlüssel können zum Entsperren von LUKS2-Datenträgern verwandt werden, wann immer Passphrasen akzeptiert werden. Sie sind dazu gedacht, in Kombination mit einem registrierten Hardware-Sicherheits-Token als Rettungsoption verwandt zu werden, wenn der Token verloren geht.

Das Werkzeug kann zusätzlich zum Aufzählen derzeit registrierter Sicherheits-Token und dem Bereinigen einer Teilmenge von ihnen verwandt werden. Letzteres kann mit der Registrieraktion eines neuen Sicherheits-Token kombiniert werden, um Registrierungen zu aktualisieren oder zu ersetzen.

Das Werkzeug unterstützt nur LUKS2-Datenträger, da es die Metainformationen des Tokens in dem LUKS2-JSON-Token-Bereich speichert, der bei anderen Verschlüsselungsformaten nicht vorhanden ist.

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

TPM2-PCRs und -Richtlinien

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

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

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

Tabelle 1. Gut-bekannte PCR-Definitionen

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.

ENTSPERREN

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

--unlock-key-file=PFAD

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

Hinzugefügt in Version 252.

--unlock-fido2-device=PFAD

Ein FIDO2-Gerät anstelle eines aus der Standardeingabe gelesenen Passwortes/einer Passphrase zum Entsperren des Datenträgers verwenden. Erwartet ein Hidraw-Gerät, das sich auf ein FIDO2-Gerät bezieht (z. B. /dev/hidraw1). Alternativ kann der besondere Wert »auto« angegeben werden, um automatisch den Geräteknoten des aktuell eingesteckten Sicherheits-Token zu bestimmen (davon darf es nur genau einen geben). Diese automatische Erkennung wird nicht unterstützt, falls auch die Option --fido2-device= angegeben wird. Beachten Sie, dass derzeit FIDO2-Geräte, die ohne ein zugehörigen LUKS2-Token registriert wurden (d.h. --fido2-parameters-in-header=no), nicht zum Entsperren verwandt werden können.

Hinzugefügt in Version 253.

--unlock-tpm2-device=PFAD

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

Hinzugefügt in Version 256.

EINFACHE REGISTRIERUNG

Die folgenden Optionen, die zur Registrierung von Entsperrungen basierend auf einfacher Benutzereingabe verwandt werden können, werden verstanden:

--password

Registriert ein reguläres Passwort/eine reguläre Passphrase. Dieser Befehl entspricht größtenteils cryptsetup luksAddKey, allerdings in Kombination mit --wipe-slot= in einem Aufruf, siehe unten.

Hinzugefügt in Version 248.

--recovery-key

Registriert einen Rettungsschlüssel. Rettungsschlüssel sind größtenteils identisch zu Passphrasen, sind aber Computer-generiert statt durch Menschen ausgewählt und haben daher eine höhere garantierte Entropie. Die Schlüssel verwenden einen Zeichensatz, der leicht einzugeben ist und vom Bildschirm mittels eines QR-Codes eingelesen werden kann.

Hinzugefügt in Version 248.

PKCS#11 ENROLLMENT

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

--pkcs11-token-uri=URI

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

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

Um einen LUKS2-Datenträger mit einem registrierten PKCS#11-Sicherheits-Token zu entsperren, legen Sie die Option pkcs11-uri= in der zutreffenden Zeile in /etc/crypttab fest:

meindatenträger /dev/sda1 - pkcs11-uri=auto

Siehe crypttab(5) für ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der zugehörigen Zeile in /etc/crypttab.

Hinzugefügt in Version 248.

FIDO2 ENROLLMENT

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

--fido2-device=PFAD

Registriert einen FIDO2-Sicherheits-Token, der die Erweiterung »hmac-secret« implementiert (z.B. einen YubiKey). Erwartet ein Hidraw-Gerät, das sich auf ein FIDO2-Gerät bezieht (z.B. /dev/hidraw1). Alternativ kann der besondere Wert »auto« angegeben werden, um automatisch den Geräteknoten des aktuell eingesteckten Sicherheits-Tokens zu bestimmen (davon darf es nur genau einen geben). Diese automatische Erkennung wird nicht unterstützt, falls auch die Option --unlock-fido2-device= angegeben wird. Der besondere Wert »list« kann zum Aufzählen aller derzeit eingesteckten geeigneten FIDO2-Token verwandt werden. Beachten Sie, dass viele Hardware-Sicherheits-Token, die FIDO2 implementieren, ebenfalls den älteren PKCS#11-Standard implementieren. Typischerweise sollte FIDO2 bevorzugt werden, da es leichter zu verwenden und moderner ist.

Um einen LUKS2-Datenträger mit einem registrierten FIDO2-Sicherheits-Token zu entsperren, legen Sie die Option fido2-device= in der zutreffenden Zeile in /etc/crypttab fest:

meindatenträger /dev/sda1 - fido2-device=auto

Siehe crypttab(5) für ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der zugehörigen Zeile in /etc/crypttab.

Hinzugefügt in Version 248.

--fido2-credential-algorithm=ZEICHENKETTE

Gibt den bei der Erstellung von Zugangsberechtigungen zu verwendenden COSE-Algorithmus an. Der Vorgabewert ist »es256«. Unterstützte Werte sind »es256«, »s256« und »eddsa«.

»es256« bezeichnet ECDSA über NIST P-256 mit SHA-256. »rs256« bezeichnet 2048-bit RSA mit PKCS#1.5-Auffüllung und SHA-256. »eddsa« bezeichnet EDDSA über Curve25519 mit SHA-512.

Beachten Sie, dass Ihr Authentikator sich entscheiden könnte, nicht alle Algorithmen zu unterstützen.

Hinzugefügt in Version 251.

--fido2-salt-file=PFAD

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

Hinzugefügt in Version 257.

--fido2-parameters-in-header=LOGISCH

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

Hinzugefügt in Version 257.

--fido2-with-client-pin=LOGISCH

Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer eine PIN beim Entsperren des Datenträgers eingeben muss (die FIDO2-Funktionalität »clientPin«). Standardmäßig »yes«. (Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalität »clientPin« überhaupt nicht unterstützt oder das Aktivieren oder Deaktivieren nicht erlaubt.)

Hinzugefügt in Version 249.

--fido2-with-user-presence=LOGISCH

Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer seine Anwesenheit beim Entsperren des Datenträgers nachweisen muss (die FIDO2-Funktionalität »up«). Standardmäßig »yes«. (Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalität »up« überhaupt nicht unterstützt oder das Aktivieren oder Deaktivieren nicht erlaubt.)

Hinzugefügt in Version 249.

--fido2-with-user-verification=LOGISCH

Steuert beim Registrieren eines FIDO2-Sicherheits-Tokens, ob der Benutzer beim Entsperren des Datenträgers überprüft werden muss (die FIDO2-Funktionalität »uv«). Standardmäßig »no«. (Beachten Sie: Diese Einstellung ist wirkungslos, falls der Sicherheits-Token die Funktionalität »uv« überhaupt nicht unterstützt oder das Aktivieren oder Deaktivieren nicht erlaubt.)

Hinzugefügt in Version 249.

TPM2-REGISTRIERUNG

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

--tpm2-device=PFAD

Registriert einen TPM2-Sicherheits-Chip. Erwartet einen Geräteknotenpfad, der sich auf einen TPM2-Chip bezieht (z.B. /dev/tpmrm0). Alternativ kann der besondere Wert »auto« angegeben werden, um automatisch den Geräteknoten des aktuell ermittelten TPM2-Geräts zu bestimmen (davon darf es nur genau einen geben). Der besondere Wert »list« kann zum Aufzählen aller derzeit eingesteckten geeigneten TPM2-Chips verwandt werden.

Um einen LUKS2-Datenträger mit einem registrierten TPM2-Sicherheits-Chip zu entsperren, legen Sie die Option tpm2-device= in der zutreffenden Zeile in /etc/crypttab fest:

meindatenträger /dev/sda1 - tpm2-device=auto

Siehe crypttab(5) für ein umfassenderes Beispiel eines Aufrufs von systemd-cryptenroll und der zugehörigen Zeile in /etc/crypttab.

Verwenden Sie --tpm2-pcrs= (siehe unten), um zu konfigurieren, an welchen TPM2-PCR-Index die Registrierung angebunden werden soll.

Hinzugefügt in Version 248.

--tpm2-device-key=PFAD

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

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

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

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

systemd-analyze srk > srk.tpm2b_public

Hinzugefügt in Version 255.

--tpm2-seal-key-handle=REFERENZ

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

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

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

Hinzugefügt in Version 255.

--tpm2-pcrs=PCR[+PCR…]

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

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

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

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

Hinzugefügt in Version 248.

--tpm2-with-pin=LOGISCH

Beim Registrieren eines TPM2-Gerätes steuert dies, ob der Benutzer eine PIN beim Entsperren des Laufwerks zusätzlich zur PCR-Anbindung angeben muss, basierend auf der TPM2-Richtlinien-Authentifizierung. Standardmäßig »no«. Obwohl es PIN heißt, können alle Zeichen verwandt werden, nicht nur Zahlen.

Beachten Sie, dass eine inkorrekte PIN-Eingabe beim Entsperren den TPM-Wörterbuch-Sperrmechanismus erhöht und Benutzer für eine längere Zeit aussperren könnte, abhängig von seiner Konfiguration. Der Sperrmechanismus ist eine globale Eigenschaft des TPM, systemd-cryptenroll steuert oder konfiguriert den Sperrmechanismus nicht. Sie können die tpm2-tss-Werkzeuge zur Untersuchung oder Konfiguration des Wörterbuch-Sperrmechanismus mit den Befehlen tpm2_getcap(1) bzw. tpm2_dictionarylockout(1) verwenden.

Hinzugefügt in Version 251.

--tpm2-public-key=PFAD, --tpm2-public-key-pcrs=PCR[+PCR…], --tpm2-signature=PFAD

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

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

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

Hinzugefügt in Version 252.

--tpm2-pcrlock=PFAD

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

Hinzugefügt in Version 255.

WEITERE OPTIONEN

Die folgenden zusätzlichen Optionen werden verstanden:

--wipe-slot=POSITION[,POSITION…]

Bereinigt einen oder mehrere LUKS2-Schlüsselpositionen. Akzeptiert eine Kommata-getrennte Liste von numerischen Positionsindices oder die besondere Zeichenkette »all« (um alle Schlüsselpositionen zu bereinigen), »empty« (um alle Schlüsselpositionen zu bereinigen, die mit einer leeren Passphrase entsperrt sind), »password« (um alle Schlüsselpositionen zu bereinigen, die mit einer traditionellen Passphrase entsperrt sind), »recovery« (um alle Schlüsselpositionen zu bereinigen, die mit einem Wiederherstellungsschlüssel entsperrt sind), »pkcs11« (um alle Schlüsselpositionen zu bereinigen, die mit einem PKCS#11-Token entsperrt sind), »fido2« (um alle Schlüsselpositionen zu bereinigen, die mit einem Fido2-Token entsperrt sind), »tpm2« (um alle Schlüsselpositionen zu bereinigen, die mit einem TPM2-Chip entsperrt sind) oder jede Kombination dieser Zeichenketten oder numerischen Indices, wodurch dann alle Positionen, die auf einen davon passen, bereinigt werden. Als Vorsichtsmaßnahme wird eine Aktion, die alle Positionen ohne Ausnahme bereinigt (so dass der Datenträger überhaupt nicht mehr entsperrt werden kann, außer der Datenträger-Schlüssel ist bekannt), abgelehnt.

Dieser Schalter kann alleine verwandt werden. In diesem Fall wird nur die angefragte Bereinigungsaktion ausgeführt. Er kann auch in Kombination mit einer der oben aufgeführten Registrierungsoptionen verwandt werden. In diesem Fall wird zuerst die Registrierung abgeschlossen und nur wenn das erfolgreich war, wird die Bereinigungsaktion ausgeführt — und die frisch hinzugefügte Position wird immer von der Bereinigung ausgeschlossen. Die Kombination von Registrierung und Positionsbereinigung kann daher zur Aktualisierung bestehender Registrierungen verwandt werden:

systemd-cryptenroll /dev/sda1 --wipe-slot=tpm2 --tpm2-device=auto

Der obige Befehl wird den TPM2-Chip registrieren und dann alle vorher erstellten TPM2-Registrierungen auf dem LUKS2-Datenträger bereinigen, wodurch nur die frisch erstellte verbleibt. Die Kombination von Bereinigung und Registrierung kann auch zum Ersetzen der Registrierung von verschiedenen Typen verwandt werden, beispielsweise zum Ändern einer PKCS#11-Registrierung auf eine FIDO2-Registrierung:

systemd-cryptenroll /dev/sda1 --wipe-slot=pkcs11 --fido2-device=auto

Oder zum Ersetzen eines registrierten leeren Passworts durch TPM2:

systemd-cryptenroll /dev/sda1 --wipe-slot=empty --tpm2-device=auto

Hinzugefügt in Version 248.

--list-devices

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

Hinzugefügt in Version 257.

-h, --help

Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version

Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

--no-pager

Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.

ZUGANGSBERECHTIGUNGEN

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

cryptenroll.passphrase, cryptenroll.new-passphrase

Kann eine Passphrase zum Entsperren des Datenträgers bzw. zum neuen Registrieren enthalten.

Hinzugefügt in Version 256.

cryptenroll.tpm2-pin, cryptenroll.new-tpm2-pin

Kann eine TPM2-PIN zum Entsperren des Datenträgers bzw. zum neuen Registrieren enthalten.

Hinzugefügt in Version 256.

cryptenroll.fido2-pin

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

Hinzugefügt in Version 256.

cryptenroll.pkcs11-pin

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

Hinzugefügt in Version 256.

EXIT-STATUS

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

BEISPIELE

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

SIEHE AUCH

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

ANMERKUNGEN

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

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.

systemd 257.1