Nonce w AES-GCM nie musi być tajny, ale jego powtórzenie może być katastrofalne
W trybie AES-GCM każda wiadomość używa IV/nonce, który zwykle może być przesyłany jawnie. Krytyczny warunek jest inny: dla tego samego klucza wartości nie powinny się powtarzać. NIST podkreśla, że spełnienie wymogu unikalności jest kluczowe dla bezpieczeństwa GCM i że nawet pojedyncze powtórzenie IV z tym samym kluczem może otworzyć drogę do ataków na autentyczność. To kontrintuicyjne, bo łatwo uznać publiczną wartość za „nieistotną”. W kryptografii parametr może być całkowicie jawny, a jednocześnie jego poprawne zarządzanie może być niemal tak ważne jak ochrona samego klucza.
Nonce to nie drugi klucz
IV w GCM nie jest projektowany jako tajemnica współdzielona przez obie strony. Może znajdować się obok szyfrogramu, ponieważ odbiorca i tak potrzebuje go do odszyfrowania. Jego rolą jest sprawienie, aby kolejne wywołania szyfru z tym samym kluczem miały różne konteksty. Bezpieczeństwo zależy więc od własności „nie powtarzaj”, a nie „ukryj”. To dobry przykład, dlaczego intuicja „wszystko ważne w kryptografii powinno być sekretem” jest błędna.
GCM łączy szyfrowanie licznikowe z uwierzytelnianiem
GCM wykorzystuje tryb zbliżony do licznika do tworzenia strumienia maskującego dane oraz funkcję GHASH do wyliczenia tagu autentyczności. IV uczestniczy w tworzeniu punktu startowego dla tych operacji. Jeśli ten sam klucz i IV zostaną użyte ponownie dla innych danych, powstają zależności między szyfrogramami, a część struktury odpowiedzialnej za uwierzytelnianie również traci założenia bezpieczeństwa. Dlatego problem nie ogranicza się do „ujawnienia, że wiadomości są podobne”. Może dotyczyć zarówno poufności, jak i możliwości fałszowania.
NIST traktuje unikalność jako wymóg krytyczny
SP 800-38D formułuje wymóg, aby prawdopodobieństwo ponownego użycia tego samego IV z tym samym kluczem dla różnych wejść było skrajnie małe. Dokument stwierdza, że jeśli IV się powtórzy, implementacja może stać się podatna na ataki fałszowania, oraz porównuje praktyczne znaczenie tego wymagania do ochrony samego klucza. To wyjątkowo mocne sformułowanie jak na wartość, która może być publiczna.
Dlatego liczniki bywają bezpieczniejsze niż „po prostu losuj”
Jednym ze sposobów gwarantowania unikalności jest konstrukcja deterministyczna: część identyfikuje urządzenie lub kontekst, a część wywołania rośnie jak licznik. Jeśli projekt zapewnia, że para nigdy się nie powtórzy dla danego klucza, nie trzeba liczyć na szczęście losowania. Można też używać wartości losowych, ale wtedy system musi kontrolować prawdopodobieństwo kolizji i liczbę wiadomości pod jednym kluczem. Zarządzanie nonce jest więc problemem protokołu, nie tylko pojedynczego wywołania biblioteki.
Mała pomyłka architektoniczna może złamać świetny szyfr
AES jako prymityw może pozostawać całkowicie bezpieczny. GCM jako tryb może być prawidłowo zaimplementowany. A mimo to system może być niebezpieczny, jeśli po restarcie resetuje licznik nonce, klonuje stan na wiele maszyn albo przez błąd używa tej samej wartości dwukrotnie. To idealna ilustracja głównego motywu bezpieczeństwa komputerowego: właściwości kryptograficzne istnieją tylko wtedy, gdy zachowane są warunki ich użycia.
Dla GCM „niemal nigdy się nie powtórzy” to słabsza gwarancja niż „nie może się powtórzyć”
SP 800-38D szczególnie mocno podkreśla wymóg unikalności IV dla danego klucza. Przy losowym generowaniu trzeba więc liczyć się z prawdopodobieństwem kolizji rosnącym wraz z liczbą wiadomości, podczas gdy dobrze zaprojektowany licznik lub konstrukcja z częścią stałą i rosnącą może zapewnić unikalność konstrukcyjnie aż do kontrolowanego limitu. To ciekawy przypadek, w którym „bardziej losowo” nie musi znaczyć „bezpieczniej”. Nonce nie potrzebuje nieprzewidywalności, jeśli schemat wymaga przede wszystkim braku powtórzeń. Projektant powinien więc dobrać generator do własności wymaganej przez protokół, a nie automatycznie stosować losowość wszędzie. Właśnie pomylenie unikalności z losowością jest jednym z częstych źródeł błędów w użyciu AEAD.
Najczęściej zalecany 96-bitowy IV w GCM nie jest przypadkową liczbą
SP 800-38D wyróżnia 96-bitowe IV jako długość szczególnie wygodną dla GCM, ponieważ pozwala bezpośrednio zbudować początkowy blok licznika bez dodatkowego hashowania IV. Standard dopuszcza także inne długości, ale wymaga wtedy odpowiedniej konstrukcji i nadal bezwzględnego pilnowania unikalności dla danego klucza. To pokazuje, że nawet parametr wyglądający jak „techniczny szczegół formatu” może mieć związek zarówno z bezpieczeństwem, jak i wydajnością. Projekt protokołu powinien określić skąd bierze się nonce, jak zapobiega kolizjom po restarcie i kiedy zmienia się klucz. Sam wybór AES-GCM w bibliotece nie rozwiązuje tych pytań; bezpieczeństwo zależy również od cyklu życia wartości otaczających szyfr.