Weryfikacja bez kontaktu z wystawcą: Dlaczego przyszły cyfrowy MDP nie może dzwonić do wystawcy przy każdym użyciu

Unieważnienie to najtrudniejszy problem w każdym przyszłym cyfrowym Międzynarodowym Dokumencie Prawa Jazdy (MDP). Najprostszy sposób jego rozwiązania jest zarazem najbardziej niebezpieczny: uczynienie wystawcy uczestnikiem każdej pojedynczej prezentacji. Nowoczesne transgraniczne poświadczenie kierowcy powinno domyślnie odrzucać ten skrót.

Niemal każda propozycja cyfrowej tożsamości zawiera to samo uspokajające zdanie:

„Poświadczenie można zweryfikować natychmiastowo.”

Czasem zdanie to opisuje autentyczny postęp. Czasem opisuje inwigilację z bardziej przyjaznym interfejsem użytkownika.

Opublikowane dziś standardy wyraźnie wskazują, że weryfikator nie musi kontaktować się z wystawcą za każdym razem, gdy poświadczenie jest okazywane:

• Aktualna architektura mDL według NIST stwierdza, że weryfikator może potwierdzić autentyczność i integralność, ufając podpisowi wystawcy i kluczom publicznym — bez jakiegokolwiek bezpośredniego kontaktu z wystawcą.
• AAMVA potwierdza, że norma ISO/IEC 18013-5 wymaga obsługi pobierania z urządzenia i jedynie opcjonalnie dopuszcza pobieranie z serwera.
• AAMVA ostrzega również, że w modelu pobierania z serwera organ wystawiający uczestniczy w czasie rzeczywistym w każdym użyciu — co oznacza, że może technicznie rejestrować, kiedy poświadczenie jest używane, jakie dane są udostępniane, a nawet wnioskować o lokalizacji na podstawie analizy adresu IP.

To nie jest drobny przypis. To centralne pytanie projektowe dla następnej generacji transgranicznych poświadczeń kierowcy.

Niebezpieczny skrót: Scalenie czterech pytań w jedno połączenie sieciowe

Wadliwe architektury łączą cztery zupełnie różne pytania w jedno połączenie na żywo z wystawcą:

1. Czy to poświadczenie jest autentyczne?
2. Czy osoba je okazująca jest uprawnioną posiadaczką?
3. Czy samo poświadczenie jest nadal ważne?
4. Czy leżące u podstaw krajowe uprawnienie do kierowania pojazdem jest nadal w mocy?

Źle zaprojektowany system odpowiada na wszystkie cztery pytania, dzwoniąc do wystawcy w czasie rzeczywistym. Dobrze zaprojektowany system rozdziela je — ponieważ nie są to te same problemy i nie powinny korzystać z tego samego mechanizmu.

Autentyczność powinna być weryfikowana lokalnie, nie przez sieć

Poświadczenie może być kryptograficznie autentyczne bez jakiejkolwiek obserwacji transakcji przez wystawcę.

• Model zaufania mDL według NIST stwierdza, że autentyczność i integralność są sprawdzane na podstawie podpisu wystawcy i kluczy publicznych — bez konieczności nawiązywania połączenia z wystawcą na żywo.
• Usługa AAMVA Digital Trust Service istnieje właśnie po to, aby zapewnić weryfikatorom dostęp do ważnych kluczy publicznych wystawcy bez wywołań zwrotnych przy każdej transakcji.

Zasada projektowania 1: Nie używaj połączenia na żywo do rozwiązywania problemu, który podpisy już rozwiązują.

Jeżeli weryfikator dysponuje zaufanymi kluczami wystawcy i otrzymuje prezentację zgodną ze standardami, autentyczność jest lokalnym sprawdzeniem kryptograficznym, a nie zależnością sieciową.

Powiązanie z posiadaczem powinno być udowadniane lokalnie, nie zgłaszane globalnie

Drugie pytanie — czy to jest uprawniony posiadacz? — również ma odpowiedź niewymagającą sieci.

Obecna architektura EUDI nakazuje powiązanie z urządzeniem dla PID-ów i poświadczeń zgodnych z normą ISO/IEC 18013-5. Weryfikator żąda od portfela podpisania nowego wyzwania przy użyciu klucza prywatnego odpowiadającego kluczowi publicznemu osadzonemu w poświadczeniu:

• W normie ISO/IEC 18013-5 nazywa się to uwierzytelnianiem mdoc.
• W SD-JWT VC nazywa się to powiązaniem klucza.

W obu przypadkach posiadanie jest udowadniane lokalnie i kryptograficznie. Żadne dane osobowe nie muszą nigdy docierać do wystawcy.

Zasada projektowania 2: Udowadniaj posiadanie lokalnie. Nie potwierdzaj tożsamości globalnie.

Przyszły MDP powinien wyczerpać możliwości powiązania z urządzeniem, lokalnego uwierzytelniania posiadacza i odpowiedzi na wyzwanie weryfikatora zanim rozważy jakikolwiek mechanizm po stronie wystawcy.

Status poświadczenia i status uprawnienia do kierowania to dwie różne rzeczy

Wiele projektów systemów tożsamości cyfrowej zaciera to rozróżnienie i właśnie tutaj popełniają błąd.

Specyfikacja W3C Bitstring Status List wyraźnie to podkreśla: informacje o statusie dołączone do weryfikowalnego poświadczenia dotyczą samego weryfikowalnego poświadczenia — niekoniecznie leżącego u podstaw uprawnienia w świecie rzeczywistym. Cyfrowe poświadczenie może zostać unieważnione, ponieważ jego mechanizm podpisywania został naruszony, podczas gdy leżące u podstaw uprawnienie do kierowania pozostaje w pełni ważne.

Przyszły MDP potrzebuje zatem dwóch odrębnych warstw statusu:

• Warstwa statusu poświadczenia — dla samego poświadczenia cyfrowego lub kanału prezentacji.
• Warstwa uprawnień do kierowania — dla leżącego u podstaw krajowego uprawnienia do prowadzenia pojazdu.

Niekiedy zmieniają się jednocześnie. Często jednak nie. System, który je myli, będzie reagował nadmiernie, ujawniał więcej danych niż to konieczne lub będzie robił jedno i drugie.

Naruszenie portfela powinno być propagowane przez warstwę statusu — nie wyzwalać wywołań zwrotnych weryfikatora

Przyszły MDP potrzebuje również jasnej odpowiedzi na pytanie, co się dzieje, gdy portfel zostaje naruszony.

Architektura EUDI dostarcza takiej odpowiedzi:

• Dostawca portfela wydaje Poświadczenia Jednostki Portfela zawierające informacje o unieważnieniu.
• Integralność portfela jest regularnie weryfikowana; jeśli portfel nie jest już bezpieczny, jego poświadczenie zostaje unieważnione.
• Dostawcy PID muszą regularnie sprawdzać, czy portfel nie został unieważniony. Jeśli tak, unieważniają PID.
• Weryfikując status PID, strona ufająca pośrednio weryfikuje status portfela.

To jest warstwy, którą przyszły MDP powinien przyjąć. Nie należy prosić każdego weryfikatora o niezależne sprawdzanie dostawcy portfela. Pozwól, aby naruszenie portfela propagowało się przez istniejący potok statusu poświadczenia, a weryfikatorzy konsultowali ten jeden kanał chroniący prywatność.

Trzy wykonalne wzorce unieważniania (bez wywołań zwrotnych)

EUDI wymaga, aby dostawcy stosowali jedną z trzech metod unieważniania:

• Poświadczenia krótkotrwałe — ważne przez 24 godziny lub krócej, dzięki czemu unieważnianie staje się zbędne.
• Lista statusów poświadczenia — opublikowana lista, z którą weryfikatorzy mogą się konsultować.
• Lista unieważnień poświadczenia — jawna lista unieważnionych poświadczeń.

W przypadku poświadczeń ważnych dłużej niż 24 godziny EUDI wymaga osadzenia informacji o unieważnieniu zawierającej:

• Adres URL, pod którym strony ufające mogą pobrać listę statusów.
• Identyfikator lokalizujący poświadczenie na tej liście.

Jeżeli wiarygodne informacje o unieważnieniu są niedostępne — na przykład gdy strona ufająca jest offline — EUDI nakazuje stronie ufającej przeprowadzenie analizy ryzyka przed przyjęciem lub odrzuceniem poświadczenia.

