Zabezpečení elektronické pošty

Transkript

1 MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY ^TIS m p Zabezpečení elektronické pošty BAKALÁŘSKÁ PRÁCE Michal Prokeš Brno, podzim 2005

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval 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

3 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 klienta Mutt, umožňující zasílání zabezpečených ů s přílohou ve formátu OpenPGP tak, aby byli čitelné v programu Pine. m

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

5 Obsah 1 Úvod 1 2 Kryptologie Základní kryptologické pojmy Symetrické metody Asymetrické metody Hashování Hybridní šifry 6 3 Zabezpečení elektronické pošty Bezpečnostní protokoly Správa klíčů OpenPGP S/MIME Začlenění bezpečnosti do u PGP/inline PGP/mime S/mime 15 4 Testování klientů elektronické pošty Příprava a testování Testovací sada pgp/mime Testovací sada pgp/inline Testovací sada s/mime Výsledky testování jednotlivých klientů MS Outlook Express MS Outlook 2000, 2002, Mutt devel Mutt stable The Bat! Exmh Mozilla Thunderbird Mozilla Suite Balsa Pine Becky! Syplpheed-Claws Sylpheed Klienti nepodporující žádné zabezpečení Závěry z testování klientů 23 5 Implementace Patch pro Mutt i 26 6 Závěr 28 v

6 A Patch pro Mutt i 29 Literatura 37 vi

