Fonctionnalités

Cette page contient des informations sur les fonctionnalités cryptographiques d'Android Keystore, telles que fournies par l'implémentation sous-jacente de KeyMint (ou Keymaster).

Primitives cryptographiques

Keystore fournit les catégories d'opérations suivantes :

  • Création de clés, ce qui génère un matériel de clé privée ou secrète accessible uniquement à l'environnement sécurisé. Les clients peuvent créer des clés de différentes manières :
    • Génération de clés
    • Importation de matériel de clé non chiffré
    • Importation de matériel de clé chiffré
  • Attestation de clé : la création de clés asymétriques génère un certificat contenant la partie clé publique de la paire de clés. Ce certificat contient également des informations sur les métadonnées de la clé et l'état de l'appareil, toutes signées par une chaîne de clés remontant à une racine approuvée.
  • 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)

Notez que Keystore et KeyMint ne gèrent pas les opérations de clé publique pour les clés asymétriques.

Les éléments de protocole, tels que l'objectif, le mode et le remplissage, ainsi que les contraintes de contrôle des accès, sont spécifiés lorsque les clés sont générées ou importées et sont définitivement associées à la clé, ce qui garantit qu'elle ne peut pas être utilisée d'une autre manière.

Les primitives et les modes qui doivent être compatibles avec l'implémentation de KeyMint sont décrits dans la spécification de l'interface HAL IKeyMintDevice.

L'implémentation sous-jacente de KeyMint doit effectuer une génération de nombres aléatoires afin de prendre en charge la génération de clés et la création de remplissage aléatoire ou de vecteurs d'initialisation (IV). Pour ce faire, le système Android fournit régulièrement de l'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 ne fournissent pas une sécurité optimale 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 essentiel que Keystore applique les contrôles d'accès.

Les contrôles d'accès sont définis comme une "liste d'autorisation" de paires balise/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 une balise est spécifiée dans l'interface HAL KeyMint (anciennement Keymaster).

Les valeurs de balise compatibles sont définies dans le fichier Tag.aidl. Chacune d'elles est associée à un TagType qui indique le type de la valeur associée (par exemple, entier ou octets) et si elle peut être répétée pour spécifier plusieurs valeurs compatibles.

