暗号鍵へのアクセスが低エントロピー知識要素（ロック画面 PIN など）によって保護されるように、安全なハードウェアを使用して暗号鍵を保存するクラウド サービスについて説明します。セキュア ハードウェアは、正しい知識要素の提供に何度も失敗すると、格納されている暗号鍵を永続的に回復不能にすることで、ブルート フォース攻撃を防ぐように設計されています。
作成者: Shabsi Walfish
バージョン日付: 2018-03-06
注: このドキュメントはまだ開発中であり、実装の詳細はまだ完成していません。システムが安定し、より多くのドキュメントを作成できるようになったら、より詳しい情報を追加してこのホワイトペーパーを更新します（特に、関連するオープンソース リリースとの関連）。
概要
従来、暗号化（データのプライバシーを保護するために使用される）では、攻撃者から見てエントロピーが高いシークレットを使用する必要がありました。暗号化スキームでは、正しいシークレットが見つかるまですべての可能性のあるシークレットのスペースを探索するブルート フォース攻撃に耐える必要があるため、高エントロピーが必要です。現在のコンピューティング能力の可用性を考慮すると、暗号シークレットの妥当な最小エントロピー要件は 70 ～ 80 ビット程度になるでしょう。残念なことに、そのようなエントロピー1 を持つパスワードやその他のシークレットを記憶し、確実に思い出すことは、特にまれにしか使用されない場合です（ただし、高エントロピー パスワードを頻繁に使用するのは難しく、面倒です）。このため、ユーザーが記憶する可能性が高い「知識要素」としてシークレット データを保護するには、暗号化技術を使用して個人データをどのように保護すればよいのか、という難しい課題が残されています。さまざまな理由から、この問題は極めて困難であるため、Cloud Storage サービスは通常、ユーザーが自身のシークレットを記憶することに依存するのではなく、Cloud Storage プロバイダ自体が管理するシークレットを使用してデータを暗号化します。
暗号シークレットと人間が記憶するシークレットの要件のギャップを埋めるアプローチの 1 つは、Cloud Key Vault（CKV）サービスを使用して、低エントロピーの人間の記憶に残るシークレットで保護された高エントロピー「復旧鍵」を保存することです。CKV サービスは、人間の記憶に残る正しい秘密を把握していることを証明した当事者にのみ復旧キーをリリースします。人間の記憶に残るシークレットに対するブルート フォース攻撃は、CKV サービスによって阻止できます。CKV サービスは、シークレットに関する知識を証明するために失敗する試行回数に絶対的な制限を適用します。リカバリキー自体は標準の暗号対称鍵で、どこにでも安全に保存できる大量のデータ（ディスク バックアップなど）を簡単に暗号化できる（認証済みの）暗号化スキームでの使用に適しています。このような暗号化されたデータは、リカバリキーを取得できない人にとっては役に立ちません。
このホワイトペーパーでは、Trusted Hardware Modules（THM）を使用して Cloud Key Vault サービスを構築するアプローチについて説明します。CKV サービスの最初の実装では、ユーザーのロック画面知識要素（LSKF）でリカバリキーを保護するように設計されています。LSKF とは、スマートフォンのロック解除に使用する秘密の PIN、パスワード、またはスワイプ パターンです。人間は LSKF を確実に記憶できます。同時に、このような LSKF Secret は通常、試行回数が非常に少ない攻撃者に耐えるのに十分なエントロピーを持っているため、CKV サービスに適しています。
Cloud Key Vault サービスの最初の適用は、クライアントサイド暗号化が適用された Android バックアップを有効にすることです。これまで、Android デバイス上でローカルに暗号化されたファイルは、ユーザーの LSKF で保護された鍵を使用していましたが、クラウドに保存（および暗号化）されたファイルのバックアップは LSKF で保護されませんでした。Cloud Key Vault により、初めて、クラウドに保存されている Android バックアップのロック画面保護も可能になりました。つまり、Google のサーバーは暗号化されたバックアップの内容にアクセスしたり、コンテンツを復元したりすることはできません。ユーザーの LSKF を持つデバイスのみがバックアップを復号できます。
基本コンセプト
当初、Cloud Key Vault サービスでサポートされているクライアント プラットフォームは Android 9 Pie オペレーティング システムのみです。このホワイトペーパーでは、このホワイトペーパーでは、Google Play 開発者サービスを備えた Android 9 Pie オペレーティング システムを搭載したデバイスを指します。Google のサーバー側の実装は、追加の Titan チップ2 がインストールされている特別な Google サーバーで実行されます。Google が設計した Titan チップは、Trusted Hardware Module のハードウェア コンポーネントとして機能し、Google のプロトコルとセキュリティ適用メカニズム（後述）を実装するカスタム ブートローダーとファームウェアでプロビジョニングしています。Google では、プロトコルが実際に Titan ハードウェア上で実行されていることを保証するために、ハードウェア構成証明手法を使用しています。
CKV サービスは、ハードウェア障害（チップの燃焼など）やデータセンターのメンテナンスによる長期にわたるサービス停止によって、大量のデータを失うことなく、数十億台の Android デバイス3 からのトラフィックを処理するためにスケーリングする必要があります。このため、Titan チップを搭載したサーバーはコホートに編成され、各コホートは、同じ鍵マテリアルのコピーを含む複数の独立した THM で構成されています。特定のコホートは、システムの可用性と信頼性の目標を達成できるように、異なるメンテナンス ゾーンにある物理的に異なるデータセンターに分散されます。スケーラビリティを確保するために、クライアントは複数のコホートにシャーディングされるため、サーバーを追加するだけでサービスの容量を調整して、使用可能なコホートの数を増やすことができます。
これで、Cloud Key Vault サービス アーキテクチャの主要コンポーネントを列挙する準備ができました。
アーキテクチャ コンポーネント / 用語集
ロック画面の知識要素（LSKF）: 短い PIN、3 × 3 ドットでのスワイプ パターン、パスワードなど、人間が記憶できる秘密。このシークレットは、デバイスをローカルでロック解除する機能を保護するために使用され、ユーザーのローカル デバイスの画面ロックのプライマリ（または「強力な」）認証要素と見なされます。
クライアント: Android 9 Pie オペレーティング システムと Google Play 開発者サービス、または同等にサポートされているソフトウェアを実行しているエンドユーザー デバイス。
-
Android フレームワーク:Android 9 Pie 以降の API を指す場合は、この一般的な用語（または単にフレームワーク）を使用します。以前のリリースを指すものではありません。
Google Play 開発者サービス: エンドユーザー デバイス上で実行されるサービスとアプリのコレクション。Google のアカウント システムやカスタム サーバー API との連携を可能にします。
リカバリ エージェント: Android 9 Pie デバイス（または同様のもの）上のユーザー空間で 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 を登録し、それぞれが異なるデバイスまたは LSKF に対応している場合があります。Vault 内の THM のみが Vault の内容を調査または抽出できます。
Vault サーバー: Google データセンターで稼働する汎用マシンで、Trusted Hardware Module（THM）を追加するために特別に改良されています。
プロトコル設計
CKV プロトコルは、次のような複数のフェーズで構成されます。
初期化
システムを初期化するために、Google は「ルート オブ トラスト」の公開鍵を提供します。この公開鍵は、フレームワークが Google のハードウェア構成証明を検証するために使用します。このルート オブ トラストの署名鍵はオフラインで保存され、厳重に保護されているため、署名するには複数の従業員の関与が必要になります。このルート オブ トラストの公開鍵は Android OS に組み込まれており、OS のアップデートによってのみ変更できます。
また、Google は、THM の各コホートの公開鍵のリストと、リスト上の証明書を定期的に公開しています。リストの証明書は、ルート オブ トラストにチェーンバックする署名を使用します。公開リストの各更新にはシーケンス番号も含まれているため、ロールバックを防ぐことができます。復旧エージェントは、最近公開されたコホートの公開鍵のリストを取得し、フレームワークに供給します。次に、フレームワークは証明書を検証し、Vault 作成フェーズで使用するコホート公開鍵をリストからランダムに選択します。
Vault の作成
復元エージェントは、コホート公開鍵のリストを取得してフレームワークが初期化を完了できるようサポートした後、フレームワークに新しい Vault の作成をリクエストします。次にユーザーが LSKF を入力すると、フレームワークは新しい復旧鍵を生成し、まず LSKF のハッシュから導出された鍵で暗号化し、次に初期化時にフレームワークによって選択されたコホート公開鍵で暗号化します。生成された暗号化された blob が Vault で、フレームワークによって回復エージェントに返されてから、Google の CKV サービスにアップロードします。
Vault を開く
新しいデバイスの復旧エージェントが特定の Vault に保存されている復旧鍵にアクセスする必要がある場合、まず、Vault を作成した元のデバイスの LSKF を入力するようユーザーに求めます。回復エージェントは、その LSKF を使用して回復要求を作成するようフレームワークに要求します。フレームワークは新しい要求者鍵を生成し、その要求者鍵と要求された LSKF のハッシュを、Vault の元々の暗号化に使用されたのと同じコホート公開鍵で暗号化します。結果として得られる暗号化された 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 のアップデートなしでは変更できません。これにより、LSKF はハードウェア ベースのブルート フォース保護を適切に適用する Vault の作成にのみ使用されるという確信が得られます。Cloud Key Vault サービスの THM を使用して LSKF のブルート フォース保護を実現することで、（Google Pixel 2 デバイスと同様に）デバイスでセキュアなハードウェアを使用する場合と同等のセキュリティを実現できます。
LSKF はデバイスの安全なハードウェア以外の場所に保存されることは想定されていないため、新しい Vault を作成できるのはデバイスのロック解除直後に限られます。ユーザーが LSKF を入力してデバイスをロック解除すると、フレームワークが RAM 内の LSKF を一時的に使用できるようになります。これが、Vault を作成する新しい API によって使用されるタイミングです。デバイスがロックされている間は、LSKF が利用できないため、LSKF で保護された新しい Vault を作成することはできません。
復旧エージェントの保護
復旧エージェントが提供する主なセキュリティ保護は、復旧エージェントが現在のデバイスや復旧キーの LSKF を見ないようにするプロトコルです。クライアント側でこれらを確認できるのはフレームワークのみとなるため、復旧エージェントの潜在的なバグやセキュリティの脆弱性を悪用することが難しくなります。リカバリ エージェントは主に、ライフサイクル イベントと、Cloud とフレームワーク間のデータの受け渡しを管理するために使用されます。これに対する唯一の例外は、ユーザーが古いデバイスの LSKF を入力する必要がある、Vault を開くプロトコルの直前の復元中に発生します。古いデバイス用に要求された LSKF を収集する UI は、復元エージェント4に実装されています。ただし、フレームワークが回復要求の作成を引き継ぐとすぐに、回復エージェントの実装は要求された LSKF を「消去」します。
プロトコルのセキュリティ機能
プロトコルの詳細な分析はこのドキュメントの範囲外ですが、プロトコルに組み込まれている保護機能をいくつか紹介します。特に、プロトコルは全体で LSKF のハッシュのみを使用します。つまり、LSKF のエントロピーが高い場合（たとえば、適切な高エントロピーのパスワードである場合）、パスワード ハッシュを保存するよりも Vault を保存するほうがはるかに優れています。この場合、パスワード ハッシュは THM のセキュリティとは無関係のセキュリティ対策を提供できます。このため、プロトコルの一部として、LSKF のソルト付き「メモリハード」ハッシュをサポートしています。また、Vault を作成したデバイスの識別子に暗号的にバインドし、Vault 起動プロトコルでチャレンジとして使用されるノンスに復元要求をバインドして、復元要求が最新であることを確認します。
復旧鍵は Vault が作成されるたびに新しく生成されるため、既存の Vault エントリを新しく作成された Vault で上書きすることで鍵のローテーションを実装します。Vault で使用される失敗した試行カウンタのアドレスは、Vault の作成時に選択されます。フレームワークにより、LSKF が変更されたか、コホート公開鍵の新しい証明済みリストがある場合を除き、後続の Vault に使用されるカウンタ アドレスは変更されません。したがって、LSKF のブルート フォース保護に悪影響を及ぼすことなくリカバリ鍵のローテーションを行うことができます。
Cloud Key Vault サービスのサーバー セキュリティ
このサーバーは、通常のサーバー ハードウェア上で実行されるソフトウェアと、専用のハードウェア上で実行されるファームウェア（Titan チップ）を組み合わせて実装されます。各レイヤで提供される保護について説明します。
ハードウェアの保護
CKV サービスのサーバー側に実装されている主なセキュリティ保護は、Google 独自のカスタム設計の Titan チップを使用して構築された Trusted Hardware Module（THM）です。チップは、CKV プロトコルの実装に必要な API を公開するファームウェアを実行します。特に、鍵ペアを生成してコホートの他のメンバーと安全に共有することで、ファームウェア ロジックが秘密鍵がコホートの Titan チップの外部に漏洩しないように保護できます。また、Vault Opening オペレーションを実行し、失敗した試行の Vault ごとのカウンタを厳密に増加させておくこともできます（カウンタは Titan チップ内に保存された状態に基づきます）。CKV Titan チップ ファームウェアによって実行されるプロトコルについては、このドキュメントの今後のリリースで詳しく説明します。
サーバーのセキュリティは Titan チップのファームウェア ロジックから派生しているため、チップがシークレットを漏洩させたり、カウンタ制限を無視したりするような方法でロジックが変更されないようにする必要があります。この目標を達成するために、Titan ブートローダーを変更し、更新が適用される前にチップに保存されているデータ（コホートの秘密鍵など）を完全にワイプするようにもしています。この保護機能の欠点は、ファームウェアのバグにパッチを適用するには、ある程度のデータ損失が生じることです。ファームウェアの更新は、既存のハードウェアを破棄して新しいチップに置き換えるのと機能的に同等です。重要なファームウェア パッチが必要な場合、Google は証明済みのコホート公開鍵のまったく新しいリストを作成して公開し、すべてのユーザーを新しいリストに段階的に移行する必要があります。このリスクを軽減するため、Google ではファームウェアのコードベースを最小限に抑え、潜在的なセキュリティの問題がないか慎重に監査しています。
ソフトウェアの保護
THM によって課される Vault ごとのハード障害制限に加えて、CKV サービスにはソフトウェア ベースのレート制限も実装されています。レート制限は、ハイジャッカーがユーザーのアカウントに侵入して復元の失敗回数の上限をすぐに使い果たしてしまうことを防ぎ、実際のユーザーの復旧キーへのアクセスが実質的にロックアウトされるのを防ぐように設計されています。画面のロック解除に何度も失敗するとユーザーのデバイスによって生じる時間遅延と同様に、CKV サービスは、以降失敗する Vault を開くリクエストごとに遅延を増加させます。
また、ユーザーデータをホストするクラウド サービスに対して、厳格なアクセス制御、モニタリング、監査など、標準的なセキュリティ対策を実装しています。
詳細なプロトコル仕様
詳細なプロトコル仕様はまだ開発中です。このドキュメントは、今年後半に Android オープンソース プロジェクトでクライアント コードが公開されるとともに、それらの詳細を含むように更新される予定です。
Notes
- 「Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX.」2014 年 8 月 1 日、https://www.usenix.org/node/184458。↩
- 「Google Cloud Platform ブログ: Titan の詳細: 平文のセキュリティ」2017 年 8 月 24 日、https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html。 ↩
- 「Google は、Android で月間 20 億台を超えるアクティブなデバイスを発表しています...」、2017 年 5 月 17 日、https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users。↩
- これにより、別のデバイスの LSKF を入力するための柔軟な UI を提供できます。現在のデバイスのフレームワークには、古いデバイスの LSKF を入力するための適切な UI がない可能性があります。↩