We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Sicheres Löschen von Daten auf SSDs

00:00

Formal Metadata

Title
Sicheres Löschen von Daten auf SSDs
Title of Series
Number of Parts
95
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Um Daten auf Festplatten sicher zu löschen gibt es etablierte Programme und Vorgehensweisen. Bei SSDs sieht das gänzlich anders aus: Diese speichern die Daten auf ganz andere Weise und erzeugen im normalen Betrieb eigenständig Kopien. Eine ganze SSD zuverlässig zu löschen ist relativ einfach, selektiv einzelne Daten aus Partitionen oder Dateien sicher zu entfernen ist hingegen schwer. Der Vortrag stellt das Problem und den Unterschied zwischen SSDs und Festplatten vor und präsentiert eine Erweiterung für cryptsetup für Linux, mittels derer das in vielen Geräten vorhandene TPM-Modul genutzt wird um Daten aus einzelnen verschlüsselten Containern von SSDs sicher zu entfernen.
Keywords
22
Thumbnail
54:22
27
29
36
Thumbnail
1:05:58
38
Thumbnail
1:00:58
65
Thumbnail
44:43
75
91
Thumbnail
1:21:58
94
HTTPHTMLHard disk driveWordXMLComputer animationLecture/Conference
Data storage deviceComputer networkPenetrationstestMoment (mathematics)LaufzeitComputer networkPasswordIP addressClefWeb page
LaceOscillationWeb browserWeb pageHard disk driveXMLUML
Hard disk driveLöschen <Datenverarbeitung>Population densityLecture/Conference
Löschen <Datenverarbeitung>Data storage deviceZugriffPasswordHard disk driveZugriffLöschen <Datenverarbeitung>Computer animation
Computer fileHard disk driveElectronic program guideNeumann boundary conditionData storage deviceRandom accessLöschen <Datenverarbeitung>Spatial data infrastructureCoroutineRandom numberUSB <Schnittstelle>Game theoryOscillationSoliDBack-face cullingComputer hardwareRandom numberDeath by burningRandom accessHard disk driveUSB-StickOperating systemDirection (geometry)Component-based software engineeringContinuous trackBlock (periodic table)Enterprise architectureServer (computing)Data storage deviceComputer fileLINUXPAPInstallable File SystemVaporFunction (mathematics)ICQFörderverein International Co-Operative StudiesLöschen <Datenverarbeitung>Data storage devicePartition (number theory)
Löschen <Datenverarbeitung>Hard disk driveInstallable File SystemMetadataBlock (periodic table)FingerprintComputer hardwarePartition (number theory)Hard disk driveSet (mathematics)Computer fileALT <Programm>MetadataLöschen <Datenverarbeitung>Installable File SystemNullEigenvalues and eigenvectorsLecture/ConferenceJSONXMLUML
Hard disk drivePartition (number theory)Partition (number theory)Computer fileBlock (periodic table)Hard disk drivePlatteMetadataInstallable File SystemLöschen <Datenverarbeitung>NullLecture/ConferenceComputer animation
Hard disk driveComputer fileBlock (periodic table)Faster-than-lightTranslation (relic)Flash memoryBlock (periodic table)Direction (geometry)Operating systemComputer fileALT <Programm>Set (mathematics)Löschen <Datenverarbeitung>Installable File SystemInternetdienstNumberFörderverein International Co-Operative StudiesLecture/ConferenceJSONXML
Table (information)Block (periodic table)Set (mathematics)Hard disk driveBackupInstallable File SystemInfinityComputer fileUSB-StickNullBitLecture/Conference
Block (periodic table)Data storage deviceLöschen <Datenverarbeitung>Table (information)Plane (geometry)Computer fileSequenceBlock (periodic table)Hard disk driveSet (mathematics)SpeicherbereinigungComputer animation
WEBUser interfacePACEIntelBlock (periodic table)FlagDifferent (Kate Ryan album)ExpressionMatrix (mathematics)Computer programNetwork socketData structureSet (mathematics)Back-face cullingSoftware developerState of matterData recoveryVaporWINDOWS <Programm>SoftwareCore dumpLecture/ConferenceXML
WEBLöschen <Datenverarbeitung>Reading (process)Block (periodic table)Operating systemBack-face cullingHard disk driveLöschen <Datenverarbeitung>Computer fileOperating systemBlock (periodic table)Partition (number theory)Installable File SystemFirmwareLecture/ConferenceXML
Block (periodic table)Block (periodic table)NullOperating systemInternetSystem administratorInstallable File SystemHard disk driveCalculationContent (media)Computer fileLecture/ConferenceXMLComputer animation
Partition (number theory)Parameter (computer programming)PasswordHard disk drivePasswordPartition (number theory)LINUXPAPParameter (computer programming)Disk read-and-write headDeciphermentMaster KeyComputer fileArray data structureLogarithmSoftware testingLecture/ConferenceProgram flowchart
CalculationWritingBlogPasswordHard disk driveDisk read-and-write headUsabilityBlock (periodic table)Lecture/Conference
Polar coordinate systemPasswordLINUXField extensionPasswordEncryptionLINUXPolar coordinate systemPartition (number theory)PenetrationstestEEPROMClefThermodynamic systemModule (mathematics)Text Encoding InitiativeWINDOWS <Programm>Computer animation
Data storage deviceField extensionPasswordLINUXServer (computing)Master KeyHard disk drivePartition (number theory)DeciphermentLecture/ConferenceJSONXML
Löschen <Datenverarbeitung>EncryptionLINUXHard disk driveData storage devicePasswordPatch (Unix)Lecture/ConferenceComputer animation
Object (grammar)Computer fileHard disk driveProduct (category theory)Systems <München>LimitierungsverfahrenSpur <Datentechnik>Black boxFlash memoryLaptopLecture/ConferenceJSONXML
Hard disk driveMainframe computerBlock (periodic table)Order of magnitudeSpur <Datentechnik>Lecture/Conference
Data storage deviceTwitterLaptopPasswordPlatte
ClefVersion <Informatik>Scientific modellingLöschen <Datenverarbeitung>Flash memoryLaptopBlack boxAlgorithmMicrocontrollerFirmwarePackung <Mathematik>CryptanalysisNullBlock (periodic table)PasswordData storage deviceHard disk driveBit rateLattice (order)USB-StickLecture/Conference
openSUSEWorld Wide WebComputer animation
Transcript: German(auto-generated)
Während die letzten Menschen vielleicht noch einströmen, ein paar Worte zur Einleitung. Auch von meiner Seite herzlich willkommen auf der Frostcon 12 im Jahre 2017. Schön, dass ihr alle hier seid und euch so zahlreich zu früher Zeit zum ersten Vortrag eingefunden habt.
Wenn euch dieser Vortrag gefällt, wovon ich ausgehe, würde ich euch gerne darum bitten, im Anschluss noch den Vortrag zu bewerten, im FRAP, im Vortragsprogramm, ein Feedback zu hinterlassen, was uns hilft bei der Auswahl von Speikern und von dem, was besonders gut geklappt hat.
Wobei ich mir beim nächsten Vortrag sehr sicher bin, dass das ein sehr positives Feedback wird. Wir haben als Thema ein Thema, das sehr aktuell ist. Seit vielen Jahren hat man verschiedene Techniken, um Festplatten zu löschen. Unser nächster Vortragender, der Alex Neumann vom Red Team aus Aachen,
hat sich damit beschäftigt, ob, warum und warum vor allem nicht diese Methoden auf SSDs anwendbar sind. Deshalb würde ich euch bitten, großen Applaus für Alex. Ja, auch von mir einmal Hallo. Schön, dass so viele dann doch zu dieser sehr frühen Stunde hier hingefunden haben.
Heute soll es darum gehen, wie wir für uns eine Methode gefunden haben, datensicher auf SSDs zu löschen und warum das vielleicht gar nicht so einfach ist, wie es im ersten Moment klingt. Ganz kurz ein bisschen was zu uns. Wir führen einen Penetrationstest durch, sind darauf spezialisiert, machen das jetzt schon seit 2004, also eine ganze Weile, also deutlich auch bevor SSDs überhaupt in Laptops angekommen sind.
Penetrationstests sind weltweit unterwegs und wir machen immer, wenn es sich anbietet, auch ein bisschen Forschung im IT-Sicherheitsbereich. Das ist nicht unser Hauptfokus, aber manchmal bietet sich das auch an, je nachdem, was wir in PenTests finden oder was wir selber an Herausforderungen haben, die sich uns stellen. Ja, gerade kurz nochmal, was ist ein Penetrationstest?
Für uns ist ein Penetrationstest ein tatsächlicher Angriff auf ein Produkt oder ein Netzwerk mit dem Ziel, das zu erreichen, was auf keinen Fall passieren darf. Das ist also bei einem Onlineshop oder bei einer Webseite, wo man Waren erwerben kann, sind das so Sachen wie die Benutzerpasswörter, sind das so Sachen wie der SSL Private Key oder so Dinge wie Adressen,
E-Mail-Adressen, Passwörter von Benutzern, Kreditkarten, Nummern. Das sind so Dinge, die wir regelmäßig in einen Penetrationstest zugreifen können. Und diese Daten müssen wir sicher wieder löschen, denn nach so einem PenTest, die sind auf unserem System während der Laufzeit gespeichert, nachher müssen die da wieder weg und das muss sich Kunden auch garantieren können.
Das heißt, wir haben während des Penetrationstests die Herausforderung, dass so Daten anfallen. Manchmal kann man das auch nicht vorhersehen, dass da dann plötzlich eine Webseite auftauchen wird, die Kreditkartennummern enthält, CCV-Nummern enthält, die man eigentlich gar nicht speichern sollte. Und dann liegt das ja wenigstens in meinem Browser-Cache. Das heißt, wir haben schon dafür gesorgt, dass die einzelnen Kunden bzw. Projekte sehr gut voneinander getrennt sind und wir die einzeln löschen können.
Denn Kunden haben auch schon mal Rückfragen. Das heißt, wir löschen jetzt nicht zum Ende eines PenTest komplett alle Daten und schmeißen die weg, sondern haben eine gewisse Zeit, in der wir die Daten auch aufheben und spätestens nach zwei Wochen werden die dann sicher gelöscht. Bisher war das kein Problem mit Festplatten. Da weiß man, da gibt es auch eine Studie dazu. Früher hat man gesagt, man muss Daten auf Festplatten immer mehrfach überschreiben.
Das ist aktuell wohl nicht mehr so. Also ab 80 GB ist dann die Datendichte so hoch, dass man auch mit einmaligem Überschreiben mit sehr hoher Wahrscheinlichkeit nicht mehr wieder herstellen kann. Das hat auch jemand mal ausprobiert vor einer Weile. Das ist auch die Empfehlung des BSI. Das heißt, mit Festplatten kein Problem. Wir hatten vor ein paar Jahren die Herausforderung.
Wir wollten neue Laptops anschaffen, neue Arbeitsgeräte und die ganzen Kollegen. Ich habe mich des Themas angenommen. Die ganzen Kollegen sind zu mir gekommen und haben gesagt, ja, aber SSDs, das wäre doch schon was. Also dann ist alles schneller und schöner und besser und wir können viel effizienter arbeiten. Dann haben wir uns aber mal angeguckt, wie ist das denn mit dem Datenlöschen auf SSDs? Das kann auch eigentlich gar nicht so schwer sein. Zunächst mal noch eine Definition,
was für uns sicheres Löschen bedeutet. Dieser Vorgang ist unwiederbringlich. Das heißt, selbst wenn ich mich jetzt entscheide, ich lösche irgendwelche Daten, ich lösche den Container für ein Projekt und mir morgen jemand eine Waffe an den Kopf hält im Zweifelsfall und sagt, stell das bitte wieder her. Selbst dann soll ich nicht in der Lage sein, das wieder herzustellen. Das ist eine sehr starke Definition von sicherem Löschen.
Das ist aber der Anspruch, den wir an uns selber haben. Das heißt, ich habe da mal so ein Häufchen fotografiert, was aus unserem Schretter normalerweise fällt. Das ist für uns unwiederbringlich. Das wäre vielleicht noch wieder herstellbar, wenn man wahnsinnig viel Aufwand treibt, aber in der Praxis ist das eben nicht zu leisten. Ja, das heißt, unser Angreifermodell,
das ist wieder aus einem Pentest, da definiert man vorher mit dem Kunden zusammen ein Angreifermodell. Wir haben einen Angreifer, der hat physischen Zugriff auf das System und die SSD, der ist sehr gut darin, kennt sich mit Elektronik aus, der hat die Passwörter des Benutzers. Wenn ich das selber bin, mein eigenes Passwort, was ich die zwei Wochen vorher jeden Tag eingegeben habe, das weiß ich noch. Und die Annahme ist, ich lösche irgendetwas
und direkt danach möchte ich selber es wieder herstellen. Das ist so das stärkste Angreifermodell, was uns eingefallen ist, was wir für uns aber auch realistisch finden. So, ja, bei Festplatten. Wie ist das noch? Eine Festplatte, wir haben Blöcke, das sind meist 512 Bytes, so ist das ganze intern organisiert. Wir haben da in irgendeiner Form Partitionen, oder ob man das jetzt mit LVM oder irgendeinem anderen Volume-Manager noch macht,
aber irgendwie sind diese Blöcke der Festplatte in verschiedene Bereiche aufgeteilt. Ich habe da Dateisysteme drin, da sind Dateien drin, die verschiedene Blöcke, je nachdem wie groß sie sind, dann einnehmen, die können auch da liegen. Man sieht halt jetzt zum Beispiel die Datei C, das Gelbe, da sind einfach 6 Blöcke, die irgendwo verteilt sind, die das Dateisystem jetzt dieser Datei zugeordnet hat.
Ja, wenn ich eine ganze Festplatte löschen möchte, das ist relativ einfach. Ich kann im Prinzip, physisches Zerstören ist immer möglich, aber ich kann auch das gesamte Speicher überschreiben, und zwar unter Linux oder BSD mit DD. Ich kann auch die Löschfunktion des Laufwerks verwenden, das nennt sich Arta-Secure-Erase. Unter physisches Zerstören fällt auch so was wie Degaussen, also dass man wirklich die Magnetschichten
einmal komplett durcheinanderwirbelt, damit sind die Daten dann auch weg. Bei SSDs sieht das ein bisschen anders aus. Die haben einen Flash-Speicher, das heißt, da sind vor allen Dingen keine mechanischen und keine magnetischen Komponenten mehr dran beteiligt. Was für Benutzer immer schön ist, das ist eine sehr schnelle Datentransferrate. Man hat wahlfreien Zugriff ohne Latenz, da muss kein Lesekopf erst hin sich bewegen,
sondern man kann da einfach direkt zugreifen. Ein Nachteil ist, dass SSDs, wenn da 120 GB draufstehen, da sind da meistens so 140 ungefähr drin. Wir haben also ein gewisses Overprovisioning, wo die Hersteller in die Geräte mehr Speicher einbauen, als das Gerät nach außen freigibt und das, als man auch als Benutzer von außen überschreiben könnte.
So, erste These, SSDs verhalten sich wie Festplatten. Das geht auch genauso, haben in der Regel die gleichen Anschlüsse. Es gibt SATA-SSDs, die verhalten sich in Richtung Betriebssystem erst mal wie Festplatten. Das kann auch nicht so schwer sein. Gut, gucken wir mal nach. Beim BSI, da gibt es bsi-für-bürger.de. Ich habe bei denen auch angefragt, was man da machen kann, bevor wir so SSDs angeschafft haben. Und im Prinzip sagen die, ja, man kann das löschen,
dann sollte man diese Secure Erase Funktion verwenden und anschließend nochmal mit Zufallszahlen überschreiben. Auf der anderen Seite, unter Sicherheitsürtümer sagen sie aber, dass die SSDs und USB-Sticks sich gar nicht sicher löschen lassen. Das heißt, auch das BSI ist sich nicht so ganz sicher, was es denn da jetzt empfehlen möchte, zumindest für Bürger.
Ja, was hätten wir für Möglichkeiten von den Festplatten? Eben gut physisch zerstören, wenn man das klein genug schreddert und die Speicher-ICs auch klein genug weg sind. Okay, gut, das kann man immer machen. Verbrennen oder Thermit ist auch eine Option. Überschreiben des gesamten Speichers ist schon etwas schwieriger. Ich hab eben gesagt, wenn da 120 GB draufsteht, sind 140 drin. Wenn ich aber 120 überschreibe, was ist denn mit den letzten GB?
Sind die überschrieben, sind die nicht überschrieben? Was ist denn damit? Und je nachdem, welchen SSD-Hersteller man fragt oder ob das eine Consumer oder eine Server Enterprise SSD ist, sind diese Speicherbereiche, die da mehr drin sind, ganz erheblich. Also 25 bis 50 % der angegebenen Speichergröße ist nochmal extra verbaut.
Das machen die Hersteller, damit das Gerät länger hält und damit es schnell sein kann. Gut, bleibt die letzte Möglichkeit. Ich sage dem Gerät selber, bitte lösche dich sicher. Das ist ja nichts anderes. Das hat jemand mal ausprobiert in 2011. Ein Forscher aus der University of San Diego, soweit ich weiß. Er hat das Ganze vorgestellt und hat sich überlegt, okay, wir kaufen jetzt mal einen ganzen Haufen SSDs.
Das ist jetzt schon ein paar Jahre her. Wir schreiben da Daten drauf, wir schreiben jeden Block einzeln. Und zwar so, dass wenn man den Dampf von einem einzelnen Block bekommt, man sicher sagen kann, okay, das war Block 15 und den habe ich um diese Zeit geschrieben. Also ich schreibe so eindeutige Signaturen da rein. Anschließend führen Sie Secure Erase durch, bzw. in dem Paper geht es darum, verschiedene Methoden
von Festplatten auch für SSDs auszuprobieren. Und unter anderem haben Sie Secure Erase probiert. Sie haben auch mehrfaches überschreiben probiert, alles was man so kennt. Haben anschließend die FlashECs direkt ausgelesen, d.h. sie haben die von der Platine der SSD runtergelötet, haben eine eigene Hardware entwickelt und haben die dann direkt ausgelesen, haben anschließend geguckt, wenn ich diese Blöcke, wo ich weiß, wie die aussehen,
wo ich weiß, wie der Fingerprint eines jeden Blocks ist, kann ich die wiederfinden. Und dann haben wir festgestellt, dass das Arteria Secure Erase, zumindest für die SSDs in 2011, die Sie untersucht haben, fehlerhaft implementiert war. Das ist die Hardware. Man sieht da diese beiden schwarzen Blöcke. Das ist eine übliche Bauform für ältere FlashECs TSOP48. Da haben die einfach so Sockel genommen, die kann man auch fertig kaufen.
Kommen wir gleich nochmal kurz drauf und da kann man das direkt auslesen. Das haben Sie damals benutzt. Und das Ergebnis im Prinzip war, Secure Erase kann man zwar machen, aber es gab SSDs, die haben das einfach überhaupt nicht gemacht. Die haben gesagt, ja, Secure Erase, alles prima durchgeführt. Alle Daten sind weg. Die Daten waren aber noch vollständig da. Die haben nachher die SSD wieder angesteckt und konnten das Dateisystem wieder lesen.
Das heißt, so richtig zu dem Zeitpunkt, so richtig konnte man sich da auch nicht drauf verlassen. Das heißt, SSDs verhalten sich wie Festplatten. Ja, ist nicht ganz so. Gut, löschen von Partitionen und Dateien. Nächste These, zumindest Dateien und Partitionen können wir doch genauso löschen, wenn wir jetzt schon das ganze Gerät nicht löschen können. Gut, was hatten wir bei Partitionen und Festplatten? Die sind gut abgegrenzt.
Ich habe da diese Menge von Blöcken. Ich habe da verschiedenfarbige Partitionen. Eine Partition hat meistens ein eigenes Dateisystem. Meistens, da gibt es dann auch wieder Unterschiede. Aber ich kann im Prinzip sagen, ganz genau, welche Blöcke gehören zu welcher Partition und kann hergehen. Und alle diese Blöcke, die zu einer bestimmten Partition gehören, die kann ich am Stück überschreiben, zum Beispiel mit Nullen.
Das hat den charmanten Vorteil, dass auch Datenreste, die ansonsten so übrig bleiben, temporäre Dateien, Metadaten, es gibt ja auch Journaling-Dateisysteme, die zunächst an einen ganz anderen Speicherbereich das ganze schreiben. Das bleibt ja alles liegen. Das ist das, was man üblicherweise so vergisst, wenn man sich sagt, okay, ich habe eine Datei, die muss weg und einfach so ein Truviwipe oder sowas benutzt, was halt nur die Blöcke der Datei überschreibt.
Gut, das heißt also insgesamt eine Partition ist eigentlich so eine ganz gute Einheit, um zu löschende Dateien abzulegen. Mit dem Nachteil, man muss sich das natürlich vorher überlegen. Weil wenn so eine Datei, jetzt irgendein Wörttokument, was man von einem Kunden kriegt, wenn das erst mal auf Laufweg C gelandet ist, dann kriegt man das da halt eigentlich nicht so gut wieder runter. Wie sieht das aus? Ich habe hier nochmal das Bild von eben eingeblendet.
Wenn ich jetzt eine ganze Partition überschreiben möchte, zum Beispiel die blaue, dann gehe ich halt her, wähle diese Blöcke aus. Mein System sagt mir ganz genau, welche dazugehören und kann die einfach überschreiben, jetzt in diesem Fall mit großem X. Dann weiß ich ziemlich sicher, dass diese braun markierten Blöcke da auf jeden Fall weg sind. Wie sieht das mit Dateien aus? Das war jetzt ganze Partition.
Üblicherweise haben Dateisysteme kein Interface, um einzelne Blöcke zu einer Datei zu finden. Das gibt es noch für die aktuellen Blöcke einer Datei, aber nicht für die Blöcke, die eine Datei vielleicht während des Schreibvorgangs früher mal gehabt hat. Wenn man da mit Wim beispielsweise eine Datei editiert, dann legt er auch immer so eine Swap-Datei an. Da ist der gesamte Inhalt sowie der Verlauf eventuell noch mehr mit drin.
Die löscht er dann auch einfach so. Das heißt, nachher findet man die im Dateisystem auch gar nicht. Das heißt, diese temporären Kopien, da weiß ich einfach nichts drüber. Die kann sein, dass die auf der Platte sind, kann sein, dass die nur im Journaling gelandet sind und ich habe sie schnell genug wieder gelöscht, als dass sie gar nicht auf der Platte gelandet sind. Darüber weiß ich einfach gar nichts. Weiterhin habe ich das Problem, dass so Dinge wie Dateinamen meistens in den Metadaten von Fallsystemen abgelegt werden.
Da habe ich bisher noch gar nicht drüber geredet. Wie kann man denn nicht diese Metadatenblöcke, die es ja auch irgendwo gibt, überschreiben? Zusätzlich so Journaling macht es halt insgesamt sehr schwer. Das heißt eigentlich, unser Fazit, das Löschen von Dateien in Partitionen ist so einfach gar nicht möglich, nicht mal auf Festplatten. Denn ich weiß einfach nicht,
welche temporären Daten sind da noch übrig, die ich einfach nicht gesehen habe. Es gibt so ein paar Ideen, dass man anfängt, den freien Speicher der Partitionen dann nochmal zu füllen. Das heißt, ich lösche eine Datei und anschließend schreibe ich große Dateien mit lauter Nullen, sodass hoffentlich der gesamte Speicherplatz der Partition und damit alle Blöcke, die irgendwann mal Teil der Datei gewesen sein könnten, überschrieben sind.
So richtig hundertprozentig ist das aber auch nicht. Und das mögen wir zumindest nicht, wenn es um Kundendaten geht, von denen ich dem Kunde mit gutem Gewissen sagen möchte, die sind gelöscht, die sind wirklich weg. Das heißt, eigentlich kann ich das so nicht so richtig gut machen. Ich habe das hier nochmal aufgemalt. Angenommen, ich möchte Datei C löschen. Dann müsste ich erstmal die Blöcke der Datei überschreiben,
von denen ich das kenne. Dann kann ich die Datei im Dateisystem löschen. Und dann müsste ich den gesamten freien Speicher eigentlich auffüllen um eventuelle Kopien. Man sieht das da ganz unten rechts, da ist noch ein C. Da war vielleicht vorher mal Daten der Datei C drin, dass ich den halt auch mit erwische. Ja, jetzt haben wir SSDs noch ein paar mehr Besonderheiten, als ich eben erwähnt habe. Denn die präsentieren sich in Richtung Betriebssystem
auch wieder als Menge von Blöcken. Jeder Block in dem physischen Flash-Speicher kann aber nur ein einziges Mal geschrieben werden. Und um das Ganze dann wieder zu löschen, um einen Block wieder leer zu machen, kann ich nicht einen einzelnen Block löschen, sondern ich muss die gesamte Seite, so nennt sich das, das ist auch eine Menge von Blöcken, die da physisch zusammen sind, die muss ich im Prinzip Spannung anlegen
und dann ist aber die ganze Seite, also eine Menge von Blöcken, gelöscht. Das nächste Problem ist, dass SSDs sich darum kümmern müssen, dass sie den Flash-Speicher, der da verbaut ist, möglichst gleichmäßig ausnutzen. Denn so Flash-Speicher hat so, aus den EEPROM-Zeiten kenne ich da ein paar Zahlen, man kann so 10 bis 15.000 Mal schreiben, das waren so alte Flash-Speicher ICs.
Das ist aber jetzt für ein Dateisystem wie FAT32, das am Anfang des Geräts seine Tabelle hat, welche Dateien sind vorhanden, wo jedes Mal, wenn ich irgendetwas ändere, diese ersten Blöcke neu geschrieben werden, dann habe ich ein Problem, weil dann gehen diese Blöcke sehr schnell kaputt. Das hat man am Anfang gesehen bei USB-Sticks, die keine besondere Technik dafür hatten, dass diese Blöcke am Anfang speziell behandelt wurden,
sondern diese USB-Sticks sind relativ schnell kaputt gegangen, weil das Dateisystem immer die ersten Blöcke neu geschrieben hat und irgendwann geht das dann los, dass da Bits feststecken, dass man da Bits nicht mehr zu eins machen kann, sondern Nullen feststecken und dann ist das Ganze kaputt. Und SSDs sollen einen ähnlichen Datensicherheitsaspekt haben wie Festplatten, das heißt,
die SSD muss sich selber darum kümmern, ihren Flash-Speicher, den sie zur Verfügung hat, möglichst gleichmäßig auszunutzen. Wie macht sie das? Na ja, sie hat eine Indirektionsebene, nennt sich Flash Translation Layer, FTL, da kommen wir gleich auch nochmal drauf, um im Prinzip dem Benutzer nach außen vorzugaukeln, ich habe hier eine Menge Blöcke Nummer 1 bis 1000, aber intern habe ich erstens viel mehr und zweitens, wo die denn jetzt wirklich liegen,
im physischen Flash-Speicher, das ändert sich immer. Das heißt, wenn ich jetzt so eine SSD habe, man sieht da wieder die Blöcke wie bei der Festplatte, man sieht auch, ich habe jetzt eine Tabelle namens FTL, ich möchte ein großes X in Block Nummer 3 schreiben, dann sucht sich die SSD irgendeinen Flash-Block aus, der gerade jetzt leer ist, das ist also hellgrau gemalt, meint leer, schreibt das X da rein und macht einen Eintrag
in seine FTL-Tabelle, Block Nummer 3 liegt jetzt an dieser Stelle. Das heißt, wenn ich jetzt das rauslesen möchte, würde ich der SSD sagen, lese Block 3, die guckt in der Tabelle nach, liest das aus dem Flash und liefert mir die Daten zurück. Wenn ich jetzt das mache, was man bei SSDs tut, um Dateien zu überschreiben, also ich schreibe ein Y und da rein, sieht man, der hat einen ganz anderen Speicherbereich ausgewählt
und hat einfach diesen Pfeil, diese Indirektionsebene von der Tabelle umgesetzt auf das Y. Man sieht hier auch schön, das X ist weiterhin vorhanden. Wenn ich jetzt Block 3 lese, bekomme ich ein Y, aber das X ist weiterhin da. Genauso, wenn ich noch was reinschreibe, sieht man hier, schattiert dargestellt, diese Blöcke sind quasi beschrieben, also nicht leer, enthalten alte Daten, ich kann aber von außen gar nicht darauf zugreifen,
weil die einzige Methode, die ich habe, ist der SSD zu sagen, lese Block 3 und dann guckt er halt in seiner Tabelle nach und sieht, ok, da muss ich jetzt an eine bestimmte Stelle gehen. Gut, wie ist das, wenn ich jetzt diese Situation habe, ich habe Daten überall geschrieben, die vielleicht nicht verwendet wurden, aber ich habe eine ganze Menge belegte Blöcke, keine freien Blöcke,
nur noch 2 freie Blöcke und soll aber 4 Stück schreiben, A, B, C, D. Dann sieht die SSD, ok, ich habe zu wenig leere Blöcke, ich leere also eine ganze Seite, einen ganzen Bereich, der gerade nicht benutzt wird und kann jetzt da meine Daten reinschreiben. Das ist das übliche Vorgehen, das versucht eine SSD aber so zu machen, dass das nicht passiert, wenn der Benutzer gerade eine Schreibanforderung hat,
denn das Problem ist, das Lehren von so einer Seite dauert relativ lange. Das heißt, die SSD führt intern schon Garbage Collection durch, sie löscht vielleicht, jetzt oben rechts dargestellt, eine weitere Seite, während der Benutzer gerade gar nichts schreibt und organisiert intern ihre Daten um. Das heißt, selbst die SSD hat jetzt Daten verschoben, sie hat sogar Kopien erzeugt, von denen ich als Benutzer von außen überhaupt nichts weiß.
Das heißt, ich weiß nicht, was die SSD tut, ich weiß nicht, wann sie es tut und ich weiß nicht, wie viele Kopien da noch bleiben. So, und das kann man auch noch weiter machen, also die SSD versucht da immer auch noch möglichst viele gleichmäßig aneinander liegende Blöcke leer zu haben, weil da kann sie direkt reinschreiben, das geht schnell, nur das Lehren dauert wie gesagt lange.
So, das heißt, die Folgerungen für SSDs sind, das ist so ungefähr der Forschungsstand, wo ich dann war, wo ich dann erstmal gesagt habe, nur SSDs, ob wir die überhaupt einsetzen können, weiß man nicht so genau. Das heißt, das Überschreiben von Daten funktioniert nicht, das ist das erste Problem. Das nächste Problem ist, die SSDs erzeugen Kopien von Daten und selbst wenn ich überschreiben könnte, selbst wenn ich an
die Stellen schreiben könnte, habe ich immer noch das Problem, dass da viel mehr Speicher drin ist, als ich eigentlich von außen sehe. Das heißt, ich würde auch durch überschreiben nie jetzt wirklich die Daten löschen können. Gut, kleiner Exkurs nochmal als Realitätsabgleich, wie realistisch ist das denn, dass einen Angreifer da tatsächlich, also jemand, wenn ich jetzt selber das wieder herstellen wollte, ich habe eben gesagt,
ich bin eventuell selber der Angreifer, wie realistisch ist denn das, dass ich jetzt aus diesem Flashdaten wieder bekomme? Na ja, wir haben dann mal kurz geguckt bei AliExpress, das ist so eine chinesische Seite, wo man sehr viel Elektronik kaufen kann und hier ist dargestellt für 128 Dollar, bekommt man so einen Programmieradapter für Nandflash, das ist so eine übliche Bauweise für SSDs
für Flashspeicher, da bekommt man auch schon die üblichen TSOP 48 Adapter für diese älteren Flashbausteine direkt mit dabei, das heißt, man kauft sich diesen Adapter, das sieht ungefähr so aus, kann man das Speicher-IC nach dem Auslöten mit so einer Heißluftpistole, kann man den da einfach einspannen, kann den ganz bequem auslesen, da ist auch komplett schon, da kriegt man verschiedene Adapter dabei,
da ist auch schon eine Software dabei, die das für einen macht, das heißt, da braucht man eigentlich nicht, und diese Speicher-ICs haben einen zumindest unter Speicher-IC Herstellern standardisiert das Interface, das heißt, man steckt den da einfach rein, dann sagt die Software, ach gucke mal, da habe ich einen Flash-IC erkannt, das ist die Seitengröße, man sieht das da rechts auf dem Bild so ein bisschen, ich lese das jetzt mal aus, dann habe ich einen Dump der Daten.
Es gibt da auch noch verschiedene andere Adapter, BGA63 ist ein anderer Sockel, der bei kleineren SSDs, also M2 SSDs zum Beispiel, gerne verbaut wird, das gibt es auch fertig, wenn man da noch ein bisschen mehr klickt, dann sieht man auch die Bewerben das explizit mit, es ist eigentlich egal, ob das Speicher-IC schon mal irgendwo eingelötet war oder nicht, wir haben da spezielle Pins, die das auf jeden Fall immer können und schön Kontakt
haben, dass man das auf jeden Fall auch auslesen kann. Das heißt, das reine Auslesen der Daten ist gar nicht so schwierig, da investiere ich, weiß nicht, 200, 250 Dollar, dann habe ich so einen Programmieradapter, habe eine Software dafür, die mir unter Windows zumindest einen direkten Dampf der Daten gibt, habe dann natürlich noch das Problem, das muss man natürlich auch dabei sagen, dass die SSD-Hersteller da eine ganze
Menge auch interne Datenstrukturen auf den SSDs haben, meistens sind die Flash-Seiten, die man so nach außen rausbekommt, sind kleiner als die, die die im Flash-Stand verwenden, weil die da Verwaltungsinformationen ablegen und man muss dann halt noch das reverse engineering, was der SSD-Hersteller dann da für sich gemacht hat. Ich habe auch mal bei SSD-Herstellern angefragt, in dem Fall bei Micron,
die sind sich des Problems bewusst, dass Leute Daten löschen können müssen, sie haben eine Arbeitsgruppe gegründet, in die man aber, wenn man nicht Speicher-Hersteller ist, leider so nicht reinkommt und es gab in den letzten Jahren auch keine Ergebnisse dieser Arbeitsgruppe, die man zumindest so von außen sieht. Das heißt, ja, die haben im Prinzip gesagt, weiß ich nichts darüber. Gut, ansonsten kann man da, da sieht man noch mal den
Programmieradapter, der hat so Pins da unten, da setzt man das Ganze dann rein. Wenn man Angreifer ist, der ein bisschen tiefere Taschen hat, kann man auch einfach einen Datenrettungsunternehmen beauftragen und wir haben auch mal geguckt, was die üblichen Datenrettungsunternehmen so anbieten und in dem Fall ist das jetzt hier Kroll. Die sagen auch, dass sie Daten retten können von fast allen SSD-Herstellern. Das heißt, da ist
zu erwarten, dass es vielleicht eine Kooperation zwischen SSD-Herstellern und den Datenrettungsunternehmen gibt, dass die Dokumentation vielleicht bekommen oder spezielle Firmwares bekommen, mit denen man die Daten da rausbekommt, selbst wenn in dem Flash-Translation-Layer halt noch kein Eintrag mehr da ist. Das heißt, so insgesamt, das ist zwar nicht so einfach, die Daten da wieder rauszubekommen, aber so wahnsinnig schwer und so
ja, Hexenwerk ist das auch nicht wirklich. Wahrscheinlich ist es ein bisschen, das läuft auf ein bisschen Geduld hinaus, die man da haben muss. Gut, das heißt Zwischenfazit, meine These, ja, löschen von Partitionen und Dateien geht genauso, ja, ist auch nicht so wirklich richtig. Dann war ich an dem Punkt, also sind SSDs unsicherer als Festplatten? Ja, schauen wir mal. Es gibt
eine sehr interessante Eigenschaft, ein Kommando nennt sich Trimble, wo das Betriebssystem der SSD mitteilt, der Benutzer hat eine Datei gelöscht, diese Blöcke gehörten zu dieser Datei, die brauche ich jetzt nicht mehr. Das ist das, was man bei Festplatten nicht braucht, weil Festplatten, wenn ich einen Block schreibe und den nachher in meinem Dateisystem nicht mehr verwende, dann ist der Festplatt das einfach egal,
weil der Block bleibt dort bestehen, ich kann da auch weiter Daten rauslesen, in der Forensik wird das sehr gerne benutzt, wenn man da einen PC hat und eine Festplatte hat, um dann aus dem aktuellen Dateisystem nicht benutzten Blöcken die alten Daten wieder rauszukratzen, Carving nennt sich das Ganze, und das ist ein großer Bereich der Forensik, die sich damit beschäftigen, das sieht man auch, wenn man sich mal so Tools anschaut dafür.
Bei einer SSD ist das anders, wenn ich eine SSD vom Betriebssystem her mitteile, der Block wird nicht mehr benötigt, dann kann ich danach die Daten nicht mehr lesen, aktuelle SSDs haben da einen Standard für, der nennt sich Read Zero After Trim, das heißt, sobald ich der SSD einmal mitgeteilt habe, dass der Block nicht mehr benutzt wird, dann liefert die SSD, obwohl sie vielleicht
intern die Daten sogar noch hätte, nur noch Nullen auf Lese-Zugriffe zurück. Die Daten sind zwar immer noch gespeichert, ich habe vom Betriebssystem her aber erstmal keine Möglichkeit da dran zu kommen. In dem Fall weiß ich aber einfach leider nicht, was die SSD damit getan hat. Ich habe ihr gesagt, ich brauche das nicht mehr, sie gibt es mir nicht mehr raus. Was sie damit tut, keine Ahnung. In dem Fall sieht das so aus, wir schreiben
ein X in Block 3, da gibt es wieder so einen Eintrag, das Betriebssystem teilt der SSD mit, es wird nicht mehr benötigt. Ich habe also weiterhin dieses X gespeichert, ich bekomme nur Nullen zurück, aber die Daten sind eventuell noch da. Reicht für uns leider auch nicht, aber das ist so eine besondere Eigenschaft. Die hat einen Vorteil, dass nämlich diese Dinge, die man in der Forensik auf Festplatten
früher gemacht hat, wie eben dieses Carving, also Blöcke lesen, die im Dateisystem nicht verwendet wurden, um alte Daten zu rekonstruieren, das ist deutlich aufwendiger, weil ich erstmal die SSD davon überzeugen muss, im Prinzip genau das, was unser Angreifer vorhin versucht hat, nämlich Flash direkt auslesen eventuell. Vom Betriebssystem her aber komme ich da erstmal so direkt nicht dran, über die Sataschen-Stelle kann ich nur sagen,
lese Block 3, dann bekomme ich halt Nullen zurück, das hilft so einem Forensiker nicht so wirklich. Das betrifft aber auch so Dinge wie Swap-Dateien, Kopien, die Word erzeugt hat, Vim, Swap-Files, die halt auch Inhalt enthalten. Das heißt, wenn ich jetzt mal schaue, was kann so eine Malware, wenn ich jetzt eingedrungen bin in eine Penetrationstest, kann das zum Beispiel auch mit
Metasploit passieren, ich bin Administrator auf einem bestimmten Rechner, wenn der eine SSD hat und dieses Trimmediscard eingeschaltet ist, dann habe ich das Problem, dass ich wirklich nur die aktuellen Daten sehe und nicht alte Daten mehr. Das ist für die Forensik eine Herausforderung, für uns als jemand, der nicht möchte, dass da alte Daten überhaupt lesbar sind, ist das sogar ein Vorteil. Also
SSDs sind unsicherer als Festplatten, ist auch nicht wirklich so der Fall, das ist irgendwie so ein Zwischending. Für uns sind die so sicherheitstechnisch unausgewogen, weil auf der einen Seite habe ich das so Temp-Dateien werden ein bisschen besser, auf der anderen Seite, ich weiß aber nicht, was ist denn mit meinen Daten. Gut, was macht man, wenn man nicht mehr weiter weiß, dann verschlüsselt man, wir verschlüsseln sehr viele Daten, auch alle unsere Daten, die wir
für Kunden in PenTest haben. Mit Festplatten war das auch kein Problem, es gibt unter Linux ein Standard für Festplatten- passwörter, das ist eigentlich ein Passwörter, das nennt sich Lux, der im Prinzip erlaubt mehrere Passwörter zu haben für eine bestimmte Partition oder für einen bestimmten Container. Auf Festplatten ist es kein Problem, ich habe am Anfang der Partition einen Lux-Header, da sind Daten gespeichert,
ein bisschen Krypto, damit man das härter macht, verschiedene Passwörter auszuprobieren. Und im Prinzip brauche ich, um eine Partition zu entschlüsseln, ein Passwort, ich brauche eine Parameter, die da in dem Lux-Header stehen, und ich brauche so Daten aus einem Key-Slot, und damit kann ich einen Master Key entschlüsseln. Wenn ich jetzt eine von diesen beiden jetzt oben stehenden Dingen entsorgen kann, das heißt,
entweder das Passwort oder die Daten aus dem Lux-Header, dann kann ich diese Entschlüsselung nicht machen, egal wie viele Daten da nachher sind. Das ist bei Festplatten wichtig, wenn ich eine 4 TB Festplatte habe und die schnell löschen möchte, dann reicht es mit sehr hoher Wahrscheinlichkeit, dass ich wirklich am Anfang diesen Header überschreibe, und dann kann ich mir sicher sein, wenn dieser Header weg ist, dann kann ich es auf jeden Fall nicht mehr
entschlüsseln, weil ich die entsprechenden Parameter nicht mehr habe, weil ich diesen Key-Slot nicht mehr habe. Das Problem ist, dass auch dieser Header natürlich auf einer SSD gespeichert würde. Wir haben ja eben gelernt, SSDs erzeugen Kopien, machen Garbage-Collection, das heißt, selbst wenn ich mittels Trim der SSD sage, ich möchte jetzt diesen Header am Anfang komplett entsorgen, dann weiß ich ja nicht, wenn ich
die Flashbausteine auslese, dann finde ich 5 Kopien oder sowas. Der Mensch, der das Paper geschrieben hat zu dem Untersuchungen von SSDs mit dem Auslöten, die haben bis zu 15 Kopien eines einzelnen Blogs im Speicher irgendwo gefunden in die SSD, während ihrer kurzen Zeit, die sie zwischen dem Beschreiben und dem Auseinanderbauen noch am Rechner war,
hat die selber erzeugt. Das heißt, es kann auch sein, dass von diesem Header da noch Kopien erzeugt sind, deswegen kann ich mich da nicht richtig drauf verlassen. Unsere Idee war jetzt, was versuchen wir denn, weil wir müssen jetzt irgendwie mal aus diesem Dilemma rauskommen, weil dauerhaft Festplatten einsetzen wäre eine Möglichkeit, ist aber jetzt auch nicht so richtig schön.
SSDs haben ja auch Vorteile in der Usability und alle Kollegen wollten das natürlich auch gerne haben. Deswegen haben wir uns mal angeguckt, können wir vielleicht das Passwort oder Header woanders speichern und sind dann drauf gekommen, dass es viele Laptops und mittlerweile auch fast alle anderen PCs einen TPM-Chip eingebaut haben. Das ist vor 10, 15 Jahren mal in der Open-Source-Community auch sehr verschrien worden, weil es da
Bestrebungen gab, das als sehr geschlossenes System zu bauen. Es stellt sich aber heraus, dass dieser TPM-Chip auch einige Teile hat, die man sehr gut benutzen kann und die es unter Linux auch gut benutzbar sind mittlerweile. Unter anderem gibt es da ein Modul, das nennt sich NV-RAM. Da ist ein bisschen Speicher und das ist wirklich wirklich ein bisschen Speicher für Schlüssel. Das ist so für
Verschlüsselungssachen gedacht wie Windows-Festplattenverschlüsselung, wo dann der Key dort abgelegt wird. Diesen Speicherbrecht kann man auch auf gewisse Weise schützen, dass der nur lesbar ist, wenn ein bestimmter Bootloader da gebootet hat. Das war uns aber alles gar nicht so wichtig. Wichtig war, es gibt dort Speicher, der ist unabhängig von meiner SSD und den kann ich sicher löschen. Das muss man sich als kleines EEPROM
vorstellen und das sind so 2 KB Speicher. Das ist wirklich nicht viel, für uns reicht es aber aus. Man kann den Zugriffsschutz per Passwort versehen, das heißt, wenn ich es hinbekomme auf einem unserer Arbeitslaptops eine andere Linux-Distribution zu booten, da ist dann das Passwort nicht drin. Das heißt, man kann das auch nicht so einfach auslesen. Jetzt war unsere Idee, wir speichern
einfach ein Teilpasswort in diesem TPM-Chip, weil das können wir wegschmeißen. Das heißt, wir setzen Verschlüsselung ein, verschlüsseln einen Container zum Beispiel für einen Penetrationstest und setzen das Passwort aus zwei Teilpasswörtern zusammen, nämlich ein Passwort, was ich als Benutzer eingebe, was lang und sicher ist und ein zweites zufällig generiertes Passwort, was auch nochmal lang genug ist,
um alleine schon sehr sicher zu sein und das speichere ich im TPM-Chip. Das wird bei der Eingabe des Benutzerpassworts automatisch angehängt und insbesondere bekommt der Benutzer dieses Passwort nicht angezeigt. Das hat die weiteren Vorteile, dass wenn ich mal bei einem Kunden bin und jetzt eine Präsentation halte, mein Passwort für diese Daten, die ich für die Präsentation brauche, dort
eingebe und jetzt einen Angreifer eine Kamera montiert hat, die einfach meine Eingaben mitliest und ich anschließend diese Partition lösche und damit auch dieses TPM- Passwort lösche, da kann der Angreifer noch so viel Daten aus meinem Flash auslesen, selbst wenn er mein Passwort hat oder ich mich selber noch dran erinnere, dann kommt er an die Daten nicht ran, weil ihm dieser signifikante Anteil des Passworts aus dem TPM-Chip fehlt.
Das haben wir implementiert als Erweiterung für Krypt Setup für Linux. Sieht dann halt so aus, ich gebe mein Passwort ein, aus dem TPM wird das zweite Passwort, was neu gewählt wird pro Partition, das wird dann da rausgelesen und dann kann ich mit den Daten, die auf der SSD noch gespeichert sind, meinen Master Key entschlüsseln und die Entschlüsselung vornehmen.
Gut, mein Fazit insgesamt für euch heute ist, nehmt mit, SSD sind keine Festplatten, gerade wenn es darum geht, nicht nur schnell Daten zu speichern, sondern diese Daten auch eventuell wieder loszuwerden, seid euch darüber im Klaren, was ist euer Angreifermodell, das ist was anderes, wenn ich einen Arbeitslaptop auf Reisen dabei habe, als wenn ich eine SSD in einem Server habe, aber das betrifft auch so
Bereiche wie Datenschutz zum Beispiel, dass wenn ich Daten von Kunden speichere, Daten von Bewerbern speichere, dann haben diese Leute eventuell einen Anspruch, diese Daten auch korrigiert oder gelöscht zu bekommen, dann muss man halt schauen, wie weit muss das gehen, reicht das, wenn die SSD die Daten nicht mehr rausliefert, und dann muss ich wirklich die aus dem Flash komplett entfernen, das ist wirklich wichtig,
da muss man sich mal Gedanken drüber machen, und viele Leute, ich hab diesen Vortrag jetzt das zweite Mal gehalten, viele Leute sind sich dessen nicht bewusst, dass SSDs einfach ganz anders sind. Gut, SSDs und Festplatten haben große Unterschiede, darüber habe ich euch jetzt eine ganze Weile was erzählt, wenn ich Daten wirklich unwiederbringlich löschen möchte, so nach unserer Definition,
es soll sehr sehr schwer sein, dass die Daten wiederherzustellen, dann ist auf SSDs so erstmal direkt nicht möglich. Es ist aber möglich, wenn man diesen TPM-Chip benutzt, ein zweites Passwort dort ablegt, wir haben das Ganze in CryptSatab integriert, für CryptSatab 1 gibt es einen Patch, den haben wir auf GitHub veröffentlicht, die URL ist da gleich auch noch mit drin, ich lade die Folien nachher auch hoch, da kann man sich das Ganze
anschauen, es gibt für CryptSatab 2 die Idee, und das ist glaube ich jetzt in den letzten Tagen auch schon mal passiert, dass da jemand, die Library, die wir geschrieben haben, da direkt mit integriert, dass man das demnächst auch dann vielleicht aus dem Standard CryptSatab dann hat, dass wir auch immer unser CryptSatab selber patchen müssen, das muss nicht sein. Insgesamt sind damit SSDs deutlich besser geworden, denn ich habe diesen Schutz
von temporären Dateien, ich muss mich nicht so genau darum kümmern, dass ich wirklich alle temporären Objekte wirklich habe, solange es einen Container noch gibt, denn das macht die SSD für mich, die legt die Hürde, bis ich an diese Dateien rankomme, schon mal deutlich höher. Das Problem ist, das werden wir auf Dauer mit Festplatten auch bekommen. Es gab so zwischendurch mal
so Hybridesysteme, SSDs, also erstmal SSDs, werden natürlich immer häufiger eingesetzt. Ich glaube, dass wenige Leute hier im Raum noch ein Laptop haben, wo keine SSD drin verbaut ist, das wird eher die Ausnahme wahrscheinlich sein. Es gab diese Hybridprodukte, die einen kleinen Flash-Speicher kombiniert haben mit einer Festplatte, da weiß man leider gar nicht so viel drüber, weil das alles die Festplatte
als Blackbox auch macht, was da in dem Flash-Speicher passiert. Das Problem ist, Festplatten werden ein ähnliches Problem bekommen. Denn wenn man Festplatten anguckt, die vier Terabyte und größer sind, das sind häufig mittlerweile SMR-Geräte. SMR ist Singled Magnetic Recording, wo im Prinzip die Datenspuren so wahnsinnig eng zusammengelegt werden,
um so eine hohe Datendichte zu erreichen, dass ich nicht eine einzelne Spur löschen kann, weil das die nebenan, die acht Spuren, die nebenan liegen, auch direkt mitlöschen würde. Und da habe ich plötzlich genau die gleiche physische Limitierung wie beim Flash. Ich kann nicht einen einzelnen Block löschen, sondern ich muss eine Seite löschen. Das sind üblicherweise so Größenordnungen zwei bis vier Megabyte, wobei ein Block in der Regel 512 Bytes sind.
Das heißt viel mehr. Und bei Festplatten wird es halt genauso sein, dass die halt auch so, weiß nicht, fünf oder acht oder sechzehn Megabyte am Stück die nebeneinander liegenden Spuren, die kann ich nur am Stück löschen. Ich kann sie nacheinander beschreiben, aber ich habe da ein ähnliches Problem, dass halt alte Daten da drin liegen bleiben. Da ist noch nicht so ganz raus, wie das Ganze funktioniert.
Es gibt da verschiedene Methoden, diese Art von Datenablage zu managen. Zum einen kann das die Festplatte selber machen. Da ist es dann genauso wie bei SSDs. Ich weiß nicht viel drüber. Es gibt Hybridemoli und es gibt auch einen Modus, dass man sagt, das macht der Host. Das heißt, der Host kümmert sich, dass auf diesen speziellen Sektionen immer dann die Daten auch weggeräumt werden oder sowas.
Da hätte man dann ein bisschen Kontrolle darüber. Da habe ich jetzt nicht reingeschaut, aber da wird es prinzipiell ein ähnliches Problem geben. Gut, das war mein Vortrag soweit. Vielen Dank für eure Aufmerksamkeit. Ich habe da unten die Folien verlinkt. Generell gibt es auch einen Stand von uns. Wenn ihr da Fragen habt, da trefft ihr mich auch auf jeden Fall zwischendurch nochmal. Die Folien wird es nachher auch geben.
Wir haben einen Twitter-Account. Habt ihr Fragen?
Die Frage war, was mache ich denn, wenn ich jetzt als Privatbenutzer meinen Laptop verkaufe? Was ist denn die sicherste Methode da, die Daten zu sichern? Wenn ich meinen PC verkaufe, ich würde einfach die Platte nicht mitverkaufen. Im Zweifelsfall eine günstige reinstecken und eine SSD eine günstige neue reinstecken.
Das wäre das sicherste. Wenn man ein ganzes Laufwerk löschen möchte, dann ist das Secure Erase ganz gut für die meisten Fälle. Wenn du das machen würdest wie ich, dann hättest du deine SSD auch verschlüsselt. Das heißt, da bräuchte man dann auch nochmal das Passwort. Aber Secure Erase ist eine gute Methode, um ein ganzes Laufwerk zu löschen. Das ist nur, wenn man jetzt mit so Geräten jeden Tag arbeiten muss
und neue Daten speichert, ist das mit dem Secure Erase so eine Sache. Wenn du es physisch zerstörst, bei einer SSD immer darauf achten, dass man die Flashchips auch mit zerstört, weil sonst die Partikelgröße klein genug ist. Für Privatleute ist das ein größeres Problem.
Das ist aber auch jetzt schon seit 20 Jahren oder so was bekannt. Da hat ein Bekannter von mir angefangen, auf Ebay Festplatten zu kaufen, um mal zu gucken. Teilweise auch im Rahmen eines Kurses an der Uni, um mal zu gucken, was findet man denn auch so Festplatten.
Das heißt, dass Leute Daten löschen, bevor sie Datenträger verkaufen, ist sowieso eher selten. Es gibt aber Linux-Distributionen von einem Live-USB-Stick, die so für Daten löschen gedacht sind, die unter anderem auch Secure Erase machen. Das wird auch beim BSI empfohlen. Das kann man auch für SSDs ganz gut benutzen. Die aktuellen Modelle sollten bei Secure Erase ziemlich die Daten wegräumen.
Das betrifft natürlich dann das gesamte Laufwerk. Und das kann man auch als Privatmensch gut machen.
Die Frage war, was ist denn mit Festplatten, also mit SSDs, die selbst verschlüsselnd sind. Da gibt es einen Standard namens Opal, der mittlerweile in Version 2.0 entstanden ist, wo man im Prinzip der SSD beim booten sagt, das ist mein Key, das ist mein Passwort. Die Frage war jetzt, was ist denn mit solchen Geräten? Reicht das vielleicht auch aus?
Was muss man denn da machen? Das Problem an dieser Art von Sicherheit ist, dass das für Privat vielleicht auch ausreicht. Für uns als jemand, der Daten löschen muss, reicht das nicht aus. Denn man kann nicht sehen, was SSDs damit tatsächlich tun. Verschlüsseln Sie die Daten tatsächlich? Oder ist das vielleicht irgendwie nur ein ich speichere das Passwort in der SSD
und wenn der User das richtige Passwort hat, dann gebe ich ihm halt die Daten sonst eben nicht. Was passiert, wenn man die Sachen löscht? Werden da die Daten gelöscht? Wird da nur der Key gelöscht? Wird vielleicht der Key hinten um einen hochgezählt und dann ist es ein neuer Key? Da weiß man einfach nichts darüber. Das Problem ist, diese ganzen Abläufe in der SSD sind halt von außen eine komplette Blackbox und die Anbieter
ich hab die auch mal gefragt die sagen auch nicht darüber, was sie machen. Das ist deren Geschäftsgeheimnis. Da möchten sie einfach nichts drüber sagen. Was es einfach sehr schwierig macht, das wirklich zu durchschauen und zu beurteilen, kann man das nutzen oder kann man das nicht nutzen. Es ist als Schutzmechanismus alleine nicht geeignet.
Meiner Meinung nach könnte man es auch sein lassen, wenn man jetzt aber wieder auf die Situation kommt, ich möchte privat meinen Laptop verkaufen, dann kann das das sein, was den Käufer davon abhält, meine Daten zu lesen. Ich würde mich nicht darauf verlassen.
Die Frage war, was passiert denn, wenn ich als Privatmensch eine SSD bei Ebay kaufe und die verwende und dann aus irgendwelchen Gründen jemand auf diese SSD draufschaut
und dort strafrechtlich relevantes Material findet, was da vorher drauf war, was aber in dem Fall nicht von dir stammt. Rein aus praktischer Sicht sollte so ein Secure Erase da ausreichend sein. Die Methode, wie das wahrscheinlich implementiert sein wird, ist, dass einmal der gesamte Flash-Speicher quasi geleert wird. Das reicht in der Regel aus.
Es gab da mal Forschung, dass man aus gelöschten Flash-Zellen Dinge wieder herstellen kann. Das würde ich aber mal auf deutlich mehr als Standardforensik schieben. Das ist nicht so einfach möglich. Das heißt, eine Secure Erase durchführen, dann bekommt man das da mit hoher Wahrscheinlichkeit so nicht mehr wieder raus. Das ist halt das Problem. Man kann sich nicht darauf verlassen für den Hausgebrauch und was die Usability angeht.
Wenn man dann eine SSD von außen fragt, was für Daten hast du denn in Block 3 gespeichert, dann wird die mit Sicherheit sagen, da sind Nullen drin. Da müsste man wirklich schon den Weg gehen, dass man das auslötet und alles dann noch mal einzeln findet.
Angriffer nicken mir das weg, nachdem ich das gerade geschrieben habe und versucht habe, meine Daten rauszufinden. Für den Fall wäre mit jeder weiteren Benutzung würde ich steigern die Wahrscheinlichkeit, dass ich zusammenhängende Daten überhaupt finden kann. Genau, der Einwurf war, wenn du die SSD natürlich benutzt, irgendwann speicherst du Daten drauf, die organisiert sich um, die wird
auch Daten wieder löschen. Darauf kann man sich nicht verlassen. Das heißt aber, selbst wenn du eine SSD von Ebay kaufst, die jetzt keinen Secure Erase durchführt, mit der Zeit sinkt die Wahrscheinlichkeit sehr stark ab, dass man da überhaupt noch Daten rekonstruieren kann, weil irgendwann wird die SSD an allen Speicherblöcken mal vorbeigekommen sein, weil sie versucht ja auch den Speicher sehr gleichmäßig zu verwenden. Das heißt,
irgendwann wird das auch mit der Zeit dann weg sein.
Können wir vielleicht gleich nach dem Vortrag nochmal darüber sprechen. Der Einwand war im Prinzip,
wenn man mehrere SSDs hat, dann kann man auch versuchen, die zu beobachten, wie sie reagieren nach einem Secure Erase, versus wie sie reagieren, wenn man sie aus der Packung nimmt, und dann versuchen, darüber abzuleiten, was die SSDs intern tun. Okay, also ernst gemacht. Wenn du dann nachher kommst einfach nochmal vorbei, dann können wir da nochmal drüber sprechen.
Gibt es noch weitere Fragen? Ja, ansonsten wie gesagt, ich laufe hier auf der Konferenz auch noch rum, meine Kollegen sind am Stand, wenn euch das interessiert.
Ja, die Frage war, was ist denn, hat dir vielleicht schon mal jemand die SSD-Firmware modifiziert, um da dann einfach die Flashblöcke so am Stück auszulesen? Ich weiß von keiner Forschung, ich weiß, dass das jemand mal gemacht hat, auf dem holländischen Hackercamp von vor vier Jahren, mit Festplatten, da war ein Arm Mikrocontroller drauf,
da gab es eine extra Firmware. Ich persönlich gehe davon aus, dass SSD-Hersteller solche Firmwares bereits haben, und dass es eventuell auch die weitergegeben wurden an so Daten-Rettungsunternehmen, weil die natürlich daran interessiert sind, möglichst die Daten so zu haben. Im Prinzip ist da auch nur ein Mikrocontroller drauf, ich halte es für, also ich vermute mal, dass da sehr viel Engineering-Zeit reingeflossen ist,
diese Algorithmen zu bauen, für den SSD-Hersteller, dass der seinen Flash-Speicher möglichst gut ausliest. Da gibt es noch so Sachen, wenn man Daten abspeichert, dass sie teilweise das auch aufteilen auf zwei verschiedene Flash-ICs, dass es so Striping ist, um da die Datenrate nochmal zu erhöhen. Das wäre auf jeden Fall mal interessant, das mal zu reverse-ingenieren und mal zu gucken, ob man das bekommt und vor allen Dingen dann die Blöcke auslesen kann,
ohne die SSD zu zerstören. Das wäre so, was ich mal sehr interessant fände. Hat meines Wissens noch niemand gemacht. Wenn euch das prinzipiell Spaß macht, wir suchen auch neue Mitarbeiter. Vielen Dank fürs Zuhören.