A szalagcím és a valóság
„Az EU életkor-ellenőrző alkalmazása 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 közread egy adatvédelmi eszközt, egy kutató feltöri, a kritikusok pedig rázúdulnak.
Mi másként olvassuk. Az ezt a szalagcímet előállító hibafeltárási 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ő alkalmazásáról szóló részletes hibafeltárási elemzésünket. 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ő alkalmazás 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 hibafeltárása
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 hibafeltárás, 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-s életkor-ellenőrző alkalmazás ugyanazzal a három hibával jelent volna meg, amelyet Paul Moore talált. A fejlesztőcsapaton kívül senki sem tudott volna róluk. A hibák kihasználatlanul maradtak volna (vagy jól finanszírozott támadók csendben kihasználták volna őket), egészen addig, amíg egy valódi incidens nyilvánosságra hozatalra nem kényszerít. A javítási ciklus lassabb lett volna, a rendszerbe vetett bizalom pedig 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.
A technikai közönség pontosította a keretezést. Több, sok 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 szál az r/programmingHungary-n hozta a legszakmaibb vitát, amelyet láttunk: helyesen azonosította a mögöttes OpenID Verifiable Credentials plusz OpenID4VP-szelektív adatközlési protokollréteget, elismerte, hogy az adatvédelmi architektúra az életkor-ellenőrzési tér egyik jobb megoldása, és közben bírálta a Google Play Services-függőséget. 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 hibafeltárási ciklus az a ciklus, amely alapján az ü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 szélső esetet 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ő alkalmazással. 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 teszik működővé az auditciklust.
Fogadjon el hozzájárulásokat. Ha a külső kutatók javításokat is beadhatnak, az fegyelmezi a karbantartókat, és bevonva tartja 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 hibafeltárás 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 technológiai alapot, amelyet a biztonsági kutatók elolvashatnak. Ha az ellenőrzője zárt forráskóddal működik, elfogadja a korábban leírt kudarcmódot: lassabb javítások, alacsonyabb bizalom, nincs út a külső hozzájárulások felé.
Hagyja, hogy az ökoszisztéma elvégezze a biztonsági vizsgálatának egy részét Ön helyett. Annak követése, amit a kutatók a kapcsolódó nyílt forráskódú projektekben találnak — a tárca, az életkor-ellenőrző alkalmazás, a referencia-ellenőrzők — az egyik legnagyobb hatású 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ő alkalmazásában 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