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.

In diesem Artikel wird beschrieben, 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.

Direktstart

Dateibasierte Verschlüsselung ermöglicht eine neue Funktion in Android eingeführt 7.0 genannt sofort gebootet . Direct Boot ermöglicht es verschlüsselten Geräten, direkt auf den Sperrbildschirm zu booten. Zuvor auf verschlüsselte Geräte mit Full-Disk - Verschlüsselung (FDE), benötigt Benutzer - Anmeldeinformationen zur Verfügung zu stellen , bevor alle Daten zugegriffen werden kann, von der das Telefon zu verhindern alle Durchführung aber die grundlegendsten Operationen. Zum Beispiel konnten Alarme nicht funktionieren, Barrierefreiheitsdienste waren nicht verfügbar und Telefone konnten keine Anrufe empfangen, 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, ist es für diese Anwendungen möglich, in einem begrenzten Kontext zu arbeiten. Dies kann passieren, bevor Benutzer ihre Anmeldeinformationen bereitgestellt haben, während die privaten 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, ein Speicherort, der sowohl während des Direktstartmodus 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 ausschließlich auf einem Bootzeit-Passwort basiert.

Die Direct Boot API ermöglicht verschlüsselten Anwendungen den Zugriff auf jeden dieser Bereiche. Es gibt Änderungen des Anwendungslebenszyklus die Notwendigkeit aufzunehmen Anwendungen zu benachrichtigen , wenn ein Benutzer CE Speicherung in Reaktion auf erste Eingabe Anmeldeinformationen auf dem Bildschirm sperren, oder im Fall von Arbeitsprofil entriegelt ist eine Bereitstellung von Arbeit Herausforderung . 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) untersuchen.

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

• Telefondienste und Dialer
• Eingabemethode zum Eingeben von Passwörtern in den Sperrbildschirm

Beispiele und Quelle

Android bietet eine Referenzimplementierung von dateibasierte Verschlüsselung, bei der vold ( System / vold ) für die Verwaltung von Speichergeräten und Volumes auf Android die Funktionalität zur Verfügung stellt. Durch das Hinzufügen von FBE erhält vold mehrere neue Befehle zur Unterstützung der Schlüsselverwaltung für die CE- und DE-Schlüssel mehrerer Benutzer. Neben dem Kern ändert die verwenden dateibasierte Verschlüsselungsfunktionen im Kernel, viele Systempakete einschließlich der Lockscreen und der SystemUI modifiziert wurden , um die FBE und Direct - Boot - Funktionen zu unterstützen. Diese beinhalten:

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

* System - Anwendungen, die die Verwendung defaultToDeviceProtectedStorage manifest - Attribut

Weitere Beispiele für Anwendungen und Dienste , die Verschlüsselung bewusst sind , können durch Ausführen des Befehls finden mangrep directBootAware im Rahmen oder Pakete Verzeichnis der AOSP Quellbaum.

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 Fähigkeiten bietet oder keinen ausreichenden Schutz für Verschlüsselungsschlüssel gewährleistet.
• Keymaster / Schlüsselspeicher und Torwächter muss in einem implementiert werden Trusted Execution Environment (TEE) Schutz für die DE - Tasten zur Verfügung zu stellen , so dass eine nicht autorisierte OS (OS benutzerdefinierte auf das Gerät geflasht) kann einfach nicht die DE - Tasten anfordern.
• Hardware Root of Trust and Verified Boote gebunden an die keymaster Initialisierung ist erforderlich , dass Device Encryption Anmeldeinformationen durch ein nicht autorisiertes Betriebssystem nicht zugänglich sind zu gewährleisten.

Hinweis: Speicher Richtlinien angewendet werden in einen Ordner und alle Unterordner. Hersteller sollten den unverschlüsselten Inhalt 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 Anwendungen wie Wecker, Telefon, sollte Barrierefreiheit android gemacht werden: directBootAware nach Direkt Boot - Entwickler - Dokumentation.

