Demonstrace šifrování na platformě Java Card

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce Demonstrace šifrování na platformě Java Card Bc. Petr Vlášek Vedoucí práce: Ing. Jiří Buček Studijní program: Elektrotechnika a informatika, strukturovaný magisterský Obor: Informatika a výpočetní technika Studijní plán: Softwarové inženýrství květen 2008

2 ii

3 Poděkování Tímto bych rád poděkoval rodině, přátelům, škole a vedoucímu práce, že mi umožnili pracovat nad danou problematikou. iii

4 iv

5 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne v

6 vi

7 Abstract The work describes the principles of smart cards based on Java Card platform. In this paper we discuss the Java Card security mechanisms and their vulnerabilities and the cryptography services provided by the platform to Java Card applets. The introduction to secure messaging and secure loading of applets as specified by Open platform is included too. Then this paper provides the analysis of the possibilities how to integrate the smart card topics to the cryptography courses and offers prepared exercises that through Java Card applets cover the work with cryptography services of the platform. This work includes the development of the library providing access to Java card, test tool for exercise applets and plug-in for NetBeans IDE that enables the functions like the applet loading on the card and provides support for Java Card applet development in NetBeans IDE. Abstrakt Práce popisuje principy technologie smart karet Java Card platformy. V tomto textu jsou diskutovány její mechanismy zabezpečení, možné slabiny a kryptografická podpora, kterou platforma poskytuje Java Card appletům. Připojen je také popis mechanismu zabezpečeného nahrávání appletů dle specifikace Open platform. Rozebrány jsou dále možnosti zapojení karet do výuky kryptografie a připraveny demonstrační úlohy pro práci s kryptografií v Java Card appletech. V rámci práce byla vytvořena knihovna pro přístup k Java kartám, testovací nástroj pro applety úloh a plug-iny pro vývojové prostředí NetBeans, které umožňují nahrávat applety na kartu a podporují vývoj Java Card appletů v rámci NetBeans. vii

8 viii

9 Obsah 1 Úvod Aplikace smart karet...2 Analýza 2 Java Card platforma Vlastnosti Java Card platformy APDU komunikace s appletem Zdrojový kód appletu Překlad a nahrávání appletu na kartu Zabezpečení Java Card Platformy Mechanismy zabezpečení platformy Java Card Bezpečnost jazyka Java na platformě Java Card Applet Firewall Atomické operace a transakční zpracování Útoky na zabezpečení platformy Java Card Opatření pro podporu bezpečnosti platformy Java Card Hardwarové zabezpečení karet platformy Java Card Java Card cryptography API Návrh a vlastnosti Java Card cryptography API Třídy a rozhraní Java Card cryptography API Práce s Java Card cryptography API Specifikace Open Platform Role entit na kartě definované Open Platform Nahrávání a instalace aplikací Zabezpečení v Open platform Open platform API Global platform Karta GemXpresso Pro R Obecná charakteristika karty Zabezpečení Kryptografické klíče Podporované algoritmy a klíče Java Card Crypto API Applet GemSafe Funkce appletu GemSafe Spuštění appletu GemSafe Využití appletu GemSafe ve výuce Jiná podobná řešení...48 Řešení a realizace 8 Příprava úloh pro výuku...49 ix

10 8.1 Zahrnutí Java karet do výuky Úlohy pro výuku Podpůrná aplikace pro testování appletů úloh Aplikace Java Card image manager Knihovna SimpleSmartCardAPI Analýza existujících řešení a požadavky kladené na knihovnu Architektura a návrh knihovny SimpleSmartCardAPI Příklady použití knihovny SimpleSmartCardAPI Ukázky implementace Testování Využití dalších zdrojů Vývoj NetBeans plug-inů Tvorba plug-inů pro vývojové prostředí NetBeans Java Card Manager plug-in Java Card Project plug-in Závěr Seznam použité literatury...93 A Zabezpečení Open platform...95 A.1 Kryptografické algoritmy...95 A.2 Kryptografické klíče Open Platform...96 A.3 Zabezpečená komunikace...98 A.4 Vzájemná autentikace (Mutual authentication)...99 A.5 APDU příkazy pro vytvoření zabezpečeného kanálu A.6 Integrita A.7 Šifrování A.8 Šifrování a dešifrování klíčů A.9 Kontrola na kartu nahrávaného obsahu A.10 Delegovaná správa obsahu B Úloha DES šifrování Zadání Testování v aplikaci JavaCard Exercise Manager Zdrojový kód applet úlohy DES šifrování C Implementace záložky DES cvičení D Implementace bezpečného kanálu E Návod k NetBeans plug-inům Instalace Java Card Project plug-in Java Card Manager plug-in F Obsah přiloženého CD G Seznam zkratek x

11 Seznam ilustrací Seznam ilustrací Ilustrace 1: Struktura APDU příkazu...4 Ilustrace 2: Varianty komunikace...5 Ilustrace 3: Struktura APDU odpovědi...5 Ilustrace 4: Ilustrace sdílení objektů sdíleného rozhraní...14 Ilustrace 5: Neoprávněné poskytnutí objektu sdíleného rozhraní třetímu objektu...18 Ilustrace 6: Změna.cap souboru - instrukce 0x1A na 0x1B...22 Ilustrace 7: Proces nahrávání aplikace na kartu...39 Ilustrace 8: Scénář komunikace s appletem SimpleString...50 Ilustrace 9: Scénář komunikace s appletem DES úlohy...51 Ilustrace 10: Scénář komunikace s appletem úlohy RSA podpis...52 Ilustrace 11: Aplikace pro testování appletů úloh...54 Ilustrace 12: Aplikace Java Card image manager...56 Ilustrace 13: Základní pohled na architekturu přístupu ke kartě pomocí knihovny SimpleSmartCardAPI...62 Ilustrace 14: Seznam připojených karet v plug-inu Java Card manager...78 Ilustrace 15: Výpis obsahu karty v plug-inu Java Card manager...80 Ilustrace 16: Kompomenta APDU manager plug-inu Java Card manager...81 Ilustrace 17: Java Card projekt typ v NetBeans...85 Ilustrace 18: Průběh procesu vzájemné autentikace Ilustrace 19: Derivační data pro generování session klíčů Ilustrace 20: Generování session ENC klíče Ilustrace 21: Generování session MAC klíče Ilustrace 22: Proces generování MAC hodnoty pro ADPU příkaz Ilustrace 23: Proces šifrování dat APDU příkazu Ilustrace 24: Nahrávání nezabezpečené kontrolou integrity Ilustrace 25: Nahrávání zabezpečené kontrolou integrity Ilustrace 26: Nahrávání zabezpečené podpisem Ilustrace 27: Nahrávání zabezpečené podpisem třetí strany (RSA varianta) Ilustrace 28: Mechanismus delegované správy obsahu xi

12 xii

13 Seznam tabulek Tabulka 1: Třídy a rozhraní balíčku javacard.security...26 Tabulka 2: Třídy a rozhraní balíčku javacard.security (pokračování tabulky 1)...27 Tabulka 3: Třídy a rozhraní balíčku javacardx.crypto...27 Tabulka 4: Kryptografické klíče používané Card managerem...97 Tabulka 5: Kryptografické klíče používané Bezpečnostní doménou...97 xiii

14 xiv

15 KAPITOLA 1 Úvod 1 1 Úvod S rozvojem výpočetní techniky do oblastí každodenního života vznikají nové či dále roste důraz na existující požadavky týkající se například ochrany osobních dat či ověření identity uživatele. Tyto požadavky jsou řešeny kryptografickými prostředky. Již několik let aplikace výpočetní techniky a jejích softwarových systémů, popřípadě dalších elektrotechnických zařízení (např. mobilních telefonů) explicitně či transparentně využívají kryptografických metod k zajištění zabezpečení dat či ověřování uživatelů. Součástí těchto systémů často bývají také tzv. smart karty (neboli čipové karty), tedy karty opatřené mikroprocesorem a pamětí, na nichž jsou například uložena uživatelova soukromá data či soukromé kryptografické klíče. Vzhledem k pokrokům výpočetní techniky tyto karty dnes dokáží realizovat výpočetně náročné operace jako je například šifrování a je na nich tedy možné vykonávat části aplikační logiky celkového systému. Uživatelova soukromá data či kryptografické klíče tedy nemusejí vůbec opustit kartu a dostat se do potenciálně nebezpečného prostředí, protože veškeré operace nad nimi či jimi prováděné mohou být realizované prostředky karty přímo v zabezpečeném prostředí karty samotné. Vzhledem ke konvergenci a interoperabilitě počítačových a síťových systémů roste perspektiva využití smart karet jako obecně používaného média, jimiž dané systémy mohou ověřit identitu uživatele. Jelikož jsou smart karty často důležitou součástí kryptografických systémů, bylo v rámci inovace náplně předmětu Aplikovaná kryptografie vyučovaného Katedrou počítačů ČVUT FEL rozhodnuto zapojit tématiku smart karet do výuky tohoto předmětu a zejména zakoupit sadu karet a čteček, s nimiž by studenti mohli pracovat na cvičeních. V rámci grantu MŠMT Podpora výuky aplikované kryptografie (č.proj. 2525/2007) byly koupeny čtečky a karty GemXpresso od výrobce Gemalto, které jsou postaveny na dnes široce využívané a perspektivní platformě Java Card. Cílem této práce je provést rozbor funkčnosti platformy Java Card, jejího zabezpečení a kryptografických služeb, které nabízí. Na základě toho poté připravit demonstrace kryptografických služeb a vývoje aplikací na této platformě, které by bylo možné využít pro výuku. Jak se však v průběhu práce na daném tématu ukázalo, zvláštní pozornost bylo třeba věnovat i vývoji podpůrných nástrojů pro práci s kartami a podpůrných nástrojů pro vývoj kartových aplikací. Tyto by byly vhodné pro potřeby výuky, kdy studenti s kartami pracují bez předchozích znalostí principů, na nichž jsou kartové aplikace a práce s nimi založeny. Tímto je práce tématicky rozdělena do třech okruhů, které na sebe vzájemně navazují: Seznámení s platformou Java Card, principy jejího zabezpečení, kryptografickými službami, které nabízí a možnostmi zabezpečené správy obsahu karty. Příprava témat a úloh, jimiž mohou být smart karty zapojeny do výuky. Vývoj podpůrných nástrojů pro testování výukových úloh, intuitivní správu karty a podporu vývoje aplikací pro kartu. Součástí práce jsou též hotová znění výukových úloh, která byla použita na cvičeních předmětu Aplikovaná kryptografie v letním semestru akademického roku 2007/2008.

16 2 KAPITOLA 1 Úvod Kartou, která byla využívána pro převážnou většinu testů a experimentů spojených s vypracováním této práce, byla karta GemXpresso R3.2 E64 podporující verzi 2.1 platformy Java Card. Z tohoto důvodu je výklad, není-li uvedeno jinak, směřován k této verzi platformy Java Card. V pozdější dodávce karet byly dodány karty GemXpresso R4 podporující verzi 2.2 platformy, na nichž však bylo provedeno pouze testování funkčnosti již hotových aplikací a nástrojů. Z obsahových a časových důvodů se práce nevěnuje možnostem přinášeným touto verzí platformy (jako je například komunikace s kartou pomocí techniky Remote Method Invocation (RMI) či biometrického API určeného k ověřování uživatelů na základě biometrických údajů), protože z časových důvodů nebylo možné se s těmito novými funkcemi plně seznámit zejména formou přímých experimentů s nimi. Práce je zaměřena pouze na platformu Java Card a konkrétní oblasti s touto platformou spojené. Jejím záměrem není věnovat se například otázkám týkajícím se zabezpečení smart karet z hardwarového hlediska či jiným tématům spojeným se smart kartami, jichž se platforma Java Card přímo netýká. Pro širší a obecný pohled na problematiku smart karet včetně otázek týkajících se hardware lze doporučit např. [1]. 1.1 Aplikace smart karet Historie použití smart karet se datuje do začátku osmdesátých let 20. století, kdy byly poprvé nasazeny ve Francii jako předplacené telefonní karty. Toto jejich využití se stalo velmi populárním i v ostatních částech Evropy. Velkého rozmachu se karty dočkaly v telefonním průmyslu na počátku devadesátých let s příchodem standardu mobilní komunikace GSM, kdy začaly být využívány jako SIM moduly do mobilních telefonů. V těchto letech se též začaly uplatňovat jako identifikační karty pro vstup do míst s omezeným přístupem či jako elektronické peněženky (ve formě karet s přednabitým finančním kreditem), které se dále prosazovaly s příchodem internetu a elektronických nákupů. V sektoru bankovních karet se smart karty začaly prosazovat po polovině devadesátých let, kdy postupně začaly nahrazovat starší typy platebních karet s magnetickým páskem tedy technologii, která představovala pouze pasivní uložení identifikačních údajů. S přijímáním zákonů a norem o digitálním podpisu posléze začalo rozšiřování smart karet i coby úložišť soukromých klíčů a nástroje k podepisování. V dnešní době se smart karty používají v široké škále aplikací. Od zmiňovaných telefonních karet a SIM karet pro mobilní telefony nebo nejrůznější aplikace elektronických peněženek (čehož je např. s oblibou využíváno při velkých akcích typu olympijské hry, kdy návštěvníci mohou v areálech platit a prokazovat se kartou) se jedná o karty určené k ověřování držitele a digitálnímu podepisování, platební a kreditní karty, jízdenky městské hromadné dopravy, karty určené k dekódování placených televizních kanálů, karty zdravotního pojištění, na nichž mohou být uloženy i důležité údaje o zdravotním stavu držitele, tachografy, řidičské průkazy, na nichž je možné uchovávat informace o přestupcích řidiče, digitální pasy či digitální občanské průkazy. Příkladem použití smart karty je FINEID [2] smart karta použitá ve Finsku, která slouží jako občanský průkaz, ovšem zároveň je možné použít ji ke službám e-governmentu, digitálnímu podepisování, šifrování, pro přístup k bankovním službám a informačním systémům (např. informační systém univerzity) nebo jako karta zdravotního pojištění.

17 KAPITOLA 2 Java Card platforma 3 2 Java Card platforma Tato kapitola shrnuje základní koncepty platformy Java Card a seznamuje se základními rysy vývoje aplikací na této platformě. Na zde uvedené koncepty navazují další kapitoly. 2.1 Vlastnosti Java Card platformy Technologie Java Card adaptuje Java platformu pro smart karty (čipové karty) a jiná podobná zařízení (např. USB security tokeny). Stejně jako je rysem standardní platformy Java multiplatformost, i zde přináší Java Card platforma přednost napsání programu s jedním zdrojovým kódem v jazyku Java, který lze spouštět na jakýchkoli zařízeních podporujících Java Card a jeho běhové prostředí. Tento fakt značně usnadnil vývoj aplikací pro smart karty, jelikož před příchodem technologie Java Card se oblast smart karet vyznačovala mnoha specifiky při psaní aplikací pro karty různých výrobců jednalo se zejména o proprietární API, odlišné operační systémy, správu paměti, atd. Technologie Java Card vývoj aplikací zcela odstiňuje od rozdílů mezi kartami jednotlivých výrobců. Díky tomu se tedy jednak usnadnil a zefektivnil vývoj aplikací pro smart karty, ale také otevřel pro vývojáře třetích stran, kteří mohli začít poskytovat obecně funkční řešení pro karty jakéhokoliv výrobce. S tím souvisí i druhá výrazná přednost platformy Java Card, která se týká faktu, že na kartě může být přítomno několik různých (oddělených i spolupracujících) aplikací a lze je na kartu nahrávat kdykoliv během funkčního období karty. To přináší přednosti týkající se možnosti aktualizace aplikací či přidání funkčnosti kartě prostřednictvím nově nahrané aplikace, aniž by bylo nutné vydat novou sérii karet. Jedná se v současnosti o jednu z nejperspektivnějších platforem za rok 2007 bylo vydáno 1,2 miliardy smart karet na platformě Java Card a celkově jich za dobu existence této platformy bylo vydáno více než 3 miliardy. Specifikace Java Card platformy se skládá ze tří částí: Java Card API definuje framework, balíčky a třídy, které jsou použity při vývoji aplikací. Java Card virtual machine (JCVM) specifikuje podmnožinu jazyka Java používanou v Java Card a virtuální stroj. Java Card runtime environment (JCRE) definuje běhové chování platformy Java Card (správa paměti, bezpečnost aplikací). Na smart karty podporující Java Card může být nahráno několik aplikací, které se nazývají applety. Jednotlivé applety jsou od sebe izolované tzv. applet firewallem a pokud není explicitně uvedeno, nemají applety vzájemně přístup ke svým metodám, instancím a proměnným. Applety na kartě jsou rozlišovány pomocí tzv. AID (Application Identifier), což je hexadecimální identifikátor appletu. V okamžiku nahrání appletu na kartu vzniká na kartě tzv. Load soubor, což je nenainstalovaný applet. Procesem instalace na kartě vzniká instance appletu. Applet je sám pasivní a chová se jako server obsluhující požadavky, které jsou mu zaslány z terminálu či PC. Při vypnutí karty (tj. vyjmutí z terminálu či čtečky) je stav instance appletu zachován.

18 4 KAPITOLA 2 Java Card platforma V okamžiku vložení karty do terminálu, či čtečky, jsou všechny applety na kartě neaktivní, aktivní je pouze běhové prostředí, které přijímá požadavky týkající se obsluhy appletů a dat na kartě, tj. i požadavek na výběr konkrétního appletu pomocí jeho AID APDU příkazem SELECT. Jakmile je applet vybrán, pak jsou APDU příkazy přesměrovávány jemu. 2.2 APDU komunikace s appletem Komunikace mezi kartou a koncovým zařízením (čtečka, terminál, aplikace na pc, apod.) probíhá na základě předávání paketů dat specifického formátu zvaného APDU (Application Protocol Data Units). Rozlišují se dva typy APDU paketů: command APDU (příkaz) a response APDU (odpověď). V technologii Java Card komunikace probíhá tím, že host (terminál, aplikace, apod.) odesílá kartě APDU příkaz, ten je pomocí JCRE a Card manageru předán vybranému appletu, na což applet odpovídá skrze JCRE odesláním APDU odpovědi APDU příkaz Strukturu APDU příkazu popisuje následující obrázek: Každý APDU příkaz obsahuje povinnou hlavičku a volitelnou část těla. Hlavička obsahuje čtyři byty, jejichž význam je následující: CLA (1 byte): identifikuje třídu instrukcí. Podle CLA lze APDU příkazy rozdělovat například na příkazy specifické pro card manager, příkazy přenášené zabezpečeným kanálem atp. Konkrétní rozdělení specifikuje ISO Pro applety lze volit CLA například 0x80 či hodnoty v intervalu 0xB0-0xCF. INS (1 byte): určuje, která instrukce třídy specifikované CLA se má provést. P1 (1 byte): 1. parametr instrukce. Toto pole obsahuje byte, který může sloužit jako parametr instrukce (např. specifikovat režim instrukce) či jako vstupní data instrukce. P2 (1 byte): 2. parametr instrukce. Toto pole obsahuje byte, který může sloužit jako parametr instrukce (např. specifikovat režim instrukce) či jako vstupní data instrukce. Tělo obsahuje následující volitelná pole: Lc (1 byte): určuje délku dat v poli Data. Data (Lc počet bytů): data zaslaná s příkazem. Může se jednat o data, které daná instrukce zpracuje, či o další parametry pro instrukci. Jedná se o pole bytů, je na autorovi appletu, jakými daty toto pole naplní a jakým způsobem bude formátováno. Le (1 byte): určuje maximální délku dat očekávanou v odpovědi. Ilustrace 1: Struktura APDU příkazu

19 KAPITOLA 2 Java Card platforma 5 Ilustrace 2: Varianty komunikace Na základě toho, zda jsou APDU příkazem odesílána data a zda jsou nějaká očekávána, existují čtyři varianty komunikace: Case 1: příkaz nenese data, nejsou na něj očekávána data v odpovědi. Case 2: příkaz nenese data, jsou na něj očekávána data v odpovědi. Case 3: příkaz nese data, nejsou na něj očekávána data v odpovědi. Case 4: příkaz nese data, jsou na něj očekávána data v odpovědi APDU odpověď Každá APDU odpověď obsahuje povinné zápatí a volitelnou část těla. Zápatí obsahuje dvou bytový status word (SW). To má normou několik definovaných tříd a hodnot. SW indikuje, jakým způsobem kartě zaslaný APDU příkaz proběhl zda korektně, či zda došlo k nějaké výjimce či chybě. K výjimkám a chybám může patřit neznámý kód instrukce, odeslání více dat v odpovědi, než kolik bylo specifikováno polem Le v APDU příkazu, chyba při ověření atd. První byte SW určuje třídu dané indikace či chyby, druhý byte specifikuje detaily (kupříkladu počet přebytečných bytů, které měl applet k odeslání). Tělo APDU odpovědi obsahuje bytové pole s daty odpovědi na APDU příkaz. Vzhledem k tomu, že komunikace s kartou, resp. appletem probíhá pomocí APDU příkazů, je nutné při návrhu appletu připravit též protokol komunikace mezi appletem a hostem (aplikací, terminálem, apod.). Ilustrace 3: Struktura APDU odpovědi

20 6 KAPITOLA 2 Java Card platforma Konkrétně tedy, jakou třídu či třídy instrukcí bude applet podporovat, a následně pro každou metodu appletu, která má být volána, je třeba určit, jaký kód (INS) bude mít a jakým způsobem bude docházet k předání dat a parametrů. Klasické javovské metody appletu jsou tedy volány na základě APDU příkazů došlých k appletu a hodnoty jejich pole INS. Parametry a data, s nimiž metoda pracuje, je nutné získat z parametrů či těla APDU příkazu. Podobně též návratové hodnoty je nutné předávat skrze APDU odpovědi. 2.3 Zdrojový kód appletu Každý applet musí rozšiřovat abstraktní třídu javacard.framework.applet, která je základní bázovou třídou pro všechny applety. Tato třída definuje metody, jimiž probíhá komunikace mezi appletem a JCRE. Tyto metody musí applet ke své korektní funkci překrýt. Jde zejména o metody install a process. (Jedná se o podobný princip jako s applety J2SE a jejich metodami destroy, init, start, stop, či s midlety paltformy J2ME a jejich metodami startapp, pauseapp a destroyapp). Metoda install je volána při instalaci appletu a každý applet ji musí implementovat. Z této metody by měl být volán konstruktor appletu a předáno mu pole s instalačními parametry, které metoda přebírá. Metoda install musí přímo či nepřímo volat metodu register, jinak instalace selže. Metodu install lze vzdáleně přirovnat k metodě main klasického javovského zdrojového kódu. Podobně jako metoda main představuje vstupní bod do celého programu, vytvoří instance a získá parametry příkazového řádku, je i zde metoda install první metodou appletu, která je volána, vytvoří instanci appletu a přebírá pole s instalačními parametry. Metoda process specifikuje, jak applet reaguje na zaslané APDU příkazy. V parametru získává instanci třídy APDU, která zapouzdřuje přijatý APDU příkaz. Z tohoto objektu lze získat pole bytů APDU příkazu a následně testovat hodnoty pole INS. Podle toho se na základě příkazu switch volají metody appletu implementující konkrétní aplikační logiku. public void process(apdu apdu) throws ISOException{ // APDU objekt obsahuje pole bytů s obsahem apdu příkazu byte[] buffer = apdu.getbuffer(); // pole INS apdu příkazu byte ins = buffer[iso7816.offset_ins]; } // volání konkrétní metody na základě obsahu INS pole switch (ins) { case SET: setstring(apdu); break; case GET: getstring(apdu); break; default: // applet danou instrukci nepodporuje ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED); }

21 KAPITOLA 2 Java Card platforma 7 Pro detailní rozbor výstavby appletu viz. soubor ukazkovy_applet.pdf v adresáři ukazky na CD příloze, kde je popsána a okomentována základní struktura appletu. 2.4 Překlad a nahrávání appletu na kartu Zdrojový kód appletu je nutné nejprve zkompilovat na.class soubory. Zdrojový kód appletu je překládán pomocí překladače javac dodávaného s JDK firmy Sun. Příklad kompilace appletu nazvaného SimpleString: javac -g -target 1.1 -source 1.2 -cp %JC21_HOME%\lib\api21.jar cz\cvut\fel\ jc\cviceni\simplestring\*.java Parametr -g určuje, že soubor má být přeložen se všemi informacemi pro debug. To může pomoci efektivnější konverzi appletu v dalším kroku, protože takto je vytvořena tabulka lokálních proměnných včetně jejich typů, čehož může nástroj pro konverzi využít. Pakliže tato tabulka k dispozici není, nástroj konverze určuje typy proměnných sám, což ne vždy vede k nejefektivnějšímu kódu. Parametry -target a -source instruují překladač, aby zachovával kompatibilitu překladu se staršími verzemi jazyka, což je nutné pro nástroj konverze. -cp určuje classpath, tj. soubory a knihovny, vůči nimž má být kód překládán. Zde je nutné uvést cestu k souboru api21.jar či api.jar, který je součástí Java Card Development Kitu (v adresáři bin či lib). Ten obsahuje Java Card API, které applet na kartě využívá, a je nutné, aby vůči němu byl soubor přeložen. Kompilací získaný.class soubor (popř. soubory) je nutné zkonvertovat. Konverze je proces, při němž se ještě předtím, než je applet nahrán na kartu, vykoná preprocessing, který virtuální stroj na pc při zavádění normální javovské třídy vykonává. To se týká i kontrol, zda přeložený soubor splňuje požadavky Java Card platformy a zda volá pouze podmnožinu příkazů jazyka Java na Java Card platformě dostupných. Výsledkem konverze je.cap soubor, který se svou podstatou podobá jar souboru také jde o kontejner tříd. Soubor.cap je již applet připravený k nahrání na kartu. Konverzi zajišťuje nástroj Converter, který je součástí Java Card Development Kitu. V konfiguračním souboru je možná nástroji Converter předat parametry konverze. K nim patří například přiřazení AID instanci appletu a jeho balíčku. Následně lze.cap soubor nahrát na kartu k tomu určeným postupem. Na kartě vznikne Load soubor. Z něho poté lze na kartě vytvořit instanci appletu, kterou lze vybrat příkazem SELECT.

22 8 KAPITOLA 2 Java Card platforma

23 KAPITOLA 3 Zabezpečení Java Card Platformy 9 3 Zabezpečení Java Card Platformy V této kapitole jsou rozebrány mechanismy zabezpečení platformy Java Card a shrnuty tři základní typy útoků na mechanismus zabezpečení platformy. Přestože Java Card platforma zajišťuje silné zabezpečení, je nutné dbát na preventivní mechanismy týkající se zejména.cap souborů, které budou nahrávány na kartu. 3.1 Mechanismy zabezpečení platformy Java Card Bezpečnost Java Card platformy je zásadním faktorem pro bezpečnost smart karet založených na této platformě. Ty jsou zejména používané jako komponenty bezpečnostní architektury cílové domény (smart karty sloužící jako úložiště soukromých klíčů a dat, jsou jimi podepisovány bankovní transakce, mohou sloužit jako elektronické peněženky, uživatel se jimi ověřuje pro přístup do zabezpečených částí systému,...). Jazyk Java obecně je považován za zabezpečený. Platforma Java Card se však oproti standardní platformě jazyka Java liší v mnoha zásadních aspektech, které přispívají ke zvýšení bezpečnosti. Ovšem na druhou stranu mohou tyto odlišnosti do platformy Java Card vnášet slabiny, které jsou zneužitelné v případě, kdy nejsou dodrženy základní postupy, jimiž lze zajistit zabezpečení platformy a od ní se odvíjející zabezpečení appletů samotných. Java Card platforma oproti standardní platformě jazyka Java neobsahuje některé funkce. Tato absence funkčnosti platformy Java Card, jakkoli to může znít paradoxně, může představovat implicitní přispění k zabezpečení platformy Java Card. Příkladem je absence dynamického načítání tříd a absence vláken. Java Card platforma neumožňuje dynamické načítání tříd, čímž se vyhýbá některým bezpečnostním problémům, které by tento mechanismus mohl způsobovat. Absence dynamického načítání tříd tedy pro platformu znamená usnadnění typové kontroly, která tímto může zaručovat větší bezpečnost. Absence vláken je do jisté míry omezením funkčnosti vynuceným zejména omezenými výpočetními a paměťovými prostředky karty, nicméně sekundárně lze toto omezení vnímat jako příspěvek k potenciálnímu zvýšení bezpečnosti appletů a platformy, jelikož vícevláknové programování přispívá ke složitějšímu návrhu aplikace, který může vést k neodhaleným bezpečnostním slabinám. K zabezpečení platformy Java Card však přispívají zejména následující rysy a mechanismy, které jsou k podpoře zabezpečení platformy explicitně určené. Seznam uvádí jednotlivé rysy a mechanismy, které budou rozebrány v dalších oddílech kapitoly, přičemž bude vycházeno z problematiku detailně pokrývajícího textu [3] a dále [1] a [4]: Využívání bezpečnostních mechanismů jazyka Java typové kontroly, kontroly hranic polí, kontrola přístupnosti členů tříd,...) Applet firewall mechanismus, který zajišťuje izolaci jednotlivých appletů a řídí přístup jednotlivých appletů k proměnným a metodám jiných appletů. Atomické operace a transakční zpracování definované hodnoty proměnných v případě, že dojde k přerušení operací zápisu nových hodnot do proměnných. Zákaz nativních metod v appletech nativní metody nejsou předmětem bezpečnostních kontrol Java Card platformy. Applety nemohou nativní metody využívat.

24 10 KAPITOLA 3 Zabezpečení Java Card Platformy Platforma appletům nabízí dále služby kryptografického API Java Card cryptography API a služby prostředků ověřování (PIN a ve verzi platformy 2.2 biometrika). 3.2 Bezpečnost jazyka Java na platformě Java Card Applety Java Card platformy jsou tvořeny klasickými soubory Java tříd. Ty jsou kompilovány jakýmkoli standardním kompilátorem javovského kódu. Proces kompilace tedy zajišťuje základní kontroly jazykového zabezpečení jako například (pro detailnější informace viz. [5] nebo [6]), zda: všechny reference na metody a proměnné jsou kontrolovány, zda jsou odpovídajícího typu, nejsou porušena pravidla přístupnosti proměnných a metod, není možné provést konverzi reference na int a naopak, program nemůže přistupovat k hodnotě neinicializované lokální proměnné, objekty nemohou být přetypovány na typ podtřídy bez explicitního přetypování a kontroly. Na kartu je však applet nahráván v.cap formátu, což je formát kontejneru srovnatelný s formátem.jar u standardní platformy či.jad u mobilní. Cap formát určen pro prostředí Java karet. Obsahuje předzpracované datové struktury a optimalizovaný bytekód pro běhové prostředí na kartě, které z důvodu omezených výpočetních a paměťových prostředků toto zpracování (včetně některých kontrol) nemůže provádět na kartě. Cap soubor je vytvářen nástrojem Converter (součást Java Card Development Kitu), který představuje off-card (přítomnou mimo kartu) část virtuální stroje provádí principiálně stejné kontroly a operace, které při načítání tříd provádí virtuální stroj standardní platformy Java. On-card (přítomnou na kartě) část virtuálního stroje představuje interpret, který zajišťuje vykonávání instrukcí bytekódu, řídí alokaci paměti a zajišťuje běhovou bezpečnost. Nahrání třídy včetně kontrol zabezpečení je tedy rozděleno do dvou fází, kdy v první části jsou mimo kartu provedeny statické kontroly a předzpracování, a ve druhé fázi dochází k běhovým kontrolám a vykonávání kódu na kartě. Nástroj Converter provádí následující kontroly souborů tříd, které zajišťují, že: Nedochází k porušení správy paměti a přetečení či podtečení zásobníku kódem. Nedochází k porušení omezení přístupnosti (např. private proměnná není přístupná mimo svou třídu). Metody jsou volány se správným počtem parametrů správného typu. Proměnným jsou přiřazovány hodnoty správného typu. Objekty jsou přistupovány vždy správným typem (objekt A je vždy použit jako objekt A, popř. jako jeho nadtřídy). Nedochází k nedovoleným konverzím typů. Kromě toho Converter provádí kontroly testující, zda kód tříd odpovídá požadavkům podmnožiny kódu jazyka Java pro platformu Java Card.

25 KAPITOLA 3 Zabezpečení Java Card Platformy 11 Poslední kategorií operací jsou optimalizace vygenerovaného kódu, mezi něž patří: Inicializace statických proměnných. Optimalizace bytekódu. Vytvoření datových struktur pro virtuální stroj. Nástroj Converter využívá při provádění kontrol tzv. export soubory. Ty představují API tříd a balíčků, které applet importuje (lze na ně nahlížet jako na hlavičkové soubory jazyka C). Obsahují informace o rozsahu přístupnosti a názvech tříd, přístupnosti a signaturách metod a přístupnosti proměnných. Kromě toho obsahují též informace využité při linkování a vytváření referencí mezi balíčky. Vůči informacím z export souborů, které reprezentují veřejné API jiných appletů (a často těch nahraných na kartě, k nimž export soubor představuje jedinou na pc přítomnou reprezentaci), jsou třídy appletů konvertovány. Cap soubor obsahuje tedy již předzpracovaná data, čímž de facto představuje odlehčenou reprezentaci, která už postrádá některé rysy zabezpečení jazyka Java, protože při konverzi již došlo k jejich kontrole. Cap soubor je tedy zranitelný vůči změnám, které by mohly ohrozit bezpečnost cílové platformy. Virtuální stroj na kartě totiž očekává korektní a ověřený applet, který neporušuje bezpečnostní pravidla platformy a jazyka. Je tedy nutné před nahráváním.cap souboru na kartu soubor ověřit nástrojem Verifier (součást Java Card Development Kitu), zda soubor stále splňuje požadavky. Verifier by měl být používán ke statické kontrole.cap souboru předtím, než je soubor nahrán na kartu. Kontroly, které Verifier vykonává, odpovídají jednotlivým kontrolám prováděným nástrojem Converter. Kromě toho kontroluje i konsistenci.cap souboru s export soubory tříd, které jsou třídami v.cap souboru importovány. V případě, kdy je applet na kartu nahráván okamžitě po konverzi, je možné proces verifikace vynechat, jakož nástroj Converter provádí stejnou sadu kontrol jako nástroj Verifier. Jedná-li se však o nahrávání.cap souboru třetí strany či souboru, který byl zasílán např. po síti, je nutné vždy ověřit, zda se jedná o.cap soubor, který neporušuje bezpečnostní požadavky platformy a jazyka. Nutno dodat, že použití nástroje Verifier před nahráním.cap souboru na kartu není platformou nijak vynuceno či automatizováno. 3.3 Applet Firewall Java Card platforma poskytuje k užívání multi-appletové prostředí. To znamená, že na kartě může být nahráno několik appletů od různých výrobců. Je tedy nutné zajistit, aby jednotlivé applety měly svůj vlastní soukromý prostor. Applety totiž uchovávají mnohá citlivá data jako jsou soukromé kryptografické klíče, biometrická data držitele karty či stav konta elektronické peněženky. Tuto izolaci appletů zajišťuje tzv. applet firewall. Ve výchozím stavu nemohou applety přistupovat k metodám a proměnným jiných appletů a to i v případě, že by byly označeny modifikátorem public. Častým požadavkem návrhu appletů je však sdílení funkčnosti či dat dvou nezávislých appletů typickým případem je platební a applet věrnostního programu: za realizovanou platbu pomocí platebního appletu zákazník získá nějaké věrnostní body, které spravuje applet věrnostního programu ten může být využit i jinými applety, jejichž

