Zabezpečení elektronické pošty

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA

INFORMATIKY

^TIS

mp

Zabezpečení elektronické pošty BAKALÁŘSKÁ PRÁCE

Michal Prokeš

Brno, podzim 2005

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypra­ coval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování použí­ val nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: Mgr. et Mgr. Jan Krhovják 11

Shrnutí Práce se zabývá zabezpečením elektronické pošty pomocí protokolů OpenPGP a S/MIME. Hlavním cílem je zmapovat základní rozdíly mezi uvedenými protkoly a jejich podporu v konkrétních poštovních klientech. Součástí práce je také úprava textového poštovního kli­ enta Mutt, umožňující zasílání zabezpečených emailů s přílohou ve formátu OpenPGP tak, aby byli čitelné v programu Pine.

m

Klíčová slova Digitální podpis, email, GnuPG, Mutt, OpenPGP, PGP, s/mime

Obsah 1 Úvod 2 Kryptologie 2.1 Základní kryptologické pojmy 2.2 Symetrické metody 2.3 Asymetrické metody 2.4 Hashování 2.5 Hybridní šifry 3 Zabezpečení elektronické pošty 3.1 Bezpečnostní protokoly 3.1.1 Správa klíčů 3.1.2 OpenPGP 3.1.3 S/MIME 3.2 Začlenění bezpečnosti do emailu 3.2.1 PGP/inline 3.2.2 PGP/mime 3.2.3 S/mime 4 Testování klientů elektronické pošty 4.1 Příprava a testování 4.1.1 Testovací sada pgp/mime 4.1.2 Testovací sada pgp/inline 4.1.3 Testovací sada s/mime 4.2 Výsledky testování jednotlivých klientů 4.2.1 MS Outlook Express 4.2.2 MS Outlook 2000, 2002, 2003 4.2.3 Mutt devel 1.5.10 4.2.4 Mutt stable 1.4.2 4.2.5 The Bat! 4.2.6 Exmh 2.7.0 4.2.7 Mozilla Thunderbird 1.0.7 4.2.8 Mozilla Suite 1.7.12 4.2.9 Balsa 2.2.6 4.2.10 Pine 4.52 4.2.11 Becky! 2.22.02 4.2.12 Syplpheed-Claws 1.9.15 4.2.13 Sylpheed 2.1.3 4.2.14 Klienti nepodporující žádné zabezpečení 4.3 Závěry z testování klientů 5 Implementace 5.1 Patch pro Mutt 1.5.10i 6 Závěr

1 3 3 4 5 6 6 7 8 8 9 14 14 14 14 15 16 16 16 16 17 17 17 18 18 18 19 19 20 20 20 20 21 22 22 23 23 26 26 28 v

A Patch pro Mutt 1.5.10i Literatura

29 37

vi

Kapitola 1

Úvod Práce popisuje možnosti zabezpečení elektronických dat, definuje základní pojmy a pouka­ zuje na problémy, které se zabezpečením souvisí. Mimo technických potíží se setkáváme i s problémy zcela jiného charakteru. Zatímco u neelektronických způsobů komunikace mají uživatelé podvědomě zažitá rizika a míru důvěryhodnosti jednotlivých kanálů (tele­ fon, dopis, osobní setkání) a způsobů zabezpečení (podpis, notářsky ověřený podpis, ra­ zítko), u elektronické komunikace tomu tak mnohdy není. Tento text ukazuje alternativy k tradičnímu způsobu zabezpečení dokumentů, stručně popisuje principy elektronického zabezpečení a jejich zranitelná místa, přičemž se specializuje na zabezpečení elektronické pošty. Cílem práce je testování bezpečnostních funkcí poštovních klientů a jejich rozšíření. Pro testování bylo vybráno 21 známých poštovních klientů, u nichž byla ověřována schopnost provádět jednotlivé zabezpečovací úkony pomocí dvou nejpoužívanějších protokolů (OpenPGP a S/MIME), sledován je také komfort práce se zabezpečenou poštou a čtení pošty za­ slané z jiných klientů, tedy vzájemná kompatibilita poštovních klientů. Nakonec je prezentován naprogramovaný patch umožňující zaslat zabezpečenou zprávu z textového klienta Mutt do dosud nekompatibilních klientů a navrhována úprava RFC umožňující tvorbu kompatibilnejších zpráv. Jako úvod do problematiky slouží kapitola Kryptologie, která definuje základní pojmy a nastiňuje problémy související se zabezpečením. Kapitola Zabezpečení elektronické pošty poukazuje na to, že uživatelé věnují zabezpe­ čení elektronických dat nižší pozornost, než je tomu u dokumentů papírových. Uvádí existu­ jící způsoby řešení bezpečnostních problémů a rozebírá základní odlišnosti uvedených pro­ tokolů. Specializuje se na rozdíly v bezpečnostní politice, zejména ve správě klíčů. Podrob­ něji se věnuje protokolu OpenPGP Závěr kapitoly je věnován způsobu začlenění zabezbečených dat do běžné emailové zprávy a stručně popisuje bezpečnostní formáty: pgp/inline, pgp/mime a s/mime. Hlavním cílem práce bylo otestování poštovních klientů na podporu jednotlivých for­ mátů a kompatibilitu zpráv s ostatními klienty. Důraz byl kladen na emaily s přílohami. Výsledky těchto testů jsou popsány ve čtvrté kapitole, která popisuje schopnosti a pro­ blémy jednotlivých klientů pracovat se zabezpečenými zprávami. Pokud tyto funkce pro­ gram nemá v základní distribuci, je stručně uveden způsob, jak do něj potřebné vlastnosti začlenit. Pátá kapitola popisuje naprogramovaný opravný patch, který zvyšuje kompatibilitu mezi 1

1. ÚVOD

pravděpodobně nejpoužívanějšími textovými klienty - Mutt a Pine. Jsou popsány jak dů­ vody pro výběr tohoto programu k napsání patche, tak i původní a nové chování pro­ gramu. Podobně jako rozšíření Enigmail pro jiného poštovního klienta, i tento upravený klient umožňuje vytvářet zabezpečené zprávy s přílohami ve formátu, který je čitelný větši­ nou klientů podporujících zabezpečení. Závěrečná kapitola nabízí porovnání množství klientů podporujících jednotlivé formáty zabezpečení a popisuje výhody a nevýhody užití jednotlivých formátů v konkrétních situa­ cích. Dále je prezentován návrh na plně kompatibilní řešení podepisování zpráv, umožňující podepsat zprávu více formáty současně.

2

Kapitola 2

Kryptologie Tato kapitola je koncipována jako úvod do problematiky zabezpečování elektronických dat. Jejím cílem je seznámení se základními kryptologickými pojmy a s kryptografickými meto­ dami a postupy. 2.1

Základní kryptologické pojmy

Už s příchodem prvních abeced bylo potřeba řešit bezpečnostní problémy spojené s lidskou komunikací. U většiny zpráv je důležité znát identitu autora a mnohdy také čas vzniku. U vícestranných dohod také souhlas dalších osob s jejím obsahem. Už ve starověku (Egypt, Mezopotámie) je zaznamenaná snaha o utajení obsahu zprávy před neoprávněnými čte­ náři změnami v písmu. Za první užití moderních metod zabezpečení se podle [8] považují rozkazy Julia Ceasara zasílané generálům 1 . Dalšími důležitými historickými milníky byly světové války 2 , rozšíření výpočetní techniky v druhé polovině 20. století a masový nástup internetu na jeho konci. Zabezpečením zpráv se dnes zabývá vědní obor kryptologie, který v sobě zahrnuje kryptografíi, kryptoanalýzu a steganografíi. Kryptografie je nauka o metodách šifrování (utajení obsahu zprávy před neoprávněným čtenářem) a dešifrování (převod zpět na čitelný text oprávněnou osobou). Otázka bezpeč­ nosti komunikace nemusí vždy spočívat pouze v utajení přenášené informace, proto kryp­ tografie hledá také řešení autentizace - ověření identity autora zprávy, zajištění integrity (neporušenosti) zprávy - možnosti ověřit, že jsme informaci dostali v identické podobě jako byla vytvořena. A v neposlední řadě také nepopiratelnosti (neodmítnutelnosti). Ta znemož­ ňuje osobám distancovat se od provedné akce se zprávou, např. její napsání, přečtení, pode­ psání. Základním zákonem moderní kryptografie jsou pravidla pruského důstojníka Kerckhoffa z roku 1883 známé jako Kerckhoffůvprincip[5]. Bezpečnost kryptosystému nelze stavět na utajení algoritmu, ale pouze na utajení tajemství (klíče). Odolnost systému je třeba uva­ žovat proti útočníkům, kteří detailně znají použitý algoritmus. Díky tomuto principu se mohly kvalitní šifry rozšířit z přísně tajných výzkumných ústavů a armádních laboratoří k široké veřejnosti. Rozšířilo se nejen jejich užití, ale také samotný vývoj. Každý, kdo má 1. J. Ceasar zaměnil ve zprávách A za D, B za E apod. Poslíček tedy nevěděl jakou zprávu nese, ale generálovi stačilo znát klíč (počet posunů = 3) a uměl tak přečíst původní obsah zprávy. 2. V Německu bylo sestrojeno snad nejznámější šifrovací zařízení - Enigma.

3

2.2. SYMETRICKÉ METODY dnes přístup k počítači, může svá data chránit natolik, že by všem počítačům světa trvalo je­ jich dešifrování mnoho let. Výpočetní technika zažívá stále prudký vývoj a její rychlost roste exponenciálně. To, co je dnes neřešitelné pro všechny počítače světa, může být v budoucnu řešitelné několika výkonnými stroji. Čím déle chceme zprávu tajit, tím delší šifrovací klíč bychom měli použít. Kryptografické šifry problémy ve skutečnosti neřeší, ale zaručují vysokou pravděpodob­ nost, že s užitím dostupné techniky a znalostí bude téměř nemožné bezpečnost v rozumném čase narušit. Při výběru šifry a zejména délky klíče je tedy nutné uvažovat nejen nad tech­ nickými možnostmi potenciálního útočníka, ale také na čase, po který potřebujeme zajistit bezpečnost dat. Čím delší klíč, tím vyšší bezpečnost, ale pomalejší kryptografické operace. Spolu s kryptografií se rozvíjí také kryptoanalýza, neboli nauka o luštění šifer. Zabývá se sílou šifer, tedy jejich odolností vůči násilným útokům (lámání šifry), ale také hledá postupy výpočtu obsahu šifrované zprávy bez znalosti potřebného tajemství a možnosti porušení ostatních zabezpečovacích technik. Žádná z dnes běžně používaných šifer neodolá tzv. útoku hrubou silou, tedy postup­ nému vyzkoušení všech možných klíčů. Moderní šifry však mají takové množství možných klíčů, že je tento postup vzhledem k potřebné technice a časové náročnosti pro útočníka ne­ použitelný. Kryptoanalýza hledá metody, které by umožnily útočníkovi čas potřebný k pro­ vedení útoku výrazně zkrátit. Pokud se analytikům podaří takovou metodu najít, stává se šifra prolomenou. Slabiny nestačí hledat v samotných šifrovacích či podepisovacích protokolech. Důležité je zabezpečení celého kryptosystému. Známým útokem je např. Man in the middle. Komu­ nikující strany nevědomky komunikují přes prostředníka, který zprávu dešifruje, přečte a případně upraví a znovu zabezpečí pro druhou stranu. I silné šifrování bez zajištění autentizace tak může být snadno napadeno. Při užití silných šifer je také mnohdy snadnější získat samotné tajemství přímou cestou, tedy krádeží, vydíráním apod. Ochrana tajemství je tedy jednou z nejsložitějších a nejdůležitějších částí zabezpečení. Pod kryptologii se řadí také steganografíe, která má za cíl utajit samotnou existenci zprávy.

2.2

Symetrické metody

Symetrická šifra využívá stejný klíč pro šifrování i dešifrování zprávy. Obě strany sdílejí tutéž tajnou informaci a její pomocí mohou zprávu jak šifrovat, tak dešifrovat. Symetrické šifry bývají jednodušší na implementaci, rychlé a i při relativně krátkých klíčích bezpečné, ale řeší pouze problém utajení zprávy. Před zabezpečenou komunikací je třeba se dohodnout na sdíleném tajemství, tedy ustavit klíč. Komunikující strany se tak musí předem setkat nebo jiným bezpečným způsobem přenést klíč a zajistit vzájemnou autentizaci. Pro každý komunikující pár potřebujeme jiný klíč. Při velkém množství vzájemně komunikujících může být množství klíčů opravdu vysoké. Ustavení klíče částečně řeší protokol Diffie-Hellman [21]. Umožňuje ustavit symetrický 4

