SSL - 2 (elektronický podpis)

6. 3. 2006 | Rastislav Stanik | Bezpečnost | 15867×

Jak využít SSL k bezpečnému podepisování dokumentů, použití grafických programů, zabezpečení komunikace na webu, zrušené certifikáty.

• Úvod
• Certifikačná autorita
• Certifikát
• Elektronický podpis
• Od CUI ku GUI
• Bezpečný web
• Odvolávam, čo som odvolal ...

Elektronický podpis

Elektronický podpis sa vyrába tak, že zo vstupného dokumentu sa spočíta kontrolný súčet. Kontrolný súčet 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ý súkromný kľúč a vstupný súbor. Nikto iný, než ten, kto disponuje súkromným kľúčom, nemôže vytvoriť rovnaký podpis. Ten, kto chce zistiť, či dokument je pravý (nebol zmenený jeho obsah), spočíta jeho kontrolný súčet. Ten sa potom porovná s kontrolným súčtom, 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 odsekoch sme používali pre prácu s certifikátmi program openssl z balíka OpenSSL. Teraz sa pozrieme, ako využiť SSL v maileri či browseri. Aby certifikáty použí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 však 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átmi stretávame, sú webové servery. Typickým príkladom sú webové servery pre internetbanking. Zmyslom je, aby si použí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 súkromný 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 tohto č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 súkromný 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áš súkromný 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 súkromný 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 používateľa a ani nie je tou najdôležitejšou časťou tohto 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.

       

Komentáře

[GeBu]

Super články. Jen škoda, že screenshoty jsou z anglického TB.

[karely]

Super články. Je dobře, že screenshoty jsou z anglického TB

[GeBu]

Proč to je dobře? Tvůj rodný jazyk není čeština?

[rastos]

Rodný jazyk autora nie je čeština . Ale o to nejde. Zastávam názor, že prekladaný program stráca na kvalite a preto používam prakticky všetok software nelokalizovaný - anglický. Problém je tiež v tom, že preklady niektorých pojmov nie sú ustálené. A to sa potom človek čuduje keď lúšti chybovú hlášku "neplatný popisovač" a podobne . Pravdou je, že by som pri tých screenshotoch mal rád aj linky na screenshoty z iných klientov než TB, ale nejak som sa k tomu nedokopal. Zatiaľ.

[GeBu]

No, já jsem se ptal na rodný jazyk autora toho příspěvku "karely", který ho napsal česky :). Zajímavý názor s tou lokalizací, ale internet bude jistě plný screenshotů v angličtině. Naopak smysl článků a screenshotů vidím, když na českém webu budou v nějakém pro čecha dobře srozumitelném jazyce (např. slovenštině). Pokročilí uživatelé ty screenshoty nepotřebují a navíc lidí, kteří používají programy v originále je hodně málo. Což je fakt. Denně na czilla.cz řešíme "nemám to česky", ale nepamatuju si, že bych řešil "chci to anglicky". V podstatě pro člověka, který neumí anglicky je pak dost velký problém s těmi screenshoty, protože se vůbec neshodují s tím co má v PC. Co se týká ustálení pojmů tak to je možné, ale osobně v tom velký problém nevidím. Docela by mě zajímalo proč by měla lokalizace snižovat kvalitu - máte na mysli funkčnost?

[rastos]

Docela by mě zajímalo proč by měla lokalizace snižovat kvalitu - máte na mysli funkčnost?

Mám na mysli nepresnosť prekladu. Veľmi často sa stáva, že prekladateľ nepozná, resp. dostatočne nepreskúma, súvislosti v ktorých je daný termín použitý. Problémom, je tiež to, že niektoré stringy v originálnom programe sú použité na viacerých miestach v rôznych pádoch. V angličtine to nevadí, pretože vo všetkých pádoch má to slovo stále rovnaký tvar, ale v našich jazykoch dochádza k tomu, že slovo je na jednom mieste správne a na inom nesprávne vyskloňované. Ďalším príkladom je niečo, čo som zažil nedávno pri čítaní jednej knižky o SQL - prekladateľ prekladal aj príklady. Ale nie konzistentne. Takže meno stĺpca v CREATE TABLE bolo anglické, ale v SELECT statemente už bolo preložené. Skrátka urobiť dobrý preklad nie je jednoduché. A keď chcem mať istotu tak sa obraciam na originál.

Ale samozrejme priznávam, že máš svoju pravdu. Považuj moju náchylnosť používať anglický soft za moju úchylku, a ja sa budem snažiť pri písaní ďalšieho článku myslieť na Tvoju pripomienku.

[GeBu]

