Vyvojari: Kvalifikovana elektronicka pecat server riesenie

Ahojte,

potrebujem vytvorit riesenie ktore bude podipsovat zip subory na serveri (podpis CAdES), ktore budu nasledne posielane do statu. Vacsina rieseni, ktore som nasiel funguju vo webovom prostredi, ale nedokazem sa dopatrat k nicomu pouzitelnemu, co by fungovalo na serveri bez interakcie s pouzivatelom.
Vedeli by ste ma prosim nasmerovat k API (idealne Java, ale budem rad za cokolvek) ktore by som vedel pouzit na podpisovanie na serveri ?

Zatial som sa najblizsie dopracoval k nasledujucim linkom:
Vyvojari: postup ako implementovat podpisovanie cez ZEP - webove riesenia
Disig QES Signer - vyzera ze je to platena sluzba (v com nevidim problem), ktora podporuje len windows + Web services :frowning:
sipvs - 4 roky stary studentsky pokus z FIITky, ktory vola .NET dll kniznice z D.Signer/XAdES - najviac sa priblizuje tomu co potrebujem

Tiez som si prebehol prirucku integratora D.Signer-XAdES (package sk.ditec.zep.dsigner.xades
.*), ta ale vyzaduje interakciu pouzivatela cez dialogove okna.

Dakujem za pomoc

Toto je komplikovana problematika. Cim to podpisujes? eID? mandatny certifikat? pecat? Masovo? Jednorazovo? Od toho zalezia riesenia.

Cez pecat sa to da podpisovat napriklad priamo cez integraciu na UPVS. Kuk sem

https://generator.swagger.io/index.html?url=https://dev.premium-slovensko-sk-api.staging.slovensko.digital/openapi.yaml

Ten tam CAdES ma nejaky specialny vyznam?

Dakujem za rychle odpovede,

Toto je komplikovana problematika. Cim to podpisujes?

Vizia je taka, ze si zabezpecime elektronicku pecat a budeme mat zabezpeceny server, ku ktoremu bude pripojena citacka s pecatou. Tento server budeme pouzivat na podpisovanie zip suborov, ktore nasledne posielame do statu. Tento navrh sa vsak moze menit.

Prebehol som si swagger ktory si posielal a resource /api/cep/sign vyzera velmi zaujimavo. Akym sposobom sa ale v takomto pripade riesi bezpecnost ? Ako sa dostanes k pecati, ktora sa pouzije na podpisovanie ?

Ten tam CAdES ma nejaky specialny vyznam?

Podpisuje sa binarne ZIP, preto CAdES. Je to taktiez poziadavka statu:
Pri pečatení súboru prevádzkovateľ označí súbor kvalifikovanou elektronickou pečaťou vo formáte CAdES alebo kvalifikovaným elektronickým podpisom.

Pecat je v HSM na UPVS, ty k tomtu pristupujes cez API, cez svoj kluc + cele to je cez ipsec tunel. Je to taky hack, ale normalne je to sluzba UPVS.

Ktory manual citujes?
Zaujima ma to lebo pri kvalifikovanej elektronickej pecati by nemalo byt pozadovane ze musi byt cades alebo xades. Podstatne by malo byt to ze je to kvalifikovana pecat a stat musi overit aj XAdES aj CAdES. To ci ty budes oznacovat pecatou CAdES alebo XAdES toto by ti nemal nikto predpisovat. Zvlast nie stat ktory je povinny overit aj aj.
Mozno je to prirucka niektoreho konkretneho systemu, ktory pecati pomocou cades, ale neviem o obmedzeni ktore by predpisovalo ze kvalifikovana pecat musi byt iba ten ktory konkretny format.
Cize mozno to co potrebujes je pecatenie kvalifikovanou elektronickou pecatou vo formate ASiC-E na baze bud XAdES alebo CAdES. Vysledkom toho je subor asice, ktory je zip suborom.

Ditec aplikacia vzdy vyzaduje UI a interakciu uzivatela, aj vacsina aplikacii vyzaduje interakciu s uzivatelom, ak si to chces napisat sam tak existuje na bazi java skoro hotova vec ktoru zabezpecila EU vola sa DSS, ale aj tam treba nejake muchy vychytavat kedze u nas su urcite poziadavky na podpis, ktore treba aplikovat a to si vyzaduje aj trochu studia. Alebo sa obrat na vyrobcov podpisovacich aplikacii a ti maju aj aplikacie na take ucely ako pozadujes.
Potom este je moznost vyuzit funkcie CEP UPVS ale to vyzaduje bud sa integrovat alebo niekoho kto ta integruje pomocou svojho riesenia. Zalezi aj od toho kde sa bude nachadzat privatny kluc ak v tvojej organizacii mas moznosti viac, ak v HSM v NASES tak len cez integraciu.

