• ベストアンサー

SSLの暗号化について

ミルです。 SSLの暗号化の仕組みについて易しく教えていただきたいです。 SSLのWebページで情報を送信すると、どんなしくみで 送信側と受信側で鍵をやりとりするってことなんでしょうか? 本を読んでもよくわかんなくって。

noname#222815
noname#222815

質問者が選んだベストアンサー

  • ベストアンサー
  • yamma
  • ベストアンサー率27% (29/107)
回答No.6

追加の質問をよく見てなかったので補足です。 ちょっとごちゃごちゃしますが、証明書についてと受け渡しについてです。 第三者認証機関(仮にベリなんちゃら)の公開鍵は証明書とともに 既にブラウザに入っている事はご存じの通りです。 A社のサーバーがSSLの要求を受けると、ベリなんちゃらの証明書を送ってきます。 その証明書にはA社の公開鍵が入っており、ベリなんちゃらの秘密鍵で暗号化されています。 それをブラウザに既に入っている、ベリなんちゃらの公開鍵で復号化します。 取り出したA社の公開鍵はベリなんちゃらが保証していますので、この公開鍵で 複合化出来るデータはA社からの物に間違いない。となります。 ポイントは、A社がベリなんちゃらに認証の申請をする際にも、 公開鍵とA社の情報を伝えるだけなので、 「まったく本当にA社以外には秘密鍵に触れていない」 という事です。 で、その公開鍵を使って、共通鍵を作るための乱数データを暗号化して A社のサーバーに送り、A社は秘密鍵を使ってそれを複合化して、自分が 作った乱数を加えて・・・・と、共通鍵の生成に入るのですが、 実はSSLの要求の時点と、それに対して証明書を送り返す時点で、 一回限りの乱数を互いが互いに送り合っていて、 (その乱数+上の乱数データ)×アルゴリズム でそれぞれの共通鍵をつくるようです。 (詳しく説明する自信がないのでこれくらいでご勘弁) 〆として、信頼性の問題としては一般的に ・共通鍵の信頼性は鍵の長さに比例する。 ・公開鍵・秘密鍵の信頼性は数学的根拠による。 と言われています。 これでどうでしょうか。

noname#222815
質問者

お礼

yammaさん、御礼が遅れてしまいすみません。 こんなに熱心に教えていただいたって言うのに… 本当にお詫びいたします。 ここまで丁寧に説明がある本ってあるようでないんですよね。 繰り返し読み返して、理解を深められるよう頑張ります。 どうもありがとうございました。

その他の回答 (5)

  • yamma
  • ベストアンサー率27% (29/107)
回答No.5

>3のトコは、私のブラウザソフトが共通鍵を >生成しているんですか? ブラウザとサーバーがそれぞれ生成します。 ブラウザから暗号化して送るためのブラウザ用共通鍵と サーバーから暗号化して送るためのサーバー用共通鍵が あります。 (つまりお互いがブラウザ用とサーバー用の共通鍵を 両方持ちます) 共通鍵の利点は、 ・鍵が一つで良い  (ブラウザ用鍵で暗号化したデータは   ブラウザ用鍵で復号する)  (サーバー用鍵で暗号化したデータは   サーバー用鍵で復号する) ・暗号化・複合化のスピードが速い という点だと言われています。 >共通鍵っていうのは、どんな仕事をしているんでしょうか? 一般的な暗号化と複合化です。 お互いが同じ暗号表をもって、文字を置き換えて 読むのと同程度です。 しかし、その暗号表を「絶対に他人が持っていない」と 確信出来れば安心です。 その為にお互いが暗号表を送り合うのに公開鍵・秘密鍵を 使います。 >公開鍵=暗号鍵 >秘密鍵=解読鍵って他の方に教えていただいて、私の この場合を具体的にお話ししますと 私たちは、例えばA社の公開鍵でデータを暗号化して送り、 A社は秘密鍵で解読します。 一方、A社はデータを秘密鍵で暗号化してこちらに送り、 私たちはA社の公開鍵を使って解読します。 つまりどちらも暗号化・復号化が出来るのですが、 秘密鍵で暗号化した物を秘密鍵で解読したり、 公開鍵で暗号化した物を公開鍵で解読したりは出来ないのがポイントです。 この性質を利用すれば、第三者に「これは確かにA社の 公開鍵だ」と 証明してもらうだけで、私たちが間違いなくA社とデータの やりとりをしているのだという事が保証されるわけです。 (A社の公開鍵で復号できた=A社の秘密鍵で暗号化した) (A社の公開鍵で暗号化した=A社の秘密鍵でしか解読出来ない) ちょっとややこしくなってしまったかもしれません。 ちなみに、少し前に 「SSLの鍵の長さが40ビットから128ビットになった」 という話を聞いたかもしれませんが、これは共通鍵の長さの事です。 (公開鍵・秘密鍵の長さは512ビットor1024ビットです。) こんな感じでいかがでしょうか。

  • you-m
  • ベストアンサー率58% (190/327)
