Anmeldedaten für Identität
Android-Geräte verwenden die Anmeldedaten für die Identität. um die Anmeldedaten auf dem Gerät sicher zu verwalten. Anmeldedaten für die Identität Die Bibliothek bietet eine Reihe von Sicherheitsfunktionen, die vom Aussteller verwendet werden sollten damit ihre Integration in Google so sicher wie möglich ist.
Signierte Nonce
Die Bibliothek „Identity Credential“ erfordert eine Challenge (in dieser API als Nonce) beim Abrufen des Zertifikats zur Geräteidentität, das an den Aussteller gesendet wird in RegisterDeviceRequest. Diese Nonce wird signiert und in die Attestierungserweiterung des Geräts eingebettet Identitätszertifikat. So kann der Aussteller auf die Aktualität vertrauen des Zertifikats und der Attestierung und dass es nicht von einem Server noch einmal wiedergegeben wird. mitten in der Kommunikation sind.
Zugriffskontrollprofile
Mit Zugriffssteuerungsprofilen kann der Aussteller genau angeben, die in „Identity Credential“ gespeicherten Daten geschützt werden sollen. Die Der Aussteller kann angeben, ob eine Nutzerauthentifizierung für den Zugriff auf die Daten erforderlich ist und wie lange der Nutzer eine Authentifizierung durchführen muss. Künftig (nicht derzeit unterstützt wird, können Sie mithilfe dieser Funktion einschränken, welche Leser auf das Datenelement zugreifen können. Details zum Formatieren der Zugriffssteuerung -Profile sind im Format des Anmeldedatenobjekts zu finden.
Bereitstellungsnachweis
Anhand des Objekts „Bereitstellungsnachweis“ wissen Aussteller, dass der Die Anmeldedaten wurden in „Identity Credential“ gespeichert. Ein Aussteller sollte MSOs erst dann für Berechtigungsnachweise ausstellen, wenn sie den Nutzerverwaltung. Weitere Informationen zu diesem Objekt findest du in der Dokumentation zu „Identity Credential“.
Objektformate
Jedes dieser Objekte wird zwischen Gerät und dem Aussteller. Daher können die Server von Google sich nicht normalisieren, und einige dieser Objekte können andere Formate haben als die der restlichen API-Objekte. Der Berechtigungsnachweis ist beispielsweise in CBOR formatiert und nicht als JSON, wie es auf Android-Ebene erwartet wird.
Anmeldedaten
Das Ausweisdokument enthält die Datenelemente und Informationen dazu, wie auf sie zugegriffen werden soll. Es
enthält die beiden primären Objekte provisionedData und accessControlProfiles. Die
provisionedData enthält alle Namespaces, die für den
Anmeldedatentyp ist. Für einen digitalen Führerschein wäre dies beispielsweise
org.iso.18013.5.1 und org.aamva.18013.5.1. Die Dateneinträge und -werte
innerhalb der Namespaces die relevanten Zugriffssteuerungsprofile angeben. Dies ist
Dabei handelt es sich um eine Liste von IDs, wobei die ID einem Zugriffssteuerungsprofil im
der accessControlProfiles-Liste. Im folgenden Beispiel ist der [0] in jedem Datenelement
bezieht sich auf das Zugriffssteuerungsprofil mit der ID 0, nicht auf den Index 0.
Im Folgenden finden Sie ein Beispiel für ein nicht codiertes CBOR-Zuordnungsdatenelement.
{ "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 } ] }
Dieses Objekt sollte dann im CBOR-Format codiert, verschlüsselt und base64-codiert. Sind die Daten in der Testumgebung nicht verschlüsselt, sollte sie im CBOR-Format und dann base64-codiert sein.
Beachten Sie, dass das obige Beispiel eine nicht codierte CBOR-Zuordnung und nicht eine JSON-Datei ist. Wenn ein JSON-String in CBOR codiert ist, wird es vom Android-Gerät nicht richtig geparst.
Mobile Sicherheitsobjekte
ISO/IEC 18013-5 definiert ein Mobile Security Object (MSO), das dafür sorgt, dass der mDL nicht manipuliert wurden und von einer vertrauenswürdigen Behörde ausgegeben wurden.
MSO enthält Folgendes:
- Digest-Werte: Dies sind eindeutige Werte, die für jede Daten generiert werden. -Element in den mDL-Anmeldedaten. Sie werden verwendet, um zu prüfen, ob die Daten seit der Unterzeichnung des MSO geändert wurde.
- Geräteschlüssel: Dies ist ein eindeutiger Schlüssel, der für jedes Mobilgerät generiert wird. in dem die Anmeldedaten gespeichert werden. Es wird verwendet, um das MSO an das Gerät zu binden verhindern, dass es auf anderen Geräten verwendet wird.
- Gültigkeitsinformationen: Dazu gehören das Start- und Enddatum, für das das MSO gültig ist.
- IA-Signatur: Dies ist eine digitale Signatur, die erstellt wird. von der ausstellenden Behörde (IA) mit ihrem privaten Schlüssel erstellt. Damit wird überprüft, ob das MSO von einer vertrauenswürdigen Behörde ausgestellt wurde.
MSO hat die folgende CCDL-Struktur:
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 IssuerSigStatische Auth-Daten
Die statischen Auth-Daten, die sowohl den
digestIdMapping und issuerAuth sollten vom Aussteller erstellt werden.
Die digestIdMapping für einen bestimmten Namespace besteht aus einem Array von
IssuerSignedItem-Instanzen mit jeweils einem Nullwert für das Attribut elementValue.
Außerdem wird die issuerAuth durch Signieren des
MobileSecurityObjectBytes mit 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 }
Beim Aufruf der /provisionMobileSecurityObjects
Endpunkt wird StaticAuthDataBytes mit HPKE verschlüsselt und
als Teil der Antwort.
Hier ist ein Codebeispiel für die Erstellung von MSOs und statischen Auth-Daten.