Tento článok je jemným úvodom do problematiky bezpečnej elektronickej komunikácie. Ten kto chce komunikovať v prostredí internetu bezpečným spôsobom má na výber dve technológie. Jednou je použitie systému PGP resp. jeho implementácie GPG. Jeho charakteristikou je to, že dôveryhodnosť komunikácie je založená len na vzťahu odosielateľa a príjemcu. V istých situáciách, ale tento spôsob nie je vyhovujúci. Ak chceme komunikovať so štátnymi inštitúciami, alebo servermi, ktoré sú prakticky mimo náš dosah, otvára sa priestor pre systém bezpečnostných certifikátov. Z technického hľadiska je tento systém označovaný skratkou SSL - Secure Socket Layer - ak ho chceme používať, tak najlacnejšou cestou je použitie balíka OpenSSL.
V systéme SSL nie je nutné, aby sa príjemca a odosielateľ navzájom osobne poznali. Overenie ich totožnosti zabezpečuje Certifikačná Autorita - CA. Je to organizácia, ktorá vydáva bezpečnostné certifikáty. Sú to dátové konštrukcie umožňujúce používanie elektronického podpisu. Ak dostanem správu od užívateľa XY a tá správa je podpísaná jeho certifikátom, ktorý vydala CA, tak CA ručí za to, že ten certifikát bol vydaný práve užívateľovi XY a nikto okrem neho nemohol vytvoriť príslušný podpis. Certifikáty tiež obsahujú kryptografické údaje, ktoré je možné použiť na šifrovanie dát pri elektronickej komunikácii.
Vo svete existuje mnoho certifikačných autorít. Sú to organizácie, ktoré na požiadanie vydajú certifikát, ktorý potom možno použiť na bezpečnú elektronickú komunikáciu. Medzi najznámejšie patrí RSA Security Inc. či VeriSign Inc. Ich certifikáty často používajú banky a medzinárodné internetové obchody. Certifikačná autorita ako organizácia musí dodržiavať prísne bezpečnostné pravidlá - počnúc fyzickým zabezpečením priestorov, kde sa činnosť CA vykonáva, cez off-site zálohy, až po bezpečnostné previerky pracovníkov a podobne. S tým sú prirodzene spojené náklady, ktoré CA často prenáša na svojich klientov. Vydanie certifikátu je preto spravidla platená služba. Existujú, ale aj CA, ktoré vydávajú certifikáty za nízku cenu resp. zadarmo. Medzi najznámejšie CA tejto triedy patrí Thawte. Na Slovensku aj v Čechách platí už niekoľko rokov Zákon o elektronickom podpise, ktorý pre účely právne záväzného elektronického podpisu vyžaduje použitie štátom uznanej certifikačnej autority. Povolenie na činnosť CA vydáva Národný bezpečnostný úrad. Ten takisto vydáva bezpečnostné predpisy pre činnosť CA, vykonáva ich kontrolu a funguje ako "koreňová CA" - podpisuje certifikáty komerčných certifikačných autorít. Na Slovensku medzi akreditované CA patrí napr. CA EVPÚ v Dubnici nad Váhom. (V Čechách certifikáty vydáva napr. aj Česká pošta, ale nie som si istý či tieto certifikáty spĺňajú všetky náležitosti vyžadované českou legislatívou.)
V niektorých situáciách nám, ale postačí CA, ktorú si vytvoríme sami. Jediným problémom je, že musíme všetkých ľudí, s ktorými chceme komunikovať pomocou certifikátov vydaných našou CA, presvedčiť o dôveryhodnosti tejto CA. Certifikačné autority ako VeriSign, Thawte a pod., si svoju dôveryhodnosť získali mnohoročným pôsobením na trhu. Našťastie urobiť si vlastnú certifikačnú autoritu technicky nie je nijak zložité. Použijeme program OpenSSL. Pravdepodobne tak nesplníme podmienky ktoré stanovuje zákon o elektronickom podpise, ale pre účely nahliadnutia do problematiky to stačí. S použitím programu OpenSSL vytvoríme CA nasledovne:
V prvom rade vytvoríme súbor s parametrami pre vytvorenie DSA kľúča
openssl dsaparam -outform PEM -out CAdsaparamfile -genkey 1024 Generating DSA parameters, 1024 bit long prime This could take some time ...+++++++++++++++++++++++++++++++++++++++++++++++++++* .......+.....+.+..........+....+............+.+......................+.......... ...+...........+...............+.........+.......+..........+................... +..+.....+.+...........+....+.+.......+..............+....+................+.... .......+............+.............+..+......+.+...+.+....+.+.................... ....+.......+.+................+............+.....+.....+..+....++++++++++++++++ +++++++++++++++++++++++++++++++++++*
Prvý parameter hovorí, že vytvárame DSA parametrický súbor.
Ďalšie parametre hovoria, že výstup je vo formáte
PEM, výstupný súbor
bude mať meno CAdsaparamfile a generovaný kľúč bude mať dĺžku 1024 bitov. Balík
OpenSSL používa konfiguračný súbor. Ten by mal byť spravidla umiestnený v
/etc/ssl/openssl.cnf. Tam môžu byť rôzne defaultné nastavenia
preddefinované. V tomto článku sa budem snažiť používať ho čo najmenej a pokiaľ
možno všetky požadované nastavenia definovať cez prepínače na príkazovom
riadku.
Ďalším krokom je vytvorenie DSA kľúča:
openssl gendsa CAdsaparamfile -out CAdsaprivtekey Generating DSA key, 1024 bits
Parametre tentokrát hovoria, že generujeme DSA kľúč s parametrami uvedenými v CAdsaparamfile a výstupný súbor sa bude volať CAdsaprivtekey.
Nasleduje predposledný krok - vytvorenie požiadavky na certifikát samotnej CA:
openssl req -new -x509 -key CAdsaprivtekey -out CAcertificate You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:SK State or Province Name (full name) [Some-State]:Slovakia Locality Name (eg, city) []:Trencin Organization Name (eg, company) [Internet Widgits Pty Ltd]:Rastos Certificate Authority Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:rastos CA Email Address []:
V parametroch vidíme, že vyrábame požiadavku (request)
pre vytvorenie nového certifikátu typu X509 s použitím DSA kľúča
v súbore CAdsaprivtekey. Výsledný certifikát bude uložený do súboru
s názvom CAcertificate. Tento certifikát budeme
používať pre vytváranie certifikátov jednotlivých užívateľov.
Súbor s certifikátom je zakódovaný base64 kódovaním. Vyzerá
takto:
-----BEGIN CERTIFICATE----- MIIDuTCCA3mgAwIBAgIJANc8qEjrcbHnMAkGByqGSM44BAMwXjELMAkGA1UEBhMC ... LAIUWMK6QHBbzNzOG4VznLxaXubHsKcCFDEXLLUV8REDXxLwTdQajeDWeerI -----END CERTIFICATE-----
Ak chceme vidieť jeho obsah v zrozumiteľnej forme, pomôže nám tento príkaz:
openssl x509 -text -in CAcertificate -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d7:3c:a8:48:eb:71:b1:e7
...
Pre fungovanie CA je ešte potrebné urobiť ešte jeden krok - vytvoriť súbor, v ktorom bude OpenSSL udržiavať aktuálny zoznam vydaných a aj neplatných certifikátov a ich počet:
mkdir demoCA touch demoCA/index.txt echo 01 > demoCA/serial
Umiestnenie názov týchto súborov definuje konfiguračný súbor
[ CA_default ] dir = ./demoCA # Where everything is kept database = $dir/index.txt # database index file. serial = $dir/serial # The current serial number
Keď chce užívateľ dostať certifikát od našej CA, musí nám najprv poslať požiadavku (request):
openssl req -new -out RScertrequest -keyout RSprivatekey Generating a 1024 bit RSA private key ......................................++++++ .++++++ writing new private key to 'RSprivatekey' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. ...
Všimnite si, že program si vypýtal "PEM pass phrase" - to je heslo, ktoré budeme používať pri vytváraní elektronického podpisu. Jeho bezpečnosť je dôležitým prvkom bezpečnosti celého systému.
Certifikačná autorita by si mala teraz overiť, že požiadavka skutočne patrí osobe, ktorá ju doručila a potom môže vytvoriť samotný certifikát:
openssl ca -in RScertrequest -out RScertificate.pem -policy policy_anything \ -outdir . -cert CAcertificate -keyfile CAdsaprivtekey -verbose -days 365 Using configuration from /etc/ssl/openssl.cnf 0 entries loaded from the database ... Certificate is to be certified until Feb 11 21:22:57 2007 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries writing new certificates writing ./01.pem Data Base Updated
V tomto príkaze sú použité parametre, ktoré hovoria, že CA použije
požiadavku RScertrequest na vytvorenie certifikátu podpísaného
certifikačnou autoritou. Tento certifikát bude spôsobilý na všetky
úkony (šifrovanie/podpisovanie/...) a bude vytvorený s použitím
certifikátu CAcertificate a súkromného kľúča v
CAdsaprivtekey a tento certifikát bude platný 365 dní.
Súbor RScertificate.pem teda CA vráti žiadateľovi a ten
ho môže odteraz používať pre komunikáciu pomocou SSL. Certifikačná
autorita si ponecháva jednu kópiu v podpísaného certifikátu v súbore
01.pem. Z overeného certifikátu si môžeme vytiahnuť verejný
kľúč, ktorý budeme potrebovať pri overovaní podpisu
openssl x509 -noout -pubkey -in RScertificate.pem > RSpublickey
Elektronický podpis sa vyrába tak, že zo vstupného dokumentu sa spočíta kontrolná suma. Kontrolná suma sa počíta špeciálnym matematickým algoritmom. Jeho špeciálnosť spočíva v tom, že pre ľubovoľný vstup poskytne na výstupe reťazec, z ktorého nie je možné odvodiť pôvodný vstup a zároveň aj tá najmenšia zmena vo vstupe, má za následok zmenu vo výstupe. V minulosti sa používal jednoduchý algoritmus zvaný CRC, v súčasnosti sa používa napr. algoritmus s označením MD5, ale ten je vytláčaný algoritmom SHA1 resp. SHA2. Získaný výstupný reťazec, sa potom zašifruje pomocou súkromného kľúča:
openssl dgst -sign RSprivatekey vstupny_subor > podpis Enter pass phrase for RSprivatekey:
Program si vypýta heslo prislúchajúce ku RSprivatekey a s jeho pomocou vytvorí elektronický podpis. Podpis je unikátny pre daný privátny kľúč a vstupný súbor. Nikto iný, než ten kto disponuje privátnym kľúčom, nemôže vytvoriť rovnaký podpis. Ten, kto chce zistiť či dokument je pravý (nebol zmenený jeho obsah), spočíta jeho kontrolnú sumu. Tá sa potom porovná s kontrolnou sumou, ktorá sme získali dešifrovaním overovaného podpisu:
Ak by súbor medzičasom niekto pozmenil, elektronický podpis už nebude sedieť:openssl dgst -verify RSpublickey -signature podpis < vstupny_subor Verified OK
openssl dgst -verify RSpublickey -signature podpis < zmeneny_subor Verification Failure
V predchádzajúcich odstavcoch sme používali pre prácu s certifikátmi program openssl z balíka OpenSSL. Pozrieme sa teraz ako využiť SSL v maileri či browseri. Aby certifikáty užívateľov bolo možné používať na šifrovanie či podpisovanie správ, musíme najprv naučiť program rozoznávať certifikačnú autoritu, ktorá certifikáty vydáva.
|
|
|
Náš vlastný certifikát potrebujeme importovať ak plánujeme podpisovať odosielané správy. Mailové programy spravidla požadujú certifikát v inom formáte ako sme používali doteraz - PKCS#12. Našťastie openssl poskytuje možnosť previesť certifikáty do požadovaného formátu:
openssl pkcs12 -in RScertificate.pem -inkey RSprivatekey -export \ -out RScertificate.p12 Enter pass phrase for RSprivatekey: Enter Export Password: Verifying - Enter Export Password:
Certifikáty ľudí, ktorých podpisy budeme overovať, alebo ktorým budeme posielať šifrované správy, musíme takisto importovať.
Po ukončení importovania môžeme potom pri písaní správy nastaviť či má byť šifrovaná, alebo podpísaná, alebo oboje:
 |
 |
 |
