Dateibasierte Verschlüsselung

Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (File-based Encryption, FBE). Bei der dateibasierten Verschlüsselung können verschiedene Dateien mit unterschiedlichen Schlüsseln verschlüsselt und unabhängig voneinander entsperrt werden.

In diesem Artikel wird beschrieben, wie Sie die dateibasierte Verschlüsselung auf neuen Geräten aktivieren und wie System-Apps die Direct Boot APIs verwenden können, um Nutzern ein optimales und sicheres Erlebnis zu bieten.

Alle Geräte, die mit Android 10 oder höher auf den Markt kommen, müssen die dateibasierte Verschlüsselung verwenden.

Direct Boot

Die dateibasierte Verschlüsselung ermöglicht die neue mit Android 7.0 eingeführte Funktion Direct Boot. Mit dem direkten Start können verschlüsselte Geräte direkt zum Sperrbildschirm starten. Bisher mussten Nutzer auf verschlüsselten Geräten mit Laufwerksverschlüsselung (Full-Disk Encryption, FDE) Anmeldedaten angeben, bevor auf Daten zugegriffen werden konnte. Dadurch konnte das Smartphone nur sehr grundlegende Vorgänge ausführen. Beispielsweise konnten Alarme nicht funktionieren, Bedienungshilfen waren nicht verfügbar und Telefone konnten keine Anrufe empfangen, sondern waren auf grundlegende Notruffunktionen beschränkt.

Mit der Einführung der dateibasierten Verschlüsselung (File-based Encryption, FBE) und den neuen APIs, die Anwendungen auf die Verschlüsselung aufmerksam machen, ist es möglich, dass diese Anwendungen in einem eingeschränkten Kontext ausgeführt werden. Dies kann passieren, bevor Nutzer ihre Anmeldedaten angegeben haben, während gleichzeitig private Nutzerdaten geschützt werden.

Auf einem Gerät mit FBE stehen jedem Nutzer zwei Speicherorte für Apps zur Verfügung:

  • Verschlüsselter Anmeldedatenspeicher (Credential Encrypted, CE), der Standardspeicherort, der nur verfügbar ist, nachdem der Nutzer das Gerät entsperrt hat.
  • Der geräteverschlüsselte Speicher ist ein Speicherort, der sowohl im Direktstartmodus als auch nach dem Entsperren des Geräts verfügbar ist.

Diese Trennung erhöht die Sicherheit von Arbeitsprofilen, da mehr als ein Nutzer gleichzeitig geschützt werden kann, da die Verschlüsselung nicht mehr ausschließlich auf einem Passwort beim Start basiert.

Die Direct Boot API ermöglicht es verschlüsselungsfreundlichen Apps, auf alle diese Bereiche zuzugreifen. Es gibt Änderungen am App-Lebenszyklus, um Apps darüber zu informieren, dass der CE-Speicher eines Nutzers entriegelt wurde, nachdem er zum ersten Mal Anmeldedaten auf dem Sperrbildschirm eingegeben hat, oder dass im Fall eines Arbeitsprofils eine Sicherheitsabfrage gestellt wurde. Geräte mit Android 7.0 müssen diese neuen APIs und Lebenszyklen unterstützen, unabhängig davon, ob sie FBE implementieren oder nicht. Ohne FBE sind der DE- und CE-Speicher jedoch immer entsperrt.

Eine vollständige Implementierung der dateibasierten Verschlüsselung auf den Dateisystemen Ext4 und F2FS wird im Android Open Source Project (AOSP) bereitgestellt und muss nur auf Geräten aktiviert werden, die die Anforderungen erfüllen. Hersteller, die FBE verwenden, können Möglichkeiten zur Optimierung der Funktion basierend auf dem verwendeten System-on-Chip (SoC) untersuchen.

Alle erforderlichen Pakete in AOSP wurden aktualisiert, damit sie Direct Boot unterstützen. Wenn Gerätehersteller jedoch benutzerdefinierte Versionen dieser Apps verwenden, müssen zumindest Pakete mit direkter Startfunktion vorhanden sein, die die folgenden Dienste bieten:

  • Telefoniedienste und Telefon
  • Eingabemethode für die Eingabe von Passwörtern auf dem Sperrbildschirm

Beispiele und Quelle

