Žádné ověření voláním domů: Proč budoucí digitální mezinárodní řidičský průkaz nesmí při každém použití kontaktovat vydavatele

Odvolání platnosti je nejtěžším problémem jakéhokoli budoucího digitálního mezinárodního řidičského průkazu (MŘP). Nejjednodušší způsob, jak ho vyřešit, je zároveň nejnebezpečnější: učinit z vydavatele účastníka každé jednotlivé prezentace. Moderní přeshraniční řidičský doklad by měl tento zkratka odmítat jako výchozí nastavení.

Téměř každý návrh digitální identity obsahuje stejnou uklidňující větu:

„Doklad lze ověřit okamžitě.”

Někdy tato věta popisuje skutečný pokrok. Jindy popisuje sledování s přívětivějším uživatelským rozhraním.

Dnes publikované standardy již jasně stanoví, že ověřovatel nepotřebuje kontaktovat vydavatele pokaždé, když je doklad předložen:

• Aktuální architektura mDL institutu NIST uvádí, že ověřovatel může potvrdit autentičnost a integritu důvěřováním podpisu a veřejným klíčům vydavatele — bez jakéhokoli přímého kontaktu s vydavatelem.
• AAMVA potvrzuje, že norma ISO/IEC 18013-5 vyžaduje podporu pro načítání ze zařízení a načítání ze serveru povoluje pouze volitelně.
• AAMVA také varuje, že při načítání ze serveru je vydávající orgán zapojen v reálném čase při každém použití — což znamená, že technicky může zaznamenávat, kdy byl doklad použit, jaká data byla sdílena, a dokonce vyvozovat polohu z analýzy IP adres.

To není bezvýznamná poznámka pod čarou. Je to ústřední otázka návrhu pro příští generaci přeshraničních řidičských dokladů.

Nebezpečná zkratka: Sloučení čtyř otázek do jednoho síťového volání

Špatné architektury slučují čtyři zcela odlišné otázky do jediného živého volání vydavateli:

1. Je tento doklad autentický?
2. Je osoba, která ho předkládá, oprávněným držitelem?
3. Je samotný doklad stále platný?
4. Je podkladové národní řidičské oprávnění stále v platnosti?

Špatně navržený systém odpovídá na všechny čtyři otázky voláním domů v reálném čase. Dobře navržený systém je odděluje — protože to nejsou stejné problémy a neměly by sdílet jeden mechanismus.

Autentičnost by měla být ověřována lokálně, nikoli přes síť

Doklad může být kryptograficky pravý, aniž by vydavatel transakci vůbec zaznamenal.

• Model důvěryhodnosti mDL institutu NIST uvádí, že autentičnost a integrita se ověřují na základě podpisu a veřejných klíčů vydavatele — bez nutnosti živého kontaktu s vydavatelem.
• Služba AAMVA Digital Trust Service existuje právě proto, aby ověřovatelům poskytovala přístup k platným veřejným klíčům vydavatelů bez zpětných volání při každé transakci.

Návrhový princip 1: Nepoužívejte živé připojení k řešení problému, který již řeší digitální podpisy.

Pokud ověřovatel disponuje důvěryhodnými klíči vydavatele a obdrží prezentaci odpovídající standardům, je ověření autentičnosti lokální kryptografickou operací, nikoli závislostí na síti.

Vazba na držitele by měla být prokázána lokálně, nikoli hlášena globálně

Druhá otázka — je to oprávněný držitel? — má rovněž odpověď bez využití sítě.

Aktuální architektura EUDI vyžaduje vazbu na zařízení pro PID a atestace dle ISO/IEC 18013-5. Ověřovatel žádá peněženku, aby podepsala novou výzvu pomocí soukromého klíče odpovídajícího veřejnému klíči vloženému do dokladu:

• V normě ISO/IEC 18013-5 se toto označuje jako ověření mdoc.
• V SD-JWT VC se označuje jako vazba klíče.

V obou případech je vlastnictví prokázáno lokálně a kryptograficky. Žádné osobní údaje nemusí nikdy dosáhnout k vydavateli.

Návrhový princip 2: Prokazujte vlastnictví lokálně. Neprokazujte identitu globálně.

Budoucí MŘP by měl plně využít vazbu na zařízení, lokální ověření držitele a výzvu-odpověď ověřovatele dříve, než zváží jakýkoli mechanismus na straně vydavatele.

Stav dokladu a stav řidičského oprávnění jsou dvě různé věci

Mnohé návrhy digitální identity toto rozlišení stírají, a právě tam se mýlí.

