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 CDD 9.11.2 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 Weaver HAL à 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.

Composants

Weaver se compose de trois composants :

  • Interface AIDL Weaver (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 : 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 la TA à 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 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 le TA) n'est pas actif et que la clé fournie correspond exactement à la clé stockée.

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 du 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 à entropie élevée généré de manière aléatoire.

weaverSecret est conçu pour n'être récupéré que par l'un des éléments suivants :

  • 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 l'agent Weaver. 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 des identifiants chiffrés (CE) de l'utilisateur pour le chiffrement basé sur les fichiers (FBE) 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.

Weaver vs Gatekeeper

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

  1. Validation : vérification du 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 désormais gérés par des inscriptions Gatekeeper distinctes, l'une pour la clé LSKF sous userId + 100000 et l'autre 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.
Traitement des erreurs 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

Le code de référence pour les implémentations Weaver dans les éléments sécurisés compatibles ISO/IEC7816-4 est disponible dans AOSP : external/libese/.

Tests

Pour valider une implémentation Weaver, utilisez VtsHalWeaverTargetTest :

atest VtsHalWeaverTargetTest

ou :

vts-tradefed run vts -m VtsHalWeaverTargetTest