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

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Šifrování komunikace mobilních zařízení pomocí Java ME DIPLOMOVÁ PRÁCE Ondřej Životský Brno, jaro 2007

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

3 Poděkování Chtěl bych poděkovat svému vedoucímu práce Mgr. Janu Pavlovičovi za jeho vedení, náměty i kritiku. Rád bych také poděkoval kamarádům, kteří mi pomohli testovat aplikace na svém mobilním telefonu. Dík patří také všem, kteří mě jakkoliv pomohli, poradili nebo jen povzbudili. iii

4 Shrnutí Cílem diplomové práce bylo prozkoumat možnosti vývoje aplikací pro platformu Java ME a vytvořit aplikaci pro mobilní zařízení, která by umožňovala šifrovat komunikaci. V této práci je detailněji popsána platforma Java ME, její vlastnosti a využití. Větší pozornost je věnována knihovnám určeným pro mobilní telefony. Nemalá část je věnována i rozboru šifrovacích algoritmů a možnostem jejich použití v Java ME. V práci je popsán i vývoj aplikace umožňující šifrování, která je součástí této diplomové práce. iv

5 Klíčová slova Java ME, MIDP, CLDC, MIDlet, Sybek, šifrování v

6 Obsah 1 Úvod Java Platform, Micro Edition (Java ME) Konfigurace platformy Java ME Connected Limited Device Configuration Connected Device Configuration Profily platformy Java ME Mobile Information Device Profile Information Module Profile Foundation Profile Personal Basis Profile Personal Profile Rozšiřující balíčky MIDlet Životní cyklus MIDletu Základní funkce Record Management System Uživatelské prostředí MIDletu Sít ová komunikace Bezpečnost Instalace Chystané novinky v MIDP Java APIs for Bluetooth Průzkum okolí Komunikace Správa zařízení Šifrování Symetrické šifry DES AES IDEA Šifry s veřejným klíčem Diffie-Hellman ElGamal RSA Rabin Eliptické křivky Šifrování v Java ME Vývoj aplikace Sybek Požadavky na systém Analýza sytému vi

7 4.3 Návrh systému Implementace systému Uživatelské prostředí Ukládání dat Textové zprávy Lokální adresář Bluetooth komunikace Šifrování dat Nastavení a další funkce Testování Závěr Literatura A Popis případů užití vii

8 Kapitola 1 Úvod Pro většinu lidí dnes patří mobilní telefon mezi zařízení, bez kterých se lze jen těžko obejít. Běžně se s ním můžeme setkat u malých dětí ve škole, u spolupracovníků i u seniorů. S rostoucí popularitou tohoto zařízení se rozvíjí i jeho možnosti využití. Díky rychlému rozvoji technologií se také prudce zvyšuje jeho výkon. Proto je možné jej použít nejen na telefonování a posílání zpráv, ale k i běhu aplikací, her a multimédií. Mobilní telefon se stává důležitou součástí každého člověka. Nárůst popularity a možnosti využití však přináší obavy z útoků a krádeží. Telefon často ukrývá důležitá data a citlivé informace. Předávání těchto informací však není bezpečné, nebot kdokoliv může celkem jednoduše bezdrátovou komunikaci odposlouchávat. Ale každý člověk má přece právo na své soukromí. Po nezabezpečené síti je potřeba posílat data, která by neměla být přístupná třetí osobě. Pro většinu lidí se stalo normální, že přistupují na webové stránky nebo k ům prostřednictvím šifrovaných spojení. Ve světě mobilních telefonů se tato možnost začíná pomalu objevovat také, ale zatím jen u sít ových spojení. U volání a posílání zpráv zatím tuto možnost nemáme. Je tedy potřeba využít nějaké aplikace, která nám umožní zachování soukromí i bezpečnosti. Bohužel v současné době žádná takové aplikace není zdarma k dispozici. Proto by bylo dobré, kdyby existovala alternativa k draze placeným aplikacím, ale přitom poskytovala stejnou funkčnost a bezpečnost. A tento úkol byl motivací pro moji diplomovou práci. Prakticky na všech mobilních telefonech, které přicházejí na trh, je v současné době podpora Java ME aplikací. Z tohoto hlediska se tedy jedná se o ideální platformu pro vývoj aplikací určených pro mobilní telefony. Kvůli svému univerzálnímu rozhraní a hlavně kvůli požadavkům na bezpečnost má však určitá omezení. Není tedy možné využít veškeré funkce a možnosti, které mobilní telefon poskytuje uživateli. Vývojář se musí spokojit pouze se základními funkcemi a případně s několika rozšiřujícími balíčky. Vývoj aplikací, které řídí nebo obsluhují základní funkce telefonu, je tedy značně omezen. A některé funkce nelze pomocí Java ME ovládat vůbec. Vedle Java ME platformy bývají v současných výkonných telefonech i operační systémy Symbian, Windows Mobile nebo jiné. Operační systém dává vývojáři oproti Javě větší svobodu. Aplikace mají přístup do telefonu a mohou využívat mnohem více jeho funkcí. Mohou upravovat nastavení systému, přistupovat k datům, službám atd. Mobilní telefony však zatím nemají podporu pro více operačních systémů, takže pořízením telefonu si také zvolíte operační systém, který budete používat. Ale aplikace napsané pro určitý operační sys- 1

9 1. ÚVOD tém nejsou přenositelné, takže je nespustíte na jiném systému. Toto je výhoda platformy Java ME, nebot je podporována na všech telefonech. A nezáleží na tom, jaký mají operační systém, nebo jestli vůbec nějaký mají. Následující kapitola této práce se proto zabývá platformou Java ME. Je v ní popsána struktura platformy, její členění i vazby k ostatním technologiím. V jednotlivých kapitolách jsou podrobněji popsány její vlastnosti a knihovny, které nabízí. Pro lepší pochopení je většina informací doplněna krátkým příkladem kódu, který demonstruje praktické použití. Další kapitola je věnována šifrování. Blíže se v ní popisuje dělení šifer, jejich spolehlivost, využitelnost a základní principy algoritmů. Seznámení s konkrétními šiframi a jejich vlastnostmi pomáhá pochopit volbu šifrovacích algoritmů v aplikaci, která je součástí této práce. Čtvrtá kapitola se zabývá vývojem aplikace Sybek. Jednotlivé podkapitoly odrážejí postup při vývoji. Pomocí UML diagramů je zde zobrazen systém, jeho chování a struktury. Podrobněji se věnuje implementačním detailům aplikace. Závěr kapitoly je věnován testování. 2

10 Kapitola 2 Java Platform, Micro Edition (Java ME) Java Platform, Micro Edition (nebo zkráceně Java ME) je soubor technologií a specifikací, který umožňuje vytvořit prostředí pro běh aplikací napsaných v jazyce Java i na malých zařízeních s omezenými prostředky. Poskytuje jednoduché a univerzální rozhraní pro ovládání nebo řízení přístrojů od různých výrobců. Její využití je vidět zejména v mobilních telefonech a kapesních počítačích (PDA), ale používá se i v jiných zařízení jako je televizní settop box nebo tiskárna. Díky univerzálnímu rozhraní jsou aplikace napsané pro platformu Java ME vysoce přenositelné a použitelné na zařízení od téměř jakéhokoliv výrobce. Následující obrázek zobrazuje přehled Java ME technologií a jejich souvislosti s technologiemi celé Javy 1 : 1. Zdroj: Sun Microsystems, Inc., 3

11 2.1. KONFIGURACE PLATFORMY JAVA ME Celá technologie Java ME je postavena na 3 základních elementech: konfigurace - poskytuje nejzákladnější knihovny a možnosti virtuálního stroje pro velké množství zařízení profily - soubor API, který je specifický pro menší množinu zařízení volitelné balíčky - soubor API, které jsou specifické pro konkrétní technologie nebo zařízení 2.1 Konfigurace platformy Java ME Konfigurací se v Java ME rozumí specifikace softwarového vybavení pro určitou skupinu zařízení. Tyto skupiny jsou určeny podle hardwarového vybavení (velikost paměti, rychlost procesoru, vlastností displeje,...). Každá konfigurace obsahuje specifikaci virtuálního stroje, základních knihoven, tříd a API. Nejsou zde definovány žádné knihovny pro práci s uživatelským rozhraním, interakci s uživatelem, správu událostí atd. Toto je definováno v tzv. profilech, které jsou jakousi nadstavbou konfigurací. V současnosti existují pro Java ME dvě základní konfigurace. Pro menší zařízení typu mobilní telefon je určena Connected Limited Device Configuration (CLDC), pro výkonnější zařízení typu smartphone je určena Connected Device Configuration (CDC) Connected Limited Device Configuration Connected Limited Device Configuration (CLDC) je zaměřená na malá zařízení s velmi omezenými zdroji. Specifikuje minimální požadavky na knihovny a komponenty Javy, hlavní knihovny, vstup a výstup, sít a bezpečnost. Tato konfigurace je určená pro zařízení s následující charakteristikou: 160 KB až 512 KB celkové paměti pro platformu Java (128 KB energeticky nezávislé paměti pro virtuální stroj a knihovny CLDC, minimálně 32 KB energeticky závislé paměti pro běh aplikací) 16-bitový nebo 32-bitový procesor napájení z baterie, nízká spotřeba energie připojení k nějaké síti, často bezdrátově, nespolehlivě a s omezenou šířkou pásma (9600 b/s i méně) Tato konfigurace je používána hlavně v mobilních telefonech, pagerech a PDA. Implementací virtuálního stroje pro CLDC je takzvaný Kilobyte Virtual Machine (KVM). Vzhledem k omezeným zdrojům nepodporuje KVM práci s pohyblivou řádovou čárkou, finalizaci, plnou obsluhu chyb (error handling), Java Native Interface (JNI), skupiny vláken a démonická 4

12 2.2. PROFILY PLATFORMY JAVA ME vlákna, uživatelské class-loadery, reflexi a slabý typ reference (weak reference). Navíc není specifikována podpora uživatelského rozhraní, správa aplikací (instalace, spouštění, mazání) a interakce aplikace s uživatelem. Toto je ponecháno pro definování v profilech, které jsou nadstavbou konfigurace. Virtuální stroj poskytuje jednoduchý bezpečnostní model zvaný sendbox. To znamená, že aplikace je spuštěna v uzavřeném prostředí a mimo vlastních knihoven může využívat pouze API definované konfigurací, profily a API podporované zařízením. Aplikace tedy nemá přístup nikam, kam to virtuální stroj nepovolí a neumožní Connected Device Configuration Connected Device Configuration (CDC) je určená pro výkonná mobilní zařízení s velkou pamětí a výkonem, která zvládnou běh plného virtuálního stroje Javy. CDC je podmnožinou Java SE, která obsahuje téměř všechny knihovny z Java SE, mimo knihoven pro práci grafickým uživatelským rozhraním. CDC poskytuje základ pro Java ME na zařízeních, která jsou charakteristická těmito vlastnostmi: minimálně 512 KB paměti ROM, minimálně 256 KB paměti RAM 32-bitový procesor připojení k nějaké síti podpora úplné implementace Java Virtual Machine (JVM) pro platformu Java SE Tato konfigurace je využívána v PDA, set-top boxech, navigátorech atd. Přestože tyto zařízení musí zvládnou běh standardní JVM, bývá na nich implementace virtuálního stroje uzpůsobená jejich výkonu a možnostem. Implementace takového stroje bývá označována jako Compact Virtual Machine (CVM). CVM se svými vlastnostmi a funkcemi příliš neliší od běžného virtuálního stroje pro Java SE. Pro obzvláště výkonná mobilní zařízení existuje i HotSpot virtuální stroj, který již umožňuje kompilaci a optimalizaci aplikace za běhu. 2.2 Profily platformy Java ME Profil doplňuje konfiguraci zařízení o další knihovny, které zpřístupňují zdroje specifické pro užší a konkrétnější množinu zařízení. Profil specifikuje například uživatelské rozhraní, ukládání dat, přístup ke zdrojům atd. Obě používané konfigurace mají své vlastní profily, které jsou na nich postavené: nejznámější profily pro CLDC konfiguraci Mobile Information Device Profile (MIDP) Information Module Profile (IMP) 5

