Heutzutage tragen wir einen Großteil unseres Lebens auf unseren Mobiltelefonen mit uns herum: persönliche Fotos, private Chats, Arbeitsdokumente, gespeicherte Passwörter, Banking-Apps… Wenn Sie Ihr Telefon verlieren oder es gestohlen wird, ohne dass Ihre Daten geschützt sind Es kann sich zu einer echten Katastrophe ausweiten, sowohl persönlich als auch beruflich, daher ist es wichtig zu wissen, wie man Maßnahmen ergreift, um die Sicherheit stärken.
Um dieses Risiko zu minimieren, hat Android seit Jahren verschiedene Verschlüsselungsmechanismen integriert, die weit über eine einfache PIN oder ein Entsperrmuster hinausgehen. Festplattenverschlüsselung und dateibasierte Verschlüsselung, zusammen mit verifiziertem Bootvorgang und hardwaregeschützten SchlüsselnSie bilden ein komplexes Ökosystem, das so konzipiert ist, dass selbst jemand, der das Gerät in der Hand hält, die Informationen ohne die entsprechenden Zugangsdaten nicht lesen kann. Falls Sie dies benötigen, konsultieren Sie bitte So verschlüsseln Sie Ihr Mobiltelefon.
Was ist Datenverschlüsselung auf Android und warum ist sie so wichtig?
Wenn wir von der Verschlüsselung eines Android-Geräts sprechen, meinen wir den Vorgang der alle gespeicherten Daten in unlesbare Informationen umwandeln Wenn Sie nicht den richtigen Schlüssel haben. Praktisch gesehen ist es so, als würden Sie den gesamten Inhalt Ihres Telefons in einen digitalen Tresor legen, der nur mit Ihrer PIN, Ihrem Muster, Ihrem Passwort oder Ihrem biometrischen Faktor geöffnet werden kann.
Diese Verschlüsselung schützt sowohl persönliche Daten (Fotos, Videos, Nachrichten, heruntergeladene Dateien) als auch Unternehmensdaten. Im Geschäftsumfeld ist es ein Schlüsselelement für die Einhaltung von Vorschriften wie der europäischen DSGVO oder dem HIPAA in den USA.Dies verringert das Risiko von Datenlecks erheblich, falls ein Terminal mit Kundendaten, Krankenakten, juristischen Dokumenten oder internen VPN-Zugangsdaten verloren geht oder gestohlen wird. Darüber hinaus wird die Aufrechterhaltung der sichern Dadurch wird verhindert, dass der Verlust des Geräts zum vollständigen Datenverlust führt.
Es ist wichtig zu beachten, dass eine Bildschirmsperre allein nicht ausreicht. Eine PIN ohne Verschlüsselung verhindert lediglich die Nutzung der Telefonoberfläche, aber Wenn der Speicher nicht verschlüsselt ist, könnte ein Angreifer die Daten physisch extrahieren. durch Kopieren des Speicherinhalts mithilfe forensischer Tools oder Ausnutzung von Bootloader-Schwachstellen. Zusätzlich durch die Verwendung von Prey-Sicherheits-App Es kann helfen, ein verlorenes oder gestohlenes Gerät zu lokalisieren und zu verwalten und ergänzt so die Verschlüsselung.
Bei aktivierter Verschlüsselung werden die Daten in einem mathematisch unverständlichen Format ohne den Schlüssel gespeichert. Selbst wenn jemand die Datenpartition Byte für Byte kopiert oder ein modifiziertes System startetSie erhalten lediglich bedeutungslose Blöcke verschlüsselter Daten.
Von der vollständigen Festplattenverschlüsselung bis zur dateibasierten Verschlüsselung
Historisch gesehen hat Android zwei Hauptansätze zur Geräteverschlüsselung verfolgt: Vollständige Festplattenverschlüsselung (FDE) und dateibasierte Verschlüsselung (FBE)Das Verständnis des Unterschieds hilft sehr dabei, zu verstehen, was zu einem bestimmten Zeitpunkt geschützt wird und warum bestimmte Funktionen auch dann noch funktionieren, wenn das Telefon "gesperrt" ist.
Die vollständige Festplattenverschlüsselung wurde in Android 4.4 (API 19) eingeführt und erlangte mit Android 5.0 (API 21) größere Bedeutung. In diesem Modell Die gesamte Benutzerdatenpartition ist mit einem einzigen Schlüssel geschützt.Dieser Schlüssel wird aus den Anmeldeinformationen des Benutzers abgeleitet, daher kann das System erst dann auf irgendetwas im Verzeichnis /data zugreifen, wenn Sie beim Start Ihre PIN, Ihr Entsperrmuster oder Ihr Passwort eingeben.
Dieser Ansatz ist aus Datenschutzsicht sehr robust, hat aber einen klaren Nachteil: Nahezu das gesamte System bleibt so lange funktionsunfähig, bis es nach dem Start zum ersten Mal entsperrt wird.Alarme sind nicht möglich, viele Dienste starten nicht, und das Telefon kann nicht einmal normale Anrufe empfangen, sondern nur Notrufe, weil die Telefonschicht noch keinen Zugriff auf ihre Daten hat.
Um dieses Problem zu lösen, hat Google in Android 7.0 Nougat (API 24) das gesamte Verschlüsselungsschema überarbeitet und die dateibasierte Verschlüsselung (FBE) eingeführt. In diesem Modell Jede Datei kann mit einem anderen Schlüssel geschützt werden.Dies ermöglicht es, verschiedene Teile des Systems unabhängig voneinander zu entsperren, je nachdem, welche Zugangsdaten verwendet wurden.
FBE bringt auch den sogenannten Modus mit DirektstartDadurch kann das Gerät direkt zum Sperrbildschirm hochfahren und einige Apps können in einem eingeschränkten Kontext funktionieren, bevor der Benutzer seine PIN oder sein Passwort eingibt.
Funktionsweise des Direktstartmodus und der CE/DE-Trennung
Die wichtigste konzeptionelle Änderung bei FBE besteht darin, dass bei einem dateibasierten Verschlüsselungsgerät, Jeder Systembenutzer verfügt über zwei separate Speicherbereiche.mit unterschiedlichen Schlüsseln und unterschiedlichen Entsperrzeiten.
Der erste ist Anmeldeinformationsverschlüsselter Speicher (CE)Dies ist der Standardspeicherort für Benutzer- und Anwendungsdaten und wird erst nach Eingabe der Anmeldedaten beim Start freigegeben. Hier sollten alle wirklich sensiblen Daten gespeichert werden: Anwendungsdatenbanken, persönliche Dokumente, lokale E-Mail-Backups usw.
Das zweite ist das Geräteverschlüsselter Speicher (DE)Dieser Bereich ist sowohl im Direktstartmodus (vor der Anmeldung) als auch danach verfügbar und wird mit einem gerätegebundenen Schlüssel verschlüsselt, der nach erfolgreichem Systemstart sofort verfügbar ist. Er enthält Daten, die bereits vor dem ersten Entsperren zugänglich sein müssen: grundlegende Benachrichtigungen, Telefondienste, einige Bedienungshilfen, Wecker-Apps oder die Anmeldemethode des Sperrbildschirms.
Ideal, Wenn eine App funktionieren muss, bevor der Benutzer das Gerät entsperrt (zum Beispiel bei einem Wecker oder einem Telefonwähler) speichern Sie in DE nur das, was für diese grundlegende Funktion unbedingt erforderlich ist, und bewahren Sie alle persönlichen oder kritischen Informationen in CE auf.
Tatsächlich ist Googles Empfehlung eindeutig: Die Dateien sollten nach Möglichkeit im CE-Verzeichnis liegen.Der DE-Speicher ist für minimale Konfigurationen und kurzlebige Daten gedacht, nicht für sensible Inhalte wie vollständige Kontaktlisten, Chatverläufe oder Firmendokumente.
Technische Anforderungen und die obligatorische Natur der Verschlüsselung in modernen Android-Versionen
Android 7.0 erlaubt FBE, und ab Android 10 ist es von Google vorgeschrieben. Alle Geräte, die mit dieser Version oder einer späteren Version ausgeliefert werden, verwenden dateibasierte Verschlüsselung.Bei Telefonen ohne hardwareseitige AES-Verschlüsselungsbeschleunigung wird der Adiantum-Algorithmus verwendet, um eine gute Leistung aufrechtzuerhalten.
Für die ordnungsgemäße Implementierung von FBE muss der Hersteller mehrere grundlegende Anforderungen erfüllen. Zum einen muss er Der Linux-Kernel des Geräts muss die fscrypt-Dateisystemverschlüsselungsschicht unterstützen. Für ext4 oder F2FS (die beiden gängigen Optionen für /data in Android). In modernen Kerneln aktivieren Sie einfach Optionen wie CONFIG_FS_ENCRYPTION und, falls Sie die Inline-Verschlüsselung nutzen möchten, CONFIG_FS_ENCRYPTION_INLINE_CRYPT.
Es ist auch notwendig, KeyMint oder zumindest Keymaster 1.0Gatekeeper läuft in einer Trusted Execution Environment (TEE). Dadurch werden die mit dem Gerät und dem Benutzer verknüpften Verschlüsselungsschlüssel vor unautorisierten Betriebssystemen und modifizierten Kerneln geschützt, die versuchen, mit entsperrtem Bootloader zu starten.
Das Gerät muss außerdem über Folgendes verfügen: Hardware-Vertrauensanker und verifizierter Startvorgang Dies hängt mit dem KeyMint-Initialisierungsprozess zusammen und verhindert unbefugten Zugriff auf die Geräteverschlüsselungsschlüssel (DE-Schlüssel). Anders ausgedrückt: Selbst wenn eine modifizierte Firmware aufgespielt wird, verweigert die Sicherheitshardware die Freigabe der Schlüssel, wenn die Bootkette nicht legitim ist.
Auf Konfigurationsebene wird die FBE-Verschlüsselung durch Bearbeiten der fstab-Datei des Geräts für die Benutzerdatenpartition aktiviert. Dort wird eine entsprechende Option angegeben. Dateiverschlüsselung=… Dabei wird der Inhaltsverschlüsselungsalgorithmus (üblicherweise aes-256-xts oder Adiantum), der Dateibenennungsalgorithmus (aes-256-cts, aes-256-heh, aes-256-hctr2 oder adiantum) und eine Reihe optionaler Flags (v1/v2, inlinecrypt_optimized, emmc_optimized, wrappedkey_v0, dusize_4k) definiert.
Welche Teile des Systems sind verschlüsselt und wie sind die Schlüssel organisiert?
In einem Android-System mit korrekt konfiguriertem FBE ist /data wie folgt organisiert: verschiedene „Speicherklassen“ abhängig vom Schlüssel, der sie schützt, und dem Zeitpunkt, an dem sie zugänglich werden.
Es gibt Verzeichnisse, die nicht mit FBE verschlüsselt sind (obwohl sie in vielen Fällen mit Metadatenverschlüsselung verschlüsselt sind), wie zum Beispiel /data/apex (mit Ausnahme einiger Unterverzeichnisse) /data/lost+found, /data/preloads oder /data/unencrypted. Dies sind Pfade, in denen Systemkomponenten oder -strukturen gespeichert sind, die nicht mit Benutzeranmeldeinformationen verknüpft werden müssen.
Dann gibt es noch die Klasse von System vonDiese Kategorie gruppiert verschlüsselte Daten pro Gerät, die keinem bestimmten Benutzer zugeordnet sind: /data/app, /data/misc, /data/system, /data/vendor und andere Unterverzeichnisse von /data. Zusätzlich gibt es die Klasse „per_boot“ (/data/per_boot) für temporäre Dateien, die nach einem Neustart nicht erhalten bleiben müssen.
Für jeden Benutzer werden spezifische CE- und DE-Routen erstellt: /data/user/${user_id}, /data/system_ce/${user_id}, /data/misc_ce/${user_id}, /data/vendor_ce/${user_id} Für interne CE; und /data/user_de/${user_id}, /data/system_de/${user_id}, /data/misc_de/${user_id}, /data/vendor_de/${user_id} für interne DE. Falls erweiterbarer Speicher vorhanden ist (SD-Karte als Erweiterung des internen Speichers), werden ähnliche Strukturen unter /mnt/expand/${volume_uuid}/ repliziert.
Die Schlüsselverwaltung übernimmt vold, der Android-Volume-Daemon. Vold verwaltet FBE-Schlüssel und speichert sie verschlüsselt auf der Festplatte. (Ausgenommen ist der „On Boot“-Schlüssel, der jedes Mal neu generiert und nie gespeichert wird.) Beispielsweise werden die internen Benutzer-CE- und DE-Schlüssel in /data/misc/vold/user_keys/ce/${user_id} bzw. /data/misc/vold/user_keys/de/${user_id} gespeichert und ihrerseits durch Schlüssel im Keystore der TEE geschützt.
Mit Ausnahme der internen Speicher-CE-Schlüssel sind die übrigen FBE-Schlüssel mit AES-256-GCM unter Verwendung von Keystore-Schlüsseln verschlüsselt, die die sichere Umgebung nicht verlassen. Darüber hinaus werden Techniken wie Rollback-Resistenz und „secdiscardable“-Dateien verwendet. um sicherzustellen, dass das Löschen eines Schlüssels wirklich endgültig ist, selbst gegen Versuche, frühere Systemzustände wiederherzustellen.
Zusammenhang zwischen Bildschirmsperre, synthetischem Passwort und CE-Schlüsseln
Interne CE-Speicherschlüssel bieten eine zusätzliche Schutzebene, da sie tatsächlich verhindern, dass ein Angreifer, selbst wenn er die Kontrolle über das System hat, Ihre Daten ohne Ihr Passwort entschlüsseln kann. Android führt hier das Konzept der synthetischen Passwörter ein.: ein Geheimnis mit hoher Entropie, das vom System für jeden Benutzer zufällig generiert wird und niemals direkt eingegeben wird, sondern durch die PIN, das Entsperrmuster oder das Sperrpasswort geschützt ist (LSKF).
Der Dienst LockSettingsService auf system_server verwaltet dieses synthetische Passwort. Wenn Sie Ihre PIN oder Ihr Bildschirmpasswort einrichten oder ändernDas System nimmt diese LSKF-Datei, leitet sie durch scrypt (um sie etwas abzusichern) und verwendet sie zur Interaktion mit Weaver oder Gatekeeper, abhängig von der Hardware des Geräts.
Auf Weaver-fähigen Geräten ist der gehärtete LSKF mit einem zufälligen Geheimnis hoher Entropie verknüpft, das in einem sicheren Element (SE) oder der TEE gespeichert ist. Das synthetische Passwort wird dann zweimal verschlüsselt: zuerst mit einem Schlüssel, der aus dem LSKF und dem Weaver-Geheimnis abgeleitet ist, und anschließend mit einem Schlüsselspeicherschlüssel. Dies führt zu … eine hardwareseitig erzwungene Begrenzung der Versuchsrate um das Passwort zu erraten und so schnelle Brute-Force-Angriffe zu verhindern.
Auf Geräten ohne Weaver wird das gehärtete LSKF mit Gatekeeper verwendet, und auch hier wird das synthetische Passwort zuerst mit einem aus dem LSKF abgeleiteten Schlüssel und einer Wegwerfdatei und dann mit einem Keystore-Schlüssel verschlüsselt, der mit der Authentifizierung in Gatekeeper verknüpft ist. Das Ergebnis ist, dass CE-Schlüssel nicht freigeschaltet werden können, ohne diese Schutzmechanismen zu überwinden.selbst wenn ein Versuch mit einem modifizierten System oder einem alternativen Bootvorgang unternommen wird.
Wenn Sie Ihre PIN oder Ihr Sperrpasswort ändern, wird der LockSettingsService Dadurch wird die bisherige Verbindung zwischen LSKF und synthetischem Passwort aufgehoben.Bei Geräten mit Unterstützung für umgekehrte Reverse-Resistance-Verschlüsselung verhindert dies die Wiederverwendung alter Verknüpfungen und verstärkt so das Sicherheitsmodell zusätzlich.
Ist die Verschlüsselung auch bei einem entsperrten oder gerooteten Bootloader noch geschützt?
Dies führt uns zu einem der Punkte, der unter fortgeschrittenen Nutzern die meisten Diskussionen auslöst. Theoretisch sollte ein „gut konzipiertes“ Verschlüsselungssystem nicht einfach dadurch geknackt werden, dass der Bootloader entsperrt ist. oder weil Sie eine ADB-Shell mit Root-Rechten erhalten: Solange Sie nicht über den aus dem Benutzerpasswort abgeleiteten Schlüssel verfügen, sollten die Daten unlesbar bleiben.
In der Praxis verfolgt das moderne Android-Modell zwei Ziele: zum einen, dass CE-Schlüssel können nicht ohne LSKF bezogen werden.Dies ist der kombinierten Verwendung von TEE/SE, Gatekeeper/Weaver und Keystore zu verdanken; außerdem blockiert Verified Boot den Zugriff auf DE-Schlüssel, wenn ein nicht vertrauenswürdiges System erkannt wird. Es gibt jedoch wichtige Nuancen.
Eine davon ist, dass auf Geräten mit FBE, Einige Inhalte im Verzeichnis /data sind in der deutschen Version möglicherweise schon vor der PIN-Eingabe verfügbar.Dies umfasst interne Strukturen, Hilfsdateien und sogar bestimmte Verzeichnisse in /data/misc, /data/system oder ähnlichen Verzeichnissen, die zwar auf der Festplatte verschlüsselt sind, aber nach dem Systemstart entschlüsselt werden, da der DE-Schlüssel ohne Benutzerinteraktion verfügbar ist.
In einigen realen Experimenten wurde beispielsweise beobachtet, dass auf einem Moto X4 mit LineageOS 16 (Android 9), aktivem FBE und aktivierter SD-Karte, Das Verzeichnis /data wird beim Erreichen des Sperrbildschirms bereits als eingebunden angezeigt.Über eine ADB-Root-Shell lassen sich einige spezifische Dateien ohne Passworteingabe extrahieren. Andere hingegen funktionieren nicht oder sind scheinbar nicht zugänglich, was darauf hindeutet, dass sie korrekt an CE gebunden sind.
Noch gravierender ist, dass, wenn die Genehmigungen und Richtlinien nicht ordnungsgemäß angepasst werden, Es ist möglich, bestimmte Schlüssel, die mit anpassbaren Volumes verknüpft sind, aus /data/misc/vold zu lesen.Beispielsweise bei der verschlüsselten SD-Karte. Mit diesem Schlüssel ist es möglich, das Volume außerhalb des Telefons einzubinden und zu entschlüsseln, wodurch die Verschlüsselung der Karte wirkungslos wird.
Diese Art von Situationen sind weniger ein Konstruktionsfehler von FBE selbst, sondern Implementierungsfehler oder unsichere Konfigurationen Bei benutzerdefinierten ROMs, modifizierten Recoveries oder Geräten, bei denen der Hersteller nicht alle Empfehlungen befolgt hat (z. B. nicht ordnungsgemäße Isolation des Zugriffs auf /data/misc/vold, fehlende Anwendung von SELinux im strikten Modus oder nicht korrekte Trennung der Daten, die in CE gehören sollen), überprüfen und anpassen. Sicherheitseinstellungen hilft, diese Risiken zu verringern.
Warum funktionieren Spotify, YouTube und Benachrichtigungen noch, wenn mein Telefon gesperrt ist?
Eine sehr häufige Frage unter Nutzern lautet: Ist „alles verschlüsselt“, wenn ich mein Telefon sperre? Warum werden immer noch Benachrichtigungen ausgelöst, Spotify funktioniert weiterhin oder werden weiterhin Nachrichten empfangen? während der Bildschirm ausgeschaltet ist und das Gerät scheinbar geschützt ist?
Der Schlüssel liegt im FBE-Modell und der Unterscheidung zwischen Bildschirmsperrzustand und Speicherentsperrzustand. Nach dem ersten Entsperren nach dem Hochfahren bleiben die meisten CE-Schlüssel so lange verfügbar, wie das Gerät nicht neu gestartet wird.Durch das Sperren des Bildschirms wird nicht alles von Grund auf neu verschlüsselt; es wird lediglich der logische Zugriff auf die Benutzeroberfläche und bestimmte APIs unterbunden, aber das System verfügt weiterhin über die Schlüssel im Speicher, um betriebsbereit zu sein.
Darüber hinaus werden viele der von Apps wie Spotify, YouTube oder Push-Benachrichtigungsdiensten benötigten Daten in DE-Zonen gespeichert oder repliziert, oder die Apps sind als „directBootAware“ gekennzeichnet. um mit einem eingeschränkten Datensatz arbeiten zu können, solange der Benutzer die PIN noch nicht eingegeben hat. nach einem Neustart. Deshalb können Sie beispielsweise einen Anruf erhalten oder einen Alarm hören, selbst wenn das Telefon gerade erst eingeschaltet wurde und Sie sich noch auf dem Sperrbildschirm befinden.
Die Entschlüsselung dauert nicht buchstäblich "1 Sekunde"; was tatsächlich passiert, ist Folgendes: Die Hauptarbeit wurde bereits beim Startvorgang und dem ersten Entriegeln erledigt.Ab diesem Zeitpunkt bleiben die Tasten aktiv (bis zum nächsten Neustart), damit nicht ständig alles neu berechnet werden muss, was die Benutzererfahrung unerträglich machen würde.
Dies bedeutet, dass ein Angreifer, der nach dem Hochfahren des Geräts bereits entsperrt ist und dadurch erhöhte Berechtigungen erlangt (zum Beispiel durch Root-Malware oder eine Kernel-Schwachstelle), Er könnte auf wesentlich mehr Informationen zugreifen, als wenn er es direkt nach dem Einschalten des Geräts versuchen würde, bevor irgendjemand die PIN eingibt.Deshalb ist es so wichtig Neustart erzwingen Entsperren Sie das Gerät, bevor Sie es an Grenzbeamte, Reparaturtechniker oder in anderen sensiblen Situationen übergeben, und entsperren Sie es nicht wieder.
Was System-Apps mit Direct Boot können und was nicht.
Mit dem Aufkommen von FBE führte Android neue APIs und Manifestattribute ein, damit Apps wissen, dass In welchem Verschlüsselungsstatus befindet sich das Gerät? und welche Speicherkapazität ihnen jeweils zur Verfügung steht.
Im Manifest einer App können zwei relevante Attribute deklariert werden: android:directBootAware und android:defaultToDeviceProtectedStorage. Die erste Option gibt an, dass alle App-Komponenten die Verschlüsselung kennen und im Direct-Boot-Modus funktionieren können; die zweite Option bewirkt, dass die App standardmäßig den DE-Speicher anstelle des CE-Speichers für ihre Daten verwendet.
System-Apps, die mit defaultToDeviceProtectedStorage gekennzeichnet sind, müssen Prüfen Sie sorgfältig, welche Informationen an diesem Ort gespeichert sind. und alle Daten, die als persönlich oder sensibel gelten könnten, an CE zu übertragen. Die Hersteller sind dafür verantwortlich, keine umfangreichen Verlaufsdaten, Kontaktlisten oder Benutzerdaten an DE zu übertragen, sondern sich auf die Mindestkonfigurationen zu beschränken, die für die Funktionsfähigkeit des Geräts vor der ersten Entsperrung erforderlich sind.
Um diese Kontexte besser zu handhaben, bietet Android Methoden wie beispielsweise Context.createCredentialProtectedStorageContext() und Context.isCredentialProtectedStorage(), die es Apps ermöglichen, explizit auszuwählen, wo ihre Daten gespeichert oder gelesen werden sollen, basierend auf dem Verschlüsselungsstatus und den Datenschutzanforderungen.
Auf Mehrbenutzergeräten mit Arbeitsprofilen wird die Sache noch komplizierter: Jeder Benutzer und jedes Jobprofil verfügt über eigene CE- und DE-Schlüssel.. App-Berechtigungen Funktionen wie INTERACT_ACROSS_USERS oder INTERACT_ACROSS_USERS_FULL ermöglichen es bestimmten System-Apps, zwischen Benutzern zu interagieren, können aber nur auf die CE derjenigen zugreifen, die bereits freigeschaltet sind, wodurch eine weitere Isolationsebene hinzugefügt wird.
SD-Kartenverschlüsselung und adaptiver Speicher: Stärken und Schwächen
Wenn Sie eine SD-Karte als adaptiven Speicher verwenden, behandelt Android diese als verschlüsselte Erweiterung des internen Speichers. Die Karte ist mit einem Schlüssel verschlüsselt, den im Prinzip nur das Gerät selbst verwenden können sollte.Dieser Schlüssel wird verschlüsselt zusammen mit anderen Volume-Schlüsseln unter Pfaden wie /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} oder /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} gespeichert.
Seit Android 9 werden FBE und adaptiver Speicher vollständig unterstützt, und ab Android 11 ist die Definition von Inhalts- und Metadatenverschlüsselungsformaten durch Systemeigenschaften wie … vereinheitlicht. ro.crypto.volume.options oder ro.crypto.volume.metadata.encryption. In früheren Versionen wurden separate Eigenschaften für Inhaltsmodi und Dateinamen verwendet, und auf vielen Geräten wurde der Standardwert für Namen auf adaptiven Volumes nicht empfohlen, sodass er explizit angepasst werden musste.
Im Idealfall, selbst wenn jemand die SD-Karte entfernt, Die Daten sollten ohne den auf dem Telefon gespeicherten Schlüssel unzugänglich bleiben.Wenn der Schlüssel jedoch aufgrund einer Fehlkonfiguration des Geräts mit einer Root-Shell aus /data/misc/vold extrahiert werden kann, bricht das Modell zusammen. Dies verdeutlicht, warum die bloße Aktivierung der Verschlüsselung in der Theorie nicht ausreicht: Sie muss durch fundierte SELinux-Richtlinien und eine sorgfältige Berechtigungsverwaltung ergänzt werden.
Für SD-Karten, die als herkömmlicher (nicht adaptiver) externer Speicher verwendet werden, bieten viele Hersteller unter Einstellungen > Sicherheit die Option "SD-Karte verschlüsseln" an. Normalerweise stellt diese Verschlüsselung sicher, dass nur dieses eine Gerät die Daten auf der Karte lesen kann.Der Vorgang kann je nach Größe und Geschwindigkeit der SD-Karte unterschiedlich lange dauern. Nach Abschluss des Vorgangs sind die Inhalte der Karte in einem anderen Telefon oder Computer nicht mehr lesbar. Darüber hinaus empfiehlt es sich, die Karte regelmäßig aufzubewahren. Cloud-Backups um sicherzustellen, dass bei einem Kartenausfall keine Informationen verloren gehen.
Selbst dann, wenn der Schlüsselansatz nicht richtig verknüpft ist, Durch das Auslesen des SD-Kartenschlüssels aus dem Telefon selbst könnte dieser extern entschlüsselt werden.Daher raten viele Unternehmen in Hochsicherheitsbereichen davon ab, adaptive SD-Speicher zu verwenden oder deren Einsatz auf nicht kritische Daten zu beschränken.
Verschlüsselung, Leistung und mögliche Nachteile
Die Verschlüsselung ist mit einem Rechenaufwand verbunden: Das Lesen oder Schreiben verschlüsselter Daten erfordert die Anwendung von Algorithmen wie AES-256-XTS oder Adiantum. Auf modernen Geräten mit hardwarebasierter kryptografischer Beschleunigung (zum Beispiel ARMv8 CE-Erweiterungen auf ARM64), die Auswirkungen auf Leistung und Stromverbrauch sind sehr gering und kaum wahrnehmbar.
Um die Leistung zu maximieren, enthalten gängige Android-Kernel ein Framework von Inline-VerschlüsselungDies ermöglicht es bestimmten Speichercontrollern (UFS, eMMC), Daten „während der Übertragung“ zu verschlüsseln und zu entschlüsseln. Die Aktivierung von Optionen wie CONFIG_BLK_INLINE_ENCRYPTION, CONFIG_SCSI_UFS_CRYPTO oder CONFIG_MMC_CRYPTO zusammen mit Flags wie inlinecrypt_optimized oder emmc_optimized trägt dazu bei, den Overhead zu minimieren und die Batterielebensdauer zu verlängern.
Bei älteren Geräten oder solchen ohne Unterstützung für beschleunigtes AES kann der Leistungsverlust deutlicher spürbar sein, daher Google wird Adiantum entwerfenDieses System ist darauf ausgelegt, auch auf einfacher Hardware hohe Sicherheit zu bieten. Dennoch kann es bei einigen Nutzern zu leichten Leistungseinbußen kommen, insbesondere wenn die Verschlüsselung auf einem leistungsschwachen Gerät manuell aktiviert wird.
Ein weiterer Punkt, den man beachten sollte, ist folgender: Sobald der Speicher verschlüsselt ist, gibt es in der Regel kein Zurück mehr ohne einen Werksreset.Das Format der Festplattenverschlüsselung wird durch Optionen wie `fileencryption` in der Datei `fstab` definiert und lässt sich nicht einfach per Over-the-Air-Update (OTA) ändern. Um die Verschlüsselung zu deaktivieren, muss üblicherweise die Datenpartition gelöscht und das System neu installiert werden.
Bei älteren Android-Versionen benötigten einige herkömmliche OTA-Updates Zugriff auf Daten im Verzeichnis /data von der Wiederherstellungspartition aus, was nicht möglich ist, wenn dieser Bereich durch DE geschützt ist. In solchen Fällen entschieden sich einige Hersteller für … Das oberste Verzeichnis unverschlüsselt lassen (zum Beispiel /data/misc_ne) ausschließlich zum Speichern von Aktualisierungspaketen, wobei mit SELinux gesteuert wird, dass nur der Aktualisierungsprozess darauf zugreifen kann.
Abgesehen von diesen technischen Überlegungen besteht der größte „Nachteil“ der Verschlüsselung für den Durchschnittsnutzer darin, dass Wenn Sie Ihre PIN oder Ihr Passwort vergessen und es keine Wiederherstellungsmechanismen gibt, sind die Informationen für immer verloren.Es gibt keine offizielle Hintertür: Ohne den LSKF und ohne die Möglichkeit, das synthetische Passwort abzuleiten, können CE-Schlüssel nicht wiederhergestellt werden.
Letztendlich macht dieses gesamte Framework die Festplattenverschlüsselung und den Schutz sensibler Daten auf Android wesentlich ausgefeilter, als es auf den ersten Blick erscheint. Zwischen FDE und FBE, den CE- und DE-Bereichen, der TEE, KeyMint, Gatekeeper, fscrypt, Metadatenverschlüsselung und verifiziertem BootenDas System ist so konzipiert, dass es einem unbefugten Angreifer, selbst wenn er das Gerät in seinen Händen hält und versucht, modifizierte Software zu starten oder ADB mit Root-Zugriff zu verwenden, äußerst schwerfallen wird, ohne das Passwort des Benutzers etwas Nützliches zu lesen, vorausgesetzt, der Hersteller hat die Empfehlungen befolgt und der Benutzer ergänzt dies durch eine starke Sperre, aktuelle Updates und gesunden Menschenverstand bei der Installation von Anwendungen.
