公開鍵暗号はどう共有秘密を確立する？鍵共有・暗号化・署名を解説

ウェブサイトでのログインやオンラインショッピングでの決済など、現代のインターネットでは日常的に安全な通信が行われています。その根底を支えているのが「公開鍵暗号」の技術です。

しかし、「公開された鍵でデータを暗号化して送る仕組み」だけでは、Web通信の安全性は成り立ちません。現代のWeb標準であるTLS 1.3などの通信において、データ本文の暗号化に公開鍵暗号が直接使われることはほとんどなく、中心的な役割を果たしているのは、見知らぬ二者が盗聴者の前で共通の鍵を作り出す「鍵合意（Key Agreement）」と、通信相手の真正性を確かめる「デジタル署名」です。

本記事では、「公開鍵暗号がどのようにして共有の秘密を確立するのか」という問いを中心に、暗号化・デジタル署名・鍵合意という3大機能の根本的な違い、Diffie-Hellman方式による鍵確立の仕組み、TLS 1.3における多段階鍵スケジュール、そして2024年に正式確定した耐量子暗号（PQC）の最新動向までを客観的な事実に基づいて分かりやすく解説します。

---

1. 公開鍵暗号の基本原理：一方向性と鍵ペアの3大機能

公開鍵暗号の最大の特徴は、ペアとなる「公開鍵」と「秘密鍵」を別々に使い分ける点にあります。公開鍵は誰にでも公開してよい情報であり、秘密鍵は所有者本人だけが厳重に保管する情報です。

この仕組みを数学的に支えているのが「計算の一方向性」です。ある方向の計算は容易に行えるのに対し、その逆方向の計算は極めて困難であるという性質を指します。ただし、ここでいう「逆方向の計算が困難」とは、数学的に絶対不可能であることを意味するわけではありません。適切な群や楕円曲線、および既知の解読手法に対して安全と評価されたパラメータが選定されている条件において、現実的な計算資源（スーパーコンピュータ等を用いても天文学的な時間がかかること）に照らし合わせて、秘密を求めることが極めて難しいと考えられている状態を指します。さらに公開鍵暗号では、特定の「秘密情報（トラップドア：抜け穴）」を知っている者だけが、その困難な逆計算を容易に行えるような数学的構造が利用されます。

上の図（図1）は、公開鍵暗号技術が持つ主要な3つの処理方式を示したものです。多くの入門書では「南京錠」の比喩が使われます。受信者が開いた南京錠（公開鍵）を配り、送信者がその錠をかけて荷物を送れば、鍵（秘密鍵）を持つ受信者だけが箱を開けられる、という説明です。

この比喩は直感的ですが、重要な前提があります。それは「相手から渡された南京錠が、本当に相手本人のものであると確認できていること」です。また、南京錠を施錠した送信者本人であっても、一度施錠してしまえば受信者の公開鍵だけでは通常その暗号文を自力で復号（元に戻すこと）はできません（図1の小図1参照）。

公開鍵暗号の技術は、目的によって次の3つの機能に明確に分類されます。

1. 公開鍵暗号化（機密性の確保）：受信者の公開鍵でメッセージを暗号化し、受信者の秘密鍵でのみ復号する。
2. デジタル署名（完全性と真正性の確保）：作成者の秘密鍵を使って署名を生成し、受信者が作成者の公開鍵を使って検証する。
3. 鍵合意（共有秘密の確立）：双方が公開情報を交換し合い、第三者に盗聴されていても安全に同一の秘密値を各自の手元で導出する。

現代の安全な通信プロトコルは、これら3つの機能を適材適所で組み合わせることで成り立っています。

---

2. デジタル署名は「暗号化の逆」ではない：検証アルゴリズムの仕組み

公開鍵暗号の説明で最も頻繁に見られる誤解の一つが、「デジタル署名とは、秘密鍵で暗号化し、公開鍵で復号することである」という表現です。歴史的な初期のRSA暗号の一面だけを捉えて便宜的にそう説明されることがありましたが、現代の暗号学においてこの説明は正確ではありません。

