先日、「SSL証明書の仕組み」勉強会に参加してきたので、その備忘録です。
この記事では、暗号アルゴリズムなど詳細のことは書いておりません。
用語
簡単ですが、専門用語が出てくるので、その説明を先に書いておきます。
平文
暗号化されていないただの文章。このままだと送信中に誰かに読まれる可能性がある。
暗号
通信の秘密を守るため、当事者間だけでわかるように決めた特殊な記号。
復号
暗号化された平文(暗号文)を、読めるように平文に戻すこと。
基本的に、暗号化・復号化する際は「鍵」(以下で言う、共通鍵・公開鍵・秘密鍵)というものを利用します。
共通鍵暗号方式とは
交換鍵暗号方式を理解するには、共通鍵暗号方式も理解しといた方が良いので、共通鍵暗号方式も解説します。
- クライアントとサーバーが同じ鍵を持つ(共通鍵)
-
クライアントが平文を共通鍵で暗号化し、サーバーは共通鍵で、復号する
メリット
同じ鍵でしか復号できないので、セキュリティが担保される。
デメリット
クラアントとサーバは、どうやって共通鍵を共有するのか???
直接、鍵を送ると通信途中で鍵自身が盗まれてしまう。。。
交換鍵暗号方式とは
- 公開鍵はインターネット上に公開しておく(誰もが使えるように)秘密鍵は、保持しておく
- 公開鍵・秘密鍵のどちらでも暗号化できるが、復号する際は対の鍵でしか復号できない
- ex) 公開鍵で暗号化すると、対になている秘密鍵でしか復号できない仕組み
暗号復号フロー
1. 受信者は、公開鍵・秘密鍵を保持
2. 受信者は、公開鍵を公開する
3. 送信者は、受信者の公開鍵で送信したい平文を暗号化する
4. 送信する
5. 受信者は、保持している秘密鍵で復号する
メリット
安全に通信できる。
デメリット
交換鍵の信用性が問われる。
共通鍵・公開鍵暗号方式とは
上記の2つの暗号方式にはそれぞれデメリットがありました。
そこで、両方の方式を組み合わせることにより、お互いのデメリットを打ち消せると開発されたのがこの暗号方式です。
暗号復号フロー
- 送信者は、共通鍵を2つ持つ
- 受信者は、公開鍵・秘密鍵を持つ
- 受信者は、公開鍵を公開する
- 送信者は、「共通鍵・送りたい平文」両方を公開鍵で暗号化する
- 受信者は、送られてきた暗号文を秘密鍵で復号する
- これで、受信者にも共通鍵を渡すことができたので、以降は、共通鍵暗号方式で通信をおこなう
SSLサーバ証明書
該当のサーバが信頼できるものですよと、裏付けるもの。
認証局が該当のサーバが正当なものかどうか日々調査している。
上記の共通鍵・交換鍵暗号方式で、安全な通信が担保されるのですが、公開鍵の信用性が担保されていません。
そこで、SSLを証明書を使って公開鍵の信用性を担保します。
以下のサイトで図付きで詳しく解説されています。
暗号復号フロー
- サーバは、公開鍵・サーバ情報を保持
- 認証局は、認証局秘密鍵を保持
- クライアントは、認証局公開鍵を保持(chromなどのブラウザにプレインストールされている)
- サーバは、公開鍵とサーバ情報を認証局に渡す
- 認証局は、サーバが正常か・信用できるものなのかを検証する
- 認証局は、認証局秘密鍵で、サーバ情報と公開鍵を暗号化する(証明書)
- それをサーバに渡す
- クライアントが、サーバと通信しようとする
- サーバは、証明書をクライアントに渡す
- クライアントは、認証局公開鍵で証明書を復号する
- サーバの公開鍵・サーバ情報を取得する
- 認証局がセキュリティを担保したサーバの公開鍵を、クライアントが手にする
SSL証明書で、公開鍵のセキュリティを担保している
まとめ
ちょっと文章だけで長くなってしまいました。
最近は、Googleの規制が厳しくなり、きちんとSSL証明書を発行していないwebサイトなどは
SEOで引っかかりにくくなっているようです。
その辺のこともまた記事を書きたいと思います。
コメントを残す