Raspberry Pi automatisch Daten sicher löschen?
Hallo,
ich habe öfters mal mit sehr vertraulichen Daten zu tun, deshalb stelle ich mir die Frage, ob man das sichere Löschen nicht mit einem Raspberry Pi automatisieren könnte. Also, dass ich nen USB Stick rein stecke (vielleicht auch noch nen Taster drücke), der dann automatisch sicher gelöscht wird (also so, dass die Daten mehrfach überschrieben werden). Bin in diesem Gebiet leider nicht sehr erfahren, hättet ihr eine Idee, wie ich das umsetzen könnte?
LG
5 Antworten
Das Problem ist, dass der Raspberry Pi nur über SD-Karte gestartet wird, und sie also auch als Festplatte genutzt wird! Bei virtuellen Maschinen kann es auch sein, dass das VMDK VHDD etc. noch nicht "komplett gelöscht" wurde
Das Problem ist, dass der Raspberry Pi nur über SD-Karte gestartet wird, und sie also auch als Festplatte genutzt wird!
So wie ich das verstehe, möchte der Fragesteller einen Raspberry Pi bauen, der ein Laufwerk, das per USB angeschlossen wird, automatisch löscht (überschreibt). Das ist insofern kein Problem, als das die interne SD-Karte des Raspberry Pi nicht betreffen dürfte.
Einen USB-Stick "sicher löschen" ist ohnehin so eine Sache. Die Sticks basieren auf Flashspeicher und arbeiten mit Wear-Levelling. Selbst wenn Du den gesamten logischen Adressraum (den der Host sieht) überschreibst, bedeutet das nicht, dass Du tatsächlich alle physikalischen Zellen beschrieben hast. Der Flash-Speicher ist in der Regel um 7 % "overprovisioned" und wenn die Daten komprimierbar sind, schafft der Controller es eventuell auch, sie in einer noch geringeren Anzahl physikalischer Seiten "unterzubringen".
SSDs unterstützen das ATA Secure Erase Kommando, das (sofern korrekt implementiert) bewirken soll, dass die Zellen tatsächlich physikalisch gelöscht werden. Das Kommando geht im Gegensatz zum Überschreiben auch sehr schnell (wenige Sekunden für eine SSD mit einigen hundert GB Kapazität).
Allerdings vertraue ich bei sensiblen Daten auch nicht mehr auf ATA Secure Erase (und schon gar nicht auf überschreiben des "sichtbaren Adressraums). Der einzige wirkliche Schutz ist meines Erachtens, das Laufwerk zu verschlüsseln, am besten per Software, damit alles, was über den USB- bzw. SATA-Bus läuft, bereits Ciphertext ist. Wenn das Laufwerk "selbstverschlüsselnd" ist, musst Du ihm ja wieder "vertrauen", dass es den Klartext oder den Schlüssel nicht "mitschneidet" und irgendwo ablegt. "Hardware-Verschlüsselung" ist somit auch keine Lösung, wenn man dem Laufwerk "misstraut".
Nein. Flash-Speicher ist leider kompliziert.
Zwei Schreiboperationen auf die selbe Seite ("logische Adresse" = Adresse, die der Host = Computer "sieht") landen im Speicher auf unterschiedlichen physikalischen Speicherzellen. Wenn Du die selbe Adresse "überschreibst", landen die neu geschriebenen Daten daher nicht tatsächlich in den selben physikalischen Speicherzellen (= Transistoren), wie beim ersten Schreibzugriff auf diese Adresse.
Selbst wenn Du den gesamten physikalischen Adressraum überschreiben könntest, so gäbe es weitere Speicherzellen, da Flash-Speicher in der Regel "overprovisioned" ist, d. h. er enthält etwa 7 % mehr Speicher, als "nach außen" sichtbar ist. Dieser Speicher wird zum einen dafür genutzt, um immer "freie" (und somit beschreibbare) Zellen zur Verfügung zu haben. Die Seiten im Flash-Speicher muss man nämlich explizit "löschen", bevor man sie neu beschreiben kann und "löschen" ist ein relativ zeitintensiver Vorgang, weshalb man immer einige "gelöschte Seiten" gewissermaßen "vorhält". Zum anderen dient er auch als "Reserve", falls einige Speicherzellen durch die Fertigung schadhaft sind oder mit der Zeit schadhaft werden und ausfallen.
Daneben wird noch allerlei anderer "Unsinn" gemacht, etwa die Daten komprimiert oder zumindest dedupliziert. Wenn Du eine Nullfolge schreibst, kann der Speicher intern z. B. eine Speicherseite mit einer Nullfolge beschreiben, dann alle logischen Adressen auf diese eine physikalische Adresse umsetzen (die Adressumsetzung muss er ja wegen des Wear-Levellings ohnehin machen) und schon sind (bis auf eine Seite, die aber locker aus dem "Overprovisioning" entstammen kann) noch sämtliche Daten (auf physikalischer Ebene) vorhanden, aber Dein Rechner sieht nur noch Nullen.
Also selbst den gesamten "logischen Adressraum" (den der Host sieht) mit Nullen zu überschreiben bringt noch nicht notwendigerweise Sicherheit, zumindest nicht gegen einen Angreifer, der wirklich unter Umgehung der Host-Schnittstelle "in den Speicher hineinschauen kann". Das sind alles noch Vorgänge, die der Speicher selbst durchführt, treten also auch dann auf, wenn wir wirklich "auf unterster Ebene" einen Schreibbefehl nach dem anderen an den Speicher absetzen. Mit einem Dateisystem fangen wir da erst gar nicht an, das macht alles noch komplizierter (und unzuverlässiger, wenn man sicher löschen will).
Ah ok, das mit dem Wear levelling war mir bekannt (Existenz und Funktionsweise, nicht der Begriff) aber das mit dem Overprovisioning wusste ich nicht. Wieder was dazu gelernt :)
Ich benutze momentan die Verschlüsselung, welche in meiner Samsung 840EVO-SSD eingebaut ist (aus performancegründen, mit biosgesteuerter passwortabfrage) und war von Anfang an etwas skeptisch was die sicherheit angeht... Ich konnte darüber allerdings keine Infos finden, deshalb auch meine Zweifel... Da du ja anscheinend Experte bist, würde ich jetzt einfachmal ganz schamlos fragen, ob du da Informationen bzgl. der Sicherheit hast?
Nein, aber ich habe hier ebenfalls eine Samsung 840 Evo verbaut. Ich werde diese aber ersetzen.
Meine SSD läuft noch auf der alten Firmware-Version, die vom geläufigen "Samsung-Bug" betroffen ist. Die Zellen entladen sich über die Zeit (es gibt keine perfekten Isolatoren) und der Controller frischt sie wohl derzeit nicht auf. Das zeigt sich vor allem in Performanceproblemen beim Lesen, weil der Controller durch die "gedrifteten" Bits die redundante Information zur Fehlerkorrektur nutzen muss. Letztlich ist es aber auch ein Problem bezüglich der Datensicherheit, da Seiten, die lange nicht beschrieben werden, ihren Inhalt irgendwann verlieren werden.
Es ist eine neue Firmware-Version verfügbar, die den Fehler behebt, indem der Controller die Speicherseiten regelmäßig ausliest und den Inhalt zurückschreibt, den Speicher also "auffrischt", wie das auch beim DRAM passiert, nur eben hier mit sehr viel längerer Zykluszeit. Die neue Firmware habe ich aber nie installiert, da sie einen anderen (noch viel schwerwiegenderen) Fehler im Zusammenhang mit dem "Queued TRIM"-Befehl hat.
https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/
Diesen Fehler gibt es wohl auch bei allen Nachfolgemodellen (850 Pro/Evo, etc.) und er kann zu verheerendem Datenverlust führen, weil die SSD anscheinend manchmal "wahllos irgendwelche Speicherseiten löscht".
Den Linux-Kernelentwicklern ist der Fehler bekannt und sie haben Samsung-SSDs für den Befehl explizit "geblacklisted", sodass das Betriebssystem kein "Queued TRIM" mehr an diese SSDs absetzt. (In welchen Kernelversionen dieser Patch bereits enthalten ist, weiß allerdings auch kein Mensch.) Samsung hat aber soweit ich weiß die Firmware bisher nicht korrigiert.
Eine Samsung SSD ist somit letztlich "eine tickende Zeitbombe". Ich warte darauf, dass endlich vorlesungsfrei ist, damit ich die Samsung 840 Evo in meinem System durch eine Intel SSD 730 ersetzen kann. Ich habe zwar ein Backup, aber das Problem ist, wenn wirklich nur einzelne Seiten/Sektoren kaputt gehen, merkst Du das ja nicht notwendigerweise und dann werden eventuell auch mal beschädigte Daten ins Backup übernommen. Das ist ne ganz üble Sache. Deswegen möchte ich die SSD eigentlich so bald wie möglich ersetzen und dann kommt mir auch keine Samsung mehr ins Haus.
Zuvor hatte ich übrigens eine OCZ Vertex 2 verbaut. Die ist mir irgendwann einfach "gestorben" und gab sich als ein Gerät mit kryptischem Namen aus. Das war meine erste SSD. Damals galt das noch als "schwarze Magie", einen nicht rotierenden Festspeicher im Computer zu haben. ;-) Ich habe der Sache auch nie so ganz getraut und hatte immer umfassende Backups auf "richtigen" Festplatten. Wobei mir eine "richtige" Festplatte auch schon ausgefallen ist, das heißt die sind auch nicht "failproof". Hardware geht leider kaputt. Letztlich hilft nur Redundanz, also möglichst viele Kopien auf möglichst unterschiedlichen Datenträgern. ;-) Dann kommt es aber immer noch drauf an, Fehler zu erkennen. Das ist leider nicht so einfach, zumindest sofern es sich nicht um einen "Totalausfall" handelt oder der Defekt das Dateisystem betrifft und das Laufwerk nicht mehr mounten lässt.
Die Sache ist, ich "vertraue meinen Laufwerken nicht" und deshalb kommt auf meinen Systemen Verschlüsselung per LUKS/dm-crypt zum Einsatz. Ja, das belastet die CPU, wenn viel gelesen und geschrieben wird, aber ok.
dd of=/dev/sd1 if=/dev/null bs=1M
das sd1 durch den tatsächlichen namen des sticks ersetzen
mehrfaches überschreiben bringt übrigens GAR nichts (ausser zeitverbrauch)
mehrfaches überschreiben bringt übrigens GAR nichts (ausser zeitverbrauch)
Bei (modernen) Festplatten stimmt das, bei Flash-Speicher kann man es nicht sagen.
Flash-Speicher ist "overprovisioned". Das heißt, er hat "eigentlich" mehr Speicher, als nach außen "sichtbar"/verfügbar ist. Wenn Du ihn einfach überschreibst, hast Du nicht alle Speicherzellen "erwischt".
Selbst wenn Du ihn mehrfach überschreibst, ist es keine Garantie, dass Du damit alle Speicherzellen "erwischt", aber Deine Chancen steigen.
Kommt drauf an, wer deine vertraulichen Dateien nicht bekommen darf. Wenn Regierungen die Dateien auf keinen Fall sehen dürfen, dann hast du ein Problem. Dann könntest du aber immerhin den USB-Stick kaputtmachen, wenn es zum Ernstfall kommt. Wenn nicht gerade IT-Profis deine Daten nicht sehen sollen, dann kannst du auch einfach formatieren.
Warum so kompliziert? Nutze virtuelle Rechner und lösch die bei Bedarf - also wenn die Daten nicht mehr gebraucht werden.
Dafür gibts Tools, die das mit dem Überschreiben erledigen. Ein simples Script mit den nötigen Parametern und es geht mit einem Klick.
Ok, Danke :)
Hättest du mir vielleicht den Namen eines solchen Tools? Ein kleines Script traue ich mir sogar zu ;)
Unter Linux kannst Du ein Blockgerät einfach per dd überschreiben.
dd if=/dev/zero of=/dev/sdX bs=1M
Das /dev/sdX durch den korrekten Gerätenamen ersetzen.
Liest 1 MiB große Blöcke von /dev/zero (eine Datei, die eine unendlich lange Nullfolge enthält) und schreibt sie (sequentiell und blockweise) nach /dev/sdX, bis der gesamte Speicher überschrieben ist.
Wenn es nur darum geht, den kompletten Flash-speicher zu löschen, so kann man doch einfach alles leer machen, und eine mit nullen gefüllte datei schreiben, welche die komplette Kapazität aufbraucht.