Specifikace W3C Bitstring Status List tento bod jasně formuluje: stavové informace připojené k ověřitelnému dokladu se vztahují na samotný ověřitelný doklad — nikoli nutně na podkladové oprávnění v reálném světě. Digitální doklad může být odvolán, protože byl kompromitován jeho podpisový mechanismus, zatímco podkladové řidičské oprávnění zůstává plně platné.

Budoucí MŘP proto potřebuje dvě odlišné stavové vrstvy:

• Vrstva stavu dokladu — pro samotný digitální doklad nebo kanál prezentace.
• Vrstva řidičského oprávnění — pro podkladové národní oprávnění k řízení.

Někdy se mění společně. Často nikoli. Systém, který je zaměňuje, bude přehnaně reagovat, odhalovat více dat, než je nutné, nebo obojí.

Kompromitace peněženky by se měla šířit prostřednictvím stavu — nikoli spouštět zpětná volání ověřovatelů

Budoucí MŘP také potřebuje jasnou odpověď na otázku, co se stane, když je peněženka kompromitována.

Architektura EUDI jedno řešení nabízí:

• Poskytovatel peněženky vydává atestace jednotky peněženky obsahující informace o odvolání.
• Integrita peněženky je průběžně znovu ověřována; pokud peněženka již není bezpečná, její atestace je odvolána.
• Poskytovatelé PID musí pravidelně kontrolovat, zda peněženka nebyla odvolána. Pokud ano, odvolají PID.
• Ověřením stavu PID spoléhající strana implicitně ověřuje stav peněženky.

To je vrstvení, které by měl budoucí MŘP přijmout. Nežádejte každého ověřovatele, aby nezávisle kontroloval poskytovatele peněženky. Nechte kompromitaci peněženky šířit se prostřednictvím stávajícího kanálu stavu dokladu a nechte ověřovatele konzultovat tento jediný kanál zachovávající soukromí.

Tři funkční vzory odvolání (bez zpětných volání)

EUDI vyžaduje, aby poskytovatelé používali jednu ze tří metod odvolání:

• Krátkodobé atestace — platné 24 hodin nebo méně, takže odvolání se stává nepotřebným.
• Seznam stavů atestací — zveřejněný seznam, který mohou ověřovatelé konzultovat.
• Seznam odvolání atestací — explicitní seznam odvolaných dokladů.

Pro atestace platné déle než 24 hodin vyžaduje EUDI vložení informací o odvolání, které zahrnují:

• Adresu URL, kde mohou spoléhající strany načíst seznam stavů.
• Identifikátor umísťující doklad v rámci tohoto seznamu.

Pokud spolehlivé informace o odvolání nejsou k dispozici — například když je spoléhající strana offline — EUDI ji vyzývá k provedení analýzy rizik před přijetím nebo odmítnutím dokladu.

Závěr: odvolání není jediným mechanismem, a rozhodně není ospravedlněním pro povinná zpětná volání vydavateli.

Krátkodobé jako výchozí nastavení, dlouhodobé pouze tam, kde je to nutné

Jedno z nejúčinnějších opatření na ochranu soukromí v celém systému je zároveň nejjednodušší: udržujte to, co je předloženo, krátkodobé.

• EUDI uvádí, že atestace platné 24 hodin nebo méně nevyžadují infrastrukturu pro odvolání — vyprší dříve, než by odvolání mělo smysl.
• W3C uvádí, že ověřitelné prezentace jsou typicky krátkodobé a nejsou určeny pro dlouhodobé ukládání.
• NIST výslovně varuje před opakovaným přenášením opakovaně použitelných identifikátorů pro každodenní použití. Každodenní ověřování by se mělo opírat o technologie k tomu určené, jako jsou přístupové klíče (passkeys), nikoli o opakované předkládání dokladu bohatého na identitní data.
• NIST také zvolil lokální ověření na zařízení místo biometrického porovnávání na straně serveru právě proto, že lokální ověření zachovává soukromí a je provozně efektivnější.

Návrhový princip 3: Základní doklad může mít střednědobou dobu platnosti, ale samotná prezentace by měla být krátkodobá, specifická pro ověřovatele a nepoužitelná opakovaně.

Seznamy stavů jsou správným výchozím mechanismem

Pokud nelze vše učinit krátkodobým, je potřeba stavová infrastruktura — a seznam stavů je správnou výchozí volbou.

Standard W3C Bitstring Status List v1.0 popisuje mechanismus zachovávající soukromí, prostorově úsporný a výkonný pro zveřejňování stavových dat, jako je pozastavení nebo odvolání. Mezi klíčové vlastnosti patří:

