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 notwendige(n) Passphrase(n) 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 (während der Registrierung) ein zufällig erstellter Schlüssel 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.

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.

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

Verwendet ein abgetrenntes (separates) Metadatengerät oder -datei, in der die LUKS-Kopfzeilen gespeichert sind. Diese Option ist nur für LUKS-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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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

Erzwingt den einfachen Verschlüsselungsmodus.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

Akzeptiert entweder den besonderen Wert »auto« oder eine RFC7512 PKCS#11 URI[1], 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.

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.

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.

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.

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.

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.

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.

Legt fest, wie lange Systemd auf das Auftauchen eines 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«).

Richtet dieses verschlüsselte Blockgerät in der Initramfs 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 Initramfs eingehängte Dateisysteme enthalten, sollten diese Option verwenden.

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

# 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 /usr/lib/systemd/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.
sudo bash -c 'echo "mytest /dev/sdXn - pkcs11-uri=auto" >> /etc/crypttab'

•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 Dokumentation[2].

# 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 /usr/lib/systemd/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.
sudo bash -c 'echo "mytest /dev/sdXn - fido2-device=auto" >> /etc/crypttab'

# 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 /usr/lib/systemd/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.
sudo bash -c 'echo "mytest /dev/sdXn - tpm2-device=auto" >> /etc/crypttab'