}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Srovnání vybraných kryptografických technologií a prototypová implementace BAKALÁŘSKÁ PRÁCE Petr Černý Brno, jaro 2010

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. Petr Černý Vedoucí práce: doc. RNDr. Václav Matyáš, M.Sc., Ph.D. ii

3 Poděkování Děkuji doc. RNDr. Václavu Matyášovi, M.Sc., Ph.D. za poskytování konzultací a odborné vedení při zpracování této bakalářské práce. Děkuji ing. Pavlovi Černému za poskytnutí konzultací a prostředí pro vývoj prototypové implementace. iii

4 Shrnutí Cílem této práce je poskytnout přehled dostupných technologií, které lze použít pro šifrování a digitální podpis u ve formátu S/MIME. Praktické využití bude předvedeno implementací vybraného řešení v IS Kaskáda [40]. iv

5 Klíčová slova CAPICOM, CMS, digitální podpis, kryptografická knihovna, OpenSSL, PKCS#7, S/MIME, StreamSec II v

6 Obsah 1 Úvod Dostupné zdroje informací, průmyslové standardy Standardy pro šifrování a digitální podpisy ů PKCS#7 a CMS - Syntaxe kryptografických zpráv.. 6 Možné typy obsahu v obálce ContentInfo Důležité RFC dokumenty S/MIME - Secure/Multipurpose Internet Mail Extensions Služby poskytnuté digitálním podpisem dat Služby poskytnuté šifrováním dat Nevýhody použití S/MIME Vytvoření S/MIME zásilky Přijetí S/MIME zásilky Typy S/MIME zpráv Rozpoznání typu S/MIME zásilky Důležité RFC dokumenty Standardy pro certifikáty a klíče PKCS#12 - Syntaxe pro výměnu osobních informací Srovnání vybraných technických řešení Popis systému pro prototypovou implementaci Kritéria výběru technologie pro implementaci Kompatibilita s IS Kaskáda Technologická kompatibilita Licenční kompatibilita Implementace funkcí Seznam požadovaných funkcí Dokumentovanost API Složitost API Stabilita Podpora produktu Open StreamSec II Kompatibilita s IS Kaskáda Technická kompatibilita Licenční kompatibilita Úroveň implementace funkcí Dokumentovanost API Složitost API

7 3.3.5 Dostupnost SDK Stabilita Podpora autorů OpenSSL Kompatibilita s IS Kaskáda Technická kompatibilita Licenční kompatibilita Úroveň implementace funkcí Dokumentovanost API Složitost API Dostupnost SDK Stabilita Podpora autorů Capicom a CryptoAPI Kompatibilita s IS Kaskáda Technická kompatibilita Licenční kompatibilita Úroveň implementace funkcí Dokumentovanost API Složitost API Dostupnost SDK Stabilita Podpora autorů Vyhodnocení průzkumu Shrnutí výhod a nevýhod jednotlivých řešení Open StreamSec II Výhody Nevýhody OpenSSL Výhody Nevýhody Capicom Výhody Nevýhody Zvolení konkrétní implementace Implementace vybraného řešení v IS Kaskáda Shrnutí kroků implementace Komplikace související se zvolenou implementací Závěr A Zdrojové kódy pro práci se zásilkami

8 A.1 Vytvoření podpisu typu attached signature A.2 Vytvoření podpisu typu detached signature A.3 Zašifrování zásilky A.4 Zpracování příchozí zprávy s ohledem na MIME hlavičky. 35 A.5 Pomocné funkce B Zdrojové kódy pro práci s certifikáty B.1 Přidání přijatého certifikátu do systémového úložiště B.2 Vytvoření osobního certifikátu

9 1 Úvod Digitální podpis je s vyjímkou drobných odlišností elektronickou alternativou podpisu vytvořeného lidskou rukou a perem. Bez podpisu bychom se dnes těžko obešli, nebot jím na sebe bereme závazky a prokazujeme naši identitu při podepisování smluv či papírových dopisů. Náš vlastnoruční podpis lze ověřit a prohlásit, s jak velkou pravděpodobností byl skutečně vytvořen naší rukou. Obdobnou funkci má také podpis elektronický, který se přes svojí odlišnou povahu a způsob vzniku svojí důvěryhodností vyrovná podpisu vedenému naší rukou. Elektronický podpis je založen na použití asymetrické kryptografie a v této práci předpokládám znalost alespoň základních pojmů z této oblasti. Pokud nejste seznámeni s principy asymetrické kryptografie, doporučuji se s nimi před dalším čtením seznámit. Z hlediska aplikované kryptografie je digitální podpis obvykle založen na vytvoření otisku posílané zprávy a aplikování asymetrické šifrovací funkce na tento otisk s použitím privátního klíče odesílatele. Elektronický podpis - stejně jako podpis vlastnoruční - neskrývá obsah odeslané zprávy, nezaručí důvěrnost přenášených dat a zprávu si tak může kdokoliv přečíst. Díky podpisu však můžeme ověřit, kdo zprávu vytvořil. K zaručení důvěrnosti slouží šifrování s využitím asymetrické kryptografie. Zásilka je zpracována zvoleným algoritmem za použití veřejného klíče příjemce a obsah zásilky se tímto stává nečitelným pro všechny osoby, které nevlastní příjemcův soukromý klíč. V kapitole 2 se zabývám dostupnými standardy, které se týkají práce s podepsanými či šifrovanými daty, standardizačními organizacemi a podrobnějším rozborem jednotlivých standardů včetně ukázek ových zpráv ve formátu S/MIME. Kapitola 3 popisuje tři dostupná technická řešení, která budu v této práci srovnávat. Jedná se o řešení použitelná v prostředí Delphi IDE, jmenovitě OpenStreamSec Toolkit, OpenSSL a Capicom(CryptoAPI). Popis výsledků, ke kterým jsem dospěl srovnáním jednotlivých řešení, je shrnut v kapitole 4 spolu s udáním důvodů pro konečný výběr konkrétního technického řešení. V závěru práce se zabývám shrnutím přínosu prototypové implementace a možnostmi dalšího rozvoje prototypového systému s ohledem na použití zvoleného technického řešení. V přílohách lze najít ukázky zdrojových kódů, které byly použity pro implementaci požadované funkčnosti. Pro jejich použití budete kromě vý- 4

10 1. ÚVOD vojového prostředí Delphi potřebovat také komponenty z balíku Synapse [14]. 5

