Android 7.0 und höher unterstützen die dateibasierte Verschlüsselung (File-Based Encryption, FBE). Mit FBE können verschiedene Dateien mit verschiedenen 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. Bei der Verwendung von FBE werden andere Informationen wie Verzeichnislayouts, Dateigrößen, Berechtigungen und Erstellungs-/Änderungszeiten nicht verschlüsselt. Diese anderen Informationen werden als Dateisystemmetadaten bezeichnet.
Mit Android 9 wurde die Unterstützung für die Verschlüsselung von Metadaten eingeführt. Bei der Metadatenverschlüsselung werden alle Inhalte, die nicht durch die FBE verschlüsselt werden, mit einem einzigen Schlüssel verschlüsselt, der zum Zeitpunkt des Starts vorhanden ist. Dieser Schlüssel wird durch Keymaster geschützt, der wiederum durch den verifizierten Bootmodus geschützt wird.
Die Metadatenverschlüsselung ist immer für angepassten Speicher aktiviert, wenn die 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 gebracht wurden, muss die Metadatenverschlüsselung für den 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 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. Sie sollte nicht über ein Over-the-air-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 Android Common Kernels ab Version 4.14 unterstützt. Diese Version von dm-default-key verwendet ein hardware- und anbieterunabhängiges Verschlüsselungsframework 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 Inline-Verschlüsselungshardware (Hardware, die Daten verschlüsselt/entschlüsselt, während sie auf dem Weg zum/vom Speichergerät sind), sofern verfügbar. Wenn Sie keine Hardware für die Inline-Verschlüsselung verwenden, müssen Sie auch einen Fallback auf die Kryptografie-API des Kernels aktivieren:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Wenn Sie keine Hardware für die Inline-Verschlüsselung 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 vom Android Common Kernel nicht unterstützt. Es lag also an den Anbietern, dm-default-key zu implementieren.
Metadatendateisystem einrichten
Da nichts in der userdata-Partition gelesen werden kann, bevor der Metadaten-Verschlüsselungsschlüssel vorhanden ist, muss in der Partitionstabelle eine separate Partition namens „Metadatenpartition“ für das Speichern der Keymaster-Blobs reserviert werden, die diesen Schlüssel schützen. Die Metadatenpartition sollte 16 MB groß sein.
fstab.hardware muss einen Eintrag für das Metadatendateisystem enthalten, das sich auf dieser Partition befindet und unter /metadata bereitgestellt wird. Außerdem muss das Flag formattable angegeben werden, damit es beim Starten formatiert wird. Das Dateisystem „f2fs“ funktioniert nicht auf kleineren Partitionen. Wir empfehlen stattdessen „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 der Dienst früh genug gestartet wird, fügen Sie init.hardware.rc die folgende Strophe hinzu:
# We need vold early for metadata encryption
on early-fs
start vold
Keymaster muss ausgeführt und bereit sein, bevor init versucht, /data bereitzustellen.
init.hardware.rc sollte bereits eine mount_all-Anweisung enthalten, die /data selbst in der on
late-fs-Strophe bereitstellt. 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 abschließend keydirectory=/metadata/vold/metadata_encryption der 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 AES-256-XTS der Metadatenverschlüsselungsalgorithmus für den internen Speicher. Sie können dies überschreiben, indem Sie die Option metadata_encryption auch in der Spalte fs_mgr_flags festlegen:
- Auf Geräten ohne AES-Beschleunigung kann die Adiantum-Verschlüsselung durch Festlegen von
metadata_encryption=adiantumaktiviert werden. - Auf Geräten, die hardwareverschlüsselte Schlüssel unterstützen, kann der Metadatenverschlüsselungsschlüssel hardwareverschlüsselt werden, indem
metadata_encryption=aes-256-xts:wrappedkey_v0(odermetadata_encryption=:wrappedkey_v0) festgelegt wird, daaes-256-xtsder Standardalgorithmus ist.
Da sich die Kernelschnittstelle zu dm-default-key in Android 11 geändert hat, müssen Sie auch darauf achten, 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) 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 von der Versand-API-Ebene 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 außerdem die häufigen Probleme, die unten beschrieben werden.
Tests
Führen Sie zuerst den folgenden Befehl aus, um zu prüfen, ob die Verschlüsselung von Metadaten auf dem 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 in der fstab des Geräts festgelegt haben, unterscheidet sich die Ausgabe geringfügig von der oben. 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 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, bei dem die mit Metadaten verschlüsselte /data-Partition bereitgestellt wird, 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. Während dieses Aufrufs ist init blockiert und Versuche, init-Properties zu lesen oder festzulegen, werden blockiert, bis mount_all abgeschlossen ist.
Wenn in dieser Phase ein Teil der Arbeit von vold direkt oder indirekt beim Lesen oder Festlegen einer Property blockiert ist, kommt es zu einem Deadlock. Es ist wichtig, dass vold die Schlüssel lesen, mit Keymaster interagieren und das Datenverzeichnis bereitstellen kann, ohne weitere Interaktionen mit init.
Wenn Keymaster beim Ausführen von mount_all nicht vollständig gestartet ist, antwortet er erst auf vold, wenn er bestimmte Eigenschaften aus init gelesen hat. Dies führt genau zu der beschriebenen Sackgasse. Wenn du exec_start wait_for_keymaster wie oben beschrieben über die entsprechende mount_all-Aufrufmethode platzierst, wird Keymaster im Voraus vollständig ausgeführt und dieser Deadlock wird vermieden.
Konfiguration auf adoptable storage
Seit Android 9 ist eine Form der Metadatenverschlüsselung immer auf angepasstem Speicher aktiviert, wenn die 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 adoptable storage: eine veraltete, die auf dm-crypt basiert, und eine neuere, die auf dm-default-key basiert. Damit für Ihr Gerät die richtige Implementierung 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 Volume-Metadaten (und der neuen Standardversion der FBE-Richtlinie) unabhängig von der API-Auslieferungsebene 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 ausgeliefert werden, wird für die Verschlüsselung von Metadaten auf adoptable storage wie beim internen Speicher das dm-default-key-Kernelmodul verwendet. Welche Kernelkonfigurationsoptionen Sie aktivieren müssen, finden Sie in den Voraussetzungen oben. Beachten Sie, dass Inline-Verschlüsselungshardware, die auf dem internen Speicher des Geräts funktioniert, für adoptable Storage möglicherweise nicht verfügbar ist. Daher ist möglicherweise CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y erforderlich.
Standardmäßig verwendet die dm-default-key-Methode zur Verschlüsselung von Volume-Metadaten den AES-256-XTS-Verschlüsselungsalgorithmus mit 4.096-Byte-Kryptosektoren. Der Algorithmus kann überschrieben werden, indem Sie die Systemeigenschaft ro.crypto.volume.metadata.encryption festlegen. 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 durch Festlegen von ro.crypto.volume.metadata.encryption=adiantum aktiviert werden.
Alte Methode
Auf Geräten, die mit Android 10 oder niedriger ausgeliefert werden, wird für die Verschlüsselung von Metadaten auf zuweisbarem Speicher das Kernelmodul dm-crypt anstelle von dm-default-key verwendet:
CONFIG_DM_CRYPT=y
Im Gegensatz zur dm-default-key-Methode wird bei der dm-crypt-Methode der Dateiinhalt zweimal verschlüsselt: 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 dafür sorgt, dass FBE-Schlüssel mindestens so schwer zu manipulieren sind wie der Metadatenverschlüsselungsschlüssel. Anbieter können Kernelanpassungen vornehmen, um die doppelte Verschlüsselung zu vermeiden. Dazu können sie insbesondere die Option allow_encrypt_override implementieren, die Android an dm-crypt weitergibt, wenn die Systemeigenschaft ro.crypto.allow_encrypt_override auf true gesetzt ist.
Diese Anpassungen werden vom Android Common Kernel nicht unterstützt.
Standardmäßig wird für die Verschlüsselungsmethode der Volume-Metadaten von dm-crypt der AES-128-CBC-Verschlüsselungsalgorithmus mit ESSIV und 512-Byte-Kryptosektoren verwendet. Diese Einstellung kann überschrieben werden, indem Sie die folgenden Systemeigenschaften festlegen, die auch für die Datenträgervollverschlüsselung verwendet werden:
ro.crypto.fde_algorithmwählt den Algorithmus für die Metadatenverschlüsselung aus. Die Auswahlmöglichkeiten sindaes-128-cbcundadiantum. Adiantum kann nur verwendet werden, wenn das Gerät keine AES-Beschleunigung hat.ro.crypto.fde_sector_sizewählt die Größe des Kryptosektors aus. Folgende Optionen sind verfügbar: 512, 1024, 2048 und 4096. Verwenden Sie für die Adiantum-Verschlüsselung den Wert 4096.