Komisia pre štandardy ISVS - PS4

Obe veci su od NASES-u. Detaily zial neovladam a moj high-level nazor je “takmer cele zle”. Spytaj sa teda prosim rovno v NASES-e.

V Nasese sa v poslednej dobe veľmi zle “pýta”. Práve na to je PS.

OK, budem davat vacsi pozor.

Firma co ho dodala uz neexistuje … (a licencny server je najskor asi vypnuty … ) :slight_smile: aj take veci sa stavaju. Preto ho treba kupit aj so zdrojovym kodom.

1 Like

Prosim nie. Cela zemegula riesi responzivny web a my to ideme zase rozsekavat na dva kusy?

Na 18.11.2020 je ohlasene 10. zasadnutie PS4 (vid https://metais.vicepremier.gov.sk/standardization/meetingdetail/55 ) pricom v programe je nateraz najma:

  • Návrh štruktúry pre potvrdenie autorizácie vykonanej podľa § 23 ods. 1 písm. a) bod 2 zákona o e-Governmente (tzv. “autorizácia klikom”)” (podrobnosti zatail nezaslali, prislubene na neskor, ale teda pred 18.11.)

Zasadanie bude spojene s 9. zasadnutim PS2 ( Komisia pre štandardy ISVS - PS2 - Bezpečnostné štandardy ).

1 Like

18.11. 2020 bolo teda spolocne zasadnutie PS2 a PS4, zapis je tu: MetaIS

16.12.2020 sa konalo dalsie on-line zasadnutie PS4. Zapis: 12. zasadnutie PS 4 - zápis - PS4 - technické štandardy - Confluence

Niektore z bodov uz sli aj do KS ISVS, vid hlasovanie spomenute tu: Komisia pre štandardy ISVS - #54 by hanecak

Dnes bolo spoločné stretnutie PS2+PS4, program:
2) Návrh atribútov JSON Web Token používanom s protokolom REST a OpenID Connect pre použitie s API GW bod 2_spoločného zasadnutia_ JSON Web Token.docx (41.8 KB)
.
3) Návrh na používanie špecifikácie Canonical XML 2.0 pri výpočte digitálneho odtlačku doručovanej správy v doručenkách
bod 3_spoločného zasadnutia_Canonical.docx (25.5 KB)

Za mňa takto:
Ad 2):

  • chceme vidiet cele scenare pouzitia, z pohladu specializovaneho portalu a z pohladu externej appky
  • v scenaroch primarne postupnost volani API a ich atributy
  • k tomu ^ chceme vidiet aj dlhodoby plan, ako sa “postupne” maju veci menit, jasne ze od nejakeho casu dalej tam bude ze este nevieme presne ako
  • identity:
    • propagovane nech su centralne identity,
    • ak sa pridava nieco nove (napr. prihlasenie cez fb), nech sa to primapuje k centralnym identitam na upvs
    • nech su jednotne identifikatory pre fyzicke osoby na medzisystemovu identifikaciu,
    • je mi jedno co to bude, nech si MV povie co chce
  • qaa: nech sa da do planu priamo aj prechod na urovne podla eIDAS a zrusenie slovenskych

Itas toto vidi podobne.

Ad 3):

  • odtlacok v dorucenke je dolezity, urcite ho nerusit
  • vytvaranie dorucenky sa tyka nielen UPVS/CEP, ale aj OVM ktore CEP nepouzivaju, pritom dorucovania mimo schranok bude stale viac
  • nech objekt, z ktoreho sa odtlacok pocita je spracovavany na bit presne ako bol odoslany
  • nech si aj odosielatel vie overit dorucenku
  • je mi jedno ci tento objekt je presne iba “podanie”, alebo aj cast “spravy” okolo toho, ale nech je to taka vec, ktoru odosielatel vidi = moze overit

API v súčasnosti začína byť jeden z najpoužívanejších vektorov útoku. Bol by som rad keby sa toto prizvukovalo, mam pocit ze zatiaľ sa tomuto aspektu nevenuje dostatočná pozornosť.

1 Like

