Dateibasierte Verschlüsselung

Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (FBE). Durch die dateibasierte Verschlüsselung können verschiedene Dateien mit verschiedenen 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 verwenden können, um Benutzern die bestmögliche und sicherste Benutzererfahrung zu bieten.

Direkter Start

Die dateibasierte Verschlüsselung ermöglicht eine neue in Android 7.0 eingeführte Funktion namens Direct Boot . Mit Direct Boot können verschlüsselte Geräte direkt auf dem Sperrbildschirm gestartet werden. Bisher mussten Benutzer auf verschlüsselten Geräten mit FDE ( Full-Disk Encryption ) Anmeldeinformationen angeben, bevor auf Daten zugegriffen werden konnte, sodass das Telefon nicht alle bis auf die grundlegendsten Vorgänge ausführen konnte. Beispielsweise konnten Alarme nicht ausgeführt werden, Zugänglichkeitsdienste waren nicht verfügbar und Telefone konnten keine Anrufe empfangen, sondern beschränkten sich nur auf grundlegende Notrufoperationen.

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 und gleichzeitig private Benutzerinformationen geschützt sind.

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

• CE-Speicher (Credential Encrypted), der Standardspeicherort, der erst verfügbar ist, nachdem der Benutzer das Gerät entsperrt hat.
• Device Encrypted (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 nur auf einem Startzeitkennwort basiert.

Mit der Direct Boot-API können verschlüsselungsfähige Anwendungen auf jeden dieser Bereiche zugreifen. Es gibt Änderungen im Anwendungslebenszyklus, um der Notwendigkeit Rechnung zu tragen, Anwendungen zu benachrichtigen, wenn der CE-Speicher eines Benutzers entsperrt wird , wenn zuerst Anmeldeinformationen auf dem Sperrbildschirm eingegeben werden, oder wenn das Arbeitsprofil eine Arbeitsherausforderung darstellt . 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 befindet sich der 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) untersuchen.

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

• Telefoniedienste 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 unter Android bereitstellt. Durch das Hinzufügen 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 grundlegenden Änderungen zur Verwendung der dateibasierten Verschlüsselungsfunktionen im Kernel wurden viele Systempakete, einschließlich des Sperrbildschirms und der SystemUI, geändert, um die Funktionen FBE und Direct Boot 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

Weitere Beispiele für Anwendungen und Dienste, die für die Verschlüsselung mangrep directBootAware sind, finden Sie, indem Sie den Befehl mangrep directBootAware im Framework- oder mangrep directBootAware .

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 einer HAL-Version 1.0 oder 2.0. Es gibt keine Unterstützung für Keymaster 0.3, da dies nicht die erforderlichen Funktionen bietet oder einen ausreichenden Schutz für Verschlüsselungsschlüssel gewährleistet.
• Keymaster / Keystore und Gatekeeper müssen in einer Trusted Execution Environment (TEE) implementiert sein, um die DE-Schlüssel zu schützen, damit ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht wurde) 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 ein nicht autorisiertes Betriebssystem nicht auf die Anmeldeinformationen für die Geräteverschlüsselung zugreifen kann.

Hinweis : Speicherrichtlinien werden auf einen Ordner und alle seine Unterordner angewendet. Hersteller sollten den Inhalt, der unverschlüsselt bleibt, auf den OTA-Ordner und den Ordner beschränken, der den Schlüssel enthält, der das System entschlüsselt. Die meisten Inhalte sollten sich in einem mit Anmeldeinformationen verschlüsselten Speicher und nicht in einem mit Geräten verschlüsselten Speicher befinden.

Implementierung

In erster Linie sollten Apps wie Wecker, Telefon und Eingabehilfen für Android: directBootAware gemäß der Direct Boot- Entwicklerdokumentation erstellt werden.

Kernel-Unterstützung

