AVDH megszűnik

Ha esetleg használtok bármilyen rendszerben AVDH "integrációt", akkor érdemes tudni, hogy a tervek szerint jövőre már nem lesz elérhető. 

A 2024. augusztus 31-én hatályos E-ügyintézési törvény szerinti azonosításra visszavezetett dokumentumhitelesítés-szolgáltatás használatát 2024. december 31-ig kell biztosítani.

https://jogaszvilag.hu/szakma/az-elektronikus-maganokirat-tisztaz-vagy-…

Hozzászólások

Az ügyfélkapu változása is érdekes lesz. A prezentációból:

> AVDH: elektronikus aláírási szolgáltatásként megszűnik (DHSZ megmarad!)
> Ügyfélkapu: hagyományos egyfaktoros azonosítás megszűnik

Digitális állampolgárság Idővonal

k2024 ?     - Végrehajtási rendelet megjelenik
2024.07.01. - Dáp törvény hatályba lép
2024.09.01. - Eüsztv. hatályát veszti
2024.09.01. - DÁP mobilalkalmazás, eAláírás, eAzonosítás
2024.12.31. - Ügyfélkapus azonosítás, AVDH megszűnik
2025.06.01. - Közműszolgáltatókra vonatkozó szabályok életbe lépése
2026.01.01. - ePosta, eDokumentumkezelés, eFizetés

--
Légy derűs, tégy mindent örömmel

Kicsit kapkodnak, úgy érzem.  Jelenleg az AVDH *működik*, segítségével tudok ügyet intézni, dokumentumokat beküldeni például egészségpénztárnak, a DÁP meg sehol nincs, a dap.gov.hu arra kér, hogy menjek be a kormányablakba, hogy várólistára kerülhessek.  End userként kb. nem érdekes, hogy technológiailag mekkora tákolmány az AVDH, akkor kellene kiváltani, ha már van bejáratott, működő alternatíva.

Én hiába tudok S/MIME aláírt emailt küldeni vagy akár pl. a Docusign nevű rettenetet használni, ha a fogadó oldal kifejezetten AVDH-t szeretne és más fogadására/ellenőrzésére az ottani munkaerő fel sincs készítve.  És visszakanyarodva az eredeti hozzászólásomhoz, arra próbáltam kilyukadni, hogy mivel nem elérhető még széles körben az utódjául szánt szolgáltatás, a tervezett év végi kivezetést meglehetősen korainak tartom.

Nezd meg a planoknal a feature listat, az osszes publikus csomag a “simple”t tudja csak. Ami nem szamit elektronikus alairasnak, technikai ertelemben, az az a szint amikor wordbe odairod a neved vagy beilleszted az alairasod egy kepbol.

sajat maguk is leirjak:

If ID verification is needed, an advanced or qualified electronic signature may be required

rendes megoldas csak custom/enterprise csomagban van plusz penzert

A valós digitális aláírást biztosító, auditált rendszerekben a regisztráció során történik egy személy azonosítás (sok helyen ezért kell fizikailag is bemenni) majd pedig létrehoznak egy privát kulcsot egy HSM-ben, valamint beállítják a hozzáférését a felhasználónak az adott kulcshoz (két faktorosat). Innentől a felhasználó feladata ennek a védelme mert ezek az aláírások a bíróság előtt olyannak felelnek meg, mintha 2 tanú előtt történt volna meg az aláírás. Ezért vannak rommá auditálva ezek a bizalmi szolgáltatók.  

"a minősített elektronikus aláírás a saját kezű aláírással azonos joghatású, azaz ezzel más személyek „segítsége”, tanúk, ügyvéd vagy közjegyző nélkül is létrehozható olyan dokumentum, ami teljes bizonyító erővel bír, azaz az ellenkező bizonyításáig az egész EU területén teljes bizonyító erővel bizonyítja, hogy az okirat aláírója az abban foglalt nyilatkozatot megtette, illetve elfogadta vagy magára kötelezőnek ismerte el."

https://jogaszvilag.hu/szakma/digitalis-vs-elektronikus-alairas/

Ezért kell baromira védeni a digitális aláíráshoz szükséges hozzáférést, mert bizony el lehet adni az autóját valakinek teljesen törvényesen ha nem vigyáz az azonosításhoz szükséges dolgaira.
 

Nem ez az első hülye rendelkezés a világon, de van az a lobbi ami átnyomta.
Technikai szempontból nem változik semmi: a digitális aláírás azt bizonyítja hogy XY kulcsához volt hozzáférés, nem pedig azt hogy XY aláírta.
És persze: a felhasználó hibája ha ellopják az adatait, nem a rendszer rossz.

