Google Cloud Key Vault サービス

暗号鍵へのアクセスが低エントロピー知識要素(ロック画面 PIN など)によって保護されるように、安全なハードウェアを使用して暗号鍵を保存するクラウド サービスについて説明します。セキュア ハードウェアはブルート フォース攻撃を防ぐために設計されており、正しい知識要素の指定に失敗しすぎると、保存されている暗号鍵を永続的に復元できなくなります。

著者: Shabsi Walfish
バージョン日付: 2018-03-06

注: このドキュメントは現在も開発中であり、実装の詳細はまだ完成していません。システムが安定し、より多くのドキュメントを生成できるようになったら、このホワイトペーパーを更新して、より詳細な情報を記載します(特に関連するオープンソース リリースと併せて)。

概要

従来、暗号化(データのプライバシーを確保するために使用)では、攻撃者の観点から高エントロピーを持つシークレットを使用する必要があります。高いエントロピーが必要なのは、この暗号化スキームでは、正しいシークレットが見つかるまで、可能性のあるすべてのシークレットの領域を探索するブルート フォース攻撃に耐える必要があるためです。現在のコンピューティング能力の利用可能性を考慮すると、暗号シークレットの妥当な最小エントロピー要件は 70 ~ 80 ビット程度になるでしょう。残念なことに、かなりのエントロピー量を持つパスワードやその他のシークレットを記憶して確実に思い出す1ことは、人間にとって非常に困難です。これは、特に使用頻度が極めて低い場合です(ただし、高エントロピー パスワードを頻繁に使用するのは難しく、面倒です)。このことから、ユーザーが覚える可能性が高い「知識要素」として機密データを暗号化技術で保護するにはどうすればよいかという難しい課題が残されています。さまざまな理由から、この問題は非常に困難であり、Cloud Storage サービスは通常、ユーザーが自身のシークレットを覚えておくことに依存するのではなく、Cloud Storage プロバイダ自体によって管理されるシークレットを使用してデータを暗号化します。

暗号シークレットと人間が記憶できるシークレットの要件のギャップを埋めるアプローチの一つは、Cloud Key Vault(CKV)サービスを使用して、人間が記憶できる低エントロピーのシークレットで保護された、高エントロピー「復旧鍵」を保存することです。CKV サービスは、人間が記憶する正しいシークレットを知っていることを証明した当事者にのみリカバリキーをリリースします。人間の記憶に残るシークレットに対するブルート フォース攻撃は、CKV サービスによって阻止される可能性があります。CKV サービスは、シークレットを認識していることを証明するための試行失敗の回数に絶対的な上限を適用します。リカバリキー自体は標準の暗号対称鍵であり、どこにでも安全に保存できる大量のデータ(ディスク バックアップなど)を簡単に暗号化できる(認証済みの)暗号化スキームでの使用に適しています。このような暗号化されたデータは、リカバリキーを取得できない人にとっては役に立ちません。

