SSL/TLS、電子商取引、本人認証などで、公開鍵暗号化方式、証明書や認証局などの用語が出てきます。 ただし、これらは処理が複雑に見え、イメージが湧きにくいことがよくあります。
ここで、公開鍵暗号方式、認証局、デジタル署名の理解を助ける私のイメージを記事にします。
プロトコルの正確性は求めず、あくまで、仕組みをイメージしてもらうことを目的にまとめます。
まず、公開鍵と秘密鍵について、理解しましょう。(一応、RSA前提です)

- 公開鍵を使ってデータを暗号化すると、そのデータは秘密鍵で復号できます。(といいますか、秘密鍵でしか復号できません。)
- 秘密鍵を使ってデータを暗号化すると、そのデータは公開鍵で復号できます。(といいますか、公開鍵でしか復号できません)
まず、これは覚えましょう。

ではAさんとBさんが公開鍵/秘密鍵を使って暗号化通信するとします。
Aさんが公開鍵と秘密鍵のペアを作成します。

Aさんの秘密鍵は、その名の通り、Aさんの秘密なので、誰にも見せず、隠しておきます。Aさんの公開鍵は、通信相手に公開してもOKです。このAさんの公開鍵をBさんに渡します。

BさんはAさんの公開鍵を使って、データを暗号化し、Aさんは、そのデータをAさんの秘密鍵を使って、復号します。また、AさんからのデータはAさんの秘密鍵を使って暗号化し、BさんはAさんの公開鍵を使って、復号します。

はい、以上です。これで何も問題ないように思います。しかし、ここで大きな問題があるのです。
それは、Aさんの公開鍵は本当にAさんのものなのか?ということです。
例えば、わるーい人が自分の公開鍵を「Aさんの公開鍵だよ」って、渡してもBさんはそれに気付くことが難しいのです。BさんはAさんだと思って、わるーい人にデータを送ってしまうのです。

このように、公開鍵をもらった人は、「本当にこの公開鍵は正しいの?」って、疑わないといけないのです。
今回の場合は、BさんはAさんの公開鍵を「本当にAさんの公開鍵なの?」って、疑わないといけません。

Aさんは、どうやって、「この公開鍵は自分のだ!」って、Bさんに認めてもらうのでしょうか。
まず、Aさん自身が「この公開鍵は自分のだ!」っていくら主張しても、そんなのBさんは信じてくれません。

では、第三者に証明してもらいましょう。ここで、Cさんに来てもらいます。Cさんに「この公開鍵はAさんだよ」って証明してもらいます。これだと第三者の意見なので、Aさんが主張するよりマシですね。
ただ、Bさんからすると、「Cさん?お前誰だよ?」となります。Cさんがわるーい人で、Aさんとグルかもしれませんね。

誰かに証明してもらっても、その人が信用できない。そう、キリがないのです。この世に絶対、信用できる人っていないのか・・・?とみんなで考えたところ、、、、おられました。。。 それは神様です。

神様は信用できるでしょう。理由はありません。だって、神様ですから。
神様も公開鍵と秘密鍵を持っています。

神様の秘密鍵は、絶対に秘密です。なぜなら、あの神様が秘密にしてる鍵ですから。
上でも書きましたが、公開鍵は、必ず、「本当にこの公開鍵は正しいの?」って、疑わないといけません。
では、神様の公開鍵は、どうでしょう。この鍵は疑ってはいけません。この鍵は正しいのです。なぜなら、神様の公開鍵ですから。これは神様の公開鍵だよって、神様が証明しているのです。(これは自己署名です)

神様の公開鍵は絶対に正しいのです。疑ってはいけません。疑ってはいけないので、みーんなに神様の公開鍵は信頼済みとし、あらかじめ、配っておきましょう。

これで、この世の中、神様のいうことは正しい ということになりました。
では、Aさんは、「この公開鍵は自分のだ!」って、Bさんに認めてもらうにはどうすれば良いでしょう。Bさんは神様の公開鍵は信頼しています。
Aさんは、神様に相談します。

神様は、「申請書に名前や住所を書いて、公開鍵と合わせて、持って参れ!」 と言い、Aさんは神様の言われた通りにします。

神様は、その申請書とAさんの公開鍵を見えないところに持っていって、こっそり神様の秘密鍵で暗号化します。(このあたりもCSRのハッシュ値を署名するので、ちょっと正確性には欠けます。暗号と署名も正確には異なります。) それをAさんの公開鍵に添付してAさんの証明書を作成します。

では、Aさんは、Bさんにこの証明書を渡します。Bさんは神様のお手紙に気づきます。

Bさんは神様の公開鍵を持っています。これは絶対に正しい鍵なので、これで、お手紙を開けます。
中を開けて見ると、Aさんの公開鍵と同じものが入っているじゃありませんか(CSRのハッシュ値比較なので、公開鍵以外の情報もあり、ちょっと正確性に欠けます)。ということは、このAさんの公開鍵は神様が秘密鍵で暗号化したんだ!
神様が暗号化したということはこれは絶対Aさんの公開鍵だ。信じましょう。

となります。
今まで登場人物に、用語など、少し補足すると以下にようになります。

- ルート認証局(CA認証局):神様です。公的なルート認証局としては、例えば、GMOグローバルサインやDigiCertがあります。プライベートに認証局を立てることも可能です。もちろん、プライベート認証局の公開鍵の自己署名付き証明書をルート証明書として、端末など認証する側にインストールする必要があります。
- デジタル署名:CSR(Certificate Signing Request:申請書情報と公開鍵など)のハッシュ値をルート認証局の秘密鍵で署名(暗号)
- ルート証明書:ルート認証局の公開鍵に、自己署名(ルート認証局の秘密鍵で署名(暗号))をつけた証明書です。
正確性には欠けますか、これで、ざっくりイメージを掴んでいただいて、実務やさらに細かいプロトコルの動作の学習に役立てもらえるとうれしいです。
コメント