Google が本番環境マシンに起動時整合性を適用する方法

このコンテンツの最終更新日は 2023 年 10 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。

このドキュメントでは、Google が本番環境マシンで起動プロセスの整合性を確保するために使用するインフラストラクチャ制御について説明します。メジャード ブート プロセスの上に構築されたこれらの制御機構は、Google がデータセンターのマシンをブートスタック全体の脆弱性から確実に復旧し、マシンを任意の起動状態から既知の良好な構成に戻す際に役立ちます。

はじめに

データセンター マシンのセキュリティ ポスチャーは、起動時に確立されます。マシンの起動プロセスでは、Google の本番環境でマシンを安全に実行しながら、マシンのハードウェアを構成し、オペレーティング システムを初期化します。

Google では、起動プロセスの各ステップで期待される起動状態を適用し、顧客データを安全に保つために、業界トップクラスの制御機構を実装しています。これにより、マシンで目的のソフトウェアが起動され、マシンの初期のセキュリティ ポスチャーを損なうおそれのある脆弱性を排除しています。

このドキュメントでは、起動プロセスについて説明し、起動フローの各ステップで Google の制御機構がどのように動作するかを示します。

背景

このセクションでは、マシンの認証情報、ハードウェアのルート オブ トラスト、シールされた認証情報および暗号シールの各用語について定義します。

マシンの認証情報

Google のマシン管理システムの中心的なコンポーネントの一つは認証情報インフラストラクチャです。これは、内部の認証局（CA）と、認証情報のローテーション フローを調整する他のコントロール プレーン要素で構成されています。

Google の本番環境フリートのマシンは、安全なチャネルを確立する際に相互認証を実行します。この相互認証のため、各マシンは Google の CA 公開鍵を所有しています。各マシンには独自の公開鍵/秘密鍵のペアと、その鍵ペアの証明書があります。

各マシンの公開鍵/秘密鍵のペアは、CA によって署名された証明書とともに「マシンの認証情報」と呼ばれ、マシンがフリート内の他のマシンに対して自身を認証するために使用されます。本番環境のネットワーク内では、各マシンはトラフィックを交換する前に、他のマシンの公開鍵が Google の CA によって認定されていることを確認します。

ハードウェアのルート オブ トラストと暗号シーリング

コンピューティング デバイスの高度化に伴い、デバイスの攻撃対象領域も拡大しています。このため、デバイスにハードウェア ルート オブ トラスト（RoT）が導入されています。これは、マシン上の機密データを保護する、小規模な高信頼実行環境です。RoT は、ノートパソコンやスマートフォンなどのモバイル デバイスだけでなく、デスクトップ PC などの従来型デバイスでも使用されます。

Google のデータセンターのマシンは、その最深層部に Google が設計したカスタム ハードウェアのルート オブ トラスト（Titan）が組み込まれています。Google では、Titan と暗号シーリングというメカニズムにより、各マシンが期待する構成とソフトウェア バージョンを実行していることを確認しています。

暗号シーリングは、Trusted Computing Group が発表した仕様である Trusted Platform Module（TPM）によるシーリングと似ていますが、この暗号シーリングにはさらにいくつかの利点があります。Titan により、低レベルのファームウェアの測定と証明の精度が向上しています。

暗号シーリングには以下の 2 つのコントロールがあります。

  • 機密データの暗号化
  • データの復号条件となるポリシー

シールされた認証情報

Google の認証情報インフラストラクチャでは、暗号シーリングと、マシンのハードウェアのルート オブ トラストによって制御される鍵を使用して、マシンの認証情報を保存時に暗号化します。暗号化された認証情報の秘密鍵と対応する証明書を「シールされた認証情報」といいますGoogle では、マシンの認証情報に加えて、このシーリング メカニズムを使用して他の機密データを保護しています。

各マシンは、マシンで起動する必要のあるソフトウェアを指定する復号ポリシーに準拠している場合にのみ、マシンの認証情報を復号してアクセスできます。たとえば、オペレーティング システム カーネルの目的のリリースを指定するポリシーにマシンの認証情報をシールすると、必要なカーネル バージョンを起動していない限り、マシンはマシンクラスタに参加できなくなります。

復号ポリシーは、メジャード ブートというプロセスで適用されます。ブートスタック内のすべてのレイヤが次のレイヤを測定し、マシンは起動の終了時にこの測定チェーンを証明します。多くの場合、この測定結果は暗号ハッシュになります。

認証情報のシーリング プロセス

