暗号化済みiCloudバックアップ：信頼不要のクラウド保管

VaultaireのiCloudバックアップは、固定サイズのパディング済みレコードをユーザーのプライベートなCloudKitデータベースにアップロードする前に、保管庫のデータをデバイス上でAES-256-GCMにより暗号化する。Appleは暗号文を保存するが、バックアップキーを読み取れる形で受け取ることはない。

暗号化済みiCloudバックアップとは

スマートフォンは壊れる。スマートフォンは紛失する。スマートフォンは盗まれる。最もプライベートなファイルが一つのデバイスにしか存在しないなら、一度の事故で永遠に失われる可能性がある。バックアップがこれを解決する——しかし従来のクラウドバックアップは別の問題を生む：あなたがコントロールできない企業があなたのファイルの読み取れるコピーを持つことになる。

Vaultaireは第3の道を選ぶ。保管庫はデフォルトでiCloudにバックアップされ、オフにもできるが、データはスマートフォンを離れる前にローカルで暗号化される。Vaultaireはパターンからポータブルなバックアップキーを導出し、それで固定サイズのチャンク、暗号化されたレコードタグ、バージョンディレクトリ、リカバリーデータを保護する。Appleにアップロードされるのは暗号文であり、読み取れる写真、ファイル名、構造タグではない。ただしCloudKitからは、アカウントやサービスのメタデータ、レコード数、パディング後のサイズ、アクセスのタイミングがわかる可能性がある。

暗号化はアップロードの前に行われる。アップロード中でも後でもない。これが決定的な違いだ。多くのクラウドサービスは、送信中のデータを「転送時」に、サーバー上のデータを「保存時」に暗号化するが、サービス側が復号キーを持てる場合がある。VaultaireがCloudKitに送るのは、暗号化されたバックアップレコードと暗号化されたリカバリーエンベロープだ。どちらも単体では、Appleに読み取れるバックアップキーを渡さない。

仕組み：ステップごとの解説

仕組みは明確な処理順序に沿っている。まずバックアップ用の認証情報をローカルで導出し、各コンポーネントを暗号化してパディングし、その結果のレコードと暗号化されたリカバリー情報だけをアップロードする。

ステップ1：保管庫がローカルで暗号化される

iCloudバックアップのために、VaultaireはPBKDF2-HMAC-SHA512を600,000回反復し、パターンからデバイスに依存しない別のバックアップキーを導出する。これはデバイスに紐づく保管庫キーでも、ローカルのファイル暗号化に使うランダムなマスターキーでもない。アプリはこのバックアップキーとAES-256-GCMで、保管庫の再構築に必要なコンポーネントを保護する。

ステップ2：暗号化されたブロブがiCloudに送られる

アプリはバックアップを固定サイズのチャンクに分割し、暗号化した各チャンクを10MBにパディングし、構造タグを暗号化し、おとりレコードを追加する。こうして中身の見えないレコードは、プライベートなCloudKitデータベース内の専用ゾーンにアップロードされ、iCloudストレージの容量を消費する。このレコード構成により、読み取れるファイル名、ファイルの種類、コンテンツハッシュ、論理的な役割はCloudKitに公開されない。

ステップ3：リカバリー用のアクセスは別にラップされる

読み取れるバックアップキーが、CloudKitのフィールドとしてアップロードされたり、暗号文の横に埋め込まれたりすることはない。パターンによる復元では、新しいデバイス上でキーを改めて導出する。フレーズによる復元では、リカバリーフレーズから導出した別のリカバリーキーで、保管庫キーとバックアップキーを収めた暗号化マニフェストを開く。このラッパーにより、AppleにもVaultaireにも平文の復号キーを渡さずに復元できる。

AppleがVaultaireのバックアップレコードを直接復号できない理由

この境界は、ポリシー上の約束だけでなく、クライアント側暗号化と鍵の管理から生まれる。Vaultaireは暗号文をアップロードするが、保管庫の中身の復号に必要な認証情報とキーは、クライアントとそのリカバリー情報の側に残る。

