Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Caractéristiques

Cette page contient des informations sur les fonctionnalités cryptographiques de Keystore sous Android 6.0 et supérieur.

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 de wrapping de clé)
  • Importation de clés symétriques brutes (pas de wrapping de clé)
  • Cryptage et décryptage asymétriques avec les modes de remplissage appropriés
  • Signature et vérification asymétriques avec digestion et modes de remplissage appropriés
  • Cryptage et décryptage symétriques dans les modes appropriés, y compris un mode AEAD
  • Génération et vérification de codes d'authentification de messages symétriques

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

En plus de la liste ci-dessus, il existe un autre service fourni par les implémentations de Keymaster, mais qui n'est pas exposé en tant qu'API: la génération de nombres aléatoires. Ceci est utilisé en interne pour la génération de clés, de vecteurs d'initialisation (IV), de remplissage aléatoire et d'autres éléments de protocoles sécurisés qui nécessitent un caractère aléatoire.

Primitives nécessaires

Toutes les implémentations de Keymaster fournissent:

  • RSA
    • Prise en charge des clés 2048, 3072 et 4096 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ésumé pour la signature RSA:
      • SHA-256
    • Modes de remplissage pour le cryptage / décryptage RSA:
      • Non rembourré
      • RSAES-OAEP ( PaddingMode::RSA_OAEP )
      • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
  • ECDSA
    • La prise en charge des clés 224, 256, 384 et 521 bits est prise en charge, à l'aide des courbes NIST P-224, P-256, P-384 et P-521, respectivement
    • Modes de résumé pour ECDSA:
      • Aucun résumé (obsolète, sera supprimé à l'avenir)
      • SHA-256
  • AES
    • Les clés 128 et 256 bits sont prises en charge
    • CBC , CTR, ECB et GCM. L'implémentation GCM ne permet pas l'utilisation d'étiquettes inférieures à 96 bits ou de longueurs nonce autres que 96 bits.
    • Modes de PaddingMode::NONE et PaddingMode::PKCS7 est pris en charge pour les modes CBC et ECB. Sans remplissage, le cryptage 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é d'au moins 32 octets.

SHA1 et les autres membres de la famille SHA2 (SHA-224, SHA384 et SHA512) sont fortement recommandés pour les implémentations Keymaster. Keystore les fournit dans le logiciel si l'implémentation matérielle de Keymaster 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 d'accès par clé

Les clés matérielles qui ne peuvent jamais être extraites de l'appareil n'offrent pas beaucoup de sécurité si un attaquant 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 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 balises 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 répétition d'une balise est spécifiée dans la documentation de la balise . Lorsqu'une clé est créée, l'appelant spécifie une liste d'autorisation. L'implémentation de Keymaster sous-jacente à Keystore modifie la liste pour spécifier des informations supplémentaires, telles que si la clé a une protection anti-retour, et renvoie une liste d'autorisation "finale", codée dans l'objet blob de clé retourné. Toute tentative d'utilisation de la clé pour une opération cryptographique échoue si la liste d'autorisation finale est modifiée.

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

Keymaster 3 a changé le préfixe KM_TAG en Tag:: .

Les types possibles incluent:

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

UINT : entiers non signés 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 64 bits. Exemple: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : Identique à ULONG , sauf que l'étiquette 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 : Vrai ou faux. Une balise de type BOOL est supposée être "false" si la balise n'est pas présente et "true" si elle est présente. Exemple: TAG::ROLLBACK_RESISTANT

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

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

Application matérielle ou logicielle

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

Toutes les implémentations:

  • Appliquez la correspondance exacte (et non l'application) de toutes les autorisations. Les listes d'autorisations dans les objets blob de clé correspondent exactement aux autorisations renvoyées lors de la génération de clé, y compris le classement. Toute incompatibilité entraîne un diagnostic d'erreur.
  • Déclarez les autorisations dont les valeurs sémantiques sont appliquées.

Le mécanisme de l'API pour déclarer les 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 responsable de placer les valeurs appropriées dans chacun, en fonction de ce qu'il peut appliquer.

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

Par exemple, envisagez une implémentation basée sur TrustZone qui ne prend pas en charge l'expiration de clé. Une clé avec une date d'expiration peut encore être créée. La liste d'autorisation de cette clé comprendra la balise TAG::ORIGINATION_EXPIRE_DATETIME avec la date d'expiration. Une demande à Keystore pour les caractéristiques clés trouvera cette balise dans la liste sw_enforced et le matériel sécurisé n'appliquera pas l'exigence d'expiration. Cependant, les tentatives d'utilisation de la clé après l'expiration seront rejetées par Keystore.

Si le périphérique est ensuite mis à niveau avec un matériel sécurisé hw_enforced charge l'expiration, une demande de caractéristiques de clé trouvera TAG::ORIGINATION_EXPIRE_DATETIME hw_enforced dans la liste hw_enforced et les tentatives d'utilisation de la clé après l'expiration échoueront même si le magasin de clés est en quelque sorte subverti ou contourné. .

Pour plus d'informations sur la manière de déterminer si les clés sont sauvegardées sur le matériel, consultez Attestation de clé .

Autorisations de construction de messages cryptographiques

Les balises suivantes permettent de 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 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 ont un ensemble d'objectifs associé, exprimé sous la forme d'une ou de plusieurs entrées d'autorisation avec la balise TAG::PURPOSE , qui définit comment elles peuvent être utilisées. Les objectifs sont:

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

Toute clé peut avoir n'importe quel sous-ensemble de ces objectifs. Notez que certaines combinaisons 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 attaquant qui peut convaincre le système de déchiffrer des données arbitraires pour générer des signatures.

Importer et exporter

Keymaster prend uniquement en charge l'exportation des clés publiques, au format X.509, et l'importation de:

  • Paires de clés publiques et privées au format PKCS # 8 codé DER, sans chiffrement basé sur un mot de passe
  • Clés symétriques sous forme d'octets bruts

Pour garantir que les clés importées peuvent être distinguées des clés générées en toute sécurité, 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 trouvera dans la liste hw_enforced des caractéristiques de la clé, tandis qu'une clé qui a été importée dans un matériel sécurisé aura la valeur KeyOrigin::IMPORTED .

Authentification d'utilisateur

Les implémentations Secure Keymaster n'implémentent pas l'authentification 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 via deux ensembles de balises. Le premier ensemble indique quel utilisateur peut utiliser la clé:

  • TAG::ALL_USERS indique que la clé est utilisable par tous les utilisateurs. S'il est 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 multi-utilisateurs), pas de l'UID de l'application, et il est appliqué uniquement par un logiciel non sécurisé. S'il est présent, TAG::ALL_USERS n'est pas présent.
  • TAG::USER_SECURE_ID a 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 deuxième ensemble indique si et quand l'utilisateur doit être authentifié. Si aucune de ces balises n'est présente, mais TAG::USER_SECURE_ID est, l'authentification est requise pour chaque utilisation de la clé.

  • NO_AUTHENTICATION_REQUIRED indique qu'aucune authentification utilisateur n'est requise, bien que la clé ne puisse toujours être utilisée que par les applications exécutées en tant qu'utilisateur (s) spécifié (s) par TAG::USER_ID .
  • TAG::AUTH_TIMEOUT est une valeur numérique spécifiant, en secondes, à quel point l'authentification de l'utilisateur doit être fraîche pour autoriser l'utilisation de la clé. Cela s'applique uniquement aux opérations de clé privée / secrète. Les opérations de clé publique ne nécessitent pas d'authentification. Les délais d'attente ne traversent pas les redémarrages; après un redémarrage, toutes les clés ne sont «jamais authentifiées». Le délai d'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 à ~ 136 ans; vraisemblablement, les appareils Android sont redémarrés plus souvent que cela).

Liaison client

La liaison client, l'association d'une clé avec une application client particulière, se fait via un ID client optionnel et des données client optionnelles ( TAG::APPLICATION_ID et TAG::APPLICATION_DATA , respectivement). Keystore traite ces valeurs comme des blobs opaques, garantissant uniquement que les mêmes blobs présentés lors de la génération / importation de clé 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 savoir pour pouvoir utiliser la touche.

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

Expiration

Keystore prend en charge la restriction de l'utilisation des clés par date. Le début de validité de la clé et les expirations de clé peuvent être associés à une clé et Keymaster 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 "origine" et "utilisation" est basée sur le fait que la clé est utilisée pour "générer" 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.

Le TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME et TAG::USAGE_EXPIRE_DATETIME balises sont facultatives. Si les balises sont absentes, on suppose que la clé en question peut toujours être utilisée pour déchiffrer / vérifier les messages.

Étant donné que l'heure de l'horloge murale est fournie par le monde non sécurisé, il est peu probable que les balises liées à l'expiration soient dans la liste appliquée par le matériel. L'application matérielle de l'expiration exigerait que le monde sécurisé obtienne d'une manière ou d'une autre du temps et des données fiables, par exemple via un protocole de réponse à un défi avec un serveur de temps distant de confiance.

Racine de la liaison 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é Keymaster lors du démarrage, de préférence par le chargeur de démarrage. 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 vérifier la signature sur l'image de démarrage et l'état de verrouillage du périphérique. Si la clé publique est modifiée pour autoriser l'utilisation d'une image système différente 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 n'est utilisable, sauf si la racine de confiance précédente est restaurée et un système qui est 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 attaquant d'utiliser les 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é. Ou il peut y avoir d'autres cas dans lesquels 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 Keymaster HAL 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 Keymaster en cours d'exécution n'est requise. Les balises associées à une clé peuvent être inspectées pour voir si une clé est autonome. À l'heure actuelle, seules deux valeurs sont définies:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

Rapidité

Lors de sa création, la vitesse d'utilisation maximale peut être spécifiée avec TAG::MIN_SECONDS_BETWEEN_OPS . Les implémentations de 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.

L'approche simple pour implémenter les limites de vitesse est un tableau des ID de clé et des horodatages de dernière utilisation. Cette table sera probablement de taille limitée, mais peut contenir au moins 16 entrées. Dans le cas où la table est pleine et qu'aucune entrée ne peut être mise à jour ou rejetée, les implémentations matérielles sécurisées «à sécurité intégrée», préférant refuser toutes les opérations de touches à vitesse limitée jusqu'à ce que l'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 contient au moins quatre clés et qui échoue également. Notez que les applications ne pourront 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éensemencement du générateur de nombres aléatoires

Parce que le matériel sécurisé génère des nombres aléatoires pour le matériel clé et les vecteurs d'initialisation (IV), et parce que les générateurs de nombres aléatoires matériels peuvent ne pas toujours être entièrement fiables, le Keymaster HAL fournit une interface pour permettre au client de fournir une entropie supplémentaire qui sera mélangée à l'aléatoire. numéros 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 via l'API externe ne peuvent pas être la seule source de caractère aléatoire utilisée pour la génération de nombres. En outre, l'opération de mélange utilisée doit garantir que la sortie aléatoire est imprévisible si l'une quelconque des sources d'amorçage est imprévisible.

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