回答No.4

気になってもう一度調べなおしました。 yammaさんの言うとおり、公開鍵暗号方式で”実際のデータの暗号化をする為の鍵”をやり取りするが正解でした。 ここで言う共通鍵は、公開鍵暗号方式でない、暗号化と解読両方ができる鍵です。 公開鍵暗号方式の良い点は、解読の為の鍵を、外部に一切出す必要が無い事です。逆に不便な点は、前の私の説明のとおり、一組のキーペアでできる通信は一方通行だという点です。 通常の暗号化では、やり取りする相手同士で同じ鍵を持たなければいけません。 すると、鍵を作った方から相手に送る際に盗まれる危険性があります。 ただし、一度双方が鍵を持てば、同じ鍵で双方向の安全な通信ができます。 SSLは、両方を組み合わせる事で、二つの方式の弱点をカバーしあってるわけですね。 公開鍵暗号方式を使って、データ暗号化の為の鍵(共通鍵ですね)をサーバからクライアントに渡す。このやり取りは一方通行でいいわけですし、暗号化されてますから途中で鍵を盗まれる心配はありません。 そして、この共通鍵を使って、その後のデータの暗号化をする事で、双方向のやり取りを暗号化できると、そういうわけです。 ん~、勉強になった(笑) それともう一つ、認証局の話ですね。 IE6を使ってらっしゃるようですが、私はIE5.5なので、若干メニューが違うかもしれません。 インターネットオプション>コンテンツ>証明書 というボタンがあってですね。ここにいわゆる証明書機関が予め登録されています。 これも、証明書というよりも証明書を発行する機関として、信頼するという設定です。 いくらサーバ証明書があっても、証明書自体は、ツールがあれば簡単に生成できます。 問題はそれをどんな証明機関が発行したかって言う点なんですね。IEには、予め有名どころのそういった証明機関が登録されていて、そこが発行したサーバ証明書を持っているかどうかで、信頼の目安としているわけです。 とまあ、そんな感じで訂正とフォローでした。

noname#222815
質問者

お礼

you-mさん、ごぶさたしてしまってすみませんでした。 かれこれ1ヶ月もたってしまいました。ごめんなさい。 とっても熱心にご教授いただき有難うございました。 このページは保存版にさせていただきます。 感謝感謝です。 本当に、お礼が遅れてしまってすみませんでした。

  • yamma
  • ベストアンサー率27% (29/107)
回答No.3

確かに公開鍵と秘密鍵だけだと一方通行になりますが、 通常ブラウザは共通鍵でやりとりをしています。 公開鍵と秘密鍵を使うのは共通鍵を受け渡しする時だけです。 つまり、 1.WebブラウザからSSLによる通信をサーバに要求 2.署名付きの証明書とサーバの公開鍵を送付 3.共通鍵をランダムに生成 4.生成した共通鍵をサーバの公開鍵で暗号化して送付 5.共通鍵での通信を開始 という事です。

