╚ßst 47 - CW 16/98

BezpeΦnΘ komunikaΦnφ protokoly

AΦkoliv byly protokoly rodiny TCP/IP vyvφjeny pro Ministerstvo obrany USA, jejich hlavnφm cφlem nebylo zajiÜt∞nφ bezpeΦnΘ komunikace, ale hlavn∞ co nejv∞tÜφ odolnost proti v²padk∙m Φßstφ komunikaΦnφch sφtφ (v potencißlnφ vßlce by byly toti₧ nejd°φve zniΦeny hlavnφ komunikaΦnφ uzly).

Ve ve°ejnΘ sφti je proto nutnΘ provozovat bezpeΦnostnφ protokoly a₧ na vrstvßch vyÜÜφch ne₧ je vrstva IP (privßtnφ sφt∞ mohou pou₧φvat i bezpeΦnostnφ protokoly na ni₧Üφ ·rovni ne₧ TCP/IP).

BezpeΦnostnφ protokoly se musφ vyrovnat v prvnφ °ad∞ s nßsledujφcφmi ·koly:

- zajistit d∙v∞rnost spojenφ,

- umo₧nit ov∞°enφ identity komunikujφcφch stran (autentizaci),

- zajistit integritu dat.

Secure Socket Layer (SSL verze 3.0)

SSL je bezpeΦnostnφ protokol navr₧en² firmou Netscape. Tento protokol je mo₧nΘ za°adit do relaΦnφ vrstvy modelu OSI. Je mo₧nΘ jej provozovat nad jakoukoliv spolehlivou spojovanou slu₧bou (nap°. TCP). SSL domlouvß bezpeΦnostnφ parametry b∞hem ustavovßnφ spojenφ. Kdy₧ spolu klient a server zaΦφnajφ komunikovat, musφ si dohodnout p°edevÜφm kryptografickΘ parametry, verzi protokolu, metodu p°edßnφ tajn²ch klφΦ∙ pomocφ Üifrovacφho algoritmu s ve°ejn²m klφΦem a voliteln∞ se mohou autentizovat. Tato fßze se naz²vß SSL Handshake protokol. P°edßvßnφ zprßv mezi klientem a serverem je ve standardizovanΘ podob∞ na obrßzku 1 a ve zjednoduÜenΘ podob∞ na obrßzku 2.

1. Klient poÜle zprßvu ClientHello. Zprßva obsahuje verzi protokolu, ΦasovΘ razφtko, nßhodnΘ Φφslo (o velikosti 28 byt∙), identifikaci relace a seznam podporovan²ch Üifrovacφch a kompresnφch metod. Server odpovφ pomocφ zprßvy ServerHello, kterß obsahuje verzi protokolu, identifikaci relace a zvolenou metodu Üifrovßnφ a komprese.

2. Server mß mo₧nost voliteln∞ poslat 3 druhy zprßv:

╖ Certificate -- v p°φpad∞, ₧e mß b²t server autentizovßn, poÜle svΘ certifikßty klientovi k ov∞°enφ svΘ identity.

╖ CertificateRequest -- neanonymnφ server m∙₧e po₧adovat po klientovi certifikßty jeho identity, vydanΘ r∙zn²mi certifikaΦnφmi autoritami.

╖ ServerKeyExchange -- tuto zprßvu server posφlß v p°φpad∞, ₧e nemß ₧ßdn² certifikßt, nebo mß certifikßt pou₧iteln² pouze k podepisovßnφ. Obsahuje identifikßtor kryptografickΘho algoritmu, kter² bude pou₧it pro v²m∞nu tajn²ch klφΦ∙, a parametry tohoto algoritmu (ve°ejn² klφΦ).

3. Server ukonΦφ tuto fßzi pomocφ zprßvy ServerHelloDone.

4. Klient vygeneruje tajn² klφΦ relace a poÜle zprßvu ClientKeyExchange, kterß tento klφΦ obsahuje (zaÜifrovan² pomocφ algoritmu ve°ejnΘho klφΦe).

