Digitálne Podpisované PDF Dokumenty

MASARYKOVA UNIVERZITA

FAKULTA INFORMATIKY

Digitálne podpisované PDF dokumenty

Bakalárska práca

Peter Bočák

Brno, jar 2008 Vyhlásenie

Vyhlasujem, že táto práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal v práci, riadne citujem s uvedením úplného odkazu na prí- slušný zdroj.

V Brne, 22. 5. 2008 …......

Peter Bočák

1 Poďakovanie

Rád by som poďakoval pánovi RNDr. Petrovi Sojkovi, Ph.D., vedúcemu svojej bakalárskej práce, najmä za jeho podnetné návrhy pri tvorbe práce, ako aj konzultantovi Mgr. Martinovi Šárfymu, Ph.D. za cenné pripomienky k aplikácii. Ďalej by som chcel poďakovať svojim priateľom a známym, ktorí mi poskytli svoje zostavy na testovanie výkonu aplikácie. Poďakovanie si zaslúžia aj vývojári použitej knižnice iText, ktorá vý- znamne uľahčila proces implementácie.

2 Abstrakt

Cieľom bakalárskej práce Digitálně podepisované PDF dokumenty je návrh a implementácia softvérovej aplikácie určenej na hromadné digitálne podpisovanie dokumentov digitálnej matematickej knižnice DML-CZ. Úvodné časti sú spojené s pri- blížením technológie digitálneho podpisu, ktorá sa neskoršie spája do konkrétnej súvi- slosti s formátom PDF a jeho zabezpečením. Záverečné časti tvorí prevažne analýza aplikácie, či už vo fáze analýzy požiadaviek, alebo hotového produktu.

Abstract

The aim of the bachelor project Digitally Signed PDF Documents is project and implementation of software aplication appointed for mass signing of digital mathematic library DML-CZ documents. Introducing parts are connected with explanation of digital sign technology, which is later connected with the specific coherence of the PDF format and its safety support. The final parts mainly consist of analyse of aplication in the analyse requests or final product.

Kľúčové slová

digitálny podpis, elektronický podpis, digitálny certifikát, certifikačná autorita, registračná autorita, hashovacia funkcia, asymetrická kryptografia, Public Key Infrastructure, Certificate Revocation List, Portable Document Format, kontextový diagram, diagram dátových tokov

3 Zoznam obrázkov a tabuliek

Obrázok 1: Kontextový diagram ...... 20 Obrázok 2: Diagram dátových tokov prvej úrovne ...... 21 Obrázok 3: Diagram dátových tokov procesu načítania súborov ...... 23 Obrázok 4: Zobrazenie digitálneho podpisu ...... 30 Obrázok 5: Informácie o digitálnom podpise dokumentu ...... 30 Obrázok 6: Certifikačná cesta a nastavenie dôveryhodných identít ...... 31 Obrázok 7: Informácia o revokácii certifikátu ...... 32 Obrázok 8: Graf výkonu aplikácie s homogénnymi dátami ...... 34 Obrázok 9: Graf výkonu aplikácie s nehomogénnymi dátami ...... 35

Tabuľka 1: Zoznam hashovacích algoritmov a ich vlastnosti ...... 12 Tabuľka 2: Minišpecifikácia syntaxe parametrov ...... 22 Tabuľka 3: Editory dokumentov vo formáte PDF ...... 27 Tabuľka 4: Prehliadače dokumentov vo formáte PDF ...... 28 Tabuľka 5: Výkon aplikácie testovaný na homogénnych dátach ...... 33 Tabuľka 6: Výkon aplikácie testovaný na nehomogénnych dátach ...... 34

4 Obsah

Úvod ...... 7 1 Technológia digitálneho podpisu a infraštruktúra PKI ...... 8 1.1 Čo je digitálny podpis ...... 8 1.2 Asymetrická kryptografia ...... 9 1.3 Funkcia odtlačku dokumentu ...... 9 1.4 Mechanizmus digitálneho podpisu ...... 11 1.5 Digitálny certifikát ...... 11 2 Digitálny podpis v súvislosti s českou legislatívou ...... 13 3 Zabezpečenie súborového formátu PDF ...... 15 4 Návrh aplikácie pre dávkové podpisovanie ...... 16 4.1 Špecifikácia aplikácie ...... 16 4.2 Kontextový diagram ...... 18 4.3 Diagram dátových tokov ...... 19 5 Implementácia a použitie ...... 24 5.1 Parametre aplikácie a výstup ...... 24 5.2 Zobrazenie a verifikácia digitálneho podpisu ...... 25 5.3 Výkonové testy ...... 30 Záver ...... 33 Literatúra ...... 34 Prílohy ...... 35

5 Úvod

Témou práce je digitálne podpisovanie dokumentov ako formy zabezpečenia matematicky orientovaných informácií, považovaných za zdroj poznatkov českej digi- tálnej matematickej knižnice DML-CZ.

Prácu som si zvolil z dôvodu jej zamerania na digitálny podpis, s ktorým už dlhšie obdobie pracujem v oblasti informačných systémov pre zdravotnícke zariadenia. Ďalším dôvodom, ktorý ma presvedčil pri voľbe tejto témy, je jej uplatnenie v rozsiah- lejšom projekte.

Cieľom mojej práce je stručne osvetliť problematiku digitálneho podpisu a poskytnúť nástroj, ktorý umožní jednoducho, a pokiaľ možno čo najrýchlejšie, digitál- ne podpisovať veľký objem PDF dokumentov.

Práca je rozdelená do piatich kapitol. V prvej kapitole sú popísané základné prvky digitálneho podpisu a princípy, na základe ktorých je táto technológia postavená. Oboznamuje tiež so súvisiacou infraštruktúrou verejných kľúčov, ktorá je jeho neoddeli- teľnou súčasťou.

Ďalšia kapitola popisuje niektoré právne zákony týkajúce sa digitálneho podpisu relevantné z hľadiska projektu DML-CZ.

Tretia kapitola oboznamuje s dokumentovým formátom PDF z pohľadu zabez- pečenia. Spomenuté sú jednotlivé elementy zabezpečenia, ako aj reštrikcie, ktorými je možné zamedziť zásahom do dokumentu.

Nasledujúca kapitola sa venuje podrobnej analýze a návrhu aplikácie; popisuje elementárne procesy pomocou klasických metód štruktúrovanej analýzy.

Posledná časť je venovaná hotovej implementácii z hľadiska použitia a objas- ňuje verifikáciu podpisu v editoroch a prehliadačoch PDF dokumentov, pričom poukazuje na nástroje, ktoré sú s digitálnym podpisom schopné pracovať. Nasleduje testovanie na zostavách s rôznym výkonom.

