Dane logowania
Urządzenia z Androidem korzystają z danych logowania tożsamości. do bezpiecznego zarządzania danymi logowania na urządzeniu. Dane uwierzytelniające tożsamość oferuje szereg funkcji zabezpieczeń, które powinien wykorzystać wydawca .
Podpisana liczba jednorazowa
Biblioteka danych logowania do tożsamości przyjmuje „test zabezpieczający” (w tym interfejsie API określany jako wartość jednorazową) podczas pobierania certyfikatu tożsamości urządzenia wysłanego do wystawcy w parametrze RegisterDeviceRequest. Ta wartość jednorazowa jest podpisana i umieszczona w rozszerzeniu atestu urządzenia certyfikat tożsamości. Dzięki temu wydawca może mieć pewność co do aktualności certyfikatu i atestu oraz że nie jest on ponownie odtwarzany przez serwer w środku komunikacji.
Profile kontroli dostępu
Profile kontroli dostępu umożliwiają wydawcy precyzyjne określenie, chcą chronić dane przechowywane w Dokumentach tożsamości. wydawca może określić, czy dostęp do danych wymaga uwierzytelniania użytkownika , a także czas, jaki użytkownik ma na przeprowadzenie uwierzytelniania. Przyszły (nie obecnie obsługiwane) przypadki użycia tej funkcji obejmują ograniczenie liczby czytelników nie mają dostępu do elementu danych. Szczegółowe informacje o formatowaniu kontroli dostępu profile można znaleźć w formacie obiektów danych logowania.
Dowód obsługi administracyjnej
Obiekt potwierdzenia obsługi administracyjnej pozwala wydawcom dowiedzieć się, że Dane logowania zostały zapisane w danych logowania tożsamości. Wydawca powinien nie może wystawiać MSO w celu uzyskania poświadczeń, dopóki nie otrzymają i nie zweryfikujemy i udostępnianie danych. Więcej informacji na temat tego obiektu znajdziesz w dokumentacji danych uwierzytelniających tożsamości.
Formaty obiektów
Każdy z tych obiektów jest w pełni szyfrowany między urządzeniem a wystawcy. W efekcie serwery Google nie mają możliwości normalizacji. i niektóre z nich mogą mieć inny format niż pozostałych obiektów API. Na przykład dokument jest sformatowany w CBOR, niż JSON, ponieważ jest to oczekiwane na poziomie Androida.
Dane logowania
Dane logowania zawierają elementy danych oraz sposób uzyskania do nich dostępu. it
zawiera dwa główne obiekty: provisionedData i accessControlProfiles.
provisionedData zawiera wszystkie przestrzenie nazw powiązane z
typ danych logowania to. Na przykład w przypadku prawa jazdy mobilnego będzie to
org.iso.18013.5.1 i org.aamva.18013.5.1. Wpisy i wartości danych
wewnątrz przestrzeni nazw określ odpowiednie profile kontroli dostępu. To jest
w postaci listy identyfikatorów, gdzie identyfikator odpowiada profilowi kontroli dostępu
listę accessControlProfiles. W poniższym przykładzie parametry [0] w każdym z tych danych
wpis odnosi się do profilu kontroli dostępu o identyfikatorze 0, a nie o indeksie 0.
Poniżej znajduje się przykład niezakodowanego elementu danych mapy CBOR.
{ "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 } ] }
Obiekt powinien być zakodowany w formacie CBOR, zaszyfrowany, a następnie z kodowaniem base64. Jeśli w środowisku testowym dane nie są szyfrowane, powinien być zakodowany w formacie CBOR, a następnie w formacie base64.
Powyższy przykład to niezakodowana mapa CBOR, a nie plik JSON. Jeśli ciąg JSON zakodowany w formacie CBOR nie zostanie prawidłowo przeanalizowany przez urządzenie z Androidem.
Obiekty zabezpieczeń urządzeń mobilnych
ISO/IEC 18013-5 definiuje obiekt zabezpieczeń mobilnych (MSO), by zapewnić, że mDL że zostały one wydane przez zaufany urząd.
MSO zawiera następujące elementy:
- Wartości zbiorcze: to niepowtarzalne wartości generowane dla poszczególnych danych. danych logowania mDL. Służą one do sprawdzenia, czy dane nie zostały zmieniono od czasu podpisania MSO.
- Klucz urządzenia: unikalny klucz generowany dla każdego urządzenia mobilnego. w którym są przechowywane dane uwierzytelniające. Służy do powiązania MSO z urządzeniem oraz uniemożliwiać korzystanie z niej na innych urządzeniach.
- Informacje o prawidłowości: obejmuje daty rozpoczęcia i zakończenia, dla których MSO jest prawidłowe.
- Podpis IA: jest to podpis cyfrowy generowany. przez urząd wydający (IA) za pomocą swojego klucza prywatnego. Służy do sprawdzania, czy MSO zostało wydane przez zaufany organ.
MSO ma następującą strukturę 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 IssuerSigStatyczne dane uwierzytelniania
Statyczne dane uwierzytelniania, na które składają się
digestIdMapping i issuerAuth powinny być tworzone przez wydawcę.
Element digestIdMapping określonej przestrzeni nazw składa się z tablicy
IssuerSignedItem instancji, z których każda ma wartość zerową dla właściwości elementValue.
issuerAuth jest też generowany przez podpisanie
MobileSecurityObjectBytes za pomocą: 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 }
Po wywołaniu /provisionMobileSecurityObjects
StaticAuthDataBytes jest szyfrowany przy użyciu HPKE i przesyłany
jako część odpowiedzi.
Oto przykładowy kod do tworzenia MSO i statycznych danych uwierzytelniania.