Clé et attestation d'identité

Keystore offre un endroit plus sécurisé pour créer, stocker et utiliser des clés cryptographiques de manière contrôlée. Lorsque le stockage de clés sauvegardé sur matériel est disponible et utilisé, le matériel de clé est plus sécurisé contre l'extraction de l'appareil, et Keymaster applique des restrictions difficiles à contourner.

Toutefois, cela n'est vrai que si l'on sait que les clés du magasin de clés se trouvent dans un stockage matériel. Dans Keymaster 1, les applications ou les serveurs distants n'avaient aucun moyen de vérifier de manière fiable si tel était le cas. Le démon du magasin de clés a chargé le keymaster HAL disponible et a cru tout ce que le HAL disait concernant la sauvegarde matérielle des clés.

Pour remédier à cela, Keymaster a introduit l'attestation de clé dans Android 7.0 (Keymaster 2) et l'attestation d'identité dans Android 8.0 (Keymaster 3).

L'attestation de clé vise à fournir un moyen de déterminer avec précision si une paire de clés asymétriques est basée sur du matériel, quelles sont les propriétés de la clé et quelles contraintes sont appliquées à son utilisation.

L'attestation d'identité permet à l'appareil de fournir la preuve de ses identifiants matériels, tels que le numéro de série ou l'IMEI.

Attestation de clé

Pour prendre en charge l'attestation de clé, Android 7.1 a introduit un ensemble de balises, de types et de méthodes dans HAL.

Mots clés

  • Tag::ATTESTATION_CHALLENGE
  • Tag::INCLUDE_UNIQUE_ID
  • Tag::RESET_SINCE_ID_ROTATION

Taper

Keymaster 2 et inférieur

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

Méthode AttestKey

Maître des clés 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 et inférieur

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);
  • dev est la structure du périphérique keymaster.
  • keyToAttest est le blob de clé renvoyé par generateKey pour lequel l'attestation sera créée.
  • attestParams est une liste de tous les paramètres nécessaires à l'attestation. Cela inclut Tag::ATTESTATION_CHALLENGE et éventuellement Tag::RESET_SINCE_ID_ROTATION , ainsi que Tag::APPLICATION_ID et Tag::APPLICATION_DATA . Les deux derniers sont nécessaires pour déchiffrer le blob de clé s'ils ont été spécifiés lors de la génération de la clé.
  • certChain est le paramètre de sortie, qui renvoie un tableau de certificats. L'entrée 0 est le certificat d'attestation, ce qui signifie qu'elle certifie la clé de keyToAttest et contient l'extension d'attestation.

La méthode attestKey est considérée comme une opération de clé publique sur la clé attestée, car elle peut être appelée à tout moment et n'a pas besoin de respecter les contraintes d'autorisation. Par exemple, si la clé attestée nécessite une authentification de l'utilisateur pour être utilisée, une attestation peut être générée sans authentification de l'utilisateur.

Certificat d'attestation

Le certificat d'attestation est un certificat X.509 standard, avec une extension d'attestation facultative qui contient une description de la clé attestée. Le certificat est signé avec une clé d'attestation certifiée. La clé d'attestation peut utiliser un algorithme différent de celui de la clé attestée.

Le certificat d'attestation contient les champs du tableau ci-dessous et ne peut contenir aucun champ supplémentaire. Certains champs spécifient une valeur de champ fixe. Les tests CTS valident que le contenu du certificat est exactement tel que défini.

SÉQUENCE du certificat

Nom du champ (voir RFC 5280 ) Valeur
tbsCertificat SÉQUENCE du certificat TBSCertificate
algorithme de signature AlgorithmeIdentifiant de l'algorithme utilisé pour signer la clé :
ECDSA pour les clés EC, RSA pour les clés RSA.
valeur de signature BIT STRING, signature calculée sur le tbsCertificate codé en ASN.1 DER.

SÉQUENCE du certificat TBSCertificat

