Ich habe gelesen, dass SSDs auch nach mehrfachem Überschreiben nicht sicher gelöscht sind. Begründet wird das damit, dass SSDs einen für das Betriebssystem scheinbaren Datenträger generieren. Der physische Datenbestand kann sich aber auch in einem nach außen hin unsichtbaren Reservespeicher befinden oder er ist physisch an einem anderen Ort, welche von der Löschsoftware nicht erreicht werden kann. Diese Erklärung ist bis dahin verständlich. Allerdings habe ich dazu eine Verständnisfrage: Nehmen wir an ich habe eine SSD mit 10GB Speicher und es gibt keinen Reservespeicher. Nehmen wir an der Speicherkontroller der SSD ist so ausgelegt, die Daten so zu verteilen, dass jede physische Speicherzelle gleich häufig beschrieben wird(offizielle Funktionsdefinition des Conrollers). Nehmen wir weiter an, dass die SSD absolut neu ist, sie wurde noch nie beschrieben. Jetzt wird das erste GB der SSD mit sensiblen Daten beschrieben. Wenn ich jetzt die gesamte SSD sicher überschreiben will sollte doch Folgendes passieren: Zuerst werden physisch die restlichen 9GB mit zufälligen Daten gefüllt. Wenn ich jetzt nochmals den gesamten Speicher mit 10GB überschreibe müssten doch alle Daten restlos gelöscht sein und jede Zelle wäre demnach gleich oft, also hier 2-mal überschrieben. Damit wären allen zellen sicher überschrieben.... 2. Gedankenexperiment: Gleiche Ausgangslage wie oben,allerdings soll die SSD über einen 5GB großen Reservespeicher verfügen. Wir überschreiben wie oben die verbleibenden freien 9GB des hypothetischen Hauptspeichers. Im ersten GB befinden sich wiederum sensible Daten. Damit sind die 10Gb gefüllt. Allerdings schreibe ich nun nochmals 5GB auf die Platte die nun im theoretischen Reservespeicher landen da diese Speicherzellen noch nie beschrieben worden sind. Wenn ich nun nochmals 1GB+9GB+5GB=15GB auf die Platte schreibe müssten doch theoretisch die sensiblen Daten sicher gelöscht sein. Jede physische Flashspeicherzelle wäre genau 2-mal beschrieben. Allgemein müsste gelten: X sei benutzbare Speicherkapazität der SSD; B belegter Speicher mit sensiblen Daten Y sei Reservespeicher; Z die notwendige Anzahl der Überschreibungszyklen zum sicheren Überschreiben der Daten; Dann gilt unter der Annahme das jede Speicherzelle gleich oft beschrieben werden soll, für das sichere löschen aller Daten: Z=((X-B)+Y+X+Y)/X=(2X+2Y-B)/X; Verbesserung: Z=(2X+2Y)/X; Somit ergäbe sich für das 2. Gedankenexperiment folgende Anzahl von zwingenden Überschreibungszyklen Z: Z=(2*10GB+2*5GB)/10GB=3 => 3 Überschreibungsszyklen für Löschsoftware notwendig für sicheres Überschreiben der Daten der SSD Warum ist es aber trotzdem nicht sicher die obige SSD mind. 3 mal zu überschreiben? Liegt es am Controller der SSD, dass physische Speicherzellen doch unterschiedlich oft beschrieben werden?
Die Lösung lautet Secure Erase. Ist ein einziger Befehl an die SSD, die daraufhin den Schlüssel für das interne Wear-Leveling bzw. die interne Verschlüsselung verwirft und alle Blöcke als leer annimmt. Danach kommt man nicht mehr sinnvoll an die an sich noch vorhandenen Daten ran. Das mehrfache Beschreiben der SSD ist schädlich, aus diesem Grund soll man u.a. das Defragmentieren abschalten, da es hohe Schreiblasten erzeugt und dadurch die Flashzellen ausleiert.
Sascha schrieb: > Die Lösung lautet Secure Erase. ich möchte widersprechen. die lösung lautet den datenträger nie unverschlüsselte daten sehen zu lassen.
c.m. schrieb: > ich möchte widersprechen. > die lösung lautet den datenträger nie unverschlüsselte daten sehen zu > lassen. naja, einige SSD veschlüsseln automatisch. Sei erzeugen einfach beim Secure Erase einen neuen Schlüssel.
Ich wollte nicht fragen, wie man eine SSD sicher löscht, sondern warum Mehrfachüberschreiben nichts hilft. Wenn der Controller alle Speicherzellen gleich oft beschreibt, würde ich doch nach und nach alle Speicherzellen überschreiben können. Sie den Kontext meiner obigen Frage.
Ja, aber nur im Mittel gleich oft. D.h. du kannst nicht sicher herausfinden wann er eine bestimmte physikalische Speicherstelle wirklich überschrieben hat. Je öfter du drüber schreibst, desto höher die Wahrscheinlichkeit, aber die Details der Algorithmen verraten die Hersteller nicht.
Liegt ein Dateisystem drüber, dürfte es reichen, einmal komplett die 10GB (erster Fall) drüberzubügeln. Alle Bereiche sind dann referenziert - wo soll da noch das 1GB an "sicher zu löschenden" Daten rumliegen? Es ist dann völlig egal, was der Controller da ausheckt.
Hans schrieb: > Ich wollte nicht fragen, wie man eine SSD sicher löscht, sondern warum > Mehrfachüberschreiben nichts hilft. weil man nicht weiß was der controller in wirklichkeit macht. du kannst nicht überprüfen wo welche daten liegen, du weißt nicht ob die "sensiblen daten" unerreichbar für schreibzugriffe auf reserve flash gelandet sind. das gleiche prblem hast du btw auch bei festplatten mit reserve sektoren (was eigentlich redundant zu erwähnen ist, weil alle diese sektoren haben). wenn dir fad ist kannst du dir mal anschauen was die LUKS entwickler für verrenkungen gemacht haben um keyslots so zu verteilen das sie nicht aus reservesektoren rekonstruiert werden können. fazit: (mahrfach)überschreiben kann helfen, muss aber nicht. unüberprüfbar. lösung: keine unverschlüsselten daten speichern.
Hans schrieb: > Wenn der Controller alle Speicherzellen gleich oft beschreibt, würde ich > doch nach und nach alle Speicherzellen überschreiben können. > Sie den Kontext meiner obigen Frage. Deine Überlegung ist vollkommen richtig. Leider sieht die Praxis etwas anders aus als das Gedankenexperiment. Du hast ein Dateisystem auf der SSD, daher werden manche LBA öfter geschrieben als andere (z.B. die Verzeichnisse). Der SSD-Controller führt intern Buch, welche Speicherblöcke (von denen jeder mehrere 512byte LBA enthält) wie oft aktualisiert wurden. Daher kann es bei starker Unsymmetrie durchaus vorkommen, dass auch bei mehrmaligem Überschreiben zunächst immer die gleichen Blöcke verwendet und andere dafür nicht angetastet werden. Wie secure der secure erase nun wirklich ist, steht auf einem anderen Blatt. Evgeny K. aus R. hat gerade entdeckt, dass es bereits Malware gibt, welche die Firmware von Festplatten und SSDs patcht...
Sammy schrieb: > Liegt ein Dateisystem drüber, dürfte es reichen, einmal komplett die > 10GB (erster Fall) drüberzubügeln. Alle Bereiche sind dann referenziert > - wo soll da noch das 1GB an "sicher zu löschenden" Daten rumliegen? Es > ist dann völlig egal, was der Controller da ausheckt. Das trifft leider nicht zu. Bei einer Magnetplatte ist tatsächlich eine Zuordnung vom Dateisystem zum Sektor (und somit dem physikalischem Speicherort) möglich. Bei SSDs kann der Controller die Inhalte von ein und dem selben Sektor bei mehreren Schreibzugriffen auf verschiedene Speicherzellen aufteilen. Umgekehrt sollte man aber auch betrachten, wie hoch der Aufwand ist, an diese Daten heran zu kommen. Da muss ich einzelne Flashchips auslesen und mir aus dem Datensalat die richtigen Fitzel herauspicken. Ich kann mir nicht vorstellen, dass irgend wer hunderte (oder wahrscheinlich eher zehntausende) Euro ausgibt, um Teile meiner Katzenfotos zu rekonstruieren ;-) Wenn ich natürlich mit Firmengeheimnissen hantiere komme ich schnell in andere Regionen. In diesem Fall sollte man tatsächlich keine unverschlüsselten Daten auf eine SSD schreiben, bzw. die SSD nach dem Ende ihrer Einsatzdauer zu zerstören.
1 | dd if=/dev/zero of=/dev/sdX bs=1M |
kommt eine Fehlermeldung, dann ist die Platte gelöscht.
Gerrit B. schrieb: > Bei SSDs kann der Controller die Inhalte von ein und dem selben Sektor > bei mehreren Schreibzugriffen auf verschiedene Speicherzellen aufteilen. Na und? Wenn es fuer 10GB Speicherzellen gibt und ich 10GB via Dateisystem draufkopiere (also alles neue referenziert ist), ist alles alte uebrerschrieben. Ansonsten ist das Laufwerk kaputt und ich kann nicht zu 100% auf die neuen Daten zugreifen.
Korrektur: wenn der Konsolenprompt wieder da ist, ist die Platte gelöscht
bingo schrieb: > Korrektur: wenn der Konsolenprompt wieder da ist, ist die Platte > gelöscht Oder auch nicht, darum geht es hier ja. Und schon garnicht wenn sowas wie Fanny oder Grayfish in deiner Festplatte wohnen: http://m.spiegel.de/netzwelt/web/a-1018852.html
Sammy schrieb: > Na und? Wenn es fuer 10GB Speicherzellen gibt und ich 10GB via > Dateisystem draufkopiere (also alles neue referenziert ist), ist alles > alte uebrerschrieben. Ansonsten ist das Laufwerk kaputt und ich kann > nicht zu 100% auf die neuen Daten zugreifen. Dumm nur, dass die typische SSD wie schon erwähnt Reservebereiche hat. Du hast also hinter 10 GB Dateisystem z.B. 12 GB Speicherzellen. Somit bleiben 2 GB, die man noch nach Daten durchwühlen kann.
Hans schrieb: > ...und es gibt keinen Reservespeicher. Sammy schrieb: > ...die 10GB (erster Fall) drüberzubügeln. Gerrit B. schrieb: > Dumm nur, dass die typische SSD wie schon erwähnt Reservebereiche hat. Bleib doch beim Thema!
Hallo, Man kann davon ausgehen dass die Daten sicher gelöscht sind, wenn der Physikalische Flash Block Erased wurde. Welcher Physikalische Block wann gelöscht wird, entscheidet jedoch nicht der Host (Computer) sondern der Controller der SSD. NAND Flash kann in kleineren Einheiten programmiert und gelesen werden, man spricht in der Regel von (Logischen) Pages. Bevor eine Page Programmiert werden kann muss sie aber gelöscht sein, Löschen kann man jedoch nur in grösseren Einheiten, den sog. (Logischen) Flash Blöcken. Blöcke sind ein vielfaches grösser als eine Page (bis zu einem MiB oder noch grösser). Ein Block kann nicht unendlich oft gelöscht werden weil er einer Abnutzung unterliegt. Daher versucht der Controller die Block Erases möglichst sparsam zu verwenden. Welcher Block wann wie gelöscht wird unterliegt dem Algorithmus des Controllers und ist abhängig vom a) Ist zustand b) Zugriff Jede SSD hat etwas mehr Blöcke zur Verfügung als für den Userbereich benötigt wird. Nimmt man nun eine neue SSD, schreibt an eine Logische Adresse Daten, und überschreibt diese danach wieder, ist es sehr wahrscheinlich dass der Controller die Daten zwar intern als nun ungültig vermerkt hat, diese aber noch nicht Physikalisch gelöscht wurden. Solange der Controller freie, bereits gelöschte Blöcke/pages zur Verfügung hat wird er diese belegen, da es von der Performance her idealer ist. Ein Block wird erst gelöscht wenn viele Pages eines Blockes ungültig geworden sind und der Controller diesen auflöst (Garbage Collection). Wann das genau der Fall ist entscheidet der Controller. Es kann deshalb je nach Zugriff sehr gut sein, das längst gelöschte Daten Physikalisch noch Programmiert sind. Wenn eine SSD Sequentiell mehrfach überschrieben wird, kann man aber davon ausgehen dass die Daten weitgehend gelöscht sind. Theoretisch ist es, abhängig vom Algorithmus aber möglich das gewisse Reserveblöcke noch mit ungültigen Daten programmiert sind. Weil diese recht geringe Wahrscheinlichkeit für Militärische oder ähnliche Zwecke nicht sicher genug ist, gibt es spezielle Löschalgorithmen und Funktionen die eben auch diese Reserveblöcke mitlöschen. Gruss
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.