ZKP és adatvédelem a dVPN hálózatokban | Web3 biztonság

A bizalmi kérdés a hagyományos VPN-eknél

Gondolkoztál már azon, miért adjuk át a teljes digitális életünket egyetlen VPN-szolgáltatónak, reménykedve abban, hogy nem néznek bele az adatainkba? Őszintén szólva elképesztő, hogy 2025-ben a legfőbb adatvédelmi bástyánk még mindig egy központosított vállalat „becsületszava”.

A legtöbb hagyományos szolgáltató fennhangon hirdeti a „naplózásmentes” (no-logs) irányelveit, de hálózati szakemberként látom a csomagszintű valóságot. Még ha nem is mentik el a böngészési előzményeidet, a csatlakozás pillanatában továbbra is látják a valódi IP-címedet és az időbélyegeket.

• Központosított hibaforrások: A hagyományos szolgáltatók saját kontroll alatt álló szerverfürtöket üzemeltetnek. Ha egy kormányzati szerv adatkéréssel fordul hozzájuk, vagy egy hacker rendszergazdai (root) hozzáférést szerez, az adataid ott fognak heverni a RAM-ban.
• A bizalmi szakadék: Kénytelen vagy hinni nekik. Az ExpressVPN egyik 2024-es tanulmánya megjegyzi, hogy a felhasználók alapvetően a szolgáltató őszinteségére vannak utalva, mivel nincs technikai eszköz annak ellenőrzésére, mi történik valójában a háttérrendszerekben.
• Adatmegőrzési törvények: Számos joghatóságban az internetszolgáltatókat és a VPN-cégeket törvény kötelezi bizonyos metaadatok tárolására, ami bizonyos régiókban jogilag lehetetlenné teszi a valódi „naplózásmentességet”.

Éveket töltöttem az internetszolgáltatói megfigyelések tanulmányozásával, és a probléma mindig a közvetítőnél (middleman) gyökerezik. Ha a szervernek azonosítania kell téged a hitelesítéshez, akkor ez az információ máris biztonsági kockázattá válik.

A Wikipedia szerint a zéró tudású igazolásokat (Zero-Knowledge Proof – ZKP) már 1985-ben kidolgozták pontosan azért, hogy megoldják ezt a dilemmát: hogyan igazolható a jogosultság titkok felfedése nélkül. Végre eljutottunk oda, hogy ez a koncepció a matematikai tanulmányokból átkerül a valódi forráskódokba.

A valódi probléma tehát nem csupán a rosszindulatú szereplőkben, hanem magában az architektúrában rejlik. Olyan rendszerre van szükségünk, ahol a hálózat képes igazolni a fizetés tényét vagy a hozzáférési jogosultságot anélkül, hogy valójában tudná, ki vagy „te”.

A következőkben azt nézzük meg, hogyan írja át a ZKP ezt a forgatókönyvet a bizalmi probléma megoldása érdekében.

Mik azok a zéró tudású igazolások egyáltalán?

Ha próbáltál már kriptográfiát magyarázni valakinek, aki nem „hálózatos szakember”, pontosan tudod, milyen nehéz feladat. Pedig a zéró tudású igazolások (Zero-Knowledge Proof – ZKP) koncepciója valójában pofonegyszerű, ha egy pillanatra elfelejtjük a prímszámokat, és inkább egy bűvös barlangra gondolunk.

A szakmában ezt klasszikusan az Ali Baba barlangjának történetével szemléltetjük. Képzeljünk el egy kör alakú barlangot két útvonallal (A és B), amelyek a barlang mélyén egy titkos ajtónál találkoznak. Peggy ismeri a jelszót, amivel az ajtó nyílik; Victor bizonyítékot akar arra, hogy Peggy nem hazudik, de Peggy nem akarja elárulni magát a jelszót.

A bizonyításhoz Peggy bemegy a barlangba, miközben Victor kint várakozik. Victor ezután bekiabál: „Gyere ki az A útvonalon!” Ha Peggy az ajtónál áll, kinyitja azt, és megjelenik a kért oldalon. Ha ezt hússzor megismétlik, és Peggy egyszer sem hibázik, a matematika szabályai szerint szinte biztos, hogy ismeri a jelszót. Ez azért működik, mert minden egyes sikeres körrel feleződik az esélye annak, hogy csak szerencséje volt; 20 kör után az esélye annak, hogy csaló, nagyjából egy a millióhoz. Ezt hívjuk a matematika világában „megalapozottságnak” (soundness).

