Dateibasierte Verschlüsselung

Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (FBE). Die dateibasierte Verschlüsselung ermöglicht die Verschlüsselung verschiedener Dateien mit unterschiedlichen Schlüsseln, die unabhängig voneinander entsperrt werden können.

Dieser Artikel beschreibt, wie Sie die dateibasierte Verschlüsselung auf neuen Geräten aktivieren und wie Systemanwendungen die Direct-Boot-APIs verwenden können, um Benutzern die bestmögliche und sicherste Erfahrung zu bieten.

Alle Geräte, die mit Android 10 und höher gestartet werden, müssen die dateibasierte Verschlüsselung verwenden.

Direkter Start

Die dateibasierte Verschlüsselung ermöglicht eine neue Funktion, die in Android 7.0 namens Direct Boot eingeführt wurde. Direct Boot ermöglicht es verschlüsselten Geräten, direkt zum Sperrbildschirm zu booten. Zuvor mussten Benutzer auf verschlüsselten Geräten mit Full-Disk-Verschlüsselung (FDE) Anmeldeinformationen eingeben, bevor auf Daten zugegriffen werden konnte, wodurch das Telefon daran gehindert wurde, alle außer den grundlegendsten Vorgängen auszuführen. Beispielsweise konnten Alarme nicht funktionieren, Barrierefreiheitsdienste waren nicht verfügbar und Telefone konnten keine Anrufe entgegennehmen, sondern waren nur auf grundlegende Notruffunktionen beschränkt.

Mit der Einführung der dateibasierten Verschlüsselung (FBE) und neuer APIs, um Anwendungen auf die Verschlüsselung aufmerksam zu machen, können diese Apps in einem begrenzten Kontext betrieben werden. Dies kann passieren, bevor Benutzer ihre Anmeldeinformationen angegeben haben, während private Benutzerinformationen weiterhin geschützt sind.

Auf einem FBE-fähigen Gerät stehen jedem Benutzer des Geräts zwei Speicherorte für Anwendungen zur Verfügung:

• Credential Encrypted (CE)-Speicher, der der Standardspeicherort ist und nur verfügbar ist, nachdem der Benutzer das Gerät entsperrt hat.
• Device Encrypted (DE)-Speicher, bei dem es sich um einen Speicherort handelt, der sowohl während des direkten Startmodus als auch nach dem Entsperren des Geräts durch den Benutzer verfügbar ist.

Diese Trennung macht Arbeitsprofile sicherer, da mehr als ein Benutzer gleichzeitig geschützt werden kann, da die Verschlüsselung nicht mehr nur auf einem Boot-Passwort basiert.

Die Direct Boot API ermöglicht verschlüsselungsfähigen Anwendungen den Zugriff auf jeden dieser Bereiche. Es gibt Änderungen am Anwendungslebenszyklus, um der Notwendigkeit gerecht zu werden, Anwendungen zu benachrichtigen, wenn der CE-Speicher eines Benutzers als Reaktion auf die erste Eingabe von Anmeldeinformationen auf dem Sperrbildschirm entsperrt wird oder wenn das Arbeitsprofil eine Arbeitsherausforderung bereitstellt . Geräte mit Android 7.0 müssen diese neuen APIs und Lebenszyklen unterstützen, unabhängig davon, ob sie FBE implementieren oder nicht. Ohne FBE befinden sich DE- und CE-Speicher jedoch immer im entsperrten Zustand.

Eine vollständige Implementierung der dateibasierten Verschlüsselung auf den Dateisystemen Ext4 und F2FS wird im Android Open Source Project (AOSP) bereitgestellt und muss nur auf Geräten aktiviert werden, die die Anforderungen erfüllen. Hersteller, die sich für die Verwendung von FBE entscheiden, möchten möglicherweise Möglichkeiten zur Optimierung der Funktion basierend auf dem verwendeten System-on-Chip (SoC) erkunden.

