Wie geclonte SSD löschen?

Holt schrieb:
Bei der XP941 passt das beim Secure Erease wohl öfter, aber das ist auch eine OEM SSD
Die XP941 wird vom Magician Tool unter Windows gar nicht als Samsung Produkt erkannt und bietet gar kein secure erase an.
Vielleicht geht das mit 3rd party software, aber wenn das schief geht braucht man sich hinter nicht über Samsung ärgern.
 
Habe hier mal alle notwendigen Schritte für die Nachwelt zusammengefasst ;):

SSD für Vekauf löschen
=======================

- Eingabeaufforderung starten
- "DISKPART" ausführen
- Mit dem Befehl "list disk" werden alle Datenträger angezeigt
- Mit "select disk X" das Laufwerk auswählen (X=Nummer des Datenträgers)
- Befehl "clean all" ausführen (ACHTUNG! Alle Daten werden unwiederruflich gelöscht!)
- Danach Datenträger zur Sicherheit noch neu partitionieren (z.B. per Datenträgerverwaltung o.ä.)
- Fertig!

Gruß
Kümmel
 
Magician erkennt keiner der OEM SSDs von Samsung, aber man braucht ja nicht Magician um ein Secure Erease auszuführen, da gibt es andere Tools und man kann es unter Linux mit Bordmitteln (hdparm) machen.
 
@kuemmelkassel: Danke für die Zusammenfassung. Und das ist dann ebenbürtig zu secure erase? Wie lange dauert dann die Ausführung des clean all so im allgemeinen? Geht das genau so zuverlässig auch mit HDDs?
 
Hast Du einen groben Wert, wie lange das dauert? Meine letzter secure erase auf einer SSD (256 GB) hat ca. 5 sec. gedauert.
 
Deutlich länger. Einen groben Wert habe ich leider nicht, da ich den Vorgang meist bei Feierabend starte. Vielleicht hat da @Holt einen Wert für uns.
 
Das ist halt das coole bei secure erase: da die SSD grundsätzlich immer alle Daten verschlüsselt speichert, wird beim secure erase einfach der momentane Schlüssel weggeworfen und ein neuer erzeugt. Und schwups, sind die bisherigen Daten nicht mehr entschlüsselbar.
 
In der Bash auf einer Linux-Live-Distri mit dem Kommando 'hdparm'.
 
Faust2011 schrieb:
Hast Du einen groben Wert, wie lange das dauert?
Das dauert eben so lange wie es dauerd die SSD einmal komplett zu überschreiben, wie lange das ist hängt von der jweiligen SSD ab, wie voll sie war etc.
Faust2011 schrieb:
Meine letzter secure erase auf einer SSD (256 GB) hat ca. 5 sec. gedauert.
Damit wird dem Controller ja auch gesagt alle Blöcke zu löschen, was relativ schnell geht.

Faust2011 schrieb:
Das ist halt das coole bei secure erase: da die SSD grundsätzlich immer alle Daten verschlüsselt speichert
Das ist so nicht richtig und hängt auch von der jeweiligen SSD bzw. deren Controller und FW ab, aber nicht alle verschlüsseln die Daten im NAND und ob die die es machen dann wirklich den Schlüssel wechseln und die alten Daten wirklich nicht mehr entschlüsselbar sind, das wird man auch kaum je mit Sicherheit wissen (Stichwort: Backdoor).

Werden mit CLEN ALL alle LBAs überschrieben, kann der Controller die alten Daten schon aus Platzmangel gar nicht alle behalten, allenfalls bleiben irgendwo Rest im der einen oder anderen Page, aber auf die kann auch keiner mehr normal zugreifen, weil der LBA ja nun auf die Page mit den neu geschriebenen Daten gemappt ist.
 
Faust2011 schrieb:
In der Bash auf einer Linux-Live-Distri mit dem Kommando 'hdparm'.

Wenn kompletter TRIM reicht (und normalerweise reicht das), dann einfach 'blkdiscard /dev/totessd'. Dauert ein paar Sekunden und fertig und die Daten sieht man nie wieder.

Es sei denn man traut der Hardware nicht, dann das gute alte 'shred' drüber (ein Durchgang). Zufallsdaten kann die SSD nicht wegkomprimieren, es wird also zwangsweise soviel überschrieben wie geht.
 
Zuletzt bearbeitet:
Holt schrieb:
Das ist so nicht richtig und hängt auch von der jeweiligen SSD bzw. deren Controller und FW ab, aber nicht alle verschlüsseln die Daten im NAND und ob die die es machen dann wirklich den Schlüssel wechseln und die alten Daten wirklich nicht mehr entschlüsselbar sind, das wird man auch kaum je mit Sicherheit wissen (Stichwort: Backdoor).

