Hardware-verpackte Schlüssel

Wie die meisten Datenträger- und Dateiverschlüsselungssoftware stützt sich die Speicherverschlüsselung von Android in der Regel auf die im Systemspeicher vorhandenen Rohverschlüsselungsschlüssel, damit die Verschlüsselung durchgeführt werden kann. Auch wenn die Verschlüsselung nicht durch Software, sondern durch spezielle Hardware durchgeführt wird, müssen die Rohverschlüsselungsschlüssel in der Regel weiterhin von Software verwaltet werden.

Das wird traditionell nicht als Problem angesehen, da die Schlüssel bei einem Offlineangriff nicht vorhanden sind. Dies ist die Hauptart von Angriffen, vor denen die Speicherverschlüsselung schützen soll. Es besteht jedoch der Wunsch, einen besseren Schutz vor anderen Arten von Angriffen wie Cold-Boot-Angriffen und Onlineangriffen zu bieten, bei denen ein Angreifer möglicherweise Systemspeicher auslesen kann, ohne das Gerät vollständig zu schädigen.

Um dieses Problem zu lösen, wurde in Android 11 die Unterstützung für hardwareverpackte Schlüssel eingeführt, sofern Hardware-Unterstützung vorhanden ist. Hardware-verpackte Schlüssel sind Speicherschlüssel, die nur in Rohform für spezielle Hardware bekannt sind. Software sieht und arbeitet nur mit diesen Schlüsseln in verpackter (verschlüsselter) Form. Diese Hardware muss Speicherschlüssel generieren und importieren, Speicherschlüssel in sitzungsspezifische und langfristige Formen verpacken, Unterschlüssel ableiten, einen Unterschlüssel direkt in eine Inline-Krypto-Engine programmieren und einen separaten Unterschlüssel an die Software zurückgeben können.

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

Design

In diesem Abschnitt wird die Funktion der hardwareverpackten Schlüssel beschrieben, einschließlich der erforderlichen Hardwareunterstützung. Im Mittelpunkt dieser Erläuterungen steht die dateibasierte Verschlüsselung (File-based Encryption, FBE). Die Lösung gilt jedoch auch für die Metadatenverschlüsselung.

Eine Möglichkeit, die Notwendigkeit von Rohverschlüsselungsschlüsseln im Systemspeicher zu vermeiden, besteht darin, sie nur in den Schlüsselslots einer Inline-Krypto-Engine zu speichern. Bei diesem Ansatz gibt es jedoch einige Probleme:

  • Die Anzahl der Verschlüsselungsschlüssel kann die Anzahl der Schlüsselslots überschreiten.
  • Inline-Krypto-Engines verlieren in der Regel den Inhalt ihrer Schlüsselslots, wenn der Speichercontroller (normalerweise UFS oder eMMC) zurückgesetzt wird. Das Zurücksetzen des Speichercontrollers ist ein standardmäßiges Verfahren zur Fehlerbehebung, das ausgeführt wird, wenn bestimmte Arten von Speicherfehlern auftreten. Solche Fehler können jederzeit auftreten. Wenn Inline-Kryptografie verwendet wird, muss das Betriebssystem daher immer bereit sein, die Schlüsselslots ohne Eingriff des Nutzers neu zu programmieren.
  • Inline-Krypto-Engines können nur zum Verschlüsseln/Entschlüsseln ganzer Datenblöcke auf dem Laufwerk verwendet werden. Bei der FBE muss die Software jedoch weiterhin andere kryptografische Aufgaben ausführen können, z. B. die Verschlüsselung von Dateinamen und die Ableitung von Schlüssel-IDs. Die Software benötigt für diese anderen Aufgaben weiterhin Zugriff auf die FBE-Rohschlüssel.

Zur Vermeidung dieser Probleme werden die Speicherschlüssel stattdessen als hardwareverpackte Schlüssel umgewandelt, die nur entpackt und von dedizierter Hardware verwendet werden können. So kann eine unbegrenzte Anzahl von Schlüsseln unterstützt werden. Darüber hinaus wird die Schlüsselhierarchie geändert und teilweise auf diese Hardware verschoben. Dadurch kann ein Unterschlüssel für Aufgaben, die keine Inline-Krypto-Engine verwenden können, an Software zurückgegeben werden.

Schlüsselhierarchie

Schlüssel können mithilfe einer KDF (Schlüsselableitungsfunktion) wie HKDF aus anderen Schlüsseln abgeleitet werden, was zu einer Schlüsselhierarchie führt.

Das folgende Diagramm zeigt eine typische Schlüsselhierarchie für die FBE, wenn keine hardwareverpackten Schlüssel verwendet werden:

FBE-Schlüsselhierarchie (Standard)
Abbildung 1. FBE-Schlüsselhierarchie (Standard)

