写真保管庫を思い描く最も簡単な方法
写真を金庫の中に入れるところを想像してください。
この比喩には1つ重要な限界があります。物理的な金庫に入るのは1つの物体です。一方、端末は多くのコピーを保持し得ます。「写真」やギャラリーの原本、保管庫にインポートしたコピー、サムネイル、編集済みのバージョン、メッセージの添付、クラウド上のコピー、書き出したファイルなどです。1つのコピーを暗号化しても、他のコピーが自動的に保護されたり削除されたりするわけではありません。
保管庫は、ロックされている間、自分が管理するデータを保護します。元のコピー、画面に表示された平文、書き出したファイルは、それぞれ別のセキュリティ境界に属します。
- 写真は平文です。つまり、読める状態の元の情報です。
- 金庫の鍵は暗号鍵です。暗号アルゴリズムが使う、長くランダムな秘密情報です。
- 施錠された金庫は暗号文です。鍵がなければ意味を持たないように見えるべきデータです。
- パスワード、PIN、パターンは、アプリが鍵を使ってよいことを証明します。それ自体が、すべてのファイルを直接暗号化する鍵であるべきではありません。
写真をインポートすると何が起きるのか
適切に設計されたインポートの流れは、通常、大きく4つの段階をたどります。
現代の保管庫の多くは AES-GCM を使います。AES は NIST FIPS 197 で標準化されたブロック暗号であり、GCM は NIST SP 800-38D で規定された認証付き暗号化のモードです。
こうした標準としての来歴は重要ですが、アルゴリズム名だけでアプリが安全である証明にはなりません。鍵の生成、ノンスの扱い、メタデータ、バックアップ、エラー処理、平文が存在する時間の長さも、すべて重要です。
- アプリが選択されたファイルを読み込みます。この時点では、元の写真がシステムの写真ライブラリにまだ存在している場合があります。
- アプリがランダムな保管庫の鍵を生成、または取得します。安全なアプリケーションは、覚えやすい単語や予測可能な値ではなく、オペレーティングシステムの暗号学的乱数生成器を使います。
- アプリが写真を暗号化し、認証します。出力は暗号文と、それが改変されていないことを検証するために必要な情報です。
- アプリが封をした結果を保存します。保管庫がロックされると、復号鍵へのアプリの通常のアクセスは取り除かれます。
パスワードをファイルの鍵にすべきでない理由
人は、自分が覚えられるパスワード、PIN、パターンを選びます。暗号鍵は、長く、ランダムで、推測が現実的でないものであるべきです。これらは別々の役割です。
健全な設計では、認証情報と、保管庫を保護するランダムな鍵とを分離します。
Argon2id は現代的な鍵導出の選択肢の1つです。RFC 9106 は Argon2 をメモリハードな関数として説明し、その主要な変種として Argon2id を含めています。メモリハードな処理は、特に大規模な場合に、1回ごとの推測をより高価にします。ただし、1234、短い四角形、使い回されたパスワードを強い秘密情報に変えることはできません。
この階層的なモデルは、パスワードの変更も現実的にします。アプリは、すべての写真を復号して再暗号化する代わりに、安定した保管庫の鍵へのアクセスの包み方を変えられます。OWASP も「Cryptographic Storage Cheat Sheet」で、データ暗号鍵を別個の鍵暗号鍵で保護するという、同じ考え方の分離を説明しています。
- パスワード、PIN、またはパターンを入力します。
- 鍵導出関数が、それを固有のソルトとともに処理し、意図的に計算資源を消費します。
- その結果が、ランダムな保管庫の鍵を解錠、または取り出します。
- 保管庫の鍵が、コンテンツ、メタデータ、個々のファイル用の別々の鍵の起点になります。
認証付き暗号化が重要な理由
暗号化は1つの問いに答えます。「鍵がない者に、このデータの内容が分かるか」
認証は別の問いに答えます。「この暗号化されたデータは変更されたか」
AES-GCM は両方の役割を兼ねます。アプリがファイルに封をするとき、認証タグも生成します。暗号文またはその保護された文脈が変更されていれば検証は失敗し、アプリは平文を渡すことを拒否すべきです。NIST は SP 800-38D でこれを「関連データ付き認証暗号」と呼んでいます。
関連データは、暗号化された記録を、入れ替えられてはならない事実——たとえばその保管庫、ファイル、レコードの種別、チャンクの位置——に結び付けられます。これにより、有効な暗号化ブロックが誤った文脈へ黙って移されることを防げます。
安全側に倒れて失敗することには、トレードオフがあります。破損または改変された暗号文は利用できなくなる可能性があります。これは検証されていない出力を表示するより安全ですが、代替不可能なファイルにテスト済みのバックアップが必要な理由でもあります。
写真はフルサイズの画素だけではない
元のファイルが暗号化されていても、プライベートなメディアは手がかりを残し得ます。完全な保管庫の設計では、次を考慮する必要があります。
保管庫がフルサイズの写真を暗号化しても、読み取れるサムネイルや内容の分かるファイル名をディスク上に残していれば、最も機微な情報が依然として露出しているかもしれません。優れた製品文書は、その保護境界にコンテンツ、メタデータ、サムネイル、一時ファイルが含まれるかどうかを明示すべきです。
- ファイル名と利用者が付けたラベル
- 日付、位置情報、その他のメタデータ
- サムネイルとプレビュー
- 編集内容と最適化されたバージョン
- Live Photo やペアになった動画のデータ
- アルバムへの所属と検索インデックス
- 閲覧や書き出しの際に作られる一時ファイル
「ロックされている」とは実際にどういうことか
保管庫がロックされているとき、アプリはファイルを表示するために必要な、有効な平文の鍵への通常のアクセスを失っているべきです。暗号化されたファイルはストレージ上に残り得ますが、必要な鍵がなければ、それらのファイルは意味のある形で読めないはずです。
ロックを解除すると状況は変わります。画像を表示するには、オペレーティングシステムが描画できるだけのデータをアプリが復号しなければなりません。そのとき平文はメモリ上と表示経路上に存在します。アプリのライフサイクルに応じたロック、鍵の短い有効期間、保護された一時ストレージは露出を減らせますが、見えている平文を見えなくすることはできません。
Android では、Android Keystore が対象となる鍵素材を書き出し不可のまま保持し、対応端末ではセキュアなハードウェアに結び付けられます。Apple の Keychain のデータ保護も同様に、機微な項目に対して保護クラスと Secure Enclave が強制するアクセス制御を提供します。
これらのプラットフォーム機能は価値がありますが、すでに侵害され、ロックが解除された端末を安全にするものではありません。アプリやオペレーティングシステムを制御する悪意あるソフトウェアは、鍵そのものを書き出せなくても、鍵を使う操作を要求したり、利用者が閲覧している間の平文を観測したりできる場合があります。
非表示アルバム、端末の暗号化、暗号化された保管庫は別物
これらの保護は組み合わせて機能し得ますが、解決する問題は異なります。
したがって「暗号化されている」は完全な答えではありません。どのコピーが、誰に対して、端末がどの状態のときに守られるのか、そして誰が鍵を入手できるのかを尋ねてください。
- 保護の種類 — 主に何を守るか — 解除の権限 — 重要な限界
- 非表示アルバムやギャラリーでの非表示 — 写真アプリ内での偶発的な発見 — 通常は端末または写真アプリのロック — 項目は同じ写真ライブラリとクラウド同期のモデルに留まり得る
- 端末ストレージの暗号化 — ロックまたは電源オフの端末上のデータ — 端末のパスコードとプラットフォームの鍵 — 端末のロックが解除されれば、許可されたアプリは自分のデータを使える
- 暗号化された写真保管庫 — 保管庫がロックされている間の、アプリが管理するコピー — 保管庫の認証情報とアプリの鍵設計 — 原本、書き出したファイル、画面、その他のコピーは別のまま
- エンドツーエンド暗号化されたクラウド上のコピー — 認可された端点の間のコンテンツ — 認可された端末が利用できる鍵 — 提供者はアカウント、時刻、サイズ、通信のメタデータを処理し得る
ゼロ知識暗号化とは何か
ゼロ知識暗号化は一般に、提供者が暗号化されたデータを保存する一方で、利用者のコンテンツを復号するのに必要な鍵を持たない、というサービス構成を指して使われます。暗号化はデータが提供者に届く前に行われ、復号は認可された利用者の端末で行われます。
分かりやすい比喩は、金庫を貸すが暗証番号は決して受け取らないホテルです。ホテルは金庫を保管し、運ぶことができます。金庫が存在することと、その大きさも分かります。しかし暗証番号を忘れた利用者のために金庫を開けることはできません。
クラウドの保管庫については、中心となる問いは次のとおりです。
ゼロ知識とは、サービスが文字どおり何も知らないという意味ではありません。それは暗号化されたコンテンツへのアクセスについての説明であり、あらゆるサービスのメタデータが存在しないという意味ではありません。また、ロックが解除された端点を保護するものでもありません。侵害された端末は、正当な復号の後で写真を観測できます。
1つのシステムが両方の説明を使うこともありますが、読者はどちらかのラベルだけに頼るのではなく、文書化された鍵と復旧の設計を確認すべきです。
ここには現実のトレードオフがあります。提供者からの分離を強めるほど、利用者側の責任は大きくなります。認可されたすべての端末と、すべての復旧用の秘密情報を失えば、データは永久にアクセスできなくなり得ます。
- 暗号鍵は利用者の端末で生成または導出されますか。
- 提供者が平文の鍵や認証情報を受け取ることはありますか。
- アカウントのサポートがアクセスをリセットし、以前のファイルを明らかにできますか。
- 新しい端末には、復旧用の秘密情報や既存端末からの承認が必要ですか。
- アカウント、時刻、端末、ストレージ容量、ネットワークのメタデータのうち、何が見えるままですか。
- ゼロ知識とエンドツーエンド暗号化の違い — 考え方は重なりますが、力点が異なります。
- エンドツーエンド暗号化は経路を説明します。コンテンツがサービスを通って移動・同期する間、復号できるのは認可された端点だけであるべきだ、という考え方です。
- ゼロ知識暗号化は提供者のアクセスを強調します。提供者は、保存された利用者のコンテンツを復号するのに必要な権限を持つべきではない、という考え方です。
- 復旧に関するトレードオフ — 提供者が本当に復号の権限を持たないなら、リセット用のリンクをメールで送るだけで、以前の暗号化されたコンテンツへのアクセスを回復させることはできません。復旧には、リカバリーフレーズ、リカバリーキー、既存端末からの承認、事前に書き出した鍵といった、別の権限の源が必要になります。
保管庫アプリを信頼する前に尋ねるべき7つの質問
- 1. 正確には何が暗号化されるのか — 元のコンテンツ、サムネイル、ファイル名、メタデータ、メモ、一時ファイルについて明示的な記述を探してください。暗号方式の名前だけでは不十分です。
- 2. 鍵はどこから来るのか — アプリはコンテンツ用の鍵に暗号学的に安全な乱数を使うべきです。パスワードやパターンは、そのままファイルの鍵になるのではなく、文書化された鍵導出の設計を通るべきです。
- 3. 改ざんを検出するか — AES-GCM や ChaCha20-Poly1305 のような認証付き暗号化、あるいは十分に文書化された「暗号化してから認証する」構成を探してください。OWASP は、利用できる場合は認証付きのモードを推奨しています。
- 4. 原本はどうなるのか — インポートと削除は別々の操作です。「写真」やギャラリー、「最近削除した項目」やゴミ箱、「ファイル」、クラウドライブラリ、メッセージ、共有アルバム、他の端末を確認してください。
- 5. 端末を紛失したらどうなるのか — 復元可能なコピーのない暗号化保管庫は、プライバシーは守っても可用性は守りません。復旧に元の端末、暗号化バックアップファイル、フレーズ、アカウント、あるいはそれらの組み合わせのどれが必要かを理解してください。
- 6. 提供者はアクセスをリセットして以前のデータを明らかにできるか — できるなら、提供者または復旧の仕組みが、復号の権限へ至る何らかの経路を持っています。それは意図された利便性かもしれませんが、明確に開示されるべきです。
- 7. 限界は書かれているか — 信頼できる文書は、暗号方式の名前だけでなく、侵害された端末、弱い認証情報、書き出したファイル、削除の限界、バックアップ、復旧できないデータについても論じるべきです。
架空の例
この架空のシナリオでは、Maya がパスポートのスキャンを保管庫にインポートし、ロックと解除の後にフル解像度のコピーが開くことを確認します。それから、文書化された暗号化バックアップを作成してテストします。この2つの確認を終えて初めて、不要な元のコピーがないか、「写真」、「最近削除した項目」、「ファイル」、「メッセージ」、クラウドの写真ライブラリを見直します。
保管庫は、ロックされている間、自分が管理するコピーを保護します。バックアップは端末の紛失に備えます。他のコピーを取り除くことは、保管庫の外での露出を減らします。これらは3つの別々の役割であり、どれか1つでも省けば結果は変わります。
覚えやすい認証情報がランダムな鍵へのアクセスを承認し、認証付き暗号化が管理下の写真を封をされた暗号文に変えます。
暗号化で守れないもの
暗号化された写真保管庫には、次のことはできません。
正しい心構えは単純です。暗号化は、明示された境界の内側では強力です。優れたプライバシーは、その境界を理解し、そこを越えるすべてのコピーを管理することから生まれます。
- 原本、書き出したファイル、メッセージ、バックアップ、受信者のコピーを自動的に取り除くこと
- ロック解除された画面を別のカメラが撮影するのを止めること
- 弱い、あるいは見られてしまったパスワードやパターンを推測不可能にすること
- ロック解除中に、侵害されたオペレーティングシステムから平文を守ること
- フラッシュストレージ、スナップショット、古いバックアップからの物理的な消去を保証すること
- 有効な暗号文のコピーと必要な復旧用の秘密情報がすべて失われた後にデータを復旧すること
- アプリや暗号化ストレージが存在するという証跡をすべて隠すこと
よくある質問
- ファイルをコピーすれば保管庫の中身を読めますか？ — 健全な設計は、コピーされた暗号文を、必要な鍵素材なしには読めないものにすることを目指します。これはオフラインでのコピーについての話です。保管庫のロックが解除されている間に元の端末を制御している人物は、これとは異なる——そしてはるかに容易な——攻撃面に向き合っています。
- AES-256 であればアプリが安全だと証明できますか？ — いいえ。AES-256 は標準化された暗号方式ですが、それが安全に使われているかどうかは周囲の設計が決めます。鍵の生成、認証付きのモード、ノンスの一意性、メタデータ、一時ファイル、バックアップ、エラー処理のすべてが重要です。
- サムネイルも暗号化されますか？ — プライベートな内容が分かってしまうのであれば、保管庫の保護境界の内側にあるべきです。ただし、インポート前や書き出し後に作られたプレビューを、他のアプリやオペレーティングシステムが保持している可能性はあります。
- パスワードを変更すると、すべての写真が再暗号化されますか？ — 必ずしもそうではありません。階層的な設計では、パスワードは安定したランダムな保管庫の鍵へのアクセスを制御します。認証情報が変わったというだけの理由で、アプリはすべてのコンテンツを再暗号化することなく、その鍵へのアクセスを包み直せます。
- 暗号化されたデータが破損したらどうなりますか？ — 暗号文またはその保護された文脈が検証できない場合、認証付きの復号は失敗すべきです。これにより、変更されたデータが黙って受け入れられることは防げますが、破損したファイルは利用できなくなり得ます。代替不可能なものには、テスト済みのバックアップを用意してください。
- 暗号化バックアップは自動的にプライベートかつ復元可能ですか？ — いいえ。プライバシーは誰が鍵を持つかに依存し、復元は必要な権限と有効な暗号化コピーの両方を保持し続けているかに依存します。リカバリーフレーズは、失われたバックアップファイルを再生成できません。
一次情報源と参考資料
NullVault の製品固有の実装については、別途「セキュリティアーキテクチャ」と「セキュリティ上の限界」をご覧ください。
ガイド確認日：2026年8月30日。
- NIST FIPS 197：Advanced Encryption Standard (AES)
- NIST SP 800-38D：Galois/Counter Mode (GCM) と GMAC
- RFC 9106：Argon2 メモリハード関数
- OWASP 暗号化ストレージ・チートシート
- Android Developers：Android キーストア システム
- Android Developers：暗号化
- Apple Platform Security：Keychain のデータ保護
- Apple Platform Security：暗号化とデータ保護の概要
Eli はまず、機微でないデータでテストします。「暗号化された写真保管庫の仕組みを検討するにあたり、まず機微でない項目を1つ使う」。次に Eli は2つ目の確認手順に従います。「該当するアプリまたは端末をロックし、新しいセッションから結果を確認する」。この架空のシナリオは判断の流れを示すものであり、製品テストの報告ではありません。
- 「暗号化された写真保管庫の仕組み」で説明した結果は、エクスポート済み、共有済み、キャッシュ済み、クラウド同期済みのコピーを自動的には対象としません。
- 認証情報の紛失、アプリコンテナの削除、端末の初期化、未検証のバックアップにより、保護されたデータが利用できなくなることがあります。
保管庫は実際には何を守るのですか？
保管庫は、自分が管理するコピーが保存状態でロックされている間、それを守ります。カメラロールにまだある写真、すでに書き出された写真、ロック解除された画面に表示されている写真は守りません。
暗号化された保管庫の鍵は誰が持っていますか？
ローカル優先の設計では、鍵は利用者の端末上で、認証情報とプラットフォームの鍵素材から導出されます。だからこそ、認証情報を忘れ、復旧経路をテストしていない場合、コンテンツが永久に利用できなくなり得ます。