Miért opcionális a blokklánc a jövőbeli Nemzetközi Vezetői Engedély (IDP) szempontjából

A jövőbeli Nemzetközi Vezetői Engedélynek (IDP) átláthatóságra, megbízhatósági pontokra és nyilvános elszámoltathatóságra van szüksége. Amire alapértelmezés szerint nincs szüksége, az az, hogy maguk a sofőrök kerüljenek fel egy elosztott főkönyvre.

A digitális, határon átnyúló IDP-ről folytatott minden komoly beszélgetés előbb-utóbb ugyanazt a javaslatot vonzza: „Tegyük fel blokklánra.” A vonzerő érthető. A blokkláncok illetéktelen módosítással szembeni védelmet, közös láthatóságot és csak hozzáfűzéses előzményt kínálnak. Ezek valós tulajdonságok. A határon átnyúló sofőrazonosság összefüggésében azonban ezeket nagyon gyakran a rossz rétegre alkalmazzák.

Ez a cikk elmagyarázza, miért van ez így, ismerteti, mit mondanak valójában a szabványok, és felvázol egy jobb architekturális mintát.

Mit mondanak valójában a szabványok a blokkláncról

A W3C Ellenőrizhető Hitelesítő Adatok Adatmodellje egyértelműen kimondja, hogy az ellenőrizhető adatregiszter számos formát ölthet, például:

• Megbízható adatbázisok
• Decentralizált adatbázisok
• Állami személyazonosság-adatbázisok
• Elosztott főkönyvek

A DID Core ugyanilyen egyértelmű: számos DID-módszer használ elosztott főkönyv technológiát, de nem mindegyik. Más szóval a szabványok már elutasítják azt az elképzelést, hogy a blokklánc a digitális hitelesítő adatok kötelező alapja.

Ez a megfelelő kiindulópont a jövőbeli IDP-hez. A hasznos kérdés nem az, hogy „blokklánc vagy nem blokklánc?”, hanem:

Melyik rétegnek van valóban szüksége átláthatóságra, és melyik réteg az, amelynek alapértelmezés szerint semmiképpen sem szabad nyilvános infrastruktúrává válnia?

A blokklánc tulajdonságok gyűjteménye, nem követelmény

Az első hiba az, hogy a „blokklánc”-ot egyetlen követelményként kezelik. Holott nem az. Lehetséges tulajdonságok összessége, többek között:

• Megosztott publikáció
• Csak hozzáfűzéses előzmény
• Elosztott működés
• Visszaigazolás-generálás
• Ellenállás az egyoldalú módosításokkal szemben

Ezek közül néhány hasznos a jövőbeli IDP szempontjából. Néhány irreleváns. Néhány pedig egyenesen veszélyes, ha emberi hitelesítő adatok alanyaira alkalmazzák. A W3C-regisztermodell szándékosan teszi lehetővé a többféle megvalósítást, mivel a különböző ökoszisztémák különböző kompromisszumokat igényelnek.

Három probléma, amelyet nem szabad összevonni

A második hiba az, hogy három különböző problémát egyetlen rendszerbe sűrítenek. A jövőbeli IDP esetében ezeket külön kell tartani:

1. Hol él a jogi igazság. A vezetési jog az illetékes nemzeti jogosítványnyilvántartásokban keresendő.
2. Hogyan kerül terjesztésre a megbízhatósági anyag. A kiállítói kulcsok és az ellenőrzői tanúsítványok a kontrollált megbízhatósági regiszterekbe tartoznak.
3. Hogyan ellenőrzi az ökoszisztéma a változásokat. Ez az átláthatósági rétegbe tartozik.

A valós ökoszisztémák már így működnek. Az AAMVA digitális megbízhatósági szolgáltatása letölthető listában terjeszti a kiállítók nyilvános kulcsait, mielőtt egy ellenőrző valaha is kapcsolatba kerülne egy mobilvezetői engedéllyel (mDL). Az EU mobilvezetői engedélyre vonatkozó kézikönyve előírja, hogy a tagállamok értesítsék a Bizottságot az engedélyezett mDL-kiállítókról, a Bizottság pedig közzéteszi ezen hatóságok ellenőrzési listáját. Ez megbízhatóság-elosztás blokklánc nélkül.

Mit tanít nekünk a tanúsítvány-átláthatóság

A nyilvános interneten a leghatékonyabb átláthatósági modell nem egy fogyasztói blokklánc. Ez a tanúsítvány-átláthatóság (CT).

Az RFC 9162 a CT-t olyan protokollként írja le, amely nyilvánosan naplózza a TLS-kiszolgálói tanúsítványokat, hogy bárki:

• Ellenőrizze a hitelesítésszolgáltató tevékenységét
• Észlelje a problémás vagy hibásan kiállított tanúsítványokat
• Magát a naplót is ellenőrizze

