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 le facteur de connaissance de l'écran de verrouillage (LSKF), tel que le code, le schéma et le mot de passe.

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

Dans Android 9 et versions ultérieures, la section 9.11.2 du CDD exige que les appareils compatibles avec StrongBox fournissent du 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 sécurisée des utilisateurs.

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, l'implémentation de Weaver est fortement recommandée, même sur les appareils sans composant sécurisé dédié.

Composants

Weaver se compose de trois composants :

• Interface AIDL Weaver (IWeaver) : spécification formelle de la HAL. Android 13 et versions antérieures utilisaient HIDL au lieu d'AIDL.
• Service HAL (couche d'abstraction matérielle) Weaver: processus Android spécifique au fournisseur qui implémente l' IWeaver interface.
• Application de confiance (TA) Weaver: logique de base s'exécutant dans un environnement sécurisé. Elle 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é de taille fixe et une valeur de taille fixe. Chaque emplacement est identifié par son ID, un entier compris 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'inactivité de la limitation du débit (appliquée par la TA) n'est pas actif et que la clé fournie correspond exactement à la clé stockée.
• warmUp() : dans Android 17 et versions ultérieures, transmet un indice indiquant 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 sur 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 de verrouillage d'écran, une chaîne par défaut est utilisée.
• Valeur d'emplacement (weaverSecret) : secret cryptographique à haute entropie généré de manière aléatoire.

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

• Fournir le weaverKey correct à la TA Weaver dans sa règle de limitation du débit.
• Compromettre l'environnement sécurisé dans lequel la TA Weaver s'exécute. Cette opération est censée être très difficile.

LockSettingsService utilise à la fois 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 les identifiants (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 ne publie pas le secret.

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

Weaver vs. Gatekeeper

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

1. Vérification : vérification du LSKF, avec limitation du débit appliquée par le 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 de jetons de réinitialisation de code sécurisés 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 le LSKF sous userId + 100000 et l'autre pour le mot de passe synthétique sous userId.

Weaver a été introduit pour prendre en charge le premier rôle, en utilisant une interface HAL plus simple compatible avec les implémentations basées sur le composant sécurisé (SE).

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 composants sécurisés compatibles avec la norme ISO/IEC7816-4.

Tests

Pour valider une implémentation Weaver, utilisez VtsHalWeaverTargetTest :

atest VtsHalWeaverTargetTest

ou :

vts-tradefed run vts -m VtsHalWeaverTargetTest