012345

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

Šifrování komunikace mobilních zaˇrízení pomocí Java ME D IPLOMOVÁ PRÁCE

Ondˇrej Životský

Brno, jaro 2007

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

Vedoucí práce: Mgr. Jan Pavloviˇc ii

Podˇekování Chtˇel bych podˇekovat svému vedoucímu práce Mgr. Janu Pavloviˇcovi za jeho vedení, námˇety i kritiku. Rád bych také podˇekoval kamarádum, ˚ kteˇrí mi pomohli testovat aplikace na svém mobilním telefonu. Dík patˇrí také všem, kteˇrí mˇe jakkoliv pomohli, poradili nebo jen povzbudili.

iii

Shrnutí Cílem diplomové práce bylo prozkoumat možnosti vývoje aplikací pro platformu Java ME a vytvoˇrit aplikaci pro mobilní zaˇrízení, která by umožnovala ˇ šifrovat komunikaci. V této práci je detailnˇeji popsána platforma Java ME, její vlastnosti a využití. Vˇetší pozornost je vˇenována knihovnám urˇceným pro mobilní telefony. Nemalá cˇ ást je vˇenována i rozboru šifrovacích algoritmu˚ a možnostem jejich použití v Java ME. V práci je popsán i vývoj aplikace umožnující ˇ šifrování, která je souˇcástí této diplomové práce.

iv

Klíˇcová slova Java ME, MIDP, CLDC, MIDlet, Sybek, šifrování

v

Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Java Platform, Micro Edition (Java ME) . . . . . . . . 2.1 Konfigurace platformy Java ME . . . . . . . . . . 2.1.1 Connected Limited Device Configuration 2.1.2 Connected Device Configuration . . . . . 2.2 Profily platformy Java ME . . . . . . . . . . . . . 2.2.1 Mobile Information Device Profile . . . . 2.2.2 Information Module Profile . . . . . . . . 2.2.3 Foundation Profile . . . . . . . . . . . . . 2.2.4 Personal Basis Profile . . . . . . . . . . . . 2.2.5 Personal Profile . . . . . . . . . . . . . . . 2.3 Rozšiˇrující balíˇcky . . . . . . . . . . . . . . . . . . 2.4 MIDlet . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Životní cyklus MIDletu . . . . . . . . . . 2.4.2 Základní funkce . . . . . . . . . . . . . . . 2.4.3 Record Management System . . . . . . . 2.4.4 Uživatelské prostˇredí MIDletu . . . . . . 2.4.5 Sít’ová komunikace . . . . . . . . . . . . . 2.4.6 Bezpeˇcnost . . . . . . . . . . . . . . . . . . 2.4.7 Instalace . . . . . . . . . . . . . . . . . . . 2.4.8 Chystané novinky v MIDP 3.0 . . . . . . 2.5 Java APIs for Bluetooth . . . . . . . . . . . . . . . 2.5.1 Pruzkum ˚ okolí . . . . . . . . . . . . . . . 2.5.2 Komunikace . . . . . . . . . . . . . . . . . 2.5.3 Správa zaˇrízení . . . . . . . . . . . . . . . 3 Šifrování . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Symetrické šifry . . . . . . . . . . . . . . . . . . . 3.1.1 DES . . . . . . . . . . . . . . . . . . . . . . 3.1.2 AES . . . . . . . . . . . . . . . . . . . . . . 3.1.3 IDEA . . . . . . . . . . . . . . . . . . . . . 3.2 Šifry s veˇrejným klíˇcem . . . . . . . . . . . . . . . 3.2.1 Diffie-Hellman . . . . . . . . . . . . . . . 3.2.2 ElGamal . . . . . . . . . . . . . . . . . . . 3.2.3 RSA . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Rabin . . . . . . . . . . . . . . . . . . . . . 3.2.5 Eliptické kˇrivky . . . . . . . . . . . . . . . 3.3 Šifrování v Java ME . . . . . . . . . . . . . . . . . 4 Vývoj aplikace Sybek . . . . . . . . . . . . . . . . . . 4.1 Požadavky na systém . . . . . . . . . . . . . . . . 4.2 Analýza sytému . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 3 4 4 5 5 6 7 7 7 8 8 9 11 12 12 13 15 16 17 18 18 19 19 20 21 21 23 24 25 26 27 28 29 29 30 30 32 32 33 vi

4.3 4.4

Návrh systému . . . . . . . . . Implementace systému . . . . . 4.4.1 Uživatelské prostˇredí . . 4.4.2 Ukládání dat . . . . . . 4.4.3 Textové zprávy . . . . . 4.4.4 Lokální adresáˇr . . . . . 4.4.5 Bluetooth komunikace . 4.4.6 Šifrování dat . . . . . . . 4.4.7 Nastavení a další funkce 4.5 Testování . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . A Popis pˇrípadu˚ užití . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35 36 37 38 38 39 40 41 41 42 43 44 45

vii

Kapitola 1

Úvod Pro vˇetšinu lidí dnes patˇrí mobilní telefon mezi zaˇrízení, bez kterých se lze jen tˇežko obejít. Bˇežnˇe se s ním mužeme ˚ setkat u malých dˇetí ve škole, u spolupracovníku˚ i u senioru. ˚ S rostoucí popularitou tohoto zaˇrí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ˇehu aplikací, her a multimédií. Mobilní telefon se stává duležitou ˚ souˇcástí každého cˇ lovˇeka. Nárust ˚ popularity a možnosti využití však pˇrináší obavy z útoku˚ a krádeží. Telefon cˇ asto ukrývá duležitá ˚ data a citlivé informace. Pˇredávání tˇechto informací však není bezpeˇcné, nebot’ kdokoliv muže ˚ celkem jednoduše bezdrátovou komunikaci odposlouchávat. Ale každý cˇ lovˇek má pˇrece právo na své soukromí. Po nezabezpeˇcené síti je potˇreba posílat data, která by nemˇela být pˇrístupná tˇretí osobˇe. Pro vˇetšinu lidí se stalo normální, že pˇristupují na webové stránky nebo k emailum ˚ prostˇrednictvím šifrovaných spojení. Ve svˇetˇe mobilních telefonu˚ se tato možnost zaˇcí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ˇreba využít nˇejaké aplikace, která nám umožní zachování soukromí i bezpeˇcnosti. Bohužel v souˇcasné dobˇe žádná takové aplikace není zdarma k dispozici. Proto by bylo dobré, kdyby existovala alternativa k draze placeným aplikacím, ale pˇritom poskytovala stejnou funkˇcnost a bezpeˇcnost. A tento úkol byl motivací pro moji diplomovou práci. Prakticky na všech mobilních telefonech, které pˇricházejí na trh, je v souˇcasné dobˇe podpora Java ME aplikací. Z tohoto hlediska se tedy jedná se o ideální platformu pro vývoj aplikací urˇcených pro mobilní telefony. Kvuli ˚ svému univerzálnímu rozhraní a hlavnˇe kvuli ˚ požadavkum ˚ na bezpeˇcnost má však urˇcitá omezení. Není tedy možné využít veškeré funkce a možnosti, které mobilní telefon poskytuje uživateli. Vývojáˇr se musí spokojit pouze se základními funkcemi a pˇrípadnˇe s nˇekolika rozšiˇrujícími balíˇcky. Vývoj aplikací, které rˇ ídí nebo obsluhují základní funkce telefonu, je tedy znaˇcnˇe omezen. A nˇekteré funkce nelze pomocí Java ME ovládat vubec. ˚ Vedle Java ME platformy bývají v souˇcasných výkonných telefonech i operaˇcní systémy Symbian, Windows Mobile nebo jiné. Operaˇcní systém dává vývojáˇri oproti Javˇe vˇetší svobodu. Aplikace mají pˇrístup do telefonu a mohou využívat mnohem více jeho funkcí. Mohou upravovat nastavení systému, pˇristupovat k datum, ˚ službám atd. Mobilní telefony však zatím nemají podporu pro více operaˇcních systému, ˚ takže poˇrízením telefonu si také zvolíte operaˇcní systém, který budete používat. Ale aplikace napsané pro urˇcitý operaˇcní sys1

1. Ú VOD tém nejsou pˇrenositelné, 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ˇcní systém, nebo jestli vubec ˚ nˇejaký mají. Následující kapitola této práce se proto zabývá platformou Java ME. Je v ní popsána struktura platformy, její cˇ lenˇení i vazby k ostatním technologiím. V jednotlivých kapitolách jsou podrobnˇeji popsány její vlastnosti a knihovny, které nabízí. Pro lepší pochopení je vˇetšina informací doplnˇena krátkým pˇríkladem kódu, který demonstruje praktické použití. Další kapitola je vˇenována šifrování. Blíže se v ní popisuje dˇelení šifer, jejich spolehlivost, využitelnost a základní principy algoritmu. ˚ Seznámení s konkrétními šiframi a jejich vlastnostmi pomáhá pochopit volbu šifrovacích algoritmu˚ v aplikaci, která je souˇcástí této práce. ˇ Ctvrtá kapitola se zabývá vývojem aplikace Sybek. Jednotlivé podkapitoly odrážejí postup pˇri vývoji. Pomocí UML diagramu˚ je zde zobrazen systém, jeho chování a struktury. Podrobnˇeji se vˇenuje implementaˇcním detailum ˚ aplikace. Závˇer kapitoly je vˇenován testování.

2

Kapitola 2

Java Platform, Micro Edition (Java ME) Java Platform, Micro Edition (nebo zkrácenˇe Java ME) je soubor technologií a specifikací, který umožnuje ˇ vytvoˇrit prostˇredí pro bˇeh aplikací napsaných v jazyce Java i na malých zaˇrízeních s omezenými prostˇredky. Poskytuje jednoduché a univerzální rozhraní pro ovládání nebo rˇ ízení pˇrístroju˚ od ruzných ˚ výrobcu. ˚ Její využití je vidˇet zejména v mobilních telefonech a kapesních poˇcítaˇcích (PDA), ale používá se i v jiných zaˇrízení jako je televizní settop box nebo tiskárna. Díky univerzálnímu rozhraní jsou aplikace napsané pro platformu Java ME vysoce pˇrenositelné a použitelné na zaˇrízení od témˇerˇ jakéhokoliv výrobce. Následující obrázek zobrazuje pˇrehled Java ME technologií a jejich souvislosti s technologiemi celé Javy1 :

1. Zdroj: Sun Microsystems, Inc., http://java.sun.com/javame/technology

3

2.1. KONFIGURACE PLATFORMY JAVA ME Celá technologie Java ME je postavena na 3 základních elementech: •

konfigurace - poskytuje nejzákladnˇejší knihovny a možnosti virtuálního stroje pro velké množství zaˇrízení

•

profily - soubor API, který je specifický pro menší množinu zaˇrízení

•

volitelné balíˇcky - soubor API, které jsou specifické pro konkrétní technologie nebo zaˇrízení

2.1

Konfigurace platformy Java ME

Konfigurací se v Java ME rozumí specifikace softwarového vybavení pro urˇcitou skupinu zaˇrízení. Tyto skupiny jsou urˇceny podle hardwarového vybavení (velikost pamˇeti, rychlost procesoru, vlastností displeje, ...). Každá konfigurace obsahuje specifikaci virtuálního stroje, základních knihoven, tˇrí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ˇcasnosti existují pro Java ME dvˇe základní konfigurace. Pro menší zaˇrízení typu mobilní telefon je urˇcena Connected Limited Device Configuration (CLDC), pro výkonnˇejší zaˇrízení typu smartphone je urˇcena Connected Device Configuration (CDC). 2.1.1 Connected Limited Device Configuration Connected Limited Device Configuration (CLDC) je zamˇerˇ ená na malá zaˇrí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ˇcnost. Tato konfigurace je urˇcená pro zaˇrízení s následující charakteristikou: •

160 KB až 512 KB celkové pamˇeti pro platformu Java (128 KB energeticky nezávislé pamˇeti pro virtuální stroj a knihovny CLDC, minimálnˇe 32 KB energeticky závislé pamˇeti pro bˇeh aplikací)

•

16-bitový nebo 32-bitový procesor

•

napájení z baterie, nízká spotˇreba energie

•

pˇripojení k nˇejaké síti, cˇ asto bezdrátovˇe, nespolehlivˇe a s omezenou šíˇrkou pásma (9600 b/s i ménˇe)

Tato konfigurace je používána hlavnˇe v mobilních telefonech, pagerech a PDA. Implementací virtuálního stroje pro CLDC je takzvaný Kilobyte Virtual Machine (KVM). Vzhledem k omezeným zdrojum ˚ nepodporuje KVM práci s pohyblivou rˇ ádovou cˇ árkou, finalizaci, plnou obsluhu chyb (error handling), Java Native Interface (JNI), skupiny vláken a démonická 4

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ˇení, 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ˇcnostní model zvaný sendbox. To znamená, že aplikace je spuštˇena v uzavˇreném prostˇredí a mimo vlastních knihoven muže ˚ využívat pouze API definované konfigurací, profily a API podporované zaˇrízením. Aplikace tedy nemá pˇrístup nikam, kam to virtuální stroj nepovolí a neumožní. 2.1.2 Connected Device Configuration Connected Device Configuration (CDC) je urˇcená pro výkonná mobilní zaˇrízení s velkou pamˇetí a výkonem, která zvládnou bˇeh plného virtuálního stroje Javy. CDC je podmnožinou Java SE, která obsahuje témˇerˇ 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ˇrízeních, která jsou charakteristická tˇemito vlastnostmi: •