A CT legfontosabb tervezési tanulsága: az átláthatóság akkor a legértékesebb, ha a kiállítói magatartást és a megbízhatósági anyagot rögzíti — nem a végfelhasználói tevékenységet.

A jövőbeli IDP-re alkalmazva ez azt jelenti, hogy olyan dolgokat kell naplózni, mint:

• Kiállítói kulcsok kibocsátása és rotálása
• Megbízhatósági horgonyok közzététele
• Ellenőrzői kategóriák regisztrálása
• Szabályzatváltozások
• Megfelelőségi nyilatkozatok
• Biztonsági szempontból releváns események

Ez nem jelenti azt, hogy nyilvános vagy félig nyilvános főkönyvet hozunk létre a jogosultakról, a hitelesítő adatok azonosítóiról vagy a bemutatási eseményekről. Ez nem átláthatóság. Ez túlzott adatgyűjtés.

SCITT: miért nem azonos az átláthatóság az igazsággal

Az IETF SCITT-architektúra tervezete továbbviszi ezt a gondolkodásmódot. A SCITT olyan átláthatósági szolgáltatást definiál, amely ellenőrizhető adatstruktúrát tart fenn, és kriptográfiai visszaigazolásokat bocsát ki, amelyek bizonyítják az aláírt állítások belefoglalását. Az átláthatósági szolgáltatás identitását a támaszkodó felek által ismert nyilvános kulcs rögzíti, a megbízhatósági horgonyok és a regisztrációs szabályzatok maguk is átláthatóvá válnak.

Ez egy erőteljes modell az IDP-infrastruktúra számára, mivel az átláthatóságot a megbízhatósági anyag és a szabályzat körüli ellenőrizhető szolgáltatássá alakítja — nem személyes utazási események köré.

A SCITT az átláthatóság korlátait illetően is egyértelmű:

• Egy regisztrált állítás csak azt bizonyítja, hogy egy kiállító elkészítette és regisztrálta azt — nem azt, hogy az állítás határozatlan ideig helyes.
• Egy későbbi aláírt állítás felválthatja a korábbit.
• Az átláthatóság nem akadályozza meg a tisztességtelen vagy kompromittált kiállítókat; felelőssé teszi őket.

A sofőrazonosság tekintetében ez a különbségtétel rendkívül fontos: az átláthatósági napló bizonyíték és ellenőrzési előzmény, nem pedig valakinek a vezetési jogát meghatározó mérvadó jogi állapot.

A SCITT azt is megjegyzi, hogy az átláthatósági szolgáltatás a csak hozzáfűzéses sorrendjét megbízható hardver, konszenzusprotokollek és kriptográfiai bizonyítékok kombinációjával védheti. Még az átláthatósági réteg sem igényel egyetlen meghatározott blokklánc-tervezetet. A konszenzus az egyik lehetőség, nem az egyetlen.

A helyes architekturális szétválasztás a jövőbeli IDP-hez

A jövőbeli IDP-nek négy különálló rétegre kell szétválasztania a feladatokat:

1. Mérvadó nyilvántartások arról, ki vezethet (nemzeti engedélyezési hatóságok)
2. Megbízhatósági regiszterek a kiállítói és ellenőrzői kulcsokhoz
3. Állapot-infrastruktúra a frissesség és a visszavonás kezeléséhez
4. Opcionális átláthatósági réteg a szabályzatok, a megbízhatósági horgonyok, a visszaigazolások és a megfelelőségi nyilatkozatok nyilvános ellenőrzéséhez

Miután szétválasztjuk ezeket a rétegeket, a blokklánc-kérdés sokkal élesebben merül fel. Többé nem az a kérdés, hogy „legyen-e a jövőbeli IDP blokkláncon?”, hanem:

Melyik réteg profitál valójában — ha egyáltalán valamelyik — a csak hozzáfűzéses nyilvános ellenőrzésből?

Öt ok, amiért a láncon tárolt sofőrazonosság nem a megfelelő alapértelmezés

1. Tartós nyomkövetési jeleket hoz létre

Az EUDI adatvédelmi munkája rámutat, hogy az igazolások bemutatása egyedi értékeket tartalmazhat, például:

• Sók
• Hash-értékek
• Visszavonási azonosítók
• Eszközhöz kötött nyilvános kulcsok
• Aláírások
• Időbélyegek

Mivel ezek az értékek ugyanazon igazolás esetén rögzítettek, lehetővé teszik a támaszkodó felek számára, hogy különböző tranzakciókat összekapcsoljanak, és viselkedési profilt állítsanak össze a felhasználóról. Az EUDI kifejezetten figyelmeztet arra, hogy ez sérti azt az ésszerű elvárást, miszerint az elkülönülő pénztárca-tevékenységeket nem szabad összekapcsolni.

