ZEP v Slovenskej republike a Európskej únii

Transcription

1 Slovenská technická univerzita v Bratislave FAKULTA ELEKTROTECHNIKY A INFORMATIKY ZEP v Slovenskej republike a Európskej únii Diplomová práca FEI Študijný program: Študijný odbor: Školiace pracovisko: Vedúci záverečnej práce: Konzultant: aplikovaná informatika aplikovaná informatika Katedra aplikovanej informatiky a výpočtovej techniky prof. RNDr. Otakar Grošekm PhD. Mgr. Juraj Bednár Bratislava 2011 Bc. Tomáš Zaťko

2 ČESTNÉ PREHLÁSENIE Čestne prehlasujem, že diplomovú prácu som vypracoval samostatne na základe vlastných teoretických a praktických poznatkov, konzultácií a štúdia odbornej literatúry, ktorej úplný prehľad je uvedený v zozname použitej literatúry. Bratislava 9. máj 2011

3 Zadanie: ZEP v Slovenskej republike a Európskej únii Analyzujte situáciu používania zaručeného elektronického podpisu v Slovenskej republike a Európskej únii. Popíšte nedostatky existujúcich aplikácií certifikovaných pre použitie v SR a navrhnite aplikáciu, ktorá sa popísané nedostatky pokúsi odstrániť. Vytvorte navrhnutú aplikáciu, ktorá realizuje zaručený elektronický podpis a jeho overenie podľa príslušného predpisu Národného Bezpečnostného Úradu. Aplikáciu vytvorte tak, aby bola použiteľná s otvorenými formátmi. Úlohy: 1. Naštudujte legislatívne súvislosti týkajúce sa zaručeného elektronického podpisu do miery potrebnej pre technickú implementáciu v Slovenskej republike a Európskej únii 2. Popíšte všetky právne náležitosti potrebné pre používanie zaručeného elektronického podpisu v Slovenskej Republike 3. Popíšte a porovnajte existujúce aplikácie a ich nedostatky 4. Navrhnite aplikáciu na realizáciu zaručeného elektronického podpisu a jeho overenie 5. Implementujte a otestujte navrhnutú aplikáciu. Literatúra: 1. Zákon č. 215/2002 Z. z. o elektronickom podpise 2. Ostatná literatúra podla zadania vedúceho práce

4 Ďakujem svojmu odbornému konzultantovi Mgr. Jurajovi Bednárovi, za cenné rady, pomoc a podporu. Ďakujem svojim rodičom za roky strávené formovaním mojej osobnosti a za všetku energiu, ktorú na to vynaložili. Ďakujem svojej rodine, partnerke a priateľom za to, že spríjemňujú čas strávený na tejto planéte.

5 Anotácia V práci popisujeme aktuálny stav v oblasti zaručeného elektronického podpisu v Európskej únii a konkrétne, Slovenskej a Českej republike. V skorších častiach práce ozrejmujeme matematické princípy, na ktorých je založený digitálny podpis. Ozrejmujeme rozdiel a súvislosti medzi pojmami digiálny podpis, elektronický podpis a zaručený elektronický podpis. Neskôr popisujeme procesy, možnosti, povinnosti a právne náležitosti súvisiace s používaním zaručeného elektronického podpisu. Dôležitým výsledkom práce je označenie nedostatkov, ktoré majú dopad na bezpečnosť používania zaručeného elektronického podpisu v Slovenskej republike. Navrhujeme niekoľko opatrení, ktorými je možné spomínané nedostatky odstrániť. Výsledkom zistených nedostatkov existujúcich softvérových riešení je návrh vlastnej aplikácie pre používateľov zaručeného elektronického podpisu. Kľúčové slová: zaručený elektronický podpis, kvalifikovaný certifikát, bezpečné zariadenie, akreditovaná certifikačná autorita

6 Anotation In this thesis we describe an actual situation regarding the qualified electronic signature in European Union, especially in the Slovak and Czech Republic. In earlier parts we describe the mathematical principles of digital signature. We explain differences and relations among the digital signature, electronic signature, and qualified electronic signature. Later we describe processes, options, duties and legislative context regarding the qualified electronic signature. Important outcome of this thesis is the identification of drawbacks that affects security of qualified electronic signature usage in the Slovak Republic. We offer several countermeasures that can fix the described drawbacks. Another result of identified drawbacks of the existing software products is design of our own application for signatures creation and verification. Keywords: qualified electronic signature, qualified certificate, secure device, accredited certification authority

7 Táto stránka je zámerne ponechaná prázdna 7

8 Obsah 1 Úvod 13 2 Bezpečnosť Informačná bezpečnosť Kryptografia Symetrická kryptografia Asymetrická kryptografia Hašovacie funkcie X Digitálny certifikát Certifikačná autorita Infraštruktúra verejných kľúčov Pavučina dôvery Podpis Digitálny podpis Elektronicky podpis Zaručený elektronický podpis Legislatíva v Slovenskej Republike Legislatíva v Českej Republike Kompatibilita ZEP v Európskej únii Formáty podpisu CAdES XAdES PAdES a iné formáty Používanie ZEP v Slovenskej Republike Začiatok používania Útok Podvrhnutie inštalačných balíkov Podvrhnutie certifikátu koreňovej certifikačnej autority Riešenie Komunikácia s Disig a NBÚ Principiálna bezpečnosť ZEP Aktuálny legislatívny stav a jeho dopady na bezpečnosť Zhoda zobrazeného s podpisovaným Výhradne softvérové riešenie na nededikovanom systéme Použitie hardvérového kryptografického modulu na nededikovanom systéme

9 3.8.5 Použitie dedikovaného systému Bezpečné a cenovo dostupné riešenie Problémy štandardov Certifikované produkty Hardvérové produkty Softvérové produkty Naša aplikácia Analýza Návrh Implementácia Komunikácia so zariadením Vytváranie podpisu a obálky Záver 69 A CD 76 B Odpoveď NBÚ na žiadosť o poskytnutie informácií 77 C Textová podoba certifikátu NBÚ KCA3 79 D Ukážky certifikátov bezpečných produktov 82

10 Zoznam obrázkov 1 Komponenty informačnej bezpečnosti [30] Hierarchia certifikačných autorít Diagram procesu podpisovania Diagram procesu overovania Inštrukcie pre začiatok používania Spojenie protokolom HTTP Inštalované certifikáty Gemalto USB Shell Token V Hlavné menu aplikácie QSign Podpisovanie dokumentu v aplikácii QSign Aplikácia QSign sa pýta na dôveryhodnosť KCA Rozdelenie komponentov SCA Schéma komponentov našej SCA Schéma komponentov našej SVA Zoznam tabuliek 1 Zrušovacie kódy Zaručený elektronický podpis bez časovej pečiatky Zaručený elektronický podpis s časovou pečiatkou Zaručený elektronický podpis s úplnou informáciou na overenie platnosti 38 5 Archívny zaručený elektronický podpis Atribúty CAdES a XML elementy XAdES s rovnakým významom obsahu 39 7 Výskyt ASN.1 atribútov v CAdES a XML elementov v XAdES Ukážka obsahu zep súboru Zoznam skratiek API - Application Programming Interface ASCII - American Standard Code for Information Interchange ASN.1 - Abstract Syntax Notation 1 CA - Certificate Authority CMS Cryptographic Message Syntax CPV - Certificate path validator

11 CRL Certificate Revocation List DER Distinguished Encoding Rules (for ASN.1) DHC - Data Hashing Component DTBSF - Data To Be Signed Formatter EFF - Electronic Frontier Foundation EP - Elektronický podpis ES - Electronic signature HSM - Hardware Security Module HTTP - HyperText Transfer Protocol HTTPS - HTTP Secure ISECOM - The Institute for Security and Open Methodologies ISO - International Organization for Standardization KC - Kvalifikovaný certifikát KCA - Koreňová CA MIME - Multipurpose Internet Mail Extensions MITM - Man-in-the-middle attack NONCE - Number used once OCSP - Online Certificate Status Provider OID - Object IDentifier OSSTMM - Open Source Security Testing Methodology Manual PKCS - Public Key Cryptographic Standards PKI - Public Key Infrastructure QC - Qualified Certificate RSA - Rivest, Shamir and Adleman Algorithm SAV - Signature Attributes Viewer SCA - Signature Creation Application SCVA - Signature Creation & Verification Application SDC - Signer s Document Composer

12 SDD - Signer s Document Decomposer SDOC - a Signed Data Object Composer SDOD - a Signed Data Object Decomposer SDP - Signer s Document Presentation Component SIC Signer Interaction Component SPI - Service Provider Interface SSCD - Secure Signature Creation Device SSL - Secure Socket Layer SVA - Signature Verification Application SVC - Signature verification component TLS - Transport Layer Security XAdES - XML Advanced Electronic Signature XER - XML Encoding Rules (for ASN.1) XML - Extensible Markup Language ZEP - Zaručený elektronický podpis (Qualified Electronic Signature)

13 1 Úvod Informačné technológie v súčasnosti vedome či nevedome stretávame na každom kroku. Čoraz väčšie množstvo aktivít vykonávame v takzvanom virtuálnom priestore. Počítače zapojené v sieti používame pri štúdiu, práci, zábave či komunikácii s blízkymi. Z tepla domova vieme už aj nakupovať a množstvo online služieb sa neustále zväčšuje. Tomuto trendu sa postupne prispôsobuje aj štát. S jeho orgánmi môžeme komunikovať pomocou elektronickej pošty, množstvo informácií vieme získať z príslušných webových stránok. Dokážeme uskutočňovať právne úkony, na ktoré bolo v nedávnej minulosti nutné osobne navštíviť úrad. Elektronicky môžeme napríklad založiť firmu, alebo podať daňové priznanie. Tieto vymoženosti so sebou prinášajú radu výhod, avšak aj riziká. Aby bola elektronická komunikácia v úradnom styku bezpečná, bolo potrebné vytvoriť mechanizmy s takými podmienkami, aby boli riziká znížené na akceptovateľnú úroveň. Vzniknuté mechanizmy voláme zaručený elektronický podpis. V tejto práci sa zaoberáme zaručeným elektronickým podpisom hlavne z pohľadu užívateľa a užívateľskej bezpečnosti. Popisujeme matematické, ako aj právne a procesné princípy, na ktorých je postavený zaručený elektronický podpis. Téma zaručeného podpisu je veľmi dôležitá, pretože v budúcnosti budeme čoraz viac konfrontovaný s jeho použitím. 2 Bezpečnosť Aby sme v nasledujúcich častiach práce vylúčili nedorozumenia, ujasníme si najskôr niekoľko pojmov. Začneme od významu slova bezpečnosť, ktorý je každému človeku kontextovo známy. Bezpečnosť môžeme chápať ako úroveň ochrany subjektu pred poškodením, zničením, stratou, kriminálnou činnosťou, alebo vo všeobecnosti pred hrozbou niečoho zlého. Bežne sa stretávame s políciou, predstavujúcou bezpečnostnú zložku štátu, ktorá má chrániť jeho záujmy. Počas jazdy autom sme pripútaní bezpečnostným pásom, ktorý má vo chvíli dopravnej nehody chrániť naše telo pred poškodením. Ľudia si do bytov inštalujú bezpečnostné dvere, ktoré majú chrániť ich osobný majetok pred krádežou. Inštitút pre bezpečnosť a otvorené metodológie v metodológii OSSTMM [1] definuje bezpečnosť ako funkciu odlúčenia aktíva od hrozby. Odlúčenie je možné dosiahnuť tromi logickými a proaktívnymi spôsobmi: 1. Vytvoriť fyzickú alebo logickú bariéru medzi aktívami a hrozbami 2. Upraviť hrozby do neškodného stavu 3. Odstrániť hrozby 13

14 Môžeme povedať, že bezpečnosť je o znižovaní miery rizika. Mierna rizika závisí na bezpečnostnom okolí, teda iných subjektoch vo fyzickej alebo logickej blízkosti chráneného aktíva. Parametre bezpečnostného okolia sa vo väčšine prípadov časom menia. Z toho dôvodu je bezpečnosť dynamická a jej prvky treba s postupujúcim časom upravovať vzhľadom na aktuálne súvislosti. 2.1 Informačná bezpečnosť Jednou z odnoží bezpečnosti je informačná bezpečnosť. Môžeme ju definovať [29] ako schopnosť siete alebo informačného systému ako celku odolať s určitou úrovňou spoľahlivosti náhodným udalostiam, nezákonnému, alebo zákernému konaniu, ktoré ohrozuje dostupnosť, pravosť, integritu a dôvernosť uchovávaných alebo prenášaných údajov a súvisiacich služieb poskytovaných, alebo prístupných prostredníctvom týchto sietí a systémov. Často bývajú zamieňané pojmy informačná bezpečnosť a počítačová bezpečnosť. Vzhľadom na to, že v dnešnej dobe sú informačné systémy väčšinou realizované pomocou počítačových systémov, sú tieto oblasti v úzkej súvislosti, ale nie sú totožné. Informačná bezpečnosť sa zaoberá ochranou informácií vo všetkých formách, či už ide o údaje vytlačené na papieri, údaje v ľudskej pamäti, alebo údaje uložené na USB kľúči. Počítačová bezpečnosť je špecializovanou odnožou informačnej bezpečnosi, ktorá sa zaoberá ochranou informácií uložených v digitálnej podobe, v počítačových systémoch. Hlavnými cieľmi informačnej bezpečnosti sú integrita údajov, dôvernosť údajov, dostupnosť údajov, autentickosť údajov, nepopierateľnosť konania a časová súslednosť. Integrita (alebo tiež neporušenosť) zaručuje, že s údajmi medzi časom ich vzniku a aktuálnym časom ich použitia nedošlo ich zmene. Či už ide o zmenu náhodnú, spôsobenú chybou prenosového kanálu, alebo úložného média, alebo chybu spôsobenú cieleným zásahom. V prvom prípade môžeme zmenu odhaliť a zároveň opraviť s použitím samoopravného kódu. V druhom prípade, ktorý je z hľadiska bezpečnosti dôležitejší, problém riešime pomocou hašovacích funkcií iných metód, ktoré podrobnejšie rozoberieme v samostatnej kapitole. Dôvernosť údajov zaručuje, že údaje budú prístupné iba autorizovaným osobám a naopak neautorizované osoby k chráneným údajom nebudú vedieť pristúpiť. Dôvernosť najlepšie zabezpečujeme s použitím kryptografických algoritmov. Autentickosť zaručuje, že vieme spoľahlivo určiť, že informácie sú pravé a nezmenené a že obe strany, ktoré si informácie vymieňajú, sú tie, za ktoré sa vydávajú. 14

15 Autentickosť zabezpečujeme s použitím elektronického podpisu. Nepopierateľnosť konania zaručuje, že ak osoba uskutočnila určitý úkon, nemôže táto osoba tvrdiť, že daný úkon neuskutočnila. Taktiež zaručuje, že k určitému uskutočnenému úkonu vieme jednoznačne priradiť osobu, ktorá ho vykonala. Časová súslednosť zaručuje, že vieme spoľahlivo určiť v akej chronológii boli operácie vykonané a s použitím prídavných prvkov tiež určiť presný čas vykonaných operácií. Najčastejšie uvádzané ciele, sú niekedy spoločne označované ako CIA trojca (CIA triad), podľa začiatočných písmen anglických názvov Confidentiality - dôvernosť, Integrity - neporušenosť, Availability - dostupnosť. Na obrázku 1 vidíme, akým spôsobom sú okolo CIA trojce, s chránenými informáciami uprostred, vybudované kľúčové bezpečnostné komponenty. Obr. 1: Komponenty informačnej bezpečnosti [30] 15

16 2.2 Kryptografia Dôvernosťou (a dnes už aj integritou prenášaných informácií) sa zaoberá vedná disciplína zvaná kryptografia. Jej základnou úlohou je transformácia hodnotných údajov do takej formy, v ktorej sú pre každú neautorizovanú osobu nepoužiteľné. Širšou vednou disciplínou je kryptológia, ktorú definujeme [28] ako metódy pre ochranu správy pred nepriateľom (kryptografia), ako aj štúdium odolnosti použitých metód voči známym útokom, resp. štúdium samotných metód narušenia (kryptoanalýza). Aby mohol byť text zo svojej hodnotnej formy (v tejto forme ho budeme nazývať otvorený text) transformovaný do nečitateľnej formy (v tejto forme ho budeme nazývať zašifrovaný text), je potrebné aplikovať deterministický a vopred známy algoritmus. Jeho aplikovanie nazývame šifrovanie. Opačnú procedúru, ktorú vykonáva autorizovaná osoba, aby zo zašifrovaného textu získala pôvodný otvorený text, voláme dešifrovanie. Algoritmus pre vykonanie transformácie jedným aj druhým smerom voláme šifrovací algoritmus, alebo skrátene šifra. Aby bola transformácia bezpečná a teda mala význam, je potrebné proces parametrizovať tajným kľúčom. Kryptografia je rozsiahla vedná disciplína a pre jej bližšie štúdium odporúčame dostupnú slovenskú literatúru [28] a referencie v nej. Pre účely tejto práce iba v krátkosti pripomenieme dve jej základné kategórie, ktoré sú rozdelené podľa spôsobu narábania s kľúčom. V niektorých prípadoch budeme používať zaužívané [33] mená fiktívnych osôb. Menami Alica a Bob budeme označovať osoby, ktoré chcú spolu bezpečne komunikovať, Eva (od anglického eavesdropping - odpočúvanie) bude pasívny útočník, ktorý dokáže odpočúvať komunikáciu a menom Mallory (od anglického malicious - zákerný) budeme označovať útočníka, ktorý vie aktívne zasahovať do komunikácie Symetrická kryptografia Ak je na šifrovanie a dešifrovanie správy potrebný rovnaký kľúč, hovoríme o symetrickej kryptografii. Predstavme si že Bob posiela Alici správu, ktorá je zašifrovaná kľúčom K. Aké možnosti má Eva, ktorá odchytí zašifrovaný text, ale nepozná kľúč, ktorý bol použitý na šifrovanie? Ak bola použitá moderná šifra, ktorá dodržiava Kerckhoffov princíp a výskum v oblasti kryptoanalýzy v nej nepreukázal zraniteľnosti, potom Eve neostáva nič iné, ako sa pokúšať o získanie šifrovacieho kľúču. Ak bol šifrovací kľúč medzi autorizovanými účastníkmi komunikácie vymenený bezpečným spôsobom, napríklad pri osobnom stretnutí, ostáva Eve prehľadanie priestoru kľúčov hrubou silou. Čo však v prípade, ak účastníci komunikácie nemali príležitosť pre bezpečnú výmenu kľúčov? Akým spôsobom si môžu Alica s Bobom dohodnúť kľúč? Keďže chcú používať šifrovanie, je zrejmé, že komunikačný kanál nie je bezpečný. To znamená, že zaslanie správy obsahujúcej kľúč cez takýto kanál nemá význam. Eva, ktorá má možnosť kanál 16

17 odpočúvať, by zachytila kľúč a následne by dokázala dešifrovať zachytené šifrované správy. Ďalej si predstavme, že potrebujeme zabezpečiť, aby spolu bezpečne komunikovala väčšia skupina ľudí. Členovia tejto skupiny sa môžu stretnúť vopred a vymeniť si navzájom kľúče. Aby bola komunikácia pre všetkých bezpečná, každý pár ľudí musí mať vlastný (iný) kľúč. To znamená, že v skupine n ľudí vznikne (n 2 n)/2 párov. Teda každý človek musí vykonať toľko osobných výmen kľúčov. Vidíme, že sme narazili na vážnu prekážku v efektívnom používaní symetrickej kryptografie. Symetrická kryptografia však riešenie problému s distribúciou kľúču neponúka. Do roku 1976 neexistovalo riešenie vôbec Asymetrická kryptografia V novembri roku 1976 zverejnili W. Diffie a M. Hellman prelomový článok [31], ktorý odštartoval nový prúd kryptografie. Tento prúd nazývame kryptografia verejného kľúča, alebo tiež asymetrická kryptografia. Algoritmus, ktorý Hellman a Diffie popísali, slúži na bezpečnú výmenu kľúča cez nezabezpečený kanál. Kľúč je postupne skonštruovaný účastníkmi a nikdy nie je poslaný v otvorenej forme. Takto dohodnutý kľúč sa spravidla ďalej používa pri šifrovaní pomocou symetrickej kryptografie. Algoritmus je založený na probléme diskrétneho logaritmu a nesie názov po svojich autoroch Diffie Hellman key exchange. Nasledujúcim pokrokom bolo vyvinutie algoritmu RSA v roku Názov algoritmu vznikol zo začiatočných písmen priezvisk svojich autorov (Rivest, Shamir, Adleman). Tento algoritmus, ktorý bol popísaný v [32], je založený na probléme faktorizácie zložených čísel a je prvým algoritmom, ktorý je vhodný na šifrovanie a zároveň podpisovanie (ktoré vysvetlíme neskôr). Základným stavebným prvkom je kľúčový pár. Asymetria v označení asymetrická kryptografia pochádza z rozdelenia kľúčového páru na súkromný a verejný kľúč. Vlastník páru zverejní svoj verejný kľúč tak, aby sa k nemu mohol dostať každý, kto s ním chce komunikovať. Pomocou verejného kľúču je možné správu zašifrovať a takto šifrovanú ju poslať nezabezpečeným kanálom. Dešifrovanie je možné vykonať iba s pomocou súkromného kľúču. Ukážeme si jednoduchý zápis algoritmu [28]: 1. Každý účastník siete zverejní verejný (šifrovací) kľúč (n, e), kde n = pq je súčin dvoch veľkých prvočísel a gcd(e, ϕ(n)) = Zároveň si vypočíta súkromný (dešifrovací) kľúč (n, d), splňujúci rovnosť ed 1 (mod ϕ(n)). 3. Otvorený text (správa) je x Z n. Šifrovanie a dešifrovanie je dané vzťahmi šifrovanie: e k (x) x e (mod n) 17

