Верификация без обращения к серверу: почему будущий цифровой МВУ не должен обращаться к эмитенту при каждом использовании

Отзыв документа — наиболее сложная проблема любого будущего цифрового Международного Водительского Удостоверения (МВУ). Самый простой способ её решения одновременно является и самым опасным: сделать эмитента участником каждой отдельной презентации. Современный трансграничный водительский документ должен отказываться от этого пути по умолчанию.

Практически в каждом предложении по цифровой идентификации содержится одна и та же обнадёживающая фраза:

«Документ может быть верифицирован мгновенно.»

Иногда эта фраза описывает подлинный прогресс. Иногда — слежку с более дружелюбным интерфейсом.

Действующие опубликованные стандарты уже чётко указывают на то, что верификатору не нужно обращаться к эмитенту каждый раз при предъявлении документа:

• Текущая архитектура mDL от NIST гласит, что верификатор может подтвердить подлинность и целостность документа, доверяя подписи эмитента и открытым ключам, без какого-либо прямого контакта с эмитентом.
• AAMVA подтверждает, что стандарт ISO/IEC 18013-5 требует поддержки получения данных с устройства и лишь опционально допускает получение данных с сервера.
• AAMVA также предупреждает, что при серверном получении данных орган-эмитент участвует в режиме реального времени при каждом использовании — а значит, технически может фиксировать, когда использовался документ, какие данные были переданы, и даже определять местоположение через анализ IP-адресов.

Это не второстепенная сноска. Это ключевой вопрос проектирования для следующего поколения трансграничных водительских документов.

Опасный путь: сведение четырёх вопросов к одному сетевому запросу

Неудачные архитектуры объединяют четыре совершенно разных вопроса в один запрос в реальном времени к эмитенту:

1. Является ли этот документ подлинным?
2. Является ли предъявляющий его человек законным владельцем?
3. Является ли сам документ всё ещё действительным?
4. Является ли лежащее в основе национальное право на управление транспортным средством всё ещё действующим?

Плохо спроектированная система отвечает на все четыре вопроса путём обращения к серверу в реальном времени. Хорошо спроектированная система разделяет их — потому что это разные проблемы, и у них не должно быть общего механизма решения.

Подлинность должна верифицироваться локально, а не через сеть

Документ может быть криптографически подлинным без того, чтобы эмитент когда-либо наблюдал за транзакцией.

• Модель доверия mDL от NIST гласит, что подлинность и целостность подтверждаются по подписи эмитента и открытым ключам — прямой контакт с эмитентом в режиме реального времени не требуется.
• Служба цифрового доверия AAMVA существует именно для того, чтобы предоставлять верификаторам доступ к действующим открытым ключам эмитента без обратных обращений по каждой транзакции.

Принцип проектирования 1: Не используйте сетевое соединение для решения проблемы, которую уже решают цифровые подписи.

Если верификатор располагает доверенными ключами эмитента и получает презентацию, соответствующую стандартам, проверка подлинности — это локальная криптографическая операция, а не зависимость от сети.

Привязка к владельцу должна подтверждаться локально, а не передаваться глобально

Второй вопрос — является ли это законным владельцем? — также имеет ответ, не требующий обращения к сети.

Текущая архитектура EUDI предписывает привязку к устройству для PID и аттестаций по ISO/IEC 18013-5. Верификатор просит кошелёк подписать свежий запрос с использованием закрытого ключа, соответствующего открытому ключу, встроенному в документ:

• В ISO/IEC 18013-5 это называется аутентификацией mdoc.
• В SD-JWT VC это называется привязкой ключа.

В обоих случаях владение подтверждается локально и криптографически. Никакие персональные данные не должны достигать эмитента.

Принцип проектирования 2: Подтверждайте владение локально. Не доказывайте личность глобально.

Будущий МВУ должен исчерпать возможности привязки к устройству, локальной аутентификации владельца и проверки запроса верификатора прежде, чем рассматривать любые механизмы на стороне эмитента.

Статус документа и статус права на вождение — это две разные вещи

Многие проекты в области цифровой идентификации размывают это различие, и именно здесь они ошибаются.

Спецификация W3C Bitstring Status List чётко формулирует этот момент: статусная информация, прикреплённая к верифицируемому документу, относится к самому верифицируемому документу — не обязательно к лежащему в основе праву реального мира. Цифровой документ может быть отозван из-за компрометации механизма подписи, тогда как само право на вождение остаётся полностью действительным.