26 12 KAPITOLA 3 Zabezpečení Java Card Platformy používání nějakým způsobem může ovlivňovat hodnotu věrnostních bodů. Podobně i platební applet samotný může být využíván různými applety, které potřebují realizovat nějaké platby. Applet firewall poskytuje mechanismus, kterým appletům umožňuje sdílet funkčnost na základě modelu klient-server. Klient applet může server appletu zaslat požadavek na sdílení nějaké metody. Server applet tomuto požadavku může vyhovět, či ho odmítnout (kupříkladu na základě úspěšně autentikace). Pokud je požadavek na sdílení server appletem povolen, může klient applet využívat metod, které server applet deklaroval ve sdíleném rozhraní. V tomto oddílu budou probrány základní principy applet firewallu a mechanismy vývoje appletů využívajících sdílenou funkčnost jiných appletů Kontexty Existující objekty v rámci běhového prostředí jsou rozděleny do prostorů zvaných kontexty. Applet firewall představuje hranici mezi jednotlivými kontexty. Ve výchozím stavu nelze z jednoho kontextu přistupovat k objektům a jejich metodám či proměnným v jiném kontextu. Při vytvoření instance appletu (tedy při nainstalování appletu) je appletu přiřazen nový kontext. Tento kontext (konkrétně nazývány skupinový kontext) sdílejí všechny instance appletu stejného balíčku jako je applet, pro který byl tento kontext vytvořen mezi jednotlivými instancemi appletů stejného balíčku tedy není izolace tvořená applet firewallem. Množina kontextů obsahuje kontext se speciálními privilegii, který přísluší běhovému prostředí platformy. Z toho kontextu je možné přistupovat do kontextu jakéhokoliv appletu. Naopak, do tohoto kontextu nelze přistupovat z žádného jiného kontextu. V jednom časovém okamžiku je na kartě pouze jeden aktivní kontext jedná se buď o kontext běhového prostředí, nebo o kontext aktivního appletu. Nově vytvořený objekt je přiřazen momentálně aktivnímu kontextu. Princip kontextů a applet firewallu neplatí pro statické proměnné a metody, jelikož třídy samotné nejsou příslušné žádnému kontextu. Na ně jsou uplatňována pouze jazyková omezení přístupu v podobě modifikátorů přístupnosti. Ke statické proměnné či metodě lze tedy přistupovat z jakéhokoliv kontextu. Nicméně fakt, že ke statické proměnné lze přistupovat ze všech kontextů, neznamená, že v případě, kdy proměnná obsahuje referenci na objekt, je tento objekt přístupný také ze všech kontextů zde se opět uplatňuje pravidlo kontextů a k metodám a proměnným objektu lze přistupovat pouze v rámci kontextu, v němž byl objekt vytvořen. Ne zcela zřejmým faktem může být skutečnost, že objekt vytvořený v rámci statické metody je přiřazen do kontextu volajícího metoda je totiž provedena v kontextu volajícího. Z uvedeného je tedy patrné, že applet nemůže překročit hranice svého kontextu, které představuje applet firewall. Výjimkou je pouze zmiňovaný kontext běhového prostředí, který může přistoupit k jakékoliv metodě či proměnné jakéhokoliv objektu na kartě. V okamžiku, kdy běhové prostředí spustí metodu appletu, dojde ke změně aktivního kontextu z kontextu běhového prostředí na kontext daného appletu. Při návratu z této metody se aktivním kontextem opět stane kontext běhového prostředí. Tímto dochází například k přepínaní kontextů při přijetí APDU příkazů běhové prostředí spustí metodu vybraného appletu process, která zpracovává přijatý APDU příkaz, čímž dojde ke změně aktivního kontextu na kontext appletu. Applet v reakci na přijatý APDU příkaz provede nějaké operace, načež se po jejich vykonání aktivním kontextem stává opět kontext běhového prostředí.

27 KAPITOLA 3 Zabezpečení Java Card Platformy Sdílení objektů Platforma nabízí tři mechanismy sdílení, jimiž lze sdílet data či metody mezi objekty příslušící rozdílným kontextům: Využití vstupních objektů běhového prostředí. Využití globálních polí. Využití sdílených rozhraní. Při využití mechanismů sdílení je virtuálním strojem povolen přístup k objektu z jiného kontextu pomocí přepnutí kontextu (context switch). Při volání metody objektu z jiného kontextu dojde k uložení momentálně aktivního kontextu na interní zásobník virtuálního stroje a k přepnutí kontextu; aktivním kontextem se stane nový kontext. Volaná metoda je vykonána v novém kontextu a při návratu či vyvolání výjimky dochází k obnovení původního uloženého kontextu, který se stává aktivním kontextem. Vstupní objekty běhového prostředí Applet firewall by ve výchozím stavu nepovolil přístup ze žádného kontextu k objektům vlastněným kontextem běhového prostředí. Výjimku však tvoří tzv. vstupní objekty běhového prostředí. Jedná se o objekty vlastněné kontextem běhového prostředí, které však obsahují vstupní (veřejné) metody běhového prostředí, k nimž lze přistupovat z jakéhokoliv kontextu. Jakmile je tato metoda volána, dojde k přepnutí aktivního kontextu na kontext běhového prostředí. Specifikace rozlišuje dva typy vstupních objektů běhového prostředí: dočasné vstupní objekty běhového prostředí trvalé vstupní objekty běhového prostředí Dočasné vstupní objekty běhového prostředí se vyznačují tím, že reference na ně nemůže být uložena ve statické či instanční proměnné nebo v poli. Tímto je zabráněno znovuvyužívání těchto objektů. Příkladem dočasných vstupních objektů běhového prostředí je APDU objekt či výjimky běhového prostředí. Naopak reference na trvalé vstupní objekty běhového prostředí ukládat lze, stejně jako tyto objekty znovupoužívat. Příkladem jsou například instance třídy AID. Globální pole Globální pole lze považovat za sdílený paměťový buffer, k němuž má přístup jakýkoliv applet a běhové prostředí. Jako globální pole může být běhovým prostředím označeno pole primitivních hodnot. Ve skutečnosti je globální pole zvláštním typem dočasného vstupního objektu běhového prostředí. Z jakéhokoliv kontextu lze přistupovat k jeho veřejným proměnným (prvky pole a délka pole) a k jeho jediné metodě equals. Ta, pokud je zavolána, je vykonána v kontextu běhového prostředí. Protože jsou globální pole dočasnými vstupními objekty běhového prostředí, nelze reference na ně ukládat do statických a instančních proměnných ani do polí.

28 14 KAPITOLA 3 Zabezpečení Java Card Platformy Jedinými globálními poli, která jsou v platformě definována, jsou pole APDU buffer a pole, které je předáváno jako parametr v metodě install. Implementace běhového prostředí však většinou jako parametr metodě install předávají pole APDU buffer. U pole APDU buffer běhové prostředí zajišťuje, že je vymazáno, kdykoliv dojde k výběru appletu příkazem SELECT nebo před přijmutím nového APDU příkazu. Sdílená rozhraní Sdílená rozhraní jsou mechanismem, který umožňuje sdílení objektů a jejich metod mezi applety jiných kontextů. Sdílené rozhraní je rozhraní, které rozšiřuje rozhraní Shareable. Ve sdíleném rozhraní jsou definovány metody sdíleného objektu, k nimž bude možné přistupovat z jiných kontextů. Objekt, který implementuje nějaké sdílené rozhraní (může implementovat více rozhraní či může rozšiřovat třídu, která toto rozhraní implementuje) se nazývá objekt sdíleného rozhraní (Shareable interface object (SIO)). V rámci kontextu, v němž byl objekt vytvořen, se jedná o normální objekt, k jehož instančním proměnným a metodám lze volně přistupovat v daném kontextu. Pro jiné kontexty se však jedná o objekt typu sdíleného rozhraní a lze tedy přistupovat pouze k metodám, které dané rozhraní definuje. Ostatní metody a (všechny) instanční proměnné jsou izolovány applet firewallem. Mechanismus sdílených rozhraní si lze představit na modelu klient server. Server applet (tj. applet, který bude nabízet své služby prostřednictvím metod sdíleného rozhraní), vytvoří instanci objektu, který implementuje sdílené rozhraní (v praxi sdílené rozhraní často implementuje sám server applet, čímž se sám stává objektem sdíleného rozhraní). Tyto metody zahrnují ty služby, které chce server applet poskytovat klientským appletům. Skrze objekt sdíleného rozhraní tedy klientská applet posílá zprávy (tj. volá metody) server appletu. Server applet navíc může poskytovat různé služby různým typům klientů to znamená, že je definováno několik sdílených rozhraní, jejichž implementující instance server vytvoří a skrze tyto objekty s ním komunikují klientské applety, přičemž každý applet využívá objekt sdíleného rozhraní, který je příslušný jeho službám. Tuto situaci ilustruje následující schéma, kde server applet A nabízí dva typy objektů sdíleného rozhraní. Applet B využívá služby objektů sdíleného rozhraní 1 a 2. Applet C využívá služby objektu sdíleného rozhraní 2. Ilustrace 4: Ilustrace sdílení objektů sdíleného rozhraní

29 KAPITOLA 3 Zabezpečení Java Card Platformy 15 Následující příklad ukazuje, jakým způsobem lze sdílené rozhraní implementovat v kódu appletu a jaké bezpečnostní mechanismy lze pro sdílení funkčnosti dvou appletů využít. Příklad ilustruje typickou situaci platebního appletu a appletu věrnostního programu. Věrnostní applet reprezentuje službu, kterou držitel karty získává věrnostní body podle transakcí, které kartou realizuje. Týkat se to může jednak zmiňovaného platebního appletu, kdy za určitý podíl utracených elektronických peněz držitel karty získá bod do věrnostního programu. Věrnostní body může držitel karty směnit za výhody či slevy. Věrnostní applet může být sdílen nejen platebním appletem, ale kupříkladu appletem pro výdej obědů, platby hromadné dopravy či parkování, kdy za každou službu, kterou držitel karty využije, získá věrnostní body. (Pozn: Sdílení objektů lze samozřejmě také řetězit tj. zatímco platební applet využívá appletu věrnostního, může být platební applet, který implementuje logiku platby elektronickými penězi, využíván jinými applety, které vyžadují realizaci nějakých plateb.) Předpokládejme tedy, že na kartě jsou ve dvou rozdílných balíčcích (a tedy kontextech) applety platby (PaymentApplet) a věrnostního programu (LoyaltyApplet). K tomu, aby applet platby mohl využívat funkčnost appletu věrnostního programu, je nutné vykonat následující kroky: 1) Applet věrnostního programu vytvoří objekt sdíleného rozhraní reprezentující služby, které platebnímu appletu nabídne. 2) Platební applet požádá věrnostní applet o objekt sdíleného rozhraní. 3) Platební applet skrze objekt sdíleného rozhraní aktualizuje věrnostní body. Aktualizaci bodů zpracovává applet věrnostního programu. Sdílené rozhraní appletu věrnostního programu je definováno takto: public interface LoyaltySharedInterface extends Shareable { } public void addbenefitpoints(short points); Applet věrnostního programu bude implementovat toto rozhraní, čímž se sám stane objektem sdíleného rozhraní. Z jiných kontextů však bude možné přistupovat pouze k metodě addbenefitpoints ze sdíleného rozhraní. Implementace metody sdíleného rozhraní addbenefitpoints je například tato: // totalpoints je instanční proměnná appletu udržující hodnotu celkového počtu věrnostních bodů public void addbenefitpoints(short points) { } totalpoints = (short) (totalpoints + points); Applet věrnostního programu, který zde v modelu klient server vystupuje jako server nabízející služby, musí dále implementovat metodu getshareableinterfaceobject, kterou

30 16 KAPITOLA 3 Zabezpečení Java Card Platformy definuje, jaký objekt sdíleného rozhraní bude poskytovat. Metoda má následující signaturu: public Shareable getshareableinterfaceobject(client_aid, byte parameter) Parametr client_aid označuje AID appletu, který žádal o poskytnutí objektu sdíleného rozhraní. Podle AID různých klientských appletů může server vracet objekty různých sdílených rozhraní příslušné pro dané klienty. Parametr parameter je aplikačně závislý lze jím předávat appletu, který je žádán o poskytnutí objektu sdíleného rozhraní, parametry určující například, jaký typ či verzi objektu sdíleného rozhraní applet žádá, nebo může jít o parametr, který může zajišťovat elementární metodu ověření, kdy žádající applet předá appletu, který žádá, společně známou tajnou hodnotu. Implementace této metody v appletu věrnostního programu, který sám implementuje sdílené rozhraní, může být například tato: public Shareable getshareableinterfaceobject(client_aid, byte parameter) { return this; } Platební applet nyní musí applet věrnostního programu požádat o objekt sdíleného rozhraní. K tomu musí znát AID appletu věrnostního programu. Třída JCSystem knihoven platformy poskytuje statickou metodu lookupaid, která pro pole bytů v parametru určujících požadované AID vrací buďto instanci třídy AID zapouzdřující byty AID, nebo null v případě, že applet daného AID se na kartě nenachází. Poté, co touto metodou platební applet ověří, zda je věrnostní applet na kartě přítomen a v případě, že ano, získá instanci třídy AID reprezentující AID věrnostního appletu, může skrze běhové prostředí požádat věrnostní applet o objekt sdíleného rozhraní. Žádost o objekt sdíleného rozhraní lze realizovat statickou metodou třídy JCSystem getappetshareableinterfaceobject. Její signatura je následující: public static Shareable getappletshareableinterfaceobject(aid server_aid, byte parameter) Parametr server_aid označuje AID appletu, který je žádán o poskytnutí objektu sdíleného rozhraní. Parametr parameter výše uvedená metoda getshareableinterfaceobject. Platební applet získá objekt sdíleného rozhraní následujícími příkazy a následně na daném objektu může volat jeho metody. Následující metoda je volána platebním appletem poté, co proběhne platba. Metoda přidá daný počet věrnostních bodů prostřednictvím objektu sdíleného rozhraní. public void updatebenefitpoints(short points) { // pole loyaltyappletaidbytes obsahuje byty AID appletu věrnostního // programu AID loyaltyappletaid = JCSystem.lookupAID(loyaltyAppletAIDBytes, (short)0, loyaltyappletaidbytes.length); if (loyaltyappletaid == null) {

31 KAPITOLA 3 Zabezpečení Java Card Platformy 17 } // applet požadovaného AID nenalezen, lze např. vrátit chybový // status word } LoyaltySharedInterface sio = (LoyaltySharedInterface) (JCSystem.getAppletShareableInterfaceObject(loyaltyAppletAID, (byte)0x00); if (sio == null) { // z nějakého důvodu nebyl získán objekt sdíleného rozhraní, lze např. // vrátit chybový status word } // volání metody sdíleného rozhraní sio.addbenefitpoints(points); Mechanismy zabezpečení při použití sdílených rozhraní Z hlediska zabezpečení má server applet možnost ověřit při poskytnutí objektu sdíleného rozhraní jednak parametr předávaný metodou pro žádost o sdílené rozhraní. Tento parametr může být interpretován jako sdílená tajná hodnota mezi server appletem a klientským appletem. Pokud klientský applet žádá nesprávnou tajnou hodnotou, může server poskytnutí objektu sdíleného rozhraní odmítnout. V tomto případě se jedná skutečně o jednoduchou techniku, kterou je na straně server appletu minimálně nutné doplnit čítačem neúspěšných žádostí o objekt sdíleného rozhraní, přičemž po daném počtu neúspěchů, server odmítne objekt sdíleného rozhraní vydat zcela, dokud není čítač nějakým způsobem resetován (např. k tomu určenou instrukcí, k níž má přístup pouze administrátor appletu pomocí jiným mechanismů zabezpečení např. PIN či vzájemná autentikace popsané v dalších kapitolách). Podobně může server applet ověřovat AID klientského appletu, který žádá o objekt sdíleného rozhraní. Toto však lze považovat za velmi hrubou a neflexibilní metodu ověření spoléháním na statickou hodnotu AID je klientský applet nucen dodržovat toto AID, a naopak zcela jiný applet může být na kartu nahrán s daným AID a vystupovat jako správný klientský applet, který server očekává. AID appletu tedy nelze považovat za vlastnost, na níž by měla být založena důvěra v klientský applet. Jakkoli jsou předchozí dva mechanismy nepříliš bezpečné, míra zabezpečení, kterou poskytují, je ještě nižší faktem, že dané mechanismy lze využít pouze v okamžiku, kdy klientský applet žádá o objekt sdíleného rozhraní. Klientský applet přitom může porušit kontrakt a získaný objekt sdíleného rozhraní poskytnout dalšímu appletu bez vědomí server appletu. Server applet by tedy v každé metodě sdílené rozhraní měl na jejím začátku kontrolovat, zda AID appletu z kontextu, z něhož byla metoda volána, odpovídá AID appletu, který o objekt sdíleného rozhraní žádal. Pokud se obě AID liší, znamená to, že je objekt sdíleného rozhraní používán jiným appletem, než který o něj žádal. AID appletu z předchozího kontextu lze zjistit statickou metodou třídy JCSystem getpreviouscontextaid, která vrací AID předchozího kontextu.

32 18 KAPITOLA 3 Zabezpečení Java Card Platformy Ilustrace 5: Neoprávněné poskytnutí objektu sdíleného rozhraní třetímu objektu Tuto kontrolu lze doplnit mechanismem plnohodnotné autentikace, kdy klientský i server applet provedou autentikaci například na bázi challenge response, kdy server klientskému appletu předá náhodná data. Klientský applet je zašifruje klíčem, který je sdíleným tajemstvím mezi ním a serverem. Zašifrovaná náhodná data předá klientský applet zpět serveru, který je dešifruje a pokud jsou dešifrovaná data shodná s vygenerovanými, znamená to, že klientský applet zná sdílené tajemství a je tímto ověřen. Autentikaci lze provést pomocí dalšího sdíleného objektu, který je předán jako parametr každé metody sdíleného rozhraní, pro níž má být provedena autentikace volajícího appletu a skrze kterou má server applet možnost předat challenge data klientskému appletu (tj. zavolat metodu tohoto dodatečného sdíleného objektu, jehož metody klientský applet implementuje, tj. prostřednictvím parametrů metod lze klientskému appletu předat data). Pomocí kontroly AID předchozího kontextu a autentikace klientského appletu na začátku vykonávání každé metody objektu sdíleného rozhraní, může server applet ověřovat, že metoda objektu sdíleného rozhraní je (přímo) volána appletem, který o tento objekt sdíleného rozhraní žádal a který zná sdílené tajemství. 3.4 Atomické operace a transakční zpracování Čipové karty nasazené do praktického používání jsou často vystaveny fyzikálním vlivům prostředí (vlhkost, prach, teplota, vibrace), které mohou podobně jako prosté předčasné vytažení karty z terminálu či úmyslná snaha činnost karty přerušit a uvést do nekonzistentího stavu způsobit, že dojde k přerušení probíhající operace. Tato situace může způsobit nekonzistenci dat, kdy kupříkladu aktualizace pole bytů proběhne pouze nad částí pole, či zápis do dvou proměnných proběhne pouze nad proměnnou první, ovšem ne už druhou. Tyto nekonzistence mohou narušit předpoklady, které applet klade na svá data a stav, v němž se nachází, a posléze narušit bezpečnost appletu či platformy. Java Card platforma nabízí následující prvky, které zabraňují nekonzistencím v datech či stavu appletu: Platforma garantuje, že změna proměnné persistentního objektu či třídy je vždy atomická, tj. v případě, že nastane chyba během operace změny hodnoty dané proměnné, bude hodnota obnovena na původní hodnotu. Metoda arraycopy zaručuje atomicitu kopie všech elementů pole. To znamená, že dojde ke zkopírování všech elementů pole do cílového pole, či nedojde ke zkopírování

33 KAPITOLA 3 Zabezpečení Java Card Platformy 19 žádného a hodnoty elementů cílového pole jsou ponechány na původních. Platforma nabízí model transakcí, tedy pasáží kódu, které proběhnou buď celé, či jsou veškeré změny provedené jednotlivými příkazy v pasáži zrušeny. Takto lze kupříkladu zajistit atomické změny více proměnných najednou buď jsou změněny hodnoty všech proměnných v bloku transakce, či není změněna žádná a hodnoty proměnných jsou vráceny do původního stavu. Objekty, které byly ve zrušené transakci vytvořeny a alokovány, jsou zrušeny a reference na tyto objekty nastaveny na null či do původního stavu. 3.5 Útoky na zabezpečení platformy Java Card Problematika slabin platformy Java Card je v literatuře zmiňována velmi zřídka. Často se jedná o články zabývajícími se technikami prevence v podobě verifikace kódu v okamžiku načítání třídy na kartě. Jediné konkrétní typu útoků zmiňuje [7] a dále rozšiřuje [8]. V multi-appletovém prostředí, které platforma Java Card poskytuje, není vyloučena situace, kdy na kartě budou přítomny applety konkurenčních poskytovatelů. Jednotlivé applety na kartě nahrané mohou navíc disponovat rozdílnými bezpečnostními standardy. Na kartě může tedy být přítomen applet, jehož vývoj a funkčnost podléhá přísným bezpečnostním kritériím, s appletem, na který nejsou kladeny žádné požadavky týkající se zabezpečení. Důsledkem těchto faktorů lze Java kartu považovat za nehomogenní prostředí, v němž vyvstávají následující rizika týkající se koexistence různých appletů na kartě [7]: 1) Applet může vykazovat chování, které sice není destruktivní, může však narušovat korektní funkci ostatních appletů. 2) Applet může dočasně či trvale vyřadit kartu z provozu. 3) Applet se může podílet se na neoprávněných externích činnostech s využitím externích prostředků. 4) Applet může neoprávněně vyzradit důvěrná data uživatele. 5) Applet může útočit na ostatní applety či na celou platformu. Java Card platforma nezajišťuje žádné mechanismy, kterými by mohla eliminovat první čtyři rizika. Applet může kupříkladu obsahovat nekonečný cykl, který kartu alespoň dočasně vyřadí z činnosti. Applet může také záměrně vyvolávat chyby kryptografických operací, které mohou operační systém (resp. běhové prostředí) či Card manager považovat za útoky a kartu dočasně či nevratně zablokovat. Applet také může kartu vyřadit z činnosti tvorbou objektů v persistentní paměti a tím paměť zcela zaplnit. [7] rozlišuje tři kategorie appletů, které mohou narušit bezpečnost Java Card platformy: Ověřené applety zneužívající služby platformy (sem náleží applety s kódem typu trojský kůň, kdy dochází například k neoprávněnému sdílení dat PINu zadávaného pro jeden applet s ostatními applety). Ověřené applety využívající chyb v platformě. Po ověření modifikované applety, které obcházejí bezpečnostní mechanismy platformy. Pro poslední dvě kategorie je zejména v [8] popsáno několik typů útoků na platformu Java

