Datenträgername verschlüsseltes_Gerät Schlüsseldatei Optionen

1.Das erste Feld enthält den Namen des resultierenden Datenträgers mit entschlüsselten Daten; sein Blockgerät wird unterhalb von /dev/mapper/ eingerichtet.

2.Das zweite Feld enthält einen Pfad zu dem darunterliegenden Blockgerät oder der Datei oder eine Festlegung eines Blockgerätes mittels »UUID=« gefolgt von der UUID.

3.Das dritte Feld gibt einen absoluten Pfad auf eine Datei mit dem Verschlüsselungsschlüssel an. Optional kann dem Pfad »:« und eine /etc/fstab-artige Geräteangabe folgen (z.B. beginnend mit »LABEL=« oder ähnlichem). In diesem Fall wird der Pfad relativ zu der Wurzel des festgelegten Gerätedateisystems angenommen. Falls das Feld nicht vorhanden oder »none« oder »-« lautet, wird eine Schlüsseldatei, die nach dem zu entsperrenden Datenträger benannt ist (d.h. der ersten Spalte der Zeile), der ».key« angehängt ist, automatisch aus den Verzeichnissen /etc/cryptsetup-keys.d/ und /run/cryptsetup-keys.d/ geladen, falls vorhanden. Andernfalls muss das Passwort während des Systemstarts manuell eingegeben werden. Für die Verschlüsselung des Auslagerungsbereichs kann /dev/urandom als Schlüsseldatei verwandt werden, was zu einem zufälligen Schlüssel führt.

Falls sich der festgelegte Schlüsseldateipfad auf ein AF_UNIX-Datenstrom-Socket im Dateisystem bezieht, wird der Schlüssel beschafft, indem eine Verbindung zu dem Socket aufgebaut und er aus der Verbindung gelesen wird. Dies ermöglicht der Implementierung eines Dienstes, die Schlüsselinformationen dynamisch bereitzustellen, zu dem Zeitpunkt, zu dem sie benötigt werden. Details sind weiter unten beschrieben.

4.Das vierte Feld, falls vorhanden, ist eine Kommata-getrennte Liste von Optionen. Die unterstützten Optionen sind nachfolgend aufgeführt.

1.Am offensichtlichsten ist, dass der Benutzer interaktiv während der Datenträgeraktivierung (d.h. typischerweise beim Systemstart) danach gefragt und gebeten werden kann, die notwendigen Passphrasen einzugeben.

2.Der (entschlüsselte) Schlüssel kann aus einer Datei auf der Platte, möglicherweise einem Wechselmedium, eingelesen werden. Das dritte Feld jeder Zeile kodiert den Ort, Details sind weiter oben beschrieben.

3.Der (entschlüsselte) Schlüssel kann von einem anderen Dienst erbeten werden, indem anstelle einer Schlüsseldatei im dritten Feld ein AF_UNIX-Dateisystem-Socket festgelegt wird. Details sind weiter oben und nachfolgend beschrieben.

4.Der Schlüssel kann über ein PKCS#11-kompatibles Hardware-Token oder eine Smartcard beschafft werden. In diesem Fall wird ein verschlüsselter Schlüssel auf einer Platte/einem Wechselmedium gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Der verschlüsselte Schlüssel wird dann durch den PKCS#11-Token mittels eines darauf gespeicherten RSA-Schlüssels entschlüsselt und dann für das Entsperren des verschlüsselten Datenträgers verwandt. Verwenden Sie die nachfolgend beschriebene Option pkcs11-uri=, um diesen Mechanismus zu verwenden.

5.Auf ähnliche Weise kann der Schlüssel mittels eines FIDO2-kompatiblen Hardware-Security-Tokens (der die Erweiterung »hmac-secret« implementieren muss) beschafft werden. In diesem Fall wird ein zufällig erstellter Schlüssel während der Registrierung auf der Platte/dem Wechsellaufwerk gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Der zufällige Schlüssel wird mit einer indizierten Hash-Funktion (HMAC) auf dem FIDO2-Token gehasht, wobei ein auf dem Token gespeicherter geheimer Schlüssel verwandt wird, der diesen nie verlässt. Der daraus entstandene Hash-Wert wird dann als Schlüssel benutzt, um den verschlüsselte Datenträger zu entsperren. Verwenden Sie die nachfolgend beschriebene Option fido2-device=, um diesen Mechanismus zu verwenden.

6.Auf ähnliche Weise kann der Schlüssel mittels eines TPM2-Sicherheits-Chips beschafft werden. In diesem Fall wird (während der Registrierung) ein zufällig erstellter Schlüssel, der durch einen asymmetrischen, vom TPM2-Chip abgeleiteten Schlüssel verschlüsselt wurde, auf der Platte/dem Wechsellaufwerk gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Verwenden Sie die nachfolgend beschriebene Option tpm2-device=, um diesen Mechanismus zu verwenden.

Legt die zu verwendende Chiffre fest. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option. Eine Chiffre mit unvorhersagbaren IV-Werten, wie »aes-cbc-essiv:sha256«, wird empfohlen. Eingebettete Kommata in der Festlegung der Chiffre müssen durch vorangestellte Rückwärtsschrägstriche maskiert werden, wie im nachfolgenden Beispiel gezeigt.

Hinzugefügt in Version 186.

Erlaubt die Durchleitung von Discard-Anfragen an das verschlüsselte Blockgerät. Dies verbessert die Leistung bei SSD-Speichern, hat aber Auswirkungen auf die Sicherheit.

Hinzugefügt in Version 207.

Legt den für Passwörter zu verwendenden Hash fest. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option.

