TOR wdraża nowy silnik szyfrowania. Po ponad 20 latach nowy mechanizm załata podatność na ataki typu tagging

Każdy z nas, kto choć na chwilę szukał sposobu na zapewnienie anonimowości w sieci, spotkał się zapewne z pojęciem sieci TOR (The Onion Routing). I choć technologia ta pochodzi z lat 90, do chwili obecnej jest szeroko stosowana między innymi przez dziennikarzy, badaczy cyberbezpieczeństwa i każdego kto chce pozostać anonimowy w sieci. 
TLDR:

Dokładna data wdrożenia poprawek nie został opublikowana.

Na oficjalnym blogu Tor Project pojawiła się informacja o planach wdrożenia nowego schematu szyfrowania danych – Counter Galois Onion.

Schemat ma zastąpić znany od ponad 20 lat algorytm tor1.

Wdrożenie poprawek jest konsekwencją ujawnionych słabości w mechanizmie zabezpieczającym transmisję, tj.: podatności na ataki typu tagging, brak forward secrecy oraz przestarzały algorytm zapewniający integralność danych (SHA1).

Aktualizacja obejmowałaby zarówno implementację Tor napisaną w Rust, jak i starszą wersję w C.

Cała sieć opiera się na protokole opracowanym przez Marynarkę Wojenną Stanów Zjednoczonych zwanym trasowaniem cebulowym. I tak jak cebula składa się z warstw, tak samo każdy pakiet danych jest opatrzony warstwą szyfrowania, która zostaje zdejmowana na kolejnych węzłach. Nikt z uczestników komunikacji nie wie skąd pochodzi dany pakiet ani dokąd zmierza. Każdy węzeł zna adres poprzedni i następny – odtworzenie całej drogi pakietu stanowi duże wyzwanie, praktycznie nierealne do osiągnięcia. Aby zobrazować, w jaki sposób działa TOR, warto zapoznać się z poniższą grafiką.

Komunikacja między węzłami jest zabezpieczona protokołem tor1, wykorzystującym algorytm AES-128-CTR do zabezpieczenia poufności danych oraz SHA1 do zapewnienia integralności. 

AES-128-CTR jest algorytmem symetrycznym, działającym w trybie licznikowym. Szyfrowanie polega na wykonaniu operacji XOR między wiadomością P oraz ciągiem klucza AES(K,counter):

C = P XOR AES(K,counter)

Integralność danych gwarantuje algorytm SHA1. Znacznik HS’ jest generowany na podstawie danych pakietu (P) oraz 20 bajtowego wewnętrznego stanu funkcji – HS.

HS’ = SHA1(HS, P) 

Analogiczna procedura występuje na kolejnych węzłach uczestniczących w komunikacji. Warto więc zadać pytanie, to gdzie jest w takim razie słaby punkt? 

Odpowiedź może zaskoczyć, bo takich punktów jest więcej niż jeden, ale po kolei.

Problem 1 – Podatność na ataki typu tagging.

Ataki te polegają na próbach oznaczenia ruchu sieciowego, a mówiąc dokładniej na umieszczeniu wewnątrz wiadomości, na węźle wejściowym znacznika i obserwacji, czy na węźle wyjściowym uda się wykryć zmianę. Jeśli zmiana zostanie zaobserwowana, atakujący ma pewność, że węzły uczestniczą w tym samym obwodzie, a co za tym idzie może skojarzyć adres IP użytkownika z serwerem docelowym (deanonimizacja). 

Protokół tor1 był podatny na ten atak, ponieważ weryfikacja integralności danych odbywa się lokalnie, na każdym z węzłów pośredniczących w komunikacji, bez sprawdzenia czy dane otrzymane od poprzedniego węzła nie zostały zmodyfikowane.

Problem 2 – Brak forward secrecy

