CRYPTTAB(5)

BEZEICHNUNG
crypttab - Konfiguration für verschlüsselte Blockgeräte

ÜBERSICHT

/etc/crypttab

BESCHREIBUNG

Die Datei /etc/crypttab beschreibt verschlüsselte Blockgeräte, die während der frühen Systemstartphase eingerichtet werden.

Leere Zeilen und Zeilen, die mit dem Zeichen »#« beginnen, werden ignoriert. Jede andere verbleibende Zeile beschreibt ein verschlüsseltes Blockgerät. Felder werden durch Leeraum begrenzt.

Jede Zeile hat die Form

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

Die ersten zwei Felder sind verpflichtend, die verbleibenden zwei optional.

Die Einrichtung eines verschlüsselten Blockgerätes mittels dieser Datei kann in vier Verschlüsselungsmodi erfolgen: LUKS, TrueCrypt, BitLocker und einfach. Siehe cryptsetup(8) für weitere Informationen über jeden Modus. Wenn kein Modus in dem Optionsfeld festgelegt wurde und das Blockgerät eine LUKS-Signatur enthält, dann wird es als LUKS-Gerät geöffnet. Andernfalls wird angenommen, dass es in rohem DM-Crypt-Format (einfacher Modus) ist.

Die vier Felder von /etc/crypttab sind wie folgt definiert:

    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.

SCHLÜSSELBESCHAFFUNG

Es werden sechs verschiedene Mechanismen zur Beschaffung des Entschlüsselungs-Schlüssels oder der Passphrase zum Entsperren des verschlüsselten Datenträgers unterstützt. Konkret:

    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 gespeicherter, im Entsperrprozess verwandter Schlüssel auf einer Platte/einem Wechselmedium gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Für RSA ist der gespeicherte Schlüssel ein verschlüsselter Datenträgerschlüssel. Der verschlüsselte Datenträgerschlüssel wird dann durch den PKCS#11-Token mit einem darauf gespeicherten privaten RSA-Schlüssels entschlüsselt und zum Entsperren des verschlüsselten Laufwerks verwandt. Bei Kryptographie mit elliptischen Kurven ist der gespeicherte Schlüssel der im Registrierungsprozess erstellte öffentliche Schlüssel. Der öffentliche Schlüssel wird dann zur Ableitung eines gemeinsamen Geheimnisses mit dem auf dem PKCS#11-Token gespeicherten privaten Schlüssels verwandt. Das abgeleitete gemeinsame Geheimnis wird 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.

Für die letzteren fünf Mechanismen ist die Quelle für das Schlüsselmaterial, das zum Entsperren des Datenträgers verwandt wird, primär in dem dritten Feld jeder /etc/crypttab-Zeile kodiert, kann aber auch in /etc/cryptsetup-keys.d/ und /run/cryptsetup-keys.d/ (siehe oben) oder in den LUKS2-JSON-Token-Datenkopf (im Falle der letzteren drei) konfiguriert werden. Verwenden Sie das Werkzeug systemd-cryptenroll(1), um PKCS#11-, FIDO2- und TPM2-Geräte in LUKS2-Datenträgern zu registrieren.

UNTERSTÜTZTE OPTIONEN

Die folgenden Optionen können im vierten Feld jeder Zeile verwandt werden:

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

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

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

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

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

keyfile-size=
    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 dort die Schlüsseldateigröße durch die Schlüsselgröße gegeben ist. Sie wird auch ignoriert, wenn die Schlüsseldatei als Salt-Datei für ein FIDO2-Token verwandt wird, da die Salt-Größe in diesem Fall durch die FIDO2-Spezifikation auf genau 32 byte definiert ist.

    Hinzugefügt in Version 188.

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

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

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

