Google Cloud Key Vault サービス

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

安全なハードウェアを使用して暗号鍵を保存し、鍵へのアクセスが低エントロピーの知識要素（ロック画面 PIN など）によって保護されるクラウド サービスについて説明します。安全なハードウェアは、正しい知識要素の提供に失敗した試行回数が上限を超えると、保存されている暗号鍵を永続的に復元できなくすることで、ブルート フォース攻撃を防ぐように設計されています。

作成者: Shabsi Walfish
バージョン日: 2018-03-06

注: このドキュメントはまだ作成中であり、実装の詳細は最終調整中です。システムが安定し、ドキュメントが作成できるようになったら、このホワイトペーパーを更新して詳細情報を提供します（特に、関連するオープンソース リリースと合わせて）。

概要

従来、暗号化（データのプライバシーを確保するために使用）では、攻撃者の視点からエントロピーの高いシークレットの使用が必要でした。高いエントロピーが必要な理由は、暗号化スキームが、正しいシークレットが見つかるまで、可能性のあるすべてのシークレットの空間を探索するブルートフォース攻撃に耐えなければならないためです。現在の計算能力を考えると、暗号秘密情報の最小エントロピー要件は 70 ～ 80 ビット程度が妥当です。残念ながら、人間は、その量のエントロピー¹を持つパスワードやその他のシークレットを記憶し、確実に思い出すことは非常に困難です。特に、使用頻度が低い場合はなおさらです（ただし、エントロピーの高いパスワードを頻繁に使用するのは困難で面倒です）。秘密をユーザーが覚えやすい「知識要素」にしたい場合、暗号化技術で非公開データを保護するにはどうすればよいか、という難しい問題が残ります。さまざまな理由から、この問題を解決するのは非常に困難です。そのため、通常、Cloud Storage サービスは、ユーザーが独自のシークレットを覚えておくのではなく、Cloud Storage プロバイダ自体が管理するシークレットを使用してのみデータを暗号化します。

暗号シークレットと人間が覚えられるシークレットの要件のギャップを埋めるアプローチの一つは、Cloud Key Vault（CKV）サービスを使用して、低エントロピーの人間が覚えられるシークレットによって保護された高エントロピーの「復元鍵」を保存することです。CKV サービスは、正しい人間が覚えられる秘密を知っていることを証明した当事者にのみ復元キーをリリースします。人間が覚えられるシークレットに対するブルートフォース攻撃は、CKV サービスによって防ぐことができます。CKV サービスは、シークレットの知識を証明するための失敗した試行回数に絶対的な上限を適用します。復元鍵自体は標準の暗号対称鍵であり、大量のデータを簡単に暗号化できる（認証済み）暗号化スキームで使用できます。このような暗号化されたデータは、復元鍵を取得できないユーザーには無用です。

このホワイトペーパーでは、信頼できるハードウェア モジュール（THM）を使用して Cloud Key Vault サービスを構築するアプローチについて説明します。CKV サービスの最初の実装は、ユーザーのロック画面認証情報（LSKF）（スマートフォンのロックを解除するために使用される秘密の PIN、パスワード、スワイプ パターン）を使用してリカバリ キーを保護するように設計されています。人間は LSKF を正確に記憶できます。同時に、このような LSKF シークレットには通常、試行回数が非常に限られている攻撃者に対抗するのに十分なエントロピーがあるため、CKV サービスに適しています。

Cloud Key Vault サービスの最初のアプリケーションは、クライアントサイド暗号化された Android バックアップを有効にすることです。以前は、Android デバイスでローカルに暗号化されたファイルは、ユーザーの LSKF で保護された鍵を使用していましたが、Cloud に保存（および暗号化）されたこれらのファイルのバックアップは LSKF で保護されていませんでした。Cloud Key Vault で、Cloud に保存されている Android バックアップのロック画面保護が初めて可能になりました。つまり、Google のサーバーは暗号化されたバックアップの内容にアクセスしたり、復元したりすることはできません。バックアップを復号できるのは、ユーザーの LSKF がインストールされているデバイスのみです。

