通信と保存の暗号化
「サイトへ送った情報は、途中で誰かに読まれないの？」
通信相手を確かめて暗号化する仕組みと、保存した情報の守り方を見てみましょう。
01疑問
そのまま送って平気？
通信中の情報相手へ送る情報は、途中で読まれないのかな？
02体験
そのままなら読める
平文のままでは暗号化していない情報は、途中でのぞかれるおそれがあるんだ。
03仕組み
相手を確認して守る
証明書と鍵の合意TLSでは相手を確認して鍵を作り、通信を暗号化するんだね。
04納得
運ぶときも保管も
通信と保存を分ける通信を守る仕組みと、保存した情報を守る仕組みは別なんだ。
なぜ「暗号化」が必要なのか
ネットで送ったデータは、Wi-Fi や通信会社などたくさんの『他人の設備』を経由して届きます。そのまま（平文）では途中で覗き見されるため、手紙を封筒に入れるように鍵で封をします。残る問いは、封をする鍵そのものを初対面の相手とどう共有するか、です。
証明書で確認し、鍵交換から通信鍵を作る
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「TLS 1.3のしくみ（証明書・鍵交換・暗号通信）」。参加者4人、ステップ12個。 【参加者】（左から右） - あなた: ブラウザ - Webサーバ: https:// の接続先 - 認証局: 信頼の第三者（CA） - 保管庫: サーバのDB 【流れ】（上から下へ） ── ① 事前準備：サーバが証明書を用意（あなたが来る前） ── 1. Webサーバ → 認証局: 公開鍵とドメインの確認を申請 2. 認証局 → Webサーバ: 証明書を発行（応答） ── ② 接続：鍵交換と本人確認 ── 3. あなた → Webサーバ: 方式と鍵交換用の公開情報を送る 4. Webサーバ → あなた: 方式を選び、鍵交換の公開情報を返す（応答） 5. あなた（自身で処理）: 双方で共有秘密から鍵を導出 6. Webサーバ → あなた: 証明書と接続への署名を送る（応答） 7. あなた（自身で処理）: 証明書と署名を検証 8. あなた → Webサーバ: 接続の検証を完了 ── ③ 本番の通信（以後ずっと・共通鍵） ── （ページを開くたび繰り返し の枠） 9. あなた → Webサーバ: 共通鍵で暗号化して送信 10. Webサーバ → あなた: 共通鍵で暗号化して返信（応答） ── ④ 保存：しまう間も暗号化（保管時暗号化） ── 11. Webサーバ → 保管庫: 別の鍵で暗号化して保存 12. 保管庫 → Webサーバ: 暗号文のまま保管（応答）
送った後のデータは、何が守る？
顧客情報をHTTPSで送ると、通信中のデータは暗号化されます。受け取って保存した後は、保存時の暗号化がディスクやバックアップの持ち出しに備えます。守る場面が違うので、両方を設計します。
この図をテキストで読む
構成図「通信と保存では、守る場所が違う」。ブロック3個、つながり2本。 【ブロック】 - 利用者の端末: 顧客情報を送る - アプリ: 受信して処理する - 保存先: ディスク等へ保存
暗号化されていても、アプリが誤った相手へ復号済みの情報を返せば漏洩します。復号できる権限や鍵を守り、アプリの認可も別に確かめます。
HTTPSなら、相手も安全？
偽サイトも、自分で用意したドメインに対してHTTPSを使えます。HTTPSが確かめるのは接続先ドメインと通信の保護です。そのサイトの内容や、持ちかけられた取引の安全まで保証するものではありません。
たとえばメールで口座情報の変更を求められたら、リンク先がHTTPSかだけを見て手続きを進めません。正規のドメインを確認し、普段使う公式の経路から用件を確かめます。
押さえておきたい用語
- 平文・暗号文
- 公開鍵と秘密鍵（公開鍵暗号）
- 共通鍵
- 証明書・認証局（CA）
- HTTPS / TLS
- 保管時暗号化（at-rest）
『Webのしくみ のまとめ読み』を読み終えました。
Webのしくみ の記事 6 本を、行き来せずひととおり読み終えられます。