Re: Sicheres Loeschen von Festplatten

Olaf Hoyer <ohoyer(at)ohoyer.de> wrote:
> Eine der Fragen, die periodisch haeufiger hochschlaegt, und die mich
> jetzt gerade auch konkret beruflich beschaeftigt, ist, wie eine Platte
> zuverlaessig zu loeschen ist, bevor sie ausser Haus geht.
>
> Szenario: Alte Rechner werden incl. Festplatte z.B. verkauft oder
> verschrottet, so dass die Platten natuerlich definiert leergemacht
> werden muessen.
>
> Was ich nach einigen Recherchen und nem Telefonat mit Ontrack

Laß mich mal kurz lachen.

OnTrack war nicht in der Lage, von einer Festplatte, die
eine Reihe defekte Sektoren hatte, irgendwas zu retten.
Kein Stück. Ich habe mit FreeBSD-Bordmitteln (dd, ein
leicht modifiziertes fsck, und ein paar andere Dinge)
von dieser Festplatte diverse MySQL-Tables, Webseiten und
Bilder restaurieren können.

Du ahnst jetzt sicher, für wie kompetent ich OnTrack nun
halte.

Allerdings haben sie mit folgender Aussage wohl recht:

> rausbekommen habe, ist, dass bei allen halbwegs aktuellen Platten
> bereits ein einmaliges Ueberschreiben mit Datenschrott (sowas wie dd
> if=/dev/urandom of=/dev/ad0) die Platte in einen Zustand versetzt, wo
> keine Daten mehr zu rekonstruieren sind, und spaetestens bei 3-maligem
> Ueberschreiben keine Chance fuer ein Labor besteht, noch irgendwie
> verwertbare Daten runterzuholen.

Das halte ich für korrekt.

> Dh. so einige Wissenschaften, wie sie z.B. in diversen, zertifizierten
> oder anerkannten Verfahren stecken, wie z.B. DoD 5220-22.M, dem
> Guttmann 35-pass verfahren etc.

Der arme Herr Gutmann wurde _gründlichst_ mißverstanden.
Es gibt kein »Gutmann 35-pass Verfahren«, das man sinnvoll
auf eine bestimmte Festplatte anwenden kann. Aus diesem
Grund hat er seiner Arbeit später einen Epilog hinzugefügt
(den man eigentlich als erstes lesen sollte), um das zu
klären. Leider scheinen nur wenige bis zu dem Epilog
durchzukommen, da sich die Mythen um das 35-pass Verfahren
weiterhin hartnäckig halten.

Ich erlaube mir mal, die wichtigsten Aussagen herauszu-
schnippeln: »In the time since this paper was published,
some people have treated the 35-pass overwrite technique
described in it more as a kind of voodoo incantation to
banish evil spirits than the result of a technical analysis
of drive encoding techniques. In fact performing the full
35-pass overwrite is pointless for any drive [...] You never
need to perform all 35 passes. For any modern PRML/EPRML
drive, a few passes of random scrubbing is the best you can
do. [...] With modern high-density drives, even if you've
got 10KB of sensitive data on a drive and can't erase it
with 100% certainty, the chances of an adversary being able
to find the erased traces of that 10KB in 80GB of other
erased traces are close to zero.«

Die vollständige Arbeit von Gutmann ist hier zu finden:

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

Wobei man noch betonen muß, daß die Arbeit von 1996 ist,
also 10 Jahre alt, und teilweise auf Eigenschaften von
Festplatten beruht, die noch erheblich älter sind. Wie
Du schon richtig sagtest: Bei modernen Platten, bei
denen man die Anzahl der Atome pro Bit fast schon an
einer Hand abzählen kann (Stichwort Perpendicular Recor-
ding), genügt wohl ein einziger Überschreibvorgang mit
Zufallsdaten.

> Konkrete Fragen, die sich hieraus fuer mich ergeben:
>
> - weiss jemand, (ggf. mit Quelle) obs verbindliche, empfohlene Regeln
> staatlicher Natur gibt (oder welche davon gerade aktuell ist)

Ist mir nicht bekannt, und auf den Webseiten des BSI
sind auf Anhieb auch keine konkreten Informationen zu
dieser Thematik zu finden.

> - stellt z.B. ein dd(1) sicher, dass es jeden Block auf der Platte
> erwischt, gerade wenns mit einer Blocksize groesser der Blocksize eines
> Sektors arbeitet?

Es stellt sicher, daß Du jeden adressierbaren Block der
Festplatte erwischst, sofern keine I/O-Fehler auftreten.

Du hast also zwei potentielle Probleme: Erstens können
I/O-Fehler auftreten. Wenn die Platte den Schreibvorgang
abbricht, werden die Bytes dahinter nicht überschrieben.

Zweitens gibt es physikalische Sektoren auf der Festplatte,
die sich nicht logisch adressieren lassen. Das sind z.B.
Reservesektoren für das Bad-Sector-Remapping, und natür-
lich die Originalsektoren, die bereits remappt wurden.
Diese kannst Du auf herkömmlichem Weg nicht überschreiben.

> - RAID-Controller oder simple Controller mit Cache haben da natuerlich
> auch so freudige Ueberraschungen, vermute ich

Nunja, wenn einen Controller mit NVRAM-gestütztem Cache
hast, und Du gibst diesen zusammen mit der Platte weg,
dann muß Du natürlich auch dafür sorgen, daß der Cache
gelöscht wird.

> - Kann einem evtl. ein write-cache auf der Platte boese Streiche
> spielen, oder fasst dieser lediglich einige Zugriffe zusammen und bei
> Ausschalten desselben wirds einfach nur langsamer wegen erhoehter Anzahl
> der Zugriffe, weil viele eben nicht mehr kombiniert werden koennen?

Letzteres. Write-Caches auf Platten sind üblicherweise
kein NVRAM, sondern normaler DRAM, weil's sonst zu teuer
wäre. Da würde ich mir keine Sorgen machen.

> - wenn man auf obige Weise einen dd macht, wie stellt man sicher, dass
> auch alle Sektoren ueberschrieben sind?

Wenn das dd(1) ohne Fehlermeldungen terminiert, dann wur-
den zumindest alle Sektoren überschrieben, die über das
Device logisch adressierbar sind.

Die sicherste Methode, um die Daten auf der gesamten Fest-
platte zu vernichten, ist sicherlich eine physikalische
oder chemische Zerstörung der Oberflächen. Allerdings
kann man sie dann nicht mehr verkaufen.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message