• ベストアンサー
  • 困ってます

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

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

共感・応援の気持ちを伝えよう!

  • 回答数2
  • 閲覧数216
  • ありがとう数7

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

  • ベストアンサー
  • 回答No.2
  • ngsvx
  • ベストアンサー率49% (157/315)

質問者さんの知識がどの程度かわからないため、 概要を簡単に説明します。 暗号化の方式は大きく分けて次の2通りがあります ●公開鍵暗号方式  公開鍵で暗号化し、秘密鍵で復号化します。  公開鍵で暗号化したものは、秘密鍵を使わないと復号化できません。  (公開鍵では復号化できません) ●共通鍵暗号方式  暗号化、復号化ともに同じ鍵を使用します。 公開鍵暗号方式を使えば全て解決しそうですが、こちらは処理に時間がかかる等の欠点があります。 そのためSSLでは、次のようなことを行います。 ・データそのものの暗号化は共通鍵で行う。 ・データを暗号化した時の共通鍵は、公開鍵で暗号化し相手サーバーに渡す。 そのため、共通鍵は傍受されても、それは公開鍵で暗号化されているため問題ありません。 また、公開鍵を知られても秘密鍵がなければ復号化できないわけですから、問題ありません。 ちなみに、秘密鍵で暗号化すると公開鍵でしか復号化できなくなります。 これを利用したものが電子署名です。 以前同じようなことを答えたので、よろしければ参考にして下さい。 http://oshiete1.goo.ne.jp/qa1024098.html

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ご丁寧な解説、そして過去の回答事例間教えていただき、どうもありがとうございます。 そもそも、このような分野に明るくないので、ちょっともやもやしている部分はありますが、なんとなくイメージがつかめた気がします。

