Diese Seite wurde von der Cloud Translation API übersetzt.

Dateibasierte Verschlüsselung

Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (FBE). Die dateibasierte Verschlüsselung ermöglicht die Verschlüsselung verschiedener Dateien mit unterschiedlichen Schlüsseln, die unabhängig voneinander entsperrt werden können.

Dieser Artikel beschreibt, wie Sie die dateibasierte Verschlüsselung auf neuen Geräten aktivieren und wie Systemanwendungen die Direct-Boot-APIs verwenden können, um Benutzern die bestmögliche und sicherste Erfahrung zu bieten.

Direkter Start

Die dateibasierte Verschlüsselung ermöglicht eine neue Funktion, die in Android 7.0 namens Direct Boot eingeführt wurde. Direct Boot ermöglicht es verschlüsselten Geräten, direkt zum Sperrbildschirm zu booten. Zuvor mussten Benutzer auf verschlüsselten Geräten mit Full-Disk-Verschlüsselung (FDE) Anmeldeinformationen eingeben, bevor auf Daten zugegriffen werden konnte, wodurch das Telefon daran gehindert wurde, alle außer den grundlegendsten Vorgängen auszuführen. Beispielsweise konnten Alarme nicht funktionieren, Barrierefreiheitsdienste waren nicht verfügbar und Telefone konnten keine Anrufe entgegennehmen, sondern waren nur auf grundlegende Notruffunktionen beschränkt.

Mit der Einführung der dateibasierten Verschlüsselung (FBE) und neuer APIs, um Anwendungen auf die Verschlüsselung aufmerksam zu machen, können diese Apps in einem begrenzten Kontext betrieben werden. Dies kann passieren, bevor Benutzer ihre Anmeldeinformationen angegeben haben, während private Benutzerinformationen weiterhin geschützt sind.

Auf einem FBE-fähigen Gerät stehen jedem Benutzer des Geräts zwei Speicherorte für Anwendungen zur Verfügung:

Credential Encrypted (CE)-Speicher, der der Standardspeicherort ist und nur verfügbar ist, nachdem der Benutzer das Gerät entsperrt hat.
Device Encrypted (DE)-Speicher, bei dem es sich um einen Speicherort handelt, der sowohl während des direkten Startmodus als auch nach dem Entsperren des Geräts durch den Benutzer verfügbar ist.

Diese Trennung macht Arbeitsprofile sicherer, da mehr als ein Benutzer gleichzeitig geschützt werden kann, da die Verschlüsselung nicht mehr nur auf einem Boot-Passwort basiert.

Die Direct Boot API ermöglicht verschlüsselungsfähigen Anwendungen den Zugriff auf jeden dieser Bereiche. Es gibt Änderungen am Anwendungslebenszyklus, um der Notwendigkeit gerecht zu werden, Anwendungen zu benachrichtigen, wenn der CE-Speicher eines Benutzers als Reaktion auf die erste Eingabe von Anmeldeinformationen auf dem Sperrbildschirm entsperrt wird oder wenn das Arbeitsprofil eine Arbeitsherausforderung bereitstellt . 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 befinden sich DE- und CE-Speicher jedoch immer im entsperrten Zustand.

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 sich für die Verwendung von FBE entscheiden, möchten möglicherweise Möglichkeiten zur Optimierung der Funktion basierend auf dem verwendeten System-on-Chip (SoC) erkunden.

Alle notwendigen Pakete in AOSP wurden aktualisiert, um Direct-Boot-fähig zu sein. Wenn Gerätehersteller jedoch angepasste Versionen dieser Apps verwenden, sollten sie sicherstellen, dass es mindestens Direct-Boot-fähige Pakete gibt, die die folgenden Dienste bereitstellen:

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, in der vold ( system/vold ) die Funktionalität zum Verwalten von Speichergeräten und Volumes auf Android bereitstellt. Das Hinzufügen von FBE stellt vold mehrere neue Befehle zur Verfügung, um die Schlüsselverwaltung für die CE- und DE-Schlüssel mehrerer Benutzer zu unterstützen. Zusätzlich zu den Kernänderungen zur Verwendung der dateibasierten Verschlüsselungsfunktionen im Kernel wurden viele Systempakete, einschließlich des Sperrbildschirms und der SystemUI, modifiziert, um die FBE- und Direct-Boot-Funktionen zu unterstützen. Diese schließen ein:

AOSP Dialer (Pakete/Apps/Dialer)
Tischuhr (Pakete/Apps/DeskClock)
LatinIME (Pakete/Eingabemethoden/LatinIME)*
Einstellungs-App (Pakete/Apps/Einstellungen)*
SystemUI (Frameworks/Basis/Pakete/SystemUI)*