Поэтому будущий МВУ нуждается в двух отдельных уровнях статуса:

• Уровень статуса документа — для самого цифрового документа или канала презентации.
• Уровень права на вождение — для лежащего в основе национального права управления транспортным средством.

Иногда они меняются одновременно. Часто — нет. Система, смешивающая их, будет реагировать избыточно, раскрывать больше данных, чем необходимо, или и то, и другое.

Компрометация кошелька должна распространяться через статус — а не вызывать обращения верификатора

Будущий МВУ также нуждается в чётком ответе на вопрос о том, что происходит при компрометации кошелька.

Архитектура EUDI предоставляет его:

• Поставщик кошелька выпускает Аттестации Единицы Кошелька, содержащие информацию об отзыве.
• Целостность кошелька периодически повторно верифицируется; если кошелёк больше не является безопасным, его аттестация отзывается.
• Поставщики PID обязаны регулярно проверять, не был ли кошелёк отозван. Если да — они отзывают PID.
• Верифицируя статус PID, доверяющая сторона косвенно верифицирует статус кошелька.

Именно такое многоуровневое построение должен принять будущий МВУ. Не нужно требовать от каждого верификатора самостоятельно проверять поставщика кошелька. Пусть компрометация кошелька распространяется через существующий конвейер статуса документа, а верификаторы обращаются к этому единственному конфиденциальному каналу.

Три работоспособных схемы отзыва (без обратных обращений)

EUDI обязывает поставщиков использовать один из трёх методов отзыва:

• Краткосрочные аттестации — действительны 24 часа или менее, поэтому отзыв становится излишним.
• Список статусов аттестаций — опубликованный список, который могут запрашивать верификаторы.
• Список отзыва аттестаций — явный список отозванных документов.

Для аттестаций, действительных более 24 часов, EUDI требует встраивания информации об отзыве, включающей:

• URL, по которому доверяющие стороны могут получить список статусов.
• Идентификатор, позволяющий найти документ в этом списке.

Если надёжная информация об отзыве недоступна — например, когда доверяющая сторона работает офлайн — EUDI предписывает доверяющей стороне провести анализ рисков перед принятием или отклонением документа.

Вывод: отзыв — это не единственный механизм и уж точно не обоснование для обязательных обратных обращений к эмитенту.

Краткосрочность по умолчанию, долгосрочность — только там, где необходимо

Одна из наиболее эффективных мер защиты конфиденциальности во всём стеке — также и самая простая: делайте предъявляемые данные краткосрочными.

• EUDI указывает, что аттестации сроком действия 24 часа или менее не требуют инфраструктуры отзыва — они истекают прежде, чем отзыв стал бы актуальным.
• W3C указывает, что верифицируемые презентации, как правило, краткосрочны и не предназначены для длительного хранения.
• NIST прямо предостерегает от многократной передачи повторно используемых идентификаторов в повседневном использовании. Повседневная аутентификация должна опираться на технологии, созданные для этой цели, такие как ключи доступа (passkeys), а не на многократное предъявление насыщенного персональными данными документа.
• NIST также выбрал локальную аутентификацию на устройстве вместо серверного биометрического сопоставления именно потому, что локальная аутентификация сохраняет конфиденциальность и более эффективна в операционном отношении.

Принцип проектирования 3: Базовый документ может иметь средний срок действия, однако сама презентация должна быть краткосрочной, специфичной для верификатора и не допускающей повторного использования.

Списки статусов — правильный механизм по умолчанию

Когда нельзя сделать всё краткосрочным, необходима статусная инфраструктура — и список статусов является правильным выбором по умолчанию.

Стандарт W3C Bitstring Status List v1.0 описывает конфиденциальный, пространственно-эффективный и высокопроизводительный механизм публикации статусных данных, таких как приостановка или отзыв. Ключевые свойства включают:

• Каждый эмитент управляет списком для выданных им документов.
• Формат хорошо сжимается, поскольку большинство документов остаются не отозванными.
• Размер списка по умолчанию составляет 131 072 записи, что, по утверждению W3C, обеспечивает достаточную групповую конфиденциальность в среднем случае.
• Там, где требуется более высокая групповая конфиденциальность, могут использоваться более крупные списки.