Hinzugefügt in Version 186.

Verwendet ein abgetrenntes (separates) Metadatengerät oder -datei, in der die Kopfzeilen, die den oder die Hauptschlüssel enthalten, gespeichert sind. Diese Option ist nur für LUKS- und TrueCrypt/VeraCrypt-Geräte relevant. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option.

Optional kann dem Pfad ein »:« und eine /etc/fstab-Gerätespezifikation folgen (z.B. beginnend mit »UUID=« oder ähnlich). In diesem Fall ist der Pfad relativ zu der Dateisystemwurzel des Geräts. Das Gerät wird automatisch nur für die LUKS-Geräteaktivierungsdauer eingehängt.

Hinzugefügt in Version 219.

Legt die Anzahl der am Anfang der Schlüsseldatei zu überspringenden Byte fest. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option.

Hinzugefügt in Version 187.

Legt die maximale Anzahl der aus der Schlüsseldatei zu lesenden Byte fest. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option. Diese Option wird im einfachen Verschlüsselungsmodus ignoriert, da dann die Schlüsseldateigröße durch die Schlüsselgröße gegeben ist.

Hinzugefügt in Version 188.

Falls aktiviert, wird die angegebene Schlüsseldatei gelöscht, nachdem der Datenträger aktiviert wurde oder wenn die Aktivierung fehlschlug. Dies ist insbesondere nützlich, wenn die Schlüsseldatei vor der Aktivierung nur flüchtig erlangt wurde (z.B. über eine Datei in /run/, die durch einen vor der Aktivierung ausgeführten Dienst erzeugt wurde) und nach der Verwendung entfernt werden muss. Standardmäßig aus.

Hinzugefügt in Version 246.

Legt die Schlüsselposition, mit der die Passphrase oder der Schlüssel verglichen werden soll, fest. Falls die Schlüsselposition nicht auf die übergebene Passphrase oder den Schlüssel passt, aber eine andere passen würde, schlägt die Einrichtung des Gerätes dennoch fehl. Diese Option impliziert luks. Siehe cryptsetup(8) für mögliche Werte. Die Vorgabe ist, alle Schlüsselpositionen sequenziell durchzuprobieren.

Hinzugefügt in Version 209.

Legt die Zeitüberschreitung für das Gerät, auf dem die Schlüsseldatei liegt oder das Gerät, das als Schlüsseldatei verwandt wird, fest und fällt auf ein Passwort zurück, falls auf dieses Gerät nicht zugegriffen werden kann. Siehe systemd-cryptsetup-generator(8) für Schlüsseldateien auf externen Geräten.

Hinzugefügt in Version 243.

Erzwingt den LUKS-Modus. Wenn dieser Modus verwandt wird, werden die folgenden Optionen ignoriert, da sie durch die LUKS-Kopfzeilen auf dem Gerät bereitgestellt werden: cipher=, hash=, size=.

Hinzugefügt in Version 186.

Entschlüsselt BitLocker-Gerät. Entschlüsselungsparameter werden durch Cryptsetup aus dem BitLocker-Header abgeleitet.

Hinzugefügt in Version 246.

Markiert, dass dieses Kryptogerät Netzwerk benötigt. Es wird nach der Verfügbarkeit des Netzwerkes gestartet, ähnlich wie mit _netdev markierte systemd.mount(5)-Units. Die Dienste-Unit zur Einrichtung dieses Gerätes wird zwischen remote-fs-pre.target und remote-cryptsetup.target einsortiert, statt zwischen cryptsetup-pre.target und cryptsetup.target.

Tipp: Falls dieses Gerät für einen in fstab(5) festgelegten Einhängepunkt verwandt wird, sollte die Option _netdev auch für den Einhängepunkt verwandt werden. Andernfalls könnte eine Abhängigkeitsschleife erstellt werden, bei der der Einhängepunkt durch local-fs.target hereingezogen, während der Dienst zur Konfiguration des Netzwerkes normalerweise nach dem Einhängen des lokalen Dateisystems gestartet wird.

Hinzugefügt in Version 235.

Dieses Gerät wird nicht zu cryptsetup.target hinzugefügt. Das bedeutet, dass es beim Systemstart nicht automatisch entsperrt wird, außer etwas anderes zieht es herein. Falls insbesondere das Gerät als Einhängepunkt verwandt wird, wird es während des Systemstarts automatisch entsperrt, außer der Einhängepunkt selbst ist auch mit noauto deaktiviert.

Hinzugefügt in Version 186.

Dieses Gerät wird keine harte Abhängigkeit von cryptsetup.target sein. Es wird weiterhin hereingezogen und gestartet, aber das System wird nicht darauf warten, dass das Gerät auftaucht und entsperrt wird und der Systemstart wird nicht fehlschlagen, falls das nicht klappt. Beachten Sie, dass andere Units weiterhin von dem entsperrten Gerät abhängen und weiterhin fehlschlagen könnten. Falls insbesondere das Gerät als Einhängepunkt verwandt wird, muss der Einhängepunkt selbst auch die Option nofail haben, oder der Systemstart wird fehlschlagen, falls das Gerät nicht erfolgreich entsperrt wurde.

Hinzugefügt in Version 186.

Anfangsversatz im Gerät im Hintergrund, in 512-Byte-Sektoren. Diese Option ist nur für einfache Geräte relevant.

Hinzugefügt in Version 220.

Erzwingt den einfachen Verschlüsselungsmodus.

Hinzugefügt in Version 186.

Richtet das verschlüsselte Blockgerät schreibgeschützt ein.

Hinzugefügt in Version 186.