暗号化とデジタル署名は、目的もアルゴリズムの構造も根本的に異なる独立した処理です。現代の標準的な署名方式であるEdDSA（RFC 8032）などを確認すると、デジタル署名は以下の2つの独立したアルゴリズムによって成り立っています。

• 署名作成アルゴリズム（Sign）：作成者の「秘密鍵」と送信したい「メッセージ（またはそのハッシュ値）」を入力とし、数学的な計算を行って「署名データ」を出力する。
• 検証アルゴリズム（Verify）：作成者の「公開鍵」、「メッセージ」、送られてきた「署名データ」の3つを入力とし、あらかじめ定められた数学的関係式が満たされているかどうかを判定して、「正当（True）」または「不正（False）」を出力する。

図1の小図2に示されているように、検証者は暗号文を平文に戻す「復号」を行っているわけではありません。公開鍵を使って、「この署名データが、確かに対応する秘密鍵とこのメッセージから生成された正当なものか」という関係式を確かめているだけです。また、安全なシステム設計においては、暗号化に使う鍵ペアとデジタル署名に使う鍵ペアを同一にせず、署名専用の鍵として分離して管理することが基本原則とされています。

ここで、デジタル署名が保証する範囲について、客観的な限界を正しく理解しておく必要があります。デジタル署名の検証が成功したときに確認できるのは、以下の2点に限られます。

• メッセージが通信途中で改ざんされていないこと（データの完全性）。
• その署名が、検証に用いた公開鍵と対になる秘密鍵によって作成されたこと（作成元の真正性）。

これらは、「秘密鍵が第三者に盗まれず厳重に管理されていること」および「公開鍵が確かに本人のものであると確認できていること」を前提としています。デジタル署名が正当であるからといって、送信者の「人間的な善意」や「書かれている内容が客観的事実であること（真実性）」までを数学が保証してくれるわけではありません。

---

3. 鍵合意の核心：Diffie-Hellman方式と鍵導出関数（KDF）

インターネット上で暗号化通信を始めるとき、最大の課題となるのが「通信相手とどうやって共通の秘密鍵を共有するか」です。共通鍵をそのまま平文で送信してしまえば、ネットワークを盗聴している第三者に漏洩してしまいます。

この課題を解決する手段には、大きく分けて「鍵配送（Key Transport）」と「鍵合意（Key Agreement）」という2つの異なるアプローチが存在します。

• 鍵配送（Key Transport）：通信の一方が秘密の暗号鍵（またはその元となる値）を生成し、相手の公開鍵で暗号化してネットワーク越しに送信する方式。
• 鍵合意（Key Agreement）：通信を行う双方がそれぞれ自分自身の秘密値を保持し、公開情報だけを交換し合うことで、最終的に双方が同一の秘密値を各自の手元で計算・導出する方式。

後者の「鍵合意」を世界で初めて公に提唱したのが、ホイットフィールド・ディフィー（Whitfield Diffie）とマーティン・ヘルマン（Martin Hellman）が1976年に発表した画期的な論文『New Directions in Cryptography』でした。この論文は公開鍵暗号と鍵共有の考え方を広く知られるものにした代表的な公開論文であり、その中で示された方式は「Diffie-Hellman（DH）鍵合意」と呼ばれています。

「全員に聞かれているのに、二人だけの秘密を作れる」という状況は、一見すると不思議に思えます（なお、この表現は当時の歴史的な引用句ではなく、この画期的な性質を分かりやすく伝えるための説明用の言葉です）。

絵の具の混色モデル（直感的な理解）

Diffie-Hellman鍵合意の直感的なイメージとしてよく用いられるのが、絵の具の混色モデルです。

1. 二人はあらかじめ、誰に見られてもよい共通の「ベース色（黄色）」を決めておきます。
2. アリスは秘密の色（赤色）を選び、ベース色と混ぜて「オレンジ色」を作り、ボブへ送ります。
3. ボブも秘密の色（青色）を選び、ベース色と混ぜて「黄緑色」を作り、アリスへ送ります。
4. 通信路上を見ている盗聴者は、共通の黄色と、混ざったオレンジ色、黄緑色を見ることができますが、混ざった色からアリスやボブの秘密の色だけを分離することは困難です。
5. アリスは受け取った黄緑色に自分の秘密の色（赤色）を混ぜ、ボブは受け取ったオレンジ色に自分の秘密の色（青色）を混ぜます。
6. 双方の手元には「黄色＋赤色＋青色」が混ざり合った同一の「茶色」が完成します。