link-volume-key=
    Gibt den Kernelschlüsselbund und die Schlüsselbeschreibung (siehe keyrings(7)) an, mit denen LUKS2-Laufwerkschlüssel während der Geräteaktivierung verlinkt werden. Die Kernelschlüsselbundbeschreibung und die Schlüsselbeschreibung muss durch »::« voneinander getrennt werden.

    Der Kernelschlüsselbundanteil kann eine Zeichenkettenbeschreibung oder ein vordefinierter Kernelschlüsselbund sein, dem »@« vorangestellt wird (z.B. verwenden Sie mit »@s« den Sitzungs- oder mit »@u« den Benutzerschlüsselbund direkt). Der Typpräfixtext in der Kernelschlüsselbundbeschreibung wird nicht benötigt. Der angegebene Kernelschlüsselbund muss zum Zeitpunkt der Geräteaktivierung bereits existieren.

    Der Schlüsselanteil ist eine Zeichenkettenbeschreibung, der optional »%key_type:« vorangestellt ist. Falls kein Typ festgelegt ist, wird standardmäßig der »user«-Typ-Schlüssel verlinkt. Siehe keyctl(1) zu weiteren Informationen über Schlüsselbeschreibungen (Abschnitt KEY IDENTIFIERS).

    Beachten Sie, dass der verlinkte Datenträgerschlüssel nicht automatisch bereinigt wird, wenn das Gerät abgehängt wird.

    Hinzugefügt in Version 256.

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

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

    Hinzugefügt in Version 246.

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

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

nofail
    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. Falls eine Schlüsseldatei und/oder eine header festgelegt wurden, werden auch die Abhängigkeiten auf ihre zugehörigen Verzeichnisse nicht fatal sein, so dass das Aushängen besagter Verzeichnisse nicht dazu führen wird, dass die erstellte Cryptset-Unit deaktiviert wird.

    Hinzugefügt in Version 186.

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

plain
    Erzwingt den einfachen Verschlüsselungsmodus.

    Hinzugefügt in Version 186.

read-only, readonly
    Richtet das verschlüsselte Blockgerät schreibgeschützt ein.

    Hinzugefügt in Version 186.

same-cpu-crypt
    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.

submit-from-crypt-cpus
    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.

no-read-workqueue
    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.

no-write-workqueue
    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.

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

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

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

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

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

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

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

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

    Hinzugefügt in Version 206.

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

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

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

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

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

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

    Hinzugefügt in Version 249.

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

    Hinzugefügt in Version 186.

password-echo=yes|no|masked
    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.

password-cache=yes|no|read-only
    Steuert, ob Zwischenspeicher für Passwörter oder PINs von Sicherheits-Token verwandt werden soll. Akzeptiert einen logischen Wert oder die besondere Zeichenkette »read-only«. Standardmäßig »yes«.

    Falls auf »read-only« gesetzt, wird der Kernel-Schlüsselbund auf ein Passwort/eine PIN geprüft, bevor interaktiv danach gefragt wird. Falls auf »yes« gesetzt, wird zusätzlich zur Prüfung des Schlüsselbundes jedes eingegebene Passwort/jede eingegebene PIN in dem Schlüsselbund mit einer 2,5-minütigen Zeitüberschreitung vor dem Entfernen zwischengespeichert.

    Beachten Sie, dass diese Option für PKCS#11-Sicherheits-Token nicht erlaubt ist. Der Grund dafür ist, dass PKCS#11-Sicherheits-Token normalerweise so konfiguriert sind, dass sie sich sperren, wenn eine ungültige PIN mehrfach eingegeben wurde. Daher könnte die Verwendung des Zwischenspeichers dazu führen, dass der Token unabsichtlich gesperrt wird.

    Hinzugefügt in Version 257.

pkcs11-uri=
    Akzeptiert entweder den besonderen Wert »auto« oder eine RFC7512 PKCS#11 URI[2], die auf einen privaten 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 ein 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 Schlüssel oder alternativ nur auf ein Position oder einen Token beziehen. In letzterem Fall wird eine Suche nach einem geeigneten privaten Schlüssel durchgeführt. Werden in diesem Fall mehrere geeignete Objekte gefunden, wird der Token abgelehnt. Die in der dritten Spalte der Zeile konfigurierte Schlüsseldatei wird unverändert (d.h. in binärer Form, unverarbeitet) verwandt. Der daraus entstehende entschlüsselte Schlüssel (für RSA) oder das abgeleitete gemeinsame Geheimnis (für ECC) 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.

fido2-device=
    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 für LUKS2-Datenträger zu registrieren.

    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.

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

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

