Google ogłosił otwarcie specyfikacji i referencyjnej implementacji protokołu PSP (PSP Security Protocol), służącego do szyfrowania ruchu pomiędzy centrami danych. Protokół wykorzystuje architekturę enkapsulacji ruchu podobną do IPsec ESP (Encapsulated Security Payloads) przez IP, zapewniając szyfrowanie, kontrolę integralności kryptograficznej i uwierzytelnianie źródła. Kod implementacyjny PSP napisany jest w języku C i rozpowszechniany na licencji Apache 2.0.
Cechą PSP jest optymalizacja protokołu w celu przyspieszenia obliczeń i zmniejszenia obciążenia centralnego procesora poprzez przeniesienie operacji szyfrowania i deszyfrowania na stronę kart sieciowych (odciążenie). Akceleracja sprzętowa wymaga specjalnych kart sieciowych kompatybilnych z PSP. W przypadku systemów z kartami sieciowymi, które nie obsługują PSP, proponowana jest implementacja programowa SoftPSP.
Protokół UDP służy jako transport do przesyłania danych. Pakiet PSP zaczyna się od nagłówka IP, po którym następuje nagłówek UDP, a następnie własny nagłówek PSP zawierający informacje o szyfrowaniu i uwierzytelnianiu. Następnie dołączana jest zawartość oryginalnego pakietu TCP/UDP, kończąc na końcowym bloku PSP z sumą kontrolną potwierdzającą integralność. Nagłówek PSP, a także nagłówek i dane kapsułkowanego pakietu są zawsze uwierzytelniane w celu potwierdzenia tożsamości pakietu. Dane zawarte w pakiecie mogą zostać zaszyfrowane, przy czym możliwe jest także selektywne szyfrowanie, przy jednoczesnym pozostawieniu części nagłówka TCP niezaznaczonej (przy zachowaniu kontroli autentyczności), na przykład w celu umożliwienia kontroli pakietów na sprzęcie sieci tranzytowej.
PSP nie jest powiązany z żadnym konkretnym protokołem wymiany kluczy, oferuje kilka opcji formatu pakietu i obsługuje użycie różnych algorytmów kryptograficznych. Na przykład zapewniona jest obsługa algorytmu AES-GCM do szyfrowania i uwierzytelniania (uwierzytelniania) oraz AES-GMAC do uwierzytelniania bez szyfrowania rzeczywistych danych, na przykład gdy dane nie są wartościowe, ale trzeba upewnić się, że nie zostały zostały naruszone podczas transmisji i że są to te właściwe, które zostały pierwotnie wysłane.
W odróżnieniu od typowych protokołów VPN, PSP wykorzystuje szyfrowanie na poziomie poszczególnych połączeń sieciowych, a nie całego kanału komunikacji, tj. PSP używa oddzielnych kluczy szyfrowania dla różnych tunelowanych połączeń UDP i TCP. Takie podejście pozwala na ściślejszą izolację ruchu z różnych aplikacji i procesorów, co jest istotne w przypadku, gdy na tym samym serwerze działają aplikacje i usługi różnych użytkowników.
Google używa protokołu PSP zarówno do ochrony własnej komunikacji wewnętrznej, jak i do ochrony ruchu klientów Google Cloud. Protokół jest początkowo zaprojektowany do efektywnej pracy w infrastrukturze na poziomie Google i powinien zapewniać sprzętowe przyspieszenie szyfrowania w obecności milionów aktywnych połączeń sieciowych oraz ustanawiania setek tysięcy nowych połączeń na sekundę.
Obsługiwane są dwa tryby pracy: „stanowy” i „bezstanowy”. W trybie „bezstanowym” klucze szyfrujące przesyłane są do karty sieciowej w deskryptorze pakietu, a w celu odszyfrowania są wyodrębniane z pola SPI (indeks parametrów bezpieczeństwa) obecnego w pakiecie przy użyciu klucza głównego (256-bitowy AES, przechowywany w pamięci karty sieciowej i wymieniana co 24 godziny), co pozwala zaoszczędzić pamięć karty sieciowej i zminimalizować informacje o stanie szyfrowanych połączeń przechowywane po stronie sprzętu. W trybie „stanowym” klucze dla każdego połączenia są przechowywane na karcie sieciowej w specjalnej tabeli, podobnie jak przyspieszanie sprzętowe jest realizowane w IPsec.
PSP zapewnia unikalną kombinację możliwości protokołu TLS i IPsec/VPN. TLS odpowiadał Google pod względem bezpieczeństwa połączenia, ale nie był odpowiedni ze względu na brak elastyczności w zakresie przyspieszania sprzętowego i brak obsługi UDP. IPsec zapewniał niezależność protokołu i dobrze obsługiwał akcelerację sprzętową, ale nie obsługiwał przypisywania kluczy do poszczególnych połączeń, był zaprojektowany tylko dla niewielkiej liczby tworzonych tuneli i miał problemy ze skalowaniem akceleracji sprzętowej ze względu na przechowywanie pełnego stanu szyfrowania w tabelach znajdujących się w pamięci karty sieciowej (np. do obsługi 10 milionów połączeń potrzeba 5 GB pamięci).
W przypadku PSP informacja o stanie szyfrowania (klucze, wektory inicjujące, numery sekwencyjne itp.) może być przesyłana w deskryptorze pakietu TX lub w postaci wskaźnika do pamięci systemu hosta, bez zajmowania pamięci karty sieciowej. Według Google’a na szyfrowanie ruchu RPC w infrastrukturze firmy przeznaczono wcześniej około 0.7% mocy obliczeniowej i dużą ilość pamięci. Wprowadzenie PSP poprzez zastosowanie akceleracji sprzętowej umożliwiło zmniejszenie tego wskaźnika do 0.2%.
Źródło: opennet.ru