Alle notwendigen Pakete in AOSP wurden aktualisiert, um Direct-Boot-fähig zu sein. Wenn Gerätehersteller jedoch angepasste Versionen dieser Apps verwenden, sollten sie sicherstellen, dass es mindestens Direct-Boot-fähige Pakete gibt, die die folgenden Dienste bereitstellen:

• Telefoniedienste und Dialer
• Eingabemethode für die Eingabe von Passwörtern auf dem Sperrbildschirm

Beispiele und Quelle

Android bietet eine Referenzimplementierung der dateibasierten Verschlüsselung, in der vold ( system/vold ) die Funktionalität zum Verwalten von Speichergeräten und Volumes auf Android bereitstellt. Das Hinzufügen von FBE stellt vold mehrere neue Befehle zur Verfügung, um die Schlüsselverwaltung für die CE- und DE-Schlüssel mehrerer Benutzer zu unterstützen. Zusätzlich zu den Kernänderungen zur Verwendung der dateibasierten Verschlüsselungsfunktionen im Kernel wurden viele Systempakete, einschließlich des Sperrbildschirms und der SystemUI, modifiziert, um die FBE- und Direct-Boot-Funktionen zu unterstützen. Diese beinhalten:

• AOSP Dialer (Pakete/Apps/Dialer)
• Tischuhr (Pakete/Apps/DeskClock)
• LatinIME (Pakete/Eingabemethoden/LatinIME)*
• Einstellungs-App (Pakete/Apps/Einstellungen)*
• SystemUI (Frameworks/Basis/Pakete/SystemUI)*

* Systemanwendungen, die das Manifestattribut defaultToDeviceProtectedStorage verwenden

Weitere Beispiele für verschlüsselungsfähige Anwendungen und Dienste finden Sie, indem Sie den Befehl mangrep directBootAware im Verzeichnis frameworks oder packages des AOSP-Quellbaums ausführen.

Abhängigkeiten

Um die AOSP-Implementierung von FBE sicher zu verwenden, muss ein Gerät die folgenden Abhängigkeiten erfüllen:

• Kernel-Unterstützung für Ext4-Verschlüsselung oder F2FS-Verschlüsselung.
• Keymaster-Unterstützung mit HAL-Version 1.0 oder höher. Es gibt keine Unterstützung für Keymaster 0.3, da dies nicht die erforderlichen Funktionen bietet oder keinen ausreichenden Schutz für Verschlüsselungsschlüssel gewährleistet.
• Keymaster/ Keystore und Gatekeeper müssen in einer Trusted Execution Environment (TEE) implementiert werden, um Schutz für die DE-Schlüssel bereitzustellen, damit ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht wird) nicht einfach die DE-Schlüssel anfordern kann.
• Hardware Root of Trust und Verified Boot, die an die Keymaster-Initialisierung gebunden sind, sind erforderlich, um sicherzustellen, dass DE-Schlüssel nicht von einem nicht autorisierten Betriebssystem zugänglich sind.

Implementierung

In erster Linie sollten Apps wie Wecker, Telefon und Barrierefreiheitsfunktionen gemäß der Direct Boot- Entwicklerdokumentation android:directBootAware gemacht werden.

Kernel-Unterstützung

Kernel-Unterstützung für Ext4- und F2FS-Verschlüsselung ist in den allgemeinen Android-Kerneln ab Version 3.18 verfügbar. Um es in einem Kernel der Version 5.1 oder höher zu aktivieren, verwenden Sie:

CONFIG_FS_ENCRYPTION=y

Verwenden Sie für ältere Kernel CONFIG_EXT4_ENCRYPTION=y , wenn das userdata Dateisystem Ihres Geräts Ext4 ist, oder verwenden Sie CONFIG_F2FS_FS_ENCRYPTION=y wenn das userdata Dateisystem Ihres Geräts F2FS ist.

Wenn Ihr Gerät Adoptable Storage unterstützt oder Metadatenverschlüsselung im internen Speicher verwendet, aktivieren Sie auch die Kernel-Konfigurationsoptionen, die für die Metadatenverschlüsselung erforderlich sind, wie in der Dokumentation zur Metadatenverschlüsselung beschrieben.

