有用なセキュリティの問いは、暗号化が強そうに聞こえるかではなく、何を守り、誰が鍵を持ち、何がその主張を裏付けるかです。
「軍用レベルの暗号化」という情報だけでは、メッセージングアプリを評価できません。この表現からは、誰が鍵を持つのか、どの会話が保護されるのか、バックアップから平文が露出するのか、端末が侵害されたら何が起きるのかは分かりません。
取るべき対応は、暗号化を否定することではありません。印象的なラベルを、確認可能な具体的な主張に置き換えることです。
AES-256 はアルゴリズムの選択であり、完全なセキュリティモデルではない
AES は公開標準であり、秘密の軍事技術ではありません。NIST の FIPS 197 は AES-128、AES-192、AES-256 を規定しています。末尾の数字は鍵長です。この標準は 2023 年に編集上の更新が行われましたが、アルゴリズムは変わっていません。
強力な暗号でも、サービス側が平文にアクセスできるシステムで使われることがあります。鍵が何ビットかだけでなく、誰が復号できるかを尋ねてください。鍵の生成・保存方法、本人性の認証方法、そしてどのような障害条件でアプリが安全でないまま処理を続けずに停止するのかも確認しましょう。
ベンダーが AES-GCM と明示するなら、単に AES と言うより具体的です。GCM は暗号化と認証を組み合わせます。それでも、nonce の正しい扱い、認証タグの検証、その他の実装要件は重要です。技術的な参照先は NIST の GCM 仕様であり、ロゴはアプリが正しく実装している証拠にはなりません。
宣伝でひとまとめにされがちな四つの異なる主張
| 主張 | 対処すること | 証明しないこと |
|---|---|---|
| 通信経路の暗号化 | アプリからサーバーなど、接続上の保護 | サーバーが内容を読めないこと |
| 保存データの暗号化 | 特定の鍵・アクセスモデルの下での保存データの保護 | 運営者が復号鍵を持たないこと |
| エンドツーエンド暗号化 | 指定されたエンドポイント間の内容の保護 | 侵害された端末の安全性や、受信者の誠実さ |
| 耐量子鍵確立 | 鍵の確立における特定の量子脅威への耐性 | アプリ全体の監査、匿名性、将来の安全性の保証 |
通信経路の暗号化は、すべての事業者のデータベースが生の平文を保存していることを意味するものではありません。サービスが保存データも暗号化している場合はあります。重要なのは、事業者が鍵を管理しているか、あるいは別の方法で読める内容にアクセスできるかです。あるスローガンを別のスローガンに置き換えるのではなく、正確に区別しましょう。
より広い入門として、エンドツーエンド暗号化が保護する範囲についての記事も参照してください。
「NIST 標準を使用」は「FIPS 検証済み」ではない
FIPS 203 は、鍵カプセル化メカニズムである ML-KEM を定義しています。メッセンジャーは、そのアルゴリズムを使用すると説明していても、アプリ全体が認証や独立したレビューを受けているとは限りません。標準、アルゴリズムの試験、暗号モジュールの検証、製品のセキュリティ監査は、それぞれ異なる証拠です。
NIST の暗号モジュール検証プログラムは、承認された機能を実装するだけでは FIPS 140 モジュール検証を受けたことにはならないと明示しています。製品が検証済みと宣伝するなら、証明書、正確なモジュールとバージョン、動作環境、承認された構成を求めてください。その上で、証明書が製品のどの部分を実際に対象としているかを確認します。
このため「256 ビットの安全性」を、メッセンジャー全体の一括評価として使うべきではありません。プロトコルの組み合わせ、鍵管理、実装によって、それぞれ異なる制約が生じる可能性があります。
パスワード認証はメッセージの暗号化ではない
ログインの仕組みが答えるのは、ユーザーがアカウントにアクセスできるかです。E2EE が答えるのは、保護されたメッセージ内容を誰が読めるかです。どちらも、もう一方の性質を自動的に提供するわけではありません。
例えば SRP は、パスワードそのものを送信せずに認証するよう設計されています。しかし、認証データベースが盗まれても無害という意味ではありません。RFC 5054 の SRP に関するセキュリティの説明では、検証子が盗まれるとパスワード推測攻撃などのリスクが生じると説明されています。「盗まれるパスワードがないのだから、サーバー侵害は問題にならない」と結論付けないでください。
読者が実際に続けて尋ねるべきなのは、アカウント復旧、アクティブなセッション、アカウントへのアクセスと暗号鍵の関係です。「ゼロ知識」と繰り返すだけでは、重要な問いは解決しません。
メッセンジャーのセキュリティページを確かめる五つの質問
- どの機能が対象か。 個別チャット、グループ、ファイル、通話、公開投稿、バックアップでは、保護の境界が異なる場合があります。
- 使用可能な鍵を誰が持つか。 復旧鍵、リンクされた端末、サーバー側での処理モードも含めて考えます。
- 相手のエンドポイントをどう認証するか。 鍵の検証、意味のある変更警告、文書化された信頼モデルを確認します。
- どんな証拠があるか。 仕様、再現可能なビルド、テストベクトル、独立監査は異なる問いに答えます。それぞれのバージョンと範囲を尋ねてください。
- 何が依然として見え、あるいは脆弱なのか。 メタデータ、侵害された端末、コピーされたメッセージ、公開内容を説明から消してはいけません。
同じ基準を Livara にも適用してください。セキュリティ文書は LVR1 と LGS1 を挙げ、運用上の境界を公開しています。これらは評価すべき製品の主張であり、独立した認証ではありません。Proof Labが提供するのは限定的な実演と成果物のチェックであり、すべての機能やリリースが安全であることの証明ではありません。
独立監査の読み方
日付、監査担当者、コードのリビジョン、対象プラットフォーム、除外された構成要素を確認します。概要のバッジだけでなく、指摘事項と修正状況を読んでください。暗号ライブラリの監査が、アカウント復旧、ウェブアプリ、通知、運用上の安全性を自動的に対象とするわけではありません。
監査がないことは安全性への裏付けの不足であり、特定の脆弱性の証拠ではありません。逆に、監査も永久保証ではありません。有用な比較は証拠とその限界を記録するもので、普遍的な「最も安全な」勝者を宣言するものではありません。
よくある質問
「軍用レベル」は常に AES-256 の別名なのか
いいえ。この表現から特定のアルゴリズムや認証を推測しないでください。ベンダーに正確な意味を明示するよう求めましょう。
より強い暗号化でスクリーンショットやマルウェアを防げるか
受信者による内容のコピーや、侵害された端末によるアクセス可能なデータの流出は防げません。これらは別の脅威です。
セキュリティのスローガンより有用な指標は何か
明確な対象範囲、名前が示されたプロトコル、明示的な限界、そして出荷された実装に対する検討可能な証拠です。その説明は、何を信頼し、何をなお確認すべきかを判断する助けになるべきです。
