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.
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?
Zu den Metadaten kann man hier ein paar Infos nachlesen: https://source.android.com/security/encryption/metadata?hl=en
Allgemein stellt Google ja relativ viele Informationen zur Android-Basis bereit.
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.