2.3. ASYMETRICKÉ METODY tajný klíč bez nutnosti předem sdílet tajemství3. Protokol je založen na problému diskrét­ ního logaritmu. Obě komunikující strany si sdělí dvě veřejné konstanty a vygenerují vlastní tajný klíč, jehož pomocí vypočítají mezivýpočet a předají ho druhé straně. Z obdrženého mezivýpočtu a svého tajného klíče vypočítají obě strany stejný sdílený klíč, aniž by znaly ta­ jemství druhé strany. Protokol Diffie-Hellman nezajišťuje autentizaci a lze na něj aplikovat útok Man in the middle. Z tohoto důvodu není plnohodnotným řešením distribuce klíčů. Pro zvýšení bezpečnosti se někdy užívá jednorázových či časově omezených klíčů. Ko­ munikující strany si jich předem dohodnou více a sníží tak množství prozrazených infor­ mací v případě prolomení šifry4. 2.3

Asymetrické metody

Až v roce 1976 publikovali Whitfield Diffie, Martin Hellman a Ralph Merkle článek o nových možnostech kryptografie, čímž byly položeny základy asymetrických kryptografických me­ tod. Hned vzápětí (1978) vzniká první asymetrický šifrový systém - RSA. Tyto metody se snaží odstranit problémy a nedostatky symetrické kryptografie. Algoritmy používají různé klíče pro šifrování a dešifrování (tzv. klíčový pár, obsahující veřejný a soukromý klíč). Veřejný klíč není třeba tajit a používá se pro šifrování zprávy či ověření podpisu. Soukromý klíč je využíván k dešifrování či k vytváření podpisu 5 . Před za­ čátkem komunikace je třeba předat pouze veřejné klíče. Jelikož neobsahují žádné tajemství, mohou být distribuovány libovolnou cestou. Důležité je ověřit autenticitu a integritu přija­ tého klíče [kap. 3]. K zahájení komunikace není nutno přenášet ani sdílet žádné tajemství. S jediným párem je možno bezpečně komunikovat s neomezeným množstvím uživatelů. Asymetrická kryptografie je založena na jednosměrné funkci se zadními vrátky. Tedy na funkci, z jejíhož výsledku nelze získat vstupní hodnotu bez znalosti dodatečného tajemství. Taková ideální funkce není známa, ale blíží se k ní funkce založené na obtížných matema­ tických problémech. Výpočet je však výrazně snazší pokud známe více údajů 6 . Síla kvalitní asymetrické šifry závisí stejně jako u symetrické na délce klíče. Se znalostí algoritmu však lze předem vyřadit některé možnosti, které nemohou být řešením matema­ tického problému. Pro zachování bezpečnosti přenosu je třeba použít výrazně delší klíče než u symetrické kryptografie. Kvůli výpočetně složitějším algoritmům a delším klíčům je výrazně pomalejší než symetrická kryptografie. I asymetrická kryptografie však má své slabé stránky. Za potenciální bezpečnostní ri­ ziko lze totiž považovat samotný princip založený na matematickém problému, jehož řešení 3. Tuto metodu poprvé prezentovali veřejnosti pánové Whitfield Diffie a Martin Hellman v roce 1976. Již dříve ji užívala britská armáda, ale algoritmus tajila. 4. Např. německá Enigma užívala za 2. světové války pro rádiové vysílaní německé armády symetrické šifry s časově omezeným klíčem. Pro každý den byl předem dohodnut jiný klíč. Pokud se britské armádě podařilo klíč získat, mohli rozluštit pouze vysílání z jednoho dne. 5. Přičemž je vhodné používat pro podepisování/ověřování a šifrování/dešifrování jiný klíčový pár. 6. Příkladem je součin velkých prvočísel. Výpočet je relativně snadný. Rozložit výsledek zpět na prvočísla je však netriviální problém. Pokud je ovšem známo jedno z uvedených prvočísel, je to opět jednoduché. Na podobném principu fungují všechny asymetrické šifry.

5

2.4. HASHOVÁNÍ není známo. Nelze vyloučit, že v budoucnu bude nalezeno snadné řešení onoho problému a všechny šifry na něm založené se ze dne na den stanou snadno rozluštitelnými. Na rozdíl od rychlosti vývoje výpočetní techniky nelze odhadnout, zda a kdy se to vědcům podaří. I přes tento fakt jsou asymetrické šifry s užitím dlouhých klíčů považovány za dostatečně silné. 2.4

Hashování

S kryptografií úzce souvisí také hashování. Tímto pojmem se myslí užití jednosměrné funkce, která má definované vlastnosti. Ideální kryptografická hashovací funkce vygeneruje z kaž­ dého vstupu libovolné délky jednoznačný výstup konstantní délky nazývaný hash, někdy také otisk. Z hashe nelze zpětně určit vstup. Při minimální změně vstupu se změní 50% bitů hashe. Pomocí hashe ověřujeme integritu klíčů a je využíván i při podepisování zprávy. Tyto funkce se také užívají samostatně k uchování hesel v systému a jejich ochraně před prozrazením. Heslo je uloženo v podobě hashe. Pokud tedy uživatel zadá heslo, je snadné pomocí hashovací funkce ověřit, že je totožné s uloženým. Útočník s právy administrátora má však přístup pouze k hashům a musel by tak provést slovníkový útok nebo útok hrubou silou. Pro ztížení takových útoků se využívá náhodný řetězec, tzv. sůl. Ta se přidá na vstup spolu s heslem a je s heslem uložena i v otevřené podobě. Díky soli mají stejná hesla různý hash. Nepozná se tak, že má více uživatelů stejné heslo. 2.5

Hybridní šifry

Jak bylo uvedeno výše, asymetrická kryptografie řeší některé nedostatky symetrické za cenu nízké rychlosti. Ukázalo se, že symetrické a asymetrické šifry lze zkombinovat a tím celý proces zefektivnit. Princip je velice jednoduchý. Požadovaný obsah zašifrujeme symetrickou šifrou užitím náhodně vygenerovaného klíče. Pouze tento náhodný klíč zašifrujeme užitím veřejného klíče příjemce. Tím získáme rychlost symetrické kryptografie a výhody asyme­ trické současně. A konečně, pokud máme více příjemců, není třeba šifrovat celou zprávu vícekrát, ale stačí zašifrovat onen jednorázový klíč pro každého příjemce.

6

Kapitola 3

Zabezpečení elektronické pošty Ruční podpis na papírových dokumentech bereme jako samozřejmost. Před odesláním ta­ kový dokument automaticky zabalíme do obálky, nebo jej zabezpečíme ještě důkladněji (třeba notářsky ověřeným podpisem či uschováním v trezoru). V dnešní době se ale do­ kumenty stále častěji uchovávají a šíří elektronicky. Uživatelé ovšem věnují zabezpečení elektronických dokumentů mnohem menší pozornost. Nástroje pro zabezpečení elektronic­ kých dat však existují a jejich užití je zakotveno i v legislativě vyspělých států, včetně České republiky. Pokud dokument nepodepíšeme vlastnoručně, ale pouze elektronicky, jedná se o elek­ tronický podpis. Ten tvoří elektronická reprezentace údajů sloužících k autentizaci. Můžou jej tvořit naše iniciály, jméno s kontaktními údaji, ale také biometrická data 1 apod. Jelikož takový podpis lze jednoduše zfalšovat, vznikl v druhé polovině 70. let minulého století digi­ tální podpis2, který pomocí asymetrické kryptografie zajistí vazbu mezi podepsanými daty a elektronickým podpisem. Digitálním podpisem lze zaručit autentičnost a integritu, pomocí časových razítek i exis­ tenci v čase a v neposlední řadě nepopiratelnost vytvoření. Nepopiratelnost doručeníbohužel běžně užívané systémy stále nepodporují. V následujícím textu budeme digitální podpis většinou zkracovat na podpis, stejně jako digitálně podepsat na podepsat. V české legisla­ tivě [22] je také definován pojem zaručený elektronický podpis, což je elektronický podpis, který splňuje předepsané parametry nutné pro spolehlivé ověření totožnosti podepisujícího. V některých případech je navíc vhodné utajit obsah zprávy před zraky cizích osob. Ať už jde o státní tajemství, strategické firemní informace, nebo soukromé sdělení. V internetových diskuzích se objevují názory, že pokud nejsme zločinci, nemáme co tajit. Ale i když nejsme zločinci, dopis automaticky zabalíme do obálky a zalepíme, aby si ho doručovatelka nečetla. Obdobného efektu dosáhneme u elektronických dat pomocí šifrování a následného dešifrování zprávy. Podepsání, šifrování a nebo obojí budeme souhrnně nazývat zabezpe­ čenia nadále se nebudeme věnovat obecným apsektům bezpečnosti, ale pouze zabezpečení elektronické pošty.

1. Elektronická reprezentace otisku prstu apod. 2. Digitální podpis umí vytvořit některé asymetrické šifry, které umí také šifrovat soukromým klíčem a dešif­ rovat (ověřovat podpis) veřejným.

7

3.1. BEZPEČNOSTNÍ PROTOKOLY 3.1

Bezpečnostní protokoly

Nejpoužívanější protokoly pro zabezpečení el. pošty jsou S/MIME a OpenPGP Tyto proto­ koly využívají silné kryptografické algoritmy a užitím dostatečně dlouhých klíčů zabezpečí zprávu na měsíce i roky. Dle RSA Security by měla být 80-bitová symetrická, respektive 1024-bitová RSA šifra bezpečná do roku 2010.128-bitová symetrická, respektive 3072-bitová RSA šifra by pak měla být bezpečná déle než do roku 2030. K oběma protokolům existují volně šířitelné i komerční implementace. Oba protkoly řeší tytéž problémy a sdílejí dokonce i některé algoritmy. Zprávu zabezpe­ čují vhodnou kombinací hashovacích funkcí, symetrické i asymetrické kryptografie. Avšak tato řešení jsou navzájem nekompatibilní a to jak ve formátu zprávy, tak ve formátu sa­ motného klíče. Standardizaci obou protokolů provázely problémy s užitím patentovaných šifer, což neumožňuje IETF (Internet Engineering Task Force) vyhlásit je za standard. V sou­ časnosti má každý protokol svou pracovní skupinu v IETF, která se zabývá jeho dalším vývojem. Mimo tyto pracovní skupiny existuje také IMC (Internet Mail Consortium), jež má mnoho individuálních i komerčních členů. Snaží se pomáhat ve vývoji obou protokolů, protože každý má své zastánce. Cílem konsorcia je vybrat jeden z protkolů. 3.1.1

Správa klíčů

K bezpečnému využití služeb obou protokolů je třeba zajisit kvalitní a spolehlivou správu veřejných klíčů. Je důležité zajistit integritu a autentičnost přijatých klíčů a umožnit jejich odvolání v případě kompromitace. Bez této jistoty nelze zaručit bezpečnost. Certifikační autority s/mime S/mime byl od počátku vyvíjen zejména pro podnikovou sféru. Pro ověřování klíčů byl zvolen model centrální správy. Zakládá se tzv certifikační au­ torita (CA), která ověřuje identitu majitele a vydává certifikáty3 ke klíčům pro konkrétní užití (provozování internetového serveru, zabezpečení elektronické komunikace, vydávání certifikátů). Může tedy svěřit pravomoc vydávat certifikáty další osobě. Kořenová CA (root CA) má svůj certifikát podepsaný jen sama sebou a tvoří tak počátek stromu. Uživatel potom důvěřuje nejen klíčům podepsaným důvěrnou root CA, ale také klíčům podepsaným libo­ volnou CA mající oprávnění vydávat certifikáty od níž vede cesta k důvěrné CA. Myšlenka vychází tedy z toho, že si uživatel do klienta nainstaluje jako kořenovou CA svého zaměst­ navatele a ten potom rozhoduje o tom, který klíč je pravý, či jaká další organizace může vydávat důvěrné certifikáty. Předpokládá se, že vydavatel certifikátů má lepší prostředky pro ověření identity než samotný uživatel. V praxi jsou však v systému automaticky nain­ stalované kořenové certifikáty mnohých uznávaných autorit a pokud je uživatel nesmaže, automaticky tak důvěřuje velkému stromu CA. 3. Certifikát je digitální podpis veřejného klíče vytvořený důvěryhodnou třetí stranou. Potvrzuje identitu vlastníka příslušného soukromého klíče.

8