noname#222815
質問者

補足

yammaさん、細く有難うございます。 皆さんのおかげで、本当、整理がつきそうでワクワクしています。 もうちょっと、お付き合いお願いしたいです。 お忙しい中すみません××× yammaさんが分かりやすくまとめて下さったので、 イメージがわいてきました。嬉しいです。 っで、質問ですが、3のトコは、私のブラウザソフトが共通鍵を 生成しているんですか? 共通鍵っていうのは、どんな仕事をしているんでしょうか? 公開鍵=暗号鍵 秘密鍵=解読鍵って他の方に教えていただいて、私の 中で整理できたトコなんですが… すみませんが、宜しくお願いしたいです。

  • you-m
  • ベストアンサー率58% (190/327)
回答No.2

SSL自体は、特にWebでの暗号化に特化したものではありません。いわゆる公開鍵暗号を利用した暗号化通信方式です。telnetやftpに実装されたものもあります。 基本的には、暗号化する為の鍵(公開鍵)と、それを解読する為の鍵(秘密鍵)がペアをペアで生成します。 情報を送信する側は、公開鍵を使用して暗号化します。受信した側は、秘密鍵で解読します。 Webで使用される場合、公開鍵にはそのサーバのデジタル証明書が使用されます。誰のどういうサーバであるという証明書です。この証明書は認証局がそのサーバの秘密鍵から生成します。一般的にはベリサイン等の有名な認証機関に証明書を発行してもらいますが、自前で発行しても機能的には違いがありません。NTサーバ+オプションパックや2000サーバ等では、その為の機能があります。 違いは、ブラウザ側で標準で認められた認証局では無い為、そのデジタル証明書を使用する際に警告が出るだけです。(そのサーバの証明書に対する信用の違いですね) Webでの一般的な使われ方では、個人情報の入力フォーム等ですが、送信側は当然ブラウザ、受信側がサーバになります。最初にhttps://~のURLに飛んだ際に、サーバ側からサーバ証明書が送られてきます。以降のブラウザからの送信は、https://のURLから抜けるまで、その証明書で暗号化されて送信されるわけです。 このように、一般的なSSLによる暗号化は「一方通行」です。 サーバから、ブラウザに送信されてくる情報、つまりブラウザの画面に表示されている情報は暗号化されて届いたものではありません。この点を誤解されている方は結構多いので、気をつけるべきでしょう。入力フォームを用意してあるサイトには、せっかくSSLを使用しているのに、確認のためにサーバからデータを送り返してるサイトも見受けられます。この場合、すべてのデータは無防備な状態でブラウザに送信されているという事です。 もちろん、サーバからブラウザ向けの通信を暗号化する事も可能です。ただしこの場合には、そのブラウザ(クライアント)側で自分自身を証明するデジタル証明書が必要となります。最近は、個人証明書を利用する仕組みも徐々に増えてきましたから、もう少しすれば個人でデジタル証明書を持つ事も一般的になるかもしれません。 とまあ、あまり分かりやすい説明では無かったかもしれませんが、参考になりましたでしょうか。 さすがに、あまり詳細には説明し切れませんし、間違ってる部分もあるかもしれませんので、知見のある方、フォローしてください。

noname#222815
質問者

補足