V závere sú zhrnuté dosiahnuté ciele a prínos celej práce s načrtnutím potenciál- nych rozšírení.

6 1 Technológia digitálneho podpisu a infraštruktúra PKI

1.1 Čo je digitálny podpis

Digitálny podpis je dnes čoraz častejšie skloňovaným pojmom a postupne sa snaží vytláčať v praxi stále vo veľkej miere využívaný klasický, rukou písaný podpis. S nástupom informatizácie spoločnosti, súvisiacej s elektronickým spracúvaním stále väčšieho množstva dokumentov, bolo nutné vytvoriť adekvátny nástroj, ktorý je schop- ný sprostredkovať rovnaké vlastnosti (výhody) klasického podpisu. Digitálny podpis má teda za úlohu zabezpečiť nasledujúce vlastnosti dokumentu:

– pravosť – garantuje identitu podpisovateľa, tzn. podpisovateľ je tou istou osobou, za ktorú sa vydáva,

– integrita – potvrdzuje, že po podpísaní dokumentu nedošlo k žiadnej jeho zmene, a teda ani k sfalšovaniu,

– nepopierateľnosť autorstva – označuje skutočnosť, že podpisovateľ nemôže poprieť súvislosť medzi podpísaným dokumentom a svojou osobou.

Na splnenie uvedených vlastností postačujú princípy asymetrickej kryptografie v kombinácii s funkciami digitálneho odtlačku dokumentu a začlenenie verejných kľú- čov do infraštruktúry PKI. Na rozdiel od klasického podpisu poskytuje digitálny podpis niekoľko výhod:

– zrýchlenie prístupu k informáciám,

– zvýšenie efektivity ukladania informácií,

– zjednodušenie realizácie transakcií,

– zníženie prácnosti, chybovosti a nákladov.

Naopak, nevýhodou digitálneho podpisu je skutočnosť, že jeho implementácia a používanie je pre neskúseného užívateľa pomerne náročné (vzhľadom na klasický podpis). Práve tento fakt spomaľuje proces nasadenia digitálneho podpisu do praxe.

7 1.2 Asymetrická kryptografia

V kontraste so symetrickou kryptografiou, ktorá na šifrovanie ľubovoľnej infor- mácie používa iba jeden tajný šifrovací kľúč, existuje kryptografia asymetrická. Tá pou- žíva na zašifrovanie kľúčový pár: privátny a verejný kľúč. Použitím kľúčového páru odpadáva problém distribúcie tajného kľúča medzi prijímateľom a odosielateľom sprá- vy, ako je to v prípade symetrických algoritmov. Šifrovať obsah dokumentu je možné tak privátnym, ako aj verejným kľúčom, pričom na dešifrovanie sa použije druhý z páru kľúčov. V súvislosti s technológiou digitálneho podpisu sa privátny kľúč používa na vytvorenie samotného podpisu, verejný kľúč na jeho overenie. Pokiaľ chceme dokument šifrovať tak, aby nemohol byť prečítaný treťou stranou, použijeme na šifrovanie verejný kľúč. Správu potom môže dešifrovať iba vlastník príslušného privátneho kľúča.

Najznámejším asymetrickým šifrovacím algoritmom je algoritmus RSA (objave- ný v roku 1977). Aktuálne v najväčšej miere používaná dĺžka šifrovacích kľúčov je 1024 bitov, ktorá sa postupom času začína nahrádzať dlhšími, a teda bezpečnejšími kľúčmi dĺžky 2048 bitov prípadne 4096 bitov.

1.3 Funkcia odtlačku dokumentu

Funkcia digitálneho odtlačku, tzv. hashovacia funkcia, je jednocestná funkcia, ktorá ľubovoľne dlhú, konečnú informáciu transformuje na reťazec konštantnej dĺžky (tzv. hash, odtlačok). Pre rovnakú vstupnú informáciu má konkrétna hashovacia funkcia vždy rovnaký výstup. Funkcia je dobre definovaná, pokiaľ:

– je jednocestná – pri znalosti výstupu nie je možné nijakým spôsobom získať vstup,

– pri minimálnej zmene vstupnej informácie vracia úplne rozdielny výstup; táto vlast- nosť sa označuje ako lavínovitosť,

– je silne bezkolízna, tzn. nie je v prijateľnom čase možné nájsť aspoň dva rovnaké vstupy, ktoré by vracali rovnaký výsledok,

– je slabo bezkolízna, tzn. nie je možné v rozumnom čase k danému vstupu nájsť iný vstup tak, aby nastala kolízia,

– má rovnomerné rozloženie výstupov – funkcia distribuuje výstupy rovnomerne v ce- lom obore hodnôt, teda produkuje málo kolízií.1

1 http://sk.wikipedia.org/wiki/Ha%C5%A1ovacia_funkcia (2. 3. 2008)

8 „Jednocestné funkcie sú konštruované na výpočtových operáciách nízkej úrovne (predovšetkým bitové operácie a posuny) a sú teda výpočtovo veľmi rýchle a efektívne. Algoritmy pre výpočet odtlačku nie sú v žiadnom prípade šifrovacími algoritmami (už vzhľadom k nejednoznačnosti – neexistuje inverzná funkcia).“2

Vlastnosti najpoužívanejších hashovacích algoritmov sú zhrnuté v nasledujúcej tabuľke:

Rozsah výstupu Veľkosť Algoritmus Veľkosť bloku Kolízie (v bitoch) slova HAVAL 256/224/192/160/128 1024 32 Áno MD2 128 128 8 Takmer MD4 128 512 32 Áno MD5 128 512 32 Áno PANAMA 256 256 32 S medzerami RIPEMD 128 512 32 Áno RIPEMD-128/256 128/256 512 32 Nie RIPEMD-160/320 160/320 512 32 Nie SHA-0 160 512 32 Áno SHA-1 160 512 32 S medzerami SHA-256/224 256/224 512 32 Nie SHA-512/384 512/384 1024 64 Nie Tiger(2)-192/160/ 192/160/128 512 64 Nie 128 WHIRLPOOL 512 512 8 Nie Tabuľka 1: Zoznam hashovacích algoritmov a ich vlastnosti3

Pre digitálny podpis je najvhodnejšie použiť hashovacie algoritmy, ktoré sú bezkolízne. Ideálnym kandidátom na využitie v tomto smere je hashovacia funkcia SHA (navrhnutá National Security Agency) s dĺžkou aspoň 256 bitov. Donedávna značne používaná funkcia MD5 sa dnes javí ako nevhodná. Kolízie je aktuálne možné z MD5 získať v pomerne krátkom čase. Vzhľadom na tento fakt Narodní bezpečnostní úřad ČR uvádza nasledujúce doporučenia o používaní hashovacích funkcií:

– odporúča sa ďalej nepoužívať hashovacie funkcie s výstupom menším ako 160 bitov (napr. hashovacie funkcie MD4, MD5, RIPEMD, HAVAL-128 atď.),

– odporúča sa neodkladne zahájiť prípravu k prechodu od hashovacej funkcie SHA-1 na novú generáciu hashovacích funkcií triedy SHA-2 (SHA-224, SHA-256, SHA-384 a SHA-512),

2 Dostálek, L. a kol.: Velký průvodce infrastrukturou PKI a technologií elektronického podpisu, str. 21. 3 http://en.wikipedia.org/wiki/Cryptographic_hash_function (4. 3. 2008)

9 – odporúča sa preskúmať všetky bezpečnostné aplikácie a kryptografické prostriedky, v ktorých sa využívajú hashovacie funkcie, a odborne posúdiť vplyv najnovších kryptoanalytických útokov na ich bezpečnosť.4

1.4 Mechanizmus digitálneho podpisu

Vytvorenie digitálneho podpisu prebieha v niekoľkých krokoch. V prvom rade je z dokumentu spočítaný odtlačok verejne známym algoritmom, ktorý ho jednoznačne identifikuje a zabezpečí jeho integritu. Akákoľvek zmena v dokumente spôsobí, že zme- nený dokument už nesúhlasí s vypočítaným odtlačkom, a má preto neplatný podpis.

Druhým krokom je aplikácia asymetrickej šifry na digitálny odtlačok. Ten je za- šifrovaný prostredníctvom privátneho kľúča podpisovateľa. V tejto etape je už okrem integrity zaistená aj nepopierateľnosť autorstva.

Posledným krokom, ktorý už sčasti spadá do overovania podpisu, je distribúcia verejného kľúča k overovateľovi podpisu. Aby bola zabezpečená pravosť podpisu, musí sa za podpisovateľa zaručiť dôveryhodná tretia strana. Na tento účel bola vybudovaná rozsiahla infraštruktúra verejných kľúčov PKI (Public Key Infrastructure). Hlavnou úlohou PKI je poskytnúť aparát, za pomoci ktorého overovateľ ľahko zistí identitu pod- pisovateľa.

K overeniu digitálneho podpisu slúži digitálny certifikát obsahujúci verejný kľúč podpisovateľa. Na princípe asymetrickej kryptografie je potom dešifrovaný odtlačok do-kumentu. Keďže hashovacia funkcia má verejne známy algoritmus, z dokumentu je znova spočítaný digitálny odtlačok a porovnáva sa s odtlačkom dešifrovaným. v prípade zhody (a platnosti certifikátu) môžeme digitálny podpis označiť za platný.

1.5 Digitálny certifikát

Pred použitím verejného kľúča by mal užívateľ získať dôkaz, na základe ktorého sa môže s istotou spoľahnúť na identitu vlastníka verejného kľúča. Inak povedané, verejný kľúč musí byť označený ako dôveryhodný spoľahlivou treťou stranou (Trusted Third Party, TPP) vydaním certifikátu. Certifikáty vydáva certifikačná autorita, ktorá sa týmto za identitu vlastníka zaručí svojím digitálnym podpisom.

4 http://www.nbu.cz/ko/info.php (16. 3. 2008)

10 Digitálny certifikát je dátová štruktúra, ktorá podľa štandardu X.5095 obsahuje položky verzia certifikátu, poradové číslo, algoritmus podpisu, vystaviteľ certifikátu, začiatok obdobia platnosti, koniec obdobia platnosti, predmet a verejný kľúč. Môže tak- tiež obsahovať ďalšie rozšírenia, najčastejšie rozsah použitia certifikátu, prístup k distri- bučným miestam na získanie zoznamu zneplatnených certifikátov a vlastnosti ako digi- tálny odtlačok a algoritmus odtlačku. Rozšírenia certifikátu sú definované v štandarde RFC3280, ktorý zároveň popisuje vhodnosť ich aplikácie, či už v certifikátoch certifi- kačných autorít, alebo koncových užívateľov, prípadne ich použitie označí za nevhodné. Spomenuté identifikačné údaje spolu s verejným kľúčom certifikačná autorita potvrdí svojím digitálnym podpisom a pripojí ho k certifikátu.

Vyhotovenie certifikátu je osobitý proces definovaný príslušnou, verejne známou certifikačnou politikou danej certifikačnej autority. Užívateľ si za pomoci aplikácie6 vy- generuje kľúčový pár a podá žiadosť o vydanie certifikátu. Žiadosť je presne definovaná štruktúra obsahujúca verejný kľúč, identifikačné údaje žiadateľa a ďalšie informácie podpísané práve vygenerovaným privátnym kľúčom. Tiež by mala obsahovať dôkaz o vlastníctve príslušného súkromného kľúča z toho dôvodu, ak by existoval iný žiadateľ s rovnakým súkromným kľúčom. S ohľadom na stupeň významnosti certifikátu je často požadovaná osobná prítomnosť pri overovaní identifikačných údajov (proces overovania identity je väčšinou postúpený tzv. registračnej autorite, ktorá potom údaje spro- stredkuje certifikačnej autorite).

Špeciálnym typom certifikátu je tzv. kvalifikovaný certifikát, ktorý je vydávaný kvalifikovaným poskytovateľom certifikačných služieb a jeho cieľom je nahradiť rukou písaný podpis elektronickým podpisom.

„Kvalifikovaný certifikát umožňuje overiť za-ručený elektronický podpis (advanced electronic signature) spĺňajúci tieto požiadavky: 1. je jednoznačne spojený s podpisujúcou osobou, 2. umožňuje identifikáciu podpisujúcej osoby vo vzťahu k dátovej správe, 3. bol vytvorený a pripojený k dátovej správe pomocou prostriedkov, ktoré podpisujúca osoba môže udržať pod svojou výhradnou kontrolou, 4. je k dátovej správe, ku ktorej sa vzťahuje, pripojený takým spôsobom, že je možné zistiť akú- koľvek následnú zmenu dát.“7

5 Štandard X.509 verzie 3 je definovaný v dokumente RFC3280 r. 2002. 6 V operačnom systéme Windows® je pre tento účel vstavaná aplikácia certmgr.msc, vhodnou alterna- tívou môže byť multiplatformová open-source aplikácia OpenSSL; obe obsahujú sadu nástrojov na generovanie žiadostí a správu certifikátov. 7 Zákon 227/2000 o elektronickom podpise, MI ČR, 2000, §2, bod b).

11 2 Digitálny podpis v súvislosti s českou legislatívou