Zajtra (16.3.) je stretnutie PS4+2 k novým nápadom Mirri na spôsoby autorizácie. Program:

Myslienka, ze sa bude vyuzivat certifikat na eID aj po tom co nosič a jeho čip budú vyradené zo zoznamu QSCD a takto vykonaný podpis sa od času Č zmení z KEP na zdokonaleny ma jednu technickú vadu.
A síce certifikát (napríklad na eID) má v sebe príznak že je uložený na QSCD.
Preto museli aj kvalifikovaní poskytovatelia zneplatniť tie certifikáty dňa 16.12.2021 na karách CardOS 4.4., lebo po tomto dátume by inak niesli v sebe klamlivu a chybnú informáciu, že stále sú uložené na QSCD.
Čiže ak HW na ktorom je privátny kľúč a certifkát skončí ako QSCD (stratí certifikáciu), dá sa naďalej používať, ale je potrebné na neho certifikát a privátny kľúč znova vygenerovať (už bez príznaku QSCD). Takto potom môže vytvárať zdokonalené podpisy založené na kvalif. certifkáte. Určite ale nie s pôvodným certifikátom, ktorým sa vyttváral KEP.

Neplánuje sa využiť pôvodný kvalifikovaný certifikát pre KEP z eID, ale “na diaľku vydať nový”, je to v tom dokumente uvedené, ale bez hocakých detailov.

Za nás stanovisko:

K obom bodom na nové spôsoby autorizácie:

  • Ide o natoľko zásadné zmeny, že odporúčanie pre ich riešenie nemá byť predmetom rokovania pracovných skupín pre štandardy ITVS, ale pracovných skupín pre strategické priority NKIVS, odporúčame PS Lepšie služby a PS Kybernetická bezpečnosť. Na tejto úrovni má byť identifikovaná a odsúhlasená stratégia v oblasti identifikácie/autentifikácie/autorizácie (IAA - tieto 3 oblasti spolu tesne súvisia), ktorá môže byť následne z hľadiska legislatívneho a technického prevedenia prediskutovaná v PS pre štandardy.
  • Sme zásadne proti takto čiastkovým legislatívnym zmenám, ktoré však budú mať zásadný dopad na VS v oblasti autorizácie, najmä ak verejná správa a obzvlášť MIRRI+Nases nevyužívajú ani v súčasnosti existujúce možnosti z legislatívy plynúce. Zároveň žiadame pripraviť a prezentovať celkový koncepčný pohľad a plán pre oblasť IAA, ideálne na plánovacie obdobie NKIVS, t.j. do roku 2026.
  • Žiadame MIRRI+Nases aby urýchlene zaistili možnosť realizácie autorizácie použitím na to určenej funkcie IS (tzv. autorizácia klikom) podľa §23 ods.1 písm.a) bod 2. ZoEG pre podania autorizované na ÚPVS, najneskôr do konca roka 2022. Skutočne nerozumieme, prečo sa mrhá kapacitou na vymýšľanie „nových nápadov“ ako sú prezentované v zaslaných materiáloch, namiesto sústredenia sa na implementáciu toho, čo už v legislatíve je zakotvené a je na tom všeobecná zhoda.