Nom du champ (voir RFC 5280 ) Valeur
version INTEGER 2 (signifie certificat v3)
serialNumber INTEGER 1 (valeur fixe : identique sur tous les certificats)
signature AlgorithmeIdentifiant de l'algorithme utilisé pour signer la clé : ECDSA pour les clés EC, RSA pour les clés RSA.
issuer Identique au champ objet de la clé d’attestation de lot.
validity SÉQUENCE de deux dates, contenant les valeurs de Tag::ACTIVE_DATETIME et Tag::USAGE_EXPIRE_DATETIME . Ces valeurs sont en millisecondes depuis le 1er janvier 1970. Voir RFC 5280 pour les représentations correctes de la date dans les certificats.
Si Tag::ACTIVE_DATETIME n'est pas présent, utilisez la valeur de Tag::CREATION_DATETIME . Si Tag::USAGE_EXPIRE_DATETIME n’est pas présent, utilisez la date d’expiration du certificat de clé d’attestation par lots.
subject CN = "Android Keystore Key" (valeur fixe : identique sur tous les certificats)
subjectPublicKeyInfo SubjectPublicKeyInfo contenant la clé publique attestée.
extensions/Key Usage digitalSignature : défini si la clé a un objectif KeyPurpose::SIGN ou KeyPurpose::VERIFY . Tous les autres bits sont désactivés.
extensions/CRL Distribution Points Valeur à déterminer
extensions/"attestation" L'OID est 1.3.6.1.4.1.11129.2.1.17 ; le contenu est défini dans la section Extension de l'attestation ci-dessous. Comme pour toutes les extensions de certificat X.509, le contenu est représenté sous la forme d'un OCTET_STRING contenant un codage DER de la SEQUENCE d'attestation.

Extension d'attestation

L'extension attestation contient une description complète des autorisations keymaster associées à la clé, dans une structure qui correspond directement aux listes d'autorisation telles qu'utilisées dans Android et le keymaster HAL. Chaque balise d'une liste d'autorisation est représentée par une entrée SEQUENCE ASN.1, explicitement balisée avec le numéro de balise keymaster, mais avec le descripteur de type (quatre bits de poids fort) masqué.

Par exemple, dans Keymaster 3, Tag::PURPOSE est défini dans types.hal comme ENUM_REP | 1 . Pour l'extension d'attestation, la valeur ENUM_REP est supprimée, laissant la balise 1 . (Pour Keymaster 2 et versions antérieures, KM_TAG_PURPOSE est défini dans keymaster_defs.h.)

Les valeurs sont traduites de manière simple en types ASN.1, selon ce tableau :

