Gatekeeper

Le sous-système Gatekeeper effectue l'authentification par mot de passe/schéma de l'appareil dans un environnement d'exécution sécurisé (TEE). Gatekeeper enregistre et valide les mots de passe à l'aide d'une clé secrète matérielle. De plus, Gatekeeper limite le nombre de tentatives de validation infructueuses consécutives et doit refuser de traiter les demandes en fonction d'un délai d'attente et d'un nombre donné de tentatives infructueuses consécutives.

Lorsque les utilisateurs valident leurs mots de passe, Gatekeeper émet un jeton d'authentification signé avec une clé HMAC par démarrage, qui n'est disponible que pour les composants sécurisés. Ce jeton est envoyé au Keystore soutenu par le matériel. En d'autres termes, un jeton d'authentification Gatekeeper indique à Keystore que les applications peuvent utiliser les clés liées à l'authentification (par exemple, les clés créées par les applications).

Architecture

Gatekeeper comporte trois composants principaux :

• gatekeeperd (daemon Gatekeeper) : service Binder C++ dans Android qui contient une logique indépendante de la plate-forme implémentant l'interface AIDL IGateKeeperService, basée sur une implémentation IGatekeeper sous-jacente spécifique au fournisseur.
• Service de couche d'abstraction matérielle (HAL) Gatekeeper : implémentation spécifique au fournisseur de l'interface AIDL IGatekeeper. Ce service HAL s'exécute dans Android, mais la fonctionnalité Gatekeeper de base doit s'exécuter dans un environnement sécurisé. Il communique donc généralement avec la TA Gatekeeper.
• Application de confiance Gatekeeper : implémentation spécifique au fournisseur qui s'exécute dans le TEE et effectue la validation du mot de passe ou du schéma.

LockSettingsService envoie une requête (via Binder) qui atteint le démon gatekeeperd dans l'OS Android. Le démon gatekeeperd envoie ensuite une requête au service HAL IGatekeeper, qui à son tour atteint son homologue Gatekeeper TA dans le TEE :

Figure 1 : Flux de données de haut niveau pour l'authentification par GateKeeper.

Le démon gatekeeperd donne aux API du framework Android l'accès à la HAL et participe à la création de rapports sur les authentifications des appareils dans le Keystore. Le démon gatekeeperd s'exécute dans son propre processus et est distinct du serveur système.

Implémentation HAL

Le démon gatekeeperd utilise le HAL IGatekeeper pour interagir avec le TA Gatekeeper sous-jacent pour l'authentification par mot de passe. L'implémentation de l'environnement d'exécution sécurisé Gatekeeper doit être capable de signer (enregistrer) et de valider les blobs. Toutes les implémentations doivent respecter le format standard du jeton d'authentification (HardwareAuthToken) généré à chaque validation de mot de passe réussie. Pour en savoir plus sur le contenu et la sémantique de HardwareAuthToken, consultez la définition de HardwareAuthToken.aidl.

Les implémentations du fournisseur du HAL IGatekeeper doivent implémenter les fonctions enroll et verify :

