Google Cloud Key Vault サービス

安全なハードウェアを使用して暗号化鍵を格納するクラウド サービスについて説明します。このクラウド サービスでは、暗号化鍵へのアクセスが低エントロピーの知識ファクタ（ロック画面 PIN など）によって保護されます。安全なハードウェアはブルート フォース攻撃を防ぐように設計されており、正しい知識ファクタを入力しようとする試行の失敗回数が多すぎると、格納された暗号化鍵が永続的に取得できなくなります。

公開者: Shabsi Walfish
バージョンの日付: 2018-03-06

注: このドキュメントは未完成であり、実装の詳細を準備しているところです。システムが安定し、さらに多くのドキュメントが作成されると、このホワイトペーパーをより詳細な情報で更新します（特に関連するオープンソース リリースが追加される予定です）。

概要

以前より、暗号化（データのプライバシーを確保するために使用する）には、攻撃者の視点から見てエントロピーが高い秘密の使用が必要でした。暗号化スキームでは、目的の秘密が見つかるまで可能性のあるすべての秘密を探し回るブルート フォース攻撃に耐える必要があるため、高エントロピーが要求されます。現在の利用可能な計算能力を考慮すると、暗号を使用した秘密の最小限の妥当なエントロピー要件は 約 70～80 ビットになるでしょう。残念ながら、人間にとっては、こうした量のエントロピーを持つパスワードやその他の秘密を記憶して確実に思い出すことは困難です^1。ほとんど使用しないパスワードや秘密の場合は特に難しくなります（ただし、高エントロピーのパスワードを頻繁に使用することは非効率で手間がかかります）。そのため、秘密をユーザーが覚えやすい「知識ファクタ」にする場合、暗号化テクノロジーによってプライベート データをどのように保護すればよいのか、という困難な課題に直面します。さまざまな理由でこの課題の解決は難しいため、通常、クラウド ストレージ サービスでは、ユーザーが独自の秘密を記憶するのではなく、クラウド ストレージ プロバイダ自身によって管理される秘密を使ったデータの暗号化のみを行います。

暗号を使用した秘密と人間が記憶する秘密の要件間のギャップを埋める 1 つのアプローチは、Cloud Key Vault（CKV）サービスを使用して、人間が記憶する低エントロピーの秘密で保護された高エントロピーの「回復鍵」を格納することです。CKV サービスでは、人間が記憶する正しい秘密を知っていることを証明した当事者のみに回復鍵がリリースされます。秘密を知っていることを証明しようとする試行に失敗した回数に絶対的な制限を適用する CKV サービスを使用すると、人間が記憶する秘密に対するブルート フォース攻撃を阻止することができます。回復鍵自体は標準の暗号化対称鍵であり、どこにでも安全に格納できる大量のデータ（ディスクのバックアップなど）を簡単に暗号化できる（認証された）暗号化スキームでの使用に適しています。回復鍵を取得できない人物にとって、このような暗号化されたデータは無意味になります。

このホワイトペーパーでは、Trusted Hardware Module（THM）を使用して Cloud Key Vault サービスを構築する Google のアプローチについて説明します。CKV サービスの最初の実装は、スマートフォンをロック解除するための秘密の PIN、パスワード、スワイプ パターンなど、ユーザーのロック画面知識ファクタ（Lock Screen Knowledge Factor: LSKF）で回復鍵を保護するように設計されています。人間は LSKF を確実に記憶することができます。また、通常、こうした秘密の LSKF は、ごく限られた回数しか試行できない攻撃者を防ぐ最小限のエントロピーを備えているため、CKV サービスに最適です。

Cloud Key Vault サービスが最初に適用されるのは、クライアント側による Android バックアップの暗号化です。以前は、Android 端末上でローカルで暗号化されたファイルに対しては、ユーザーの LSKF で保護された鍵を使用していましたが、クラウドで格納（および暗号化）されたこれらのファイルのバックアップはロック画面によって保護されていませんでした。Cloud Key Vault では、クラウドに格納された Android バックアップもロック画面で保護することが初めて可能になりました。つまり、Google のサーバーは、暗号化されたバックアップのコンテンツにアクセスしたり復元したりすることができません。ユーザーの LSKF が入力された端末のみでバックアップが復号化できます。

主要なコンセプト

当初は、Cloud Key Vault サービスでサポートされるクライアント プラットフォームは近々登場する Android P オペレーティング システムだけです。また、このページでクライアントと言うときは、Google モバイル サービスが導入された Android P オペレーティング システムを実行している端末を指します。サーバー側の実装は、追加の Titan チップ² を備えた特別に指定された Google サーバーで実行されます。Google が設計した Titan チップは、Trusted Hardware Module のハードウェア コンポーネントとして機能し、カスタム ブートローダーに加えて、プロトコルとセキュリティを適用するメカニズムを実装するファームウェアとともにプロビジョニングされます（後述します）。Titan ハードウェアでプロトコルが実際に実行されることを保証するために、ハードウェア構成証明技術を活用しています。

