Dateibasierte Verschlüsselung

Android 7.0 und höher unterstützt dateibasierte Verschlüsselung (FBE). Durch die dateibasierte Verschlüsselung können verschiedene Dateien mit unterschiedlichen Schlüsseln verschlüsselt werden, die unabhängig voneinander entsperrt werden können.

In diesem Artikel wird beschrieben, wie Sie die dateibasierte Verschlüsselung auf neuen Geräten aktivieren und wie Systemanwendungen die Direct Boot-APIs nutzen können, um Benutzern das bestmögliche und sicherste Erlebnis zu bieten.

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

Direkter Start

Die dateibasierte Verschlüsselung ermöglicht eine neue Funktion namens Direct Boot , die in Android 7.0 eingeführt wurde. Direct Boot ermöglicht es verschlüsselten Geräten, direkt über den Sperrbildschirm zu starten. Bisher mussten Benutzer auf verschlüsselten Geräten mit Full-Disk-Verschlüsselung (FDE) Anmeldeinformationen angeben, bevor auf Daten zugegriffen werden konnte, wodurch das Telefon nur die grundlegendsten Vorgänge ausführen konnte. Beispielsweise konnten Alarme nicht aktiviert werden, 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, ist es für diese Apps möglich, in einem begrenzten Kontext zu arbeiten. Dies kann passieren, bevor Benutzer ihre Anmeldeinformationen angegeben haben, und schützt gleichzeitig private Benutzerinformationen.

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 erst verfügbar ist, nachdem der Benutzer das Gerät entsperrt hat.
• Geräteverschlüsselter (DE) Speicher, ein Speicherort, der sowohl im Direktstartmodus 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 ausschließlich 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 ein 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 nach Möglichkeiten suchen, die Funktion basierend auf dem verwendeten System-on-Chip (SoC) zu optimieren.

Alle erforderlichen Pakete in AOSP wurden aktualisiert, um den Direktstart zu unterstützen. Wenn Gerätehersteller jedoch angepasste Versionen dieser Apps verwenden, sollten sie sicherstellen, dass mindestens direktstartfähige Pakete vorhanden sind, die die folgenden Dienste bereitstellen:

• Telefondienste und Dialer
• Eingabemethode zur Eingabe von Passwörtern in den Sperrbildschirm

Beispiele und Quelle

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

• AOSP Dialer (Pakete/Apps/Dialer)
• Schreibtischuhr (Pakete/Apps/DeskClock)
• LatinIME (Pakete/Eingabemethoden/LatinIME)*
• Einstellungen-App (Pakete/Apps/Einstellungen)*
• SystemUI (Frameworks/Base/Pakete/SystemUI)*

* Systemanwendungen, die das Manifestattribut defaultToDeviceProtectedStorage “ verwenden

Weitere Beispiele für Anwendungen und Dienste, die die Verschlüsselung berücksichtigen, finden Sie, indem Sie den Befehl mangrep directBootAware im Frameworks- oder Packages-Verzeichnis des AOSP-Quellbaums ausführen.

Abhängigkeiten

Um die AOSP-Implementierung von FBE sicher nutzen zu können, 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 dieses 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 zu bieten, sodass ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht wird) die DE-Schlüssel nicht einfach 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 für ein nicht autorisiertes Betriebssystem zugänglich sind.

Implementierung

In erster Linie sollten Apps wie Wecker, Telefon und Eingabehilfen 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 gängigen 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 anpassbaren Speicher unterstützt oder die 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 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) durch Festlegen der folgenden Kernel-Konfigurationsoptionen aktiviert 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 gängigen Android-Kernel (Version 4.14 und höher) enthalten ein Framework, das die Verwendung von Inline-Verschlüsselung ermöglicht, wenn Hardware- und Treiberunterstützung des Herstellers verfügbar ist. Das Inline-Verschlüsselungs-Framework 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 außerdem Folgendes:

CONFIG_SCSI_UFS_CRYPTO=y

Wenn Ihr Gerät eMMC-basierten Speicher verwendet, aktivieren Sie außerdem Folgendes:

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 anpassbarem Speicher aktiviert. Das Verschlüsselungsformat im anpassbaren Speicher kann jedoch bei Bedarf überschrieben 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 für den 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 mit Android 11 oder höher gestartet wurde (wie durch ro.product.first_api_level bestimmt), oder v1, wenn das Gerät mit 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 verarbeiten kann. Dies geschieht durch die Ableitung nur eines Dateiinhalts-Verschlüsselungsschlüssels pro CE- oder DE-Schlüssel und nicht eines pro Datei. Die Generierung von IVs (Initialisierungsvektoren) wird entsprechend angepasst.
  • Das Flag emmc_optimized ähnelt inlinecrypt_optimized , wählt jedoch 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 ermöglicht die Verwendung von 64-Bit-IVs.
  • Auf Geräten, die in Hardware verpackte Schlüssel unterstützen, ermöglicht das Flag wrappedkey_v0 “ die Verwendung von in Hardware verpackten 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, ist die empfohlene Einstellung für die meisten Geräte fileencryption=aes-256-xts . Wenn Sie Inline-Verschlüsselungshardware verwenden, ist 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 festgelegt wird.

