Weaver

Die in Android 8.1 eingeführte Weaver Hardware Abstraction Layer (HAL) (IWeaver.aidl) bietet eine sichere Schnittstelle für die Nutzerauthentifizierung mit dem Lock Screen Knowledge Factor (LSKF) wie PIN, Muster und Passwort.

Weaver ersetzt die LSKF-Bestätigungsfunktion von Gatekeeper. Gatekeeper wird jedoch weiterhin zum Generieren von Hardware-Authentifizierungstokens verwendet.

In Android 9 und höher ist in CDD 9.11.2 festgelegt, dass Geräte, die StrongBox unterstützen, spezielle sichere Hardware für die sichere Nutzerauthentifizierung bereitstellen müssen. Durch die Implementierung des Weaver HAL mit dieser sicheren Hardware wird die Anforderung „Sichere Nutzerauthentifizierung“ erfüllt.

Auf Geräten ohne dediziertes Secure Element (SE) kann Weaver trotzdem in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) wie Trusty implementiert werden.

In Android 17 und höher wird die Implementierung von Weaver auch auf Geräten ohne dediziertes sicheres Element dringend empfohlen.

Komponenten

Weaver besteht aus drei Komponenten:

  • Weaver-AIDL-Schnittstelle (IWeaver): Die formale Spezifikation der HAL. Unter Android 13 und niedriger wurde HIDL anstelle von AIDL verwendet.
  • Weaver-Hardwareabstraktionsschicht (HAL)-Dienst: Ein anbieterspezifischer Android-Prozess, der die IWeaver-Schnittstelle implementiert.
  • Weaver Trusted Application (TA): Die Kernlogik, die in einer sicheren Umgebung ausgeführt wird. Sie führt die LSKF-Überprüfung durch und erzwingt die Ratenbegrenzung. Der HAL-Dienst kommuniziert über einen implementationsspezifischen sicheren Kanal mit der TA.

Schnittstelle

Die Weaver-Schnittstelle bietet ein Array mit persistenter Größe mit Slots, die jeweils einen Schlüssel und einen Wert mit fester Größe enthalten. Jeder Slot wird durch seine ID identifiziert, eine Ganzzahl im Intervall [0, numSlots - 1]. Der Wert eines Slots ist nur zugänglich, wenn ein Schlüssel bereitgestellt wird, der mit dem gespeicherten Schlüssel übereinstimmt.

Die Weaver-Benutzeroberfläche besteht hauptsächlich aus folgenden Elementen:

  • getConfig(): Ruft die Anzahl der Slots, die Schlüsselgröße und die Wertgröße ab, die von der Implementierung unterstützt werden.
  • write(): Überschreibt den angegebenen Slot mit einem neuen Schlüssel/Wert-Paar. Dieser Vorgang ist atomar und macht vorherige Daten dauerhaft nicht wiederherstellbar (sicheres Löschen).
  • read(): Versucht, den Wert des angegebenen Slots abzurufen. Dies ist nur möglich, wenn das vom TA erzwungene Zeitlimit für die Ratenbegrenzung nicht aktiv ist und der angegebene Schlüssel genau mit dem gespeicherten Schlüssel übereinstimmt.
  • warmUp(): In Android 17 und höher wird ein Hinweis darauf gegeben, dass bald ein Lese- oder Schreibvorgang stattfinden könnte.

Die vollständige Schnittstellenspezifikation finden Sie unter IWeaver.aidl.

Verwendung durch Android

Wenn eine Weaver-Implementierung verfügbar ist, wird sie von LockSettingsService im Android-Systemserver verwendet, um Nutzerdaten zu schützen. Für jeden Nutzer auf dem Gerät verwaltet LockSettingsService einen Weaver-Slot:

  • Slot-Schlüssel (weaverKey): Ein Hash des LSKF des Nutzers. Wenn der Nutzer keine Displaysperre hat, wird ein Standardstring verwendet.
  • Slot-Wert (weaverSecret): Ein kryptografisches Secret mit hoher Entropie, das zufällig generiert wird.