18 dešifrovanie: d k (y) y e (mod n) Keď chce Alica po prvý krát šifrovane komunikovať s Bobom, pošle mu svoj verejný kľúč V K A a on odpovie so svojim verejným kľúčom V K B. Keďže už pozná Alicin verejný klúč, svoju odpoveď zašifruje. Alica získa Bobov verejný kľúč a všetku nasledujúcu komunikáciu môžu šifrovať. Eve, ktorá takúto výmenu kľúčov zachytila, získané údaje k zlomeniu šifry nepomôžu. Predstavme si však prípad, kedy je v strede komunikácie Mallory a situáciu pozmení nasledovne: Alica posiela svoj verejný kľúč e A Bobovi. Mallory správu zachytí a vidí, že Alica posiela Bobovi svoj verejný kľúč. Mallory správu zmení a Bobovi pošle svoj vlastný verejný kľúč e M. Bob prečíta Malloryho správu s verejným kľúčom e M v domnení, že ide o Alicin kľúč. Odpovie svojim verejným kľúčom e B a svoju odpoveď zašifruje kľúčom e M. Mallory zachytí Bobovu odpoveď a dešifruje ju svojim súkromným kľúčom d M. Vidí, že Bob posiela Alici svoj verejný kľúč e B a miesto neho jej pošle svoj kľúč e M, pričom správu zašifruje Alicinim verejným kľúčom e A. Alica získanú správu dešifruje svojim súkromným kľúčom d A a prečíta si Malloryho verejný kľúč e M v domnení, že získala kľúč, ktorý patrí Bobovi. V tejto chvíli dokáže Mallory dešifrovať a modifikovať všetku komunikáciu medzi Alicou a Bobom. Ako si môže Alica (Bob) overiť, že verejný kľúč patrí skutočne Bobovi (Alici)? V praxi sa tento problém rieši za pomoci tretej strany, ktorá je pre Alicu aj Boba (a mnoho ďalších ľudí) dôveryhodná. Tretia strana vie k verejnému kľúču pridať overiteľnú informáciu, v ktorej vyhlasuje, že daný verejný kľúč naozaj patrí danej konkrétnej osobe. Túto informáciu budeme volať certifikát a jej vydavateľa certifikačná autorita Hašovacie funkcie Dôležitou oblasťou kryptografie je problematika hašovacích funkcií. Haše majú v koncepte digitálneho podpisu obrovský bezpečnostný význam, preto si priblížime ich princíp. Všeobecná hašovacia funkcia je taká funkcia, ktorá zo vstupu ľubovoľnej dĺžky vypočíta výstupnú hodnotu konštantnej dĺžky a spĺňa nasledovné podmienky: Rýchlosť výpočtu - výpočet výstupu H(x) zo vstupu x musí byť rýchly 18

19 Distribúcia výstupov - výstupy funkcie musia byť v obore hodnôt rozložené rovnomerne Lavínovitosť - závislosť výstupu na vstupe je taká silná, že aj najmenšia zmena vstupu výrazným spôsobom ovplyvní výstup Kryptografická haš funkcia musí okrem spomenutých podmienok spĺňať aj niekoľko ďaľších: Jednosmernosť (preimage resistance) - musí byť ľahké ľahké nájsť pre hodnotu vstupu x hodnotu H(x), ale ťažké nájsť inverznú funkciu, teda nájsť pre hodnotu H(y) hodnotu y. Silná bezkolíznosť (second preimage resistance) - pre každý vstup x 1 musí byť ťažké nájsť ľubovoľný vstup x 2 taký, že H(x 1 ) = H(x 2 ). Slabá bezkolíznosť (collision resistance) - musí byť ťažké nájsť ľubovoľné dva vstupy x 1 a x 2 také, že H(x 1 ) = H(x 2 ). 2.3 X.509 X.509 je kryptografický štandard pre systémy založené na asymetrickej kryptografii. Špecifikuje napríklad formát digitálnych certifikátov, zoznamy zrušených certifikátov, parametre certifikátov, alebo metódy na kontrolu platnosti certifikátov. Štandard bol po prvý krát vydaný roku V dnešnej dobe je ako X.509 bežne označovaný štandard X.509 verzie 3, ktorý je popísaný v [34]. Pravidlá jeho používania popisuje [42] Digitálny certifikát Digitálny certifikát je elektronický dokument, ktorý preukazuje spojitosť medzi verejným kľúčom a identitou jeho držiteľa. Certifikát vydáva dôveryhodná tretia strana, ktorú voláme certifikačná autorita. V praxi sa používajú rôzne typy certifikátov podľa toho, akú úroveň dosahuje overenie údajov o vlastníkovi. Napríklad pri certifikátoch používaných pre zabezpečenie prístupu na webové stránky pomocou protokolu HTTPS sa často používajú certifikáty, pri ktorých CA overuje iba to, či má žiadateľ kontrolu nad doménou, na ktorú certifikát žiada. Menej časté sú tzv. EV (z anglického extended Validation) certifikáty, pri ktorých je kontrola CA oveľa pozornejšia, trvá dlhšie a berie do úvahy aj právnu stránku celej veci. Špeciálnou kategóriou sú certifikáty, ktoré sú podpísané samé sebou (častejšie sa používa z anglickej terminológie Self-signed certificate ). Ide buď o certifikáty, ktoré sú určené na 19

20 testovanie implementácie zabezpečeného spojenia, alebo certifikáty, ktoré sú na vrchole reťaze dôvery (ktorú popíšeme neskôr). V oblasti elektronického podpisu sa používa pojem kvalifikovaný certifikát (a kvalifikovaná certifikačná autorita), ktorý vysvetlíme neskôr. V samotnom certifikáte sa nachádzajú informácie o dobe platnosti, identite vlastníka, verejný kľúč vlastníka a digitálny podpis týchto údajov, ktorý vytvorila vydávajúca certifikačná autorita. Štruktúra certifikátu je zadefinovaná v ASN.1 a jej vizuálna podoba vyzerá nasledovne: Certifikát Verzia Sériové číslo ID číslo algoritmu Vydavateľ Platnosť Od Do Vlastník verejného kľúču Informácie o verejnom kľúči vlastníka Algoritmus Verejný kľúč Unikátny identifikátor vydavateľa (voliteľné) Unikátny identifikátor vlastníka (voliteľné) Rozšírenia (voliteľné)... Algoritmus podpisu certifikátu Podpis certifikátu Certifikačná autorita Certifikačná autorita je dôveryhodná tretia strana, ktorá vydáva certifikáty verejných kľúčov, podľa ktorých si účastníci komunikácie môžu overiť, či je vlastníkom verejného 20

21 (a teda tiež prislúchajúceho súkromného) kľúča naozaj deklarovaná entita. Aby mohlo byť takéto overenie uskutočnené, musí užívateľ certifikačnej autorite dôverovať a poznať jej vlastný certifikát. Predstavme si nasledovnú zjednodušenú situáciu. Existuje jedna dôveryhodná certifikačná autorita, ktorej veria všetci užívatelia. Každý z nich získal jej certifikát dôveryhodnou cestou, napríklad ako súčasť inštalačného média operačného systému. Alica a Bob chcú spolu bezpečne komunikovať a obaja vlastnia certifikáty verejných kľúčov, ktoré podpísala (jediná) certifikačná autorita. Alica zašle Bobovi svoj certifikát a Bob overením zistí, že CA sa skutočne zaručila za to, že verejný kľúč patrí Alici. Bob zašle v odpovedi Alici svoj vlastný certifikát a Alica ho overí rovnakým spôsobom ako Bob. Už v predošlej časti sme ukázali, že Eve, ktorá komunikáciu odpočúva, získané informácie nepomôžu. Aké možnosti má v tomto prípade Mallory, ktorý vie zasahovať do komunikácie? Obohaťme predchádzajúci príklad s Mallorym o prítomnosť certifikátov: Alica posiela svoj certifikáť C A Bobovi. Mallory správu zachytí a vidí, že Alica posiela Bobovi svoj certifikát. Mallory vidí, že certifikát podpísala CA, ktorej Bob dôveruje. Mallory správu zmení a Bobovi pošle svoj vlastný certifikát C M, ktorý sa vydáva za Alicin a je podpísaný sebou samým. Bob prečíta Malloryho správu s certifikátom C M v domnení, že ide o Alicin certifikát. Bob certifikát overí a zistí, že nie je podpísaný certifikačnou autoritou, ktorej dôveruje. Bob v tejto chvíli vie, že niečo nie je v poriadku a preto nepokračuje v komunikácii. V praxi ale neexistuje jediná certifikačná autorita, ktorej dôverujú všetci užívatelia. Naopak, existujú viaceré certifikačné autority zapojené v hierarchickej štruktúre v rámci Infraštruktúry verejných kľúčov Infraštruktúra verejných kľúčov Infraštruktúra verejných kľúčov (často označovaná PKI podľa anglického Public Key Infrastructure) je množinou hardvérových a softvérových prostriedkov, ľudí, politík a postupov potrebných na tvorbu, správu, distribúciu, používanie, ukladanie a zrušovanie digitálnych certifikátov [37]. V súčasnosti sú používané dve formy tejto infraštruktúry. Akronymom PKI (niekedy označovanom PKI CA) sa väčšinou označuje prvá z nich a to tá, ktorá je založená na hierarchickom modeli certifikačných autorít. Na vrchole hierarchie sa nachádza koreňová certifikačná autorita (KCA). Jej certifikát je podpísaný samým sebou. Medzi rozšíreniami, ktoré určujú možnosti 21

22 Obr. 2: Hierarchia certifikačných autorít použitia, sa nachádza informácia o tom, že certifikát patrí certifikačnej autorite. X509v3 extensions : X509v3 Basic Constraints : CA: TRUE KCA vydáva certifikáty pre ďalšie certifikačné autority, pričom do rozšírení vydaných certifikátov zapisuje pravidlá. Nasledujúci záznam v certifikáte hovorí o tom, že certifikát síce patrí certifikačnej autorite, ale dĺžka cesty certifikačncýh autorít od autority, pre ktorú je certifikát vydaný, je nulová. X509v3 extensions : X509v3 Basic Constraints : CA:TRUE, pathlen =0 To v praxi znamená, že táto certifikačná autorita nedokáže vytvoriť ďalšie certifikačné autority. V skutočnosti je technicky možné podpísať certifikát ďaľšej certifikačnej autorite, avšak v takom prípade je na zodpovednosti validačného algoritmu, aby pri kontrole platnosti certifikačnej cesty takto vytvorenú CA zamietol ako nedôveryhodnú a certifikát ňou vydaný považoval za nevalidný. V prípade, že pathlen=n, kde n > 0, môže pokračovať podpisovanie certifikátov hierarchicky podradených CA až do hĺbky n. Je dôležité si uvedomiť, že podpisovanie do šírky obmedzené nie je. Teda CA s pathlen=1 môže vytvoriť neobmedzené množstvo podriadených CA. Dôležitou súčasťou infraštruktúry verejných kľúčov je zrušovanie certifikátov. Štandard X.509 definuje dva spôsoby, akým je zrušovanie uskutočňované. Prvým a starším z nich je zverejňovanie zoznamov zrušených certifikátov (označovaných CRL podľa anglického Certificate Revocation List). CRL obsahuje zoznam sériových čísel 22

23 zrušených certifikátov a je podpísaný súkromným kľúčom certifikačnej autority, ktorá ho vydala. Uvedením v zozname môže byť platnosť certifikátu buď pozastavená, alebo zrušená. Pozastavenie je stav, ktorý je možné odvolať. Odvolať zrušenie nie je možné. V špecifikácii [38] je definovaných niekoľko kódov, ktoré vyjadrujú dôvod zrušenia certifikátu. Ich zoznam uvádzame v tabuľke 1. Zoznamy zrušených certifikátov sú zverejňované periodicky, typicky raz za tridsať minút. K zverejneniu novej verzie zoznamu môže dôjsť aj okamžite po zrušení certifikátu, ak sa tak CA rozhodne urobiť. Zoznam vydáva vždy tá CA, ktorá vydala certifikáty so sériovými číslami uvedenými v zozname. Kód Textová hodnota Vysvetlenie 0 unspecified Zrušenie bez udania dôvodu. 1 keycompromise Kompromitácia privátneho kľúča 2 cacompromise Kompromitácia certifikačnej autority 3 affiliationchanged Zmena v pridružení 4 superseded Nahradenie novým certifikátom 5 cessationofoperation Zastavenie činnosti 6 certificatehold Pozastavenie certifikátu 7 Nepoužíva sa 8 removefromcrl Odvolanie pozastavenia 9 privilegewithdrawn Odobratie prísupových práv 10 aacompromise Kompromitácia atribútovej autority Tabuľka 1: Zrušovacie kódy Alternatívnou a novšou metódou pre overenie, či je certifikát zrušený, je použitie protokolu OCSP (Online Certificate Status Protocol). Vznikol, aby odstránil niektoré nedostatky svojho predchodcu CRL. Správy protokolu sú kódované v ASN.1 a zabalené v HTTP. Na požiadavku obsahujúcu sériové číslo overovaného certifikátu, odpovedá server podpísanou odpoveďou jednou z možností good (certifikát je platný), revoked (certifikát je zrušený), alebo unknown (certifikát s daným sériovým číslom nie je známy). Protokol má voliteľnú ochranu pred útokom opakovaním (replay attack). Rozšírenie požiadavky môže obsahovať NONCE, ktorý je súčasťou podpísanej časti odpovede. Používanie NONCE však nie je povinné. OCSP je rýchlejší spôsob overenia, pretože jeho odpoveď má menšiu veľkosť ako bežný CRL súbor. Na strane klienta navyše odpadá nutnosť prehľadávať dlhý zoznam kvôli hľadanému sériovému číslu. Keď chce Alica overiť, či je Bobov certifikát platný, overovací algoritmus musí vykonať overenie certifikačnej cesty. V prvom kroku musí zistiť, či aktuálny čas spadá do intervalu platnosti Bobovho certifikátu. Následne overí jeho podpis. Na to potrebuje poznať verejný kľúč certifikačnej autority, ktorá certifikát vydala. Ten sa nachádza v certifikáte certifikačnej autority. V ňom sú okrem iných uložené aj informácie o tom, ako je možné získať zoznam zrušených certifikátov. Algoritmus teda príslušnou cestou 23

24 (CRL, alebo OCSP) overí, či Bobov certifikát nebol zrušený a taktiež overí podpis získanej odpovede. Pokračuje overením podpisu Bobovho certifikátu. Ak je v poriadku, algoritmus v ďaľšom kroku overuje certifikát príslušnej CA. Tam sa proces opakuje. Znovu je braný do úvahy certifikát nadradenej CA, podľa ktorej sa overuje podpis certifikátu podriadenej CA a prítomnosť v zozname zrušených certifikátov a tento postup pokračuje až po dôveryhodnú koreňovú CA. Infraštruktúra verejných kľúčov certifikačných autorít má niekoľko známych bezpečnostných nedostatkov. Princíp PKI je založený hlavne na dôvere užívateľov k certifikačným autoritám. Nedávny výskum [35][36] nadácie Electronic Frontier Foundation ukázal, že bežne používaný softvér dôveruje viac ako 1400 certifikačným autoritám. Certifikačné autority spolupracujú na štátom vykonávaných útokoch [40] typu MITM. Ak útočník zablokuje CRL a OCSP, väčšina bežného softvéru (webové prehliadače, mailové klienty) nevyhlási žiadnu chybu. CA Comodo sa dňa 15.Marca 2011 stala terčom úspešného útoku [39], ktorého výsledkom bolo vydanie 9 certifikátov pre 7 domén svetového významu. Tieto a rôzne iné nedostatky uberajú dôveru v certifikačné autority, ktorá je základným kameňom tohoto systému. Pri používaní elektronického podpisu na slovensku sa používa PKI CA, ktorej aktuálne jedinou koreňovou certifikačnou autoritou je NBÚ. Aktuálny stav má nedostatky, ktoré popíšeme v neskorších častiach práce Pavučina dôvery Alternatívny prístup k autentifikácii verejných kľúčov je schéma, ktorú nazývame pavučina dôvery (web of trust). Koncept tejto schémy navrhol v roku 1992 Phil Zimmermann, autor populárneho šifrovacieho softvéru PGP. Systém pavučiny dôvery je na rozdiel od PKI CA plne decentralizovaný. Nezávislých sietí dôvery môže existovať mnoho a zapojiť sa so svojim kľúčom môže ktokoľvek. Každý účastník má na začiatku certifikát podpísaný samým sebou a postupne získava podpisy iných účastníkov. K podpisovaniu dochádza typicky pri osobnom stretnutí a kľúče si vzájomne podpisujú ľudia, ktorí sa už v minulosti poznali. Sieť sa tvorí a rozširuje práve vzájomným podpisovaním. Jej štruktúra pripomína sociálnu sieť. Tento koncept sa v prostredí zaručeného elektronického podpisu nepoužíva a preto sa s ním ďalej nebudeme zaoberať. 24

25 2.4 Podpis Podpis, ktorý človek vykoná pomocou pera a svojej ruky na papieri, vyjadruje súhlas podpísanej osoby s podpisovaným dokumentom a potvrdzuje jej identitu. Vyjadrenie tohoto súhlasu má právnu váhu a vzniknutý záväzok je právne vymáhateľný. Význam vlastnoručného podpisu spočíva hlave v tom, že jeho falšovanie je ťažké. V dnešnej dobe, kedy informačné technológie stretávame na každom kroku, potrebujeme obdobu vlastnoručného podpisu, ktorú je možné aplikovať na elektronické dokumenty a spĺňa pri najmenšom nasledovné požiadavky: Môže byť vytvorená iba subjektom, ktorý reprezentuje Umožňuje prijímateľovi dokumentu overiť, že dokument nebol po podpísaní zmenený Umožňuje identifikovať vlastníka podpisu a potvrdzovať vôľu podpis vytvoriť Ak tieto požiadavky preložíme do zaužívanej terminológie z oblasti informačnej bezpečnosti, potrebujeme: autenticitu možno overiť, že dokument naozaj podpísal človek, ktorému patrí daný elektronický podpis, integritu možno preukázať, že po podpísaní nedošlo v podpísaných dátach k žiadnej zmene, nepopierateľnosť presnejšie nepopierateľnosť pôvodu - autor podpisu nemôže tvrdiť, že elektronický dokument nepodpísal Spomenuté podmienky spĺňa elektronický podpis. Jeho použitím navyše získame možnosť použitia časovej pečiatky, ktorá preukazuje dátum a čas podpísania dokumentu. Elektronický podpis je legislatívny koncept, ktorý definuje konkrétne pravidlá pre všetky súvisiace náležitosti. Je postavený na matematickom modeli, ktorý voláme digitálny podpis. Keďže elektronický podpis je v súčasnosti implementovaný jedine pomocou digitálneho podpisu, tieto pojmy sú často zamieňané. Pojem elektronický podpis je však širší, ako pojem digitálny podpis. 2.5 Digitálny podpis Digitálny podpis je založený na princípoch asymetrickej kryptografie, o ktorej sme písali v časti Berme do úvahy algoritmus RSA. Povedali sme si, že základným prvkom je kľúčový pár. Súkromný kľúč má poznať iba jeho vlastník a teda osoba, ktorej bude patriť digitálny podpis a verejný kľúč musí poznať každý človek, ktorý potrebuje 25