K bodu 2, návrh na akceptáciu zdokonaleného podpisu (AdES):

  • Ako jediný dôvod pre tento návrh je uvedené ukončenie možnosti používania eID vydaných pred 25.6.2021 ako QSCD po 31.12.2022. Tento hraničný termín je známy už viac ako rok. Žiadame MIRRI, aby neodkladne pripravil a prezentoval koncepčný plán zvládnutia tejto situácie. Pripomíname, že v niektorých predpisoch je osobitná úprava autorizácie, kde všeobecné riešenia nepomôžu, napr. autorizácia v rámci daňového poriadku.
  • Za podstatnú súčasť riešenia situácie po 31.12.2022 považujeme umožnenie využiť autorizáciu klikom.
  • Sme zásadne proti zavedeniu plošnej povinnosti akceptovať zdokonalený podpis pre všetky OVM. Stručne povedané, AdES má všetky nevýhody KEP a ešte niektoré ďalšie. Špeciálne upozorňujeme na to, že identifikácia subjektu, ktorému bol certifikát vydaný, je automatizovane prakticky nerealizovateľná. Pripomíname, že riešenie tohto problému pri KEP je uvedené v §2 ods.1 zákona č.272/2016, umožňujúce uvádzanie rodného čísla v certifikáte, pričom pri schvaľovaní tejto úpravy MVSR argumentovalo, že bez tejto možnosti nie je možné plošne vydávať certifikáty pre KEP s rodným číslom. Pre zdokonalený podpis takáto úprava neexistuje. Pripomíname, že nariadenie eIDAS zakazuje povinnosť uvádzať v certifikáte identifikátory a dáva držiteľovi možnosť v certifikáte uviesť dokonca namiesto mena pesudonym. Problém „so zahraničnými podpismi“ sa týka nielen nových formátov, ale aj zásadného rozšírenia okruhu akceptovaných certifikátov.
  • V materiáli nie je pripojená analýza čo i len odhadovaných potrebných zmien, harmonogramu a súvisiacich nákladov spojených s vydávaním nových certifikátov, zamýšľaných pre zdokonalený podpis.
  • V súčasonosti eID obsahujú aj iný podpisový certifikát ako pre KEP, prosíme o detailnú informáciu, či je tento certifikát použiteľný pre vytváranie zdokonaleného podpisu. Upozorňujeme, že v týchto certifikátoch nie je uvedený univerzálny identifikátor držiteľa.
  • Žiadame túto legislatívnu zmenu nerealizovať.

K bodu 3, návrh na tzv. fikciu autorizácie:

  • Nerozumieme dôvodom, prečo má byť zavedená takáto forma autorizácie.
  • Ak má ísť o riešenie výlučne pre ÚPVS, nie je jasné, prečo namiesto implementácie autorizácie klikom Nases plánuje takúto legislatívnu zmenu, navyše ak rozdiel medzi autorizáciou klikom a navrhovanou fikciou autorizácie je minimálny.
  • Žiadame túto legislatívnu zmenu nerealizovať.
1 Like

Navrh noveho sposobu autorizacie
Nebolo by lepsie miesto
• fikciu autorizácie nebude možné použiť, ak jej použitie osobitný predpis zakazuje.
uviesť
• fikciu autorizácie nebude možné použiť, ak osobitný predpis vyzaduje iny sposob autorizacie?.

K tej otazke 1 v analyze ze
Môže mať na národnej úrovni zdokonalený elektronický podpis v zmysle
Nariadenia eIDAS rovnocenné účinky s vlastnoručným podpisom?

Ano stat si moze urcit ze aj podpis s nizsou urovnou ako KEP moze byt povazovany za vlastnorucny.
Len to ma nevyhodu v tom ze to co u nas budeme povazovat za vlastnorucny sa nemusi povazovat za vlastnorucny v inom state EU, ktory neprehlasil zdokonaleny podpis zalozeny na kvalifikovanom certifikate za vlastnorucny. Bolo by potom treba tomu urobit aj prislusnu osvetu aby sa niekto takto medzistatne na to potom nespolahol a neprisiel k problemu v inej krajine.

Trochu sa pri tom zrovnavani pozabudlo na to ze sice ano podpis vyjadruje volu atd atd, ale u KEPu ako vlastnorucneho podpisu je velmi silny argument prave to ulozenie a ochrana privatneho kluca na tomto zariadeni. Cize ta vlastnorucnost je akoby zosilnena tym, ze privatny kluc je vo vyhradnej moci podpisujuceho.
Napr. ked mam certifikat na QSCD zariadeni ku ktoremu mam PIN povedzme 6 miestne cislo, tak ten kto by chcel moj privatny kluc zneuzit po troch pokusoch o zadanie pinu zariadenie znepristupni.