Ahogy azt a Concordium is megjegyezte, itt egy paradigmaváltásról van szó: az „adatmegosztásról” áttérünk a „bizonyíték-megosztásra”. Ahhoz, hogy egy protokoll valóban ZKP-nak minősüljön, három technikai feltételnek kell megfelelnie:

• Teljesség (Completeness): Ha az állítás igaz, egy becsületes igazoló minden esetben meggyőzi az ellenőrt. A logikában nincs helye „téves negatívnak”.
• Megalapozottság (Soundness): Ha Peggy hazudik, nem tudja becsapni Victort, csak valamilyen elenyészően kicsi, asztronómiai véletlen folytán. A NIST definíciója szerint ezt gyakran „tudásalapú ZKP-nak” nevezik, ahol azt igazolod, hogy birtokodban van a „tanú” (a titok).
• Zéró tudás (Zero-knowledge): Ez a legfontosabb pont. Victor semmit nem tud meg magáról a jelszóról, csak annyit, hogy Peggy ismeri azt.

Az én szakterületemen az identitást általában kockázati tényezőnek tekintjük. Ha egy dVPN csomópont (node) ismeri a publikus kulcsodat, az már egy csomagszintű digitális nyom. A ZKP ezt a helyzetet fordítja meg.

A Concordium egyik 2024-es cikke rávilágít, hogy a vállalatok számára az adatvédelem már nem csupán egy extra funkció, hanem „alapkövetelmény”. Legyen szó arról, hogy igazolnod kell a 18. életévedet egy webshopban, vagy hitelesítened kell egy egészségügyi leletet, a ZKP lehetővé teszi a folyamat logikai ellenőrzését anélkül, hogy az érzékeny adatokat kitennénk a hálózatra.

A következőkben nézzük meg, hogyan tartja ez a technológia valóban rejtve az IP-címedet egy decentralizált hálózatban.

A ZKP alkalmazása a dVPN ökoszisztémában

Hogyan ültetjük át a gyakorlatba ezt a „mágikus barlangos” matematikát egy dVPN-be? Papíron jól mutat, de amikor a nyers adatcsomagok befutnak egy csomóponthoz (node), a dolgok hamar bonyolulttá válnak. Egy hagyományos hálózatban a szerver általában egy adatbázis alapján ellenőrzi a személyazonosságot – ami adatvédelmi szempontból hatalmas vörös posztó.

A cél itt az anonim hitelesítés. Azt szeretnénk, hogy a node tudja: neked jogod van a sávszélesség használatához, anélkül, hogy ismerné a kilétedet vagy a fizetési előzményeidet.

A legtöbb modern dVPN projekt a zk-SNARK (Succinct Non-Interactive Arguments of Knowledge) technológiát alkalmazza. Ahogy korábban láttuk, ezek azért kiválóak, mert nincs szükség folyamatos oda-vissza kommunikációra a felek között.

• Előfizetési igazolások: Bizonyítani tudod a blokkláncon, hogy kifizetted a havi csomagot. A node ellenőriz egy „igazolást”, amely tanúsítja, hogy a tárcád szerepel a „fizetett” listában, anélkül, hogy valaha is látná a tárcacímedet.
• Hozzáférés-kezelés: Ahelyett, hogy felhasználónevet és jelszót használnál – amit egy internetszolgáltató (ISP) lehallgathatna, vagy egy node naplózhatna –, egy kriptográfiai igazolást küldesz. Ez olyan, mintha felmutatnál egy „hitelesített” jelvényt a személyi igazolványod átadása nélkül.
• Node-reputáció: A csomópontok is használhatják a ZKP-t annak igazolására, hogy nem rosszindulatúak – például bizonyíthatják, hogy nem módosították a csomagokat – anélkül, hogy felfednék a belső szerverarchitektúrájukat.

Egy P2P hálózatban az IP-címed gyakorlatilag az otthoni lakcímednek felel meg. Ha egy node-üzemeltető tisztességtelen, minden csatlakozó IP-címet naplózhatna. A kézfogás (handshake) során alkalmazott ZKP segítségével azonban szétválasztjuk az „identitást” a „kapcsolattól”.

A Cloudflare adatai szerint már 2021-ben elkezdték használni az „egy-a-sokból igazolásokat” a privát webes hitelesítéshez. Ez lényegében lehetővé teszi a felhasználó számára, hogy igazolja: a jogosult felhasználók csoportjába tartozik (például „fizetős előfizető”), anélkül, hogy elárulná, pontosan melyik felhasználó ő. Ha egy ekkora óriás ezt használja a hardverek ellenőrzésére adatvisszaélés nélkül, biztos lehetsz benne, hogy a dVPN-ek is ugyanezt teszik a felhasználói munkamenetek biztosítására.