Seit Android 14 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 ist geplant, dies zum Standardmodus für die Verschlüsselung von Dateinamen zu machen. Wenn Ihr Kernel über AES-HCTR2-Unterstützung verfügt, kann die Verschlüsselung von Dateinamen aktiviert werden, indem filenames_encryption_mode auf aes-256-hctr2 gesetzt wird. 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 Dateiinhaltsverschlüsselungsmodus FSCRYPT_MODE_PRIVATE anzugeben. Dieser Modus wird von den gängigen Android-Kerneln nicht implementiert, könnte aber von Anbietern mithilfe benutzerdefinierter Kernel-Patches implementiert werden. Das von diesem Modus erzeugte Format auf der Festplatte war herstellerspezifisch. Auf Geräten mit Android 11 oder höher 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

Anpassbare Aufbewahrung

Seit Android 9 können FBE und Adoptable Storage gemeinsam genutzt werden.

Durch Angabe der fileencryption fstab-Option für userdata werden außerdem automatisch sowohl die FBE- als auch die Metadatenverschlüsselung auf dem verwendbaren Speicher aktiviert. Sie können jedoch die FBE- und/oder Metadatenverschlüsselungsformate auf verwendbarem 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 dem anpassbaren Speicher aus. Es hat dieselbe Syntax wie das Argument für die fstab-Option der fileencryption und verwendet dieselben Standardeinstellungen. Sehen Sie sich die Empfehlungen zur fileencryption oben an, um zu erfahren, was Sie hier verwenden sollten.
• ro.crypto.volume.metadata.encryption wählt das Metadaten-Verschlüsselungsformat für den verwendbaren 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 , mit der Ausnahme, dass die Standardeinstellung 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 Metadaten-Verschlüsselungsformat für den verwendbaren Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung .

Integration mit Keymaster

Der Keymaster HAL sollte als Teil der early_hal Klasse gestartet werden. Dies liegt daran, dass FBE erfordert, dass Keymaster in der post-fs-data Boot-Phase, in der vold die ersten Schlüssel einrichtet, bereit sein muss, Anfragen zu bearbeiten.

Ohne Verzeichnisse

init wendet den System-DE-Schlüssel auf alle Verzeichnisse der obersten Ebene von /data an, mit Ausnahme der Verzeichnisse, 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> für den Befehl mkdir in Init-Skripten gesteuert werden. Die möglichen Werte von <action> sind in der README-Datei 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 Speicherort:

/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 einbinden, die nur den Anwendungen Zugriff gewähren, die das unverschlüsselte Verzeichnis verwenden müssen. Dadurch sollten alle nicht vertrauenswürdigen Anwendungen ausgeschlossen werden.

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

Unterstützt Direct Boot in Systemanwendungen

Anwendungen auf Direct Boot aufmerksam machen

Um eine 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 steht allen zur Verfügung.

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

Das Attribut directBootAware auf Anwendungsebene ist eine Abkürzung für die Kennzeichnung aller Komponenten in der App als verschlüsselungsbewusst.

Das Attribut defaultToDeviceProtectedStorage leitet den Standard-App-Speicherort so um, dass er auf den DE-Speicher und nicht auf den CE-Speicher verweist. System-Apps, die dieses Flag verwenden, müssen alle am Standardspeicherort gespeicherten Daten sorgfältig prüfen und die Pfade vertraulicher Daten ändern, um CE-Speicher zu verwenden. Gerätehersteller, die diese Option nutzen, 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 stehen die folgenden System-APIs zur expliziten Verwaltung eines vom CE-Speicher unterstützten Kontexts bei Bedarf zur Verfügung, 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-fähige Anwendungen interagieren auf folgende Weise zwischen Benutzern: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL ermöglichen es einer Anwendung, über alle Benutzer auf dem Gerät hinweg zu agieren. Allerdings können diese Apps 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 die Entsperrung eines Benutzers bedeutet nicht, dass alle Benutzer auf dem Gerät entsperrt sind. Die Anwendung sollte diesen Status überprüfen, bevor versucht wird, 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 Schlüsselmeister (in TEE) kann den TEE-Schlüssel des Profils bereitstellen.

