Fórum Root.cz
Hlavní témata => Software => Téma založeno: Vox 14. 09. 2016, 00:01:12
-
Zdravím, těžce bojuji s kvalifikovanými podpisovými certifikáty, které využívám k podepisování svých e-mailů. Dosud jsem se domníval, že je využívám správně, ale člověk, se kterým si píšu, má opačný názor. Chtěl bych Vás tady jako odborníky poprosit o názory na stávající situace.
1) Vždy podepisuji e-mail spolu s veškerými přílohami v programu Mozilla Thunderbird pomocí volby Options -> Digitaly sign this message. Dosud jsem se domníval, že v takto podepsané zprávě jsou chráněny před změnou veškeré přílohy. Stačí z technického hlediska podepsat pouze e-mail nebo je nutno samostatně podepsat veškeré přílohy, aby byly chráněny před neoprávněnými změnami?
2) Dále ke svému e-mailu připojuji svůj veřejný certifikát ve formátu .crt, aby bylo možno můj podpis vytvořený soukromým klíčem kvalifikovaného certifikátu jednoznačně ověřit. Domnívám se, že bez tohoto veřejného klíče není možné zjistit, zda byl e-mail podepsán správnou osobou. K tomuto certifikátu se pravděpodobně není možné jinak dostat, protože podle smlouvy uzavřené s mým poskytovatelem certifikačních služeb by neměl být v jeho veřejném úložišti. Přesto mi ale člověk, se kterým si píši tvrdí, že stačí e-mail elektronicky podepsat a že připojování veřejného klíče k e-mailu není potřeba. Jaké jsou tedy možnosti ověření identity pisatele dokumentu bez připojeného veřejného klíče?
3) Taky bych potřeboval vědět, jestli je nutno veřejný klíč (nebo veřejnou část certifikátu - mám v tom zmatek) nějakým způsobem připojovat k jinému dokumentu nebo jím nějaký dokument podepisovat, pokud jej chci někomu zaslat. Domníval jsem se, že k tomuto účelu slouží soukromý klíč ve formátu pkcs12 importovaný do Thunderbirdu a že dostačuje podepsat e-mail, před čímž do jeho přílohy vložím veřejný klíč jako běžný soubor.
Předem Vám děkuji za odpovědi a vyjasnění situace. Nerad bych při podepisování dokumentů postupoval nepřesně nebo nezodpovědně.
-
Nechť to, co napíšu potvrdí někdo, kdo to používá, mě to jen zajímalo, koukal jsem se, co najdu. Podle popisu to bude S/MIME multipart/signed. Poměrně dost toho půjde vykoukat ze zdrojového kódu té zprávy, viz příklad na http://www.in2eps.com/fo-cms/tk-fo-cms-ex14.html.
1) Podepsáno je to, co je mezi boundary, která jsou specifikované v hlavičce. Předpokládám, že celé přílohy mezi boundary nebudou, pokud tam nejsou ani jejich hashe, jsou nepodepsané (můj tip).
2) Certifikát by měl (SHOULD) být součástí podpisu, není potřeba ho přikládat zvlášť. Je-li tam půjde ověřit opět ze zdrojového kódu. Vezmi ze zdrojové zprávy podpis a dekóduj ho pomocí base64 --decode | dumpasn1 -. Měl bys tam vidět (mimo jiné) certifikát, který přikládáš. Jak takový certifikát vypadá zjistíš pomocí dumpasn1 cert.crt.
3) Součástí certifikátu je (mimo jiné) veřejný klíč. Aby někdo mohl podpis ověřit, potřebuje veřejný klíč. Aby mohl ověřit, že veřejný klíč je důvěryhodný, potřebuje certifikát. Pokud Thunderbird přidávat certifikát do podpisu, není třeba se zabývat jeho distribucí.
-
Ad 1) Bylo by potřeba vidět konkrétní e-mail. Obvykle je podepsaný celý e-mail – i samotné tělo e-mailu může být v e-mailu vložené vícekrát (např. čistý text a HTML), stejným způsobem, jako přílohy. Ale formát e-mailu je hodně obecný, je možné je do sebe různě vnořovat, takže vždy dokážete vyrobit e-mail, kde bude část podepsaná a část nepodepsaná.
Pokud posíláte textové dokumenty, je podle mne nejlepší udělat z nich PDF a to podepsat. Například fakturu pak takhle příjemce snadno vloží do účetního systému, a když jí z něj za pět let otevře, pořád dokáže podpis ověřit. Když podepíšete e-mail, dokument z něj se brzy osamostatní, a kdo pak má pátrat, kde je ten původní podepsaný e-mail.
Ad 2) Certifikát nemusíte ručně přikládat jako přílohu, zvolte, že jej má e-mailový klient přikládat k podpisu. Pro ověření podpisu je certifikát potřeba, takže je nejlepší ho k podpisu vždy přikládat. Je možné, že příjemce e-mailu už váš certifikát má (v osobních kontaktech nebo v nějakém firemním adresáři), ale je lepší na to nespoléhat. I kdybyste u certifikační autority povolil jeho zveřejnění, tam ho klient nejspíš nenajde, protože nebude vědět, u které autority by ho měl hledat.
Ad 3) Certifikát je celý veřejný, jeho součástí je veřejný klíč. Privátní klíč nikdy nikam neposíláte, ten je tajný a nikdo ho nesmí znát. Nastavte si program, kterým podepisujete, aby certifikát přikládal rovnou k podpisu – ověřující program jej pak umí rovnou použít. Když ho přidáte vedle jako přílohu, musel by si ho adresát importovat ručně do svého adresáře.
-
Díky za informace, moc jste mi pomohli.
-
Problematika elektronickeho podpisu je hodne komplikovana (zvlast eidas a vsechny mozne normy :() takze to budu brat spis zjednodusene a z praktickeho hlediska. Pro hlubsi zkoumani je dobry serial na lupe a kniha Bajecny svet el. podpisu od Peterky.
Jak bylo receno - zalezi na konkretnim emailu, ale me thunderbird zahrnuje do podepsane casti i prilohy.
Pozor, samotna priloha podepsana neni ! Tj. jakmile se priloha z emailu ulozi, neni podepsana a neda se overit ze je nezmenena. Prilohy (napr. pdf soubory) je potreba podepsat zvlast pokud maji byt duveryhodne i bez emailu.
Clovek by se musel hodne snazit aby se certifikat do emailu nepridal automaticky, myslim ze rucni pridavani je zbytecne.
U podepisovani dokumentu je to podobne - aplikace (napr. adobe reader nebo jak se jmenuje) pdf podepise a vlozi vse potrebne. V praxi se podepisuji hlavne pdf a xml. U pdf pozor aby byl podpis ve formatu pades (stary pkcs7 uz neni podle eidas norem).
CA zverejnuje pouze CRL seznamy pro kontrolu revokace. Krome privatniho klice ale neni zadny problem se zverejnenim - i kdyz "verejny" certifikat bude znat nepritel, k nicemu mu to neni (krome validace).
Pro uplne overeni je nutne mimo "verejneho" certifikatu jeste CRL list/OCSP request pro zjisteni jestli certifikat neni revokovan. Totez pro vsechny intermediate a root CA. Pokud se bavime o eidasu tak se CA musi nachazet na EU trusted
seznamu a certifikat musi obsahovat esign qc statement. Plus "standardni" veci jako CRL url, AIA atd.
-
Certifikační autorita může na přání zveřejňovat i certifikáty. Odkaz na CRL nebo OCSP je součástí certifikátu, takže pokud příjemce důvěřuje příslušné certifikační autoritě, je certifikát (automaticky) přiložený k podpisu to jediné, co potřebuje znát pro ověření podpisu.
-
No, spíš je může na přání <strong>ne</strong>zveřejňovat. (Nad smyslem takového počínání zákazníka je pak zbytečné dumat.)
-
Jak je to s intermediate certifikáty? Dávají se do podpisu nebo existuje nějaká stadardní cesta, jak se k nim dostat?
-
Ten, kdo podpis ověřuje, musí intermediate certifikát mít – buď z podpisu, nebo ve svém úložišti certifikátů. Bez toho nedokáže podpis ověřit (pokud nebude ručně hledat intermediate certifikát na internetu). Měl by tedy být součástí podpisu, stejně jako by měl inetermediate certifikáty posílat třeba HTTPS server. Ale jak se v tomhle chová který e-mailový klient jsem nikdy nezkoumal.
-
Odkaz na stazeni issuer certifikatu je obvykle v tzv. AIA casti certifikatu.
-
Este nikto z uzivatelskeho hladiska neodpovedal na 1)
1) V mailovom klientovi vidim podpisanu prilohu s takou "pecatou". Pred zmenou prilohy to neochrani. Utocnik moze podpisanu prilohu odstranit a dat tam druhu nepodpisanu.
-
Odkaz na stazeni issuer certifikatu je obvykle v tzv. AIA casti certifikatu.
Máte pravdu. Nevíte, zda to e-mailoví klienti nebo prohlížeče PDF při ověřování podpisů používají? Webové prohlížeče intermediate certifikáty nestahují (což je docela pochopitelné, protože by to blokovalo navázání HTTPS spojení – ale zase by si mohl prohlížeč certifikát uložit do nějaké cache).
Este nikto z uzivatelskeho hladiska neodpovedal na 1)
1) V mailovom klientovi vidim podpisanu prilohu s takou "pecatou". Pred zmenou prilohy to neochrani. Utocnik moze podpisanu prilohu odstranit a dat tam druhu nepodpisanu.
Tazatel se neptal na podepsané přílohy, ale na podepsaný e-mail. Testovací podepsaný e-mail z MS Outlooku vypadá takhle:
multipart/signed (podepsaný e-mail)
- multipart/mixed (e-mail)
- - multipart/alternative (tělo e-mailu)
- - - text/plain (tělo e-mailu jako čistý text)
- - - text/html (tělo e-mailu jako HTML)
- - application/pdf (příloha)
- application/pkcs7-signature (podpis)
Takže podepsaný je celý e-mail, jak tělo e-mailu tak příloha. Pokud by útočník přílohu v e-mailu vyměnil, nebude podpis e-mailu sedět.