Az AVDH valóban baromság volt úgy,ahogy itt ment: user bejelentkezett usernév/jelszó párossal, és utána kapott a dokumentumára egy stemplit, hogy az AVDH-s aláíró azonosította és ő az, akinek mondja magát. Azonosította. Akár egy usernévvel meg egy jelszóval.
Az e-személyi az ennél fényévekkel jobb megoldás (volt), mivel ott egy célhardver birtoklása, és az azon lévő érvényes(!) certhez tartozó privát kulcs feloldásához szükséges, kötelezően x számjegyből álló PIN ismerete (volt) szükséges az aláíráshoz. Ez a módszer jelenleg is működik üzleti szolgáltatásként, csak épp egy QSCD eszköz kb. nettó 20E Ft körül van, és erre még kell a megfelelő szintű tanúsítvány is (jellemzően a kártya/token cert igénylésével együtt olcsóbb), de nem ördögtől való a birtoklás+tudás alapján elkészített, teljes bizonyító erejű magánokiratot biztosító elektronikus aláírás. Mivel a telefonból a privát kulcsot ugyanúgy nem tudod kinyerni, _és_ az eID-hez megkövetelték vagy a személyes azonosítást, vagy az NFC-s e-személyis azonosítást (személyi+pin), így az aláíráshoz szükséges kulcspár/cert elkészülte és telefonba költözése sem ördögtől való.

Az AVDH az volt, mint amit a neve is elárul: Azonosításra Visszavezetett Dokumentum Hitelesítés.
Az E-személyis aláírás tényleg jobb volt, de az meg már nincsen.
A DÁP meg nem megy megfelelő okostelefon nélkül. Szóval egy számítógéppel már nem használható semmire sem.

Érdekel, hogy így januárban hogy lehet majd ügyet intézni.

Nagy Péter

Hát, pontosan ez a gondom! A Digitális Állampolgárság nevű kezdeményezés azt eredményezi, hogy amit eddig ingyen és kényelmesen el tudtam intézni számítógépről, ahhoz most vagy be kell mennem, és papíron intézni, vagy tanúsítványt kell vennem pénzért (amihez szintén személyesen kell azonosítanom magam egy tanúsítvány-kiállítónál), és azzal intézni.

Nem érzem magam tőle Digitálisabbnak. 

Nagy Péter

És persze itt is felmerül az a kérdés, hogy ha a fogadó fél kifejezetten DÁP aláírást vár el, akkor kitörölheted a seggedet a digitális tanusítványoddal a _valamelyik_ kiadó cégtől.

Nem kell emlékeztetnem senkit ugyebár, hogy itthon még mindig csak a Netlock számít sok helyen elismert hitelesítésszolgáltatónak _kizárólag_.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Az egészben a legviccesebb, hogy az AVDH megszűnésének pillanattától pont előírták, hogy az ügyfélkapu eléréséhez kötelező a két faktoros ügyfélkapu+, vagy a DÁP használata. (az e-személyi-s bejelentkezést pedig attól a pillanattól vezetik ki éppen)

Nagy Péter

1 faktoros authentikacioval, Juliska123! jelszó mellett egyébként is megkerdojelezheto a hitelesség. 

Error: nmcli terminated by signal Félbeszakítás (2)

Erre _sem_ lett volna szabad használni, mivel egy usernév/jelszó párossal teljes egészében megszemélyesíthető az adott állampolgár úgy, hogy annak, amit így tesz a támadó az adott polgár viseli az összes jogkövetkezményét - de elég, ha az összes adatát, ami üf.kapun keresztül elérhető leszipkázzák...

Mondjuk úgy, hogy az qrvarégen volt, hogy a usernév/jelszó elégségesnek tekinthető volt - az igazi gond a 2FA kiterjesztésével/kötelezővé tételével az volt, hogy az n+1 ügyfélkapu alá integrált rendszerben nem voltak képesek mindenütt megvalósítani az ügyfélkapu+ kompatibilis működést...

Nem jól érted. Korábban nekem a Lechner tudásközpontnál lévő szolgáltatásokhoz nem működött az ügyfélkapu+ (az érdeklődésemre válaszul azt írták, hogy dolgoznak rajta - legalább fél évvel voltunk az ügyfékapu+ bevezetése/élesítése után egyébként...) de tippre azért bátorkodnak betervezni a 2FA kötelezővé tételét (vagy ugye az e-személyis logint), mert addigra minden érintett/kapcsolódó rendszer képes lesz ezt kezelni.
 

Az faca, egy durva nagy visszalépés, mert ugye ToTP-t kávédarálón is lehet futtatni minden biztonsági körítés nélkül, egy hardvertokenes cert alapú login ennél sokkal biztonságosabb, hiszen a birtoklás az egy és csak egy eszközhöz köti a logint, nem egy szoftveresen simán másolhatóhoz. (Kereshetem elő a üfkapu+ usernév/jelszó párost - szerencsére a GA-ban minimum két telefonon ott van a 2. faktorhoz a secret...)
 

Az ügyfélkapu+ jelenleg is GA-val vagy MS Authenticator-ral, szabványos TOTP-vel működik, mindkettő képes a kódokat (azaz azokat a shared secret-eket, ami alapján generálható az idő alapú kód) google, illetve microsoft fiókba menteni... És onnan sima liba kihúzni egy másik eszközre az összeset egyben, de GA-ból egy saját formátumú QR-kóddal is átvihető egy másik GA instance-ba. Ez lesz ahelyett, hogy egy kizárólag egy példányben létező hardvertokenen tárolt, onnan ki nem nyerhető kulcsot használna azonosításra az ügyfélkapu... (hogy ez e-személyi, vagy valamilyen más, X509-es certet használó megoldás, jelen esetben mindegy.)
 