3.1. BEZPEČNOSTNÍ PROTOKOLY Síť důvěry OpenPGP OpenPGP byl původně vyvíjen zejména pro osobní použití. Ná­ sledně byl částeně komercializován zejména z důvodu soudních sporů o užití patentova­ ných algoritmů. Ověřování identity majitele klíče se zakládá na tzv. síti důvěry (web of truth). Neexistují centrální certifikační autority. Snahou je přenést zodpovědnost na kon­ cové uživatele. Umožňuje nám podepisovat veřejné klíče, u nichž dokážeme ověřit identitu majitele. Zvlášť se ověřuje platnost a důvěryhodnost klíče. OpenPGP klíče mohou být ší­ řeny spolu s neomezeným množstvím podpisů. Platnost klíče udává míru důvěry v inte­ gritu a autenticitu klíče. Pokud věříme v platnost klíče, pak věříme v pravost podpisu a také můžeme posílat šifrované zprávy dané osobě. Důvěryhodnost klíče potom udává míru naší důvěry v ostatní klíče, které jsou tímto důvěryhodným klíčem podepsány. OpenPGP má více stupňů důvěry v klíč. Nevěřím, věřím částečně a věřím zcela. Automaticky po­ tom důvěřujeme klíčům podepsaným více klíči s částečnou důvěrou, nebo alespoň jedním, kterému důvěřujeme zcela. Toto řešení se zřejmě více shoduje s důvěrou v reálném světě. Důvěřujeme pravosti podpisu, který někdo vytvořil před našimi zraky a také podpisu, který někdo podepsal před zraky někoho, komu důvěřujeme. S každou další osobou se však naše důvěra snižuje. Délka cesty od námi ověřeného klíče je omezená. Tento model se zdá být aplikovatelný i na podnikové prostředí, kdy klíč našeho zaměstnavatele označíme za zcela důvěrný a důvěřujeme tak kontaktům, které prověří náš zaměstnavatel. Částečně tedy mů­ žeme simulovat systém CA. K získání klíčů osob, se kterými jsme ještě nekomunikovali a k podepisování a odvolávání klíčů slouží servery klíčů. 3.1.2

OpenPGP

Historie PGP do verze 2.6.3i První verzi PGP 1.0 napsal Philip. R. Zimmerman v roce 1991 pro sebe a své kama­ rády. Byla užita jeho vlastní, kryptograficky slabá, symetrická šifra Bass-O-Matici, hasovací funkce MD4 a asymetrická šifra RSA. Užití RSA rozpoutalo spory s vlastníkem licence to­ hoto algoritmu. Licence se vztahovala pouze na území spojených států, P R. Zimmerman tedy udělil licenci na vývoj a prodej komerční verze pro USA firmě ViaCrypt. Mimo území USA bylo PGP šířeno jako freeware. Následoval prudký vývoj, který se ustálil v roce 1993 ve freeware verzi PGP 2.3a (MD5, IDEA, RSA) pro použití mimo USA a komerční 2.4.x pro trh USA. Změna algoritmů zname­ nala nekompatibilitu s předchozími verzemi. Následně se podařilo domluvit licenci na užití RSA pro USA. Vznikla verze PGP 2.5 (freeware pro nekomerční účely v USA), která musela být podle licence nekompatibilní s předchozími verzemi. V roce 1996 vydal S. Schumacher verzi 2.6.3i vycházející z vývojové verze PGP 2.6 (RSA až 8192 bitů, DH/DSS). Tato verze se snažila sjednotit verze pro USA a svět a stala se také na dlouho nejpopulárnější verzí. Ofici­ ální verze jsou 2.6.2 (USA) a 2.6.2i (svět). P R. Zimmerman má potíže s vládou USA, která staví distribuci PGP ve světě na stejnou úroveň jako vývoz nebezpečných zbraní z USA, protože nedokáže šifrované zprávy dekódovat. PGP 4.x, PGP 5.x, PGP 6.x, G10 Komerční verze (ViaCrypt) PGP 4.x vychází v roce 1996 (samostatný šifrovací a pode9

3.1. BEZPEČNOSTNÍ PROTOKOLY pisovací klíč, DH klíče a netscape plugin). Zimmermanův spor s USA končí bez vznesení obvinění a P. R. Zimmerman zakládá PGP Inc., která kupuje ViaCrypt a vrací se do hry. Následující verze se snaží být zpětně kompatibilní s verzí 2.6.x tak, že umožňují číst tyto zprávy a na vyžádání i šifrovat pro tyto verze. V roce 1997 vydává PGP Inc. verzi PGP 5.0 (DH/DSS, RSA v komerční verzi, SHA-1, MD5, IDEA, 3DES, CAST), grafické rozhraní pro Windows a MacOS, freeware verze pro příkazovou řádku. Ve stejném roce vzniká pracovní skupina v IETF a první draft OpenPGP vycházející z verze PGP 5.0. NAI kupuje PGP Inc. Jakmile se objeví draft OpenPGP vydává Werner Koch svou implementaci OpenPGP G10 (později přejmenováno na GnuPG) s cílem vytvořit kompatibilní nástroj s GNU licencí. PGP 6.0 (1998 NAI Inc.) přidává plnou podporu RSA včetně generování klíčů, PGPDisk (transparentní šifrování disku Windows, MacOS). OpenPGP standard, GnuPG, PGP 6.5 V roce 1998 byl vydán standard OpenPGP, RFC 2440. GnuPG (původně G10) má tedy volné ruce k vývoji plně kompatibilního řešení. NAI se vydává směrem uzavírání zdrojového kódu a přidáváním vlastností nesouvi­ sejících s původní funkcionalitou. PGP 6.5 (rok 1999) obsahuje PGPNet (implemetnace IPSEC/IKE) pro Windows. PGP 6.5.3 je již šířena bez zdrojového kódu. NAI využívá popula­ rity PGP a pod názvem PGP e-ppHance šíří svůj firewall. GnuPG 1.0 (DSA, Elgamal, hashovací funkce MD5, RIPEMD, SHA1 a symetrické algo­ ritmy CAST, 3DES, AES) vychází v roce 1999 jako první stabilní implementace OpenPGP s GNU licencí. Nově obsahuje podporu přidávání dalších algoritmů. Konec patentu RSA, PGP 7.x, PGP 8.x, GPGME Patent RSA skončil v roce 2000. NAI Inc. vydává PGP 7.0 (symetrická šifra CAST, hash SHAl) s integrovaným firewallem pro Windows. Plná podpora RSA včetně možnosti zvlášt­ ního podepisovacího a šifrovacího klíče. Ve verzi PGP 7.0.3 opouští P. R. Zimmerman NAI a dává záruku, že PGP do této verze neobsahuje zadní vrátka. 2002 NAI oznamuje, že se nepodařilo nalézt kupce PGP Desktop a že ukončuje vývoj a nebude prodlužovat servisní smlouvy. V zápětí vzniká nová společnost PGP Corporation, kupuje licenci a ve stejném roce vydává PGP 8.0 (podpora Windows XP a Mac OS X) GnuPG s plnou podporou RSA, standardní nastavení uzpůsobeny lepší komptaibilitě s PGP 7.x, přidána podpora AES. Spolu s GnuPG začíná vývojtaké GPGME (crypto API pro jiné apliace) a GPA (grafické prostředí pro linux). GnuPG je kompatibilní s grafickými nadstavami Windows a MacOS pro PGP. V roce 2002 začíná vývoj GPGRemail pro zabez­ pečené mailinglisty a NewPG (implementace S/MIME se stejným prostředím jako GPG pro OpenPGP). V roce 2003 jsou představeny OpenPGP smartcards. Současný vývoj Nalezeny slabiny v MD5. Všechny nástroje začínají standardně užívat SHAl. GPG a s ním související nástroje zaznamenávají stále prudký vývoj. Jeho implementace se stává standardní součástí nejen linuxových distribucí. 2004 vychází GPGME 1.0 (cílem je poskytnout jednoduché a jednotné API pro GnuPG). Současný vývoj směřuje k jednotnému API pro OpenPGP i S/MIME. 21.4.2005 vychází vývojová verze GnuPG 1.9.16 vycházející z GnuPG 1.3 pro OpenPGP a NewPG pro S/MIME. Vše směřuje ke GnuPG 2.0 umožňující 10

3.1. BEZPEČNOSTNÍ PROTOKOLY užívat protokoly OpenPGP i S/MIME. Formát OpenPGP zprávy OpenPGP zpráva definovaná v RFC2440 [13] je kompletní, nezávislá zpráva, obsahující více částí (tzv paketů) včetně všech potřebných hlaviček. Je de­ finováno více typů, které se mohou navíc navzájem zanořovat. Obsahem šifrovaného paketu tak může být podepsaný paket apod. Zpráva je formována tak, aby bylo možné ji dekódo­ vat na jeden průchod. Tedy informace o použitých algoritmech je na začátku zprávy a při prvním průchodu je možné například spočítat hash a ten ověřit s podpisem umístěným na konci. Tato zpráva je samostatně využitelná například pro podepisování či šifrování dat na disku. V OpenPGP zprávě je využíván digitální podpis 3.1.2, šifrování 3.1.2, komprimovaná data a radix64 kódování 3.1.2. Začlenění OpenPGP do MIME zpráv popisuje samostatné RFC. Podepisování zpráv Mnohdy není nutné tajit obsah zprávy, ale i přesto je třeba zajistit možnost ověření odesílatele zprávy. Tedy to, že zpráva skutečně pochází od uživatele je­ hož jménem je psaná. Pravdivost standardní hlavičky emailu „From:", která nese informaci o odesílateli, běžně nelze ověřit, a tak není obtížné vydávat se za kohokoli jiného. Totožná zpráva má pro příjemce mnohdy zcela jiný význam v závislosti na osobě odesílatele, proto je důležité mít možnost ověřit, od koho zpráva pochází. Samotné ověření identity odesílatele není dostatečné. Očekávaný výsledek přináší až v kombinaci s ověřením integrity samotné zprávy. Tedy toho, že jsme zprávu obdrželi s ta­ kovým obsahem, s jakým ji odesílatel odeslal, a že nebyla změněna třetí osobou. Nepopiratelnost zprávy znemožňuje odesílateli později popřít, že danou zprávu napsal. Tento bod s předchozími zcela nesouvisí, ale jeho význam může být v některých případech stejný, ne-li větší, jako zajištění autenticity a integrity. Uvedené problémy, tedy autentizaci odesílatele, integritu a nepopiratelnost zprávy řeší digitální podpis. Idea elektronického podpisu vychází ze zakódování zprávy pomocí asy­ metrické kryptografie a následné možnosti porovnat text s dekódovaným. Protože šifrování asymetrickou šifrou je časově velice náročné a výsledný podpis by byl zbytečně dlouhý, podepisuje se pouze hash. Podepisující vloží zprávu na vstup dané hashovací funkce (RFC definuje následující hash funkce: MD5, SHA-1, RIPE-MD/160, MD2, TIGER192, HAVAL5/160. Podpora všech algo­ ritmů není vyžadována. Použití dalších algoritmů není vyloučeno.) a výstup zašifruje svým soukromým klíčem. Příjemce dekóduje užitím veřejného klíče odesílatele podepsaný otisk, vloží obsah zprávy na vstup totožné funkce a výstup porovná. V případě shody je podpis platný. U emailu se hash vytváří ze zprávy včetně MIME hlaviček. Teprve tento otisk je po­ depsán příslušným soukromým klíčem podepisujícího a přiložen za nezměněný text. Takto podepsanou zprávu je možno následně zašifrovat. Šifrování zpráv Mnohé zprávy obsahují tajný materiál. Ať už se jedná o osobní poštu, průmyslové tajemství či materiály tajných služeb, je mnohdy zapotřebí přenést zprávu přes 11

