Podpisovanie cez mobilne riesenie DCOM

Že ide o autorizáciu klikom je stanovisko DEÚS, nie moje. Prezentované naposledy na workshope na MIRRI cez prázdniny. Vrátane technických detailov ktoré tu popisujem.
Budem iba rád, ak si tu svoje riešenie začnú vysvetľovať sami.
Potvrdzujem že prezentované riešenie považujem za dobré, ale ja by som tam napr. nemiešal elektronický podpis žiadny. Btw. aj riešenie ktoré prezentoval Nases má robiť autorizáciu klikom.

Nerozumiem otázke, v čom je problém?

Toto nemusí mať nič spoločné s ÚPVS. Aj formálne, “elektronická správa” je definovaná v §3.e z.305/2013 (iba) takto: “[Na účely tohto zákona sa rozumie] elektronickou správou logicky usporiadaný celok údajov obsahujúci identifikáciu odosielateľa a adresáta”. Skrátka v tej elektronickej správe (na jej štruktúru nie sú na ňu zákonom/vyhláškou kladené ďalšie špeciálne požiadavky), ktorá zachytáva realizáciu podania, zaznačím kto je odosielateľ. No-brainer. Potom túto správu pošlem na ÚPVS do schránky používateľa, vhodne zabalenú “Používateľ X vykonal nasledovné podanie:…”. To píšem všeobecne, detaily riešenia DEÚS nepoznám.
Už dnes však viaceré systémy de-lege používajúce autorizáciu klikom toto v nejakej insitnej forme robia (to nie je urážka ale odkaz na to že boli implementované ešte pred prijatím pravidiel o autorizácii klikom), povedzme žiadosť o výpis z RPO, kde do schránky na ÚPVS príde skutočne správa kde používateľ je označený ako odosielateľ. Určite to nie je tak že “pristupujú do mojej schránky”, ako sa to pomocou API ÚPVS spraví neviem.

Na túto tému som sa pýtal, žiadne ďalšie konkrétnosti/dokumenty k tomu som nedostal.

Za základ považujem overenie súladu s požiadavkami na úroveň identifikácie “pokročilá” podľa eIDAS, resp. na úroveň autentifikácie 3 podľa SK štandardov. Nechápem prečo CSIRT tento pohľad vôbec neriešil (dokonca je možné že o tých požiadavkách ani nevedeli).

1 Like

Metóda SaveToOutbox v edesk na upvs. Žiadna veľká veda.

Ja by som to ani nedal SaveToOutbox, ale informatívna správa od príslušného úradu. T.j. odosielateľ príslušný úrad, uložené klasicky mne do schránky.

Wow.

Úprimne, som prekvapený.

Bohužiaľ v tom negatívnom zmysle.

Takže sa vychádza z tvrdenia, že to mal byť údajne zdokonalený podpis podľa eIDAS, potom to nie je elektronický podpis, ale autorizácia “klikom”, pričom táto využíva koncept elektronického podpisu? Zaujímavé.

Je asi potrebné sa vrátiť ku dôvodovej správe k novelizácii zákona č. 305/2013, ktorým sa zavádza inštitút autorizácie “klikom”:

"K bodom 36 až 38 (§ 23)
Zmeny v ustanoveniach o autorizácii sú dvojakého charakteru. Hlavnou zmenou je možnosť autorizovať podanie („podpisovať“) aj s použitím funkcionality prístupového miesta, bez nutnosti využiť elektronický podpis. Ide o spôsob, ktorý sa dnes používa napríklad na potvrdzovanie prijatia správ v elektronickej schránke a rozširuje sa aj v osobitných konaniach ako alternatíva k „bežnému podpisovaniu“. Vzhľadom na to, že identita osoby je v danom prípade preukázaná prostredníctvom autentifikátora (dnes najmä občianskeho preukazu) a nie je sporná, je predpoklad, že takýto spôsob autorizácie sprístupní využívanie elektronických služieb aj pre osoby, ktoré z rôznych dôvodov nedisponujú elektronickým podpisom. Navyše, touto zmenou sa dosiahne aj to, že postačí aj občiansky preukaz s elektronickým čipom a osoba bude môcť cez ústredný portál verejnej správy využívať elektronické služby v plnom rozsahu, bez potreby obstarávania ďalších technických, či programových prostriedkov. "

