012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Srovnání vybraných kryptografických technologií a prototypová implementace ˇ B AKALÁ RSKÁ PRÁCE

ˇ Petr Cerný

Brno, jaro 2010

Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

ˇ Petr Cerný

Vedoucí práce: doc. RNDr. Václav Matyáš, M.Sc., Ph.D. ii

Podˇekování Dˇekuji doc. RNDr. Václavu Matyášovi, M.Sc., Ph.D. za poskytování konzultací a odborné vedení pˇri zpracování této bakaláˇrské práce. ˇ Dˇekuji ing. Pavlovi Cernému za poskytnutí konzultací a prostˇredí pro vývoj prototypové implementace.

iii

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

iv

Klíˇcová slova CAPICOM, CMS, digitální podpis, kryptografická knihovna, OpenSSL, PKCS#7, S/MIME, StreamSec II

v

Obsah 1 2

3

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dostupné zdroje informací, prumyslové ˚ standardy . . . . . . . . 2.1 Standardy pro šifrování a digitální podpisy e-mailu˚ . . . . . 2.1.1 PKCS#7 a CMS - Syntaxe kryptografických zpráv . . Možné typy obsahu v obálce ContentInfo . . . . . . Duležité ˚ RFC dokumenty . . . . . . . . . . . . . . . . 2.1.2 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ˇrení S/MIME zásilky . . . . . . . . . . . . . . . Pˇrijetí S/MIME zásilky . . . . . . . . . . . . . . . . . Typy S/MIME zpráv . . . . . . . . . . . . . . . . . . Rozpoznání typu S/MIME zásilky . . . . . . . . . . . Duležité ˚ RFC dokumenty . . . . . . . . . . . . . . . . 2.2 Standardy pro certifikáty a klíˇce . . . . . . . . . . . . . . . . . 2.2.1 PKCS#12 - Syntaxe pro výmˇenu osobních informací . Srovnání vybraných technických rˇešení . . . . . . . . . . . . . . 3.1 Popis systému pro prototypovou implementaci . . . . . . . . 3.2 Kritéria výbˇeru technologie pro implementaci . . . . . . . . 3.2.1 Kompatibilita s IS Kaskáda . . . . . . . . . . . . . . . Technologická kompatibilita . . . . . . . . . . . . . . Licenˇcní kompatibilita . . . . . . . . . . . . . . . . . . 3.2.2 Implementace funkcí . . . . . . . . . . . . . . . . . . . Seznam požadovaných funkcí . . . . . . . . . . . . . 3.2.3 Dokumentovanost API . . . . . . . . . . . . . . . . . . 3.2.4 Složitost API . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Stabilita . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 Podpora produktu . . . . . . . . . . . . . . . . . . . . 3.3 Open StreamSec II . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Kompatibilita s IS Kaskáda . . . . . . . . . . . . . . . Technická kompatibilita . . . . . . . . . . . . . . . . . Licenˇcní kompatibilita . . . . . . . . . . . . . . . . . . 3.3.2 Úrovenˇ implementace funkcí . . . . . . . . . . . . . . 3.3.3 Dokumentovanost API . . . . . . . . . . . . . . . . . . 3.3.4 Složitost API . . . . . . . . . . . . . . . . . . . . . . . .

4 6 6 6 7 8 9 9 10 10 11 12 12 17 17 19 19 20 20 20 20 20 21 21 21 21 21 22 22 23 23 23 23 23 23 24 1

3.3.5 Dostupnost SDK . . . . . . . . . . . . . . . . . . . 3.3.6 Stabilita . . . . . . . . . . . . . . . . . . . . . . . . 3.3.7 Podpora autoru˚ . . . . . . . . . . . . . . . . . . . . 3.4 OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Kompatibilita s IS Kaskáda . . . . . . . . . . . . . Technická kompatibilita . . . . . . . . . . . . . . . Licenˇcní kompatibilita . . . . . . . . . . . . . . . . 3.4.2 Úrovenˇ implementace funkcí . . . . . . . . . . . . 3.4.3 Dokumentovanost API . . . . . . . . . . . . . . . . 3.4.4 Složitost API . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Dostupnost SDK . . . . . . . . . . . . . . . . . . . 3.4.6 Stabilita . . . . . . . . . . . . . . . . . . . . . . . . 3.4.7 Podpora autoru˚ . . . . . . . . . . . . . . . . . . . . 3.5 Capicom a CryptoAPI . . . . . . . . . . . . . . . . . . . . 3.5.1 Kompatibilita s IS Kaskáda . . . . . . . . . . . . . Technická kompatibilita . . . . . . . . . . . . . . . Licenˇcní kompatibilita . . . . . . . . . . . . . . . . 3.5.2 Úrovenˇ implementace funkcí . . . . . . . . . . . . 3.5.3 Dokumentovanost API . . . . . . . . . . . . . . . . 3.5.4 Složitost API . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Dostupnost SDK . . . . . . . . . . . . . . . . . . . 3.5.6 Stabilita . . . . . . . . . . . . . . . . . . . . . . . . 3.5.7 Podpora autoru˚ . . . . . . . . . . . . . . . . . . . . 4 Vyhodnocení pruzkumu ˚ . . . . . . . . . . . . . . . . . . . . . . 4.1 Shrnutí výhod a nevýhod jednotlivých rˇ ešení . . . . . . . 4.1.1 Open StreamSec II . . . . . . . . . . . . . . . . . . Výhody . . . . . . . . . . . . . . . . . . . . . . . . Nevýhody . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . Výhody . . . . . . . . . . . . . . . . . . . . . . . . Nevýhody . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Capicom . . . . . . . . . . . . . . . . . . . . . . . . Výhody . . . . . . . . . . . . . . . . . . . . . . . . Nevýhody . . . . . . . . . . . . . . . . . . . . . . . 4.2 Zvolení konkrétní implementace . . . . . . . . . . . . . . 4.3 Implementace vybraného rˇ ešení v IS Kaskáda . . . . . . . 4.3.1 Shrnutí kroku˚ implementace . . . . . . . . . . . . 4.3.2 Komplikace související se zvolenou implementací 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Zdrojové kódy pro práci se zásilkami . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24 24 24 25 25 25 25 26 26 26 26 26 26 27 27 27 27 27 27 27 28 28 28 29 29 29 29 29 29 29 29 30 30 30 30 30 30 31 32 33 2

A.1 Vytvoˇrení podpisu typu attached signature . . . . . . . . . A.2 Vytvoˇrení podpisu typu detached signature . . . . . . . . . A.3 Zašifrování zásilky . . . . . . . . . . . . . . . . . . . . . . . A.4 Zpracování pˇríchozí zprávy s ohledem na MIME hlaviˇcky A.5 Pomocné funkce . . . . . . . . . . . . . . . . . . . . . . . . . B Zdrojové kódy pro práci s certifikáty . . . . . . . . . . . . . . . B.1 Pˇridání pˇrijatého certifikátu do systémového úložištˇe . . . B.2 Vytvoˇrení osobního certifikátu . . . . . . . . . . . . . . . .

. . . . . . . .

33 34 35 35 38 39 39 42

3

1 Úvod Digitální podpis je s vyjímkou drobných odlišností elektronickou alternativou podpisu vytvoˇreného lidskou rukou a perem. Bez podpisu bychom se dnes tˇežko obešli, nebot’ jím na sebe bereme závazky a prokazujeme naši identitu pˇri podepisování smluv cˇ i papírových dopisu. ˚ Náš vlastnoruˇcní podpis lze ovˇerˇ it a prohlásit, s jak velkou pravdˇepodobností byl skuteˇcnˇe vytvoˇren naší rukou. Obdobnou funkci má také podpis elektronický, který se pˇres svojí odlišnou povahu a zpusob ˚ vzniku svojí duvˇ ˚ eryhodností vyrovná podpisu vedenému naší rukou. Elektronický podpis je založen na použití asymetrické kryptografie a v této práci pˇredpokládám znalost alesponˇ základních pojmu˚ z této oblasti. Pokud nejste seznámeni s principy asymetrické kryptografie, doporuˇcuji se s nimi pˇred dalším cˇ tením seznámit. Z hlediska aplikované kryptografie je digitální podpis obvykle založen na vytvoˇrení otisku posílané zprávy a aplikování asymetrické šifrovací funkce na tento otisk s použitím privátního klíˇce odesílatele. Elektronický podpis - stejnˇe jako podpis vlastnoruˇcní - neskrývá obsah odeslané zprávy, nezaruˇcí duvˇ ˚ ernost pˇrenášených dat a zprávu si tak muže ˚ kdokoliv pˇreˇcíst. Díky podpisu však mužeme ˚ ovˇerˇ it, kdo zprávu vytvoˇril. K zaruˇcení duvˇ ˚ ernosti slouží šifrování s využitím asymetrické kryptografie. Zásilka je zpracována zvoleným algoritmem za použití veˇrejného klíˇce pˇríjemce a obsah zásilky se tímto stává neˇcitelným pro všechny osoby, které nevlastní pˇríjemcuv ˚ soukromý klíˇc. V kapitole 2 se zabývám dostupnými standardy, které se týkají práce s podepsanými cˇ i šifrovanými daty, standardizaˇcními organizacemi a podrobnˇejším rozborem jednotlivých standardu˚ vˇcetnˇe ukázek e-mailových zpráv ve formátu S/MIME. Kapitola 3 popisuje tˇri dostupná technická rˇ ešení, která budu v této práci srovnávat. Jedná se o rˇ ešení použitelná v prostˇredí Delphi IDE, jmenovitˇe OpenStreamSec Toolkit, OpenSSL a Capicom(CryptoAPI). Popis výsledku, ˚ ke kterým jsem dospˇel srovnáním jednotlivých rˇ ešení, je shrnut v kapitole 4 spolu s udáním duvod ˚ u˚ pro koneˇcný výbˇer konkrétního technického rˇ ešení. V závˇeru práce se zabývám shrnutím pˇrínosu prototypové implementace a možnostmi dalšího rozvoje prototypového systému s ohledem na použití zvoleného technického rˇ ešení. V pˇrílohách lze najít ukázky zdrojových kódu, ˚ které byly použity pro implementaci požadované funkˇcnosti. Pro jejich použití budete kromˇe vý4

