証明書
暗号化

暗号化とか、証明書とか

More than 1 year has passed since last update.

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

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

  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.ルート認証局に認証してもらうことによって中間認証局ができ、信頼できる相手となる。

さいごに

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