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

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Rychlost kryptografických operací na mobilních telefonech BAKALÁŘSKÁ PRÁCE Martin Těhan Brno, podzim 2009

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

Poděkování Děkuji vedoucímu práce panu Ing. Mgr. Zdeňku Říhovi, Ph.D. za trpělivost a cenné rady. Dále děkuji panu Josefu Podneckému ze společnosti Telefónica O2 Czech republic, a. s. za zapůjčení mobilních telefonů. iii

Shrnutí Práce se zabývá vývojem kryptografických aplikací pro mobilní telefony. V úvodní části podává stručný přehled běžných šifrovacích a podepisovacích algoritmů a hašovacích funkcí. Následuje popis možností vývoje na mobilních telefonech a nakonec jsou zveřejněny výsledky měření rychlosti jednotlivých kryptografických operací na různých mobilních zařízeních. iv

Abstract This thesis focuses on developing cryptographic aplications on mobile phones. There is a brief sumarisation of common ciphers an hash functions in the first part. It is followed by description of software development on mobile phones. Results of cryptographic operations speed measurment are published in final part. v

Klíčová slova mobilní telefon, kryptografie, vývoj aplikací, Java ME, test výkonu vi

Obsah 1 Úvod................................... 4 2 Základní pojmy............................. 6 2.1 Hašovací funkce a autentizační kódy zpráv.......... 6 2.1.1 Jednocestná funkce.................... 6 2.2 Generování náhodných a pseudonáhodných čísel...... 7 2.2.1 Pseudonáhodná čísla................... 7 2.2.2 Generování náhodných čísel.............. 7 2.2.3 Generování pseudonáhodných čísel.......... 7 2.3 Symetrická kryptografie..................... 7 2.4 Asymetrická kryptografie.................... 8 2.5 Proudové šifry........................... 8 2.5.1 Synchronní proudové šifry............... 8 2.5.2 Asynchronní proudové šifry.............. 8 2.6 Blokové šifry............................ 9 2.7 Operační módy blokových šifer................. 9 2.7.1 Electronic Code Book (ECB)............... 9 2.7.2 Cipher-Block Chaining (CBC).............. 9 2.7.3 Cipher Feedback (CFB)................. 9 2.7.4 Output Feedback (OFB)................. 10 2.7.5 Counter (CTR)...................... 10 2.8 Zarovnání............................. 10 3 Běˇzné algoritmy............................. 11 3.1 Hašovací funkce.......................... 11 3.1.1 Algoritmy MDx...................... 11 MD4............................ 11 MD5............................ 11 MD6............................ 12 3.1.2 Algoritmy SHS...................... 12 SHA-0 a SHA-1...................... 12 SHA-2........................... 12 3.1.3 Tiger............................ 13 3.1.4 Whirlpool......................... 13 1

3.2 Symetrické blokové šifry..................... 13 3.2.1 DES............................. 13 3.2.2 TripleDES......................... 14 3.2.3 AES............................. 14 3.2.4 Blowfish.......................... 14 3.2.5 Twofish.......................... 14 3.2.6 Serpent........................... 15 3.2.7 IDEA............................ 15 3.2.8 RC6............................. 15 3.3 Symetrické proudové šifry.................... 15 3.3.1 RC4............................. 15 3.3.2 Salsa20........................... 16 3.4 Asymetrické blokové šifry.................... 16 3.4.1 RSA............................. 16 3.4.2 ElGamal.......................... 16 3.5 Podpisové algoritmy....................... 16 3.5.1 DSA............................ 16 4 Programování pro mobilní telefony................. 17 4.1 Java ME (Java Platform, Micro Edition)............ 17 4.1.1 Connection Limited Device Configuration (CLDC). 17 Mobile Information Device Profile (MIDP)...... 18 Information Module Profile (IMP)........... 18 4.1.2 Connected Device Configuration (CDC)........ 18 Foundation Profile (FP)................. 18 Personal Basis Profile (PBP)............... 19 Personal Profile (PP)................... 19 4.1.3 Security and Trust Services API for J2ME....... 19 4.2 Bouncy Castle........................... 19 4.3 Proprietární operační systém.................. 19 4.4 Symbian.............................. 20 4.4.1 Symbian Cryptographic API.............. 21 4.5 Windows.............................. 21 4.5.1.NET Compact Framework............... 21 4.6 Android.............................. 22 4.7 iphone OS............................. 22 4.8 Palm OS.............................. 22 5 Naprogramovaná aplikace...................... 24 5.1 Generování pseudonáhodných čísel.............. 25 5.2 Testování rychlosti otisků.................... 25 5.3 Testování rychlosti symetrických blokových šifer....... 25 2

5.4 Testování rychlosti symetrických proudových šifer...... 26 5.5 Testování rychlosti asymetrických blokových šifer...... 26 5.6 Testování rychlosti podepisovacích algoritmů......... 26 5.7 Generování klíčů......................... 26 6 Závěr................................... 28 A Provedená měření........................... 35 A.1 Délka vstupního textu 1024 b.................. 35 A.2 Délka vstupního textu 10240 b.................. 45 A.3 Délka vstupního textu 409600 b................. 55 A.4 Asymetrické šifry a podpisové algoritmy........... 65 A.5 Generování pseudonáhodných čísel.............. 69 A.6 Generování klíčů......................... 70 B Seznam testovaných mobilních telefonů.............. 74 C Zadání bakalářské práce........................ 75 3

Kapitola 1 Úvod Mobilní telefon se stal nedílnou součástí našich životů a v západní civilizaci ho vlastní prakticky každý člověk v produktivním věku. Skutečnost, že je jeden mobilní telefon většinou pevně svázán s jednou konkrétní osobou přímo vnucuje myšlenku, použít ho k identifikaci, či dokonce autorizaci dané osoby. K tomu je ale potřeba, aby byly splněny některé předpoklady. Jedná se zejména o dostatečnou výkonnost a možnost interakce s okolím nosného hardwaru a uživatelsky přívětivou instalaci a následné používání aplikace, která by toto zajišt ovala. Vzhledem k tomu, že výkonostní parametry současných mobilů střední třídy jsou minimálně na úrovní osobních počítačů z poloviny devadesátých let, dá se říci, že po hardwarové stránce plně dostačují. Vedle typicky telefonních protokolů a rozličných protokolů pro přenos dat v mobilní síti, dnešní telefony vesměs umožňují komunikovat i pomocí jiných bezdrátových technologií. Z tohoto pohledu je určitě nejzajímavější Bluetooth, který se používá k připojení hands-free a přenosu malých objemů dat. V této práci si kladu za cíl prozkoumat možnosti použití kryptografie na mobilních telefonech z pozice bežného programátora. Chtěl bych podat přehledný souhrn toho, co která platforma nabízí a poskytnout jasné srovnání výkonnosti jednotlivých mobilních zařízení. Práce je rozdělena do tří částí. V té první velice zběžně připomínám základní pojmy týkající se kryptografie a představuji testované algoritmy. Nesnažím se dodat matematicky přesný popis, jen krátce popisuji historii a vývoj a zaměřuji se na to, kde se daný algoritmus používá. Do testu jsem se snažil vybrat hlavně běžně používané a v praxi osvědčené algoritmy. Pokud není uvedeno jinak, informace o popisovaných algoritmech jsem čerpal z knihy Handbook of Applied Cryptography [30], kapitoly 6, 7 a 8. Druhá část pak představuje možnosti vývoje na mobilních telefonech. Kromě obecného popisu vývoje aplikací pro danou platformu jsem se snažil najít a různé knihovny a rozhraní, které mají zjednodušit použití kryptografie právě pro tento druh zařízení. Ve třetí části se pak věnuji samotné podstatě svojí práce, tj. popisu tes- 4