1. Ú VOD vojového prostˇredí Delphi potˇrebovat také komponenty z balíku Synapse [14].

5

2 Dostupné zdroje informací, prumyslové ˚ standardy Pro schopnost dvou ruzných ˚ aplikací vzájemnˇe komunikovat je klíˇcové použití spoleˇcného “jazyka”, kterému budou rozumˇet – jejich autoˇri se proto musí držet pˇri implementaci aplikace dohodnutých a uznávaných standardu. ˚ V této kapitole bych proto chtˇel uvést základní standardy zaruˇcující schopnost používat elektronicky podepsané cˇ i šifrované e-maily a pracovat s klíˇci pro asymetrickou kryptografii.

2.1

Standardy pro šifrování a digitální podpisy e-mailu˚

V této kapitole se budu zabývat tˇremi standardy zamˇerˇ 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ˇrenosy po Internetu, standard S/MIME se specializuje na kryptografické zpracování e-mailu˚ za použití standardu CMS. 2.1.1 PKCS#7 a CMS - Syntaxe kryptografických zpráv Standard PKCS#7 byl vyvinut roku 1993 v RSA Laboratories (výzkumná divize spoleˇcnosti RSA) a jeho verze 1.5 byla používána jako prumyslový ˚ standard, pˇrestože nebyl udržován žádnou standardizaˇcní organizací. Plánovaná verze 1.6, která mˇela být uveˇrejnˇena v roce 1997, nebyla dokoncˇ ena, nebot’ na základˇe standardu PKCS#7 vytvoˇrila organizace Internet Engineering Task Force (dále IETF) standard Cryptographic Message Syntax (dále CMS). První verze standardu CMS byla uveˇrejnˇena v bˇreznu roku 1998 v dokumentu RFC2315 [28]. Standard CMS zachovává se standardem PKCS#7 zpˇetnou kompatibilitu a je novˇejší, proto se dále v této práci budu zabývat pouze standardem CMS. Standard CMS definuje syntax pro vytvoˇrení obálky kolem kryptograficky zpracovaných dat. Obálka obsahuje vždy informaci o druhu aplikované kryptografické operace, kryptograficky zpracovaná data a pˇrípadné dodateˇcné metainformace (použitý algoritmus, seznam použitých certifi6

˚ 2. D OSTUPNÉ ZDROJE INFORMACÍ , PR UMYSLOVÉ STANDARDY

