3 posts were merged into an existing topic: Elektronické voľby sú zlý nápad
Passkey vytvoreny na Mac Studio, automaticky funguje na iPhone/iPad/Macbooku. Podpisovanie na macOS cez to neviem vyskusat, kedze pouzivam Autogram a tam to zatial ide len cez citacku a Autogram v Mobile.
Podpisovanie na iPhone v poriadku, je mozne vyber medzi xades a pades. Ocenujem, ze ako default je pouzity pades, snad sa to viac rozsiri. Je mozne pridavat aj viac podpisov.
Co ale nechapem je, ze nieje mozne pridavat kvalifikovane casove peciatky. Z tohto dovodu ostavam nadalej pri Autogram v Mobile / Autogram (ajked stale neviem v Safari rozbehat Auogram v Mobile podpisovanie, vo Firefoxe mi to funguje).
Je tam priestor na zlepsenie, napriklad by som vcelku ocenil, ak by som vedel iniciovat podpisovanie na iPade s tym, že na iPhone by som vykonal autentifikaciu a autorizaciu pri eID.
Dalsou vecou je, ze by nebolo zle, ak by to podporovalo nielen eID, ale aj ine certifikaty, konkretne custom eIDAS certifikaty vydavane certifikacnymi autoritami v EU, cochvila chcem vyskusat mandatny certifikat vydavany od První certifikační autorita, a.s. (StarCos 3.7 NFC)
1 Like
Pozor na zelania, niektore sa mozu aj vyplnit. PAdES je asi najviac pruseroidny format zo vsetkych. A teraz si stat este vymyslel, ze do PDF bude vkladat tzv. embedded subory, napr. XML, co je ale celkom pekny pruser, pretoze ten kto podpisuje, nevidi to co je vlozene, ale podpise to. Vlozene XML sice moze sluzit na automaticke spracovanie toho, co to PDFko zobrazuje, ale nikto neriesi, ak sa tie dve veci budu lisit. O utokoch na PAdES, ktorych je evidentne najviac, ani nehovorim. Ale chapem, ze uzivatelia to vedia otvorit a citat a dokonca chcu, aby tam mali aj vizualny podpis, aj ked po technickej stranke im nic nezarucuje a v nicom nepomaha.
1 Like
PSA
Na stranke sluzby.orsr.sk sa nieje mozne autentifikovat s mID passkey, hádže chybu:
Problém je, že tam ani nieje pre užívateľa možnosť alternatívnej autentifikácie. Jednoducho sa musíte prepnúť na stránku slovensko.sk a tam sa odhlásiť. Následne je ale možné sa autentifikovať pomocou Slovensko v Mobile 
Je to na zaplakanie.
Njn, to nespochybňujem, ale je to najrozšírenejšia forma komunikácie a je akceptovaný skoro všade, narozdiel od xadesu. Riziká sa nájdu všade, pre aj proti. Ale určite existuje možnosť, ako rizikám predísť, v opacnom prípade by sa ten formát nepoužíval a všetci na svete by použivali xades, nie? ten XML je ale aj v Xadese a okrem toho, ak sa použije QTS a zaroven generacia XML suboru spolu s podpisom pades, tak to asi tazko zmodifikujeme.
Toto su porodne bolesti, uplne rovnako tomu bolo aj pri SVM. Pamatame sa nie?
Tam nejde o modifikaciu toho xml po podpise, ale pred nim. Staci do PDF vlozit dotaciu za 10.tis a do vlozeneho xml za 100.tis, to vlozene nikto nevidi, ale obsahovo sa podpise aj PDF aj vlozene XML. Strojovo sa spracovava to vlozene xml. Ak to niekto vie, tak vo vysledku sa mozes pokusit o podvod. Obsah vlozeneho suboru podpisujuci nevidel.
Podobny pripad uz nastal, aj ked neslo o podvod ale chybu. Nepouzila sa pre zobrazenie schema pouzita pri podpise, ale vizualizacna. Ta vizualizacna bola OK. Ta podpisova obsahovala zrovna chybu a vkladala do sumy kod nejakeho policka. Cize podpisujuci podpisal nieco uplne ine - to co videl, ako sa vo vysledku zobrazovalo v schranke prostrednictvom vizualizacnej schemy.
2 Likes
toto sa inak stava dost casto, programator sa sekne a zmenu vo vizualizacnej scheme nepremietne do podpisovej a problem je na svete. my odporucame aj pre podpisovanie pouzivat vizualizacnu schemu prave kvoli tomuto.
- Nesúlad XML s vizuálnou častou je aplikačný problem, nie problem pades štandardu
- Spravne validatory toto predsa overia
- Taktiež samotná legislatíva môže pomôcť pri správnom nasadení a vymáhaní
- Xades aj pades majú moznost implementovať xml a rovnakým spôsobom je možné podpísať xml s iným grafickým obsahom bez rozdielu.
- Pades ako format zaručuje podľa mna omnoho dlhšiu lehotu validacie a ma definitívne prednosti. To že sa xml+pdf používa už tak dlho len potvrdzuje, že sa “problémom” sa predísť správnou implementáciou.
Takze v konečnom dôsledku je Xades len zbytočnou bariérou a preto som za pades
my odporucame aj pre podpisovanie pouzivat vizualizacnu schemu prave kvoli tomuto.
Toto by bolo na samostatnú diskusiu, či to je správne odporúčanie.
NASES síce tvrdí, že balíčky kontroluje, ale žiaľ nie raz sa “chybička vloudila”. No a pri tom PDF-ku sú vkladané súbory len ďalší potenciálne vektor útoku okrem všetkých tých, ktoré už existujú. Je tam minimálne ešte jeden ďalší, ktorý som zámerne verejne neuviedol a ten je podstatne horší ako to, že vložené xml-ko nesedí s obsahom vizuálu v dokumente. Osobne by som vrele neodporúčal podpisovať PDF dokumenty, ktoré obsahujú prílohu a ak, tak veľmi veľmi obozretne.
1 Like
Prepáčte, ale dovolím si nesúhlasiť. Okrem bodu 1 sú to skôr zbožné želania, ako realita. Ale úplne rozumiem tomu, že z pohľadu koncového používateľa je PAdES najlepšia voľba. Z pohľadu formátu a toho, na čo bol primárne ten formát určený, je to pri elektronickom podpise nočná mora.
1 Like
Volali mi z helpdesku MSSR, tak sme si prešli celý proces a zistili sme, že netušia, že už existuje možnosť prihlasovania cez MeID 
Tragikomické. Pani na helpdesku mi jednoducho povedala že im všetko ide a mám sa sťažovať na slovensko.sk
Pokračovanie:
“Dobrý deň pán …,
pre prihlásenie sa k elektronickým službám Ministerstva spravodlivosti SR je potrebné použiť elektronický preukaz s čipom, aplikáciu Slovensko v mobile alebo prihlasovací prostriedok vydaný v niektorej z krajín EÚ. Bližšie informácie k uvedenému spôsobu autentifikácie (MeID) k službám Ministerstva spravodlivosti SR Vám poskytnú na kontaktných údajoch uvedených v ozname o chybe, ktorú ste nám zaslali v prílohe.
https://www.justice.gov.sk/pomoc-a-podpora/
S pozdravom
Ústredné kontaktné centrum
UPOZORNENIE: Aby bola Vaša správa korektne doručená, predmet neupravujte.”
No to je celkom pekny prusvih. Vase odporucanie aspon z casti redukuje rizika tohoto velmi zle vymysleneho sposobu podpisovania xml formularov. Len ci to neni v rozpore s vyhlaskou kde sa pise kedy ktoru schemu pouzivat.
Cely system je uplne zle. Lebo nikde nie je ani legislativne ani technicky zaistene, ze od vlozenia xml do datacontainera pred podpisanim az po konecne zobrazenie dokumentu druhej doverujucej strane sa pouzije rovnaka schema.
Overovac podpisu overi platnost asic podpisu, ale uz je na vyvojarovi aplikacie pomocou akej schemy zobrazi dokument pouzivatelovi. Nic ho nenuti pouzit rovnaku schemu aku pouzil podpisujuci.
Takze to co vidi jedna aj druha strana je zavisle na externej scheme, a je len na vyvojarovi ci si da tu pracu aby pri vizualizacii pouzil tu spravnu.
PDF dokument s vlozenym XML aspon zabezpecuje ze vsetko co podpisujuci podpisuje a vidi je vo vnutri podpisovaneho pdf a nie je zavisle na externych zdrojoch. Mne sa tento sposob zda omnoho bezpecnejsi ako podpisovanie xml ,ktore v sucasnosti robime. Samozrejme nesmie to byt formular ktory je sam zavisly na externych schemach.
Zavisi na validacii toho vkladaneho xml do pdf pred podpisanim, ale povazujem to za lepsiu cestu. Ved napriklad j format ZUGFERD, ktory to tak robi je velmi rozsireny
Koľko stojí tento projekt?
Na najbližšie tri roky sú náklady 22 miliónov eur, z toho sa podľa ministra vnútra Matúša Šutaja Eštoka (Hlas-SD) zatiaľ minula len malá časť. Štát už vynaložil dva milióny eur aj za aplikáciu Slovensko v mobile, ktorá však ponúka obmedzené možnosti.
Toto čo do tohto zarátali? 22 mega za tri roky?
A ty si píšeš vlastný vizualizator pdf, ze toto dokážeš garantovať? Či si závislý na niečom zvonka, čo ani nevieš ako tie tisíce features pdf spolu interaguju a či náhodou tvoja implementácia nemá nejaký obskurny bug, ktorý zobrazí trošku niečo iné.
Oblúkom sa dostávame zase k tomu, že najzložitejšie miesto podpisovania je wysiwys a to na konci dňa končí na dôvere. Dôveruješ dodávateľovi, že ti tam nepodvrhne niečo iné a navyše ešte aj musíš mať istotu, že tvoj stroj nie je kompromitovany a náhodou nepošle na podpis nejaký iný hash, ktorý si niekam odloží alebo rovno pošle na server.
Prave o to ide aby som dokazal co najviac minimalizovat vsetky tieto rizika.
Pdf format poskytuje na to vynikajuce schopnosti. Prevedenim PDF do PDF/A zaistime, ze sam pdf dokument v sebe nebude obsahovat ziadne features, ktore by umoznovali zavislosti na externych zdrojoch. To je jednym z ucelov pouzitia PDF/A formatu, ktora zaisti ze sa nemusim starat o to ci dokument ma alebo nema nevhodne vlastnosti.
Druhym velmi vysokym rizikom je podpisovanie XML suborov.
XML subor mozem podpisat dvomi roznymi sposobmi a to ako binarny subor, alebo pouzit kanonizacny algoritmus a tak podpisat. Ked pouzijem kanonizaciu tak rovnaka hodnota podpisu bude platna pre rozne xml binarne subory.
Cize ak do pdfa vlozim xml, tak to co vidim podpisujem a mam istotu ze to nie je zavisle na nicom externom. Ak si do pdfa vlozim pre ulahcenie strojoveho spracovania xml data a tieto budu mnou podpisane tak by som mal rucit za ich spravnost. Ak medzi tym co som videl a podpisoval a tym co mu prikladam v prilohe je rozdiel, tak nesiem za to zodpovednost.
Skor som pozeral na XmlDatacontainer kde su vlozene xml údaje spolocne s referenciou na transformacnu schemu. Su tam aj nejake Hash hodnoty pomocou ktorych si moze druha strana overit ze pouziva spravnu schemu, ktoru pri zobrazeni pouzivatelovi tuto schemu pouzije.
No a stacilo urobit to ze v XmlDatacontaineri bude vlozena aj cela transformacna schema a cele to bude podpisane. Potom staci len stanovit povinnost ze prezentacna aplikacia musi pouzit tu schemu ktora bola podpisana a ktoru pouzil aj podpisujuci v case ked podpisoval. No aj tu moze zlomyselny programator pri prezentovani podstrcit inu schemu.
Och, och, och. Ani náhodou a presne naopak. Tak ako píše @DusanM.
A ako funguje vlastne to Passkey na eIDENTITA? Ak to nevyzaduje device-bound passkey, ale funguje tam sync cez iCloud (pripadne cez 3rd party password manager). Ako je riesena ochrana, ze si to (OP) rucne nenahram do 10-tich mobilov, alebo mi ten passkey nejak neunikne?
Ak som spravne pochopil, v CZ ta ich identita vyuziva HW FIDO tokeny, aby sa to nestalo.
Passkey je pre každé zariadenie iný.
Inak asi vyšla nova verzia, píše ze nepodporovany prehliadač. Údajne ide len Chrome, Firefox a Samsung. Pritom na Edge na 12 v pohode a na 14 nejde ani jeden. Čím ďalej tým lepšie.
Ako moze byt iny, ked na iOSe sa passkey zosychronizuje na vsetky zariadenia co su prihlasne v rovnakom iCloud ucte? Znamena to, ze sa s passkey z iPhone neprihlasim s tym istym passkey napr. na iPade?
Neviem ako to ma Apple, ale pre kazde zariadenie mam iny passkey.
S passkey na jednom androide sa neprihlasim na druhom do MeID