11 2 Dostupné zdroje informací, průmyslové standardy Pro schopnost dvou různých aplikací vzájemně komunikovat je klíčové použití společného jazyka, kterému budou rozumět jejich autoři se proto musí držet při implementaci aplikace dohodnutých a uznávaných standardů. V této kapitole bych proto chtěl uvést základní standardy zaručující schopnost používat elektronicky podepsané či šifrované y a pracovat s klíči pro asymetrickou kryptografii. 2.1 Standardy pro šifrování a digitální podpisy ů V této kapitole se budu zabývat třemi standardy zaměřenými na zpracování digitálních dat kryptografickými operacemi. Prvním a nejstarším standardem je Public Key Cryptography Standard #7 (dále PKCS#7, viz 2.1.1). Druhým standardem je Cryptographic Message Syntax (dále CMS, viz kapitola 2.1.1) odvozený ze standardu PKCS#7. Posledním standardem, který zde popíši, je Secure/Multipurpose Internet Mail Extensions (dále pouze S/MIME, viz 2.1.2). Zatímco standardy PKCS#7 a CMS definují obecný postup obalení kryptograficky zpracovaných dat pro přenosy po Internetu, standard S/MIME se specializuje na kryptografické zpracování ů za použití standardu CMS PKCS#7 a CMS - Syntaxe kryptografických zpráv Standard PKCS#7 byl vyvinut roku 1993 v RSA Laboratories (výzkumná divize společnosti RSA) a jeho verze 1.5 byla používána jako průmyslový standard, přestože nebyl udržován žádnou standardizační organizací. Plánovaná verze 1.6, která měla být uveřejněna v roce 1997, nebyla dokončena, nebot na základě standardu PKCS#7 vytvořila organizace Internet Engineering Task Force (dále IETF) standard Cryptographic Message Syntax (dále CMS). První verze standardu CMS byla uveřejněna v březnu roku 1998 v dokumentu RFC2315 [28]. Standard CMS zachovává se standardem PKCS#7 zpětnou kompatibilitu a je novější, proto se dále v této práci budu zabývat pouze standardem CMS. Standard CMS definuje syntax pro vytvoření obálky kolem kryptograficky zpracovaných dat. Obálka obsahuje vždy informaci o druhu aplikované kryptografické operace, kryptograficky zpracovaná data a případné dodatečné metainformace (použitý algoritmus, seznam použitých certifi- 6

12 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY kátů a další). Obalení dat je možné provádět rekurzivně, na jedna vstupní data lze tedy postupně aplikovat libovolný počet kryptografických operací. Této vlastnosti lze využít například k podpisu digitálních dat více uživateli. Mimo jiné nachází tento standard praktické využití také při komunikaci s Certificate Revocation List [29] (dále CRL) za účelem odvolání platnosti certifikátů. Základním prvkem, který CMS popisuje pomocí Abstract Syntax Notation 1 [38] (dále ASN.1), je ContentInfo. ContentInfo je obálka obsahující dva prvky - jednoznačně určený typ obsahu a obsah. Typ obsahu je popsán pomocí Object ID (dále jen OID, unikátní řetězec čísel). Aktuální seznam OID [1] udržuje Internet Mail Consorcium. Možné typy obsahu v obálce ContentInfo CMS definuje v RFC3852 [24] šest základních typů pro rozlišení obsahu, přičemž další typy jsou definovány odděleně v jiných RFC dokumentech (například níže uvedený typ compressed-data je definován v RFC3274 [17]). Standard S/MIME (viz 2.1.2) využívá první čtyři níže uvedené typy. Data - obsahem tohoto typu jsou libovolné 8bitové řetězce dat, například text v kódování ASCII. S/MIME používá id-data k označení obsahu ve formátu MIME (Multipurpose Internet Mail Extensions). Signed-data - obsahem jsou libovolná data s žádným až libovolným počtem podpisů. Z podepisovaných dat se vytvoří otisk (digest) pomocí algoritmu specifického pro každého podepisujícího a tento otisk se podepíše soukromým klíčem podepisujícího. Přidáním informací o podepisujícím do pole SignerInfo pro každého podepisujícího vzniká objekt SignersInfo, který spolu s podepsanými daty tvoří objekt SignedData, který je obsahem výsledné obálky ContentInfo. Příjemce po přijetí zprávy vytvoří nezávislý otisk za pomoci ověřeného veřejného klíče podepisujícího a pokud vypočítaný otisk odpovídá přijatému, je podpis prohlášen za platný. Enveloped-data - obsahem jsou libovolná zašifrovaná data a libovolný počet zašifrovaných šifrovacích klíčů pro jednoho či více příjemců. Kombinace jednoho zašifrovaného obsahu a jednoho zašifrovaného šifrovacího klíče pro jednoho příjemce je digitální obálka pro tohoto příjemce. 7

13 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY Compressed-data - obsahem jsou libovolná data, na která je aplikován kompresní algoritmus. Všichni klienti s podporou CMS typu Compresseddata musí umět pracovat s kompresí zlib [7]. Komprese dat redukuje redundanci, která by mohla pomoci útočníkovi při pokusu o prolomení bezpečnosti hrubou silou a umožňuje rychlejší zpracování zásilek díky změnšení objemu dat. Digested-data - obsahem jsou libovolná data a otisk těchto dat vypočítaný vybraným algoritmem. Obvykle je objekt typu digested-data použit pro kontrolu integrity a používá se jako vstup při zpracování objektu enveloped-data. Encrypted-data - obsahem jsou libovolná zašifrovaná data. Na rozdíl od typu enveloped-data však nejsou přiloženy informace o příjemcích, ani zašifrované šifrovací klíče. Šifrovací klíče musí být spravovány jiným způsobem, nebo odvozené z poskytnuté informace. Typickým případem užití tohoto typu je zašifrování dat a jejich lokální uložení, přičemž šifrovací klíč bývá odvozen z hesla pro přístup k datům. Authenticated-data - obsahem jsou libovolná data, jejich Message Authentication Code (dále MAC) a zašifrované autentizační klíče pro jednoho nebo více příjemců. Kombinace MAC a jednoho zašifrovaného autentizačního klíče pro jednoho příjemce je nezbytná pro ověření integrity původního obsahu jedním příjemcem. Důležité RFC dokumenty RFC2315 [28] - PKCS #7: Cryptographic Message Syntax Version 1.5 je standard definující první verzi standardu CMS, která téměř kopíruje standard PKCS #7. RFC2630 [21] - Cryptographic Message Syntax (Proposed standard) je aktualizace standardu CMS zachovávající zpětnou kompatibilitu s verzí 1.5. Tato aktualizace není označena jako samostatná verze, nebot pouze rozšiřuje možnosti pro přenos certifikátu. Konkrétně umožňuje uložení doručeného certifikátu na straně klienta a nepřikládání certifikátu k zásilce pro následující komunikaci. 8

