Credencial de identidad
Los dispositivos Android usan la Credencial de identidad. para administrar credenciales en el dispositivo de forma segura. La credencial de identidad La biblioteca ofrece varias funciones de seguridad que la entidad emisora debe usar para garantizar que su integración en Google sea lo más segura posible.
Nonce firmado
La biblioteca de Identity Credential presenta un “desafío” (denominada en esta API como el nonce) cuando se recupera el certificado de identidad del dispositivo que se envió a la entidad emisora en RegisterDeviceRequest. Este nonce está firmado y, además, incorporado en la extensión de certificación del dispositivo certificado de identidad. Esto permite que la entidad emisora confíe en las visitas recientes del certificado y la certificación, y de que ningún servidor los vuelva a reproducir en medio de las comunicaciones.
Perfiles de control de acceso
Los perfiles de control de acceso permiten que la entidad emisora especifique con precisión la forma queremos que se protejan los datos que se almacenan en la credencial de identidad. El la entidad emisora puede especificar si se requiere la autenticación del usuario para acceder a los datos y el tiempo que tiene el usuario para realizar la autenticación. Futuro (no los casos de uso de esta función incluyen la limitación de lectores los usuarios puedan acceder al elemento de datos. Detalles sobre cómo dar formato al control de acceso los perfiles en el formato del objeto Credencial.
Comprobante de aprovisionamiento
El objeto de prueba de aprovisionamiento permite a las entidades emisoras saber que las la credencial se almacenó correctamente en Credencial de identidad. Una entidad emisora debe no emitirán MSO para obtener una credencial hasta que reciban y verifiquen el comprobante de de servicios. Este objeto se documenta más en la documentación de credenciales de identidad.
Formatos de objeto
Cada uno de estos objetos está encriptado de extremo a extremo entre el dispositivo y la de la entidad emisora. En consecuencia, los servidores de Google no tienen la capacidad de normalizar estos objetos, y algunos de estos objetos pueden tener formatos diferentes a los del el resto de los objetos de la API. Por ejemplo, la Credencial tiene el formato CBOR, en lugar que JSON, ya que eso es lo que se espera a nivel de Android.
Credencial
La credencial contiene los elementos de datos y la forma en que se debe acceder a ellos. Integra
Contiene dos objetos principales, provisionedData y accessControlProfiles. El
provisionedData contiene todos los espacios de nombres relevantes para lo que sea que
el tipo de credencial. Por ejemplo, en el caso de las licencias de conducir para dispositivos móviles,
org.iso.18013.5.1 y org.aamva.18013.5.1. Los valores y las entradas de datos
Dentro de los espacios de nombres, especifica los perfiles de control de acceso relevantes. Este es
como una lista de IDs, donde el ID corresponde a un perfil de control de acceso en
la lista accessControlProfiles. En el siguiente ejemplo, el [0] de cada dato
se refiere al perfil de control de acceso con ID 0, no con el índice 0.
A continuación, se muestra un ejemplo de un elemento de datos del mapa CBOR sin codificación.
{ "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 } ] }
Este objeto debe codificarse en formato CBOR, encriptarse y, luego, codificado en base64. En el entorno de pruebas y los datos no están encriptados, debe codificarse en el formato CBOR y, luego, en Base64.
Ten en cuenta que el ejemplo anterior es un mapa CBOR sin codificación, no JSON. Si una cadena JSON está codificado en CBOR, el dispositivo Android no lo analizará correctamente.
Objetos de seguridad para dispositivos móviles
El estándar ISO/IEC 18013-5 define un objeto de seguridad para dispositivos móviles (Mobile Security Object, MSO) para garantizar que la Licencia de Conducir Digital (mDL). que los datos no están alterados y que fueron emitidos por una autoridad confiable.
MSO incluye lo siguiente:
- Valores de resumen: Son valores únicos que se generan para cada dato en la Credencial de Licencia de Conducir Digital. Se usan para verificar que los datos no desde que se firmó el MSO.
- Clave de dispositivo: Es una clave única que se genera para cada dispositivo móvil. que almacena la Credencial. Se usa para vincular el MSO al dispositivo y para para evitar que se use en otros dispositivos.
- Información de validez: Incluye las fechas de inicio y finalización de las de que el MSO sea válido.
- Firma IA: Es una firma digital que se crea por la autoridad emisora (IA) con su clave privada. Se utiliza para verificar que el MSO haya sido emitido por una autoridad confiable.
MSO tiene la siguiente estructura de CCDL:
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 IssuerSigDatos de autenticación estáticos
Los datos estáticos de autenticación, que comprenden las
La entidad emisora debe crear digestIdMapping y issuerAuth.
El digestIdMapping de un espacio de nombres específico consta de un array de
Instancias de IssuerSignedItem, cada una con un valor nulo para la propiedad elementValue
Además, issuerAuth se genera firmando el
MobileSecurityObjectBytes usando 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 }
Después de invocar /provisionMobileSecurityObjects
extremo, el StaticAuthDataBytes se encripta con HPKE y se transmite
como parte de la respuesta.
Este es un muestra de código para construir MSO y datos estáticos de autenticación.