Die Smartphone-Verschlüsselung ist ein Bereich, bei dem es auf Einzelheiten ankommt. Die dateibasierter Verschlüsselung von Android Nougat war ein Feature, bei dem ich echt dachte, dass Google jetzt endlich in Sachen Sicherheit, zumindest bei der Verschlüsselung, aufholt. Ich möchte nicht zu viel vorweg nehmen, aber der Abstand zwischen iOS und Android ist größer denn je.
Foto: Google
Wechsel von Komplett- zu dateibasierter Verschlüsselung
Mit Android 7.0 (Nougat) verabschiedet sich Google von der vollständigen Verschlüsselung. Stattdessen bietet das mobile Betriebssystem mit der Option "Direct Boot" die Möglichkeit der dateibasierten Verschlüsselung. Soweit, so gut, dieses Verfahren ist bereits von anderen Systemen wie iOS bekannt. Leider hat Google mit dieser Funktion aber nicht das Problem des stetig entschlüsselten Datenträgers adressiert. Der Internet-Riese konzentrierte sich viel mehr auf die Herausforderung, dass ein Gerät nach dem ersten Einschalten keine brauchbaren Daten anzeigt. Zur Erläuterung:
Entwickler haben für ihre Apps zwei Möglichkeiten der Datenverschlüsselung. Es gibt die Option der
mit Anmeldedaten verschlüsselten Speicherung: Dateien dieses Bereichs werden unter dem Benutzerpasswort verschlüsselt und sind nicht vor der Eingabe des Passworts durch den Benutzer verfügbar (einmal); sowie
der geräteverschlüsselten Speicherung: Diese Dateien werden nur mit den auf Hardware hinterlegten Schlüsseln verschlüsselt. Somit sind sie nach dem Booten verfügbar, sogar vor Eingabe des PIN-Codes durch den Benutzer.
Wirft man einen Blick in den Source-Code wird die Schwäche des Systems noch deutlicher. An der entscheidenden Stelle wirft das System den Schlüssel (Encryption Key) nicht weg, es behält ihn im Speicher ... und Google dokumentiert dies freundlich mit "// TODO: remove from kernel keyring".
Bemerkenswerterweise lagert Android N nicht einmal seine Disk Keys im Kernel - stattdessen werden diese vom „vold" daemon gehalten, der als Nutzer „root" im Userspace läuft. Dies macht Exploits nicht unbedingt einfach, ist jedoch sicherlich nicht der beste Weg, die Dinge zu handhaben.
Immerhin: Zur Ehrenrettung sei erwähnt, dass Android-N im Zusammenhang mit Android for Work einen eigenen Encryption Key zu erhalten scheint.
Wo ist das Problem ?
Es kommen mehrere Probleme zusammen. Grundsätzlich vertraue ich persönlich keinem System, dass den Schlüssel zur Entschlüsselung im Speicher behält, auch dann, wenn das Gerät gesperrt ist. Das ist eine (persönlich empfundene) Unsitte von Google. Aber hier reiht sich Google in bewährte Praxis ein, denn auch BlackBerry hat dies seit längerem als Feature im Programm.
Google kann den mit "ToDo" vermerkten Programmcode auch nicht einfach ergänzen, viele Millionen App-Entwickler wüßten nichts davon und mindestens ebenso viele Apps wären betroffen. Wird der Schlüssel während einer Sperrung des Geräts "entfernt", werden Anwendungen unerwarteterweise feststellen, dass ihre Dateizugriffe Fehler ausgeben.
Hilft "sichere" Android-Hardware?
Persönlich glaube ich nicht, dass die hoch gepriesene sichere Hardware einiger Hersteller (z.B. Samsung, Blackberry usw.) greift. Eine derartige Hardware löst sicherlich diverse Probleme, aber nicht den fundamentalen Fehler im Souce-Code von Android.
So zwingt beispielsweise die ARM TrustZone - sofern diese korrekt implementiert ist - Angreifer dazu, ihre Verschlüsselungscodes auf dem Gerät selbst zu erlangen, was Wörterbuchangriffe auf das Passwort erheblich erschweren sollte. In einigen Fällen kann diese Hardware genutzt werden, um einen Schlüssel vorzuhalten und nur dann zur Entsperrung einzusetzen, wenn eine biometrische Zugangskontrolle wie beispielsweise ein Fingerabdruck erfolgt. Dieser Schlüssel hat jedoch nichts mit der Verschlüsselung selbst zu tun, häufig ist das nur der Display-Schutz.
OEMs wollen Geräte verkaufen und so viel Gewinn wie möglich mit ihrer Hardware machen. Ein stetiger Preiskampf sorgt dabei für gefühlt "viel Hardware fürs Geld", drückt die Margen aber zusätzlich. Abgesehen von ganz wenigen Anbietern, wie z.B. Blackberry mit ihrer eigenen Android-Implementierung, sind wenige OEMs mit "sicherer" Hardware unterwegs.
Alles in allem wird zwar das Booten abgesichert und der Anwender erhält mit biometrischen Funktionen mehr Benutzerfreundlichkeit etc.. Das Problem, dass der Datenträger bei Handy-Sperrung eben nicht wieder verschlüsselt wird (bei iOS passiert dies spätestens 10 Sekunden nach Sperre des Gerätes), wird damit nicht adressiert.
Mein persönlicher Ausblick für die nächsten Jahre
Das Thema der Verschlüsselung erfährt, wenn ich nichts übersehen haben, bei Google eine relativ niedrige Priorität. War der Fall "FBI gegen Apple" sehr medienwirksam aufbereitet, dürfte ein Angriff gegen Android-Handys im Hinterzimmer bereits passieren, auch ohne die Unterstütung von Google. Die Dateiverschlüsselung hilft hier jedenfalls nicht solange der einzige Schutz eine Display-Sperre darstellt.
Im Vergleich zu Android ist Apples iOS somit sehr gut mit dem Fokus auf Anwender und Unternehmen aufgestellt, zumindest bei Datenschutz und -sicherheit.
Bis Google Apple hier eingeholt haben wird, werden daher noch viele Jahre vergehen. Der Leidtragende ist dabei der Anwender. Ich freue mich auf Ihre Kommentare, auch falls dieser Text etwas übersehen haben sollte. (mb)