Signal、暗号化の「信頼の穴」を塞ぐ自動鍵検証を実装

暗号化メッセージアプリSignalに、対面不要で暗号鍵の正当性を確認できる新機能が加わった。ロシア情報機関による攻撃が続く中、「プロトコル自体の弱点」に初めてメスが入る。

安全番号という「正しいけれど使えない」仕組み

Signalの暗号化は、メッセージを送るとき相手の公開鍵をサーバーから取得するところから始まる。だがそのサーバーが侵害され、偽の鍵を返してきたら？攻撃者が間に割り込み、すべてのメッセージを傍受できてしまう。いわゆる中間者攻撃だ。

Signalにはこれを防ぐ手段がすでにあった。「安全番号」と呼ばれる60桁の数列を、相手と直接会ってQRコードで照合するか、別の信頼できるチャネルで確認する方法だ。暗号的には完璧な仕組みだが、実際にやっている人はほとんどいない。

対面で60桁を照合してくれ、と頼まれて応じる友人がどれだけいるか。セキュリティの世界では「理論上正しいが誰もやらない対策」は、存在しないのと同じだ。

鍵透過性という解決策

Signalは現地時間8月11日、「自動鍵検証」と呼ばれる新機能を発表した。正式名称はAutomatic Key Verification。対面も別チャネルも要らない。アプリが自動で暗号鍵の正当性を検証する。

安全番号の手動照合と等しい保証を、対面も別の通信手段も使わずに実現する検証の仕組みだ。

Signalのソフトウェアエンジニア、キャサリン・イェン（Katherine Yen）氏はこう説明している。

仕組みの核にあるのは「鍵透過性」（key transparency）と呼ばれる技術だ。ユーザーの電話番号やユーザー名と公開鍵の対応関係を、改ざん不可能な暗号ログに記録する。このログは追記専用で、過去の記録を書き換えたり削除したりできない。

ここまでなら「Signalが正直に運営していれば問題ない」で終わる。だが鍵透過性のポイントは、Signalすら信頼しなくていい設計にあることだ。

3者による監視体制

ログの整合性を検証するのは、Signal自身に加えてCloudflareとTrail of Bitsの2つの独立した第三者監査機関だ。

Trail of BitsはSignalの参照実装を使わず、仕様書からゼロベースで独自の監査システムを構築した。しかもこの業務に対してSignalから報酬を受け取っていない。自由で安全な通信は公共財だ、という信念に基づく無償の取り組みだと明言している。

Signalアプリは定期的にマークル木のヘッドを取得し、3つの監査機関すべての署名が7日以内に付与されているかを確認する。署名がなければアプリが警告を出す。つまり、仮にSignalのサーバーが完全に乗っ取られたとしても、偽の鍵を配り続けられるのは最大1週間だ。

Signalのサーバーが悪意を持って動作しても、7日以内にクライアントが異常を検知する設計になっている。

何を守り、何を守らないか

ここで冷静に整理しておきたい。この機能が対処するのは「サーバーレベルでの鍵すり替え」だ。Signalの内部が侵害されて偽の公開鍵を配られるシナリオに対する防御になる。

一方、2025年から激化しているロシア情報機関による攻撃は、まったく別の手口だ。UNC5792やUNC4221と名付けられたグループは、「Signalサポート」を装ったフィッシングメッセージでユーザーを騙し、リンクデバイス機能を悪用してアカウントに侵入している。暗号を破るのではなく、人を騙す。

2026年6月には、FBIとCISAがこの攻撃の手口がバックアップリカバリキーの窃取にまで拡大していると警告した。米国務省はUNC5792の構成員の特定につながる情報に最大1000万ドル（約15億9000万円）の懸賞金を設定している。

自動鍵検証は、こうしたフィッシング攻撃を防ぐ機能じゃない。アカウントの乗っ取りを検知する機能でもない。守るのはSignal自身のインフラに対する攻撃であり、ユーザーを狙った攻撃とは違う。

Signalの設計思想を考えれば、この区別は当然のことだ。鍵透過性はプロトコルの信頼基盤を強化するもの。ユーザーのリテラシーに依存する問題は、5月に追加されたフィッシング対策の警告メッセージなど、別のレイヤーで対処する。

使い方と制約

有効化はSettings > Privacy > Advancedから「Automatic Key Verification」をオンにすればいい。相手の連絡先を開いて「View Safety Number」から「Verify Automatically」をタップすれば、鍵の正当性が確認できる。成功すれば緑のチェックマークと「Encryption verified」が表示される。

ただ、制約がある。この機能は相手の電話番号が必要だ。ユーザー名だけでつながっている相手には使えない。電話番号を知らない相手の暗号鍵を検証するには、従来の安全番号による手動確認に戻るしかない。

電話番号を知らない相手には自動検証は使えない。その場合は従来の安全番号で手動確認する必要がある。

また、相手が電話番号を変更した場合にも自動検証は使えなくなる。暗号化自体は維持されるが、検証ステータスが不明になるため、別の信頼できるチャネルで確認することが推奨される。

最後のピースが埋まった

鍵透過性の導入は、WhatsAppが2023年4月、AppleのiMessageが2023年末、Metaが2025年11月と、主要な暗号化メッセージングプラットフォームで順次進んできた。Signalの対応で、主要プレイヤーのすべてが鍵透過性モデルに参加したことになる。

Signalがこの技術を「最後に」実装したことには、おそらく意味がある。後発であるぶん、監査機関の独立性やオープンソース実装の徹底など、設計の純度が際立つ。CloudflareとTrail of Bitsという外部の目を入れつつ、サーバーもオープンソースで公開した。信頼を要求する代わりに、検証可能性を提供する。Signalらしいアプローチだ。

暗号プロトコルは堅牢でも、その上に載る「信頼の仕組み」は長らく手つかずだった。その穴が、いま塞がろうとしている。

関連記事

• Signalが英国のデバイス一斉スキャン計画に「監視インフラだ」と反論
• EFFがMeta批判、暗号化廃止で「ユーザーのせいにするな」
• Appleの「メールを非公開」は警察からは隠せない
• 国連サイバー犯罪条約、批准わずか3カ国。「重大犯罪」の定義が握る人権の行方
• Windowsの人気アプリを装う偽サイト72件、開発者が組織的作戦を発見
• 教皇の祈りアプリ、71万人の個人情報が丸見えに
• Zimbraのゼロクリック攻撃、27機関が共同勧告 1年間継続
• 反対多数でも止められなかった。EUチャットコントロールが復活
• CAPTCHA不要へ。Cloudflareとブラウザ3社が新プロトコル
• 「AIは友だちではない」Signal代表が突きつけた問い