Hardware-verpackte Schlüssel

Wie bei den meisten Festplatten- und Dateiverschlüsselungssoftware bietet die Speicherverschlüsselung von Android sind üblicherweise darauf angewiesen, dass die rohen Verschlüsselungsschlüssel im Systemspeicher damit die Verschlüsselung durchgeführt werden kann. Auch wenn die Verschlüsselung durchgeführt wird nicht durch Software, sondern nur auf dedizierter Hardware, muss Software in der Regel um die Rohverschlüsselungsschlüssel zu verwalten.

Dies wird üblicherweise nicht als Problem angesehen, da die Schlüssel nicht vorhanden sind. während eines Offlineangriffs. Dies ist die Hauptart eines Angriffs, den der Speicher die Verschlüsselung vor. Es besteht jedoch der Wunsch, erhöhter Schutz vor anderen Arten von Angriffen, z. B. Kaltstart Angriffe und Onlineangriffe, bei denen Angreifer ohne die Geräte zu beeinträchtigen.

Um dieses Problem zu lösen, wurde mit Android 11 für hardwareverpackte Schlüssel, bei denen Hardwareunterstützung vorhanden ist. Hardware-verpackte Schlüssel sind Speicherschlüssel, die nur in Rohform bekannt sind. dedizierte Hardware kann die Software diese Schlüssel nur in verpackten (verschlüsseltes) Formular. Diese Hardware muss in der Lage sein, Daten zu generieren und zu importieren sowie die flüchtige und langfristige Verpackung von Speicherschlüsseln, Unterschlüssel direkt in eine Inline-Krypto-Engine programmieren und gibt einen separaten Unterschlüssel an die Software zurück.

Hinweis: Eine Inline-Krypto-Engine (oder Inline-Krypto-Engine Verschlüsselungshardware) bezieht sich auf Hardware, die Daten verschlüsselt/entschlüsselt, während er ist unterwegs zum/vom Speichergerät. Normalerweise ein UFS- oder eMMC-Host Controller, der die von der entsprechenden JEDEC-Spezifikation.

Design

In diesem Abschnitt wird das Design der Funktion für mit Hardware verpackte Schlüssel beschrieben, einschließlich: welche Hardware- Unterstützung dafür benötigt wird. In diesem Artikel geht es hauptsächlich um die dateibasierte Verschlüsselung (File-based Encryption, FBE). für Metadaten Verschlüsselung verwenden.

Um zu vermeiden, dass die unverarbeiteten Verschlüsselungsschlüssel im Systemspeicher erforderlich sind, können Sie nur in den Schlüsselslots einer Inline-Krypto-Engine. Diese birgt einige Probleme:

  • Die Anzahl der Verschlüsselungsschlüssel kann die Anzahl der Schlüsselslots überschreiten.
  • Inline-Krypto-Engines können nur zum Ver-/Entschlüsseln vollständiger Daten auf der Festplatte. Bei FBE muss die Software jedoch Andere kryptografische Aufgaben erledigen, z. B. die Verschlüsselung von Dateinamen und das Ableiten von Schlüssel Kennzeichnungen. Die Software benötigt weiterhin Zugriff auf die FBE-Rohschlüssel, um und diese andere Arbeit machen.

Um diese Probleme zu vermeiden, werden die Speicherschlüssel mit Hardware verpackten Schlüsseln, die nur entpackt und verwendet werden können dedizierte Hardware. Dadurch kann eine unbegrenzte Anzahl von Schlüsseln unterstützt werden. In Außerdem wird die Schlüsselhierarchie geändert und teilweise auf diese Hardware verschoben. mit dem ein Unterschlüssel für Aufgaben an die Software zurückgegeben werden kann, für die kein Inline-Krypto-Engine.

Schlüsselhierarchie

Schlüssel können mit einem KDF (Key Derivation Function, KDF) von anderen Schlüsseln abgeleitet werden, z. B. HKDF. was zu einer Schlüsselhierarchie führt.

