Google работи върху сигурното съхраняване на цифровите шофьорски книжки в Android

click fraud protection

Android R може да поддържа сигурно съхраняване на мобилни шофьорски книжки на устройства като Google Pixel 2, Google Pixel 3 или Google Pixel 4.

Актуализация 1 (3/6/19 @ 20:44 ET): Повече подробности за плановете на Google за IdentityCredential API бяха споделени от Шон Уилдън, ръководител на екипа за сигурност, поддържан от Android. Статията е актуализирана с тези подробности в края. Следва оригиналната статия.

Носенето на портфейл стана по-малко необходимост за мен, откакто започнах да го използвам Google Pay да управлявам кредитните си карти, но все още няма начин да пътувам навсякъде без шофьорската си книжка. Познавам няколко души, които използват калъфи за портфейли, за да държат няколко карти, които имат трябва да продължете тяхното лице, но чакам деня, когато мога законно да карам до Walmart само с телефона си. Дигиталната шофьорска книжка предлага множество предимства пред традиционната лична карта. Не можете да го загубите, можете да го актуализирате дистанционно, така че да не се налага да се редите на опашка в DMV, можете да го изтриете дистанционно, ако телефонът ви бъде откраднат, по-малко вероятно е да получите вашата самоличност откраднат, тъй като не е необходимо да носите портфейл с леснодостъпна информация, по-малко вероятно е да оставите телефона си у дома и ще имате по-лесно време да го изведете искане. Властите в САЩ бавно признават предимствата на мобилната шофьорска книжка, поради което чуваме, че все повече американски щати тестват приемането им всяка година.

Например жителите на Луизиана могат да изтеглят Envoc-разработена LA Портфейл приложение, което е одобрено от правоприлагащите органи на Лос Анджелис за проверка на лиценза и ATC на LA за сделки с алкохол и тютюневи изделия. Проверката на възрастта е особено интересна, тъй като потребителите могат да ограничат мобилното приложение да показва само необходимата информация на продавач на алкохол или тютюн. Другаде, компания за цифрова сигурност Джемалто си партнира с Колорадо, Айдахо, Мериленд, Вашингтон и Уайоминг, за да стартира пилотни програми, преди да пусне своето решение за цифрова шофьорска книжка. В същото време, Американската асоциация на администраторите на моторни превозни средства работи за стандартизиране на тази нова форма на електронна идентификация.

Примерно изображение на цифрова шофьорска книжка, достъпна чрез приложението LA Wallet. Източник: Envoc

Има обаче недостатъци на цифровата шофьорска книжка. Имате голям контрол върху това кой може да види вашия физически документ за самоличност, но имате по-малко контрол върху това кой или Какво има достъп до неговата цифровизирана форма. Можете да защитите с парола или ПИН код телефона си или приложението, което изтегля мобилния ви лиценз, но винаги има шанс телефонът ви и всичките му данни да бъдат компрометирани. Плюс това, трябва да се уверите, че телефонът ви има достатъчно сок, за да поддържа Android да работи, за да можете да изтеглите лиценза. С IdentityCredential API, Google работи за разрешаването на двата проблема. В бъдеща версия на Android, може би Android R, устройства с правилния хардуер ще могат да съхраняват сигурно идентификационни карти, особено цифрови шофьорски книжки, и дори достъп до тях, когато устройството няма достатъчно енергия за зареждане на Android.

IdentityCredential API

На пръв поглед ангажиментът, изпратен от Шон Уилдън, ръководител на екипа на Android за хардуерно хранилище за ключове, не изглежда много интересен. Въпреки това, ако прегледате файловете IdentityCredential и IdentityCredentialStore, ще намерите множество препратки към какви видове „идентификационни данни“ се отнася Google. Например IdentityCredential използва протокол за обмен на ключове, който се „използва от ISO18013-5 стандарт за мобилни шофьорски книжки." Освен това този протокол се използва като „основа за текущата работа по ISO други стандартизирани идентификационни данни." Въпреки че е малко вероятно скоро да видим мобилни паспорти, ясно е, че този API е предназначен за нещо повече от мобилни шофьорски книжки.