Elektronický podpis je akceptovaný českou legislatívou od roku 2000 vydaním zákona č. 227/2000 o elektronickom podpise. Cieľom tejto legislatívy je uplatnenie elektronického podpisu ako náhrady klasického, rukou písaného podpisu. Z hľadiska projektu DML-CZ sú významné najmä nasledujúce odseky:

„§3 Súlad s požiadavkami na podpis

(1) Dátová správa je podpísaná, pokiaľ je zaopatrená elektronickým podpisom.

(2) Použitie zaručeného elektronického podpisu, založeného na kvalifikovanom certifikáte a vytvoreného za pomoci prostriedku pre bezpečné vytváranie podpisu, umožňuje overiť, že dátovú správu podpísala osoba uvedená na tomto kvalifikovanom certifikáte.

§4 Súlad s originálom

Použitie zaručeného elektronického podpisu zaručuje, že pokiaľ dôjde k porušeniu obsahu správy od okamihu, keď bola podpísaná, toto porušenie bude možné zistiť.

§12 Náležitosti kvalifikovaného certifikátu

(1) Kvalifikovaný certifikát musí obsahovať:

(a) označenie, že je vydaný ako kvalifikovaný certifikát podľa tohto zákona,

(b) obchodné meno poskytovateľa certifikačných služieb, jeho sídlo, ako i údaj, že cer- tifikát bol vydaný v Českej republike,

(d) zvláštne znaky podpisujúcej osoby, ak to vyžaduje účel kvalifikovaného certifikátu,

(e) dáta na overovanie podpisu, ktoré zodpovedajú dátam na vytváranie podpisu, ktoré sú pod kontrolou podpisujúcej osoby,

(f) zaručený elektronický podpis poskytovateľa certifikačných služieb, ktorý kvalifi- kovaný certifikát vydáva,

(g) číslo kvalifikovaného certifikátu unikátne u daného poskytovateľa certifikačných služieb,

(h) počiatok a koniec platnosti kvalifikovaného certifikátu,

(i) prípadné údaje o tom, či sa používanie kvalifikovaného podpisu obmedzuje podľa povahy a rozsahu iba pre určité použitie,

(j) prípadne obmedzenie hodnôt transakcií, pre ktoré môže byť kvalifikovaný certifikát použitý,

12 (2) Ďalšie osobné údaje smie kvalifikovaný certifikát obsahovať iba so súhlasom podpisujú- cej osoby.“8

Pokiaľ bude pre podpisovanie použitý certifikát vydaný zahraničnou cer- tifikačnou autoritou, je dôležité spomenúť ešte nasledovný odsek:

„§16 Uznávanie zahraničných certifikátov

(1) Certifikát, ktorý je vydaný zahraničným poskytovateľom certifikačných služieb ako kvalifikovaný v zmysle tohto zákona, môže byť používaný ako kvalifikovaný certifikát vtedy, pokiaľ je uznaný poskytovateľom certifikačných služieb podľa tohto zákona, a za podmienky, že tento poskytovateľ certifikačných služieb zaručí v rovnakom rozsahu ako u svojich kvalifikovaných certifikátov správnosť a platnosť kvalifikovaného certifi- kátu vydaného v zahraničí.

(2) Certifikát, ktorý je vydaný zahraničným poskytovateľom certifikačných služieb ako kvalifikovaný v zmysle tohto zákona, je uznaný ako kvalifikovaný certifikát vtedy, pokiaľ to vyplýva z rozhodnutia Úřadu pro ochranu osobních údajů (ďalej len Úrad) alebo medzinárodných zmlúv, alebo pokiaľ bude medzi príslušným zahraničným orgánom alebo zahraničným poskytovateľom certifikačných služieb a Úradom uzavretá dohoda o vzá- jomnom uznávaní certifikátov.“8

8 Zákon 227/2000 o elektronickom podpise, MI ČR, 2000.

13 3 Zabezpečenie súborového formátu PDF

PDF (Portable Document Format) je súborový formát, ktorý vyvinula firma Adobe, aby umožnila ukladanie dokumentov nezávisle na použitom hardvéri alebo soft- véri. Formát zaručuje, že sa uložený obsah zobrazí na rôznych použitých zariadeniach rovnako.

PDF poskytuje z hľadiska bezpečnosti niekoľko rôznych možností ako obmedziť prácu s dokumentom. Reštrikcie sú v niektorých prípadoch obmedzené verziou prehlia- dača alebo editoru Acrobat, z dôvodu, že staršie verzie podporujú iba jednoduchšie sy- metrické šifry (verzia 3 až 5 podporuje šifrovanie 40-bit RC4, neskoršie verzie pou- žívajú bezpečnejšiu šifru 128-bit RC4 alebo AES). Z pohľadu šifrovania ponúka PDF buď šifrovanie celého dokumentu, alebo šifrovanie s obmedzeniami:

– šifrovanie s výnimkou metadát (umožní v šifrovanom dokumente vyhľadávať),

– šifrovanie iba súborov v prílohe,

– žiadať heslo pri otváraní, upravovaní alebo tlačení dokumentu; poprípade nastaviť heslo pre zmenu reštrikcií.

Tlač dokumentu je taktiež možné obmedziť v niekoľkých úrovniach, a to buď tlač úplne zakázať, povoliť tlač iba s nízkym rozlíšením (150 dpi), alebo ju ponechať bez obmedzení.

Ďalšie reštrikcie sa týkajú editovania obsahu. Aj v tomto prípade je na výber z niekoľkých alternatív, ktoré môžeme buď povoliť, alebo zakázať:

– akékoľvek úpravy dokumentu,

– vkladanie, mazanie a otáčanie stránok, eventuálne možno povoliť aj digitálny podpis a vyplnenie polí formulára,

– vyplnenie polí formulára a digitálny podpis existujúceho poľa pre podpis, prípadne pridávanie komentárov,

– úpravy s výnimkou extrahovania stránok,

– kopírovanie obsahu (text, obrázky a iné objekty),

– sprístupnenie textu aplikáciám na čítanie textu určeným zrakovo postihnutým použí- vateľom.

14 4 Návrh aplikácie pre dávkové podpisovanie

4.1 Špecifikácia aplikácie

Projekt DML-CZ (Česká digitální matematická knihovna) vznikol na digitalizá- ciu matematických textov medzinárodnej úrovne vydaných v Českej Republike s cie- ľom umožniť rýchlejší a pohodlnejší prístup k informáciám matematického zamerania. Jeho zámerom je tiež poskytnúť prostriedok, ktorý umožní informácie efektívne sklado- vať, triediť a vyhľadávať a v konečnom dôsledku začleniť projekt do celosvetovej matematickej knižnice WDML.

