Attestation des clés et des ID

Le keystore offre un emplacement plus sécurisé pour créer, stocker et utiliser des de manière contrôlée. Lorsque le stockage de clés intégré au matériel est disponible et utilisé, le matériel de clé est mieux protégé contre l'extraction depuis l'appareil ; Keymaster applique des restrictions difficiles à neutraliser.

Toutefois, cela n'est vrai que si l'on sait que les clés du keystore stockage matériel. Dans Keymaster 1, il n'existait aucun moyen pour les applications ou des serveurs distants pour vérifier de manière fiable si c'était le cas. Le daemon du keystore chargé le keymaster HAL disponible et croyait tout ce que disait le HAL avec concernant le support matériel des clés.

Pour y remédier, Keymaster a introduit l'attestation de clé dans Android 7.0 (Keymaster 2) et son ID. attestation dans Android 8.0 (Keymaster 3).

L'attestation des clés vise à fournir un moyen déterminer si une paire de clés asymétrique est intégrée au matériel, quelles sont les propriétés de la clé et les contraintes qui s'appliquent à son utilisation.

L'attestation d'ID permet à l'appareil de fournir une preuve de ses identifiants matériels, comme le numéro de série ou le code IMEI.

Attestation des clés

Pour prendre en charge l'attestation des clés, Android 7.0 a introduit un ensemble de balises, de types et au HAL.

Tags

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

Type

Keymaster 2 et versions antérieures

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

Méthode AttestKey

Keymaster 3

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

Keymaster 2 et versions antérieures

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 de l'appareil 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 pour attestation. Cela inclut Tag::ATTESTATION_CHALLENGE et éventuellement Tag::RESET_SINCE_ID_ROTATION, et Tag::APPLICATION_ID et Tag::APPLICATION_DATA. La 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 des clés.
  • certChain est le paramètre de sortie, qui renvoie un tableau de certificats. L'entrée 0 correspond au certificat d'attestation. certifie la clé auprès de keyToAttest et contient le d'attestation.

La méthode attestKey est considérée comme une opération de clé publique sur le certifié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é certifiée nécessite que une authentification à utiliser, une attestation peut être générée sans que l'utilisateur l'authentification unique.

Certificat d'attestation

Le certificat d'attestation est un certificat X.509 standard, avec une option d'attestation contenant une description de la clé certifiée. La le certificat est signé avec une clé d'attestation certifiée. La clé d'attestation peuvent utiliser un algorithme différent de celui de la clé certifiée.

Le certificat d'attestation contient les champs du tableau ci-dessous et ne peut pas contenant des champs supplémentaires. Certains champs spécifient une valeur fixe. CTS les tests valident que le contenu du certificat est exactement tel que défini.

SEQUENCE du certificat

Nom du champ (voir RFC 5280) Valeur
certificat tbs SÉQUENCE DE Certificats TTS
signatureAlgorithm AlgorithmIdentifier de l'algorithme utilisé pour signer la clé:
ECDSA pour les clés EC, RSA pour les clés RSA.
signatureValue BIT STRING, signature calculée sur le tbsCertificate encodé au format DER ASN.1.

SÉQUENCE DE Certificats TLS

Nom du champ (voir RFC 5280) Valeur
version INTEGER 2 (correspond à un certificat v3)
serialNumber INTEGER 1 (valeur fixe: identique sur tous les certificats)
signature AlgorithmIdentifier 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 par lot.
validity SÉQUENCE de deux dates, contenant les valeurs de Tag::ACTIVE_DATETIME et Balise : USAGE_EXPIRE_DATETIME. Ces valeurs sont exprimées en millisecondes depuis le 1er janvier 1970. Consultez le document RFC 5280 pour obtenir de dates 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 le délai d'expiration date du certificat de clé d'attestation par lot.
subject CN = "Clé Android Keystore" (valeur fixe: identique sur tous les certificats)
subjectPublicKeyInfo SubjectPublicKeyInfo contenant la clé publique certifiée
extensions/Key Usage digitalSignature: défini si la clé a l'objectif KeyPurpose::SIGN ou KeyPurpose::VERIFY Tous les autres bits ne sont pas définis.
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 Extension d'attestation ci-dessous. Comme pour tous Extensions de certificat X.509, le contenu est représenté sous la forme d'une chaîne OCTET_STRING contenant un encodage DER de la SEQUENCE d'attestation.