3.1. BEZPEČNOSTNÍ PROTOKOLY nebezpečné kanály (zejména síť Internet) nebo ji uchovat na nedostatečně zabezpečených médiích. Je tedy nutné zajistit, aby zprávu mohli číst jen vyjmenovaní příjemci a aby ne­ mohla být nikým odposlechnuta. Utajení zpráv nevyvolává jen otázky technického řešení, ale také řadu politických problémů. Kvalitní silné šifry jsou dnes běžně dostupné a existuje možnost jejich zneužití k trestné činnosti. Některé státy, zejména USA, omezují šifrování zákonem z obavy před organizováním zločineckých a teroristických akcí. Povolují tedy jen tzv. lehké šifry, které by měly být prostředky tajných služeb či armády rozluštitelné. Před samotným šifrováním zprávy (souboru) by měly všechny implementace, pokud to charakter dat umožní, data komprimovat. Tím se nejen sníží velikost dat, která bude nutno zakódovat, ale zejména se tím sníží možnost využití slovníkového útoku na dekódování zprávy. OpenPGP standard definuje tři typy komprese: bez komprese, ZIP (RFC1951) a ZLIB (RFC1950). OpenPGP šifruje zprávu vždy užitím symetrické šifry pomocí jednorázového, náhodně vygenerovaného klíče. K vygenerování klíče není třeba znát žádné sdílené tajemství. Tento klíč se nazývá „session-key". Samotný klíč (session-key) se zašifruje pro každého příjemce zvlášť. Teprve zde je užita asymetrická kryptografie a použit veřejný klíč příjemce, popří­ padě opět symetrická šifra, tentokrát s klíčem vygenerovaným speciálním algoritmem na základě tajemství sdíleného s adresátem. Stejným způsobem si příjemce vygeneruje klíč, kterým bude moci „session-key" dekódovat. Tyto zakódované „session" klíče uvozují vý­ slednou šifrovanou zprávu. Je třeba si ale uvědomit, že bezpečnost zprávy je jen taková, jak silná je nejslabší použitá šifra. OpenPGP umožňuje kombinaci podepsané a šifrované zprávy. Pokud chceme tuto kom­ binaci použít, je nutné zprávu podepsat ještě před šifrováním. Radix-64 OpenPGP zpráva obsahující šifrovaná data, podpis nebo klíč je tvořena binár­ ními daty. Protože některé systémy neumí s takovými daty řádně pracovat, využívá tento protokol radix64 konverze, někdy též nazývané jako „ASCII armored". Implemetace tohoto algoritmu je povinná pro všechny klienty. Jedná se o převod binárních dat do 7bitového kó­ dování, tedy pouze do tisknutelných znaků. Je to kombinace base64 kódování a kontrolního součtu CRC. Takto zakódovaná data jsou navíc opatřena hlavičkou definující typ obsahu a příslušnou patičkou. Převod hesla na klíč Algoritmus převodu hesla na klíč (string-to-key S2K) se používá k vygenerování klíče symetrické šifry ze zadaného dlouhého hesla (tzv. passphrase). Užívá se na dvou místech. Na zašifrování soukromého klíče a na generování klíče pro symetricky kódované zprávy. OpenPGP definuje tři verze S2K algoritmu. V základní variantě se heslo předá na vstup hashovací funkce a výstup se použije jako klíč. Délka požadovaného klíče i výstupu z hash funkce závisí na použitých algoritmech. Pokud je výstup delší než požadovaný klíč, použije se jen potřebná část. Pokud je kratší, předá se heslo znovu hashovací funkci, tentokrát s 0 na začátku, potom se dvěma nulami na začátku, až se spojením výstupů získá potřebný klíč. 12

3.1. BEZPEČNOSTNÍ PROTOKOLY Další možností je verze s použitím soli. Algoritmus je totožný se základní verzí, pouze se na vstup spolu s heslem předává i tzv. sůl. Solí se v kryptografii myslí náhodný řetězec, který je přidán k heslu před hashováním a který zajistí, že i dvě totožná hesla mají různé hashe a není tedy poznat, že jsou stejná. Cílem je znesnadnit slovníkové útoky na heslo. Poslední způsob přidává navíc opakované hashování výstupu hash funkce. To prodlouží dobu potřebnou k provedení případného slovníkového útoku.

Klíč Součástí klíče je i seznam podporovaných symetrických algoritmů a hash algo­ ritmů v pořadí podle priority. Při šifrování by měl být použit první algoritmus ze seznamu, který má odesílatelův klient implementován. Zneplatňovat veřejný klíč má právo majitel soukromého klíče. Ten však může udělit oprávnění zneplatnit tento klíč i jiným klíčům. Toto oprávnění je součástí veřejného klíče a umožní klíč zneplatnit i v případě ztráty sou­ kromého klíče. Rovněž může být využito v podnikové sféře, kdy zaměstnavatel bude moci zneplatnit klíče svých zaměstnanců po ukončení pracovního poměru. Součástí klíče je vždy jedna nebo více uživatelských identit. Identita sestává z uživatel­ ského jména a emailové adresy. Ke každé identitě může náležet více certifikátů (podpisů). Aby byl klíč s danou identitou platný, musí být podepsán alespoň sám sebou. Ostatní uživa­ telé nemusí podepsat všechny identity, ale jen ty, které ověřili. Podepisující si rovněž může určit, zda vystavený certifikát (podpis) je jen pro jeho potřebu, nebo zda se může šířit spolu s klíčem i pro další uživatele.

Distribuce klíče Klíč je možno distribuovat jakoukoli cestou formou OpenPGP zprávy obsahující klíč a jemu příslušející údaje. Pro zjednodušení distribuce klíčů a zejména zjed­ nodušení distribuce příslušných podpisů (certifikátů) existují tzv. servery klíčů. Jsou to ve­ řejně přístupné servery, kam je možno nahrávat klíče a přihrávat jejich podpisy. Server klíčů nijak neověřuje platnost klíče. Slouží pouze jako veřejné úložiště. Platnost klíče si ověřuje uživatel na základě otisku staženého klíče, případně na základě příslušných podpisů důvě­ ryhodnými klíči. Majitel klíče může ke každé identitě uvést preferovaný server klíčů. Na ten by měli ostatní nahrávat svoje podpisy (certifikáty).

Použité algoritmy OpenPGP algoritmy uvedené v RFC2440 Algoritmy veřejného klíče: RSA (podpis + šifrování), RSA (pouze šifrování), RSA (pouze podpis), Elgamal (pouze šifrování), Elgamal (podpis + šifrování), DSA (standard digitálního podpisu). Symetrické algoritmy: IDEA, Triple-DES, CAST5, Blowfish, SAFER-SK128, DES, AES Kompresní algoritmy: ZIP, ZLIB Hash algoritmy: MD5, SHA-1, RIPE-MD/160, MD2, TIGER/192, HAVAL Povinné algoritmy: DSA (podpis), Elgamal (asymetrické šifrování), Triple-DES (symet­ rická šifra), SHA-1 (hash) 13

3.2. ZAČLENĚNÍ BEZPEČNOSTI DO EMAILU 3.1.3

S/MIME