Это смещает вопрос с:

«Могу ли я прямо сейчас спросить эмитента об этом пользователе?»

на:

«Располагаю ли я уже достаточно актуальным конфиденциальным списком статусов для принятия решения локально?»

Это значительно лучший вопрос — как с технической, так и с политической точки зрения.

«Без обращения к серверу» — это модель загрузки данных, а не лозунг

Важнейшее правило в руководстве EUDI по конфиденциальности носит процедурный, а не философский характер.

Доверяющие стороны не должны запрашивать список статусов каждый раз при предъявлении документа. Вместо этого они обязаны:

• Загружать каждую новую версию списка один раз.
• Делать это в момент времени и из местоположения, не связанных ни с одной из пользовательских презентаций.
• Распространять список внутри организации доверяющей стороны.
• Получать список без аутентификации доверяющей стороны.

В этом и состоит операционная суть верификации без обращения к серверу: обновляйте статус отдельно от пользовательских презентаций — никогда не для конкретного человека, никогда не для конкретной транзакции.

Этот единственный архитектурный выбор не позволяет эмитенту или поставщику статусов узнать, какой верификатор проверял какой документ в какой момент.

Групповая конфиденциальность: требование, о котором большинство проектов забывает

Многие системы декларируют избирательное раскрытие данных внутри самой презентации, а затем молча игнорируют конфиденциальность при проверке статусов. Это существенный пробел.

Требования EUDI к конфиденциальности предусматривают, что:

• Индексы в списках статусов должны быть назначены случайным образом, чтобы индекс сам по себе никогда не становился сигналом для отслеживания.
• Каждый список должен охватывать достаточно большое число документов для обеспечения групповой конфиденциальности.
• Если список иначе окажется слишком маленьким, поставщики должны добавлять неиспользуемые записи, чтобы скрыть реальное количество документов.

Будущий МВУ не может претендовать на конфиденциальность, опираясь лишь на избирательное раскрытие данных. Если механизм отзыва утечкой выдаёт факт презентации, дизайн конфиденциальности является неполным.

Работа в офлайн-режиме — не крайний случай, а базовое требование

Любая система для путешествий, предполагающая идеальное соединение, спроектирована неудовлетворительно.

• AAMVA подтверждает, что получение данных с устройства работает без внешнего соединения как для устройства владельца, так и для считывателя, и что стандарт ISO/IEC 18013-5 требует поддержки получения данных с устройства для mDL.
• EUDI допускает, что доверяющие стороны могут работать офлайн и не иметь кэшированного списка статусов, и в этом случае рекомендует провести анализ рисков перед принятием решения.

Примите этот компромисс заблаговременно:

Невозможно одновременно обеспечить идеальную работу в офлайн-режиме и идеальную актуальность данных в реальном времени.

Любая архитектура, обещающая и то, и другое без компромисса, либо неточна, либо незаметно вновь вводит слежку. Правильный ответ — сделать актуальность входным параметром политики, а не универсальной сетевой зависимостью.

Журналы — там, где конфиденциальность незаметно нарушается

Даже превосходная статусная архитектура может быть разрушена неосторожным ведением журналов.

• EUDI требует, чтобы экземпляры доверяющих сторон удаляли уникальные элементы и временны́е метки сразу после того, как они больше не нужны, и запрещает их пересылку.
• AAMVA запрещает участникам отслеживать владельцев mDL или использование mDL, кроме случаев, предусмотренных законом, требует, чтобы органы-эмитенты минимизировали передачу статических или долгосрочных метаданных, и ограничивает доступ к журналам активности самим владельцем.
• AAMVA также требует, чтобы при удалении с устройства удалялась информация журналов и метаданные, способные раскрыть историю использования, — и чтобы это удаление было возможно в офлайн-режиме.

Это поведение на уровне протокола, а не административная рутина. Будущий МВУ должен рассматривать долгосрочные идентификаторы, временны́е метки и журналы как потенциальные инструменты слежки до тех пор, пока не будет явно доказано обратное.

Конкретная архитектура без обращения к серверу для будущего МВУ

Объединяя все принципы, вот что система должна делать на практике:

1. Выдайте базовый документ с привязкой к устройству. Привяжите документ к ключам, защищённым в безопасной среде кошелька — это обязательно по EUDI для PID и аттестаций ISO/IEC 18013-5.
2. Запрашивайте только необходимые данные с использованием свежего запроса. В транзакции OpenID4VP DCQL-запрос позволяет кошельку показать владельцу, какие атрибуты запрашиваются, а верификатор выдаёт запрос для предотвращения повторного использования (согласно текущей архитектуре mDL от NIST).
3. Создавайте краткосрочную презентацию, а не повторно используемый идентификатор. Каждая презентация должна быть специфичной для верификатора, запроса и момента времени.
4. Верифицируйте подлинность локально. Проверяйте подписи и открытые ключи эмитента в офлайн-режиме; служба доверия AAMVA создана именно для этого.
5. Проверяйте статус из кэшированных, отдельно обновляемых списков. Там, где документы слишком долгосрочны, чтобы пропустить отзыв, используйте локально кэшированные списки статусов, обновляемые по расписанию, не связанному с пользовательскими презентациями.
6. Применяйте политику рисков при недоступности актуальных данных. Сделайте офлайн-решения явной политикой верификатора, а не неструктурированными догадками.
7. Агрессивно удаляйте данные отслеживания. Удаляйте уникальные элементы транзакций и временны́е метки, когда они больше не нужны; не храните журналы, по которым можно восстановить историю передвижений.

Вот как выглядит серьёзная архитектура без обращения к серверу — многоуровневая, конфиденциальная, криптографически локальная и операционно честная в отношении офлайн-реальности.

Три паттерна, которые должны быть запрещены на уровне проектирования

Зрелая экосистема будущего МВУ должна рассматривать следующее как архитектурные просчёты, а не как варианты оптимизации:

• Обязательные обратные обращения к эмитенту при каждой презентации. Собственное руководство AAMVA по конфиденциальности объясняет, почему это недопустимо.
• Использование водительского документа в качестве стандартного входа в систему. NIST прямо предостерегает от многократного предъявления документов, содержащих персональные данные, для повседневной аутентификации.
• Хранение идентификаторов, временны́х меток и журналов, по которым можно восстановить историю презентаций. EUDI и AAMVA требуют противоположного.

Основной аргумент в одном предложении

Мгновенная верификация не должна становиться разрешением для слежки на стороне эмитента.

Будущий МВУ должен уметь:

• Подтверждать подлинность локально.
• Подтверждать владение локально.
• Проверять актуальность конфиденциально.
• Допускать офлайн-реальность.
• Функционировать корректно при отсутствии исчерпывающей информации.

Всё это не делает систему слабее. Это делает её достойной развёртывания в масштабе.

В тот момент, когда водительский документ становится инструментом записи того, кто что показал, где и когда, он перестаёт быть более безопасной версией бумажного документа. Он превращается в инфраструктуру наблюдения.

Именно этим будущий МВУ должен отказаться становиться.

Часто задаваемые вопросы

Что такое «верификация с обращением к серверу»?
Это любая система, при которой верификатор обращается к эмитенту в режиме реального времени для проверки документа. Хотя она одновременно решает вопросы подлинности и отзыва, она также позволяет эмитенту наблюдать за каждым фактом предъявления документа.

Требует ли стандарт ISO/IEC 18013-5 онлайн-контакта с эмитентом?
Нет. AAMVA подтверждает, что стандарт ISO/IEC 18013-5 требует поддержки получения данных с устройства и лишь опционально допускает серверное получение данных.

Как может работать отзыв без обращения к эмитенту?
С помощью краткосрочных документов, списков статусов аттестаций или списков отзыва аттестаций — в идеале при условии, что доверяющая сторона загружает статусные данные отдельно от пользовательских презентаций.

Почему «групповая конфиденциальность» важна для списков статусов?
Если список статусов слишком мал или его индексы предсказуемы, запрос статуса может раскрыть, какой именно документ был только что предъявлен. Случайные индексы и большие списки предотвращают это.

Является ли офлайн-верификация действительно практичной?
Да — и органы по стандартизации, включая AAMVA и EUDI, прямо требуют её. Компромисс состоит в том, что идеальная актуальность данных в реальном времени несовместима с идеальной работой в офлайн-режиме, поэтому актуальность должна стать политическим решением, а не жёсткой зависимостью.