Wniosek: unieważnianie nie jest jednym mechanizmem, a z pewnością nie uzasadnieniem dla obowiązkowych wywołań zwrotnych do wystawcy.

Krótkotrwałe domyślnie, długotrwałe tylko tam, gdzie to konieczne

Jednym z najskuteczniejszych środków ochrony prywatności w całym stosie jest zarazem najprostszy: utrzymuj krótki czas życia prezentowanych danych.

• EUDI stwierdza, że poświadczenia ważne przez 24 godziny lub krócej nie wymagają infrastruktury unieważniania — wygasają, zanim unieważnianie miałoby znaczenie.
• W3C stwierdza, że weryfikowalne prezentacje są zazwyczaj krótkotrwałe i nieprzeznaczone do długoterminowego przechowywania.
• NIST wyraźnie ostrzega przed wielokrotnym przesyłaniem identyfikatorów wielokrotnego użytku do codziennego stosowania. Codzienna autentykacja powinna opierać się na technologiach do tego przeznaczonych, takich jak klucze dostępu, a nie na wielokrotnym okazywaniu poświadczenia bogatego w dane tożsamości.
• NIST wybrał również lokalną autentykację na urządzeniu zamiast dopasowywania biometrycznego po stronie serwera właśnie dlatego, że autentykacja lokalna zachowuje prywatność i jest operacyjnie bardziej wydajna.

Zasada projektowania 3: Bazowe poświadczenie może mieć średni okres ważności, ale sama prezentacja powinna być krótkotrwała, specyficzna dla weryfikatora i niepowtarzalna.

Listy statusów są właściwym domyślnym mechanizmem

Gdy nie można sprawić, aby wszystko było krótkotrwałe, potrzebna jest infrastruktura statusu — a lista statusów jest właściwym rozwiązaniem domyślnym.

Specyfikacja W3C Bitstring Status List v1.0 opisuje mechanizm chroniący prywatność, wydajny przestrzennie i wysokowydajny, służący do publikowania danych statusu, takich jak zawieszenie lub unieważnienie. Kluczowe właściwości obejmują:

• Każdy wystawca zarządza listą dla wydanych przez siebie poświadczeń.
• Format dobrze się kompresuje, ponieważ większość poświadczeń pozostaje nieunieważniona.
• Domyślny rozmiar listy wynosi 131 072 wpisy, co według W3C zapewnia odpowiednią prywatność grupową w przeciętnym przypadku.
• Większe listy mogą być używane tam, gdzie potrzebna jest silniejsza prywatność grupowa.

Zmienia to pytanie z:

„Czy mogę zapytać wystawcę o tego użytkownika teraz?”

na:

„Czy mam już wystarczająco aktualną, chroniącą prywatność listę statusów, aby podjąć decyzję lokalnie?”

To znacznie lepsze pytanie — zarówno technicznie, jak i politycznie.

„Bez kontaktu z wystawcą” to wzorzec pobierania, nie slogan

Najważniejsza zasada w wytycznych EUDI dotyczących prywatności ma charakter proceduralny, nie filozoficzny.

Strony ufające nie mogą żądać listy statusów za każdym razem, gdy prezentowane jest poświadczenie. Zamiast tego muszą:

• Pobierać każdą nową wersję listy jednorazowo.
• Robić to w czasie i z lokalizacji niezwiązanych z żadną prezentacją użytkownika.
• Dystrybuować listę wewnętrznie w organizacji strony ufającej.
• Pobierać listę bez uwierzytelniania strony ufającej.

To jest operacyjny rdzeń weryfikacji bez kontaktu z wystawcą: odświeżaj status oddzielnie od prezentacji użytkownika — nigdy per osoba, nigdy per transakcja.

Ten jeden wybór projektowy uniemożliwia wystawcy lub dostawcy statusu dowiedzenie się, który weryfikator sprawdzał które poświadczenie w danym momencie.

Prywatność grupowa: wymóg, o którym większość projektów zapomina

Wiele systemów chwali się selektywnym ujawnianiem w samej prezentacji, po czym po cichu ignoruje prywatność przy przeglądaniu statusów. To znacząca luka.

Wymagania EUDI dotyczące prywatności określają, że:

• Indeksy na listach statusów muszą być przypisywane losowo, aby sam indeks nie stawał się sygnałem śledzenia.
• Każda lista musi obejmować wystarczająco dużą liczbę poświadczeń, aby zapewnić prywatność grupową.
• Jeżeli lista byłaby zbyt mała, dostawcy powinni dodawać nieużywane wpisy, aby ukryć rzeczywistą liczbę poświadczeń.

Przyszły MDP nie może twierdzić, że chroni prywatność jedynie na podstawie selektywnego ujawniania. Jeśli mechanizm unieważniania ujawnia zdarzenie prezentacji, projekt prywatności jest niekompletny.

Praca w trybie offline nie jest przypadkiem brzegowym — to wymaganie podstawowe

Każdy system podróży zakładający doskonałą łączność jest źle zaprojektowany.

• AAMVA potwierdza, że pobieranie z urządzenia działa bez zewnętrznej łączności zarówno dla urządzenia posiadacza, jak i czytnika, oraz że norma ISO/IEC 18013-5 wymaga obsługi pobierania z urządzenia przez mDL-e.
• EUDI przyjmuje, że strony ufające mogą być offline i nie posiadać zbuforowanej listy statusów; w takim przypadku zaleca przeprowadzenie analizy ryzyka przed podjęciem decyzji.

Zaakceptuj ten kompromis od razu:

Nie można mieć jednocześnie doskonałej pracy w trybie offline i doskonałej aktualności w czasie rzeczywistym.

Każda architektura obiecująca jedno i drugie bez kompromisu jest albo nieprecyzyjna, albo po cichu przywraca inwigilację. Właściwą odpowiedzią jest uczynienie aktualności parametrem polityki, a nie powszechną zależnością sieciową.

Logi to miejsce, gdzie prywatność po cichu zawodzi

Nawet doskonała architektura statusów może zostać unicestwiona przez niedbałe logowanie.

• EUDI wymaga, aby instancje stron ufających usuwały unikalne elementy i znaczniki czasu natychmiast po tym, gdy nie są już potrzebne, i zabrania ich przekazywania dalej.
• AAMVA zabrania podmiotom śledzenia posiadaczy mDL lub korzystania z mDL, z wyjątkiem przypadków wymaganych przez prawo, wymaga od organów wydających minimalizowania udostępniania statycznych lub długotrwałych metadanych oraz ogranicza dostęp do dzienników aktywności do samego posiadacza.
• AAMVA wymaga również, aby usunięcie danych z urządzenia usuwało informacje z dzienników i metadane, które mogłyby ujawnić historię użytkowania — oraz aby usunięcie to było możliwe w trybie offline.

To jest zachowanie protokołu, a nie administracyjne porządkowanie. Przyszły MDP musi traktować długotrwałe identyfikatory, znaczniki czasu i logi jako potencjalne narzędzia śledzenia, dopóki nie zostanie wyraźnie udowodnione coś przeciwnego.

Konkretna architektura bez kontaktu z wystawcą dla przyszłego MDP

Łącząc wszystkie zasady, oto co system powinien faktycznie robić:

1. Wydaj bazowe poświadczenie powiązane z urządzeniem. Powiąż poświadczenie z kluczami chronionymi w bezpiecznym środowisku portfela — obowiązkowe w EUDI dla PID-ów i poświadczeń zgodnych z normą ISO/IEC 18013-5.
2. Żądaj tylko tego, co potrzebne, z nowym wyzwaniem. W transakcji OpenID4VP zapytanie DCQL pozwala portfelowi pokazać posiadaczowi, które atrybuty są żądane, a weryfikator wydaje wyzwanie, aby zapobiec powtórzeniu (zgodnie z aktualną architekturą mDL według NIST).
3. Generuj krótkotrwałą prezentację, nie identyfikator wielokrotnego użytku. Każda prezentacja powinna być specyficzna dla weryfikatora, żądania i danego momentu.
4. Weryfikuj autentyczność lokalnie. Sprawdzaj podpisy wystawcy i klucze publiczne offline; usługa zaufania AAMVA jest zbudowana dokładnie do tego celu.
5. Sprawdzaj status na podstawie zbuforowanych, oddzielnie odświeżanych list. Tam, gdzie poświadczenia są zbyt długotrwałe, aby pomijać unieważnianie, używaj lokalnie zbuforowanych list statusów odświeżanych według harmonogramu niezwiązanego z prezentacjami użytkownika.
6. Stosuj politykę ryzyka, gdy aktualność jest niedostępna. Podejmuj decyzje w trybie offline w oparciu o jawną politykę weryfikatora, a nie nieustrukturyzowane domysły.
7. Agresywnie usuwaj dane śledzące. Wyrzucaj unikalne elementy transakcji i znaczniki czasu, gdy nie są już potrzebne; nie przechowuj logów, które mogłyby odtworzyć historię ruchu.

