Authentication

Android utilise des authentificateurs utilisateur pour déverrouiller l'appareil et contrôler l'accès aux clés cryptographiques. Cela implique les composants suivants :

• Fournisseur de services et de stockage de clés cryptographiques Stocke les clés cryptographiques et fournit des routines de chiffrement standard en plus de ces clés. Android est compatible avec un Keystore matériel et KeyMint (anciennement Keymaster) pour les services de chiffrement, y compris le chiffrement matériel pour le stockage de clés, qui peut inclure un environnement d'exécution sécurisé (TEE) ou un élément sécurisé (SE), tel que StrongBox.
• Authentificateurs utilisateur Attester de la présence de l'utilisateur et/ou de l'authentification réussie. Android est compatible avec Gatekeeper pour l'authentification par code, schéma ou mot de passe, et avec Fingerprint pour l'authentification par empreinte digitale. Les appareils fournis avec Android 9 ou version ultérieure peuvent utiliser BiometricPrompt comme point d'intégration unique pour l'empreinte digitale et d'autres données biométriques. Ces composants communiquent leur état d'authentification avec le service Keystore via un canal authentifié. (Le système Android Keystore au niveau du framework est également soutenu par le service keystore.)

Chacun de ces composants est spécifique au fournisseur, mais l'implémentation du fournisseur est requise pour satisfaire à une spécification d'interface Hardware Abstraction Layer (HAL) et pour réussir les tests VTS (Vendor Test Suite) 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 les requêtes Binder du système Android.
• Une application de confiance (TA, Trusted Application) s'exécute dans l'environnement sécurisé et effectue les opérations sécurisées proprement dites.

Inscription

Au premier démarrage de l'appareil après une réinitialisation des paramètres d'usine, tous les authentificateurs sont prêts à recevoir les identifiants enregistrés par l'utilisateur. Un utilisateur doit d'abord enregistrer un code, un schéma ou un mot de passe avec Gatekeeper (ou Weaver, si disponible). Cette inscription initiale crée un identifiant sécurisé (SID) de 64 bits généré de manière aléatoire, qui sert d'identifiant pour l'utilisateur et de jeton de liaison pour son matériel cryptographique. Ce SID utilisateur est lié de manière cryptographique au mot de passe de l'utilisateur. Les authentifications réussies à Gatekeeper génèrent des AuthTokens contenant le SID utilisateur pour ce mot de passe.

Un utilisateur qui souhaite modifier un identifiant existant doit le présenter. Si un identifiant existant est validé, le SID utilisateur associé à l'identifiant existant est transféré au 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 une inscription non approuvée pour enregistrer un nouvel identifiant sans présenter d'identifiant existant. 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 typique, qui implique des interactions entre plusieurs composants 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 des autres composants.

Une fois qu'un utilisateur a configuré un identifiant et qu'un SID utilisateur lui a été attribué, il peut commencer l'authentification, qui débute lorsqu'il fournit un code, un schéma, un mot de passe, une empreinte digitale ou une autre donnée 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 un code, un schéma ou un 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 TA homologue, 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 Gatekeeper HAL. Si l'authentification dans le TEE réussit, le TA Gatekeeper émet un AuthToken contenant le SID de l'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 module TA d'empreinte digitale dans le TEE, via le HAL d'empreinte digitale. Si l'authentification dans le TEE réussit, le TA d'empreinte digitale émet un AuthToken (signé avec la clé HMAC AuthToken).
   • Pour les autres authentifications biométriques, la liste des daemons biométriques appropriés écoute l'événement biométrique et l'envoie au service HAL biométrique et à la TA appropriés.
3. Le démon reçoit un AuthToken signé et le transmet au service Keystore via une extension de l'interface Binder du service Keystore. (gatekeeperd avertit également le service Keystore lorsque l'appareil est à nouveau verrouillé et lorsque le mot de passe de l'appareil change.)
4. Le service Keystore transmet les jetons d'authentification à KeyMint et les valide à l'aide de la clé partagée avec le composant TEE biométrique Gatekeeper et compatible. KeyMint considère l'horodatage du jeton comme la dernière heure d'authentification et fonde sa décision de libérer une clé (pour permettre à une application de l'utiliser) sur cet horodatage.

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 de l'authentificateur vers le service keystore2 dans Android, qui les transmet à son tour à la TA KeyMint. Cela permet également au service keystore2 de refuser rapidement les requêtes qui sont 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 AuthToken

Le format de l'AuthToken est donné 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 les trustlets biométriques compatibles). Ainsi, pour une protection renforcée contre les attaques par rejeu, la clé HMAC doit être générée de manière aléatoire chaque fois que l'appareil redémarre.

Il existe deux façons courantes pour les TA d'accéder à cette clé HMAC partagée :

• Accord sur le secret partagé : le service keystore2 exécute un protocole d'accord sur les clés 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 participantes. Toutefois, les TA participants doivent avoir accès à un secret commun prépartagé.
• Accès direct : les TA qui résident dans le même environnement sécurisé peuvent utiliser un mécanisme de communication interprocessus 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 de l'environnement d'exécution sécurisé.

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 la trustlet biométrique appropriée. 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.

Étant donné que 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 qui sont vouées à l'échec, car il connaît la table d'authentification du système, ce qui permet d'économiser un IPC potentiellement coûteux dans le TEE.