• Každý vydavatel spravuje seznam pro doklady, které vydal.
• Formát se dobře komprimuje, protože většina dokladů zůstává neodvolána.
• Výchozí velikost seznamu je 131 072 záznamů, což W3C uvádí jako dostatečné skupinové soukromí v průměrném případě.
• Tam, kde je potřeba silnější skupinové soukromí, lze použít větší seznamy.

To posouvá otázku od:

„Mohu se zeptat vydavatele na tohoto uživatele právě teď?”

k:

„Mám již dostatečně aktuální seznam stavů zachovávající soukromí, abych se mohl rozhodnout lokálně?”

To je mnohem lepší otázka — technicky i politicky.

„Žádné volání domů” je vzor stahování, nikoli heslo

Nejdůležitější pravidlo v pokynech EUDI pro ochranu soukromí je procesní, nikoli filozofické.

Spoléhající strany nesmějí žádat o seznam stavů pokaždé, když je doklad předložen. Místo toho musí:

• Stáhnout každou novou verzi seznamu jednou.
• Učinit tak v čase a z místa, které nesouvisí s žádnou prezentací uživatele.
• Distribuovat seznam interně v rámci organizace spoléhající strany.
• Načítat seznam bez ověření totožnosti spoléhající strany.

To je provozní jádro ověřování bez volání domů: obnovujte stav odděleně od prezentací uživatelů — nikdy pro každou osobu zvlášť, nikdy pro každou transakci zvlášť.

Tato jediná návrhová volba zabrání vydavateli nebo poskytovateli stavu zjistit, který ověřovatel zkontroloval který doklad v kterém okamžiku.

Skupinové soukromí: požadavek, na který většina návrhů zapomíná

Mnoho systémů hlasitě propaguje selektivní zveřejňování v rámci samotné prezentace a přitom tiše ignoruje soukromí při vyhledávání stavů. To je závažná mezera.

Požadavky EUDI na ochranu soukromí specifikují, že:

• Indexy v seznamech stavů musí být náhodně přiřazeny, aby se index sám nikdy nestal sledovacím signálem.
• Každý seznam musí pokrývat dostatečně velký počet dokladů, aby bylo zajištěno skupinové soukromí.
• Pokud by byl seznam jinak příliš malý, měli by poskytovatelé přidat nepoužité záznamy, aby skryli skutečný počet dokladů.

Budoucí MŘP nemůže tvrdit, že chrání soukromí pouze na základě selektivního zveřejňování. Pokud mechanismus odvolání prozradí událost prezentace, návrh ochrany soukromí je neúplný.

Offline provoz není okrajový případ — je to základní požadavek

Jakýkoli cestovní systém, který předpokládá dokonalé připojení, je špatně navržen.

• AAMVA potvrzuje, že načítání ze zařízení funguje bez externího připojení jak pro zařízení držitele, tak pro čtečku, a že ISO/IEC 18013-5 vyžaduje, aby mDL podporovaly načítání ze zařízení.
• EUDI připouští, že spoléhající strany mohou být offline a nemít uložený seznam stavů v mezipaměti; v takovém případě doporučuje provést analýzu rizik před rozhodnutím.

Přijměte tento kompromis včas:

Nelze mít zároveň dokonalý offline provoz a dokonalou aktuálnost v reálném čase.

Jakákoli architektura slibující obojí bez kompromisů je buď nepřesná, nebo tiše znovu zavádí sledování. Správnou reakcí je učinit z aktuálnosti vstup pro politiku, nikoli univerzální závislost na síti.

Logy jsou místem, kde soukromí tiše selhává

I vynikající stavová architektura může být zmařena neopatrným logováním.

• EUDI vyžaduje, aby instance spoléhajících stran likvidovaly unikátní prvky a časová razítka, jakmile již nejsou potřeba, a zakazuje jejich předávání.
• AAMVA zakazuje zúčastněným stranám sledovat držitele mDL nebo používání mDL s výjimkou případů vyžadovaných zákonem, vyžaduje od vydávajících orgánů minimalizaci sdílení statických nebo dlouhodobých metadat a omezuje přístup k protokolům aktivit na samotného držitele.
• AAMVA také vyžaduje, aby odstranění dat ze zařízení odstranilo informace z protokolů a metadata, která by mohla odhalit historii používání — a aby toto odstranění bylo možné provést offline.

Toto je chování protokolu, nikoli administrativní housekeeping. Budoucí MŘP musí považovat dlouhodobé identifikátory, časová razítka a logy za potenciální nástroje sledování, pokud není výslovně prokázán opak.

Konkrétní architektura bez volání domů pro budoucí MŘP

Spojením všech principů dohromady — zde je to, co by systém měl ve skutečnosti dělat:

1. Vydejte základní doklad vázaný na zařízení. Navažte doklad na klíče chráněné v bezpečném prostředí peněženky — povinné v rámci EUDI pro PID a atestace dle ISO/IEC 18013-5.
2. Vyžádejte pouze to, co je potřeba, s novou výzvou. V transakci OpenID4VP umožňuje dotaz DCQL peněžence zobrazit držiteli, které atributy jsou vyžadovány, a ověřovatel vydá výzvu k zabránění opakovanému přehrání (dle aktuální architektury mDL institutu NIST).
3. Vygenerujte krátkodobou prezentaci, nikoli opakovaně použitelný identifikátor. Každá prezentace by měla být specifická pro ověřovatele, žádost a daný okamžik.
4. Ověřte autentičnost lokálně. Ověřujte podpisy a veřejné klíče vydavatele offline; důvěryhodnostní služba AAMVA je k tomu přesně určena.
5. Kontrolujte stav z mezipaměti, samostatně obnovovaných seznamů. Tam, kde jsou doklady příliš dlouhodobé, aby bylo možné odvolání přeskočit, používejte lokálně uložené seznamy stavů obnovované podle plánu, který nesouvisí s prezentacemi uživatelů.
6. Uplatňujte politiku rizik, pokud aktuálnost není k dispozici. Učiňte z offline rozhodování explicitní politiku ověřovatele, nikoli nestrukturované dohady.
7. Agresivně odstraňujte sledovací data. Likvidujte transakčně unikátní prvky a časová razítka, jakmile již nejsou potřeba; neuchovávejte logy, které by mohly rekonstruovat historii pohybu.

Tak vypadá seriózní architektura bez volání domů — vrstvená, zachovávající soukromí, kryptograficky lokální a provozně upřímná ohledně offline reality.

Tři vzory, které by měly být zakázány již v návrhu

Vyspělý ekosystém budoucího MŘP by měl tyto vzory považovat za selhání architektury, nikoli za volby optimalizace:

• Povinná zpětná volání vydavateli při každé prezentaci. Vlastní pokyny AAMVA pro ochranu soukromí vysvětlují, proč je to škodlivé.
• Používání řidičského dokladu jako běžného přihlašovacího prostředku. NIST výslovně varuje před opakovaným předkládáním dokladů obsahujících identitní data pro každodenní ověřování.
• Uchovávání identifikátorů, časových razítek a logů, které mohou rekonstruovat historii prezentací. Jak EUDI, tak AAMVA vyžadují pravý opak.

Základní argument v jedné větě

Okamžité ověření se nesmí stát povolením pro sledování na straně vydavatele.

Budoucí MŘP by měl být schopen:

• Prokázat autentičnost lokálně.
• Prokázat vlastnictví lokálně.
• Ověřit aktuálnost soukromě.
• Tolerovat offline realitu.
• Fungovat spolehlivě i v případě, kdy dokonalé informace nejsou k dispozici.

Nic z toho systém neoslabuje. Naopak ho to činí hodným nasazení ve velkém měřítku.

Ve chvíli, kdy se řidičský doklad stane nástrojem pro zaznamenávání toho, kdo co kde a kdy ukázal, přestává být bezpečnější verzí papírového dokladu. Stává se infrastrukturou pro sledování.

Právě tím se budoucí MŘP stát odmítá.

Často kladené otázky

Co je „ověření voláním domů”?
Jedná se o jakýkoli návrh, v němž ověřovatel kontaktuje vydavatele v reálném čase za účelem ověření dokladu. Přestože zároveň řeší autentičnost i odvolání, umožňuje vydavateli sledovat každou událost prezentace.

Vyžaduje ISO/IEC 18013-5 online kontakt s vydavatelem?
Ne. AAMVA potvrzuje, že ISO/IEC 18013-5 vyžaduje podporu pro načítání ze zařízení a načítání ze serveru povoluje pouze volitelně.

Jak může odvolání fungovat bez kontaktování vydavatele?
Prostřednictvím krátkodobých dokladů, seznamů stavů atestací nebo seznamů odvolání atestací — ideálně tak, že spoléhající strana stahuje stavová data odděleně od prezentací uživatelů.

Proč je „skupinové soukromí” důležité pro seznamy stavů?
Pokud je seznam stavů příliš malý nebo jeho indexy jsou předvídatelné, může dotaz na stav prozradit, který konkrétní doklad byl právě předložen. Náhodné indexy a velké seznamy tomu zabraňují.

Je offline ověřování skutečně praktické?
Ano — a normalizační orgány včetně AAMVA a EUDI to výslovně vyžadují. Kompromis spočívá v tom, že dokonalá aktuálnost v reálném čase je neslučitelná s dokonalým offline provozem, takže aktuálnost musí být politickým rozhodnutím, nikoli pevnou závislostí.