5. Pokud server po₧adoval certifikßty, pak je zaÜle (zprßva Certificate). Pokud mß certifikßt podepisovacφ schopnosti, pak poÜle podepsan² obsah p°edchßzejφcφch zprßv (zprßva CertificateVerify).

6. Klient poÜle zprßvu ChangeCypherSpec a nastavφ Üifrovacφ a podpisovacφ algoritmy.

7. Klient poÜle zprßvu Finished ji₧ zaÜifrovanou tajn²m klφΦem.

8. Server poÜle zprßvu ChangeCypherSpec a nastavφ Üifrovacφ a podpisovacφ algoritmy.

9. Server poÜle zprßvu Finished ji₧ zaÜifrovanou tajn²m klφΦem.

V tΘto chvφli ji₧ probφhß mezi ob∞ma stranami bezpeΦnß komunikace. Protokol umo₧≥uje zm∞nu zp∙sobu Üifrovßnφ a v²m∞nu dalÜφch certifikßt∙ kdykoliv v pr∙b∞hu komunikace. (Certifikßt je v∞tÜinou ve°ejn² klφΦ majitele, spolu s dalÜφmi informacemi identifikujφcφmi vlastnφka, podepsan² n∞jakou certifikaΦnφ autoritou. Certifikßty se bude zab²vat n∞kter² z dalÜφch dφl∙ tohoto serißlu). Protokol SSL ne°eÜφ ov∞°ovßnφ platnosti certifikßt∙, tato zßle₧itost m∙₧e b²t implementaΦn∞ zßvislß.

Jak je vid∞t, protokol definuje rßmec, kter²m probφhß bezpeΦnß komunikace. Protokol nevy₧aduje vyu₧itφ specifick²ch Üifrovacφch a autentizaΦnφch metod. Jsou zde definovßny n∞kterΘ zßkladnφ typy:

- v²m∞na klφΦ∙: Diffie-Hellman a RSA v kombinaci s DSS (Digital Signature Standard) nebo Fortezza (neve°ejn² algoritmus);

- symetrickΘ Üifrovacφ algoritmy: IDEA, RC2, RC4, DES, 3-DES, Fortezza;

- haÜovacφ funkce (pou₧itΘ pro kontrolu integrity dat): MD5, SHA nebo kombinace obou.

V souΦasnosti se SSL pou₧φvß hlavn∞ pro bezpeΦnΘ http (https), je mo₧nΘ takΘ pou₧φvat bezpeΦnΘ SMTP (ssmtp) nebo NNTP (snntp). SSL vÜak nenφ omezen jen na tyto slu₧by.

N∞kterΘ nedostatky

BezpeΦnost tohoto protokolu zßle₧φ na tom, jakΘ parametry si spolu klient se serverem dohodnou. V p°φpad∞, ₧e je umo₧n∞na neautentizovanß komunikace, je bezpeΦnost ohro₧ena pomocφ ·toku typu man-in-the-middle. Navφc n∞kterΘ Üifrovacφ algoritmy pou₧φvajφ pouze 40bitovΘ klφΦe, co₧ m∙₧e vΘst ke snadnΘmu prolomenφ klφΦe.

