Metadatenverschlüsselung

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 entsprechend metadata_encryption=:wrappedkey_v0 , da aes-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 stehen aes-128-cbc und adiantum . 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.