kátu˚ a další). Obalení dat je možné provádˇet rekurzivnˇe, na jedna vstupní data lze tedy postupnˇe aplikovat libovolný poˇcet kryptografických operací. Této vlastnosti lze využít napˇríklad k podpisu digitálních dat více uživateli. Mimo jiné nachází tento standard praktické využití také pˇri komunikaci s Certificate Revocation List [29] (dále CRL) za úˇcelem odvolání platnosti certifikátu. ˚ 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ˇcnˇe urˇcený typ obsahu a obsah. Typ obsahu je popsán pomocí Object ID (dále jen OID, unikátní rˇ etˇezec cˇ í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 typu˚ pro rozlišení obsahu, pˇricˇ emž další typy jsou definovány oddˇelenˇe v jiných RFC dokumentech (napˇríklad níže uvedený typ compressed-data je definován v RFC3274 [17]). Standard S/MIME (viz 2.1.2) využívá první cˇ tyˇri níže uvedené typy. Data - obsahem tohoto typu jsou libovolné 8bitové rˇ etˇezce dat, napˇríklad text v kódování ASCII. S/MIME používá id-data k oznaˇcení obsahu ve formátu MIME (Multipurpose Internet Mail Extensions). Signed-data - obsahem jsou libovolná data s žádným až libovolným pocˇ tem podpisu. ˚ Z podepisovaných dat se vytvoˇrí otisk (digest) pomocí algoritmu specifického pro každého podepisujícího a tento otisk se podepíše soukromým klíˇcem podepisujícího. Pˇridá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ˇrí objekt SignedData, který je obsahem výsledné obálky ContentInfo. Pˇríjemce po pˇrijetí zprávy vytvoˇrí nezávislý otisk za pomoci ovˇerˇ eného veˇrejného klíˇce podepisujícího a pokud vypoˇcítaný otisk odpovídá pˇrijatému, je podpis prohlášen za platný. Enveloped-data - obsahem jsou libovolná zašifrovaná data a libovolný poˇcet zašifrovaných šifrovacích klíˇcu˚ pro jednoho cˇ i více pˇríjemcu. ˚ Kombinace jednoho zašifrovaného obsahu a jednoho zašifrovaného šifrovacího klíˇce pro jednoho pˇríjemce je “digitální obálka” pro tohoto pˇríjemce. 7


Compressed-data - obsahem jsou libovolná data, na která je aplikován kompresní algoritmus. Všichni klienti s podporou CMS typu Compresseddata musí umˇet pracovat s kompresí zlib [7]. Komprese dat redukuje redundanci, která by mohla pomoci útoˇcníkovi pˇri pokusu o prolomení bezpeˇcnosti hrubou silou a umožnuje ˇ rychlejší zpracování zásilek díky zmˇenšení objemu dat. Digested-data - obsahem jsou libovolná data a otisk tˇechto dat vypocˇ ítaný vybraným algoritmem. Obvykle je objekt typu digested-data použit pro kontrolu integrity a používá se jako vstup pˇri zpracování objektu enveloped-data. Encrypted-data - obsahem jsou libovolná zašifrovaná data. Na rozdíl od typu enveloped-data však nejsou pˇriloženy informace o pˇríjemcích, ani zašifrované šifrovací klíˇce. Šifrovací klíˇce musí být spravovány jiným zpu˚ sobem, nebo odvozené z poskytnuté informace. Typickým pˇrípadem užití tohoto typu je zašifrování dat a jejich lokální uložení, pˇriˇcemž šifrovací klíˇc bývá odvozen z hesla pro pˇrístup k datum. ˚ Authenticated-data - obsahem jsou libovolná data, jejich Message Authentication Code (dále MAC) a zašifrované autentizaˇcní klíˇce pro jednoho nebo více pˇríjemcu. ˚ Kombinace MAC a jednoho zašifrovaného autentizaˇcního klíˇce pro jednoho pˇríjemce je nezbytná pro ovˇerˇ ení integrity puvod˚ ního obsahu jedním pˇríjemcem. Duležité ˚ RFC dokumenty RFC2315 [28] - “PKCS #7: Cryptographic Message Syntax Version 1.5” je standard definující první verzi standardu CMS, která témˇerˇ kopíruje standard PKCS #7. RFC2630 [21] - “Cryptographic Message Syntax (Proposed standard)” je aktualizace standardu CMS zachovávající zpˇetnou kompatibilitu s verzí 1.5. Tato aktualizace není oznaˇcena jako samostatná verze, nebot’ pouze rozšiˇruje možnosti pro pˇrenos certifikátu. Konkrétnˇe umožnuje ˇ uložení doruˇceného certifikátu na stranˇe klienta a nepˇrikládání certifikátu k zásilce pro následující komunikaci. 8


RFC3274 [17] - “Compressed Data Content Type for Cryptographic Message Syntax (CMS)” definuje podrobnosti týkající se S/MIME typu Compresseddata, zejména zpusob ˚ vytvoˇrení obálky a použitelné cˇ i povinnˇe podporované algoritmy. RFC3369 [23] - “Cryptographic Message Syntax (Proposed standard)” je další aktualizace CMS standardu verze 1.5 rozšiˇrující standard o práci s klíˇci a upravující možnosti pˇrenosu certifikátu. ˚ Nejvýznamnˇejší zmˇenou provedenou v tomto standardu je však oddˇelení specifikace šifrovacích a hešovacích algoritmu˚ 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ˇrující množinu formátu˚ použitelných pro pˇrenos certifikátu˚ a pˇridávající zpusob ˚ práce s ovˇerˇ ením platnosti certifikátu pomocí revocation lists. RFC5652 [25] - “Cryptographic Message Syntax (Draft standard)” upˇresnuje ˇ drobné nejasnosti v RFC3852 bez pˇridání nových prvku˚ do standardu CMS. 2.1.2 S/MIME - Secure/Multipurpose Internet Mail Extensions Standard S/MIME je udržován standardizaˇcní 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 zpusob ˚ práce s digitálnˇe podepsanými, šifrovanými cˇ i komprimovanými e-maily. Služby poskytnuté digitálním podpisem dat Autentizace umožnuje ˇ pˇríjemci jednoznaˇcnˇe urˇcit identitu autora cˇ i autoru˚ zprávy. Kontrola integrity poskytuje jistotu, že obsah zprávy nebyl pˇri pˇrenosu zmˇenˇen. Nepopiratelnost puvodu ˚ zajišt’uje, že zpráva byla podepsána osobou, jejíž soukromý klíˇc byl použit k podpisu. V nepopiratelnosti puvodu ˚ se projevuje rozdíl mezi vlastnoruˇcním a digitálním podpisem - pokud nˇekdo získá soukromý klíˇc podepisujícího a vytvoˇrí s jeho pomocí digitální podpis, je 9


tento podpis naprosto identický s podpisem, který by vytvoˇril puvodní ˚ majitel soukromého klíˇce. Z tohoto pohledu je použití digitálního podpisu nevýhodou, avšak ve srovnání s vlastnoruˇcním podpisem má také velikou výhodu. Pˇri vytvoˇrení vlastnoruˇcního podpisu nejsou obvykle žádné dva podpisy zcela stejné, proto pˇri ovˇerˇ ení pravosti podpisu lze pouze posoudit, s jakou pravdˇepodobností byl podpis opravdu vytvoˇren podepsanou osobou. U digitálního podpisu je ovˇerˇ ení vždy jisté - pro podpis dat daný soukromý klíˇc použit byl, nebo nebyl. Služby poskytnuté šifrováním dat Pomocí šifrování pˇrenášených dat lze dosáhnout pˇredevším soukromí - obsah zprávy mohou cˇ íst pouze uživatelé, kteˇrí mají potˇrebné soukromé klíˇce. Nevýhody použití S/MIME Web-mailoví klienti nemohou implementovat podporu standardu S/MIME na stranˇe serveru, nebot’ k podepsání cˇ i zašifrování zprávy potˇrebují pˇrístup k soukromému klíˇci podepisující entity. Soukromý klíˇc by však mˇel být po celou dobu existence pod výhradní kontrolou svého vlastníka a umístˇení klíˇce na cizí server proto nelze akceptovat jako rˇ ešení. Výpoˇcty k aplikaci kryptografických operací tedy musí být provádˇeny na stranˇe klienta (webového prohlížeˇce, implementace je obvykle formou zásuvných modulu). ˚ Zásuvné moduly jsou bohužel v souˇcasné dobˇe dostupné pouze pro nˇekteré webové prohlížeˇce založené na jádˇre Gecko [12] (napˇríklad Mozilla Firefox). Nˇekteˇrí e-mailoví klienti neumí data ve formátu S/MIME zpracovat, což muže ˚ vést k neˇcitelnosti e-mailu cˇ i zobrazení pˇrílohy se jménem “smime.p7s” kterou neumí bˇežní uživatelé otevˇrít. Šifrování e-mailu zajišt’uje end-to-end security, tedy zašifrovaný obsah je k pˇríjemci doruˇcen v nezmˇenˇené podobˇe. 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 e-mailu je neˇcitelný pro antivirové programy na branách do firemních sítí, u poskytovatele internetového pˇripojení cˇ i na webmailových serverech. Malware se muže ˚ touto cestou dostat až na koncovou stanici pˇríjemce. Možnou obranou je spolehlivý personální antivirus a firewall na stanici, kde dojde k otevˇrení zásilky, uložení klíˇce na serveru s antivirem nebo použití techniky key-escrow. Zašifrování e-mailu 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ˇcné. 10


Vytvoˇrení S/MIME zásilky Každá zásilka ve formátu MIME se skládá z nˇekolika cˇ ástí (obvykle nazývaných part cˇ i MIME entita) oddˇelených oddˇelovaˇcem (boundary), který je v rámci zásilky unikátní. Jednotlivé cˇ ásti lze do sebe vnoˇrovat a vytvárˇ et tak stromovou strukturu (vzniká n-ární koˇrenový strom). K podpisu cˇ i šifrování se používají klíˇce uložené ve fomátu PKCS#12 [30] (viz 2.2.1). Kryptografické operace lze aplikovat na libovolnou MIME entitu (pˇrípadnˇe na zásilku jako celek, triviálnˇe aplikací na koˇrenovou entitu bez hlaviˇcek definovaných v RFC822 [5]) a v libovolném poˇctu iterací. Pˇred kryptografickým zpracováním vstupních dat je potˇreba tato data uvést do kanonického tvaru (viz RFC2049 [13]). Proces vytvoˇrení S/MIME entity se skládá ze dvou základních kroku˚ aplikace kryptografické operace na puvodní ˚ MIME entitu a vytvoˇrení nových MIME hlaviˇcek. Tímto zpusobem ˚ dojde k “obalení” puvodního ˚ obsahu, pˇriˇcemž obalení lze provést nˇekolika postupy. O konkrétním postupu informuje novˇe vzniklý S/MIME part pomocí adekvátní hodnoty MIME atributu Content-type (viz 2.1.2). Takovéto obalení lze provádˇet opakovanˇe, pˇriˇcemž kryptografické operace cˇ i podepisující autority se mohou libovolnˇe stˇrídat. Vícenásobného obalení se také využívá k vytvoˇrení “trojobalu” (triple wrapping, definováno v RFC2634 [20], sekce 1.1). Technika triple wrapping spoˇcívá v digitálním podepsání, zašifrování a opˇetovném podepsání puvodního ˚ obsahu. První (vnitˇrní) podpis zajišt’uje integritu, nepopiratelnost puvodu ˚ a autentizaci. Pˇripojením nˇekterých atributu˚ hlaviˇcky k obsahu podepsanému prvním podpisem jsou tyto atributy chránˇeny stejnˇe jako puvodní ˚ obsah. Následné zašifrování zaruˇcí duvˇ ˚ ernost podepsaného obsahu, vˇcetnˇe podepsaných atributu˚ hlaviˇcky. Druhý (vnˇejší) podpis poskytuje autentizaci a ovˇerˇ ení integrity informací, které jsou zpracovány pˇri pˇreposílání zásilky. Takto zpracovaná MIME entita (vˇcetnˇe hlaviˇcek) pˇrijde od odesílatele k pˇríjemci nezmˇenˇena bez ohledu na pocˇ et agentu, ˚ kteˇrí zpracovávají zásilku bˇehem doruˇcení (napˇríklad mailinglistoví agenti). Algoritmus pro šifrování obsahu, který musí umˇet odesílatel i pˇríjemce, je DES EDE3 CBC (dále 3DES [22]), pˇríjemce by mˇel podporovat také RC2 [37] se 40bitovým klíˇcem (dále RC2/40), algoritmus lze však použít pouze na informace, které nemusí být silnˇe šifrované. Pˇríjemce i odesílající by mˇeli podporovat algoritmus AES [32] s použitím klíˇce o velikosti 128,192 a 256 bitu. ˚ Kvuli ˚ dodržení zpˇetné kompatibility s klienty, kteˇrí nepodporují standard S/MIME, by mˇel odesílající klient uvádˇet jméno souboru v hlaviˇckách 11


MIME entity Content-disposition a Content-type. Pˇrípona souboru by mˇela odpovídat danému typu S/MIME zprávy (viz 2.1.2). Pˇrijetí S/MIME zásilky Po pˇrijetí zprávy a ovˇerˇ ení platnosti veˇrejného certifikátu by mˇel pˇríjemce zaznamenat cˇ as pˇrijetí zprávy a preferovaný algoritmus symetrické kryptografie pro další komunikaci. Pˇri každém dalším pˇrijetí zprávy by mˇel pˇríjemce ovˇerˇ it, že cˇ as podepsání zprávy je vyšší než poslední zaznamenaný cˇ as pˇrijetí zprávy. Pˇri vytváˇrení odpovˇedi na pˇrijatou zásilku by mˇel pˇrijímající klient zohlednit seznam preferovaných algoritmu. ˚ Pokud odesílatel zprávy nespecifikoval preferované algoritmy, pˇri odpovˇedi se použije stejný algoritmus, jaký byl použit u pˇríchozí zprávy. Klient musí být schopen ovˇerˇ ovat pravost X.509 certifikátu˚ podle PKIX [2] a nesmí používat PKCS #6 [31] certifikáty. Typy S/MIME zpráv Atribut Content-type hlaviˇcky novˇe vytvoˇrené MIME zásilky muže ˚ nabývat hodnot application/pkcs7-mime nebo multipart/signature. První uvedený MIME typ se používá k pˇrenosu CMS typu˚ EnvelopedData, SignedData a CompressedData, druhý typ se používá k pˇripojení podpisu oddˇelenˇe od podepisovaného obsahu (tzv. detached signature). Odesílající agent by mˇel navíc do atributu Content-type pˇridat parametr smime-type, aby sdˇelil pˇrijímajícímu agentovi kryptografické operace, které byly aplikovány na vnoˇrený obsah a ulehˇcil tak práci s dekódováním ASN.1 struktury zásilky. Odesílající agent by mˇel také použít parametr name a uvést jméno souboru (napˇríklad “smime”) vˇcetnˇe pˇrípony kvuli ˚ kompatibilitˇe s pˇrijímajícími klienty, kteˇrí nepodporují zpracování S/MIME zásilek. Možné kombinace pˇrípon uvádí následující tabulka: MIME typ application/pkcs7-mime application/pkcs7-mime application/pkcs7-mime application/pkcs7-signature

CMS typ SignedData, EnvelopedData SignedData CompressedData SignedData

Pˇrípona p7m p7c p7z p7s

12


Parametr smime-type: Úˇcelem parametru je poskytnout informace o aplikovaných kryptografických operacích pˇríjemci. Seznam možných kombinací: parametr smime-type enveloped-data signed-data certs-only compressed-data

CMS typ EnvelopedData SignedData SignedData CompressedData

Vnitˇrní obsah id-data id-data none id-data

S/MIME typ enveloped-data: Tento typ zprávy slouží k posílání textu v šifrované podobˇe, ale absence podpisu nezaruˇcuje integritu dat. Postup vytvoˇrení MIME entity: 1. MIME entita je pˇrevedena do kanonického tvaru. 2. MIME entita a další potˇrebná data jsou pˇrevedeny 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ˇridány parametry smime-type=enveloped-data a name =smime.p7m Pˇríklad hlaviˇcky 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 muže ˚ obsahovat v atributu Contenttype dva ruzné ˚ MIME typy, konkrétnˇe “application/pkcs7-mime” nebo “multipart/signed”. Odesílatel by mˇel preferovat “multipart/signed” (tzv. detached signature, obsah je cˇ itelný i pro klienty bez podpory S/MIME). Pˇrijímající agent musí umˇet zpracovat obˇe možnosti. MIME typ application/pkcs7-mime používá S/MIME typ signed-data. Pˇrípony souboru mohou být p7m (podepsaná zpráva) nebo p7c (obsah zprávy je prázdný, úˇcelem zásilky je pˇredání pˇriloženého certifikátu). 13


• Postup podepsání MIME entity je následující: 1. MIME entita je pˇrevedena do kanonického tvaru. 2. MIME entita a další potˇrebná data jsou pˇrevedeny 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ˇridány dva nové parametry – smime-type=signed-data a name =smime.p7m Ukázková hlaviˇcka 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ˇrení zprávy pro odeslání certifikátu je následující: 1. Je vytvoˇren 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ˇcka S/MIME partu je shodná s pˇredchozím pˇrípadem až na pˇríponu souboru v atributu Content-type. MIME typ multipart/signed se používá pro oznaˇcení entity, která má dva potomky (dvˇe dceˇrinné MIME entity). Tento typ je doporuˇcen pro použití odesílatelem, nebot’ obsah je cˇ itelný i pro klienty, kteˇrí neumí zpracovat zásilky typu S/MIME. V prubˇ ˚ ehu doruˇcení zásilky však muže ˚ dojít napˇríklad ke zmˇenˇe zalomení rˇ ádku˚ 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


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ˇrípona souboru je p7s. Vnoˇrený objekt SignedData nesmí obsahovat pole encapContentInfo. V hlaviˇcce je také uveden algoritmus použitý pro vytvoˇrení otisku (parametr micalg v atributu Content-type). Postup vytvoˇrení MIME entity typu multipart/signed : 1. MIME entita je pˇrevedena do kanonického tvaru. 2. MIME entita a další potˇrebná data jsou pˇrevedeny do CMS objektu typu SignedData, musí však chybˇet pole encapContentInfo. 3. Kanonizovaná puvodní ˚ MIME entita je vložena jako první dceˇrinná entita do novˇe vzniklé entity typu multipart/signed. 4. CMS objekt SignedData bez pole encapContentInfo je zpracován v souladu s použitým pˇrepravním kódováním. Použité pˇrepravní 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ˇrinná entita do rodiˇcovské entity typu multipart/signed. 6. Atribut Content-type je obohacen o parametry protocol=“application/pkcs7-mime” a micalg={množina alesponˇ jedné z hodnot v následující tabulce, oddˇelených cˇ árkami}. Parametr micalg slouží k urˇcení algoritmu pro výpoˇcet otisku zprávy pˇri 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


--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ˇrení S/MIME entity typu compressed-data: 1. MIME entita je pˇrevedena do kanonického tvaru. 2. MIME entita a další potˇrebná data jsou pˇrevedeny 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ˇresnující ˇ parametry – smime-type=compressed-data a name=smime.p7z Pˇríklad hlaviˇcky 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


Vícenásobné kryptografické operace: nˇekolikanásobné obalení je umožnˇeno identickým typem vstupních i výstupních dat pro každou ze tˇrí výše uvedených metod obalení. Výsledek jedné operace lze tedy poskytnout jako vstup operaci následující a poˇcet takovýchto iterací není omezen. Poˇradí aplikace podpisu a šifrování na zpracovaná data není bezvýznamné. Zašifrování podepsané zprávy bezpeˇcnˇe skryje podpis, který proto není možno zmˇenit. Naopak pˇri podepsání zašifrované zprávy je podpis vystaven možné zmˇenˇe, ale lze jej ovˇerˇ it bez dešifrování. Pˇríjemce zprávy, která byla zašifrována a poté podepsána, si muže ˚ ovˇerˇ it, že zašifrovaný obsah nebyl zmˇenˇen. Nemuže ˚ však urˇcit jakýkoliv vztah mezi podepisujícím a nezašifrovaným obsahem. Pˇríjemce zprávy, která byla podepsána a poté zašifrována, muže ˚ pˇredpokládat, že podepsaný obsah nebyl zmˇenˇen, ale schopný útoˇcník mohl zmˇenit neautentizované cˇ ásti šifrované zprávy. ˇ Rešení dilematu, zda dˇríve šifrovat nebo podepisovat, nabízí výše uvedená technika triple wrapping. Kompresi dat nemá smysl aplikovat na binární cˇ i kryptograficky zpracovaná data, lze ji však s úspˇechem použít na data kódovaná v base64 cˇ i na digitální data pˇred kryptografickým zpracováním. Rozpoznání typu S/MIME zásilky E-mail je v souladu se standardem S/MIME, pokud platí kterákoliv z následujících možností (pˇrí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ˇrípona souboru p7m, p7s, p7c

Dulež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ˇrebrala kontrolu organizace IETF (dokument je založen na standardu PKCS #7). Popisuje zpusob ˚ vytvoˇrení a zpracování pˇrijaté S/MIME zásilky, definuje nové potˇrebné MIME typy a je kompatibilní se standardem PKCS #7. RFC2312 [9] - “S/MIME Version 2 Certificate Handling” se stejnˇe jako pˇredchozí standard zabývá shrnutím standardu PKCS #7. Zamˇerˇ uje se na 17


ovˇerˇ ení klíˇcu, ˚ zaslaných jako souˇcást S/MIME zprávy, na základˇe správy certifikátu˚ v systémovém úložišti. RFC2632 [33] - “S/MIME Version 3 Certificate Handling” je aktualizací verze 2 a zamˇerˇ uje se na práci s certifikáty, kterou musí všichni S/MIME klienti podporovat a rozšiˇruje základní požadavky definované v RFC2459 [26] o použití Certificate Revocation Lists a o zákaz používání PKCS #6 certifikátu. ˚ RFC2633 [34] - “S/MIME Version 3 Message Specification” je aktualizací standardu verze 2, která upˇresnuje ˇ nˇekteré nejasnosti ve specifikaci standardu a pˇridává atributy pro drobná rozšíˇrení funkˇcnosti. RFC2634 [20] - “Enhanced Security Services for S/MIME” je dobrovolné rozšíˇrení standardu S/MIME umožnující ˇ odeslání podepsaného potvrzení o pˇríjmu zásilky, pˇrenos atributu identifikujícího míru citlivosti dat (security label ), provozování zabezpeˇcených mailing-listu˚ a podepisování certifikátu˚ zasílaných jako souˇcást zprávy. RFC3850 [35] - “S/MIME Version 3.1 Certificate Handling” je aktualizací RFC2632 [33], které rozšiˇruje o povinnost podporovat CRLv1 a CRLv2, aktualizuje množinu použitelných šifrovacích a hešovacích algoritmu˚ a upˇresnuje ˇ nˇekteré nejasnosti z dˇrívˇejší verze standardu. RFC3851 [36] - “S/MIME Version 3.1 Message Specification” upˇresnuje ˇ povinnost použití algoritmu˚ pro vytvoˇrení podpisu a šifrování dat, upˇresnuje ˇ nejasnosti pˇredchozích verzí standardu a zavádí možnost použití CMS typu Compressed-data.

2.2

Standardy pro certifikáty a klíˇce

2.2.1 PKCS#12 - Syntaxe pro výmˇenu osobních informací Standard PKCS#12 vznikl a je udržován v RSA Laboratories a je zaˇrazen do skupiny standardu˚ Public-Key Cryptography Standards (PKCS). Definuje formát souboru˚ pro ukládání soukromých klíˇcu˚ s odpovídajícími certifikáty veˇrejných klíˇcu, ˚ chránˇených symetrickým šifrováním založeným na hesle. Pˇredchudcem ˚ standardu PKCS#12 je standard PFX od firmy Microsoft. 18


PKCS#12 je kontejnerový formát, jeden soubor s typickou pˇríponou p12 muže ˚ obsahovat více vložených objektu, ˚ napˇríklad více certifikátu. ˚ Uvádˇet více informací o standardu PKCS#12 není dle mého názoru pro tuto práci relevantní, nebot’ standard se netýká pˇrímo zadaného tématu. Všechna zvažovaná technická rˇ 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 rˇ ešení. Více informací o PKCS#12 lze nalézt prostudováním následujících zdroju: ˚ • PKCS #12: Personal Information Exchange Syntax Standard [30]. • OpenSSL PKCS#12 FAQ [19].

19

3 Srovnání vybraných technických rˇešení 3.1

Popis systému pro prototypovou implementaci

Prototypová implementace nˇekteré z níže diskutovaných technologií bude provedena v informaˇcním systému Kaskáda [40]. Kaskáda je systém pro správu firemní agendy, Custommer Resource Management a Enterprise Resource Planning. Umožnuje ˇ mimo jiné vedení úˇcetnictví, správu komunikací, skladu, ˚ objednávek, zakázek, majetku, rˇ ízení projektu˚ a muže ˚ sloužit jako dokumentový sklad. Systém zaˇcal vznikat v roce 2000 na základˇe pˇredchozích deseti let zkušeností s vývojem firemních IS pro prostˇredí Microsoft DOS. Cílová skupina zákazníku˚ jsou malé a stˇrední firmy, které nechtˇejí cˇ i nemohou implementovat komplexní systémy jako je SAP.

3.2

Kritéria výbˇeru technologie pro implementaci

Kritéria jsou rˇ azena podle duležitosti ˚ od nejduležitˇ ˚ ejších. Následuje krátký popis významu každého kritéria, podle kterého se bude rˇ ídit výbˇer technologie pro implementaci. 3.2.1 Kompatibilita s IS Kaskáda Vybraná technologie musí být s IS Kaskáda kompatibilní z pohledu technologického i licenˇcního. Technologická kompatibilita Kaskáda používá SQL server od firmy Software602 (602SQL Server, dˇríve komerˇcní produkt), který byl v roce 2009 uvolnˇen jako freeware pro volné použití a verze 10 byla uvolnˇena pod názvem OpenSQL Server vˇcetnˇe zdrojových kódu. ˚ Kaskáda [40] je vyvíjena v prostˇredí Borland Delphi 6 (nyní Embarcadero Delphi [10], dále jen Delphi). Delphi IDE (Integrated Development Environment) je založeno na objektovˇe orientované verzi jazyka Pascal (Object Pascal). Cílovým operaˇcní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ému˚ provozovat i ve Windows Vista 20

ˇ 3. S ROVNÁNÍ VYBRANÝCH TECHNICKÝCH REŠENÍ

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


3.2.5 Stabilita Zvolené technické rˇ ešení musí být v použité verzi stabilní, nebot’ aktualizace technického rˇ ešení v IS Kaskáda [40] budou provádˇeny pouze v nezbytnˇe nutných pˇrípadech. 3.2.6 Podpora produktu Podmínkou zvolení technického rˇ ešení je aktivní podpora produktu – formou mailing-listu, diskuzních fór a podobnˇe.

22


3.3

Open StreamSec II

Autorem kolekce komponent StreamSec Tools je Henrick Hellström. StreamSec Tools je kolekce komponent a tˇríd pro Delphi IDE zamˇerˇ ených na kryptografii a bezpeˇcnost. Produkt implementuje podporu pro SSL/TLS, S/MIME a práci s X.509 certifikáty. Verze 2.1 je dostupná zdarma, novˇejší verze 3 je komerˇcní produkt s cenou okolo 500 e [18] za jednoho vývojáˇre. Verzi 2.1 lze stáhnout na adrese http://sourceforge.net/projects/openstrsecii/files/.

3.3.1 Kompatibilita s IS Kaskáda Technická kompatibilita Open StreamSec II je kolekce VCL komponent a tˇríd vyvinutých pˇrímo pro Delphi IDE a je plnˇe kompatibilní s Delphi6. Licenˇcní kompatibilita Volnˇe dostupná verze 2.1 je dostupná pod licencí ve stylu BSD [39], která dovoluje šíˇrení ve formˇe zdrojových kódu˚ i pˇreložených binárních dat a to vˇcetnˇe pˇrípadných uživatelských úprav cˇ i jako souˇcást komerˇcního software. Požaduje s distribucí zdrojového cˇ i binárního kódu také distribuovat text puvodní ˚ licence a jméno StreamSec ani jména autoru˚ nesmí být spojována s produktem vzniklým úpravou puvodního ˚ produktu bez pˇredchozího souhlasu autoru. ˚ 3.3.2 Úrovenˇ implementace funkcí Verze 2.1 poskytuje veškerou požadovanou funkˇcnost a to vˇcetnˇe vlastního rˇ ešení správy X.509 certifikátu. ˚ 3.3.3 Dokumentovanost API Dokumentace se nainstaluje jako souˇcást Delphi IDE a lze ji najít v menu Nápovˇeda. Dokumentace bohužel není pˇríliš podrobná a popisy nˇekterých tˇríd a metod chybí úplnˇe. V nˇekterých pˇrípadech je jeden funkˇcní aspekt implementován ve více tˇrídách, avšak nikde nejsou popsány rozdíly v jednotlivých implementacích. 23


3.3.4 Složitost API Množina tˇríd a funkcí je velká a neintuitivnˇe pojmenovaná. Práce s API není jednoduchá a uživatel je nucen pracovat postupem “pokus-omyl”. 3.3.5 Dostupnost SDK SDK je na velmi dobré úrovni, poskytuje sadu demo aplikací i balíky komponent které lze nainstalovat do Delphi IDE bˇežnými nástroji, které IDE nabízí. Ukázkové aplikace jsou bohužel zamˇerˇ eny pˇredevším na práci s X.509 certifikáty a pro zpracování S/MIME zásilek neposkytly potˇrebné ukázkové zdrojové kódy. 3.3.6 Stabilita Implementace založená na poslední uvolnˇené verzi je stabilní. 3.3.7 Podpora autoru˚ Další vývoj produktu byl zastaven, respektive byla založena nová komerˇcní vývojová vˇetev StreamSec 3. Vývojová vˇetev 2.1 má stále aktivní podporu komunity vývojáˇru˚ Delphi, zejména díky implementaci starší verze 2.1 do mnoha aplikací.

24


3.4

OpenSSL

OpenSSL je komunitní projekt, aktuální seznam vývojáˇru˚ je dostupný na http://www.openssl.org/about/. Autory knihovny SSLEay, na které je OpenSSL založeno, jsou Eric A. Young a Tim J. Hudson. OpenSSL je sada nástroju˚ zamˇerˇ ených na implementaci protokolu SSL (Secure Socket Layer) verze 2 i 3, protokolu TLS (Transport Layer Security) a obecnˇe na vývoj nástroje poskytujícího podporu pro nejruznˇ ˚ ejší kryptografické operace. Mezi základní principy dodržované pˇri vývoji OpenSSL patˇrí otevˇrenost zdrojových kódu˚ pˇri zachování možnosti využít nástroj v komerˇcních aplikacích. Pro úˇcely 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žnuje ˇ vygenerovat osobní certifikát podle standardu PKCS #12. K tomuto úˇcelu však musí být OpenSSL alesponˇ verze 0.9.5a a musí být kompilované spolu s knihovnou pkcs12 ), který jsem používal pˇri testování všech tˇrí technických rˇ ešení. OpenSSL je software s otevˇreným zdrojovým kódem, který lze stáhnout z ftp://ftp.openssl.org/source/. Binární spustitelné soubory pˇreložené pro linuxové operaˇcní systémy jsou obvykle souˇcástí distribuce, binární soubory pro Windows lze stáhnout z http://www.openssl.org/related/binaries.html. 3.4.1 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ˇredevším knihovnu libeay32.dll. DLL knihovny jsou dostupné jako souˇcá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ˇe libeay32.dll. Licenˇcní kompatibilita OpenSSL je licencováno pod dvˇemi licencemi typu BSD [39]. Jedna pochází od autoru˚ OpenSSL a druhá od autoru˚ knihovny SSLEay, na které je 25


OpenSSL postaveno. Aktuální licence je v plném znˇení pˇrístupná na http: //www.openssl.org/source/license.html. 3.4.2 Úrovenˇ implementace funkcí OpenSSL poskytuje podporu pro ovˇerˇ 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áˇrení a ovˇerˇ ování. OpenSSL bohužel neposkytuje mechanismus úložištˇe certifikátu. ˚ 3.4.3 Dokumentovanost API API je kvalitnˇe dokumentováno online na stránkách projektu, navíc je k dispozici mnoho tutoriálu˚ a dokumentu˚ publikovaných cˇ leny komunity. 3.4.4 Složitost API API je relativnˇe jednoduché, funkce pro práci s S/MIME zásilkami jsou však ve fázi vývoje a nejsou stabilní. 3.4.5 Dostupnost SDK SDK není dostupné. 3.4.6 Stabilita OpenSSL je stále se vyvíjející projekt, který se postupnˇe mˇení. Samotné knihovny poskytují relativnˇe stabilní rˇ ešení, rozhraní mezi knihovnou libeay32.dll a Delphi IDE je však stále nekompletní a postupnˇe vyvíjené. 3.4.7 Podpora autoru˚ Projekt se aktivnˇe vyvíjí a komunita jeho uživatelu˚ a vývojáˇru˚ poskytuje velmi dobrou podporu.

26


3.5

Capicom a CryptoAPI

Autorem ActiveX prvku CAPICOM je spoleˇcnost 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ˇem certifikátu˚ Windows. 3.5.1 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 vytvorˇ it rozhraní pro komunikaci. Pro úˇcely volání CryptoAPI z Delphi IDE je dostupné rozhraní poskytované projektem JEDI API Library [27]. Licenˇcní kompatibilita CAPICOM je distribuován pod licencí Microsoftu, která dovoluje CAPICOM volnˇe distribuovat a zahrnovat do vlastních produktu˚ za podmínky splnˇení nˇekolika požadavku, ˚ které IS Kaskáda splnuje ˇ a pˇrípadná implementace umožnuje. ˇ CryptoAPI je bˇežnou souˇcástí systému˚ Windows. Projekt JEDI API Library lze použít i v komerˇcních aplikacích. 3.5.2 Úrovenˇ implementace funkcí CryptoAPI (tedy i CAPICOM) poskytuje veškerou požadovanou funkˇcnost vˇcetnˇe pˇrístupu k systémovému úložišti certifikátu. ˚ 3.5.3 Dokumentovanost API CAPICOM i CryptoAPI mají online dokumentaci dostupnou na webu Microsoft Development Network [3]. 3.5.4 Složitost API Funkce a tˇrídy mají velmi intuitivní názvy, názvy parametru˚ jsou naopak cˇ asto mnohoznaˇcné, avšak též dostateˇcnˇe dokumentované. 27


3.5.5 Dostupnost SDK CAPICOM SDK lze zdarma stáhnout z http://www.microsoft.com/ downloads/ (konkrétní adresa se bohužel cˇ asto mˇení, proto doporuˇcuji použít vyhledávání). SDK obsahuje samotnou knihovnu capicom.dll a nˇekolik 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ˇe velké množství ukázkového kódu. 3.5.6 Stabilita Použití CryptoAPI i CAPICOMu zajišt’uje stabilitu odpovídající implementaci v dané verzi operaˇcního systému, celkovˇe jsem však pˇri testování nenarazil na problémy se stabilitou. 3.5.7 Podpora autoru˚ Microsoft uvádí ve své online dokumentaci rˇ adu pˇríkladu, ˚ z nichž nˇekteré jsou souˇcá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ódu˚ od Microsoftu i od autoru˚ tˇretí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ˇcuje Microsoft využít pˇrímého volání funkcí CryptoAPI.

28

4 Vyhodnocení pruzkumu ˚ 4.1

Shrnutí výhod a nevýhod jednotlivých rˇešení

4.1.1 Open StreamSec II Výhody Jedná se o nativní rˇ ešení založené od základu na prostˇredí Delphi IDE a jazyce Object Pascal. Poskytuje vlastní rˇ ešení správy certifikátu˚ a jejich úložištˇe.

Nevýhody Nedostatky v dokumentaci považuji za natolik závažné, že vyluˇcují praktickou použitelnost a spolehlivost celého rˇ ešení. Ukázkové aplikace se bohužel zamˇerˇ ují zejména na práci s X.509 certifikáty a jejich úložištˇe, bez dokumentace jsem tedy nebyl schopen implementovat v plném rozsahu práci s S/MIME zásilkami.

4.1.2 OpenSSL Výhody Dokumentace je podrobná, dobˇre strukturovaná, snadno dostupná, podpora komunity je aktivní. OpenSSL je stabilní a ovˇerˇ ené rˇ ešení použité v mnoha aplikacích.

Nevýhody OpenSSL bohužel neimplementuje úložištˇe certifikátu, ˚ nekontroluje odvolání certifikátu u Certificate Revocation List a neumí automaticky urˇcit typ použitého hešovacího algoritmu na základˇe atributu SMIMECapabilities hlaviˇcky Content-Type. Verze 1.0 umí pracovat pouze s S/MIME v2, složitˇejší struktury definované v S/MIME v3 zpusobují ˚ chyby pˇri parsování. MIME parser použitý v OpenSSL není stabilní a kolabuje na nˇekterých neobvyklých zprávách. 29

˚ 4. V YHODNOCENÍ PR UZKUMU

4.1.3 Capicom Výhody CAPICOM a CryptoAPI jsou cˇ asto používaným nástrojem, díky cˇ emuž mají silnou podporu ze strany vývojáˇru˚ i uživatelu. ˚ Navíc umožnují ˇ pracovat se systémovým úložištˇem certifikátu, ˚ které jsou obvykle zvyklí spravovat i uživatelé s nepˇríliš velkými znalostmi v oblasti kryptografie (zejména v pˇrípadˇe, ž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ˇrípadˇe potˇreby nahradit za pˇrímá volání CryptoAPI. CAPICOM má rozhraní tak jednoduché, že v nˇem nˇekteré funkce chybí. Napˇríklad v pˇrípadˇe, že podpis neprojde ovˇerˇ ením, jelikož není považován za duvˇ ˚ eryhodný, nejsou naplnˇeny promˇenné potˇrebné pro pˇrípadnou instalaci certifikátu do systémového úložištˇe. Takováto místa je potˇreba v praktické implementaci doplnit pˇrí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ˇcné rˇ ešení CAPICOM a CryptoAPI. Duvodem ˚ byla pˇredevším dostupnost veškerých požadovaných funkcí vˇcetnˇe vlastního rˇ ešení úložištˇe certifikátu˚ a spolehlivost. S pomocí CAPICOMu lze implementovat tvorbu a ovˇerˇ ování podepsaných zásilek i práci se zásilkami šifrovanými, na druhou stranu z mého pˇredbˇežného pruzkumu ˚ nevyplývaly žádné zásadní nedostatky, které by ohrožovaly funkˇcnost cˇ i udržitelnost rˇ ešení postaveného na knihovnˇe CAPICOM. Ukázky práce s knihovnou CAPICOM a CryptoAPI jsou uvedeny jako pˇrílohy na konci této práce.

4.3

Implementace vybraného rˇešení v IS Kaskáda

4.3.1 Shrnutí kroku˚ implementace Implementace probíhala ve dvou základních krocích: 1. implementace práce s podpisy typu attached signature (vytváˇrení a kontrola podpisu) ˚ pro ovˇerˇ ení technické kompatibility s IS Kaskáda; 30

˚ 4. V YHODNOCENÍ PR UZKUMU

2. implementace práce s podpisy typu detached signature a práce s šifrovanými zásilkami. 4.3.2 Komplikace související se zvolenou implementací Žádná z komplikací, na které jsem narazil pˇri implementaci, se neprojevovala náhodnˇe (což by naznaˇcovalo možnou nestabilitu v budoucím praktickém provozu). Pˇri implementaci jsem musel vyˇrešit následující problémy související s použitím CAPICOM: • CAPICOM umí pracovat pouze s rˇ etˇezci v kódování Unicode s pevnou dvoubajtovou šíˇrkou znaku, což neodpovídá vnitˇrní reprezentaci rˇ etˇezce v Delphi6. Navíc v pˇrípadˇe, že rˇ etˇezec má lichý poˇcet znaku, ˚ je poslední znak oˇríznut (což zejména v pˇrípadˇe, že z rˇ etˇezce poˇcítáme heš, není pˇrijatelné). ˇ Rešení spoˇcívá v použití typu WideString, který používá pevnou šíˇrku znaku˚ a zmˇenˇe na sudou délku rˇ etˇezce. • Zpráva podepsaná pomocí CAPICOM v režimu detached signature šla zpˇetnˇe ovˇerˇ it v IS Kaskáda i v poštovním klientovi Mozilla Thunderbird, nikoliv však v Microsoft Outlooku. Duvodem ˚ je, že Outlook pˇred výpoˇctem kontrolního heše z podepisované MIME entity odstraní poslední zalomení rˇ ádku (znaky Carriage Return a Line Feed). ˇ Rešením bylo pˇri podepisování v režimu detached signature vypocˇ ítat heš pro podpis z podepisované MIME entity a poté pˇred finálním sestavováním MIME zásilky na konec podepisované entity pˇridat volný rˇ ádek. Schopnost ovˇerˇ enit podpis klientem Mozilla Thunderbird zustala ˚ touto úpravou zachována. • V pˇrípadˇe, že selže ovˇerˇ ení podpisu, funkcemi CAPICOMu nelze zjistit certifikáty použité pro podepsání zprávy. Typickým scénáˇrem je obdržení e-mailu od osoby, jejíž certifikát ještˇe nemáme nainstalován, a není tedy duvˇ ˚ eryhodný, o certifikátu se však domníváme, že je pravý (osoba s níž komunikujeme nám sdˇelila otisk certifikátu a otisk odpovídá). ˇ Rešením je pˇrímé volání funkcí CryptoAPI, které umožnují ˇ z podepsaných dat získat podpisové certifikáty bez ohledu na výsledek ovˇerˇ ení podpisu. Certifikáty jsou následnˇe zobrazeny uživateli a pˇrípadnˇe importovány do systémového úložištˇe.

31

5 Závˇer Na základˇe rozboru uvedeného v kapitole 4 hodnotím zvolení knihovny CAPICOM a použití CryptoAPI jako vhodné, nebot’ jsem byl schopen s jejich pomocí implementovat veškerou požadovanou funkˇcnost za požadovaných podmínek. Navzdory komplikacím uvedeným v sekci 4.3.2 jsem byl pˇríjemnˇe pˇrekvapen mírou zapouzdˇrení celé funkˇcnosti v knihovnˇe CAPICOM, což mi umožnilo soustˇredit se na aplikaˇcní logiku místo na implementaci základních kryptografických operací. Záporným aspektem zapouzdˇrení z hlediska vývoje aplikace jsou velmi úsporná chybová hlášení, která neposkytují dostatek informací. K podrobnˇejším informacím jsem se obvykle dostal po prostudování dokumentace CryptoAPI a diskuzních fór na Internetu, zejména mailing-listu produktu Synapse. Domnívám se, že rˇ ešení bude i do budoucna stabilní a schopné provozu na všech aktuálnˇe dostupných verzích systému Microsoft Windows (Windows XP, Windows Vista a Windows 7). V pˇrípadˇe, že v následujících verzích systému Windows nebude možné používat knihovnu CAPICOM, lze s vynaložením nepˇríliš velkého úsilí pˇrejít na pˇrímé volání služeb Cryptographic Service Provider pomocí CryptoAPI. V dubnu 2010 je již prototypová implementace pˇrevedena z testovacího provozu do provozu u zákazníku, ˚ k jejich plné spokojenosti. Nabyté znalosti a základ prototypové implementace v IS Kaskáda mají potenciál být znovu využity pro zabezpeˇcení dat ukládaných do relaˇcní databáze. Zejména by se mohlo jednat o ukládání citlivých vnitrofiremních dokumentu˚ cˇ i o implementaci práce s datovými schránkami pro komunikaci se státními institucemi.

32

A Zdrojové kódy pro práci se zásilkami A.1 Vytvoˇrení podpisu typu attached signature procedure VytvorAttachedSignature(From, To, Subject, Content : String) : TMimeMess; var MessBody : TMimeMess; SignData : SignedData; ContentPart : TMimePart; begin ContentPart := nil; SD := nil; Result := nil; try MessBody := TMimeMess.Create; MessBody.Header.From := From; MessBody.Header.ToList.Add(To); MessBody.Header.Subject := Subject; MessBody.MessagePart.Headers.Add( ’Content-Type: application/x-pkcs7-mime; ’ + ’smime-type="signed-data"; ’ + ’name="smime.p7m"’+#13#10 + ’Content-Transfer-Encoding: base64’+#13#10 + ’Content-Disposition: attachment; ’+ ’filename="smime.p7m"’); ContentPart := TMimePart.Create; ContentPart.Headers.Add( ’Content-type: text/plain’+#13#10+ ’Content-Transfer-Encoding: 7bit’); ContentPart.PartBody.Text := Content; ContentPart.ComposeParts; SD := CoSignedData.Create; SD.Content := StringToAPIString( ContentPart.Lines.Text); 33

A. Z DROJOVÉ KÓDY PRO PRÁCI SE ZÁSILKAMI MessBody.MessagePart.PartBody.Text := APIStringToString( SD.Sign( nil, false, CAPICOM_ENCODE_BASE64 ) ); MessBody.EncodeMessage; Result := MessBody; finally ContentPart.Free; SD.Free; end; end;

A.2 Vytvoˇrení podpisu typu detached signature procedure VytvorDetachedSignature (From, To, Subject, Content : String) : TMimeMess; var MessBody: TMimeMess; MainPart, CntPart, SigPart : TMimePart; StrBase64 : String; SD : SignedData; begin SD := nil; Result := nil; try MessBody := TMimeMess.Create; MessBody.Header.From := From; MessBody.Header.ToList.Add(To); MessBody.Header.Subject := Subject; MainPart := MessBody.AddPartMultipart(’signed; ’+ ’protocol="application/x-pkcs7-signature";’ + #13#10 + ’ micalg=SHA1’, nil); MainPart.PrePart.Text := ’This is a multi-part ’+ ’message in MIME format.’+#13#10+#13#10; CntPart := MessBody.AddPart(MainPart); CntPart.Headers.Add(’Content-type: text/plain’); 34

A. Z DROJOVÉ KÓDY PRO PRÁCI SE ZÁSILKAMI CntPart.Headers.Add(’Content-Transfer-Encoding:’+ ’ 7bit’); CntPart.PartBody.Text := Content; CntPart.ComposeParts; SD := CoSignedData.Create; SD.Content:=StringToAPIString(CntPart.lines.Text); StrBase64 := APIStringToString(SD.Sign(nil,true, CAPICOM_ENCODE_BASE64)); CntPart.PartBody.Text := CntPart.PartBody.Text+ #13#10; SigPart := MessBody.AddPart(MainPart); SigPart.EncodingCode := ME_BASE64; SigPart.Headers.Add( ’Content-Type: ’+’application/x-pkcs7-signature;’+ #13#10#9+’name="smime.p7s"’ + #13#10# + ’Content-Transfer-Encoding: base64’ + #13#10# + ’Content-Disposition: attachment;’+ #13#10#9+’filename="smime.p7s"’); SigPart.PartBody.Text := StrBase64; MessBody.EncodeMessage; Result := MessBody; finally SD.Free; end; end;

A.3 Zašifrování zásilky A.4 Zpracování pˇríchozí zprávy s ohledem na MIME hlaviˇcky function ConvertSMIMEtoMIME(var SMIMEMess:TMimeMess): boolean; var SD : SignedData; ED : EnvelopedData; 35

A. Z DROJOVÉ KÓDY PRO PRÁCI SE ZÁSILKAMI SmimeType,CntToVerify : string; PartMain,PartContent,PartSign : TMimePart; M : TMemoryStream; i : integer; begin Result := true; try SMIMEMess.DecomposeParts; PartMain := SMIMEMess.MessagePart; If UpperCase(PartMain.Primary)=’APPLICATION’then begin If UpperCase(PartMain.Secondary)=’X-PKCS7-MIME’ then begin SmimeType := copy(PartMain.Headers.text,Pos( ’smime-type’,PartMain.Headers.text)+11,15); if ((Pos(’"’,SmimeType) = 1)) then SmimeType := Copy(SmimeType,2, Length(SmimeType)); if ((Pos(’"’,SmimeType) > 0) and (Pos(’;’,SmimeType) > Pos(’"’,SmimeType)) and (Pos(’;’,SmimeType) > 0)) then SmimeType := LowerCase(Copy(SmimeType,0, Pos(’"’,SmimeType) -1)) else if (Pos(’;’,SmimeType) > 0) then SmimeType := LowerCase(Copy(SmimeType,0, Pos(’;’,SmimeType) -1)) else if (Pos(#13,SmimeType) > 0) then SmimeType := LowerCase(Copy(SmimeType,0, Pos(#13,SmimeType) -1)); try M := TMemoryStream.Create; if UpperCase(SmimeType) = ’ENVELOPED-DATA’ then begin ED := CoEnvelopedData.Create; ED.Decrypt(PartMain.PartBody.Text); M.Seek(0,soFromBeginning); M.Write(Pointer(ED.Content)^, length(ED.Content)*sizeof(WideChar)); 36

A. Z DROJOVÉ KÓDY PRO PRÁCI SE ZÁSILKAMI end else if UpperCase(SmimeType) = ’SIGNED_DATA’ then begin SD := CoSignedData.Create; SD.Verify(PartMain.PartBody.Text,false, CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE); M.Seek(0,soFromBeginning); M.Write(Pointer(SD.Content)^, length(SD.Content)*sizeof(WideChar)); end; M.Seek(0,soFromBeginning); PartMain.Lines.LoadFromStream(M); PartMain.DecomposeParts; Result := true; finally M.Free; end; end else if UpperCase(PartMain.Primary) = ’MULTIPART’ then begin if UpperCase(PartMain.Secondary) = ’SIGNED’ then begin PartContent := PartMain.GetSubPart(0); PartSign := PartMain.GetSubPart(1); SD := CoSignedData.Create; ContentToVerify := PartContent.Lines.Text; SetLength(CntToVerify, length(CntToVerify)-2); SD.Content := StringToAPIString(CntToVerify); SD.Verify(PartSign.PartBody.Text,true, CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE); Result := true; end; end; except on E:Exception do begin ShowMessage(E.Message); 37

A. Z DROJOVÉ KÓDY PRO PRÁCI SE ZÁSILKAMI Result := false; end; end; end;

A.5 Pomocné funkce function StringToAPIString(const Source: String): WideString; var StrStream: TStringStream; Ptr: Pointer; begin StrStream := TStringStream.Create(Source); try SetLength(Result, (StrStream.Size + 1) div 2); StrStream.Read(Result[1], StrStream.Size); Ptr := Pointer(Integer(Pointer(Result)) - 4); PInteger(Ptr)^ := StrStream.Size; finally StrStream.Free; end; end; function APIStringToString(const Source: WideString): String; var U : IUtilities; begin try U := CoUtilities.Create; Result := U.BinaryStringToByteArray(Source); finally U.Free; end; end;

38

B Zdrojové kódy pro práci s certifikáty B.1 Pˇridání pˇrijatého certifikátu do systémového úložištˇe procedure AddCertificateToStore(Part:TMimePart); var hStoreHandle,SystemStoreHandle : HCERTSTORE; MessBlob : CRYPT_INTEGER_BLOB; Mess : TMimeMess; SignedData,CertLabel : string; pSignerCert : PCCERT_CONTEXT; pszCertValue,pszHash : PChar; HashLength:DWORD; begin pSignerCert := nil; try try Part.DecodePart; SetLength(SignedData,Part.DecodedLines.Size); Part.DecodedLines.ReadBuffer( Pointer(SignedData)^, Part.DecodedLines.Size); MessBlob.cbData := Part.DecodedLines.Size; MessBlob.pbData := Pointer(SignedData); hStoreHandle := CryptGetMessageCertificates( X509_ASN_ENCODING or PKCS_7_ASN_ENCODING, 0,0,MessBlob.pbData, MessBlob.cbData ); SystemStoreHandle := CertOpenSystemStore(0,’MY’); GetMem(pszCertValue,1024); pSignerCert := CertEnumCertificatesInStore( hStoreHandle, nil); while pSignerCert <> nil do begin 39

B. Z DROJOVÉ KÓDY PRO PRÁCI S CERTIFIKÁTY try CertLabel := ’’; //Certificate is not present in system store. //lets ask the user whether to add it. CertGetNameString(pSignerCert, CERT_NAME_ATTR_TYPE, 0, PChar(szOID_COMMON_NAME), pszCertValue,20); If StrLen(pszCertValue) > 0 then CertLabel := CertLabel + ’Common name:’ + pszCertValue + #13#10; CertGetNameString(pSignerCert, CERT_NAME_ATTR_TYPE, 0, PChar(szOID_SUR_NAME), pszCertValue,20); If StrLen(pszCertValue) > 0 then CertLabel := CertLabel + ’Surname:’ + pszCertValue + #13#10; // More parameters can be read and shown // in similar way... CertGetCertificateContextProperty( pSignerCert, CERT_SHA1_HASH_PROP_ID, pszCertValue, HashLength); GetMem(pszHash,HashLength*2); BinToHex(pszCertValue,pszHash,HashLength); If StrLen(pszCertValue) > 0 then CertLabel := CertLabel + ’Hash:’ + pszHash + #13#10; ShowMessage(CertLabel); if (nil = CertFindCertificateInStore( SystemStoreHandle, X509_ASN_ENCODING or PKCS_7_ASN_ENCODING, 0, CERT_FIND_EXISTING,pSignerCert,nil)) 40

B. Z DROJOVÉ KÓDY PRO PRÁCI S CERTIFIKÁTY then begin if (CertAddCertificateContextToStore( SystemStoreHandle, pSignerCert, CERT_STORE_ADD_NEW, nil)) then begin ShowMessage(’Certificate imported’+ ’ succesfully’); end else begin case GetLastError of $80092005 : ShowMessage(’Certificate is already’+ ’ in store.’) else ShowMessage(’Error occured while ’+ ’trying to import the certificate.’); end; end; end else begin //Certificate is already stored end; except on E:Exception do ShowMessage(E.Message +#13#10+ IntToStr(GetLastError)); end; pSignerCert := CertEnumCertificatesInStore( hStoreHandle, pSignerCert); end; except on E:Exception do ShowMessage(E.Message + ’ / ’ + #13#10 + IntToStr(GetLastError)); end; finally end; end;

41

B. Z DROJOVÉ KÓDY PRO PRÁCI S CERTIFIKÁTY

B.2 Vytvoˇrení osobního certifikátu Na pˇríkazové rˇ ádce nejprve zadáme pˇríkaz pro vytvoˇrení páru klíˇcu, ˚ který bude mít platnost jeden rok a uloží se do souboru keypair.pem: openssl req -x509 -nodes -days 365 -newkey rsa:1024 \ -keyout keypair.pem -out keypair.pem A poté zkonvertujeme klíˇce do formátu, který lze importovat do systémového úložištˇe Windows: pkcs12 -export -in keypair.pem -out user.p12 \ -name "Jméno uživatele"

42

Literatura [1] Internet Mail Consortium. Actual oid list. Dokument je dostupný na URL http://www.imc.org/ietf-smime/oids.html (navštíveno 10.4.2010). [2] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard), May 2008. [3] Microsoft Corporation. Dokumentace knihovny capicom. Dokument je dostupný na URL http://msdn.microsoft.com/en-us/ library/aa375732%28VS.85%29.aspx (navštíveno 10.4.2010). [4] Microsoft Corporation. Microsoft security - what is activex control? Dokument je dostupný na URL http://www.microsoft.com/ protect/terms/activex.aspx (navštíveno 10.4.2010). [5] D. Crocker. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. RFC 822 (Standard), August 1982. Obsoleted by RFC 2822, updated by RFCs 1123, 2156, 1327, 1138, 1148. [6] University of Geneva DCIS. Openssl interface for delphi. Dokument je dostupný na URL http://www.disi.unige.it/person/ FerranteM/delphiopenssl/ (navštíveno 10.4.2010). [7] P. Deutsch and J-L. Gailly. ZLIB Compressed Data Format Specification version 3.3. RFC 1950 (Informational), May 1996. [8] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, and L. Repka. S/MIME Version 2 Message Specification. RFC 2311 (Informational), March 1998. [9] S. Dusse, P. Hoffman, B. Ramsdell, and J. Weinstein. S/MIME Version 2 Certificate Handling. RFC 2312 (Informational), March 1998. [10] Embarcadero. Embarcadero delphi. Projekt je dostupný na URL http://www.embarcadero.com/products/delphi/ (navštíveno 10.4.2010). [11] Free Software Foundation. What is copyleft? - gnu project - free software foundation (fsf). Dokument je dostupný na URL http: //www.gnu.org/copyleft/ (navštíveno 10.4.2010). 43

B. Z DROJOVÉ KÓDY PRO PRÁCI S CERTIFIKÁTY [12] Mozilla Foundation. Gecko web browser kernel. Projekt je dostupný na URL https://developer.mozilla.org/en/Gecko (navštíveno 10.4.2010). [13] N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. RFC 2049 (Draft Standard), November 1996. [14] Lukáš Gebauer. Ararat synapse. Projekt je dostupný na URL http: //synapse.ararat.cz/ (navštíveno 10.4.2010). [15] General public license. Dokument je dostupný na URL http://www. gnu.org/copyleft/gpl.html (navštíveno 10.4.2010), 2005. [16] Gnu win32 project. Projekt je dostupný na URL http://gnuwin32. sourceforge.net/ (navštíveno 10.4.2010). [17] P. Gutmann. Compressed Data Content Type for Cryptographic Message Syntax (CMS). RFC 3274 (Proposed Standard), June 2002. [18] Henrick Wibell Hellström. Streamsec tools order. Dokument je dostupný na URL http://www.streamsec.com/order_ strsectools.asp (navštíveno 10.4.2010). [19] Dr Stephen N Henson. Openssl pkcs#12 faq. Dokument je dostupný na URL http://www.drh-consultancy.demon.co.uk/ pkcs12faq.html (navštíveno 10.4.2010). [20] P. Hoffman. Enhanced Security Services for S/MIME. RFC 2634 (Proposed Standard), June 1999. Updated by RFC 5035. [21] R. Housley. Cryptographic Message Syntax. RFC 2630 (Proposed Standard), June 1999. Obsoleted by RFCs 3369, 3370. [22] R. Housley. Triple-DES and RC2 Key Wrapping. RFC 3217 (Informational), December 2001. [23] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369 (Proposed Standard), August 2002. Obsoleted by RFC 3852. [24] R. Housley. Cryptographic Message Syntax (CMS). RFC 3852 (Proposed Standard), July 2004. Obsoleted by RFC 5652, updated by RFCs 4853, 5083. 44

B. Z DROJOVÉ KÓDY PRO PRÁCI S CERTIFIKÁTY [25] R. Housley. Cryptographic Message Syntax (CMS). RFC 5652 (Draft Standard), September 2009. [26] R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 2459 (Proposed Standard), January 1999. Obsoleted by RFC 3280. [27] Jedi api library. Projekt je dostupný na URL http://jedi-apilib. sourceforge.net/ (navštíveno 10.4.2010). [28] B. Kaliski. PKCS #7: Cryptographic Message Syntax Version 1.5. RFC 2315 (Informational), March 1998. [29] RSA Laboratories. Certificate revocation list. Dokument je dostupný na URL http://www.rsa.com/glossary/default.asp? id=1106 (navštíveno 10.4.2010). [30] RSA Laboratories. Pkcs #12: Personal information exchange syntax standard. Dokument je dostupný na URL http://www.rsa.com/ rsalabs/node.asp?id=2138 (navštíveno 10.4.2010). [31] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard. Dokument je dostupný na URL http://www.rsa.com/rsalabs/ node.asp?id=2128 (navštíveno 10.4.2010). [32] National Institute of Standards and Technology. Federal information processing standards publication 197. Dokument je dostupný na URL http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf (navštíveno 10.4.2010). [33] B. Ramsdell. S/MIME Version 3 Certificate Handling. RFC 2632 (Proposed Standard), June 1999. Obsoleted by RFC 3850. [34] B. Ramsdell. S/MIME Version 3 Message Specification. RFC 2633 (Proposed Standard), June 1999. Obsoleted by RFC 3851. [35] B. Ramsdell. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. RFC 3850 (Proposed Standard), July 2004. [36] B. Ramsdell. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. RFC 3851 (Proposed Standard), July 2004. 45

B. Z DROJOVÉ KÓDY PRO PRÁCI S CERTIFIKÁTY [37] R. Rivest. A Description of the RC2(r) Encryption Algorithm. RFC 2268 (Informational), March 1998. [38] International Telecommunication Union. Recommendation x.680 (07/02). Dokument je dostupný na URL http://www.itu.int/ rec/T-REC-X.680-200207-S/en (navštíveno 10.4.2010). [39] Berkeley University of California. Original bsd license. Dokument je dostupný na URL http://www.xfree86.org/3.3.6/ COPYRIGHT2.html#6 (navštíveno 10.4.2010). ˇ [40] Pavel Cerný poˇcítaˇcové služby. ekaskada. Projekt je dostupný na URL http://www.ekaskada.cz/ (navštíveno 10.4.2010).

46

012345

Recommend Documents