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

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 oder einen Wiederherstellungsschlüssel bereitzustellen (d.h. einen der letzteren beiden Schlüsseltypen). Beispielsweise ist es derzeit nicht möglich, ein Gerät mit einem FIDO2-Schlüssel zu entsperren, um einen neuen FIDO2-Schlüssel zu registrieren. Um einen neuen FIDO2-Schlüssel zu registrieren, ist es daher notwendig, eine breits registrierte Passphrase oder einen Wiederherstellungsschlüssel bereitzustellen. Falls daher in der Zukunft ein Schlüsselwechsel gewünscht ist, wird im Allgemeinen empfohlen, TPM2-, FIDO2-, PKCS#11-Schlüsselregistrierung mit derRegistrierung einer regulären Passphrase oder eines Wiederherstellungsschlüssels zu kombinieren.

Beachten Sie auch, dass die Registrierung mehrerer FIDO2-Token derzeit nicht sehr nützlich ist, da beim Entsperren systemd-cryptsetup nicht identifizieren kann, welcher Token derzeit eingesteckt ist und daher nicht weiß, welche Authentifizierungsanfrage zu dem Gerät gesandt werden soll. Diese Beschränkung betrifft Token nicht, die mit PKCS#11 registriert wurden, da Token dieser Art sofort (vor der Authentifizierung) identifiziert werden können.

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.

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

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

--pkcs11-token-uri=URI
    Registriert einen PKCS#11-Sicherheits-Token oder eine Smartcard (z.B. einen YubiKey). Erwartet eine PKCS#11-Smartcard-URI, die sich auf den Token bezieht. Alternativ kann der besondere Wert »auto« angegeben werden, um automatisch die URI des aktuell eingesteckten Sicherheits-Tokens zu bestimmen (davon darf es nur genau einen geben). Der besondere Wert »list« kann zum Aufzählen aller derzeit eingesteckten geeigneten PKCS#11-Token verwandt werden. Der Sicherheits-Token muss ein RSA-Schlüsselpaar enthalten, das zum Verschlüsseln des zufällig erstellten Schlüssels verwandt wird, der zum Entsperren des LUKS2-Datenträgers eingesetzt wird. Der verschlüsselte Schlüssel wird dann in dem LUKS2-JSON-Token-Kopfzeilenbereich gespeichert.

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

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

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

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

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

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

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

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

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

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

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