このセクションでは、Google のマシンで使用される認証情報のシーリングとメジャード ブート プロセスについて説明します。次の図は、この流れを表しています。

認証情報のシーリング フロー。

マシンの認証情報を特定の起動ポリシーでシールするには、次の操作を行います。

  1. Google のマシン自動化インフラストラクチャがマシンのソフトウェア アップデートを開始します。目的のソフトウェア バージョンが認証情報インフラストラクチャに渡されます。
  2. Google の認証情報インフラストラクチャは Titan にシーリング鍵をリクエストします。マシンで目的のソフトウェアが起動している場合にのみ、Titan が鍵を使用するというポリシーが適用されています。
  3. 認証情報インフラストラクチャは、返された鍵のポリシーと、マシン自動化インフラストラクチャによって通知されたインテントを比較します。ポリシーがとインテントが一致していることを確認すると、認証情報インフラストラクチャは、認定されたマシンの認証情報をマシンに発行します。
  4. 認証情報インフラストラクチャは、手順 2 で調達されたシーリング鍵を使用してこの認証情報を暗号化します。
  5. 暗号化された認証情報は、以降の起動時に Titan によって復号できるようにディスクに保存されます。

メジャード ブート プロセス

次の図に示すように、Google マシンのブートスタックは 4 つのレイヤから構成されています。

メジャード ブート プロセスの 4 つのレイヤ。

レイヤには次のものがあります。

  • ユーザー空間: デーモンやワークロードなどのアプリケーション。
  • システム ソフトウェア: ハイパーバイザまたはカーネル。ネットワーク、ファイル システム、仮想メモリなどのハードウェア機能をユーザー空間に抽象化する、最も低位のソフトウェア。
  • ブート ファームウェア: BIOS やブートローダーなど、カーネルを初期化するファームウェア。
  • ハードウェアのルート オブ トラスト: Google マシンで、ファームウェアやその他の低レベルの CPU サービスを暗号的に測定する Titan チップ。

起動中、各レイヤは次のレイヤを測定してから、そのレイヤに制御を渡します。マシンのシールされた認証情報は、Google の認証情報インフラストラクチャが指定するように、起動中に収集されたすべての測定値がシールされた認証情報の復号ポリシーに適合する場合にのみ、オペレーティング システムから利用可能になります。そのため、マシンがシールされた認証情報でオペレーションを実行できることは、マシンがメジャード ブート ポリシーを満たしていることを意味します。このプロセスは暗黙的な構成証明の一種です。

マシンが目的の状態から逸脱したソフトウェアを起動した場合、マシンはフリート内での動作に必要な認証情報を使用して復号できず、オペレーションは失敗します。このようなマシンは、マシン管理インフラストラクチャが自動修復アクションをトリガーするまで、ワークロードのスケジューリングに参加できません。

カーネルの脆弱性からの復旧

マシンがカーネル バージョン A を実行しているときに、セキュリティ研究者がこのカーネル バージョンに脆弱性を発見したとします。このような場合、Google は脆弱性にパッチを適用し、更新されたカーネル バージョン B をフリートにロールアウトします。

この脆弱性にパッチを適用するだけでなく、フリート内の各マシンに新しいマシン認証情報を発行します。認証情報のシーリング プロセスで説明したように、新しいマシン認証情報は復号ポリシーにバインドされます。このポリシーは、カーネル バージョン B がマシンで起動した場合にのみ適用されます。ブート ファームウェアの測定値がマシンの起動ポリシーを満たしていないため、目的のカーネルを実行していないマシンは新しいマシン認証情報を復号できません。このプロセスの一環として、古いマシンの認証情報も失効します。

これらのマシンは、コントロール プレーンのインテントに合わせてカーネルが更新されるまで、マシンクラスタに参加できません。こうした制御により、脆弱性のあるカーネル バージョン A を実行しているマシンは、カーネル バージョン B にアップグレードされるまで、ジョブやユーザーデータを受信できなくなります。

ブート ファームウェアの脆弱性からの復旧

オペレーティング システムのカーネルではなく、ブート ファームウェアに脆弱性があった場合はどうなるのでしょうか。カーネルの脆弱性から復旧するで説明した同じ対策が、このような脆弱性からの復旧にも役立ちます。

Google の Titan チップは、マシンの起動前にマシンのブート ファームウェアを測定します。これにより、Titan は、ブート ファームウェアがマシン認証情報の起動ポリシーを満たしているかどうかを判断します。目的のブート ファームウェアを実行していないマシンは、新しいマシンの認証情報を取得できません。また、ブート ファームウェアがコントロール プレーンのインテントに従うまで、そのマシンはマシンクラスタに参加できません。