Type de maître de clé Type ASN.1
ENUM ENTIER
ENUM_REP ENSEMBLE d'ENTIER
UINT ENTIER
UINT_REP ENSEMBLE d'ENTIER
ULONG ENTIER
ULONG_REP ENSEMBLE d'ENTIER
DATE ENTIER (millisecondes depuis le 1er janvier 1970 00:00:00 GMT)
BOOL NULL (dans keymaster, la balise présente signifie vrai, absent signifie faux.
La même sémantique s'applique au codage ASN.1)
BIGNUM Non utilisé actuellement, donc aucun mappage n'est défini
BYTES OCTET_STRING

Schéma

Le contenu de l'extension d'attestation est décrit par le schéma ASN.1 suivant.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  applicationId               [601] EXPLICIT OCTET_STRING OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

Champs KeyDescription

Les champs keymasterVersion et attestationChallenge sont identifiés par position, plutôt que par balise, de sorte que les balises sous la forme codée spécifient uniquement le type de champ. Les champs restants sont implicitement balisés comme spécifié dans le schéma.

Nom de domaine Taper Valeur
attestationVersion ENTIER Version du schéma d'attestation : 1, 2 ou 3.
attestationSecurity Niveau de sécurité Le niveau de sécurité de cette attestation. Il est possible d'obtenir des attestations logicielles de clés matérielles. De telles attestations ne sont pas fiables si le système Android est compromis.
keymasterVersion ENTIER Version du périphérique keymaster : 0, 1, 2, 3 ou 4.
keymasterSecurity Niveau de sécurité Le niveau de sécurité de l’implémentation du keymaster.
attestationChallenge OCTET_STRING Valeur de Tag::ATTESTATION_CHALLENGE , spécifiée dans la demande d'attestation.
uniqueId OCTET_STRING ID unique facultatif, présent si la clé a Tag::INCLUDE_UNIQUE_ID
softwareEnforced Liste d'autorisation Facultatives, autorisations keymaster qui ne sont pas appliquées par le TEE, le cas échéant.
teeEnforced Liste d'autorisation Facultatif, autorisations Keymaster appliquées par le TEE, le cas échéant.

Champs de la liste d'autorisations

Les champs AuthorizationList sont tous facultatifs et sont identifiés par la valeur de la balise keymaster, les bits de type étant masqués. Un balisage explicite est utilisé afin que les champs contiennent également une balise indiquant leur type ASN.1, pour une analyse plus facile.

Pour plus de détails sur les valeurs de chaque champ, consultez types.hal pour Keymaster 3 et keymaster_defs.h pour Keymaster 2 et versions antérieures. Les noms de balises Keymaster ont été transformés en noms de champs en omettant le préfixe KM_TAG et en changeant le reste en casse camel, donc Tag::KEY_SIZE est devenu keySize .

Champs RootOfTrust

Les champs RootOfTrust sont identifiés par position.

Nom de domaine Taper Valeur
verifiedBootKey OCTET_STRING Un hachage sécurisé de la clé utilisée pour vérifier l'image système. SHA-256 recommandé.
deviceLocked BOOLÉEN Vrai si le chargeur de démarrage est verrouillé, ce qui signifie que seules les images signées peuvent être flashées et qu'une vérification de démarrage vérifiée est effectuée.
verifiedBootState État de démarrage vérifié État de démarrage vérifié.
verifiedBootHash OCTET_STRING Un résumé de toutes les données protégées par Verified Boot. Pour les appareils qui utilisent l’implémentation Android Verified Boot de Verified Boot, cette valeur contient le résumé de la structure VBMeta ou la structure des métadonnées Verified Boot. Pour en savoir plus sur la façon de calculer cette valeur, consultezThe VBMeta Digest

Valeurs VerifiedBootState

Les valeurs de verifiedBootState ont les significations suivantes :

Valeur Signification
Verified Indique une chaîne de confiance complète s'étendant du chargeur de démarrage aux partitions vérifiées, y compris le chargeur de démarrage, la partition de démarrage et toutes les partitions vérifiées.
Dans cet état, la valeur verifiedBootKey est le hachage du certificat intégré, c'est-à-dire le certificat immuable gravé dans la ROM.
Cet état correspond à l'état de démarrage vert tel que documenté dans la documentation du flux de démarrage vérifié .
SelfSigned Indique que la partition de démarrage a été vérifiée à l'aide du certificat intégré et que la signature est valide. Le chargeur de démarrage affiche un avertissement et l'empreinte digitale de la clé publique avant de permettre la poursuite du processus de démarrage.
Dans cet état, la valeur verifiedBootKey est le hachage du certificat auto-signé.
Cet état correspond à l'état de démarrage jaune tel que documenté dans la documentation du flux de démarrage vérifié .
Unverified Indique qu’un périphérique peut être librement modifié. L’intégrité du périphérique est laissée à l’utilisateur pour vérification hors bande. Le chargeur de démarrage affiche un avertissement à l'utilisateur avant d'autoriser la poursuite du processus de démarrage.
Dans cet état, la valeur verifiedBootKey est vide.
Cet état correspond à l'état de démarrage orange tel que documenté dans la documentation du flux de démarrage vérifié .
Failed Indique que la vérification de l'appareil a échoué. Aucun certificat d'attestation ne contient réellement cette valeur, car dans cet état le chargeur de démarrage s'arrête. Il est inclus ici par souci d’exhaustivité.
Cet état correspond à l'état de démarrage rouge tel que documenté dans la documentation du flux de démarrage vérifié .

Valeurs de niveau de sécurité

Les valeurs de securityLevel ont les significations suivantes :

Valeur Signification
Software Le code qui crée ou gère l'élément concerné (attestation ou clé) est implémenté dans le système Android et pourrait être modifié si ce système est compromis.
TrustedEnvironment Le code qui crée ou gère l'élément concerné (attestation ou clé) est implémenté dans un Trusted Execution Environment (TEE). Il pourrait être modifié si le TEE est compromis, mais le TEE est très résistant aux compromissions à distance et modérément résistant aux compromissions par attaque matérielle directe.
StrongBox Le code qui crée ou gère l'élément concerné (attestation ou clé) est implémenté dans un module de sécurité matériel dédié. Il pourrait être modifié si le module de sécurité matériel est compromis, mais il est très résistant aux compromissions à distance et aux compromissions par attaque matérielle directe.

Identifiant unique

L'ID unique est une valeur de 128 bits qui identifie l'appareil, mais uniquement pour une période de temps limitée. La valeur est calculée avec :

HMAC_SHA256(T || C || R, HBK)

Où:

  • T est la "valeur du compteur temporel", calculée en divisant la valeur de Tag::CREATION_DATETIME par 2592000000, en supprimant tout reste. T change tous les 30 jours (2592000000 = 30 * 24 * 60 * 60 * 1000).
  • C est la valeur de Tag::APPLICATION_ID
  • R vaut 1 si Tag::RESET_SINCE_ID_ROTATION est présent dans le paramètre attest_params de l'appel attest_key, ou 0 si la balise n'est pas présente.
  • HBK est un secret matériel unique connu de Trusted Execution Environment et jamais révélé par celui-ci. Le secret contient au moins 128 bits d'entropie et est unique à chaque appareil individuel (l'unicité probabiliste est acceptable étant donné les 128 bits d'entropie). HBK doit être dérivé du matériel de clé fusionné via HMAC ou AES_CMAC.

Tronquez la sortie HMAC_SHA256 à 128 bits.

Clés d'attestation et certificats

Deux clés, une RSA et une ECDSA, ainsi que les chaînes de certificats correspondantes, sont provisionnées en toute sécurité dans l'appareil.

Android 12 introduit le provisionnement de clés à distance, et Android 13 nécessite que les appareils le mettent en œuvre. Remote Key Provisioning fournit aux appareils sur le terrain des certificats d’attestation ECDSA P256 par application. Ces certificats ont une durée de vie plus courte que les certificats fournis en usine.

Plusieurs IMEI

Android 14 ajoute la prise en charge de plusieurs IMEI dans l’enregistrement d’attestation de clé Android. Les OEM peuvent implémenter cette fonctionnalité en ajoutant une balise KeyMint pour un deuxième IMEI. Il est de plus en plus courant que les appareils disposent de plusieurs radios cellulaires et les constructeurs OEM peuvent désormais prendre en charge les appareils dotés de deux IMEI.

Les OEM doivent disposer d'un IMEI secondaire, s'il est présent sur leurs appareils, à fournir à la ou aux implémentations de KeyMint afin que ces implémentations puissent l'attester de la même manière qu'elles attestent du premier IMEI.

Attestation d'identité

Android 8.0 inclut la prise en charge facultative de l'attestation d'identité pour les appareils dotés de Keymaster 3. L'attestation d'identité permet à l'appareil de fournir la preuve de ses identifiants matériels, tels que le numéro de série ou l'IMEI. Bien qu'il s'agisse d'une fonctionnalité facultative, il est fortement recommandé que toutes les implémentations de Keymaster 3 la prennent en charge, car la possibilité de prouver l'identité de l'appareil permet des cas d'utilisation tels qu'une véritable configuration à distance sans contact pour être plus sécurisés (car le côté distant peut être certain qu'il parle au bon appareil, et non à un appareil usurpant son identité).

