Authentification

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

• Stockage de clés cryptographiques et fournisseur de services. Stocke les clés de chiffrement et fournit des routines de chiffrement standard en plus de ces clés. Android prend en charge un Keystore et un Keymaster basés sur le matériel 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 élément sécurisé (SE), tel que Strongbox.
• Authentificateurs d'utilisateurs. Attester de la présence de l'utilisateur et/ou de l'authentification réussie. Android prend en charge Gatekeeper pour l'authentification par code PIN/modèle/mot de passe et Fingerprint pour l'authentification par empreinte digitale. Les appareils livrés avec Android 9 et versions ultérieures peuvent utiliser BiometricPrompt comme point d'intégration unique pour les empreintes digitales et la biométrie supplémentaire. Ces composants communiquent leur état d'authentification au service de magasin de clés via un canal authentifié. (Le système Android Keystore au niveau du framework est également soutenu 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 basés sur le matériel (AuthTokens).

Inscription

Au premier démarrage de l'appareil après une réinitialisation d'usine, tous les authentificateurs sont prêts à recevoir les inscriptions d'informations d'identification de l'utilisateur. Un utilisateur doit initialement inscrire un code PIN/modèle/mot de passe auprès de Gatekeeper. Cette inscription initiale crée un identifiant sécurisé (SID) utilisateur 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 d'utilisateur est cryptographiquement lié au mot de passe de l'utilisateur ; les authentifications réussies auprès du Gatekeeper génèrent des AuthTokens qui contiennent le SID utilisateur pour ce mot de passe.

Un utilisateur qui souhaite modifier un identifiant doit présenter un identifiant existant. Si un justificatif d'identité existant est vérifié avec succès, le SID utilisateur associé au justificatif d'identité existant est transféré vers le nouveau justificatif d'identité, permettant à l'utilisateur de continuer à accéder aux clés après avoir modifié un justificatif d'identité. Si un utilisateur ne présente pas d'identifiant existant, le nouvel identifiant est inscrit 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 qu'on appelle une inscription non approuvée .

Dans des circonstances normales, le framework Android n'autorise pas une inscription non approuvée, de sorte que la plupart des utilisateurs ne verront jamais cette fonctionnalité. Cependant, les réinitialisations forcées de mot de passe, soit par un administrateur de périphérique, soit par un attaquant, peuvent provoquer cela.

Authentification

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

1. Un utilisateur fournit une méthode d'authentification et le service associé fait une demande au démon associé.
   • Pour le code PIN, le modèle ou le mot de passe, LockSettingsService une demande à gatekeeperd .
   • Les flux d'authentification basés sur la biométrie dépendent de la version d'Android. Sur les appareils exécutant Android 8.x et versions antérieures, FingerprintService envoie une demande à fingerprintd ). Sur les appareils exécutant Android 9 et versions ultérieures, BiometricPrompt une demande au démon biométrique approprié (par exemple, fingerprintd pour les empreintes digitales ou faced pour le visage) à l'aide de la classe Biometric Manager appropriée, telle que FingerprintManager ou FaceManager . Quelle que soit la version, l'authentification biométrique se produit de manière asynchrone après l'envoi de la demande.
2. Le démon envoie des données à son homologue, qui génère un AuthToken :
   • Pour l'authentification par code PIN/modèle/mot de passe, gatekeeperd envoie le code PIN, le modèle ou le hachage du mot de passe à Gatekeeper dans le TEE. Si l'authentification dans le TEE est réussie, le Gatekeeper dans le TEE envoie un AuthToken contenant le SID utilisateur correspondant (signé avec la clé AuthToken HMAC) à son homologue dans le système d'exploitation Android.
   • Pour l'authentification par empreintes digitales, fingerprintd écoute les événements d'empreintes digitales et envoie les données à Fingerprint dans le TEE. Si l'authentification dans le TEE est réussie, Fingerprint dans le TEE envoie un AuthToken (signé avec la clé AuthToken HMAC) à son homologue dans le système d'exploitation Android.
   • Pour les autres authentifications biométriques, le démon biométrique approprié écoute l'événement biométrique et l'envoie au composant TEE biométrique approprié.
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 informe également le service keystore lorsque l'appareil est reverrouillé et lorsque le mot de passe de l'appareil change.)
4. Le service de magasin de clés transmet les AuthTokens à Keymaster et les vérifie à l'aide de la clé partagée avec le Gatekeeper et le composant TEE biométrique pris en charge. Keymaster fait confiance à l'horodatage du jeton comme dernière heure d'authentification et fonde une décision de libération de clé (pour permettre à une application d'utiliser la clé) sur l'horodatage.

Format AuthToken

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

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 trustlets biométriques pris en charge). Ainsi, pour une protection supplémentaire contre les attaques par relecture, 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 fonction d'implémentation dépendante de la plate-forme. La clé ne doit jamais être mise à disposition en dehors du TEE. Si un système d'exploitation TEE ne dispose pas d'un mécanisme de communication interprocessus interne (IPC) et doit transférer les données via le système d'exploitation non approuvé, le transfert doit être effectué via un protocole d'échange de clés sécurisé.

Le système d'exploitation Trusty , qui fonctionne à 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 pas ou ne cachent pas la valeur.

Comme certains TEE n'ont pas d'infrastructure IPC, aucune communication n'a lieu entre les applets dans le TEE. Cela permet également au service de stockage de clés de refuser rapidement les demandes 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.