「共通鍵暗号は速いけど鍵の配送が大変。公開鍵暗号は安全だけど処理が重い。ハッシュ関数は改ざん検知に使えて、デジタル署名は本人確認に…」
これまでの連載で学んできた暗号技術。一つひとつは理解できても、実際のインターネットでどう使われているのか、イメージできていますか?
実は、あなたが今この記事を読んでいるまさにこの瞬間も、学んできたすべての技術が見事に連携して、通信の安全を守っています。
今回は第2週目の総復習として、HTTPS通信という「現場」で、バラバラに見えた技術たちがどう協力し合っているのかを、一本の線でつなげていきます。
「点」だった知識が「線」になり、やがて「面」として理解できる。その瞬間を、ぜひ体験してください。
この記事を読み終える頃には、ブラウザのアドレスバーに表示される小さな鍵マークの裏側で、どれほど精巧な仕組みが動いているか、手に取るように分かるはずです。
1. HTTPS通信の全体像(安全な接続が確立されるまで)
なぜ「準備」がこれほど重要なのか
Webブラウザで「鍵マーク」が付いたサイト(https://〜)にアクセスする時、実はページが表示される前に、水面下で壮大な「準備作業」が行われています。
この準備作業こそが「ハンドシェイク(握手)」です。
いきなり本題のデータをやり取りするのではなく、まず「本当に信頼できる相手なのか」「どうやって安全に通信するか」を確認し合う。この慎重さが、インターネットの安全を支えているのです。
そして、このハンドシェイクの中に、これまで学んだ暗号技術のすべてが凝縮されています。
全体は3つのステップで進む
HTTPS通信の流れは、大きく分けて以下の3ステップです。
- 接続確立(挨拶と暗号方式の相談)
- サーバー認証と鍵交換(信頼確認と共通鍵の準備) ←ここが最重要!
- 暗号化通信開始(データのやり取り)
それぞれのステップで、異なる暗号技術が登場します。順を追って見ていきましょう。
ステップ1 : 接続確立(挨拶と暗号方式の相談)
まず、ブラウザ(クライアント)がWebサーバーに「安全に通信したいです」と声をかけます。
この時、お互いに「自分はこんな暗号技術に対応していますよ」とリストを見せ合い、共通して使える最も安全な方式を選びます。
たとえば、「共通鍵暗号はAES、公開鍵暗号はRSA、ハッシュ関数はSHA-256で行きましょう」といった具合です。
このステップ自体はまだ暗号化されていません。あくまで「これから安全な通信をするための打ち合わせ」です。
ステップ2 : サーバー認証と鍵交換(信頼の確認と共通鍵の準備)
ここからが本番です。HTTPS通信の核心部分であり、これまで学んだすべての技術が総動員される場面です。
このステップの目的は2つあります。
- 相手が本物のサーバーかどうか確認する(認証)
- これから使う共通鍵を安全に共有する(鍵交換)
具体的な流れを見ていきましょう。
(1) 証明書の提示
サーバーは、自分の身分を証明するため「サーバー証明書(電子証明書)」をブラウザに送ります。
これは、いわばサーバーの身分証明書です。「私は本物の○○サイトのサーバーです」という主張が書かれています。
(2) 証明書の検証(PKI・デジタル署名・ハッシュ関数が活躍)
ブラウザは、送られてきた証明書が本物かどうかを検証します。ここでPKI(公開鍵基盤)の仕組みが登場します。
証明書には、信頼できる第三者機関である認証局(CA)のデジタル署名が付いています。
ブラウザは、あらかじめ持っているCAの公開鍵を使って、このデジタル署名を検証します。検証の過程ではハッシュ関数も使われ、証明書が改ざんされていないことを確認します。
検証に成功すれば、「この証明書は信頼できるCAが発行した本物で、内容も改ざんされていない」ことが保証されます。
(3) サーバーの公開鍵を取り出す
証明書が本物だと分かったら、その中に含まれているサーバーの公開鍵を取り出します。
この公開鍵が、次のステップで重要な役割を果たします。
(4) 共通鍵の元を安全に送る(公開鍵暗号が活躍)
ブラウザは、これからの通信で使う「共通鍵の元(プレマスターシークレット)」を自分で生成します。
この「共通鍵の元」をサーバーに送る必要がありますが、そのままでは盗聴される危険があります。
そこで、先ほど取り出したサーバーの公開鍵で暗号化して送ります。
公開鍵で暗号化されたデータは、対応する秘密鍵を持つサーバーしか復号できません。盗聴者が途中で傍受しても、解読は不可能です。
(5) 共通鍵の生成(鍵管理と共通鍵暗号)
サーバーは、自分だけが持つ秘密鍵を使って、送られてきたデータを復号し、「共通鍵の元」を取り出します。
ここで鍵管理の重要性が浮き彫りになります。もしサーバーの秘密鍵が盗まれていたら、攻撃者も同じように復号できてしまうからです。
無事に「共通鍵の元」を共有できたら、お互いにそれを元に実際の通信で使う共通鍵(セッション鍵)を生成します。
ステップ3 : 暗号化通信開始(高速で安全なやり取り)
長い準備が終わり、ようやく本題のデータ通信が始まります。
ここからは、先ほど共有した共通鍵を使って、すべてのデータを暗号化してやり取りします。
共通鍵暗号が本領を発揮
WebページのHTML、CSS、JavaScript、画像など、すべてのデータが共通鍵暗号(AESなど)で暗号化されます。
共通鍵暗号は処理が速いため、大量のデータを快適にやり取りできます。これが、公開鍵暗号だけでなくハイブリッド暗号方式を使う理由です。
ハッシュ関数がデータの完全性を守る
さらに、通信データにはメッセージ認証コード(MAC)が付加されます。
これは、データと共通鍵を元にハッシュ関数で生成されるもので、途中でデータが改ざんされていないかを検証できます。
登場した技術のおさらい
各技術が果たした役割を振り返る
HTTPSのフローを通じて、それぞれの暗号技術がどこでどう使われていたか、改めて整理しましょう。
ここでは、単なる復習にとどまらず、なぜその技術がその場面で使われるのか、他の技術では代替できないのかという視点も加えて深掘りしていきます。
共通鍵暗号と公開鍵暗号:絶妙な役割分担
共通鍵暗号が「本番」を支える理由
共通鍵暗号(AES、ChaCha20など)は、大量のデータを高速に暗号化する「実働部隊」です。
WebページのHTML、CSS、JavaScript、画像、動画など、私たちが日常的にやり取りするデータは膨大です。これらすべてを暗号化するには、処理速度が命です。
共通鍵暗号は、同じ鍵で暗号化も復号もできるシンプルな仕組みのため、処理が非常に高速です。動画のストリーミングのようなリアルタイム性が求められる場面でも、ストレスなく通信できるのはこの速度があるからです。
しかし、共通鍵暗号には致命的な弱点がありました。それが「鍵配送問題」です。
暗号化に使う鍵と復号に使う鍵が同じため、事前に相手と同じ鍵を共有しておく必要があります。インターネット越しに初対面の相手と通信する場合、どうやって安全に鍵を渡せばいいのでしょうか?
公開鍵暗号が「準備」を可能にする
ここで登場するのが公開鍵暗号(RSA、ECDHEなど)です。
公開鍵暗号の最大の特徴は、暗号化に使う鍵(公開鍵)と復号に使う鍵(秘密鍵)が別であることです。
公開鍵は誰に知られても問題ありません。むしろ、広く公開することが前提です。一方、秘密鍵は本人だけが厳重に管理します。
この仕組みを使えば、「共通鍵の元」を公開鍵で暗号化して送ることで、盗聴者がいても安全に鍵を共有できます。公開鍵で暗号化されたデータは、対応する秘密鍵を持つ相手しか復号できないからです。
ただし、公開鍵暗号には処理が重いという欠点があります。複雑な数学的計算(素因数分解や楕円曲線の演算)を必要とするため、大量のデータを暗号化するには向きません。
ハイブリッド暗号方式 : 両者の良いとこ取り
そこで、HTTPS通信ではハイブリッド暗号方式を採用しています。
- 公開鍵暗号で共通鍵を安全に交換する(準備段階)
- 共通鍵暗号で実際のデータを高速に暗号化する(本番)
この組み合わせにより、安全性と速度の両立が実現されているのです。
それぞれの技術が持つ長所を活かし、短所を補い合う。この絶妙なバランスこそが、インターネット通信の快適さと安全性を支えています。
PKI・デジタル署名・ハッシュ関数:信頼を築く三本柱
共通鍵を安全に交換できても、もう一つ大きな問題が残っています。
「相手が本当に正規のサーバーなのか」という問題です。
攻撃者が正規のサーバーになりすまし、偽の公開鍵を送ってきたらどうなるでしょうか? ブラウザは気づかずに共通鍵を暗号化して送ってしまい、攻撃者はそれを復号できてしまいます。
これを防ぐのが、PKI(公開鍵基盤)を中心とした信頼の仕組みです。
ハッシュ関数:改ざんを見抜く「指紋」
ハッシュ関数(SHA-256など)は、どんなデータからも固定長の「ハッシュ値」を生成する関数です。
ハッシュ値には重要な特性があります。
- 元のデータが1ビットでも変わると、ハッシュ値は全く別のものになる
- ハッシュ値から元のデータを復元することは事実上不可能
- 同じハッシュ値を持つ別のデータを作ることは事実上不可能
この特性により、ハッシュ値はデータの「指紋」として機能します。
HTTPS通信では、証明書の検証時や通信データの完全性確認(MAC)など、様々な場面でハッシュ関数が活躍します。
デジタル署名:信頼できる「実印」
デジタル署名は、ハッシュ関数と秘密鍵を組み合わせて作る「デジタルの実印」です。
仕組みはこうです。
- 証明書のハッシュ値を計算する
- そのハッシュ値を認証局(CA)の秘密鍵で暗号化する
- これがデジタル署名となり、証明書に添付される
署名を検証する側(ブラウザ)は、次のように確認します。
- 証明書から署名を取り出し、CAの公開鍵で復号する
- 証明書本体のハッシュ値を自分で計算する
- 両方が一致すれば、「この証明書はCAが署名した本物で、改ざんされていない」と確認できる
もし証明書が改ざんされていたら、ハッシュ値が一致しないため、すぐに検知できます。
PKI:信頼を社会システムとして実装する
では、ブラウザはどうやってCAの公開鍵を入手するのでしょうか?
ここでPKI(公開鍵基盤)という社会的な仕組みが登場します。
PKIは、証明書の発行、管理、検証に関わるすべての要素を包括する概念です。
- 認証局(CA) : 証明書を発行し、デジタル署名を付与する信頼できる第三者機関
- ルート証明書 : CAの公開鍵を含む証明書。ブラウザやOSにあらかじめインストールされている
- 証明書失効リスト(CRL) : 危殆化した証明書のリスト
- OCSP : 証明書の有効性をリアルタイムで確認する仕組み
ブラウザは出荷時点で、世界的に信頼されている主要なCAのルート証明書を持っています。これにより、初対面のWebサイトでも、CAの公開鍵を使って証明書を検証できるのです。
この「信頼の連鎖」により、インターネット全体で一貫した認証の仕組みが実現されています。
鍵管理:すべてを支える見えない土台
ここまで見てきた精巧な仕組みも、たった一つの要素が崩れると全てが台無しになります。
それがサーバーの秘密鍵の漏洩です。
秘密鍵が盗まれると何が起きるか
もしサーバーの秘密鍵が攻撃者の手に渡ったら、次のような事態が発生します。
- なりすまし : 攻撃者は正規のサーバーになりすまし、ユーザーから送られてくる共通鍵の元を復号できる
- 盗聴 : 過去の通信も遡って復号される可能性がある(Perfect Forward Secrecyが実装されていない場合)
- 中間者攻撃 : ユーザーと正規サーバーの間に入り込み、両者の通信を傍受・改ざんできる
つまり、暗号化も認証も、すべて無意味になってしまうのです。
鍵管理の実践
そのため、秘密鍵の管理には厳重な対策が求められます。
- 物理的な隔離 : 秘密鍵を専用のハードウェア(HSM: Hardware Security Module)に保管し、外部からアクセスできないようにする
- アクセス制御 : 秘密鍵にアクセスできる人員を最小限に制限し、操作ログを記録する
- バックアップと冗長化 : 秘密鍵を安全に複製し、災害時にも事業継続できるようにする
- 定期的な更新 : 証明書と秘密鍵を定期的に更新し、万が一の漏洩リスクを時間的に区切る
危殆化への対応
それでも秘密鍵が漏洩してしまった場合、証明書失効(Revocation)という仕組みがあります。
CAに連絡して証明書を失効させると、その証明書は「証明書失効リスト(CRL)」やOCSP(Online Certificate Status Protocol)を通じて無効化され、ブラウザは接続を拒否するようになります。
ただし、この対応には時間がかかることもあり、その間に被害が拡大する可能性もあります。だからこそ、予防としての鍵管理が何よりも重要なのです。
技術はバラバラではなく、一つの生態系
ここまで見てきたように、HTTPS通信を支える暗号技術は、それぞれが独立しているのではなく、相互に依存し、補完し合う生態系を形成しています。
- 共通鍵暗号は速いが、公開鍵暗号がなければ鍵を共有できない
- 公開鍵暗号は安全だが、デジタル署名とPKIがなければ相手を信頼できない
- デジタル署名は強力だが、ハッシュ関数がなければ改ざんを検知できない
- どれほど精巧な仕組みも、鍵管理が不十分なら一瞬で崩壊する
一つでも欠ければ、全体が機能しません。
この「全体像」を理解することが、セキュリティを本質的に学ぶ上で最も重要なポイントなのです。
試験で問われるポイント
「どの鍵で何を暗号化するか」を正確に
情報処理安全確保支援士試験などでは、このHTTPSの流れの中で「どの鍵が何に使われるか」が頻出です。
特に混乱しやすいのが、次の3つのパターンです。
パターン1 : 共通鍵を送る時
- 使う鍵 : サーバーの公開鍵
- 目的 : 暗号化(秘匿)
- ポイント : 公開鍵で暗号化すれば、対応する秘密鍵を持つサーバーしか復号できない
パターン2 : デジタル署名を検証する時
- 使う鍵 : 認証局(CA)の公開鍵
- 目的 : 署名の検証(真正性の確認)
- ポイント : 暗号化ではなく、「本物かどうか」を確かめるための検証
パターン3 : 実際のデータをやり取りする時
- 使う鍵 : 交換した共通鍵
- 目的 : 高速な暗号化・復号
- ポイント : 準備が終わった後の本番の通信では、ずっと共通鍵を使う
処理の順序を押さえる
時系列も重要です。
まず、「証明書の検証」(相手が本物か確認)があって、初めて「共通鍵の交換」(公開鍵暗号を使用)ができます。
そして、鍵交換が終わって初めて「暗号化通信」(共通鍵暗号を使用)が始まります。
この順番を、フロー図とともに頭に入れておきましょう。
学んだ知識を定着させよう
ここまでの内容が理解できたか、簡単なクイズで確認してみましょう。
まとめ
今回は、第1週目の総復習として、これまで学んできた暗号技術がHTTPS通信の中でどのように連携しているかを、一つのフローで整理しました。
- 接続確立、サーバー認証&鍵交換、暗号化通信という3つのステップがある
- PKI、デジタル署名、公開鍵暗号は、通信前の「信頼の確立」と「共通鍵の安全な交換」を担う
- 実際のデータ通信は、高速な共通鍵暗号で行われる(ハイブリッド暗号方式)
- すべての前提として、秘密鍵の適切な鍵管理が不可欠
点と点だった知識が、一本の線でつながったのではないでしょうか。
個々の技術を学んでいる時は「なぜこんな複雑な仕組みが必要なのか」と感じたかもしれません。しかし、こうして全体像を俯瞰すると、それぞれが不可欠な役割を担っていることが分かります。
どれか一つでも欠ければ、インターネットの安全は成り立ちません。
さて、次回からは第3週目に入ります。
今回の解説で「認証局(CA)って実際どんな組織なの?」「誰がどうやって管理しているの?」と疑問を持たれた方もいるでしょう。実は、HTTPSの信頼の根幹を支えるPKIには、知られざる役割分担や、厳格すぎるほどの運用ルールが存在します。次回は、その舞台裏に迫ります。
インターネットの信頼が、どのような仕組みで守られているのか。その答えが、次回明らかになります。