Žiadne overovanie „call-home": Prečo budúci digitálny medzinárodný vodičský preukaz nesmie pri každom použití kontaktovať vydavateľa

Revokácia je najťažším problémom každého budúceho digitálneho medzinárodného vodičského preukazu (MVP). Najjednoduchší spôsob, ako ho vyriešiť, je zároveň najnebezpečnejší: spraviť z vydavateľa účastníka každej jednotlivej prezentácie. Moderné cezhraničné vodičské poverenie by malo tento skratku odmietnuť ako predvolené nastavenie.

Takmer každý návrh digitálnej identity obsahuje rovnakú uisťujúcu vetu:

„Poverenie je možné okamžite overiť.”

Niekedy táto veta opisuje skutočný pokrok. Niekedy opisuje sledovanie s prívetivejším používateľským rozhraním.

Dnes publikované normy už jasne uvádzajú, že overovateľ nemusí pri každom predložení poverenia kontaktovať vydavateľa:

• Aktuálna architektúra mDL podľa NIST uvádza, že overovateľ môže overiť pravosť a integritu dôverou v podpis vydavateľa a verejné kľúče — bez akéhokoľvek priameho kontaktu s vydavateľom.
• AAMVA potvrdzuje, že norma ISO/IEC 18013-5 vyžaduje podporu načítania zo zariadenia a voliteľne umožňuje iba načítanie zo servera.
• AAMVA tiež varuje, že pri načítaní zo servera je vydávajúci orgán zapojený v reálnom čase pri každom použití — čo znamená, že technicky môže zaznamenávať, kedy bolo poverenie použité, aké údaje boli zdieľané, a dokonca odvodiť polohu z analýzy IP adries.

To nie je nepodstatná poznámka pod čiarou. Je to ústredná dizajnová otázka pre novú generáciu cezhraničných vodičských poverení.

Nebezpečná skratka: Zlúčenie štyroch otázok do jedného sieťového volania

Zlé architektúry spájajú štyri veľmi odlišné otázky do jedného živého volania na vydavateľa:

1. Je toto poverenie pravé?
2. Je osoba, ktorá ho predkladá, oprávneným držiteľom?
3. Je samotné poverenie stále platné?
4. Je základné národné vodičské oprávnenie stále v platnosti?

Zle navrhnutý systém odpovedá na všetky štyri otázky tým, že v reálnom čase kontaktuje domovský server. Dobre navrhnutý systém ich oddeľuje — pretože nejde o rovnaký problém a nemali by zdieľať rovnaký mechanizmus.

Pravosť by mala byť overovaná lokálne, nie cez sieť

Poverenie môže byť kryptograficky pravé bez toho, aby vydavateľ transakciu vôbec zaznamenal.

• Model dôvery mDL podľa NIST uvádza, že pravosť a integrita sú overované z podpisu vydavateľa a verejných kľúčov — bez potreby živého kontaktu s vydavateľom.
• Služba digitálnej dôvery AAMVA (Digital Trust Service) existuje práve preto, aby overovateľom poskytla prístup k platným verejným kľúčom vydavateľa bez spätných volaní pri každej transakcii.

Princíp návrhu 1: Nepoužívajte živé pripojenie na riešenie problému, ktorý už riešia podpisy.

Ak overovateľ vlastní dôveryhodné kľúče vydavateľa a prijme prezentáciu v súlade s normami, overenie pravosti je lokálna kryptografická kontrola, nie závislosť na sieti.

Viazanosť na držiteľa by mala byť preukázaná lokálne, nie hlásená globálne

Druhá otázka — je toto oprávnený držiteľ? — má tiež odpoveď bez potreby siete.

Aktuálna architektúra EUDI nariaďuje viazanosť na zariadenie pre PID a atestácie podľa ISO/IEC 18013-5. Overovateľ požiada peňaženku, aby podpísala čerstvú výzvu pomocou súkromného kľúča zodpovedajúceho verejnému kľúču vloženému do poverenia:

• V norme ISO/IEC 18013-5 sa to nazýva autentifikácia mdoc.
• V SD-JWT VC sa to nazýva viazanosť kľúča.

V oboch prípadoch je držba preukázaná lokálne a kryptograficky. Žiadne osobné údaje nikdy nemusia dosiahnuť vydavateľa.

Princíp návrhu 2: Preukazujte držbu lokálne. Nepreukazujte identitu globálne.

Budúci MVP by mal vyčerpať viazanosť na zariadenie, lokálnu autentifikáciu držiteľa a výzvu-odpoveď overovateľa skôr, než zváži akýkoľvek mechanizmus na strane vydavateľa.

Stav poverenia a stav vodičského oprávnenia sú dve rozdielne veci

Mnohé návrhy digitálnej identity toto rozlíšenie stierajú, a práve tam robia chybu.

Špecifikácia W3C Bitstring Status List to jasne uvádza: informácie o stave priložené k overiteľnému povereniu sa vzťahujú na samotné overiteľné poverenie — nie nevyhnutne na základné oprávnenie v reálnom svete. Digitálne poverenie môže byť odvolané, pretože jeho podpisovací mechanizmus bol kompromitovaný, zatiaľ čo základné vodičské oprávnenie zostáva úplne platné.

Budúci MVP preto potrebuje dve odlišné stavové vrstvy:

• Vrstva stavu poverenia — pre samotné digitálne poverenie alebo kanál prezentácie.
• Vrstva vodičského oprávnenia — pre základné národné oprávnenie na riadenie vozidla.

Niekedy sa menia súčasne. Často sa nemenia. Systém, ktorý ich zamieňa, bude nadmerne reagovať, odhalí viac údajov, ako je potrebné, alebo oboje.

Kompromitácia peňaženky by mala byť kaskádovaná cez stav — nie spúšťať spätné volania overovateľom

Budúci MVP tiež potrebuje jasné riešenie pre prípad kompromitácie peňaženky.

Architektúra EUDI ho poskytuje:

• Poskytovateľ peňaženky vydáva atestácie jednotky peňaženky obsahujúce informácie o odvolaní.
• Integrita peňaženky je priebežne overovaná; ak peňaženka už nie je bezpečná, jej atestácia je odvolaná.
• Poskytovatelia PID musia pravidelne kontrolovať, či peňaženka bola odvolaná. Ak áno, odvolajú aj PID.
• Overením stavu PID závislá strana implicitne overuje stav peňaženky.

Toto je vrstvenie, ktoré by mal budúci MVP prijať. Nežiadajte každého overovateľa, aby nezávisle kontroloval poskytovateľa peňaženky. Nechajte kompromitáciu peňaženky preniknúť cez existujúci kanál stavu poverenia a nechajte overovateľov konzultovať tento jediný kanál zachovávajúci súkromie.

Tri funkčné vzory revokácie (bez potreby spätných volaní)

EUDI vyžaduje, aby poskytovatelia používali jednu z troch metód revokácie:

• Krátkodobé atestácie — platné 24 hodín alebo menej, takže revokácia sa stáva zbytočnou.
• Zoznam stavov atestácií — publikovaný zoznam, ktorý môžu overovateľa konzultovať.
• Zoznam odvolaných atestácií — explicitný zoznam odvolaných poverení.

Pre atestácie platné dlhšie ako 24 hodín EUDI vyžaduje vloženie informácií o odvolaní, ktoré obsahujú:

• Adresu URL, kde môžu závislé strany načítať zoznam stavov.
• Identifikátor umiestnenia poverenia v rámci tohto zoznamu.

Ak spoľahlivé informácie o odvolaní nie sú k dispozícii — napríklad keď je závislá strana offline — EUDI ju usmerňuje vykonať analýzu rizík pred prijatím alebo odmietnutím poverenia.

Záver: revokácia nie je jediný mechanizmus, a rozhodne nie je ospravedlnením pre povinné spätné volania vydavateľovi.