基本コンセプト

当初、Cloud Key Vault サービスでサポートされているクライアント プラットフォームは Android 9 Pie オペレーティング システムのみです。このホワイトペーパーでクライアントについて言及する場合は、Google Play サービスを搭載した Android 9 Pie オペレーティング システムを搭載したデバイスを指しています。サーバーサイドの実装は、追加の Titan チップ² が搭載された特別に指定された Google サーバーで実行されます。Google が設計した Titan チップは、信頼できるハードウェア モジュールのハードウェア コンポーネントとして機能します。Google は、プロトコルとセキュリティ適用メカニズム（以下で説明）を実装するカスタム ブートローダとファームウェアを特別にプロビジョニングします。Google は、プロトコルが Titan ハードウェアで実際に実行されていることを保証するために、ハードウェア構成証明手法を使用しています。

CKV サービスは、ハードウェア障害（チップの焼損など）によるユーザーデータの大量の損失や、データセンターのメンテナンスによる長時間の停止を経験することなく、数十億台の Android デバイスからのトラフィックを処理するようにスケーリングする必要があります。³このため、Titan チップを搭載したサーバーはコホートに編成されます。各コホートは、同じ鍵マテリアルのコピーを含む複数の独立した THM で構成されます。特定のコホートは、システムが可用性と信頼性の目標を達成できるように、異なるメンテナンス ゾーンの物理的に異なるデータセンターに分散されます。スケーラビリティを確保するため、クライアントは複数のコホートにシャーディングされます。これにより、サーバーを追加して使用可能なコホートの数を増やすだけで、サービスの容量を調整できます。

これで、Cloud Key Vault サービス アーキテクチャの主要コンポーネントを列挙する準備が整いました。

アーキテクチャ コンポーネント / 用語集

ロック画面の認証情報（LSKF）: 人間が覚えられる秘密情報（短い PIN、3 x 3 のドット グリッド上のスワイプ パターン、パスワードなど）。このシークレットは、デバイスをローカルでロック解除する機能を保護するために使用され、ユーザーのローカル デバイスの画面ロックのプライマリ（または「強力な」）認証要素と見なされます。

クライアント: Android 9 Pie オペレーティング システムと Google Play 開発者サービス、または同等のサポートされているソフトウェアを搭載したエンドユーザー デバイス。

Android フレームワーク: この汎用的な用語（または単にフレームワーク）は、Android 9 Pie 以降の API を指すために使用します。以前のリリースを指すものではありません。

Google Play 開発者サービス: エンドユーザーのデバイスで実行されるサービスとアプリのコレクション。これにより、Google のアカウント システムとカスタム サーバー API との連携が可能になります。

リカバリ エージェント: Android 9 Pie デバイス（または同様のデバイス）のユーザー空間で Google Play 開発者サービスの一部として実行されるシステム アプリケーション。リカバリ エージェントは、さまざまなプロトコルのクライアントサイドを実行し、必要に応じて Android オペレーティング システムとインターフェースを構築して、LSKF に関連するプロトコル メッセージを作成します。

復元請求: ユーザーが復元キーを取得する場合は、復元請求を作成する必要があります。この復元請求には、ユーザーが知っていると主張する LSKF の暗号化されたコピーが含まれています。通常、古いデバイスの復元キーにアクセスしようとしている新しいデバイスで、古いデバイスの LSKF の入力を求められます。

復元キー: Cloud Key Vault サービスによって保護され、クライアント デバイスでのデータの暗号化（および認証）に使用される暗号秘密鍵。リカバリ キーが Vault に保存されると（後述）、クライアントがデータを暗号化するために使用しなくなった時点で、ローカルコピーを削除できます。

Cloud Key Vault（CKV）サービス: クライアント デバイスが人間が覚えられる LSKF で保護された暗号鍵を保存できるようにするインターネット サービス。

コホート: 互いの冗長レプリカとして機能できる Vault サーバー/THM のコレクション。

コホートの公開鍵: THM の特定のコホートによって生成された鍵ペアの公開鍵。対応する秘密鍵は、鍵の生成時にコホートに含まれていた THM 内でのみ使用できます。

