大規模なハードウェアのオフロードを実現する PSP の暗号化がオープンソースで登場

※この投稿は米国時間 2022 年 5 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

10 年近く前、Google はユーザーのプライバシーを保護するために、データセンター間のトラフィックの暗号化を開始しました。それ以来 Google は、ほぼすべての転送中のデータを暗号化するべく、徐々に変更をロールアウトしてきました。Google の取り組みについて詳しくは、転送データの暗号化のホワイトペーパーをご覧ください。こうした取り組みによって、個別のプライバシーやセキュリティ上のメリットは得られましたが、ソフトウェアの暗号化には大きな代償が伴いました。というのも、リモート プロシージャ コール（RPC）と対応するメモリの暗号化および復号に、Google の処理能力の最大 0.7% を消費する必要がありました。現在、Google がオープンソースとして公開する PSP（再帰的頭字語で、PSP セキュリティ プロトコルのこと）を使った、ネットワーク インターフェース カード（NIC）への暗号化のオフロードが広まっているのは、こうした代償のためです。

Google の本番環境マシンは、厳格な分離要件を有する複数のテナント間で共有されています。そのため Google では、Transport Layer Security（TLS）と同様の、接続ごとの暗号化と認証を必須としています。Google ほどの規模であれば、数百万の伝送制御プロトコル（TCP）のライブ接続をサポートし、最大で毎秒 10 万の新規接続を維持できる暗号のオフロードを想定する必要があります。

オフロードに適したプロトコルを開発する前に、Google では現在の業界基準である Transport Layer Security（TLS）とインターネット プロトコル セキュリティ（IPsec）を調査しました。TLS はセキュリティ要件に合致していますが、カーネルの接続状態とハードウェアのオフロード状態が密結合にあるため、オフロードに適したソリューションであるとは言えません。また、TLS は UDP のような非 TCP トランスポート プロトコルもサポートしていません。

一方、IPsec プロトコルは、トランスポート独立で、ハードウェアへのオフロードも可能です。しかし、IPSec のオフロード ソリューションにも制約があります。関連する更新頻度の低いハードウェア テーブルで、すべての暗号化状態を保存していることが一因となり、必要な規模を経済的に支えることが不可能となっています。送信と受信の各エントリーのサイズを 256 バイトと仮定した場合、1,000 万接続に必要な総メモリは 5 GB（256 バイト x 2 x 1,000 万）で、一般的なオフロード エンジンの対応可能な容量を優に超えます。既存の IPsec のオフロード エンジンは、少数のサイト間トンネルの暗号化をサポートするように設計されています。最終的に、レイヤ 4 接続ごとの鍵のサポートがないことから、IPsec はセキュリティ要件に合致していないと判断しました。

これらの課題に対処するために、トランスポート独立で、接続ごとのセキュリティを実現し、オフロードに適している TLS のようなプロトコルである、PSP（再帰的頭字語で、PSP セキュリティ プロトコルのこと）を開発しました。

Google では、ユースケースに応じてこれらすべてのプロトコルを採用しています。たとえば、ユーザー向け接続には TLS を、サードパーティ製アプライアンスとの相互運用が必要なサイト間の暗号化には IPsec を、データセンター内とデータセンター間のトラフィックには PSP を使用しています。

PSP は、大規模なデータセンター トラフィックの要件に合うことを意識して設計されています。PSP では、特定の鍵交換プロトコルは必須ではなく、提供するパケット形式や暗号アルゴリズムの選択肢はわずかです。PSP は、レイヤ 4 接続（TCP 接続など）ごとの暗号鍵にすることで、接続ごとのセキュリティを実現しています。PSP では、パケットを送信するときに暗号化のステータスがパケット記述子内のデバイスに伝えられる場合や、セキュリティ パラメータ インデックス（SPI）やオンデバイスのマスターキーを使ってパケットを受信するときに暗号化のステータスが引き出される場合があるため、ステートレスなオペレーションをサポートしています。これにより、ハードウェアのステータスを最小限に抑えることができ、大規模なオンデバイス テーブルを維持する典型的なステートフル暗号化技術と比べて、ハードウェアのステータスの急増を防止することが可能です。

