Verschlüsselung für mobile Betriebssystem wie Android ist trivial und mit wenigen Einstellungen aktiviert. Wegen einiger Änderungen in der Vergangenheit gibt es für Android jedoch viele veraltete Informationen.

Verschlüsselung ist bei Desktop-Betriebssystemen wie Windows, Linux oder macOS eine peinliche Leerstelle. Obwohl es für alle drei Systeme leistungsfähige Lösungen gibt, verzichten alle Hersteller auf eine standardmäßige Aktivierung und Bewerben diese auch nicht aktiv. Während Windows und macOS sich wenigstens noch nachträglich verschlüsseln lassen, schauen Linux-Nutzer in die Röhre, wenn sie bei der Installation die entsprechenden Optionen nicht gesetzt haben.

Nicht so bei mobilen Betriebssystemen. Google und Apple haben in ihre Betriebssysteme für Tablets und Smartphones selbstverständlich leistungsstarke Verschlüsselungsmethoden implementiert, die im Hintergrund automatisch aktiviert werden, sobald der Anwender die Codesperre (sowie ggf. biometrische Verfahren) aktiviert. Bei Android hat Google hier in der Vergangenheit einige Änderungen vorgenommen, weshalb viele Berichte dazu veraltet sind und teils unverständliche Kürzel kursieren.

FDE: Full Disk Encryption

Die FDE-Verschlüsselung stand am Anfang. Technisch gesehen handelte es sich um eine Festplattenverschlüsselung auf Basis von dm-crypt. Insbesondere bei diesen tieferen Bereichen von Android merkt man oft die Linux-Basis, denn letztlich ist das nicht viel anderes als die LUKS-Vollverschlüsselung bei Linux.

Technisch war das natürlich etwas aufwendiger. Die Verschlüsselung erfolgte in der üblichen Blockdevice-Methode, bei der die gesamten Userdata-Partition verschlüsselt wurde. Die Verschlüsselung erfolgte mit einem einzigartigen Schlüssel, der gleichermaßen an den Benutzer-PIN gebunden und mittels TEE signiert wurde. Mit diesem Schlüssel wurden jene Bereiche verschlüsselt, in denen Android Benutzerdaten speichert.

Es gab nur ein grundlegendes Problem. Bei einem Neustart des Android-Smartphones waren viele Funktionen nicht verfügbar, bevor der Anwender seine Passphrase eingegeben hatte. Beispielsweise Wecker oder auch Telefonanrufe. Das war natürlich für ein Smartphone-Betriebssystem keine zufriedenstellende Lösung.

Diese Lösung steht nach einer längeren Übergangsphase nicht mehr zur Verfügung. Android ab Version 10 nutzt nur noch die FBE-Methode.

FBE: File Based Encryption

Um diese Beschränkungen zu beheben, hat Google ab Android 7 die dateibasierte Verschlüsselung (FBE) eingeführt. Dabei handelte es sich um eine Neuentwicklung auf Basis des für Android verwendeten Dateisystems ext4. Die Umstellung hat je nach OEM-Hersteller etwas gedauert, weshalb zwischen den Versionen 7 und 9 die Verschlüsselung je nach Konfiguration und Hersteller unterschiedlich funktioniert hat, aber heute ist FBE die Standardverschlüsselung.

Ein netter Nebenaspekt: Diese Erweiterung des ext4-Dateisystems zog mit Kernel 4.1 bzw. 4.6 (fscrypt) direkt upstream ein und kommt dadurch allen Linux-Anwendern zugute. Die Adaption verzögerte sich hier etwas, aber mit systemd-homed steht nun erstmals eine praktikable Umsetzung für den Linux-Desktop zur Verfügung.

Technisch gibt es zwei Bereiche. Den Standarspeicherplatz (Credential Encrypted = CE), der erst nach der Entschlüsselung zur Verfügung steht und den sogenannten Device Encrypted (DE) Speicher, der während des Direct Boot-Verfahrens Anwendungen ermöglicht mit begrenztem Datenzugriff zu funktionieren.