Kernel-Unterstützung

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

CONFIG_FS_ENCRYPTION=y

Für ältere Kernel, Verwendung CONFIG_EXT4_ENCRYPTION=y , wenn Ihr Gerät die userdata - Dateisystem ist Ext4 oder Verwendung CONFIG_F2FS_FS_ENCRYPTION=y , wenn Ihr Gerät die userdata - Dateisystem F2fs ist.

Wenn Ihr Gerät unterstützt adoptable Speicher oder wird verwenden Metadaten - Verschlüsselung auf internen Speicher, ermöglichen auch die Kernel - Konfigurationsoptionen für Metadaten - Verschlüsselung benötigt wie in der beschriebenen Metadaten Verschlüsselung Dokumentation .

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 das Benutzererlebnis zu verbessern. Auf ARM64-basierten Geräten kann beispielsweise die ARMv8 CE-Beschleunigung (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, Gerätehersteller reduzieren auch Hardware-Implementierung erwägen Inline - Verschlüsselung kann, die verschlüsselt / entschlüsselt die Daten , während sie auf dem Weg zum / vom Speichergerät ist. 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ü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 Ihr Gerät eMMC-basierten Speicher verwendet, aktivieren Sie außerdem:

CONFIG_MMC_CRYPTO=y

Aktivieren der dateibasierten Verschlüsselung

FBE Aktivieren der auf einem Gerät erfordert es auf den internen Speicher ermöglichen ( userdata ). Dadurch wird FBE auch automatisch auf anpassungsfähigem Speicher aktiviert; jedoch kann das Verschlüsselungsformat auf dem verwendbaren Speicher bei Bedarf überschrieben werden.

Interne Speicher

FBE wird durch Addieren der Option aktiviert fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] auf die fs_mgr_flags Spalte der fstab Linie für userdata . Diese Option definiert das Verschlüsselungsformat im internen Speicher. Es enthält bis zu drei durch Doppelpunkte getrennte Parameter:

• Die contents_encryption_mode Parameter definiert , die kryptografischen Algorithmus zum Verschlüsseln von Dateiinhalten verwendet wird. Es kann entweder aes-256-xts oder adiantum . Seit 11 Android kann es auch leer bleibt den Standard - Algorithmus zu bestimmen, das ist aes-256-xts .
• Die filenames_encryption_mode Parameter definiert , welcher Verschlüsselungsalgorithmus zu verschlüsseln Dateinamen verwendet wird. Es kann entweder aes-256-cts , aes-256-heh oder adiantum . Wenn nicht angegeben, wird standardmäßig aes-256-cts wenn contents_encryption_mode ist aes-256-xts oder zu adiantum wenn contents_encryption_mode ist adiantum .
• Die flags Parameter, neu in Android 11, ist eine Liste der Flaggen durch den getrennt + Charakter. Die folgenden Flags werden unterstützt:
  • Die v1 Version 1 Verschlüsselung wählt Flag Politik; die v2 Richtlinien Version 2 Verschlüsselung wählt Flagge. Version 2 Verschlüsselungsrichtlinien verwenden , um eine sichere und flexible Schlüsselableitungsfunktion . Der Standardwert ist v2 , wenn das Gerät auf Android 11 oder höher gestartet (wie bestimmt durch ro.product.first_api_level ) oder v1 , wenn das Gerät auf Android 10 oder senken gestartet.
  • Die inlinecrypt_optimized Flagge wählt ein Verschlüsselungsformat , das für die Inline - Verschlüsselung Hardware optimiert ist , die nicht eine große Anzahl von Schlüsseln effizient umgehen kann . Dies geschieht durch die Ableitung nur eines Dateiinhalts-Verschlüsselungsschlüssels pro CE- oder DE-Schlüssel anstelle eines pro Datei. Die Erzeugung von IVs (Initialisierungsvektoren) wird entsprechend angepasst.
  • Die emmc_optimized Flag ist ähnlich inlinecrypt_optimized , sondern wählt auch ein IV - Erzeugungsverfahren , daß Grenzen IVs auf 32 Bits. 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. Bei anderer Inline - Verschlüsselung Hardware verwendet inlinecrypt_optimized statt. Dieses Flag sollte niemals auf UFS-basiertem Speicher verwendet werden; die UFS-Spezifikation erlaubt die Verwendung von 64-Bit-IVs.
  • Auf Geräten , dass die Unterstützung Hardware-wrapped Tasten , die wrappedkey_v0 ermöglicht Flag die Verwendung von Hardware-wrapped Schlüssel für FBE. Dies kann nur mit dem in Kombination verwendet wird inlinecrypt Mount - Option, und entweder die inlinecrypt_optimized oder emmc_optimized Flagge.