Android bietet eine Referenzimplementierung der dateibasierten Verschlüsselung, bei der vold (system/vold) die Funktionen zum Verwalten von Speichergeräten und Volumes unter Android bereitstellt. Durch die Hinzufügung von FBE bietet vold mehrere neue Befehle zur Unterstützung der Schlüsselverwaltung für die CE- und DE-Schlüssel mehrerer Nutzer. Neben den grundlegenden Änderungen zur Verwendung der dateibasierten Verschlüsselungsfunktionen im Kernel wurden viele Systempakete, einschließlich des Sperrbildschirms und der System-UI, so geändert, dass sie die FBE- und Direct Boot-Funktionen unterstützen. Dazu gehören:

  • AOSP Dialer (Pakete/Apps/Telefon)
  • Tischuhr (packages/apps/DeskClock)
  • LatinIME (Pakete/Eingabemethoden/LatinIME)*
  • Einstellungen (Pakete/Apps/Einstellungen)*
  • SystemUI (frameworks/base/packages/SystemUI)*

* System-Apps, die das defaultToDeviceProtectedStorage Manifest-Attribut verwenden

Weitere Beispiele für verschlüsselungsbewusste Anwendungen und Dienste finden Sie, wenn Sie den Befehl mangrep directBootAware im Framework- oder Paketverzeichnis des AOSP-Quellbaums ausführen.

Abhängigkeiten

Damit die AOSP-Implementierung von FBE sicher verwendet werden kann, muss ein Gerät die folgenden Abhängigkeiten erfüllen:

  • Kernelunterstützung für die Ext4- oder F2FS-Verschlüsselung.
  • Keymaster-Unterstützung mit HAL-Version 1.0 oder höher. Keymaster 0.3 wird nicht unterstützt, da es nicht die erforderlichen Funktionen bietet oder einen ausreichenden Schutz für Verschlüsselungsschlüssel gewährleistet.
  • Keymaster/Keystore und Gatekeeper müssen in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) implementiert werden, um die DE-Schlüssel zu schützen, damit ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht ist) nicht einfach die DE-Schlüssel anfordern kann.
  • Hardware Root of Trust und Verified Boot, die an die Keymaster-Initialisierung gebunden sind, sind erforderlich, damit DE-Schlüssel nicht von einem nicht autorisierten Betriebssystem zugänglich sind.

Implementierung

Vor allem Apps wie Wecker, Telefon und Bedienungshilfen sollten gemäß der Entwicklerdokumentation zu Direct Boot die Eigenschaft „android:directBootAware“ haben.

Kernel-Unterstützung

Kernelunterstützung für die Ext4- und F2FS-Verschlüsselung ist in den Android Common Kernels ab Version 3.18 verfügbar. So aktivieren Sie die Funktion in einem Kernel der Version 5.1 oder höher: 

CONFIG_FS_ENCRYPTION=y

Bei älteren Kerneln verwenden Sie CONFIG_EXT4_ENCRYPTION=y, wenn das userdata-Dateisystem Ihres Geräts Ext4 ist, oder CONFIG_F2FS_FS_ENCRYPTION=y, wenn das userdata-Dateisystem Ihres Geräts F2FS ist.

Wenn Ihr Gerät zulässigen Speicher unterstützt oder die Metadatenverschlüsselung im internen Speicher verwendet, aktivieren Sie auch die für die Metadatenverschlüsselung erforderlichen Kernel-Konfigurationsoptionen, wie in der Dokumentation zur Metadatenverschlüsselung beschrieben.

Neben der funktionalen Unterstützung für die Ext4- oder F2FS-Verschlüsselung sollten Gerätehersteller auch die kryptografische Beschleunigung aktivieren, um die dateibasierte Verschlüsselung zu beschleunigen und die Nutzererfahrung zu verbessern. Auf ARM64-basierten Geräten kann die ARMv8-CE-Beschleunigung (Cryptography Extensions) beispielsweise durch Festlegen der folgenden Kernelkonfigurationsoptionen aktiviert werden: 

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Um die Leistung weiter zu verbessern und den Energieverbrauch zu senken, können Gerätehersteller auch Inline-Verschlüsselungshardware implementieren, die die Daten auf dem Weg zum/vom Speichergerät verschlüsselt/entschlüsselt. Die gängigen Android-Kernel (Version 4.14 und höher) enthalten ein Framework, das die Inline-Verschlüsselung ermöglicht, wenn Hardware- und Anbietertreiber unterstützt werden. Das Inline-Verschlüsselungs-Framework kann durch Festlegen der folgenden Kernel-Konfigurationsoptionen aktiviert werden: 

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Wenn Ihr Gerät UFS-basierten Speicher verwendet, aktivieren Sie auch Folgendes: 

CONFIG_SCSI_UFS_CRYPTO=y