Az olyan projektek, mint a SquirrelVPN, már implementálják ezeket a zk-SNARK alapú kézfogásokat, hogy még az a csomópont se tudja, ki vagy valójában, amelyhez közvetlenül csatlakozol.

A következőkben azt vizsgáljuk meg, hogyan teszik ezek az igazolások működőképessé a sávszélesség-megosztás gazdasági oldalát anélkül, hogy bárki biztonsága sérülne.

Sávszélesség-bányászat és tokenizált jutalmak

Tekintsünk a „sávszélesség-bányászatra” úgy, mint az internet Airbnb-jére. Gyakorlatilag engedélyezzük idegeneknek, hogy áthaladjanak az otthoni hálózatunk digitális folyosóján, amiért cserébe tokenekben kapunk díjazást. Azonban a zéró tudású bizonyítások (ZKP) nélkül ezek az idegenek – vagy akár maga a hálózat – sokkal többet láthatnának a „házunkban” zajló eseményekből, mint amennyit szeretnénk.

Egy P2P (peer-to-peer) felépítésben két dolgot kell igazolnunk: azt, hogy a csomópont (node) valóban továbbította az adatokat, és azt, hogy a felhasználó rendelkezik a fizetéshez szükséges kreditekkel. Korábban ez azt jelentette, hogy a hálózatnak minden egyes adatcsomagot nyomon kellett követnie, ami hatalmas adatvédelmi rést jelentett.

• Útválasztási igazolás (Proof of Routing): ZKP-t használunk annak igazolására, hogy egy csomópont adott mennyiségű forgalmat kezelt. A node egy olyan „bizonyítékot” küld a blokkláncnak, amely egyezik a felhasználó „nyugtájával”, de egyik fél sem fedi fel a csomagok tényleges tartalmát vagy célállomását.
• Tokenizált ösztönzők: Az üzemeltetők az igazolt rendelkezésre állás és az átvitt adatmennyiség alapján kapnak jutalmat. Mivel az ellenőrzés zéró tudású technológiával történik, a hálózatnak nem kell ismernie az üzemeltető valós személyazonosságát ahhoz, hogy a tokeneket a tárcájába utalja.
• Fair Exchange (Méltányos csere): Ahogy a szakirodalom is hivatkozik rá, ezek a protokollok biztosítják, hogy a „bizonyító” (a node) meggyőzze az „ellenőrzőt” (a hálózatot) az elvégzett munkáról anélkül, hogy a munka során kezelt érzékeny adatokat fel kellene fednie.

Őszintén szólva, láttam már elég internetszolgáltatói (ISP) megfigyelést ahhoz, hogy tudjam: ha nem anonimizáljuk a fizetési réteget, akkor valójában nem beszélhetünk valódi adatvédelemről. Ha a kriptovaluta-tárcánk címe összeköthető az otthoni IP-címünkkel és a forgalmi naplókkal, akkor a dVPN-ben (decentralizált VPN) a „VPN” rész gyakorlatilag értelmét veszti.

A következőkben azt vizsgáljuk meg, hogyan érhetjük el, hogy a hálózat ne lassuljon le ezen komoly matematikai műveletek végzése közben – ez a kirakós „Succinct”, azaz tömörségi része.

A ZKP technológiai akadályai a hálózatkezelésben

Nézzék, én rajongok a zéró tudású igazolások (ZKP) mögött álló matematikáért, de legyünk őszinte egy pillanatra: ezt átültetni egy élő hálózatba kőkemény kihívás. Egy dolog a táblán bebizonyítani, hogy tudunk egy titkot, és egy teljesen másik dolog ugyanezt megtenni akkor, amikor valaki éppen egy 4K-s videót próbál streamelni egy decentralizált csomóponton keresztül.

A zk-SNARK technológia nevében szereplő „tömörség” (Succinct) elvileg a gyorsaságot szolgálná, de az igazolások generálása még mindig brutális módon zabálja a CPU-ciklusokat. Ha a telefonodnak komoly számítási teljesítményt kell kifejtenie csak azért, hogy hitelesítsen egy adatcsomagot, az akkumulátorod pillanatok alatt lemerül, a késleltetés (latency) pedig az egekbe szökik.

