Zasady projektowania bezpiecznych protokołów

Projektowanie bezpiecznych protokołów zakłada istnienie przeciwnika, który całkowicie kontroluje sieć. Model Doleva-Yao (1983) określa, że przeciwnik może przechwytywać, odczytywać, opóźniać, powtarzać, usuwać i modyfikować dowolne wiadomości przesyłane w sieci. Może również tworzyć wiadomości nieodróżnialne od wiadomości uczciwych stron. Może komponować nowe wiadomości ze znanych składników wiadomości. Nie może łamać prymitywów kryptograficznych (odszyfrowywać bez klucza ani fałszować podpisów). Co najważniejsze, przeciwnik jest ograniczony obliczeniowo — działa w czasie wielomianowym — ale kontroluje wszystkie kanały komunikacyjne. Bezpieczeństwo protokołu oznacza osiągnięcie celów uwierzytelniania i poufności nawet wobec tak potężnego przeciwnika, przy założeniu wyłącznie trudności obliczeniowej leżącej u podstaw użytych prymitywów.

Abadi i Needham (1994) zebrali praktyczne wnioski dotyczące projektowania protokołów w postaci zestawu zasad. (1) Każda wiadomość powinna jasno określać swoje znaczenie: interpretacja wiadomości powinna być samodzielna i nie może zależeć od kontekstu. (2) Warunki, które muszą zostać spełnione, aby podmiot podjął działanie, powinny być wyraźnie określone w protokole. (3) Jeśli tożsamość podmiotu ma znaczenie, powinna być wyraźnie podana w wiadomości. (4) Należy jasno określić, dlaczego używane jest szyfrowanie: szyfrowanie zapewnia poufność, a podpisy zapewniają uwierzytelnianie — nie należy używać szyfrowania zamiast podpisu. (5) Wiadomość powinna być szyfrowana na tej warstwie protokołu, na której potrzebna jest jej poufność. Zasady te zapobiegły wielu lukom typu NS.

Ataki polegające na powtórzeniu należą do najczęstszych luk w protokołach. Mechanizmy świeżości zapewniają, że odebrana wiadomość została wygenerowana niedawno, a nie odtworzona ze starej sesji. Stosuje się dwa podejścia: (1) Nonces (Number used ONCE, czyli wartości używane tylko raz) — mechanizm challenge-response, w którym odbiorca wysyła losową wartość i oczekuje jej powtórzenia w odpowiedzi. Odpowiedź musi zawierać nonce zaszyfrowany lub podpisany, co uniemożliwia wykorzystanie wcześniej zarejestrowanej wiadomości do spełnienia nowego wyzwania. (2) Znaczniki czasu — obie strony dołączają bieżący czas, a wiadomość z nieaktualnym znacznikiem czasu jest odrzucana. Znaczniki czasu wymagają zsynchronizowanych zegarów (Kerberos dopuszcza 5-minutowe odchylenie). Nonce są preferowane, gdy synchronizacja zegarów jest niedostępna, natomiast znaczniki czasu upraszczają bezstanową weryfikację.

Używanie tego samego klucza kryptograficznego do wielu celów prowadzi do niebezpiecznych interakcji. Jeśli klucz K jest używany zarówno do szyfrowania, jak i uwierzytelniania, przeciwnik może podawać spreparowane szyfrogramy mechanizmowi uwierzytelniania, aby wydobywać informacje. TLS 1.3 rygorystycznie unika tego problemu dzięki HKDF-Expand-Label, używając odrębnych etykiet dla każdego wyprowadzanego klucza: „c hs traffic” (uzgadnianie klienta), „s hs traffic” (uzgadnianie serwera), „c ap traffic” (ruch aplikacji klienta). Nawet jeśli klucz uzgadniania zostanie ujawniony, klucze aplikacji wyprowadzone z innej gałęzi HKDF pozostają bezpieczne. Projekty protokołów muszą obejmować kontrolą każdy klucz pod kątem ryzyka wielokrotnego użycia i wyprowadzać osobne klucze do osobnych celów.