Wenn auf Ihrem Gerät eMMC-basierter Speicher verwendet wird, aktivieren Sie außerdem Folgendes: 

CONFIG_MMC_CRYPTO=y

Dateibasierte Verschlüsselung aktivieren

Wenn Sie die FBE auf einem Gerät aktivieren möchten, müssen Sie sie auch auf dem internen Speicher (userdata) aktivieren. Dadurch wird die FBE auch automatisch für den anpassbaren Speicher aktiviert. Das Verschlüsselungsformat für den anpassbaren Speicher kann bei Bedarf jedoch überschrieben werden.

Interner Speicher

Zum Aktivieren von FBE wird die Option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] in die Spalte fs_mgr_flags der Zeile fstab für userdata eingefügt. Mit dieser Option wird das Verschlüsselungsformat im internen Speicher definiert. Er enthält bis zu drei durch Doppelpunkte getrennte Parameter:

  • Der Parameter contents_encryption_mode definiert, welcher kryptografische Algorithmus zum Verschlüsseln des Dateiinhalts verwendet wird. Die Beziehung kann entweder aes-256-xts oder adiantum sein. Seit Android 11 kann es auch leer bleiben, um den Standardalgorithmus anzugeben: aes-256-xts.
  • Der Parameter filenames_encryption_mode definiert, welcher kryptografische Algorithmus zum Verschlüsseln von Dateinamen verwendet wird. Das kann aes-256-cts, aes-256-heh, adiantum oder aes-256-hctr2 sein. Wenn nicht angegeben, wird standardmäßig aes-256-cts verwendet, wenn contents_encryption_mode gleich aes-256-xts ist, oder adiantum, wenn contents_encryption_mode gleich adiantum ist.
  • Der in Android 11 neu eingeführte Parameter flags ist eine Liste von Flags, die durch das Zeichen + getrennt sind. Die folgenden Flags werden unterstützt:
    • Mit dem Flag v1 werden Verschlüsselungsrichtlinien der Version 1 und mit dem Flag v2 die Verschlüsselungsrichtlinien der Version 2 ausgewählt. Verschlüsselungsrichtlinien der Version 2 verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion. Die Standardeinstellung ist v2, wenn das Gerät unter Android 11 oder höher (wie durch ro.product.first_api_level festgelegt) gestartet wurde, oder v1, wenn das Gerät unter Android 10 oder niedriger gestartet wurde.
    • Das Flag inlinecrypt_optimized wählt ein Verschlüsselungsformat aus, das für Inline-Verschlüsselungshardware optimiert ist, die eine große Anzahl von Schlüsseln nicht effizient verarbeitet. Dazu wird nur ein Dateiinhaltsverschlüsselungsschlüssel pro CE- oder DE-Schlüssel abgeleitet, anstatt einer pro Datei. Die Generierung von IVs (Initialisierungsvektoren) wird entsprechend angepasst.
    • Das Flag emmc_optimized ähnelt inlinecrypt_optimized, wählt aber auch eine IV-Generierungsmethode aus, die IVs auf 32 Bit begrenzt. Dieses Flag sollte nur auf Inline-Verschlüsselungshardware verwendet werden, die der JEDEC eMMC v5.2-Spezifikation entspricht und daher nur 32‑Bit-IVs unterstützt. Auf anderer Inline-Verschlüsselungshardware verwenden Sie stattdessen inlinecrypt_optimized. Dieses Flag sollte niemals für UFS-basierten Speicher verwendet werden. Die UFS-Spezifikation erlaubt die Verwendung von 64‑Bit-IVs.
    • Auf Geräten, die hardwareverpackte Schlüssel unterstützen, ermöglicht das Flag wrappedkey_v0 die Verwendung von hardwareverpackten Schlüsseln für FBE. Diese Option kann nur in Kombination mit der Bereitstellungsoption inlinecrypt und entweder dem Flag inlinecrypt_optimized oder emmc_optimized verwendet werden.
    • Das Flag dusize_4k erzwingt eine Größe der Verschlüsselungsdateneinheit mit 4.096 Byte, auch wenn die Blockgröße des Dateisystems nicht 4.096 Byte beträgt. Die Größe der Verschlüsselungsdateneinheit ist die Granularität der Verschlüsselung des Dateiinhalts. Dieses Flag ist seit Android 15 verfügbar. Dieses Flag sollte nur verwendet werden, um die Verwendung von Inline-Verschlüsselungshardware zu ermöglichen, die keine Dateneinheiten größer als 4.096 Byte unterstützt, auf einem Gerät, das eine Seitengröße von mehr als 4.096 Byte und das Dateisystem f2fs verwendet.