Führt die Verschlüsselung auf der gleichen CPU aus, auf der E/A übergeben wurde. Die Vorgabe ist die Verwendung einer unbegrenzten Arbeitswarteschlange, so dass die Verschlüsselungsarbeit automatisch zwischen verfügbaren CPUs ausbalanciert wird.

Dies benötigt Kernel 4.0 oder neuer.

Hinzugefügt in Version 242.

Deaktiviert das Abladen von Schreibaktionen in einen separaten Thread nach der Entschlüsselung. Es gibt einige Situationen, bei denen das Abladen der Schreibaktionen aus Entschlüsselungs-Threads in einen dedizierten Thread die Leistung deutlich senkt. Die Vorgabe ist, Schreibaktionen auf einen dedizierten Thread abzuladen, da es für den CFQ-Scheduler von Vorteil ist, wenn Schreibaktionen im gleichen Kontext übergeben werden.

Dies benötigt Kernel 4.0 oder neuer.

Hinzugefügt in Version 242.

Umgeht die interne Arbeitswarteschlange von dm-crypt und verarbeitet Leseanfragen synchron. Standardmäßig werden diese Anfragen in eine Warteschlange eingestellt und dann asynchron verarbeitet.

Dies benötigt Kernel 5.9 oder neuer.

Hinzugefügt in Version 248.

Umgeht die interne Arbeitswarteschlange von dm-crypt und verarbeitet Schreibanfragen synchron. Standardmäßig werden diese Anfragen in eine Warteschlange eingestellt und dann asynchron verarbeitet.

Dies benötigt Kernel 5.9 oder neuer.

Hinzugefügt in Version 248.

Wie viele 512-Byte-Sektoren der verschlüsselten Daten am Anfang übersprungen werden sollen. Dies unterscheidet sich von der Option offset= im Hinblick auf die im Initialisierungsvektor (IV) für die Berechnung verwandte Anzahl an Sektoren. Durch die Verwendung von offset= wird die IV-Berechnung durch die gleiche negative Anzahl verschoben. Falls daher offset=n übergeben wird, wird Sektor n eine Sektorennummer 0 für die IV-Berechnung erhalten. skip= bewirkt, dass Sektor n auch der erste Sektor des zugeordneten Gerätes ist, aber dabei die Nummer n für die IV-Erstellung hat.

Diese Option ist nur für einfache Geräte relevant.

Hinzugefügt in Version 220.

Legt die Schlüsselgröße in Bits fest. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option.

Hinzugefügt in Version 186.

Legt die Sektorgröße in Byte fest. Siehe cryptsetup(8) für mögliche Werte und den Vorgabewert dieser Option.

Hinzugefügt in Version 240.

Das verschlüsselte Gerät wird als Auslagerungsgerät benutzt. Es wird nach der Einrichtung des verschlüsselten Blockgerätes entsprechend mit mkswap(8) formatiert. Diese Option impliziert plain.

WARNUNG: Durch Verwendung der Option swap wird der Inhalt der benannten Partition während jedes Systemstarts zerstört. Stellen Sie daher sicher, dass das zugrundeliegende Blockgerät korrekt angegeben ist.

Hinzugefügt in Version 186.

Verwendet den TrueCrypt-Verschlüsselungsmodus. Beim Einsatz dieses Modus werden die folgenden Optionen ignoriert, da sie durch die TrueCrypt-Kopfzeilen bereitgestellt oder nicht anwendbar sind: cipher=, hash=, keyfile-offset=, keyfile-size=, size=.

Beim Einsatz dieses Modus wird die Passphrase aus der im dritten Feld übergebenen Datei gelesen. Es wird nur die erste Zeile dieser Datei ohne das Zeilenvorschubszeichen gelesen.

Beachten Sie, dass das TrueCrypt-Format sowohl Passphrasen als auch Schlüsseldateien zur Ableitung eines Passworts für den Datenträger verwendet. Daher müssen die Passphrase und alle Schlüsseldateien angegeben werden. Verwenden Sie tcrypt-keyfile=, um den absoluten Pfad zu allen Schlüsseldateien anzugeben. Bei der Verwendung einer leeren Passphrase in Kombination mit einer oder mehrerer Schlüsseldateien verwenden Sie »/dev/null« als Passwortdatei im dritten Feld.

Hinzugefügt in Version 206.

Verwendet den versteckten TrueCrypt-Datenträger. Diese Option impliziert tcrypt.

Dies bildet den versteckten Datenträger, das sich innerhalb des im zweiten Feld angegebenen Datenträgers befindet, ab. Beachten Sie, dass es keinen Schutz für den versteckten Datenträger gibt, falls stattdessen der äußere Datenträger eingehängt wird. Siehe cryptsetup(8) für weitere Informationen über diese Beschränkung.

Hinzugefügt in Version 206.

Legt den absoluten Pfad zu der für ein TrueCrypt-Datenträger zu verwendenden Schlüsseldatei fest. Dies impliziert tcrypt und kann mehr als einmal zur Angabe mehrerer Schlüsseldateien verwandt werden.

Lesen Sie beim Einsatz des TrueCrypt-Verschlüsselungsmodus den Eintrag zu tcrypt für das Verhalten der Passphrase und Schlüsseldateien.

Hinzugefügt in Version 206.

TrueCrypt im Systemverschlüsselungsmodus verwenden. Diese Option impliziert tcrypt.

Hinzugefügt in Version 206.

