Dateibasierte Verschlüsselung

Android 7.0 und höher unterstützt die dateibasierte Verschlüsselung (File-based Encryption, FBE). Mit der dateibasierten Verschlüsselung können verschiedene Dateien verschlüsselt werden mit verschiedenen Schlüsseln, 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 Nutzern um die bestmögliche und sicherste Nutzererfahrung zu bieten.

Alle Geräte, die mit Android 10 und höher auf den Markt kommen, erforderlich, um die dateibasierte Verschlüsselung zu verwenden.

Direct Boot

Die dateibasierte Verschlüsselung ermöglicht die in Android 7.0 eingeführte neue Funktion Direkt Booten. Mit Direct Boot können verschlüsselte Geräte direkt am Schloss gestartet werden Bildschirm. Bisher auf verschlüsselten Geräten mit der Einstellung full-disk Verschlüsselung (Data Encryption, FDE) verwenden, mussten Nutzer ihre Anmeldedaten angeben, bevor Daten konnten zugänglich sind, sodass das Telefon nur die grundlegendsten Geschäftsabläufe. Beispielsweise konnten Alarme nicht funktionieren, Bedienungshilfen waren nicht verfügbar und die Telefone konnten keine Anrufe empfangen, sondern waren auf einfache Notrufe.

Mit der Einführung der dateibasierten Verschlüsselung (File-based Encryption, FBE) und neuen APIs Anwendungen mit Verschlüsselung geschützt sind, können diese Anwendungen in einem begrenzten Kontext. Das kann passieren, bevor Nutzer ihre und gleichzeitig die privaten Nutzerdaten schützen.

Auf einem FBE-fähigen Gerät hat jeder Nutzer des Geräts zwei Speicherorte für Anwendungen verfügbar:

• Credential Encrypted (CE)-Speicher – der Standardspeicherort und erst verfügbar, nachdem der Nutzer das Gerät entsperrt hat.
• Der DE-Speicher (Device Encrypted) ist ein Speicherort, der sowohl im Direct Boot-Modus und nachdem der Nutzer das Gerät entsperrt hat.

Diese Trennung erhöht die Sicherheit von Arbeitsprofilen, da mehrere zu schützen, da die Verschlüsselung nicht mehr ausschließlich auf einem das Boot-Zeit-Passwort.

Die Direct Boot API ermöglicht verschlüsselungsbewussten Anwendungen den Zugriff auf diese . Der Anwendungslebenszyklus wurde geändert, um die Notwendigkeit benachrichtigt, wenn der CE-Speicher eines Nutzers entsperrt als Reaktion auf Eingabe von Anmeldedaten auf dem Sperrbildschirm oder im Falle eines Arbeitsprofils und eine geschäftlich Challenge. Geräte mit Android 7.0 müssen diese neuen APIs unterstützen und unabhängig davon, ob FBE implementiert ist oder nicht. Obwohl ohne die Der FBE-, DE- und CE-Speicher bleibt immer im entsperrten Zustand.

Eine vollständige Implementierung der dateibasierten Verschlüsselung in der Ext4- und F2FS-Datei wird im Android Open Source Project (AOSP) bereitgestellt und muss die die Anforderungen erfüllen. Hersteller, die sich für FBE entscheiden können Sie nach Möglichkeiten suchen, die Funktion basierend auf dem System-on-a-Chip (SoC) verwendet.

Alle erforderlichen Pakete in AOSP wurden so aktualisiert, dass sie Direct-Boot-fähig sind. Wenn Gerätehersteller jedoch benutzerdefinierte Versionen dieser Apps verwenden, dass es zumindest direkt-bootsensitive Pakete gibt, die folgenden Dienste:

• Telefoniedienste und Telefon
• Eingabemethode zur Eingabe von Passwörtern auf dem Sperrbildschirm

Beispiele und Quelle

Android bietet eine Referenzimplementierung der dateibasierten Verschlüsselung, bei der vold (system/vold) bietet Funktionen zur Verwaltung von Speichergeräten und auf Android-Geräten. Durch das Hinzufügen von FBE erhält vold mehrere neue Befehle um die Schlüsselverwaltung für die CE- und DE-Schlüssel mehrerer Nutzer zu unterstützen. Außerdem auf die grundlegenden Änderungen zur Verwendung der dateibasierten Verschlüsselungsfunktionen im Kernel, viele Systempakete, einschließlich der Sperrbildschirm und SystemUI wurden modifiziert, um die FBE- und Direct-Funktionen zu unterstützen. Startfunktionen. Dazu gehören:

• AOSP-Dialer (Pakete/Apps/Telefon)
• Schreibtischuhr (Pakete/Apps/DeskClock)
• LatinIME (Pakete/Eingabemethoden/LatinIME)*
• App „Einstellungen“ (Pakete/Apps/Einstellungen)*
• SystemUI (frameworks/base/packages/SystemUI)*

* Systemanwendungen, die die defaultToDeviceProtectedStorage verwenden Manifest-Attribut

Weitere Beispiele für verschlüsselungsbewusste Anwendungen und Dienste indem Sie den Befehl mangrep directBootAware in der Frameworks oder Pakete der AOSP Quellstruktur.

Abhängigkeiten

Damit die AOSP-Implementierung von FBE sicher verwendet werden kann, muss ein Gerät die folgenden Abhängigkeiten:

• Kernel-Unterstützung für Ext4- oder F2FS-Verschlüsselung
• Keymaster Unterstützung mit HAL-Version 1.0 oder höher. Es wird keine Unterstützung für Keymaster 0.3, da diese nicht die erforderlichen Funktionen bietet oder Verschlüsselungsschlüssel ausreichend geschützt sind.
• Keymaster/Keystore und Der Gatekeeper muss in einer vertrauenswürdigen Ausführung implementiert werden. Environment (TEE), um die DE-Schlüssel zu schützen, damit ein nicht autorisiertes Betriebssystem (benutzerdefiniertes Betriebssystem, das auf das Gerät geflasht wurde) kann nicht einfach den DE-Schlüssel.
• Hardware-Root of Trust und verifizierter Bootmodus an die Keymaster-Initialisierung gebunden ist, ist erforderlich, um sicherzustellen, dass DE-Schlüssel nicht wenn ein nicht autorisiertes Betriebssystem darauf zugreifen kann.

Implementierung

Vor allem Apps wie Wecker, Telefon und Bedienungshilfen auf android:directBootAware gemäß der Richtlinie DirectBootAware Boot.

Kernel-Unterstützung

Kernel-Unterstützung für die Ext4- und F2FS-Verschlüsselung ist in der Android- Kernel, Version 3.18 und höher. Um sie in einem Kernel der Version 5.1 zu aktivieren oder höher verwenden:

CONFIG_FS_ENCRYPTION=y

Verwenden Sie für ältere Kernel CONFIG_EXT4_ENCRYPTION=y, wenn sich Ihr Gerät userdata-Dateisystem ist Ext4 oder verwenden Sie CONFIG_F2FS_FS_ENCRYPTION=y, wenn dein Gerät userdata ist ist F2FS.

Falls Ihr Gerät eine adaptive Unterstützung Speicher oder verwendet Metadaten Verschlüsselung im internen Speicher, 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üsselungen bietet das Gerät Hersteller sollten auch die kryptografische Beschleunigung ermöglichen, und die Nutzererfahrung verbessern. Zum Beispiel auf ARM64-basierte Geräte können die Beschleunigung von ARMv8 CE (Cryptography Extensions) aktiviert, indem Sie die folgenden Kernel-Konfigurationsoptionen festlegen:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Um die Leistung weiter zu verbessern und den Stromverbrauch zu reduzieren, können Gerätehersteller können Sie auch Inline-Verschlüsselungshardware implementieren, verschlüsselt/entschlüsselt die Daten auf dem Weg zum/vom Speichergerät. Die gängigen Android-Kernel (Version 4.14 und höher) enthalten ein Framework, das ermöglicht die Verwendung der Inline-Verschlüsselung, wenn die Unterstützung von Hardware- und Anbietertreibern verfügbar. Sie können das Framework für die Inline-Verschlüsselung aktivieren, indem Sie die folgende Kernel-Konfigurationsoptionen:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Wenn auf Ihrem Gerät UFS-basierter Speicher verwendet wird, aktivieren Sie außerdem:

CONFIG_SCSI_UFS_CRYPTO=y

Wenn auf Ihrem Gerät eMMC-basierter Speicher verwendet wird, aktivieren Sie außerdem Folgendes:

CONFIG_MMC_CRYPTO=y

Dateibasierte Verschlüsselung aktivieren