14 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY RFC3274 [17] - Compressed Data Content Type for Cryptographic Message Syntax (CMS) definuje podrobnosti týkající se S/MIME typu Compresseddata, zejména způsob vytvoření obálky a použitelné či povinně podporované algoritmy. RFC3369 [23] - Cryptographic Message Syntax (Proposed standard) je další aktualizace CMS standardu verze 1.5 rozšiřující standard o práci s klíči a upravující možnosti přenosu certifikátů. Nejvýznamnější změnou provedenou v tomto standardu je však oddělení specifikace šifrovacích a hešovacích algoritmů do samostatného dokumentu (RFC3852, viz níže). RFC3852 [24] - Cryptographic Message Syntax (Proposed standard) je aktualizace standardu CMS specifikující šifrovací a hešovací algoritmy, rozšiřující množinu formátů použitelných pro přenos certifikátů a přidávající způsob práce s ověřením platnosti certifikátu pomocí revocation lists. RFC5652 [25] - Cryptographic Message Syntax (Draft standard) upřesňuje drobné nejasnosti v RFC3852 bez přidání nových prvků do standardu CMS S/MIME - Secure/Multipurpose Internet Mail Extensions Standard S/MIME je udržován standardizační organizací Internet Engineering Task Force a jeho aktuální verze je 3.1. S/MIME popisuje aplikaci CMS (viz 2.1.1) na zásilky ve formátu MIME, tedy definuje způsob práce s digitálně podepsanými, šifrovanými či komprimovanými y. Služby poskytnuté digitálním podpisem dat Autentizace umožňuje příjemci jednoznačně určit identitu autora či autorů zprávy. Kontrola integrity poskytuje jistotu, že obsah zprávy nebyl při přenosu změněn. Nepopiratelnost původu zajišt uje, že zpráva byla podepsána osobou, jejíž soukromý klíč byl použit k podpisu. V nepopiratelnosti původu se projevuje rozdíl mezi vlastnoručním a digitálním podpisem - pokud někdo získá soukromý klíč podepisujícího a vytvoří s jeho pomocí digitální podpis, je 9

15 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY tento podpis naprosto identický s podpisem, který by vytvořil původní majitel soukromého klíče. Z tohoto pohledu je použití digitálního podpisu nevýhodou, avšak ve srovnání s vlastnoručním podpisem má také velikou výhodu. Při vytvoření vlastnoručního podpisu nejsou obvykle žádné dva podpisy zcela stejné, proto při ověření pravosti podpisu lze pouze posoudit, s jakou pravděpodobností byl podpis opravdu vytvořen podepsanou osobou. U digitálního podpisu je ověření vždy jisté - pro podpis dat daný soukromý klíč použit byl, nebo nebyl. Služby poskytnuté šifrováním dat Pomocí šifrování přenášených dat lze dosáhnout především soukromí - obsah zprávy mohou číst pouze uživatelé, kteří mají potřebné soukromé klíče. Nevýhody použití S/MIME Web-mailoví klienti nemohou implementovat podporu standardu S/MIME na straně serveru, nebot k podepsání či zašifrování zprávy potřebují přístup k soukromému klíči podepisující entity. Soukromý klíč by však měl být po celou dobu existence pod výhradní kontrolou svého vlastníka a umístění klíče na cizí server proto nelze akceptovat jako řešení. Výpočty k aplikaci kryptografických operací tedy musí být prováděny na straně klienta (webového prohlížeče, implementace je obvykle formou zásuvných modulů). Zásuvné moduly jsou bohužel v současné době dostupné pouze pro některé webové prohlížeče založené na jádře Gecko [12] (například Mozilla Firefox). Někteří oví klienti neumí data ve formátu S/MIME zpracovat, což může vést k nečitelnosti u či zobrazení přílohy se jménem smime.p7s kterou neumí běžní uživatelé otevřít. Šifrování u zajišt uje end-to-end security, tedy zašifrovaný obsah je k příjemci doručen v nezměněné podobě. Tato vlastnost je nevhodná, pokud je se zamýšleným obsahem zašifrován a odeslán také škodlivý kód (malware). Obsah zašifrovaného u je nečitelný pro antivirové programy na branách do firemních sítí, u poskytovatele internetového připojení či na webmailových serverech. Malware se může touto cestou dostat až na koncovou stanici příjemce. Možnou obranou je spolehlivý personální antivirus a firewall na stanici, kde dojde k otevření zásilky, uložení klíče na serveru s antivirem nebo použití techniky key-escrow. Zašifrování u brání indexování obsahu a fulltextovému hledání, není-li v systému uložena dešifrovaná kopie, což nemusí být bezpečné. 10

16 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY Vytvoření S/MIME zásilky Každá zásilka ve formátu MIME se skládá z několika částí (obvykle nazývaných part či MIME entita) oddělených oddělovačem (boundary), který je v rámci zásilky unikátní. Jednotlivé části lze do sebe vnořovat a vytvářet tak stromovou strukturu (vzniká n-ární kořenový strom). K podpisu či šifrování se používají klíče uložené ve fomátu PKCS#12 [30] (viz 2.2.1). Kryptografické operace lze aplikovat na libovolnou MIME entitu (případně na zásilku jako celek, triviálně aplikací na kořenovou entitu bez hlaviček definovaných v RFC822 [5]) a v libovolném počtu iterací. Před kryptografickým zpracováním vstupních dat je potřeba tato data uvést do kanonického tvaru (viz RFC2049 [13]). Proces vytvoření S/MIME entity se skládá ze dvou základních kroků - aplikace kryptografické operace na původní MIME entitu a vytvoření nových MIME hlaviček. Tímto způsobem dojde k obalení původního obsahu, přičemž obalení lze provést několika postupy. O konkrétním postupu informuje nově vzniklý S/MIME part pomocí adekvátní hodnoty MIME atributu Content-type (viz 2.1.2). Takovéto obalení lze provádět opakovaně, přičemž kryptografické operace či podepisující autority se mohou libovolně střídat. Vícenásobného obalení se také využívá k vytvoření trojobalu (triple wrapping, definováno v RFC2634 [20], sekce 1.1). Technika triple wrapping spočívá v digitálním podepsání, zašifrování a opětovném podepsání původního obsahu. První (vnitřní) podpis zajišt uje integritu, nepopiratelnost původu a autentizaci. Připojením některých atributů hlavičky k obsahu podepsanému prvním podpisem jsou tyto atributy chráněny stejně jako původní obsah. Následné zašifrování zaručí důvěrnost podepsaného obsahu, včetně podepsaných atributů hlavičky. Druhý (vnější) podpis poskytuje autentizaci a ověření integrity informací, které jsou zpracovány při přeposílání zásilky. Takto zpracovaná MIME entita (včetně hlaviček) přijde od odesílatele k příjemci nezměněna bez ohledu na počet agentů, kteří zpracovávají zásilku během doručení (například mailinglistoví agenti). Algoritmus pro šifrování obsahu, který musí umět odesílatel i příjemce, je DES EDE3 CBC (dále 3DES [22]), příjemce by měl podporovat také RC2 [37] se 40bitovým klíčem (dále RC2/40), algoritmus lze však použít pouze na informace, které nemusí být silně šifrované. Příjemce i odesílající by měli podporovat algoritmus AES [32] s použitím klíče o velikosti 128,192 a 256 bitů. Kvůli dodržení zpětné kompatibility s klienty, kteří nepodporují standard S/MIME, by měl odesílající klient uvádět jméno souboru v hlavičkách 11