* Systemanwendungen, die das Manifestattribut defaultToDeviceProtectedStorage verwenden

Weitere Beispiele für verschlüsselungsfähige Anwendungen und Dienste finden Sie, indem Sie den Befehl mangrep directBootAware im Verzeichnis frameworks oder packages des AOSP-Quellbaums ausführen.

Abhängigkeiten

Um die AOSP-Implementierung von FBE sicher zu verwenden, muss ein Gerät die folgenden Abhängigkeiten erfüllen:

Kernel-Unterstützung für Ext4-Verschlüsselung oder F2FS-Verschlüsselung.
Keymaster-Unterstützung mit einer HAL-Version 1.0 oder 2.0. Es gibt keine Unterstützung für Keymaster 0.3, da dies nicht die erforderlichen Funktionen bietet oder keinen ausreichenden Schutz für Verschlüsselungsschlüssel gewährleistet.
Keymaster/ Keystore und Gatekeeper müssen in einer Trusted Execution Environment (TEE) implementiert werden, um Schutz für die DE-Schlüssel bereitzustellen, damit ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht wird) nicht einfach die DE-Schlüssel anfordern kann.
Hardware Root of Trust und Verified Boot , die an die Keymaster-Initialisierung gebunden sind, sind erforderlich, um sicherzustellen, dass die Anmeldeinformationen für die Geräteverschlüsselung nicht von einem nicht autorisierten Betriebssystem abgerufen werden können.

Hinweis : Speicherrichtlinien werden auf einen Ordner und alle seine Unterordner angewendet. Hersteller sollten die unverschlüsselten Inhalte auf den OTA-Ordner und den Ordner beschränken, der den Schlüssel enthält, der das System entschlüsselt. Die meisten Inhalte sollten sich in einem mit Anmeldeinformationen verschlüsselten Speicher und nicht in einem geräteverschlüsselten Speicher befinden.

Implementierung

In erster Linie sollten Apps wie Wecker, Telefon, Barrierefreiheitsfunktionen gemäß der Direct Boot- Entwicklerdokumentation android:directBootAware gemacht werden.

Kernel-Unterstützung

Kernel-Unterstützung für Ext4- und F2FS-Verschlüsselung ist in den allgemeinen Android-Kerneln ab Version 3.18 verfügbar. Um es in einem Kernel der Version 5.1 oder höher zu aktivieren, verwenden Sie:

CONFIG_FS_ENCRYPTION=y

Verwenden Sie für ältere Kernel CONFIG_EXT4_ENCRYPTION=y , wenn das Benutzerdaten-Dateisystem Ihres Geräts userdata ist, oder verwenden CONFIG_F2FS_FS_ENCRYPTION=y , wenn das userdata -Dateisystem Ihres Geräts F2FS ist.

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

Neben der funktionalen Unterstützung für Ext4- oder F2FS-Verschlüsselung sollten Gerätehersteller auch die kryptografische Beschleunigung aktivieren, um die dateibasierte Verschlüsselung zu beschleunigen und das Benutzererlebnis zu verbessern. Beispielsweise kann auf ARM64-basierten Geräten die Beschleunigung von ARMv8 CE (Cryptography Extensions) aktiviert werden, indem die folgenden Kernel-Konfigurationsoptionen festgelegt 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 auf dem Weg zum/vom Speichergerät verschlüsselt/entschlüsselt. Die allgemeinen Android-Kernel (Version 4.14 und höher) enthalten ein Framework, das die Verwendung von Inline-Verschlüsselung ermöglicht, wenn Hardware- und Herstellertreiberunterstützung verfügbar ist. Das Inline-Verschlüsselungsframework 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:

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Aktivieren der dateibasierten Verschlüsselung

Um FBE auf einem Gerät zu aktivieren, muss es im internen Speicher ( userdata ) aktiviert werden. Dadurch wird FBE auch automatisch auf Adoptable Storage aktiviert; jedoch kann das Verschlüsselungsformat auf dem verwendbaren Speicher bei Bedarf außer Kraft gesetzt werden.

Interne Speicher