Wenn Sie FBE auf einem Gerät aktivieren möchten, müssen Sie es im internen Speicher aktivieren (userdata) Dadurch wird FBE auch automatisch Speicher; Das Verschlüsselungsformat für nutzbaren Speicher wird jedoch möglicherweise überschrieben. wenn nötig.

Interner Speicher

Zum Aktivieren von FBE wird die Option hinzugefügt fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] in die Spalte fs_mgr_flags der Zeile fstab für userdata Mit dieser Option wird das Verschlüsselungsformat intern definiert Speicherplatz. Sie enthält bis zu drei durch Doppelpunkte getrennte Parameter:

• Mit dem Parameter contents_encryption_mode wird definiert, verwendet einen kryptografischen Algorithmus, um Dateiinhalte zu verschlüsseln. Dies kann entweder aes-256-xts oder adiantum. Seit Android 11 können Sie auch leer bleiben, um die Standardalgorithmus, nämlich aes-256-xts.
• Mit dem Parameter filenames_encryption_mode wird definiert, verwendet einen kryptografischen Algorithmus, um Dateinamen zu verschlüsseln. Dies kann entweder aes-256-cts, aes-256-heh, adiantum oder aes-256-hctr2. Wenn keine Angabe erfolgt, wird standardmäßig aes-256-cts, wenn contents_encryption_mode gleich aes-256-xts oder auf adiantum, wenn contents_encryption_mode ist adiantum.
• Der flags-Parameter, neu bei Android 11 ist eine Liste von Flags, die durch das + Zeichen. Die folgenden Flags werden unterstützt: <ph type="x-smartling-placeholder">
  </ph>
  • Mit dem Flag v1 werden Verschlüsselungsrichtlinien der Version 1 ausgewählt. die Das Flag v2 zum Auswählen von Verschlüsselungsrichtlinien der Version 2. Version Zwei Verschlüsselungsrichtlinien verwenden eine sicherere und flexiblere Schlüsselableitungsfunktion. Der Standardwert ist v2, wenn das Gerät mit Android 11 oder höher (gemäß ro.product.first_api_level) oder v1, wenn das Gerät mit Android 10 oder darunter.
  • Mit dem Flag inlinecrypt_optimized wird eine Verschlüsselung ausgewählt das für Inline-Verschlüsselungshardware optimiert ist, die keine eine große Anzahl von Schlüsseln effizient verwalten. Dies geschieht durch Ableitung der nur einen Verschlüsselungsschlüssel für Dateiinhalte pro CE- oder DE-Schlüssel verwenden, eine Datei pro Datei. Die Generierung von IVs (Initialisierungsvektoren) ist angepasst werden.
  • Das Flag emmc_optimized ähnelt dem inlinecrypt_optimized, es wird aber auch „IV“ ausgewählt -Generierungsmethode, die die IVs auf 32 Bit begrenzt. Dieses Flag sollte nur auf Inline-Verschlüsselungshardware verwendet werden, die den Spezifikation von JEDEC eMMC v5.2 und unterstützt daher nur 32-Bit- IVs. Verwenden Sie auf anderer Inline-Verschlüsselungshardware Stattdessen inlinecrypt_optimized. Dieses Flag darf niemals in UFS-basiertem Speicher verwendet werden; ermöglicht die UFS-Spezifikation die Verwendung von 64-Bit-IVs.
  • Geräte, die hardwareverpackte Geräte unterstützen keys, ermöglicht das Flag wrappedkey_v0 die Verwendung von Hardware-verpackte Schlüssel für FBE. Kann nur in Kombination verwendet werden mit der inlinecrypt-Bereitstellungsoption und entweder inlinecrypt_optimized oder emmc_optimized melden.
  • Das Flag dusize_4k erzwingt die Größe der Verschlüsselungsdateneinheit 4.096 Byte, auch wenn die Blockgröße des Dateisystems nicht 4.096 beträgt Bytes. Die Größe der Verschlüsselungsdateneinheit ist der Detaillierungsgrad der Datei, Verschlüsselung von Inhalten. Dieses Flag ist seit Android verfügbar 15 (AOSP experimentell) Dieses Flag sollte nur verwendet werden, um Verwendung von Inline-Verschlüsselungshardware, die keine Daten unterstützt Einheiten mit mehr als 4096 Byte auf einem Gerät mit Seitengröße die größer als 4.096 Byte ist und das f2fs-Dateisystem verwendet.