Prüft auf ein VeraCrypt-Datenträger. VeraCrypt ist eine Abspaltung von TrueCrypt, die größtenteils kompatibel ist, aber andere, stärkere Schlüsselableitungsalgorithmen verwendet, die ohne diesen Schalter nicht erkannt werden können. Aktivierung dieser Option könnte das Entsperren deutlich verlangsamen, da die Schlüsselableitung von VeraCrypt viel länger als die von TrueCrypt dauert. Diese Option impliziert tcrypt.

Hinzugefügt in Version 232.

Legt den Wert eines angepassten »Personal Iteration Multiplier« (PIM) fest, der im Bereich 0…2147468 für Standard-Veracrypt-Datenträger und 0…65535 für Veracrypt-Systemdatenträger sein kann. Ein Wert 0 impliziert die Vorgabe von Veracrypt. Diese Option wird nur wirksam, wenn tcrypt-veracrypt gesetzt ist.

Beachten Sie, dass VeraCrypt einen minimalen erlaubten PIM-Wert erzwingt, der von der Passwortstärke und dem für die Schlüsselableitung verwandten Hash-Algorithmus abhängt. Allerdings prüft veracrypt-pim= dies nicht gegen diese Schranken. Siehe die Veracrypt-Personal-Iteration-Multiplier[1]-Dokumentation für weitere Informationen.

Hinzugefügt in Version 254.

Legt die Zeitüberschreitung für die Abfrage eines Passworts fest. Falls keine Einheit angegeben ist, werden Sekunden verwandt. Unterstützte Einheiten sind s, ms, us, min, h, d. Eine Zeitüberschreitung von 0 wartet unendlich lang (dies ist die Vorgabe).

Hinzugefügt in Version 186.

Das verschlüsselte Blockgerät wird für den Einsatz als /tmp/ vorbereitet; es wird mittels mkfs(8) formatiert. Akzeptiert einen Dateisystemtyp als Argument, wie »ext4«, »xfs« oder »btrfs«. Falls kein Argument angegeben ist, ist »ext4« die Vorgabe. Diese Option impliziert plain.

WARNUNG: Durch Verwendung der Option tmp wird der Inhalt der benannten Partition während jedes Systemstarts zerstört. Stellen Sie daher sicher, dass das zugrundeliegende Blockgerät korrekt angegeben ist.

Hinzugefügt in Version 186.

Legt die maximale Anzahl an Abfragen des Benutzers nach einem Passwort fest. Die Vorgabe ist 3. Falls auf 0 gesetzt, wird der Benutzer unendlich oft nach einem Passwort gefragt.

Hinzugefügt in Version 186.

Akzeptiert ein logisches Argument, standardmäßig falsch. Falls wahr, wird niemals interaktiv nach einem Passwort/einer PIN gefragt. Nützlich für Systeme ohne Monitor.

Hinzugefügt in Version 249.

Falls das Verschlüsselungspasswort aus der Konsole ausgelesen wird, muss es zweimal eingegeben werden, um Tippfehler zu vermeiden.

Hinzugefügt in Version 186.

Steuert, ob Passwörter oder die PINs von Sicherheits-Token bei der Eingabe auch gleich auf der Konsole wieder ausgegeben werden. Akzeptiert einen logischen Wert oder die besondere Zeichenkette »masked«. Die Vorgabe ist password-echo=masked.

Falls aktiviert, werden die eingegebenen Zeichen 1:1 ausgegeben. Falls deaktiviert, werden die eingegebenen Zeichen in keiner Weise wieder ausgegeben, der Benutzer erhält keine Rückmeldung zu seiner Eingabe. Falls auf »masked« gesetzt, wird ein Sternchen (»*«) für jedes getippte Zeichen ausgegeben. Unabhängig davon, welcher Modus ausgewählt wird, wird die Ausgabe eingegebener Zeichen ausgeschaltet, falls der Benutzer zu irgendeinem Zeitpunkt die Tabulatortaste (»↹«) oder vor der Eingabe anderer Daten die Rückschritttaste (»⌫«) drückt.

Hinzugefügt in Version 249.

Akzeptiert entweder den besonderen Wert »auto« oder eine RFC7512 PKCS#11 URI[2], die auf einen privaten RSA-Schlüssel zeigt, der zum Enschlüsseln des in der dritten Spalte der Zeile festgelegten verschlüsselten Schlüssels verwandt wird. Dies ist nützlich, um verschlüsselte Datenträger mittels PKCS#11-kompatible Sicherheits-Token oder Smartcards zu entsperren. Weiter unten finden Sie ein Beispiel, wie Sie diesen Mechanismus zum Entsperren eines LUKS2-Datenträgers mit einem YubiKey-Sicherheits-Token verwenden können.

Falls dies als »auto« festgelegt wurde, dann muss der Datenträger vom Typ LUKS2 sein und die PKCS#11-Sicherheits-Token-Metadaten in seinem LUKS2-JSON-Token-Abschnitt tragen. In diesem Modus werden die URI und der verschlüsselte Schlüssel automatisch aus dem LUKS2-JSON-Token-Datenkopf gelesen. Verwenden Sie systemd-cryptenroll(1) als einfaches Werkzeug zum Registrieren von PKCS#11-Sicherheits-Token oder -Smartcards, auf eine Art, die mit »auto« kompatibel ist. In diesem Modus sollte die dritte Spalte der Zeile leer bleiben (das bedeutet, als »-« festgelegt sein).

