暗号化ストレージはファイルのバイト列と復号権限を分離しますが、受信者、メタデータ、ローカルコピーは引き続き脅威モデルに含まれます。
エンドツーエンド暗号化された添付ファイルは、平文のファイルをサーバーに渡さずに保存できます。一般的な設計では、送信者の端末で新しいコンテンツ鍵を使ってファイルを暗号化し、暗号文をアップロードし、認証付きの暗号化メッセージ内で意図した受信者へ鍵を送ります。
この分離は有用ですが、「ゼロ知識ストレージ」は完全な仕様ではありません。鍵、ファイル参照、ファイル名、アクセス制御、ダウンロード済みコピーをどう扱うかは、なお確認が必要です。
添付ファイルのライフサイクル
- ファイルを準備する。 送信者が写真、動画、文書を選びます。メタデータの削除や変換処理は別の手順です。暗号化だけでは EXIF や文書のプロパティは取り除かれません。
- 暗号材料を作る。 安全な実装は、選択した方式に従って必要な鍵と nonce を生成します。
- アップロード前に暗号化する。 ストレージサービスが受け取るのは、元の内容ではなく暗号化されたバイト列です。
- 認証付きの参照を届ける。 暗号化されたチャットメッセージが、ファイルの所在、復号鍵、関連する完全性メタデータなど、受信者に必要な情報を運びます。
- 取得して検証する。 受信クライアントはデータ本体を取得し、結果を有効な内容として扱う前に認証を検証します。
- ローカルコピーを管理する。 表示、書き出し、編集、ギャラリーへの保存によって、元の暗号化ストレージの境界外にコピーが作られることがあります。
鍵は、暗号化された封筒に包まれて同じ提供者の基盤を通る場合があります。これを「帯域外」と呼ぶと誤解を招きます。データ本体の保存とは論理的に分離されていても、独立した通信経路で届けられるとは限らないからです。
認証付き暗号が加えるもの
認証付き暗号方式は機密性を保護し、認証対象の範囲内で許可されていない変更を検出します。NIST の GCM 仕様は、そのような構成の一つと要件を定義しています。鍵と nonce の正しい扱い、認証結果の確認が不可欠です。広く認められたアルゴリズムの名前だけで、すべての実装が安全になるわけではありません。
アプリはファイルを正しいメッセージと会話に結び付ける必要もあります。有効な暗号化データ本体であることだけでは、その特定のチャットに属する証拠になりません。ファイル識別子、想定サイズ、チャンク順序、添付メタデータには適切な認証設計が必要です。
ストレージサービスがなお知り得ること
| 情報 | 内容の暗号化だけで隠れるか？ |
|---|---|
| 元のファイルのバイト列 | 鍵のない当事者から隠すよう設計されている |
| 暗号化後のおおよそのサイズ | 通常は隠れない |
| アップロードとダウンロードの時刻 | 通常は隠れない |
| どのアカウントがファイルを要求するか | ルーティングとアクセス制御の設計による |
| ファイル名とキャプション | プロトコルがそれらも保護する場合のみ |
| 受信者が保存したコピー | いいえ。受信者はすでに平文へアクセスできる |
データ本体が暗号化されていてもアクセス制御は重要です。不要なダウンロード、悪用、識別子の露出を制限できます。暗号化は、権限管理、保持方針、可用性の代わりにはなりません。
大きなファイルにはスローガン以上のものが必要
大容量ファイルの設計では、ストリーミングや認証付きチャンクへの分割が使われる場合があります。メモリ使用量を減らせますが、チャンク番号、最終的な長さ、再試行、途中切れの扱いを定義しなければなりません。性能値を捏造したり、メッセージにファイルを含めると必ず「ラチェット状態の肥大化」が起きると主張したりしてはいけません。結果は実装次第です。
有益な試験には、有効なファイル、1 バイトの改変、途中で切れたダウンロード、順序を入れ替えたチャンク、権限のない取得の試行が含まれます。これらは、許可された試験環境で機密性のないファイルだけを使って実施してください。クライアントが無効なデータを開く前に拒否するかを記録します。
Livara が文書化していること
Livara のセキュリティページは、アップロード前の暗号化、保護されたセッション内で運ばれるファイルごとのランダムな鍵、対応する非公開グループを含む E2EE が有効な会話でのファイル名とキャプションの保護を説明しています。古い非対応グループは明示的に対象外です。保護された会話と公開配信チャンネルも区別しています。これらは文書化された製品の主張であり、本記事で新たに実施した実装監査ではありません。
脅威モデルも、受信者や侵害された端末が読める内容を露出させ得ると認めています。したがって暗号化ストレージは、チャットメッセージの削除時に画像がすべての端末から消えるとは約束できません。
機密ファイルを共有する前に確認すること
その会話タイプが E2EE に対応するか、意図した受信者全員が信頼できるか、ファイル自体に個人を識別できるメタデータがあるかを確認してください。ギャラリーへの自動保存とクラウド写真バックアップは別々に確認します。文書では、コメント、変更履歴、埋め込みプロパティを送信前に削除すべきか検討します。
最後に、削除と復元を理解してください。サーバー上のデータ本体を除去すると今後のダウンロードを止められますが、受信者の既存コピーを回収できません。必要な鍵を失うと、暗号化ファイルが残っていても読めなくなる可能性があります。良い添付ファイル設計は、この両方を明確に説明します。