Extension d'attestation

L'extension attestation contient une description complète du keymaster. les autorisations associées à la clé, dans une structure qui correspond directement aux listes d'autorisation utilisées dans Android et dans le HAL keymaster. Chaque tag de une liste d'autorisation est représentée par un numéro ASN1.SEQUENCE , explicitement avec le numéro de tag keymaster, mais avec le descripteur de type (quatre en haut des bits de commande) masqués.

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

Les valeurs sont facilement traduites en types ASN.1, comme indiqué dans le tableau suivant:

Type de Keymaster Type ASN.1
ENUM INTEGER
ENUM_REP SET sur INTEGER
UINT INTEGER
UINT_REP SET sur INTEGER
ULONG INTEGER
ULONG_REP SET sur INTEGER
DATE INTEGER (millisecondes depuis le 1er janvier 1970 à 00:00:00 GMT)
BOOL NULL (dans keymaster, la balise présente signifie "true" et absente signifie "false".
La même sémantique s'applique à l'encodage ASN.1.)
BIGNUM Non utilisé actuellement, 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,
  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

keymasterVersion et attestationChallenge les champs sont identifiés par position plutôt que par tag. Ainsi, les tags encodés ne spécifient que type de champ. Les champs restants sont implicitement balisés comme spécifié dans du schéma.

Nom du champ Type Valeur
attestationVersion INTEGER Version du schéma d'attestation: 1, 2 ou 3.
attestationSecurity Niveau de sécurité Niveau de sécurité de cette attestation. Il est possible d'obtenir un logiciel des clés intégrées au matériel. De telles attestations ne peuvent pas être approuvées si Le système Android est compromis.
keymasterVersion INTEGER Version de l'appareil keymaster: 0, 1, 2, 3 ou 4.
keymasterSecurity Niveau de sécurité Niveau de sécurité de l'implémentation de 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é comporte Tag::INCLUDE_UNIQUE_ID
softwareEnforced AuthorizationList Des autorisations de keymaster facultatives qui ne sont pas appliquées par le TEE, si toutes.
teeEnforced AuthorizationList Autorisations Keymaster facultatives appliquées par le TEE, le cas échéant.

Champs AuthorizationList

Les champs AuthorizationList sont tous facultatifs et sont identifiés par valeur de balise keymaster, avec les bits de type masqués. Le taggage explicite étant utilisé, les champs contiennent également une balise indiquant et leur type ASN.1, pour faciliter l'analyse.

Pour en savoir plus sur les valeurs de chaque champ, consultez types.hal pour Keymaster 3 et keymaster_defs.h pour Keymaster 2 et versions antérieures. Noms des tags Keymaster ont été transformées en noms de champs en omettant le KM_TAG et modifier le préfixe reste à Camel Case ("casse de chameau"), donc Tag::KEY_SIZE est devenu keySize

Champs RootOfTrust

Les champs RootOfTrust sont identifiés par position.

Nom du champ Type Valeur
verifiedBootKey OCTET_STRING Hachage sécurisé de la clé utilisée pour vérifier l'image système. SHA-256 recommandé.
deviceLocked BOOLEAN "True" si le bootloader est verrouillé, ce qui signifie que seules les images signées peuvent mis à jour et que la vérification du démarrage validé est terminée.
verifiedBootState VerifiedBootState État du démarrage validé.
verifiedBootHash OCTET_STRING Condensé de toutes les données protégées par le démarrage validé. Pour les appareils qui utilisent l'implémentation du démarrage validé Android, cette valeur contient le condensé de la structure VBMeta, qui correspond au démarrage validé. structure des métadonnées. Pour en savoir plus sur le calcul de cette valeur, consultez Condensé VBMeta

