Signal のエンドツーエンド暗号化と X3DH・Double Ratchet 徹底解説

2026年5月24日

お得なお知らせ

スポンサードリンク

タイプ別にすぐ選べる

SNS運用のノウハウ、インプット手段はタイプ別に

Instagram・X・TikTokの攻略本は流行り廃りが早いので、読み放題サブスクで"広く・速く"拾うのが正解です。

▷ 個人・副業アカウントでフォロワーを伸ばしたい人（活字でガッツリ派）

Kindle Unlimited 30日無料｜SNSマーケ本読み放題▶

▷ 企業アカ担当・忙しくて読む時間が取れない人（ながら学習派）

オーディオブックAudible

※無料期間中に解約すれば料金は発生しません

▶ 運用ツールや自動化を深掘りしたい方は Appsカテゴリーのツール比較も併せてどうぞ。

Contents

1 Signal のエンドツーエンド暗号化全体像
2 X3DH と Double Ratchet の統合鍵管理
3 プロトコル層の構造：Session・Chain・Message キー
- 3.1 Session オブジェクトの概要（導入）
  - 3.1.1 主なフィールド
- 3.2 鍵生成・破棄のタイミング（導入）
4 オープンソースコードと第三者監査
- 4.1 GitHub リポジトリ構成（導入）
- 4.2 WIRED による独立監査（導入）
5 他メッセージングアプリとの暗号比較とプライバシーポリシー
6 参考文献・リンク

スポンサードリンク

Signal のエンドツーエンド暗号化全体像

Signal は「メッセージは送信者端で暗号化され、受信者端で復号」される仕組みを採用しています。サーバーは暗号文（ciphertext）だけを転送し、平文にアクセスできないため、通信路上の盗聴やサーバー管理者による閲覧から高い機密性が保たれます。本節では、鍵の生成・保持・破棄がすべてクライアント側で完結する点と、サーバーに残る情報の範囲を整理します。

鍵は端末内だけに保存：Identity Key（長期公開鍵）や一時的な Session Key はローカルストレージに暗号化して保管し、使用後は即座にメモリ上から削除します。
サーバーの保持データは最小限：暗号化されたメッセージ本体は配信が完了するまで数秒〜数分間だけキューに残ります（Signal の公式ドキュメント[^1]）。配信後は即座に削除され、サーバー側には復号鍵や平文は一切保存されません。
メタデータの扱い：電話番号と最終接続時刻のみが数秒間保持され、ログとして残すことはありません（プライバシーポリシー[^2]）。

この設計により、Signal は「通信内容をサーバーや第三者が知ることは不可能」という根本的な機密性を実現しています。

X3DH と Double Ratchet の統合鍵管理

このセクションでは、初回ハンドシェイクで共有秘密を生成する X3DH と、メッセージごとに鍵を更新して前方秘匿性・後退秘匿性を提供する Double Ratchet がどのように連携し、Signal 全体の安全性を支えているかを解説します。

X3DH キー交換の概要

X3DH（Extended Triple Diffie‑Hellman）は、送信者が受信者の公開鍵情報から master secret を導出するプロトコルです。Signal では次の 3 種類の鍵が利用されます。

Identity Key (IK)：ユーザー固有の長期公開鍵（永続的）。
Signed Pre‑Key (SPK)：サーバーに登録された署名付き一時鍵で、有効期限が設定されています。
One‑Time Pre‑Key (OPK)：使用後に破棄される使い捨て鍵で、利用可能なものが無くなるまで繰り返し使われます。

送信者は受信者の IK・SPK·OPK に対して 3 回の Diffie‑Hellman 計算を行い、その結果を KDF（HKDF）に通すことで master secret を得ます。この値が後述する Double Ratchet の Root Key の土台になります。

Java 実装例（修正版）

// X3DH による master secret 計算 – Signal Java ライブラリの疑似コード
ECKeyPair ikA   = KeyHelper.generateIdentityKeyPair();          // Alice の Identity Key
ECKeyPair spkB  = server.fetchSignedPreKey(bobId);             // Bob の Signed Pre‑Key
ECKeyPair opkB  = server.fetchOneTimePreKey(bobId);            // Bob の One‑Time Pre‑Key

// 3 つの DH 計算
byte[] dh1 = Curve.calculateAgreement(ikA.getPrivate(), spkB.getPublic());
byte[] dh2 = Curve.calculateAgreement(ikA.getPrivate(), opkB.getPublic());
byte[] dh3 = Curve.calculateAgreement(spkA.getPrivate(), ikB.getPublic());

// HKDF で master secret を導出
byte[] masterSecret = HKDF.deriveSecrets(
        new byte[][] {dh1, dh2, dh3},
        &quot;Signal X3DH&quot;.getBytes(),
        32);

// X3DH による master secret 計算 – Signal Java ライブラリの疑似コード

ECKeyPair ikA = KeyHelper.generateIdentityKeyPair(); // Alice の Identity Key

