Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (FBE). FBE ermöglicht die Verschlüsselung verschiedener Dateien mit unterschiedlichen Schlüsseln, die unabhängig voneinander entsperrt werden können. Diese Schlüssel werden verwendet, um sowohl Dateiinhalte als auch Dateinamen zu verschlüsseln. Wenn FBE verwendet wird, werden andere Informationen wie Verzeichnislayouts, Dateigrößen, Berechtigungen und Erstellungs-/Änderungszeiten nicht verschlüsselt. Zusammengenommen werden diese anderen Informationen als Dateisystem-Metadaten bezeichnet.
Android 9 hat die Unterstützung für Metadatenverschlüsselung eingeführt. Bei der Metadatenverschlüsselung verschlüsselt ein einziger Schlüssel, der beim Booten vorhanden ist, 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 immer auf adoptierbarem Speicher 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
-Dateisystem 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; Dies ist nichts, was ein OTA ändern sollte.
Die Metadatenverschlüsselung erfordert, dass das Modul dm-default-key
in Ihrem Kernel aktiviert ist. In Android 11 und höher wird dm-default-key
von den allgemeinen Android-Kernels, 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, sofern verfügbar, Inline-Verschlüsselungshardware (Hardware, die Daten verschlüsselt/entschlüsselt, während sie auf dem Weg zum/vom Speichergerät sind). Wenn Sie keine Inline-Verschlüsselungshardware verwenden, ist es auch erforderlich, 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
nicht vom allgemeinen Android-Kernel unterstützt. Es war daher Sache der Anbieter, dm-default-key
zu implementieren.
Metadaten-Dateisystem einrichten
Da nichts in der Benutzerdatenpartition gelesen werden kann, bis der Metadatenverschlüsselungsschlüssel vorhanden ist, muss die Partitionstabelle eine separate Partition namens „Metadatenpartition“ zum Speichern der Keymaster-Blobs, die diesen Schlüssel schützen, beiseite legen. Die Metadatenpartition sollte 16 MB groß sein.
fstab.hardware
muss einen Eintrag für das Metadaten-Dateisystem enthalten, das auf dieser Partition lebt und es unter /metadata
einhängt, einschließlich des formattable
Flags, 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 Einhängepunkt /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
werden, bevor /data
gemountet wird. Um sicherzustellen, dass es früh genug gestartet wird, fügen Sie die folgende Strophe zu init.hardware.rc
:
# We need vold early for metadata encryption on early-fs start vold
Keymaster muss laufen und bereit sein, bevor init versucht, /data
einzuhängen.
init.hardware.rc
sollte bereits eine mount_all
Anweisung enthalten, die /data
selbst in der Zeile on late-fs
einhängt. Fügen Sie vor dieser Zeile die Direktive hinzu, um den Dienst wait_for_keymaster
:
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 keydirectory=/metadata/vold/metadata_encryption
zur Spalte fs_mgr_flags des fstab
-Eintrags für userdata
. 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 Metadaten-Verschlüsselungsalgorithmus im internen Speicher AES-256-XTS. Dies kann überschrieben werden, indem die Option metadata_encryption
gesetzt wird, ebenfalls in der Spalte fs_mgr_flags :
- Auf Geräten ohne AES-Beschleunigung kann die Adiantum-Verschlüsselung aktiviert werden, indem
metadata_encryption=adiantum
gesetzt wird. - Auf Geräten, die hardwareverpackte Schlüssel unterstützen, kann der Metadatenverschlüsselungsschlüssel hardwareverpackt werden, indem
metadata_encryption=aes-256-xts:wrappedkey_v0
(oder äquivalentmetadata_encryption=:wrappedkey_v0
, daaes-256-xts
der Standardalgorithmus ist) eingestellt wird.
Da sich die Kernel-Schnittstelle zu dm-default-key
in Android 11 geändert hat, müssen Sie auch sicherstellen, dass Sie den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL
in device.mk
. 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 Ebene der Versand-API zu erzwingen:
PRODUCT_PROPERTY_OVERRIDES += \ ro.crypto.dm_default_key.options_format.version=2
Validierung
Um zu überprüfen, ob die Metadatenverschlüsselung aktiviert ist und ordnungsgemäß funktioniert, führen Sie die unten beschriebenen Tests durch. Beachten Sie auch die unten beschriebenen allgemeinen 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 ähnlich sein wie:
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 standardmäßigen Verschlüsselungseinstellungen außer Kraft setzen, indem Sie die Option metadata_encryption
in der fstab
des Geräts festlegen, weicht die Ausgabe geringfügig von der obigen 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 Korrektheit 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 metadatenverschlüsselte /data
-Partition einhängt, führt init
das vdc-Tool aus. Das vdc-Tool stellt über binder
eine Verbindung zu vold
, um das mit Metadaten verschlüsselte Gerät einzurichten und die Partition zu mounten. Für die Dauer dieses Aufrufs wird init
blockiert, und Versuche, init
-Eigenschaften entweder zu lesen oder zu setzen, werden blockiert, bis mount_all
beendet ist. Wenn zu diesem Zeitpunkt ein Teil der Arbeit von vold
direkt oder indirekt beim Lesen oder Festlegen einer Eigenschaft blockiert wird, kommt es zu einem Deadlock. Es ist wichtig sicherzustellen, dass vold
die Arbeit des Lesens der Schlüssel, die Interaktion mit Keymaster und das Mounten des Datenverzeichnisses abschließen kann, ohne weiter mit init
zu interagieren.
Wenn Keymaster nicht vollständig gestartet ist, wenn mount_all
läuft, wird es nicht auf vold
antworten, bis es bestimmte Eigenschaften von init
gelesen hat, was genau zu dem beschriebenen Deadlock führt. Das Platzieren exec_start wait_for_keymaster
über dem relevanten mount_all
Aufruf, wie dargelegt, stellt sicher, dass Keymaster im Voraus vollständig ausgeführt wird, und vermeidet so diesen Deadlock.
Konfiguration auf akzeptablem Speicher
Seit Android 9 ist eine Form der Metadatenverschlüsselung immer auf adoptierbarem Speicher aktiviert, wenn FBE aktiviert ist, selbst wenn die Metadatenverschlüsselung auf dem internen Speicher nicht aktiviert ist.
In AOSP gibt es zwei Implementierungen der Metadatenverschlüsselung auf adoptierbarem Speicher: eine veraltete basierend auf dm-crypt
und eine neuere basierend auf dm-default-key
. Um sicherzustellen, dass die richtige Implementierung für Ihr Gerät ausgewählt wird, stellen Sie sicher, dass Sie den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL
in device.mk
. 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 Verschlüsselungsmethode für Volume-Metadaten (und der neuen standardmäßigen FBE-Richtlinienversion) unabhängig von der Ebene der Versand-API 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 adoptierbarem Speicher das Kernelmodul dm-default-key
, genau wie auf dem internen 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, möglicherweise auf adoptierbarem Speicher 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 ro.crypto.volume.metadata.encryption
festgelegt wird. Der Wert dieser Eigenschaft hat dieselbe Syntax wie die oben beschriebene fstab-Option metadata_encryption
. Beispielsweise kann auf Geräten ohne AES-Beschleunigung die Adiantum-Verschlüsselung aktiviert werden, indem ro.crypto.volume.metadata.encryption=adiantum
wird.
Legacy-Methode
Auf Geräten, die mit Android 10 oder niedriger gestartet werden, verwendet die Metadatenverschlüsselung auf adoptierbarem Speicher das Kernelmodul dm-crypt
anstelle von dm-default-key
:
CONFIG_DM_CRYPT=y
Im Gegensatz zur dm-default-key
-Methode bewirkt die dm-crypt
Methode, dass Dateiinhalte zweimal verschlüsselt werden: einmal mit einem FBE-Schlüssel und einmal mit dem Metadaten-Verschlüsselungsschlüssel. Diese doppelte Verschlüsselung reduziert die Leistung und ist nicht erforderlich, um die Sicherheitsziele der Metadatenverschlüsselung zu erreichen, da Android sicherstellt, dass FBE-Schlüssel mindestens so schwer zu kompromittieren sind wie der Metadaten-Verschlüsselungsschlüssel. Anbieter können Kernel-Anpassungen vornehmen, um die doppelte Verschlüsselung zu vermeiden, insbesondere durch Implementieren der Option allow_encrypt_override
, die Android an dm-crypt
weitergibt, 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
Volumen-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 keine AES-Beschleunigung hat. -
ro.crypto.fde_sector_size
wählt die Krypto-Sektorgröße aus. Zur Auswahl stehen 512, 1024, 2048 und 4096. Verwenden Sie für die Adiantum-Verschlüsselung 4096.