Valeurs VerifiedBootState

Les valeurs de verifiedBootState ont la signification suivante:

Valeur Signification
Verified Indique une chaîne de confiance complète s'étendant du bootloader jusqu'à la validation des partitions, y compris le bootloader, la partition de démarrage et toutes les partitions des partitions.
Dans cet état, la valeur verifiedBootKey correspond au hachage de l'élément certificat, ce qui signifie que le certificat immuable gravé dans la ROM.
Cet état correspond à l'état de démarrage vert, comme indiqué dans l'article <ph type="x-smartling-placeholder"></ph> sur le flux de démarrage validé.
SelfSigned Indique que la partition de démarrage a été validée à l'aide de la certificat, et la signature est valide. Le bootloader affiche un avertissement et l'empreinte de la clé publique avant d'autoriser le processus de démarrage à se poursuivre.
Dans cet état, la valeur verifiedBootKey correspond au hachage du code certificat.
Cet état correspond à l'état de démarrage jaune, comme indiqué dans l'article <ph type="x-smartling-placeholder"></ph> sur le flux de démarrage validé.
Unverified Indique qu'un appareil peut être modifié librement. L'intégrité de l'appareil est laissée à l'utilisateur pour vérifier hors bande. Le bootloader affiche un avertissement à l'utilisateur avant d'autoriser le processus de démarrage à se poursuivre.
Dans cet état, la valeur verifiedBootKey est vide.
Cet état correspond à l'état de démarrage orange, comme indiqué dans les <ph type="x-smartling-placeholder"></ph> sur le flux de démarrage validé.
Failed Indique que la validation de l'appareil a échoué. Aucun certificat d'attestation contient en fait cette valeur, car dans cet état, le bootloader s'arrête. Il est inclus ici par souci d'exhaustivité.
Cet état correspond à l'état de démarrage rouge, comme indiqué dans l'article <ph type="x-smartling-placeholder"></ph> sur le flux de démarrage validé.

Valeurs SecurityLevel

Les valeurs de securityLevel ont la signification suivante:

Valeur Signification
Software Le code qui crée ou gère l'élément concerné (attestation ou clé) est implémentée dans le système Android et peut être modifiée ou compromis.
TrustedEnvironment Le code qui crée ou gère l'élément concerné (attestation ou ) est implémentée dans un environnement d'exécution sécurisé (TEE). Il peut s'agir altéré si le TEE est compromis, mais le TEE est très résistant aux compromis et modérément résistants aux compromis par une attaque matérielle directe.
StrongBox Le code qui crée ou gère l'élément concerné (attestation ou clé) est implémentée dans un module matériel de sécurité dédié. Il peut s'agir si le module de sécurité matériel est compromis, résiste aux compromissions à distance et hautement résistantes aux compromissions une attaque matérielle.

Identifiant unique

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

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

Où :

  • T est la "valeur de compteur temporel", calculée en divisant la de Tag::CREATION_DATETIME de 2 592 000 000, en abandonnant reste. T changements tous les 30 jours (2 592 000 000 = 30 x 24 x 60) * 60 * 1000).
  • C est la valeur de Tag::APPLICATION_ID.
  • R est égal à 1 si Tag::RESET_SINCE_ID_ROTATION est présente dans le paramètre attest_params à l'appel attest_key, ou 0 si le paramètre est absente.
  • HBK est un secret matériel unique connu de l'API Trusted d'exécution et jamais révélé par celui-ci. Le secret contient au moins 128 bits d'entropie, propre à chaque appareil l'unicité est acceptable compte tenu des 128 bits d'entropie). Le HBK doit être dérivé du matériel de clé fusionnée via HMAC ou AES_CMAC.

Tronquez la sortie HMAC_SHA256 à 128 bits.

Les clés d'attestation certificats

Deux clés, une RSA et une ECDSA, et les chaînes de certificats correspondantes, sont provisionnées de manière sécurisée sur l'appareil.