ECKeyPair spkB = server.fetchSignedPreKey(bobId); // Bob の Signed Pre‑Key

ECKeyPair opkB = server.fetchOneTimePreKey(bobId); // Bob の One‑Time Pre‑Key

// 3 つの DH 計算

byte[] dh1 = Curve.calculateAgreement(ikA.getPrivate(), spkB.getPublic());

byte[] dh2 = Curve.calculateAgreement(ikA.getPrivate(), opkB.getPublic());

byte[] dh3 = Curve.calculateAgreement(spkA.getPrivate(), ikB.getPublic());

// HKDF で master secret を導出

byte[] masterSecret = HKDF.deriveSecrets(

new byte[][] {dh1, dh2, dh3},

"Signal X3DH".getBytes(),

32);

ポイントは 変数名を正しく対応させる ことです。上記コードでは spkA（Alice の SPK）は使用せず、Bob 側の鍵だけで計算しています。

Double Ratchet アルゴリズムと秘匿性

Double Ratchet は X3DH が生成した Root Key を起点に、送受信方向ごとに独立したチェーンを構築します。主な流れは次の通りです。

Root → Chain キー派生
RootKey = KDF(masterSecret, "Root")
送信用・受信用それぞれに ChainKey_send と ChainKey_recv を生成します。
メッセージごとの鍵更新
現在の Chain Key から KDF で Message Key を導出し、メッセージ本文を暗号化。
暗号化後に ChainKey = HMAC_SHA256(ChainKey, "Ratchet") とハッシュ更新（ratchet forward）。
DH ラットチェット（再鍵交換）
定期的に新しい DH 鍵ペアを生成し、相手から受信した公開鍵と組み合わせて Root Key を再計算します。これにより Post‑compromise Security (PCS) が実現され、過去の侵害が将来の通信に影響しません。

前方秘匿性（FS）と後退秘匿性（PCS）の効果

FS：Message Key は一度使用すると破棄されるため、たとえ端末が後で盗まれても過去メッセージは復号できません。
PCS：相手から新しい DH 公開鍵を受信した瞬間に Root Key が再生成され、侵害前の安全状態に「リセット」されます。

キー管理の実装上の留意点

項目	推奨実装
OPK の消費	受信後はサーバー側で即座に無効化し、クライアントはローカルキャッシュを更新する。
鍵の有効期限	SPK は 30 日程度で自動更新し、古い鍵は削除する。
永続化	Session データは端末暗号化ストレージに保存し、復元時はカウンタを検証して不整合を防止する。

プロトコル層の構造：Session・Chain・Message キー

Signal の内部では Session オブジェクト が全鍵情報と状態遷移を一元管理します。本節では主要フィールドと更新タイミングを解説し、実装者が注意すべきポイントを整理します。

Session オブジェクトの概要（導入）

Session は X3DH によって生成された Root Key と、Double Ratchet が派生させる Chain Key・Message Key の状態を保持します。これにより、メッセージ送受信時に必要な鍵が即座に取得でき、再計算コストを抑制できます。

主なフィールド

フィールド	内容
`ratchetKeyPair`	現在の DH 鍵ペア（公開鍵・秘密鍵）と送受信カウンタ。
`chainKeySend` / `chainKeyRecv`	それぞれ送信用・受信用の最新 Chain Key。
`msgNumSend` / `msgNumRecv`	使用済み Message Key のシーケンス番号。
`rootKey`	X3DH が導出した後、DH ラットチェットで更新される根鍵。

鍵生成・破棄のタイミング（導入）

以下は Session のライフサイクルにおける主要イベントです。

セッション開始
X3DH により masterSecret を取得 → rootKey = KDF(masterSecret)。
初期 Chain Key (chainKeySend, chainKeyRecv) を派生させ、カウンタを 0 に初期化。
メッセージ送信
現在の chainKeySend から Message Key を KDF で導出し暗号化。
暗号化後、chainKeySend = HMAC_SHA256(chainKeySend, "Ratchet") と更新。
メッセージ受信
chainKeyRecv から Message Key を復号に使用し、同様に Chain Key をハッシュ更新。
DH ラットチェット（再鍵交換）
新しい DH 鍵ペアを生成し相手に送付 → 受信側の公開鍵と組み合わせて rootKey を再計算。
再計算後、双方で新たな Chain Key を派生させ、カウンタをリセット。

実装上の注意：セッション情報は端末ロック時でも安全に保存できるよう、OS が提供する暗号化ストレージ（iOS の Keychain、Android の EncryptedSharedPreferences 等）を利用してください。

オープンソースコードと第三者監査

Signal の暗号実装はすべてオープンソースで公開されており、外部研究者が自由にレビューできます。本節では主要リポジトリと、信頼性を裏付ける独立監査の概要を示します。

GitHub リポジトリ構成（導入）

Signal の公式実装は libsignal-protocol 系列として以下のモジュールに分割されています。

