Szyfrowanie uwierzytelnione: AES-GCM i ChaCha20-Poly1305

Szyfrowanie uwierzytelnione (Authenticated Encryption, AE) rozwiązuje podstawowy problem: tradycyjne szyfrowanie zapewnia wyłącznie poufność — utrzymuje dane w tajemnicy — ale nie weryfikuje, czy szyfrogram został zmodyfikowany. Atakujący może zmienić bity w szyfrogramie, a odbiorca odszyfruje bezwartościowe dane, nie wiedząc, że zostały zmienione. Szyfrowanie uwierzytelnione z powiązanymi danymi (Authenticated Encryption with Associated Data, AEAD) jednocześnie zapewnia integralność i autentyczność, generując zarówno zaszyfrowany szyfrogram, jak i znacznik uwierzytelniający, który wykrywa każdą modyfikację.

AES-GCM (Galois/Counter Mode) łączy dwa komponenty: AES-CTR (Counter Mode) do szyfrowania oraz GMAC (Galois Message Authentication Code) do zapewniania integralności. AES-CTR generuje strumień klucza przez szyfrowanie wartości licznika i wykonanie operacji XOR z tekstem jawnym — dzięki temu szyfrowanie można zrównoleglić, w przeciwieństwie do trybu CBC. GMAC oblicza znacznik uwierzytelniający na podstawie szyfrogramu i wszelkich powiązanych danych. Powstały znacznik (128 bitów) jest przesyłany wraz z szyfrogramem; zmiana choćby jednego bitu unieważnia znacznik.

AES-GCM wymaga nonce (liczby użytej tylko raz), zwykle o długości 96 bitów (12 bajtów). Nonce musi być unikalny dla każdej pojedynczej operacji szyfrowania z użyciem tego samego klucza — nie musi być tajny, ale nigdy nie może się powtórzyć. Ponowne użycie nonce w AES-GCM ma katastrofalne skutki: jeśli dwie wiadomości zostaną zaszyfrowane tym samym kluczem i nonce, atakujący może wykonać operację XOR na szyfrogramach, anulując strumień kluczowy i potencjalnie odzyskując oba teksty jawne. Ta luka jest czasami nazywana „niewłaściwym użyciem nonce” i doprowadziła do rzeczywistych ataków umożliwiających odzyskanie kluczy.

Gdy wartości nonce AES-GCM są ponownie używane, atakujący może obliczyć C1 XOR C2 = P1 XOR P2 (XOR obu tekstów jawnych), ponieważ w obu przypadkach użyto tego samego strumienia kluczowego. Ponowne użycie nonce umożliwia także odzyskanie klucza uwierzytelniania H, co pozwala atakującemu fałszować prawidłowe tagi uwierzytelniania dla dowolnych wiadomości — całkowicie łamiąc zarówno poufność, jak i integralność. System Sony PS3 padł ofiarą dokładnie takiego ataku. Ochronę zapewniają losowe wartości nonce (generowane za pomocą CSPRNG) albo deterministyczny licznik, który nigdy się nie zeruje.

ChaCha20-Poly1305 to drugi szyfr AEAD wymagany w TLS 1.3. ChaCha20 jest szyfrem strumieniowym zaprojektowanym przez Daniela Bernsteina, który generuje strumień kluczowy za pomocą operacji add-rotate-XOR (ARX) — bez tablic przeglądania, w całkowicie stałym czasie i z bardzo wysoką szybkością na procesorach bez sprzętowego przyspieszenia AES. Poly1305 to jednorazowy MAC (kod uwierzytelniania wiadomości), który oblicza tag uwierzytelniania na podstawie szyfrogramu. Razem zapewniają zabezpieczenia równoważne AES-GCM, ale są znacznie szybsze na urządzeniach mobilnych i IoT.

Nowoczesne procesory x86 i ARM64 używane w komputerach stacjonarnych i serwerach zawierają instrukcje sprzętowe AES-NI, dzięki którym AES-GCM działa niezwykle szybko. Jednak wiele procesorów urządzeń mobilnych i IoT nie obsługuje AES-NI, przez co programowa implementacja AES-GCM jest stosunkowo wolna. ChaCha20-Poly1305 zaprojektowano z myślą o szybkim działaniu programowym z użyciem prostych operacji arytmetycznych, dzięki czemu urządzenia mobilne osiągają porównywalną wydajność bez sprzętowego przyspieszenia. Firma Google dodała ChaCha20-Poly1305 do TLS jako alternatywę właśnie dla urządzeń z Androidem, a obecnie jest to pełnoprawny zestaw szyfrów w TLS 1.3.

