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 basés sur du matériel pour les applications. Le système Android Keystore au niveau du framework est pris en charge par le service système keystore2. Cela repose à son tour 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é basé sur du matériel, tel qu'un environnement d'exécution sécurisé (TEE) ou un composant sécurisé (SE).
• Authentificateurs utilisateur Attestez 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 livrés avec Android 9 ou version ultérieure peuvent utiliser BiometricPrompt comme point d'intégration unique pour les empreintes digitales et les données biométriques supplémentaires.
  Ces composants communiquent leur état d'authentification avec le service keystore2 à l'aide de jetons d'authentification (AuthTokens) basés sur du matériel .

Chacun de ces composants est spécifique au fournisseur, mais l'implémentation du fournisseur doit respecter une spécification d'interface Hardware Abstraction Layer (HAL) et réussir les tests de la suite de tests du fournisseur (VTS) correspondante.

Les implémentations du fournisseur sont généralement également divisées en deux parties, connectées par un mécanisme de communication propre au fournisseur :

• Un service HAL s'exécute en tant que processus système Android, recevant des requêtes de liaison du système Android.
• Une application fiable (TA) s'exécute dans l'environnement sécurisé, effectuant les opérations sécurisées.

Inscription

Lors du premier démarrage de l'appareil après une réinitialisation 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 avec Gatekeeper (ou Weaver, le cas échéant). Cette inscription initiale crée un SID (Secure User Identifier) 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 des identifiants existants doit les présenter. Si des identifiants existants sont validés, le SID utilisateur associé aux identifiants existants est transféré vers les nouveaux identifiants, ce qui permet à l'utilisateur de continuer à accéder aux clés après avoir modifié des identifiants.

Dans certains cas, un administrateur d'appareil peut effectuer une inscription non approuvée pour enregistrer de nouveaux identifiants sans présenter d'identifiants existants. L'utilisateur peut ainsi 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 type, qui implique des interactions entre plusieurs composants à la fois dans Android et dans 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 de chacun.

Une fois qu'un utilisateur a configuré des identifiants et qu'un SID utilisateur lui a été attribué, il peut commencer l'authentification, qui commence lorsqu'il fournit un code, un schéma, un mot de passe, une empreinte digitale ou une autre authentification biométrique forte.

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 démon 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 homologue TA, 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 aboutit, 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 au TA Fingerprint dans le TEE, via le HAL Fingerprint. Si l'authentification dans le TEE réussit, le TA Fingerprint émet un jeton AuthToken (signé avec la clé HMAC AuthToken).
   • Pour toute autre authentification biométrique, 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. L'AuthToken signé obtenu est transmis au service système keystore2 via une interface Binder.
4. Le service keystore2 associe les AuthTokens à la requête pour demander à KeyMint (anciennement Keymaster) d'effectuer des opérations de cryptographie. Le service HAL KeyMint les transmet au TA KeyMint, qui les valide à l'aide de la clé HMAC partagée avec le Gatekeeper et les composants TEE biométriques compatibles. KeyMint considère l'horodatage du jeton comme la dernière heure d'authentification et décide d'autoriser ou non l'utilisation de la clé en fonction de l'horodatage.

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

Format AuthToken

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

Flux 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/Keymaster et les 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 partagé prédéfini 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 le TA biométrique approprié. La clé HMAC est conservée uniquement dans KeyMint. Fingerprint et Gatekeeper demandent la clé à KeyMint pour chaque utilisation et ne conservent ni ne mettent en cache la valeur.