V pracovných skupinách Governance a Lepšie služby sa začala diskusia k dokumentu “Legislatívny zámer zmien v autorizácii elektronickej úradnej komunikácie”.
Zdá sa, že téma autorizácie je vcelku živá, tak zakladám k tomu nový topic.
Dokument opisuje, ako sa dnešný systém (autorizácia klikom + KEP s ekvivalenciou voči vlastnoručnému / osvedčenému podpisu v listinnom svete) prejde na systém kde sa definujú 4 úrovne bezpečnostných záruk, každý OVM si má povedať pre autorizácie úkonov “u neho” v ktorej budú úrovni a otvorené možnosti pre technickú realizáciu autorizácie v každej úrovni.
Autorom materálu je P.Frič+M.Kaľavský, keď som sa pýtal na zadanie, dostal som odpoveď, že “pri úvahách o mobilnom ID sa ukázalo ako nevieme robiť poriadne autorizáciu na mobile, lebo v ňom nie je QSCD, tak vznikla od predošlého vedenia sekcie požiadavka poriadne to vyriešiť v legislatíve”.
Nuz, ale snad oficialny dokument ma vyzerat nejako inak. Na zaklade akej poziadavky (kto ju zadal), kto to vypracoval, kedy, ktora to je verzia (nejake rfevizie, prvy draft) … snad takto sa ziaden oficialny material nikdy nemal robit
Toto posielam za mňa pred rokovaním pracovnej skupiny:
Tému autorizácie nemá zmysel riešiť úplne izolovane, je silne prepojená s témami identifikácie, autentifikácie a prideľovania oprávnení (authentication / authorization / access control).
V týchto oblastiach je predložený dokument jedna z mála viditeľných centrálnych aktivít. Aj v tomto kontexte navrhnutú zmenu legislatívy vnímam mimoriadne negatívne. Vítam možnosť diskusie ešte v tomto skorom štádiu pripravovanej zmeny, vopred posielam tieto pripomienky / otázky:
Nie je jasné, aký problém navrhovaná legislatívna zmena má riešiť. V oblasti autentifikácie/autorizácie samozrejme v súčasnosti vidím viaceré výzvy, avšak žiadnu z nich nie je potrebné riešiť „zmenou legislatívy“ a navyše takouto zásadnou. Práve naopak, zásadne obmedzené zdroje ktoré máme (najmä čas = ľudské kapacity x potrebné zmeny) má zmysel investovať do riešenia práve tých akútnych problémov.
Navyše efekt legislatívnej zmeny sa nevyhnutne dostaví až v dlhodobom horizonte, minimálne 2 rokov, najmä ak ide o takto rozsiahlu zmenu. Čiže navrhovaná zmena nemôže vyriešiť žiadne akútne problémy.
Rozumiem plánu na „dlhodobé zmeny“, avšak v súčasnosti sme natoľko pozadu v nasadení toho čo „je možné teraz“ a v skutočnom riešení dnes známych problémov, že podľa mňa nedokážeme dobre odhadovať ani potrebu a zameranie dlhodobých zásadných zmien. Sústreďme sa najbližšie 2 roky na akútne problémy a následne bude jasnejšie čo/ako je vhodné meniť dlhodobo.
Pri poslednej väčšej novelizácii z.305/2013 bolo deklarované, že jedných z jej účelov je vyriešenie všetkých potrebných zmien týkajúcich sa autentifikácie/autorizácie, a to aj z pohľadu interakcie IS-IS. Je preto prekvapivé, že práve teraz prichádza návrh na ďalšie a zásadné zmeny v tejto oblasti, hoci zatiaľ ani to čo už v zákone je uvedené dnes nie je poriadne využívané.
Materiál správne konštatuje, že v prostredí verejnej správy je vhodný „konzervatívny prístup k autorizácii“. Jeden z aspektov tejto konzervatívnosti je minimalizácia nákladov, a to tak na riešenia komunikácie s FO/PO, rovnako aj v rámci verejnej správy interne. Práve podpora iba vhodnej minimálnej sady technologických riešení k takejto minimalizácii nákladov povedie – čo je presne opačný prístup ako je predpokladaný v predkladanom návrhu.
Predkladaný návrh bude práveže mimoriadne náročný na zdroje, pričom odhad v tejto oblasti absentuje. Pôjde o náklady tak na technologické riešenia, ako aj organizačné zabezpečenie – samotná zmena legislatívy, súvisiace predpisy, centrálna správa metód autorizácie, posúdenia jednotlivých nových spôsobov autorizácie. Ak by sa v návrhu na legislatívnu zmenu malo pokračovať, je potrebné do neho už v súčasnosti doplniť odhad potrebných zdrojov.
V súčasnosti už jeden prístup založený na „úrovniach“ máme – v autentifikácii (tak v SK Výnose o štandardoch, ako aj v nariadení eIDAS) a vidíme ako mimoriadne slabo je pochopený/uplatňovaný zo strany OVM.
.
V neposlednom rade navrhovaná legislatívna úprava vyzerá byť mimoriadne podrobná, s čím je pri legislatívnych zmenách potrebné narábať veľmi opatrne (napr. vlastnoručný podpis nie je legislatívne definovaný) a taktiež navrhovaný postup nemá zrejme vo svete obdobu.
Rovnako negatívne vnímam možnosť „výberu metódy autorizácie“ zo strany každého OVM. Oproti súčasnému stavu by išlo o významné rozšírenie možností rozhodovania orgánov VS na úkor zákonodarnej moci. Aj na základe doterajších skúseností je zrejmé, že tendenciou OVM bude povoliť iba najstriktnejšie možné úrovne, čo bude zásadne znižovať použiteľnosť.
V súčasnosti pri listinne realizovaných úkonoch má VS dobre (historicky) stanovené a legislatíve zakotvené požiadavky na autorizáciu. To zahŕňa aj ošetrenie rizík pri rôznych neštandardných situáciách (podvody, falšovania, vynútená autorizácia a pod.). Preto považujem za mimoriadne vhodné elektronické spôsoby autorizácie presne zacieliť na charakteristické metódy autorizácie z listinného sveta. Z tohto hľadiska je vo VS najširšie používaná úroveň „vlastoručný podpis“ a „osvedčený podpis“. Presne týmto úrovniam zodpovedajú dnes v legislatíve zachytené elektronické metódy „autorizácia kliknutím“ (presnejšie autorizácia použitím funkcie informačného systému) a KEP. V duchu zásady „prostriedok s vyššími zárukami je použiteľný tam kde stačia nižšie záruky“ je možné KEP použiť aj tam, kde je postačujúci iba vlastnoručný podpis – rovnako ako je takto možné využiť osvedčený podpis.
Nevidím teda ani z tohto hľadiska dôvod na zásadné zmeny v oblasti autorizácie z pohľadu legislatívy. Skôr je potrebné sa sústrediť na implementáciu všetkých možností ktoré nám už súčasná legislatíva poskytuje a vyriešenie súvisiacich problémov – z ktorých niektoré sú známe aj viac ako 10 rokov.
.
Metóda autorizácie kliknutím poskytuje vo všetkých aspektoch (aspekty v zmysle predkladaného návrhu) vyššie bezpečnostné záruky ako vlastnoručný podpis. Pri identifikácii konajúceho, integrite úkonu, zachytení času vykonania úkonu, ako aj nespochybniteľnosti úkonu poskytuje vlastnoručný podpis iba minimálne záruky, čo aj doteraz bolo pre VS dostatočné. Z tohto hľadiska je možné bez obáv plošne nasadiť autorizáciu kliknutím všade tam, kde je vyžadovaný (iba) vlastnoručný podpis – odhadom ide o viac ako 80% všetkých úkonov pri interakcii s VS. Ako som už uviedol vyššie, na riešenie pochybností sa použijú doterajšie metódy formálne / právne / znalecké.
Mechanizmus použitia používateľom lokálne vytváraného „elektronického podpisu“ sa celosvetovo ukazuje ako veľmi slabo používané riešenie. QES/AdES má pri interakcii FO/PO s VS viaceré podstatné slabé miesta, najmä:
slabá možnosť automatickej identifikácie podpisujúceho
závislosť na tretích stranách (CA v rámci celej certifikačnej cesty)
mimoriadne komplikované overovanie platnosti podpisu
mimoriadne široké možnosti podpisových formátov/kontajnerov
prenesenie všetkej zodpovednosti na používateľa ktorý podpis vytvára, pričom tento de-facto je vo veľmi nevýhodnom postavení (vie iba veľmi slabo overiť čo podpisuje)
Naopak, špeciálne v asymetrických vzťahoch (t.j. kde neide o voľnú dohodu viacerých rovnocenných strán, ale o použitie schematickej služby poskytovanej jednou stranou v štandardizovaných formálnych aj technických rámcoch) stále viac rozšírené metódy sú založené na silnej identifikácii „používateľa“ a zachytenie prejavu vôle sa realizuje technickými prostriedkami výlučne pod kontrolou poskytovateľa služby. Výhodou tohto prístupu je mimoriadna flexibilnosť na strane poskytovateľa služby, tak v oblasti „servisu“ pre používateľa (t.j. spraviť implementáciu jednoducho použiteľnou), ako aj v úrovni bezpečnostných záruk za jeho časť riešenia.
.
V navrhovanej úprave kľúčovým miestom je definovanie úrovní pre jednotlivé aspekty bezpečnostných záruk. Pritom sa navrhujú binárne kritériá pre splnenie určitého aspektu záruk – áno/nie = spĺňa/nespĺňa. Je potrebné uvedomiť si, že v realite je situácia odlišná; každá reálna implementácia v uvedených aspektoch poskytuje záruky do určitej výšky a nikdy nie úplne. Preto pri zavedení navrhovaného konceptu bude potrebné stanoviť hranicu, kedy už určité záruky sú „splnené“. Táto hranica bude arbitrárna a do budúcnosti bude spôsobovať podstatné obmedzenia deklarovanej flexibility.
Zároveň v niektorých aspektoch v súčasnosti vnímané záruky sú de-facto iluzórne. Najlepším príkladom je deklarácia, kedy pri vytváraní KEP má údajne používateľ „pod svojou kontrolou prostriedky, ktorými sa autorizácia vykonáva“. V skutočnosti táto premisa platí iba teoreticky, reálne používateľ použije hardvér a softvér, ktorý nemá úplne pod svojou kontrolou a nevie overiť ako funguje, rovnako nevie overiť aký dokument v skutočnosti podpisuje – z jeho pohľadu ide „iba“ o súhlas s tým, čo vidí na obrazovke a dôveru v poskytovateľa nástrojov ktoré používa.
Do diskusie k téme autentifikácii/autorizácii však chcem pristúpiť konštruktívne. Mali by sme sa spoločne zamyslieť, ktoré problémy a ciele pred nami sú a je potrebné ich riešiť. Navrhujem nasledovné aktivity z krátkodobého hľadiska:
Rozšírenie nasadenia metódy autorizácie kliknutím všade tam, kde to už súčasná legislatívna úprava umožňuje. V tejto téme má samozrejme zmysel postupovať tiež koordinovane, nasledovným spôsobom:
„toolkit“ pre čo najjednoduchšie nasadenie v nových službách
úprava existujúcich služieb podľa priorít, najmä používanosti služby
najskôr tam, kde nie je „odpor úradníkov“, prípadné výhrady
Vydať štandard pre preukazovanie autorizácie kliknutím, najmä pri komunikácii medzi OVM navzájom
Reálna klasifikácia elektronických služieb do úrovní autentifikácie, špecificky do úrovne „pokročilá“ podľa eIDAS
Zmena SK štandardu pre úrovne autentifikácie na 3 úrovne kompatibilné s eIDAS
Pri identifikačných schémach podľa eIDAS doriešiť, aby SK implementácia nebola iba Potemkinova dedina, t.j. po prihlásení ne-SK schémou vedel občan aj reálne nejaké služby použiť
Doriešiť skutočné akceptovanie KEP, nielen založeného na certifikátoch z eID, vrátane opustenia prítomnosti RČ v certifikáte pre KEP v eID.
A taktiež nasledovné aktivity z dlhodobého hľadiska:
Strategické riešenie pre komunikáciu IS-IS, špecificky čo s registrom autentifikačných certifikátov, ktorý považujem za legislatívny archaizmus.
Naopak, asap riešenia pre udeľovanie oprávnení na zastupovanie – špeciálne centrálny register elektronických plnomocenstiev
Zmysel a uplatnenie úrovne autentifikácie „nízka“ podľa eIDAS a systematický prístup jej využitia. Napr. autentifikácia pomocou verejne používaných schém – Google, Facebook…
Funkčné riešenia pre dlhodobé uchovávanie autorizovaných elektronických dokumentov. Špecificky modul MDUERZ ÚPVS nie je jasné aké funkcie v súčasnosti plní a akým spôsobom
… mi to pripomina toho rusa zamestnaneho vo fabrike na sijacie stroje … Ked sa ho pytali ze preco este nema doma sijaci stroj, ved predsa sa obcas nejake suciastky daju vyniest von … A on na to, ze ved obcas vynesiem … ale furt je z toho len gulomet …
Najcastejsie sa meniaci zákon furt menia tí istí ludia… a myslienke jednotného eu trhu sa furt len vzdalujeme genialnymi slovenskymi specialitami …
Trochu nerozmiem tomu ako metoda kliknutia poskytuje vyssie zaruky ako vlastnosrucny podpis.
Vychadzam z toho, ze vlastnorucny podpis = kvalifikovany elektronicky podpis (eIDAS) je podmieneny tym ze privatny kluc je ulozeny na bezpecnom zariadeni a podpisujuci a jedine on ho ma vo svojej moci. Cize vlastnosrucny podpis je postaeny na tejto zasade ktora zarucuje to ze podpis vykonala prave a len tato osoba. V com autorizacia klikom poskytne vyssie zaruky ze klikla prave tato osoba ?
U kvalifikovaneho= vlastnorucneho je legislativny istota vychadzajuca z eIDAS, ze ak je podpis platny tak je iste ze ho vykonala osoba, ktorej po overeni totoznosti vydala CA kvalifikovany certifikat a ako jednina mala pristup k QSCD zariadeniu s privatnym klucom. Cize preukazatelne mame urcenu osobu a kedze nikto iny nema pristup k privatnemu klucu tak mame aj istotu ze ukon urobila prave ona.
Neexistuje legislativna moznost ako preniest moznost pouzit QSCD inou osobou.Podla eIDAS neexistuje moznost popdisania inou osobou bez toho aby boli porusene tieto praidla.
Identifikacia podpisujuceho predsa vychadza z pouzitych postupov Osobna navsteva certifikacnej autority, vystavenie kvalifikovaneho certifikatu osobe na zaklade overenia totoznosti a aky je problem v zistenia si podpisujuceho potom z certifikatu v podpise automatizovanym sposobom? Ved to je len o spracovani certifikatu a udajov z neho. A naviac je tu istota ze ak je podpis platny tak ho mohla urobit len osoba ktora ma QSCD zariadenie vo svojej moci pricom sa legislativne predpoklada ze je to prave ten co mu bol kvalifikovany certifikat vydany.
zavislost na CA, ok ale to sa da zjednodusit. napr. NBU trvale archivuje aj udaje vsetkych CA aj zrudsenych, ak tam ma udaje o vsetkych vydanych kvalifikovanych certifikatoch a ich platnosti, staci potom z retazca vynechat pri overovani tie nadriadene.
technicky je to overovanie sice zlozite ale ked sa raz naprogramuje uz to zlozite nie je lebo postup je stale rovnaky, to co zazivame je tym ze nemame ustalene formaty a ich moznosti ale to sa da riesit, prave zuzenim moznosti vyuzitia formatov. Ktore sice poskytuju velmi siroke moznosti, ale treba to brat tak ze to je iba moznost a pouzitie podpisu smeroat iba smerom k podpisanym datam a overeniu ci je podpis neporuseny, ziadne zbytocne rozsirenia vyuzivanie moznosti ktore smeruju nad tento jednoduchy rozsah funkcionality. cize zamerat sa iba na podpis a data, tie ostatne ficury nepouzivat.
podpisujuci vzdy niesol zodpovednost za to co podpisuje. Podpisovaci softver mu musi dat moznost pred podpisanim precitat v takom tvare a zobrazeni to co podpisuje v akom to ma v hlave. Cize neda sa na stranke vytvarat formular v jednom zobrazeni a pred podpisom mu to zobrazit iba v podobe cisteho textu bez trozlozenia na stranke ako to videl ked to spracovaval.
Tu nejde o to ze nevie overit, to je o tom ze je na nas aby sa znovu vratila povicnnost zobrazit to uzivatelovi v takej forme v akej to vytvaral. Ale to vsetko su len veci praktickej aplikacie podpisovania. A koli tomu tuto moznost zavrhnut sa mi nezda sprane.
Trochu sa mi zda problem ze v nasej legislative sme kvalifikovanej elektronickej pecati priradili ucinok vyssi ako je v nariadeni eIDAS.
Kym u elektronickych podpisov eIDAS dava moznost vnutrostanej legislative vymedzit pravny ucinok s vynimkou zasady ze kvalifikoany podpis=vlastnorucny. U elektronickych pecati tuto moznost neuvadza.
Pricom elektronicke pecate by mali sluzit ako dokaz ze dokument vydala pravdnicka osoba a zabezpecuju istotu iba pokial ide o povod a integritu dokumentu.
My vsak sme pecati pripisali aj ucinok suhlasu s obsahom dokumentu.
(lebo nam to zrejme v danej dobe zjednodusilo autorizaciu uradnych dokumentov?)
V eIDAS nie je ekvivalencia medzi KEP a vlastnoručným podpisom, ale implikácia. Čiže ak na úkone je možný vlastnoručný podpis, (z toho vyplýva že) musí byť použiteľný KEP. Že táto implikácia nefunguje naopak (čiže všetko kde je KEP sa dá nahradiť vlastnoručným podpisom) je asi zrejmé.
K bezpečnostným zárukám vlastnoručného podpisu (odrážky podľa toho dokumentu):
identifikácia konajúceho je iba uvedená v texte, zo samotného podpisu sa vôbec nedá usúdiť kto to podpísal, falšovanie je triviálne a dokonca bežne rozšírené “podpíš to za mňa”
čas vykonania úkonu je iba uvedený v texte, nie je žiadna šanca zistiť či je ten čas skutočný, falšovanie času je triviálne, pri úradných úkonoch sa v podstate na čas autorizácie pri vl.p. nehľadí, dôležité sú iné časy, napr. čas doručenia
integrita úkonu: keďže vl.p. je na poslednej strane, je triviálne predošlé strany vymeniť, keďže vl.p. je ľahké falšovať, dá sa vymeniť aj strana s podpisom, aj bez akéhokoľvek falšovania sa dá v dokumente dopĺňať a škrtať, vcelu rozšírené sú bianko podpísané stránky
nespochybniteľnosť úkonu: vl.p. sa nekontroluje voči ničomu, hockedy môže autorizujúci vyhlásiť že on to nepodpísal, alebo naopak niekto môže podpis sfalšovať
vl.p. je založený na čestnosti konania autorizujúceho a dostatočných obranných prostriedkoch ak sa stane problém - tak kde to nestačí je vyžadované v zákone ešte niečo ďalšie, napr. osobná prítomnosť, zápisnica, osvedčený podpis atď.
Lenže neide o to, že CA vie kto si. Problém je, že to potrebuje zistiť každý kto podpísaný dokument používa. SK hack je kvôli tomu dávať do certifikátu pre eID rodné číslo, ktoré je zákonom zakázané používať. Vzniká šibnutá situácia, kedy v dokumente nesmieš RČ uviesť (lebo ochrana OÚ), ale v podpise vždy je - a nejako to doteraz nikomu nevadilo. Naopak, ak podpíšeš niečo s cert. kde RČ nie je, Tvoje podanie okamžite skončí na neidentifikovaní podpisovateľa. Pritom eIDAS priamo umožňuje v certifikáte nemať žiadne osobne identifikujúce údaje, alebo dokonca pseudonym.
Ale aj toto je stále komplikované. Navyše je to popretie pôvodného zmyslu PKI, ktorý bol ten, aby dve komunikujúce strany neboli závislé “na štáte”. Pritom aktuálne najväčší používateľ KEP je práve verejná správa, čo je samo o sebe paradox.
Akože áno, všetko sa dá nejako riešiť, ale jednak pozri na náklady a dvak načo toto celé? Prečo povedzme keď si niečo kupuješ cez Amazon nemôžeš poslať “kúpnopredajnú zmluvu podpísanú KEP”? Ale stačí kliknúť na “Objednávam”?
Toto je moja najobľúbenejšia odrážka. Presne problém je v tom, že sme hodili celú zodpovednosť na používateľa (a eIDAS to zabetónoval). Pritom používateľ fakt nemá šancu pozrieť sa dovnútra softvéru ktorým podpisuje. Nemá šancu zistiť, či to čo sa mu zobrazuje skutočne podpísal. Triviálny útok je zobraziť používateľovi niečo iné ako sa pošle do QSCD na podpis. Od koho má používateľ nainštalovaný podpisovací softvér? U nás je “štátny podpisovací SW” - čiže ak by tento štát chcel sfalšovať môj KEP, stačí mi pri najbližšom update poslať modifikovaný SW, ktorý podpíše hocičo treba keď najbližšie zadám PIN. Alebo povedzme ten PIN si niekde uloží a ďalej podpisuje kedy/čo potrebuje. Ďalší update zahľadí stopy. Som ITčkar a aj tak nemám šancu (rozumej nemám kapacitu) detailne pitvať čo ten softvér robí. Ty áno?
Po všetkom čo som za posledných 20 rokov videl/čítal o tom ako ľahký je hack podpisovacích SW (môj obľúbený hack bol povedzme vhodne využiť rôznosť default fontov v rôznych verziách OS) som fakt presvedčený, že celý el.podpis bol pokus ITčkarov zabezpečiť technickými prostriedkami vytvorenie dôvery, v ktorom si však pre svoju hru dali srandovné limity, že čo už neriešia.
V tejto situácii je hnusný alibizmus celú zodpovednosť hodiť na používateľa. To okrem iného znamená, že používateľ si na vlastné náklady musí preukazovať keby sa niekde stal problém, napr. aj v prípade útoku ktorý popisujem vyššie.
Ale veď naopak. To čo eIDAS nezakazuje, si môžeš vnútroštátne spraviť ako chceš. KEPečať považujem teraz za dobrý nástroj pre autorizáciu úradných dokumentov.
No, tu mám na mysli najmä OpenAPI, ktoré eIDAS nerieši vôbec.
Ono celkovo to nariadenie vo viacerých oblastiach bol skôr pokus a nie pevné riešenie. A nie prvý pokus. Povedzme kvalifikované doručovacie služby - kto a kde ich má a používa, kto ich potrebuje? Každý štát si spravil vlastné riešenie. A pritom u nás štvrtina zákona 305/2013 je o doručovaní. Stačila jedna veta “použije sa kvalifikovaná doručovacia služba podľa <ref. eIDAS>”.
Povedzme skor ze vsetko co je podpisane KEPom ma hodnotu vlatnorucneho podpisu aj ked sa na dokumente vlastnorucny podpis nevyzadoval.
To je len o tom ze mu treba poskytnut jednoduchy nastroj ktory mu to po klinuti na dokument v zrozumitelnej forme ukaze. Ta “sila” kvalifikovaneho certifikatu je najma v tom, ze sa musi dat dopracovat k drzitelovi- fyzickej osobe, aj v pripade ak mu bol vydany na pseudonym.
Cely PKI system v dobe svojho vzniku bol zavedeny aj z toho dovodu aby sa dalo komunikovat po celom svete bez nutnosti sa stretnut.
Ale v dnesnej dobe na urovni statu mame prehlad o vsetkych kval. certifikatoch NBU (nase certifikaty by sme si vedeli aj jednoduchsie overovat) a na overoanie ostatnych je urceny postup na zaklade trustedlistu EU, cize system na overenie je funkcny a dostatocny.
V dobe ked podpisovanie robila jedna ci dve firmy to problem bol ale dnes uz je sutuacia ina.
Ano suhlasim ze je mnoho typov podani a uradnych veci kde skutocne bude postacovat stlacit "Objednavam
Suhlasim s tebou. Tym ze uz sa nerobi posudzovanie softveru vytvarajuceho podpis tak ako v minulosti, nikde nie je zarucene ze poodpisujeme to co si myslime ze podpisujeme. Naviac je stale viac SW na podpisovanie, kde si mozno vyvojar v dobrom vedomi svedomi nieco vysvetlil inak. eIDAS to prehodil na zodpovednost podpisujuceho tym ze povedl ze podpis je platny dokial to niekto nespochybni. Tym sa otazka spravnosti posunula z vytvarania podpisu na jeho overovanie.
Druha vec je ze NBU pred eIDASom preverovalo nielen to aky je podpis ale aj to ci sa podpisujucemu zobrazuje iba to co v skutocnosti podpisu. Toto je podla mna slabym clankom celeho eIDAS a tiez takato certifikacia musi byt aj pri zarucenej konverzii, kde z padelku v paierovej podobe moze vzniknut “osvedcena kopia” niecoho co nikdy neexistovalo.
Vhodne nastavenymi standardami sa da riziko minimalizovat
napr. PDF/A musi obsahovat vsetky fonty v sebe.
Som aj zastancom aby podpisany el. formular obsahoval v podpise aj transformacne data ktorym formular prezentoval uzivatelovi v dobe ked stalcil tlacidlo Podpisat. Nie len namespace, ale vsetko musi byt ako podpsana vlastnost v podpise. Aj ked nam to sposobi problem s velkodstou sprav. Aby nemohlo ani teoreticky vzniknut riziko podvrhnutia ineho zobrazenia
Naco to potom v pripade elektronickeho podpisu eIDAS vyslovne uvadza? Ked to neni vyslovne uvedene a stat si moze urobit ako chce. Ale potom bude treba sledovat co ktory stat EU aku rolu pripisal pecati lebo ju nebudem vediet spravne interpretovat ak nepoznam vnutrostatne predpisy danej krajiny… Nehovoriac o tom ze suhlas s obsahom tam kde clovek nemusi byt v danom procese spracovania vobec zainteresovany sa mi zda prisilny. Pecat sa zo svojho principu moze pouzivat aj pre automatizovane pecatenie dokuemntov bez zasahu cloveka. Teda ak by islo iba o povod a neporusenost tak v takom pripade je to OK, ale suhlas s obsahom?
Ano tam kde staci potvrdenie povodu a integrity tam je pecat na mieste. Napriklad sa divim ze v zakone o DPH je na prvom mieste spomenuty kvalifoikovany elektronicky podpis tam kde sa uz z principu pyta zdokonalena elektronicka pecat. Ale tam kde sa musi vyjadrit aj vola vyjadrit suhlas s obsahom, tam pecat nepatri.
Mozno co ja viem ak by ta pecat mala nejake atributy ze sa jedna o taku pecat na autorizaciu uradneho dokumenu tak ok.
(Organizacia moze mat aj 100 kvalifikovanych pecati na rozne ucely a kazda z nich sa da povazovat za taku ktora vyjadruje aj suhlas s obsahom, pri tom iba ta jedna je sucastou uzatvoreneho IS kde sluzi na schvalovanie a neda sa pouzit inak ako po prihlaseni sa do tohoto IS a len ako sucast daneho procesu, ostatne iba vyjadruju povod a neporusenost tak ako maju) Cize vonku z organizacie ja netusim ci bola pouzita taka alebo taka pecat a podla egov zakona ma to ani zaujimat nemusi.
Tak prosím uveď konkrétne aký “jednoduchý nástroj” toto zabezpečí.
Ani predošlá certifikácia SW pre podpis to nemohla zaručiť. Malo to aj známe nedostatky, napr. patchovanie vyžadovalo opätovnú certifikáciu…
Nerozumiem. Úplne každá autorizácia je okrem iného prejav vôle (súhlasu s predmetom autorizácie).
Pokiaľ máš problém s automatizovaným vytváraním autorizovaných úradných dokumentov, to sa rieši ináč, nie metódou autorizácie. V skutočnosti predsa každá operácia v počítači je “automatizovaná”, ide iba o rozsah oddelenia “prejav vôle vykonaný človekom” a “okamihom aplikovania operácií ktoré úkon autorizácie zachytia”. Ak napr. databáza (register) obsahuje určité údaje, ktoré sa tam dostali správnym spôsobom, prečo by mal niekto pri každom výpise vizuálne kontrolovať čo sa vydáva? Resp. aj pri tej vizuálnej kontrole čo asi tak môže skontrolovať?
Ad autentifikčané certifikáty pre potreby IS-IS: eIDAS predsa pozná 1. kvalifikovanú elektornickú pečať (len pre P.O.) alebo 2. kvalifikovaný certifikát pre autentifikáciu webového sídla (obdoba systémového certifikátu).
Tieto dva spôsoby sú dokonca vyžadované napr. v článku 34 v rámci RTS SCA od EBA (PSD2 v súvislosti s otvorený rozhraním pre poskytovateľov platobných služieb - PISP, CISP a pod.):
“Na účely identifikácie podľa článku 30 ods. 1 písm. a) sa poskytovatelia platobných služieb spoliehajú na kvalifikované certifikáty pre elektronické pečate, ako sa uvádza v článku 3 bode 30 nariadenia (EÚ) č. 910/2014, alebo pre autentifikáciu webového sídla, ako sa uvádza v článku 3 bode 39 uvedeného nariadenia.”
Vieme ako sa overujú vo všeobecnosti kvalifikované certifikáty automatizovaným spôsobom ku aktuálnemu časovému momentu, najmä ak máme v slovenskej legislatíve povinnosti pre kvalifikovaných poskytovateľov dôveryhodných služieb poskytovať OCSP rozhranie.
Skutočne nerozumiem, prečo vytvárame, vedieme a udržujeme takého registre, keď sa to za ideálnych podmienok realizuje takýmto spôsobom. EBA predsa nebude viesť zoznam certifikátov všetkých poskytovateľov platobných služieb…
To sa neda nikdy ale certifikacny organ preskusal funkcionalitu a ak sa dodrzal navod na pouzitie, podpis bol v poriadku.
To bol ale problem vyrobcu. Verejnosti sa to netykalo, tam iba mala istotu ze podpis je vyhotoveny tak ako ma byt.
nemusi byt ak chces preukazat iba to co pecati prisudzuje eIDAS teda istotu povodu a integrity nemusis dokument ani citat. Jednoducho ho zapecatis. Vtedy sa neriesi ci si s obsahom suhlasil, ale iba to ze dokument pochadza z tvojej organizacie a je neporuseny. Povod a integrita uvadzany tam neznamena suhlas s obsahom. Aj ked v praxi zapecatim spravidla iba to s cim suhlasim.
Cize napriklad u faktur ktore v normalnom papierovom svete sa ani nepodpisuju, by malo stacit zapecatenie faktury, ktore osvedci ze faktura pochadza z danej organizacie a nedoslo k jej pozmeneniu.
No, čl.30.1 hovorí iba o autentifikácii poskytovateľa služby, tam je použitie týchto mechanizmov, ktoré poskytujú vyššie záruky, zmysluplné.
Avšak, ako si si určite pozrel v čl.30.2: “Na účely autentifikácie používateľa platobných služieb rozhranie uvedené v odseku 1 umožní poskytovateľom služieb informovania o účte a poskytovateľom platobných iniciačných služieb, aby sa spoliehali na všetky postupy autentifikácie, ktoré poskytuje poskytovateľ platobných služieb spravujúci účet používateľovi platobných služieb.”
Lebo nie sú “ideálne podmienky”, a lebo manažment kvalifikovaných certifikátov je drahý a nie je dôvod nútiť používateľov tieto náklady znášať.
článok 30 ods 1 a) hovorí o:
“poskytovatelia služieb informovania o účte, poskytovatelia platobných iniciačných služieb a poskytovatelia platobných služieb vydávajúci platobné nástroje viazané na kartu sú schopní sa identifikovať voči poskytovateľovi platobných služieb spravujúcemu účet” - teda tretích stranách ako P.O., ktoré sa musia identifikovať ak komunikujú s bankou (poskytovateľ spravujúci účet). A pre tento účel sa práve predpisuje článok 34 s názvom “Certifikáty” - “Na účely identifikácie podľa článku 30 ods. 1 písm. a)”
Ty na druhej strane spomínaš už čl. 30. ods 2, ktorý hovorí o používateľoch platobných služieb (teda osobách, z ktorých účtu vedeného v banke sa má platiť napr.). Preto účel je diametrálne odlišný.
Tu platí, že tretie strany (poskytovatelia iniciačných sužieb, služieb informovania o účete alebo vydávajúcich platobné prostriedky) sa môžu spoľahnúť na všetky postupy autentifikácie používateľa (rozumej silná viacfaktorová dynamická autentifikácia), ktoré poskytuje alebo ponúka banka (poskytovateľ platobných služieb spravujúci účet používateľovi platobných služieb).
Takže prvé je o vzájomnej identifikácii a autentifikácii IS systémov tretích strán a banky, v druhom o overenie a prejav vôle používateľa s konkrétnou transakciou technologicky neutrálnym spôsobom využívajúcim dynamickú MFA osoby.
na toto sme sa konkretne nbu dopytovali. Dohladovy organ sa spolahol na expertizu v pisomnej podobe od jedneho z expertov, ktorí majp CISSP, alebo ine bezpecnostne certifikaty. Takze v praxi to vyzrera tak ze si firma najde zivnostnika s bezpecnostnym certifikatom a on napise posudok, podla ktoreho NBU vyda “certifikat”. Skuma sa sposob buildovania, bezpoecnost narabania so softverom a ze v nom nie su nejake zadne vratka. O SPRAVNOM VYTVARANI, alebo SPARAVNOM OVEROVANI podpisu ten certifikat nehovori nic. Podla slov NBU ide vlastne o uradne Rozhodnutie (ktore nazvali certifikaciou) podla zakona o spravnom konani…