Neben der funktionalen Unterstützung für Ext4- oder F2FS-Verschlüsselung sollten Gerätehersteller auch die kryptografische Beschleunigung aktivieren, um die dateibasierte Verschlüsselung zu beschleunigen und das Benutzererlebnis zu verbessern. Beispielsweise kann auf ARM64-basierten Geräten die Beschleunigung von ARMv8 CE (Cryptography Extensions) aktiviert werden, indem die folgenden Kernel-Konfigurationsoptionen festgelegt werden:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Um die Leistung weiter zu verbessern und den Stromverbrauch zu senken, können Gerätehersteller auch die Implementierung von Inline-Verschlüsselungshardware in Betracht ziehen, die die Daten auf dem Weg zum/vom Speichergerät verschlüsselt/entschlüsselt. Die allgemeinen Android-Kernel (Version 4.14 und höher) enthalten ein Framework, das die Verwendung von Inline-Verschlüsselung ermöglicht, wenn Hardware- und Herstellertreiberunterstützung verfügbar ist. Das Inline-Verschlüsselungsframework kann durch Festlegen der folgenden Kernel-Konfigurationsoptionen aktiviert werden:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Wenn Ihr Gerät UFS-basierten Speicher verwendet, aktivieren Sie auch:

CONFIG_SCSI_UFS_CRYPTO=y

Wenn Ihr Gerät eMMC-basierten Speicher verwendet, aktivieren Sie auch:

CONFIG_MMC_CRYPTO=y

Aktivieren der dateibasierten Verschlüsselung

Um FBE auf einem Gerät zu aktivieren, muss es im internen Speicher ( userdata ) aktiviert werden. Dadurch wird FBE auch automatisch auf Adoptable Storage aktiviert; jedoch kann das Verschlüsselungsformat auf dem verwendbaren Speicher bei Bedarf außer Kraft gesetzt werden.

Interne Speicher

FBE wird aktiviert, indem die Option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] zur Spalte fs_mgr_flags der fstab Zeile für userdata hinzugefügt wird. Diese Option definiert das Verschlüsselungsformat im internen Speicher. Es enthält bis zu drei durch Doppelpunkte getrennte Parameter:

• Der Parameter contents_encryption_mode definiert, welcher kryptografische Algorithmus zum Verschlüsseln von Dateiinhalten verwendet wird. Es kann entweder aes-256-xts oder adiantum sein. Seit Android 11 kann es auch leer gelassen werden, um den Standardalgorithmus anzugeben, der aes-256-xts ist.
• Der Parameter filenames_encryption_mode definiert, welcher kryptografische Algorithmus zum Verschlüsseln von Dateinamen verwendet wird. Es kann entweder aes-256-cts , aes-256-heh , adiantum oder aes-256-hctr2 sein. Wenn nicht angegeben, wird standardmäßig aes-256-cts verwendet, wenn contents_encryption_mode aes-256-xts ist, oder adiantum , wenn contents_encryption_mode adiantum ist.
• Der flags Parameter, neu in Android 11, ist eine Liste von Flags, die durch das + -Zeichen getrennt sind. Die folgenden Flags werden unterstützt:
  • Das v1 -Flag wählt Verschlüsselungsrichtlinien der Version 1 aus; Das v2 Flag wählt Verschlüsselungsrichtlinien der Version 2 aus. Verschlüsselungsrichtlinien der Version 2 verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion . Der Standardwert ist v2, wenn das Gerät auf Android 11 oder höher gestartet wurde (wie durch ro.product.first_api_level bestimmt), oder v1, wenn das Gerät auf Android 10 oder niedriger gestartet wurde.
  • Das Flag inlinecrypt_optimized wählt ein Verschlüsselungsformat aus, das für Inline-Verschlüsselungshardware optimiert ist, die eine große Anzahl von Schlüsseln nicht effizient verarbeitet. Dazu wird nur ein Verschlüsselungsschlüssel für Dateiinhalte pro CE- oder DE-Schlüssel abgeleitet, anstatt einer pro Datei. Die Generierung von IVs (Initialisierungsvektoren) wird entsprechend angepasst.
  • Das Flag emmc_optimized ähnelt inlinecrypt_optimized , wählt aber auch eine IV-Generierungsmethode aus, die IVs auf 32 Bit begrenzt. Dieses Flag sollte nur auf Inline-Verschlüsselungshardware verwendet werden, die mit der JEDEC eMMC v5.2-Spezifikation kompatibel ist und daher nur 32-Bit-IVs unterstützt. Verwenden Sie auf anderer Inline-Verschlüsselungshardware stattdessen inlinecrypt_optimized . Dieses Flag sollte niemals auf UFS-basiertem Speicher verwendet werden; Die UFS-Spezifikation erlaubt die Verwendung von 64-Bit-IVs.
  • Auf Geräten, die hardwareverpackte Schlüssel unterstützen, aktiviert das wrappedkey_v0 Flag die Verwendung von hardwareverpackten Schlüsseln für FBE. Dies kann nur in Kombination mit der Mount-Option inlinecrypt und entweder dem Flag inlinecrypt_optimized oder emmc_optimized verwendet werden.

