暗号化はどの鍵でメッセージを開けるかを決めます。その鍵が誰に渡ったかは別に確認する必要があります。
いいえ。グループのエンドツーエンド暗号化だけでは、隠れたメンバーの参加を防げません。「サーバーはグループにメンバーを追加できるのか」という問いの答えは、メッセージの暗号化だけでなく、メンバー管理と確認の仕組みに左右されます。Livara の文書によると、実際に E2EE モードで動作する互換性のある非公開グループでは、LGS1 がコンテンツを暗号化します。メンバー変更後の鍵ローテーションは将来のアクセスを制限するためのもので、端末にメンバー情報と鍵の更新が適用される必要があります。すでに受け取ったコピーを取り戻すものではありません。
要点
- エンドツーエンド暗号化が目指すのはメッセージの機密性であり、メンバー一覧の安全には別の仕組みが必要です。
- E2EE 状態を確認した、互換性のある Livara の非公開グループでは、LGS1 はメッセージ、編集、添付ファイルの鍵を対象とします。互換性のない古いグループにこの説明を当てはめないでください。
- Signal、WhatsApp、SimpleX、Element を「暗号化済み」というラベルだけで比較するのは不十分です。メンバー変更通知、管理者の役割、本人確認方法も評価する必要があります。
- 正規に許可されたアカウントが攻撃者に操作されて参加しても、画面が常にそれを検出できるわけではありません。メンバーは本人性や重要な変更を独立した経路で確認すべきです。
- Livara Proof Lab は P-256、HKDF、AES-GCM のローカルデモとファイルのハッシュ確認を提供します。LVR1/LGS1 の完全な実装や独立監査ではありません。
グループ暗号化は隠れたメンバーを防ぐのか？
いいえ。コンテンツだけでなく、メンバー状態も暗号学的かつ検証可能な形で参加者間に同期するプロトコルでなければ、防げません。この記事でいう「隠れたメンバー」は、人間の参加者が加入に気づかなかったり、本人性を正しく認識しなかったりしたまま、将来のメッセージにアクセスするアカウントです。
エンドツーエンド暗号化とは、会話当事者の端末だけがメッセージ内容を読めるべきだという意味です。ただし、その端末は誰に鍵を送るのかを知る必要もあります。サーバーが受信者一覧を変更できるなら、暗号化が正しく機能しながら、望まないメンバー向けにもメッセージが暗号化される可能性があります。コンテンツとメタデータの違いは「エンドツーエンド暗号化とその限界」のガイドを参照してください。
したがって、「暗号化グループに対するサーバー攻撃」は必ずしも AES の解読や数学的問題の解決を意味しません。サーバーはメンバー管理を通じて、有効なアカウントを将来の受信者に加える可能性があります。そのアカウントが鍵を持たなかった過去のメッセージは別問題で、主な危険は加入後のアクセスです。
Livara のグループメンバー管理について何が分かるか？
Livara のセキュリティ文書 は、サーバーによるメンバー・役割の管理とコンテンツ暗号化を分けて説明しています。これは評価上重要な境界ですが、それだけで実際の攻撃の成功や完全に見えない加入が証明されるわけではありません。そのように主張するには、クライアントの動作、鍵配布、メンバー変更通知、攻撃条件を試験する必要があります。
問うべきなのは、端末が一覧の変更を独立に検証するか、新メンバーへ鍵を送る前に利用者に何を表示するかです。この記事は Livara の監査や侵入テストの結果を提示していません。
5 つのメッセンジャーでメンバー一覧の安全性はどう違うか？
主な違いは、誰がメンバー変更を許可するか、メンバーがどう知るか、新しいアカウントの本人性を独立に確認できるかです。エンドツーエンド暗号化があるだけでは、メッセンジャーのサーバーへの信頼を十分に説明できません。
| メッセンジャー | グループのコンテンツ | メンバー管理と実際の信頼 | 慎重な結論 |
|---|---|---|---|
| Livara | E2EE を利用する互換性のある非公開グループでは、LGS1 がテキスト、編集、添付ファイルの鍵を対象とします。 | メンバーが変わると送信者鍵は自動的に再生成・再配布されます。 | 製品文書によれば、互換性のある非公開グループのコンテンツとメディア鍵は配信前に保護されます。個々のグループの状態を確認してください。 |
| Signal | Signal のグループに関するサポート は、サービスがグループのメンバー、タイトル、画像、属性を記録しないと説明しています。 | 同じ資料によれば、管理者はメンバーを追加できる人を設定し、グループリンクに管理者承認を有効化できます。それでも参加者はメンバー変更を確認する必要があります。 | 設計はサービスが知る情報を制限しますが、利用者はメンバー変更とアカウントの本人性を確認すべきです。 |
| WhatsApp の暗号化概要 は、個人とグループのメッセージがエンドツーエンド暗号化されると説明しています。 | WhatsApp のヘルプ資料 は、新メンバーへの任意の一部履歴共有と、管理者がその共有を制限する権限を説明しています。 | グループ内容は暗号化されますが、メンバーの正当性は管理者設定とアプリの通知から評価する必要があります。 | |
| SimpleX | SimpleX のグループ文書 は、各メンバーが他のメンバーと個別の接続を持つと説明しています。 | プロトコル仕様は、役割やメンバー変更メッセージを持つ参加者間の接続の集合としてグループを説明します。人間の管理者が存在することと矛盾しません。 | グローバル識別子のないグループでも、メンバー管理や感染端末に関するすべての危険がなくなるわけではありません。 |
| Element / Matrix | Matrix のエンドツーエンド暗号化仕様 は、m.room.encryption イベントとルーム暗号化アルゴリズムを定義しています。 |
Matrix のメンバー仕様 は、ルーム状態の m.room.member イベントでメンバー状態を表現し、ホームサーバーが配布します。 |
ルーム暗号化とメンバー状態は別の層です。参加者は端末とルームの変更を確認すべきです。 |
この表は絶対的な順位ではありません。各システムの脅威モデルは異なり、アプリ、端末、グループ管理、参加者の行動で結果は変わります。実際の選択には「安全なメッセンジャーのチェックリスト：12 の質問」を各製品の公式文書と併用してください。
メッセンジャーのサーバーへの信頼をどう比較するか？
信頼を「はい・いいえ」に単純化せず、サーバーが具体的に何を見て何を変更できるかを問いましょう。文章を読めないサーバーでも、通信時刻、グループメンバー、初期鍵の配布を管理している場合があります。
第一に、コンテンツの機密性を分けて考える
メッセージ、編集、リアクション、タイトル、添付ファイルとその鍵が、正確にどこで暗号化されるかを確認します。Livara の文書によれば、LGS1 は E2EE を利用する互換性のある非公開グループのテキスト、編集、添付ファイルの鍵を対象とします。この説明はチャンネルには当てはまりません。
第二に、メンバー管理の権限を特定する
誰が招待でき、誰が申請を承認し、クライアントが変更をどう表示するかを明確にします。サーバーがグループ状態を強制するなら、サーバー侵害の脅威を脅威モデルに明記する必要があります。
第三に、本人性とメンバー資格を分ける
見慣れた名前があっても、鍵がその本人のものとは限りません。Livara の safety number はアプリ外で鍵の指紋を比較できますが、この機能だけでメンバー一覧全体を確認したことにはなりません。鍵透明性機能も、文書で裏付けられている場合にだけ製品の機能として扱ってください。
第四に、証拠と主張を分ける
製品文書、監査報告、独立試験は同じものではありません。信頼できる報告には、バージョン、調査範囲、発見事項、修正を明示する必要があります。アルゴリズム名や二つの実装の一致だけで、メンバー管理の安全性が証明されるわけではありません。
グループチャットのメンバーをどう確認するか？
参加者は一覧の変更を直ちに確認し、重要な相手の本人性を独立した経路で確認すべきです。高リスクの会話では、名前、写真、アカウント番号を見るだけでは足りません。誤った情報、再割り当てされた情報、攻撃者の管理下にある情報かもしれないためです。
Livara では二人が対面、既知の相手との通話、独立した経路で safety number を比較できます。予期しない鍵変更を見つけられることがありますが、二者間の比較だけで大きなグループ全員を一度に確認できるわけではありません。実際の手順は「safety number でチャットを確認する」ガイドで説明しています。
機密性の高いグループには、次の簡単な手順が役立ちます。
- 可能な限りメンバー追加権限を管理者に限定します。
- 加入、退出、役割変更の通知を、その都度すぐ確認します。
- 新メンバーの本人性を、そのグループの外で確認します。
- 不審な変更があれば機密情報の送信を止め、確認済みのメンバーで新しいグループを作ります。
- 各アカウントの端末とリンク済みセッションを定期的に確認します。
これらは危険を減らしますが、メンバー管理の設計上の欠陥を修復するものではありません。サーバーや管理者アカウントが侵害され、画面で変更が分かりにくければ、利用者はなお加入に気づかない可能性があります。
よくある質問
サーバーは暗号を破らずにグループへメンバーを追加できるか？
はい。メッセンジャーの設計がメンバー一覧の管理をサーバーに委ねている場合です。この場合、サーバーは暗号を破る必要がなく、将来の受信者にアカウントを追加して、クライアントにその相手向けにも暗号化させることができます。可能かどうか、どう行うかは各製品のメンバープロトコル次第です。
Livara のグループで LGS1 はどう動くか？
製品文書によれば、E2EE を利用する互換性のある非公開グループでは、LGS1 が送信者の鍵チェーンと署名を使って内容と添付ファイルの鍵を保護します。メンバー退出後の将来アクセスの制限は、メンバー変更の適用と新しい鍵の配布に依存します。Proof Lab は一部の暗号要素のローカルデモとハッシュ確認だけを提供します。LGS1 の完全な実装、プロトコル監査、メンバー管理の安全性の証明ではありません。
safety number の比較で隠れたメンバーの加入を証明できるか？
いいえ。safety number の比較は、二人の間で鍵の本人性を独立した経路から確認し、予期しない鍵変更を検出することがあります。しかし、他の誰もグループに入っていないとは証明しません。一覧、メンバー通知、重要なアカウントの本人性は別途確認する必要があります。
最も安全なメンバー一覧を持つメッセンジャーはどれか？
これらの資料から絶対的な勝者は決められません。Signal、WhatsApp、SimpleX、Element、Livara はメンバー管理と脅威モデルが異なるためです。適切な選択は自分の危険に左右されます。誰がメンバー資格を管理し、変更をどう通知し、サーバーの外で本人性を確認できるかを調べてください。