Die Kernel-Unterstützung für die Ext4- und F2FS-Verschlüsselung ist in den allgemeinen Android-Kerneln ab Version 3.18 verfügbar. Verwenden Sie Folgendes, um es in einem Kernel ab Version 5.1 zu aktivieren:

CONFIG_FS_ENCRYPTION=y

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

Wenn Ihr Gerät einen akzeptablen Speicher unterstützt oder eine Metadatenverschlüsselung im internen Speicher verwendet, aktivieren Sie auch die für die Metadatenverschlüsselung erforderlichen Kernelkonfigurationsoptionen, wie in der Dokumentation zur Metadatenverschlüsselung beschrieben.

Zusätzlich zur funktionalen Unterstützung der Ext4- oder F2FS-Verschlüsselung sollten Gerätehersteller auch die kryptografische Beschleunigung aktivieren, um die dateibasierte Verschlüsselung zu beschleunigen und die Benutzererfahrung zu verbessern. Auf ARM64-basierten Geräten kann beispielsweise die ARMv8 CE-Beschleunigung (Cryptography Extensions) aktiviert werden, indem die folgenden Kernelkonfigurationsoptionen 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, mit dem die Inline-Verschlüsselung verwendet werden kann, wenn Hardware- und Hersteller-Treiberunterstützung verfügbar ist. Das Inline-Verschlüsselungsframework kann durch Festlegen der folgenden Kernelkonfigurationsoptionen 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:

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 ) userdata . Dadurch wird FBE auch automatisch für anpassbaren Speicher aktiviert. Das Verschlüsselungsformat für den akzeptablen 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 Zeile fstab für userdata . Diese Option definiert das Verschlüsselungsformat im internen Speicher. Es enthält bis zu drei durch Doppelpunkte getrennte Parameter:

• Die contents_encryption_mode Parameter definiert , die kryptografischen Algorithmus zum Verschlüsseln von Dateiinhalten verwendet wird. Es kann entweder aes-256-xts oder adiantum .
• 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 oder adiantum . Wenn nicht angegeben, wird standardmäßig aes-256-cts wenn contents_encryption_mode ist aes-256-xts oder zu adiantum wenn contents_encryption_mode ist adiantum .
• Der in Android R neue Parameter flags ist eine Liste von Flags, die durch das Zeichen + getrennt sind. Folgende Flags werden unterstützt:
  • Das Flag v1 wählt Verschlüsselungsrichtlinien der Version 1 aus. Das Flag v2 wählt Verschlüsselungsrichtlinien der Version 2 aus. Verschlüsselungsrichtlinien der Version 2 verwenden eine sicherere und flexiblere Funktion zur Schlüsselableitung . Der Standardwert ist v2, wenn das Gerät unter Android R oder höher gestartet wurde (wie von ro.product.first_api_level ), oder v1, wenn das Gerät unter 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 den Dateiinhalt pro CE- oder DE-Schlüssel und nicht einer pro Datei abgeleitet. Die Erzeugung von IVs (Initialisierungsvektoren) wird entsprechend angepasst.
  • Das emmc_optimized Flag ä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 der JEDEC eMMC v5.2-Spezifikation entspricht und daher nur 32-Bit-IVs unterstützt. Verwenden inlinecrypt_optimized auf anderer Inline-Verschlüsselungshardware stattdessen inlinecrypt_optimized . Dieses Flag sollte niemals für UFS-basierten Speicher verwendet werden. Die UFS-Spezifikation ermöglicht die Verwendung von 64-Bit-IVs.
  • Das Flag " wrappedkey_v0 ermöglicht die Verwendung von mit Hardware wrappedkey_v0 Schlüsseln. Wenn diese Option aktiviert ist, werden FBE-Schlüssel nicht von der Software generiert, sondern von Keymaster mithilfe des STORAGE_KEY Tags. Dann ist jeder FBE-Schlüssel, der dem Kernel tatsächlich zur Verfügung gestellt wird, der aus STORAGE_KEY exportierte STORAGE_KEY Schlüssel, wodurch er mit einem kurzlebigen Schlüssel pro Boot umbrochen wird. Der Kernel stellt dann die verpackten Schlüssel direkt der Inline-Verschlüsselungshardware zur Verfügung. Bei korrekter Implementierung sind die nicht umschlossenen Schlüssel niemals im Systemspeicher vorhanden, und ein kompromittierter umschlossener Schlüssel kann nach einem Neustart nicht verwendet werden. Dieses Flag erfordert Hardware-Unterstützung, Keymaster-Unterstützung für STORAGE_KEY , Kernel-Treiber-Unterstützung, die inlinecrypt Mount-Option und entweder die inlinecrypt_optimized oder emmc_optimized Flags.

