XADM: Jak funguje protokol SSL (Secure Sockets Layer)

Překlady článku Překlady článku
ID článku: 245152 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Tento článek poskytuje přehled o funguje protokol SSL (Secure Sockets Layer) (SSL).

Další informace

Úvod k Key Cryptography

Kryptografie veřejného klíče RSA (Rivest-Shamir-Adleman) je široce používá pro ověřování a šifrování v počítači průmyslu. Netscape má licenci kryptografie RSA s veřejným klíčem z RSA Data Security Inc. pro použití v jeho produkty speciálně pro ověřování.

Šifrování pomocí veřejného klíče je technika používá dvojici asymetrické klíče pro šifrování a dešifrování. Každé dvojice klíčů se skládá z veřejného klíče a soukromý klíč. Veřejný klíč provedené široce veřejné, kdy je jej distribuovány. Nikdy distribuovány soukromý klíč; ji vždy zachována tajný.

Data zašifrována pomocí veřejného klíče lze dešifrovat pouze pomocí soukromého klíče. Naopak lze data zašifrována pomocí soukromého klíče dešifrovat pouze pomocí veřejného klíče. Vlastnost, díky kryptografie s veřejným klíčem proto užitečné je tento asymmetry.

Pro ověřování pomocí Public Key Cryptography

Ověřování je proces ověření identity, takže jednu entitu můžete být jisti identity jiné entitě. V následujících příkladech uživateli a uživatel B pomocí kryptografie s veřejným klíčem ověřit identitu uživatel B. Následující zápis označuje položka byla šifrovány nebo dešifrovány pomocí kryptografie s klíčem
{something}key
something je popis zboží, který byl šifrovány nebo dešifrovány a key je klíč používaný k šifrování nebo dešifrování dané položky.

V následujícím příkladu má uživateli chce uživatel B User B. ověřovat dvojici klíčů jeden veřejné a privátní. Uživatel B zobrazí veřejný klíč k uživateli (Toto je popsána v tomto článku v části "Předávání mimo veřejných klíčů"). Uživatel A generuje náhodné zprávu a odešle ji způsobem uživatel B:
SE-> Brandom_message
Uživatel B použije k zašifrování zprávy náhodné soukromý klíč a vrátí šifrované verze uživatele A:
B-> SE {random_message}User_B's_private_key
Uživatel A obdrží tuto zprávu a dešifruje pomocí veřejného klíče, který uživatel B dříve publikován. Uživatel A porovná dešifrované zprávy s zprávu uživateli původně odeslána uživatel B; Pokud zprávy odpovídat, uživateli ví, že novější zpráva pochází od uživatel B, protože imposter pravděpodobně z důvodu by neznáte soukromý klíč uživatel B a tak by nemohl správně zašifrování náhodné zprávy odeslat uživateli A.

Další oblasti, které je třeba vzít v úvahu

Pokud víte přesně co jste jsou šifrování je nikdy vhodné něco zašifrovat pomocí soukromého klíče a odeslat jej jinému uživateli. Je to proto, že jste může být uchovávány zodpovědný za šifrované hodnotu (Nezapomeňte, že pouze šifrování lze provést, protože máte pouze soukromý klíč).

Proto v tomto příkladu namísto šifrování původní zprávu, že uživateli odeslán uživatel B konstrukce výtah ze zprávy a zašifruje, že výtah ze zprávy. Výtah ze zprávy je odvozen z původní zpráva náhodné a má následující vlastnosti užitečné:
  • Digest je obtížné stornovat. Někdo pokusu zosobnit uživatel B nelze určit původní zprávu z digest.
  • Impersonator má potíže při hledání jinou zprávu, která vypočítá stejnou hodnotu algoritmu digest.
Uživatel B je chráněn pomocí výtah. Uživatel B vypočítá výtah náhodné zpráva, že uživateli odeslány a šifruje výsledek. Uživatel B odešle zpět šifrované výtah uživatele A. uživateli lze vypočítat stejné digest a uživatel B ověření dešifrování zprávy uživatel B a porovnání hodnoty.

Původní data pro ověřování

Postup popsaný v tomto článku v části "Další otázky" je znám jako digitální podpis. Tento postup vyžaduje, aby uživatel B zprávu podepsat, že uživateli generovány; Toto je téměř jako nebezpečné pro uživatel B jako šifrování náhodnou hodnotu pochází uživatele A. Následkem toho tento protokol ověřování příklad vyžaduje jeden krok být zabezpečené; uživatel B potřebuje pocházejí některé (nebo všechna) data způsobem:
Jste uživatel B A B B-> hello-> jsou? Uživatel A, to je {User BdigestB] [uživatel A, to je uživatel} User_B's_private_key
Když uživatel B používá tento protokol, uživatel B ví, co zpráva je odesílán uživateli a proto může uživatel B bezpečně podepsat zprávu. Uživatel B odešle nejprve nezašifrované verzi zprávy "uživateli, je tento uživatel B," a uživatel B pak odešle verze digested zašifrovány. Uživatel A lze snadno ověřit uživatel B je uživatel B a uživatel B nemusí podepsat nic nebylo vytvořeno s uživateli B.