Die festgelegte URI kann sich entweder direkt auf einen privaten, auf dem Token gespeicherten RSA-Schlüssel oder alternativ nur auf ein Position oder einen Token beziehen. In letzterem Fall wird eine Suche nach einem geeigneten privaten RSA-Schlüssel durchgeführt. Werden in diesem Fall mehrere geeignete Objekte gefunden, wird der Token abgelehnt. Der in der dritten Spalte der Zeile konfigurierte verschlüsselte Schlüssel wird unverändert (d.h. in binärer Form, unverarbeitet) an die RSA-Entschlüsselung weitergegeben. Der daraus entstehende entschlüsselte Schlüssel wird dann Base64-kodiert, bevor er zum Entsperren des LUKS-Datenträgers verwandt wird.

Verwenden Sie systemd-cryptenroll --pkcs11-token-uri=list, um alle geeigneten, derzeit eingesteckten PKCS#11-Sicherheits-Token zusammen mit ihren URIs aufzulisten.

Beachten Sie, dass viele neuere Sicherheits-Token, die auch als PKCS#11-Sicherheits-Token verwandt werden können, typischerweise auch das neuere und einfachere (nachfolgend beschriebene) fido2-device= implementieren, um sie stattdessen mit FIDO2 zu registrieren. Beachten Sie, dass ein mittels PKCS#11 registrierter Token nicht zum Entsperren eines Datenträgers mittels FIDO2 verwandt werden kann, außer er ist auch mittels FIDO2 registriert und umgekehrt.

Hinzugefügt in Version 245.

Akzeptiert entweder den besonderen Wert »auto« oder den Pfad zu einem »hidraw«-Geräteknoten (z.B. /dev/hidraw1), der sich auf einen FIDO2-Sicherheits-Token bezieht, der die Erweiterung »hmac-secret« implementiert (was die meisten aktuellen Hardware-Sicherheits-Token machen). Weiter unten finden Sie ein Beispiel, wie dieser Mechanismus eingerichtet wird, um einen verschlüsselten Datenträger mit einem FIDO2-Sicherheits-Token zu entsperren.

Falls dies als »auto« festgelegt wird, wird das FIDO2-Token-Gerät automatisch erkannt, wenn es eingesteckt wird.

FIDO2-Datenträgerentsperrung benötigt einen Client-Kennungs-Hash (CID), der mittels fido2-cid= (siehe unten) konfiguriert wird und einen Schlüssel, der an die HMAC-Funktionalität des Sicherheits-Tokens übergeben werden muss (der in der dritten Spalte der Zeile konfiguriert wird), um zu funktionieren. Falls nicht konfiguriert und der Datenträger vom Typ LUKS2 ist, wird die CID und der Schlüssel stattdessen von den LUKS2-JSON-Token-Metadaten gelesen. Verwenden Sie systemd-cryptenroll(1) als einfaches Werkzeug, um FIDO2-Sicherheits-Token, die zum automatischen Modus kompatibel sind, der nur für LUKS2-Datenträger verfügbar ist, zu konfigurieren.

Verwenden Sie systemd-cryptenroll --fido2-device=list, um alle geeigneten und derzeit eingesteckten FIDO2-Sicherheits-Token zusammen mit ihren Geräteknoten aufzulisten.

Diese Option implementiert den folgenden Mechanismus: der konfigurierte Schlüssel wird mittels der vom FIDO2-Gerät implementierten HMAC-indizierten Hash-Funktion gehasht, indiziert durch einen geheimen Schlüssel, der im Gerät eingebettet ist. Der daraus entstehende Hash-Wert wird Base64-kodiert und zum entsperren des LUKS2-Datenträgers verwandt. Da es nicht möglich sein darf, den geheimen Schlüssel vom Hardware-Token auszulesen, sollte es nicht möglich sein, den gehashten Schlüssel zu ermitteln, wenn der konfigurierte Schlüssel übergeben wird — ohne den Hardware-Token zu besitzen.

Beachten Sie, dass viele Sicherheits-Token, die FIDO2 implementieren, auch PKCS#11 implementieren, was zum Entsperren von Datenträgern mit der oben beschriebenen Option pkcs11-uri= geeignet ist. Typischerweise ist der neuere, einfachere FIDO2-Standard zu bevorzugen.

Hinzugefügt in Version 248.

Akzeptiert eine Base64-kodierte FIDO2-Client-Kennung, die für die FIDO2-Entsperraktion verwandt werden soll. Falls festgelegt, aber nicht fido2-device=, dann wird fido2-device=auto impliziert. Falls fido2-device= verwandt wird aber nicht fido2-cid=, dann muss der Datenträgertyp LUKS2 sein und die CID wird aus den LUKS2-JSON-Token-Kopfzeilen ausgelesen. Verwenden Sie systemd-cryptenroll(1) zum Registrieren von FIDO2-Token in den LUKS2-Kopfzeilen, die zu diesem Modus kompatibel sind.

Hinzugefügt in Version 248.

Akzeptiert eine Zeichenkette, die die FIDO2-Weiterleitungs-Partei (rp) für die FIDO2-Entsperraktion konfiguriert. Falls nicht festgelegt, wird »io.systemd.cryptsetup« verwandt, außer falls die LUKS2-JSON-Token-Kopfzeilen einen anderen Wert enthalten. Normalerweise sollte es nicht notwendig sein, diesen Wert außer Kraft zu setzen.

Hinzugefügt in Version 248.

Akzeptiert entweder den besonderen Wert »auto« oder den Pfad zu einem Geräteknoten (z.B. /dev/tpmrm0), der sich auf einen TPM2-Sicherheits-Chip bezieht. Siehe weiter unten für ein Beispiel, wie dieser Mechanismus zum Entsperren eines verschlüsselten Datenträgers mit einem TPM2-Chip verwandt wird.

