通話の安全性を考えるときは、「暗号化されているか」だけでなく、暗号化がどこで終わるのか、録音・録画によって何が変わるのかを確認しましょう。
チャットが暗号化されているという事実だけでは、音声、映像、画面共有、通話の録音・録画も同じように保護されているとは証明できません。通話を評価するには、メディアがどこまで暗号化されたままなのか、誰が鍵を持つのか、録音・録画などの機能を有効にすると何が変わるのかを確認する必要があります。
このガイドでは、セキュリティに関する主張を検証可能な層に分けて考えます。プロトコルの名前や鍵マークは、これらの問いへの答えの代わりにはなりません。
1つのアプリにある3つの異なる経路
| 経路 | データの例 | セキュリティ上の問い |
|---|---|---|
| 保存されるメッセージ | テキスト、写真、ファイル、音声メッセージ | 端末、サーバー、バックアップにあるコピーを誰が読めるのか？ |
| ライブメディア | マイクの音声、映像、画面共有 | 暗号化が終わるのは相手の端末か、それとも中継サーバーか？ |
| シグナリング | 通話への招待、応答、接続を調整する情報 | 制御メッセージや接続先の身元情報を誰が変更できるのか？ |
チャットで送る音声メッセージはファイルですが、音声通話はライブストリームです。製品によっては、この2つに異なる鍵や仕組みを使っている場合があります。音質がよいことやテキストメッセージが届かないことだけで、もう一方の安全性が分かるわけでもありません。
DTLS-SRTP から何が分かる？
WebRTC では SRTP がメディアストリームを保護し、DTLS-SRTP はその鍵材料を確立する方法の1つです。RFC 5764 は DTLS-SRTP の仕組みを、RFC 3711 はメディアパケットの保護を説明しています。
しかし、「WebRTC を使用している」というだけでは、会議サーバーがメディアを復号するかどうかは分かりません。暗号化の終端と、その認証方法が明確である必要があります。利用者とサーバーの間の通信が暗号化されていても、処理や録音・録画のために、サーバーが復号後の内容へアクセスできる場合があります。これは参加者間の E2EE と同じではありません。
RFC 8827 の WebRTC セキュリティアーキテクチャ でも、メディアの保護に加え、ウェブアプリへの信頼、シグナリング経路、相手の身元が重要であることが示されています。パケットが暗号化されていても、製品のすべての構成要素を信頼できるという意味ではありません。
なぜシグナリングを別に評価する必要がある？
シグナリングは、誰が誰と通話するのか、接続をどのように確立するのかを調整します。アプリが制御メッセージを保護していても、その保護が参加者の実際の身元やメディアの鍵にどう結び付いているかを確認する必要があります。
文書を読む際には、次の3つを確認すればよいでしょう。
- 招待、応答、鍵情報は改ざんから保護されているか？
- 利用者は、その鍵が意図した相手のものだとどう判断できるか？
- 鍵や端末が変わったとき、どのような警告が表示されるか？
E2EE の通話でも、経路情報、時刻、通話の参加者はサービス側に把握される場合があります。メッセージングのメタデータ解説では、この違いを取り上げています。
通話の録音・録画は新たなセキュリティ境界
「暗号化された通話」という説明だけでは、録音・録画されたコピーについて十分に分かりません。参加者は自分の端末で音声や映像を記録できます。サーバー側の録音・録画についても、別途文書で説明する必要があります。サーバーは記録のために読み取り可能なメディアへアクセスするのか、誰がファイルを保持するのか、いつ削除されるのか、という点です。
録音・録画を有効にするとセキュリティモードが変わるなら、その変化が参加者に明確に伝わる必要があります。機密性の高い会話の前には、録音・録画の状態と各人の同意を確認しましょう。アプリ内の録音・録画表示がオフであっても、別の機器で誰も記録していないという保証にはなりません。
Livara の現在の文書をどう読む？
Livara のセキュリティページ では、直接通話とグループ通話を E2EE と説明していますが、任意で有効にするサーバー側の録音・録画は例外としています。REC が表示されるモードでは、通話の保護はトランスポート暗号化に切り替わります。これは製品文書の主張であり、この記事によるテストや独立監査の結果ではありません。
旧文書の、すべてのグループ通話を「Android の2〜6人」に限定する説明は、現在の文書と一致しないため、このガイドの前提にはしません。利用したい人数、プラットフォーム、バージョンについては、現在のガイドとアプリの実際の動作を確認する必要があります。この記事は収容人数のテストを提供するものではありません。
また、ML-KEM のようなチャット用アルゴリズムの名前だけでは、通話メディアにも同じアルゴリズムが使われているとは証明できません。通話が耐量子性を持つと主張するには、メディア経路と認証に特化した証拠が必要です。Livara の脅威モデル は機能ページと併せて読み、独立したテストの代わりにしないでください。
2つのサービスを比較する前の短いチェックリスト
「はい」と答える項目には、バージョン名と情報源も記録しましょう。
- 2人通話、グループ通話、画面共有がそれぞれ別に説明されているか？
- サーバーがパケットを転送するだけなのか、メディアを復号できるのかが明確か？
- 参加者の身元と鍵を確認できるか？
- 端末の変更、メンバーの追加、録音・録画の開始が明確に分かるか？
- ウェブとアプリで通話の経路は同じか、違いがあるか？
- 録音・録画ファイルとメタデータの保持について説明されているか？
- テストや監査の証拠は、同じバージョンと機能を対象にしているか？
文書に答えがなければ「不明」と記載してください。答えがないことは、安全性の証明でも盗聴の証明でもありません。
よくある質問
E2EE の通話は相手による録音・録画を防げる？
いいえ。正当な受信者は読み取り可能な内容へアクセスでき、ソフトウェアや別の機器で記録する可能性があります。
トランスポート暗号化はよくないもの？
トランスポート暗号化は、通信経路上の盗聴に対する重要な保護を提供します。違いは、終端となるサービスが復号後の内容へアクセスできることです。これを利用者間の E2EE と呼ぶべきではありません。
チャットで耐量子暗号を使っていれば、通話も耐量子性を持つ？
いいえ。主張は、同じ層、アルゴリズム、実装バージョンに関するものでなければなりません。チャットと通話は別々に評価してください。