minimálnˇe 512 KB pamˇeti ROM, minimálnˇe 256 KB pamˇeti RAM

•

32-bitový procesor

•

pˇripojení k nˇejaké 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ˇrestože tyto zarˇ ízení musí zvládnou bˇeh standardní JVM, bývá na nich implementace virtuálního stroje uzpusobená ˚ jejich výkonu a možnostem. Implementace takového stroje bývá oznaˇcována jako Compact Virtual Machine (CVM). CVM se svými vlastnostmi a funkcemi pˇríliš neliší od bˇežného virtuálního stroje pro Java SE. Pro obzvláštˇe výkonná mobilní zaˇrízení existuje i HotSpot virtuální stroj, který již umožnuje ˇ kompilaci a optimalizaci aplikace za bˇehu.

2.2

Profily platformy Java ME

Profil doplnuje ˇ konfiguraci zaˇrízení o další knihovny, které zpˇrístupnují ˇ zdroje specifické pro užší a konkrétnˇejší množinu zaˇrízení. Profil specifikuje napˇríklad uživatelské rozhraní, ukládání dat, pˇrístup ke zdrojum ˚ atd. Obˇe používané konfigurace mají své vlastní profily, které jsou na nich postavené: •

nejznámˇejší profily pro CLDC konfiguraci –

Mobile Information Device Profile (MIDP)

–

Information Module Profile (IMP) 5

2.2. PROFILY PLATFORMY JAVA ME – •

Digital Set Top Box Profile - "On Ramp to OCAP"

nejznámˇejší profily pro CDC konfiguraci –

Foundation Profile (FP)

–

Personal Basis Profile (PBP)

–

Personal Profile (PP)

2.2.1 Mobile Information Device Profile Jedná se o nejˇcastˇeji používaný profil, který je urˇcen pro mobilní telefony, pagery a základní PDA. Je založen na konfiguraci CLDC. Stále poˇcítá s prací s omezenou energií, sítí, pamˇetí, výkonem i malým displejem. MIDP je urˇcen jak pro zaˇrízením s operaˇcním systémem, se soubˇežným zpracováním více úloh a souborovým systémem, tak pro zaˇrízení s jednoduchým systémem s vlákny a bez souborového systému. Mobilní zaˇrízení musí mít pouze jádro schopné obsluhovat základní hardware (obsluha pˇrerušení a výjimek, plánování), musí zvládat práci se sítí, s energeticky nezávislou pamˇetí, správu aplikací, poskytovat reálný cˇ as, zapisovat do bitového displeje a cˇ íst ze vstupu (klávesnice). S pˇribývajícími vlastnostmi a možnostmi v profilu MIDP se zvyšují i požadavky na zaˇrízení, na kterých mohou být implementovány. Následující tabulka ukazuje hardwarové požadavky jednotlivých verzí:

6

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

ˇ ˇ 2.3. ROZŠI RUJÍCÍ BALÍ CKY knihovny by byla zbyteˇcná. V profilu je definován nový model aplikace zvaný Xlet, který dovoluje mimo jiné i IXC, což je vzájemná komunikaci mezi Xley bˇežícími na stejném zaˇrízení (inner-Xlet communication). PBP specifikuje nezbytné jádro knihovny java.awt pro práci s grafikou v jednom oknˇe. Je urˇcen zaˇrízením s kvalitním pˇripojením k síti, se základním grafickým výstupem, 2 MB ROM pamˇeti a 1 MB RAM pamˇeti. Puvodní ˚ PBP vycházel ze specifikace Java SE v 1.3.1, proto byl pozdˇeji nahrazen verzí 1.1, která již vychází z Java SE verze 1.4. 2.2.5 Personal Profile Personal Profile využívá CDC konfiguraci a je postaven na profilech FP a PBP. Je to množina API, která podporuje zaˇrízení s omezenými zdroji a s GUI rozhraním založeným na AWT komponentách. Profil je uzpusoben ˚ zaˇrízením s kvalitním pˇripojením k Internetu a nabízí náhradu k technologii PersonalJava. Snaží se vytvoˇrit novou generaci PersonalJava, ale soucˇ asnˇe zachovat zpˇetnou kompatibilitu. Puvodní ˚ 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ˇeti. Profil umožnuje ˇ spouštˇet aplikace typu Xlet, ale i klasických programu˚ s metodou public static void main(String[]). Novˇe je pˇridána i podpora webových appletu. ˚

2.3

Rozšiˇrující balíˇcky

Rozšiˇrující balíˇcky (optional packages) obohacují funkcionalitu konfigurací a profilu˚ platformy Java ME o knihovny, které jsou typické pro nˇejakou skupinu zaˇrízení, ale tyto funkce nemusí být nutnˇe podporovány na všech tˇechto zaˇrízeních. Balíˇcky jsou modulární, proto muže ˚ výrobce implementovat jen ty, které uzná za vhodné. Typickým pˇríkladem rozšiˇrujícího balíˇcku je napˇríklad Location API, které poskytuje aplikacím funkce pro zjišt’ování aktuální fyzické pozice mobilního zaˇrízení. Je urˇcen zaˇrízením s konfigurací CLDC i CDC, ale záleží pouze na výrobci, zda chce tuto funkˇcnost implementovat. Nejznámˇejší rozšiˇrující balíˇcky jsou: •

Mobile Media API (ovládání zvuku, ˚ hudby a hlasitosti, generování jednoduchých tónu) ˚

•

Wireless Messaging API (odesílání, pˇríjem a práce se zprávami typu SMS, MMS, CBS a USSD)

•

Java APIs for Bluetooth (umožnuje ˇ spojení pˇres bluetooth, podpora protokolu: ˚ RFCOMM, OBEX a Service Discovery)

•

Mobile Game API (usnadnˇení vývoje kvalitnˇejších her. Podporuje real-time, multiplayer, detekci kolizí, transformace obrázku, ˚ textury, stínování atd.)

•

Location API (udává fyzickou polohu mobilního zaˇrízení) 8

2.4. MIDLET •

Scalable 2D Vector Graphics API (podpora 2D vektorové grafiky a obrázku˚ ve formátu SVG)

•

PDA Optional Packages (pˇrístup do souborového systému, adresáˇre, kalendáˇre a todo listu)

•

RMI Optional Package (podpora volání vzdálených metod)

•

J2ME Web Services (umožnuje ˇ pˇrístup k webovým službám)

2.4

MIDlet

MIDlet je aplikace urˇcená pro bˇeh na mobilním zaˇrízení s platformou Java ME, konfigurací CLDC a profilem MIDP. Kromˇe knihoven z profilu a konfigurace, muže ˚ MIDlet požadovat ke svému bˇehu i nˇekteré volitelné balíˇcky. MIDlet je pˇrenositelný a mˇel by být spustitelný na jakémkoliv zaˇrízení, které splnuje ˇ všechny požadavky. Zobrazení grafického výstupu i ovládání nˇekterých komponent se muže ˚ lišit podle znaˇcky a typu zaˇrízení, ale funkˇcnost je vždy ekvivalentní. MIDlet je zabalen do JAR archívu. ˚ Archív musí obsahovat manifest, jeden nebo více MIDletu˚ a další potˇrebné knihovny. Muže ˚ obsahovat i obrázky, text a další zdroje, které aplikace využívá. Manifest obsahuje informace o poˇctu MIDletu, ˚ jejich název, verzi a minimální konfiguraci a profil, které potˇrebují ke svému bˇehu. Muže ˚ obsahovat také popis, ikonu, velikost atd. Následující pˇríklad ukazuje manifest popisující archív se dvˇema MIDlety. MIDlet-Name: Hry MIDlet-Version: 2.4.36 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ˇríklad potˇrebný profil se zjistí voláním metody getAppProperty("MicroEdition-Profile"), která vrátí rˇ etˇezec se zadanou hodnotou. Pro spuštˇení bˇežné aplikace je tˇreba do mobilního zaˇrízení nahrát JAR archív. To však vždycky nestaˇcí. K definici dalších informací a požadavku˚ aplikace slouží deskriptor aplikace. Jedná se o další soubor, který je distribuován spolu s JAR archívem. Deskriptor aplikace má pˇríponu JAD a je podobného formátu, jako manifest v archívu. Je v nˇem možné doplnit informace nutné k instalaci aplikace, oprávnˇení, autory atd. Stejnˇe jako manifest, tak i deskriptor má atributy povinné, volitelné a libovolné vlastní, které nezaˇcínají MIDletnebo MicroEdition-. Pokud je nˇejaký atribut uveden v deskriptoru i manifestu, mˇel by mít stejnou hodnotu, jinak záleží jen na zaˇrízení, kterou z nich bude brát v potaz. Následující pˇríklad ukazuje deskriptor se standardními i vlastními atributy. 9

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: 34186 MIDlet-Jar-URL: Send.jar MIDlet-Permissions: javax.wireless.messaging.sms.send MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 SMS-Port: 12345

První rˇ ádky jsou stejné jako v pˇrípadˇe manifestu, pak následují dvˇe povinné položky: informace o velikosti aplikace (v bytech) a cesta k aplikaci. Další rˇ ádek rˇ íká, že aplikace chce mít oprávnˇení posílat SMS zprávy. Na posledním rˇ ádku je uveden vlastní atribut s cˇ íslem portu. Uživatel si tak muže ˚ zmˇenit cˇ íslo portu, se kterým aplikace pracuje, aniž jakkoliv zasáhne do aplikace nebo samotného JARu. V mobilním zaˇrízení tak muže ˚ být aplikace nainstalována duplicitnˇe, protože obˇe instance nemusí pˇristupovat ke stejnému portu. Každý MIDlet má k dispozici API z CLDC, MIDP, rozšiˇrujících balíku˚ a všechny soubory v archívu. K jiným souborum, ˚ funkcím ani zdrojum ˚ se z aplikace nelze dostat, pokud pˇrístup k nim neposkytuje nˇejaké z uvedených API. Proto je dobré uvádˇet seznam nutných rozširˇ ujících balíˇcku˚ do deskriptoru aplikace. Mobilní zaˇrízení tak muže ˚ uživatele informovat již pˇri instalaci, že nepodporuje nˇekteré funkce a tak není možné MIDlet spustit. V opaˇcném pˇrípadˇe se aplikace bez varování ukonˇcí a cˇ asto se uživatel ani nedozví proˇc. Stejnˇe jako bˇežná aplikace pro platformu Java SE má hlavní tˇrídu, která obsahuje metodu public static void main(String[]), tak i v MIDletu je tˇrída, která funguje jako vstupní bod celé aplikace. Nemusí však obsahovat konkrétní metodu, ale musí rozširˇ ovat abstraktní tˇrídu javax.microedition.midlet.MIDlet. Aplikace se pak spouští metodou startApp(). Jméno hlavní tˇrídy je vždy uvedeno v manifestu. Následující pˇrí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."); // set text 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 }

10