Protokol takΘ umo₧≥uje p°ejφt ke komunikaci pomocφ starÜφ verze (SSL 2.0). Verze 2.0 umo₧≥ovala ·toΦnφkovi (man-in-the-middle) modifikovat n∞kterΘ zprßvy tak, aby si komunikujφcφ strany dohodly Üifru s co nejmenÜφm klφΦem. Zßle₧φ tedy pouze na aplikaci, zda povolφ p°echod k verzi 2.0 nebo ne. V²zva k rozlomenφ SSL verze 2.0 byla ·sp∞Ün∞ dokonΦena po 8 dnech rozlomenφm zprßvy hned dv∞ma t²my (v rozmezφ 2 hodin). (http://pauillac.inria.fr/~doligez/ssl/).

Tento protokol takΘ obsahuje patentovanΘ algoritmy (RSA), co₧ m∙₧e zp∙sobit problΘmy p°i implementaci. Platnost patentu pro algoritmus Diffie-Hellman vÜak ji₧ vyprÜela.

PCT (Private Communication Technology)

Je to velmi podobn² protokol od firmy Microsoft. Pou₧φvß stejn² zßkladnφ formßt jako SSL, tak₧e server m∙₧e rozliÜit mezi t∞mito dv∞ma protokoly, pokud jsou pou₧φvßny souΦasn∞. Hlavnφ rozdφly jsou p°edevÜφm ve v²m∞n∞ zprßv p°i handshake protokolu a odd∞lenφ autentizaΦnφch klφΦ∙ od Üifrovacφch.

SHTTP (verze 1.4)

Jednß se o protokol, kter²m je mo₧nΘ zabezpeΦit komunikaci pomocφ HTTP. Byl vytvo°en tak, aby byl snadno integrovateln² s HTTP a je s nφm kompatibilnφ. SHTTP je protokol na aplikaΦnφ ·rovni a je na rozdφl od SSL, kter² po celou dobu komunikace udr₧uje spojenφ mezi stranami, protokol typu dotaz-odpov∞∩ (co₧ m∙₧e b²t v²hodnΘ).

SHTTP zprßvy jsou syntakticky stejnΘ jako zprßvy HTTP a sklßdajφ se z po₧adavku nebo stavovΘho °ßdku, nßsledovan²m hlaviΦkami a t∞lem zprßvy.

SHTTP poskytuje pro zabezpeΦenφ zprßvy 3 zßkladnφ mo₧nosti: digitßlnφ podpis, autentizaci a Üifrovßnφ. Protokol SHTTP nenφ zßvisl² na urΦitΘm druhu algoritm∙ a umo₧≥uje pou₧φvat r∙znΘ metody p°edßvßnφ klφΦ∙ a certifikßt∙.

Podepisovßnφ se dosahuje pomocφ certifikßt∙, kterΘ mohou b²t souΦßstφ zprßvy, nebo mohou b²t doruΦeny nezßvisle na zprßv∞. Agenti musφ podporovat algoritmus DSS (Digital Signature Standard).

Autentizace a integrita zprßvy je zajiÜt∞na pomocφ haÜovacφ funkce (MAC). Agenti musφ podporovat algoritmus MD5 a RSA-MD5-HMAC (HMAC je bezpeΦn∞jÜφ haÜovacφ funkce).

èifrovßnφ zprßvy je zajiÜt∞no symetrick²mi Üiframi. Pou₧itelnΘ jsou jak proudovΘ, tak blokovΘ Üifry. BlokovΘ Üifry se v∞tÜinou pou₧φvajφ v re₧imu CBC (Cipher Block Chaining). Agenti musφ podporovat DES-CBC.

V²m∞na klφΦ∙ m∙₧e b²t zajiÜt∞na bu∩ p°φmo pomocφ algoritm∙ ve°ejnΘho klφΦe, nebo je mo₧nΘ tajn² Üifrovacφ klφΦ vym∞nit jin²mi metodami nezßvisl²mi na SHTTP. Jako algoritmy ve°ejnΘho klφΦe se pou₧φvajφ Diffie-Hellman a RSA.

V²hodou protokolu SHTTP je to, ₧e protokol je navr₧en tak, aby bylo mo₧no pou₧φt proxy. Nev²hodou naopak z∙stßvß, ₧e tento protokol je svßzßn s protokolem HTTP a nelze jej pou₧φt pro jin² druh p°enosu.

Zßv∞rem

AΦkoliv existujφ i dalÜφ protokoly pro bezpeΦnou komunikaci, je zejmΘna SSL hojn∞ pou₧φvßn a podporovßn hlavn∞ ve webov²ch aplikacφch a zatφm mß podstatn² nßskok p°ed ostatnφmi protokoly na svΘ ·rovni. V²razn∞jÜφ zm∞ny m∙₧e v budoucnu p°inΘst protokol TLS (Transport Layer Security) p°ipravovan² WWW konzorciem. My se ale v p°φÜtφ Φßsti serißlu podφvßme na specializovan² protokol SET pro elektronickΘ platby na bßzi platebnφch karet.