読む前にこの記事のポイントを音声で確認できます。この音声は本記事をもとにAIツール（NotebookLM）で自動生成したもので、発音や言い回しが不自然な箇所や、内容の誤りが含まれる可能性があります。理解の補助としてご利用ください。
SSL/TLS、電子商取引、本人確認などの場面では、公開鍵暗号、証明書、認証局といった用語が出てきます。ただ、これらは仕組みが複雑に見えて、イメージがわきにくいことがよくあります。
この記事では、公開鍵暗号、認証局、デジタル署名の仕組みを、私なりのイメージで説明します。プロトコルの細かい動作よりも、全体の仕組みをつかんでもらうことを目的にしています。
- 公開鍵と秘密鍵の2つの使い方（暗号化とデジタル署名）
- 「その公開鍵は本当に本人のものか」という問題
- 認証局（神様）が証明書を発行し、受け取った側が確かめる流れ
- ルート証明書、中間証明書、サーバ証明書の関係
公開鍵と秘密鍵
まず、公開鍵と秘密鍵を理解しましょう。公開鍵と秘密鍵は、必ずペアで作られる2つの鍵です。公開鍵は誰に渡してもよい鍵で、秘密鍵は自分だけが持ち、誰にも見せない鍵です。このペアには、次の2つの使い方があります。
| 使い方 | 使う鍵 | イメージ |
|---|---|---|
| 暗号化 | 相手の公開鍵で暗号化し、相手が自分の秘密鍵で復号する | 開いた南京錠（公開鍵）をみんなに配っておき、届いた箱は自分だけが持つ鍵（秘密鍵）で開ける |
| デジタル署名 | 自分の秘密鍵で署名し、相手が自分の公開鍵で確かめる | 自分だけが持つハンコ（秘密鍵）で押し、配ってある印影（公開鍵）と照らし合わせてもらう |
まず、この2つを覚えましょう。この記事では RSA を例にしたイメージで説明しますが、楕円曲線暗号（ECDSA など）でも、公開鍵と秘密鍵の役割は同じです。
Aさんが鍵ペアを作り、公開鍵を渡す
AさんとBさんが、公開鍵暗号を使って通信するとします。まず、Aさんが公開鍵と秘密鍵のペアを作ります。Aさんの秘密鍵は、その名のとおりAさんだけの秘密なので、誰にも見せずに隠しておきます。Aさんの公開鍵は、相手に渡しても問題ないので、Bさんに渡します。
Bさんが公開鍵で暗号化し、Aさんが秘密鍵で復号する
Bさんは、Aさんの公開鍵を使ってデータを暗号化して送ります。このデータは、Aさんの秘密鍵でしか復号できません。途中で誰かに見られても、Aさんの秘密鍵を持っていない人には読めません。
反対に、AさんからBさんへ秘密のデータを送るときは、Bさんの公開鍵で暗号化します。Aさんの秘密鍵で処理したデータは、Aさんの公開鍵を持っている人なら誰でも元に戻せるので、中身を隠す目的には使えません。こちらは「Aさんが作った」ことを示すデジタル署名に使います。
また、実際の通信では、公開鍵暗号でデータそのものを暗号化することはほとんどありません。公開鍵暗号は相手の確認や鍵の受け渡しに使い、データの暗号化には AES などの共通鍵暗号を使います。鍵の受け渡しの仕組みは Diffie-Hellman 鍵交換 の記事で説明しています。
その公開鍵は本当にAさんのもの？
これで問題なく通信できるように思えます。しかし、ここに大きな問題があります。それは、「Aさんの公開鍵は、本当にAさんのものなのか？」ということです。
たとえば、悪い人が自分の公開鍵を「Aさんの公開鍵だよ」と言って渡しても、Bさんがそれに気付くのは難しいのです。Bさんはその鍵で暗号化してしまい、データは悪い人に読まれてしまいます。
このように、公開鍵を受け取った人は、いつも「この公開鍵は本当に正しいの？」と疑わなければなりません。では、Aさんは、どうやって「この公開鍵は自分のものだ」とBさんに認めてもらえばよいのでしょうか。
自分で言っても、知り合いに言ってもらってもキリがない
まず、Aさん自身が「この公開鍵は自分のものだ」といくら主張しても、Bさんは信じてくれません。では、第三者のCさんに「これはAさんの公開鍵だよ」と証明してもらうのはどうでしょう。Aさん本人が言うよりはましですが、Bさんからすると「Cさんって誰？」となります。CさんがAさんとグルかもしれません。
証明してくれる人がいても、その人を信用できるとは限りません。その人を証明する人を探し、さらにその人を証明する人を探し……と、キリがありません。
神様（ルート認証局）に証明してもらう
この世に、絶対に信用できる人はいないのか……とみんなで考えたところ、いらっしゃいました。それは神様です。神様が信用できる理由はありません。だって神様ですから。この「みんなが信用すると決めた存在」が、ルート認証局です。
神様の公開鍵を、あらかじめみんなに配っておく
神様も、公開鍵と秘密鍵のペアを持っています。神様の秘密鍵は絶対に秘密です。神様は、自分の公開鍵に自分で署名した証明書を作ります。これがルート証明書（自己署名証明書）です。
公開鍵は必ず疑わなければなりませんでした。神様の公開鍵も、自分で署名しているだけなので、それだけでは正しさを証明できません。そこで、神様の公開鍵は「信頼してよいもの」として、あらかじめみんなに配っておきます。実際には、パソコンやスマートフォンの OS やブラウザに、信頼済みのルート証明書が最初から入っています。
これで、この世の中では「神様の公開鍵で確かめられたものは正しい」ということになりました。
Aさんが神様に申請し、証明書を作ってもらう
Aさんは神様に相談します。神様は「申請書に名前などを書いて、公開鍵と一緒に持って参れ」と言い、Aさんはそのとおりにします。この申請書を CSR（Certificate Signing Request、証明書署名要求）と呼びます。CSR は Aさん自身の秘密鍵で署名して出すので、「この公開鍵とペアの秘密鍵を Aさんが持っている」ことも示せます。
神様は、申請してきたのが本当に Aさんかを確かめたうえで、Aさんの名前、Aさんの公開鍵、発行者（神様）、有効期限などを書いた証明書を作ります。そして、その証明書の中身に、神様の秘密鍵で署名します。これがデジタル署名です。署名は証明書の中身全体に対して付けるので、名前や公開鍵が1文字でも書き換えられると、署名が合わなくなります。
Bさんが神様の公開鍵で証明書を確かめる
Aさんは、この証明書を Bさんに渡します。Bさんは、証明書に神様の署名が付いていることに気付きます。Bさんは神様の公開鍵（ルート証明書）を持っているので、それを使って署名を確かめます。
署名が正しければ、この証明書は本当に神様が発行したもので、中身も書き換えられていないことがわかります。神様が「これは Aさんの公開鍵だ」と言っているのだから、この公開鍵は Aさんのものだと信じられます。実際には、署名に加えて、有効期限内か、証明書の名前が接続先と一致しているか、失効していないかも確かめます。
実際の世界では
中間認証局と証明書チェーン
実際には、ルート認証局が利用者の証明書に直接署名することはあまりありません。ルート認証局は「中間認証局」の証明書に署名し、中間認証局が Webサーバなどの証明書（サーバ証明書）に署名します。神様の代わりに、神様が認めた使いの人が証明書を発行するイメージです。
Bさん（ブラウザ）は、サーバ証明書の署名を中間証明書の公開鍵で確かめ、中間証明書の署名をルート証明書の公開鍵で確かめます。こうしてルート証明書までたどれれば、サーバ証明書を信頼します。このつながりを証明書チェーンと呼びます。
TLS（HTTPS）では
HTTPS で Webサイトに接続すると、サーバはサーバ証明書と中間証明書を送ってきます。ブラウザは証明書チェーンをたどって、接続先が本物のサーバかを確かめます。TLS 1.3 では、サーバは証明書を送ったあと、自分の秘密鍵でハンドシェイクの内容に署名（CertificateVerify）し、証明書の公開鍵とペアの秘密鍵を持っていることを示します。データを暗号化する鍵は、Diffie-Hellman 鍵交換で作ります。
公的なルート認証局には、たとえば GMOグローバルサインや DigiCert があります。社内向けにプライベート認証局を立てることもできます。その場合は、プライベート認証局のルート証明書を、確かめる側の端末に信頼済みの証明書としてインストールする必要があります。
まとめ
これまでの登場人物と用語を対応させると、次のようになります。
| この記事のたとえ | 実際の用語 | 説明 |
|---|---|---|
| 神様 | ルート認証局（CA） | みんなが信頼すると決めた認証局。公的な認証局のほか、プライベート認証局も立てられる |
| 神様の公開鍵入りの証明書 | ルート証明書（自己署名証明書） | ルート認証局の公開鍵に、ルート認証局自身が署名した証明書。OS やブラウザに最初から入っている |
| 神様に出す申請書 | CSR（証明書署名要求） | 名前などの情報と公開鍵を書き、申請者自身の秘密鍵で署名した申請 |
| Aさんの証明書 | サーバ証明書など（X.509 形式） | 名前、公開鍵、発行者、有効期限などに、認証局が署名したもの |
| 神様の署名 | デジタル署名 | 証明書の中身に対して、認証局の秘密鍵で付けた署名。認証局の公開鍵で確かめる |
| 神様の使い | 中間認証局 | ルート認証局に認められ、サーバ証明書などを発行する認証局 |
正確な仕様とは違う部分もありますが、このイメージをつかんでおくと、実務や、より細かいプロトコルの学習に役立つと思います。
コメント