Wenn Sie keine Inline-Verschlüsselungshardware verwenden, ist fileencryption=aes-256-xts die empfohlene Einstellung für die meisten Geräte. Wenn Sie Inline-Verschlüsselungshardware verwenden, ist die empfohlene Einstellung für die meisten Geräte fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (oder gleichwertig fileencryption=::inlinecrypt_optimized). Auf Geräten ohne AES-Beschleunigung kann Adiantum anstelle von AES verwendet werden. Dazu legen Sie fileencryption=adiantum fest.

Seit Android 14 ist AES-HCTR2 der bevorzugte Modus für die Verschlüsselung von Dateinamen auf Geräten mit beschleunigten Kryptografieanweisungen. AES-HCTR2 wird jedoch nur von neueren Android-Kerneln unterstützt. Für eine zukünftige Android-Version ist geplant, diese Funktion zum Standardmodus für die Verschlüsselung von Dateinamen zu machen. Wenn Ihr Kernel AES-HCTR2 unterstützt, kann die Verschlüsselung von Dateinamen aktiviert werden, indem Sie filenames_encryption_mode auf aes-256-hctr2 festlegen. Im einfachsten Fall würde dies mit fileencryption=aes-256-xts:aes-256-hctr2 geschehen.

Auf Geräten, die mit Android 10 oder niedriger ausgeliefert wurden, kann auch fileencryption=ice verwendet werden, um die Verwendung des Verschlüsselungsmodus für den Dateiinhalt FSCRYPT_MODE_PRIVATE anzugeben. Dieser Modus wird von den Android Common Kernels nicht implementiert, kann aber von Anbietern mit benutzerdefinierten Kernel-Patches implementiert werden. Das in diesem Modus erstellte On-Disk-Format war anbieterspezifisch. Auf Geräten mit Android 11 oder höher ist dieser Modus nicht mehr zulässig. Stattdessen muss ein Standardverschlüsselungsformat verwendet werden.

Standardmäßig erfolgt die Verschlüsselung von Dateiinhalten mit der Cryptography API des Linux-Kernels. Wenn Sie stattdessen Inline-Verschlüsselungshardware verwenden möchten, fügen Sie auch die Bereitstellungsoption inlinecrypt hinzu. Eine vollständige fstab-Zeile könnte beispielsweise so aussehen: 

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Verwendbarer Speicher

Seit Android 9 können FBE und adaptiver Speicher zusammen verwendet werden.

Wenn Sie die fstab-Option fileencryption für userdata angeben, werden auch die FBE- und die Metadatenverschlüsselung für zulässigen Speicher automatisch aktiviert. Sie können die FBE- oder Metadatenverschlüsselungsformate für den anpassbaren Speicher jedoch überschreiben, indem Sie Eigenschaften in PRODUCT_PROPERTY_OVERRIDES festlegen.

Auf Geräten, die mit Android 11 oder höher auf den Markt gebracht wurden, verwende die folgenden Eigenschaften:

  • ro.crypto.volume.options (neu in Android 11) wählt das FBE-Verschlüsselungsformat auf dem zuweisbaren Speicher aus. Sie hat dieselbe Syntax wie das Argument für die fileencryption-Fstab-Option und verwendet dieselben Standardwerte. Informationen zur Verwendung finden Sie in den Empfehlungen für fileencryption oben.
  • ro.crypto.volume.metadata.encryption wählt das Metadatenverschlüsselungsformat für verwendbare Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Verschlüsselung von Metadaten.

Auf Geräten, die mit Android 10 oder niedriger auf den Markt gebracht wurden, verwende die folgenden Eigenschaften:

  • ro.crypto.volume.contents_mode wählt den Modus für die Inhaltsverschlüsselung aus. Dies entspricht dem ersten durch Doppelpunkte getrennten Feld von ro.crypto.volume.options.
  • ro.crypto.volume.filenames_mode wählt den Verschlüsselungsmodus für Dateinamen aus. Dies entspricht dem zweiten durch Doppelpunkte getrennten Feld von ro.crypto.volume.options, mit der Ausnahme, dass auf Geräten, die mit Android 10 oder niedriger ausgeliefert wurden, standardmäßig aes-256-heh verwendet wird. Auf den meisten Geräten muss dies explizit auf aes-256-cts überschrieben werden.
  • ro.crypto.fde_algorithm und ro.crypto.fde_sector_size wählen das Metadatenverschlüsselungsformat für zulässigen Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung.