A csomagszintű elemzések során szerzett tapasztalataim alapján a routingnál minden ezredmásodperc számít. Amikor bevezetjük a ZKP-t, gyakorlatilag egy „számítási adót” vetünk ki minden egyes kézfogásra (handshake).

• CPU-túlterhelés: Egy igazolás generálása nagyságrendekkel erőforrás-igényesebb, mint annak ellenőrzése. A legtöbb dVPN-felhasználó mobilról vagy olcsó routerekről csatlakozik, amelyek nem éppen szuperszámítógépek, így a „bizonyító” (prover) oldal válik a szűk keresztmetszetté.
• Áramköri hibák (Circuit Bugs): Ha a matematika nem golyóálló, „alulkorlátozott áramkörök” (under-constrained circuits) jönnek létre. Az olyan kiberbiztonsági cégek jelentései, mint a Trail of Bits, rámutattak, hogy a SNARK-hibák túlnyomó többsége ezekből a logikai résekből fakad, ahol egy támadó potenciálisan hamis igazolást generálhat.
• Hálózati lag: Az interaktív igazolások folyamatos oda-vissza kommunikációt igényelnek. De még a nem-interaktív változatoknál is gondot okozhat az igazolások mérete. Például a zk-STARK-ok – a ZKP egy másik típusa – nem igényelnek „megbízható beállítást” (trusted setup), ami biztonságosabbá teszi őket, viszont sokkal nagyobb az igazolási méretük, ami pont azt a sávszélességet tömíti el, amit megvédeni próbálunk.

Őszintén szólva a fejlesztők többsége még mindig azt az „arany középutat” keresi, ahol a biztonság már kikezdhetetlen, de az internetélmény még nem emlékeztet az 1995-ös betárcsázós korszakra.

A következőkben megnézzük, hogyan próbálja az iparág valójában orvosolni ezt a késleltetési problémát, hogy végre ne kelljen választanunk a privát szféra és a sebesség között.

A cenzúramentes internet jövője

Vajon mi a végcélja ennek a rengeteg matematikai fejlesztésnek? Őszintén szólva, egy olyan teljes szemléletváltás előtt állunk, ahol a „beépített adatvédelem” (privacy by design) már nem csupán egy marketinges szlogen, hanem a hálózat forráskódjába égetett valóság lesz.

Ahogy haladunk a DePIN (decentralizált fizikai infrastruktúra-hálózatok) korszaka felé, az a régi modell, amelyben egy központi VPN-szolgáltatónak adjuk át a személyazonosságunkat, hamarosan olyan őskövületnek tűnik majd, mint a betárcsázós internet. A jövő a „szelektív közzétételről” szól: csak azt igazoljuk, ami feltétlenül szükséges, és semmi többet.

Az internet következő korszakát nem az határozza meg, hogy ki gyűjti a legtöbb adatot, hanem az, hogy ki jön rá, miként igényelheti a legkevesebbet. Itt lépnek be a képbe a zkVM-ek (zéró tudású virtuális gépek). Ezek lehetővé teszik, hogy komplex logikai műveleteket – például annak ellenőrzését, hogy a felhasználó korlátozott régióból jelentkezik-e be, vagy rendelkezik-e érvényes előfizetéssel – láncon kívül (off-chain) futtassunk le, majd csak egy apró igazolást tegyünk közzé a blokkláncon.

• Skálázható adatvédelem: Az olyan eszközök, mint a RISC Zero vagy a Succinct Labs lehetővé teszik a fejlesztők számára, hogy a zéró tudású bizonyítékok (ZKP) logikáját olyan hétköznapi nyelveken írják meg, mint a Rust. Ez azt jelenti, hogy a dVPN-ek a korábban említett hatalmas „számítási adó” nélkül is képesek lesznek skálázódni.
• Cenzúrával szembeni ellenállás: Ha egy csomópont (node) nem tudja, ki vagy és mit nézel, a kormányok számára is sokkal nehezebb kényszeríteni az adott csomópontot a blokkolásra.
• Vállalati adaptáció: Ahogy azt a Concordium is említette, a vállalkozások kezdenek úgy tekinteni az adatokra, mint kockázati forrásra. Ha nem tárolják a felhasználói adatokat, nem is veszíthetik el azokat egy adatvédelmi incidens során.

Bár a technológia még gyerekcipőben jár, az irány egyértelmű. Egy olyan internetet építünk, ahol nem kell külön kérned az adatvédelmet – az alapértelmezetten, protokollszinten garantált lesz. Találkozunk a következő technológiai elemzésnél!