7 Kapitola 1 Úvod Práce popisuje možnosti zabezpečení elektronických dat, definuje základní pojmy a poukazuje 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ů (telefon, dopis, osobní setkání) a způsobů zabezpečení (podpis, notářsky ověřený podpis, razí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ů (Open- PGP a S/MIME), sledován je také komfort práce se zabezpečenou poštou a čtení pošty zaslané 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í existující způsoby řešení bezpečnostních problémů a rozebírá základní odlišnosti uvedených protokolů. Specializuje se na rozdíly v bezpečnostní politice, zejména ve správě klíčů. Podrobně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é ové 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 formátů a kompatibilitu zpráv s ostatními klienty. Důraz byl kladen na y s přílohami. Výsledky těchto testů jsou popsány ve čtvrté kapitole, která popisuje schopnosti a problémy jednotlivých klientů pracovat se zabezpečenými zprávami. Pokud tyto funkce program 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

8 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í programu. 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šinou 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 situací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

9 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 metodami 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 čtenář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 kryptografie 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í, podepsá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

10 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 jejich 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ěpodobnost, ž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 technický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 postupné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 nepoužitelný. Kryptoanalýza hledá metody, které by umožnily útočníkovi čas potřebný k provedení ú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. Komunikují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

11 2.3. ASYMETRICKÉ METODY tajný klíč bez nutnosti předem sdílet tajemství 3. Protokol je založen na problému diskrétní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 tajemství 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íčů. Komunikující strany si jich předem dohodnou více a sníží tak množství prozrazených informací v případě prolomení šifry 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 metod. 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řijaté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 matematický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 matematické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í riziko 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 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

12 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 asymetrické 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

13 Kapitola 3 Zabezpečení elektronické pošty Ruční podpis na papírových dokumentech bereme jako samozřejmost. Před odesláním takový 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 dokumenty 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í elektronický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 elektronický 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í digitální podpis 2, 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 existenci 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é legislativě [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šifrovat (ověřovat podpis) veřejným. 7

14 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 protokoly 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 bitová symetrická, respektive 3072-bitová RSA šifra by pak měla být bezpečná déle než do roku 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 samotné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ů 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í autorita (CA), která ověřuje identitu majitele a vydává certifikáty 3 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 libovolnou 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ěstnavatele 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 nainstalované 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

15 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í patentovaný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 koncové 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 integritu 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 potom 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íčů OpenPGP Historie PGP do verze 2.6.3i První verzi PGP 1.0 napsal Philip. R. Zimmerman v roce 1991 pro sebe a své kamará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 tohoto 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ů znamenala 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 (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 pode- 9

16 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 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í nesouvisejících s původní funkcionalitou. PGP 6.5 (rok 1999) obsahuje PGPNet (implemetnace IP- SEC/IKE) pro Windows. PGP je již šířena bez zdrojového kódu. NAI využívá popularity PGP a pod názvem PGP e-pphance šíří svůj firewall. GnuPG 1.0 (DSA, Elgamal, hashovací funkce MD5, RIPEMD, SHA1 a symetrické algoritmy 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 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áštního podepisovacího a šifrovacího klíče. Ve verzi PGP opouští P. R. Zimmerman NAI a dává záruku, že PGP do této verze neobsahuje zadní vrátka 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 GPGR pro zabezpeč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í 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 vychází vývojová verze GnuPG 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

17 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 definová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ódovat 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í 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 jehož jménem je psaná. Pravdivost standardní hlavičky u 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 takový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í asymetrické 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 algoritmů 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 u se hash vytváří ze zprávy včetně MIME hlaviček. Teprve tento otisk je podepsá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

18 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 nemohla 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 kombinaci 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ární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

19 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 algoritmů 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 soukromé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živatelského jména a ové 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živatelé 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 zjednoduš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 (symetrická šifra), SHA-1 (hash) 13

20 3.2. ZAČLENĚNÍ BEZPEČNOSTI DO U 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 definová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 u Způsoby začlenění bezpečnosti do ové zprávy definuje RFC1847 [11] (Security Multiparts for MIME) z roku Tento dokument vytváří dva podtypy MIME typu Multipart. 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 algoritmus 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čí automatické 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 potřebné pro rozkódování zašifrované zprávy. Druhá část potom obsahuje proud zašifrovaný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 PGP/inline Vkládá radix-64 kódované OpenPGP pakety přímo do těla zprávy. Neobsahuje žádné speciá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 PGP/mime Definuje způsob začlenění PGP funkcionality do ové komunikace. Je využíváno příslušných podtypů Multipart definovaných v RFC1847 [11]. 14

21 3.2. ZAČLENĚNÍ BEZPEČNOSTI DO U Pro šifrovanou zprávu se využívá MIME rozšíření Multipart/Encrypted a zavádí protokol 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. ová 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ásleduje 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šifrovanou) OpenPGP zpráva a vložit ji do multipart/encrypted. Veřejný klíč je možno distribuovat jako MIME část u typu application/pgp-keys" v OpenPGP ASCII-armored podobě S/mime S/mime CMS (Cryptographic Message Syntax) zpráva může být do ové zprávy začleněna podle RFC3851 [17] a to zvolením typu zprávy application/x-pkcs7-mime a nastavení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ý a do druhé příslušný podpis ve formátu CMS zprávy. 15

22 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 testovacích ů. 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í y jsou otevřeny v jednotlivých klientech a posuzuje se schopnost a komfort jejich čtení. Následně jsou ze všech klientů odeslány y ve všech formátech a sepsán postup jak takový odeslat a zda je to vůbec možné Testovací sada pgp/mime Tato sada testuje schopnost klientů zobrazit y 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řijatý klíč (rfc3156/7) 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 text/plain. 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

23 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ášť Testovací sada s/mime s/mime šifrovaný s/mime podepsaný s/mime podepsaný a šifrovaný 4.2 Výsledky testování jednotlivých klientů MS Outlook Express Podpora s/mime je vestavěná. Zprávy jsou dešifrovány a pravost podpisu ověřována automaticky. 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í neexistuje 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 ( obsahují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 standardní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 bez zabezpečení. 17

24 4.2.2 MS Outlook 2000, 2002, VÝSLEDKY TESTOVÁNÍ JEDNOTLIVÝCH KLIENTŮ Všechny tři testované verze mají vestavěnou podporu s/mime a existuje pro ně GPGExch plugin ( 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 Mutt devel 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 ] 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 Mutt stable Oproti Mutt 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

25 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 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 u 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 u Part.txt s informací o tom, že je zabezpečen a zobrazí pouze ji, dokud uživatel nestiskne dešifrovací tlačítko. U podepsaných ů se po stisknutí zobrazí výstup zabezpečovacího programu. Po dešifrování v u 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í . Pokud aktivujeme současně OpenPGP i s/mime, je zpráva zabezpečena nejprve pomocí pgp a následně také pomocí s/mime Exmh Tcl/tk nadstavba unixového nmh klienta. Program plně podporuje pgp/mime a vůbec nepodporuje 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 nastavoval 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í u zobrazí tlačítko pro dešifrování/ověření. Pokud má více MIME částí, jsou zřetelně oddělené a číslované. Pokud je zabezpečena jen část u, 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