Fonctionnalités

Cette page contient des informations sur les fonctionnalités de chiffrement d'Android Keystore, telles que 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, qui génère des clés privées ou secrètes accessibles uniquement à l'environnement sécurisé. Les clients peuvent créer des clés de différentes manières :
    • Génération de clés récentes
    • 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 également des informations sur les métadonnées de la clé et l'état de l'appareil (facultatif), le tout signé par une clé renvoyant à 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)

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. Ils sont liés de manière permanente à la clé, ce qui garantit qu'elle ne peut pas être utilisée d'une autre manière.

En plus de la liste ci-dessus, les implémentations KeyMint (anciennement Keymaster) fournissent un autre service qui n'est pas exposé en tant qu'API : la génération de nombres aléatoires. Il est utilisé en interne pour générer des clés, des vecteurs d'initialisation (IV), un remplissage aléatoire et d'autres éléments de protocoles sécurisés qui nécessitent de l'aléatoire.

Primitives nécessaires

Toutes les implémentations KeyMint fournissent :

  • RSA
    • Prise en charge des clés de 2 048, 3 072 et 4 096 bits
    • Prise en charge de l'exposant public F4 (2^16+1)
    • Modes de remplissage pour la signature RSA :
      • RSASSA-PSS (PaddingMode::RSA_PSS)
      • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
    • Modes Digest pour la signature RSA :
      • SHA-256
    • Modes de remplissage pour le chiffrement/déchiffrement RSA :
      • Sans rembourrage
      • RSAES-OAEP (PaddingMode::RSA_OAEP)
      • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
  • ECDSA
    • Les clés de 224, 256, 384 et 521 bits sont compatibles, en utilisant respectivement les courbes NIST P-224, P-256, P-384 et P-521.
    • Modes Digest pour ECDSA :
      • Aucun récapitulatif (obsolète, sera supprimé à l'avenir)
      • SHA-256
  • AES
    • Les clés de 128 et 256 bits sont acceptées.
    • CBC, CTR, ECB et GCM. L'implémentation GCM n'autorise pas l'utilisation de tags de moins de 96 bits ni de longueurs de nonce autres que 96 bits.
    • Les modes de remplissage PaddingMode::NONE et PaddingMode::PKCS7 sont acceptés pour les modes CBC et ECB. Sans remplissage, le chiffrement en mode CBC ou ECB échoue si l'entrée n'est pas un multiple de la taille du bloc.
  • HMAC SHA-256, avec n'importe quelle taille de clé jusqu'à au moins 32 octets.

SHA1 et les autres membres de la famille SHA2 (SHA-224, SHA384 et SHA512) sont vivement recommandés pour les implémentations KeyMint. Keystore les fournit dans le logiciel si l'implémentation KeyMint matérielle ne les fournit pas.

Certaines primitives sont également recommandées pour l'interopérabilité avec d'autres systèmes :

  • Tailles de clé plus petites pour RSA
  • Exposants publics arbitraires pour RSA

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 essentiel que Keystore applique des contrôles d'accès.

Les contrôles d'accès sont définis comme une "liste d'autorisation" de paires tag/valeur. Les tags d'autorisation sont des entiers de 32 bits et les valeurs sont de différents types. Certains tags peuvent être répétés pour spécifier plusieurs valeurs. La possibilité de répéter un tag est spécifiée dans l'interface KeyMint HAL. Lorsqu'une clé est créée, l'appelant spécifie une liste d'autorisation. L'implémentation KeyMint sous-jacente à Keystore modifie la liste pour spécifier des informations supplémentaires, par exemple si la clé est protégée contre la restauration, et renvoie une liste d'autorisation "finale", encodée dans le blob de clé renvoyé. Toute tentative d'utilisation de la clé pour une opération de chiffrement échoue si la liste d'autorisation finale est modifiée.

Pour Keymaster 2 et les versions antérieures, l'ensemble des tags possibles est défini dans l'énumération keymaster_authorization_tag_t et est définitivement fixe (bien qu'il puisse être étendu). Les noms étaient précédés du préfixe KM_TAG. Les quatre premiers bits des ID de tag sont utilisés pour indiquer le type.

Le responsable de la clé 3 a remplacé le préfixe KM_TAG par Tag::.

Voici quelques exemples de types possibles :

ENUM : les valeurs de nombreux tags sont définies dans des énumérations. Par exemple, les valeurs possibles de TAG::PURPOSE sont définies dans l'enum keymaster_purpose_t.

ENUM_REP : identique à ENUM, sauf que la balise peut être répétée dans une liste d'autorisation. La répétition indique plusieurs valeurs autorisées. Par exemple, une clé de chiffrement comporte probablement KeyPurpose::ENCRYPT et KeyPurpose::DECRYPT.

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. L'implémentation KeyMint sous-jacente 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. Toute tentative de modification de la liste d'autorisation (y compris de l'ordre) entraîne la création d'un keyblob non valide qui ne peut pas être utilisé pour les opérations cryptographiques.

Application des règles au niveau du matériel ou des logiciels

Toutes les implémentations matérielles sécurisées ne contiennent pas les mêmes fonctionnalités. Pour prendre en charge différentes approches, Keymaster fait la distinction entre l'application du contrôle d'accès au monde sécurisé et non sécurisé, ou l'application matérielle et logicielle, respectivement.

Cette valeur est exposée dans l'API KeyMint avec le champ securityLevel du type KeyCharacteristics. Le matériel sécurisé est chargé de placer les autorisations dans 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 accès à des informations fiables sur la date et l'heure. Par conséquent, les autorisations telles que Tag::ORIGINATION_EXPIRE_DATETIME sont appliquées par Keystore dans Android et auraient SecurityLevel::KEYSTORE.

Pour savoir si les clés et leurs autorisations sont soutenues par le matériel, consultez Attestation de clé.

Autorisations de construction de messages cryptographiques

Les tags suivants sont utilisés pour définir les caractéristiques cryptographiques des opérations utilisant la clé associée :

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

Les tags suivants sont répétables, ce qui signifie que plusieurs valeurs peuvent être associées à une même 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 plusieurs entrées d'autorisation avec le tag Tag::PURPOSE, qui définissent leur utilisation. Les finalités sont définies dans KeyPurpose.aidl.

Notez que certaines combinaisons de valeurs d'objectif créent des problèmes de sécurité. Par exemple, une clé RSA qui peut ê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 de clés

Keymaster n'accepte que l'exportation de clés publiques au format X.509 et l'importation des é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 un 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 un 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 de l'utilisateur, mais dépendent d'autres applications de confiance qui le font. Pour l'interface que ces applications implémentent, consultez la page Gatekeeper.

Les exigences d'authentification des utilisateurs sont spécifiées à l'aide de deux ensembles de tags. Le premier ensemble indique les méthodes d'authentification qui permettent d'utiliser la clé :

  • Tag::USER_SECURE_ID est une valeur numérique de 64 bits qui spécifie l'ID utilisateur sécurisé fourni dans un jeton d'authentification sécurisé pour déverrouiller l'utilisation de la clé. Si la clé est répétée, elle peut être utilisée si l'une des valeurs est fournie dans un jeton d'authentification sécurisé.

Le deuxième ensemble indique si et quand l'utilisateur doit être authentifié. Si aucun de ces tags n'est présent, 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 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_TIMEOUT est une valeur numérique qui indique, en secondes, la durée de validité de l'authentification de l'utilisateur nécessaire pour autoriser l'utilisation de la clé. Les délais d'inactivité ne sont pas conservés lors des redémarrages. Après un redémarrage, toutes les authentifications sont invalidées. Le délai d'inactivité peut être défini sur une valeur élevée pour indiquer que l'authentification est requise une fois par démarrage (2^32 secondes équivalent à environ 136 ans ; les appareils Android sont probablement redémarrés plus souvent).

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 détaillée, consultez KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED est appliqué par Keystore, et non par KeyMint. Toutefois, dans 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 (superclés) lorsque l'appareil est verrouillé de manière à ce qu'elles ne puissent être récupérées qu'en cas de 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.
  • Clé super 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 (qui ne peut avoir lieu que lorsque l'appareil est déverrouillé).

Keystore génère ces super clés lors 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 ces super-clés en cache dans la 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 met à zéro 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é qu'un code, un schéma ou un mot de passe, Keystore met à zéro les parties secrètes de ses super clés mises en cache. Cela signifie que 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 que par un code, un schéma ou un mot de passe équivalent.
  • Si l'utilisateur n'a activé que l'authentification biométrique de classe 3 ("forte") et un code, un schéma ou un mot de passe, Keystore fait en sorte que les super clés puissent être récupérées par l'une des données biométriques de classe 3 enregistrées par l'utilisateur (généralement une empreinte digitale), en tant qu'alternative à un code, un schéma ou un 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 met à zéro les copies en texte brut de toutes ces clés.
  • Si l'utilisateur a activé une authentification biométrique de classe 1 ("pratique") ou de classe 2 ("faible"), ou un agent de confiance de déverrouillage actif, Keystore conserve les super clés mises en cache en texte brut. Dans ce cas, la sécurité cryptographique n'est pas assurée pour les clés UNLOCKED_DEVICE_REQUIRED. Les utilisateurs peuvent éviter ce recours moins sécurisé en n'activant pas ces méthodes de déverrouillage. Les méthodes de déverrouillage les plus courantes qui appartiennent à ces catégories sont la 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 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é biométrique et, le cas échéant, tente de les déchiffrer. Cette opération ne fonctionne 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, comme l'exige KeyMint (et non Keystore).

Liaison de client

L'association d'une clé à une application cliente spécifique, appelée liaison client, s'effectue à l'aide d'un ID client facultatif et de 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 du client ne sont pas renvoyées par KeyMint. L'appelant doit le connaître pour pouvoir utiliser la clé.

Cette fonctionnalité n'est pas disponible pour les applications.

Expiration

Le Keystore permet de limiter l'utilisation des clés par date. Une date de début de validité et une date d'expiration peuvent être associées à une clé. Keymaster refuse d'effectuer des opérations sur la clé si la date/heure actuelles sont en dehors de la plage de validité. La plage de validité de la clé est spécifiée avec les tags Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME et Tag::USAGE_EXPIRE_DATETIME. La distinction entre "création" et "utilisation" repose sur le fait que la clé est utilisée pour "créer" un nouveau texte chiffré/une nouvelle 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 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 lors du 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 de la clé publique utilisée pour valider la signature sur l'image de démarrage et de 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'accroître 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 informatique d'utiliser les clés KeyMint.

Clés autonomes

Certains matériels sécurisés KeyMint peuvent choisir de stocker le matériel de clé en interne et de renvoyer des identifiants plutôt que du matériel de clé chiffré. Il peut également arriver que les clés ne puissent pas être utilisées tant qu'un autre composant système non sécurisé ou sécurisé n'est pas disponible. Le HAL KeyMint permet à l'appelant de demander qu'une clé soit "autonome" via la balise TAG::STANDALONE, ce qui signifie qu'aucune ressource autre que le blob et le système KeyMint en cours d'exécution n'est requise. Vous pouvez inspecter les tags associés à une clé pour déterminer si elle est autonome. Actuellement, seules deux valeurs sont définies :

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Cette fonctionnalité n'est pas disponible pour les applications.

Vélocité

Lors de sa création, la vélocité d'utilisation maximale peut être spécifiée avec TAG::MIN_SECONDS_BETWEEN_OPS. Les implémentations TrustZone refusent d'effectuer des opérations de chiffrement avec cette clé si une opération a été effectuée moins de TAG::MIN_SECONDS_BETWEEN_OPS secondes auparavant.

L'approche simple pour implémenter des limites de vitesse consiste à utiliser un tableau d'ID de clés et d'horodatages de dernière utilisation. Cette table est de taille limitée, mais peut contenir au moins 16 entrées. Si la table est pleine et qu'aucune entrée ne peut être mise à jour ni supprimée, les implémentations matérielles sécurisées "échouent de manière sécurisée", en préférant refuser toutes les opérations de clé à vitesse limitée jusqu'à l'expiration de l'une des entrées. Il est acceptable que toutes les entrées expirent au redémarrage.

Les clés peuvent également être limitées à n utilisations par démarrage avec TAG::MAX_USES_PER_BOOT. Cela nécessite également une table de suivi, qui peut contenir au moins quatre clés et qui est également sécurisée. Notez que les applications ne peuvent pas créer de clés limitées par démarrage. Cette fonctionnalité n'est pas exposée via Keystore et est réservée aux opérations système.

Cette fonctionnalité n'est pas disponible pour les applications.

Réinitialisation 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 (VI), 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 au client 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 principale de seed. Les données de départ fournies par l'API externe ne peuvent pas être la seule source d'aléatoire utilisée pour la génération de nombres. De plus, l'opération de mixage utilisée doit garantir que la sortie aléatoire est imprévisible si l'une des sources de départ est imprévisible.