Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT

Transcription

1 Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT Bc. Ján Tóth ARCHIVÁCIA ELEKTRONICKÉHO PODPISU VYCHÁDZAJÚCA Z FORMÁTU XAdES S PODPOROU DLHODOBEJ OVERITEĽNOSTI Diplomová práca Študijný program: Softvérové inţinierstvo Študijný odbor: Softvérové inţinierstvo Miesto vypracovania: Ústav informatiky a softvérového inţinierstva, FIIT STU Bratislava Vedúci diplomového projektu: Ing. Ján Dobias Pedagogický vedúci: Mgr. Daniela Chudá, PhD. máj 2011

2 Zadanie

3 Anotácia Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Študijný program: Softvérové inžinierstvo Autor: Bc. Ján Tóth Bakalársky projekt: Archivácia elektronického podpisu vychádzajúca z formátu XAdES s podporou dlhodobej overiteľnosti Vedenie bakalárskeho projektu: Ing. Ján Dobias Pedagogický vedúci: Mgr. Daniela Chudá, PhD. Máj, 2011 Práca sa zaoberá rôznymi moţnosťami dlhodobej archivácie elektronického podpisu, pričom sa zameriava najmä na XAdES formát elektronického podpisu a analýzu jeho archívnej formy XAdES-A. V práci sa analyzujú aj iné moţnosti dlhodobej archivácie podpisu. Ide predovšetkým o centralizované archivačné systémy. Cieľom práce je zhrnúť poznatky a prístupy ku archivácii, identifikovať hlavné výhody a nevýhody rôznych prístupov a pokúsiť sa navrhnúť vlastnú úpravu existujúcich štandardov XAdES-A pre dlhodobú archiváciu elektronického podpisu tak, aby sa v čo moţno najväčšej miere odstránili nedostatky a vyuţili sa prednosti rôznych spôsobov archivácie podpisu. Analyzované poznatky sa pretransformujú do návrhu nového formátu archívnej formy podpisu XAdES-A. Bude navrhnutý archivačný systém, ktorý dokáţe vytvárať a overovať elektronický podpis v tomto novom formáte. Tento systém bude taktieţ implementovaný a otestovaný.

4 Annotation Slovak University of Technology Bratislava FACULTY OF INFORMATICS AND INFORMATION TECHNOLOGIES Degree Course: Software engineering Author: Bc. Ján Tóth Bachelor Theses: Archivation of electronic signature based on XAdES with support of longterm verification Supervisor: Ing. Ján Dobias Pedagogical supervisor: Mgr. Daniela Chudá, PhD. May, 2011 This thesis deals with different ways of long-term archiving of electronic signature, mainly it is focused on XAdES electronic signature and its archive form XAdES-A. Another ways of archiving electronic signatures are also described. Centralized archiving systems are particularly described. Aim of this work is to gather all knowledge and all kinds of approach in long-term archiving of electronic signature, indentify advantages and disadvantages of these approaches and to try to design and change of standard XAdES-A in such way, that it could be possible to remove all negatives of this form and to use all positives from others way to archive signature. All kinds of analyzed knowledge can be transformed to new design of XAdES-A. New archiving system for creating and verifying this new form of electronic signature will be also designed. This system will be implemented and tested.

5 Čestné prehlásenie Prehlasujem, ţe som diplomovú prácu vypracoval samostatne s vyuţitím uvedených zdrojov literatúry.... vlastnoručný podpis V Bratislave, dňa...

6 Obsah 1 Úvod a základné pojmy Hashovacia funkcia, hash Elektronický podpis Asymetrické šifry Vytváranie elektronického podpisu Slovenská a európska legislatíva Analýza problému Certifikát verejného kľúča Definícia jednotlivých polí Zoznam revokovaných certifikátov Certifikačná autorita Overovanie certifikátov Autorita pre vydávanie časových pečiatok Časová pečiatka Moţné problémy pri pouţití ČP XML Podpis (XML Signature) XAdES XAdES-BES XAdES-EPES XAdES-T XAdES-C Archivácia podpisu Archívne formy XAdESu SLTAS Problémy spojené s dlhodobou overiteľnosťou podpisu Návrh Architektúra systému Klientská aplikácia Archivačný systém (serverová časť) Návrh dátového modelu Návrh XSD schém podpisov XAdES-T - Klient Archívna forma Opatovné vytváranie časových pečiatok Postup vytvárania tohto elementu je nasledovný Vytváranie, archivovanie a overovanie podpisu Opis riešenia Vytváranie párov kľúčov a certifikátov Implementácia klienta Implementácia archivačného systému Vytváranie archívnej formy podpisu Overovanie archívneho podpisu Vytváranie časových pečiatok Vytváranie opätovných časových pečiatok Databáza Logovanie... 40

7 4.7 Overenie riešenia Overenie generovaných XML dokumentov voči schémam Testovacie scenáre Zhodnotenie Klientská aplikácia Archivačný systém Moţnosti budúceho rozvoja systému Pouţitá literatúra Prílohy Príloha A - Technická dokumentácia Príloha B Pouţívateľská príručka Príloha C - Umiestnenie súborov na DVD médiu... 70

8 Zoznam pouţitých obrázkov a tabuliek Tabuľka 2.1: Certificate (Certifikát)... 5 Tabuľka 2.2: AlgorithmIdentifier... 5 Tabuľka 2.3: TBSCertificate... 5 Tabuľka 2.4: TBSCertList pre CRL... 7 Tabuľka 2.5: revokedcertificates... 7 Tabuľka 2.6: TimeStampReq... 9 Tabuľka 2.7: TSTInfo Tabuľka 2.8: Formáty XAdESu Tabuľka 4.1: Procedúry uloţené v DB Obrázok 3.1 Architektúra systému Obrázok 3.2: Klient Obrázok 3.3: Server Obrázok 3.4: Logický dátový model Obrázok 3.5: Diagram činností pre vytváranie elektronického podpisu Obrázok 3.6: Diagram činností pre vytváranie archívnej formy podpisu Obrázok 4.1: Strom certifikátov Obrázok 4.2: Vrstvy archivačného systému Obrázok 4.3: Sekvenčný diagram pre vytváranie archívneho podpisu Obrázok 4.4: Sekvenčný diagram pre overovanie archívneho podpisu Obrázok B.1: Obnovenie databázy Obrázok B.2: Okno pre vytvorenie nového podpisu Obrázok B.3: Špecifikovanie elmentu QualifyingProperties Obrázok B.4: Oznam o úspešnom vytvorení podpisu Obrázok B.5: Moţnosť zobrazenia podpisu v štandardnej aplikácii pre xml súbory Obrázok B.6: Okno pre archivovanie podpisu Obrázok B.7: Oznam o úspešnom archivovaní podpisu Obrázok B.8: Okno pre overenie archivovaného podpisu Obrázok B.9: Okno pre vyţiadanie archívneho podpisu... 68

9 Zoznam použitých skratiek AS Archivačný systém ASN.1 - Abstract Syntax Notation One CA Certifikačná autorita DB - Databáza EÚ Európska únia NBÚ Národný bezpečnostný úrad ORM Objektovo relačný mapovač PKI Public Key Infrastructure (Infraštruktúra verejného kľúča) SK Súkromný kľúč TS Time-stamp (Časová pečiatka) TSA Time-stamp authority (Autorita pre vydávanie časových pečiatok) TSP Time Stamp Protocol (Protokol časovej pečiatky) UTC Universal Time, Coordinated (Medzinárodný koordinovaný čas) VK Verejný kľúč XAdES XML Advanced Electronic Signature XML extensible markup language XMLDSIG XML Digital Signature (XML digitálny podpis) Z.z. Zbierka zákonov Z Zulu (zodpovedá UTC)

10 1 Úvod a základné pojmy Cieľom tejto práce je preskúmať a analyzovať súčasné spôsoby dlhodobej archivácie elektronického podpisu (najmä vo formáte XAdES). V analýze je dôleţité tieto formy porovnať a zamyslieť sa nad moţnými zmenami pre dlhodobú archiváciu elektronického podpisu. Dokument je rozdelený na niekoľko kapitol. Prvá sa venuje zavedeniu základných pojmov ako je hash, elektronický podpis, asymetrické šifrovanie atď. Druhá kapitola je pomerne podrobne rozoberá problematiku PKI, rôzne spôsoby archivácie elektronického podpisu a snaţí sa porovnať tieto spôsoby. Tretia kapitola Návrh vychádza z poznatkov zosumarizovaných v predchádzajúcich kapitolách a na základe týchto vedomostí je v tejto kapitole uvedený návrh systému pre dlhodobú archiváciu elektronického podpisu. Ďalšou kapitolou je Opis riešenia, kde je opísaný spôsob implementácie všetkých časí navrhovaného systému a je tu taktieţ uvedené aj overenie tohto riešenia. Poslednou kapitolou je Zhodnotenie, kde sú zhrnuté výsledky tejto práce a kapitola obsahuje aj moţné smerovanie ďalšieho vývoja navrhovaného systému. Práca obsahuje aj tri nasledovné prílohy: technická dokumentácia, pouţívateľská príručka a výpis umiestnenia súborov na pribalenom DVD médiu. 1.1 Hashovacia funkcia, hash Hashovacia funkcia vytvára z veľkých reťazcov rôznej dĺţky konštantné reťazce hashe, hash hodnoty. Hash digitálny odtlačok, je vlastne nejaký reťazec reprezentujúci digitálny dokument, hash je výsledok hashovacej funkcie. Ţelanou vlastnosťou takýchto funkcií je, aby mali akékoľvek dokumenty rôznu hodnotu hashu. Tým je moţné zabezpečiť aby aj sa aj veľmi malá zmena elektronického dokumentu premietla do zmeny hashu tohto dokumentu a tak môţeme hash povaţovať za reprezentáciu dokumentu. Existuje niekoľko hashovacích funkcií napr. MD5 (táto funkcia uţ nie je povaţovaná za bezpečnú), SHA1, hashovacie funkcie rodiny SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512), SHA3 (hashovacia funkcia, ktorá by sa v budúcnosti mala stať štandardom, momentálne sa stále vyvíja). 1.2 Elektronický podpis Elektronický podpis môţe poskytovať dôkaz o pravosti elektronického dokumentu. V niektorých krajinách v závislosti od ich zákonov je moţné ho vyuţiť aj ako náhradu 1

11 klasického podpisu. V nasledujúcich podkapitolách bude podpísaný základný princíp vytvárania a overovania elektronického podpisu Asymetrické šifry Asymetrické šifry tvoria základ elektronického podpisu. Ide o šifry, ktoré vyuţívajú dvojicu pár kľúčov, verejný (VK) a súkromný kľúč (SK). Súkromný kľúč sa vyuţíva na vytvorenie elektronického podpisu. Tým je zaručené, ţe nikto iný nemohol vytvoriť elektronický podpis, iba majiteľ dvojice kľúčov (vychádzame z predpokladu, ţe takáto dvojica kľúčov bola vytvorená náhodne a nikto majiteľovi neodcudzil jeho SK a nemohol ho tak zneuţiť). Hocikto potom môţe pomocou VK kľúču overiť platnosť podpisu. Základnou myšlienkou je, ţe pomocou SK je relatívne veľmi jednoduché vytvoriť podpis. Taktieţ je jednoduché overiť podpis pomocou VK, no bez znalosti SK je matematicky veľmi náročné dešifrovať hodnotu podpisu a tým získať pôvodné podpisované dáta a zneuţiť ich RSA Ide o najpouţívanejší algoritmus. Jeho autormi sú Ron Rivest, Adi Shamir a Leonard Adleman, podľa ktorých je algoritmus aj pomenovaný. Prvýkrát bol algoritmu predstavený v roku Algoritmus vyuţíva SK/VK kľúč. Je povaţovaný za bezpečný, ak je dĺţka kľúčov aspoň 1024 bitov [4] ECC Elliptic Curve Cryptography Kryptografia eliptických kriviek. Kľúč dĺţky 1024 bitov pre algoritmus RSA zodpovedá pribliţne 160 bitov dlhému kľúču pre algoritmus ECC, pričom je výpočtová náročnosť pribliţne rovnaká [4] Vytváranie elektronického podpisu Postup vytvárania elektronického podpisu 1. Výpočet hashu dokumentu. 2. Vytvorenie podpisu nad hashom dokumentu pomocou súkromného kľúča. Overenie elektronického podpisu 1. Výpočet hashu prijatého dokumentu. 2. Dešifrovanie podpisu pomocou verejného kľúča a tým získanie podpisovaného hashu dokumentu. 3. Overenie hashov z bodov 1 a 2, ak sa rovnajú, môţeme podpis vyhlásiť za platný. 2

