Schlagwort: LUKS

LUKS – Verschlüsselte Platten retten.

Raptor 21018 Comments

Aus gegeben Anlass ( an dieser Stelle nochmal dank an den Ubuntu-Server-Installer) ein kleinen hinweis was man machen kann, wenn einem der CryptHeader zerstörrt wurde.

Zuerst muss man Ruhe bewahren. Dann sich die Fakten klar machen. Bei modernen Verschlüsslungsverfahren wird nicht gesamte Platte mit einmal verschlüsselt sondern immer häppchenweise. Eine zerstörte verschlüsselte Partition lässt sich genauso wieder herstellen wie eine normale Partition. Mit einem Unterschied: der CryptHeader. Dieser enthällt den Hauptschlüssel, ohne diesen hat man verloren. Sowohl ein eventuell eingerichtetes KeyFile als auch das Password leifern nur zugriff auf diesen Schlüssel. Ist dieser Schlüssel im eimer, so bleibt nur noch das Entschlüsseln per BruteForce… wie Erfolgversprechend das ist, hängt von der Schlüssellänge ab… Wenn man ein Backup einpsielen kann, ist es jetzt aber der richtige Zeitpunkt dies zu tun….

Meine Lektion vom Wochenende, ohne CryptoHeader hat man kaum eine Chance. Eventuell kann man noch wie hier beschrieben versuchen zu retten, was zu retten ist und den Header selber „neu schreiben“. Das funktioniert allerdings nur, solange der Schlüssel selber noch intakt ist. Die chancen dafür stehen gar nicht schlecht. Der eigendliche Schlüssel wird relativ weit hinten „versteckt“. Bei mir erst ab Byte 4096 (wenn ich die Daten richtig interpretiere).[1. Wiki: LUKS-Header-Format]

Um einem solchen Stress aber aus dem weg zu gehen gibt es eine ganz einfache Methode: einfach den Luks-Header sichern! War das früher nur über dd un der Kenntniss der HeaderLength möglich, geht das ganze jetzt komfortabel über das cryptsetup-Kommando. Dazu muss man die gewünschte Partition unmount und das CryptDevice schließen, anschließend kann man folgenden Befehl ausfürhen:

sudo cryptsetup luksHeaderBackup  --header-backup-file=header.backup /dev/sdXN

Um im Falle eines Fehlers den Header wieder herzustellen braucht es folgenden Befehl:

sudo cryptsetup luksHeaderRestore  --header-backup-file=header.backup /dev/sdXN

Wichtig dabei anzumerken ist, dass das HeaderFile auf keinen fall in der verschlüsselten Partition liegen sollte. Das bringt wenig. Es macht auch keinen sinn, dieses File irgendwo aufzubewahren, wo man ohne weiteres keinen Zugriff drauf bekommt. Von diesem File geht in erster linie keine Sicherheitsrisiko aus. Da es ein Angreifer eh ohne weiteres von der Platte ausgelesen werden kann und dies tun wird, um so das Password zu schneller brechen. Man sollte dieses file aber auch nicht unbedingt bei Facebook einstellen 😉

Verschlüsselung von RAIDs

Raptor 2101Leave a comment

Will man einen RAID verschlüsseln, steht man vor verschiedenen Problemen. Zuallererst muss man sich klar werden, dass eine Verschlüsselung die Datensicherheit (Redundanz) gefährden kann. Tausend Backups nützen nichts wenn der Schlüssel bzw. das Schlüsselfile verloren gegangen ist. Das klingt banal, schießt einen aber ins Knie, wenn der RAID bei einem Systemausfall die wichtigen Daten am Leben hält, das Schlüsselfile aber mit ins Nirwana gegangen ist.

Umgekehrt torpediert dein RAID meist mit der schieren Masse an  Daten die Datensicherheit im Sinne des Zugriffsschutzes. Je mehr Daten man mit dem gleichen Schlüssel verschlüsselt, desto „leichter“ lässt sich der Schlüssel aus dieser Menge extrahieren. Ab 2 GByte sollte man sich intensiv damit beschäftigen, welchen Verschlüsselungsalgorithmus (Cipher) man verwenden kann und mit welcher Schlüssellänge man arbeiten sollte.

Neben solchen theoretischen Vorüberlegungen muss man sich aber auch klar werden wie man Verschlüsseln will. Welche Features will man nutzen, worauf kann man verzichten. Ich für meinen Teil hatte klare Vorstellungen von meinem Setup:

  • FullDiskEncryption (FDE): Das RAID Array soll im ganzen verschlüsselt werden.
  • Dynamische RAID-Vergrößerung: Ab gewissen Speichergrößen ist eine Verdopplung des Speichers nicht mehr praktikabel oder schlicht bezahlbar.

Beide Punkte zusammen haben jedoch ihren Knackpunkt. Nicht alle Verschlüsselungstechnologien sind bei FDE (oder überhaupt) in der Lage einmal verschlüsselte Container/Volumes in der Größe zu verändern. TrueCrypt kann dies nur bei Containern und dann mit einem Performance-Overhead, der inakzeptabel ist. Bei den OpenSource-Technologien bleibt dann nur noch dm-crypt über. Dieses hat jedoch die „Schwäche“, dass der Verschlüsselungheader (welcher Cipher, Start, Ende, etc) selber unverschlüsselt auf der Platte liegt. Sicherheitstechnisch ist das kein Problem. Auch wenn der Angreifer den Cipher kennt, beißt er sich bei den richtigen Algorithmen und Schlüssellängen die Zähne aus. Nur kann ein dm-crypt Benutzer nicht glaubhaft abstreiten, dass er eben dm-crypt nicht benutzt.

