エンドツーエンド暗号化は対応する内容を端末間で保護しますが、端末や利用者の誤りや弱点までなくすものではありません。
エンドツーエンド暗号化（E2EE）は、配送サービスではなく参加端末が読み取る手段を持つようにして、対応するメッセージ内容を保護します。誰が通信しているかを自動的に隠したり、感染したスマートフォンを安全にしたり、受信者によるコピーを止めたりするものではありません。
このガイドでは、メッセージが送信者から受信者に届くまでをたどり、E2EEとHTTPSを比較しながら、メッセンジャーの暗号化に関する主張を確かめる実践的な確認項目を説明します。
エンドツーエンド暗号化とは？
エンドツーエンド暗号化は、情報を送信者の端末で暗号化し、参加する受信者の端末だけで復号する保護方式です。
適切に設計されたE2EEの会話では、メッセージは読める平文のまま送信端末を離れません。暗号文、つまり正しい暗号鍵なしでは利用できないよう変換された情報として送られます。
メッセージサービスは、保護対象の内容を読める形で得ることなく、暗号化データの配送と同期を支援できます。プロトコルによっては、同じ原理を一対一の通信にもグループ通信にも適用できます。
ここでいう「端」は参加端末であり、必ずしも二台のスマートフォンだけではありません。グループや、本人がリンクしたノートパソコンにより、許可された端末が増えることがあります。
これが、エンドツーエンド暗号化と通常の通信経路の暗号化の中心的な違いです。
E2EEはどのように機能するか
数学は複雑でも、メッセージがたどる基本的な流れは理解できます。
1. 各参加者が暗号鍵を持つ
安全なメッセージクライアントは、ユーザーの端末上で暗号鍵の情報を作成または保存します。
一部の鍵は公開して共有できます。秘密鍵は、メッセージの復号に必要な秘密情報を端末が確立または復元するために使うので、保護しなければなりません。
2. 端末同士がメッセージ用の共通秘密情報を確立する
参加者は、一致する秘密情報を導出するために必要な公開情報を交換します。
秘密そのものを読めるデータとして送る必要はないはずです。各端末が必要な暗号処理を独立して行います。
3. メッセージをローカルで暗号化する
送信者が送信を押すと、アプリは送信端末上でメッセージを暗号化します。
読める文章は、アップロードや中継の前に暗号文になります。
4. サーバーが暗号文を届ける
メッセージ基盤は暗号化メッセージを受信者へ配送し、同期、配信、複数の許可された端末への対応のため、暗号文を保持する場合があります。
サーバーは引き続き重要な運用処理を担います。E2EEが変えるのは、サーバーが扱うメッセージ内容の形です。
5. 受信者が復号する
許可された受信端末は、自身の暗号情報を用いて暗号文を認証し、復号します。
読めるメッセージは許可された端末に表示されます。その後、ローカル履歴、通知、バックアップ、エクスポートには、それぞれ独自の保護が必要です。
エンドツーエンド暗号化は何を守るか
E2EEは主に、会話の内容を守るために設計されています。
アプリと実装によっては、次の内容が含まれます。
- 個別のテキストメッセージ
- 写真と動画
- 音声メッセージ
- 文書と添付ファイル
- 音声通話やビデオ通話
- メッセージの編集と返信
これらがクライアントで正しく暗号化されていれば、ネットワーク通信を傍受する攻撃者が見るのは、元のメッセージではなく暗号化データであるはずです。
サービス基盤で利用可能な、読める会話内容も減らせます。
ただし、「暗号化」を魔法の言葉として扱ってはいけません。どの会話の種類と内容の処理経路が対象なのか、ユーザーには正確に知る権利があります。
E2EEが自動的には守らないもの
エンドツーエンド暗号化は強力ですが、その境界はしばしば誤解されます。
メッセージのメタデータ
システムは、メッセージの配送と同期のために運用情報を必要とする場合があります。
サービスによっては、次の情報が含まれます。
- どのアカウントがメッセージを送ったか
- どの会話が受け取ったか
- いつ送信されたか
- 配信と既読の状態
- 会話のメンバー情報
- 暗号化メッセージのサイズ
- 端末やセッションの情報
メッセージ本文を読めなくても、その周辺の一部情報はシステムが利用できる場合があります。
そのため、「メッセージ内容が暗号化される」と「サービスがメタデータを収集しない」は別の主張です。
侵害された端末
エンドツーエンド暗号化は、マルウェアや、端末に十分なアクセス権を持つ攻撃者から平文を守るものではありません。そのアクセスに、画面のロック解除が必須とは限りません。画面がロックされているというだけでは、侵害されたOSがメッセージデータにアクセスできない証明にはなりません。
メッセージは最終的に、許可された端末で読める状態になる必要があります。アプリが復号したデータ、メモリー、画面にアクセスできる攻撃者は、内容を取得できる場合があります。具体的な露出は端末、ソフトウェア、侵害の状況によって異なります。
端末の安全対策は引き続き不可欠です。
- OSの更新をインストールする
- 強い端末パスコードを使う
- ブラウザー拡張機能を確認する
- アカウント復旧情報を守る
- 不明なアプリやダウンロードを避ける
受信者の行動
復号後に参加者がメッセージをコピー、転送、撮影、スクリーンショット保存することを、E2EEは防げません。
暗号化は端末間の配送を保護します。相手側の端末を使う人を制御するものではありません。
アカウント復旧の問題
復旧システムは、安全性と使いやすさのバランスを取る必要があります。
弱い復旧手順は、強い暗号化を損なう可能性があります。一方、復旧を一切認めないシステムでは、鍵を失ったときに暗号化された履歴へ永久にアクセスできなくなる場合があります。
信頼できるアプリは、復旧の仕組み、何をバックアップするか、復旧用の認証情報を失うとどうなるかを説明するべきです。
E2EEとTLSは同じものではない
現代のウェブサイトの多くは、HTTPSとTLSでブラウザーとサーバー間の通信を保護しています。
これは重要です。同じネットワーク上や通信経路の途中にいる人が、接続を簡単に読み取ったり改変したりすることを防ぎます。
TLSはその両端間の接続を保護します。通常のウェブメッセージでは、その片端はサービスです。別の内容暗号化層で保護されていなければ、サービスはアプリのデータを読めます。TLS仕様は、その接続における盗聴、改ざん、偽造への保護を説明しています。
標準的な、サーバーが読めるメッセージ方式では、次のように動作します。
- 端末がネットワーク接続を暗号化する。
- サーバーが読めるメッセージ内容を受け取り、処理する。
- サーバーが受信者に向けて別の保護された接続を開く。
エンドツーエンド暗号化では、メッセージ自体が参加者向けに暗号化されてから、保護されたネットワーク接続の中に入ります。
簡単に比較すると、次のようになります。
| 保護 | TLSだけのメッセージ通信 | エンドツーエンド暗号化 |
|---|---|---|
| ネットワーク転送中のデータを保護する | はい | はい |
| ネットワークを通る前に保護される | はい。そのTLS接続に対して | はい。意図したメッセージ端末に対して |
| 配送サービスが保護された本文を読める | 内容を別途暗号化しなければ通常は読める | 想定された鍵設計では暗号文だけからは読めない |
| 端末の安全性が依然として必要 | はい | はい |
| メタデータが自動的に隠れる | いいえ | いいえ |
TLSとE2EEは競合するものではありません。プライベートなメッセージシステムには、一般に安全な通信経路と正しく実装された内容暗号化の両方が必要です。
この定義をLivaraに当てはめる
セキュリティ文書によると、Livaraは個別通信にP-256とML-KEM-768を組み合わせたLVR1のハイブリッド鍵合意を使います。互換性のある非公開グループは、一対一のセッションを通して配布されるLGS1の送信者鍵を使います。公開チャンネルはサーバーが読めるため、E2EEと説明すべきではありません。
この区別はブランド名ではなく、実際の通信機能に関するものです。文書は通話の暗号化も別に説明しており、異なる信頼境界を持つ、状態が見える録音モードも含まれます。すべての機能が同じ保護を持つと思い込まず、現在の会話と通話の状態を確認してください。
これらは製品文書による主張であり、この記事のために実施した独立監査ではありません。運用メタデータと侵害された端末は、引き続き重要な制約です。耐量子鍵合意が対処するのは暗号学上の一定のリスクであり、フィッシング、安全でないバックアップ、ロック解除済みの画面を無害にするものではありません。
公開鍵フィンガープリントが重要な理由
暗号化された会話は、システムが示す任意の鍵ではなく、意図した鍵と通信することに依存します。
公開鍵フィンガープリントは、参加者の公開鍵を短く表したものです。二人は、対面の会話や相手を確認済みの通話など、別の信頼できる経路でフィンガープリントを比較できます。
一致していれば、想定した鍵が使われているという確信を高められます。
フィンガープリントが変わっても、それだけで攻撃の証明にはなりません。正当な鍵のリセットや端末復旧でも変わる場合があります。ただし、その変化は黙って無視されるのではなく、見えるようにされ、説明可能であるべきです。
バックアップと復旧は通常の通信の暗号化とは別
アプリが通常のメッセージをエンドツーエンド暗号化していても、別のバックアップには異なる鍵やアクセス規則が使われる場合があります。平文のエクスポートも、読める内容を暗号化された会話の外へ移してしまいます。何をバックアップするか、誰が復号できるか、復旧用情報を失うとどうなるかを尋ねましょう。
Livaraの文書にある復旧バックアップは、アップロード前に暗号化して封じられ、本人性情報を復元します。チャット履歴ではありません。アカウントや本人性の復旧で、過去のすべての会話も戻ると推測しないでください。より広い判断のためには、暗号化チャットを安全にバックアップする方法をご覧ください。
プライベートなメッセージアプリを評価する方法
「暗号化」「安全」という言葉だけでメッセージサービスを判断しないでください。
具体的な質問をしましょう。
どの会話がE2EEか
個別チャット、グループ、チャンネル、通話、添付ファイルに保護が適用されるか確認してください。
鍵はどこで生成・保存されるか
クライアントで鍵を作るか、バックアップをどう保護するかについて、明確な説明を探しましょう。
サーバーは何を保持するか
責任あるサービスは、メッセージ内容と、配送経路、タイムスタンプ、メンバー情報、配信情報、その他の運用データを区別するべきです。
鍵が変わるとどうなるか
予期しない鍵の置き換えは見えるべきです。無通知の鍵変更は、ユーザーが連絡先を検証する能力を弱めます。
復旧はどう機能するか
事業者が鍵を復元できるか、復旧用秘密情報が必要か、それを失うとどうなるかを確認しましょう。
主張は独立して検証されているか
セキュリティ文書、公開プロトコル、専門家のレビュー、独立監査は、それぞれ異なる水準の裏づけを提供します。
宣伝文句だけでは監査になりません。
プライバシーには明確な境界が必要
最も強いプライバシーの説明は、「信じてください」ではありません。
次の点についての、正確で検証できる説明です。
- 何を暗号化するか
- どこで暗号化するか
- どの鍵が関わるか
- サーバーが何を受け取るか
- どのメタデータが残るか
- 対象外の会話はどれか
- 復旧が脅威モデルをどう変えるか
エンドツーエンド暗号化は、プライバシーのすべてではありません。しかし、慎重に実装され、誠実に説明されれば、私的な通信の重要な基盤になります。
実践的な次の一歩として、安全なメッセージサービスの12問チェックリストを使い、実際に利用する個別チャット、グループ、添付ファイル、通話、バックアップを確認しましょう。
よくある質問
E2EEは何の略ですか。
E2EEはエンドツーエンド暗号化の略です。保護対象の内容を一人の参加者の端末で暗号化し、別の許可された端末で復号することを意味します。
インターネット接続事業者はE2EEのメッセージを読めますか。
接続事業者は、接続が存在することや一部のネットワークレベルの情報を観察できる場合があります。しかし、正しく暗号化されたメッセージ内容が、通信中に読める平文として現れることはないはずです。
エンドツーエンド暗号化はメタデータも隠しますか。
自動的には隠しません。メッセージシステムは、サービス運営に必要な配送経路、メンバー情報、タイムスタンプ、配信状態、暗号文のサイズ、その他の情報を処理する場合があります。
盗まれたロック解除済みスマートフォンをE2EEで守れますか。
すでに許可され、ロック解除済みの端末を攻撃者が制御している場合、どの暗号化プロトコルでもメッセージを完全には守れません。強い端末保護は依然として必要です。
Livaraの会話はすべてエンドツーエンド暗号化されていますか。
Livaraは現在、一対一の個別メッセージの本文とメディア、および互換性のある非公開グループにE2EEを提供すると文書化しています。これらのグループはLGS1でエンドツーエンド暗号化され、メンバー変更時には送信者鍵が自動更新されます。チャンネルはTLSと認証付きのサーバー側権限制御を使い、エンドツーエンド暗号化とは主張されていません。
紛失したLivaraの暗号鍵は復旧できますか。
公開文書は、必要な復旧用秘密情報を使って、バックアップ済みの本人性情報を復元する方式を説明しています。これはチャット履歴を復元するものではありません。元の端末を削除・交換する前に、現在の復旧手順を読んでください。
E2EEと前方秘匿性は同じですか。
いいえ。E2EEは、保護された内容を誰が読めるべきかを表します。前方秘匿性は、後に鍵が侵害されたときに過去のメッセージがどう影響を受けるかに関する性質です。侵害後セキュリティは、定められた条件の下で侵害後に保護を回復することに関する性質です。これらはプロトコルと実装に依存します。例えばMLS仕様は、グループ鍵の設計について両方を明示的に定義しています。しかし、すべての暗号化メッセンジャーが自動的に両方を提供したり、MLSを使ったりするという意味ではありません。