26 overiť pravosť digitálneho podpisu. Schéma digitálneho podpisu sa bežne skladá z troch algoritmov: 1. Generovanie kľúčov - náhodná voľba súkromného kľúču z množiny možných súkromných kľúčov a vypočítanie prislúchajúceho verejného kľúču. 2. Podpisovanie - výpočet hodnoty podpisu na základe súkromného kľúču a podpisovanej správy. 3. Overovanie - overenie platnosti podpisu na základe verejného kľúču, podpísanej správy a samotného podpisu. Bezpečnosť tohoto riešenia sa spolieha na to, že z verejného kľúča (n, e) nie je možné vypočítať prislúchajúci súkromný exponent d. V súčasnosti sa dôveryhodnosť opiera o aktuálny kryptografický výskum, ktorý doposiaľ neukázal spôsob ako s dostupnými prostriedkami v polynomickom čase faktorizovať modul n na p a q a pomocou (p 1)(q 1) vypočítať d. Na druhej strane nie je známy dôkaz, že takýto algoritmus neexistuje. Autori RSA dokázali [32], že vypočítanie d z (n, e) je rovnako ťažký problém, ako faktorizovanie n na p a q. Digitálny podpis je informácia vypočítaná z dokumentu a súkromného kľúču. S použitím verejného kľúču prislúchajúceho k súkromnému kľúču použitého na vytvorenie podpisu je možné overiť, či je daný dokument zhodný s dokumentom, z ktorého bol podpis vypočítaný. Za predpokladu, že súkromné kľúče sú známe iba ich vlastníkom, digitálny podpis spĺňa podmienku autenticity a integrity. Aby sme docielili aj splnenie podmienky nepopierateľnosti zdroja, je potrebné vytvoriť dôveryhodné spojenie medzi verejným kľúčom a identitou vlastníka prislúchajúceho súkromného kľúču. Na tento účel slúžia digitálne certifikáty, ktoré sme popísali v časti Pre úplnosť v krátkosti vysvetlíme princípy vzniku a overenia podpisu. Uvedené príklady sú úmyselne zjednodušené, aby lepšie ilustrovali princíp fungovania. Podpisovanie správy pomocou RSA je založené na rovnakom princípe ako šifrovanie. Keď Alice posiela Bobovi správu m, šifruje ju tým, že jej hodnotu umocní Bobovim verejným exponentom e. Šifrovaná správa má teda hodnotu c = m e (mod n). Bob dokáže dešifrovať zašifrovanú správu c jej umocnením na svoj súkromný exponent d. Vďaka tomu, že ed = 1 (mod n), platí c d = (m e ) d = m ed = m (mod n). Pri vytváraní podpisu sa rovnako využíva vlastnosť ed = 1 (mod n). Keď chce Bob poslať Alici podpísanú správu m, umocní ju na svoj súkromný exponent d a Alici pošle výsledok s = m d. V praxi sa miesto správy podpisuje jej haš. Podpisovanie má potom priebeh vyobrazený na obrázku 3. 26

27 Dáta Hašovacia funkcia Haš Šifrovanie súkromným kľúčom signatára Dig Certifikát Podpis Dáta Hašovacia funkcia Pripojenie k dátam Haš Digitálne podpísané dáta Obr. 3: Diagram procesu podpisovania Overovanie podpisu znovu využíva vlastnosť RSA ed = 1 (mod n). Keď Alica získa podpísanú správu s, ktorú jej zaslal Bob, umocnením na Bobov verejný exponent e získa pôvodnú správu m. Platí s e = (m d ) e = m de = m. Bob nemôže poprieť, že Alici poslal správu m, pretože nikto iný nepozná súkromný exponent d a teda nemohol vytvoriť s = m d. Povedali sme, že v praxi sa podpisuje haš správy a nie samotná správa, preto praktické overovanie podpisu má priebeh vyobrazený na obrázku 4. 27

28 Haš Šifrovanie súkromným kľúčom signatára Digitálne podpísané dáta ojenie dátam Podpis Dáta Hašovacia funkcia Haš? Podpis Dešifrovanie verejným kľúčom signatára Haš Obr. 4: Diagram procesu overovania odpísané dáta 2.6 Elektronicky podpis Elektronický podpis je v širšom význame ľubovoľný elektronický prostriedok, ktorý vyjadruje súhlas podpísanej osoby s podpisovaným obsahom. Elektronický podpis je legislatívny koncept, ktorý upravuje jeho podobu, pravidlá používania a v mnohých krajinách je (alebo niektoré jeho špeciálne prípady) pred zákonom zrovnoprávnený s vlastnoručným podpisom. To je možné vďaka trom kľúčovým vlastnostiam (autentifikácia, integrita, nepopierateľnosť), ktoré sme už spomínali skôr. Veľmi dôležitou vlastnosťou elektronického podpisu je tiež nemožnosť podpísať bianko dokument. V rôznych krajinách sveta sú rôznymi spôsobmi upravené pravidlá používania a jeho podoba. Napríklad v Spojených štátoch amerických je podľa zákona elektronickým podpisom elektronický zvuk, symbol, alebo proces, ktorý je priložený a logicky spojený so zmluvou alebo iným záznamom s úmyslom daný záznam podpísať [41]. V Európskej únii ho definuje ako dáta v elektronickej forme, ktoré sú pripojené alebo logicky pridružené k ostatným elektronickým dátam a ktoré slúžia ako metóda overovania pravosti [14], pričom ďalej pomocou nutných požiadaviek definuje jeho špeciálny prípad 28

29 zdokonalený elektronický podpis. V Slovenskej a Českej republike sa používa pojem zaručený elektronický podpis. V oboch krajinách ide o špeciálny prípad zdokonaleného elektronického podpisu, ale v každej z nich je definovaný inak. Túto problematiku podrobnejšie rozoberieme v samostatnej kapitole. 3 Zaručený elektronický podpis 3.1 Legislatíva v Slovenskej Republike V Slovenskej Republike je používanie zaručeného elektronického podpisu legislatívne upravené zákonom č. 215/2002 Z.z. [2] o elektronickom podpise a o zmene a doplnení niektorých zákonov (ďalej len zákon ). 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 osôb a právnických osôb pri používaní elektronického podpisu, hodnovernosť a ochranu elektronických dokumentov podpísaných elektronickým podpisom. Zákon vychádza zo Smernice Európskej únie č. 1999/93/EC z decembra 1999 [14] a účinnosť nadobudol v plnom rozsahu dňa 1. septembra Na slovensku je ústredným orgánom štátnej správy pre elektronický podpis Národný bezpečnostný úrad. Ten k zákonu vydal niekoľko vykonávacích predpisov, ktoré ďalej upravujú podmienky používania ZEP: Vyhláška Národného bezpečnostného úradu č. 131/2009 Z.z., o formáte, obsahu a správe certifikátov a kvalifikovaných certifikátov a formáte, periodicite a spôsobe vydávania zoznamu zrušených kvalifikovaných certifikátov (o certifikátoch a kvalifikovaných certifikátoch) [7] Vyhláška Národného bezpečnostného úradu č. 132/2009 Z.z., o podmienkach na poskytovanie akreditovaných certifikačných služieb a o požiadavkách na audit, rozsah auditu a kvalifikáciu audítorov [8] Vyhláška Národného bezpečnostného úradu č. 133/2009 Z.z., o obsahu a rozsahu prevádzkovej dokumentácie vedenej certifikačnou autoritou a o bezpečnostných pravidlách a pravidlách na výkon certifikačných činností [9] Vyhláška Národného bezpečnostného úradu č. 134/2009 Z.z., ktorou sa ustanovujú podrobnosti o požiadavkách na bezpečné zariadenia na vyhotovovanie časovej pečiatky a požiadavky na produkty pre elektronický podpis (o produktoch elektronického podpisu) [10] Vyhláška Národného bezpečnostného úradu č. 135/2009 Z.z., o formáte a spôsobe vyhotovenia zaručeného elektronického podpisu, spôsobe zverejňovania verejného kľúča úradu, podmienkach platnosti pre zaručený elektronický podpis, postupe 29

30 pri overovaní a podmienkach overovania zaručeného elektronického podpisu, formáte časovej pečiatky a spôsobe jej vyhotovenia, požiadavkách na zdroj časových údajov a požiadavkách na vedenie dokumentácie časových pečiatok (o vyhotovení a overovaní elektronického podpisu a časovej pečiatky) [11] Vyhláška Národného bezpečnostného úradu č. 136/2009 Z.z., o spôsobe a postupe používania elektronického podpisu v obchodnom styku a administratívnom styku [12] Podľa aktuálneho právneho stavu v SR je zaručeným elektronickým podpisom taký elektronický podpis, ktorý spĺňa nasledovné podmienky: je vyhotovený pomocou súkromného kľúča, ktorý je určený na vyhotovenie zaručeného elektronického podpisu. možno ho vyhotoviť len s použitím bezpečného zariadenia na vyhotovovanie elektronického podpisu. spôsob jeho vyhotovovania umožňuje spoľahlivo určiť, ktorá fyzická osoba zaručený elektronický podpis vyhotovila, na verejný kľúč patriaci k súkromnému kľúču použitému na vyhotovenie zaručeného elektronického podpisu je vydaný kvalifikovaný certifikát. Bezpečné zariadenie na vyhotovovanie elektronického podpisu je také zariadenie, na vyhotovenie elektronického podpisu, ktoré spĺňa požiadavky zákona [2] a od úradu získalo certifikát bezpečného produktu pre ZEP. Kvalifikovaný certifikát je podľa 7 zákona 215/2002 taký certifikát, ktorý okrem štandardných podmienok pre certifikát spĺňa ešte ďalšie podmienky: Bol vydaný akreditovanou certifikačnou autoritou fyzickej osobe ( obyčajný certifikát nemusí byť nutne vydaný na meno fyzickej osoby, pretože zákon povoľuje aj vydanie na základe pseudonymu, ak tento jednoznačne identifikuje osobu). V certifikáte musí byť uvedené, že je kvalifikovaný. Kvalifikovaný certifikát má obmedzenia na použitie. Znamená to, že je v ňom uvedené, či môže byť prislúchajúci súkromný kľúč použitý na podpisovanie alebo šifrovanie. To znamená, že súkromný kľúč a k nemu prislúchajúci kvalifikovaný certifikát bol vydaný registračnou autoritou za použitia certifikovaného produktu, a podpisovať 30

31 možno len pomocou certifikovaného zariadenia SSCD a certifikovanej aplikácie SCVA. V kontexte zaručeného elektronického podpisu v Slovenskej Republike certifikovaným produktom označujeme taký produkt, ktorý od NBÚ SR získal Certifikát bezpečného produktu pre zaručený elektronický podpis. Ukážka takéhoto certifikátu je v prílohe D. Akreditovaná certifikačná autorita akreditáciu od Národného bezpečnostného úradu. je taká certifikačná autorita, ktorá získala Podpisová politika definuje pravidlá pre vytváranie a overovanie elektronického podpisu. Je súčasťou podpísaných atribútov rozšíreného elektronického podpisu. 3.2 Legislatíva v Českej Republike V Českej Republike legislatívu súvisiacu so zaručeným elektronickým podpisom upravujú ZÁKON č. 227/2000 Sb. o elektronickém podpisu a o změně některých dalších zákonů (zákon o elektronickém podpisu) [23] VYHLÁŠKA č. 378/2006 Sb. o postupech kvalifikovaných poskytovatelů certifikačních služeb, o požadavcích na nástroje elektronického podpisu a o požadavcích na ochranu dat pro vytváření elektronických značek (vyhláška o postupech kvalifikovaných poskytovatelů certifikačních služeb) [24] VYHLÁŠKA č. 496/2004 Sb. o elektronických podatelnách NAŘÍZENÍ VLÁDY č. 495/2004 Sb., kterým se provádí zákon č. 227/2000 Sb., o elektronickém podpisu a o změně některých dalších zákonů (zákon o elektronickém podpisu), ve znění pozdějších předpisů POKYN č. D-252, Podmínky pro podání v daňových věcech prostřednictvím datové zprávy (podání v elektronické podobě) INSTRUKCE Ministerstva spravedlnosti ČR č. 13/2002-OI-SP-2 ze dne o používání elektronického podpisu v resortu spravedlnosti V Českej Republike je zaručeným elektronickým podpisom elektronický podpis, ktorý spĺňa nasledujúce 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, 31

32 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žno zistiť akúkoľvek následnú zmenu dát, Zákon ďalej definuje, že podpisujúcou osobou je fyzická osoba, ktorá je držiteľom prostriedku pre vytváranie elektronických podpisov a prostriedkom pre vytváranie elektronických podpisov je technické zariadenie, alebo programové vybavenie, ktoré sa používa k vytváraniu elektronických podpisov. To v praxi znamená, že český zákon na rozdiel od slovenského nevyžaduje používanie SSCD zariadení, ani používanie certifikovaných softvérových produktov. 1. Prostriedok pre bezpečné vytváranie podpisu musí za pomoci zodpovedajúcich technických a programových prostriedkov a postupov minimálne zaistiť, že a) dáta sa pre vytváranie podpisu môžu vyskytnúť iba raz a že ich utajenie je náležite zaistené, b) dáta pre vytváranie podpisu nie je možné pri náležitom zaistení odvodiť zo znalosti spôsobu ich vytvárania a že podpis je chránený proti falšovaniu s využitím existujúcej dostupnej technológie c) dáta pre vytváranie podpisu môžu byť podpisujúcou osobou spoľahlivo chránené proti zneužitiu treťou osobou 2. Prostriedky pre bezpečné vytváranie podpisu nesmú meniť dáta, ktoré sa podpisujú, ani zabraňovať tomu, aby boli tieto dáta predložené podpisujúcej osobe pred vlastným procesom podpisovania 3. Prostriedky pre bezpečné vytváranie elektronických podpisov musia byť pred svojim použitím bezpečným spôsobom vydané a dáta pre vytváranie elektronických podpisov musia byť dôveryhodným spôsobom v týchto prostriedkoch vytvorené, alebo do nich pridané. 4. Prostriedok pre bezpečné overovanie podpisu musí za pomoci zodpovedajúcich technických a programových prostriedkov a postupov minimálne zaistiť, aby a) dáta používané na overenie podpisu zodpovedali dátam zobrazeným osobe, ktorá overenie vykonáva b) bol podpis spoľahlivo overený a výsledok tohoto overenia bol riadne zobrazený c) osoba vykonávajúca overenie mohla spoľahlivo zistiť obsah podpísaných dát d) pravosť a platnosť certifikátu pri overovaní podpisu boli spoľahlivo zaistené 32

33 e) výsledok overenia a totožnosť osoby boli riadne zobrazené f) bolo jasne uvedené použitie pseudonymu g) bolo možné zistiť všetky zmeny ovplyvňujúce bezpečnosť Zákon ďalej prikazuje, že podpisujúca osoba je povinná zaobchádzať s prostriedkami, ako aj s dátami pre vytváranie zaručeného elektronického podpisu s náležitou starostlivosťou tak, aby nemohlo dôjsť k ich neoprávnenému použitiu a v prípade hroziaceho nebezpečenstva takéhoto zneužitia o tom neodkladne upovedomiť poskytovateľa certifikačných služieb. Z uvedeného vyplýva, že zákon právnym jazykom popisuje požiadavky na na digitálny podpis a stanovuje bezpečnostné podmienky na zariadenia pre prácu so ZEP. Tieto podmienky ale na strane užívateľa nie sú nijakým spôsobom vynucované. Používateľ ZEP v Českej republike si sám na svojom počítači generuje kľúčový pár a žiadosť o vydanie kvalifikovaného certifikátu, ktorú zašle registračnej autorite. Český užívateľ má teda na rozdiel od slovenského užívateľa prístup k hodnote privátneho kľúču. Bežným softvérovým vybavením na vytváranie ZEP je klient elektronickej pošty s podporou S/MIME. 3.3 Kompatibilita ZEP v Európskej únii Témou elektronického podpisu sa zaoberá smernice Európskej únie č. 1999/93/EC z decembra 1999 [14] z ktorej vychádza aj náš zákon č. 215/2002 Z.z. [2]. Smernica definuje minimálne požiadavky na veci súvisiace s elektronickým podpisom a súvisiace povinnosti členských štátov. Implementáciu tejto smernice legislatívne upravuje každá členská krajina zvlášť. Rozhodnutím komisie 2009/767/ES zo sa ustanovujú opatrenia na uľahčenie postupov elektronickými spôsobmi prostredníctvom miest jednotného kontaktu podľa smernice Európskeho parlamentu a Rady 2006/123/ES o službách na vnútornom trhu. Toto rozhodnutie nadobudlo účinnosť dňa Orgány verejnej moci sú od dňa nadobudnutia účinnosti povinné uznávať kvalifikované certifikáty vydané poskytovateľmi certifikačných služieb členských krajín EÚ, ak je splnený predpoklad, že príslušná členská krajina zverejní zoznam dôveryhodných poskytovateľov služieb. Toto rozhodnutie, žiaľ, nemá očakávaný dopad a automaticky neumožňuje používanie používanie kvalifikovaných certifikátov vydaných inými členskými krajinami EÚ. NBÚ SR v tejto súvislosti vydal právne stanovisko [15], ktoré sa odvoláva na smernicu Európskeho parlamentu a Rady 199/93/ES [14]. V tej je uvedené, 33

34 že podmienky pre platnosť cudzích elektronických podpisov na svojom teritóriu si stanovuje každý štát sám a smernica v tomto smere dáva iba odporúčania. Túto skutočnosť na Slovensku upravuje 17 ods. 2 zákona [2] a to nasledovne: Dňom vstupu Slovenskej republiky do Európskej únie sa certifikát vydaný certifikačnou autoritou majúcou sídlo v niektorej z krajín Európskej únie, ktorého platnosť možno overiť v Slovenskej republike, stáva rovnoprávnym certifikátu vydanému v Slovenskej republike. Kvalifikovaný certifikát vydaný uvedenou certifikačnou autoritou bude mať rovnakú právnu účinnosť ako kvalifikovaný certifikát vydaný v Slovenskej republike. Z tejto formulácie vyplýva, že pre overenie zaručeného elektronického podpisu vydaného zahraničnou akreditovanou certifikačnou autoritou je rozhodujúca možnosť overiť platnosť certifikátu príslušného verejného kľúča. Proces overenie podlieha právnym predpisom Slovenskej republiky. Postup overovania zaručeného elektronického podpisu upravuje vyhláška Národného bezpečnostného úradu č. 135/2009 Z. z. o vyhotovení a overovaní elektronického podpisu a časovej pečiatky [11]. Na overenie zaručeného elektronického podpisu sa v zmysle vyhlášky [11] vyžaduje, aby boli dostupné úplné informácie o všetkých certifikátoch verejných kľúčov potrebných na overenie platnosti daného zaručeného elektronického podpisu, ako aj úplné informácie o zoznamoch zrušených certifikátov alebo informácie o stave certifikátov, ktoré sú rozhodujúce na overenie platnosti daného zaručeného elektronického podpisu. To znamená, že na bezpečné a hodnoverné overenie platnosti zaručeného elektronického podpisu v Slovenskej republike musíme poznať celý reťazec certifikátov verejného kľúča: kvalifikovaný certifikát verejného kľúča podpisovateľa certifikát verejného kľúča akreditovanej certifikačnej autority certifikát verejného kľúča Národného bezpečnostného úradu. Celý reťazec overovania kvalifikovaného certifikátu verejného kľúča, začínajúc kvalifikovaným certifikátom verejného kľúča podpisovateľa, končiac certifikátom verejného kľúča koreňovej certifikačnej autority, musí byť dodržaný a zachovaný aj v prípade zahraničných certifikátov. Národný bezpečnostný úrad je podľa 34 zákona č. 575/2001 z. z. o organizácii činnosti vlády a organizácii ústrednej štátnej správy ústredným orgánom štátnej správy pre elektronický podpis. Národný bezpečnostný úrad vykonáva kontrolu dodržiavania zákona a jeho vykonávacích predpisov a garantuje bezpečnosť prostredia elektronického podpisu. Národný bezpečnostný úrad však nemôže ručiť za zahraničné akreditované certifikačné autority a nimi vydané kvalifikované certifikáty, pretože nemá právo na ich kontrolu, a o ktorých nevie za akých legislatívnych, technických, organizačných, bezpečnostných a iných podmienok poskytujú svoje služby. Jediným možným riešením 34