Dane uwierzytelniające muszą być powiązane z konkretną sesją, w której są używane. Bez takiego powiązania dane uwierzytelniające uzyskane w jednej sesji można ponownie wykorzystać w innej. Techniki: (1) Uwzględnienie identyfikatorów sesji w danych podpisanych lub uwierzytelnionych kodem MAC. (2) Uwzględnienie transkryptu DH w podpisie (podejście STS). (3) Użycie klucza sesji wyprowadzonego przez HKDF do obliczenia kodu MAC dla tożsamości (podejście SIGMA). Komunikat Finished w TLS 1.3: MAC(server_finished_key, transcript_hash) — kod MAC obejmuje kompletny transkrypt, dlatego ponowne wykorzystanie komunikatu Finished z innej sesji kończy się niepowodzeniem. To powiązanie zapobiega atakom między sesjami, które występowały we wczesnych wersjach Kerberos i NS.

Protokoły powinny ujawniać wyłącznie minimum informacji niezbędne do ich działania. Tożsamości należy ujawniać wyłącznie podmiotom, które ich potrzebują. Nie należy dołączać numerów seryjnych certyfikatów ani identyfikatorów umożliwiających powiązanie sesji z tożsamościami, chyba że jest to wymagane. TLS 1.3 szyfruje certyfikat serwera (w przeciwieństwie do TLS 1.2, w którym jest on przesyłany jawnym tekstem), ograniczając ilość informacji dostępnych pasywnemu podsłuchującemu. ESNI (Encrypted SNI, obecnie ECH — Encrypted Client Hello) szyfruje wskazanie nazwy serwera, aby ukryć, z którym serwerem łączy się klient. Minimalne ujawnianie informacji jest także zasadą projektowania tokenów: roszczenia JWT powinny zawierać tylko informacje potrzebne do autoryzacji, a nie pełne rekordy tożsamości.

Negocjowanie wersji jest częstym obszarem ataków: przeciwnik usuwa lub modyfikuje ClientHello, aby zmusić obie strony do użycia starszej, słabszej wersji protokołu. Mechanizmy ochrony: (1) Uwierzytelnione negocjowanie wersji — wynegocjowaną wersję należy zawrzeć w podpisanym transkrypcie (TLS Finished obejmuje ClientHello wraz z wersją). (2) Znaczniki obniżenia wersji — TLS 1.3 umieszcza specjalne bajty w ServerHello.Random podczas przechodzenia na TLS 1.2, aby klient mógł wykryć obniżenie wersji. (3) Zapobieganie niezgodności wersji — serwery muszą odrzucać niepoprawne ClientHello, zamiast po cichu przechodzić na starszą wersję. (4) SCSV — TLS_FALLBACK_SCSV sygnalizuje serwerowi, że klient ponawia próbę z niższą wersją, dzięki czemu serwer może odrzucić nieuprawnione przejście na starszą wersję.

Komunikaty protokołu powinny być objęte zobowiązaniem już od pierwszej wymiany. Niemodyfikowalność oznacza, że przeciwnik nie może zmodyfikować szyfrogramu ani podpisu tak, aby weryfikacja powiodła się w innym kontekście. AEAD zapewnia niemodyfikowalność szyfrogramu — każda modyfikacja unieważnia znacznik uwierzytelniający. Na poziomie protokołu haszowanie transkryptu sprawia, że wymiana Finished na końcu uzgadniania obejmuje zobowiązaniem każdy wysłany komunikat. Zapobiega to atakom typu wytnij i wklej: połączenie komunikatów z dwóch różnych sesji nie może utworzyć prawidłowej wartości Finished dla żadnej z tych sesji. Schematy zobowiązań (zobowiązania oparte na skrótach) rozszerzają tę ochronę na przebiegi protokołów wymagające wcześniejszego zobowiązania przed ujawnieniem.

