Perfect forward secrecy
Školení, která pořádám 
Několik hodin jsem se snažil pochopit, jak přesně funguje Perfect forward secrecy, a většina zdrojů, které jsem nastudoval, mě spíše zmátla. Vzhledem k tomu, že to je vlastně nakonec docela jednoduché, tak bych se o svůj nález chtěl podělit.
Nejprve, jaký problém Perfect forward secrecy řeší? Jde o to, že při běžné TLS komunikaci (používané třeba při HTTPS) je heslo, které se používá pro šifrování komunikace, chráněno soukromým klíčem serveru. Funguje to zhruba takhle:
- Server pošle klientovi svůj veřejný klíč a certifikátem zaručí, že je opravdu od něj.
- Klient si vymyslí nějaké heslo, to si zapamatuje a zároveň ho zašifruje veřejným klíčem serveru, což pošle na server.
- Server si heslo rozšifruje svým soukromým klíčem a dál toto heslo oba používají pro šifrování komunikace.
Nevýhoda tohoto postupu je očividná. Pokud někdo získá soukromý klíč serveru, tak si může dešifrovat veškerou komunikaci mezi ním a všemi jeho klienty. A to nejen pro budoucí komunikace, ale i pro všechny předchozí. Pokud tedy někdo odposlouchává šifrovanou komunikaci serveru a ukládá si ji, tak pokud se mu v budoucnu podaří klíč získat, tak si veškeré uložené komunikace může zpětně rozšifrovat. Jak získá klíč, je celkem jedno, může to být výrazným zlepšením výkonu počítačů, násilím, chybou v systému nebo třeba soudní obsílkou.
Každý článek o Perfect forward secrecy vám řekne, že PFS tohle řeší tím, že server pro každé spojení používá nový pár klíčů, které po ukončení spojení zahodí. Tím pádem při získání master klíče serveru není možné zpětně dešifrovat předchozí komunikaci. Já jsem ale nechápal, jak se tento pár klíčů vytváří. Odvozuje se nějak z master klíče, takže předchozí komunikace sice dešifrovat nejde, ale budoucí půjde, protože jednorázové klíče si bude moci útočník taky odvodit? Odpověď je ne – jednorázový pár klíčů je na master klíči zcela nezávislý. Heslo pro šifrování komunikace si server s klientem vymění pomocí Diffie–Hellmana:
- Server si vygeneruje soukromý klíč a z něj odvozený veřejný klíč pošle klientovi.
- Klient si vygeneruje svůj soukromý klíč a veřejný pošle na server.
- Server spojí svůj soukromý klíč s klientovým veřejným, klient svůj soukromý se serverovým veřejným.
- Díky vlastnostem algoritmu vyjde oběma to samé, což ustanoví za heslo používané pro šifrování další komunikace.
Ve většině článků o PFS jsem taky našel zmínku o eliptických křivkách. Souvisí to spolu nějak, jsou eliptické křivky něčím výjimečné, takže algoritmus funguje díky nim? Odpověď je ne. Eliptické křivky se při výměně klíčů používají hlavně proto, že jsou mnohem rychlejší, takže nás generování klíčů tolik nebolí. Stejně tak dobře by PFS fungovalo i s tradičnějším postupem používajícím násobení velkých prvočísel.
Použití PFS nezamezí držiteli soukromého klíče v útoku Man in the middle. Pokud ale útočník dokáže komunikaci jen odposlouchávat a nedokáže ji usměrňovat, tak mu ani získání vašeho soukromého klíče nepomůže k jejímu rozšifrování. Musel by získat klíč pro každou komunikaci, kterou chce rozšifrovat.
Je smutné, že PFS se začíná více používat až poslední dobou, přestože bylo vynalezeno dokonce dříve než SSL (předchůdce TLS). Google je v této oblasti průkopníkem, který se významně podílel na zahrnutí jeho podpory do OpenSSL a do prohlížečů. Všiml jsem si, že Facebook už PFS také používá, ale třeba servery Microsoftu ještě stále ne. Podpora mezi prohlížečí je už dobrá, takže pokud provozujete server na HTTPS, tak si použití PFS ověřte a případně požádejte o jeho nasazení, server to zatíží jen o trochu navíc.
Technicky zdatnějším čtenářům se omlouvám za případné nepřesnosti a budu rád za doplnění nebo opravu. Článek jsem se snažil napsat pochopitelně i pro laiky.
Diskuse
E:
Pro každé spojení se používá nový pár klíčů? Nemění se spíš jen nějaká passphrase?MW:
Úplně nové klíče. Diffie-Hellman vypadá takto:http://michalwiglasz.cz/files/dh.png
Veřejný klíč bude g a n, soukromé klíče jsou x, y. Pro každou relaci mohou být všechny čtyři hodnoty úplně jiné.
Petr Šťastný:
Doporučuji tento analyzátor SSL, pomůže otestovat a optimalizovat nastavení serveru:https://www.ssllabs.com/ssltest/index.html
Patrik:
Eliptické křivky jsou výjimečné tím, že "nalezení diskrétního logaritmu náhodného elementu eliptické křivky s ohledem na známý základní bod je nemožné". Kdežto algoritmus faktorizace známe, byť je to u velkých čísel s dnešní technikou časově náročný úkol. Ale není nemožný.Samozřejmě máš pravdu v tom, že jsou eliptické křivky úspornější. Někde jsem ale četl, že jsou problémy s patenty.
Martin:
Žádný algoritmus pro faktorizaci není - pokud tedy nepočítáme i bruteforce. A ta časová náročnost není "náročná", je spíš nemožná. Konkrétně jsou to hodně velké násobky staří vesmíru i za předpokladu minimální energetické náročnosti každé operace.
Michal Gebauer:
Jak s tím souvisejí neuronové sítě? Matematika je u šifrování vyřešená předem, k čemu by byla hádací síť lepší oproti bruteforce? K nalezení optimalizací bez použití matematického postupu?
Michal Gebauer: v6ak:
Jsou tu lepší algoritmy než čistý bruteforce. Např. GNFS. Pro přehled: http://en.m.wikipedia.org/wiki/Integer_factorization
A pak tu je Shorův algoritmus pro faktorizaci v O(n^3). Stačí jen mít kvantový počítač a dostatek paměti.
v6ak:
Opravdu jsou EC bezpečnější než RSA? Mám za to, že klasickým počítačům je odolné obojí a kvantovým nejsou odolné ani EC.
MW:
Odolné je obojí, ale EC stačí méně bitů klíče na stejnou bezpečnost.v6ak:
Souhlas s počtem bitů. Ale o to mi tu nešlo. Ony mohou být i jiné relativně drobné (aspoň z dnešního pohledu) rozdíly mezi EC a RSA. Narážel jsem na příspěvek, na který jsem reagoval:
Na klasickém počítači je faktorizace stále asymptoticky exponenciální. (Z popisu na Wikipedii to není úplně zřejmé na první pohled, ale dá se to dokázat. Složitost je evidentně vyšší než e^(x^(1/3)) a to je podle limity podílu pořád exponenciální - viz http://www.wolframalpha.com/input/?i=lim_….0000000000000000000000000001%5ex%29%29.) Sice je potřeba pro obdobnou bezpečnost více bitů, ale dá se to ještě ustát.
Naproti tomu na kvantovém počítači RSA ani EC zcela určitě neobstojí, pokud bude mít dost paměti. Proti RSA máme Shorův algoritmus, který funguje v O(n^3). U EC je situace asi podobná, protože na to existuje modifikovaný Shorův algoritmus pro řešení diskrétního logaritmu: https://en.wikipedia.org/wiki/Elliptic_curve_…_computing_attacks
Birkof:
Moc pěkně popsané. Díky
Martin:
Nevím, ale fakt, že není komunikace odolná proti Man in the middle je podle mě dost podstatný problém. Takový wifi hijack je otázka několika minut a pak už jsou podpisy certifikátů to jediné co stojí v cestě odposlechu.v6ak:
Samotné PFS nezabrání MITM, na to jsou jiné nástroje. To neznamená, že použitím PFS se staneme zranitelní na MITM.
Diskuse je zrušena z důvodu spamu.
© 2005-2024 