Mozno hlupa otazka, ale aby mi to bolo uplne jasne, klucom myslis heslo, alebo hardwarove zariadenie ?
Dalsia vec ktoru som zabudol spomenut je ze zip ktore sa podpisuje bude mat stovky MB - kludne aj 500 MB. Predstavuje to nejaky problem ?

Je to dane samostatnou vyhlaskou, ktora firme nariaduje posielat interne data do statu. Generujeme vela xml suborov -> zipujeme -> sifrujeme -> podpisujeme

Je tam riesena aj integracia s HW citackou / USB tokenom ?

No prave to je to ze stat ktory je POVINNY vediet overit kazdy format podpisu a pecate predpisuje ze iba CAdES - zrejme ide o nedokonalost apliikacie na strane statu a pravnicke osoby su nutene do toho aby to bol iba taky podpis ktory na dany OVM ma svoju aplikaciu, ale jeho povinnost je jeden podpis robit a vsetky overovat.

K tomu DSS neviem ti poradit skus sa spytat v podpisuj,sk oni to podla mna maju pekne poriesene.
Lebo aj ked to rozbehas este je riziko ze podpis sice bude v pohode co sa tyka eIDAS ale bude mat problemy s overvanim v CEP, cize tymto problemom sa da vyhnut pouzitim riesenia ktore uz tie muchy vychytalo. S CAdES om nemam skusenost ale XAdES bolo treba urcite upravovat ten nim vytvoreny nebol u nas overitelny.

Hw zariadenie je u nich. Ty máš len kľúč k api.

Čo sa týka 500MB. Teoreticky by to nemalo vadiť, veď podpisuje sa vždy len nejaký hash a nie obsah súboru avšak neviem ci takéto nizkourovnove api vystrcili von. Zdá sa mi ze nie. @pzbell vieme zistiť od NASES? Príde mi to celkom normálna požiadavka.

Asi mas namysli toto či niiečo iné:
5.4 Využitie kvalifikovanej el. pečate ako prostriedku na autorizáciu el. správ
Inštitúcie VS majú možnosť využiť elektronickú podateľňu ÚPVS (Modul CEP) ako vlastnú podateľňu. Pokiaľ agenda inštitúcie explicitne nevyžaduje autorizáciu el. správ - podaní/rozhodnutí vlastnoručným podpisom je možné na podpísanie využiť v zmysle zákona 215/2002 Z. z a 305/2013 Z. z aj Kvalifikovaný systémový certifikát (KSC) umožňujúci vytváranie kvalifikovanej elektronickej pečaťe (ZEPe). ZEPe je zároveň možné využiť v prostredí ÚPVS na autorizáciu technických správ, ktoré vyžadujú na vstupe el. podpísanú žiadosť. Na tento účel modul CEP podporuje funkcionalitu registrácie KSC v certifikovanom zariadení podateľne. Na stránkach portálu NBÚ je vedený zoznam akreditovaných certifikačných autorít (ACA), ktoré môžu podpisové – technické certifikáty vytvoriť.

To je zrejme určene iba pre OVM. Toto asi neurobi pravnicka osoba.

PS. ta prirucka stale obsahuje nazvy z historie ale je platna.

Technicky tam asi nebude ziadny problem, ze by to nemohlo byt aj pre PO, ale tipnem tiez, ze klasickej PO (nie OVM) to len tak nedaju. Skusime overit v NASES. V integracnych manualoch na prve pozretie nevidim nic explicitne.

Myslím, že ide o hardvérové obmedzenie podateľne (máme podobné obmedzenia na inom projekte), ale ako môžte skúsiť aj väčšie, som zvedavý ako majú nadimenzovanú podateľňu na upvs. Keďže čím väčší súbor, tým viac RAM sa mi zdá.

Pri podpisovaní hashov ide podľa mňa o integritný podpis (nie som expert, možno niekto z podpisuj.sk sa vie k tomu vyjadriť).