Wenn Sie keine Inline-Verschlüsselungshardware verwenden, wird für die meisten Gerät: fileencryption=aes-256-xts. Bei Verwendung von Inline-Creatives Verschlüsselungshardware ist die empfohlene Einstellung für die meisten Geräte fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (oder entsprechend fileencryption=::inlinecrypt_optimized). An auf Geräten ohne AES-Beschleunigung kann Adiantum anstelle von AES verwendet werden. Einstellung fileencryption=adiantum.

Seit Android 14 ist AES-HCTR2 der bevorzugte Modus für die Dateinamenverschlüsselung. für Geräte mit Anweisungen zur beschleunigten Kryptografie. Es werden jedoch nur neuere Android-Kernel unterstützt. AES-HCTR2. Für eine zukünftige Android-Version ist dies voraussichtlich der Standardmodus für Dateinamen. Verschlüsselung. Wenn Ihr Kernel AES-HCTR2 unterstützt, kann er für die Dateinamenverschlüsselung aktiviert werden, indem filenames_encryption_mode wird auf aes-256-hctr2 festgelegt. Im einfachsten Fall würde dies mit fileencryption=aes-256-xts:aes-256-hctr2 geschehen.

Auf Geräten mit Android 10 oder niedriger Mit fileencryption=ice kann auch die Verwendung des Verschlüsselungsmodus für FSCRYPT_MODE_PRIVATE-Dateiinhalte. Dieser Modus ist nicht von den gemeinsamen Android-Kerneln implementiert werden, mit benutzerdefinierten Kernel-Patches. Das von diesem Modus erzeugte On-Disk-Format anbieterspezifisch. Auf Geräten, die mit Android auf den Markt gebracht werden 11 oder höher ist, ist dieser Modus nicht mehr zulässig und ein Stattdessen muss das Standardverschlüsselungsformat verwendet werden.

Standardmäßig erfolgt die Verschlüsselung von Dateiinhalten mithilfe der Cryptography API Wenn Sie stattdessen Inline-Verschlüsselungshardware verwenden möchten, Fügen Sie die inlinecrypt-Bereitstellungsoption hinzu. Beispiel: Eine vollständige fstab-Zeile könnte 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

Verwendbarer Speicher

Seit Android 9, FBE und adaptiver Speicher kann zusammen genutzt werden.

Angabe der fstab-Option fileencryption für userdata aktiviert außerdem automatisch die FBE- und die Metadatenverschlüsselung Speicherplatz. Sie können die FBE- und/oder Metadatenverschlüsselungsformate auf akzeptablen Speicher durch Festlegen von Attributen in PRODUCT_PROPERTY_OVERRIDES

Auf Geräten mit Android 11 oder höher: folgenden Eigenschaften:

• ro.crypto.volume.options (neu in Android) 11) wählt das FBE-Verschlüsselungsformat auf akzeptablen Speicher. Er hat dieselbe Syntax wie das -Argument des fileencryption, und es werden dieselben Standardwerte verwendet. In den Empfehlungen für fileencryption oben erfährst du, was du tun solltest die Sie hier verwenden können.
• ro.crypto.volume.metadata.encryption zum Auswählen der Metadaten Verschlüsselungsformat für zulässigen Speicher. Siehe Metadaten Dokumentation zur Verschlüsselung.

Auf Geräten mit Android 10 oder niedriger: folgenden Eigenschaften:

• ro.crypto.volume.contents_mode zum Auswählen der Inhalte Verschlüsselungsmodus. Dies entspricht dem ersten durch einen Doppelpunkt getrennten Feld von ro.crypto.volume.options
• ro.crypto.volume.filenames_mode zum Auswählen der Dateinamen Verschlüsselungsmodus. Dies entspricht dem zweiten durch einen Doppelpunkt getrennten Feld ro.crypto.volume.options, mit der Ausnahme, dass die Standardeinstellung auf Geräten verwendet wird die mit Android 10 oder niedriger eingeführt wurden, aes-256-heh. Bei den meisten Geräten muss dies explizit überschrieben mit aes-256-cts.
• ro.crypto.fde_algorithm und ro.crypto.fde_sector_size wählen Sie die Metadatenverschlüsselung aus zu verwertenden Speicherformaten. Siehe Metadaten Dokumentation zur Verschlüsselung.