Lorsque KeyMint crée une clé, l'appelant spécifie une liste d'autorisation pour la clé. Cette liste est modifiée par Keystore et KeyMint pour ajouter des contraintes supplémentaires, et l'implémentation sous-jacente de KeyMint encode la liste d'autorisation finale dans le keyblob renvoyé. La liste d'autorisation encodée est liée de manière cryptographique au keyblob, de sorte que toute tentative de modification de la liste d'autorisation (y compris l'ordre) génère un keyblob non valide qui ne peut pas être utilisé pour les opérations cryptographiques.

Application par matériel ou par logiciel

Toutes les implémentations de matériel sécurisé ne contiennent pas les mêmes fonctionnalités. Pour prendre en charge différentes approches, KeyMint distingue l'application sécurisée et non sécurisée du contrôle des accès, ou l'application matérielle et logicielle, respectivement.

Cela est exposé dans l'API KeyMint avec le champ securityLevel de 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 concernant 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 un 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 auraient SecurityLevel::KEYSTORE.

Pour en savoir plus sur la détermination si les clés et leurs autorisations sont prises en charge par le matériel, consultez la section Attestation de clé.

Autorisations de création de messages cryptographiques

Les balises suivantes sont utilisées pour définir les caractéristiques cryptographiques des opérations à l'aide de la clé associée :

  • Tag::ALGORITHM
  • Tag::KEY_SIZE
  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::CALLER_NONCE
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Les balises suivantes sont répétables, ce qui signifie que plusieurs valeurs peuvent être associées à une seule clé :

  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::DIGEST
  • Tag::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 la balise Tag::PURPOSE, qui définit la façon 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 qui peut convaincre le système de déchiffrer des données arbitraires de générer des signatures.

Importation des clés

KeyMint permet d'importer les éléments suivants :

  • Paires de clés asymétriques au format PKCS#8 encodé 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é 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 est répertorié 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 de l'utilisateur

Les implémentations KeyMint sécurisées n'implémentent pas l'authentification utilisateur, mais dépendent d'autres applications approuvées qui le font. Pour connaître 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 autorisent l'utilisation de la clé :

  • Tag::USER_SECURE_ID possè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é. En cas de répétition, la clé peut être utilisée si l'une des valeurs est fournie dans un jeton d'authentification sécurisé.

Le deuxième ensemble indique si l'utilisateur doit être authentifié et quand. Si aucune de ces balises n'est présente, mais que Tag::USER_SECURE_ID l'est, une authentification est requise pour chaque utilisation de la clé.

  • Tag::NO_AUTHENTICATION_REQUIRED indique qu'aucune authentification 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_TIMEOUT est 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 appliqués aux redémarrages. 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 correspond à 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 peuvent être utilisées 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 de manière cryptographique les clés UNLOCKED_DEVICE_REQUIRED lorsque l'appareil est verrouillé pour 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é.

Pour ce faire, Keystore "superchiffre" toutes les clés UNLOCKED_DEVICE_REQUIRED avant de les stocker dans sa base de données. Lorsque cela est possible, il protège les clés de superchiffrement (super clés) lorsque l'appareil est verrouillé de sorte qu'elles ne puissent être récupérées que par un déverrouillage réussi de 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) possè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_REQUIRED importées ou généré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_REQUIRED importées ou générées lorsque l'appareil est verrouillé pour l'utilisateur. Les clés chiffrées avec cette clé asymétrique sont chiffrées à nouveau avec la clé symétrique lors de la première utilisation (ce qui ne peut se produire que lorsque l'appareil est déverrouillé).

Keystore génère ces super clés au moment de la création de l'utilisateur et les stocke dans sa base de données, chiffrées par le mot de passe synthétique de l'utilisateur. Ils peuvent ainsi être récupérés à l'aide d'un code, d'un schéma ou d'un mot de passe équivalent.

Keystore met également en cache ces super clés en mémoire, ce qui lui permet de fonctionner sur les clés UNLOCKED_DEVICE_REQUIRED. Toutefois, il ne tente de mettre en cache les parties secrètes de ces clés que lorsque l'appareil est déverrouillé pour l'utilisateur. Lorsque l'appareil est verrouillé pour l'utilisateur, Keystore efface 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 met à zéro les parties secrètes de ses super clés mises en cache. Les super-clés ne peuvent donc être récupérées que via la copie chiffrée de la base de données, qui ne peut être déchiffrée que par un code, un schéma ou un équivalent de mot de passe.
  • Si l'utilisateur ne dispose que de données biométriques de classe 3 ("fortes") et que le code, le schéma ou le mot de passe sont activés, Keystore s'arrange pour que les super clés soient récupérables par l'une des données biométriques de classe 3 enregistrées par l'utilisateur (généralement une empreinte digitale), comme alternative au code, au schéma ou au mot de passe. Pour ce faire, il génère une nouvelle clé AES-256-GCM, chiffre avec elle les parties secrètes des super-clés, importe la clé AES-256-GCM dans KeyMint en tant que clé liée à la biométrie qui nécessite que l'authentification biométrique ait réussi au cours des 15 dernières secondes, et met à zéro les copies de texte brut de toutes ces clés.
  • Si l'utilisateur dispose d'une empreinte biométrique de classe 1 ("pratique"), d'une empreinte biométrique de classe 2 ("faible") ou d'un agent de confiance de déverrouillage actif activé, Keystore conserve les super clés en cache en texte brut. Dans ce cas, la sécurité cryptographique pour les clés UNLOCKED_DEVICE_REQUIRED n'est pas fournie. Les utilisateurs peuvent éviter ce remplacement moins sécurisé en ne les activant pas. 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 le 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 aux données biométriques et, le cas échéant, tente de les déchiffrer. Cette opération ne fonctionne que si l'utilisateur s'est authentifié avec une biométrie de classe 3 au cours des 15 dernières secondes, appliquée par KeyMint (et non par Keystore).

Liaison client

L'association d'une clé à une application cliente spécifique, appelée liaison client, 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/importation de clés sont présentés pour chaque utilisation et sont identiques octet par octet. Les données de liaison client ne sont pas renvoyées par KeyMint. L'appelant doit le connaître pour pouvoir utiliser la clé.

Cette fonctionnalité n'est pas exposée aux applications.

Expiration

Le keystore permet de limiter l'utilisation des clés par date. La date de début de validité et l'expiration de la clé peuvent être associées à une clé, et Keystore refuse d'effectuer des opérations de clé si la date/heure actuelle est 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 nouveau texte chiffré/signature/etc. ou pour "utiliser" un texte chiffré/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 balises sont absentes, on suppose que la clé en question peut toujours être utilisée pour déchiffrer/valider les messages.

Étant donné que l'heure de référence est fournie par l'environnement non sécurisé, les balises liées à l'expiration figurent dans la liste appliquée par le logiciel.

Liaison de la racine de confiance

Keystore exige 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 consiste en le hachage de la clé publique utilisée pour valider 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 ne peut être utilisée, 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 le logiciel en rendant impossible l'utilisation des clés KeyMint par un système d'exploitation installé par un pirate informatique.

Régénération de la valeur source 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, le 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 graine principale. Les données de départ fournies via 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 s'assurer que la sortie aléatoire est imprévisible si l'une des sources de graine est imprévisible.