Firma Google ogłosiła otwarcie specyfikacji i referencyjnej implementacji protokołu PSP (PSP Security Protocol), stosowanego do szyfrowania ruchu pomiędzy centrum danych. Protokół wykorzystuje architekturę enkapsulacji podobną do IPsec ESP (Encapsulating Security Payloads) na poziomie IP, zapewniając szyfrowanie, kryptograficzną kontrolę integralności i uwierzytelnianie źródła. Kod implementacji PSP napisany jest w języku C i udostępniany na licencji Apache 2.0.
Cechą charakterystyczną PSP jest optymalizacja protokołu mająca na celu przyspieszenie obliczeń i zmniejszenie obciążenia procesora poprzez przeniesienie operacji szyfrowania i deszyfrowania na karty sieciowe (offload). Do zastosowania akceleracji sprzętowej wymagane są specjalne karty sieciowe zgodne z PSP. Dla systemów z kartami sieciowymi, które nie wspierają PSP, proponowana jest programowa implementacja SoftPSP.
Jako transport do przesyłania danych wykorzystywany jest protokół UDP. Pakiet PSP zaczyna się od nagłówka IP, po którym następuje nagłówek UDP, a następnie nagłówek PSP z informacjami o szyfrowaniu i uwierzytelnianiu. Następnie dołączana jest treść oryginalnego pakietu TCP/UDP, która kończy się blokiem PSP z sumą kontrolną potwierdzającą integralność. Nagłówek PSP, jak również nagłówek i dane enkapsulowanego pakietu są zawsze uwierzytelniane w celu potwierdzenia autentyczności pakietu. Dane pakietu enkapsulowanego mogą być szyfrowane, przy czym dopuszcza się możliwość selektywnego stosowania szyfrowania z pozostawieniem części nagłówka TCP w postaci otwartej (z zachowaniem kontroli autentyczności), na przykład w celu umożliwienia inspekcji pakietów na sprzęcie sieciowym w tranzycie.
PSP nie jest związany z żadnym określonym protokołem wymiany kluczy, oferuje kilka opcji formatu pakietów oraz wspiera użycie różnych algorytmów kryptograficznych. Na przykład, zapewniana jest obsługa algorytmu AES-GCM do szyfrowania i kontroli autentyczności oraz AES-GMAC do weryfikacji autentyczności bez szyfrowania danych, na przykład gdy dane nie mają wartości, ale należy zapewnić, że nie zostały one zmienione w trakcie przesyłania i są tymi, które zostały pierwotnie wysłane.
W odróżnieniu od typowych VPN-w protokole PSP zastosowano szyfrowanie na poziomie poszczególnych połączeń sieciowych, a nie całego kanału komunikacyjnego, tzn. PSP stosuje oddzielne klucze szyfrowania dla różnych tunelowanych połączeń UDP i TCP. Takie podejście umożliwia osiągnięcie bardziej rygorystycznej izolacji ruchu pomiędzy różnymi aplikacjami i przetwarzaczami, co jest istotne przy uruchamianiu na jednym serwerze aplikacji i usług różnych użytkowników.
W Google protokół PSP jest stosowany zarówno do ochrony wewnętrznych komunikacji, jak i zabezpieczania ruchu klientów Google Cloud. Protokół został pierwotnie zaprojektowany do efektywnej pracy w infrastrukturach na poziomie Google i musi zapewniać przyspieszenie sprzętowe szyfrowania w warunkach istnienia milionów aktywnych połączeń sieciowych oraz nawiązywania setek tysięcy nowych połączeń na sekundę.
Wyróżnia się dwa tryby pracy - „stateful” i „stateless”. W trybie „stateless” klucze szyfrowania są przesyłane do karty sieciowej w nagłówku pakietu, a do odszyfrowania są wydobywane z pola SPI (Security Parameter Index) znajdującego się w pakiecie za pomocą klucza głównego (256-bit AES, przechowywanego w pamięci karty sieciowej i wymienianego co 24 godziny), co pozwala zaoszczędzić pamięć karty sieciowej i zminimalizować informacje o stanie szyfrowanych połączeń przechowywanych po stronie sprzętu. W trybie „stateful” klucze dla każdego połączenia są przechowywane na karcie sieciowej w specjalnej tabeli, analogicznie do sposobu, w jaki realizowane jest przyspieszenie sprzętowe w IPsec.
PSP oferuje swoistą kombinację możliwości protokołów TLS i IPsec/VPN. TLS odpowiadał Google pod względem ochrony na poziomie poszczególnych połączeń, ale zaczynał być niewystarczający ze względu na brak elastyczności dla przyspieszenia sprzętowego oraz brak wsparcia dla UDP. IPsec zapewniał niezależność od protokołów i dobrze wspierał przyspieszenie sprzętowe, ale nie obsługiwał powiązania kluczy z poszczególnymi połączeniami, był projektowany jedynie do niewielkiej liczby tuneli oraz miał problemy z wydajnością przyspieszenia sprzętowego z powodu przechowywania pełnego stanu szyfrowania w tabelach umieszczonych w pamięci karty sieciowej (na przykład do obsługi 10 mln połączeń wymagana jest pamięć 5 GB).
W przypadku PSP informacje o stanie szyfrowania (klucze, wektory inicjalizacji, numery sekwencyjne itp.) mogą być przesyłane w TX-deskriptorze pakietu lub w formie wskaźnika do pamięci systemu gospodarza, nie zajmując pamięci karty sieciowej. Według danych Google wcześniej na szyfrowanie ruchu RPC w infrastrukturze firmy wydawano około 0,7% mocy obliczeniowej i dużą ilość pamięci. Wdrożenie PSP poprzez wykorzystanie środków przyspieszenia sprzętowego pozwoliło obniżyć ten wskaźnik do 0,2%.
Źródło: opennet.ru