Wenn Sie keine Inline-Verschlüsselungshardware verwenden, wird für die meisten Geräte die 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 . Auf Geräten ohne AES-Beschleunigung kann Adiantum anstelle von AES verwendet werden, indem fileencryption=adiantum .

Auf Geräten, die mit Android 10 oder niedriger fileencryption=ice wird auch fileencryption=ice akzeptiert, um die Verwendung des Verschlüsselungsmodus für den FSCRYPT_MODE_PRIVATE anzugeben. Dieser Modus wird von den gängigen Android-Kerneln nicht implementiert, kann jedoch von Anbietern mithilfe benutzerdefinierter Kernel-Patches implementiert werden. Das von diesem Modus erzeugte On-Disk-Format war herstellerspezifisch. Auf Geräten, die mit Android R oder höher gestartet werden, ist dieser Modus nicht mehr zulässig und es muss stattdessen ein Standardverschlüsselungsformat verwendet werden.

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

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

Angenommener Speicher

Seit Android 9 können FBE und anpassbarer Speicher zusammen verwendet werden.

Durch Angabe der fileencryption fstab für die userdata für userdata auch automatisch die FBE- und Metadatenverschlüsselung für den akzeptablen Speicher aktiviert. Sie können jedoch die Verschlüsselungsformate FBE und / oder Metadaten für den akzeptablen Speicher überschreiben, indem Sie Eigenschaften in PRODUCT_PROPERTY_OVERRIDES .

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

• ro.crypto.volume.options (neu in Android R) wählt das FBE-Verschlüsselungsformat für den akzeptablen Speicher aus. Es hat dieselbe Syntax wie das Argument für die fileencryption fstab für die fileencryption und verwendet dieselben Standardeinstellungen. In den obigen Empfehlungen zur fileencryption zur Verwendung hier.
• ro.crypto.volume.metadata.encryption wählt das Metadatenverschlüsselungsformat für den akzeptablen 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 Verschlüsselungsmodus für Inhalte 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 der Standardwert auf Geräten, die mit Android 10 oder niedriger gestartet wurden, aes-256-heh . 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 Metadatenverschlüsselungsformat für den akzeptablen Speicher aus. Weitere Informationen finden Sie in der Dokumentation zur Metadatenverschlüsselung .

Integration mit Keymaster

Die Generierung der Schlüssel und die Verwaltung des Kernel-Schlüsselbunds werden von vold . Die AOSP-Implementierung von FBE erfordert, dass das Gerät Keymaster HAL Version 1.0 oder höher unterstützt. Frühere Versionen des Keymaster HAL werden nicht unterstützt.

Beim ersten Start werden die Schlüssel von Benutzer 0 zu Beginn des Startvorgangs generiert und installiert. Bis die on-post-fs Fs on-post-fs Phase von init abgeschlossen ist, muss der Keymaster bereit sein, Anforderungen zu bearbeiten. Auf Pixel-Geräten wird dies durch einen Skriptblock erledigt, der sicherstellt, dass Keymaster gestartet wird, bevor /data bereitgestellt wird.

Verschlüsselungsrichtlinie