S/MIME užívá vlastní typ zprávy Cryptographic Message Syntax (CMS) dle RFC3852 [18] a S/MIME Version 3.1 Message Specification (RFC 3851 [17]). Certifikáty jsou potom defi­ novány v S/MIME Version 3.1 Certificate Handling (RFC 3850 [16]) S/MIME v3 algoritmy uvedené v RFC3370 Pro tvorbu hashů se používá MD5 a SHA-1 Podepisovací algoritmy: DSA, RSA Ustavení klíče: Diffie-Hellman [kap. 2.2] Přenos klíče: RSA Symetrická šifra: Triple-DES, RC2 Převod heslo na klíč (S2K): PBKDF2 (RFC2898 PKCS#5) 3.2

Začlenění bezpečnosti do emailu

Způsoby začlenění bezpečnosti do emailové zprávy definuje RFC1847 [11] (Security Multiparts for MIME) z roku 1995. Tento dokument vytváří dva podtypy MIME typu Multi­ part. Jsou to Multipart/Signed pro podepsání nezašifrované zprávu a Multipart/Encrypted, umožňující přenášet zprávu šifrovaně. Povinným parametrem je protokol, který určuje al­ goritmus a u Multipart/Signed i parametr micalg, který udává použitou hash funkci. Multipart/Signed rozděluje zprávu na dvě části. První je obsah zprávy a druhá část je samostatný podpis. To umožňuje korektní zobrazení i v poštovních klientech nepodporují­ cích kontrolu elektronického podpisu. Vzhledem k zneplatnění podpisu při jakékoli změně textu zprávy se silně doporučuje zakódování zprávy do 7bitového ascii. Tím se vyloučí au­ tomatické zakódování smtp klientem v případě nemožnosti přenášet 8bitová či binární data, které by způsobilo zneplatnění podpisu. Multipart/Encrypted také rozděluje zprávu na 2 části. V první části jsou informace po­ třebné pro rozkódování zašifrované zprávy. Druhá část potom obsahuje proud zašifrova­ ných dat. OpenPGP využívá obě tyto rozšíření. S/MIME v3 podporuje pouze Multipart/Signed. Pro šifrovanou zprávu využívá vlastní MIME typ. 3.2.1

PGP/inline

Vkládá radix-64 kódované OpenPGP pakety přímo do těla zprávy. Neobsahuje žádné spe­ ciální hlavičky. Klienty tedy nemohou bez přečtení těla zprávy detekovat zabezpečení. Ve zprávách typu MIME umožuje zabezpečit pouze hlavní textové tělo bez příloh. 3.2.2

PGP/mime

Definuje způsob začlenění PGP funkcionality do emailové komunikace. Je využíváno pří­ slušných podtypů Multipart definovaných v RFC1847 [11]. 14

3.2. ZAČLENĚNÍ BEZPEČNOSTI DO EMAILU Pro šifrovanou zprávu se využívá MIME rozšíření Multipart/Encrypted a zavádí pro­ tokol „application/pgp-encrypted". První část zprávy obsahuje text „Version: 1" a v druhé části je kompletní OpenPGP zpráva včetně všech PGP hlaviček. Emailová zpráva se šifruje včetně MIME hlaviček. Pro samostatný podpis užívá pgp/mime rozšíření Multipart/Signature dle RFC1847 a protokol application/pgp-signature. Aby bylo umožněno zkontrolovat podpis na jeden průchod, parametr micalg obsahuje pgp-*hash funkce*. RFC3156 [14] definuje: „pgp-md5", „pgp-shal", „pgp-ripemdl60", „pgp-md2", „pgp-tigerl92", and „pgp-haval-5-160". Násle­ duje text zprávy a ve druhé části je umístěn samostatný podpis v ASCII-armored formě OpenPGP zprávy. Pro zprávu současně podepsanou i zašifrovanou jsou definovány dvě možnosti. Mů­ žeme využít vnořovaného MIME a podepsanou zprávu multipart/signed zašifrovat do multipartencrypted. Druhou možností je použít kombinovanou (podepsanou a zašifrova­ nou) OpenPGP zpráva a vložit ji do multipart/encrypted. Veřejný klíč je možno distribuovat jako MIME část emailu typu „application/pgp-keys" v OpenPGP ASCII-armored podobě. 3.2.3

S/mime

S/mime CMS (Cryptographic Message Syntax) zpráva může být do emailové zprávy začle­ něna podle RFC3851 [17] a to zvolením typu zprávy application/x-pkcs7-mime a nastave­ ním Content-Disposition na attachement s názvem souboru smime a příponou .p7m, .p7c, p7z či p7s podle typu vložené CMS zprávy. U podepsané, nezašifrované zprávy můžeme místo uvedeného způsobu použít, stejně jako u protokolu OpenPGP, rozšíření Multipart/Signed dle RFC1847 [11]. V takovém řípadě nastavíme protkol na application/pkcs7-signature a parametr micalg na jednu z hodnot: „md5", „shal", „sha256", „sha512", ale i jinou, dle užité hashovací funkce. Do první části vložíme podepisovaný email a do druhé příslušný podpis ve formátu CMS zprávy.

15

Kapitola 4

Testování klientů elektronické pošty 4.1

Příprava a testování

Příprava testování spočívala v definování sledovaných problémů a vytvoření tří sad testo­ vacích emailů. Pro každého z testovaných klientů jsou uvedeny instalační parametry, případně pluginy, nutné ke zprovoznění práce se zabezpečenou poštou. Testovací emaily jsou otevřeny v jed­ notlivých klientech a posuzuje se schopnost a komfort jejich čtení. Následně jsou ze všech klientů odeslány emaily ve všech formátech a sepsán postup jak takový email odeslat a zda je to vůbec možné. 4.1.1

Testovací sada pgp/mime

Tato sada testuje schopnost klientů zobrazit emaily odeslané ve formátu dle RFC 3156 MIME Security with OpenPGP [14]. •

pgp/mime šifrovaný (rfc3156/4)

•

pgp/mime podepsaný a pgp/mime podespaný se špatným podpisem (rfc3156/5)

•

pgp/mime podepsaný a šifrovaný (vložené mime dle rfcl847 [11]) a totéž se špatným podpisem (rfc3156/6.1)

•

pgp/mime podepsaný a šifrovaný (kombinovaně) (rfc3156/6.2)

•

pgp/mime klíč (application/pgp-key) testuje, zda klient dokáže naimportovat při­ jatý klíč (rfc3156/7)

4.1.2

Testovací sada pgp/inline

Zabezpečené pouze tělo zprávy pomocí OpenPGP (rfc2440 [13]) je vložené do zprávy bez mime hlaviček, případně jako typ t e x t / p l a i n . Přílohy jsou v dešifrované podobě. Cílem je také zjistit, zda klienti upozorní uživatele, že část zprávy není zabezpečena. •

pgp/inline šifrované tělo, nešifrované přílohy 16

4.2. VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ •

pgp/inline podepsané tělo, nepodepsané přílohy + totéž s neplatným podpisem

•

pgp/inline šifrované a podepsané tělo, nešifrované přílohy

Každá příloha byla zabezpečena zvlášť a přiložena s příponou .pgp Snahou bylo zjistit, zda klienti umí tyto přílohy dešifrovat. •

pgp/inline šifrované tělo a každá příloha zvlášť

•

pgp/inline šifrované a podepsané tělo i každá příloha zvlášť

4.1.3

Testovací sada s/mime

•

s/mime šifrovaný

•

s/mime podepsaný

•

s/mime podepsaný a šifrovaný

4.2

Výsledky testování jednotlivých klientů

4.2.1

MS Outlook Express

Podpora s/mime je vestavěná. Zprávy jsou dešifrovány a pravost podpisu ověřována au­ tomaticky. V dialogu odesílání zprávy lze šifrovaní, podepisování či kombinaci aktivovat kliknutím na příslušné ikony. V seznamu jsou zabezpečené zprávy označeny příslušnou ikonou. Vzhledem k uzavřenosti kódů komerčního klienta a minimální podpoře rozšíření neexis­ tuje rozšíření přidávající podporu pgp/mime. Pro pgp/inline můžeme doinstalovat plugin GPGOE 0.4.1, který je také součástí balíku WinPT (http://winpt.sourceforge.net/) obsahu­ jícího: GPG, Tray, Explorer Extensions. Outlook Express plugin, Eudora plugin, Passphrase agent. Pro využití PGP zabezpečení musí běžet GPGOE. Ten při odesílání zamění funkci standardních s/mime tlačítek za GPG. Pro čtení stačí otevřít vybranou zprávu. V případě účtu imap musí být zpráva načtena ještě před otevřením, jinak se pgp obsah nerozpozná. Program zobrazí zvláštní okno s ověřením podpisu a rozšifrovanou zprávu. Ve zprávě zů­ stává ascii armored pgp paket. Pro odeslání je postup stejný jako pro s/mime. Po odeslání zvolíme klíče, které se použijí. Nelze zvolit šifrování i podepisování současně. Při standard­ ním nastavení pošle PGP zprávu jako text/plain, ale také alternativně jako text/html spolu s html tágy Toto rozšíření se během testování chovalo nestabilně a při jeho používání dochá­ zelo k pádu aplikace. Za nejzásadnější problém s tímto rozšířením však považuji skutečnost, že při chybě šifrování/podepisování nezastaví proces odesílání a odešle email bez zabezpe­ čení. 17

4.2. VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ 4.2.2

MS Outlook 2000, 2002, 2003

Všechny tři testované verze mají vestavěnou podporu s/mime a existuje pro ně GPGExch plugin (http://www3.gdata.de/gpg/) pro podporu pgp/inline. V případě testů na stroji Intel Celeron + Win XP Home i AMD Opteron 64bit + Win XP Proffesional se mi nepodařilo zabezpečené zprávy odeslat. Během čtení aplikace dokonce zprávu nenávratně přepsala. Podle internetových diskuzí by však uvedené rozšíření mělo být pro pgp/inline použitelné. PGP/mime podporováno není vůbec. 4.2.3

Mutt devel 1.5.10

Primárně určen pro unixové os, ale existují i binární balíčky pro MS Windows s Cygwin. Ovládání bezpečnostních funkcí je snadné. Na nezabezpečené části Mutt viditelně upozorní a sám neumožní odeslání zprávy ve formátu pgp/inline s nezabezpečenými přílohami 1 . Tím má uživatel jistotu, že zabezpečil celou zprávu. Lze využít pgp/mime, pgp/inline (bez příloh) i s/mime. Pro OpenPGP protokol lze využít pgp 2.x 5.x a 6.x a kompatibilní, nebo gpg [6]. Pro s/mime využívá openssl. Pokud chceme využívat služeb s/mime, je třeba při kompilaci uvést parametr -with-ssl. OpenPGP žádné speciální parametry nevyžaduje. Před použitím je však třeba oba protokoly nastavit. Veškeré nastavení se provádí v konfiguračním souboru Muttu. Nejjednodušší je použít vzorové konfigurační skripty z instalačního balíčku. Jsou umístěné v adresáři contrib a pojmenované podle jednotlivých verzí. Pro OpenPGP {pgpl.rc pgp5.rc pgpó.rc a gpg.rč) by mělo stačit vybraný soubor nakopírovat do systému a v -/.muttrc jej načíst (např. source „ ~ / .mutt/gpg.rc"). Pro s/mime (smime.re) je však navíc nutné nastavit cesty k certifikátům a klíčům. Při standardním nastavení klient dešifruje/ověřuje zprávy automaticky. U pgp/inline je třeba většinou stisknout Esc-P Automaticky je zpráva dešifrována/ověřena pokud hlavička Content-Type obsahuje atribut x-action, který je přidáván do odesílaných zpráv. Stabilní verze Muttu [kap. 4.2.4] navíc požaduje nastavený typ mime na application/pgp. Tento způsob je ale nestandardizovaný a dnes se nedoporučuje. Pro šifrování/podepisování pgp/mime, či pgp/inline stačí v dialogu odesílání zprávy stisknout klávesu p, čímž se vyvolá menu s nabídkou způsobu zabezpečení. Pro s/mime takové menu vyvoláme standardně klávesou S. 4.2.4

Mutt stable 1.4.2

Oproti Mutt 1.5.10 neumožňuje menu pgp vybrat typ. Standardně je používán pgp/mime. Změnu formátu na pgp/inline je třeba předem vynutit zadáním konfiguračního parametru set pgp_create_traditional=yes. Nejedná se však o klasické PGP/inline, ale o jeho proprietární úpravu. Hlavička zprávy je nastavena na Content-Type: application/'pgp; íormat=text; x-action=AKCE. Výraz AKCE v uvedeném termínu je nahrazen slovem sign, nebo encrypt 1.

Pokud tento formát zvolíme u zprávy s přílohami, odmítne ji poslat a nabídne použití formátu pgp/mime.

18

4.2. VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ v závislosti na typu zabezpečení. Pokud je zpráva podpepsána i šifrována, pak je zvoleno také encrypt S tímto formátem však mají ostatní klienti problém a většinou jej zobrazí jako prázdný s přílohou typu application/pgp, kterou nedokáží zpracovat. Číst lze stejně jako ve vývojové verzi. S/mime protokol nelze ve standardní instalaci užít. 4.2.5

The Bat!

Běží na platformě MS Windows. Podporuje pgp/mime, pgp/inline i s/mime. Neupozor­ ňuje na nezabezpečené přílohy při čtení zprávy. Při odesílání ve formátu pgp/inline přílohy nezabezpečuje a uživatele o tom nijak neinformuje. Lze využít: interní openpgp (RSA do 4096bit,128-bit IDEA, MD-5), pgp 2.6.3, 5.5.x, 6.0.x a novější, gpg, s/mime interní, s/mime MS CryptoAPI. Instalace nevyžaduje žádné speciální parametry. Nastavení s/mime je v menu Options>S/MIME, pro OpenPGP v Tools->OpenPGP->OpenPGP Preferences U každého emailu je tlačítko pro dešifrování/ověření (v náhledu i po otevření zprávy). U pgp/mime klient vytvoří novou část emailu Part.txt s informací o tom, že je email za­ bezpečen a zobrazí pouze ji, dokud uživatel nestiskne dešifrovací tlačítko. U podepsaných emailů se po stisknutí zobrazí výstup zabezpečovacího programu. Po dešifrování v emailu zůtává přidaná informační část Part.txt (pgp/mime a s/mime) či ASCII Armored pgp paket u pgp/inline. Dešifrovaná část a přílohy jsou zobrazeny jako další části. V dialogu psaní zprávy je menu Privacy, v němž je možné nastavit jaké zabezpečení bude použito pro aktuální email. Pokud aktivujeme současně OpenPGP i s/mime, je zpráva zabezpečena nejprve pomocí pgp a následně také pomocí s/mime. 4.2.6

Exmh 2.7.0

Tcl/tk nadstavba unixového nmh klienta. Program plně podporuje pgp/mime a vůbec ne­ podporuje s/mime. Tento klient dříve podporoval jen mutaci pgp/application. Kromě toho, že užívá jiná klíčová slova v x-action než Mutt, přidal si ještě hlavičku x-format a nastavo­ val ji na ŕexŕ pro textový obsah, nebo na mime a šifroval do ní mime tělo. V této verzi je dostupný i formát pgp/inline, kdy je typ nastaven správně na text/plain, ale algoritmus je použit stejný jako pro pgp/application, který je možno také vybrat. Problém tedy nastane pokud odešleme zprávu s přílohami. Zabezpečena je celá mime zpráva a ostatní klienti ji potom neumí správně zobrazit. Podporované verze jsou: pgp 2, pgp 5, pgp 6 a gpg. Instalace nevyžaduje speciální parametry. Nastavení nalezneme v menu Preferences>General PGP Interface a nebo Preferences->GnuPG interface v závislosti na použité verzi. Při čtení emailu zobrazí tlačítko pro dešifrování/ověření. Pokud má email více MIME částí, jsou zřetelně oddělené a číslované. Pokud je zabezpečena jen část emailu, je tlačítko v dané části. Je tedy zřetelné, zda jsou zabezpečeny i přílohy. V dialogu nové zprávy je menu Crypt se standardním nastavením dle Preferences a lze je pro konkrétní zprávu upravit. Verze pgp, typ PGP/inline, PGP/mime a application/pgp. Program neumí automaticky nastavit použitou codepage. 19

4.2. VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ 4.2.7

Mozilla Thunderbird 1.0.7

Multiplatformní (Windows, Linux, Mac) grafický poštovní klient. Standardně podporuje protokol s/mime. S rozšířením má i plnou podporu pro pgp/mime a pgp/inline. Informace o stavu zabezpečení zprávy je zřetelná, stejně jako označení nezabezpečené přílohy. Na ode­ sílání nezabezpečených příloh upozorní a také nabídne změnu formátu, nebo samostatné šifrování každé přílohy. Nepodporuje pgp, ale pouze GnuPg. S/mime je vestavěný a nepotřebuje žádnou speciání instalaci. OpenPGP potřebuje do­ instalovat rozšíření Enigmail. Nastavení s/mime nalezneme v menu Úpravy->Nastavení účtu->Zabezpečení, pro OpenPGP se nám vytvoří menu v hlavní nabídce nazvané Enigmail nebo OpenPGP. Dešifrování/ověřování lze nastavit automaticky nebo stisknutím ikony pera (zámku), která se u emailu zobrazuje. Enigmail doplňuje k emailu barevný proužek (zelený nebo červený) signalizující a popisující stav zabezpečení daného emailu. Pokud obsahuje neza­ bezpečené části, je navíc do textu hlavní zprávy přidána tučně informace, že přílohy nejsou zabezpečeny. V dialogu odeslání zprávy je ikona Zabezpečení, nebo zvlášť ikona pro s/mime a Open­ PGP, pokud je doinstalován Enigmail. V ní zvolíme, zda šifrovat či podepisovat a vybraný formát. Umožňuje užití s/mime i OpenPGP současně. Kompletní zprávu zabezpečenou po­ mocí OpenPGP pak zabezpečí pomocí s/mime. 4.2.8

Mozilla Suite 1.7.12

Platí totéž co pro Mozilla Thunderbird 4.2.7. 4.2.9

Balsa 2.2.6

Unixový grafický emailový klient pro prostředí Gnome. Pro aktivaci podpory OpenPGP (pgp/mime i pgp/inline) je třeba instalační parametr —with-gpgme=gpgme-conf i g . Pro podporu pgp/smime potom — e n a b l e - s m i m e . Při čtení emailu s nezabezpečenými přílohami není tato skutečnost na první pohled zřejmá. Jde však zobrazit MIME strom zprávy a v něm je přehledně vyznačeno, které části jsou zabezpečeny a jak. Vyžaduje gpg verze 1.9 a vyšší a také gpgme. Nastavení implicitních pravidel najdeme v menu N a s t a v e n i - > I d e n t i t y , ostatní až při odesílání. Dešifrování/ověřování probíhá automaticky, případně po stisku ikony zabez­ pečení. Při odesílání zvolíme typ zabezpečení i formát v menu Volby. Přílohy u formátu pgp/inline nezabezpečuje a nijak na to neupozorňuje. 4.2.10 Pine 4.52 Unix a MS Windows textový klient. Standardně neobsahuje žádné zabezpečení. V distribuci je patch pro s/mime využívající openssl. Integrace do klienta je dobrá, ale neumí ověřit pod­ pis uvnitř zašifrované zprávy. V případě současného podepisování i šifrování pine napřed 20

4.2. VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ šifruje a až potom podepisuje. Podporu pgp/inline získáme např. aplikovaním filtrů z ba­ líčku pinepgp. Při čtení emailu je zřetelné, která část je zabezpečena, ale při odesílání není uživatel upozorněn, že odesílá přílohy nezabezpečené. Filtry pracují s pgp 2.6.x, 5.x, 6.5.x a gpg větším než 1. Při hledání podpory pgp/mime pro pine jsem nalezl pouze filtry příchozí pošty, které zprávu dešifrují/ověří a v nezabezpečené podobě uloží do složky Temp. Tam šiji uživatel může přečíst a následně smazat. Pokud chceme využívat funkcí s/mime, je třeba před kompilací programu aplikovat patch, který najdeme v distribučním balíčku v adresáři c o n t r i b / smime a kompilovat s pod­ porou ssl (SSLDIR=, SSLINCLUDE=, SSLIB=). Dále je třeba umístit klíče a certifikáty na požadované místo dle pine/README. smime. Při čtení podepsané nebo nejprve šifrované a potom podepsané zprávy je podpis ověřen automaticky. Pokud je zpráva šifrovaná, vy­ zve program ke stisknutí zkratkové klávesy a zadání hesla a dešifruje ji. V dialogu odeslání zprávy se v menu nabízí klávesa pro šifrování a podepsání. Po nainstalování filtrů pinepgp 2 si každý uživatel spustí skript dle požadované verze pgp (např. p i n e g p g - i n s t a l l ) a ten v jeho konfiguračním souboru nastaví příchozí i odchozí filtry. Pokud jako parametr skriptu přidá ještě svůj email, bude zpráva vždy šifrována i pro něj. Před zobrazením projde pgp/inline zpráva filtrem, který se v případě potřeby dotáže na heslo k vašemu klíči. Zpráva je doplněna o textové označení začátku a konce za­ bezpečení a výstup zabezpečovacího programu. Při odesílání máme na výběr z filtru, který zprávu podepíše, zašifruje, nebo obojí. 4.2.11 Becky! 2.22.02 Windowsový komerční grafický klient. Zabezpečení je řešeno formou pluginů. Pro pgp je dodáván ve standardní distribuci. Pro GnuPg existuje plugin BkGnuPg 3 . Integrace pluginů do klienta není příliš dobrá. Gpg plugin dešifruje pgp/inline tak, že vloží dešifrovaný text před OpenPGP paket, který zůstane vidět. U pgp/mime předává zprávu programu jen jed­ nou. Při použití pgp/mime encaps (RFC3156/6.1 [14]) tak nedojde k ověření podpisu uvnitř šifrované zprávy. Na nezabezpečené přílohy neupozorňuje ani u příchozích, ani u odchozích zpráv. Pluginy umí užít programy pgp, gpg a integrovaný s/mime. Jako většina Windows aplikací obsahuje interaktivní instalátor. Plugin s/mime je třeba stáhnout zvlášť a *.dll soubory přehrát do adresáře plugins. U BkGnuPg je na stažení i verze s instalátorem. Nastavení najdeme v menu T o o l s - > P l u g - I n s S e t u p pro každý plugin zvlášť. V náhledovém okně zprávy zvolíme v menu Tools->(GnuPg PGP S/MIME): Decrypt And Verify. Tato funkce zobrazí výstup bezpečnostního programu a zprávu dešifruje/ověří. U PGP/mime vidí uživatel místo obsahu zprávy jen hlavičky a musí vlastnoručně aktivo­ vat GPG dešifrování. Zpráva se pak zobrazí rozšifrovaná dle očekávání. Problém nastane při užití mime encapsulated kombinace podpisu a šifrování (RFC3156/6.1). Klient email 2. 3.

Pinepgp filtry http://www.megaloman.com/~hany/software/pinepgp/. BkGnuPg http://hp.vector.co.jp/authors/VA023900/gpg-pin/index_en.html.

21

4.2. VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ správně rozšifruje a zobrazí, ale ukáže nám výstup pouze prvního průchodu gpg a tudíž neověří podpis. U PGP/inline vidí uživatel Radix-64 podobu PGP paketu. Není problém si tedy uvědomit, že se jedná o šifrovanou zprávu a aktivovat dešifrování z menu. Před Open­ PGP paket se pak vloží rozšifrovaný text. U S/MIME šifrované zprávy se zobrazí hlavičky emailu jako u pgp/mime, ale jsou doplněné o textovou informaci, že je to s/mime šifrovaná zpráva a jak máme postupovat k dešifrování. Pokud je zpráva pouze podepsaná, nejsme nijak upozorněni, pouze z přílohy smime.p7s máme šanci poznat existenci podpisu a ručně vyvolat ověření. V dialogu nové zprávy v menu T o o l s jsou položky názevpluginu: funkce, pomocí nichž aktivujeme požadované zabezpečení. Po jejich aktivaci nám klient nabídne možnost nasta­ vení a výběr klíčů, hesla a provede popsanou operaci. Email ale neodešle. U PGP/MIME se tedy tělo bez příloh přepíše na OpenPGP paket a u PGP/MIME s S/MIME se dokonce vše přesune do příloh a tělo vidět není. Email se ale po zašifrování sám neodešle a je třeba tak učinit ručně. 4.2.12 Syplpheed-Claws 1.9.15 Grafický klient pro unixové systémy a MS Windows s Cygwin. Zabezpečení je řešeno for­ mou pluginů. S/mime lze využít pouze s pluginem etpan! Privacy^ a to pouze pro čtení. Pluginy pro OpenPGP jsou dodané přímo s distribucí. Integrace s klientem je dobrá. Ten dokáže v seznamu zpráv zobrazovat ikonku zabezpečení a ke každé zprávě přidat ikony se signalizací zabezpečení a možností zobrazit výstup zabezpečovacího programu. Při čtení pgp/inline podepsané zprávy se zobrazí OpenPGP hlavičky v textu a tudíž je zjevné, co bylo podepsáno. V případě nešifrovaných příloh není tato skutečnost viditelná. OpenPGP plugin by měl podle dokumentace také umět ověřit s/mime podpis pomocí gpgme. To se mi však nepodařilo ověřit. Přílohy ve formátu pgp/inline odesílá nezašifrované a uživatele nijak neinformuje. Využít lze pouze gpgme. Při instalaci nejsou potřeba zádně speciální parametry, ale po spuštění je třeba pluginy aktivovat. V Nastavení->Plugins->Nahrát zásuvný modul zvolíme postupně pgpcore.so, pgpinline.so i pgpw.ime.so. Nastavení automatické kontroly apod. je možné prostřednic­ tvím menu Nastavení->Předvolby->Zásuvné moduly->GPG. Při čtení zprávy se podpis ově­ řuje automaticky nebo pomocí zabezpečovací ikony. V odesílacím dialogu volíme způsob zabezpečení v menu Options->Privacy System 4.2.13 Sylpheed 2.1.3 Jednodušší verze klienta Sylpheed-Claws4.2.12. Nemá pluginy, OpenPGP je při instalaci standardně povoleno. PGP/mime dešifruje/ověřuje automaticky. PGP/inline nečte, umí však použít ASCII-armored formát pro šifrování i podpis. Pokud však odešleme ASCIIarmored zprávu s přílohami nebo šifrovanou i podespanou, klient zašifruje/podepíše ve 4.

etpan! Privacy http://claws.sylpheed.org/downloads/etpan-privacy-0.9_gtk2.tar.gz.

22

4.3. ZÁVĚRY Z TESTOVÁNÍ KLIENTŮ formátu pgp/inline celou mime zprávu. Program neumožní odeslat nezabezpečenou pří­ lohu. Místo toho vytvoří zprávu, kterou nejde v jiných klientech standardním způsobem přečíst. Nastavovat bezpečnost můžeme v Nastavení->Nastavení aktuálního účtu->Soukromí. Při odesílání zprávy zvolíme PGP Sign, PGP Encrypt nebo kombinaci (přímo pod předmě­ tem). Formát lze měnit pouze v nastavení. 4.2.14 Klienti nepodporující žádné zabezpečení Při testování následujících klientů bylo zjištěno, že nepodporují žádný z uvedených způ­ sobů zabezpečení pošty a pro žádný z nich mi není známá existence nějakého rozšíření, které by podporu přidalo. •

Incredimail (http://www.incredimail.com)

•

Mailer 3.1 http://danielturecek.wz.cz/

•

Pimmy http://www.geminisoft.com/en/download.aspx

•

KomaMail http://www.koma-code.de/

•

yMail http: / /www.spacejock.com/

•

AllegroMail (http://slunecnice.cz)

•

Popcorn email http://ultrafunk.com/products/popcorn/

•

G-Lock EasyMail http://www.glocksoft.com/em/

4.3

Závěry z testování klientů

PGP/INLINEje nejdostupnějším, zároveň však nejproblémovějším a většinou nejméně po­ hodlným formátem pro zabezpečení pošty. Následující výhody i nevýhody oproti dalším formátům jsou zapříčiněny tím, že pgp/inline není koncipován pro MIME zprávy 5 . Mohou ho použít uživatelé libovolného poštovního klienta. Pokud daný klient tento formát nepod­ poruje a není pro něj dostupné rozšíření, lze využít externího šifrovacího nástroje, který umí pracovat s obsahem schránky, případně s obsahem aktuálního okna. Tento formát ovšem přináší řadu problémů, z nichž asi nejzásadnějším je práce s přílohami. Tento formát ne­ umožňuje zabezpečení příloh. Až na několik výjimek klienti označí email za zabezpečený a podpis za platný a žádným způsobem neinformují uživatele, že se tato informace týká pouze těla zprávy. Stejně tak při odesílání téměř žádný testovaný klient neupozorňuje na to, že přílohy odešle nezabezpečené. S dalším problémem se setkáváme pokud odesíláme 5.

Všechny bezpečnostní prvky jsou v textové podobě v těle emailu.

23

4.3. ZÁVĚRY Z TESTOVÁNÍ KLIENTŮ alternativní MIME části k tělu zprávy. Ty obvykle nejsou textové, ale např. html, a tak je není možné touto metodou regulérně zabezpečit. V neposlední řadě je zde ještě problém s kódováním podepsané zprávy při přenosu. Podepsaná zpráva by měla být před odeslá­ ním převedena do 7bitového kódování, např. do formátu quoted-printable. V opačném pří­ padě totiž může dojít k pozměnění zprávy některými servery a k porušení podpisu. Toto jednodušší pluginy ani externí aplikace bohužel nezajistí. Pgp/inline se potýká ještě s jed­ ním, implementačním, problémem. Jelikož jsou bezpečnostní hlavičky až v těle zprávy, není možné detekovat zabezpečení pro automatické dešifrování/ověřování zprávy, ale ani zob­ razení identifikace v seznamu zpráv jinak než parsováním těla každé zprávy, což je časově dost náročné. Stabilní verze klienta Mutt a Exmh se snaží některé problémy s pgp/inline odstranit. Vznikl tak proprietární nejednotný formát application/pgp. Hlavička nese informaci o tom, že je email zabezpečen, a její atribut informaci o typu zabezpečení. Díky tomu již není nutné parsovat každou zprávu a je možné zobrazovat informaci o zabezpečení v seznamu a to i pokud máme k dispozici pouze hlavičky, např. u protokolu IMAP. Nastavení typu na appli­ cation/pgp však způsobují potíže se zobrazením na ostatních klientech. Ti obvykle takovou zprávu zobrazují jako prázdnou s přílohou typu application/pgp a není správně zpraco­ vána. Lepší se tak zdá být řešení použité ve vývojové verzi Muttu, které zprávu označí jako text/plain, ale přidá mu atribut x-action. Mutt tak dostane potřebné informace a ostatní klienti by měli zprávu zobrazit v pořádku. Exmh však zachází ještě dál a snaží se řešit i problém s přílohami. Definuje tedy ještě atribut x-format a pokud má zpráva přílohy, za­ bezpečí celou mime zprávu a nastaví uvedený atribut na mime. Toto řešení je ovšem zcela nekompatibilní s ostatními klienty. S/MIME a PGP/MIME jsou určeny pro použití v MIME zprávách. Zabezpečena je celá MIME zpráva kromě hlavičky. Je tak vyřešen problém s přílohami. Vzhledem k tomu, že se zabezpečuje celá MIME zpráva a tudíž i hlavičky jednotlivých částí, může zabezpečovací program zajistit také správné přenosové kódování. Tyto výhody však znamenají složitější implemetaci. Vyžadují užší spolupráci klienta s případným pluginem. Zatímco u pgp/inline stačilo pluginu, aby měl ve vhodnou chvíli přístup k textu zprávy, u těchto formátů je již za­ potřebí přístup k celé MIME zprávě, což je u některých klientů problematické. Patří mezi ně bohužel i hodně používaní MS klienti MS Outlook a MS Outlook Express. Ty mají automa­ ticky podporu s/mime, ale plugin pro pgp/mime pro ně není. Pokud pro klienty existuje plugin přidávající podporu těchto protokolů, pak je většinou dobře integrován do klienta a pohodlný na ovládání. U pgp/inline to nebývá pravidlem. Formát s/mime je častěji inte­ grován přímo do klienta, nebo je jeho podpora přidávána formou patchů. Pgp/mime bývá častěji šířen pomocí pluginů, které většinou podporují i starší pgp/inline. Pokud máme možnost používat oba dva formáty, je výběr nejsložitější v případě odesí­ lání podepsané, nešifrované zprávy. Příjemci mohou být neznámí, nemusí být sami vlast­ níky šifrovacích klíčů a tudíž není zřejmé, který formát podpisu budou schopni ověřit. Ne­ zbývá než si nějaký vybrat, nebo se s příjemci předem dohodnout. Jako vhodné řešení do budoucnosti bych považoval rozšíření RFC1847 [11], podle kterého jsou tvořeny zabezpe­ čené MIME zprávy, o možnost přidat více podpisů k jedné zprávě. To by umožnilo nejen 24

4.3. ZÁVĚRY Z TESTOVÁNÍ KLIENTŮ podepsat zprávu oběma formáty a nechat na příjemci, který podpis ověří, ale také opatřit jednu zprávu podpisy více osob, jak je to běžné v papírové komunikaci.

25

Kapitola 5

Implementace Součástí práce bylo na základě výsledků testů naimplementovat podporu bezpečnosti do klienta, který ji nemá, případně vylepšit nějakou stávající implemetaci. Požadavkem bylo co nejméně zasahovat do zdrojových souborů programu a podporu přidat nejlépe pomocí externího filtru. Z klientů jsem vyřadil ty, které nejsou obecně známé a tudíž je předpoklad minimální uživatelské základny. U známějších klientů je podpora většinou dobrá, nebo je­ jich implementace vyžadují velký zásah do samotného programu. Naprosto nedostatečná je podpora OpenPGP formátu u MS Outlook a MS Outlook Ex­ press. Vzhledem k uzavřenosti kódu a neexistenci zobrazovacích či odesílacích filtrů není implementace za daných podmínek možná. V úvahu připadalo přidání podpory do unixového textového klienta Exmh. Nakonec byl však také z důvodu malé uživatelské základny vyřazen. Zaměřil jsem se na kompatibilitu klientů Pine a Mutt, pravděpodobně nejpoužívanějších textových klientů, při zasílání zabezpečené pošty s přílohami. Z testů plyne, že Mutt pod­ poruje jak s/mime, tak pgp/mime i pgp/inline. Program Pine je na tom hůře. S/MIME je podporován patchem a PGP/MIME tento klient nepodporuje vůbec. Vzhledem k návrhu programu by implementace PGP/MIME vyžadovala velký zásah do zdrojů. Rozhodl jsem se využít podpory PGP/INLINE pomocí zobrazovacích filtrů pinepgp. Pine dokáže zprávu pgp/inline přečíst, ale Mutt nedovolí odeslat zabezpečenou zprávu s přílohou v tomto for­ mátu. 5.1

Patch pro Mutt 1.5.10i

Inspiroval jsem se oblíbeným rozšířením Enigmail pro Mozillu Thunderbird a balík Mo­ zilla Suite. Toto rozšíření se snaží o maximální kompatibilitu s ostatními klienty. Podpora OpenPGP je v Muttu velice dobrá. Striktně však zakazuje odeslání pgp/inline zprávy s pří­ lohou. Rozšíření Enigmail tuto možnost připouští. Při pokusu o odeslání dá uživateli vybrat, jak chce se zprávou naložit. Jednou z možností je odeslání zprávy ve formátu PGP/MIME. Tento formát nemá s přílohami problém a stejnou možnost nabízí svým uživatelům také klient Mutt. Jako další možnost nabízí Enigmail odeslání ve formátu pgp/inline a šifro­ vání/podepsání každé přílohy zvlášť. Toto řešení není zcela ideální, protože není zajištěna vazba mezi přílohami a textem, ale pokud je o tom uživatel dostatečně informován a sou­ hlasí, je to relativně bezpečný způsob odeslání emailu do klienta, který podporuje pouze tento jednodušší formát. 26

5.1. PATCH PRO MUTT 1.5.101 Při zvoleném formátu pgp/inline kontroluje originální Mutt zda je email text/plain a po­ kud není, zobrazí varování, že nelze použít tento formát, a nabízí možnost užít pgp/mime. Patch mění tuto kontrolu a pokud zjistí, že má email více částí, zobrazí možnost přechodu na pgp/mime nebo užití výše uvedné metody se šifrováním každé zprávy samostatně. Zá­ roveň uživatele informuje o možném riziku porušení integrity mezi textem zprávy a přílo­ hami. Pokud uživatel zvolí novou metodu, jsou text/plain části s dispozicí nastavenou na inline zabezpečeny metodou pgp/inline a všechny části s dispozicí attachementjsou zabez­ pečeny samostatně. Jejich typ se mění na application/octet-stream, kódování na BASE64 a k názvu souboru je přidána přípona -pgp- Uživatel klienta podporujícího pouze text/plain si tak může pohodlně přečíst text zprávy a přílohy si uloží a rozšifruje či ověří podpis pomocí externího programu. Patch přidává 3 nové konfigurační parametry. Jsou to pgp_attach_sign_command, de­ finující příkaz pro samostatné podepsání přílohy, pgp_attach_encrypt_sign_command pro podepsanou a zašifrovanou přílohu a také pgp_attach_encrypt_only_command pro zašifro­ vanou nepodepsanou přílohu. Tyto proměnné udávají, stejně jako obdobné pro pgp/mime, příkaz, pomocí kterého je zpracována příloha při zvolení nově implementované metody odeslání.

27

Kapitola 6

Závěr Závěrem lze říci, že možnosti zabezpečení elektronické komunikace jsou dobré. Bezpeč­ nostní formáty PGP/INLINE, PGP/MIME i S/MIME poskytují při správném užití vysokou míru zabezpečení a jsou běžně dostupné. Pro platformu Windows i Linux existuje řada kli­ entů podporujícíh alespoň jeden z nich. Existence třech formátů sice vytváří konkurenční prostředí a tudíž dává motivaci vývojářům se navzájem předhánět v kvalitě, ale také způ­ sobuje potíže v kompatibilitě zasílaných zpráv. Každý z protokolů má své zastánce a mnozí výrobci poštovních klientů mají tendenci implementovat pouze jeden z protokolů. Ideální klient pro používání zabezpečené pošty by měl umět přečíst zprávu zaslanou libovolným klientem, ale také odeslat zprávu čitelnou v libovolném klientu podporujícím některý formát zabezpečení. Tyto požadavky splňuje (alespoň v rámci testovaných klientů) multiplatformní grafický poštovní klient Thunderbird s rozšířením Enigmail. Z textových multiplatformních klientů se k podobnému ideálu blíží Mutt, který neumožňuje zaslat email s přílohou pro klienta podporujícího pouze formát PGP/INLINE. Jako součást této bakalář­ ské práce byl naprogramován opravný patch, který napodobuje řešení této problematiky zmíněným rozšířením Enigmail a tento nedostatek odstraňuje. Přestože existuje textový i grafický klient umožňující zaslat zprávu v libovolném for­ mátu, je třeba předem vědět, jaké formáty podporuje klient adresáta. Schází možnost opatřit zprávu bezpečnostními prvky obou protokolů, aby mohla být přečtena v libovolném pro­ gramu podporujícím alespoň jeden z nich. Řešením by mohlo být rozšíření RFC1847, které by umožnilo přidat více podpisů k jedné zprávě.

28

Dodatek A

Patch pro Mutt 1.5.10i Následuje výpis rozdílů mezi orginální a upravenou verzí programu. Řádky končící znakem \ jsou ve skutečnosti delší a celý následující řádek je jejich pokračováním. Na přiloženém CD je opravný patch bez těchto tiskových úprav. diff

-bur m u t t - 1 . 5 . 1 0 - o r i g / c o n t r i b / g p g . r e mutt-1.5.10/contrib/gpg.re m u t t - 1 . 5 . 1 0 - o r i g / c o n t r i b / g p g . r e 2 0 0 5 - 1 1 - 2 7 2 3 : 3 6 : 2 6 . 0 0 0 0 0 0 0 0 0 +0100 +++ m u t t - 1 . 5 . 1 0 / c o n t r i b / g p g . r e 2 0 0 5 - 1 1 - 2 7 2 3 : 4 9 : 2 0 . 0 0 0 0 0 0 0 0 0 +0100 @@ - 8 3 , 3 + 8 3 , 8 @@ # This v e r s i o n uses — s t a t u s - f d messages s e t p g p _ g o o d _ s i g n = " A \ \ [ G N U P G : \ \ ] GOODSIG" +# E n c r y p t / s i g n a l o n e a t t a c h e m e n t i n p g p / i n l i n e f o r m a t m e s s a g e +set pgp_attach_encrypt_only_command="pgpewrap / u s r / b i n / g p g —batch\ —quiet —no-verbose —output - —encrypt —textmode — a l w a y s - t r u s t \ +set pgp_attach_encrypt_sign_command="pgpewrap / u s r / b i n / g p g \ % ? p ? — p a s s p h r a s e - f d 0? — b a t c h — q u i e t — n o - v e r b o s e —textmode\ — o u t p u t - — e n c r y p t — s i g n %?a?-u %a? — a l w a y s - t r u s t — - r %r — %f" +set pgp_attach_sign_command="/usr/bin/gpg —no-verbose —batch\ — q u i e t — o u t p u t - % ? p ? — p a s s p h r a s e - f d 0? — s i g n — t e x t m o d e %?a?-u\ ^a ; ^r

- b u r mu t t - 1 . 5 . 1 0 - o r i g / g l o b a l s . h m u t t - 1 . 5 . 1 0 / g l o b a l s . h 2 0 0 5 - 1 1 - 2 7 2 3 : 3 6 : 2 6 . 0 0 0 0 0 0 0 0 0 +0100 mutt-1.5 .10-orig/globals.h 2 0 0 5 - 1 1 - 2 7 2 3 : 3 7 : 0 3 . 0 0 0 0 0 0 0 0 0 +0100 +++ m u t t - 1 . 5 . 1 0 / g l o b a l s . h @@ - 2 0 6 , 6 +2 0 6 , 9 @@ WHERE c h a r *PgpVerifyCommand; WHERE c h a r *PgpDecryptCommand,• WHERE c h a r *PgpSignCommand; +WHERE c h a r *PgpAttachSignCommand; +WHERE c h a r *PgpAttachEncryptSignCommand; +WHERE c h a r *PgpAttachEncryptOnlyCommand; WHERE c h a r *PgpEncryptSignCommand; WHERE c h a r *PgpEncryptOnlyCommand; WHERE c h a r *PgplmportCommand,• d i f f - b u r mu tt-1.5.10-orig/init.h mutt-1.5.10/init.h m u t t - 1 . 5 .10-orig/init.h 2005-11-27 23:36:26.000000000 +0100 diff

29

A. PATCH PRO M U T T 1 . 5 . 1 0 I

+++ mutt-1.5.10/init.h 2005-11-27 23:36:58.000000000 +0100 @@ -1667,6 +1667,18 @@ ** (PGP only) */ { "pgp_encrypt_only_command", DT_STR, R_NONE, UL\ &PgpEncryptOnlyCommand, 0}, + + /* + * * .pp + ** This commands are used to detached secure attachements in + ** PGP/inline message. Note that the use of this format is\ \fBstrongly\fP + ** \fBdeprecated\fP. + ** (PGP only) + */ + í "pgp_attach_sign_command", DT_STR, R_NONE, UL\ &PgpAttachSignCommand, 0}, + í "pgp_attach_encrypt_sign_command", DT_STR, R_NONE, UL\ &PgpAttachEncryptSignCommand, 0}, + í "pgp_attach_encrypt_only_command", DT_STR, R_NONE, UL\ &PgpAttachEncryptOnlyCommand, 0}, + /* ** .pp ** This command is used to encrypt a body part without\ signing it. diff -bur mutt-1.5.10-orig/mutt_crypt.h mutt-1.5.10/mutt_crypt.h mutt-1.5.10-orig/mutt_crypt.h 2005-11-27 23:36:26.000 +0100 +++ mutt-1.5.10/mutt_crypt.h 2005-11-27 23:37:19.000 +0100 @@ -44,6 +44,7 @@ #define APPLICATION_SMIME (1 << 9) #define PGP_TRADITIONAL_CHECKED +#define PGP_TRADITIONAL_ATTACH

(1 << 10) (1 << 11)

#define PGPENCRYPT (APPLICATION_PGP | ENCRYPT) #define PGPSIGN (APPLICATION_PGP | SIGN) diff -bur mutt-1.5.10-orig/pgp.c mutt-1.5.10/pgp.c mutt-1.5.10-orig/pgp.c 2005-11-27 23:36:26.000 +0100 +++ mutt-1.5.10/pgp.c 2005-11-27 23:37:26.000 +0100 @@ -1338,10 +1338,63 @@ return (t); } +/* Use hacked version of pgp/inline with attachements? */ +int pgp_traditional_attach_menu (void){ + switch(mutt_multi_choice (_("Secure every attachement\ (a)lone or use PGP/(M)IME? (h)elp\n"), _("amh"))){

30

A. PATCH PRO M U T T 1 . 5 . 1 0 I + + + + + +

case 1: return 1; case 2: return 2; case 3: fputs(_("Standard PGP/inline can be only clear\ text message.\n\rFor message with attachemets it is better\ to choose PGP/(M)IME format, but it is not supported by\ every mail client.\n\r"),stdout); + fputs(_("For example by MS Outlook, MS Outlook\ Express on Windows and PINE on Linux.\n\r\n\r"),stdout); + fputs(_("There is a risk of breaking integrity between\ message body and attachements if you choose 'Secure every\ attachement (a)lone'.\n\r"),stdout); + fputs(_("Use this choice only for sending messages to\ mail clients without PGP/MIME.\n\r\n\r"),stdout); + return pgp_traditional_attach_menu (); + } +} + BODY *pgp_traditional_encryptsign (BODY *a, int flags, char *keylist) { + BODY *b, *p, *g; + + /* encryptsign text/plain */ + if(a->type == TYPETEXT && ! ascii_strcasecmp (a->subtype, "plain")) + return pgp_traditional_encryptsign_part(a,flags,keylist); + + /* check if it is possible to use hacked version with encryptsignX every attachement alone */ + else if (a->type == TYPEMULTIPART){ + for(p = a->parts;p;p=p->next){ + if (p->disposition == DISPINLINE){ + if(p->type != TYPETEXT || ascii_strcasecmp (p->subtype,\ "plain")) + return NULL; + } + } + + /* hacked inline can work. Do you want it? */ + if( pgp_traditional_attach_menu () == 2) + return NULL; + + + +

}

/* hacked multipart vesrion */ if((b = pgp_traditional_encryptsign_part(a->parts,flags,keylist))\ == NULL) + return NULL;

31

A. PATCH PRO M U T T 1 . 5 . 1 0 I + + + +

b = mutt_make_multipart (b); for(p = a->parts->next;p;p=p->next){ g = b->parts->next; b->parts->next = pgp_traditional_encryptsign_part (p,flags\ | PGP_TRADITIONAL_ATTACH,keylist); + if (b->parts->next == NULL) return NULL; + b->parts->next->next = g; + } + return (b); +} + +BODY *pgp_traditional_encryptsign_part (BODY *a, int flags, char *keylist) +{ BODY *b; + +

char *pgpatname;

char pgpoutfile[_POSIX_PATH_MAX]; char pgperrfile[_POSIX_PATH_MAX]; char pgpinfile[_POSIX_PATH_MAX]; @@ -1360,18 +1413,21 @@ pid_t thepid; -

if

(a->type != TYPETEXT) return NULL; if (ascii_strcasecmp (a->subtype, "plain")) + if ( (a->type != TYPETEXT || ascii_strcasecmp (a->subtype,\ "plain")) + && (! (flags & PGP_TRADITIONAL_ATTACH) || a->disposition\ != DISPATTACH)) return NULL; + +/* convert charset only for text part */ +if (a->type == TYPETEXT && a->disposition == DISPINLINE ){ + flags &= ~PGP_TRADITIONAL_ATTACH; + mutt_mktemp (pgpinfile); if ((fp = fopen (a->filename, "r")) == NULL) { mutt_perror (a->filename); return NULL; } -

mutt_mktemp (pgpinfile); if ((pgpin = safe_fopen (pgpinfile, "w")) == NULL) { mutt_perror (pgpinfile);

32

A. PATCH PRO M U T T 1 . 5 . 1 0 I

@@ -1414,6 +1470,7 @@ } safe_fclose (&fp); fclose (pgpin); +} mutt_mktemp (pgpoutfile); mutt_mktemp (pgperrfile); @@ -1434,7 +1491,8 @@ if ((thepid = pgp_invoke_traditional (&pgpin, NULL, NULL, -1, fileno (pgpout),\ fileno (pgperr), pgpinfile, keylist,\ flags)) == -1) + (a->type == TYPETEXT\ && a->disposition == DISPINLINE) ? pgpinfile : a->filename, + keylist, flags)) == -1) { mutt_perror _("Can't invoke PGP"); fclose (pgpout); @@ -1488,14 +1546,29 @@ b = mutt_new_body (); +

if(a->type == TYPETEXT && a->disposition == DISPINLINE){ b->encoding = ENC7BIT; b->type = TYPETEXT; b->subtype = safe_strdup ("plain");

mutt_set_parameter ("x-action", flags & ENCRYPT ?\ "pgp-encrypted" : "pgp-signed", &b->parameter); mutt_set_parameter ("charset", send_charset, &b->parameter); + b->disposition = DISPINLINE; + b->use_disp = 1; + if (!(flags & ENCRYPT)) + b->encoding = a->encoding; + + } + else{ + b->type = TYPEAPPLICATION; + b->subtype = safe_strdup ("octet-stream"); + b->encoding = ENCBASE64; + b->disposition = DISPATTACH; + b->use_disp = 1; + pgpatname = a->d_filename ? a->d_filename : a->filename;

33

A. PATCH PRO M U T T 1 . 5 . 1 0 I

+ + +

strcat(pgpatname,".pgp"); b->d_filename = safe_strdup (pgpatname); } b->filename = safe_strdup (pgpoutfile);

@@ -1509,14 +1582,10 @@ #endif -

b->disposition = DISPINLINE; b->unlink = 1; b->noconv = 1; b->use_disp = 0;

-

if (!(flags & ENCRYPT)) b->encoding = a->encoding;

return b; } diff -bur mutt-1.5.10-orig/pgp.h mutt-1.5.10/pgp.h mutt-1.5.10-orig/pgp.h 2005-11-27 23:36:26.000 +0100 +++ mutt-1.5.10/pgp.h 2005-11-27 23:37:29.000 +0100 @@ -97,6 +97,7 @@ /* private ? */ int pgp_verify_one (BODY *, STATE *, const char * ) ; BODY *pgp_traditional_encryptsign (BODY *, int, char * ) ; +BODY *pgp_traditional_encryptsign_part (BODY *, int, char * ) ; BODY *pgp_encrypt_message (BODY *, char *, int); BODY *pgp_sign_message (BODY * ) ; diff -bur mutt-1.5.10-orig/pgpinvoke.c mutt-1.5.10/pgpinvoke.c mutt-1.5.10-orig/pgpinvoke.c 2005-11-27 23:36:26.000 +0100 +++ mutt-1.5.10/pgpinvoke.c 2005-11-27 23:37:35.000 +0100 @@ -247,6 +247,11 @@ int pgpinfd, int pgpoutfd, int pgperrfd, const char *fname, const char *uids, int flags) { + if ( (flags & PGP_TRADITIONAL_ATTACH) && (flags & ENCRYPT) ) + return pgp_invoke (pgpin, pgpout, pgperr, pgpinfd, pgpoutfd,\ pgperrfd, + flags & SIGN ? 1 : 0, fname, NULL, PgpSignAs, uids, + flags & SIGN ? PgpAttachEncryptSignCommand :\ PgpAttachEncryptOnlyCommand); + if (flags & ENCRYPT) return pgp_invoke (pgpin, pgpout, pgperr, pgpinfd, pgpoutfd,\

34

A. PATCH PRO M U T T 1 . 5 . 1 0 I

pgperrfd, flags & SIGN ? 1 : 0, fname, NULL, PgpSignAs, uids, @@ -254,7 +259,7 @@ else return pgp_invoke (pgpin, pgpout, pgperr, pgpinfd, pgpoutfd,\ pgperrfd, 1, fname, NULL, PgpSignAs, NULL, PgpClearSignCommand); + flags & PGP_TRADITIONAL_ATTACH ?\ PgpAttachSignCommand : PgpClearSignCommand); }