ルート オブ トラスト ファームウェアの脆弱性からの復旧

RoT は脆弱性の影響を受けませんが、Google の起動制御により、RoT 独自の変更可能コード内のバグからでも復旧することができます。

Titan のブートスタックは、独自のセキュアブート フローとメジャード ブートフローを実装しています。Titan チップの電源がオンになると、ハードウェアが Titan のブートローダーを暗号的に測定し、ブートローダーが Titan のファームウェアを測定します。Titan ファームウェアは、マシンのカーネルやブート ファームウェアと同様に、バージョン番号で暗号的に署名されています。Titan のブートローダーは署名を検証して、Titan ファームウェアのバージョン番号を抽出し、そのバージョン番号を Titan のハードウェア ベースの鍵導出サブシステムにフィードします。

Titan のハードウェア サブシステムは、バージョニングされた鍵導出スキームを実装します。これにより、バージョン X の Titan ファームウェアは、X 以下のすべてのバージョンにバインドされたチップ固有の鍵を取得できます。Titan ハードウェアにより、バージョン X のファームウェアは、X 以下（ただし X を超えない）バージョンにバインドされた鍵にアクセスできます。マシンの認証情報を含め、Titan にシールされているすべてのシークレットは、バージョニングされた鍵を使用して暗号化されます。

証明書とシーリング鍵は Titan チップごとに異なります。一意の鍵を使用することで、Google データセンター内での実行が予想される Titan チップのみを信頼することができます。

次の図は、Titan とバージョン鍵を示しています。バージョン X のファームウェアはバージョン X+1 の鍵にアクセスできませんが、それより前の鍵にはアクセスできます。

Titan のバージョン。

Titan ファームウェアに重大な脆弱性が存在する場合、Google は、バージョン番号が大きいパッチをリリースし、その後は、より大きい Titan ファームウェア バージョンにバインドされた新しいマシン認証情報を発行します。これらの新しい認証情報は、古い脆弱な Titan ファームウェアで復号できません。マシンが本番環境で新しい認証情報を使用して処理を実行している場合、マシンの Titan チップが最新のファームウェアで実行されていることになります。

ルート オブ トラストの信頼性の確保

このドキュメントで説明する制御機構はすべてハードウェア RoT 自体の機能に基づいています。Google の認証情報インフラストラクチャは、これらの RoT によって出力された署名を使用して、マシンが目的のソフトウェアを実行しているかどうかを判断します。

したがって、ハードウェアの RoT が真正なものかどうか、また RoT が最新のファームウェアを実行しているかどうかを認証情報インフラストラクチャが判定できるようにすることが非常に重要です。

各 Titan チップは、製造時に一意のエントロピーでプログラムされます。Titan の低レベルの起動ルーチンがエントロピーをデバイス固有の鍵に変換します。Titan 製造ラインのセキュア エレメントにより、Google ではこのチップ固有の鍵を使用して正規の Titan チップかどうかを認識することができます。

次の図は、この承認プロセスを示しています。

Titan の承認プロセス。

本番環境では、Titan はデバイス ID 構成エンジン（DICE）と同様のフローを使用して、デバイス固有の鍵で発行された署名を承認します。これには、Titan ファームウェアのバージョン情報も含まれています。この証明により、Titan チップが発行した署名のなりすましや、古い Titan ファームウェアへのロールバック、新しい Titan ファームウェアへのなりすましを防ぐことができます。これらの制御機構により、Titan から受信した署名が本物の Titan ファームウェアを実行している、本物の Titan ハードウェアによって生成されたことを検証できます。

起動時の整合性に基づいたビルド

このドキュメントでは、マシンのアプリケーション プロセッサが目的のコードを確実に起動する仕組みについて説明しました。これらのメカニズムは、ハードウェアのルート オブ トラスト チップと結合されたメジャード ブートフローに依存しています。

Google の脅威モデルでは、マシンの復号された認証情報を不正に入手するために、CPU と RoT の間のバスに物理的に侵入してくる攻撃者も想定しています。このリスクを最小化するため、Google は、Trusted Computing Group の TPM と DPE の API、および Caliptra の統合されたルート オブ トラストを一つにして、アクティブな相互接続を減らす標準ベースのアプローチの開発を進めています。

次のステップ

作成者: Jeff Andersen、Kevin Plybon