Wenn Sie keine Inline - Verschlüsselung Hardware die empfohlene Einstellung für die meisten Geräte im Einsatz ist fileencryption=aes-256-xts . Wenn Sie die empfohlene Einstellung für die meisten Geräte Inline - Verschlüsselung Hardware verwenden ist fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (oder äquivalent fileencryption=::inlinecrypt_optimized ). Bei Geräten ohne jegliche Form von AES - Beschleunigung, Adiantum werden kann anstelle von AES durch Einstellung verwendet fileencryption=adiantum .

Bei Geräten , die mit Android 10 oder weniger ins Leben gerufen, fileencryption=ice ist auch die Verwendung des angeben akzeptiert FSCRYPT_MODE_PRIVATE Dateiinhalte Verschlüsselungsmodus. Dieser Modus wird von den allgemeinen Android-Kernels nicht implementiert, könnte jedoch von Anbietern mit benutzerdefinierten Kernel-Patches implementiert werden. Das von diesem Modus erzeugte Festplattenformat war herstellerspezifisch. Auf Geräten, die mit Android 11 oder höher starten, ist dieser Modus nicht mehr zulässig und stattdessen muss ein Standardverschlüsselungsformat verwendet werden.

Standardmäßig erfolgt die Verschlüsselung des Dateiinhalts mithilfe der Kryptografie-API des Linux-Kernels. Wenn Sie stattdessen Inline - Verschlüsselung Hardware verwenden möchten, fügen Sie auch die inlinecrypt Option montieren. Zum Beispiel kann eine vollständige fstab könnte Linie wie folgt 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

Da Android 9, FBE und adoptable Lagerung können zusammen verwendet werden.

Die Angabe von fileencryption fstab Option für userdata ermöglicht auch automatisch sowohl FBE und Metadaten - Verschlüsselung auf adoptable Speicher. Sie können jedoch die FBE und / oder Metadaten Verschlüsselungsformate auf anpassungsSpeicher außer Kraft setzen von Eigenschaften bei der Einrichtung 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 die FBE Verschlüsselungsformat auf adoptable Lagerung. Es hat die gleiche Syntax als Argument für die fileencryption fstab Option, und es verwendet die gleichen Vorgaben. Siehe die Empfehlungen für fileencryption oben für das, was hier zu verwenden.
• ro.crypto.volume.metadata.encryption wählt die Metadaten Verschlüsselungsformat auf adoptable Speicher. Finden Sie in der Metadaten - Verschlüsselung Dokumentation .

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

• ro.crypto.volume.contents_mode wählt den Inhalt Verschlüsselungsmodus. Dies entspricht dem ersten Doppelpunkte getrennte Bereich ro.crypto.volume.options .
• ro.crypto.volume.filenames_mode wählt den Dateinamen Verschlüsselungsmodus. Dies ist gleichbedeutend mit dem zweiten Doppelpunkt getrennten Bereich ro.crypto.volume.options , mit der Ausnahme , dass der Standard auf Geräte , die mit Android gestartet 10 oder niedriger ist , aes-256-heh . Bei den meisten Geräten muss dies ausdrücklich außer Kraft gesetzt werden , aes-256-cts .
• ro.crypto.fde_algorithm und ro.crypto.fde_sector_size wählen Sie die Metadaten Verschlüsselungsformat auf adoptable Speicher. Finden Sie in der Metadaten - Verschlüsselung Dokumentation .

