Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (File-Based Encryption, FBE). Bei FBE können verschiedene Dateien mit unterschiedlichen Schlüsseln verschlüsselt werden, die unabhängig voneinander entsperrt werden können. Mit diesen Schlüsseln werden sowohl Dateiinhalte als auch Dateinamen verschlüsselt. Wenn FBE verwendet wird, werden andere Informationen wie Verzeichnislayouts, Dateigrößen, Berechtigungen und Erstellungs-/Änderungszeiten nicht verschlüsselt. Zusammenfassend werden diese anderen Informationen als Dateisystemmetadaten bezeichnet.
Unter Android 9 wurde die Unterstützung für die Metadatenverschlüsselung eingeführt. Bei der Metadatenverschlüsselung wird ein einzelner Schlüssel, der beim Booten vorhanden ist, verwendet, um alle Inhalte zu verschlüsseln, die nicht durch FBE verschlüsselt werden. Dieser Schlüssel wird durch KeyMint (früher Keymaster) geschützt, das wiederum durch den verifizierten Bootmodus geschützt wird.
Die Metadatenverschlüsselung ist auf adoptable storage immer aktiviert, wenn FBE aktiviert ist. Die Metadatenverschlüsselung kann auch für den internen Speicher aktiviert werden. Auf Geräten, die mit Android 11 oder höher auf den Markt kommen, muss die Metadatenverschlüsselung im internen Speicher aktiviert sein.
Implementierung im internen Speicher
Sie können die Metadatenverschlüsselung auf dem internen Speicher neuer Geräte einrichten, indem Sie das metadata-Dateisystem einrichten, die Initialisierungssequenz ändern und die Metadatenverschlüsselung in der fstab-Datei des Geräts aktivieren.
Voraussetzungen
Die Metadatenverschlüsselung kann nur eingerichtet werden, wenn die Datenpartition zum ersten Mal formatiert wird. Daher ist diese Funktion nur für neue Geräte verfügbar. Sie kann nicht durch ein OTA-Update geändert werden.
Für die Metadatenverschlüsselung muss das dm-default-key-Modul in Ihrem Kernel aktiviert sein. Unter Android 11 und höher wird dm-default-key von den gemeinsamen Android-Kernels ab Version 4.14 unterstützt. Diese Version von dm-default-key verwendet ein hardware- und anbieterunabhängiges Verschlüsselungs-Framework namens blk-crypto.
So aktivieren Sie dm-default-key:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key verwendet, sofern verfügbar, Inline-Verschlüsselungshardware (Hardware, die Daten verschlüsselt/entschlüsselt, während sie zum/vom Speichergerät übertragen werden). Wenn Sie keine Inline-Verschlüsselungshardware verwenden, müssen Sie auch einen Fallback auf die Kryptografie-API des Kernels aktivieren:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Wenn Sie keine Inline-Verschlüsselungshardware verwenden, sollten Sie auch alle verfügbaren CPU-basierten Beschleunigungen aktivieren, wie in der FBE-Dokumentation empfohlen.
Unter Android 10 und niedriger wurde dm-default-key nicht vom gemeinsamen Android-Kernel unterstützt. Es lag daher an den Anbietern, dm-default-key zu implementieren.
Metadaten-Dateisystem einrichten
Da nichts in der userdata-Partition gelesen werden kann, bis der Metadaten-Verschlüsselungsschlüssel vorhanden ist, muss in der Partitionstabelle eine separate Partition namens Metadatenpartition für die Speicherung der KeyMint-Blobs reserviert werden, die diesen Schlüssel schützen. Die Metadatenpartition sollte 16 MB groß sein.
fstab.hardware muss einen Eintrag für das Metadaten-Dateisystem enthalten, das sich auf dieser Partition befindet und unter /metadata bereitgestellt wird. Dazu gehört auch das Flag formattable, damit es beim Booten formatiert wird. Das f2fs-Dateisystem funktioniert nicht auf kleineren Partitionen. Wir empfehlen stattdessen die Verwendung von ext4. Beispiel:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
Damit der Bereitstellungspunkt /metadata vorhanden ist, fügen Sie BoardConfig-common.mk die folgende Zeile hinzu:
BOARD_USES_METADATA_PARTITION := true
Änderungen an der Initialisierungssequenz
Wenn die Metadatenverschlüsselung verwendet wird, muss vold ausgeführt werden, bevor /data bereitgestellt wird. Damit sie früh genug gestartet wird, fügen Sie init.hardware.rc den folgenden Abschnitt hinzu:
# We need vold early for metadata encryption
on early-fs
start vold
KeyMint muss ausgeführt und bereit sein, bevor init versucht, /data zu mounten.
init.hardware.rc sollte bereits eine mount_all-Anweisung enthalten, mit der /data selbst im on
late-fs-Abschnitt eingebunden wird. Fügen Sie vor dieser Zeile die Anweisung zum Ausführen des wait_for_keymaster-Dienstes hinzu:
on late-fs … # Wait for Keymaster exec_start wait_for_keymaster # Mount RW partitions which need run fsck mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Metadatenverschlüsselung aktivieren
Fügen Sie schließlich keydirectory=/metadata/vold/metadata_encryption der Spalte fs_mgr_flags des Eintrags fstab für userdata hinzu. Eine vollständige fstab-Zeile könnte beispielsweise so aussehen:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable
Standardmäßig ist der Metadatenverschlüsselungsalgorithmus auf dem internen Speicher AES‑256‑XTS. Dies kann durch Festlegen der Option metadata_encryption überschrieben werden, ebenfalls in der Spalte fs_mgr_flags:
- Auf Geräten ohne AES-Beschleunigung kann die Adiantum-Verschlüsselung durch Festlegen von
metadata_encryption=adiantumaktiviert werden. - Auf Geräten, die Hardware-Wrapped Keys unterstützen, kann der Metadatenverschlüsselungsschlüssel durch Festlegen von
metadata_encryption=aes-256-xts:wrappedkey_v0(oder alternativmetadata_encryption=:wrappedkey_v0, daaes-256-xtsder Standardalgorithmus ist) in einen Hardware-Wrapped Key umgewandelt werden.
Da sich die Kernelschnittstelle zu dm-default-key in Android 11 geändert hat, müssen Sie auch darauf achten, dass Sie den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL in device.mk festgelegt haben. Wenn Ihr Gerät beispielsweise mit Android 11 (API‑Level 30) auf den Markt kommt, sollte device.mk Folgendes enthalten:
PRODUCT_SHIPPING_API_LEVEL := 30
Sie können auch die folgende Systemeigenschaft festlegen, um die Verwendung der neuen dm-default-key API unabhängig vom Versand-API-Level zu erzwingen:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.dm_default_key.options_format.version=2
Zertifizierungsstufe
Führen Sie die unten beschriebenen Tests aus, um zu prüfen, ob die Metadatenverschlüsselung aktiviert ist und ordnungsgemäß funktioniert. Beachten Sie auch die häufigen Probleme, die unten beschrieben werden.
Tests
Führen Sie zuerst den folgenden Befehl aus, um zu prüfen, ob die Metadatenverschlüsselung im internen Speicher aktiviert ist:
adb rootadb shell dmctl table userdata
Die Ausgabe sollte in etwa so aussehen:
Targets in the device-mapper table for userdata: 0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors
Wenn Sie die Standardverschlüsselungseinstellungen überschrieben haben, indem Sie die Option metadata_encryption im fstab des Geräts festgelegt haben, weicht die Ausgabe geringfügig von der oben gezeigten ab. Wenn Sie beispielsweise die Adiantum-Verschlüsselung aktiviert haben, ist das dritte Feld xchacha12,aes-adiantum-plain64 anstelle von aes-xts-plain64.
Führen Sie als Nächstes vts_kernel_encryption_test aus, um die Richtigkeit der Metadatenverschlüsselung und FBE zu prüfen:
atest vts_kernel_encryption_test
oder:
vts-tradefed run vts -m vts_kernel_encryption_test
Häufige Probleme
Während des Aufrufs von mount_all, mit dem die metadatenverschlüsselte Partition /data gemountet wird, führt init das VDC-Tool aus. Das Tool „vdc“ stellt über binder eine Verbindung zu vold her, um das metadatenverschlüsselte Gerät einzurichten und die Partition bereitzustellen. Während dieses Anrufs ist init blockiert. Versuche, init-Attribute zu lesen oder festzulegen, werden blockiert, bis mount_all abgeschlossen ist.
Wenn in dieser Phase ein Teil der Arbeit von vold direkt oder indirekt durch das Lesen oder Festlegen einer Eigenschaft blockiert wird, kommt es zu einem Deadlock. Es ist wichtig, dass vold die Arbeit des Lesens der Schlüssel, der Interaktion mit KeyMint und des Einbindens des Datenverzeichnisses ohne weitere Interaktion mit init ausführen kann.
Wenn KeyMint beim Ausführen von mount_all nicht vollständig gestartet ist, reagiert es erst auf vold, wenn bestimmte Eigenschaften aus init gelesen wurden. Dies führt genau zu dem beschriebenen Deadlock. Wenn Sie exec_start wait_for_keymaster über dem entsprechenden mount_all-Aufruf platzieren, wie oben beschrieben, wird KeyMint vollständig im Voraus ausgeführt und dieser Deadlock wird vermieden.
Konfiguration auf verwendbarem Speicher
Seit Android 9 ist eine Form der Metadatenverschlüsselung immer auf adoptable storage aktiviert, wenn FBE aktiviert ist, auch wenn die Metadatenverschlüsselung auf dem internen Speicher nicht aktiviert ist.
In AOSP gibt es zwei Implementierungen der Metadatenverschlüsselung auf adoptablem Speicher: eine eingestellte, die auf dm-crypt basiert, und eine neuere, die auf dm-default-key basiert. Damit die richtige Implementierung für Ihr Gerät ausgewählt wird, müssen Sie in device.mk den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL festlegen. Wenn Ihr Gerät beispielsweise mit Android 11 (API-Level 30) auf den Markt kommt, sollte device.mk Folgendes enthalten:
PRODUCT_SHIPPING_API_LEVEL := 30
Sie können auch die folgenden Systemeigenschaften festlegen, um die Verwendung der neuen Methode zur Verschlüsselung von Datenträgermetadaten (und der neuen Standard-FBE-Richtlinienversion) unabhängig vom API-Level des ausgelieferten Geräts zu erzwingen:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.volume.metadata.method=dm-default-key \
ro.crypto.dm_default_key.options_format.version=2 \
ro.crypto.volume.options=::v2
Aktuelle Methode
Auf Geräten, die mit Android 11 oder höher auf den Markt kommen, wird für die Metadatenverschlüsselung auf adoptablem Speicher das Kernelmodul dm-default-key verwendet, genau wie beim internen Speicher. Informationen dazu, welche Kernelkonfigurationsoptionen aktiviert werden müssen, finden Sie oben unter Voraussetzungen. Hardware für die Inline-Verschlüsselung, die auf dem internen Speicher des Geräts funktioniert, ist möglicherweise nicht für den adoptable Speicher verfügbar. Daher ist möglicherweise CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y erforderlich.
Standardmäßig wird für die Verschlüsselungsmethode für dm-default-key-Volume-Metadaten der AES-256-XTS-Verschlüsselungsalgorithmus mit 4096-Byte-Kryptosektoren verwendet. Der Algorithmus kann durch Festlegen des Systemattributs ro.crypto.volume.metadata.encryption überschrieben werden. Der Wert dieser Eigenschaft hat dieselbe Syntax wie die oben beschriebene metadata_encryption-fstab-Option. Auf Geräten ohne AES-Beschleunigung kann beispielsweise die Adiantum-Verschlüsselung aktiviert werden, indem ro.crypto.volume.metadata.encryption=adiantum festgelegt wird.
Alte Methode
Auf Geräten mit Startversion Android 10 und niedriger wird für die Metadatenverschlüsselung auf adoptablem Speicher das Kernelmodul dm-crypt anstelle von dm-default-key verwendet:
CONFIG_DM_CRYPT=y
Im Gegensatz zur dm-default-key-Methode werden bei der dm-crypt-Methode Dateiinhalte zweimal verschlüsselt: einmal mit einem FBE-Schlüssel und einmal mit dem Metadatenverschlüsselungsschlüssel. Diese doppelte Verschlüsselung beeinträchtigt die Leistung und ist nicht erforderlich, um die Sicherheitsziele der Metadatenverschlüsselung zu erreichen, da Android dafür sorgt, dass FBE-Schlüssel mindestens so schwer zu kompromittieren sind wie der Metadatenverschlüsselungsschlüssel. Anbieter können Kernelanpassungen vornehmen, um die doppelte Verschlüsselung zu vermeiden, insbesondere durch die Implementierung der Option allow_encrypt_override, die von Android an dm-crypt übergeben wird, wenn die Systemeigenschaft ro.crypto.allow_encrypt_override auf true gesetzt ist.
Diese Anpassungen werden vom gemeinsamen Android-Kernel nicht unterstützt.
Standardmäßig wird für die Verschlüsselungsmethode für dm-crypt-Volumemetadaten der AES-128-CBC-Verschlüsselungsalgorithmus mit ESSIV und 512-Byte-Kryptosektoren verwendet. Dies kann durch Festlegen der folgenden Systemeigenschaften überschrieben werden (die auch für die vollständige Festplattenverschlüsselung verwendet werden):
- Mit
ro.crypto.fde_algorithmwird der Algorithmus für die Metadatenverschlüsselung ausgewählt. Die Optionen sindaes-128-cbcundadiantum. Adiantum kann nur verwendet werden, wenn das Gerät keine AES-Beschleunigung bietet. ro.crypto.fde_sector_sizewählt die Größe des Kryptosektors aus. Die Auswahlmöglichkeiten sind 512, 1024, 2048 und 4096. Verwenden Sie für die Adiantum-Verschlüsselung 4096.