Das folgende Diagramm zeigt eine typische Schlüsselhierarchie für FBE, wenn Hardware-verpackte Schlüssel werden nicht verwendet:

<ph type="x-smartling-placeholder">
</ph> FBE-Schlüsselhierarchie (Standard) <ph type="x-smartling-placeholder">
</ph> Abbildung 1: FBE-Schlüsselhierarchie (Standard)

Der FBE-Klassenschlüssel ist der Rohverschlüsselungsschlüssel, den Android an das Linux-System übergibt. bestimmte verschlüsselte Verzeichnisse wie das mit Anmeldedaten verschlüsselter Speicher für einen bestimmten Android-Nutzer. Im Kernel wird als fscrypt-Masterschlüssel bezeichnet.) Von diesem Schlüssel leitet der Kernel folgenden Unterschlüsseln:

  • Die Schlüsselkennung. Dieser wird nicht zur Verschlüsselung verwendet, sondern ein Wert. zur Identifizierung des Schlüssels, mit dem eine bestimmte Datei oder ein bestimmtes Verzeichnis geschützt sind.
  • Verschlüsselungsschlüssel für Dateiinhalte
  • Der Verschlüsselungsschlüssel der Dateinamen

Im folgenden Diagramm wird dagegen die Schlüsselhierarchie für FBE dargestellt, wenn Hardware-verpackte Schlüssel werden verwendet:

<ph type="x-smartling-placeholder">
</ph> FBE-Schlüsselhierarchie (mit Hardware-verpacktem Schlüssel) <ph type="x-smartling-placeholder">
</ph> Abbildung 2: FBE-Schlüsselhierarchie (mit Hardware-verpacktem Schlüssel)

Im Vergleich zum vorherigen Fall wurde dem Schlüssel eine zusätzliche Ebene hinzugefügt. und der Verschlüsselungsschlüssel für Dateiinhalte wurde verschoben. Der Stamm Knoten stellt immer noch den Schlüssel dar, den Android an Linux übergibt, um eine Reihe von verschlüsselten Verzeichnissen suchen. Dieser Schlüssel liegt jedoch ephemerisch verpackt vor und damit er verwendet werden kann, muss er an die entsprechende Hardware übergeben werden. Diese Hardware muss Implementieren Sie zwei Schnittstellen, die einen sitzungsspezifischen Schlüssel verwenden:

  • Eine Schnittstelle zum Ableiten von inline_encryption_key und direkten in einen Schlüsselslot der Inline-Krypto-Engine programmieren. Dadurch kann Datei Inhalte zu verschlüsseln/entschlüsseln, ohne dass Software Zugriff auf die Rohdaten hat . In den gängigen Kerneln von Android entspricht diese Schnittstelle der blk_crypto_ll_ops::keyslot_program-Vorgang, der Folgendes sein muss: Speichertreiber implementiert wird.
  • Eine Schnittstelle zum Ableiten und Zurückgeben von sw_secret ("Software") geheim“ -- auch als "raw Secret" bezeichnet an manchen Orten), was der Schlüssel ist, Unter Linux werden die Unterschlüssel für alles andere als Dateiinhalte abgeleitet. Verschlüsselung. In den gängigen Kerneln von Android entspricht diese Schnittstelle der blk_crypto_ll_ops::derive_sw_secret-Vorgang, der Folgendes sein muss: Speichertreiber implementiert wird.

Zum Ableiten von inline_encryption_key und sw_secret aus dem Rohspeicherschlüssel verwendet wird, muss die Hardware einen kryptografisch starken KDF verwenden. Dieser KDF Best Practices für Kryptografie einhalten; Die Sicherheitsstufe muss mindestens 256 Bit, d.h. genug für einen späteren Algorithmus. Außerdem muss ein einen eindeutigen Label-, Kontext- und/oder anwendungsspezifischen Informationsstring, wenn das Ableiten der einzelnen Unterschlüsseltypen, um zu gewährleisten, dass die kryptografisch isoliert sind, d.h. das Wissen über einen von ihnen verrät keine Sonstiges. Schlüsselerweiterungen sind nicht erforderlich, da der Rohspeicherschlüssel bereits ein ein zufällig zufälliger Schlüssel an.