34 20 KAPITOLA 3 Zabezpečení Java Card Platformy Card, z nichž k nejvýznamnějším patří následující tři popsané. Zdrojové kódy appletů realizujících experimenty těchto útoků se nacházejí v CD příloze v adresáři utoky a jeho jednotlivých podadresářích Útok type confusion (záměna typů) na sdílené rozhraní Tento typ útoku využívá záměny datových typů v parametru metody sdíleného rozhraní, díky čemuž applet může dosáhnout přístupu k částem paměti, k nimž nemá mít přístup. Tyto části paměti mohou obsahovat data různého charakteru, včetně dat (jiných appletů), která by měla být utajena. Předpokládejme sdílené rozhraní, které implementuje server applet nahraný na kartě. public interface typeattackinterface extends Shareable { } public void typeattack(short[] buff); Následně dojde k vytvoření klient appletu, který využívá odlišného rozhraní. public interface typeattackinterface extends Shareable { } public void typeattack(byte[] buff); Klient applet je vůči tomuto pozměněnému rozhraní přeložen a následně zkonvertován s export soubory obsahujícími pozměněnou signaturu metody typeattack jako parametr není uveden typ [S označující pole typu short, ale [B označující pole typu byte. S tímto export souborem, který sice není binárně kompatibilní s rozhraním na kartě, dojde k úspěšné konverzi klient appletu. Klient applet je následně nahrán na kartu. Typ short je reprezentován dvěma byty. Znamená to, že pole typu short o daném počtu prvků obsazuje dvakrát tolik paměti, kolik pole typu byte o stejném počtu prvků. Vyvolá-li nyní klient applet metodu typeattack server appletu a předá v ní pole bytů, server applet pole v parametru považuje za pole typu short, tudíž přistupuje k obsahu paměti, které by toto pole, pokud by opravdu bylo typu short, obsazovalo. Předané pole je však typu byte, tudíž druhá polovina domnělého pole typu short zasahuje do části paměti, která nepřísluší předanému poli. Z příkladu je patrné, že neoprávněný přístup do paměti realizuje server applet. K útoku je tedy zapotřebí nejen škodlivý kód klient appletu, ale na útoku (má-li být např. obsah paměti navracen v APDU odpovědi) musí kooperovat server applet. [7] popisuje úspěšnou realizaci útoku na referenční implementaci java karty 2.2. Na simulátoru cref Java Development Kitu se podařilo applet nahrát, volání metody však vracelo chybový status word 0x6F00. Podobné chování vykazovala i karta GemXpresso R3 applet se podařilo na kartu nahrát. Dokonce šlo přistupovat k prvkům pole podvrženého typu, ovšem pouze na indexy, které náležely oblastem paměti původního typu pole. Na kartě tedy pravděpodobně dochází k dodatečným kontrolám typů a hranic pole za běhu, které nejsou definovány specifikací [9]. Tento útok záměnou typů ve sdíleném rozhraní je tedy v novější

35 KAPITOLA 3 Zabezpečení Java Card Platformy 21 verzi referenční implementace a na dané kartě neúspěšný Útok type confusion (záměna typů) úpravou.cap souboru Jak již bylo popsáno, virtuální stroj na kartě očekává, že na kartu jsou nahrávány pouze ověřené.cap soubory. Dojde-li k modifikaci.cap souboru, lze oklamat virtuální stroj a získat podobně jako v appletu předchozím přístup k částem paměti, k nimž by applet jinak neměl přístup. V balíčku appletu je vytvořena následující třída: public class Fake { short size; } public Fake(short s) { size = s; } U instancí této třídy je podstatný fakt, že hodnota instanční proměnné size je v paměti uložena na stejném místě, na které objekty polí ukládají délku pole. Skrze přiřazení instance této třídy do proměnné typu pole lze docílit toho, že virtuální stroj bude hodnotu proměnné size pokládat za délku domnělého pole. Applet vytvoří instanci této třídy: private Fake fake = new Fake((short)0x8000); V appletu je definována metoda processreadmem takto: void processreadmem(apdu apdu) { byte[] buffer = apdu.getbuffer(); Fake tmp = fake; byte[] copyfrom = buffer; apdu.setincomingandreceive(); Util.arrayCopy(copyFrom, (short)0, buffer, (short)0, (short)20); } apdu.setoutgoingandsend((short)0, (short)20); Tato metoda nejprve získá referenci na APDU buffer, přiřadí ji proměnné copyfrom. Následně přijme data a zkopíruje prvních 20 bytů pole copyfrom do pole buffer od indexu 0 (copyfrom a buffer ukazují na stejné pole). Poté odešle prvních 20 bytů pole buffer jako data v APDU odpovědi. Tento kód kompilátor bez problémů přeloží a Converter konvertuje a ověří. K provedení útoku je nutné přiřadit do copyfrom referenci na fake. Toto kompilátor ani Converter nepovolí. Je tedy nutné přiřazení provést přímo v.cap souboru až po překladu a konverzi. Do kódu metody jsou proto vloženy všechny reference, které jsou potřebné.

36 22 KAPITOLA 3 Zabezpečení Java Card Platformy Ilustrace 6: Změna.cap souboru - instrukce 0x1A na 0x1B Ve vzniklém.cap souboru nyní stačí pouze proměnné copyfrom přiřadit referenci, kterou získá jí předcházející pomocná proměnná tmp která je ve zdrojovém kódu přítomna pouze pro tuto snadnou lokalizaci jednotlivých referencí. V řeči instrukcí (pro detaily instrukcí virtuálního stroje viz. [10]) reference, na níž odkazuje proměnná fake, je uložena do proměnné tmp instrukcí astore_3. Proměnná copyfrom je inicializována referencí na buffer instrukcí aload_2. Změnou instrukce aload_2 (0x1A) na aload_3 (0x1B) je dosaženo toho, že proměnná copyfrom má poté referenci na instanci třídy Fake, ovšem systém se domnívá, že jde o bytové pole o jeho délce. Tím applet získává přístup k paměti. Útok byl testovaný na kartě GemXpresso R3.2 E64. Při vykonávání instrukcí běhové prostředí přerušilo relaci s kartou. Na kartě tedy pravděpodobně dochází k dodatečným kontrolám za běhu, které nejsou definovány specifikací [9] Útoky na transakční mechanismus [8] popisuje případ, kdy vytváření objektů během transakce, která je zrušena, může vést k záměně typů vytvářených objektů. Podstata útoku je založena na potenciálním chybném implementování transakčního mechanismu, kdy lze pomocí vícenásobného přiřazování referencí na v transakci vytvořený objekt transakční mechanismus oklamat, následkem čehož není reference na v transakci vytvořený objekt uvolněna. short[] array1; // instanční proměnná short[] array2; // instanční proměnná public void transactionconfusion() { short[] localarray = null; // lokální proměnná JCSystem.beginTransaction(); array1 = new short[1]; array2 = localarray = array1; JCSystem.abortTransaction(); // programové zrušení transakce } Před přerušením transakce je ve všech třech proměnných reference na stejné pole. Po zrušení transakce by korektní transakční mechanismus měl nastavit všechny tři proměnné na null. Známé chybné implementace transakčního mechanismu však nastavují na null pouze proměnné array1 a array2, přičemž reference v proměnné localarray je zachována. Po zrušení transakce dojde při vytvoření nového objektu k opětovnému použití této domněle uvolněné reference, čehož může být využito k záměně typů objektů.

37 KAPITOLA 3 Zabezpečení Java Card Platformy 23 Zdroj tohoto chování je ve faktu, že transakční mechanismus při programovém zrušení transakce (JCSystem.abortTransaction()) nenavrací původní stav proměnných alokovaných na zásobníku. Vedle korektní implementace transakčního mechanismu specifikace běhového prostředí Java Card [9] určuje možné preventivní řešení, kdy je vytvoření objektů v transakci, která je následně programově zrušena, považováno za programovou chybu či útok na bezpečnost platformy, následkem čehož běhové prostředí přeruší relaci s kartou. Toto chování je implementováno na kartě GemXpresso R3.2 E Opatření pro podporu bezpečnosti platformy Java Card [7] jmenuje několik opatření týkajících se vývoje a správy appletů, jejichž dodržení znamená prevenci vůči předchozím či jiným útokům podobného charakteru ještě dříve, než je daný kód vykonáván na kartě. Daná opatření jsou uvedena v následujícím oddílu a doplněna o další informace a možnosti podpory bezpečnosti platformy Java Card Kontrola zdrojového kódu appletů Pouhé ověření nástrojem Verifier zajišťuje korektnost appletu (resp..cap souboru) z pohledu bezpečnostních požadavků jazyka Java a platformy. Z pohledu rizik však ověření nedokáže předcházet bezpečnostním rizikům plynoucím z návrhu appletů. Do této oblasti spadají úmyslně či neúmyslně špatně navržené applety, které vedou k omezení služeb platformy či zablokování karty, applety, které se snaží využívat bezpečnostních slabin platformy, nebo applety s bezpečnostními slabinami v jejich vlastním návrhu, které by mohly ohrozit applety samotné včetně dalších appletů na kartě. Těmto rizikům lze předejít zajištěním kontroly zdrojového kódu appletů, které jsou nahrávány na kartu Ověření.cap souborů Před nahráním appletu na kartu je bezpodmínečně nutné.cap soubory appletů ověřovat nástrojem Verifier. Vhodnou technikou je také digitální podepisování.cap souborů a export souborů. Pomocí digitálního podpisu je zajištěno, že jakákoliv změna.cap či export souboru po jeho podepsání bude odhalena. Při instalaci appletu je ověřen digitální podpis, kterým applet (.cap soubor) podepsala důvěryhodná entita zodpovědná za verifikaci kódu. Platformy pro správu obsahu karty Open platform či Global platform definují několik bezpečnostních modelů podporujících autenticitu nahrávaného.cap souboru právě na základě digitálního podpisu a mechanismů zabezpečeného nahrávání appletů. Vývoj smart karet a technických prostředků by v dohledné době mohl nabízet i možnost širší verifikace kódu ověřovacími mechanismy na kartě. Již v dnešní době některé typy Java karet mají implementován virtuální stroj, který dokáže ověřovat, zda.cap soubory instalovaných appletů neporušují pravidla zabezpečení jazyka. Nicméně tato technologie není zatím stále dovedena do stavu, kdy by znamenala důvěryhodný mechanismus obrany proti útokům záměny typů. V rozboru [8] jsou známy případy karet s ověřováním nahrávaných.cap souborů a spuštěných tříd, které však v některých případech byly náchylné útokům stejně jako karty bez tohoto ověřování.

38 24 KAPITOLA 3 Zabezpečení Java Card Platformy Je však nutné uvědomit si, že zabezpečení Java Card platformy není zajištěno pouze bezpečnostními mechanismy, které jsou v ní implementovány. Ty zabezpečení pouze doplňují a podobně jako i v jiných systémech je i zabezpečení platformy Java Card zajištěno důrazem na zajištění bezpečnosti všech procesů počínají vývojem appletu a konče zabezpečením implementovaným appletem. Nedůslednost během kteréhokoliv procesu může bezpečnost celé platformy zcela degradovat. 3.7 Hardwarové zabezpečení karet platformy Java Card Platforma Java Card nijak nepřispívá k hardwarovému zabezpečení čipových karet založených na této technologii. Z hlediska ochrany před hardwarovými útoky se tedy karty platformy Java Card nijak neodlišují od čipových karet jiných technologií a nepřinášejí tedy žádné nové ochrany před útoky hardwarového charakteru či útoky obecně platné pro čipové karty. Mezi tyto útoky patří odposlouchávání sběrnic, analýza napěťových výkyvů, změna hodinové frekvence, vystavení karty změnám teploty, změna obsahu paměti vlivem optického záření, diferenční analýza chyb, atd. (pro bližší popis a další reference viz. [1] či [4]).

39 KAPITOLA 4 Java Card cryptography API 25 4 Java Card cryptography API Java Card platforma obsahuje mezi svými základními balíčky i balíčky pro práci s kryptografií, které poskytují třídy a rozhraní umožňující využívat v appletech kryptografických operací. Jedná se o balíček javacard.security a rozšiřující balíček javacardx.crypto. Tyto balíčky jsou nazývány jako Java Card cryptography API či zkráceně jako crypto API. Pro detaily a bližší reference o popisovaných kryptografických algoritmech viz. např. [11] nebo [12]. 4.1 Návrh a vlastnosti Java Card cryptography API Java Card cryptography API je navrženo na principu oddělení rozhraní od implementace. To přináší API nezávislost na implementaci konkrétních algoritmů a možnost využívat implementace různých poskytovatelů. V těchto rysech je API záměrně navržené tak, aby se podobalo kryptografickým API jiných Java platforem, což napomáhá unifikaci Java Card platformy a ostatních Java platforem. Zatímco kupříkladu na J2SE (standardní platforma Javy) je kryptografické API často využíváno ve spolupráci s implementací jiných poskytovatelů namísto výchozí implementace od firmy Sun Microsystems skrze zaregistrování implementace jiných poskytovatelů do běhového prostředí Javy na cílovém stroji, na platformě Java Card, kde je běhové prostředí napevno nahráno na kartu, nelze dodatečně přidávat implementace jiných poskytovatelů, než jaké jsou nahrané v ROM paměti karty. Jedná se o implementace zařazené přímo výrobcem karty do běhového prostředí Java Card společně s prostředím samotným. Rys API nezávislosti na implementaci se tedy s výhodou projevuje i zde, protože různé typy karet mohou podporovat rozdílné kryptografické algoritmy a jejich implementace, ovšem API zůstává stabilní a neměnné. Dalším aspektem, s nímž jsou spojené kryptografické algoritmy, je fakt, že kryptografické algoritmy jsou předmětem vývozních omezení a regulí USA, tudíž i tato okolnost je zdrojem variability ve funkčnosti, která je pokryta návrhem API. Návrh API též umožňuje přidávání nových algoritmů beze změn API a podporuje přenositelnost appletů mezi různými kartami od různých výrobců a tedy pravděpodobně i různých implementací v appletu zahrnutých kryptografických metod samozřejmě jen pokud dané karty vůbec podporují požadovanou množinu kryptografických algoritmů. Java Card cryptography API definuje typy kryptografických služeb a poskytuje rozhraní přístupu k nim. Poskytovatel běhového prostředí rozšiřováním abstraktních tříd a implementací rozhraní poskytuje konkrétní implementaci daných kryptografických služeb. Ty však zůstávají programátorovi appletu zcela skryty, protože pracuje pouze s veřejnými třídami API. Jako konkrétní třída s implementací může kupříkladu existovat třída MessageDigestSHA, která implementuje výpočet haše pomocí hašovací funkce SHA. Třída MessageDigestSHA rozšiřuje abstraktní třídu MessageDigest a překrývá její metody. Programátor appletu však nemusí znát (a ani nezná) názvy konkrétních tříd implementujících výpočet haše funkcí SHA. Tyto názvy a implementace se ve skutečnosti mohou v každé implementaci běhového prostředí Java Card lišit. Programátor appletu pouze zavolá tovární metodu veřejné abstraktní třídy MessageDigest, kterou uvedením parametru požádá o konkrétní implementaci hašovací funkce SHA.

40 26 KAPITOLA 4 Java Card cryptography API MessageDigest sha = MessageDigest.getInstance(MessageDigest.ALG_SHA, false); Vrácena je instance neveřejné třídy, zde nazvané ilustračně MessageDigestSHA, která ovšem splňuje rozhraní MessageDigest, a práce s ní je pro programátora zcela transparentní. Applet tedy není vázán na konkrétní implementace. Parametry ve formě veřejných statických konstant každé třídy určují, jaké kryptografické algoritmy třída poskytuje. Tyto konstanty jsou také jedinými prvky API, které se s různými verzemi platformy liší. 4.2 Třídy a rozhraní Java Card cryptography API Java Card cryptography API je rozděleno do dvou balíčků. Prvním balíčkem je balíček javacard.security. Ten je součástí základních balíčků API platformy Java Card. Obsahuje třídy a rozhraní služeb, které nepodléhají vývozním omezením USA. Jedná se o rozhraní pro implementování klíčů symetrické a asymetrické kryptografie, třídu, která je zodpovědná za tvorbu klíčů, třídy pro práci s podpisy a autentikací a třídy pro generování náhodných dat. Následující tabulka popisuje třídy a rozhraní balíčku javacard.security. Key SecretKey DESKey PrivateKey PublicKey RSAPrivateKey RSAPrivateCrtKe y Základní rozhraní pro všechny klíče. Rozhraní pro klíče použité v symetrické kryptografii. Rozhraní reprezentující 8-,16- a 24-bytový klíč DES nebo dva či tři klíče pro 3DES. Základní rozhraní pro soukromé klíče použité v asymetrické kryptografii. Základní rozhraní pro veřejné klíče použité v asymetrické kryptografii. Rozhraní reprezentující soukromý RSA klíč ve formě modulexponent. Klíč může být použit pro podepsání dat či pro dešifrování dat. Rozhraní reprezentující soukromý RSA klíč ve formě použité pro Čínskou větu o zbytích (p, q, pq, Dp, Dq). Klíč může být použit pro podepsání dat či pro dešifrování dat. Tabulka 1: Třídy a rozhraní balíčku javacard.security

41 KAPITOLA 4 Java Card cryptography API 27 RSAPublicKey DSAKey DSAPrivateKey DSAPublicKey KeyBuilder MessageDigest Signature RandomData CryptoException Rozhraní reprezentující veřejný RSA klíč. Klíč může být použit pro ověření podpisu či pro zašifrování dat. Základní rozhraní pro implementaci veřejného a soukromého klíče DSA algoritmu. Rozhraní reprezentující soukromý DSA klíč určený k podepsání dat. Rozhraní reprezentující veřejný DSA klíč určený k ověření podpisu. Třída určená pro tvorbu objektů reprezentujících kryptografické klíče. Abstraktní třídy pro hašovací funkce. Abstraktní třída pro algoritmy digitálního podpisu. Abstraktní třída pro algoritmy generující náhodná data. Výjimka používá při práci s Java Card cryptography API Tabulka 2: Třídy a rozhraní balíčku javacard.security (pokračování tabulky 1) Druhým balíčkem Java Card cryptography API je balíček javacardx.crypto. Obsahuje třídu Cipher určenou pro implementování šifrování a rozhraní KeyEncryption určené pro práci se zašifrovanými klíči. Popis obou obsahuje následující tabulka. Cipher KeyEncryption Abstraktní třída reprezentující šifrovací algoritmus. Všechny implementované algoritmy tuto třídu rozšiřují. Třída definuje rozhraní pro práci se šiframi tj. k šifrování a dešifrování. Rozhraní, které poskytuje možnost šifrovat kryptografické klíče. Tabulka 3: Třídy a rozhraní balíčku javacardx.crypto 4.3 Práce s Java Card cryptography API Tvorba kryptografických klíčů Filosofie práce s Java Card cryptography API se odvíjí od návrhu API, kde veškeré kryptografické objekty (klíče, algoritmy, funkce) jsou odpovídajícími objekty daného typu v jazyce Java. Šifrovací algoritmus, který je reprezentován instancí nějaké konkrétní podtřídy abstraktní třídy Cipher, používá pro šifrování či dešifrování svůj klíč, který je ovšem instancí šifrovacího algoritmu akceptován pouze jako instance nějaké třídy implementující rozhraní Key či některého jeho rozšiřujícího rozhraní (např. SecretKey). Je tedy nejprve nutné instance tříd klíčů vytvořit a naplnit je byty, které tvoří klíč. K vytváření instancí klíčů slouží třída KeyBuilder a její metoda buildkey. Ta vrací instanci, která je typu

42 28 KAPITOLA 4 Java Card cryptography API Key. Lze si ji představit jako typovou obálku, která bude posléze naplněna byty klíče metodou setkey (či dále nastavena dalšími metodami podle typu klíče). Metoda buildkey má následující signaturu: public static Key buildkey(byte keytype, short keylength, boolean keyencryption) Parametr keytype určuje, jaký typ klíče má být vytvořen. Tento parametr lze zadat jako některou z konstant definujících typ klíče. Parametr keylength určuje, jakou délku má mít vytvářený klíč. Tento parametr lze zadat jako některou z konstant definujících délku klíče pro daný typ klíče. Parametr keyencryption určuje, zda má být vytvářený klíč v zašifrované formě, tj. data, kterými bude klíč nastaven, jsou šifrovaná. Příklad vytvoření DES klíče o délce 8 bytů: Key deskey = KeyBuilder.buildKey(KeyBuilder.TYPE_DES, KeyBuilder.LENGTH_DES, false); Vytvořený objekt je typu Key. Pro další práci s klíči je však vhodné přetypovat vrácenou instanci na typ, který ji reprezentuje. Tímto lze na vytvořeném klíči volat metody, které mohou být pro každý typ klíče specifické. Přetypování na DESKey: DESKey deskey = (DESKey)KeyBuilder.buildKey(KeyBuilder.TYPE_DES, KeyBuilder.LENGTH_DES, false); Vytvořený přetypovaný objekt klíče lze nyní naplnit daty klíče. K tomu slouží v případě klíče pro DES metoda setkey definován v rozhraní DESKey. Signatura metody je následující: public void setkey(byte[] keydata, short koff) Parametr keydata označuje pole bytů obsahující byty klíče. Parametr koff určuje offset, na němž v poli keydata začíná část bytů klíčů. Nastavení klíče byty pro dané pole tedy probíhá takto: byte[] deskeybytes = {(byte) 0x38, (byte) 0x12, (byte) 0xA4, (byte) 0x19, (byte) 0xC6, (byte) 0x3B, (byte) 0xE7, (byte) 0x71}; deskey.setkey(deskeybytes, (short) 0);

43 KAPITOLA 4 Java Card cryptography API 29 Jiné typy klíčů nežli DES klíč mohou vyžadovat odlišný způsob inicializace. Kupříkladu RSA veřejný klíč je nutné inicializovat nastavením modulu a exponentu, což ilustruje následující příklad: RSAPublicKey publickey = publickey = (RSAPublicKey) KeyBuilder.buildKey(KeyBuilder.TYPE_RSA_PUBLIC, KeyBuilder.LENGTH_RSA_512, false); publickey.setexponent(publicexponentbytes, (short) 0, (short) publicexponentbytes.length); publickey.setmodulus(modulusbytes, (short) 0, (short) modulusbytes.length); Je-li při vytváření klíče parametr keyencryption nastaven jako true, znamená to, že data klíče jsou nastavovaná v zašifrované formě. Vytvořený klíč s parametrem keyencryption jako true je instance třídy implementující rozhraní KeyEncryption balíčku javacardx.crypto. Toto rozhraní definuje metody setkeycipher a getkeycipher, kterými lze nastavovat metodu, která je použita k šifrování klíče, resp. ji vracet. Metodou buildkey je tedy standardně vytvořen objekt klíče. Jemu je metodou setkeycipher předána instance šifrovací metody a metodou pro nastavení bytů klíče v objektu jsou předány byty klíče v zašifrované formě Šifrování a dešifrování dat Šifrování a dešifrování dat je realizováno konkrétními třídami rozšiřujícími třídu Cipher. Konkrétní třídy implementují danou šifrovací metodu, v kódu se však pracuje pouze s třídou Cipher. Instance objektu šifry, kterou lze šifrovat a dešifrovat data, je získána pomocí metody getinstance třídy Cipher. Signatura metody je následující: public static Cipher getinstance(byte algorithm, boolean externalaccess) Parametr algorithm určuje, pro jaký algoritmus má být vrácena instance. Tento parametr lze zadat jako některou z konstant třídy Cipher definujících šifrovací algoritmus. Parametr externalaccess určuje, zda má být instance algoritmu přístupná i externě z jiného kontextu, než v jakém byla vytvořena. K vytvořené instanci mohou přistupovat applety z kontextu, v jakém byla instance vytvořena tedy applet, který ji vytvořil a applety stejného balíčku. Mohou k ní však pomocí pomocí shareable mechanismu popsaném v oddílu přistupovat i applety z jiných balíčků (jiných kontextů). Nastavení externalaccess parametru na false určuje, že instance nemá být přístupná jinému kontextu, než v jakém byla vytvořena. Při nastavení parametru externalaccess na false implementace využívá transientní pole, například s parametrem CLEAR_ON_DESELECT. Toto kromě přístupnosti kontextů k danému poli určuje též, že applet, který k poli přistupuje, musí být aktuálně vybrán. Pole je běhovým prostředím udržováno pouze po dobu, kdy je applet vybrán. Po získání instance metody je nutné metodu inicializovat nastavit jí klíče, mód, ve kterém

44 30 KAPITOLA 4 Java Card cryptography API má metoda pracovat (šifrování/dešifrování), a volitelné parametry (např. inicializační vektor). K tomu slouží dvě varianty metody init. Jejich signatura je následující: public void init(key thekey, byte themode) public void init(key thekey, byte themode, byte[] barray, short boff, short blen) Parametr thekey určuje objekt klíče, který má být metodě předán. Parametr themode určuje, zda má metoda pracovat v módu šifrování (Cipher.MODE_ENCRYPT), nebo dešifrování (Cipher.MODE_DECRYPT). Parametr barray specifikuje pole obsahující specifické inicializační parametry dané metody. Parametr boff určuje offset, na němž v poli barray začíná část s inicializačními parametry. Parametr blen určuje délku inicializačních parametrů v poli barray. Následující příklad ilustruje vytvoření instance šifry RSA s formátováním výplní podle PKCS1, která bude šifrovat data zadaným veřejným klíčem. // publickey je instance klíče typu RSAPublicKey Cipher rsa = Cipher.getInstance(Cipher.ALG_RSA_PKCS1, false); rsa.init(publickey, Cipher.MODE_ENCRYPT) Následující příklad ilustruje vytvoření instance šifry DES v CBC režimu se zadaným inicializačním vektorem, která bude dešifrovat. Data nejsou formátována výplní. // deskey je instance klíče typu DESKey // vector je pole osmi bytů použité jako inicializační vektor Cipher des = Cipher.getInstance(Cipher.ALG_DES_CBC_NOPAD, false); des.init(deskey, Cipher.MODE_DECRYPT, vector, (short)0, (short)8); Vlastní šifrování či dešifrování je provedeno metodami update a dofinal. Jejich signatury jsou následující: public short update(byte[] inbuff, short inoffset, short inlength, byte[] outbuff, short outoffset) public short dofinal(byte[] inbuff, short inoffset, short inlength, byte[] outbuff, short outoffset) Parametr inbuff určuje pole, které obsahuje vstupní data algoritmu. Ta budou šifrována, či dešifrována podle nastaveného módu metody. Parametr inoffset určuje offset, na němž v poli inbuff začínají data k šifrování, či dešifrování. Parametr inlength určuje délku dat k zašifrování v poli inbuff. Parametr outbuff určuje pole, do něhož bude zapisován otevřený, či šifrový text (podle módu metody). Může se jedna o stejné pole jako inbuff. Parametr outoffset určuje offset, na který bude do pole outbuff zapsán otevřený, či šifrový

45 KAPITOLA 4 Java Card cryptography API 31 text (podle módu metody). Obě metody šifrují, či dešifrují data z vstupního pole inbuff do výstupního pole outbuff. Obě metody vrací, kolik bytů bylo vloženo do výstupu v poli outbuff. Metoda update se používá v případě, kdy data k zašifrování, či dešifrování nejsou celá přítomna v jednom poli, či jsou získávána v blocích postupně. K zašifrování/dešifrování posledního bloku dat je nutné použít metodu dofinal. Metoda dofinal se používá v případě, kdy jsou všechna data k zašifrování, či dešifrování přítomna v jednom poli, či k zašifrování/dešifrování poslední části dat, jejichž předchozí části byly šifrovány/dešifrovány metodou update. Metoda dofinal ukončuje proces šifrování/dešifrování a resetuje instanci šifry do stavu, v jakém byla inicializována metodou init (inicializační vektor je ovšem nastaven na nulu). Je doporučené používat metodu dofinal ve všech případech, kdy je to možné. Metoda update při výpočtech využívá dodatečné struktury v paměti pro ukládání mezivýsledků a její výkonnost může být horší než výkonnost metody dofinal. Příklad zašifrování dat pomocí v předchozím příkladu inicializovaného objektu algoritmu DES: des.dofinal(apdubuffer, (short) ISO7816.OFFSET_CDATA, bytesread, apdubuffer, (short) (ISO7816.OFFSET_CDATA)); Poznámka: Pro šifrovací metodu 3DES není definována konstanta, která může být předána parametru metody Cipher.getInstance. Namísto toho je instance šifry 3DES vytvořena získání instance šifry DES, která je inicializována klíčem typu 3DES Generování a ověřování digitálního podpisu Proces generování a ověřování digitálního podpisu se velmi podobá procesu šifrování či dešifrování pomocí třídy Cipher. K práci s digitálním podpisem se však namísto ní využívá třídy Signature. Konkrétní třídy implementují danou metodou podpisu, v kódu se však pracuje pouze s třídou Signature. Instance objektu podpisu, kterou lze podepisovat data a ověřovat podpis, je získána pomocí metody getinstance třídy Signature. Signatura metody je následující: public static Signature getinstance(byte algorithm, boolean externalaccess) Parametr algorithm určuje, pro jaký algoritmus má být vrácena instance. Tento parametr lze zadat jako některou z konstant třídy Signature definujících metodu podpisu. Metoda podpisu v sobě zahrnuje kombinaci hašovací funkce a šifrovacího algoritmu. Parametr externalaccess určuje, zda má být instance algoritmu přístupná i externě z jiného kontextu, než v jakém byla vytvořena. Význam je stejný jako v případě stejnojmenného

46 32 KAPITOLA 4 Java Card cryptography API parametru v metodě getinstance třídy Cipher. Po získání instance metody je nutné metodu inicializovat nastavit jí klíče, mód, ve kterém má metoda pracovat (podpis/ověření), a volitelné parametry (např. inicializační vektor). K tomu slouží dvě varianty metody init. Jejich signatura je následující: public void init(key thekey, byte themode) public void init(key thekey, byte themode, byte[] barray, short boff, short blen) Parametr thekey určuje objekt klíče, který má být metodě předán. Parametr themode určuje, zda má metoda pracovat v módu podepisování (Signature.MODE_SIGN), nebo ověření podpisu (Signature.MODE_VERIFY). Parametr barray specifikuje pole obsahující specifické inicializační parametry dané metody. Parametr boff určuje offset, na němž v poli barray začíná část s inicializačními parametry. Parametr blen určuje délku inicializačních parametrů v poli barray. Následující příklad ilustruje vytvoření instance podpisové metody využívající šifru RSA s formátováním výplní podle PKCS1, která bude šifrovat zadaným soukromým klíčem haš dat k podepsání pomocí hašovací funkce SHA-1. Signature podpis = Signature.getInstance(Signature.ALG_RSA_SHA_PKCS1, false); podpis.init(privatekey, Signature.MODE_SIGN); Podepsání dat je provedeno metodami update a sign. Jejich signatury jsou následující: public void update(byte[] inbuff, short inoffset, short inlength) public short sign(byte[] inbuff, short inoffset, short inlength, byte[] sigbuff, short sigoffset) Parametr inbuff určuje pole, které obsahuje vstupní data pro podepsání. Parametr inoffset určuje offset, na němž v poli inbuff začínají data k podepsání. Parametr inlength určuje délku dat k podepsání v poli inbuff. Parametr sigbuff určuje pole, do něhož budou zapsány byty podpisu. Parametr sigoffset určuje offset, na který bude do pole sigbuff zapsán podpis. Metoda update se používá v případě, kdy data k podepsání nejsou celá přítomna v jednom poli, či jsou získávána v blocích postupně. Metoda pouze předává hašovací funkci další data, z nichž je vypočítávána haš. Vlastní podepsání provádí metoda sign, jíž se i v případě využití metody update předá poslední blok dat. Metoda sign se používá k vlastnímu podepsání dat, tj. zašifrování haše dat k podepsání. V případě, kdy jsou všechna data k podepsání přítomna v jednom poli, lze použít tuto metodu bez nutnosti používání metody update. Metoda sign ukončuje proces generování podpisu

47 KAPITOLA 4 Java Card cryptography API 33 a resetuje instanci podepisovací metody do stavu, v jakém byla inicializována metodou init (inicializační vektor je ovšem nastaven na nulu). Je doporučené používat metodu sign ve všech případech, kdy je to možné. Metoda update při výpočtech využívá dodatečné struktury v paměti pro ukládání mezivýsledků a její výkonnost může být horší než výkonnost metody sign. Metoda sign vrací délku podpisu. Příklad podepsání pomocí v předchozím příkladu inicializovaného objektu podepisovací metody: // buffer je pole bytů obsahující data k podepsání // signaturedata je pole, do něhož budou vloženy byty podpisu podpis.sign(buffer, (short) ISO7816.OFFSET_CDATA, bytesread, signaturedata, (short) 0); Ověření podpisu je zajištěno podobně jako podepsání kombinací metody update a metody verify. Signatura metody verify je následující: public boolean verify(byte[] inbuff, short inoffset, short inlength, byte[] sigbuff, short sigoffset, short siglength) Parametr inbuff určuje pole, které obsahuje podepisovaná data k ověření. Parametr inoffset určuje offset, na němž v poli inbuff začínají podepisovaná data k ověření. Parametr inlength určuje délku podepisovaných dat v poli inbuff. Parametr sigbuff určuje pole, které obsahuje byty podpisu. (Pole může být stejné jako pole inbuff.) Parametr sigoffset určuje offset, na kterém začínají v poli sigbuff byty podpisu. Parametr siglength určuje délku podpisu. Metoda verify vrací true, pokud došlo k úspěšnému ověření podpisu. V opačném případě vrací false. Metoda update se opět používá v případě, kdy podepisovaná data k ověření nejsou celá přítomna v jednom poli, či jsou získávána v blocích postupně. Metoda pouze předává hašovací funkci další data, z nichž je vypočítávána haš. Vlastní ověření provádí metoda verify, jíž se v případě využití metody update předá poslední blok dat. Metoda verify se používá k vlastnímu ověření dat, tj. dešifrování podpisu veřejným klíčem a porovnáním dešifrovaného podpisu s vygenerovanou haší pro data, která jsou ověřována. V případě, kdy jsou všechna data k ověření přítomna v jednom poli, lze použít tuto metodu bez nutnosti používání metody update. Metoda verify ukončuje proces generování podpisu a resetuje instanci podepisovací metody do stavu, v jakém byla inicializována metodou init (inicializační vektor je ovšem nastaven na nulu).

48 34 KAPITOLA 4 Java Card cryptography API Je doporučené používat metodu verify ve všech případech, kdy je to možné. Metoda update při výpočtech využívá dodatečné struktury v paměti pro ukládání mezivýsledků a její výkonnost může být horší než výkonnost metody verify. Následující příklad ilustruje proces ověření podpisu: // pole buffer obsahuje data o délce datalength // za nimi pole buffer obsahuje byty podpisu o délce 64 podpis.init(publickey, Signature.MODE_VERIFY); boolean verifyok = podpis.verify(buffer, (short) (ISO7816.OFFSET_CDATA), (short) datalength, buffer, (short) (ISO7816.OFFSET_CDATA + datalength),(short) 64); Práce s hašovacími funkcemi Hašovací funkce jsou reprezentovány abstraktní třídou MessageDigest. Konkrétní třídy, které třídu MessageDigest rozšiřují, obsahují implementace hašovacích metod. Díky návrhu Java Card cryptography API se však v kódu pracuje pouze se třídou MessageDigest. Instance objektu hašovací funkce je získána pomocí metody getinstance třídy MessageDigest. Signatura metody je následující: public static MessageDigest getinstance(byte algorithm, boolean externalaccess) Parametr algorithm určuje, pro jakou hašovací metodu má být vrácena instance. Tento parametr lze zadat jako některou z konstant třídy MessageDigest definujících hašovací funkci. Parametr externalaccess určuje, zda má být instance hašovací funkce přístupná i externě z jiného kontextu, než v jakém byla vytvořena. Význam je stejný jako v případě stejnojmenného parametru v metodě getinstance třídy Cipher. Následující příklad ilustruje vytvoření instance hašovací funkce MD5: MessageDigest md5 = MessageDigest.getInstance(MessageDigest.ALG_MD5, false); Vlastní výpočet haše je zajištěn metodami update a dofinal. Jejich signatury jsou následující: public void update(byte[] inbuff, short inoffset, short inlength) public short dofinal(byte[] inbuff, short inoffset, short inlength, byte[] outbuff, short outoffset) Parametr inbuff určuje pole, které obsahuje data, z nichž má být počítána haš. Parametr inoffset určuje offset, na němž v poli inbuff začínají data, z nichž má být

49 KAPITOLA 4 Java Card cryptography API 35 počítána haš. Parametr inlenght určuje délku dat, z nichž má být počítána haš. Parametr outbuff určuje pole, do něhož bude zapsána haš. Parametr outoffset určuje offset, na který bude do pole outbuff zapsána haš. Metoda update se používá v případě, kdy data, z nichž má být počítána haš, nejsou celá přítomna v jednom poli, či jsou získávána v blocích postupně. Metoda pouze předává hašovací funkci další data, z nichž je vypočítávána haš. Proces je vždy nutno zakončit metodou dofinal, jíž je předán poslední blok dat. Metoda dofinal se používá v případě, kdy jsou všechna data, z nichž má být vypočítána haš, přítomna v jednom poli, či k ukončení výpočtu haše, kdy je jí předána poslední část dat, z nichž má být počítána haš, přičemž předchozí části byly hašovací funkci předány metodou update. Metoda dofinal ukončuje proces výpočtu haše a resetuje instanci hašovací funkce. Je tedy možné po zavolání metody dofinal danou instanci hašovací funkce použít k výpočtu další hašovací funkce. Je doporučené používat metodu dofinal ve všech případech, kdy je to možné. Metoda update při výpočtech využívá dodatečné struktury v paměti pro ukládání mezivýsledků a její výkonnost může být horší než výkonnost metody dofinal. Příklad výpočtu haše pomocí instance hašovací funkce MD5: // pole buffer obsahuje data, z nichž má být vypočítána haš. Data se nacházejí na pozici 10 a mají délku 50 // haš je generována do pole digest md5.dofinal(buffer, (short)10, (short)50, digest, (short)0); Generování náhodných dat Abstraktní třída RandomData reprezentuje generátor náhodných dat. Pomocí ní lze v appletu generovat náhodná data splňující kryptografické požadavky. Instance objektu generátoru náhodných dat je získána pomocí metody getinstance třídy RandomData. Signatura metody je následující: public static RandomData getinstance(byte algorithm) Parametr algorithm určuje, jakého typu generátoru náhodných dat má být vrácená instance. Tento parametr lze zadat jako některou z konstant třídy RandomData. Následující příklad ilustruje vytvoření instance generátoru náhodných dat pro kryptograficky

50 36 KAPITOLA 4 Java Card cryptography API bezpečné generování náhodných dat: RandomData generator = RandomData.getInstance(RandomData.ALG_SECURE_RANDOM); Metodou setseed lze generátoru zadat volitelný seed v podobě pole bytů. Signatura metody setseed je následující: public void setseed(byte[] buffer, short offset, short length) Parametr buffer určuje pole, které obsahuje byty seedu. Parametr offset určuje offset, na kterém v poli buffer začínají byty seedu. Parametr length určuje délku seedu. Náhodná data jsou generována metodou generatedata. Signatura metody generatedata je následující: public void generatedata(byte[] buffer, short offset, short length) Parametr buffer určuje pole, do něhož budou zapsány byty vygenerovaného data. Parametr offset určuje offset v poli buffer, od kterého budou zapsány byty vygenerovaného data. Parametr length určuje délku vygenerovaných dat v bytech. Následující příklad ilustruje generování náhodných dat: // data jsou generována do pole output a mají délku 10 generator.generatedata(output, (short)0, (short)10); Java Card cryptography API na kartě GemXpresso R3.2 a v simulátoru JCWDE Jelikož je balíček javax.crypto určen jako volitelné rozšíření knihoven platformy a je předmětem vývozních omezení není specifikací jeho plná implementace vyžadována. Proto se jeho obsah liší mezi různými typy karet či jednotlivých dodávek. Kapitola 6 uvádí, jaké algoritmy jsou přítomny na kartě GemXpresso R3.2 E64. Ve verzi Java Card Development Kitu nepodporuje simulátor JCWDE používání kryptografických operací. K tomu lze využít simulátor z verze Java Card Development Kitu, který podporuje vybrané algoritmy. Konkrétní algoritmy podporované simulátorem jsou k nalezení v uživatelské příručce Java Card Development Kitu na straně 109.

51 KAPITOLA 5 Specifikace Open Platform 37 5 Specifikace Open Platform Specifikace Java Card nedefinuje, jakým způsobem je spravován obsah karty a řešena bezpečnostní architektura, která umožňuje například zabezpečené nahrávání appletů na kartu, či výpis obsahu karty pouze na základě autentikace karty a terminálu. Java Card specifikace přináší pouze obecnou specifikaci appletů pro instalaci a odstranění appletů (installer applet a deletion manager). Java Card Development Kit na základě této specifikace obsahuje referenční implementaci installeru, kterou lze využít například pro správu appletů v simulátoru cref. Jak se ukázalo v kapitole 3, existují bezpečnostní rizika spojená s nahráváním appletů na kartu, kdy je potřeba zaručit, že nahrávaný.cap soubor není po své verifikaci již dále změněn. Open platform je specifikace vytvořená asociací Visa ve spolupráci s výrobci čipových karet definující standardy správy obsahy karty nezávislé na výrobci karet a hardwaru. Tímto tedy karty podporující Open platform přinášejí jednotnou architekturu správy karty a jejího zabezpečení. Specifikace Open platform pokrývá zabezpečenou komunikaci s kartou, správu obsahu karty, možnosti ověřování obsahu nahrávaného na kartu mezi více zainteresovanými subjekty (vydavatelem karty a poskytovatelem aplikace) a možnosti, jak lze appletům zprostředkovat kryptografické služby jako je například zabezpečená komunikace. Tato kapitola a dodatek A představuje výtah základních vlastností a mechanismů souvisejících s bezpečností, které specifikace Open platform [13] definuje. Blíže se kapitola v dodatku věnuje tématu vzájemné autentikace karty a externí entity a zabezpečené komunikaci mezi kartou a externí entitou. Tyto pasáže jsou inspirací či návodem, jak appletům pomocí Java Card cryptography API navrhovat vlastní schémata autentikace a zabezpečené komunikace. Detailní seznámení s principy definovanými specifikací bylo nutné k implementaci knihovny SimpleSmartCardAPI popisované v kapitole 8. Poznámka: V následujícím textu jsou applety označovány jako aplikace. Open platform specifikace není určena pouze pro Java Card platformu, ale i pro jiné technologie, které nepoužívají termín applet, nýbrž aplikace. 5.1 Role entit na kartě definované Open Platform Card Manager Hlavní entitou v rámci Open platform specifikace na kartě je tzv. Card manager. Card manager je zodpovědný za přístup aplikací k běhovému prostředí, zpracování APDU příkazů došlých na kartu, správu obsahu karty a bezpečnost. Z oblasti správy obsahu karty Card manager nabízí funkce jako je nahrávání aplikací, tvorba jejich instancí, mazání aplikací a rušení instancí. Z oblasti bezpečnosti pak správu kryptografických klíčů, šifrování a dešifrování, generování digitálních podpisů a verifikace nahrávaných aplikací. Card manager lze na kartě považovat za zástupce vydavatele karet.

52 38 KAPITOLA 5 Specifikace Open Platform Bezpečnostní domény Bezpečnostní domény (Security domains) jsou speciální aplikace, které na kartě zastupují poskytovatele aplikací. Pro své aplikace poskytují kryptografické služby a zajišťují správu klíčů. Aplikace může kupříkladu využívat zabezpečené komunikace pomocí zabezpečeného kanálu veškeré procesy spojené s otevírání zabezpečeného kanálu, přenosem APDU příkazů přes kanál a jejich šifrování, dešifrování či ověření však nemusí implementovat sama aplikace, ale právě pro tyto operace může využít služeb bezpečnostní domény. Card manager na kartě může být považován za výchozí bezpečnostní doménu na kartě. Služby zabezpečené komunikace, jakož i kryptografické klíče, které poskytuje Card manager mohou aplikace využít. Přestože je tedy možné pro aplikace využívat klíče, které spravuje Card manager, není to doporučený postup. Aplikace může klíče pro kryptografické operace spravovat sama ad hoc a podobně sama implementovat kryptografické služby. Efektivnější pro vývoj aplikací je však svěřit tyto procesy bezpečnostní doméně, která tyto služby zajišťuje pro všechny další aplikace stejného poskytovatele aplikací. Každý poskytovatel aplikací má díky tomu na kartě svůj privátní prostor, kryptografické služby a klíče pro vlastní aplikace Bezpečnostní domény kromě uvedených služeb poskytují ve spolupráci s Card managerem možnost kontroly integrity a původu nahrávaných aplikací před tím, než jsou aplikace fyzicky nahrány na kartu. Bezpečnostní doména musí aplikacím nabízet možnost otevření zabezpečeného kanálu, ověření externí vzájemnou autentikací, extrakci příkazů přijatých zabezpečeným kanálem (tj. je zkontrolována integrita příkazu a/nebo příkaz je dešifrován a veškerá dodatečná data týkající se bezpečnosti jsou z příkazu odstraněna), nevratné smazání veškerých dat použitých při vzájemné autentikaci či vytváření zabezpečeného kanálu. 5.2 Nahrávání a instalace aplikací Ověřené entity mohou měnit seznam aplikací či knihoven nahraných na kartu. Aplikace a knihovny jsou na kartě uloženy v tzv. Load souborech, které vznikají nahráním.cap souboru na kartu. Obsah je kartě předáván v podobě data bloků a výsledkem je nahraný Load soubor na kartě. Proces nahrání aplikace na kartu se skládá ze dvou povinných fází a jedné volitelné. První fázi představuje požadavek na Card manager týkající se nahrání.cap souboru. Tento požadavek je vyvolán příkazem INSTALL ve variantě [for load]. Ve druhé fázi jsou následně kartě postupně předány jednotlivé bloky nahrávaného.cap souboru aplikace pomocí příkazu LOAD. V závislosti na limitech přenosu dat komunikačního protokolu a limitech karty může být soubor aplikace rozdělen do několika bloků, které jsou postupně nahrány na kartu. Třetí nepovinná, fáze je instalace aplikace pomocí příkazu INSTALL ve variantě [for install], skrze níž vznikne funkční instance aplikace, kterou lze zvolit příkazem SELECT. Možné jsou zde tedy dva scénáře provést všechny tři příkaze bezprostředně po sobě, či provést pouze první dva a aplikaci takto pouze na kartu přednahrát a její instalaci odložit na dobu pozdější.

53 KAPITOLA 5 Specifikace Open Platform 39 Ilustrace 7: Proces nahrávání aplikace na kartu Aplikaci lze z paměti karty odstranit příkazem DELETE. Příkaz DELETE odstraňuje jak Load soubory nahrané na kartu, tak instance aplikací. Předtím, než je Load soubor či instance odstraněna, Card manager kontroluje, zda na odstraňovaný objekt existuje nějaká reference. Pokud ano, odstranění daného Load souboru či instance nemůže být provedeno. 5.3 Zabezpečení v Open platform Open platform definuje následující mechanismy zabezpečení: Vzájemná autentikace karty a externí entity. Komunikace zabezpečeným kanálem šifrování APDU příkazů a kontrola jejich integrity zabezpečující, že nedochází k úpravě APDU příkazů. Zašifrované předávání kryptografických klíčů kartě. Správa obsahu karty prostřednictvím zabezpečeného kanálu nahrávat či mazat applety lze pouze po vzájemné autentikaci karty a externí entity. Kontrola na kartu nahrávaného obsahu pomocí DAP (Data Authentication Pattern) zaručení, že na kartu jsou nahrávané nemodifikované.cap soubory pocházející od důvěryhodného zdroje. Delegovaná správa obsahu karty možnost spravovat obsah karty bez přispění Card manageru, přičemž je zaručen původ a integrita nahrávaných aplikací. Globální PIN přístupný aplikacím nahraným na kartě. Jednotlivé mechanismy zabezpečení jsou blíže popsány v dodatku A.

54 40 KAPITOLA 5 Specifikace Open Platform 5.4 Open platform API Open platform definuje API, které mohou applety nahrané na kartě využít pro přístup ke službám Card manageru či Bezpečnostních domén. Rozhraní ProviderSecurityDomain na kartě reprezentuje poskytovatele aplikací, tj. jedná se o reprezentaci Bezpečnostní domény. Třída implementující rozhraní poskytuje pro aplikace tohoto poskytovatele kryptografické operace, správu klíčů, podporu zabezpečené komunikace či zabezpečeného nahrávání obsahu. Pomocí metod tohoto rozhraní lze implementovat služby, které Bezpečnostní doména poskytuje aplikacím. API dále definuje třídu OPSystem, která obsahuje metody pro nastavování a ověřování globálního PINu, nastavování life cyclu aplikace a Card manageru a metodu, kterou aplikace získá referenci na svou přidruženou Bezpečnostní doménu. Blíže viz. [13] nebo příklad appletu využívající služeb Bezpečnostní domény [15]. 5.5 Global platform Specifikace Open platform byla později přejmenována na Global platform a byla vytvořena nová verze této specifikace definující nové mechanismy zabezpečení, kterými jsou například zabezpečený kanál protokolu 02, který umožňuje například zabezpečení APDU odpovědí kontrolou integrity.

55 KAPITOLA 6 Karta GemXpresso Pro R Karta GemXpresso Pro R3.2 Tato kapitola popisuje vlastnosti karty GemXpresso Pro R3.2, která byla použita pro testování. Popsána dále bude i adaptace Open platform na této kartě a specifika implementace platformy Java Card. 6.1 Obecná charakteristika karty Karta GemXpresso Pro R3.2 je čipová karta od firmy GemPlus z typové řady GemXpresso Pro R3.x. Typová řada GemXpresso Pro R3.x je kompatibilní se specifikacemi: Java Card obsahujícím specifikace Java Card (specifikace virtuálního stroje), Java Card Runtime Environment (specifikace běhového prostředí) a Java Card API (API knihoven Java Card nahraných na kartě). Global platform card specification (známé též jako Open platform 2.0.1) definující management karty. Na kartě tedy lze spouštět applety kompilované vůči knihovnám Java Card či Správa obsahu karty a karty samotné je možná pomocí postupů definovaných v Open platform, což přináší možnosti zabezpečeného nahrávání appletů, otevírání zabezpečeného kanálu a možnosti využívat pro applety různých výrobců vlastní kryptografické klíče a kryptografické služby. Karta tedy splňuje i ideovou charakteristiku karet Java card spočívající možnosti spouštět na kartě různé applety a to ne z předdefinované množiny přednahraných appletů, ale včetně možnosti nové applety na kartu nahrávat. 6.2 Zabezpečení Karta GemXpresso Pro R3.2 plně implementuje zabezpečení a kryptografické služby definované specifikacemi, s nimiž je kompatibilní. V případě Java Card platformy se jedná o následující aspekty a služby zabezpečení: Soubory tříd jsou pro zajištění jazykové bezpečnosti před nahráním na kartu verifikovány pomocí nástrojů Java Card Development Kitu. Mezi tyto nástroje patří nástroj Converter a verifycap, verifyexp a verifygen. (viz. kapitola 3) Java Card Runtime Environment prostřednictvím applet firewallu izoluje jednotlivé applety, čímž je zajištěno, že applet nemůže získat přístup k objektům jiného appletu, pokud mu to není explicitně povoleno. (viz. kapitola 3) Kryptografické operace a služby nabízejí balíčky javacard.security a javacardx.crypto. (viz. kapitola 4) V případě Open platform se jedná o následující aspekty a služby zabezpečení: Možnost nastavení globálního PINu, který může být použit applety nahranými na kartě.

56 42 KAPITOLA 6 Karta GemXpresso Pro R3.2 Vzájemná autentikace externí entity a karty. Zabezpečený kanál (kontrola integrity APDU příkazů a zašifrování dat APDU příkazů). Zabezpečená správa obsahu karty. Definování Bezpečnostních domén poskytujících aplikacím kryptografické služby. Zabezpečení komunikace mezi Card managerem, Bezpečnostními doménami a aplikacemi. Karta nepodporuje delegovanou správu obsahu. 6.3 Kryptografické klíče Karta GemXpresso Pro R3.2 dle Open platform definuje statické klíče, které vlastní Card manager. Klíče jsou sdružovány do sad klíčů. Karta může obsahovat 129 sad měnitelné sady s indexem a neměnitelnou sadu s indexem 255. Každá sada obsahuje tři klíče definované Open platform jako ENC použitý k šifrování dat a zabezpečené komunikaci, MAC používaný pro výpočet MAC hodnoty při zabezpečení kontrolou integrity a KEK klíč pro šifrování klíčů předávaných kartě příkazem PUT KEY. Card manager karty využívá klíčů nastavených od výrobce. Ty mohou být dodány spolu s kartou, častější však bývá předání pouze tzv. mother či master klíče (označovaný KMC klíč), z něhož jsou klíče ENC, MAC a KEK odvozeny. K odvození klíčů je použit 3DES v režimu ECB. Klíčem je KMC klíč a šifrována jsou diversifikační data. Ta jsou pro každý z trojice klíčů jiná. Jejich hodnotu určuje následující tabulka. Symbol označuje zřetězení hodnot. ENC 0xAA 0xBB seriové číslo IC 0xF0 0x01 0xAA 0xBB seriové číslo IC 0x0F 0x01 MAC 0xAA 0xBB seriové číslo IC 0xF0 0x02 0xAA 0xBB seriové číslo IC 0x0F 0x02 KEK 0xAA 0xBB seriové číslo IC 0xF0 0x03 0xAA 0xBB seriové číslo IC 0x0F 0x03 0xAA a 0xBB jsou dva nejméně významné byty AID Card manageru. Sériové číslo IC je 4-bytová hodnota. Je získáno z CPLC (Card Production Life Cycle) dat. CPLC data lze z karty získat příkazem GET DATA či INITIALIZE UPDATE. Levá polovina (8 bytů) daného statického klíče je získána zašifrováním levé poloviny diversifikačních dat pro daný klíč pomocí 3DES v režimu ECB za použití KMC klíče. Analogický je postup pro pravou polovinu klíče. Hodnota KMC může být určena jako specifická pro zákazníka či pro sadu karet, či je použita výchozí, která je ASCII kódem řetězce 'GEMXPRESSOSAMPLE', tj. 0x47 0x45 0x4D 0x58 0x50 0x52 0x45 0x53 0x53 0x4F 0x53 0x41 0x4D 0x50 0x4C 0x45. Pro nasazení karet je tedy nutné tuto hodnotu změnit, či změnit jednotlivě hodnoty statických klíčů (ty nemusejí splňovat podmínku odvoditelnosti z nějakého KMC, tj. mohou mít hodnoty na sobě zcela nezávislé).

57 KAPITOLA 6 Karta GemXpresso Pro R Podporované algoritmy a klíče Java Card Crypto API Karta GemXpresso Pro R3.2 podporuje v rámci Java Card cryptography API následující algoritmy a typy klíčů: V balíčku javacard.security jsou metodou KeyBuilder.buildKey podporovány následující typy a délky klíčů: javacard.security.keybuilder.type_des pro DES klíč javacard.security.keybuilder.type_des_transient_deselect pro DES klíč; klíč je na uchováván pouze v RAM paměti a po vybrání jiné aplikace, resetu či vyjmutí karty je klíč smazán javacard.security.keybuilder.type_des_transient_reset pro DES klíč; klíč je na uchováván pouze v RAM paměti a po resetu či vyjmutí karty je klíč smazán javacard.security.keybuilder.type_rsa_public pro veřejný RSA klíč javacard.security.keybuilder.type_rsa_private pro soukromý RSA klíč javacard.security.keybuilder.type_rsa_crt_private pro soukromý RSA klíč uložený ve formě využívané Čínskou větou o zbytcích javacard.security.keybuilder.length_des pro DES klíč o délce 8 bytů javacard.security.keybuilder.length_des3_2key pro DES klíč o délce 16 bytů javacard.security.keybuilder.length_des3_3key pro DES klíč o délce 24 bytů javacard.security.keybuilder.length_rsa_512 pro RSA klíč o délce 512 bitů javacard.security.keybuilder.length_rsa_768 pro RSA klíč o délce 768 bitů javacard.security.keybuilder.length_rsa_1024 pro RSA klíč o délce 1024 bitů javacard.security.keybuilder.length_rsa_2048 pro RSA klíč o délce 2048 bitů V balíčku javacard.security jsou metodou Signature.getInstance podporovány následující algoritmy: javacard.security.signature.alg_des_mac4_nopad pro výpočet hodnoty MAC s použitím DES či 3DES v CBC režimu. MAC má délku 4 byty. Vstupní data musí být zarovnána na bloky délky 8. javacard.security.signature.alg_des_mac8_nopad pro výpočet hodnoty MAC s použitím DES či 3DES v CBC režimu. MAC má délku 8 bytů. Vstupní data musí být zarovnána na bloky délky 8. javacard.security.signature.alg_des_mac4_iso9797_m1 pro výpočet hodnoty MAC s použitím DES či 3DES v CBC režimu. MAC má délku 4 byty. Vstupní data jsou formátována výplní dle schématu metody 1 popisované v ISO javacard.security.signature.alg_des_mac8_iso9797_m1 pro výpočet

58 44 KAPITOLA 6 Karta GemXpresso Pro R3.2 hodnoty MAC s použitím DES či 3DES v CBC režimu. MAC má délku 8 bytů. Vstupní data jsou formátována výplní dle schématu metody 1 popisované v ISO javacard.security.signature.alg_des_mac4_iso9797_m2 pro výpočet hodnoty MAC s použitím DES či 3DES v CBC režimu. MAC má délku 4 byty. Vstupní data jsou formátována výplní dle schématu metody 2 popisované v ISO javacard.security.signature.alg_des_mac8_iso9797_m2 pro výpočet hodnoty MAC s použitím DES či 3DES v CBC režimu. MAC má délku 8 bytů. Vstupní data jsou formátována výplní dle schématu metody 2 popisované v ISO javacard.security.signature.alg_rsa_sha_pkcs1 pro výpočet podpisu pomocí zašifrování 20 bytové haše vypočítané SHA formátované dle PKCS1 schématu. javacard.security.signature.alg_rsa_md5_pkcs1 pro výpočet podpisu pomocí zašifrování 16 bytové haše vypočítané MD5 formátované dle PKCS1 schématu. javacard.security.signature.alg_rsa_sha_iso9796 pro výpočet podpisu pomocí zašifrování 20 bytové haše vypočítané SHA formátované dle schématu popsaném v ISO V balíčku javacard.security jsou metodou RandomData.getInstance podporovány následující algoritmy: javacard.security.randomdata.alg_secure_random pro generování kryptograficky bezpečených náhodných dat. javacard.security.randomdata.alg_pseudo_random pro generování pseudonáhodných dat. V balíčku javacard.security jsou metodou MessageDigest.getInstance podporovány následující algoritmy: javacard.security.messagedigest.alg_sha pro použití algoritmu SHA. javacard.security.messagedigest.alg_md5 pro použití algoritmu MD5. V balíčku javacard.security podporuje třída KeyPair následující parametry: javacard.security.keypair.alg_rsa pro pár klíčů algoritmu RSA. javacard.security.keypair.alg_rsa_crt pro pár klíčů algoritmu RSA uložených ve formě využívané Čínskou větou o zbytcích javacard.security.keybuilder.length_rsa_512 pro klíče délky 512 bitů javacard.security.keybuilder.length_rsa_1024 pro klíče délky 1024 bitů javacard.security.keybuilder.length_rsa_2048 pro klíče délky 2048 bitů (pouze pro ALG_RSA_CRT)

59 KAPITOLA 6 Karta GemXpresso Pro R V balíčku javacardx.crypto jsou metodou Cipher.getInstance podporovány následující algoritmy: javacardx.crypto.cipher.alg_des_cbc_nopad pro DES či 3DES v CBC režimu; algoritmus neformátuje vstupní data výplní, ta musí být zarovnána na bloky délky 8. javacardx.crypto.cipher.alg_des_ecb_nopad pro DES či 3DES v ECB režimu; algoritmus neformátuje vstupní data výplní, ta musí být zarovnána na bloky délky 8. javacardx.crypto.cipher.alg_des_cbc_iso9797_m1 pro DES či 3DES v CBC režimu. Vstupní data jsou formátována výplní dle schématu metody 1 popisované v ISO javacardx.crypto.cipher.alg_des_ecb_iso9797_m1 pro DES či 3DES v ECB režimu. Vstupní data jsou formátována výplní dle schématu metody 1 popisované v ISO javacardx.crypto.cipher.alg_des_cbc_iso9797_m2 pro DES či 3DES v CBC režimu. Vstupní data jsou formátována výplní dle schématu metody 2 popisované v ISO javacardx.crypto.cipher.alg_des_ecb_iso9797_m2 pro DES či 3DES v ECB režimu. Vstupní data jsou formátována výplní dle schématu metody 2 popisované v ISO javacardx.crypto.cipher.alg_rsa_nopad pro RSA; algoritmus neformátuje vstupní data výplní. javacardx.crypto.cipher.alg_rsa_pkcs1 pro RSA; vstupní data jsou formátova výplní podle schématu PKCS1.

60 46 KAPITOLA 6 Karta GemXpresso Pro R3.2

61 KAPITOLA 7 Applet GemSafe 47 7 Applet GemSafe V kapitole 4 byly popsány principy a použití Java Card cryptography API balíčků, které Java Card platforma používá ke kryptografickým operacím. Jak bylo z popisu patrné, tyto balíčky poskytují pouze implementaci kryptografických algoritmů různých typů a případně s využitím různých norem specifikujících například formátování výplní, neposkytují však žádná hotová řešení, jimiž by bylo možné kartu rovnou použít například k autentikaci. Tato řešení je nutné implementovat ve formě appletů právě prostředky Java Card cryptography API, případně též s využitím služeb Card manageru dle specifikace Open platform. Applety lze samozřejmě implementovat vlastními silami, nebo využít hotových produktů, k nimž patří například applet GemSafe. V následujících oddílech jsou ve stručnosti popsány základní funkce appletu a princip práce s ním. Pro bližší informace o možnostech konfigurace appletu, detailu jeho funkční či APDU příkazů, které podporuje, viz. [17]. 7.1 Funkce appletu GemSafe Applet GemSafe mají jako Load soubor nahraný od výrobce určité typové řady karet GemXpresso. Výrobce, společnost Gemalto, nabízí též typovou řadu karet GemSafeXpresso, což jsou karty, na nichž je nahrán pouze applet GemSafe, který je určen jako výchozí, a na tyto karty nelze nahrávat další applety. GemSafe je applet poskytující funkce, s nimiž může být karta, na níž je GemSafe applet spuštěn, používána jako součást systémů infrastruktury veřejného klíče. Applet může být použitý k podepisování dokumentů. V appletu je uložen soukromý klíč, kterým jsou dokumenty podepisovány. Mezi funkce appletu patří též generování páru veřejný soukromý klíč, takže jako soukromý klíč použitý k podepisování může být použitý ten vygenerovaný na kartě, tj. soukromý klíč nikdy neopustí kartu. Dalším využitím appletu je jeho funkce bezpečného úložiště certifikátů a obecně jakýchkoli dat. Přístup k úložišti může být zabezpečen PINem či požadavkem vzájemné autentikace. Vzájemná autentikace může být appletem vyžadována i pro provádění některých operací (např. podepisování). Applet podporuje vzájemnou autentikaci na bázi symetrických i asymetrických kryptografických algoritmů. To, jakým způsobem budou jednotlivé datové soubory či objekty zabezpečeny (PIN, vzájemná autentikace, zabezpečený kanál v libovolných kombinacích), lze pro jednotlivé soubory a objekty nastavit během fáze personalizace. GemSafe applet podporuje komunikaci vlastním zabezpečeným kanálem mezi ním a terminálem. Přenos ukládaných dat je tedy zabezpečen prostředky zabezpečeného kanálu, který odpovídá mechanismu zabezpečeného kanálu definovaným Open platform. Appletu je možné nastavit několik různých profilů, tzv. bezpečnostních oblastí, z nichž každé může obsahovat různé klíče či data. Přístup ke každému prostředí může být zabezpečen vlastním PINem a mezi jednotlivými prostředími lze vytvářet podmíněné vazby či hierarchie. Pro jednotlivé PINy lze nastavit počet pokusů pro jejich úspěšné ověření, ale též například

62 48 KAPITOLA 7 Applet GemSafe počet jejich použití, kdy se po daném počtu úspěšných ověření PIN zablokuje a je třeba nastavit nový. PINy lze při vytváření navazovat na sebe například tím, že k odblokování jednoho je zapotřebí jiný PIN. 7.2 Spuštění appletu GemSafe GemSafe applet je třeba nejprve z Load souboru nainstalovat příkazem INSTALL [for install]. Během instalace lze appletu v parametrech předat inicializační parametry, v nichž lze například určit, kolik neúspěšných vzájemných autentikací povede k zablokování karty, kolik klíčů bude appletem podporováno pro uložení či, v jakých případech má být požadováno ověření PINem. Po nainstalování appletu následuje fáze personalizace, během níž jsou v appletu vytvořeny bezpečnostní oblasti, předány kryptografické klíče či binární soubory, které budou uložené na kartě. Komunikace s appletem během fáze personalizace je vedena zabezpečeným kanálem. Po explicitním ukončení fáze personalizace přechází applet do aplikační fáze, v níž už nejde provádět některá konfigurační nastavení prováděná ve fázi personalizace. Pro personalizační a aplikační fázi applet definuje seznam APDU příkazů, které přijímá a jimiž jsou realizovány jednotlivé operace. 7.3 Využití appletu GemSafe ve výuce V rámci experimentu se podařilo applet GemSafe na kartě nainstalovat a personalizovat symetrickými klíči a PINem. Komunikace s appletem prostřednictvím ručně zadávaných APDU příkazů je však velmi náročná, jelikož data APDU příkazů jsou složena z mnoha jednotlivých parametrů, které na sebe mají často návaznosti. Z tohoto důvodu by bylo vhodné pro práci s GemSafe appletem používat či vyvinout aplikaci, jejímž prostřednictvím by bylo možné applet konfigurovat. Tato aplikace by obsahovala seznam APDU příkazů a pole a volby pro sestavování těchto APDU příkazů. V rámci výuky by poté bylo možné s appletem komunikovat a nechat jím realizovat kryptografické operace či se pokusit integrovat jeho funkčnost např. do operačního systému. 7.4 Jiná podobná řešení K dalším podobným řešením patří Muscle Card applet [18], který podobně jako applet GemSafe umožňuje realizovat kryptografické operace a fungovat v rámci systému infrastruktury veřejného klíče. Muscle Card applet je projekt zaměřený zejména na využívání služeb smart karet v prostředí operačního systému Linux.

63 KAPITOLA 8 Příprava úloh pro výuku 49 8 Příprava úloh pro výuku Jednou z hlavních motivací této diplomové práce bylo provést analýzu oblasti Java karet, jejich funkčnosti a podpůrných nástrojů s cílem zahrnout tématiku smart karet a konkrétně smart karet technologie Java Card do výuky kryptografie na ČVUT FEL Katedrou počítačů v oboru Výpočetní technika. V rámci grantu MŠMT Podpora výuky aplikované kryptografie (č.proj. 2525/2007) byla nakoupena sada smart karet technologie Java Card a jejich čteček. Následující oddíly popisují připravené úlohy týkající se práce s Java kartami, které jsou určeny k samostatné práci studentů na cvičeních. Je provedena diskuze dalších možných typů úloh, které by bylo možné zařadit do výuky. Zadání úloh včetně appletů úloh je umístěno na CD přílohu do adresáře ulohy\applety, kde se nachází zdrojové kódy appletů úloh, a ulohy\dokumentace, kam jsou umístěna zadání a podpůrné texty. Dodatek B pro příklad uvádí pokyny k úloze DES šifrování a zdrojový kód jejího appletu. 8.1 Zahrnutí Java karet do výuky Oblast smart karet se vyznačuje velkou šíří principů, kterým je nutné k rozumné práci s kartami porozumět. Týká se to jednak obecných témat týkající se praktického využití smart karet a dále pak principů, na nichž je založeno používání karty tedy komunikace s aplikacemi na kartě, komunikační APDU protokol, jímž jsou volány jednotlivé funkce aplikace na kartě. V případě Java karet se tématika dále týká pochopení výstavby Java card appletu. Zde se projevuje výhoda platformy Java Card, kde je kód appletu obecný a zcela odstíněn od konkrétních proprietárních technologií a díky tomu snáze pochopitelný a osvojitelný a to též z důvodu, že jsou applety Java Card programovány v podmnožině běžně rozšířeného jazyka Java. Díky tomu je uživatelům známé i vývojové prostředí, kdy lze k programování appletů použít jakékoliv vývojové prostředí podporující jazyk Java, ale též formát API dokumentace, která je pro API platformy Java Card vytvořena typickým stylem Javadoc dokumentace jako v případě standardní platformy jazyka Java. K problematičtějším oblastem patří proces konverze appletu na.cap soubor a následně nahrání.cap souboru na kartu a vytvoření instance appletu. Proces konverze appletu vyžaduje úpravy konfiguračních souborů nástroje Converter. Možnost použití freeware nástrojů pro správu obsahu karty je velmi omezená osvědčený nástroj GPShell [16] vyžaduje též nastavování konfiguračních souborů (resp. souborů skriptů, které tento nástroj vykonává). Pro správné nastavení obou nástrojů je nutné dobré pochopení problematiky, či na míru připravené konfigurační soubory, popř. nástroj či skript, který by umožňoval generování těchto souborů. Při procesu konverze a nahrávání appletu na kartu a také při testování appletu samotného (ať už na kartě či v simulátoru) může nastat velmi problematická situace ve chvíli, kdy je v nahrávaném appletu chyba. Tato chyba se může projevit chybovými hláškami při konverzi, nahrávání appletu na kartu i při komunikaci s appletem na kartě. Často je chyba indikována pouhým chybovým kódem status word. Pro uživatele, který se smart kartou pracuje poprvé, je

64 50 KAPITOLA 8 Příprava úloh pro výuku velmi obtížné z tohoto chybového kódu odvodit, čeho se chyba skutečně týká, v jaké části systému se může nacházet (tj. zda jde o chybu v appletu, špatně zadaný APDU příkaz či o chybu např. v procesu nahrávání) a jak chybu opravit. V neposlední řadě je též nutné pamatovat na fakt, že studenti se s kryptografií v rámci předmětu seznamují, což může zvyšovat riziko chyb v appletech. Potřebné jsou proto postupy a nástroje, které by studenty pokud možno odstínily od pro úlohy nepodstatných aspektů a naopak zdůraznily problematiku pokrytou úlohami. 8.2 Úlohy pro výuku Pro časovou dotaci jednoho cvičení (1,5 hodiny) byly vybrány následující tři úlohy: SimpleString DES šifrování RSA podepisování Úloha SimpleString Úloha SimpleString je míněna jako seznamovací úloha s výstavbou appletu a principy komunikace se smart kartou. Applet přijímá zaslaná data a na požádání je odesílá zpět. Úloha je založena na experimentování s tím, jak applet reaguje na různé příkazy. Je možné applet modifikovat například tak, aby vracel uložené data dvakrát za sebou či aby vracel data na ohraničená pozicemi specifikovanými v parametrech P1 a P2 APDU příkazu. K dispozici je plný a okomentovaný zdrojový kód appletu. Pomocí dodaných nástrojů je applet zkompilován, zkonvertován a nahrán na kartu. Komunikace s appletem má následující scénář: Z PC je appletu posláno pole bytů jako data. Následně je pro demonstraci persistence dat appletu možné kartu vyjmout ze čtečky a opět ji do ní vložit. Appletu je zaslán dotaz na délku dat, která uchovává. Applet reaguje délkou uložených dat. Následně je appletu zaslán dotaz na data dané délky a applet reaguje odpovědí obsahující prvním příkazem zaslané pole bytů. Ilustrace 8: Scénář komunikace s appletem SimpleString

65 KAPITOLA 8 Příprava úloh pro výuku Úloha DES šifrování Úloha DES šifrování je zaměřena na práci se symetrickým šifrovacím algoritmem DES (Data Encryption Standard). Algoritmus je v úloze použit pro šifrování a dešifrování dat zaslaných appletu spuštěném na kartě. Zároveň je tato úloha představením obecných principů práce s třídami balíčků javacard.security a javacardx.crypto tedy s třídami a rozhraními, které na platformě Java Card zajišťují rámec kryptografických služeb. K dispozici je okomentovaný zdrojový kód appletu, v němž jsou některé části kódu související s použitím Java Card cryptography API vynechány. Úkolem je tyto části doplnit s pomocí Javadoc dokumentace platformy či textu, který seznamuje s Java Card cryptography API a uvádí příklady jeho použití. Po doplnění zdrojového kódu je pomocí dodaných nástrojů applet zkompilován, zkonvertován a nahrán na kartu. Úloha má následující scénáře komunikace s appletem: A: Z PC je appletu na kartě zaslán otevřený text k zašifrování. Na APDU příkaz s otevřeným textem applet odpovídá příslušným šifrovým textem. Na straně PC je k dispozici nástroj umožňující provést kontrolní šifrování. Výsledek lze porovnat s výsledkem přijatým od appletu na kartě. B: Přijatý šifrový text od appletu (či jiný na pc zašifrovaný) je zaslán appletu na kartě. Na APDU příkaz se šifrovým textem applet odpovídá otevřeným textem. Ten by měl odpovídat původnímu otevřenému textu. Ilustrace 9: Scénář komunikace s appletem DES úlohy

66 52 KAPITOLA 8 Příprava úloh pro výuku Úloha RSA podpis Úloha RSA podpis je zaměřena na práci s asymetrickou kryptografií konkrétně s RSA algoritmem použitým pro podepisování dat. Úloha demonstruje vytvoření digitálního podpisu a proces jeho verifikace na platformě Java Card. Proces podepsání dokumentu probíhá ve výpočtu haše funkcí SHA a dále pak RSA zašifrováním této haše soukromým klíčem. Tímto je vytvořen podpis. Ověření podpisu spočívá ve výpočtu haše dokumentu, která se pro korektní ověření podpisu musí rovnat původní haši dešifrované z podpisu veřejným klíčem. Podobně jako v předchozí úloze, i zde jde zároveň o ukázku principů práce s třídami balíčků javacard.security a javacardx.crypto tedy s třídami, které na platformě Java Card zajišťují rámec kryptografických služeb. K dispozici je okomentovaný zdrojový kód appletu, v němž jsou některé části kódu související s použitím Java Card cryptography API vynechány. Úkolem je tyto části doplnit s pomocí Javadoc dokumentace platformy či textu, který seznamuje s Java Card cryptography API a uvádí příklady jeho použití. Po doplnění zdrojového kódu je pomocí dodaných nástrojů applet zkompilován, zkonvertován a nahrán na kartu. Úloha má následující scénáře komunikace s appletem: A: Z PC je appletu na kartě zasláno pole bytů. Na APDU příkaz se zaslanými daty applet odpovídá podpisem dat. Na straně PC je k dispozici nástroj umožňující získat podpis zaslaných dat i prostřednictvím PC. Výsledek tedy lze porovnat s výsledkem přijatým od appletu na kartě. Ilustrace 10: Scénář komunikace s appletem úlohy RSA podpis

67 KAPITOLA 8 Příprava úloh pro výuku 53 B: Z PC je appletu na kartě zasláno pole bytů a jeho podpis (lze využít výsledků předchozího scénáře, anebo si podpůrným nástrojem vygenerovat pro zcela nová data nový podpis; či data, pro něž je již nějaký podpis vytvořen, záměrně pozměnit a pozorovat negativní výsledek ověření). Na APDU příkaz se zaslanými daty a jejich podpisem applet odpovídá pouze prostřednictvím stavového slova v případě úspěšného ověření podpisu jde o standardní stavové slovo označující korektní provedení příkazu. V opačném případě bude vráceno stavové slovo označující neúspěšné ověření Další možná témata úloh Úlohy postavené na třec výše uvedených scénářích byly zadány studentům na cvičení předmětu Aplikovaná kryptografie v letním semestru akademického roku 2007/2008, na nichž jsem asistoval. Mezi počtem cca. 25 studentů, kteří pracovali ve dvojicích či samostatně, většina dokončila první dvě úlohy. Několika studentům se podařilo dokončit všechny tři úlohy i přesto, že na PC v učebně bylo nejdříve nutné nainstalovat všechny potřebné nástroje. Zdá se tedy, že výběr úloh je časově odpovídající jednomu cvičení. Tyto tři úlohy představují základ vývoje appletů využívajících kryptografii na platformě Java Card a použitích základních kryptografických primitiv, nabízejí se též další témata, která by bylo možné zařadit mezi úlohy reprezentující základní využití smart karet. Programování aplikace na straně pc, která komunikuje s kartou V této úloze může být podstatou implementování metody aplikace, která bude spuštěná na PC a prostřednictvím karty bude podepisovat nějaká data. Úkolem by bylo doplnit implementaci metody, která komunikuje s kartou a zasílá ji APDU příkaz, kterým dojde k podepsání appletu zaslaných dat. Úloha může být kombinovaná tím, že na straně appletu budou vynechány části kódu v metodě, která podepisuje data. Aplikace v sobě bude mít zabudovanou funkčnost, ověřování podpisu podepsaných dat. Implementace výplně Úkolem může být v metodě appletu implementovat nějaký typ formátování výplní otevřeného textuu, který bude šifrován na kartě. Komunikace zabezpečeným kanálem či vzájemná autentikace karty a externí entity Cílem této úlohy může být doplnění metod jak na straně appletu, tak na straně aplikace na pc komunikující s kartou, které budou realizovat zabezpečenou komunikaci mezi appletem na kartě a aplikací na pc či jejich vzájemnou autentikaci. Práce s appletem GemSafe Úkolem v této úloze může být práce s appletem GemSafe (viz. kapitola 7) nahraným na kartě. Operací může být například uložení páru asymetrických klíčů a jejich prostřednictvím podepsání dokumentu. Tato úloha však vyžaduje dodatečnou aplikaci na straně PC, skrze níž bude možné applet GemSafe konfigurovat. 8.3 Podpůrná aplikace pro testování appletů úloh Pro podporu práce s těmito úlohami byla vytvořena aplikace Správce úloh Java Card (Java Card Exercise Manager), která pro každou úlohu obsahuje pomocné funkce. Představuje také přístupový bod k appletům úloh a lze skrze ni s těmito applety komunikovat.

68 54 KAPITOLA 8 Příprava úloh pro výuku Ilustrace 11: Aplikace pro testování appletů úloh Jedná se o aplikaci s grafickým uživatelským rozhraním naprogramovanou v jazyku Java z důvodu možné přenositelnosti mezi různými operačními systémy, které se mohou vyskytovat v učebnách. Aplikace je vyvinuta s použitím knihovny pro přístup ke smart kartám SimpleSmartCard API, která je popsána v následující kapitole. V levé horní části aplikace obsahuje panel APDU manažeru, skrze který lze sestavovat APDU příkazy zasílané na kartu. Součástí je též seznam instrukcí, které applet dané úlohy podporuje. Po volbě některé z instrukcí je automaticky doplněn kód a třída instrukce do polí INS, resp. CLA, což umožňuje věnovat pozornost pouze vyplňování polí s parametry a daty. Ve spodní části aplikace obsahuje oblast, do níž je vypisována APDU komunikace mezi PC a kartou. Veškeré odeslané APDU příkazy a přijaté odpovědi na ně jsou přehledně vypisovány zde. V pravé části aplikace obsahuje panel záložek, přičemž každá záložka odpovídá aplikací podporované úloze. Výběrem záložky dojde k zaslání příkazu SELECT, který na kartě vybere applet příslušící dané úloze. V případě kryptografických úloh je pak obsahem každé záložky podpora dané úlohy ve formě kontrolních šifrování či podepisování dat na PC, jimiž lze kontrolovat výstupy appletu. Aplikace obsahuje pouze ty ovládací prvky, které jsou nutné k testování úloh. Nedochází tedy k zahlcení a zmatení uživatelů volbami, které nesouvisí s právě prováděnou činností. Pro kontrolní výpočty kryptografických operací aplikace využívá balíčků java.security a javax.crypto, které jsou součástí standardní knihovny jazyka Java. Aplikaci je možné rozšiřovat o další úlohy rozšířením abstraktní třídy AbstractExercise, která definuje následující metody, které je nutné či možné implementovat: protected String getexercisename() vrací název úlohy. protected String getaid() vrací AID úlohy zapsané hexadecimálně jako řetězec bez oddělovačů a prefixu 0x.

69 KAPITOLA 8 Příprava úloh pro výuku 55 protected void getinstructions(map<string, String> instructiontable) vrací Map, kde klíče jsou názvy instrukcí a hodnoty hexadecimální kódy instrukcí zapsané jako řetězec bez oddělovačů a prefixu 0x. Tyto definice jsou použité v seznamu instrukcí. protected String getcla() vrací výchozí hodnotu CLA pole pro daný applet úlohy. Hodnota je zapsána hexadecimálně jako řetězec bez oddělovačů a prefixu 0x. protected CryptoService getcryptoservice() vrací instanci třídy implementující rozhraní CryptoService (viz. dále). protected JTextField getinputdatafield() vrací referenci na textové pole této záložky, z něhož má být zpřístupněna možnost kopírovat data do pole dat APDU příkazu v panelu APDU manažer. protected void initcomponents(jpanel panel) slouží k vytvoření komponent této záložky a jejich umístění na poskytnutý panel. Třída musí ve svém konstruktoru ve chvíli, kdy je plně inicializovaná zavolat metodu nadtřídy install s parametrem this. Pokud třída implementuje metodu actionperformed(actionevent e) rozhraní ActionListener, musí v jejím těle nejprve zavolat super.actionperformed(e), aby neodstínila zpracování událostí nadtřídy. Záložku je pak nutné přidat do kódu metody inittabs ve třídě ExercisePane. Tím je záložka zařazena do systému aplikace. Příklad implementace záložky DES šifrování se nachází v dodatku C. Aplikace definuje rozhraní CryptoService, které usnadňuje volání kryptografických metod v rámci aplikace. Toto rozhraní implementující třídy pak v jednotlivých metodách realizují danou kryptografickou operaci a pro zadané parametry vrací výsledek. Rozhraní definuje tyto metody: Metoda encryptdata pro otevřený text zadaný v parametru a pro daný klíč text zašifruje a vrátí. Metoda decryptdata pro šifrový text zadaný v parametru a pro daný klíč text dešifruje a vrátí. Metoda getsignature pro v parametru zadaná data a soukromý exponent s modulem data podepíše a podpis vrátí. Metoda verifysignature pro v parametru zadaná data, veřejný exponent s modulem ověří správnost zadaného podpisu. Příklad implementace metody encryptdata ve třídě DESCryptoService: public byte[] encryptdata(byte[] plaindata, byte[] keybytes) { try { SecretKey key = new SecretKeySpec(keyBytes, "DES");

70 56 KAPITOLA 8 Příprava úloh pro výuku } Cipher descipher = Cipher.getInstance("DES"); descipher.init(cipher.encrypt_mode, key); return descipher.dofinal(plaindata); } catch (Exception e) { System.err.println(e.getMessage()); return null; } Zdrojový kód testovací aplikace se nachází na CD příloze v adresáři aplikace\javacardexcercisemanager\src. Dokumentace aplikace se nachází na přiloženém CD v adresáři aplikace\javacardexcercisemanager\doc. Spustitelný soubor aplikace je na CD v adresáři aplikace\javacardexcercisemanager\dist. Aplikace pro spuštění vyžaduje nainstalované běhové prostředí Javy verze Aplikace Java Card image manager Aplikace Java Card Image Manager je jednoduchá aplikace, která umožňuje formátování karet do jejich výchozího stavu, což je vhodné po cvičeních, kdy jsou na karty nahrány applety úloh a je nutné karty rychle uvést do původního stavu, v jakém karta byla před nahráním těchto appletů. Aplikace je podobně jako ostatní úlohy komunikující s kartami postavena na knihovně SimpleSmartCardAPI. Aplikace pracuje ve dvou režimech. V prvním režimu vytváří obraz obsahu karty seznam Load souborů a instancí appletů, které jsou na kartě nahrané a vytvořené. Jedná se o prostý seznam AID. Pro každý typ karty (identifikovaný ATR) lze mít v rámci aplikace jeden obraz. Tyto obrazy jsou vkládány do seznamu a seznam ukládán do souboru. Vytvořit obraz pro kartu lze kliknutím na tlačítko 'Add Image' a následným vložením karty, pro níž má být vytvořen obraz, do čtečky. Ilustrace 12: Aplikace Java Card image manager

71 KAPITOLA 8 Příprava úloh pro výuku 57 Ve druhém režimu aplikace provádí porovnání obsahu vložené karty s obrazem (má-li pro daný typ karty aplikace uložený obraz). Load soubory a instance, které na kartě oproti uloženému obrazu obsahu karty přebývají, jsou z karty odstraněny. V tomto režimu se aplikace nachází do té doby, dokud tento režim není explicitně zastaven. Kliknutím na tlačítko 'Start Cards Formatting to Images' je spuštěno formátování a každá vložená karta bude porovnána se svým odpovídajícím obrazem a přebytečné instance či Load soubory vymazány. Režim formátování lze zastavit kliknutím na tlačítko 'Stop Cards Formatting to Images'. Tímto způsobem lze tedy velmi rychle navrátit do původního stavu i více karet. Pro přístup k obsahu karet aplikace využívá instance třídy CardManagerAdapter a JavaCardAPDUManager ze SimpleSmartCardAPI knihovny. Naváže s kartou připojení zabezpečeným kanálem s použitím výchozího master klíče karet GemXpresso a pomocí metod getloadfiles a getinstances třídy JavaCardAPDUManager se dotáže na obsah karty. Obdržené seznamy buďto uloží jako obraz, pokud je v režimu vytváření obrazu karty, anebo porovná se seznamy uloženými pro danou kartu a prvky, které nejsou v průniku obou seznamů, z karty odstraní. Zdrojový kód aplikace se nachází na CD příloze v adresáři aplikace\javacardimagemanager\src. Dokumentace aplikace se nachází na přiloženém CD v adresáři aplikace\javacardimagemanager\doc. Spustitelný soubor aplikace je na CD v adresáři aplikace\javacardimagemanager\dist. Aplikace pro spuštění vyžaduje nainstalované běhové prostředí Javy verze 1.6.

72 58 KAPITOLA 8 Příprava úloh pro výuku

73 KAPITOLA 9 Knihovna SimpleSmartCardAPI 59 9 Knihovna SimpleSmartCardAPI Pro vývoj aplikací využitých v této práci, které komunikují s kartou, bylo nutné vyvinout knihovnu SimpleSmartCardAPI, která poskytuje snadný programový přístup ke kartě a appletům. Knihovna SimpleSmartCardAPI je knihovna napsaná v jazyku Java, která slouží ke komunikaci s kartami, simulátorem a umožňuje volat vybrané funkce Card manageru. Knihovna je navržená jako objektová nadstavba nad knihovnami javax.smartcardio a APDUIO. Následující oddíly popisují motivaci k vytvoření této knihovny, specifika a detaily jejího návrhu, příklady použití knihovny a také příklady implementace některých oblastí Open platform specifikace týkající se zabezpečení. Ty mohou sloužit jako příklad psaní aplikačního kódu komunikujícího s appletem na kartě s využitím metod zabezpečení Open Platform. S využitím této knihovny byly vyvinuty všechny v diplomové práci zahrnuté aplikace komunikující s kartou, přičemž v nich už díky tomu nebylo nutné dodávat žádné části kódu či metod, které by komunikovaly s kartou. Popisu knihovny je zde věnována větší pozornost, protože představuje základ všech ostatních aplikací, jejichž vývoj se díky tomu omezil pouze na aplikační a prezentační logiku, a také z důvodu, že obsahuje implementované funkce specifikace Open platform týkající se zabezpečené komunikace a může tedy sloužit jako příklad implementace aplikace komunikující s appletem zabezpečeným kanálem. Podrobné informace o třídách a rozhraních knihovny a detailech metod jsou popsány v javadoc API dokumentaci (anglický jazyk) na přiloženém CD v adresáři SimpleSmartCardAPI\doc. Zdrojový kód knihovny SimpleSmartCardAPI se nachází v adresáři SimpleSmartCardAPI\src. Přeložená distribuce knihovny (soubor SimpleSmartCardAPI.jar) je uložena v adresáři SimpleSmartCardAPI\dist. 9.1 Analýza existujících řešení a požadavky kladené na knihovnu Existuje několik knihoven, které poskytují API pro komunikaci s čipovými kartami z programového kódu. Pomocí těchto API lze přistupovat k terminálu (čtečce karet) a případně kartě v něm vložené. Vložené kartě lze pak zasílat APDU příkazy. Základní knihovnou je knihovna APDUIO dodávaná spolu s Java Card Development Kitem. Tuto Java knihovnu využívají nástroje kitu a lze jí též využít i při psaní aplikace, která bude komunikovat s kartou. Tato knihovna obsahuje též možnost komunikace se simulátory karet JCWDE a Cref dodávané s kitem. Komunikace se simulátory je založena na socketovém připojení mezi aplikací a simulátorem, skrze které jsou simulátoru zasílány APDU příkazy. Další knihovnou je Open Card Framework (resp. Global Platform framework, který podobně jako Global Platform specifikace nahradila Open platform specifikaci, nahradil Open Card Framework) [16]. Tato knihovna je dostupná jednak ve verzi pro jazyk C, tak i ve verzi pro jazyk Java. Tuto knihovnu využívá nástroj GPShell, což je nástroj příkazové řádky pomocí něhož lze jednoduchým skriptovacím jazykem přistupovat ke kartě a posílat kartě APDU příkazy a instrukce Card manageru, které definuje Open/Global platform. Na podobné bázi je postavena i knihovna JCOP API. Jedná se o knihovnu napsanou v jazyce Java, která je součástí JCOP tools, což je sada nástrojů určených pro vývoj aplikací pro Java

74 60 KAPITOLA 9 Knihovna SimpleSmartCardAPI Card v rámci vývojové prostředí Eclipse. Knihovna a nástroje spolupracují s kartami kompatibilními se specifikací GlobalPlatform, primárně je však určena pro karty platformy JCOP (Java Card Open Platform), což je platforma vyvinutá společností IBM. Pomocí knihovny lze podobně jako pomocí Open/Global platform knihovny komunikovat s kartou pomocí APDU příkazů, ale knihovna obsahuje i třídy a metody, které umožňují volat funkce Card manageru. Verze Java Development Kitu 1.6 obsahuje balíček javax.smartcardio, který je určený pro komunikaci se smart kartami. Java od verze 1.6 tedy obsahuje přímo ve své standardní distribuci třídy a metody. Knihovna však umožňuje pouze práci s připojenými terminály (čtečkami) a vloženými kartami. Tímto tedy navazuje na knihovnu APDUIO, představuje však v kódu snáze použitelnější API. Mezi rysy všech uvedených knihoven však patří návaznost jejich API na nativní systémová volání. To znamená, že tyto knihovny s výjimkou JCOP API neposkytují příliš abstraktní přístup ke kartě a appletům, což v případě objektově orientovaných programů vede k nutnosti vytvořit v aplikaci vrstvu, která adaptuje jednotlivé skupiny společných funkčností do tříd a přidává podpůrné objekty typu např. Listener, jejichž použitím nedojde k narušení návrhu relaxované architektury aplikace vlivem komunikace objektů z nižších vrstev s objekty vyšších vrstev. Vzhledem k tomu, že požadavek na komunikaci jak s kartou, tak se simulátorem, a zároveň požadavek návrhu knihovny, který by podporoval objektový charakter aplikací, nesplňovala žádná ze jmenovaných knihoven, došlo k rozhodnutí vytvořit knihovnu novou, která by splňovala následující požadavky a charakteristiky, čímž by usnadňovala vývoj dalších aplikací, které byly pro podporu komunikace s Java kartami plánované: Různé vrstvy abstrakce využití knihovny by mělo být pokud možno co nejobecnější tj. aby podporovala jak jednoduché operace typu APDU komunikace s kartou, tak operace související se správou Card manageru či nabízela podporu instrukčního API (tj. instrukcím, které applet dokáže vykonávat) appletů na kartě nahraných. Podpora komunikace se simulátorem knihovna by měla nabízet možnost komunikace se simulátorem pomocí stejného rozhraní jako probíhá komunikace s kartou. Knihovna by měla nabízet vícestupňovou hierarchii dědičnosti založenou na rozhraních, abstraktních třídách a konkrétních podtřídách, což podpoří možnosti rozšiřování knihovny o další funkčnost (např. dodatečně přidané protokoly zabezpečeného kanálu, nové specifikace Card manageru, či případné nové varianty APDU komunikace). Knihovna by měla být vystavěna nad již existující knihovnou zajišťující komunikaci s kartou. Knihovna by podle příslušné míry abstrakce dané vrstvy měla nabízet možnosti pracovat i s jinými datovými typy než byte (zejména se String). Knihovna by prvořadě měla podporovat karty používané ve výuce. Vzhledem k tomu, že nejstarší typ karet je GemXpresso R3, je tedy nutná podpora specifikace Open platform (s níž jsou novější typy karet zpětně kompatibilní). Implicitním požadavkem bylo využití jazyka Java, jelikož všechny uvažované aplikace, které by knihovnu využívaly, byly vlivem několika faktorů též plánovány vyvíjet v jazyku Java.

75 KAPITOLA 9 Knihovna SimpleSmartCardAPI 61 Jako knihovny, nad nimiž by byla nová knihovna postavena, byly zvoleny knihovny javax.smarcardio a APDUIO. První jmenovaná z důvodu, že je součástí standardní distribuce Javy a tedy přítomna na systémech, na nichž je nahrána verze 1.6 standardní platformy Java. Druhou knihovnou byla knihovna APDUIO, která jako jediná podporuje komunikaci se simulátorem a která je přítomna na všech systémech, na nichž je přítomen i simulátor (předpoklad je zde ten, že jak simulátor, tak knihovna jsou součástí Java Card Development Kitu, tudíž pokud je na cílovém systému přítomen simulátor, pak pravděpodobně i tato knihovna). Nově vyvíjená knihovna byla nazvána SimpleSmartCardAPI. 9.2 Architektura a návrh knihovny SimpleSmartCardAPI Knihovna je rozdělena do tří balíčků. Balíček cz.cvut.fel.vlasek.simpleapi.api obsahuje třídy a rozhraní, které jsou přímo určeny jako veřejné API celé knihovny. Balíček cz.cvut.fel.vlasek.simpleapi.impl zahrnuje třídy, které jsou implementací rozhraní a tříd balíčku api. Tyto třídy jsou též určené k používání, jako typy by však měly být používány třídy z balíčku api. Balíček cz.cvut.fel.vlasek.simpleapi.util obsahuje utility třídy využité napříč všemi třídami (jedná se zejména o metody poskytující konverzní a formátovací metody). Třídy knihovny lze rozdělit do tří úrovní abstrakce. Nejnižší úroveň představují třídy, jejichž instance reprezentují připojení ke kartě a kartu samotnou. Druhá úroveň tříd reprezentuje správce appletů. Třetí, nejvyšší úroveň tvoří třídy reprezentující applet samotný. Následuje popis nejdůležitějších tříd a rozhraní knihovny SimpleSmartCardAPI Rozhraní JavaCardAdapter Jedním ze základních rozhraní knihovny je rozhraní JavaCardAdapter. Jedná se o přístupový bod ke kartě či pohled na kartu a to bez ohledu na to, zda jde o skutečnou kartu vloženou do čtečky, nebo o kartu v podobě spuštěného simulátoru. JavaCardAdapter představuje stabilní rozhraní pro komunikaci s kartou. Všechny ostatní třídy vyšší úrovně, které komunikují s kartou nebo simulátorem, komunikují přes instanci některé ze tříd implementujících rozhraní JavaCardAdapter. Žádost o zaslání APDU příkazu je instancí třídy implementující rozhraní JavaCardAdapter převedena na žádost, kterou instance předá konkrétnímu spojení s kartou či simulátorem. Tím, že k instancím tříd implementujících rozhraní JavaCardAdapter by měly instance tříd vyšší úrovně abstrakce přistupovat typem tohoto rozhraní, je zajištěna nezávislost instancí tříd vyšší úrovně na konkrétním typu připojení tedy, zda se jedná o připojení k reálné kartě, nebo k simulátoru. JavaCardAdapter definuje metody pro poslání APDU příkazu založené na tom, že jednotlivá pole APDU příkazu jsou předána skrze parametry metody. Metody přijímají parametry typu byte, String či bytové pole obsahující byty APDU příkazu. Metodám lze předávat rovnou data APDU příkazů bez nutnosti specifikovat jejich délku, délka dat je dopočítána automaticky. JavaCardAdapter také definuje metody, jimiž lze v různých formátech získávat odpověď či status word odeslaného APDU příkazu. Rozhraní definuje též metodu select, jíž lze předat AID appletu, který má být na kartě vybrán.

76 62 KAPITOLA 9 Knihovna SimpleSmartCardAPI Ilustrace 13: Základní pohled na architekturu přístupu ke kartě pomocí knihovny SimpleSmartCardAPI JavaCardAdapter udržuje seznam objektů zajímajících se o průběh komunikace. Jedná se o instance tříd implementujících rozhraní APDUListener. Tyto instance jsou při každém přeneseném páru APDU příkaz APDU odpověď informovány o proběhlé komunikace a je jim předána instance třídy APDUEvent, která reprezentuje konkrétní APDU událost, tedy pár APDU příkaz APDU odpověď. Všechny třídy z vyšších vrstev návrhu aplikace, v níž je knihovna použita (např. z vrstvy View aplikace kupříkladu textové pole zobrazující výpis APDU komunikace) by měly implementovat rozhraní APDUListener a registrovat se u příslušné instance JavaCardAdapter, díky čemuž budou adaptérem automaticky informovány o APDU komunikaci. V rozhraní JavaCardAdapter jsou také definovány metody, pomocí nichž každá implementace tohoto rozhraní může vracet tabulku (instanci třídy Map) přiřazující kódům instrukcí a bytům status word textový popis (například pro instrukci s kódem 0xA4 popis 'SELECT'), kterého mohou využít třídy vypisující APDU komunikaci. Rozhraní JavaCardAdapter má pět implementací (tři konkrétní). První z nich je třída AbstractJavaCardAdapter. Tato třída je abstraktní a je určena k rozšiřování. Zajišťuje logiku registrování a informování posluchačů APDU komunikace a převody mezi metodami s různými typy parametrů. Další dvě implementace rozšiřují AbstractJavaCardAdapter a jedná se o konkrétní třídy JavaCardAPDUAdapter a JavaCardSimulatorAdapter. První z nich představuje přístupový bod k reálně kartě, druhá z nich k simulátoru.

77 KAPITOLA 9 Knihovna SimpleSmartCardAPI 63 Třída JavaCardAPDUAdapter předává žádosti o zaslání APDU příkazů knihovně javax.smartcardio, která APDU příkaz odešle na kartu. Třída JavaCardSimulatorAdapter žádost předává knihovně APDUIO, která APDU příkaz socketovým připojením pošle spuštěnému simulátoru. Pro třídy vyšší úrovně je navíc transparence zařízení, s nímž komunikují (karta, nebo simulátor), zajištěna tím, že APDU příkazy, které simulátor vyžaduje před komunikací s appletem (příkazy týkající se nahrání a vytvoření instance appletu v simulátoru), vykonává automaticky JavaCardSimulatorAdapter třídy vyšší úrovně tedy mohou provést standardní SELECT appletu a případné detaily s tím spojené jsou zajištěné implementacemi JavaCardAdapter. Další implementací rozhraní JavaCardAdapter je abstraktní třída CardManagerAdapter, který rozšiřuje JavaCardAPDUAdapter. Třída CardManagerAdapter definuje abstraktní metody odpovídající funkčnosti Card manageru na kartě (např. vytvoření instance appletu, nahrání appletu, atd.). Její rozšiřující potomci implementují konkrétní specifikaci Card manageru. Knihovna obsahuje implementaci Card manageru dle specifikace Open platform a to jeho funkčnosti týkající se správy appletů a Load souborů. Rozšiřující třídy implementují mechanismy vzájemné autentikace a komunikace zabezpečeným kanálem Rozhraní JavaCardConnections Instance tříd implementujících rozhraní JavaCardAdapter nejsou vytvářeny volně konstruktory, ale jejich tvorbu řídí instance tříd implementujících rozhraní JavaCardConnections. Rozhraní JavaCardConnections představuje abstrakci připojení, resp. objektu, který přiděluje přístupové body (JavaCardAdapter), s nimiž lze komunikovat s kartou. Specifikací terminálu, k němuž je připojena karta, popř. karty přímo, a protokolu komunikace lze získat instanci třídy implementující rozhraní JavaCardAdapter určené pro komunikaci s kartou. Pro získání adaptéru komunikujícího se simulátorem lze požádat příslušnou instanci třídy implementující rozhraní JavaCardConnections. Konkrétní třídy tohoto rozhraní jsou navrženy dle návrhového vzoru singleton. Maximálně jedna jejich instance existuje za běhu a ta je navíc globálně přístupná statickou metodou getcardconnection. Instance tříd implementujících rozhraní JavaCardConnections udržují seznam objektů zajímajících se o změny ve stavu vložených a vyjmutých karet ze čteček připojených k PC. Tyto objekty jsou instancemi tříd implementujících rozhraní JavaCardListener. Instance jsou při každém vložení i vyjmutí karty informovány o této změně, která je reprezentována instancí třídy JavaCardEvent. Rozhraní JavaCardConnections definuje několik metod užitečných při získávání seznamu terminálů, v nichž je vložena karta, či seznamu instancí reprezentujících vložené karty. Kromě abstraktní třídy AbstractJavaCardConnections, která je určena k rozšiřování konkrétními třídami reprezentujícími konkrétní typ připojí a obsahuje implementaci mechanismu registrování a informování posluchačů o změnách ve stavu vložených karet, knihovna obsahuje dvě konkrétní třídy JavaCardAPDUConnections a JavaCardSimulatorConnections. Třída JavaCardAPDUConnections vrací instance třídy JavaCardAPDUAdapter a je-li specifikována platforma správy karty, pak instance tříd CardManagerAdapter. Třída JavaCardSimulatorConnections vrací instance třídy

78 64 KAPITOLA 9 Knihovna SimpleSmartCardAPI JavaCardSimulatorAdapter Rozhraní JavaCardApplet Rozhraní JavaCardApplet představuje abstrakci appletu. Není podstatné, zda se jedná o applet, který na kartě (či simulátoru) skutečně existuje, o applet, který na kartě neexistuje, ale potenciálně bude vytvořen, či o applet, který představuje pouze pohled na existující applet na kartě. Myšlenka je zde podobná jako v případě třídy java.io.file, která reprezentuje soubor bez ohledu na to, zda tento soubor v souborovém systému existuje. Applety představují vyšší úroveň abstrakce při komunikaci s kartou. Idea je založena na myšlence, že nyní je komunikace vedena s appletem a jeho metodami, resp. instrukcemi. Odesílání APDU příkazů je zde postaveno na modelu volání metody, jíž se předají data odesílaná appletu, přičemž metoda vrací odpověď, kterou applet na příkaz odeslal. Každá instance třídy implementující rozhraní JavaCardApplet může mít asociovanou tabulku instrukcí. Jedná se o instanci Map, jejíž klíče jsou textové identifikátory a hodnoty kódy instrukcí. Kódům instrukcí lze tedy přiřadit textové zkratky, které budou zastupovat danou instrukci. Každá instance navíc zná své AID a umí se na kartě (je-li tam odpovídající applet, který reprezentuje, přítomen) vybrat, či se smazat. Instancím lze také přiřadit výchozí hodnotu CLA pole APDU příkazů. S appletem na kartě či simulátoru lze komunikovat pomocí tří kategorií metod. První kategorií jsou metody invokecommand. Ty umožňují zasílat appletu APDU příkazy, jejichž instrukce je specifikovaná textovou zkratkou definovanou v tabulce instrukcí. Druhou kategorií jsou metody send. Ty umožňují tvořit APDU příkaz pomocí zadaných parametrů metody. Obě uvedené kategorie pak mají čtyři varianty pro každý typ APDU příkazu, které usnadňují práci s metodami, protože podle dané varianty pomíjejí zadávání pro ně nepodstatných parametrů. Varianty jsou identifikované suffixem v názvu metody. 1. varianta case 1 APDU příkaz (žádná odesílaná data, žádná přijímaná data): bez suffixu (tj. invokecommand a send). 2. varianta case 2 APDU příkaz (žádná odesílaná data, přijímaná data): suffix AndReceive (tj. invokecommandandreceive a sendandreceive). 3. varianta case 3 APDU příkaz (odesílaná data, žádná přijímaná data): suffix WithData (tj. invokecommandwithdata a sendwithdata). 4. varianta case 4 APDU příkaz (odesílaná data, přijímaná data): suffix WithDataAndReceive (tj. invokecommandwithdataandreceive a sendcommandwithdataandreceive). Třetí kategorií jsou metody sendapdu, které umožňují přímou tvorbu APDU příkazů pomocí zadání všech parametrů reprezentujících jednotlivá pole APDU příkazu. Obě výše uvedené kategorie pouze transformují zadané parametry a posléze volají jednu z metod sendapdu. Ta přepošle žádost o odeslání APDU příkazu instanci třídy implementující rozhraní JavaCardAdapter.

79 KAPITOLA 9 Knihovna SimpleSmartCardAPI 65 Výhoda práce s rozhraním JavaCardApplet se projevuje zejména při vývoji aplikací komunikujích se složitějšími applety, které přijímají mnoho různých instrukcí. Pomocí rozhraní JavaCardApplet lze s takovými applety jednoduše komunikovat voláním metod, které vyžadují parametry skutečně potřebné pro daný typ APDU příkazu. Rozhraní JavaCardApplet má jednu konkrétní implementaci JavaCardAppletImpl Rozhraní JavaCardAppletManager Instance tříd implementujících rozhraní JavaCardApplet jsou vytvářeny prostřednictvím instancí tříd implementujících rozhraní JavaCardAppletManager. JavaCardAppletManager představuje abstrakci správce appletů. Může jít o reprezentaci správce appletů na kartě, či pouze o továrnu na nové instance tříd implementujících rozhraní JavaCardApplet. Knihovna obsahuje jednu konkrétní implementaci tohoto rozhraní třídu JavaCardAPDUAppletManager. Funkčnost instance třídy JavaCardAPDUAppletManager se odlišuje podle toho, jaký typ instance JavaCardAdapter je jí předán. Pokud se jedná o instanci třídy rozšiřující abstraktní třídu CardManagerAdapter, pak lze vykonávat i správu obsahu appletů na kartě (nahrávání, mazání). V opačném případě slouží instance třídy JavaCardAPDUAppletManager k vytváření instancí JavaCardApplet a jako jejich cache zajišťující, že nebude vytvořeno více instancí se stejným AID. Rozhraní JavaCardManager definuje metody pro správu Load souborů a instancí appletů na kartě, pro nahrávání appletů z.cap souborů a pro získávání seznamu Load souborů a instancí appletů na kartě. Tyto metody přistupují ke kartě skrze CardManagerAdapter a jeho metody. Pomocí rozhraní JavaCardManager lze tedy provádět kompletní správu obsahu Load souborů a instancí appletů na kartě s využitím všech třídy vyšší úrovně abstrakce, které knihovna SimpleSmartCardAPI nabízí (kupříkladu seznam instancí na kartě je vracen jako java.util.list obsahující elementy typu JavaCardApplet). Instance tříd rozhraní JavaCardManager mohou též udržovat seznam instancí tříd rozšiřujících rozhraní JavaCardAppletStateChangeListener tedy instancí, které mají zájem být informovány o změnách ve stavu nahraných Load souborů a vytvořených instancí appletů na kartě. Těmto instancím je při každém změně (nahrání Load souboru, smazání Load souboru, vytvoření instance appletu, odstranění instance appletu) předána instance třídy JavaCardAppletStateChangeEvent, která reprezentuje změnu, k níž v obsahu karty došlo. Tohoto mohou využívat například aplikace, které nějakým způsobem zobrazují seznam Load souborů či na kartě vytvořených instancí a pomocí naslouchání na změny obsahu karty aktualizovat dané zobrazované seznamy. 9.3 Příklady použití knihovny SimpleSmartCardAPI Připojení ke kartě Následující část kódu ilustruje vytvoření adaptéru pro komunikaci s kartou ve čtečce, která je v systému vedena jako první (index 0), a to pomocí jakéhokoliv dostupného protokolu komunikace (parametr '*').

80 66 KAPITOLA 9 Knihovna SimpleSmartCardAPI JavaCardConnection connection = JavaCardAPDUConnections.getCardConnection(); JavaCardAdapter adapter = connection.getjavacardapduadapter(0, "*"); Následující část kódu ilustruje vytvoření adaptéru pro komunikaci s kartou, kterou systém vyhledá jako první (index 0). JavaCardConnection connection = JavaCardAPDUConnections.getCardConnection(); List<JavaCard> cards = connection.getconnectedcards(); JavaCardAPDUImpl card = (JavaCardAPDUImpl)card.get(0); JavaCardAdapter adapter = card.getjavacardadapter(); Připojení k simulátoru Adaptér pro komunikaci se simulátorem lze vytvořit postupem, který uvádí následující příklad. Simulátor poslouchá na portu 9025, použit bude protokol APDU komunikace T=0. JavaCardConnection connection = JavaCardSimulatorConnections.getCardConnection(); JavaCardAdapter adapter = connection.getjavacardsimulatoradapter(9025, "T=0"); Zaslání APDU příkazu Zaslání APDU příkazu s poli CLA: 0x80, INS:0x20, P1: 0x00, P2:0x00, bez dat a očekávanou odpovědí v podobě 10 (0x0A) bytů. Příkaz je zaslán prostřednictvím dříve získaného adaptéru (bez ohledu na to, zda adaptér karty, či simulátoru). Pokud příkaz proběhne správně, je odpověď vypsána na standardní výstup. Pokud dojde k chybě, je na standardní výstup vypsán status word chyby. String sw = adapter.sendapdu("80", "20", "00", "00", null, "0A"); if (adapter.islastproceedok) { String response = adapter.getlastresponseasstring(); System.out.println(response); } else { System.out.println(sw); } Komunikace s appletem Následující příklad ilustruje vytvoření instance JavaCardApplet pro applet SimpleString popsaný v kapitole 8. Applet SimpleString má AID C900101, používá třídu instrukcí CLA 0x80 a tři instrukce: 0x10 pro zapsání dat, 0x20 pro načtení dat a 0x20 s parametrem 0x01 pro načtení délky uložených dat. Appletu bude zasláno 0x1234 na následně načteno.

81 KAPITOLA 9 Knihovna SimpleSmartCardAPI 67 JavaCardConnection connection = JavaCardAPDUConnections.getCardConnection(); JavaCardAdapter adapter = connection.getjavacardapduadapter(0, "*"); JavaCardAPDUAppletManager appletmanager = new JavaCardAPDUAppletManager(adapter); // získání instance appletu JavaCardApplet simplestring = appletmanager.getapplet(" c900101"); // nastavení tabulky instrukcí simplestring.getinstructiontable().put("read_string", "10"); // INS 0x10 simplestring.getinstructiontable().put("write_string", "20"); / INS /0x20 // nastavení výchozí hodnoty pole CLA APDU příkazů posílaných appletu simplestring.setpreferredcla("80"); // CLA 0x80 // výběr appletu na kartě simplestring.select(); // poslání dat appletu simplestring.invokecommandwithdata("write_string", "1234"); // získání délky dat uložených v appletu // P1: 0x01, P2: 0x00, Le: 0x01 byte[] length = simplestring.invokecommandandreceive("read_string", (byte)0x01, (byte)0x00, (byte)0x01); // získání dat uložených v appletu String data = simplestring.invokecommandandreceive("read_string", length[0]); Získání seznamu instancí appletů na kartě Následující příklad ilustruje získání seznamu vytvořených instancí appletů na kartě. Nejprve je získána instance CardManagerAdapter. Jemu jsou nastaveny klíče pro vzájemnou autentikaci, kterými dojde ke vzájemné autentikaci. Poté je již možné přistupovat ke Card manageru. JavaCardConnections connection = JavaCardAPDUConnections.getCardConnection(); // získání adaptéru pro Card manager specifikace Open Platform ('op201') CardManagerAdapter adapter = (CardManagerAdapter) connection.getconnectionadapter(0, "*", "op201"); JavaCardAPDUAppletManager appletmanager = new JavaCardAPDUAppletManager(adapter); // nastavení klíčů byte[] enc = Conversions.hexStringToByteArray(" fc01506e0aca4acc0a13a20"); byte[] mac = Conversions.hexStringToByteArray("1551fb cce2a016d15f5445e"); byte[] kek =

82 68 KAPITOLA 9 Knihovna SimpleSmartCardAPI Conversions.hexStringToByteArray("b81fdbb63e062ddff740f6d892733a04"); adapter.setauthenticationkeys(enc, mac, kek); // výběr Card manageru na kartě adapter.selectapplet("a d00"); // vzájemná autentikace na úroveň zabezpečení 1 adapter.authenticate(1); // získání seznamu instancí appletů na kartě List<JavaCardApplet> applets = appletmanager.getappletinstanceslist(); 9.4 Ukázky implementace V tomto oddílu je popsána implementace vybraných bezpečnostních mechanismů, které Open platform definuje, v knihovně SimpleSmartCardAPI. Jedná se o vzájemnou autentikaci a komunikaci zabezpečeným kanálem Vzájemná autentikace Vzájemná autentikace je provedena metodou authenticate definovanou ve třídě CardManagerAdapter. Metoda authenticate přijímá jako parametr úroveň zabezpečení zabezpečeného kanálu, který bude otevřen po úspěšné vzájemné autentikaci. Metoda authenticate nejprve zavolá metodu initializeupdate, v rámci níž je vygenerováno náhodné host challenge a odesláno na kartu příkazem INITIALIZE UPDATE. Karta vrací mj. card challenge a card kryptogram. Host challenge je generováno pomocí instance třídy SecureRandom, která je součástí balíčku java.security standardní platformy jazyku Java. Zdrojový kód metody initializeupdate: public Response initializeupdate(int keysetversion, int keyindex) throws... try { // generování náhodných data do pole hostchallenge SecureRandom.getInstance("SHA1PRNG").nextBytes(hostChallenge); } catch (NoSuchAlgorithmException ex) { } // odeslání příkazu INITIALIZE UPDATE kartě sendapdu((byte) 0x80, (byte) 0x50, (byte) keysetversion, (byte) keyindex, hostchallenge, (byte) 0x00); Response response = new Response(getLastResponse()); if (response.isok()) { System.arraycopy(response.getData(), 0, keydiversificationdata, 0, 10); System.arraycopy(response.getData(), 10, keyinformationdata, 0, 2); System.arraycopy(response.getData(), 12, cardchallenge, 0, 8); System.arraycopy(response.getData(), 20, cardcryptogram, 0, 8); } return response;

83 KAPITOLA 9 Knihovna SimpleSmartCardAPI 69 } V metodě authenticate jsou dále generovány session klíče pro vzájemnou autentikaci a zabezpečený kanál. Nejprve jsou sestavena derivační data pro generování session klíčů dle pravidel popsaných v oddílu A.4.1. Pole temp představuje pole s derivačními daty. System.arraycopy(cardChallenge, 4, temp, 0, 4); System.arraycopy(hostChallenge, 0, temp, 4, 4); System.arraycopy(cardChallenge, 0, temp, 8, 4); System.arraycopy(hostChallenge, 4, temp, 12, 4); Následně jsou derivační data zašifrována šifrou 3DES v režimu ECB s použitím statických klíčů (zde ENCx a MACx označují 24-bytové rozšíření 16-bytových statických klíčů a představuje tři klíče pro 3DES, přičemž k 1 = k 3 ). Využity jsou objekty rozšíření Java Cryptography Extension, které je součástí knihoven standardní platformy jazyka Java. // vytvoření instance šifry Cipher desecb = Cipher.getInstance("TripleDES/ECB/NoPadding"); // vytvoření instance klíče SecretKey staticenckey = new SecretKeySpec(ENCx, "DESede"); // incializace šifry klíčem do režimu šifrování desecb.init(cipher.encrypt_mode, staticenckey); // vlastní zašifrování pole temp, v němž se nacházejí derivační data // výsledek šifrování v poli sessionenc sessionenc = desecb.dofinal(temp); SecretKey staticmackey = new SecretKeySpec(MACx, "DESede"); desecb.init(cipher.encrypt_mode, staticmackey); sessionmac = desecb.dofinal(temp); V tomto okamžiku jsou metodou authenticate vygenerovány session klíče a metoda pokračuje ověřením card kryptogramu: // otevřený text sestavený na straně PC, z něhož bude vygenerován lokální card kryptogram určený k ověření karty byte[] cardauthenticationcryptogramplain = new byte[24]; System.arraycopy(hostChallenge, 0, cardauthenticationcryptogramplain, 0, 8); System.arraycopy(cardChallenge, 0, cardauthenticationcryptogramplain, 8, 8); byte[] DESPadding = { (byte) 0x80, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00 }; System.arraycopy(DESPadding, 0, cardauthenticationcryptogramplain, 16, 8); byte[] mac = new byte[8]; // generování MAC hodnoty, která je card kryptogramem // pole mac obsahuje MAC hodnotu CryptoServices.fullTripleDESMAC(sessionENC, cardauthenticationcryptogramplain, null, mac);

84 70 KAPITOLA 9 Knihovna SimpleSmartCardAPI if (!Arrays.equals(mac, cardcryptogram)) { throw new AdapterException("Can't match card cryptogram"); } Po ověření card kryptogramu metoda authenticate vygeneruje host kryptogram, který pomocí metody externalauthenticate zašle kartě příkazem EXTERNAL AUTHENTICATE. // otevřený text, z něhož bude generován host kryptogram byte[] hostauthenticationcryptogram = new byte[24]; System.arraycopy(cardChallenge, 0, hostauthenticationcryptogram, 0, 8); System.arraycopy(hostChallenge, 0, hostauthenticationcryptogram, 8, 8); System.arraycopy(DESPadding, 0, hostauthenticationcryptogram, 16, 8); // generování MAC hodnoty, která je host kryptogramem // pole mac obsahuje MAC hodnotu CryptoServices.fullTripleDESMAC(sessionENC, hostauthenticationcryptogram, null, mac); // předání dat metodě externalauthenticate, která skrze příkaz EXTERNAL AUTHENTICATE pošle host kryptogram na ověření kartě response = externalauthenticate(sessionmac, securitylevel, mac); // nevrací-li karta korektní status word, metoda authenticate vrací false if (!response.isok()) { return false; } Tímto je dokončen proces vzájemné autentikace Komunikace zabezpečeným kanálem Pokud je nastavena úroveň zabezpečení na úroveň vyšší než 0, je každý adaptérem odesílaný příkaz nejprve modifikován metodou securecommand. Metoda jako parametry přijímá APDU příkaz, session ENC a MAC klíč a inicializační vektor, který je použit pro kontrolu integrity posloupnosti zasílaných příkazů. Vrací APDU příkaz, který je zabezpečený podle nastavené úrovně zabezpečení. Komentovaný kód je vzhledem k délce vyčleněn do dodatku D Metody realizující kryptografické operace Výše uvedené metody využívají kryptografických operací, které jsou implementovány v metodách fulltripledes a fulltripledesmac třídy CryptoServices. Metoda fulltripledes realizuje šifrování šifrou 3DES v režimu CBC. Využívá objekty rozšíření Java Cryptography Extension, které je součástí knihoven standardní platformy jazyka Java. V parametru key metoda přijímá klíč, kterým bude realizováno šifrování, v parametru data

85 KAPITOLA 9 Knihovna SimpleSmartCardAPI 71 přijímá otevřený text,v parametru vector přijímá inicializační vektor pro šifrování a parametr encdata je pole, do něhož bude vložen šifrový text. public static void fulltripledes(byte[] key, byte[] data, byte[] vector, byte[] encdata) throws... { // není-li zadán inicializační vektor, jsou použity nuly if (vector == null) { vector = new byte[]{ (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00 }; } // objekt inicializačního vektoru IvParameterSpec iv = new IvParameterSpec(vector); // 3DES využívá tři klíče, které jsou mu zadány jako pole délky 24 bytů // zde je klíč k_1 shodný s k_3 byte[] extendedkey = new byte[24]; System.arraycopy(key, 0, extendedkey, 0, 16); System.arraycopy(key, 0, extendedkey, 16, 8); // získání objektu šifry Cipher cbc = Cipher.getInstance("TripleDES/CBC/NoPadding"); // vytvoření objektu klíče SecretKey secretkey = new SecretKeySpec(extendedKey, "DESede"); // inicializace šifry klíčem a módem šifrování cbc.init(cipher.encrypt_mode, secretkey, iv); // kopie zašifrovaných dat do výstupního parametru System.arraycopy(cbc.doFinal(data), 0, encdata, 0, encdata.length); } Metoda fulltripledesmac realizuje generování MAC hodnoty šifrou 3DES v režimu CBC. Využívá objekty rozšíření Java Cryptography Extension, které je součástí knihoven standardní platformy jazyka Java. V parametru key metoda přijímá klíč, kterým bude realizováno šifrování, v parametru data přijímá text, pro který bude generována MAC hodnota, v parametru vector přijímá inicializační vektor pro šifrování a parametr mac je pole, do něhož bude vložena hodnota MAC. public static void fulltripledesmac(byte[] key, byte[] data, byte[] vector, byte[] mac) throws... { // není-li zadán inicializační vektor, jsou použity nuly if (vector == null) { vector = new byte[]{ (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00 }; } // objekt inicializačního vektoru IvParameterSpec iv = new IvParameterSpec(vector); // 3DES využívá tři klíče, které jsou mu zadány jako pole délky 24 bytů // zde je klíč k_1 shodný s k_3 byte[] extendedkey = new byte[24];

86 72 KAPITOLA 9 Knihovna SimpleSmartCardAPI System.arraycopy(key, 0, extendedkey, 0, 16); System.arraycopy(key, 0, extendedkey, 16, 8); // získání objektu šifry Cipher cbc = Cipher.getInstance("TripleDES/CBC/NoPadding"); // vytvoření objektu klíče SecretKey secretkey = new SecretKeySpec(extendedKey, "DESede"); // inicializace šifry klíčem a módem šifrování cbc.init(cipher.encrypt_mode, secretkey, iv); // kopie posledního bloku zašifrovaných dat, který představuje MAC hodnotu, do výstupního parametru System.arraycopy(cbc.doFinal(data), data.length - 8, mac, 0, 8); } 9.5 Testování Při vývoji knihovny byla použita testovací třída obsahující metody testující základní funkčnost knihovny a několik JUnit testů (zejména na konverzní funkce). Testování určitých částí knihovny bylo však problematické z důvodu rozdílného chování podpůrných knihoven javax.smartcardio a APDUIO, kdy první jmenovaná některé chybové stavy karty reprezentuje výjimkami, zatímco druhá odpovědmi s chybovými kódy status word. Na vyšších úrovních abstrakce se toto chování podařilo sjednotit jednotným mechanismem výjimek. Testy probíhaly vždy vůči simulátoru či reálně kartě, jak se však ukázalo nejvhodnější by bylo nejprve implementovat virtuální kartu tedy objekt, který by přijímal APDU příkazy a definovaně na ně reagoval. Knihovna je použita v několika aplikacích, s nimiž již několikrát pracovali různí uživatelé. Zatím nebyl registrován zásadní problém, který by se týkal nekorektní funkčnosti. Známým problémem je souběžné spuštění několika aplikací komunikujících s kartou. Jednak zde vzniká nesynchronizace, kdy si obě aplikace berou kontext (jinými slovy vybírají na kartě každá svůj applet), dále při uzavření jedné aplikace, dojde k přeruší spojení s kartou, což přeruší i spojení pro aplikaci druhou. 9.6 Využití dalších zdrojů Pro vývoj knihovny SimpleSmartCardAPI byly využity open-source projekty Smartcard list [19] a ASAL [20]. Smartcard List je průběžně aktualizovaný seznam názvů čipových karet a hodnot ATR (answer-to-reset), které karta po vložení pošle terminálu. Protože ATR hodnota bývá, není-li dodatečně změněna, shodná pro jednotlivé typy karet, lze ji využít pro identifikaci výrobce a typu karty. SimpleSmartCardAPI tohoto seznamu využívá ve třídě JavaCardImpl, kde lze pomocí metod getdescription a getshortdescription získat informace o vložené kartě. Během vývoje a testování knihovny byla knihovna testována s několika typy karet GemXpresso, které seznam neobsahoval. Hodnoty ATR těchto karet spolu s označením typu byly zaslány autorovi seznamu pro doplnění seznamu a zahrnuty do nové verze seznamu.

87 KAPITOLA 9 Knihovna SimpleSmartCardAPI 73 ASAL (Advanced Smartcard Access Library) je rozpracovaná knihovna, jejímž záměrem je poskytnout možnost přístupu z programového kódu na čipové karty různých platforem. Se souhlasem autora byly z knihovny ASAL využity partie kódu týkající se konverzí a některých funkcí přístupu ke Card manageru specifikace Open platform. Vzhledem k tomu, že šlo ve většině případů o partie funkcí, které nebyly v knihovně ASAL dokončené, a dále vzhledem k tomu, že mnoho důležitých funkcí (např. zabezpečený kanál či nahrávání bloků.cap souboru na kartu) v knihovně ASAL zcela chybělo, byl autorovi po dokončení knihovny SimpleSmartCardAPI zaslán zdrojový kód knihovny SimpleSmartCardAPI pro možnost dalšího rozvoje i této knihovny.

88 74 KAPITOLA 9 Knihovna SimpleSmartCardAPI

89 KAPITOLA 10 Vývoj NetBeans plug-inů Vývoj NetBeans plug-inů Má-li být do výuky zahrnuta práce s Java kartami, je nutné mít k dispozici nástroje, jimiž bude probíhat správa appletů nahraných na kartu a případně nástroj podporující vývoj appletů pro Java Card platformu (tedy bude nabízet šablony zdrojového kódu appletů, možnosti kompilace, konverze atp.). Tato kapitola popisuje vývoj plug-inů pro vývojové prostředí NetBeans, které požadované funkce podporují. Mezi existujícími nástroji není příliš velký výběr. K dispozici jsou samozřejmě nástroje od výrobců karet. Za ty je však nutné zaplatit poplatky a zpravidla jsou tyto nástroje limitované pouze pro karty daného výrobce, což znamená nepraktickou volbu pro případ, kdy by v budoucnu došlo k zakoupení karet od jiného výrobce. Často jde též o aplikace zbytečně mohutné, snažící se postihnout několik aspektů najednou (např. obsahovat i vývojové prostředí), přičemž na některé jejich zahrnuté funkce je vhodnější ať už z hlediska funkčnosti, tak zvyku uživatelů, použít specializované či běžně používané nástroje (např. běžně používané vývojové prostředí). Z freeware aplikací lze volit mezi nástrojem příkazové řádky GPShell [16] a nástrojem v podobě plug-inu (rozšíření) do vývojového prostředí Eclipse JCOP tools. GPShell je nástroj, který je konfigurován vlastním skriptovacím jazykem, a umožňuje na kartě ovládat Card manager odpovídající specifikaci Global platform. Pomocí nástroje GPShell lze tedy například na kartu nahrávat applety či je z karty mazat. Charakter nástroje GPShell však vyžaduje editaci konfiguračních souborů (či jejich generování pomocí nějakého k tomu vytvořeného nástroje). GPShell však nenabízí žádnou podporu, co se týká kompilace appletů a jejich konverze. JCOP tools tuto podporu nabízejí, stejně tak jako možnost spravovat obsah karty. Nevýhodou však je, že se jedná o plug-in pro vývojové prostředí Eclipse, zatímco v počítačových učebnách je podporováno zejména vývojové prostředí NetBeans. Velmi sporným bodem je též dostupnost těchto nástrojů, nutnost nástroj jednotlivě aktivovat aktivačním klíčem od výrobce a reference týkající se nekompatibility s některými kartami typu GemXpresso. Z tohoto důvodu bylo rozhodnuto vytvořit nové nástroje určené ke správě obsahu appletů na kartě a podpoře vývoje appletů, které by byly vhodné zejména pro uživatele, kteří se s platformou Java Card setkávají poprvé a pro potřeby cvičení. Tyto nástroje jsou vytvořeny jako plug-iny (rozšíření) pro vývojové prostředí NetBeans podporované v počítačových učebnách. Důvody pro volbu NetBeans jsou následující: Vývojové prostředí NetBeans nabízí širokou škálu API, která lze využít pro tvorbu uživatelského rozhraní, ukládání aplikačních nastavení a životního cyklu aplikace. Vývojové prostředí NetBeans je psané v jazyku Java, lze tedy využívat funkce knihovny SimpleSmartCardAPI. Nástroje pro správu obsahu appletů na kartě a podporu vývoje appletů jsou přítomné přímo ve vývojovém prostředí, v němž jsou applety vyvíjeny. Veškeré funkce jsou tedy přítomné v jednom spuštěném programu. Byl vytvořen plug-in Java Card Manager určený pro správu obsahu karty a komunikaci s applety na kartě a plug-in Java Card Project, který přináší do vývojového prostředí NetBeans typ projektu určený pro vývoj Java Card appletů (šablona zdrojového kódu appletu,

90 76 KAPITOLA 10 Vývoj NetBeans plug-inů podpora konverze appletů a spouštění simulátoru z NetBeans). Plug-in Java Card Manager byl zaslaný na review zdrojového kódu firmě Sun Microsystems (která stojí za vývojem NetBeans) a došlo k jeho schválení. Tudíž splňuje požadavky korektního používání NetBeans API a lze ho tedy využívat jako oficiálně schválený plug-in pro NetBeans Tvorba plug-inů pro vývojové prostředí NetBeans Vývojové prostředí NetBeans je open-source projekt, jehož vývoj krátce po jeho vzniku převzala firma Sun Microsystems. Podle vlastních slov autorů projektu NetBeans, není NetBeans od začátku míněno čistě jako vývojové prostředí, ale jako platforma pro vývoj tzv. rich client aplikací desktopových aplikací nabízejích definované standardy uživatelského rozhraní a funkcionality aplikace. V případě NetBeans platformy to znamená například připravený systém menu a akcí, různé pohledy na hierarchické seznamy, možnost manipulovat s komponentami v hlavním okně, integrace nápovědy, poskytnutí možností perzistence uživatelských nastavení, podpora pro dialogová okna různých typů, podpora lokalizací aplikace, správa aktualizací aplikace atd. Platforma NetBeans je založena na systému modulů, kde každý modul poskytuje specializovanou funkčnost, k níž je přistupováno prostřednictvím API. Moduly deklarují vzájemné závislosti. Oddělení API od implementace umožňuje vytvářet závislosti modulů pouze na neměnném API, zatímco implementace se mohou lišit. Jako moduly jsou naprogramovány veškeré komponenty vývojového prostředí NetBeans. Pro vývoj rich client aplikace tedy stačí odstranit používání modulů, které nejsou pro danou aplikaci potřebné (např. aplikace pro prohlížení obrázků nevyužívá podporu pro kontrolu zdrojového kódu jazyka Java nebo okna editorů, může však využívat podporu pro načítání souborů a vizuální komponenty typu strom pro zobrazení např. adresářů s obrázky). Tímto způsobem lze tedy z vývojového prostředí postaveným na platformě NetBeans postupně odstraňovat funkčnost tak, aby představovala společný jmenovatel s funkčností nové aplikace. Naopak touto cestou ale také lze do vývojového prostředí formou dalších modulů funkčnost přidávat. Důležitý konceptem vývoje modulů pro NetBeans je, že využívá tzv. Systémový filesystém (systém filesystem). Ten představuje centrální úložiště pro konfigurační data NetBeans platformy. Každý modul má možnost (resp. pro začlenění své funkčnosti do NetBeans musí) v systémovém filesystému vytvořit vlastní složky, v nichž definuje zaintegrování částí modulu do infrastruktury NetBeans. Systémový filesystém například definuje složky typu 'Menu' či 'Actions' a přidáním dalších složek do nich lze do systému NetBeans přidávat nové položky menu a uživatelské akce. Systémový filesystém je založen na xml souborech, které definuje každý modul jako soubor layer.xml. Tyto soubory definují, na jaké místo filesystému vkládají moduly nové položky. Sloučením těchto souborů od všech přidaných modulů do NetBeans vznikne daný systémový filesystém. Konceptem spojeným s modulární architekturou NetBeans je využití vzoru Lookup. Lookup představuje mechanismus, jakým lze pro zadanou třídu či rozhraní najít instanci, která přísluší dané třídě či rozhraní. Lookup si lze hrubě představit jako speciální kolekci obsahující instance. V této kolekci lze vyhledávat podle třídy či rozhraní, kdy kolekce vrací příslušné instance. Tento koncept umožňuje jednak programové závislosti na API reprezentovanými

91 KAPITOLA 10 Vývoj NetBeans plug-inů 77 rozhraními bez ohledu na typu implementace. Modulu tedy stačí, aby při požadování funkčnosti po jiném modulu specifikoval pouze rozhraní dané funkčnosti a je mu pomocí Lookupu vrácena nějaká instance, která dané rozhraní splňuje. Lookup umožňuje též instanci dané třídy poskytovat měnitelnou funkčnost či separovat jedno rozhraní od druhého. Toto si lze představit např. na jedné položce hierarchie objektů typu Node. Ta zpravidla reprezentuje nějaký objekt soubor, otevřený projekt, připojení k databázi, nebo například applet na kartě. To znamená, že instance Node musí nějakým způsobem vracet (např. při požadavku vykonat nějakou operaci objektu, jehož položka, která ho reprezentuje, je vybrána) objekt, který reprezentuje, či například stav daného objektu. Tohoto je docíleno tím, že každá Node má svůj Lookup, do něhož má možnost přidávat objekty. Dotazy na danou Node jsou pak vedeny na její Lookup a v něm vyhledány příslušné instance. Některé objekty umožňují obsah Lookupu měnit dynamicky, takže např. okno s textem, jehož obsah se změnil a nebyl uložen, může v Lookupu obsahovat instanci objektu, který dokáže text uložit, zatímco pokud dokument změněn nebyl, Lookup okna tento objekt neobsahuje. Pro bližší informace o architektuře NetBeans platformy viz. [21], [22] a API dokumentaci platformy [23] Java Card Manager plug-in Funkce Java Card manager plug-inu Java Card Manager plug-in je rozšíření vývojového prostředí NetBeans, které poskytuje následující funkce: Zobrazení karet připojených k PC. Možnost zasílat vybrané kartě APDU příkazy prostřednictvím komponenty APDU manažer. Možnost vybrat na vybrané kartě příkazem SELECT applet zadaným AID. Možnost připojit se k zapnutému simulátoru JCWDE, posílat mu APDU příkazy prostřednictvím komponenty APDU manažer. Zobrazení APDU komunikace mezi kartou či simulátorem a PC. Otevření zabezpečeného kanálu mezi PC a appletem na kartě (se zdůrazněním otevření zabezpečeného kanálu ke Card manageru). Zobrazení nahraných Load souborů a instancí appletů na kartě formou stromového zobrazení typické pro zobrazování hierarchie souborů a adresářů v souborovém systému. Možnost odstranit zvolenou instanci appletu a vymazat zvolený Load soubor. Možnost vytvořit instanci zvoleného Load souboru. Možnost nahrát.cap soubor na kartu. Možnost nahrát.cap soubor na kartu a v jednom kroku vytvořit jeho instanci. Těmito funkcemi plug-in pokrývá všechny procedury, které je nutné během výuky vykonávat při správě obsahu appletů na kartě. Ovládací rozhraní plug-inu je pro uživatele seznámeného se základy Java Card platformy a systémem správy appletů na kartě intuitivní. Mnohá

92 78 KAPITOLA 10 Vývoj NetBeans plug-inů nastavení obsahují předdefinované hodnoty či ukládají naposledy zadané hodnoty. Kupříkladu při nahrávání úloh pro cvičení není při celém procesu nutné vyplňovat jakékoliv dodatečné parametry, protože většina je předdefinovaná jako výchozí a další je možné získat např. analýzou.cap souboru Návrh a implementace Java Card Manager plug-inu Seznam karet připojených k PC byl umístěn na záložku 'Services' (dříve 'Runtime'), která ve vývojovém prostředí NetBeans obsahuje služby, které lze odtud spouštět či používat. Jsou se zařazené spuštěné webové servery, databázové servery, webové služby či aplikační servery. Vzhledem k tomu, že připojená Java karta konceptuálně představuje také službu, je zařazení seznamu připojených karet zvoleno právě do této záložky. Přiřazení další větve do stromové hierarchie záložky 'Services' je zajištěno rozšířením systémového filesystému ve složce UI a její podsložce Runtime. Tam je přidána instance třídy JavaCardRootNode, která představuje kořenovou položku seznamu připojených karet. Tímto přidáním a zároveň vytvořením instance kořenové položky seznamu připojených karet je vlastně spuštěn celý plug-in. Z jiného místa v rámci vývojového prostředí NetBeans k plug-inu nevede žádná reference. Úprava systémového filesystému je provedena v souboru layer.xml modulu plug-inu. <folder name="ui"> <folder name="runtime"> <file name="org-netbeans-modules-javacardmanager- JavaCardRootNode.instance"> <attr name="position" intvalue="800"/> </file> </folder> </folder> Plug-in výrazně využívá API NetBeans balíčku org.openide.nodes, který poskytuje třídy a nástroje pro práci s elementy hierarchických struktur, jakož je z velké části založen na práci se stromovým zobrazením obsahu karty. Všechny funkce, které se týkají komunikace s kartou a simulátorem, jsou zajištěny knihovnou SimpleSmartCardAPI. Ta, aby mohla být využita v rámci plug-inu, musí být též do systému přidána jako modul tzv. library wrapper modul, který pouze obaluje binární distribuci knihovny. Modul Java Card Manager na tento knihovní modul deklaruje závislost, tudíž může využívat jeho API. Ilustrace 14: Seznam připojených karet v plug-inu Java Card manager

93 KAPITOLA 10 Vývoj NetBeans plug-inů 79 Modul plug-inu je rozdělen do následujících balíčků: org.netbeans.modules.javacardmanager Tento balíček obsahuje základní třídy a rozhraní použité pro fungování plug-inu. org.netbeans.modules.javacardmanager.actions V tomto balíčku jsou zahrnuty všechny třídy uživatelských akcí, které jsou v plug-inu použité (např. nahrání appletu, smazání Load souboru atd.) org.netbeans.modules.javacardmanager.nodes Balíček obsahující třídy všech typů elementů stromové struktury (element pro jednu vloženou kartu, simulátor, složku instancí, složku Load soubor, jednu instanci a jeden Load soubor). org.netbeans.modules.javacardmanager.resources V tomto balíčku jsou uloženy obrázky všech použitých ikon. org.netbeans.modules.javacardmanager.ui Tento balíček obsahuje všechny dialogy, které plug-iny zobrazuje, komponentu APDU manažeru a podpůrné komponenty uživatelského rozhraní použité v plug-inu. Instance třídy JavaCardRootNode, tedy kořenového elementu seznamu připojených karet, využívá instance vnitřně definované podtřídy třídy ChildFactory, která je zodpovědná za tvorbu potomků elementu, což je v rámci stromového zobrazení reprezentováno podvětvemi daného elementu. Metodě createkeys, kterou definuje třída ChildFactory, přidává do jí předaného seznamu, seznam tzv. klíčů tedy objektů, které budou obsaženy v seznamu, resp. pro které budou vytvořeny elementy seznamu typu JavaCardNode metodou createnodeforkey (pro simulátor je vytvořen element typu SimulatorNode). Metodě createkeys je předán seznam karet (instancí třídy JavaCard) připojených k PC, získaný metodou getconnectedcards třídy JavaCardConnections knihovny SimpleSmartCardAPI. Do seznamu je též vždy přidán simulátor, pro nějž je vytvořena větev, která je v seznamu připojených karet vždy přítomna a představuje místo, z něhož se lze připojit ke spuštěnému simulátoru. Podtřída třídy ChildFactory je zároveň posluchačem událostí Java karty (tj. implementuje rozhraní JavaCardListener), díky čemuž dochází k aktualizaci zobrazení při vložení či vyjmutí karty ze čtečky. Elementy reprezentující jednotlivé připojené karty jsou instance třídy JavaCardNode a v případě simulátoru SimulatorNode. Instance třídy JavaCardNode vkládají do svého Lookupu instanci třídy JavaCardController. Instance JavaCardController pro každou připojenou kartu reprezentují stav dané karty a služby, které nabízí poskytuje instanci třídy JavaCardAdapter pro každou kartu nebo umožňuje zjistit, zda je ke kartě navázané připojení zabezpečeným kanálem. Instance třídy JavaCardController je posluchačem APDU událostí své karty (tj. implementuje rozhraní APDUListener) a zároveň se mohou instanci třídy JavaCardController registrovat instance, které chtějí být informovány o změnách stavu karty (instance tříd implementujících ChangeListener). Změny týkající se APDU komunikace jsou předány instanci třídy APDUOutputService, která komunikuje se službami NetBeans vypisující informace do textové výstupní komponenty NetBeans.

94 80 KAPITOLA 10 Vývoj NetBeans plug-inů Ilustrace 15: Výpis obsahu karty v pluginu Java Card manager Instance třídy JavaCardNode předávají metodou getactions systému NetBeans akce, které je pro element možné vyvolat v menu. V tomto případě se jedná o akce připojení a odpojení od zabezpečeného kanálu, akci výběru appletu na kartě a akci otevření komponenty APDU manažeru. Akce jsou instance podtříd třídy NodeAction a je jim předána instance Node, která v případě vyvolání akce, danou akci vyvolala. Akce tedy může získáním instance třídy JavaCardController z Lookupu instance Node získat přístup ke kartě (resp. k adaptéru karty) a provést požadovanou operaci. Stejným způsobem může akce požádat instanci třídy JavaCardController o stav připojení ke kartě a zobrazit se v menu elementu například jako neaktivní v případě, že je karta ve stavu, kdy danou akci není možné provést. Tohoto modelu akcí jednotlivých elementů a mechanismu, jakým akce přistupují k instancím, které dané položky reprezentují, je využito i ve všech dalších případech typů elementů. Instance třídy JavaCardNode využívá instance vnitřní třídy, která je podtřídou třídy ChildFactory zodpovědné za tvorbu potomků elementu. V případě, že je vytvořen zabezpečený kanál mezi pc a kartou, metoda createkeys vytvoří podvětve 'Load files' (instance třídy LoadFilesNode) a 'Applet Instances' (instance třídy AppletInstancesNode), které dále obsahují jednotlivé elementy Load souborů a instancí appletů. Vnitřní třída implementuje rozhraní ChangeListener a její instance se registruje u instance třídy JavaCardController dané karty, čímž je informována o změnách ve stavu připojení karty. Pokud dojde k otevření zabezpečeného kanálu, je vnitřní třída o tomto informována a vytvoří zmiňované podvětve, či je naopak v případě zavření zabezpečeného kanálu odstraní. Instance tříd LoadFilesNode a AppletInstancesNode, které reprezentují složky pro Load soubory či instance appletů, pracují na podobném principu jako JavaCardNode a který vychází z použití API balíčku org.openide.node. Obě instance opět vytvářejí instanci vnitřní třídy, která je podtřídou třídy ChildFactory. Tato instance jednak pomocí metod rozhraní JavaCardAppletManager získá metodami getloadedapplets či getappletinstances daný obsah na kartě a vytvoří pro něj elementy v rámci dané složky (buď instance třídy LoadFileNode, nebo instance třídy AppletInstanceNode). Zároveň je tato instance posluchačem změn ve stavu appletů (implementuje rozhraní JavaCardAppletStateChangeListener) a v případě, že dojde ke změně obsahu appletů na kartě, příslušně upraví zobrazený obsah. Instance tříd LoadFilesNode, AppletInstancesNode, LoadFileNode a AppletInstaceNode reprezentující postupně elementy složky Load souborů, složky

95 KAPITOLA 10 Vývoj NetBeans plug-inů 81 instancí appletů, Load souboru a instance appletu elementům mají přiřazeny akce, které lze vykonávat. U instance třídy LoadFilesNode jde o akce nahrání.cap souboru na kartu. V případě instance třídy AppletInstancesNode jde o nahrání.cap souboru na kartu a vytvoření instance appletu. Instance třídy LoaFileNode má přiřazeny akce smazání Load souboru a vytvoření instance appletu z vybraného Load souboru. Instance třídy AppletInstanceNode má přiřazeny akce odstranění instance, výběr instance na kartě příkazem SELECT a otevření APDU manažeru. Komponenta APDU manažeru je instancí třídy APDUManagerTopComponent rozšiřující třídu TopComponent, kterou definuje NetBeans API. Jedná se o vizuální komponentu systému NetBeans, s níž lze v rámci systému manipulovat měnit její velikost či ji přesunovat na jiná umístění v rámci hlavního okna NetBeans. Komponenta obsahuje textová pole odpovídající polím APDU příkazu, do nichž lze vepsat hodnotu, která bude použita při odeslání APDU příkazu na kartu. Komponentu APDU manažeru lze otevřít z menu elementů simulátoru (je-li připojen), připojené karty a instancí appletů. Komponenta APDU manažeru může zůstat otevřená, přičemž pokud dojde v seznamu karet k výběru jiné karty, lze prostřednictvím dříve otevřené komponenty APDU manažeru komunikovat rovnou s touto kartou. Tohoto chování je dosaženo tím, že instance třídy APDUManagerTopComponent získá referenci na instanci třídy ExplorerManager, která spravuje obsah seznamu zobrazený v záložce 'Services'. Následně instance třídy APDUManagerTopComponent vytvoří instanci PropertyChangeListener, kterou zaregistruje instanci ExplorerManageru. Tímto je instance třídy APDUManagerTopComponent informována o změnách výběru v seznamu na záložce 'Services'. Následně instance třídy APDUManagerTopComponent testuje, zda se v Lookupu vybraného elementu v záložce 'Services' vyskytuje instance třídy AdapterProvider. Přítomnost instance této třídy v Lookupu elementu indikuje, že daný element může zpracovávat APDU příkazy (jinými slovy umí vrátit adaptér pro komunikaci s kartou ) a je pro něj z Lookupu získána instance třídy JavaCardController, prostřednictvím něhož APDU manažer získá adaptér ke komunikaci s kartou či simulátorem. Pokud se v Lookupu vybraného elementu instance třídy AdapterProvider nevyskytuje, pak se komponenta APDU manažeru zneaktivní. Ilustrace 16: Kompomenta APDU manager plug-inu Java Card manager

96 82 KAPITOLA 10 Vývoj NetBeans plug-inů Popsané chování je ve zdrojovém kódu implementováno takto: // tato metoda je volána při otevření komponenty v systému NetBeans public void componentopened() { // získání reference na komponentu reprezentující záložku 'Services' TopComponent runtime = WindowManager.getDefault().findTopComponent("runtime"); // získání reference na její ExplorerManager explorermanager = ((ExplorerManager.Provider) runtime).getexplorermanager(); refreshstate(); // vytvoření posluchače změn explorermanageru PropertyChangeListener l = new PropertyChangeListener() { public void propertychange(propertychangeevent evt) { } // změna označuje výběr elementů v seznamu if (evt.getsource() == explorermanager && ExplorerManager.PROP_SELECTED_NODES.equals(evt.getPropertyName())) { refreshstate(); } } }; explorermanager.addpropertychangelistener(l); // metoda zjišťuje, zda jsou vybrané elementy schopné APDU komunikace a mění stav komponenty public void refreshstate() { // získání vybraných elementů Node[] nodes = explorermanager.getselectednodes(); AdapterProvider ap = null; } // jsou-li nějaké vybrané, získej od prvního jeho lookup a z něj //instanci AdapterProvider if (nodes.length > 0) { ap = nodes[0].getlookup().lookup(adapterprovider.class); } // v lookupu byla nalezena instance AdapterProvider if (ap!= null) { // získej z lookupu instanci JavaCardController controller = nodes[0].getlookup().lookup(javacardcontroller.class); // nastav komponentu jako aktivní enablecomponent(true); } // v lookupu nebyla nalezena instance AdapterProvider else { // uvolni referenci na předchozí používanou instanci //JavaCardController controller = null; // nastavi komponentu jako neaktivní enablecomponent(false); } updatetitle();

97 KAPITOLA 10 Vývoj NetBeans plug-inů 83 Z uvedeného plyne, že instance elementů reprezentujících Java kartu (instance třídy JavaCardNode), instance appletu (instance třídy AppletInstanceNode) a simulátor (instance třídy JavaCardSimulatorNode) musí do svého Lookupu vložit instance tříd AdapterProvider a JavaCardController. Instance třídy JavaCardNode a AppletInstance toto dělají. Navíc, veškeré instance podvětví elementu reprezentujícího připojenou Java kartu si předávají instanci třídy JavaCardController a vkládají ji do svého Lookupu (např. i instance třídy LoadFilesNode reprezentující složku Load souborů musí mít přístup k instanci JavaCardController a přes ní k adaptéru, aby mohla poslat na kartu požadavek o vrácení seznamu nahraných Load souborů). U instance třídy JavaCardSimulatorNode reprezentující element simulátoru je však situace odlišná. U instancí reprezentujících element připojené karty či instance appletu bylo jasné, že pakliže jsou vytvořené, je to pouze tehdy, kdy je karta vložena do čtečky a je smysluplný požadavek s ní komunikovat. Element reprezentující simulátor však představuje pouze přístupový bod a má dva stavy první, kdy je nepřipojený k simulátoru, a druhý, kdy je k simulátoru připojený. Podle těchto stavů by měla příslušně reagovat i komponenta APDU manažeru a být neaktivní tehdy, pokud neexistuje připojení k simulátoru, a naopak. Vlivem výše zmíněného mechanismu, kdy se komponenta APDU manažeru stává aktivní, či neaktivní podle přítomnosti instance třídy AdapterProvider v Lookupu vybraného elementu, toto znamená, že je nutné dynamicky měnit obsah Lookupu instance třídy JavaCardSimulatorNode podle toho, zda je instance ve stavu připojeném k simulátoru (přidat do Lookupu instanci třídy AdapterProvider), či ne (odstranit z Lookupu instanci třídy AdapterProvider). Tohoto lze docílit tím, že se instance třídy JavaCardSimulatorNode stane posluchačem změn (implementuje rozhraní ChangeListener) své instance třídy JavaCardController. Tímto je informována o změnách v připojení ke kartě, resp. simulátoru. Následně ze svého Lookupu podle stavu instance třídy JavaCardController (zda je po změně stavu v připojeném stavu, či odpojeném) přidat či odstranit ze svého Lookupu instanci třídy AdapterProvider. Měnit obsah svého Lookupu může instance JavaCardSimulatorNode pomocí získání tzv. cookie setu, což je množina objektů tříd impementujících rozhraní Node.Cookie, do níž lze přidávat instance, či z ní instance odebírat. Obsah cookie setu je v případě, kdy nebyl zadán žádný Lookup v konstruktoru, vracen jako Lookup instance. Mechanismus cookie objektů v NetBeans předcházel mechanismu Lookup. Jedná se o principiálně srovnatelné mechanismy, které se přechodem na využívání Lookupu nyní takto prolínají. Metody zajišťující dynamickou změnu obsahu Lookupu instance třídy JavaCardSimulatorNode na základě změn v instanci třídy JavaCardController. // voláno na základě změn ohlášených instancí třídy JavaCardController public void statechanged(changeevent e) { if (controller.isconnected()) { getcookieset().add(adapterprovider); } else { getcookieset().remove(adapterprovider); } }

98 84 KAPITOLA 10 Vývoj NetBeans plug-inů Postup instalace plug-inu Java Card Manager a návod k němu je uvedený v dodatku E. Dokumentace k plug-inu Java Card Manager je uvedena na CD v adresáři nb_pluginy\javacardmanagersuite\javacardmanager\doc. Zdrojové kódy plug-inu Java Card Manager se nacházejí na CD v adresáři nb_pluginy\javacardmanagersuite\javacardmanager\src. Plug-in vyžaduje k nainstalování NetBeans minimálně verze 6.0 a Java Runtime Environment nejméně verze 1.6 (nutné k běhu knihovny SimpleSmartCardAPI, kterou plug-in využívá). Dále přítomnost modulu SimpleSmartCardAPI Java Card Project plug-in Návrh a implementace Java Card Project plug-inu Plug-in Java Card Project přináší do NetBeans možnost vytvořit projekt pro vývoj appletu pro Java kartu. To znamená, že jsou při editaci zdrojového kódu appletu podporovány třídy a rozhraní definovaná v základních knihovnách platformy Java Card (což při editaci zdrojového kódu appletu např. přináší i možnosti doplňování kódu a automatických importů). Dále je podporovaná kompilace zdrojových kódů appletu tak, aby zkompilované soubory mohly být konvertované na.cap soubory nástrojem Converter. Podporováno je spuštění konverze přeložených souborů z NetBeans a spuštění simulátoru JCWDE z NetBeans. Tento plug-in neimplementuje nový typ projektu, ovšem namísto toho představuje rozšíření typu projektu určeného pro standardní platformu jazyka Java (J2SEProject). Lze tedy využít již existující implementace a doplnit ji o funkčnost příslušnou vývoji appletů pro Java karty. Přidání položek do seznamu typů projektů při vytváření nového projektu v NetBeans lze provést úpravou systémového filesystému. Do systémového filesystému je ve složkách 'Templates' a v ní ve složce 'Project' přidána složka 'JavaCard' a do ní šablona projektu, která po vytvoření projektu bude otevřena v editoru a obsahuje základní kostru appletu pro Java kartu. Vytvoření projektu probíhá v dialogu typu průvodce. Jeho otevření je specifikováno jako atribut souboru šablony vytvoření instance třídy JavaCardProjectWizardIterator. Úprava systémového filesystému je provedena v souboru layer.xml modulu plug-inu. <folder name="templates"> <folder name="project"> <folder name="javacard">... <file name="javacardapplet.xml">... <attr name="instantiatingiterator" newvalue="org. netbeans.modules.javacardproject. templates.javacardprojectwizarditerator"/> </file> </folder> </folder> </folder>

99 KAPITOLA 10 Vývoj NetBeans plug-inů 85 Ilustrace 17: Java Card projekt typ v NetBeans Modul plug-inu je rozdělen do následujících balíčků: org.netbeans.modules.javacardproject Tento balíček obsahuje základní třídy pro fungování plug-inu. org.netbeans.modules.javacardproject.actions V tomto balíčku jsou třídy uživatelských akcí, které jsou v plug-inu použité. org.netbeans.modules.javacardproject.resources Tento balíček obsahuje soubory, které jsou použité v průvodci vytvoření nového projektu a při vytváření nového projektu. org.netbeans.modules.javacardproject.templates Tento balíček obsahuje třídy panelů průvodce vytváření nového projektu. org.netbeans.modules.javacardproject.ui V tomto balíčku jsou třídy dialogů uživatelského rozhraní. org.netbeans.modules.javacardproject.ui.resources V tomto balíčku se nacházejí ikony použité v dialozích uživatelského rozhraní. Průvodce vytvořením Java Card projektu je implementován třídami JavaCardProjectWizardIterator, ConfigureProjectPanel, ConfigureProjectPanelView, JavaCardKitPathsPanel a JavaCardKitPathsPanelView. Třída JavaCardProjectWizardIterator implementuje rozhraní WizardDescritor.InstantiatingIterator definované platformou NetBeans. To znamená, že tato třída představuje iterátor průchodu po panelech dialogu typu průvodce a po ukončení dojde k vytvoření instance projektu. Rozhraní WizardDescritor.InstantiatingIterator definuje metody určené pro přechod mezi jednotlivými panely průvodce. Jednotlivé panely průvodce jsou reprezentovány třídami ConfigureProjectPanel (nastavení obecných vlastností projektu) a JavaCardKitPathsPanel (nastavení cest k Java Card Development Kitu). Ty implementují rozhraní WizardDescriptor.Panel a obsahují implementaci logiky kontroly

100 86 KAPITOLA 10 Vývoj NetBeans plug-inů zadávaných informací a jejich ukládání či načítání při přechodech mezi panely průvodce. Instance třídy ConfigureProjectPanel představuje panel pro zadávání názvu projektu, názvu appletu a jeho package a AID appletu a package, které bude použité při konverzi. Instance třídy JavaCardKitPathsPanel představuje panel pro zadávání cest k Java Card Development kitu. Obě třídy obsahují aplikační logiku daných panelů a jako view komponentu panelu vracejí instance tříd ConfigureProjectPanelView či JavaCardKitPathsPanelView. Blíže o vytváření a mechanice dialogů typu průvodce viz [24]. Po potvrzení voleb a stisknutí tlačítka pro dokončení průvodce je volána metoda instantiate třídy JavaCardProjectWizardIterator a v rámci ní je s parametry zadanými v panelech průvodce vytvořen nový projekt ze šablony, kterou modul plug-inu obsahuje. Vytvoření nového projektu ze šablony zajišťuje metoda createprojectfromtemplate třídy JavaCardProjectGenerator. Jí je v parametrech předán objekt reprezentující šablonu projektu, cesta k adresáři, do něhož bude projekt vygenerován, názvy a texty v rámci šablony, které budou nahrazeny názvy zadanými v panelech průvodce (jedná se o název třídy appletu a tedy i název konstruktoru a název package appletu) a vlastnosti specifické pro Java Card projekt, kterými jsou cesty ke knihovnám a nástrojům Java Card Development Kitu specifikované v panelech průvodce vytvořením projektu. Metoda createprojectfromtemplate zkopíruje šablonu z archivu do daného umístění a nahradí v ní názvy ze šablony tak, aby odpovídaly názvům zadaných v průvodci vytvořením projektu. Následně upraví vlastnosti projektu (soubor project.properties) o cesty ke knihovnám a nástrojům Java Card Development Kitu specifikované v panelech průvodce vytvořením projektu. Pro úpravu ukládaných vlastností projektu je nejprve nutné získat instanci reprezentující projekt. Referenci lze získat metodou findproject třídy Project, která pro zadaný adresář vrací projekt, který je v tomto adresáři uložen. Protože Java Card typ projektu rozšiřuje typ projektu standardní platformy Javy [25], kde jsou projekty založené na využívání nástroje Ant, lze na získané referenci po přetypování na J2SEProject zavolat metodu getantprojecthelper, která pro daný projekt vrací instanci třídy AntProjectHelper, která nabízí metody pro podporu práce s projekty založené na nástroji Ant. Na vrácené instanci třídy AntProjectHelper lze zavolat metodu getproperties a předat ji relativní cestu k souboru vlastností, využít však lze proměnnou AntProjectHelper. PROJECT_PROPERTIES_PATH. Tato metoda vrací instanci třídy EditableProperties, což je třída rozšiřují abstraktní třídu AbstractMap a lze skrze ni získávat hodnoty vlastností pro dané klíče, měnit hodnoty vlastností a přidávat nové klíče a jim odpovídající hodnoty. Uložit tyto vlastnosti lze pomocí metody putproperties instance třídy AntProjectHelper, jíž je předána relativní cesta k souboru vlastností a instance EditableProperties, která má být uložena. Poté, co jsou nastaveny vlastnosti nově vytvářeného projektu, je nutné pro podporu editování kódu Java Card appletů projektu nastavit cestu k základním knihovnám Java Card platformy. Cesta k nim byla zadána v průvodci vytvářením nového projektu. Nyní tedy stačí tuto knihovnu do projektu programově přidat. V Lookupu instance reprezentující projekt získané v předchozím kroku lze vyhledat instanci třídy J2SEProjectClassPathModifier a na ní zavolat metodu addroots, jíž je předána cesta k souboru, který má být přidán do classpath

101 KAPITOLA 10 Vývoj NetBeans plug-inů 87 projektu. Po těchto krocích je projekt vytvořen a ve vývojovém prostředí otevřen zdrojový kód appletu, v němž je přednastavena základní kostra appletu. Šablona projektu, z níž byl projekt vytvořen, již obsahuje nastavení, která parametrizují překlad zdrojového kódu appletu na.class soubory tak, aby bylo možné je nástrojem Converter zkonvertovat. Standardními akcemi build či clean & build tedy lze zdrojové kódy projektu zkompilovat. Jelikož je Java Card typ projektu postavený nad projektem standardní platformy Javy, je velmi obtížná, či nemožná změna v projektu již existující funkčnosti toto se týká například akce run, kterou lze modifikovat pouze v té míře, že je upravena položka cíle 'run' v konfiguračním souboru pro Ant, který je k těmto akcím volán. Podobně je též přidávání nových akcí omezeno. Pro nový typ projektu je tedy nejvhodnější implementovat celý projekt od začátku. Nicméně postup, kterým projektu přidat nové akce, existuje a pro momentální funkčnost projektu pro podporu vývoje Java Card appletů zcela postačuje. Jedná se o rozšíření menu projektu o následující akce pomocí úprav v systémovém filesystému. Do složky 'Projects' a její podsložky 'Actions' jsou přidány položky pro třídy akcí, jejichž instance mají být do menu přidány. Toto popisuje následující pasáž souboru layer.xml definující úpravy systémového filesystému, které modul provádí: <folder name="projects"> <folder name="actions">... <file name="org-netbeans-modules-javacardproject-actions- ConvertAction.instance"> <attr name="position" intvalue="3"/> </file>... </folder> </folder> Pokud by se jednalo o normální třídy akcí, pak budou přidány do menu pro všechny projekty bez ohledu na typ. Použitím vzoru, kdy třída akce implementuje rozhraní ContextAwareAction (tedy funkčnost akce, která je aktivní dle momentálního kontextu), a triku, kdy pro projekty, které nejsou typu Java Card projektu (nemají ve vlastnostech klíče specifické pro Java Card projekt), je místo položky menu zobrazeno prázdné (ve smyslu žádné) místo, lze docílit zobrazování daných akcí pouze pro Java Card typ projektu. Tímto tedy lze docílit toho, že pro nekartový projekt zůstane menu projektu nepozměněné, ale pro Java Card typ projektu budou zobrazeny položky 'Convert', 'Build & Convert', 'Run JCWDE Simulator' a 'Java Card Project Properties'. Akce pro konverzi.class souborů na.cap a akce spuštění simulátoru JCWDE využívá příslušných nástrojů Java Card Development Kitu. Obě akce nejprve vytvoří z vlastností projektu (AID appletu, AID package, cesta k export souborům) parametry příkazové řádky, případně dočasné konfigurační soubory, a s nimi spustí v novém vlákně nový proces, v němž jsou příslušné nástroje volány s danými parametry či soubory konfigurace. Výstup spuštěných procesů je přesměrován do výstupního okna NetBeans, ve vývojovém prostředí NetBeans tedy lze kontrolovat výstup obou nástrojů. Pro spuštěný simulátor JCWDE je v rámci NetBeans Java Card typu projektu známa chyba,

102 88 KAPITOLA 10 Vývoj NetBeans plug-inů kdy simulátor nelze vypnout (pouze tím, je-li skutečně použit). Proces, kterým plug-in spouští simulátor, totiž není ten, v něm je nakonec simulátor skutečně spuštěn, a na nový proces, v němž je simulátor spuštěn, plug-in nemá referenci. Jelikož je simulátor programem napsaným v Javě, nelze proces identifikovat podle názvu, protože jeho název je např. pod Windows 'java.exe' jako u jakéhokoliv jiného javovského programu (a tedy například i samotných NetBeans). Prostředky Javy se tuto situaci zatím nepodařilo vyřešit. Nicméně spuštění simulátoru a následná práce s ním ukončená odpojením od simulátoru, simulátor ukončuje korektně. Postup instalace plug-inu Java Card Project a návod k němu je uvedený v dodatku E. Dokumentace k plug-inu Java Card Project je uvedena na CD v adresáři nb_pluginy\javacardmanagersuite\javacardproject\doc. Zdrojové kódy plug-inu Java Card Project se nacházejí na CD v adresáři nb_pluginy\javacardmanagersuite\javacardproject\src. Plug-in vyžaduje ke spuštění NetBeans minimálně verze 6.0, Java Runtime Environment nejméně verze 1.6 (nutné k běhu knihovny SimpleSmartCardAPI, kterou plug-in využívá) a přítomnost plug-inu Java Card Manager. Plug-in korektně funguje na operačních systémech Windows a Unix, jelikož pouze pro tyto systémy jsou podporovány nástroji Java Card Development Kitu.

103 KAPITOLA 11 Závěr Závěr Výsledkem práce je několik hotových produktů ať už v podobě aplikací a nástrojů, tak dokumentů, či připravených ukázkových appletů a úloh pro výuku. Tímto práce splňuje své zadání, kdy se podařilo prozkoumat a zmapovat aspekty technologie Java Card a následně připravit možné scénáře zapojení smart karet platformy Java Card do výuky včetně vyvinutí podpůrných nástrojů. Literatura a možné zdroje, z nichž bylo možné při práci na zadaných tématech čerpat, se vyznačovaly značnou nevyvážeností některá témata byla pokryta velmi široce (zejména ta týkající se obecného programování Java Card appletů), jiným tématům se však materiály věnovaly ve velmi malé míře. Jednalo se zejména o specifika karet od jednotlivých výrobců a implementace či samotné použití bezpečnostních funkcí definovaných v Open platform specifikaci. Toto je částečně možné vysvětlit tím, že využití daných funkcí je často zahrnuto v bezpečnostních řešeních jednotlivých výrobců karet, k nimž je dokumentace implementace neveřejná (de facto by se to rovnalo zveřejňování částí implementace operačního systému karty), a open-source implementace daných funkcí či mechanismů v mnoha případech neexistují. Ukázalo se, že přestože Java Card platforma nabízí nezávislost na výrobci karty, tato nezávislost se uplatňuje zejména na oblast vývoje appletů. Správa obsahu karty je předmětem jiných specifikací, které výrobcům v některých oblastech ponechávají volnost, čímž může docházet k jistým rozdílům mezi jednotlivými výrobci či verzemi specifikací. Kompatibilita s platformou Java Card a zpětná kompatibilita mezi platformami je však zaručena. V první fázi práce na zadané oblasti bylo nutné se seznámit s pro mě do té doby neznámou oblastí smart karet platformy Java Card a vývojem appletů pro tuto platformu. Následnou částí bylo zmapování kryptografických služeb, které Java Card platforma poskytuje prostřednictvím Java Card Cryptography API, kde se s výhodou dalo využít zkušeností s architekturou kryptografických služeb poskytovaných standardní platformou jazyka Java. Dále bylo nutné seznámit se s principy správy obsahu karty definovanými specifikací Open platform. V rámci práce byly provedeny také experimenty v podobě útoků zaměřených na možné slabiny modelu zabezpečení platformy Java Card. Přestože tyto útoky na testované kartě nebyly úspěšné, čímž se prokázalo, že bezpečnost platformy je jištěna nejen požadavky specifikace platformy, ale též její konkrétní implementací od výrobce, seznámení se s těmito typy útoků na platformu bylo přínosné. Po seznámení se s platformou, jejími možnostmi, nástroji vývojového kitu a procesem vývoje a nahráváním appletů na kartu došlo k rozboru těchto možností a postupů s ohledem na jejich zahrnutí do výuky. Byly připraveny návrhy témat výukových úloh a experimentů a scénáře práce s nimi včetně návrhu a implementace aplikace, která by zprostředkovávala testovací a kontrolní rozhraní appletům úloh. S ohledem na nedostatečné, či naopak příliš komplexní dostupné nástroje týkající se vývoje a správy appletů bylo rozhodnuto vyvinout pro tyto činnosti vlastní nástroje. Na základě tohoto rozhodnutí a související analýzy byla nejprve vyvinuta knihovna SimpleSmartCardAPI, která představuje objektovou nadstavbu nad existujícími knihovnami

104 90 KAPITOLA 11 Závěr javax.smartcardio a APDUIO pro přístup ke kartě a simulátoru z programového kódu aplikací. Knihovna SimpleSmartCardAPI umožňuje skrze několik úrovní abstrakce komunikovat s kartou či simulátorem. K přednostem knihovny patří zejména objektový návrh, který umožňuje její snadné zakomponování do aplikací psaných v jazyce Java a také možnost využívat vybrané funkce Card manageru na kartě (například nahrání appletu). Knihovna se stala důležitým stavebním prvkem dále vyvinutých aplikací a výrazně zjednodušila proces jejich vývoje. Spolu s vývojem testovací aplikace pro výukové úlohy bylo dokončeno i znění jednotlivých úloh a připraveny podklady pro výuku v podobě dokumentů popisujících vlastnosti platformy, stručný úvod do vývoje appletů a příručku k použití Java Card cryptography API. Testovací aplikace umožňuje přímý přístup k appletům úloh na kartě a podporu pro jednotlivé úlohy v podobě předdefinovaných APDU příkazů, které applety přijímají, či kontrolních výpočtů kryptografických operací na PC pro porovnání s výsledky výpočtů, které realizují applety na kartě. Úlohy byly zadané formou doplňování či rozšiřování šablon appletů a následného ověření jejich funkčnosti zasíláním APDU příkazů skrze testovací aplikaci. Zadání úloh pokrývalo základní použití kryptografických operací v appletu. Variant zadání se však kromě implementace na straně appletu nabízí mnohem více, ať už v podobě programování aplikace na PC, která komunikuje s kartou a využívá její služby, či například práce s bezpečnostními applety typu GemSafe (tedy přímé využívání karty jako komponenty bezpečnostních systémů). Tyto varianty zadání jsou však otázkou další přípravy příslušných podpůrných nástrojů či prostředí. Pro podporu vývoje appletů v rámci úloh na cvičení byl vyvinut plug-in (rozšíření) Java Card Project pro vývojové prostředí NetBeans, které je dostupné na PC v počítačových laboratořích. Tento plug-in zakomponuje mezi typy projektů přítomné v NetBeans typ projektu pro Java Card platformu. Přináší možnosti spouštění nástrojů souvisejících s vývojem appletů (konverze, simulace) z NetBeans bez nutnosti tyto nástroje volat z příkazové řádky a tvořit jejich konfigurační soubory. Plug-in též při vytvoření nového projektu připraví kostru zdrojového kódu Java Card appletu. S ohledem pro další rozšiřování plug-inu by bylo výhodné implementovat i možnost správy platforem Java Card (jako je tomu například u projektů platformy J2ME) nebo podporu debuggeru. Dále byl vyvinut plug-in Java Card Manager umožňující snadnou a intuitivní správu obsahu k PC připojených karet. Tedy možnost nahrávat na karty applety, či je z nich mazat. Umožňuje též posílání APDU příkazů a vytvoření zabezpečeného kanálu mezi kartou a PC, jímž lze přenášenou komunikaci zabezpečit. Plug-in obsahuje též podporu připojení ke spuštěnému simulátoru karty JCWDE, který je součástí vývojového kitu Java Card platformy. Tento nástroj byl zaslán na review kódu vývojářům NetBeans z firmy Sun Microsystems a byl schválen jako plug-in, který korektně využívá API platformy NetBeans. Pro vývoj uvedených plug-inů bylo nutné seznámit se principy platformy NetBeans a API, která NetBeans platforma nabízí. NetBeans platforma představuje zajímavou možnost i co se týká možného dalšího využití ve výuce, jelikož vývoj základních modulů (plug-inů) není příliš složitý. Bylo by tak tedy možné přímo do vývojového prostředí zahrnout některé nástroje, které by mohly podporovat práci studentů při cvičeních v rámci předmětů, kde je vývojové prostředí NetBeans využito. Zajímavou možností je též tvorba šablon [26], jimiž

105 KAPITOLA 11 Závěr 91 by bylo možné prostřednictvím lokálně založeného Update Centra NetBeans v rámci katedry takto distribuovat studentům podklady v podobě šablon projektů a zdrojových kódů k úlohám. Studenti by tímto způsobem měli možnost,přistupovat ke zdrojovým kódům programů pro cvičení přímo z NetBeans. Byla též vyvinuta podpůrná aplikace Java Card Image manager umožňující karty použité ve výuce rekonfigurovat do jejich původního stavu. V rámci práce došlo též ke spolupráci a podpoře open-source projektů. Kromě výše zmíněných plug-inů pro NetBeans se jedná o rozšíření seznamu typů smart karet projektu Smart Cards list a projekt knihovny ASAL pro přístup k různých platformám smart karet. V rámci zpětné vazby na připravené úlohy a vyvinuté nástroje jsem asistoval při cvičeních předmětu APK týkajících se práce s Java kartami. Účast na nich přinesla cenné zkušenosti a poznatky týkající se připravených úloh a vyvinutých aplikací stran jejich možných vylepšení, ale zároveň i potvrzení správnosti rozhodnutí v jejich návrhu většina studentů se s aplikacemi intuitivně seznámila a studenti byli schopni postupovat samostatně. Lze tedy říct, že daný záměr úloh a k nim příslušných nástrojů se podařilo splnit. Zajímavou zkušeností byl samotný podíl na vedení cvičení, kdy samotná nutnost formulovat odpovědi na dotazy studentů vedla ke kladnému zhodnocení vlastních znalostí získaných v průběhu diplomové práce. Práce otevřela také některá další témata vhodná pro pokračování či rozvoj. Vedle zmiňovaných návrhů na další témata úloh pro práci se smart kartami či využití NetBeans ve výuce se jedná o témata, která by mohla být součástí semestrálních, bakalářských či diplomových prací. Velmi užitečný by byl podpůrný nástroj pro applet GemSafe, který by umožňoval konfiguraci appletu a komunikaci s ním. Následně by bylo možné zmapovat možnosti využití tohoto appletu a například integrace jeho služeb do operačního systému či případně vytvoření vlastního bezpečnostního appletu. Námětem pro další práci mohou být též útoky na zabezpečení platformy Java Card založené na podobných principech, které byly popsány a něž odkazují reference. Další práce je též možná na knihovně SimpleSmartCard API v podobě dokončení implementace všech funkcí, které specifikuje Open platform, a zahrnutí specifikace Global platform. Podobně je též možné o další funkce rozšiřovat oba plug-iny pro NetBeans. Samostatnou kapitolou je aktuální vydání nové specifikace Java Card 3.0, která reflektuje dostupnost výkonnějšího hardwaru pro využití ve smart kartách a přináší zcela nové možnosti jako jsou vlákna, dynamické načítání tříd, využití Servlet API a podpora http komunikace na webové bázi. Vypracováním diplomové práce jsem načerpal mnohé nové poznatky a zkušenosti z oblastí, s nimiž není zcela běžné se setkat. Zejména je nutné zmínit podrobné seznámení se s platformou Java Card a specifikací Open platform, a vývojem modulů pro platformu NetBeans. V rámci práce byly formulované a do výuky zahrnuté úlohy pro výuku kryptografie. Vyvinuto bylo několik pomocných, ale též obecně použitelných aplikací knihovna SimpleSmartCardAPI a plug-iny pro vývojové prostředí NetBeans podporující vývoj aplikací pro platformu Java Card.

106 92 KAPITOLA 11 Závěr

107 KAPITOLA 12 Seznam použité literatury Seznam použité literatury [1] Rankl W., Effing W. Smart card Handbook. Wiley, West Sussex, [2] FINEID.FI: [3] Chen Z. Java Card Technology for Smart Cards. Addison Wesley (Java series), Palo Alto, [4] Hendry M. Smart card security and applications. Artech house, [5] Oaks S. Java Security. O'Reilly, Sebastopol, [6] The Java Virtual Machine Specification: [7] Witteman M. Java Card Security. Information Security Bulletin 11/2003. [8] Mostowski W., Poll E. Malicious Code on Java Card Smartcards: Attack and Countermeasures. [9] Sun Microsystems. Java Card Runtime Environment Specification. [10] Sun Microsystems. Java Card Virtual Machine Specification (JCDK 2.2.2). [11] Přibyl J., Kodl J. Ochrana dat v informatice. Vydavatelství ČVUT, Praha, [12] Menezes A. J., van Oorschot P. C., Vanstone S. A. Handbook of Applied Cryptography. CRC Press, [13] Open platform specification 2.0.1: augsburg.de/lehrstuehle/swt/se/teaching/ws0708/javacard/dokumentation/card- Specification.pdf [14] Delegated management US patent: description.html [15] Guidelines for developing applications on Open platform cards: developing_apps_on_op_cards_11a.pdf [16] GlobalPlatform project: [17] Gemplus. GemSafe applet reference manual. [18] MUSCLE smart card develeopment: [19] Smart Card List. Rudovic Rousseau: [20] ASA. Ali Selen: [21] Boudreau T., Tulach J., Wielenga G. Rich Client Programming: Plugging into the NetBeans(TM) Platform. Prentice hall, [22] NetBeans Platform Developer FAQs: [23] NetBeans API JavaDoc: [24] Howto Implement Wizard steps: [25] NetBeans 4.x Project & Build System How-To:

108 94 KAPITOLA 12 Seznam použité literatury [26] NetBeans Project Sample Module Tutorial:

109 KAPITOLA A Zabezpečení Open platform 95 A Zabezpečení Open platform A.1 Kryptografické algoritmy Níže jsou uvedeny kryptografické algoritmy, které Open platform využívá. Pro bližší detaily o jejich principech viz. [11] nebo [12]. A.1.1 Data Encryption Standard (DES) DES je symetrická bloková šifra. Ve své výchozí nejjednodušší variantě využívá 8-bytový klíč k šifrování 8-bytových bloků otevřeného textu, které jsou šifrované na 8 bytů šifrového textu. Stejný klíč je využit i pro dešifrování 8-bytových bloků šifrového textu na 8-bytové bloky otevřeného textu. Open platform využívá varianty 3DES v tzv. EDE módu. 8-bytový blok otevřeného textu je zašifrován pomocí DES s klíčem k 1, poté je dešifrován klíčem k 2 a následně zašifrován klíčem k 3. Výsledkem je 8-bytový blok šifrového textu. Proces dešifrování je opačný k šifrování. Open platform využívá pro kryptografické operace klíče délky 16 bytů. Jedná se tedy o variantu two key 3DES, kdy jsou tyto 16-bytové klíče rozděleny na dvě poloviny levá polovina (8 bytů) je použita jako klíče k 1 =k 3 a pravá polovina (8 bytů) jako klíč k 2. Open platform 3DES operace využívá v režimech Cipher Block Chaining (CBC) a Electronic Code Book (ECB). Režim Electronic Code Book (ECB) ECB režim šifrování spočívá v šifrování 8-bytových bloků otevřeného textu jednotlivě otevřený text je rozdělen na 8-bytové bloky (pokud není délka textu v bytech beze zbytku dělitelná 8, je poslední blok doplněn tzv. výplní (padding), viz. konkrétní implementace DES v Open platform) a ty jsou jednotlivě šifrovány. Režim Cipher Block Chaining (CBC) Šifrování v CBC režimu je založeno na řetězení výstupů šifrování 8-bytových bloků otevřeného textu (pokud není délka textu v bytech beze zbytku dělitelná 8, je poslední blok doplněn výplní, viz. konkrétní implementace DES v Open platform) s dalšími vstupními bloky otevřeného textu. Šifrový text jednoho bloku je tedy určen jednak jako výstupní šifrový text, ale také jako vstup pro šifrování otevřeného textu následujícího bloku. Předchozí výstup je se vstupem kombinován bitovou operací XOR. První blok otevřeného textu je řetězen s inicializačním vektorem. Ten je pro šifrování OP definován jako 8 bytů binární nuly (0x00). Open platform využívá režimu CBC nejen pro šifrování, ale i generování podpisu. A.1.2 Generování podpisu (varianta full 3DES MAC) Při generování podpisu je jako při režimu CBC šifrování 3DES šifrový text předchozího zašifrovaného bloku společně s otevřeným textem aktuálního bloku vstupem pro šifrování bloku. Rozdílem oproti režimu šifrování je zde fakt, že na výstup jde pouze šifrový text posledního bloku. Šifrové texty všech předchozích bloků jsou použity pouze jako vstupy pro šifrování bloků následujících. Šifrový text posledního bloku představuje podpis, resp. MAC,

110 96 KAPITOLA A Zabezpečení Open platform celého otevřeného textu. Hodnota inicializačního vektoru je určena konkrétním použitím metody v rámci Open platform. A.1.3 Generování podpisu (varianta single DES + final 3DES MAC) Jedná se o modifikaci varianty full 3DES vyznačující se vyšší výkonností kvůli použití jednoduchého DES šifrování. Princip je shodný s variantou full 3DES MAC s tím rozdílem, že šifrování jednotlivých bloků je zajištěno jednoduchým DES šifrováním; pouze poslední blok je zašifrován pomocí 3DES. Výstupem je opět pouze poslední blok, který představuje MAC celého otevřeného textu. Hodnota inicializačního vektoru je určena konkrétním použitím metody v rámci Open platform. A.1.4 Secure Hash Algorithm (SHA-1) SHA-1 hašovací funkce vytváří 20-bytovou hodnotu, která je použita dále pro účely ověření či podpisu. A.1.5 Algoritmy veřejného klíče Open platform používá RSA jako algoritmus veřejného klíče. Veškeré operace, pro něž Open platform používá RSA, jsou operace podepisování a ověření. Použit je konkrétně standard PKCS1. Podepsání dokumentu spočívá v zašifrování 20-bytové haše dokumentu pomocí soukromého klíče. Podpis má délku modulu veřejného klíče v případě Open platform má modul délku 1024 bitů (128 bytů). Ověření podpisu je založena na dešifrování podpisu odpovídajícím veřejným klíčem a porovnání dešifrované haše s haší vypočítanou z přijaté zprávy. Pokud se obě haše rovnají, je ověření podepsaného dokumentu úspěšné. A.2 Kryptografické klíče Open Platform Open platform definuje klíče používané pro zabezpečenou komunikaci a kryptografické operace využívané Card managerem a Bezpečnostními doménami. Aplikace mohou samozřejmě využívat vlastní bezpečnostní protokoly a vlastní klíče, které Open platform nespecifikuje a které jsou definované aplikací samotnou. Klíče jsou na kartě uchovávány v kontejneru zvaném sada klíčů (key set). Sada může obsahovat jeden či více klíčů a na kartě může být uloženo několik sad. Card manager využívá následujících klíčů, které jsou využívány k zabezpečené správě karty a správě obsahu aplikací na kartě a které mohou používat aplikace využívající kryptografických služeb Card manageru. Jedná se o tzv. statické klíče jejich hodnota zůstává stejná, dokud není explicitně změněna.

111 KAPITOLA A Zabezpečení Open platform 97 Klíč Použití Délka ENC klíč Vzájemná autentikace a šifrování 16 bytů MAC klíč Vzájemná autentikace a kontrola integrity 16 bytů KEK klíč Šifrování a dešifrování klíčů 16 bytů Token klíč Ověřování tokenů (RSA veřejný klíč) Klíč potvrzení Generování potvrzení Tabulka 4: Kryptografické klíče používané Card managerem 1024 bitů 16 bytů Šifrovací klíč (ENC klíč), MAC klíč jsou využívány pro otevření a používání zabezpečeného kanálu. ENC a MAC klíče nejsou v zabezpečeném kanálu využívány přímo jsou použity ke generování session klíčů určených pro šifrování a kontrolu integrity zpráv a jsou platné pouze pro jednu relaci. K vygenerovaní session klíčů dochází při vzájemné autentikaci, což je dle Open platform úvodní proces otevírání zabezpečeného kanálu. KEK klíč je využíván ve své statické formě pro zabezpečení přenosu klíčů na kartu. Token klíč a klíč potvrzení jsou využity v případě, kdy karta podporuje tzv. delegovanou správu (delegated management). V tom případě musí Card manager obsahovat sadu obsahující tyto klíče. Token klíč je 1024bitový veřejný RSA klíč, který je používán pro ověření load a install tokenů. Klíč potvrzení je používán pro zabezpečení potvrzení instalace, nahrání a smazání. Sada s token klíčem a klíčem potvrzení nemůže být použita pro otevření zabezpečeného kanálu. Bezpečnostní domény pro své kryptografické služby využívají také různých kryptografických klíčů. Ty jsou využívány kryptografickými službami poskytovanými aplikacím (např. zabezpečený kanál) a jsou dále použity k zabezpečení správy Bezpečnostní domény, k zabezpečení delegované správy a k ověřování obsahu, který je nahráván na kartu. Následující klíče představují minimum, které Bezpečnostní doména musí podporovat. Význam, vlastnosti a použití ENC, MAC a KEK klíčů jsou totožné s odpovídajícími klíči Card manageru. Klíč Použití Délka ENC klíč Vzájemná autentikace a šifrování 16 bytů MAC klíč Vzájemná autentikace a kontrola integrity 16 bytů KEK klíč Šifrování a dešifrování klíčů 16 bytů DAP klíč Ověřování DAP (veřejný RSA klíč / DES klíč) Tabulka 5: Kryptografické klíče používané Bezpečnostní doménou 1024 bitů / 16 bytů

112 98 KAPITOLA A Zabezpečení Open platform Podporuje-li Bezpečnostní doména ověření DAP (Data authentication pattern), musí obsahovat sadu klíčů s buď DES klíčem, anebo 1024bitovým veřejným RSA klíčem. Pomocí těchto klíčů je ověřován podpis data bloků Load souboru. Sada s klíčem pro ověření DAP nesmí být použita pro otevření zabezpečeného kanálu. A.3 Zabezpečená komunikace Open Platform definuje protokol zabezpečené komunikace pomocí zabezpečeného kanálu (Secure channel). Zabezpečený kanál je využíván Card managerem a může být využíván Bezpečnostními doménami. Níže popsaný model je v tomto znění využíván Card managerem. Bezpečnostní doména může definovat vlastní protokol nebo využít popsaného. Zabezpečený kanál definuje tři základní bezpečnostní služby: Vzájemná autentikace (mutual authentication) karta i externí entita vzájemně ověří svou totožnost pomocí znalosti sdíleného tajemství. Vzájemná autentikace je platná pouze po omezený čas jednu komunikační relaci. Pokud relace skončí, je třeba provést novou autentikaci. Při otevírání zabezpečeného kanálu vždy dochází k vzájemné autentikaci. Integrita karta dokáže ověřit, že příchozí komunikace pochází od ověřené entity a že příchozí data nejsou během přenosu pozměněna a přichází v pořadí, v jakém je entita vyslala. Šifrování šifrování na kartu přenášeného obsahu otevřené komunikace pomocí šifrování a dešifrování. Na základě toho jsou definovány tři úrovně zabezpečení pro zabezpečený kanál: 0 Vzájemnou autentikací je ověřena karta a externí entita; je vytvořen zabezpečený kanál, ovšem k zabezpečení komunikace nedochází. 1 Vzájemnou autentikací je ověřena karta a externí entita; je vytvořen zabezpečený kanál a je zabezpečen kontrolou integrity komunikace. 3 Vzájemnou autentikací je ověřena karta a externí entita; je vytvořen zabezpečený kanál a je zabezpečen kontrolou integrity komunikace a šifrováním otevřeného obsahu. Zabezpečený kanál definovaný specifikací Open platform poskytuje možnosti pro zabezpečení APDU příkazů; odpovědi na příkazy zabezpečeny prostředky zabezpečeného kanálu nejsou. Zabezpečený kanál je automaticky uzavřen, pokud nastane jedna z následujících situací: Aplikací přijatý APDU příkaz obsahuje bezpečnostní chybu. Aplikací přijatý APDU příkaz neobsahuje zabezpečení požadované úrovní zabezpečení. Dojde k výběru jiné aplikace, než s jakou byl navázán zabezpečený kanál.

113 KAPITOLA A Zabezpečení Open platform 99 Dojde k ukončení relace s kartou. Poznámka: Příkaz SELECT nikdy nevyžaduje zabezpečený kanál. Jedná se o výběr aplikace přímo určený pro jakékoliv externí entity. I neověřené entita má možnost vybrat zvolenou aplikaci, vůči níž se posléze může ověřit. A.4 Vzájemná autentikace (Mutual authentication) Ke vzájemné autentikaci dochází při otevírání zabezpečeného kanálu. Karta i externí entita vzájemně ověřují svoji totožnost pomocí znalosti sdíleného tajemství, kterým jsou statické klíče karty. Pokud v procesu autentikace dojde k chybě, musí být celá procedura zrušena a započata od začátku. Popišme si nejprve proces vzájemné autentikace obecně. V následujících odstavcích budou jednotlivé kroky rozebrány detailněji. 1) Externí entita inicializuje otevření zabezpečeného kanálu pomocí příkazu INITIALIZE UPDATE. Jako data příkazu jsou kartě předána externí entitou vygenerovaná náhodná data, tzv. host challenge. 2) Karta po obdržení příkazu INITIALIZE UPDATE a v něm předané host challenge vygeneruje vlastní náhodná data, tzv. card challenge. Z card challenge, host challenge a statických klíčů karta vygeneruje session klíče klíče platné pouze pro tuto relaci zabezpečeného kanálu. 3) Pomocí session klíčů je kartou vytvořen tzv. card cryptogram. Card cryptogram a card challenge jsou jako odpověď odeslány externí entitě. 4) Externí entita má nyní stejná data, jaká vlastní karta host challenge i card challenge. Pomocí nich je schopna zkonstruovat session klíče a card cryptogram. Porovnáním card cryptogramu získaného od karty s vlastním vygenerovaným může externí entita ověřit kartu jsou-li oba kryptogramy stejné, znamená to, že karta zná sdílené tajemství. 5) Externí entita nyní podobným způsobem vygeneruje host cryptogram a odešle ho kartě pomocí příkazu EXTERNAL AUTHENTICATE. Karta zná všechna data, která externí entita použila k vygenerování host cryptogramu a může tedy vygenerovat vlastní host cryptogram. Porovnáním host cryptogramu vygenerovaného externí entitou s vlastním vygenerovaným může karta ověřit externí entitu jsou-li oba kryptogramy stejné, znamená to, že externí entita zná sdílené tajemství. A.4.1 Session DES klíče a jejich generování Session DES klíče jsou generovány pro každou relaci zabezpečené komunikace mezi kartou a externí entitou. Konkrétně jsou generovány při otevírání zabezpečeného kanálu. Jsou využity pro vzájemnou autentikace karty a externí entity a v další zabezpečené komunikaci, je-li vyžadována. Tímto je zajištěno, že klíče použité pro vzájemnou autentikaci, kontrolu integrity komunikace a šifrování komunikace jsou při každém spojení různé nelze tedy klíče jednoho připojení k zabezpečenému kanálu využít k úspěšné komunikaci v nově otevřeném zabezpečeném kanálu. Protože jsou tyto session klíče kromě vzájemné autentikace využity pro kontrolu integrity komunikace a šifrování komunikace, jsou pro generování session klíčů využity ENC a MAC statické klíče.

