ブラウザーは強力な暗号を実行できますが、配信されるコードも信頼に値する必要があります。
ブラウザーは、ネイティブのメッセージアプリをインストールせずに、耐量子鍵確立を含むエンドツーエンド暗号化をローカルで実行できます。難しいのは、その数学的処理をタブ内で実行できるかどうかではありません。配信されるアプリ、鍵の取り扱い、更新経路に、その会話に必要な信頼を置けるかどうかです。
インストールできない場合、ウェブ経由のアクセスは便利です。しかし、それによって検閲、侵害されたホスティング、悪意のある拡張機能、侵害された端末の影響を受けなくなるわけではありません。
ブラウザーの暗号学的な構成要素
WebCrypto は、暗号化、鍵導出、署名、鍵管理の低レベル操作を提供します。一般的な実装には AES-GCM や ECDH などのプリミティブがあります。これらの操作は構成要素であり、認証を備えた完全なメッセージングプロトコルではありません。
必要なネイティブ API が利用できない場合、ウェブアプリは JavaScript や WebAssembly を使った、レビュー済みの ML-KEM 実装を追加できます。ブラウザーの対応状況は変化するため、開発者はすべてのブラウザーが同じアルゴリズムを提供すると考えず、対象の正確なバージョンで機能を検出する必要があります。
概念的なハイブリッド処理の流れは次のとおりです。
- 暗号学的に安全な乱数を使って適切な鍵を生成する。
- プロトコルの識別機構を使って相手の鍵素材を認証する。
- 従来型と耐量子型それぞれの共有秘密への寄与を取得する。
- 指定された鍵スケジュールと会話のコンテキストに従って、それらを組み合わせる。
- nonce と状態を正しく扱い、導出鍵で認証付き暗号化を行う。
これは説明のための概要であり、実装手順書ではありません。FIPS 203 は ML-KEM を標準化していますが、特定のブラウザーアプリを認証したり、チャットプロトコルのすべての手順を定義したりするものではありません。
HTTPS による配信も信頼モデルの一部
通常、平文を処理する JavaScript と WebAssembly はサーバーが供給します。悪意をもって改変されたアプリは、暗号ライブラリが健全なアルゴリズムを使っていても、暗号化前または復号後のメッセージを読むことができます。
HTTPS は配信元の認証と、ネットワークからの干渉に対する配信の保護に役立ちます。しかし、オリジンの運営者、そのデプロイシステムや依存関係が侵害されていないことの証明にはなりません。通常の HTTPS ウェブページが、自動的に独立して署名されたアプリケーションパッケージになるわけでもありません。
W3C WebCrypto のセキュリティ上の考慮事項 は、スクリプト注入とアプリの完全性を保護する必要性を説明しています。Content Security Policy、慎重な依存関係管理、その他のウェブセキュリティ対策はリスクを減らしますが、いずれも任意の同一オリジンのスクリプトを、アプリのデータに触れられない非信頼の観察者へと変えるものではありません。
WebAssembly もアプリのセキュリティ境界を共有します。サンドボックスは定義されたインターフェースを通じたホストへのアクセスを制限しますが、呼び出し元のページを信頼できるものにはしません。C を Wasm にコンパイルしても、元の言語がメモリ安全になるわけではありません。
鍵は必ずしも RAM だけに存在するわけではない
ブラウザーメッセンジャーは、ユーザーが同じ識別情報に戻れるように、鍵や暗号化された状態を永続保存する場合があります。端末のリンクや暗号化された復元を提供する場合もあります。そうした挙動は、存在しないと決めつけるのではなく、文書で説明される必要があります。
確認したい質問には次のものがあります。
- どの鍵が、どのブラウザーストレージに永続保存されるか。
- サイトデータを消去したり、プライベートブラウジングのセッションを終了したりするとどうなるか。
- 抽出不可の鍵でも、アプリのコンテキストで動く悪意あるコードから利用できるか。
- 新たに配信された更新は、古いローカル状態にアクセスできるか。
- 復元によって戻るのは識別情報か、メッセージ履歴か、それとも両方か。
抽出不可の WebCrypto 鍵が制限するのは API 経由のエクスポートです。それだけでは、敵対的なアプリコードが許可された操作を要求したり、平文を収集したりすることを防げません。
ウェブとネイティブのクライアントではトレードオフが異なる
| 検討事項 | ブラウザークライアント | ネイティブクライアント |
|---|---|---|
| 配布 | オリジン、ホスティング、ウェブ更新経路 | アプリストアまたはパッケージの配布・署名経路 |
| ローカル永続化 | ブラウザーストレージとプロファイルの挙動 | OS のアプリストレージとアプリのライフサイクル |
| 露出面 | 同一オリジンのスクリプト、拡張機能、ブラウザーの脆弱性 | アプリの依存関係と OS／アプリの脆弱性 |
| 可用性 | 到達可能なドメインと必要なネットワークサービス | インストール済みでも必要なネットワークサービスは必要 |
実装を調べずに、どちらの列からも優劣は決められません。ウェブアプリはアプリストアから削除された後もアクセスできる場合がありますが、ドメインの遮断やネットワーク経路の欠如によって利用できなくなる可能性は残ります。
性能は約束するのではなく測定する
FIPS 203 における ML-KEM-768 は、1,184 バイトのカプセル化鍵と 1,088 バイトの暗号文を使います。これらのサイズは、各短文メッセージに新しい素材を付けるのではなく、プロトコルが KEM 更新を計画的に行う理由を理解する助けになります。アプリ全体の帯域幅や速度の測定値ではありません。
有用なベンチマークは、ブラウザー、端末、ビルド、ウォームアップ方法、測定対象の操作、所要時間の分布を明記します。ページ起動、モジュール読み込み、メモリ使用量、低性能端末、ネットワークのオーバーヘッドも含めてください。「すべての現代的なスマートフォンで 2 ミリ秒未満」といった主張には、公表された測定結果が必要です。本記事はそれを提供していません。
Livara に当てはめると
Livara のセキュリティ概要は、LVR1 と復元の境界を説明しています。Proof Lab は、選ばれたローカルの P-256、HKDF、AES-GCM 操作を実演します。このページは、LVR1/LGS1 の完全な組み合わせがそのテスト環境の対象外であると明示しています。したがって、実演の成功は、配信済みのウェブコードすべての安全性を証明しません。
ブラウザーで機微な会話をする前に、正規の保守されたクライアントを使い、現在の脅威モデルを確認し、ブラウザープロファイルを保護し、サポートされる鍵確認手順で相手を検証してください。ウェブ配信の境界を評価に含め続ければ、利便性と有用な暗号技術は両立できます。
