Fonctionnalités

Cette page contient des informations sur les fonctionnalités cryptographiques de Keystore sous Android 6.0 ou version ultérieure.

Primitives cryptographiques

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

  • Génération de clés
  • Importation et exportation de clés asymétriques (pas d'encapsulation de clé)
  • Importation de clés symétriques brutes (sans encapsulation de clé)
  • Chiffrement et déchiffrement asymétriques avec des modes de remplissage appropriés
  • Signature et validation asymétriques avec hachage et modes de remplissage appropriés
  • Chiffrement et déchiffrement symétriques dans les modes appropriés, y compris un mode AEAD
  • Génération et validation de codes d'authentification de message symé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.

En plus de la liste ci-dessus, les implémentations Keymaster fournissent un autre service, mais 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 du hasard.

Primitives nécessaires

Toutes les implémentations Keymaster fournissent les éléments suivants:

  • 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 de récapitulatif pour la signature RSA :
      • SHA-256
    • Modes de remplissage pour le chiffrement/déchiffrement RSA :
      • Sans marge intérieure
      • 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 prises en charge, respectivement à l'aide des courbes NIST P-224, P-256, P-384 et P-521.
    • Modes de récapitulatif 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 de GCM n'autorise pas l'utilisation de tags de moins de 96 bits ni de nonces de longueur autre que 96 bits.
    • Les modes de remplissage PaddingMode::NONE et PaddingMode::PKCS7 sont compatibles avec 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 de bloc.
  • HMAC SHA-256, avec une taille de clé d'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 Keymaster. Le Keystore les fournit en logiciel si l'implémentation matérielle de Keymaster ne le fait 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 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). Lorsqu'une clé est créée, l'appelant spécifie une liste d'autorisation. L'implémentation Keymaster sous-jacente à Keystore modifie la liste pour spécifier des informations supplémentaires, par exemple si la clé dispose d'une protection de rollback, et renvoie une liste d'autorisations "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 versions antérieures, l'ensemble des balises possibles est défini dans l'énumération keymaster_authorization_tag_t et est définitivement fixé (mais il peut être étendu). Les noms étaient précédés du préfixe KM_TAG. Les quatre premiers bits des ID de balise sont utilisés pour indiquer le type.

Keymaster 3 a remplacé le préfixe KM_TAG par Tag::.

Les types possibles sont les suivants:

ENUM:de nombreuses valeurs de balises sont définies dans des énumérations. Par exemple, les valeurs possibles de TAG::PURPOSE sont définies dans l'énumération 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 contient probablement KeyPurpose::ENCRYPT et KeyPurpose::DECRYPT.

UINT:entiers non signés de 32 bits. Exemple : TAG::KEY_SIZE

UINT_REP:identique à UINT, sauf que la balise peut être répétée dans une liste d'autorisation. La répétition indique plusieurs valeurs autorisées.

ULONG:entiers non signés de 64 bits. Exemple : TAG::RSA_PUBLIC_EXPONENT

ULONG_REP:identique à ULONG, sauf que la balise peut être répétée dans une liste d'autorisation. La répétition indique plusieurs valeurs autorisées.

DATE:valeurs de date/heure, exprimées en millisecondes depuis le 1er janvier 1970. Exemple: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : "True" ou "False". Une balise de type BOOL est considérée comme "false" si elle n'est pas présente et comme "true" si elle l'est. Exemple: TAG::ROLLBACK_RESISTANT

BIGNUM:entiers de longueur arbitraire, exprimés sous forme de tableau d'octets dans l'ordre big-endian. Exemple : TAG::RSA_PUBLIC_EXPONENT

BYTES:séquence d'octets. Exemple : TAG::ROOT_OF_TRUST

Application par matériel ou par logiciel

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

Toutes les implémentations:

  • Exiger une correspondance exacte (et non une application) de toutes les autorisations. Les listes d'autorisations dans les blobs de clés correspondent exactement aux autorisations renvoyées lors de la génération de clés, y compris l'ordre. Tout écart entraîne un diagnostic d'erreur.
  • Déclarez les autorisations dont les valeurs sémantiques sont appliquées.

Le mécanisme d'API permettant de déclarer des autorisations appliquées par le matériel se trouve dans la structure keymaster_key_characteristics_t. Il divise la liste d'autorisation en deux sous-listes, hw_enforced et sw_enforced. Le matériel sécurisé est chargé de placer les valeurs appropriées dans chacune d'elles, en fonction de ce qu'il peut appliquer.

De plus, Keystore implémente l'application logicielle de toutes les autorisations, qu'elles soient appliquées par le matériel sécurisé ou non.

Prenons l'exemple d'une implémentation basée sur TrustZone qui n'est pas compatible avec l'expiration des clés. Une clé avec une date d'expiration peut toujours être créée. La liste d'autorisation de cette clé inclut la balise TAG::ORIGINATION_EXPIRE_DATETIME avec la date d'expiration. Une requête envoyée au keystore pour les caractéristiques de clé trouve cette balise dans la liste sw_enforced, et le matériel sécurisé n'applique pas l'exigence d'expiration. Toutefois, les tentatives d'utilisation de la clé après expiration sont rejetées par Keystore.

