Erstmal willkommen im Forum!
dann werden wegen des internen wear levelings nach dem Verschlüsseln vermutlich noch alte Inhalte unverschlüsselt irgendwo auf der SSD bestehen bleiben und nicht überschrieben worden sein?
Das kann und wird auch passieren, aber da die Daten ja beim Verschlüsseln uberschrieben werden, werden die alten Daten die vorher für diese Adresssen abgelegt werden, dann automatisch ungültig und werden vom Controller irgendwann gelsöcht um wieder Platz zu schaffen. Da fiel geschrieben werden wird, dürfte das eher früher als später passieren, aber auch wenn es später passiert, so kommt man nicht mehr auf normalen Wege an diese Daten, da sie keinem LBA mehr zugeordnet wird und dem alten LBA nun die neuen verschlüsselten Daten zugeordnet wurden. Das Problem ist also in der Praxis keines, weil die alten Daten sehr bald ganz gelöscht sein werden und nir wenn schnelle Eingreiftrupper direkt nach Abschluß der Verschlüsselung klingelt und die SSD sofort zum Fachmann bringt, könnte man vielleicht noch irgendwo irgendwelche Reste finden, aber ich glaube die würden Dich dann eher geschickt überreden denen das Passwort zu nennen
2. Wichtiger: Was ist mit den Daten, die NACH der Verschlüsselung auf der C:-Partition zum Schreiben anfallen?
Die werden von der SW auf der CPU verschüsselt, die SSD kenne die unverschlüsselten Daten also gar nicht und weiß auch nicht, dass da was verschlüsseltes geschrieben wird.
Diese werden vom SSD-Controller auch frei über die Speicherbausteine verteilt, wie ich vermute?
Ja wie immer bei SSDs, daraus ziehen die ja ihre Performance.
D. h. ab dem Moment der Verschlüsselung der Systempartition gelangt nichts unverschlüsselt auf die SSD, was das System oder ich selbst auf C: schreibe?
Nach meinem Kenntnisstand ja, jedendfalls alles was auf die verschlüsselten Partition(en) oder in die Container gespeichert wird.
3. Wenn diese Annahmen richtig sind, könnte ich dann einmalig und vorübergehend den Rest der C:-Kapazität manuell mit Zufallsdaten auffüllen und D: ebenso, sodass die SSD bis auf den kleinen unpartitionierten Bereich quasi voll ist. Dabei müssten doch die vorhandenen "Altdaten" aus der Phase vor der Verschlüsselung dann überschrieben werden, und wenn ich dann alle Zufallsdaten wieder lösche, besteht kein Recovery-Risiko für diese Datenfragmente mehr?
Damit würdest Du nichts überschreiben, denn die alten Daten sind schon durch das Überschreiben während der Verschlüsselung ungültig geworden, die werden auch vom Controller spätestens bei der nächsten Idle-GC, die hat auch jede halbwegs moderne SSD, dann entfernt werden, die Idle-GC dient ja dazu wieder frisch gelöschte NAND Pages für den nächste Schreibvorgang beretizustellen und wozu soll dann ein Controller ungültig gewordenen Daten aufbewahren? Ungültig werden Daten für einen SSD Controllern wenn die LBAs denen die zugeordnet sind überschrieben oder getrimmt werden. Wurde er unpartitionierte Bereich niemals beschrieben, gibt es beim Überschreiben auch keine Daten die dabei ungültig werden.
Also vergiss das mit dem Überschreiben des unpartitionierten Bereiches einfach.
Wenn das so funktioniert, gibt es aber Gründe, das trotzdem nicht so zu tun?
Damit die SSD weiterhin mehr OP hat, würde ich es lassen. Wenn TRIM nicht funktioniert oder nicht getrimmt wird, würden sonst die Daten ewig vom Controler als gültig mitgeschleppt werden müssen.
4. Noch eine Verständnisfrage zum "sicheren Löschen", ... Auf der SSD würde beim Erasen aber das wear leveling zuschlagen und die Nullen im ungünstigen Fall in irgendeinen anderen Speicherbereich schreiben und danach die AVI als gelöscht markieren?
Das wird sogar ganz sicher passieren, da die SSD Controller neue Daten immer nur in leeren NAND Pages angelegen können, gelöscht werden können NANDs aber nur blockweise und ein Block hat locker 256, 512 oder auch 1024 Pages und die können auch gültige Daten von anderen Dateien enthalten, die kann man nicht mal eben löschen, nur weil die Daten einer Page nun überschrieben oder getrimmt wurden, das wäre ja für die Writamplification totaler Wahnsinn.
Aber auch hier gilt, dass die Müllabfuhr, also die Garbage Collection und räumt die Daten bei nächste Gelegenheit weg, die wurden ja durch das Überschreiben ihrer Adressen ungültig und können ab dem Zeitpunkt des Überschreibens auch nicht mehr so normal ausgelesen werden. Den Effekt hat auch TRIM, wenn das funktioniert braucht man bei SSDs nichts mit Ereasern zu überschreiben. Das kannst und solltest Du mit dem Tool
TrimCheck prüfen. Man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten. Wurde TRIM nicht als funktionierend erkannt, kann man es auch erneut laufen lassen und es prüft die Daten noch einmal. TrimCheck muss auf der SSD liegen, wenn es ausgeführt wird, der User muss in dem Verzeichnis Schreibrechte haben und es darf weder verschlüsselt noch komprimiert sein.
Die Daten wären in dem Fall also noch vorhanden und die Nullen nur ZUSÄTZLICH an einer anderen Stelle?
Ja, aber nur bis die Müllabfuhr kommt und auslesbar sind sie auch nur noch, wenn man entweder eine manipulierte FW hat oder die Speicherbausteine ablötet und direkt ausliest. Über normale Befehle zum Auslesen von Adressen kommt man nicht mehr ran und Recovertools wie Testdisk oder GetDataBack werden auch nichts mehr finden.
Das sind doch platteninterne Vorgänge, während die SSD sich nach außen wie eine Festplatte verhält? Heißt dass, dass ein konventionelles Recovery-Programm wie z. B. Recuva, das die Platte nach Datenfragmenten absucht, doch nur die Nullen aus dem vermeintlichen Eraser-Vorgang findet, weil der Controller der SSD dem Programm die Datenbereiche wie bei einer HD präsentiert, aber nicht die Speicherbausteine direkt ausgelesen werden?
Genau das, die Speicherbereiche in denen die eigentlich schon überschriebenen oder getrimmten Daten stehen die noch nicht intern gelöscht wurden, sind nicht mehr normal auslesbar.
Dieses direkte Auslesen der Speicherbausteine habe ich bisher immer nur als teure Dienstleistung spezialisierter Labore gefunden. Existiert hier schon eine spezielle Software, die das auch dem Normaluser ermöglicht?
Die könnte es nur im Zusammenhang mit einer maipulierten FW geben, da die normalen ATA Befehl immer nur über LBAs auf Daten zugreifen können, also nie direkt auf Speicherbereiche des NANDs, die werden intern im Controller eben auf die nach außen sichtbaren LBAs gemappt und ein LBA auch immer wieder auf ganz andere NAND Adressen, das passiert bei jedem Überschreiben oder wenn die Garbage Collection die Daten mal wieder intern umkopiert hat, was aus verschiedenen Gründen passieren kann.
Aber selbst wenn man nun eine FW manipuliert um Speicheradressen direkt auslesen zu können, so muss man auch noch die richtigen Speicheradressen finden und zwar viele richtige Adressen und die auch noch in der richtigen Reihenfolge, denn die LBAs zeigen in der Mappingtabelle nach dem TRIM oder dem Überschreibe ja nun nicht mehr auf die korrekten Speicheradressen. Die stehen vermutlich nur noch in einer Liste von Speicheradressen mit ingültigen Daten, wenn sie noch nicht gelöscht wurden. Bei Micron/Crucial SSD mit Marvell Controller wie der m500 wäre das aber sogar einfach, da die die LBAs auch mit den Daten zusammen in den Pages ablegen. Darauf beruht auch die
Crucial m4 Power Cycle Wiederbelebungsmethode, die auch bei deren Nachfolgern noch funktioniert.
Von anderen SSDs ist mir das aber nicht bekannt.
Dies wäre ja (wenn die übrigen Überlegungen stimmen) dann ein sehr wichtiger Aspekt bei der Beurteilung der zu erwartenden Sicherheitsrisiken durch wear-leveling-Datenfragmente.
Beachte folgendes: Verschlüsselung schützt nur für den Fall, dass der Darenträger physikalisch in die falschen Hände gerät, es schützt aber eben gerade nicht davor ausspioniert zu werden. Das Ausspionieren übernimmt Schadsoftware die vielleicht schon auf Deinem Rechner läuft und sich dann den Schlüssel auch gar nicht merken muss, weil Du den ja jedesmal artig selbst korrekt eingibt um überhaupt selbst an Deine Daten zu kommen!
Bedenke auch: In der Praxis verhindert die Datenverschlüsselung am Ende nur den Zugriff auf die Daten durch genau eine Person: Den Besitzer! Backups sind also doppelt und dreifach anzulegen!
sondern D: als unverschlüsselten Bereich für unkritische Daten weiter nutzen. – Wenn sich die Verschlüsselung dann so verhält, wie oben gemutmaßt, würde mir das reichen.
Keine Sorgen, der unverschlüsselte Bereich stellt ein Risiko für die Verschlüsselten Daten auf der anderen Partition dar, die können darüber nicht ausgelesen werden.
Ich fragte nur hier, weil hier einige das ATA security feature set nutzen.
