Metadatenverschlüsselung

Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (File-Based Encryption, FBE). Bei FBE können verschiedene Dateien mit unterschiedlichen 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. Wenn FBE verwendet wird, werden andere Informationen wie Verzeichnislayouts, Dateigrößen, Berechtigungen und Erstellungs-/Änderungszeiten nicht verschlüsselt. Zusammenfassend werden diese anderen Informationen als Dateisystemmetadaten bezeichnet.

Unter Android 9 wurde die Unterstützung für die Metadatenverschlüsselung eingeführt. Bei der Metadatenverschlüsselung wird ein einzelner Schlüssel, der beim Booten vorhanden ist, verwendet, um alle Inhalte zu verschlüsseln, die nicht durch FBE verschlüsselt werden. Dieser Schlüssel wird durch KeyMint (früher Keymaster) geschützt, das wiederum durch den verifizierten Bootmodus geschützt wird.

Die Metadatenverschlüsselung ist auf adoptable storage immer aktiviert, wenn 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 kommen, muss die Metadatenverschlüsselung im 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 Initialisierungssequenz ä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 kann nicht durch ein OTA-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 gemeinsamen Android-Kernels ab Version 4.14 unterstützt. Diese Version von dm-default-key verwendet ein hardware- und anbieterunabhängiges Verschlüsselungs-Framework 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, sofern verfügbar, Inline-Verschlüsselungshardware (Hardware, die Daten verschlüsselt/entschlüsselt, während sie zum/vom Speichergerät übertragen werden). Wenn Sie keine Inline-Verschlüsselungshardware verwenden, müssen Sie auch einen Fallback auf die Kryptografie-API des Kernels aktivieren:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Wenn Sie keine Inline-Verschlüsselungshardware 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 nicht vom gemeinsamen Android-Kernel unterstützt. Es lag daher an den Anbietern, dm-default-key zu implementieren.

Metadaten-Dateisystem einrichten

Da nichts in der userdata-Partition gelesen werden kann, bis der Metadaten-Verschlüsselungsschlüssel vorhanden ist, muss in der Partitionstabelle eine separate Partition namens Metadatenpartition für die Speicherung der KeyMint-Blobs reserviert werden, 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 und unter /metadata bereitgestellt wird. Dazu gehört auch das Flag formattable, damit es beim Booten formatiert wird. Das f2fs-Dateisystem funktioniert nicht auf kleineren Partitionen. Wir empfehlen stattdessen die Verwendung von 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 sie früh genug gestartet wird, fügen Sie init.hardware.rc den folgenden Abschnitt hinzu:

# We need vold early for metadata encryption
on early-fs
    start vold

KeyMint muss ausgeführt und bereit sein, bevor init versucht, /data zu mounten.

init.hardware.rc sollte bereits eine mount_all-Anweisung enthalten, mit der /data selbst im on late-fs-Abschnitt eingebunden wird. 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 schließlich keydirectory=/metadata/vold/metadata_encryption der Spalte fs_mgr_flags des Eintrags fstab 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 auf dem internen Speicher AES‑256‑XTS. Dies kann durch Festlegen der Option metadata_encryption überschrieben werden, ebenfalls in der Spalte fs_mgr_flags:

  • Auf Geräten ohne AES-Beschleunigung kann die Adiantum-Verschlüsselung durch Festlegen von metadata_encryption=adiantum aktiviert werden.
  • Auf Geräten, die Hardware-Wrapped Keys unterstützen, kann der Metadatenverschlüsselungsschlüssel durch Festlegen von metadata_encryption=aes-256-xts:wrappedkey_v0 (oder alternativ metadata_encryption=:wrappedkey_v0, da aes-256-xts der Standardalgorithmus ist) in einen Hardware-Wrapped Key umgewandelt werden.

Da sich die Kernelschnittstelle zu dm-default-key in Android 11 geändert hat, müssen Sie auch darauf achten, dass Sie den richtigen Wert für PRODUCT_SHIPPING_API_LEVEL in device.mk 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 vom Versand-API-Level 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 auch die häufigen Probleme, die unten beschrieben werden.

Tests

Führen Sie zuerst den folgenden Befehl aus, um zu prüfen, ob die Metadatenverschlüsselung im internen Speicher aktiviert ist:

adb root
adb 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 im fstab des Geräts festgelegt haben, weicht die Ausgabe geringfügig von der oben gezeigten ab. Wenn Sie beispielsweise die Adiantum-Verschlüsselung aktiviert haben, ist 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 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, mit dem die metadatenverschlüsselte Partition /data gemountet wird, führt init das VDC-Tool aus. Das Tool „vdc“ stellt über binder eine Verbindung zu vold her, um das metadatenverschlüsselte Gerät einzurichten und die Partition bereitzustellen. Während dieses Anrufs ist init blockiert. Versuche, init-Attribute zu lesen oder festzulegen, werden blockiert, bis mount_all abgeschlossen ist. Wenn in dieser Phase ein Teil der Arbeit von vold direkt oder indirekt durch das Lesen oder Festlegen einer Eigenschaft blockiert wird, kommt es zu einem Deadlock. Es ist wichtig, dass vold die Arbeit des Lesens der Schlüssel, der Interaktion mit KeyMint und des Einbindens des Datenverzeichnisses ohne weitere Interaktion mit init ausführen kann.

Wenn KeyMint beim Ausführen von mount_all nicht vollständig gestartet ist, reagiert es erst auf vold, wenn bestimmte Eigenschaften aus init gelesen wurden. Dies führt genau zu dem beschriebenen Deadlock. Wenn Sie exec_start wait_for_keymaster über dem entsprechenden mount_all-Aufruf platzieren, wie oben beschrieben, wird KeyMint vollständig im Voraus ausgeführt und dieser Deadlock wird vermieden.

Konfiguration auf verwendbarem Speicher

Seit Android 9 ist eine Form der Metadatenverschlüsselung immer auf adoptable storage 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 adoptablem Speicher: eine eingestellte, die auf dm-crypt basiert, und eine neuere, die auf dm-default-key basiert. Damit die richtige Implementierung für Ihr Gerät 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 Datenträgermetadaten (und der neuen Standard-FBE-Richtlinienversion) unabhängig vom API-Level des ausgelieferten Geräts 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 auf den Markt kommen, wird für die Metadatenverschlüsselung auf adoptablem Speicher das Kernelmodul dm-default-key verwendet, genau wie beim internen Speicher. Informationen dazu, welche Kernelkonfigurationsoptionen aktiviert werden müssen, finden Sie oben unter Voraussetzungen. Hardware für die Inline-Verschlüsselung, die auf dem internen Speicher des Geräts funktioniert, ist möglicherweise nicht für den adoptable Speicher verfügbar. Daher ist möglicherweise CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y erforderlich.

Standardmäßig wird für die Verschlüsselungsmethode für dm-default-key-Volume-Metadaten der AES-256-XTS-Verschlüsselungsalgorithmus mit 4096-Byte-Kryptosektoren verwendet. Der Algorithmus kann durch Festlegen des Systemattributs ro.crypto.volume.metadata.encryption überschrieben werden. 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 aktiviert werden, indem ro.crypto.volume.metadata.encryption=adiantum festgelegt wird.

Alte Methode

Auf Geräten mit Startversion Android 10 und niedriger wird für die Metadatenverschlüsselung auf adoptablem Speicher das Kernelmodul dm-crypt anstelle von dm-default-key verwendet:

CONFIG_DM_CRYPT=y

Im Gegensatz zur dm-default-key-Methode werden bei der dm-crypt-Methode Dateiinhalte zweimal verschlüsselt: einmal mit einem FBE-Schlüssel und einmal mit dem Metadatenverschlüsselungsschlüssel. Diese doppelte Verschlüsselung beeinträchtigt 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 kompromittieren sind wie der Metadatenverschlüsselungsschlüssel. Anbieter können Kernelanpassungen vornehmen, um die doppelte Verschlüsselung zu vermeiden, insbesondere durch die Implementierung der Option allow_encrypt_override, die von Android an dm-crypt übergeben wird, wenn die Systemeigenschaft ro.crypto.allow_encrypt_override auf true gesetzt ist. Diese Anpassungen werden vom gemeinsamen Android-Kernel nicht unterstützt.

Standardmäßig wird für die Verschlüsselungsmethode für dm-crypt-Volumemetadaten der AES-128-CBC-Verschlüsselungsalgorithmus mit ESSIV und 512-Byte-Kryptosektoren verwendet. Dies kann durch Festlegen der folgenden Systemeigenschaften überschrieben werden (die auch für die vollständige Festplattenverschlüsselung verwendet werden):

  • Mit ro.crypto.fde_algorithm wird der Algorithmus für die Metadatenverschlüsselung ausgewählt. Die Optionen sind aes-128-cbc und adiantum. Adiantum kann nur verwendet werden, wenn das Gerät keine AES-Beschleunigung bietet.
  • ro.crypto.fde_sector_size wählt die Größe des Kryptosektors aus. Die Auswahlmöglichkeiten sind 512, 1024, 2048 und 4096. Verwenden Sie für die Adiantum-Verschlüsselung 4096.