1. ÚVOD tovací aplikace a publikaci naměřených výsledků. Teoreticky jsem se opíral o způsob, jakým B. Schneier a D. Whiting testovali rychlost finalisty při vybírání AES [39]. Bohužel jsem neměl k dispozici zařízení, kterým bych měřil rychlost operací na počet cyklů procesoru a musel jsem se spokojit s měřením časového úseku v milisekundách. Na rozdíl od pánů Schneiera a Whitinga vždy pracuji s plnou verzí algoritmu, tj. s algoritmem s plným počtem rund a nezkoumám výsledky pro nejniˇzšší bezpečnou a nejvyšší nedostatečně bezpečnou konfiguraci. 5

Kapitola 2 Základní pojmy 2.1 Hašovací funkce a autentizační kódy zpráv 2.1.1 Jednocestná funkce Jednocestná funkce je taková funkce, jejíž vyčíslení je velmi jednoduché, ale je nemožné z výsledku funkce odvodit její vstup [26]. Ze zadaného x tedy lze snadno získat f(x), avšak výpočet inverzní funkce, to jest získání x při znalosti f(x), je sice teoreticky možný, ale prakticky velmi obtížný. Mezi funkce, které jsou v současné době používány jako jednocestné funkce, patří například následující: Násobení Součin dvou (i velmi velkých) čísel lze spočítat snadno; faktorizační algoritmy mají exponenciální složitost Rabinova funkce Lze dokázat, že zjišt ování druhé odmocniny modulo N je výpočetně ekvivalentní faktorizaci čísla N. Druhá mocnina na konečném tělese je tedy kandidátem na jednocestnou funkci. Umocňování nad konečným tělesem Výpočet diskrétního logaritmu se obecně pokládá za náročnou úlohu. Jednocestné funkce mají své využití v asymetrické kryptografii a při tvorbě hašů. Existence jednocestných funkcí nebyla matematicky ani prokázána ani vyvrácena. Hašovací funkce je jednocestná funkce, která danému vstupu přiřadí výstup pevné, v porovnání se vstupem relativně malé délky. Doporučovaná délka haše je v dnešní době alespoň 160 bitů pro běžné použití, v kritických aplikacích se doporučuje používat haše o délce kolem 256 bitů. 6

2.2 Generování náhodných a pseudonáhodných čísel 2.2.1 Pseudonáhodná čísla 2. ZÁKLADNÍ POJMY Pseudonáhodná čísla, jsou čísla generovaná deterministickým algoritmem, jejichž posloupnost je statistickými testy nerozlišitelná od posloupnosti náhodných čísel. 2.2.2 Generování náhodných čísel Generování skutečně náhodných čísel by se mělo i v deterministickém prostředí opírat o nějaký nepředvídatelný (nejlépe fyzikální) jev. Zdroje náhodných čísel můžeme rozdělit podle kvality [28]: Velmi dobré zdroje Speciální hardware od renomovaných výrobců Dobré zdroje Většina uživatelských vstupů: Rychlost úhozů na klávesnici, pohyb myší, zvukové šumy... Přijatelné zdroje Některé softwarové zdroje: Stav I/O, sít ové statistiky... Nevhodné zdroje Systémový čas, číslo procesu, doba běhu procesu... 2.2.3 Generování pseudonáhodných čísel Vzhledem k tomu, ˇze získat skutečně náhodná čísla je velmi drahá operace, v praxi se používají hlavně generátory pseudonáhodných čísel (PRNG), které z počátečního malého náhodného čísla (semínka) vygenerují posloupnost pseudonáhodných čísel. Generátor pseudonáhodných čísel je konečný stavový automat. 2.3 Symetrická kryptografie Též nazývaná Kryptografie s tajným klíčem. Příjemce i odesílatel zprávy sdílí stejný klíč, který použijí k šifrování a dešifrování zprávy. Největší nevýhodou symetrické kryptografie je velký počet klíčů. K vzájemné důvěrné komunikaci mezi M objekty je třeba (M 1)! různých klíčů. Naopak mezi přednosti patří vysoká rychlost šifrování a dešifrování. V současnosti je za dostatečnou délku klíče považováno 80 bitů, v praxi se spíše setkáváme s klíči o délce 128, 160 nebo i 256 bitů. 7

2. ZÁKLADNÍ POJMY 2.4 Asymetrická kryptografie Asymetrická kryptografie, neboli Kryptografie s veřejným klíčem předpokládá použití dvou klíčů, veřejného a soukromého. Zatímco soukromý klíč je uchováván v tajnosti, veřejný je rozdistribuován mezi potencionální komunikanty. Pokud objekt A (Alice) chce komunikovat s objektem B (Bob), zašifruje zprávu Bobovým veřejným klíčem a pošle ji Bobovi. Ten k dešifrování použije svůj privátní klíč. Z toho je patrné, že oba klíče musí mít nějakou společnou vlastnost, že spolu musí být nějak spojeny. Tohoto spojení se dosahuje právě za použití jednocestných funkcí. 2.5 Proudové šifry Občas nazývané stavové šifry, nebot výstup nezávisí pouze na vstupu a klíči, ale i vnitřím stavu. Častěji jsou implementovány jako symetrické šifry, i když existují i proudové šifry s veřejným klíčem, například Blum-Goldwasserovo schéma. Proudové šifry, jak již název napovídá, zpracovávají plynulý tok dat a to bud po bytech nebo bitech. Na rozdíl od blokových šifer nepotřebují buffer a jejich hardwarová implementace je obecně rychlejší. Dělíme je na synchronní a asynchronní. 2.5.1 Synchronní proudové šifry Synchronními jsou nazývány ty šifry, u kterých je klíč expandován nezávisle na šifrovaném respektive dešifrovaném textu. Tento postup má samozřjmě své výhody i nevýhody. Příjemce a odesílatel musí být vzájemně synchronizováni. Jakákoliv ztráta (nebo vložení) dat během přenosu tuto synchronizaci naruší a znemožní pokračovat bez opětovné resynchronizace. Naproti tomu pokud dojde pouze ke změně, nikoliv ztrátě dat, tato chyba se projeví pouze v příslušném bloku a nepropaguje se dále. 2.5.2 Asynchronní proudové šifry Asynchronní, někdy též samosynchronizační šifry používají k vytvoření keystreamu nejen klíč, ale i pevně stanovenou část již zpracovaného textu. Tyto šifry jsou schopny automaticky obnovit synchronizaci při ztrátě či vložení dat, přijemce příjde pouze o určitý počet znaků. Záměna znaků bez změny délky přenesených dat se ale na rozdíl od synchronních šifer zpropaguje právě v celé části, kde je poškozený zašifrovaný text potřebný k vytvoření keystreamu. 8