L'attestation d'identification fonctionne en créant des copies des identifiants matériels de l'appareil auxquelles seul l'environnement d'exécution sécurisé (TEE) peut accéder avant que l'appareil ne quitte l'usine. Un utilisateur peut déverrouiller le chargeur de démarrage de l'appareil et modifier le logiciel système et les identifiants signalés par les frameworks Android. Les copies des identifiants détenus par le TEE ne peuvent pas être manipulées de cette manière, garantissant que l'attestation d'identification de l'appareil n'attestera que les identifiants matériels d'origine de l'appareil, contrecarrant ainsi les tentatives d'usurpation d'identité.

La surface principale de l'API pour l'attestation d'ID s'appuie sur le mécanisme d'attestation de clé existant introduit avec Keymaster 2. Lors de la demande d'un certificat d'attestation pour une clé détenue par keymaster, l'appelant peut demander que les identifiants matériels de l'appareil soient inclus dans les métadonnées du certificat d'attestation. Si la clé est conservée dans le TEE, le certificat reviendra à une racine de confiance connue. Le destinataire d'un tel certificat peut vérifier que le certificat et son contenu, y compris les identifiants matériels, ont été rédigés par le TEE. Lorsqu'on lui demande d'inclure les identifiants matériels dans le certificat d'attestation, le TEE atteste uniquement les identifiants détenus dans son stockage, tels qu'ils sont renseignés dans l'usine.