35 ako uznať platnosť zahraničného kvalifikovaného certifikátu v Slovenskej republike je uzavretie medzinárodnej dohody alebo prijatie legislatívy v rámci Európskej únie, ktorá jednotlivé štáty zaviaže dodržiavať porovnateľné pravidlá a akreditačné postupy pre posúdenie dôveryhodnosti poskytovateľov certifikačných služieb (Akreditované certifikačné autority). Voľnosť smernice [14] navyše spôsobuje, že súčasný stav teórie bezpečnosti vytvárania elektronického podpisu v rámci Európskej únie nie je jednotný. Kontrastným príkladom je extrémna prísnosť v Slovenskej republike v porovnaní s extrémnou voľnosťou v českej republike. 3.4 Formáty podpisu Aby bolo možné používanie ZEP, je potrebné definovať jednoznačné pravidlá pre formát a obsah podpisu. Túto úlohu vykonáva NBÚ, ktorý podľa vyhlášok NBÚ č. 131/2009 Z.z. a č. 135/2009 Z.z. zverejňuje platné formáty zaručených elektronických podpisov, ich formálne špecifikácie, ako aj iné súvisiace náležitosti [21]. Podĺa štandardu [22], ktorý vydal NBÚ, musia byť zaručené elektronické podpisy slúžiace na komunikáciu s orgánmi verejnej moci v Slovenskej republike vytvorené od typu CAdES alebo XAdES. Iné typy než CAdES a XAdES sa nesmú použiť. CAdES alebo XAdES podpisy musia obsahovať všetky povinné atribúty, ktoré sú pre jednotlivé formáty ZEP požadované, ale môžu obsahovať aj iné, nešpecifikované voliteľné atribúty. V nasledovných častiach si popíšeme formáty CAdES a XAdES CAdES Podpisový formát CAdES (CMS Advanced Electronic Signatures) je definovaný v [19]. Jeho štruktúra je vyjadrená v ASN.1. Všeobecný štandard CAdES definuje šesť podformátov, ktoré sa líšia úrovňou ochrany. Každý nasledujúci je rozšírením predchádzajúceho: CAdES základná forma spĺňajúca zákonné požiadavky pre rozšírený podpis CAdES-T (timestamp) pridáva časovú pečiatku CAdES-C (complete) k podpísaným dokumentom pridáva referencie na verifikačné údaje (certifikáty a zoznamy zrušených certifikátov) CAdES-X (extended) k referenciám, ktoré pridáva CAdES-C pridáva časovú pečiatku 35

36 CAdES-X-L (extended long-term) pridáva samotné certifikáty a zoznamy zrušených certifikátov CAdES-A (archival) pridáva možnosť periodického pridávania časovej pečiatky V Slovenskej republike je možné používať jeho nasledovné podformáty: Zaručený elektronický podpis bez časovej pečiatky (Tabuľka 2) Zaručený elektronický podpis s časovou pečiatkou (Tabuľka 3) Zaručený elektronický podpis s úplnou informáciou na overenie platnosti (Tabuľka 4) Tento typ podpisu vzhľadom na zistené nedostatky pri uvádzaní nepriamych CRL a OCSP sa neodporúča používať. Archívny zaručený elektronický podpis (Tabuľka 5) Archívny podpis slúži hlavne na ochranu podpisu podpisovateľa z dlhodobého hľadiska, aby bolo možné podpis overiť a považovať ho za platný aj v prípadoch, ak dôjde ku kompromitácii CA alebo znemožneniu prístupu k informáciám o CRL, OCSP alebo, ak algoritmy použité na vytvorenie podpisu sa po dlhšej dobe stanú menej bezpečnými. V takýchto prípadoch bude možné podpis overiť a považovať za platný vďaka tomu, že archívny podpis zabezpečí podpisom časovej pečiatky dlhodobejšie dôveryhodné uzavretie obsahu všetkých potrebných informácií na overenie podpisu. Archivovanie elektronického podpisu pomocou archívneho zaručeného podpisu vyžaduje samostatné archívne opečiatkovanie každého podpisu so silnejším kľúčom a v dostatočne dlhých časových intervaloch, čo so všetkými certifikátmi a údajmi potrebnými na overenie platnosti certifikátov je neefektívne pri väčších počtoch podpisov a preto sa odporúča, pri systémoch archivujúcich veľké množstvo elektronických podpisov, použitie integritného podpisu podľa postupu v prílohe B v dokumente [22] XAdES XAdes (XML Advanced Electronic Signatures) je podpisový formát popísaný v [20]. Podformáty a pravidlá pre obsah atribútov podpisového formátu CAdES platia rovnako pre obsah elementov v XAdES formáte. Kvôli jednoznačnosti pri definovaní povinných atribútov zaručeného elektronického podpisu uvádzame tabuľku 6, ktorá atribútom z formátu CAdES priraďuje XML element z formátu XAdES. 36

37 P/V Názov atribútu id-contenttype id-messagedigest id-aa-ets-signingcertificatev2 alebo id-aa-signingcertificate id-aa-ets-sigpolicyid id-signingtime id-aa-ets-contenttimestamp id-aa-ets-signerlocation id-aa-ets-certificaterefs id-aa-ets-revocationrefs id-aa-ets-esctimestamp alebo id-aa-ets-certcrltimestamp id-aa-ets-archivetimestamp id-aa-ets-certvalues id-aa-ets-revocationvalues id-aa-ets-signerattr Tabuľka 2: Zaručený elektronický podpis bez časovej pečiatky P/V Názov atribútu id-contenttype id-messagedigest id-aa-ets-signingcertificatev2 alebo id-aa-signingcertificate id-aa-ets-sigpolicyid id-aa-signaturetimestamptoken id-signingtime id-aa-ets-contenttimestamp id-aa-ets-signerlocation id-aa-ets-certificaterefs id-aa-ets-revocationrefs id-aa-ets-esctimestamp alebo id-aa-ets-certcrltimestamp id-aa-ets-archivetimestamp id-aa-ets-certvalues id-aa-ets-revocationvalues id-aa-ets-signerattr Tabuľka 3: Zaručený elektronický podpis s časovou pečiatkou PAdES a iné formáty Smernica Európskeho parlamentu a Rady 1999/93/ES [14] ako aj vyhláška NBÚ č. 135/2009 [11] neobmedzujú formát zdokonaleného elektronického podpisu len na CMS či XML formát podpisu. Umožňujú implementáciu podpisu aj v iných formátoch, ktoré zabezpečujú nimi stanovené požiadavky. Príkladom je PAdES (PDF AdES). V súčasnosti tieto formáty neumožňujú uloženie všetkých potrebných údajov na overenie platnosti kvalifikovaného certifikátu, ktorý musí byť vydaný na verejný kľúč prislúchajúci k súkromnému kľúču uloženému na SSCD podpisovateľa. Z toho 37

38 P/V Názov atribútu id-contenttype id-messagedigest id-aa-ets-signingcertificatev2 alebo id-aa-signingcertificate id-aa-ets-sigpolicyid id-aa-signaturetimestamptoken id-aa-ets-certificaterefs id-aa-ets-revocationrefs id-aa-ets-certvalues alebo v SignedData.certificates id-signingtime id-aa-ets-esctimestamp alebo id-aa-ets-certcrltimestamp id-aa-ets-contenttimestamp id-aa-ets-signerlocation id-aa-ets-archivetimestamp id-aa-ets-revocationvalues id-aa-ets-signerattr Tabuľka 4: Zaručený elektronický podpis s úplnou informáciou na overenie platnosti P/V Názov atribútu id-contenttype id-messagedigest id-aa-ets-signingcertificatev2 alebo id-aa-signingcertificate id-aa-ets-sigpolicyid id-aa-signaturetimestamptoken id-aa-ets-certvalues id-aa-ets-revocationvalues id-aa-ets-archivetimestamp id-signingtime id-aa-ets-certificaterefs id-aa-ets-revocationrefs d-aa-ets-esctimestamp alebo id-aa-ets-certcrltimestamp id-aa-ets-contenttimestamp id-aa-ets-signerlocation id-aa-ets-signerattr Tabuľka 5: Archívny zaručený elektronický podpis dôvodu ich používanie na Slovensku zákon nedovoľuje. 38

39 ASN.1 Atribút (id-contenttype) (id-messagedigest) (id-signingtime) (id-aa-ets-signingcertificatev2) alebo(id-aa-signingcertificate) (id-aa-ets-sigpolicyid) (id-aa-ets-contenttimestamp)* (id-aa-ets-signerlocation)? (id-aa-ets-certificaterefs) (id-aa-ets-revocationrefs) (id-aa-signaturetimestamptoken)+ ((id-aa-ets-esctimestamp)* (id-aa-ets-certcrltimestam)*)+ (id-aa-ets-archivetimestamp)+ (id-aa-ets-certvalues) (id-aa-ets-revocationvalues) (id-aa-ets-signerattr) Ekvivalentný XML element (DataObjectFormat) + pri MIME obálke je typ MimeType = message/rfc822 a Encoding = base64 a ak nie je použitá MIME obálka, tak typ uvedený v MimeType musí byť v súlade s dokumentom [47] Nemá ekvivalent v XML podpise. V XML podpise je haš počítaný na základe pravidiel definovaných v dokumente XAdES a je obsiahnutý v elemente DigestValue. (SigningTime) (SigningCertificate) (SignaturePolicyIdentifier) (AllDataObjectsTimeStamp)* alebo (IndividualDataObjectsTimeStamp)* (SignatureProductionPlace)? (CompleteCertificateRefs) (CompleteRevocationRefs) (SignatureTimeStamp)+ ( (SigAndRefsTimeStamp)* (RefsOnlyTimeStamp)* )+ (ArchiveTimeStamp)+ (CertificatesValues) (RevocationValues) (SignerRole) Tabuľka 6: Atribúty CAdES a XML elementy XAdES s rovnakým významom obsahu Značka Vysvetlenie ( ) iba jeden raz ( )* nemusí, ale môže byť aj viackrát ( )? nemusí, ale môže byť jedenkrát ( )+ musí byť minimálne jedenkrát Tabuľka 7: Výskyt ASN.1 atribútov v CAdES a XML elementov v XAdES 39

40 3.5 Používanie ZEP v Slovenskej Republike Pre vydanie prostriedkov na zaručený elektronický podpis je potrebná osobná návšteva jednej z pobočiek registračných autorít (ďalej RA). V pobočke RA je potrebné predložiť dva doklady totožnosti, napríklad občiansky preukaz a cestovný pas. V prípade, že o vydanie prostriedkov žiada splnomocnená osoba, alebo je potrebné, aby bol v kvalifikovanom certifikáte uvedený aj názov organizácie, je potrebné predložiť aj ďalšie potrebné dokumenty uvedené v [4]. Pre účely tejto práce sme dňa v pobočke RA Disig, Záhradnícka 151, Bratislava požiadali o vydanie prostriedkov na zaručený elektronický podpis. Proces zahŕňal podanie žiadosti o vydanie kvalifikovaného certifikátu certifikačnou autoritou CA Disig, uzavretie zmluvy o vydaní a používaní kvalifikovaného certifikátu a služieb CA Disig, prevzatie prostriedkov pre ZEP (SSCD zariadenie obsahujúce súkromný kľúč a kvalifikovaný certifikát), potvrdenia o vydaní KC (ktoré obsahuje heslo pre zrušenie certifikátu) a inštrukcií pre začiatok používania. Celý proces bol bezproblémový a trval asi tridsať minút. Zaručený elektronický podpis sa v Slovenskej republike využíva najmä v styku so štátnou správou. V súčastnosti je možné ZEP používať v styku s colnou správou, daňovou správou, a na portáli verejnej správy. V styku s colnou správou môže subjekt používať ZEP v colnom konaní. Na to musí: 1. Zabezpečiť všetkým relevantným osobám prostriedky pre ZEPom 2. Zaregistrovať sa do elektronickej podateľne CRSR a to predložením: Dohody o používaní zaručeného elektronického podpisu Prílohy k dohode Technických parametrov elektronickej komunikácie Originálu alebo úradne overenej kópie výpisu z OR 3. Vlastniť softvér potrebný pre komunikáciu s CRSR. V styku s daňovou správou môže subjekt elektronicky podávať daňové dokumenty. Aby to bolo možné, je potrebné, aby osoba zastupujúca subjekt v elektronickej komunikácii s daňovou správou vlastnila prostriedky pre ZEP a z jej kvalifikovaného certifikátu bolo jasné, že má oprávnenie podpisovať za daný subjekt elektronický daňový dokument. Ďalej je potrebná registrácia na portáli drsr.sk, ktorá zahŕňa: 1. Vyplnenie registračného formulára na drsr.sk, pri ktorej bude subjektu pridelené ID. 2. Osobná autorizácia na miestne príslušnom Daňovom úrade realizovaná predložením potrebnej dokumentácie. 40

41 3. Inštalácia SW v zmysle požiadaviek prevádzkovateľa portálu drsr.sk. 4. Prijatie u s potvrdením o vytvorení konta na portáli drsr.sk. 5. Prihlásenie sa na portál drsr.sk cez ID a heslo a následné priradenie kvalifikovaného certifikátu do správy certifikátov. Ústredný portál verejnej správy umožňuje občanom/subjektom zasielať tzv. kvalifikované podania, pri ktorých sa textová časť podania podpisuje zaručeným elektronickým podpisom. Aktuálne je cez portal.gov.sk možno elektronicky komunikovať so ZEP s týmito inštitúciami: Obchodný register SR Kataster nehnuteľností SR Úrad priemyselného vlastníctva SR Štatistický úrad SR Podmienkou je úspešná registrácia na portáli. Tá vyžaduje niekoľko krokov: 1. Vytvorenie konta na portal.gov.sk. 2. Vyplnenie, podpísanie a odoslanie žiadosti o registráciu certifikátu. 3. Získanie potvrdenia o registrácii, ktoré bude odoslané do schránky nového konta na portáli. 4. Návšteva notára, overenie osobných údajov a spísanie notárskej zápisnice. 5. Doručenie zápisnice na pracovisko ÚPVS. 6. Potvrdenie registrácie pracovníkom ÚPVS, ktoré bude odoslané do schránky konta na portáli. 3.6 Začiatok používania Pri prevzatí prostriedkov pre zaručený elektronický podpis sme obdržali aj inštrukcie pre začiatok používania. Po dohode so spoločnosťou Disig a.s. ich v cenzurovanej 1 podobe uvádzame na obrázku 5. Inštrukcie obsahujú niekoľko nedostatkov, ktoré majú zásadný dopad na bezpečnosť celkového riešenia. Inštrukcie sú vágne a kontrastujú s úrovňou bezpečnosti v oblastiach, ktoré ošetruje zákon. V inštrukciách je od užívateľa žiadané, aby nainštaloval dva inštalačné súbory (Čítačka GEMC Twin USB resp. Usb Shell Token a Siemens CardOS API), koreňové certifikáty CA Disig a certifikát KCA NBÚ SR. 1 Odstránené sú predvolené autentifikačné údaje a kontakt na technickú podporu. 41

42 Obr. 5: Inštrukcie pre začiatok používania Inštrukcie začínajú nasledovne: Z web stránky spoločnosti Disig, a.s. je potrebné nainštalovať dva inštalačné súbory. Nájdete ich v tejto časti: časť Produkty, menu Podpora, podmenu Siemens HiPathSicurity. Webové prehliadače po zadaní webovej adresy v bežnej forme, bez špecifikácie protokolu, štandardne používajú protokol HTTP (ukážku uvádzame na obrázku 6). Http je jednoduchý textový protokol pre prenos dokumentov medzi klientom a serverom internetovej služby www. Protokol HTTP ako taký nie je šifrovaný. Pre zabezpečenie http komunikácie sa používa nadstavba označovaná HTTPS. Táto nadstavba obaľuje protokol HTTP do protokolu SSL alebo TLS a vďaka tomu umožňuje jednak šifrovanie prenosu, ako aj overovanie identity servera pomocou PKI. V prípade že bude užívateľ postupovať podľa obdržaných inštrukcií, bude celá komunikácia prebiehať nezabezpečeným protokolom HTTP. Táto komunikácia je zraniteľná na útok typu MITM 2. Ani jeden z inštalačných balíkov stiahnutých cez nezabezpečené pripojenie nie je digitálne podpísaný a v inštrukciách nie je spomenutá žiadna možnosť overenia pravosti súborov. Pri inštalácii certifikátov systém užívateľa upozorňuje na ich nedôveryhodnosť, 2 Jednoduchý spôsob, ako sa dá táto zraniteľnosť zneužiť na inštaláciu podvrhnutého softvéru, ukážeme v ďalšej časti. 42

43 Obr. 6: Spojenie protokolom HTTP ako je vidieť na obrázku 7. Ich reťaz totiž nevedie ku žiadnemu z certifikátov, ktoré systém považuje za dôveryhodné. Certifikát certifikačnej autority Disig je podpísaný koreňovým certifikátom certifikačnej autority NBÚ SR. Koreňový certifikát NBÚ je podpísaný sebou samým. Po inštalácii týchto certifikátov ich bude operačný systém považovať za dôveryhodné. V situácii, do ktorej nás inštrukcie vedú, je však dôveryhodnosť certifikátov pochybná. Bežný užívateľ ich totiž rovnako ako inštalačné súbory získa nezabezpečenou cestou. Server poskytujúci webové stránky komunikuje aj zabezpečeným protokolom HTTPS. Použitý SSL certifikát je podpísaný koreňovým certifikátom certifikačnej autority Disig 3. Príslušný KC sa nachádza v zozname dôveryhodných CA vo väčšine rozšírených webových prehliadačov (Windows Internet Explorer, Mozilla Firefox, Google Chrome), aj keď nie vo všetkých (Opera). V prípade, že je užívateľ znalý a sám zvolí zabezpečenú verziu protokolu, bude komunikácia so serverom spoločnosti Disig šifrovaná, identita serveru overená a užívateľ chránený pred útokom typu MITM. Preto pokladáme za veľmi nešťastné, že užívatelia sú štandardne inštruovaní ku komunikácii pomocou nezabezpečeného spojenia. Server poskytujúci webové stránky ep.nbusr.sk zabezpečeným protokolom https nekomunikuje vôbec. To znamená, že užívateľ pri komunikácii s týmto serverom nemá možnosť ochrany pred útokom typy MITM. 3 Ide o iný certifikát ako ten, s ktorým sú vydávané kvalifikované certifikáty pre ZEP. 43

44 Obr. 7: Inštalované certifikáty 3.7 Útok Podvrhnutie inštalačných balíkov V tejto sekcii popíšeme jednoduchý spôsob, ako je možné vyššie popísanú chybu zneužiť na to, aby užívateľ do svojho systému nainštaloval podvrhnutý softvér. Uvažujme napríklad o nasledovnej situácii. Užívateľ Bob je pripojený v kaviarni pomocou bezdrôtového pripojenia poskytovaného zákazníkom kaviarne. Sieťové nastavenie bolo vykonané pomocou DHCP. Aktuálna IP adresa je nastavená na , DNS server je Útočník Mallory sa nachádza v dosahu rovnakej bezdrôtovej siete a je v nej pripojený. Jeho IP adresa je V počítači má nainštalovaný softvérový balík dsniff [13] a (ľubovoľný) webový server. V prípravnej fáze nastavil Mallory webový server tak, aby poskytoval modifikovanú verziu stránok Modifikácia spočíva v jedinej zmene a to v zmene inštalačného balíku. Mallory začne do siete zasielať také sfalšované ARP odpovede, ktoré zabezpečia, že sa k nemu dostanú pakety smerujúce na adresu DNS serveru. To dosiahne pomocou nástroju arpspoof. Nakoniec bude na požiadavky smerované DNS serveru odpovedať falošnými odpoveďami, ktoré preložia na IP adresu To dosiahne pomocou nástroju dnsspoof. Bob vo svojom systéme zadá do webového prehliadaču adresu a zobrazí sa mu stránka. Podľa inštrukcií sa cez sekcie Produkty, Podpora, Siemens HiPathSicurity dostane k inštalačnému súboru, ktorý zo stránky stiahne a pod 44

45 účtom administrátora vykoná jeho inštaláciu do systému. Bob však v skutočnosti nekomunikoval so skutočným serverom spoločnosti Disig a.s., ale s webovým serverom nainštalovaným na počítači útočníka. Inštalačný súbor ktorý užívateľ nainštaloval bol modifikovaný a okrem pôvodnej funkcionality do systému nainštaloval škodlivý kód, pomocou ktorého bude mať Mallory v budúcnosti kontrolou nad Bobovým počítačom Podvrhnutie certifikátu koreňovej certifikačnej autority Teraz popíšeme modelový príklad, v ktorom bude vyššie spomínaná zraniteľnosť zneužitá na inštaláciu podvrhnutého certifikátu certifikačnej autority medzi dôveryhodné CA. Dovoľujeme si tvrdiť, že priemerný používateľ si v takejto situácii nedokáže uvedomiť, že sa stal obeťou úspešného útoku. Môžeme uvažovať o rovnakej sieťovej konfigurácii a v princípe rovnakom prevedení MITM útoku uvedenom v predošlej časti. V tomto prípade Bob podľa inštrukcií inštaluje certifikát koreňovej certifikačnej autority NBÚ - KCA3. Pomocou webového prehliadača načíta príslušnú stránku a klikne na odkaz Koreňovej Certifikačnej Autority NBÚ - KCA3, ktorá smeruje na adresu Mallory miesto skutočného certifikátu KCA3 sprístupnil Bobovi certifikát vlastnej certifikačnej autority MCA. V tejto chvíli bude chcieť Bob vyskúšať základné operácie v užívateľskej aplikácii pre ZEP aby zistil, či sa inštalácia podarila. Pri prvom pokuse o overenie podpiísaného dokumentu zistí, že niečo nie je v poriadku. Overenie sa nepodarí, pretože certifikačná cesta nie je platná. Na vrchole certifikačnej cesty overovaného podpisu je totiž certifikát KCA3, ktorý v systéme nie je nainštalovaný. Bob je bežný používateľ s priemernými znalosťami informačných technológií a súdiac, že počas inštalácie nastala chyba, ju zopakuje. Pri opakovaní postupu už Mallory druhý krát nepodvrhne MCA miesto KCA3 a teda Bob si konečne úspešne stiahne a nainštaluje skutočný certifikát KCA3. Bob v rámci testu znovu vyskúša overiť podpis. Tentokrát je overenie pozitívne, pretože na vrchole cesty je úspešne nainštalovaný KCA3. V tejto chvíli Bobov systém dôveruje KCA3, ale aj MCA. Mallory v ďalšom kroku zneužije získanú dôveru vo falošnú CA pri MITM útoku na internet banking a tým získa Bobove peniaze. Tieto scenáre sú iba ukážkami a skutočné prevedenie útoku môže mať mnoho iných podôb. 45