fido2-pin=
    Steuert, ob der Benutzer eine PIN eingeben muss, wenn der Datenträger entsperrt wird (die FIDO2-Funktionalität »clientPin«). Diese Option gilt nur im manuellen Modus, d.h. wenn die Option fido2-cid= gesetzt ist. Standardmäßig weder true noch false, sondern das v248-Verhalten, d.h.: zuerst wird ohne PIN versucht, aber wenn der Token meldet, dass eine PIN benötigt wird, wird erneut versucht, diesmal mit der Abfrage der PIN.

    Hinzugefügt in Version 257.

fido2-up=
    Steuert, ob der Benutzer beim Entsperren des Datenträgers seine Anwesenheit nachweisen muss (auf den Token klopfen muss, die FIDO2-Funktionalität »up«). Diese Option gilt nur im manuellen Modus, d.h. wenn die Option fido2-cid= gesetzt ist. Standardmäßig weder true noch false, sondern das v248-Verhalten, d.h.: zuerst wird ohne UP versucht, aber wenn der Token meldet, dass UP benötigt wird, wird erneut mit aktiviertem UP versucht.

    Hinzugefügt in Version 257.

fido2-uv=
    Steuert, ob beim Entsperren des Datenträgers die Benutzerprüfung erfolgen muss (die FIDO2-Funktionalität »uv«). Diese Option gilt nur im manuellen Modus, d.h. wenn die Option fido2-cid= gesetzt ist. Standardmäßig weder true noch false, sondern das v248-Verhalten, d.h.: die Konfiguration von UV wird komplett unterlassen.

    Hinzugefügt in Version 257.

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

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

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

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

tpm2-pcrlock=
    Akzeptiert einen absoluten Pfad zu einer TPM2-Pcrlock-Richtliniendatei, wie sie vom Werkzeug systemd-pcrlock(8) 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.

tpm2-measure-pcr=
    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.

tpm2-measure-bank=
    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.

tpm2-measure-keyslot-nvpcr=
    Steuert, ob Informationen über die verwandte LUKS-Entsperr-Schlüsselposition in einen nichtflüchtigen TPM2-Index (Nvindex im PCR-Modus) eingemessen werden soll. Wird dies auf eine leere Zeichenkette gesetzt (was die Vorgabe ist), erfolgt keine TPM2-Nvindex-Erweiterung, andernfalls wird die Schlüsselpositionsinformation in einen Nvindex des angegeben Namens eingemessen, der reserviert wird, wenn notwendig. Es wird empfohlen, dies auf »cryptsetup« zu setzen, um diese Logik zu aktivieren. Der Positionsindex und der verwandte Entsperrmechanismus (d.h. »tpm2«, »fido2«, »pkcs11«) wird zusammen mit dem aktivierten Datenträgernamen und seiner UUID eingemessen.

    Hinzugefügt in Version 259.

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

try-empty-password=
    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.

x-systemd.device-timeout=
    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.

x-initrd.attach
    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.

In der frühen Systemstartphase und wenn die Konfiguration des Systemverwalters neu geladen wird, wird diese Datei durch systemd-cryptsetup-generator(8) in eine native Systemd-Unit übersetzt.

AF_UNIX-SCHLÜSSELDATEIEN

Falls der Schlüsseldateipfad (wie in der dritten Spalte der /etc/crypttab-Einträge festgelegt, siehe oben) sich auf ein AF_UNIX-Datenstrom-Socket in dem Dateisystem bezieht, wird der Schlüssel erlangt, indem eine Verbindung zu dem Socket aufgebaut und der Schlüssel aus der Verbindung gelesen wird. Die Verbindung erfolgt von einem AF_UNIX-Socket in dem abstrakten Namensraum, siehe unix(7) für Details. Der Quell-Socket-Name wird gemäß folgendem Format ausgewählt:

    NUL ZUFALL /cryptsetup/ DATENTRÄGER

Mit anderen Worten: ein Nullbyte (NUL) (wie für abstrakte Namensraum-Sockets benötigt), gefolgt von einer zufälligen Zeichenkette (bestehend nur aus alphanumerischen Zeichen), gefolgt von der wörtlichen Zeichenkette »cryptsetup«, gefolgt von dem Namen des Datenträgers, für den der Schlüssel erlangt werden soll. Zum Beispiel für einen Datenträger »myvol«:

    \0d7067f78d9827418/cryptsetup/myvol