Priblížme si to: ak je to klik, malo by ísť o funkciu prístupového miesta - výhradne (pokiaľ viem tu sa vytvára podpis s kryptomateriálom na telefóne). V žiadnom prípade by sa nemal využívať elektronický podpis resp. jeho koncept pri tomto type autorizácie. Predpokladám, že ak je riešenie postavené na báze AC, potom je vysoko pravdepodobné, že napĺňa definíciu AdES podľa eIDAS - už bola spomenutá iným diskutujúcim vyššie (a na začiatku dodávateľ tvrdil, že ide o AdES). Pripomínam tiež, že elektronický podpis môže používať výlučne iba fyzická osoba (nemôže sa teda jednať o elektronický podpis prístupovým miestom resp. právnickou osobou - v tom prípade by to mohla byť jedine elektornická pečať - ideálne kvalifikovaná). Takže v tomto prípade zrejme používateľ vytvorí “elektronický podpis” (kamuflovaný ako “Klik”) a to navyše tak, že používa ten istý kľúč pre prihlasovanie a ten istý aj pre autorizáciu! Mohli sme si vo videu o aktivácii všimnúť, že sa nastavuje iba jeden znalostný faktor. Pritom odporúčaná prax (schválne, pozrite si videá o Smart-ID, zdieľané p. Sucháľom) mať separátne kryptografické materiály s nezávislým nastavením a overením znalostných faktorov pre autentifikáciu a autorizáciu.

Ako bonus: ak sa používa podpisovanie na účely autentifikácie, tak sa porušuje samotné nariadenie eIDAS, ktoré jasne odlišuje nové nariadenie od predošlej smernice o elektronickom podpise tým, že podpisovanie je možné použiť výlučne fyzickou osobou na autorizáciu (prejav súhlasu nad množinou údajov), nie na autentifikáciu.

Toto nie je možné považovať za dobrý príklad, práve naopak. Pravdepodobne nespĺňa ani požiadavky vyplývajúce zo zákona (a rácio stanovené v dôvodovej správe) a ani požiadavky eIDAS a definovaných konceptov. Preto by ma zaujímalo, aké boli akceptačné kritériá, ako bol preukázaný súlad s legislatívnym rámcom, vrátane eIDAS - vrátane bezpečnostných záruk.

Tým nadväzujem aj na príspevok p. Illeka ohľadom CSIRT, vyhodnocovania atď… Práve preto je kľúčové bezodkladne (už včera bolo neskoro) vytvoriť nejaký hodnotiaci rámec všetkých aspektov elektornických identifikačných schém platný pre všetkých bez výnimky a vyhodnocovanie by malo byť vykonávané kompetentnými odborníkmi v tejto špecifickej oblasti. Takéto faux pas by sa nemalo udiať a ani zopakovať.

Očakával by som väčšiu principiálnosť, konzistentnosť a dôslednosť pri hodnotení takýchto riešení z pohľadu S.D, ktoré zrejme budú mať ambíciu dohodnúť sa s Nases a umožniť využívanie aj na UPVS (alebo dokonca aj na iných prístupových miestach samotných OVM). Tu nejde o piškôrky, ale o práva a povinností F.O. A ešte si na poslednej obrazovke po aktivácii napíšu bez rozpakov: “Odteraz môžete pri elektronickej komunikácii používať svoj občiansky preukaz v mobile…” Možno by stálo za to zodvihnúť “červenú vlajočku”?