Propriétés de stockage

Le stockage qui contient les identifiants de l'appareil doit avoir ces propriétés :

  • Les valeurs dérivées des identifiants d'origine de l'appareil sont copiées dans le stockage avant que l'appareil ne quitte l'usine.
  • La méthode destroyAttestationIds() peut détruire définitivement cette copie des données dérivées de l'identifiant. La destruction permanente signifie que les données sont complètement supprimées, de sorte qu'aucune réinitialisation d'usine ni aucune autre procédure effectuée sur l'appareil ne peut les restaurer. Ceci est particulièrement important pour les appareils sur lesquels un utilisateur a déverrouillé le chargeur de démarrage, modifié le logiciel système et modifié les identifiants renvoyés par les frameworks Android.
  • Les installations RMA devraient avoir la capacité de générer de nouvelles copies des données dérivées de l’identifiant matériel. De cette façon, un appareil qui passe par RMA peut à nouveau effectuer une attestation d'identité. Le mécanisme utilisé par les installations RMA doit être protégé afin que les utilisateurs ne puissent pas l'invoquer eux-mêmes, car cela leur permettrait d'obtenir des attestations d'identités usurpées.
  • Aucun code autre que l'application de confiance Keymaster dans le TEE n'est capable de lire les données dérivées de l'identifiant conservées dans le stockage.
  • Le stockage est inviolable : Si le contenu du stockage a été modifié, le TEE le traite comme si les copies du contenu avaient été détruites et refuse toute tentative d'attestation d'identité. Ceci est implémenté en signant ou en MACing le stockage comme décrit ci-dessous .
  • Le stockage ne contient pas les identifiants d'origine. L'attestation d'identité impliquant une contestation, l'appelant fournit toujours les identifiants à attester. Le TEE doit seulement vérifier que celles-ci correspondent aux valeurs qu'elles avaient initialement. Le stockage des hachages sécurisés des valeurs d'origine plutôt que des valeurs permet cette vérification.

Construction

Pour créer une implémentation possédant les propriétés répertoriées ci-dessus, stockez les valeurs dérivées de l'ID dans la construction suivante S. Ne stockez pas d'autres copies des valeurs d'ID, à l'exception des emplacements normaux dans le système, qu'un propriétaire de périphérique peut modifier par root :

S = D || HMAC(HBK, D)

où:

  • D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
  • HMAC est la construction HMAC avec un hachage sécurisé approprié (SHA-256 recommandé)
  • HBK est une clé matérielle qui n'est utilisée à aucune autre fin
  • ID 1 ...ID n sont les valeurs d'ID d'origine ; l'association d'une valeur particulière à un index particulier dépend de l'implémentation, car différents appareils auront un nombre différent d'identifiants
  • || représente la concaténation