2. ZÁKLADNÍ POJMY 2.6 Blokové šifry Tyto šifry zpracovávají data v poměrně velkých blocích, l 64bity. Striktně pojatá bloková šifra je bezstavová, což znamená, že každý blok dat je šifrován/dešifrován pouze na základě klíče. Při tomto pojetí a větších objemech šifrovaných dat je možné provést úspěšný útok založený na frekvenční analýze, nebot stejný blok dat zašifrovaný stejným klíčem jednoduše vyústí ve stejný zašifrovaný blok. Z tohoto důvodu byly vyvinuty tzv. Operační módy blokových šifer, které do zpracování zanáší závislost na předchozím textu a tím přibližují blokové šifry šifrám proudovým. 2.7 Operační módy blokových šifer Operační módy popisují jakým způsobem, a jestli vůbec, jsou jednotlivé bloky řetězeny a jakým způsobem závisí zpracování daného bloku na výsledku zpracování předchozích bloků [13]. Následující módy patří k těm nejvíce používaným. 2.7.1 Electronic Code Book (ECB) Základní mód, který zpracovává každý blok vstupního textu nezávisle na ostatních. Proto je vhodný pouze pro texty v délce několika málo bloků, ideálně pouze jednoho. Záměna bitů při přenosu se projeví pouze v daném bloku. 2.7.2 Cipher-Block Chaining (CBC) Přidává závislost právě šifrovaného bloku na bloku předchozím. Správné dešifrování bloku c j je podmíněno správným dešifrováním bloku c (j 1). Předpokládá použití inicializačního vektoru (IV), který nemusí být tajný. Tento operační mód je samosynchronizující ve smyslu záměny bitů, či ztráty celých bloků. Zotavení při smazání nebo přidání jednotlivých bitů je nad možnosti tohoto módu. Řetězení také umožňuje pouze sekvenční zápis a čtení. 2.7.3 Cipher Feedback (CFB) Používá lineární posuvný registr, což umožňuje zpracování po blocích velikosti r < n, kde n je délka bloku symetrické šifry. Odolnost proti chybám je na obdobné úrovni jako u CBC, s tím rozdílem, že ke zotavení je třeba 9

2. ZÁKLADNÍ POJMY n/r bloků. CFB mód je nevhodný k použití s blokovými šiframi s veřejným klíčem, místo něj je třeba použít CBC. 2.7.4 Output Feedback (OFB) Podobá se CFB s tím rozdílem, že klíčový materiál je naprosto nezávislý na vstupním textu. Toto uspořádání má i své další výhody, například umožňuje předvypočítání klíčového materiálu z klíče a inicializačního vektoru před samotným přenosem zprávy, což ve svém důsledku poskytuje schopnost paralelního zpracování při přenosu. Další předností je vpodstatě nulová propagace chyb. Záměna bitu v zašifrovaném textu ovlivní pouze bit na odpovídající pozici otevřeného texu. Ovšem ani tento mód neposkytuje nástroje na zotavení při ztrátě bitů při přenosu. OFB je definován ve dvou variantách. Starší, popsaná ve [21] používá feedback r < n stejně jako CFB, novější a bezpečnější, definovaná jako ISO [24] už pracuje pouze s n- bitovými bloky. 2.7.5 Counter (CTR) Tento mód má spoustu shodných rysů s OFB. Hlavní rozdíl oproti OFB spočívá ve vytváření klíčového materiálů. Zatímco v OFB se následující bloky tvoří za pomoci předchozích, u CTR se ke stejnému účelu používá počítadlo (odtud název Counter). Tento mód samozřejmě poskytuje vyšší rychlost zpracování, na druhou stranu je mnohem náročnější na správu klíčů a počítadla. Stejné hodnoty počítadla nesmí být použity nejen v rámci zprávy, ale vždy pro stejný klíč. Odolnost proti chybám je totožná jako u OFB. 2.8 Zarovnání I v češtině běžně označované termínem padding a v dalším textu budu používat právě tento výraz. Padding se používá hned z několika důvodů. Zaprvé kvůli doplnění různě dlouhých vstupních dat na délku bloku (násobek délky bloku) při zpracování blokovými šiframi. Dále se padding používá, pokud chceme přidat nějakou náhodnou informaci do předvídatelného textu. Zde se termín padding používá z historických důvodů, původně se pouze ke zprávě připojilo náhodné číslo. Současná schémata používají sofistikovanějších metod. Používání paddingu také případnému útočníkovi ztěžuje analýzu provozu [31]. 10

Kapitola 3 Běˇzné algoritmy 3.1 Hašovací funkce 3.1.1 Algoritmy MDx Rodina algoritmů, za níž stojí Ronald Rivest. Název je zkratkou slov Message Digest a pořadového čísla. MD4 Publikován v říjnu 1990 [35]. Délka výsledného otisku je 128 bitů. MD4 se stal základním kamenem a vzorem pro další funkce, jako například MD5 a SHA. Již v roce 1991 byly popsány první chyby v návrhu [9]. Hans Dobbertin v roce 1996 zveřejnil první útok založený na nalezení kolizí [10] a v roce 2004 skupina vedená Xiaoyun Wang publikovala velmi rychlý způsob nalezení kolize [44]. Poslední ranou pro MD4 bylo zveřejnění postupu, který umožňuje nalezení kolizních záznamů s časovou složitostí srovnatelnou se samotným hašováním. MD5 Jeden z nejznámějších a nejrozšířenějších hašovacích algoritmů. Byl publikován v roce 1991 [36]. V roce 1994 B. den Boer and A. Bosselaers objevili postup nalezení pseudokolizí. V březnu 2005 byl zveřejněn úspěšný analytický útok na hašovací funkci [27]. Přestože se v současnosti dají na běžném PC najít kolize za méně než minutu [25], je MD5 stále populární a používá se ke kontrole integrity dat. V minulosti se běžně využívala pro vytváření otisků hesel a v SSL certifikátech. Z neomezeného vstupu vytváří otisky o délce 128 bitů. 11

3. BĚŽNÉ ALGORITMY MD6 Poslední hašovací funkce z dílny Ronalda Rivesta, vydaná v roce 2008 [37]. Na rozdíl od předchozích generací MDx je vstup omezen na 2 64 1 bitů, výstupy pak mohou být libovolné délky v intervalu 1 až 512 bitů. Původně byla přihlášena do výběrového řízení na SHA-3. MD6 však byla z tohoto řízení jejími tvůrci stažena, posléze sice bylo toto stažení dementováno, ale MD6 stejně do dalšího kola nepostoupila. Do výběrového řízení totiž nebyla přihlášena původní funkce, ale funkce se sníženým počtem rund, která měla zajistit rychlejší zpracování. Autorům se nepovedlo podat důkaz bezpečnosti a proto oznámili, že MD6 nesplňuje interní požadavky. 3.1.2 Algoritmy SHS SHS (Secure Hash Standard) jsou definovány Americkým standarded [16]. SHA-0, SHA-1 a SHA-2 byly vytvořeny vládní agenturou NSA. O implementaci SHA-3 právě probíhá otevřená soutěž, což je postup, který se osvědčil u hledání nové symetrické šifry pro AES. Do druhého kola postoupilo čtrnáct algoritmů. V současné době probíhá veřejná diskuze. Vítěz bude pravděpodobně vyhlášen v srpnu 2010. SHA-0 a SHA-1 První specifikace algoritmu, známá jako SHA-0 byla vydána v roce 1993, byla však vzápětí stažena a nahrazena specifikaci [15] označovanou jako SHA-1. Algoritmy se od sebe liší pouze přidáním bitového posunu v kompresní funkci. SHA-1 se svým návrhem podobá algoritmům MD4 a MD5. Na rozdíl od nich produkuje 160 bitový haš a délka vstupu je omezena na 2 64. Algoritmus SHA-1 nebyl ještě plně kompromitován, přestože existují útoky, které dokáží odhalit kolizi rychleji, než hrubou silou. Nejlepším dosavadním výsledkem je 2 52 operací [29] (útok hrubou sílou s využitím narozeninového paradoxu má složitost 2 80 ). NIST vydala prohlášení, ve kterém nařizuje plný přechod federálních amerických institucí na SHA-2 do konce roku 2010. SHA-1 se používá v PGP, SSH, SSL a IPsec, dále pak v DSS (který přechází na SHA-2) a také nahradila MD5 při vytváření a ukládání otisků hesel v jednoduchých webových aplikacích. SHA-2 SHA-2 je souhrnné označení pro čtveřici algoritmů SHA-224, SHA-256, SHA- 384 a SHA-512. Tyto algoritmy byly publikovány ve FIPS PUB 180-2 [16] 12