In Keymaster einbinden

Der Keymaster HAL sollte als Teil der early_hal-Klasse gestartet werden. Dies liegt daran, dass FBE erfordert, dass der Keymaster zur Verarbeitung von Anfragen in der post-fs-data-Bootphase bereit ist, in der vold die anfänglichen Schlüssel einrichtet.

Verzeichnisse ausschließen

init wendet den System-DE-Schlüssel auf alle Verzeichnisse der obersten Ebene von /data an, mit Ausnahme von Verzeichnissen, die unverschlüsselt sein müssen, wie das Verzeichnis, das den DE-Schlüssel des Systems selbst enthält, und Verzeichnisse, die CE- oder DE-Verzeichnisse des Nutzers enthalten. Verschlüsselungsschlüssel werden rekursiv angewendet und können nicht von Unterverzeichnissen überschrieben werden.

Unter Android 11 und höher kann der Schlüssel, der für Verzeichnisse gilt, mit dem encryption=<action>-Argument für den Befehl mkdir in Init-Scripts gesteuert werden. Die möglichen Werte von <action> sind in der README-Datei für die Android-Initialisierungssprache dokumentiert.

In Android 10 wurden die init-Verschlüsselungsaktionen an folgender Stelle hartcodiert: 

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Unter Android 9 und niedriger war der Standort: 

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Sie können Ausnahmen hinzufügen, um zu verhindern, dass bestimmte Verzeichnisse überhaupt verschlüsselt werden. Wenn solche Änderungen vorgenommen werden, sollte der Gerätehersteller SELinux-Richtlinien einbinden, die nur den Apps Zugriff gewähren, die das unverschlüsselte Verzeichnis verwenden müssen. Dadurch sollten alle nicht vertrauenswürdigen Anwendungen ausgeschlossen werden.

Der einzige bekannte zulässige Anwendungsfall hierfür ist die Unterstützung alter OTA-Funktionen.

Unterstützung von Direct Boot in System-Apps

Apps auf den Direct Boot-Modus aufmerksam machen

Für eine schnelle Migration von Systemanwendungen gibt es zwei neue Attribute, die auf Anwendungsebene festgelegt werden können. Das defaultToDeviceProtectedStorage-Attribut ist nur für System-Apps verfügbar. Das directBootAware-Attribut ist für alle verfügbar. 

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

Das Attribut directBootAware auf App-Ebene dient als Kurzform, um alle Komponenten in der App als verschlüsselungsbewusst zu kennzeichnen.

Das Attribut defaultToDeviceProtectedStorage leitet den standardmäßigen App-Speicherort so weiter, dass er auf den DE-Speicher und nicht auf den CE-Speicher verweist. System-Apps, die dieses Flag verwenden, müssen alle am Standardspeicherort gespeicherten Daten sorgfältig prüfen und die Pfade sensibler Daten so ändern, dass der CE-Speicher verwendet wird. Gerätehersteller, die diese Option verwenden, sollten die gespeicherten Daten sorgfältig prüfen, um sicherzustellen, dass sie keine personenbezogenen Daten enthalten.

Wenn Sie in diesem Modus arbeiten, sind die folgenden System-APIs verfügbar, um bei Bedarf einen vom CE-Speicher unterstützten Kontext explizit zu verwalten. Sie entsprechen ihren gerätegeschützten Pendants.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Unterstützung mehrerer Nutzer

In einer Umgebung mit mehreren Nutzern erhält jeder Nutzer einen separaten Verschlüsselungsschlüssel. Jeder Nutzer erhält zwei Schlüssel: einen DE- und einen CE-Schlüssel. Nutzer 0 muss sich zuerst auf dem Gerät anmelden, da es sich um einen speziellen Nutzer handelt. Dies ist für die Geräteverwaltung relevant.

Kryptografische Apps interagieren auf diese Weise zwischen Nutzern: Mit INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL kann eine App für alle Nutzer auf dem Gerät agieren. Diese Apps können jedoch nur auf CE-verschlüsselte Verzeichnisse für Nutzer zugreifen, die bereits entsperrt sind.

Eine App kann möglicherweise in den DE-Bereichen frei interagieren, aber ein Nutzer, der entsperrt ist, bedeutet nicht, dass alle Nutzer auf dem Gerät entsperrt sind. Die App sollte diesen Status prüfen, bevor sie versucht, auf diese Bereiche zuzugreifen.