Étant donné que les sorties HMAC sont de taille fixe, aucun en-tête ou autre structure n'est requis pour pouvoir trouver les hachages d'ID individuels, ou le HMAC de D. En plus de vérifier les valeurs fournies pour effectuer l'attestation, les implémentations doivent valider S en extrayant D de S. , en calculant HMAC(HBK, D) et en le comparant à la valeur dans S pour vérifier qu'aucun identifiant individuel n'a été modifié/corrompu. En outre, les implémentations doivent utiliser des comparaisons à temps constant pour tous les éléments d'ID individuels et la validation de S. Le temps de comparaison doit être constant quel que soit le nombre d'ID fournis et la correspondance correcte de n'importe quelle partie du test.

Identifiants matériels

L'attestation d'ID prend en charge les identifiants matériels suivants :

  1. Nom de la marque, tel que renvoyé par Build.BRAND dans Android
  2. Nom de l'appareil, tel que renvoyé par Build.DEVICE dans Android
  3. Nom du produit, tel que renvoyé par Build.PRODUCT dans Android
  4. Nom du fabricant, tel que renvoyé par Build.MANUFACTURER dans Android
  5. Nom du modèle, tel que renvoyé par Build.MODEL dans Android
  6. Numéro de série
  7. IMEI de toutes les radios
  8. MEID de toutes les radios

Pour prendre en charge l'attestation d'ID d'appareil, un appareil atteste de ces identifiants. Tous les appareils fonctionnant sous Android possèdent les six premiers et ils sont nécessaires au fonctionnement de cette fonctionnalité. Si l'appareil dispose de radios cellulaires intégrées, l'appareil doit également prendre en charge l'attestation des IMEI et/ou MEID des radios.

L'attestation d'identité est demandée en effectuant une attestation de clé et en incluant les identifiants de périphérique à attester dans la demande. Les identifiants sont étiquetés comme suit :

  • ATTESTATION_ID_BRAND
  • ATTESTATION_ID_DEVICE
  • ATTESTATION_ID_PRODUCT
  • ATTESTATION_ID_MANUFACTURER
  • ATTESTATION_ID_MODEL
  • ATTESTATION_ID_SERIAL
  • ATTESTATION_ID_IMEI
  • ATTESTATION_ID_MEID

L'identifiant à attester est une chaîne d'octets codée en UTF-8. Ce format s'applique également aux identifiants numériques. Chaque identifiant à attester est exprimé sous forme de chaîne codée en UTF-8.

Si l'appareil ne prend pas en charge l'attestation d'ID (ou si destroyAttestationIds() a été précédemment appelé et que l'appareil ne peut plus attester ses identifiants), toute demande d'attestation de clé incluant une ou plusieurs de ces balises échoue avec ErrorCode::CANNOT_ATTEST_IDS .

Si l'appareil prend en charge l'attestation d'identification et qu'une ou plusieurs des balises ci-dessus ont été incluses dans une demande d'attestation de clé, le TEE vérifie que l'identifiant fourni avec chacune des balises correspond à sa copie des identifiants matériels. Si un ou plusieurs identifiants ne correspondent pas, l'attestation entière échoue avec ErrorCode::CANNOT_ATTEST_IDS . Il est valable que le même tag soit fourni plusieurs fois. Cela peut être utile, par exemple, lors de l'attestation des IMEI : un appareil peut avoir plusieurs radios avec plusieurs IMEI. Une demande d'attestation est valide si la valeur fournie avec chaque ATTESTATION_ID_IMEI correspond à l'une des radios de l'appareil. La même chose s'applique à toutes les autres balises.

Si l'attestation réussit, les ID attestés sont ajoutés à l' extension d'attestation (OID 1.3.6.1.4.1.11129.2.1.17) du certificat d'attestation émis, en utilisant le schéma ci-dessus . Les modifications par rapport au schéma d'attestation Keymaster 2 sont en gras , avec des commentaires.

API Java

Cette section est uniquement informative. Les implémenteurs de Keymaster n'implémentent ni n'utilisent l'API Java. Ceci est fourni pour aider les implémenteurs à comprendre comment la fonctionnalité est utilisée par les applications. Les composants du système peuvent l'utiliser différemment, c'est pourquoi il est crucial que cette section ne soit pas traitée comme normative.