Ei kotiinsoittoa -vahvistus: Miksi tulevaisuuden digitaalinen kansainvälinen ajokortti ei saa ottaa yhteyttä liikkeeseenlaskijaan jokaisella käyttökerralla

Peruutus on vaikein ongelma missä tahansa tulevaisuuden digitaalisessa kansainvälisessä ajokortissa (IDP). Helpoin tapa ratkaista se on myös vaarallisin: tehdä liikkeeseenlaskijasta osallistuja jokaisessa yksittäisessä esityksessä. Modernin rajat ylittävän ajoasiakirjan tulee kieltäytyä tästä oikotiestä oletusarvoisesti.

Lähes jokainen digitaalisen identiteetin ehdotus sisältää saman rauhoittavan lauseen:

“Asiakirja voidaan vahvistaa välittömästi.”

Joskus tämä lause kuvaa aitoa edistystä. Joskus se kuvaa valvontaa ystävällisemmällä käyttöliittymällä.

Tänään julkaistut standardit tekevät jo selväksi, että tarkastajan ei tarvitse ottaa yhteyttä liikkeeseenlaskijaan joka kerta, kun asiakirja esitetään:

• NISTin nykyinen mDL-arkkitehtuuri toteaa, että tarkastaja voi vahvistaa aitouden ja eheyden luottamalla liikkeeseenlaskijan allekirjoitukseen ja julkisiin avaimiin – ilman suoraa yhteyttä liikkeeseenlaskijaan.
• AAMVA vahvistaa, että ISO/IEC 18013-5 edellyttää tukea laitehakuun ja sallii palvelinhakun vain valinnaisesti.
• AAMVA varoittaa myös, että palvelinhaussa myöntävä viranomainen on mukana reaaliajassa jokaisella käyttökerralla – mikä tarkoittaa, että se voi teknisesti kirjata, milloin asiakirjaa käytetään, mitä tietoja jaetaan, ja jopa päätellä sijainnin IP-analyysin avulla.

Se ei ole pieni alaviite. Se on seuraavan sukupolven rajat ylittävien ajoasiakirjojen keskeinen suunnittelukysymys.

Vaarallinen oikotie: Neljän kysymyksen supistaminen yhdeksi verkkokutsuksi

Huonot arkkitehtuurit yhdistävät neljä hyvin erilaista kysymystä yhdeksi reaaliaikaiseksi kutsuksi liikkeeseenlaskijalle:

1. Onko tämä asiakirja aito?
2. Onko esittäjä asiakirjan oikeutettu haltija?
3. Onko asiakirja itse edelleen voimassa?
4. Onko taustalla oleva kansallinen ajo-oikeus edelleen voimassa?

Huonosti suunniteltu järjestelmä vastaa kaikkiin neljään soittamalla kotiin reaaliajassa. Hyvin suunniteltu järjestelmä erottaa ne toisistaan – koska ne eivät ole sama ongelma eikä niillä pitäisi olla yhteistä mekanismia.

Aitous tulisi vahvistaa paikallisesti, ei verkon kautta

Asiakirja voi olla kryptografisesti aito ilman, että liikkeeseenlaskija koskaan havaitsee tapahtumaa.

• NISTin mDL-luottamusmalli toteaa, että aitous ja eheys vahvistetaan liikkeeseenlaskijan allekirjoituksesta ja julkisista avaimista – reaaliaikaista yhteyttä liikkeeseenlaskijaan ei tarvita.
• AAMVA:n Digital Trust Service on olemassa nimenomaan antaakseen tarkastajille pääsyn voimassa oleviin liikkeeseenlaskijan julkisiin avaimiin ilman tapahtumakohtaisia takaisinkutsuja.

Suunnitteluperiaate 1: Älä käytä reaaliaikaista yhteyttä ratkaisemaan ongelmaa, jonka allekirjoitukset jo ratkaisevat.

Jos tarkastajalla on luotetut liikkeeseenlaskijan avaimet ja hän vastaanottaa standardien mukaisen esityksen, aitous on paikallinen kryptografinen tarkistus, ei verkkoriippuvuus.

Haltijasidos tulisi todistaa paikallisesti, ei raportoida maailmanlaajuisesti

Toiseen kysymykseen – onko tämä oikeutettu haltija? – on myös verkkoton vastaus.

Nykyinen EUDI-arkkitehtuuri edellyttää laitesidosta PID-asiakirjoille ja ISO/IEC 18013-5 -todistuksille. Tarkastaja pyytää lompakkoa allekirjoittamaan tuoreen haasteen käyttämällä yksityistä avainta, joka vastaa asiakirjaan upotettua julkista avainta:

• ISO/IEC 18013-5:ssä tätä kutsutaan mdoc-todennukseksi.
• SD-JWT VC:ssä sitä kutsutaan avainside-todennukseksi.

Kummassakin tapauksessa hallussapito todistetaan paikallisesti ja kryptografisesti. Henkilötietojen ei koskaan tarvitse tavoittaa liikkeeseenlaskijaa.

Suunnitteluperiaate 2: Todista hallussapito paikallisesti. Älä todista henkilöllisyyttä maailmanlaajuisesti.

Tulevaisuuden IDP:n tulisi hyödyntää laitesidos, paikallinen haltijatodentaminen ja tarkastajan haaste-vastaus-mekanismi ennen kuin se harkitsee mitään liikkeeseenlaskijapuolen mekanismia.

Asiakirjan tila ja ajo-oikeuden tila ovat kaksi eri asiaa

Monet digitaalisen identiteetin suunnitelmat hämärtävät tämän erottelun, ja siinä ne menevät pieleen.

W3C:n Bitstring Status List -määrittely ilmaisee asian selkeästi: todennettavaan asiakirjaan liitetty tilatietous koskee itse todennettavaa asiakirjaa – ei välttämättä taustalla olevaa tosielämän oikeutta. Digitaalinen asiakirja saatetaan peruuttaa, koska sen allekirjoitusmekanismi on vaarantunut, vaikka taustalla oleva ajo-oikeus on täysin voimassa.

Tulevaisuuden IDP tarvitsee siksi kaksi erillistä tilakerrosta:

• Asiakirjan tilakerros – digitaaliselle asiakirjalle tai esityskanavalle.
• Ajo-oikeuden kerros – taustalla olevalle kansalliselle ajo-oikeudelle.

Joskus nämä muuttuvat yhdessä. Usein eivät. Järjestelmä, joka sekoittaa ne, reagoi ylimitoitetusti, paljastaa enemmän tietoja kuin tarpeen, tai molempia.

Lompakon vaarantumisen tulisi levitä tilan kautta – ei laukaista tarkastajan takaisinkutsuja

Tulevaisuuden IDP tarvitsee myös selkeän vastauksen siihen, mitä tapahtuu, kun lompakko vaarantuu.

EUDI-arkkitehtuuri tarjoaa sellaisen:

• Lompakon tarjoaja myöntää Wallet Unit Attestations -todistuksia, jotka sisältävät peruutustiedot.
• Lompakon eheys tarkistetaan säännöllisesti; jos lompakko ei ole enää turvallinen, sen todistus peruutetaan.
• PID-tarjoajien on säännöllisesti tarkistettava, onko lompakko peruutettu. Jos näin on, he peruuttavat PID:n.
• Tarkastamalla PID:n tilan luottava osapuoli tarkistaa implisiittisesti myös lompakon tilan.

Tämä on kerrostus, jonka tulevaisuuden IDP:n tulisi omaksua. Älä pyydä jokaista tarkastajaa tarkistamaan lompakon tarjoajaa itsenäisesti. Anna lompakon vaarantumisen levitä olemassa olevan asiakirjan tilasputkilinjan kautta ja anna tarkastajien käyttää sitä yhtä yksityisyyttä suojaavaa kanavaa.

Kolme toimivaa peruutusmallia (ilman takaisinkutsuja)

EUDI edellyttää tarjoajilta yhden kolmesta peruutusmenetelmästä:

• Lyhytikäiset todistukset – voimassa enintään 24 tuntia, joten peruutus käy tarpeettomaksi.
• Attestation Status List – julkaistu lista, jota tarkastajat voivat käyttää.
• Attestation Revocation List – selkeä lista peruutetuista asiakirjoista.

Yli 24 tuntia voimassa oleville todistuksille EUDI edellyttää peruutustietojen upottamista, johon sisältyy:

• URL-osoite, josta luottavat osapuolet voivat hakea tilalistan.
• Tunniste, joka paikantaa asiakirjan kyseisessä listassa.

Jos luotettavia peruutustietoja ei ole saatavilla – esimerkiksi kun luottava osapuoli on offline-tilassa – EUDI kehottaa luottavaa osapuolta tekemään riskianalyysin ennen asiakirjan hyväksymistä tai hylkäämistä.