Jede Arbeitsprofil-Nutzer-ID erhält außerdem zwei Schlüssel: DE und CE. Wenn die Arbeitsanfrage erfüllt ist, wird der Profilnutzer entsperrt und der Keymaster (in TEE) kann den TEE-Schlüssel des Profils bereitstellen.

Updates verarbeiten

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher auf der Nutzerdatenpartition zugreifen. Geräten, auf denen FBE implementiert ist, wird dringend empfohlen, OTA mit A/B-Systemupdates zu unterstützen. Da das Over-the-air-Update während des normalen Betriebs angewendet werden kann, ist keine Wiederherstellung erforderlich, um auf Daten auf dem verschlüsselten Laufwerk zuzugreifen.

Wenn Sie eine ältere OTA-Lösung verwenden, für die eine Wiederherstellung erforderlich ist, um auf die OTA-Datei in der userdata-Partition zuzugreifen:

  1. Erstellen Sie in der Partition userdata ein Verzeichnis der obersten Ebene (z. B. misc_ne).
  2. Konfigurieren Sie dieses Verzeichnis der obersten Ebene als unverschlüsselt (siehe Verzeichnisse ausschließen).
  3. Erstellen Sie im Verzeichnis der obersten Ebene ein Verzeichnis zum Speichern von OTA-Paketen.
  4. Fügen Sie eine SELinux-Regel und Dateikontexte hinzu, um den Zugriff auf dieses Verzeichnis und dessen Inhalt zu steuern. Nur der Prozess oder die Apps, die OTA-Updates erhalten, sollten Lese- und Schreibzugriff auf dieses Verzeichnis haben. Keine andere App oder kein anderer Prozess sollte Zugriff auf dieses Verzeichnis haben.

Zertifizierungsstufe

Damit die implementierte Version der Funktion wie beabsichtigt funktioniert, sollten Sie zuerst die vielen CTS-Verschlüsselungstests ausführen, z. B. DirectBootHostTest und EncryptionTest.

Wenn auf dem Gerät Android 11 oder höher installiert ist, führen Sie auch vts_kernel_encryption_test aus: 

atest vts_kernel_encryption_test

oder:

vts-tradefed run vts -m vts_kernel_encryption_test

Darüber hinaus können Gerätehersteller die folgenden manuellen Tests durchführen. Auf einem Gerät mit aktiviertem FBE:

  • Prüfen Sie, ob ro.crypto.state vorhanden ist.
    • Prüfen, ob ro.crypto.state verschlüsselt ist
  • Prüfen Sie, ob ro.crypto.type vorhanden ist.
    • Achten Sie darauf, dass ro.crypto.type auf file festgelegt ist

Außerdem können Tester prüfen, ob der CE-Speicher gesperrt ist, bevor das Gerät zum ersten Mal seit dem Start entsperrt wurde. Verwenden Sie dazu eine userdebug- oder eng-Buildversion, legen Sie für den Hauptnutzer eine PIN, ein Muster oder ein Passwort fest und starten Sie das Gerät neu. Führen Sie vor dem Entsperren des Geräts den folgenden Befehl aus, um den CE-Speicher des Hauptnutzers zu prüfen. Wenn auf dem Gerät der Nutzermodus des headless-Systems verwendet wird (die meisten Automotive-Geräte), ist Nutzer 10 der Hauptnutzer. Führen Sie daher Folgendes aus: 

adb root; adb shell ls /data/user/10

Auf anderen Geräten (den meisten Nicht-Automotive-Geräten) ist der Hauptnutzer Nutzer 0. Führen Sie daher folgenden Befehl aus:

adb root; adb shell ls /data/user/0

Die aufgeführten Dateinamen müssen Base64-codiert sein. Dies weist darauf hin, dass die Dateinamen verschlüsselt sind und der Schlüssel zu ihrer Entschlüsselung noch nicht verfügbar ist. Wenn die Dateinamen im Klartext aufgeführt sind, ist ein Fehler aufgetreten.

Geräteherstellern wird außerdem empfohlen, die vorgelagerten Linux-Tests für fscrypt auf ihren Geräten oder Kerneln auszuführen. Diese Tests sind Teil der Testsuite des xfstests-Dateisystems. Diese vorgelagerten Tests werden jedoch nicht offiziell von Android unterstützt.

Details zur AOSP-Implementierung

Dieser Abschnitt enthält Details zur AOSP-Implementierung und beschreibt, wie die dateibasierte Verschlüsselung funktioniert. Gerätehersteller sollten hier keine Änderungen vornehmen müssen, um FBE und Direct Boot auf ihren Geräten zu verwenden.

