Co łączy te dwa algorytmy szyfrujące i sprawia, że są one podatne na atak mogący prowadzić do odczytania szyfrowanej komunikacji TLS, SSH czy IPsec? O tym dowiecie się w tym wpisie.

64-bitowe bloki w szyfrach blokowych

Wśród szyfrów symetrycznych (dane szyfrowane i deszyfrowane są tym samym kluczem) wyróżniamy ich dwa główne rodzaje: szyfry blokowe i strumieniowe. Atak dotyczy tych pierwszych i to na nich się skupmy.

Szyfry blokowe, tak jak sugeruje ich nazwa, w celu zaszyfrowania danych dzielą je na bloki o stałej długości. Bloki te w zależności od algorytmu mogą przyjmować różne długości. W większości sytuacji dane do zaszyfrowania nie mieszczą się w jednym bloku. Dane dzielone są więc na odpowiednią ilość bloków, a w celu zmniejszenia ryzyka skutecznej kryptoanalizy stosuje się tzw. tryby pracy szyfrów blokowych. Określają one sposób w jaki szyfrowane są kolejne bloki tekstu jawnego. Jednym z pierwszych, ale ciągle jeszcze popularnym trybem jest CBC (ang. Cipher Block Chaining).

I właśnie zbyt krótka, bo tylko 64-bitowa długość bloków wejściowych dla szyfrowanych danych otwiera drogę do ataku nazwanego Sweet32 (o genezie nazwy później). Wśród podatnych szyfrów, oprócz tych wymienionych w tytule, znajdują się także praktycznie niewykorzystywane dziś DES i IDEA. Na atak nie jest narażony najpopularniejszy obecnie szyfr blokowy AES, który wykorzystuje bloki 128-bitowe.

Jak działa atak?

Szyfrując dużą ilość danych przy pomocy algorytmu blokowego istnieje ryzyko, że za którymś razem otrzymamy ten sam szyfrogram (zaszyfrowane dane) dla bloku tekstu jawnego, który otrzymaliśmy jakiś czas wcześniej. Innymi słowy, wystąpi kolizja. Wystąpienie kolizji uzależnione jest właśnie od długości bloków, im są one krótsze tym ryzyko kolizji większe.

Badacze, wykorzystując paradoks dnia urodzin, udowodnili, że po przetworzeniu przy użyciu 3DES CBC w przybliżeniu 2ˆ32 bloków wiadomości o długości 64-bitów możemy spodziewać się występowania kolizji. Samo natrafienie na kolizję nie daję oczywiście z automatu możliwości czytania tekstu jawnego. Wymagane jest wykonanie dodatkowych operacji (zależnych od trybów z których korzysta danych szyfr czy znajomości struktury tekstu jawnego), które jak przedstawiają w swojej pracy badacze, są do zrobienia w rozsądnym czasie w rzeczywistym środowisku.

Warto zauważyć, że w ataku nieistotna jest długość stosowanych kluczy szyfrujących, a jedynie stosowana długość bloków. Dlatego na atak narażony jest 3DES stosujący 168-bitowy klucz czy Blowfish z kluczem 256-bitowym.

Realne zagrożenie?

Atak, bez wątpienia, jest ciekawy. Jednak, żeby powiódł się w praktyce muszą zostać spełnione nietrywialne warunki (mowa o ataku na TLS):

1. Konieczność wynegocjowania przez klienta i serwer szyfru działającego na 64-bitowych blokach.
2. Możliwość zbierania danych z szyfrowanej sesji przez długi czas. Chodzi o to, żeby cała sesja szyfrowana była przy użyciu tego samego klucza. W swoich testach badacze wykorzystali złośliwy skrypt napisany w Javascripcie do zebrania wystarczającej ilości danych (610 GB), które pozwoliły im na odczytanie ciasteczka sesyjnego (zajęło im to około 30 godzin).

Pierwszy z nich ma duże szanse powodzenia pod warunkiem, że zarówno klient jak i serwer używają starego oprogramowania. Przy użyciu najnowszych wersji przeglądarek z 10 000 najpopularniejszych domen 226 pozwoliło na wynegocjowanie 3DES w połączeniu SSL/TLS. Z tych 226 tylko 72 pozwoliły na zebranie niezbędnej ilości danej tj. na wysłanie około 800 000 żądań w tej samej sesji. Szacunkowo daje to 0.6% narażonych połączeń.

Spełnienie drugiego warunku często jest ograniczone przez konfigurację serwera, a dadatkowo wymaga dostępu do ruchu sieciowego ofiary i możliwości zaserwowania mu złośliwego skryptu.

Co ciekawe, wśród podatnych systemów znalazł się popularny OpenVPN, który domyślnie korzystał z Blowfish. Praca francuskich naukowców spowodowała także m.in. rezygnację ze wsparcia dla 3DES w OpenSSL (od wersji 1.1.0).

Jak zminimalizować ryzyko? Najbardziej oczywistym sposobem jest wyłączenie blokowych szyfrów operujących na kluczach 64-bitowych (3DES, Blowfish) lub chociaż usunięcie ich na dalszy plan (priorytetyzacja szyfrów). Drugi sposób do ograniczenie ilości żądań, które mogą zostać przesłane do serwera w jednej sesji.

Podsumowanie

Atak Sweet32, choć z pewnością nie jest prosty do wykonania, obnaża słabości szyfrów blokowych stosujących zbyt krótkie bloki na które dzielone są dane wejściowe. Dzięki przedstawionym w pracy wynikom wiemy, że istnieje możliwość złamania, teoretycznie bezpiecznego, szyfrowanego kanału, a to zawsze wywołuje pewne zaniepokojenie. Dodatkowo, tego rodzaju ataki są często optymalizowane co czyni je coraz bardziej praktycznymi.

Na koniec jeszcze obiecane wyjaśnienie nazwy Sweet32. Powstała ona na bazie gry słów. W Ameryce Północnej 16 urodziny, będące krokiem w dorosłość, nazywane są sweet sexteen. Jako, że w swoim odkryciu badacze wykorzystali atak urodzinowy, który okazywał się być skuteczny po 2ˆ32 prób to nazwali go Sweet32.

—

Źródła:

[1] https://sweet32.info/SWEET32_CCS16.pdf

[2] https://sweet32.info/

[3] http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html