In Keymaster einbinden

Der Keymaster HAL sollte als Teil der early_hal-Klasse gestartet werden. Der Grund dafür ist, dass für FBE der Keymaster bereit ist, Anfragen des post-fs-data-Bootphase: In dieser Phase richtet vold ein. die Anfangsschlüssel.

Verzeichnisse ausschließen

init wendet den DE-Systemschlüssel auf alle Verzeichnisse der obersten Ebene von /data, mit Ausnahme der Verzeichnisse, muss unverschlüsselt sein, wie z. B. das Verzeichnis, das den DE-Schlüssel des Systems enthält und Verzeichnisse, die CE- oder DE-Verzeichnisse für Nutzer enthalten. Verschlüsselungsschlüssel gelten rekursiv und können nicht durch Unterverzeichnisse überschrieben werden.

Unter Android 11 und höher init gilt für Verzeichnisse, die über den encryption=<action>-Argument in mkdir in Init-Skripten verwenden. Die möglichen Werte für <action> sind in den README-Datei für die Android-Initialisierungssprache.

In Android 10 werden die Verschlüsselungsaktionen init wurden am folgenden Speicherort hartcodiert:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Unter Android 9 und niedriger war der Speicherort:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Es ist möglich, Ausnahmen hinzuzufügen, damit bestimmte Verzeichnisse nicht verschlüsselt werden. Wenn solche Änderungen vorgenommen werden, Hersteller sollte angeben. SELinux-Richtlinien, die nur Zugriff auf die Anwendungen, die das unverschlüsselte Verzeichnis verwenden müssen. Damit sollten alle nicht vertrauenswürdigen Anwendungen.

Einziger akzeptabler Anwendungsfall dafür ist die Unterstützung eines älteren OTA-Updates Funktionen.

Direct Boot in Systemanwendungen unterstützen

Anwendungen auf den Direct Boot-Modus aufmerksam machen

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

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

Das Attribut directBootAware auf Anwendungsebene steht für eine Kennzeichnung dass alle App-Komponenten verschlüsselungsbewusst sind.

Mit dem Attribut defaultToDeviceProtectedStorage wird der Standardwert Speicherort der App, um auf den DE-Speicher und nicht auf den CE-Speicher zu verweisen. System-Apps, die dieses Flag verwenden, müssen alle in der Standard- und die Pfade der sensiblen Daten so ändern, dass sie den CE-Speicher verwenden. Gerät Hersteller, die diese Option nutzen, die Daten, um sicherzustellen, dass keine personenbezogenen Daten enthalten sind.

In diesem Modus werden die folgenden System-APIs bei Bedarf explizit einen Kontext verwalten, der von CE-Speicher unterstützt wird. entsprechen den entsprechenden Versionen.

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

Unterstützung für mehrere Nutzer

In einer Umgebung mit mehreren Nutzern erhält jeder Nutzer einen separaten Verschlüsselungsschlüssel. Jeder Nutzer erhält zwei Schlüssel: einen DE- und einen CE-Schlüssel. Nutzer 0 muss sich zuerst auf dem Gerät anmelden. bestimmte Nutzende. Dies gilt für das Gerät Verwaltung verwendet.

Kryptografische Anwendungen interagieren so zwischen Nutzern: INTERACT_ACROSS_USERS und INTERACT_ACROSS_USERS_FULL Zulassen, dass eine Anwendung für alle Nutzer des Geräts tätig ist Diese -Apps können nur noch auf CE-verschlüsselte Verzeichnisse für Nutzer zugreifen, die bereits entsperrt.

Eine Anwendung kann in den DE-Regionen frei interagieren, aber ein Nutzer „Entsperrt“ bedeutet nicht, dass alle Nutzer auf dem Gerät entsperrt sind. Die App diesen Status überprüfen, bevor versucht wird, auf diese Bereiche zuzugreifen.

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

Updates verarbeiten

Die Wiederherstellungspartition kann nicht auf den DE-geschützten Speicher im Nutzerdatenpartitionierung. Für die Unterstützung von Geräten mit FBE wird dringend empfohlen, OTA mit A/B-Systemupdates Als kann das Over-the-air-Update (OTA) während des normalen Betriebs angewendet werden. Eine Wiederherstellung ist nicht erforderlich. auf die Daten auf dem verschlüsselten Laufwerk zugreifen.