Złożone protokoły często zawodzą na granicach stanów. Jeśli przejście między stanami jest niejednoznaczne — co się dzieje, gdy komunikat 3 nadejdzie przed komunikatem 2? co się dzieje, gdy nadejdzie komunikat nieoczekiwanego typu? — implementacje mogą zachowywać się odmiennie, tworząc niespójności możliwe do wykorzystania przez przeciwnika. Specyfikacje protokołów muszą definiować: kompletną maszynę stanów (wszystkie stany i prawidłowe przejścia), zachowanie w przypadku nieoczekiwanych danych wejściowych (odrzucenie z określonym błędem lub ciche zignorowanie), limity czasu i retransmisji oraz czyszczenie stanu sesji. SSL/TLS historycznie borykał się z rozbieżnościami implementacji maszyn stanów — CVE-2014-0160 (Heartbleed) było w istocie awarią maszyny stanów, w której żądanie heartbeat zostało przetworzone w stanie, gdzie pamięć nie była odpowiednio ograniczona.

Protokoły kryptograficzne rzadko są używane samodzielnie. Protokół AKE ustanawia klucz sesji, który następnie wykorzystuje protokół warstwy aplikacji. Jeśli protokół AKE i protokół aplikacji zostaną zaprojektowane niezależnie, bez uwzględnienia kompozycyjności, ich wzajemne oddziaływanie może naruszyć bezpieczeństwo. Model Universal Composability (UC) (Canetti, 2001) zapewnia ścisły model kompozycji protokołów: protokół jest bezpieczny w modelu UC, jeśli zachowuje bezpieczeństwo przy dowolnym łączeniu z innymi protokołami bezpiecznymi w modelu UC. TLS 1.3, Signal i Noise dążą do zapewnienia bezpieczeństwa kompozycyjnego. W praktyce należy używać powiązania kanału (eksportować skrót transkryptu), aby powiązać sesję AKE z późniejszym uwierzytelnianiem w warstwie aplikacji i zapobiec przekazywaniu danych uwierzytelniających między sesjami ustanowionymi przez ten sam protokół AKE.

Projektanci protokołów wielokrotnie popełniają te same typy błędów. (1) Samodzielne tworzenie kryptografii: implementowanie własnych szyfrów blokowych, kodów MAC lub mechanizmów wyprowadzania kluczy bez weryfikacji przez niezależnych ekspertów. (2) Niejawne zaufanie: uznawanie źródła komunikatu na podstawie kontekstu sieciowego zamiast dowodu kryptograficznego. (3) Opcjonalne zabezpieczenia: umożliwienie konfigurowania szyfrowania lub uwierzytelniania, co nieuchronnie prowadzi do obniżenia poziomu bezpieczeństwa. (4) Długowieczne tokeny bez możliwości unieważnienia: wydawanie JWT lub kluczy sesji z długim okresem ważności i bez mechanizmu unieważniania. (5) Ignorowanie kanału błędów: brak uwierzytelniania komunikatów o błędach pozwala przeciwnikowi wstrzykiwać błędy i wpływać na działanie protokołu. (6) Używanie szyfrowania do uwierzytelniania: szyfrowanie danych nie uwierzytelnia ich źródła bez kodu MAC lub podpisu.

Zgodnie z zasadami Abadi-Needham, dlaczego komunikat powinien jawnie zawierać tożsamość nadawcy, gdy tożsamość ma znaczenie?

Bezpieczne projektowanie protokołów opiera się na uznanych zasadach: modelu przeciwnika Dolev-Yao (przeciwnik kontrolujący sieć), zasadach Abadi-Needham (jawna tożsamość, samowystarczalne komunikaty), zapewnianiu świeżości za pomocą wartości nonce lub znaczników czasu, separacji kluczy za pomocą HKDF z odrębnymi etykietami, powiązaniu danych uwierzytelniających z sesją, minimalnym ujawnianiu informacji, zapobieganiu obniżeniu wersji dzięki uwierzytelnianiu transkryptu, niemodyfikowalności zapewnianej przez AEAD i haszowanie transkryptu, jasno zdefiniowanym maszynom stanów z określoną obsługą błędów oraz kompozycyjności potwierdzonej dowodami bezpieczeństwa w modelu UC. Naruszenia tych zasad są źródłem niemal każdej znanej podatności kryptograficznej na poziomie protokołu.