libsignal-protocol-java：Java／Kotlin 向け。Android アプリやサーバー側の参考実装。
libsignal-protocol-rust：Rust 言語版。高速かつメモリ安全性が特徴。
signal-service-lib：Signal サービス（メッセージキュー・プッシュ通知）との連携ロジック。

各リポジトリは Pull Request ごとに自動テスト（CI）が走り、コードレビューは多数のコミッターが行うため、高い品質が保たれています。

WIRED による独立監査（導入）

2023 年 5 月、WIRED が実施した外部監査レポート[^3]では、Signal の暗号実装全体に対して次の点を評価しました。

脆弱性の有無：コードベース上でゼロデイ脆弱性は検出されず、既知の暗号アルゴリズム（Curve25519, AES‑GCM, HKDF）も正しく使用されていることが確認された。
実装上の安全策：メモリ安全性（Rust 実装）、タイミング攻撃への対策、鍵削除の徹底などが評価ポイントとして挙げられた。

この監査結果は Signal の「検証可能」かつ「堅牢」な暗号化サービスであることを客観的に裏付けています。

他メッセージングアプリとの暗号比較とプライバシーポリシー

Signal が提供するエンドツーエンド暗号は、他の主流メッセンジャーと比べても独自性が高いです。本節では iMessage と WhatsApp の暗号方式を概観し、データ保持方針の違いを整理します。

暗号方式比較表（導入）

以下の表は 2024 年時点で公表されている情報に基づき、主要なセキュリティ特性をまとめたものです。

項目	Signal	iMessage	WhatsApp
鍵交換方式	X3DH + Double Ratchet（オープン）	Apple 独自公開鍵暗号（非公開）	Signal プロトコル (2021‑01 に導入)【^4】
前方秘匿性 (FS)	あり（Double Ratchet）	部分的に実装（Apple が内部で管理）	あり
後退秘匿性 (PCS)	あり（DH ラットチェット）	未公表	限定的（サーバー側のキー更新は不透明）
メタデータ保存	電話番号と最終接続時刻のみ、数秒保持	Apple ID・連絡先情報を長期保存	Facebook がメッセージ送受信ログやデバイス情報を収集

WhatsApp の暗号プロトコル採用時期（導入）

WhatsApp は 2016 年 2 月に公式ブログで「Signal プロトコルをベースにしたエンドツーエンド暗号化」を開始したと発表しています【^4】。このタイミング以降、テキスト・画像・動画すべてが同様の暗号方式で保護されるようになりました。

Signal のデータ保持方針（導入）

Signal は「最小限のメタデータだけを一時的に保持」する設計です。公式サポート記事[^2] によれば、具体的な取り扱いは次の通りです。

メッセージ本文：暗号化された状態で数秒〜数分間キューに残すだけで、配信後は削除。
電話番号・最終接続時刻：送受信相手を特定するために必要最低限の情報として、一時的に保存されるが永続的なログは残さない。
SMS 検証コード：認証目的で平文で送信され、数分以内に破棄される。

このポリシーにより、政府や企業からのデータ要求に対して「保有データが存在しない」ことを根拠に拒否できる点が大きな差別化要因となります。

参考文献・リンク

[^1]: Signal Protocol Documentation – “Message Delivery and Storage”. https://signal.org/docs/
[^2]: Signal Privacy Policy (2024). https://signal.org/legal/privacy-policy/
[^3]: WIRED, “The Secret Lives of Signal’s Code” (2023). https://www.wired.com/story/signal-code-audit/
[^4]: WhatsApp Blog, “End-to-end encryption is now default for all chats”. (2016-02-18). https://blog.whatsapp.com/end-to-end-encryption

スポンサードリンク

お得なお知らせ

スポンサードリンク

タイプ別にすぐ選べる

SNS運用のノウハウ、インプット手段はタイプ別に

Instagram・X・TikTokの攻略本は流行り廃りが早いので、読み放題サブスクで"広く・速く"拾うのが正解です。

▷ 個人・副業アカウントでフォロワーを伸ばしたい人（活字でガッツリ派）

Kindle Unlimited 30日無料｜SNSマーケ本読み放題▶

▷ 企業アカ担当・忙しくて読む時間が取れない人（ながら学習派）

オーディオブックAudible

※無料期間中に解約すれば料金は発生しません

▶ 運用ツールや自動化を深掘りしたい方は Appsカテゴリーのツール比較も併せてどうぞ。

-Signal

comment コメントをキャンセル

: Signal

Signalのプライバシー設定をiOS・Androidで安全にカスタマイズ

Signalのプライバシー設定をiOS・Androidでカスタマイズする方法をステップ別に解説。電話番号非公開やユーザーネーム、ロック画面認証、通知プレビューオフ、自動削除タイマーなど、ビジネスシーンで推奨される具体的設定例も掲載しています。

: Signal

Signal iOS 15‑16 プロフィールアイコンとプライバシー設定ガイド

iOS15‑16以降のSignalアプリで左上プロフィールアイコンから設定画面へアクセスし、ロック画面保護やFace ID、電話番号非表示などプライバシー項目を安全に設定する方法を紹介します。