Annyit még hozzátennék, hogy TOTP-t pl. KeePass is tud kezelni (pluginnal még jobban), és a GA-ból a QR kóddal exportált tokeneket a KeePass alá is be lehet olvasni (vagy fordítva is, lehet exportálni is). A KeePass pedig utána kiír minden secretet, ami csak érdekel, akár QR kódot is mutat hozzá.

Nagy Péter

A tokennel az a baj, hogy ahhoz minimum driver kell a géphez, és telefonról például mérsékelten lesz üzemképes, mert nem tudod hova bedugni, stb.

Sajnos hiába az a legbiztonságosabb megoldás, az r=0.5 felhasználókkal inkompatibilis. Még a TOTP azonosítás is rengeteg helyen billeg, nagyon komoly mennyiségű felhasználó támogatás fog kelleni a használatához, de azt jelenleg beláthatóbbnak gondolom (mert jobban el is van terjedve) mint egy token alapú cuccot.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Az e-személyi tökéletes eszköz lett volna, ahogy az eID-re történő, qrmányablakba befáradás nélküli regisztrálás is működik. Vagy ahogy az eszemélyihez készült app is, ami egy sima kártyaolvasót csinál a telefonból, amivel az eszig PC-s alkalmazás hálózaton beszélget...

 

Az okostelefonbuzi mivolta miatt, a Google/Apple-függősége miatt és amiatt, mert jól működő okostelefonok százezreit kell kidobálni, az Android 10 és iOS 16 minimum OS-követelményeknek köszönhetően. Mindeközben biometrikus azonosítás már Android 5.0-án is van.

Nem a biometrikus azonosítás hiánya a probléma, hanem az, hogy a régi android-okban rengeteg olyan hiba, sérülékenység van,a mit de facto már nem fognak javítani. Egy security device lukas, gyártói supporttal nem rendelkező szoftverrel nem security device, hanem e-hulladék, akár tetszik, akár nem. Nem kell a régi telefont kidobni, csak épp biztonsági eszköznek, illetve elektronikus okmánynak nem lehet azokat használni.
 

Nem kell a régi telefont kidobni, csak épp biztonsági eszköznek, illetve elektronikus okmánynak nem lehet azokat használni.

Lehet őket használni, biztonságtudatosan, pont úgy, mint egy Windows XP-t, a támadási felületeket minimalizálva. iOS esetben pedig nem is igaz, amit írsz, mert biztonsági javításokat szokott kapni.

Szerkesztve: 2024. 09. 01., v – 20:02

Aki pedig nem rendelkezik kétévente újravásárolt okostelefonnal, az visszatérhet a papíralapú ügyintézéshez, aláíráshoz, ugyanis már induláskor Android 11 az igénye az IdomSoft Zrt. babzsákfejlesztői által összetákolt Digitális Állampolgár csinálmánynak.

Ismét jól működő rendszerek tönkretételével akarunk fejlődni™.

AVDH egy csökevény volt

Ezt nem vitatja senki.

Az új megoldással el fogom tudni intézni az állami (egészségpénztári, stb) dolgaimat a desktop Fedorámról vagy hozzáköt valami szűk platformhoz, mert csak? Ha hozzáköt, akkor per definition funkciót vesztek el, ami zavar. 

Az appot nem én fejlesztem, de ahogy sejtem a telefont fogja használni aláíró eszközként (mint szinte minden ilyen). Ami teljesen rendben van. Nem hinném, hogy a te desktopodat fel kellene adnod emiatt, csak épp kell egy (meglévő) eszköz majd az aláírás elfogadására. Ha nem így csinálják meg, akkor Viktornál panaszkodj. 

Van ügyfélkapud? Van. Abból tessék ügyfékapu+ -ra váltani. Mivel a QR-kód tartalma jól definiált,a mit a 2FA beállításához kapsz, azzal akár egy konzolos totp-alpkalmazást is meg tudsz etetni, és onnantól kezdve készen is vagy.

Egyébként meg lehet venni kártyaolvasót nem túl súlyos pénzekért, és azzal, meg az e-személyiddel (és a megfelelő alkalmazással) alá tudsz írni, be tudsz jelentkezni az ügyfélkapu-n.

Hogy egy rolling disztribúcióban ezek mennyire működőképesek, azt nem tudom, de a szolgáltatásokat jellemzően a felhasználói bázis eloszlása alapján a nagy többségre alakítják ki.

Van ügyfélkapud? Van. Abból tessék ügyfékapu+ -ra váltani.

what? Ez hogy jön ahhoz, hogy kivezetik az AVDH-t, és, ha jól értem a szálat, a helyette jövő DÁP nem lesz elérhető desktopon?

(régesrég 2FA-s az ügyfélkapum, ne is beszéljünk róla, mekkora szar megvalósításban)

Szerintem Polgárjenő vagy ASP-s iktatórendszerrel ír alá (az is ilyen AVDH szerű hozzácsapja PDF-be mellékletként ki írta alá, majd a rendszer aláírja), vagy a NISZ-es GOVCA-s PKI-s mókolással, hisz az esziges aláírásából nemigazán derül ki, hogy ő polgármesterként írta alá. 