Bei Verwendung einer älteren OTA-Lösung, für die eine Wiederherstellung erforderlich ist, um auf die OTA-Datei zugreifen zu können für die Partition userdata:

1. Erstellen Sie ein Verzeichnis der obersten Ebene (z. B. misc_ne) im Partition userdata.
2. Konfigurieren Sie dieses Verzeichnis der obersten Ebene als unverschlüsselt (siehe Verzeichnisse ausschließen).
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 zu steuern und den Inhalt des Inhalts. Nur der Prozess oder die Anwendungen, die OTA-Updates erhalten, sollten in dieses Verzeichnis schreiben und lesen können. Kein anderer Antrag oder Prozess auf dieses Verzeichnis zugreifen können.

Zertifizierungsstufe

Um sicherzustellen, dass die implementierte Version der Funktion wie beabsichtigt funktioniert, führen Sie zuerst der vielen CTS-Verschlüsselungstests, wie DirectBootHostTest und EncryptionTest.

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

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 einer Gerät mit aktiviertem FBE:

• Prüfen, ob ro.crypto.state vorhanden ist <ph type="x-smartling-placeholder">
  </ph>
  • Achten Sie darauf, dass ro.crypto.state verschlüsselt ist
• Prüfen, ob ro.crypto.type vorhanden ist <ph type="x-smartling-placeholder">
  </ph>
  • Achten Sie darauf, dass ro.crypto.type auf file festgelegt ist

Außerdem können Tester prüfen, ob der CE-Speicher gesperrt ist, die zum ersten Mal seit dem Start entsperrt wurden. Verwenden Sie dazu ein userdebug oder eng erstellen, eine PIN, ein Muster oder Passwort für den Hauptnutzer eingeben und das Gerät neu starten. Bevor Sie das Gerät entsperren, Führen Sie den folgenden Befehl aus, um den CE-Speicher des Hauptnutzers zu prüfen. Wenn die verwendet ein monitorloses System Nutzermodus (die meisten Automobil-Geräte) ist der Hauptnutzer Nutzer 10. Führen Sie daher folgenden Befehl aus:

adb root; adb shell ls /data/user/10

Auf anderen Geräten (die meisten Nicht-Automotive-Geräte) ist der Hauptnutzer Nutzer 0, sodass ausführen:

adb root; adb shell ls /data/user/0

Die aufgeführten Dateinamen müssen Base64-codiert sein. Dies weist darauf hin, dass der Dateinamen verschlüsselt sind und der Schlüssel zum Entschlüsseln ist noch nicht verfügbar. Wenn die Dateinamen im Klartext aufgeführt sind, ist ein Fehler aufgetreten.

Geräteherstellern wird außerdem empfohlen, die vorgelagerten Linux-Tests für fscrypt auf ihren Geräten oder Kernel. Diese Tests sind Teil der Testsuite des xfstests-Dateisystems. Sie können jedoch diese Upstream-Tests werden von Android nicht offiziell unterstützt.

Details zur AOSP-Implementierung

Dieser Abschnitt enthält Details zur AOSP-Implementierung und beschreibt, wie dateibasierte Verschlüsselung funktioniert. Für Gerätehersteller dürfte dies nicht erforderlich sein um hier Änderungen vorzunehmen, um FBE und Direct Boot auf ihren Geräten zu verwenden.

fsCrypt-Verschlüsselung

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

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

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

fscrypt unterstützt zwei Versionen der Verschlüsselungsrichtlinien: Version 1 und Version 2. Version 1 wurde eingestellt und die CDD-Anforderungen für Geräte, die mit Android 11 und höher sind nur mit der Version kompatibel 2. Verschlüsselungsrichtlinien der Version 2 verwenden HKDF-SHA512 um die tatsächlichen Verschlüsselungsschlüssel aus den Schlüsseln abzuleiten, die vom Nutzerbereich bereitgestellt werden.

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

Speicherklassen

In der folgenden Tabelle sind die FBE-Schlüssel und die Verzeichnisse aufgeführt, die sie schützen, Details:

Schlüsselspeicher und -schutz

Alle FBE-Schlüssel werden von vold verwaltet und verschlüsselt auf dem Laufwerk gespeichert. mit Ausnahme des Schlüssels pro Boot, der überhaupt nicht gespeichert wird. In der folgenden Tabelle listet die Speicherorte der verschiedenen FBE-Schlüssel auf:

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

