Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Portier

Le sous-système Gatekeeper effectue une authentification par modèle / mot de passe de périphérique dans un environnement d'exécution sécurisé (TEE). Gatekeeper enregistre et vérifie les mots de passe via un HMAC avec une clé secrète matérielle. De plus, Gatekeeper limite les tentatives de vérification échouées consécutives et doit refuser de traiter les demandes en fonction d'un délai d'expiration donné et d'un nombre donné de tentatives infructueuses consécutives.

Lorsque les utilisateurs vérifient leurs mots de passe, Gatekeeper utilise le secret partagé dérivé de TEE pour signer une attestation d'authentification à envoyer au magasin de clés matériel . Autrement dit, une attestation de Gatekeeper notifie Keystore que les clés liées à l'authentification (par exemple, les clés que les applications ont créées) peuvent être libérées pour être utilisées par les applications.

Architecture

Gatekeeper comprend trois composants principaux:

  • gatekeeperd (démon Gatekeeper). Un service de classeur C ++ contenant une logique indépendante de la plate-forme et correspondant à l'interface Java GateKeeperService .
  • Couche d'abstraction matérielle de Gatekeeper (HAL) . L'interface HAL dans hardware/libhardware/include/hardware/gatekeeper.h , et le module d'implémentation.
  • Gatekeeper (TEE) . L'homologue TEE de gatekeeperd . Une implémentation de Gatekeeper basée sur TEE.

Gatekeeper nécessite l'implémentation du Gatekeeper HAL (en particulier les fonctions dans hardware/libhardware/include/hardware/gatekeeper.h ) et le composant Gatekeeper spécifique à TEE (basé en partie sur le fichier d'en-tête system/gatekeeper/include/gatekeeper/gatekeeper.h qui inclut des fonctions virtuelles pures pour créer / accéder aux clés et calculer les signatures).

Le LockSettingsService fait une demande (via Binder) qui atteint le démon gatekeeperd dans le système d'exploitation Android. Le démon gatekeeperd fait alors une requête qui atteint son homologue (Gatekeeper) dans le TEE:

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

Le démon gatekeeperd permet aux API du framework Android d'accéder à la HAL et participe à la création de rapports sur les authentifications des appareils à 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 la HAL pour interagir avec l'homologue TEE du démon gatekeeperd pour l'authentification par mot de passe. L'implémentation HAL doit pouvoir signer (inscrire) et vérifier les objets blob. Toutes les implémentations doivent respecter le format standard du jeton d'authentification (AuthToken) généré à chaque vérification réussie du mot de passe. Pour plus de détails sur le contenu et la sémantique du AuthToken, consultez Format AuthToken .

Les implémentations du fichier d'en-tête hardware/libhardware/include/hardware/gatekeeper.h doivent implémenter les fonctions d' enroll et de verify :

  • La fonction d' enroll prend un objet blob de mot de passe, le signe et renvoie la signature en tant que handle. Le blob retourné (d'un appel à l' enroll ) doit avoir la structure indiquée dans system/gatekeeper/include/gatekeeper/password_handle.h .
  • La fonction de verify doit comparer la signature produite par le mot de passe fourni et s'assurer qu'elle correspond au descripteur de mot de passe inscrit.

La clé utilisée pour inscrire et vérifier ne doit jamais changer et doit être redérivable à chaque démarrage de l'appareil.

Trusty et autres implémentations

Le système d'exploitation Trusty est le système d'exploitation de confiance open source de Google pour les environnements TEE et contient une implémentation approuvée de GateKeeper. Cependant, vous pouvez utiliser n'importe quel système d' exploitation TEE pour implémenter Gatekeeper tant que le TEE a accès à une clé matérielle et à une horloge monotone sécurisée qui passe en mode veille .

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

La clé HMAC utilisée pour inscrire et vérifier les mots de passe est dérivée et conservée uniquement dans GateKeeper.

Android fournit une implémentation C ++ générique de GateKeeper qui ne nécessite que l'ajout de routines spécifiques à l'appareil pour être complète. Pour implémenter un portier TEE avec un code spécifique à l'appareil pour votre TEE, reportez-vous aux fonctions et commentaires dans system/gatekeeper/include/gatekeeper/gatekeeper.h . Pour le TEE GateKeeper, les principales responsabilités d'une implémentation conforme comprennent:

  • Respect du Gatekeeper HAL.
  • Les AuthTokens retournés doivent être formatés conformément à la spécification AuthToken (décrite dans Authentification ).
  • Le portier TEE doit être en mesure de partager une clé HMAC avec Keymaster, soit en demandant la clé via un IPC TEE à la demande, soit en maintenant un cache valide de la valeur à tout moment.

ID utilisateur sécurisé (SID)

Un SID utilisateur est la représentation TEE d'un utilisateur (sans connexion forte à un ID utilisateur Android). Le SID est généré avec un générateur de nombres pseudo-aléatoires cryptographiques (PRNG) chaque fois qu'un utilisateur enregistre un nouveau mot de passe sans en fournir le précédent. Ceci est connu comme une réinscription non approuvée et n'est pas autorisé par le framework Android dans des circonstances normales. Une réinscription approuvée se produit lorsqu'un utilisateur fournit un mot de passe précédent valide; dans ce cas, le SID utilisateur est migré vers le nouveau handle de mot de passe, en conservant les clés qui lui étaient liées.

Le SID de l'utilisateur est HMAC avec le mot de passe dans la poignée de mot de passe lorsque le mot de passe est inscrit.

Les SID utilisateur sont écrits dans le AuthToken renvoyé par la fonction de verify et associés à toutes les clés Keystore liées à l'authentification (pour plus de détails sur le format AuthToken et Keystore, voir Authentification ). Comme un appel non approuvé à la fonction d' enroll modifiera le SID utilisateur, l'appel rendra les clés liées à ce mot de passe inutiles. Les attaquants peuvent modifier le mot de passe de l'appareil s'ils contrôlent le système d'exploitation Android, mais ils détruiront les clés sensibles protégées contre la racine au cours du processus.

Demander une limitation

GateKeeper doit être en mesure de limiter en toute sécurité les tentatives de force brute sur les informations d'identification d'un utilisateur. Comme indiqué dans hardware/libhardware/include/hardware/gatekeeper.h , la HAL permet de renvoyer un timeout en millisecondes. Le délai d'attente informe le client de ne plus appeler GateKeeper tant que le délai n'est pas écoulé; GateKeeper ne doit pas traiter les demandes s'il y a un délai d'attente.

GateKeeper doit écrire un compteur d'échecs avant de vérifier un mot de passe utilisateur. Si la vérification du mot de passe réussit, le compteur d'échecs doit être effacé. Cela empêche les attaques qui empêchent la limitation en désactivant la console MMC intégrée (eMMC) après avoir émis un appel de verify . La fonction d' enroll vérifie également le mot de passe de l'utilisateur (s'il est fourni) et doit être limitée de la même manière.

S'il est pris en charge par l'appareil, il est fortement recommandé d'écrire le compteur d'échec sur le stockage sécurisé. Si le périphérique ne prend pas en charge le chiffrement basé sur les fichiers, ou si le stockage sécurisé est trop lent, les implémentations peuvent utiliser directement le bloc de mémoire protégée par relecture (RPMB).