Nakoniec, S.D má medzi svojimi členmi aj spoločnosť (sekcia “stredná firma”, s prepojením na dodávateľa riešenia a nedá sa vylúčiť, že pre svoje účely využíva to isté jadro riešenia, ktoré je však používané v inom kontexte a tam to môže byť “v pohode”. Možno je to toto spred mnohých, mnohých rokov (https://www.encapsecurity.com/mtrust-chooses-encaps-software-based-authentication-solution/).

Som zvedavý, či sa bude vyžadovať okamžité pozastavenie používania až do momentu vykonania nápravy a uvedenie riešenia do súladu so všetkými povinnými/mandatórnymi požiadavkami definovanými v národnom a tiež nadradenom legislatívnom akte v podobe nariadenia.
Navyše, som napätý, s čím príde novovzniknutá štátna akciová spoločnosť v KE pre štátne IT, ktorá by mala ako medzi prvými úlohami riešiť aj Mobile ID. Priznám sa, mám obavy - ak “komerčný odborníci” dokázali vyprodukovať tento príklad napriek aspoň akej-takej a predsa nedostatočnej znalosti pomerov a požiadaviek…

1 Like

Tak tymto to cele zaklincovali.

Priznam sa, ze som sa v tejto uvahe uplne stratil. Ved bolo povedane, ze autorizacia kliknutim funguje tak, ze sa pouzivatel autentifikuje a nasledne kliknutim sa autorizuje ukon. Kde presne tam vidite elektronicky podpis? A kde vidite el. podpis pouzity na autentifikaciu pouzivatela? Ci dokonca nejaky prislub suladu s eIDAS? Nerozoberali sme prave vo vedlajsej teme, ze autorizacia klikom urcite nie je podla eIDAS a ani taka byt nechcela? Mozno aj preto porovnanie s estonskym Smart-ID nie je uplne na mieste.

Toto je predsa uplne naopak. Ved povodna zmluva bola s NASES prave preto, aby sa to pouzivalo centralne na UPVS.

Toto je samozrejme “velke marketingove zjednodusenie”. Uz len preto, ze to je de jure maximalne vlastnorucny podpis a nie KEP. Urcite by sa policia zasmiala, keby som im ukazal pri kontrole nejaku apku DCOMu.

PS. Moje meno sa pise dost inak.

Zdá sa, že nikto dnes nevie jasne a konzistentne povedať, ako má fungovať autorizácia klikom resp. akým spôsobom sa naplnia všetky požiadavky uvedené v zákone. Jediné, čo ako-tak zužuje obsah pojmu autorizácia klikom je práve dôvodová správa a tá vylučuje elektronické podpisovanie ako také. P. Illek spomínal, že sa využíva elektronický podpis pre dosiahnutie integrity pri tomto akože “kliku”. Ak sa vylučuje podpis, ostáva už len pečať - a tu som o pečati nepočul ani zmienku. Zadaním PIN-u sa vykoná tá istá operácia s tým istým kryptomateriálom pre autentifikáciu a zároveň aj autorizáciu - pričom si všimnime, že v samotnom popise pri aktivácii a aj video návodoch na podpisovanie sa jasne hovorí o podpisovaní https://www.dcom.sk/videonavody-mid . Autentifikácia a aj autorizácia, za predpokladu, že je na základe AC a konzistentná s prezentovaným riešením v júli 2020 a ostatnými materiálmi zverejnenými tu na platforme, zrejme vykoná výzvu-odpoveď. Autorizácia vykoná tú istú operáciu avšak nad samotným obsahom. 1. Tento úkon “autorizácie klikom” má byť vykonaný prístupovým miestom bez využitia elektronického podpisovania a obávam sa, že v tomto prípade sa to nedeje týmto spôsobom. 2. Je dôvodné podozrenie, že sa napĺňajú definície eIDAS pre AdES (a) je jedinečne spojený s podpisovateľom; b)
umožňuje určenie totožnosti podpisovateľa; c) je vyhotovený pomocou údajov na vyhotovenie elektronického podpisu, ktoré môže podpisovateľ s vysokou mierou dôveryhodnosti používať pod svojou výlučnou kontrolou, a d) je prepojený s údajmi, ktoré sa ním podpisujú, takým spôsobom, že každú dodatočnú zmenu údajov možno zistiť.) najmä ak dodávateľ v riešení najskôr avizoval využitie práve AdES. Z toho môžeme usúdiť, že sa nejedná o autorizáciu spôsobom, ktorý je v súlade s platnou legislatívou.

Čo sa týka súvislosti s eIDAS, tu nadväzujem na riešenie ako autentifikačného mechanizmu - ak je to autentifikačný prostriedok, tak by mal byť použitý na autentifikáciu na príslušnej úrovni bezpečnostných záruk. Zároveň však platí, že autorizácia na autentifikáciu nie je prípustná a logicky ani autentifikácia by nemal byť použitá na autorizáciu. Tu však tieto koncepty zlievame a používame simultánne aj ako autorizačný nástroj. Preto je možné ho posudzovať ako v rozkole so základnými princípmi nariadenia eIDAS. Podľa definície “Kliku” samozrejme by nemal byť tento spôsob autorizácie elektronickým podpisom vôbec (bez pochýb - tak je to predsa uvedené v dôvodovej správe) a tiež nespadá pod eIDAS, keďže je definovaný výhradne na národnej úrovni.

Smart-ID som uviedol ako príklad, kedy sa jasne oddeľuje autentifikácia od autorizácie keď sa používajú tie isté mechanizmy, ale v jasne vymedzenom kontexte a so samostatným nastavením faktorov a kryptografických materiálov - neumožňuje sa “duálne” využitie (autentifikácia a autorizácia zároveň), zrejme práve kvôli spomínanému princípu eIDAS. Diskutované riešenie je pravým opakom tejto “očakávanej” praxe. V bankách a komerčnom sektore (PSD2 SCA) to môže byť dostatočné, v eGov podľa eIDAS však nie.