Integration mit Keymaster

Die Erzeugung von Schlüsseln und das Management des Kernels Schlüsselbund wird durch gehandhabt 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 Booten werden die Schlüssel von Benutzer 0 generiert und früh im Bootvorgang installiert. Durch die Zeit , die on-post-fs Phase der init abgeschlossen ist , muss der Keymaster bereit sein , um Anfragen zu bearbeiten. Bei Pixel - Geräten wird dies , indem er ein Skriptblock Keymaster gestartet wird sicherstellen , behandelt vor /data angebracht ist.

Verschlüsselungsrichtlinie

Die dateibasierte Verschlüsselung wendet die Verschlüsselungsrichtlinie auf Verzeichnisebene an. Wenn ein Gerät die userdata Partition erstellt wird, werden die grundlegenden Strukturen und Maßnahmen durch die Anwendung init - Skripten. Diese Skripte lösen die Erstellung der CE- und DE-Schlüssel des ersten Benutzers (Benutzer 0) aus und legen fest, 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 Berechtigungs- und Gerätespeicherorte werden erstellt und die Verschlüsselungsrichtlinie verknüpft diese Schlüssel mit diesen Verzeichnissen.

In Android 11 und höher wird die Verschlüsselungsrichtlinie nicht mehr in einen zentralen Standort fest einprogrammiert, sondern durch Argumente zu den definierten mkdir Befehlen in den Init - Skripten. Verschlüsselte Verzeichnisse mit dem System DE Schlüssel Nutzung encryption=Require , während unverschlüsselt Verzeichnisse (oder Verzeichnisse , deren Verzeichnisse verschlüsselt mit pro-Benutzerschlüssel) Verwendung encryption=None .

In Android 10 war die Verschlüsselungsrichtlinie an diesem Speicherort fest codiert:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 und früheren Versionen lautete 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 Änderungen Art daraus gemacht werden , dann sollten die Gerätehersteller sind SELinux - Richtlinien , die nur Zugriff auf die Anwendungen gewähren , dass Notwendigkeit , die unverschlüsselt Verzeichnis zu verwenden. Dies sollte alle nicht vertrauenswürdigen Anwendungen ausschließen.

Der einzige bekannte akzeptable Anwendungsfall hierfür ist die Unterstützung von Legacy-OTA-Funktionen.

Unterstützung von Direct Boot in Systemanwendungen

Anwendungen Direct Boot bewusst machen

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

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

Das directBootAware Attribut auf der Anwendungsebene ist eine Abkürzung für die Kennzeichnung aller Komponenten in der App als Verschlüsselung bewusst zu sein.

Das defaultToDeviceProtectedStorage Attribut leitet die Standard - App Lagerort Punkt DE Lagerung statt bei CE Lagerung des Zeigens. System-Apps, die dieses Flag verwenden, müssen alle am Standardspeicherort gespeicherten Daten sorgfältig prüfen und die Pfade sensibler Daten ändern, um 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 stehen die folgenden System-APIs zur Verfügung, um bei Bedarf einen durch CE-Speicher unterstützten 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 relevant für die Geräteverwaltung Verwendungen.

Crypto-fähige Anwendungen interagieren über Benutzer auf diese Weise: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL erlauben eine Anwendung für alle Benutzer auf dem Gerät zu handeln. Diese Apps können jedoch nur auf CE-verschlüsselte Verzeichnisse für Benutzer zugreifen, die bereits entsperrt sind.

Eine Anwendung kann möglicherweise in den DE-Gebieten frei interagieren, aber ein entsperrter Benutzer bedeutet nicht, dass alle Benutzer auf dem Gerät entsperrt sind. Die Anwendung sollte diesen Status überprüfen, bevor versucht wird, 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 Updates

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher auf der Benutzerdatenpartition zugreifen. Geräte FBE Umsetzung wird dringend Unterstützung OTA Verwendung empfohlen A / B System - Updates . Da der OTA während des normalen Betriebs angewendet werden kann, ist keine Wiederherstellung erforderlich, um auf die Daten auf dem verschlüsselten Laufwerk zuzugreifen.