46 3.7.3 Riešenie Popísané bezpečnostné nedostatky je možné odstrániť niekoľkými opatreniami. Všetky navrhované opatrenia sú triviálne a keďže ošetrujú rôzne nedostatky, odporúčame nasadiť kombináciu všetkých navrhovaných opatrení. NBÚ by mal sprístupniť svoje webové sídlo aj cez protokol HTTPS a použiť komerčný SSL EV certifikát. Užívateľ by mal od RA získať kópie potrebných inštalačných súborov a certifikátov už pri osobnej návšteve RA vrámci získavania prostriedkov pre ZEP. RA by mala umiestniť hodnoty haš odtlačkov (z rodiny SHA2) inštalačných súborov a potrebných certifikátov do dokumentu s inštrukciami pre začiatok používania, ktorý dostáva klient na papieri. Súčasťou by mal byť tiež jednoduchý návod na overenie haš hodnôt. RA by mala pozmeniť inštrukcie, aby užívateľa vyzývali na návštevu stránky RA cez zabezpečený protokol HTTPS. Zapojené strany by mali pozmeniť konfigurácie relevantných webových serverov (NBÚ, RA) tak, aby vykonávali automatické presmerovanie na zabezpečený protokol HTTPS prinajmenšom v sekciách, kde sa sťahujú inštalačné súbory a potrebné certifikáty Komunikácia s Disig a NBÚ Vo veci vyššie popisovaných nedostatkov sme kontaktovali spoločnosť Disig a.s. a NBÚ SR. Zo spoločnosti Disig a.s. sme dostali odpoveď, že viacerými z položených otázok sa už dávnejšie zaoberali a snažili sa nájsť vhodný pomer medzi bezpečnosťou a použiteľnosťou z pohľadu väčšinového zákazníka. V minulosti bolo zvykom zákazníkom spolu s SSCD zariadeniami odovzdávať aj potlačené inštalačné CD s ovládačmi, toto riešenie sa však neosvedčilo, nakoľko dochádzalo k častým stratám nosičov a zákazníkom museli byť opätovne sprístupnené potrebné súbory. Čo sa týka certifikátu Koreňovej Certifikačnej Autority NBÚ - KCA3, na stánke spoločnosti je iba odkaz na stránky NBU, odkiaľ si klienti tento certifikát môžu nainštalovať. Čo sa týka možnosti prístupu na www stránky spoločnosti Disig pomocou protokolu HTTPS, táto voľba je aktívna a pre vybrané podstránky, z ktorý užívatelia odosielajú svoje informácie smerom do spoločnosti, je vynútené automatické presmerovanie na HTTPS. Spoločnosť nevidí dôvod vynúteného prístupu k sekcii download cez HTTPS, pretože výrobca sám sprístupňuje referenčné inštalačné súbory iba cez HTTP a bez hašov a väčšina pokročilých užívateľov uprednostňuje inštalačné súbory priamo od výrobcu. Spoločnosť 46

47 na požiadanie stále umožňujeme klientom získať kópie potrebných inštalačných súborov a certifikátov už pri osobnej návšteve RA v rámci získavania prostriedkov pre ZEP na ich prenosné médium, avšak už automaticky nedáva inštalačné CD. Disig zváži ponúkanie inštalačného CD za príplatok a umiestnenie hodnôt haš odtlačkov (z rodiny SHA2) inštalačných súborov a potrebných certifikátov do dokumentu s inštrukciami pre začiatok používania. Spoločnosť pripomenula, že tento dokument vznikol ako výsledok ohlasu od klientov, ktorí požadovali veľmi jednoduchý návod, ako čo najrýchlejšie sprevádzkovať zariadenia pre ZEP. Národný bezpečnostný úrad sme oslovili so žiadosťou o sprístupnenie informácií na základe zákona číslo 211/2000. Z odpovede vyplýva, že certifikát verejného kľúča KCA3 bol v zmysle 12 ods. 2 vyhlášky NBÚ č. 135/2009 Z. z. [11] zverejnený v tlači, konkrétne Hospodárske noviny z dňa 19. novembra 2009, na 4. strane a Verejná správa, číslo 25-26/2009, na 45. strane a žiadnej inej. K zverejneniu certifikátu verejného kľúča teda došlo iba v tlači z roku 2009 (ktorá v súčasnosti nie je ľahko dostupná) a na webovej stránke úradu (ktorá je dostupná iba cez protokol http, náchylný na útoky typu MITM). Z odpovede na otázku Považuje NBÚ SR takéto zverejnenie z hľadiska bezpečnosti za dostatočné? vyplýva, že Národný bezpečnostný úrad takéto zverejnenie považuje z bezpečnostného hľadiska za dostatočné. Odpoveď v plnom znení uvádzame v prílohe B. Popisované bezpečnostné nedostatky kontrastujú s bezpečnostnou latkou, ktorú legislatíva v niektorých bodoch nasadila (napr. režim povinnej certifikácie produktov pre ZEP). Je škoda, že sa niektoré veci nedotiahli do konca a tým reálne zvyšujú riziko. V súvislosti so známym reťaz je tak slabá, ako jej najslabšie ohnivko si myslíme, že poskytovateľ certifikačných služieb má morálnu zodpovednosť za to, aby slabé ohnivká maximálne eliminoval. Na Slovensku zatiaľ nebol medializovaný žiaden podvodov so ZEP, ale také podvody sú nepochybne iba otázkou času. 3.8 Principiálna bezpečnosť ZEP Aktuálny legislatívny stav a jeho dopady na bezpečnosť Zaručený elektronický podpis má niekoľko principiálnych problémov. Podľa 4 zákonu č. 215/2002 Z.z. [2] je zaručený elektronický podpis špecifický prípad elektronického podpisu, ktorý spĺňa okrem iných nasledovné podmienky: b) možno ho vyhotoviť len s použitím bezpečného zariadenia na vyhotovovanie elektronického podpisu podľa 2 písm. h), 47

48 c) spôsob jeho vyhotovovania umožňuje spoľahlivo určiť, ktorá fyzická osoba zaručený elektronický podpis vyhotovila, V tejto časti zhrnieme principiálne problémy, týchto požiadaviek. Podmienka o vyhotovení len s použitím bezpečného zariadenia na vyhotovovanie elektronického podpisu núti užívateľa použiť také hardvérové a softvérové vybavenie, ktoré získalo certifikát bezpečného produktu pre zaručený elektronický podpis. V prípade softvérového vybavenia dodržanie tejto podmienky nie je overiteľné. Uvažujme o necertifikovanej implementácii softvéru na vytváranie elektronického podpisu (keďže aplikácia nie je certifikovaná, nevytvára ZEP, ale len EP). Aplikácia bude komunikovať so zariadením SSCD, ktoré má v sebe kvalifikovaný certifikát a dokáže vytvárať digitálny podpis. Táto aplikácia vie podpísané dokumenty uložiť do obálky, ktorá spĺňa predpísaný formát, napríklad CAdES, rovnakým spôsobom, ako to robí certifikovaná aplikácia. Necertifikovaná aplikácia vie teda vytvárať také podpísané dokumenty, ktoré sú identické s podpísanými dokumentami vytvorenými certifikovanou aplikáciou. Cieľová strana, ktorá takto podpísané dokumenty overuje, nedokáže zistiť, či bol na vytvorenie podpisu použitý certifikovaný, alebo necertifikovaný produkt. V jednom z možných prípadov bol porušený zákon, a teda podpis je iba EP, nie ZEP, avšak na základe výstupných súborov, ktoré sú identické, nie je možné zistiť ktorý prípad nastal 4. Tento príklad núti človeka k zamysleniu, či má takáto neoveriteľná podmienka význam. Samotná certifikácia softvérových produktov so sebou nesie niekoľko problémov. Pri certifikácii produktov sa posudzujú aj knižnice, ktoré aplikácia používa. Tieto knižnice sú však v mnohých prípadoch dynamicky načítavané a v rôznych verziách systému sa menia. Certifikát, ktorý aplikácia dostáva, obsahuje haš hodnotu inštalačného balíku konkrétnej verzie softvéru, ktorá certifikát získala. Počas behu aplikácie sa však vykonáva aj kód knižníc, ktoré nepochádzajú z inštalačného balíku. Certifikát v skutočnosti platí iba na podmnožinu kódu aplikácie. Režim povinnej certifikácie do pravidiel používania ZEP prináša významné bezpečnostné riziko. Predstavme si situáciu, kedy útočník objaví v certifikovanej aplikácii pre vytváranie a overovanie ZEP bezpečnostnú dieru. Diera spočíva v tom, že s použitím špeciálne pripraveného dokumentu sa aplikácia pri jeho overovaní dostane do neštandardného stavu, ktorý vyústi do vykonávania podvrhnutého strojového kódu. Táto chyba sa následne začne masívne zneužívať. Tvorca softvéru chybu identifikuje a odstráni. Aby mohli opravenú verziu aplikácie používať užívatelia, musí prejsť opravená verzia celým procesom certifikácie. Počas doby od odhalenia bezpečnostnej diery po vydanie certifikátu na opravenú verziu majú užívatelia na výber dve zlé možnosti. Buď budú používať deravú aplikáciu a vystavovať sa tým riziku, že sa stanú obeťou 4 S pomocou súborového systému, ktorý má podporu deduplikácie dát, je dokonca možné dosiahnuť takú komickú situáciu, v ktorej časť dát zároveň je aj nie je ZEP 48

49 rozšíreného útoku, alebo počas tejto doby nebudú ZEP používať. Podmienku o spoľahlivom určení osoby, ktorá zaručený elektronický podpis vyhotovila, nie je prakticky splniteľná. Existencia dokumentu s platným digitálnym podpisom nemusí nutne znamenať vôľu vlastníka podpisu tento dokument podpísať. Tento problém podrobne popísali Jaroslav Janaček a Richard Ostertag v [25] Zhoda zobrazeného s podpisovaným Dôležitou požiadavkou je vlastnosť WYSIWYS. V tejto časti na niekoľkých príkladoch ukážeme, že zaručenie toho, že podpisovaný obsah je zhodný s obsahom zobrazeným, nie je ľahká úloha a zároveň to, že existencia podpisu dokumentu nemusí znamenať vôľu podpis daného dokumentu vykonať Výhradne softvérové riešenie na nededikovanom systéme Uvažujme o prípade, kedy užívateľ nemá žiadne špecializované hardvérové zariadenie na vytváranie elektronického podpisu. Na jeho vytváranie používa štandardný počítač s bežným operačným systémom, rôznym programovým vybavením a aktívnym pripojením na internet. Privátny kľúč je chránený heslom a uložený na bežnom pamäťovom médiu, napríklad na USB kľúči. Popisovaný prípad je realitou v Českej Republike. Keď chce užívateľ podpísať dokument, musí si ho najskôr prečítať. Na to použije prehliadač, ktorý mu daný dokument zobrazí. Prehliadač však v niektorých prípadoch nemusí zobraziť všetok obsah. Niektoré časti môžu ostať skryté v závislosti od nastavenia. Z toho dôvodu je bezpečnejšie podpisovať iba jednoduché dokumenty, napríklad čistý text, pri ktorých takáto situácia nemôže nastať. Pri zložitejších dokumentoch musí byť jasne definované čo sa zobrazí a že sa zobrazí vždy to isté. Po prečítaní dokumentu užívateľ použije podpisovaciu aplikáciu na vytvorenie podpisu pre daný dokument. Tá si z média prečíta súbor s zašifrovaným privátnym kľúčom, užívateľ zadá heslo s ktorým aplikácia privátny kľúč rozšifruje a použije ho na vypočítanie podpisu. Teraz aplikácia vie privátny kľúč a mohla by bez vedomia užívateľa podpísať aj iné dokumenty. Aj v prípade, že tvorca aplikácie takéto nekalé funkcie do aplikácie nezakomponoval, nie je vylúčené, že niekto aplikáciu modifikoval. Nemožno tiež vylúčiť prítomnosť aplikačnej chyby, ktorá je zneužiteľná na to, aby sa aplikácia správala nekalým spôsobom. V tomto prípade uvažujeme o nededikovanom systéme. Môže si byť užívateľ istý, že niekto do aplikácie, alebo systému nenainštaloval škodlivý kód? Ak má k systému fyzický prístup niekto iný, alebo je systém pripojený k 49

50 internetu, prítomnosť škodlivého kódu nie je možné vylúčiť. V dnešnej dobe je softvér natoľko komplexný, že odhalenie takejto modifikácie nie je jednoduchou úlohou ani pre experta v danej oblasti. Keď uvážime, aké sofistikované cielené útoky používali útočníci v minulosti, získame predstavu, že bežný užívateľ prakticky nedokáže rozlíšiť, či je jeho systém kompromitovaný. Z vyššie uvedeného je zrejmé, že používanie čisto softvérového riešenia na nededikovanom systéme je veľmi nerozumné, pretože so sebou prináša riziko absolútnej kompromitácie, ktorá môže byť úplne skrytá až do prejavu následkov útoku. Jedinou výhodou takéhoto riešenia je jeho nízka cena Použitie hardvérového kryptografického modulu na nededikovanom systéme Ďalší možný prípad je taký, kedy užívateľ vlastní špecializované hardvérové zariadenie - kryptografický modul, pomocou ktorého vyvára elektronický podpis. Privátny kľúč je uložený na zariadení a nie je možné ho z neho prečítať. Pred neautorizovaným použitím je chránený heslom, alebo PINom. Tento modul je pripojený k bežnému nededikovanému systému. Popisovaný prípad je realitou v Slovenskej Republike. V tomto prípade je prvým problémom spôsob, akým sa zadávajú autorizačné údaje (PIN). V čase písania práce boli na Slovensku certifikované také SSCD produkty ([26], tabuľka A), ktoré nemali vlastné rozhranie pre zadanie autorizačných údajov a užívateľ ich zadáva pomocou počítača. Aj v tomto prípade môže byť systém modifikovaný. Škodlivý kód síce nedokáže získať privátny kľúč, ale môže odchytávať stlačené klávesy a získať autorizačné údaje. Kým je v počítači vložený kryptografický modul, dokáže s pomocou autorizačných údajov podpisovať ľubovoľné dokumenty bez vedomia užívateľa. Situácia by bola lepšia v prípade, že by mal modul vlastný vstup (klávesnicu) pre zadávanie autorizačných údajov a vyžadoval by autorizáciu pri každom podpisovaní. Ale aj v tomto prípade má útočník priestor pre to, aby podpísal ľubovoľný dokument. Situácia môže byť nasledovná. Užívateľ vloží kryptografický modul, prezrie si dokument, ktorý chce podpísať a následne zadá aplikácii príkaz na vytvorenie podpisu. Aplikácia požiadavku pošle modulu, ten si vyžiada PIN, užívateľ ho zadá, modul dokument podpíše a podpis odovzdá aplikácii. Aplikácia na vytváranie podpisu, alebo nejaká časť operačného systému, však môže byť modifikovaná takým spôsobom, že kryptografický modul dostal na podpísanie iný dokument ako ten, ktorý užívateľ videl na obrazovke a chcel podpísať. Užívateľ si to nemusí všimnúť, pretože softvér môže byť modifikovaný tak, že následná kontrola vytvoreného podpisu ukáže, že je všetko v poriadku. 50

51 Vidíme, že ani používanie hardvérového modulu, ktoré nevie zobrazovať podpisované dáta, neposkytuje dostatočnú bezpečnosť. Prípad, kedy sú autorizačné údaje zadávané priamo do modulu, je bezpečnejší, ale stále necháva útočníkovi priestor Použitie dedikovaného systému Najvyššiu bezpečnosť dosiahneme použitím systému, ktorý je dedikovaný iba na vytváranie elektronického podpisu. Takýto systém musí byť rozumne dôveryhodný a musí vykonávať celý proces od zobrazenia podpisovaného dokumentu, cez získanie autorizačných dát a dešifrovanie privátneho kľúču až po samotný výpočet podpisu. Modifikácia takéhoto systému útočníkom musí byť veľmi zložitá. V prípade, že je takto dedikovaným systémom bežný počítač, je potrebné, aby boli nainštalované iba minimálne a nevyhnutné softvérové prostriedky. Aby sa predišlo sieťovému útoku, internetové pripojenie musí byť odpojené, alebo aspoň obmedzené na nutné minimum. Aby sme zabezpečili, aby modifikáciu nemohol vykonať útočník s fyzickým prístupom, uložíme počítač do špeciálneho obalu. Takéto riešenie je zo spomínaných najbezpečnejšie, ale zároveň je najdrahšie. Variant, ktorý dbá aj na fyzickú bezpečnosť, môže byť rádovo drahší ako čisto softvérové riešenie Bezpečné a cenovo dostupné riešenie Nie je mysliteľné, aby bežní užívatelia vynakladali obrovské finančné prostriedky na dedikovaný systém popísaný vyššie. V tejto časti popíšeme riešenie, ktoré je rozumne bezpečné a zároveň cenovo dostupné. Užívateľ použije rovnaký počítačový systém, ako bežne používa a môže (ale nemusí) použiť hardvérový modul. Na účely vytvárania podpisu bude mať na CD špeciálnu kópiu operačného systému, ktorá bude obsahovať iba programové vybavenie nevyhnutné na svoj účel a bola vytvorená dôveryhodným tvorcom. Keď chce v tomto prípade užívateľ vytvoriť podpis, najprv odpojí všetky sieťové prvky, vypne štandardný operačný systém a zavedie systém z špeciálneho CD. V ňom vykoná potrebné operácie - otvorí a prezrie dokument, zadá autorizačné údaje, vytvorí podpis, uloží ho na pevný disk a následne špeciálny systém vypne, CD vyberie a spustí svoj štandardný operačný systém. Takéto riešenie žiaľ v súčasnosti neexistuje ako hotový produkt, ktorý by si mohli užívatelia zakúpiť a používať. V skutočnosti je aj tento relatívne bezpečný prípad náchylný na niektoré typy útokov. V rámci sofistikovaného sieťového útoku je napríklad možné upraviť tie časti kódu, ktoré sa spúšťajú ešte skôr ako operačný systém, teda BIOS, alebo jeho modernú náhradu UEFI. V tomto prípade existuje oveľa jednoduchší útok. Útočníkovi 51

52 s fyzickým prístupom stačí, aby špeciálne CD, ktorému užívateľ verí, vymenil za CD s modifikovanou verziou systému, ktorá obsahuje škodlivý kód. Tento kód môže kooperovať s kódom nainštalovaným v bežnom systéme. Najskôr sa počas práce s bežným systémom a pripojením na internet na disk uložia inštrukcie od útočníka. Tieto inštrukcie môžu obsahovať alternatívny dokument a príkaz na jeho podpísanie. Neskôr užívateľ spustí modifikovanú verziu špeciálneho systému a škodlivý kód spustený z CD na pevnom disku nájde inštrukcie od útočníka a alternatívny dokument, ktorý podpíše miesto dokumentu, ktorý chcel podpísať užívateľ. Toto riziko je možné znížiť použitím podpísaním média so špecializovaným systémom v dobe, kedy je možné veriť, že obsah nie je modifikovaný. Teda napríklad pri preberaní od dôveryhodného dodávateľa. 3.9 Problémy štandardov Súčasným problémom v používaní ZEP je aj nemožnosť komunikovať so štátnou správou otvorenými textovými formátmi. Podľa 19 výnosu Ministerstva financií Slovenskej republiky o štandardoch pre informačné systémy verejnej správy [48] je štandardom pre textové súbory prijímanie a čítanie všetkých doručených formátov textových súborov, ktorými sú Rich Text Format (.rtf), Hypertext Markup Language (.html,.htm) alebo Extensible Hypertext Markup Language (.xhtml) podľa World Wide Web Consortium (W3C), Portable Document Format (.pdf) minimálne vo verzii 1.3 a maximálne vo verzii 1.5, Open Document Format (.odt) maximálne vo verzii 1.2, Text Format (.txt) v kódovaní UTF-8, Koncepcia využívania softvérových produktov vo verejnej správe [49] v bode podpora otvorených štandardov hovorí, že služby verejnej správy by podľa najlepších praktík mali poskytovať prístup na základe otvorených štandardov. Predovšetkým by nikdy nemali vyžadovať od verejnej správy nákup alebo využitie systémov od špecifických dodávateľov pre prístup k verejným službám, pretože toto by znamenalo neprípustné štátom podporované budovanie monopolistického postavenia vybraných dodávateľov. Najlepšia prax pri obstarávaní softvéru pre verejnú správu predstavuje použitie otvorených štandardov. Vyhláška úradu o spôsobe a postupe používania elektronického podpisu v obchodnom a administratívnom styku v prílohe 3 definuje nasledovné formáty elektronických dokumentov: 52

