A szalagcím és a valóság
„Az EU életkor-ellenőrző appja 2 perc alatt feltörhető” — ez volt a szalagcím, amely 2026. április 15. és 17. között trendelt a Redditen és a tech-sajtóban. Több mint 6 500 felszavazat az r/europe, r/privacy, r/technology és r/BuyFromEU fórumokon kudarcként keretezte a történetet — az EU szállít egy adatvédelmi eszközt, egy kutató feltöri, a kritikusok rázúdulnak.
Mi másként olvassuk. Az ezt a szalagcímet előállító disclosure-ciklus pontosan az, ahogyan egy közcélú digitális infrastruktúrának működnie kell. Ez a legjobb érv, amit idén láttunk arra, miért kell a kritikus, államközeli szoftvernek nyílt forráskódúnak lennie, és miért kell minden EUDI Tárca-integrációt végző ellenőrzőnek ugyanezt az utat választania.
Paul Moore tényleges leletének technikai elemzéséért lásd az EU életkor-ellenőrző app disclosure-jának részletes elemzését. Ez a bejegyzés egy szinttel feljebb érvel.
Hogyan zajlott valójában a ciklus
0. nap — Az Európai Bizottság bejelenti, hogy az életkor-ellenőrző app technikailag készen áll. Von der Leyen hangsúlyozza, hogy a kód teljes egészében nyílt forráskódú, és bárki átvizsgálhatja.
1. nap — Egy független biztonsági kutató (Paul Moore) elolvassa a nyilvános Android-repót, azonosít három tervezési hibát a helyi állapotkezelésben, és rövid bemutatót tesz közzé az X-en.
2. nap — A Reddit és a technikai sajtó felerősíti a történetet. Az adatvédelmi és biztonsági közösség maga is belemélyül a forráskódba. Más kutatók reprodukálják az eredményeket, tisztázzák a feltételeket, és különválasztják a FUD-ot a jogos aggályoktól.
3. nap és azután — Megindul a javítási ciklus. Az EU referenciacsapata ellen nyilvános issue-k jönnek létre. A javítások a fő ágba kerülnek, nyilvánosan átvizsgálják őket, és a következő kiadásban érkeznek.
Ez egy működő auditciklus, és három napot vett igénybe. A zárt forráskódú szoftver nem mozog ilyen gyorsan, nem hozza ennyire nyilvánosan a felszínre a hibákat, és nem teszi lehetővé a közösségnek, hogy fokozatosan bizalmat építsen annak olvasásával, mit és miért javítanak.
Hogyan néz ki ehelyett egy zárt tárca-disclosure
Vesse össze az EUDI Tárca-ciklust azzal, ahogy történelmileg lezajlottak az azonosítás-ellenőrző szolgáltatói adatlopások. Böngésszen át bármelyik nagy nyilvánosságot kapott incidenst az elmúlt években az ellenőrzési piacról, és egy mintázat rajzolódik ki:
- A szolgáltató belsőleg felfedezi vagy gyanítja a problémát.
- Hetek vagy hónapok telnek el, mielőtt bárki külső tudomást szerezne róla.
- A javítás zárt ajtók mögött kezdődik, nyilvános részletek nélkül arról, mit javítanak.
- A disclosure, ha egyáltalán megtörténik, utólagos szabályozási bejelentés vagy a hatókört minimalizáló sajtónyilatkozat.
- A végfelhasználóknak és az integrátoroknak nincs módjuk ellenőrizni, hogy a javítás valóban a gyökérokot kezeli-e, mert a forrás nem nyilvános.
Ez az ellenpélda. Egy zárt forráskódú EU életkor-ellenőrző app ugyanazzal a három hibával szállt volna le, amelyet Paul Moore talált. A fejlesztőcsapaton kívül senki sem tudott volna róluk. A hibák kihasználatlanul ültek volna (vagy csendesen kihasználva a jól finanszírozott ellenfelek által), egészen addig, amíg egy valódi incidens disclosure-ra nem kényszerít. A javítási ciklus lassabb lett volna. A rendszerbe vetett bizalom alacsonyabb.
A konkrét állítások, amelyek kiállták a próbát
A Reddit technikai reakciójára érdemes odafigyelni, mert nem egyszerűen egyetértett a kutatóval. Egyetértett az állítás bizonyos részeivel, nem értett egyet a keretezés bizonyos részeivel, és megfigyeléseket adott hozzá, amelyeket a kutató elmulasztott.
Helytálló kritika, pontosan jelentve. Három tervezési hiba a helyi állapotkezelésben egy rootolt, fizikailag feltört eszközön. Ezek valósak és javítva lesznek.
Keretezési visszalökés a technikai közönségtől. Több legtöbb felszavazatot kapott komment a subreddit-eken rámutatott, hogy a „rootolt eszköz fizikai hozzáféréssel” lényegesen szűkebb fenyegetésmodell, mint amit a „2 perc alatt feltörve” sugall. Az r/europe 832 felszavazatos kommentje egyszerűen megjegyezte: „így kell a nyílt forráskódú szoftvernek működnie”.
További aggályok, amelyeket a közösség felszínre hozott. A platformattesztációra való támaszkodás követelménye (amely kényszerítően iOS-t vagy Androidot hoz), a Google Play Services függés az Android-buildben, valamint a szabad (libre) kliensek felé vezető út hiánya — mindezeket közösségi tagok vetették fel ugyanazt a forráskódot olvasva. Ezek komolyabb stratégiai kérdések, mint a helyi állapot-hibák, és egy zárt megvalósításban láthatatlanok lettek volna.
Szakmailag megalapozott elismerés. A magyar fejlesztői topik az r/programmingHungary-n vitte a leginkább szakmailag megalapozott vitát, amelyet láttunk: a mögöttes OpenID Verifiable Credentials plusz OpenID4VP-szelektív adatközlés stack helyes azonosítása, annak elismerése, hogy az adatvédelmi architektúra az életkor-ellenőrzési tér egyik jobb tervezése, egyidejűleg a Google Play Services-függőség kritikája. Az ilyen árnyalt nyilvános értékelés egyszerűen nem történhetne meg zárt kóddal szemben.
Miért fontos ez konkrétan az ellenőrző feleknek
Ha olyan ellenőrzőt épít, amely EUDI Tárca-tanúsítványokat fog éles üzemben fogadni, a most látott disclosure-ciklus az a ciklus, amelyen az Ön ügyfelei meg fogják ítélni Önt. A kereskedők és a végfelhasználók nem fogják olvasni a forráskódját. Azt fogják olvasni, hogy milyen incidensek és javítások történtek, és milyen gyorsan. Egy olyan nyílt forráskódú ellenőrző SDK, amely nyilvánosan javítja a hibákat, megörökli annak a tárca-ökoszisztémának a bizalomépítő tulajdonságait, amelyben részt vesz.
Az OpenEUDI-t erre az elvre építettük. Az ellenőrzői logika minden sora MIT-licencű és nyilvánosan auditálható. Ha valaki talál egy hibát, be tudja nyújtani, mi nyilvánosan javítjuk, és minden integrátor látja a javítást. Ha valaki meg akarja érteni, hogyan kezelünk egy trükkös peremesetet az OpenID4VP-ben, olvashatja a kódot, ahelyett hogy a marketingünkben bízna. Az OpenEUDI SDK-gyorsindító oktatóanyag pontosan azt a megvalósítást mutatja be, amelyet egy biztonsági kutató auditálna.
A szuverenitási érv
Van egy második érv, amelynek semmi köze a hibákhoz. Az EU évek óta megfogalmazza a digitális szuverenitás melletti érvelést: az európai polgárok azonosítási adatai, az európai intézmények kriptográfiai kulcsai, az európai szabályozók auditálási jogai nem függhetnek olyan szoftvertől, amelynek forráskódját az EU-n kívüli szolgáltatón kívül senki sem olvashatja.
Ebből az álláspontból az egyetlen tisztességes következtetés az, hogy minden EU-kötelezett azonosítási infrastruktúrának nyílt forráskódúnak kell lennie. Nem marketingbeli nyílt forráskódnak, hanem forráshoz hozzáférhető, reprodukálhatóan építhető és közösségileg auditálható kódnak. Minden ennél kevesebb olyan szuverenitási rést hagy maga után, amelyet semennyi tanúsítási papírmunka nem tölt be.
Az EU komolyan vette ezt a következtetést a tárcával és az életkor-ellenőrző appal. Az ellenőrzői infrastruktúrának ugyanolyan komolyan kell vennie. Egy olyan ellenőrző, amely nyílt forráskódú tárca-tanúsítványokban bízik meg, de ő maga zárt kódon fut, a legjobb esetben is következetlen, a legrosszabb esetben stratégiailag törékeny.
Mit kell jelentenie a „nyílt forráskódnak” egy ellenőrző számára
A tisztánlátás kedvéért: a „nyílt forráskód” szükséges, de nem elégséges feltétel. Egy nyílt forráskódú ellenőrzőnek a következőknek is meg kell felelnie:
Auditálhatónak kell lennie, nem csak olvashatónak. A teszt-lefedettség nélküli vagy átláthatatlan függőségi láncú kód technikailag olvasható, de gyakorlatilag nem auditálható. Az ENISA-tanúsítási séma tervezete megragadja ezt a különbséget a tárcák kontextusában, és ugyanaz a mérce vonatkozik az ellenőrzőkre is.
Nyilvánosan javítsa a hibákat. Egy privát javítás egy nyilvános repóban az érték felét jelenti. Az issue trackerek, a nyilvános pull requestek és az átlátható changelogok azok, amik az auditciklust működővé teszik.
Fogadjon el hozzájárulásokat. A külső kutatóknak engedélyezni a javítások beadását tartja őszintén a karbantartót, és tartja bevonva a közösséget.
Tartson meg megengedő licencet. MIT, Apache 2.0 vagy hasonlóan megengedő licenc. A copyleft licencek filozófiailag védhetők, de gyakorlatilag korlátozzák, ki fog integrálni a kódjával.
Tanulságok az ellenőrzői oldal számára
A 2026. áprilisi disclosure három tartós tanulságot hagy mindenki számára, aki az EUDI Tárca-ökoszisztémára épít.
Használjon auditálható kódot. Akár az OpenEUDI SDK-t, egy másik nyílt megvalósítást fogad el, akár sajátot épít, válasszon olyan stacket, amelyet a biztonsági kutatók elolvashatnak. Ha az ellenőrzője zárt forráskódban szállít, elfogadja a korábban leírt kudarcmódot: lassabb javítások, alacsonyabb bizalom, nincs út a külső hozzájárulásokra.
Hagyja, hogy az ökoszisztéma elvégezze a biztonsági vizsgálatának egy részét Ön helyett. Annak olvasása, amit a kutatók a kapcsolódó nyílt forráskódú projektekben találnak — a tárca, az életkor-ellenőrző app, a referencia-ellenőrzők — az egyik legnagyobb tőkeáttételű biztonsági tevékenység, ami egy ellenőrzőcsapat számára elérhető. Még incidenssé válásuk előtt megkapja a leleteket.
Válassza el az adatvédelmi architektúrát a megvalósítási hibáktól. Azok a kritikusok, akik azt mondják, hogy „az EU életkor-ellenőrző appban hibák vannak, tehát az egész adatvédelem-központú megközelítés rossz”, tévednek. A kriptográfiai tervezés szilárd. A hibák a helyi állapotkezelésben vannak, nem a protokollban. Arról, hogyan építsen ugyanazokra az adatvédelmi primitívekre, lásd Adatvédelem-központú életkor-ellenőrzés OpenEUDI-val cikkünket.
A csendes győzelem
Ha van egyetlen mondat, amelyet ebből az egész epizódból magával vihet, akkor az az, amit az r/europe legfelül kommentelője írt: „így kell a nyílt forráskódú szoftvernek működnie”. Ez nem a hibák védelme. Ez annak a rendszernek a leírása, amely megtalálja és kijavítja őket. Ez a rendszer jobb az alternatívánál, és a különbség egyre nagyobb, valahányszor egy zárt forráskódú szolgáltatónál incidens történik, amelyet a régi módon kezel.
Az EU elkötelezte magát amellett, hogy az azonosítási infrastruktúráját nyíltan építi. Az ellenőrzőkészítőknek ugyanezt az elkötelezettséget kell vállalniuk. Az infrastruktúra jelenlegi állapotáért a 27 tagállamban lásd 2026. áprilisi bevezetési követőnket, a mögötte lévő szabályozási keretért pedig lásd az IR 2026/798 magyarázónkat.
Az OpenEUDI MIT-licencű, auditálható és ingyenes. Menedzselt WRPAC-tanúsítványokkal és teljesen nyílt forráskódú kódbázissal történő éles üzemű ellenőrzéshez lásd az eIDAS Pro menedzselt csomagjait.
Címkék
Cikk megosztása
Segítsen másoknak megismerni az eIDAS-ellenőrzést