Klucz szyfrujący zabezpieczający komunikację jest generowany na początku nawiązania sesji i nie ulega zmianie do momentu zestawienia ponownego połączenia (wylosowanie nowych węzłów pośredniczących w komunikacji). Niesie to za sobą poważne konsekwencje. Jeżeli założymy, że bieżący klucz szyfrujący został przechwycony, atakujący oprócz możliwości podsłuchania aktywnej sesji, może odszyfrować przeszłe transmisje, oczywiście w ramach tego samego obwodu (te same węzły uczestniczące w komunikacji). Sytuacja, w której od aktualnego klucza szyfrującego, zależy bezpieczeństwo poufności przeszłych transmisji jest jawnym naruszeniem forward secrecy.

Problem 3 – Długość taga uwierzytelniającego

Integralność danych została zabezpieczona algorytmem SHA1. Nie jest to najsilniejszy mechanizm, gwarantujący niepodrabialność danych, rekomendowane są bezpieczniejsze funkcje skrótu, jak np. SHA2. Jednak problem leży gdzieś indziej, a mianowcie w liczbie bajtów użytych jako znacznik danych. W protokole tor1 długość znacznika wynosi 4 bajty, mimo iż bezpośrednio z funkcji SHA1 generowane jest 20 bajtów. Daje to atakującemu szansę ok. 1 do 4 miliardów (2^32-1) na pomyślne sfałszowanie pakietu.

W odpowiedzi na powyższe zagrożenia, Tor Project poinformował o zaawansowanych pracach nad wdrożeniem nowego schematu szyfrowania – Counter Galois Onion (CGO).

Counter Galois Onion

Algorytm CGO został opracowany przez kryptografów Jeana Paula Degabriele’a, Alessandro Melloniego, Jeana-Pierre’a Müncha i Martijna Stama. Bazuje na konstrukcji Rugged Pseudorandom Permutation zwanej UIV+.

Jak widzimy na powyższym schemacie, dane wejściowe są dzielone na dwie części, odpowiednio krótsza lewa X_L oraz dłuższa prawa X_R. Część X_L jest podawana na wejście algorytmu E_T (zmodyfikowany AES-128) wraz z parametrem H (stałą predefiniowaną w protokole). Wynik Y_L jest podawany na wejście do PRF (Pseudo Random Function), w wyniku czego generowany jest keystream, zabezpieczający dalszą część wiadomości (XOR z wiadomością X_R). Wynikiem przeprowadzonej operacji jest szyfrogram Y_L || Y_R.

Dużą zmianą w stosunku do algorytmu tor1 jest sposób przetwarzania wiadomości. CGO operuje na całym bloku danych oferując uwierzytelnione szyfrowanie. Ponadto, klucz szyfrujący jest aktualizowany po przetworzeniu każdego bloku danych, a tag uwierzytelniający jest powiązany z poprzednim blokiem. W ten sposób zostało wyeliminowane zagrożenie związane z atakiem typu tagging. Każda nieuprawniona zmiana danych zostaje wykryta, a blok danych odrzucony.

Drugi problem związany z forward secrecy został rozwiązany poprzez aktualizację klucza szyfrującego dla każdego bloku. Przejęcie bieżącego klucza nie pozwala na odszyfrowanie wcześniejszego ruchu. 

Problem słabego mechanizmu integralności danych, został rozwiązany poprzez implementację 16-bajtowego taga uwierzytelniającego, wbudowanego w schemat CGO.

Zainteresowanych szczegółami technicznymi odwołujemy bezpośrednio do dokumentacji autorów.

Aktualizacja nie została jeszcze wdrożona. Zgodnie z informacjami opublikowanymi przez Tor Project, obecnie trwają zaawansowane prace nad integrowaniem rozwiązania w obu głównych wersjach Tor, zarówno w implementacji Arti (Rust) jak i w starszej wersji napisanej w C. Z punktu widzenia użytkowników, zmiana będzie praktycznie nieodczuwalna. 

Źródło: blog.torproject.org, eprint.iacr.org.

~_secmike