Задълбочавайки се, Google разработва типовете ключове за подписване, поддържани от API на IdentityCredential. Има два вида удостоверяване на данни: статично и динамично. Статичното удостоверяване включва ключове, създадени от издаващия орган, докато динамичното удостоверяване включва ключове, създадени от защитния хардуер на устройството (като Титан М в Pixel 3 и Pixel 3 XL.) Предимството на динамичното удостоверяване е, че е по-трудно за нападателя да компрометира защитения хардуер, за да копира идентификационните данни на друго устройство. Освен това, динамичното удостоверяване прави по-трудно свързването на определени идентификационни данни с данните на потребителя.

Приложение за Android може да представи IdentityCredential на четец, като поиска от потребителя да инициира безжична връзка чрез NFC. Препоръчва се приложенията да пазят тези транзакции, като изискват разрешение от потребителя под формата на диалогов прозорец и/или защита с парола.

Ако дадено устройство има поддържания хардуер, режимът „директен достъп“ ще бъде наличен, за да позволи представянето на IdentityCredential, дори ако няма достатъчно енергия, за да поддържа Android да работи. Това е възможно само когато устройството има отделен защитен хардуер и достатъчно мощност, за да работи с този хардуер, за да сподели идентификационните данни през NFC. Устройства като Google Pixel 2 и Google Pixel 3 трябва да отговарят на изискванията, тъй като и двете устройства имат модули за сигурност, устойчиви на манипулации които са отделни от основния SoC.

Ако устройството няма отделен защитен процесор, то все още може да поддържа IdentityCredential API, макар и без поддръжка за директен достъп. Ако хранилището за идентификационни данни е внедрено само в софтуера, то може да бъде компрометирано от атака срещу ядрото. Ако хранилището за идентификационни данни е внедрено в TEE, то може да бъде компрометирано от странични канални атаки на процесора, като напр. Meltdown и Spectre. Ако хранилището за идентификационни данни е внедрено в отделен процесор, вграден в същия пакет като основния CPU, той е устойчив на физически хардуерни атаки, но не може да се захранва, без да се захранва и основното ПРОЦЕСОР.

Чувствителността на документа ще определи дали едно или повече от тези реализации на хранилище за идентификационни данни ще бъдат поддържани. Разработчиците могат да проверят сертификата за сигурност на внедряването на магазина за идентификационни данни. Реализациите на хранилище за идентификационни данни за самоличност могат да бъдат несертифицирани или да имат ниво на гаранция за оценка от 4 или по-високо. EAL казва на разработчиците на приложения колко сигурно е внедряването срещу потенциални атаки.

Както споменах преди, Google възнамерява този API да се използва за всеки стандартизиран тип документ, въпреки че те изброяват мобилни шофьорски книжки ISO 18013 като пример. Типът документ е необходим, така че защитният хардуер да знае какъв тип идентификационни данни е в случай режимът на директен достъп трябва да се поддържа и да позволява на приложенията да знаят какъв тип документ е четецът искане.

Това е цялата информация, която имаме досега за този нов API. Тъй като сме толкова близо до пускането на първия Android Q Developer Preview, не мисля, че е вероятно да видим поддръжка за сигурно съхраняване на мобилни шофьорски книжки в Android Q. Въпреки това, този API може да бъде готов до момента, в който Android R излезе през 2020 г. Google Pixel 2, Google Pixel 3 и предстоящият Google Pixel 4 трябва да поддържат този API с режим на директен достъп в Android R, благодарение на наличието на необходимия отделен защитен процесор. Ще ви уведомим, ако научим повече информация за това какво възнамерява да прави Google с този API.


Актуализация 1: Повече подробности за API на IdentityCredential

Shawn Willden, авторът на IdentityCredential API ангажимента, сподели допълнителни подробности за API в секциите за коментари. Той отговори на няколко коментара от потребители, които ще възпроизведем по-долу:

Потребителят Munnimi заяви:

„И когато полицията вземе телефона ви и отиде до полицейската кола, те могат да проверят какво има в телефона.“

Г-н Уилдън отговори:

„Това е нещо, което конкретно работя, за да направя невъзможно. Намерението е да структурирате потока, така че служителят да не може полезно да вземе телефона ви. Идеята е да докоснете NFC с телефона на служителя, след това да отключите с пръстов отпечатък/парола, след което телефонът ви да премине в режим на заключване, докато данните се прехвърлят през bluetooth/Wifi. Режимът на заключване означава, че удостоверяването с пръстов отпечатък няма да го отключи, изисква се парола. Това е специално за да се принуди позоваването на петата поправка за защита срещу самоуличаване, което някои съдилища са установили, че не попречи на полицията да ви принуди да отключите с биометрични данни, но всички са съгласни, че не им позволява да ви принудят да дадете паролата си (поне в Съединените Щати).

Имайте предвид, че това е стремеж, а не ангажимент. Начините, по които можем да наложим потока върху разработчиците на приложения за самоличност, са ограничени, защото ако отидем твърде далеч, те могат просто изберете да не използвате нашите API. Но това, което можем да направим, е да ги улесним да направят правилните, чувствителни към поверителността, нещо."

Потребителят RobboW заяви:

„Това е безполезно в Австралия. От нас се изисква да имаме нашата физическа, официална шофьорска книжка с нас, докато шофираме. Цифровото копие просто е подходящо за кражба на самоличност."

Г-н Уилдън отговори:

„Австралия е активен участник в комисията по ISO 18013-5 и е много заинтересована от подкрепата за мобилни шофьорски книжки. Що се отнася до кражбата на самоличност, има много защити срещу това да бъдат вградени. Статията споменава някои от тях."

Потребителят solitarios.lupus заяви:

„Като се има предвид какво прави този сайт, мисля, че всеки тук знае, че това няма да работи и е огромен проблем със сигурността за правоприлагащите органи. Лесно да се фалшифицира, фалшифицира и манипулира."

Г-н Уилдън отговори:

„Откровеното фалшифициране ще бъде почти невъзможно, тъй като всички данни са цифрово подписани. Подправянето на идентификационни данни ще изисква фалшифициране на цифровия подпис, което или изисква радикално прекъсване на съответния криптография (което би нарушило TLS и почти всичко останало) или в противен случай кражба на подписа на издаващия орган ключове. Дори промяна, като вземете някои подписани елементи от данни от един DL (напр. рождена дата, показваща, че сте над 21 години) и някои от друг (напр. вашата истинска снимка) ще бъде невъзможно, тъй като подписването обхваща целия документ, обвързвайки всички елементи заедно."

Марката на потребителя заяви:

„Ако фотокопието никога не е било валидно за лична карта, защо разговорът по телефона има значение? Дори ако Google обещае да го направи защитено, как това ще спре някой да покаже фалшиво приложение?

И все пак, дори и да няма отговори на това, аз все още смятам, че е добре поради причините, посочени в тази статия. Бих го искал за паспорти - не непременно за пътуване, но други случаи, когато е необходим документ за самоличност (не шофирам, така че паспортът ми е единственият ми документ за самоличност).

Разбира се, бих го предпочел, ако Обединеното кралство не се превръщаше в общество на „документи, моля“, където в някои случаи трябва да имате сканиран паспорт дори само за да отидете в кръчма...“

Г-н Уилдън отговори:

„Цифровите подписи ще го направят сигурен. Можете да имате фалшиво приложение, но то не може да генерира правилно подписани данни.

Между другото, паспортите също са много важни за тази работа. Шофьорските книжки са отправната точка, но протоколите и инфраструктурата са внимателно проектирани, за да поддържат широк набор от идентификационни данни, по-специално включително паспорти. Разбира се, ще трябва да убедим ICAO да приеме подхода, но мисля, че това е много вероятно."


Благодарение на XDA Recognized Developer luca020400 за върха!