Johtopäätös: peruutus ei ole yksittäinen mekanismi, eikä se ole missään tapauksessa peruste pakollisille liikkeeseenlaskijan takaisinkutsuille.

Lyhytikäinen oletusarvona, pitkäikäinen vain tarvittaessa

Yksi koko pinon tehokkaimmista yksityisyystoimenpiteistä on myös yksinkertaisin: pidä esitetty tieto lyhytikäisenä.

• EUDI toteaa, että enintään 24 tuntia voimassa olevat todistukset eivät vaadi peruutusinfrastruktuuria – ne vanhenevat ennen kuin peruutus olisi merkityksellistä.
• W3C toteaa, että todennettavat esitykset ovat tyypillisesti lyhytikäisiä eikä niitä ole suunniteltu pitkäaikaiseen säilytykseen.
• NIST varoittaa nimenomaisesti uudelleen käytettävien tunnisteiden toistuvasta lähettämisestä päivittäiseen käyttöön. Päivittäisen todentamisen tulisi perustua siihen tarkoitukseen rakennettuihin teknologioihin, kuten salasanat-avaimiin (passkeys), ei identiteettirikkaan asiakirjan toistuvaan esittämiseen.
• NIST valitsi myös paikallisen laitetodennuksen palvelinpuolen biometrisen tunnistuksen sijaan nimenomaan siksi, että paikallinen todennus suojaa yksityisyyttä ja on operatiivisesti tehokkaampaa.

Suunnitteluperiaate 3: Perusasiakirjalla voi olla keskipitkä voimassaoloaika, mutta esityksen itsensä tulisi olla lyhytikäinen, tarkastaja-kohtainen ja kertakäyttöinen.

Tilalistat ovat oikea oletusmekanismi

Kun kaikkea ei voi tehdä lyhytikäiseksi, tarvitaan tilainfraa – ja tilalista on oikea oletus.

W3C:n Bitstring Status List v1.0 kuvaa yksityisyyttä suojaavan, tilaa säästävän ja suorituskykyisen mekanismin tilatietojen – kuten keskeytyksen tai peruutuksen – julkaisemiseen. Keskeisiä ominaisuuksia ovat:

• Jokainen liikkeeseenlaskija hallinnoi listaa myöntämilleen asiakirjoille.
• Muoto tiivistyy hyvin, koska suurin osa asiakirjoista pysyy peruuttamattomana.
• Oletuslistakoko on 131 072 merkintää, mikä W3C:n mukaan tarjoaa riittävän ryhmäyksityisyyden keskimääräisessä tapauksessa.
• Suurempia listoja voidaan käyttää, kun tarvitaan vahvempaa ryhmäyksityisyyttä.

Tämä siirtää kysymyksen:

“Voinko kysyä liikkeeseenlaskijalta tästä käyttäjästä juuri nyt?”

muotoon:

“Onko minulla jo riittävän tuore yksityisyyttä suojaava tilalista, jonka perusteella voin päättää paikallisesti?”

Se on paljon parempi kysymys – sekä teknisesti että poliittisesti.

“Ei kotiinsoittoa” on latausmalli, ei iskulause

Tärkein sääntö EUDI:n yksityisyysohjeistuksessa on menettelyllinen, ei filosofinen.

Luottavat osapuolet eivät saa pyytää tilalistaa joka kerta, kun asiakirja esitetään. Sen sijaan niiden on:

• Ladattava jokainen listan uusi versio kerran.
• Tehtävä se ajankohtana ja paikasta, joka ei liity mihinkään käyttäjän esitykseen.
• Jaettava lista sisäisesti luottavan osapuolen organisaatiossa.
• Haettava lista ilman luottavan osapuolen todentamista.

Tämä on ei-kotiinsoitto-vahvistuksen operatiivinen ydin: päivitä tila erillään käyttäjien esityksistä – ei koskaan henkilökohtaisesti, ei koskaan tapahtumittain.

Tämä yksi suunnitteluratkaisu estää liikkeeseenlaskijaa tai tilapalveluntarjoajaa saamasta tietää, mikä tarkastaja tarkisti minkä asiakirjan milloin.

Ryhmäyksityisyys: vaatimus, jonka useimmat suunnitelmat unohtavat

Monet järjestelmät mainostavat valikoivaa tietojen luovutusta itse esityksessä ja sivuuttavat hiljaisesti tilahakujen yksityisyyden. Tämä on merkittävä puute.

EUDI:n yksityisyysvaatimukset täsmentävät, että:

• Tilalistojen indeksit on oltava satunnaisesti määritetty, jottei indeksistä itsestään tule seurantasignaalia.
• Jokaisen listan on katettava riittävän suuri joukko asiakirjoja ryhmäyksityisyyden varmistamiseksi.
• Jos lista olisi muutoin liian pieni, tarjoajien tulisi lisätä käyttämättömiä merkintöjä todellisen asiakirjamäärän hämärtämiseksi.

Tulevaisuuden IDP ei voi väittää olevansa yksityisyyttä suojaava pelkästään valikoivan tietojen luovutuksen perusteella. Jos peruutusmekanismi vuotaa esitystapahtuman, yksityisyyssuunnittelu on epätäydellinen.

Offline-toiminta ei ole reunatapaus – se on ydintarve

Mikä tahansa matkustusjärjestelmä, joka olettaa täydellisen yhteyden, on huonosti suunniteltu.

• AAMVA vahvistaa, että laitehaku toimii ilman ulkoista yhteyttä sekä haltijan laitteen että lukijan osalta, ja että ISO/IEC 18013-5 edellyttää mDL:ien tukevan laitehakua.
• EUDI hyväksyy, että luottavat osapuolet voivat olla offline-tilassa ilman välimuistissa olevaa tilalistaa, jolloin se suosittaa riskianalyysiä ennen päätöstä.

Hyväksy tämä kompromissi ajoissa:

Täydellinen offline-toiminta ja täydellinen reaaliaikainen tuoreus eivät voi olla yhtä aikaa mahdollisia.

Mikä tahansa arkkitehtuuri, joka lupaa molemmat ilman kompromisseja, on joko epätarkka tai ottaa hiljaisesti käyttöön valvonnan uudelleen. Oikea vastaus on tehdä tuoreudesta politiikkasyöte, ei yleinen verkkoriippuvuus.

Lokit ovat paikka, jossa yksityisyys hiljaisesti epäonnistuu

Jopa erinomainen tilainfrastruktuuri voidaan pilata huolimattomalla lokikirjanpidolla.

• EUDI edellyttää, että luottavien osapuolten instanssit hävittävät yksilölliset elementit ja aikaleimaukset heti, kun niitä ei enää tarvita, ja kieltää niiden edelleen lähettämisen.
• AAMVA kieltää sidosryhmiä seuraamasta mDL-haltijoita tai mDL:n käyttöä, paitsi lain vaatiessa, edellyttää myöntäviltä viranomaisilta staattisten tai pitkäikäisten metatietojen jakamisen minimoimista ja rajoittaa toimintalokien käyttöoikeuden haltijalle.
• AAMVA edellyttää myös, että laitteella tapahtuva poistaminen poistaa lokitiedot ja metatiedot, jotka voisivat paljastaa käyttöhistorian – ja että tämä poistaminen on mahdollista myös offline-tilassa.

Tämä on protokollakäyttäytymistä, ei hallinnollista siivousta. Tulevaisuuden IDP:n on kohdeltava pitkäikäisiä tunnisteita, aikaleimoja ja lokeja mahdollisina seurantatyökaluina, ellei toisin nimenomaisesti osoiteta.

Konkreettinen ei-kotiinsoitto-arkkitehtuuri tulevaisuuden IDP:lle

Kokoamalla periaatteet yhteen, tässä on mitä järjestelmän tulisi käytännössä tehdä:

1. Myönnä laitesidonnainen perusasiakirja. Sido asiakirja lompakon turvallisessa ympäristössä suojattuihin avaimiin – pakollinen EUDI:ssa PID:lle ja ISO/IEC 18013-5 -todistuksille.
2. Pyydä vain tarvittavat tiedot tuoreella haasteella. OpenID4VP-tapahtumassa DCQL-kysely antaa lompakolla näyttää haltijalle, mitä attribuutteja pyydetään, ja tarkastaja lähettää haasteen toiston estämiseksi (NISTin nykyisen mDL-arkkitehtuurin mukaan).
3. Luo lyhytikäinen esitys, ei uudelleenkäytettävää tunnistetta. Jokaisen esityksen tulee olla tarkastaja-, pyyntö- ja hetki-kohtainen.
4. Vahvista aitous paikallisesti. Validoi liikkeeseenlaskijan allekirjoitukset ja julkiset avaimet offline-tilassa; AAMVA:n luottamuspalvelu on rakennettu juuri tätä varten.
5. Tarkista tila välimuistissa olevista, erikseen päivitetyistä listoista. Kun asiakirjat ovat liian pitkäikäisiä peruutuksen ohittamiseksi, käytä paikallisesti välimuistissa olevia tilalistoja, joita päivitetään aikataululla, joka ei liity käyttäjän esityksiin.
6. Sovella riskipolitiikkaa, kun tuoreus ei ole saatavilla. Tee offline-päätöksistä selkeä tarkastajan politiikka, ei jäsentymätöntä arvausta.
7. Poista seurantatiedot aggressiivisesti. Hävitä tapahtumalle yksilölliset elementit ja aikaleimaukset, kun niitä ei enää tarvita; älä säilytä lokeja, jotka voisivat rekonstruoida liikehistorian.