Keďže digitálna knižnica obsahuje obrovský objem informácií, ktoré musia byť zabezpečené predovšetkým pred neautorizovanou zmenou, je potrebné bezpečne ochrá- niť tieto údaje adekvátnymi prostriedkami. Najvhodnejším nástrojom je práve digitálny podpis, ktorý jednoznačne zaručí integritu dokumentov a autorstvo. Niektoré prehlia- dače súborov PDF umožňujú digitálny podpis priamo overiť, ako aj skontrolovať plat- nosť certifikátu a zobraziť ďalšie vlastnosti podpisu.

Cieľom špecifikácie je analyzovať požiadavky kladené na aplikáciu umožňujúcu digitálny podpis k dokumentu pripojiť a konkrétne definovať zoznam týchto požiada- viek. Ďalším krokom je stanovenie cieľov takým spôsobom, aby po implementácii apli- kácie bolo možné určiť, či uvedený cieľ dosiahla.

Požiadavky a ciele:

– Hlavným cieľom je vyvinúť nástroj na dávkové digitálne podpisovanie dokumentov prostredníctvom open-source nástrojov.

– V prvom rade je kladený dôraz na čo najvyšší výkon vzhľadom na veľký objem spracovávaných dokumentov.

– Grafické užívateľské rozhranie nie je požadované, postačí zadávanie parametrov prostredníctvom príkazového riadku.

15 – Aplikácia umožní načítať dokumenty rôznymi spôsobmi:

▪ zoznamom súborov,

▪ špecifikovaním priečinka, v ktorom sú súbory umiestnené,

▪ ako jediný súbor.

– Digitálny podpis by nemal v dokumente pôsobiť rušivo. Užívateľ má mať k nemu prístup iba v prípade, keď potrebuje digitálny podpis overiť.

– Aplikácia by mala byť multiplatformová a nezávislá na komponentoch hostiteľského operačného systému.

– Umožní nastaviť parametre digitálneho podpisu reason a location, ktoré sa zobrazujú pri overovaní podpisu ako sprievodná informácia.

– Poskytne nástroj pre bezpečné zadávanie hesla k privátnemu kľúču.

Nástroje na implementáciu:

Odporúčaná knižnica iText obsahuje sadu funkcií určených na digitálne podpísanie PDF dokumentov. Jej použitie je vhodné vzhľadom na fakt, že vyhovuje zodpovedajúcim požiadavkám. Knižnica je voľne dostupná pod licenciami MPL9 alebo LGPL.10 Keďže je celá vyvinutá na platforme programovacieho jazyka Java, je tento jazyk adekvátnym nástrojom pre implementáciu aplikácie. Výhodou je tiež jeho nezá- vislosť a nezávislosť vyvinutých aplikácií na hostiteľskej platforme operačného sys- tému.

Použité je vývojové prostredie NetBeans® s verziou platformy Java SE 6 Update 10. Vzhľadom na to, že sa oblasť zabezpečenia v Jave často aktualizuje každým vydaním novšej verzie, nie je vhodné používať pre správny chod aplikácie verzie staršie.

9 Konkrétne znenie licencie je na stránkach knižnice iText: http://www.lowagie.com/iText/MPL-1.1.txt. 10 LGPL je akceptovaná iba kvôli spätnej kompatibilite (licencia je uvedená na stránke http://www.lowagie.com/iText/lgpl.txt).

16 4.2 Kontextový diagram

Kontextový diagram zobrazuje celú aplikáciu ako jediný proces, aby bolo možné jednoznačne určiť všetky komponenty a dáta, ktoré do systému vstupujú alebo sú vý- sledkom transformácií v systéme. Aplikácia na dávkové digitálne podpisovanie (pdfsign) je znázornená týmto jednoduchým kontextovým diagramom:

heslo k privátnem u kľúču s ú b o r y u ž í v a t e ľ p a r a m e t r e p d f s i g n podpísnané súbory súborový systém

Obrázok 1: Kontextový diagram

Do systému vstupuje užívateľ, ktorý označí súbory určené na digitálny podpis. Tiež definuje parametre podpisu a odovzdá systému certifikát obsahujúci privátny kľúč. Aplikácia ďalej od užívateľa požaduje heslo k privátnemu kľúču, aby mohla k sú- boru s certifikátom pristupovať. Na základe získaných informácií načíta z externej pamäte súborový systém užívateľom špecifikované súbory. Následne prebehne sa- motná transformácia (digitálny podpis súborov) a odovzdá súborovému systému výsledok transformácie.

17 4.3 Diagram dátových tokov

parametre 1 parsovanie užívateľ parametrov

zadaj heslo heslo nezadané

2 zdroj súborov

získaj heslo

o e

u a

f n s

l o

k t

á n

zoznam súborov y t 3 načítanie sú b o ro v súbory načítané súbory

4 súborový systém podpísané súbory podpísanie s ú b o r o v

Obrázok 2: Diagram dátových tokov prvej úrovne

1. Parsovanie parametrov Aplikácia načíta parametre odovzdané prostredníctvom funkcie main a uloží ich do premennej args (pole reťazcov). Parsované budú najskôr prvé, povinné, parametre, a to typ zdroja súborov, vymedzenie zdroja (závislé na type zdroja) a parametre reason a location. Po ich správnom zadaní pokračuje v overovaní voliteľných parametrov: heslo a príznak nahradzovania súborov. V opačnom prí- pade aplikácia zareaguje zodpovedajúcou výnimkou:

– IllegalArgumentException – je vyvolaná, ak nastane jedna z nasledujúcich možností:

▪ počet parametrov je menší ako 5 alebo väčší ako 8,

▪ parameter na určitej pozícii nespĺňa požadovanú syntax,

18 ▪ chybná syntax vzhľadom na (správny) počet parametrov určená minišpe- cifikáciou podľa nasledujúcej rozhodovacej tabuľky:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 5 parametrov T T T T F F F F F F F F F F F F 6 parametrov F F F F T T T T F F F F F F F F 7 parametrov F F F F F F F F T T T T F F F F 8 parametrov F F F F F F F F F F F F T T T T Par. -replace T T F F T T F F T T F F T T F F Par. -password T F T F T F T F T F T F T F T F Chyba T T T F T F T T T T F T F T T T Tabuľka 2: Minišpecifikácia syntaxe parametrov

– FileNotFoundException – nastane, ak súbor s certifikátom nebol nájdený.

2. Získanie hesla Ak nebolo heslo zadané parametrom, aplikácia vyvolá konzolu na jeho vloženie, ktorá nezobrazuje zadávané znaky. Pokiaľ privátny kľúč nie je chránený heslom stačí konzolu ukončiť potvrdením prázdneho reťazca. Pole, ktoré obsahuje jednotlivé znaky hesla, je po sprístupnení privátneho kľúča zmazané, aby sa minimalizovala životnosť citlivých dát v pamäti.

