Dateibasierte Verschlüsselung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Android 7.0 und höher unterstützen 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 die bestmögliche und sicherste Nutzung 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 eine neue Funktion, die in Android 7.0 eingeführt wurde: 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 Full-Disk-Verschlüsselung (FDE) Anmeldedaten angeben, bevor auf Daten zugegriffen werden konnte. Das Smartphone konnte dann nur noch die grundlegendsten Funktionen ausführen. So konnten beispielsweise Wecker nicht funktionieren, Dienste zur Barrierefreiheit waren nicht verfügbar und Smartphones konnten keine Anrufe empfangen, sondern waren auf die grundlegenden Funktionen des Notrufs beschränkt.

Mit der Einführung der dateibasierten Verschlüsselung (File-Based Encryption, FBE) und neuer APIs, die Apps über die Verschlüsselung informieren, können diese Apps in einem eingeschränkten Kontext ausgeführt werden. Dies kann geschehen, bevor Nutzer ihre Anmeldedaten angegeben haben, und dabei werden private Nutzerdaten geschützt.

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 macht Arbeitsprofile sicherer, da dadurch mehrere Nutzer gleichzeitig geschützt werden können, da die Verschlüsselung nicht mehr nur auf einem Passwort zur Bootzeit 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 FBE implementiert ist oder nicht. Ohne FBE sind der DE- und CE-Speicher jedoch immer entsperrt.

Eine vollständige Implementierung der dateibasierten Verschlüsselung in 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 sie dafür sorgen, dass es mindestens Direct Boot-kompatible Pakete mit den folgenden Diensten gibt:

• Telefoniedienste und Dialer
• 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 Hauptä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 (packages/apps/Dialer)
• Tischuhr (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Einstellungen (Pakete/Apps/Einstellungen)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

Weitere Beispiele für Apps und Dienste, die die Verschlüsselung berücksichtigen, finden Sie, wenn Sie den Befehl mangrep directBootAware im Verzeichnis „frameworks“ oder „packages“ 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 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 wurde) die DE-Schlüssel nicht einfach 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.

Kernelunterstü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 Adoptive Storage unterstützt oder die Metadatenverschlüsselung auf dem internen Speicher verwendet, aktivieren Sie auch die Kernelkonfigurationsoptionen, die für die Metadatenverschlüsselung erforderlich sind, wie in der Dokumentation zur Metadatenverschlüsselung beschrieben.

