Android 7.0 und höher unterstützt dateibasierte Verschlüsselung (FBE). FBE ermöglicht die Verschlüsselung verschiedener Dateien mit unterschiedlichen Schlüsseln, die unabhängig voneinander entsperrt werden können. Mit diesen Schlüsseln werden sowohl Dateiinhalte als auch Dateinamen verschlüsselt. Bei Verwendung von FBE werden andere Informationen wie Verzeichnislayouts, Dateigrößen, Berechtigungen und Erstellungs-/Änderungszeiten nicht verschlüsselt. Zusammengenommen werden diese anderen Informationen als Dateisystem-Metadaten bezeichnet.
Mit Android 9 wurde die Unterstützung für die Metadatenverschlüsselung eingeführt. Bei der Metadatenverschlüsselung verschlüsselt ein einzelner, beim Booten vorhandener Schlüssel alle Inhalte, die nicht von FBE verschlüsselt werden. Dieser Schlüssel wird durch Keymaster geschützt, der wiederum durch verifizierten Start geschützt ist.
Die Metadatenverschlüsselung ist auf dem anpassbaren Speicher immer aktiviert, wenn FBE aktiviert ist. Die Metadatenverschlüsselung kann auch im internen Speicher aktiviert werden. Bei Geräten, die mit Android 11 oder höher gestartet werden, muss die Metadatenverschlüsselung im internen Speicher aktiviert sein.
Implementierung auf internem Speicher
Sie können die Metadatenverschlüsselung im internen Speicher neuer Geräte einrichten, indem Sie das metadata einrichten, die Init-Sequenz ä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. Daran sollte ein OTA nichts ändern.
Für die Metadatenverschlüsselung muss das Modul dm-default-key in Ihrem Kernel aktiviert sein. In Android 11 und höher wird dm-default-key von den gängigen Android-Kerneln, Version 4.14 und höher, unterstützt. Diese Version von dm-default-key verwendet ein hardware- und herstellerunabhängiges Verschlüsselungsframework namens blk-crypto .
Um dm-default-key zu aktivieren, verwenden Sie:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key verwendet Inline-Verschlüsselungshardware (Hardware, die Daten auf dem Weg zum/vom Speichergerät verschlüsselt/entschlüsselt), sofern verfügbar. Wenn Sie keine Inline-Verschlüsselungshardware verwenden, ist es auch notwendig, einen Fallback auf die Kryptografie-API des Kernels zu aktivieren:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Wenn Sie keine Inline-Verschlüsselungshardware verwenden, sollten Sie auch jede verfügbare CPU-basierte Beschleunigung aktivieren, wie in der FBE-Dokumentation empfohlen.
In Android 10 und niedriger wurde dm-default-key vom allgemeinen Android-Kernel nicht unterstützt. Es lag daher an den Anbietern dm-default-key zu implementieren.
Metadaten-Dateisystem einrichten
Da nichts in der Benutzerdatenpartition gelesen werden kann, bis der Metadaten-Verschlüsselungsschlüssel vorhanden ist, muss die Partitionstabelle eine separate Partition namens „Metadatenpartition“ für die Speicherung der Keymaster-Blobs reservieren, 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, indem es unter /metadata gemountet wird, einschließlich des formattable , um sicherzustellen, dass es beim Booten formatiert wird. Das f2fs-Dateisystem funktioniert nicht auf kleineren Partitionen; Wir empfehlen stattdessen die Verwendung von ext4. Zum Beispiel:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
Um sicherzustellen, dass der Mountpunkt /metadata vorhanden ist, fügen Sie die folgende Zeile zu BoardConfig-common.mk hinzu:
BOARD_USES_METADATA_PARTITION := true
Änderungen an der Init-Sequenz
Wenn Metadatenverschlüsselung verwendet wird, muss vold ausgeführt werden, bevor /data gemountet wird. Um sicherzustellen, dass es früh genug gestartet wird, fügen Sie die folgende Zeilengruppe zu init.hardware.rc hinzu:
# We need vold early for metadata encryption
on early-fs
start vold Keymaster muss ausgeführt und bereit sein, bevor init versucht /data einzuhängen.
init.hardware.rc sollte bereits eine mount_all Anweisung enthalten, die /data selbst in der Strophe on late-fs einhängt. Fügen Sie vor dieser Zeile die Anweisung zum Ausführen des Dienstes wait_for_keymaster 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} --lateMetadatenverschlüsselung einschalten
Fügen Sie schließlich keydirectory=/metadata/vold/metadata_encryption zur Spalte fs_mgr_flags des fstab Eintrags 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 im internen Speicher AES-256-XTS. Dies kann überschrieben werden, indem die Option metadata_encryption ebenfalls in der Spalte fs_mgr_flags festgelegt wird:
- Auf Geräten ohne AES-Beschleunigung kann die Adiantum-Verschlüsselung durch die Einstellung
metadata_encryption=adiantumaktiviert werden. - Auf Geräten, die in Hardware verpackte Schlüssel unterstützen, kann der Metadatenverschlüsselungsschlüssel durch Festlegen von
metadata_encryption=aes-256-xts:wrappedkey_v0(oder entsprechendmetadata_encryption=:wrappedkey_v0, daaes-256-xtsder Standardalgorithmus ist) in Hardware verpackt werden.
Da sich die Kernel-Schnittstelle zu dm-default-key in Android 11 geändert hat, müssen Sie auch sicherstellen, dass Sie in device.mk den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL festgelegt haben. Wenn Ihr Gerät beispielsweise mit Android 11 (API-Level 30) gestartet wird, sollte device.mk 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 von der Versand-API-Ebene zu erzwingen:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.dm_default_key.options_format.version=2
Validierung
Führen Sie die unten beschriebenen Tests aus, um zu überprüfen, ob die Metadatenverschlüsselung aktiviert ist und ordnungsgemäß funktioniert. Beachten Sie auch die unten beschriebenen häufigen Probleme .
Tests
Führen Sie zunächst den folgenden Befehl aus, um zu überprüfen, ob die Metadatenverschlüsselung im internen Speicher aktiviert ist:
adb rootadb shell dmctl table userdata
Die Ausgabe sollte 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 überschreiben, indem Sie die Option metadata_encryption in der fstab des Geräts festlegen, weicht die Ausgabe geringfügig von der oben genannten ab. Wenn Sie beispielsweise die Adiantum-Verschlüsselung aktiviert haben, lautet 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 der FBE zu überprü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 , der die mit Metadaten verschlüsselte /data Partition bereitstellt, führt init das vdc-Tool aus. Das VDC-Tool stellt über binder eine Verbindung zu vold her, um das mit Metadaten verschlüsselte Gerät einzurichten und die Partition bereitzustellen. Für die Dauer dieses Aufrufs ist init blockiert und Versuche, init Eigenschaften entweder zu lesen oder festzulegen, werden blockiert, bis mount_all abgeschlossen ist. Wenn zu diesem Zeitpunkt ein Teil der Arbeit von vold beim Lesen oder Festlegen einer Eigenschaft direkt oder indirekt blockiert wird, kommt es zu einem Deadlock. Es ist wichtig sicherzustellen, dass vold das Lesen der Schlüssel, die Interaktion mit Keymaster und das Mounten des Datenverzeichnisses ohne weitere Interaktion mit init abschließen kann.
Wenn Keymaster beim Ausführen mount_all nicht vollständig gestartet ist, antwortet es nicht auf vold , bis es bestimmte Eigenschaften von init gelesen hat, was genau zu dem beschriebenen Deadlock führt. Durch die Platzierung exec_start wait_for_keymaster über dem entsprechenden mount_all Aufruf wird sichergestellt, dass Keymaster im Voraus vollständig ausgeführt wird, und so dieser Deadlock vermieden wird.
Konfiguration auf anpassbarem Speicher
Seit Android 9 ist eine Form der Metadatenverschlüsselung immer auf dem anpassbaren Speicher 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 anpassbarem Speicher: eine veraltete, die auf dm-crypt basiert, und eine neuere, die auf dm-default-key basiert. Um sicherzustellen, dass die richtige Implementierung für Ihr Gerät ausgewählt wird, stellen Sie sicher, dass Sie in device.mk den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL festgelegt haben. Wenn Ihr Gerät beispielsweise mit Android 11 (API-Level 30) gestartet wird, sollte device.mk enthalten:
PRODUCT_SHIPPING_API_LEVEL := 30
Sie können auch die folgenden Systemeigenschaften festlegen, um die Verwendung der neuen Volume-Metadaten-Verschlüsselungsmethode (und der neuen Standard-FBE-Richtlinienversion) unabhängig von der Versand-API-Ebene 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 gestartet werden, verwendet die Metadatenverschlüsselung auf anpassbarem Speicher das Kernelmodul dm-default-key , genau wie auf internem Speicher. Sehen Sie sich die Voraussetzungen oben an, um zu erfahren, welche Kernel-Konfigurationsoptionen aktiviert werden müssen. Beachten Sie, dass Inline-Verschlüsselungshardware, die auf dem internen Speicher des Geräts funktioniert, auf anpassbarem Speicher möglicherweise nicht verfügbar ist und daher möglicherweise CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y erforderlich ist.
Standardmäßig verwendet die dm-default-key Volume-Metadaten-Verschlüsselungsmethode den AES-256-XTS-Verschlüsselungsalgorithmus mit 4096-Byte-Kryptosektoren. Der Algorithmus kann überschrieben werden, indem die Systemeigenschaft ro.crypto.volume.metadata.encryption festgelegt wird. Der Wert dieser Eigenschaft hat dieselbe Syntax wie die oben beschriebene fstab-Option metadata_encryption . Auf Geräten ohne AES-Beschleunigung kann die Adiantum-Verschlüsselung beispielsweise durch die Einstellung ro.crypto.volume.metadata.encryption=adiantum aktiviert werden.
Legacy-Methode
Auf Geräten, die mit Android 10 oder niedriger gestartet werden, verwendet die Metadatenverschlüsselung auf anpassbarem Speicher das dm-crypt Kernelmodul anstelle von dm-default-key :
CONFIG_DM_CRYPT=y
Im Gegensatz zur dm-default-key Methode führt die dm-crypt Methode dazu, dass Dateiinhalte zweimal verschlüsselt werden: einmal mit einem FBE-Schlüssel und einmal mit dem Metadaten-Verschlüsselungsschlüssel. Diese doppelte Verschlüsselung verringert die Leistung und ist nicht erforderlich, um die Sicherheitsziele der Metadatenverschlüsselung zu erreichen, da Android sicherstellt, dass FBE-Schlüssel mindestens genauso schwer zu kompromittieren sind wie der Metadatenverschlüsselungsschlüssel. Anbieter können Kernel-Anpassungen vornehmen, um die doppelte Verschlüsselung zu vermeiden, insbesondere durch Implementierung der Option „ allow_encrypt_override “, die Android an dm-crypt übergibt, wenn die Systemeigenschaft „ ro.crypto.allow_encrypt_override “ auf „ true gesetzt ist. Diese Anpassungen werden vom allgemeinen Android-Kernel nicht unterstützt.
Standardmäßig verwendet die dm-crypt Volume-Metadaten-Verschlüsselungsmethode den AES-128-CBC-Verschlüsselungsalgorithmus mit ESSIV und 512-Byte-Kryptosektoren. Dies kann überschrieben werden, indem die folgenden Systemeigenschaften festgelegt werden (die auch für FDE verwendet werden):
-
ro.crypto.fde_algorithmwählt den Metadaten-Verschlüsselungsalgorithmus aus. Zur Auswahl stehenaes-128-cbcundadiantum. Adiantum darf nur verwendet werden, wenn das Gerät über keine AES-Beschleunigung verfügt. -
ro.crypto.fde_sector_sizewählt die Größe des Kryptosektors aus. Zur Auswahl stehen 512, 1024, 2048 und 4096. Für die Adiantum-Verschlüsselung verwenden Sie 4096.