3. Načítanie súborov Špecifikácia procesu načítanie súborov je reprezentovaná diagramom dátových tokov nižšej úrovne. Podľa vstupného dátového paketu proces výber zdroja rozhodne o použití príslušného algoritmu. Výsledok operácie zapíše do esenciálnej pamäti zoznam súborov, ktorá je týmto pripravená k digitálnemu podpísaniu dokumentov. V prípade zlyhania zareaguje výnimkou. Proces netestuje formát dokumentu, iba jeho príponu. Testovanie integrity (v zmysle integrity formátu PDF, nie digitálneho podpisu) prebieha až v procese podpisovania načítaných súborov.

19 3.2 príznak pre načítanie podpriečinkov súbory načítanie súborov súborový systém cesta k priečinku z priečinku načítané súbory súbory súbor

3.1 3.3 Výber názov súboru so zoznamom načítanie súborov zdroja z o z o z n a m u načítané súbory

3.4 názov súboru n a č í t a n i e zoznam súborov jedného súboru zdoj súborov načítaný súbor

Obrázok 3: Diagram dátových tokov procesu načítanie súborov

3.1 Výber zdroja Výber zdroja je jednoduchý proces definovaný nasledujúcim výrazom štruktúrovanej angličtiny. Dátový paket zdroj súborov obsahuje dve informácie – typ zdroja a zdroj.

case (typ zdroja) of priečinok: príznak pre načítanie podpriečinkov := false; načítanie súborov z priečinku(zdroj); priečinok vrátane podpriečinkov: príznak pre načítanie podpriečinkov := true; načítanie súborov z priečinku(zdroj); zoznam súborov: načítanie súboru so zoznamom(zdroj); jeden súbor: načítanie jedného súboru(zdroj); end;

20 3.2 Načítanie súborov z priečinku Algoritmus načíta súbory do esenciálnej pamäti načítané súbory z priečinka odovzdaného v argumente. Najskôr zisťuje nastavenie príznaku pre čítanie podpriečinkov. Ak je nastavený, funkcia je spúšťaná rekurzívne pre každý podpriečinok. Keďže proces načítavania súborov môže byť pri ich veľkom množstve alebo zložitej adresárovej štruktúre zdĺhavý, funkcia vypi- suje na štandardný výstup informáciu o počte doteraz prečítaných súborov. Pokiaľ cesta k priečinku alebo priečinok neexistuje, aplikácia zareaguje výnimkou FileNotFoundException.

3.3 Načítanie súborov zo zoznamu Funkcia najskôr overí existenciu textového dokumentu. Potom súbor otvorí a číta po riadkoch až do konca. Na každom riadku očakáva cestu k sú- boru a názov vrátane prípony. Prázdne riadky sú ignorované. Následne overuje, či sa uvedený súbor nachádza v zadanom umiestnení, ak nie, vypíše na štandardný chybový výstup názov chybne špecifikovaného súboru. Pokiaľ textový dokument so zoznamom súborov neexistuje, aplikácia zareaguje výnimkou FileNotFoundException. Výnimka IOException je vyvolaná, ak nastane vstupno-výstupná chyba pri čítaní zoznamu.

3.4 Načítanie jedného súboru Načítanie jedného súboru je triviálny proces; aplikácia reaguje podobne ako v predošlých prípadoch výnimkou FileNotFoundException, po- kiaľ požadovaný súbor neexistuje.

4. Podpísanie súborov Proces podpisovania súborov je založený najmä na funkcionalite dvoch vzájomne (funkčne) previazaných komponentov. V prvom rade je to externá knižnica iText disponujúca triedami PdfReader a PdfStamper. Účelom triedy PdfReader je sprostredkovať vstupno-výstupný prúd medzi podpisovým mechanizmom a dokumentom vo formáte PDF. PdfStamper umožňuje vytvoriť digitálny podpis a nastaviť jeho parametre.

21 Prácu s certifikátom, privátnym kľúčom a úložiskom certifikátov podporuje samotný subsystém tried jazyka Java – java.security. Poskytuje tiež potrebné asymetrické algoritmy, hashovacie funkcie a dalšie mechanizmy či protokoly. Proces podpisovania je pri veľkom objeme vstupných dát časovo nároč- ný, pri každom podpísanom dokumente sa preto aktualizuje progres spracova- ných súborov a vypíše sa na štandardný výstup. Po skončení odošle na štandard- ný výstup časový údaj informujúci o trvaní celého procesu. Názov podpísaného dokumentu je štandardne tvorený prefixom „signed_“. Pokiaľ je nastavený príznak -replace, je názov súboru zhodný so sú- borom pôvodným a pôvodnú verziu tak nahrádza. Pri podpisovaní môže nastať niekoľko chybových stavov, na ktoré aplikácia reaguje nasledujúcimi výnimkami: – IOException – môže nastať v dvoch prípadoch: ▪ aplikácia nemôže otvoriť podpisovaný dokument, ▪ aplikácia nemôže otvoriť súbor s uloženým privátnym kľúčom a certifikátom. – DocumentException – všeobecná chyba pri práci s dokumentom bližšie upresnená pri jej vzniku prostredníctvom knižnice iText. – KeyStoreException – chyba vzniknutá pri práci s úložiskom certifiká- tov. Chybu bližšie špecifikuje prostredie Javy a odovzdá na štandardný chy- bový výstup detailnejšiu informáciu. – FileNotFoundException – súbor s privátnym kľúčom a príslušným certifikátom nebol nájdený v zadanom umiestnení. – UnrecoverableKeyException – privátny kľúč nie je možné získať z úložiska certifikátov. – NoSuchAlgorithmException – je vyvolaná, ak systém požaduje spro- stredkovanie algoritmu, ktorý nie je dostupný v prostredí java.security. – CertificateException – vzniká pri všeobecnej chybe vzniknutej pri práci s certifikátom. Chyba je bližšie špecifikovaná prostredím Javy.

22 5 Implementácia a použitie

5.1 Parametre aplikácie a výstup

Syntax parametrov aplikácie je vypísaná na štandardný výstup pri spustení bez parametrov alebo spolu s chybovým hlásením pri ich nesprávnom zadaní. pdfsign [typ zdroja] [zdroj] [certifikát] [location] [reason] {-password heslo} {-replace} povinné parametre:

– [typ zdroja] – môže obsahovať nasledujúce hodnoty:

▪ -f – podpísanie súborov v priečinku,

▪ -sf – podpísanie súborov v priečinku vrátane podpriečinkov,

▪ -list – podpísanie súborov, ktoré definuje zoznam uložený v textovom súbore,