2.4. MIDLET public void commandAction(Command command, Displayable displayable) { destroyApp(true); // always exit } }

2.4.1 Životní cyklus MIDletu Abstraktní tˇrída MIDlet, kterou rozšiˇruje každý MIDlet, definuje tˇri základní metody pro práci s aplikací: startApp() pro spuštˇení aplikace, pauseApp() pro pozastavení aplikace a destroyApp(boolean unconditional) pro ukonˇcení aplikace. Pokud je aplikace nainstalována, jsou její tˇrídy, datové úložištˇe a ostatní soubory uloženy v mobilním zaˇrízení. Spustit ji uživatel muže ˚ prostˇrednictvím aplikaˇcního manažeru (application manager software) svého mobilního zaˇrízení. Aplikaˇcní manažer vytvoˇrí instanci MIDletu voláním bezparametrického konstruktoru a následnˇe zavolá metodu startApp(). U aplikací napsaných pro platformu Java SE je bˇežné, že muže ˚ být spuštˇeno nˇekolik aplikací souˇcasnˇe, mužou ˚ provádˇet výpoˇcty i v pˇrípadˇe, že nejsou aktivní a mužou ˚ se vzájemnˇe spouštˇet. Nic z toho však MIDlet nemuže. ˚ Vždy bˇeží právˇe jeden a pˇri spuštˇení jiného je nejprve ten pˇredchozí ukonˇcen. Každý spuštˇený MIDlet se vždy nachází v jednom z následujících stavu: ˚ •

aktivní (Active)

•

zastavený (Paused)

•

ukonˇcený (Destroyed)

Obrázek 2.1: Životní cyklus MIDletu Aplikaˇcní manažer vytvoˇrí novou instanci MIDletu a jeho stav nastaví na zastavený. V konstruktoru muže ˚ aplikace provést nˇejakou inicializaci. Pak aplikaˇcní manažer mobilního zaˇrízení zavolá metodu startApp(), stav MIDletu se zmˇení na aktivní a aplikace muže ˚ bˇežet. Pˇri nˇejaké události (pˇríchozí zpráva, volání atd.) je aplikace doˇcasnˇe pozastavena. V takovém pˇrípadˇe zavolá aplikaˇcní manažer metodu pauseApp(), ve které by mˇela 11

2.4. MIDLET aplikace uvolnit všechny sdílené prostˇredky a zdroje, ale její provedení by mˇelo být co nejrychlejší. Jakmile je to možné, zavolá aplikaˇcní manažer opˇet metodu startApp() a aplikace muže ˚ pokraˇcovat ve své cˇ innosti. Do stavu ukonˇcený se MIDlet dostane zavoláním metody notifyDestroyed(), nebo pokud aplikaˇcní manažer zavolá destroyApp(). Aplikace by pˇred ukonˇcením mˇela uvolnit všechny zdroje, které využívá. Pokud aplikace ještˇe nechce nebo nemuže ˚ skonˇcit, muže ˚ vyvolat výjimku MIDletStateChangeException, cˇ ímž muže ˚ zamezit pˇrechodu od stavu ukonˇcený. Aplikaˇcní manažer mobilního zaˇrízení však muže ˚ kdykoliv aplikaci ukonˇcit. 2.4.2 Základní funkce Profil MIDP definuje dvˇe základní vlastnosti systému (property): microedition.profiles a microedition.locale. Aplikace si tak mohou zjistit verzi implementovaného profilu, nebo aktuálnˇe nastavený jazyk a zvyklosti (locale). Pomocí metody getAppProperty() je možné v aplikaci zjistit jejich hodnotu. První vlastnost využívají aplikace, které jsou urcˇ eny pro provoz na široké škále zaˇrízení a tedy a i na více verzích profilu MIDP. Aplikace tak muže ˚ uživateli znepˇrístupnit nˇekteré funkce s oduvodnˇ ˚ ením, že je telefon nepodporuje (napˇríklad práci se zvukem). Pokus o volání neexistující funkce profilu totiž mívá za následek pád celé aplikace, cˇ asto i bez výpisu chyby na displej. Druhá vlastnost systému je užiteˇcná hlavnˇe pro internacionalizaci aplikací. Voláním funkce System.getProperty("microedition.locale") je možné získat aktuálnˇe nastavené locale mobilního zaˇrízení. Užiteˇcný je i balík java.util, který nabízí tˇrídy Timer a TimerTask pro provádˇení metod v zadaný cˇ as, nebo pro pravidelné spouštˇení kódu v zadaném cˇ asovém intervalu. Nová verze profilu MIDP, která je již na vˇetšinˇe mobilních telefonu, ˚ umožnuje ˇ i jednoduchou práci s multimédii. Jedná se o úplnˇe základní funkce jako pˇrehrá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ˇrehráváním multimédií je rˇ ízena singletonem Manager, který zpˇrístupnuje ˇ pˇrehrávaˇce na konkrétní typ záznamu. Pomocí tˇrídy Manager je také možné vygenerovat tón nebo zjistit, zda je vubec ˚ možné daný typ záznamu pˇrehrát. Samotné pˇrehrávaˇce médií, definované rozhraním Player, mají svuj ˚ životní cyklus s nˇekolika stavy, které zaruˇcují postupnou inicializaci pˇrehrávaˇce. Než se záznam z disku nebo Internetu naˇcte, muže ˚ to nˇejakou dobu trvat, proto se záznam nejprve naˇcte, pˇripraví do pamˇeti a teprve poté se muže ˚ pˇrehrát. Kdykoliv bˇehem této inicializace je možné pˇrechod do následujícího stavu zrušit. Rozhraní Player poskytuje základní ovládací prvky pro pˇrehrávání a informace o záznamu. Rozhraní VolumeControl definuje metody pro rychlé vypínání zvuku (mute), nastavení hlasitosti i zjištˇení obou tˇechto hodnot. 2.4.3 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ˇe RMS). V dobˇe, kdy vznikla specifikace profilu MIDP ještˇe nemˇeli mobilní 12

2.4. MIDLET zaˇrízení pamˇet’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ˇetšinˇe mobilních telefonu˚ byl tento prostor silnˇe omezen. Dnes je už mnohem vˇetší a dokonce je možné data mezi MIDlety sdílet. Datové úložištˇe je pojmenovaná množina záznamu, ˚ která má jedineˇcné ID v rámci celého mobilního zaˇrízení. Každý MIDlet muže ˚ mít datových úložišt’ více. Pˇri jejich vytváˇrení se rozhodne, jestli sem mohou jiné MIDlety cˇ íst a zapisovat. Každý záznam je pole bytu˚ a vždy má pˇridˇelené ID, které je jedineˇcné jen v rámci datového úložištˇe. Pˇri cˇ tení, zápisu i editaci záznamu˚ není tˇreba rˇ ešit zámky nebo semafory, protože pˇrístup k datum ˚ je atomická, synchronní a serializovaná operace. Pokud však MIDlet používá více vláken, je pouze na programátorovi, aby zajistil bezpeˇcný pˇrístup k datum. ˚ Napˇríklad pˇri zápisu více vláken souˇcasnˇe na konec stejného datového úložištˇe se muže ˚ stát, že obˇe zapíší na stejnou pozici a tím si data pˇrepíší. Každé datové úložištˇe si navíc pamatuje i cˇ as poslední zmˇeny a aktuální cˇ íslo verze dat. K pˇrístupu do RMS se používá tˇrídy RecordStore. Pomocí této tˇrídy je možné provádˇet veškeré oˇcekávané operace, napˇríklad zjistit seznam všech datových úložišt’ MIDletu, volné místo, cˇ as posledního pˇrístupu k nˇekterému úložišti, uložení záznamu, modifikace, cˇ tení, smazání atd. Následující úsek kódu ukazuje práci s datovým úložištˇem. 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ˇríkladu je vidˇet, že práce s datovým úložištˇem není nijak složitá. Jako identifikátor konkrétního úložištˇe se používá textový rˇ etˇezec. Pˇri otevírání úložitˇe parametrem zvolíme, že neexistující úložištˇe chceme vytvoˇrit. Poté mužeme ˚ pracovat se záznamy. Ty jsou reprezentovány polem bytu˚ a pˇri cˇ tení nebo modifikaci se na nˇe odkazujeme pomocí jedineˇcného cˇ ísla záznamu. Každému datovému úložišti je možné nastavit RecordListener, který pak pˇrijímá události pˇri zmˇenˇe dat. Pro výbˇer záznamu˚ jsou užiteˇcné tˇrídy RecordFilter a RecordComparator, pomocí nichž lze jednoduše porovnávat a vybírat záznamy. Pro rychlé procházení všech záznamu˚ se používá tˇrída RecordEnumeration. 2.4.4 Uživatelské prostˇredí 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úrovnové ˇ a nízkoúrovnové ˇ API. Vysokoúrovnové ˇ zjednodušuje práci, ale pˇresný vzhled výstupu záleží na konkrétní implementaci každého výrobce zaˇrízení. Aplikace nemuže ˚ ani ovládat posun obrazovky, navigaci 13

