Weaver

La couche d'abstraction matérielle (HAL) Weaver (IWeaver.aidl), introduite dans Android 8.1, fournit une interface sécurisée pour l'authentification des utilisateurs avec un facteur de connaissance de l'écran de verrouillage (LSKF), tel qu'un code, un schéma ou un mot de passe.

Weaver remplace la fonctionnalité de validation LSKF de Gatekeeper. Toutefois, Gatekeeper est toujours utilisé pour générer des jetons d'authentification matérielle.

Dans Android 9 et les versions ultérieures, la section 9.11.2 du CDD exige que les appareils compatibles avec StrongBox fournissent un matériel sécurisé dédié qui prend en charge l'authentification sécurisée des utilisateurs. L'implémentation de la HAL Weaver à l'aide de ce matériel sécurisé répond à l'exigence d'"authentification utilisateur sécurisée".

Sur les appareils sans composant sécurisé (SE) dédié, Weaver peut toujours être implémenté dans un environnement d'exécution sécurisé (TEE) tel que Trusty.

Dans Android 17 et versions ultérieures, il est fortement recommandé d'implémenter Weaver, même sur les appareils sans composant sécurisé dédié.

Composants

Weaver se compose de trois composants :

  • Interface Weaver AIDL (IWeaver) : spécification formelle du HAL. Android 13 et les versions antérieures utilisaient HIDL au lieu d'AIDL.
  • Service Weaver Hardware Abstraction Layer (HAL) : processus Android spécifique au fournisseur qui implémente l'interface IWeaver.
  • Application sécurisée Weaver (TA) : logique principale s'exécutant dans un environnement sécurisé. Il effectue la vérification LSKF et applique la limitation du débit. Le service HAL communique avec l'environnement d'exécution sécurisé à l'aide d'un canal sécurisé spécifique à l'implémentation.

Interface

L'interface de Weaver présente un tableau de taille fixe d'emplacements persistants, chacun contenant une clé et une valeur de taille fixe. Chaque emplacement est identifié par son ID, un entier dans l'intervalle [0, numSlots - 1]. La valeur d'un emplacement n'est accessible que lorsqu'une clé correspondant à la clé stockée est fournie.

L'interface de Weaver se compose principalement des éléments suivants :

  • getConfig() : récupère le nombre d'emplacements, la taille de la clé et la taille de la valeur compatibles avec l'implémentation.
  • write() : remplace l'emplacement spécifié par une nouvelle paire clé/valeur. Cette opération est atomique et rend les données précédentes définitivement irrécupérables (suppression sécurisée).
  • read() : tente de récupérer la valeur de l'emplacement spécifié. Cette opération ne réussit que lorsque le délai d'expiration de la limitation du débit (appliqué par l'AT) n'est pas actif et que la clé fournie correspond exactement à la clé stockée.
  • warmUp() : dans Android 17 et versions ultérieures, indique qu'une lecture ou une écriture peut se produire prochainement.

Pour obtenir la spécification complète de l'interface, consultez IWeaver.aidl.

Utilisation par Android

Lorsqu'une implémentation Weaver est disponible, LockSettingsService dans le serveur système Android l'utilise pour protéger les données utilisateur. Pour chaque utilisateur de l'appareil, LockSettingsService gère un emplacement Weaver :

  • Clé d'emplacement (weaverKey) : hachage de la clé LSKF de l'utilisateur. Si l'utilisateur n'a pas configuré de verrouillage de l'écran, une chaîne par défaut est utilisée.
  • Valeur de l'emplacement (weaverSecret) : secret cryptographique aléatoire à haute entropie.

weaverSecret est conçu pour n'être récupéré que par :

  • Fournir le weaverKey correct à l'agent Weaver dans sa règle de limitation du débit.
  • Compromettre l'environnement sécurisé dans lequel s'exécute Weaver TA Cette tâche est volontairement très difficile.

LockSettingsService utilise weaverKey et weaverSecret pour chiffrer le mot de passe synthétique de l'utilisateur. Étant donné que le mot de passe synthétique protège le stockage chiffré par identifiants de l'utilisateur pour le chiffrement basé sur les fichiers et les clés liées à l'authentification de l'utilisateur dans le Keystore Android, les données restent inaccessibles tant que Weaver n'a pas publié le secret.

Dans Android 17 et versions ultérieures, les appels LockSettingsService appellent la méthode warmUp() de Weaver lorsque la clé LSKF commence à être saisie. Les implémentations Weaver peuvent utiliser ce signal pour faire passer le matériel sécurisé d'un état de faible consommation d'énergie à un état de consommation normale afin de réduire la latence pour une prochaine requête read().

Weaver et Gatekeeper

Historiquement, le HAL Gatekeeper remplissait deux rôles distincts dans un seul appel verify() :

  1. Validation : vérification de la clé LSKF, avec limitation du débit appliquée par TEE.
  2. Attestation : émission d'un HardwareAuthToken pour informer KeyMint (anciennement Keymaster) que l'authentification LSKF a réussi.

Pourquoi passer à Weaver ?

Avec l'introduction des jetons de réinitialisation sécurisée du code secret dans Android 8.1, le mot de passe synthétique est devenu le secret cryptographique principal. Les deux rôles décrits ci-dessus sont gérés par des inscriptions Gatekeeper distinctes : une pour la clé LSKF sous userId + 100000 et une pour le mot de passe synthétique sous userId.

Weaver a été introduit pour remplacer le premier rôle, en utilisant une interface HAL plus simple avec prise en charge des implémentations basées sur Secure Element (SE).

Fonctionnalité Weaver Gatekeeper
Suppression sécurisée La suppression sécurisée est requise et facile à implémenter, car l'interface utilise un nombre fixe d'emplacements de taille fixe. La suppression sécurisée n'est pas requise et est difficile à implémenter, car l'interface accepte un nombre illimité d'inscriptions.
Matériel Optimisé pour les SE, mais fonctionne également dans les TEE. TEE uniquement. L'implémenter dans un SE n'offre aucun avantage en termes de sécurité avec la conception actuelle.
Gestion des exceptions Des codes d'erreur plus clairs. Codes d'erreur ambigus. Par conséquent, l'écran de verrouillage ne fait pas la différence entre les codes secrets incorrects et les échecs non liés.
Atomicité Le code de LockSettingsService qui utilise Weaver effectue des modifications LSKF de manière atomique. Les nouvelles données sont écrites dans un nouvel emplacement Weaver, et l'ancien emplacement n'est effacé que lorsque cela ne présente aucun risque. Le code de LockSettingsService qui utilise Gatekeeper n'effectue pas les modifications LSKF de manière atomique. Toutes les données utilisateur peuvent être perdues en cas de problème lors du changement de la clé LSKF.

Code de référence

AOSP contient deux implémentations de référence de Weaver :

  • Dans Android 17 et versions ultérieures, system/weaver/ contient une implémentation Weaver pour les environnements sécurisés généraux.
  • Dans Android 8.1 et versions ultérieures, external/libese/ contient une implémentation Weaver pour les éléments sécurisés compatibles ISO/IEC7816-4.

Tests

Pour valider une implémentation Weaver, utilisez VtsHalWeaverTargetTest : 

atest VtsHalWeaverTargetTest

ou :

vts-tradefed run vts -m VtsHalWeaverTargetTest