このホワイトペーパーでは、信頼できるハードウェア モジュール(THM)を使用して Cloud Key Vault サービスを構築するアプローチについて説明します。CKV サービスの最初の実装は、ユーザーのロック画面の知識要素(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 では、ハードウェア構成証明技術を使用して、Google のプロトコルが Titan ハードウェア上で実際に実行されていることを保証しています。

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

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

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

ロック画面の知識要素(LSKF): 短い PIN、3 × 3 ドットのグリッドでのスワイプ パターン、パスワードなど、人が記憶する秘密情報。このシークレットは、デバイスをローカルでロック解除する機能を保護するために使用され、ユーザーのローカル デバイスの画面ロックで第 1 の(または「強力な」)認証要素と見なされます。

クライアント: 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 内でのみ使用できます。

信頼できるハードウェア モジュール(THM): 最小限の信頼できるコンピューティング環境を提供するように設計された専用のセキュリティ モジュール(マイクロコントローラ)。少なくとも、セキュア エレメントは秘密鍵を生成または保存でき、不揮発性の進化状態を維持できる必要があります(以前の状態にリセットすることを伴う攻撃を防ぐため)。

Vault: CKV サービスのデータベース内の特定のエントリ。単一のデバイスの LSKF で保護された復旧鍵が含まれます。エンドユーザーは、それぞれ別のデバイスまたは LSKF に対応する複数の Vault を持つ場合があります。Vault サーバーの THM のみが Vault の内容を検査または抽出できます。

Vault サーバー: Google データセンターで稼働する汎用マシン。Trusted Hardware Module(THM)を追加するために特別に改良されています。

プロトコル設計

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

初期化

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

Google は、THM の各コホートの公開鍵のリストと、そのリストにある証明書を定期的に公開しています。リストの証明書は、ルート オブ トラストにチェーンバックする署名を使用します。公開済みリストの各更新にはシーケンス番号も含まれているため、ロールバックを防止できます。リカバリ エージェントは、コホート公開鍵の最新の公開リストを取得し、フレームワークに提供します。その後、フレームワークは証明書を検証し、Vault の作成フェーズで使用するコホート公開鍵をリストからランダムに選択します。

Vault の作成

復元エージェントは、フレームワークがコホート公開鍵のリストを取得して初期化を完了できるようサポートした後、フレームワークに新しい Vault を作成するようリクエストします。次にユーザーが LSKF を入力すると、フレームワークは新しいリカバリキーを生成し、最初に LSKF のハッシュから派生した鍵で暗号化し、次に初期化時にフレームワークによって選択されたコホート公開鍵で暗号化します。生成された暗号化された blob は、フレームワークから復元エージェントに返され、Google の CKV サービスにアップロードする Vault になります。

Vault を開く

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

CKV は、復元要求(および対応する Vault)を、正しいコホートの一部である Vault サーバーにルーティングします。次に、Vault サーバーの THM がリカバリ要求を復号し、要求された LSKF ハッシュを使用して元の Vault からリカバリ鍵の抽出を試みます(内部暗号鍵を導出します)。元の LSKF ハッシュと要求された LSKF ハッシュが一致する場合、THM は Vault から復元鍵を抽出し、Recovery Claim に含まれていた要求者鍵で再暗号化します。失敗した場合、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 を入力してデバイスをロック解除すると、LSKF が RAM 内のフレームワークで短時間使用できるようになります。その時点で、Vault を作成する新しい API でその API が使用されます。デバイスがロックされている間は、LSKF が利用できないため、LSKF で保護された Vault を新たに作成することはできません。

復元エージェントの保護

リカバリ エージェントが提供する主なセキュリティ保護は、リカバリ エージェントが現在のデバイスまたは復元キーの LSKF をまったく見えないように設計されていることです。クライアント側でこれらを確認する必要があるのはフレームワークのみであるため、復元エージェントの潜在的なバグやセキュリティの脆弱性を悪用することは非常に困難です。リカバリ エージェントは、主にライフサイクル イベントを管理し、クラウドとフレームワーク間でのデータの受け渡しを管理するために使用します。これの唯一の例外は、ユーザーが古いデバイスの 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 を開く操作を実行し、失敗した試行の Vault ごとに厳密に増加するカウンタを維持することもできます(このカウンタは Titan チップに保存された状態を基盤としています)。CKV Titan チップ ファームウェアによって実行されるプロトコルの詳細については、このドキュメントの今後のリリースで説明します。

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

ソフトウェアの保護

THM によって適用される Vault ごとの厳格な障害制限に加え、CKV サービスにはソフトウェアベースのレート制限も実装されています。レート制限は、ハイジャッカーがユーザーのアカウントに侵入し、復元の試行失敗回数の上限をすぐに使い果たして、実際のユーザーによる復旧キーへのアクセスが実質的にロックされるのを防ぐように設計されています。画面のロック解除に何度も失敗するとユーザーのデバイスに生じる遅延時間と同様に、CKV サービスでは、後続の Vault を開くリクエストが失敗するたびに遅延時間が増加します。

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

詳細なプロトコル仕様

詳細なプロトコル仕様は現在も作成中です。このドキュメントは、今年後半に Android オープンソース プロジェクトでクライアント コードが公開されるとともに、その詳細を含むように更新される予定です。

Notes

  1. 「Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX」2014 年 8 月 1 日、https://www.usenix.org/node/184458
  2. 「Google Cloud Platform ブログ: Titan の詳細: 平文のセキュリティ」2017 年 8 月 24 日、https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html
  3. 「Google は Android の月間アクティブ デバイス数が 20 億以上を発表」...2017 年 5 月 17 日、https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users
  4. これにより、別のデバイスの LSKF を入力するための柔軟な UI を提供できます。現在のデバイスのフレームワークには、古いデバイスの LSKF を入力するための適切な UI がない可能性があります。