- ベストアンサー
SSLの暗号化について
ミルです。 SSLの暗号化の仕組みについて易しく教えていただきたいです。 SSLのWebページで情報を送信すると、どんなしくみで 送信側と受信側で鍵をやりとりするってことなんでしょうか？ 本を読んでもよくわかんなくって。
- ネットワーク
- 回答数6
- ありがとう数4
- みんなの回答 （6）
- 専門家の回答
質問者が選んだベストアンサー
追加の質問をよく見てなかったので補足です。 ちょっとごちゃごちゃしますが、証明書についてと受け渡しについてです。 第三者認証機関（仮にベリなんちゃら）の公開鍵は証明書とともに 既にブラウザに入っている事はご存じの通りです。 Ａ社のサーバーがSSLの要求を受けると、ベリなんちゃらの証明書を送ってきます。 その証明書にはＡ社の公開鍵が入っており、ベリなんちゃらの秘密鍵で暗号化されています。 それをブラウザに既に入っている、ベリなんちゃらの公開鍵で復号化します。 取り出したＡ社の公開鍵はベリなんちゃらが保証していますので、この公開鍵で 複合化出来るデータはＡ社からの物に間違いない。となります。 ポイントは、Ａ社がベリなんちゃらに認証の申請をする際にも、 公開鍵とＡ社の情報を伝えるだけなので、 「まったく本当にＡ社以外には秘密鍵に触れていない」 という事です。 で、その公開鍵を使って、共通鍵を作るための乱数データを暗号化して Ａ社のサーバーに送り、Ａ社は秘密鍵を使ってそれを複合化して、自分が 作った乱数を加えて・・・・と、共通鍵の生成に入るのですが、 実はSSLの要求の時点と、それに対して証明書を送り返す時点で、 一回限りの乱数を互いが互いに送り合っていて、 （その乱数＋上の乱数データ）×アルゴリズム でそれぞれの共通鍵をつくるようです。 （詳しく説明する自信がないのでこれくらいでご勘弁） 〆として、信頼性の問題としては一般的に ・共通鍵の信頼性は鍵の長さに比例する。 ・公開鍵・秘密鍵の信頼性は数学的根拠による。 と言われています。 これでどうでしょうか。
その他の回答 (5)
- yamma
- ベストアンサー率27% (29/107)
＞３のトコは、私のブラウザソフトが共通鍵を ＞生成しているんですか? ブラウザとサーバーがそれぞれ生成します。 ブラウザから暗号化して送るためのブラウザ用共通鍵と サーバーから暗号化して送るためのサーバー用共通鍵が あります。 （つまりお互いがブラウザ用とサーバー用の共通鍵を 両方持ちます） 共通鍵の利点は、 ・鍵が一つで良い （ブラウザ用鍵で暗号化したデータは ブラウザ用鍵で復号する） （サーバー用鍵で暗号化したデータは サーバー用鍵で復号する） ・暗号化・複合化のスピードが速い という点だと言われています。 ＞共通鍵っていうのは、どんな仕事をしているんでしょうか? 一般的な暗号化と複合化です。 お互いが同じ暗号表をもって、文字を置き換えて 読むのと同程度です。 しかし、その暗号表を「絶対に他人が持っていない」と 確信出来れば安心です。 その為にお互いが暗号表を送り合うのに公開鍵・秘密鍵を 使います。 ＞公開鍵＝暗号鍵 ＞秘密鍵＝解読鍵って他の方に教えていただいて、私の この場合を具体的にお話ししますと 私たちは、例えばＡ社の公開鍵でデータを暗号化して送り、 Ａ社は秘密鍵で解読します。 一方、Ａ社はデータを秘密鍵で暗号化してこちらに送り、 私たちはＡ社の公開鍵を使って解読します。 つまりどちらも暗号化・復号化が出来るのですが、 秘密鍵で暗号化した物を秘密鍵で解読したり、 公開鍵で暗号化した物を公開鍵で解読したりは出来ないのがポイントです。 この性質を利用すれば、第三者に「これは確かにＡ社の 公開鍵だ」と 証明してもらうだけで、私たちが間違いなくＡ社とデータの やりとりをしているのだという事が保証されるわけです。 （Ａ社の公開鍵で復号できた＝Ａ社の秘密鍵で暗号化した） （Ａ社の公開鍵で暗号化した＝Ａ社の秘密鍵でしか解読出来ない） ちょっとややこしくなってしまったかもしれません。 ちなみに、少し前に 「ＳＳＬの鍵の長さが４０ビットから１２８ビットになった」 という話を聞いたかもしれませんが、これは共通鍵の長さの事です。 （公開鍵・秘密鍵の長さは５１２ビットor１０２４ビットです。） こんな感じでいかがでしょうか。
- you-m
- ベストアンサー率58% (190/327)
気になってもう一度調べなおしました。 yammaさんの言うとおり、公開鍵暗号方式で”実際のデータの暗号化をする為の鍵”をやり取りするが正解でした。 ここで言う共通鍵は、公開鍵暗号方式でない、暗号化と解読両方ができる鍵です。 公開鍵暗号方式の良い点は、解読の為の鍵を、外部に一切出す必要が無い事です。逆に不便な点は、前の私の説明のとおり、一組のキーペアでできる通信は一方通行だという点です。 通常の暗号化では、やり取りする相手同士で同じ鍵を持たなければいけません。 すると、鍵を作った方から相手に送る際に盗まれる危険性があります。 ただし、一度双方が鍵を持てば、同じ鍵で双方向の安全な通信ができます。 SSLは、両方を組み合わせる事で、二つの方式の弱点をカバーしあってるわけですね。 公開鍵暗号方式を使って、データ暗号化の為の鍵（共通鍵ですね）をサーバからクライアントに渡す。このやり取りは一方通行でいいわけですし、暗号化されてますから途中で鍵を盗まれる心配はありません。 そして、この共通鍵を使って、その後のデータの暗号化をする事で、双方向のやり取りを暗号化できると、そういうわけです。 ん～、勉強になった（笑） それともう一つ、認証局の話ですね。 IE6を使ってらっしゃるようですが、私はIE5.5なので、若干メニューが違うかもしれません。 インターネットオプション＞コンテンツ＞証明書 というボタンがあってですね。ここにいわゆる証明書機関が予め登録されています。 これも、証明書というよりも証明書を発行する機関として、信頼するという設定です。 いくらサーバ証明書があっても、証明書自体は、ツールがあれば簡単に生成できます。 問題はそれをどんな証明機関が発行したかって言う点なんですね。IEには、予め有名どころのそういった証明機関が登録されていて、そこが発行したサーバ証明書を持っているかどうかで、信頼の目安としているわけです。 とまあ、そんな感じで訂正とフォローでした。
お礼
you-mさん、ごぶさたしてしまってすみませんでした。 かれこれ1ヶ月もたってしまいました。ごめんなさい。 とっても熱心にご教授いただき有難うございました。 このページは保存版にさせていただきます。 感謝感謝です。 本当に、お礼が遅れてしまってすみませんでした。
- yamma
- ベストアンサー率27% (29/107)
確かに公開鍵と秘密鍵だけだと一方通行になりますが、 通常ブラウザは共通鍵でやりとりをしています。 公開鍵と秘密鍵を使うのは共通鍵を受け渡しする時だけです。 つまり、 １．WebブラウザからSSLによる通信をサーバに要求 ２．署名付きの証明書とサーバの公開鍵を送付 ３．共通鍵をランダムに生成 ４．生成した共通鍵をサーバの公開鍵で暗号化して送付 ５．共通鍵での通信を開始 という事です。
補足
yammaさん、細く有難うございます。 皆さんのおかげで、本当、整理がつきそうでワクワクしています。 もうちょっと、お付き合いお願いしたいです。 お忙しい中すみません××× yammaさんが分かりやすくまとめて下さったので、 イメージがわいてきました。嬉しいです。 っで、質問ですが、３のトコは、私のブラウザソフトが共通鍵を 生成しているんですか? 共通鍵っていうのは、どんな仕事をしているんでしょうか? 公開鍵＝暗号鍵 秘密鍵＝解読鍵って他の方に教えていただいて、私の 中で整理できたトコなんですが… すみませんが、宜しくお願いしたいです。
- you-m
- ベストアンサー率58% (190/327)
SSL自体は、特にWebでの暗号化に特化したものではありません。いわゆる公開鍵暗号を利用した暗号化通信方式です。telnetやftpに実装されたものもあります。 基本的には、暗号化する為の鍵（公開鍵）と、それを解読する為の鍵（秘密鍵）がペアをペアで生成します。 情報を送信する側は、公開鍵を使用して暗号化します。受信した側は、秘密鍵で解読します。 Webで使用される場合、公開鍵にはそのサーバのデジタル証明書が使用されます。誰のどういうサーバであるという証明書です。この証明書は認証局がそのサーバの秘密鍵から生成します。一般的にはベリサイン等の有名な認証機関に証明書を発行してもらいますが、自前で発行しても機能的には違いがありません。NTサーバ+オプションパックや2000サーバ等では、その為の機能があります。 違いは、ブラウザ側で標準で認められた認証局では無い為、そのデジタル証明書を使用する際に警告が出るだけです。(そのサーバの証明書に対する信用の違いですね) Webでの一般的な使われ方では、個人情報の入力フォーム等ですが、送信側は当然ブラウザ、受信側がサーバになります。最初にhttps://～のURLに飛んだ際に、サーバ側からサーバ証明書が送られてきます。以降のブラウザからの送信は、https://のURLから抜けるまで、その証明書で暗号化されて送信されるわけです。 このように、一般的なSSLによる暗号化は「一方通行」です。 サーバから、ブラウザに送信されてくる情報、つまりブラウザの画面に表示されている情報は暗号化されて届いたものではありません。この点を誤解されている方は結構多いので、気をつけるべきでしょう。入力フォームを用意してあるサイトには、せっかくSSLを使用しているのに、確認のためにサーバからデータを送り返してるサイトも見受けられます。この場合、すべてのデータは無防備な状態でブラウザに送信されているという事です。 もちろん、サーバからブラウザ向けの通信を暗号化する事も可能です。ただしこの場合には、そのブラウザ（クライアント）側で自分自身を証明するデジタル証明書が必要となります。最近は、個人証明書を利用する仕組みも徐々に増えてきましたから、もう少しすれば個人でデジタル証明書を持つ事も一般的になるかもしれません。 とまあ、あまり分かりやすい説明では無かったかもしれませんが、参考になりましたでしょうか。 さすがに、あまり詳細には説明し切れませんし、間違ってる部分もあるかもしれませんので、知見のある方、フォローしてください。
補足
you-mさん、とってもとっても丁寧に有難うございました。ここは本当、いい人ばっかりで嬉しいです。 繰り返し読ませていただき、ちょっと謎の闇から抜け出せそうです。 でも、ちょっと疑問がありましたので、再度質問をお願いしたいです。 ＞この証明書は認証局がそのサーバの秘密鍵から生成します。一般的にはベリサイン等の有名な認証機関に証明書を発行してもらいます っということは、私の使用しているブラウザソフト（IE6）に 最初から入っているベリサインの証明書ってのは、特に 使われずにHTTPSの通信のやり取りがされているんですか？ 以前から何のためにたくさんの証明書があるのか不思議だったのです。 あと、SSLは443ポートでのやり取りになるって何かで読んだのですが、 私がHTTPSのURLを要求した場合、その要求データから（サーバへ向かうデータから）443でやり取りが行われるんですか? 理屈の整理がつかないって気持ち悪くって… お忙しい中すみませんが、もうしばしお付き合いをお願いしたいです。 宜しく宜しくお願いします。
- akinya
- ベストアンサー率50% (3/6)
参考URLを見てみてください。
お礼
ご教授有難うございました。 早速拝見いたしました。っが、詳しすぎて今ひとつ 理解が出来ませんでした。 レベルが低くてすみません。 もうすこしPCに関して詳しくなってからでしたら、 理解も可能かもしれませんが… でもでもよいページをご紹介くださってありがとうございました。
お礼
yammaさん、御礼が遅れてしまいすみません。 こんなに熱心に教えていただいたって言うのに… 本当にお詫びいたします。 ここまで丁寧に説明がある本ってあるようでないんですよね。 繰り返し読み返して、理解を深められるよう頑張ります。 どうもありがとうございました。