12 1.2.3 Slovenská a európska legislatíva V rámci legislatívy Európskej únie upravuje pouţívanie elektronického podpisu Smernica Európskej únie č. 1999/93/EC z decembra Na Slovensku pouţívanie elektronického podpisu upravuje Zákon o elektronickom podpise č. 215/2002 Z.z. v znení neskorších právnych predpisov. Zákon nadobudol účinnosť 1. septembra 2002 (jeho posledná novelizácia prebehla v roku 2008). Zákon upravuje vzťahy vznikajúce v súvislosti s vyhotovovaním a pouţívaním elektronického podpisu, práva a povinnosti fyzických a právnických osôb pri pouţívaní elektronického podpisu, hodnovernosť a ochranu elektronických dokumentov podpísaných elektronickým podpisom. Národný bezpečnostný úrad (NBÚ) je ústredným orgánom štátnej správy pre elektronický podpis [7]. Zákon je okrem toho doplnený niekoľkými Vyhláškami NBÚ z roku 2009, ktoré upravujú napr. pouţívanie certifikátov resp. kvalifikovaných certifikátov, pouţívaní elektronického podpisu v obchodnom a administratívnom styku atď. 3

13 2 Analýza problému 2.1 Certifikát verejného kľúča Certifikát je elektronický dokument, ktorý dokazuje, ţe daná osoba je skutočným vlastníkom verejného kľúča a k nemu prislúchajúcemu súkromnému kľúču. Obsahuje verejný kľúč majiteľa páru kľúčov a jeho identifikačné údaje [4]. Certifikáty vydáva nezávislá tretia strana Certifikačná autorita (CA). Všetky poloţky sú podpísané certifikačnou autoritou, t.j. certifikát je taktieţ elektronicky podpísaný dokument. Certifikát je moţné získať dokumentom Ţiadosť o certifikát. Štruktúra Certifikátu verejného kľúča je definovaná štandardom RFC5280 nasledovne (opísanej pomocou jazyka ASN.1, všetky ďalšie štruktúry PKI sú v tejto práci taktieţ opísané pomocou jazyka ASN.1) [3]: Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } Štruktúra poloţky AlgorithmIdentifier je nasledovná: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Štruktúra poloţky TBSCertificate je nasledovná: TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueid [1] IMPLICIT UniqueIdentifier OPTIONAL, 4

14 } subjectuniqueid [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] EXPLICIT Extensions OPTIONAL Definícia jednotlivých polí V Tabuľke 2.1 sú vysvetlené poloţky štruktúry Certificate. Tabuľka 2.1: Certificate (Certifikát) Certificate tbscertificate Obsahuje sekvenciu TBSCertificate signaturealgorithm Sekvencia AlgorithmIdentifier signaturevalue Obsahuje digitálny podpis vytvorený nad ASN.1 DER kódovanou štruktúrou tbscertificate algorithm parameters Tabuľka 2.2: AlgorithmIdentifier AlgorithmIdentifier Identifikuje algoritmus (napr. SHA- 1, DSA,...) Obsahuje voliteľné parametre, ktoré môţu byť špecifikované pouţitým algoritmom version serialnumber signature issuer validity subject subjectpublickeyinfo Tabuľka 2.3: TBSCertificate TBSCertificate Definuje verziu certifikátu Poradové číslo certifikátu Sekvencia AlgorithmIdentifier CA, ktorá vydala certifikát Obsahuje 2 poloţky notbefore a notafter, ktoré vymedzujú platnosť certifikátu Identifikuje entitu Obsahuje verejný kľúč a taktieţ špecifikuje algoritmus, 5

15 issueruniqueid subjectuniqueid extensions s ktorým sa kľúč pouţíva pomocou algorithmidentifier Poloţky slúţia na jednoznačnú identifikáciu vydavateľa certifikátu (CA) a predmet certifikátu, musia byť prítomné ak ide o verziu certifikátu 2 alebo 3, ak je certifikát verzie 1, poloţky nesmú byť pouţité Obsahuje rôzne rozšírenia certifikátu, ktoré špecifikujú napr. pouţitie kľúča, certifikačnú politiku, atď. V Tabuľke 2.2 a 2.3 sú vysvetlené všetky poloţky štruktúr AlgorithmIdentifier a TBSCertificate. 2.2 Zoznam revokovaných certifikátov Platnosť certifikátov verejného kľúča je vymedzená poloţkami notbefore a notafter. Po uplynutí času uvedeného v poloţke notafter nie je moţné certifikát pouţívať. Okrem tohto spôsobu môţe certifikát stratiť platnosť, ak ho CA vyhlási za neplatný certifikát sa stáva revokovaný. K tomu môţe dôjsť napríklad, ak majiteľovi niekto odcudzí súkromný kľúč a on potom poţiada CA o revokáciu certifikátu. Neplatné certifikáty sú uvádzané v dokumentoch s názvom Zoznam revokovaných (odmietnutých) certifikátov (Certificate revocation list - CRL), ktoré kaţdá CA pravidelne vydáva. Štruktúra je veľmi podobná štruktúre certifikátu a je taktieţ definovaná štandardom RFC-5280 [3]: Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } Odlišná je najmä štruktúra poloţky TBSCertList: TBSCertList ::= SEQUENCE { version signature issuer thisupdate nextupdate Version OPTIONAL, AlgorithmIdentifier, Name, Time, Time OPTIONAL, 6

16 } revokedcertificates SEQUENCE OF SEQUENCE { usercertificate CertificateSerialNumber, revocationdate Time, crlentryextensions Extensions OPTIONAL } OPTIONAL, crlextensions [0] EXPLICIT Extensions OPTIONAL Tabuľka 2.4 podrobne popisuje jednotlivé poloţky štruktúry TBSCertList pre CRL. version signature issuer thisupdate nextupdate crlextensions Tabuľka 2.4: TBSCertList pre CRL TBSCertList Definuje verziu zoznamu, ak je vyuţitá poloţka crlextensions, hodnota musí byť 2 Identifikuje algoritmus pouţitý na podpis CRL Identifikuje CA, ktorá daný CRL vydala Obsahuje čas vydania CRL Obsahuje čas vydania nasledujúceho CRL Rozšírenia CRL, môţu sa objaviť iba s verziou 2 CRL obsahuje poloţku revokedcertificated, ktorá obsahuje zoznam revokovaných certifikátov. Ak ţiadne takéto certifikáty neexistujú, tak sa táto poloţka v CRL nesmie nachádzať. Jej podrobnejšia štruktúra je bliţšie opísaná v nasledovnej tabuľke. usercertificate revocationdate crlentryextensions Tabuľka 2.5: revokedcertificates revokedcertificates Sériové číslo revokovaného certifikátu Čas revokovania certifikátu Ďalšie rozšírenia záznamu, táto poloţka sa dá pouţiť iba s verziou 2 7

17 2.3 Certifikačná autorita Certifikačná autorita (CA) je nezávislá inštitúcia, ktorá vydáva certifikáty verejného kľúča (certifikáty môţu byť vydávané súkromným osobám ale aj iným certifikačným autoritám). Na to by mohla vydávať certifikáty musí byť vlastníkom certifikátu verejného kľúča, ktorý jej umoţňuje vydávať certifikáty. Certifikát môţe získať tak, ţe jej ho vydá iná certifikačná autorita alebo si tento certifikát vydá sama. V druhom prípade pôjde o sefl-signed certifikát, v takom prípade ide o koreňovú CA Overovanie certifikátov Samotné overovanie elektronického podpisu nepozostáva len z matematického overenia hodnoty elektronického podpisu tak, ako je to uvedené v kapitole Pri overovaní je potrebné overiť aj certifikát. Ten musí byť platný, t.j. jeho platnosť nevypršala alebo nie je uvedený na zozname CRL. Okrem toho tento certifikát mohol byť vydaný ľubovoľnou certifikačnou autoritou z mnoţstva CA po celom svete. Overovateľ podpisu by mal akceptovať podpis, len ak certifikát vydala certifikačná autorita, ktorú povaţuje za dôveryhodnú (jej certifikát je uvedený v jeho zozname dôveryhodných CA). Z poznatku v uvedeného v kapitole 2.3 vyplýva, ţe certifikát nemusela vydať dôveryhodná certifikačná autorita, ale certifikát tejto CA mohol byť vydaný certifikačnou autoritou, ktorú overovateľ elektronického podpisu povaţuje za dôveryhodnú (resp. medzi certifikátom CA, ktorá vydala certifikát vyuţitý pri tvorbe overovaného elektronického podpisu, a certifikátom dôveryhodnej CA môţe byť ľubovoľný počet CA). Pri overovaní podpisu je preto potrebné zostaviť certifikačnú cestu, ktorá vedie aţ ku certifikátu CA, ktorú overovateľ povaţuje za dôveryhodnú [4]. 2.4 Autorita pre vydávanie časových pečiatok Podobne ako existuje CA pre vydávanie certifikátov, existuje Autorita pre vydávanie časových pečiatok (TSA). Komunikáciu medzi ţiadateľmi časovej pečiatky a TSA a vydávanie samotných časových pečiatok špecifikuje protokol TSP, ktorý je definovaný v štandarde RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol. 8

18 2.5 Časová pečiatka Časová pečiatka je určitým spôsobom dokument, ktorý hovorí o tom, ţe nejaké dáta existovali v presne stanovenom časovom okamihu. Časová pečiatka je nevyhnutnou súčasťou procesu dlhodobej archivácie elektronického podpisu. Vytváranie ţiadosti o vydanie časovej pečiatky a jej štruktúru, odpovede TSA a štruktúru samotnej pečiatky definuje RFC3161. Komunikácia medzi jednotlivými entitami pri ţiadosti a vytváraní časovej pečiatky je definovaná pomocou protokolu TSP (Time Stamp Protocol). Pre získanie časovej pečiatky je potrebné vytvoriť ţiadosť o časovú pečiatku (TimeStampReq), jej štruktúra je definovaná štandardom RFC 3161 nasledovne [1]: TimeStampReq ::= SEQUENCE { version INTEGER { v1(1) }, messageimprint MessageImprint, reqpolicy TSAPolicyId OPTIONAL, nonce INTEGER OPTIONAL, certreq BOOLEAN DEFAULT FALSE, extensions [0] IMPLICIT Extensions OPTIONAL } version messageimprint reqpolicy nonce certreq extensions Tabuľka 2.6: TimeStampReq TimeStampReq Špecifikuje pouţitú verziu TimeStampReq Obsahuje hash dát, nad ktorými je potrebné vytvoriť časovú pečiatku a taktieţ obsahuje identifikátor algoritmu pouţitého na výpočet hashu Obsahuje identifikátor politiky, ktorá by mala byť pouţitá TSA Veľké náhodné číslo Špecifikuje či je potrebné v odpovedi TSA zahrnúť aj jej certifikát verejného kľúča rozšírenia V Tabuľke 2.6 sú uvedené všetky poloţky štruktúry TimeStampReq. TSA potom odpovedá štruktúrou Odpoveď časovej pečiatky (TimeStampResp): 9

19 TimeStampResp ::= SEQUENCE { status PKIStatusInfo, timestamptoken TimeStampToken OPTIONAL } Dôleţitou súčasťou odpovede je štruktúra PKIStatusInfo. Tá informuje o tom, či bola ţiadosť v poriadku. V prípade, ţe nie, uvádza sa v nej dôvod zamietnutia ţiadosti. Ak je ţiadosť v poriadku, tak sa v TimeStampResp musí nachádzať aj poloţka TimeStampToken. PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusstring PKIFreeText OPTIONAL, failinfo PKIFailureInfo OPTIONAL } Základom štruktúry TimeStampToken je TSTInfo, ktorej štruktúra je definovaná nasledovne: TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageimprint MessageImprint, serialnumber INTEGER, gentime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL } Tabuľka 2.7 podrobne opisuje všetky poloţky štruktúry TSTInfo. version policy Tabuľka 2.7: TSTInfo TSTInfo Špecifikuje verziu Identifikátor politiky, musí ísť o rovnakú hodnotu aká je v rovnakej poloţke uvedená v ţiadosti o časovú pečiatku (TimeStampReq) 10

20 messageimprint serialnumber gentime accurancy ordering nonce tsa extensions Odtlačok správy, opäť musí ísť o totoţnú hodnotu ako v TimeStampReq Sériové číslo, v rámci TSA by malo ísť o jedinečné číslo Uvádza čas vytvorenia časovej pečiatky v tvare YYYYMMDDhhmmss[.s...]Z 1 Ide o voliteľnú poloţku, upresňuje časovú odchýlku od UTC času Ak je táto poloţka prítomná, tak všetky časové pečiatky od danej TSA môţu byť zoradené podľa poloţky gentime (bez ohľadom na accurancy) Hodnota nonce sa musí byť vyplnená ak je uvedená aj v TimeStampReq a musí byť vyplnená rovnakou hodnotou Slúţia na identifikáciu TSA Rozšírenia Možné problémy pri použití ČP Aj keď časová pečiatka dokazuje, ţe nejaké dáta existovali v určitom čase, stále ide o podpísaný dokument, ktorého platnosť je nepriamo spojená s certifikátom TSA, ktorá časovú pečiatku vydala. Pri overovaní pečiatky preto potrebné vykonávať podobnú procedúru overovania certifikátov ako pri overovaní certifikátu verejného kľúča. Pre certifikát TSA a časovú pečiatku platí, ţe by jeho platnosť mala byť oveľa dlhšia ako platnosť certifikátu pouţívateľa, ktorý vytvoril podpis. TSA získava nový certifikát v predstihu aby sa platnosť starého a nového certifikátu prekrývali a bolo moţné všetky časové pečiatky overiť resp. obnoviť. 2.6 XML Podpis (XML Signature) Ide o XML formát elektronického podpisu (ďalej ako XMLDSIG). Definuje ho štandard XML Signature Syntax and Processing, ktorý jasne špecifikuje obsah všetkých elementov, ktoré 1 YYYYMMDDhhmmss[.s..]Z príklad Z (YYYY rok, MM mesiac, DD deň, hh hodiny, mm minúty, ss - sekundy) 11

