Fonctionnalités

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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

Primitives cryptographiques

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

  • Génération de clé
  • Importation et exportation de clés asymétriques (pas d'enveloppement de clé)
  • Importation de clés symétriques brutes (pas d'enveloppement de clé)
  • Chiffrement et déchiffrement asymétriques avec modes de remplissage appropriés
  • Signature et vérification asymétriques avec des modes de digestion et de remplissage appropriés
  • Chiffrement et déchiffrement 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 rembourrage, 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 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 Digest pour la signature RSA :
      • SHA-256
    • Modes de remplissage pour le chiffrement/déchiffrement RSA :
      • Non rembourré
      • RSAES-OAEP ( PaddingMode::RSA_OAEP )
      • RSAES-PKCS1-v1_5 ( Mode de 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 :
      • Pas de résumé (obsolète, sera supprimé à l'avenir)
      • SHA-256
  • AES
    • Les clés 128 et 256 bits sont prises en charge
    • CBC , CTR, BCE et GCM. L'implémentation GCM n'autorise pas l'utilisation de balises inférieures à 96 bits ou de longueurs nonce autres que 96 bits.
    • Les modes PaddingMode::NONE et PaddingMode::PKCS7 sont pris en charge 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 fortement recommandés pour les implémentations Keymaster. Keystore les fournit dans le logiciel si l'implémentation matérielle 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 à la 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). Ainsi, il est crucial 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 balise/valeur. Les balises d'autorisation sont des entiers 32 bits et les valeurs sont de types variés. Certaines balises peuvent être répétées pour spécifier plusieurs valeurs. Si une balise peut être répétée 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 au Keystore modifie la liste pour spécifier des informations supplémentaires, telles que si la clé dispose d'une protection 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 toute opération cryptographique échoue si la liste d'autorisation finale est modifiée.

Pour Keymaster 2 et versions antérieures, l'ensemble de balises possibles est défini dans l'énumération keymaster_authorization_tag_t et est fixé de manière permanente (bien qu'il puisse être étendu). Les noms étaient précédés de KM_TAG . Les quatre premiers bits des ID de balise 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 des é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 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 : vrai ou faux. Un tag de type BOOL est supposé être "faux" si le tag n'est pas présent et "vrai" s'il est présent. Exemple : TAG::ROLLBACK_RESISTANT

BIGNUM : entiers de longueur arbitraire, exprimés sous la forme d'un 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 blobs de clés correspondent exactement aux autorisations renvoyées lors de la génération de clés, y compris la commande. Toute non-concordance provoque un diagnostic d'erreur.
  • Déclarez les autorisations dont les valeurs sémantiques sont imposées.

Le mécanisme d'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 chargé de placer les valeurs appropriées dans chacun, 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.

Par exemple, considérez une implémentation basée sur TrustZone qui ne prend pas en charge l'expiration de la clé. Une clé avec une date d'expiration peut encore être créée. La liste d'autorisation de cette clé inclura la balise TAG::ORIGINATION_EXPIRE_DATETIME avec la date d'expiration. Une demande à Keystore pour les caractéristiques de la clé 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 expiration seront rejetées par Keystore.

Si l'appareil est ensuite mis à niveau avec un matériel sécurisé prenant en charge l'expiration, une demande de caractéristiques de clé trouvera TAG::ORIGINATION_EXPIRE_DATETIME ORIGINATION_EXPIRE_DATETIME 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 d'une manière ou d'une autre subverti ou contourné. .

Pour plus d'informations sur la manière de déterminer si les clés sont basé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és, exprimés sous la forme d'une ou plusieurs entrées d'autorisation avec la balise TAG::PURPOSE , qui définit la manière dont elles peuvent être utilisées. Les finalités 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 de générer des signatures.

Importer et exporter

Keymaster prend uniquement en charge l'exportation de 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 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 se retrouvera dans la liste hw_enforced des caractéristiques de la clé, tandis qu'une clé qui a été importée dans du matériel sécurisé aura la valeur KeyOrigin::IMPORTED .

Authentification d'utilisateur

Les implémentations de Secure Keymaster n'implémentent pas l'authentification des utilisateurs, 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'ils sont présents, 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), et non de l'UID de l'application, et qu'il n'est appliqué que par des logiciels non sécurisés. 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é qui est 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 que TAG::USER_SECURE_ID est, l'authentification est requise pour chaque utilisation de la clé.

  • NO_AUTHENTICATION_REQUIRED indique qu'aucune authentification d'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, la fraîcheur de l'authentification de l'utilisateur 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'attente 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 vraisemblablement redémarrés plus souvent que cela).

Liaison client

La liaison client, l'association d'une clé à une application client particulière, se fait via un ID client facultatif et certaines données client facultatives ( TAG::APPLICATION_ID et TAG::APPLICATION_DATA , respectivement). Keystore traite ces valeurs comme des blobs opaques, s'assurant 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 connaître pour pouvoir utiliser la clé.

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é 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 ::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 « 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 TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME ::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/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 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 une heure et des données de confiance, par exemple via un protocole de réponse à défi avec un serveur de temps distant de confiance.

Racine de 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 cryptographiquement liée à chaque clé gérée par Keymaster.

La racine de confiance est constituée 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 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, à moins que la racine de confiance précédente ne soit restaurée et qu'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 rendant impossible l'utilisation des clés Keymaster par un système d'exploitation installé par un attaquant.

Clés autonomes

Certains matériels sécurisés Keymaster peuvent choisir de stocker le matériel de clé en interne et de renvoyer les poignées plutôt que le matériel de clé crypté. Ou il peut y avoir d'autres cas dans lesquels les clés ne peuvent pas être utilisées tant qu'un autre composant de 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 mettre en œuvre des limites de vélocité est un tableau d'ID de clé et d'horodatages de dernière utilisation. Cette table sera probablement de taille limitée, mais accueillera au moins 16 entrées. Dans le cas où la table est pleine et qu'aucune entrée ne peut être mise à jour ou supprimée, les implémentations matérielles sécurisées « fail safe », préférant refuser toutes les opérations de clé à 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 est également sécurisée. 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 dans le aléatoire. nombres 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 de semence 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, au matériel sécurisé.