Si l'appareil est ensuite mis à niveau avec du matériel sécurisé compatible avec l'expiration, une requête de caractéristiques de clé trouve TAG::ORIGINATION_EXPIRE_DATETIME dans la liste hw_enforced et tente d'utiliser la clé après l'expiration, même si le keystore est subverti ou contourné.

Pour en savoir plus sur la détermination si les clés sont basées sur du 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 et TAG::DIGEST.

TAG::PADDING, TAG::DIGEST et PaddingMode::BLOCK_MODE sont répétables, ce qui signifie que plusieurs valeurs peuvent être associées à une seule clé, et que 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 les suivants:

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

N'importe quelle clé peut avoir un sous-ensemble de ces objectifs. Notez que certaines combinaisons 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.

Importer et exporter

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 publiques et privées au format PKCS#8 encodé DER, sans chiffrement par 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 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 Secure Keymaster n'implémentent pas l'authentification de l'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 l'utilisateur autorisé à utiliser la clé:

  • TAG::ALL_USERS indique que la clé peut être utilisée par tous les utilisateurs. Si présent, TAG::USER_ID et TAG::USER_SECURE_ID ne sont pas présents.
  • TAG::USER_ID a une valeur numérique spécifiant l'ID de l'utilisateur autorisé. Notez qu'il s'agit de l'ID utilisateur Android (pour les appareils multi-utilisateurs), et non de l'UID de l'application. Il n'est appliqué que par des logiciels non sécurisés. Si présent, TAG::ALL_USERS n'est pas présent.
  • 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é.

  • NO_AUTHENTICATION_REQUIRED indique qu'aucune authentification de l'utilisateur n'est requise, bien que la clé ne puisse toujours être utilisée que par les applications exécutées en tant qu'utilisateurs spécifiés par TAG::USER_ID.
  • 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é. Cela ne s'applique qu'aux opérations de clé privée/secrète. Les opérations de clé publique ne nécessitent pas d'authentification. Les délais avant expiration ne sont pas cumulés entre les redémarrages. Après un redémarrage, toutes les clés ne sont jamais authentifié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).

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 Keymaster. 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 peuvent ê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 Keymaster 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 mot de passe équivalent.
  • 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 Keymaster 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, 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 appartiennent à 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 à la biométrie et, le cas échéant, tente de la 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 Keymaster (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 Keymaster. L'appelant doit le connaître pour pouvoir utiliser la clé.

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

Validité

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 Keymaster refuse d'effectuer des opérations de clé si la date/heure actuelle ne se trouve pas dans la plage de validité. 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 "origine" 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é, il est peu probable que les balises liées à l'expiration figurent dans la liste appliquée par le matériel. L'application matérielle de l'expiration nécessiterait que le monde sécurisé obtienne d'une manière ou d'une autre des données et un temps fiables, par exemple via un protocole de défi-réponse avec un serveur de temps distant fiable.

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é Keymaster 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 Keymaster.

La racine de confiance se compose 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 Keymaster 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 empêchant un système d'exploitation installé par un pirate informatique d'utiliser des clés Keymaster.

Clés autonomes

Certains matériels sécurisés Keymaster peuvent choisir de stocker le matériel de clé en interne et de renvoyer des poignées plutôt que du matériel de clé chiffré. Il peut également y avoir d'autres cas où les clés ne peuvent pas être utilisées tant qu'un autre composant du système mondial non sécurisé ou sécurisé n'est pas disponible. Le HAL Keymaster permet à l'appelant de demander qu'une clé soit "autonome" via la balise TAG::STANDALONE, ce qui signifie qu'aucune autre ressource que le blob et le système Keymaster en cours d'exécution n'est requise. Vous pouvez inspecter les balises associées à 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 exposée aux applications.

Vélocité

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

La méthode simple d'implémenter des limites de vitesse consiste à utiliser une table d'ID de clé et de codes temporels de dernière utilisation. Cette table est de taille limitée, mais peut accueillir au moins 16 entrées. Si le tableau est plein et qu'aucune entrée ne peut être mise à jour ou supprimée, les implémentations matérielles sécurisées sont "fail-safe", c'est-à-dire qu'elles préfèrent refuser toutes les opérations de clé limitées en vitesse jusqu'à ce qu'une des entrées expire. 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 accueillir au moins quatre clés et qui est également à sécurité intégré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 exposée aux applications.

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 Keymaster 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 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.

Cette fonctionnalité n'est pas exposée aux applications, mais elle est utilisée par le framework, qui fournit régulièrement de l'entropie supplémentaire, récupérée à partir d'une instance Java SecureRandom, au matériel sécurisé.