関連するQ&A

  • 自己署名証明書(オレオレ証明書)の暗号化について

    SSL暗号化通信の仕組み自体は,下記URLの通りとして把握しております. (1*) http://www.twsvc.com/about_ssl (2*) http://www.ibm.com/developerworks/jp/websphere/library/web/web_security/pdf/2_6.pdf これを,オレオレ証明書を用いた暗号化通信で考えると,セキュリティに関する識者である高木氏は,自分の日記にて以下のように書いています. >共通鍵暗号による暗号化通信をしています。鍵は一緒に配送します。この暗号は正常に機能しているでしょうか? >「今の話は共通鍵暗号じゃなくて公開鍵暗号だろ」って? オーケー、では、次の比較に対してどう答えるか。 >1.共通鍵暗号による暗号化通信 >2.公開鍵暗号による暗号化通信で認証なし(認証検証時の警告を無視する使用形態) >3.公開鍵暗号による暗号化通信で認証あり (略) >では、1.と 2. を比べたときはどうか。「3.ほどではないが 1.よりは 2. の方がまし」と言えるだろうか? それは誤りである。 (略) >公開鍵暗号の公開鍵がいっしょに配送されている暗号化通信では、傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえば、それで暗号化されて戻ってくる暗号文を復号できる。 ※詳細は,高木氏の「PKIよくある勘違い(1)「オレオレ証明書でもSSLは正常に機能する」」をご参照ください. ここで,疑問になるのが,”傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえばいい”という点です. オレオレ証明書では,ルート証明書にたどり着けないため,ブラウザはオレオレ認証局の公開鍵をもっていない. そのため,サーバ証明書内の公開鍵を取得できない. だから,サーバ証明書送付時にオレオレ認証局の公開鍵を送付する必要がある. オレオレ認証局の公開鍵を用いて,サーバ証明書から公開鍵を抜き出す もしこのとき,オレオレ認証局の公開鍵が自作鍵に置き換えられたとしても,ただ単にサーバ証明書から公開鍵を抜き出すことができず,そこで通信が終了すれば”それで暗号化されて戻ってくる暗号文を復号できる”ことも無いように思えるのですが,いかがでしょうか. (つまり,高木氏の言う差し替えた自作鍵でサーバ証明書内の公開鍵が取得できるかどうか) これができなければ,確かに暗号化通信(というか通信そのもの)自体は破綻していますが,高木氏の懸念しているような「重要な情報の流出」にはつながらないように思えます. 乱文になってしまいまして申し訳ありません. もし,私自身に勘違いや解釈違い等ありましたら,ご指摘いただけると幸いです. よろしくお願いします.

  • HTTPS(SSL)の仕組みとセキュリティについて

    SSLの仕組みと,そのセキュリティについての質問です. 現在,HTTPSで利用するSSLの仕組みについて勉強をしています. しかしながら, 自身がSSLの仕組みについて正しく理解できているか分かりません. また,どうしても理解ができない点が何個かあり,質問させて頂く次第になりました. (様々な書籍やwebを拝見したのですが,いづれも腑に落ちませんでした...) そのため,まず大まかに私が理解しているHTTP上のSSLの仕組みを書き,最後に質問を書かせて頂こうかと思います. 長くなりますが宜しくお願い致します. ■主な登場人物 ・認証局  CA秘密鍵  CA証明書(公開鍵?)  CA証明書発行要求  ・証明書  KEYファイル(秘密鍵/公開鍵)  CSRファイル/申請書(issuer側の情報/公開鍵)  CRTファイル/サーバー証明書(CSRを認証局の秘密鍵で捻ったモノ) ■証明書の発行 1-1.証明書を発行したい者がCSRファイルという申請書を作成し,認証局に送ります.    →CSRには登録情報(issuer)やサーバー(証明書を発行したい者)の公開鍵などが含まれます. 1-2.認証局はCSRファイルが適切であれば,署名(subject)し,認証局の秘密鍵でCSRの中の公開鍵のみを暗号化します. 1-3.これがCRTファイルになり,証明書を発行したい者に送り返されます. この時,サーバー(証明書を発行した者)は認証局によって署名されたCRTファイルを持っています. 次にこれを利用したHTTPS通信について書きます. ■HTTPS通信 2-1.クライアントがサーバーに通信要請をします. 2-2.サーバーは証明書(CRT)をクライアントに送ります. 2-3.クライアントは送られてきたCRTが信頼できるか認証局の証明書(公開鍵)を使って検証します.    →CRTに埋め込まれているサーバーの公開鍵は認証局の秘密鍵によって暗号化されているので,これを認証局の公開鍵で複合化します.    →認証局の公開鍵はルート証明書といい,事前にブラウザに組み込まれているものとします. 2-4.クライアントは共通鍵を発行します. 2-5.クライアントはCSRから複合化したサーバーの公開鍵を用い,自身で発行した共通鍵を暗号化してサーバーに送ります 2-6.サーバーは受け取った暗号データを自身の持つ秘密鍵で複合化し,共通鍵を取得します. 2-7.後はこの共通鍵でデータを暗号化し通信します, ■質問 1.オレオレ証明書+認証局の場合でも正常に通信ができるのはなぜか 私の理解だと2-3で,クライアントが認証局の公開鍵を用い,サーバーの証明書からサーバーの公開鍵を複合化し,それを元に共通鍵を暗号化しています. これはクライアントが認証局のルート証明書(公開鍵)を保有しているから複合化できるはずです. オレオレ証明書の場合は,認証局の公開鍵がクライアントにインストールされていません. そのため,サーバーの公開鍵を複合化できず,共通鍵の生成に失敗し,通信できなくなると思います. しかしながら,ブラウザは「署名が不明な接続先です」とのエラーを出すだけで,通信(接続)ができてしまいます. なぜでしょうか. 2.IssuerとSubjectは暗号化されていないのか 私の理解だと1-2の認証局では,サーバーの公開鍵しか暗号化されていません. ということはIssuerとSubjectは暗号化されていないということでしょうか. また,それはなぜでしょうか. 3.IssuerとSubjectは偽装できるか opensshを用いることで認証局を構築することができます. この時に,Subjectの設定をベリサインの認証局と全く同じようにし, 証明書も,ベリサインの認証局を使っているサイトのIssuerと全く同じようにした場合, SubjectとIssuerが全く同じ証明書ができると思います. この場合は,本物の証明書と同様の証明書を複製できてしまうのでしょうか. できないとは思いますが,それはなぜでしょうか. 4.証明書の偽装は可能か ブラウザから証明書の情報を見ることができます.もちろんbyteデータのraw certificateも見ることができます. この情報を丸々コピーし,全く異なるサーバーに証明書として読みこませて通信した場合は, 署名されてしまうのでしょうか. されないとは思いますが,それはなぜでしょうか. (例えば,URL=CN情報が異なっているから確認できるとか..?それならCN情報だけ書き換えてしまえばいい?) 5.証明書の検証をするにはどうしたらよいか 証明書を検証をするには,その証明書を発行した認証局の公開鍵を利用するしかないのでしょうか. 例えば,サーバー証明書(CRT)のフィンガープリントsha1データを事前に保持さえしていれば, サーバーに証明書を示された際にCRTのフィンガープリントを比較すれば,特定のサーバーかどうか検証できるか・・? 6.MITMについて MITM攻撃により,証明書が途中で書きかわることが考えられます. この場合は,書き換わった証明書をどのように特定すればいいのでしょうか. 例えば,認証局のルート証明書がないなどが考えられますが, 仮に,Rapid SSLなどで署名されている証明書でMITM攻撃がされた場合どうなるでしょうか? この場合は,Issuerなどを比較するしかないように考えられます. しかし,Issuerはcsr申請の際にうまいこと,書き換えることができてしまいます. そう考えると,どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか, フィンガープリントは偽装することができないのでしょうか. 以上となります. 様々な質問を書いてしまい,申し訳ありません 説明不足で乱文だとは思いますが, 分かる範囲でお答え頂けませんでしょうか. 宜しくお願い致します.

  • 暗号化

    SSHとSSLの違いを教えてください. SSHとSSLの暗号の仕方は同じですか?両方ともサーバ公開鍵でクライアントの共通鍵を送り,データの暗号は共通鍵で行いますか?

