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) wie 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 dedizierte 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.

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 aus:

  • 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.

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 abgerufen werden, wenn eine der folgenden Bedingungen erfüllt ist:

  • Der richtige weaverKey wird innerhalb der Richtlinie zur Ratenbegrenzung an die Weaver-TA übergeben.
  • Die sichere Umgebung, in der die Weaver-TA ausgeführt wird, wird kompromittiert. 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 CE-Speicher (Credential-Encrypted) 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 Geheimnis freigibt.

Weaver im Vergleich zu Gatekeeper

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

  1. Überprüfung: Überprüfen des LSKF mit TEE-erzwungener Ratenbegrenzung.
  2. Attestierung: Ausstellen 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 jetzt von separaten Gatekeeper-Registrierungen übernommen, 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 SE-basierte (Secure Element) Implementierungen 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 Optimiert für SEs, funktioniert aber auch in TEEs. Effektiv nur TEE. Die Implementierung in einem SE bietet mit dem aktuellen Design keinen Sicherheitsvorteil.
Fehlerbehebung Eindeutigere Fehlercodes Mehrdeutige Fehlercodes. Daher wird auf dem Sperrbildschirm nicht unterschieden zwischen falschen LSKFs und nicht damit zusammenhängenden Fehlern.
Atomizitä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

Referenzcode für Weaver-Implementierungen in ISO/IEC7816-4-kompatiblen Secure Elements ist in AOSP verfügbar: external/libese/.

Test

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

atest VtsHalWeaverTargetTest

oder:

vts-tradefed run vts -m VtsHalWeaverTargetTest