2.4. MIDLET v textu atd. Rovnˇež pˇrístup ke klávesnici je zprostˇredkován pˇres API implementace, které poskytuje jen základní události. Všechny tˇrídy vysokoúrovnového ˇ API jsou potomky tˇrídy Screen a jejich práce cˇ asto bývá podporována i hardwarovˇe. Jedná se tedy o možnost rychlejšího zobrazení grafického výstupu, ale s ruzným ˚ vzhledem na ruzných ˚ zaˇrízeních. Toho se hojnˇe využívá u aplikací, které nabízí nˇejakou funkˇcnost a nikoli dokonalý vzhled. Nízkoúrovnové ˇ API poskytuje aplikaci vˇetší kontrolu nad výstupem. Aplikace má plný pˇrístup k obrazovce, muže ˚ na ni vykreslovat, muže ˚ detailnˇeji pracovat se vstupem, reagovat na stisk konkrétní klávesy nebo její uvolnˇení. Toto je užiteˇcné hlavnˇe pˇri tvorbˇe her. Pˇri využití nízkoúrovnového ˇ API již není zaruˇcena pˇrenositelnost. Ta záleží na tom, jestli aplikace nevyužívá speciální vlastnosti jen nˇekterých displeju. ˚ Tˇrídy poskytující nízkoúrovnové ˇ API jsou potomky tˇrídy Canvas nebo Graphics. K displeji se aplikace bˇehem celého svého bˇehu dostane skrze tˇrídu Display, která slouží jako rozhraní aplikaˇcního manažeru. Ten umožnuje ˇ aplikaci, pokud je v aktivním stavu, zobrazovat nové obrazovky na displej mobilního zaˇrízení. Tˇrída reprezentující obrazovku displeje je potomek Displayable. Vysokoúrovnové ˇ API poskytuje tˇrídy List, TextBox, Form a Alert, nízkoúrovnové ˇ nabízí k rozšíˇrení abstraktní tˇrídu Canvas. Celé API uživatelského rozhraní je vláknovˇe bezpeˇcné, metody pro práci s displejem tedy mohou být volány i z vláken, cˇ asovaˇcu˚ atd. Pro ovládání aplikace jsou definovány pˇríkazy, které reprezentují stisk nˇejaké klávesy. Pˇríkazy, objekty typu Command, se pˇriˇrazují ke každé obrazovce. Záleží na zaˇrízení, ke které konkrétní klávese bude tento pˇríkaz pˇriˇrazen. Každý pˇríkaz má popis, který se zobrazí na obrazovce, typ pˇríkazu a prioritu. Priorita urˇcuje duležitost ˚ pˇríkazu a slouží hlavnˇe k vzájemnému porovnávání pˇríkazu. ˚ Typ udává, zda se jedná o pˇríkaz typu potvrd’, zpˇet, zruš, nápovˇeda atd. Zaˇrízení má tak možnost pˇriˇrazovat pˇríkazy zpˇet stále na jednu klávesu, nebo naopak programátor muže ˚ reagovat na pˇríkaz typu zpˇet, který nedefinoval, ale který odpovídá speciální klávese zpˇet pˇrímo na mobilním zaˇrízení. Speciální události jsou generovány v nízkoúrovnovém ˇ API pˇri stisku klávesy na 3-klávesovém nebo 5-klávesovém joysticku. U tˇechto kláves je pˇresnˇe definován jejich význam (nahoru, dolu, ˚ stˇrelba, pˇrípadnˇe i vlevo a vpravo). Následuje pˇríklad zpracování pˇríkazu z obrazovky aplikace (vysokoúrovnové ˇ 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úrovnovém ˇ API. 14

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ˇrízení muže ˚ poskytovat i další funkce a pˇríkazy, aniž o tom má aplikace jakékoliv tušení. Typickým pˇríkladem takové funkce je pˇrepínání cˇ ísel a písmen pˇri psaní textu. Aplikace pomocí vysokoúrovnového ˇ API vytvoˇrí textové pole a pˇridá nˇejaké pˇríkazy. Uživatel má však možnost zapínat napˇríklad T9, vkládat speciální symboly, oznaˇcovat a kopírovat text. O tyto funkce se aplikace nestará, ty obstarává implementace MIDP. Užiteˇcnou funkcí, kterou nabízejí nˇekteré telefony, je možnost výbˇeru telefonního cˇ ísla z adresáˇre, pokud je v aplikaci políˇcko oznaˇcené jako telefonní cˇ íslo. U vykreslování obrazovek v nízkoúrovnovém ˇ API je nutné obsluhovat mnohem více událostí nˇež ve vysokoúrovnovém. ˇ Napˇríklad je nutné obsluhovat požadavky na pˇrekreslení. Pˇri zmˇenách v obraze, napˇríklad pohybu hráˇce, je nutné volat metodu pro pˇrekreslení dané cˇ ásti obrazu. Vykreslování probíhá v systému souˇradnic, jejichž poˇcátek je v levém horním rohu, délku os je možné zjistit pˇríkazy getWidth() a getHeight(). Na výstup je možné vykreslovat jednoduché grafické prvky, text i obrázky. Následující pˇríklad ukazuje, jak lze vytvoˇrit 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ˇridán balík javax.microedition.lcdui.game. Ten poskytuje bohaté grafické funkce, které bývají hardwarovˇe akcelerované. V programu se nemusí vytváˇret základní funkce a tím se i zmenšuje celková velikost aplikace. Všechny funkce jsou navíc sluˇcitelné s prací se základními grafickými prvky ze standarvního balíku javax.microedition.lcdui. 2.4.5 Sít’ová komunikace Profil MIDP obsahuje silnou podporu sít’ové komunikace, zejména se jedná o podporu HTTP spojení. Toto spojení muže ˚ být realizováno nejen pˇres TCP/IP, ale i pˇres WAP nebo iMode s pˇrístupem pˇres bránu. Implementace dovoluje pˇrístup na internetové stránky, ale i k webovým službám. Každé zaˇrízení musí plnˇe podporovat minimálnˇe verzi HTTP 1.1, vˇcetnˇe HEAD, GET a POST požadavku. ˚ Spojení se naváže zavoláním metody open() tˇrídy Connector, jako parametr se uvádí adresa. Pˇríklad pˇrístupu na Internet z MIDletu: 15

2.4. MIDLET Connector.open("http://www.fi.muni.cz:8080");

Tˇrída Connector neotevírá jen HTTP spojení. Aplikace mohou také navázat pˇrímé spojení pˇres TCP/IP nebo UDP/IP. Staˇcí v parametru pro otevˇrení spojení uvést místo protokolu http text socket respektive datagram. Pokud není zadána adresa serveru, pak se na zadaném portu vytvoˇrí server cˇ ekající na pˇríchozí spojení z jiného zaˇrízení. Spojení pˇres sériový port je možné navázat použitím parametru "comm:port;parametry" (prametr muže ˚ napˇríklad vypadat takto: "comm:COM1;baudrate=19200"). Sít’ová spojení jsou vždy obousmˇerná, lze tedy u nich otevˇrít vstupní i výstupní proud naráz. Následující pˇrí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ˇridána podpora šifrování, mobilní zaˇrízení tak muže ˚ otevˇrít i HTTPS nebo SSL spojení. Nechybí ani podpora certifikátu˚ a jejich automatické ovˇerˇ ování. Aplikace se nemusí o tuto funkcionalitu vubec ˚ starat. Pro zvýšení bezpeˇcnosti 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 rˇ ádek zaˇcínající textem MIDlet-Permissions: a za ním seznam protokolu, ˚ které chce využívat. Pokud aplikace cˇ eká na pˇríchozí sít’ové spojení, musí být stále aktivní a s mobilním zaˇrízením tedy není možné pracovat. Proto existuje tˇrída PushRegistry, která umožnuje ˇ MIDletu zaregistrovat u aplikaˇcního manažeru protokol a port, který chce obsluhovat. Pak je možné MIDlet vypnout. Jakmile pˇrijde na daný port požadavek na spojení pˇres požadovaný port, aplikaˇcní manažer MIDlet spustí. Registraci je ˇ možné provést již pˇri instalaci MIDletu a to prostˇrednictvím deskriptoru. Cást deskriptoru pak vypadá napˇríklad takto: MIDlet-Permissions: javax.microedition.io.Connector.serversocket, javax.microedition.io.PushRegistry MIDlet-Push-1: socket://:12345,example.socket.SocketMIDlet,*

První rˇ ádek rˇ íká, že aplikace chce používat pˇríchozí spojení pˇres soket a chce být automaticky spouštˇena. Na druhém rˇ ádku je požadavek o spuštˇení MIDletu SocketMIDlet, pokud se nˇejaké zaˇrízení pokusí pˇripojit na port 12345 pˇres TCP/IP. Hvˇezdiˇcka znamená, že se muže ˚ jednat o spojení z jakékoliv adresy. 2.4.6 Bezpeˇcnost Podle specifikace MIDP 1.0 bˇežely MIDlety v sendboxu a bezpeˇcnost se nemusela nijak rˇ ešit. S verzí 2.0 pˇrišly nové funkce a s tím i potˇreba vytvoˇrit jednoduchý bezpeˇcnostní model, aby nedošlo k masivnímu rozšíˇrení viru˚ a jiného škodlivého softwaru na mobilní zaˇrízení. MIDlety se proto dˇelí na duvˇ ˚ eryhodné a neduvˇ ˚ eryhodné. Neduvˇ ˚ eryhodné mají neomezený 16

2.4. MIDLET pˇrístup k základním balíˇckum ˚ definovaným ve verzi 1.0 a k tˇrídám pro práci se sít’ovým spojením pˇres http a https protokoly. Ostatní funkce je možné využít, jen pokud je uživatel explicitnˇe povolí, nˇekteré mohou být dokonce zakázány úplnˇe. Duvˇ ˚ eryhodné MIDlety nemají žádná omezení ve využívání funkcí, uživatel však muže ˚ nˇekteré funkce aplikaci zakázat. Uživatel si zvolí pro každou oblast funkcí (sít’ové spojení, pˇrístup k souborum ˚ atd.), zda je aplikace muže ˚ používat, nemuže, ˚ nebo jestli se musí dotázat uživatele. Aby se aplikace mohla stát duvˇ ˚ eryhodnou, musí být digitálnˇe podepsána. Podepisování a ovˇerˇ ování MIDletu˚ je založeno na X.509 Public Key Infrastructure. Programátor musí digitálnˇe podepsat celý JAR archív a do deskriptoru aplikace pˇridá parametry obsahující podpis a certifikát. Pˇri instalaci aplikace si aplikaˇcní manažer ovˇerˇ í podpis a v pˇrípadˇe úspˇechu zaˇradí aplikaci mezi duvˇ ˚ eryhodné. Pro práci s certifikáty se využívá knihovna javax.microedition.pki.

2.4.7 Instalace Instalace MIDletu je možná více zpusoby, ˚ cˇ asto záleží i na konkrétním zaˇrízení a výrobci. Jeden zpusob ˚ však mají všechny zaˇrízení podporující MIDP 2.0 a vyšší spoleˇcný. Jedná se o OTA (Over-The-Air) instalaci. Každé zaˇrízení musí poskytovat prohlížeˇc, který dokáže rozpoznat aplikaci podle deskriptoru, uložit ji do zaˇrízení a nainstalovat. V praxi to bývá bˇežný integrovaný prohlížeˇc, který se používá k pˇrístupu na Internet. Uživatel pak na stránce pouze "klikne" na odkaz smˇerˇ ující na nˇejaký deskriptor a mobilní zaˇrízení udˇelá vše zbylé. Jakmile je aplikace lokálnˇe uložena, aplikaˇcní manažer ji nainstaluje a je pˇripravena k použití. V pˇrípadˇe takovéto instalace nabízí mobilní zaˇrízení možnost automatické aktualizace. Pˇri požadavku uživatele o aktualizaci, mobilní zaˇrízení stáhne znovu deskriptor aplikace (ze stejné adresy) a ovˇerˇ í, zda nedošlo ke zmˇenˇe verze MIDletu. Pokud ano, provede aktualizaci. Veškeré nastavení a uložená data v aplikaci zustanou. ˚ Další výhodou tohoto postupu je možnost zjištˇení, zda dané mobilní zaˇrízení je schopné MIDlet spustit. V deskriptoru jsou atributy požadující minimální konfiguraci, profil i volitelné balíˇcky. Pokud aplikaˇcní manažer zjistí, že nˇekterou z podmínek nesplnuje, ˇ oznámí to uživateli a MIDlet vubec ˚ nestáhne. Podle atributu˚ je schopen poznat i napˇríklad to, že nemá dostatek místa na aplikaci. Témˇerˇ všechny mobilní telefony poskytují možnost instalace aplikace i jiným zpusobem. ˚ Nˇekteré rozpoznají aplikaci pˇri procházení pamˇet’ové karty nebo lokálního souborového systému. Uživatel tak muže ˚ aplikaci uložit do mobilu pˇres datový kabel nebo bezdrátové spojení a nemusí vubec ˚ využívat pˇrístup na Internet. Nˇekteˇrí výrobci poskytují i speciální software do poˇcítaˇce, pomocí kterého je možné MIDlety instalovat pˇres sít’ové spojení z pocˇ ítaˇce. Nevýhodou tˇechto alternativních postupu˚ instalace je to, že není možné provádˇet automatické instalace. 17

2.5. JAVA APIS FOR BLUETOOTH 2.4.8 Chystané novinky v MIDP 3.0 Specifikace Mobile Information Device Profile 3.0 je v souˇcasné dobˇe stále ještˇe ve vývoji. V prosinci vyšla "Early Draft Review" specifikace, ze které je možné vyˇcíst nˇekteré pˇripravované novinky. Jedná se cˇ asto o funkce, které jsou poskytovány ruznými ˚ výrobci prostˇrednictvím rozšiˇrujících balíˇcku, ˚ ale nejsou standardizovány, takže je každý výrobce implementuje jinak. Další funkce jsou pˇridány díky vzrustající ˚ výkonnosti mobilních zaˇrízení, vˇetší pamˇet’ové kapacitˇe, pˇrídavným kartám i výdrži baterie. Hlavní novinky nové specifikace, které snad uvidíme i ve finální verzi, jsou: •

souˇcasný bˇeh více MIDletu˚ na jednom virtuálním stroji

•

možnost bˇehu MIDletu na pozadí

•

spuštˇení MIDletu˚ pˇri spuštˇení mobilního zaˇrízení

•

dovoluje vzájemnou komunikaci MIDletu˚

•

MIDlety budou moci sdílet knihovny (LIBlety)

•

zkonkrétnˇení specifikací, aby byla zaruˇcena maximální pˇrenositelnost mezi mobilními zaˇrízeními

•

vykreslovat na sekundární displej

•

podpora pro výkonné hry

•

bezpeˇcné, pˇripojitelné i vzdálené RMS

•

podpora IPv6

2.5

Java APIs for Bluetooth

Bezdrátovou technologií bluetooth je vybavena vˇetšina všech nových mobilních zaˇrízení. Pro práci s bluetooth slouží rozšiˇrující balíˇcek Java APIs for Bluetooth, který je specifikován v JSR-82. Balíˇcek poskytuje aplikacím rozhraní ke komunikaci prostˇrednictvím této bezdrátové technologie. Zaˇrízení musí mít konfiguraci CLDC a profil MIDP. Specifikace obsahuje základní podporu komunikace pˇres protokoly RFCOMM, OBEX a Service Discovery protocol. První protokol nám dovoluje vytvoˇrit nízkoúrovnové ˇ spojení pˇres datový proud. Aplikace se musí starat o veškeré rˇ ízení komunikace. OBEX je standardní protokol pro výmˇenu objektu. ˚ Využívá se hlavnˇe k synchronizaci a pˇrenosu souboru. ˚ Service Discovery protocol slouží k hledání okolních aktivních zaˇrízení. Mobilní zaˇrízení, které implementuje bluetooth API, musí poskytovat základní bezpeˇcnostní prvky definované bluetooth standardem. Také je nezbytné, aby umožnilo spárování zaˇrízení a jejich pˇrípadnou autorizaci. Funkce, které API poskytuje je možné rozdˇelit do tˇrí základních skupin: 18

2.5. JAVA APIS FOR BLUETOOTH •

Pruzkum ˚ okolí

•

Komunikace

•

Správa zaˇrízení

2.5.1 Pruzkum ˚ okolí Pro pruzkum ˚ okolí se využívá tˇrídy DiscoveryAgent. K nalezení aktivních zaˇrízení slouží metoda retrieveDevices() nebo startInquiry(). První metoda zjišt’uje dostupnost dˇríve nalezených zaˇrízení. Druhá spustí ve zvláštním vláknˇe prohledávání okolí a všechna nalezená zaˇrízení pˇredává prostˇrednictvím rozhraní DiscoveryListener. Zaˇrízení jsou pˇredávána metodou deviceDiscovered(), konec prohledávání okolí je oznámeno voláním metody inquiryCompleted(). Následující pˇríklad ukazuje inicializaci bluetooth a spuštˇení 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ˇrízením, musí se pˇripojit ke konkrétní službˇe. Napˇríklad k odeslání souboru pˇres OBEX je nutné vyhledat na zaˇrízení službu, která se staré o pˇríjem dat pˇres OBEX. Vyhledávání služeb na vzdáleném zaˇrízení opˇet zajišt’uje DiscoveryAgent, prostˇrednictvím metody searchServices(). Nalezené služby se pˇredávají prostˇrednictvím stejného rozhraní. Každá služba má svuj ˚ identifikátor (UUID) a atributy. Podle tˇechto informací je možné vybrat hledanou službu. Veškeré informace o službˇe zapouzdˇruje tˇrída ServiceRecord. 2.5.2 Komunikace Využití služby na vzdáleném zaˇrízení je možné jen v pˇrípadˇe, že aplikace bude komunikovat stejným protokolem. K navázání spojení se využívá metoda open(URL) tˇrídy Connector, parametrem metody je adresa zaˇrízení ve tvaru protokol://adresa:[UUID];parametry. Pokud chce aplikace vytvoˇrit službu, která bude cˇ ekat na pˇríchozí spojení, uvede jako adresu zaˇrízení localhost. Tím se otevˇre spojení na lokálním zaˇrízení. Následným voláním metody acceptAndOpen() se zaˇcne cˇ ekat na pˇripojení nˇejakého vzdáleného zaˇrízení. ... try { // create service url = "btspp://localhost:102030405060708090A1B1C1D1D1E100;name=SPPEx"; service = (StreamConnectionNotifier) Connector.open(url); StreamConnection con = (StreamConnection) service.acceptAndOpen(); } catch (Exception e) { showError(e.getMessage()); }

19

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

20

Kapitola 3

Šifrování Potˇreba utajovat informace a zprávy je stará skoro jako lidstvo samo. Bˇehem cˇ asu se samozˇrejmˇe metody utajování informací výraznˇe zmˇenily. Staˇrí Egypt’ané používali pro utajení textu speciální hieroglyfy, pozdˇeji se tetovali zprávy otrokum ˚ pod vlasy, spart’anští vojeˇ vudci ˚ používali plátno namotávané na hul. ˚ Casem se zaˇcaly rozvíjet složitˇejší šifry, napˇríklad posun znaku˚ abecedy, šifrovací mˇrížky, prohazování znaku˚ atd. V pˇredminulém století se zaˇcaly rozvíjet šifrovací stroje, které umožnovali ˇ rychlejší a dumyslnˇ ˚ ejší šifrování. S rozvojem poˇcítaˇcu˚ se šifrování stalo aktuální nejen pro vojenské a politické úˇcely, ale i pro obyˇcejné lidi. V souˇcasné dobˇe je šifrování využíváno témˇerˇ všude, kde se nepoužívá k pˇrenosu dat manuální doruˇcování. Šifrované jsou bˇežné telefonní hovory, emailová komunikace i televizní vysílání. V praxi se nejˇcastˇeji používají dvˇe základní množiny šifer. Jsou to šifry s verˇ ejným klíˇcem a symetrické šifry. Šifrováním se zabývá kryptografie. Kryptografie je nauka využívající poznatku˚ z matematiky ke kódování a dekódování dat tak, aby je nebylo možné cˇ íst bez znalosti urˇcitého tajemství. Naproti tomu existuje kryptoanalýza, která se snaží získat data bez znalosti tohoto tajemství. Kryptoanalytici vlastnˇe ovˇerˇ ují kvalitu výsledku˚ kryptografie a pomáhají tak vytváˇret opravdu bezpeˇcné šifry, které se pak používají v praktickém životˇe.

3.1

Symetrické šifry

Symetrické šifrovací algoritmy jsou ty, které používají k zašifrování dat i jejich dešifrování stejný klíˇc (sdílené tajemství). Výhodou tˇechto algoritmu˚ je jejich vysoká rychlost oproti algoritmum ˚ šifrujícím pomocí veˇrejného klíˇce. Velkou nevýhodou je však fakt, že komunikující strany se musí nejprve domluvit na sdíleném klíˇci a tento klíˇc nesmí být nikým odˇ poslechnut. Díky tomu bývají v praxi ménˇe používané, než asymetrické šifry. Casto se však využívá kombinace obou druhu˚ šifer: nˇekterá pro bezpeˇcné pˇredání klíˇce, jiná pro šifrování a jiná pro digitální podpis. •

šifrování zprávy m klíˇcem k: c = e(m, k)

•

dešifrování zprávy m klíˇcem k: m = d(c, k)

Algoritmy symetrického šifrování provádí vˇetšinou jednodušší matematické operace typu bitový souˇcet, negace, nonekvivalence atd. Díky tomu jsou jednak rychlé, ale hlavnˇe je 21

3.1. SYMETRICKÉ ŠIFRY možné je jednoduše implementovat hardwarovˇe. Na nˇekterých zaˇrízeních proto bývá hardwarová podpora šifrování, ale využití nacházejí také na ruzných ˚ cˇ ipových kartách, cˇ teˇckách apod.

Obrázek 3.1: Symetrické šifrování Vˇetšina šifer používala délku klíˇce 64 bitu, ˚ což v dnešní dobˇe již není bezpeˇcné, proˇ tože bˇežné poˇcítaˇce jsou schopny hrubou silou takto krátký klíˇc zjistit. Casto se užívají klíˇce o délce 256 nebo 128 bitu. ˚ Kratší bývají užity jen k šifrování zpráv, které brzy ztrácejí informaˇcní hodnotu. Symetrické šifry se dˇelí do dvou základních skupin podle toho, jestli se data šifrují postupnˇe bit po bitu, nebo jestli se šifruje ucelený blok dat. Prvním zpusobem, ˚ tedy postupným zpracováním dat, pracují proudové šifry. Naproti tomu šifry blokové vezmou vždy pevný poˇcet bitu˚ 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ˇctem bitu. ˚ Tyto bloky jsou pomocí klíˇce zašifrovány a výstupem je pˇríslušná cˇ ást šifrovaného textu. Nˇekteré algoritmy provádˇejí nˇekolikanásobné šifrování bloku dokola, aby se zvýšila bezpeˇcnost. Blokové šifry jsou na šifrování dat v praxi využívány cˇ astˇeji než proudové. Mezi blokové šifry patˇrí napˇríklad algoritmy DES, AES, IDEA, Blowfish a jiné. 22

3.1. SYMETRICKÉ ŠIFRY Proudové šifry jsou rychlejší než blokové. Vhodnˇejší jsou tam, kde není možné využívat buffer. Typickým pˇríkladem je telekomunikace a jiné real-time spojení, kde není vhodné cˇ ekat na naplnˇení bufferu, ale je tˇreba data šifrovat ihned. Mezi zástupce proudových šifer patˇrí algoritmy RC4, FISH, Helix, SEAL, WAKE a další. Proudové šifry dˇelíme na dvˇe základní skupiny: •

synchronní proudové šifry

•

proudové šifry s vlastní synchronizací (asynchronní).

Synchronní proudová šifra je taková, která nevyužívá k šifrování text (puvodní ˚ ani šifrovaný). Data jsou šifrována pomocí klíˇce a stavu, ve kterém se funkce nachází. Pˇri dešifrování je proto potˇreba mít stejný klíˇc a postupnˇe procházet ekvivalentními stavy. Pokud se pˇri pˇrenosu ztratí jediný bit (nebo pˇribude), 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íˇce i pˇredchozích n bitu˚ šifrovaného textu. Tím se zvyšuje bezpeˇcnost, ale pˇri ztrátˇe jednoho bitu se následujících n bitu˚ zprávy dekóduje špatnˇe. Po tˇechto n bitech se další data již dekódují opˇet správnˇe. 3.1.1 DES DES (Data Encryption Standard) patˇrí mezi nejznámˇejší šifrovací algoritmy a patˇrí mezi první zástupce blokových šifer. O jeho vývoj se v sedmdesátých letech postarala firma IBM. Brzy byl pˇrijat 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íˇc o délce 64 bitu, ˚ z toho je 56 bitu˚ použito k šifrování a 8 bitu˚ jako parita. Bloky jsou délky 64 bitu, ˚ výsledkem šifrovací funkce je i stejnˇe dlouhý výstup. Šifrování probíhá v 16 kolech (round). Z klíˇce je vypoˇcítáno šestnáct podklíˇcu, ˚ pro každé kolo jeden. Na vstupním text se provede poˇcáteˇcní permutace a pak se rozdˇelí na pravou 23

3.1. SYMETRICKÉ ŠIFRY a levou polovinu. Levá polovina je pozmˇenˇena funkcí, která má jako vstup pˇríslušný klíˇc a pravou polovinou. Poté se levá a pravá polovina vymˇení. Toto se opakuje 16-krát. V posledním kole již neprobˇehne výmˇena stran. Nakonec se provede koneˇcná permutace bitu. ˚ Dešifrování se provádí stejným algoritmem, pouze klíˇce pro každé kolo se berou v opaˇcném poˇradí. V souˇcasné dobˇe 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ˇríliš krátkému klíˇci se používá spíše její varianta Triple DES, nebo výkonnˇejší a bezpeˇcnˇejší AES. Triple DES (3DES, TDES), varianta algoritmu DES, používá k šifrování tˇri ruzné ˚ klíˇce. Pomocí algoritmu DES zašifruje text prvním klíˇcem, šifrovaný text pomocí stejného algoritmu zašifruje druhým klíˇcem a nakonec se postup zopakuje i s tˇretím klíˇcem. Dešifrování se provádí opˇet trojím pruchodem ˚ algoritmu DES, klíˇce se však použijí v opaˇcném poˇradí. 3.1.2 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ˇekdy nazýván jako Rijndael po svých autorech Joan Daemenu a Vincent Rijmenu. AES pracuje s blokem délky 128 bitu, ˚ šifrovací klíˇc musí mít délku 128, 192 nebo 256 bitu. ˚ Šifrování probíhá nad tabulkou o rozmˇerech 4x4 byty a opakovanˇe se provádˇejí výpoˇcetní kola (round), jejichž poˇcet závisí na délce klíˇce. Pro každé kolo se vypoˇcítají klíˇce podobným zpusobem ˚ jako u DES. Nejprve se do tabulky dosadí cˇ istý text. Pak probíhají fáze, ve kterých se postupnˇe provedou tyto kroky:

Obrázek 3.4: Postup pˇri šifrování algoritmem AES

24

3.1. SYMETRICKÉ ŠIFRY •

AddRoundKey - pro každý byte tabulky se vypoˇcte nová hodnota jako aij XOR kij , kde a jsou puvodní ˚ hodnoty v tabulce a k je klíˇc pˇrí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ˇe šifrovaného textu

•

ShiftRows - všechny rˇ ádky jsou posunuty vlevo o urˇcený poˇcet míst (rotuje se dokola: nejlevˇejší byte na rˇ ádku se posouvá úplnˇe vpravo)

•

MixColumns - každý sloupec je vynásoben pevnˇe daným polynomem

Tato šifra dosahuje velmi dobrých výsledku jak v rychlosti, tak v bezpeˇcnosti. Jedná se o relativnˇe 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ˇejší symetrickou šifru. 3.1.3 IDEA IDEA (International Data Encryption Algorithm) je další z rˇ ady mladých šifrovacích algoritmu, ˚ které dosahují dobrých výsledku. ˚ Uveˇrejnˇena byla na zaˇcátku devadesátých let a mˇela nahradit nedostaˇcující šifru DES. V souˇcasné dobˇe se pravdˇepodobnˇe 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ˇcní úˇcely. Algoritmus šifruje bloky velikosti 64 bitu˚ a stejnˇe velké bloky jsou i na výstupu. Pracuje s klíˇcem délky 128 bitu. ˚ Pˇri šifrování se projde 8-krát kolem (round), což je definovaná množina operací. Pro každé kolo se vypoˇcítá 6 zvláštních klíˇcu˚ délky 16 bitu. ˚ Vstup je rozdˇelen do cˇ tyˇr 16-ti bitových bloku. ˚ V každém kole se se vstupními bloky a ruznými ˚ klíˇci provádˇejí operace XOR, sˇcítání modulo 216 a násobení modulo 216 +1. Mísením tˇechto ruzných ˚ algebraických operací se docílí vysoké bezpeˇcnosti.

Obrázek 3.5: Diagram jednoho kola algoritmu IDEA

25

ˇ ˇ 3.2. ŠIFRY S VE REJNÝM KLÍ CEM

3.2

Šifry s veˇrejným klíˇcem

Šifry s veˇrejným klíˇcem využívají vždy nˇejaké veˇrejné informace (klíˇce) k šifrování zpráv. K dešifrování je pak nutný nˇejaký tajný klíˇc. Šifrování není symetrické, protože se šifruje jiným klíˇcem a jinou funkcí, než se pozdˇeji dešifruje. Proto je šifrování s veˇrejným klíˇcem oznaˇcováno i jako asymetrické šifrování. •

šifrování zprávy m klíˇcem k1 : c = e(m, k1 )

•

dešifrování zprávy m klíˇcem k2 : m = d(c, k2 )

Asymetrické šifrovací algoritmy potˇrebují k zašifrování dat jiný klíˇc, než k jejich zpˇetnému dešifrování. Tato šifrovací metoda je novˇejší než symetrické šifrování a v souˇcasnosti se také mnohem více používá. K šifrování je tˇreba dvojice klíˇcu: ˚ veˇrejný klíˇc a soukromý klíˇc. Verˇ ejným klíˇcem se data zašifrují a dešifrovat je pak lze pouze klíˇcem soukromým. Odesílatel zašifruje zprávu veˇrejným klíˇcem pˇríjemce a odešle ji. Pokud se zprávy zmocní nˇekdo jiný, nemuže ˚ ji dešifrovat, protože nezná soukromý klíˇc pˇríjemce. Jediný, kdo si zprávu muže ˚ pˇreˇcíst, je jen skuteˇcný pˇríjemce.

Obrázek 3.6: Použití šifer s veˇrejným klíˇcem K tomu, aby pˇríjemce vˇedˇel, kdo opravdu zprávu poslal, slouží digitální podpis. K digitálnímu podepisování se také používá asymetrická kryptografie. Odesílatel vytvoˇrí kontrolní souˇcet zprávy (hash) a svým soukromým klíˇcem ho zašifruje. Tím zprávu digitálnˇe podepíše. Pokud si chce nˇekdo ovˇerˇ it odesílatele, dešifruje hash veˇrejným klíˇcem odesílatele a pokud je kontrolní souˇcet správný, znamená to, že zprávu opravdu poslal on. Navíc to znamená, že ji cestou nikdo neupravil. Podpis muže ˚ vytvoˇrit jen ten, kdo zná soukromý klíˇc, tedy pravý odesílatel. Nˇekteré z požadavku˚ na digitální podpis jsou: •

autenticita - musí dokazovat, kdo dokument psal 26

ˇ ˇ 3.2. ŠIFRY S VE REJNÝM KLÍ CEM •

nezfalšovatelnost - nikdo nedokáže podepsat za nikoho jiného

•

jednorázové použití - podpis platí pro jediný dokument, nelze ho pˇrenášet na další dokumenty

•

nezmˇenitelnost dokumentu - podepsaný dokument již nelze zmˇenit

•

nepopiratelnost - podpis jasnˇe rˇ íká, že uživatel dokument skuteˇcnˇe napsal

Problém u asymetrické kryptografie je s bezpeˇcnou distribucí veˇrejného klíˇce. Odesílatel šifruje data klíˇcem pˇríjemce, ale jeho veˇrejný klíˇc musí nˇejak získat. Vˇetšinou ho stáhne z internetu nebo si ho nechá poslat. To ale nejsou úplnˇe bezpeˇcné datové kanály a nˇejaký útoˇcník mu muže ˚ podstrˇcit svuj ˚ klíˇc a komunikaci odposlouchávat. Proto se místo veˇrejných klíˇcu˚ distribuují certifikáty. Certifikát je veˇrejný klíˇc s informacemi o majiteli, platnosti atd, který je digitálnˇe podepsán certifikaˇcní autoritou. Certifikaˇcní autorita pak ruˇcí za správnost údaju˚ v certifikátu. Soukromý a veˇrejný klíˇc spolu samozˇrejmˇe musí matematicky souviset, ale je nesmírnˇe duležité, ˚ aby z veˇrejného klíˇce nebylo možné zjistit klíˇc soukromý. Celá bezpeˇcnost dat závisí na dobrém šifrovacím algoritmu a na dobrém klíˇci. Jednou z duležitých ˚ vˇecí je, aby oba klíˇce mˇeli dostateˇcnou délku a jejich zjištˇení hrubou silou se tak pohybovalo v rˇ ádech desítek let nebo i víc. Šifrovací funkce jsou jednocestné, což znamená, že z dat a klíˇce se vypoˇcítají zašifrovaná data, která nelze touto funkcí a klíˇcem dešifrovat. V souˇcasné dobˇe je asymetrická kryptografie nejpoužívanˇejší, protože není potˇreba pˇredávat sdílený klíˇc bezpeˇcnou cestou, kterou nikdo nemuže ˚ odposlechnout. Veˇrejný klíˇc pˇríjemce muže ˚ znát kdokoliv. Je potˇreba mít pouze jistotu, že odesílatel šifruje data správným klíˇcem, tedy klíˇcem pˇríjemce. To sice není úplnˇe triviální problém, ale existují zpusoby, ˚ jak toho docílit. A pak si obˇe strany mužou ˚ být jisté, že jejich sdílená data nikdo nezná. K šifrování dat se nejˇcastˇeji používá RSA algoritmus, nejˇcastˇeji využíván bývá také k digitálnímu podpisu. Není ale zdaleka jediný. K výmˇenˇe sdíleného tajemství pro následnou symetrickou kryptografii se hojnˇe využívá Diffie-Hellman. Jeho modifikace, algoritmus ElGamal, je zase velmi rychlý, ale zdvojnásobuje šifrovanou zprávu. Velký rozmach lze oˇcekávat algoritmu˚ nad eliptickou kˇrivkou, které vykazují výborné výsledky. 3.2.1 Diffie-Hellman Tento algoritmus je jeden z nejstarších, ale stále jeden z nejbezpeˇcnˇejších algoritmu˚ pro výmˇenu sdíleného tajemství nebo klíˇce. V praxi se nikdy klíˇc nebo heslo nepošlou fyzicky po síti, ale obˇe dvˇe komunikující strany se pˇritom domluví na sdíleném klíˇci. V roce 1976 tento algoritmus publikoval Whitfield Diffie a Martin Hellman. Jeho bezpeˇcnost je založena na problému výpoˇctu diskrétního logaritmu. Díky jednoduchým výpoˇcetním operacím je algoritmus velmi rychlý. Ke komunikaci je tˇreba dvou, tˇreba i veˇrejnˇe známých, cˇ ísel p a q. Odesílatel si zvolí ˇ cˇ íslo a a vypoˇcítá A = ga mod p. Císlo A pošle adresátovi. Ten si zvolí cˇ íslo b a vypoˇcte B b = g mod p, poté pošle odesílateli cˇ íslo B. Spoleˇcný klíˇc si oba spoˇcítají pomocí vzorce K = 27

ˇ ˇ 3.2. ŠIFRY S VE REJNÝM KLÍ CEM

Obrázek 3.7: Bezpeˇcná výmˇena klíˇce algoritmem Diffie-Hellman Ba mod p respektive K = Ab mod p. Spoleˇcné sdílené tajemství K pak mohou použít k další komunikaci. 3.2.2 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ˇe odlišná od funkce pro šifrování. Obˇe funkce jsou postaveny na základˇe problému vyˇreš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ˇcnost, že výsledná šifrovaná data jsou dvakrát delší, než je puvodní ˚ text. U digitálního podpisu to tolik nevadí, ale u objemných dat je to velká nevýhoda. ElGamal je také výpoˇcetnˇe nároˇcnˇejší než napˇríklad RSA algoritmus. Ke generování soukromého a veˇrejného klíˇce slouží tˇri cˇ ísla. Dvˇe veˇrejnˇe známá cˇ ísla p a q, kde p je prvoˇcíslo a obˇe jsou co nejvyššího rˇ ádu. Dalším cˇ ísle je náhodnˇe zvolené cˇ íslo a, které je menší než p. Pak je nutné spoˇcítat r = qa mod p. Veˇrejný klíˇc je trojice (p; q; r), soukromým klíˇcem je pouze cˇ íslo a. Komunikace mezi odesílatelem a pˇríjemcem vypadá následovnˇe: 1. odesílatel (A) si zjistí veˇrejný klíˇc (p; q; r) pˇríjemce (B) 2. zpráva m musí být menší než p 3. A si zvolí náhodné cˇ íslo k, menší než p 4. A spoˇcte cˇ ísla x = qk mod p a y = mrk mod p 5. A pošle B dvojici (x; y) 6. B spoˇcte z = xp-1-a mod p 7. nakonec B dešifruje data: m = zy mod p 28

ˇ ˇ 3.2. ŠIFRY S VE REJNÝM KLÍ CEM Jak je vidˇet z pˇredchozího postupu, šifrování textu vyžaduje náhodné cˇ íslo k. Toto cˇ íslo je voleno náhodnˇe, vždy znovu, takže pˇri šifrování stejného textu nˇekolikrát za sebou, budou data posílaná pˇríjemci pokaždé jiná. Pˇresto je lze vždy pˇrevést na puvodní ˚ (stejný) text. 3.2.3 RSA Šifrovací algoritmus RSA je jeden z nejznámˇejších, jeho využití je vhodné k šifrování dat i k elektronickému podpisu. Jméno algoritmu pochází od jeho tvurc ˚ u˚ Rona Rivesta, Adi Shamira a Leonarda Adlemana, kteˇrí jej v roce 1977 prezentovali. Bezpeˇcnost tohoto algoritmu je postavena na problému faktorizace vysokých cˇ ísel. Pˇríjemce zpráv (A) vygeneruje veˇrejný a soukromý klíˇc následujícím zpusobem: ˚ 1. zvolí dvˇe náhodná velká prvoˇcísla p a q 2. spoˇcítá n = pq 3. vypoˇcte hodnotu Eulerovy funkce f(n) = (p-1)(q-1) 4. zvolí cˇ íslo e menší než f(n) a nesoudˇelné s f(n) 5. vypoˇcítá cˇ íslo d tak, aby platilo (de) mod f(n) ≡ 1 mod f(n) Veˇrejný klíˇc je dvojice (n; e), soukromý klíˇc je dvojice (n; d). Nˇekdy se klíˇce poˇcítají mírnˇe odlišnou metodou a uchová se více cˇ ísel, která pak urychlují šifrovací funkce. Pokud chce nˇejaký odesílatel (B) poslat zprávu A, zjistí si jeho veˇrejný klíˇc (n; e) a data zašifruje funkcí c = me mod n, kde m je zpráva menší než n. Následnˇe B pošle A zašifrovanou zprávu c. A k dešifrování použije funkci m = cd mod n. K digitálnímu podpisu se užívá opaˇcného postupu. Pokud A chce podepsat dokument m, vytvoˇrí jeho kontrolní souˇcet (hash) a zašifruje ho svým soukromým klíˇcem. Toto muže ˚ kdokoliv dešifrovat veˇrejným klíˇcem, který získá od A, a ovˇerˇ it si tak, že dokument m psal opravdu A. Algoritmus RSA je stále považován za bezpeˇcný, i když se objevují teoretické možnosti, jak by se mohl v budoucnu dát rozlomit na kvantových poˇcítaˇcích. Prozatím však staˇcí, aby klíˇc byl velký alesponˇ 1024 bitu, ˚ aby jej nebylo možné souˇcasnými prostˇredky rozlomit. Rychlost šifrovacích funkcí je mnohem pomalejší než u symetrického algoritmu AES. Pro zvýšení bezpeˇcnosti je u RSA používá vyplnovací ˇ schéma. Zpráva m = 0 je vždy šifrována jako 0, bez ohledu na exponent i modulus. Stejnˇe tak je tomu i s m = 1. Vyplnovací ˇ schéma umožnuje ˇ pˇred vlastním šifrováním zprávu m vyplnit dodateˇcnými hodnotami tak, aby nikdy neklesla pod bezpeˇcnou úroven. ˇ To zárovenˇ stˇežuje slovníkové útoky, tedy porovnávání šifrovaných dat s šifrovanými bˇežnými slovy. 3.2.4 Rabin Žádoucí vlastností každého šifrovacího algoritmu je jeho obtížné prolomení. O Rabinu se mluví jako o pˇríkladu opravdu bezpeˇcného algoritmu. Jeho bezpeˇcnost je založena na ob29

3.3. ŠIFROVÁNÍ V JAVA ME tížnosti faktorizace, stejnˇe jako napˇrí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íˇcu˚ je tˇreba vytvoˇrit dvˇe náhodná velká prvoˇcísla p a q, která jsou pˇribližnˇe stejnˇe velká. Následnˇe se spoˇcítá cˇ íslo n = pq. Veˇrejný klíˇc je cˇ íslo n a soukromý klíˇc je dvojice (p; q). Komunikace, pak probíhá následovnˇe: 1. odesílatel (A) si zjistí veˇrejný klíˇc n pˇríjemce(B) 2. zpráva m musí být menší než n 3. A spoˇcte cˇ íslo c = m2 mod n 4. A pošle B cˇ íslo c 5. B zjistí cˇ tyˇri odmocniny m1 , m2 , m3 , m4 z cˇ ísla c mod n speciálním algoritmem 6. puvodní ˚ práva m je jedna z m1 , m2 , m3 , m4 . B nˇejakým zpusobem ˚ rozhodne která. Pro jednoduchost zde není uveden algoritmus pro výpoˇcet odmocnin, který je však lehce dostupný. V posledním kroku je ale další nejasnost. Jak rozhodnout, která z odmocnin repreˇ zentuje puvodní ˚ data? Rešení této otázky je ponecháno na každé konkrétní implementaci. Nejˇcastˇeji se však pˇridává na konec zprávy pevný poˇcet bitu˚ ze zaˇcátku zprávy. Správný korˇ en je poté ten, který má pˇríslušných poˇcet bitu˚ na zaˇcátku i na konci shodný. Pokud existuje více takových koˇrenu, ˚ pak je c odmítnuto jako podvržené. Algoritmus Rabin je pˇri š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á cˇ ínská vˇeta o zbytcích. Výrazné rozšíˇrení algoritmu brzdí i fakt, že je tˇreba dalších výpoˇcetních nákladu˚ na vybrání správného výsledku. 3.2.5 Eliptické kˇrivky Eliptické kˇrivky jsou pˇredmˇetem zkoumání déle než 150 let. Jejich využití v kryptografii se však zkoumá až posledních 20 let. Bezpeˇcnost algoritmu˚ je založena na úloze diskrétního eliptického logaritmu. Výhodou je vysoká rychlost šifrování i dešifrování oproti bˇežným symetrickým i asymetrickým algoritmum, ˚ také softwarové i hardwarové nároky jsou mnohem menší. Algoritmy využívající eliptické kˇrivky se zaˇcí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ˇcasných, zatím bezpeˇcnostnˇe dostaˇcujících, algoritmu˚ symetrické a hlavnˇe asymetrické kryptografie. V budoucnu se ale jistˇe doˇckáme jejich masivního využití.

3.3

Šifrování v Java ME

Šifrování v mobilních zaˇrízeních je rˇ ešeno úˇcelovˇe pro ovˇerˇ ování podpisu, ˚ práci s certifikáty a šifrování sít’ového spojení. Vše je rˇ ešeno na úrovni firmwaru nebo operaˇcního systému. 30

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ˇreba provádˇet v rámci vlastních knihoven, nebo knihoven tˇretí strany. U platformy Java ME je také tˇreba brát ohled na omezené zdroje i výkon. Vhodné jsou proto zejména symetrické šifry, které nevyžadují tolik systémových prostˇredku, ˚ ale poskytují dostateˇcnou bezpeˇcnost. Asymetrické šifry pracují s velkými cˇ í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

Kapitola 4

Vývoj aplikace Sybek Následující kapitola je vˇenována postupum ˚ pˇri vývoji aplikace Sybek, která umožnuje ˇ zasílání šifrovaných zpráv mezi mobilními zaˇrízeními. Aplikace je urˇcená pro mobilní zaˇrízení, které umožnují ˇ bˇeh Java ME aplikací a obsahují konfiguraci CLDC 1.1 a profil MIDP verze alesponˇ 2.0.

4.1

Požadavky na systém

Spojení mezi dvˇema mobilními telefony probíhá vˇetšinou šifrovanˇe. Šifruje se spojení mezi vysílaˇcem a telefonem volajícího, interní pˇrenos sítí i spojení mezi telefonem pˇríjemce a jiným vysílaˇcem. Aˇckoliv se spojení zdá bezpeˇcné, je možné jej vcelku jednoduše odposlouchávat. Každý cˇ lovˇek tak ztrácí jistotu svého soukromí. Je tedy potˇreba vyvinou aplikaci, která by dokázala zajistit bezpeˇcnou komunikaci mezi mobilními zaˇrízeními. Hlavní funkˇcní požadavky na aplikaci: •

musí dokázat šifrovat zprávy

•

musí odesílat i pˇrijímat zprávy

•

musí umˇet pracovat se zprávami (vytváˇret, ukládat, mazat, upravovat a odesílat)

•

musí umožnovat ˇ uložení kontaktu˚ (telefonních cˇ ísel se jmény)

•

mˇela by komunikovat i pˇres bluetooth

•

mohla by pracovat se zprávami typu MMS

•

mohla by šifrovat i hovory

Hlavní nefunkˇcní požadavky na aplikaci: •

musí být pˇrenositelná

•

musí být bezpeˇcná

•

mˇela by být rychlá

•

mˇela by mít intuitivní ovládání 32

4.2. ANALÝZA SYTÉMU Podle zadaných požadavku˚ lze nyní sestrojit diagram pˇrípadu˚ užití, který by mˇel vystihovat chování systému:

pozn.: Detailní popis pˇrípadu˚ užití je v pˇríloze A.

4.2

Analýza sytému

Podle požadavku˚ 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ˇrízení. Ukládání a cˇ tení dat proto musí zapouzdˇrovat jedna tˇrída, aby bylo možné jednoduše zvolit mezi místem ukládání. Aby byla tˇrída co nejvíce univerzální, bude vhodné k pˇredávání dat použít nˇejaké univerzální rozhraní. Aby byla aplikace uživatelsky pˇrívˇetivá, mˇel by uživatel mít možnost mˇenit její chování prostˇrednictvím nastavení. Nastavení bude koncentrováno v jedné, pravdˇepodobnˇe statické, tˇrídˇe. Ta bude implementovat rozhraní, které ji umožní ukládání do databáze. K práci s kontakty bude sloužit další tˇrída, která bude obstarávat základní manipulaci s kontaktem, tedy jeho vytvoˇrení, uložení do databáze, nastavení nových hodnot atd. Pro práci se zprávami je opˇet tˇreba vytvoˇrit tˇrídu, která bude zajišt’ovat základní práci se 33

4.2. ANALÝZA SYTÉMU zprávou. Také musí implementovat rozhraní, které umožní ukládat zprávu. Navíc je tˇreba, aby bylo možné zprávy šifrovat. Tuto funkcionalitu je vhodné pˇresunout do další tˇrídy, která muže ˚ být využívána. Posílání dat je vhodné také vyˇclenit, nebot’ data mohou být poslána více zpusoby ˚ (jako SMS nebo pˇres bluetooth). Pˇríjem dat musí obstarávat další tˇrída, jejíž funkce bude volána mobilním zaˇrízením pˇri pˇríchodu zprávy. Podle pˇredchozích pˇredpokladu˚ by mohl analytický diagram tˇríd vypadat pˇribližnˇe takto:

Význam a funkce jednotlivých tˇríd: •

Menu je tˇrí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áˇri aplikace. Umožnuje ˇ provádˇení 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žnuje ˇ jejich zmˇenu a stará se o uložení. 34

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žnuje ˇ jejich zmˇeny, cˇ tení i mazání.

•

Sender zajišt’uje odeslání dat zvoleným kanálem.

•

Receiver slouží k pˇríjmu zpráv, které pˇrijdou na mobilní zaˇrízení.

•

CryptoUtils je tˇrída, která se stará o šifrování dat.

4.3

Návrh systému

Podle pˇredchozích požadavku˚ je nutné vytvoˇrit aplikaci s intuitivním ovládáním. Funkce by mˇely být pˇrehlednˇe seskupeny a mˇely by nabízet maximální možnou funkcionalitu, kterou u takové aplikace lze oˇcekávat. Návrh hlavních funkcí systému, který nastinuje ˇ základní funkcionalitu i uživatelské prostˇredí, je znázornˇen na následujících stavových diagramech.

Obrázek 4.1: Stavový diagram podsystému pro práci se zprávami

35

4.4. IMPLEMENTACE SYSTÉMU

Obrázek 4.2: Stavový diagram podsystému pro práci s kontakty

4.4

Implementace systému

Vˇetšina puvodních ˚ požadavku˚ na systém se podaˇrila implementovat a výsledkem dlouhého vývoje je aplikace Sybek. Jedná se o aplikaci urˇcenou pro mobilní zaˇrízení s platformou Java ME. Ke své cˇ innosti vyžaduje konfiguraci CLDC 1.1, profil MIDP 2.0 a nˇekteré rozšiˇrující balíˇcky, které však nejsou nutné pro základní funkˇcnost aplikace, ale díky nim je možné napˇríklad komunikovat pˇres bluetooth. Následující obrázek zobrazuje diagram nasazení systému:

Aplikace Sybek dokáže posílat textové zprávy v šifrované podobˇe jako bˇežnou SMS i pˇres bluetooth spojení. K šifrování je využívána kvalitní implementace nejpoužívanˇejších 36

4.4. IMPLEMENTACE SYSTÉMU algoritmu. ˚ 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ˇrit jednoduchý prototyp a otestovat jej na mobilních telefonech i v emulátoru. Teprve pak byly tyto funkce zaˇclenˇeny do aplikace. Tím se také zjednodušilo závˇereˇcné testování celé aplikace.

4.4.1 Uživatelské prostˇredí Pro zobrazování uživatelského prostˇredí bylo zámˇernˇe zvoleno vysokoúrovnové ˇ API, aby byla zaruˇcena maximální pˇrenositelnost. U starších telefonu˚ by navíc složitá grafika mohla zbyteˇcnˇe zpomalovat celou aplikaci. V implementaci jsou tak využity pouze standardní komponenty zobrazující grafické uživatelské prostˇredí.

(a)

(b)

(c)

Obrázek 4.3: Ukázky menu na ruzných ˚ emulátorech Menu aplikace je realizováno jednoduchým seznamem akcí, který je zobrazen tˇrídou List. Pohyb v nˇem je možný pomocí standardního joysticku na mobilním telefonu. K navigaci je možné využívat i speciální tlaˇcítka, které telefon poskytuje, napˇríklad zvláštní tlaˇcítko pro akci zpˇet. Obrazovky s kombinovaným vstupem jsou zobrazeny pomocí tˇrídy Form. Ta zobrazuje textová políˇcka (telefonní cˇ íslo, heslo, jméno) nebo výbˇer hodnoty (zaškrtnutí více, vybrání jedné). K editaci textu je použita tˇrída TextBox, která mimo oˇceká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ˇetšinou se jedná o zapínání a vypínání prediktivního psaní, vkládání speciálních symbolu, ˚ smajlíku˚ atd. Pˇri psaní zprávy tak máte k dispozici témˇerˇ všechny funkce, jako u psaní SMS pˇrímo v telefonu. 37

4.4. IMPLEMENTACE SYSTÉMU 4.4.2 Ukládání dat O ukládání veškerých dat i uživatelského nastavení se stará tˇrída DatabaseReaderWriter. Její hlavní úˇcel je odstínit práci s úložným prostorem od ostatní funkcionality aplikace. S daty se pracuje prostˇrednictvím rozhraní DatabaseItem, což zajišt’uje univerzální použití této tˇrídy. Hlavní úˇcel návrhu tohoto rˇ ešení je možnost jednoduše mˇenit datové úložištˇe a to i za bˇehu aplikace. K ukládání dat se v souˇcasné implementaci využívá RMS, jehož kapacita muže ˚ být znaˇcnˇe omezená. Její velikost záleží na konkrétním telefonu a výrobci. Dnes je u vˇetšiny zaˇrízení sdílená s pamˇetí telefonu, takže její velikost bývá 5 MB a více. Toto však není zaruˇceno a telefon muže ˚ mít velikost RMS napˇríklad jen 1 MB. Pro tento pˇrípad je vhodné mít možnost ukládat data do souborového systému nebo na pamˇet’ovou kartu, kde je místa dostatek. Z cˇ asových duvod ˚ u˚ však tato funkcionalita v souˇcasné verzi nebyla implementována, vždy je použito RMS, ale aplikace je pˇripravena na jednoduché pˇridání této funkce. V aplikaci se ukládají tˇri ruzné ˚ typy objektu: ˚ zprávy, kontakty a nastavení. Tˇrídy, které zajišt’ují ukládání tˇechto objektu, ˚ musí implementovat rozhraní DatabaseItem. Ukládaná data jsou reprezentována polem bytu. ˚ K pˇrevodum ˚ souží metody toByteArray() a parse(byte[]). Každý objekt má své jedineˇcné cˇ íslo v rámci dané databáze. Toto cˇ íslo je pˇridˇeleno pˇri ukládání dat, objektu je nastaveno pomocí metody setDatabaseID(int). Rozhraní ještˇe definuje metody pro porovnávání, rˇ azení a jiné.

4.4.3 Textové zprávy Aby se aplikace spustila po pˇríchodu zprávy, je nutné ji instalovat. Instalace se provádí standardní postupem popsaným výše. Tím si aplikace zarezervuje pˇríchozí zprávy na portu ˇ 16961. Císlo portu je zapsáno v deskriptoru aplikace, v pˇrípadˇe kolize s jinou aplikací je možné cˇ íslo bˇežným editorem zmˇenit a aplikaci pˇreinstalovat. Pˇríchozí zprávy obsluhuje tˇrída SMSReceiver. Zpráva je nejprve pˇreˇctena z otevˇreného spojení, které aplikaci pˇredá aplikaˇcní manažer. Pokud je pˇrenos dat úspˇešný, zpráva se uloží do databáze a uživatel je informován o pˇrijetí nové SMS. Všechny zprávy jsou uloženy v jedné databázi a pomocí pˇríznaku je u každé rozlišeno, zda je pˇrijatá, odeslaná nebo v archívu. Navíc je možné rozlišit pˇreˇctenou a nepˇreˇctenou zprávu nebo odeslanou a neodeslanou. Podle pˇríznaku je uživatel vidí v pˇríslušné podsložce a s urˇcitou ikonou. Každá zpráva se dá samozˇrejmˇe editovat, cˇ íst, smazat, pˇresunout atd. Nˇekteré funkce záleží i na nastaveném pˇríznaku. Pˇri psaní nové zprávy je uživateli mimo standardních funkcí nabídnuta možnost zhuštˇení a rozpuštˇení textu. Jedná se o funkce, které již nabízí nˇekolik mobilních telefonu˚ pˇri psaní zpráv, ale nejsou nijak bˇežné. Funkce z textu vypustí všechny mezery a poˇcáteˇcní písmeno každého slova pˇrevede na velké. Tak je text cˇ lovˇeku dobˇre cˇ itelný, ale zpráva je o 10%-20% kratší. Druhá funkce plní opaˇcnou funkci, tedy text takového formátu pˇrevádí zpˇet na bˇežný text. Jinou funkcí je možné do textu vložit údaje z lokálního adresáˇre aplikace. 38

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ˇríklad jen telefonní cˇ íslo a jméno). Další užiteˇcnou funkcí je možnost komprimace textové zprávy. Takto komprimovaná zpráva není cˇ itelná jako obyˇcejná SMS, ale binární zpráva. Kompresi provádí tˇrída SMSCompressor, která jej pˇrevede do binární podoby. Bˇežný text tak dokáže zmenšit na 70%-80% puvodní ˚ velikosti (mˇerˇ eno v binární podobˇe). Pˇresná úˇcinnost komprese záleží na konkrétním textu, použití diakritiky a speciálních symbolu. ˚ Zprávu je samozˇrejmˇe možné pˇred odesláním zašifrovat. Pokud uživatel vyhledá telefonní cˇ íslo pˇríjemce v adresáˇri aplikace, použije se automaticky heslo pro tento kontakt. Jinak je nutné zadat heslo ruˇcnˇe, nebo zprávu nešifrovat. K odesílání zpráv slouží tˇrída SMSSender, pro pˇrenos pˇres bluetooth je to BlueToothDataSender. Tyto jednoduché tˇrídy se už starají jen o odeslání pole bytu˚ a zobrazí informace uživateli o úspˇechu cˇ i neúspˇechu. 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ˇríjemce musí mít nainstalován Sybek, aby si mohl zprávu zobrazit. Zprávu v cˇ isté podobˇe je možné poslat na jakýkoliv mobilní telefon a ten by ji mˇel standardnˇe pˇrijmout a zobrazit. 4.4.4 Lokální adresáˇr Aplikace uživateli umožnuje, ˇ aby si uložil vlastní kontakty. U každého kontaktu je evidováno jméno, telefon, emailová adresa a pˇrípadnˇe heslo. Heslo muže ˚ být sdílené tajemství pro symetrickou šifru nebo veˇrejný klíˇc daného pˇríjemce urˇcený k asymetrickému šifrování. Kontakty lze samozˇrejmˇe prohlížet, editovat i mazat. Oˇcekávanou funkcí, která ovšem v aplikaci není implementována, je možnost pracovat s kontakty z adresáˇre mobilního telefonu. V dnešní dobˇe již vˇetšina telefonu˚ podporuje i ukládání hesel do adresáˇre, proto se zdá být interní adresáˇr aplikace naprosto zbyteˇcný. Existují však dva duvody ˚ jeho existence. Patrnˇe nikdo si nebudete šifrovanˇe dopisovat pˇres 39

