DM-Crypt

Aus Gentoo Linux Wiki

Wechseln zu: Navigation, Suche
Dieser Artikel ist Teil der Security Sammlung.
Firewall • Dienste absichern • Verschlüsselung • alphabetischer Security Index

Inhaltsverzeichnis

[Bearbeiten] Warum DM-Crypt und Cryptsetup-LUKS?

Cryptsetup hat einen Schönheitsfehler, es trennt die Informationen des Keys von den zu verschlüsselnden Informationen. Die Cryptsetup Parameter stehen in Skripten oder Dateien und wer diese verliert, verliert den Zugriff auf seine Daten. Linux Unified Key Setup (LUKS) hebt diese Trennung auf und bietet sicherheitstechnisch wichtige Vorteile:

[Bearbeiten] LUKS

  • LUKS definiert einen Header für DM-Crypt Partitionen, der alle Informationen für die sichere Schlüsselableitung sowie den Verschlüsselungsalgorithmus und -Modus enthält.
  • Passwortmanagement von LUKS bietet drei Konzepte:
    • Schlüsselhierarchien
    • PBKDF2
    • Anti-Forensische Informationssicherung

[Bearbeiten] Schlüsselhierarchien

Masterkey

Das klassische Cryptsetup übergibt den abgeleiteten Schlüssel direkt an den Kernel, das hat den Nachteil, dass bei einer Änderung des Passworts alle Daten neu verschlüsselt werden müssen. LUKS bietet eine zusätzliche Passwortmanagement-Schicht, die Schlüsselhierarchie schiebt eine weitere Krypto-Schicht zwischen den abgeleiteten Schlüssel und den Key, mit dem die Partitionsdaten geschützt werden. Der erzeugte Schlüssel chiffriert nun einen Masterkey, der die Daten der Partition letztendlich verschlüsselt.

Bei Passwortänderung wird der Master-Key mit dem alten Passwort entschlüsselt und verschlüsselt ihn anschließend mit dem neuen Passwort. Da sich der Klartext-Master-Key nicht ändert, bleiben die Partitionsdaten erhalten.

mehrere Passwörter

LUKS bietet sogenannte Key-Slots, es lassen sich bis zu acht verschiedene Passwörter definieren, dies ist praktisch um Backup-Passwörter anzulegen oder mehreren Benutzern eigene Zugangsdaten zu geben. Für jedes Passwort wird eine gleichwertige Kopie des Master-Keys im Header abgelegt. Vorteil ist auch die äußerst schnelle Datenvernichtung, es reicht alle Passwörter zu entfernen, dies entfernt ebenfalls den Master-Key und die gespeicherten Informationen werden nutzlos. Optimal ist es noch den Header der LUKS Partition mehrmals zu überschreiben.

[Bearbeiten] PBKDF2

PBKDF2 heißt Password-Based Key Derivation Function, Version 2 und ist Teil von PKCS#5 (Public Key Cryptography Standard 5) und in RFC 2898 spezifiziert. Es kommen die Verfahren Salting und Stretching zum Einsatz um Wörterbuchangriffe zu vereiteln.

Stretching

Benutzer haben Vorliebe für kurze und einfach zu merkende Passwörter. Ein 128-Bit-Passwort besteht aus einer 22-stelligen Zeichenfolge, die wenigsten verwenden solche langen Passwörter. Die Aufblähung auf 128 Bit muss die Entropy Gap überwinden, die Kluft beim Grad an Zufälligkeit zwischen Passwort- und der Schlüsseldomäne.

Ein Verfahren ist zum Beispiel das Padding (Auffüllen mit vorgegebenen Werten), dabei wird die Entropy Gap nicht zufälliger. PBKDF2 ermittelt die Ableitung des Schlüssels mit einer absichtlich rechenintensiven Funktion. Das kostet Zeit bei Wörterbuchangriffen, die sich schnell summiert. Das nennt man Stretching.

Salting

PBKDF2 hängt zusätzlich an das Passwort eine zufällige Zeichenkette an, bevor es den Schlüssel ableitet. Durch die beliebige Variierbarkeit müsste ein Universalwörterbuch mehr Einträge als Atome im Universum besitzen, um auf alle möglichen PBKDF2-Kombinationen zu passen.

[Bearbeiten] Anti-Forensische Informationssicherung

Master-Keys sind im Verhältnis zur Sektorgröße einer Festplatte sehr kurz (zb. 128, 192 oder 256 Bit bei Aes) und passen problemlos in einen Sektor. Festplatten kennen die Funktion Sector Remapping, eine einfache Technik, die einen schlecht lesbaren Sektor in eine reservierte Festplattenzone kopiert und dann sämtlichen Zugriff umleitet. Für den Datenrettungsprofi mittels modifizierter Firmware kein Problem, an diese Daten ranzukommen. Bei einem kompromitierten Passwort wird trotz Änderung dieses der Inhalt der Festplatte schnell erreichbar.

