短い答え
エンドツーエンド暗号化が正しく実装されているということは、メッセージのコンテンツが送信者のデバイス上で暗号化され、意図された受信エンドポイントによってのみ復号化できることを意味します。配信サービスは、平文や会話キーではなく、暗号文を処理する必要があります。ただし、E2EE はエンドポイント間のパスを保護します。エンドポイント、受信者、すべてのメタデータ、またはすべてのバックアップが信頼できるものになるわけではありません。
「エンドツーエンド」とは実際には何を意味するのか
エンドポイントは、会話を読み取るために必要なキーを保持するデバイスまたはアプリケーション インスタンスです。暗号化は、メッセージが送信者のエンドポイントを離れる前に行われます。復号化は、承認された受信エンドポイントに到達した後に行われます。
その境界線が重要なのです。 TLS などのトランスポート暗号化は、デバイスとサーバー間の接続を保護します。エンドツーエンド暗号化では、仲介者が平文キーを受け取らないようにすることを目的とした別個のメッセージ レベルの境界が追加されます。 IETF のメッセージング層セキュリティ標準では、メッセージを配信するサーバーではなく、通信するエンドポイントがメッセージにアクセスできるようにすることが目標だと説明されています。
製品ラベルだけでは証拠になりません。 ID 認証、キー管理、グループ メンバーシップの変更、古いキーの削除、実装の品質、バックアップの動作はすべて、実際のセキュリティの結果に影響を与えます。
E2EE が保護するように設計されているもの
正確な保証はプロトコルと実装によって異なりますが、最新の認証済み E2EE は次のリスクに対処することを目的としています。
ネットワーク傍受
Wi-Fi、ISP、または中間ネットワークを観察している人には、読み取り可能なメッセージの内容ではなく、暗号化されたトラフィックが表示されるはずです。
好奇心旺盛なサービスプロバイダー
会話キーを保持しない配信サービスは、通常のメッセージ暗号文を開くことができません。
配信サーバーの侵害
メッセージレベルの暗号化により、インフラストラクチャのルーティングまたは一時的にキューに入れられた暗号文が侵害された場合でも、コンテンツの機密性を維持できます。
検出されないメッセージの変更
認証された暗号化を使用すると、受信者は、正しいキー認証と実装を条件として、変更または偽造された暗号文を拒否できます。
過去のメッセージの一部暴露
Forward Secrecy を備えたプロトコルは、古い鍵マテリアルを削除または拡張するため、後の鍵侵害によって以前のすべてのメッセージが自動的に公開されることはありません。これは追加のプロトコル プロパティであり、E2EE の同義語ではありません。
E2EE が自動的に保護しないもの
セキュリティ上の誤解のほとんどは、メッセージの内容の保護が通信システム全体の保護として扱われるときに始まります。
侵害されたエンドポイントまたはロック解除されたエンドポイント
マルウェア、ロックされていない盗難デバイス、通知プレビュー、スクリーンショット、キーボード、およびユーザー補助サービスは、暗号化前または復号化後に平文に遭遇する可能性があります。
メッセージを受け取る人
許可された受信者は、合法的に読めるものをコピー、写真、引用、または転送できます。コントロールが消えると、保持される履歴が減少します。敵対的な受信者に忘れさせることはできません。
すべてのメタデータ
配信により、タイミング、トラフィック量、IP アドレス、宛先、デバイス トークン、またはグループ操作が公開される可能性があります。プロトコルとアーキテクチャにより、このメタデータの一部を最小限に抑えたりシールドしたりできますが、コンテンツ暗号化だけではメタデータを削除できません。
暗号化されていないバックアップとエクスポート
平文の履歴または回復可能なキーが別のシステムにコピーされた場合、そのコピーには独自のセキュリティ境界があります。 「チャットは E2EE です」ということは、すべてのバックアップがそうだということを証明するものではありません。
本当は誰が向こうにいるのか
間違ったキーまたは置き換えられたキーで暗号化すると、間違った相手との間で完全に暗号化された会話が作成される可能性があります。キーの検証と信頼できる ID バインディングは引き続き重要です。
可用性と強制
サービスは、暗号化されたトラフィックを遅延、ブロック、レート制限、または削除することができます。 E2EE は、ユーザーがエンドポイントのロックを解除したり、知っていることを開示したりすることを強制されることを防ぐこともできません。
脅威モデル: E2EE は役に立ちますか?
便利なセキュリティの質問は、アプリが単に「暗号化されている」かどうかを尋ねるのではなく、攻撃者の名前を指定します。
| シナリオ | E2EE はコンテンツを保護しますか? | 他に重要なことは何ですか |
|---|---|---|
| ネットワークオブザーバーがトラフィックを傍受する | 通常ははい | 強力なプロトコル、安全な実装、トラフィック分析の制限 |
| 配信サーバーが侵害されました | 通常ははい | キーは承認されたエンドポイント上に残しておく必要があります。メタデータは表示されたままになる可能性があります |
| ロックを解除したまま携帯電話を盗まれる | いいえ | デバイスのロック、ローカル ストレージ保護、通知ポリシー、短期保存 |
| 受信者が意図的にメッセージを録音する | いいえ | 信頼、ポリシー、透かし、限定的開示、法的管理 |
| 攻撃者が ID キーを置き換える | それ自体ではありません | キーの検証、透明性、認証、変更警告 |
| サービスがメッセージの配信を拒否する | いいえ | 可用性の設計、監視、代替通信計画 |
City of Hats がこの境界を処理する方法
City of Hats は、E2EE をより広範な脅威モデルの 1 つのレイヤーとして扱います。以下のステートメントは、公開されているアーキテクチャと製品の動作について説明しています。これらは、ソフトウェアがエンドポイントのリスクや受信者の行動を排除できるという主張ではありません。
メッセージレベルの暗号化
City of Hats は、Double Ratchet および AES-256-GCM とのハイブリッド X25519 および ML-KEM-768 キーの確立を使用して、Hat-to-Hat メッセージ、ファイル、および呼び出しのクライアント側 E2EE を文書化します。会話の復号化キーは、承認されたデバイス上に残ることを目的としています。
技術的な透明性 →登録 ID が少なくなる
Hat は、電話番号や電子メールがなくても作成できます。 Phrase IDs、複数の Hats、および使い捨て Hats により、すべての通信コンテキストを 1 つのキャリアまたはメールボックス ID に結び付ける必要性が軽減されます。侵害されたデバイスやネットワーク接続が匿名になることはありません。
Disposable Hats →中継された暗号化された通話
City of Hats は中継された音声とビデオを文書化するため、他の参加者は直接ピアツーピア IP アドレスを受信しません。リレーは暗号化されたメディアを処理しますが、ネットワークレベルのメタデータには依然として現実的な脅威モデルが必要です。
暗号化された通話 →会話回復パスがない
コンシューマ メッセンジャーは、プロバイダーが保持するメッセージ回復ボールトなしで設計されています。唯一の許可されたデバイスを失うと、メッセージ履歴が失われる可能性があります。これにより、サーバー側の回復要求に対する耐性が向上しますが、これは意図的な可用性のトレードオフです。
プライバシーとデータの取り扱い →納品後の管理
View Once、リコール、GeoLock、Certified Send、Channel Seal、およびその他のセキュリティ モードは、通常のアクセスまたは保持を制限する可能性があります。これらの制御により露出が軽減されます。 2 台目のカメラやすでに侵害されているエンドポイントを使用して、許可された受信者を破ることはできません。
セキュリティモード →書き込み可能な通信コンテキスト
Hats とチャネルは書き込むことも期限切れにすることもできるため、長期間有効な ID や無制限の会話履歴は必須ではありません。破壊すると、後で利用できるものが減少します。保護されたシステムの外部ですでに取得された情報を撤回することはできません。
Channel Seal →暗号化されたメッセンジャーを評価する方法
「エンドツーエンド暗号化」という言葉にとどまらないでください。プロバイダーまたはそのドキュメントに問い合わせてください。
- デフォルトで E2EE となる通信タイプ (メッセージ、グループ、ファイル、通話、ビジネス インタラクション) はどれですか?
- キーはどこで生成、保存、ローテーション、バックアップ、削除されるのでしょうか?
- ID キーはどのように検証されるのでしょうか?また、キーが変更されるとどうなりますか?
- サービスはどのようなコンテンツとメタデータを観察または保持できますか?
- 侵害されたデバイス、紛失したデバイス、または新たにリンクされたデバイスでは何が起こりますか?
- 受信者はコンテンツをエクスポート、転送、キャプチャ、または永久に保持できますか?
- プロトコル仕様、ソースコード、監査、または再現可能な技術的証拠は利用可能ですか?
- 前方機密性、侵害後のセキュリティ、メタデータ耐性、可用性など、E2EE から独立しているセキュリティ プロパティはどれですか?
結論
エンドツーエンドの暗号化は、メッセージの内容を信頼できるグループから配信サービスとネットワークを削除する可能性があるため、不可欠です。それはプライバシー システム全体ではありません。強力で安全な通信は、エンドポイント、ID、メタデータ、保持、回復、受信者の動作、トレードオフの正直な文書化にも依存します。
一次情報源と詳細な資料
この記事で使用されている標準およびファーストパーティの技術資料。 2026 年 8 月 9 日にアクセス。
- IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
- IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
- NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
- Signal. Sealed Sender: metadata and message delivery
- Signal. Disappearing messages and the hostile-recipient boundary
City of Hats の製品ステートメントは、当社独自の公開ドキュメントにリンクされており、独立して検証されるまではファーストパーティのクレームとして評価される必要があります。
← ナレッジセンターに戻る