Neben der funktionalen Unterstützung der Ext4- oder F2FS-Verschlüsselung sollten Gerätehersteller auch die kryptografische Beschleunigung aktivieren, um die dateibasierte Verschlüsselung zu beschleunigen und die Nutzerfreundlichkeit zu verbessern. Auf ARM64-basierten Geräten kann beispielsweise die ARMv8-CE-Beschleunigung (Cryptography Extensions) aktiviert werden, indem die folgenden Kernelkonfigurationsoptionen festgelegt 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 Android Common Kernels (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üsselungsframework kann aktiviert werden, indem Sie die folgenden Kernel-Konfigurationsoptionen festlegen:

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 Ihr Gerät eMMC-basierten Speicher verwendet, aktivieren Sie auch 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

FBE wird aktiviert, indem der Spalte fs_mgr_flags der Zeile fstab für userdata die Option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] hinzugefügt wird. Mit dieser Option wird das Verschlüsselungsformat für den 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. Er kann entweder aes-256-xts oder adiantum sein. Seit Android 11 kann das Feld auch leer bleiben, um den Standardalgorithmus anzugeben, der aes-256-xts ist.
• Der Parameter filenames_encryption_mode definiert, welcher kryptografische Algorithmus zum Verschlüsseln von Dateinamen verwendet wird. Dies kann entweder 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 aes-256-xts ist, oder adiantum, wenn contents_encryption_mode adiantum ist.
• Der Parameter flags, neu in Android 11, 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 ausgewählt, mit dem Flag v2 Verschlüsselungsrichtlinien der Version 2. Verschlüsselungsrichtlinien der Version 2 verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion. Standardmäßig ist „v2“ festgelegt, wenn das Gerät mit Android 11 oder höher gestartet wurde (wie von ro.product.first_api_level festgelegt). Andernfalls ist „v1“ festgelegt, wenn das Gerät mit Android 10 oder niedriger gestartet wurde.
  • Mit dem Flag inlinecrypt_optimized wird ein Verschlüsselungsformat ausgewählt, 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 IV (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. Verwenden Sie bei anderer Inline-Verschlüsselungshardware 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 hardwareverschlüsselte Schlüssel unterstützen, ermöglicht das Flag wrappedkey_v0 die Verwendung von hardwareverschlüsselten Schlüsseln für die FBE. Diese Option kann nur in Kombination mit der Bereitstellungsoption inlinecrypt und entweder dem Flag inlinecrypt_optimized oder emmc_optimized verwendet werden.
  • Mit dem Flag dusize_4k wird die Größe der Verschlüsselungsdateneinheit auf 4.096 Byte festgelegt, 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 Hardware für die Inline-Verschlüsselung verwenden, ist für die meisten Geräte die Einstellung fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (oder fileencryption=::inlinecrypt_optimized) empfohlen. Auf Geräten ohne AES-Beschleunigung kann Adiantum anstelle von AES verwendet werden. Dazu muss fileencryption=adiantum festgelegt werden.

Seit Android 14 ist AES-HCTR2 der bevorzugte Modus für die Verschlüsselung von Dateinamen auf Geräten mit beschleunigten kryptografischen Anweisungen. AES-HCTR2 wird jedoch nur von neueren Android-Kerneln unterstützt. In einer zukünftigen Android-Version soll er zum Standardmodus für die Verschlüsselung von Dateinamen werden. 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 geschieht dies mit fileencryption=aes-256-xts:aes-256-hctr2.

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 von diesem Modus erzeugte Laufwerkformat war anbieterspezifisch. Auf Geräten, die mit Android 11 oder höher ausgeliefert werden, ist dieser Modus nicht mehr zulässig. Stattdessen muss ein Standardverschlüsselungsformat verwendet werden.

Standardmäßig erfolgt die Verschlüsselung des Dateiinhalts mit der Kryptografie-API des Linux-Kernels. Wenn Sie stattdessen Inline-Verschlüsselungshardware verwenden möchten, fügen Sie auch die inlinecrypt-Montageoption 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 automatisch sowohl die FBE als auch die Metadatenverschlüsselung auf adoptable Storage aktiviert. Sie können die FBE- oder Metadatenverschlüsselungsformate für anpassbaren Speicher jedoch überschreiben, indem Sie Eigenschaften in PRODUCT_PROPERTY_OVERRIDES festlegen.

Verwenden Sie auf Geräten, die mit Android 11 oder höher ausgeliefert wurden, 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. Weitere Informationen finden Sie in den Empfehlungen für fileencryption oben.
• Mit ro.crypto.volume.metadata.encryption wird das Verschlüsselungsformat für Metadaten im zuweisbaren Speicher ausgewählt. Weitere Informationen finden Sie in der Dokumentation zur Verschlüsselung von Metadaten.

Verwenden Sie auf Geräten, die mit Android 10 oder niedriger ausgeliefert wurden, die folgenden Eigenschaften:

• Mit ro.crypto.volume.contents_mode wird der Verschlüsselungsmodus für den Inhalt ausgewählt. Dies entspricht dem ersten durch Doppelpunkte getrennten Feld von ro.crypto.volume.options.
• Mit ro.crypto.volume.filenames_mode wird der Verschlüsselungsmodus für Dateinamen ausgewählt. 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.
• Mit ro.crypto.fde_algorithm und ro.crypto.fde_sector_size das Format für die Metadatenverschlüsselung im zuweisbaren Speicher auswählen. Weitere Informationen finden Sie in der Dokumentation zur Verschlüsselung von Metadaten.

Keymaster einbinden

Die Keymaster HAL sollte als Teil der early_hal-Klasse gestartet werden. Das liegt daran, dass bei der FBE-Verschlüsselung Keymaster bereits in der post-fs-data-Bootphase bereit sein muss, Anfragen zu verarbeiten. In dieser Phase richtet vold die ersten Schlüssel ein.

Verzeichnisse ausschließen

init wendet den DE-Schlüssel des Systems auf alle Verzeichnisse der obersten Ebene von /data an, mit Ausnahme von Verzeichnissen, die nicht verschlüsselt werden müssen, z. B. das Verzeichnis, das den DE-Schlüssel des Systems selbst enthält, und Verzeichnisse, die CE- oder DE-Verzeichnisse von Nutzern 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 init auf Verzeichnisse anwendet, über das encryption=<action>-Argument für den Befehl mkdir in Init-Scripts gesteuert werden. Die möglichen Werte für <action> sind in der README für die Android-Init-Sprache 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 Apps ausgeschlossen werden.

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

Direct Boot in System-Apps unterstützen

Apps für Direct Boot optimieren

Um die schnelle Migration von System-Apps zu ermöglichen, gibt es zwei neue Attribute, die auf App-Ebene 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 Standardspeicherort der App an den DE-Speicher weiter, anstatt ihn auf den CE-Speicher zu verweisen. 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

Jeder Nutzer in einer Umgebung mit mehreren Nutzern erhält 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.

Kryptowährungs-Apps interagieren auf diese Weise nutzerübergreifend: Mit INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL kann eine App nutzerübergreifend 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 allen DE-Regionen frei interagieren. Wenn jedoch ein Nutzer entsperrt ist, bedeutet das 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 mit Datenträgerverschlüsselung geschützten Speicher auf der userdata-Partition zugreifen. Bei Geräten mit FBE wird dringend empfohlen, die Over-the-air-Funktion mit A/B-Systemupdates zu unterstützen. Da die Over-the-air-Aktualisierung 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 auf oberster Ebene (z. B. misc_ne).
2. Konfigurieren Sie dieses Verzeichnis auf oberster Ebene so, dass es nicht verschlüsselt wird (siehe Verzeichnisse ausschließen).
3. Erstellen Sie im übergeordneten Verzeichnis ein Verzeichnis für OTA-Pakete.
4. Fügen Sie eine SELinux-Regel und Dateikontexte hinzu, um den Zugriff auf dieses Verzeichnis und seinen 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 vorgesehen funktioniert, führen Sie zuerst die vielen CTS-Verschlüsselungstests aus, 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

Außerdem können Gerätehersteller die folgenden manuellen Tests durchführen. Auf einem Gerät mit aktivierter 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 gesetzt 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 Geräten, die nicht der Automobilbranche zuzuordnen sind) ist der Hauptnutzer „Nutzer 0“. Führen Sie daher Folgendes aus:

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