LUKS trickst Datenretter aus, indem ein AF-Splitter diese Daten um das Viertausendfache aufbläht. Die aufgeblasene Information ist nicht redundant, es ist immer der komplette Datensatz nötig, um den Master-Key zu bestimmen. Fehlt ein Sektor, ist ein Zugriff unmöglich.

[Bearbeiten] Sichere Datenhaltung

Bei der Verschlüsselung einer Festplatte steht man vor dem Problem, dass man einen wahlfreien Zugriff auf die zu verschlüsselnden Daten garantieren muss.

Aus diesem Grund werden stets Blöcke zu 128 bis 256 bit mit Hilfe eines symmetrischen Chiffrieralgorithmuses (wie etwa AES, Twofish oder Serpent) einzeln verschlüsselt. Die Art und Weise wie dabei blockweise verfahren wird, wird mit Hilfe eines Chiffrier-Modus bestimmt.

Konkret sind im Linux-Kernel folgende Chiffrier-Modi implementiert:

  • ECB (Electronic Code Book)
  • CBC (Cipher Block Chaining)
  • LRW (Liskov, Rivest, Wagner)
  • XTS (XEX encryption mode with tweak and ciphertext stealing, Erweiterung von LRW, erst im Kernel 2.6.24 fix integriert)

ECB trägt seinen Namen zu Unrecht, es chiffriert jeden Klartextblock unabhängig von allen anderen. Aufgrund genormter Fileheader z.b. lassen sich andere Daten mit dem gleichen Inhalt auslesen.

CBC bezieht das Chiffrat eines Blocks in die Berechnung des unmittelbar folgenden Blocks mit ein. Damit wird sichergestellt, dass gleiche Klartextblöcke unterschiedlich verschlüsselt werden. Für komplette Partitionen ist dieses Vorgehen jedoch ungeeignet, da bei Änderung des ersten Sektors die komplette Partiton neu verschlüsselt werden müsste. Aus diesem Grund nutzt CBC die Rekursion sektorweise. Dies führt jedoch wieder zu dem bekannten Problem, dass (diesmal) Sektoren gleichen Inhalts wieder gleich verschlüsselt werden, und so unter Anderem anfällig für Watermarking-Angriffe sind. Dabei werden Dateien so geformt, dass man sie später wiederfindet. Solche Markierungen können zum Beispiel unbemerkt per E-Mail mitgeliefert werden.

Um dies zu verhindern, kann man einen Initialisierungsvektor (Chiffriermodus cbc-essiv anstelle von cbc-plain) einsetzen, der zu Beginn jeder Verschlüsselungskette mit einberechnet und z.B. aus der Sektorposition errechnet wird. Dies führt zu unterschiedlichen Chiffraten trotz Sektoren gleichen Inhalts.

LRW ist seit Version 2.6.20 im Kernel enthalten. Es ist der mit Abstand sicherste Chiffriermodus, und ist vergleichbar schnell wie CBC (mit ESSIV SHA256). Der Chiffriername lautet dann lrw-benbi. Im Gegensatz zu CBC arbeitet LRW blockweise indem für jeden Block ein zufälliger Schlüssel für den symmetrischen Chiffrieralgorithmus simuliert wird.

Für die Verwaltung von LRW werden 128 bit benötigt, das heißt dass zur Schlüssellänge vom gewählten symmetrischen Algorithmus 128 bit dazu addiert werden. Im Falle von AES wären 256, 320 und 384 bit möglich.

XTS (als modifizierter LRW-Modus) soll in Zukunft den LRW-Algorithmus ersetzen und ist mit Version 2.6.24 in den Kernel aufgenommen worden. (Chiffriername xts-plain) XTS ist der von der IEEE P1619-Arbeitsgruppe ausgewählte Nachfolger von LRW, da LRW als unsicher gilt, wenn der Schlüssel selbst auf der (mit LRW und dem selben Schlüssel) verschlüsselten Partition gespeichert wird. Hierbei ist es unter Umständen möglich den 128bit großen Verwaltungsschlüssel von LRW auszulesen, was die Sicherheit auf ECB zurückstufen würde.

Dies betrifft allerdings praktisch nur den Fall, dass der Schlüssel auf eine mit LRW verschlüsselten Swap-Partition ausgelagert wird, oder ein Hibernate auf eine mit LRW verschlüsselten Swap-Partition durchgeführt wird. Unter allen anderen Umständen ist obige Sicherheitslücke bei einem LUKS-Header nicht möglich.

XTS benötigt einen Verwaltungsschlüssel von 128 oder 256 bit, so dass mit AES eine Gesamtschlüssel von 256, 320, 384 und 512 bit möglich wären.


Momentan sind XTS und LRW als Experimental eingestuft und sollten daher mit Vorsicht verwendet werden.

[Bearbeiten] Installation

Nun zum praktischen Teil.

[Bearbeiten] Kerneloptionen

