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 werden, die unabhängig voneinander entsperrt werden können.

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 ermöglichen.

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 und Direct Boot heißt. Mit Direct Boot können verschlüsselte Geräte direkt zum Sperrbildschirm hochgefahren werden. Bisher mussten Nutzer auf verschlüsselten Geräten mit Vollverschlüsselung (Full-Disk Encryption, FDE) Anmeldedaten angeben, bevor auf Daten zugegriffen werden konnte. Dadurch konnte das Smartphone nur die grundlegendsten Vorgänge ausführen. So konnten beispielsweise keine Alarme ausgelöst werden, Bedienungshilfen waren nicht verfügbar und Smartphones konnten keine Anrufe empfangen, sondern nur grundlegende Notrufnummern wählen.

Mit der Einführung der dateibasierten Verschlüsselung (File-Based Encryption, FBE) und neuer APIs, mit denen Apps über die Verschlüsselung informiert werden, können diese Apps in einem eingeschränkten Kontext ausgeführt werden. Das kann passieren, bevor Nutzer ihre Anmeldedaten angegeben haben, und schützt gleichzeitig private Nutzerinformationen.

Auf einem Gerät mit FBE hat jeder Nutzer des Geräts zwei Speicherorte, die Apps zur Verfügung stehen:

• Der Credential Encrypted (CE)-Speicher ist der Standardspeicherort und nur verfügbar, wenn der Nutzer das Gerät entsperrt hat.
• „Device Encrypted“-Speicher (DE), ein Speicherort, der sowohl im Direct Boot-Modus als auch nach dem Entsperren des Geräts durch den Nutzer verfügbar ist.

Durch diese Trennung werden Arbeitsprofile sicherer, da mehr als ein Nutzer gleichzeitig geschützt werden kann, da die Verschlüsselung nicht mehr nur auf einem Bootzeitpasswort basiert.

Die Direct Boot API ermöglicht verschlüsselungsfähigen Apps den Zugriff auf jeden dieser Bereiche. Der App-Lebenszyklus wurde geändert, um Apps zu benachrichtigen, wenn der CE-Speicher eines Nutzers entsperrt wird, nachdem er Anmeldedaten auf dem Sperrbildschirm eingegeben hat oder im Fall eines Arbeitsprofils eine Arbeitsherausforderung bereitgestellt wurde. Geräte mit Android 7.0 müssen diese neuen APIs und Lebenszyklen unterstützen, unabhängig davon, ob FBE implementiert ist. Ohne FBE sind DE- und CE-Speicher jedoch immer entsperrt.

Eine vollständige Implementierung der dateibasierten Verschlüsselung für die Dateisysteme Ext4 und F2FS ist im Android Open Source Project (AOSP) enthalten und muss nur auf Geräten aktiviert werden, die die Anforderungen erfüllen. Hersteller, die sich für die Verwendung von FBE entscheiden, können die Funktion basierend auf dem verwendeten System-on-a-Chip (SoC) optimieren.

Alle erforderlichen Pakete in AOSP wurden aktualisiert, um Direct Boot zu unterstützen. Wenn Gerätehersteller jedoch benutzerdefinierte Versionen dieser Apps verwenden, möchten sie zumindest sicherstellen, dass es Direct-Boot-kompatible Pakete gibt, die die folgenden Dienste bereitstellen:

• Telefoniedienste und Dialer
• Eingabemethode zum Eingeben von Passwörtern auf dem Sperrbildschirm

Beispiele und Quelle

Android bietet eine Referenzimplementierung der dateibasierten Verschlüsselung, in der vold (system/vold) die Funktionalität zum Verwalten von Speichergeräten und ‑volumes auf Android bereitstellt. Durch die Einführung von FBE erhält vold mehrere neue Befehle zur Unterstützung der Schlüsselverwaltung für die CE- und DE-Schlüssel mehrerer Nutzer. Zusätzlich zu den grundlegenden Änderungen zur Verwendung der dateibasierten Verschlüsselungsfunktionen im Kernel wurden viele Systempakete, einschließlich des Sperrbildschirms und der System-UI, geändert, um die Funktionen für die dateibasierte Verschlüsselung und den direkten Start zu unterstützen. Dazu gehören:

• AOSP-Dialer (packages/apps/Dialer)
• Tischuhr (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Einstellungen (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* System-Apps, die das Manifestattribut defaultToDeviceProtectedStorage verwenden

Weitere Beispiele für Apps und Dienste, die Verschlüsselung unterstützen, 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:

• Kernel-Unterstützung für Ext4- oder F2FS-Verschlüsselung.
• KeyMint (oder Keymaster 1.0 oder höher). Keymaster 0.3 wird nicht unterstützt, da es nicht die erforderlichen Funktionen bietet und keinen ausreichenden Schutz für Verschlüsselungsschlüssel gewährleistet.
• KeyMint/Keymaster und Gatekeeper müssen in einer Trusted Execution Environment (TEE) implementiert werden, um die DE-Schlüssel zu schützen. So kann ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht wurde) die DE-Schlüssel nicht einfach anfordern.
• Hardware Root of Trust und Verified Boot, die an die KeyMint-Initialisierung gebunden sind, sind erforderlich, um sicherzustellen, dass DE-Schlüssel nicht von einem nicht autorisierten Betriebssystem abgerufen werden können.

Implementierung

Apps wie Wecker, Telefon und Bedienungshilfen sollten in erster Linie gemäß der Entwicklerdokumentation zu Direct Boot (Direktstart) android:directBootAware sein.

Kernel-Unterstützung

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

CONFIG_FS_ENCRYPTION=y

Bei älteren Kernels 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 adoptable storage unterstützt oder die Metadatenverschlüsselung auf dem internen Speicher verwendet, aktivieren Sie auch die für die Metadatenverschlüsselung erforderlichen Kernelkonfigurationsoptionen, 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 Nutzerfreundlichkeit zu verbessern. Auf ARM64-basierten Geräten kann die ARMv8 CE-Beschleunigung (Cryptography Extensions) beispielsweise durch Festlegen der folgenden Kernel-Konfigurationsoptionen aktiviert werden:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Um die Leistung weiter zu verbessern und den Stromverbrauch zu senken, können Gerätehersteller auch die Implementierung von Inline-Verschlüsselungshardware in Betracht ziehen, die die Daten verschlüsselt/entschlüsselt, während sie auf dem Weg zum/vom Speichergerät sind. Die gemeinsamen Android-Kernel (Version 4.14 und höher) enthalten ein Framework, das die Verwendung von Inline-Verschlüsselung ermöglicht, wenn Hardware- und Anbieter-Treiberunterstützung verfügbar ist. 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 außerdem:

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Dateibasierte Verschlüsselung aktivieren

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

Interner Speicher

FBE wird aktiviert, indem der Option fs_mgr_flags in der fstab-Zeile 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. Sie enthält bis zu drei durch Doppelpunkte getrennte Parameter:

• Der Parameter contents_encryption_mode definiert, welcher kryptografische Algorithmus zum Verschlüsseln von Dateiinhalten verwendet wird. Sie kann entweder aes-256-xts oder adiantum sein. Seit Android 11 kann das Feld auch leer gelassen werden, um den Standardalgorithmus aes-256-xts anzugeben.
• Mit dem Parameter filenames_encryption_mode wird der kryptografische Algorithmus definiert, der zum Verschlüsseln von Dateinamen verwendet wird. Sie kann entweder aes-256-cts, aes-256-heh, adiantum oder aes-256-hctr2 sein. Wenn nichts angegeben ist, 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, der in Android 11 neu ist, ist eine Liste von Flags, die durch das Zeichen + getrennt sind. Die folgenden Flags werden unterstützt:
  • Das Flag v1 wählt Verschlüsselungsrichtlinien der Version 1 aus, das Flag v2 Verschlüsselungsrichtlinien der Version 2. Version 2-Verschlüsselungsrichtlinien verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion. Standardmäßig wird V2 verwendet, wenn das Gerät mit Android 11 oder höher eingeführt wurde (gemäß ro.product.first_api_level), und V1, wenn das Gerät mit Android 10 oder niedriger eingeführt wurde.
  • Das Flag inlinecrypt_optimized wählt ein Verschlüsselungsformat aus, das für Inline-Verschlüsselungshardware optimiert ist, die nicht effizient mit einer großen Anzahl von Schlüsseln umgehen kann. Dazu wird nur ein Verschlüsselungsschlüssel für Dateiinhalte pro CE- oder DE-Schlüssel abgeleitet und nicht einer pro Datei. Die Generierung von Initialisierungsvektoren (IVs) wird entsprechend angepasst.
  • Das Flag emmc_optimized ähnelt inlinecrypt_optimized, wählt aber auch eine Methode zur Generierung von IVs aus, die IVs auf 32 Bit begrenzt. Dieser Flag sollte nur für Inline-Verschlüsselungshardware verwendet werden, die der JEDEC eMMC v5.2-Spezifikation entspricht und daher nur 32-Bit-IVs unterstützt. Verwenden Sie auf anderer Inline-Verschlüsselungshardware stattdessen inlinecrypt_optimized. Dieses Flag sollte niemals für UFS-basierten Speicher verwendet werden, da die UFS-Spezifikation die Verwendung von 64-Bit-IVs zulässt.
  • Auf Geräten, die hardware-wrapped keys unterstützen, wird durch das Flag wrappedkey_v0 die Verwendung von hardware-wrapped keys für FBE ermöglicht. Diese Option kann nur in Kombination mit der Mount-Option inlinecrypt und entweder dem Flag inlinecrypt_optimized oder emmc_optimized verwendet werden.
  • Das Flag dusize_4k erzwingt, dass die Größe der Verschlüsselungsdateneinheit 4096 Byte beträgt, auch wenn die Dateisystemblockgröße nicht 4096 Byte beträgt. Die Größe der Verschlüsselungsdateneinheit ist die Granularität der Verschlüsselung von Dateiinhalten. Dieses Flag ist seit Android 15 verfügbar. Dieses Flag sollte nur verwendet werden, um die Verwendung von Inline-Verschlüsselungshardware zu aktivieren, die keine Dateneinheiten unterstützt, die größer als 4096 Byte sind, auf einem Gerät, das eine Seitengröße von mehr als 4096 Byte und das F2FS-Dateisystem verwendet.

Wenn Sie keine Inline-Verschlüsselungshardware verwenden, ist die empfohlene Einstellung für die meisten Geräte fileencryption=aes-256-xts. 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, indem fileencryption=adiantum festgelegt wird.

Seit Android 14 ist AES-HCTR2 der bevorzugte Modus für die Verschlüsselung von Dateinamen auf Geräten mit beschleunigten Kryptografieanweisungen. Allerdings unterstützen nur neuere Android-Kernel AES-HCTR2. In einer zukünftigen Android-Version soll dies der Standardmodus für die Verschlüsselung von Dateinamen werden. Wenn Ihr Kernel AES-HCTR2 unterstützt, kann die Dateinamenverschlüsselung durch Festlegen von filenames_encryption_mode auf aes-256-hctr2 aktiviert werden. Im einfachsten Fall wird dies mit fileencryption=aes-256-xts:aes-256-hctr2 erledigt.

Auf Geräten, die mit Android 10 oder niedriger auf den Markt gekommen sind, wird auch fileencryption=ice akzeptiert, um den Verschlüsselungsmodus für den Inhalt der Datei FSCRYPT_MODE_PRIVATE anzugeben. Dieser Modus wird von den gemeinsamen Android-Kerneln nicht implementiert, kann aber von Anbietern mit benutzerdefinierten Kernel-Patches implementiert werden. Das von diesem Modus erstellte On-Disk-Format war anbieterspezifisch. Auf Geräten, die mit Android 11 oder höher auf den Markt kommen, ist dieser Modus nicht mehr zulässig. Stattdessen muss ein Standardverschlüsselungsformat verwendet werden.

Standardmäßig werden Dateiinhalte mit der Kryptografie-API des Linux-Kernels verschlüsselt. Wenn Sie stattdessen Inline-Verschlüsselungshardware verwenden möchten, fügen Sie auch die Mount-Option 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 adaptable storage zusammen verwendet werden.

Wenn Sie die fstab-Option fileencryption für userdata angeben, werden sowohl FBE als auch die Metadatenverschlüsselung für adoptable storage automatisch aktiviert. Sie können die FBE- oder Metadatenverschlüsselungsformate auf adoptablem Speicher jedoch überschreiben, indem Sie Attribute in PRODUCT_PROPERTY_OVERRIDES festlegen.

Verwenden Sie auf Geräten, die bei Markteinführung Android 11 oder höher nutzten, die folgenden Eigenschaften:

• ro.crypto.volume.options (neu in Android 11) wählt das FBE-Verschlüsselungsformat für verwendbaren Speicher aus. Sie hat dieselbe Syntax wie das Argument für die fstab-Option fileencryption und verwendet dieselben Standardwerte. Sehen Sie sich die Empfehlungen für fileencryption oben an.
• Mit ro.crypto.volume.metadata.encryption wird das Format für die Metadatenverschlüsselung auf verwendbarem Speicher ausgewählt. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung.

Verwenden Sie auf Geräten, die mit Android 10 oder niedriger auf den Markt gekommen sind, die folgenden Eigenschaften:

• Mit ro.crypto.volume.contents_mode wird der Verschlüsselungsmodus für Inhalte ausgewählt. 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 Doppelpunkt getrennten Feld von ro.crypto.volume.options, mit der Ausnahme, dass der Standardwert auf Geräten, die mit Android 10 und niedriger auf den Markt kamen, aes-256-heh ist. Auf den meisten Geräten muss dies explizit auf aes-256-cts gesetzt werden.
• ro.crypto.fde_algorithm und ro.crypto.fde_sector_size wählen Sie das Format für die Metadatenverschlüsselung auf dem verwendbaren Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung.

In KeyMint einbinden

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

Verzeichnisse ausschließen

init wendet den System-DE-Schlüssel auf alle Verzeichnisse der obersten Ebene von /data an, mit Ausnahme von Verzeichnissen, die nicht verschlüsselt sein dürfen, z. B. das Verzeichnis, das den System-DE-Schlüssel selbst enthält, und Verzeichnisse, die Nutzer-CE- oder -DE-Verzeichnisse enthalten. Verschlüsselungsschlüssel werden rekursiv angewendet und können nicht durch Unterverzeichnisse überschrieben werden.

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

In Android 10 waren die init-Verschlüsselungsaktionen an der folgenden Stelle fest codiert:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Unter Android 9 und niedriger war der Speicherort:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Es ist möglich, Ausnahmen hinzuzufügen, um zu verhindern, dass bestimmte Verzeichnisse überhaupt verschlüsselt werden. Wenn solche Änderungen vorgenommen werden, sollte der Gerätehersteller SELinux-Richtlinien einfügen, die nur den Apps Zugriff auf das unverschlüsselte Verzeichnis gewähren, die es benötigen. Dadurch sollten alle nicht vertrauenswürdigen Apps ausgeschlossen werden.

Der einzige bekannte zulässige Anwendungsfall ist die Unterstützung von Legacy-OTA-Funktionen.

Direct Boot in System-Apps unterstützen

Apps für Direct Boot optimieren

Um die schnelle Migration von System-Apps zu erleichtern, gibt es zwei neue Attribute, die auf App-Ebene festgelegt werden können. Das Attribut defaultToDeviceProtectedStorage ist nur für System-Apps verfügbar. Das Attribut directBootAware ist für alle verfügbar.

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

Das Attribut directBootAware auf App-Ebene ist eine Kurzform, um alle Komponenten in der App als verschlüsselungsfähig zu kennzeichnen.

Das Attribut defaultToDeviceProtectedStorage leitet den Standardspeicherort der App an den DE-Speicher anstelle des CE-Speichers um. System-Apps, die dieses Flag verwenden, müssen alle im 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.

In diesem Modus sind die folgenden System-APIs verfügbar, um bei Bedarf einen Kontext zu verwalten, der durch CE-Speicher gesichert wird. Sie entsprechen ihren Device Protected-Pendants.

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

Mehrere Nutzer unterstützen

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 er ein spezieller Nutzer ist. Das ist für die Geräteverwaltung relevant.

Krypto-Apps interagieren auf folgende Weise mit Nutzern: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL ermöglichen einer App, auf alle Nutzer auf dem Gerät zuzugreifen. Diese Apps können jedoch nur auf CE-verschlüsselte Verzeichnisse für Nutzer zugreifen, die bereits entsperrt sind.

Eine App kann möglicherweise frei in allen DE-Bereichen interagieren, aber wenn 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.

Jeder Nutzer-ID für Arbeitsprofile werden außerdem zwei Schlüssel zugewiesen: DE und CE. Wenn die Arbeitsanforderung erfüllt ist, wird der Profilnutzer entsperrt und KeyMint (im TEE) kann den TEE-Schlüssel des Profils bereitstellen.

Updates verarbeiten

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher in der userdata-Partition zugreifen. Geräte, die FBE implementieren, sollten dringend OTA mit A/B-Systemupdates unterstützen. Da das OTA während des normalen Betriebs angewendet werden kann, ist keine Wiederherstellung erforderlich, um auf Daten auf dem verschlüsselten Laufwerk zuzugreifen.

Wenn Sie eine Legacy-OTA-Lösung verwenden, für die der Zugriff auf die OTA-Datei auf der Partition userdata über die Wiederherstellung erforderlich ist:

1. Erstellen Sie auf 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 obersten Verzeichnis 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 in dieses Verzeichnis lesen und schreiben können. 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 ausgeführt wird, 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.
  • ro.crypto.state muss verschlüsselt sein
• Prüfen Sie, ob ro.crypto.type vorhanden ist.
  • Prüfen Sie, ob ro.crypto.type auf file gesetzt ist.

Außerdem können Tester überprüfen, ob der Speicher des Arbeitsprofils gesperrt ist, bevor das Gerät seit dem Booten zum ersten Mal entsperrt wurde. Verwenden Sie dazu einen userdebug- oder eng-Build, legen Sie eine PIN, ein Muster oder ein Passwort für den Hauptnutzer 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 das Gerät den Headless System User Mode (die meisten Automotive-Geräte) verwendet, ist der Hauptnutzer Nutzer 10. Führen Sie also 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 also 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 zum Entschlüsseln noch nicht verfügbar ist. Wenn die Dateinamen im Klartext aufgeführt sind, stimmt etwas nicht.

Gerätehersteller werden außerdem aufgefordert, die Upstream-Linux-Tests für fscrypt auf ihren Geräten oder Kernels auszuführen. Diese Tests sind Teil der xfstests-Dateisystemtestsuite. Diese Upstream-Tests werden jedoch nicht offiziell von Android unterstützt.

AOSP-Implementierungsdetails

In diesem Abschnitt finden Sie Details zur AOSP-Implementierung und eine Beschreibung der Funktionsweise der dateibasierten 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

Die Adiantum-Verschlüsselung wird ebenfalls 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 ist veraltet und die CDD-Anforderungen für Geräte, die mit Android 11 und höher auf den Markt kommen, sind nur mit Version 2 kompatibel. Bei Version 2-Verschlüsselungsrichtlinien wird HKDF-SHA512 verwendet, um die tatsächlichen Verschlüsselungsschlüssel aus den vom Nutzerbereich bereitgestellten Schlüsseln abzuleiten.

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 der Festplatte gespeichert, mit Ausnahme des Schlüssels pro Bootvorgang, der überhaupt nicht gespeichert wird. In der folgenden Tabelle sind die Speicherorte der verschiedenen FBE-Schlüssel aufgeführt:

Wie in der Tabelle oben zu sehen ist, werden die meisten FBE-Schlüssel in Verzeichnissen gespeichert, die mit einem 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 auch eine Verschlüsselungsebene auf alle FBE-Schlüssel an. Jeder Schlüssel außer den CE-Schlüsseln für den internen Speicher wird mit AES‑256‑GCM mit einem eigenen Keystore-Schlüssel verschlüsselt, der nicht außerhalb der TEE verfügbar ist. Dadurch wird sichergestellt, dass FBE-Schlüssel nur entsperrt werden können, wenn ein vertrauenswürdiges Betriebssystem gebootet wurde, was durch den verifizierten Bootmodus erzwungen wird. Für den Keystore-Schlüssel ist auch ein Rollback-Schutz erforderlich. Dadurch können FBE-Schlüssel auf Geräten, auf denen KeyMint den Rollback-Schutz unterstützt, sicher gelöscht werden. Als Best-Effort-Fallback, wenn kein Rollback-Schutz verfügbar ist, wird der SHA-512-Hash von 16.384 zufälligen Bytes, die in der Datei secdiscardable gespeichert sind, die neben dem Schlüssel gespeichert ist, als Tag::APPLICATION_ID des Keystore-Schlüssels verwendet. Alle diese Bytes müssen wiederhergestellt werden, um einen FBE-Schlüssel wiederherzustellen.

CE-Schlüssel für den internen Speicher erhalten einen stärkeren Schutz, der dafür sorgt, dass 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 beider clientseitigen und 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 die interne Speicherung 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, wird der LSKF zuerst durch scrypt gestreckt, wobei eine Zeit von etwa 25 ms und eine Speichernutzung von etwa 2 MiB angestrebt werden.LockSettingsService Da LSKFs in der Regel kurz sind, bietet dieser Schritt normalerweise nicht viel Sicherheit. Die wichtigste Sicherheitsebene ist die unten beschriebene Secure Element (SE) oder die TEE-erzwungene Ratenbegrenzung.

Wenn das Gerät ein Secure Element (SE) hat, wird der gedehnte LSKF mit dem Weaver HAL einem zufälligen Geheimnis mit hoher Entropie zugeordnet, das im SE gespeichert ist.LockSettingsService LockSettingsService verschlüsselt das synthetische Passwort dann zweimal: zuerst mit einem Softwareschlüssel, der aus dem gedehnten LSKF und dem Weaver-Secret abgeleitet wird, und dann mit einem nicht authentifizierungsgebundenen Keystore-Schlüssel. Dadurch wird die Ratenbegrenzung von LSKF-Vermutungen durch SE erzwungen.

Wenn das Gerät keine SE hat, verwendet LockSettingsService stattdessen den gestreckten 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 secdiscardable-Datei abgeleitet wird, und dann mit einem Keystore-Schlüssel, der an die Gatekeeper-Registrierung gebunden ist. Dadurch wird die Ratenbegrenzung von LSKF-Vermutungen 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 so 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.