Aha už chápu. Já myslel, že to ovlivňuje funkčnost. Slyšel jsem to totiž už 2x, ale ohledně lokalizace software pro Windows. * Když jsem studoval tak můj spolužá dělal brigádu na překladu Win95 a nedoporučoval mi lokalizaci používat, že se na to kašle. Nevím, jestli si vzpomenu dobře, ale říkal něco o překladu maker nebo co. * Podobně kamarád mi nedávno říkal něco podobného. Asi to souvisí s tím, jak se to provádí. Windows programy nejsou tak pěkně na překlad připravené a řetězce se vytahují z binárek speciálním softem atd. Ale to všechno mám jen z doslechu. A myslím, že u většiny open source je to trochu jinak. To s tou terminologií z Mozilly znám. Pojmy se snažíme ladit a je to docela náročné: vybrat správný termín a pak ho ještě na správných místech správně používat. Díky. Jsem učitel a začal jsem s šifrováním a podpisem laborovat právě teď. A ukázky v angličtině nejsou pro moje studenty to pravé.

[Jan Kundrát (jkt)]

Co srovnani podpisu emailu s GPG?

[rastos]

GPG (resp. PGP) pracuje na trocha inom princípe. Osobne ho považujem za príťažlivejšie ako certifikáty, ale jeho podpora v rôznych mailových klientoch je nižšia ... teda ... samozrejme pre mozillu/thunderbird existuje enigmail a tuším funguje aj v kmaili a ďalších linuxových mail-klientoch. Ale v outlooku to nie je ono. (Nie že by som našiel odvahu to skúšať ) Pre PGP existuje tiež celkom dobrá dokumentácia. Najviac sa mi páčili dva textové dokumenty, ktoré boli súčasťou verzie 2.6.x. Jednu zaujímavú pasáž som si dokonca preložil.

Veľa sa dá dočítať aj vo FAQ pre comp.security.pgp ( jedna stará verzia je tu: 1, 2, 3, 4, 5, 6, 7, 8, 9 ) Skrátka som mal pocit, že fungovanie PGP/GPG je medzi linuxákmi, ktorí si vedia pohľadať trocha dokumentácie na googli, dostatočne známe a článok o ňom by bolo nosenie dreva do lesa.

[kowalski]

enigmail česky a enigmail blog

[Jan Kundrát (jkt)]

Rozdily jsou mi principialne jasne (trusted CA vs. model web of trust), mozna by stalo za clanek rozvest oboji.

[lovec]

Hm .. Ako mozes uverejnovat take strasne bludy. Keby som o podpise tusil tak malo ako ty, tak by som nenasiel v sebe odvahu napisat clanok (a podpisat ho, no brr...).

Ak pozabudneme na hroznu terminologiu.. Napisat, ze predtym sa na vypocet hashu pre podpis pouzival algoritmus CRC, alebo uplne suverenne prekrstit SHA256 na SHA2 a pododne [CENSURED].

[rastos]

Hm .. Ako mozes uverejnovat take strasne bludy. Keby som o podpise tusil tak malo ako ty, tak by som nenasiel v sebe odvahu napisat clanok (a podpisat ho, no brr...).

Už v diskusii pri prvej časti som sa Ťa pýtal, či by si bol ochotný urobiť recenziu druhej časti - prv než vyjde. Nereagoval si.

Máš pravdu. Nie som expert na SSL, CA ani X.509. Som len človek, čo pozná PGP a chcel vedieť ako bezpečne komunikovať s inými ľuďmi, pre ktorých používanie PGP/GPG nie je praktické. Niečo som si o tom prečítal, vyskúšal a zafungovalo mi to. Tak som to popísal v článku. Asi z toho neurobím doktorantskú prácu, ale niektorým sa to tu zišlo a páčilo.

CRC - nehovorím, že by sa CRC používal v kontexte elektronického podpisu ako ho chápe zákon či SSL alebo PGP. CRC - cyclic redundancy check - je algoritmus, ktorý sa používal ešte v časoch DOS-u a pkzip-u na overenie toho, že nejaký súbor nebol poškodený - napr. pri chybe čítania z diskety a podobne. Už v polovičke 90 rokov som stretával na unixoch program sum, ktorý slúži na podobné účely.

SHA-2 - wikipedia - The first member of the family, published in 1993, is officially called SHA; however, it is often called SHA-0 to avoid confusion with its successors. Two years later, SHA-1, the first successor to SHA, was published. Four more variants have since been issued with increased output ranges and a slightly different design: SHA-224, SHA-256, SHA-384, and SHA-512 — sometimes collectively referred to as SHA-2.

Na záver zopakujem to čo som Ti povedal už v diskusii k minulej časti: ak nesúhlasíš s niečím čo je v článku, je tu diskusia, v ktorej to môžeme uviesť na pravú mieru.

[GeBu]

Podle způsobu jakým lovec píše bych se vykašlal na něj jakokoliv reagovat. Každý pozná co je zač.

[peko]

Hezký článek, jinak zajímavé info o tom, jak to technicky funguje mají třeba tady: www.digitalni-podpis.cz