Ja hovorím o aktuálnom stave - riešenie je momentálne nasadené v DEUS/dcom.sk, nie UPVS/slovensko.sk. Zákon umožňuje po dohode s Nases využívať aj na UPVS (otázne, či aj na ďalších prístupových miestach a špecializovaných portáloch). Ak by sa šlo podľa spomínanej zmluvy, tak už teraz by sme mali vidieť ďalší mechanizmus na UPVS a zrejme by sa neriešil paralelný vývoj košickou IT spoločnosťou na niečo, čo by malo byť už zazmluvnené a poskytované - alebo sa mýlim?

Za to sa ospravedlňujem.

To čo som chcel vyjadriť sú vážne pochybnosti o súlade s legislatívou a hlavne neexistuje efektívny a aplikovateľný mechanizmus preskúmania schémy a to ešte pred uvedením do používania jednotným spôsobom s jasným výkladom atď. A to môže mať veľmi závažné následky a pochybnosti o nových spôsoboch autentifikácie a autorizácie.

Inak ked uz to tu tak rozoberame, to vydavanie certifikatov na dialku len zadanim BOKu nie je uplne to iste? eIDAS je s tymto v pohode? (Na rozdiel od autorizacie klikom toto naozaj podla eIDAS ist musi)

https://www.opytajsauctovnika.sk/nahranie-a-aktualizaciu-certifikatu-na-obciansky-preukaz-uz-zvladnete-aj-vy-sami/

V tomto prípade sa jedná o diametrálne odlišný proces vydávania KC, ktorý vyžaduje pred vydaním certifikátov overiť totožnosť tak ako uvádza eIDAS (v tomto prípade autentifikáciou na úrovni “Vysoká” zadaním BOK). Samostatne sa potom autorizuje zmluva pomocou KEP (teda použitím PIN). Z toho mi vyplýva, že je to tak, ako to má byť: autentifikácia s BOK separátnym mechanizmom a autorizácia s PIN a KEP.

1 Like

Áno presne tak, jedná sa o autentifikáciu na úrovni “Vysoká”, pričom táto bola notifikovaná a schválená v súlade s eIDAS nariadením.

Asi som sa nevyjadril jasne. Toto vobec nespochybnujem, len mi to pride velmi velmi podobne autorizacii klikom. Tu ziadost o vydanie KC totiz autorizujem tym, ze sa autentifikujem na urovni vysoka a kliknem. Hotovo.

Toto nie je celkom tak, vydanie KC sa autorizuje okrem autentifikácie s BOK aj podpísaním PKCS#10 žiadosti.

Formalne ano, prakticky to je tak, ze zadas BOK, nastavis si PIN/PUK a potom tymto istym PINom autorizujes ziadost. Cize cely proces je sice na oko komplikovanejsi, ale realne ho ho chrani len ten BOK. To bola pointa.

Spat k teme: Na celom tom rieseni DCOM je otazna podla mna len biometria + fotka OP sluziaca na prvotne stotoznenie. Toto nerobia ani estonci, oni skor vyuzivaju na toto stotoznenie prihlasenie cez bankovy ucet (kde to uz prebehlo nejako inak - najskor osobne).

Kazdy system je iba tak silny ako jeho najslabsi clanok. Toto sa zda ze je takym clankom.
Kedze dalsie videa okrem tych aktivacii sa mi nedali prehrat tazko sa vyjadrit k tomu napr. co pise @Nikhaj ale uz ta samotna aktivacia jedna aj druha (ak uz sa aktivuje cez eID bolo by potrebne aby ten QR bol vlozeny v schranke a az tam si ho odfotografovat a pod.) vyvolava vela otaznikov.

Problem je to ze biometria a fotka z OP je takmer cele riesenie lebo okrem toho jedina nova funkcionalita je defacto kryptooperacia vyvolana z mobilu (defacto zawrapovany web), kezto doteraz si potvrdil podanie v prehliadacia a podpisal. Ciže riešenie ma dve časti registracia a podpisovanie/kryptooperacie nad udajmi dokumentu a identity. Nič viac riešenie neobsahuje je to len DCOM specifik.

Priznam sa, ze neviem co tymto chces povedat.

Trochu si to konstatovanie protireci. Ved zadate BOK (autentifikacia+identifikacia), nasledne generovanie kluca na karte, na ktory sa ma vydat certifikat - automaticky to znamena nastavenie PIN/PUK. Prave novym klucom (zadanim PIN) sa podpisuje - teda sa vyuziva autorizacna funkcionalita, nie autentifikacna.