you-mさん、とってもとっても丁寧に有難うございました。ここは本当、いい人ばっかりで嬉しいです。 繰り返し読ませていただき、ちょっと謎の闇から抜け出せそうです。 でも、ちょっと疑問がありましたので、再度質問をお願いしたいです。 >この証明書は認証局がそのサーバの秘密鍵から生成します。一般的にはベリサイン等の有名な認証機関に証明書を発行してもらいます っということは、私の使用しているブラウザソフト(IE6)に 最初から入っているベリサインの証明書ってのは、特に 使われずにHTTPSの通信のやり取りがされているんですか? 以前から何のためにたくさんの証明書があるのか不思議だったのです。 あと、SSLは443ポートでのやり取りになるって何かで読んだのですが、 私がHTTPSのURLを要求した場合、その要求データから(サーバへ向かうデータから)443でやり取りが行われるんですか? 理屈の整理がつかないって気持ち悪くって… お忙しい中すみませんが、もうしばしお付き合いをお願いしたいです。 宜しく宜しくお願いします。

  • akinya
  • ベストアンサー率50% (3/6)
回答No.1

参考URLを見てみてください。

参考URL:
http://www.atmarkit.co.jp/fnetwork/rensai/pki03/pki01.html
noname#222815
質問者

お礼

ご教授有難うございました。 早速拝見いたしました。っが、詳しすぎて今ひとつ 理解が出来ませんでした。 レベルが低くてすみません。 もうすこしPCに関して詳しくなってからでしたら、 理解も可能かもしれませんが… でもでもよいページをご紹介くださってありがとうございました。