Wenn Sie keine Inline-Verschlüsselungshardware verwenden, lautet die empfohlene Einstellung für die meisten Geräte fileencryption=aes-256-xts . Wenn Sie Inline-Verschlüsselungshardware verwenden, lautet die empfohlene Einstellung für die meisten Geräte fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (oder gleichwertig fileencryption=::inlinecrypt_optimized ). Auf Geräten ohne AES-Beschleunigung kann Adiantum anstelle von AES verwendet werden, indem fileencryption=adiantum gesetzt wird.

Seit Android 14 (AOSP experimentell) ist AES-HCTR2 der bevorzugte Modus der Dateinamenverschlüsselung für Geräte mit beschleunigten Kryptografieanweisungen. Allerdings unterstützen nur neuere Android-Kernel AES-HCTR2. In einer zukünftigen Android-Version soll es zum Standardmodus für die Verschlüsselung von Dateinamen werden. Wenn Ihr Kernel AES-HCTR2 unterstützt, kann er für die Verschlüsselung von Dateinamen aktiviert werden, indem Sie filenames_encryption_mode auf aes-256-hctr2 setzen. Im einfachsten Fall würde dies mit fileencryption=aes-256-xts:aes-256-hctr2 geschehen.

Auf Geräten, die mit Android 10 oder niedriger gestartet wurden, wird fileencryption=ice auch akzeptiert, um die Verwendung des Verschlüsselungsmodus für Dateiinhalte FSCRYPT_MODE_PRIVATE anzugeben. Dieser Modus wird von den gängigen Android-Kernels nicht implementiert, könnte aber von Anbietern implementiert werden, die benutzerdefinierte Kernel-Patches verwenden. Das von diesem Modus erzeugte On-Disk-Format war herstellerspezifisch. Auf Geräten, die mit Android 11 oder höher starten, ist dieser Modus nicht mehr zulässig und es muss stattdessen ein Standard-Verschlüsselungsformat verwendet werden.

Standardmäßig erfolgt die Verschlüsselung von Dateiinhalten mithilfe der Kryptografie-API des Linux-Kernels. Wenn Sie stattdessen Inline-Verschlüsselungshardware verwenden möchten, fügen Sie auch die inlinecrypt Mount-Option hinzu. Eine vollständige fstab -Zeile könnte beispielsweise so aussehen:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Annehmbarer Speicher

Seit Android 9 können FBE und Adoptable Storage zusammen verwendet werden.

Die Angabe der fstab-Option fileencryption für userdata aktiviert auch automatisch sowohl die FBE- als auch die Metadatenverschlüsselung auf adoptierbarem Speicher. Sie können jedoch die FBE- und/oder Metadatenverschlüsselungsformate auf anpassbarem Speicher überschreiben, indem Sie Eigenschaften in PRODUCT_PROPERTY_OVERRIDES festlegen.

Verwenden Sie auf Geräten, die mit Android 11 oder höher gestartet wurden, die folgenden Eigenschaften:

• ro.crypto.volume.options (neu in Android 11) wählt das FBE-Verschlüsselungsformat auf akzeptablem Speicher aus. Es hat die gleiche Syntax wie das Argument der fstab-Option fileencryption und verwendet die gleichen Standardwerte. Sehen Sie sich die Empfehlungen für fileencryption oben an, um zu erfahren, was hier zu verwenden ist.
• ro.crypto.volume.metadata.encryption wählt das Metadaten-Verschlüsselungsformat auf dem annehmbaren Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung .

Verwenden Sie auf Geräten, die mit Android 10 oder niedriger gestartet wurden, die folgenden Eigenschaften:

• ro.crypto.volume.contents_mode wählt den Inhaltsverschlüsselungsmodus aus. Dies entspricht dem ersten durch Doppelpunkte getrennten Feld von ro.crypto.volume.options .
• ro.crypto.volume.filenames_mode wählt den Verschlüsselungsmodus für Dateinamen aus. Dies entspricht dem zweiten durch Doppelpunkte getrennten Feld von ro.crypto.volume.options , außer dass der Standardwert auf Geräten, die mit Android 10 oder niedriger gestartet wurden aes-256-heh ist. Auf den meisten Geräten muss dies explizit auf aes-256-cts überschrieben werden.
• ro.crypto.fde_algorithm und ro.crypto.fde_sector_size wählen das Verschlüsselungsformat für Metadaten auf akzeptablem Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung .

Integration mit Keymaster

Der Keymaster HAL sollte als Teil der Klasse early_hal gestartet werden. Dies liegt daran, dass FBE erfordert, dass Keymaster bereit ist, Anforderungen in der post-fs-data Bootphase zu verarbeiten, in der vold die anfänglichen Schlüssel einrichtet.

Ausgenommen Verzeichnisse

init wendet den System-DE-Schlüssel auf alle Top-Level-Verzeichnisse von /data an, mit Ausnahme von Verzeichnissen, die unverschlüsselt sein müssen: das Verzeichnis, das den System-DE-Schlüssel selbst enthält, und Verzeichnisse, die Benutzer-CE- oder DE-Verzeichnisse enthalten. Verschlüsselungsschlüssel gelten rekursiv und können nicht von Unterverzeichnissen überschrieben werden.

In Android 11 und höher kann der Schlüssel, den init auf Verzeichnisse anwendet, durch das Argument encryption=<action> des Befehls mkdir in Init-Skripten gesteuert werden. Die möglichen Werte von <action> sind in der README für die Android-Init-Sprache dokumentiert.

In Android 10 wurden die init Verschlüsselungsaktionen an folgendem Ort fest codiert:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 und früher war der Standort:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Es ist möglich, Ausnahmen hinzuzufügen, um zu verhindern, dass bestimmte Verzeichnisse überhaupt verschlüsselt werden. Wenn Änderungen dieser Art vorgenommen werden, sollte der Gerätehersteller SELinux-Richtlinien einschließen, die nur den Anwendungen Zugriff gewähren, die das unverschlüsselte Verzeichnis verwenden müssen. Dies sollte alle nicht vertrauenswürdigen Anwendungen ausschließen.

Der einzige bekannte akzeptable Anwendungsfall dafür ist die Unterstützung älterer OTA-Funktionen.

Unterstützung von Direct Boot in Systemanwendungen

Anwendungen Direct Boot-fähig machen

Um die schnelle Migration von System-Apps zu erleichtern, gibt es zwei neue Attribute, die auf Anwendungsebene festgelegt werden können. Das Attribut defaultToDeviceProtectedStorage ist nur für System-Apps verfügbar. Das Attribut directBootAware ist für alle verfügbar.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

Das Attribut directBootAware auf Anwendungsebene ist eine Abkürzung zum Markieren aller Komponenten in der App als verschlüsselungsfähig.