3. BĚŽNÉ ALGORITMY v roce 2001. Původní návrh počítal pouze s posledními třemi, SHA-224 byl doplněn později. Konstrukčně vycházejí ze svého předchůdce, přesto zatím nebyl oznámen žádný výrazně úspěšný útok. Produkují haše o délkach 224, 256, 384 a 512 bitů. Délka vstupu je omezena na 2 64 bitů u SHA-224 / SHA- 256, respektive na 2 128 u SHA-384 / SHA-512. Postupně nahrazuje SHA-1. 3.1.3 Tiger Tato hašovácí funkce byla navržena v roce 1995 Rossem Andersonem a Eli Bihamem [5]. Výsledný řetězec má délku 192 bitů. Zatím nebyl nalezen žádný úspěšný útok. Své využití nalezl hlavně v P2P sítích. Tiger existuje i ve verzi Tiger2, která se od svého předchůdce liší pouze implementováním jiného paddingu (stejného jako používají algoritmy SHA). 3.1.4 Whirlpool Autorem je Vincent Rijmen. Hašovací funkce Whirlpool vychází z blokové šifry Rijndael (pozdější AES) [33]. Byla publikována v roce 2000 a od té doby prošla dvěma revizemi, tou poslední v roce 2003. Na vstupu očekává řetězec o maximální délce 2 256. Finální haš má délku 512 bitů. Tato funkce byla přijata za mezinárodní standard ISO/IEC 10118-3. 3.2 Symetrické blokové šifry 3.2.1 DES Celým názvem Data Encryption Standard, při odkazování přímo na použitý algoritmus se používá zkratka DEA (Data Encryption Algoritmus). Jedna z nejznámějších a nejrozšířenějších symetrických šifer. Počátky vývoje sahají až do první poloviny sedmdesátých let. Byl navržen firmou IBM na základě předchozích algoritmů označovaných jako Lucifer. Algoritmus operuje s 64bitovými bloky a 56 bity celkem 64bitového klíče (zbylých 8 bitů není algoritmem využito a většinou slouží k paritní kontrole). Finální verze byla zveřejněna v roce 1977 a přijata jako americký standard [19]. Tento standard byl několikrát revidován a potvrzován, naposledy v roce 1999 [20]. Nakonec byl stažen v roce 2005 po uvedení AES. Na DEA není znám žádný úspěsný analytický útok, standard byl stažen, protože délka klíče 56 bitů neposkytuje dostatečnou ochranu před útokem hrubou silou. 13

3. BĚŽNÉ ALGORITMY 3.2.2 TripleDES Jak již název napovídá TripleDES vychází z DES a jeho popis je připojen k poslední revizi DES [20]. TripleDES je definován jako složená funkce následujícím způsobem: C = E k3 (D k2 (E k1 (P ))), kde P je otevřený blok dat, C zašifrovaný blok, E, D po pořádku šifrovací, dešifrovací funkce DES a k1 až k3 příslušné klíče. Rozeznáváme dva hlavní způsoby zvolení klíčů: 1. Všechny tři klíče jsou na sobě nezávislé 2. První a druhý klíč jsou vzájemně různé, třetí klíč je shodný s prvním 3. Specifikace pamatuje i na případ, kdy jsou všechny tři klíče shodné Takto upravený DEA sice poskytuje bezpečnost ekvivalentní 112 či 168 bitům klíče, ovšem za cenu ztrojnásobení výpočetní doby algoritmu. 3.2.3 AES American Encryption Standard. Vzešel ze soutěže o nový americký standard vyhlášené v roce 1996. Vítěz byl oznámen v listopadu 2001 [18] a stal se jím algoritmus Rijndael vytvořený dvojicí Vincent Rijmen, Joan Daemen. Pro účely AES byly vybrány algoritmy pracující s délkou klíče 128, 192 a 256 bitů. Každý z nich operuje se 128bitovými bloky. 3.2.4 Blowfish Navržen Brucem Schneierem v roce 1993 [40]. Jako jeden z prvních kryptografických materiálů Blowfish nebyl nikdy patentován, ale byl poskytnut k volnému použití. Dodnes nebyla odhalena žádná slabina algoritmu s plným počtem rund. Blowfish pracuje se 64 nebo 128bitovými bloky a umožňuje použít klíče o délkách 32 až 448 bitů (pouze čísla dělitelná osmi). V základním nastavení předpokládá 128 bitový klíč. 3.2.5 Twofish Algoritmus Twofish je následovníkem algoritmu Blowfish a jeden z finalistů soutěže o americký standard AES [38]. Stejně jako jeho předchůdce nebyl nikdy patentován. I z tohoto důvodu se stal jedním z mála algoritmů standardizovaných pro použití v OpenPGP. Používá bloky mající délku 128 bitů. Klíče mohou být v rozsahu od 128 do 256 bitů. 14

3. BĚŽNÉ ALGORITMY 3.2.6 Serpent Skončil druhý v soutěži o AES. V roce 1998 ho publikoval tým kolem Eli Bihama a Rose Andersona (mimo jíné autoři hašovací funkce Tiger) [1]. Algoritmus je volně dostupný pod GPL. Povolené délky klíčů 128, 196 a 256 bitů jsou spolu se vstupním textem zpracovávany ve 128bitových blocích. 3.2.7 IDEA Nezkrácený název zní International Data Encryption Algorithm. Algoritmus byl navržen v roce 1991 pány Jamesem Masseyem a Xuejia Lai [22]. Na rozdíl od předchozích je patentovaný, ale pro nekomerční využití je poskytován zdarma. Uplatňuje se hlavně v PGP v2 a je též jedním z volitelných algoritmů pro OpenPGP. Šifrování probíhá po 64bitových blocích za použití 128bitového klíče. 3.2.8 RC6 Algoritmus byl v roce 1998 navržen speciálně pro soutěž o AES [34]. Vychází ze svého předchůdce RC5, ale má zvětšený blok na 128 bitů a registry optimalizované k použití na 32bitové architektuře. Možné délky klíčů 128, 196 a 256 bitů také odpovídají zadání soutěže. RC6 je patentován společností RSA Security Inc. 3.3 Symetrické proudové šifry 3.3.1 RC4 Nejznámější a velmi často používaná proudová šifra, která vznikla už v roce 1987 v RSA Security Inc. Oficiální kód šifry je stále obchodním tajemstvím, ale po úniku informací o implementaci v roce 1994 1 se jí podařilo zrekonstruovat. Tato verze se většinou nazývá ARC4 nebo ARCFOUR. Klíč může být 8 až 4096 bitů, v praxi se setkáváme s délkami jako u symetrických blokových šifer tj. mezi 64 a 256 bity. RC4 je použitá v řadě významných protokolů, mezi nimiˇz vynikají SSL, WEP, WPA či BitTorrent protocol. 1. Článek Thank you Bob Anderson. Cypherpunks mailing list. 1994. http:// cypherpunks.venona.com/date/1994/09/msg00304.html. 15