Der FBE-Klassenschlüssel ist der Rohverschlüsselungsschlüssel, den Android an den Linux-Kernel übergibt, um einen bestimmten Satz verschlüsselter Verzeichnisse zu entsperren, z. B. den mit Anmeldedaten verschlüsselten Speicher für einen bestimmten Android-Nutzer. Im Kernel wird dieser Schlüssel als fscrypt-Masterschlüssel bezeichnet. Aus diesem Schlüssel leitet der Kernel die folgenden Unterschlüssel ab:

  • Die Schlüsselkennung. Dieser Wert wird nicht für die Verschlüsselung verwendet, sondern dient dazu, den Schlüssel zu identifizieren, mit dem eine bestimmte Datei oder ein bestimmtes Verzeichnis geschützt ist.
  • Der Verschlüsselungsschlüssel für den Dateiinhalt
  • Der Verschlüsselungsschlüssel für Dateinamen

Im Gegensatz dazu zeigt das folgende Diagramm die Schlüsselhierarchie für die FBE, wenn hardwareverpackte Schlüssel verwendet werden:

FBE-Schlüsselhierarchie (mit hardwareverpacktem Schlüssel)
Abbildung 2. FBE-Schlüsselhierarchie (mit hardwareverpacktem Schlüssel)

Im Vergleich zum vorherigen Fall wurde der Schlüsselhierarchie eine zusätzliche Ebene hinzugefügt und der Verschlüsselungsschlüssel für den Dateiinhalt wurde verschoben. Der Stammknoten stellt weiterhin den Schlüssel dar, den Android an Linux übergibt, um eine Reihe verschlüsselter Verzeichnisse zu entsperren. Dieser Schlüssel ist jetzt jedoch in einer verpackten Form und muss an eine spezielle Hardware übergeben werden, um verwendet werden zu können. Auf dieser Hardware müssen zwei Schnittstellen implementiert werden, die einen sitzungsspezifischen Schlüssel verwenden:

  • Eine Schnittstelle, um inline_encryption_key abzuleiten und direkt in einen Schlüsselschlitz der Inline-Krypto-Engine zu programmieren. So können Dateiinhalte verschlüsselt/entschlüsselt werden, ohne dass Software Zugriff auf den Rohschlüssel hat. In den allgemeinen Android-Kerneln entspricht diese Schnittstelle dem Vorgang blk_crypto_ll_ops::keyslot_program, der vom Speichertreiber implementiert werden muss.
  • Eine Schnittstelle zum Ableiten und Zurückgeben von sw_secret („Software Secret“, an manchen Stellen auch „Raw Secret“ genannt), dem Schlüssel, mit dem Linux die Unterschlüssel für alles andere als die Verschlüsselung des Dateiinhalts ableitet. In den gemeinsamen Android-Kerneln entspricht diese Schnittstelle dem Vorgang blk_crypto_ll_ops::derive_sw_secret, der vom Speichertreiber implementiert werden muss.

Um inline_encryption_key und sw_secret aus dem Rohspeicherschlüssel abzuleiten, muss die Hardware einen kryptografisch starken KDF verwenden. Diese KDF muss den Best Practices für Kryptografie entsprechen und eine Sicherheitsstärke von mindestens 256 Bit haben, was für jeden später verwendeten Algorithmus ausreicht. Außerdem muss beim Ableiten der einzelnen Arten von Unterschlüsseln ein eindeutiges Label, ein eindeutiger Kontext und ein app-spezifischer Informationsstring verwendet werden, um sicherzustellen, dass die resultierenden Unterschlüssel kryptografisch isoliert sind, d. h., dass das Wissen um einen von ihnen keine anderen preisgibt. Eine Schlüsselstreckung ist nicht erforderlich, da der Rohspeicherschlüssel bereits ein gleichmäßig zufälliger Schlüssel ist.

Technisch gesehen kann jeder KDF verwendet werden, der die Sicherheitsanforderungen erfüllt. Zu Testzwecken muss dieselbe KDF jedoch im Testcode neu implementiert werden. Derzeit wurde ein KDF überprüft und implementiert. Sie finden es im Quellcode für vts_kernel_encryption_test. Für die Hardware wird dieser KDF empfohlen, der NIST SP 800-108 „KDF in Counter Mode“ mit AES-256-CMAC als PRF verwendet. Hinweis: Für die Kompatibilität müssen alle Teile des Algorithmus 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üsselverschlüsselung definiert:

  • Sitzungsspezifisches Wrapping: Die Hardware verschlüsselt den Rohschlüssel mit einem Schlüssel, der bei jedem Starten des Geräts zufällig generiert wird und nicht direkt außerhalb der Hardware freigegeben wird.
  • Langfristige Verschlüsselung: Die Hardware verschlüsselt den Rohschlüssel mit einem eindeutigen, persistenten Schlüssel, der in die Hardware integriert ist und nicht direkt außerhalb der Hardware freigegeben wird.

Alle Schlüssel, die zum Entsperren des Speichers an den Linux-Kernel übergeben werden, sind sitzungsbasiert verpackt. So wird sichergestellt, dass ein Angreifer, der einen verwendeten Schlüssel aus dem Systemspeicher extrahiert, diesen Schlüssel nicht nur außerhalb des Geräts, sondern auch auf dem Gerät nach einem Neustart nicht verwenden kann.