4.4. IMPLEMENTACE SYSTÉMU Sybek s desítkami lidí, proto zadání nˇekolika cˇ ísel není takový problém. Navíc je tak možné používat soukromá cˇ ísla, která nejsou uložena v adresáˇri telefonu. Ale hlavní duvod ˚ je jiný. K pˇrístupu do adresáˇre je nutný rozšiˇrující balíˇcek PDA Optional Packages (JSR-75), který hodnˇe telefonu˚ nepodporuje. Navíc telefony, které jej implementují, neposkytují pˇrístup do adresáˇre neduvˇ ˚ eryhodným MIDletum. ˚ Aplikace by tedy musela být ještˇe digitálnˇe podepsaná. Vzhledem k tomu, že na žádném z testovacích telefonu˚ se nepodaˇrilo pˇristoupit do adresáˇre, byla funkce radˇeji vypuštˇena, nebot’ ji nebylo možné vubec ˚ otestovat. 4.4.5 Bluetooth komunikace Spojení pˇres bluetooth zajišt’uje tˇrí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ˇrízení, zjistit jejich adresy a nezbytné informace. K tomu slouží metoda findDevices(), která spustí prohledávání okolí. Adresy zaˇrízení, které jsou dostupné a pˇripraveny ke spojení, poskytuje metoda getFoundedDevices(). Kdykoliv je také možné zjistit aktivní zaˇrízení z pˇredchozího hledání pomocí metody getCachedDevices(). Každý mobilní telefon má navíc seznam uložených zaˇrí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ˇrízení Aby bylo možné poslat zprávu mezi dvˇema aplikacemi na ruzných ˚ zaˇrízeních, je nutné v Sybeku spustit službu, která bude cˇ ekat na vzdálené spojení pˇres bluetooth. Vytvoˇrení bluetooth služby a její nastavení se provádí metodami createService(), setServiceAttribute(), runServiceListening() a stopService(). V pˇrípadˇe, že se nˇejaké vzdálené zaˇrízení pˇripojí, vyvolá se pˇríslušná metoda posluchaˇce služby. Pak mohou zaˇrízení obousmˇernˇe komunikovat pˇres bˇežný datový proud. Tˇrída BlueToothDriver poskytuje i metody pro vyhledávání aktivních služeb na každém zaˇrízení. Pokud uživatel posílá zprávu, aplikace vyhledá aktivní zaˇrízení, která mají spuštˇenou službu pro pˇríjem zpráv (speciální služba Sybeku), zobrazí je uživateli a ten si 40