Trusted Hardware Module（THM）: 最小限の信頼できるコンピューティング環境を提供するように設計された専用のセキュリティ モジュール（マイクロコントローラ）。少なくとも、セキュア エレメントは秘密鍵の生成や保存、非揮発性の状態の変化の維持が可能な必要があります（以前の状態へのリセットに関連する攻撃を防ぐため）。

Vault: CKV サービスのデータベース内の特定のエントリ。単一デバイスの LSKF で保護されたリカバリ鍵が含まれています。エンドユーザーには、それぞれが異なるデバイスまたは LSKF に対応する複数の Vault が登録されている場合があります。Vault のコンテンツを調べたり抽出したりできるのは、Vault サーバーの THM のみです。

Vault サーバー: Google データセンターで動作する汎用マシン。信頼できるハードウェア モジュール（THM）を追加するために特別に改造されています。

プロトコルの設計

CKV プロトコルは、次の複数のフェーズで構成されています。

初期化

システムを初期化するために、Google は「信頼のルート」の公開鍵を提供します。この鍵は、Framework が Google のハードウェア構成証明の検証に使用します。この信頼できるルートの署名鍵はオフラインに保存され、慎重に保護されているため、署名するには複数の従業員の参加が必要です。この信頼ルートの公開鍵は Android OS に組み込まれており、OS のアップデートでのみ変更できます。

また、Google は THM のコホートごとに公開鍵のリストと、そのリストのアテステーションを定期的に公開しています。リストの構成証明では、信頼ルートに連結する署名が使用されます。公開リストの各更新にはシーケンス番号も含まれるため、ロールバックを防ぐことができます。リカバリ エージェントは、コホートの公開鍵の最新の公開リストを取得し、Framework に提供します。フレームワークは証明書を検証し、Vault の作成フェーズで使用されるコホート公開鍵をリストからランダムに選択します。

Vault の作成

コホート公開鍵のリストを取得して Framework の初期化を完了させた後、復元エージェントは Framework に新しい Vault の作成をリクエストします。ユーザーが次に LSKF を入力するたびに、Framework は新しい復元鍵を生成し、まず LSKF のハッシュから導出された鍵で暗号化し、次に初期化時に Framework によって選択されたコホート公開鍵で暗号化します。生成された暗号化された blob は、Framework から復元エージェントに渡される Vault であり、復元エージェントはそれを Google の CKV サービスにアップロードします。

保管庫の開閉

新しいデバイスの復元エージェントが特定のVault に保存されている復元キーにアクセスする必要がある場合、まず、そのVault を作成した元のデバイスの LSKF を入力するようユーザーに求めるメッセージが表示されます。復元エージェントは、その LSKF を使用して復元通知を作成するよう Framework に依頼します。Framework は新しい Claimant Key を生成し、その Claimant Key と、申し立てられた LSKF のハッシュを、Vault が最初に暗号化されたものと同じコホート公開鍵で暗号化します。生成された暗号化された blob はリカバリ クレームと呼ばれ、Framework はこれをリカバリ エージェントに渡します。リカバリ エージェントは、この blob を CKV サービスに提示します。

CKV は、復元通知（および対応するVault）を、適切なコホートの一部であるVault サーバーに転送します。Vault サーバーの THM は、復元クレームを復号し、申し立てられた LSKF ハッシュを使用して元のVault から復元鍵を抽出しようとします（内部暗号鍵を導出するため）。元の LSKF ハッシュと申告された LSKF ハッシュが一致する場合、THM は Vault から復元鍵を抽出し、復元請求に含まれている申立人鍵で再暗号化します。そうでない場合、THM は失敗した試行カウンタを増やします。失敗した試行回数のカウンタが上限に達すると、THM はこのVault の以降の復元通知の処理を拒否します。

最後に、すべてが正常に完了すると、再暗号化された復元キー（申立人キーで暗号化されている）が Vault サーバーから Framework まで送り返されます。フレームワークは、申立人鍵のコピーを使用して復元鍵を復号し、プロトコルが完了します。