„AD” w AEAD oznacza Associated Data (dane powiązane) — metadane tekstu jawnego, które są uwierzytelniane, ale nie są szyfrowane. Umożliwia to uwierzytelnianie danych, które muszą pozostać czytelne (takich jak nagłówki pakietów lub pola typu rekordu), przy jednoczesnej ochronie przed modyfikacją. W TLS 1.3 bajty nagłówka rekordu są uwzględniane jako dane powiązane w obliczeniach AEAD. Jeśli atakujący zmodyfikuje nagłówek (np. zmieni długość rekordu), weryfikacja tagu uwierzytelniania zakończy się niepowodzeniem, a połączenie zostanie przerwane.

Zanim AEAD stał się standardem, kryptografowie zalecali rozwiązanie Encrypt-then-MAC (EtM): zaszyfrowanie tekstu jawnego, a następnie obliczenie kodu MAC na podstawie szyfrogramu. Jest to bezpieczne, ale wymaga dwóch oddzielnych operacji z użyciem dwóch oddzielnych kluczy. Schematy AEAD, takie jak AES-GCM, łączą obie operacje z użyciem jednego klucza, upraszczając implementację i eliminując całą klasę ataków typu padding oracle, które nękały MAC-then-Encrypt (MtE) — kolejność stosowaną w starszych wersjach TLS (CBC + HMAC). TLS 1.3 korzystający z AEAD całkowicie unika tych problemów.

Zarówno AES-128-GCM, jak i AES-256-GCM są zatwierdzone przez NIST i uznawane za bezpieczne wobec komputerów klasycznych. AES-128 zapewnia 128-bitowy poziom bezpieczeństwa i działa nieco szybciej; AES-256 zapewnia 256-bitowy poziom bezpieczeństwa, oferując większy margines bezpieczeństwa wobec przyszłej analizy kryptograficznej i zagrożeń kwantowych. W większości dzisiejszych zastosowań AES-128-GCM jest wystarczający, ale systemy rządowe przetwarzające informacje niejawne (NSA Suite B) wymagają AES-256. TLS 1.3 oferuje oba warianty, a serwery mogą ustalać ich priorytet na podstawie swojej polityki bezpieczeństwa.

Podczas odszyfrowywania szyfrogramu AEAD odbiorca musi zweryfikować tag uwierzytelniania przed odszyfrowaniem. Proces wygląda następująco: ponownie obliczyć oczekiwany tag na podstawie otrzymanego szyfrogramu, klucza i nonce; porównać go z otrzymanym tagiem za pomocą funkcji porównującej działającej w stałym czasie; dopiero jeśli wartości są zgodne, przystąpić do odszyfrowywania. Porównanie w stałym czasie ma kluczowe znaczenie — jeśli zostanie przerwane przy pierwszym niezgodnym bajcie, atakujący może przeprowadzić atak z kanałem bocznym oparty na pomiarze czasu i fałszować prawidłowe tagi bajt po bajcie. Każda biblioteka AEAD, która stosuje porównanie kończące się przedwcześnie, jest podatna na atak.

Algorytmy AEAD są powszechnie stosowane we współczesnych systemach bezpieczeństwa: TLS 1.3 używa AES-GCM i ChaCha20-Poly1305 do szyfrowania wszystkich rekordów; VPN WireGuard korzysta wyłącznie z ChaCha20-Poly1305; protokół Signal używa go do szyfrowania wiadomości; protokół QUIC (będący podstawą HTTP/3) używa AES-GCM. Gdy widzą Państwo zestaw szyfrów taki jak TLS_AES_256_GCM_SHA384, SHA384 odnosi się do funkcji skrótu HKDF używanej do wyprowadzania kluczy, a nie do mechanizmu integralności — za integralność odpowiada tag GCM.

Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: algorytmy AEAD zapewniają jednocześnie poufność i integralność za pomocą tagu uwierzytelniania, który wykrywa każdą modyfikację szyfrogramu; ponowne użycie nonce AES-GCM ma katastrofalne skutki — umożliwia odzyskanie strumienia kluczowego i sfałszowanie klucza uwierzytelniania — dlatego nonce musi być unikalny dla każdego szyfrowania; a ChaCha20-Poly1305 jest wydajną alternatywą dla AES-GCM na urządzeniach pozbawionych sprzętowego przyspieszenia AES. W następnej części omówimy funkcje wyprowadzania klucza służące do zabezpieczania haseł.