Cette page a été traduite par l'API Cloud Translation.

Authentication

Android utilise le concept de clés cryptographiques contrôlées par l'authentification de l'utilisateur, qui nécessite les composants suivants:

Fournisseur de services et de stockage de clés cryptographiques. Stocke des clés cryptographiques et fournit des routines de chiffrement standards en plus de ces clés. Android est compatible avec un Keystore basé sur le matériel et Keymaster pour les services cryptographiques, y compris la cryptographie basée sur le matériel pour le stockage des clés, qui peut inclure un environnement d'exécution sécurisé (TEE) ou un composant 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/mot de passe et Fingerprint pour l'authentification par empreinte digitale. Les appareils livrés avec Android 9 ou version ultérieure peuvent utiliser BiometricPrompt comme point d'intégration unique pour l'empreinte digitale et les données biométriques supplémentaires. 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 pris en charge par le service keystore.)

Les composants Gatekeeper, Fingerprint et Biometric fonctionnent avec Keystore et d'autres composants pour prendre en charge l'utilisation de jetons d'authentification (AuthTokens) basés sur du matériel.

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/schéma/mot de passe avec Gatekeeper. Cette inscription initiale crée un identifiant sécurisé utilisateur (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 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 doit présenter des identifiants existants. 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. Si un utilisateur ne présente pas d'identifiants existants, les nouveaux identifiants sont enregistrés avec un SID utilisateur entièrement aléatoire. L'utilisateur peut accéder à l'appareil, mais les clés créées sous l'ancien SID utilisateur sont définitivement perdues. C'est ce que nous appelons une inscription non approuvée.

Dans des conditions normales, le framework Android n'autorise pas l'enregistrement non approuvé. Par conséquent, la plupart des utilisateurs ne verront jamais cette fonctionnalité. Toutefois, des réinitialisations de mot de passe forcées, par un administrateur de l'appareil ou un pirate informatique, peuvent entraîner cette situation.

Authentification

Une fois qu'un utilisateur a configuré des identifiants et reçu un SID utilisateur, il peut commencer l'authentification, qui commence lorsqu'il fournit un code, un schéma, un mot de passe ou une empreinte digitale. Tous les composants TEE partagent une clé secrète qu'ils utilisent pour s'authentifier mutuellement.

Figure 1 Flux d'authentification

Un utilisateur fournit une méthode d'authentification, et le service associé envoie une requête au daemon associé.
- 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.
Le daemon envoie des données à son 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 à Gatekeeper dans le TEE. Si l'authentification dans le TEE aboutit, Gatekeeper dans le TEE envoie un AuthToken contenant le SID utilisateur correspondant (signé avec la clé HMAC AuthToken) à son homologue dans l'OS Android.
- Pour l'authentification par empreinte digitale, fingerprintd écoute les événements d'empreinte digitale et envoie les données à Fingerprint dans le TEE. Si l'authentification dans le TEE aboutit, l'empreinte digitale dans le TEE envoie un AuthToken (signé avec la clé HMAC AuthToken) à son homologue dans l'OS Android.
- Pour toute autre authentification biométrique, le daemon biométrique approprié écoute l'événement biométrique et l'envoie au composant TEE biométrique approprié.
Le daemon reçoit un AuthToken signé et le transmet au service keystore via une extension de l'interface Binder du service keystore. (gatekeeperd informe également le service Keystore lorsque l'appareil est verrouillé de nouveau et que le mot de passe de l'appareil change.)
Le service Keystore transmet les AuthTokens à Keymaster et les valide à l'aide de la clé partagée avec le Gatekeeper et du composant TEE biométrique compatible. Keymaster considère le code temporel du jeton comme la dernière heure d'authentification et base sa décision de libération de clé (pour autoriser une application à utiliser la clé) sur le code temporel.

Format AuthToken

Pour assurer le partage et la compatibilité des jetons entre les langues et les composants, le format AuthToken est décrit dans hw_auth_token.h. Il s'agit d'un protocole de sérialisation simple avec des champs de taille fixe.

Champ	Type	Obligatoire	Description
Version de l'AuthToken	1 octet	Oui	Balise de groupe pour tous les champs ci-dessous.
Défi	Entier non signé de 64 bits	Non	Entier aléatoire pour éviter les attaques par rejeu. Généralement, l'ID d'une opération de cryptographie demandée. Actuellement utilisé par les autorisations d'empreinte transactionnelle. Le cas échéant, AuthToken n'est valide que pour les opérations de cryptographie contenant le même défi.
SID utilisateur	Entier non signé de 64 bits	Oui	Identifiant utilisateur non répétitif lié de manière cryptographique à toutes les clés associées à l'authentification de l'appareil. Pour en savoir plus, consultez Gatekeeper.
ID de l'authentificateur (ASID)	Entier non signé de 64 bits dans l'ordre réseau	Non	Identifiant utilisé pour associer à une règle d'authentificateur spécifique. Tous les authentificateurs ont leur propre valeur d'ASID qu'ils peuvent modifier en fonction de leurs propres exigences.
Type d'authentificateur	Entier non signé de 32 bits dans l'ordre réseau	Oui	0x00 correspond à Gatekeeper. 0x01 correspond à l'empreinte digitale.
Code temporel	Entier non signé de 64 bits dans l'ordre réseau	Oui	Durée (en millisecondes) depuis le dernier démarrage du système.
AuthToken HMAC (SHA-256)	Blob 256 bits	Oui	MAC SHA-256 avec clé de tous les champs, à l'exception du champ HMAC.

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, Keymaster et les trustlets biométriques compatibles). Par conséquent, pour une protection accrue contre les attaques par rejeu, la clé HMAC doit être générée de manière aléatoire à chaque redémarrage de l'appareil.

Le protocole de partage de cette clé HMAC avec tous les composants est une fonctionnalité d'implémentation dépendante de la plate-forme. La clé ne doit jamais être mise à disposition en dehors du TEE. Si un OS TEE ne dispose pas d'un mécanisme de communication interprocessus (IPC) interne et doit transférer les données via l'OS non approuvé, le transfert doit être effectué via un protocole d'échange de clés 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 Keymaster et Gatekeeper ou le trustlet biométrique approprié. La clé HMAC est conservée uniquement dans Keymaster. Fingerprint et Gatekeeper demandent la clé à Keymaster pour chaque utilisation et ne conservent ni ne mettent en cache la valeur.

Comme certains TEE ne disposent pas d'une 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 à échouer, car il connaît la table d'authentification du système, ce qui évite un IPC potentiellement coûteux dans le TEE.