Credencial de identidade
Os dispositivos Android usam a credencial de identidade para gerenciar as credenciais no dispositivo com segurança. A credencial de identidade oferece vários recursos de segurança que precisam ser usados pelo emissor para garantir que a integração deles com o Google seja o mais segura possível.
Valor de uso único assinado
A biblioteca de credenciais de identidade enfrenta um "desafio" (chamado nesta API de o valor de uso único) ao recuperar o certificado de identidade do dispositivo, enviado ao emissor no RegisterDeviceRequest. Esse valor de uso único é assinado e incorporado na extensão de atestado do dispositivo. certificado de identidade. Isso permite que o emissor tenha confiança no tempo para retorno do certificado e do atestado e se ele não está sendo reproduzido por um servidor no meio das comunicações.
Perfis de controle de acesso
Os perfis de controle de acesso são uma maneira do emissor especificar com precisão como quer que os dados armazenados na credencial de identidade sejam protegidos. O o emissor pode especificar se a autenticação do usuário é necessária para acessar os dados e quanto tempo o usuário tem para realizar a autenticação. Futuro (não atualmente disponível), casos de uso desse recurso incluem limitar quais leitores possam acessar o elemento de dados. Detalhes sobre como formatar o controle de acesso podem ser encontrados no formato de objeto credencial.
Comprovante de provisionamento
O objeto de prova de provisionamento é uma maneira dos emissores saberem que o a credencial foi armazenada na credencial de identidade. Um emissor precisa não emitir MSOs para uma credencial até que eles recebam e verifiquem o comprovante de na nuvem. Consulte a Identity Credential documentation (em inglês) para consultar mais informações sobre esse objeto.
Formatos de objeto
Cada um desses objetos é criptografado de ponta a ponta entre o dispositivo e o emissor. Como resultado, os servidores do Google não têm capacidade de normalizar esses objetos, e alguns deles podem estar em formatos diferentes dos o restante dos objetos da API. Por exemplo, a credencial é formatada em CBOR, JSON, porque é isso que é esperado no Android.
Credencial
A credencial contém os elementos de dados e como eles devem ser acessados. Ela
contém dois objetos principais, provisionedData e accessControlProfiles. O
provisionedData contém todos os namespaces relevantes para qualquer
tipo de credencial. Por exemplo, para a carteira de habilitação para dispositivos móveis, seria
org.iso.18013.5.1 e org.aamva.18013.5.1. As entradas e os valores de dados
dentro dos namespaces especificam os perfis de controle de acesso relevantes. Isso é
feito como uma lista de IDs, onde o ID corresponde a um perfil de controle de acesso no
na lista de accessControlProfiles. No exemplo abaixo, o [0] em cada dado
entrada refere-se ao perfil de controle de acesso com ID 0, não índice 0.
Veja abaixo o exemplo de um item de dados do mapa CBOR não codificado.
{ "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 } ] }
Esse objeto deve ser codificado no formato CBOR, criptografado e codificada em base64. No ambiente de teste e os dados não estão sendo criptografados, ela precisa ser codificada no formato CBOR e, em seguida, codificada em base64.
O exemplo acima é um mapa CBOR não codificado, não JSON. Se uma string JSON for codificado em CBOR, ele não será analisado corretamente pelo dispositivo Android.
Objetos de segurança para dispositivos móveis
A ISO/IEC 18013-5 define um objeto de segurança móvel (MSO, na sigla em inglês) para garantir que a mDL dados não sejam adulterados e que tenham sido emitidos por uma autoridade confiável.
O MSO contém o seguinte:
- Valores de resumo: são valores exclusivos gerados para cada dado na credencial da mDL. Elas são usadas para verificar se os dados não foram alterada desde que o MSO foi assinado.
- Chave do dispositivo: é uma chave exclusiva gerada para cada dispositivo móvel. que armazena a credencial. Ele é usado para vincular o MSO ao dispositivo e evitar que ele seja usado em outros dispositivos.
- Informações de validade: incluem as datas de início e término das quais o MSO é válido.
- Assinatura IA: é uma assinatura digital criada pela autoridade emissora (IA) usando sua chave privada. Ele é usado para verificar se o MSO foi emitido por uma autoridade confiável.
O MSO tem a seguinte estrutura 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 IssuerSigDados estáticos de autenticação
Os dados estáticos de autenticação, que compreendem
digestIdMapping e issuerAuth precisam ser construídos pelo emissor.
O digestIdMapping de um namespace específico consiste em uma matriz de
Instâncias de IssuerSignedItem, cada uma com um valor nulo para a propriedade elementValue.
Além disso, o issuerAuth é gerado assinando o
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 }
Após a invocação do /provisionMobileSecurityObjects
o StaticAuthDataBytes é criptografado usando HPKE e transmitido
como parte da resposta.
Confira exemplo de código para criar MSOs e dados de autenticação estática.