Das Attribut defaultToDeviceProtectedStorage leitet den Standard-App-Speicherort so um, dass er auf den DE-Speicher verweist, anstatt auf den CE-Speicher. System-Apps, die dieses Flag verwenden, müssen alle am Standardspeicherort gespeicherten Daten sorgfältig prüfen und die Pfade sensibler Daten ändern, um den CE-Speicher zu verwenden. Gerätehersteller, die diese Option verwenden, sollten die von ihnen gespeicherten Daten sorgfältig prüfen, um sicherzustellen, dass sie keine personenbezogenen Daten enthalten.

Bei der Ausführung in diesem Modus sind die folgenden System-APIs verfügbar, um bei Bedarf einen durch CE-Speicher gesicherten Kontext explizit zu verwalten, die ihren gerätegeschützten Gegenstücken entsprechen.

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

Unterstützung mehrerer Benutzer

Jeder Benutzer in einer Mehrbenutzerumgebung erhält einen separaten Verschlüsselungsschlüssel. Jeder Benutzer erhält zwei Schlüssel: einen DE- und einen CE-Schlüssel. Benutzer 0 muss sich zuerst am Gerät anmelden, da es sich um einen speziellen Benutzer handelt. Dies ist für die Geräteverwaltung relevant.

Krypto-bewusste Anwendungen interagieren benutzerübergreifend auf diese Weise: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL ermöglichen einer Anwendung, über alle Benutzer auf dem Gerät hinweg zu agieren. Diese Apps können jedoch nur auf CE-verschlüsselte Verzeichnisse für Benutzer zugreifen, die bereits entsperrt sind.

Eine Anwendung kann möglicherweise frei über die DE-Bereiche hinweg interagieren, aber ein entsperrter Benutzer bedeutet nicht, dass alle Benutzer auf dem Gerät entsperrt sind. Die Anwendung sollte diesen Status überprüfen, bevor sie versucht, auf diese Bereiche zuzugreifen.

Jede Arbeitsprofil-Benutzer-ID erhält außerdem zwei Schlüssel: DE und CE. Wenn die Arbeitsherausforderung erfüllt ist, wird der Profilbenutzer entsperrt und der Keymaster (in TEE) kann den TEE-Schlüssel des Profils bereitstellen.

Umgang mit Aktualisierungen

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher auf der Benutzerdatenpartition zugreifen. Es wird dringend empfohlen, dass Geräte, die FBE implementieren, OTA mit A/B-Systemaktualisierungen unterstützen. Da das OTA während des normalen Betriebs angewendet werden kann, ist keine Wiederherstellung erforderlich, um auf Daten auf dem verschlüsselten Laufwerk zuzugreifen.

Bei Verwendung einer älteren OTA-Lösung, die eine Wiederherstellung erfordert, um auf die OTA-Datei auf der userdata zuzugreifen:

1. Erstellen Sie ein Verzeichnis der obersten Ebene (z. B. misc_ne ) in der userdata Partition.
2. Konfigurieren Sie dieses Verzeichnis der obersten Ebene so, dass es unverschlüsselt ist (siehe Verzeichnisse ausschließen ).
3. Erstellen Sie ein Verzeichnis innerhalb des Verzeichnisses der obersten Ebene, um OTA-Pakete zu speichern.
4. Fügen Sie eine SELinux-Regel und Dateikontexte hinzu, um den Zugriff auf dieses Verzeichnis und seinen Inhalt zu steuern. Nur der Prozess oder die Anwendungen, die OTA-Updates erhalten, sollten in der Lage sein, dieses Verzeichnis zu lesen und zu schreiben. Keine andere Anwendung oder kein anderer Prozess sollte Zugriff auf dieses Verzeichnis haben.

Validierung

Um sicherzustellen, dass die implementierte Version des Features wie beabsichtigt funktioniert, führen Sie zuerst die vielen CTS-Verschlüsselungstests aus, wie z. B. DirectBootHostTest und EncryptionTest .

Wenn auf dem Gerät Android 11 oder höher ausgeführt wird, führen Sie auch vts_kernel_encryption_test aus:

atest vts_kernel_encryption_test

oder:

vts-tradefed run vts -m vts_kernel_encryption_test