35

Literatura [1] Pinkava Jaroslav: ELEKTRONICKÝ PODPIS - využití v bankovnictví, http: / / cryptoworld.inío/pinkava/'prezentace/bankyl.ppt [2] Tilman, L.: Using PGP/GnuPG and http://stud3.tuwien.ac.at/~e0025974/uni/crypto.pdf. [3] The Free Software Foundation: http://www.gnupg.org/gph/en/manual.pdf, [4] Internet mail consortium: S/MIME pgpmime.html (říjen 2005).

S/MIME

The GNU 1999.

and OpenPGP,

with

Privacy

Email,

Handbook,

http://www.imc.org/smime-

[5] Kerckhoffs, A.: La cryptographie militaire, Journal des sciences militaires, vol. IX, le­ den - únor 1883. 2.1 [6] Mutt developers: USING http://www.mutt.org/doc/PGP-Notes.txt

PGP FROM WITHIN (prosinec 2005), 6.11.2001. 4.2.3

[7] Pavlík Roman [TNS a.s.]: OpenPGP v ČR, Slidy http://www.gpg.cz/~rp/GnuPG/EurOpen/openpgp20020405.pdf 5. března 2002. [8] Network Associates: An Introduction ftp://ftp.pgpi.Org/pub/pgp/7.0/docs/english/IntroToCrypto.pdf 1990-2000. 2.1 [9] Pinkava Jaroslav world.info /pinkava/