Bei Verwendung einer Legacy - OTA - Lösung, die die OTA - Datei auf der Recovery - Zugriff erfordert userdata

1. Erstellen Sie ein Verzeichnis auf oberster Ebene (zB misc_ne ) in der userdata
2. Fügen Sie dieses Top-Level - Verzeichnis auf die Verschlüsselungsrichtlinie Ausnahme (siehe Verschlüsselungsrichtlinie oben).
3. Erstellen Sie ein Verzeichnis innerhalb des Verzeichnisses der obersten Ebene, um OTA-Pakete zu speichern.
4. 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 die implementierte Version der Funktion funktioniert wie vorgesehen zu gewährleisten, laufen zunächst die vielen CTS - Verschlüsselung Tests, wie DirectBootHostTest und EncryptionTest .

Wenn das Gerät mit Android 11 oder höher, führt auch vts_kernel_encryption_test :

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:

• Überprüfen Sie, ob ro.crypto.state existiert
  • Stellen Sie sicher , ro.crypto.state ist verschlüsselt
• Überprüfen Sie, ob ro.crypto.type existiert
  • Stellen Sie sicher , ro.crypto.type wird eingestellt file

Zusätzlich Tester können Sie eine Boot - userdebug mit einem Lockscreen Satz auf der primären Benutzerinstanz. Dann adb Schal in das Gerät und die Verwendung su Wurzel werden. Stellen Sie sicher , /data/data enthält verschlüsselte Dateinamen; wenn nicht, stimmt etwas nicht.

Die Gerätehersteller auch zu erforschen laufen die ermutigt vorgeschalteten Linux - Tests für fscrypt auf ihren Geräten oder Kerne. Diese Tests sind Teil der Dateisystem-Testsuite xfstests. Diese Upstream-Tests werden jedoch von Android nicht offiziell 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

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 über 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 durch einen anderen Schlüssel (einen 256-Bit-AES-GCM-Schlüssel) im TEE gespeichert. Um diesen TEE-Schlüssel verwenden zu können, müssen drei Voraussetzungen erfüllt sein:

• Das Auth-Token
• Der gestreckte Ausweis
• Der „sekundär verwerfbare Hash“

Der Auth - Token ist ein kryptografisch authentifizierte Token generiert durch Torwächter , wenn ein Benutzer erfolgreich anmeldet. Der TEE wird sich weigern , den Schlüssel zu verwenden , es sei denn , die richtige Auth - Token versorgt wird. Wenn der Benutzer keine Anmeldeinformationen hat, wird kein Authentifizierungstoken verwendet oder benötigt.

Der gestreckte Berechtigungsnachweis ist die Anmeldeinformationen des Benutzers nach dem Salzen und Strecken mit dem scrypt Algorithmus. Die Berechtigung wird tatsächlich einmal in die Sperreinstellungen Service gehasht , bevor sie weitergeleitet werden vold für die Weitergabe an scrypt . Dies wird kryptographisch gebunden an den Schlüssel in dem TEE mit allen Garantien , die anzuwenden KM_TAG_APPLICATION_ID . Wenn der Benutzer keine Anmeldeinformationen hat, werden keine gestreckten Anmeldeinformationen verwendet oder benötigt.

Der secdiscardable hash ist ein 512-Bit - Hash eines Zufallsgenerators 16 KB Datei zusammen mit anderen gespeicherten Informationen verwendet , um den Schlüssel, wie beispielsweise die Samen zu rekonstruieren. 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. Dies wird kryptographisch gebunden an den Schlüssel in dem TEE mit allen Garantien , die anzuwenden KM_TAG_APPLICATION_ID .

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