3. BĚŽNÉ ALGORITMY 3.3.2 Salsa20 Autorem je Daniel J. Bernstein [4]. Šifru přihlásil v roce 2005 do projektu estream [14]. O kvalitách tohoto algoritmu svědčí, že se probojoval do nejužšího finále. Preferovaná délka klíče je 256 bitů, další podporovaná je 128 bitů. 3.4 Asymetrické blokové šifry 3.4.1 RSA RSA je pojmenován po svých tvůrcích R. Rivestovi, A. Shamirovi a L. Adlemanovi, kteří tento algoritmus navrhli v roce 1977. Podobný algoritmus popsal již v roce 1973 Clifford Cocks pracující pro Britskou tajnou službu. Jeho práce se však neujala a vzhledem k tomu, že byla odtajněna až v roce 1997 je jasné, ˇze Rivest, Shamir a Adleman navrhli RSA zcela nezávisle na Cocksovi. Jedná se o první široce používaný algoritmus pro asymetrickou kryptografii a zároveň první, který lze použít současně pro šifrování a podepisování. Bezpečnost algoritmu spočívá ve faktorizaci velkých čísel. Vzhledem k tomu, že se jedná o deterministický algoritmus, je RSA náchylný k útokům se známým otevřeným textem. Tomu se dá snadno zabránit použitím vhodného paddingu na bázi náhodných čísel. 3.4.2 ElGamal Spatřil světlo světa v roce 1985. Jeho autorem je Taher Elgamal. Bezpečnost závisí na problému výpočtu diskrétního logaritmu nad cyklickou grupou. Jeho hlavní nevýhodou je, že šifrovaná data jsou dvakrát delší, než data nezašifrovaná. Ze stejných důvodů jako u RSA se i u algoritmu ElGamal doporučuje doplňovat schéma alespoň vhodným paddingem. 3.5 Podpisové algoritmy 3.5.1 DSA Navtržen v roce 1991 americkým Národním institutem pro standardy a technologie (NIST). O dva roky později se stal základem pro Digital Signature Standard (DSS) [17]. DSA vyžaduje použití nějaké hašovací funkce. Původní návrh DSS trval na použití SHA-1, poslední revize připouští i použití SHA-2. DSA je speciálním případem Elgamalova podpisového schématu. 16

Kapitola 4 Programování pro mobilní telefony Vzhledem k tomu, že mobilní telefon je poměrně široký pojem, nejde pronášet nějaké kategorické a generalizující výroky, co lze a co ne. Nejjednoduší způsob, jak mobilní telefony alespoň částečně kategorizovat, je podle použitého operačního systému. Ten totiž tvoří základní programátorskou platformu a od něj se odvíjí možnosti daného zařízení. Před popisem řešení pro jednotlivé operační systémy se budu věnovat univerzální platformě Java ME a pro ni napsaným knihovnám. 4.1 Java ME (Java Platform, Micro Edition) Java ME 1 je platforma pro vývoj aplikací na mobilních zařízeních a jedna ze tří základních Javovských platforem (spolu s Javou SE a Javou EE). Jedná se o kolekci technologií a specifikací pro mobilní zařízení, které mohou být vzájemně kombinovány tak, aby poskytly základ pro vývoj aplikací na míru hardwarovým omezením konkrétního zařízení. Podle rychlosti CPU, množství operační paměti a podle možností připojení rozlišujeme dvě bázové konfigurace, každou z nich může rozšiřovat jeden nebo více profilů. Základní syntaxe jazyka Java je stejná jako ve všech ostatních edicích. V současné době je Java ME podporována drtivou většinou mobilních zařízení a to bud přímo, jako je tomu u většiny proprietárních systémů a Symbianu, nebo pomocí virtuálního stroje dodaného třetí stranou, například pro Windows Mobile 2. 4.1.1 Connection Limited Device Configuration (CLDC) Konfigurace, která je vhodná pro mobilní telefony a PDA s malou operační pamětí [8]. Vyžaduje 160 kb ROM a 32 kb RAM. Není pevně svázána s žádným virtuálním strojem, nicméně podle referenčí implementace od SUN 1. http://java.sun.com/javame/index.jsp 2. Srovnávací tabulka je dostupná na http://www.comp.lancs.ac.uk/$\ sim$fittond/ppcjava.html. (Vydáno 2003) 17

4. PROGRAMOVÁNÍ PRO MOBILNÍ TELEFONY nazvané KVM (Kilobyte Virtual Machine) musí být podporovány následující balíky: java.io poskytuje vstupní a výstupní datové proudy java.lang poskytuje třídy nutné pro návrh v programovacím jazyce Java java.util obsahuje framework kolekcí, nástroje pro usnadnění práce s datem a časem, a další různorodé nástroje javax.microedition.io třídy pro správu všeobecného spojení V současné době se používá CLDC verze 1.1 (JSR 139), která oproti předchozí verzi 1.0 (JSR 30) přidává podporu aritmetiky s desetinnou čárkou a podporu zařízení s většími zdroji. CLDC neobsahuje definici uživatelského rozhraní (klávesnice, display), to je záležitostí profilů. Ke konfiguraci CLDC se vážou následující: Mobile Information Device Profile (MIDP) Nejrozšířenější profil pro použití s CLDC. Právě ten je implementován v mobilních telefonech a jednodušších PDA. K CLDC přidává hlavně podporu klávesnice a displayů. Aktuální verze je 2.0 (JSR 118), předchozí 1.0 (JSR 37). Information Module Profile (IMP) Modul pro použití na zařízeních bez displaye. Implementuje totéž, co MIDP, kromě tříd zabývajících se výstupním rozhraním. 4.1.2 Connected Device Configuration (CDC) Tato konfigurace je vhodná pro mobilní zařízení disponující relativně vysokým výkonem [7]. Předpokládá se 32bitový procesor a využitelných 2 MB RAM a 2,5 MB ROM. Aktuální verzí je CDC 1.1.2 (JSR 218), které navazuje na CDC 1.0.2 (JSR 36) Foundation Profile (FP) Základní profil bez podpory grafického rozhraní. Implementuje balíky java.io, java.lang, java.math, java.util a java.security na úrovni Javy SE ve verzi 1.4.2. Současná verze je 1.1.2 (JSR 219). 18