Umgang mit Updates

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher auf der Benutzerdatenpartition zugreifen. Geräten, die FBE implementieren, wird dringend empfohlen, OTA mithilfe von A/B-Systemaktualisierungen zu unterstützen. Da 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 .
2. Konfigurieren Sie dieses Verzeichnis der obersten Ebene so, dass es unverschlüsselt ist (siehe Ausschließen von Verzeichnissen ).
3. Erstellen Sie im Verzeichnis der obersten Ebene ein Verzeichnis zum Speichern von OTA-Paketen.
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, in diesem 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 der Funktion wie vorgesehen funktioniert, führen Sie zunächst die vielen CTS-Verschlüsselungstests aus, z. B. DirectBootHostTest und EncryptionTest .

Wenn auf dem Gerät Android 11 oder höher läuft, 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:

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

Darüber hinaus können Tester eine userdebug Instanz mit einem für den primären Benutzer festgelegten Sperrbildschirm starten. Geben Sie dann adb Shell in das Gerät ein und verwenden Sie su , um Root zu werden. Stellen Sie sicher, /data/data verschlüsselte Dateinamen enthält. Wenn nicht, stimmt etwas nicht.

Gerätehersteller werden außerdem aufgefordert, die Ausführung der Upstream-Linux-Tests für fscrypt auf ihren Geräten oder Kernels zu prüfen. Diese Tests sind Teil der Dateisystem-Testsuite xfstests. Allerdings werden diese Upstream-Tests von Android nicht offiziell unterstützt.

Details zur AOSP-Implementierung

Dieser Abschnitt enthält Details zur AOSP-Implementierung und beschreibt, wie die dateibasierte Verschlüsselung funktioniert. Hier sollte es für Gerätehersteller nicht nötig sein, irgendwelche Änderungen vorzunehmen, um FBE und Direct Boot auf ihren Geräten zu nutzen.

fscrypt-Verschlüsselung

Die AOSP-Implementierung verwendet die „fscrypt“-Verschlüsselung (unterstützt von ext4 und f2fs) im Kernel und ist normalerweise wie folgt konfiguriert:

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

Auch die Adiantum-Verschlüsselung wird 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. Verschlüsselungsrichtlinien der Version 2 verwenden HKDF-SHA512, um die tatsächlichen abzuleiten Verschlüsselungsschlüssel aus den vom Userspace bereitgestellten Schlüsseln.

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

Speicherklassen

In der folgenden Tabelle sind die FBE-Schlüssel und die von ihnen geschützten Verzeichnisse detaillierter aufgeführt:

Schlüsselaufbewahrung und -schutz

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

Wie in der vorherigen Tabelle gezeigt, werden die meisten FBE-Schlüssel in Verzeichnissen gespeichert, die mit einem anderen FBE-Schlüssel verschlüsselt sind. Schlüssel können erst entsperrt werden, wenn die Speicherklasse, in der sie enthalten sind, entsperrt wurde.

vold wendet außerdem eine Verschlüsselungsebene auf alle FBE-Schlüssel an. Jeder Schlüssel außer CE-Schlüsseln für den internen Speicher wird mit AES-256-GCM unter Verwendung eines eigenen Keystore- Schlüssels verschlüsselt, der nicht außerhalb des TEE 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 für den 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 von 16384 zufälligen Bytes, 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 ein stärkeres Schutzniveau, das sicherstellt, dass sie nicht entsperrt werden können, ohne entweder den Lock Screen Knowledge Factor (LSKF) des Benutzers (PIN, Muster oder Passwort), ein sicheres Passwort-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 zunächst das LSKF aus, indem es es durch scrypt leitet, wobei eine Zeit von etwa 25 ms und eine Speichernutzung von etwa 2 MiB angestrebt werden. Da LSKFs in der Regel kurz sind, bietet dieser Schritt meist keine große Sicherheit. Die wichtigste Sicherheitsebene ist die unten beschriebene Secure Element (SE) oder TEE-erzwungene Ratenbegrenzung.

Wenn das Gerät über ein Secure Element (SE) verfügt, ordnet LockSettingsService das gestreckte LSKF mithilfe der Weaver-HAL einem zufälligen Geheimnis mit hoher Entropie zu, das im SE gespeichert ist. LockSettingsService verschlüsselt dann das synthetische Passwort zweimal: erstens 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 ermöglicht eine SE-erzwungene Ratenbegrenzung von LSKF-Schätzungen.

Wenn das Gerät nicht über eine SE verfügt, verwendet LockSettingsService stattdessen das gestreckte LSKF als Gatekeeper- Passwort. LockSettingsService verschlüsselt dann das synthetische Passwort zweimal: erstens 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 authentifiziert ist. Dies ermöglicht eine TEE-erzwungene Ratenbegrenzung von LSKF-Schätzungen.

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 werden die hier beschriebenen Schutzmaßnahmen auch dann angewendet, wenn der Benutzer nicht über eine LSKF verfügt.