114 100 KAPITOLA A Zabezpečení Open platform Ilustrace 18: Průběh procesu vzájemné autentikace Karta v okamžiku přijetí příkazu INITIALIZE UPDATE a vygenerování náhodné hodnoty card challenge zná čtyři vstupní parametry pro generování session klíčů statický ENC klíč (16 bytů), statický MAC klíč (16 bytů), host challenge (8 bytů) a card challenge (8 bytů). 1) Z host challenge a card challenge jsou vytvořena derivační data pro nově vytvářené session klíče. Derivační data mají délku 16 bytů první 4 byty jsou tvořeny druhou polovinou card challenge, následující 4 byty jsou tvořeny první polovinou host challenge, předposlední čtyři byty jsou tvořeny první polovinou card challenge a poslední čtyři byty jsou tvořené druhou polovinou host challenge. 2) Vzniklá derivační data délky 16 bytů jsou šifrována 3DES v režimu ECB. Šifrováním derivačních dat s použitím statického klíče ENC je získán session klíč ENC o délce 16 bytů. Šifrováním derivačních dat s použitím statického klíče MAC je získán session klíč MAC o délce 16 bytů. Tento postup provede jak karta, tak i externí entita poté, co od karty obdrží card challenge. Oba subjekty nyní vlastní session klíče pro komunikaci. Ilustrace 19: Derivační data pro generování session klíčů

