Carding 4 Carders
Professional
- Messages
- 2,724
- Reaction score
- 1,586
- Points
- 113
Мы полагались на нашу способность идентифицировать людей и предметы на протяжении сотен тысяч лет, с момента появления нашего вида и до. То, как вы выглядите, как вы ведете себя, как вы общаетесь - все то, что делает вас внутренне собой, - используется другими, чтобы идентифицировать вас. После того, как вы идентифицированы, вам могут доверять или, в действительности, вас могут определить как личность, которой нельзя доверять. Но само отождествление должно быть на первом месте.
Это работает только тогда, когда есть уже существующие отношения, которые, конечно же, можно использовать для получения знаний, используемых для идентификации. Когда вам нужно идентифицировать себя перед кем-то другим, с кем-то, кого вы никогда не встречали, мы исторически полагались на документы, фотографии, подробности и информацию о вас и вашем прошлом. Люди будут путешествовать с рекомендательными письмами или даже с другим человеком - буквально доверенным третьим лицом - чтобы помочь другим идентифицировать себя.
В настоящее время мир, в котором живет и работает большинство людей, намного больше, сложнее и взаимосвязан, поэтому мы создали учреждения и службы, которые могут выступать в качестве доверенных третьих сторон, чтобы идентифицировать людей или одобрять доверенные документы, чтобы сделать это вместо них. Паспорта и водительские права являются примерами этих типов удостоверяющих личность документов по доверенности, предоставляющих полезность в качестве систем идентификации общего назначения, существенно расширяющих их назначение за пределы их первоначальной компетенции. До недавнего времени эти типы идентификационных систем были полностью физическими - в значительной степени просто обновленными версиями старого рекомендательного письма.
Однако этот тип чисто физических систем часто можно легко воспроизвести, и в течение последнего десятилетия или около того мы видели введение электронных паспортов и водительских прав, которые сочетают в себе функции физической безопасности традиционного паспорта с функциями логической безопасности. такие как криптографические подписи и внутренняя обработка. Теперь мы переходим в мир коммерциализации - платежей, технологий и идентичности - и это приводит к тому, что наши документы также переводятся в цифровую форму в мобильные реализации.
В этом посте я конкретно расскажу о лицензиях мобильных драйверов (mDL) - что это такое, как работает и что это значит для тех, кто их использует и хочет их развернуть. На момент написания стандарт ISO для mDL (ISO18013-5) еще не совсем готов, но UL уже некоторое время является ключевым участником и участником рабочей группы ISO. Хотя это и работа, которую мы проделали с некоторыми из первых пользователей mDL, у нас есть уникальный контекст и опыт, которыми мы можем поделиться.
mDL - версия TL; DR
Итак, что такое «мобильные» водительские права и как они работают? Что ж, это не обязательно то же самое, что и лицензии, к которым вы привыкли ... Традиционные водительские лицензии полагаются на физическую реализацию для обеспечения безопасности с помощью голограмм на пластике, определенных наложений изображений, возможно, даже физического чипа в карте и т. Д. быть подтвержденным лицом, проверяющим идентификатор, что помогает предотвратить подделки и модификации.
Водительское удостоверение мобильного телефона, напротив, представляет собой цифровую версию этих документов, удостоверяющих личность; хранится и внедряется в коммерческую готовую систему (COTS), такую как мобильный телефон - отсюда и буква «m» в mDL. Потому что мобильная лицензия не имеет физического аспекта и не может полагаться на функции физической безопасности. Вместо использования лица, просматривающего физическую сущность лицензии для ее аутентификации, mDL должен полагаться на использование отдельного «считывателя», который подключается к экземпляру mDL для аутентификации логических аспектов реализации.
Подключения могут осуществляться с помощью различных технологий - NFC, BLE, WiFi, оптических и т. д. - и с применением криптографии для обеспечения конфиденциальности и аутентичности передаваемых данных.
Я знаю тебя. Я знаю все о тебе
Мы уже отмечали, что идентификация может работать только в том случае, если есть уже существующие отношения или какая-либо доверенная третья сторона, а в случае ваших физических водительских прав это ваша местная версия Департамента транспортных средств, какое-то государственное учреждение, уполномоченное проверять который:
Когда mDL может быть запущен удаленно, он должен полагаться на наличие существующей физической лицензии, чтобы действовать как корень доверия для идентификации пользователя. Пользователь обычно фотографирует эту существующую лицензию на свой телефон, затем делает селфи в качестве доказательства своей личности, и оба этих снимка используются для подтверждения действительности существующей лицензии и права собственности на эту лицензию текущим. пользователь мобильного телефона.
Конечно, безопасность, реализованная на этом этапе, очень важна, поскольку это устанавливает владельца всех данных, которые впоследствии будут предоставлены мобильному устройству. Однако этот этап намеренно не охвачен действующим стандартом ISO для лицензий для мобильных драйверов, поскольку он входит в новый стандарт, над которым надлежит работать в течение следующих нескольких лет - ISO 23220.
Это текущее отсутствие ясности в отношении выпуска и предоставления мобильных лицензий обеспечивает гибкость для внедрения, но также несет с собой сложность и риски. Большинство случаев мошенничества с мобильными платежами происходит на этапе оцифровки, когда преступники обходят плохо реализованные средства контроля на этапе идентификации и проверки. При развертывании реализаций лицензий для мобильных водителей выясняется, как обеспечивается безопасность в отношении реализации этой идентификации и проверки, эффективность любого используемого биометрического сопоставления, использование метаданных, таких как геолокация, способ реализации механизмов отката или увеличения масштаба при сбое технологии или риски считаются слишком высокими для автоматического сопоставления - все эти вещи (и многое другое!) должны быть тщательно продуманы и протестированы.
Sacnner Darkly
В предыдущем разделе я отмечал, что для проверки лицензии мобильных водителей требуется использование считывающего устройства. Конечно, вы можете просто «взглянуть» на такую лицензию, и вы увидите, что представляет собой изображение традиционной физической лицензии. Однако такой образ - это всего лишь образ. Даже с дополнительной защитой, такой как движущиеся изображения водителя, эффекты движения или искажения, реализуемые при прикосновении к лицензионному изображению, действительность мобильной лицензии действительно может быть подтверждена только при использовании отдельного компонента или системы считывателя.
Здесь снова можно провести параллель с платежами. Когда вы используете платежную карту, эта карта больше не проверяется только физическими средствами - данные на магнитной полосе карты или данные на внутреннем чипе карты используются для того, чтобы карта могла быть проверена другими сторонами (терминал, приобретатель, Эмитент). Это связано с тем, что физические аспекты платежных карт легко «клонировать» или копировать, поэтому простого физического исследования самой карты недостаточно. Даже проверки чисто статических данных, таких как данные на магнитной полосе карты или считываемые компьютером штрих-коды, часто бывает недостаточно, поскольку их также можно легко скопировать с одной карты на другую.
Точно так же, как у нас есть платежные терминалы для считывания и проверки данных на платежных картах, нам нужны считыватели mDL, чтобы делать то же самое с лицензиями мобильных водителей. Ограничивает ли это полезность MDL по сравнению с традиционной лицензией? Возможно, в некотором роде - но это также может сделать их более безопасными. Задача состоит в том, чтобы реализовать системы чтения наиболее легко развертываемым и совместимым образом, возможно, путем предоставления веб-интерфейсов API или бесплатной загрузки приложений для распространенных мобильных операционных систем.
Ниже приводится иллюстрация компонентов высокого уровня и соединений системы MDL.
Важно, чтобы безопасность этих систем чтения и серверной части также была проверена, чтобы гарантировать правильную и безопасную настройку всей экосистемы. Возможно, вам захочется иметь разные типы читателей для разных уровней уверенности; Если MDL проверяется на соответствие возрасту в кинотеатре, это явно другой профиль риска, чем если бы он проверялся при пересечении границы или полицией. Реализованные считыватели могут аналогичным образом обеспечивать различные уровни уверенности и безопасности для фактического процесса чтения, например, вероятно, полиции потребуется специальная система проверки лицензии или что вы захотите провести дополнительные проверки систем COTS, используемых такими организациями. если не используются специальные читатели.
Обучение тому, как правильно использовать и проверять mDL, также важно; Вы же не хотите, чтобы люди использовали просто изображение MDL для идентификатора, например, при создании банковского счета!
Шшш… Это секрет!
Использование устройства COTS в качестве основы для функций лицензирования мобильных водителей - отличный способ обеспечить максимальный охват технологии, но оно создает сложности, когда дело доходит до безопасности данных и обработки, используемых как mDL, так и любыми COTS-системами. читатели. На этапе идентификации и проверки владелец лицензии идентифицирует себя для серверной части управляющего органа, и ему назначаются («предоставляются») некоторые конкретные данные, которые помогают однозначно идентифицировать это устройство COTS и привязать экземпляр приложения к личности пользователя. Без защиты эти данные могут быть скопированы на другой телефон, по сути копируя или «клонируя» мобильную лицензию. Хуже того, он может быть изменен при транспортировке или хранении перед использованием,
Не поймите меня неправильно, безопасность современных операционных систем COTS действительно хороша. Полностью пропатченное и обновленное устройство Android или iOS - один из самых безопасных коммерческих продуктов, которые вы можете купить. Однако при развертывании mDL вы, вероятно, не захотите ограничивать область действия только самыми последними и полностью исправленными устройствами, поскольку это значительно ограничит объем развертывания. См. Приведенный ниже график распределения версий Android с течением времени (собранный с веб-сайта распространения Google Android https://developer.android.com/about/dashboards и красиво отображенный на этом графике ниже по адресу https://www.bidouille.org/misc / androidcharts). Это показывает, как долго старые версии Android могут оставаться на рынке, даже если они могут быть устаревшими на несколько версий.
Проблема, конечно, в том, что вы не можете поддерживать все исторические версии, потому что независимо от того, насколько безопасной может быть новая или обновленная система на момент ее первоначального выпуска, старые и обновленные COTS-устройства, приложения или операционные системы могут быть весьма небезопасными ...
Таким образом, необходимо принять решение о том, какой минимальный уровень устройства или операционной системы вы примете для развертывания вашей реализации mDL. Любое такое решение также подразумевает необходимость периодического обновления принятых платформ COTS, поскольку то, что ранее считалось приемлемым, становится слишком старым и небезопасным для дальнейшего использования, поскольку время продолжает обнаруживать ранее неизвестные уязвимости.
Как вы собираетесь принимать эти решения? Как вы собираетесь сообщить существующим держателям мобильных лицензий, что они должны либо обновить свой телефон, либо отозвать свой mDL? Какой уровень безопасности требуется для вашей реализации и как вы собираетесь проверить правильность его реализации на всех устройствах, на которых развернут mDL?
Например, потребуется ли вам, чтобы mDL изолировал важные операции в логически отдельной Trusted Execution Environment (TEE) или выделенном процессоре безопасности, что ограничит тип поддерживаемых устройств и способ их развертывания? Или вас устраивает, что приложение и данные защищены в «богатой» операционной системе Android или iOS, если вы можете обеспечить определенный уровень безопасности? Как вы собираетесь определять и проверять тот уровень безопасности, который должен применяться, и какие данные у вас есть или следует использовать, чтобы принять это решение?
Как и во многих других случаях, необходимо сделать выбор между областью действия, совместимостью и безопасностью, и часто это игра с нулевой суммой, когда выбор в одном направлении влияет на выбор, который вы можете сделать в другом.
Мой бэкэнд выглядит в этом уязвимым?
В предыдущих обсуждениях использования и безопасности лицензий на мобильные драйверы мы обсуждали, что считыватель и сам mDL подключаются к серверной системе; но как именно это реализовано, остается на усмотрение разработчика. Часто будут использоваться общие протоколы безопасности, такие как TLS, что является хорошей идеей, но не менее важна точная конфигурация - какие шифровальные комплекты, какие версии, как управлять сертификатами и т.д.?
В последнем разделе мы обсудили безопасность хранения предоставленных данных, и здесь нам необходимо рассмотреть безопасность связи, которая также подразумевает проблему начальной загрузки. Если вы доставляете данные инициализации в mDL впервые, это, по сути, «ванильное» приложение - как и любое другое приложение mDL этого типа, которое было загружено из магазина приложений. До первого шага процесса подготовки уникальные данные для какого-либо приложения отсутствуют. Как вы затем идентифицируете и аутентифицируете приложение для начальной подготовки, чтобы предотвратить атаки «посередине», когда злоумышленник может находиться между подлинным приложением и серверной частью для сбора или изменения отправленных данных? Как вы определяете используемую платформу и систему, человека, запрашивающего данные лицензии?
Поскольку мобильные операционные системы становятся все более безопасными с каждой версией, они также усиливают контроль конфиденциальности, изолируя и предотвращая использование данных пользователя или устройства. Как ни странно, это может усложнить применение мер безопасности, так как серверные системы, такие как элементы управления аттестацией и мониторингом, часто работают лучше для старых версий операционной системы, чем для новых.
Есть и другие сложности, когда речь идет о безопасности самого сервера. Как защищены данные в месте их хранения в этой точке концентрации? Какие конкретные требования к конфиденциальности применяются в географическом регионе, в котором вы будете развертывать систему мобильных лицензий, и как то, что вы делаете, влияет на те, которые выходят за рамки традиционных данных лицензий, которые вы собираете (например, как поддерживаются и контролируются какие-либо системы биометрического сопоставления)? Если вы используете стороннюю систему, что вы сделали для проверки эффективности их настройки безопасности?
Использование токенов также обеспечивает большую гибкость в отношении доверия к использованию считывателя; вы можете повысить безопасность системы, потребовав большего количества проверок подлинности считывателей, подключающихся к токенам. В качестве альтернативы вы действительно можете снизить уровень безопасности для читателей при использовании токена, поскольку токен обеспечивает неявное намерение и временные рамки для извлечения этих данных. Ваше решение в любом случае - для большей или меньшей безопасности при работе с токенами - может зависеть от типа предоставленного токена и от того, какие данные ему разрешено получать.
Важно, как именно вы разрешите это использовать. Использование токенов в mDL может абсолютно сделать вещи более безопасными. Плохо реализованные, они также могут создавать совершенно новые проблемы.
Совместимость
Традиционные лицензии на драйверы могут использоваться в самых разных регионах и юрисдикциях, но из-за необходимости в читателях, которые могут аутентифицировать криптографические аспекты mDL, может возникнуть проблема совместимости при рассмотрении их для аналогичного широкого использования. Чтобы гарантировать, что ваши лицензии могут быть аутентифицированы, вам необходимо будет совместно использовать какую-то общую криптографическую структуру или иметь главный корневой ключ подписи, который используется (или, по крайней мере, доверяет) в ряде разных географических регионов.
Стандарт ISO для лицензий на мобильные драйверы гарантирует, что любая произвольная реализация (если она разработана в соответствии со стандартом) должна иметь возможность форматировать данные таким образом, чтобы любой произвольный читатель мог их интерпретировать. Однако ответ, как всегда, как вы уже догадались, не так прост. Стандарт ISO позволяет использовать различные физические интерфейсы связи (NFC, Wi-Fi, QR-коды и т. д.), Поэтому, если считыватель предназначен для использования с оптическими реализациями mDL, но сам mDL обменивается данными только через Bluetooth, тогда они не будут разговаривать.
Любой, кто работал со стандартизацией и совместимостью, также знает, что стандартизованные протоколы часто могут быть реализованы неправильно или с различными интерпретациями нормативных правил, встроенных в стандарт. Тестирование реализаций имеет важное значение - вы не можете просто предполагать, что любая система сможет правильно работать во всех ситуациях. Возможно, менее очевидно, что тестирование совместимости также может выявить проблемы безопасности, когда данные обрабатываются или управляются неправильно, или когда происходит утечка данных, которые в противном случае должны были оставаться конфиденциальными.
Онлайн против офлайн
Последний аспект лицензий на мобильные драйверы, который необходимо учитывать, - это использование в автономном режиме. Очень разумно учитывать, что мобильное устройство может быть вне зоны действия связи, когда это требуется для использования mDL. Возможно, распределение данных пользователей полностью исчерпано, возможно, они находятся на стоянке здания или в мертвой точке без приема, или, возможно, они отключили данные для экономии роуминга или других расходов. В любом случае, когда соединение с серверной частью невозможно, разумно ожидать, что мобильная лицензия по-прежнему будет пригодна для использования.
Но влияет ли это на безопасность вашей реализации? Также разумно ожидать, что пользователь может перенести свой mDL на другой телефон (в случае потери, обновления и т. Д.) - и теперь мы должны подумать, что произойдет, если телефон будет отключен, а затем тот же пользователь установит свой mDL на другой телефон. (онлайн) телефон? На данный момент у нас есть две полностью действующие копии mDL: (старая) автономная версия и (новая) онлайн-версия! Ниже представлена иллюстрация этого процесса.
По сути, это «простой» метод клонирования любого экземпляра mDL. Конечно, правильное изображение первоначального держателя лицензии применяется к каждой лицензии, но это действительно облегчает людям «делиться» лицензиями между друзьями (я уверен, что никто из нас никогда не встречал людей, которые делали бы это, чтобы они могли тайком своих друзей в бары и ночные клубы мы?).
Специфика реализации сценариев использования mDL, обучения пользователей и развертывания должна учитывать методы смягчения воздействия клонирования этого типа.
Лучше, чем пластик?
Итак, действительно ли мобильная водительская лицензия лучше и безопаснее, чем физическая? Ну, как и почти все, это зависит от обстоятельств. Это зависит от уровня гарантии, который вам нужен в вашей системе, от того, используется ли mDL с допустимым считывателем, какие меры безопасности встроены в реализацию и какие методы вы использовали для их проверки. Это зависит от того, насколько безопасны ваши приложения mDL и читатели mDL, насколько защищен ваш бэкэнд и насколько хорошо вы настроили управление ключами. Это зависит от того, насколько эффективно вы обучили людей правильному использованию экземпляров mDL и насколько легко им применить это обучение на практике.
Проще говоря, когда дело доходит до безопасности реализаций mDL, ваш опыт может отличаться. В UL мы уже много лет участвуем в стандартизации и тестировании на соответствие реализаций mDL, создавая и проверяя модели угроз и планы тестирования, а также помогая обучать людей как рискам, так и возможностям. Используя последнюю аналогию с автомобилем, мы уже несколько раз обходили этот квартал.
Это работает только тогда, когда есть уже существующие отношения, которые, конечно же, можно использовать для получения знаний, используемых для идентификации. Когда вам нужно идентифицировать себя перед кем-то другим, с кем-то, кого вы никогда не встречали, мы исторически полагались на документы, фотографии, подробности и информацию о вас и вашем прошлом. Люди будут путешествовать с рекомендательными письмами или даже с другим человеком - буквально доверенным третьим лицом - чтобы помочь другим идентифицировать себя.
В настоящее время мир, в котором живет и работает большинство людей, намного больше, сложнее и взаимосвязан, поэтому мы создали учреждения и службы, которые могут выступать в качестве доверенных третьих сторон, чтобы идентифицировать людей или одобрять доверенные документы, чтобы сделать это вместо них. Паспорта и водительские права являются примерами этих типов удостоверяющих личность документов по доверенности, предоставляющих полезность в качестве систем идентификации общего назначения, существенно расширяющих их назначение за пределы их первоначальной компетенции. До недавнего времени эти типы идентификационных систем были полностью физическими - в значительной степени просто обновленными версиями старого рекомендательного письма.
Однако этот тип чисто физических систем часто можно легко воспроизвести, и в течение последнего десятилетия или около того мы видели введение электронных паспортов и водительских прав, которые сочетают в себе функции физической безопасности традиционного паспорта с функциями логической безопасности. такие как криптографические подписи и внутренняя обработка. Теперь мы переходим в мир коммерциализации - платежей, технологий и идентичности - и это приводит к тому, что наши документы также переводятся в цифровую форму в мобильные реализации.
В этом посте я конкретно расскажу о лицензиях мобильных драйверов (mDL) - что это такое, как работает и что это значит для тех, кто их использует и хочет их развернуть. На момент написания стандарт ISO для mDL (ISO18013-5) еще не совсем готов, но UL уже некоторое время является ключевым участником и участником рабочей группы ISO. Хотя это и работа, которую мы проделали с некоторыми из первых пользователей mDL, у нас есть уникальный контекст и опыт, которыми мы можем поделиться.
mDL - версия TL; DR
Итак, что такое «мобильные» водительские права и как они работают? Что ж, это не обязательно то же самое, что и лицензии, к которым вы привыкли ... Традиционные водительские лицензии полагаются на физическую реализацию для обеспечения безопасности с помощью голограмм на пластике, определенных наложений изображений, возможно, даже физического чипа в карте и т. Д. быть подтвержденным лицом, проверяющим идентификатор, что помогает предотвратить подделки и модификации.
Водительское удостоверение мобильного телефона, напротив, представляет собой цифровую версию этих документов, удостоверяющих личность; хранится и внедряется в коммерческую готовую систему (COTS), такую как мобильный телефон - отсюда и буква «m» в mDL. Потому что мобильная лицензия не имеет физического аспекта и не может полагаться на функции физической безопасности. Вместо использования лица, просматривающего физическую сущность лицензии для ее аутентификации, mDL должен полагаться на использование отдельного «считывателя», который подключается к экземпляру mDL для аутентификации логических аспектов реализации.
Подключения могут осуществляться с помощью различных технологий - NFC, BLE, WiFi, оптических и т. д. - и с применением криптографии для обеспечения конфиденциальности и аутентичности передаваемых данных.
Я знаю тебя. Я знаю все о тебе
Мы уже отмечали, что идентификация может работать только в том случае, если есть уже существующие отношения или какая-либо доверенная третья сторона, а в случае ваших физических водительских прав это ваша местная версия Департамента транспортных средств, какое-то государственное учреждение, уполномоченное проверять который:
- Вы можете водить автомобиль в соответствии с местными стандартами.
- Вы тот, кем себя называете.
Когда mDL может быть запущен удаленно, он должен полагаться на наличие существующей физической лицензии, чтобы действовать как корень доверия для идентификации пользователя. Пользователь обычно фотографирует эту существующую лицензию на свой телефон, затем делает селфи в качестве доказательства своей личности, и оба этих снимка используются для подтверждения действительности существующей лицензии и права собственности на эту лицензию текущим. пользователь мобильного телефона.
Конечно, безопасность, реализованная на этом этапе, очень важна, поскольку это устанавливает владельца всех данных, которые впоследствии будут предоставлены мобильному устройству. Однако этот этап намеренно не охвачен действующим стандартом ISO для лицензий для мобильных драйверов, поскольку он входит в новый стандарт, над которым надлежит работать в течение следующих нескольких лет - ISO 23220.
Это текущее отсутствие ясности в отношении выпуска и предоставления мобильных лицензий обеспечивает гибкость для внедрения, но также несет с собой сложность и риски. Большинство случаев мошенничества с мобильными платежами происходит на этапе оцифровки, когда преступники обходят плохо реализованные средства контроля на этапе идентификации и проверки. При развертывании реализаций лицензий для мобильных водителей выясняется, как обеспечивается безопасность в отношении реализации этой идентификации и проверки, эффективность любого используемого биометрического сопоставления, использование метаданных, таких как геолокация, способ реализации механизмов отката или увеличения масштаба при сбое технологии или риски считаются слишком высокими для автоматического сопоставления - все эти вещи (и многое другое!) должны быть тщательно продуманы и протестированы.
Sacnner Darkly
В предыдущем разделе я отмечал, что для проверки лицензии мобильных водителей требуется использование считывающего устройства. Конечно, вы можете просто «взглянуть» на такую лицензию, и вы увидите, что представляет собой изображение традиционной физической лицензии. Однако такой образ - это всего лишь образ. Даже с дополнительной защитой, такой как движущиеся изображения водителя, эффекты движения или искажения, реализуемые при прикосновении к лицензионному изображению, действительность мобильной лицензии действительно может быть подтверждена только при использовании отдельного компонента или системы считывателя.
Здесь снова можно провести параллель с платежами. Когда вы используете платежную карту, эта карта больше не проверяется только физическими средствами - данные на магнитной полосе карты или данные на внутреннем чипе карты используются для того, чтобы карта могла быть проверена другими сторонами (терминал, приобретатель, Эмитент). Это связано с тем, что физические аспекты платежных карт легко «клонировать» или копировать, поэтому простого физического исследования самой карты недостаточно. Даже проверки чисто статических данных, таких как данные на магнитной полосе карты или считываемые компьютером штрих-коды, часто бывает недостаточно, поскольку их также можно легко скопировать с одной карты на другую.
Точно так же, как у нас есть платежные терминалы для считывания и проверки данных на платежных картах, нам нужны считыватели mDL, чтобы делать то же самое с лицензиями мобильных водителей. Ограничивает ли это полезность MDL по сравнению с традиционной лицензией? Возможно, в некотором роде - но это также может сделать их более безопасными. Задача состоит в том, чтобы реализовать системы чтения наиболее легко развертываемым и совместимым образом, возможно, путем предоставления веб-интерфейсов API или бесплатной загрузки приложений для распространенных мобильных операционных систем.
Ниже приводится иллюстрация компонентов высокого уровня и соединений системы MDL.
Важно, чтобы безопасность этих систем чтения и серверной части также была проверена, чтобы гарантировать правильную и безопасную настройку всей экосистемы. Возможно, вам захочется иметь разные типы читателей для разных уровней уверенности; Если MDL проверяется на соответствие возрасту в кинотеатре, это явно другой профиль риска, чем если бы он проверялся при пересечении границы или полицией. Реализованные считыватели могут аналогичным образом обеспечивать различные уровни уверенности и безопасности для фактического процесса чтения, например, вероятно, полиции потребуется специальная система проверки лицензии или что вы захотите провести дополнительные проверки систем COTS, используемых такими организациями. если не используются специальные читатели.
Обучение тому, как правильно использовать и проверять mDL, также важно; Вы же не хотите, чтобы люди использовали просто изображение MDL для идентификатора, например, при создании банковского счета!
Шшш… Это секрет!
Использование устройства COTS в качестве основы для функций лицензирования мобильных водителей - отличный способ обеспечить максимальный охват технологии, но оно создает сложности, когда дело доходит до безопасности данных и обработки, используемых как mDL, так и любыми COTS-системами. читатели. На этапе идентификации и проверки владелец лицензии идентифицирует себя для серверной части управляющего органа, и ему назначаются («предоставляются») некоторые конкретные данные, которые помогают однозначно идентифицировать это устройство COTS и привязать экземпляр приложения к личности пользователя. Без защиты эти данные могут быть скопированы на другой телефон, по сути копируя или «клонируя» мобильную лицензию. Хуже того, он может быть изменен при транспортировке или хранении перед использованием,
Не поймите меня неправильно, безопасность современных операционных систем COTS действительно хороша. Полностью пропатченное и обновленное устройство Android или iOS - один из самых безопасных коммерческих продуктов, которые вы можете купить. Однако при развертывании mDL вы, вероятно, не захотите ограничивать область действия только самыми последними и полностью исправленными устройствами, поскольку это значительно ограничит объем развертывания. См. Приведенный ниже график распределения версий Android с течением времени (собранный с веб-сайта распространения Google Android https://developer.android.com/about/dashboards и красиво отображенный на этом графике ниже по адресу https://www.bidouille.org/misc / androidcharts). Это показывает, как долго старые версии Android могут оставаться на рынке, даже если они могут быть устаревшими на несколько версий.
Проблема, конечно, в том, что вы не можете поддерживать все исторические версии, потому что независимо от того, насколько безопасной может быть новая или обновленная система на момент ее первоначального выпуска, старые и обновленные COTS-устройства, приложения или операционные системы могут быть весьма небезопасными ...
Таким образом, необходимо принять решение о том, какой минимальный уровень устройства или операционной системы вы примете для развертывания вашей реализации mDL. Любое такое решение также подразумевает необходимость периодического обновления принятых платформ COTS, поскольку то, что ранее считалось приемлемым, становится слишком старым и небезопасным для дальнейшего использования, поскольку время продолжает обнаруживать ранее неизвестные уязвимости.
Как вы собираетесь принимать эти решения? Как вы собираетесь сообщить существующим держателям мобильных лицензий, что они должны либо обновить свой телефон, либо отозвать свой mDL? Какой уровень безопасности требуется для вашей реализации и как вы собираетесь проверить правильность его реализации на всех устройствах, на которых развернут mDL?
Например, потребуется ли вам, чтобы mDL изолировал важные операции в логически отдельной Trusted Execution Environment (TEE) или выделенном процессоре безопасности, что ограничит тип поддерживаемых устройств и способ их развертывания? Или вас устраивает, что приложение и данные защищены в «богатой» операционной системе Android или iOS, если вы можете обеспечить определенный уровень безопасности? Как вы собираетесь определять и проверять тот уровень безопасности, который должен применяться, и какие данные у вас есть или следует использовать, чтобы принять это решение?
Как и во многих других случаях, необходимо сделать выбор между областью действия, совместимостью и безопасностью, и часто это игра с нулевой суммой, когда выбор в одном направлении влияет на выбор, который вы можете сделать в другом.
Мой бэкэнд выглядит в этом уязвимым?
В предыдущих обсуждениях использования и безопасности лицензий на мобильные драйверы мы обсуждали, что считыватель и сам mDL подключаются к серверной системе; но как именно это реализовано, остается на усмотрение разработчика. Часто будут использоваться общие протоколы безопасности, такие как TLS, что является хорошей идеей, но не менее важна точная конфигурация - какие шифровальные комплекты, какие версии, как управлять сертификатами и т.д.?
В последнем разделе мы обсудили безопасность хранения предоставленных данных, и здесь нам необходимо рассмотреть безопасность связи, которая также подразумевает проблему начальной загрузки. Если вы доставляете данные инициализации в mDL впервые, это, по сути, «ванильное» приложение - как и любое другое приложение mDL этого типа, которое было загружено из магазина приложений. До первого шага процесса подготовки уникальные данные для какого-либо приложения отсутствуют. Как вы затем идентифицируете и аутентифицируете приложение для начальной подготовки, чтобы предотвратить атаки «посередине», когда злоумышленник может находиться между подлинным приложением и серверной частью для сбора или изменения отправленных данных? Как вы определяете используемую платформу и систему, человека, запрашивающего данные лицензии?
Поскольку мобильные операционные системы становятся все более безопасными с каждой версией, они также усиливают контроль конфиденциальности, изолируя и предотвращая использование данных пользователя или устройства. Как ни странно, это может усложнить применение мер безопасности, так как серверные системы, такие как элементы управления аттестацией и мониторингом, часто работают лучше для старых версий операционной системы, чем для новых.
Есть и другие сложности, когда речь идет о безопасности самого сервера. Как защищены данные в месте их хранения в этой точке концентрации? Какие конкретные требования к конфиденциальности применяются в географическом регионе, в котором вы будете развертывать систему мобильных лицензий, и как то, что вы делаете, влияет на те, которые выходят за рамки традиционных данных лицензий, которые вы собираете (например, как поддерживаются и контролируются какие-либо системы биометрического сопоставления)? Если вы используете стороннюю систему, что вы сделали для проверки эффективности их настройки безопасности?
Токенизация личности
Стандарт лицензии на мобильные драйверы позволяет доставить считывающему устройству «токенизированный» идентификатор, так что данные лицензии фактически не передаются напрямую из mDL - вместо этого считыватель использует маркер в качестве механизма аутентификации для запроса лицензии. данные, которые будет извлекать считыватель непосредственно из серверных систем. Это может быть полезно, когда извлекаемые данные создают чрезмерную нагрузку на среду передачи данных (например, при использовании QR-кодов).Использование токенов также обеспечивает большую гибкость в отношении доверия к использованию считывателя; вы можете повысить безопасность системы, потребовав большего количества проверок подлинности считывателей, подключающихся к токенам. В качестве альтернативы вы действительно можете снизить уровень безопасности для читателей при использовании токена, поскольку токен обеспечивает неявное намерение и временные рамки для извлечения этих данных. Ваше решение в любом случае - для большей или меньшей безопасности при работе с токенами - может зависеть от типа предоставленного токена и от того, какие данные ему разрешено получать.
Важно, как именно вы разрешите это использовать. Использование токенов в mDL может абсолютно сделать вещи более безопасными. Плохо реализованные, они также могут создавать совершенно новые проблемы.
Совместимость
Традиционные лицензии на драйверы могут использоваться в самых разных регионах и юрисдикциях, но из-за необходимости в читателях, которые могут аутентифицировать криптографические аспекты mDL, может возникнуть проблема совместимости при рассмотрении их для аналогичного широкого использования. Чтобы гарантировать, что ваши лицензии могут быть аутентифицированы, вам необходимо будет совместно использовать какую-то общую криптографическую структуру или иметь главный корневой ключ подписи, который используется (или, по крайней мере, доверяет) в ряде разных географических регионов.
Стандарт ISO для лицензий на мобильные драйверы гарантирует, что любая произвольная реализация (если она разработана в соответствии со стандартом) должна иметь возможность форматировать данные таким образом, чтобы любой произвольный читатель мог их интерпретировать. Однако ответ, как всегда, как вы уже догадались, не так прост. Стандарт ISO позволяет использовать различные физические интерфейсы связи (NFC, Wi-Fi, QR-коды и т. д.), Поэтому, если считыватель предназначен для использования с оптическими реализациями mDL, но сам mDL обменивается данными только через Bluetooth, тогда они не будут разговаривать.
Любой, кто работал со стандартизацией и совместимостью, также знает, что стандартизованные протоколы часто могут быть реализованы неправильно или с различными интерпретациями нормативных правил, встроенных в стандарт. Тестирование реализаций имеет важное значение - вы не можете просто предполагать, что любая система сможет правильно работать во всех ситуациях. Возможно, менее очевидно, что тестирование совместимости также может выявить проблемы безопасности, когда данные обрабатываются или управляются неправильно, или когда происходит утечка данных, которые в противном случае должны были оставаться конфиденциальными.
Онлайн против офлайн
Последний аспект лицензий на мобильные драйверы, который необходимо учитывать, - это использование в автономном режиме. Очень разумно учитывать, что мобильное устройство может быть вне зоны действия связи, когда это требуется для использования mDL. Возможно, распределение данных пользователей полностью исчерпано, возможно, они находятся на стоянке здания или в мертвой точке без приема, или, возможно, они отключили данные для экономии роуминга или других расходов. В любом случае, когда соединение с серверной частью невозможно, разумно ожидать, что мобильная лицензия по-прежнему будет пригодна для использования.
Но влияет ли это на безопасность вашей реализации? Также разумно ожидать, что пользователь может перенести свой mDL на другой телефон (в случае потери, обновления и т. Д.) - и теперь мы должны подумать, что произойдет, если телефон будет отключен, а затем тот же пользователь установит свой mDL на другой телефон. (онлайн) телефон? На данный момент у нас есть две полностью действующие копии mDL: (старая) автономная версия и (новая) онлайн-версия! Ниже представлена иллюстрация этого процесса.
По сути, это «простой» метод клонирования любого экземпляра mDL. Конечно, правильное изображение первоначального держателя лицензии применяется к каждой лицензии, но это действительно облегчает людям «делиться» лицензиями между друзьями (я уверен, что никто из нас никогда не встречал людей, которые делали бы это, чтобы они могли тайком своих друзей в бары и ночные клубы мы?).
Специфика реализации сценариев использования mDL, обучения пользователей и развертывания должна учитывать методы смягчения воздействия клонирования этого типа.
Лучше, чем пластик?
Итак, действительно ли мобильная водительская лицензия лучше и безопаснее, чем физическая? Ну, как и почти все, это зависит от обстоятельств. Это зависит от уровня гарантии, который вам нужен в вашей системе, от того, используется ли mDL с допустимым считывателем, какие меры безопасности встроены в реализацию и какие методы вы использовали для их проверки. Это зависит от того, насколько безопасны ваши приложения mDL и читатели mDL, насколько защищен ваш бэкэнд и насколько хорошо вы настроили управление ключами. Это зависит от того, насколько эффективно вы обучили людей правильному использованию экземпляров mDL и насколько легко им применить это обучение на практике.
Проще говоря, когда дело доходит до безопасности реализаций mDL, ваш опыт может отличаться. В UL мы уже много лет участвуем в стандартизации и тестировании на соответствие реализаций mDL, создавая и проверяя модели угроз и планы тестирования, а также помогая обучать людей как рискам, так и возможностям. Используя последнюю аналогию с автомобилем, мы уже несколько раз обходили этот квартал.
