Cette page contient des informations sur les fonctionnalités de chiffrement d'Android Keystore, telles qu'elles sont fournies par l'implémentation KeyMint (ou Keymaster) sous-jacente.
Primitives cryptographiques
Keystore propose les catégories d'opérations suivantes :
- Création de clés, ce qui génère des éléments de clé privée ou secrète accessibles uniquement à l'environnement sécurisé. Les clients peuvent créer des clés de différentes manières :
- Génération de nouvelles clés
- Importation de matériel de clé non chiffré
- Importation de matériel de clé chiffré
- Attestation de clé : la création d'une clé asymétrique génère un certificat contenant la partie clé publique de la paire de clés. Ce certificat contient éventuellement des informations sur les métadonnées de la clé et l'état de l'appareil, toutes signées par une clé associée à une racine de confiance.
- Opérations de chiffrement :
- Chiffrement et déchiffrement symétriques (AES, 3DES)
- Déchiffrement asymétrique (RSA)
- Signature asymétrique (ECDSA, RSA)
- Signature et validation symétriques (HMAC)
- Accord de clé asymétrique (ECDH)
Les éléments de protocole, tels que l'objectif, le mode et la marge intérieure, ainsi que les contraintes de contrôle des accès, sont spécifiés lors de la génération ou de l'importation des clés et sont liés de manière permanente à la clé, ce qui garantit que la clé ne peut pas être utilisée d'une autre manière.
Les primitives et les modes qui doivent être compatibles avec l'implémentation KeyMint sont décrits dans la spécification de l'interface HAL IKeyMintDevice.
L'implémentation KeyMint sous-jacente doit générer des nombres aléatoires pour permettre la génération de clés et la création de vecteurs de remplissage ou d'initialisation (IV) aléatoires. Pour ce faire, le système Android fournit régulièrement une entropie supplémentaire à l'implémentation KeyMint.
Contrôle des accès aux clés
Les clés matérielles qui ne peuvent jamais être extraites de l'appareil n'offrent pas beaucoup de sécurité si un pirate informatique peut les utiliser à volonté (bien qu'elles soient plus sécurisées que les clés qui peuvent être exfiltrées). Il est donc crucial que Keystore applique des contrôles d'accès.
Les contrôles des accès sont définis comme une "liste d'autorisation" de paires tag/valeur. Les tags d'autorisation sont des entiers 32 bits et les valeurs sont de différents types. Certaines balises peuvent être répétées pour spécifier plusieurs valeurs. La possibilité de répéter un tag est spécifiée dans l'interface HAL KeyMint (anciennement Keymaster).
Les valeurs de tag acceptées sont définies dans le fichier Tag.aidl, et chacune est associée à un TagType qui indique le type de la valeur associée (par exemple, un entier ou des octets) et si elle peut être répétée pour spécifier plusieurs valeurs acceptées.
Lorsque KeyMint crée une clé, l'appelant spécifie une liste d'autorisations pour la clé. Cette liste est modifiée par Keystore et KeyMint pour ajouter des contraintes supplémentaires, et l'implémentation KeyMint sous-jacente encode la liste d'autorisations finale dans le keyblob renvoyé. La liste d'autorisations encodée est liée de manière cryptographique au keyblob. Ainsi, toute tentative de modification de la liste d'autorisations (y compris l'ordre) entraîne un keyblob non valide qui ne peut pas être utilisé pour les opérations cryptographiques.
Application matérielle ou logicielle
Les implémentations matérielles sécurisées ne contiennent pas toutes les mêmes fonctionnalités. Pour prendre en charge différentes approches, KeyMint distingue l'application du contrôle des accès sécurisé et non sécurisé, ou l'application matérielle et logicielle, respectivement.
Cela est exposé dans l'API KeyMint avec le champ securityLevel du type KeyCharacteristics. Le matériel sécurisé est chargé de placer les autorisations dans le KeyCharacteristics avec le niveau de sécurité approprié, en fonction de ce qu'il peut appliquer. Ces informations sont également exposées dans les enregistrements d'attestation pour les clés asymétriques : les caractéristiques des clés pour SecurityLevel::TRUSTED_ENVIRONMENT ou SecurityLevel::STRONGBOX apparaissent dans la liste hardwareEnforced, et les caractéristiques pour SecurityLevel::SOFTWARE ou SecurityLevel::KEYSTORE apparaissent dans la liste softwareEnforced.
Par exemple, les contraintes sur l'intervalle de date et d'heure pendant lequel une clé peut être utilisée ne sont généralement pas appliquées par l'environnement sécurisé, car il n'a pas d'accès fiable aux informations de date et d'heure. Par conséquent, les autorisations telles que Tag::ORIGINATION_EXPIRE_DATETIME sont appliquées par Keystore dans Android et ont la valeur SecurityLevel::KEYSTORE.
Pour savoir comment déterminer si les clés et leurs autorisations sont stockées dans un keystore matériel, consultez Attestation des clés.
Autorisations de construction de messages cryptographiques
Les tags suivants permettent de définir les caractéristiques cryptographiques des opérations utilisant la clé associée :
Tag::ALGORITHMTag::KEY_SIZETag::BLOCK_MODETag::PADDINGTag::CALLER_NONCETag::DIGESTTag::MGF_DIGEST
Les tags suivants sont reproductibles, ce qui signifie que plusieurs valeurs peuvent être associées à une seule clé :
Tag::BLOCK_MODETag::PADDINGTag::DIGESTTag::MGF_DIGEST
La valeur à utiliser est spécifiée au moment de l'opération.
Objectif
Les clés sont associées à un ensemble d'objectifs, exprimés sous la forme d'une ou de plusieurs entrées d'autorisation avec le tag Tag::PURPOSE, qui définit la manière dont elles peuvent être utilisées. Les objectifs sont définis dans KeyPurpose.aidl.
Notez que certaines combinaisons de valeurs d'objectif créent des problèmes de sécurité. Par exemple, une clé RSA pouvant être utilisée à la fois pour chiffrer et signer permet à un pirate informatique de convaincre le système de déchiffrer des données arbitraires pour générer des signatures.
Importation des clés
KeyMint est compatible avec l'importation des éléments suivants :
- Paires de clés asymétriques au format PKCS#8 encodé en DER (sans chiffrement basé sur un mot de passe)
- Clés symétriques sous forme d'octets bruts
Pour s'assurer que les clés importées peuvent être distinguées des clés générées de manière sécurisée, Tag::ORIGIN est inclus dans la liste d'autorisation de clés appropriée. Par exemple, si une clé a été générée dans du matériel sécurisé, Tag::ORIGIN avec la valeur KeyOrigin::GENERATED se trouve dans la liste hw_enforced des caractéristiques de la clé, tandis qu'une clé importée dans du matériel sécurisé a la valeur KeyOrigin::IMPORTED.
Authentification des utilisateurs
Les implémentations KeyMint sécurisées n'implémentent pas l'authentification des utilisateurs, mais dépendent d'autres applications de confiance qui le font. Pour l'interface implémentée par ces applications, consultez la page Gatekeeper.
Les exigences d'authentification des utilisateurs sont spécifiées via deux ensembles de balises. Le premier ensemble indique les méthodes d'authentification qui permettent d'utiliser la clé :
Tag::USER_SECURE_IDpossède une valeur numérique de 64 bits spécifiant l'ID utilisateur sécurisé fourni dans un jeton d'authentification sécurisé pour déverrouiller l'utilisation de la clé. Si elle est répétée, la clé peut être utilisée si l'une des valeurs est fournie dans un jeton d'authentification sécurisé.
Le second ensemble indique si l'utilisateur doit être authentifié et, le cas échéant, à quel moment.
Si aucune de ces balises n'est présente, mais que Tag::USER_SECURE_ID l'est, l'authentification est requise pour chaque utilisation de la clé.
Tag::NO_AUTHENTICATION_REQUIREDindique qu'aucune authentification de l'utilisateur n'est requise, bien que l'accès à la clé soit toujours limité à l'application propriétaire (et à toutes les applications auxquelles elle accorde l'accès).Tag::AUTH_TIMEOUTest une valeur numérique spécifiant, en secondes, l'ancienneté de l'authentification de l'utilisateur pour autoriser l'utilisation de la clé. Les délais avant expiration ne sont pas conservés après un redémarrage. Après un redémarrage, toutes les authentifications sont invalidées. Le délai avant expiration peut être défini sur une valeur élevée pour indiquer que l'authentification est requise une fois par démarrage (2^32 secondes correspondent à environ 136 ans ; les appareils Android sont probablement redémarrés plus souvent que cela).
Exiger un appareil déverrouillé
Les clés avec Tag::UNLOCKED_DEVICE_REQUIRED ne sont utilisables que lorsque l'appareil est déverrouillé. Pour en savoir plus sur la sémantique, consultez
KeyProtection.Builder#setUnlockedDeviceRequired(boolean).
UNLOCKED_DEVICE_REQUIRED est appliqué par Keystore, et non par KeyMint. Toutefois, sous Android 12 et versions ultérieures, Keystore protège les clés UNLOCKED_DEVICE_REQUIRED de manière cryptographique lorsque l'appareil est verrouillé afin de s'assurer que, dans la plupart des cas, elles ne peuvent pas être utilisées même si Keystore est compromis lorsque l'appareil est verrouillé.
Sauf mention explicite de l'utilisation de KeyMint, toutes les opérations de cryptographie et de génération de nombres aléatoires décrites dans cette section utilisent BoringSSL. Tous les secrets sont mis à zéro dès qu'ils ne sont plus nécessaires.
Super-clés UnlockedDeviceRequired
Pour protéger les clés UNLOCKED_DEVICE_REQUIRED de manière cryptographique, Keystore les "superchiffre" avant de les stocker dans sa base de données. Dans la mesure du possible, il protège les clés de superchiffrement (superclés) lorsque l'appareil est verrouillé, de sorte qu'elles ne puissent être récupérées qu'en déverrouillant l'appareil. (Le terme "superchiffrement" est utilisé, car cette couche de chiffrement est appliquée en plus de la couche de chiffrement que KeyMint applique déjà à toutes les clés.)
Chaque utilisateur (y compris les profils) dispose de deux super-clés associées à UNLOCKED_DEVICE_REQUIRED :
- Super-clé symétrique UnlockedDeviceRequired. Il s'agit d'une clé AES-256-GCM. Il chiffre les clés
UNLOCKED_DEVICE_REQUIREDqui sont importées, générées ou utilisées lorsque l'appareil est déverrouillé pour l'utilisateur. - Super-clé asymétrique UnlockedDeviceRequired. Il s'agit d'une paire de clés ECDH P-521. Il chiffre les clés
UNLOCKED_DEVICE_REQUIREDimportées ou générées lorsque l'appareil est verrouillé pour l'utilisateur. Pour en savoir plus, consultez Stocker des clés lorsque l'appareil est verrouillé.
Générer et protéger les super-clés
Lorsqu'un utilisateur est créé, Keystore génère les super-clés UnlockedDeviceRequired de l'utilisateur et les stocke dans sa base de données, chiffrées (indirectement) par le mot de passe synthétique de l'utilisateur :
- Le serveur système dérive le mot de passe Keystore de l'utilisateur à partir du mot de passe synthétique de l'utilisateur à l'aide d'une fonction de dérivation de clé SP800-108.
- Le serveur système transmet le mot de passe Keystore de l'utilisateur à Keystore.
- Keystore génère les super-clés de l'utilisateur.
- Pour chacune des super-clés de l'utilisateur :
- Keystore génère un salage aléatoire.
- Keystore dérive une clé AES-256-GCM à partir du mot de passe Keystore de l'utilisateur et du salage à l'aide de HKDF-SHA256.
- Keystore chiffre la partie secrète de la super-clé à l'aide de cette clé AES-256-GCM.
- Keystore stocke la super-clé chiffrée et son salage dans sa base de données. S'il s'agit d'une clé asymétrique, la moitié publique de la clé est également stockée non chiffrée.
Cette procédure permet de déchiffrer ces super-clés lorsque le mot de passe synthétique de l'utilisateur est connu, par exemple lorsque le code, le schéma ou le mot de passe correct de l'utilisateur est saisi.
Keystore met également en cache ces super-clés en mémoire, ce qui lui permet d'opérer sur les clés UNLOCKED_DEVICE_REQUIRED. Toutefois, il tente de mettre en cache les parties secrètes de ces clés uniquement lorsque l'appareil est déverrouillé pour l'utilisateur. Lorsque l'appareil est verrouillé pour l'utilisateur, Keystore remplace par des zéros sa copie mise en cache des parties secrètes de ces super-clés, si possible. Plus précisément, lorsque l'appareil est verrouillé pour l'utilisateur, Keystore sélectionne et applique l'un des trois niveaux de protection pour les super-clés UnlockedDeviceRequired de l'utilisateur :
- Si l'utilisateur n'a activé que le code, le schéma ou le mot de passe, Keystore remet à zéro les parties secrètes de ses super-clés mises en cache. Ainsi, les super-clés ne peuvent être récupérées que via la copie chiffrée dans la base de données, qui ne peut être déchiffrée qu'avec un code, un schéma ou un mot de passe équivalent.
- Si l'utilisateur n'a activé que les données biométriques de classe 3 ("fortes") et un code, un schéma ou un mot de passe, Keystore s'assure que les super-clés peuvent être récupérées par l'une des données biométriques de classe 3 enregistrées de l'utilisateur (généralement l'empreinte digitale), comme alternative au code, au schéma ou au mot de passe équivalent. Pour ce faire, il génère une nouvelle clé AES-256-GCM, chiffre les parties secrètes des super-clés avec celle-ci, importe la clé AES-256-GCM dans KeyMint en tant que clé liée à la biométrie qui nécessite une authentification biométrique réussie au cours des 15 dernières secondes, et remplace par des zéros les copies en texte brut de toutes ces clés.
- Si l'utilisateur a activé un agent de confiance de déverrouillage actif, une authentification biométrique de classe 1 ("pratique") ou une authentification biométrique de classe 2 ("faible"), Keystore conserve les super-clés en texte brut dans le cache. Dans ce cas, la sécurité cryptographique des clés
UNLOCKED_DEVICE_REQUIREDn'est pas assurée. Les utilisateurs peuvent éviter cette solution de secours moins sécurisée en n'activant pas ces méthodes de déverrouillage. Les méthodes de déverrouillage les plus courantes qui entrent dans ces catégories sont le déverrouillage par reconnaissance faciale sur de nombreux appareils et le déverrouillage avec une montre connectée associée.
Lorsque l'appareil est déverrouillé pour l'utilisateur, Keystore récupère les super-clés UnlockedDeviceRequired de l'utilisateur, si possible. Pour un déverrouillage équivalent par code, schéma ou mot de passe, il déchiffre la copie de ces clés stockée dans la base de données. Sinon, il vérifie s'il a enregistré une copie de ces clés chiffrées avec une clé liée à la biométrie et, le cas échéant, tente de la déchiffrer. Cette opération ne réussit que si l'utilisateur s'est authentifié avec succès à l'aide d'une méthode biométrique de classe 3 au cours des 15 dernières secondes, appliquée par KeyMint (et non Keystore).
Stocker des clés lorsque l'appareil est verrouillé
Keystore permet aux utilisateurs d'importer et de générer des clés UNLOCKED_DEVICE_REQUIRED lorsque l'appareil est verrouillé. Il utilise un schéma de chiffrement hybride pour s'assurer qu'elles ne peuvent être déchiffrées que lorsque l'appareil est déverrouillé ultérieurement :
- Chiffrement (importation ou génération d'une clé
UNLOCKED_DEVICE_REQUIREDlorsque l'appareil est verrouillé) :- Keystore génère une nouvelle paire de clés ECDH P-521 éphémère.
- Keystore génère un secret partagé en effectuant un accord de clé ECDH entre la clé privée de cette paire de clés éphémère et la moitié publique de la super-clé asymétrique UnlockedDeviceRequired.
- Keystore génère un salage aléatoire.
- Keystore dérive une clé AES-256-GCM à partir du secret partagé et du sel à l'aide de HKDF-SHA256.
- Keystore chiffre la clé
UNLOCKED_DEVICE_REQUIREDà l'aide de cette clé AES-256-GCM. - Keystore stocke la clé
UNLOCKED_DEVICE_REQUIREDchiffrée, le salage et la moitié publique de la paire de clés éphémère dans sa base de données.
- Déchiffrement (à l'aide de la clé
UNLOCKED_DEVICE_REQUIREDcréée lorsque l'appareil est déverrouillé) :- Keystore charge la clé
UNLOCKED_DEVICE_REQUIREDchiffrée, le salage et la moitié publique de la paire de clés éphémère à partir de sa base de données. - Keystore génère un secret partagé en effectuant un accord de clé ECDH entre la moitié publique de la paire de clés éphémère et la moitié privée de la super-clé asymétrique UnlockedDeviceRequired. La clé privée est disponible, car l'appareil est déverrouillé.
- Keystore dérive une clé AES-256-GCM à partir de la clé secrète partagée et du salage à l'aide de HKDF-SHA256. Cette clé AES-256-GCM est identique à celle qui a été dérivée lors du chiffrement.
- Keystore déchiffre la clé
UNLOCKED_DEVICE_REQUIREDà l'aide de la clé AES-256-GCM. - Keystore rechiffre la clé
UNLOCKED_DEVICE_REQUIREDà l'aide de la super-clé symétrique UnlockedDeviceRequired. Cela n'affecte pas les propriétés de sécurité de la clé, mais permet d'y accéder plus rapidement par la suite.
- Keystore charge la clé
Cette fonctionnalité permet aux applications de stocker des données lorsque l'appareil est verrouillé, de sorte qu'elles ne puissent être déchiffrées que lorsque l'appareil est déverrouillé. Pour ce faire, les applications doivent suivre ces étapes :
- Générez une clé AES-256-GCM en dehors de Keystore.
- Chiffrez les données à l'aide de la clé AES‑256‑GCM.
- Importez la clé AES-256-GCM dans Keystore avec l'ensemble de protection de clé
setUnlockedDeviceRequired(true). - Mettre à zéro la copie d'origine de la clé.
Pour déchiffrer les données lorsque l'appareil est déverrouillé, utilisez la clé importée dans Keystore.
Liaison de clients
La liaison client, c'est-à-dire l'association d'une clé à une application cliente particulière, s'effectue via un ID client facultatif et des données client facultatives (Tag::APPLICATION_ID et Tag::APPLICATION_DATA, respectivement). Keystore traite ces valeurs comme des blobs opaques, en s'assurant uniquement que les mêmes blobs présentés lors de la génération/l'importation de la clé sont présentés pour chaque utilisation et sont identiques octet par octet. Les données de liaison du client ne sont pas renvoyées par KeyMint. L'appelant doit la connaître pour pouvoir utiliser la clé.
Cette fonctionnalité n'est pas exposée aux applications.
Expiration
Keystore permet de limiter l'utilisation des clés par date. Le début de la validité et l'expiration de la clé peuvent être associés à une clé. Keystore refuse d'effectuer des opérations de clé si la date/l'heure actuelle se situe en dehors de la plage valide. La plage de validité de la clé est spécifiée avec les balises Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME et Tag::USAGE_EXPIRE_DATETIME. La distinction entre "création" et "utilisation" dépend de l'utilisation de la clé pour "créer" un texte chiffré/une signature/etc. ou pour "utiliser" un texte chiffré/une signature/etc. existant. Notez que cette distinction n'est pas exposée aux applications.
Les balises Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME et Tag::USAGE_EXPIRE_DATETIME sont facultatives. Si les tags sont absents, on suppose que la clé en question peut toujours être utilisée pour déchiffrer/valider les messages.
Étant donné que l'heure réelle est fournie par le monde non sécurisé, les tags liés à l'expiration figurent dans la liste des tags appliqués par logiciel.
Liaison de la racine de confiance
Keystore nécessite que les clés soient liées à une racine de confiance, qui est une chaîne de bits fournie au matériel sécurisé KeyMint au démarrage, de préférence par le bootloader. Cette chaîne de bits est liée de manière cryptographique à chaque clé gérée par KeyMint.
La racine de confiance se compose du hachage de la clé publique utilisée pour vérifier la signature sur l'image de démarrage et l'état de verrouillage de l'appareil. Si la clé publique est modifiée pour permettre l'utilisation d'une autre image système ou si l'état de verrouillage est modifié, aucune des clés protégées par KeyMint créées par le système précédent n'est utilisable, sauf si la racine de confiance précédente est restaurée et qu'un système signé par cette clé est démarré. L'objectif est d'augmenter la valeur des contrôles d'accès aux clés appliqués par logiciel en empêchant un système d'exploitation installé par un pirate d'utiliser les clés KeyMint.
Réamorçage du générateur de nombres aléatoires
Étant donné que le matériel sécurisé génère des nombres aléatoires pour le matériel de clé et les vecteurs d'initialisation (IV), et que les générateurs de nombres aléatoires matériels ne sont pas toujours entièrement fiables, la HAL KeyMint fournit une interface permettant à Keystore de fournir une entropie supplémentaire, qui est mélangée aux nombres aléatoires générés.
Utilisez un générateur de nombres aléatoires matériel comme source de départ principale. Les données de départ fournies par l'API externe ne peuvent pas être la seule source de hasard utilisée pour la génération de nombres. De plus, l'opération de mélange utilisée doit garantir que la sortie aléatoire est imprévisible si l'une des sources de départ est imprévisible.