Без перевірки «дзвінка додому»: чому майбутнє цифрове МВП не повинно звертатися до емітента при кожному використанні

Відкликання — найскладніша проблема будь-якого майбутнього цифрового Міжнародного водійського посвідчення (МВП). Найпростіший спосіб її вирішення є водночас і найнебезпечнішим: зробити емітента учасником кожної окремої презентації. Сучасний транскордонний водійський документ повинен за замовчуванням відмовлятися від цього спрощення.

Майже кожна пропозиція цифрової ідентичності містить одну й ту саму заспокійливу фразу:

«Документ можна перевірити миттєво.»

Іноді ця фраза описує справжній прогрес. Іноді — стеження з більш зручним інтерфейсом користувача.

Чинні опубліковані стандарти вже чітко зазначають, що верифікатор не повинен звертатися до емітента щоразу, коли пред’являється документ:

• Чинна архітектура 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 прямо попереджає проти повторної передачі багаторазових ідентифікаторів для повсякденного використання. Щоденна автентифікація повинна спиратися на технології, створені для цієї мети, такі як ключі доступу, а не на повторне пред’явлення документа, насиченого особистими даними.
• NIST також обрав локальну автентифікацію на пристрої замість біометричного зіставлення на стороні сервера саме тому, що локальна автентифікація зберігає конфіденційність і є операційно ефективнішою.

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

Списки статусів є правильним механізмом за замовчуванням

Коли не можна зробити все короткостроковим, потрібна інфраструктура статусів — і список статусів є правильним варіантом за замовчуванням.

Bitstring Status List v1.0 від W3C описує механізм публікації даних про статус — наприклад, про призупинення або відкликання — що зберігає конфіденційність, є компактним і високопродуктивним. Ключові властивості:

• Кожен емітент управляє списком для виданих ним документів.
• Формат добре стискається, оскільки більшість документів залишаються невідкликаними.
• Розмір списку за замовчуванням становить 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, прямо вимагають цього. Компроміс полягає в тому, що ідеальна актуальність у режимі реального часу несумісна з ідеальною офлайн-роботою, тому актуальність повинна стати рішенням на рівні політики, а не жорсткою залежністю.