Digitaalinen tuotepassi ei näytä kaikille samoja tietoja. Ostaja näkee julkiset tiedot. Korjaamo tai kierrättäjä näkee enemmän. Markkinavalvontaviranomainen näkee kaiken. Tämä on selvitetty, ja eurooppalaisissa standardeissa se on nykyään nimenomaisesti määritelty.
Mielenkiintoisempi kysymys on hieman hienovaraisempi: jos jollekin paljastetaan julkisten tietojen lisäksi suojattuja kenttiä, voiko hän todistaa, että juuri nämä kentät ovat aitoja? Vai onko hänen luotettava siihen, että alusta on valinnut ne oikein ja välittänyt ne eteenpäin muuttamattomina?
Useimpien alustojen kohdalla rehellinen vastaus on: luottamus. Olemme rakentaneet alustamme niin, että vastaus on todiste - ei vain julkisten kenttien osalta, vaan jokaisen kentän osalta, joka lisätään vasta tietojen paljastamisen yhteydessä. Miksi tämä ero on merkityksellinen ja miksi olemme valinneet tämän työläämmän tien.
Kaikki täyttävät pääsyoikeussäännön samalla tavalla
EN 18239, eurooppalainen standardi, ## jokakoskee pääsyoikeuksia, turvallisuutta ja luottamuksellisuutta DPP:ssä, vaatii pääsynhallintaa kunkin tietokentän osalta: jokaiselle kentälle on sääntö, kuka sen saa nähdä. Tämä on oikea vaatimus, eikä sitä ole vaikea täyttää. Olemme eritellyt näiden standardien aseman kohdassa yhdenmukaistetut standardit.
Tavallinen tapa toteuttaa tämä on palvelinpuoleinen suodatus. Palvelin tietää, kuka pyytää tietoa, tarkistaa, mitä kyseinen henkilö saa nähdä, ja palauttaa juuri tämän osan. Käyttöoikeuksien hallinta: hoidettu. Standardi ei vaadi enempää.
Tässä on kuitenkin yksi ongelma, jota standardi ei ota huomioon: Ote saapuu allekirjoittamattomana. Lukija saa hänelle kootun näkymän ja joutuu luottamaan siihen, että palvelin on valinnut sisällön rehellisesti eikä ole muuttanut sitä siirron aikana. Julkisen tiedotteen kohdalla tämä on hyväksyttävää. Mutta kun kyseessä on arvo, johon tietojen käsittelijä perustaa esimerkiksi käytetyn pariston hinnan, se vaatii paljon luottamusta.
Missä yksittäinen allekirjoitus saavuttaa rajansa
Ilmeisin ratkaisu on allekirjoittaa tiedot. Tavallinen allekirjoitus toimii hyvin asteikon molemmissa päissä: julkinen näkymä allekirjoitetaan, täydellinen tietojoukko allekirjoitetaan, ja molemmat tarkistetaan julkisen avaimen avulla ilman, että välissä on palvelinta. Miten tämä tapahtuu yksityiskohtaisesti, on kuvattu artikkelissa Allekirjoitukset ja varmenteet DPP:ssä.
Keskivaiheilla järjestelmä pettää. Koko asiakirjan kattava allekirjoitus kattaa täsmälleen yhden kenttäjoukon, nimittäin ne kentät, jotka olivat olemassa allekirjoitushetkellä. Jos valtuutetulle lukijalle avataan lisäksi suojattu kenttä, tämä kenttä jää allekirjoitetun joukon ulkopuolelle ja saapuu hänelle suojaamattomana. Jos sen sijaan allekirjoitetaan alusta alkaen koko tietue, allekirjoitus kattaa kyllä kaiken, mutta silloin jouduttaisiin näyttämään kaikki kaikille.
Välissä olevat tahot jäävät siten järjestelmän ulkopuolelle: korjaamo, vakuutusyhtiö, kierrättäjä. Jos haluttaisiin allekirjoittaa etukäteen jokainen mahdollinen ”kuka näkee mitä” -yhdistelmä, jokaiselle yhdistelmälle tarvittaisiin oma allekirjoitettu asiakirja, ja yhdistelmien määrä kasvaa räjähdysmäisesti jokaisen uuden käyttöoikeusryhmän myötä. Kukaan ei tee niin. Turvaudutaan allekirjoittamattomaan palvelinsuodattimeen, ja välivaihe perustuu jälleen luottamukseen.
Jokaisen kentän allekirjoittaminen erikseen
On olemassa parempi ratkaisu, ja sen varaan rakennamme alustamme. Sen sijaan, että valmis asiakirja allekirjoitettaisiin yhtenä kokonaisuutena, allekirjoittaja määrittelee jokaisen kentän erikseen yhdellä allekirjoituskierroksella (standardeihin perehtyneille: W3C-todistus ecdsa-sd-2023 valikoivaa paljastamista varten).
Jokainen näkymä alkaa julkisesta ytimestä
Jokainen näkymä alkaa siis samoista julkisista kentistä. Se, mitä lukija näkee tämän lisäksi, lisätään kenttä kerrallaan, ja jokainen näistä kentistä johtaa edelleen laatijan julkiseen avaimeen - offline-tilassa, ilman uutta allekirjoitusta ja ilman luottamusta näkymän kokoajaan. Kentät, joihin ei ole oikeutta, puuttuvat yksinkertaisesti. Niitä ei ole mustattu, vaan niitä ei ole lainkaan, eikä niistä vuoda mitään läpi.
Miksi ”katkeamaton” on koko asian ydin
Kuvittele notaari, joka ei todista kirjettä kokonaisuudessaan, vaan jokaisen kappaleen erikseen. Julkisen kirjeen saa jokainen. Se, jolla on oikeus saada enemmän, saa lisäkappaleet, ja jokaisessa niistä on edelleen saman notaarin sinetti. Tavallisessa menettelyssä alusta kirjoittaa nämä kappaleet puolestasi, ja se, mitä sinulle toimitetaan, kantaa enää vain sinun sanaasi.
Miksi ”ehjä” on tässä yhteydessä tärkeää, ansaitsee vielä yhden lauseen selityksen. Ehjä sinetti ei tarkoita, että sisältö on totta. Se tarkoittaa: juuri tämän lähettäjä on kirjoittanut, eikä kukaan ole sen jälkeen muuttanut siitä mitään. Täten luottamuskysymyksen ulkopuolelle jää jokainen, joka on vain välittänyt asiakirjan eteenpäin - välimuisti, verkko, arkisto, me. Sillä, kuka on antanut passin teille, ei ole enää merkitystä.
Ja sinetti on binäärinen. Se joko pysyy paikallaan tai ei, puoliksi rikkoutunutta sinettiä ei ole olemassa. Jos sinetti murtuu, et saa tietää, mitä lausetta on muutettu, vaan vain sen, että et voi enää luottaa koko asiakirjaan. Siksi ei ole asteittaista eroa siinä, saapuvatko lisäkentät sinetillä vai ilman: ilman sinettiä ne eivät ole vain hieman heikommin vahvistettuja, vaan ne eivät ole lainkaan vahvistettuja.
Molemmat menetelmät tarkasteltavina
Kuka tahansa voi tarkistaa tämän itse. Transpareo Time Machine on avoimen lähdekoodin sovelluksemme tuotepassien tarkasteluun: se selaa passin versiohistoriaa ja laskee samalla jokaisen allekirjoituksen katsojan selaimessa kysymättä sitä palvelimeltamme. Sovelluksessa on julkisesti saatavilla kaksi esimerkkipassia. T-paidan passissa on koko asiakirjaa koskeva allekirjoitus, kun taas pariston passissa tiedot on esitetty kenttäkohtaisesti.
Molemmat ovat avoimia W3C-spesifikaatioita: eddsa-jcs-2022 koko asiakirjan kattavalle allekirjoitukselle, ecdsa-sd-2023 kenttäkohtaiselle julkistukselle. Kuka tahansa voi toteuttaa ne. Työmäärä on syy siihen, miksi monet eivät aio tehdä niin: koko asiakirjan kattava allekirjoitus on huomattavasti edullisempi toteuttaa ja ylläpitää, ja se riittää niille, jotka toimittavat vain julkisia tietoja.
Se, että Time Machine hallitsee molemmat menetelmät, on tarkoituksellista ja pysyykin niin. Se ei kuulu millekään alustalle. Tarkastaja, joka hyväksyisi vain kalliimman menetelmän, olisi työkalu meille eikä kenellekään muulle.
Kenelle suojatut kentät paljastetaan
On syytä kysyä, kenelle julkisten tietojen lisäksi ylipäätään paljastetaan mitään. Ei satunnaiselle ostajalle - hän saa julkisen passin. Ne ovat kierrättäjä, joka arvioi käytetyn akkupaketin arvon; vakuuttaja, joka hinnoittelee riskin; kierrättäjä, joka lajittelee kemikaaleja; viranomainen, joka rakentaa tapausta. Nämä ovat lukijoita, joiden päätökset liittyvät rahaan tai turvallisuuteen.
Ja juuri nämä kentät jäävät tavanomaisessa lähestymistavassa paljastamatta. Juuri ne, joilla olisi eniten syytä haluta kryptografista todistetta, eivät saa sitä nimenomaan niistä kentistä, jotka vaikuttavat heidän päätökseensä.
Mielestämme varmennusmerkin tulisi tarkoittaa samaa kaikille. ”Transpareon tarkastama” tarkoittaa korjaamon laajennetussa näkymässä samaa kuin ostajan julkisessa passissa: jokainen näytetty osa on peräisin myöntäjältä eikä sitä ole sen jälkeen muutettu. Sertifikaatti, joka koskee vain julkisia kenttiä, on puolittaista.
Enemmän kuin standardi vaatii
Sanomme tämän suoraan: mitään tästä ei ole määrätty. EN 18239 -standardi vaatii, että pääsyä hallitaan, ja palvelinpuolen suodatin hallitsee pääsyä moitteettomasti. Myös julkisten kenttien tekeminen kryptografisesti todennettaviksi on jotain, mitä teemme ylimääräisenä palveluna - se ei ole pakollinen vaatimus, jota sääntely meiltä edellyttää.
Juuri siksi se on syytä kirjata ylös. Olisi helppoa täyttää standardin kirjaimellinen vaatimus, toimittaa palvelinsuodatin ja julistaa vaihe suoritetuksi. Meille on tärkeämpää, että sitoumus pätee kaikkialla, missä sinetti esiintyy. Sillä allekirjoitetun passin koko tarkoitus on, ettei kenenkään tarvitse luottaa alustaan. Keskitason poikkeuksena jättäminen palauttaa juuri sen luottamuksen, jonka allekirjoituksen oli tarkoitus poistaa.
Sama periaate saa kentän unohtumaan
Jokaisen kentän erikseen määritteleminen tuo mukanaan toisen ominaisuuden, ja tätä eurooppalainen lainsäädäntö itse asiassa vaatii. Yleinen tietosuoja-asetus antaa ihmisille oikeuden saada henkilötiedot poistettua. Yhtenä kokonaisuutena allekirjoitettu tietue ei voi täyttää tätä vaatimusta tuhoamatta omaa allekirjoitustaan.
Koska tässä jokainen kenttä on erillinen, yksittäinen kenttä voidaan poistaa, kun taas kaikki muu pysyy edelleen todennettavissa. Jos henkilötietoja päätyy vahingossa passiin, ne voidaan poistaa siististi, ja passi pysyy voimassa: ei uutta myöntämistä, ei katkenneita tietoja. Lain mukaan säilytettävät pakolliset kentät jäävät paikoilleen; poistettavat tiedot voidaan poistaa pyynnöstä, jopa vuosia myöhemmin.
Silti täysin tavallinen passi
Mikään näistä seikoista ei tee passista erityistä objektia, jonka vain omat työkalumme pystyvät avaamaan. Se pysyy verifioitavana tunnistetietona (Verifiable Credential) JSON-LD-muodossa, johon web-standardien maailma on siirtymässä, ja samaa muotoa käyttävät myös YK:n läpinäkyvyysprotokolla (UN Transparency Protocol) ja muu W3C-ympäristö.
Passi, jonka ostaja skannaa selaimessaan, on siis sama objekti, jonka datahuoneen kumppani voi lukea, ja kuka tahansa standardien mukainen tarkastaja voi tarkistaa sen, ei vain meidän. Lisäturvallisuus ei maksa lukijalle mitään eikä sido ketään meihin.
Miksi tämä on teknisesti vaikeaa
Ensin, jotta ei syntyisi väärää käsitystä: emme ole keksineet tätä menetelmää. ecdsa-sd-2023 on julkinen W3C-spesifikaatio, sen taustalla oleva salaustekniikka ei ole meidän keksintöämme, ja kuka tahansa, joka haluaa toteuttaa sen, voi lukea siitä lisää. Idean keksiminen ei ole vaikeaa. Vaikeaa on rakentaa se niin, että salasana toimii vielä kymmenen vuoden kuluttua. Siinä piilee työn ydin, ja siitä voidaan sanoa jotain hyödyllistä.
Ero kuulostaa pieneltä, mutta se muuttaa perustan: tavallinen allekirjoitus laskee dokumentin tavujen perusteella. Valikoiva paljastaminen laskee asiakirjan väittämien perusteella. Passi muokataan ennen allekirjoittamista standardoituun muotoon, jossa jokainen tieto on erillinen, itsenäinen lause. Vasta tämän ansiosta yksi lause voidaan jättää pois vahingoittamatta muita.
Tämän myötä syntyy ongelma, jota tavallisella tavu-allekirjoituksella ei ole: sama standardoitu muoto on saatava täsmälleen takaisin kymmenen vuoden kuluttua. Ei suunnilleen, vaan merkki merkiltä, muuten todiste ei enää kelpaa. Kolme asiaa estää tämän, ja kaikki kolme ovat huomaamattomia.
Luvut menettävät tyyppinsä. Jos luku kirjoitetaan pelkkänä JSON-muodossa, sentyyppi katoaa matkan varrella. Arvo kuten 2,0 palautuu JSON-kierroksen jälkeen muodossa 2. Ihmiselle se on sama asia, mutta standardoidussa muodossa se on eri lause, ja tarkistus epäonnistuu.
Nimet eivät vielä tarkoita mitään. Jotta standardoitu muoto syntyisi, jokaisen kentän nimen on viitattava yksiselitteiseen merkitykseen. Jos jokin puuttuu, kenttä katoaa muunnoksessa huomaamatta. Se näkyy sitten passissa, mutta todistus ei kata sitä, eikä kukaan huomaa sitä.
Merkitykset löytyvät yleensä verkosta. Tämä vastaavuus on sanastossa, jonka useimmat työkalut lataavat verkosta tarkistuksen yhteydessä. Kuka näin tekee, asettaa passinsa tarkistettavuuden riippuvaiseksi siitä, että vieras osoite vastaa vielä kymmenen vuoden kuluttua, ja vieläpä muuttumattomana.
Kuinka ratkaisimme ongelman
Suljimme nämä kolme kohtaa jo alkulähteellä sen sijaan, että olisimme korjanneet ne myöhemmin.
Tyyppien määrittely. Jokainen arvo kirjoitetaan tyyppinsä mukaisesti, ja julkaisu keskeytyy heti, kun standardoidussa muodossa esiintyy edes yksi tyypittömä luku. Virhe havaitaan siis heti, kun se aiheuttaa yhden rivin menetyksen, eikä vasta vuosia myöhemmin selittämättömänä tarkastusvirheenä.
Sanastot. Jokainen sanasto, johon passi viittaa, on meillä paikallisesti saatavilla eikä sitä koskaan haeta verkosta. Tuntematon osoite aiheuttaa allekirjoituksen keskeytyksen, eikä se johda hiljaiseen paluuseen tyhjään tulokseen.
Tunnisteet. Jokaisella dokumentin solmulla on vakaa tunniste, jotta standardoitu muoto pysyy toistettavissa sen sijaan, että jokaisella kierroksella annettaisiin uusia apunimiä.
Herkin osa liittyy Bring Your Own Key -periaatteeseen. Jokaista myöntämistä varten tarvitaan ylimääräinen, lyhytaikainen avain, jolla julkistettavat kentät allekirjoitetaan yksitellen. Myöntäjä luo ja hävittää tämän avaimen itse. Jos avain olisi meillä, voisimme keksiä yksittäisiä kenttiä jälkikäteen, ja julkaisijan allekirjoituksen riippumattomuus olisi enää vain väitettä. Tarkistamme palautetun todistuksen tallennettua julkista avainta vastaan, ennen kuin luotamme siihen.
Jokaisessa passissa on kaksi tällaista todistetta, yksi myöntäjältä ja yksi Transpareolta, ja kumpikin niistä johdetaan lukijan näkökulmasta riippumattomasti. Kaksi allekirjoitusta, kaksi toisistaan riippumatonta auktoriteettia, jopa yksittäisen julkistettavan kentän osalta.
Meille tämä vaiva on perusteltua. Emme ole lisänneet todennettavuutta jälkikäteen; alusta on rakennettu sen ympärille jo ensimmäisestä versiosta lähtien. Jokainen passi allekirjoitetaan julkaisun yhteydessä ja ketjutetaan edelliseen versioon. Muuttumaton kymmenen vuoden arkisto on luotu ja se astuu voimaan heti, kun passit on rekisteröity EU-DPP-rekisteriin rekisteröidään. Kunkin kentän allekirjoittaminen koko lohkon sijaan on tämän ytimen laajennus, ei lisäys johonkin, jota ei ole koskaan tarkoitettu tähän tarkoitukseen.
Missä olemme
Yksinkertaistettuna valinta on helppo. Voitte paljastaa suojatut kentät ja pyytää lukijaa luottamaan suodattimeenne - tämä täyttää standardin vaatimukset. Tai voitte paljastaa ne ja antaa todisteen samalla - tämä täyttää korkeamman vaatimuksen, jonka nämä kentät mielestämme ansaitsevat.
Olemme päättäneet esittää todisteen jokaiselle lukijalle, koska varmennuksen tulisi tarkoittaa samaa asiaa riippumatta siitä, kuka sitä tarkastelee. Jos haluatte nähdä, miten se toimii: edellä linkitetyt kaksi esimerkkiä tarkistetaan suoraan selaimessa, offline-tilassa, pelkän julkisen avaimen avulla.