53 ASCII v niektorom z kódovaní znakov podľa ISO. Microsoft/Apple Rich Text Format (RTF) Verzia 1.5. Adobe Portable Document Format (PDF) Verzia 1.3. Adobe Portable Document Format (PDF) Verzia 1.4. HTML XML 1.0. XHTML 1.0. XHTML 1.1. Open Office. org XML File Format. Secure Hyper Text Transfer Protocol. S/MIME Verzia 3. Formát je definovaný v zahraničnej norme. Security Services for S/MIME. Tag Image File Format for image technology (TIFF). Portable Network Graphics (PNG). V praxi ale štátna správa používa proprietárne formáty. V styku, kde sa používa ZEP argumentuje tým, že neexistuje certifikovaná aplikácia, ktorá by dokázala podpisovať otvorené formáty. Na druhú stranu štátna správa používa neštandardný formát 602XML, v ktorom sú na ústrednom portále verejnej správy uložené elektronické formuláre. S týmto formátom sa dokonca ako s jediným formátom elektronických formulárov počíta v projekte centrálnej elektronickej podateľne [51]. Je dôležité poukázať na fakt, že formát 602XML nie je štandardom. Ide o proprietárny formát, ku ktorému nebola zverejnená kompletná dokumentácia. Zverejnené popisy tohoto formátu nie sú dostatočné na vytvorenie aplikácie so zhodnou vizualizáciou formulárov, akú dosahuje proprietárna aplikácia. Tento formát napriek deklaráciám nedodržiava štandard XSL-FO. Nikdy neprešiel revíziou a preto nie je možné vylúčiť, že obsahuje potenciálne nežiadúce prvky. Zmeny tohoto formátu prebiehajú na základe ľubovôle súkromnej spoločnosti Software602. Certifikáciou softvéru, ktorý podpisuje 602XML a jeho používaním v štátnej správe formát v podstate získal neoprávnenú legitimitu a to aj napriek tomu, že je v rozpore s výnosom o štandardoch pre informačné systémy verejnej správy. 53

54 3.10 Certifikované produkty Certifikácia produktu pre elektronický podpis je proces v ktorom sa posudzuje súlad technických zariadení a procedúr na vyhotovovanie a overovanie zaručených elektronických podpisov, časových pečiatok a iných produktov pre elektronický podpis s bezpečnostnými požiadavkami stanovenými právnymi predpismi Slovenskej republiky, štandardami a smernicami Národného bezpečnostného úradu a medzinárodnými normami a štandardmi. Certifikáciu vykonáva v zmysle zákona [2] úrad na základe žiadosti o certifikáciu produktu pre ZEP. Ak žiadosť spĺňa potrebné náležitosti, procesom certifikácie sa zaoberá sekcia informačnej bezpečnosti a elektronického podpisu (SIBEP). Úrad nemá akreditované skúšobné laboratórium a pre potreby certifikácie je potrebné predložiť bezpečnostné certifikáty od laboratórií, alebo atestačných stredísk úradom uznaných inštitúcií, alebo uistenie tretej strany, čiže dodaním záverečnej správy bezpečnostného auditu, vyhotovené nezávislým audítorom s výrokom o splnení bezpečnostných požiadaviek. Na základe týchto údajov úrad do 90 dní rozhodne o tom, či je produkt je, alebo nie je v súlade s požiadavkami. V prípade kladného posúdenia produkt získa certifikát bezpečného produktu pre ZEP a bude automaticky doplnený do zoznamu certifikovaných bezpečných produktov na webovej stránke úradu [26]. Všetky produkty, ktoré mali v dobe písania práce platný certifikát, prešli bezpečnostným auditom komerčných bezpečnostných firiem. Certifikované produkty určené pre užívateľov ZEP sú hardvérové a softvérové. Hardvérové sú SSCD (Secure Signature Creation Device), teda zariadenia, na ktorých je uložený súkromný kľúč a ktoré vytvárajú digitálny podpis. Softvrové sú SCVA (Signature Creation & Verification Application), SCA (Signature Creation Application) a SVA (Signature Verification Application), teda aplikácie, ktoré zaručený elektronický podpis vytvárajú (SCA), overujú (SVA), alebo ho vedia vytvárať a zároveň overovať (SCVA) Hardvérové produkty Zoznam certifikovaných hardvérových produktov je uvedený na webovej stránke úradu [26] v tabuľke A. Pre účely tejto práce sme získali a používali produkt Siemens HiPath SIcurity Smart Card 32KB, verzia SLE66CX322P. Ide o čipovú kartu s veľkosťou bežnej SIM karty, na ktorej čipe beží operačný systém CardOS V4.3. Na komunikáciu s počítačom je nevyhnutná čítačka smart kariet. V našom prípade sme používali čítačku Gemalto Usb Shell Token V2 vyobrazenú na obrázku 8. Čítačka je produkt, na ktorý sa nevzťahuje povinnosť certifikácie. Figuruje iba ako rozhranie medzi počítačom a smart kartou. 54

55 Obr. 8: Gemalto USB Shell Token V Softvérové produkty Zoznam certifikovaných hardvérových produktov je uvedený na webovej stránke úradu [26] v tabuľke B. V tabuľke boli v čase písania práce tri softvérové produkty v rôznych verziách. Pre účely tejto práce sme získali a používali produkt QSign vo verzii 4.0 s licenciou QSign personal. Aplikáciu ICASignZEP vyvinula česká spoločnosť První certifikační autorita, a.s., bezpečnostný audit vykonala spoločnosť VaF, s.r.o., RNDr. Jozef Vyskoč, Ph.D. a certifikát bol udelený Aplikácia je typu SCA a podporuje formáty RTF a TXT. Umožňuje pracovať aj s formátmi DOC a DOCX takým spôsobom, že ich pred podpísaním skonvertuje a uloží do formátu RTF. ICASignZEP nie je samostatná aplikácia. Je to dynamicky načítavateľná knižnica pre operačné systémy Windows. Podporuje podpisové formáty CAdES-EPES a CAdES-EPES-T. Až do doby odovzdania práce sa nám k tomuto produktu nepodarilo získať iné informácie ako tie, ktoré sú uvedené na webovej stránke úradu. Rovnako sa nám nepodarilo získať samotnú aplikáciu. Rodinu softvérových produktov D.Signer vyvinula spoločnosť Ditec, a.s., bezpečnostný audit vykonala spoločnosť KPMG Slovensko, s.r.o. Hlavnou aplikáciou rodiny je D.Signer/XAdES. Podpora dokumentových formátov závisí od inštalovaných pluginov. V súčasnosti sú certifikované pluginy pre prácu s formátmi XML, PDF a FO. Podporovaný podpisový formát je XAdES-EPES. Inštalačné balíky sú digitálne podpísané a tým chránené pred podsunutím modifikovanej verzie. Táto aplikácia nie je samostatnou aplikáciou. Ide o webového klienta, ktorý sa vyvoláva na webovej stránke ako ActiveX komponent. To obmedzuje jeho použitie len na internetový prehliadač Internet Explorer. Sa slovensku sa aplikácia používa na portáli DR SR na podávanie daňových priznaní. V rámci práce sa nám k nej z dôvodu procesných prekážok nepodarilo získať aktívny prístup. Aplikáciu QSign vyvinula spoločnosť Ardaco, a.s., bezpečnostný audit vykonala spoločnosť THE-M, s.r.o. Ide o jedinú samostatnú a zároveň najkomplexnejšiu aplikáciu. Inštalačný balík nie je digitálne podpísaný a teda nie je chránený pred podsunutím modifikovanej verzie. Webová stránka spoločnosti Ardaco, z ktorej je možné inštalačný balík stiahnuť, je prístupná zabezpečeným protokolom HTTPS, ale jeho použitie nie je povinné. V najnovšej certifikovanej verzii, ktorou bola v čase 55

56 písania práce verzie 4.0, je podpora dokumentových formátov TXT, RTF, PDF, PDF/A-1, XML, 602XML, TIFF, PNG. Aplikácia umožňuje pracovať aj s dokumentom formátu DOC a to takým spôsobom, že tento formát skonvertuje do formátu RTF, ktorý následne podpíše. Podobne dovoľuje pracovať s grafickými formátmi GIF, JPG a BMP, ktoré najskôr skonvertuje do formátu PNG, ktorý po konverzii podpíše. Podporované podpisové formáty sú CAdES-EPES, CAdES-EPES-T, CAdES-EPES- C-X, CAdES-EPES-A, XAdES-EPES, XAdES-EPES-T, XAdES-EPES-C-X, XAdES- EPES-A. Aplikácia QSign má tri rôzne druhy licencií [16]: Licencia na overovanie je poskytovaná zdarma a je voľne šíriteľná. Umožňuje overovanie zaručených elektronických podpisov a overovanie obyčajných elektronických podpisov. Licencia neumožňuje vytvorenie ZEP. Licencia QSign Personal komerčná licencia, ktorá umožňuje plnú funkcionalitu aplikácie QSign vrátanie podpisovania ZEP. Licencia je naviazaná na kvalifikovaný certifikát. To znamená, že aplikácia umožní vytvorenie ZEP iba po prihlásení kvalifikovaným certifikátom, ktorý je aktivovaný touto licenciou. Po prihlásení sa certifikátom, ktorý nie je aktivovaný, aplikácia neumožní vytvorenie ZEP. Licencia sa nahráva priamo na bezpečné zariadenie s kvalifikovaným certifikátom, a preto je zároveň použiteľná na ktoromkoľvek počítači, na ktorom je nainštalovaná aplikácia QSign a vyhovuje systémovým požiadavkám. Stačí mať už len zariadenie s uloženou aktiváciou tejto licencie. Licencia QSign Office komerčná licencia, ktorá umožňuje plnú funkcionalitu aplikácie QSign vrátane podpisavania ZEP. Licencia je naviazaná na inštaláciu na danom počítači (licencia sa nahráva priamo do počítača), a preto ju možno použiť len na tom konkrétnom počítači, kde bola aktivácia vykonaná. To znamená, že umožní vytvorenie ZEP po prihlásení sa ľubovoľným kvalifikovaným certifikátom. Pre účely tejto práce sme získali komerčnú licenciu QSign Personal. Aplikáciu sme nainštalovali na 64 bitovú verziu operačného systému Windows 7 Professional. Inštalácia bola jednoduchá a nehlásila žiadne chybové stavy. Oproti deklarovaným vlastnostiam chýbala možnosť vykonávať operácie podpisovania a overovania súborov z kontextového menu prieskumníka. Tento nedostatok sme bližšie neskúmali, ale dá sa predpokladať, že je spôsobený rozdielnou štruktúrou alebo interpretáciou relevantných častí databázy windows registrov. Aplikácia sa okrem kontextového menu prieskumníka ovláda cez ovládaciu ponuku vyvolanú kliknutím na ikonu aplikácie v lište system tray. Ako vidieť na obrázku 9, menu je jednoduché a prehľadné. Aplikácia používa koncept prihlásenia. V tomto kontexte to znamená, že používateľ v aplikácii zvolí SSCD zariadenie a certifikát, ktorým sa bude podpisovať. Prihlásenie je nutné na podpisovanie elektronických dokumentov a z toho dôvodu 56

57 Obr. 9: Hlavné menu aplikácie QSign sa menu voľba podpisovanie aktivuje až po ňom. Ukážka podpisovacieho dialógu je na obrázku 10. Pri samotnom podpisovaní užívateľ najskôr zvolí súbor, ktorý chce podpísať. Aplikácia mu zobrazí jeho náhľad. Užívateľ musí explicitne vyjadriť svoj súhlas s podpisovaným obsahom. Po potvrdení zadá autorizačné údaje PIN a Sec Auth PIN, po čom sa vytvorí samotný podpis. Na vykonanie potrebných operácií je pritom nutný iba Sec Auth PIN. Túto dôležitú informáciu sme nadobudli pri komunikácii so smart kartou z prostredia našej aplikácie. Pri operáciách, ktoré vyžadujú overenie certifikačnej cesty (overovanie dokumentu, prihlásenie), sa QSign užívateľa pýta na dôveryhodnosť KCA (Obrázok 11). Predpokladáme, že táto otázka má slúžiť ako bezpečnostný prvok. Súhlasíme s tým, že explicitné vyjadrenie dôvery v koreňovú certifikačnú autoritu môže mať z bezpečnostného hľadiska určitý význam. V súčasnej situácii ho ale považujeme minimálne za diskutabilný. Aplikácia v bežných podmienkach beží na nededikovanom systéme pripojenom do internetovej siete spolu s iným softvérovým vybavením tak, ako sme to popísali v časti Predpokladajme, že Mallory je schopný vykonávať ľubovoľný kód na Alicinom počítači. Alica overuje zmluvu podpísanú zaručeným elektronickým podpisom. Overovanú zmluvu Alici podsunul Mallory a podpísaná je falošným elektronickým podpisom. V prípade, že Mallory nainštaloval do systému falošný certifikát KCA a Alica si všimne rozdiel haš hodnoty, otázka ohľadom dôvery v KCA efektívne zabránila útoku. Mallory je však pripravený útočník a softvér QSign pozná. Preto Alici podstrčí jeho modifikovanú verziu, ktorá zobrazí miesto informácií z podvrhnutej KCA informácie správnej KCA. Navyše ak je Alica bežný užívateľ s priemerným vzdelaním v oblasti informačných technológií, pravdepodobne na opakujúcu sa otázku vždy inštinktívne zareaguje potvrdením dôvery bez kontroly hašu. 57

58 Obr. 10: Podpisovanie dokumentu v aplikácii QSign Obr. 11: Aplikácia QSign sa pýta na dôveryhodnosť KCA 58

59 4 Naša aplikácia V tejto časti navrhneme aplikáciu, ktorá bude schopná pracovať s elektronickým podpisom. Našim cieľom je dosiahnuť kompatibilitu s existujúcimi aplikáciami. V rámci prípravnej fázy diplomovej práce sme absolvovali stretnutie s odborníkmi spoločnosti Ditec a.s., ktorá vytvorila produkt DSigner. Zo stretnutia okrem iného vyplynulo, že realizácia plnohodnotnej aplikácie pre elektronický podpis, ktorá by mala potenciál získať certifikát NBÚ, počas doby vyhradenej na tvorbu diplomovej práce nie je reálna. Z tohoto dôvodu budeme našu aplikáciu navrhovať ako modulárnu a v rámci možností sa pokúsime zrealizovať ukážkové moduly niektorých častí. Dlhodobým cieľom je vytvorenie takej množiny aplikačných modulov, s ktorou výsledná aplikácia bude môcť získať certifikát NBÚ a tak sa stať plnohodnotnou aplikáciou pre tvorbu a overovanie zaručeného elektronického podpisu. Dosiahnutie tohoto cieľa je žiaľ nad rámec tejto práce. 4.1 Analýza Povedali sme, že v súčasnosti existujú tri certifikované aplikácie pre ZEP. Iba jedna z nich je plnohodnotná a samostatná užívateľská aplikácia. Ide o aplikáciu QSign. Za jej najväčšie funkčné nedostatky považujeme chýbajúcu podporu otvorených formátov a fakt, že funguje iba v prostredí operačného systému Windows. Z bezpečnostného hľadiska vidíme problém najmä v riziku útoku na operačný systém, alebo inštalovaný softvér. Tento problém sme bližšie popísali v časti V časti sme vysvetlili, prečo pokladáme za neužitočné pýtanie sa na dôveryhodnosť KCA pri každom overovaní certifikačnej cesty. Napriek tomu, že nejde o bezpečnostný, ale skôr kozmetický problém, sa pokúsime navrhnúť lepšiu alternatívu. Dôležitým bezpečnostným problémom je distribúcia aplikácie. Pri návrhu aplikácie musíme vychádzať najmä z vyhlášky úradu o produktoch elektronického podpisu [10]. Zameriame sa najskôr na 3, ktorý definuje požiadavky na produkty na vyhotovenie zaručeného elektronického podpisu. Podľa týchto požiadaviek vyhovuje produkt na vyhotovenie zaručeného elektronického podpisu určený pre podpisovateľa alebo overovateľa zaručeného elektronického podpisu požiadavkám zákona vtedy, keď a) pracujú so schválenými podpisovými schémami, algoritmami a parametrami týchto algoritmov, teda b) je preukázaná zhoda 1. so štandardom uvedeným v prílohe č. 1 prvom bode. Ide teda o dokument 59

60 ITU-T RECOMMENDATION X.509 (08/2005) ISO/IEC : Information technology - open systems interconnection - the directory: public key and attribute certificate frameworks [42], ktorý popisuje pravidlá používania X.509 a IETF RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [38], ktorý definuje formát CRL. V praxi to znamená, že je potrebné korektne narábať so súbormi v definovaných formátoch a korektne narábať s PKI, predovšetkým dôkladne implementovať overovanie certifikačnej cesty. 2. s kryptografickými štandardami infraštruktúry verejného kľúča uvedenými v prílohe č. 1 druhom bode, 3. s požiadavkami uvedenými v osobitnom predpise, 1) c) úrad pre ne vydal certifikát podľa 24 ods. 9 zákona. Táto požiadavka však v rámci tejto práce nemôže byť splnená z dôvodov, ktoré sme už spomenuli skôr. Zároveň chceme odstrániť nedostatky, ktoré existujú v existujúcich riešeniach. V rámci zabezpečenia princípu WYSIWYS sa pokúsime navrhnúť variant, ktorý bude cenovo dostupný a zároveň čo najviac bezpečný. Budeme myslieť na dôležitosť bezpečného spôsobu distribúcie aplikácie s ohľadom na súčasný reálny stav vo svete PKI. Pri voľbe programovacieho jazyku, ktorý je pre implementáciu najvhodnejší, sme zvažovali niekoľko požiadaviek. Od výslednej aplikácie požadujeme aby bola bezpečná, jednoducho rozšíriteľná, a nezávislá na architektúre počítača a operačnom systéme. Tieto podmienky veľmi dobre spĺňa programovací jazyk Java. Java je objektový programovací jazyk, ktorý núti programátora riešiť chybové situácie chytaním výnimiek. Programy bežia v chránenom režime virtuálneho stroja (JVM). Programy v tomto jazyku nie sú náchylné na bezpečnostné chyby typu pretečenie. Má veľmi dobrú spätnú kompatibilitu - programy napísané a skompilované do byte-kódu v prvej verzii jazyka idú aj po 15 rokoch rovnako správne v aktuálnych verziách. Navyše pri behu na nových verziách JVM je možné pozorovať v mnohých prípadoch zlepšenie rýchlosti bez zmeny pôvodného kódu. Aktuálne verzie JVM vedia napríklad počas behu programu dynamicky rekompilovať bajtkód na takú verziu strojového kódu, ktorý je v danej situácii rýchlejší. V prostredí jazyka Java existuje niekoľko rozhraní vykonávajúcich kryptografické operácie. Súhrnne ich označujeme Java Cryptography Architecture (JCA) a Java Cryptography Extension (JCE). Kryptografické rozhrania sú založené na volaní jednotlivých poskytovateľoch (v anglickej terminológii provider). Keď aplikácia posiela príkaz aplikačnému programovému rozhraniu (API), operácie sú v skutočnosti 60