Android 12 introduit le provisionnement de clés à distance et Android 13 nécessite des appareils le mettre en œuvre. Le provisionnement de clés à distance fournit aux appareils sur le terrain les certificats d'attestation ECDSA P256 par application. Ces certificats sont de plus court que ceux provisionnés en usine.

Plusieurs codes IMEI

Android 14 permet la prise en charge de plusieurs codes IMEI dans le Enregistrement d'attestation des clés Android. Les OEM peuvent implémenter cette fonctionnalité en ajoutant un tag KeyMint pour un second code IMEI. Il est de plus en plus courant que les appareils possèdent plusieurs antennes cellulaires et les OEM peuvent désormais prendre en charge les appareils avec deux codes IMEI.

Les OEM sont tenus d'avoir un code IMEI secondaire, s'il en existe sur leurs appareils, pour être provisionnées à la ou les implémentations KeyMint, afin que ces implémentations puissent attestent de la même façon qu'ils attestent du premier code IMEI

Attestation d'identité

Android 8.0 inclut la prise en charge facultative de l'attestation d'ID pour les appareils avec Keymaster 3. L'attestation d'ID permet à l'appareil de fournir une preuve de son matériel tels que le numéro de série ou le code IMEI. Cette fonctionnalité est facultative, Nous recommandons vivement que toutes les implémentations de Keymaster 3 soient prises en charge. En effet, la preuve de l'identité d'un appareil permet la configuration à distance sans contact afin d'en renforcer la sécurité (car le côté distant peut assurez-vous qu'il s'agit du bon appareil, et non de l'usurpation d'identité l'identité).

L'attestation d'ID crée des copies des identifiants matériels de l'appareil auquel seul l'environnement d'exécution sécurisé (TEE) peut accéder en sortie d'usine. Un utilisateur peut déverrouiller le bootloader de l'appareil et modifier le le logiciel système et les identifiants signalés par les frameworks Android. La les copies des identifiants détenus par le TEE ne peuvent pas être manipulées de cette manière, garantissant que l'attestation de l'ID de l'appareil n'attestera que l'authentification des identifiants matériels d'origine contre ainsi les tentatives de spoofing.

La surface d'API principale pour l'attestation d'ID s'appuie sur la clé existante d'attestation introduit avec Keymaster 2. Lorsque vous demandez un d'attestation pour une clé détenue par keymaster, l'appelant peut demander que les identifiants matériels de l'appareil soient inclus dans l'attestation les métadonnées du certificat. Si la clé est conservée dans le TEE, le certificat sera à une racine de confiance connue. Le destinataire d'un tel certificat peut vérifier que le certificat et son contenu, y compris le matériel les identifiants, ont été écrits par le TEE. Lorsqu'on vous demande d'inclure du matériel dans le certificat d'attestation, le TEE n'atteste que des identifiants conservés dans son espace de stockage, tels qu'ils sont insérés dans l'usine.

Propriétés de stockage

L'espace de stockage qui contient les identifiants de l'appareil doit avoir les propriétés suivantes:

  • Les valeurs dérivées des identifiants d'origine de l'appareil sont copiées dans dans l'espace de 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 définitive signifie données sont effacées. Ni un rétablissement de la configuration d'usine procédure effectuée sur l'appareil peut le restaurer. C'est particulièrement important pour les appareils sur lesquels un utilisateur a déverrouillé le bootloader et modifié le logiciel système et modifié les identifiants renvoyés par Android cadres réglementaires.
  • Les installations ARM doivent pouvoir générer de nouvelles copies des données dérivées de l'identifiant matériel. De cette façon, un un appareil qui passe par l'ARM peut effectuer à nouveau une attestation d'ID. La mécanisme utilisé par les installations ARM doivent être protégés pour que les utilisateurs ne puissent pas l'appeler eux-mêmes, car cela leur permettrait d'obtenir des attestations des ID falsifiés.
  • Aucun code autre que l'application de confiance Keymaster dans le TEE ne peut lire le de données dérivées des identifiants conservées dans l'espace de stockage.
  • Le stockage est protégé contre les accès non autorisés: si le contenu de l'espace de stockage a été modifié, le TEE le traite de la même manière que si les copies du contenu avaient a été détruite et refuse toutes les tentatives d'attestation d'identité. Elle est implémentée en signant ou en créant une commande MAC sur le stockage comme décrit ci-dessous.
  • L'espace de stockage ne contient pas les identifiants d'origine. Comme l'attestation d'ID un défi, l'appelant fournit toujours les identifiants est attesté. Le TEE a seulement besoin de vérifier que ces valeurs correspondent aux valeurs qu’elle dont vous disposiez au départ. Stockage de hachages sécurisés des valeurs d'origine au lieu des valeurs active cette vérification.

Construction

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

S = D || HMAC(HBK, D)

où :

  • D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
  • 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
  • ID1...IDn correspond aux valeurs d'ID d'origine. l'association d'un une valeur particulière à un index dépend de la mise en œuvre, différents appareils ont des nombres d'identifiants différents
  • || représente la concaténation

Comme les sorties HMAC ont une taille fixe, aucun en-tête ni aucune autre structure ne sont nécessaire pour trouver les hachages d’ID individuels, ou le HMAC de D. De plus, à la vérification des 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 ID individuel n'a été modifié/corrompu. Par ailleurs, les implémentations doivent effectuer des comparaisons en temps constant pour tous les identifiants et la validation de S. La durée de comparaison doit être constante, quelle que soit le nombre d'ID fournis et la correspondance correcte de toute partie du test.

Identifiants matériels

L'attestation d'ID est compatible avec les identifiants matériels suivants:

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

Pour prendre en charge l'attestation des ID d'appareil, un appareil atteste de ces identifiants. Tout les appareils fonctionnant sous Android disposent des six premiers appareils, fonctionnalité. Si l'appareil intègre des signaux radio cellulaires, il doit également permettre l'attestation des codes IMEI et/ou MEID des signaux radio.

l'attestation d'ID est demandée en effectuant une attestation de clé et en incluant le des identifiants d'appareils à attester dans la requête. Les identifiants portent le libellé suivant:

  • 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 encodée au format UTF-8. Ce format s'applique aux des identifiants numériques. Chaque identifiant à attester est exprimé sous la forme d'un Chaîne encodée au format UTF-8.

Si l'appareil n'est pas compatible avec l'attestation d'ID (ou destroyAttestationIds() a déjà été appelé et l'appareil ne peut pas ses identifiants), toute demande d'attestation de clé incluant un ou plusieurs des éléments suivants : ces balises échouent avec ErrorCode::CANNOT_ATTEST_IDS.

Si l'appareil est compatible avec l'attestation d'identification et qu'une ou plusieurs des balises ci-dessus comportent inclus dans une demande d'attestation de clé, le TEE vérifie l'identifiant fournies avec chacun des tags correspond à sa copie des identifiants matériels. Si un ou plusieurs identifiants ne correspondent pas, l'intégralité de l'attestation échoue avec ErrorCode::CANNOT_ATTEST_IDS Il est possible que le même tag soit fournies plusieurs fois. Cela peut être utile, par exemple, pour attester des codes IMEI: Un appareil peut posséder plusieurs radios avec plusieurs codes IMEI. Une demande d'attestation est valide si la valeur fournie avec chaque ATTESTATION_ID_IMEI correspond l'une des radios de l'appareil. Il en va de même pour tous les autres tags.

Si l'attestation aboutit, les ID certifiés sont ajoutés au extension d'attestation (OID 1.3.6.1.4.1.11129.2.1.17) du certificat d'attestation émis, à l'aide du schéma ci-dessus. Modifications de Keymaster 2 d'attestation sont en gras et accompagnés de commentaires.

API Java

Cette section est fournie à titre indicatif uniquement. ni les implémentations de Keymaster, mettre en œuvre ni utiliser l'API Java. Ces informations sont fournies pour aider les responsables de la mise en œuvre à comprendre la façon dont elle est utilisée par les applications. Les composants système peuvent l'utiliser différemment, c'est pourquoi il est essentiel que cette section ne soit pas considérée comme normative.