Tältä vakavasti otettava ei-kotiinsoitto-arkkitehtuuri näyttää – kerrostettu, yksityisyyttä suojaava, kryptografisesti paikallinen ja operatiivisesti rehellinen offline-todellisuuden suhteen.

Kolme mallia, jotka tulisi kieltää suunnittelulla

Kypsän tulevaisuuden IDP-ekosysteemin tulisi kohdella näitä arkkitehtuurivirheinä, ei optimointivalintoina:

• Pakolliset liikkeeseenlaskijan takaisinkutsut jokaisessa esityksessä. AAMVA:n oma yksityisyysohjeistus selittää, miksi tämä on haitallista.
• Ajoasiakirjan käyttäminen rutiininomaisena kirjautumisena. NIST varoittaa nimenomaisesti identiteettiä sisältävien asiakirjojen toistuvasta esittämisestä päivittäiseen todentamiseen.
• Tunnisteiden, aikaleimausten ja lokien säilyttäminen, jotka voivat rekonstruoida esityshistorian. Sekä EUDI että AAMVA edellyttävät päinvastaista.

Ydinsanoma yhdessä lauseessa

Välittömästä vahvistuksesta ei saa tulla lupaa liikkeeseenlaskijapuolen valvonnalle.

Tulevaisuuden IDP:n tulisi pystyä:

• Todistamaan aitous paikallisesti.
• Todistamaan hallussapito paikallisesti.
• Tarkistamaan tuoreus yksityisesti.
• Sietämään offline-todellisuutta.
• Toimimaan sujuvasti, kun täydellinen tieto ei ole saatavilla.

Mikään tästä ei tee järjestelmästä heikomman. Se tekee siitä käyttöönottamisen arvoisen laajassa mittakaavassa.

Sillä hetkellä, kun ajoasiakirjasta tulee työkalu, jolla kirjataan kuka näytti mitä, missä ja milloin, se lakkaa olemasta paperiversion turvallisempi versio. Siitä tulee valvontainfrastruktuuri.

Juuri sitä tulevaisuuden IDP:n tulisi kieltäytyä olemasta.

Usein kysytyt kysymykset

Mitä “kotiinsoitto-vahvistus” tarkoittaa?
Se on mikä tahansa suunnitelma, jossa tarkastaja ottaa reaaliajassa yhteyttä liikkeeseenlaskijaan asiakirjan vahvistamiseksi. Vaikka se ratkaisee aitouden ja peruutuksen samanaikaisesti, se antaa liikkeeseenlaskijalle myös mahdollisuuden havaita jokainen esitystapahtuma.

Vaatiiko ISO/IEC 18013-5 verkkoyhteyttä liikkeeseenlaskijaan?
Ei. AAMVA vahvistaa, että ISO/IEC 18013-5 edellyttää laitehakutukea ja sallii palvelinhakun vain valinnaisesti.

Miten peruutus voi toimia ottamatta yhteyttä liikkeeseenlaskijaan?
Lyhytikäisten asiakirjojen, todistusten tilalistojen tai todistusten peruutuslistojen avulla – ihanteellisesti siten, että luottava osapuoli lataa tilatiedot erillään käyttäjien esityksistä.

Miksi “ryhmäyksityisyys” on tärkeää tilalistojen kannalta?
Jos tilalista on liian pieni tai sen indeksit ovat ennustettavia, tilakysely voi paljastaa, mikä tietty asiakirja juuri esitettiin. Satunnaiset indeksit ja suuret listat estävät tämän.

Onko offline-vahvistus todella käytännöllistä?
Kyllä – ja standardointielimet, kuten AAMVA ja EUDI, edellyttävät sitä nimenomaisesti. Kompromissi on, että täydellinen reaaliaikainen tuoreus on yhteensopimaton täydellisen offline-toiminnan kanssa, joten tuoreudesta on tultava politiikkapäätös, ei kova riippuvuus.