▪ -file – podpísanie jedného súboru,

– [zdroj] – definuje cestu alebo súbor v závislosti na parametri typ zdroja,

– [certifikát] – cesta k súboru s privátnym kľúčom a zodpovedajúcim cer- tifikátom,

– [location] – definuje vlastnosť digitálneho podpisu location,

– [reason] – definuje vlasnosť digitálneho podpisu reason.

voliteľné parametre:

– {-password heslo} – heslo k privátnemu kľúču; ak nie je zadané, aplikácia o heslo požiada neskôr,

– {-replace} – nahradí pôvodné súbory podpísanými verziami.

23 5.2 Zobrazenie a verifikácia digitálneho podpisu

Existuje celý rad prehliadačov a editorov súborov vo formáte PDF určených pre rôzne operačné systémy. Len málo z nich má však schopnosť digitálny podpis v dokumente zistiť, zobraziť a verifikovať. V tabuľkách sú uvedené prehliadače a editory pra- cujúce na rôznych platformách. Označené sú aplikácie pracujúce s digitálnym podpisom. Ostatné aplikácie síce digitálne podpísaný dokument bez problémov otvoria, neob- sahujú však nástroje na prácu s podpisom a jeho zobrazenie.

Zobrazenie Platforma Editor Verzia a verifikácia podpisu Adobe Acrobat 8.0 Áno Adobe Freehand 11.0.2 Nie Adobe Illustrator CS3 Nie Ghostscript 8.61 Nie Multiplatformové Inkscape 0.46 Nie Pdftk 1.12 Nie PDF Studio 4.82 Nie PDFEdit 0.4.1 Nie Nie CutePDF Professional 3.5 (iba podpísanie) Ecopy Desktop 9.2 Nie Jaws PDF 2.0 Nie Microsoft Windows® NitroPDF 5.0 Áno PagePlus X2 - Nie Pdf Sign & Seal 4.0.5 Áno Pdf - XChange 4.0148 Nie Unix/Linux PDFEdit (verzia pre Unix) 0.4.1 Nie Tabuľka 3: Editory dokumentov vo formáte PDF

24 Zobrazenie Platforma Prehliadač Verzia a verifikácia podpisu

Adobe Reader 8.1.2 Áno Foxit Reader 2.3 Nie Multiplatformové Multivalent 02/01/2006 Nie STDU Viewer 1.4.9 Nie Drumlin PDF Reader 2.121 Nie Microsoft Windows® PDF – Xchage Viewer 2.037 Nie Sumatra PDF 0.8 Nie ePDFView 0.1.6 Nie Evince 2.21.1 Nie GPdf 0.104 Nie Unix/Linux gv 3.5.8 Nie KPDF 0.5.9 Nie Okular 0.6.3 Nie Xpdf 3.02pl2 Nie Prewiev 3.0.2 Nie Mac OS X Safari 2.1 Nie Skim 1.0 Nie Tabuľka 4: Prehliadače dokumentov vo formáte PDF

Z uvedených aplikácií patrí medzi najpoužívanejšie nástroje na prácu s digi- tálnym podpisom multiplatformový prehliadač Adobe Reader. Podpis je v tomto prehlia-dači reprezentovaný ikonou (prípadne aj obrázkom, pokiaľ ide o viditeľný podpis) a po otvorení záložky informuje užívateľa o autorovi, validite a čase podpisu. Pokiaľ nie je podpis platný, presne definuje, z akého dôvodu nespĺňa požadované kritériá. Môže to byť niektorá z nasledujúcich možností:

– certifikát podpisovateľa bol revokovaný,

– certifikát podpisovateľa expiroval,

– certifikát podpisovateľa bol odstránený zo zoznamu dôveryhodných identít alebo bola zmenená úroveň dôveryhodnosti,

– podpísaný dokument bol zmenený po aplikovaní podpisu.

25 Obrázok 4: Zobrazenie digitálneho podpisu

Tiež je možné získať podrobnejšie informácie o podpise, certifikáte podpisovate- ľa a certifikátoch súvisiacich certifikačných autorít. Pokiaľ nie je k podpisu pripojená časová známka, prehliadač zobrazí varovanie, ktoré upozorňuje na nedôveryhodnosť ča- sovej informácie pri podpisovaní, tzn. čas nepochádza zo zabezpečeného zdroja.

Obrázok 5: Informácie o digitálnom podpise dokumentu

26 Aby bol podpis platný, musí obsahovať na ceste k certifikátu aspoň jeden certifikát označený ako dôveryhodný. Spravovať certifikáty a nastavovať úrovne dôve- ryhodnosti umožňuje Adobe Reader prostredníctvom nástroja Certificate Viewer. Tiež informuje o hodnotách jednotlivých atribútov certifikátu, ceste k certifikátu a o stave revokácie.

Obrázok 6: Certifikačná cesta a nastavenie dôveryhodných identít

Stav revokácie prehliadač aktualizuje na základe informácie uvedenej v atribúte certifikátu. Najčastejšie býva zadaná URI adresou; prehliadač pri požiadavke o validá- ciu podpisu automaticky skontroluje pripojenie k internetu a získa CRL certifikačnej autority. Pokiaľ pripojenie neexistuje, označí validitu podpisu ako neoveriteľnú. CRL mô- že užívateľ sprostredkovať aj iným spôsobom, napríklad vo forme súboru na prenosnom médiu.

27 Obrázok 7: Informácia revokácii certifikátu

Ostatné editory pracujúce s digitálne podpísanými dokumentami poskytujú viac- menej podobné možnosti overovania podpisu, aj keď nie v takom rozsahu ako popísaný Adobe Reader (výnimkou je samozrejme editor Adobe Acrobat, ktorý disponuje rovna- kými nástrojmi pre verifikáciu).

28 5.3 Výkonové testy

Aplikácia bola v záverečnej etape testovaná na rôznych zostavách z hľadiska parametrov aj hostiteľského operačného systému. Zostavy č. 2, 3 a 4 používajú rovnaké pamäti (výrobca, frekvencia) a ostatné komponenty s výnimkou kapacity, resp. operač- ného systému, a preto v najväčšej miere odrážajú skutočný výkon aplikácie.

Prvú, homogénnu množinu testovaných dát tvorí 1000 PDF dokumentov (rovna- ké dokumenty s veľkosťou 823 kB) s bohatou adresárovou štruktúrou. Čas uvedený v tabuľke zodpovedá času podpísaniu všetkých dokumentov a nezahŕňa čas využitý na ich načítanie.