4. PROGRAMOVÁNÍ PRO MOBILNÍ TELEFONY Personal Basis Profile (PBP) Přidává podporu jednoduchého grafického rozhraní, java beanů a RMI. Současná verze je 1.1.2 (JSR 217). Personal Profile (PP) Oproti PBP obsahuje pouze rozšířenou podporů grafického rozhraní, včetně kompletního rozhraní Java 2D. Současná verze je 1.1 (JSR 216). 4.1.3 Security and Trust Services API for J2ME Volitelné API (JSR 177), které rozšiřuje Javu ME o podporu bezpečnostních prvků a poskytuje rozhraní pro správu digitálních podpisů a implementaci kryptografických operací. Dále poskytuje podporu pro JavaCards. Jádrem API jsou balíky java.security a javax.crypto obsahující třídu Cipher, která se stará o samotné šifrování / dešifrování. Vzhledem k tomu, že se jedná o volitelnou součást, není možné se plně spolehnout na to, že bude vždy dostupná. 4.2 Bouncy Castle Nejrozšířenější kryptografická knihovna, která je dostupná v jazycích Java a C# [6]. Poskytuje implementace všech běžných kryptografických algoritmů a několika protokolů (openpgp a x509 nevyjímaje). Javová implementace se skládá ze dvou hlavních částí, JCE poskytovatele a odlehčeného API, které je použitelné na jakékoliv Javové platformě. Právě odlehčené API může být s úspěchem využito i při programování aplikací pro mobilní telefony. Nejen, ˇze zpřístupňuje celý balík org.bouncycastle.*, ale hlavně přidává do Javy ME některé třídy balíku java.util a java.math, které jsou běžné na vyšších platformách, ale do specifikace Java ME se nedostaly. V tomto směru je největším přínosem knihovny Bouncy Castle implementace třídy BigInteger pro velká celá čísla. 4.3 Proprietární operační systém Uzavřený operační systém bez možnosti vývoje aplikací třetími stranami. Tyto operační systémy jsou psány na míru danému zařízení (maximálně rodině zařízení) bez možnosti přenosu na jiný hardware. Kolem roku 2000 se začíná objevovat integrovaná podpora pro různé technologie, které by 19

4. PROGRAMOVÁNÍ PRO MOBILNÍ TELEFONY umožňovaly instalaci vlastního softwaru, hlavně her. V té době si získaly největší popularitu Mophun, In-Fusio, N-Gage a výše zmíněná Java ME. Zatímco Java ME je dnes dostupná prakticky na každém zařízení, ty zbývající jsou vpodstatě mrtvé. In-Fusio bylo spjaté s firmou Philips a po jejím ústupu ze segmentu mobilních telefonů In-Fusio koupila společnost Zenops. V dnešní době nemá ani funkční webové stránky. Naproti tomu největším propagátorem technologie Mophun, jejímž autorem je Antony Hartley, byl velmi silný hráč na trhu, konsorcium Sony Ericsson. Aplikace jsou psány v jazyce C/C++ za využití speciálního, i když volně dostupného, SDK. Neúspěch Mophunu prvděpodobně zavinila licenční politika, která umožňovala provozovat pouze certifikované aplikace. Obdobný přístup Applu při distribuci aplikací pro iphone paradoxně patří k nejúspěšnějším projektům poslední doby. N-Gage je herní platforma od Nokie. V současné době již není implementována do nových modelů a Nokia oznámila, že do konce roku 2010 pro N-Gage ukončí veškerou podporu. Přestože výše zmíněné platformy díky použitému programovacímu jazyku a běhovému prostředí nevylučují možnost práce s kryptografickými primitivy, vˇzdy byly profilovány jen jako herní řešení a nenašel jsem žádné ucelené projekty, at už v podobě nějakých knihoven, tříd nebo API, které by se kryptografii na těchto platformách věnovaly. 4.4 Symbian Operační systém 3 [42], který byl od konce osmdesátých let vyvíjen společností Psion pod jménem EPOC. V červnu 1998 do Psionu vstupují výrobci mobilů Nokia, Motorola a Ericsson a dochází k přejmenování OS na Symbian. Postupným vývojem se od sebe oddělilo několik platforem, z nichž každá poskytuje vlastní SDK a vzájemně nejsou plně kompatibilní. Mezi nejznámější patří UIQ a S60. Nativním jazykem pro vývoj aplikací na Symbianu je velmi speciální dialekt C++. Tento dialekt je poplatně době svého vzniku položen velmi nízkoúrovňově, což se z dnešního hlediska jeví jako prográmátorsky nepřívětivé. Mezi další podporované jazyky lze zařadit Javu ME, Python,.NET a standardní C/C++. 3. http://www.symbian.org 20

4.4.1 Symbian Cryptographic API 4. PROGRAMOVÁNÍ PRO MOBILNÍ TELEFONY Toto API [43] poskytuje zakladní kryptografické služby pro využití skrze základní rozhraní Symbian OS. Je rozděleno do několika základních oblastí: symetrické šifrování AES, DES, 3DES, ARC4 asymetrické šifrování RSA podle PKCS#1.5 kontrola integrity a ověřování podpisů DSA výměna klíčů Diffie-Hellman otisky zpráv Podporuje pouze základní blokové módy ECB a CBC, paddingy můžeme vybírat mezi standadry PKCS#1 v1.5 pro šifrování a pro podepisování, PKCS#7/TLS, nebo SSLv3/TLS. Počet implementovaných algoritmů je poměrně omezený, nicméně je schopen uspokojit většinu požadavků. 4.5 Windows Microsoft dodává vlastní operační systém pro chytré mobilní telefony, založený na Windows CE. Původně se jmenoval Pocket PC, od roku 2003 je vydáván pod názvem Windows Mobile 4. Rozlišují se tři hlavní verze: pro Pocket PC bez mobilního telefonu, pro Pocket PC s MT a pro smartphone). Smartphone podle Microsoftu znamená mobilní telefon s otevřeným OS bez dotykové obrazovkz. Vývoj aplikací v C++ je umožněn pomocí SDK, které spolupracuje s MS Visual Studiem. V poslední době je umožněn i vývoj za pomoci nástrojů třetích stran, které využívají možností.net Compact Frameworku. Nativní podpora Javy chybí, nicméně existuje několik různých virtuálních strojů, které lze na Windows Mobile nainstalovat. 4.5.1.NET Compact Framework Odlehčená verze.net Frameworku navrˇzená specialně pro běh na mobilních zařízeních a set-top boxech [11]. Podporuje téměř totéž, co plnohodnotný.net Framework s několika malými omezeními [12]. 4. http://www.microsoft.com/cze/windowsmobile/ 21

4. PROGRAMOVÁNÍ PRO MOBILNÍ TELEFONY 4.6 Android Android 5 je platforma pro mobilní zaříezení obsahukjící operační systém a základní aplikace [2]. Byl představen firmou Google v roce 2007. V současné době se o vývoj a udžování Androidu stará sdružení firem zvané Open Handset Alliance (OHA). Operační systém Androidu je založen na Linuxu, vývoj aplikací probíhá v jazyce Java. Android k tomuto účelu poskytuje vlastní SDK. Podobně jako na platformě Java ME, kde aplikační třídy musí být potomky třídy MIDlet (pro CLDC), nebo Xlet (pro CDC), na Androidu k podobnému účelu slouží třída Activity, která se stará o životní cyklus aplikace. Na rozdíl od MIDletů, aplikace nemusí dědit třídu Activity povinně, ovšem naprostá většina z nich to dělá. SDK pro Android obsahuje vlastní třídy pro uživatelské rozhaní a komunikaci. Vývoj kryptografických aplikací pro tuto platformu je podpořen standardními Javovými balíky java.security a javax.crypto [3]. V tomto ohledu se tvorba aplikací neliší od vývoje nad Javou SE. S úspěchem lze využít i javových kryptografických knihoven dodaných třetí stranou, jako například již popisovanou knihovnu BouncyCastle. 4.7 iphone OS Operační systém firmy Apple odvozený od OS X, který je použit v Apple iphone 6 a Apple ipod Touch [23]. Až do začátku roku 2008 iphone OS nepodporoval aplikace třetích stran. V březnu 2008 vyšlo první SDK, které vývoj umožňovalo. I tak zůstává vydávání aplikací pro iphone OS svázáno striktní politikou Applu. Aplikace jsou psány v jazyce Objective- C. To umožňuje použití standardních knihoven pro C. Na rozdíl od jiných otevřených platforem iphone OS nepodporuje aplikace napsané v žádném jiném jazyce, dokonce ani animace ve Flashi. V létě 2008 SUN s velkou slávou oznámil, že v brzké době dodá JVM pro iphone. Vše ale utichlo a ani po roce a půl žádné JVM vydané není [41]. 4.8 Palm OS Navržený společností Palm v roce 1996 pro PDA [32]. Chvíli byl dostupný pod obchodním názvem Garnet OS. Nejnovější verze pochází z roku 2004 a jmenuje se Palm OS Cobalt. V současné době se Palm zabývá vývojem 5. http://www.android.com/ 6. http://www.apple.com/iphone/ 22

