なぜ「暗号化」が必要なの？
ネットで送ったデータは、Wi-Fi や通信会社などたくさんの『他人の設備』を経由して届きます。そのまま（平文）では途中で覗き見されるため、手紙を封筒に入れるように鍵で封をします。残る問いは、封をする鍵そのものを初対面の相手とどう共有するか、です。
暗号化のしくみ ── 鍵の受け渡しから保存まで
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「暗号化のしくみ（公開鍵・証明書・保管時）」。参加者4人、ステップ12個。 【参加者】（左から右） - あなた: ブラウザ - Webサーバ: https:// の接続先 - 認証局: 信頼の第三者（CA） - 保管庫: サーバのDB 【流れ】（上から下へ） ── ① 事前準備：サーバが証明書を用意（あなたが来る前） ── 1. Webサーバ → 認証局: 公開鍵を提出し本人確認を申請 2. 認証局 → Webサーバ: 証明書を発行（公開鍵に署名）（応答） ── ② 接続：鍵交換と本人確認 ── 3. あなた → Webサーバ: https:// で安全に話したいと接続 4. Webサーバ → あなた: 公開鍵（＋証明書）を渡す（応答） 5. あなた（自身で処理）: 証明書を検証（本物のサイトか確認） 6. あなた（自身で処理）: この通信専用の「共通鍵」を作る 7. あなた → Webサーバ: 共通鍵を「公開鍵で施錠」して送る 8. Webサーバ（自身で処理）: 秘密鍵で開ける ── ③ 本番の通信（以後ずっと・共通鍵） ── （ページを開くたび繰り返し の枠） 9. あなた → Webサーバ: 共通鍵で暗号化して送信 10. Webサーバ → あなた: 共通鍵で暗号化して返信（応答） ── ④ 保存：しまう間も暗号化（保管時暗号化） ── 11. Webサーバ → 保管庫: 別の鍵で暗号化して保存 12. 保管庫 → Webサーバ: 暗号文のまま保管（応答）
鍵マークと「相手が本物か」は別の話
鍵マーク（HTTPS）は『中身が暗号化されている』ことを示すだけで、『相手が本物のサイトか』は保証しません。偽サイトでも HTTPS は使えます。ドメイン名が正しいかは必ず自分の目で確認しましょう。
押さえておきたい用語
- 平文・暗号文
- 公開鍵と秘密鍵（公開鍵暗号）
- 共通鍵
- 証明書・認証局（CA）
- HTTPS / TLS
- 保管時暗号化（at-rest）