Die dateibasierte Verschlüsselung wendet die Verschlüsselungsrichtlinie auf Verzeichnisebene an. Wenn die userdata eines Geräts zum ersten Mal erstellt wird, werden die grundlegenden Strukturen und Richtlinien von den init Skripten angewendet. Diese Skripte lösen die Erstellung der CE- und DE-Schlüssel des ersten Benutzers (Benutzer 0) aus und definieren, welche Verzeichnisse mit diesen Schlüsseln verschlüsselt werden sollen. Wenn zusätzliche Benutzer und Profile erstellt werden, werden die erforderlichen zusätzlichen Schlüssel generiert und im Schlüsselspeicher gespeichert. Ihre Speicherorte für Anmeldeinformationen und Geräte werden erstellt, und die Verschlüsselungsrichtlinie verknüpft diese Schlüssel mit diesen Verzeichnissen.

In Android R und höher ist die Verschlüsselungsrichtlinie nicht mehr an einem zentralen Ort fest mkdir , sondern wird durch Argumente für die Befehle mkdir in den Init-Skripten definiert. Mit dem System-DE-Schlüssel verschlüsselte Verzeichnisse verwenden encryption=Require , während unverschlüsselte Verzeichnisse (oder Verzeichnisse, deren Unterverzeichnisse mit Benutzerschlüsseln verschlüsselt sind) encryption=None .

In Android 10 wurde die Verschlüsselungsrichtlinie an diesem Speicherort fest codiert:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 und früheren Versionen 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 einschließen , die nur den Zugriff auf die Anwendungen gewähren, die das unverschlüsselte Verzeichnis verwenden müssen. Dies sollte alle nicht vertrauenswürdigen Anwendungen ausschließen.

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

Unterstützung von Direct Boot in Systemanwendungen

Anwendungen Direct Boot bewusst machen

Um eine schnelle Migration von System-Apps zu ermöglichen, können auf Anwendungsebene zwei neue Attribute festgelegt werden. 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 directBootAware Attribut auf Anwendungsebene ist eine Abkürzung zum Markieren aller Komponenten in der App als verschlüsselungsfähig.

Das Attribut defaultToDeviceProtectedStorage leitet den Standardspeicherort der App so um, dass er auf den DE-Speicher zeigt, 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 vertraulicher Daten ändern, um 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 persönlichen Informationen enthalten.

In diesem Modus stehen die folgenden System-APIs zur Verfügung, um bei Bedarf explizit einen durch CE-Speicher gesicherten Kontext zu verwalten, der ihren gerätegeschützten Gegenstücken entspricht.

• 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 beim Gerät anmelden, da es sich um einen speziellen Benutzer handelt. Dies ist für die Verwendung durch die Geräteverwaltung relevant.

Kryptobewusste Anwendungen interagieren auf folgende Weise zwischen Benutzern: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL ermöglichen es einer Anwendung, auf alle Benutzer auf dem Gerät zu reagieren. Diese Apps können jedoch nur auf CE-verschlüsselte Verzeichnisse für Benutzer zugreifen, die bereits entsperrt sind.