このように、二人は秘密の色そのものを一度も相手に送ることなく、手元に同一の秘密を作り出すことができます。

数学的な教育用モデル（小さな数値例）

実際のDiffie-Hellman鍵合意では、絵の具ではなく「剰余演算（余りを求める計算）」が用いられます。仕組みを理解するための教育用の数値例（小さな素数を用いた模型）で計算の流れを見てみましょう。

誰にでも公開されるパラメータとして、素数 p = 23 と、生成元と呼ばれる基準値 g = 5 をあらかじめ共有しておきます。

1. アリスは自分だけの秘密の値 a = 6 を選び、次の計算を行って公開値 A をボブに送信します。

A = g^a \bmod p = 5^6 \bmod 23 = 15625 \bmod 23 = 8

1. ボブは自分だけの秘密の値 b = 15 を選び、同様に計算して公開値 B をアリスに送信します。

B = g^b \bmod p = 5^{15} \bmod 23 = 19

1. 通信路上には p=23, g=5 に加え、公開値 A=8 と B=19 が流れます。
2. アリスは受け取った B=19 と自分の秘密 a=6 を使って計算します。

S = B^a \bmod p = 19^6 \bmod 23 = 47045881 \bmod 23 = 2

1. ボブは受け取った A=8 と自分の秘密 b=15 を使って計算します。

S = A^b \bmod p = 8^{15} \bmod 23 = 35184372088832 \bmod 23 = 2

冪乗の数学的性質（(g^b)^a = (g^a)^b = g^{ab} \bmod p）により、アリスとボブの手元にはまったく同じ共有秘密「2」が求まります。

現実の安全性と鍵導出関数（KDF）の必須性

注意しなければならないのは、上記の小さな数値例は剰余演算の仕組みを直感するための「模型」に過ぎず、実用的な安全性は一切持たないということです。

盗聴者が公開値 A = g^a \bmod p から秘密の指数 a を求める問題を「離散対数問題」と呼びます。一般に「総当たりで調べるしかない」と説明されることがありますが、これも不正確です。数学の世界には指数計算法など、単純な総当たりよりもはるかに効率的な解読アルゴリズムが存在します。

そのため、実運用において安全性を確保するには、解読手法に対抗できる適切な数学的構造（有限体の群や楕円曲線）を選定し、十分なサイズのパラメータを採用する必要があります。推奨されるパラメータ基準は一律ではなく、有限体離散対数暗号（FFC）か楕円曲線暗号（ECC）かといった方式ごとに、公的機関の規格（NIST SP 800-56A Rev. 3など）によって詳細に定められています。

さらに、図1の小図3に示されている極めて重要なルールがあります。Diffie-Hellman計算によって得られた「共有秘密（Shared Secret）」の数値を、そのまま通信データの暗号化鍵として使ってはならないという点です。

数学的な計算で得られた共有秘密には、ビットの並びに偏り（特定のパターンが出やすい性質）が含まれている可能性があります。高品質な暗号鍵には、すべてのビットが偏りなくランダムであることが要求されます。

そのため、NIST規格等の標準仕様では、計算された共有秘密を必ず「鍵導出関数（KDF: Key Derivation Function）」と呼ばれる一方向の変換関数に入力し、統計的に偏りのない均一なビット列に変換してから、通信用の暗号鍵として使用することが義務付けられています。

---

4. 中間者攻撃の脅威と公開鍵基盤（PKI・証明書）の役割

Diffie-Hellman鍵合意は画期的な技術ですが、単体では致命的な弱点を持っています。それは「通信相手の身元を確かめる手段（認証）が含まれていない」という点です。