関連するQ&A

  • SSLの原理?

    「SSLのフォームに入力された情報は自動的に暗号化されて送信される」という説明がよくあるのですが、ユーザから送られた内容がSSLサーバ内で暗号化されるのではないのでしょうか?サーバで暗号化されるのであれば、サーバへ到達するまでは暗号化されないのでしょうか?もしくはユーザが送信する時点で暗号化されるのしくみということなのでしょうか?つまり、SSLサーバは「解読機」ということになるのかな?また、「SSLサーバはWebサーバのすぐ隣にないと意味がない」という見解を何かで読んだのですが、これはつまり「WebサーバとSSLサーバの間のやり取りは暗号化されない」ということでしょうか?私がWebページを作っているクライアントに説明を求められています。よろしくお願いします。

  • SSL暗号化の仕組みについて教えてください

    SSL暗号化の仕組みについて、教えてください。 公開鍵を使って共通鍵を生成し、共通鍵で通信をすることで傍受やなりすましによる情報漏えいを防ぐということはわかるのですが、 第三者が公開鍵も、共通鍵も傍受して、情報を傍受していたら情報漏えいのリスクは完全には排除できないような気がするのですが、その点にまでコメントされたものは本でもネットでも見当たらなかったので、 どなたかご存知の方がいらっしゃればご解説願います。 http://www.soumu.go.jp/joho_tsusin/security/kiso/k01_ssl.htm

  • SSLによる通信について

    WWWにおける、公開鍵方式による暗号化について質問です。 SSLを使ったHPでは ブラウザ→サーバー  暗号化されている サーバー→ブラウザ  ??? あるHPにおいてブラウザから個人情報を入力し、 サーバーに送信すると、SSLを使っている場合、 情報は暗号化されて送られますよね。 逆に、個人情報の変更などをする場合、サーバーに保存されてあった 個人情報が、クライアント側に送られてくるわけですが、 このときには情報は暗号化されているのでしょうか? しくみまで詳しく分かっているかた教えてください。 おねがいいたします。

  • SSLでの暗号化は必須でしょうか?

    ネットショップをひらく計画をしています。 ショッピングカートを導入して注文を受けるしくみを作っています。 (つまり自前で製作) 大手などのネットショップは個人情報を入力時、ほとんどがSSLによるデータの暗号化を行うページとなっております。 しかし当方のネットショップは、決済方法にクレジットカード払いはないので、注文者が入力するのは住所や名前、電話番号などになります。 それでも、SSLでの暗号化というものは信頼や安心度という点から、導入するにこしたことはないかと思うのですが、購入者側の心理もやはり同じようなものでしょうか? (別に住所や電話番号が重要度の低い情報だと言ってるわけではありませんが) また、万全を期すためクレジット決済のない場合でもページを暗号化するべきとなると、今度はメールで注文を受けるということもセキュリティの面からできなくなるかと思います(しかしショッピングカートが使用できないブラウザを使用してる人もいるので、メールでの注文を受けることも必要なのです) 質問内容は、 1.クレジット決済がなくてもSSLでの暗号化ページは必要か? 2.SSLを使用してページを作っているのに、メールで受注可能とするのはおかしいですか?

  • 非SSLページからSSLページへの遷移時の暗号化

    SSLについて人によって意見がまちまちな問題が 浮上しており、困っております。 ぜひお詳しい方のお知恵をお借りできたらと思い投稿させていただきました。 非SSLページ(入力フォーム)→SSLページ(確認ページ) という単純な遷移です。 非SSLページは静的なhtmlファイルで 個人情報を入れてpostでsubmitするフォームになっています。 このとき、私の認識では、個人情報は暗号化されると 思っていました。 しかし、入力フォームもSSLページでなければ暗号化 されないという意見とそうでない意見が交錯しています。 遷移先がSSLであれば、証明書等チェックが入って 最終的にフォームの値含め、通信データは暗号化されて送信 されると思っていますが間違っているでしょうか? ちなみに個人情報を入れるページは心理的にはhttps であったほうがいいということは間違い無いと思います。 技術的な見地でお願いします。 よろしくお願いしますm(_ _)m

  • InfoseekメールはSSLで暗号化受信送信がしていないと分かりGm

    InfoseekメールはSSLで暗号化受信送信がしていないと分かりGmailを持ちましたが他にもう一つ無料の物を持ちたいと思っています。検索したら無料のAOLメール、怪しそうなとくとくメールという物がありました。AOLメールはSSLで暗号化受信送信は出来ますか?とくとくメールとは安全なメール、SSLで暗号化受信送信は出来ますか?他にSSLで暗号化受信送信が無料で使用出来るものが有りますか? 詳しい方、教えてくざさい。お願い致します。

  • SSL暗号化通信について

    SSL暗号化通信について教えてください。ホームページ上で、SSL暗号化通信で送信する形式に書き込みをすると、自分のアドレスは特定されるのですか。

  • SSLについて

    SSL (コンピュータどうしの通信の内容を暗号化して情報をより安全にやり取りするため) あるページにログインしょうとした時、環境がSSLに対応していない可能性がありますと出てログインが出来ません、SSLに対応するにはどうすれば良いのですか、 他のページではログインが出来ています。 PC Win98

  • SSL暗号化通信

    このページの入力項目は すべて、SSL暗号化通信によって保護されますって 書いてあれば、ウイルスとかに感染してても(してないと思うけど)個人情報を入力しても大丈夫ですか? 個人情報を盗まれないですか?

  • フリーCGIで出来たメールにSSLをかけるには?

    フリーCGIで出来たメールフォームを、ホームページに設置予定です。 サーバーのメールの仕組みからではなく、 CGIから発信される仕組みのようです。 このメールフォームには個人情報を書き込む項目が設けられているので、 SSLをかけて暗号化された状態で送信者から受信者まで届く仕組みにしたいと考えています。 暗号化されてほしいのは、 【発信者】~【サーバー】~【インターネット】~【受信者】 の間すべてです(「~」の部分です)。 色々調べてみたところ、 「CGIから発信されるタイプのメールにはSSLはかけられない」 「サーバー自体にSSLがかかっているのでSSLはかけられる」 「発信者とサーバーの間だけがSSLで、  サーバー以降にはSSLがかからない」 「発信者~受信者までの道程全てにSSLをかけるには  ベリサインセキュアメールIDの取得が必要だが高額、  設置もプログラム知識が無いとムリ」 等、どの情報が正しいのか判別がつかない状態です。 CGIから発信される仕組みのフリーCGIで出来たメールにSSLはかけられますか?それにはどのような準備が必要でしょうか?どなたか、助けてください。よろしくお願いします。

    • 締切済み
    • CGI