A cikkből:

... januártól már csak e-aláírással lehet ügyvédi meghatalmazást adni az ingatlanos ügyintézésekhez. Az eSzemélyihez kapcsolt aláírás azonban a lakosság 98 százalékánál nincs meg, és az AVDH sem lesz már használható ...

Az ütemtervük szerint a DÁP mobilalkalmazás, eAláírás, eAzonosítás 09.01-től elérhető és úgy néz ki január 1-től megkerülhetetlen. Mintha most lenne teszt üzem jövőre pedig éles üzem...
--
Légy derűs, tégy mindent örömmel!

Azért jó az AVDH, mert működik, platform-független és tetszőleges dokumentum aláírható vele. Emellett PDF-be is képes beágyazni az aláírást. Ha a Digitális Állampolgárság fronton is születik egy ilyen megoldás, akkor az is megfelelő lesz az AVDH helyett. Ha nem születik, akkor az visszalépés lesz az AVDH-hoz képest, akkor is, ha az AVDH most egyesek szerint nem tökéletes.

1. Irreleváns, amennyiben magyarországi ügyintézésről van szó.

2. A felhasználó és a rendszer által van aláírva, pontosabban a rendszer által, a felhasználó nevében.

3. Semmivel sem szarabb, mint egy okostelefonos szutyok, ami még a kétfaktoros hitelesítés koncepcióját sem teljesíti, ha minden az okostelefonon történik.

és milyen igazad van. Nem ettől. Hanem ettől lesz igazam:

2. A felhasználó és a rendszer által van aláírva, pontosabban a rendszer által, a felhasználó nevében.

Ez mi? Érted mi az az elektronikus aláírás? Vagy csak megerősíted, hogy igazam van és ilyen formában helyeselsz?

3. Semmivel sem szarabb, mint egy okostelefonos szutyok, ami még a kétfaktoros hitelesítés koncepcióját sem teljesíti, ha minden az okostelefonon történik.

Miről beszélsz? Tudod hogy fog működni?

Ez mi? Érted mi az az elektronikus aláírás? Vagy csak megerősíted, hogy igazam van és ilyen formában helyeselsz?

Te érted, hogy az elektronikus aláírás mitől lesz hiteles? Nem attól, hogy én generálok egy random kulcsot és azzal aláírok valamit. Hanem attól, hogy azt a Belügyminisztérium is hitelesnek ismeri el és ez a hitelesség bármikor ellenőrizhető. Ha az aláírás az én gépemen történik, nem az Ügyfélkapu szerverein, ugyanúgy szükségem van hitelesített kulcsra, amit a Belügyminisztérium is hitelesnek tekint. Ezt felfogod? Ha igen, akkor innentől már csak egy lépésre van az, hogy kb. mindegy, kinek a gépén történik az aláírás. A lényeg, hogy kinek a megbízásából.

Miről beszélsz? Tudod hogy fog működni?

Pontosan úgy, ahogy az összes többi "kétfaktoros" app, ami megelégszik azzal, hogy az egyik faktor az okostelefon, meg a másik faktor is az okostelefon.

Tehát, nem, megint nincs igazad, csak igyekszel erőltetni a csőlátásod azzal, hogy másokat leminősítgetsz.

Nem érted a pki "lényegét" és ilyen "apróságokat" elfelejtesz, hogy mindketten egy harmadik (megbízható) entitásban - a tanúsítóban bíztok meg - ill. hogy a privát kulcsod a te birtokodban van jó esetben egy biztonságos tároló eszközön és azt nem hagyja el soha, ezért más a te "nevedben" aláírást nem tud készíteni.

Az állam megengedte magának hogy bízzon benned (meg te is benne), hogy helyetted készít aláírást - ha előzőleg azonosított elégséges módon. Ennek viszonylag kevés köze van ahhoz, hogy technikailag mi lenne a megbízható vagy hol kéne még a világban megbízható aláírást készíteni tudni.

(Ha jól tudom személyit is lehet úgy pótolni, hogy nem változik a privát kulcsod... Az kit zavar? ;) )

Nem szükséges. Nem fog lerohadni a lábam, ha be kell mennem a kormányablakhoz személyesen, ügyet intézni.

Inkább sajnáld azt az Isten tudja mennyi okostelefont, amit emiatt fognak újravásárolni, kidobni.

Sajnáld a privát szféráját azoknak, akiknek ezentúl muszáj lesz eladniuk a lelküket minimum az Apple-nek vagy a Google-nek, hogy élhessenek a Digitális Állampolgárság lehetőségével.

Nem kell semmit sem kidobni. Az e-személyihez kell egy megfelelő kártyaolvasó, amit akár az eSzemélyiM alkalmazással is ki lehet váltani, ha minden igaz.

Az, hogy a személyazonosításra használt okmány vagy elektronikus eszköz milyen biztonsági feltételeket kell, hogy teljesítsen, azt szerencsére nem te határozod meg - ha nem tetszik, nincs megfelelő eszközöd, akkor nem kell használni.