115 KAPITOLA A Zabezpečení Open platform 101 Ilustrace 20: Generování session ENC klíče Ilustrace 21: Generování session MAC klíče A.4.2 Proces generování a ověřování card cryptogramu Card cryptogram je generován pomocí card a host challenge hodnot. Za host challenge je připojena card challenge a výsledek je doplněn osmibytovým blokem v podobě 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00. Následně je vytvořen podpis toho 24-bytového bloku pomocí 3DES v režimu CBC, jakožto varianta full 3DES. Jako inicializační vektor jsou voleny binární nuly. Klíčem pro 3DES je session ENC klíč. Výsledný 8-bytový podpis je card cryptogram. A.4.3 Proces generování a ověřování host cryptogramu Host kryptogram je generován pomocí card a host challenge hodnot. Za card challenge je připojena host challenge a výsledek je doplněn osmibytovým blokem v podobě 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00. Následně je vytvořen podpis toho 24-bytového bloku pomocí 3DES v režimu CBC, jakožto varianta full 3DES. Jako inicializační vektor jsou voleny binární nuly. Klíčem pro 3DES je session ENC klíč. Výsledný 8-bytový podpis je host cryptogram. A.5 APDU příkazy pro vytvoření zabezpečeného kanálu V této sekci jsou stručně popsány APDU příkazy definované Open platform sloužící k vytvoření zabezpečeného kanálu mezi kartou a externí entintou. Pro více informací viz. [13]. A.5.1 INITIALIZE UPDATE Příkaz INITIALIZE UPDATE je určený k přenosů informací o kartě a aktuální relaci mezi kartou a externí entitou. Zároveň tento příkaz inicializuje vytváření zabezpečeného kanálu. Může být použit kdykoliv k vytvoření nového zabezpečeného kanálu (i ve chvíli, kdy už zabezpečený kanál vytvořen je). Příkazem je kartě zasláno host challenge, sada klíčů, která má být vybrána, a v rámci sady konkrétní klíč, který má být použit pro otevření zabezpečeného kanálu. Odpovědí na příkaz je card challenge, card cryptogram, data použitá pro diversifikaci klíčů a označení sady a popř. klíče, který byl použit k vytvoření zabezpečeného kanálu. A.5.2 EXTERNAL AUTHENTICATE Příkaz EXTERNAL AUTHENTICATE je kartou použit k autentikaci externí entity (skrze přenášený host cryptogram) a je jím určena úroveň zabezpečení zabezpečeného kanálu.