その他の回答 (1)

  • 回答No.1
  • FEX2053
  • ベストアンサー率37% (7930/21154)

実際その通りで、SSL通信の「そのセッションで使用する」共通鍵を 破られたら、通信内容は丸判りです。ですので、その共通鍵はとても 長い文字列の「鍵」を3重に掛けて送っています(3DESと言います)。 また、その「鍵」はその通信限りの使い捨てですから、仮にひとつの 通信で解析できたとしても、次の通信では使えません。結果として 「長い時間をかけて鍵が解析できたとしても意味がない」わけで、 「解析に時間のかかる長い鍵」と合わせて、セキュリティを確保して いるのです。 なお、同様な理由で「秘密鍵」を知られてもダメになるのですが、 これは「ベリサイン」などのSSLセッションを提供している会社が 厳重に保管して外部に漏らさないようになっています。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

わかりやすいご説明、どうもありがとうございました。

関連するQ&A

  • SSLの暗号化について

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

  • 暗号化の鍵について

    情報処理技術者試験に暗号化の公開鍵や秘密鍵や共通鍵に関連した問題が出題されることがあります。この暗号化は一般の使用者が実際使うのではなく,情報処理技術者のSEやプログラマーなどの仕事をしている人が使用しているのでしょうか。具体例を教えてください。 一方で,ネットのhttpsのsがついている場合は暗号化されているというのをきいたことがありますが、これはネットワーク管理者が暗号化しているのでしょうか。 誰がどのように鍵を作り、システムに組み込んでいるのかイメージしたいので教えてください。 宜しくお願いいたします。

  • SSL での 公開鍵、秘密鍵

    Gメールで、POP接続してメールを取り出すときは、 SSL(TLS)での接続となります。 ここで、RSA暗号を使う場合の、公開鍵を秘密鍵のセットは 接続した瞬間に作成されるのでしょうか? それとも、既に作ってある公開鍵と秘密鍵のセットが選ばれるのでしょうか? もし、既に作ってあるセットの中から選ぶ場合には、 鍵のセットはサーバーの中に何セットくらい用意されているのでしょうか? WireShark で、SSL の暗号化を解読してパケットの中を見る方法があるとのことで、 すこし、気になっています。 お分かりの方よろしくお願いいたします。   参考: https://www.softbanktech.jp/yko/2010/07/001129.html

  • SSLについて・・・

    SSLは公開鍵方式・共通鍵方式を使用する、つまり、ハイブリット式  だと言うことは分かるのですが、デジタル署名方式も用いる!と単語を調べると書かれています。 SSLとは色々な鍵交換方式を用いて安全にコミュニケーションを行うことなのですか? また、OSI基本参照とはどのような事なのですか? 頭文字で、上位層からアプセトネデブと覚えましたが意味が分かりません。 例えばネットワーク層ではどのような事が行われているのですか? お手数ですが教えてください!お願いします!

  • RSAによる暗号化について

    よくRSAでの暗号化で鍵の長さが512ビットや1024ビットなどのものがありますが、これは公開鍵eと秘密鍵dと共通鍵nのどの鍵が512ビットなのでしょうか?自分の中では512ビットの鍵であれば全て(e,d,n)は512であると思っているのですが、dを計算する時(ユークリッド互除法を用いる)、どうしてもdはeやnの鍵の長さの2倍のビット長が必要な気がします。どうしてもわかりません。鍵のビット長について教えてください。お願いします。

  • SSLの仕組みについて整理したい事

    本を読んでると 色々用語が出て何か混乱してるのですが・・・ 単純に・・・と言うか要約すると サーバー側で秘密鍵・証明書を作って 証明書は信頼できるクライアントに配布して クライアントはそれなりソフトを開いて(例えばSSLもできるFTPソフト) 証明書を使ってアカウント入力し、データを送信 で、サーバー側で秘密鍵で開ける・・・って手順なんでしょうか? 一つの本には単純に秘密鍵作成と証明書作成だけ書いてて もう一つの本は詳しく?掘り下げて サーバ証明書・サーバ公開鍵・サーバ秘密鍵・証明局公開鍵 とかあって、何だか判り辛いです・・・ サーバ証明書が公開鍵にあたるのかと思ってました (データの開け閉めに対して鍵はペアだから、やりとりするのに3つ以上も必要なんでしょうか???) ちなみに サーバ・CENTOS 6 と クライアント・WINDOWS 7 でやってます イマイチイメージがしにくいです よろしくお願いします

  • SSL/TLSについて、誤っているものを教えて下さ

    1 SSL.TLSは、httpやsmtpなどと組合せることができる 2 SSL/TLSは、公開鍵が偽造されていないことを前提とする 3 SSL/TLSは、サーバ側の秘密鍵が漏洩していないことを前提とする 4 SSL/TLSは、サービス提供者の認証をするためだけの技術であり、守秘の機能を有していない

  • SSLの信頼性について

    ネット販売の代金決済にSSLによる暗号化通信があります。以前に知人がクレジットカードによるSSL決済でURLのプロトコルhttpsの確認、右下タスクトレイ上に鍵マーク確認、カギマークから発行元証明書の確認もしたようです。しかし結果して悪用されたそうです。その話を聞いて私はネット上のSSLを信頼していません。下記についてご助言を頂きたいと思います。 (1)ブラウザで公開鍵で暗号化し、送信したデータが    通信経路上で秘密鍵が盗取されてデータが復元さ   れ、情報盗取されることは可能でしょうか。 (2)証明書の発行元の偽装は簡単に行えるのでしょう    か。 (3)発行元が本人(法人)であることは何で確認すれば    安全でしょうか。以上お願いいたします。

  • 暗号化の鍵について

    通信の際の暗号化技術には色々なものがありますが、 鍵って盗むことはできるのでしょうか。私が盗みたい訳ではないんですが、技術として可能のか疑問に思いまして。。。 SSLによる通信の場合であれば、最後に生成される共通鍵が盗めれば、暗号化した情報が読めてしまうわけですよね? でも、鍵って実態のあるものではないと思ったので、どうなんでしょう。 ちょっと変な質問ですが、もしわかる方いらっしゃいましたら、お願いします。

  • SSLの電子証明書を使った身元保証について

    別のカテで質問したのですが回答が得られなかったので、もう一度質問します。 知識がほとんどないまま毎日のようにインターネットを利用しているのでこれではいかんと、独学でインターネットのことについて勉強していて、度々こちらでもわからないことを教えてもらっています。 今日は、セキュリティーのことについて勉強しているところなのですが、SSLの電子証明書を使った身元保証についてわからないことがあるので教えて下さい。 ネット上で商売をしようという業者は、認証局から電子証明書を受け取り、自社のWebサーバーにインストールしておきますよね? 買い物をするとき、顧客はSSLを業者に要求し、業者は電子証明書を送信し、顧客は業者を確認し、共通鍵を作成し、業者の公開鍵で暗号化して共通鍵を送り、業者は自分の秘密鍵で複合する、わけですが、具体的にどういうことなのかわからないんです。 買い物をしようとすると、認証局から電子証明書を受け取っている業者には、錠前のマークが出るんですよね? 錠前のマークをダブルクリックすると「証明書の情報」が開きますよね? 本当は、この情報を元に、相手の身元を確認する作業というのをしなければいけないものなのでしょうか? それとも、錠前マークが出ている時点で、自動的に確認が取れているということなのでしょうか? つまり、何がわからないかと言うと、「買い物をするとき、顧客はSSLを業者に要求し、業者は電子証明書を送信し、顧客は業者を確認し、共通鍵を作成し、業者の公開鍵で暗号化して共通鍵を送り、業者は自分の秘密鍵で複合する」この流れが、具体的にネットショッピングする際のどの作業のことなのかがイメージできないんです。 解説していただけると助かります。