キーとノンスを正しく扱えば、AES-256-GCMは保護された平文を明かさない暗号文を生成し、ランダムな256ビットキーへの直接の総当たりは計算上現実的ではない。ただし、それでシステム全体が破られなくなるわけではない。認証情報のエントロピー、リカバリー情報、端末、ソフトウェアの完全性、実装上の欠陥は、依然として脅威モデルの一部だ。AES規格が提供するのは暗号プリミティブであり、そのキーがどう守られるかは周囲の設計で決まる。

Appleは読み取れるバックアップキーを受け取らない。アプリは、パターンによる復元ではパターンからそのキーを導出し、フレーズによる復元ではフレーズで暗号化されたマニフェストから取り出す。CloudKitが保存するのは暗号化された出力と、それを取得するのに必要な運用上のレコードであり、読み取れる保管庫の中身ではない。

裁判所命令があっても

AppleがiCloudデータに関する有効な法的要求を受けた場合、該当するiCloudの保護モデルのもとで入手可能なレコードとメタデータを提供できる。Vaultaireがアップロードするのはクライアント側で暗号化したCloudKitレコードであり、読み取れる保管庫のファイルや平文のバックアップキーではない。Appleはこれらの暗号文レコードと関連するサービスメタデータを提出できるが、保護された保管庫の中身を平文に戻すのに必要なバックアップキーは持っていない。

これはクライアント側暗号化という設計の帰結だ。Appleは保有するCloudKitレコードを引き渡せる。それでも保管庫の中身を読むには、パターンから導出したバックアップキーか、暗号化されたリカバリーマニフェストを開くリカバリーフレーズが必要になる。

信頼モデル：企業ではなく数学を信頼する

従来のクラウドストレージはプロバイダーを信頼することを要求する。彼らがデータを適切に暗号化することを信頼する。ファイルを覗き見しないことを信頼する。政府の圧力に抵抗することを信頼する。従業員がアクセス権を悪用しないことを信頼する。会ったことのない組織にかける信頼としては大きすぎる。

Vaultaireの暗号化済みiCloudバックアップにより、機密保持のためにAppleを信頼しなければならない範囲は小さくなる。コンテンツの保護は、アプリが正しいキーを導出し、AES-GCMを正しく使い、パターンとリカバリーフレーズをプロバイダーの手に渡さないことにかかっている。それでも、Vaultaireクライアント、iOS、ロック解除されたデバイスは信頼する必要があり、保存されたレコードを利用可能に保つ点ではAppleも信頼することになる。

Appleのサーバーが侵害されても、悪意あるAppleの従業員がアクセスしても、見えるのは保管庫ファイルではなく暗号文と、レコード数、サイズ、時刻といったメタデータだ。Appleが明日プライバシーポリシーを変えても、Appleはバックアップキーを持っていない。ただし、CloudKitのデータを入手した人は、パターンの推測をオフラインで試せる。パターンの組み合わせは少ないため、6点で1回曲がるだけの短いパターンより、長く何度も曲がるパターンのほうが推測されにくい。

信頼を完全になくせる暗号化アプリはない。Vaultaireの設計はAppleの役割を暗号化レコードの保管と転送に絞るが、暗号処理を正しく行う責任はクライアントに、使用中のキーと平文を守る責任はデバイスに残る。

新しいデバイスでの保管庫復元

ここで暗号化バックアップがその価値を証明する。スマートフォンが失われた——紛失、故障、盗難、機種変更。保管庫はiCloudにバックアップされていた。次に何が起きるかを説明する。

ステップ1：新しいデバイスにVaultaireをインストール

新しいiPhoneまたはiPadのApp StoreからVaultaireをダウンロードする。アプリはiCloudアカウントに暗号化されたバックアップが存在することを検知する。

ステップ2：パターンを描く

Vaultaireにおなじみの5×5グリッドが表示される。バックアップを作成したときと同じパターンを描く。バックアップキーの導出はデバイスに依存しないため、同じパターンとグリッドサイズなら新しいデバイスでも同じバックアップキーが得られる。ローカルのデバイスソルトは、このクラウドバックアップ用の導出には含まれない。