FBE wird aktiviert, indem die Option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] zur Spalte fs_mgr_flags der fstab -Zeile für userdata . Diese Option definiert das Verschlüsselungsformat im internen Speicher. Es 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. Es kann entweder aes-256-xts oder adiantum sein. Seit Android 11 kann es auch leer gelassen werden, 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. Es kann entweder aes-256-cts , aes-256-heh oder adiantum sein. Wenn nicht angegeben, wird standardmäßig aes-256-cts verwendet, wenn aes-256-xts contents_encryption_mode , oder adiantum , wenn contents_encryption_mode adiantum ist.
Der flags Parameter, neu in Android 11, ist eine Liste von Flags, die durch das + -Zeichen getrennt sind. Die folgenden Flags werden unterstützt:
- Das v1 Flag wählt Verschlüsselungsrichtlinien der Version 1 aus; Das v2 Flag wählt Verschlüsselungsrichtlinien der Version 2 aus. Verschlüsselungsrichtlinien der Version 2 verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion . Der Standardwert ist v2, wenn das Gerät auf Android 11 oder höher gestartet wurde (wie durch ro.product.first_api_level bestimmt), oder v1, wenn das Gerät auf 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 Verschlüsselungsschlüssel für Dateiinhalte 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 mit der JEDEC eMMC v5.2-Spezifikation kompatibel ist und daher nur 32-Bit-IVs unterstützt. Verwenden Sie auf anderer Inline-Verschlüsselungshardware stattdessen inlinecrypt_optimized . Dieses Flag sollte niemals auf UFS-basiertem Speicher verwendet werden; Die UFS-Spezifikation erlaubt die Verwendung von 64-Bit-IVs.
- Auf Geräten, die hardwareverpackte Schlüssel unterstützen, aktiviert das wrappedkey_v0 -Flag die Verwendung von hardwareverpackten Schlüsseln für FBE. Dies kann nur in Kombination mit der Mount-Option inlinecrypt und entweder dem inlinecrypt_optimized oder emmc_optimized verwendet werden.

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

Auf Geräten, die mit Android 10 oder niedriger gestartet wurden, wird fileencryption=ice auch akzeptiert, um die Verwendung des Verschlüsselungsmodus für Dateiinhalte FSCRYPT_MODE_PRIVATE anzugeben. Dieser Modus wird von den gängigen Android-Kernels nicht implementiert, könnte aber von Anbietern implementiert werden, die benutzerdefinierte Kernel-Patches verwenden. Das von diesem Modus erzeugte On-Disk-Format war herstellerspezifisch. Auf Geräten, die mit Android 11 oder höher starten, ist dieser Modus nicht mehr zulässig und es muss stattdessen ein Standard-Verschlüsselungsformat verwendet werden.

Standardmäßig erfolgt die Verschlüsselung von Dateiinhalten mithilfe der Kryptografie-API des Linux-Kernels. Wenn Sie stattdessen Inline-Verschlüsselungshardware verwenden möchten, fügen Sie auch die inlinecrypt -Mount-Option 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

Annehmbarer Speicher

Seit Android 9 können FBE und Adoptable Storage zusammen verwendet werden.

Die Angabe der fstab-Option fileencryption für userdata auch automatisch sowohl die FBE- als auch die Metadatenverschlüsselung auf adoptierbarem Speicher. Sie können jedoch die FBE- und/oder Metadatenverschlüsselungsformate auf anpassbarem Speicher überschreiben, indem Sie Eigenschaften in PRODUCT_PROPERTY_OVERRIDES .

Verwenden Sie auf Geräten, die mit Android 11 oder höher gestartet wurden, die folgenden Eigenschaften:

ro.crypto.volume.options (neu in Android 11) wählt das FBE-Verschlüsselungsformat auf akzeptablem Speicher aus. Es hat die gleiche Syntax wie das Argument der fstab-Option fileencryption und verwendet die gleichen Standardwerte. Sehen Sie sich die Empfehlungen für die fileencryption oben an, um zu erfahren, was hier zu verwenden ist.
ro.crypto.volume.metadata.encryption wählt das Metadaten-Verschlüsselungsformat auf dem annehmbaren Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung .

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

ro.crypto.volume.contents_mode wählt den Inhaltsverschlüsselungsmodus 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 , außer dass der Standardwert auf Geräten, die mit Android 10 oder niedriger gestartet wurden, aes-256-heh ist. 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 Verschlüsselungsformat für Metadaten auf akzeptablem Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung .

Integration mit Keymaster

Die Generierung von Schlüsseln und die Verwaltung des Kernel-Schlüsselbunds wird von vold . Die AOSP-Implementierung von FBE erfordert, dass das Gerät Keymaster HAL Version 1.0 oder höher unterstützt. Es gibt keine Unterstützung für frühere Versionen von Keymaster HAL.

Beim ersten Start werden die Schlüssel von Benutzer 0 früh im Startvorgang generiert und installiert. Wenn die on-post-fs Phase von init abgeschlossen ist, muss der Keymaster bereit sein, Anfragen zu bearbeiten. Auf Pixel-Geräten wird dies gehandhabt, indem ein Skriptblock sicherstellt, dass Keymaster gestartet wird, bevor /data gemountet wird.

