Metadatenverschlüsselung

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