17 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY MIME entity Content-disposition a Content-type. Přípona souboru by měla odpovídat danému typu S/MIME zprávy (viz 2.1.2). Přijetí S/MIME zásilky Po přijetí zprávy a ověření platnosti veřejného certifikátu by měl příjemce zaznamenat čas přijetí zprávy a preferovaný algoritmus symetrické kryptografie pro další komunikaci. Při každém dalším přijetí zprávy by měl příjemce ověřit, že čas podepsání zprávy je vyšší než poslední zaznamenaný čas přijetí zprávy. Při vytváření odpovědi na přijatou zásilku by měl přijímající klient zohlednit seznam preferovaných algoritmů. Pokud odesílatel zprávy nespecifikoval preferované algoritmy, při odpovědi se použije stejný algoritmus, jaký byl použit u příchozí zprávy. Klient musí být schopen ověřovat pravost X.509 certifikátů podle PKIX [2] a nesmí používat PKCS #6 [31] certifikáty. Typy S/MIME zpráv Atribut Content-type hlavičky nově vytvořené MIME zásilky může nabývat hodnot application/pkcs7-mime nebo multipart/signature. První uvedený MIME typ se používá k přenosu CMS typů EnvelopedData, Signed- Data a CompressedData, druhý typ se používá k připojení podpisu odděleně od podepisovaného obsahu (tzv. detached signature). Odesílající agent by měl navíc do atributu Content-type přidat parametr smime-type, aby sdělil přijímajícímu agentovi kryptografické operace, které byly aplikovány na vnořený obsah a ulehčil tak práci s dekódováním ASN.1 struktury zásilky. Odesílající agent by měl také použít parametr name a uvést jméno souboru (například smime ) včetně přípony kvůli kompatibilitě s přijímajícími klienty, kteří nepodporují zpracování S/MIME zásilek. Možné kombinace přípon uvádí následující tabulka: MIME typ CMS typ Přípona application/pkcs7-mime SignedData, EnvelopedData p7m application/pkcs7-mime SignedData p7c application/pkcs7-mime CompressedData p7z application/pkcs7-signature SignedData p7s 12

18 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY Parametr smime-type: Účelem parametru je poskytnout informace o aplikovaných kryptografických operacích příjemci. Seznam možných kombinací: parametr smime-type CMS typ Vnitřní obsah enveloped-data EnvelopedData id-data signed-data SignedData id-data certs-only SignedData none compressed-data CompressedData id-data S/MIME typ enveloped-data: Tento typ zprávy slouží k posílání textu v šifrované podobě, ale absence podpisu nezaručuje integritu dat. Postup vytvoření MIME entity: 1. MIME entita je převedena do kanonického tvaru. 2. MIME entita a další potřebná data jsou převedeny do CMS objektu typu EnvelopedData. 3. CMS objekt EnvelopedData je zabalen do CMS objektu ContentInfo. 4. CMS objekt ContentInfo je vložen do MIME partu typu application/pkcs7-mime. 5. Do atributu Content-type jsou přidány parametry smime-type=enveloped-data a name =smime.p7m Příklad hlavičky entity typu enveloped-data: Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m S/MIME typ signed-data: Zpráva může obsahovat v atributu Contenttype dva různé MIME typy, konkrétně application/pkcs7-mime nebo multipart/signed. Odesílatel by měl preferovat multipart/signed (tzv. detached signature, obsah je čitelný i pro klienty bez podpory S/MIME). Přijímající agent musí umět zpracovat obě možnosti. MIME typ application/pkcs7-mime používá S/MIME typ signed-data. Přípony souboru mohou být p7m (podepsaná zpráva) nebo p7c (obsah zprávy je prázdný, účelem zásilky je předání přiloženého certifikátu). 13

19 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY Postup podepsání MIME entity je následující: 1. MIME entita je převedena do kanonického tvaru. 2. MIME entita a další potřebná data jsou převedeny do CMS objektu typu SignedData. 3. CMS objekt SignedData je zabalen do CMS objektu ContentInfo. 4. CMS objekt ContentInfo je vložen do MIME entity s atributem Content-type: application/pkcs7-mime. 5. Do atributu Content-type jsou přidány dva nové parametry smime-type=signed-data a name =smime.p7m Ukázková hlavička entity s podepsanými daty: Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m Postup vytvoření zprávy pro odeslání certifikátu je následující: 1. Je vytvořen CMS objekt typu SignedData s prázdným polem signerinfos a bez pole encapcontentinfo. 2. CMS objekt SignedData je zabalen do CMS objektu ContentInfo. 3. CMS objekt ContentInfo je vložen do MIME entity s atributem Content-type: application/pkcs7-mime. 4. Atribut Content-type obsahuje navíc smime-type=certs-only a name =smime.p7c Hlavička S/MIME partu je shodná s předchozím případem až na příponu souboru v atributu Content-type. MIME typ multipart/signed se používá pro označení entity, která má dva potomky (dvě dceřinné MIME entity). Tento typ je doporučen pro použití odesílatelem, nebot obsah je čitelný i pro klienty, kteří neumí zpracovat zásilky typu S/MIME. V průběhu doručení zásilky však může dojít například ke změně zalomení řádků a tím k porušení podpisu. První MIME entita obsahuje nezašifrovaná data v kanonickém tvaru [13] a její MIME typ odpovídá typu podepsaných dat. Druhá MIME entita 14