21 musí dokument obsahovať, spôsob a postup vypočítavania a overovania elektronického podpisu. Príklad XML podpisu je moţné nájsť v Prílohe 1. Ukáţka XML štruktúry XAdES formátu. Všetky dátové objekty, ktoré budú podpísané sa nachádzajú v elemente ds:object. Kaţdý takýto objekt je referencovaný pomocou elementu Reference, ktorý obsahuje hash hodnotu dátového objektu. Presný spôsob vytvárania XML podpisu je popísaný niţšie. Na základe umiestnenia podpisovaných dát v XML dokumente, rozlišujeme tieto druhy XML elektronického podpisu [5]: 1. enveloping dáta, nad ktorými je vytváraný elektronický podpis, sa nachádzajú vo vnútri XML štruktúry podpisu (pod elementom ds:singature) 2. enveloped XML dáta, nad ktorými je vypočítavaný podpis uţ obsahujú element pre hodnotu podpisu, tento fakt je potrebné zohľadniť pri vytváraní/overovaní elektronického podpisu 3. detached podpisovaný obsah sa nachádza mimo XML dokumentu napríklad v inom súbore, preto je vo vzťahu k Signature elementu detached - oddelený Vytváranie podpisu môţeme rozdeliť na 2 kroky, prvým je vytváranie referencií [5]: 1. Aplikovanie transformačných algoritmov na dátový objekt. 2. Výpočet hash hodnoty. 3. Vytvorenie elementu Reference (ktorý obsahuje aj informácie o transformačnom algoritme z bodu 1., algoritmus pouţitý pri výpočet hash hodnoty a samotnú hash hodnotu). Počet objektov, ktoré je moţné podpísať je neobmedzený. Druhou časťou je vytvorenie samotného podpisu. 1. Vytvorenie elementu SignedInfo (obsahuje SignatureMethod, CanonicalizationMethod a všetky elementy Reference). 2. Kanonizácia elementu SignedInfo a výpočet hodnoty elektronického podpisu (tá sa bude nachádzať v elemente SignatureValue). 3. Vytvorenie elementu Signature, ktorý obsahuje elementy SignedInfo, Object, KeyInfo, a SignatureValue. 12

22 Validáciu elektronického podpisu môţeme taktieţ rozdeliť na dva kroky. Prvým je validácia referencii [5]: 1. Kanonizácia elementu SignedInfo algoritmom, ktorý je uvedený v elemente CanonicalizationMethod. 2. Pre všetky elementy Reference sa aplikuje nasledovný postup: a. získanie dátového objektu, na ktorý odkazuje element Reference a aplikovanie transformačného algoritmu, ak je to potrebné b. výpočet hash hodnoty dátového objektu pomocou algoritmu, ktorý je uvedený v elemente DigestMethod c. porovnanie vypočítanej hodnoty hashu s tou, ktorá je uvedená v elemente Reference, ak tieto hodnoty nie sú rovnaké, elektronický podpis nie je platný (ukončenie validácie) Druhým krokom je overenie samotnej hodnoty podpisu. Postup je štandardom definovaný nasledovne: 1. Získanie informácii o VK z elementu KeyInfo (alebo z iného zdroja). 2. Získanie spôsobu výpočtu elektronického podpisu z elementu SignatureMethod a pomocou získaného kľúča overenie hodnoty podpisu (SignatureValue) získaného nad elementom SignedInfo. Ak oba kroky prebehli úspešne, elektronický podpis je platný. 2.7 XAdES XML Advanced electronic signature (XAdES) je XML formát elektronického podpisu. Ide o rozšírenie štandardu XMLDSIG opísaného v kapitole 2.6. Je produktom ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). Štandard je vydaný v súlade s platnou legislatívou EÚ [6]. Výraznou mierou rozširuje XMLDSIG o ďalšie prvky a mechanizmy pre zabezpečenie elektronického podpisu. Môţeme rozoznať 7 rôznych formátov XAdESu, ktoré sú uvedené v nasledovnej tabuľke. Formát XAdES-BES (Basic Electronic Signature) Tabuľka 2.8: Formáty XAdESu Popis Základný formát postavený nad XMLDSIG Rozširuje XMLDSIG o element SignedProperties a nepodpisovaný 13

23 XAdES-EPES (Explicit Policy based Electronic Signature ) XAdES-T (TimeStamp) XAdES-C (Complete Validation Data) XAdES-X (extended validation data) XAdES-X-L (extended validation data incorporated for the long term) XAdES-A (Archiving validation data) nepovinný element UnsignedProperties Rozširuje XMLDSIG resp. XAdES-BES o povinný element SignaturePolicyIdentifier, ktorý slúţi na identifikáciu podpisovej politiky a musí byť vyuţitý pri overovaní podpisu Rozširuje základný formát o časovú pečiatku, ktorá sa potom vkladá do elementu SignatureTimeStamp Pridáva údaje, ktoré sa vyuţijú pri validácii elektronického podpisu (referencie na certifikačnú cestu, informácie o revokovaných certifikátov) Pridáva časovú pečiatku nad validačnými údajmi alebo nad elementom Signature, ochrana pred kompromitovaním certifikátov alebo kľúčov Pridáva validačné dáta pre dlhodobé uchovávanie elektronického podpisu Pridáva ďalšie validačné dáta a časové pečiatky, aby bol podpis chránený aj v prípade, ţe kryptografické algoritmy pouţité pri je ho vytváraní budú vyhlásené, za kryptograficky slabé XAdES-BES - rozširuje základný formát podpisu o povinný podpisovaný element SignedProperties a nepovinný podpisovaný element UnsignedProperties - pomocou neho je chránený podpisovaný certifikát, môţe to nastať 2 spôsobmi: - zahrnutím certifikátu do elementu SigningCertificate - element SigningCertificate môţe byť vynechaný, v takom prípade je potrebné je certifikát zahrnúť do elementu ds:keyinfo 14

24 - okrem toho môţe zahŕňať nasledovné elementy [6]: - SigningTime, - DataObjectFormat, - CommitmentTypeIndication, - SignerRole, - SignatureProductionPlace, - jeden z IndividualDataObjectsTimeStamp alebo AllDataObjectsTimeStamp, jeden alebo viac elementov CounterSignature (ide o nepodpisovaný element) XAdES-EPES - je postavený na XAdES-BES podpise resp. XML podpise - zavádza povinný element SignaturePolicyIdentifier XAdES-T - tento formát môţe byť pouţitý ak existuje dôveryhodný čas spojený s podpisom, ten môţe byť reprezentovaný dvomi spôsobmi: - zahrnutím elementu SignatureTimeStamp pod element UnsignedProperties <UnsignedSignatureProperties> (CounterSignature) (SignatureTimeStamp) </UnsignedSignatureProperties> - vytvorením časovej pečiatky treťou stranou (samotná pečiatka sa potom nenachádza v XAdES dokumente a je zodpovednosťou vyhotoviteľa časovej pečiatky, aby zabezpečil vhodný spôsob dôkaz o existencii podpisu v danom čase) XAdES-C - rozširuje formát XAdES-T o dva resp. štyri elementy uvedené v nasledujúcej XML štruktúre: <UnsignedSignatureProperties> (CounterSignature)* 15

25 (SignatureTimeStamp) (CompleteCertificateRefs) (CompleteRevocationRefs) (AttributeCertificateRefs)? (AttributeRevocationRefs)? </UnsignedSignatureProperties> - CompleteCertificateRefs element obsahuje referencia na všetky certifikáty CA, ktoré sú potrebné pri overovaní elektronického podpisu (bez certifikátu potrebného pri vytváraní podpisu) - CompleteRevocationRefs obsahuje všetky referencie na validačné dáta, ktoré je potrebné vyuţiť pri overovaní elektronického podpisu - AttributeCertificateRefs a AttributeRevocationRefs elementy obsahujú analogicky referencie na atribútové certifikáty V Prílohe 1 je uvedená kompletná XML štruktúra XAdES-EPES formátu elektronického podpisu. 2.8 Archivácia podpisu Časom sa môţe stať, ţe dokazovať a overiť elektronický podpis a časovú pečiatku môţe zlyhať z niekoľkých dôvodov. Napríklad nemusia existovať alebo byť dostupné všetky revokačné informácie, alebo samotný certifikát vyuţitý pri podpise stratí platnosť alebo algoritmus vyuţitý na vytvorenie podpisu je uţ povaţovaný za slabý. Aj napriek tomu, je ţiaduce mať moţnosť overiť elektronický podpis aj po veľmi dlhej dobe. K tomu slúţia archívne formy elektronického podpisu [2] Archívne formy XAdESu Ako je zrejmé z Tabuľky 2.8, na archiváciu elektronického podpisu formátu XAdES sa vyuţívajú jeho dve formu a to XAdES-X-L a XAdES-A. Formát XAdES-X-L vychádza z formátu XAdES-X XAdES-X XAdES-X vychádza z formy XAdES-C a rozširuje ju o jednu aţ viacero časových pečiatok. Na základe toho, nad akými elementmi sa vytvára časová pečiatka rozlišujeme dva typy X 16

26 formy. Obe vytvárajú spoločne časovú pečiatku nad elementmi CompleteCertificateRefs a CompleteRevocationRefs. Poskytujú ochranu všetkých referencií v uvedených elementoch ak by bol napríklad kľúč CA kompromitovaný [6] XAdES-X typ 1 Časová pečiatka je vytváraná nad elementmi SignatureValue, SignatureTimeStamp (ak je tento element prítomný), CompleteCertificateRefs, CompleteRevocationRefs. Časová pečiatka sa potom nachádza pod elementom SigAndRefsTimeStamp (týchto elementov môţe byť viac, pričom kaţdý z nich by mal obsahovať časovú pečiatku od inej TSA) XAdES-X typ2 Časová pečiatka resp. pečiatky sa nachádzajú pod elementom RefsOnlyTimeStamp. Z názvu je zrejmé, ţe pečiatka je vytváraná nad elementmi CompleteCertificateRefs a CompleteRevocationRevs. <UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)* (CompleteCertificateRefs) (CompleteRevocationRefs) (AttributeCertificateRefs)? (AttributeRevocationRefs)? (SigAndRefsTimeStamp)* (RefsOnlyTimeStamp)* </UnsignedSignatureProperties> XAdES-X-L Je postavený na oboch typoch XAdES-X a rozširuje ich o elementy CertificateValues a RevocationValues. <UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)* (CompleteCertificateRefs) (CompleteRevocationRefs) (AttributeCertificateRefs)? (AttributeRevocationRefs)? (SigAndRefsTimeStamp)* 17