Ha stabil jogosulti azonosítókat, stabil hitelesítő azonosítókat, újrafelhasználható hash-eket vagy egyedileg nyomon követhető visszavonási eseményeket tesz közzé egy nyilvános főkönyvön, nem a nyomkövetési problémát oldja meg — hanem örök időkre rögzíti azt.

2. Visszavonási és frissességi eseményeket fed fel

A W3C Bitstring Status List ajánlása egyértelműen leírja a problémát: ha egy-az-egyhez megfeleltetés létezik egy hitelesítő adat és az állapotát közzétevő URL között, a közzétevő összekapcsolhatja a jogosultat, az ellenőrzőt és az ellenőrzés időpontját. A specifikáció egy vezetői engedély példájával illusztrálja, miért sérti a magánélethez fűződő általános elvárásokat az, ha a kiállító nyomon követi a jogosultat, amikor az belép egy helyszínre.

A Bitstring Status List által javasolt jobb alapértelmezés:

• Nagy, tömöríthető állapotlisták, ahol sok hitelesítő adat osztozik egyetlen állapot-erőforráson
• Alapértelmezett listaméret: 131 072 bejegyzés
• A támaszkodó felek az új verziókat külön töltik le, anélkül hogy azonosítanák magukat
• Véletlenszerű indexek és csoportos adatvédelmi garanciák

Ez az egyéni, láncon tárolt visszavonási nyomvonalak ellentéte.

3. Összekeveri a hitelesítő adat állapotát a jogi vezetési állapottal

Egy digitális hitelesítő adat visszavonható, mert az aláírási mechanizmusa kompromittálódott — miközben a valós életbeli vezetési jog érvényes marad. A hitelesítő adatok eseményeinek nyilvános főkönyve nem helyettesíti tisztán egy nemzeti jogosítványnyilvántartás mérvadó állapotát.

A SCITT megerősíti ezt: egy regisztrált állítást később egy új válthatja fel, a támaszkodó felek pedig szabályzat és előzmény alapján döntik el, miben bíznak. A napló nem örök igazság. Ez bizonyíték arról, ki mit mondott, mikor, milyen szabályzat alapján. A jogi igazság gyökere a nemzeti engedélyezési hatóság marad.

4. Rossz irányítási problémát céloz meg

A határon átnyúló sofőrazonosság elsősorban nem konszenzusproblémát jelent. Irányítási probléma:

• Ki jogosult kiállításra?
• Melyek az aktuális nyilvános kulcsok?
• Melyek az engedélyezett ellenőrzők?
• Mely adatigénylések egyeznek a deklarált céllal?
• Melyik szabályzatverzió volt érvényes az adott időpontban?

A valós ökoszisztémák már irányított megbízhatósági infrastruktúrán keresztül válaszolnak ezekre, nem decentralizált konszenzus útján:

• Az AAMVA digitális megbízhatósági szolgáltatása letölthető listában teszi közzé a kiállító hatóságok nyilvános kulcsait.
• Az EU mobilvezetői engedélyre vonatkozó kézikönyve szerint a Bizottság közzéteszi az engedélyezett mDL-kiállítók listáját.
• Az ETSI pénztárca-támaszkodó fél tanúsítványokra vonatkozó munkája géppel olvasható ellenőrzői hitelesítést biztosít, a szándékolt felhasználással és a regisztrált igényelt attribútumokkal együtt.

Ez egyértelmű nyilvános megbízhatósági adminisztráció — nem decentralizált irányítás.

5. Nem oldja meg az úton felmerülő valóságot

Számos blokklánc-javaslat hallgatólagosan feltételezi, hogy az élő hálózati hozzáférés előnyt jelent. A sofőr-hitelesítő adatoknál — különösen az út szélén vagy utazás közben — ez gyakran nem így van.

Az AAMVA megvalósítási útmutatója rögzíti, hogy:

• Az eszközről való lekérés külső kapcsolat nélkül is működik mind a jogosult, mind az olvasó számára a tranzakció idején.
• Az ISO/IEC 18013-5 szabvány megköveteli az eszközről való lekérés támogatását.
• Az ellenőrzőnek nem kell a tranzakció időpontjában hozzáférnie a kiállítói nyilvános kulcsokhoz. A kulcsok előre letölthetők.

Ha egy ellenőrző már képes helyben érvényesíteni a gyorsítótárazott megbízhatósági anyag alapján, az élő blokklánc-függőség nem nélkülözhetetlen. Legjobb esetben is csupán egy egyes háttérbeli ellenőrzési funkciókra vonatkozó megvalósítási választás.

Minek kell átláthatónak lennie a jövőbeli IDP-ben