Technisch gesehen kann jeder KDF verwendet werden, der die Sicherheitsanforderungen erfüllt. Zu Testzwecken ist es jedoch notwendig, denselben KDF in und testen Sie den Code. Derzeit wurde ein KDF überprüft und implementiert. kann er gefunden werden, im Quellcode für vts_kernel_encryption_test. Es wird empfohlen, für die Hardware diesen KDF zu verwenden, der NIST SP 800-108 „KDF in Counter Mode“ mit AES-256-CMAC als PRF verwendet. Zur Kompatibilität müssen alle Teile des Algorithmus müssen identisch sein, einschließlich der Auswahl der KDF-Kontexte und Labels für jeden Unterschlüssel.

Key-Wrapping

Um die Sicherheitsziele von hardwareverpackten Schlüsseln zu erreichen, sind zwei Arten der Schlüsselverpackung definiert sind:

  • Sitzungsspezifisches Wrapping: Die Hardware verschlüsselt den Rohschlüssel mit einem Schlüssel. die bei jedem Start zufällig generiert und nicht direkt bereitgestellt wird, außerhalb der Hardware.
  • Langfristiges Wrapping: Die Hardware verschlüsselt den Rohschlüssel mit einer eindeutiger, dauerhafter Schlüssel, der in die Hardware integriert ist, der nicht direkt die außerhalb der Hardware sichtbar sind.

Alle Schlüssel, die zum Entsperren des Speichers an den Linux-Kernel übergeben werden, werden mit flüchtigem Wrapping. So wird sichergestellt, dass, wenn ein Angreifer in der Lage ist, ein bereits verwendete Schlüssel aus dem Systemspeicher, ist dieser Schlüssel unbrauchbar. und nach einem Neustart auch direkt auf dem Gerät.

Gleichzeitig muss Android eine verschlüsselte Version speichern können. der Schlüssel auf der Festplatte, damit sie überhaupt entriegelt werden können. Die Rohfassung Schlüssel wären für diesen Zweck geeignet. Es ist jedoch wünschenswert, niemals die unbearbeiteten Schlüssel überhaupt im Systemspeicher vorhanden sind, sodass sie nie extrahiert werden können, extern verwendet werden, auch wenn die Funktion beim Booten extrahiert wurde. Aus diesem Grund ist das Konzept von langfristiger Wrapping-Funktion definiert.

Um die Verwaltung von Schlüsseln zu unterstützen, die auf diese beiden Arten verpackt sind, muss die Hardware folgende Schnittstellen implementieren:

  • Schnittstellen zum Generieren und Importieren von Speicherschlüsseln und deren Rückgabe im um ein langfristig umschlossenes Format zu erstellen. Der Zugriff auf diese Schnittstellen erfolgt indirekt über KeyMint erstellen und dem KeyMint-Tag TAG_STORAGE_KEY entsprechen. Das „Generieren“ Die Funktion wird von vold verwendet, um neuen Speicher zu generieren Schlüssel für Android, während die "Import"-Schlüssel können von Nutzenden vts_kernel_encryption_test, um Testschlüssel zu importieren.
  • Eine Schnittstelle zum Konvertieren eines langfristig verpackten Speicherschlüssels in einen sitzungsspezifisch verpackten Speicherschlüssel. Dies entspricht dem convertStorageKeyToEphemeral: KeyMint-Methode. Diese Methode wird verwendet, der Reihe nach von vold und vts_kernel_encryption_test um den Speicher freizuschalten.

Der Key-Wrapping-Algorithmus ist ein Implementierungsdetail, sollte jedoch einen starken AEAD wie AES-256-GCM mit zufälligen IVs aus.