4. PROGRAMOVÁNÍ PRO MOBILNÍ TELEFONY nového operačního systému založeného na Linuxu jménem webos 7. Aplikace pro původní Palm OS byly psány v jazyce C/C++. Některá IDE umožňují vývoj aplikací pro Palm OS v Pascalu. Původně existoval i javovský virtuální stroj pro tuto platformu, na začátku roku 2008 byla jeho podpora ukončena. 7. http://palmwebos.org/ 23

Kapitola 5 Naprogramovaná aplikace Aplikace je napsána v jazyce Java pro platformu Java ME a má formu jednoduchého midletu, který provede příslušné testy a jejich výsledky vypíše na obrazovku. Použitá konfigurace CLDC 1.0 společně s profilem MIDP 2.0 zajišt uje širokou podporu mobilních zařízení a jednoduchý vývoj. O kryptografické operace se stará knihovna Bouncy Caste s pořadovým číslem 1.43 v odlehčené verzi pro mobilní Javu. T630 jako jediný v testu nepodporuje profil MIDP ve verzi 2.0, proto pro něj byla aplikace sestavena za použití profilu MIDP 1.0. Kvůli jedoušší manipulaci na pomalejších mobilních telefonech jsem vytvořil i několik shodných podaplikací, které se liší pouze parametrem délky vstupního textu. Doba běhu samozřejmě závisí na použitém hardwaru a pohybuje se mezi dvěma až třiceti hodinami. Jádro aplikace tvoří testovací metody, které měří délku trvání jednotlivých operací. Hlavními testovanými okruhy jsou symetrické blokové i proudové šifry, asymetrické šifry, generování pseudonáhodných čísel, podepisování, hašovací funkce a generování klíčů. Testy symetrických šifer a hašovacích algoritmů probíhají ve více kolech na vstupních datech o různých velikostech. Zvoleny byly vstupy o délce 1 KB, 10 KB a 400 KB. Horní hranice 400 KB byla vybrána s ohledem na běžnou velikost mobilních aplikací. Kontrola integrity či ověření podpisu staˇzené aplikace jsou v praxi poměrně časté případy použití kryptografických operací nad takto velkými daty. Větší vstupy už vzhledem k omezené velikosti operační paměti nemá smysl zkoušet. Stejně tak si lze jen těžko představit reálnou situaci, při které by bylo nutné kryptograficky zpracovávat větší objem dat na mobilním zařízení. Pro zajištění objektivity se všechny testy, při kterých se pracuje s klíči nebo jinými vstupními daty opakovány s deseti různými klíči a výsledný čas je součtem časů všech pokusů. Čas je měřen pouze na skutečně testované operaci, tj. až po načtení všech potřebných dat do paměti, vygenerování klíčů a inicializace šifrovací funkce (pokud právě toto není součástí testu). Pokud daný test probíhá vícekrát s jedněmi daty, je do celkového času zahrnuta i režie cyklu. Tu však můžeme zanedbat. 24

5. NAPROGRAMOVANÁ APLIKACE Všechny výsledné časy jsou udávány v milisekundách. Bohužel ne každé zařízení vrací systémový čas opravdu přesně. Často se setkáváme s přesností sotva na desítky milisekund, což samozřejmě nepříznivě ovlivňuje přesnost měření. Pokud daná třída neumožňuje vygenerování všech parametrů šifry či podpisového algoritmu náhodně a žádá zadání inicializačních dat, jsou pouˇzity hodnoty z testovacích tříd balíku org.bouncycaste.crypto.test. Výjimku z popsaného tvoří asymetrické šifry a podpisové algoritmy. Z ú- sporných důvodů se pro ně generuje pouze jeden pár klíčů. Opětovné generování by bylo časově neúnosné a neúměrně by protáhlo samotné testování. 5.1 Generování pseudonáhodných čísel Měří se čas vygenerování jednoho sta pseudonáhodných čísel datového typu long. Generátor využívá hašovací funkce SHA-1. Jako semínko slouží systémový čas, který sice není doporučený pro ostré nasazení, ale rozhodně je nejdostupnější a pro testovací účely plně dostačuje. 5.2 Testování rychlosti otisků Testovány jsou algoritmy MD5, Whirlpool, Tiger, SHA-1 a všechny čtyři algoritmy SHA-2. S každým vstupním textem je provedeno deset hašování, vstupní text je desetkrát obměněn. Výsledný čas tedy udává trvání jednoho sta průběhů dané hašovací funkce. 5.3 Testování rychlosti symetrických blokových šifer V této části se zabývám měření rychlosti následujících symetrických blokových šifer: AES, DES, dvouklíčový TripleDES, Blowfish a jeho následovníka Twofish, dále pak IDEA a Serpent. Se stejnými vstupními daty (otevřený text, tajný klíč, připadně i inicializační vektor) je provedeno deset opakování, vstupní data jsou opět desetkrát obměněna. Šifrování i dešifrování je měřeno zvlášt. Není použit žádný padding. Všechny blokové šifry jsou testovány v operačních módech ECB, CBC a OFB. Pozornost si zaslouží implementace operačních módů u trojnásobného DES. Knihovna Bouncy Castle implementuje operační módy šifer jakožto třídy obalující dané šifry. Proto aplikuje operační mód pouze jednou nad šifrou jako celkem a ne pro každou šifru DES zvlášt, jak je tomu například v implementaci pro SSH1. Všechny šifry kromě DES a TripleDES používají klíč o délce 128 bitů. 25

