著者: Cesar Ghali、Adam Stubblefield、Ed Knapp、Jiangtao Li、Benedikt Schmidt、Julien Boeuf
このドキュメントの内容は 2017 年 12 月時点のものです。このホワイトペーパーは作成時点の状況を表しています。お客様の保護の継続的改善のため、Google Cloud のセキュリティ ポリシーおよびシステムは適宜変更される場合があります。
PDF 版をダウンロード
CIO レベルの概要
- Google の Application Layer Transport Security（ALTS）は、Google が開発した相互認証および転送暗号化システムです。ALTS は通常、Google のインフラストラクチャ内におけるリモート プロシージャ コール（RPC）通信を保護するために使用されます。ALTS は概念的に相互認証 TLS と似ていますが、Google のデータセンター環境のニーズを満たすよう設計および改善されています。
- ALTS の信頼モデルは、クラウドのようなコンテナ化されたアプリケーションに合わせて調整されています。ID は特定のサーバー名またはホストではなく、エンティティにバインドされます。この信頼モデルは、ホスト間でのシームレスなマイクロサービス複製、負荷分散、および再スケジューリングを容易にします。
- ALTS は、handshake プロトコル（セッション再開あり）とレコード プロトコルという 2 つのプロトコルに依存しています。これらのプロトコルはセッションの確立や、その認証、暗号化、再開の方法を管理します。
- ALTS は Google が使用しているカスタムのトランスポート層セキュリティ ソリューションです。Google では本番環境に合わせて ALTS を調整しているため、ALTS と業界標準である TLS との間にはいくらかのトレードオフがあります。詳細については、トレードオフをご覧ください。
はじめに
Google の本番環境システムは、1 秒あたり O（1010）個のリモート プロシージャ コール（RPC）をまとめて発行するマイクロサービス1 のコンスタレーションで構成されています。Google のエンジニアが本番環境ワークロード2 をスケジュールすると、そのワークロードで発行または受信された RPC は、デフォルトで ALTS によって保護されます。この構成不要の自動的な保護は、Google の Application Layer Transport Security（ALTS）によって提供されます。ALTS では RPC にこの自動保護が与えられることに加えて、本番環境マシン間での簡単なサービス複製、負荷分散、再スケジューリングが容易になります。このホワイトペーパーでは ALTS について説明し、Google の本番環境インフラストラクチャ上におけるそのデプロイについて見ていきます。
対象者: このドキュメントは、Google で認証と転送のセキュリティがどのように実行されているかについて関心をお持ちの、インフラストラクチャ セキュリティの専門家を対象としています。
前提条件: 読者はこの概要の知識に加えて、Google でのクラスタ管理についても基本的な理解を有していることを前提とします。
アプリケーション レベルのセキュリティと ALTS
ウェブブラウザから VPN に至るまで、多くのアプリケーションは TLS（Transport Layer Security）や IPSec などの安全な通信プロトコルに依存して、転送中のデータを保護しています3。Google では、アプリケーション レイヤで動作する相互認証および転送暗号化システムである ALTS を使用して、RPC 通信を保護しています。アプリケーション レベルのセキュリティを使用すると、各アプリケーションが認証されたリモートピア ID を持つことができ、それを利用してきめ細かな認証ポリシーを実装することが可能になります。
TLS を使用しない理由
現在のインターネット トラフィックの大部分が TLS を使用して暗号化されている中で、Google が ALTS のようなカスタムのセキュリティ ソリューションを使用していることは奇妙に思われるかもしれません。ALTS は 2007 年、Google が開発を開始しました。当時 TLS は、Google の最低限のセキュリティ基準を満たさない数多くのレガシー プロトコルのサポートにバンドルされていました。Google では、必要な TLS コンポーネントを採用し望ましいものを実装することで独自のセキュリティ ソリューションを設計することも可能でしたが、より Google に適したシステムを一から構築するほうが、既存のシステムにパッチを当てるよりもメリットが大きいと判断しました。さらに ALTS は Google のニーズにより適しており、過去の状況を鑑みても、古い TLS よりも安全性に優れています。以下に、TLS と ALTS の主な違いを示します。
- HTTPS のセマンティクスを使用した TLS の信頼モデル4 と ALTS には大きな違いがあります。前者では、サーバー ID は特定の名前とそれに対応する命名スキームにバインドされています。ALTS では、同じ ID を複数の命名スキームで使用できます。このレベルの間接性によって柔軟性が向上し、ホスト間でのマイクロサービス複製、負荷分散、再スケジューリングのプロセスが大幅に簡略化されます。
- TLS と比較して、ALTS は設計と実装が容易です。その結果、ソースコードの手動検査や広範なファジングによってバグやセキュリティの脆弱性をモニタリングすることがより簡単になっています。
- ALTS ではプロトコル バッファを使用して証明書やプロトコル メッセージがシリアル化されますが、TLS では ASN.1 でエンコードされた X.509 証明書が使用されます。Google の本番環境サービスの大部分は、プロトコル バッファを使用して通信（および場合によってはストレージ）を行っているため、ALTS のほうが Google の環境により適したものとなっています。
ALTS の設計
ALTS は高い信頼性を誇るシステムとして設計されており、ユーザーの関与を最小限に抑えたサービス間認証とセキュリティを実現しています。これを達成するため、以下のような特性が ALTS の設計の一部となっています。
- 透過性: ALTS 構成はアプリケーション レイヤに対して透過的です。デフォルトでは、サービス RPC が ALTS によって保護されます。そのためアプリケーション デベロッパーは、認証情報の管理やセキュリティ構成について心配することなく、サービスの機能ロジックに集中できます。サービス間接続の確立時、ALTS は認証されたリモートピア ID 情報をアプリケーションに提供します。これを使用することで、きめ細かな認証チェックと監査が可能になります。
- 最先端の暗号化: ALTS で使用されているすべての暗号プリミティブおよびプロトコルは、現在の既知の攻撃について最新のものです。ALTS は Google が管理するマシン上で動作します。つまり、サポートされているすべての暗号プロトコルは、簡単にアップグレードして迅速に導入できます。
- ID モデル： ALTS は認証を、ホスト名ではなく主に ID で実行します。Google ではすべてのネットワーク エンティティ（企業ユーザー、物理マシン、本番環境のサービスやワークロードなど）に、関連付けられた ID があります。サービス間のすべての通信は相互に認証されます。
- キーの配布: ALTS は ID を持つ各ワークロードに依存します。ID は一連の認証情報として表されます。こうした認証情報は、ユーザーの関与なしに、初期化時に各ワークロード内でデプロイされます。それと並行して、それらの認証情報の信頼ルートと信頼チェーンがマシンとワークロードに対して確立されます。このシステムでは、アプリケーション デベロッパーの介入なしに、自動での証明書のローテーションと取り消しが可能になっています。
- スケーラビリティ: ALTS は Google の大規模なインフラストラクチャをサポートするため、非常にスケーラブルに設計されています。この要件により、効率的なセッションの再開が開発されました。
- 長時間接続: 認証された鍵交換の暗号オペレーションは、コンピューティング コストが高くなります。Google のインフラストラクチャの規模に対応するため、初回の ALTS handshake の後は、接続を長期間維持することで、システムの全体的なパフォーマンスを向上できます。
- シンプルさ: TLS はデフォルトで、レガシーのプロトコル バージョンと下位互換性をサポートしています。一方 ALTS は、Google がクライアントとサーバーの両方を制御しており、それらがネイティブで ALTS をサポートするように設計されているため、はるかにシンプルになっています。
ALTS の信頼モデル
ALTS は認証を、ホストではなく主に ID で実行します。Google では、すべてのネットワーク エンティティ（企業ユーザー、物理マシン、本番環境サービスなど）に、関連付けられた ID があります。これらの ID は ALTS 証明書に埋め込まれており、セキュアな接続の確立時のピア認証に使用されます。Google が追求しているモデルは、Google の本番環境サービスを、サイト信頼性エンジニア（SRE）5 が管理できる本番環境エンティティとして実行することです。これらの本番環境サービスの開発バージョンは、SRE と開発者の両者が管理できるテスト エンティティとして実行されます。
たとえば、「service-frontend」と「service-backend」という 2 つのサービスを含むプロダクトがあるとします。SRE はこうしたサービスの本番環境バージョンである、「service-frontend-prod」および「service-backend-prod」を起動できます。開発者はテストのため、このサービスの開発バージョン「service-frontend-dev」と「service-backend-dev」をビルドして起動することができます。本番環境サービスの承認構成は、各サービスの開発バージョンを信頼しないように構成されます。
ALTS の認証情報
ALTS の認証情報には 3 種類あり、すべてプロトコル バッファ メッセージ形式で表現されます。
- マスター証明書: リモートの署名サービスによって署名され、handshake 証明書の検証に使用されます。マスター証明書には、RSA 鍵ペアなどのマスター秘密鍵に関連付けられた公開鍵が含まれています。この秘密鍵は handshake 証明書への署名に使用されます。こうした証明書は、以下で説明する ALTS ポリシーと組み合わせて使用する場合、基本的に制限付きの中間認証局（CA）の証明書となります。マスター証明書は通常、Borgmaster6 のようなコンテナ化されたワークロードの本番環境マシンとスケジューラに対して発行されます。
- handshake 証明書: マスター秘密鍵によってローカルに作成および署名されます。この証明書には、静的な Diffie-Hellman（DH）パラメータや handshake 暗号など、ALTS handshake（セキュアな接続の確立）の際に使用されるパラメータが含まれています。また handshake 証明書には、その派生元となるマスター証明書、すなわち handshake 証明書に署名するマスター秘密鍵に関連付けられた証明書が含まれています。
- 再開鍵: 再開チケットを暗号化するために使用される秘密鍵です。この鍵は、同じデータセンター セル内で同じ ID で実行されるすべての本番環境ワークロード間で一意であり、そこで共有される、再開識別子 IDR で識別されます。ALTS でのセッション再開の詳細については、セッションの再開をご覧ください。
図 1 は、署名サービスの検証鍵、マスター証明書、handshake 証明書で構成される、ALTS 証明書チェーンを示しています。署名サービスの検証鍵は ALTS における信頼のルートであり、Google の本番環境ネットワークや企業ネットワーク内のすべての Google マシンにインストールされます。
図 1: ALTS 証明書チェーン
ALTS では署名サービスがマスター証明書を認証し、次にそのマスター証明書が handshake 証明書を認証します。handshake 証明書はマスター証明書より頻繁に作成されるため、このアーキテクチャによって署名サービスの負荷が軽減されます。Google では特に handshake 証明書について、証明書のローテーションが頻繁に発生します7。この頻繁なローテーションにより、handshake 証明書に含まれる静的な鍵交換ペアが補われます8。
証明書の発行
ネットワーク上のエンティティを ALTS のセキュアな handshake に参加させるには、エンティティに handshake 証明書をプロビジョニングする必要があります。発行元はまず、署名サービスによって署名されたマスター証明書を取得し、それを必要に応じてエンティティに渡します。次に handshake 証明書が作成され、関連付けられたマスター秘密鍵によって署名されます。
発行元は通常、マシンや人に対して証明書を発行するときは Google 内部の認証局（CA）、ワークロードに対して証明書を発行するときは Borgmaster になります。ただしこれは、たとえばテスト データセンター セルに対しては制限付き Borgmaster など、他のエンティティであってもかまいません。
図 2 は、署名サービスを使用してマスター証明書を作成する方法を示しています。このプロセスは以下の手順で構成されます。
図 2: 証明書の発行
- 証明書の発行元が、証明書署名リクエスト（CSR）を署名サービスに送信します。このリクエストは ID A の証明書を作成するよう署名サービスに要求するものです。この ID はたとえば企業ユーザーや、Google の本番環境サービスの ID などにできます。
- 署名サービスは証明書の発行元（CSR に含まれる）を、リクエスト元（この場合は証明書の発行元）に設定して署名します。対応する署名サービスの公開（検証）鍵が、すべての Google マシンにインストールされていることを思い出してください。
- 署名サービスが、署名された証明書を返送します。
- ID A の handshake 証明書が作成され、マスター証明書に関連付けられた秘密鍵によって署名されます。
上記のプロセスに示されるように、ALTS では証明書の発行元と署名者は 2 つの異なる論理エンティティになります。この場合、発行元は証明書の発行元エンティティであり、署名者は署名サービスです。
ALTS には、人、マシン、ワークロードという 3 つの一般的な証明書カテゴリがあります。以下のセクションでは、これらの証明書がそれぞれ ALTS でどのように作成され使用されるかを概説します。
人の証明書
Google では ALTS を使用して、人間のユーザーが本番環境サービスに対して発行する RPC を保護しています。RPC を発行するには、ユーザーが有効な handshake 証明書を提供する必要があります。たとえば A さんがアプリケーションを使用して、ALTS で保護される RPC を発行する場合、Google の内部 CA に対して認証することができます。この場合はユーザー名、パスワード、2 要素認証プロセスを使用して CA への認証を行います。このオペレーションの結果、A さんは 20 時間有効な handshake 証明書を取得できます。
マシン証明書
Google のデータセンターのすべての本番環境マシンには、マシンのマスター証明書があります。この証明書はマシン管理デーモンなど、そのマシン上のコア アプリケーションの handshake 証明書を作成するために使用されます。マシン証明書に埋め込まれている主な ID は、マシンの一般的な目的を表します。たとえば、異なる種類の本番環境ワークロードおよび開発ワークロードを実行するために使用されるマシンは、異なる ID を持つことができます。マスター証明書は検証済みのソフトウェア スタックを実行しているマシンでのみ使用できます。場合によっては、この信頼のルートがカスタムのセキュリティ ハードウェアにあることもあります9。本番環境マシンのマスター証明書はすべて CA によって発行され、数か月ごとにローテーションされます。また、すべての handshake 証明書は数時間ごとにローテーションされます。
ワークロード証明書
ALTS の重要な利点は、ワークロード ID の発想で機能しているため、マシン間での簡単なサービス複製、負荷分散、再スケジューリングが容易になることです。Google の本番環境ネットワークでは、Borg10 というシステムを使用してクラスタ管理とマシンリソースの割り当てを大規模に行っています。Borg による証明書の発行方法は、ALTS のマシンに依存しないワークロード ID の実装の一部です。
Google の本番環境ネットワークの各ワークロードは、Borg セルで実行されます。各セルには Borgmaster という論理的に一元化されたコントローラと、そのセル内の各マシン上で実行される Borglets という複数のエージェント プロセスが含まれています。ワークロードは Borgmaster が発行した、関連付けられたワークロード handshake 証明書によって初期化されます。図 3 は、Borg を使用した ALTS でのワークロード認証のプロセスを示しています。
図 3: Google の本番環境ネットワークにおける handshake 証明書の作成
Borgmaster はこれで、ALTS を使用する必要のあるワークロードをスケジューリングできます。以下の手順は、クライアントが Borg 上で特定の ID として実行するワークロードをスケジューリングするときに発生します。
- 各 Borgmaster には、マシンマスター証明書と、関連付けられた秘密鍵（図には示していません）があらかじめインストールされています。
- ALTSd11 は Borgmaster の handshake 証明書を生成し、マシンマスター秘密鍵を使用してそれに署名します。この handshake 証明書により、Borgmaster は ALTS で保護される RPC を発行できます。
- Borgmaster がベース ワークロード マスター証明書と、対応する秘密鍵を作成します。Borgmaster は、署名サービスによって署名されたこのベース ワークロード マスター証明書を取得するためのリクエスト（ALTS で保護される RPC）を開始します。その結果、署名サービスは Borgmaster をこの証明書に発行元として記録します。
- Borgmaster はクライアントが、ワークロードをワークロード構成で指定された ID として実行する権限を持っていることを確認します。問題がなければ、Borgmaster は Borglet に Borg ワークロードをスケジューリングし、ワークロード handshake 証明書とそれに対応する秘密鍵を発行します。この証明書はベース ワークロード マスター証明書からチェーンされています。その後、ワークロード handshake 証明書とその秘密鍵は、Borglet に（Borgmaster と Borglet の間の相互認証された ALTS 保護チャネルを介して）安全に送信されます。Borgmaster はベース ワークロード マスター証明書をローテーションし、実行中のすべてのワークロードについて、handshake 証明書を約 2 日ごとに再発行します。さらに同じセル内で同じユーザーとして実行されている各ワークロードは、Borgmaster によってプロビジョニングされた同じ再開鍵と識別子（IDR）を受け取ります。
- ワークロードが ALTS で保護される RPC を作成する必要がある場合は、handshake プロトコルでワークロード handshake 証明書が使用されます。IDR は、セッション再開を開始するための handshake の一部としても使用されます。ALTS でのセッション再開の詳細については、セッションの再開をご覧ください。
ALTS ポリシーの適用
ALTS ポリシーは、どの発行元がどの ID について特定のカテゴリの証明書を発行する権限を持っているかをリストしたドキュメントです。これは Google の本番環境ネットワーク上のすべてのマシンに配布されます。たとえば ALTS ポリシーでは、CA はマシンおよび人に対して証明書を発行できます。また Borgmaster は、ワークロードに対して証明書を発行できます。
証明書の発行時とは対照的に、証明書の検証時のポリシー適用は、さまざまな種類のデプロイに対して異なるポリシーを適用できるため、より柔軟なアプローチであることがわかっています。たとえばテストクラスタのポリシーは、本番環境クラスタのポリシーよりも制限の緩いものにすることが可能です。
ALTS handshake の際、証明書の検証には ALTS ポリシーのチェックが含まれます。このポリシーでは、検証された証明書にリストされている発行元が、その証明書を発行する権限を持つことが保証されます。そうでない場合、証明書は拒否され、handshake 処理は失敗します。図 4 は、ALTS でポリシー適用がどのように機能するかを示しています。図 2 のシナリオに従い、ここでは Mallory（特権をエスカレーションしようと考えている企業ユーザー）が、ネットワーク管理者に対し、マスター証明書を発行しようとしているとします。これはネットワークを再構成できる強力な ID です。この場合、Mallory が ALTS ポリシーでこのオペレーションの実行を許可されないことは言うまでもありません。
図 4: 証明書の発行と利用
- Mallory がネットワーク管理者 ID 用のマスター証明書を発行し、そこに署名サービスによる署名を受けます。これは図 2 の最初の 3 つのステップと同様です。
- Mallory は作成したマスター証明書に関連付けられたマスター秘密鍵を使用して、ネットワーク管理者の handshake 証明書をローカルに作成し署名します。
- 作成した handshake 証明書を使用して Mallory がネットワーク管理者の ID を偽装しようとした場合は、Mallory が通信しようとしている相手側の ALTS ポリシー施行者が、そのオペレーションをブロックします。
証明書の失効
Google では、証明書は期限切れになったか、Google の証明書失効リスト（CRL）に含まれている場合、無効とされます。このセクションでは、Google 内部の証明書失効メカニズムの設計について説明します。このメカニズムは、本ドキュメントの作成時点においてはまだデプロイのテスト中です。
人間の企業ユーザーに対して発行されるすべての証明書には、日次の有効期限タイムスタンプが付いているため、ユーザーは毎日再認証を行う必要があります。本番環境マシンに対して発行される証明書の多くは、有効期限タイムスタンプを使用していません。Google では本番環境用証明書の期限満了について、タイムスタンプに依存することを避けています。これはクロック同期の問題による機能停止につながるおそれがあるからです。代わりに Google では、証明書のローテーションおよびインシデント対応処理の信頼できる情報源として、CRL を使用しています。図 5 は CRL がどのように機能するかを示したものです。
図 5: 失効 ID を使用したマスター証明書の作成
- CA のインスタンスが初期化されると12、CA は CRL サービスに連絡し、失効 ID の範囲を要求します。失効 ID は、8 ビットの証明書カテゴリ（人の証明書やマシンの証明書など）と 56 ビットの証明書 ID という 2 つの要素を含む、長さ 64 ビットの ID です。CRL サービスはこれらの ID の範囲を選択し、それを CA に返します。
- CA はマスター証明書のリクエストを受信すると、証明書を作成し、そこに範囲から選択した失効 ID を埋め込みます。
- それと同時に、CA は新しい証明書を失効 ID にマッピングし、その情報を CRL サービスに送信します。
- CA がマスター証明書を発行します。
handshake 証明書に割り当てられる失効 ID は、証明書の使用方法によって異なります。たとえば人間の企業ユーザーに対して発行される handshake 証明書は、ユーザーのマスター証明書の失効 ID を継承します。Borg ワークロードに対して発行される handshake 証明書の場合、失効 ID は Borgmaster の失効 ID の範囲によって割り当てられます。この ID 範囲は、図 5 と同様のプロセスで CRL サービスによって Borgmaster に割り当てられます。ピアが ALTS handshake に関与している場合は、ピアが CRL ファイルのローカルコピーをチェックして、リモートピア証明書が失効していないことを確認します。
CRL サービスはすべての失効 ID を、ALTS を使用するすべての Google マシンに対して push 可能な単一のファイルにコンパイルします。CRL データベースは数百メガバイトですが、生成される CRL ファイルはさまざまな圧縮技術が利用されるためわずか数メガバイトになります。
ALTS プロトコル
ALTS は、handshake プロトコル（セッション再開あり）とレコード プロトコルという 2 つのプロトコルに依存しています。このセクションでは、各プロトコルの概要を詳しく説明します。ただしこれらの概要は、プロトコルの詳細な仕様と解釈されるべきものではありません。
handshake プロトコル
ALTS handshake プロトコルは、Perfect Forward Secrecy（PFS）とセッション再開の両方をサポートする、Diffie-Hellman ベースの認証鍵交換プロトコルです。ALTS のインフラストラクチャでは、各クライアントおよびサーバーがそれぞれの ID と、信頼される署名サービス検証鍵にチェーンした楕円曲線 Diffie-Hellman（ECDH）鍵を含む証明書を持っています。ALTS では handshake で PFS が使用されない場合でも、これらの静的 ECDH 鍵が頻繁に更新されて前方秘匿性が更新されるため、PFS はデフォルトでは有効になっていません。handshake の際、クライアントとサーバーは共有の転送暗号鍵と、その暗号鍵を使用して保護されるレコード プロトコルを安全にネゴシエートします。たとえばクライアントとサーバーは、AES-GCM を使用した RPC セッションを保護するための 128 ビットキーに同意する場合があります。handshake は、4 つのシリアル化されたプロトコル バッファ メッセージで構成されています。その概要を図 6 に示します。
図 6: ALTS handshake プロトコル メッセージ
- クライアントが ClientInit メッセージを送信して handshake を開始します。このメッセージには、クライアントの handshake 証明書と、クライアントがサポートする handshake 関連の暗号とレコード プロトコルのリストが含まれています。クライアントが終了済みのセッションを再開しようとしている場合は、再開識別子と暗号化されたサーバー再開チケットが含まれます。
サーバーは ClientInit メッセージを受信すると、クライアントの証明書を検証します。それが有効であれば、サーバーはクライアントから提供されたリストから、handshake 暗号とレコード プロトコルを選択します。サーバーは ClientInit メッセージに含まれる情報と自身のローカル情報を組み合わせて、DH 交換の結果を計算します。この結果は、以下のセッション シークレットを生成するプロトコルの写しとともに、鍵導出関数13 への入力として使用されます。
- ペイロード メッセージを暗号化し認証するために使用されるレコード プロトコル秘密鍵 M。
- 将来のセッションで再開チケットに使用される再開シークレット R。
- 認証シークレット A。
サーバーはその証明書、選択した handshake 暗号、レコード プロトコル、および必要に応じて暗号化された再開チケットを含む、ServerInit メッセージを送信します。
サーバーが、handshake オーセンティケータを含む ServerFinished メッセージを送信します14。このオーセンティケータの値は、事前定義によるビット文字列とオーセンティケータのシークレット A によって算出された、ハッシュベースのメッセージ認証コード（HMAC）を使用して計算されます。
クライアントは ServerInit を受信すると、サーバー証明書を検証し、サーバーと同様の DH 交換結果を計算して、同じ M、R、A シークレットを取得します。クライアントは取得した A を使用して、受信した ServerFinished メッセージのオーセンティケータ値を検証します。handshake 処理のこの時点で、クライアントは M を使用したメッセージの暗号化を開始できます。これでクライアントが暗号化されたメッセージを送信できるようになるため、ALTS には RTT handshake プロトコルが 1 つあることになります。
handshake の最後にクライアントは、異なる事前定義のビット文字列を使用して計算された同様のオーセンティケータ値（手順 3 参照）を含む ClientFinished メッセージを送信します。必要に応じて、クライアントは将来のセッション用に、暗号化された再開チケットを含めることができます。このメッセージがサーバーによって受信され検証されると、ALTS handshake プロトコルが終了し、サーバーは M を使用して以降のペイロード メッセージの暗号化と認証を開始できます。
handshake プロトコルは、Google の社内セキュリティ分析チームの Thai Duong がレビューを行い、Bruno Blanchet が Martin Abadi の助力を得て、Proverif15 ツールを使用しながら正式に検証しました。
レコード プロトコル
handshake プロトコルのセクションでは、handshake プロトコルを使用してレコード プロトコルのシークレットがネゴシエートされる方法を説明しました。このプロトコル シークレットは、ネットワーク トラフィックの暗号化と認証に使用されます。これらのオペレーションを実行するスタックのレイヤは、ALTS レコード プロトコル（ALTSRP）と呼ばれます。
ALTSRP には、さまざまな鍵サイズとセキュリティ機能を備えた一連の暗号化スキームが含まれています。handshake の際、クライアントは優先順位別にソートされた優先スキームのリストを送信します。サーバーはクライアントのリストから、サーバーのローカル構成と一致する最初のプロトコルを選択します。このスキーム選択の方法により、クライアントとサーバーの両者が異なる暗号化の優先順位を持つことができるため、Google では暗号化スキームを段階的に導入（または削除）することが可能になっています。
フレーム処理
フレームは ALTS における最小のデータ単位です。各 ALTSRP メッセージはそのサイズに応じて、1 つまたは複数のフレームで構成できます。各フレームには以下のフィールドが含まれます。
- Length: フレームの長さ（バイト単位）を示す、符号なしの 32 ビット値。この長さ 4 バイトのフィールドは、全フレーム長の一部には含まれません。
- Type: フレームの種類（例: データフレームなど）を指定する 32 ビット値。
- Payload: 実際に認証され、必要に応じて暗号化された送信データ。
フレームの最大長は 1 MB + 4 バイトです。現行の RPC プロトコルでは、フレーム長をさらに制限しています。短いフレームのほうがバッファリングに必要なメモリが少ないからです。大きなフレームは、サーバーを枯渇させようとするサービス拒否（DoS）攻撃の際、潜在的な攻撃者によって利用されるおそれもあります。Google ではフレーム長を制限するだけでなく、同じレコード プロトコルのシークレット M を使用して暗号化できるフレームの数も制限しています。この制限は、フレーム ペイロードの暗号化と復号に使用される暗号化スキームによって異なります。この制限に達した場合は、接続を閉じる必要があります。
ペイロード
ALTS では各フレームに、完全性が保護され必要に応じて暗号化されたペイロードが含まれています16。本ドキュメントの発行時点で、ALTS は以下のモードをサポートしています。
- AES-128-GCM、AES-128-VCM: それぞれ AES-GCM モードおよび AES-VCM モード、128 ビットキー使用。これらのモードではそれぞれ GCM および VCM 方式17 を使用して、ペイロードの機密性と完全性が保護されます。
- AES-128-GMAC、AES-128-VMAC: これらのモードはタグ コンピューティングについて、それぞれ GMAC と VMAC を使用した完全性のみの保護をサポートしています。ペイロードは、その完全性を保護する暗号化タグを含む平文で転送されます。
Google では脅威のモデルおよびパフォーマンス要件によって、さまざまな保護モードを使用しています。通信するエンティティが Google によってまたは Google のために管理されている同じ物理的境界内にある場合は、完全性のみの保護が使用されます。これらのエンティティはデータの機密性に基づいて、選択により認証付き暗号にアップグレードすることも可能です。通信しているエンティティが、Google によってまたは Google のために管理されている別の物理的境界内にあり、通信が広域ネットワークを通過する場合は、選択されたモードに関係なく、接続のセキュリティが認証付き暗号に自動的にアップグレードされます。Google では、データが Google によってまたは Google のために管理されている物理的境界の外に転送される場合、同じ厳格なセキュリティ手段を適用することができないため、転送中のデータにさまざまな保護を適用しています。
各フレームはそれぞれ別個に完全性が保護され、必要に応じて暗号化されます。両方のピアでリクエスト カウンタとレスポンス カウンタの両方が維持され、これらは通常のオペレーション中に同期されます。サーバーが順序どおりでないリクエストや繰り返しのリクエストを受信すると、暗号の完全性検証が失敗し、リクエストは破棄されます。同様にクライアントでも、繰り返されるレスポンスや順序の誤ったレスポンスは破棄されます。さらに両方のピアが（フレーム ヘッダーに値を含めるのではなく）カウンタを維持していることで、転送データ量がさらに節約されます。
セッションの再開
ALTS では、ユーザーは負荷の高い非対称暗号化のオペレーションを行うことなく、以前のセッションを再開できます。セッション再開は ALTS の handshake プロトコルに組み込まれている機能です。
ALTS handshake により、クライアントとサーバーは再開チケットを安全に交換（およびキャッシュに保存）できます。再開チケットはその後、接続を再開するために使用できます18。キャッシュされたそれぞれの再開チケットは、同一のデータセンター セル内で同じ ID で実行されているすべてのワークロードに固有の再開識別子（IDR）によりインデックス付けされます。これらのチケットは、対応する識別子に関連付けられた対称鍵を使用して暗号化されます。
ALTS は 2 種類のセッション再開をサポートしています。
サーバー側のセッション再開: クライアントが、サーバー ID と取得した再開シークレット R を含む再開チケットを作成し暗号化します。再開チケットは handshake 終了時に、ClientFinished メッセージでサーバーに送信されます。将来のセッションでは、サーバーが ServerInit メッセージでチケットをクライアントに送り返すことで、セッションを再開できます。チケットを受信したクライアントは、再開シークレット R とサーバーの ID の両方を復元できます。クライアントはこの情報を使用してセッションを再開できます。
IDR は常に ID と関連付けられており、特定の接続に関連付けられるものではありません。ALTS では、複数のクライアントが同じデータセンター内で同じ ID を使用できます。これにより、クライアントは以前に通信していない可能性のあるサーバーとのセッションを再開できます。たとえば、ロードバランサが同じアプリケーションを実行している別のサーバーにクライアントを送信した場合などです。
クライアント側のセッション再開: handshake の終了時、サーバーは暗号化された再開チケットを、ServerFinished メッセージでクライアントに送信します。このチケットには再開シークレット R とクライアントの ID が含まれています。クライアントはこのチケットを使用して、同じ IDR を共有する任意のサーバーとの接続を再開できます。
セッションが再開されると、再開シークレット R を使用して新しいセッション シークレット M'、R'、A' が導出されます。M' はペイロード メッセージの暗号化と認証に、A' は ServerFinished および ClientFinished メッセージの認証に使用され、R' は新しい再開チケット内にカプセル化されます。同じ再開シークレット R が 2 回以上は使用されないことに注意してください。
トレードオフ
KCI（Key Compromise Impersonation）攻撃
ALTS handshake プロトコルは設計上、KCI（Key Compromise Impersonation）攻撃の影響を受けやすくなっています。敵対者がワークロードの DH 秘密鍵または再開鍵を不正に入手した場合は、その鍵を使用してこのワークロードに対し他のワークロードを偽装できます19。これは Google の再開脅威モデルに明示的に含まれています。Google ではある ID の 1 つのインスタンスが発行した再開チケットを、その ID の他のインスタンスでも使用できるようにしたいと考えているからです。
ALTS handshake プロトコルには KCI 攻撃からの保護を実現するバリアントがありますが、これは再開が望まれない環境でのみ使用する価値があるものです。
handshake メッセージのプライバシー
ALTS はどの内部 ID が通信を行っているかを隠すようには設計されていないため、ピアの ID を隠すための handshake メッセージの暗号化は行われません。
Perfect Forward Secrecy（前方秘匿性）
ALTS では、Perfect Forward Secrecy（PFS、前方秘匿性）はサポートされていますが、デフォルトで有効にはなっていません。代わりに大半のアプリケーションについては、頻繁な証明書ローテーションを使用して前方秘匿性が確立されます。TLS 1.2（およびそれ以前のバージョン）では、セッション再開は PFS で保護されていません。ALTS で PFS を有効にすると、PFS は再開されたセッションに対しても有効になります。
ゼロ ラウンドトリップ再開
TLS 1.3 ではゼロ ラウンドトリップ（0-RTT）を必要とするセッション再開が可能になっていますが、これはセキュリティ特性が弱くなっています20。Google の RPC 接続は一般的に長時間になるため、Google では ALTS に 0-RTT のオプションを含めていません。この結果、チャネル設定のレイテンシを低減させることは、0-RTT handshake によって必要となる複雑さの増大やセキュリティ低下との適切なトレードオフにはなりませんでした。
その他の参考資料
- Google で転送中のデータがどのように暗号化されるかについては、Google Cloud での転送データの暗号化のホワイトペーパーをご覧ください。
- セキュリティが Google の技術インフラにどのように組み込まれているかの概要は、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。