Ataki typu replay i luki związane z ponownym użyciem nonce

Nonce (liczba użyta raz) gwarantuje, że ta sama wiadomość w postaci tekstu jawnego zaszyfrowana dwukrotnie wygeneruje różne szyfrogramy. Jest to niezbędne dla bezpieczeństwa semantycznego: atakujący obserwujący wiele szyfrogramów nie uzyskuje informacji o tym, czy szyfrują one takie same, czy różne teksty jawne. W szyfrach strumieniowych i szyfrach blokowych w trybie CTR nonce inicjuje generowanie strumienia klucza, dlatego ma kluczowe znaczenie dla bezpieczeństwa.

W AES-GCM nonce o długości 96 bitów służy do zainicjowania licznika dla szyfrowania w trybie CTR, a także uczestniczy w obliczaniu uwierzytelnienia GHASH. Wartość licznika dla każdego bloku AES jest uzyskiwana przez zwiększanie wartości początkowej wyprowadzonej z nonce. Jeśli dwa szyfrowania używają tego samego nonce i klucza, generują ten sam strumień klucza, przez co XOR ich szyfrogramów jest równy XOR ich tekstów jawnych.

Dwa szyfrogramy GCM zaszyfrowane przy użyciu tej samej pary (klucz, nonce): ich XOR jest równy XOR tekstów jawnych. Jeśli atakujący zna jeden tekst jawny, co często zdarza się w scenariuszach z wybranym tekstem jawnym, natychmiast odzyskuje drugi. Nawet bez znajomości tekstu jawnego XOR szyfrogramów ujawnia wzorce językowe i może być analizowany za pomocą technik crib-dragging. Jest to jeden z najbardziej katastrofalnych wzorców niewłaściwego użycia kryptografii.

Ponowne użycie nonce w GCM ma dodatkową katastrofalną konsekwencję wykraczającą poza odzyskanie tekstu jawnego. Klucz uwierzytelniający GHASH, H, jest wyprowadzany wyłącznie z klucza szyfrującego. Jeśli dwie wiadomości współdzielą parę (klucz, nonce), atakujący może rozwiązać równania wielomianowe i odzyskać H. Znając H, atakujący może tworzyć prawidłowe tagi uwierzytelniające GCM dla dowolnych szyfrogramów, całkowicie łamiąc integralność wiadomości.

TLS 1.3 uwzględnia ryzyko ponownego użycia nonce występujące w implementacjach TLS 1.2. TLS 1.3 generuje nonce GCM przez wykonanie XOR na 12-bajtowym IV zapisu, wyprowadzonym z uzgadniania połączenia, oraz 8-bajtowym numerze sekwencyjnym, rozszerzonym zerami do 12 bajtów. Ponieważ numery sekwencyjne zwiększają się dla każdego rekordu, każdy rekord używa unikalnego nonce. Eliminuje to ryzyko związane z losowym generowaniem nonce, a jednocześnie zapewnia unikalność nonce za pomocą mechanizmu numerów sekwencyjnych.

Atak typu replay polega na przechwyceniu prawidłowej wiadomości lub tokenu uwierzytelniającego i retransmisji w późniejszym czasie w celu wywołania oszukańczego skutku. Przykłady to ponowne przesłanie transakcji bankowej w celu podwójnego obciążenia rachunku, ponowne przesłanie prawidłowej odpowiedzi uwierzytelniającej w celu podszycia się pod użytkownika lub ponowne przesłanie podpisanego polecenia do urządzenia. Atakujący nie musi rozumieć wiadomości ani jej modyfikować; samo retransmitowanie przechwyconych danych wystarcza do przeprowadzenia ataku.

Dołączenie znacznika czasu do uwierzytelnianych wiadomości zapewnia ochronę przed atakami replay. Odbiorca akceptuje wiadomości tylko w krótkim przedziale czasowym, na przykład w ciągu 5 minut od zadeklarowanego znacznika czasu. Wiadomość powtórzona po kilku godzinach wykracza poza ten przedział i zostaje odrzucona. Znacznik czasu musi być uwierzytelniony, czyli znajdować się wewnątrz HMAC lub dodatkowych danych AEAD, aby atakujący nie mógł go zmodyfikować tak, by wiadomość wyglądała na świeżą.

Numery sekwencyjne zapewniają silniejszą ochronę przed atakami replay niż znaczniki czasu, ponieważ wykrywają nie tylko stare powtórzenia, lecz także duplikaty i dostarczenie wiadomości w niewłaściwej kolejności. Odbiorca przechowuje oczekiwany następny numer sekwencyjny oraz przesuwne okno niedawno widzianych numerów. Każda wiadomość musi mieć numer sekwencyjny mieszczący się w dozwolonym oknie i nieużyty wcześniej. TLS używa numerów sekwencyjnych, aby zapobiegać powtarzaniu rekordów w obrębie sesji.

W przypadku AES-GCM zalecaną strategią generowania losowych nonce jest używanie 96 bitów pochodzących z kryptograficznie bezpiecznego generatora liczb pseudolosowych (CSPRNG). Dla losowych nonce o długości 96 bitów prawdopodobieństwo kolizji wynikające z paradoksu dnia urodzin osiąga wartość 2^-32 po 2^32 szyfrowaniach (około 4 miliardach). W aplikacjach o dużym natężeniu ruchu należy przejść na nonce oparte na liczniku albo użyć innego AEAD, takiego jak XChaCha20-Poly1305 z nonce o długości 192 bitów, aby zwiększyć bezpieczny limit.

Deterministyczne nonce oparte na liczniku pozwalają uniknąć problemów związanych z paradoksem dnia urodzin, ale wymagają starannego zarządzania stanem. Licznik musi być zachowywany między ponownymi uruchomieniami aplikacji; licznik, który po ponownym uruchomieniu jest resetowany do zera, natychmiast powoduje ponowne użycie nonce z tym samym kluczem. Licznik należy zaktualizować atomowo przed użyciem nonce, a nie po nim. W systemach rozproszonych nonce oparte na liczniku wymagają koordynacji, aby zapobiec użyciu tej samej wartości licznika przez dwa węzły.

XChaCha20-Poly1305 rozszerza nonce ChaCha20-Poly1305 z 96 do 192 bitów. W przypadku losowych nonce o długości 192 bitów prawdopodobieństwo kolizji wynikające z paradoksu dnia urodzin jest pomijalne nawet po 2^96 szyfrowaniach, czyli po astronomicznie dużej liczbie wiadomości. Dzięki temu losowe generowanie nonce jest bezpieczne bez praktycznych obaw związanych z paradoksem dnia urodzin. libsodium's crypto_secretbox (XSalsa20-Poly1305) używa nonce o długości 192 bitów z tego samego powodu.

Co atakujący może odzyskać, jeśli dwa szyfrogramy GCM zostały utworzone przy użyciu tego samego klucza i nonce?

Podsumowanie ponownego użycia nonce: nonce zapewniają unikalność szyfrogramów, ponowne użycie nonce GCM ujawnia XOR tekstów jawnych i łamie uwierzytelnianie przez odzyskanie H, TLS 1.3 używa XOR numeru sekwencyjnego i IV, aby zagwarantować unikalność nonce, a ataki replay polegają na retransmisji prawidłowych wiadomości bez ich modyfikowania. Znaczniki czasu i numery sekwencyjne w uwierzytelnianych wiadomościach zapobiegają atakom replay. W GCM należy używać losowych nonce o długości 96 bitów, pamiętając o ograniczeniach wynikających z paradoksu dnia urodzin, albo XChaCha20 z większą przestrzenią losowych nonce.