Poznámka: predchádzajúca verzia toho článku hovorila o pužití SHA-1 a DSA algoritmov. Oba boli označené za zastaralé vo Firefoxe 37, resp. 38. Preto som článok upravil tak, aby používal SHA-256a RSA:

Úvod

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.)

Certifikačná autorita

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:

Prvým krokom je vytvorenie privátneho RSA kľúča:

openssl genrsa -out CArsaprivtekey 2048

Generating RSA private key, 2048 bit long modulus
.....................................................................................................+++
..........................................+++
e is 65537 (0x10001)

Parametre hovoria, že vytvárame súbor CArsaprivtekey, do ktorého chceme zapisať 2048-bitový kľúč. Chránenie tohoto súboru pred nepovolanými osobami je základným kameňom bezpečnosti Certifikarnej Autority.

Nasleduje ďalší krok - vytvorenie požiadavky na certifikát samotnej CA:

openssl req -new -x509 -key CArsaprivtekey -out CAcertificate.pem -days 3560 -sha256

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 RSA kľúča v súbore CArsaprivtekey. Výsledný certifikát bude uložený do súboru s názvom CAcertificate.pem. Tento certifikát budeme používať pre vytváranie certifikátov jednotlivých užívateľov. Parameter -days 3650 hovorí, že platnosť certifikátu bude 3560 dní (10 rokov) a -sha256 hovorí, že pri použití tohto certifikátu sa bude používať hashovacia funkcia SHA-256.

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.pem -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

Certifikát

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 -days 3650 -sha256

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 takisto dôležitým prvkom bezpečnosti celého systému. Parametre-days 3650 -sha256 majú rovnaký význam, ako bolo popísané vyššie.

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.pem -keyfile CArsaprivtekey -verbose -days 3650 -md sha256

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.pem a súkromného kľúča v CArsaprivtekey a tento certifikát bude platný 3650 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

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:

openssl dgst -verify RSpublickey -signature podpis < vstupny_subor

Verified OK

Ak by súbor medzičasom niekto pozmenil, elektronický podpis už nebude sedieť:

openssl dgst -verify RSpublickey -signature podpis < zmeneny_subor

Verification Failure

Od CUI ku GUI

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ú.

Bezpečný web

Ď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.

Odvolávam čo som odvolal ...

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 CArsaprivtekey -cert CAcertificate.pem

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é:

Záver

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.