Verschlüsselung anstatt Löschung auf SSD?
Hallo,
auf SSDs ist ja wegen Wear Leveling und anderem schwer möglich Dateien sicher zu löschen wie auf einer HDD, da sie ja mitunter mit der Zeit in einem anderen Block gespeichert werden als dem wo sie vorher waren. Wäre eine Möglichkeit die Verschlüsselung der Datei, und diese im Nachhinein zu löschen, oder stellt das keinen Unterschied dar ?
3 Antworten
SSDs (und andere Laufwerke) werden durch den "ATA Secure Erase"-Befehl sicher gelöscht - zumindest wenn die Hersteller diesen Befehl korrekt implementieren.
Den Befehl abzusetzen ist aber nicht so ganz einfach. Mit einem (Live-)Linux und dem Tool "hdparm" ist es möglich. Und Du verlässt Dich natürlich darauf, dass der Hersteller nicht "böse" ist. SSDs (Festplatten übrigens ebenfalls) haben ihre eigene Firmware und könnten zumindest theoretisch durchaus sensible Daten (z. B. kryptographische Schlüssel) "erkennen" und z. B. in einen speziellen Bereich "wegschreiben", an den es kein Herankommen mehr gibt.
Ich selbst betreibe SSDs mit (softwareseitiger) Full-Disk-Encryption, z. B. per VeraCrypt oder LUKS/dm-crypt (und z. B. AES-XTS-512 als Block-Cipher). Bei mir "bekommt das Laufwerk niemals Klartext zu sehen". Die Sicherheit hängt natürlich maßgeblich davon ab, dass der Schlüssel niemals "leaked".
Grundlegend: Wenn die Datei nie unverschlüsselt auf der SSD gespeichert wird /wurde, dann ja, wäre das (verschlüsseln) eine Option.
Und dann kommen Dir die temporären Kopien während der Bearbeitung in die Quere und das ganze war fürn A.... .
(/) ist eigentlich nicht notwendig, es ist eher das eine oder andere in /etc was man vielleicht gerne verschlüsselt hätte, je nach System auch /var (oder Teile davon) - Insofern wird es einfacher, wenn man (/) verschlüsselt.
Ich habe beispielsweise "/home" nicht separat.
Bei ner SSD möchte ich nicht zu viel partitionieren. Ich möchte die Option haben, Pakete zu deinstallieren und dafür mehr Daten abzulegen oder umgekehrt.
Ebenso trenne ich "/var" nicht ab.
"/etc" ist meist klein. Dafür eine separate Partition anzulegen dürfte auch ziemlicher Overhead sein.
Richtig, zumal abgetrenntes /etc beim Booten ätzend ist - insofern ist / einfach praktikabel.
Wenn es im wesentlichen um /home (eigene Partition) geht und /tmp volatil ist, dann kann man auch bei (/) durchaus verzichten.
Andererseits /usr abtrennen, um es unverschlüsselt zu lassen (bei /) ist eigentlich auch praktisch, vor allem bei NVMe-SSDs - nur laut freedesktop/systemd-Truppe, sei das ja schon immer 'broken' gewesen ....
Also mit trim werden die zellen schon ziemlich komplett gelöscht, nicht so wie früher und ausserdem kannste die ssd auch einfach einmal mit müll vollballern das jede zelle beschrieben wurde.
ausserdem kannste die ssd auch einfach einmal mit müll vollballern das jede zelle beschrieben wurde.
SSDs haben physisch mehr Zellen, als nach außen sichtbar ist. Das wird als "Overprovisioning" bezeichnet und macht etwa 7 - 15 % der Nennkapazität aus.
Was in den "ausgemappten" Zellen steht, kannst Du nicht lesen und Du kannst auch nicht beeinflussen, in welche physischen Zellen die SSD schreibt.
Aber zumindest kommt ein Angreifer mit "üblichen Software-Tools" an diese Daten auch nicht mehr heran, da sie über die S-ATA- (oder NVMe-)Schnittstelle nicht "abgreifbar" sind. Man müsste den verbauten Flash-Speicher schon direkt auslesen, um das zu "sehen". Es kommt also gewissermaßen darauf an, vor wem man sich schützen möchte.
Ich würde sagen, von einer einmalig überschriebenen SSD etwas wiederherzustellen ist außerhalb der Reichweite gewöhnlicher Krimineller. Ob man "mehr Sicherheit braucht", muss man selbst wissen. Ich bin bislang immer auf Nummer sicher gegangen.
Das allgemeine Problem ist:
Du weißt nie, ob es nicht Vendor Options für erweiterte Commands gibt, um eben genau den Pool auszulesen - und sei es für Analysen im Zuge der Fertigung etc. .
Ich möchte da an alte IDE HDDs erinnern, deren Jumper-Block bei manchem Hersteller auch ein UART-Interface für den direkten Firmwarezugriff mit an Board hat(te).
Es ist also unklar, ob man wirklich die SSD aufschrauben und auf nen JTAG-Header (o.ä.) gehen muß.
Naja das strapaziert sie ja unnötig, und unter Umständen will ich ja nur eine alte Datei oder einen Ordner sicher löschen, weil er sensible Daten enthält.
also übers strapazieren würd ich mir keine gedanken machen, die dinger halten EWIG...
wollen wa ma gucken wie alt deine ist?
nenne mir das modell und die kapazität
Bei jeder Speicherung/Löschung geht ein Teil der Beschichtung der speziellen MOSFETs verloren. Laut Hersteller kann meine bis zu 300 Terabytes in der Lebenszeit gespeichert ab. Die hat 500GB und auch die Dauer für eine Datei das ganze Ding zuzumüllen finde ich etwas unverhältnismäßig.
Modell ist Western Digital SN520 wenn ich mich nicht irre
Will die nicht loswerden, aber wenn ich mal ne Steuererklärung oder irgendwas anderes wichtiges was ich nicht mehr brauche sicher vernichten will, ohne Speicherplatz zu besetzen, suche ich halt nach ner sicheren Methode. Und ja das ist wahrlich ein nettes Gerät.
Oh nice das wusste ich nicht. Danke. Wie hast du das den herausgefunden ?
Nein habe ich nicht. Da der Laptop ein par Tage alt ist, und das meine erste SSD ist, wollte ich mich nur schonmal wegen Löschverfahren vergewissern. Jetzt mal abgesehen von TRIM. Wäre das von mir oben genannte Verfahren mit Verschlüsselung und Löschung möglich ?
Das weiss ich nicht, ich befasse mich wenig mit dem vernichten von daten, ich speicher sensibles in der cloud... und auf usb
"Im normalen Betrieb" würde ich nicht zu viel Wert auf "sicheres Löschen" legen. Beim Ausrangieren wäre das erforderlich oder wenn Du davon ausgehst, dass das Laufwerk / Gerät gestohlen wird.
Für den Fall würde ich aber zu einer Vollverschlüsselung raten und wenn Du das Laufwerk ausrangieren möchtest, dann "Secure Erase" und ggf. physische Zerstörung.
Ja, nur "full disk encryption" ist wirklich sicher.
Unter Linux kann (muss) man "/boot" (Kernel und initrd) und "/boot/efi" (Bootloader) unverschlüsselt lassen, aber "/" und swap muss man verschlüsseln.