Anfänglich war ein Nachteil der FDE-Methode die fehlende Verschlüsselung der Metadaten (Berechtigungen, Dateigröße, Verzeichnis-Layout etc.). Diese berechtigte Kritik – z. B. in diesem Short Paper – kann man auch heute noch häufiger lesen, wenn es um Android-Verschlüsselung geht. Das Problem hat Google in Android 9 behoben und es ist somit nicht mehr aktuell.

Der wesentliche Unterschied für den Anwender: Mit FBE gesicherte Android-Geräte booten ganz normal in den Sperrbildschirm und bieten dort auch vor der Entschlüsselung durch den Anwender Funktionalitäten wie Anrufe, Wecker etc.

Aktivierung durch den Anwender

Sobald der Anwender einen PIN, eine Passphrase und/oder biometrische Merkmale hinterlegt hat, ist die Verschlüsselung aktiviert. Normalerweise geschieht dies bereits bei der Initialisierungsroutine. Anwender müssen mehrfache Warnungen überspringen, um ihre Geräte ohne entsprechenden Schutz nutzen zu können. Das ist meiner Ansicht nach die richtige Vorgehensweise. Überprüfen lässt sich der Status in den Einstellungen und Sicherheit und dort in Verschlüsselung und Anmeldedaten.

Hier ist wie aus dem folgenden Screenshot bei „Smartphone verschlüsseln“ der Status Verschlüsselt zu sehen. Weitere Einstellungsmöglichkeiten oder Handlungsbedarf bestehen nicht.

Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.

4 Ergänzungen

  1. Das mit der fehlenden „Bewerbung“ FDE auf dem Linuxdesktop würde ich zumindest nicht für alle Distributionen unterschreiben. Zumindest im Fedora-Installer ist die zugehörige Checkbox doch recht deutlich plaziert und die Verschlüsselung lässt sich auch mit der erweiterten Partitionierung sehr gut an die eigenen Bedürfnisse anpassen. Dass dm-crypt sich nicht nachträglich aufs Rootfs anwenden lässt, ist technisch nachvollziehbar. Hier stellt sich aber natürlich die Frage, ob es ggf. sinnvoll sein kann, by default alles zu verschlüsseln, aber einen Keyslot ohne Passphrase einzurichten, d.h. eine automatische Entsperrung zu ermöglichen (nicht nur für einfachere nachträgliche „Verschlüsselung“, sondern auch, damit zur sicheren Löschung nicht der komplette Datenträger überschrieben werden muss, sondern nur der Header).

    Den vorletzten Absatz zu Metadatenschutz bei fscrypt finde ich interessant. Hast Du da weitergehende Informationen, was seit Android 9 diesbezüglich passiert, was fscrypt am Desktop nicht kann?

  2. Was nutzt einem Verschlüsselung am Handy, wenn man dann nicht arbeiten kann, weil irgendwas kaputt wieder ist und dadruchr das ganze Handy zurückgesetzt wurde… gar nix. Also lass ich das lieber mit der Verschlüsselung. Zuletzt mit Linegeagos (9) versucht.

    Pin eingeben, es lädt ewig. Was war, Schlüssel kaputt. Oder Upgrade mit TWRP ging nicht wegen Verschlüsselung. Nur mit Löschen war es möglich das Android neue aufsetzen, anstatt ohne Verschlüsselung einfach das Upgrade durchzuführen. Ok alles geplättet.

    Wenn ich mal wieder Zeit und bock habe zum basteln, dann probier ich das noch mal aus. Am PC das gleiche. Den kann man nicht einfach so mitnehmen. Am Laptop siehts wieder anders aus, wenn die Platte fest eingebaut ist dann wird die verschlüsselt. Aber am Laptop weiß ich das es funktioniert und mir nicht wie ein Knüppel zwischen die Beine fliegt und mich am Arbeiten hindert.

    • Android-Verschlüsselung klappt sehr gut, aber natürlich nicht wenn man Crap wie TWRP nutzt. LineageOS hat nicht umsonst inzwischen ein eigenes Recovery entwickelt.

Schreiben Sie eine Ergänzung

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihre Ergänzung ein!
Bitte geben Sie hier Ihren Namen ein