• La méthode enroll prend un blob de mot de passe, le signe et renvoie la signature sous forme de handle. Le blob renvoyé (à partir d'un appel à enroll) doit avoir la structure indiquée dans system/gatekeeper/include/gatekeeper/password_handle.h.
• La fonction verify doit comparer la signature produite par le mot de passe fourni et s'assurer qu'elle correspond au handle du mot de passe enregistré.

La clé utilisée pour l'enregistrement et la validation ne doit jamais changer et doit pouvoir être redérivée à chaque démarrage de l'appareil.

Trusty et autres implémentations

Le système d'exploitation Trusty est l'OS sécurisé Open Source de Google pour les environnements TEE. Il contient une implémentation approuvée de Gatekeeper. Toutefois, n'importe quel OS TEE peut implémenter Gatekeeper à condition que le TEE ait accès à une clé persistante soutenue par le matériel et à une horloge sécurisée et monotone qui fonctionne en mode veille.

Trusty utilise un système IPC interne pour communiquer une clé secrète partagée directement entre KeyMint (anciennement Keymaster) et l'implémentation Trusty de Gatekeeper (le Trusty Gatekeeper). Ce secret partagé est utilisé pour signer les jetons d'authentification envoyés à Keystore afin de fournir des attestations de validation du mot de passe. Trusty Gatekeeper demande la clé à KeyMint pour chaque utilisation et ne conserve ni ne met en cache la valeur. Les implémentations sont libres de partager ce secret de toute manière qui ne compromet pas la sécurité.

La clé HMAC utilisée pour enregistrer et valider les mots de passe est dérivée et conservée uniquement dans Gatekeeper.

Android fournit une implémentation Gatekeeper C++ générique qui ne nécessite que l'ajout de routines spécifiques à l'appareil pour être complète. L'implémentation Trusty est basée sur celle-ci. Pour implémenter un Gatekeeper TEE avec un code spécifique à l'appareil pour votre TEE, reportez-vous aux fonctions et aux commentaires dans system/gatekeeper/include/gatekeeper/gatekeeper.h. Les principales responsabilités d'une implémentation conforme incluent :

• Respect du HAL IGatekeeper.
• Les jetons d'authentification renvoyés doivent être mis en forme conformément à la spécification HardwareAuthToken (décrite dans Authentification).
• Le Gatekeeper TEE doit pouvoir partager une clé HMAC avec KeyMint, soit en demandant la clé via un IPC TEE à la demande, soit en conservant un cache valide de la valeur à tout moment.

ID sécurisés utilisateur (SID)

Un SID utilisateur est la représentation TEE d'un utilisateur (sans lien fort avec un ID utilisateur Android). Le SID est généré avec un générateur de nombres pseudo-aléatoires (PRNG) cryptographique chaque fois qu'un utilisateur enregistre un nouveau mot de passe sans en fournir un précédent. Il s'agit d'une réinscription non fiable, qui ne se produit normalement que lorsqu'un utilisateur définit un mot de passe ou un schéma pour la première fois.

Une réinscription fiable se produit lorsqu'un utilisateur fournit un ancien mot de passe valide, par exemple lorsqu'il change de mot de passe. Dans ce cas, le SID de l'utilisateur est migré vers le nouveau handle de mot de passe, ce qui conserve les clés qui y étaient liées.

Le SID de l'utilisateur est inclus dans l'authentification HMAC avec le mot de passe dans le handle du mot de passe lorsque le mot de passe est enregistré.

Les SID utilisateur sont inclus dans le HardwareAuthToken renvoyé par la fonction verify() et associés à toutes les clés Keystore liées à l'authentification (pour en savoir plus sur le format HardwareAuthToken et Keystore, consultez Authentification).

Notez qu'un appel non approuvé à la fonction enroll() modifie le SID de l'utilisateur, ce qui rend les clés liées à ce mot de passe inutiles. Les pirates informatiques peuvent modifier le mot de passe de l'appareil s'ils contrôlent l'OS Android, mais ils détruisent les clés sensibles protégées par le root au cours du processus.

Limitation des requêtes

Gatekeeper doit être en mesure de limiter de manière sécurisée les tentatives de force brute sur les identifiants d'un utilisateur. Comme indiqué dans GatekeeperVerifyResponse.aidl, le HAL permet de renvoyer un délai avant expiration en millisecondes. Le délai avant expiration indique au client de ne pas rappeler Gatekeeper avant la fin du délai. Gatekeeper ne doit pas traiter les requêtes si un délai d'attente est en cours.

Gatekeeper doit écrire un compteur d'échecs avant de valider le mot de passe d'un utilisateur. Si la validation du mot de passe réussit, le compteur d'échecs doit être effacé. Cela empêche les attaques qui empêchent la limitation du débit en désactivant la carte MMC intégrée (eMMC) après l'émission d'un appel verify. La fonction enroll vérifie également le mot de passe de l'utilisateur (le cas échéant) et doit être limitée de la même manière.

Si l'appareil le permet, il est vivement recommandé d'écrire le compteur d'échecs dans un espace de stockage sécurisé. Si l'appareil n'est pas compatible avec le chiffrement basé sur des fichiers ou si le stockage sécurisé est trop lent, les implémentations peuvent utiliser directement le bloc mémoire protégé contre la relecture (RPMB).