Verwenden Sie tpm2-pcrs= (siehe unten), um die Menge der TPM2-PCRs, die an die Datenträger-Entsperrung gebunden werden soll, zu konfigurieren. Verwenden Sie systemd-cryptenroll(1) als einfacheres Werkzeug zum Registrieren von TPM2-Sicherheits-Chips bei LUKS2-Datenträgern.

Falls als »auto« festgelegt, wird das TPM2-Gerät automatisch ermittelt. Verwenden Sie systemd-cryptenroll --tpm2-device=list, um alle derzeit verfügbaren geeigneten TPM2-Geräte zusammen mit ihren Geräteknoten aufzulisten.

Diese Option implementiert die folgenden Mechanismen: Beim Registrieren eines TPM2-Gerätes mittels systemd-cryptenroll an einem LUKS2-Datenträger wird auf dem Rechner ein zufälliger Schlüssel zum Entsperren des Datenträgers erstellt und in den TPM2-Chip geladen, wo er mit dem asymmetrischen »primären« Schlüsselpaar, das vom internen »seed«-Schlüssel des TPMs abgeleitet ist, verschlüsselt wird. Es wird sichergestellt, dass weder der Seed-Schlüssel noch der primäre Schlüssel jemals den TPM2-Chips verlassen — der jetzt verschlüsselte zufällige Schlüssel darf dies aber. Er wird in den JSON-Token-Kopfzeilen des LUKS2-Datenträgers gespeichert. Beim Entsperren des verschlüsselten Datenträgers wird auf dem TPM2-Chip das primäre Schlüsselpaar erneut erstellt (was funktioniert, solange der Seed-Schlüssel auf dem TPM-Chip korrekt verwaltet wird). Dieses Schlüsselpaar wird dann zum Entschlüsseln (auf dem TPM2-Chips) des verschlüsselten Schlüssel aus den JSON-Token-Kopfzeilen des LUK2-Datenträgers, der dort beim Registrieren gespeichert wurde, verwandt. Der daraus entstehende entschlüsselte Schlüssel wird dann zum Entschlüsseln des Datenträgers verwandt. Wenn der zufällige Schlüssel verschlüsselt wird, dann werden die aktuellen Werte der ausgewählten PCRs (siehe unten) in der Aktion eingebunden, so dass ein anderer PCR-Status zu einem anderen verschlüsselten Schlüssel führt und der entschlüsselte Schlüssel nur wiederhergestellt werden kann, falls der gleiche PCR-Zustand reproduziert wird.

Hinzugefügt in Version 248.

Akzeptiert eine durch »+« getrennte Liste von numerischen TPM2-PCR- (d.h. »Plattformkonfigurationsregister«) Indices, an die die TPM2-Datenträgerentsperrung gebunden werden sollen. Diese Option ist nur nützlich, wenn die TPM2-Registrierungsmetadaten nicht bereits in den LUKS2-JSON-Token-Kopfzeilen verfügbar sind, auf die Art, wie sie systemd-cryptenroll dort hineinschreibt. Falls nicht verwandt (und keine Metadaten in den LUKS2-JSON-Token-Kopfzeilen sie definieren) ist die Vorgabe eine Liste mit einem einzigen Eintrag: PCR 7. Weisen Sie eine leere Zeichenkette zu, um eine Richtlinie festzulegen, die den Schlüssel an keine PCR bindet, wodurch der Schlüssel für lokale Programme zugreifbar wird, unabhängig von dem aktuellen PCR-Status.

Hinzugefügt in Version 248.

Akzeptiert ein logisches Argument, standarmäßig »false«. Steuert, ob TPM2-Datenträger-Entsperrung neben PCRs an eine PIN gebunden ist. Entsprechend ist diese Option nur nützlich, falls die TPM2-Registrierungs-Metadaten nicht verfügbar sind.

Hinzugefügt in Version 251.

Akzeptiert einen absoluten Pfad zu einer TPM2-PCR-JSON-Signaturdatei, wie sie vom Werkzeug systemd-measure(1) erstellt wird. Damit können LUKS2-Datenträger an jeden PCR-Wert gesperrt werden, für den eine gültige Signaturdatei bereitgestellt werden kann, die auf einen öffentlichen Schlüssel passt, der bei der Schlüsselregistrierung angegeben wurde. Siehe systemd-cryptenroll(1) zu Details über das Registrieren von öffentlichen TPM2-PCR-Schlüsseln. Falls diese Option nicht angegeben ist, aber versucht wird, einen LUKS2-Datenträger mit einer signierten TPM2-PCR-Registrierung zu entsperren, wird nach einer geeigneten Signaturdatei tpm2-pcr-signature.json in /etc/systemd/, /run/systemd/, /usr/lib/systemd/ (in dieser Reihenfolge) gesucht.

Hinzugefügt in Version 252.

Akzeptiert einen absoluten Pfad zu einer TPM2-Pcrlock-Richtliniendatei, wie sie vom Werkzeug systemd-pcrlock(1) erstellt wird. Damit können LUKS2-Datenträger an eine lokale Richtlinie erlaubter PCR-Werte mit Varianten gesperrt werden. Siehe systemd-cryptenroll(1) zu Details über das Registrieren von TPM2-Pcrlock-Richtlinien. Falls diese Option nicht angegeben ist, aber versucht wird, einen LUKS2-Datenträger mit einer TPM2-Pcrlock-Registrierung zu entsperren, wird nach einer geeigneten Datei pcrlock.json in /run/systemd/ und /var/lib/systemd/ (in dieser Reihenfolge) gesucht.

Hinzugefügt in Version 255.