Eine Anwendung kann möglicherweise in allen DE-Bereichen frei interagieren. Ein entsperrter Benutzer bedeutet jedoch 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 Benutzer-ID des Arbeitsprofils erhält außerdem zwei Schlüssel: DE und CE. Wenn die Arbeitsaufgabe erfüllt ist, wird der Profilbenutzer entsperrt und der Keymaster (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-Systemupdates zu unterstützen . Da der 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, für deren Zugriff auf die OTA-Datei auf der userdata eine Wiederherstellung erforderlich ist:

1. Erstellen Sie ein Verzeichnis der obersten Ebene (z. B. misc_ne ) in der userdata .
2. Fügen Sie dieses Verzeichnis der obersten Ebene zur Ausnahme der Verschlüsselungsrichtlinie hinzu (siehe Verschlüsselungsrichtlinie oben).
3. Erstellen Sie ein Verzeichnis im Verzeichnis der obersten Ebene, in dem OTA-Pakete gespeichert werden sollen.
4. Fügen Sie eine SELinux-Regel und Dateikontexte hinzu, um den Zugriff auf diesen Ordner und dessen Inhalt zu steuern. Nur der Prozess oder die Anwendungen, die OTA-Updates erhalten, sollten in der Lage sein, in diesen Ordner zu lesen und zu schreiben. Keine andere Anwendung oder kein anderer Prozess sollte Zugriff auf diesen Ordner haben.

Validierung

Führen Sie zunächst die zahlreichen CTS-Verschlüsselungstests wie DirectBootHostTest und EncryptionTest aus, um sicherzustellen, dass die implementierte Version der Funktion wie beabsichtigt funktioniert .

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

atest vts_kernel_encryption_test

oder:

vts-tradefed run vts -m VtsKernelEncryptionTest

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

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

Darüber hinaus können Tester eine userdebug Instanz mit einem auf dem primären Benutzer festgelegten userdebug starten. Dann adb Shell in das Gerät und verwenden Sie su , um root zu werden. Stellen Sie sicher, dass /data/data verschlüsselte Dateinamen enthält. Wenn dies nicht der Fall ist, stimmt etwas nicht.

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

Details zur AOSP-Implementierung

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.

Verschlüsselung verschlüsseln

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

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

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

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

Schlüsselableitung

Dateibasierte Verschlüsselungsschlüssel, bei denen es sich um 512-Bit-Schlüssel handelt, werden verschlüsselt von einem anderen Schlüssel (einem 256-Bit-AES-GCM-Schlüssel) gespeichert, der im TEE enthalten ist. Um diesen TEE-Schlüssel verwenden zu können, müssen drei Anforderungen erfüllt sein:

• Das Authentifizierungstoken
• Der gestreckte Ausweis
• Der "secdiscardable Hash"

Der Auth - Token ist ein kryptografisch authentifizierte Token generiert durch Torwächter , wenn ein Benutzer erfolgreich anmeldet. Der TEE wird sich weigern , den Schlüssel zu verwenden , es sei denn , die richtige Auth - Token versorgt wird. Wenn der Benutzer keine Anmeldeinformationen hat, wird kein Authentifizierungstoken verwendet oder benötigt.

Der gestreckte Berechtigungsnachweis ist der Benutzerberechtigungsnachweis nach dem Salzen und Dehnen mit dem scrypt . Der Berechtigungsnachweis wird tatsächlich einmal im vold gehasht, bevor er zur Weitergabe an scrypt an vold übergeben wird. Dies ist kryptografisch an den Schlüssel im TEE gebunden, mit allen Garantien, die für KM_TAG_APPLICATION_ID gelten. Wenn der Benutzer keinen Berechtigungsnachweis hat, wird kein erweiterter Berechtigungsnachweis verwendet oder benötigt.

Der secdiscardable hash ist ein 512-Bit-Hash einer zufälligen 16-KB-Datei, die zusammen mit anderen Informationen gespeichert wird, die zur Rekonstruktion des Schlüssels verwendet werden, z. B. dem Startwert. Diese Datei wird sicher gelöscht, wenn der Schlüssel gelöscht oder auf neue Weise verschlüsselt wird. Dieser zusätzliche Schutz stellt sicher, dass ein Angreifer jedes Bit dieser sicher gelöschten Datei wiederherstellen muss, um den Schlüssel wiederherzustellen. Dies ist kryptografisch an den Schlüssel im TEE gebunden, mit allen Garantien, die für KM_TAG_APPLICATION_ID gelten.

In den meisten Fällen werden FBE-Schlüssel auch einem zusätzlichen Schlüsselableitungsschritt im Kernel unterzogen, um die tatsächlich für die Verschlüsselung verwendeten Unterschlüssel zu generieren, z. B. Schlüssel pro Datei oder pro Modus. Für Verschlüsselungsrichtlinien der Version 2 wird hierfür HKDF-SHA512 verwendet.