116 102 KAPITOLA A Zabezpečení Open platform Příkazu musí bezprostředně předcházet úspěšné vykonání příkazu INITIALIZE UPDATE. Příkaz je vždy zabezpečen kontrolou integrity (tj. přidáním MAC hodnoty hlavičky a dat příkazu, jak je popsáno v 5.9). A.6 Integrita Karta dokáže ověřit, že příchozí komunikace pochází od ověřené entity a že příchozí data nejsou během přenosu pozměněna a přichází v pořadí, v jakém je entita vyslala. Kontrola integrity a původu zprávy je zajištěna použitím 3DES šifrování v CBC režimu pomocí session klíčů vygenerovaných při vzájemné autentikaci karty a externí entity. Při odesílání APDU příkazu kartě je z hlavičky a dat APDU příkazu vypočítána hodnota MAC (Message Authentication Code). Ta je připojena k příkazu. Karta po obdržení příkazu použitím stejných operací a při vzájemné autentikaci vygenerovaných session klíčů vypočítá MAC z hlavičky a dat přijatého APDU příkazu a porovná ho s hodnotou MAC, která byla kartě zaslána externí entitou. Pokud se obě hodnoty MAC rovnají, přijatý příkaz odpovídá originálu vyslanému externí entitou. Otevřený zabezpečený kanál může podle úrovně zabezpečení vyžadovat kontrolu integrity přenášených APDU příkazů pomocí MAC. Jedná se konkrétně o úrovně 1 a 3. Na úrovni 0 je kontrola integrity požadována pouze pro příkaz EXTERNAL AUTHENTICATE, který je součástí procesu otevírání zabezpečeného kanálu. Poznámka: MAC hodnota je vypočítávána z otevřeného textu příkazu. Pokud je zabezpečený kanál na úrovni zabezpečení 3 (šifrování dat příkazu), je tedy na straně externí entity nejprve vypočítána hodnota MAC příkazu, posléze je příkaz zašifrován. Na straně karty je příkaz nejprve dešifrován a z otevřeného textu je vypočítána hodnota MAC přijatého APDU příkazu. Kontrola dodržení pořadí kartou přijatých příkazů s pořadím příkazů odeslaných externí entitou je zajištěna tím, že jako inicializační vektor při výpočtu MAC pro aktuální příkaz je použita hodnota MAC předchozího příkazu. A.6.1 Generování a ověřování MAC Pro generování a ověřování MAC hodnoty APDU příkazu je využíván session MAC klíč. MAC je vypočítáván pomocí 3DES v režimu CBC a variantě full 3DES. Hodnota MAC je vypočítávána pro celý APDU příkaz kromě pole Le (je-li v příkazu přítomno). Před výpočtem MAC hodnoty je nutné provést úpravu hlavičky příkazu a výplň. Pravidla pro modifikaci hlavičky APDU příkazu jsou následující: Délka dat APDU příkazu (pole Lc) musí být zvětšena o 8. Toto vyjadřuje připojení 8 bytů hodnoty MAC za vlastní data APDU příkazu. Pole CLA APDU příkazu musí být upraveno tak, aby vyjadřovalo, že se jedná o zabezpečený APDU příkaz. Toto je definováno jako úprava 3. bitu CLA bytu na hodnotu 1. U Open platform definovaných příkazů to znamená, že hodnota CLA bytu bude 0x84 namísto 0x80.