PSP は、カスタム ヘッダーとカスタム トレーラーを利用する User Datagram Protocol（UDP）のカプセル化を使用します。PSP のパケットはもともとの IP ヘッダーで始まり、事前に指定した宛先ポート上の UDP ヘッダー、PSP の情報を含む PSP ヘッダー、もともとの TCP / UDP パケット（ヘッダーとペイロードを含む）と続き、Integrity Checksum Value（ICV）を含む PSP トレーラーで終わります。レイヤ 4 パケット（ヘッダーとペイロード）は、Crypt Offset と呼ばれるユーザー提供のオフセットに基づいて、暗号化するか認証することができます。このフィールドは、たとえば、必要に応じてパケット サンプリングやネットワークの検査をサポートする際に、全体のパケットの暗号化を保ちながら、認証済みの TCP ヘッダーを転送中に一部、非暗号化する場合などに使用できます。

これは、トラフィックをアプリケーションに適切に帰属するうえでの重要な可視化機能で、IPsec では実現できません。注目して欲しいのは、UDP ヘッダーが UDP のチェックサムで保護されており、PSP ヘッダーが常に認証されていることです。

Google は、本番環境の Linux カーネルである Andromeda（Google のネットワーク仮想化スタック）と Snap（Google のホスト ネットワーキング システム）で PSP をサポートし、内部でのコミュニケーションと Cloud のお客様向けの両方で PSP を活用できるようにしています。2022 年現在、PSP の暗号のオフロードで、Google の処理能力の 0.5% を節約できています。

その他の暗号プロトコルと同じく、接続の両端で PSP のサポートが必要です。これは、古い NIC と新しい NIC（PSP 対応）が混ざった既存のデプロイでは困難な場合があります。Google は、PSP のソフトウェア実装（SoftPSP）を構築し、PSP 対応の NIC が古いマシンと通信できるようにして、ペア単位のサーバー接続におけるカバー範囲を劇的に向上させました。

PSP は、ゼロコピー手法と組み合わせることで、複数のメリットをもたらしてくれます。たとえば、送信と受信の両方における TCP のゼロコピーの影響は、ソフトウェア暗号化のためのペイロードの追加の読み取りと書き込みに限定されていました。しかし、PSP がそうした追加の読み込みと保存を取り除いたことで、RPC の処理ではもはやネットワーク スタック内のペイロードに触れる必要がなくなりました。たとえば、大規模な 1 MB の RPC では、PSP とゼロコピーを組み合わせることで、3 倍のスピードアップが実現しています。

Google は、PSP が業界に顕著なセキュリティ上のメリットを数多く提供してくれると確信しています。本番環境における確かな実績を踏まえ、PSP があらゆる場面や幅広い適用事例においてスケーラブルで安全なコミュニケーションの標準となることを期待しています。そのために、Google は PSP をオープンソース化することで、さらなる NIC ベンダーによるコミュニティやハードウェアでの実装といった幅広い導入を推進していきます。詳細については、http://github.com/google/psp をご参照ください。以下のような内容が含まれています。

• PSP アーキテクチャの仕様

• リファレンス ソフトウェアの実装

• 一連のテスト ケース

さらなる質問やディスカッションをご希望の場合は、PSP discussion Google グループにご参加いただくか、こちら psp-discuss@googlegroups.com からグループにお問い合わせください。

謝辞: PSP の開始以降ずっと協力してくれている、プラットフォーム、セキュリティ、カーネル ネットワーキング、RPC、Andromeda、その他のネットワーク インフラストラクチャのチームをはじめとするさまざまなチームの、技術インフラストラクチャおよび Cloud の多くの同僚たちに感謝します。