Krátkodobé ako predvolené, dlhodobé iba tam, kde je to nevyhnutné

Jedno z najúčinnejších opatrení na ochranu súkromia v celom zásobníku je zároveň najjednoduchšie: uchovávajte to, čo je prezentované, krátkodobo.

• EUDI uvádza, že atestácie platné 24 hodín alebo menej nevyžadujú infraštruktúru revokácie — expirujú skôr, ako by revokácia mala zmysel.
• W3C uvádza, že overiteľné prezentácie sú zvyčajne krátkodobé a nie sú určené na dlhodobé ukladanie.
• NIST výslovne varuje pred opakovaným prenášaním opakovane použiteľných identifikátorov pri bežnom používaní. Každodenná autentifikácia by mala spoliehať na technológie určené na tento účel, ako sú passkeys, nie na opakované predkladanie poverenia bohatého na identitu.
• NIST tiež zvolil lokálnu autentifikáciu zariadenia pred biometrickým párovaním na strane servera práve preto, že lokálna autentifikácia chráni súkromie a je prevádzkovo efektívnejšia.

Princíp návrhu 3: Základné poverenie môže mať strednodobú platnosť, ale samotná prezentácia by mala byť krátkodobá, špecifická pre overovateľa a neopakovateľná.

Zoznamy stavov sú správnym predvoleným mechanizmom

Keď nemôžete urobiť všetko krátkodobým, potrebujete stavovú infraštruktúru — a zoznam stavov je správnou predvolenou voľbou.

W3C’s Bitstring Status List v1.0 opisuje mechanizmus zachovávajúci súkromie, priestorovo úsporný a vysokovýkonný na publikovanie stavových údajov, ako je pozastavenie alebo odvolanie. Kľúčové vlastnosti zahŕňajú:

• Každý vydavateľ spravuje zoznam pre poverenia, ktoré vydal.
• Formát sa dobre komprimuje, keďže väčšina poverení zostáva neodvolaná.
• Predvolená veľkosť zoznamu je 131 072 záznamov, čo podľa W3C v priemernom prípade poskytuje primerané skupinové súkromie.
• Pre prípad, kde je potrebné silnejšie skupinové súkromie, možno použiť väčšie zoznamy.

Tým sa otázka mení z:

„Môžem sa teraz opýtať vydavateľa na tohto používateľa?”

na:

„Mám už dostatočne aktuálny zoznam stavov zachovávajúci súkromie, aby som sa rozhodol lokálne?”

To je oveľa lepšia otázka — technicky aj politicky.

„Žiadne call-home” je vzor sťahovania, nie heslo

Najdôležitejšie pravidlo v usmerneniach EUDI o súkromí je procedurálne, nie filozofické.

Závislé strany nesmú žiadať zoznam stavov pri každom predložení poverenia. Namiesto toho musia:

• Stiahnuť každú novú verziu zoznamu raz.
• Urobiť tak v čase a z miesta, ktoré nesúvisí so žiadnou prezentáciou používateľa.
• Distribuovať zoznam interne v rámci organizácie závislej strany.
• Načítať zoznam bez autentifikácie závislej strany.

Toto je prevádzkové jadro overovania bez call-home: obnovujte stav oddelene od prezentácií používateľov — nikdy per osoba, nikdy per transakcia.

Toto jediné rozhodnutie o návrhu zabraňuje vydavateľovi alebo poskytovateľovi stavu dozvedieť sa, ktorý overovateľ kontroloval ktoré poverenie v akom okamihu.

Skupinové súkromie: Požiadavka, na ktorú väčšina návrhov zabúda

Mnohé systémy hlasne propagujú selektívne zverejňovanie vnútri samotnej prezentácie a potom ticho ignorujú súkromie pri vyhľadávaní stavov. To je závažná medzera.

Požiadavky EUDI na súkromie špecifikujú, že:

• Indexy v zoznamoch stavov musia byť náhodne priraďované, aby sa samotný index nikdy nestal sledovacím signálom.
• Každý zoznam musí pokrývať dostatočne veľký počet poverení na zabezpečenie skupinového súkromia.
• Ak by inak bol zoznam príliš malý, poskytovatelia by mali pridať nepoužívané záznamy, aby zakryli skutočný počet poverení.

Budúci MVP nemôže tvrdiť, že chráni súkromie iba na základe selektívneho zverejňovania. Ak mechanizmus revokácie odhalí udalosť prezentácie, dizajn ochrany súkromia je neúplný.

Offline prevádzka nie je okrajový prípad — je to základná požiadavka

Každý cestovný systém, ktorý predpokladá dokonalé pripojenie, je zle navrhnutý.

• AAMVA potvrdzuje, že načítanie zo zariadenia funguje bez externého pripojenia pre zariadenie držiteľa aj čítačku, a že norma ISO/IEC 18013-5 vyžaduje, aby mDL podporoval načítanie zo zariadenia.
• EUDI akceptuje, že závislé strany môžu byť offline a nemajú uložený zoznam stavov v cache; v takom prípade odporúča analýzu rizík pred rozhodnutím.

Prijmite tento kompromis včas:

Nemôžete mať zároveň dokonalú offline prevádzku a dokonalú aktuálnosť v reálnom čase.

Každá architektúra sľubujúca oboje bez kompromisov je buď nepresná, alebo potichu znovu zavádza sledovanie. Správna odpoveď je urobiť z aktuálnosti vstup pre politiku, nie univerzálnu závislosť na sieti.

Záznamy sú miestom, kde súkromie ticho zlyháva

Aj výborná stavová architektúra môže byť zničená neopatrným zaznamenávaním.

• EUDI vyžaduje, aby inštancie závislých strán vymazali jedinečné prvky a časové pečiatky hneď, ako už nie sú potrebné, a zakazuje ich ďalšie posielanie.
• AAMVA zakazuje zainteresovaným stranám sledovať držiteľov mDL alebo ich používanie s výnimkou prípadov vyžadovaných zákonom, vyžaduje, aby vydávajúce orgány minimalizovali zdieľanie statických alebo dlhodobých metadát, a obmedzuje prístup k záznamu aktivít iba na držiteľa.
• AAMVA tiež vyžaduje, aby pri mazaní na zariadení boli odstránené informácie záznamu a metadáta, ktoré by mohli odhaliť históriu používania — a aby toto mazanie bolo možné aj offline.

Toto je správanie protokolu, nie administratívna poriadková práca. Budúci MVP musí považovať dlhodobé identifikátory, časové pečiatky a záznamy za potenciálne sledovacie nástroje, pokiaľ nie je preukázaný opak.

Konkrétna architektúra bez call-home pre budúci MVP

Spojením princípov dokopy, tu je to, čo by mal systém skutočne robiť:

1. Vydajte základné poverenie viazané na zariadenie. Viažte poverenie ku kľúčom chráneným v bezpečnom prostredí peňaženky — povinné podľa EUDI pre PID a atestácie ISO/IEC 18013-5.
2. Žiadajte iba to, čo je potrebné, s čerstvou výzvou. V transakcii OpenID4VP umožňuje dotaz DCQL peňaženke ukázať držiteľovi, ktoré atribúty sú požadované, a overovateľ vydá výzvu na zabránenie znovuprehratiu (podľa aktuálnej architektúry mDL NIST).
3. Generujte krátkodobú prezentáciu, nie opakovateľne použiteľný identifikátor. Každá prezentácia by mala byť špecifická pre overovateľa, požiadavku a daný moment.
4. Overujte pravosť lokálne. Validujte podpisy vydavateľa a verejné kľúče offline; dôverová služba AAMVA je vytvorená práve na tento účel.
5. Kontrolujte stav z uložených, samostatne obnovovaných zoznamov. Kde sú poverenia príliš dlhodobé na vynechanie revokácie, použite lokálne uložené zoznamy stavov obnovované podľa harmonogramu nesúvisiaceho s prezentáciami používateľov.
6. Uplatnite rizikovú politiku, keď aktuálnosť nie je dostupná. Urobte z offline rozhodnutí explicitnú politiku overovateľa, nie neštruktúrované dohadovanie.
7. Agresívne mažte sledovacie údaje. Zahoďte transakčne jedinečné prvky a časové pečiatky, keď už nie sú potrebné; neuchovávajte záznamy, ktoré by mohli rekonštruovať históriu pohybu.

