Google malkovris evoluojn rilatajn al la sekura retprotokolo de PSP

Google anoncis la malfermon de specifoj kaj referenca efektivigo de la PSP (PSP Security Protocol), uzata por ĉifri trafikon inter datumcentroj. La protokolo uzas trafikan enkapsulan arkitekturon similan al IPsec ESP (Encapsulating Security Payloads) super IP, disponigante ĉifradon, kriptan integreckontrolon kaj fontkonfirmon. La realigkodo de PSP estas skribita en C kaj distribuita sub la licenco Apache 2.0.

Karakterizaĵo de PSP estas la optimumigo de la protokolo por akceli kalkulojn kaj redukti la ŝarĝon sur la centra procesoro movante ĉifrajn kaj malĉifrajn operaciojn al la flanko de retaj kartoj (malŝarĝo). Akcelado de aparataro postulas specialajn PSP-kongruajn retkartojn. Por sistemoj kun retkartoj kiuj ne apogas PSP, softvara efektivigo de SoftPSP estas proponita.

La UDP-protokolo estas uzata kiel transporto por transdono de datumoj. PSP-pakaĵeto komenciĝas per IP-titolo, sekvita per UDP-kapo, kaj tiam sia propra PSP-kapo kun ĉifrado kaj aŭtentikiginformoj. Poste, la enhavo de la origina TCP/UDP-pakaĵeto estas almetita, finiĝante kun fina PSP-bloko kun ĉeksumo por konfirmi integrecon. La PSP-titolo, same kiel la kaplinio kaj datenoj de la enkapsuligita pakaĵeto, ĉiam estas aŭtentikigitaj por konfirmi la identecon de la pakaĵeto. La datenoj de la enkapsuligita pakaĵeto povas esti ĉifritaj, dum estas eble selekteme apliki ĉifradon lasante parton de la TCP-kapo en la klara (daŭrigante aŭtenteckontrolon), ekzemple, por disponigi la kapablon inspekti pakaĵetojn sur transitretikipaĵo.

Google malkovris evoluojn rilatajn al la sekura retprotokolo de PSP

PSP ne estas ligita al iu specifa ŝlosila interŝanĝo protokolo, ofertas plurajn pakaĵetformatajn opciojn kaj subtenas la uzon de malsamaj kriptografiaj algoritmoj. Ekzemple, subteno estas provizita por la algoritmo AES-GCM por ĉifrado kaj aŭtentikigo (aŭtentikigo) kaj AES-GMAC por aŭtentikigo sen ĉifrado de la realaj datumoj, ekzemple kiam la datumoj ne estas valoraj, sed vi devas certigi, ke ĝi ne havas. estis mistraktitaj dum transdono kaj ke ĝi estas la ĝusta. kiuj estis origine senditaj.

Male al tipaj VPN-protokoloj, PSP uzas ĉifradon je la nivelo de individuaj retkonektoj, kaj ne la tutan komunikadkanalon, t.e. PSP uzas apartajn ĉifradŝlosilojn por malsamaj tunelitaj UDP kaj TCP-ligoj. Ĉi tiu aliro ebligas atingi pli striktan izolitecon de trafiko de malsamaj aplikoj kaj procesoroj, kio estas grava kiam aplikoj kaj servoj de malsamaj uzantoj funkcias sur la sama servilo.

Google uzas la PSP-protokolon kaj por protekti siajn proprajn internajn komunikadojn kaj por protekti la trafikon de klientoj de Google Cloud. La protokolo estas komence desegnita por funkcii efike en Guglo-nivelaj infrastrukturoj kaj devus provizi aparatan akcelon de ĉifrado en la ĉeesto de milionoj da aktivaj retaj konektoj kaj la establado de centoj da miloj da novaj ligoj sekundo.

Du operaciaj reĝimoj estas subtenataj: "ŝtata" kaj "senŝtata". En "sennacia" reĝimo, ĉifradŝlosiloj estas elsenditaj al la retkarto en la pakaĵpriskribilo, kaj por malĉifrado ili estas ĉerpitaj de la SPI (Security Parameter Index) kampo ĉeestanta en la pakaĵeto uzante ĉefŝlosilon (256-bita AES, stokita en la memoro de la retkarto kaj anstataŭigita ĉiujn 24 horojn), kio ebligas al vi ŝpari retan karton-memoron kaj minimumigi informojn pri la stato de ĉifritaj konektoj stokitaj ĉe la ekipaĵo. En "ŝtata" reĝimo, la ŝlosiloj por ĉiu konekto estas stokitaj sur la retkarto en speciala tabelo, simile al kiel aparatara akcelo estas efektivigita en IPsec.

Google malkovris evoluojn rilatajn al la sekura retprotokolo de PSP

PSP provizas unikan kombinaĵon de TLS kaj IPsec/VPN-protokolkapabloj. TLS konvenis al Guglo laŭ po-koneksa sekureco, sed ne estis taŭga pro ĝia manko de fleksebleco por hardvarakcelado kaj manko de UDP-subteno. IPsec disponigis protokolsendependecon kaj apogis hardvarakceladon bone, sed ne apogis ŝlosilligadon al individuaj ligoj, estis dizajnita por nur malmulto de tuneloj kreitaj, kaj havis problemojn skali hardvarakceladon pro stokado de la plena ĉifrada stato en tabeloj situantaj en la memoro. de la retkarto (ekzemple, 10 GB da memoro necesas por trakti 5 milionojn da konektoj).

Koncerne PSP, informoj pri la stato de ĉifrado (ŝlosiloj, inicialigvektoroj, sekvencnombroj, ktp.) povas esti elsenditaj en la TX-pakaĵpriskribilo aŭ en la formo de montrilo al gastiga sistemmemoro, sen okupado de retkartmemoro. Laŭ Google, proksimume 0.7% de komputika potenco kaj granda kvanto da memoro antaŭe estis elspezitaj por ĉifrado de RPC-trafiko en la infrastrukturo de la firmao. La enkonduko de PSP per la uzo de aparatara akcelo ebligis redukti ĉi tiun ciferon al 0.2%.

fonto: opennet.ru

Aldoni komenton