| | | | | Mottó:
Ami vagy, amit hinni se mersz,
Hogy egyedi vagy, ami csak te lehetsz,
Hogy többet érsz, mint egy platinakártya,
Egy TAJ szám, egy mobil, pénztárca.
/Kowalsky meg a Vega: Mit mondjak még?/ | | 2023. június 30. | | | | | eSignDay: European Digital Identity Wallet (eIDAS 2.0) | | | | | | A "wallet" vagy "tárca" fogalomról az utóbbi években sokszor lehetett hallani, mert a "mobil adattárca" központi téma volt a Digitális Jólét Programban is, a "mobil pénztárca" pedig a POS-terminálos fizetésre alkalmas, emulált bankkártyákkal már elérhető több fejlesztőtől, sőt a fintech hírportálokon már szupertárcákról is lehet olvasni. Nos, a helyzet az, hogy ezek az elképzelések nincsenek is annyira messze attól, amit az eIDAS 2.0 hoz be "European Digital Identity Wallet" fogalomként...
Maga az eIDAS 2.0, mint jogszabály gyökerei 1999-ig nyúlnak vissza, amikor megszületett az elektronikus aláírásról szóló irányelv (Directive 1999/93/EC). Ezt követte az eIDAS 1.0 (Regulation (EU) No 910/2014), ami az elektronikus aláírás mellett szabályozta az elektronikus azonosítást és az azonosított felhasználókról egy szűk adathalmaz lekérdezhetőségét és továbbítását. Most, az eIDAS 2.0 ezen lekérdezhető adatkört nyitná ki teljesen és minden funkciót - minősített elektronikus aláírás létrehozását, a felhasználó-hitelesítést és a felhasználó-azonosításhoz kapcsolódóan tetszőleges felhasználói adat elérhetőségét - egy egységes, szabványos tárca keretrendszeren keresztül biztosítana.
Az ilyen, EU szinten egységesen alkalmazandó műszaki szabályozások bevezetése előtt szoktak kísérleti projekteket, LSP-ket (Large-Scale Pilot) tartani. Az eIDAS 1.0 előtt a STORK (Secure idenTity acrOss boRders linKed) projektből estek ki a kipróbált, pontos specifikációk. Az eIDAS 2.0 esetében is elindult négy ilyen LSP (EWC, DC4EU, POTENTIAL, NOBID), amelyek közül háromban magyar partner is szerepel. Ezek célja tehát az, hogy megvizsgálják, hogy az EU által kiadott ARF (Architecture and Reference Framework) dokumentumban meghatározott kezdeti műszaki feltételek szerinti rendszerek életképesek lehetnek-e, vagy milyen más specifikáció szerint lennének jók.
De mi is pontosan az eIDAS 2.0 szerinti "wallet"?
A jogszabályi fogalommeghatározás igazából ismerős dolgokat tartalmaz, hiszen egy eIDAS szerinti rendszernek továbbra is biztosítania kell valahogy- minősített elektronikus aláírás létrehozását,
- felhasználó hitelesítését (akár erős ügyfél-hitelesítés révén is, SCA - Strong Customer Authentication - követelményeknek megfelelően),
- a beazonosított felhasználóról adatok szolgáltatását.
Az újdonság talán ott jön elő, hogy az eddigi, jellemzően "online" folyamatok mellett mindezeket a funkciókat "offline" folyamatoknál is támogatni kell. (Ez viszont újragondolást igényelhet, illetve eleve valószínűleg csak néhány folyamatnál lesz lehetséges az "offline" működés támogatása, hiszen sok esetben van szükség a naprakészség miatt a friss adatokért való bekérdezésre, vagy egyszerűen csak a jogosultságellenőrzésre szerver oldalon, akár a felhasználói "consent" érvényre juttatása miatt is, de elektronikus aláírásnál is el kell tudni érni a visszavonási adatokat "online".)
Az ARF (Architecture and Reference Framework) dokumentumban található dobozkás ábra bemutatja az eIDAS 2.0 szerinti "wallet" megoldást és annak környezetét. Az érdekes az, hogy lényegét tekintve azonban nincs olyan nagy változás az eIDAS 1.0 szerint létrejött rendszerekhez képest. Legalábbis Magyarországon... (elképzelhető, hogy más országban komolyabb továbbfejlesztést fog igényelni a megfelelés az új feltételeknek, de a hazai ökoszisztéma viszonylag fájdalommentesen tudja az eIDAS 2.0 környezetet is támogatni).
De miért is mondom ezt? Az eIDAS 1.0 szerinti rendszerek jelenleg is támogatják- minősített elektronikus aláírás létrehozását: élő KAÜ session birtokában AVDH rendszerrel ("online") - bár, ez nem minősített elektronikus aláírást hoz létre, de a teljes bizonyító erejű magánokiratot igénylő folyamatokhoz ez is elégséges jelenleg Magyarországon - vagy eSzemélyi okmány eSIGN applet-tel ("offline"),
- felhasználó hitelesítését: KAÜ mögötti pl. Ügyfélkapu+ révén ("online") vagy eSzemélyi okmány eSIGN és ePASS applet-tel ("offline"),
- a beazonosított felhasználóról adatok szolgáltatását: KAÜ mögötti pl. ÖNY vagy JKÜ révén, esetleg KKSZB révén ("online") vagy eSzemélyi okmány ePASS applet-tel ("offline").
Bár, a közigazgatási szakrendszerek mellett a piaci szereplők számára is elérhetővé tette a jogszabály a KAÜ, ÖNY, AVDH stb. (SZEÜSZ/KEÜSZ) rendszerek használatát, azonban a csatlakozások adminisztratív oldala meglehetősen bonyolult, illetve ha valaki nem jogosult a díjmentes igénybe vételre, akkor annak továbbra is várnia kell, míg kialakítják a díjtáblázatokat. Akinek viszont a jogszabály "a Pmt. szerinti ügyfél-átvilágítás (a továbbiakban: ügyfél-átvilágítás) céljára, közérdekből díjmentesen biztosítja" ezen rendszerekhez való hozzáférést, az be tudja illeszteni őket a saját üzleti folyamataiba. Ne felejtsük el, hogy 2023-02-01 óta ezen jogosulti kör tagja lehet az összes "2017. évi LIII. törvény (a továbbiakban: Pmt.) 1. § (1) és (1a) bekezdése szerinti szolgáltató", beleértve a hitelintézeteken (bankokon) túlmenően a biztosítókat, nyugdíjpénztárakat, ingatlanirodákat, online kaszinókat és távszerencsejátékokat vagy akár úgy általánosságban az ügyvédi irodákat!
Az eSzemélyi okmány kapcsán is még sokan csak varázslatként tekintenek az NFC-s adatkiolvasási és elektronikus aláírási lehetőségekre, pedig pont a banki világgal, a bankkártyákkal való hasonlatosság miatt azt lehetne feltételezni, hogy ma már teljesen természetes, ha- a bankkártya vagy eSzemélyi okmány beköltözik a mobiltelefonba (pl. Credit Card Tokenization),
- a bankkártya vagy eSzemélyi okmány NFC-n keresztül kommunikál egy másik eszközzel (pl. MasterCard PayPass vagy Visa payWave POS terminál, tablet, mobiltelefon),
- a bankkártya vagy eSzemélyi okmány adatai távoli szervereken kerülnek letárolásra és tranzakció során meghívásra (pl. Host Card Emulation).
Az ARF (Architecture and Reference Framework) dokumentum megkülönböztet két "wallet" konfigurációt: Type 1 és Type 2. Alapvetően, az eIDAS 2.0 szerinti az újabb interfészeket fogja támogatni a Type 1 rekeszben és minden más - pl. eIDAS 1.0 szerinti - interfészű megoldás a Type 2 rekeszben fog helyet kapni. Az eltérő konfigurációkhoz eltérő joghatások is fognak társulni. (Az még nem is világos, hogy az eIDAS 1.0 szerinti rendszerek, amikhez jelenleg is komoly joghatás társul - de a régebbi interfészek miatt a Type 2 rekeszbe kerülnek -, milyen joghatással fognak bírni a jövőben, ha esetleg nem tudnak Type 1 rekeszre váltani?! Részben ezen bizonytalanságok miatt is az fontos célkitűzés, hogy az eIDAS 1.0 szerinti - legacy - rendszerek a kisebb továbbfejlesztések révén meg tudjanak felelni az eIDAS 2.0 szerinti követelményeknek, hogy a joghatásuk megmaradjon, azaz ne kelljen az eIDAS 2.0 miatt mindent nulláról kezdeni, újrafejleszteni, mert az rengeteg időt és költséget jelentene.)
Érdemes kiemelni, hogy az eIDAS 2.0 és a "wallet" kapcsán megjelenő "offline" folyamatok támogathatósága, az ezzel együtt járó nagyobb felhasználói kontroll az adatok felett, illetve a lekérdezhető, továbbítható adatok körének jelentős kibővítése azt sugallja, hogy nem csak az eIDAS 1.0 volt a kiindulási alap az új jogszabályhoz, hanem vélhetőleg ezen eIDAS 2.0 tudná a műszaki megvalósítást adni a GDPR 20. cikk szerinti "Az adathordozhatósághoz való jog" követelményéhez is. (Itt is szükség lehet újragondolásra abból a szempontból, hogy jelenleg a tranzakciókat indító felek eddig mind jogi személyek voltak - jogi személyek vannak regisztrálva jelenleg is a SZEÜSZ/KEÜSZ rendszerekhez -, viszont ebben a modellben a természetes személyek is indíthatnák a tranzakciókat, amire egyébként a jogszabály lehetőséget is ad.)
Látszik tehát, hogy a lekérdezhető, továbbítható adatok kapcsán a "wallet" érinti az eIDAS 1.0 és eIDAS 2.0 mellett a GDPR-t, illetve annak kormányzati oldalát szabályozó DGA-t és SDG-t (ennek II. mellékletében szereplő 21 eljárás került be egyébként a Nemzeti Digitális Állampolgárság Programba), de lefedhet néhány szektor-specifikus területet is, mint a banki PSD2-t (számlainformációkat, számlatörténetet lekérdező AISP rendszereket) vagy egészségügyi CBH-t (kórelőzményeket és hordható eszközök által mért aktuális adatokat lekérdező rendszereket). Ez a széles elérhető adatkör a többi "wallet" funkcióval párosítva azt jelzi, hogy érdemes lesz az eIDAS 2.0 fejleményeire figyelnie azoknak, akik a felsorolt jogszabályokra épülő szolgáltatásokat terveznek, készítenek, üzemeltetnek, mert találhatnak új, kiaknázható lehetőségeket.
A műszaki oldalról nézve azt lehet mondani, hogy az "online" működési modell jelenleg is ismert, ott legfeljebb az interfészek, kommunikációs protokollok szintjén lesz valamennyi változás. Az "offline" működési modell támogatása az érdekes újdonság, azaz ami helyben - mobiltelefonon belül - tárolt vagy mobiltelefonnal, mint kártyaolvasóval NFC (proximity) interfészen keresztül elért adatokat, funkciókat jelent. Az adatok, attribútumok, igazolások könnyen beköltözhetnek a mobiltelefonba, mert ezeket jelenleg is jellemzően (pl. BM által) elektronikus aláírással ellátva, integritásvédetten lehet lekérdezni a közigazgatási adatbázisokból, vagy más adatforrásokról (pl. eSzemélyi okmány). A minősített elektronikus aláírás létrehozásához szükséges titkos kulcsoknál viszont továbbra is kérdéses, hogy miképp lehet őket biztonságos kulcstárolóban elhelyezni a mobiltelefonban. Természetesen, vannak SE (Secure Element), illetve TEE (Trusted Execution Environment) részek a mobiltelefonon belül is, de az ezekhez való hozzáférés egy gyártási, beállítási folyamat során (legyen az a processzort gyártó cég vagy a mobil operátor, aki a SIM kártyát perszonalizálja, konfigurálja), másokkal összehangolva (pl. kormányzati hitelesítés-szolgáltatóval, CA-val) nem annyira egyszerű (az elmúlt 20+ évben nem sikerült ez megoldani). Ezek alapján gyanítható, hogy a minősített elektronikus aláírás létrehozása továbbra is egy külön chipkártya (pl. eSzemélyi okmány) vagy tárolt kulcsos szolgáltatás (pl. Cloud-HSM) révén lesz elérhető a "wallet" modulon keresztül megszólítva.
Bár, a működési modellben valóban kevés az újdonság (az "offline" folyamat jelent újat, de az "online" folyamatot a jelenlegi eIDAS 1.0 ökoszisztéma is támogatja), azért minden alrendszer interfésze, kommunikációs protokollja, az attribútumok adatstruktúrája kapott egy csavart. Az ARF (Architecture and Reference Framework) dokumentum és az általa meghivatkozott egyéb specifikációk ábráiról leolvashatók, hogy miket kell támogatnia egy eIDAS 2.0 szerinti, Type 1 konfigurációjú "wallet" megoldásnak:- minősített elektronikus aláírás létrehozását az eddigi XAdES (XML-alapú), PAdES (PDF-alapú), CAdES (CMS-alapú) mellett támogatni kell JAdES (JSON-alapú) adatstruktúráknál is,
- felhasználó hitelesítését az eddigi, XML-alapú SAML protokoll helyett a JSON-alapú OIDC4VCI protokollal kell támogatni,
- a beazonosított felhasználóról adatok szolgáltatását az eddigi vegyes adatstruktúrák (az eIDAS 1.0 szerinti OASIS SAML Assertion-től kezdve az útlevél BM által aláírt CMS-én át a hagyományos - IETF RFC 5755 szerinti - attribútumtanúsítványig) helyett egységes, JSON-alapú vagy - az ASN.1-hez hasonló - CBOR-alapú adatstruktúrákkal oldják meg (attól függően, hogy "online" - távoli adatlekérdezéses - vagy "offline" - NFC-s kártyás adatlekérdezéses - folyamatról van szó), ez utóbbinál pedig az eSzemélyi okmány által is használt PACE, azaz kiterjesztett ECKA-DH helyett az egyszerűbb ECKA-DH protokollt használja kapcsolatfelépítéshez (a BSI TR-03111 specifikáció által leírtak közül).
A módosítások, leképezések az eIDAS 1.0 szerinti megoldásokról az eIDAS 2.0 szerinti világra nem tűnnek annyira nehéznek, de a pici változás is változás, azaz mozogni fognak az alapok, amikre építkezni lehet. Szerencsésebb lett volna, ha a visszafele való kompatibilitásra, az eIDAS 1.0 szerinti legacy rendszerekkel való együttműködésre jobban odafigyelnek, hogy a már meglevő, kiforrott megoldásokat ne kelljen mindenhol módosítani.
Érdemes külön szót ejteni a kriptográfiai rétegről. A NIST (National Institute of Standards and Technology) PQC (Post-Quantum Cryptography) - 6 év matematikai vizsgálata alapján - 2022. július 5-én bejelentette a kvantumszámítógépeknek is ellenálló algoritmusok versenyének győzteseit, amik "quantum-safe" módon tudnak adatokat pl. rejtjelezni (azaz jók lesznek a "poszt-kvantumtitkosítás" biztosítására), vagy aláírni (sértetlenséget és hitelességet biztosítani). Az ezutáni teendőkről már írtam korábban (ld. a Post-Quantum Cryptography: új Ibtv. (2013. évi L. törvény) és NIST PQC bejegyzést), a tervezett ütemezésben pedig több helyen is 2025 szerepel, amikorra szeretnék, ha a legfontosabb crypto library-kben kitesztelt módon elérhetők lennének az új algoritmusok megvalósításai (ezzel számolva pedig a legtöbb ráépülő alkalmazásnak legkésőbb 2030-2033-ig át is kellene állnia). Az eIDAS 2.0 szerinti "wallet" számára ez azt jelenti, hogy mire megjelennek az új szabványokat is támogató "wallet" megoldások, várhatóan egyből szembesülnek egy algoritmusváltási feladattal is, ami a funkciók közül a minősített elektronikus aláírás létrehozását, illetve a beazonosított felhasználóról adatok szolgáltatását érinti (mivel ez utóbbiaknál is aláírt adathalmazokról van szó).
A NIST PQC versenyre benevezett algoritmusok mintakódjai bárki számára elérhetők, de még várni kell arra, hogy pontosan mely paraméterezésekkel, illetve esetleges módosításokkal kerülnek szabványosításra. Ettől függetlenül a működések, viselkedések, erőforrásigények tesztelése miatt lehet olvasni arról híreket, hogy az OpenSSL, BearSSL, wolfSSL, libsodium/NaCl library-khez is készültek már kiegészítések, sőt, a BouncyCastle hivatalos csomagjában, a v1.72 (2022-09-25) verziót követően több lépésben - fokozatosan bevezetve - jelent meg a CRYSTALS-Dilithium és a Falcon, illetve a CRYSTALS-Kyber és a Classic McEliece támogatása. (A tapasztalatok azt mutatják, hogy mind a .NET, mind a Java keretrendszerek esetében vannak hiányosságok a kriptográfiai rétegekben, amelyek a mindennapi használatnál mégis szükségesek lehetnek. Ezeket a legegyszerűbben a Java vagy C# nyelven elérhető BouncyCastle crypto library révén lehet pótolni, ezért az ehhez kapcsolódó fejleményeket érdemes kiemelten figyelni.)
Az eIDAS 2.0 szerinti "wallet" talán legfontosabb előnye, hogy az adatgazdaságot segítheti, az adatközlekedtetési problémákra általános megoldást jelenthet. A (köz)hiteles adatokkal feltöltött űrlapokat, dokumentumokat pedig "wallet" révén el lehet látni minősített elektronikus aláírással, igaz, erre viszont az eddigi, eIDAS 1.0 szerinti - legacy - rendszerek is már képesek voltak. Az új követelmények egyetlen szépséghibája, hogy minden rétegben eltérnek picit a jelenlegiektől, ezért mozogni fognak az interfészek, kommunikációs protokollok, az attribútumok adatstruktúrái, de a cél az, hogy ez a lehető legkevésbé akadályozza a meglevő rendszerek használatát és továbbfejlesztését.
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