ステップ3：保管庫が復号される

暗号化されたバックアップがiCloudからダウンロードされ、新しいデバイス上でローカルに復号される。写真、動画、ドキュメントが残していたときのままに戻ってくる。プロセス全体は小さな保管庫なら数秒、大きなものなら数分かかる。このプロセス中、Appleが受け取るのは暗号化されたレコードだけで、読み取れる保管庫の中身を受け取ることはない。

パターンの代わりにリカバリーフレーズを使うこともできる。この場合、同じキーを直接再生成するわけではない。Vaultaireはフレーズからリカバリーキーを導出し、フレーズに対応する暗号化リカバリーマニフェストを取得して、保存された保管庫キーとバックアップキーを取り出してから、暗号化されたチャンクを復元する。2つの方法は、異なるキー階層を通って同じバックアップにたどり着く。

デフォルトでオン、オフにもできる

暗号化済みiCloudバックアップは、無料版でもProでもデフォルトで有効になっている。24時間ごとに実行され、ネットワーク設定を変えない限りWi-Fiのみを使う。暗号化されたバックアップが破られるより、電話を紛失したり壊したりすることのほうが多いため、新しい保管庫は復元できるコピーを持った状態で始まる。

VaultaireにCloudKit経由で保管庫のレコードをアップロードさせたくない人もいる。Vaultaireのバックアップをオフにし、同期と共有を使わなければ、アプリはこうした保管庫データの転送を開始しない。これはAppleのOSによるバックアップ動作とは別の話だ。iOSとAppleアカウントの設定によっては、iCloudやコンピューターへのデバイスバックアップにアプリコンテナのデータが含まれることがある。脅威モデル上、スマートフォンを唯一のコピーにする必要があるなら、こうしたシステムバックアップも確認して管理すること。

バックアップをオンのままにすると、デバイスを失っても保管庫を復元できる代わりに、データの暗号化されたコピーがAppleのサーバーに置かれる。コピーは暗号化されており、復号に必要な認証情報はあなたの管理下にあり、Appleが読み取れる保管庫の中身を受け取ることもない。それでもコピーは存在し、CloudKitのデータを入手した人はオフラインでパターンの推測を試せる。脅威モデル上、スマートフォンを唯一のコピーにする必要があるなら、バックアップをオフにすること。

VaultaireのCloudKitバックアップはいつでも無効にできる。無効にすると、Vaultaireはその暗号化バックアップをプライベートなCloudKitデータベースから削除する。別に存在するiOSのデバイスバックアップ、コンピューターのバックアップ、書き出したファイル、共有したコピー、他のデバイス上のデータは確認も消去もしない。

バックアップであり、同期ではない

暗号化済みiCloudバックアップが何でないかを理解することが重要だ。デバイス間のリアルタイム同期ではない。写真を追加するたびに更新される保管庫のライブミラーでもない。

暗号化済みiCloudバックアップは、復元可能なバージョンを保存する。手動でバックアップを開始したとき、またはロック解除後にVaultaireの24時間ごとの確認でバックアップが始まったとき、アプリは保管庫の現在の状態をステージングし、暗号化されたレコードをアップロードする。変更のないコンポーネントは直近のバージョンと重複排除でき、中断したアップロードは再開できる。後から追加したファイルは、その後の新しいバージョンが完了した時点で反映される。

この分離は意図的だ。バックアップは復元用のバージョンを保持し、デバイス間の継続的な同期はVaultaireのデバイス同期機能が担う。それでもバックアップ処理はステージング、重複排除、チャンクのアップロード、再試行、バージョンディレクトリ、復元トランザクションを管理する必要があるため、そのセキュリティは暗号方式だけでなく、これらの仕組みにも左右される。

貸金庫のようなものだと考えるといい。ドキュメントを絶えず行き来させるのではない。重要なファイルのコピーを箱に入れ、家が火事になったら銀行に取りに行く。オリジナルはあなたと一緒にある。バックアップは必要になるまで静かに待っている。