4.4. IMPLEMENTACE SYSTÉMU muže ˚ zvolit, kam chce zprávu poslat. Zaˇrízení se spojí se službou, pošle data a odpojí se. Zasílání a pˇríjem souboru˚ probíhá stejnˇe, pouze se využívá standardní služby OBEX, takže komunikace muže ˚ probíhat i s bˇežným telefonem nebo poˇcítaˇcem. O pˇríjem dat z bluetooth komunikace se starajá BTReceiverSMS a BTReceiverFile, každá tˇrída pˇrijímá data z jiné bluetooth služby. Po pˇrijetí se starají o rˇ ádné uložení do databáze nebo souborového systému a o informování uživatele. 4.4.6 Šifrování dat K bezpeˇcnému zašifrování dat je potˇreba dobrý algoritmus a jeho dobrá implementace. ˇ Casto se stává, že se povede rozluštit data šifrovaná kvalitním kryptografickým algoritmem, protože je chyba v nˇejaké konkrétní implementaci tohoto algoritmu. Z tohoto duvodu ˚ jsou v aplikaci Sybek k šifrování dat použity knihovny tˇretí strany, aby byla zaruˇcena maximální bezpeˇcnost. Konkrétnˇe se jedná o knihovny z Bouncy Castle Crypto APIs1 , které jsou považovány za velmi kvalitní a bezpeˇcné. Šifrovací API umožnuje ˇ práci s mnoha algoritmy, poskytuje užiteˇcné funkce a pˇrepisuje nˇekteré standardní knihovny. Z duvodu ˚ minimalizace byly do aplikace pˇridány jen nejnutnˇejší knihovny pro práci se dvˇema vybranými algoritmy. Jeden algoritmus pro symetrické šifrování a druhý pro šifrování s veˇrejným klíˇcem. Navíc bylo nutné pˇridat tˇrídu BigInteger pro práci s velkými cˇ ísly a tˇrídu SecureRandom, která lépe generuje náhodná cˇ ísla. Pro šifrování bylo nutné zvolit bezpeˇcný, ale hodnˇe rychlý algoritmus, který navíc potˇrebuje k bˇehu minimum systémových prostˇredku. ˚ Takové jsou symetrické šifry. Z jejich rˇ ad byl vybrán, jako ideální rˇ ešení, algoritmus AES. V reálném mobilním telefonu pˇri šifrování nedochází témˇerˇ k žádnému zpoždˇení. Aby bylo možné šifrovat i pomocí klíˇce, byl do aplikace doimplementován algoritmus RSA. Jeho použitelnost na bˇežném telefonu však zatím není pˇríliš možná. Práce s tak velkými cˇ ísly není ještˇe pro mobilní telefon vhodná, nˇekteré ji díky omezené pamˇeti ani nezvládnou. Kompletní práci se šifrováním zapouzdˇruje tˇrída Crypter, která využívá metod balíku z Bouncy Castle. Pomocí statických metod lze jednoduše zašifrovat i dešifrovat data jedním ze dvou algoritmu. ˚ Pro pˇrípadné využívání asymetrického šifrování nabízí i možnost vygenerování dvojice klíˇcu. ˚ 4.4.7 Nastavení a další funkce Uživatel má možnost ovlivnit chování systému pomocí základního nastavení. Technologie bluetooth muže ˚ zbyteˇcnˇe spotˇrebovávat baterii, pokud se nepoužívá, proto je možné jednotlivé služby povolit nebo zakázat. Lze také upravit výchozí nastavení tˇechto hodnot, aby se aplikovali ihned po startu aplikace. Pro práci se souborovým systémem je vhodné nastavit výchozí adresáˇr. V sekci kryptografie je nastavení a funkce týkající se klíˇce k asymetrickému šifrování. 1. http://www.bouncycastle.org