セキュリティ対策

Cloud Key Vault システムは、スタックの複数のレイヤにセキュリティ保護を組み込むことで、「多層防御」を提供することを目的としています。これらの保護機能の仕組みを理解するために、まずクライアントについて説明してから、スタック上位の Cloud Key Vault Service まで説明します。

クライアント セキュリティ

通常、ロック画面の知識要素（LSKF）は、OEM によって異なるさまざまな方法でデバイスに保存され、保護されます。これは、特定の OEM とデバイスによって異なります。たとえば、Google Pixel 2 デバイスでは、改ざん防止ハードウェア セキュリティ モジュールを使用して LSKF を保存し、LSKF の検証にハードウェアベースのレート制限を適用しています。Cloud Key Vault の使用を可能にするために導入される新しい Framework API は、デバイスがこのようなハードウェア セキュリティ モジュールを使用して LSKF のストレージを保護する場合でも、既存のセキュリティ保証を可能な限り維持するように設計されています。

このセクションでは、LSKF に関連するすべてのセキュリティ メカニズムの全体像を説明するのではなく、新しい Cloud Key Vault 機能に影響する関連するセキュリティ問題と保護に焦点を当てます。

フレームワーク API の保護

CKV サービスをサポートするために追加された新しい Framework API は @SystemApi としてマークされており、特別な権限を必要とします。これにより、Google Play 開発者サービスなどの OEM 承認済みのシステムアプリでのみ使用できるようになります。これにより、ユーザーがデバイスにインストールするアプリに公開される可能性のある直接的な攻撃対象が大幅に削減されます。

また、Framework API により、信頼ルートによって構成されたコホート公開鍵に対してのみ Vault が作成されます。信頼のルーツは、出荷時に OEM によってフレームワークに焼き込まれるため、OS のアップデートなしで変更することはできません。これにより、LSKF がハードウェアベースのブルートフォース保護を適切に適用する Vault の作成にのみ使用されていることが保証されます。Cloud Key Vault サービスで LSKF のブルートフォース攻撃を防ぐ THM を使用すると、デバイスで同じ目的に安全なハードウェアを使用する場合と同等のセキュリティを実現できます（Google Pixel 2 デバイスなど）。

LSKF がセキュアなハードウェア以外のデバイス上の任意の場所に保存されるとは想定されていないため、新しい Vault を作成できるのは、デバイスのロックを解除した直後のみです。ユーザーが LSKF を入力してデバイスのロックを解除すると、LSKF は RAM 内のフレームワークで一時的に使用可能になります。この時点で、Vault を作成する新しい API が Vault を使用します。デバイスがロックされている間は、LSKF を使用できないため、新しい LSKF で保護された Vault を作成できません。

復元エージェントの保護

リカバリ エージェントで提供される主なセキュリティ保護は、リカバリ エージェントが現在のデバイスの LSKF やリカバリ鍵を決して見ることができないようにプロトコルが設計されていることです。クライアント側ではフレームワークのみがこれらの情報を参照するため、リカバリ エージェントで潜在的なバグやセキュリティ上の脆弱性を悪用することは非常に困難です。リカバリ エージェントは、主にライフサイクル イベントと、Cloud と Framework 間でのデータのやり取りを管理するために使用されます。唯一の例外は、復元中に Vault Opening プロトコルの直前に、ユーザーが古いデバイスの LSKF を入力する必要がある場合です。古いデバイスの申し立て済み LSKF を収集する UI は、Recovery Agent ⁴ に実装されています。ただし、Recovery Agent の実装では、Framework が Recovery Claim の作成を引き継ぐとすぐに、申し立てられた LSKF が「忘れられます」。

プロトコルのセキュリティ機能