dostupné na URL (říjen 2005),

to

Cryptography, (listopad 2005),

[AEC s.r.o.]: Úvod do kryptologie, úvod/ uvod9S.pdf, květen 1998.

[10] Hasselbacher, K.: Replacing http://www.gnupg.org/gph/en/pgp2x.html,

PGP 1999.

2.x

MUTT,

http://crypto-

with

GnuPG,

[11] J. Galvin [Trusted Information Systems CyberCash, Inc. Innosoft International, Inc.], S. Murphy [Trusted Information Systems CyberCash, Inc. Innosoft International, Inc.], S. Crocker [CyberCash, Inc. Innosoft International, Inc.], N. Freed [Innosoft Inter­ national, Inc.]: RFC1847Security Multiparts for MIME: Multipart/Signed and Multi­ part/Encrypted, ftp://ftp.isi.edu/in-notes/rfcl847.txt (prosinec2005), říjen 1995. 3.2, 3.2.2,3.2.3,4.1.1,4.3 [12] D. Atkins [MIT Comp-Comm Consulting Boulder Software Engineering], W. Stallings [Comp-Comm Consulting Boulder Software Engineering], P. Zimmer­ mann [Boulder Software Engineering]: RFC1991 PGP Message Exchange Formats, ftp://ftp.isi.edu/in-notes/rfcl991.txt, srpen 1996. 36