Verschlüsselungsrichtlinie

Die dateibasierte Verschlüsselung wendet die Verschlüsselungsrichtlinie auf Verzeichnisebene an. Wenn die Benutzerdatenpartition eines userdata zum ersten Mal erstellt wird, werden die grundlegenden Strukturen und Richtlinien von den init -Skripten angewendet. Diese Skripte lösen die Erstellung der CE- und DE-Schlüssel des ersten Benutzers (Benutzer 0) aus und definieren, welche Verzeichnisse mit diesen Schlüsseln verschlüsselt werden sollen. Wenn zusätzliche Benutzer und Profile erstellt werden, werden die erforderlichen zusätzlichen Schlüssel generiert und im Keystore gespeichert; ihre Speicherorte für Anmeldeinformationen und Geräte werden erstellt und die Verschlüsselungsrichtlinie verknüpft diese Schlüssel mit diesen Verzeichnissen.

In Android 11 und höher ist die Verschlüsselungsrichtlinie nicht mehr an einem zentralen Ort fest codiert, sondern wird durch Argumente für die mkdir Befehle in den Init-Skripten definiert. Verzeichnisse, die mit dem System-DE-Schlüssel verschlüsselt sind, verwenden encryption=Require , während unverschlüsselte Verzeichnisse (oder Verzeichnisse, deren Unterverzeichnisse mit benutzerspezifischen Schlüsseln verschlüsselt sind) encryption=None verwenden.

In Android 10 wurde die Verschlüsselungsrichtlinie an diesem Ort fest codiert:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 und früher war der Standort:

/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 Änderungen dieser Art vorgenommen werden, sollte der Gerätehersteller SELinux-Richtlinien einschließen, die nur den Anwendungen Zugriff gewähren, die das unverschlüsselte Verzeichnis verwenden müssen. Dies sollte alle nicht vertrauenswürdigen Anwendungen ausschließen.

Der einzige bekannte akzeptable Anwendungsfall dafür ist die Unterstützung älterer OTA-Funktionen.

Unterstützung von Direct Boot in Systemanwendungen

Anwendungen Direct Boot-fähig machen

Um die schnelle Migration von System-Apps zu erleichtern, gibt es zwei neue Attribute, die auf Anwendungsebene 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 Anwendungsebene ist eine Abkürzung zum Markieren aller Komponenten in der App als verschlüsselungsfähig.

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

Bei der Ausführung in diesem Modus sind die folgenden System-APIs verfügbar, um bei Bedarf einen durch CE-Speicher gesicherten Kontext explizit zu verwalten, die ihren gerätegeschützten Gegenstücken entsprechen.

Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()

Unterstützung mehrerer Benutzer

Jeder Benutzer in einer Mehrbenutzerumgebung erhält einen separaten Verschlüsselungsschlüssel. Jeder Benutzer erhält zwei Schlüssel: einen DE- und einen CE-Schlüssel. Benutzer 0 muss sich zuerst am Gerät anmelden, da es sich um einen speziellen Benutzer handelt. Dies ist für die Geräteverwaltung relevant.

Krypto-bewusste Anwendungen interagieren benutzerübergreifend auf diese Weise: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL ermöglichen einer Anwendung, über alle Benutzer auf dem Gerät hinweg zu agieren. Diese Apps können jedoch nur auf CE-verschlüsselte Verzeichnisse für Benutzer zugreifen, die bereits entsperrt sind.

Eine Anwendung kann möglicherweise frei über die DE-Bereiche hinweg interagieren, aber ein entsperrter Benutzer bedeutet nicht, dass alle Benutzer auf dem Gerät entsperrt sind. Die Anwendung sollte diesen Status überprüfen, bevor sie versucht, auf diese Bereiche zuzugreifen.

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

Umgang mit Aktualisierungen

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher auf der Benutzerdatenpartition zugreifen. Es wird dringend empfohlen, dass Geräte, die FBE implementieren, OTA mit A/B-Systemaktualisierungen 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.

Bei Verwendung einer älteren OTA-Lösung, die eine Wiederherstellung erfordert, um auf die OTA-Datei auf der userdata :

