Authentication

Android utilise le concept d'authentificateurs utilisateur, qui permettent de déverrouiller l'appareil et de contrôler l'accès aux clés cryptographiques. Cela implique les composants suivants :

  • Fournisseur de services et de stockage de clés cryptographiques. Android Keystore fournit des services cryptographiques intégrés au matériel pour les applications. Le système Android Keystore au niveau du framework est soutenu par le service système keystore2. Il est basé sur une implémentation KeyMint (anciennement Keymaster) sous-jacente spécifique au fournisseur, qui garantit que le matériel de clé n'est accessible que dans un environnement sécurisé intégré au matériel, tel qu'un environnement d'exécution sécurisé (TEE) ou un composant sécurisé (SE), comme StrongBox.
  • Authentificateurs d'utilisateurs Attester de l'authentification réussie de l'utilisateur. Android est compatible avec les composants d'authentification suivants :
    • Gatekeeper pour l'authentification par code, schéma ou mot de passe dans le TEE.
    • (Facultatif) Weaver pour l'authentification par code, schéma ou mot de passe dans un élément sécurisé.
    • Empreinte digitale pour l'authentification par empreinte digitale.
    • Autres méthodes d'authentification biométrique Les appareils équipés d'Android 9 ou version ultérieure peuvent utiliser BiometricPrompt comme point d'intégration unique pour les empreintes digitales et d'autres données biométriques.
    Ces composants communiquent leur état d'authentification au service keystore2 à l'aide de jetons d'authentification (AuthTokens) intégrés au matériel.

Chacun de ces composants est spécifique au fournisseur, mais l'implémentation du fournisseur doit respecter une spécification d'interface de couche d'abstraction matérielle (HAL) et réussir les tests de la suite de tests du fournisseur (VTS) correspondants.

Les implémentations des fournisseurs sont généralement divisées en deux parties, connectées par un mécanisme de communication spécifique au fournisseur :

  • Un service HAL s'exécute en tant que processus système Android et reçoit des requêtes Binder du système Android.
  • Une application de confiance (TA) s'exécute dans l'environnement sécurisé et effectue les opérations de sécurité réelles.

Enregistrement

Lors du premier démarrage de l'appareil après un rétablissement de la configuration d'usine, tous les authentificateurs sont prêts à recevoir les enregistrements d'identifiants de l'utilisateur. Un utilisateur doit d'abord enregistrer un code, un schéma ou un mot de passe auprès de Gatekeeper (ou de Weaver, si disponible). Cet enregistrement initial crée un identifiant de sécurité utilisateur (SID) 64 bits généré de manière aléatoire, qui sert d'identifiant pour l'utilisateur et de jeton de liaison pour le matériel cryptographique de l'utilisateur. Ce SID utilisateur est lié de manière cryptographique au mot de passe de l'utilisateur. Les authentifications réussies auprès de Gatekeeper génèrent des AuthTokens contenant le SID utilisateur pour ce mot de passe.

Un utilisateur qui souhaite modifier un identifiant existant doit présenter cet identifiant. Si un identifiant existant est validé, le SID utilisateur associé à l'identifiant existant est transféré vers le nouvel identifiant, ce qui permet à l'utilisateur de continuer à accéder aux clés après avoir modifié un identifiant.

Dans certains cas, un administrateur d'appareil peut effectuer un enregistrement non fiable pour enregistrer un nouvel identifiant sans présenter d'identifiant existant. Cela permet à l'utilisateur d'accéder à l'appareil, mais les clés créées sous l'ancien SID utilisateur sont définitivement perdues.

Authentification

Cette section décrit un flux d'authentification standard, qui implique des interactions entre plusieurs composants d'Android et de l'environnement sécurisé. Notez que tous les composants sécurisés partagent une clé HMAC secrète (par démarrage) qu'ils utilisent pour authentifier les messages des uns et des autres.

Une fois qu'un utilisateur a configuré un identifiant et qu'un SID lui a été attribué, il peut commencer l'authentification. Celle-ci débute lorsqu'un utilisateur fournit un code, un schéma, un mot de passe, une empreinte digitale ou une autre donnée biométrique forte. Flux d'authentification

