ここまでの記事で、データが家からNTTの局舎、ISPを通ってWebサーバに届く道のり（物理）と、IPアドレスやMACアドレスで宛先を決める仕組み（論理）を見てきました。でも、この道(インターネット)は世界中の人が共有している公道です。何も対策をしなければ、途中で中身をのぞかれたり、書き換えられたりするおそれがあります。
この記事では、通信の中身を狙う次の2つの危険を取り上げます。
| 危険 | どんなことが起きるか | たとえ |
|---|---|---|
| 盗聴（盗み見） | 通信の途中で、パスワードやカード番号を読まれる | はがきの文面を配達途中で読まれる |
| 改ざん・なりすまし | 中身を書き換えられたり、偽物のサイトに誘導されたりする | 手紙をすり替えられる、偽の差出人から届く |
これに対する守りが、暗号化（SSL/TLS）と電子署名です。どちらも「公開鍵と秘密鍵」という同じ道具で成り立っているので、2つを並べると鍵の使い方の違いがよく分かります。これまでの通信の流れの図に書き加える形で解説します。
全体像：通信の流れに補足
これまでの「パソコン → 家のルータ → インターネット → Webサーバ」の流れに、2つの守りを書き加えると次のようになります。
- ① 暗号化（SSL/TLS）：パソコンからサーバまでを丸ごと包み、途中のインターネットでの盗み見を防ぎます。
- ② 電子署名：認証局が署名したサーバ証明書で、接続先が本物のサイトかを確かめます。
それぞれ、詳しく見ていきましょう！
暗号化（SSL/TLS）：盗み見を防ぐ
暗号化とは、データを決まったルールで変換して、第三者には読めない状態にすることです。元のデータを平文、変換後を暗号文、元に戻すことを復号と呼びます。変換と復号に使う「合言葉」のようなデータが鍵です。
例えば、「わたしはげんきです」という文章を送る時を考えましょう。
暗号化ルール(=鍵)：文字を一つずらす(あ→い、こ→さ)
の時、暗号文は「をちすひごあくどせ」となります。
暗号化ルールを知っていたら復号、解読できますが、第三者からは全く読めません。これが暗号化です！
暗号化の方式には、鍵の使い方の違いで2種類あります。
共通鍵暗号方式
暗号化と復号に同じ鍵を使う方式です。家の鍵と同じで、閉めるのも開けるのも1本の鍵です。
- 長所：処理が速く、大きなデータの暗号化に向いている
- 短所：相手に鍵を安全に渡す方法が問題になる（鍵を送る途中で盗まれたら終わり）
- 通信相手ごとに別の鍵が必要。n人が互いにやり取りするには n(n−1)/2 個の鍵がいる
- 代表例：AES
公開鍵暗号方式
公開鍵と秘密鍵という、ペアになった2つの鍵を使う方式です。公開鍵で暗号化したものは、ペアの秘密鍵でしか復号できません。
たとえるなら、公開鍵は「誰でも閉められる南京錠」、秘密鍵は「その南京錠を開けられる、持ち主だけの鍵」です。
- 受信者が、公開鍵（南京錠）をみんなに配っておく
- 送信者は、受信者の公開鍵でデータを暗号化して送る
- 受信者は、自分だけが持つ秘密鍵で復号する
- 長所：秘密鍵を誰にも渡さなくてよいので、鍵の受け渡しの問題が起きない。鍵の数は1人2個（n人で2n個）で済む
- 短所：処理が遅い
- 代表例：RSA、楕円曲線暗号
どっちが主流？
現在の通信では、この二つの暗号化方式を組み合わせた、「ハイブリット暗号方式」が主流です。
どちらの形式も長所短所がありましたので、組み合わせて利用することでその欠点をなくそうという発想です。
共通鍵暗号方式では、共通鍵をどう安全に渡すかが短所でしたが、その鍵の受け渡しを公開鍵暗号方式で行います。
そして、安全に渡した共通鍵でデータを暗号化します。これにより、公開鍵暗号方式のデータ暗号化復号化に時間がかかるという短所もカバーしています。
利用例：SSL/TLS方式
ハイブリット暗号化方式を利用して、Webサイトの通信を暗号化しているのがSSL/TLSです。
※SSLは古い規格で、今使われているのは後継のTLSですが、名残で「SSL/TLS」とまとめて呼ばれます。
HTTP(ウェブサイトの通信を行うプロトコル)の通信をTLSで暗号化したものがHTTPSで、ブラウポート番号は、HTTPの80番に対してHTTPSは443番を使います。
Webサイト運営者にとっては、HTTPS化は今や必須です。お問い合わせフォームやログイン画面がある場合は特に、利用者の情報を守る基本対策になります。
このウェブサイトもSSL/TLSで暗号化しています！
URLがHTTPSで始まっていますよね？これが暗号化の目印です。
電子署名：改ざんとなりすましを防ぐ
暗号化で中身は読まれなくなりましたが、まだ2つの心配が残ります。「途中で書き換えられていないか（改ざん）」と「相手は本当に本人か（なりすまし）」です。これを確かめるのが電子署名（デジタル署名）です。紙の書類に押すハンコやサインの、デジタル版と考えてください。
暗号化でデータを読まれることはなくなりましたが、このままだと、余計なデータを加えられる/削除される危険性はあります。
「わたしはげんきです」と送ろうとしたのに、第三者がデータを加えて「わたしはげんきんです」というデータになったら、伝えたい内容が伝わりませんよね、、
準備：ハッシュ値
電子署名の前に、ハッシュ関数という道具を押さえておきます。ハッシュ関数は、どんなデータからでも決まった長さの値（ハッシュ値）を作る仕組みです。
- 同じデータからは、必ず同じハッシュ値ができる
- データが1文字でも変わると、まったく違うハッシュ値になる
- ハッシュ値から元のデータを復元することはできない
つまりハッシュ値は、データの「指紋」です。送る前と届いた後の指紋を比べれば、改ざんされていないかが分かります。
電子署名の仕組み
電子署名は、公開鍵暗号の鍵を暗号化のときと逆向きに使います。
- 送信者は、送りたいデータのハッシュ値を作る
- そのハッシュ値を、送信者の秘密鍵で暗号化する。これが電子署名になる
- データと電子署名をセットで送る
- 受信者は、電子署名を送信者の公開鍵で復号し、ハッシュ値を取り出す
- 受け取ったデータから自分でもハッシュ値を作り、4.と一致するか比べる
一致すれば、次の2つが同時に確かめられます。
- 改ざんされていない：データが変わっていれば、ハッシュ値が一致しない
- 本人が送った：送信者の公開鍵で復号できたのは、ペアの秘密鍵を持つ本人が署名した証拠
認証局（CA）とサーバ証明書
ここで最後の疑問が残ります。「その公開鍵は、本当にその人のものなのか？」。偽物が自分の公開鍵を「銀行の公開鍵です」と配っていたら、電子署名の検証も通ってしまいます。
そこで登場するのが、認証局（CA）です。認証局は、信頼できる第三者として「この公開鍵は、確かにこのサイトの持ち主のものです」と保証するデジタル証明書を発行します。証明書には、認証局自身の電子署名が付いています。
Webサイトの場合はサーバ証明書（SSL/TLS証明書）と呼ばれ、HTTPSの通信の最初にブラウザへ送られます。ブラウザは認証局の署名を検証し、本物のサイトだと確かめてから暗号化通信を始めます。1章のTLSの手順の1番目は、この確認のことです。
役所の印鑑証明にたとえると、電子署名が「実印」、サーバ証明書が「印鑑証明書」、認証局が「役所」にあたります。
まとめ
通信の中身は、公開鍵と秘密鍵を使った2つの守りで守られています。
- 暗号化（SSL/TLS）：中身を読めなくして、盗み見を防ぐ。公開鍵暗号の仕組みで共通鍵を共有し、データは速い共通鍵暗号でやり取りする
- 電子署名：送信者の秘密鍵で署名し、改ざんとなりすましを見抜く。公開鍵の持ち主は認証局が保証する
3回の記事で、「物理的な道のり」「宛先を決める論理的な仕組み」「通信の中身を守る仕組み」を見てきました。ブラウザの鍵マークひとつにも、たくさんの技術が詰まっていることが見えてきたと思います。
次回は企業向けのセキュリティ応用編です。ネットワークの出入口を守るファイアウォールから始めて、ゼロトラストやSASEといった新しい考え方までを解説します。
(余裕があれば、昨今の情報漏えいはどのセキュリティの穴を突かれたのかまで解説します！)
コメント