暗号化とか、証明書とか個人的なメモ
暗号化通信の基本的な仕組み
- Aは秘密鍵を作る。
- Aは作った秘密鍵とペアになるような公開鍵を作る。
- Aはその公開鍵をBに渡す。
- 通信するときは、その秘密鍵と公開鍵のペアで通信する。
一見これで問題ないように見えるのですが、これには大きな問題が含まれています。
3.の公開鍵を渡すというポイントです。
その受け渡しをどうやってセキュアに実施しますか？
これって鶏と卵ですよね。
つまり、セキュアに通信するために鍵交換をしたいのに、
その鍵交換には、セキュアな通信が必要・・・という。
これを解決する方法はひとつしかありません。
OSのインストール時にインストールディスクとかに埋め込んでおくんです。
※インストールディスクは改ざんされない前提ですけどね。
これについては、製品を買ってきて手に入れるのが大半だと思うので、問題ないです。
じゃあ、全部のサイトの公開鍵を埋め込んでおくんですか？という話です。
そんなん無理な話ですよね。どんどん新しいサイトもできますし、ほぼ無限大に存在します。
結論から言うと、OSインストール時に埋め込む鍵は限られています。
そうすると、鍵をあらかじめ持っていないサイトとは通信できない気がします。
その場合はどうするのか。その場合は、「すでに信頼している人から、保証してもらう」ことが有効になります。
次に、その、「既に信頼している人から、保証してもらう」仕組みを考えてみる。
暗号化通信と証明書
Aが証明書を作るプロセス
- Aは秘密鍵を作る。
- Aは作った秘密鍵とペアになるような公開鍵を作る。
- Aはその公開鍵に署名してもらう書類を作る。(CSR=Certificate Signature Rrequire)
- AはCSRをKに渡す。
- Kは受け取ったCSRに対して、Kの秘密鍵で暗号化して、証明書を作る。
- Kは作った証明書をAに返す。
AがBと通信するプロセス。
- BはAにアクセスする。
- AはBに証明書をかえす。
- Bはその証明書をKに問い合わせて本物かどうか確認する。
- 確認の結果問題なければ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.ルート認証局に認証してもらうことによって中間認証局ができ、信頼できる相手となる。
さいごに
なんかまとまりのない文章となってしまいました
嘘とか言ってたら指摘していただけると幸いです