Identifiants d'identité
Les appareils Android utilisent l'identifiant d'identité pour gérer de manière sécurisée les identifiants sur l'appareil. Identifiants d'identité propose un certain nombre de fonctionnalités de sécurité que l'émetteur doit utiliser pour vous assurer que leur intégration avec Google est aussi sécurisée que possible.
Nonce signé
La bibliothèque d'identifiants d'identité relève un défi (appelés dans cette API nonce) lors de la récupération du certificat d'identité de l'appareil, envoyé à l'émetteur dans RegisterDeviceRequest. Ce nonce est signé et intégré à l'extension d'attestation de l'appareil certificat d'identité. Cela permet à l'émetteur de s'assurer de la récence du certificat et de l'attestation, et qu'ils ne sont pas rejoués par un serveur au milieu des communications.
Profils de contrôle d'accès
Les profils de contrôle d'accès permettent à l'émetteur de spécifier précisément comment ils et souhaitez que les données stockées dans les identifiants d'identité soient protégées. La l'émetteur peut spécifier si l'authentification de l'utilisateur est requise pour accéder aux données et le temps dont dispose l'utilisateur pour s'authentifier. Futur (pas cette fonctionnalité, par exemple en limitant les lecteurs peuvent accéder à l'élément de données. Détails sur le formatage du contrôle des accès se trouvent au format de l'objet Identifiant.
Preuve du provisionnement
L'objet Preuve du provisionnement permet aux émetteurs de savoir que L'identifiant a bien été stocké dans "Identity Credential" (Identifiant d'identité). Un émetteur doit ne pas émettre de MSO pour un certificat tant qu'il n'a pas reçu et validé la preuve de et le provisionnement. Pour en savoir plus sur cet objet, consultez la documentation sur les identifiants d'identité.
Formats des objets
Chacun de ces objets est chiffré de bout en bout entre l'appareil et de l'émetteur. Par conséquent, les serveurs Google ne sont pas en mesure de normaliser ces objets, et certains d'entre eux peuvent avoir des formats différents de le reste des objets de l'API. Par exemple, le Justificatif d'identité est au format CBOR que JSON, ce qui est attendu au niveau d'Android.
Identifiant
L'identifiant contient les éléments de données et leur mode d'accès. Il
contient deux objets principaux, provisionedData et accessControlProfiles. La
provisionedData contient tous les espaces de noms pertinents pour le
type d'identifiants. Par exemple, pour un permis de conduire mobile, il s'agit de
org.iso.18013.5.1 et org.aamva.18013.5.1. Entrées de données et valeurs
dans les espaces de noms spécifient les profils de contrôle d'accès concernés. C'est
sous la forme d'une liste d'identifiants, où l'identifiant correspond à un profil de contrôle d'accès dans
la liste accessControlProfiles. Dans l'exemple ci-dessous, le [0] dans chaque donnée
L'entrée fait référence au profil de contrôle d'accès associé à l'ID 0, et non à l'index 0.
Vous trouverez ci-dessous un exemple d'élément de données de carte CBOR non codé.
{ "provisionedData": { "org.iso.18013.5.1": [ { "name": "family_name", "value": "Smith", "accessControlProfiles": [ 1 ] }, { "name": "given_name", "value": "Stewart", "accessControlProfiles": [ 1 ] }, { "name": "birth_date", "value": { "tag": 1004, "value": "1965-09-01" }, "accessControlProfiles": [ 1 ] }, { "name": "issue_date", "value": { "tag": 1004, "value": "2022-08-01" }, "accessControlProfiles": [ 1 ] }, { "name": "expiry_date", "value": { "tag": 1004, "value": "2027-08-01" }, "accessControlProfiles": [ 1 ] }, { "name": "issuing_authority", "value": "IA", "accessControlProfiles": [ 1 ] }, { "name": "issuing_country", "value": "US", "accessControlProfiles": [ 1 ] }, { "name": "document_number", "value": "D04320785", "accessControlProfiles": [ 1 ] }, { "name": "portrait", "value": { "type": "Buffer", "data": [ 167, 30, 148, 218, 204, 75, 112, 162, 138, 40, 52, 63, 255 ] }, "accessControlProfiles": [ 1 ] }, { "name": "un_distinguishing_sign", "value": "USA", "accessControlProfiles": [ 1 ] }, { "name": "driving_privileges", "value": [ { "expiry_date": { "tag": 1004, "value": "2027-08-01" }, "issue_date": { "tag": 1004, "value": "2022-08-01" }, "vehicle_category_code": "B" } ], "accessControlProfiles": [ 1 ] }, { "name": "sex", "value": 1, "accessControlProfiles": [ 1 ] }, { "name": "height", "value": 170, "accessControlProfiles": [ 1 ] }, { "name": "weight", "value": 79, "accessControlProfiles": [ 1 ] }, { "name": "eye_colour", "value": "Blue", "accessControlProfiles": [ 1 ] }, { "name": "hair_colour", "value": "Gray", "accessControlProfiles": [ 1 ] }, { "name": "age_in_years", "value": 57, "accessControlProfiles": [ 1 ] }, { "name": "age_over_18", "value": true, "accessControlProfiles": [ 1 ] }, { "name": "age_over_21", "value": true, "accessControlProfiles": [ 1 ] }, { "name": "resident_address", "value": "1600 Amphitheatre Pkwy ", "accessControlProfiles": [ 1 ] }, { "name": "issuing_jurisdiction", "value": "US-CA", "accessControlProfiles": [ 1 ] }, { "name": "resident_city", "value": "Mountain View", "accessControlProfiles": [ 1 ] }, { "name": "resident_state", "value": "CA", "accessControlProfiles": [ 1 ] }, { "name": "resident_postal_code", "value": "94043", "accessControlProfiles": [ 1 ] }, { "name": "resident_country", "value": "US", "accessControlProfiles": [ 1 ] } ], "org.iso.18013.5.1.aamva": [ { "name": "DHS_compliance", "value": "F", "accessControlProfiles": [ 1 ] }, { "name": "domestic_driving_privileges", "value": [ { "domestic_vehicle_class": { "domestic_vehicle_class_code": "D", "domestic_vehicle_class_description": "Operator", "expiry_date": { "tag": 1004, "value": "2027-08-01" }, "issue_date": { "tag": 1004, "value": "2022-08-01" } }, "domestic_vehicle_restrictions": [ { "domestic_vehicle_restriction_code": "B", "domestic_vehicle_restriction_description": "Corrective lenses (also automated - vision screening)" } ] } ], "accessControlProfiles": [ 1 ] }, { "name": "aamva_version", "value": "1", "accessControlProfiles": [ 1 ] }, { "name": "family_name_truncation", "value": "N", "accessControlProfiles": [ 1 ] }, { "name": "given_name_truncation", "value": "N", "accessControlProfiles": [ 1 ] }, { "name": "organ_donor", "value": true, "accessControlProfiles": [ 1 ] } ] }, "accessControlProfiles": [ { "id": 1, "userAuthenticationRequired": true, "timeoutMillis": 10000 } ] }
Cet objet doit ensuite être encodé au format CBOR, chiffré, puis avec un encodage en base64. Si, dans l'environnement de test, les données ne sont pas chiffrées, elle doit être encodée au format CBOR, puis encodée en base64.
Notez que l'exemple ci-dessus est une carte CBOR non encodée, et non au format JSON. Si une chaîne JSON est codé en CBOR, il ne sera pas correctement analysé par l'appareil Android.
Objets de sécurité mobile
La norme ISO/IEC 18013-5 définit un objet de sécurité mobile (MSO, Mobile Security Object) pour garantir que le mDL les données ne sont pas falsifiées et qu'elles ont été émises par une autorité de confiance.
MSO contient les éléments suivants:
- Valeurs condensées: il s'agit de valeurs uniques générées pour chaque donnée. du Justificatif d'identité du mDL. Elles sont utilisées pour vérifier que les données n'ont pas ont changé depuis la signature du MSO.
- Clé de l'appareil: il s'agit d'une clé unique générée pour chaque appareil mobile. qui stocke l'Identifiant. Il est utilisé pour lier le MSO à l'appareil et pour pour empêcher son utilisation sur d'autres appareils.
- Informations sur la validité: elles incluent les dates de début et de fin le MSO est valide.
- Signature AI: il s'agit d'une signature numérique créée par l'autorité d'émission (IA) à l'aide de sa clé privée. Il permet de vérifier que le MSO a bien été émis par une autorité de confiance.
MSO possède la structure CCDL suivante:
MobileSecurityObjectBytes = #6.24(bstr .cbor MobileSecurityObject)
MobileSecurityObject = {
"digestAlgorithm" : tstr, ; Message digest algorithm used
"valueDigests" : ValueDigests, ; Array of digests of all data elements
"deviceKeyInfo" : DeviceKeyInfo,
"docType" : tstr, ; DocType as used in Documents
"validityInfo" : ValidityInfo
}
DeviceKeyInfo = {
"deviceKey" : DeviceKey
? "keyAuthorizations" : KeyAuthorizations,
? "keyInfo" : KeyInfo
}
DeviceKey = COSE_Key ; Device key in COSE_Key as defined in RFC 8152
KeyAuthorizations = {
? "nameSpaces" : AuthorizedNameSpaces
? "dataElements" : AuthorizedDataElements
}
AuthorizedNameSpaces = [+ NameSpace]
AuthorizedDataElements = {+ NameSpace => DataElementsArray}
DataElementsArray = [+ DataElementIdentifier]
KeyInfo = { * int => any} ; Positive integers are RFU, negative integers may be used for proprietary use
ValueDigests = {
"nameSpaces" : NameSpacesDigests
}
NameSpacesDigests = {
+ NameSpace => DigestIDs
}
DigestIDs = {
+ DigestID => Digest
}
ValidityInfo = {
"signed" : tdate,
"validFrom" : tdate,
"validUntil" : tdate,
? "expectedUpdate" : tdate
}
NameSpace = tstr ; NameSpace as used in IssuerSigned
DigestID = uint ; DigestID as used in IssuerSigDonnées d'authentification statiques
Les données d'authentification statiques, qui comprennent à la fois
digestIdMapping et issuerAuth doivent être créés par l'émetteur.
Le digestIdMapping d'un espace de noms spécifique se compose d'un tableau de
Instances IssuerSignedItem, chacune avec une valeur nulle pour la propriété elementValue.
De plus, le issuerAuth est généré en signant
MobileSecurityObjectBytes avec COSE_Sign1.
StaticAuthDataBytes = (bstr .cbor StaticAuthData) StaticAuthData = { "digestIdMapping" : DigestIdMapping, "issuerAuth" : IssuerAuth } DigestIdMapping = { NameSpace => [ + IssuerSignedItemBytes ] } ; Defined in ISO 18013-5 ; NameSpace = String DataElementIdentifier = String DigestID = uint IssuerAuth = COSE_Sign1 ; The payload is MobileSecurityObjectBytes IssuerSignedItemBytes = #6.24(bstr .cbor IssuerSignedItem) IssuerSignedItem = { "digestID" : uint, ; Digest ID for issuer data auth "random" : bstr, ; Random value for issuer data auth "elementIdentifier" : DataElementIdentifier, ; Data element identifier "elementValue" : DataElementValue ; Data element value }
Lors de l'appel de /provisionMobileSecurityObjects
le StaticAuthDataBytes est chiffré à l'aide de HPKE et transmis
dans la réponse.
Voici un exemple de code pour construire des MSO et des données d'authentification statiques.