Oh, stimmt. Da lauert eine Gefahrenquelle. Ich hatte in diesem Szenario nur meinen Käufer der SSD im Blick. Und dass der so einen Aufwand treibt, um an meine (langweiligen) Daten zu kommen, das bezweifle ich... aber Du hast natürlich mit diesem Punkt vollkommen Recht.

Rumo schrieb:
Wenn kompletter TRIM reicht (und normalerweise reicht das), dann einfach 'blkdiscard /dev/totessd'.

Wieder was gelernt. Danke.
 
Wenn Du die SSD irgendjemandem verkaufst und da nicht etwas drauf war was die Schlapphüte interessieren dürfte und was sie anderes nicht abgreifen könnten, etwa weil der Rechner nie im Netz war, dann sollte ein Secure Erease reichen. Aber wenn man all das so hört was die können, bis hin zu Viren für Festplatten-FW, dann wäre es meiner Meinung nach nicht so abwägig ein Secure Erease anzugreifen. Das ist schnell gemacht, wenn man jemandem auf die Pellte rückt und der das merkt, braucht er dafür nicht viel Zeit, weniger als das SEK zum Aufbrechen der Tür und zeiht denen eine lange Nase weil die Beweie weg sind. Da wäre es doch zu schön ihm dann das Gegenteil zu beweisen, wenn er aus dem Koma erwacht ist :D

So ein Secure Erease ist doch ein zu verlockendes Angriffsziel für eine Schwächung der Sicherheit, gerade wenn es vermeindlich nur den Schlüssel für die Verschlüsselung tauscht und der Controller hat dann auch keine Notwendigkeit die Daten wirklich zu löschen, überschreibt man sie aber, so hat er schlicht keinen Platz die alten Daten aufzubewahren, außer er hat eine Datenkompression, aber die haben nur Schrottcontroller und außerdem ahnt er ja nicht, dass das Überschreiben eigentilch ein Löschen ist und ein Angreifer der die Schreibfunktion manipuliert, würde schnell die ganze SSD unbrauchbar machen, dann würde sie verschrottet und ersetzt werden. Löschen durch Überschreiben dürfte damit immer noch der sicherste Weg sein.

blkdiscard ist auch eine Möglichkeit, daran hatte ich gar nicht gedacht. Ob es funktioniert hat, müsste man auch leicht prüfen können. Dazu muss man nur schauen ob die SSD hinterher an beliebigen Stelle nur immer 00 zurückgibt. Schlauerweise liest man vorher aus wo welche Dateien gespeichert waren und schau nach das doch nicht 00 stand, ähnlich dem hier beschriebenen TRIM Test unter Linux:
TRIM wäre gegen Angriffe von Schlapphüten aber vermutlich ähnlich unsicher, aber davon wollen wie mal nicht ausgehen, zumal das für jeden Rechner mit Verbindung zum Internet gilt.
 
Ist der Sinn hinter einem Secure Erase nicht dass die SSD alle Zellen auf Null zurück setzt und damit wieder die OOTB Performance erreicht wird?
Ich meine wenn die SSD nur den Schüssel wegwirft muss der NAND vor dem neuen beschreiben ja immer noch gelöscht werden, was wieder länger dauert und Performance frisst.
 
prüfen ob die gesamte ssd 00 ist: cmp /dev/ssd /dev/zero

sollte liefern: EOF on /dev/ssd
 
@hoobi

Den Schlüssel zu ersetzen geht sehr schnell und stellt sicher, dass die Daten nicht mehr "verständlich" ausgelesen werden können.

Das Löschen der Blöcke kann dann im Hintergrund passieren.


Das Erreichen der OOTB Performance ist nur ein netter Effekt und muss nicht gegen sein.
 
Das mit der OOTB Performance gilt ja vor allem für Sandforce SSDs, die andere verlieren beim normalen Einsatz als Consumer SSDs mit funktionierendem TRIM eingentlich nicht wirklich an Performance.
 
Faust2011 schrieb:
@kuemmelkassel: Danke für die Zusammenfassung. Und das ist dann ebenbürtig zu secure erase?
Ist es nicht, da die Flash-Zellen wegen des Wear-Levelings so nicht gelöscht werden, sondern "clean all" einfach in die noch freien Flash-Zellen schreibt.
 
jtsn schrieb:
sondern "clean all" einfach in die noch freien Flash-Zellen schreibt.
Nein, es werden alle LBAs überschrieben, was zwar auch mehr oder weniger alle freien FlashPages überschreibt, aber je nach Füllstand der SSD den Controller auch zwingt mehr oder weniger alle schon beschriebenen Blöcke zu löschen um überhaupt Platz zu haben, außer der Controller hat eine Datenkompression. Aber selbst da reicht es, denn die LBAs werden ja auch die neuen Daten gemappt und die alten Daten sind durch das Überschrieben der LBAs auf die sie gemappt waren, ungültig und werden vom Controller auch früher oder später gelöscht.
 
Zurück
Oben