AES-GCM może chronić poufność wiadomości i wykrywać nieuprawnione zmiany. Sam nie informuje jednak odbiorcy, czy poprawna poza tym wiadomość została już przetworzona.
Łatwo pomylić trzy wymagania: unikalne pary klucz/nonce podczas szyfrowania, uwierzytelnianie wiadomości i jej kontekstu oraz obsługę powtórzeń na poziomie protokołu. HKDF może pomóc wyprowadzać klucze, lecz nie spełnia automatycznie wszystkich trzech.
Ponowne użycie nonce i powtórzenie wiadomości to różne zdarzenia
| Zdarzenie | Co się dzieje | Wymagana ochrona |
|---|---|---|
| Ponowne użycie nonce podczas szyfrowania | Różne teksty jawne szyfruje się tym samym kluczem GCM i nonce | Niezawodna strategia przydzielania par klucz/nonce |
| Manipulacja | Zmieniono szyfrogram lub uwierzytelniany kontekst | Uwierzytelnione odszyfrowanie i odrzucenie przy niepowodzeniu |
| Powtórzenie | Wcześniej poprawna zaszyfrowana wiadomość zostaje dostarczona ponownie | Stan i reguły aplikacji rozpoznające duplikaty lub nieaktualne wiadomości |
| Zmiana kolejności | Poprawne wiadomości docierają w innej kolejności | Kolejność określona przez protokół i ograniczona obsługa wiadomości poza kolejnością |
Powtórzony szyfrogram nadal może mieć poprawny znacznik uwierzytelniający. Niczego nie zmieniono. Błędem jest więc twierdzenie, że każdy duplikat automatycznie nie przechodzi uwierzytelniania AES-GCM. RFC 5116 wyraźnie oddziela interfejs AEAD od usług ochrony przed powtórzeniami.
Dlaczego para klucz–nonce nie może się powtarzać
Nonce w GCM nie musi być tajne, ale musi spełniać wymagania unikalności schematu dla danego klucza. Często stosuje się nonce 96-bitowe, czyli 12-bajtowe; wybór tej długości nie gwarantuje poprawnego generowania.
Ponowne użycie tego samego klucza i nonce dla różnych tekstów jawnych ponownie wykorzystuje strumień szyfrujący, ujawniając zależności między tekstami jawnymi. Może też podważyć autentyczność i umożliwić fałszowanie. Skutki są poważne, ale nie należy opisywać ich jako automatycznego ujawnienia każdego starego klucza lub każdej wiadomości na koncie. Zakres zależy od ponownie użytego klucza i protokołu.
NIST SP 800-38D definiuje GCM i jego wymagania. Implementacje muszą przestrzegać odpowiednich limitów wywołań i zasad generowania nonce, a nie uproszczonej reguły „bezpieczne do tylu wiadomości”.
Co wnosi HKDF
HKDF, określone w RFC 5869, wyprowadza materiał kluczowy z wejściowego materiału tajnego za pomocą etapów ekstrakcji i rozszerzania. Protokoły mogą używać etykiet kontekstu i odrębnych danych wejściowych do rozdzielania kluczy o różnych zastosowaniach.
HKDF jest deterministyczne. Jeśli klient po awarii lub przywróceniu starszego stanu powtórzy ten sam stan i dane wejściowe, może ponownie wyprowadzić ten sam wynik. Dodanie HKDF do projektu nie czyni zatem ponownego użycia nonce niemożliwym.
Klucze odrębne dla każdej wiadomości mogą zmniejszyć ilość treści chronionej jednym kluczem, ale bezpieczny postęp stanu, rozdzielanie kluczy i ich usuwanie nadal mają znaczenie. Ta sama wartość nonce przy rzeczywiście różnych kluczach nie jest takim samym błędem jak powtórzenie pary klucz/nonce; protokół musi zapewnić, że klucze naprawdę są różne.
Ochrona przed powtórzeniami należy do protokołu
Odbiorca może śledzić identyfikatory wiadomości, pozycje w sekwencji, epoki sesji lub wykorzystane klucze mechanizmu ratchet. Odpowiednie pola muszą być uwierzytelniane, aby atakujący nie mógł oznaczyć starej wiadomości jako nowej.
Aplikacja musi następnie zdecydować, co oznacza duplikat. Wyświetlenie dodatkowego dymku czatu jest niewygodne; dwukrotne wykonanie tej samej czynności może być poważniejsze. Ponowienia sieciowe są normalne, dlatego obok kontroli kryptograficznych często potrzebne jest przetwarzanie idempotentne.
Nie wymagaj, aby każda poprawna wiadomość docierała ściśle w kolejności, chyba że protokół przewiduje takie zachowanie. Klienci mobilni regularnie łączą się ponownie, ponawiają wysyłanie i otrzymują opóźnione wiadomości. Bezpieczna obsługa odróżnia uzasadnioną spóźnioną wiadomość od wiadomości już wykorzystanej lub należącej do niewłaściwego kontekstu.
Co przetestować przed zadeklarowaniem ochrony
- Uruchom ponownie po przydzieleniu nonce, ale przed zapisaniem faktu wysłania: czy przydział może się powtórzyć?
- Przywróć starszą migawkę stanu: czy klucze, liczniki lub rejestry powtórzeń mogą się cofnąć?
- Wysyłaj równocześnie z dwóch procesów roboczych lub urządzeń: czy ich domeny klucz/nonce są rozdzielone?
- Dostarcz tę samą poprawną wiadomość dwa razy: czy czynność aplikacji wykonywana jest raz?
- Zmień identyfikator sesji lub nagłówek: czy kontekst jest związany kryptograficznie?
- Dostarcz poprawne wiadomości poza kolejnością: czy obsługiwane opóźnienia są tolerowane bez przyjmowania nieaktualnego stanu?
API uwierzytelnionego odszyfrowania powinny zwracać tekst jawny aplikacji tylko po pomyślnej weryfikacji. To wymaganie interfejsu, a nie twierdzenie, że żadna implementacja nigdy nie oblicza wewnętrznie tymczasowego bufora tekstu jawnego.
Jak poprawnie odczytywać deklaracje Livara
Dokumentacja bezpieczeństwa Livara wymienia AES-256-GCM, łańcuchy kluczy dla poszczególnych wiadomości i kontekst LVR1/LGS1. Te elementy kryptograficzne same nie dowodzą poprawnego odtwarzania po awarii, przydzielania nonce ani odrzucania powtórzeń. Takie deklaracje wymagają szczegółów protokołu dla konkretnych wersji i dowodów z testów.
Solidny projekt jawnie przypisuje każde zadanie: wyprowadzanie kluczy tworzy zamierzone klucze, AEAD uwierzytelnia treść i kontekst, a stanowa logika protokołu decyduje, czy poprawna wiadomość jest teraz dopuszczalna.
