メッセンジャーのサーバーが侵害されても、必ずしもすべてのメッセージが読まれるわけではありません。結果は、保存されているデータ、鍵の所在、攻撃者のアクセス権限によって異なります。チャット本文が正しくエンドツーエンド暗号化されていても、アカウント情報、時刻、グループへの所属、配信経路は機微な情報になり得ます。
インシデントを評価する際は、まず攻撃者が何を手にしたのかを確認してください。データベースのコピー、インフラの鍵、稼働中のサーバー、それともソフトウェア配信システムでしょうか。それぞれ影響は異なります。
データベースの盗難とサーバーの掌握は異なる
古いデータベースのコピーだけを持つ攻撃者は、その時点で記録されていたデータに限られます。稼働中のサービスを掌握すれば、新しいデータの記録、セッションの窃取、応答の改変、相手の鍵の差し替えの試行が可能になる場合があります。ソフトウェアの配信経路への侵入には別の危険があります。エンドポイント上の悪意あるコードは、暗号化前や復号後の本文を見られる可能性があります。
したがって、「データベースにメッセージ本文の鍵がない」という説明は重要ですが、あらゆる侵害への完全な答えではありません。
5つのアーキテクチャパターンを比較する
これは説明用のパターンであり、5製品のランキングではありません。一つのサービスが、機能ごとに複数のパターンを採用していることもあります。
| パターン | データベースから取得できるデータ | 重要な境界 |
|---|---|---|
| 平文のメッセージとパスワード | 内容と認証情報を直接読める | 両方のデータに適切な保護がない |
| ハッシュ化したパスワードと平文のメッセージ | 内容は読める。パスワードの推測を検証できる場合がある | パスワード保存方法の品質はチャット本文を保護しない |
| サーバーの鍵で暗号化した内容 | 暗号文。読めるかは鍵へのアクセスに依存 | 鍵とデータの実質的な分離が重要 |
| E2EE チャットと提供者がアクセスできるバックアップ | 現在のチャットは保護されても、履歴のコピーには別の漏えい経路がある | バックアップの方針と鍵を確認する必要がある |
| E2EE チャットと、独立した鍵による暗号化された復旧 | 暗号文と運用データ。内容の保護は設計と鍵の保護に依存 | デバイス、リカバリーフレーズ、相手の認証が引き続き重要 |
サーバーのディスク暗号化は、ディスクそのものの盗難に役立ちます。稼働中のサービスや復号鍵まで攻撃者が手にした場合に、同じ保護があると想定してはいけません。E2EE の目的は、中継サービスが保護された内容を読むための鍵を持たないことです。
メタデータから何が分かるのか？
メタデータは、どのアカウント同士が通信したか、いつ活動していたか、どのグループに属しているか、どれだけのデータが移動したかを示す場合があります。メッセージ本文ではありませんが、つながりや活動パターンを知るうえで価値があります。
Livara のセキュリティページは、ルーティング、メンバー情報、時刻、暗号文のサイズ、配信状態など、運用データの保存と処理を明記しています。プライベートな内容の機密性を、完全な匿名性や、サーバー上に一切データがないことと解釈してはいけません。
SRP でもアカウントデータの推測攻撃リスクはなくならない
SRP は、パスワード自体を直接送らずに、それを知っていると証明する方法です。サーバーには引き続き verifier という検証用データが保存されます。RFC 5054 のセキュリティ節は、verifier が盗まれると、パスワードを推測する辞書攻撃が可能になる場合があると説明しています。
つまり、「パスワードをネットワーク上に送らない」ことと、「盗まれるパスワード関連データが存在しない」ことは別です。使い回さない強いパスワード、デバイスの保護、適切なインシデント対応は依然必要です。SRP は内容の暗号化やログインセッションの保護の代わりにもなりません。
Livara ではどのような境界が公表されているか？
Livara のセキュリティ文書は、ダイレクトメッセージに LVR1、保護されたグループに LGS1 を説明しています。グループの保護は実際の状態に依存し、互換性のない旧グループに E2EE の表示を付けるべきではありません。公開チャンネルはこの機密性の境界の外にあります。
同じ文書は、v7 復旧を、アップロード前に保護される暗号化された ID パッケージと説明しています。この処理が復元するのは暗号学的な ID であり、チャット履歴ではありません。リカバリーフレーズの漏えいや鍵を持つデバイスの侵害は、データベースだけの盗難とは別のシナリオです。
これらは製品が公表している説明であり、この記事による独立監査の結果ではありません。AES や ML-KEM という名前だけでも、鍵管理やアプリの実装が正しいと証明することはできません。
インシデントの発表時に何を尋ねるべきか？
- どの期間とシステムが影響を受けたのか。「利用者情報」という曖昧な表現では不十分です。
- 平文、ファイル、鍵、verifier、ログインセッションがアクセス可能だったのか、それとも暗号文だけだったのか。
- 攻撃者はサービスや利用者に配信するソフトウェアを変更できたのか。
- セッションのログアウト、パスワード変更、更新、相手の ID 確認など、公式経路でどの対応が必要なのか。
- 推奨される復旧手順でローカル履歴が失われる可能性はないか。アプリを削除する前に制限を読んでください。
知らない相手からのメッセージにある「緊急のアカウント確認」リンクは使わないでください。公式アドレスを自分で開いて発表を確認しましょう。Livara の脅威モデルは一般的な境界の理解に役立ちますが、実際のインシデントの範囲は、その事件の証拠に基づいて特定する必要があります。