Figure 1. Flux d'authentification

  1. Un utilisateur fournit une méthode d'authentification, et le service associé envoie une requête au service HAL.
    • Pour le code, le schéma ou le mot de passe, LockSettingsService envoie une requête à gatekeeperd.
    • Les flux d'authentification biométrique dépendent de la version d'Android. Sur les appareils équipés d'Android 8.x ou version antérieure, FingerprintService envoie une requête à fingerprintd. Sur les appareils équipés d'Android 9 ou version ultérieure, BiometricPrompt envoie une requête au daemon biométrique approprié (par exemple, fingerprintd pour les empreintes digitales ou faced pour le visage) à l'aide de la classe BiometricManager appropriée, telle que FingerprintManager ou FaceManager. Quelle que soit la version, l'authentification biométrique s'effectue de manière asynchrone après l'envoi de la requête.
  2. Le service HAL envoie des données à son TA équivalent, qui génère un AuthToken :
    • Pour l'authentification par code, schéma ou mot de passe, gatekeeperd envoie le hachage du code, du schéma ou du mot de passe au TA Gatekeeper dans le TEE, via le service HAL Gatekeeper. Si l'authentification dans le TEE réussit, le TA Gatekeeper émet un AuthToken contenant le SID utilisateur correspondant (signé avec la clé HMAC partagée).
    • Pour l'authentification par empreinte digitale, fingerprintd écoute les événements d'empreinte digitale et envoie les données à l'application de confiance Fingerprint dans l'environnement d'exécution sécurisé (TEE), via la HAL Fingerprint. Si l'authentification dans le TEE réussit, l'AT d'empreinte digitale émet un AuthToken (signé avec la clé HMAC AuthToken).
    • Pour les autres authentifications biométriques, le daemon biométrique approprié écoute l'événement biométrique et l'envoie au service HAL biométrique et au TA appropriés.
  3. Le jeton d'authentification signé obtenu est transmis au service système keystore2 via une interface Binder.
  4. Le service keystore2 associe les AuthTokens à la requête pour que KeyMint (anciennement Keymaster) effectue des opérations cryptographiques. Le service HAL KeyMint les transmet à l'AT KeyMint, qui les valide à l'aide de la clé HMAC partagée avec Gatekeeper et les composants TEE biométriques compatibles. KeyMint considère le code temporel du jeton comme la dernière heure d'authentification et décide d'autoriser ou non l'utilisation de la clé en fonction de ce code temporel.

Le flux d'authentification ne nécessite pas de communication directe entre les TA dans l'environnement sécurisé : les AuthTokens transitent de la TA d'authentification au service keystore2 dans Android, qui les transmet à son tour à la TA KeyMint. Cela permet également au service keystore2 de refuser rapidement les requêtes vouées à l'échec, car il connaît les AuthTokens disponibles dans le système, ce qui évite un IPC potentiellement coûteux dans le TEE.

Format du jeton d'authentification

Le format de l'AuthToken est indiqué par la spécification AIDL dans HardwareAuthToken.aidl.

Processus de démarrage de l'appareil

À chaque démarrage d'un appareil, la clé HMAC AuthToken doit être générée et partagée avec tous les composants TEE (Gatekeeper, KeyMint et TA biométriques compatibles). Pour éviter les attaques par rejeu, la clé HMAC doit être générée de manière aléatoire à chaque redémarrage de l'appareil.

Les TA peuvent accéder à cette clé HMAC partagée de deux manières courantes :

  • Accord de secret partagé : le service keystore2 exécute un protocole d'accord de clé multidirectionnel au démarrage de l'appareil, ce qui permet de dériver de manière sécurisée la clé HMAC entre les TA participants. Toutefois, les TA participants doivent avoir accès à un secret prépartagé commun.
  • Accès direct : les TA qui résident dans le même environnement sécurisé peuvent utiliser un mécanisme de communication inter-processus interne (qui dépend de la plate-forme) pour partager la clé HMAC.

Dans les deux cas, la clé HMAC ne doit jamais être mise à disposition en dehors du TEE.

Le système d'exploitation Trusty, qui s'exécute à côté d'Android, est un exemple de TEE, mais d'autres TEE peuvent être utilisés à la place. Trusty utilise un système IPC interne pour communiquer directement entre KeyMint et Gatekeeper ou l'AT biométrique appropriée. La clé HMAC est conservée uniquement dans KeyMint. Fingerprint et Gatekeeper demandent la clé à KeyMint à chaque utilisation, et ne conservent pas ni ne mettent en cache la valeur.

Comme certains TEE ne disposent pas d'infrastructure IPC, aucune communication n'a lieu entre les applets du TEE. Cela permet également au service Keystore de refuser rapidement les requêtes vouées à l'échec, car il connaît la table d'authentification du système, ce qui évite un IPC potentiellement coûteux dans le TEE.