Prüfen Sie, ob die aufgeführten Dateinamen Base64-codiert sind. Das bedeutet, dass die Dateinamen verschlüsselt sind und der Schlüssel zur Entschlüsselung noch nicht verfügbar ist. Wenn die Dateinamen im Klartext aufgeführt sind, stimmt etwas nicht.

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

Details zur AOSP-Implementierung

In diesem Abschnitt finden Sie Details zur AOSP-Implementierung und eine Beschreibung der datenträgerbasierten Verschlüsselung. 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 von 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:

Schlüsselspeicherung 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:

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

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 entsperrt werden können, wenn ein vertrauenswürdiges Betriebssystem gestartet wurde, wie vom verifizierten Bootmodus erzwungen. Für den Keystore-Schlüssel wird auch eine Rollback-Resistenz angefordert, wodurch FBE-Schlüssel auf Geräten, auf denen Keymaster Rollback-Resistenz unterstützt, sicher gelöscht werden können. Als Best-Effort-Fallback für den Fall, dass die Rollback-Resistenz nicht verfügbar ist, wird der SHA-512-Hash von 16.384 Zufallsbytes verwendet, die in der Datei secdiscardable gespeichert sind, die neben dem Schlüssel gespeichert ist. Dieser Hash wird als Tag::APPLICATION_ID des Schlüsselspeicherschlüssels verwendet. Alle diese Bytes 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 von 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 er den LSKF zuerst, indem er ihn durch scrypt leitet, wobei eine Zeit von etwa 25 ms und eine Speichernutzung von etwa 2 MiB angestrebt wird. Da LSKFs in der Regel kurz sind, bietet dieser Schritt in der Regel nicht viel Sicherheit. Die Hauptsicherheitsebene ist das Secure Element (SE) oder die TEE-erzwungene Ratenbegrenzung, die unten beschrieben wird.

Wenn das Gerät ein Secure Element (SE) hat, ordnet LockSettingsService den gedehnten LSKF mithilfe der Weaver HAL einem zufälligen Geheimnis mit hoher Entropie zu, das im SE gespeichert ist. LockSettingsService verschlüsselt das synthetische Passwort dann zweimal: zuerst mit einem Softwareschlüssel, der aus dem gedehnten LSKF und dem Weaver-Secret abgeleitet wurde, und zweitens mit einem nicht authentifizierten Keystore-Schlü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 das synthetische Passwort dann zweimal: zuerst mit einem Softwareschlüssel, der aus dem gedehnten LSKF und dem Hash einer verworfenen Datei abgeleitet wird, und zweitens mit einem Schlüsselspeicherschlüssel, der an die Gatekeeper-Registrierung gebunden ist. Dadurch wird die Ratenbegrenzung von LSKF-Versuchen durch TEE erzwungen.

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 keinen LSKF hat.