Předávání mimo veřejných klíčů

Jak může uživatel ruky mimo veřejný klíč zabezpečeným způsobem? Následuje příklad ověřovací protokol pro uživatele B:
SE-> B B-> SE-> B B-> SE
Ahoj, Zdravím dochází uživatel B User_B's_public_key prokázat uživateli, je tento
Uživatel B {digest [uživateli, tento uživatel B je]} User_B's_private_key
Pokud je použit tento protokol, kdokoli může zosobnit uživatele B. Imposter je musí mít veřejný a soukromý klíč. Imposter může ležet uživateli a uživatel B zosobnit poskytnutím imposter jeho vlastní veřejný klíč namísto uživatel B veřejný klíč. Potom imposter "prokazuje" imposter je něco zašifrováním pomocí soukromého klíče imposter uživatel B a uživateli nelze zjistit, imposter není uživateli B.

Chcete-li tento problém vyřešit, má komunity standardy invented objekt nazývá certifikát. Certifikát obsahuje následující informace:
  • Název vystavitele certifikátu.
  • Entita, pro kterého je certifikát, právě vydán (známé také jako předmět).
  • Veřejný klíč předmět.
  • Některé časová razítka.
Certifikát je podepsán pomocí soukromého klíče certifikátu vystavitele. Everyone zná veřejný klíč vystavitele certifikátu (to znamená, že certifikát vystavitele také má certifikát). Certifikáty jsou standardní metoda svázat název veřejného klíče.

Pokud je použita technologie certifikát everyone můžete zkontrolovat uživatel B certifikátu naleznete, pokud forged certifikát. Pokud uživatel B udržuje těsné řízení soukromý klíč a uživatel B skutečně získá certifikát, je certifikát technologii zabezpečený. Amended protokolu pomocí tento postup je následující:
A B B-> A B B->->-> Ahoj, Zdravím, jsem uživatel BUser_B's_certificate prokázat
jej uživateli, tento je uživatel B {digest [uživateli, tento uživatel B je]} User_B's_private_key
Jakmile uživateli přijme první zprávu uživatel B mohou uživateli prozkoumejte certifikát, zkontrolujte podpis (jako v předchozím příkladu, pomocí algoritmu digest a dešifrování veřejných klíčů) a potom zkontrolujte předmět (tj. uživatel B název) a zobrazit, že je ve skutečnosti důvěryhodnosti veřejný klíč je veřejný klíč uživatel B potom může uživatel uživateli B. a mohou požadovat ověření totožnosti uživatel B.

Uživatel B projde stejným procesem jako ohraničená v předchozím příkladu navrhování výtah ze zprávy a reagovat na uživateli s podepsané verzí digest. Uživatel může ověřit uživatel B výtah ze zprávy pomocí veřejného klíče z certifikátu a kontrole výsledku.

Osoba chtít ovlivňovat zabezpečenou komunikaci (v tomto příkladu uživatel C) můžete vytvořit následující scénář zkuste provést:
A-> C C-> A C C->-> Ahoj, Zdravím, jsem uživatel BUser_B's_certificate prokázat
jej???
Uživatel C však nemůže splnit uživateli v poslední zprávu. Uživatel C nemá uživatel B soukromý klíč, takže C uživatele nelze sestavit zprávu uživateli bude domníváte pochází z uživateli B.

Výměna skrytá

Po uživateli byl ověřen uživatel B, můžete uživateli odeslat uživatel B zprávu může pouze uživatel B způsobem dekódování
SE-> B {secret}User_B's_public_key
kde je jediným způsobem, jak určit secret dešifrováním výše zprávu pomocí soukromého klíče uživatel B. Výměna tajný klíč je jiným způsobem výkonné použití kryptografie s veřejným klíčem. I Pokud pozorované komunikaci mezi uživateli a uživatel B nikdo ale uživatel B mohou určit tajné informace.

Zvyšuje účinnost předávání tuto techniku informací zabezpečení Internetu pomocí tajný klíč jako jiný klíč, ale v tomto případě je klíč symetrický šifrovací algoritmus, například Data Encryption Standard (DES), RC4 nebo KONCEPTU. Uživatel A zná tajný klíč, protože uživateli před odesílání uživatel B User B. zná tajný klíč, protože uživatel B má soukromý klíč a uživatele A zprávu může dešifrovat tajný klíč generován. Protože uživateli a uživatel B znát tajný klíč, mohou oba spustit symetrický šifrovací algoritmus a pak odesílat zprávy zašifrované pomocí algoritmus symetrického šifrování. Revidované protokol, který používá tento postup je následující:
A B B->-> A B B-> A B B-> Ahoj, Zdravím->->, jsem uživatel BUser_B's_certificate
prokázat uživateli, tento je uživatel B {digest [uživateli, tento uživatel B je]} User_B's_private_key
pořádku uživatel B je zde tajný klíč {secret} User_B's_public_key {some_message} secret_key
Metoda slouží k výpočtu secret_key je až do protokolu je definovaného ale secret_key jednoduše lze kopii tajný klíč.