Erstellen Sie ein Verzeichnis der obersten Ebene (z. B. misc_ne ) in der userdata Partition.
Fügen Sie dieses Verzeichnis der obersten Ebene zur Ausnahme der Verschlüsselungsrichtlinie hinzu (siehe Verschlüsselungsrichtlinie oben).
Erstellen Sie ein Verzeichnis innerhalb des Verzeichnisses der obersten Ebene, um OTA-Pakete zu speichern.
Fügen Sie eine SELinux-Regel und Dateikontexte hinzu, um den Zugriff auf diesen Ordner und seinen Inhalt zu steuern. Nur der Prozess oder die Anwendungen, die OTA-Updates erhalten, sollten in der Lage sein, diesen Ordner zu lesen und zu schreiben. Keine andere Anwendung oder kein anderer Prozess sollte Zugriff auf diesen Ordner haben.

Validierung

Um sicherzustellen, dass die implementierte Version des Features wie beabsichtigt funktioniert, führen Sie zuerst die vielen CTS-Verschlüsselungstests aus, wie 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

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

Prüfen Sie, ro.crypto.state existiert
- Stellen Sie sicher ro.crypto.state verschlüsselt ist
Überprüfen Sie, ro.crypto.type vorhanden ist
- Stellen Sie sicher, ro.crypto.type auf file gesetzt ist

Darüber hinaus können Tester eine userdebug Instanz mit einem auf den primären Benutzer eingestellten Sperrbildschirm booten. Dann adb Shell in das Gerät und mit su root werden. Stellen Sie sicher, dass /data/data verschlüsselte Dateinamen enthält; wenn nicht, stimmt etwas nicht.

Gerätehersteller werden auch ermutigt, die Ausführung der Upstream-Linux-Tests für fscrypt auf ihren Geräten oder Kerneln zu prüfen. Diese Tests sind Teil der Dateisystem-Testsuite xfstests. Diese Upstream-Tests werden jedoch nicht offiziell von Android unterstützt.

AOSP-Implementierungsdetails

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 "fscrypt"-Verschlüsselung (unterstützt von ext4 und f2fs) im Kernel und ist normalerweise so konfiguriert:

Verschlüsseln Sie Dateiinhalte mit AES-256 im XTS-Modus
Verschlüsseln Sie Dateinamen mit AES-256 im CBC-CTS-Modus

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

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

Schlüsselableitung

Dateibasierte Verschlüsselungsschlüssel, bei denen es sich um 512-Bit-Schlüssel handelt, werden verschlüsselt von einem anderen Schlüssel (einem 256-Bit-AES-GCM-Schlüssel) gespeichert, der im TEE gespeichert ist. Um diesen TEE-Schlüssel verwenden zu können, müssen drei Voraussetzungen erfüllt sein:

Das Authentifizierungstoken
Der gestreckte Berechtigungsnachweis
Der „secdiscardable hash“

Das Authentifizierungstoken ist ein kryptografisch authentifiziertes Token , das von Gatekeeper generiert wird, wenn sich ein Benutzer erfolgreich anmeldet. Das TEE lehnt die Verwendung des Schlüssels ab, wenn nicht das richtige Authentifizierungstoken bereitgestellt wird. Wenn der Benutzer keine Anmeldeinformationen hat, wird kein Authentifizierungstoken verwendet oder benötigt.

Der gestreckte Berechtigungsnachweis ist der Benutzer-Berechtigungsnachweis nach dem Salzen und Strecken mit dem scrypt . Die Anmeldeinformationen werden tatsächlich einmal im Sperreinstellungsdienst gehasht, bevor sie an vold zur Weitergabe an scrypt übergeben werden. Diese ist mit allen Garantien, die für KM_TAG_APPLICATION_ID gelten, kryptografisch an den Schlüssel im TEE gebunden. Wenn der Benutzer keinen Berechtigungsnachweis hat, werden keine erweiterten Berechtigungsnachweise verwendet oder benötigt.

Der secdiscardable hash ist ein 512-Bit-Hash einer zufälligen 16-KB-Datei, die zusammen mit anderen Informationen gespeichert wird, die zum Rekonstruieren des Schlüssels verwendet werden, z. B. dem Seed. Diese Datei wird beim Löschen des Schlüssels sicher gelöscht oder neu verschlüsselt; Dieser zusätzliche Schutz stellt sicher, dass ein Angreifer jedes Bit dieser sicher gelöschten Datei wiederherstellen muss, um den Schlüssel wiederherzustellen. Diese ist mit allen Garantien, die für KM_TAG_APPLICATION_ID gelten, kryptografisch an den Schlüssel im TEE gebunden.

In den meisten Fällen werden FBE-Schlüssel auch einem zusätzlichen Schlüsselableitungsschritt im Kernel unterzogen, um die Unterschlüssel zu generieren, die tatsächlich für die Verschlüsselung verwendet werden, beispielsweise Schlüssel pro Datei oder pro Modus. Für Verschlüsselungsrichtlinien der Version 2 wird dafür HKDF-SHA512 verwendet.