このプロトコルの詳細な分析は、このドキュメントの範囲外ですが、プロトコルに組み込まれている保護機能のいくつかについて説明します。特に、プロトコルでは LSKF のハッシュのみが使用されます。つまり、LSKF のエントロピーが高い場合（たとえば、優れた高エントロピー パスワードの場合）、Vault を保存する方がパスワード ハッシュを保存するよりもはるかに優れています。この場合、パスワード ハッシュは THM のセキュリティとは独立したセキュリティ対策を提供できます。このため、Google はプロトコルの一部として、LSKF の塩付き「メモリハード」ハッシュをサポートしています。また、Vault を作成したデバイスの ID に暗号的にバインドし、Vault オープン プロトコル中のチャレンジとして使用されるノンスにリカバリ クレームをバインドして、リカバリ クレームが新規であることを確認します。

復元キーは Vault の作成ごとに新しく生成されるため、既存の Vault エントリを新しく作成された Vault で上書きすることで鍵のローテーションを実装します。Vault で使用される失敗した試行カウンタのアドレスは、Vault の作成時に選択されます。Framework では、LSKF が変更された場合、またはコホート公開鍵の新しい構成証明リストがある場合を除き、後続の Vault で使用されるカウンタ アドレスが変更されないようにします。したがって、LSKF のブルートフォース攻撃からの保護を損なうことなく、リカバリキーのローテーションを行うことができます。

Cloud Key Vault Service のサーバー セキュリティ

このサーバーは、通常のサーバー ハードウェアで実行されるソフトウェアと、特殊なハードウェア（Titan チップ）で実行されるファームウェアを組み合わせて実装されています。各レイヤで提供される保護について説明します。

ハードウェア保護

CKV サービスのサーバー側に実装されている主なセキュリティ保護は、Google 独自のカスタム設計の Titan チップを使用して構築された信頼できるハードウェア モジュール（THM）です。チップは、CKV プロトコルの実装に必要な API を公開するファームウェアを実行しています。特に、ファームウェア ロジックによって秘密鍵がコホートの Titan チップの外部に漏洩しないように、コホートの他のメンバーと鍵ペアを生成して安全に共有できます。また、Vault のオープン オペレーションを実行し、失敗した試行の Vault ごとのカウンタを厳密に増分することもできます（このカウンタは、Titan チップ内に保存されている状態に基づいています）。CKV Titan チップ ファームウェアによって実行されるプロトコルの詳細については、このドキュメントの今後のリリースで説明します。

サーバー セキュリティは Titan チップのファームウェア ロジックから派生するため、チップがシークレットを漏洩させたり、カウンタの上限を無視したりできないように、ロジックが変更されないようにする必要があります。この目標を達成するため、Titan ブートローダも変更し、更新が適用される前にチップに保存されているデータ（コホートの秘密鍵など）が完全に消去されるようにしています。この保護機能の欠点は、データの損失を伴うことなくファームウェアのバグを修正できないことです。ファームウェアの更新は、機能的には既存のハードウェアを破壊して新しいチップに置き換えることと同等です。重要なファームウェア パッチが必要な場合は、Google は証明済みのコホート公開鍵のまったく新しいリストを作成して公開し、すべてのユーザーを新しいリストに段階的に移行する必要があります。このリスクを軽減するため、ファームウェア コードベースをかなり最小限に抑え、潜在的なセキュリティ問題がないか慎重に監査しています。

ソフトウェア保護

CKV サービスは、THM によって適用される Vault ごとの障害に関する厳格な上限に加えて、ソフトウェアベースのレート制限も実装します。レート制限は、不正使用者がユーザーのアカウントに侵入して、失敗した復元試行の上限を迅速に使い果たし、実際のユーザーが復元キーにアクセスできなくすることを防ぐように設計されています。画面のロック解除に失敗した回数が多すぎるとユーザーのデバイスで適用される時間遅延と同様に、CKV サービスでは、Vault の開封リクエストが失敗するたびに時間遅延が長くなります。

また、厳格なアクセス制御、モニタリング、監査など、ユーザーデータをホストする Cloud サービスに対して標準的なセキュリティ対策も実施しています。

詳細なプロトコル仕様

プロトコルの詳細な仕様はまだ作成中です。今年後半に Android Open Source Project でクライアント コードが公開されるとともに、このドキュメントも更新され、詳細が追加される予定です。

備考