CKV サービスは、ハードウェアの障害（焼けたチップなど）により大量のデータを失ったり、データセンターのメンテナンス作業に起因する長時間にわたる機能停止に遭遇したりすることなく、何十億³ もの Android 端末からのトラフィックを処理できるようにスケーリングする必要があります。そのため、Titan チップを備えたサーバーは複数のコホートに分類されます。各コホートは、同じ鍵マテリアルのコピーが含まれた独立したいくつかの THM で構成されます。システムの可用性と信頼性の要件を確実に満たすために、任意のコホートは、さまざまなメンテナンス ゾーンにある物理的に異なったデータセンターに分散されます。拡張性のために、クライアントは多数の異なるコホートで共有され、サーバーを追加して利用可能なコホートの数を増やすだけで、サービスのキャパシティを調整できるようにしています。

Cloud Key Vault サービス アーキテクチャの主要コンポーネントを次に示します。

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

ロック画面知識ファクタ（LSKF）: 短い PIN、3 x 3 ドットグリッドでのスワイプ パターン、パスワードなど、人間が記憶する秘密。この秘密は端末をローカルでロック解除する機能を保護し、ユーザーのローカル端末の画面ロックに使用するプライマリ（または「強力な」）認証要素であるとみなされます。

クライアント: Android P オペレーティング システムと Google モバイル サービスを実行しているエンドユーザー端末、または同等にサポートされるソフトウェア。

Android フレームワーク: この一般名称は、Android オペレーティング システムの次のリリース（Oreo リリースの後継であり、現時点では、名前がまだ付けられていない）以降の API を指すときに使用し、以前のリリースを指すことはありません。

Google モバイル サービス: エンドユーザー端末で実行されるサービスとアプリのコレクションであり、Google のアカウント システムとカスタム サーバー API を操作できるようにします。

回復エージェント: Android P 端末（または同様の端末）上のユーザー スペースで Google Play サービスの一部として実行されるシステム アプリケーション。回復エージェントはクライアント側のさまざまなプロトコルを実行し、必要に応じて、LSKF に関連するプロトコル メッセージを作成するために、Android オペレーティング システムと連動します。

回復要求: ユーザーが回復鍵を取得する際は、覚えている LSKF の暗号化されたコピーが含まれた回復要求を作成する必要があります。通常、ユーザーは、古い端末の回復鍵へのアクセスを試みる新しい端末に古い端末の LSKF を入力するように求められます。

回復鍵: Cloud Key Vault サービスによって保護されている暗号化秘密鍵であり、クライアント端末でデータを暗号化（および認証）するときに使用します。回復鍵が Vault（以下を参照）に格納されたら、クライアントで回復鍵を使用してデータを暗号化した直後にローカル コピーを削除することができます。

Cloud Key Vault（CKV）サービス: このインターネット サービスをクライアント端末で使用すると、人間が記憶する LSKF によって保護されている暗号化鍵を格納できます。

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

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

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

Vault: CKV サービスのデータベース内の特定のエントリであり、単一の端末の LSKF で保護された回復鍵が格納されます。エンドユーザーは複数の Vault を保持でき、各 Vault は異なる端末または LSKF に対応しています。Vault サーバーの THM だけが Vault のコンテンツを検査または抽出できます。

Vault サーバー: Google のデータセンターで稼動している汎用マシンであり、追加の Trusted Hardware Module（THM）が組み込まれています。

プロトコル設計

CKV プロトコルは、次のようないくつかのフェーズで構成されます。

初期化

Google は、システムを初期化するにあたって、Android フレームワークが Google のハードウェア構成証明を検証するために使用する「信頼のルート」の公開鍵を提供します。この信頼のルートの署名鍵はオフラインで格納されて、厳重に保護されるため、この署名鍵で署名するには複数の従業員が対応する必要があります。この信頼のルートの公開鍵は Android OS に埋め込まれ、OS のアップデートを通じてのみ変更されます。

Google は、THM の各コホートの公開鍵のリストに加えて、リストの構成証明を定期的に発行します。リストの構成証明では、信頼のルートにチェーンバックする署名を使用します。また、公開されたリストの各アップデートには、シーケンス番号が含まれているため、ロールバックを防止することができます。回復エージェントはコホート公開鍵の最近発行されたリストを取得して、Android フレームワークに供給します。次に、Android フレームワークは構成証明を検証し、Vault 作成フェーズで使用されるコホート公開鍵をリストからランダムに選択します。

Vault を作成する