Pri takomto nastavení bude text správy šifrovaný. Pozor, ale na to že informácie v hlavičke mailu, teda odosielateľ, príjemca, predmet správy a podobne šifrované nie sú.
Ďalšou oblasťou, kde sa s SSL certifikáty stretávame sú webové servery.
Typickým príkladom sú webové servery pre internetbanking. Zmyslom je,
aby si užívateľ bol istý, že je skutočne spojený s webovým serverom
banky a nie nejakého podvodníka, ktorý sa snaží vylákať cenné informácie,
číslo kreditky a podobne. Okrem autentickosti servera sa SSL postará
aj o šifrovanie dát prenášaných medzi webovým serverom a browserom.
Ako to funguje si môžeme vyskúšať pomerne
jednoducho. Potrebujeme k tomu webový server apache, ktorý bol skompilovaný
s podporou ssl - pri kompilovaní bol použitý prepínač
--with-openssl. SSL funkcionalita je dostupná vo forme
modulu s názvom mod_ssl. Aby bola aktivovaná, musí konfigurácia
apache obsahovať direktívu:
LoadModule ssl_module libexec/apache/libssl.so
Moja distribúcia to konkrétne rieši tak, že v konfiguračnom súbore
/etc/apache/httpd.conf treba zrušiť komentár na riadku,
ktorý includuje súbor s konfiguráciou SSL:
# ==> mod_ssl configuration settings <== Include /etc/apache/mod_ssl.conf
Správne nahratie mod_ssl sa prejaví aj v logu (o umiestnení logu rozhoduje
direktíva ErrorLog a vplyv má aj LogLevel v
httpd.conf):
tail /var/log/apache/error_log ... [Wed Feb 8 21:25:24 2006] [notice] Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7d configured -- resuming normal operations
Okrem správneho nahratia mod_ssl potrebujeme prinajmenšom certifikát a zodpovedajúci privátny kľúč. O ich umiestnení rozhodujú direktívy v konfiguračnom súbore:
SSLCertificateFile /etc/apache/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache/ssl.key/server.key
Podstatné je aj nastavenie portu. Webové spojenia chránené pomocou SSL sa tradične robia na porte https (s číslom 443):
<IfDefine SSL> Listen 80 Listen 443 </IfDefine>
Teraz nám už ostáva iba prekrížiť prsty a odštartovať to:
httpd -DSSL Apache/1.3.33 mod_ssl/2.8.22 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server ras:443 (RSA) Enter pass phrase: Ok: Pass Phrase Dialog successful.
Či apache počúva na porte https nám povie napr. netstat
netstat -ltp |grep http tcp 0 0 *:http *:* LISTEN 3616/httpd tcp 0 0 *:https *:* LISTEN 3616/httpd
Ak je všetko v poriadku, tak sa môžeme pokúsiť pripojiť pomocou browsera. Pretože ja som použil certifikát, ktorý som si vyrobil sám tak ma browser upozorní, že taký certifikát ani CA nepozná a ponúkne mi zaradiť ho medzi dôveryhodné certifikáty. Tomu sa dá vyhnúť ak certifikát CA vopred zaradíme do zoznamu dôveryhodných CA:
 |
 |
