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 entwederaes-256-xts
oderadiantum
sein. Seit Android 11 kann das Feld auch leer gelassen werden, um den Standardalgorithmusaes-256-xts
anzugeben. - Mit dem Parameter
filenames_encryption_mode
wird der kryptografische Algorithmus definiert, der zum Verschlüsseln von Dateinamen verwendet wird. Sie kann entwederaes-256-cts
,aes-256-heh
,adiantum
oderaes-256-hctr2
sein. Wenn nichts angegeben ist, wird standardmäßigaes-256-cts
verwendet, wenncontents_encryption_mode
aes-256-xts
ist, oderadiantum
, wenncontents_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 Flagv2
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
ähneltinlinecrypt_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 stattdesseninlinecrypt_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-Optioninlinecrypt
und entweder dem Flaginlinecrypt_optimized
oderemmc_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.
- Das Flag
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-Optionfileencryption
und verwendet dieselben Standardwerte. Sehen Sie sich die Empfehlungen fürfileencryption
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 vonro.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 vonro.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 aufaes-256-cts
gesetzt werden.ro.crypto.fde_algorithm
undro.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:
- Erstellen Sie auf der Partition
userdata
ein Verzeichnis auf oberster Ebene, z. B.misc_ne
. - Konfigurieren Sie dieses Verzeichnis auf oberster Ebene so, dass es nicht verschlüsselt wird (siehe Verzeichnisse ausschließen).
- Erstellen Sie im obersten Verzeichnis ein Verzeichnis zum Speichern von OTA-Paketen.
- 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
auffile
gesetzt ist.
- Prüfen Sie, ob
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:
Speicherklasse | Beschreibung | Verzeichnisse |
---|---|---|
Unverschlüsselt | Verzeichnisse in /data , die nicht durch FBE geschützt werden können oder müssen. Auf Geräten, auf denen Metadatenverschlüsselung verwendet wird, sind diese Verzeichnisse nicht wirklich unverschlüsselt, sondern werden durch den Metadatenverschlüsselungsschlüssel geschützt, der dem System-DE entspricht. |
|
System DE | Geräteverschlüsselte Daten, die nicht mit einem bestimmten Nutzer verknüpft sind |
|
Pro Bootvorgang | Flüchtige Systemdateien, die einen Neustart nicht überdauern müssen | /data/per_boot |
User CE (intern) | Pro Nutzer verschlüsselte Daten auf dem internen Speicher |
|
Nutzer DE (intern) | Pro Nutzer verschlüsselte Daten auf dem internen Speicher |
|
Nutzer-CE (übernehmbar) | Pro Nutzer verschlüsselte Daten mit Anmeldedaten auf dem adoptable Speicher |
|
Nutzer DE (adoptable) | Nutzerspezifische, auf dem Gerät verschlüsselte Daten auf dem adoptable Storage |
|
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:
Schlüsseltyp | Speicherort des Schlüssels | Speicherklasse des Schlüsselstandorts |
---|---|---|
System-DE-Schlüssel | /data/unencrypted |
Unverschlüsselt |
Schlüssel für interne Nutzer-CEs | /data/misc/vold/user_keys/ce/${user_id} |
System DE |
Nutzer-DE-Schlüssel (intern) | /data/misc/vold/user_keys/de/${user_id} |
System DE |
Vom Nutzer verwaltete Schlüssel (adoptable) | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} |
User CE (intern) |
Nutzer-DE-Schlüssel (übernehmbar) | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} |
Nutzer DE (intern) |
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.