Ale mate pravdu, odbocili sme.
Nemyslim si, ze len biometria je otazna. Viac ma znepokojuje rovina, ci je alebo nie je toto riesenie v rovine autentifikacno/autorizacnej (elektronicky klikopodpis ci ako to nazvat) v sulade s dnes platnym zakonom 305/2013 s ohladom na dovodovu spravu a aj eidas. Ak nie (co kludne moze byt tento pripad - dokonca si myslim, ze je to vysoko pravdepodobne), tak sa mi to javi ako zasadny problem, pretoze ziadne podanie autorizovane tymto sposobom nemoze byt akceptovatelne. Ved ked by to bola funkcia pristupoveho miesta, tak niekde predsa musi byt zadokumentovana, opisana, implementovana na nejakom komponente/pristupovom mieste mimo pouzivatelskeho prostredia.

Asi hovorime o dvoch roznych veciach.

  1. Ja rozumiem logike preco bezpecaci chcu dva PINy. Ale ako to byva, realita je mozno smutnejsia, na tejto malej vzorke vidiet preco https://twitter.com/dusoft/status/1308403815704649728)
  2. Realne je PIN na autorizaciu ziadna ochrana, ked si viem novy cert vygenerovat len pomocou BOK.

Stale nevidim dovod preco by to malo byt v sulade s eidas. Je to na vnutrostatnu autorizaciu, mame to v zakone.

Co sa tyka autorizacie. Ja stale nerozumiem, kde stale vidime toho strasiaka pri autorizacii klikom. V 305/2013 sa pise

použitím na to určenej funkcie informačného systému prístupového miesta a po úspešnej autentifikácii osoby ktorá autorizáciu vykonáva, zodpovedajúcej najmenej úrovni zabezpečenia „pokročilá“ podľa osobitného predpisu,20a) ak sa zabezpečí uvedenie tejto osoby ako odosielateľa elektronickej správy, nemennosť obsahu autorizovaného dokumentu do momentu uloženia v elektronickej schránke adresáta, spojenie autorizovaného dokumentu s identifikátorom osoby odosielateľa a zachovanie väzby medzi nimi, ak to osobitný predpis nezakazuje

Cize postupujem v krokoch:

  1. Prihlasim sa urovnou pokrocila
  2. Zobrazim pouzivatelovi co ide autorizovat.
  3. Pouzivatel klikne v dostatocne kratkom casovom intervale na tlacitko “Autorizovat”
  4. System zasle do schranky adresata v mojom mene podanie. Pripadne tam to pristupove miesto strci nejaku autorizacnu dolozku, aby bolo jasne ktory system to spravil a akceptovali to na nejakom inom urade.

Kde presne mame problem s takymto primitivnym riesenim?

1 Like

Mozno by sme mali vyslovne hovorit iba o podaniach kde sa nevyzaduje autorizacia KEPom.
Cize napriklad podavam Vseobecne podanie na nejaky urad a nebudem ho podpisovat KEPom
Ak dosiahnu pozadovanu uroven prihlasenia potom podobne ako v schranke (kde sa dnes mozem rozhodnut ci podanie podpisem alebo odoslem bez podpisu) sa len do nej prihlasim, vyplnim formular vseobecneho podania a odoslem. V schranke sa pred odoslanim rozhodnem ci podpisem alebo nie, tu by sa to nemalo dat dokial sa nevyriesi pokrocila uroven prihlasnia a QSCD na mobile resp. vzdialene podpisanie KEPom

Akonahle je treba autorizacia KEPom uz je to ina vec.
Tu nas asi pomylil ten zdokonaleny podpis, ktory nechapem aku ma ulohu kedze som vsetky videa nevidel.

A ako pise aj @Nikhaj nemalo by sa to diat takto akousi vrstvou pred portalom, ale mala by na to existovat podla zakona zdokumentovana a zverejnena sada funkcii. A pre aktivaciu mobilneho zariadenia aj stanoveny postup procesov v suvislosti s portalom UPVS ktorym sa cely proces zdokumentuje a vylucia sa moznosti zneuzitia. Napr. celu aktivaciu riesit formou sprav UPVS (napr. sprava o tom ze mobilne zariadenie chce prevziat identitu s ciarovym kodom, cinnost v mobile a nasledna sprava o tom ze zariadenie xy sa naparovalo na moju identitu, odsuhlasenie pod…) Schranka by mala zaroven obsahoat sekciu kde vidim vsetky taketo zariadenia ktore som si naparoval a ak by tam bolo nejake co mi nedava zmysel musi byt moznost zo schranky ho deaktivovat. A asi aj dalsie veci. Bez toho to ani nespustat lebo skusat na ostro sa neoplaca…