Сложность интеграции мобильного водительского удостоверения (mDL) заключается не в вызове API для проверки личности, а в понимании того, что происходит за этим интерфейсом: где хранятся учетные данные, кто защищает ключи устройства, как управляются сертификаты доверия и что продолжает работать при отсутствии сети или сбое поставщика услуг. В статье, опубликованной на InfoQ, представлен архитектурный подход к системам mDL, построенным в соответствии со стандартом ISO/IEC 18013-5, предназначенный для организаций, выбирающих поставщика, SDK, платформу кошелька или сервис верификации.
Разделение установления личности и выдачи учетных данных
Предлагаемый подход начинается с разделения двух разных этапов жизненного цикла идентичности. На этапе установления личности пользователь фотографирует свое физическое водительское удостоверение и записывает видео для проверки живости, после чего доказательства и извлеченные данные отправляются в систему верификации. Компетентный орган, например ведомство транспортных средств, проверяет эти доказательства автоматически или вручную, прежде чем принять решение об одобрении или отклонении.
После одобрения начинается этап предоставления. Устройство создает асимметричные ключи внутри Secure Enclave или защищенного элемента, а затем отправляет открытый ключ, сертификаты аттестации и ссылку на процедуру установления личности органу, выдавшему документ. Этот орган связывает данные водительского удостоверения с ключом внутри подписанного Mobile Security Object, после чего шифрует пакет учетных данных и отправляет его в кошелек для хранения в аппаратно защищенной области.
Организация не обязана выполнять эти шаги самостоятельно, однако она должна определить сторону, ответственную за каждый шаг, и сторону, которой принадлежит решение о доверии, вытекающее из него.
Что следует проверять за интерфейсом поставщика?
В статье отмечается, что успешного пилотного опыта с вызовом функций вроде verifyCredential() или requestPresentation() недостаточно для оценки поставщика. Проверка должна охватывать шесть взаимосвязанных направлений:
- Криптографическая архитектура: создание и защита ключей, аттестация устройства, алгоритмы и жизненный цикл ключей.
- Доверие и инфраструктура открытых ключей: корни доверия, сертификаты Document Signer, списки доверия и отзыва.
- Конфиденциальность и минимизация данных: выборочное раскрытие, телеметрия, хранение данных о предъявлении и риски связывания транзакций.
- Работа в автономном режиме: материалы, хранящиеся в кэше, устаревшее состояние отзыва и поведение системы при отсутствии сети.
- Интероперабельность: соответствие ISO/IEC 18013-5 и возможность взаимодействия с независимыми кошельками и верификаторами.
- Операционная устойчивость: последствия сбоя поставщика, сохранение действительности учетных данных, механизмы восстановления и обработки отказов.
Криптография и сертификаты — не детали реализации
В статье предлагается использовать Hybrid Public Key Encryption в соответствии с RFC 9180 для защиты передачи данных через интернет и обмена данными через API, с параметрами, включающими DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 и AES-128-GCM. Однако криптографию, согласно предлагаемому подходу, не следует рассматривать отдельно от модели доверия: необходимо понимать, где начинается и заканчивается шифрование, кто создает и защищает ключи, как выполняется их ротация и какие компоненты находятся в пределах границы доверия поставщика.
Связь между серверами кошельков, платформами выдачи и системами верификации также требует взаимной аутентификации через TLS и четкой инфраструктуры сертификатов. В статье рассматриваются разные роли сертификатов: от корня доверия, хранящегося в автономном аппаратном модуле безопасности, до краткоживущих сертификатов Document Signer, сертификатов mTLS и сертификатов аттестации ключей устройств. Ключевым остается распределение ответственности: какую инфраструктуру управляет поставщик, какая находится под контролем организации и какие отношения доверия остаются в ведении органа, выдавшего документ.
Что практически меняется при сбое сервиса?
В архитектуре различаются синхронные операции, происходящие во время верификации, такие как обмен данными через NFC или прямая проверка через API, и асинхронные операции, которые можно выполнять в фоновом режиме, например проверку установления личности, предоставление учетных данных, ротацию ключей и синхронизацию списков доверия.
Такое разделение позволяет продолжать предъявление существующего удостоверения и его проверку в автономном режиме, если это разрешено политиками, тогда как синхронизацию списков доверия или обновления отзыва можно отложить. В статье предлагается тестировать предъявление и проверку без сети, истекшие учетные данные, устаревшие списки отзыва, расхождение часов устройства, восстановление соединения и поведение системы при сбое поставщика. Зависимость от поставщика с высокой доступностью все равно может стать единой точкой отказа, если для каждой проверки требуется соединение с его серверными службами.
Выборочное раскрытие и предотвращение зависимости от поставщика
Требуемые данные различаются в зависимости от ситуации. Например, пункту контроля в аэропорту могут потребоваться имя, фотография, дата рождения, номер документа и орган, выдавший документ, тогда как магазину может быть достаточно логического утверждения о том, что возраст пользователя превышает 21 год, вместе с фотографией — без имени, адреса или номера документа. Поэтому недостаточно тестировать поставщика по одному сценарию: его необходимо оценивать с учетом политик организации и фактических категорий транзакций.
В материале предлагается сохранять бизнес-логику независимой от архитектуры поставщика, чтобы приложения выражали такую политику, как запрос подтверждения того, что возраст превышает 21 год, вместо распространения специфичных для поставщика структур данных по всей системе. Можно скрыть такие детали, как последовательность CBOR, формирование сообщений APDU и вызовы криптографических библиотек, однако точки доверия, идентичность органа, выдавшего документ, раскрываемые атрибуты, состояние сертификатов и отзыва, зависимость от поставщика и возможности автономной работы должны оставаться видимыми для организации.
Взгляд certi.news
Реальное изменение, на котором сосредоточена статья, заключается в переходе от тестирования функции SDK к проверке полной системы доверия mDL. Такой подход полезен для команд безопасности, идентификации и закупок, поскольку позволяет определить, что можно приобрести, а что должно оставаться под управлением организации: можно приобрести реализацию кошелька, протоколы NFC и криптографические библиотеки, тогда как политики раскрытия, авторизации и аудита, а также управление ключами, сертификатами, конфиденциальностью, доступностью и интероперабельностью должны выстраиваться самой организацией.
Однако предложенный подход сам по себе не решает такие вопросы, как местные требования к соблюдению нормативов или модели управления между органами, выдающими документы, и верификаторами. Кроме того, гарантия корректности подписи не гарантирует конфиденциальность, если системы хранят избыточные записи или связывают операции предъявления с пользователями. Поэтому вопросы отслеживания, сохраняющего конфиденциальность отзыва и ответственности при сбое поставщика по-прежнему требуют организационных и регуляторных решений до перехода к промышленной эксплуатации.