Denn man möchte vermutlich weder, dass irgendwelche geschäftlichen Daten Fremden in die Hände kommen, noch wird man scharf drauf sein, die privaten Bilder von Tante Erna aus ihrem Urlaub in Hinterzupfingen anderen Menschen zu präsentieren.
Dabei geht es nicht um sensible private Daten wie Lebensläufe, Bankdaten, Kontoauszüge oder wichtige geschäftliche Daten, nein vielmehr geht es um alle vorhandenen Daten, bzw. auch vermeintlich schon gelöschte Daten. Gelöscht heißt nämlich, dass das Betriebssystem nur den Verweis auf die Daten löscht bzw. den Bereich intern als leer markiert, so dass dort neue Daten gespeichert werden können.
Diese Daten sind nicht umsonst privater Natur und genau das sollen sie auch bleiben. Das heißt nicht, dass man etwas zu verstecken hat, denn schließlich laufen wir ja auch alle nicht grundlos mit Kleidung rum.
Nach gängiger Meinung genügt zum sicheren Löschen das Überschreiben der kompletten Festplatte mit einem Zufallsmuster. Gerüchte, wonach selbst überschriebene Daten aus "Restmagnetspuren" der Spurränder von Festplatten wiederhergestellt werden konnten, gehören wohl ins Reich der Verschwörungstheorien und scheinen nur Spekulationen zu sein. (Update: Ein entsprechender Artikel von Peter Gutmann, beschreibt daher eine Methodik zum sicheren Löschen von Daten durch mehrmaliges Überschreiben mit unterschiedlichen Bitmustern. Zu beachten ist aber, dass dieser Artikel von 1996 stammt und wohl mittlerweile durch die vergrößerte Speicherdichte heutzutage nicht mehr allgemein gültig ist. Es stellt sich sogar die Frage, ob einfaches Überschreiben durch Nullen nicht sogar eine ausreichende Sicherheit beim Überschreiben verspricht.)
Um das zu erreichen, genügt bei einer gängigen Linuxdistribution der dd Befehl. Damit kann man sehr einfach Daten auf die Festplatte schreiben. Die gängige Empfehlung ist dabei, dd if=/dev/urandom of=/dev/sda bs=1M auszuführen. Damit liest man aus dem Pseudo-Zufallspool des Systems und schreibt die Daten als 1 MB große Blöche auf das Gerät /dev/sda. Das ist grundsätzlich auch ok, das einzige Problem, was man dabei hat ist, dass der Zufallspool normalerweise nicht sehr gut gefüllt ist und nur relativ langsam gelesen werden kann.
Bei heutigen Festplattengenerationen mit mehreren hundert Gigabyte Speicher, kann da schon einmal ein Nacht für das Überschreiben drauf gehen (oder vielleicht sogar mehr, ich habe das noch nicht so genau getestet).
Schneller und äquivalent sicher ist es dagegen, die Festplatte mit Nullen zu beschreiben, die danach verschlüsselt werden. Dazu kann man cryptsetup verwenden, was mittlerweile wohl bei allen modernen Linux Distributionen dabei sein sollte:
CODE:
# cryptsetup -d /dev/random -c aes-xts-plain create sda /dev/sda
# dd if=/dev/zero of=/dev/mapper/sda bs=1M
# cryptsetup remove sda
Hier legt man eine logische Blockschicht über dem Gerät /dev/sda an, dass mit einem Zufallsschlüssel, der aus dem Zufallspool /dev/random kommt, verschlüsselt wird. Alles was auf dem neuen Blockschicht /dev/mapper/sda geschrieben wird, wird intern verschlüsselt auf das eigentliche Gerät /dev/sda geschrieben. Der Schlüssel ist eigentlich egal, er wird im Prinzip nur genutzt, um ein zufälliges Bitmuster aus den Nullen zu generieren und zu schreiben.
Damit braucht das System nicht auf den langsamen Zufalls-Entropiepool zu warten (es muß nämlich von dort nur zur Erstellung des Schlüssels einmalig 256bit lesen), sondern kann sehr schnell lesen die Nullen lesen. Durch die Verschlüsselung verlangsamt sich die Schreibgeschwindigkeit zwar, ist aber dennoch größer als bei der vorherigen Methode. In Zeiten immer schnellerer CPUs (zumindest in Desktop System) fällt der Geschwindigkeitsverlust wahrscheinlich immer geringer aus und wer von Anfang an ein verschlüsseltes Gesamtsystem verwendet, der wird gar keine Geschwindigkeitseinbußen bemerken.
Getestet habe ich das Ganze auch mal mit einer leeren 10GB Partition:
CODE:
chrisbra@ubuntu:/temp$ dd if=/dev/zero of=big_file bs=10M count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
10485760000 Bytes (10 GB) kopiert, 228,142 s, 46,0 MB/s
root@ubuntu:/temp# losetup /dev/loop2 big_file
root@ubuntu:/temp# time dd if=/dev/urandom of=/dev/loop2 bs=1M
dd: Schreiben von „/dev/loop2“: No space left on device
10000+1 Datensätze ein
9999+1 Datensätze aus
10485760000 Bytes (10 GB) kopiert, 1786,48 s, 5,9 MB/s
real 29m46.537s
user 0m0.050s
sys 25m36.450s
root@ubuntu:/temp#
root@ubuntu:/temp# cryptsetup -d /dev/random -c aes-xts-plain create loop /dev/loop2
root@ubuntu:/temp# time dd if=/dev/zero of=/dev/mapper/loop bs=1M
dd: Schreiben von „/dev/mapper/loop“: No space left on device
10001+0 Datensätze ein
10000+0 Datensätze aus
10485760000 Bytes (10 GB) kopiert, 205,879 s, 50,9 MB/s
real 3m25.885s
user 0m0.000s
sys 0m12.290s
Wie man sieht, habe ich hier eine durchschnittliche Schreibgeschwindigkeit von 5,9MB/s mittels der traditionellen Methode erhalten. Durch das Verschlüsseln, konnte die Schreibgeschwindigkeit fast verneunfacht werden. Noch drastischer sind die absoluten Zeiten: fast 30 Minuten anstelle von 3,5 Minuten.
Das ist natürlich kein Benchmark, sondern soll nur zeigen, welch drastischen Unterschiede zwischen den Methoden existieren. Spielen kann man eventuell noch mit dem Blocksize Parameter, der in diesem Beispiel auf 1 Megabyte gesetzt war. Es ist nicht auszuschließen, dass es mit einem anderen Verschlüsselungsalgorithmus (hier aes-xts-plain) sogar noch schneller geht. (einfahcer Benchmark verschiedener Verschlüsselungsalgorithmen und noch ein Benchmark, ausführlicher)
Disclaimer: Unbedingt zweimal prüfen, auf welches Gerät man schreibt, bevor man sich sein System zerschießt. Dieses Gerät sollte auch nicht anderweitig parallel verwendet werden, sonst besteht die Gefahr, dass noch etwaige Daten nicht überschrieben werden konnten, weil sie noch geöffnet waren.