41

4.5. TESTOVÁNÍ Dále je možné nastavit vibrace a blikání displeje pˇri pˇrijetí nové zprávy. Uživatel také muže ˚ zvolit, zda se mají odeslané zprávy ukládat nebo ne. Pˇri odesílání je nutné zadat nˇekteré volby (zda šifrovat a komprimovat), ty lze také pˇrednastavit. Dobrou funkcí muže ˚ být i možnost varování, že text je delší než jedna SMS. Pokud telefon podporuje pˇrístup do souborového systému a komunikaci s bluetooth prostˇrednictvím OBEX, muže ˚ uživatel šifrovat i soubory a posílat je na jiná zaˇrízení pˇres bluetooth. Takové soubory je možné samozˇrejmˇe i pˇrijímat.

4.5

Testování

Aplikace je urˇcena pro libovolné mobilní zaˇrízení, které splnuje ˇ minimální požadavky, které byly uvedeny výše. Vývoj byl však zamˇerˇ en hlavnˇe pro využití na mobilních telefonech. Testování aplikace bylo tedy omezeno jen na testy v mobilních telefonech. Testování aplikace bylo provedeno nejen na reálných telefonech, ale i v emulátorech, které poskytují výrobci. Chování emulátoru konkrétního telefonu by se nemˇelo lišit od skuteˇcného chování v reálném zaˇrízení. Jediný problém je u simulací sítˇe a sít’ových spojení. Zde není simulace úplnˇe vˇerohodná, proto je vždy tˇreba aplikaci testovat i reálným použitím. Aplikace byla otestována na nˇekolika mobilních telefonech ruzných ˚ výrobcu. ˚ Nejprve byla testována základní funkcionalita aplikace, tedy posílání a pˇríjem textových zpráv formou bˇežné SMS. U všech telefonu˚ aplikace fungovala dle oˇcekávání a fungovala výbornˇe. S pˇrístupem do souborového systému a prací s kontakty také žádný telefon nemˇel problém. Pˇri testování aplikace se všichni uživatelé pohybovali v aplikaci naprosto pˇrirozenˇe, lze proto usoudit, že aplikace má intuitivní uživatelské prostˇredí. U práce s asymetrickými klíˇci aplikace na nˇekterých mobilních telefonech padala, pravdˇepodobnˇe v dusledku ˚ nedostatku pamˇeti. Šifrování se symetrickým klíˇcem však funguje všude bez vˇetších problému. ˚ Další problémy se vyskytly u testu˚ komunikace pˇres bluetooth. Telefony jistého výrobce totiž implementují je cˇ ást standardu JSR-82 (APIs for Bluetooth). Jeden telefon pˇri inicializaci bluetooth vždy bezduvodnˇ ˚ e "zamrzl" a po delší dobˇe pokraˇcoval v práci. Pˇres toto se podaˇrilo úspˇešnˇe otestovat i funkˇcnost zasílání zpráv pˇres bluetooth. Testování základních funkcí aplikace dopadlo úspˇešnˇe. Problémy nˇekterých mobilních telefonu˚ s komunikací pˇres bluetooth by mohla vyˇrešit lite verze, která by obsahovala jen základní funkce. Tato verze by tak byla použitelná i pro telefony bez podpory bluetooth. Její velikost by však nemˇela, na rozdíl od standardní verze, pˇresáhnout 128 KB, nebot’ starší telefony vˇetší aplikace nezvládnou.

