USB-Stick vor dem Verkauf oder Entsorgung

Ausgangslage

Bei modernen SSDs ist sicheres Löschen kein Problem mehr. Ein ATA Secure Erase oder bei Self-Encrypting-Drives (SEDs) ein Crypto-Erase, und die Sache ist in Sekunden erledigt – der Controller wirft entweder die komplette FTL-Tabelle weg oder schmeisst den Verschlüsselungskey über Bord. Sauber, schnell, zuverlässig, auch für Zellen, die dem Host durch Wear-Leveling und Overprovisioning gar nie sichtbar waren.

Die Frage, die sich daraus ergab: Geht das bei einem gewöhnlichen USB-Stick genauso?

Problem

Kurz nachgedacht, und die Antwort war klar: nein, nicht in der gleichen Form. Der Grund liegt nicht im fehlenden Tool, sondern in der Architektur selber.

Ein USB-Stick spricht schlicht kein Protokoll, das einen Secure-Erase- oder Crypto-Erase-Befehl kennt. Der Controller exponiert dem Host nur ein logisches Blockgerät. Was darunter liegt – die physische NAND-Adressierung, Wear-Leveling, Spare-Bereiche fürs Overprovisioning, ausgemusterte Bad-Blocks – bleibt für den Host komplett unsichtbar und wird ausschliesslich von der internen Controller-Firmware verwaltet.

Also getestet, was pragmatisch möglich ist:

shred /dev/sdX -v -n 0 -z

Null Random-Pässe, nur ein finaler Zero-Pass, mit Fortschrittsanzeige. Effektiv dasselbe wie ein simples dd if=/dev/zero of=/dev/sdX. Die klassischen mehrfachen Random-Pässe (-n 3 oder mehr, Stichwort Gutmann-Methode) stammen aus der Magnetplatten-Ära, wo es um Restmagnetisierung ging. Bei NAND-Flash ist eine Zelle nach dem Überschreiben einfach überschrieben – mehr Passes bringen keinen zusätzlichen Sicherheitsgewinn.

Damit ist aber nur der logische Adressraum abgedeckt, den der Controller über die Flash Translation Layer (FTL) anbietet. Nicht erreicht werden:

• bereits als defekt markierte und ausgemusterte Blöcke
• Spare- respektive Overprovisioning-Bereiche, die der Controller fürs Wear-Leveling zurückhält
• alte physische Kopien von Daten, die durch Wear-Leveling an einen neuen Ort verschoben wurden, bevor der aktuelle logische Sektor neu gemappt worden ist

Die logische Anschlussfrage: Gibt es einen Befehl, um direkt auf alle physischen Zellen zuzugreifen? Auch hier: nein. Und zwar nicht, weil das Tooling fehlt, sondern weil das USB-Mass-Storage- respektive SCSI-Protokoll gar keine Kommandos dafür vorsieht. Der einzige Weg an die physischen Zellen führt über Chip-Off-Forensik – den NAND-Chip von der Platine löten und mit einem dedizierten Hardware-Programmer direkt auslesen. Das ist Forensik-Terrain, kein Software-Befehl.

Auflösung

Für den Alltag heisst das: Ein einzelner Zero-Pass via shred -n 0 -z oder dd ist software-seitig das Maximum, was auf einem gewöhnlichen Stick machbar ist. Für die allermeisten Anwendungsfälle ist das auch völlig ausreichend.

Zwei Ausnahmen, bei denen echtes Crypto-Erase trotzdem möglich ist:

• Hardware-verschlüsselte Sticks (z.B. Kingston IronKey, Apricorn Aegis): Ein PIN-Reset respektive eine Reinitialisierung setzt den AES-Key zurück – das ist dann tatsächlich SSD-artig sicher und sofort erledigt.
• USB-Gehäuse mit echter SSD/NVMe drin, sofern UASP und ATA-Passthrough unterstützt werden: Da lässt sich teilweise mit hdparm --security-erase oder nvme-cli durchgreifen. Keine Garantie, hängt vom Bridge-Chip im Gehäuse ab.

Für alles andere – Daten dürfen unter keinen Umständen rekonstruierbar sein – bleibt am Ende nur die physische Zerstörung des Sticks. Dem Controller ist schlicht nicht zu trauen, dass er jede physische Zelle wirklich preisgibt.

Eine Überlegung, die sich daraus ergibt: Wenn ein Stick sowieso schon länger im Einsatz ist und irgendwann verkauft oder weitergegeben werden soll, lohnt sich Vorsorge. Statt erst am Schluss vor dem Problem „wie krieg ich das jetzt wirklich sauber weg“ zu stehen, den Stick gleich zu Beginn der Nutzung software-seitig verschlüsseln, z.B. mit LUKS unter Linux oder VeraCrypt plattformübergreifend. Beim späteren Verkauf reicht dann ein einfacher Crypto-Erase im Kleinformat: den LUKS-Header überschreiben respektive den Container-Key verwerfen, und die Daten sind ohne Schlüssel nicht mehr rekonstruierbar – unabhängig davon, ob der Zero-Pass wirklich jede physische Zelle erreicht hat oder nicht. Der zusätzliche Zero-Pass danach ist dann nur noch Kosmetik, kein Sicherheitsfaktor mehr.

Der Haken: Das funktioniert nur, wenn die Verschlüsselung von Anfang an aktiv war. Nachträglich auf einen bereits benutzten, unverschlüsselten Stick eine Verschlüsselung draufzusetzen, hilft nichts – die alten unverschlüsselten Daten liegen ja weiterhin unverschlüsselt in irgendwelchen physischen Zellen, an die man ohnehin nicht rankommt.

Lessons Learned

• SSD-Methoden (Secure Erase, Crypto-Erase) lassen sich nicht 1:1 auf USB-Sticks übertragen, weil das Protokoll die entsprechenden Befehle gar nicht kennt.
• Mehrfache Random-Pässe vor dem Überschreiben sind bei Flash-Speicher unnötig, das ist ein Relikt aus der HDD-Zeit.
• TRIM wird von vielen Sticks nicht oder nur unzuverlässig unterstützt, ein Overwrite hat also keine Garantie, wirklich jede physische Zelle zu erreichen.
• Ein einzelner Zero-Pass ist für die meisten Zwecke pragmatisch ausreichend, aber nicht forensisch beweisbar sauber.
• Wirklich hohe Anforderungen an Datenlöschung erfüllt bei einem Stick ohne Crypto-Erase nur physische Zerstörung.
• Wer einen Stick von Anfang an mit LUKS oder VeraCrypt verschlüsselt, hat sich beim späteren Verkauf ein echtes Crypto-Erase erkauft – nachträglich funktioniert das nicht mehr.

Fazit

SSDs haben mit Secure Erase und Crypto-Erase einen sauberen, protokollseitig definierten Weg, Daten zuverlässig loszuwerden. USB-Sticks haben das nicht, weil ihnen schlicht das nötige Kommando-Set fehlt und der Controller die physische Ebene komplett vor dem Host versteckt. Für den Alltag reicht ein einzelner Zero-Pass völlig. Wer aber wirklich sichergehen will, dass nichts rekonstruierbar bleibt, kommt um Zerstörung des Sticks nicht herum – ausser der Stick bringt von Haus aus Hardware-Verschlüsselung mit.