61 posielané prednastaveným poskytovateľom na ich SPI. Pre naše účely budeme používať poskytovateľa pre štandard PKCS#11 [17], implementujúceho API zvané Cryptoki. To zabezpečuje komunikáciu so zariadeniami ako sú smart karty, alebo kryptografické akcelerátory. Javový Sun PKCS#11 provider na rozdiel od ostatných poskytovateľov neimplementuje kryptografické algoritmy sám, ale správa sa ako most medzi JCA a JCE API a natívnym PKCS#11 API. Jeho použitie v jave je zdokumentované v referenčnej príručke [18]. Aby bola aplikácia v budúcnosti jednoducho rozšíriteľná, navrhujeme modulárnu architektúru. Funkcionalita, ktorá umožňuje pridávať moduly do skompilovanej aplikácie, je výhodná pretože v takom prípade je možné certifikovať jednotlivé moduly. Na podobnom modulárnom princípe je postavená rodina D.Signer. Pre dosiahnutie základnej funkčnosti aplikácie je potrebné zabezpečiť: komunikáciu so zariadením SSCD podporu podpisového formátu podporu formátu dokumentu, ktorého sa podpis týka overovanie platnosti podpisu (certifikačnej cesty) užívateľské rozhranie Európska komisia pre štandardizáciu vydala štandard, ktorý stanovuje bezpečnostné požiadavky pre aplikáciu na tvorbu elektronického podpisu [43]. Z nich vyplýva rozdelenie modulov na dôveryhodné a aplikačne závislé komponenty (na obrázku 12). Dôveryhodné komponenty sú také, ktoré sú povinné a zabezpečujúce základnú požadovanú funkcionalitu SCA. Aplikačne závislé komponenty sú všetky ostatné a ich existencia, architektúra a funkcionalita závisí na aplikácii. Štandard stanovuje celú radu bezpečnostných požiadaviek na jednotlivé komponenty. Pri každom z nich uvádza hrozby a potrebné bezpečnostné opatrenia. 4.2 Návrh Aplikáciu potrebujeme navrhnúť vzhľadom na nedostatky existujúcich aplikácií vyplývajúcich z analýzy. Beh aplikácie na rôznych operačných systémoch je zabezpečený použitým programovacím jazykom. Interné moduly budú vystavané pomocou balíkov skompilovaných do výsledného jar súboru. Externé moduly bude možné dynamicky načítavať pomocou java reflection. K funkciám externých modulov budeme pristupovať pomocou brán. Na obrázkoch 13 a 14 sú schémy komponentov SCA a SVA. V skutočnosti ide o komponenty jednej SCVA. 61

62 CWA 14170:2004 (E) 5.3 Signature Creation Applications The primary parts of a Signature Creation Application for which this document specifies requirements are the set of trusted and application specific components that are shown in Figure 2. SCA Components Signature Creation Application Trusted SCA components Application Specific SCA components User Interface Signer s Document Presentation Component (SDP) Signature Attribute Viewer (SAV) Signer Interaction Component (SIC) Data To Be Signed Formatter (DTBSF) Signer s Document composer (SDC) Signed Data Object Composer (SDOC) Signature Logging Component (SLC) Others Signer Authentication Component (SAC) Signature- Creation Device (SCDev) Data Hashing Component (DHC) SCDev/SCA Communicator (SSC) Net Interface SSCD/SCA Interface (Trusted Path) SCDev/SCA Authenticator (SSA)* SCA Manager *Conditionally present 14 Figure 2 - SCA Components A Signature Creation Application contains trusted and application specific components: The trusted components are all mandatory if not marked otherwise and are relevant for every SCA; Note: DHC and SAC are always considered to be present in order to encourage compatibility of the SCA with the widest possible population of SCDevs. The application specific components are application context dependent, i.e. their presence, construction and functionality is application specific. The trusted SCA components are: Obr. 12: Rozdelenie komponentov SCA Ich oddelené vyobrazenie sme zvolili pre lepšiu prehľadnosť schém. SIC Signer Interaction Component - Komponent na interakciu so signatárom, pomocou ktorého signatár (užívateľ) interaguje s aplikáciou (SCA) a tým ovláda proces vytvárania podpisu. Cez tento komponent prebieha všetka komunikácia. Užívateľ pomocou neho volí podpisovaný dokument, atribúty podpisu a číta SDP SD Presentation Component used for presenting the SD that the signer selects by the Signer Interaction Component. The security requirements are specified in section 8; odpovede aplikácie. Výnimkou z komunikácie sú autentifikačné údaje, na ktoré je potrebný samostatný komponent (SCA). SAV - Signature Attributes Viewer used for viewing the Signature Attributes that the signer selects by the Signer Interaction Component and which will be signed together with the SD. The SAV shall include a capability to present the major components of the possibly application specific Signer's Certificate Content. The requirements are specified in section 9; DTBSF Data To Be Signed Formatter - Komponent na formátovanie dát, ktoré sa majú podpísať. Jeho úlohou je pripraviť správny formát, v ktorom sú DTBSF Data To Be Signed Formatter which formats and sequences the SD or a hash of it haš together dokumentu, with the Signature metadáta Attributes a atribúty and delivers podpisu. the result to the Data Hashing Component. The requirements are specified in section 12; DTBSF GATE Brána ku konkrétnym implementáciám DTBSF v moduloch. SIC - Signer Interaction Component through which the signer interacts with the SCA to control the signature creation process, and through which the SCA returns error and status messages to the Napr. príprava atribútov podľa podpisovej politiky. SDP Signer s Document Presentation Component - Komponent na vyobrazenie podpisovaného dokumentu, ktorý užívateľ zvolil v SIC. SAV Signature Attributes Viewer - Prehliadač atribútov podpisu slúži na 62

63 Dokument ZEP SIC SDP+SAV GATE DTBSF GATE SDC GATE SDOC GATE SAC DHC SSCD Obr. 13: Schéma komponentov našej SCA prehliadanie atribútov podpisu, ktoré užívateľ zvolil v SIC a ktoré budú podpísané spolu s dokumentom. SDP+SAV GATE Brána ku konkrétnym implementáciám SDP a SAV v jednotlivých moduloch. Napr. rtfviewer, pngviewer. DHC Data Hashing Component - Komponent na vytváranie hašov dát. V prípade, že proces hašovania robí SSCD, je tento komponent iba prestupnou stanicou dát. SDC Signer s Document Composer - Komponent na vytváranie podpisovaného dokumentu. Vo všeobecnosti môže ísť napríklad o textový editor. V našom prípade ide o komponent overujúci potrebné vlastnosti dokumentu (neprítomnosť aktívnych prvkov), alebo konvertor formátov, ktoré nie sú zákonom podporované, na zákonom podporované formáty. SDC GATE Brána ku konkrétnym implementáciám SDC v moduloch. Napr. docx2rtf, jpeg2png. SDOC a Signed Data Object Composer - z DTBSF berie naformátované dáta 63

64 a uloží ich do obálky príslušného formátu. SDOC GATE Brána ku konkrétnym implementáciám SDOC v moduloch. Napr. CAdES, XAdES. ZEP Výsleok overenia SIC SDP+SAV GATE SDD GATE SDOD GATE DHC SVC CPV Obr. 14: Schéma komponentov našej SVA SDOD a Signed Data Object Decomposer - dekompozícia obálky príslušného formátu na časti, ktoré je možné spracovať ďalšími komponentami. SDOD GATE Brána ku konkrétnym implementáciám SDOD. Napr. CAdES, PAdES. SDD Signer s Document Decomposer - Komponent overujúci potrebné vlastnosti dokumentu (neprítomnosť aktívnych prvkov). SDD GATE Brána ku konkrétnym implementáciám SDD. Napr. rtfverifier, svgverifier. CPV Certificate path validator - komponent overujúci platnosť certifikačnej cesty. Súčasťou je overovanie zrušených certifikátov po celej certifikačnej ceste. SVC Signature verification component - komponent, ktorý na základe výstupu z SDOD (hodnoty atribútov podpisu a ich korektnosť vzhľadom na podpisovú politiku), výstupu z CPV, a porovnania hašu z DHC a hašu vypočítaného z podpisu vyhodnotí platnosť podpisu. 64

65 Na zabezpečenie WYSIWYS použijeme riešenie načrtnuté v časti Na prácu s podpisom pripravíme špeciálnu verziu operačného systému, ktorá sa bude zavádzať z CD a bude obsahovať iba overené programové vybavenie nevyhnutné na prácu s podpisom. Vhodným základom pre takéto prostredie je projekt Knoppix [44]. Ide o operačný systém založený na OS Debian GNU/Linux. Je vytvorený tak, aby dokázal bežať priamo z CD (preto názov LiveCD) bez nutnosti inštalácie na pevný disk. Pre naše účely je potrebné systém modifikovať. Potrebujeme pridať našu aplikáciu a softvér, na ktorom závisí, a zároveň zredukovať prítomný softvér na nutné minimum. Na tento účel použijeme návod na modifikáciu OS Knoppix [45]. V modifikácii potrebujeme predovšetkým pridať prostredie pre beh Java programov (JRE) a softvérové prostriedky na prácu so smart kartami. V rámci redukovania softvéru na nutné minimum bude vytvorená redukovaná verzia grafického užívateľského rozhrania, ktorá bude umožňovať iba operácie súvisiace s vytváraním a overovaním elektronického podpisu. Spolu s aplikáciou nainštalujeme sadu certifikátov dôveryhodných certifikačných autorít pokrývajúcich zákonné požiadavky všetkých krajín Európskej únie. Zároveň pridáme certifikát vydavateľa modifikovanej verzie operačného systému. Po každom štarte bude systém kontaktovať server vydavateľa, odkiaľ stiahne informácie týkajúce sa dôležitých zmien, ktoré nastali od vzniku bežiacej verzie systému. Pôjde o aktualizácie certifikátov, podpisových politík, prípadne iných náležitostí súvisiacich so ZEP, alebo bezpečnostné aktualizácie systému, bezpečnostné upozornenia, odôvodnené odporúčania na získanie novej verzie a podobne. Všetky prevzaté metadáta a aktualizačné dáta budú podpísané a podpis sa bude overovať voči certifikátu vydavateľa systému. Aby sme zabezpečili, že útok na podvrhnutie falošnej verzie tohoto systému bude ťažký, zavedieme nasledovné ochranné mechanizmy. Podvrhnutiu falošného inštalačného média v MITM útoku pri sťahovaní zo serveru zabránime vynútením HTTPS pripojenia na celej webovej lokalite projektu. Na HTTPS použijeme EV SSL certifikát. Užívateľ bude na stránke projektu vyzvaný, aby získanú kópiu systému zapísal na CD-R médium, na ktoré je možný iba jednorázový zápis, nikdy nie na CD-RW médium, na ktoré je možné zapisovať opakovane. Ďalej by mal ihneď po zapísaní obsahu médium vlastnoručne podpísať. Navyše budeme cez registračné autority distribuovať kópie systému na lisovaných médiách obohatených o bezpečnostné prvky. Každý užívateľ bude vyzvaný, aby svoju kópiu bezprostredne po obdržaní vlastnoručne podpísal. Tento návrh považujeme za vhodný, pretože spĺňa podmienky pre separáciu komponentov popísané v [43], zároveň umožňuje rozširovanie funkcionality a odstraňuje niektoré bezpečnostné nedostatky, ktoré sme v práci popísali. 65

66 4.3 Implementácia Implementácia popisovaného návrhu jednou osobou za čas vyhradený na tvorbu diplomovej práce žiaľ pre komplexnosť riešenia nie je reálna. Rozhodli sme sa vytvoriť implementáciu aspoň niektorých modulov. V základnej funkcionalite sme vytvorili modul pre komunikáciu s SSCD zariadením a SDOC/SDOD modul pre podpisový formát CAdES. Implementácia prebiehala v prostredí operačného systému Ubuntu Maverick a vo vývojovom prostredí NetBeans. Na implementáciu sme použili knižnicu Bouncy Castle [46] Komunikácia so zariadením V rámci práce sme používali SSCD zariadenie Siemens HiPath SIcurity Smart Card, ku ktorému sme pristupovali pomocou čítačky Gemplus GemPC Key SmartCard Reader. Komunikovali sme pomocou štandardného API na prístup ku kryptografickému hardvéru PKCS#11 a pre prístup k údajom na karte pomocou štandardu PKCS#15. V softvéri je komunikácii implementovaná pomocou triedy SmartCard. Volania sú priamočiare a jednoduché. Avšak aby to bolo možné, bolo naskôr potrebné pripraviť potrebné súčasti systému. V prostredí OS Ubuntu bolo potrebné nainštalovať a nakonfigurovať niekoľko softvérových balíkov: coolkey - Smart Card PKCS #11 cryptographic module libccid - PC/SC driver for USB CCID smart card readers libopensc2 - Smart card library with support for PKCS#15 compatible smart cards opensc - Smart card utilities with support for PKCS#15 compatible cards pcsc-tools - Some tools to use with smart cards and PC/SC jeden z balíkov: openct - middleware framework for smart card terminals pcscd - Middleware to access a smart card using PC/SC (daemon side) Pričom z dvojce balíkov pcscd a openct sme nakoniec vybrali balík pcscd, pretože vychádza z novšieho projektu, ktorý je lepšie udržiavaný a má širšiu podporu zariadení. Pcscd má na starosti správu zdrojov a figuruje ako prostredník medzi smart kartou a aplikáciami. Na operačných systémoch založených na Debiane hľadá Java čítačky smart kariet pomocou knižnice uloženej v /usr/lib/libpcsclite.so. Tam sa 66