Ale ak mam kvalifikovany certifikat spolocne s privatnym klucom ulozeny povedzme v PFX subore ktory je tiez chraneny 6 miestnym PINom, staci zneuzivatelovi softver, ktory tych 1 milion moznosti spravneho najdenia pinu vyskusa. Z jedneho PFX suboru si moze urobit 1000 kopii aby sa mu lahsie hladal spravny pin. Cize toto uz podstatne oslabuje tu “vlastnorucnost” a hlavne schopnost mat svoj privatny kluc vyhradne vo svojej moci. Cize toto by asi chcelo trochu viac o tom diskutovat nielen z pravneho hladiska ale aj z hladiska praktickeho a technickeho.

v ČR je takto možné len dávať podania na OVM. Smerom z OVM to už musí byť KEP + QTS

Hrubé poznámky:

problem revokacie cert. na starsich eID

  • bude upravena aplikacie pre eID aby upozornovala usr. ze cert. budu revokovane
    • riesi sa aky text/odporucanie sa zobrazi
  • na eID sa “zablokuju certifikaty” tak, aby sa nedali pouzit
    • cim odpadne problem ze budu vznikat neplatne podpisy
    • Nases vidi denne 10ky podpisov s revokovanym certifikatom
    • v niektorych konaniach usr. nikto na toto neupozorni
    • S.D: sme proti automatickemu zablokovaniu
  • obstaranie novej podpisovacej aplikacie, ktora umozni kontrolovat platnost cert.
    • je spusteny projekt, ale nevedia ako dopadne / ci vcas
    • dnes podpisovacia app. na UPVS nezobrazi varovanie pri revokovanom cert
  • pripravuje sa zmena podatelne UPVS ze sa bude zasielat odosielatelovi info ak podpis bol neplatny
  • bude musiet niekolko 100tisic obcanov vymenit si ob.preukaz ak zostane povinnost podisovat KEPom
    • DXC: aktivnych pouzivatelov KEP je teraz 290tisic
    • Disig: teraz aktivnych “starych” cert pre KEP je 410tisic

teraz vydavane eID maju platnost cert. QSCD do juna 2026
NFC eID tiez bude platnost certifikacie max. 5 rokov, limituje to eIDAS
AdES to ma byt “prechodne riesenie”

  • ze za 2 roky tu ma byt elektronicka penazenka, ktora moze robit KEP
  • alebo aj remote signing
  • “potom sa mozeme vratit primarne ku KEPu”

Itas je proti plosnej povinnosti OVM prijimat doc. autorizovane AdES
na centralnej urovni je neimplementovanetlne automatizovane rozoznamvat vsetky formaty AdES

pracuje sa aj na tom aby sa autorizacia klikom dostala do praxe

  • v ramci SvM bude mozna aj autorizacia z mobilu
  • nieco sa riesi ze bude pomocou remote signingu ??
  • S.D: autorizacia klikom nie je viazana na SvM, v zakone je to roky, nech to Nases konecne spravi
  • S.D: ocakavam ze Mirri povie pevny datum kedy aut.klikom na UPVS bude funkcna a to najneskor 1.1.2023

sucasny cip na eID- je predlozenia ziadost o predlzenie certifikacie o 1 rok

  • a ocakava sa, ze sa bude predlzovat

dnes existujuce nie-KEP cert. na eID sa daju pouzit na vytvorenie AdES

  • ale ich CA nie je v trusted liste eIDAS, cize to bude AdES bez kvalifikovaneho cert.
  • tieto certifikaty sa nebudu revokovat na konci 2022

Skor som to dnes pochopil tak, ze aktualny cip (CardOS 5.4) resp. certfikacia bola udelena na 5 rokov (povodne do 17.6. 2025) a uz bola platnost certifikacie raz predlzena minuly rok znova na max obdobie 5 rokov (nova doba platnosti do 28.9.2026).

Teda zatial platnost do 28.9.2026… Max dobu platnosti (tych max 5 rokov) a sposoby predlzenia neurcuje eidas, ale certifikacna schema, ktora stanovuje ramec a spolocne postupy certifikacie produktov, uznavanie certifikatov atd. vid napr. odkaz sog-is, alebo aj odkaz CCRA

Áno presne tak, nejasne som to napísal.