vold wendet außerdem eine Verschlüsselungsebene auf alle FBE-Schlüssel an. Jeder Schlüssel CE-Schlüssel für den internen Speicher werden mit AES-256-GCM mit eigener Keystore-Schlüssel, der nicht T-Shirts sichtbar sind. Dadurch wird sichergestellt, dass FBE-Schlüssel nur dann entsperrt werden können, wenn ein vertrauenswürdiges Betriebssystem gestartet wurde, wie durch den verifizierten Bootmodus erzwungen. Rollback durchführen Widerstand wird auch für den Schlüsselspeicherschlüssel angefordert, wodurch FBE-Schlüssel werden auf Geräten, auf denen der Keymaster einen Rollback unterstützt, sicher gelöscht. Als Der SHA-512 ist ein Best-Effort-Fallback für den Fall, dass der Rollback-Widerstand nicht verfügbar ist. Hash von 16.384 zufälligen Byte, die in der gespeicherten Datei secdiscardable gespeichert sind zusammen mit dem Schlüssel als Anwendungs-ID Tag des Schlüsselspeicherschlüssels. Alle diese Byte müssen wiederhergestellt werden, FBE-Schlüssel.

CE-Schlüssel für den internen Speicher erhalten einen stärkeren Schutz, der Sie können nur entsperrt werden, wenn der Sperrbildschirm des Nutzers bekannt ist. Knowledge Factor (LSKF) (PIN, Muster oder Passwort), ein sicheres Token zum Zurücksetzen des Sicherheitscodes oder sowohl den clientseitigen als auch den serverseitigen Schlüssel für ein Bei Neustart fortsetzen: Tokens zum Zurücksetzen des Sicherheitscodes dürfen nur für Arbeitsprofile und voll verwaltete Geräte.

Dazu verschlüsselt vold jeden CE-Schlüssel für den internen Speicher Dabei wird ein AES-256-GCM-Schlüssel verwendet, der vom synthetischen Passwort des Nutzers abgeleitet wurde. Das synthetische Passwort ist ein unveränderliches kryptografisches Secret mit hoher Entropie, das die für jeden Nutzer zufällig generiert werden. LockSettingsService Zoll system_server verwaltet das synthetische Passwort und die Art und Weise, wie geschützt ist.

Um das synthetische Passwort mit dem LSKF zu schützen, LockSettingsService dehnt zuerst den LSKF, indem er sie übergibt scrypt mit Ausrichtung auf eine Zeit von etwa 25 ms und einer eine Speichernutzung von etwa 2 MiB. Da LSKFs in der Regel kurz sind, bietet nicht viel Sicherheit. Die wichtigste Sicherheitsebene ist die sichere Element (SE) oder TEE-erzwungene Ratenbegrenzung, wie unten beschrieben.

Wenn das Gerät ein Secure Element (SE) hat, gilt: LockSettingsService ordnet den erweiterten LSKF einem zufälligen Secret mit hoher Entropie zu, das im SE unter Verwendung von Weaver HAL. Anschließend verschlüsselt LockSettingsService das synthetische Passwort zweimal: zuerst mit einem Softwareschlüssel, der aus dem LSKF- und Weaver-Geheimnis gedehnt . Dies ermöglicht eine von der SE erzwungene Ratenbegrenzung für LSKF-Vermutungen.

Wenn das Gerät keinen SE hat, dann LockSettingsService verwendet den gestreckten LSKF als Gatekeeper Passwort. LockSettingsService verschlüsselt dann das synthetische Passwort. zweimal: Zuerst mit einem Softwareschlüssel, der vom erweiterten LSKF abgeleitet ist, und dem Hash der eine entschleusbare Datei und zweitens einen Schlüsselspeicherschlüssel, der auth-gebunden an den Anmeldung am Gatekeeper. Dies ermöglicht eine vom TEE erzwungene Ratenbegrenzung für LSKF-Vermutungen.

Wenn der LSKF geändert wird, löscht LockSettingsService alle Informationen im Zusammenhang mit der Bindung des synthetischen Passworts an das alte Passwort LSKF Auf Geräten, die Weaver- oder Rollback-resistente Keystore-Schlüssel unterstützen, garantiert das sichere Löschen der alten Bindung. Aus diesem Grund sind die Schutzmaßnahmen werden auch dann angewendet, wenn der Nutzer kein LSKF hat.