Ich gebe zu: Der Komfort von Fingerabdrucksensoren ist verlockend. Ein kurzer Druck auf den Sensor, schon ist das Handy per Fingerabdruck entsperrt. Kein Herumtippen auf dem Display, keine PIN, kein Muster. Gerade wenn man viel unterwegs ist, macht das den Alltag einfacher. Aber dieser Komfort hat seinen Preis und der wird nach einem aktuellen Urteil des Bundesgerichtshofs (BGH) deutlicher denn je.
Finger drauf – Tür auf: Was das BGH entschieden hat
Der BGH in einem gerade veröffentlichtem Urteil hat klargestellt: Ermittlungsbehörden dürfen Beschuldigte zwingen, ihr Smartphone per Fingerabdruck oder Gesichtserkennung zu entsperren. Die sogenannte Selbstbelastungsfreiheit (auch bekannt als nemo tenetur) greift dabei nicht – denn biometrische Entsperrung gilt juristisch als passiv. Solange ich also nicht aktiv eine PIN mitteile, ist der Zwang rechtlich zulässig.
Das Urteil (Az. 2 StR 232/24) findet sich hier im Volltext und ist in seiner juristischen Tragweite ziemlich deutlich: Der Staat darf bei entsprechender Verdachtslage biometrische Entsperrmethoden gegen den Willen der Betroffenen nutzen. Die Hürde liegt damit nicht mehr in der technischen Umsetzbarkeit, sondern nur noch in der rechtlichen Begründung durch die Ermittler.
Warum uns das alle betrifft – nicht nur Kriminelle
Natürlich wird niemand gezwungen, biometrische Sperren zu verwenden. Aber genau das ist der Punkt: Viele von uns tun es freiwillig, oft ohne zu wissen, was das im Ernstfall bedeutet. Wer glaubt, dass Datenschutz nur für „die mit was zu verbergen“ gilt, hat das Prinzip nicht verstanden. Es geht um Selbstbestimmung. Darum, wer Zugriff auf unsere privaten Daten hat – und unter welchen Bedingungen.
Unsere Smartphones enthalten weit mehr als nur Telefonnummern, Chats und Urlaubsfotos. Kalender, Standortverläufe, 2FA-Apps, Banking, Trading, Passwortmanager und vieles mehr. Wer Zugriff auf ein entsperrtes Gerät hat, kann in kürzester Zeit tiefe Einblicke in unser digitales Leben gewinnen. Umso wichtiger ist es, bewusst zu entscheiden, wie wir unsere täglich mit uns herumgetragenen Geräte schützen.
Apple iPhones und Android-Handys lassen sich bei Bedarf sehr schnell so sperren, dass biometrische Verfahren wie Fingerabdruck oder Gesichtserkennung nicht mehr funktionieren.
Biometrischen Entsperren temporär deaktivieren
Zum Glück bieten moderne Smartphones und Tablets mit Android oder iOS mittlerweile direkte Wege, biometrische Entsperrung wie eben den Fingerabdruck mit einem oder wenigen Knopfdrücken auszuschalten, ohne die Biometrie komplett zu deaktivieren. Das kann in Situationen wichtig sein, in denen ihr kurz davor steht, euer Gerät aus der Hand zu geben. Etwa bei einer Kontrolle oder Durchsuchung.
Android (Google, Samsung und Co.)
Allgemein (meiste Geräte): Ein/Aus-Taste lange gedrückt halten » Sperren
Google Pixel: Ein/Aus-Taste + Lauter gleichzeitig » Sperren
Damit wird die aktuelle Sitzung gesperrt und biometrische Entsperrung per Fingerabdruck oder Gesichtserkennung ist deaktiviert. Eine PIN oder ein Passwort ist danach zum Entsperren des Geräts zwingend erforderlich. Auch ein Neustart würde in diesem Fall nicht weiterhelfen, da sich das Gerät danach sowieso nur per Pin aufsperren ließe.
Hinweis: Wer möchte, kann das Verhalten der Powertaste in den Einstellungen von Android anpassen: Einstellungen » System » Touch-Gesten & Bewegungen » Ein-/Aus-Taste gedrückt halten » Ein-/Aus-Menü
Apple (iPhone, iPad, iOS)
5x schnell die Seitentaste drücken » biometrische Entsperrung wird deaktiviert (auch bekannt als Lockdown Mode)
Seit iOS 18.4 gibt es außerdem ein interessantes Detail: Wird das iPhone drei Tage lang nicht benutzt, startet es automatisch neu und wechselt in den sogenannten BFU-Modus („Before First Unlock“). Selbst professionelle Forensiklösungen wie Cellebrite haben dann (zumindest laut ihrer eigenen Aussage nach) Probleme, an die Daten zu kommen. Solange die PIN eben nicht bekannt ist.
Konsequenz: Komfort oder Kontrolle – ihr entscheidet
Ich will niemandem vorschreiben, wie ihr eure Geräte absichert. Aber ich finde es wichtig, die Folgen zu kennen. Biometrie ist bequem, aber eben auch angreifbar, gerade aus juristischer Sicht. Wer sich auf den Schutz durch Fingerabdruck oder Gesichtserkennung verlässt, sollte sich bewusst sein, dass dieser Schutz in bestimmten Situationen keinen Bestand hat. Die einfache Alternative: PIN oder Passwort und im Zweifel schnell auf den Sperren-Knopf. Damit behaltet ihr die Kontrolle darüber, wann euer Gerät entsperrt wird und vor allem, durch wen.
Über die Jahre haben sich bei mir hier unzählige USB-Sticks und SD-Speicherkarten angesammelt. Oft stammen diese nicht von Markenherstellern, sondern aus der Ramschkiste von Werbematerialprovidern — Pressekonferenzen und Produktpräsentationen sei Dank. In der Praxis merke ich jedoch, dass es durchaus einen Unterschied macht, ob ein Speicherstick von Sandisk, Samsung und einem anderen renommierten Hersteller stammt oder ob das Werbematerial aus irgendeiner asiatischen Hinterhofbude zusammengeschustert wurde. Und dabei rede ich nicht einmal von Fälschungen, die mehr Kapazität vortäuschen, sondern einfach nur von schlechter Qualität und Schreib-/Lesefehlern.
Ich hatte in der letzten Zeit häufig das Problem, dass sich diese miesen Sticks immer oben im Stapel ansammelten und somit beim Griff in die Grabbelkiste immer als erste in meiner Hand lagen. Spätestens beim Schreiben größerer Datenmengen, etwa eines ISO-Images einer Linux-Distribution, kommt es dann zu Problemen. Die Schreib-/Leserate bricht ein oder es gibt gleich aussagekräftigere IO-Fehler. Um diese Problematik auszuschließen, möchte ich also alle meine USB-Sticks und SD-Speicherkarten einmal auf Fehler überprüfen und defekte Datenträger für immer aussortieren. Unter Linux geht das mit Bordmitteln.
USB-Sticks auf Fehler prüfen
Im ersten Schritt müsst ihr die Geräte-ID des USB-Sticks oder der Speicherkarte herausfinden. Steckt den Datenträger daher an den Rechner an oder legt die SD-Karte in das entsprechende Lesegerät und gebt im Terminal lsblk ein. Das Kommando listet euch sämtliche am Rechner angeschlossene Datenträger auf. Anhand der Größe des Datenträgers lässt sich in der Regel die Geräte-ID erkennen. In meinem Beispiel bindet das System meinen 8 GByte großen USB-Stick unter sdc (also /dev/sdc in der vollständigen Syntax) ein. Seid ihr euch nicht sicher, dann zieht den zu kontrollierenden Datenträger ab und wiederholt lsblk. Fehlt sdc in der ausgegebenen Liste, dann habt ihr die richtige Kennung. Alternativ lässt sich die Kennung auch mit grafischen Tools wie der Laufwerksverwaltung von Gnome ermitteln.
$ lsblk
[...]
sdc 8:32 1 7,5G 0 disk
├─sdc1 8:33 1 2,9G 0 part /run/media/toff/Ubuntu 21.10 amd64
├─sdc2 8:34 1 4,1M 0 part
└─sdc3 8:35 1 300K 0 part
[...]
Auch die in Gnome integrierte Laufwerksverwaltung zeigt die Geräte-IDs von Festplatten, SSDs, USB-Sticks und anderen in das System eingebundenen Datenträgern an.
Für die eigentliche Fehlersuche kommt nun das Kommando badblocks aus dem Paket e2fsprogs zum Einsatz, das zur Grundausstattung der üblichen Distributionen gehört. Es kann vorkommen, dass sich Badblocks erst einmal weigert, die Überprüfung zu starten, da das Laufwerk bereits vom System benutzt sei. In der Regel kommt das davon, dass das Betriebssystem den Datenträger automatisch einbindet, sobald ihr den USB-Stick ansteckt. Auf meinem System genügt das Antippen des Icons zum Aushängen des Laufwerks im Dateimanager nicht, ich muss die Geräte-ID des Laufwerks und der dazugehörigen Partitionen gezielt mit umount aushängen.
$ sudo badblocks -wsv /dev/sdc
/dev/sdc wird offensichtlich vom System genutzt; es ist zu unsicher, Badblocks zu starten!
$ sudo umount /dev/sdc*
umount: /dev/sdc: nicht eingehängt.
umount: /dev/sdc2: nicht eingehängt.
umount: /dev/sdc3: nicht eingehängt.
An dieser Stelle muss ich eine Warnung schreiben: Beim Prüfen auf Fehler überschreibt Badblocks sämtliche Daten und Partitionen auf dem angegebenen Datenträger. Stellt daher auf jeden Fall sicher, dass ihr die richtige Geräte-ID an das Kommando übergibt und sichert vor der Aktion wichtige Daten vom betroffenen USB-Stick oder der SD-Speicherkarte. Im Fall der Fälle könnt die Daten nach der Fehlerüberprüfung nicht wiederherstellen.
Beim Aufruf von Badblocks übergebt ihr dem Kommando die Parameter -wsv sowie die Geräte-ID. Die Parameter weisen das Programm an, einen destruktiven Schreibtest auszuführen (-w), den Fortschritt anzuzeigen (-s) und generell mehr Informationen auszugeben (-v). Der ausführliche Test beschreibt jeden Block des Datenträgers viermal hintereinander mit unterschiedlichen Mustern (0xaa, 0x55, 0xff und 0x00). Je nach Geschwindigkeit und Kapazität müsst ihr dafür eine längere Zeit einplanen. Die Prüfung des von mir im Beispiel benutzten USB-Sticks nach dem USB-2.0-Standard und 8 GByte Kapazität benötigte über eine Stunde.
$ sudo badblocks -wsv /dev/sdc
Es wird getestet Mit Muster 0xaa: 0.00% erledigt, 0:00 verstrichen. (0/0/0 Fehler) erledigt
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x55: 0.00% erledigt, 23:47 verstrichen. (0/0/0 Fehler) erledigt
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0xff: 0.00% erledigt, 47:33 verstrichen. (0/0/0 Fehler) erledigt
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x00: 0.00% erledigt, 1:11:26 verstrichen. (0/0/0 Fehler) erledigt
Lesen und Vergleichen:erledigt
Neben der destruktiven Prüfmethode unterstützt Badblocks einen zerstörungsfreien Lesen+Schreiben-Modus. Diesen aktiviert ihr mit dem Parameter -n anstatt von -w. In dieser Variante sichert Badblocks die Daten des geprüften Speicherblocks zuerst in den Arbeitsspeicher, überschreibt dann den Datenblock mit Zufallsdaten und prüft, ob die Daten korrekt geschrieben werden konnten. Abschließend schreibt Badblocks die Sicherung wieder auf den Datenträger zurück. Auf den ersten Blick erscheint die Prüfroutine schneller, da es nur einen Prüfdurchlauf gibt, in der Praxis brauch das Sichern und Zurückschreiben der bestehenden Daten allerdings wesentlich mehr Zeit. In meinem Beispiel anstatt nur etwas mehr als einer Stunde über 2,5 Stunden.
$ sudo badblocks -nsv /dev/sdc
Es wird nach defekten Blöcken im zerstörungsfreien Lesen+Schreiben-Modus gesucht
Von Block 0 bis 7812607
Es wird nach defekten Blöcken gesucht (zerstörungsfreier Lesen+Schreiben-Modus)
Es wird mit zufälligen Mustern getestet: 94.36% erledigt, 2:35:18 verstrichen. (0/0/0 Fehler)
Gefälschte USB-Sticks ermitteln
Einen Schritt weiter geht das Tool F3 oder etwas länger Fight Flash Fraud. Das Open-Source-Programm prüft ausführlich, ob ein Datenträger wirklich die Kapazität besitzt, die er vorgibt zu haben. Ein Thema, das leider immer noch aktuell ist, besonders wenn man super günstige Angebote aus dem Internet kauft. Um gefälschte USB-Sticks oder SD-Speicherkarten aufzudecken, müsst ihr das Programm aus dem Paketquellen installieren. Debian, Ubuntu, Fedora und Co. führen das Konsolenwerkzeug in den offiziellen Repositories, das Paket nennt sich in der Regel f3. Arch Linux führt das Programm nur im AUR, zur Installation braucht ihr daher einen AUR-Helper.
### Installation unter Arch Linux oder Manjaro:
$ yay -S f3
### Installation unter Debian, Ubuntu oder Raspberry Pi OS:
$ sudo apt install f3
Die Kommandos zum Prüfen von USB-Datenträgern lauten nun f3write, f3read und f3probe. Die ersten zwei Befehle müsst ihr in Kombination nutzen. Als Option übergebt ihr den Kommandos jeweils den Mountpunkt des Datenträgers. f3write schreibt nun so lange ein Gigabyte große Dateien auf den eingebundenen Datenträger, bis der Platz ausgeht. Anschließend prüft ihr mit f3read, ob die geschriebenen Daten auch wirklich wieder gelesen werden können. Falls es sich um einen gefälschten USB-Stick oder eine manipulierte SD-Speicherkarte handeln sollte, dann würde f3read korrupte Sektoren ausgeben. Bei dieser Prüfung bleiben alle Daten auf dem Datenträger erhalten, ihr müsst am Ende nur wieder die h2w-Dateien löschen, sonst habt ihr keinen Platz mehr auf dem Stick.
Ein wenig schneller arbeitet f3probe --destructive. Die Option --destructive ist optional, die beschleunigt die Aktion jedoch ganz wesentlich. Bei diesem Test beschreibt F3 nur die nötigsten Sektoren und kümmert sich auch nicht um eine Datensicherung. Da die Probe direkt auf die Hardware zugreif, gebt ihr als Parameter nicht den Mountpunkt sondern die Geräte-ID (hier /dev/sdg) an. Der Test mit meinem 4 GByte großen USB-2.0-Stick dauert so nur ein wenig mehr als sieben Minuten. Habt aber bei dieser Prüfung wieder im Hinterkopf, dass die Routine sämtliche Datenblöcke auf dem Datenträger überschreibt.
$ f3probe --destructive --time-ops /dev/sdg
[...]
Good news: The device `/dev/sdg' is the real thing
Device geometry:
*Usable* size: 3.73 GB (7831552 blocks)
Announced size: 3.73 GB (7831552 blocks)
Module: 4.00 GB (2^32 Bytes)
Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 7'17"
Operation: total time / count = avg time
Read: 2.73s / 4812 = 568us
Write: 7'13" / 3637313 = 119us
Reset: 1us / 1 = 1us
Sowohl Badblocks als auch F3 helfen beim Analysieren von Fehlern auf Datenträgern. Bei der Prüfung müsst ihr allerdings immer ein wenig Zeit mitbringen. Die ausführliche Analyse eines 8 GByte großen USB-Sticks kann schonmal zwei Stunden dauern, besonders wenn bei der Prüfung die Daten erhalten bleiben sollen und der USB-Stick nur mit dem langsamen USB-2.0-Protokoll arbeitet. Danach könnt ihr aber davon ausgehen, dass der USB-Stick oder die SD-Speicherkarte auch wirklich funktionieren und die Kapazität besitzen, die auf dem Aufdruck steht.
