}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Užití cˇ ipové karty ke generování a správˇe šifrovacích klíˇcu˚ ˇ B AKALÁ RSKÁ PRÁCE
Viktor Spáˇcil
Brno, jaro 2009
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: Mgr. Roman Žilka ii
Shrnutí Cílem této bakaláˇrská práce je proniknout do oblasti cˇ ipových karet, seznámit se s jejich fungováním a naprogramovat doprovodnou aplikaci. Tato aplikace bude uživateli poskytovat možnost šifrování a dešifrování vybraných souboru˚ uložených na poˇcítaˇci za použití cˇ ipové karty.
iii
Klíˇcová slova smart card, cˇ ipová karta, .NET Smart Card Framework, Microsoft .NET Framework, C#, šifrování, dešifrování, AES, Rijndael
iv
Obsah 1 2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Použité nástroje a hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ Cipové karty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Rozdˇelení cˇ ipových karet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Kontaktní cˇ ipové karty . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Bezkontaktní cˇ ipové karty . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Duální cˇ ipové karty . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 USB cˇ ipové karty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ 2.3.1 Cipová karta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Operaˇcní systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Bˇehové prostˇredí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Zavadˇecˇ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gemalto .NET Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Odlišnosti .NET Smart Card Frameworku . . . . . . . . . . . . . . . . . . . . 3.2 Obsah cˇ ipové karty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Pˇrehled rolí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Souborový systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Profil cˇ ipové karty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Common Language Runtime (CLR) . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Garbage collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Správa životního cyklu aplikací . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Správa aplikaˇcní domény . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aplikace doprovázející bakaláˇrskou práci . . . . . . . . . . . . . . . . . . . . . . 4.1 Požadavky kladené na aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Návrh aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Kontextový diagram (úrovenˇ 0) . . . . . . . . . . . . . . . . . . . . . . 4.2.2 DFD (úrovenˇ 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 DFD (úrovenˇ 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Serverová cˇ ást aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Poskytované funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.1 Generování šifrovacího klíˇce a inicializaˇcního vektoru (IV) 4.3.1.2 Uložení šifrovacího záznamu . . . . . . . . . . . . . . . . . . 4.3.1.3 Získání záznamu pro dešifrování . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 3 3 4 5 5 5 6 6 6 8 8 9 9 10 10 10 13 13 14 14 15 15 16 17 18 18 18 20 20 21 21 22 22 23 23 23 25 25 v
4.3.1.4 Výpis všech uložených záznamu˚ . . . . . . . . . . . 4.3.1.5 Smazání vybraného záznamu/vybraných záznamu˚ 4.3.1.6 Ovˇerˇ ení hesla . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.7 Naˇctení záznamu˚ ze záložního souboru . . . . . . . 4.4 Klientská cˇ ást aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Poskytované funkce . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1.1 Šifrování . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1.2 Výpoˇcet hashe souboru . . . . . . . . . . . . . . . . . 4.4.1.3 Dešifrování . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 GUI – grafické uživatelské rozhraní . . . . . . . . . . . . . . . 4.5 Nástroj pro inicializaci záložního souboru . . . . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah pˇriloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
26 26 27 27 27 28 28 29 29 29 31 33 34 35
vi
Kapitola 1
Úvod Bezpeˇcnost se poslední dobou stává v oblasti informaˇcních technologií stále více sklonovaˇ ným pojmem. Pˇredevším pak v situacích, kdy se pracuje s velice citlivými informacemi, jakými jsou napˇríklad osobní údaje nebo bankovní záznamy. Vždy budou existovat lidé, kteˇrí tyto informace chtˇejí získat a zneužít je ve svuj ˚ vlastní prospˇech. Proto musí být vynalézány stále nové a nové metody zabezpeˇcení, aby riziko odcizení a zneužití tˇechto informací bylo co nejmenší. Právˇe z tohoto duvodu ˚ pˇrišly na scénu i cˇ ipové karty. Ty jsou tu s námi již 40 let, bˇehem nichž prošly nutným vývojem, aby se pˇrizpusobily ˚ mˇenícím se bezpeˇcnostním požadavkum, ˚ až do podoby, jakou známe dnes. V souˇcasnosti nacházejí cˇ ipové karty uplatnˇení v celé rˇ adˇe oblastí. Používají se napˇríklad ve zdravotnictví, ve finanˇcní sféˇre nebo k zajištˇení poˇcítaˇcové bezpeˇcnosti. Do budoucna se objevují i plány, ve kterých by jedna cˇ ipová karta zcela nahradila obˇcanský prukaz, ˚ rˇ idiˇcský prukaz, ˚ cestovní pas, kreditní kartu a mohla by ˇ zárovenˇ obsahovat i kompletní zdravotní záznamy držitele. V Ceské Republice je plánováno zahájení zkušebního provozu cˇ ipových karet, které budou zastupovat obˇcanský prukaz, ˚ popˇrípadˇe cestovní pas, na 1. cˇ ervenec roku 2010. V této bakaláˇrské práci se vˇenuji právˇe tématu cˇ ipových karet. Cílem práce je naprogramovat klientskou aplikaci, která bude provádˇet šifrování a dešifrování uživatelem zvolených souboru, ˚ které jsou uloženy na poˇcítaˇci, za pomoci šifrovacích klíˇcu, ˚ které budou generovány serverovou aplikací umístˇenou na cˇ ipové kartˇe. Ta bude zárovenˇ zajišt’ovat i bezpeˇcné ukládání tˇechto klíˇcu˚ na kartu. Následující druhá kapitola obsahuje obecné informace o cˇ ipových kartách. Seznámíme se zde s jejich historií a vývojem. Rovnˇež si pˇredstavíme jednotlivé existující druhy karet, jejich hardware a softwarovou výbavu. Závˇer kapitoly je vˇenován popisu zpusobu ˚ komunikace mezi cˇ teˇckou a cˇ ipovou kartou. V rámci tˇretí kapitoly se pˇresuneme z obecné roviny ke konkrétnímu typu cˇ ipové karty v podobˇe Gemalto .NET Smart Card. Programování pro tento typ karty je postaveno na .NET Smart Card Frameworku, který se odlišuje od klasického Microsoft .NET Frameworku. S tˇemito odlišnostmi se seznámíme hned v úvodu kapitoly. Dále si ukážeme, co všechno Gemalto .NET karta obsahuje, a jak lze k jejímu obsahu pˇristupovat. Pˇredstavíme si také bˇehové prostˇredí, které zajišt’uje bˇeh aplikací na .NET cˇ ipové kartˇe. ˇ Ctvrtá kapitola je vˇenována samotné aplikaci, jež doprovází bakaláˇrskou práci. Popíšeme si zde požadavky kladené na tuto aplikaci a seznámíme se s jejím návrhem v podobˇe 1
1.1. POUŽITÉ NÁSTROJE A HARDWARE DFD1 diagramu. ˚ Dále jsou ve cˇ tvrté kapitole podrobnˇe popsány serverová a klientská cˇ ást této aplikace a jejich jednotlivé poskytované funkce. U klientské cˇ ásti se navíc seznámíme s jejím GUI2 . Konec cˇ tvrté kapitoly je pak vˇenován nástroji sloužícímu k inicializaci záložního souboru, který je uložen na cˇ ipové kartˇe. Poslední kapitolu práce tvoˇrí závˇer, kde jsou shrnuty získané poznatky a dosažené výsledky. Dále následuje seznam literatury, ze které bylo cˇ erpáno. Souˇcástí práce je i pˇriložené CD, které obsahuje bakaláˇrskou práci v elektronické podobˇe a veškeré zdrojové kódy k doprovodné aplikaci.
1.1
Použité nástroje a hardware
Pro vývoj aplikace, která je souˇcástí a zárovenˇ stˇežejním bodem celé bakaláˇrské práce, byl použit Microsoft .NET Framework ve verzi 2.0 a .NET Smart Card Framework rovnˇež ve verzi 2.0. Nad samotnou platformou .NET lze použít celá rˇ ada programovacích jazyku, ˚ jako jsou napˇr. Visual Basic .NET, Object Pascal, J#, funkcionální jazyk F#, IronPython a v neposlední rˇ adˇe také programovací jazyk C#. Právˇe ten byl zvolen pro naprogramování celé aplikace, což bylo dáno již samotným zadáním bakaláˇrské práce. Jazyk C# byl vyvinut, stejnˇe jako .NET Framework, firmou Microsoft. Jedná se o vysokoúrovnový ˇ objektovˇe orientovaný jazyk, založený na jazycích C++ a Java. Za vývojové prostˇredí bylo zvoleno Microsoft Visual Studio ve starší verzi 2005, které bylo na rozdíl od novˇejší verze 2008 kompatibilní s pˇrídavným modulem Card Explorer. Card Explorer je souˇcástí .NET Smart Card Framework SDK3 a umožnuje ˇ správu obsahu karty pˇrímo z pohodlí vývojového prostˇredí. V rámci práce jsem pracoval s kontaktní cˇ ipovou kartou Gemalto .NET v2.0 a cˇ teˇckou cˇ ipových karet Gemplus PC Twin USB Smart Card Reader.
1. DFD – Data Flow Diagram, diagram datových toku. ˚ 2. GUI – Graphical User Interface, grafické uživatelské prostˇredí. 3. SDK – Software Development Kit, jedná se o sadu nástroju˚ sloužících k vývoji softwaru pro urˇcitou platformu.
2
Kapitola 2
ˇ Cipové karty V souˇcasné moderní a uspˇechané dobˇe se s cˇ ipovými kartami setkáváme témˇerˇ na každém kroku, aniž bychom si to uvˇedomovali. Používáme je napˇr. pˇri platbˇe v obchodech, pro vstup do budov cˇ i místností nebo v mobilních telefonech v podobˇe SIM karty. ˇ Cipové karty jsou velice cˇ asto oznaˇcovány jako smart card (tzv. „chytré“ karty) nebo karty s integrovaným obvodem1 [10], s. 4. Jedná se o malé pˇrenosné poˇcítaˇce s datovým úložištˇem. Konvenˇcní cˇ ipové karty mají stejný tvar i rozmˇer jako bˇežnˇe používané kreditní karty a jsou vybaveny kˇremíkovým cˇ ipem. Tento cˇ ip poskytuje pamˇet’ pro uložení dat, mikroprocesor pro manipulaci s tˇemito daty a nˇekdy bývá obsažen i kryptografický koprocesor, který je schopen provádˇet složité výpoˇcty spojené s kryptografickými operacemi. V praxi se mužeme ˚ rovnˇež setkat i s kartami, které obsahují pouze pamˇet’, popˇrípadˇe pamˇet’ a pˇredprogramovanou, pevnˇe danou logiku. Tento druh pamˇet’ových karet je schopen efektivnˇe uchovávat data, avšak nemuže ˚ s tˇemito daty nikterak manipulovat, jelikož neobsahuje mikroprocesor. Pamˇet’ové karty jsou proto závislé na hostitelské aplikaci, která je schopna provádˇet požadované operace s uloženými daty [4], s. 7. Nˇekdy se mužeme ˚ setkat s tím, že pojem smart card bývá vyhrazen pouze pro karty, které obsahují mikroprocesor a pojem cˇ ipová karta zahrnuje navíc i ryze pamˇet’ové karty [10], s. 4. Ve své práci používám kartu, které odpovídá oznaˇcení smart card, avšak oba dva výše uvedené pojmy budu v práci používat jako rovnocenné.
2.1
Historie
Pokud se chceme vˇenovat tématu cˇ ipových karet, mˇeli bychom se nejdˇríve dukladnˇ ˚ e seznámit s jejich historií. Díky nízké cenˇe syntetických materiálu, ˚ jako je PVC, došlo na poˇcátku padesátých let 20. století v USA k velkému rozšíˇrení plastových karet, které byly vhodné pro každodenní použití. Byly schopny velice dobˇre odolávat vlivu podnebí a mechanickému namáhání. První celoplastová platební karta se objevila v roce 1950. Vydal ji Diners Club a umožnovala ˇ lidem z vyšších spoleˇcenských kruhu˚ platit svým „dobrým jménem“ namísto penˇezi. Karta vešla ve známost jako „cestovní a zábavní“ karta. S pˇríchodem Visa a MasterCard do tohoto odvˇetví došlo k rapidnímu rozšíˇrení tzv. „plastových penˇez“ ve formˇe kreditních karet. Nejprve se tak událo na území USA, Evropa a zbytek svˇeta je následovali bˇehem nˇekolika let. 1.
V angliˇctinˇe oznaˇcované jako IC Card – Integrated Circuit Card.
3
ˇ ˇ 2.2. ROZD ELENÍ CIPOVÝCH KARET Hlavním úkolem tohoto druhu karet bylo poskytovat datové úložištˇe, které by bylo odolné vuˇ ˚ ci padˇelání. Avšak s postupným masovým rozšíˇrením došlo k tomu, že zabezpecˇ ení karet pˇrestalo být dostaˇcující. První vylepšení v této oblasti pˇredstavoval magnetický proužek, jenž byl umístˇen na zadní stranˇe kreditní karty. Ovšem ani tento proužek nepˇredstavoval dostateˇcné rˇ ešení, jelikož zde uložená data mohl kdokoliv s patˇriˇcným vybavením cˇ íst, smazat nebo pˇrepsat. Dále následovalo použití PINu2 . Ten však mohl být z bezpeˇcnostních duvodu ˚ uložen pouze v terminálech nebo hostitelských systémech, ale ne v magnetickém proužku. Bylo tedy nutné navazovat online spojení se systémem hostitelského poˇcítaˇce, což pˇredstavovalo urˇcitou režii v podobˇe pˇrenosu dat a rovnˇež pˇrinášelo nezanedbatelné finanˇcní náklady. Právˇe snaha snížit finanˇcní náklady vedla k hledání rˇ ešení, které by umožnilo provádˇet karetní transakce offline. V tuto chvíli pˇrichází na scénu smart card. Termín smart card poprvé použil v roce 1980 francouzský publicista Roy Bright. Samotná cˇ ipová karta však byla vynalezena daleko dˇríve a to pˇredevším díky enormnímu pokroku v rozvoji mikroelektroniky v sedmdesátých letech 20. století. Ten umožnil integrovat datové úložištˇe a mikroprocesor do kˇremíkového cˇ ipu, který zabíral plochu pouze nˇekolika málo cˇ tvereˇcných milimetru. ˚ Právˇe myšlenka zaˇclenit takovýto integrovaný obvod do identifikaˇcní karty se objevila v roce 1968 u dvou nˇemeckých inženýru, ˚ byl to Jürgen Dethloff a Helmut Gröttrup, kteˇrí si podali žádost o nˇemecký patent v únoru roku 1969. Ten byl pˇrijat v roce 1982, jedná se konkrétnˇe o patent DE 19 45 777 C3, pod názvem „Identifikanden/Identifikationsschalter“. Nezávisle na nich si v Japonsku v kvˇetnu roku 1970 požádal Kunitaka Arimura z Arimura Technology Institute o registraci stejného patentu, který se však vztahoval pouze na území Japonska. Hned v bˇreznu 1971 následovala americká patentová žádost s názvem „Information Card“, kterou podal Paul Castrucci z IBM. Ta byla pod oznaˇcením U.S. Patent 3,702,464 uznána 7. listopadu 1972. První skuteˇcný pokrok ve vývoji v této oblasti však pˇrichází až v rozmezí let 1974–1979, kdy si nechává francouzský novináˇr Roland Moréno registrovat celkem 47 patentu˚ týkajících se cˇ ipových karet v 11 zemích svˇeta a zárovenˇ zakládá francouzskou spoleˇcnost Innovatron, skrze kterou poskytuje licence dalším výrobcum. ˚ Více informací o historii cˇ ipových karet nalezneme v [5], s. 2–5, [11], s. 2–3, [6], s. 3–4.
2.2
Rozdˇelení cˇ ipových karet
Nyní se již mužeme ˚ pˇresunout z historie do souˇcasnosti, kde se moderní cˇ ipové karty dˇelí do dvou základních skupin: •
Kontaktní cˇ ipové karty
•
Bezkontaktní cˇ ipové karty
Mužeme ˚ se setkat i s dalšími druhy cˇ ipových karet, jako jsou: • 2.
Duální cˇ ipové karty (nˇekdy oznaˇcované jako hybridní cˇ ipové karty) PIN – Personal Identification Number.
4
ˇ ˇ 2.2. ROZD ELENÍ CIPOVÝCH KARET •
USB cˇ ipové karty
2.2.1
Kontaktní cˇ ipové karty
Kontaktní cˇ ipová karta má na svém tˇele umístˇenu plochu o rozmˇerech kolem 1 cm2 , která obsahuje 6 až 8 pozlacených kontaktu˚ (viz Obrázek 2.1). Prostˇrednictvím této plochy a skrze cˇ teˇcku cˇ ipových karet jsme schopni realizovat komunikaci se samotnou kartou. Karta neobsahuje vestavˇený zdroj pro vlastní napájení, které tudíž probíhá prostˇrednictvím cˇ teˇcky [13].
Obrázek 2.1: Kontaktní plocha v jedné ze svých podob, v tomto pˇrípadˇe nese 8 pozlacených kontaktu˚ (pˇrevzato z [13]) Kontaktní cˇ ipové karty lze dále rozdˇelit dle základních technických charakteristik na: [8] •
Karty ryze pamˇet’ové
•
Karty s chránˇenou pamˇetí
•
Standardní procesorové karty
•
Procesorové karty s kryptografickým koprocesorem
2.2.2
Bezkontaktní cˇ ipové karty
Bezkontaktní cˇ ipová karta nenese na svém tˇele kontaktní plochu. Komunikace mezi cˇ teˇckou a kartou probíhá prostˇrednictvím antény, která je zabudována v samotné kartˇe i cˇ teˇcce, a technologie RFID3 . Bezkontaktní cˇ ipová karta, stejnˇe jako kontaktní cˇ ipová karta, neobsahuje zdroj pro vlastní napájení, avšak je schopna získávat si energii právˇe z radiofrekvenˇcního signálu. Tento druh karet lze v mnoha pˇrípadech používat i bez toho, aniž bychom je byli nuceni vytáhnout z kapsy cˇ i penˇeženky [11], s. 8–9. Bezkontaktní cˇ ipové karty jsou definovány v standardu ISO/IEC 10536, parts 1,2,3, Identification cards – Contactless integrated circuit(s) cards – Close-coupled cards [4], s. 8. 2.2.3
Duální cˇ ipové karty
Jedná se o kombinaci kontaktní a bezkontaktní cˇ ipové karty. Duální karta obsahuje dvojici zcela samostatných integrovaných obvodu˚ – cˇ ipu, ˚ kdy jeden z nich je pˇrístupný skrze 3.
RFID – Radio Frequency Identification, technologie radiofrekvenˇcní identifikace.
5
2.3. HARDWARE kontaktní plochu na tˇele karty a druhý je pˇrístupný prostˇrednictvím zabudované antény a radiofrekvenˇcního signálu. Tato karta muže ˚ rovnˇež disponovat pouze jedním integrovaným obvodem, který podporuje obˇe dvˇe výše uvedená pˇrístupová rozhraní [11], s. 9. 2.2.4
USB cˇ ipové karty
USB cˇ ipová karta pˇrímo obsahuje rozhraní USB, kterým se jinak bˇežnˇe pˇripojuje cˇ teˇcka k hostitelskému poˇcítaˇci. Tento druh karet se výraznˇe rozmˇerovˇe liší od konvenˇcních cˇ ipových karet. Jedná se prakticky pouze o cˇ ip uzavˇrený do plastového pouzdra o velikosti ˇ cka není vubec klíˇce. Cteˇ ˚ vyžadována a cˇ ipovou kartu lze rovnou pˇripojit do USB portu hostitelského poˇcítaˇce. Alternativní využití elektrických kontaktu˚ cˇ ipové karty ve spojení s USB je popsáno v dodatku ke standardu ISO/IEC 7816-2 [4], s. 9.
2.3
Hardware
V následujícím textu práce se budeme vˇenovat výhradnˇe procesorovým kontaktním cˇ ipovým kartám, které jsou vybaveny kryptografickým koprocesorem. A to z toho duvodu, ˚ že Gemalto .NET karta, která je v rámci práce použita, spadá právˇe do této kategorie. Než pˇristoupíme k samotnému softwaru karty, mˇeli bychom se seznámit s jejím hardwarem. Fyzicky je cˇ ipová karta souˇcástí systému, který zahrnuje: •
Samotnou cˇ ipovou kartu
•
Rozhraní umožnující ˇ výmˇenu dat mezi cˇ ipovou kartou a aplikací bˇežící na hostitelském systému
2.3.1
ˇ Cipová karta
Konvenˇcní kontaktní cˇ ipová karta obsahuje vestavˇený integrovaný obvod a je formátu ID-1, který reprezentují následující rozmˇery: tloušt’ka: 0,76 mm ±0,08 mm; výška: 54 mm; délka: 85,6 mm; polomˇer zaoblení rohu: ˚ 3,18 mm ±0,30 mm. Kromˇe formátu ID-1 existují i formáty ID-00 (pomˇernˇe nový formát, také oznaˇcovaný jako „mini-card“) a ID-000 (formát pro mobilní SIM karty). Velikostní srovnání všech tˇrí formátu˚ mužeme ˚ vidˇet na Obrázku 2.2. Fyzickou podobou kontaktních cˇ ipových karet se zabývá standard ISO/IEC 7816-1, Identification Cards – Integrated Circuits(s) Cards with Contacts – Physical Characteristics [5], s. 28–31, [4], s. 7. Plastový povrch kontaktní cˇ ipové karty muže, ˚ v závislosti na tom, k cˇ emu je karta urcˇ ena, obsahovat celou rˇ adu prvku: ˚ [5], s. 31–44 •
Magnetický proužek
•
Podpis držitele, jméno držitele nebo jinou textovou informaci 6
2.3. HARDWARE
Obrázek 2.2: Porovnání trojice formátu˚ kontaktních cˇ ipových karet (pˇrevzato z [5], s. 31) •
Grafiku v podobˇe loga spoleˇcnosti nebo fotografii držitele v pˇrípadˇe identifikaˇcních karet
•
ˇ Cárový kód
•
Bezpeˇcnostní prvek napˇr. hologram, kinegram4
•
Samozˇrejmostí je pˇrítomnost kontaktní plochy
Nejduležitˇ ˚ ejší cˇ ást karty však tvoˇrí vestavˇený integrovaný obvod – cˇ ip, který se skládá z následujících cˇ ástí: [5], s. 8 •
Elektrické kontakty – jsou definovány standardem ISO/IEC 7816-2, Identification Cards – Integrated Circuits(s) Cards with Contacts – Dimensions and Location of the Contacts.
•
CPU (mikroprocesor) – ve vˇetšinˇe cˇ ipových karet se objevuje 8bit nebo 16bit mikroprocesor, zpravidla využívající instrukˇcní sadu Motorola 6805 nebo Intel 8051 a pracující na frekvenci až 5 MHz.
•
Kryptografický koprocesor – zajišt’uje složité výpoˇcty spojené s kryptografickými operacemi.
•
Tˇri druhy pamˇetí:
4. Kinegram je speciální stˇríbrnolesklá metalizovaná fólie. Obraz kinegramu je tvoˇren linkami ruzného ˚ tvaru a hloubky. Pˇri zmˇenˇe úhlu dopadajícího svˇetla se obraz kinegramu postupnˇe mˇení a vytváˇrí zdání pohyblivého obrazu.
7
2.4. SOFTWARE
2.3.2
–
RAM (Random Access Memory) – pamˇet’ s možností cˇ tení/zápisu. Slouží k docˇ asnému uložení zpracovávaných dat a její obsah je ztracen, pokud je pˇrerušeno napájení karty.
–
ROM (Read Only Memory) – pamˇet’ urˇcená pouze pro cˇ tení. Je zde uložen operaˇcní systém karty, permanentní data, permanentní aplikace. Obsah pamˇeti ROM je zachován i v pˇrípadˇe, že je pˇrerušeno napájení karty.
–
EEPROM (Electrically Erasable Programmable Read Only Memory) – stálá pamˇet’ urˇcená pro cˇ tení/zápis. Slouží jako datové úložištˇe a lze ji pˇrirovnat k pevnému disku u osobních poˇcítaˇcu. ˚ Má omezenou životnost na cca 100 000 zapiˇ sovacích cyklu˚ a dokáže udržet uložená data po dobu až deseti let. Ctení z EEPROM je stejnˇe rychlé jako cˇ tení z pamˇeti RAM, avšak zápis je až tisíckrát pomalejší. Její obsah je, stejnˇe jako obsah pamˇeti ROM, zachován i v pˇrípadˇe, že bylo pˇrerušeno napájení karty. V souˇcasné dobˇe zaˇcíná být postupnˇe nahrazována pamˇetí typu flash [6], s. 16.
Rozhraní
Nejbˇežnˇejší používané rozhraní pro propojení kontaktní cˇ ipové karty a hostitelského poˇcíˇ cka povˇetšinou pˇredstavuje samostatné zaˇrízení, ale muže taˇce je cˇ teˇcka cˇ ipových karet. Cteˇ ˚ být i zabudovaná napˇríklad v klávesnici nebo v notebooku. Jako samostatné externí zaˇrízení je nejˇcastˇeji pˇripojena k hostitelskému poˇcítaˇci skrze sériový port nebo port USB. Komunikací mezi cˇ ipovou kartou a cˇ teˇckou se budeme zabývat v podkapitole 2.5.
2.4
Software
Od hardwaru cˇ ipové karty se nyní pˇresuneme k popisu jejího softwaru. Na moderní cˇ ipové kartˇe se nachází nˇekolik duležitých ˚ softwarových komponent: •
Operaˇcní systém
•
Aplikace
Následující dvˇe komponenty se nacházejí pouze v cˇ ipových kartách obsahujících interpret. Jedná se o: •
Bˇehové prostˇredí
•
Zavadˇecˇ
8
2.4. SOFTWARE 2.4.1
Operaˇcní systém
Operaˇcní systém cˇ ipové karty zcela urˇcitˇe nenabízí takovou funkcionalitu, jakou známe napˇríklad z desktopových operaˇcních systému˚ Windows nebo UNIX. Jedná se o systém založený na pˇríkazech, na nˇež je karta schopna reagovat [11], s. 23. Tento systém je zodpovˇedný pˇredevším za rˇ ízení komunikace a pamˇet’ových operací mezi cˇ ipem a aplikací, která bˇeží na cˇ ipové kartˇe. Zajišt’uje však také správu souborového systému, a pokud karta obsahuje i kryptografický koprocesor, potom muže ˚ operaˇcní systém poskytovat i rozhraní pro kryptografický hardware [4], s. 9. Z pohledu vytváˇrení specifických aplikací mužeme ˚ rozdˇelit cˇ ipové karty na: [8] •
Karty založené na otevˇrené platformˇe. Pojem otevˇrená platforma znamená, že na kartu mohou být zavádˇeny aplikace tˇretích stran nezávisle na výrobci operaˇcního systému. Mezi nejznámˇejší otevˇrené platformy patˇrí:
•
–
Java Card
–
Multos
–
Windows for Smart Cards
Karty s proprietárním operaˇcním systémem. Ten je opakem otevˇrené platformy. V tomto pˇrípadˇe jsou poskytována samotným výrobcem operaˇcního systému pouze jeho vlastní aplikaˇcní rˇ ešení.
2.4.2
Aplikace
Dˇríve se aplikace pro cˇ ipové karty vyvíjely pro konkrétní typ použitého cˇ ipu, povˇetšinou v jazyce C. Takto vytvoˇrené aplikace byly posléze zavedeny do cˇ ipu bˇehem jeho výroby a nebylo možné je pozdˇeji nikterak modifikovat. Tento zpusob ˚ vývoje aplikací pˇrinášel mnohá úskalí. Pˇredevším se jednalo o problémy spojené s pˇrenositelností aplikace na jiný typ cˇ ipu, kdy musela být aplikace cˇ asto v mnoha ohledech pˇrepracována. V devadesátých letech 20. století však pˇrišla zmˇena v podobˇe Java Card. Tato platforma v sobˇe obsahuje interpret jazyka Java a pˇredstavuje významný krok kupˇredu v oblasti cˇ ipových karet. Vývojáˇri tak mohou vytváˇret aplikace pˇrímo v jazyce Java a již nejsou omezeni specifickým hardwarem cˇ ipu. Java aplikace mohou být na kartu libovolnˇe nahrávány, jsou zde uloženy ve stálé, pˇrepisovatelné pamˇeti, což zajišt’uje jejich snadnou správu. .NET karta obsahuje interpret jazyka CIL5 , což umožnuje ˇ vyvíjet aplikace urˇcené pro tuto kartu za použití standardu ECMA-3356 (viz podkapitola 3.4) [4], s. 10. 5. 6.
CIL – Common Intermediate Language. ECMA-335 – více informací zde [3].
9
2.5. KOMUNIKACE 2.4.3
Bˇehové prostˇredí
Bˇehové prostˇredí je právˇe tou komponentou, která obsahuje interpret. Je zodpovˇedné za bˇeh aplikací na cˇ ipové kartˇe, a jelikož aplikace ke svému bˇehu potˇrebují patˇriˇcné knihovny, tak i ty jsou souˇcástí tohoto prostˇredí. V pˇrípadˇe Java Card obsahují knihovny definice typu˚ a metod, které jsou obsaženy v Java Card API. Knihovny na .NET kartˇe pˇredstavují podmnožinu knihoven ECMA-335 standardu [4], s. 10. 2.4.4
Zavadˇecˇ
Vzhledem k tomu, že na kartu mohou být nahrávány nové aplikace, pak musí existovat i zavádˇecí program, který bude tuto cˇ innost obstarávat. Ten je zárovenˇ odpovˇedný i za odstranování ˇ aplikací z karty [4], s. 10.
2.5
Komunikace
V této chvíli jsme již obeznámeni s tím, z cˇ eho se karta skládá a jaké softwarové komponenty obsahuje. Poslední cˇ ást této kapitoly o cˇ ipových kartách bude vˇenována popisu komunikace mezi dvojicí cˇ ipová karta–ˇcteˇcka. Celý proces komunikace je zahájen vložením cˇ ipové karty do cˇ teˇcky. V tomto momentˇe je karta resetována a první informací, kterou pošle cˇ teˇcce nazpˇet, je ATR7 . ATR je definováno v ISO/IEC 7816-3 a obsahuje celou skupinu údaju, ˚ jež specifikují, jak bude probíhat následující komunikace. Po dokonˇcení resetování je ATR nadále uloženo na kartˇe pro pˇrípad, že by bylo nˇekdy pozdˇeji vyžadováno [2], s. 1. Samotná komunikace mezi cˇ teˇckou a cˇ ipovou kartou je realizována pomocí protokolu APDU8 , což je protokol aplikaˇcní vrstvy, který je popsán v standardu ISO/IEC 7816-4. Jedná se o komunikaci formou výmˇeny zpráv typu pˇríkaz–odezva (command–response), kdy APDU pˇríkaz je zasílán cˇ teˇckou a karta na nˇej reaguje patˇriˇcnou APDU odezvou [11], s. 111.
Obrázek 2.3: Struktura APDU pˇríkazu (pˇrevzato z [11], s. 112) 7. 8.
ATR – Answer To Reset. APDU – Application Protocol Data Unit.
10
2.5. KOMUNIKACE APDU pˇríkaz (viz Obrázek 2.3) se skládá z hlaviˇcky (povinná cˇ ást) a tˇela (nepovinná cˇ ást), pˇriˇcemž každá z tˇechto cˇ ástí je dále rozdˇelena do nˇekolika dalších polí. Hlaviˇcka obsahuje pole: CLA9 , INS10 , P1 a P211 . CLA slouží k rozlišení mezi pˇríkazy popsanými v ISO/IEC 7816-4 a proprietárními pˇríkazy použitého operaˇcního systému. INS reprezentuje kód konkrétního pˇríkazu a pole P1 a P2 dále blíže specifikují tento pˇríkaz. Tˇelo muže ˚ mít promˇenlivou délku i strukturu. Jeho úkolem je zprostˇredkovat požadovanou informaci kartˇe v rámci APDU pˇríkazu, nebo naopak prostˇrednictvím APDU odezvy poskytnout informaci cˇ teˇcce. Tˇelo APDU pˇríkazu obsahuje pole Lc12 , jež nese údaj o poˇctu bytu˚ obsažených v datovém poli, které mají být pˇreneseny na cˇ ipovou kartu. Le13 pole naopak udává poˇcet bytu˚ datového pole, jenž je oˇcekáván cˇ teˇckou od karty v rámci APDU odezvy. Standard ISO/IEC 7816-4 definuje cˇ tyˇri následující typy APDU pˇríkazu: ˚ [11], s. 111–112 1 Pˇríkaz, kdy nejsou pˇrenášena žádná data na kartu nebo z karty, obsahuje pouze hlaviˇcku. 2 Pˇríkaz, kdy jsou pˇrenášena data pouze z karty na cˇ teˇcku, obsahuje hlaviˇcku a tˇelo s definovaným Le polem. 3 Pˇríkaz, kdy jsou pˇrenášena data pouze z cˇ teˇcky na kartu, obsahuje vše kromˇe Le pole. 4 Pˇríkaz, kdy jsou data pˇrenášena v obou smˇerech, obsahuje kompletní hlaviˇcku i tˇelo.
Obrázek 2.4: Struktura APDU odezvy (pˇrevzato z [11], s. 112) APDU odezva (viz Obrázek 2.4) se skládá z tˇela (nepovinná cˇ ást) a dvou polí SW1 a SW214 (povinná cˇ ást), ale již neobsahuje hlaviˇcku. Tˇelo muže, ˚ ale také nemusí v pˇrípadˇe výskytu chyby nebo v závislosti na APDU pˇríkazu, obsahovat datové pole, které nese data v rámci odezvy zpˇet ke cˇ teˇcce. Velikost datového pole je specifikována Le polem v APDU pˇríkazu. SW1 a SW2 tvoˇrí návratový kód (viz Obrázek 2.5), prostˇrednictvím nˇehož je cˇ teˇcce sdˇeleno, zda vznikla pˇri zpracování zaslaného APDU pˇríkazu chyba nebo byl naopak pˇríkaz proveden v poˇrádku [11], s. 113. Pro pˇrenos APDU zpráv se využívá transportní protokol definovaný v standardu ISO/IEC 7816-3. Datové struktury, které jsou takto pˇrenášeny, jsou oznaˇcovány jako TPDU15 . Nejˇcas9. 10. 11. 12. 13. 14. 15.
CLA – Class byte. INS – Instruction byte. P1 a P2 – Parameter bytes. Lc – Length command. Le – Length expected. SW1 a SW2 – Status Words. TPDU – Transport Protocol Data Unit.
11
2.5. KOMUNIKACE
Obrázek 2.5: Návratové kódy tvoˇreny byty SW1 a SW2 (pˇrevzato z [11], s. 113) tˇeji využívanými transportními protokoly v oblasti cˇ ipových karet jsou protokoly s oznacˇ ením T=0 a T=1. T=0 je bytovˇe orientovaný, což znamená, že nejmenší pˇrenositelnou jednotku pˇredstavuje jeden byte. T=1 je naopak blokovˇe orientovaný a nejmenší pˇrenášenou jednotkou je sekvence bytu, ˚ cˇ ímž je umožnˇena i vyšší pˇrenosová rychlost oproti T=0 [12]. Oba zmínˇené protokoly jsou poloduplexní, jsou tedy schopny v daném cˇ asovém okamžiku pˇrenášet data vždy pouze jedním smˇerem.
12
Kapitola 3
Gemalto .NET Smart Card V pˇredchozích kapitolách jsme se seznámili s cˇ ipovými kartami v obecném mˇerˇ ítku. Nyní se pˇresuneme ke konkrétnímu typu kontaktní cˇ ipové karty v podobˇe Gemalto .NET Smart Card. Gemalto .NET karta byla pˇredstavena v roce 2002 a pˇredstavuje vubec ˚ první implementaci .NET Frameworku urˇceného pro cˇ ipové karty. Ten sice vznikl na popud firmy Microsoft jako reakce na stále se rozšiˇrující platformu Java Card, ale byl vytvoˇren firmou HiveMinded, která se ve své dobˇe zabývala použitím technologie .NET v malých vestavˇených zaˇrízeních [7].
3.1
Odlišnosti .NET Smart Card Frameworku
.NET Smart Card Framework je v mnoha ohledech velice podobný klasickému Microsoft .NET Frameworku, avšak v nˇekterých aspektech se pˇresto liší. Tyto aspekty chci zmínit v této cˇ ásti práce. Omezení pramenící z tˇechto odlišností nás totiž nˇekdy mohou limitovat pˇri vývoji aplikací urˇcených pro .NET cˇ ipové karty.
1.
•
.NET Smart Card Framework obsahuje bˇehové prostˇredí CLR1 optimalizované pˇrímo pro rˇ ízení bˇehu aplikací na cˇ ipové kartˇe.
•
CLR nepodporuje implicitní typy.
•
Definuje speciální binární formát pro aplikace, které mají být nahrány na kartu. Tento formát je daleko úspornˇejší než klasický .NET formát a lépe proto vyhovuje omezením, která jsou kladena na cˇ ipovou kartu.
•
.NET Smart Card Framework byl speciálnˇe navržen pro práci s pamˇet’ovým modelem nacházejícím se na cˇ ipové kartˇe. Aplikace je zde uložena ve stálé pamˇeti a je aktivována až ve chvíli, kdy je volána nˇekterou z externích aplikací.
•
Datové typy, které pracují s plovoucí desetinou cˇ árkou, nejsou dovoleny.
•
Vícerozmˇerná pole nejsou podporována, stejnˇe tak i pole s dolní hranicí jinou než nula. CLR – Common Language Runtime.
13
ˇ 3.2. OBSAH CIPOVÉ KARTY •
Nepodporuje Reflection, což je schopnost umožnující ˇ získávat informace o objektech za bˇehu.
•
.NET Smart Card Framework neumožnuje ˇ práci s vlákny.
•
Nejsou podporována asynchronní volání. Pokud tedy máme funkci, po které následuje nˇejaký další spustitelný kód, pak muže ˚ být tento kód proveden až ve chvíli, kdy je volání funkce kompletnˇe dokonˇceno.
•
a další. . . [4], s. 19–22
3.2
Obsah cˇ ipové karty
Gemalto .NET karta obsahuje výše zmínˇený .NET Smart Card Framework, za kterým si mužeme ˚ pˇredstavit jeho knihovny a bˇehové prostˇredí CLR, jemuž je vˇenována samostatná podkapitola 3.4. Dále na kartˇe nalezneme souborový systém, konfiguraˇcní soubory a servery. Servery pˇredstavují duležité ˚ on-card entity v rámci komunikace s cˇ ipovou kartou. Jejich úˇcel rozebereme pozdˇeji v oddíle 3.4.4. K nahlédnutí do obsahu karty slouží Card Explorer, jenž je souˇcástí .NET Smart Card Framework SDK. Card Explorer mužeme ˚ použít jako samostatný program nebo ho lze spustit jako zásuvný modul v rámci vývojového prostˇredí Microsoft Visual Studio 2005. Než se však dostaneme k samotnému obsahu karty, je nejprve nutné v Card Exploreru vybrat cˇ teˇcku cˇ ipových karet, do které je karta vložena, posléze zvolit roli, pod níž chceme k obsahu pˇristupovat, a zadat patˇriˇcné heslo. Tˇemito rolemi jsou admin, user a everyone. Na jejich základˇe je rozlišeno, k jakým cˇ ástem souborového systému mužeme ˚ pˇristupovat a do jakých složek nám bude umožnˇeno nahrávat své aplikace, datové soubory nebo nové knihovny. Card Explorer mimo jiné obsahuje záložky Explorer a Services. První z nich nám zobrazuje samotný souborový systém, což je pohled do EEPROM pamˇeti karty, a druhá poskytuje pˇrehled o službách/aplikacích, které právˇe bˇeží na cˇ ipové kartˇe. Vzhledem k tomu, že všechny aplikace bˇežící na kartˇe a jejich data jsou uchovávány v pamˇeti typu EEPROM, tak nejsou ovlivnˇeny ztrátou napájení, ke které dojde v okamžiku vyjmutí cˇ ipové karty ze cˇ teˇcky. 3.2.1
Pˇrehled rolí
•
Uživatel v roli admin má neomezený pˇrístup. Muže ˚ mazat staré soubory, nahrávat nové soubory, mazat a vytváˇret složky kdekoliv v systému souboru. ˚ Rovnˇež je schopen spustit a zastavit kteroukoliv službu/aplikaci na cˇ ipové kartˇe.
•
Uživatel v roli user smí manipulovat se soubory pouze ve složkách, které jsou oznacˇ eny jako public, a spravovat pouze ty služby/aplikace, jež jsou zde umístˇeny. Muže ˚ zde rovnˇež vytváˇret nové složky nebo mazat existující složky. 14
ˇ 3.3. PROFIL CIPOVÉ KARTY •
Uživatel v roli everyone nemá pˇrístup k souborovému systému, ale jen k pˇrehledu bˇežících služeb/aplikací. Nemá dostateˇcná práva pro zastavení bˇehu jakékoliv spuštˇené služby/aplikace.
3.2.2
Souborový systém
Souborový systém karty je rozdˇelen na dvˇe „diskové jednotky“ C: a D:2 [4], s. 14. Disk C: obsahuje tyto základní složky: •
Složku Gemalto – zde jsou uloženy knihovny a aplikace nahrané výrobcem.
•
Složku Pub – jedná se o jednu z public složek, kam uživatel v roli user muže ˚ zavádˇet své soubory a aplikace.
•
Složku System – zde jsou uloženy knihovny .NET Smart Card Frameworku (mscorlib.dll, system.xml.dll, SmartCard.dll), ale i jiné, které mají být pˇrístupny všem aplikacím na kartˇe. Disk D: obsahuje tyto základní složky:
•
3.3
Složku Pub, kde se nachází konfiguraˇcní soubor CardConfig.xml. V tomto souboru jsou uloženy informace, jako je dostupná komunikaˇcní rychlost karty, verze použitého cˇ ipu/karty/bˇehového prostˇredí nebo informace o podporovaných kryptografických algoritmech. Konfiguraˇcní soubor muže ˚ být zmˇenˇen pouze uživatelem v roli admin. Složka Pub je opˇet public.
Profil cˇ ipové karty
Profily jsou tvoˇreny knihovnami a specifikují množinu vlastností, kterou by mˇela obsahovat každá implementace CLI3 . CLI je definováno ve standardu ECMA-335 a umožnuje ˇ spouštˇet aplikace naprogramované ve vysokoúrovnových ˇ jazycích v ruzných ˚ prostˇredích bez potˇreby toho, aby musely být tyto aplikace pˇrepsány a pˇrizpusobeny ˚ unikátním charakteristikám tˇechto jednotlivých prostˇredí. Na implementaci CLI je založeno i .NET bˇehové prostˇredí CLR (viz podkapitola 3.4). V rámci .NET implementace CLI existují dva následující standardní profily: [3], s. 468–471 •
2. 3.
Profil jádra (Kernel profile) – pˇredstavuje minimální možnou implementaci CLI. Obsahuje tyto knihovny: Base Class Library, Runtime Infrastructure Library. Obstarává obsluhu výjimek, garbage collection, podporu programovacích struktur, tˇríd, rozhraní atd. Struktura souborového systému a obsah složek se muže ˚ u jednotlivých karet lišit. CLI – Common Language Infrastructure. Více informací zde [3].
15
3.4. COMMON LANGUAGE RUNTIME (CLR) •
Kompaktní profil (Compact profile) – rozšiˇruje funkcionalitu profilu jádra o možnost zpracování XML dat a umožnuje ˇ implementovat .NET v zaˇrízeních, jako jsou mobilní telefony nebo PDA. Je tvoˇren následujícími knihovnami: knihovny profilu jádra, XML Library, Network Library, Reflection Library.
V pˇrípadˇe .NET karet utváˇrejí knihovny .NET Smart Card Frameworku uložené v C:\System navíc ještˇe profil cˇ ipové karty. Ten umožnuje ˇ implementovat .NET v zaˇrízeních s malou velikostí pamˇeti RAM a EEPROM. Zaˇrízení tohoto typu zpravidla nedisponují uživatelským rozhraním a jsou vestavˇená. Profil cˇ ipové karty je tvoˇren celkem tˇremi knihovnami, z toho dvˇe jsou spoleˇcné s profilem jádra: Base Class Library, Runtime Infrastructure Library (mscorlib.dll, system.xml.dll), a jedna z knihoven je zamˇerˇ ena pˇrímo na cˇ ipové karty: Smartcard Library (SmartCard.dll) [4], s. 17. Vztah mezi jednotlivými profily a jejich knihovnami je zachycen na Obrázku 3.1.
Obrázek 3.1: Vztah mezi knihovnami a tˇremi .NET profily (pˇrevzato z [4], s. 17)
3.4
Common Language Runtime (CLR)
Nyní mužeme ˚ pˇristoupit k samotnému pˇredstavení bˇehového prostˇredí Common Language Runtime, které je, jak jsme si již dˇríve rˇ ekli, postaveno na implementaci CLI. CLR zajišt’uje bˇeh aplikací na cˇ ipové kartˇe v podobˇe bytekódu oznaˇcovaného též jako CIL, který je definován rovnˇež ve standardu ECMA-335. Aplikace urˇcené pro bˇeh na .NET kartách mohou být napsány v libovolném jazyce, jenž lze pˇreložit do CIL (viz Obrázek 3.2). Mezi takovéto jazyky patˇrí napˇríklad C#, J#, Visual Basic .NET, popˇrípadˇe ménˇe obvyklý IronPython, Oxygene, IronRuby a další. CLR obsažené na .NET kartˇe je plnˇe kompatibilní podmnožinou plnohodnotného .NET bˇehového prostˇredí s tím rozdílem, že je optimalizováno pˇrímo pro použití na cˇ ipových kartách. Má na starosti následující cˇ tyˇri pro nás nejduležitˇ ˚ ejší cˇ innosti: 16
3.4. COMMON LANGUAGE RUNTIME (CLR) •
Garbage collection
•
Správu životního cyklu aplikací
•
Správu aplikaˇcní domény
•
Remoting
Obrázek 3.2: Common Language Infrastructure (pˇrevzato z www:
)
3.4.1
Garbage collection
Programátor se nemusí starat o uvolnování ˇ pamˇeti, kterou již aplikace ke svému bˇehu nepotˇrebuje. Tento úkon je provádˇen automaticky právˇe pomocí garbage collection, jenž detekuje situace, kdy na objekty již nesmˇerˇ ují žádné platné odkazy. Maže tyto nepotˇrebné objekty a tím uvolnuje ˇ pro nˇe dˇríve alokovanou pamˇet’ [4], s. 30–31. 17
3.4. COMMON LANGUAGE RUNTIME (CLR) 3.4.2
Správa životního cyklu aplikací
Aplikace je rˇ ízena bˇehovým prostˇredím v rámci svého životního cyklu, který je tvoˇren celkem pˇeti etapami: [4], s. 23–24 •
Zavedení aplikace na kartu – jedná se o pouhé nahrání aplikace na kartu. Pˇred vlastním nahráním je aplikace pˇrevedena do binárního formátu (tzv. „card resident binary“), o kterém padla zmínka již v podkapitole 3.1.
•
Instalace aplikace – aplikace nahraná na kartˇe je registrována jako server a jsou registrovány i všechny její poskytované služby (viz oddíl 3.4.4 – Remoting).
•
Spuštˇení aplikace – pˇredstavuje interakci mezi aplikací na kartˇe a klientskou aplikací na PC (viz oddíl 3.4.4 – Remoting).
•
Ukonˇcení aplikace – zastavení a odregistrování všech služeb, které aplikace jako server poskytuje.
•
Odstranˇení samotné aplikace z karty.
3.4.3
Správa aplikaˇcní domény
Správa aplikaˇcní domény umožnuje ˇ souˇcasný bˇeh více aplikací na cˇ ipové kartˇe. Bezpeˇcnost a integrita každé takto bˇežící aplikace je zaruˇcena tím, že data z jedné aplikaˇcní domény nemohou pˇrímo odkazovat na data z jiné aplikaˇcní domény. Aplikaˇcní doménu si mužeme ˚ pˇredstavit jako logický ekvivalent k procesu ve Win32 aplikacích [4], s. 22. 3.4.4
Remoting
Remoting je pro nás nejduležitˇ ˚ ejší cˇ ástí této kapitoly. Popíšeme si zde komunikaci tak, jak je realizována na .NET cˇ ipových kartách. Využijeme zde i informace, jež byly zmínˇeny již dˇríve v podkapitole 2.5. Klasický remoting, který známe z .NET Frameworku, umožnuje ˇ komunikaci mezi dvˇema procesy, jež bˇeží na stejném poˇcítaˇci, popˇrípadˇe na dvou poˇcítaˇcích propojených pomocí lokální sítˇe nebo sítˇe Internet. .NET Smart Card Framework rozšiˇruje tento standardní remoting o možnost, kdy aplikace spuštˇená na PC muže ˚ komunikovat s procesem bˇežícím na cˇ ipové kartˇe nebo kdy je program v jedné aplikaˇcní doménˇe schopen pˇristupovat k datum ˚ procesu, který bˇeží v druhé aplikaˇcní doménˇe na kartˇe. Každá aplikace, kterou nahrajeme na kartu, pˇredstavuje server. Tím, že je aplikace na kartˇe nainstalována, dochází zde k registraci tohoto serveru a pˇredevším k registraci služeb, které poskytuje. Se serverovou aplikací komunikujeme právˇe prostˇrednictvím registrovaných služeb. Pod pojmem služba si pˇredstavme tˇrídu a její metody tak, jak je známe z objektových programovacích jazyku. ˚ Každá bˇežící služba je reprezentována unikátním URI4 . 4.
URI – Uniform Resource Identifier.
18
3.4. COMMON LANGUAGE RUNTIME (CLR) Klientská aplikace, bˇežící na PC, muže ˚ skrze URI a s pomocí dalších údaju˚ k tˇemto metodám pˇristupovat a volat je. Samotná komunikace mezi serverem a klientem probíhá prostˇrednictvím APDUClient kanálu na stranˇe klienta, APDUServer kanálu na stranˇe serveru a APDU protokolu (viz podkapitola 2.5). Každý z tˇechto kanálu˚ má registrován port, na kterém naslouchá, zda nepˇrišel APDU pˇríkaz pro patˇriˇcnou službu/odezva od patˇriˇcné služby bˇežící na kartˇe (viz Obrázek 3.3) [4], s. 24–28. Kompletní adresa, pomocí níž se odkazuje klientská aplikace na službu bˇežící na cˇ ipové kartˇe, má následující tvar: apdu://:<ˇ císlo portu registrované pro danou službu>/
Obrázek 3.3: Komunikace serveru a klienta prostˇrednictvím APDU kanálu a patˇriˇcného portu (pˇrevzato z [4], s. 25)
19
Kapitola 4
Aplikace doprovázející bakaláˇrskou práci V této kapitole a jejích podkapitolách se budeme vˇenovat stˇežejnímu bodu bakaláˇrské práce, který pˇredstavuje doprovodná aplikace. Nejprve se seznámíme s požadavky, které jsou na ni kladeny. Dusledné ˚ pochopení tˇechto požadavku˚ je velice duležité. ˚ Tuto fázi mužeme ˚ oznacˇ it za fázi analytickou. Vzhledem k tomu, že bakaláˇrská práce vznikla na popud jednoho z prumyslových ˚ partneru˚ Fakulty informatiky Masarykovy univerzity, jímž je firma Y Soft, a jádro aplikace bude potenciálnˇe využitelné v praxi, je nutné této fázi vˇenovat náležitou pozornost. Následnˇe si pˇredstavíme samotný návrh aplikace. Ten pˇredchází jejímu vlastnímu naprogramování a rovnˇež pˇredstavuje duležitou ˚ cˇ ást v procesu vývoje. Na vytvoˇrených diagramech si ukážeme jednotlivé cˇ ásti aplikace, zpusoby ˚ jejich vzájemné komunikace a roli uživatele ve vztahu k nim. V dalších cˇ ástech kapitoly si pak podrobnˇe rozebereme klientskou a serverovou cˇ ást aplikace a funkce, kterými disponují.
4.1
Požadavky kladené na aplikaci
Cílem bakaláˇrské práce bylo vytvoˇrit aplikaci sloužící k šifrování a dešifrování souboru˚ uložených na uživatelském poˇcítaˇci. Soubory mají být šifrovány pomocí šifrovacích klíˇcu, ˚ které jsou generovány a následnˇe ukládány v podobˇe šifrovacích záznamu˚ serverovou cˇ ástí aplikace, jež je umístˇena na cˇ ipové kartˇe. Serverová cˇ ást musí rovnˇež zajistit vyhledání odpovídajícího uloženého záznamu pro dešifrování. Hledání probˇehne na základˇe hashe vypoˇcítaného klientem ze zašifrovaného souboru. Pokud je odpovídající záznam na kartˇe nalezen, vrátí se klientské aplikaci, která pomocí nˇej provede samotné dešifrování souboru, a z karty je záznam následnˇe odstranˇen. Klientská cˇ ást aplikace bˇežící na PC musí poskytovat pˇrívˇetivé GUI, skrze které bude uživateli umožnˇeno provádˇet samotné šifrování/dešifrování vybraných souboru˚ a také správu záznamu˚ uložených na kartˇe. Správa záznamu˚ zahrnuje výpis všech na kartˇe uložených záznamu˚ a mazání již dále nepotˇrebných záznamu. ˚ Úkony jako dešifrování vybraných souboru˚ a výpis všech uložených záznamu˚ musí navíc vyžadovat po uživateli autentizaci v podobˇe hesla, které je nemˇenné a bude pevnˇe nastaveno v serverové cˇ ásti aplikace, jež provádí i jeho ovˇerˇ ení. Klientská aplikace musí být spustitelná pod operaˇcním systémem Windows XP1 nebo Windows Vista2 a bude stejnˇe jako serverová 1. 2.
Testováno na sestavˇe OS Microsoft Windows XP Professional SP3. Testováno na sestavˇe OS Microsoft Windows Vista Business Edition SP1.
20
4.2. NÁVRH APLIKACE cˇ ást naprogramována nad platformou .NET v programovacím jazyce C#. Komunikace mezi klientem a serverovou aplikací nemusí být zabezpeˇcena, jelikož se nepˇredpokládá fyzický pˇrístup potencionálního útoˇcníka k PC, na nˇemž klientská aplikace pobˇeží a k nˇemuž bude pˇripojena cˇ teˇcka s cˇ ipovou kartou.
4.2
Návrh aplikace
V této chvíli jsme již seznámeni se všemi požadavky, které jsou kladeny na aplikaci, a mu˚ žeme je promítnout do jejího samotného návrhu. Pod tímto pojmem si pˇredstavme jednotlivé procesy vyskytující se v aplikaci, komunikaci mezi tˇemito procesy, odezvy procesu˚ na události a pˇredávání rˇ ízení mezi procesy. K vytvoˇrení návrhu slouží celá rˇ ada nástroju˚ a modelovacích technik. Pro tento úˇcel jsem využil program CASE Studio a s jeho pomocí vytvoˇril návrh založený na datových tocích. Výstupem je sada DFD diagramu. ˚ 4.2.1
Kontextový diagram (úrovenˇ 0)
Kontextové DFD neboli kontextový diagram pˇredstavuje nejabstraktnˇejší pohled na aplikaci (viz Obrázek 4.1), která je na nˇem zobrazena jako jediný proces (ve skuteˇcnosti však obsahuje serverovou cˇ ást na kartˇe a klientskou cˇ ást na PC, které jsou dále tvoˇreny dalšími procesy). Úˇcelem tohoto diagramu je pˇredevším zobrazit okolní entity (v našem pˇrípadˇe uživatele), s nimiž aplikace komunikuje. Uživatel zasílá aplikaci následující požadavky: •
Požadavek na šifrování vybraného souboru – aplikace uživateli nazpˇet zasílá informaci, zda bylo šifrování úspˇešnˇe provedeno, popˇrípadˇe poskytuje chybové hlášení s vysvˇetlením, k jaké chybˇe bˇehem operace došlo. Šifrování není umožnˇeno, pokud se na kartˇe nachází uložen maximální poˇcet šifrovacích záznamu. ˚
•
Požadavek na dešifrování vybraného souboru – od aplikace pˇrichází informace úspˇechu cˇ i neúspˇechu dešifrovací operace. V pˇrípadˇe neúspˇechu obsahuje chybové hlášení s duvodem ˚ selhání.
•
Žádost o výpis všech uložených záznamu˚ – jestliže na kartˇe nejsou uloženy žádné záznamy, je o tom uživatel informován, v opaˇcném pˇrípadˇe je mu zobrazen výpis všech záznamu. ˚
•
Požadavek na smazání vybraného záznamu/vybraných záznamu˚ – aplikace opˇet oznamuje uživateli úspˇech cˇ i neúspˇechu této operace.
•
Heslo – je vyžadováno pro dešifrování souboru˚ a výpis všech na kartˇe uložených záznamu. ˚ Zpˇetnˇe je uživatel informován pouze v pˇrípadˇe, že zadáné heslo bylo nesprávné.
21
4.2. NÁVRH APLIKACE
Obrázek 4.1: Kontextový diagram (úrovenˇ 0) 4.2.2
DFD (úrovenˇ 1)
Jeho úkolem je zobrazit hlavní cˇ ásti navrhované aplikace, tedy její serverovou a klientskou cˇ ást (viz Obrázek 4.2). Od klienta putují k serverové aplikaci následující požadavky: •
Žádost na vygenerování šifrovacího klíˇce – serverová cˇ ást odpovídá jeho zasláním.
•
Šifrovací záznam urˇcený k uložení na kartˇe – záznam je bud’to úspˇešnˇe uložen nebo je v opaˇcném pˇrípadˇe klient informován o vniklé chybˇe.
•
Požadavek na získání patˇriˇcného dešifrovacího záznamu – v rámci reakce zasílá serverová aplikace klientovi dešifrovací záznam, pokud je však na kartˇe nalezen.
•
Požadavek na výpis všech uložených záznamu˚ – pokud karta obsahuje uložené záznamy, pak je jejich výpis zaslán zpˇet klientské aplikaci.
•
Uživatelem zadané heslo – serverová cˇ ást provede ovˇerˇ ení tohoto hesla a pošle výsledek ovˇerˇ ovací operace nazpˇet.
•
Žádost na smazání uživatelem vybraného záznamu/vybraných záznamu˚ – smazání záznamu˚ je bud’to úspˇešnˇe provedeno, nebo pokud dojde pˇri mazání k chybˇe, je o tom klient informován.
4.2.3
DFD (úrovenˇ 2)
DFD druhé úrovnˇe je posledním diagramem. Obsahuje dekompozici serverové a klientské cˇ ásti aplikace na jejich jednotlivé procesy. Zárovenˇ je zachycena vzájemná provázanost tˇechto procesu˚ (viz Obrázek 4.3). 22
ˇ 4.3. SERVEROVÁ CÁST APLIKACE
Obrázek 4.2: DFD (úrovenˇ 1)
4.3
Serverová cˇ ást aplikace
Od návrhu nyní pˇristoupíme k podrobnému pˇredstavení jednotlivých cˇ ástí aplikace a jejich funkcí. Jak už bylo rˇ eˇceno dˇríve, aplikace se skládá ze dvou hlavních cˇ ástí a to z cˇ ásti serverové umístˇené na cˇ ipové kartˇe a z cˇ ásti klientské, která bˇeží na PC. V této podkapitole se seznámíme s prvnˇe jmenovanou. Serverová cˇ ást je tvoˇrena dvˇema následujícími tˇrídami: •
Server – pˇredstavuje vstupní bod, jelikož obsahuje metodu Main(), která je volána ve chvíli, kdy dojde na kartˇe k instalaci aplikace. Její úlohou je zaregistrovat aplikaci na kartˇe jako server, registrovat APDUServer komunikaˇcní kanál pro pˇríjem APDU pˇríkazu˚ a odesílání APDU odezev a také registrovat URI všech poskytovaných služeb (viz oddíl 3.4.4 – Remoting), které v našem pˇrípadˇe pˇredstavuje pouze tˇrída CryptoService.
•
CryptoService – jedná se o nejduležitˇ ˚ ejší cˇ ást, jež po nainstalování aplikace pˇredstavuje na kartˇe bˇežící službu, k níž muže ˚ klient pˇristupovat (viz oddíl 3.4.4 – Remoting). Veškeré funkce poskytované serverovou cˇ ástí jsou zajišt’ovány právˇe touto tˇrídou.
4.3.1
Poskytované funkce
Nyní si postupnˇe pˇredstavíme jednotlivé nabízené funkce a také si pˇriblížíme jejich úˇcel ve spojení s klientskou aplikací. 4.3.1.1 Generování šifrovacího klíˇce a inicializaˇcního vektoru (IV) Mezi hlavní požadavky kladené na aplikaci patˇrí mimo jiné šifrování souboru, ˚ které probíhá na stranˇe klienta. Generování šifrovacího klíˇce ovšem zajišt’uje serverová cˇ ást (viz Obrázek 4.3). Jelikož je k šifrování použit algoritmus AES3 (Rijndael), musíme vygenerovat 3.
AES - Advanced Encryption Standard.
23
ˇ 4.3. SERVEROVÁ CÁST APLIKACE
Obrázek 4.3: DFD (úrovenˇ 2) klíˇc patˇriˇcné délky. V .NET Smart Card Frameworku k tomu slouží jmenný prostor System.Security.Cryptography, který obsahuje pˇrímo tˇrídu Rijndael. Generování pak probíhá následovnˇe: Rijndael rijndael = Rijndael.Create(); rijndael.GenerateKey();
Pokud nezadáme jinak, je nám vygenerován klíˇc o délce 256bit, což je i náš pˇrípad. AES algoritmus ovšem vyžaduje k šifrování i inicializaˇcní vektor (IV). Ten je vygenerován obdobným zpusobem: ˚ Rijndael rijndael = Rijndael.Create(); rijndael.GenerateIV();
Vygenerovaný IV je vždy délky 128bit. Obˇe tyto funkce (generování šifrovacího klíˇce a IV) jsou volány klientem ve chvíli, kdy je uživatelem zadán pˇríkaz k šifrování souboru. 24
ˇ 4.3. SERVEROVÁ CÁST APLIKACE 4.3.1.2 Uložení šifrovacího záznamu Pokud šifrování v klientské aplikaci probˇehne úspˇešnˇe, je kartˇe zaslán šifrovací záznam urˇcený k uložení. Záznam má následující formát: •
512bit hash zašifrovaného souboru
•
256bit šifrovací klíˇc
•
128bit inicializaˇcní vektor
•
Datum a cˇ as vzniku záznamu
•
Název zašifrovaného souboru
Velice specifické je pak uložení záznamu na kartˇe. Jsou k tomu použity dvˇe struktury. Jednou z nich je tzv. hashtable a druhou je textový soubor. Hashtable je definován ve jmenném prostoru System.Collections .NET Smart Card Frameworku a pˇredstavuje asociativní pole. Umožnuje ˇ tedy ukládat unikátní klíˇce a k nim asociované hodnoty. Každému záznamu (klíˇc–hodnota) v tomto poli odpovídá index, který je automaticky získán metodou GetHashCode() z klíˇce. Tato metoda je standardnˇe implementována pro všechny datové typy dˇedˇené ze tˇrídy Object. Pokud chceme pˇristupovat k hodnotˇe uložené v hashtablu, pak musíme poskytnout klíˇc, na který je opˇet automaticky zavolána metoda GetHashCode() a je vypoˇcítán index. Když je tento index v poli nalezen, tak je vrácena odpovídající hodnota. Jestliže je vyžádáno uložení šifrovacího záznamu, pak je v našem pˇrípadˇe za klíˇc zvolen hash zašifrovaného souboru a v rámci asociované hodnoty jsou uloženy šifrovací klíˇc, inicializaˇcní vektor, datum a cˇ as vzniku záznamu a název zašifrovaného souboru. Hashtable je použit jako primární ukládací struktura, jelikož právˇe díky použití klíˇcu˚ a hashovací funkce (metoda GetHashCode()) umožnuje ˇ v porovnání s textovým souborem témˇerˇ okamžitý pˇrístup k patˇriˇcné asociované hodnotˇe. Pro ukládání dat má hashtable alokovanou urˇcitou cˇ ást pamˇeti karty (EEPROM). Pokud je však aplikace na kartˇe zastavena, pak se garbage collection (viz oddíl 3.4.1 – Garbage collection) postará i o uvolnˇení této pamˇeti, cˇ ímž dojde k nenávratnému smazání všech uložených záznamu. ˚ Z tohoto duvod ˚ u˚ je zvoleno použití ještˇe druhé záložní ukládací struktury v podobˇe textového souboru. Ten je na kartˇe pˇrítomen i po ukonˇcení aplikace a pomocí funkce pro naˇctení záznamu˚ ze záložního souboru a nástroje pro inicializaci záložního souboru (viz podkapitola 4.5) mužeme ˚ všechny v nˇem uložené záznamy zpˇetnˇe nahrát do hashtablu v opˇetovnˇe spuštˇené serverové aplikaci. Jeden uložený záznam je v souboru reprezentován jedním rˇ ádkem. Vzhledem k pamˇet’ovým omezením cˇ ipové karty je dovoleno uložit do hashtablu, a tedy i do záložního souboru, maximálnˇe 20 záznamu. ˚ 4.3.1.3 Získání záznamu pro dešifrování Pro dešifrování nabízí serverová cˇ ást funkci sloužící k nalezení patˇriˇcného dešifrovacího záznamu v hashtablu. Ten je hledán na základˇe hashe zašifrovaného souboru, který je vy25
ˇ 4.3. SERVEROVÁ CÁST APLIKACE poˇcítán a zaslán klientskou aplikací. Pokud je pro daný hash nalezen záznam v hashtablu, pak je tento záznam poskytnut klientovi, který pomocí nˇej provede dešifrování souboru. Zárovenˇ je tento záznam z hashtablu odstranˇen a zmˇena je zanesena do záložního souboru. 4.3.1.4 Výpis všech uložených záznamu˚ Uživateli má být podle požadavku˚ kladených na aplikaci umožnˇena i správa uložených záznamu, ˚ která je možná ve chvíli, kdy je zobrazen jejich kompletní výpis skrze grafické uživatelské rozhraní klienta (viz oddíl 4.4.2). Tato funkce prochází všechny záznamy uložené v hashtablu a pˇrevádí je do následujícího formátu, v nˇemž jsou odeslány klientské aplikaci: •
Poˇradové cˇ íslo záznamu
•
Název zašifrovaného souboru
•
Datum a cˇ as vzniku záznamu
Jak si mužeme ˚ všimnout, není zobrazen hash souboru, šifrovací klíˇc ani inicializaˇcní vektor. Je tomu tak pˇredevším z bezpeˇcnostních duvod ˚ u˚ a rovnˇež proto, že se jedná o informace, které nemají pro uživatele žádnou vypovídající hodnotu. V grafickém uživatelském rozhraní je navíc skryto i poˇradové cˇ íslo záznamu, které slouží výhradnˇe v rámci aplikace k provázání vypsaných záznamu˚ se záznamy uloženými na kartˇe (viz Obrázek 4.5). 4.3.1.5 Smazání vybraného záznamu/vybraných záznamu˚ Uživatel si muže ˚ v zobrazeném výše uvedeném výpisu všech uložených záznamu˚ vybrat ty záznamy, které by chtˇel z karty odstranit (viz oddíl 4.4.2). Vybrané záznamy se prochází a získávají se jejich poˇradová cˇ ísla. Kolekce tˇechto cˇ ísel je posléze zaslána serverové aplikaci na kartˇe. Zde se pro jednotlivá poˇradová cˇ ísla zjistí jejich odpovídající uložený záznam, který je následnˇe smazán. Všechny provedené zmˇeny jsou rovnˇež promítnuty do záložního souboru. Ukázka zdrojového kódu: for (int x = 0; x < recordsNumbers.Length; x++) { int recordNumber = recordsNumbers[x]; records.Remove(hashMapping[recordNumber]); hashMapping.Remove(recordNumber); } saveChangesToFile();
Funkce zajišt’ující mazání záznamu˚ je navíc optimalizována. Optimalizace spoˇcívá v tom, že je rozlišeno, zda uživatel požaduje smazání pouze nˇekterých záznamu, ˚ kdy se použije kód uvedený výše, nebo všech na kartˇe uložených záznamu. ˚ Pokud je vyžádáno odstranˇení všech uložených záznamu, ˚ pak se volá odlišný kód, který jednoduše vymaže obsah celého hashtablu a odstraní záložní soubor: 26
ˇ 4.4. KLIENTSKÁ CÁST APLIKACE records.Clear(); File.Delete(filepath);
4.3.1.6 Ovˇerˇ ení hesla Pokud uživatel požaduje dešifrování vybraného souboru nebo výpis všech uložených záznamu, ˚ je po nˇem vyžadována autentizace v podobˇe hesla. Uživatelem zadané heslo je odesláno aplikaci na kartˇe. Zde je ovˇerˇ eno vuˇ ˚ ci heslu, které je napevno stanoveno ve zdrojovém kódu. Podle výsledku ovˇerˇ ení klientská aplikace reaguje povolením/zamítnutím požadované operace. 4.3.1.7 Naˇctení záznamu˚ ze záložního souboru Tato funkce je volána vždy, když dojde k prvotnímu spuštˇení aplikace na kartˇe. Souvisí s ní i použití nástroje pro inicializaci záložního souboru (viz podkapitola 4.5). Funkce si nejprve zkontroluje, zda je na kartˇe pˇrítomen záložní soubor. Pokud je nalezen, pak se po rˇ ádcích sekvenˇcnˇe prochází. Každý rˇ ádek je tvoˇren textovým rˇ etˇezcem, z nˇehož je potˇreba vyextrahovat jednotlivé cˇ ásti záznamu (hash zašifrovaného souboru, šifrovací klíˇc, inicializaˇcní vektor, datum a cˇ as vzniku záznamu, název zašifrovaného souboru). Získaný záznam je poté zaveden do hashtablu. Ukázka kódu, který zajišt’uje procházení záložního souboru a získání cˇ ástí záznamu z pˇreˇcteného rˇ ádku: while ((line = sr.ReadLine()) != null) { string fileHash = line.Substring(0, 88); string[] record = new string[4]; record[0] record[1] record[2] record[3]
= = = =
line.Substring(88, 44); line.Substring(132, 24); line.Substring(156, 19); line.Substring(175);
recordsInit.Add(fileHash, record); }
4.4
Klientská cˇ ást aplikace
Nejviditelnˇejší cˇ ástí z celé aplikace je pro uživatele samotný klient, který disponuje grafickým uživatelským rozhraním. Prostˇrednictvím nˇej je uživateli dovoleno provádˇet všechny úkony spojené s šifrováním/dešifrováním vybraných souboru˚ a rovnˇež se správou uložených záznamu. ˚ Klientská cˇ ást aplikace je tvoˇrena následujícími tˇrídami: •
Program – má obdobnou funkci jako tˇrída Server v serverové aplikaci. Rovnˇež obsahuje vstupní bod v podobˇe metody Main(), která v tomto pˇrípadˇe obstarává registraci APDUClient komunikaˇcního kanálu pro pˇríjem APDU odezev a odesílání APDU pˇríkazu. ˚ Zárovenˇ inicializuje a spouští GUI. 27
ˇ 4.4. KLIENTSKÁ CÁST APLIKACE •
Crypto – tato tˇrída, jak už její samotný název napovídá, zajišt’uje funkce spojené s kryptografickými operacemi šifrování a dešifrování.
•
CryptoApp – definuje vzhled hlavního okna aplikace a také obsluhuje jednotlivé události pro dané okno, jako jsou napˇr. stisk tlaˇcítka, zavˇrení okna, zobrazení okna s výpisem všech záznamu, ˚ zobrazení procházení souboru˚ atd.
•
ShowAllRecords – udává vzhled okna, kde je zobrazen výpis všech na kartˇe uložených záznamu, ˚ a rovnˇež obsluhuje jeho jednotlivé události (stisk tlaˇcítka, zavˇrení okna apod.).
•
Password – specifikuje vzhled okna, kam uživatel v pˇrípadˇe potˇreby zadává heslo, které je následnˇe odesláno k ovˇerˇ ení aplikaci na kartˇe. Opˇet obsluhuje události spojené s tímto oknem.
4.4.1
Poskytované funkce
Z oddílu 4.3.1 již máme urˇcitou pˇredstavu o funkcích, které poskytuje klientská cˇ ást. V této cˇ ásti práce si je projdeme podrobnˇeji. Všechny následující funkce spadají pod tˇrídu Crypto. 4.4.1.1 Šifrování Pro zašifrování uživatelem zvoleného souboru je zvolen symetrický šifrovací algoritmus AES (Rijndael). Jediný problém v pˇrípadˇe symetrického šifrování pˇredstavuje sdílený klíˇc, který je stejný pro šifrování i dešifrování a musí být peˇclivˇe zabezpeˇcen proti odcizení. V našem pˇrípadˇe je tento klíˇc uložen na kartˇe. Prolomení jejího zabezpeˇcení pˇredstavuje netriviální záležitost. AES je blokovou šifrou, která zpracovává data po blocích o velikosti 128bit. Pokud jsou data kratší, použije se tzv. „padding“ neboli doplnˇení dat na požadovanou délku. Používá se celá rˇ ada algoritmu, ˚ od primitivního doplnˇení nulami po složitˇejší schémata. V našem pˇrípadˇe byl pro „padding“ použit mechanismus podle PKCS #74 , který je vestavˇen pˇrímo v Microsoft .NET Frameworku. Za šifrovací mód je zvolen CBC5 . Ten funguje tak, že pˇred zašifrováním se odpovídající blok otevˇreného textu XORuje pˇredcházejícím blokem zašifrovaného textu. To znamená, že jednotlivé bloky jsou na sobˇe závislé, a aby bylo možné dešifrovat konkrétní blok, musí být dešifrovány i všechny bloky pˇredchozí. První blok se XORuje s náhodnˇe vygenerovaným blokem oznaˇcovaným jako inicializaˇcní vektor (IV) [1]. Abychom mohli pracovat s AES využijeme v tomto pˇrípadˇe jmenný prostor Microsoft .NET Frameworku System.Security.Cryptography a jeho tˇrídu RijndaelManaged. Následující kód ukazuje vytvoˇrení instance tˇrídy RijndaelManaged, nastavení paddingu a šifrova4. 5.
Více informací o PKCS #7 nalezneme v [9]. CBC – Cipher Block Chaining.
28
ˇ 4.4. KLIENTSKÁ CÁST APLIKACE cího módu. Klíˇc a IV poskytne serverová cˇ ást aplikace, když zavoláme její patˇriˇcné funkce (viz pododdíl 4.3.1.1): RijndaelManaged rijndael = new RijndaelManaged(); rijndael.Mode = CipherMode.CBC; rijndael.Padding = PaddingMode.PKCS7; rijndael.Key = service.generateKey(); rijndael.IV = service.generateIV();
Poté se prochází uživatelem zvolený soubor a je provedeno samotné šifrování a zápis do požadovaného výstupního souboru. 4.4.1.2 Výpoˇcet hashe souboru Pokud probˇehne celá operace šifrování v poˇrádku, je vypoˇcítán hash zašifrovaného souboru a vytvoˇren šifrovací záznam, který je odeslán na kartu k uložení (viz pododdíl 4.3.1.2). K výpoˇctu hashe je použita tˇrída SHA512Managed rovnˇež ze jmenného prostoru System.Security.Cryptography. Už samotný název tˇrídy napovídá, že se jedná o hashovací funkci SHA6 a cˇ íslovka 512 udává velikost výstupního hashe, tedy 512bit. 4.4.1.3 Dešifrování Když uživatel zvolí soubor k dešifrování, je vypoˇcítán hash tohoto souboru pomocí výše uvedené hashovací funkce. Ten je následnˇe zaslán serverové aplikaci, která má za úkol pro nˇej nalézt v hashtablu odpovídající uložený záznam (viz pododdíl 4.3.1.3): string fileHash = Convert.ToBase64String(getFileHash(inputFile)); string[] record = service.getRecord(fileHash);
Jestliže je záznam nalezen, pak je zaslán zpˇet klientovi. Ten pomocí šifrovacího klíˇce a inicializaˇcního vektoru, které jsou v záznamu obsaženy, provede dešifrování a zápis do patˇriˇcného výstupního souboru. 4.4.2
GUI – grafické uživatelské rozhraní
Uživatel pracuje s klientskou aplikací prostˇrednictvím grafického uživatelského rozhraní, pomocí nˇehož provádí všechny požadované úkony. Jeho jednotlivé cˇ ásti si popíšeme v tomto oddíle. Klient zobrazuje celkem tˇri okna:
6.
•
Hlavní okno aplikace
•
Okno s výpisem všech uložených záznamu˚
•
Okno pro zadání hesla SHA - Secure Hash Algorithm.
29
ˇ 4.4. KLIENTSKÁ CÁST APLIKACE Hlavní okno (viz Obrázek 4.4) spatˇríme jako první po spuštˇení aplikace. Je inicializováno tˇrídou Program a bˇeží v hlavním vláknˇe. Tento aspekt bude vysvˇetlen pozdˇeji. Je rozdˇeleno celkem na tˇri sekce: Select file, Cryptography operation a Show all records. V první z nich si uživatel zvolí požadovaný soubor pomocí tlaˇcítka Browse. Druhá sekce nabízí na výbˇer, jaká operace se má se souborem provést Encrypt (šifrovat) nebo Decrypt (dešifrovat). Požadovaná operace je zahájena stiskem tlaˇcítka Run. Poslední tˇretí sekce umožnuje ˇ tlaˇcítkem Show zobrazit okno, kde jsou vypsány všechny záznamy uložené na kartˇe (viz Obrázek 4.5).
Obrázek 4.4: Hlavní okno aplikace Zde muže ˚ uživatel pomocí tlaˇcítek Delete Selected a Delete All odstranit pouze vybrané záznamy nebo všechny uložené záznamy. Nabídku obsahující stejné možnosti lze vyvolat i kliknutím pravým tlaˇcítkem myši na tabulku s výpisem. Vybrání požadovaného záznamu se provádí kliknutím levým tlaˇcítkem myši na tento záznam. Pokud chceme oznaˇcit více záznamu, ˚ podržíme souˇcasnˇe klávesu CTRL. Pˇred zahájením dešifrování a zobrazením výpisu všech uložených záznamu˚ je uživatel vyzván k zadání hesla (viz Obrázek 4.6). O stavu aplikace je uživatel informován v hlavním oknˇe prostˇrednictvím položky Status, která nabývá hodnot Ready (aplikace v klidu) nebo Encryption/Decryption operation in progress (probíhá šifrovací nebo dešifrovací operace). Stav aplikace je zobrazen i v levé dolní cˇ ásti tohoto okna. Na zaˇcátku jsme si rˇ ekli, že hlavní okno aplikace je spuštˇeno v hlavním vláknˇe. To se stará o jeho vykreslení na obrazovku poˇcítaˇce, popˇrípadˇe jeho pˇrekreslování v pˇrípadˇe pˇresouvání okna, stisku tlaˇcítka apod. Pokud spustíme operaci jako je šifrování/dešifrování nebo požádáme o výpis všech záznamu˚ uložených na kartˇe, pak dochází k tomu, že vlákno 30
4.5. NÁSTROJ PRO INICIALIZACI ZÁLOŽNÍHO SOUBORU
Obrázek 4.5: Okno s výpisem všech záznamu˚ uložených na kartˇe zaˇcne obsluhovat zmínˇené operace a nemuže ˚ se vˇenovat vykreslování. Díky tomu muže ˚ uživatel nabýt dojmu, že aplikace „zamrzla“. Abychom pˇredešli této situaci, jsou výše uvedené operace spouštˇeny vždy v novˇe vytvoˇreném vláknˇe za použití tˇrídy BackgroundWorker ze jmenného prostoru System.ComponentModel Microsoft .NET Framewoku.
4.5
Nástroj pro inicializaci záložního souboru
Pˇri instalaci serverové cˇ ásti aplikace je volána funkce Main(), která má za úkol pouze registrovat aplikaci na kartˇe jako server, registrovat komunikaˇcní kanál a poskytované služby. Nezajišt’uje však vytvoˇrení instance tˇrídy, jenž pˇredstavuje samotnou službu (v našem pˇrí-
Obrázek 4.6: Okno pro zadání hesla 31
4.5. NÁSTROJ PRO INICIALIZACI ZÁLOŽNÍHO SOUBORU padˇe CryptoService). To znamená, že nejsou inicializovány ani promˇenné uvnitˇr této tˇrídy (pro nás je nejduležitˇ ˚ ejší promˇenná tˇrídy CryptoService reprezentující hashtable). K vytvorˇ ení instance dochází až ve chvíli, kdy je serverová cˇ ást aplikace prvnˇe volána klientem. Na promˇennou tˇrídy CryptoService pˇredstavující hashtable je pˇri této pˇríležitosti spuštˇena funkce zajišt’ující nahrání záznamu˚ ze záložního souboru (viz pododdíl 4.3.1.7). Inicializace hashtablu muže, ˚ v závislosti na poˇctu záznamu˚ uložených v záložním souboru, trvat dlouho. Bylo by tedy nepˇríjemné, kdyby byla provedena, až když uživatel prostˇrednictvím klienta volá serverovou aplikaci. Ovšem pˇredpokládám, že nahrávání aplikací na cˇ ipové karty, jejich spouštˇení a zastavování, má na starosti administrátor, a ne samotný uživatel. Tento cˇ lovˇek proto po nainstalování aplikace na kartˇe použije nástroj pro inicializaci záložního souboru, pokud samozˇrejmˇe tento soubor na kartˇe existuje. Jedná se o jednoduchého klienta, jehož jediným úkolem je obstarat právˇe první volání serverové cˇ ásti aplikace. Produkuje výstup, který obsahuje výpis všech na kartˇe uložených záznamu˚ (viz Obrázek 4.7).
Obrázek 4.7: Výstup nástroje sloužícího pro inicializaci záložního souboru
32
Kapitola 5
Závˇer Díky této bakaláˇrské práci jsem se seznámil s cˇ ipovými kartami, jejich historií, historickým vývojem a pˇredevším se zpusobem ˚ jejich fungování. Získal jsem nejenom obecné poznatky z této oblasti, ale také jsem se seznámil s konkrétním typem cˇ ipové karty v podobˇe Gemalto .NET Smart Card. Nastudování všech dostupných materiálu˚ mi umožnilo naprogramovat aplikaci doprovázející bakaláˇrskou práci, která spolupracuje právˇe s Gemalto .NET kartou. Úkolem klientské cˇ ásti této aplikace je zajišt’ovat šifrování a dešifrování uživatelem zvolených souboru, ˚ které jsou uloženy na uživatelském poˇcítaˇci, pomocí šifrovacích klíˇcu˚ poskytovaných serverovou cˇ ástí aplikace bˇežící na cˇ ipové kartˇe. Serverová cˇ ást obstarává ukládání šifrovacích záznamu˚ na samotnou kartu a zárovenˇ i jejich vyhledání v pˇrípadˇe žádosti o dešifrování souboru. Klientská aplikace navíc uživateli umožnuje ˇ správu na kartˇe uložených záznamu, ˚ což znamená jednak zobrazení výpisu všech na kartˇe uložených záznamu˚ a jednak možnost odstranit z karty nepotˇrebné záznamy. Klient je navíc vybaven grafickým uživatelským rozhraním, skrze které provádí uživatel veškeré požadované operace. Operace, jako je dešifrování souboru a zobrazení výpisu všech na kartˇe uložených záznamu, ˚ jsou navíc chránˇeny heslem. Výsledná aplikace je plnˇe funkˇcní a její jádro bude pravdˇepodobnˇe využito v praxi firmou Y Soft, na jejíž popud tato bakaláˇrská práce vznikla. Y Soft jej hodlá využít pro své vlastní firemní rˇ ešení, jehož úkolem by mˇelo být zajištˇení bezpeˇcnosti a autentizace tisku pomocí cˇ ipové karty. Uživatel tedy na poˇcítaˇci zadá žádost o tisk souboru, který se za použití karty zašifruje a následnˇe odešle na patˇriˇcnou tiskárnu. Uživatel poté pˇrijde k této tiskárnˇe a prostˇrednictvím karty provede autentizaci. Pokud je autentizace úspˇešná, je daný soubor dešifrován a fyzicky vytisknut. Celkovˇe mi tato bakaláˇrská práce rozšíˇrila obzory v oblasti poˇcítaˇcové bezpeˇcnosti, kde se právˇe cˇ ipové karty zaˇcínají prosazovat ve stále vˇetším mˇerˇ ítku, a zárovenˇ mi ukázala jejich obrovský potenciál. Do budoucna mužeme ˚ poˇcítat s jejich masovým rozšíˇrením, kdy zaˇcnou nahrazovat klasické obˇcanské prukazy, ˚ cestovní pasy, popˇrípadˇe budou obsahovat i naše kompletní zdravotní záznamy. Doufám, že se mi naskytnou další pˇríležitosti, kdy se problematikou spojenou s cˇ ipovými kartami budu moci dále zabývat.
33
Literatura [1] Valášek, M.: Symetrické šifrování AES/Rijndael v .NET, dostupné z www: . 4.4.1.1 [2] Cozmanova Software Development: Answer to Reset, dostupné z www: http://www.odbornecasopisy.cz/index.php?id_document=29027 . 2.5 [3] ECMA: ECMA-335, dostupné z www: . 6, 3.3, 3 [4] Gemalto: Gemalto .NET v2/v2+ Smart Card User Guide, dostupné z www: . 2, 2.2.2, 2.2.4, 2.3.1, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 3.1, 3.2.2, 3.3, 3.1, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.3 [5] Wolfgang, R. a Wolfgang, E.: Smart Card Handbook, 3. aktualizované vydání, John Wiley and Sons, 2004, 0-470-85668-8. 2.1, 2.3.1, 2.3.1, 2.2 [6] Chen, Z.: Java Card Technology for Smart Cards, Addison-Wesley, 2000, 0-201-703297. 2.1, 2.3.1 [7] Messmer, E.: The start of the .Net smart card, dostupné z www: . 3 [8] Hendrych, P. a Král, V. a Hrdliˇcka, M.: Zabezpeˇcená komunikace v heterogenní poˇcítaˇcové síti s využitím cˇ ipové karty, dostupné z www: . 2.2.1, 2.4.1 [9] RSA Laboratories: RFC 2315, dostupné z www: . 4 [10] Hendry, M.: Smart Card Security and Applications, 2. aktualizované vydání, Artech House, 2001, 1-58053-156-3. 2 [11] Jurgensen, T. a Guthery, S.: Smart Cards, Prentice Hall PTR, 2002, 0-13-093730-4. 2.1, 2.2.2, 2.2.3, 2.4.1, 2.5, 2.3, 2.5, 2.4, 2.5, 2.5 [12] Circiut Cellar: TPDU Protocol, dostupné z www: . 2.5 [13] Wikipedia: Smart card, dostupné z www: . 2.2.1, 2.1
34
Pˇríloha A
Obsah pˇriloženého CD Složky: •
\Bakaláˇrská práce\ – obsahuje soubor s elektronickou verzí bakaláˇrské práce ve formátu pdf.
•
\CryptographyApplication\ – zdrojové kódy ke klientské aplikaci ve formˇe projektu pro Microsoft Visual Studio 2005.
•
\OnCardServerApp\ – zdrojové kódy k serverové cˇ ásti aplikace ve formˇe projektu pro Microsoft Visual Studio 2005.
•
\InitApplication\ – zdrojové kódy k nástroji pro inicializaci záložního souboru ve formˇe projektu pro Microsoft Visual Studio 2005.
35
