Кампанія Google абвясціла аб адкрыцці спецыфікацый і эталоннай рэалізацыі пратакола PSP (PSP Security Protocol), які ўжываецца для шыфравання трафіку паміж датацэнтрамі. Пратакол выкарыстоўвае падобную на IPsec ESP (Encapsulating Security Payloads) архітэктуру інкапсуляцыі трафіку па-над IP, забяспечваючы шыфраванне, крыптаграфічны кантроль цэласнасці і аўтэнтыфікацыю крыніцы. Код рэалізацыі PSP напісаны на мове Сі і распаўсюджваецца пад ліцэнзіяй Apache 2.0.
Асаблівасцю PSP з'яўляецца аптымізацыя пратакола для паскарэння вылічэнняў і зніжэнні нагрузкі на цэнтральны працэсар праз вынас аперацый шыфравання і расшыфроўкі на бок сеткавых карт (offload). Для прымянення апаратнага паскарэння патрабуецца наяўнасць спецыяльных сеткавых карт, сумяшчальных з PSP. Для сістэм з сеткавымі картамі, якія не падтрымліваюць PSP, прапанавана праграмная рэалізацыя SoftPSP.
У якасці транспарта для перадачы даных выкарыстоўваецца пратакол UDP. Пакет PSP пачынаецца з загалоўка IP, пасля якога варта загаловак UDP і затым уласны загаловак PSP з інфармацыяй аб шыфраванні і аўтэнтыфікацыі. Далей прымацоўваецца змесціва арыгінальнага пакета TCP/UDP, якое завяршаецца фінальным блокам PSP з кантрольнай сумай для пацверджання цэласнасці. Загаловак PSP, а таксама загаловак і дадзеныя инкапсулируемого пакета заўсёды аўтэнтыфікаваны для пацверджання сапраўднасці пакета. Дадзеныя инкапсулируемого пакета могуць могуць быць зашыфраваны, пры гэтым дапушчаецца магчымасць выбарковага ўжывання шыфравання з пакіданнем часткі TCP-загалоўка ў адчыненым выглядзе (пры захаванні кантролю сапраўднасці), напрыклад, для падавання магчымасці інспектавання пакетаў на транзітным сеткавым абсталяванні.
PSP не прывязваецца да нейкага вызначанага пратаколу абмену ключамі, прапануе некалькі варыянтаў фармату пакетаў і падтрымлівае выкарыстанне розных крыптаалгарытмаў. Напрыклад, прадастаўляецца падтрымка алгарытму AES-GCM для шыфравання і праверкі сапраўднасці (аўтэнтыфікацыі) і AES-GMAC для праверкі сапраўднасці без шыфравання непасрэдных дадзеных, напрыклад калі дадзеныя не ўяўляюць каштоўнасці, але трэба гарантаваць, што яны не былі падменены падчас перадачы і менавіта тыя , што былі адпраўленыя першапачаткова.
У адрозненне ад тыпавых VPN-пратаколаў у PSP ужываецца шыфраванне на ўзроўні асобных сеткавых злучэнняў, а не ўсяго канала сувязі, г.зн. PSP выкарыстоўвае асобныя ключы шыфравання для розных тунэляваных UDP-і TCP-злучэнняў. Падобны падыход дае магчымасць дамагчыся стражэйшай ізаляцыі трафіку ад розных прыкладанняў і апрацоўшчыкаў, што актуальна пры выкананні на адным серверы прыкладанняў і сэрвісаў розных карыстачоў.
У Google пратакол PSP ужываецца як для абароны ўласных унутраных камунікацый, так і для абароны трафіку кліентаў Google Cloud. Пратакол першапачаткова разлічаны на эфектыўную працу ў інфраструктурах узроўня Google і павінен забяспечваць апаратнае паскарэнне шыфравання ва ўмовах наяўнасці мільёнаў актыўных сеткавых злучэнняў і ўсталёўкі сотняў тысяч новых злучэнняў у секунду.
Падтрымліваецца два рэжыму працы - "stateful" і "stateless". У рэжыме "stateless" ключы для шыфравання перадаюцца сеткавай карце ў дэскрыптары пакета, а для расшыфроўкі здабываюцца з прысутнага ў пакеце поля SPI (Security Parameter Index) пры дапамозе майстар-ключа (256-bit AES, захоўваецца ў памяці сеткавай карты і замяняецца кожныя 24 гадзіны), што дазваляе эканоміць памяць сеткавай карты і мінімізаваць інфармацыю аб стане шыфраваных злучэнняў, якая захоўваецца на баку абсталявання. У рэжыме "stateful" ключы для кожнага злучэння захоўваюцца на сеткавай карце ў спецыяльнай табліцы, па аналогіі тым як рэалізавана апаратнае паскарэнне ў IPsec.
PSP дае своеасаблівую камбінацыю магчымасцяў пратаколаў TLS і IPsec/VPN. TLS падыходзіў Google з пункта гледжання абароны на ўзроўні асобных злучэнняў, але не задавальняў з-за недастатковай гнуткасці для апаратнага паскарэння і адсутнасці падтрымкі UDP. IPsec забяспечваў незалежнасць ад пратаколаў і добра падтрымліваў апаратнае паскарэнні, але не падтрымліваў прывязку ключоў да асобных злучэнняў, быў разлічаны толькі на невялікую колькасць ствараных тунэляў і меў праблемы з маштабаваннем апаратнага паскарэння з-за захоўвання поўнага стану шыфравання ў табліцах, якія размяшчаюцца ў памяці сеткавай карты. (напрыклад, для апрацоўкі 10 злучэнняў патрабуецца 5 ГБ памяці).
У выпадку PSP інфармацыя аб стане шыфравання (ключы, вектары ініцыялізацыі, парадкавыя нумары і да т.п.) можа перадавацца ў TX-дэскрыптары пакета або ў форме паказальніка на памяць хост-сістэмы, не займаючы памяць сеткавай карты. Па дадзеных Google раней на шыфраванне RPC-трафіку ў інфраструктуры кампаніі марнавалася прыкладна 0.7% вылічальнай магутнасці і вялікі аб'ём памяці. Укараненне PSP за кошт прыцягнення сродкаў апаратнага паскарэння дазволіла знізіць гэты паказчык да 0.2%.
Крыніца: opennet.ru