Az, hogy a személyazonosításra használt okmány vagy elektronikus eszköz milyen biztonsági feltételeket kell, hogy teljesítsen, azt szerencsére nem te határozod meg - ha nem tetszik, nincs megfelelő eszközöd, akkor nem kell használni.

  1. Biometrikus azonosítás már Android 5.0-án is van. Nem biztonságról beszélünk itt, hanem az IdomSoft babzsákfejlesztők kényelmeskedéséről.
  2. Egy eszköz annyira biztonságos, amennyire a felhasználója biztonságtudatos.
  3. Nem azzal szokott probléma lenni, hogy egy alkalmazás megkövetel bizonyos biztonsági feltételeket, saját magára nézve. Azzal van, amikor a felhasználói szabadságot tiporja sárba azzal, hogy márpedig mindenhez is, az okostelefonon globálisan szükség™ van™ ujjlenyomattal nyitható lock screen-re, nem csak magához az alkalmazáshoz, ahogy egyébként értelmes és logikus lenne.

Már a 6-os android, mint minimum (API level 23) is warning-ot generál a google store-ba töltött alkalmazásnál, és a tervek szerint hamarosan a "nem frissíthető" kategóriába kerülnek azok az alkalmazások, amik ezt a minimumot adják meg. Ami meg ennél régebbi minimumot igényel, az már most sem megy át a Google élesítési validáción. Szóval hiába is akartak volna 21 vagy 22 API-szintet adni minimumnak, a Google nem fogadta volna be az alkalmazást.

"Egy eszköz annyira biztonságos, amennyire a felhasználója biztonságtudatos."

Ha hálózat felől, alkalmazásokon keresztül törhető, akkor nem adok neki hálózatot soha, mert biztonságtudatos vagyok... Csak épp jelen esetben pont kell neki hálózat...

Az eszköz feloldása és az alkalmazáson belüli azonosítás nagyon nem ugyanaz a réteg, nem ugyanaz a funkció. Használsz jelszót a windows-on? Minek, mikor az összes webes alkalmazásban, amit nyomogatsz róla, van jelszó...
 

Szóval hiába is akartak volna 21 vagy 22 API-szintet adni minimumnak, a Google nem fogadta volna be az alkalmazást.

Akkor lehetett volna Android 7 a minimum.

Az eszköz feloldása és az alkalmazáson belüli azonosítás nagyon nem ugyanaz a réteg, nem ugyanaz a funkció.

Én is ugyanezt mondtam. Az ilyen biztonságos™ alkalmazások mégis kikényszerítik, hogy legyen lock screen.

Captain Obvious Stirkes Again.

Attól, hogy értelmező szótárt játszol, még nem lesz szükséges a lock screen egy olyan alkalmazásnak, amit lehetne egymagában is védeni ujjlenyomat bekérésével úgy, hogy a többi appot békénhagyjuk (a felhasználó belátására bízzuk) az által, hogy nem rakunk kötelezően lock screen-t.

Nem kell ilyen appot mutatnom, ugyanis számtalan olyan app van, ami a kritikusabb műveletek elvégzése előtt is kérnek azonosítást, pl. Apple FaceID-t. Ilyen alapon nyugodtan lehetne bekérni az ujjlenyomatot az e-személyi appban.

Nem beszélve arról, hogy a lock screen-nek is van timeoutja, tehát ha a felhasználó nem zárja le a telefonját, az ugyanaz a kategória, mint amikor nem lép ki a NetBankból, vagy nem zárja be az ujjlenyomattal indított e-személyi appot.

Valaki esetleg használja az eszemélyi-s ügyfélkapu belépést linux alatt? Neten nem sok infót találtam róla...

Persze, de azért mondjuk egy parancssoros TOTP referenciaimplementációval nem biztos, hogy egyszerű lesz :-) És itt is van a hátulütője, illetve a visszalépés a hardvertokenes (e-személyi) azonosításhoz képest: az azonosításra szolgáló eszköz illetve információ tetszőleges számban észrevétlenül másolható, ellopható.

Naszoval. Ugyfelkapu+ igenylese soran ott a QR kod, de el lehet kerni tole a TOTP secretet is. Ez mehet az oathtool-nak, es boldogsag.

Igy nem kell mindenfelet jottment telefonos auth applikaciora bizni a titkaimat. Mehet a kod egy jelszo adatmazisba, AES256 titkositott fileba, szep sarga Post-it papirosra a monitor szelere stb.

Nagyon nem tudja arrafelé senki, hogy hogy működik ez...? Mert nekem kifejezetten úgy tűnik... A TOTP esetén a secret (gy.k. "titok") az ott van mindkét oldalon, és abból meg a pontos időből készül publikus algoritmussal egy numerikus kód. Ha a secret-et elviszi valaki, akkor onnantól kezdve b/6-ja a 2FA-t, mert aki elvitte, az is tud 2. faktorhoz kódot generálni...

 

Én is ezt mondom, hogy ez egy olyan előrelépés, ami hátrafelé történik... Ennél még az e-személyin lévő cert alapján történő login is jobb lenne... És az sem egy űrtechnolóia...