A jövőbeli IDP-nek feltétlenül szüksége van átláthatóságra — a megfelelő helyen.

Tegyük ezeket alapértelmezés szerint átláthatóvá:

• Kiállítói nyilvános kulcsok és kulcsrotálási események
• Megbízhatósági horgonyok és engedélyezett kiállítói listák
• Ellenőrzői hozzáférési tanúsítványok és regisztrált célmetaadatok
• Szabályzatverziók és regisztrációs szabályok
• Megfelelőségi nyilatkozatok és biztonsági szempontból releváns szoftverkiadási állítások
• Ellenőrizhető visszaigazolások, amelyek bizonyítják, hogy ezeket az állításokat regisztrálták

Ezeket ne tegyük alapértelmezés szerint nyilvánossá:

• Jogosulti azonosítók nyilvános főkönyvön
• Az ellenőrzők között újra felhasznált stabil hitelesítő azonosítók
• Bemutatásonkénti események
• Nyers visszavonási bejegyzések, amelyek egyetlen személyt azonosítanak
• Személyes adatokat tartalmazó teljes aláírt állítások, ha hash-ek vagy metaadatok is elegendőek lennének

A SCITT kifejezetten figyelmezteti a kiállítókat, hogy az átláthatósági szolgáltatásnak benyújtott állítások tartalmazhatnak magánjellegű, bizalmas vagy személyazonosításra alkalmas adatokat, ezért azokat felülvizsgálat tárgyává kell tenni. Megjegyzi azt is, hogy az átláthatósági szolgáltatások csupán kriptográfiai metaadatokat — például hash-eket — tárolhatnak, nem teljes aláírt állításokat.

Egy jobb minta: átláthatóság az ökoszisztéma körül, nem az egyénen keresztül

A jövőbeli IDP tiszta architektúrája így néz ki:

• Mérvadó nemzeti nyilvántartás — a vezetési jog jogi igazságának forrása marad.
• Hitelesítő adatok rétege — géppel ellenőrizhető vezetési jogosultságokat juttat el a jogosult pénztárcájába.
• Megbízhatósági regiszter rétege — terjeszti a kiállítói kulcsokat, az ellenőrzői tanúsítványokat és az engedélyezett kiállítói listákat.
• Állapot rétege — rövid élettartamú igazolásokat vagy külön frissített, adatvédelmet megőrző állapotlistákat alkalmaz.
• Átláthatósági réteg — belsőleg felhasználhat vagy mellőzhet konszenzust, és naplózza a megbízhatósági horgonyokat, kulcsváltozásokat, szabályzatfrissítéseket, visszaigazolásokat és ökoszisztéma-nyilatkozatokat, amelyek profitálnak a csak hozzáfűzéses nyilvános ellenőrzésből.

Ez az architektúra a blokklánc-gondolkodás hasznos elemeit veszi át — a csak hozzáfűzéses ellenőrizhetőséget, a nyilvános vizsgálatot, a illetéktelen módosítással szembeni védelmet, a visszaigazolásokat — anélkül, hogy a sofőrt tenné a rendszer nyilvános alanyává. Egyúttal megfelel annak, amit a szabványok már leírnak: a regiszterek különböző formákat ölthetnek, a DID-ek nem igényelnek elosztott főkönyveket, a megbízhatósági regiszterek már léteznek, és az adatvédelmet megőrző állapotmechanizmusok már szabványosítva vannak.

A lényegi érv

A jövőbeli IDP-nek a blokklánc legjobb ötletét kell átvennünk — az infrastruktúra nyilvános elszámoltathatóságát —, anélkül hogy elfogadnánk annak legrosszabb alapértelmezését az emberekre nézve: a tartós, globálisan látható nyomkövetést.

A gyakorlatban ez azt jelenti:

• Átláthatóság a kiállítók számára, nem a jogosultak kitettségének növelése
• Ellenőrizhető megbízhatósági horgonyok, nem nyilvános utazási nyilvántartások
• Visszaigazolások szabályzatokhoz és regisztrációkhoz, nem a hitelesítő adatok használatának állandó idővonalai
• Csak hozzáfűzéses bizonyíték az ökoszisztéma-irányításhoz, nem láncon tárolt sofőrazonosság alapértelmezésként

Ez nem a blokklánc elleni érv. Ez egy érv a blokklánc rossz rétegre való alkalmazása ellen.

A jövőbeli IDP igenis alkalmazhat konszenzus-alapú átláthatósági szolgáltatásokat az ökoszisztéma valamely pontján. De ha a tervezés azzal kezdődik, hogy a sofőrt, a hitelesítő adatot vagy a bemutatási nyomvonalat egy főkönyvre helyezi, már a rossz alapértelmezést választotta.