Takto vyzerá seriózna architektúra bez call-home — vrstevnatá, chrániaca súkromie, kryptograficky lokálna a prevádzkovo úprimná voči offline realite.

Tri vzory, ktoré by mali byť zakázané na úrovni návrhu

Vyspelý ekosystém budúceho MVP by mal tieto považovať za architektonické zlyhania, nie za voľby optimalizácie:

• Povinné spätné volania vydavateľovi pri každej prezentácii. Vlastné usmernenie AAMVA o súkromí vysvetľuje, prečo je to škodlivé.
• Používanie vodičského poverenia ako bežného prihlásenia. NIST výslovne varuje pred opakovaným predkladaním poverení nesúcich identitu pri každodennej autentifikácii.
• Uchovávanie identifikátorov, časových pečiatok a záznamov, ktoré môžu rekonštruovať históriu prezentácií. EUDI aj AAMVA vyžadujú opak.

Základný argument v jednej vete

Okamžité overenie nesmie stať sa povolením pre sledovanie na strane vydavateľa.

Budúci MVP by mal byť schopný:

• Preukázať pravosť lokálne.
• Preukázať držbu lokálne.
• Overiť aktuálnosť súkromne.
• Tolerovať offline realitu.
• Fungovať plynule, keď dokonalé informácie nie sú dostupné.

Žiadna z týchto vlastností systém neoslabuje. Robí ho hodným nasadenia vo veľkom meradle.

V momente, keď sa vodičské poverenie stane nástrojom na zaznamenávanie toho, kto čo ukázal, kde a kedy, prestáva byť bezpečnejšou verziou papiera. Stáva sa infraštruktúrou pre pozorovanie.

To je presne to, čím by sa budúci MVP nemal stať.

Často kladené otázky

Čo je „overovanie call-home”?
Je to akýkoľvek návrh, v ktorom overovateľ v reálnom čase kontaktuje vydavateľa, aby overil poverenie. Hoci rieši pravosť aj revokáciu súčasne, umožňuje tiež vydavateľovi sledovať každú udalosť prezentácie.

Vyžaduje norma ISO/IEC 18013-5 online kontakt s vydavateľom?
Nie. AAMVA potvrdzuje, že norma ISO/IEC 18013-5 vyžaduje podporu načítania zo zariadenia a iba voliteľne umožňuje načítanie zo servera.

Ako môže revokácia fungovať bez kontaktovania vydavateľa?
Prostredníctvom krátkodobých poverení, zoznamov stavov atestácií alebo zoznamov odvolaných atestácií — ideálne s tým, že závislá strana sťahuje stavové údaje oddelene od prezentácií používateľov.

Prečo je „skupinové súkromie” dôležité pre zoznamy stavov?
Ak je zoznam stavov príliš malý alebo sú jeho indexy predvídateľné, žiadosť o stav môže prezradiť, ktoré konkrétne poverenie bolo práve predložené. Náhodné indexy a veľké zoznamy tomu zabraňujú.

Je offline overovanie skutočne praktické?
Áno — a normalizačné orgány vrátane AAMVA a EUDI to výslovne vyžadujú. Kompromis spočíva v tom, že dokonalá aktuálnosť v reálnom čase je nezlučiteľná s dokonalou offline prevádzkou, takže aktuálnosť musí byť politickým rozhodnutím, nie pevnou závislosťou.