Én a "sima" ügyfélkapuróla hogy kitolták az ügyfélkapu+ -t, váltottam, illetve amikor az első e-személyit megkapta, akkor vettem egy kártyaolvasót, és inkább azt használtam bejelentkezésre - mert a három közül azt tartom a leginkább biztonságosnak. Erre most vissza..asznak a usernév-jelszó-tetszőlegesen sokszorosítható TOTP használatára, mert az e-személyis fejlesztésből... már nem lehet több gempát kiszedni...
Mondjuk ha az eID-s azonosítás úgy fog működni, hogy qr-kód, amit az eID beolvas, és másik csatornán beküldi, hogy "oké, mehet", akkor az jó is lehet - csak ugye ehhez média, illetve kamera jog kell az alkalmazásnak...

"Mondjuk ha az eID-s azonosítás úgy fog működni, hogy qr-kód, amit az eID beolvas, és másik csatornán beküldi, hogy "oké, mehet", akkor az jó is lehet - csak ugye ehhez média, illetve kamera jog kell az alkalmazásnak..."

ez nem olyan, mint az otp qr kodos belepese?

neked aztan fura humorod van...

Egyébként is tönkreteszi valid pdf/A3 -at:
verapdf avdhA3-ff846980-c6b4-48b6-8f55-62b479775289.pdf

<?xml version="1.0" encoding="utf-8"?>
<report>
  <buildInformation>
    <releaseDetails id="core" version="1.26.1" buildDate="2024-05-16T16:30:00+02:00"></releaseDetails>
    <releaseDetails id="validation-model" version="1.26.1" buildDate="2024-05-16T18:13:00+02:00"></releaseDetails>
    <releaseDetails id="gui" version="1.26.2" buildDate="2024-05-19T13:33:00+02:00"></releaseDetails>
  </buildInformation>
  <jobs>
    <job>
      <item size="1206764">
        <name>/home/zolti/Downloads/avdhA3-ff846980-c6b4-48b6-8f55-62b479775289.pdf</name>
      </item>
      <validationReport jobEndStatus="normal" profileName="PDF/A-3B validation profile" statement="PDF file is not compliant with Validation Profile requirements." isCompliant="false">
        <details passedRules="141" failedRules="4" passedChecks="7020" failedChecks="9">
          <rule specification="ISO 19005-3:2012" clause="6.8" testNumber="3" status="failed" failedChecks="2">
            <description>The file specification dictionary shall contain key AFRelationship of type Name identifying the relationship between the embedded file and the content of the document</description>
            <object>CosFileSpecification</object>
            <test>AFRelationship != null</test>
            <check status="failed">
              <context>root/EmbeddedFiles[0]</context>
              <errorMessage>The file specification dictionary for an embedded file does not contain the AFRelationship key or it has invalid value type</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]</context>
              <errorMessage>The file specification dictionary for an embedded file does not contain the AFRelationship key or it has invalid value type</errorMessage>
            </check>
          </rule>
          <rule specification="ISO 19005-3:2012" clause="6.8" testNumber="4" status="failed" failedChecks="2">
            <description>The additional information provided for associated files as well as the usage requirements for associated files indicate the relationship between the embedded file and the PDF document or the part of the PDF document with which it is associated</description>
            <object>CosFileSpecification</object>
            <test>isAssociatedFile == true</test>
            <check status="failed">
              <context>root/EmbeddedFiles[0]</context>
              <errorMessage>The file specification dictionary for an embedded file is not associated with the PDF document or any of its parts</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]</context>
              <errorMessage>The file specification dictionary for an embedded file is not associated with the PDF document or any of its parts</errorMessage>
            </check>
          </rule>
          <rule specification="ISO 19005-3:2012" clause="6.8" testNumber="1" status="failed" failedChecks="4">
            <description>The MIME type of an embedded file, or a subset of a file, shall be specified using the Subtype key of the file specification dictionary. If the MIME type is not known, the "application/octet-stream" shall be used</description>
            <object>EmbeddedFile</object>
            <test>Subtype != null &amp;&amp; /^[-\w+\.]+\/[-\w+\.]+$/.test(Subtype)</test>
            <check status="failed">
              <context>root/EmbeddedFiles[0]/EF[0]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
            <check status="failed">
              <context>root/EmbeddedFiles[0]/EF[1]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]/EF[0]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
            <check status="failed">
              <context>root/indirectObjects[71](63 0)/directObject[0]/EF[1]</context>
              <errorMessage>MIME type null of an embedded file is missing or invalid</errorMessage>
            </check>
          </rule>
          <rule specification="ISO 19005-3:2012" clause="6.2.11.4.2" testNumber="2" status="failed" failedChecks="1">
            <description>If the FontDescriptor dictionary of an embedded CID font contains a CIDSet stream, then it shall identify all CIDs which are present in the font program, regardless of whether a CID in the font is referenced or used by the PDF or not</description>
            <object>PDCIDFont</object>
            <test>fontFile_size == 0 || fontName.search(/[A-Z]{6}\+/) != 0 || containsCIDSet == false || cidSetListsAllGlyphs == true</test>
            <check status="failed">
              <context>root/document[0]/pages[0](4 0 obj PDPage)/annots[0](85 0 obj PDWidgetAnnot)/appearance[0]/contentStream[0](81 0 obj PDContentStream)/operators[2]/xObject[0]/contentStream[0](78 0 obj PDContentStream)/operators[6]/xObject[0]/contentStream[0](74 0 obj PDContentStream)/operators[4]/font[0](AAAAAB+Roboto-Regular)/DescendantFonts[0](AAAAAB+Roboto-Regular)</context>
              <errorMessage>A CIDSet entry in the Font descriptor does not correctly identify all glyphs present in the embedded font subset</errorMessage>
            </check>
          </rule>
        </details>
      </validationReport>
      <duration start="1725721286833" finish="1725721287583">00:00:00.750</duration>
    </job>
  </jobs>
  <batchSummary totalJobs="1" failedToParse="0" encrypted="0" outOfMemory="0" veraExceptions="0">
    <validationReports compliant="0" nonCompliant="1" failedJobs="0">1</validationReports>
    <featureReports failedJobs="0">0</featureReports>
    <repairReports failedJobs="0">0</repairReports>
    <duration start="1725721286756" finish="1725721287608">00:00:00.852</duration>
  </batchSummary>