SSL modul servera apache dokáže oveľa viac. Môžete povoliť prístup k niektorým URL len pre browsery, ktoré sa preukážu správnym certifikátom a podobne. Detailnejší popis je mimo rozsah tohoto článku, ale s dôverou sa môžete obrátiť na dokumentáciu.
Ak ste robili kroky popísané vyššie isto ste si všimli, že privátny kľúč je chránený heslom. Čo sa stane, keď sa heslo prezradí? V takom prípade môže niekto predstierať, že sme to my. Samozrejme za predpokladu, že získa aj náš privátny kľúč. Môže tiež dešifrovať správy určené len nám. Tento problém riešia odvolávacie certifikáty (Revocation Certificate). Certifikačná autorita, okrem vydávania certifikátov aj udržiava a publikuje CRL - zoznam certifikátov, ktoré už nie sú platné.
openssl ca -revoke RScertificate.pem -keyfile CAdsaprivtekey -cert CAcertificate
V parametroch vidíme, že odvolávame certifikát signed.pem
a potrebný je na to privátny kľúč CA a certifikát CA. O revokačných
certifikátoch sa všeobecne málo vie. V prípade, že sa napr. pripájate
na internet-banking tak by ste si mali nielen overiť, že sa pripájate
skutočne na ten správny server, ale aj to, že jeho certifikát nebol
medzičasom odvolaný. Niektoré prehliadače to dokážu robiť za nás, ak
sú správne nastavené:
 |
 |
 |
Program openssl z balíka OpenSSL, ktorý sme používali v uvedených príkladoch nie je určený pre koncového užívateľa a ani nie je tou najdôležitejšou časťou tohoto balíka. Najpodstatnejšou časťou sú knižnice implementujúce jednotlivé šifrovacie a hashovacie algoritmy a program openssl len poskytuje základný prístup k týmto knižniciam. Okrem openssl sú súčasťou balíka aj ďalšie skripty napr. CA.pl a podobne. Knižnice z balíka OpenSSL sú používané v množstve Open Source projektov, kde majú na starosti bezpečnosť ukladania a prenosu dát. Udržiavanie aktuálnosti tohoto balíka je významnou súčasťou bezpečnosti celého systému.