Protokół Station-to-Station (STS)

Protokół Station-to-Station (STS) (Diffie, van Oorschot, Wiener, 1992) zaprojektowano w celu zapewnienia uwierzytelnionego uzgadniania klucza bez zaufanej strony trzeciej. Czysta wymiana kluczy Diffiego-Hellmana nie zapewnia uwierzytelniania — przeciwnik typu man-in-the-middle może podstawić własne wartości DH, ustanawiając osobne sesje z każdą ze stron, które sądzą, że współdzielą klucz. STS łączy DH z podpisami cyfrowymi i certyfikatami kluczy publicznych, aby zapewnić wzajemne uwierzytelnianie. Strony uwierzytelniają się, podpisując transkrypt DH i wiążąc klucz sesyjny ze swoimi tożsamościami. STS bezpośrednio wpłynął na projekt IKE (Internet Key Exchange dla IPsec) i SSH.

Protokół STS działa następująco. Alicja i Bob uzgadniają grupę DH (liczbę pierwszą p i generator g). (1) Alicja wysyła do Boba g^a mod p. (2) Bob wysyła Alicji g^b mod p, Cert_B, Sig_B{g^b, g^a}. Bob podpisuje konkatenację obu wartości DH za pomocą swojego klucza prywatnego. (3) Alicja weryfikuje certyfikat i podpis Boba, a następnie wysyła Cert_A, Sig_A{g^a, g^b} zaszyfrowane przy użyciu klucza sesyjnego K = (g^ab mod p). Tożsamość Alicji i jej podpis są zaszyfrowane, co zapewnia ochronę tożsamości Alicji — pasywni podsłuchujący nie mogą powiązać Alicji z tą sesją. Obie strony obliczają K = g^ab mod p i wzajemnie się uwierzytelniają za pomocą podpisów.

Porównanie STS z nieuwierzytelnioną wymianą DH pokazuje, co wnosi uwierzytelnianie. W zwykłym DH Mallory przechwytuje g^a i g^b, podstawia g^m w komunikacji z Alicją oraz g^m w komunikacji z Bobem, ustanawiając K1 = g^am i K2 = g^bm. Mallory odszyfrowuje cały ruch. W STS Bob podpisuje {g^b, g^a} — podpis obejmuje dokładne wartości DH z tej sesji. Nawet jeśli Mallory podstawi g^m zamiast g^b, nie może sfałszować poprawnego podpisu przy użyciu klucza Boba z jego certyfikatu. Alicja odrzuca sesję. Najważniejszy wniosek: uwierzytelnianie podczas wymiany kluczy musi obejmować transkrypt DH, a nie tylko deklaracje tożsamości.

STS zapewnia doskonałą poufność w przód (PFS), ponieważ klucz sesyjny jest wyprowadzany z efemerycznych wartości DH (g^a, g^b), które są usuwane po zakończeniu sesji. Nawet jeśli długoterminowy klucz podpisujący Boba zostanie później przejęty, wcześniej zarejestrowanych sesji STS nie można odszyfrować — atakujący potrzebowałby efemerycznych wykładników DH a i b, które nigdy nie zostały zapisane. Jest to ta sama właściwość, którą zapewnia TLS w zestawach szyfrów ECDHE. Bez efemerycznego DH (na przykład przy użyciu transportu klucza RSA, w którym klucz sesyjny jest szyfrowany statycznym kluczem RSA serwera) przejęcie klucza długoterminowego pozwala odszyfrować wszystkie wcześniejsze sesje.

STS szyfruje certyfikat i podpis Alicji w kroku 3, zapewniając ochronę tożsamości odpowiadającego przed pasywnymi podsłuchującymi. Pasywny obserwator widzi tylko wartość DH Alicji i certyfikat Boba (który Bob wysyła jawnym tekstem w kroku 2). Tożsamość Alicji jest ukryta przed pasywnym podsłuchem. Aktywni atakujący przeprowadzający atak MITM są wykrywani przez nieudaną weryfikację podpisu. Ta asymetria (tożsamość inicjatora ujawniona aktywnemu atakującemu, tożsamość odpowiadającego chroniona przed pasywnym podsłuchem) jest zamierzonym kompromisem projektowym — pełna ochrona tożsamości obu stron przed aktywnymi atakującymi wymagałaby dodatkowej złożoności protokołu (wcześniejszego współdzielenia wartości DH albo użycia anonimowych elementów grupy).

IKE (Internet Key Exchange), protokół zarządzania kluczami dla IPsec, wywodzi się bezpośrednio z STS. IKEv1 (RFC 2409) wykorzystywał uwierzytelnianie podpisami w stylu STS w trybie Main Mode. IKEv2 (RFC 7296) jest przeprojektowaną, prostszą wersją z czterema przepływami komunikatów: IKE_SA_INIT (wymiana DH, wartości nonce), IKE_AUTH (tożsamość, certyfikat, podpis nad transkryptem IKE_SA_INIT). Format uwierzytelnienia to AUTH = PRF(SK_pi, transcript) w przypadku PSK albo podpis cyfrowy nad oktetami IKE_SA_INIT w przypadku uwierzytelniania za pomocą certyfikatu. IKEv2 obsługuje również Extensible Authentication Protocol (EAP) do uwierzytelniania za pomocą starszych metod opartych na hasłach, analogicznie do obsługi różnych metod uwierzytelniania przez STS.