</report>
Szerkesztve: 2024. 10. 04., p – 12:21

Az egész eIDAS találmány egy katasztrófa (mivel a gyakorlatban drága és körülményes, nincsen elég szolgáltató megfizethető áron és platformfüggetlenül, aki megfelel az eIDAS-nak), csak akkor használjon valaki elektronikus aláírást, ha kötelező, egyébként jobb a papír alapú. Amit sokan elfelejtenek, hogy nem elég valamit elektronikusan aláírni, hanem azt utána elektronikusan archiválni is kell, minősített elektronikus archiváló szolgáltatással, különben idővel lehetséges, hogy a már aláírt dokumentum elveszíti a hitelességét.

Gyakorlatilag 2 db ilyen archiváló szolgáltató van, ebből az egyik a Netlock volt amit éppen most szüntette meg teljesen az elektronikus archiválást! Nem viccelek. Elektronikus aláírást adnak, de az archiválást már oldd meg, ahogy tudod... Van a Microsec archiválás és nagyjából ennyi, mást nem is tudok.

Nem, az archiválás nem azt jelenti, hogy fellövöm felhőbe, ennél sokkal bonyolultabb.

Akkor tudna terjedni az elektronikus aláírás, ha az állam biztosítana legalább magánszemélyeknek ingyenes elektronikus aláírást, időbélyeget ÉS minősített elektronikus archiválást is, ami mind eIDAS-kompatibilis lenne, ez tudná kiváltani a papír alapú ügyintézést. Az archiválás hiányában én semmit sem írnék alá elektronikusan, hiszen idővel a már aláírt dokumentum elveszítheti a hitelességét, és akkor olyan mintha nem is létezne. Csak az archiválás biztosítja hogy hosszú távon is megőrzi a dokumentum a hitelességét, de amíg az állam nem ad ilyet ingyen, addig sokkal jobb papír alapon aláírni. (Most magánszemélyként / kkv-ként értem, nyilván ha naponta keletkezik több ezer aláírandó dokumentum, az más kategória.)

Az eIDAS egy nagyon erős szabályozás, mert egy minősített elektronikus aláírással aláírt dokumentum teljes bizonyító erővel bír. Ez egy nagyon nagyon erős vélelem, és ezért nagyon magas szintre van rakva a biztonság: egy tanúsítványkiadó cégnek elképesztően sok szabályozásnak kell megfelelni mind IT biztonság, mind folyamatok szintjén, ráadásul folyamatosan auditálják őket, mind a szoftvereket mind pedig a működést/folyamatokat. Ez egy nagyon nehéz domain, folyamatosan tanulni és képezni kell a dolgozókat mert csak igy tartható fenn egy bizalmi szolgáltató működése. Az eszközök pedig folyamatosan avulnak, a szoftvereket pedig fejleszteni kell.

Ehhez képest valójában nem drága, havi durván 5 ezer forint + áfa körül van mindkét cégnél egy minősített tanúsítvány, cserébe az irodádból el tudsz mindent intézni. Hogy ez valakinek megéri-e, vagy sem, ez egy jó kérdés, ki kell számolni.

Az archiválást valószínűleg azért szüntette meg a Netlock mert amennyibe az valójában kerülne, annyit nem hajlandó érte senki fizetni, a felülbélyegzés egyébként még csak-csak megoldható, de a végtelen ideig tárolás úgy, hogy az tutira meglegyen... hát, nem egyszerű. Egyébként van olyan cég, amely ad is erre megoldást:

https://www.digitdoc.hu/megoldasaink/hosszu-tavu-archivalas

Archiválásra egyébként 5+ illetve 11+ év esetén érdekes, a legtöbb kézzel aláírt dokumentumot valójában már 5 év után selejtezik.

Az elektronikus aláírással alapvetően szerintem nincs gond, ha bejön ez az új mobilos megoldás azzal egy átlag ember a használati eseteinek a 95%-át le tudja fedni, a maradék 5% esetén pedig majd szépen kézzel aláír, a cégeknek meg letöbbször tömeges aláírásra van szükség, azt pedig most is megoldják.

 

