Az na to, ze eIDAS to ma na vlastnorucny podpis a nie uradne osvedceny ako u nas, ze?
Upresnim
Vlastnorucny podpis podla eIDAS je KEP.
Uradne Osvedceny podpis je tiez KEP, ale zostaveny specialnym sposobom, ked sa najprv nad dokumentom urobi Kvalifikovana casova peciatka a Kvalifikovany podpis sa vytvori az z tejto peciatky a podpisovaneho dokumentu.
Oba su vlastnorucne podla eIDAS, ale u nas sa za uradne osvedceny povazuje paradoxne KEP kde je dokazatelne ze dokument existoval v case pred podpisom (to uradne osvedcenie tam chyba).
Ale riesis blbosti. Vysledok je ten, ze podla eidasu mobilom spravis leda tak vlastnorucny podpis a u nas chces mat v mobile notarsky osvedceny podpis. Citis ten jemny rozdiel?
1 Like
Nie ja len tvrdim ze ak by sa dal v mobile pouzit kvalifikovany elektronicky podpis, mozem pomocou mobilneho zariadenia podavat aj podania, kde sa zo zakona vyzaduje kvalifikovany elektronicky podpis.
Nechcem mat v mobile notarsky overeny- radsej ho nazvime uradne osvedceny. Preco by nebolo mozne mat v mobile moznost vytvorit obycajny kvalifikovany podpis - nie uradne osvedceny, ale kvalifikovany, ked uz dnes existuju moznosti ako to bezpecne urobit. Ved to je len o tom ze si u nejakej firmy zapaltim za sluzbu a mozem v mobile podpisovat kvalifikovanym elektronickym podpisom aj bez eID karty. Stat mi do mobilu nemusi vobec nic davat len mi nebrat moznost podpisat aj podanie ktore vyzaduje kvalifikovany podpis.
Daj to slovo vlastnorucny prec. Hovorme o kvalifikovanom podpise.
Kvalififikovany = vlastnorucny
Overeny = kvalifikovany ktory obsahuje v sebe casovu peciatku pred podpisom. Cize aj to aj to je KEP len inak zostrojeny. (oba su podla eIDAS vlastnorucne)
Vyhodou KEP v mobile ze mozem podavat aj podania ktore musia byt podpisane.KEPom. Staci mi obycajny KEP, nepotrebujeme uradne osvedceny ten sa vyzaduje uplne vynimocne.
Ale koncovemu pouzivatelovi je uplne jedno ako to nazves a kde su ake peciatky. Vo vysledku ho zaujima ake ukony cez ten mobil vie spravit.
Ty hovoris, ze chces vediet podpisovat, tak, ze cez to bude KEP podla EIDASu. Cize ked ti tam do extremne slabo zabezpeceneho zariadenia (lebo mobil nosis vsade, vyberas vsade…) nejako podhodim dokument, ktory bude mat peciatky na spravnom mieste sa odrazu stane na slovensku uradne osvedceny podpis. Cize napriklad ti tam podhodim, ze cely tvoj majetok je uz moj. A vela stastia na sude, tvrdit, ze ty si toto nepodpisal. Lebo ved uradne osvedceny podpis. Peciatky na spravnom mieste, aj KEP to je.
Ja neriesim, co by to tebe umoznilo, ja riesim bezpecnost. Naproti tomu, tu mame autorizaciu kliknutim, kde nepotrebujes ziadne sambalamba zlozite eidasoviny, ktore sluzia na nieco uplne ine a ma to ucinok vlastnorucneho podpisu = nemusis sa tak velmi bat, ze ked ti niekto ukradne mobil a niekde ti okukal PIN, ze s tym nejako vela skody urobi. Si vyber. A teraz ruku na srdce, kolko krat si si za zivot povedal “jaaj, tu keby sme mali EU interoperabilny KEP podpis cez mobil, tak by som nemusel vytahovat eid kartu”. Samozrejme zartujem, neverim, ze aj s tym existujucim a roky fungujucim eID si to vobec niekedy spravil na iny ukon ako na Slovensku.
1 Like
Ano podpis klikom umozni 90 percent ukonov. KEP by umoznil aj dalsie… Nakoniec je v dokumente aj jasne napisane ze remote signing nie je sucastou tohoto projektu.
Otazka bezpecnosti je samozrejme na prvom mieste. Ak dosli k zaveru ze remote signing nie tak mozno aj z tohoto dovodu.
Zabezpecenie podpisu na mobile by bola dolezita otazka ak by sa niekedy touto cestou islo. Vyhodou by bolo ze privatny kluc sa v zariadeni nenachadza a pred autorizaciou by prebehla najprv autentizacia na upvs, potom by mohlo byt biometricke overenie osoby napr. odtlacok prsta a potom by az nastalo overovanie uzivatela voci podpisovej sluzbe. Tym by sa mohlo vylucit ze aj ked mi niekto zoberie mobil, stale sa k zadavaniu autentizacnych udajov voci sluzbe podpisovania nedostane.
Ale ano mas pravdu skor ako to ake ukony voci statu viem urobit musi mat prednost posudenie bezpecnosti riesenia.
Tato “finta”, ze kluc nebude na zariadeni je len taky hack, ktory mi pride dost smiesny. Riesi podla mna len velmi marginalne vektory utoku. Mobily dnes maju rozne secure enclave/trusted store, z ktorych by si nieco dostaval velmi velmi tazko. Samozrejme kvalifikovane certifikovane ulozisko je lepsie, ale mozes mat to najlepsie HSM v trezore za dverami s tigrom, pokial sa to da zavolat cez API z tvojho mobilu, ktory je slabo chraneny, tak si to cele robil takmer uplne zbytocne. Zvykne sa hovorit, ze retaz je silna len tak, ako jej najslabsie ohnivko, ze?
4 Likes
súhlasím s týmto, ale odporúčam upraviť teda povinnosť čo riešiť len KEPom a čo inými formami aj v legislatíve, aby to bolo jasné.
T.j. aby sa riešila “závažnosť” úkonu a podľa toho sa aj vyžadovala povinnosť. Toto je dosť vágne v zákonoch upravené, určite by minimálne pri koncových službách a formulároch by sa mohol doplniť alebo spresniť parameter - dnes je tam len KEP ANO/NIE. Toto by pomohlo aj pre budúci systém s podporou mobilných služieb.
META IS - formuláre:
Používateľ formulára: interný číselník s hodnotami PO, FO, FO- podnikateľ, OVM. Viacnásobný výber je možný.
Typ formulára: Výber zo zoznamu – podanie (vstup), rozhodnutie (výstup).
Vyžaduje KEP: Zaklikne sa, ak formulár pred odoslaním vyžaduje podpísanie KEPom.
Úroveň autentifikácie: Výber zo zoznamu – aká úroveň autentifikácie používateľa je vyžadovaná na vyplnenie formulára. Obsahuje
úrovne od 1 do 4 podľa vyhlášky ÚPVII č. 78/2020 Z.z. o štandardoch pre ITVS, doplnené o úroveň 0 - anonymná. Vybraná úroveň znamená minimálnu úroveň autentifikácie, teda môže byť aj vyššia. Úroveň autentifikácie musí byť v súlade s atribútom Úroveň autentifikácie príslušnej koncovej služby.
absolútny súhlas, ja som videl chalanov zo slovenska, ktorý urobili podobný HSM klúč https://www.youtube.com/watch?v=7hp6GRSSdLk
a verím, že to vyskladali z geretov, čo sú bežne dostupné aj v mobiloch, teda musí to ísť aj v takom sofistikovanom zariadení, ako je mobil / tablet.
Alebo potom opustiť tému elektronického podpisu v mobile a naozaj sa zamerať na dvoj - trojfaktorovú autentifikáciu / autorizáciu, ktorou nahradiť proste ten elektr.podpis - KLIKOM. Toto riešenie ale by som nehovoril, že je len pre mobil, mohlo by to byť aj pre služby na IoT zariadenia a podobne … podobne, ako je tomu dnes pri rôznych termináloch
trošku si dovolím zašpekulovať a pofilozofovať 
už 90% by bol obrovský úspech, v zmysle pravidla 80:20 (paretovo optimum) Vám poviem, že 20% služieb Vám prináša 80% benefitov. A Zároveň si myslím, že platí, že ak 90% služieb je možné pokryť jednoduchším riešením, tých 10% musíte dať dodatočné náklady, ktoré Vám ale neprinesiu adekvátnu pridanú hodnotu, teda nad Vašich 90% Vám každé percento dalších služieb prinesie znižovanie % úžitku, teda Hodnoty za peniaze (BCR) 
a teda sa to neoplatí / resp. nikdy sa vynaložené prostriedky nevrátia
1 Like
Nemyslel som to tak ze 90 percent vsetkych moznych podani, ale skorej tak, ze su podania u ktorych sa vyzaduje kvalifikovany podpis (je ich malo). Cize tieto podania sa mobilom podat nedaju. Napr. ak bude niekto v zahranici a bude potrebovat urobit taketo podanie tak z napr. tabletu, ci mobilu ho ho neurobi. A z cudzieho pc je to tiez nanic.
On zas tak na smiech nie je kedze tento sposob podpisovania sa dostal az do nariadenia EK.
Dnes je to kvalifikovana sluzba, ktora dava dalsie moznosti kazdemu kto ma o nu zaujem.
Samozrejme treba zvazovat vsetky rizika a ochrana privatneho kluca je tym najzakladnejsim. V tom dokumente od disig jeho autor spomina aj tento problem s ulozenim kluca v zariadeni a vonku. Je to o pohlade na sposob ulozenia kluca.
Kym v mobile ak mi ho ukradnu ma zlodej moznost neobmedzene skusat sa ku klucu dostat. Pri kradezi mobiulu so vzdialenym podpisovanim, mi staci pozicat si iny mobil a zavolat sluzbu aby zrusili moj pristup. A uz nema utocnik na co zautocit kedze v ukradnutom mobile nic nie je.
Inak dnes sa v mobilnych zariadeniach uz podpisuju v mobilnom zariadeni aj daleko vacsie hodnoty ako nas majetok. Funguju na tom cele platformy (napr. https://www.docusign.com/ ).
Cele sa to ale toci okolo ochrany privatneho kluca.
Cize nedovera je na mieste.
A samozrejme by tie služby najprv museli existovať, alebo aspoň existovať v prijateľnej podobe 
1 Like
No tak som presiel ten majestatny dokument a dal tam moje komentare (je rozbity, ale citat sa da, pouzivam to hlavne na komentovanie)
TL;DR
- alternativy su totalna fraska, toto uplne vidiet ako strasne rozmyslali ako tam vymysliet vsetko mozne len nie tu alternativu o ktorej hovoria vsetci od zaciatku.
- dizajn manual explicitne hovori o tom, ze OVM si budu robit vlastne nativne aplikacie. mnozne cislo. je pre mna absolutne sokujuce, ze predstavitelia na MIRRI/SKIT sa na verejnych prezentaciach tvaria ze to tak nebude. V CBA je explicitne napisane, ze vznikne 5 nativnych aplikacii rocne (!) a v t3 dokonca 10 (!!!) to je jedna nativna statna aplikacia kazde dva mesiace. Toto je ciste blaznovstvo.
Idem si otvorit pivo lebo toto sa neda.
3 Likes
Preletel som pripomienky od @jsuchal , dobre spisane.
Mam pocit ze to je zhluk uplne roznych technickych a biznis tem, z celeho dokumentu mozno staci citat cast 3.4 - pozadovane vystupy:
- mobilne doklady (zrazu su len tak spomenute aj PNky)
- platby
- notifikacie
- framework, manazment a ktovie co este pre nove mobilne aplikacie (vid nizsie)
S tymi mobilnymi aplikaciami maju ocividne velke plany, je tam aj sluzba Manažment mobilných aplikácií -
Služba bude zabezpečovať:
- Registráciu mobilných aplikácií
- Overenie mobilných aplikácií
- Správa mobilných aplikácií
- Administrácia mobilných aplikácií
Ak by som to mal zhodnotit, miesto tohto riesenia mohli radsej skusit postavit nejake paralelne UPVS na responzivnom webe A kebyze to dobre funguje, mozu po castiach vypinat to stare UPVS 
Predpokladam, ze to tam dali, co vedia robit, teda vyzera, ze “potreby/poziadavky” sa prisposobuju firme …
1 Like
prepáčte prosím, Mobilné aplikácie budú mať iné rozhrania / manažment ako akékoľvek iné aplikácie? tomu nerozumiem. Myslel som, že bude jedno API, cez ktoré bude možné pristupovať k službám a je jedno, či to bude mobilne alebo PC. A tiež, ak hovoríme o mobilných aplikáciách, nemali by to byť aplikácie jedno či PC alebo mobil, ale optimalizované zobrazenie pre daný typ zariadenia, ktoré sa na služby pripojí?
ak sa idú robi mobilné aplikácie natívne pre konkrétny OS mobilu, tak sa toho dosť desím. Stačí sa pozrieť na to množstvo mobilných aplikácií, čo stát nechal urobiť pre obce a iné projekty v OPISe a kto ich dnes používa… nikde som o tom nenašiel žiadnu zmienku.
Dalšou vecou je, čo si spomínam, tak už dnes v rámci projektu eDOV v NASES mala byť možnosť reišenie aplikácií pre OpenData. sú tam dokonca aj služby aby ste mohli takéto aplikácie registrovať. videl z Vás niekto takéto aplikácie?
Materiálu a projektu by som okrem tu spomenutých tém (prípadne preberaných už počas ostatnej online prezentácie) vytkol netransparentnú architektúru. Tú ťahajú dole veľmi vágne definované závislosti od iných projektov. Zároveň projekt a jeho architektúra porušuje viaceré z doteraz platných princípov strategických dokumentov NKIVS. Samozrejme všetky princípy je možné zrevidovať, ale v slušnej spoločnosti to predpokladá najprv vyvolanie odbornej diskusie, následne férové vysporiadanie odporúčaní a až potom vystrelenie projektov. Aby sme teda namiesto jedného kroku vpred, nerobili tri kroky vzad. Môj názor po preštudovaní dokumentu je, že sa veľmi pravdepodobne práve na tie pomyselné tri kroky vzad pozeráme.
Závislosti sú v podkladoch uvedené na tieto projekty.:
- CAMP – centrálna API manažment platforma. Tento projekt by mal podľa podkladov priniesť OAuth2 a OpenIDConnect do IAM-u. To je myslím pripravené v rámci MUK-P (akýsi predvoj CAMP-u), ale MUK-P realizoval existujúci dodávateľ ÚPVS. Okolo spustenia alebo nespustenia MUK-P panuje dosť nejasností, viď zápis z riadiaceho výboru v MetaIS (MetaIS). Zároveň je v podkladoch projektu SVM uvedené, že projekt CAMP má predpokladaný termín ukončenia 30.6.2022. Znamená to, že ešte vyše roka nebude mobilná identita v produkcii ani na prihlasovanie? Koľko bude štát nakoniec musieť zaplatiť za to, aby funkcia Oauth2 a OpenIDConnect bola v IAM využiteľná (z MUK-P alebo dodaná iným spôsobom)? Samozrejme odpoveď na tieto otázky môže významne upraviť existujúcu CBA projektu SVM – najmä ak existovala možnosť pripojiť sa na v súčastnosti funkčný mechanizmus v IAM-e (SAML 2.0 IdP). Na občana by toto rozhodnutie nemalo dopad (nevie cez aký protokol by to dočasne išlo a ani ho to nezaujíma pokiaľ funkčnosť funguje) a mobilnú autentifikáciu sme mohli mať dodanú ďaleko skôr a bez závislostí od CAMP.
- Remote Signing. „Záhadný“ projekt a aj závislosť. O projekte nič nevieme, disponujeme len jednou vetou.: „Podpis dokumentu KEP s certifikátom na serveri nie je scope SVM, len autorizácia klikom“. Prvou otázkou je, načo je nám aj podpisovanie KEPom na serveri aj cez NFC. Druhou, či podpisovanie KEP-om naozaj potrebujeme, keď bude fungovať – zdôrazňujem dobre postavený - podpis klikom v mobile (CBA bude nepochybne výzva)? Podpis klikom podľa môjho názoru zatiaľ v projekte dobre postavený nie je a jeho adopcia v komerčnom sektore je veľmi otázna. Nakoniec ale tá zásadná otázka.: Prečo je tento projekt pre SVM ako závislosť? Bude dodávať niečo, čo by sme očakávali už pri SVM (teda do základného procesu podpisovania)? Ak nie – nemá čo byť v závislostiach. Z podkladov sa však môže javiť, že projekt SVM z témy „centrálnej autorizácie“ dodá len API službu (na inicializáciu podpisovania), pričom funkčnosť centrálnej vizualizácie podania pred podpisom si musí na svojom portáli urobiť (responzívne) každé OVM. Prípadne dodá ho centrálne nejaký iný projekt? Ak áno, tak ktorý (ÚPVS 3.0? Remote signing? Iný projekt?)? Kedy? Nechcem, aby toto celé vyznelo že už dopredu predpokladám zlý úmysel – naopak – verím, že témy majú racionálne vysvetlenie. Ale v podkladoch zrozumiteľné vysvetlenie nevidím, na PS to myslím nikde preberané nebolo a potencionálne dopady na CBA a porovnávanie alternatív môžu byť nemalé.
- UPVS3.0 (pripomienkovanie beží paralelne k tomuto projektu). Tu je otázka, nakoľko dodávka online formulárového engine-u uvažovaného z ÚPVS 3.0 „pozdrží“ dodanie online formulárového engine-u v natívnom mobilnom svete (sú to prepojené koncepty). Opäť, keďže nám nikto nevysvetlil, ako to bude vyskladané – v tom najhoršom scenári sa môže stať, že podpisovania v mobile sa dočkáme až keď budú hotové editory formulárov na ÚPVS 3.0. To by bol zase nie malý dopad do CBA, preto ho potrebujeme v pripomienkovaní vylúčiť.
- MOU (modul osobných údajov). Očakával by som, že už je rozhodnuté, či to bude jedna (prefereované) alebo dve mobilné aplikácie. Najmä ak si uvedomíme, že občan v prípade dvoch appiek bude musieť pozerať povolenia ktoré udelil tretím stranám na volanie služieb (v jeho mene) v inej aplikácii, než keď chce pozrieť povolenia – komu všetkému aké dáta zdieľal (zdieľa).
Čo sa týka porušenia schválených a aktuálne platných zásad a usmernení zo strategických dokumentov NKIVS, alebo uznesení na pracovných skupinách.:
- Porušenie SP Multikanál – podania sa majú robiť cez responzívny web a nie cez natívnu aplikáciu. Rovnako tak prístup do schránky.
- Snaha implementovať „inteligentné formuláre“ na mobile - porušenie Referenčnej architektúry IISVS – princípu 3 (v kapitole 3).
- Nevyužitie hotového autentifikačného mechanizmu na IAM-e (SAML 2.0 IdP), ale čakanie na Oauth2 a OpenIDConnect – v rozpore s odporúčaním z PS Strategická Architektúra (20.5.2020) a odbornej verenosti – využiť rýchlejšie dostupný mechanizmus (a Oauth2.0 a OpenIDConnect doplniť v dlhšom horizonte).
Celkovo by sme za komunitu mali navrhnúť.:
-
Aby MIRRI zverejnilo spoločný, celkový zámer a doplnili ho (referencovali) z každého predkladaného projektu. Spoločný zámer by mal obsahovať celkový pohľad na pripravované zmeny a mal by zdôvodniť navrhovanú architektúru a spôsob rozdelenia na jednotlivé projekty. Zjavne nejaký zámer na pozadí je (predpokladáme, že projekty nie sú „vystreľované“ bez internej koordinácie), chceme ho vidieť. Tento „prestrešujúci dokument“ by mal tiež jednoznačne odpovedať na vzájomné architektonické závislostí čiastkových projektov (z čiastkových to skladať je zbytočne prácne a vedie k rôznym interpretáciám a nedorozumeniu). Poslednou veľmi dôležitou vecou je jasne uviesť predstavu, ako budú jednotlivé projekty obstarávané. Je málo dôveryhodné, ak niekto povie, že všetko bude robiť SK.IT internými zdrojmi. Posledné čo tu potrebujeme – je aby SKIT bol kanál pre vyvolené firmy na pozadí, bez transparentného obstarávania (napr. cez body leasing).
-
Okrem prestrešujúceho dokumentu je potrebné požadovať konkrétne doplnenia a úpravy. Okrem iného aj férové porovnanie alternatív buy vs. build pre mobilnú autentifikáciu a podpis, ďalej dočasné vs. cieľové riešenie z pohľadu použitých autentifikačných protokolov, CBA pre každú nezávislú tému, netlačiť natívnu aplikáciu všade (dizajn systém, podania) atď.
5 Likes
ešte by som doplnil moje skúsenosti s projektom, ktorý bol písané zadanie (štúdia+príprava VO) v roku 2018-2019. chýbajú tam dopady v zmysle novej legislatívy (hlavne kyberbezpečnosť), sú veľmi striktne napísané funkčné požiadavky na systém a to bez reálnej detailnej analýzy. potvrdzuje to aj to, že sú tak ako píše @kyselat iné funkčné požiadavky ako boli pred 2 rokmi. Zároveň je problém v tom, že zadanie nie je v súlade so zákonom 85/2020, pretože by mala byť DFŠka hotová ešte pred veľkým VO na dodávku SW. Pričom ako sa písalo aj tu na fore, toto by bola práve cesta, ako rozdeliť dodanie na viacero častí. Nehovoriac o tom, že napr. konštruktor podaní alebo eFORM dizajner je už niekoľko verzií na trhu a úspešne sú implementované a funkčné, a sú v súlade s IDSK, teda kľudne by sa mohlo ísť oveľa rýchlejšie napr.verejnou súťažou návrhov HOTOVYCH RIEŠENI.
1 Like
Toto by asi malo byt k modernizacii upvs nie?