Dienste, die auf dem AF_UNIX-Datenstrom-Socket auf Anfragen warten, können den Quell-Socket-Namen mit getpeername(2) abfragen und dieses dazu verwenden, den gesandten Schlüssel zu ermitteln, wodurch ein einzelner, auf Anfragen wartender Socket Schlüssel für eine Reihe von Datenträgern bereitstellen kann. Falls die PKCS#11-Logik verwandt wird (siehe oben), wird der Socket-Quellname auf ähnliche Art ermittelt, außer dass die wörtliche Zeichenkette »cryptsetup-pkcs11« verwandt wird. Ähnlich für FIDO2 (»cryptsetup-fido2-salt«) und TPM2 (»cryptsetup-tpm2«). Es wird eine andere Pfadkomponente verwandt, damit Dienste, die Schlüsselmaterial bereitstellen, wissen, dass der geheime Schlüssel nicht direkt erbeten wurde, sondern stattdessen ein verschlüsselter Schlüssel, der mittels der PKCS#11/FIDO2/TPM2-Logik entschlüsselt wird, um den letztendlichen geheimen Schlüssel zu erlangen.

BEISPIELE

Beispiel 1. /etc/crypttab-Beispiel

Richtet vier verschlüsselte Blockgeräte ein. Eines mittels LUKS für die normale Speicherung, ein anderes für die Verwendung als Auslagerungsgerät und zwei TrueCrypt-Datenträger. Für das vierte Gerät wird die Optionszeichenkette als zwei Optionen interpretiert: »cipher=xchacha12,aes-adiantum-plain64«, »keyfile-timeout=10s«.

    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

Beispiel 2. Yubikey-basierte PKCS#11-Datenträger-Entsperrung

Die PKCS#11-Logik erlaubt das Einbinden jedes kompatiblen Sicherheits-Tokens, der in der Lage ist, RSA oder EC-Entschlüsselungsschlüssel für das Entsperren verschlüsselter Datenträger zu speichern. Als Beispiel hier die Einrichtung eines Yubikey-Sicherheits-Tokens für ein LUKS2-Datenträger zu diesem Zweck mittels ykmap(1) aus dem Yubikey-manager-Projekt, um den Token zu initialisieren und systemd-cryptenroll(1), um ihn zu dem LUKS2-Datenträger hinzuzufügen:

    # 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 none 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 symlink -r /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/… none 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

Ein paar Hinweise zu obigem:

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

Beispiel 3. FIDO2-Datenträger-Entsperrung

Die FIDO2-Logik erlaubt das Verwenden jedes kompatiblen FIDO2-Sicherheits-Tokens, der die Erweiterung »hmac-secret« zum Entsperren eines verschlüsselten Datenträgers implementiert. Als Beispiel hier die Einrichtung eines FIDO2-Sicherheits-Tokens für ein LUKS2-Datenträger mittels systemd-cryptenroll(1) zu diesem Zweck:

    # 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 none 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 symlink -r /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/… none 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

Beispiel 4. TPM2-basierte Datenträger-Entsperrung

Die TPM2-Logik erlaubt die Verwendung jedes durch den Linux-Kernel unterstützten TPM2-Chips zum Entsperren eines verschlüsselten Datenträgers. Es folgt ein Beispiel, wie ein TPM2-Chip für diesen Zweck für ein LUKS2-Datenträger mittels systemd-cryptenroll(1) eingerichtet wird:

    # 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 none 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 symlink -r /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/… none 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

SIEHE AUCH

systemd(1), systemd-cryptsetup@.service(8), systemd-cryptsetup-generator(8), systemd-cryptenroll(1), fstab(5), cryptsetup(8), mkswap(8), mke2fs(8)

ANMERKUNGEN

1.  Veracrypt Personal Iterations Multiplier
    https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html

2.  RFC7512 PKCS#11 URI
    https://tools.ietf.org/html/rfc7512

3.  Yubico-PIV-Zertifikatspositionen
    https://developers.yubico.com/PIV/Introduction/Certificate_slots.html

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