証明書
暗号化

暗号化とか、証明書とか

暗号化とか、証明書とか個人的なメモ

暗号化通信の基本的な仕組み

  1. Aは秘密鍵を作る。
  2. Aは作った秘密鍵とペアになるような公開鍵を作る。
  3. Aはその公開鍵をBに渡す。
  4. 通信するときは、その秘密鍵と公開鍵のペアで通信する。

一見これで問題ないように見えるのですが、これには大きな問題が含まれています。
3.の公開鍵を渡すというポイントです。
その受け渡しをどうやってセキュアに実施しますか?
これって鶏と卵ですよね。
つまり、セキュアに通信するために鍵交換をしたいのに、
その鍵交換には、セキュアな通信が必要・・・という。

これを解決する方法はひとつしかありません。
OSのインストール時にインストールディスクとかに埋め込んでおくんです。
※インストールディスクは改ざんされない前提ですけどね。
これについては、製品を買ってきて手に入れるのが大半だと思うので、問題ないです。

じゃあ、全部のサイトの公開鍵を埋め込んでおくんですか?という話です。
そんなん無理な話ですよね。どんどん新しいサイトもできますし、ほぼ無限大に存在します。
結論から言うと、OSインストール時に埋め込む鍵は限られています。

そうすると、鍵をあらかじめ持っていないサイトとは通信できない気がします。
その場合はどうするのか。その場合は、「すでに信頼している人から、保証してもらう」ことが有効になります。

次に、その、「既に信頼している人から、保証してもらう」仕組みを考えてみる。

暗号化通信と証明書

Aが証明書を作るプロセス

  1. Aは秘密鍵を作る。
  2. Aは作った秘密鍵とペアになるような公開鍵を作る。
  3. Aはその公開鍵に署名してもらう書類を作る。(CSR=Certificate Signature Rrequire)
  4. AはCSRをKに渡す。
  5. Kは受け取ったCSRに対して、Kの秘密鍵で暗号化して、証明書を作る。
  6. Kは作った証明書をAに返す。

AがBと通信するプロセス。

  1. BはAにアクセスする。
  2. AはBに証明書をかえす。
  3. Bはその証明書をKに問い合わせて本物かどうか確認する。
  4. 確認の結果問題なければAと通信する。

さて、ここで重要になってくるのは、Kの存在です。
これはKがいるからこそ、成り立つ仕組みなのです。
このKのことをKPIとよんでいます。

もう少し勉強したい人へ。

この、”Kに問い合わせて検証する”部分を詳しく見ていきましょう。

1.BはAから証明書をもらう。
2.BはKから公開鍵をもらう。
3.Aの証明書はKの秘密鍵で暗号化されているので、Kの公開鍵で復号化できる。
4.そのようにして、BはAの証明書が正しいことが検証できる。
5.ちなみに、証明書にはAの公開鍵が含まれているので、このようにしてBはAの正しい公開鍵を手に入れることができる。

認証局

ここで、OSに最初からインストールしている証明書のことを”ルート証明書”と呼び、
そのルート証明書で認証できるサーバーのことをルート認証局と呼んでいます。
そして、そのルート認証局に認証してもらう必要のあるサーバーを中間認証局と呼び、区別します。
中間認証局はルート認証局に証明してもらうことにより、その正当性を確保することができます。
こうして、信頼がどんどん連鎖していくことを、「信頼の連鎖」と呼ぶこともあります。
友達の友達は友達!見たいな感じですかね。違いますかね。

要約

ごちゃごちゃいってきましたが、要約すると以下のポイントとなります。
1.通信をするときには、鍵交換を行う必要がある。
→でもどうやってその鍵交換を行うの?
2.もともと埋め込まれている鍵でやり取りする相手をルート認証局と呼ぶ
→じゃあそれ以外とどうやって通信するの?
3.ルート認証局に認証してもらうことによって中間認証局ができ、信頼できる相手となる。

さいごに

なんかまとまりのない文章となってしまいました
嘘とか言ってたら指摘していただけると幸いです