شناسنامه
دستگاههای Android از کتابخانه Identity Credential برای مدیریت ایمن اعتبارنامهها در دستگاه استفاده میکنند. کتابخانه Identity Credential تعدادی از ویژگیهای امنیتی ارائه میدهد که باید توسط صادرکننده استفاده شود تا اطمینان حاصل شود که ادغام آنها با Google تا حد امکان امن است.
بدون امضا
کتابخانه Identity Credential هنگام بازیابی گواهی هویت دستگاه که برای صادرکننده در RegisterDeviceRequest ارسال میشود، یک « چالش » (که در این API به عنوان nonce نامیده میشود) انجام میدهد. این nonce امضا شده و در پسوند تصدیق شناسنامه دستگاه تعبیه شده است. این به صادرکننده اجازه میدهد تا به تازگی گواهی و گواهی اطمینان داشته باشد، و اینکه توسط سروری در وسط ارتباطات پخش نمیشود.
پروفایل های کنترل دسترسی
نمایههای کنترل دسترسی راهی برای صادرکننده است تا دقیقاً نحوه محافظت از دادههای ذخیره شده در Identity Credential را مشخص کند. صادرکننده میتواند مشخص کند که آیا برای دسترسی به عنصر داده به احراز هویت کاربر نیاز است یا خیر، و کاربر چقدر باید احراز هویت را انجام دهد. موارد استفاده آینده (در حال حاضر پشتیبانی نمی شود) از این ویژگی شامل محدود کردن خوانندگانی است که می توانند به عنصر داده دسترسی داشته باشند. جزئیات نحوه قالببندی پروفایلهای کنترل دسترسی را میتوانید در قالب شیء Credential پیدا کنید.
اثبات تامین
اثبات شیء تأمین راهی برای صادرکنندگان است که بدانند اعتبارنامه با موفقیت در Identity Credential ذخیره شده است. صادرکننده نباید MSO برای اعتبار صادر کند تا زمانی که مدرک ارائه را دریافت و تأیید کند. این شی بیشتر در مستندات هویت هویت مستند شده است.
فرمت های شی
هر یک از این اشیا بین دستگاه و صادرکننده رمزگذاری شده اند. در نتیجه سرورهای گوگل قابلیت عادی سازی این اشیاء را ندارند و ممکن است برخی از این اشیا در قالب های متفاوتی نسبت به بقیه اشیاء API باشند. به عنوان مثال، Credential به جای JSON در CBOR فرمت شده است، زیرا این چیزی است که در سطح Android انتظار می رود.
اعتبارنامه
اعتبار شامل عناصر داده و نحوه دسترسی به آنها است. این شامل دو شی اصلی، provisionedData و accessControlProfiles است. provisionedData شامل تمام فضاهای نام مربوط به هر نوع اعتباری است. به عنوان مثال، برای گواهینامه رانندگی تلفن همراه، این org.iso.18013.5.1 و org.aamva.18013.5.1 خواهد بود. ورودی های داده و مقادیر داخل فضاهای نام، پروفایل های کنترل دسترسی مربوطه را مشخص می کنند. این به عنوان لیستی از شناسه ها انجام می شود، جایی که شناسه مربوط به نمایه کنترل دسترسی در لیست accessControlProfiles است. در مثال زیر، [0] در هر ورودی داده به نمایه کنترل دسترسی با شناسه 0 اشاره دارد، نه شاخص 0.
در زیر نمونه ای از یک آیتم داده نقشه 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 } ] }
سپس این شیء باید در قالب CBOR کدگذاری شود، رمزگذاری شود و سپس base64 کدگذاری شود. اگر در محیط تست، و داده ها رمزگذاری نمی شوند، باید با فرمت CBOR کدگذاری شوند و سپس base64 کدگذاری شوند.
توجه داشته باشید که مثال بالا یک نقشه CBOR رمزگذاری نشده است، نه JSON. اگر یک رشته JSON در CBOR کدگذاری شود، توسط دستگاه Android به درستی تجزیه نمی شود.
اشیاء امنیتی موبایل
ISO/IEC 18013-5 یک شیء امنیتی موبایل (MSO) را تعریف می کند تا اطمینان حاصل شود که داده های mDL دستکاری نشده و توسط یک مرجع قابل اعتماد صادر شده است.
MSO شامل موارد زیر است:
- مقادیر خلاصه : این مقادیر منحصر به فردی هستند که برای هر عنصر داده در اعتبار mDL ایجاد می شوند. از آنها برای تأیید عدم تغییر داده ها از زمان امضای MSO استفاده می شود.
- کلید دستگاه : این یک کلید منحصر به فرد است که برای هر دستگاه تلفن همراهی که اعتبارنامه را ذخیره می کند تولید می شود. برای اتصال MSO به دستگاه و جلوگیری از استفاده از آن در دستگاه های دیگر استفاده می شود.
- اطلاعات اعتبار : این شامل تاریخ شروع و پایانی است که MSO برای آنها معتبر است.
- امضای IA : این یک امضای دیجیتالی است که توسط مرجع صادرکننده (IA) با استفاده از کلید خصوصی آن ایجاد میشود. برای تأیید اینکه MSO توسط یک مرجع مورد اعتماد صادر شده است استفاده می شود.
MSO دارای ساختار 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 IssuerSigداده های تأیید استاتیک
Static Auth Data که شامل digestIdMapping و issuerAuth است، باید توسط صادرکننده ساخته شود.
digestIdMapping برای یک فضای نام خاص شامل آرایهای از نمونههای IssuerSignedItem است که هر کدام یک مقدار تهی برای ویژگی elementValue دارد. علاوه بر این، issuerAuth با امضای MobileSecurityObjectBytes با استفاده از 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 }
پس از فراخوانی نقطه پایانی /provisionMobileSecurityObjects ، StaticAuthDataBytes با استفاده از HPKE رمزگذاری شده و به عنوان بخشی از پاسخ ارسال می شود.
در اینجا یک نمونه کد برای ساخت MSOs و Static Auth Data آورده شده است.