Číslo RAM Operačný Procesor Čas zostavy (v MB) systém 1. Intel Celeron 3,06 GHz 512 Windows XP 5:30 2. Intel Pentium 4 3GHz Prescott HT 1024 Windows XP 4:14 3. Intel Pentium 4 3GHz Prescott HT 2048 Windows XP 3:55 4. Intel Pentium 4 3GHz Prescott HT 1024 Fedora Core 9 3:40 5. AMD Athlon XP 2500+ 1,83 GHz 768 Fedora Core 7 6:02 6. AMD Athlon XP 2500+ 1,83 GHz 512 Windows XP 7:51 7. AMD Athlon XP 1800+ 1,53 GHz 512 Windows XP 9:57 8. Mobile AMD Semptron 3500+ 1,81 GHz 384 Windows XP 4:25 9. Intel Pentium Dual E2140 1,6 GHz 1024 Windows XP 2:56 Tabuľka 5: Výkon aplikácie testovaný na homogénnych dátach

29 10:48:00

09:36:00

1. Intel Celeron 3,06 GHz 08:24:00 2. Intel Pentium 4 3GHz Pres cott HT 3. Intel Pentium 4 3GHz 07:12:00 Pres cott HT 4. Intel Pentium 4 3GHz Pres cott HT 06:00:00 5. AMD Athlon XP 2500+ 1,83 GHz 6. AMD Athlon XP 2500+ 04:48:00 1,83 GHz 7. AMD Athlon XP 1800+ 1,53 GHz 8. Mobile AMD Sem ptron 03:36:00 3500+ 1,81 GHz 9. Intel Pentium Dual E2140 1,6 GHz 02:24:00

01:12:00

00:00:00 Čas

Obrázok 8: Graf výkonu aplikácie s homogénnymi dátami

Testovanie prebiehalo aj na testovacích dátach, ktoré tvorili rôzne dokumenty s odlišnou veľkosťou (1000 PDF dokumentov od 5 kB do 22 MB). Rozdiely medzi je- dnotlivými zostavami však s menšími odchýlkami priamo úmerne zodpovedali predchádzajúcim výsledkom. Výnimkou bol dvojjadrový procesor Intel Pentium Dual (zostava č. 9), ktorý druhú úlohu vykonal oveľa rýchlejšie oproti predchádzajúcej vzhľadom na ostatné zostavy.

Číslo RAM Operačný Procesor Čas zostavy (v MB) systém 1. Intel Celeron 3,06 GHz 512 Windows XP 4:18 2. Intel Pentium 4 3GHz Prescott HT 1024 Windows XP 3:15 3. Intel Pentium 4 3GHz Prescott HT 2048 Windows XP 2:56 4. Intel Pentium 4 3GHz Prescott HT 1024 Fedora Core 9 2:51 5. AMD Athlon XP 2500+ 1,83 GHz 768 Fedora Core 7 4:35 6. AMD Athlon XP 2500+ 1,83 GHz 512 Windows XP 6:10 7. AMD Athlon XP 1800+ 1,53 GHz 512 Windows XP 7:14 8. Mobile AMD Semptron 3500+ 1,81 GHz 384 Windows XP 3:22 9. Intel Pentium Dual E2140 1,6 GHz 1024 Windows XP 1:34 Tabuľka 6: Výkon aplikácie testovaný na nehomogénnych dátach

30 08:24:00

07:12:00 1. Intel Celeron 3,06 GHz 2. Intel Pentium 4 3GHz Pres cott HT 06:00:00 3. Intel Pentium 4 3GHz Pres cott HT 4. Intel Pentium 4 3GHz Pres cott HT 04:48:00 5. AMD Athlon XP 2500+ 1,83 GHz 6. AMD Athlon XP 2500+ 1,83 GHz 03:36:00 7. AMD Athlon XP 1800+ 1,53 GHz 8. Mobile AMD Sem ptron 3500+ 1,81 GHz 02:24:00 9. Intel Pentium Dual E2140 1,6 GHz

01:12:00

00:00:00 Čas

Obrázok 9: Graf výkonu aplikácie s nehomogénnymi dátami

Z porovnania oboch grafov je viditeľný nárast výkonu pri viacjadrovom proce- sore (zostava č. 9), ktorý viditeľne umožňuje vykonávať digitálny podpis efektívnejšie než procesory s jedným jadrom.

31 Záver

Z požiadaviek kladených na funkcionalitu systému transformujúceho pôvodné dokumenty na dokumenty s pripojeným digitálnym podpisom sa podarilo vyvinúť apli- káciu, ktorá stanovené ciele úspešne dosiahla.

Možným rozšírením aplikácie v budúcnosti je doplnenie systému o funkciu časovej pečiatky, ktorá pripojí k dokumentu nielen digitálny podpis, ale aj časový údaj z dôveryhodného zdroja, informujúci o čase podpísania dokumentu. Použitím funkcie časovej pečiatky odpadáva nutnosť obnovy podpisu pri vypršaní platnosti digitálneho certifikátu. Mechanizmus časových pečiatok je pripravovaný autormi knižnice iText v budúcich verziách.

Za podstatný prínos tejto práce by som označil, okrem samotnej aplikácie, podrobnú analýzu a návrh systému reprezentovaného bežne používanými, a preto zrozu- miteľnými, nástrojmi štruktúrovanej analýzy, ktoré umožnia jednoducho uplatniť ďalšie eventuálne požiadavky. Za prínos tiež považujem zhrnutie softvérových produktov, ktoré obsahujú nástroje schopné s výstupnými dokumentmi aplikácie pracovať.

Záverečné testovanie aplikácie poukazuje na skutočnosť, že podpisovanie prebehne aj pri väčšom objeme vstupných dát v prijateľnom čase na rôznych hostiteľských zostavách.

32 Literatúra

[1] Dostálek, L. – Vohnoutová, M. Velký průvodce infrastrukturou PKI a technologií elektornického podpisu. 1. vydanie. Brno: Computer Press 2007. ISBN 80-251-0828-7.

[2] Piper, F. – Murphy S. Cryptography: a very short introduction. 1. vydanie. Oxford: Oxford University Press 2002. ISBN 978-0-19-280315-3.

[3] Zákon o elektronickém podpisu a o změne některých dalších zákonů č. 227/2000 Sb. z.

Internetové zdroje:

www.adobe.com

www.en.wikipedia.org

www.ietf.org

www.lowagie.com

www.nbu.cz

www.sk.wikipedia.org

33 Prílohy

Obsah priloženého CD

Aplikacia: pdfsign.jar – softvérová aplikácia vo formáte jar cert.pfx – certifikát na testovacie účely lib – adresár obsahujúci knižnicu iText source – adresár obsahujúci súbory so zdrojovými kódmi aplikácie

Text bakalarskej prace: bakalarska praca.doc – text práce vo formáte MS Word bakalarska praca.pdf – text práce vo formáte PDF