27 (RefsOnlyTimeStamp)* (CertificatesValues) (RevocationValues) (AttrAuthoritiesCertValues)? (AttributeRevocationValues)? </UnsignedSignatureProperties> Element CertificateValues obsahuje všetky certifikáty potrebné pre overenie elektronického podpisu vrátane toho, ktorý bol pouţitý pri vytváraní elektronického podpisu (ten však nemusí byť uvedený pod týmto elementom, stačí ak je uvedený v elemente SigningCertificate resp. v elemente ds:keyinfo. Element RevocationValues obsahuje všetky revokačné dáta (CRL) potrebné pri overovaní a vyhodnocovaní elektronického podpisu. Všetky tieto údaje by mali byť získané čo moţno v najkratšom čase od vytvorenia podpisu. Formát XAdES-X-L môţe analogicky ako formát XAdES-X obsahovať elementy AttrAuthoritiesCertValues resp. AttributeRevocationValues XAdES-A Rozširuje podpis o jeden alebo viac elementov xadesv141:archivetimestamp, ktorý sa nachádza pod elementom UnsignedProperties. Prefix xadesv141 špecifikuje XML Namespace Tento element je prítomný od verzie a nahrádza element ArchiveTimeStamp z predchádzajúcich verzií podpisu. <UnsignedSignatureProperties> (xadesv141:timestampvalidationdata (CounterSignature)* ((SignatureTimeStamp) (xadesv141:timestampvalidationdata)?)* (CompleteCertificateRefs) (CompleteRevocationRefs) (AttributeCertificateRefs)? (AttributeRevocationRefs) ( (SigAndRefsTimeStamp xadesv141:timestampvalidationdata?) (RefsOnlyTimeStamp xadesv141:timestampvalidationdata?) )* (CertificatesValues) (RevocationValues) 18

28 (AttrAuthoritiesCertValues)? (AttributeRevocationValues)? ( (xadesv141:archivetimestamp xadesv141:timestampvalidationdata? )+ </UnsignedSignatureProperties> xadesv141: TimeStampValidationData Ide o nepovinný element, ktorý sa nachádza pod elementom UnsignedProperties. Obsahuje rôzne validačné dáta, ktoré sú potrebné pri overovaní všetkých časových pečiatok pouţitých kdekoľvek v danom XAdES dokumente. Element TimeStampValidation data na to vyuţíva uţ opísané elementy CertificateValues resp. RevocationValuse v kapitole Element CertificateValues obsahuje všetky potrebné certifikáty pre overenie všetkých časových pečiatok v danom dokumente. Obsahuje všetky revokačné údaje, ktoré sú potrebné pri overovaní ktorejkoľvek časovej pečiatky v dokumente xadesv141:archivetimestamp Tento element slúţi na ochranu všetkých údajov, ak by niekedy v budúcnosti rôzne kryptografické algoritmy boli prelomené resp. tieto algoritmy by uţ boli povaţované za kryptograficky slabé. Element ArchiveTimeStamp obsahuje časovú pečiatku nad kompletnými validačnými dátami (certifikáty, revokačné údaje,...) a samotným podpisom. Vytvorenie takejto časovej pečiatky je dôleţité, ak ktorákoľvek hashovacia funkcia alebo kryptografický algoritmus uţ nebudú povaţované za dostatočne bezpečné. Tento proces je dôleţité vykonať a opakovať predtým ako boli tieto algoritmy vyhlásené za slabé, preto je moţné, ţe tieto archivačné dáta budú pozostávať z viacerých časových pečiatok [6]. Pri vytváraní elementu ArchiveTimeStamp je podstatné umiestnenie elementov, nad ktorými sa vytvára časová pečiatka. Ak majú všetky tieto elementy spoločný rodičovský element, tak sa vyuţíva implicitný mechanizmus, v opačnom prípade sa vyuţíva explicitný mechanizmus. Moţnou nevýhodou formátu XAdESu-A je, ţe všetky údaje pre overenie podpisu (certifikáty, časové pečiatky,...) sú súčasťou výsledného XML dokumentu. To môţe spôsobiť neúmerný nárast veľkosti podpisovaného dokumentu. Napríklad dokument, ktorý mal pred podpísaním niekoľko sto kilobajtov, tak výsledný podpísaný dokument môţe mať veľkosť aj niekoľko desiatok megabajtov. Moţným riešením ako predísť podobnému problému je oddeliť validačné údaje od podpisu a zabezpečiť ich centrálne uchovávanie. 19

29 2.8.2 SLTAS STLAS predstavuje Secure Long-Term Archival System Zabezpečený systém pre dlhodobú archiváciu. Autori vychádzajú z uţ spomínanej myšlienky, aj napriek tomu, ţe súčasné kryptografické algoritmy (napr. RSA) sú povaţované za bezpečné a dokumenty podpísané týmito algoritmami sú dobre chránené. V budúcnosti je moţné očakávať (dokonca je to veľmi pravdepodobné), ţe tieto algoritmy budú prelomené aj vďaka stále zdokonaľujúcej sa kryptografii a taktieţ neustále stúpajúcej výpočtovej sile počítačov [9]. SLTAS si ukladá 3 jednoznačné poţiadavky pri archivácii elektronicky podpísaných dokumentov: 1. dokument bol podpísaný medzi 2 jednoznačne identifikovateľnými a nezameniteľnými okamihmi 2. od podpísania dokumentu nebol jeho obsah nijakým spôsobom zmenený 3. v čase vytvárania podpisu pomocou validného SK Navrhovaný protokol pozostáva z troch veľmi dôleţitých fáz. Prvou je, ţe klient vytvorí balík, ktorý pozostáva z podpísaného dokumentu, ktorý si klient ţelá archivovať, dôkazu kedy bol podpis vytvorený časová pečiatka a dôkazu, ţe kľúč vyuţitý na vytvorenie podpisu je platný. Takýto balík potom systém STLAS vyhodnotí a ak spĺňa všetky podmienky, tak je dokument archivovaný. Klient potom môţe kedykoľvek dokument získať z archivačného systému naspať. Dôleţitým rozdielom medzi inými archivačnými sluţbami, protokolmi alebo štandardmi, ktoré sa venujú dlhodobej archivácii elektronického podpisu a podpísaným dokumentov je, ţe tento systém vyţaduje vytvorenie časovej pečiatky aj pred vytvorením podpisu. To znamená, ţe v konečnom dôsledku existujú 2 časové pečiatky, prvá je vytvorená pred vytváraním podpisu a druha po vytvorení podpisu (tým je splnená podmienka z bodu 1). Ďalším dôleţitým aspektom je vyţadovanie platnosti certifikátu vyuţitého pri podpisovaní dokumentu v čase archivácie. Postup archivácie (klient): 1. vytvorenie časovej pečiatky pred podpísaním dokumentu, časová pečiatka je vytvorená na tzv. inicializačným vektorom (túto hodnotu pozná klient a aj systém SLTAS) 20

30 2. vytvorenie podpisu nad dokumentom a zároveň časovou pečiatkou, takto je moţné garantovať, ţe podpis bol zaručene vytvorený a existoval po čase, ktorý stanovuje časová pečiatka ČP0 3. vytvorenie druhej časovej pečiatky nad elektronickým podpisom, týmto je zabezpečená podmienka 1 zo začiatku kapitoly, elektronický podpis je vytvorený medzi dvomi jednoznačne identifikovateľnými časmi 4. vytvorený balík môţe byť odoslaný systému SLTAS Postup archivácie (server) 1. systém dostane balíček od klienta a štandardným postupom overí elektronický podpis a časové pečiatky 2. za určitých podmienok môţe existovať taká politika systému, ktorá stanovuje maximálny časový rozdiel medzi dvomi časovými pečiatkami, ak balík od klienta túto poţiadavku nespĺňa, nemôţe byť archivovaný 3. ak sú úspešne vykonané predchádzajúce dva body, systém vytvorí novú počiatku, ktorá všetko zaobaľuje 4. archivuje sa celý balík Systém takisto poskytuje automatické obnovovanie časových pečiatok. Klientom systému je taktieţ dovolené kedykoľvek archivované dokumenty získať zo systému alebo poţiadať o ich zmazanie Problémy spojené s dlhodobou overiteľnosťou podpisu Pri vytváraní podpisu s podporou jeho dlhodobej overiteľnosti je potrebné riešiť nasledovné problémy: - časová pečiatka je podpísaný dokument má obmedzenú platnosť, časovú pečiatku je taktieţ potrebné overovať spôsobom ako podpis pomocou certifikačnej cesty - na podpis časovej pečiatky bol pouţitý certifikát, ktorému skončila platnosť, je potrebné mať dôkaz o tom, ţe pečiatka bola vytvorené v dobe platnosti certifikátu - certifikát pouţitý na vytvorenie podpisu môţe byť neplatný (skončila jeho platnosť) alebo sa objaví na CRL - certifikátom, ktoré sa nachádzajú na certifikačnej ceste, môţe skončiť platnosť alebo sa objavia na CRL 21

31 - algoritmus, ktorý bol pouţitý na výpočet hashu alebo hodnoty elektronického podpisu sa podarí prelomiť (bude moţné zameniť podpisovaný objekt za iný, ktorý bude mať rovnakú hodnotu hashu) 22

32 3 Návrh Na základe analýz existujúcich archivačných systémov, dostupných riešení a moţností archivácie pomocou XAdES podpisu bude v tejto práci navrhnuté vlastné riešenie systému pre dlhodobú archiváciu elektronického podpisu. Navrhovaný systém bude vychádzať z formátu XAdES a zároveň s poznatkov centralizovaných archivačných systémov akým je napríklad SLTAS. Systém bude vychádzať zo základného formátu XAdES (resp. XAdES-T). Na vytvorenie takého podpisu bude slúţiť klientská aplikácia. Ostatné formy XAdES-u budú oddelené od základného podpisu. Tieto formy a všetky validačné dáta potrebné pri archivácií budú od formy XAdES-T oddelené a bude ich archivovať centralizovaný archivačný systém. Dôvodov na tento druh riešenia je niekoľko: 1. narastajúca veľkosť dokumentu v prípade klasickej XAdES-A formy 2. nutnosť opätovného vytváranie časových pečiatok 3. jednoduchšia validácia dlhodobo archivovaného podpisu Formát XAdES-T sa bude odkazovať na archivačné dáta prostredníctvom doplňujúcich elementov, ktoré sú taktieţ predmetom návrhu. Cieľom tohto návrhu je taktieţ prezentovať úpravy v XML štruktúre základnej formy XAdES podpisu a aj jeho archívnych formách. Archivačný systém bude poskytovať vytváranie archívnej formy podpisu, klientovi poskytuje upravenú základnú formu podpisu, ktorá odkazuje na archivačné dáta, bude podpis archivovať a poskytovať pouţívateľom overenie podpisu. Pouţívateľ bude mať taktieţ moţnosť archivačné dáta zmazať. 3.1 Architektúra systému Na Obrázku 3.1 sa nachádza návrh architektúry systému. Z návrhu je zrejmé, ţe pôjde o architektúru klient - server. Ide o celkový pohľad na systém. Pouţívateľ (User) bude vyuţívať klientskú aplikáciu (Client application) pre vytváranie podpisu. Tá bude komunikovať a Archivačným systémom (AS) prostredníctvom webových sluţieb. Tento systém bude vytvárať archivačnú formu podpisu a overovať existujúce formy archívneho podpisu vytvorené týmto systémom. 23

33 Obrázok 3.1 Architektúra systému Klientská aplikácia Klientská aplikácia bude poskytovať pouţívateľom nasledovné základné sluţby: - moţnosť podrobne vyplniť parametre, ktoré budú obsiahnuté v elemente SignedSignatureProperties (pre pre jednoduchšie vytváranie podpisu, bude moţnosť tieto parametre načítavať z konfiguračného súboru) - SK kľúč, pomocou ktorého bude vypočítaný podpis, bude aplikácia akceptovať vo formáte definovanom štandardom PKCS12 t.j. SK je distribuovaný spolu s certifikátom verejného kľúča - aplikácia bude umoţňovať podpisovanie iba XML súborov, pričom pouţívateľ musí poskytnúť XSD schému k týmto súborom a tieto súbory musia byť voči schéme validné - moţnosť vytvoriť elektronický podpis formátu XAdES resp. XAdES-T pomocou pouţívateľovho certifikátu - moţnosť vyuţiť AS pre vytvorenie archívnej formy elektronického systému (z formátu XAdES-T) - moţnosť vyuţiť AS na overenie XAdES podpisu archivovaného v minulosti pomocou AS Architektúru aplikácie je moţné vidieť na nasledovnom Obrázku 3.2. Aplikácia bude pozostávať z grafického rozhrania (GUI) a nasledovných modulov: - I/O processor - spracovanie vstupných/výstupných dát - Signer - vytvorenie podpisu - Timestamp creator - vytvorenie časovej pečiatky - AS communicator - komunikácia s AS 24

34 Timestamp creator User GUI Signer AS communicator AS I/O processor Obrázok 3.2: Klient Archivačný systém (serverová časť) Funkcie AS sú klientským aplikáciám prístupné pomocou webových sluţieb. AS bude poskytovať nasledovné sluţby: - vytváranie archívnej formy podpisu + vytvorenie modifikovaného XAdES formátu podpisu, ktorý referencuje validačné a archivačné dáta, tento modifikovaný formát je vrátený klientovi - systém bude prijímať podpis vo formáte XAdES-T, archívny podpis bude vytváraný nad formátom XAdES-T - v prípade prijatia základného XAdES formátu AS vytvorí časovú pečiatku a prijatý podpis rozšíri na formát XAdES-T - zabezpečenie vytvorenia certifikačnej cesty a získanie všetkých CRL, ktoré vydali CA v tejto ceste, za účelom správneho overenia certifikátu - archivácia všetkých validačných a archivačných údajov (certifikáty v certifikačnej ceste, CRL), tieto údaje budú súčasťou archívnej formy podpisu - overenie vytvoreného archívneho podpisu - moţnosť poskytnutia celého archívneho podpisu klientskej aplikácii/pouţívateľovi na poţiadanie - zmazanie archívneho podpisu - retimestamping vytváranie opätovných časových pečiatok, tento proces bude prebiehať automaticky Modulárna dekompozícia aplikácie je na Obrázku 3.3. Aplikácia bude pozostávať z nasledovných komponentov. 25

35 - XAdES processor - spracovanie vstupného XAdES podpisu - XAdES verifier - overenie podpisu - CA verifier overenie certifikátu - XAdES-A vytvorenie archívnej formy podpisu, vytvorenie XAdES dokumentu pre klienta - Archiver archivácia archívnej formy podpisu - Retimstamping vytváranie časových pečiatok Signature verifier Certificate verifier Client application XAdES processor XAdES-A* creator Archiver Database Retimestamping Obrázok 3.3: Server Klientskou aplikáciou nemusí byť iba aplikácia vyvíjaná v rámci tohto projektu t.j. AS nebude nijakým spôsobom previazaný s klientskou aplikáciou. Tento AS môţe byť vyuţívaný iným systémom. Príkladom takéhoto systému môţe byť napríklad elektronická podateľňa, ktorá bude denne generovať mnoţstvo elektronických podpisov a tie bude potom posielať AS na dlhodobú archiváciu Návrh dátového modelu Navrhovaný AS bude vyuţívať databázu, ktorá bude pozostávať z niekoľkých tabuliek ako je vidieť na Obrázku 3.4. Tabuľka User bude slúţiť na evidenciu všetkých pouţívateľov vyuţívajúcich AS. V tabuľkách OldSignature a ArchiveSignature budú uloţené podpisy od pouţívateľov resp. vytvorené archívne podpisy. V tabuľke Timestamp budú uloţené informácie o pouţitých časových pečiatkach. Fyzický dátový model sa nachádza v Prílohe A - Technická dokumentácia. 26

36 Obrázok 3.4: Logický dátový model 3.2 Návrh XSD schém podpisov AS bude všetky validačné dáta zdruţovať vo vlastnom XML formáte, ktorý bude oddelený od XAdES podpisu, ktorý obdrţí od pouţívateľa. Štruktúra tohto formátu bude vychádzať z podpisu verzie XAdES-A. Schéma tohto podpisu sa nachádza v prílohe Technická dokumentácia v kapitole 2 Schéma archívneho podpisu AS. Taktieţ pouţívateľ po archivácii jeho podpisu získa späť upravený dokument, ktorý bude vychádzať z formátu XAdES-T XAdES-T - Klient AS bude vracať klientskej aplikácii formát podpisu vychádzajúci zo štruktúry podpisu XAdES-T. Elementy, ktoré budú odkazovať na validačné dáta uloţené v AS sa budú nachádzať pod elementom UnsignedProperties, pôjde teda o nepodpisované dáta. Archivácia bude vychádzať z formátu XAdES-T. Klientská aplikácia vytváraná v rámci tejto práce, bude vytvárať podpis v tomto formáte. AS po obdrţaní podpisu od klienta (XAdES-T), podpis archivuje a pod element UnsignedProperties pridá element ArchiveDataRef, ktorý bude odkazovať na validačné dáta. Pre samotného pouţívateľa pridaný element, nie je aţ tak podstatný. Vyuţívať ho bude AS pri overovaní elektronického podpisu. Element bude pozostávať z elementov Transforms obsahuje transformačné algoritmy, ktoré treba aplikovať na archivačné dáta pred vypočítaním hashu, DigestMethod špecifikuje algoritmus výpočtu hashu, DigestValue obsahuje hash 27

37 archivačných dát. Povinným atribútom je URI, ktoré obsahuje Id dokumentu s archivačnými údajmi. Za vytváranie jednotlivých Id hodnôt je zodpovedný AS. <UnsignedSignatureProperties> <ArchiveDataRef URI= > <Transforms> <Transform Algorithm="" /> </Transforms> <DigestMethod Algorithm="" /> <DigestValue /> </ArchiveDataRef> </UnsignedSignatureProperties> Archívna forma Archívna forma podpisu, ktorá bude oddelená od samotného podpisu a podpisovaných dát, vychádza zo XAdES-A formy podpisu, pričom prináša niekoľko nových prvkov. Tento dokument bude archivovaný AS. Bude slúţiť pri overovaní elektronického podpisu, ak si to vyţiada klientská aplikácia. Tieto elementy sa budú nachádzať v novom dokumente pod koreňovým elementom ArchiveSignature. Kompletná schéma navrhovaného XML dokumentu sa nachádza v prílohe Technická dokumentácia v kapitole 2 Schéma archívneho podpisu AS. Koreňový element obsahuje 2 elementy: ArchiveSignatureData a ArchiveTimeStamp. Pod elementom ArchiveSignatureData sa nachádza element SignatureReference, ktorý odkazuje na podpis klientskej aplikácie. Štruktúra tohto elementu je nasledovná: <SignatureReference URI="" > <SignatureDigest> <Transforms> <Transform Algorithm="" /> </Transforms> <DigestMethod Algorithm="" /> <DigestValue /> </SignatureDigest> </SignatureReference> Element SignatureReference musí mať atribút URI, ktorý sa odkazuje na Id podpisu od klientskej aplikácie. Vytváranie jednoznačných Id bude v réţii samotného AS a pre 28

38 klientskú aplikáciu z tohto hľadiska nevyplývajú ţiadne obmedzenia ani pravidlá, ktoré musí dodrţať pri tvorbe podpisu. V elemente SignatureDigest sa nachádza hash celého podpisu (celého XML dokumentu). Vďaka tomu, ţe je hash vypočítavaný z celého dokumentu, odstraňuje sa tým problém, ktorý by mohol vzniknúť po prelomení algoritmu pouţitého pri výpočte hashu. V elemente Transforms sú špecifikované transformačné algoritmy, ktoré je treba vykonať, pred vypočítaním hash odtlačku. V elemente DigestMethod je uvedený algoritmu výpočtu hash odtlačku. Ďalšími elementmi sú jednotlivé zloţky XAdES C, X a L formátov podpisu s tým, ţe v elemente CompleteRevocationRefs sa nachádza iba element CRLRefs (t.j. sú vynechané elementy OCSPRefs a OthersRefs, z dôvodu, ţe AS bude na overovanie, či je certifikát platný vyuţívať iba CRL). Všetky tieto elementy z foriem C, X a L sa budú nachádzať pod elementom ArchiveSignatureData. Druhým dôleţitým elementom, ktorý sa bude nachádzať pod elementom ArchiveSignatureData je ArchiveTimeStamp. Štruktúra tohto elementu je nasledovná: <ArchiveTimeStamp Id="A1"> <AllDataDigest> <Transforms> <Transform Algorithm="" /> </Transforms> <DigestMethod Algorithm="" /> <DigestValue /> </AllDataDigest> <AllDataTimeStamp> <EncapsulatedTimeStamp /> </AllDataTimeStamp> </ArchiveTimeStamp> Element AllDataDigest ma totoţnú štruktúru a aj obsah elementov ako element SignatureDigest. Element AllDataTimeStamp obsahuje v elemente EncapsulatedTimeStamp časovú pečiatku. Spôsob vytvárania elementu ArchiveTimeStamp je opísaný v kapitole Error! Reference source not found. Retimestamping. 3.3 Opätovné vytváranie časových pečiatok Tento proces bude slúţiť na opätovné vytváranie časových pečiatok. Bude prebiehať automaticky, bez zásahu pouţívateľa alebo administrátora archivačného systému. Časová 29

39 pečiatka sa bude nachádzať v elemente ArchiveTimeStamp. V celom XML dokumente, ktorý vytvára AS sa musí nachádzať minimálne jeden tento element, pričom s pribúdajúcim časom budú tieto elementy pribúdať. 3.4 Postup vytvárania tohto elementu je nasledovný. Pri vytváraní prvého elementu ArchiveTimeStamp zoberie element ArchiveSignatureData, aplikuje sa naň kanonizačný algoritmus (ktorý bude potom uvedený v elemente Transforms) a vypočíta sa odtlačok hash, čim bude moţné vyplniť celý element AllDataDigest. Nad samotnou hodnotou odtlačku bude vytvorená časová pečiatka, ktorá bude v elemente AllDataTimeStamp. Element ArchiveTimeStamp má povinný atribút Id. Hodnota týchto atribútov musí byť jednoznačná v rámci celého XML dokumentu. Pri vytváraní ďalších opätovných časových pečiatok sa okrem elementu ArchiveSignatureData zoberú aj všetky existujúce elementy ArchiveTimeStamp a táto kolekcia elementov sa kanonizuje príslušným algoritmom. Zvyšný postup je totoţný ako pri vytváraní prvej časovej pečiatky. Pod elementom AllDataTimeStamp sa bude nachádzať okrem elementu EncapsulatedTimeStamp, ktorý bude obsahovať časovú pečiatku, ešte jeden element EncapsulatedTimeStamp, ktorý bude obsahovať certifikát pouţitý pri generovaní časovej pečiatky. Ak sa pri procese 3.3 bude vytváraná ďalšia časová pečiatka, tak predchádzajúci element AllDataTimeStamp bude rozšírený o ďalšie EncapsulatedTimeStamp elementy, ktoré budú obsahovať všetky certifikáty a CRL potrebné pre overenie certifikačnej cesty certifikátu pouţitého pri vytváraní časovej pečiatky. Týmto je zabezpečené, ţe kaţdá nové časová pečiatka chráni certifikačnú cestu predchádzajúcej časovej pečiatky. 30

40 3.5 Vytváranie, archivovanie a overovanie podpisu A1 Vyplnenie vstupných parametrov A3 Vytvorenie podpisu Podpis sa nepodarilo vytvoriť Nie Áno Sú parametre správne? A4 Validácia podpisu A2 Nahranie vstupných dát Je podpis validný? Nie Áno Nie Áno Podpis bol úspešne vytvorený Sú parametre správne? Obrázok 3.5: Diagram činností pre vytváranie elektronického podpisu A1 Vyplnenie vstupných parametrov - pouţívateľ v klientskej aplikácii vyplní všetky vstupné parametre, ktoré zahŕňajú informácie potrebné pre element SignedSignatureProperties, certifikát a iné potrebné informácie A2 Nahranie vstupných dát - pouţívateľ nahrá všetky vstupné dáta, ktoré chce podpísať (aplikácia bude podporovať podpisovanie XML dokumentov), a ku nim aj schémy potrebné pre validáciu - všetky tieto vstupné dáta sú overované voči prislúchajúcim schémam A3 Vytvorenie podpisu - vytvorenie pouţitím SK, ktorý spolu s certifikátom poskytol aplikácii pouţívateľ - vytvorenie podpisu je v súlade s postupom štandardu XMLDSIG, ktorý je uvedený v kapitole 1 v prílohe Technická dokumentácia A4 Validácia podpisu - vypočítaná hodnota elektronického podpisu je overená pomocou VK, ktorý je uvedený v certifikáte pouţívateľa 31

41 A5 Spracovanie XML dokumentu A11 Získanie CRL všetkých CA v certifikačnej ceste A12 Overenie certifikačnej cesty A6 Overenie dokumentu voči schémam A7 Overenie podpisu Nie Áno Prebehlo overenie úspešne? A8 Vyhodnotenie spracovania A13 Vytvorenie archívnej formy Nie Áno Prebehlo spracovanie úspešne? A14 Overenie vytvoreného podpisu A9 Overenie certifikátu Nie Prebehlo overenie úspešne? Áno Nie Áno A15 Vytvorenie rerfcencii v XML dokumente od používateľa A10 Vyskladanie certifikačnej cesty Archívny podpis nebol vytvorený Archívny podpis bol úspešne vytvorený Obrázok 3.6: Diagram činností pre vytváranie archívnej formy podpisu A5 Spracovanie XML dokumentu - aktivita v sebe zahŕňa počiatočne spracovanie prijatého XML dokumentu predovšetkým kontrolu, či ide o korektný XML dokument A6 Overenie dokumentu voči schémam - prijatý XML dokument musí byť validný voči všetkým schémam, ktoré ho definujú - AS prijíma podpisy formátu XAdES-T, to znamená, ţe prijatý dokument musí byť validný voči XADES a XMLDSIG schémam A7 Overenie podpisu - pred ďalším spracovaním je potrebné aj overiť hodnotu podpisu pomocou informácii uvedených v elemente ds:keyinfo 32

42 A8 Vyhodnotenie spracovania - kompletné spracovanie prijatého XML dokumentu je vyhodnotené a ak nastala akákoľvek chyba, archívny podpis nebude vytvorený A9 Overenie certifikátu - základné overenie certifikátu, či ide o správny formát A10 Vyskladanie certifikačnej cesty - pre úplne overenie podpisu AS vyskladá certifikačnú cestu aţ po dôveryhodnú CA - mnoţinu prehľadávaných certifikátov tvoria dva priečinky v úloţisku certifikátov systému Windows, prvým priečinkom je ASCertificates, kde sa nachádzajú certifikáty pre archivačný systém, druhým je Trusted Root Certification Authorities, kde sa nachádzajú dôveryhodné certifikáty A11 Získanie CRL všetkých CA v certifikačnej ceste - získanie najaktuálnejších CRL tých CA, ktoré sa nachádzajú v certifikačnej ceste - k získaniu sa vyuţíva rozšírenie certifikátov CRLDistributionPoint, kde sa nachádza URL adresa, kde je dostupné najnovšie CRL A12 Overenie certifikačnej cesty - overenie certifikačnej cesty voči aktuálnemu dátumu A13 Vytvorenie archívnej formy - ak boli výsledky všetkých overení správne, AS vytvorí archívnu formu podľa definovaných pravidiel a schémy A14 Overenie vytvoreného podpisu - overenie vytvorenej archívnej formy podpisu A15 Vytvorenie referencií - doplnenie referencií na archívnu formu podpisu a odoslanie rozšíreného podpisu klientskej aplikácii 33

43 4 Opis riešenia Implementácia pozostávala nasledovných častí: implementácia klientskej aplikácie, implementácia archivačného systému (serverová časť), vytvorenie a nakonfigurovanie DB, vygenerovanie potrebných certifikátov. Na implementáciu klientskej časti a archivačného systému bola vyuţitá technológia.net a programovací jazyk C#. 4.1 Vytváranie párov kľúčov a certifikátov Vzhľadom na opísaný návrh systému je potrebné pracovať s dostatočne veľkou mnoţinou certifikátov, párov kľúčov atď. S touto mnoţinou je potom moţné skladať a overovať certifikačnú cestu spôsobmi, aké sú opísané v kapitole Navrhovanú mnoţinu certifikátov a vzťahov medzi nimi je moţné zobraziť nasledovným diagramom. act Strom certifikátov CA1 CAL1_1 CAL1_2 CAL1_3* USRL2_1 CAL2_1 USRL2_2 USRL2_3 USRL3_1 Obrázok 4.1: Strom certifikátov Páry kľúčov, certifikáty a CRL zoznamy boli vygenerované pomocou open source nástroja OpenSSL. Ako prvý bol vygenerovaný pár kľúčov a certifikát koreňovej autority. Ďalšie pouţívateľské certifikáty a certifikáty pre podriadené autority boli vytvárané nasledovným postupom: 1. Vygenerovanie páru kľúčov 34

44 2. Vygenerovanie ţiadosti o certifikát 3. Vygenerovanie certifikátu zo ţiadosti Pre kroky 2 a 3 boli vytvorené konfiguračné súbory, ktoré je moţné nájsť na DVD médiu v adresári AS\DP\Data\Certificates\Config\. Označenia CA označujú certifikáty certifikačných autorít. Označenia USR sú pouţívateľské certifikáty. V oboch prípadoch písmeno L spolu s číslom označuje úroveň resp. hĺbku v strome (t.j. L1 je prvá úroveň, L2 druhá atď.). Autoritou CA1 bol vydaný jeden CRL dokument, v ktorom bol revokovaný certifikát CAL1_3 označený hviezdičkou. Vytváranie certifikátu pre autoritu pre vydávanie časových pečiatok prebiehalo podobným spôsobom. V tomto prípade je však strom certifikátov výrazne jednoduchší. TSA1 predstavuje koreňovú autoritu pre vydávanie časových pečiatok. Tento certifikát slúţi na vydanie pečiatok vyuţívaných v tejto diplomovej práci. 4.2 Implementácia klienta Klientská aplikácia slúţi na vytváranie podpisu formátu XAdES-T a komunikáciu s AS. Aplikácia bola implementovaná s maximálnym dôrazom na dodrţanie vzoru MVC. Pri vytváraní podpisu svojim grafickým rozhraním umoţňuje nastaviť všetky potrebné parametre pre vytvorenie podpisu. Pre výpočet hash hodnôt a hodnoty elektronického podpisu bola vyuţitá open souce kniţnica BouncyCastle. 4.3 Implementácia archivačného systému Archivačný systém bol rozdelený do niekoľkých vrstiev: servisná, core vrstva (biznis logika), doménová vrstva, vrstva dátových sluţieb a dátová vrstva. Pohľad na tieto vrstvy poskytuje Obrázok 4.2. Klientský program komunikuje so servisnou vrstvou. Komunikáciu medzi jednotlivými vrstvami je moţné vyjadriť dvomi sekvenčnými diagramami na Obrázkoch 4.3 a 4.4. Sluţba servisnej vrstvy beţí na serveri Internet Information Services (IIS) vo verzii 7.5. Sluţba má názov AS.Wcf.Service a poskytuje nasledovné metódy: - Archive archivuje elektronický podpis klientskej aplikácie - VerifyArchivedSignature overuje archivovaný podpis - GetArchivedData vráti archivovaný podpis, t.j. všetky archivačné dáta - DeleteArchivedData vymaţe všetky archivačné dáta z DB a disku 35

45 cmp Vrstv y systému «IIS» Aplikačná vrstva Vrstva dátových služieb Klient HTTP/SOAP Servisná vrstva «EntityFramework» ORM C# call ADO.NET Core C# call Dátová vrstva C# call MS SQL «EntityFramework» Doménová vrstva Obrázok 4.2: Vrstvy archivačného systému Vytváranie archívnej formy podpisu Klient odošle AS vytvorený podpis. Spracovanie tohto podpisu jednotlivými vrstvami je zobrazené na Obrázku 4.3. Klient komunikuje so servisnou vrstvou a táto vrstva prepošle podpis Core vrstve. Táto vrstva je zodpovedná za kompletné vyhodnotenie podpisu, jeho overenie a vytvorenie archívnej formy. V Core vrstve sa najprv overí podpis. Na to slúţi trieda XAdESValidator. Jej metódami je moţné overiť podpis postupom podľa kapitoly 2.6. Ak je tento podpis validný, uloţí sa do databázy a taktieţ na disk. Potom sa na základe certifikátu uvedeného v elemente KeyInfo vyskladá certifikačná cesta. Mnoţina prehľadávaných certifikátov pozostáva z dvoch priečinkov. Oba sa nachádzajú úloţisku certifikátov operačného systému Windows. Prvým priečinkom je Trusted Root Certification Authorities. Ide o priečinok, kde sú uloţené certifikáty autorít, ktoré sú povaţované za dôveryhodné. Druhým priečinkom je ASCertificates, tu sú uloţené všetky certifikáty, ktoré sú pre archivačný systém známe, a s ktorými pracuje. Za napĺňanie týchto priečinkov je zodpovedný modul ImportModule. Vyskladanú certifikačnú cestu je potrebné overiť. K tomuto kroku je dôleţité získať potrebné CRL dokumenty. Kaţdý certifikát, ktorý bol vygenerovaný pomocou OpenSSL, má uvedené rozšírenie CRLDistributionPoints, v ktorých je uvedená URL adresa, na ktorej je dostupný 36

46 najnovší CRL dokument. Pre kaţdý certifikát CA sa stiahne CRL dokument, ak existuje. Certifikačná cesta je overovaná k aktuálnemu dátumu. Ak je certifikačná cesta v poriadku, tak sa vytvorí kompletná štruktúra XML dokumentu pre archívne dáta. Pre túto štruktúru je potom potrebné vystaviť časovú pečiatku. Po jej získaní je XML dokument kompletný, časová pečiatka a archívne dáta môţu byť uloţené do databázy. Klientovi sa odošle rozšírený podpis, ktorý poslal do archivačného systému o element, ktorý obsahuje referenciu na archivačné dáta. sd Vytvorenie archívneho podpisu Klient Servisná vrstva Core vrstva Doménová vrstva Vrstva dátových služieb Databáza archivuj podpis() archivuj podpis() over podpis() uloz pôvodný podpis() insert() získaj validačné dáta() over všetky validačné dáta() vytvor dáta pre archívnu formu() ulož všetky validačné dáta() insert() odošli klientovi dáta() vytvor podpis z referenciami na dáta() odošli klientovi dáta() Obrázok 4.3: Sekvenčný diagram pre vytváranie archívneho podpisu Overovanie archívneho podpisu Archivačný systém umoţňuje overiť podpis pomocou všetkých archivačných dát. Klient odošle do systému podpis s referenciou na archivačné dáta. Servisná vrstva pošle prijatý podpis do Core vrstvy. Na základe referencie v prijatom podpise sa z databázy a zo súborového systému získajú archivačné dáta. Najprv sa overí ich integrita. Vypočíta sa hash hodnota týchto dát a overí sa jeho hodnota s tou, ktorá je uvedená v referencii v podpise od klienta. Ak sú hash hodnoty totoţné, získa sa z archivačných dát certifikačná cesta spolu s CRL dokumentmi a nastane ich overenie. Certifikačná cesta sa overuje voči dátumu, ktorý je uvedený v časovej pečiatke, ktorá bola vytvorená nad celou štruktúrou týchto dát. 37

47 V prípade, ţe je cesta správna a validná overia sa zvyšné časové pečiatky (ak existujú), ktoré vznikli opätovným vytváraním časových pečiatok. sd Overenie archívneho podpisu Klient Servisná vrstva Core vrstva Vrstva dátových služieb Databáza over podpis() over podpis() získaj validačné dáta() select() over všetky validačné dáta() vráť vysledok () vráť výsledok() Obrázok 4.4: Sekvenčný diagram pre overovanie archívneho podpisu 4.4 Vytváranie časových pečiatok Vytváranie časových pečiatok je simulované pomocou naprogramovanej jednoduchej certifikačnej autority pre vydávanie časových pečiatok. Ide o dll kniţnicu, ktorú vyuţíva klientská aplikácia a taktieţ aj archivačný systém. Kniţnica bola naprogramovaná pomocou kniţnice BouncyCastle. Pre vytvorenie časovej pečiatky je potrebné vygenerovať pomocou tejto kniţnice ţiadosť o časovú pečiatku. Táto ţiadosť sa potom vyhodnotí a vygeneruje sa odpoveď. Táto kniţnica simuluje iba jednoduchú autoritu bez moţnosti pokročilých nastavení. Umoţňuje iba vytvorenie ţiadosti a vygenerovanie odpovede Vytváranie opätovných časových pečiatok Súčasťou archivačného systému je modul pre opätovné vytváranie časových pečiatok. Pri vytvorení archívnej formy podpisu sa nad archivačnými dátami vytvára časová pečiatka. Platnosť tejto pečiatky je ohraničená platnosťou certifikátu, ktorý bol pouţitý na jej vytvorenie. Pred vypršaním platnosti pečiatky sa nad dátami vytvára ďalšia časová pečiatka. Postup vytvárania pečiatok: 38

48 1. Získanie časových pečiatok z DB, ktorým sa blíţi koniec platnosti (časový interval, podľa ktorého sa vyberajú pečiatky pred koncom svojej platnosti sa nastavuje v konfiguračnom súbore) 2. Získanie archivačných dát, pre ktoré sú dané pečiatky vystavené 3. Pre posledné (najaktuálnejšie) všetky časové pečiatky archivačných dát sa získa vytvorí certifikačná cesta a CRL dokumenty a zároveň nastane ich overenie, tieto dáta sa potom pridajú k poslednej časovej pečiatke 4. Nad všetkými archivačnými dátami, spolu s časovými pečiatkami a pridanými certifikátmi je vytvorená ďalšia časová pečiatka 5. Aktualizuje sa záznam časovej pečiatky v databáze 6. Aktualizuje sa záznam archivačných dát v databáze a na disku 7. Z disku sa získa podpis, pre ktorý sú vytvorené archivačné dáta, vytvorí sa element, ktorý referencuje tieto dáta a podpis sa rozšíri o tento element 8. Pouţívateľovi sa odošle rozšírený podpis na jeho ovú adresu s aktualizovaným elementom s referenciou na archivačné dáta, tento podpis nahradzuje podpis, ktorý bol pouţívateľovi vytvorený pri prvej archivácii podpisu Archivačný systém odosiela z ovej adresy archivacnysystem@gmail.com. Táto ová adresa bola vytvorená iba pre účely tejto práce. 4.5 Databáza Databáza bola vytvorená na základe návrhu z kapitoly Fyzický model tejto databázy sa nachádza v Prílohe A - Technická dokumentácia. Databáza beţí na serveri Microsoft SQL Server verzii Pre väčšinu manipulácii s dátami sa vyuţívajú nasledovné procedúry uloţené v DB (stored procedure), ktoré sú bliţšie popísané v tabuľke Tabuľka 4.1: Procedúry uloţené v DB Procedúra Opis ArchiveSignatureDel Vymaţe archivačné data ArchiveSignatureIns Vloţí archivačné dáta ArchiveSignatureUpd Aktualizuje archivačné dáta OldSignatureGet Vráti dáta pre pôvodný podpis 39

49 OldSignatureIns OldTimestampsGet TimestampDel TimestampIns TimestampUpd UserIns UserGet klientskej aplikácie Vloţí podpis od klientskej aplikácie Vráti časové pečiatky s končiacou platnosťou Vymaţe časovú pečiatku Vloţí časovú pečiatku Aktualizuje údaje o časovej pečiatke Vloţí pouţívateľa Vráti dáta pouţívateľa Z databázy boli pomocou objektovo relačného mapovača (ORM) vytvorené triedy doménovej vrstvy. Tie boli vyuţité pri ukladaní a získavaní dát z databázy. Ako ORM bol vyuţitý ADO.NET Entity Framework. 4.6 Logovanie Všetky časti klientskej aplikácie, archivačný systém a autorita pre vydávanie časových pečiatok zapisujú chyby a rôzne výnimočné stavy do logu súborov. Pre kaţdý modul existuje vlastný logovací súbor. O logovanie sa stará vlastná dll kniţnica. 4.7 Overenie riešenia Tento spôsob riešenia dlhodobej archivácie elektronického podpisu a podpory jeho dlhodobej overiteľnosti je moţné overiť dvomi spôsobmi Overenie generovaných XML dokumentov voči schémam V samotnom riešení dochádza ku generovaniu dvoch hlavných XML dokumentov. Prvým dokumentom je podpis, ktorý vytvára klientská aplikácia. Druhým je XML dokument so všetkými archivačnými dátami. Pre oba dokumenty bola navrhnuté XSD schémy. Na overenie správneho vytvárania týchto dokumentov je teda moţné vyuţiť tieto dve schémy. Vytvárané XML štruktúry boli overované pomocou nástroja Stylus Studio Testovacie scenáre Iným spôsobom overenia je vytvorenie niekoľkých jednoduchých testovacích scenárov. 40

50 Overenie klientského podpisu Prvým testovacím scenárom je overenie správneho vytvárania a overovania elektronického podpisu. Postup je nasledovný: 1. Pomocou klientskej aplikácie sa vytvorí podpis 2. Naruší sa hodnota vypočítaného hashu v dokumente 3. Klientská aplikácia sa pokúsi archivovať podpis Záver: Archivačný systém pri overovaní podpisu správne detekoval narušenú hodnotu hashu v elemente referencie, podpis označil za neplatný a nebol archivovaný Overenie archívneho podpisu Test prebieha nasledovne: 1. Pomocou AS sa elektronický podpis archivuje 2. Naruší sa hodnota hashu v elemente, ktorý referencuje podpis klientskej aplikácie 3. Klientská aplikácia sa pokúsi overiť archívny podpis Záver: Pri overovaní podpisu sa správne detekuje narušená hash hodnota a podpis je vyhodnotený ako neplatný 41

51 5 Zhodnotenie V úvode tejto práce boli zhrnuté základné pojmy a poznatky, ktoré sú hrajú významnú úlohu v PKI. Práca obsahuje dôleţitú kapitolu Analýza problému, v ktorá sa podrobne venuje problematike elektronického podpisu. Sú tu rozpísané a analyzované dva rôzne prístupy k archivácii elektronického podpisu. Podrobne je rozpísaný spôsob archivácie elektronického podpisu najmä pre formát XAdES. Druhým analyzovaným spôsobom je centralizovaný systém pre dlhodobú archiváciu dokumentov a iných dát. V analýze je spomenutých niekoľko problémov, ktoré môţu nastať pri dlhodobej archivácii elektronického podpisu. V tretej kapitole Návrh je na základe analýzy a spojenia oboch prístupov ku dlhodobej archivácii navrhnutý spôsob úpravy XAdES-A formátu elektronického podpisu takým spôsobom, aby boli čo moţno v najväčšej miere odstránené nevýhody súčasného formátu opísaného v analýze a taktieţ sa do tejto oblasti vniesli výhody aké prinášajú centralizované systémy pre dlhodobú archiváciu. Návrh pozostáva z viacerých častí: - návrhu klientskej aplikácie, ktorá bude vytvárať podpis vo formáte XAdES-T s moţnosťou konfigurácie čo moţno najväčšieho počtu parametrov tohto podpisu - návrhu archivačného systému, s ktorým bude klientská aplikácia schopná komunikovať a tento systém bude vytvárať, archivovať a overovať archívnu formu podpisu - špecifikovanie archívnej formy podpisu (z akých zloţiek bude pozostávať a čo budú obsahovať) - špecifikovanie postupu akým bude vytváraný podpis v klientskej aplikácii - špecifikovanie postupu akým bude AS vytvárať archívny podpis a ako bude tento podpis overovaný - vytvorenia schém pre upravenú verziu XAdES-T podpisu a pre archívnu formu podpisu, ktorú bude vytvárať a archivovať AS, tieto schémy sú dôleţité pri overení dodrţania formátu podpisov - vytvorenia modelu databázy V štvrtej kapitole je opísaný spôsob implementácie všetkých častí navrhnutých v tretej kapitole. V piatej kapitole je vysvetlený spôsob implementácie všetkých častí navrhovaného systému pre dlhodobú archiváciu elektronického podpisu 42

52 5.1 Klientská aplikácia V rámci tejto diplomovej práce bola vytvorená klientská aplikácia. Vlastnosti vytvoreného riešenia moţno zhrnúť v nasledovných bodoch: - klientská aplikácia vytvára XAdES-T formát podpisu - pouţívateľ môţe meniť veľkú mnoţinu parametrov podpisu - moţnosti nastavovania elementov pre element QualifyingProperties - výber algoritmu na výpočet hashu - na podpis je moţné vyuţiť SK pre algoritmus RSA, ktorý je distribuovaný spolu s certifikátom vo formáte definovanom štandardom PKCS12 - klientská aplikácia dokáţe komunikovať s AS a vyuţívať všetky sluţby poskytované týmto systémom 5.2 Archivačný systém - AS umoţňuje archiváciu elektronického podpisu, ktorý vytvorila klientská aplikácia táto operácia zahŕňa overenie prijatého podpisu, získanie všetkých dát potrebných pre vytvorenie archívnej formy podpisu - certifikáty, CRL, overenie týchto dát atď. - Umoţňuje overovať archívny podpis - Dovoľuje získať alebo vymazať všetky archivačné dáta - Zabezpečuje automatickú generáciu časový pečiatok pri procese opätovného vytvárania časových pečiatok 5.3 Možnosti budúceho rozvoja systému Pre klientsku aplikáciu a taktieţ pre samotný archivačný systém je moţné identifikovať priestor pre ďalší rozvoj týchto aplikácii. V prípade klientskej aplikácie je moţné zlepšenie definovať v nasledovných bodoch: - Implementovať moţnosť pouţitia iných podpisových algoritmov ako RSA - Implementovať moţnosť práce s podpisovými politikami V prípade archivačného systému je moţné identifikovať nasledovné moţnosti pre zlepšenie: - Podpora správy pouţívateľov - Zlepšenie procesu opätovného automatického vytvárania časových pečiatok, vytvorenie pečiatky a odoslanie notifikácie trvá istý čas (niekoľko sekúnd), pri veľkom mnoţstve podpisov resp. časových pečiatok v systéme môţe zabrať vytváranie pečiatok dlhú dobu, tento problém by bolo moţné vyriešiť viacerými spôsobmi: 43

53 - Rozdeliť generovanie pečiatok do viacerých vlákien (threadov) - Rozdeliť generovania pečiatok do niekoľkých fáz (pečiatky by sa generovali po skupinách a v dostatočne dlhom časovom predstihu) - Zabezpečiť získavanie pečiatok od viacerých autorít tým by mali časové pečiatky rôzne dlhú platnosť - Generovať časové pečiatky pre skupiny podpisov, tým by došlo k výraznému (rádovému) zníţeniu počtu pečiatok, ktoré treba vygenerovať - Zabezpečiť komunikáciu medzi archivačným systémom a klientskou aplikáciou pomocou protokolu HTTPS - AS vyuţíva pri skladaní a následnom overovaní certifikačnej cesty najaktuálnejšie CRL zoznamy, vhodnejší spôsobom by bolo počkať na vydanie CRL zoznamov všetkých CA v certifikačnej ceste aţ potom vytvoriť archívnu formu podpisu, archivácia týmto spôsobom by však mohla trvať aj niekoľko dní, jednou z priorít navrhovaného systému v tejto práci bolo poskytnúť vytvorenie archívnej formy v čo moţno najrýchlejšom čase 44

54 6 Použitá literatúra 1. Adams, C., Cain, P., Pinkas, D., Zuccherato, R.: 2001, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), ( ) 2. Blazic, A.J., Sylvester, P Provision of Long-Term Archiving Service for Digitally Signed Documents Using an Archive Interaction Protocol. In Lecture Notes in Computer Science, Springer Berlin, 2005, Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., Polk, W.: 2002, Internet X.509 Public Key InfrastructureCertificate and Certificate Revocation List (CRL) Profile, ( ) 4. DOSTÁLEK, L., VOHNOUTOVÁ, M.: Velký průvodce infrastrukturou PKI a technologií elektronického podpisu, 1. vyd. Brno, Computer Press, 2006, 534s. ISBN Eastlake, D., Reagle, J., Solo, D., 2008, XML-Signature Syntax and Processing, ( ) 6. ETSI: XML Advanced Electronic Signatures (XAdES), 2009, 7. Národný bezpečnostný úrad SR, ( ) 9. Troncoso, C., De Cock, D., and Preneel, B Improving secure long-term archival of digitally signed documents. In Proceedings of the 4th ACM international Workshop on Storage Security and Survivability (Alexandria, Virginia, USA, October 31-31, 2008). StorageSS '08. ACM, New York, NY,

55 Prílohy 46

56 Príloha A - Technická dokumentácia 47

57 A.1 Ukážka XML štruktúry XAdES formátu Niţšie je uvedená upravená XML štruktúra XAdES-EPES-T formátu. Podpis v tomto formáte obdrţí pouţívateľ potom, čo odošle svoj podpis AS, aby bol vykonaná archivácia podpisu. Pôvodný XAdES-T formát je rozšírený o element ArchiveSignatureRef, ktorý sa nachádza pod elementom UnsignedProperties. Pre samotného pouţívateľa v zásade nemá veľkú hodnotu, bude vyuţívaný najmä AS pri overovaní podpisu. Ako je spomenuté v kapitole 2.7, XAdES formát vychádza z XML Signature, elementy tohto formátu majú prefix ds. XMLDSIG <ds:signature ID?> <ds:signedinfo> <ds:canonicalizationmethod/> <ds:signaturemethod/> (<ds:reference URI? > (<ds:transforms>)? <ds:digestmethod> <ds:digestvalue> </ds:reference>)+ </ds:signedinfo> <ds:signaturevalue> (<ds:keyinfo>)? <ds:object> <QualifyingProperties> <SignedProperties> <SignedSignatureProperties> (SigningTime) (SigningCertificate) (SignaturePolicyIdentifier) (SignatureProductionPlace)? (SignerRole)? </SignedSignatureProperties> <SignedDataObjectProperties> (DataObjectFormat)* (CommitmentTypeIndication)* 48

58 (AllDataObjectsTimeStamp)* (IndividualDataObjectsTimeStamp)* </SignedDataObjectProperties> </SignedProperties> <UnsignedProperties> <UnsignedSignatureProperties> <SignatureTimeStamp/> <ArchiveSignatureRef /> </UnsignedSignatureProperties> </UnsignedProperties> </QualifyingProperties> </ds:object> </ds:signature> XAdES-EPES 49

59 A.2 Schéma archívneho podpisu AS <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <!-- Root element --> <xsd:element name="archivesignature"> <xsd:complextype> <xsd:sequence> <xsd:element name="archivesignaturedata" type="archivesignaturedatatype" maxoccurs="1" /> <xsd:element name="archivetimestamp" type="archivetimestamptype" minoccurs="1" maxoccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="required"/> </xsd:complextype> </xsd:element> <xsd:complextype name="archivesignaturedatatype"> <xsd:sequence> <xsd:element name="signaturereference" type="signaturereferencetype" minoccurs="1" /> <xsd:element name="completecertificaterefs" type="completecertificaterefstype" minoccurs="1" /> <xsd:element name="completerevocationrefs" type="completerevocationrefstype" minoccurs="1" /> <xsd:element name="sigandrefstimestamp" type="xadestimestamptype"/> <xsd:element name="refsonlytimestamp" type="xadestimestamptype"/> <xsd:element name="certificatevalues" type="certificatevaluestype"/> <xsd:element name="revocationvalues" type="revocationvaluestype"/> </xsd:sequence> </xsd:complextype> <!-- SignatureReferenceType --> <xsd:complextype name="signaturereferencetype"> <xsd:sequence> <xsd:element name="signaturedigest" type="digestalgandvaluetype"/> </xsd:sequence> <xsd:attribute name="uri" type="xsd:anyuri" use="required"/> </xsd:complextype> 50

60 <!-- CompleteCertificateRefsType --> <xsd:complextype name="completecertificaterefstype"> <xsd:sequence> <xsd:element name="certrefs" type="certidlisttype" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:complextype> <!-- CertIDListType --> <xsd:complextype name="certidlisttype"> <xsd:sequence> <xsd:element name="cert" type="certidtype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <!-- CertIDType --> <xsd:complextype name="certidtype"> <xsd:sequence> <xsd:element name="certdigest" type="digestalgandvaluetype"/> <xsd:element name="issuerserial" type="x509issuerserialtype"/> </xsd:sequence> <xsd:attribute name="uri" type="xsd:anyuri" use="optional"/> </xsd:complextype> /> <!-- DigestAlgAndValueType --> <xsd:complextype name="digestalgandvaluetype"> <xsd:sequence> <xsd:element name="transforms" type="transformstype" minoccurs="0" <xsd:element name="digestmethod" type="digestmethodtype"/> <xsd:element name="digestvalue" type="digestvaluetype" /> </xsd:sequence> </xsd:complextype> <!-- TransformsType --> <xsd:complextype name="transformstype"> <xsd:sequence> <xsd:element name="transform" type="transformtype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> 51

61 <!-- TransformType --> <xsd:complextype name="transformtype" mixed="true"> <xsd:choice minoccurs="0" maxoccurs="unbounded"> <xsd:any namespace="##other" processcontents="lax"/> <xsd:element name="xpath" type="xsd:string"/> </xsd:choice> <xsd:attribute name="algorithm" type="xsd:anyuri" use="required"/> </xsd:complextype> <!-- DigestMethodType --> <xsd:complextype name="digestmethodtype" mixed="true"> <xsd:sequence> <xsd:any namespace="##other" processcontents="lax" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="algorithm" type="xsd:anyuri" use="required"/> </xsd:complextype> <!-- DigestValueType --> <xsd:simpletype name="digestvaluetype"> <xsd:restriction base="xsd:base64binary"/> </xsd:simpletype> <!-- X509IssuerSerialType --> <xsd:complextype name="x509issuerserialtype"> <xsd:sequence> <xsd:element name="x509issuername" type="xsd:string"/> <xsd:element name="x509serialnumber" type="xsd:integer"/> </xsd:sequence> </xsd:complextype> <!-- CompleteRevocationRefsType --> <xsd:complextype name="completerevocationrefstype"> <xsd:sequence> <xsd:element name="crlrefs" type="crlrefstype" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:complextype> <!-- CRLRefsType --> 52

62 <xsd:complextype name="crlrefstype"> <xsd:sequence> <xsd:element name="crlref" type="crlreftype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <!-- CRLRefType --> <xsd:complextype name="crlreftype"> <xsd:sequence> <xsd:element name="digestalgandvalue" type="digestalgandvaluetype"/> <xsd:element name="crlidentifier" type="crlidentifiertype" minoccurs="0"/> </xsd:sequence> </xsd:complextype> <!-- CRLIdentifierType --> <xsd:complextype name="crlidentifiertype"> <xsd:sequence> <xsd:element name="issuer" type="xsd:string"/> <xsd:element name="issuetime" type="xsd:datetime" /> <xsd:element name="number" type="xsd:integer" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="uri" type="xsd:anyuri" use="optional"/> </xsd:complextype> <!-- XAdESTimeStampType --> <xsd:complextype name="xadestimestamptype"> <xsd:complexcontent> <xsd:restriction base="generictimestamptype"> <xsd:sequence> <xsd:element name="include" type="includetype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="canonicalizationmethod" type="canonicalizationmethodtype" minoccurs="0"/> <xsd:choice maxoccurs="unbounded"> <xsd:element name="encapsulatedtimestamp" type="encapsulatedpkidatatype"/> <xsd:element name="xmltimestamp" type="xsd:anytype"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> 53

63 </xsd:restriction> </xsd:complexcontent> </xsd:complextype> <!-- GenericTimeStampType --> <xsd:complextype name="generictimestamptype" abstract="true"> <xsd:sequence> <xsd:choice minoccurs="0"> <xsd:element name="include" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="referenceinfo" maxoccurs="unbounded"/> </xsd:choice> <xsd:element name="canonicalizationmethod" type="canonicalizationmethodtype" minoccurs="0"/> <xsd:choice maxoccurs="unbounded"> <xsd:element name="encapsulatedtimestamp" type="encapsulatedpkidatatype"/> <xsd:element name="xmltimestamp" type="xsd:anytype"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:complextype> <!-- IncludeType --> <xsd:complextype name="includetype"> <xsd:attribute name="uri" type="xsd:anyuri" use="required"/> <xsd:attribute name="referenceddata" type="xsd:boolean" use="optional"/> </xsd:complextype> <!-- ReferenceInfoType --> <xsd:complextype name="referenceinfotype"> <xsd:sequence> <xsd:element name="digestmethod" type="digestmethodtype" /> <xsd:element name="digestvalue" type="digestvaluetype"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:attribute name="uri" type="xsd:anyuri" use="optional"/> </xsd:complextype> <!-- CanonicalizationMethod --> <xsd:complextype name="canonicalizationmethodtype" mixed="true"> 54

64 <xsd:sequence> <xsd:any namespace="##any" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="algorithm" type="xsd:anyuri" use="required"/> </xsd:complextype> <!-- EncapsulatedPKIDataType --> <xsd:complextype name="encapsulatedpkidatatype"> <xsd:simplecontent> <xsd:extension base="xsd:base64binary"> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:attribute name="encoding" type="xsd:anyuri" use="optional"/> </xsd:extension> </xsd:simplecontent> </xsd:complextype> <!-- CertificateValuesType --> <xsd:complextype name="certificatevaluestype"> <xsd:choice minoccurs="0" maxoccurs="unbounded"> <xsd:element name="encapsulatedx509certificate" type ="EncapsulatedPKIDataType"/> <xsd:element name="othercertificate" type="xsd:anytype"/> </xsd:choice> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:complextype> <!-- RevocationValuesType --> <xsd:complextype name="revocationvaluestype"> <xsd:sequence> <xsd:element name="crlvalues" type="crlvaluestype" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:complextype> <!-- CRLValuesType --> <xsd:complextype name="crlvaluestype"> <xsd:sequence> <xsd:element name="encapsulatedcrlvalue" type="encapsulatedpkidatatype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> 55

65 <xsd:complextype name="archivetimestamptype"> <xsd:sequence> <xsd:element name="alldatadigest" type="digestalgandvaluetype" /> <xsd:element name="alldatatimestamp" type="xadestimestamptype" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="required"/> </xsd:complextype> </xsd:schema> 56

66 A.3 Fyzický dátový model Obrázok A.1: Fyzický dátový model 57

67 Príloha B Používateľská príručka 58

68 B.1 Používateľská príručka Vytvorený archivačný systém a klientská aplikácia vyţadujú nasledovné softvérové prostredie: 1. Operačný systém Windows (odporúčaná je verzia 7) 2. IIS min. verzie 7 (odporúčaná je verzia 7.5) 3..NET Framework 4 4. Microsoft SQL Server 2008 Hardvérové poţiadavky vyplývajú so softvérových poţiadaviek uvedených vyššie a hardvérových poţiadaviek spomínaného softvéru. Odporúča sa mať k dispozícii minimálne 200 MB voľného priestoru na disku. B.1.1 Inštalácia Celý adresár AS\DP z DVD média je potrebné prekopírovať na disk. Táto inštalačná príručka a všetky konfiguračné súbory predpokladajú nakopírovanie tohto adresára na disk D. V prípade iného umiestnenia je potrebné zmeniť niektoré poloţky v konfiguračných súboroch. Zoznam poloţiek, ktoré treba v tomto prípade zmeniť sa nachádza na konci tejto kapitoly. Konfigurácia databázy V MS SQL Serveri je potrebné vytvoriť databázu pre archivačný systém. Databáza sa obnovuje zo súboru ASDB v adresári AS/DB. Postup obnovenia je nasledovný: 1. Pravým kliknutím na poloţku Databases a výberom hodnoty Restore database sa otvorí okno pre obnovenie databázy 2. V zobrazenom okne je potrebné nastaviť výber zdroja na From device 3. Kliknutím na tlačidlo... je potrebné nastaviť cestu k súboru pre obnovenie databázy, cesta k súboru je AS/DB/ASDB 4. Po úspešnom zvolení zdrojového súboru je potrebné nastaviť výstupnú databázu, do políčka To database je potrebné vybrať hodnotu ASDatabase 5. Kliknutím na OK dôjde k obnoveniu databázy Kroky 2, 3 a 5 sú vyznačené na nasledovnom obrázku. 59

69 Obrázok B.1: Obnovenie databázy Import certifikátov Ďalším krokom je importovanie všetkých certifikátov do úloţiska systému Windows. Import prebehne spustením aplikácie Sk.Fiit.Toth.Dp.AS.ImportModule.exe z adresára Libs. Aplikáciu je potrebné pustiť najprv s prepínačom C a potom s prepínačom R. Prepínač C importuje všetky certifikáty, prepínač R importuje certifikáty dôveryhodných autorít. Nastavenie servera IIS V nastaveniach servera IIS je potrebné vytvoriť virtuálny priečinok pre sluţby archivačného systému. Tieto sluţby sa nachádzajú v adresári AS/AS/AS.Wcf.Service, t.j. v IIS je potrebné vytvoriť virtuálny priečinok pre tento adresár s názvom AS.Wcf.Service. 60

70 Úprava konfiguračných súborov V prípade, ţe adresár AS\DP bude nakopírovaný na iný umiestnenie ako disk D je potrebné upraviť niektoré údaje v archivačných súboroch. V nasledovnom zozname je úvedený konfiguračný súbor spolu s poloţkami, kde treba nastaviť správnu cestu podľa umiestnenia adresára AS\DP na disku. Tabuľka B.1: Zoznam konfiguračných súborov Súbor Položky AS\DP\Client\ Sk.Fiit.Toth.Dp.Client.exe.config PolicyPath, LogPath, DefaultCertificate, DefaultOutputPath, Help AS\DP\AS.Retimestamper\ Log Sk.Fiit.Toth.Dp.AS.Retimestamper.exe.config AS\DP\AS.Core.DataAccess\ Log, v dvoch poloţkách Sk.Fiit.Toth.Dp.AS.Core.DataAccess.dll.config connection string je potrebné upraviť názov servera za aktuálny servera, kde beţí databáza (čast reťazca za AS\ DP\AS.Core.DataAccess\bin\Sk.Fiit.Toth.Dp.AS.Core. dll.config AS\ DP\AS.Core.DataAccess\bin\Sk.Fiit.Toth.Dp.AS.TSA. dll.config B.1.2 Používanie klientskej aplikácie výrazom Data Source) DefaultOutputSignaturePath, DefaultOutputArchivePath, Log Log, TSACertificateFileName Klientská aplikácia sa spúšťa pomocou exe súboru Sk.Fiit.Toth.Dp.Client.exe v adresári AS\DP\Client. Štruktúra horného menu aplikácie 1. File a. Create new signature b. Archive existing signature c. Verify archived signature d. Request archived signature and data e. Delete archived signature f. Exit 2. Help a. Help b. About 61

71 Vysvetlenie jednotlivých položiek Create new signature Vytvorenie nového podpisu Kliknutím na túto poloţku je moţné vytvoriť elektronický podpis. Zobrazí okno ako na obrázku B.2. Obrázok B.2: Okno pre vytvorenie nového podpisu Podpis sa dá vytvoriť nasledovným postupom: 1. Pomocou tlačidiel Add XML alebo Remove XML sa dajú pridávať alebo odoberať XML súbory, ktoré budú podpísané 2. Výberom hodnoty pre pole Hash algorithm sa zvolí algoritmus na výpočet hash hodnôt 62

72 3. Výberom hodnoty pre pole Signature Algorithm sa nastaví algoritmus výpočtu hodnoty podpisu 4. Kliknutím na tlačidlo.. sa nastaví cesta k certifikátu, ten musí byť vo formáte pfx resp. p12 2, je potrebné vyplniť aj pole Password heslom, ktoré chráni SK zviazaný s certifikátom 5. Kliknutím na tlačidlo Specify QualifyingProperties sa zobrazí dialógové okno ako na obrázku B.3 pre nastavanie obsahu elementu QualifyingProperties 6. Kliknutím na tlačidlo.. pre pole Output file je moţné nastaviť, kde sa uloţí vytvorený elektronický podpis Obrázok B.3: Špecifikovanie elmentu QualifyingProperties 2 Ide o formát, kde je spolu s certifikátom distribuovaný aj SK 63

73 7. Úspešné vytvorenie podpisu po kliknutí na tlačidlo Sign je oznámené dialógovým oknom ako na obrázku B.4 8. Potom je zobrazené okno ako na obrázku B.5. Odpoveďou Yes je moţné zobraziť podpis pomocou štandardnej aplikácie pre prezeranie xml súborov Obrázok B.4: Oznam o úspešnom vytvorení podpisu Obrázok B.5: Moţnosť zobrazenia podpisu v štandardnej aplikácii pre xml súbory Archive existing signature Archivácia podpisu Kliknutím na poloţku Archive existing signature sa zobrazí okno ako na obrázku B.6, kde je moţné archivovať elektronický podpis. 64

74 Obrázok B.6: Okno pre archivovanie podpisu Postup je nasledovný: 1. Do pola pouţívateľ zadá svoj 2. Kliknutím na tlačidlo.. pouţívateľ vyberie podpis, ktorý chce archivovať 3. Po kliknutí na tlačidlo Archive je v prípade úspešnej archivácie informovaný nasledovným oknom 4. Potom je potrebné zadať cestu, kde sa výsledný modifikovaný podpis uloţí a následne je moţné výsledný podpis zobraziť ako pri vytváraní nového podpisu 65

75 Obrázok B.7: Oznam o úspešnom archivovaní podpisu Verify archived signature Overenie archivovaného podpisu Kliknutím na túto poloţku je zobrazené okno ako na obrázku B.8, kde je moţné overiť archívnu formu podpisu. Do pola Signature je pomocou tlačidla.. potrebné nastaviť cestu k podpisu, ktorý sa má overiť. O úspechu alebo neúspechu operácie po kliknutí na tlačidlo Verify je pouţívateľ informovaný dialógovým oknom. 66