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 alternativmetadata_encryption=:wrappedkey_v0
, daaes-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 sindaes-128-cbc
undadiantum
. 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.