5. NAPROGRAMOVANÁ APLIKACE 5.4 Testování rychlosti symetrických proudových šifer Používá šifry RC4 a Salsa20. Stejně jako v předchozím případě se měří čas jednoho sta opakování, přičemž vždy po deseti cyklech dojde k vygenerování nových vstupních dat. Opět jsou výsledky pro šifrování a dešifrování uváděny zvlášt. 5.5 Testování rychlosti asymetrických blokových šifer Měří rychlost šifer RSA a ElGamal. Samostatně je testována šifra RSA s využitím Čínské věty o zbytku 1.Testování se provádí zvlášt pro šífrování a dešifrování. Vzhledem k tomu, že RSA umožňuje použít stejný pár klíčů i k podepisování, je v tomto případě změřen i čas potřebný k podepisování a ověřování podpisu. Délka klíčů je 1024 bitů. Šifra RSA je v obou případech implementována dle standardu PKCS#1. Implementace asymetrických šifer v odlehčené knihovně Bouncy Castle je významě limitována maximální možnou délkou otevřeného textu. Ta činí u RSA pouhých 127 bytů (1016 bitů). Autoři svůj krok vysvětlují tím, že asymertická kryptografie je natolik časově náročná, že na mobilních zařízeních nemá její použití smysl jinak než ve spojení se symetrickou kryptografií a hašovacími funkcemi. Proto jsou asymetrické šifry testovány pouze pro 256bitový otevřený text. Stejná délka dat je použita na vstupu algoritmů digitálního podpisu. 5.6 Testování rychlosti podepisovacích algoritmů K otestování byl zvolen algoritmus DSA. Testuje se za stejných podmínek jako u asymetrických blokových šifer, opět probíhá deset kol podepisování nad 256bitovými daty. 5.7 Generování klíčů Testování probíhá nad klíči pro RSA, DSA, ElGamal, DES a vícenásobný DES. Pokud generované klíče závisí na velikých prvočíslech spokojíme se s osmdesátiprocentní pravděpodobností při statistických testech, že vygenerovaná hodnota je prvočíslo. Základními generovanými velikostmi jsou 512, 768, 1024 a 2048 bitů. Z důvodů velké časové náročnosti některých generování nemusí být nutně testovány všechny délky pro každý algoritmus. 1. http://en.wikipedia.org/wiki/chinese_remainder_theorem 26

5. NAPROGRAMOVANÁ APLIKACE Funkce generující klíče pro RSA vyžaduje v parametru zadání předgenerovaného e, jehož generování není součástí testů. DES a vícenásobný DES si nechávají generovat klíče o délkách 56 respektive 112 bitů. 27

Kapitola 6 Závěr Záznamy z provedených měření jsou publikovány v příloze. Rozhodl jsem se je k této práci připojit navzdory faktu, že zabírají prostor několika desítek stran. Jsou totiž přímým výsledkem mojí práce. Tyto tabulky včetně grafického zpracování jsou k dispozici na přiloženém médiu. Provedená měření jasně prokazují, že současné mobilní telefony poskytují dostatečný výkon k tomu, abychom je mohli používat k šifrování a podepisování. Na solidní úrovni je rychlost hašovacích funkcí, ale generování klíčů stále potřebuje vyšší výkon, než mu mohou mobilní telefony nabídnout. V následujícím textu rozeberu dosažené výsledky podrobněji, nejprve podle testovaných operací, poté podle jednotlivých mobilních telefonů. U hašovacích funkcí záleží na volbě algoritmu a použité implementaci. Obecně se dá říci, že algoritmy SHA-2 poskytují dostatečnou bezpečnost při zachování poměrně vysoké rychlosti. Velkým překvapením pro mě bylo, že na polovině zařízení byl algoritmus SHA-1 několikanásobně pomalejší než jeho následovníci. Ani kdysi velmi populární algoritmus MD5 nikterak nevyčníval a rychlostně byl srovnatelný s SHA-2. Zůstaneme-li ještě u posledně jmenované rodiny hašovacích funkcí, bylo zajímavé sledovat, jak na některých telefonech zvítězily SHA-224 a SHA-256 oproti SHA-384 a SHA- 512, častěji však ty druhé byly rychlejší (viz A.1: 35, A.11: 45, A.21: 55). Nepodařilo se mi odhalit příčinu velmi pomalého běhu SHA-224 na některých mobilech značky. Původně jsem myslel, že se jedná o chybu měření způsobenou pravděpodobně správcem objektů javovského virtuálního stroje, výsledky však zůstávaly prakticky stejné pro různě zkompilované testy. Šifrování a dešifrování symetrickými šiframi proběhlo podle očekávání. U žádné z nich se neprojevil rozdíl mezi rychlostí šifrování a dešifrování, nejrychlejším operačním módem byl nejjednodušší ECB. Módy CBC a OFB jsou zhruba stejně rychlé a průběh šifrování zpomalují přibližně o 10 % oproti ECB. Šifry Blowfish a Twofish se projevily jako stejně rychlé. Generování pseudonáhodných čísel nečiní problém ani těm nejpoma- 28

6. ZÁVĚR lejším telefonům v testu (viz A.35: 69), zbývá vyřešit získávání a dodání kvalitního kryptografického materiálu jako semínka. Asymetrická kryptografie byla asi nejvíce ovlivněna použitou knihovnou, která neumožňovala šifrování řetězců delších než 1027 bitů. Na 256bitovém vstupním textu se u algoritmu RSA většina mobilních telefonů dostala na časy kolem dvou vteřin při práci se soukromým klíčem a pod půl vteřiny při práci s klíčem veřejným bez použití Čínské věty o zbytku (viz A.31: 65). Její použití zrychlilo šifrování až padesátinásobně, což jsou z uživatelského hlediska již akceptovatelné hodnoty(viz A.32: 66). V těchto testech propadl pouze šest let starý T630 a na hraně využitelnosti se ocitla stále velmi oblíbená Nokia 6230i s deseti vteřinami pro operace se soukromým a třemi vteřinami pro práci s veřejným klíčem. Ve svém úvodním hodnocení jsem se velmi skepticky vyjádřil k možnosti generovat klíče přímo na mobilních telefonech s odkazem na velkou časovou náročnost tohoto problému. Přitom letmý pohled do tabulek odhaluje čísla v řádech jednotek, maximálně desítek minut. V tom hrají roli vlastnosti testu popsané v předchozí kapitole, které nezajišt ují dostatečnou bezpečnost vygenerovaných klíčů generování skutečně kvalitních klíčů by bylo časově náročnější. K takto kategorickému soudu jsem ale měl i jiný důvod. Podle mého názoru je mobilní telefon osobní zařízení určené k umožnění okamžité komunikace a dlouhodobé výpočty na něj nepatří. Navíc by bylo žádoucí provádět tyto výpočty na pozadí, což nemůsí být všude umoˇzněno. Vývojáři některých operačních systémů se totiž cíleně brání implementování multitaskingu a zdůvodňují to snahou o dosažení co nejsvižnější odezvy. Překvapilo mě, že generování klíče pro TripleDES vychází rychleji, než generování klíče pro jednoduchý DES, přestože obě generující metody jsou totožné. Provedené testy názorně dokumentují rychlost vývoje mobilního hardwaru. T630 patřil v roce 2003 mezi nejlepší telefony na Evropském trhu, Nokia 6230i se stala nejlepším mobilem roku 2005. Oba telefony tedy dělí pouhé dva roky a přitom je Nokia přibližně 20x rychlejší než. Nokia 6300 byla v roce 2006 prezentována jako mobilní telefon střední třídy, přesto je v průměru třikrát rychlejší než o dvacet měsíců starší topmodel. V tomto směru zklamal T700 z poloviny roku 2008, jehož nevyrovnané výsledky při práci s většími objemy dat si nedovedu vysvětlit jinak, než že šlo o výrobní chybu. Naopak sympaticky zapůsobil lowendový Samsung Corby, který dokázal drˇzet krok s telefony vyšších tříd a potvrdil, že na datu uvedení záleží více než na zaškatulkování do kategorií podle ceny a nabízených funkcí. 29