ディスクのコピー、サーバーのリアルタイム制御、スマートフォンへのアクセスは別々の状況です。一つの包括的な保証では三つを説明できません。
メッセージアプリのサーバーが掌握されたとき、「何が漏れるのか」という問いへの正確な答えは、保存されたデータ、鍵の所在、攻撃者のアクセスの種類によって変わります。ディスクのコピーを入手することと、稼働中のサービスやアプリの配布経路を制御することは同じではありません。
この記事は Livara の公開文書を基に、仮定のシナリオを検討します。Livara のデータセンターの所在地、実際の押収の有無、インターネット遮断時のサービス稼働の保証について主張するものではありません。コンテンツの暗号化、ネットワークの可用性、インフラの安全性は別の問題です。
まずアクセスの種類を明確にする
**サーバーの保存済みコピー：**攻撃者は、そのコピーに含まれるファイル、データベース、バックアップへアクセスします。非公開コンテンツが端末で正しく暗号化され、復号鍵をサーバーが保有していなければ、そのコピーを持つだけでは会話の平文は明らかになりません。
**サービスの能動的な制御：**攻撃者は既存のデータを読むだけでなく、一部のリクエストを止めたり、古いデータを返したり、制御下の部分の挙動を変えたりできます。この状況では、相手の本人性、バージョン管理、クライアントの完全性の確認がより重要になります。
**端末への同時アクセス：**ロック解除されたスマートフォン、マルウェア、または会話参加者が持つ読めるコピーから、まったく別の経路で内容が漏れる可能性があります。Livara の脅威モデルも、ロック解除済みまたは感染した端末の保護は保証していません。
Livara の文書ではサーバーに何が見えるのか
バージョン 0.1.68 と表示されたLivara のセキュリティページは、LVR1 の直接チャットと互換性のある LGS1 非公開グループの内容を、運用情報と区別しています。同じページは、互換性のない古いグループが明示的に E2EE の対象外にとどまると述べています。そのため、対象の会話そのものの状態を調べる必要があります。
| データの種類 | 文書に記された境界と想定される影響 |
|---|---|
| 保護された会話の本文と添付ファイル | サーバーは暗号化されたコピーを保存し、読むには適切な鍵が必要 |
| 通信メタデータ | 相手、時刻、サイズ、配信状況などの情報をサービスが取得可能 |
| グループのメンバー情報 | サーバーの運用情報と操作権限の一部 |
| 公開チャンネル | 内容は公開されており、サーバーが読める |
| v7 本人性復元パッケージ | アップロード前に暗号化され、別の復元用秘密情報が必要 |
| 任意のサーバー側録画・録音モード | REC 表示で E2EE モードと区別され、エンドツーエンドのプライバシーを前提にできない |
文書にはメタデータ保護用の LSS1 コードが記載されていますが、通常のメッセージ送信には接続されていません。プロジェクトにプロトコル名が存在しても、すべての通信で有効という証拠にはなりません。
この表は製品の主張を説明したものであり、実際の押収実験の結果でも、データベースの全コピーに対する独立監査の結果でもありません。
メタデータはどれほど重要か
人々のつながり、時刻、グループ所属に関する情報は、メッセージ本文がなくても機微なものになり得ます。しかし、保存期間、ログの対象範囲、入手されたデータのコピーを知らずに「通信関係の全体が永久に漏れる」と述べるのは正確ではありません。
実際の評価では、どのフィールドが収集され、どれだけ保存され、どのバックアップにアクセスできるかを問う必要があります。コンテンツの暗号化だけでデータ保持方針が決まるわけではありません。また、一つのメッセージアプリの構造から、すべてのアプリが必ず同じメタデータを保持すると結論づけることもできません。
サーバーの制御は今後のメッセージにどんな危険をもたらすか
セキュリティ評価では、メンバー一覧の改ざん、異なる本人性鍵の提示、更新の妨害、悪意あるクライアントの配布を個別に検証する必要があります。それぞれの影響は、クライアント側の検証、変更の表示、本人性の確認に左右されます。
実装を試験せずに、掌握されたサーバーなら必ず隠れたメンバーを追加できるとは言えません。同様に、サーバーの能動的制御に影響がないとも言えません。機微な会話では、予期しない本人性やメンバーの変更を調べるべきです。独立した信頼できる経路で相手と鍵のフィンガープリントを比較すれば、表示名だけを信頼するより多くの情報が得られます。
攻撃者が端末上で動くコードを変更すれば、暗号化前の平文を見る可能性があります。したがって、アプリの配布と更新の安全性は、このシナリオの一部であり、暗号の問題の外にあるものではありません。
ポスト量子対応は何を加えるのか
ML-KEM のNIST FIPS 203 標準は、共有秘密の確立に役立ちます。ハイブリッド構成で正しく使えば、将来の鍵交換に対する一部の攻撃のリスクを減らせます。ただし、端末の安全性、メタデータの保存制限、サーバーのアクセス制御の代わりにはなりません。
Proof Labも、一部のローカルな P-256、HKDF、AES-GCM 処理だけを示し、LVR1/LGS1 の完全な組み合わせは実験の対象外としています。成功という結果は、製品全体がインフラの掌握に耐えるという保証ではありません。
評価や実際の事案ではどうするべきか
- アクセスの種類と確認済みの情報を記録し、障害のうわさを確定したセキュリティ事案と同一視しないでください。
- アプリのバージョンと、対象の会話そのものの暗号化状態を確認してください。
- 本人性、グループメンバー、不明なセッションの変化を公式の経路で確認してください。
- 「安全性の確認」のためと称する見知らぬ人に、復元用秘密情報、パスワード、非公開コンテンツを渡さないでください。
- 深刻な危険や法律上の問題では適切な専門家に相談し、一つの記事だけを根拠に取り返しのつかない行動をしないでください。
信頼できる結論は、どのデータが、どのバージョンで、どのアクセスに対して保護されるのかを明示する必要があります。「サーバーが押収されても何も起きない」という言葉で、その答えを代用することはできません。
