U「https://」のサイトは安全って知っていても、なぜ安全なのかは曖昧でした。公開鍵・秘密鍵・認証局——これらがどう組み合わさって「盗聴されない・改ざんを検知できる・なりすましを防ぐ」を実現しているのか、整理してみました。
この記事でわかること
- 共通鍵暗号と公開鍵暗号の違い・使い分け
- ハッシュ関数の役割とメッセージ認証への応用
- デジタル署名の仕組み（改ざん検知・なりすまし防止）
- PKI（公開鍵基盤）と認証局（CA）の役割
- SSL/TLSの仕組みとHTTPSの安全性
目次
暗号化の2方式——共通鍵と公開鍵
| 方式 | 鍵の構成 | 特徴 | 代表アルゴリズム | 用途 |
|---|---|---|---|---|
| 共通鍵暗号 | 暗号化と復号に同じ鍵を使用 | 処理が速い。鍵の配送問題あり（相手に安全に鍵を渡す方法が課題） | AES・DES・3DES | 大量データの暗号化（本文の暗号化） |
| 公開鍵暗号 | 公開鍵（暗号化）と秘密鍵（復号）のペア | 鍵配送問題を解決。処理が遅い | RSA・楕円曲線暗号 | 鍵交換・デジタル署名 |
| ハイブリッド暗号 | 両方を組み合わせる | 公開鍵で共通鍵を交換→共通鍵で本文を暗号化。SSL/TLSで採用 | SSL/TLS | HTTPS通信 |
ハッシュ関数とデジタル署名の仕組み
ハッシュ関数とは
任意の長さのデータを固定長のハッシュ値（ダイジェスト）に変換する関数。特徴：① 同じデータからは必ず同じハッシュ値 ② ハッシュ値から元データを復元不可（一方向性） ③ データを1ビット変えるだけでハッシュ値が大きく変わる（雪崩効果）
代表例：SHA-256（256ビットのハッシュ値生成）・MD5（128ビット・現在は脆弱性あり）
活用例：パスワードのハッシュ保存・ダウンロードファイルの改ざん検知・デジタル署名
デジタル署名の仕組み（3つの目的を同時に達成）
- ① 送信者がハッシュ値を計算：メッセージのハッシュ値を算出
- ② 送信者の秘密鍵でハッシュ値を暗号化→「デジタル署名」が完成
- ③ 受信者が送信者の公開鍵で署名を復号→ハッシュ値を取り出す
- ④ 受信者がメッセージのハッシュ値を計算して③と比較
- 一致すれば：改ざんなし（ハッシュ値の一致）かつ送信者の本人確認（秘密鍵は本人しか持っていない）
PKI——公開鍵の正当性を保証する仕組み
PKI（Public Key Infrastructure：公開鍵基盤）
「この公開鍵は本当にその人のものか？」を証明するのがPKI。認証局（CA：Certificate Authority）：公開鍵と本人の対応を証明する第三者機関。デジタル証明書を発行する。
デジタル証明書（電子証明書）：「この公開鍵は○○に属する」ことをCAが署名した証明書。ブラウザはOSに組み込まれた信頼できるCAの証明書と照合して検証。
証明書失効：盗難・漏洩が発生した証明書を無効にする仕組み。CRL（証明書失効リスト）またはOCSPで確認。
SSL/TLSとHTTPS——Webの安全通信
| 項目 | 内容 |
|---|---|
| SSL/TLS | Webブラウザとサーバー間の通信を暗号化するプロトコル。SSLは旧称、現在はTLS（TLS 1.3が最新） |
| HTTPS | HTTPにTLSを組み合わせた安全な通信（HTTP over TLS）。URLが「https://」で始まる |
| TLSハンドシェイク | ①サーバー証明書を送付→②クライアントがCAで検証→③共通鍵を公開鍵で暗号化して交換→④以降は共通鍵で高速通信 |
| サーバー証明書 | サーバーの公開鍵をCAが署名した証明書。ブラウザがサイトの正当性を確認するために使用 |
Uのメモ
学習メモ
- 共通鍵：速い・鍵配送問題あり / 公開鍵：遅い・鍵配送問題解決 / ハイブリッド：両方の良いとこ取り
- ハッシュ関数：一方向変換・改ざん検知（SHA-256が現在の標準）
- デジタル署名：秘密鍵で署名→公開鍵で検証→改ざん検知＋本人確認を同時達成
- PKI：CAが「この公開鍵は本物」とデジタル証明書で保証する仕組み
- HTTPS：TLSで暗号化＋サーバー証明書で正当性確認→盗聴・改ざん・なりすまし防止