Uwierzytelnianie za pomocą kluczy w SSH wykorzystuje mechanizm podobny do kroku 3 STS. Po wymianie kluczy DH (SSH_MSG_KEXDH_REPLY zawiera klucz publiczny serwera, wartość DH i podpis nad hashem wymiany) klient weryfikuje klucz hosta serwera. W przypadku uwierzytelniania klienta (SSH_MSG_USERAUTH_REQUEST z metodą publickey) klient podpisuje {session_id, username, service, method, key_algo, public_key} przy użyciu swojego klucza prywatnego. Wartość session_id jest wyprowadzana z transkryptu DH, wiążąc uwierzytelnianie z tą konkretną sesją — zapobiega to fałszerstwu między sesjami, które było problemem w NS. SSH nie używa domyślnie certyfikatów, ale obsługuje je za pomocą ssh-keygen -s (podpisywanie certyfikatów) w dużych wdrożeniach.

STS należy do rodziny protokołów uwierzytelniania wymiany kluczy (AKE) SIGMA (SIGn-and-MAc), sformalizowanej przez Hugo Krawczyka. SIGMA rozszerza STS o kod MAC: każda strona podpisuje transkrypt i oblicza MAC dla swojej tożsamości przy użyciu klucza sesyjnego: MAC(K, identity). Kod MAC wiąże tożsamość z kluczem sesyjnym, zapobiegając konkretnemu atakowi, w którym przeciwnik może powiązać podpisy z różnych sesji. SIGMA-I (ochrona tożsamości inicjatora), SIGMA-R (ochrona tożsamości odpowiadającego) i SIGMA-0 (brak ochrony tożsamości) to warianty tego protokołu. IKEv2 i X3DH używany przez Signal należą do rodziny protokołów SIGMA. Formalizm SIGMA zapewnia rygorystyczny dowód bezpieczeństwa projektów w stylu STS.

STS jest podatny na atak Key Compromise Impersonation (KCI): jeśli długoterminowy klucz Alicji zostanie przejęty, atakujący może podszyć się pod dowolną stronę wobec Alicji w nowej sesji (ponieważ może sfałszować podpis Alicji dla dowolnego transkryptu). Oznacza to, że przejęcie klucza jednej strony pozwala przeciwnikowi podszywać się pod inne strony wobec tej strony. KCI jest nieodłączną cechą protokołów AKE opartych na podpisach — obrona przed nim wymaga, aby klucz sesyjny zależał od wkładu obu stron w sposób uniemożliwiający stronie, której klucz przejęto, dokonanie podmiany. HMQV (Hashed Menezes-Qu-Vanstone) i NAXOS zapewniają odporność na KCI kosztem dodatkowej złożoności.

STS zapewnia niezaprzeczalność: podpisy z kryptograficzną pewnością dowodzą, kto co powiedział. Czasami jest to niepożądane — w prywatnych rozmowach uczestnicy mogą nie chcieć, aby istniał możliwy do przedstawienia w sądzie kryptograficzny dowód ich wypowiedzi. Komunikacja Off-the-Record (OTR) i Double Ratchet używany przez Signal zapewniają zaprzeczalność: zamiast podpisywać komunikaty, wykorzystują klucze MAC, które posiadają zarówno nadawca, jak i odbiorca. Po zakończeniu rozmowy obie strony mogą twierdzić, że druga sfabrykowała komunikaty, ponieważ każda z nich posiada klucz umożliwiający generowanie kodów MAC. Kompromis polega na tym, że zaprzeczalność poświęca niezaprzeczalność. Projekty w stylu STS są odpowiednie tam, gdzie wymagana jest rozliczalność, a OTR i Signal — tam, gdzie ceniona jest zaprzeczalność.

Bezpieczeństwo STS przeanalizowano nieformalnie w pierwotnej publikacji, ale formalnie dowiedli go Bellare i Rogaway (1993, 1994) w swoim przełomowym modelu bezpieczeństwa AKE. Zdefiniowali oni, co oznacza bezpieczeństwo protokołu wymiany kluczy: nieodróżnialność kluczy sesyjnych od losowych, nawet gdy przeciwnik może rejestrować strony, ujawniać klucze sesyjne, ujawniać klucze długoterminowe (z wyjątkiem klucza docelowej sesji) i kontrolować sieć. Ten oparty na symulacji model bezpieczeństwa, rozszerzony przez Canettiego-Krawczyka, a później przez UC (Universal Composability), jest obecnie standardem dowodzenia bezpieczeństwa protokołów AKE. TLS 1.3, Signal i Noise mają formalne dowody bezpieczeństwa w wariantach tego modelu.

STS łączy efemeryczną wymianę kluczy DH z podpisami cyfrowymi, aby zapewnić uwierzytelnione uzgadnianie klucza bez TTP. Obie strony podpisują transkrypt DH, wiążąc uwierzytelnianie z sesją. STS zapewnia forward secrecy (dzięki efemerycznemu DH), wzajemne uwierzytelnianie (dzięki podpisom) oraz ochronę tożsamości respondera (dane Alice są szyfrowane przed wysłaniem). STS wywarł bezpośredni wpływ na IKEv2 i uwierzytelnianie kluczem w SSH. SIGMA formalizuje STS za pomocą MAC-ów tożsamości i dowodów bezpieczeństwa. KCI jest nieodłączną słabością STS, ograniczaną przez HMQV/NAXOS. Zaprzeczalność (jak w Signal) wymaga zastąpienia podpisów MAC-ami w celu zapewnienia autentyczności na poziomie wiadomości.