20 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY obsahuje digitální podpis (tzv. detached signature CMS typu SignedData) a používá MIME typ application/pkcs7-signature. S/MIME typ je signeddata a přípona souboru je p7s. Vnořený objekt SignedData nesmí obsahovat pole encapcontentinfo. V hlavičce je také uveden algoritmus použitý pro vytvoření otisku (parametr micalg v atributu Content-type). Postup vytvoření MIME entity typu multipart/signed: 1. MIME entita je převedena do kanonického tvaru. 2. MIME entita a další potřebná data jsou převedeny do CMS objektu typu SignedData, musí však chybět pole encapcontentinfo. 3. Kanonizovaná původní MIME entita je vložena jako první dceřinná entita do nově vzniklé entity typu multipart/signed. 4. CMS objekt SignedData bez pole encapcontentinfo je zpracován v souladu s použitým přepravním kódováním. Použité přepravní kódování lze zjistit z atributu Content-transfer-encoding druhé MIME entity. 5. MIME part typu application/pkcs7-signature je vložen jako druhá dceřinná entita do rodičovské entity typu multipart/signed. 6. Atribut Content-type je obohacen o parametry protocol= application/pkcs7-mime a micalg={množina alespoň jedné z hodnot v následující tabulce, oddělených čárkami}. Parametr micalg slouží k určení algoritmu pro výpočet otisku zprávy při validaci podpisu. Algoritmus MD5 SHA-1 SHA-256 SHA-384 SHA-512 nedefinován Hodnota parametru micalg md5 sha1 sha256 sha384 sha512 unknown Ukázková S/MIME entita typu multipart/signed: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary1 15

21 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY --boundary1 Content-Type: text/plain This is a clear-signed message. --boundary1 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition:attachment; filename=smime.p7s ghyhhhuujhjhjh77n8hhgtrfvbnj756tbb9hg4vqpfyf467ghi 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HG n8hhgtrfvhjhjh776tbb9hg4vqbnj7567ghigfhfyt6ghyhhhu --boundary1-- S/MIME typ compressed-data: Standard S/MIME verze 3.1 definuje nový typ compressed-data, který klienti konformní pouze se staršími verzemi standardu nebudou schopni zpracovat. Postup vytvoření S/MIME entity typu compressed-data: 1. MIME entita je převedena do kanonického tvaru. 2. MIME entita a další potřebná data jsou převedeny do CMS objektu typu CompressedData. 3. CMS objekt CompressedData je zabalen do CMS objektu ContentInfo. 4. CMS objekt ContentInfo je vložen do MIME entity typu application/pkcs7-mime. 5. V atributu Content-type je nutno použít dva další upřesňující parametry smime-type=compressed-data a name=smime.p7z Příklad hlavičky S/MIME entity: Content-Type: application/pkcs7-mime; smime-type=compressed-data; name=smime.p7z Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7z 16