Tak wygląda poważna architektura bez kontaktu z wystawcą — warstwowa, chroniąca prywatność, kryptograficznie lokalna i operacyjnie szczera wobec rzeczywistości trybu offline.

Trzy wzorce, które powinny być zakazane przez projekt

Dojrzały ekosystem przyszłych MDP powinien traktować je jako błędy architektoniczne, a nie wybory optymalizacyjne:

• Obowiązkowe wywołania zwrotne do wystawcy przy każdej prezentacji. Własne wytyczne AAMVA dotyczące prywatności wyjaśniają, dlaczego jest to szkodliwe.
• Używanie poświadczenia kierowcy jako rutynowego logowania. NIST wyraźnie ostrzega przed wielokrotnym okazywaniem poświadczeń zawierających dane tożsamości do codziennej autentykacji.
• Przechowywanie identyfikatorów, znaczników czasu i logów mogących odtworzyć historię prezentacji. Zarówno EUDI, jak i AAMVA wymagają czegoś odwrotnego.

Główny argument w jednym zdaniu

Natychmiastowa weryfikacja nie może stać się przyzwoleniem na inwigilację po stronie wystawcy.

Przyszły MDP powinien być w stanie:

• Udowodnić autentyczność lokalnie.
• Udowodnić posiadanie lokalnie.
• Sprawdzić aktualność w sposób chroniący prywatność.
• Tolerować rzeczywistość trybu offline.
• Funkcjonować sprawnie, gdy doskonałe informacje są niedostępne.

Nic z tego nie osłabia systemu. Sprawia, że warto wdrożyć go na dużą skalę.

W chwili, gdy poświadczenie kierowcy staje się narzędziem do rejestrowania, kto co okazał, gdzie i kiedy, przestaje być bezpieczniejszą wersją dokumentu papierowego. Staje się infrastrukturą obserwacji.

To właśnie jest to, czym przyszły MDP powinien odmówić zostania.

Często zadawane pytania

Co to jest „weryfikacja z kontaktem z wystawcą”?
To każdy projekt, w którym weryfikator kontaktuje się z wystawcą w czasie rzeczywistym w celu zweryfikowania poświadczenia. Choć rozwiązuje jednocześnie kwestię autentyczności i unieważniania, pozwala też wystawcy obserwować każde zdarzenie prezentacji.

Czy norma ISO/IEC 18013-5 wymaga kontaktu online z wystawcą?
Nie. AAMVA potwierdza, że norma ISO/IEC 18013-5 wymaga obsługi pobierania z urządzenia i jedynie opcjonalnie dopuszcza pobieranie z serwera.

Jak może działać unieważnianie bez kontaktowania się z wystawcą?
Poprzez poświadczenia krótkotrwałe, listy statusów poświadczeń lub listy unieważnień poświadczeń — najlepiej gdy strona ufająca pobiera dane statusu oddzielnie od prezentacji użytkownika.

Dlaczego „prywatność grupowa” jest ważna w przypadku list statusów?
Jeśli lista statusów jest zbyt mała lub jej indeksy są przewidywalne, żądanie statusu może ujawnić, które konkretne poświadczenie zostało właśnie zaprezentowane. Losowe indeksy i duże listy temu zapobiegają.

Czy weryfikacja offline jest naprawdę praktyczna?
Tak — i organy normalizacyjne, w tym AAMVA i EUDI, wyraźnie tego wymagają. Kompromis polega na tym, że doskonała aktualność w czasie rzeczywistym jest niekompatybilna z doskonałą pracą w trybie offline, dlatego aktualność musi stać się decyzją polityczną, a nie twardą zależnością.