サーバとかクライアントの証明書

今仕事で必要になってるんだけど、職場にいまいち理解していない人がいるようなので酔った勢いで書いてみる。

とりあえず暗号について

今回使う暗号は、大きく二つ。共通鍵暗号と公開鍵暗号。
ただし、共通鍵暗号の方はhttpsの裏側で勝手に使われているので、本当に理解しておかなくてはいけないのは公開鍵暗号のほうで、証明書とか出てくるときには必須の概念です。

というわけで、共通鍵暗号のほうはｇｇｒｋｓ。

公開鍵暗号は秘密鍵と公開鍵の二つを使う暗号の方式で、例えばxという数に公開鍵を使ってとある演算を施した答えであるyは、秘密鍵を用いると元のxに戻せ、また逆にxに秘密鍵を使ってとある演算を施した答えであるzは、公開鍵を用いると元のxに戻せるという性質を活用している。

上記のとある演算は、素因数分解を使う方式とか楕円関数を使う方式とかいろいろあります。大学時代に数学の授業で素因数分解を使う方式を習ったときには完全に理解したつもりだったけど、いまや完全に忘れた。でもそのときの教授の「暗号理論という秘密の花園にコンピュータの技術者が踏み込んでくる」という怒りの台詞は記憶に残り続ける。

この性質を使うと、「暗号化」と「署名」という二つの機能が実現できます。

暗号化と署名

以下では暗号化と署名について説明します。

まずは登場人物まとめ。

アリス

秘密鍵Aと、それに対応する公開鍵aを持っている。

ボブ

アリスさんのストーカー。公開鍵aをどうにかして入手している。

チャーリー

アリスさんの恋人。名前だけしか出てきません。

シナリオ1：ボブの恋文がアリスに届くまで

ボブさんはぜひともアリスさんに恋文を届けたい。しかし、アリスさん以外には読まれるとタイーホの恐れがあるのでアリスさんにしか読めないようにしたいのです。

そこで、アリスさんに恋文を暗号化して届けることにしました。

まず、ボブさんは恋文を何bitかずつ数値にし、それに対して公開鍵aを使ってとある演算を施します。そしてその結果の数値を並べた「暗号化済み恋文」をアリスさんの郵便受けに投函します。

アリスさんは郵便受けにあった「暗号化済み恋文」をチャーリーからのものだと勘違いし、「まぁ、チャーリーったら。間違いなく私だけを愛しているっていうためにわざわざ私にしか読めないようにしてくれたのね」なんてお気楽な考えとともに並んだ数値に対してそれぞれ秘密鍵Aを使ってとある演算を施して復号化し、並べなおして恋文を復元します。

すると、なんということでしょう。その恋文はチャーリーからのものではなくボブからのものではないですか。

アリスは気持ち悪くなってその恋文を読まずに食べてしまいます。

シナリオ2：アリスの苦情の手紙がボブに届くまで

アリスは、吐き気を抑えつつもボブが二度と恋文を送ってこないように苦情の手紙を出そうと考えます。

そこで、恨みをこめて「さっきの手紙の御用はなぁに？ アリス」としたためた後、これが間違いなくアリスから送られたものであるという証拠を残すため、アリスという署名の部分を何bitかずつ数値化して、それに対して秘密鍵Aを使ってとある演算を施し、手紙の最後に付加します。

その手紙を受け取ったボブは「ヤフー！ アリスから返事が来たぜ！」と思いつつも、チャーリーがいたずらでアリスの名を騙って送ってきた可能性を捨てきれないために署名の確認をしようと思います。

そこで、手紙の最後の数値に対して順番に公開鍵aを使ってとある演算を施し、その結果を並べます。すると、なんということでしょう。そこにはまごう事なき「アリス」という署名が浮き出てきたではありませんか。

よろこびにあふれたボブはその手紙を読まずに食べてしまいます。

以下エンドレスです。

証明書について

今までの説明で公開鍵暗号についてはなんとなく雰囲気を感じ取ってもらえたかと思います。わき道にそれまくってるのでわかりにくいかもしれませんが。

これからが本題の証明書です。

今回扱う証明書には2種類あって、サーバ証明書とクライアント証明書です。

前者は、サーバが間違いなくそのサーバであること、後者はクライアントが間違いなくそのクライアントであることを証明します。そのまんまですね。

どうやって証明するかというと、ここで「認証局」という第3者が出てきます。証明書にはその人の持っているはずの公開鍵が記載されているのですが、それに加えて認証局が署名付で「この公開鍵を持っている人は間違いなくこの人ですよ」と証明書に記載してくれるのです。

なので、サーバの証明書に記載された公開鍵を使って送りたい情報を暗号化すれば、通信を傍受されたり、DNSを差し替えられて別のサーバに送られてしまったとしても、本来送りたいサーバ以外では復号化できないため、送りたい情報が漏洩しないのです。

また、クライアントの証明書に記載された公開鍵を使った場合も同様に、そのクライアント以外には受信しても無意味な情報になるのです。

ここで重要になるのが、「認証局」なる第3者の存在です。その認証局が信頼できない場合、上の前提はまったく成り立ちません。そこで、IEやFirefoxなどのブラウザははじめから「信頼できる認証局」リストを持っていて、ベリサインなどの有名な認証局ははじめから「信頼できる」扱いされているのです。そして、新興の認証局はブラウザにはその証明書が「信頼できる」ものとしてリストされていないので、別の認証局に「信頼できるよ」とお墨付きをもらって認証局業務をやっています。その辺の詳しい話はググレ。

この辺まで書いたところで酔いが醒めてきたし、アリスたちを再登場させる元気もないのでのでそろそろ終わりにします。

間違ってたらコメントで突っ込んでください。酔っ払った状態で何も資料を見ずに書き殴っているのであまり自信ないです。

しかし図もなく文字ばっかりだから読む気が起きませんね。