De az milyen már hogy elektronikus aláírás archiválási szolgáltatás nélkül? Pont ez a baj az elektronikus aláírással, hogy kell mellé archiválás is, az meg te is írod olyan bonyolult és drága, hogy nem akar vele senki bajlódni. Tehát a gyakorlatban jelenleg az eIDAS nemigazán működik. Kellene sokkal több cég aki kínál megfizethető áron elektronikus aláírást, időbélyeget ÉS archiválást egyszerre, vagy ha ez nem megy, akkor az állam adjon ingyen, hogy terjedjen a digitalizáció. El tudom képzelni hogy megérné, ha az állam adná ingyen mindenkinek, ha ezzel nőne a GDP (pl. sok időt spórolna mindenki amit produktív, termelő munkára fordíthatna).

Érdekes lenne megnézni, hogy az USA-ban hogy működik ez ez elektronikus aláírás dolog, valahogy csak eldöcögnek ott milliárd dolláros cégek.

De érted, az a baj, hogy a magyar piac csórókból áll, itt még az is meglepő hogy van egyáltalán két épkézláb cég amely digitális aláírással foglalkozik, eiDAS-t rendesen betartva (jó, három, mert ott a NISZ is). Mindenki azt hiszi hogy ez mekkora egy atom biznisz, pedig valójában nem, mint valaki, aki azért pár évet lehúzott ebben az iparban, biztos hogy eszem ágában nem lenne ilyen céget csinálni, lényegében bármilyen másik céget csinálok akkor nagyságrenddel kevesebb szívással sokkal de sokkal több pénzt lehetne keresni.

Igen, ideális esetben a magyar állam adna mindent is, valójában meg a mobilos aláírásos megoldás szerintem bőven jó lesz a legtöbb embernek. Nem fognak azzal foglalkozni hogy dokumentumokat archiválgassanak, főleg most, hogy már mindenki átállt ECC-re, annyi ideig meg a legtöbb dokumentumra nincs szükség hogy felül kelljen hitelesíteni, vagy esetleg biztonságosan elarchiválni.

De az egész EU-ban nem nagyon van épkézláb szolgáltató, ez a baj. Lehetne legalább egy cég aki az egész EU-t kiszolgálja, többnyelven, platformfüggetlenül, megfizethető áron. A múltkor ahogy néztem, nem találtam ilyet. Elektronikus archiválásra kértem ajánlatot külföldi cégektől és horror árakat mondtak. Valamiért az egész EU-ban nem nagyon megy ez az eIDAS dolog, ezért kellene akkor a tagállamoknak mögé tenniük ingyenes állami infrastruktúrát, mert eddig a magánszektor nem látott benne fantáziát, pedig a digitalizáció nagyon fontos lenne az egész EU-ban.

Egy jó és megbízható minősített elektronikus archiváló rendszer drága. Mind hardveresen, mind szoftveresen. Csak a hardver (CAS) 100+ millió Ft-nál kezdődik. Pl: Dell EMC Centera - nem tudom, hogy most mi a pontos utódja a Dell EMC-nél, ha van egyáltalán; talán az ECS vagy az ObjectScale.
Persze, össze lehet tákolni / rakni Garázs Bt. módon is - csak az nem egy enterprise megoldás, amire komoly üzletet is lehet építeni.

Ami nagyon érdekes lesz a DÁP aláírásnál, hogy mekkora értékhatárig van biztosítva / szolgáltatói felelősségvállalás mértéke. Ha csak 5-10 millió Ft, akkor azzal még egy új autó vásárlási szerződést is nehéz lesz aláírni. Ráadásul csak magánszemélyként érvényes. Nem hiszem, hogy mondjuk egy cégvezető vagy egyéni vállalkozó használhatná a DÁP-ot aláírásra.
Ez idővel úgyis kiderül.

Amikor elolvasom az ilyen rant-et az első pár mondatból mindig kijön, hogy orbitális információhiány van vagy bias. eIDAS nem kizárólag (és specifikusan nem) csak elektronikus aláírásról szól.
Másrészről elég sok nemzeti szolgáltató van, több köztük ingyenesen biztosít eIDAS kompatibilis XAdES/PAdES aláírást amit borzasztóan könnyű. Sok közül külföldi személyek számára is elérhető. 
Az elektronikus aláírásban azért van timestamp, hogy vizsgálható legyen, hogy az adott időpontban valid volt e az aláírás. Így az aláírás érvényességének elvesztése ne érintse a dokumentum valid voltát. (ide véve az e-seal-t is)

Nem Magyarország specifikus, de az embereknek idegen ez és nem eléggé elterjedt. Az ezt támogató eljárások pont a normál EU direktívák implementálása okán abba a ciklusba érnek mint pl. Magyarországon a DÁP által (jövőben) elvégezhető aláírás.  Sajnos ezt akadályozzák az olyan tényezők, hogy a magyar kormánynak jelenleg a hatalom megőrzés fontosabb ezért a lopás előbbre való, ezért is nincsenek kész ezek a dolgok időben, nem csak az elterjedtség miatt.