Die weaverSecret kann nur auf eine der folgenden Arten abgerufen werden:

  • Stellen Sie dem Weaver-TA die richtige weaverKey gemäß seiner Ratenbegrenzungsrichtlinie zur Verfügung.
  • Die sichere Umgebung, in der die Weaver-TA ausgeführt wird, wird manipuliert. Das ist absichtlich sehr schwierig.

LockSettingsService verwendet sowohl weaverKey als auch weaverSecret, um das synthetische Passwort des Nutzers zu verschlüsseln. Da das synthetische Passwort den Credential-Encrypted-Speicher (CE) des Nutzers für die dateibasierte Verschlüsselung (File-Based Encryption, FBE) und die authentifizierungsgebundenen Schlüssel des Nutzers im Android-Keystore schützt, bleiben die Daten unzugänglich, bis Weaver das Secret freigibt.

In Android 17 und höher ruft LockSettingsService die Methode warmUp() von Weaver auf, wenn die Eingabe des LSKF beginnt. Weaver-Implementierungen können dieses Signal verwenden, um die sichere Hardware aus einem Energiesparmodus zu holen und so die Latenz für eine bevorstehende read()-Anfrage zu verringern.

Weaver und Gatekeeper

Bisher hatte das Gatekeeper-HAL zwei unterschiedliche Rollen in einem einzigen verify()-Aufruf:

  1. Bestätigung: Überprüfung des LSKF mit TEE-erzwungener Ratenbegrenzung.
  2. Bestätigung: Ausstellen einer HardwareAuthToken, um KeyMint (früher Keymaster) darüber zu informieren, dass die LSKF-Authentifizierung erfolgreich war.

Warum der Wechsel zu Weaver?

Mit der Einführung von Tokens zum sicheren Zurücksetzen des Sicherheitscodes in Android 8.1 wurde das „synthetische Passwort“ zum primären kryptografischen Geheimnis. Die beiden oben beschriebenen Rollen werden jetzt durch separate Gatekeeper-Registrierungen abgedeckt: eine für den LSKF unter userId + 100000 und eine für das synthetische Passwort unter userId.

Weaver wurde eingeführt, um die erste Rolle zu übernehmen. Dabei wird eine einfachere HAL-Schnittstelle mit Unterstützung für Implementierungen auf Basis von Secure Elements (SE) verwendet.

Funktion Weaver Gatekeeper
Sicheres Löschen Das sichere Löschen ist erforderlich und lässt sich einfach implementieren, da die Schnittstelle eine feste Anzahl von Slots mit fester Größe verwendet. Eine sichere Löschung ist nicht erforderlich und lässt sich nur schwer implementieren, da die Schnittstelle eine unbegrenzte Anzahl von Registrierungen unterstützt.
Hardware Für Secure Enclaves optimiert, funktioniert aber auch in Trusted Execution Environments. Im Grunde nur TEE. Die Implementierung in einer SE bietet mit dem aktuellen Design keinen Sicherheitsvorteil.
Fehlerbehandlung Deutlichere Fehlercodes Mehrdeutige Fehlercodes. Daher wird auf dem Sperrbildschirm nicht zwischen falschen LSKFs und nicht zusammenhängenden Fehlern unterschieden.
Atomarität Der Code in LockSettingsService, der Weaver verwendet, führt LSKF-Änderungen atomar aus. Neue Daten werden in einen neuen Weaver-Slot geschrieben und der alte Slot wird erst gelöscht, wenn dies sicher ist. Der Code in LockSettingsService, der Gatekeeper verwendet, führt LSKF-Änderungen nicht atomar aus. Alle Nutzerdaten können verloren gehen, wenn beim Ändern des LSKF etwas schiefgeht.

Referenzcode

AOSP enthält zwei Referenzimplementierungen von Weaver:

  • In Android 17 und höher enthält system/weaver/ eine Weaver-Implementierung für allgemeine sichere Umgebungen.
  • In Android 8.1 und höher enthält external/libese/ eine Weaver-Implementierung für ISO/IEC7816-4-kompatible Secure Elements.

Test

Verwenden Sie VtsHalWeaverTargetTest, um eine Weaver-Implementierung zu validieren: 

atest VtsHalWeaverTargetTest

oder:

vts-tradefed run vts -m VtsHalWeaverTargetTest