Darüber hinaus können Gerätehersteller die folgenden manuellen Tests durchführen. Auf einem Gerät mit aktiviertem FBE:

• Prüfen Sie, ob ro.crypto.state existiert
  • Stellen Sie sicher, dass ro.crypto.state verschlüsselt ist
• Überprüfen Sie, ob ro.crypto.type vorhanden ist
  • Stellen Sie sicher, ro.crypto.type auf file gesetzt ist

Darüber hinaus können Tester eine userdebug Instanz mit einem auf den primären Benutzer eingestellten Sperrbildschirm booten. Dann adb Shell in das Gerät und mit su root werden. Stellen Sie sicher, /data/data verschlüsselte Dateinamen enthält; wenn nicht, stimmt etwas nicht.

Gerätehersteller werden auch ermutigt, die Ausführung der Upstream-Linux-Tests für fscrypt auf ihren Geräten oder Kerneln zu prüfen. Diese Tests sind Teil der Dateisystem-Testsuite xfstests. Diese Upstream-Tests werden jedoch nicht offiziell von Android unterstützt.

AOSP-Implementierungsdetails

Dieser Abschnitt enthält Details zur AOSP-Implementierung und beschreibt, wie die dateibasierte Verschlüsselung funktioniert. Gerätehersteller sollten hier keine Änderungen vornehmen müssen, um FBE und Direct Boot auf ihren Geräten zu verwenden.

fscrypt-Verschlüsselung

Die AOSP-Implementierung verwendet "fscrypt"-Verschlüsselung (unterstützt von ext4 und f2fs) im Kernel und ist normalerweise so konfiguriert:

• Verschlüsseln Sie Dateiinhalte mit AES-256 im XTS-Modus
• Verschlüsseln Sie Dateinamen mit AES-256 im CBC-CTS-Modus

Adiantum-Verschlüsselung wird ebenfalls unterstützt. Wenn die Adiantum-Verschlüsselung aktiviert ist, werden sowohl Dateiinhalte als auch Dateinamen mit Adiantum verschlüsselt.

fscrypt unterstützt zwei Versionen von Verschlüsselungsrichtlinien: Version 1 und Version 2. Version 1 ist veraltet, und die CDD-Anforderungen für Geräte, die mit Android 11 und höher gestartet werden, sind nur mit Version 2 kompatibel. Version 2-Verschlüsselungsrichtlinien verwenden HKDF-SHA512, um die tatsächliche Verschlüsselungsschlüssel aus den vom Benutzerbereich bereitgestellten Schlüsseln.

Weitere Informationen zu fscrypt finden Sie in der Upstream-Kernel-Dokumentation .

Speicherklassen

Die folgende Tabelle listet die FBE-Schlüssel und die Verzeichnisse, die sie schützen, detaillierter auf:

Schlüsselaufbewahrung und Schutz

Alle FBE-Schlüssel werden von vold verwaltet und verschlüsselt auf der Festplatte gespeichert, mit Ausnahme des Per-Boot-Schlüssels, der überhaupt nicht gespeichert wird. In der folgenden Tabelle sind die Orte aufgeführt, an denen die verschiedenen FBE-Schlüssel gespeichert sind:

Wie in der vorhergehenden Tabelle gezeigt, werden die meisten FBE-Schlüssel in Verzeichnissen gespeichert, die von einem anderen FBE-Schlüssel verschlüsselt werden. Schlüssel können erst entsperrt werden, wenn die Speicherklasse, die sie enthält, entsperrt wurde.