もしアリスとボブの通信経路上に悪意ある攻撃者マロリーが割り込んでいた場合、次のような「中間者攻撃（Man-in-the-Middle Attack）」が成立してしまいます。

1. アリスはボブに向けて公開値 A を送信します。
2. マロリーは通信路上で A を遮断し、ボブにはマロリー自身の公開値 M_1 を送ります。
3. ボブはアリスに向けて公開値 B を送信しますが、マロリーはこれも遮断し、アリスにはマロリー自身の公開値 M_2 を送ります。
4. 結果として、アリスはマロリーとの間で鍵合意を行い、ボブもマロリーとの間で別個に鍵合意を完了させてしまいます。
5. アリスが暗号化して送ったメッセージはすべてマロリーの手元で復号・盗聴され、マロリーがボブ用の鍵で再暗号化してボブへ転送されます。

アリスとボブは正常に暗号通信が行われていると思い込んでいますが、実際にはすべての通信が筒抜けになってしまいます。

電子証明書（サーバー証明書）が解決すること

この中間者攻撃を防ぐために不可欠となるのが、「公開鍵が本物であることの証明」です。ここで登場するのが「公開鍵基盤（PKI: Public Key Infrastructure）」と、信頼できる第三者機関（認証局：CA）が発行する「電子証明書（サーバー証明書）」です。

サーバーは、あらかじめ認証局に自身の公開鍵を提出し、認証局の秘密鍵でデジタル署名を施した電子証明書を発行してもらいます。通信を開始する際、クライアントはサーバーからこの証明書を受け取り、OSやブラウザにあらかじめ組み込まれている「信頼されたルート認証局の公開鍵」を使って証明書の署名を検証します。

RFC 9525（サービス識別子の検証仕様）に基づき、クライアントは以下の厳格な検証を行います。

• 証明書に記載されたデジタル署名が正当であり、信頼された認証局によって発行されていること。
• 有効期限内であり、失効していないこと。
• 接続しようとしているドメイン名（例: example.com）が、証明書内に記載された対象ドメイン名と一致していること。

この検証に成功して初めて、クライアントは「提示された公開鍵は、確かに接続先ドメインの管理権限を持つサーバーのものである」と確認できます。

証明書に対するよくある誤解

Webブラウザのアドレスバーに「鍵マーク」が表示されると、「このWebサイトは安全で信頼できる」と感じる人が多いかもしれません。しかし、この解釈には注意が必要です。

電子証明書が技術的に証明しているのは、あくまで「指定されたドメイン名の正当な管理権限と、提示された公開鍵の対応関係」だけです。

認証局は、サイト運営者が法律を守る誠実な事業者であるか（道徳性）や、Webサイトに書かれている情報が真実であるか（真実性）を審査しているわけではありません。悪意を持った詐欺グループであっても、独自に取得したドメイン名に対して正当なサーバー証明書を取得し、通信を暗号化（HTTPS化）することは容易に可能です。

「通信経路が暗号化されていること」と「通信相手の事業者が信用できること」は、まったく別の問題であると認識しておく必要があります。

---

5. 現代Webを守るTLS 1.3：前方秘匿性と多段階の鍵スケジュール

私たちが普段利用しているWebブラウザの安全な通信（HTTPS）は、TLS（Transport Layer Security）プロトコルによって保護されています。2018年に策定された現行標準「TLS 1.3（RFC 8446）」では、過去の仕様から大幅な安全性の向上が図られました。

静的RSA鍵配送の廃止と「前方秘匿性」

かつてのTLS 1.2以前では、サーバーの公開鍵を使って暗号鍵の元（premaster secret）を暗号化して送信する「RSA鍵配送」が広く使われていました。

しかし、この方式には構造的なリスクがありました。もし通信内容を記録（パケットキャプチャ）している攻撃者がいた場合、将来サーバーから長期の秘密鍵が盗まれたり漏洩したりすると、過去に記録されていた通信内容が遡って一括復号されてしまうのです。

この問題を解決するため、TLS 1.3では静的なRSA鍵配送が完全に廃止されました。代わりに採用されたのが、通信セッションごとに使い捨ての一時的な鍵ペアを生成して鍵合意を行う「一時Diffie-Hellman鍵合意（(EC)DHE）」や、事前共有鍵（PSK）モードです（※楕円曲線を用いるECDHEだけでなく、有限体を用いるDHEも規格上規定されています）。