Steuert, ob der Datenträgerschlüssel des verschlüsselten Datenträgers in ein TPM2 PCR eingemessen werden soll. Falls auf »no« (die Vorgabe) gesetzt, erfolgt keine PCR-Erweiterung. Falls auf »yes« gesetzt, wird der Datenträgerschlüssel in PCR 15 eingemessen. Falls auf eine dezimale Ganzahl im Bereich 0…23 gesetzt, wird der Datenträgerschlüssel in das festgelegte PCR eingemessen. Der Datenträgerschlüssel wird zusammen mit dem Namen des aktivierten Datenträgers und seiner UUID eingemessen. Diese Funktionalität ist insbesondere für verschlüsselte Datenträger nützlich, die das Wurzeldateisystem unterlegen, da sie damit späteren TPM-Objekten erlaubt, sicher an das Wurzeldateisystem und damit die konkrete Installation gebunden zu werden.

Hinzugefügt in Version 253.

Wählt eine oder mehrere TPM2-PCR-Bänke aus, in die der Datenträgerschlüssel eingemessen werden soll, wie oben mit tpm2-measure-pcr= konfiguriert. Es können mehrere Bänke, getrennt durch Doppelpunkte, angegeben werden. Falls nicht angegeben, werden die verfügbaren und benutzten Bänke automatisch bestimmt. Erwartet einen Nachrichten-Hash-Namen (z.B. »sha1«, »sha256«, …) als Argument, um die Bank zu identifizieren.

Hinzugefügt in Version 253.