Gleichzeitig muss Android weiterhin eine verschlüsselte Version der Schlüssel auf dem Laufwerk speichern können, damit sie überhaupt entsperrt werden können. Die Rohschlüssel eignen sich dafür. Es ist jedoch wünschenswert, dass die Rohschlüssel nicht im Systemspeicher vorhanden sind, damit sie nicht extrahiert und außerhalb des Geräts verwendet werden können, auch wenn sie beim Start extrahiert werden. Aus diesem Grund wurde das Konzept des langfristigen Wrappings definiert.

Damit die Verwaltung von Schlüsseln auf diese beiden Arten unterstützt werden kann, muss die Hardware die folgenden Schnittstellen implementieren:

  • Schnittstellen zum Generieren und Importieren von Speicherschlüsseln, die in verpackter Form für die Langzeitspeicherung zurückgegeben werden. Auf diese Schnittstellen wird indirekt über KeyMint zugegriffen und sie entsprechen dem TAG_STORAGE_KEY KeyMint-Tag. Die Funktion „Generate“ (Generieren) wird von vold verwendet, um neue Speicherschlüssel zur Verwendung durch Android zu generieren, während die Funktion „Import“ von vts_kernel_encryption_test zum Importieren von Testschlüsseln verwendet wird.
  • Eine Schnittstelle zum Umwandeln eines langfristig verpackten Speicherschlüssels in einen sitzungsspezifischen verpackten Speicherschlüssel. Dies entspricht der KeyMint-Methode convertStorageKeyToEphemeral. Diese Methode wird sowohl von vold als auch von vts_kernel_encryption_test verwendet, um den Speicher zu entsperren.

Der Schlüsselverschlüsselungsalgorithmus ist ein Implementierungsdetail, sollte aber einen starken AEAD wie AES-256-GCM mit zufälligen IVs verwenden.

Softwareänderungen erforderlich

AOSP bietet bereits ein grundlegendes Framework für die Unterstützung von hardwareverpackten Schlüsseln. Dazu gehören die Unterstützung in Userspace-Komponenten wie vold sowie die Linux-Kernel-Unterstützung in blk-crypto, fscrypt und dm-default-key.

Es sind jedoch einige implementierungsspezifische Änderungen erforderlich.

Änderungen bei KeyMint

Die KeyMint-Implementierung des Geräts muss so geändert werden, dass TAG_STORAGE_KEY unterstützt und die Methode convertStorageKeyToEphemeral implementiert wird.

In Keymaster wurde exportKey anstelle von convertStorageKeyToEphemeral verwendet.

Änderungen am Linux-Kernel

Der Linux-Kernel-Treiber für die Inline-Krypto-Engine des Geräts muss so geändert werden, dass er hardwareverpackte Schlüssel unterstützt.

Legen Sie für android14 und höhere Kernel BLK_CRYPTO_KEY_TYPE_HW_WRAPPED in blk_crypto_profile::key_types_supported fest, sorgen Sie dafür, dass blk_crypto_ll_ops::keyslot_program und blk_crypto_ll_ops::keyslot_evict das Programmieren/Entfernen von hardwareverpackten Schlüsseln unterstützen und blk_crypto_ll_ops::derive_sw_secret implementieren.

Legen Sie für die Kernel android12 und android13 BLK_CRYPTO_FEATURE_WRAPPED_KEYS in blk_keyslot_manager::features fest, sorgen Sie dafür, dass blk_ksm_ll_ops::keyslot_program und blk_ksm_ll_ops::keyslot_evict das Programmieren/Entfernen von mit Hardware verpackten Schlüsseln unterstützen und blk_ksm_ll_ops::derive_raw_secret implementieren.

Für android11-Kernel müssen BLK_CRYPTO_FEATURE_WRAPPED_KEYS in keyslot_manager::features festgelegt, keyslot_mgmt_ll_ops::keyslot_program und keyslot_mgmt_ll_ops::keyslot_evict für das Programmieren und Entfernen von hardwareverpackten Schlüsseln unterstützt und keyslot_mgmt_ll_ops::derive_raw_secret implementiert werden.

Testen

Obwohl die Verschlüsselung mit hardwareverpackten Schlüsseln schwieriger zu testen ist als die Verschlüsselung mit Standardschlüsseln, ist sie dennoch möglich, indem ein Testschlüssel importiert und die Schlüsselableitung von der Hardware neu implementiert wird. Dies ist in vts_kernel_encryption_test implementiert. Führen Sie zum Ausführen dieses Tests Folgendes aus: 

atest -v vts_kernel_encryption_test

Lesen Sie das Testlog und prüfen Sie, ob die Testläufe mit Hardware-verpackten Schlüsseln (z. B. FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy und DmDefaultKeyTest.TestHwWrappedKey) übersprungen wurden, da die Unterstützung für mit Hardware verpackte Schlüssel nicht erkannt wurde, da die Testergebnisse in diesem Fall immer noch „bestanden“ sind.

Tasten aktivieren

Sobald die Unterstützung für hardwareverpackte Schlüssel des Geräts ordnungsgemäß funktioniert, können Sie die folgenden Änderungen an der fstab-Datei des Geräts vornehmen, damit Android sie für die FBE- und Metadatenverschlüsselung verwendet:

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