Mir war die juristische Debatte erstmal egal, ich wollte ein verschlüsseltes dynamisches RAID-Device. Das hat mich ein ganzes Wochenende gekostet (500GB auf 750GB zu migrieren dauert immer ungefähr 4 Stunden). Es hat sich mir ein zentrales Problem in den weg gestellt. Es gibt für die Konsole kein Tool, dass eine Partition vergrößern kann, dessen Dateisystem es nicht erkennt. Man kann mittels fdisk die Partitionstabelle löschen und neu schreiben. So sadomasochistisch bin ich aber nicht veranlagt. Man riskiert immer vollen Datenverlust!

Man kann den Umweg über Logical Volume Manager (LVM) gehen. Dazu wird bei einem vergrößerten Device nicht die Partition vergrößert, sondern im neuen freien Bereich einfach eine weitere Partition erstellt. Diese wird dann dem Logischen Device hinzugefügt. Arbeitet man nur mit einem Fake- oder Software-RAID, mag das akzeptabel sein. Kommt es bei diesen zu einem Stromausfall darf man eh beten. Hardware-RAIDs nutzen jedoch BBUs um Datenverlust im Fehlerfall zu unterbinden. Was mit der LVM Zwischenschicht wieder ausgehebelt währe.

Möglichkeit drei ist einfach: man nutzt keine Partitionierung. Dazu muss man einfach wie folgt sein Device „beschreiben“

sudo parted /dev/sdX
mklabel msdos
quit

Nach dieser Aktion hat man eine MSDOS – Partitionierung, aber nicht erschrecken, die verschwindet gleich wieder ;).
Jetzt kann man die Festplatte direkt verschlüsseln, was z.B. bei einer GPT – Partitionstabelle nicht geht.

sudo cryptsetup luksFormat --cipher aes-xts-plain:sha256 -s 256 -q /dev/sdX #Verschlüsselung anlegen
sudo cryptsetup luksOpen /dev/sdX someCryptDev #Verschlüsseltes Device öffnen
mkfs.ext3 /dev/mapper/someCryptDev #verschlüsseltes Device formatieren
mount /dev/mapper/someCryptDev /mnt/someCryptDevUncrypted

Beim Wiedereinhängen einfach luksFormat und mkfs weglassen, sonst blöd 😉
Interessant wird jetzt die Vergrößerung. Dazu im unter lagerten RAID erstmal das Device vergrößern. Um die neue Festplattengröße dem System bekannt zu machen muss man entweder mittels des RAID-Treibers ein rescann auslösen, man entlädt einfach den ganzen Treiber und hängt ihn wieder ein oder startet einfach neu.

sudo lsmod #alle Treiber anzeigen lassen und den RAID-Treiber raus suchen.
sudo modprobe -r
 #RAID-Treiber entladen
sudo modprobe
 #RAID-Treiber laden

Letztes geht nicht ohne das aushängen der gemountet Partition. Besser gesagt, es geht schon, bloß muss man dann mit Datenverlust rechnen. Ein Rescan sollte zu keinem Datenverlust führen, das ist jedoch Treiber-abhängig, in jedem Fall das Manual oder den Maintainer konsultieren. Für 3Ware (jetzt LSI) Raids müssen die Devices z.B. ausgehängt sein.

Ist die neue Festplattengröße im System bekannt, muss man sie nutzbar machen. Dazu gibt es zwei Möglichkeiten:

  • Online – ohne Downtime des Dateisystems: Dies benötigt ein Dateisystem, was das Vergrößern/Verkleinern „on-the-Fly“ unterstützt. Das können z.b. EXT3 oder XFS. 
    sudo fdisk -lu /dev/sdX #Sektoren raus schreiben
sudo cryptsetup status  #Offset raus schreiben
sudo cryptsetup resize -o  -b ;
sudo resize2fs /dev/mapper/sdX #resize des FileSystems am Beispiel EXT3
  • Offline – mit Downtime des Dateisystems: Die kann mit allen Dateisystemen durchgeführt werden, die vergrößert/verkleinert werden können. Es ist auch ein Stück komfortabler. 
    sudo umount /dev/mapper/; #aushängen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
sudo cryptsetup luksClose  #schließen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
sudo cryptsetup luksOpen /dev/sdX  #damit ist auch schon die Vergrößerung des verschlüsselten Devise erledigt...
sudo resize2fs /dev/mapper/ #resize des FileSystems am Beispiel EXT3/EXT2

    Beim öffnen des Device nutzt selbiges scheinbar automatisch allen verfügbaren Platz, wenn man nichts anderes (mittels resize) einstellt.

So kann kann in jedem Fall ohne viel Stress seine RAID-Device stückchenweise nach seinen Bedürfnissen erweitern. Dennoch sollte man von allen wichtigen Daten immer ein Backup haben! Zudem sollte man dieses Vorgehen ein, zwei mal geübt haben, bevor man es mit wichtigen Daten durchführt;)