22 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY Vícenásobné kryptografické operace: několikanásobné obalení je umožněno identickým typem vstupních i výstupních dat pro každou ze tří výše uvedených metod obalení. Výsledek jedné operace lze tedy poskytnout jako vstup operaci následující a počet takovýchto iterací není omezen. Pořadí aplikace podpisu a šifrování na zpracovaná data není bezvýznamné. Zašifrování podepsané zprávy bezpečně skryje podpis, který proto není možno změnit. Naopak při podepsání zašifrované zprávy je podpis vystaven možné změně, ale lze jej ověřit bez dešifrování. Příjemce zprávy, která byla zašifrována a poté podepsána, si může ověřit, že zašifrovaný obsah nebyl změněn. Nemůže však určit jakýkoliv vztah mezi podepisujícím a nezašifrovaným obsahem. Příjemce zprávy, která byla podepsána a poté zašifrována, může předpokládat, že podepsaný obsah nebyl změněn, ale schopný útočník mohl změnit neautentizované části šifrované zprávy. Řešení dilematu, zda dříve šifrovat nebo podepisovat, nabízí výše uvedená technika triple wrapping. Kompresi dat nemá smysl aplikovat na binární či kryptograficky zpracovaná data, lze ji však s úspěchem použít na data kódovaná v base64 či na digitální data před kryptografickým zpracováním. Rozpoznání typu S/MIME zásilky je v souladu se standardem S/MIME, pokud platí kterákoliv z následujících možností (přípony souboru pochází z parametru name atributu Content-type nebo z parametru filename atributu Content-disposition): MIME typ application/pkcs7-mime multipart/signed application/octet-stream Parametry jakékoliv protocol= application/ pkcs7-signature jakékoliv, přípona souboru p7m, p7s, p7c Důležité RFC dokumenty RFC2311 [8] - S/MIME Version 2 Message Specification je základní specifikace standardu S/MIME, nad kterým tímto dokumentem přebrala kontrolu organizace IETF (dokument je založen na standardu PKCS #7). Popisuje způsob vytvoření a zpracování přijaté S/MIME zásilky, definuje nové potřebné MIME typy a je kompatibilní se standardem PKCS #7. RFC2312 [9] - S/MIME Version 2 Certificate Handling se stejně jako předchozí standard zabývá shrnutím standardu PKCS #7. Zaměřuje se na 17

23 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY ověření klíčů, zaslaných jako součást S/MIME zprávy, na základě správy certifikátů v systémovém úložišti. RFC2632 [33] - S/MIME Version 3 Certificate Handling je aktualizací verze 2 a zaměřuje se na práci s certifikáty, kterou musí všichni S/MIME klienti podporovat a rozšiřuje základní požadavky definované v RFC2459 [26] o použití Certificate Revocation Lists a o zákaz používání PKCS #6 certifikátů. RFC2633 [34] - S/MIME Version 3 Message Specification je aktualizací standardu verze 2, která upřesňuje některé nejasnosti ve specifikaci standardu a přidává atributy pro drobná rozšíření funkčnosti. RFC2634 [20] - Enhanced Security Services for S/MIME je dobrovolné rozšíření standardu S/MIME umožňující odeslání podepsaného potvrzení o příjmu zásilky, přenos atributu identifikujícího míru citlivosti dat (security label), provozování zabezpečených mailing-listů a podepisování certifikátů zasílaných jako součást zprávy. RFC3850 [35] - S/MIME Version 3.1 Certificate Handling je aktualizací RFC2632 [33], které rozšiřuje o povinnost podporovat CRLv1 a CRLv2, aktualizuje množinu použitelných šifrovacích a hešovacích algoritmů a upřesňuje některé nejasnosti z dřívější verze standardu. RFC3851 [36] - S/MIME Version 3.1 Message Specification upřesňuje povinnost použití algoritmů pro vytvoření podpisu a šifrování dat, upřesňuje nejasnosti předchozích verzí standardu a zavádí možnost použití CMS typu Compressed-data. 2.2 Standardy pro certifikáty a klíče PKCS#12 - Syntaxe pro výměnu osobních informací Standard PKCS#12 vznikl a je udržován v RSA Laboratories a je zařazen do skupiny standardů Public-Key Cryptography Standards (PKCS). Definuje formát souborů pro ukládání soukromých klíčů s odpovídajícími certifikáty veřejných klíčů, chráněných symetrickým šifrováním založeným na hesle. Předchůdcem standardu PKCS#12 je standard PFX od firmy Microsoft. 18

24 2. DOSTUPNÉ ZDROJE INFORMACÍ, PRŮMYSLOVÉ STANDARDY PKCS#12 je kontejnerový formát, jeden soubor s typickou příponou p12 může obsahovat více vložených objektů, například více certifikátů. Uvádět více informací o standardu PKCS#12 není dle mého názoru pro tuto práci relevantní, nebot standard se netýká přímo zadaného tématu. Všechna zvažovaná technická řešení umí se soubory v tomto formátu pracovat a pro práci lze tedy využít volání API jednotlivých technických řešení. Více informací o PKCS#12 lze nalézt prostudováním následujících zdrojů: PKCS #12: Personal Information Exchange Syntax Standard [30]. OpenSSL PKCS#12 FAQ [19]. 19

25 3 Srovnání vybraných technických řešení 3.1 Popis systému pro prototypovou implementaci Prototypová implementace některé z níže diskutovaných technologií bude provedena v informačním systému Kaskáda [40]. Kaskáda je systém pro správu firemní agendy, Custommer Resource Management a Enterprise Resource Planning. Umožňuje mimo jiné vedení účetnictví, správu komunikací, skladů, objednávek, zakázek, majetku, řízení projektů a může sloužit jako dokumentový sklad. Systém začal vznikat v roce 2000 na základě předchozích deseti let zkušeností s vývojem firemních IS pro prostředí Microsoft DOS. Cílová skupina zákazníků jsou malé a střední firmy, které nechtějí či nemohou implementovat komplexní systémy jako je SAP. 3.2 Kritéria výběru technologie pro implementaci Kritéria jsou řazena podle důležitosti od nejdůležitějších. Následuje krátký popis významu každého kritéria, podle kterého se bude řídit výběr technologie pro implementaci Kompatibilita s IS Kaskáda Vybraná technologie musí být s IS Kaskáda kompatibilní z pohledu technologického i licenčního. Technologická kompatibilita Kaskáda používá SQL server od firmy Software602 (602SQL Server, dříve komerční produkt), který byl v roce 2009 uvolněn jako freeware pro volné použití a verze 10 byla uvolněna pod názvem OpenSQL Server včetně zdrojových kódů. Kaskáda [40] je vyvíjena v prostředí Borland Delphi 6 (nyní Embarcadero Delphi [10], dále jen Delphi). Delphi IDE (Integrated Development Environment) je založeno na objektově orientované verzi jazyka Pascal (Object Pascal). Cílovým operačním systémem, pro který je systém Kaskáda vyvíjen, je systém Windows verze NT a vyšší. Oficiální podpora je pouze pro Windows XP, ale program lze bez problémů provozovat i ve Windows Vista 20

26 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ či Windows 7. Výše uvedené předpoklady omezují množinu technologií vhodných pro implementaci na následující: komponenty VCL či CLX pro Delphi IDE, knihovny tříd (units) dostupné jako zdrojové kódy v jazyce Pascal, dynamicky linkované knihovny, aplikace spustitelné z příkazové řádky, ActiveX [4] prvky. Licenční kompatibilita Použité technické řešení bude součástí komerčního produktu s uzavřeným kódem, což vylučuje použití kódu licencovaného pod GNU/GPL [15], licencemi odvozenými od GNU/GPL (GNU/LGPL, GNU/AGPL apod.) či podobně restriktivními copyleft [11] licencemi Implementace funkcí Seznam požadovaných funkcí Vytvoření a ověření digitálního podpisu. Zašifrování a dešifrování obsahu. Kombinace předchozích dvou možností. Kritériem pro přijetí technického řešení naopak není schopnost parsovat zásilky ve formátu MIME. IS Kaskáda [40] k tomuto účelu využívá balík VCL komponent Synapse [14] od Lukáše Gebauera Dokumentovanost API Formát dokumentace není rozhodující, musí však umožňovat fulltextové vyhledávání. Rejstřík a seznam kapitol jsou výhodou. Dokumentace by měla odpovídat aktuálně dostupné verzi a být dostatečně podrobná a jednoznačná, aby umožnila rychlou orientaci v celém systému Složitost API API by mělo poskytovat přiměřené množství adektvátně zapouzdřených funkcí. 21

27 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ Stabilita Zvolené technické řešení musí být v použité verzi stabilní, nebot aktualizace technického řešení v IS Kaskáda [40] budou prováděny pouze v nezbytně nutných případech Podpora produktu Podmínkou zvolení technického řešení je aktivní podpora produktu formou mailing-listu, diskuzních fór a podobně. 22

28 3.3 Open StreamSec II 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ Autorem kolekce komponent StreamSec Tools je Henrick Hellström. StreamSec Tools je kolekce komponent a tříd pro Delphi IDE zaměřených na kryptografii a bezpečnost. Produkt implementuje podporu pro SSL/TLS, S/MIME a práci s X.509 certifikáty. Verze 2.1 je dostupná zdarma, novější verze 3 je komerční produkt s cenou okolo 500 e [18] za jednoho vývojáře. Verzi 2.1 lze stáhnout na adrese Kompatibilita s IS Kaskáda Technická kompatibilita Open StreamSec II je kolekce VCL komponent a tříd vyvinutých přímo pro Delphi IDE a je plně kompatibilní s Delphi6. Licenční kompatibilita Volně dostupná verze 2.1 je dostupná pod licencí ve stylu BSD [39], která dovoluje šíření ve formě zdrojových kódů i přeložených binárních dat a to včetně případných uživatelských úprav či jako součást komerčního software. Požaduje s distribucí zdrojového či binárního kódu také distribuovat text původní licence a jméno StreamSec ani jména autorů nesmí být spojována s produktem vzniklým úpravou původního produktu bez předchozího souhlasu autorů Úroveň implementace funkcí Verze 2.1 poskytuje veškerou požadovanou funkčnost a to včetně vlastního řešení správy X.509 certifikátů Dokumentovanost API Dokumentace se nainstaluje jako součást Delphi IDE a lze ji najít v menu Nápověda. Dokumentace bohužel není příliš podrobná a popisy některých tříd a metod chybí úplně. V některých případech je jeden funkční aspekt implementován ve více třídách, avšak nikde nejsou popsány rozdíly v jednotlivých implementacích. 23

29 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ Složitost API Množina tříd a funkcí je velká a neintuitivně pojmenovaná. Práce s API není jednoduchá a uživatel je nucen pracovat postupem pokus-omyl Dostupnost SDK SDK je na velmi dobré úrovni, poskytuje sadu demo aplikací i balíky komponent které lze nainstalovat do Delphi IDE běžnými nástroji, které IDE nabízí. Ukázkové aplikace jsou bohužel zaměřeny především na práci s X.509 certifikáty a pro zpracování S/MIME zásilek neposkytly potřebné ukázkové zdrojové kódy Stabilita Implementace založená na poslední uvolněné verzi je stabilní Podpora autorů Další vývoj produktu byl zastaven, respektive byla založena nová komerční vývojová větev StreamSec 3. Vývojová větev 2.1 má stále aktivní podporu komunity vývojářů Delphi, zejména díky implementaci starší verze 2.1 do mnoha aplikací. 24

30 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ 3.4 OpenSSL OpenSSL je komunitní projekt, aktuální seznam vývojářů je dostupný na Autory knihovny SSLEay, na které je OpenSSL založeno, jsou Eric A. Young a Tim J. Hudson. OpenSSL je sada nástrojů zaměřených na implementaci protokolu SSL (Secure Socket Layer) verze 2 i 3, protokolu TLS (Transport Layer Security) a obecně na vývoj nástroje poskytujícího podporu pro nejrůznější kryptografické operace. Mezi základní principy dodržované při vývoji OpenSSL patří otevřenost zdrojových kódů při zachování možnosti využít nástroj v komerčních aplikacích. Pro účely implementace do IS Kaskáda podporuje OpenSSL zejména kontrolu zpráv standardu S/MIME v2 a práci s certifikáty. OpenSSL také umožňuje vygenerovat osobní certifikát podle standardu PKCS #12. K tomuto účelu však musí být OpenSSL alespoň verze 0.9.5a a musí být kompilované spolu s knihovnou pkcs12), který jsem používal při testování všech tří technických řešení. OpenSSL je software s otevřeným zdrojovým kódem, který lze stáhnout z ftp://ftp.openssl.org/source/. Binární spustitelné soubory přeložené pro linuxové operační systémy jsou obvykle součástí distribuce, binární soubory pro Windows lze stáhnout z Kompatibilita s IS Kaskáda Technická kompatibilita Pro platformu Windows je OpenSSL dodáváno jako spustitelný soubor s rozhraním CLI (Command Line Interface), v Delphi IDE lze z projektu použít především knihovnu libeay32.dll. DLL knihovny jsou dostupné jako součást projektu GNU Win32 [16], rozhraní pro Delphi vyvinul tým z Department of Computer and Information Science z Ženevské univerzity. Jednotlivé soubory s rozhraním [6] obsahují prototypy funkcí, neobsahují však kompletní množinu funkcí dostupných v knihovně libeay32.dll. Licenční kompatibilita OpenSSL je licencováno pod dvěmi licencemi typu BSD [39]. Jedna pochází od autorů OpenSSL a druhá od autorů knihovny SSLEay, na které je 25

31 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ OpenSSL postaveno. Aktuální licence je v plném znění přístupná na http: // Úroveň implementace funkcí OpenSSL poskytuje podporu pro ověřování podpisu a dešifrování S/MIME zpráv verze 2 [8] a pro práci s certifikáty na úrovni jejich vytváření a ověřování. OpenSSL bohužel neposkytuje mechanismus úložiště certifikátů Dokumentovanost API API je kvalitně dokumentováno online na stránkách projektu, navíc je k dispozici mnoho tutoriálů a dokumentů publikovaných členy komunity Složitost API API je relativně jednoduché, funkce pro práci s S/MIME zásilkami jsou však ve fázi vývoje a nejsou stabilní Dostupnost SDK SDK není dostupné Stabilita OpenSSL je stále se vyvíjející projekt, který se postupně mění. Samotné knihovny poskytují relativně stabilní řešení, rozhraní mezi knihovnou libeay32.dll a Delphi IDE je však stále nekompletní a postupně vyvíjené Podpora autorů Projekt se aktivně vyvíjí a komunita jeho uživatelů a vývojářů poskytuje velmi dobrou podporu. 26

32 3.5 Capicom a CryptoAPI 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ Autorem ActiveX prvku CAPICOM je společnost Microsoft Corporation. Zkratka CAPICOM pochází od Cryptographic Application Programming Interface for Communication Object Model. Knihovna zjednodušuje volání systémových funkcí, které ve Windows nabízí CryptoAPI (rozhraní pro volání služeb CSP - Cryptographic Service Provider) a poskytuje podporu pro práci se systémovým úložištěm certifikátů Windows Kompatibilita s IS Kaskáda Technická kompatibilita CAPICOM je poskytován jako SDK obsahující dynamicky linkovanou knihovnu capicom.dll. Delphi IDE umí pro tuto knihovnu automaticky vytvořit rozhraní pro komunikaci. Pro účely volání CryptoAPI z Delphi IDE je dostupné rozhraní poskytované projektem JEDI API Library [27]. Licenční kompatibilita CAPICOM je distribuován pod licencí Microsoftu, která dovoluje CAPI- COM volně distribuovat a zahrnovat do vlastních produktů za podmínky splnění několika požadavků, které IS Kaskáda splňuje a případná implementace umožňuje. CryptoAPI je běžnou součástí systémů Windows. Projekt JEDI API Library lze použít i v komerčních aplikacích Úroveň implementace funkcí CryptoAPI (tedy i CAPICOM) poskytuje veškerou požadovanou funkčnost včetně přístupu k systémovému úložišti certifikátů Dokumentovanost API CAPICOM i CryptoAPI mají online dokumentaci dostupnou na webu Microsoft Development Network [3] Složitost API Funkce a třídy mají velmi intuitivní názvy, názvy parametrů jsou naopak často mnohoznačné, avšak též dostatečně dokumentované. 27

33 3. SROVNÁNÍ VYBRANÝCH TECHNICKÝCH ŘEŠENÍ Dostupnost SDK CAPICOM SDK lze zdarma stáhnout z downloads/ (konkrétní adresa se bohužel často mění, proto doporučuji použít vyhledávání). SDK obsahuje samotnou knihovnu capicom.dll a několik ukázkových aplikací, které však bohužel nejsou psány v jazyce Object Pascal. Pro použití CryptoAPI i CAPICOMu v Delphi lze najít na Internetu relativně velké množství ukázkového kódu Stabilita Použití CryptoAPI i CAPICOMu zajišt uje stabilitu odpovídající implementaci v dané verzi operačního systému, celkově jsem však při testování nenarazil na problémy se stabilitou Podpora autorů Microsoft uvádí ve své online dokumentaci řadu příkladů, z nichž některé jsou součástí CAPICOM SDK. CryptoAPI je široce používaným nástrojem, k jehož užití lze najít mnoho ukázkových zdrojových kódů od Microsoftu i od autorů třetích stran. Vývoj knihovny CAPICOM je zastaven, oficiální podpora ze strany Microsoftu je udržována do Windows verze Vista. Do budoucna doporučuje Microsoft využít přímého volání funkcí CryptoAPI. 28

34 4 Vyhodnocení průzkumu 4.1 Shrnutí výhod a nevýhod jednotlivých řešení Open StreamSec II Výhody Jedná se o nativní řešení založené od základu na prostředí Delphi IDE a jazyce Object Pascal. Poskytuje vlastní řešení správy certifikátů a jejich úložiště. Nevýhody Nedostatky v dokumentaci považuji za natolik závažné, že vylučují praktickou použitelnost a spolehlivost celého řešení. Ukázkové aplikace se bohužel zaměřují zejména na práci s X.509 certifikáty a jejich úložiště, bez dokumentace jsem tedy nebyl schopen implementovat v plném rozsahu práci s S/MIME zásilkami OpenSSL Výhody Dokumentace je podrobná, dobře strukturovaná, snadno dostupná, podpora komunity je aktivní. OpenSSL je stabilní a ověřené řešení použité v mnoha aplikacích. Nevýhody OpenSSL bohužel neimplementuje úložiště certifikátů, nekontroluje odvolání certifikátu u Certificate Revocation List a neumí automaticky určit typ použitého hešovacího algoritmu na základě atributu SMIMECapabilities hlavičky Content-Type. Verze 1.0 umí pracovat pouze s S/MIME v2, složitější struktury definované v S/MIME v3 způsobují chyby při parsování. MIME parser použitý v OpenSSL není stabilní a kolabuje na některých neobvyklých zprávách. 29

35 4. VYHODNOCENÍ PRŮZKUMU Capicom Výhody CAPICOM a CryptoAPI jsou často používaným nástrojem, díky čemuž mají silnou podporu ze strany vývojářů i uživatelů. Navíc umožňují pracovat se systémovým úložištěm certifikátů, které jsou obvykle zvyklí spravovat i uživatelé s nepříliš velkými znalostmi v oblasti kryptografie (zejména v případě, že používají Internet Explorer nebo Outlook). Nevýhody CAPICOM nemá oficiální podporu Microsoftu ve Windows 7, volání funkcí CAPICOMu však lze v případě potřeby nahradit za přímá volání CryptoAPI. CAPICOM má rozhraní tak jednoduché, že v něm některé funkce chybí. Například v případě, že podpis neprojde ověřením, jelikož není považován za důvěryhodný, nejsou naplněny proměnné potřebné pro případnou instalaci certifikátu do systémového úložiště. Takováto místa je potřeba v praktické implementaci doplnit přímým voláním CryptoAPI. 4.2 Zvolení konkrétní implementace Pro implementaci práce s S/MIME zásilkami v IS Kaskáda jsem zvolil jako konečné řešení CAPICOM a CryptoAPI. Důvodem byla především dostupnost veškerých požadovaných funkcí včetně vlastního řešení úložiště certifikátů a spolehlivost. S pomocí CAPICOMu lze implementovat tvorbu a ověřování podepsaných zásilek i práci se zásilkami šifrovanými, na druhou stranu z mého předběžného průzkumu nevyplývaly žádné zásadní nedostatky, které by ohrožovaly funkčnost či udržitelnost řešení postaveného na knihovně CAPICOM. Ukázky práce s knihovnou CAPICOM a CryptoAPI jsou uvedeny jako přílohy na konci této práce. 4.3 Implementace vybraného řešení v IS Kaskáda Shrnutí kroků implementace Implementace probíhala ve dvou základních krocích: 1. implementace práce s podpisy typu attached signature (vytváření a kontrola podpisů) pro ověření technické kompatibility s IS Kaskáda; 30

36 4. VYHODNOCENÍ PRŮZKUMU 2. implementace práce s podpisy typu detached signature a práce s šifrovanými zásilkami Komplikace související se zvolenou implementací Žádná z komplikací, na které jsem narazil při implementaci, se neprojevovala náhodně (což by naznačovalo možnou nestabilitu v budoucím praktickém provozu). Při implementaci jsem musel vyřešit následující problémy související s použitím CAPICOM: CAPICOM umí pracovat pouze s řetězci v kódování Unicode s pevnou dvoubajtovou šířkou znaku, což neodpovídá vnitřní reprezentaci řetězce v Delphi6. Navíc v případě, že řetězec má lichý počet znaků, je poslední znak oříznut (což zejména v případě, že z řetězce počítáme heš, není přijatelné). Řešení spočívá v použití typu WideString, který používá pevnou šířku znaků a změně na sudou délku řetězce. Zpráva podepsaná pomocí CAPICOM v režimu detached signature šla zpětně ověřit v IS Kaskáda i v poštovním klientovi Mozilla Thunderbird, nikoliv však v Microsoft Outlooku. Důvodem je, že Outlook před výpočtem kontrolního heše z podepisované MIME entity odstraní poslední zalomení řádku (znaky Carriage Return a Line Feed). Řešením bylo při podepisování v režimu detached signature vypočítat heš pro podpis z podepisované MIME entity a poté před finálním sestavováním MIME zásilky na konec podepisované entity přidat volný řádek. Schopnost ověřenit podpis klientem Mozilla Thunderbird zůstala touto úpravou zachována. V případě, že selže ověření podpisu, funkcemi CAPICOMu nelze zjistit certifikáty použité pro podepsání zprávy. Typickým scénářem je obdržení u od osoby, jejíž certifikát ještě nemáme nainstalován, a není tedy důvěryhodný, o certifikátu se však domníváme, že je pravý (osoba s níž komunikujeme nám sdělila otisk certifikátu a otisk odpovídá). Řešením je přímé volání funkcí CryptoAPI, které umožňují z podepsaných dat získat podpisové certifikáty bez ohledu na výsledek ověření podpisu. Certifikáty jsou následně zobrazeny uživateli a případně importovány do systémového úložiště. 31