暗号の歴史を振り返ると、人類はかなり昔から「読まれない通信」を工夫してきました。文字を別の文字に置き換え、対応表を秘密にし、やがて複雑な暗号機を使うようになります。それでも、インターネットで使える安全な通信がすぐに実現したわけではありません。
通信内容を暗号化するには鍵が必要です。では、その鍵を離れた相手へどうやって渡すのでしょうか。鍵を共有できたとして、通信している相手が本物だとどう確認するのでしょうか。途中で内容を書き換えられていないことは、何を使って確かめればよいのでしょうか。
これらは、暗号化だけでは解決できない別々の問題です。現在のTLSは、長い歴史の中で生まれた共通鍵暗号、公開鍵暗号技術、ハッシュ関数、デジタル署名を組み合わせ、さらに安全な乱数を土台として通信を守っています。
前回の記事「SSL/TLSとは？ HTTPSの暗号化・証明書・ハンドシェイクをやさしく解説」では、TLSが機密性・完全性・真正性を提供することを説明しました。今回は「なぜ複数の技術が必要なのか」を、技術が生まれた順序と、そこで解決しようとした問題から見ていきます。
先に見る：TLSを支える暗号技術の役割
この記事に登場する技術を、現在のTLSにおける役割で整理すると次のようになります。
| 技術 | 得意なこと | TLSでの主な役割 |
|---|---|---|
| 共通鍵暗号 | 大量のデータを高速に保護する | HTTPのリクエストやレスポンスを保護する |
| 公開鍵暗号技術 | 異なる役割の鍵を使う | 事前に秘密を共有していない相手との鍵共有や認証を支える |
| ハッシュ関数 | データの内容に対応する、実用上ほぼ固有の固定長の値を作る | 署名、通信内容の確認、用途別の鍵の作成を支える |
| デジタル署名 | 秘密鍵の所有とデータの真正性を示す | 証明書とハンドシェイクを検証する |
そして、この4つを安全に動かす共通の基盤が予測困難な乱数です。乱数は暗号化や署名のように一つの目的を直接実現する方式ではありませんが、秘密鍵や接続ごとの一時的な秘密値を作るために欠かせません。
暗号の出発点：あらかじめ同じ秘密を持つ
共通鍵暗号の基本的な発想は、公開鍵暗号よりはるかに古いものです。古代の換字式暗号から、軍事や外交で使われた暗号表、20世紀の暗号機まで、多くの暗号通信は「送信者と受信者が、あらかじめ同じ秘密を知っている」ことを前提としていました。
もちろん、古代の暗号と現代のAESを技術的に同じものとして扱うことはできません。それでも、同じ鍵や設定を使って暗号化と復号を行うという考え方は、現代の共通鍵暗号にもつながっています。
共通鍵暗号の長所は速さです。現在のTLSでも、Webページ、画像、Cookie、フォームの入力内容など、実際の通信データを守る主役は共通鍵暗号です。TLS 1.3では、AES-GCMやChaCha20-Poly1305といった、内容を隠すと同時に不正な変更も検出できる認証付き暗号が使われます。
共通鍵暗号は過去の技術ではありません。
公開鍵暗号技術が登場した後も、大量の通信を効率よく保護するという重要な役割を担っています。
エニグマの鍵設定表と、ワンタイムパッドの乱数表
第二次世界大戦でドイツ軍が使用したエニグマ暗号機では、ローターの選択や順序、開始位置、プラグボードの接続などが暗号の設定になります。送信側と受信側は、日ごとの設定を記載した鍵設定表を共有し、それに従って暗号機を操作しました。
この鍵設定表は、ワンタイムパッドで使われる「乱数表」と同じものではありません。ワンタイムパッドは、予測できないランダムな文字列や数列を平文と同じ長さだけ用意し、一度使った部分を二度と使わない暗号です。鍵が本当にランダムで、秘密に保たれ、再利用されないなどの条件を満たせば、理論上解読できないことが知られています。
両者に共通するのは、暗号機や暗号方式だけで通信できるわけではなく、鍵となる情報をあらかじめ作成し、安全に配布しなければならなかったことです。鍵資料を持った使者が捕まったり、保管場所から盗まれたり、同じ鍵を誤って再利用したりすれば、強力な暗号も安全ではなくなります。
エニグマの解読も「乱数が弱かった」という一つの理由だけで説明できません。機械の構造、通信手順、定型的な表現、操作者の癖、入手された資料、ポーランドや英国をはじめとする暗号解読者の研究などが重なった結果です。ここから得られる教訓は、暗号の安全性がアルゴリズム単体ではなく、鍵の生成・配布・使用・廃棄を含むシステム全体で決まることです。
最初の難問：その鍵をどうやって相手へ渡すのか
共通鍵暗号で通信するには、双方が同じ秘密鍵を持っていなければなりません。しかし、安全な通信を始めるための鍵を送ろうにも、その時点ではまだ安全な通信路がありません。暗号学では、これを鍵配送問題と呼びます。
公開鍵暗号技術が登場する以前は、信頼できる使者が鍵資料を運ぶ、当事者が直接会って共有する、専用の安全な経路を使う、組織の中央で鍵を管理するといった方法が取られていました。1976年に発表されたDiffieとHellmanの論文でも、当時の鍵は私的な使者や書留郵便などの安全な経路で先に送る必要があり、その費用と遅延が大規模な通信ネットワークの障害になると指摘されています。
2人だけの通信なら、事前に一つの鍵を共有できるかもしれません。しかし利用者が増え、誰と誰が通信するかを事前に決められなくなると、鍵の組み合わせと管理の負担は急速に大きくなります。初めて訪れるWebサイトすべてから、あらかじめ秘密鍵を手渡ししてもらうことはできません。インターネットは、この古くからの問題を無視できない規模にしました。
公開鍵暗号技術：事前に秘密を共有しないという発想
1976年、Whitfield DiffieとMartin Hellmanは「New Directions in Cryptography」を発表しました。論文が扱った大きな課題は、安全な鍵配送経路への依存を減らすことと、紙の署名に相当する仕組みをデジタル通信に持ち込むことでした。
ここでいう公開鍵暗号技術は、公開鍵と秘密鍵の非対称な性質を利用する技術の総称です。暗号化・復号だけでなく、鍵共有やデジタル署名も含めて扱います。
公開鍵暗号技術では、外部へ公開できる情報と、本人だけが守る秘密の情報を分けて扱います。その発想により、二者が秘密そのものを送らなくても、公開してよい情報を交換して同じ共有秘密を計算する道が開かれました。
現在の一般的なTLS 1.3の接続では、楕円曲線を利用したDiffie-Hellman鍵共有であるECDHEなどが使われます。クライアントとサーバーは、それぞれが接続ごとに作った秘密値を外へ出さず、対応する公開値だけを交換します。そして、自分の秘密値と相手の公開値から、双方が同じ共有秘密を計算します。
ここで大切なのは、「公開鍵で共通鍵を暗号化して送っている」とだけ理解しないことです。過去のTLSではRSAで秘密を暗号化して送る方式も使われましたが、現在のTLS 1.3では、公開値を交換して同じ秘密をそれぞれが導き出す方式が中心です。
接続ごとに一時的な秘密値を作り、利用後に破棄することにも意味があります。後日サーバーの長期的な秘密鍵が漏えいしても、保存されていた過去の通信まで一括して復号されにくくする前方秘匿性につながるからです。
ただし、公開鍵を利用する処理は、共通鍵暗号より計算負荷が大きくなります。そこでTLSは、公開鍵暗号技術で安全な通信を始め、実際の大量のデータは高速な共通鍵暗号で守るという役割分担を採用しています。
暗号化できても、相手が本物とは限らない
鍵配送の問題を解決すれば、それで安全な通信が完成するのでしょうか。実は、まだ重要な問題が残っています。鍵共有だけでは、公開値を交換している相手が誰なのかを確認できないからです。
攻撃者が途中に入り、利用者とサーバーの双方に別々の公開値を示したとします。利用者は攻撃者と、攻撃者は本物のサーバーと、それぞれ暗号化された通信路を作れてしまいます。攻撃者は一方から届いた内容を復号し、読み取ったり書き換えたりしてから、もう一方へ暗号化して送り直せます。これが中間者攻撃です。
暗号化されていることと、正しい相手と暗号化通信していることは同じではありません。
インターネットで安全な通信を作るには、機密性だけでなく、相手を確かめる真正性が必要です。そこで公開鍵暗号技術から生まれた、もう一つの重要な仕組みが使われます。
デジタル署名：相手とデータを確かめる
デジタル署名では、秘密鍵を持つ側がデータに対する署名を作り、対応する公開鍵を持つ側がそれを検証します。署名が正しく検証できれば、対応する秘密鍵で作られたことと、署名対象のデータがその後変更されていないことを確認できます。
署名の目的は、通信内容を秘密にすることではありません。また、「秘密鍵で暗号化し、公開鍵で復号するのが署名」と説明されることがありますが、これは署名方式全般を正しく表す説明ではありません。暗号化と署名は、目的も処理も分けて考える必要があります。
TLSでは、サーバーが証明書を提示し、その証明書の公開鍵に対応する秘密鍵を持っていることを、ハンドシェイクへの署名で示します。ブラウザは認証局の署名をたどって証明書を検証し、アクセス先の名前と公開鍵の結び付きを確認します。
ここにも役割分担があります。デジタル署名は「この秘密鍵で署名された」ということを示せますが、公開鍵だけを見ても、その所有者の名前までは分かりません。証明書と認証局を含むPKI（Public Key Infrastructure：公開鍵基盤）が、公開鍵とドメイン名などの識別情報を結び付けます。この仕組みは、後続の証明書チェーンの記事で詳しく扱います。
ハッシュ関数：暗号化せずにデータの変化を捉える
ハッシュ関数は、任意の長さのデータから、その内容に対応する実用上ほぼ固有の固定長の値を作る技術です。同じデータからは同じハッシュ値が得られますが、データが一文字でも変われば、通常は全く別のハッシュ値になります。そのため、ハッシュ値はデータごとの「指紋」のように変化を捉えられます。暗号化とは異なり、ハッシュ値から元のデータへ戻す「復号」はありません。
大きなデータそのものを署名処理へ直接渡すのではなく、まずハッシュ値を計算して署名に利用すれば、効率よくデータ全体を確認できます。TLSではこのほか、ハンドシェイクで交換したメッセージ全体の確認や、一つの共有秘密から用途ごとに異なる鍵を作る処理にも、ハッシュ関数の性質が利用されています。
ただし、ハッシュ値を添えただけで改ざんを防げるわけではありません。通常のハッシュは誰でも計算できるため、攻撃者がデータとハッシュ値の両方を書き換えられるなら、変更後のハッシュ値も作れてしまいます。相手やデータを確かめるには、デジタル署名、秘密鍵を使う認証コード、認証付き暗号などとの組み合わせが必要です。
MD5やSHA-1が役割を終えた理由
異なるデータから同じハッシュ値が得られることを「衝突」と呼びます。MD5やSHA-1は、単に古くなったからではなく、衝突を現実的に作り出す攻撃が進歩し、デジタル署名などの用途で必要な安全性を満たせなくなりました。
これは、暗号技術の評価が永遠に固定されるものではないことを示す例です。計算能力と攻撃技術の進歩に応じて、安全な方式や鍵長を見直せる設計と運用が必要になります。
乱数：すべての技術を足元から支える
ここまでの4つに横断的に関係するのが乱数です。秘密鍵が誰にでも予想できる値なら、どれほど優れた暗号方式を選んでも安全にはなりません。暗号で重要なのは、見た目がばらばらであることだけでなく、攻撃者が次の値や内部状態を現実的に予測できないことです。
現代のコンピューターでは、OSや暗号ライブラリが提供する暗号学的に安全な擬似乱数生成器を利用します。外部から得た予測困難な情報を種にして、暗号用途に使える値を生成する仕組みです。自分で思い付いた計算式や、ゲームなどで使う一般的な疑似乱数を秘密鍵の生成に流用してはいけません。
TLSでは、公開されるClientHelloとServerHelloのランダム値だけでなく、秘密鍵や一時的な鍵材料の生成にも安全な乱数が必要です。乱数生成器が壊れて内部状態を推測されると、公開された出力を手掛かりに、秘密の値まで予測されるおそれがあります。
なお、TLS 1.3の通信用鍵は「乱数をそのまま鍵として使う」わけではありません。鍵共有で得た秘密、ハンドシェイク全体のハッシュ、その鍵を何に使うのかを示す情報などを専用の処理に入力し、クライアントからサーバーへ送る鍵、反対方向の鍵、ハンドシェイクを守る鍵、HTTP通信を守る鍵というように、役割の異なる値を段階的に作ります。
乱数は、その出発点となる秘密を予測困難にします。ハッシュ関数を利用した鍵生成の処理は、その秘密と通信の文脈を混ぜ合わせ、用途ごとの鍵へ展開します。この二つは密接に関係しますが、同じ役割ではありません。
また、暗号で使う付加的な値には「予測できないこと」が必要なものと、「同じ鍵の下で二度使わないこと」が特に重要なものがあります。何でも乱数にすればよいわけではありません。この違いと、安全な乱数がどのように作られるかは、別の記事で詳しく取り上げます。
TLS 1.3では、技術がどう協力するのか
歴史の中で現れた問題と解決策を、現在のTLS 1.3へ戻してみましょう。証明書を使う一般的なフルハンドシェイクを大きく簡略化すると、次のように整理できます。
- 通信条件と公開値を交換する
クライアントとサーバーが、対応する方式や鍵共有に必要な公開値を交換します。 - 共有秘密を確立する
接続ごとに作った予測困難な秘密値と、相手から受け取った公開値を使い、双方が同じ共有秘密を計算します。 - 証明書とデジタル署名でサーバーを確認する
ブラウザは証明書のつながりと名前を検証します。さらに、サーバーが証明書の公開鍵に対応する秘密鍵を持ち、今回のハンドシェイクに署名したことを確認します。 - 用途別の鍵を作る
共有秘密、ハンドシェイク全体のハッシュ、用途を示す情報などから、方向と目的の異なる複数の鍵を段階的に作ります。 - 共通鍵による認証付き暗号で通信する
作成した通信用鍵を使い、HTTPのリクエストとレスポンスを高速に暗号化し、不正な変更も検出します。
実際のハンドシェイクでは、これらの処理は単純な一直線ではなく、互いのメッセージを確認しながら進みます。それでも、各技術の役割を分けて見ると、TLSが一つの万能な暗号で動いているのではないことが分かります。
よくある誤解
公開鍵暗号の方が高度なら、全部それで暗号化すればよいのでは？
公開鍵を利用する処理は計算負荷が大きく、大量のデータ処理には向きません。TLSでは、鍵共有や認証を公開鍵暗号技術が支え、実際の通信は高速な共通鍵暗号が守ります。新旧や優劣ではなく、得意分野の違いです。
ハッシュ化すれば秘密を安全に保存できますか？
ハッシュは暗号化ではなく、それだけで秘密を守る機能もありません。特にパスワードの保存には、単純なハッシュではなく、ソルトとパスワード保存専用に設計された方式が必要です。
デジタル署名があれば内容も秘密になりますか？
署名の目的は、秘密鍵の所有とデータの真正性を確認することです。内容を読ませない機密性は、共通鍵暗号など別の仕組みで確保します。
証明書が正しければ、そのWebサイトは信用できますか？
証明書は、ドメイン名などの識別情報と公開鍵の結び付きを検証する材料です。そのサイトの内容、取引条件、運営者の善良性まで保証するものではありません。
まとめ：暗号の歴史は「暗号化だけでは足りない」と分かった歴史
共通鍵暗号の基本的な発想は古くからあり、現在も大量の通信を守る主役です。しかし、インターネットでは通信相手すべてに秘密鍵を手渡しできません。公開鍵暗号技術は、事前に秘密を共有していない相手と共有秘密を確立する道を開きました。
それでも、暗号化している相手が本物かどうかは別問題です。デジタル署名と証明書が相手を確かめ、ハッシュ関数が署名、ハンドシェイクの確認、用途別の鍵作りを支えます。そして、それらの出発点となる秘密を予測困難にするのが、安全な乱数です。
- 共通鍵暗号：実際の通信を高速に守る
- 公開鍵暗号技術：事前に秘密を共有していない相手との通信開始を支える
- ハッシュ関数：データの確認と用途別の鍵作りを支える
- デジタル署名：秘密鍵の所有とデータの真正性を確認する
- 安全な乱数：予測困難な秘密値を作り、すべての技術を足元から支える
TLSが複雑に見えるのは、余計な仕組みを詰め込んでいるからではありません。内容を隠す、秘密を確立する、相手を確かめる、変更を検出するという別々の問題に、それぞれ適した技術で答えているからです。その役割分担が見えると、TLSのハンドシェイクや暗号スイートも、難しい用語の列ではなく一つのチームとして理解できるようになります。
次は、公開鍵とドメイン名をどのように結び付け、ブラウザがどのように信頼をたどるのかを、「証明書チェーン」の仕組みから見ていきます。乱数の作り方と、乱数生成の失敗が暗号全体を崩す理由も、今後の記事で改めて掘り下げます。
SSL/TLSを体系的に学びたい方へ
この記事では、暗号技術が必要になった理由とTLSでの役割分担に焦点を当てました。拙著『SSL/TLS実践入門――Webの安全性を支える暗号化技術の設計思想』では、共通鍵暗号、公開鍵暗号、ハッシュ関数、デジタル署名、乱数と鍵生成を含む暗号技術を、アルゴリズムとプロトコルの両面から体系的に解説しています。
主な確認資料
- RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
- Whitfield Diffie and Martin E. Hellman, “New Directions in Cryptography”
- NIST FIPS 197: Advanced Encryption Standard (AES)
- 大江将史・板倉広明『SSL/TLS実践入門――Webの安全性を支える暗号化技術の設計思想』（技術評論社、2024年）
最終技術確認：2026年10月。TLS 1.3の記述はRFC 9846を主な確認先としています。歴史的な説明は、技術の因果関係を理解するために簡略化しています。
コメント