fsCrypt-Verschlüsselung

Die AOSP-Implementierung verwendet die "fscrypt"-Verschlüsselung (unterstützt von ext4 und f2fs) im Kernel und ist normalerweise so konfiguriert:

  • Dateiinhalte mit AES-256 im XTS-Modus verschlüsseln
  • Dateinamen mit AES-256 im CBC-CTS-Modus verschlüsseln

Auch die Adiantum-Verschlüsselung wird unterstützt. Wenn die Adiantum-Verschlüsselung aktiviert ist, werden sowohl Dateiinhalte als auch Dateinamen mit Adiantum verschlüsselt.

fscrypt unterstützt zwei Versionen der Verschlüsselungsrichtlinien: Version 1 und Version 2. Version 1 wird eingestellt und die CDD-Anforderungen für Geräte, die mit Android 11 oder höher auf den Markt gebracht werden, sind nur mit Version 2 kompatibel. Bei Verschlüsselungsrichtlinien der Version 2 werden die tatsächlichen Verschlüsselungsschlüssel mit HKDF-SHA512 aus den vom Nutzerbereich bereitgestellten Schlüsseln abgeleitet.

Weitere Informationen zu fscrypt finden Sie in der Upstream-Kernel-Dokumentation.

Speicherklassen

In der folgenden Tabelle sind die FBE-Schlüssel und die Verzeichnisse, die sie schützen, genauer aufgeführt:

Speicherklasse Beschreibung Verzeichnisse
Unverschlüsselt Verzeichnisse in /data, die nicht oder nicht durch FBE geschützt werden können oder müssen Auf Geräten, auf denen die Metadatenverschlüsselung verwendet wird, sind diese Verzeichnisse nicht wirklich unverschlüsselt, sondern werden durch den Metadatenverschlüsselungsschlüssel geschützt, der dem System-DE entspricht.
  • /data/apex, ausgenommen /data/apex/decompressed und /data/apex/ota_reserved, die System-DEs sind
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Alle Verzeichnisse, deren Unterverzeichnisse unterschiedliche FBE-Schlüssel verwenden. Da beispielsweise jedes /data/user/${user_id}-Verzeichnis einen nutzerspezifischen Schlüssel verwendet, verwendet /data/user selbst keinen Schlüssel.
System DE Geräteverschlüsselte Daten, die nicht an einen bestimmten Nutzer gebunden sind
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • Alle anderen Unterverzeichnisse von /data, die in dieser Tabelle nicht als solche mit einer anderen Klasse angegeben sind
Pro Bootmodus Vorübergehende Systemdateien, die nach einem Neustart nicht erhalten bleiben müssen /data/per_boot
CE für Nutzer (intern) Nutzerspezifische, mit Anmeldedaten verschlüsselte Daten im internen Speicher
  • /data/data (Alias von /data/user/0)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Nutzer DE (intern) Nutzerspezifisch verschlüsselte Daten auf dem internen Speicher
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
Nutzer-CE (anpassbar) Nutzerspezifische, mit Anmeldedaten verschlüsselte Daten auf adoptable storage
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
Nutzer DE (adaptierbar) Gerätespezifische nutzerspezifische Daten auf akzeptablem Speicher
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

Schlüsselspeicher und -schutz

Alle FBE-Schlüssel werden von vold verwaltet und verschlüsselt auf dem Laufwerk gespeichert, mit Ausnahme des Schlüssels pro Boot, der gar nicht gespeichert wird. In der folgenden Tabelle sind die Speicherorte der verschiedenen FBE-Schlüssel aufgeführt:

Schlüsseltyp Speicherort des Schlüssels Speicherklasse des Schlüsselstandorts
System-DE-Schlüssel /data/unencrypted Unverschlüsselt
CE-Schlüssel für Nutzer (intern) /data/misc/vold/user_keys/ce/${user_id} System DE
DE (interne) Nutzerschlüssel /data/misc/vold/user_keys/de/${user_id} System DE
CE-Schlüssel (adaptierbar) für Nutzer /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Nutzer-CE (intern)
Nutzer-DE-Schlüssel (akzeptabel) /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Nutzer DE (intern)

Wie in der vorherigen Tabelle gezeigt, werden die meisten FBE-Schlüssel in Verzeichnissen gespeichert, die mit einem anderen FBE-Schlüssel verschlüsselt werden. Schlüssel können erst entsperrt werden, wenn die Speicherklasse entsperrt wurde, die sie enthält.

