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} --late
Metadatenverschlü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=adiantum
aktiviert 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-xts
der 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 root
adb 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_algorithm
wählt den Metadaten-Verschlüsselungsalgorithmus aus. Zur Auswahl stehenaes-128-cbc
undadiantum
. Adiantum darf nur verwendet werden, wenn das Gerät über keine AES-Beschleunigung verfügt. -
ro.crypto.fde_sector_size
wählt die Größe des Kryptosektors aus. Zur Auswahl stehen 512, 1024, 2048 und 4096. Für die Adiantum-Verschlüsselung verwenden Sie 4096.