Kolejny ciekawy atak na TLS: kiedy przestaniemy korzystać z szyfru RC4?

Nie pierwszy to raz, kiedy stojący u podstaw bezpieczeństwaInternetu protokół TLS stał się celem udanego ataku kryptografów.W 2002 roku po raz pierwszy wykazano podatność TLS na atakitypu paddingoracle (którego twórczym rozwinięciem jest tegoroczny atakLucky13). W 2011 roku badacze Duong i Rizzo zaprezentowali słynnegoBEAST-a– przeglądarkowy exploit przeciwko SSL/TLS, by rok późniejprzedstawić CRIME – atak wymierzony nie tylko przeciwko połączeniom HTTPS, ale teżi google'owemu SPDY. Biorąc pod uwagę to, że jeszcze w lutym tegoroku jedynie20 procent webowych serwerów stosowało implementacje SSL/TLSodporne na te wszystkie ataki, można powiedzieć, że opowieściwystawców certyfikatów SSL o jakimś niezwykłym bezpieczeństwiegwarantowanym przez „kłódeczkę” przy adresie stronyinternetowej, można między bajki włożyć. A to przecież niekoniec problemów z TLS.Nowy atak, przygotowany przez badaczy AlFardana, Bernsteina,Patersona, Poetteringa i Schuldta nie ma ciekawej nazwy, nazywasię po prostu AlFBPPS (podobno używanie seksownych akronimówstało się passé). Pozornie wydaje się teżdość akademicki – aby go zrealizować, należy przechwycićmiliony połączeń przenoszących takie same dane. Pozwala teżprzechwycić jedynie pierwszych kilkaset bajtów zaszyfrowanychdanych. Jednak jego znaczenie, jak dowodzą autorzy, tkwi w czymśinnym: demonstruje ryzyko stosowania powszechnie wykorzystywanego woprogramowaniu szyfru RC4.Co RC4, szyfr symetryczny (używający tego samego klucza doszyfrowania i deszyfrowania) miałby mieć wspólnego z TLS,bazującym na kryptografii klucza publicznego? Otóż TLS jedynieczęściowo korzysta z kluczy publicznych. Ich wykorzystanie jestzbyt powolne dla całego ruchu sieciowego, więc para kluczyprywatny/publiczny wykorzystywana jest tylko przy inicjalizacjipołączenia i wygenerowaniu losowego klucza, który będziewykorzystywany w symetrycznym szyfrowaniu, obejmującym wszystkiepozostałe dane przesłane po połączeniu. Jaki to szyfr symetryczny– nie jest powiedziane. Jedna z najpopularniejszych implementacjiTLS, OpenSSL, zapewnia m.in. obsługę szyfrów AES, DES, Blowfish iRC4. Ten ostatni, mimo znanych słabości, jest stosowany wciążbardzo często – według autorów nowego ataku, około50 procent całego ruchu TLS w Sieci jest szyfrowana za pomocąRC4. Najwyraźniej twórców oprogramowania nie przejęły specjalnieodkrycia z początku tego stulecia, kiedy to Adi Shamir (ten odszyfru RSA) i Itsik Mantin przedstawili praktycznyatak na RC4 (który później pozwolił na łamanie zabezpieczeńbezprzewodowych sieci WEP w ciągu kilku minut). Problem dotyczyjakości zaszyfrowanego przez RC4 strumienia danych – na początkuwystępuje wiele statystycznych anomalii, które można wykorzystaćdo odczytania zaszyfrowanych danych.[img=crypto_550px]Atak AlFBPPS również wykorzystuje statystyczne anomalie wstrumieniu RC4, na sposób dotychczas niespotykany. Badaczeprzygotowali tablice prawdopodobieństwa wystąpienia każdejwartości bajtowej (od 0 do 255) dla pierwszych 256 pozycjistrumienia (łącznie 65536 pomiarów). Dzięki nim, dysponującodpowiednio dużą próbką strumieni RC4, można zgadnąć kluczwykorzystywany w TLS. Technicznie pozyskanie takiej dużej liczbystrumieni nie jest w warunkach webowych niewyobrażalne (można np.masowo serwować różnym klientom zaszyfrowane ciasteczka), a zupływem lat i rozrastaniem się Sieci będzie coraz łatwiejsze.Paul Ducklin z Sophos Security tak opisuje możliwy scenariuszataku: załóżmy, że wiesz, że 48. bajt jawnego tekstu, P48,jest zawsze taki sam, ale nie wiesz jaki on jest. Inicjujesz więcmiliony połączeń TLS, zawierających to stałe, lecz nieznane P48.W każdym połączeniu, używającym losowo wybranego klucza sesji,P48 zostanie zaszyfrowane za pomocą pseudolosowego bajtu szyfruK48, by uzyskać pseudolosowy bajt szyfrogramu C48. Po pozyskaniumilionów różnych próbek C48, wyobraź sobie, że jedna z wartościC48 pojawia się o 1% częściej niż powinna. Nazwijmytę odchyloną wartość C48 jako C'.Z tabeli prawdopodobieństwa dla K48 odkrywasz, że bajt szyfruużyty do zaszyfrowania P by uzyskać C' to 208, ponieważ K48przyjmuje tę wartość o 1% zbyt często. Innymi słowy wartość C'to P XOR 208, więc wartość P to C' XOR 208 – właśnieuzyskałeś 48 bajt jawnego tekstu.Oczywiście aby tablicaprawdopodobieństw dla RC4 znalazła zastosowanie, liczba zebranychpróbek musi być duża. Dopiero zainicjowanie 2^{32 (4 miliardy)sesji TLS daje prawdopodobieństwo odczytania wszystkich pierwszych256 bajtów na poziomie 1,0 – jednak dobre wyniki można uzyskaćjuż z 2}24 sesji (16 milionów).W zasadzie nie ma powodu, dla któregowciąż w WWW spotyka się serwery korzystające z RC4 –dziś wszystkie nowoczesne przeglądarki pozwalają na wykorzystanieznacznie lepszych kryptosystemów. Ducklin z Sophos Security pyta,czy ktokolwiek spośród administratorów, którzy porzucili wsparciedla TLS-RC4, zauważył przez to jakieś niedogodności? Jak narazie nikt niczego takiego nie zadeklarował – ani na jego blogu,ani w dyskusjach toczących się w innych miejscach Sieci. Możezatem ze słabymi szyframi jest tak, jak z WEP - wciąż korzystająz nich po prostu ci, którzy albo o bezpieczeństwie niewiele wiedzą,albo którym po prostu się nie chce. Najlepszym rozwiązaniembyłoby więc po prostu porzucenie przez producentów przeglądarekwsparcia dla RC4, tak jak w nowych routerach powinno być porzuconewsparcie dla WEP.