Weaver

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

Weaver ersetzt die LSKF-Überprüfungsfunktion von Gatekeeper. Gatekeeper wird jedoch weiterhin verwendet, um Hardware-Authentifizierungstokens zu generieren.

In Android 9 und höher, CDD 9.11.2 erfordert, dass Geräte, die StrongBox unterstützen, eine spezielle sichere Hardware bereitstellen, die die sichere Nutzerauthentifizierung unterstützt. Durch die Implementierung der Weaver-HAL mit dieser sicheren Hardware wird die Anforderung „sichere Nutzerauthentifizierung“ erfüllt.

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

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

Komponenten

Weaver besteht aus drei Komponenten:

  • Weaver-AIDL-Schnittstelle (IWeaver): Die formale Spezifikation der HAL. In Android 13 und niedriger wurde HIDL anstelle von AIDL verwendet.
  • Weaver-Hardwareabstraktionsschicht (HAL)-Dienst: Ein anbieterspezifischer Android-Prozess, der die IWeaver Schnittstelle implementiert.
  • Weaver-TA (Trusted Application) : 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 implementierungsspezifischen sicheren Kanal mit der TA.

Schnittstelle

Die Schnittstelle von Weaver präsentiert ein Array mit fester Größe von persistenten 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 angegeben wird, der mit dem gespeicherten Schlüssel übereinstimmt.

Die Schnittstelle von Weaver 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. Diese Operation ist atomar und macht vorherige Daten dauerhaft unwiederherstellbar (sicheres Löschen).
  • read(): Versucht, den Wert des angegebenen Slots abzurufen. Dies ist nur möglich, wenn das von der TA erzwungene Timeout 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 übermittelt, 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, verwendet LockSettingsService auf dem Android-Systemserver sie, um Nutzerdaten zu schützen. LockSettingsService verwaltet für jeden Nutzer auf dem Gerät 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 Geheimnis mit hoher Entropie, das zufällig generiert wird.

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

  • Durch Angabe des richtigen weaverKey für die Weaver-TA innerhalb der Richtlinie zur Ratenbegrenzung.
  • Durch Kompromittierung der sicheren Umgebung, in der die Weaver-TA ausgeführt wird. Dies soll sehr schwierig sein.

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

In Android 17 und höher ruft LockSettingsService die warmUp()-Methode 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 reduzieren.

Weaver im Vergleich zu Gatekeeper

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

  1. Überprüfung:Überprüfung des LSKF mit TEE-erzwungener Ratenbegrenzung.
  2. Attestierung: Ausstellung eines HardwareAuthToken um KeyMint (früher Keymaster) zu benachrichtigen, dass die LSKF-Authentifizierung erfolgreich war.

Warum die Umstellung auf Weaver?

Mit der Einführung von sicheren Tokens zum Zurücksetzen des Sicherheitscodes in Android 8.1 wurde das synthetische Passwort zum primären kryptografischen Geheimnis. Die beiden oben beschriebenen Rollen werden 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 Element (SE) verwendet.

Funktion Weaver Gatekeeper
Sicheres Löschen Sicheres Löschen ist erforderlich und lässt sich einfach implementieren, da die Schnittstelle eine feste Anzahl von Slots mit fester Größe verwendet. Sicheres Löschen ist nicht erforderlich und lässt sich nur schwer implementieren, da die Schnittstelle eine unbegrenzte Anzahl von Registrierungen unterstützt.
Hardware Für SEs optimiert, funktioniert aber auch in TEEs. Effektiv nur TEE. Die Implementierung in einem SE bietet mit dem aktuellen Design keinen Sicherheits vorteil.
Fehlerbehandlung Eindeutigere Fehlercodes. Mehrdeutige Fehlercodes. Daher wird auf dem Sperrbildschirm nicht unterschieden zwischen falschen LSKFs und nicht verwandten Fehlern.
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 ein Fehler auftritt.

Referenzcode

AOSP enthält zwei Referenzimplementierungen von Weaver:

  • In Android 17 und höher, system/weaver/ enthält eine Weaver-Implementierung für allgemeine sichere Umgebungen.
  • In Android 8.1 und höher, external/libese/ enthält 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