--tpm2-pcrs= [PCR…]
    Konfiguriert die TPM2 PCRs (Plattform-Konfigurationsregister), an die die mittels --tpm2-device= erbetene Registrierung angebunden werden soll. Akzeptiert eine durch »+« getrennte Liste von numerischen PCR-Indices im Bereich 0…23. Falls nicht verwandt, wird standardmäßig nur PCR 7 verwandt. Falls eine leere Zeichenkette festgelegt ist, wird die Registrierung an überhaupt keine PCRs gebunden. PCRs erlauben das Anbinden der Registrierung an bestimmte Softwareversionen und an den Systemzustand, so dass der registrierte Entsperrschlüssel nur zugreifbar ist (kann »entsiegelt werden«), falls die festgelegte vertrauenswürdige Software und/oder Konfiguration verwandt wird.

    Tabelle 1. Gut-bekannte PCR-Definitionen
    PCR | Erklärung
    0 | Ausführbarer Code der Kernsystem-Firmware; ändert sich bei Firmware-Aktualisierungen
    1 | Konfiguration der Kernsystem-Firmware-Daten/Rechner-Plattform; enthält typischerweise die Serien- und Modellnummer, ändert sich beim Austausch grundlegender Hardware-/CPU-/RAM-Komponenten
    2 | Erweiterter oder austauschbarer ausführbarer Code; einschließlich Options-ROMs und austauschbarer Hardware
    3 | Erweiterte oder austauschbare Firmware-Daten; einschließlich Informationen über austauschbare Hardware
    4 | Systemstartprogramm und zusätzliche Treiber; Änderungen an Systemstart-Aktualisierungen. Das Shim-Projekt wird das PE-Programm, das es in Folge lädt, in dieses PCR einmessen. Falls der Linux-Kernel als UEFI-PE-Programm aufgerufen wird, wird es hier auch eingemessen. sd-stub(7) misst vom ESP eingelesene Systemerweiterungs-Abbilder hier auch ein (siehe systemd-sysext(8)).
    5 | GPT-/Partitionstabelle; ändert sich, wenn Partitionen hinzugefügt, verändert oder entfernt werden
    6 | Leistungszustandsereignisse; ändern sich beim Suspendieren/Schlafen des Systems
    7 | Sicherer Systemstartzustand; ändert sich, wenn der UEFI-SecureBoot-Modus aktiviert/deaktiviert wird oder sich Firmware-Zertifikate (PK, KEK, db, dbx, …) ändern. Das Shim-Projekt wird die meisten (nicht MOK-) Zertifikate und SBAT-Daten in dieses PCR einmessen.
    9 | Der Linux-Kernel misst alle Initrds, die er empfängt, in dieses PCR.
    10 | Das IMA-Projekt misst seinen Laufzeitzustand in dieses PCR.
    11 | systemd-stub(7) misst das ELF-Kernelabbild, die eingebettete Initrd und andere Nutzlastdaten des PE-Abbildes, in das sie abgelegt sind, in diesen PCR. Anders als bei PCR 4 (in das die gleichen Dateien eingemessen werden sollten), sollte dieser PCR-Wert leichter vorzuberechnen sein, da er nur die statischen Anteile des PE-Programms enthält. Verwenden Sie diesen PCR, um TPM-Richtlinien an ein bestimmtes Kernelabbild, möglicherweise mit eingebetteter Initrd, zu binden. systemd-pcrphase.service(8) misst Systemstartphasen-Zeichenketten in diesen PCR zu verschiedenen Meilensteinen im Systemstartprozess.
    12 | systemd-boot(7) misst die angegebene Kernelbefehlszeile in dieses PCR. systemd-stub(7) misst die 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. (Beachten Sie, dass die Kernelbefehlszeile zweimal eingemessen werden könnte, wenn systemd-boot und systemd-stub in Kombination verwandt werden!)
    13 | systemd-stub(7) misst jedes systemd-sysext(8)-Abbild, das es lädt und an den gestarteten Kernel übergibt, in diesen PCR.
    14 | Das Shim-Projekt misst seine »MOK«-Zertifikate und -Hashes in dieses PCR.

    Für die meisten Anwendungen sollte es ausreichen, sich gegen PCR 7 zu binden (und möglicherweise PCR 14, falls Shim/MOK gewünscht ist), da dies die Messung zuverlässiger Zertifikate (und möglicherweise Hashes) einschließt, die zum Validieren aller Komponenten des Systemstartprozesses bis hin (und einschließlich) des Betriebssystemkerns verwandt werden. Um Firmware- und Betriebssystemaktualisierungen zu vereinfachen, ist es typischerweise nicht empfehlenswert, PCRs wie 0 und 2 in das Einbinden bei der Registrierung aufzunehmen, da der von ihnen abgedeckte Programm-Code bereits indirekt über die in PCR 7 eingemessenen Zertifikate geschützt sein sollte. Prüfung über diese Zertifikate 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 Code-Signaturen werden sich wahrscheinlich auch mit bereits existierenden Zertifikaten validieren.

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

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

    Beachten Sie den Unterschied zwischen --tpm2-pcrs= und --tpm2-public-key-pcrs=: Ersterer bindet die Entschlüsselung an die aktuellen, angegebenen PCR-Werte; Letzteres bindet die Entschlüsselung an eine Gruppe von PCR-Werten, für die eine Signatur durch den angegebenen öffentlichen Schlüssel bereitgestellt werden kann. Leztere ist daher in Szenarien nützlicher, bei denen Software-Aktualisierungen möglich sein sollen, ohne Zugriff auf alle vorher verschlüsselten LUKS2-Datenträger zu verlieren.

    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.

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

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

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

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

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

    Oder zum Ersetzen eines registrierten leeren Passworts durch TPM2:

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

-h, --help
    Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version
    Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

EXIT-STATUS

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

SIEHE AUCH

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

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