Android 7.0 und höher unterstützen die dateibasierte Verschlüsselung (File-Based Encryption, FBE). FBE ermöglicht die Verschlüsselung verschiedener Dateien mit verschiedenen Schlüsseln, 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. Zusammen werden diese anderen Informationen als Dateisystemmetadaten bezeichnet.
Mit Android 9 wurde die Metadatenverschlüsselung unterstützt. 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 im Adoptable Storage immer aktiviert, wenn FBE aktiviert ist. Die Metadatenverschlüsselung kann auch im 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 auf internem 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 zuerst 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 allgemeinen Android-Kerneln Version 4.14 und höher unterstützt. Diese Version von dm-default-key verwendet ein hardware- und anbieterunabhängiges Verschlüsselungsframework namens blk-crypto.
Verwenden Sie Folgendes, um dm-default-key zu aktivieren:
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 Inline-Verschlüsselungshardware verwenden, müssen Sie außerdem ein Fallback auf die Cryptography 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 nicht vom allgemeinen Android-Kernel unterstützt. Daher lag es 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 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 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-Stanza bereitstellt. Fügen Sie vor dieser Zeile die Anweisung ein, um den Dienst wait_for_keymaster auszuführen:
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 in die Spalte fs_mgr_flags des Eintrags fstab für userdata ein. 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. Dies kann überschrieben werden, 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 hardwareverpackte Schlüssel unterstützen, kann der Metadaten-Verschlüsselungsschlüssel hardwareverpackt werden. Dazu legen Sie
metadata_encryption=aes-256-xts:wrappedkey_v0fest (oder entsprechendmetadata_encryption=:wrappedkey_v0, daaes-256-xtsder Standardalgorithmus ist).
Da sich die Kernel-Schnittstelle zu dm-default-key in Android 11 geändert hat, müssen Sie außerdem prüfen, ob 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 das folgende Systemattribut 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 außerdem die unten beschriebenen häufigen Probleme.
Tests
Führen Sie zuerst den folgenden Befehl aus, um zu prüfen, ob die Metadatenverschlüsselung 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. Wichtig ist, dass vold das Lesen der Schlüssel, die Interaktion mit Keymaster und das Bereitstellen des Datenverzeichnisses ohne weitere Interaktion mit init abschließen kann.
Wenn Keymaster bei der Ausführung von mount_all nicht vollständig gestartet wird, reagiert er erst auf vold, wenn er bestimmte Attribute aus init gelesen hat, was genau zum beschriebenen Deadlock führt. Wenn Sie exec_start wait_for_keymaster wie festgelegt oberhalb des relevanten mount_all-Aufrufs platzieren, wird Keymaster im Voraus vollständig ausgeführt und dieses Deadlock wird vermieden.
Konfiguration auf anpassbarem Speicher
Seit Android 9 ist eine Form der Metadatenverschlüsselung auf dem adoptierbaren Speicher immer aktiviert, wenn FBE aktiviert ist, auch wenn die Metadatenverschlüsselung im internen Speicher nicht aktiviert ist.
In AOSP gibt es zwei Implementierungen der Metadatenverschlüsselung auf akzeptablen Speicher: eine verworfene, auf dm-crypt basierende und eine neuere auf dm-default-key basierende Implementierung. Damit die richtige Implementierung für dein Gerät ausgewählt wird, muss in device.mk der richtige Wert für PRODUCT_SHIPPING_API_LEVEL festgelegt sein. Wenn auf deinem Gerät beispielsweise Android 11 (API-Level 30) auf den Markt gebracht wird, sollte device.mk Folgendes enthalten:
PRODUCT_SHIPPING_API_LEVEL := 30
Sie können auch die folgenden Systemattribute festlegen, um die Verwendung der neuen Volume-Metadaten-Verschlüsselungsmethode (und der neuen Standard-FBE-Richtlinienversion) unabhängig vom Versand-API-Level 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 gebracht werden, wird für die Metadatenverschlüsselung auf kompatiblen Speichermedien wie bei internem Speicher das Kernelmodul dm-default-key verwendet. Welche Kernel-Konfigurationsoptionen aktiviert werden müssen, erfahren Sie in den Voraussetzungen oben. Beachten Sie, dass die Inline-Verschlüsselungshardware, die im internen Speicher des Geräts funktioniert, möglicherweise nicht in einem geeigneten Speicher und daher CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y erforderlich ist.
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 dieses Attributs hat dieselbe Syntax wie die oben beschriebene fstab-Option metadata_encryption. Auf Geräten ohne AES-Beschleunigung kann beispielsweise die Adiantum-Verschlüsselung durch Festlegen von ro.crypto.volume.metadata.encryption=adiantum aktiviert werden.
Legacy-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 Kernel-Anpassungen vornehmen, um die doppelte Verschlüsselung zu vermeiden. Dazu implementieren sie insbesondere die Option allow_encrypt_override, die Android an dm-crypt übergibt, wenn das Systemattribut ro.crypto.allow_encrypt_override auf true gesetzt ist.
Diese Anpassungen werden vom allgemeinen Android-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. Dies kann durch Festlegen der folgenden Systemattribute überschrieben werden, die auch für FDE 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 bietet.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 4096.