67 však knižnica nenachádza, preto je potrebné vytvoriť symbolický odkaz. Na Ubuntu (teda v našom prípade) ho treba smerovať na na /lib/libpcsclite.so.1 (sudo ln -s /lib/libpcsclite.so.1 /usr/lib/libpcsclite.so), kým na debiane na /usr/lib/libpcsclite.so.1 (sudo ln -s /usr/lib/libpcsclite.so.1 /usr/lib/libpcsclite.so). V Jave bolo potrebné zaregistrovať príslušného kryptografického poskytovateľa. To je možné urobiť dynamicky v kóde aplikácie, alebo staticky vytvorením alebo doplnením konfiguračných súborov: /etc/java-6-sun/security/pkcs11.cfg name = SmartCard slot = 1 library = /usr/lib/opensc-pkcs11.so /etc/java-6-sun/security/java.security security.provider.7=sun.security.pkcs11.sunpkcs11 \ /etc/java-6-sun/security/pkcs11.cfg Pre účely analýzy správania je možné použiť špeciálnu knižnicu, ktorá vypisuje detailné krokové informácie o volaniach smerovaných na SSCD zariadenie: PKCS11SPY=/usr/lib/opensc-pkcs11.so pkcs11-tool \ --module /usr/lib/pkcs11-spy.so -v --pin \$PIN \ --slot 1 -i in -o test -h Vytváranie podpisu a obálky Trieda Cades umožňuje jednoduché čítanie a zapisovanie podpisovej obálky a podpisu formátu CAdES. Názov súboru obálky má príponu zep a je tvorená zip archívom, ktorý obsahuje podpisovaný dokument, podpis a podpisovú politiku. Ukážku obsahu archívu uvádzame v tabuľke 8. Knižnica bouncycastle obsahuje triedy a metódy na prácu s CMS (PKCS#7), neumožňuje však jednoduchým spôsobom pridanie rozšírení, ktoré vyžaduje CAdES. Rozšírenia sme pridali modifikáciou súčastí knižnice. Vytvorili sme jednoúčelové kópie triedy CMSAttributeTableGenerator pre generovanie tabuľky podpísaných (CMSSignedAttributeTableGenerator) a nepodpísaných atribútov (CMSUnsignedAttributeTableGenerator). Ďaľšou dôležitou zmenou je úprava triedy SignerInfoGenerator. Nepodpísané atribúty je nutné v súbore uložiť v špecifickom poradí. Knižnica však štandarde volá metódu getattributeset ktorá vracia množinu atribútov v kódovaní DER. DER je špeciálny prípad BER kódovania formátu ASN.1. 67

68 Umiestnenie (adresár) Názov súboru Význam D Z\Policy\ P Z.der Podpisová politika v DER kódovaní Dokument (na ktorý sa D Z\ M Z.eml vzťahuje podpis) v kódovaní MIME Podpis v DER/BER D Z\ S Z.p7s kódovaní vychádzajúci z formátu PKCS#7 Tabuľka 8: Ukážka obsahu zep súboru DER za zaručuje že výstup z kódovania bude vždy rovnaký. To dosahuje aj tým, že prvky v množine zotriedi podľa kľúču a do binárnej formy kóduje takto zotriedené dáta. Z toho dôvodu sme vytvorili vlastnú kópiu getmyattributeset, ktorá vracia údaje v BER kódovaní, teda bez triedenia. V aktuálnej podobe je trieda iba demonštráciou ako je možné vytvoriť požadovaný formát a na praktické použitie vyžaduje ďalšie modifikácie. 68

69 5 Záver V práci sme popísali princípy na ktorých je vybudovaný digitálny, elektronický a zaručený elektronický podpis. Popísali sme aktuálny legislatívny stav a praktické skúsenosti so získaním a používaním ZEP. Identifikovali sme niekoľko funkčných a niekoľko bezpečnostných nedostatkov aktuálneho stavu. Pri niekoľkých z nich sme uviedli popis útoku, ktorý ich zneužíva. Bezpečnostné nedostatky sa týkajú najmä tých oblastí, v ktorých zákon nedefinuje, alebo nejasne definuje bezpečnostnú úroveň. Navrhli sme sadu protiopatrení, ktoré opravujú popísané nedostatky. Protiopatrenia sme zaslali relevantným organizáciám a jedna z nich vyjadrila vôľu niektoré návrhy zvážiť. Navrhli sme vlastnú aplikáciu na vytváranie a overovanie elektronického podpisu a bezpečný spôsob jej distribúcie, spúšťania a ochrany pred útokmi. V základnej funkcionalite sme implementovali dva moduly navrhovanej aplikácie. Myslíme si, že problematika bezpečnosti zaručeného elektronického podpisu je v súčasnosti veľmi dôležitá a jej dôležitosť bude ďalej rásť. Dva semestre vyhradené na tvorbu práce sú žiaľ príliš málo vzhľadom na možnosti v ktorých by mohol výskum pokračovať do hĺbky aj šírky. 69

70 Literatúra [1] ISECOM: The Open Source Security Testing Methodology Manual 3.0, Dostupné na internete: [2] NR SR: Zákon č. 215/2002 Z.z. z 15. marca 2002 o elektronickom podpise a o zmene a doplnení niektorých zákonov, Dostupné na internete: zakony_ep/215_2002.pdf [3] DITEC: Profil XAdES_ZEP - formát ZEP na báze XAdES v1.1, Dostupné na internete: index.html [4] Disig: ZEP - Čo potrebujete, Dostupné na internete: index.php?id=156 [5] NBÚ SR: Legislatíva, Dostupné na internete: elektronicky-podpis/legislativa/index.html [6] NBÚ SR: Postup pre získanie prostriedkov k používaniu Zaručeného elektronického podpisu, Dostupné na internete: [7] NBÚ SR: Vyhláška Národného bezpečnostného úradu č. 131/2009 Z.z., o formáte, obsahu a správe certifikátov a kvalifikovaných certifikátov a formáte, periodicite a spôsobe vydávania zoznamu zrušených kvalifikovaných certifikátov (o certifikátoch a kvalifikovaných certifikátoch), Dostupné na internete: ipublisher/files/nbusr.sk/elektronicky-podpis/zakony_ep/ pdf [8] NBÚ SR: Vyhláška Národného bezpečnostného úradu č. 132/2009 Z.z., o podmienkach na poskytovanie akreditovaných certifikačných služieb a o požiadavkách na audit, rozsah auditu a kvalifikáciu audítorov, Dostupné na internete: zakony_ep/ pdf [9] NBÚ SR: Vyhláška Národného bezpečnostného úradu č. 133/2009 Z.z., o obsahu a rozsahu prevádzkovej dokumentácie vedenej certifikačnou autoritou a o bezpečnostných pravidlách a pravidlách na výkon certifikačných činností, Dostupné na internete: elektronicky-podpis/zakony_ep/ pdf 70

71 [10] NBÚ SR: Vyhláška Národného bezpečnostného úradu č. 134/2009 Z.z., ktorou sa ustanovujú podrobnosti o požiadavkách na bezpečné zariadenia na vyhotovovanie časovej pečiatky a požiadavky na produkty pre elektronický podpis (o produktoch elektronického podpisu), Dostupné na internete: zakony_ep/ pdf [11] NBÚ SR: Vyhláška Národného bezpečnostného úradu č. 135/2009 Z.z., o formáte a spôsobe vyhotovenia zaručeného elektronického podpisu, spôsobe zverejňovania verejného kľúča úradu, podmienkach platnosti pre zaručený elektronický podpis, postupe pri overovaní a podmienkach overovania zaručeného elektronického podpisu, formáte časovej pečiatky a spôsobe jej vyhotovenia, požiadavkách na zdroj časových údajov a požiadavkách na vedenie dokumentácie časových pečiatok (o vyhotovení a overovaní elektronického podpisu a časovej pečiatky), Dostupné na internete: elektronicky-podpis/zakony_ep/ pdf [12] NBÚ SR: Vyhláška Národného bezpečnostného úradu č. 136/2009 Z.z., o spôsobe a postupe používania elektronického podpisu v obchodnom styku a administratívnom styku, Dostupné na internete: zakony_ep/ pdf [13] D. Song: Dsniff, Dostupné na internete: [14] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, Dostupné na internete: do?uri=celex:31999l0093:en:html [15] NBÚ SR: Právne stanovisko k 17 ods. 2 zák. č. 215/2002 Z. z. o elektronickom podpise a o zmene a doplnení niektorých zákonov, Dostupné na internete: elektronicky-podpis/legislativa/stanovisko_par17_215_2002.pdf [16] Ardaco: QSign Personal/Office Používateľská príručka, Dostupné na internete: http: // [17] RSA Laboratories: PKCS #11: Cryptographic Token Interface Standard, Dostupné na internete: 71

72 [18] ORACLE: Java PKCS#11 Reference Guide, Dostupné na internete: p11guide.html [19] RFC 5126, CMS Advanced Electronic Signatures (CAdES), Dostupné na internete: [20] ETSI: XML Advanced Electronic Signatures (XAdES), Dostupné na internete: [21] NBÚ SR: Schválené formáty, Dostupné na internete: elektronicky-podpis/standardy-nbu/schvalene-formaty/index.html [22] NBÚ SR: Formáty zaručených elektronických podpisov, Dostupné na internete: schvalene-formaty/formaty_zep.pdf [23] Parlament ČR: Zákon č. 227/2000 Sb., o elektronickém podpisu - s barevným vyznačením posledních změn, Dostupné na internete: soubor/zakon-c sb-o-elektronickem-podpisu.asp [24] Parlament ČR: Vyhláška č. 378/2006 Sb., o postupech kvalifikovaných poskytovatelů certifikačních služeb, Dostupné na internete: vyhlaska-c sb-o-postupech-kvalifikovanych-poskytovatelu-certifikacn aspx [25] J. Janaček, R. Ostertag: Problems in practical use of electronic signatures, Informatica 26 (2002) , Dostupné na internete: si/pdf/informatica_2002_2.pdf [26] NBÚ SR: Certifikované produkty pre používateľov ZEP, Dostupné na internete: certifikacia-produktov-pre-zep/zoznam-certifikovanych-produktov/ certifikovane-produkty-pre-pouzivate-ov-zep/index.html [27] B. Schneier: Beyond Fear: Thinking Sensibly about Security in an Uncertain World, Copernicus Books, ISBN , Sep [28] O. Grošek, M. Vojvoda, M. Zanechal, P. Zajac: Základy kryptografie, ISBN , 2006 [29] MFSR: Informačná bezpečnosť, Dostupné na internete: [30] J. Manuel: The Information Security triad: CIA. Second version, Dostupné na internete: 72

73 [31] W. Diffie, M. E. Hellman: New direction in cryptography. IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976, pp: Dostupné na internete: [32] R. Rivest, A. Shamir, L. Adleman: A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM 21 (2), 1978, p Dostupné na internete: [33] Webová stránka konferencie RSA, about/conference-theme.htm [34] RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Dostupné na internete: html/rfc3280 [35] P. Eckersley, J. Burns: An Observatory for the SSLiverse, priesvitky k prezentácii z konferencie Defcon 18, Las Vegas, USA, Júl 2010, Dostupné na internete: [36] P. Eckersley, J. Burns: Is the SSLiverse a Safe Place?, priesvitky k prezent8cii z konferencie CCC 2010 : 27th Chaos Communication Congress, Berlin, Nemecko, December 2010, Dostupné na internete: pdf [37] M. Toorani, A.A.B. Shirazi: LPKI - A Lightweight Public Key Infrastructure for the Mobile Environments, Proceedings of the 11th IEEE International Conference on Communication Systems (IEEE ICCS 08), pp , Guangzhou, China, Nov Pre predplatiteľov IEEE dostupné na internete: ieee.org/xpl/freeabs_all.jsp?arnumber= [38] RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Dostupné na internete: html/rfc5280 [39] Comodo Group: Comodo Report of Incident - Comodo detected and thwarted an intrusion on 26-MAR-2011, Dostupné na internete: Comodo-Fraud-Incident html [40] C. Soghoian, S. Stamm: Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, Dostupné na internete: cloudprivacy.net/ssl-mitm.pdf [41] U.S. ACT: ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT, 73

74 Dostupné na internete: cgi?dbname=106_cong_public_laws&docid=f:publ pdf [42] ITU-T: RECOMMENDATION X.509 (08/2005), Dostupné na internete: e&id=t-rec-x i!!pdf-e&type=items [43] CEN: Security requirements for signature creation applications, Máj 2004, Dostupné na internete: ftp://ftp.cenorm.be/public/cwas/e-europe/esign/ cwa may.pdf [44] Webová stránka projektu Knoppix, Dostupné na internete: [45] Webová stránka s návodom na modifikáciu OS Knoppix, Dostupné na internete: [46] Webová stránka projektu Bouncy Castle, Dostupné na internete: bouncycastle.org/java.html [47] NBÚ SR: Upresnenia obsahu a formálne špecifikácie formátov dokumentov pre ZEP, Dostupné na internete: sk/elektronicky-podpis/legislativa/9/upresnenia_zep.pdf [48] MF SR: Výnos o štandardoch pre informačné systémy verejnej správy, Dostupné na internete: prilohy_ /7431c [49] MF SR: Koncepcia využívania softvérových produktov vo verejnej správe, Dostupné na internete: LoadDocument.aspx?categoryId=7294&documentId=3707 [50] NBÚ SR: Vyhláška o spôsobe a postupe používania elektronického podpisu v obchodnom a administratívnom styku, Dostupné na internete: elektronicky-podpis/zakony_ep/542_2002.pdf [51] MF SR: Centrálna elektronická podateľňa, Dostupné na internete: opis.gov.sk/data/files/5549.pdf 74

75 Prílohy 75

76 A CD Na priloženom CD sa nachádza obsah práce vo formáte pdf, implementovaný softvér, obrázky a literatúra dostupná v elektronickej podobe. Bližší popis obsahu sa nachádza v súbore citaj.pdf. 76

77 B Odpoveď NBÚ na žiadosť o poskytnutie informácií Národný bezpečnostný úrad Kancelária Národného bezpečnostného úradu Budatínska 30, P.O. BOX 16, Bratislava 57 Č.: 3016/2011/KÚ/OMK-004 Bratislava Vážený pán Tomáš Zaťko Vec Odpoveď na žiadosť o poskytnutie informácie Vážený pán Zaťko, na základe Vašej žiadosti o poskytnutie informácií podľa zákona NR SR č. 211/2000 Z. z. o slobodnom prístupe k informáciám Vám zasielame nasledovnú odpoveď: 1. V akej inej tlači, ako Hospodárske noviny číslo 222 zo dňa strana 4, Verejná správa číslo 25-26/ strana 45, uverejnil úrad v zmysle 12 ods. 2 vyhlášky NBÚ č. 135/2009 Z.z. certifikát verejného kľúču KCA3? Odpoveď: Self-signed certifikát verejného kľúča KCA3 (následníka KCA2) bol v zmysle 12 ods. 2 vyhlášky NBÚ č. 135/2009 Z. z. zverejnený v nasledovnej tlači: - Hospodárske noviny, dňa 19. novembra 2009, konkrétne na 4. strane - Verejná správa, číslo 25-26/2009, konkrétne na 45. strane 2. Akým iným spôsobom, ako je uverejnením v tlači a na webovej stránke úradu, uverejnil úrad v zmysle 12 ods. 2 vyhlášky NBÚ č. 135/2009 Z.z. certifikát verejného kľúču KCA3? Odpoveď: Úrad zverejnil certifikát verejného kľúča v tlači a na internetovom sídle (web stránke) úradu, pričom v zmysle druhej vety horeuvedeného 12 ods. 2 vyhlášky 135/2009 Z.z. úrad môže, ale nie je povinný, zverejniť certifikát verejného kľúča úradu iným spôsobom. 3. K zverejneniu certifikátu verejného kľúča došlo (podľa webovej stránky úradu) iba v tlači z roku 2009 (ktorá v súčasnosti nie je ľahko dostupná) a webovej stránke úradu (ktorá je dostupná iba cez protokol http, náchylný na útoky typu MITM). Považuje NBÚ SR takéto zverejnenie z hľadiska bezpečnosti za dostatočné? Odpoveď: Certifikát verejného kľúča bol zverejnený v zmysle 12 ods. 3 vyhlášky 135/2009 Z. z., čo bolo v roku 2009, preto aj tlač je z roku Zverejnenie na internetovej stránke úradu považujeme naďalej za dostatočné. 77

78 Keďže je certifikát Koreňovej certifikačnej autority dôležitý pri overovaní zaručeného elektronického podpisu, publikuje NBÚ na svojej stránke dokument Dôveryhodný zoznam podpisových politík a koreňových certifikátov, kde sú publikované všetky úradom schválené podpisové politiky a vydané certifikáty KCA. Dokument je vytvorený s použitím integritného elektronického podpisu. Rovnako všetky certifikáty KCA a všetkých akreditovaných CA sú publikované v Dôveryhodnom zozname EÚ. Všetky uvedené informácie sú dostupné na internetovej stránke úradu. 4. Akú jednoduchú, rýchlu a hlavne _dôveryhodnú_ cestu odporúča úrad na získanie certifikátu verejného kľúču KCA3? Odpoveď: Certifikát verejného kľúča je umiestnený na webovej stránke úradu ep.nbusr.sk a je tiež zahrnutý v podpísaných publikovaných dokumentoch TrustedList a TSL (podľa rozhodnutia EK 2009/767/ES). 5. Z akého dôvodu nie sú webové stránky úradu (menovite minimálne a ep.nbusr.sk) sprístupnené zabezpečeným protokolom HTTPS? Odpoveď: Platná legislatíva Slovenskej republiky takúto povinnosť neukladá. 6. Plánuje úrad sprístupniť svoje webové stránky (menovite minimálne a ep.nbusr.sk) zabezpečeným protokolom HTTPS? Odpoveď: S vystavením webových stránok úradu na protokole https sa neuvažuje. 7. V prípade, že úrad plánuje svoje webové stránky sprístupniť zabezpečeným protokolom HTTPS, na základe akých kritérií bude voliť certifikačnú autoritu, ktorá certifikát podpíše? Odpoveď: S vystavením webových stránok úradu na protokole https sa neuvažuje. 8. V prípade, že úrad plánuje svoje webové stránky sprístupniť zabezpečeným protokolom HTTPS, bude brať do úvahy existenciu uznávaných svetových certifikačných autorít, ktorých certifikáty je v súčasnosti možné overiť z mnohých zdrojov (napríklad sú súčasťou inštalácií majoritných operačných systémov a webových prehliadačov)? Odpoveď: S vystavením webových stránok úradu na protokole https sa neuvažuje. Čo sa týka existencie uznávaných svetových certifikačných autorít, ich relevancia na úrovni EÚ z pohľadu smernice 1999/93/ES o rámci spoločenstva pre elektronický podpis nie je nijako hodnotená. Za dôveryhodné v oblasti elektronického podpisu považujeme certifikačné autority deklarované v rámci EÚ v zoznamoch dôveryhodných poskytovateľov certifikačných služieb členských krajín EÚ. PhDr. Ivan Goldschmidt riaditeľ kancelárie NBÚ 78

79 C Textová podoba certifikátu NBÚ KCA3 1 Certificate : 2 Data : 3 Version : 3 (0 x2) 4 Serial Number : 1 (0 x1) 5 Signature Algorithm : sha256withrsaencryption 6 Issuer : C=SK, L= Bratislava, O= Narodny bezpecnostny urad, OU= SIBEP, CN = KCA NBU SR 3 7 Validity 8 Not Before : Nov 6 09: 59: GMT 9 Not After : Nov 6 07: 29: GMT 10 Subject : C = SK, L = Bratislava, O = Narodny bezpecnostny urad, OU = SIBEP, CN = KCA NBU SR 3 11 Subject Public Key Info : 12 Public Key Algorithm : rsaencryption 13 RSA Public Key : ( 4096 bit ) 14 Modulus ( 4096 bit ): 15 00: db:aa:d0 :8f:2f:4a :97:12: d5:b9:eb :7d :59: dc: 16 83:5 c:8b :31:17: f2:e5 :6e:5e:ce :2c:d2:c5 :27: dc: 17 67: ea:b3 :8e:f0:d7 :05:21:97: d2 :94:0 d :54:49: b1: 18 1f:2b:ed:e4 :30:9 c:8d :60:93:72:16:2 f:0e :19:0 a: 19 b7:be:ff :7f:c9 :18: c9:e4 :40:11: cd :59:67: b3 :84: 20 4e :84:8 f:e7:c4 :46: a1:bb :81:13: e1 :5c :55: bb :23: 21 b9 :87:47: e6:c8 :98:86:74:5 c :09:20: fc:c5 :53:15: 22 d8 :77:66:7 e:bb :63: a9 :2d:b3 :4b:ca :78: f8 :1c:6f: 23 64: d8 :22: ba:a7 :94: c1:d0 :25: f3 :8f :83:14: af:ba: 24 db :5c:5d:2c :57: e2 :77:89:0 c:1c :15:22:68:97: c0: 25 b8 :80:69:67: f7 :00: b8 :73:30: b8:e2 :31: d6 :7d :95: 26 12: bd :0d:ef :2b:d8 :6b :48:16: c9 :27:76: d8 :2d :95: 27 7f :45: ac :0a:bd :1e :12:91:60: f1 :9c :58:8 e:b6 :2e: 28 ee :8d :42: eb :5a :97: e4 :82:20: a8:d9 :30: d5:e0:d4: 29 86: b1:a1 :9e:5c :42:33: a0 :14: a1 :61:1 b :69: a6 :26: 30 c7 :8e:6b:8b:c8 :5c :19:9 a:f8 :20:63:6 f:ee:c7:e1: 31 15: c2:de :9b :82: b9 :5f:b5 :02: e9 :39:11:76: ad :34: 32 00:76: dd :74:3 b :26:4 d:b8:c4 :69:86:42: ae :0f :08: 33 1d:d4 :48:4 a:e2:f5:bd :5e:e6:cb :35: b0 :42:0 c :14: 34 61:1 c:6f:1d:a7:b5 :63: fd :63:88:54:93: ee :40: a4: 35 77: d4:ed:a7 :82:73:62:57:82:2 d :14: b7:d5 :4d:4e: 36 a1:e7 :8f:c8 :80: de :16:0 c :83:3 b:d8 :09:3 b:e7 :25: 37 48:9 e:4a :94:6 e:ad :6e :61: e1:c8:df:be :70:21:55: 38 11: d5:e2:e4 :5b :51:6 e:b1 :3f:b0 :31:8 b:d5 :02:96: 39 4a :83: fd :06:5 f:a9 :4d:2d :19: a9 :40: e3 :85: bf:b8: 40 8f:5d:aa :0e:e1 :84:8 d:ef:ad :4f :90:72:5 f:e6:a2: 41 55: c9 :84: bc :74:23:3 f :79: ca :40:4 d :12:91: fd :17: 42 dd :25:23:66:1 d:c3:c7 :79: af :14: f9 :9a:f9:bf:ed: 43 1f:f4 :39:16:27: fc:f0:cc:b0 :16:35: d5 :37: e0 :2e: 79

80 44 2c:d4:b0 :66:2 c:0e:ae :18:01:9 f:8f:cb :9e:b1 :0f: 45 b9 :19:12:82:0 d:c6 :70:50:0 d:7d:e5 :72: cd:da :8d: 46 09:62:77: ab:f5 :96:39:2 f:e0:c1 :4e :08: db:c6 :87: 47 31:7 b:2e :79: aa:fb :04: a9 :68:62:24: ed :0a:c2 :48: 48 30:33: ff:ed :1e :23: b9 :5b :14: bf :45:6 e:a4:d6:db: 49 35: e8:e3 50 Exponent : (0 x10001 ) 51 X509v3 extensions : 52 X509v3 Certificate Policies : 53 Policy : CPS : http :// ep. nbusr.sk/kca / doc / kca_cps. pdf X509v3 Basic Constraints : critical 57 CA: TRUE 58 X509v3 CRL Distribution Points : 59 URI : http :// ep. nbusr.sk/kca / crls3 / kcanbusr3. crl 60 URI : ldap :// ep. nbusr.sk/cn %3 dkca %20 NBU %20 SR %203, ou %3 dsibep,o%3 dnarodny %20 bezpecnostny %20 urad,l%3 dbratislava,c%3 dsk? certificaterevocationlist 61 URI : ldap :/// cn %3 dkca %20 NBU %20 SR %203, ou %3 dsibep,o%3 dnarodny %20 bezpecnostny %20 urad,l%3 dbratislava,c%3 dsk? certificaterevocationlist Subject Information Access : 64 CA Repository - URI : http :// ep. nbusr.sk/kca / certs / kca3 / kcanbusr3. p7c 65 CA Repository - URI : ldap :// ep. nbusr.sk/cn=kca NBU SR 3,ou=SIBEP,o= Narodny bezpecnostny urad,l= Bratislava,c=SK? cacertificate ; binary 66 CA Repository - URI : ldap :/// cn=kca NBU SR 3,ou=SIBEP,o = Narodny bezpecnostny urad,l= Bratislava,c=SK? cacertificate ; binary X509v3 Key Usage : critical 69 Certificate Sign, CRL Sign 70 X509v3 Subject Key Identifier : 71 7F:F1 :3D :21: C2 :97:5 A:2E :97:07:0 E:B1 :69:83:25: FD :21:86:3 E :07 72 Signature Algorithm : sha256withrsaencryption 73 36: db:f9 :12: e9 :65:42: b2:a3:b9 :89: ee :7b:d9 :1e :72:6 f:6f: 74 a0:b0 :27: c2:a2:ea :8a:9e :17:10:1 d:b6 :9a:c8 :00: b8 :8a:cb: 75 90:4 b:5e :32: de:b5 :93: f0 :45:82: d8 :57:6 a:ef :5f :07:00: fd: 76 09:7 b:b7:ab :04: e3:b5:ff :9f:c9 :38:1 b :53:56:95:47:46: ff: 77 07:2 c:d3 :6e :69:29: d7:bf :65:43:94: bc :5c:e9:da:c1 :2f :79: 78 eb:b2 :56:34:76:8 d :89:15: b8 :5c:d3 :77:59: b4 :12: b0 :87: f1: 79 06:8 e :55: b3 :57: b4:b9 :6d :06:69: d4:c8 :5d:a4 :60:33:1 c :22: 80 58:8 a :68:6 d:dd:e7:bb :53: db :5a :56:0 f :82:2 d :79:77:04:58: 80

81 81 e2:e4 :9f:8c:d4 :35:1 c :56: d5 :56:07:9 f:8b:a6 :78:3 b:7d :98: 82 2b:3c :55: df:c3 :7e:3a:ce:ee :56: c5 :5c:9e:2c:af :23:65: e8: 83 f8:c6:d4 :57:39:9 d :17:61:31:36: fb:a0:b9:fd :3a:8d:e9 :1c: 84 fd :57: c7 :48:56:39: ce:cd :6c :30:9 c :99:23:56:98:9 a :46: ed: 85 85:02:07:21:05:79: b0:ad:ff :06: ab:fc:f4 :8f :19: c7 :60:81: 86 c1 :54: cc:fd:d8 :33: cd:c7 :6c :36: f8 :74:45:69:1 b:de:a2:bd: 87 b5 :5a:a1 :27:26: b6 :90:60:85:08:3 f:a1:e8 :2c:9a:d5:de :93: 88 13:86:96:0 e:e6:f5 :74:05: f8 :2f:5c :35:96: a7 :5a:c0 :6e:2b: 89 9f:3f :87:86:81: b9 :66:2 a :14:17:33:5 d :14:91:18:24:27:42: 90 45: c6:eb :1b :40: ec :3b:6e :48:9 f :51:99:55: b3:ba :9a :15:9 c: 91 a1:fe:af:c0:a5:b8 :71:39:27:2 a:2d:3d :31:47: b9 :97:5 a:b9: 92 a0:ab:b5 :56: c2 :33:0 e :29: b2 :99:47: b4 :07:6 b :06: e7 :25: a7: 93 90:26:33: f7 :50:5 a :61:07:5 a:6e:bd :75:16:5 c :22:2 a:b8 :8c: 94 37:39:57:71: de :05:0 b:fa :3a :32: f3:cd :3e:f5 :16: ce :48:84: 95 57: dc :20: f3 :6b:b3:b6 :22:80:36: a4 :5a :15:87:0 e:f2:c1:d8: 96 6a:3c :78:21:8 d :64:10: b8:bd :4d :47:9 c:b6:e5 :8b:d8 :48: da: 97 36:9 f:4e :26:76: cb:d9 :85: c2 :55: e9:ad :6f:d3:d4 :61: d6 :46: 98 fa :05: a9 :1f :90: e5 :10:0 c :61: b0:ca :58: fa:a1:fb:c7 :5b:2e: 99 9e:ee :0d:b7 :02:19:99: d0 :4a :64:6 e:fa :30:3 c :33: d2 :60:8 f: :66:12: a2:eb :3d:d5 :04:01: a9:e4:e1 :97:78:46:9 e :58:94: : c7:c5:d9:a3 :49:7 a:c0 81

82 D Ukážky certifikátov bezpečných produktov 82

83 83