回復エージェントはコホート公開鍵のリストを取得して、フレームワークによる初期化の完了を支援した後、Android フレームワークに新しい Vault の作成をリクエストします。次に、ユーザーが LSKF を入力するたびに、フレームワークは新しい回復鍵を生成して、最初に LSKF のハッシュから派生した鍵を使って回復鍵を暗号化し、その後、初期化中にフレームワークによって選択されたコホート公開鍵を使って回復鍵を暗号化します。結果として得られる暗号化された blob が Vault であり、フレームワークによって回復エージェントに渡され、その後、回復エージェントによって Google の CKV サービスにアップロードされます。

Vault を開く

特定の Vault に格納された回復鍵に新しい端末上の回復エージェントがアクセスする必要がある場合、回復エージェントは最初に、ユーザーに対して、Vault を作成した元の端末の LSKF を入力するように求めます。次に、回復エージェントは、フレームワークに対して、入力された LSKF を使って回復要求を作成するように要求します。フレームワークは新しい要求者鍵を生成し、最初に Vault の暗号化に使用した同じコホート公開鍵を使って、その要求者鍵に加えて、要求された LSKF のハッシュを暗号化します。結果として得られる暗号化された blob は回復要求と呼ばれ、この回復要求は、フレームワークによって回復エージェントに渡され、次に、回復エージェントによって CKV サービスに送信されます。

CKV は、回復要求（および対応する Vault）を正しいコホートの一部である Vault サーバーに渡します。次に、Vault サーバーの THM は回復要求を復号化し、要求された LSKF ハッシュを使用して元の Vault から回復鍵を抽出しようと試みます（内部暗号化鍵を取得するために）。元の LSKF ハッシュと要求された LSKF ハッシュが一致した場合、THM は Vault から回復鍵を抽出し、回復要求に含まれていた要求者鍵を使って回復鍵を再暗号化します。一致しない場合、THM は失敗した試行のカウンタを上げます。失敗した試行のカウンタが制限に達すると、THM は、この Vault の以降の回復要求を処理することを拒否します。

最後に、すべての処理が正常に完了すると、再暗号化された回復鍵（この時点で、要求者鍵で暗号化されている）は Vault サーバーからフレームワークに戻されます。フレームワークでは、要求者鍵のコピーを使用して回復鍵が復号化され、プロトコルが完了します。

セキュリティ対策

Cloud Key Vault システムの目的は、スタックの複数のレベルにセキュリティ保護を含めることにより「多重防御」を提供することです。これらの保護の仕組みについての概念を理解していただくために、クライアントから Cloud Key Vault サービスに至るまでを説明します。

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

特定の OEM や端末に応じて、ロック画面知識ファクタ（LSKF）は通常、OEM によって異なるさまざまな方法を使用して端末で格納および保護されます。たとえば、Google の Pixel 2 端末では、耐タンパー性があるハードウェア セキュリティ モジュールを使用して LSKF を安全に格納し、LSKF 検証に対して、ハードウェアベースのレート制限を適用しています。Cloud Key Vault の使用を可能にするために導入されている新しい フレームワーク API は、端末でそのようなハードウェア セキュリティ モジュールを使用して LSKF のストレージが保護されている場合でも、既存のセキュリティ保証を可能な限り最大限に保持するように設計されています。

このセクションでは、LSKF に関連するすべてのセキュリティ メカニズムの詳細を説明するのではなく、特に、新しい Cloud Key Vault 機能に影響を及ぼす、関連性のあるセキュリティの問題と保護に焦点を合わせています。

フレームワーク API を保護する

CKV サービスをサポートするために追加された新しいフレームワーク API は @SystemApi とマークされ、Google Play サービスなど、OEM 承認のシステムアプリのみで利用できるようにする特別なパーミッションを必要とします。これにより、ユーザーによって端末にインストールされたアプリがさらされる可能性がある直接的な攻撃対象領域をほとんど取り除くことができます。

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

端末の安全なハードウェア以外に LSKF が格納されることはないため、端末をロック解除した直後のみに新しい Vault を作成できます。ユーザーが LSKF を入力して端末をロック解除すると、RAM でフレームワークが LSKF を短時間利用できるようになります。このとき、Vault を作成する新しい API で LSKF の利用が可能になります。端末がロックされているときは LSKF が利用できないため、LSKF で保護された新しい Vault を作成することはできません。

回復エージェントを保護する

回復エージェントに対して提供される主要なセキュリティ保護として、プロトコルの設計により回復エージェントが現在の端末の LSKF または回復鍵を識別できないようになっています。クライアント側ではフレームワークのみがこれらを識別できるため、回復エージェントの潜在的なバグやセキュリティ上の脆弱性を悪用することが難しくなっています。回復エージェントは、ライフサイクル イベントを管理したり、クラウドとフレームワークの間でデータを送受信したりするときに主に使用されます。こうした使用方法の唯一の例外は、ユーザーが古い端末の LSKF を入力する必要があるときに、Vault を開くプロトコルの直前に実行される回復処理中に発生します。つまり、古い端末の要求された LSKF を収集する UI が回復エージェントに実装されます⁴。ただし、回復エージェントの実装では、フレームワークが回復要求の作成を引き継ぐとすぐに、要求された LSKF が「破棄」されます。

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

