Vytvoril som jednoduchú cross-platform open-source desktop aplikáciu určenú výlučne na podpísanie a overenie podpisov pre komunitu a seba.
Cieľovka sú jednotlivci, ktorí chcú jednoducho offline podpísať - nie OVM, pokročilí používatelia. Momentálne nie je dostatočne prispôsobená špecificky na použitie v komunikácii s verejnou správou SR - príde čiastočne neskôr. Je plne zadarmo, všetko maximálne otvorené, pod MIT licenciou, nemám žiadnu skrytú agendu a žiaden zisk. Budem rád ak to niekoho zaujme, niekomu to pomôže a za feedback. Dostupné na octosign.sk alebo octosign.com. Upozornenie: je to WIP .
Detaily
Používateľské rozhranie je a zostane zámerne jednoduché - len jedna obrazovka na ktorej je všetko.
Automaticky sa konfiguruje na použitie nainštalovanej aplikácie Slovensko eID ak ju nájde pri prvom spustení. Umožňuje ale cez nastavenia použiť vlastnú PKCS#11, PKCS#12 alebo na Windowse ak sa nevyplní nič použije certifikáty importované do Windowsu (MS Crypto API). Predvyplnený má nekvalifikovaný timestamping server, umožňuje ho ale zmeniť za iný, ak je nevyplnený tak sa nepridávajú časové pečiatky. V budúcnosti bude možné nakonfigurovať autentifikáciu. Nevie zatiaľ robiť LTV.
Z pohľadu formátu súborov pri PDFku použije PAdES, XML envelopne s podpisom v XAdES, ostatné vkladá do ASiC. Voliteľné nastavenie tejto logiky pred podpísaním a zvolenie signature policy príde neskôr. Rovnako ako plnohodnotný viditeľný podpis - momentálne sa dá len najprv vložiť obrázok - “podpísať obrázkom” - a potom podpísať KEP.
Z technologického hľadiska to má modulárny prístup a umožňuje podpísať nielen pomocou KEP (použitím DSS od EÚ), ale aj jednoduchým obrázkom alebo niečím iným v budúcnosti (to sú tie možnosti hore na videu). To niečo iné v budúcnosti si môže ktokoľvek ľahko skúsiť spraviť obalením niečoho existujúceho v akomkoľvek jazyku, ktorý ovláda, do jednoduchej CLI aplikácie s ktorou komunikuje UI. Napríklad v Pythone nejakú klientsku knižnicu na prácu s obľúbeným blockchainom. Je to tiež technológiami a architektúrou pripravené na nasadenie na web (ale bez KEP). Nemá to žiaden server, všetko je otvorené, je tam len proxy, ktorá robí sťahovanie LOTL predvídateľne rýchle a spoľahlivé.
Je to naozaj plne pro-bono a vytvorené pre komunitu, ak by niekto chcel pomôcť tak budem veľmi rád:
Ak to skúsite a nazdieľate spätnú väzbu.
Za informácie ako to funguje v niektorom z iných štátov EEA kde by sa to dalo potom tiež ľahko použit na podpis.
Ahoj, toto vyzera vyborne. Vies co by bol gol? Keby sa podarilo spravit API ktore simuluje oficialny ditec podpisovac a tymto sa to nahradilo napriklad cez greasemonkey na oficialnych weboch.
@andrewsh dokazal takto spojazdnit podpisovanie pre firefox/linux na zivnostenskom registri. Služby živnostenského v Firefox a/alebo Linux keby sa podarilo vymenit ten hnusny ditec podpisovac za nieco opensource / krajsie, tak to by bolo vyborne.
My by sme do navody.digital tiez chceli nejaky podpisovac. Idealne keby bol podla oficialneho sk dizajn manualu. Kuk sem ako by mohol taky flow vyzerat (je komplikovanejsi ale je tam aj podpisovanie).
Tak to by bol vazne gol, s pretrhnutou a spálenou sieťou
Skusal som podpisovanie cez inu kartu (s MQC), vypisal som cestu ku kniznici (tak ako to mam nastavene v dsigneri) a bohuzial (screenshot s chybami). btw., macOS podporuje nativne pridanie digitalneho podpisu (obrazok) Fill out or sign a PDF in Preview on Mac - Apple Support
Ano, ale pre offline podpisovanie je usecase je trosku iny. Tam sa predpoklada, ze vies “co vkladas do podpisovaca”. Pekna vizualizacia je dost velky problem ak chces podporovat vsemozne formaty. Ak sa vsak obmedzis na podmnozinu, tak sa to da zvladnut.
Tym som myslel, ze ten tool je ocividne teraz na offline podpisovanie, cize vizualizaciu nema. Samozrejme ak by doslo k nahradzovaniu, tak bez vizualizacie to nema velky zmysel.
Ahoj, teší ma, že zaujalo. Nad takýmto použitím som ešte nerozmýšľal. Neviem ako sa tam komunikuje, ale myslím, že ditec má niekde dokument k JS API, nie? Ak by som pridal možnosť vyvolať aplikáciu programovateľne a zamedziť používateľovi zmeniť nastavenia v danom režime tak by to mohlo ísť. Neviem zatiaľ ale čo všetko by som tiež potreboval doplniť do samotnej aplikácie aby sa s tým dalo podpisovať - toto by mi muselo byť povedané. Snažil som sa čím viac obmedziť scope v tomto zatiaľ a mať niečo jednoduché - preto som sa až tak tiež nepúšťal do komunikácie s verejnou správou. Bolo by to ale samozrejme zaujímavé. Tiež sám používam IE s .NET keď idem niečo podpisovať. Java verzia mi nefunguje z nejakého dôvodu a nechce sa mi s tým hrať.
Ditec funguje cez localhost server na nejakom porte, kde posles dokument a naspat ho vrati podpisany (vyvola to ten podpisovaci flow. @andrewsh asi vie viac) . Toto je napodiv celkom dobry napad to takto robit (pokym to niekde nezakazu).
K tej chybe pri použití inej karty s MQC: pozriem na to neskôr a bol by som veľmi rád ak by si bol ochotný mi to potom znova testnuť nech zozbieram údaje. Momentálne to neobsahuje debug log, ktorý by som mohol pozrieť. Predpokladám, že problém je so “slotom” v čítačke. Momentálne je tam hardcoded 1 s TODOckom čo sedí len pre SK eID. Otvoril som si bug na githube.
Inak ten otravný warning na macOS je fixed, bude súčasťou ďalšej verzie.
Ak myslíš vizualizáciu XML tak nie, ako požiadavku som si to pre seba nedával. PDF je ako jediné “first-class citizen” a tam pribudne najbližšie aj viditeľný podpis. Do budúcnosti to dokážem pridať ak nájdem niečo otvorené čo mi s tým pomôže - snáď je to len zobrazenie XML so štýlom (XSLT). Nevenoval som sa tomu ale vôbec, takže by som to musel najprv naštudovať - nie zobrazovanie XML, ale čo sa robí pod tou vizualizáciou u nás. Predtým si sa pýtal na otvorenosť kódu ak som dobre postrehol. Kód je na GitHube pre softvér aj webstránku a transparentné a zdokumentované sú aj ostatné veci ako napr. tie moje prvotné požiadavky alebo aj ročné náklady. Ak sa chce niekto povŕtať alebo pokračovať tak kľudne teda môže.
Tu je kód emulátora launchera. Písal som ho v októbri, vtedy som nič nevedel o asyncio/async-await ani o JSON-RPC/WebSockets, preto je to hrozný kód, ale je to len proof of concept.
Najprv sa robí „tanec“ s naštartovaním launchera, web apka otvára ditec-dlauncher://…. Launcher počúva na portoch, ktoré od neho vyžiada web apka. getUrl vydá URL, na ktorom je “control websocket”, cez ktorý ide komunikácia s Java appletom. Je to celé zabalené do JSON-RPC.
Asi sme sa nepochopili. Argument bol, ze to nebude plnohodnotna nahrada (aj ked pre pouzivatela zrejme dostatocna); a to kvoli poziadavke (asi NBU alebo neviem koho), ze podpisovac ma zobrazit vizualizaciu podpisovaneho dokumentu.
Ale pre sukromne pouzitie (pri akceptovani rizika, ze som nevidel co podpisojem) je to asi ok. (Ved viem, co tam davam podpisovat…)
ma umožniť … my to riešime že či to zobrazíš, je na tebe … predsa ked si posielas z agendovej apky nieco co si si pred 30 sekundami pripravil a prezrel, nebudes to zase nasilu prezerat …
Napr. Niekedy ten isty programator ktory napisal podpisovaciu aplikaciu pisal aj softver ktory dokument vyhotovuje.
To je ale uplne jedno. Lebo kedysi povinna poziadavka ktora kedysi vyplvala zo zakona tj. ze si musis precitat to co podpisujes, sa postupom casu zmenila na nieco taketo “podpisovaci softver musi vediet zobrazit dokument ak sa pre to uzivatel rozhodne” NO a ci mu zobrazis tie iste data ktore ides podpisovat dnes nikto uz nekontroluje. Kedysi bolo nutne mat bezpecny prehliadac v podpisovacej aplikacii, ta sa certifikovala a pri tom sa kontrolovalo aj ci prehliadac zobrazuje to co sa podpisuje. Tym ze kontrola dnes neexistuje je iba na vyvojarovi ako to zaisti. Ditek podpisovac to ma pekne implementovane a dobry podpisovac by to aj mal robit, pokial neni sam sucastou niecoho vacsieho co tuto schopnost ma samo o sebe.
Ak sa nejedná o dynamicky generovaný dokument tak v tom nevidím až taký význam. Očakávaný scenár je, že mám PDF, ktoré som si prečítal a po prečítaní ho vložím do aplikácie a podpíšem. Viem si to ešte predstaviť pri tých XML ak ich vizuálna reprezentácia sa nedá ľahko získať a preto je to ťažšie “otvoriť” pre používateľa pred podpisom. Taktiež v tom vidím zmysel pri ASiC kedy používateľ nemusí vedieť ako pozrieť súbor v kontajneri.
Z technického hľadiska zobraziť PDF nie je problém, XML by teda tiež šlo do istej miery ak je rozumne spravená vizualizácia transformáciou (XSLT na HTML. napr.), pre ľubovoľné non-plaintext formáty to ale nie je IMHO veľmi rozumné/ľahké handlovať v aplikácii - prečo neotvoriť predvolenú aplikáciu používateľa pre ten súbor?
Ak chceme zamedziť upraveniu v čase od prezretia po čas stlačenia Podpísať, tak inú možnosť ako nutnosť držať v pamäti - pokiaľ sa nespoliehame na filesystem permissions/locking - nevidím, jedine, že by to len končilo chybou nesúhlasiaceho hashu.
Je to ale zaujímavý input, ďakujem. Mňa osobne viac trápi to upozornenie alebo celkovo vyvolanie pocitu dôležitosti stlačenia tlačidla Podpísať (známy z papiera), ktoré neviem ako správne vyvodiť aby to bolo naďalej jednoduché a nerušivé.
v scenari ze mas svojich dodavatelov ktorym veris (agendova apka, podpisovatko), ze kazdy mesiac podpisujes napriklad 100 rozhodnuti, tak ti to garantuje napriklad skusenost a dovera … To je najcastejsie viac ako predpis.
XSLT transformácia pre vizualizáciu podpisovaného súboru sa nastavuje pri inicializácii D.Signera v javascripte ako Base64 encodnuté xsltéčko (buď to z mefu alebo ak to mám lokálne tak načítam na základe metadát xslt, ktoré má uvedené použitie na sign). Ak riešenie od andrewsh vie posunúť parametre z D.Signera, malo by byť triviálne aplikovať XSLT transformáciu (ktorá by došla do appky zvonku) pre podpisované xmlko.
Inak info tu: https://www.ditec.sk/produkty/informacie_pre_integratorov_aplikacii_pre_kep
.
čo sedí len pre SK eID. Otvoril som si