Dieses Howto setzt einen Kernel der Versionsnummer 2.6.20 oder höher voraus. 2.6.4 ist Pflicht, jedoch wird ESSIV erst ab 2.6.10 unterstützt. Für beste Sicherheit mit LRW ist 2.6.20 erforderlich.

Die Optionen für DM-Crypt: 

Device Drivers  --->
  Multi-device support (RAID and LVM)  --->
    [*] Multiple devices driver support (RAID and LVM)
    < >   RAID support
    <M>   Device mapper support
    <M>     Crypt target support

Natürlich brauchen wir noch eine Crypto-API: 

Cryptographic options  --->
  --- Cryptographic API
  <*>   SHA256 digest algorithm
  <M>   LRW support
  <M>   XTS support
  <M>   Blowfish cipher algorithm
  <M>   Twofish cipher algorithm
  <M>   Serpent cipher algorithm
  <M>   AES cipher algorithms

Sha256 sollte gesetzt werden, statt Blowfish kann auch AES oder Twofish zum Beispiel verwendet werden. Welcher Algorithmus nun verwendet wird, ist persönliche Geschmackssache, allgemein wird AES oft empfohlen. Bruce Schneier empfiehlt Twofish statt Blowfish. Die größte Sicherheit bietet Serpent, dieser Algorithmus ist aber etwas langsamer als AES.

Für einen kleinen Größenvergleich: aes ist der schnellste Algorithmus, twofish ist etwa 3%, blowfish 23% und serpent 27% langsamer. Da AES aber als sicher gilt, sollte man es aufgrund des besten Durchsatzes bevorzugen (twofish wäre noch eine Alternative) und serpent zum Beispiel nur bei sehr sensiblen Informationen oder fürs Backup nutzen. Der enorme Unterschied kann unter anderem auch daran liegen, dass es für aes und twofish ein speziell optimiertes Modul für i386 und x86_64 gibt.

Nun noch den Kernel kompilieren. Die Module lassen sich dann wie folgt laden: 

modprobe dm-crypt

Diese Kommandos sollten einwandfrei funktionieren. Es ist nötig, dm-crypt beim Booten laden zu lassen um es später nicht immer manuell machen zu müssen: 

echo dm-crypt >> /etc/modules.autoload.d/kernel-2.6

[Bearbeiten] Cryptsetup

[Bearbeiten] Installation

cryptsetup
Tool to setup encrypted devices with dm-crypt
Entwickler Clemens Fruhwirth
Kategorie sys-fs
Lizenz GPL-2
Webseite luks.endorphin.org

Cryptsetup ist natürlich in Portage enthalten:

emerge -av cryptsetup

cryptsetup-luks ist veraltet und durch cryptsetup abgelöst, welches LUKS mittlerweile enthält.

Sollte es nach Wechsel von cryptsetup-luks zu cryptsetup beim Ausführen von Drittprogrammen zu Fehlermeldungen wie: "device is not LUKS encrypted, or cryptsetup with LUKS support is not installed" kommen, so bitte ein revdep-rebuild durchführen.

[Bearbeiten] Benutzung

cryptsetup luksFormat <device> [<key file>]

Initialisiert eine LUKS Partition und setzt das erste Passwort mittels Eingabe oder einen seperaten Keyfile.

Optionen:

  • -c (--cipher) - gibt den Chiffriermodus an, empfohlene Optionen sind zum Beispiel: aes-xts-plain oder aes-lrw-benbi oder aes-cbc-essiv:sha256.
  • -y (--verify-passphase) - verlangt eine doppelte Eingabe des Passworts
  • -s (--key-size) - Gibt Verschlüsselungstiefe an, die bei aes 128, 196 oder 256 Bit betragen kann, bei Blowfish z.b. von 32 bis 448 Bits reichen kann. Bei lrw-benbi muss 128 dazu gerechnet werden.

cryptsetup luksOpen <device> <name>

Öffnet eine LUKS Partition <device> und setzt das Mapping Device <name> nach einer erfolgreichen Verifikation mittels Passphrase oder Keyfile.

Optionen:

  • --key-file - gibt Keyfile an

cryptsetup luksClose <name>

Schließt eine LUKS Partition und entfernt das Mapper Device <name>

cryptsetup luksAddKey <device> [<new key file>]

Fügt ein Passwort/KeyFile hinzu, die Eingabe eines existierenden Passworts ist Pflicht. Bis zu acht Passwörter sind möglich.

Optionen:

  • --key-file - gibt Keyfile an
  • -y (--verify-passphase) - verlangt eine doppelte Eingabe des Passworts

cryptsetup luksDelKey <device> <key slot number>

Löscht einen Keyslot

cryptsetup luksDump <device>

Zeigt die Header Informationen einer LUKS Partition an.

[Bearbeiten] Anwendungsbeispiele

[Bearbeiten] Links/Quellen

Von „http://de.gentoo-wiki.com/DM-Crypt“
'Persönliche Werkzeuge
Andere Sprachen