セッション終了後に一時的な秘密鍵をメモリ上から確実に破棄しておけば、仮に将来サーバーの長期秘密鍵（証明書の鍵）が漏洩したとしても、過去の通信で使用された一時秘密はどこにも残っていないため、過去の通信を復号することは極めて困難になります。

この性質を「前方秘匿性（Forward Secrecy）」と呼びます。ただし、これも「未来永劫、絶対に解読されない」という過大な保証ではありません。一時秘密が適切に破棄されていること、および暗号アルゴリズムそのものが破られていないことを前提とした現実的な防御特性です。

TLS 1.3の多段階鍵スケジュール

TLS 1.3の接続処理（ハンドシェイク）は、洗練された多段階のプロセスで進められます。わずか1往復（1-RTT）の通信で、安全な通信路の確立と相手の認証を同時に行います。

1. 公開値の交換：クライアントは接続開始メッセージ（ClientHello）で自身の一時的な鍵合意の公開値を送り、サーバーも自身の公開値を返送（ServerHello）します。
2. 共有秘密の計算とハンドシェイク鍵の導出：双方は受け取った公開値からDiffie-Hellman計算を行って「共有秘密」を算出します。そして鍵導出関数（HKDF）を通じて、まず「ハンドシェイク用の一時暗号鍵」を導出します。
3. 証明書と署名の送信（暗号化保護下での実施）：サーバーは自身の証明書と、通信履歴に対するデジタル署名をクライアントへ送ります。このやり取り自体が、先ほど導出したハンドシェイク用鍵によって暗号化されます。
4. 認証の検証：クライアントはサーバー証明書を確認し、署名検証アルゴリズムを実行して相手が正当なサーバーであることを確かめます。
5. アプリケーション鍵の導出と通信開始：認証が完了すると鍵スケジュールは次の段階へ進み、実際のWebデータ（HTTPリクエストやレスポンス）を暗号化するための「アプリケーション用通信鍵」が導出されます。

データ通信には、機密性の確保（暗号化）と改ざん検知（完全性の確認）をひとつの処理で同時に行う「AEAD（Authenticated Encryption with Associated Data: 認証付き暗号）」が使用されます。

このように、TLS 1.3では「鍵合意」によって共有秘密を作り、「デジタル署名」によって中間者攻撃を排除し、多段階の「鍵導出」を経て安全な通信路を完成させています。

---

6. 公開鍵暗号の現在と未来：耐量子暗号（PQC）への移行

現代のインターネットの安全を支えている公開鍵暗号ですが、現在、技術的な歴史の大きな転換点を迎えています。それが「量子コンピュータ」の登場に伴う影響です。

なぜ従来の公開鍵暗号が脅かされるのか

現在広く普及しているRSA暗号（大きな素数の積を素因数分解する問題）や、Diffie-Hellman鍵合意、楕円曲線暗号（離散対数問題）は、従来の古典的コンピュータに対しては十分な安全性を誇っています。

しかし、十分な規模と精度を持つ誤り耐性型の汎用量子コンピュータが実現した場合、数学者ピーター・ショア（Peter Shor）が考案した「ショアのアルゴリズム」を実行することで、素因数分解問題や離散対数問題が現実的な時間で解かれてしまうことが理論的に証明されています。

もしこれが実現すれば、従来の公開鍵暗号化、デジタル署名、鍵合意の安全性は根底から覆ることになります。

なお、共通鍵暗号（AESなど）に対しても「グローバーのアルゴリズム」による探索の高速化が知られていますが、こちらは鍵の長さを2倍（例えばAES-128からAES-256へ）に増やすことで安全性を維持できるとされています。最も抜本的な再設計を迫られているのは、公開鍵暗号の側です。

米NISTによる耐量子暗号（PQC）標準の正式確定