vold wendet außerdem eine Verschlüsselungsebene auf alle FBE-Schlüssel an. Alle Schlüssel außer CE-Schlüsseln für den internen Speicher werden mit AES-256-GCM mit einem eigenen Keystore-Schlüssel verschlüsselt, der nicht außerhalb des TEE freigegeben wird. So wird sichergestellt, dass FBE-Schlüssel nur dann entsperrt werden können, wenn ein vertrauenswürdiges Betriebssystem gestartet wurde, wie vom verifizierten Bootmodus erzwungen. Für den Keystore-Schlüssel wird auch Rollback-Resistenz angefordert. Dadurch können FBE-Schlüssel auf Geräten, auf denen Keymaster Rollback-Resistenz unterstützt, sicher gelöscht werden. Als Best-Effort-Fallback für den Fall, dass der Rollback-Schutz nicht verfügbar ist, wird der SHA-512-Hash von 16.384 zufälligen Byte, die zusammen mit dem Schlüssel in der Datei secdiscardable gespeichert sind, als App-ID-Tag des Schlüsselspeicherschlüssels verwendet. Alle diese Byte müssen wiederhergestellt werden, um einen FBE-Schlüssel wiederherzustellen.

CE-Schlüssel für den internen Speicher werden stärker geschützt, damit sie nicht ohne Kenntnis des Lock Screen Knowledge Factor (LSKF) (PIN, Muster oder Passwort) des Nutzers, eines sicheren Tokens zum Zurücksetzen des Sicherheitscodes oder sowohl der client- als auch der serverseitigen Schlüssel für einen Resume-on-Reboot-Vorgang entsperrt werden können. Tokens zum Zurücksetzen des Sicherheitscodes dürfen nur für Arbeitsprofile und vollständig verwaltete Geräte erstellt werden.

Dazu verschlüsselt vold jeden CE-Schlüssel für den internen Speicher mit einem AES-256-GCM-Schlüssel, der aus dem synthetischen Passwort des Nutzers abgeleitet wird. Das synthetische Passwort ist ein unveränderliches kryptografisches Secret mit hoher Entropie, das für jeden Nutzer zufällig generiert wird. LockSettingsService in system_server verwaltet das synthetische Passwort und die Art und Weise, wie es geschützt wird.

Um das synthetische Passwort mit dem LSKF zu schützen, LockSettingsServicestreckt scrypt den LSKF zuerst, indem er ihn durch das System führt. Dabei wird eine Zeit von etwa 25 ms und eine Speichernutzung von etwa 2 MiB angestrebt. Da LSKFs in der Regel kurz sind, bietet dieser Schritt in der Regel nicht viel Sicherheit. Die wichtigste Sicherheitsebene ist das Secure Element (SE) oder TEE-erzwungene Ratenbegrenzung, wie unten beschrieben.

Wenn das Gerät ein Secure Element (SE) hat, ordnet LockSettingsService das erweiterte LSKF einem zufälligen Secret mit hoher Entropie zu, das mithilfe des Weaver HAL im SE gespeichert wird. LockSettingsService verschlüsselt dann das synthetische Passwort zweimal: zuerst mit einem Softwareschlüssel, der aus dem erweiterten LSKF und dem Weaver-Secret abgeleitet wurde, und dann mit einem nicht authentifizierenden Schlüsselspeicherschlüssel. Dadurch wird die Ratenbegrenzung von LSKF-Versuchen durch den Sicherheitsabstand erzwungen.

Wenn das Gerät kein SE hat, verwendet LockSettingsService stattdessen den gedehnten LSKF als Gatekeeper-Passwort. LockSettingsService verschlüsselt dann das synthetische Passwort zweimal: zuerst mit einem Softwareschlüssel, der aus dem erweiterten LSKF und dem Hash einer selektierbaren Datei abgeleitet wird, und dann mit einem Schlüsselspeicherschlüssel, der an die Gatekeeper-Registrierung auth-gebunden ist. Dies ermöglicht eine von TEE erzwungene Ratenbegrenzung für LSKF-Vermutungen.

Wenn der LSKF geändert wird, löscht LockSettingsService alle Informationen, die mit der Bindung des synthetischen Passworts an den alten LSKF verknüpft sind. Auf Geräten, die Weaver- oder Rollback-resistente Keystore-Schlüssel unterstützen, wird dadurch das sichere Löschen der alten Bindung gewährleistet. Aus diesem Grund werden die hier beschriebenen Schutzmaßnahmen auch dann angewendet, wenn der Nutzer kein LSKF hat.