13 2.2. PROFILY PLATFORMY JAVA ME Digital Set Top Box Profile - "On Ramp to OCAP" nejznámější profily pro CDC konfiguraci Foundation Profile (FP) Personal Basis Profile (PBP) Personal Profile (PP) Mobile Information Device Profile Jedná se o nejčastěji používaný profil, který je určen pro mobilní telefony, pagery a základní PDA. Je založen na konfiguraci CLDC. Stále počítá s prací s omezenou energií, sítí, pamětí, výkonem i malým displejem. MIDP je určen jak pro zařízením s operačním systémem, se souběžným zpracováním více úloh a souborovým systémem, tak pro zařízení s jednoduchým systémem s vlákny a bez souborového systému. Mobilní zařízení musí mít pouze jádro schopné obsluhovat základní hardware (obsluha přerušení a výjimek, plánování), musí zvládat práci se sítí, s energeticky nezávislou pamětí, správu aplikací, poskytovat reálný čas, zapisovat do bitového displeje a číst ze vstupu (klávesnice). S přibývajícími vlastnostmi a možnostmi v profilu MIDP se zvyšují i požadavky na zařízení, na kterých mohou být implementovány. Následující tabulka ukazuje hardwarové požadavky jednotlivých verzí: 6

14 2.2. PROFILY PLATFORMY JAVA ME V současnosti se používají v praxi dvě verze tohoto profilu: MIDP 1.0 nebo MIDP 2.0. Pracuje se ale i na nové specifikaci MIDP 3.0. Původní profil definoval jak má vypadat aplikace (sémantika MIDletů, ovládání atd.) a základní API pro práci s uživatelským rozhraním, pamět ovým úložištěm (persistent storage), sítí a časovačem. Ve verzi 2.0 přibyla podpora práce se zabezpečenou sítí a další sít ové protokoly, automatické spouštění MIDletů událostmi (časovačem nebo příchozím spojením), podpora uživatelského rozhraní specializovaného na hry, podpora zvuků, hudby a hlasitosti, podepisování MIDletů atd. Ve verzi 3.0 bude vylepšeno API uživatelského rozhraní, zvýšení bezpečnosti pamět ového úložiště, sdílení knihoven mezi MIDlety, nové vlastnosti sítě, bezpečnostní prvky, události a možnost běhu na CLDC, CDC i OSGi Information Module Profile Tento profil vychází ze specifikace MIDP a je tedy také postaven na konfiguraci CLDC. Je určen pro zařízení, která nemají displej a klávesnici. Vstup bývá realizován několika tlačítky a výstup například LED diodami. Specifikace i implementace IMP je totožná s MIDP 1.0, mimo hardwarových požadavků na vstup-výstupní zařízení a mimo balíku javax.microedition.lcdui. Později vznikla nová verze, která je nazvaná Information Module Profile - Next Generation (IMP-NG). Ta vychází z profilu MIDP 2.0 a opět z přebírá vše mimo požadavků na vstup a výstup (opět vypuštěn celý balík javax.microedition.lcdui). Je zpětně kompatibilní s IMP, podporuje zabezpečené sít ové spojení, automatické spouštění IMletů, digitální podpisy a vše ostatní z MIDP Foundation Profile Jedná se o základní profil pro konfiguraci CDC a je určen televizním set-top boxům, PDA a jiným výkonným zařízením. Jeho cílem je poskytnout API pro bohatou sít ovou podporu, bezpečnost a vstup-výstupní operace. Grafické uživatelské rozhraní v tomto profilu není vůbec řešeno. Foundation Profile je základním a často jediným profilem pro bezdisplejová výkonná zařízení typu set-top box. Mobilní telefony a PDA využívají dalších profilů, které staví na FP a přidávají k němu podporu uživatelské prostředí. Zařízení s tímto profilem musí mít minimálně 1024 KB ROM paměti, 512 KB RAM paměti, nějaké připojení k síti a nemusí mít grafický výstup. Ve verzi 1.1 je již požadováno kvalitní připojení k síti a větší pamět, doporučen je i displej a vstupní zařízení. Tato novější verze přidává funkcionalitu z Java SE v 1.4 a definuje některé volitelné balíčky, které slouží ke zvýšení bezpečnosti (Java Secure Socket Extension, Java Cryptography Extension, Authentication and Authorization Service) Personal Basis Profile Tento profil slouží hlavně jako základ, na kterém staví Personal Profile. Využití nachází na zařízeních, která zobrazují uživateli grafický výstup, ale plná implementace java.awt 7

15 2.3. ROZŠIŘUJÍCÍ BALÍČKY knihovny by byla zbytečná. V profilu je definován nový model aplikace zvaný Xlet, který dovoluje mimo jiné i IXC, což je vzájemná komunikaci mezi Xley běžícími na stejném zařízení (inner-xlet communication). PBP specifikuje nezbytné jádro knihovny java.awt pro práci s grafikou v jednom okně. Je určen zařízením s kvalitním připojením k síti, se základním grafickým výstupem, 2 MB ROM paměti a 1 MB RAM paměti. Původní PBP vycházel ze specifikace Java SE v 1.3.1, proto byl později nahrazen verzí 1.1, která již vychází z Java SE verze Personal Profile Personal Profile využívá CDC konfiguraci a je postaven na profilech FP a PBP. Je to množina API, která podporuje zařízení s omezenými zdroji a s GUI rozhraním založeným na AWT komponentách. Profil je uzpůsoben zařízením s kvalitním připojením k Internetu a nabízí náhradu k technologii PersonalJava. Snaží se vytvořit novou generaci PersonalJava, ale současně zachovat zpětnou kompatibilitu. Původní PP vychází z Java SE verze 1.3.1, proto byl aktualizován verzí 1.1 vycházející z Java SE 1.4. Minimální požadavky jsou 3,5 MB ROM a 3,5 MB RAM paměti. Profil umožňuje spouštět aplikace typu Xlet, ale i klasických programů s metodou public static void main(string[]). Nově je přidána i podpora webových appletů. 2.3 Rozšiřující balíčky Rozšiřující balíčky (optional packages) obohacují funkcionalitu konfigurací a profilů platformy Java ME o knihovny, které jsou typické pro nějakou skupinu zařízení, ale tyto funkce nemusí být nutně podporovány na všech těchto zařízeních. Balíčky jsou modulární, proto může výrobce implementovat jen ty, které uzná za vhodné. Typickým příkladem rozšiřujícího balíčku je například Location API, které poskytuje aplikacím funkce pro zjišt ování aktuální fyzické pozice mobilního zařízení. Je určen zařízením s konfigurací CLDC i CDC, ale záleží pouze na výrobci, zda chce tuto funkčnost implementovat. Nejznámější rozšiřující balíčky jsou: Mobile Media API (ovládání zvuků, hudby a hlasitosti, generování jednoduchých tónů) Wireless Messaging API (odesílání, příjem a práce se zprávami typu SMS, MMS, CBS a USSD) Java APIs for Bluetooth (umožňuje spojení přes bluetooth, podpora protokolů: RF- COMM, OBEX a Service Discovery) Mobile Game API (usnadnění vývoje kvalitnějších her. Podporuje real-time, multiplayer, detekci kolizí, transformace obrázků, textury, stínování atd.) Location API (udává fyzickou polohu mobilního zařízení) 8

16 2.4. MIDLET Scalable 2D Vector Graphics API (podpora 2D vektorové grafiky a obrázků ve formátu SVG) PDA Optional Packages (přístup do souborového systému, adresáře, kalendáře a todo listu) RMI Optional Package (podpora volání vzdálených metod) J2ME Web Services (umožňuje přístup k webovým službám) 2.4 MIDlet MIDlet je aplikace určená pro běh na mobilním zařízení s platformou Java ME, konfigurací CLDC a profilem MIDP. Kromě knihoven z profilu a konfigurace, může MIDlet požadovat ke svému běhu i některé volitelné balíčky. MIDlet je přenositelný a měl by být spustitelný na jakémkoliv zařízení, které splňuje všechny požadavky. Zobrazení grafického výstupu i ovládání některých komponent se může lišit podle značky a typu zařízení, ale funkčnost je vždy ekvivalentní. MIDlet je zabalen do JAR archívů. Archív musí obsahovat manifest, jeden nebo více MI- Dletů a další potřebné knihovny. Může obsahovat i obrázky, text a další zdroje, které aplikace využívá. Manifest obsahuje informace o počtu MIDletů, jejich název, verzi a minimální konfiguraci a profil, které potřebují ke svému běhu. Může obsahovat také popis, ikonu, velikost atd. Následující příklad ukazuje manifest popisující archív se dvěma MIDlety. MIDlet-Name: Hry MIDlet-Version: MIDlet-Vendor: SuperHry s.r.o. MIDlet-1: Tetris, /obr/tetris.png, cz.pokus.tetris MIDlet-2: Had, /obr/had.png, cz.pokus.had MicroEdition-Profile: MIDP-2.0 MicroEdition-Configuration: CLDC-1.0 Muj-vlastni-atribut: abc, 123, :-) Hodnotu každého atributu definovaného v manifestu je možné zjistit i v aplikaci. Například potřebný profil se zjistí voláním metody getappproperty("microedition-profile"), která vrátí řetězec se zadanou hodnotou. Pro spuštění běžné aplikace je třeba do mobilního zařízení nahrát JAR archív. To však vždycky nestačí. K definici dalších informací a požadavků aplikace slouží deskriptor aplikace. Jedná se o další soubor, který je distribuován spolu s JAR archívem. Deskriptor aplikace má příponu JAD a je podobného formátu, jako manifest v archívu. Je v něm možné doplnit informace nutné k instalaci aplikace, oprávnění, autory atd. Stejně jako manifest, tak i deskriptor má atributy povinné, volitelné a libovolné vlastní, které nezačínají MIDletnebo MicroEdition-. Pokud je nějaký atribut uveden v deskriptoru i manifestu, měl by mít stejnou hodnotu, jinak záleží jen na zařízení, kterou z nich bude brát v potaz. Následující příklad ukazuje deskriptor se standardními i vlastními atributy. 9

