Google heeft de opening aangekondigd van specificaties en een referentie-implementatie van het PSP (PSP Security Protocol), dat wordt gebruikt om verkeer tussen datacenters te coderen. Het protocol maakt gebruik van een architectuur voor het inkapselen van verkeer, vergelijkbaar met IPsec ESP (Encapsulated Security Payloads) over IP, en biedt encryptie, cryptografische integriteitscontrole en bronauthenticatie. De PSP-implementatiecode is geschreven in C en gedistribueerd onder de Apache 2.0-licentie.
Een kenmerk van PSP is de optimalisatie van het protocol om berekeningen te versnellen en de belasting van de centrale processor te verminderen door coderings- en decoderingsbewerkingen naar de zijkant van netwerkkaarten te verplaatsen (offload). Voor hardwareversnelling zijn speciale PSP-compatibele netwerkkaarten vereist. Voor systemen met netwerkkaarten die PSP niet ondersteunen, wordt een software-implementatie van SoftPSP voorgesteld.
Het UDP-protocol wordt gebruikt als transportmiddel voor gegevensoverdracht. Een PSP-pakket begint met een IP-header, gevolgd door een UDP-header en vervolgens zijn eigen PSP-header met coderings- en authenticatie-informatie. Vervolgens wordt de inhoud van het originele TCP/UDP-pakket toegevoegd, eindigend met een laatste PSP-blok met een controlesom om de integriteit te bevestigen. De PSP-header, evenals de header en gegevens van het ingekapselde pakket, worden altijd geverifieerd om de identiteit van het pakket te bevestigen. De gegevens van het ingekapselde pakket kunnen worden gecodeerd, terwijl het mogelijk is om selectief encryptie toe te passen terwijl een deel van de TCP-header vrij blijft (terwijl de authenticiteitscontrole behouden blijft), bijvoorbeeld om de mogelijkheid te bieden om pakketten op transitnetwerkapparatuur te inspecteren.
PSP is niet gebonden aan een specifiek sleuteluitwisselingsprotocol, biedt verschillende pakketformaatopties en ondersteunt het gebruik van verschillende cryptografische algoritmen. Zo wordt er ondersteuning geboden voor het AES-GCM algoritme voor encryptie en authenticatie (authenticatie) en AES-GMAC voor authenticatie zonder encryptie van de daadwerkelijke data, bijvoorbeeld wanneer de data niet waardevol zijn, maar je moet ervoor zorgen dat deze niet waardevol is. tijdens de verzending is geknoeid en dat het de juiste is die oorspronkelijk zijn verzonden.
In tegenstelling tot typische VPN-protocollen gebruikt PSP codering op het niveau van individuele netwerkverbindingen, en niet op het hele communicatiekanaal, d.w.z. PSP gebruikt afzonderlijke coderingssleutels voor verschillende getunnelde UDP- en TCP-verbindingen. Deze aanpak maakt het mogelijk om een striktere isolatie van verkeer van verschillende applicaties en processors te realiseren, wat belangrijk is wanneer applicaties en diensten van verschillende gebruikers op dezelfde server draaien.
Google gebruikt het PSP-protocol zowel om zijn eigen interne communicatie te beschermen als om het verkeer van Google Cloud-clients te beschermen. Het protocol is in eerste instantie ontworpen om effectief te werken in infrastructuren op Google-niveau en zou hardwareversnelling van de encryptie moeten bieden in de aanwezigheid van miljoenen actieve netwerkverbindingen en het tot stand brengen van honderdduizenden nieuwe verbindingen per seconde.
Er worden twee bedrijfsmodi ondersteund: “stateful” en “stateless”. In de “stateless” modus worden encryptiesleutels in de pakketdescriptor naar de netwerkkaart verzonden en voor decryptie worden ze uit het SPI-veld (Security Parameter Index) gehaald dat in het pakket aanwezig is met behulp van een hoofdsleutel (256-bit AES, opgeslagen in het geheugen van de netwerkkaart en wordt elke 24 uur vervangen), waardoor u netwerkkaartgeheugen kunt besparen en informatie over de status van gecodeerde verbindingen die aan de apparatuurzijde is opgeslagen, kunt minimaliseren. In de “stateful” modus worden de sleutels voor elke verbinding op de netwerkkaart opgeslagen in een speciale tabel, vergelijkbaar met hoe hardwareversnelling wordt geïmplementeerd in IPsec.
PSP biedt een unieke combinatie van TLS- en IPsec/VPN-protocolmogelijkheden. TLS was geschikt voor Google wat betreft beveiliging per verbinding, maar was niet geschikt vanwege het gebrek aan flexibiliteit voor hardwareversnelling en het gebrek aan UDP-ondersteuning. IPsec zorgde voor protocolonafhankelijkheid en ondersteunde hardwareversnelling goed, maar ondersteunde geen sleutelbinding aan individuele verbindingen, was ontworpen voor slechts een klein aantal gecreëerde tunnels en had problemen met het schalen van hardwareversnelling vanwege het opslaan van de volledige coderingsstatus in tabellen in het geheugen van de netwerkkaart (er is bijvoorbeeld 10 GB geheugen nodig om 5 miljoen verbindingen te verwerken).
In het geval van PSP kan informatie over de staat van de codering (sleutels, initialisatievectoren, volgnummers, enz.) worden verzonden in de TX-pakketdescriptor of in de vorm van een verwijzing naar het hostsysteemgeheugen, zonder het geheugen van de netwerkkaart in beslag te nemen. Volgens Google werd voorheen ongeveer 0.7% van de rekenkracht en een grote hoeveelheid geheugen besteed aan het versleutelen van RPC-verkeer in de infrastructuur van het bedrijf. De introductie van PSP door het gebruik van hardwareversnelling maakte het mogelijk dit cijfer terug te brengen tot 0.2%.
Bron: opennet.ru