このドキュメントではプロトコルを詳細に分析しませんが、プロトコルに組み込まれているいくつかの保護に重点を置いて説明します。特に、プロトコルは初めから終わりまで LSKF のハッシュのみを使用します。つまり、LSKF が高エントロピーを備えている場合（たとえば、LSKF が適切な高エントロピーのパスワードである場合）、厳密には、Vault の格納はパスワード ハッシュの格納よりも適切ですが、この場合は、THM のセキュリティとは別に、パスワード ハッシュによりセキュリティ対策を提供することができます。そのため、プロトコルの一部として LSKF のソルト付き「メモリハード」ハッシュ化をサポートしています。また、（Vault を作成した）端末の ID に Vault を暗号でバインドし、（Vault を開くプロトコルの実行中にチャレンジとして使用される）ノンスに回復要求をバインドして、回復要求が新しく作成されるようにしています。

Vault を作成するたびに回復鍵が新しく生成されるため、既存の Vault エントリを新しく作成した Vault で上書きすることにより鍵のローテーションを実装しています。Vault で使用される失敗した試行のカウンタのアドレスは Vault の作成中に選択され、Android フレームワークでは、LSKF が変更されるか、コホート公開鍵の構成証明済みの新しいリストが存在する場合を除いて、以降の Vault で使用されるカウンタのアドレスは変更されません。したがって、ブルート フォース攻撃に対する LSKF の保護に悪影響を及ぼすことなく、回復鍵のローテーションを実行できます。

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

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

ハードウェアの保護

CKV サービスのサーバー側に実装される主要なセキュリティ保護は、Google 独自のカスタム設計された Titan チップを使用して構築される Trusted Hardware Module（THM）によって提供されます。このチップにより、CKV プロトコルの実装に必要な API を公開するファームウェアが実行されます。特に、これらのプロトコルでは鍵ペアを生成してコホートの他のメンバーと安全に共有できるため、ファームウェア ロジックにより、秘密鍵がコホートの Titan チップの外部に漏洩することが防止されます。また、プロトコルは Vault を開く処理を実行したり、試行を失敗するたびに厳密に増分するカウンタを Vault ごとに維持したりできます（カウンタは、Titan チップ内に保存される状態に基づきます）。CKV Titan チップ ファームウェアによって実行されるプロトコルの詳細については、このドキュメントの将来のリリースで説明します。

サーバーのセキュリティは Titan チップのファームウェア ロジックに基づくため、ロジックが変更されて、チップが秘密を流出したり、カウンタの制限を無視したりしないようにする必要があります。この目標を達成するために、Titan のブート ローダーを変更して、チップに保存されたデータ（コホートの秘密鍵など）がアップデートの適用前に完全に消去されるようにしています。この保護の難点は、データを部分的に失うことなく、ファームウェアのバグにパッチを適用できないことです。ファームウェアのアップデートは、既存のハードウェアを破壊して新しいチップに置き換えることと機能的に同等です。重要なファームウェア パッチが必要な場合、Google は、構成証明済みのコホート公開鍵の完全に新しいリストを作成して発行し、すべてのユーザーを新しいリストに徐々に移行する必要があります。このリスクを軽減するために、ファームウェアのコードベースをほとんど最小限に保ち、潜在的なセキュリティの問題を防ぐために、コードベースを入念に検査しています。

ソフトウェアの保護

THM によって適用される Vault ごとの厳密な失敗制限に加えて、CKV サービスはソフトウェアベースのレート制限も実装します。レート制限は、攻撃者がユーザーのアカウントに侵入して、失敗した回復試行の制限にすばやく到達し、回復鍵に対する実際のユーザーのアクセスを事実上ロックすることを防ぐように設計されています。画面をロック解除しようとする試行の失敗が多すぎると、ユーザーの端末で適用される時間遅延と同じように、CKV サービスでは、Vault を開くリクエストに失敗すると、以降の各試行に失敗するごとに増加する時間遅延が適用されます。

ユーザーのデータをホストするクラウド サービスに対して、厳密なアクセス制御、監視、監査などの標準的なセキュリティ対策も実装しています。

詳細なプロトコル仕様

詳細なプロトコル仕様はまだ作成中です。このドキュメントは今年中にアップデートされ、これらの詳細に加えて、Android オープンソース プロジェクトのクライアント コードの公開が含まれる予定です。

注