Christophs Weblog

Vierundzwanzig sind zu wenig

Rettung einer verschlüsselten Partition

Es war einmal eine junge Frau, die von toller EDV sehr begeistert war. Sätze wie „ich habe meine Festplatte verschlüsselt“ brachten ihre Augen zum leuchten und weckten in ihr das „will ich auch“-Verlangen. Sätze wie „Du musst aber auch regelmäßig Backups Deiner Dateien machen“ weckten dagegen weniger Aufmerksamkeit, aber was soll’s, sie ist ja selber groß.

Nun gab vor ewig langer Zeit mal eine ihrer Festplatten den Geist auf und sie verbrachte eine bange Nacht in der Gewissheit, dass ihre Daten für immer verloren seien. Aber wie das Glück nun mal so spielt lief die Platte trotz Hardwareschadens nochmal (ein einziges letztes Mal) an und wir konnten ihre Daten retten.

Anfang letzter Woche kam nun mal wieder so ein Anruf …    

Erste Fragen am Telefon ergaben, dass die verschlüsselte Partition nicht mehr gemountet wird – der Computer fragte nichtmal mehr nach dem Passwort. Einige Zeit später ein kleinlautes Geständnis: „Ich glaube ich habe was ganz dummes gemacht: Hatte das Verzeichnis /root/crypt/ eventuell irgendwas mit der Verschlüsselung zu tun? Das habe ich letztens mal gelöscht.“

Ob es was mit der Verschlüsselung zu tun hat? Naja, ein bisschen vielleicht: DORT DRIN LIEGT DER KEY! Lag, um genau zu sein.

„Spiel doch einfach die Backups wieder ein“ … der Standardwitz. Die Antwort war mir vorher schon klar und immerhin war Ostern und sie nochdazu für dumme Witze grad nicht wirklich empfänglich.

„Nun denn, Du hast ja sicherlich nichts an der Festplatte verändert, oder? Die Datei ist bestimmt noch vorhanden“, fragte ich. „Als nichts mehr funktioniert hat, habe ich die ganzen Updates rückgängig gemacht, die ich an diesem Tag eingespielt hatte.“ – Ihre Distribution war Gentoo und Updates installieren bzw. rückgängig-machen heißt, dass viel kompiliert werden muss (sprich: auf die Platte geschrieben wird).

Zusätzlich war das Dateisystem ext3, also ein Journaling-Dateisystem, dass sowas wie „undelete“ ohnehin nicht kennt.

Nochmal die Fakten: /dev/hda1 war die root-Partition auf eventuell noch irgendwo ein gpg-Verschlüsselter 256-bit-Key für /dev/hda2 liegt. /dev/hda2 war eine via dm-crypt mit AES verschlüsselte 10 GB Parition mit sämtlichen privaten Daten dieser jungen Frau. Kein Backup weit und breit …

Wem das noch nicht reicht: In diesen privaten Daten lag eine Studienarbeit, an der sie in den letzten 4 Wochen täglich 8 Stunden geschrieben hatte. Selbstverständlich existierte auch davon keinerlei Backup.

Weiter im Text: Mir erschien es relativ hoffnungslos, dass wir jemals auf diesen Paritionen noch etwas retten könnten. hda2 direkt zu knacken war definitiv aussichtslos. AES/dm-crypt ist gerade dafür vorgesehen, dass man es nicht knacken kann (zumindest nicht in dem Jahrhundert, in dem ihr ihre Daten noch etwas gebracht hätten). Eine gelöschte, verschlüsselte Datei auf hda1 zu finden erschien mir auch nicht so aussichtsreich. Bliebe vielleicht noch die Suche im Swap, aber das war natürlich auch verschlüsselt …

Nun, in diesem Glauben haben wir Sicherungskopien der relevanten Paritionen angelegt und das System neu aufgesetzt (Ubuntu, damit die Updates schneller gehen. Keine Verschlüsselung mehr. Von der Auswahl von ext2 – das habe wenigstens ein undelete – konnte ich sie grad noch so abhalten …).

Innerlich konnte sie sich also ca. 3 Tage lang mit dem Gedanken anfreunden, dass sämtliche Daten, E-Mails, Fotos, etc. verloren sind.

Aber da es mich auch irgendwo belastet hat habe ich weiter darüber nachgedacht und bei einem Gespräch mit einem Freund bekam ich die Anregung doch noch etwas nach der gelöschten Datei zu suchen. Immerhin bestehe eine gewissen Chance, dass der Key doch noch nicht überschrieben wurde.

OK, dann schauen wir uns doch mal an, wie GPG einen String symmetrisch verschlüsselt. Vermutlich haben wir CAST5 benutzt und ah, interessant: GPG benutzt Metadaten, die den benutzten Verschlüsselungsalgorithmus angeben. Ich habe mir also einen Beispiel-Key verschlüsselt und mit folgenden Ausdruck auf /dev/hda1 losgelassen:

grep `head -c 4 beispiel-key.gpg` /backup/partition_hda1 > /tmp/moeglicher-key.txt

Tatsächlich wurde eine Zeichenkette gefunden die passen könnte. Ich musste noch etwas Datenmüll entfernen (Müll nach den verschlüsselten Daten ist egal, aber davor darf nichts stehen) und ein

cat moeglicher-key.txt | gpg

bestätigte schon mal, dass es vermutlich wirklich irgendwas verschlüsseltes sein könnte. Nun, inzwischen war es 2 Uhr nachts und ich konnte die junge Frage leider nicht direkt nach ihrem Passwort befragen (ja, ich habe es versucht ;-).

Am nächsten Morgen dann die Auflösung: Es war ihr Key, ihr Passwort funktionierte, via losetup/cryptsetup/mount ließ sich die Partition hochfahren und lieferte sämtliche verloren geglaube Daten.

Wer diese Geschichte gerne bebildert sehen möchte, der lese Userfriendly ab dem 05. April 2007 [1]. Ironischerweise hatte Stef fast zeitgleich genau das gleiche Problem und Mike durfte sich damit rumschlagen.

Aber irgendwie bin ich schon froh, dass ich ihr helfen konnte. Zum einen bin ich jetzt ihr Held und zum anderen lernt sie vielleicht was draus 🙂

[1] http://ars.userfriendly.org/cartoons/?id=20070405

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Christophs Weblog © 2009-2017