Softwareänderungen erforderlich

AOSP verfügt bereits über ein grundlegendes Framework zur Unterstützung von mit Hardware verpackten Schlüsseln. Dieses umfasst die Unterstützung in Userspace-Komponenten wie vold sowie als Linux-Kernel-Unterstützung in blk-crypto, fscrypt und dm-default-key.

Es sind jedoch einige implementierungsspezifische Änderungen erforderlich.

KeyMint-Änderungen

Die KeyMint-Implementierung des Geräts muss geändert werden, um die TAG_STORAGE_KEY und implementieren Sie die convertStorageKeyToEphemeral-Methode.

In Keymaster wurde exportKey anstelle von convertStorageKeyToEphemeral.

Änderungen am Linux-Kernel

Der Linux-Kernel-Treiber für die Inline-Krypto-Engine des Geräts muss geändert werden um hardwareverpackte Schlüssel zu unterstützen.

Für android14 und höhere Kernel: BLK_CRYPTO_KEY_TYPE_HW_WRAPPED festlegen in blk_crypto_profile::key_types_supported, machen blk_crypto_ll_ops::keyslot_program und blk_crypto_ll_ops::keyslot_evict unterstützen das Programmieren/Entfernen von hardwareverpackten Schlüsseln, und blk_crypto_ll_ops::derive_sw_secret implementieren.

Für android12- und android13-Kernel: BLK_CRYPTO_FEATURE_WRAPPED_KEYS festlegen in blk_keyslot_manager::features, machen blk_ksm_ll_ops::keyslot_program und blk_ksm_ll_ops::keyslot_evict unterstützen das Programmieren/Entfernen von hardwareverpackten Schlüsseln, und blk_ksm_ll_ops::derive_raw_secret implementieren.

Für android11-Kernel: BLK_CRYPTO_FEATURE_WRAPPED_KEYS festlegen in keyslot_manager::features, machen keyslot_mgmt_ll_ops::keyslot_program und keyslot_mgmt_ll_ops::keyslot_evict unterstützen das Programmieren/Entfernen von hardwareverpackten Schlüsseln, und keyslot_mgmt_ll_ops::derive_raw_secret implementieren.

Testen

Obwohl die Verschlüsselung mit hardwareverpackten Schlüsseln schwieriger zu testen ist als die Verschlüsselung können Sie immer noch einen Testschlüssel importieren und die Schlüsselableitung, die die Hardware übernimmt. Dies wird implementiert, in vts_kernel_encryption_test Um diesen Test durchzuführen, ausführen: 

atest -v vts_kernel_encryption_test

Lesen Sie das Testprotokoll und prüfen Sie, ob die mit Hardware verpackten Schlüssel (z.B. FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy und DmDefaultKeyTest.TestHwWrappedKey) wurden aufgrund der Unterstützung nicht übersprungen für hardwareverpackte Schlüssel nicht erkannt, da die Testergebnisse immer noch "bestanden" in diesem Fall.

Wird aktiviert

Sobald die Unterstützung für die hardwareverpackten Schlüssel des Geräts ordnungsgemäß funktioniert, können Sie Nehmen Sie folgende Änderungen an der Datei fstab des Geräts vor, um Android verwendet es für die FBE- und Metadatenverschlüsselung:

  • FBE: Fügen Sie das Flag wrappedkey_v0 zum fileencryption-Parameter. Verwenden Sie beispielsweise fileencryption=::inlinecrypt_optimized+wrappedkey_v0 Für Weitere Informationen finden Sie in der FBE Dokumentation.
  • Metadatenverschlüsselung: Fügen Sie das Flag wrappedkey_v0 zum metadata_encryption-Parameter. Verwenden Sie beispielsweise metadata_encryption=:wrappedkey_v0 Weitere Informationen finden Sie in der Metadaten Dokumentation zur Verschlüsselung.