Legt fest, wie lange maximal auf das Auftauchen des konfigurierten Sicherheitsgerätes (d.h. FIDO2, PKCS#11, TPM2) gewartet werden soll. Akzeptiert einen Zeitwert in Sekunden (es dürfen aber auch andere Zeiteinheiten angegeben werden, siehe systemd.time(7) für unterstützte Formate). Standardmäßig 30s. Sobald die festgelegte Zeitüberschreitung abgelaufen ist, wird die Authentifizierung über Passwort versucht. Beachten Sie, dass die Zeitüberschreitung für das Warten auf das Auftauchen des Sicherheitsgerätes gilt – sie gilt nicht für die PIN-Eingabeaufforderung für das Gerät (sollte eine benötigt werden) oder ähnliches. Übergeben Sie »0«, um die Zeitüberschreitung zu deaktivieren und beliebig lange zu warten.

Hinzugefügt in Version 250.

Akzeptiert ein logisches Argument. Falls aktiviert, wird zuerst versucht, den Datenträger mit einem leeren Passwort zu entsperren, bevor der Benutzer nach einem Passwort gefragt wird. Dies ist für Systeme nützlich, die mit einem verschlüsselten Datenträger initialisiert werden, bei dem nur ein leeres Passwort gesetzt ist, das dann während des ersten Systemstarts aber nach der Aktivierung mit einem geeigneten Passwort ersetzt werden muss.

Hinzugefügt in Version 246.

Legt fest, wie lange Systemd auf das Auftauchen eines blockorientierten Gerätes warten soll, bevor es bei dem Eintrag aufgibt. Das Argument ist eine Zeit in Sekunden oder in einer explizit angegebenen Einheit (»s«, »min«, »h«, »ms«).

Hinzugefügt in Version 216.

Richtet dieses verschlüsselte Blockgerät in der Initrd ein, ähnlich zu mit x-initrd.mount markierten systemd.mount(5)-Units.

Obwohl es nicht notwendig ist, den Einhängeeintrag für das Wurzeldateisystem mit x-initrd.mount zu markieren, wird x-initrd.attach weiterhin für verschlüsselte Blockgeräte empfohlen, die das Wurzeldateisystem enthalten, da Systemd andernfalls versuchen wird, das Gerät während des regulären Herunterfahrens des Systems abzuhängen, während es noch verwandt wird. Mit dieser Option wird das Gerät weiterhin abgehängt, aber später, wenn das Wurzeldateisystem ausgehängt wird.

Alle anderen verschlüsselten Blockgeräte, die in der Initrd eingehängte Dateisysteme enthalten, sollten diese Option verwenden.

Hinzugefügt in Version 245.

NUL ZUFALL /cryptsetup/ DATENTRÄGER

\0d7067f78d9827418/cryptsetup/myvol

luks       UUID=2505567a-9e27-4efe-a4d5-15ad146c258b
swap       /dev/sda7       /dev/urandom       swap
truecrypt  /dev/sda2       /etc/container_password  tcrypt
hidden     /mnt/tc_hidden  /dev/null    tcrypt-hidden,tcrypt-keyfile=/etc/keyfile
external   /dev/sda3       keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64

# SPDX-License-Identifier: MIT-0
# Alle alten Schlüssel auf dem Yubikey zerstören (Vorsicht!)
ykman piv reset
# Erstellt ein neues Schlüsselpaar (privat/öffentlich) auf dem Gerät, speichert den
# öffentlichen Schlüssel in »pubkey.pem«.
ykman piv generate-key -a RSA2048 9d pubkey.pem
# Erstellen Sie ein selbstsigniertes Zertifikat aus diesem öffentlichen Schlüssel und speichern Sie es auf dem
# Gerät. Das »subject« sollte eine beliebige, vom Benutzer gewählte Zeichenkette sein, um den Token
# damit zu identifizieren.
ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
# Wir brauchen den öffentlichen Schlüssel nicht mehr, daher wird er entfernt. Da er nicht sicherheitsrelevant
# ist, führen wir einfach ein reguläres »rm« hier aus.
rm pubkey.pem
# Registriert den frisch initialisierten Sicherheits-Token in dem LUKS2-Datenträger.
# Ersetzen Sie /dev/sdXn durch die zu verwendende Partition (z.B. /dev/sda1).
sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/sdXn
# Testen: Führen Sie »systemd-cryptsetup« aus, um zu testen, ob alles funktioniert.
sudo systemd-cryptsetup attach mytest /dev/sdXn - pkcs11-uri=auto
# Falls das funktionierte, fügen Sie die gleiche Zeile für die Zukunft dauerhaft
# zu /etc/crypttab hinzu. Der (instabile) Name /dev/sdX sollte nicht verwandt
# werden, daher wird ein stabiler Link ermitelt:
udevadm info -q -r symlink /dev/sdXn
# Fügen Sie jetzt die Zeile mittels des by-uuid-Symlinks zu /etc/crypttab
# hinzu:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/… - pkcs11-uri=auto" >>/etc/crypttab'
# Abhängig von Ihrer Distribution und Verschlüsselungsinstallation, könnte es
# notwendig sein, dass Sie Ihre Initramfs manuell neu erstellen müssen, um
# einen Yubikey / ein PKCS#11-Token zu verwenden, um während der frühen
# Systemstartphase die Partition zu entsperren.
# Weitere Informationen unter https://unix.stackexchange.com/a/705809.
# Auf Fedora-basierten Systemen:
sudo dracut --force
# Auf Debian-basierten Systemen:
sudo update-initramfs -u

•Wir verwenden RSA2048, das die längste, derzeit von Yubikeys unterstützte Schlüssellänge ist.

•Wir verwenden die Yubikey Schlüssel-Position 9d, da dies offensichtlich die für Entschlüsselungszwecke zu verwendende Position ist, siehe Yubico-PIV-Zertifikatspositionen[3].

# SPDX-License-Identifier: MIT-0
# Registrieren des Sicherheits-Tokens am LUKS2-Datenträger. Ersetzen Sie /dev/sdXn
# durch die zu verwendende Partition (z.B. /dev/sda1).
sudo systemd-cryptenroll --fido2-device=auto /dev/sdXn
# Testen: Führen Sie »systemd-cryptsetup« aus, um zu testen, ob alles funktioniert.
sudo systemd-cryptsetup attach mytest /dev/sdXn - fido2-device=auto
# Falls das funktionierte, fügen Sie die gleiche Zeile für die Zukunft dauerhaft
# zu /etc/crypttab hinzu. Der (instabile) Name /dev/sdX sollte nicht verwandt
# werden, daher wird ein stabiler Link ermitelt:
udevadm info -q -r symlink /dev/sdXn
# Fügen Sie jetzt die Zeile mittels des by-uuid-Symlinks zu /etc/crypttab
# hinzu:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/… - fido2-device=auto" >>/etc/crypttab'
# Abhängig von Ihrer Distribution und Verschlüsselungsinstallation, könnte es
# notwendig sein, dass Sie Ihre Initramfs manuell neu erstellen müssen, um
# ein FIDO2-Gerät zu verwenden, um während der frühen Systemstartphase die
# Partition zu entsperren.
# Weitere Informationen unter https://unix.stackexchange.com/a/705809.
# Auf Fedora-basierten Systemen:
sudo dracut --force
# Auf Debian-basierten Systemen:
sudo update-initramfs -u

# SPDX-License-Identifier: MIT-0
# Registrieren des TPM2-Sicherheits-Chips am LUKS2-Datenträger und Anbindung an nur
# PCR 7. Ersetzen Sie /dev/sdXn durch die zu verwendende Partition (z.B. /dev/sda1).
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn
# Testen: Führen Sie »systemd-cryptsetup« aus, um zu testen, ob alles funktioniert.
sudo systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto
# Falls das funktionierte, fügen Sie die gleiche Zeile für die Zukunft dauerhaft
# zu /etc/crypttab hinzu. Der (instabile) Name /dev/sdX sollte nicht verwandt
# werden, daher wird ein stabiler Link ermitelt:
udevadm info -q -r symlink /dev/sdXn
# Fügen Sie jetzt die Zeile mittels des by-uuid-Symlinks zu /etc/crypttab
# hinzu:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/… - tpm2-device=auto" >>/etc/crypttab'
# Prüfen Sie jetzt, dass die automatische Entsperrung funktioniert:
sudo systemd-cryptsetup detach mytest
sudo systemctl daemon-reload
sudo systemctl start cryptsetup.target
systemctl is-active systemd-cryptsetup@mytest.service
# Sobald das automatisch entsperrte Geräte vorliegt, kann es verwandt werden.
# Normalerweise wird ein Dateisystem erstellt und zu /etc/fstab hinzugefügt:
sudo mkfs.ext4 /dev/mapper/mytest
# Dies gibt die »Dateisystem-UUID« aus, die als stabiler Name verwandt werden kann:
sudo bash -c 'echo "/dev/disk/by-uuid/... /var/mytest ext4 defaults,x-systemd.mkdir 0 2" >>/etc/fstab'
# Überprüfen Sie jetzt, dass das Einhängen funktioniert:
sudo systemctl daemon-reload
sudo systemctl start /var/mytest
systemctl status /var/mytest
# Abhängig von Ihrer Distribution und Verschlüsselungsinstallation, könnte es
# notwendig sein, dass Sie Ihre Initramfs manuell neu erstellen müssen, um
# einen TPM2-Sicherheitschip zu verwenden, um während der frühen
# Systemstartphase die Partition zu entsperren.
# Weitere Informationen unter https://unix.stackexchange.com/a/705809.
# Auf Fedora-basierten Systemen:
sudo dracut --force
# Auf Debian-basierten Systemen:
sudo update-initramfs -u