こうした脅威に備え、量子コンピュータを用いても現実的な計算資源では解読が極めて困難であるような新しい数学的基礎（格子暗号など）に基づく「耐量子計算機暗号（PQC: Post-Quantum Cryptography）」の国際的な標準化が進められてきました。

そして2024年8月13日、米国立標準技術研究所（NIST）は世界に向けて極めて重要な発表を行いました。約8年間にわたる国際公募と評価プロセスを経て、最初の3つの耐量子暗号標準規格を正式に確定・公表したのです。

確定した標準規格は以下のとおりです。

• FIPS 203（ML-KEM）：格子理論に基づく鍵カプセル化メカニズム（Module-Lattice-Based Key-Encapsulation Mechanism）。主にWeb通信などの鍵確立（鍵合意の代替）として用いられる。
• FIPS 204（ML-DSA）：格子理論に基づくデジタル署名アルゴリズム（Module-Lattice-Based Digital Signature Algorithm）。一般的な認証や署名用途の主軸となる規格。
• FIPS 205（SLH-DSA）：ステートレスなハッシュ関数に基づくデジタル署名アルゴリズム（Stateless Hash-Based Digital Signature Algorithm）。格子暗号とは異なる数学的基盤を持ち、将来的なバックアップ手段としても位置づけられる。

注意すべき点は、耐量子暗号も「未来永劫、絶対に破られない暗号」として断定されているわけではないということです。新しい攻撃手法の発見や数学的な研究の進展によって安全性の評価は常に更新されます。

現在、主要なWebブラウザやサーバー環境では、従来の楕円曲線暗号と新しいPQC（ML-KEMなど）を組み合わせ、万一どちらか一方に未知の脆弱性が見つかっても安全性を保てる「ハイブリッド方式」の導入が進められています。

---

よくある疑問への回答（FAQ）

Q1. 公開鍵暗号だけで通信データを直接すべて暗号化しないのはなぜですか？

A. 計算コストが非常に高く、通信効率が低下するためです。公開鍵暗号で行う巨大な数値演算は、共通鍵暗号に比べて処理負荷が大きくなります。そのため現代の通信では、公開鍵暗号（鍵合意）を使って高速かつ安全に「共通鍵」を手元で導出し、実際のデータ通信はその共通鍵（AEAD）で行うハイブリッド構造が標準となっています。

Q2. Diffie-Hellman方式で交換される公開値が盗聴されても、本当に秘密は計算できないのですか？

A. 適切な群やパラメータが選定されている限り、計算できません。公開値から秘密の値を逆算するには「離散対数問題」を解く必要がありますが、現代の計算資源では現実的な時間内に解けないように設計されています。ただし、DH方式単体には相手の身元を確かめる機能がないため、中間者攻撃を防ぐにはデジタル署名や証明書による認証が不可欠です。

Q3. Webサイトに「鍵マーク」が付いていれば、そのサイトにクレジットカード情報を入力しても絶対に安全ですか？

A. 絶対に安全とは言えません。鍵マーク（サーバー証明書）が保証しているのは「通信経路が暗号化されており、接続先のドメイン管理サーバーと通信していること」だけであり、そのWebサイトを運営している事業者が誠実であるか（道徳性や信用性）は保証していません。詐欺サイトであっても証明書を取得してHTTPS化することは可能なため、運営元の信頼性を別途確認することが不可欠です。

---

結び

公開鍵暗号の真の革新性は、単にデータを秘匿することではなく、「見知らぬ二者が、盗聴者の存在する開かれたネットワーク上で、安全に共通の秘密を作り出せること」にありました。

相手の公開鍵で直接暗号化する古典的なイメージにとどまらず、「鍵合意」によって一時的な共有秘密を確立し、「デジタル署名」によって中間者攻撃を排除し、「鍵導出関数」によって強固な共通鍵を仕立て上げる――この精巧な連係プレーこそが、現代のWeb社会の安全を支える基盤です。

そして現在、耐量子暗号（PQC）の標準化によって、暗号技術は次の時代へ向けた新たな段階に入っています。それぞれの技術の役割と客観的な前提条件を正しく理解しておくことは、情報社会を安全に見通すための確かな基盤となるはずです。

---