vold wendet auch eine Verschlüsselungsebene auf alle FBE-Schlüssel an. Jeder Schlüssel außer CE-Schlüsseln für die interne Speicherung wird mit AES-256-GCM verschlüsselt, wobei ein eigener Keystore- Schlüssel verwendet wird, der außerhalb des TEE nicht offengelegt wird. Dadurch wird sichergestellt, dass FBE-Schlüssel nicht entsperrt werden können, es sei denn, ein vertrauenswürdiges Betriebssystem wurde gestartet, wie durch Verified Boot erzwungen. Rollback-Widerstand wird auch auf dem Keystore-Schlüssel angefordert, wodurch FBE-Schlüssel sicher auf Geräten gelöscht werden können, auf denen Keymaster Rollback-Widerstand unterstützt. Als Best-Effort-Fallback für den Fall, dass kein Rollback-Widerstand verfügbar ist, wird der SHA-512-Hash aus 16384 Zufallsbytes, der in der neben dem Schlüssel gespeicherten secdiscardable -Datei gespeichert ist, als Anwendungs-ID-Tag des Keystore-Schlüssels verwendet. Alle diese Bytes müssen wiederhergestellt werden, um einen FBE-Schlüssel wiederherzustellen.

CE-Schlüssel für den internen Speicher erhalten einen stärkeren Schutz, der sicherstellt, dass sie nicht entsperrt werden können, ohne entweder den Lock Screen Knowledge Factor (LSKF) des Benutzers (PIN, Muster oder Passwort), ein sicheres Passcode-Reset-Token oder beides auf der Client-Seite zu kennen und serverseitige Schlüssel für einen Resume-on-Reboot- Vorgang. Token zum Zurücksetzen des Passcodes dürfen nur für Arbeitsprofile und vollständig verwaltete Geräte erstellt werden .

Um dies zu erreichen, verschlüsselt vold jeden CE-Schlüssel für die interne Speicherung mit einem AES-256-GCM-Schlüssel, der aus dem synthetischen Passwort des Benutzers abgeleitet wird. Das synthetische Passwort ist ein unveränderliches kryptografisches Geheimnis mit hoher Entropie, das für jeden Benutzer zufällig generiert wird. LockSettingsService in system_server verwaltet das synthetische Passwort und die Art und Weise, wie es geschützt wird.

Um das synthetische Passwort mit dem LSKF zu schützen, dehnt LockSettingsService zuerst das LSKF, indem es es durch scrypt leitet, wobei eine Zeit von etwa 25 ms und eine Speichernutzung von etwa 2 MiB angestrebt werden. Da LSKFs normalerweise kurz sind, bietet dieser Schritt normalerweise nicht viel Sicherheit. Die Hauptsicherheitsebene ist das unten beschriebene Secure Element (SE) oder die durch TEE erzwungene Ratenbegrenzung.

Wenn das Gerät über ein sicheres Element (SE) verfügt, ordnet LockSettingsService die gestreckte LSKF einem zufälligen Geheimnis mit hoher Entropie zu, das in der SE unter Verwendung der Weaver-HAL gespeichert ist. LockSettingsService verschlüsselt dann das synthetische Passwort zweimal: zuerst mit einem Softwareschlüssel, der aus dem gestreckten LSKF und dem Weaver-Geheimnis abgeleitet wird, und zweitens mit einem nicht an die Authentifizierung gebundenen Keystore-Schlüssel. Dies stellt eine durch SE erzwungene Ratenbegrenzung von LSKF-Schätzungen bereit.

Wenn das Gerät keine SE hat, verwendet LockSettingsService stattdessen das gestreckte LSKF als Gatekeeper- Passwort. LockSettingsService verschlüsselt dann das synthetische Passwort zweimal: zuerst mit einem Softwareschlüssel, der aus dem gestreckten LSKF und dem Hash einer secdiscardable-Datei abgeleitet wird, und zweitens mit einem Keystore-Schlüssel, der an die Gatekeeper-Registrierung auth-gebunden ist. Dies stellt eine TEE-erzwungene Ratenbegrenzung von LSKF-Vermutungen bereit.

Wenn das LSKF geändert wird, löscht LockSettingsService alle Informationen, die mit der Bindung des synthetischen Passworts an das alte LSKF verbunden sind. Auf Geräten, die Weaver- oder Rollback-resistente Keystore-Schlüssel unterstützen, garantiert dies ein sicheres Löschen der alten Bindung. Aus diesem Grund gelten die hier beschriebenen Schutzmaßnahmen auch dann, wenn der Benutzer kein LSKF hat.