[13] J. Callas [Network Associates IN-Root-CA Individual Network e.V. Network Associa­ tes EIS Corporation], L. Donnerhacke [IN-Root-CA Individual Network e.V. Network Associates EIS Corporation], H. Finney [Network Associates EIS Corporation], R. Thayer [EIS Corporation]: RFC2440 OpenPGP Message Format, ftp://ftp.isi.edu/innotes/'rfc2440.txt (prosinec 2005), listopad 1998. 3.1.2,4.1.2 [14] M. Elkins [Network Associates, Inc. CryptoRights Foundation University of Califor­ nia at Berkeley ], D. Del Torto [CryptoRights Foundation University of California at Berkeley ], R. Levien [University of California at Berkeley ], T. Roessler []: RFC3156 MIME Security with OpenPGP, ftp://ftp.isi.edu/in-notes/rfc3156.txt (prosinec 2005), Srpen 2001. 3.2.2,4.1.1,4.2.11 [15] R. Housley [RSA Laboratories]: RFC3852 Cryptographic Message Syntax (CMS) Al­ gorithms, ftp://ftp.isi.edu/in-notes/rfc3370.txt (prosinec 2005), srpen 2002. [16] B. Ramsdell, Editor [Sendmail, Inc.]: RFC3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling, ftp://ftp.isi.edu/innotesZrfc3850.txt (listopad 2005), červenec 2004. 3.1.3 [17] B. Ramsdell, Editor [Sendmail, Inc.]: RFC3851 Secure /Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specificationi, ftp://ftp.isi.edu/innotesZrfc3851.txt, červenec 2004. 3.1.3,3.2.3 [18] R. Housley [Vigil Security]: RFC3852 Cryptographic Message Syntax ftp://ftp.isi.edu/in-notes/rfc3852.txt (prosinec 2005), Červenec 2004. 3.1.3 [19] RIPE NCC: E-mail Client Testing for http://www.ripe.net/db/support/security/mail_client_tests.html, [20] Secure email-clients with PGP/MIME, http://www.bretschneidernet.de/tips/secmua.html.

S/MIME Dostupné

(CMS),

Compliance, leden 2004. na

[21] The Free Encyclopedia Wikipedia: Dostupná na URL http://en.wikipedia.org nec 2005). 2.2

URL (prosi­

[22] PSP ČR: Zákon 227/2000 Sb., o elektronickém podpisu a o změně některých dal­ ších zákonů (zákon o elektronickém podpisu), ve znění pozdějších předpisů (poslední 440/2004 Sb.), 29. června 2000 - 24. června 2004. 3

37