Cette page a été traduite par l'API Cloud Translation.

Fonctionnalités

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

Primitives cryptographiques

Keystore propose les catégories d’opérations suivantes :

Génération de clé
Importation et exportation de clés asymétriques (pas d'habillage de clé)
Importation de clés symétriques brutes (pas d'habillage de clé)
Cryptage et déchiffrement asymétriques avec modes de remplissage appropriés
Signature et vérification asymétriques avec modes de digestion et de remplissage appropriés
Cryptage et déchiffrement symétriques dans des modes appropriés, dont un mode AEAD
Génération et vérification de codes d'authentification de messages symétriques

Les éléments du 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 de manière permanente à 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 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 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 cryptage/déchiffrement 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 de 224, 256, 384 et 521 bits est prise en charge, en utilisant respectivement les courbes NIST P-224, P-256, P-384 et P-521.
- 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, BCE et GCM. L'implémentation GCM ne permet pas l'utilisation de balises inférieures à 96 bits ou de longueurs occasionnelles autres que 96 bits.
- Modes de remplissage 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 sous forme logicielle 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é (même si elles sont plus sécurisées que les clés qui peuvent être exfiltrées). Il est donc crucial que Keystore applique des contrôles d'accès.

Les contrôles d'accès sont définis comme une « liste d'autorisations » de paires balise/valeur. Les balises d'autorisation sont des entiers de 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 la documentation de la balise . Lorsqu'une clé est créée, l'appelant spécifie une liste d'autorisations. L'implémentation Keymaster sous-jacente à 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'autorisations « finale », codée dans le blob de clé renvoyé. 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 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éfixés par 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 : De nombreuses valeurs de 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'autorisations. 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'autorisations. La répétition indique plusieurs valeurs autorisées.

DATE : valeurs 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 « fausse » si la balise n’est pas présente et « vraie » si elle est présente. 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 : Une séquence d'octets. Exemple : TAG::ROOT_OF_TRUST

Application du matériel ou du 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 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 l’ordre. Toute incompatibilité provoque un diagnostic d'erreur.
Déclarez les autorisations dont les valeurs sémantiques sont appliquées.

Le mécanisme API permettant de déclarer les autorisations imposé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 met en œuvre une application logicielle de toutes les autorisations, qu'elles soient appliquées ou non par le matériel sécurisé.

Par exemple, considérons une implémentation basée sur TrustZone qui ne prend pas en charge l'expiration des clés. Une clé avec une date d'expiration peut toujours être créée. La liste d'autorisation de cette clé inclura la balise TAG::ORIGINATION_EXPIRE_DATETIME avec la date d'expiration. Une requête adressée à 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 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 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 détourné ou contourné. .

Pour plus d'informations sur la façon de déterminer si les clés sont sauvegardées sur du matériel, consultez Attestation de clé .

Autorisations de construction de messages cryptographiques

Les balises suivantes sont utilisées 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 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.

But

Les clés sont associées à un ensemble d'objectifs, exprimés sous la forme d'une ou plusieurs entrées d'autorisation avec la balise TAG::PURPOSE , qui définit comment elles peuvent être utilisées. Les finalités sont :

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

N’importe quelle 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 capable de convaincre le système de déchiffrer des données arbitraires pour générer des signatures.

Importer et exporter

Keymaster prend en charge uniquement 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 cryptage par 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 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 sera trouvée dans la liste hw_enforced des caractéristiques de la clé, tandis qu'une clé importée dans un 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 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 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 plusieurs utilisateurs), et non de l'UID de l'application, et qu'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 que TAG::USER_SECURE_ID l’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, 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 chevauchent 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 probablement 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 facultatif et certaines données client facultatives ( 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 à 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 l'expiration des clés peuvent être associés à une clé et Keymaster refuse d'effectuer des opérations sur les clés 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é soit utilisée pour « créer » un nouveau texte chiffré/signature/etc., ou pour « utiliser » un texte chiffré/signature/etc. A noter que cette distinction n'est pas exposée aux applications.

Les 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écrypter/vérifier les messages.

Étant donné que l'heure murale est fournie par un 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 fiables, par exemple via un protocole de réponse au défi avec un serveur de temps distant de confiance.

Liaison de racine 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 cryptographiquement à 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 du périphérique. Si la clé publique est modifiée pour permettre l'utilisation d'une image système différente ou si l'état du 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 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 les clés en interne et de renvoyer des poignées plutôt que des clés chiffrées. Ou il peut y avoir d'autres cas dans lesquels les clés ne peuvent pas être utilisées jusqu'à ce qu'un autre composant du système mondial non sécurisé ou sécurisé soit 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. A 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 des limites de vitesse est un tableau d'ID de clé et d'horodatages de dernière utilisation. Ce tableau sera probablement de taille limitée, mais pourra accueillir 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 sont « sécurisées », préférant refuser toutes les opérations de touches à vitesse limitée 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, pouvant accueillir au moins quatre clés et également dotée d'une sécurité intégré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

Étant donné que le matériel sécurisé génère des nombres aléatoires pour les éléments de clé et les vecteurs d'initialisation (IV), et que les générateurs matériels de nombres aléatoires ne sont pas toujours entièrement fiables, le Keymaster HAL fournit une interface permettant au client de fournir une entropie supplémentaire qui sera mélangée au nombre aléatoire. nombres générés.

Utilisez un générateur matériel de nombres aléatoires 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. De plus, l'opération de mélange utilisée doit garantir que la sortie aléatoire est imprévisible si l'une des sources de départ 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é.