42

Kapitola 5

Závˇer Komunikace pˇres mobilní zaˇrízení bude stále cˇ astˇejší a její bezpeˇcnosti bude pˇrikládán stále vˇetší duraz. ˚ V souˇcasné dobˇe je ještˇe co dohánˇet. Textové zprávy i volání je možné odposlouchávat, proto je tˇreba do budoucna zajistit, aby mˇel každý cˇ lovˇek možnost zachovat si své soukromí. Úˇcelem této práce bylo vytvoˇrit aplikaci, která dokáže šifrovat komunikaci mezi mobilními zaˇrízeními. Jejím cílem bylo poskytnout uživatelum ˚ možnost chránit svá data. Výsledkem práce je aplikace Sybek, která šifruje data a tak zabranuje ˇ možnému odposlechu nepovolanou osobou. Bezpeˇcnost šifrování je založena na spolehlivé implementaci šifrovacích algoritmu˚ duvˇ ˚ eryhodných tvurc ˚ u. ˚ Výsledná aplikace je jednoduchá a pˇrehledná, ale efektivní a úˇcinná. Její využití je proto vhodné nejen pro zkušené uživatele, ale i bˇežné laiky, kteˇrí si s technikou tolik nerozumí. Aplikace je napsána tak, aby byla použitelná prakticky pro jakékoliv bˇežné mobilní zaˇrízení. Instalace a bˇeh na jakémkoliv zaˇrízení by nemˇely cˇ init problémy. S dalším vývojem techniky se snad doˇckáme i možnosti šifrování hlasu. Bud’ bude šifrování probíhat na hardwarové úrovni, nebo alesponˇ budou zaˇrízení tak výkonná, že bude možné toto provádˇet v rámci nˇejaké aplikace. Prozatím budeme muset jen doufat, že ta doba pˇrijde brzy. Aˇckoliv je aplikace funkˇcní a dostaˇcující, nabízí se spousta možností, jak ji vylepšit. Napˇríklad podpora multimediálních zpráv by se mohla hodit. Zaˇrízení implementující Wireless Messaging API 2.0 (JSR-205) jíž obsahují knihovny pro práci s MMS. Prozatím je možné posílat alesponˇ soubory pˇres bluetooth. Do budoucna bude jistˇe dobré doimplementovat i pˇrístup do adresáˇre mobilního telefonu a tak uživatelum ˚ umožnit zasílání zpráv i lidem, které nemají uloženy v aplikaci a nepamatují si jejich cˇ íslo. Za zvážení stojí i možnost ukládání dat do souboru v souborovém systému mobilního zaˇrízení, což však muže ˚ být implementaˇcnˇe nároˇcnˇejší. Domnívám se, že cíl diplomové práce se podaˇrilo realizovat úspˇešnˇe. Aplikace je pˇripravena k reálnému nasazení a doufám, že bude také hojnˇe využívána.

43

Literatura [1] Java ME Technology, Sun Microsystems, Inc., . [2] Java ME Technology APIs & Docs, Sun Microsystems, Inc., . [3] Java Specification Requests, . [4] Java ME Technical Tips, Sun Microsystems, Inc., . [5] C. Enrique Ortiz: Summary of CLDC-Based Profiles, Sun Microsystems, Inc., June 22, 2006, . [6] C. Enrique Ortiz: Obfuscating Your MIDlet Suite, Sun Microsystems, Inc., October 2006, . [7] Java ME, . [8] Darryl L. Pierce.: The JavaME Frequently Asked Questions List, . [9] The Legion of the Bouncy Castle, bouncycastle.org, . [10] Mgr. Michal Vocu: ˚ Bezpeˇcnost poˇcítaˇcových systému˚ 2., . [11] A. J. Menezes: P. C. van Oorschot: S. A. Vanstone: Handbook of Applied Cryptography, CRC Press, 1996, . [12] Elliptic curve cryptography, Certicom Inc., . [13] Bittnerová, Lucie Rút: J2ME v kostce, ZONER software, s.r.o., . [14] Michael Juntao Yuan: Data security in mobile Java applications, JavaWorld.com, 20.12.2002, . [15] Kryptografie, Wikipedie, . [16] Bloch Joshua: Java efektivnˇe - 57 zásad softwarového experta, Grada Publishing, 2002, 80-247-0416-1. 44

Pˇríloha A

Popis pˇrípadu˚ užití

45

ˇ ˚ UŽITÍ A. P OPIS P RÍPAD U

46


47


48


49

012345

Recommend Documents