Rušení zabezpečení

I když jsou použity všechny předchozí postupy, osoba, která chce ovlivňovat zabezpečenou komunikaci (User C) pravděpodobně možné provést. Ačkoli C uživatele nelze zjistit tajný mít vyměňovaných uživateli a uživatel B, C uživatele může ovlivňovat jejich konverzace podle re-arranging (nebo garbling) tajné informace. Například pokud uživatel C sedící mezi uživateli a uživatel B, C uživatele lze předat většinu informací o tam a zpět beze změny, ale garble určité zprávy (Toto je snadné uživatel C provést, protože uživatel C ví, že uživateli protokol a uživatel B se komunikovat pomocí):
SE-> C C-> B B C C->-> SE-> C C-> B B C C->-> SE-> C C-> B B C C->-> SE
Ahoj Ahoj, Zdravím, jsem uživatel B User_B's_certificate Hi, jsem uživatel B
User_B's_certificateprokázat prokázat jej uživateli, je to User {digest [uživatelské_jméno A, B
Toto je uživatel B]} User_B's_private_key uživateli, tento je uživatel B {digest [uživateli, je tento
Uživatel B]} User_B's_private_key ok uživatel B, zde je tajný klíč {secret} User_B's_public_key
pořádku uživatel B je zde tajný klíč {secret} User_B's_public_key {some_message} secret_key
Garble [{some_message} secret_key]
Uživatel C předává data bez úprav, dokud uživateli a uživatel B sdílet tajný klíč. Potom uživatel C garbles uživatel B zprávu uživateli A. V tomto okamžiku může uživateli vztahy důvěryhodnosti uživatel B, takže uživateli domníváte poškozenými zprávy a zkuste jej vyřídit. Poznámka: C uživatel znát tajný klíč; lze provést všechny uživatele C je poškození dat šifrování s tajným klíčem. V závislosti na protokol C uživatele může způsobit není platná zpráva, ale C uživatelů může získat šťastná a vyrobit platná zpráva.

Chcete-li zabránit tento druh poškození, uživateli a uživatel B lze kód ověřování zprávy do zavádět jejich protokol. Kód zpráva ověřování je část dat pomocí tajného a některé přenášených dat, je vypočítávána. Algoritmus digest, popsané výše má právě pravém vlastnosti pro vytváření zpráva kód funkce ověřování, která lze chránit proti C: uživatele
message_authentication_code: = digest [some_message, secret]
Protože User C neví tajný klíč, C uživatele nelze vypočítat správnou hodnotu digest. I v případě, že uživatel C náhodně garbles zprávy, je malé, pokud existuje velké množství dat výtah šancí na úspěch. Například pomocí MD5 (dobrý kryptografický algoritmus digest algoritmus invented RSA), uživateli a uživatel B může odeslat zprávu 128bitové hodnoty kód ověřování s jejich zprávy. Pravděpodobnost uhodnutí kód správné zprávy ověřování uživatelů C jsou přibližně 1 v 18,446,744,073,709,551,616. Pro všechny praktické účely nelze uhodnout User C kód ověřování správné zprávy.

Protokol příklad revidován znovu použít tento postup je následující:
A B B-> A B B->->-> Ahoj, Zdravím, jsem uživatel BUser_B's_certificate prokázat
jej uživateli, tento je uživatel B {digest [uživateli, tento uživatel B je]} User_B's_private_key pořádku
Uživatel B, zde je tajný klíč {secret} User_B's_public_key {some_message, message_authentication_code} secret_key
Můžete se pokusit garble zprávy uživatel C, ale výpočty kód ověřování zprávy odhalit zprávy není pocházet z uživatelů uživateli B. nebo uživatel B můžete zjistit hodnotu kód ověřování nesprávnou zprávu a zastavit komunikace. Uživatel C již zosobnit uživatele B.

Vlastnosti

ID článku: 245152 - Poslední aktualizace: 28. října 2006 - Revize: 3.3
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Klíčová slova: 
kbmt kbinfo KB245152 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:245152
Právní omezení pro obsah znalostní báze týkající se produktů, jejichž podpora byla ukončena
Tento článek byl napsán o produktech, pro které společnost Microsoft již neposkytuje nadále podporu. Článek je tedy nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.

Dejte nám zpětnou vazbu

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com