117 KAPITOLA A Zabezpečení Open platform 103 Ilustrace 22: Proces generování MAC hodnoty pro ADPU příkaz Při přidávání výplně je na konec bloku dat pole vytvořeného z hlavičky a dat APDU příkazu přidán byte 0x80. Je-li poté pole délky, která je násobkem 8, procedura výplně končí. V opačném případě je na konec pole přidávána binární nula, dokud není délka pole násobkem 8. Do výpočtu MAC vstupuje hodnota inicializačního vektoru. Pomocí inicializačního vektoru lze zajistit kontrolu dodržení posloupnosti přijatých APDU příkazů s posloupností, s jakou byly APDU příkazy odeslány externí entitou. Pro příkaz EXTERNAL AUTHENTICATE, který je vždy prvním příkazem posloupnosti příkazů zabezpečeného kanálu, je použit inicializační vektor z binárních nul. Pro následné příkazy je inicializačním vektorem vždy MAC hodnota předchozího odeslaného příkazu. Pomocí session MAC klíče a inicializačního vektoru je pro modifikovaný APDU příkaz (upravená hlavička a výplň dat) vypočítána hodnota MAC. Ta je připojena za původní (nemodifikovaná výplní) data APDU příkazu s upravenou hlavičkou. Karta musí k ověření MAC hodnoty přijatá data stejným způsobem formátovat výplní a za pomoci session MAC klíče a stejného inicializačního vektoru vypočítat vlastní hodnotu MAC. V případě korektního ověření integrity musí být MAC hodnota příkazu zachována, aby mohla být při přijetí dalšího APDU příkazu použita jako inicializační vektor pro výpočet MAC hodnoty, čímž je zajištěna kontrola posloupnosti přijatých APDU příkazů. A.7 Šifrování Šifrování přenášeného obsahu otevřené komunikace je zajištěno použitím 3DES šifrování v CBC režimu za použití vygenerovaných session klíčů při vzájemné autentikaci. Šifrována jsou pouze data APDU příkazu, hlavička zůstává v otevřené formě. Řetězení 3DES šifrování je aplikováno pouze v rámci šifrování bloků jednoho příkazu, nenavazuje mezi jednotlivými příkazy. Otevřený zabezpečený kanál může podle úrovně zabezpečení vyžadovat kromě kontroly integrity přenášených APDU příkazů pomocí MAC též šifrování datové části APDU příkazu. Jedná se konkrétně o úroveň 3. Nejprve dojde k opatření APDU příkazu MAC hodnotou a poté k zašifrování datové části příkazu.