17 2.4. MIDLET MIDlet-Name: Send SMS MIDlet-Version: 3.2 MIDlet-Vendor: Nobody a.s. MIDlet-1: Send SMS,,cz.pokus.SendSMSMidlet MIDlet-Jar-Size: MIDlet-Jar-URL: Send.jar MIDlet-Permissions: javax.wireless.messaging.sms.send MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 SMS-Port: První řádky jsou stejné jako v případě manifestu, pak následují dvě povinné položky: informace o velikosti aplikace (v bytech) a cesta k aplikaci. Další řádek říká, že aplikace chce mít oprávnění posílat SMS zprávy. Na posledním řádku je uveden vlastní atribut s číslem portu. Uživatel si tak může změnit číslo portu, se kterým aplikace pracuje, aniž jakkoliv zasáhne do aplikace nebo samotného JARu. V mobilním zařízení tak může být aplikace nainstalována duplicitně, protože obě instance nemusí přistupovat ke stejnému portu. Každý MIDlet má k dispozici API z CLDC, MIDP, rozšiřujících balíků a všechny soubory v archívu. K jiným souborům, funkcím ani zdrojům se z aplikace nelze dostat, pokud přístup k nim neposkytuje nějaké z uvedených API. Proto je dobré uvádět seznam nutných rozšiřujících balíčků do deskriptoru aplikace. Mobilní zařízení tak může uživatele informovat již při instalaci, že nepodporuje některé funkce a tak není možné MIDlet spustit. V opačném případě se aplikace bez varování ukončí a často se uživatel ani nedozví proč. Stejně jako běžná aplikace pro platformu Java SE má hlavní třídu, která obsahuje metodu public static void main(string[]), tak i v MIDletu je třída, která funguje jako vstupní bod celé aplikace. Nemusí však obsahovat konkrétní metodu, ale musí rozšiřovat abstraktní třídu javax.microedition.midlet.midlet. Aplikace se pak spouští metodou startapp(). Jméno hlavní třídy je vždy uvedeno v manifestu. Následující příklad ukazuje jednoduchý MIDlet: public class Midlet extends MIDlet implements CommandListener { private Form form; public Midlet() { form = new Form("My first application"); // create screen form.append("hello, world."); form.addcommand(new Command("Exit", Command.EXIT, 0)); form.setcommandlistener(this); // listen } public void startapp() { Display.getDisplay(this).setCurrent(form); } public void pauseapp() { } public void destroyapp(boolean unconditional) { } notifydestroyed(); // exit application // set text 10

18 2.4. MIDLET } public void commandaction(command command, Displayable displayable) { destroyapp(true); // always exit } Životní cyklus MIDletu Abstraktní třída MIDlet, kterou rozšiřuje každý MIDlet, definuje tři základní metody pro práci s aplikací: startapp() pro spuštění aplikace, pauseapp() pro pozastavení aplikace a destroyapp(boolean unconditional) pro ukončení aplikace. Pokud je aplikace nainstalována, jsou její třídy, datové úložiště a ostatní soubory uloženy v mobilním zařízení. Spustit ji uživatel může prostřednictvím aplikačního manažeru (application manager software) svého mobilního zařízení. Aplikační manažer vytvoří instanci MIDletu voláním bezparametrického konstruktoru a následně zavolá metodu startapp(). U aplikací napsaných pro platformu Java SE je běžné, že může být spuštěno několik aplikací současně, můžou provádět výpočty i v případě, že nejsou aktivní a můžou se vzájemně spouštět. Nic z toho však MIDlet nemůže. Vždy běží právě jeden a při spuštění jiného je nejprve ten předchozí ukončen. Každý spuštěný MIDlet se vždy nachází v jednom z následujících stavů: aktivní (Active) zastavený (Paused) ukončený (Destroyed) Obrázek 2.1: Životní cyklus MIDletu Aplikační manažer vytvoří novou instanci MIDletu a jeho stav nastaví na zastavený. V konstruktoru může aplikace provést nějakou inicializaci. Pak aplikační manažer mobilního zařízení zavolá metodu startapp(), stav MIDletu se změní na aktivní a aplikace může běžet. Při nějaké události (příchozí zpráva, volání atd.) je aplikace dočasně pozastavena. V takovém případě zavolá aplikační manažer metodu pauseapp(), ve které by měla 11

19 2.4. MIDLET aplikace uvolnit všechny sdílené prostředky a zdroje, ale její provedení by mělo být co nejrychlejší. Jakmile je to možné, zavolá aplikační manažer opět metodu startapp() a aplikace může pokračovat ve své činnosti. Do stavu ukončený se MIDlet dostane zavoláním metody notifydestroyed(), nebo pokud aplikační manažer zavolá destroyapp(). Aplikace by před ukončením měla uvolnit všechny zdroje, které využívá. Pokud aplikace ještě nechce nebo nemůže skončit, může vyvolat výjimku MIDletStateChangeException, čímž může zamezit přechodu od stavu ukončený. Aplikační manažer mobilního zařízení však může kdykoliv aplikaci ukončit Základní funkce Profil MIDP definuje dvě základní vlastnosti systému (property): microedition.profiles a microedition.locale. Aplikace si tak mohou zjistit verzi implementovaného profilu, nebo aktuálně nastavený jazyk a zvyklosti (locale). Pomocí metody getappproperty() je možné v aplikaci zjistit jejich hodnotu. První vlastnost využívají aplikace, které jsou určeny pro provoz na široké škále zařízení a tedy a i na více verzích profilu MIDP. Aplikace tak může uživateli znepřístupnit některé funkce s odůvodněním, že je telefon nepodporuje (například práci se zvukem). Pokus o volání neexistující funkce profilu totiž mívá za následek pád celé aplikace, často i bez výpisu chyby na displej. Druhá vlastnost systému je užitečná hlavně pro internacionalizaci aplikací. Voláním funkce System.getProperty("microedition.locale") je možné získat aktuálně nastavené locale mobilního zařízení. Užitečný je i balík java.util, který nabízí třídy Timer a TimerTask pro provádění metod v zadaný čas, nebo pro pravidelné spouštění kódu v zadaném časovém intervalu. Nová verze profilu MIDP, která je již na většině mobilních telefonů, umožňuje i jednoduchou práci s multimédii. Jedná se o úplně základní funkce jako přehrání, pauzu, zastavení, zesílení atd. Vše je v balících [package] javax.microedition.media [/package] a [package] javax.microedition.media.control [/package]. Práce s přehráváním multimédií je řízena singletonem Manager, který zpřístupňuje přehrávače na konkrétní typ záznamu. Pomocí třídy Manager je také možné vygenerovat tón nebo zjistit, zda je vůbec možné daný typ záznamu přehrát. Samotné přehrávače médií, definované rozhraním Player, mají svůj životní cyklus s několika stavy, které zaručují postupnou inicializaci přehrávače. Než se záznam z disku nebo Internetu načte, může to nějakou dobu trvat, proto se záznam nejprve načte, připraví do paměti a teprve poté se může přehrát. Kdykoliv během této inicializace je možné přechod do následujícího stavu zrušit. Rozhraní Player poskytuje základní ovládací prvky pro přehrávání a informace o záznamu. Rozhraní VolumeControl definuje metody pro rychlé vypínání zvuku (mute), nastavení hlasitosti i zjištění obou těchto hodnot Record Management System Pro uložení dat, která mají být zachována po vypnutí aplikace i celého mobilního telefonu, se používá model jednoduché databáze se záznamy, který se nazývá Record Management System (zkráceně RMS). V době, kdy vznikla specifikace profilu MIDP ještě neměli mobilní 12

20 2.4. MIDLET zařízení pamět ové karty ani interní souborový systém. Bylo však nutné, aby si aplikace mohly ukládat nastavení, skóre a jiná menší data. Na většině mobilních telefonů byl tento prostor silně omezen. Dnes je už mnohem větší a dokonce je možné data mezi MIDlety sdílet. Datové úložiště je pojmenovaná množina záznamů, která má jedinečné ID v rámci celého mobilního zařízení. Každý MIDlet může mít datových úložišt více. Při jejich vytváření se rozhodne, jestli sem mohou jiné MIDlety číst a zapisovat. Každý záznam je pole bytů a vždy má přidělené ID, které je jedinečné jen v rámci datového úložiště. Při čtení, zápisu i editaci záznamů není třeba řešit zámky nebo semafory, protože přístup k datům je atomická, synchronní a serializovaná operace. Pokud však MIDlet používá více vláken, je pouze na programátorovi, aby zajistil bezpečný přístup k datům. Například při zápisu více vláken současně na konec stejného datového úložiště se může stát, že obě zapíší na stejnou pozici a tím si data přepíší. Každé datové úložiště si navíc pamatuje i čas poslední změny a aktuální číslo verze dat. K přístupu do RMS se používá třídy RecordStore. Pomocí této třídy je možné provádět veškeré očekávané operace, například zjistit seznam všech datových úložišt MIDletu, volné místo, čas posledního přístupu k některému úložišti, uložení záznamu, modifikace, čtení, smazání atd. Následující úsek kódu ukazuje práci s datovým úložištěm. try { RecordStore recordstore = RecordStore.openRecordStore("myData", true); int recid = recordstore.addrecord(data, 0, data.length); // add new recordstore.setrecord(recid, data1, 0, data1.length); // update record recordstore.closerecordstore(); // close RecordStore.deleteRecordStore("myData"); // delete whole record store } catch (Exception ex) { // for simplification this example catch any showerror(ex.getmessage()); } Z příkladu je vidět, že práce s datovým úložištěm není nijak složitá. Jako identifikátor konkrétního úložiště se používá textový řetězec. Při otevírání úložitě parametrem zvolíme, že neexistující úložiště chceme vytvořit. Poté můžeme pracovat se záznamy. Ty jsou reprezentovány polem bytů a při čtení nebo modifikaci se na ně odkazujeme pomocí jedinečného čísla záznamu. Každému datovému úložišti je možné nastavit RecordListener, který pak přijímá události při změně dat. Pro výběr záznamů jsou užitečné třídy RecordFilter a RecordComparator, pomocí nichž lze jednoduše porovnávat a vybírat záznamy. Pro rychlé procházení všech záznamů se používá třída RecordEnumeration Uživatelské prostředí MIDletu K práci s grafickým výstupem je možné použít balíky javax.microedition.lcdui a javax.microedition.lcdui.game, které nabízí vysokoúrovňové a nízkoúrovňové API. Vysokoúrovňové zjednodušuje práci, ale přesný vzhled výstupu záleží na konkrétní implementaci každého výrobce zařízení. Aplikace nemůže ani ovládat posun obrazovky, navigaci 13

21 2.4. MIDLET v textu atd. Rovněž přístup ke klávesnici je zprostředkován přes API implementace, které poskytuje jen základní události. Všechny třídy vysokoúrovňového API jsou potomky třídy Screen a jejich práce často bývá podporována i hardwarově. Jedná se tedy o možnost rychlejšího zobrazení grafického výstupu, ale s různým vzhledem na různých zařízeních. Toho se hojně využívá u aplikací, které nabízí nějakou funkčnost a nikoli dokonalý vzhled. Nízkoúrovňové API poskytuje aplikaci větší kontrolu nad výstupem. Aplikace má plný přístup k obrazovce, může na ni vykreslovat, může detailněji pracovat se vstupem, reagovat na stisk konkrétní klávesy nebo její uvolnění. Toto je užitečné hlavně při tvorbě her. Při využití nízkoúrovňového API již není zaručena přenositelnost. Ta záleží na tom, jestli aplikace nevyužívá speciální vlastnosti jen některých displejů. Třídy poskytující nízkoúrovňové API jsou potomky třídy Canvas nebo Graphics. K displeji se aplikace během celého svého běhu dostane skrze třídu Display, která slouží jako rozhraní aplikačního manažeru. Ten umožňuje aplikaci, pokud je v aktivním stavu, zobrazovat nové obrazovky na displej mobilního zařízení. Třída reprezentující obrazovku displeje je potomek Displayable. Vysokoúrovňové API poskytuje třídy List, TextBox, Form a Alert, nízkoúrovňové nabízí k rozšíření abstraktní třídu Canvas. Celé API uživatelského rozhraní je vláknově bezpečné, metody pro práci s displejem tedy mohou být volány i z vláken, časovačů atd. Pro ovládání aplikace jsou definovány příkazy, které reprezentují stisk nějaké klávesy. Příkazy, objekty typu Command, se přiřazují ke každé obrazovce. Záleží na zařízení, ke které konkrétní klávese bude tento příkaz přiřazen. Každý příkaz má popis, který se zobrazí na obrazovce, typ příkazu a prioritu. Priorita určuje důležitost příkazu a slouží hlavně k vzájemnému porovnávání příkazů. Typ udává, zda se jedná o příkaz typu potvrd, zpět, zruš, nápověda atd. Zařízení má tak možnost přiřazovat příkazy zpět stále na jednu klávesu, nebo naopak programátor může reagovat na příkaz typu zpět, který nedefinoval, ale který odpovídá speciální klávese zpět přímo na mobilním zařízení. Speciální události jsou generovány v nízkoúrovňovém API při stisku klávesy na 3-klávesovém nebo 5-klávesovém joysticku. U těchto kláves je přesně definován jejich význam (nahoru, dolů, střelba, případně i vlevo a vpravo). Následuje příklad zpracování příkazu z obrazovky aplikace (vysokoúrovňové API). public void commandaction(command command, Displayable d) { if (d.equals(mymenu)) { // command from my menu if ((command.getcommandtype() == Command.OK) (command == List.SELECT_COMMAND)) { // user selected item // do something } if (command.getcommandtype() == Command.BACK) {// user want go back // do something } } } Následující kód ukazuje zpracování události stisku klávesy v nízkoúrovňovém API. 14

22 2.4. MIDLET public void keypressed(int keycode) { int action = getgameaction(keycode); // get game action from key event switch (action) { // choose action case LEFT : moveleft(); break; // go left case RIGHT : moveright(); break; // go right... // other options } } Mobilní zařízení může poskytovat i další funkce a příkazy, aniž o tom má aplikace jakékoliv tušení. Typickým příkladem takové funkce je přepínání čísel a písmen při psaní textu. Aplikace pomocí vysokoúrovňového API vytvoří textové pole a přidá nějaké příkazy. Uživatel má však možnost zapínat například T9, vkládat speciální symboly, označovat a kopírovat text. O tyto funkce se aplikace nestará, ty obstarává implementace MIDP. Užitečnou funkcí, kterou nabízejí některé telefony, je možnost výběru telefonního čísla z adresáře, pokud je v aplikaci políčko označené jako telefonní číslo. U vykreslování obrazovek v nízkoúrovňovém API je nutné obsluhovat mnohem více událostí něž ve vysokoúrovňovém. Například je nutné obsluhovat požadavky na překreslení. Při změnách v obraze, například pohybu hráče, je nutné volat metodu pro překreslení dané části obrazu. Vykreslování probíhá v systému souřadnic, jejichž počátek je v levém horním rohu, délku os je možné zjistit příkazy getwidth() a getheight(). Na výstup je možné vykreslovat jednoduché grafické prvky, text i obrázky. Následující příklad ukazuje, jak lze vytvořit obrazovku s jednoduchým seznamem. List mylist = new List("Select option", List.IMPLICIT); mylist.append("black", null); mylist.append("white", null); mylist.addcommand(new Command("Back", Command.BACK, 0)); mylist.setcommandlistener(this); Display.getDisplay(this).setCurrent(myList); Pro snazší tvorbu her byl do MIDP přidán balík javax.microedition.lcdui.game. Ten poskytuje bohaté grafické funkce, které bývají hardwarově akcelerované. V programu se nemusí vytvářet základní funkce a tím se i zmenšuje celková velikost aplikace. Všechny funkce jsou navíc slučitelné s prací se základními grafickými prvky ze standarvního balíku javax.microedition.lcdui Sít ová komunikace Profil MIDP obsahuje silnou podporu sít ové komunikace, zejména se jedná o podporu HTTP spojení. Toto spojení může být realizováno nejen přes TCP/IP, ale i přes WAP nebo imode s přístupem přes bránu. Implementace dovoluje přístup na internetové stránky, ale i k webovým službám. Každé zařízení musí plně podporovat minimálně verzi HTTP 1.1, včetně HEAD, GET a POST požadavků. Spojení se naváže zavoláním metody open() třídy Connector, jako parametr se uvádí adresa. Příklad přístupu na Internet z MIDletu: 15

23 2.4. MIDLET Connector.open(" Třída Connector neotevírá jen HTTP spojení. Aplikace mohou také navázat přímé spojení přes TCP/IP nebo UDP/IP. Stačí v parametru pro otevření spojení uvést místo protokolu http text socket respektive datagram. Pokud není zadána adresa serveru, pak se na zadaném portu vytvoří server čekající na příchozí spojení z jiného zařízení. Spojení přes sériový port je možné navázat použitím parametru "comm:port;parametry" (prametr může například vypadat takto: "comm:com1;baudrate=19200"). Sít ová spojení jsou vždy obousměrná, lze tedy u nich otevřít vstupní i výstupní proud naráz. Následující příklad demonstruje navázání sít ového spojení. Sting url = "socket://localhost:5000"; SocketConnection sc = (SocketConnection) Connector.open(url); OutputStream os = sc.openoutputstream(); os.write("hello, world.\r\n".getbytes());... // do something, than close stream and connection Ve verzi 2.0 profilu MIDP byla přidána podpora šifrování, mobilní zařízení tak může otevřít i HTTPS nebo SSL spojení. Nechybí ani podpora certifikátů a jejich automatické ověřování. Aplikace se nemusí o tuto funkcionalitu vůbec starat. Pro zvýšení bezpečnosti je však nutné, aby MIDlet, který chce využívat sít ové spojení, zažádal o povolení. To znamená, že v deskriptoru aplikace musí být uveden řádek začínající textem MIDlet-Permissions: a za ním seznam protokolů, které chce využívat. Pokud aplikace čeká na příchozí sít ové spojení, musí být stále aktivní a s mobilním zařízením tedy není možné pracovat. Proto existuje třída PushRegistry, která umožňuje MIDletu zaregistrovat u aplikačního manažeru protokol a port, který chce obsluhovat. Pak je možné MIDlet vypnout. Jakmile přijde na daný port požadavek na spojení přes požadovaný port, aplikační manažer MIDlet spustí. Registraci je možné provést již při instalaci MIDletu a to prostřednictvím deskriptoru. Část deskriptoru pak vypadá například takto: MIDlet-Permissions: javax.microedition.io.connector.serversocket, javax.microedition.io.pushregistry MIDlet-Push-1: socket://:12345,example.socket.socketmidlet,* První řádek říká, že aplikace chce používat příchozí spojení přes soket a chce být automaticky spouštěna. Na druhém řádku je požadavek o spuštění MIDletu SocketMIDlet, pokud se nějaké zařízení pokusí připojit na port přes TCP/IP. Hvězdička znamená, že se může jednat o spojení z jakékoliv adresy Bezpečnost Podle specifikace MIDP 1.0 běžely MIDlety v sendboxu a bezpečnost se nemusela nijak řešit. S verzí 2.0 přišly nové funkce a s tím i potřeba vytvořit jednoduchý bezpečnostní model, aby nedošlo k masivnímu rozšíření virů a jiného škodlivého softwaru na mobilní zařízení. MIDlety se proto dělí na důvěryhodné a nedůvěryhodné. Nedůvěryhodné mají neomezený 16

24 2.4. MIDLET přístup k základním balíčkům definovaným ve verzi 1.0 a k třídám pro práci se sít ovým spojením přes http a https protokoly. Ostatní funkce je možné využít, jen pokud je uživatel explicitně povolí, některé mohou být dokonce zakázány úplně. Důvěryhodné MIDlety nemají žádná omezení ve využívání funkcí, uživatel však může některé funkce aplikaci zakázat. Uživatel si zvolí pro každou oblast funkcí (sít ové spojení, přístup k souborům atd.), zda je aplikace může používat, nemůže, nebo jestli se musí dotázat uživatele. Aby se aplikace mohla stát důvěryhodnou, musí být digitálně podepsána. Podepisování a ověřování MIDletů je založeno na X.509 Public Key Infrastructure. Programátor musí digitálně podepsat celý JAR archív a do deskriptoru aplikace přidá parametry obsahující podpis a certifikát. Při instalaci aplikace si aplikační manažer ověří podpis a v případě úspěchu zařadí aplikaci mezi důvěryhodné. Pro práci s certifikáty se využívá knihovna javax.microedition.pki Instalace Instalace MIDletu je možná více způsoby, často záleží i na konkrétním zařízení a výrobci. Jeden způsob však mají všechny zařízení podporující MIDP 2.0 a vyšší společný. Jedná se o OTA (Over-The-Air) instalaci. Každé zařízení musí poskytovat prohlížeč, který dokáže rozpoznat aplikaci podle deskriptoru, uložit ji do zařízení a nainstalovat. V praxi to bývá běžný integrovaný prohlížeč, který se používá k přístupu na Internet. Uživatel pak na stránce pouze "klikne" na odkaz směřující na nějaký deskriptor a mobilní zařízení udělá vše zbylé. Jakmile je aplikace lokálně uložena, aplikační manažer ji nainstaluje a je připravena k použití. V případě takovéto instalace nabízí mobilní zařízení možnost automatické aktualizace. Při požadavku uživatele o aktualizaci, mobilní zařízení stáhne znovu deskriptor aplikace (ze stejné adresy) a ověří, zda nedošlo ke změně verze MIDletu. Pokud ano, provede aktualizaci. Veškeré nastavení a uložená data v aplikaci zůstanou. Další výhodou tohoto postupu je možnost zjištění, zda dané mobilní zařízení je schopné MIDlet spustit. V deskriptoru jsou atributy požadující minimální konfiguraci, profil i volitelné balíčky. Pokud aplikační manažer zjistí, že některou z podmínek nesplňuje, oznámí to uživateli a MIDlet vůbec nestáhne. Podle atributů je schopen poznat i například to, že nemá dostatek místa na aplikaci. Téměř všechny mobilní telefony poskytují možnost instalace aplikace i jiným způsobem. Některé rozpoznají aplikaci při procházení pamět ové karty nebo lokálního souborového systému. Uživatel tak může aplikaci uložit do mobilu přes datový kabel nebo bezdrátové spojení a nemusí vůbec využívat přístup na Internet. Někteří výrobci poskytují i speciální software do počítače, pomocí kterého je možné MIDlety instalovat přes sít ové spojení z počítače. Nevýhodou těchto alternativních postupů instalace je to, že není možné provádět automatické instalace. 17

25 2.5. JAVA APIS FOR BLUETOOTH Chystané novinky v MIDP 3.0 Specifikace Mobile Information Device Profile 3.0 je v současné době stále ještě ve vývoji. V prosinci vyšla "Early Draft Review" specifikace, ze které je možné vyčíst některé připravované novinky. Jedná se často o funkce, které jsou poskytovány různými výrobci prostřednictvím rozšiřujících balíčků, ale nejsou standardizovány, takže je každý výrobce implementuje jinak. Další funkce jsou přidány díky vzrůstající výkonnosti mobilních zařízení, větší pamět ové kapacitě, přídavným kartám i výdrži baterie. Hlavní novinky nové specifikace, které snad uvidíme i ve finální verzi, jsou: současný běh více MIDletů na jednom virtuálním stroji možnost běhu MIDletu na pozadí spuštění MIDletů při spuštění mobilního zařízení dovoluje vzájemnou komunikaci MIDletů MIDlety budou moci sdílet knihovny (LIBlety) zkonkrétnění specifikací, aby byla zaručena maximální přenositelnost mezi mobilními zařízeními vykreslovat na sekundární displej podpora pro výkonné hry bezpečné, připojitelné i vzdálené RMS podpora IPv6 2.5 Java APIs for Bluetooth Bezdrátovou technologií bluetooth je vybavena většina všech nových mobilních zařízení. Pro práci s bluetooth slouží rozšiřující balíček Java APIs for Bluetooth, který je specifikován v JSR-82. Balíček poskytuje aplikacím rozhraní ke komunikaci prostřednictvím této bezdrátové technologie. Zařízení musí mít konfiguraci CLDC a profil MIDP. Specifikace obsahuje základní podporu komunikace přes protokoly RFCOMM, OBEX a Service Discovery protocol. První protokol nám dovoluje vytvořit nízkoúrovňové spojení přes datový proud. Aplikace se musí starat o veškeré řízení komunikace. OBEX je standardní protokol pro výměnu objektů. Využívá se hlavně k synchronizaci a přenosu souborů. Service Discovery protocol slouží k hledání okolních aktivních zařízení. Mobilní zařízení, které implementuje bluetooth API, musí poskytovat základní bezpečnostní prvky definované bluetooth standardem. Také je nezbytné, aby umožnilo spárování zařízení a jejich případnou autorizaci. Funkce, které API poskytuje je možné rozdělit do tří základních skupin: 18

26 2.5. JAVA APIS FOR BLUETOOTH Průzkum okolí Komunikace Správa zařízení Průzkum okolí Pro průzkum okolí se využívá třídy DiscoveryAgent. K nalezení aktivních zařízení slouží metoda retrievedevices() nebo startinquiry(). První metoda zjišt uje dostupnost dříve nalezených zařízení. Druhá spustí ve zvláštním vlákně prohledávání okolí a všechna nalezená zařízení předává prostřednictvím rozhraní DiscoveryListener. Zařízení jsou předávána metodou devicediscovered(), konec prohledávání okolí je oznámeno voláním metody inquirycompleted(). Následující příklad ukazuje inicializaci bluetooth a spuštění prohledávání okolí. try { // init bluetooth and search for neighbour LocalDevice localdevice = LocalDevice.getLocalDevice(); DiscoveryAgent discoveryagent = localdevice.getdiscoveryagent(); localdevice.setdiscoverable(discoveryagent.giac); discoveryagent.startinquiry(discoveryagent.giac, this); } catch (Exception e) { showerror(e.getmessage()); } Aby aplikace mohla navázat spojení se vzdáleným zařízením, musí se připojit ke konkrétní službě. Například k odeslání souboru přes OBEX je nutné vyhledat na zařízení službu, která se staré o příjem dat přes OBEX. Vyhledávání služeb na vzdáleném zařízení opět zajišt uje DiscoveryAgent, prostřednictvím metody searchservices(). Nalezené služby se předávají prostřednictvím stejného rozhraní. Každá služba má svůj identifikátor (UUID) a atributy. Podle těchto informací je možné vybrat hledanou službu. Veškeré informace o službě zapouzdřuje třída ServiceRecord Komunikace Využití služby na vzdáleném zařízení je možné jen v případě, že aplikace bude komunikovat stejným protokolem. K navázání spojení se využívá metoda open(url) třídy Connector, parametrem metody je adresa zařízení ve tvaru protokol://adresa:[uuid];parametry. Pokud chce aplikace vytvořit službu, která bude čekat na příchozí spojení, uvede jako adresu zařízení localhost. Tím se otevře spojení na lokálním zařízení. Následným voláním metody acceptandopen() se začne čekat na připojení nějakého vzdáleného zařízení.... try { // create service url = "btspp://localhost: a1b1c1d1d1e100;name=sppex"; service = (StreamConnectionNotifier) Connector.open(url); StreamConnection con = (StreamConnection) service.acceptandopen(); } catch (Exception e) { showerror(e.getmessage()); } 19

27 2.5. JAVA APIS FOR BLUETOOTH Správa zařízení Pro správu zařízení existují třídy LocalDevice, RemoteDevice a DeviceClass. První třída obsahuje všechny dostupné informace o lokálním zařízení. Aplikace si může zjistit vlastní adresu, jméno, vlastnosti a jiné. Třída RemoteDevice naopak poskytuje informace o vzdáleném (nalezeném) zařízení. Mimo adresy a jména zařízení jsou k dispozici informace o autorizaci, šifrování spojení a zda je zařízení důvěryhodné. DeviceClass reprezentuje třídu nebo typ zařízení. Například může určovat, že se jedná o tiskárnu nebo telefon. 20

28 Kapitola 3 Šifrování Potřeba utajovat informace a zprávy je stará skoro jako lidstvo samo. Během času se samozřejmě metody utajování informací výrazně změnily. Staří Egypt ané používali pro utajení textu speciální hieroglyfy, později se tetovali zprávy otrokům pod vlasy, spart anští vojevůdci používali plátno namotávané na hůl. Časem se začaly rozvíjet složitější šifry, například posun znaků abecedy, šifrovací mřížky, prohazování znaků atd. V předminulém století se začaly rozvíjet šifrovací stroje, které umožňovali rychlejší a důmyslnější šifrování. S rozvojem počítačů se šifrování stalo aktuální nejen pro vojenské a politické účely, ale i pro obyčejné lidi. V současné době je šifrování využíváno téměř všude, kde se nepoužívá k přenosu dat manuální doručování. Šifrované jsou běžné telefonní hovory, ová komunikace i televizní vysílání. V praxi se nejčastěji používají dvě základní množiny šifer. Jsou to šifry s veřejným klíčem a symetrické šifry. Šifrováním se zabývá kryptografie. Kryptografie je nauka využívající poznatků z matematiky ke kódování a dekódování dat tak, aby je nebylo možné číst bez znalosti určitého tajemství. Naproti tomu existuje kryptoanalýza, která se snaží získat data bez znalosti tohoto tajemství. Kryptoanalytici vlastně ověřují kvalitu výsledků kryptografie a pomáhají tak vytvářet opravdu bezpečné šifry, které se pak používají v praktickém životě. 3.1 Symetrické šifry Symetrické šifrovací algoritmy jsou ty, které používají k zašifrování dat i jejich dešifrování stejný klíč (sdílené tajemství). Výhodou těchto algoritmů je jejich vysoká rychlost oproti algoritmům šifrujícím pomocí veřejného klíče. Velkou nevýhodou je však fakt, že komunikující strany se musí nejprve domluvit na sdíleném klíči a tento klíč nesmí být nikým odposlechnut. Díky tomu bývají v praxi méně používané, než asymetrické šifry. Často se však využívá kombinace obou druhů šifer: některá pro bezpečné předání klíče, jiná pro šifrování a jiná pro digitální podpis. šifrování zprávy m klíčem k: c = e(m, k) dešifrování zprávy m klíčem k: m = d(c, k) Algoritmy symetrického šifrování provádí většinou jednodušší matematické operace typu bitový součet, negace, nonekvivalence atd. Díky tomu jsou jednak rychlé, ale hlavně je 21

29 3.1. SYMETRICKÉ ŠIFRY možné je jednoduše implementovat hardwarově. Na některých zařízeních proto bývá hardwarová podpora šifrování, ale využití nacházejí také na různých čipových kartách, čtečkách apod. Obrázek 3.1: Symetrické šifrování Většina šifer používala délku klíče 64 bitů, což v dnešní době již není bezpečné, protože běžné počítače jsou schopny hrubou silou takto krátký klíč zjistit. Často se užívají klíče o délce 256 nebo 128 bitů. Kratší bývají užity jen k šifrování zpráv, které brzy ztrácejí informační hodnotu. Symetrické šifry se dělí do dvou základních skupin podle toho, jestli se data šifrují postupně bit po bitu, nebo jestli se šifruje ucelený blok dat. Prvním způsobem, tedy postupným zpracováním dat, pracují proudové šifry. Naproti tomu šifry blokové vezmou vždy pevný počet bitů a ten zašifrují, poslední blok se doplní náhodnými daty, které se po dešifrování zase zahodí. Obrázek 3.2: Schéma proudových a blokových šifer Blokové šifry pracují s pevným počtem bitů. Tyto bloky jsou pomocí klíče zašifrovány a výstupem je příslušná část šifrovaného textu. Některé algoritmy provádějí několikanásobné šifrování bloku dokola, aby se zvýšila bezpečnost. Blokové šifry jsou na šifrování dat v praxi využívány častěji než proudové. Mezi blokové šifry patří například algoritmy DES, AES, IDEA, Blowfish a jiné. 22

30 3.1. SYMETRICKÉ ŠIFRY Proudové šifry jsou rychlejší než blokové. Vhodnější jsou tam, kde není možné využívat buffer. Typickým příkladem je telekomunikace a jiné real-time spojení, kde není vhodné čekat na naplnění bufferu, ale je třeba data šifrovat ihned. Mezi zástupce proudových šifer patří algoritmy RC4, FISH, Helix, SEAL, WAKE a další. Proudové šifry dělíme na dvě základní skupiny: synchronní proudové šifry proudové šifry s vlastní synchronizací (asynchronní). Synchronní proudová šifra je taková, která nevyužívá k šifrování text (původní ani šifrovaný). Data jsou šifrována pomocí klíče a stavu, ve kterém se funkce nachází. Při dešifrování je proto potřeba mít stejný klíč a postupně procházet ekvivalentními stavy. Pokud se při přenosu ztratí jediný bit (nebo přibude), pak se synchronizace ztratí. Pro zachování synchronizace se proto používají další mechanizmy. Asynchronní proudové šifry využívají k šifrování i dešifrování mimo klíče i předchozích n bitů šifrovaného textu. Tím se zvyšuje bezpečnost, ale při ztrátě jednoho bitu se následujících n bitů zprávy dekóduje špatně. Po těchto n bitech se další data již dekódují opět správně DES DES (Data Encryption Standard) patří mezi nejznámější šifrovací algoritmy a patří mezi první zástupce blokových šifer. O jeho vývoj se v sedmdesátých letech postarala firma IBM. Brzy byl přijat i jako americký standard a byl využíván ve státních organizacích i soukromém sektoru. Obrázek 3.3: Princip šifrování pomocí DES K šifrování je používán klíč o délce 64 bitů, z toho je 56 bitů použito k šifrování a 8 bitů jako parita. Bloky jsou délky 64 bitů, výsledkem šifrovací funkce je i stejně dlouhý výstup. Šifrování probíhá v 16 kolech (round). Z klíče je vypočítáno šestnáct podklíčů, pro každé kolo jeden. Na vstupním text se provede počáteční permutace a pak se rozdělí na pravou 23

31 3.1. SYMETRICKÉ ŠIFRY a levou polovinu. Levá polovina je pozměněna funkcí, která má jako vstup příslušný klíč a pravou polovinou. Poté se levá a pravá polovina vymění. Toto se opakuje 16-krát. V posledním kole již neproběhne výměna stran. Nakonec se provede konečná permutace bitů. Dešifrování se provádí stejným algoritmem, pouze klíče pro každé kolo se berou v opačném pořadí. V současné době je šifra DES považována za nespolehlivou, nebot se povedlo její prolomení diferenciální i lineární kryptoanalýzou. Díky slabinám v algoritmu a příliš krátkému klíči se používá spíše její varianta Triple DES, nebo výkonnější a bezpečnější AES. Triple DES (3DES, TDES), varianta algoritmu DES, používá k šifrování tři různé klíče. Pomocí algoritmu DES zašifruje text prvním klíčem, šifrovaný text pomocí stejného algoritmu zašifruje druhým klíčem a nakonec se postup zopakuje i s třetím klíčem. Dešifrování se provádí opět trojím průchodem algoritmu DES, klíče se však použijí v opačném pořadí AES Algoritmus AES (Advanced Encryption Standard) byl vyvinut americkou vládou a v roce 2001 byl standardizován. Nahradil tak zastaralý DES. Tento algoritmus je někdy nazýván jako Rijndael po svých autorech Joan Daemenu a Vincent Rijmenu. AES pracuje s blokem délky 128 bitů, šifrovací klíč musí mít délku 128, 192 nebo 256 bitů. Šifrování probíhá nad tabulkou o rozměrech 4x4 byty a opakovaně se provádějí výpočetní kola (round), jejichž počet závisí na délce klíče. Pro každé kolo se vypočítají klíče podobným způsobem jako u DES. Nejprve se do tabulky dosadí čistý text. Pak probíhají fáze, ve kterých se postupně provedou tyto kroky: Obrázek 3.4: Postup při šifrování algoritmem AES 24

32 3.1. SYMETRICKÉ ŠIFRY AddRoundKey - pro každý byte tabulky se vypočte nová hodnota jako a ij XOR k ij, kde a jsou původní hodnoty v tabulce a k je klíč příslušného kola SubBytes - každý byte je nahrazen jiným podle použitím speciální tabulky (8-bitový S-box), což zabrání linearitě šifrovaného textu ShiftRows - všechny řádky jsou posunuty vlevo o určený počet míst (rotuje se dokola: nejlevější byte na řádku se posouvá úplně vpravo) MixColumns - každý sloupec je vynásoben pevně daným polynomem Tato šifra dosahuje velmi dobrých výsledku jak v rychlosti, tak v bezpečnosti. Jedná se o relativně nový standard, možná i proto zatím neexistuje ani teoretická možnost, jak tuto šifru zlomit. Vzhledem k tomu, že není vázána žádnými autorskými právy ani patenty, jedná se o nejpoužívanější symetrickou šifru IDEA IDEA (International Data Encryption Algorithm) je další z řady mladých šifrovacích algoritmů, které dosahují dobrých výsledků. Uveřejněna byla na začátku devadesátých let a měla nahradit nedostačující šifru DES. V současné době se pravděpodobně jedná o nejlepší symetrickou šifru. Jejímu masivnímu používání však brání fakt, že tato šifra je patentována. Zdarma je možné ji použít jen pro nekomerční účely. Algoritmus šifruje bloky velikosti 64 bitů a stejně velké bloky jsou i na výstupu. Pracuje s klíčem délky 128 bitů. Při šifrování se projde 8-krát kolem (round), což je definovaná množina operací. Pro každé kolo se vypočítá 6 zvláštních klíčů délky 16 bitů. Vstup je rozdělen do čtyř 16-ti bitových bloků. V každém kole se se vstupními bloky a různými klíči provádějí operace XOR, sčítání modulo 2 16 a násobení modulo Mísením těchto různých algebraických operací se docílí vysoké bezpečnosti. Obrázek 3.5: Diagram jednoho kola algoritmu IDEA 25

33 3.2. ŠIFRY S VEŘEJNÝM KLÍČEM 3.2 Šifry s veřejným klíčem Šifry s veřejným klíčem využívají vždy nějaké veřejné informace (klíče) k šifrování zpráv. K dešifrování je pak nutný nějaký tajný klíč. Šifrování není symetrické, protože se šifruje jiným klíčem a jinou funkcí, než se později dešifruje. Proto je šifrování s veřejným klíčem označováno i jako asymetrické šifrování. šifrování zprávy m klíčem k 1 : c = e(m, k 1 ) dešifrování zprávy m klíčem k 2 : m = d(c, k 2 ) Asymetrické šifrovací algoritmy potřebují k zašifrování dat jiný klíč, než k jejich zpětnému dešifrování. Tato šifrovací metoda je novější než symetrické šifrování a v současnosti se také mnohem více používá. K šifrování je třeba dvojice klíčů: veřejný klíč a soukromý klíč. Veřejným klíčem se data zašifrují a dešifrovat je pak lze pouze klíčem soukromým. Odesílatel zašifruje zprávu veřejným klíčem příjemce a odešle ji. Pokud se zprávy zmocní někdo jiný, nemůže ji dešifrovat, protože nezná soukromý klíč příjemce. Jediný, kdo si zprávu může přečíst, je jen skutečný příjemce. Obrázek 3.6: Použití šifer s veřejným klíčem K tomu, aby příjemce věděl, kdo opravdu zprávu poslal, slouží digitální podpis. K digitálnímu podepisování se také používá asymetrická kryptografie. Odesílatel vytvoří kontrolní součet zprávy (hash) a svým soukromým klíčem ho zašifruje. Tím zprávu digitálně podepíše. Pokud si chce někdo ověřit odesílatele, dešifruje hash veřejným klíčem odesílatele a pokud je kontrolní součet správný, znamená to, že zprávu opravdu poslal on. Navíc to znamená, že ji cestou nikdo neupravil. Podpis může vytvořit jen ten, kdo zná soukromý klíč, tedy pravý odesílatel. Některé z požadavků na digitální podpis jsou: autenticita - musí dokazovat, kdo dokument psal 26

34 nezfalšovatelnost - nikdo nedokáže podepsat za nikoho jiného 3.2. ŠIFRY S VEŘEJNÝM KLÍČEM jednorázové použití - podpis platí pro jediný dokument, nelze ho přenášet na další dokumenty nezměnitelnost dokumentu - podepsaný dokument již nelze změnit nepopiratelnost - podpis jasně říká, že uživatel dokument skutečně napsal Problém u asymetrické kryptografie je s bezpečnou distribucí veřejného klíče. Odesílatel šifruje data klíčem příjemce, ale jeho veřejný klíč musí nějak získat. Většinou ho stáhne z internetu nebo si ho nechá poslat. To ale nejsou úplně bezpečné datové kanály a nějaký útočník mu může podstrčit svůj klíč a komunikaci odposlouchávat. Proto se místo veřejných klíčů distribuují certifikáty. Certifikát je veřejný klíč s informacemi o majiteli, platnosti atd, který je digitálně podepsán certifikační autoritou. Certifikační autorita pak ručí za správnost údajů v certifikátu. Soukromý a veřejný klíč spolu samozřejmě musí matematicky souviset, ale je nesmírně důležité, aby z veřejného klíče nebylo možné zjistit klíč soukromý. Celá bezpečnost dat závisí na dobrém šifrovacím algoritmu a na dobrém klíči. Jednou z důležitých věcí je, aby oba klíče měli dostatečnou délku a jejich zjištění hrubou silou se tak pohybovalo v řádech desítek let nebo i víc. Šifrovací funkce jsou jednocestné, což znamená, že z dat a klíče se vypočítají zašifrovaná data, která nelze touto funkcí a klíčem dešifrovat. V současné době je asymetrická kryptografie nejpoužívanější, protože není potřeba předávat sdílený klíč bezpečnou cestou, kterou nikdo nemůže odposlechnout. Veřejný klíč příjemce může znát kdokoliv. Je potřeba mít pouze jistotu, že odesílatel šifruje data správným klíčem, tedy klíčem příjemce. To sice není úplně triviální problém, ale existují způsoby, jak toho docílit. A pak si obě strany můžou být jisté, že jejich sdílená data nikdo nezná. K šifrování dat se nejčastěji používá RSA algoritmus, nejčastěji využíván bývá také k digitálnímu podpisu. Není ale zdaleka jediný. K výměně sdíleného tajemství pro následnou symetrickou kryptografii se hojně využívá Diffie-Hellman. Jeho modifikace, algoritmus El- Gamal, je zase velmi rychlý, ale zdvojnásobuje šifrovanou zprávu. Velký rozmach lze očekávat algoritmů nad eliptickou křivkou, které vykazují výborné výsledky Diffie-Hellman Tento algoritmus je jeden z nejstarších, ale stále jeden z nejbezpečnějších algoritmů pro výměnu sdíleného tajemství nebo klíče. V praxi se nikdy klíč nebo heslo nepošlou fyzicky po síti, ale obě dvě komunikující strany se přitom domluví na sdíleném klíči. V roce 1976 tento algoritmus publikoval Whitfield Diffie a Martin Hellman. Jeho bezpečnost je založena na problému výpočtu diskrétního logaritmu. Díky jednoduchým výpočetním operacím je algoritmus velmi rychlý. Ke komunikaci je třeba dvou, třeba i veřejně známých, čísel p a q. Odesílatel si zvolí číslo a a vypočítá A = g a mod p. Číslo A pošle adresátovi. Ten si zvolí číslo b a vypočte B = g b mod p, poté pošle odesílateli číslo B. Společný klíč si oba spočítají pomocí vzorce K = 27

35 3.2. ŠIFRY S VEŘEJNÝM KLÍČEM Obrázek 3.7: Bezpečná výměna klíče algoritmem Diffie-Hellman B a mod p respektive K = A b mod p. Společné sdílené tajemství K pak mohou použít k další komunikaci ElGamal ElGamal je asymetrický algoritmus, který se využívá pro šifrování, ale i pro digitální podpis. Na rozdíl od RSA je však funkce pro digitální podpis úplně odlišná od funkce pro šifrování. Obě funkce jsou postaveny na základě problému vyřešit diskrétní algoritmus, ale jinak je toho mnoho nespojuje. ElGamal vychází z algoritmu Diffie-Hellman. Problémem tohoto šifrovacího algoritmu je skutečnost, že výsledná šifrovaná data jsou dvakrát delší, než je původní text. U digitálního podpisu to tolik nevadí, ale u objemných dat je to velká nevýhoda. ElGamal je také výpočetně náročnější než například RSA algoritmus. Ke generování soukromého a veřejného klíče slouží tři čísla. Dvě veřejně známá čísla p a q, kde p je prvočíslo a obě jsou co nejvyššího řádu. Dalším čísle je náhodně zvolené číslo a, které je menší než p. Pak je nutné spočítat r = q a mod p. Veřejný klíč je trojice (p; q; r), soukromým klíčem je pouze číslo a. Komunikace mezi odesílatelem a příjemcem vypadá následovně: 1. odesílatel (A) si zjistí veřejný klíč (p; q; r) příjemce (B) 2. zpráva m musí být menší než p 3. A si zvolí náhodné číslo k, menší než p 4. A spočte čísla x = q k mod p a y = mr k mod p 5. A pošle B dvojici (x; y) 6. B spočte z = x p-1-a mod p 7. nakonec B dešifruje data: m = zy mod p 28

36 3.2. ŠIFRY S VEŘEJNÝM KLÍČEM Jak je vidět z předchozího postupu, šifrování textu vyžaduje náhodné číslo k. Toto číslo je voleno náhodně, vždy znovu, takže při šifrování stejného textu několikrát za sebou, budou data posílaná příjemci pokaždé jiná. Přesto je lze vždy převést na původní (stejný) text RSA Šifrovací algoritmus RSA je jeden z nejznámějších, jeho využití je vhodné k šifrování dat i k elektronickému podpisu. Jméno algoritmu pochází od jeho tvůrců Rona Rivesta, Adi Shamira a Leonarda Adlemana, kteří jej v roce 1977 prezentovali. Bezpečnost tohoto algoritmu je postavena na problému faktorizace vysokých čísel. Příjemce zpráv (A) vygeneruje veřejný a soukromý klíč následujícím způsobem: 1. zvolí dvě náhodná velká prvočísla p a q 2. spočítá n = pq 3. vypočte hodnotu Eulerovy funkce f(n) = (p-1)(q-1) 4. zvolí číslo e menší než f(n) a nesoudělné s f(n) 5. vypočítá číslo d tak, aby platilo (de) mod f(n) 1 mod f(n) Veřejný klíč je dvojice (n; e), soukromý klíč je dvojice (n; d). Někdy se klíče počítají mírně odlišnou metodou a uchová se více čísel, která pak urychlují šifrovací funkce. Pokud chce nějaký odesílatel (B) poslat zprávu A, zjistí si jeho veřejný klíč (n; e) a data zašifruje funkcí c = m e mod n, kde m je zpráva menší než n. Následně B pošle A zašifrovanou zprávu c. A k dešifrování použije funkci m = c d mod n. K digitálnímu podpisu se užívá opačného postupu. Pokud A chce podepsat dokument m, vytvoří jeho kontrolní součet (hash) a zašifruje ho svým soukromým klíčem. Toto může kdokoliv dešifrovat veřejným klíčem, který získá od A, a ověřit si tak, že dokument m psal opravdu A. Algoritmus RSA je stále považován za bezpečný, i když se objevují teoretické možnosti, jak by se mohl v budoucnu dát rozlomit na kvantových počítačích. Prozatím však stačí, aby klíč byl velký alespoň 1024 bitů, aby jej nebylo možné současnými prostředky rozlomit. Rychlost šifrovacích funkcí je mnohem pomalejší než u symetrického algoritmu AES. Pro zvýšení bezpečnosti je u RSA používá vyplňovací schéma. Zpráva m = 0 je vždy šifrována jako 0, bez ohledu na exponent i modulus. Stejně tak je tomu i s m = 1. Vyplňovací schéma umožňuje před vlastním šifrováním zprávu m vyplnit dodatečnými hodnotami tak, aby nikdy neklesla pod bezpečnou úroveň. To zároveň stěžuje slovníkové útoky, tedy porovnávání šifrovaných dat s šifrovanými běžnými slovy Rabin Žádoucí vlastností každého šifrovacího algoritmu je jeho obtížné prolomení. O Rabinu se mluví jako o příkladu opravdu bezpečného algoritmu. Jeho bezpečnost je založena na ob- 29

37 3.3. ŠIFROVÁNÍ V JAVA ME tížnosti faktorizace, stejně jako například RSA. O algoritmu Rabin však bylo dokázáno, že jeho rozlomení hrubou silou je ekvivalentní problému faktorizace. K vygenerování dvojice klíčů je třeba vytvořit dvě náhodná velká prvočísla p a q, která jsou přibližně stejně velká. Následně se spočítá číslo n = pq. Veřejný klíč je číslo n a soukromý klíč je dvojice (p; q). Komunikace, pak probíhá následovně: 1. odesílatel (A) si zjistí veřejný klíč n příjemce(b) 2. zpráva m musí být menší než n 3. A spočte číslo c = m 2 mod n 4. A pošle B číslo c 5. B zjistí čtyři odmocniny m 1, m 2, m 3, m 4 z čísla c mod n speciálním algoritmem 6. původní práva m je jedna z m 1, m 2, m 3, m 4. B nějakým způsobem rozhodne která. Pro jednoduchost zde není uveden algoritmus pro výpočet odmocnin, který je však lehce dostupný. V posledním kroku je ale další nejasnost. Jak rozhodnout, která z odmocnin reprezentuje původní data? Řešení této otázky je ponecháno na každé konkrétní implementaci. Nejčastěji se však přidává na konec zprávy pevný počet bitů ze začátku zprávy. Správný kořen je poté ten, který má příslušných počet bitů na začátku i na konci shodný. Pokud existuje více takových kořenů, pak je c odmítnuto jako podvržené. Algoritmus Rabin je při šifrování velice rychlý, mnohem rychlejší než RSA. Dešifrování je pomalejší a je zhruba srovnatelné s dešifrováním u RSA, u obou se využívá čínská věta o zbytcích. Výrazné rozšíření algoritmu brzdí i fakt, že je třeba dalších výpočetních nákladů na vybrání správného výsledku Eliptické křivky Eliptické křivky jsou předmětem zkoumání déle než 150 let. Jejich využití v kryptografii se však zkoumá až posledních 20 let. Bezpečnost algoritmů je založena na úloze diskrétního eliptického logaritmu. Výhodou je vysoká rychlost šifrování i dešifrování oproti běžným symetrickým i asymetrickým algoritmům, také softwarové i hardwarové nároky jsou mnohem menší. Algoritmy využívající eliptické křivky se začínají prosazovat v praxi, ale zatím jen pomalu. Širšímu nasazení brání zatím slabá softwarová podpora (knihovny) a široké využívání současných, zatím bezpečnostně dostačujících, algoritmů symetrické a hlavně asymetrické kryptografie. V budoucnu se ale jistě dočkáme jejich masivního využití. 3.3 Šifrování v Java ME Šifrování v mobilních zařízeních je řešeno účelově pro ověřování podpisů, práci s certifikáty a šifrování sít ového spojení. Vše je řešeno na úrovni firmwaru nebo operačního systému. 30

38 3.3. ŠIFROVÁNÍ V JAVA ME MIDlety mají k dispozici pouze balík javax.microedition.pki, který slouží k práci s certifikáty, navíc jen pro zobrazení informací. Jakákoliv podpora pro šifrování ve specifikaci chybí. Veškeré šifrovací funkce je proto potřeba provádět v rámci vlastních knihoven, nebo knihoven třetí strany. U platformy Java ME je také třeba brát ohled na omezené zdroje i výkon. Vhodné jsou proto zejména symetrické šifry, které nevyžadují tolik systémových prostředků, ale poskytují dostatečnou bezpečnost. Asymetrické šifry pracují s velkými čísly, ale v Java ME není knihovna BigInteger, která by práci s nimi umožnila. Pokud chce programátor implementovat asymetrickou šifru, musí si tuto knihovnu dopsat. 31

39 Kapitola 4 Vývoj aplikace Sybek Následující kapitola je věnována postupům při vývoji aplikace Sybek, která umožňuje zasílání šifrovaných zpráv mezi mobilními zařízeními. Aplikace je určená pro mobilní zařízení, které umožňují běh Java ME aplikací a obsahují konfiguraci CLDC 1.1 a profil MIDP verze alespoň Požadavky na systém Spojení mezi dvěma mobilními telefony probíhá většinou šifrovaně. Šifruje se spojení mezi vysílačem a telefonem volajícího, interní přenos sítí i spojení mezi telefonem příjemce a jiným vysílačem. Ačkoliv se spojení zdá bezpečné, je možné jej vcelku jednoduše odposlouchávat. Každý člověk tak ztrácí jistotu svého soukromí. Je tedy potřeba vyvinou aplikaci, která by dokázala zajistit bezpečnou komunikaci mezi mobilními zařízeními. Hlavní funkční požadavky na aplikaci: musí dokázat šifrovat zprávy musí odesílat i přijímat zprávy musí umět pracovat se zprávami (vytvářet, ukládat, mazat, upravovat a odesílat) musí umožňovat uložení kontaktů (telefonních čísel se jmény) měla by komunikovat i přes bluetooth mohla by pracovat se zprávami typu MMS mohla by šifrovat i hovory Hlavní nefunkční požadavky na aplikaci: musí být přenositelná musí být bezpečná měla by být rychlá měla by mít intuitivní ovládání 32

40 4.2. ANALÝZA SYTÉMU Podle zadaných požadavků lze nyní sestrojit diagram případů užití, který by měl vystihovat chování systému: pozn.: Detailní popis případů užití je v příloze A. 4.2 Analýza sytému Podle požadavků je nutné, aby systém evidoval zprávy, kontakty a nastavení. K jejich uložení je možné využít bud RMS nebo souborový systém v mobilním zařízení. Ukládání a čtení dat proto musí zapouzdřovat jedna třída, aby bylo možné jednoduše zvolit mezi místem ukládání. Aby byla třída co nejvíce univerzální, bude vhodné k předávání dat použít nějaké univerzální rozhraní. Aby byla aplikace uživatelsky přívětivá, měl by uživatel mít možnost měnit její chování prostřednictvím nastavení. Nastavení bude koncentrováno v jedné, pravděpodobně statické, třídě. Ta bude implementovat rozhraní, které ji umožní ukládání do databáze. K práci s kontakty bude sloužit další třída, která bude obstarávat základní manipulaci s kontaktem, tedy jeho vytvoření, uložení do databáze, nastavení nových hodnot atd. Pro práci se zprávami je opět třeba vytvořit třídu, která bude zajišt ovat základní práci se 33

41 4.2. ANALÝZA SYTÉMU zprávou. Také musí implementovat rozhraní, které umožní ukládat zprávu. Navíc je třeba, aby bylo možné zprávy šifrovat. Tuto funkcionalitu je vhodné přesunout do další třídy, která může být využívána. Posílání dat je vhodné také vyčlenit, nebot data mohou být poslána více způsoby (jako SMS nebo přes bluetooth). Příjem dat musí obstarávat další třída, jejíž funkce bude volána mobilním zařízením při příchodu zprávy. Podle předchozích předpokladů by mohl analytický diagram tříd vypadat přibližně takto: Význam a funkce jednotlivých tříd: Menu je třída, která se stará o zobrazení funkcí a slouží jako vstupní i výstupní bod aplikace. Message reprezentuje zprávu a poskytuje veškerou funkcionalitu, která se zpráv týká. Contact reprezentuje kontakt v lokálním adresáři aplikace. Umožňuje provádění veškerých funkcí nad kontaktem. Settings slouží k poskytování aktuálního nastavení aplikace. Uchovává aktuální stav jednotlivých položek, umožňuje jejich změnu a stará se o uložení. 34

42 4.3. NÁVRH SYSTÉMU DBItem je rozhraní, které zajišt uje univerzálnost ukládání položek do databáze. Database se stará o ukládání dat, umožňuje jejich změny, čtení i mazání. Sender zajišt uje odeslání dat zvoleným kanálem. Receiver slouží k příjmu zpráv, které přijdou na mobilní zařízení. CryptoUtils je třída, která se stará o šifrování dat. 4.3 Návrh systému Podle předchozích požadavků je nutné vytvořit aplikaci s intuitivním ovládáním. Funkce by měly být přehledně seskupeny a měly by nabízet maximální možnou funkcionalitu, kterou u takové aplikace lze očekávat. Návrh hlavních funkcí systému, který nastiňuje základní funkcionalitu i uživatelské prostředí, je znázorněn na následujících stavových diagramech. Obrázek 4.1: Stavový diagram podsystému pro práci se zprávami 35

43 4.4. IMPLEMENTACE SYSTÉMU Obrázek 4.2: Stavový diagram podsystému pro práci s kontakty 4.4 Implementace systému Většina původních požadavků na systém se podařila implementovat a výsledkem dlouhého vývoje je aplikace Sybek. Jedná se o aplikaci určenou pro mobilní zařízení s platformou Java ME. Ke své činnosti vyžaduje konfiguraci CLDC 1.1, profil MIDP 2.0 a některé rozšiřující balíčky, které však nejsou nutné pro základní funkčnost aplikace, ale díky nim je možné například komunikovat přes bluetooth. Následující obrázek zobrazuje diagram nasazení systému: Aplikace Sybek dokáže posílat textové zprávy v šifrované podobě jako běžnou SMS i přes bluetooth spojení. K šifrování je využívána kvalitní implementace nejpoužívanějších 36

44 4.4. IMPLEMENTACE SYSTÉMU algoritmů. Aplikace dokáže pracovat se zprávami, vlastními kontakty i souborovým systémem telefonu. Vývoj aplikace probíhal metodou prototypování. Pro implementaci každého standardu bylo nutné vytvořit jednoduchý prototyp a otestovat jej na mobilních telefonech i v emulátoru. Teprve pak byly tyto funkce začleněny do aplikace. Tím se také zjednodušilo závěrečné testování celé aplikace Uživatelské prostředí Pro zobrazování uživatelského prostředí bylo záměrně zvoleno vysokoúrovňové API, aby byla zaručena maximální přenositelnost. U starších telefonů by navíc složitá grafika mohla zbytečně zpomalovat celou aplikaci. V implementaci jsou tak využity pouze standardní komponenty zobrazující grafické uživatelské prostředí. (a) (b) (c) Obrázek 4.3: Ukázky menu na různých emulátorech Menu aplikace je realizováno jednoduchým seznamem akcí, který je zobrazen třídou List. Pohyb v něm je možný pomocí standardního joysticku na mobilním telefonu. K navigaci je možné využívat i speciální tlačítka, které telefon poskytuje, například zvláštní tlačítko pro akci zpět. Obrazovky s kombinovaným vstupem jsou zobrazeny pomocí třídy Form. Ta zobrazuje textová políčka (telefonní číslo, heslo, jméno) nebo výběr hodnoty (zaškrtnutí více, vybrání jedné). K editaci textu je použita třída TextBox, která mimo očekávaného prostoru pro psaní nabízí i další funkce. Jsou jimi akce, které nabízí konkrétní telefon, takže jejich nabídka nebývá vždy stejná. Většinou se jedná o zapínání a vypínání prediktivního psaní, vkládání speciálních symbolů, smajlíků atd. Při psaní zprávy tak máte k dispozici téměř všechny funkce, jako u psaní SMS přímo v telefonu. 37

45 4.4. IMPLEMENTACE SYSTÉMU Ukládání dat O ukládání veškerých dat i uživatelského nastavení se stará třída DatabaseReaderWriter. Její hlavní účel je odstínit práci s úložným prostorem od ostatní funkcionality aplikace. S daty se pracuje prostřednictvím rozhraní DatabaseItem, což zajišt uje univerzální použití této třídy. Hlavní účel návrhu tohoto řešení je možnost jednoduše měnit datové úložiště a to i za běhu aplikace. K ukládání dat se v současné implementaci využívá RMS, jehož kapacita může být značně omezená. Její velikost záleží na konkrétním telefonu a výrobci. Dnes je u většiny zařízení sdílená s pamětí telefonu, takže její velikost bývá 5 MB a více. Toto však není zaručeno a telefon může mít velikost RMS například jen 1 MB. Pro tento případ je vhodné mít možnost ukládat data do souborového systému nebo na pamět ovou kartu, kde je místa dostatek. Z časových důvodů však tato funkcionalita v současné verzi nebyla implementována, vždy je použito RMS, ale aplikace je připravena na jednoduché přidání této funkce. V aplikaci se ukládají tři různé typy objektů: zprávy, kontakty a nastavení. Třídy, které zajišt ují ukládání těchto objektů, musí implementovat rozhraní DatabaseItem. Ukládaná data jsou reprezentována polem bytů. K převodům souží metody tobytearray() a parse(byte[]). Každý objekt má své jedinečné číslo v rámci dané databáze. Toto číslo je přiděleno při ukládání dat, objektu je nastaveno pomocí metody setdatabaseid(int). Rozhraní ještě definuje metody pro porovnávání, řazení a jiné Textové zprávy Aby se aplikace spustila po příchodu zprávy, je nutné ji instalovat. Instalace se provádí standardní postupem popsaným výše. Tím si aplikace zarezervuje příchozí zprávy na portu Číslo portu je zapsáno v deskriptoru aplikace, v případě kolize s jinou aplikací je možné číslo běžným editorem změnit a aplikaci přeinstalovat. Příchozí zprávy obsluhuje třída SMSReceiver. Zpráva je nejprve přečtena z otevřeného spojení, které aplikaci předá aplikační manažer. Pokud je přenos dat úspěšný, zpráva se uloží do databáze a uživatel je informován o přijetí nové SMS. Všechny zprávy jsou uloženy v jedné databázi a pomocí příznaku je u každé rozlišeno, zda je přijatá, odeslaná nebo v archívu. Navíc je možné rozlišit přečtenou a nepřečtenou zprávu nebo odeslanou a neodeslanou. Podle příznaku je uživatel vidí v příslušné podsložce a s určitou ikonou. Každá zpráva se dá samozřejmě editovat, číst, smazat, přesunout atd. Některé funkce záleží i na nastaveném příznaku. Při psaní nové zprávy je uživateli mimo standardních funkcí nabídnuta možnost zhuštění a rozpuštění textu. Jedná se o funkce, které již nabízí několik mobilních telefonů při psaní zpráv, ale nejsou nijak běžné. Funkce z textu vypustí všechny mezery a počáteční písmeno každého slova převede na velké. Tak je text člověku dobře čitelný, ale zpráva je o 10%-20% kratší. Druhá funkce plní opačnou funkci, tedy text takového formátu převádí zpět na běžný text. Jinou funkcí je možné do textu vložit údaje z lokálního adresáře aplikace. 38

46 4.4. IMPLEMENTACE SYSTÉMU (a) (b) (c) Obrázek 4.4: Práce se zprávami - složky, psaní textu a volby odeslání Uživatel si vybere kontakt a údaje které chce do textu vložit (například jen telefonní číslo a jméno). Další užitečnou funkcí je možnost komprimace textové zprávy. Takto komprimovaná zpráva není čitelná jako obyčejná SMS, ale binární zpráva. Kompresi provádí třída SMSCompressor, která jej převede do binární podoby. Běžný text tak dokáže zmenšit na 70%-80% původní velikosti (měřeno v binární podobě). Přesná účinnost komprese záleží na konkrétním textu, použití diakritiky a speciálních symbolů. Zprávu je samozřejmě možné před odesláním zašifrovat. Pokud uživatel vyhledá telefonní číslo příjemce v adresáři aplikace, použije se automaticky heslo pro tento kontakt. Jinak je nutné zadat heslo ručně, nebo zprávu nešifrovat. K odesílání zpráv slouží třída SMSSender, pro přenos přes bluetooth je to BlueToothDataSender. Tyto jednoduché třídy se už starají jen o odeslání pole bytů a zobrazí informace uživateli o úspěchu či neúspěchu. Pokud uživatel zprávu zašifruje, použije kompresi nebo obojí, pak je tato zpráva odeslána jako datová (binární) a příjemce musí mít nainstalován Sybek, aby si mohl zprávu zobrazit. Zprávu v čisté podobě je možné poslat na jakýkoliv mobilní telefon a ten by ji měl standardně přijmout a zobrazit Lokální adresář Aplikace uživateli umožňuje, aby si uložil vlastní kontakty. U každého kontaktu je evidováno jméno, telefon, ová adresa a případně heslo. Heslo může být sdílené tajemství pro symetrickou šifru nebo veřejný klíč daného příjemce určený k asymetrickému šifrování. Kontakty lze samozřejmě prohlížet, editovat i mazat. Očekávanou funkcí, která ovšem v aplikaci není implementována, je možnost pracovat s kontakty z adresáře mobilního telefonu. V dnešní době již většina telefonů podporuje i ukládání hesel do adresáře, proto se zdá být interní adresář aplikace naprosto zbytečný. Existují však dva důvody jeho existence. Patrně nikdo si nebudete šifrovaně dopisovat přes 39

47 4.4. IMPLEMENTACE SYSTÉMU Sybek s desítkami lidí, proto zadání několika čísel není takový problém. Navíc je tak možné používat soukromá čísla, která nejsou uložena v adresáři telefonu. Ale hlavní důvod je jiný. K přístupu do adresáře je nutný rozšiřující balíček PDA Optional Packages (JSR-75), který hodně telefonů nepodporuje. Navíc telefony, které jej implementují, neposkytují přístup do adresáře nedůvěryhodným MIDletům. Aplikace by tedy musela být ještě digitálně podepsaná. Vzhledem k tomu, že na žádném z testovacích telefonů se nepodařilo přistoupit do adresáře, byla funkce raději vypuštěna, nebot ji nebylo možné vůbec otestovat Bluetooth komunikace Spojení přes bluetooth zajišt uje třída BlueToothDriver, která je jádrem veškeré komunikace. Metoda activatebt() slouží k základní inicializaci bluetooth v aplikaci, mobilní telefon tak také pozná, že má zapnout bluetooth, pokud je vypnuté. Pro sít ové spojení je nutné nejprve vyhledat okolní aktivní zařízení, zjistit jejich adresy a nezbytné informace. K tomu slouží metoda finddevices(), která spustí prohledávání okolí. Adresy zařízení, které jsou dostupné a připraveny ke spojení, poskytuje metoda getfoundeddevices(). Kdykoliv je také možné zjistit aktivní zařízení z předchozího hledání pomocí metody getcached- Devices(). Každý mobilní telefon má navíc seznam uložených zařízení, které si pamatuje. Ten je dostupný voláním metody getpreknowndevices(). (a) (b) Obrázek 4.5: Práce s bluetooth - nastavení a vyhledávání okolních zařízení Aby bylo možné poslat zprávu mezi dvěma aplikacemi na různých zařízeních, je nutné v Sybeku spustit službu, která bude čekat na vzdálené spojení přes bluetooth. Vytvoření bluetooth služby a její nastavení se provádí metodami createservice(), setserviceattribute(), runservicelistening() a stopservice(). V případě, že se nějaké vzdálené zařízení připojí, vyvolá se příslušná metoda posluchače služby. Pak mohou zařízení obousměrně komunikovat přes běžný datový proud. Třída BlueToothDriver poskytuje i metody pro vyhledávání aktivních služeb na každém zařízení. Pokud uživatel posílá zprávu, aplikace vyhledá aktivní zařízení, která mají spuštěnou službu pro příjem zpráv (speciální služba Sybeku), zobrazí je uživateli a ten si 40