118 104 KAPITOLA A Zabezpečení Open platform A.7.1 Šifrování a dešifrování dat v APDU příkazu Pro šifrování datové části APDU příkazu je využíván session ENC klíč. Data jsou šifrována pomocí 3DES v režimu CBC. Datová část APDU příkazu je zašifrována na straně externí entity. Karta provede po obdržení APDU příkazu dešifrování datové části APDU příkazu. Šifrována není hlavička APDU příkazu a připojená hodnota MAC pro daný APDU příkaz. Před šifrováním dat je nutné provést výplň a úpravu hlavičky příkazu. Výplň dat je při šifrování součástí dat přenášeného APDU příkazu. Jedná se tedy o rozdíl mezi výplní u výpočtu MAC, kde výplň sloužila pouze pro potřeby výpočtu MAC hodnoty, ale nebyla již přenášena s příkazem. Pravidla pro výplň datové části APDU příkazu a její formátování před šifrováním jsou následující: Délka původních dat v otevřené formě je přidána na začátek bloku dat. Je součástí datové části APDU příkazu. Pokud je po přidání délky původních dat do datové části nyní délka datové části APDU příkazu násobkem 8, není potřeba další výplně. Není-li tomu tak, je na konec datové části přidána hodnota 0x80. Pokud je nyní délka datové části násobkem 8, není potřeba další výplně. Pokud tomu tak není, jsou na konec datové části přidávány binární nuly, dokud není délka datové části APDU příkazu násobkem 8. Všechny přidané byty do datové části APDU příkazu (délka původních dat, výplň 0x80 a výplň 0x00) musí být zahrnuty do pole Lc označujícího délku datové části APDU příkazu. Ta nyní musí reflektovat aktuální délku modifikované datové části. Datová část příkazu je nyní připravena k zašifrování. Jako hodnota inicializačního vektoru jsou voleny binární nuly. Řetězení 3DES v CBC režimu je uplatňováno pouze v rámci šifrování datové části jednoho příkazu. Příkaz je nyní možné odeslat. Karta datovou část přijatého příkazu pomocí session ENC klíče dešifruje. Následně odstraní přidané výplně a byte označující délku původního obsahu datové části a upraví délku pole Lc tak, aby reflektovalo délku původních dat neovlivněných formátováním pro šifrování. Poté lze teprve ověřovat MAC hodnotu, která byla vypočítána na straně externí entity z otevřené podoby dat. Ilustrace 23: Proces šifrování dat APDU příkazu

119 KAPITOLA A Zabezpečení Open platform 105 A.8 Šifrování a dešifrování klíčů Klíče předávané kartě v APDU příkazech jsou šifrované pomocí 3DES v režimu ECB. K šifrování je použitý statický KEK klíč. Předávané klíče jsou klíče, které karta využívá k DES operacím, takže jsou délky, která je násobkem 8, není tedy nutné využívat výplně. Zašifrované klíče jsou vloženy do datové části PUT KEY příkazu. Pro zabezpečený kanál jsou tyto zašifrované klíče stále považovány za otevřený text, a tak je, pokud je pro takovou úroveň kanál vytvořen, příkaz kontrolován kontrolou integrity, či šifrován postupem pro zabezpečenou komunikaci přes zabezpečený kanál, jak bylo popsáno výše. Společně s klíčem příkaz PUT KEY přenáší v datové části i kontrolní hodnotu, díky níž karta může ověřit, že přijatý klíč je správný. Tvorba této hodnoty se skládá ze zašifrování bloku 8 binárních nul předávaným klíčem pomocí 3DES v režimu ECB. Jako kontrolní hodnota jsou přenášeny pouze tři nejpravější byty výsledku šifrování. Karta přijatý klíč dešifruje a provede jím kontrolní šifrování nad blokem 8 binárních nul. Porovnáním tří nejpravějších bytů výsledku šifrování s přijatou kontrolní hodnotou dojde k ověření, zda přenesený klíč odpovídá klíči odeslanému externí entitou. A.9 Kontrola na kartu nahrávaného obsahu Není-li na kartě implementována delegovaná správa obsahu, nebo je zakázána, nemůže poskytovatel aplikací na kartu nahrávat či instalovat vlastní aplikace sám. Na kartu může nahrávat či instalovat aplikace pouze vydavatel karty (resp. Card manager v řeči entit na kartě). Vydavatel aplikací však může pomocí DAP mechanismů dohlížet na autenticitu a integritu aplikací nahrávaných vydavatelem karty. Kontrola integrity je založena na hašování nahrávaného.cap souboru aplikace a kontrole autenticity na DES či RSA podpisu. Ilustrace 24: Nahrávání nezabezpečené kontrolou integrity Ilustrace 25: Nahrávání zabezpečené kontrolou integrity

120 106 KAPITOLA A Zabezpečení Open platform A.9.1 Nahrávání bez kontroly integrity a původu Toto schéma představuje proces nahrávání aplikací, které není zabezpečené kontrolou integrity a autenticity.cap souboru. Vydavatel karty, tedy entita, která má přístup ke Card manageru, zde nahrává na kartu aplikace a musí důvěřovat jejich obsahu. Přestože je nahrávání realizováno zabezpečeným kanálem, není zde žádný mechanismus, který by zaručoval autenticitu a integritu souboru zasílaného přes kanál. Toto schéma je typické pro proces personalizace karty, tedy než dojde k vydání karty do užívání. A.9.2 Nahrávání zabezpečené kontrolou integrity V tomto modelu je proces nahrávání aplikací zabezpečený kontrolou integrity.cap souboru. Aplikaci na kartu nahrává vydavatel karty. Díky zabezpečení kontrolou integrity dojde k odhalení jakékoliv změny aplikace. Pokud je změna detekována, nahrávání aplikace je zrušeno. Toto schéma je typické pro nahrávání aplikací vlastněnými vydavatelem karty ve fázi, kde je již karta vydána do užívání. A.9.3 Nahrávání zabezpečené podpisem V tomto modelu je nahrávání aplikací prostřednictvím vydavatele karty zabezpečeno kontrolou integrity a digitálním podpisem nahrávaných dat. Nahrávaná data aplikace jsou podepsána veřejným RSA klíčem poskytovatele aplikace či jeho tajným DES klíčem. Díky těmto mechanismům lze detekovat modifikace dat, ke kterým by došlo od okamžiku dodání aplikace vydavateli karty a nahrání aplikace na kartu. Zároveň je potvrzena autenticita poskytovatele aplikace. Podpis může být vygenerován DES nebo RSA. Na konci procesu nahrávání aplikace dojde jednak ke kontrole integrity nahraných dat a dále k ověření podpisu, které svým veřejným RSA klíčem či tajným DES klíčem provede Bezpečnostní doména poskytovatele aplikace. Dojde-li ke zjištění změny v nahrávaných datech, je nahrávání aplikace zrušeno. K tomuto scénáři dochází při nahrávání aplikací vlastněných poskytovatelem aplikace ve fázi, kdy je již karta vydána do užívání. Ilustrace 26: Nahrávání zabezpečené podpisem

121 KAPITOLA A Zabezpečení Open platform 107 Ilustrace 27: Nahrávání zabezpečené podpisem třetí strany (RSA varianta) Podpis.cap souboru je nutný pouze pro soubory poskytovatelů asociovaných s Bezpečnostní doménou, která ma privilegia DAP ověřování. Jsou-li však na kartě přítomny Bezpečnostní domény s povinným DAP ověřováním (mandated DAP verification), je přítomnost podpisu nutná pro všechny.cap soubory nahrávané na kartu. Pokud podpis.cap soubor neobsahuje, je nahrávání.cap souboru zrušeno. Pro tyto případy je typické, že existuje třetí strana, které důvěřuje vydavatel karty i poskytovatel aplikací. Ta je zodpovědná za generování podpisů pro poskytovatele aplikací. Třetí strana vlastní soukromý RSA klíč či tajný DES klíč, jimiž podepisuje nahrávané.cap soubory. A.10 Delegovaná správa obsahu Delegovaná správa obsahu je služba, která umožňuje poskytovatelům aplikací provádět operace spojené se správou obsahu aplikací na kartě. Bez delegované správy obsahu musí každé nahrání aplikace na kartu být realizované vydavatelem karty, který jediný by měl mít možnost ověřit se vůči Card manageru a otevřít zabezpečený kanál pro správu aplikací na kartě. Tento požadavek je však pro reálné použití často nepraktický, protože by poskytovatel aplikací byl pro každé nahrání aplikace nucen obracet se na vydavatele karty. Delegovaná správa obsahu nabízí řešení, jak zajistit, aby poskytovatel aplikací mohl na kartu nahrávat vlastní aplikace. Avšak vzhledem k požadavku, že musí jít o aplikace schválené vydavatelem karty, zůstává vydavateli dohled nad tím, které aplikace bude možné na kartu nahrát. Podrobný rozbor motivace vedoucí k využívání delegované správy a detaily jejích mechanismů viz. [14]. Ilustrace 28: Mechanismus delegované správy obsahu

122 108 KAPITOLA A Zabezpečení Open platform Delegovaná správa obsahu je založena na modelu, kdy poskytovatel aplikace, který hodlá na kartu skrze svou Bezpečnostní doménu pomocí delegované správy obsahu nahrát aplikaci, musí požádat vydavatele karty o RSA podpis zvaný token. Token je generován nad parametry a sekcí dat APDU příkazu INSTALL. Token je spolu s příkazem zaslán kartě a předtím, než Card manager na požadavek Bezpečnostní domény provede fyzickou změnu obsahu karty, je podpis ověřen. Pokud je ověření úspěšné, Card manager vygeneruje tzv. potvrzení, které dokazuje provedení dané operace. A.10.1 Load a Install Token Token je na kartu zaslán spolu s příkazem INSTALL [for load]. Token zaručuje, že na kartu je nahrána aplikace, která byla poskytovatelem karty schválena a podepsána a že nedošlo k její změně či změně jejího AID. Podobné to je i v případě INSTALL [for install] příkazu zde token zaručuje, že dojde k nainstalování schválené aplikace z daného Load souboru, s potvrzeným AID, privilegii a instalačními parametry, které byly podepsány. Load token je vytvořen pomocí RSA šifrování SHA-1 haše nad obsahem příkazu INSTALL [for load] a připojené haše Load souboru. Šifrování využívá soukromý klíč pro ověřování DAP. Podobná je situace u install tokenu, který je vytvořen RSA šifrováním SHA-1 haše nad obsahem příkazu INSTALL [for install]. Šifrování využívá soukromý klíč pro ověřování DAP. Card manager ověří veřejným klíčem pro ověřování DAP Load či install token a také porovná hodnotu vložené haše Load souboru s obsahem Load souboru na kartu nahrávaným. Příkaz DELETE v Delegated managementu nevyžaduje přítomnost tokenu, poskytovatel aplikací má však přirozeně povoleno odstraňovat pouze instance a Load file, které přísluší jeho Security domain. A.10.2 Generování potvrzení Potvrzení jsou generována při delegované správě obsahu jako prostředek, kterým je vydavateli karty potvrzeno, že požadovaná operace proběhla úspěšně. Potvrzení je generováno podpisem DES v režimu CBC ve variantě single DES + final 3DES za použití klíče pro potvrzení a inicializačního vektoru v podobě binárních nul. Card manager si uchovává 16-bitový čítač vydaných potvrzení. Čítač je na počátku nastaven na hodnotu 0 a každým vydaným potvrzením je zvýšen o 1. Po dosažení maxima nelze čítač resetovat, přičemž karty nepodporují hodnotu větší než

123 KAPITOLA B Úloha DES šifrování 109 B Úloha DES šifrování Zadání Seznamte se s funkcemi Java Card cryptography API. Doplňte zdrojový kód appletu DESUloha. Applet otestujte v aplikaci JavaCard Exercise Manager. Applet DESUloha se nachází ve stejnojmenném projektu. Otevřete projekt v NetBeans. AID package appletu je: C9002 AID instance appletu je: C Applet realizuje šifrování a dešifrování appletu zaslaných dat algoritmem DES v režimu ECB bez formátování paddingem. Byty klíče jsou uloženy v poli jako instanční proměnná appletu. Applet šifruje otevřený text v podobě 8-bytového bloku zaslanému appletu. Dešifrování probíhá také nad 8-bytovým blokem šifrového textu, který je zaslán appletu na kartě. Třída instrukcí je 0x80. Instrukce pro šifrování má kód 0x10. Nevyužívá žádné parametry. Je v ní zasláno 8 bytů otevřeného textu, které applet v odpovědi vrátí zašifrované. Instrukce pro odšifrování má kód 0x20. Nevyužívá žádné parametry. Je v ní zasláno 8 bytů šifrového textu, které applet v odpovědi vrátí dešifrované. Ve zdrojovém kódu appletu jsou některé části kódu nahrazeny #######. Tyto části nahraďte metodami, názvy tříd či proměnnými tak, aby applet vykonával požadovanou funkčnost. Nápovědou je dokument Popis Java Card cryptography API, javadoc Java Card API, v některých případech lze skrytou část odvodit z jiných podobných metod jinde v appletu použitých. Po doplnění zdrojového kódu appletu, applet zkompilujte pomocí položky 'build' v menu projektu. Applet následně volbou 'Convert' v menu projektu zkonvertujte. Pomocí plug-inu JavaCard Manager na kartu nahrajte soubor vzniklý konverzí desuloha.cap, který se nachází v adresáři javacard_dist v kořenovém adresáři projektu. (V adresáři javacard_dist se nachází celá struktura package appletu a.cap soubor na jejím konci.) Testování v aplikaci JavaCard Exercise Manager Musí být vybrána záložka 'DES šifrování'.

124 110 KAPITOLA B Úloha DES šifrování Do pole označeného jako 'data k šifrování' v záložce 'DES šifrování' vyplňte 8 bytů dat (pozn. jeden byte je zobrazen dvěma hexadecimálními čísly). Stisknutím tlačítka 'šifrovat na pc' dojde ke kontrolnímu výpočtu DES šifry na PC.