SSL通信と認証局の役割について
- SSL通信とは、Webサーバとクライアント間のデータの暗号化通信を行うためのプロトコルです。
- 認証局は公開鍵を管理し、Webサーバに対して電子証明書を発行します。
- Webサーバは発行された電子証明書を利用して、クライアントから送信された共通鍵を解読します。
- ベストアンサー
下の3つの問題がわからず困っています。知っています方アドバイス下さい。
下の3つの問題がわからず困っています。知っています方アドバイス下さい。 (1)認証局がWebサーバを運営している会社に交付されている電子証明書に入ってる公開鍵は、認証局の公開鍵である？ (2)利用者がWebサーバーを運営する会社の正当性を確認するには、認証局の公開鍵を使う？ (3)利用者から送られてきた暗号化された共通鍵は、Webサーバ側の秘密鍵を使って解読している？ 自分なりの考えは(1)は正解だと思います。認証局は公開鍵を管理する組織だと思います。 (2)も正解だと思います。理由はなんとなくしかわからないので詳しく知っている方いましたら、できれば解説お願いいたします。 (3)これも正解だと思います。共通鍵は秘密鍵を使って解読してると思ったのですが・・・・できればこれも解説お願いいたします。 SSL通信について勉強不足で恥ずかしいのですが、このような問題がわかります方からのアドバイスをいただきたいと思います。 よろしくお願いいたします。
- chopper_v2011v
- お礼率90% (20/22)
- ネットワーク
- 回答数1
- ありがとう数2
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
(1) × 電子証明書にはWebサーバの公開鍵が格納されており，認証局の秘密鍵によって電子署名されている (2) ○ 電子証明書は，認証局の秘密鍵で電子署名されているので，それを検証するには認証局の公開鍵を使う (3) ○ 共通鍵は，Webサーバの公開鍵で暗号化されるので，それを解読するにはWebサーバの秘密鍵を使う 参考： 技術者でなくても分かる 電子証明書とPKI入門（理解編）日本ベリサイン https://www.verisign.co.jp/basic/pki/index_practice.html
関連するQ&A
- 以前にも、質問したのですが、この問題だけなかなか納得いかず再度質問させ
以前にも、質問したのですが、この問題だけなかなか納得いかず再度質問させて下さい。 (1)認証局がWebサーバを運営している会社に交付する電子証明書に入ってる公開鍵は、認証局の公開鍵である。 という問題なのですが、これが正しいのか間違いなのかで、間違いなら間違ってる理由を書かなければいけないのですが、 自分なりにここで質問して教えてもらった内容と本などで調べて勉強して考えてみた答えなのですが、 Webサーバーを運営する会社に交付する電子証明書の中の公開鍵はそのWebサーバーを運営する会社のもので、Webブラウザーなどに登録されているのが認証局の公開鍵？なので、この問題は誤りで、認証局の公開鍵ではなく、会社の公開鍵であってますでしょうか？ ここらへんが中々、理解できず困っています。 詳しい方からの、回答お願いいたします。 よろしくお願いいたします。
- ベストアンサー
- ネットワーク
- HTTPS(SSL)の仕組みとセキュリティについて
SSLの仕組みと，そのセキュリティについての質問です． 現在，HTTPSで利用するSSLの仕組みについて勉強をしています． しかしながら， 自身がSSLの仕組みについて正しく理解できているか分かりません． また，どうしても理解ができない点が何個かあり，質問させて頂く次第になりました． （様々な書籍やwebを拝見したのですが，いづれも腑に落ちませんでした．．．） そのため，まず大まかに私が理解しているHTTP上のSSLの仕組みを書き，最後に質問を書かせて頂こうかと思います． 長くなりますが宜しくお願い致します． ■主な登場人物 ・認証局 CA秘密鍵 CA証明書（公開鍵？） CA証明書発行要求 ・証明書 KEYファイル（秘密鍵/公開鍵） CSRファイル/申請書（issuer側の情報/公開鍵） CRTファイル/サーバー証明書（CSRを認証局の秘密鍵で捻ったモノ） ■証明書の発行 １－１．証明書を発行したい者がCSRファイルという申請書を作成し，認証局に送ります． →CSRには登録情報(issuer)やサーバー（証明書を発行したい者）の公開鍵などが含まれます． １－２．認証局はCSRファイルが適切であれば，署名（subject）し，認証局の秘密鍵でCSRの中の公開鍵のみを暗号化します． １－３．これがCRTファイルになり，証明書を発行したい者に送り返されます． この時，サーバー（証明書を発行した者）は認証局によって署名されたCRTファイルを持っています． 次にこれを利用したHTTPS通信について書きます． ■HTTPS通信 ２－１．クライアントがサーバーに通信要請をします． ２－２．サーバーは証明書(CRT)をクライアントに送ります． ２－３．クライアントは送られてきたCRTが信頼できるか認証局の証明書（公開鍵）を使って検証します． →CRTに埋め込まれているサーバーの公開鍵は認証局の秘密鍵によって暗号化されているので，これを認証局の公開鍵で複合化します． →認証局の公開鍵はルート証明書といい，事前にブラウザに組み込まれているものとします． ２－４．クライアントは共通鍵を発行します． ２－５．クライアントはCSRから複合化したサーバーの公開鍵を用い，自身で発行した共通鍵を暗号化してサーバーに送ります ２－６．サーバーは受け取った暗号データを自身の持つ秘密鍵で複合化し，共通鍵を取得します． ２－７．後はこの共通鍵でデータを暗号化し通信します， ■質問 １．オレオレ証明書＋認証局の場合でも正常に通信ができるのはなぜか 私の理解だと2-3で，クライアントが認証局の公開鍵を用い，サーバーの証明書からサーバーの公開鍵を複合化し，それを元に共通鍵を暗号化しています． これはクライアントが認証局のルート証明書（公開鍵）を保有しているから複合化できるはずです． オレオレ証明書の場合は，認証局の公開鍵がクライアントにインストールされていません． そのため，サーバーの公開鍵を複合化できず，共通鍵の生成に失敗し，通信できなくなると思います． しかしながら，ブラウザは「署名が不明な接続先です」とのエラーを出すだけで，通信（接続）ができてしまいます． なぜでしょうか． ２．IssuerとSubjectは暗号化されていないのか 私の理解だと1-2の認証局では，サーバーの公開鍵しか暗号化されていません． ということはIssuerとSubjectは暗号化されていないということでしょうか． また，それはなぜでしょうか． ３．IssuerとSubjectは偽装できるか opensshを用いることで認証局を構築することができます． この時に，Subjectの設定をベリサインの認証局と全く同じようにし， 証明書も，ベリサインの認証局を使っているサイトのIssuerと全く同じようにした場合， SubjectとIssuerが全く同じ証明書ができると思います． この場合は，本物の証明書と同様の証明書を複製できてしまうのでしょうか． できないとは思いますが，それはなぜでしょうか． ４．証明書の偽装は可能か ブラウザから証明書の情報を見ることができます．もちろんbyteデータのraw certificateも見ることができます． この情報を丸々コピーし，全く異なるサーバーに証明書として読みこませて通信した場合は， 署名されてしまうのでしょうか． されないとは思いますが，それはなぜでしょうか． (例えば，URL=CN情報が異なっているから確認できるとか．．？それならCN情報だけ書き換えてしまえばいい？） ５．証明書の検証をするにはどうしたらよいか 証明書を検証をするには，その証明書を発行した認証局の公開鍵を利用するしかないのでしょうか． 例えば，サーバー証明書(CRT)のフィンガープリントsha1データを事前に保持さえしていれば， サーバーに証明書を示された際にCRTのフィンガープリントを比較すれば，特定のサーバーかどうか検証できるか・・？ ６．MITMについて MITM攻撃により，証明書が途中で書きかわることが考えられます． この場合は，書き換わった証明書をどのように特定すればいいのでしょうか． 例えば，認証局のルート証明書がないなどが考えられますが， 仮に，Rapid SSLなどで署名されている証明書でMITM攻撃がされた場合どうなるでしょうか？ この場合は，Issuerなどを比較するしかないように考えられます． しかし，Issuerはcsr申請の際にうまいこと，書き換えることができてしまいます． そう考えると，どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか， フィンガープリントは偽装することができないのでしょうか． 以上となります． 様々な質問を書いてしまい，申し訳ありません 説明不足で乱文だとは思いますが， 分かる範囲でお答え頂けませんでしょうか． 宜しくお願い致します．
- ベストアンサー
- ネットワーク
- 自己署名証明書によるSSL通信について教えてください！
SSL通信により、データを暗号化してWeb上でやりとりするシステムの構築を考えています。 そこで自己署名というのを考えているのですが、署名の流れがいまいち分かりません。 認証局利用の場合、私の理解では、 【サーバ側】 １．サーバ側でRSA秘密鍵を生成 ２．RSA秘密鍵を元にCSRを作成 ３．CSRファイルを認証局に送信 【認証局】 ４．CA秘密鍵により暗号化し、サーバ証明書を作成 ５．サーバ側にサーバ証明書を送信 【サーバ側】 ６．クライアント側にサーバ証明書を送信 【クライアント側】 ７．サーバ側よりサーバ証明書を受信する ８．認証局より公開鍵を取得する ９．認証局の公開鍵でサーバ証明書の暗号化された鍵（認証局の秘密鍵で暗号化されたもの）を復号する １０．復号した鍵により、サーバ証明書の暗号文を復号する となります。（間違いがある場合はご指摘下さい） では、自己署名を行う場合はどうなるのでしょうか？ 単純にサーバ証明書を自分で作成すると考えてよろしいのでしょうか？ CSRファイルの作成などもやはり行うのでしょうか？ クライアント側の流れは変わらないのでしょうか？ また、この操作は接続毎に毎回行うことになるのでしょうか？ （秘密鍵、サーバ証明書は毎回変わるのでしょうか？） 初歩的な質問とは思いますが、よろしくお願いいたします。
- ベストアンサー
- ネットワーク
- サーバ証明書等の正当性の確認について。
サーバ証明書、証明書には、 認証局の署名をSHA-1等のハッシュ関数で、 ハッシュ化されたハッシュ値を、 認証局の秘密鍵で暗号化された認証局の電子署名が付加されていると思いますが、 その部分の信頼性についてですが、 認証局から、 公開鍵を取り寄せて、 ハッシュ値を取り出すと思うのですが、 もともとの平文（署名）を認証局から取り寄せることは可能でしょうか。 認証局の公開鍵で復号できたから、 認証局の秘密鍵で暗号化されているといえるのですが、 もともとの署名が何かがわかりません。 （ちょっと信頼性にかけるような気がします。） 署名を取り寄せることができれば、 署名をSHA-1等を使って、 ハッシュ値を取り出して、 公開鍵で復号したハッシュ値と比較することができます。 公開鍵と平文（署名）を取り寄せることはできないのでしょうか。
- 締切済み
- ネットワーク
- SSHって・・？
Linux勉強中で疑問に思っている点があります。 SSHを利用すると、暗号化を行うことができるということですが・・・・教えて下さい。たとえば・・・ 例：Aはサーバーで秘密鍵を保持、Bはクライアントで 公開鍵を保持。 B（クライアント/公開鍵）→A（サーバー/秘密鍵） 公開鍵を使ってサーバーAにデータを送信後、 サーバー側では、秘密鍵を使ってデータを解読。 A（サーバー/秘密鍵）→B（クライアント/公開鍵) この場合は、データはどう暗号化されているのでしょうか？秘密鍵でデータを暗号をすると、公開鍵を持ってる人達には解読できてしまうのですよね？ "ls"コマンドで叩いた機密情報が仮にA→Bに結果が返ってくる場合は、暗号化されないのでしょうか？ SSHを使ってFTPをする場合も同様のことはいえないのでしょうか？？ Webで情報を集めて、公開鍵と秘密鍵の事に関しては 調べてみたつもりなのですが・・・ 申し訳ありませんが、ご教授下さい。 よろしくお願い致します。
- ベストアンサー
- Linux系OS
- リモート認証について
本日学校の課題としてでた問題についてお聞きしたいのですが、調べても理解できなかったので質問させていただきました。 「問題」 以下の認証プロトコルを考えたとき、どのような問題点があるか具体的に述べよ。 1, 各ユーザは公開鍵をそれぞれもち、サーバは対応する公開鍵を保持する。（公開鍵からは秘密鍵はわからない。また、秘密鍵は各ユーザによって厳重に管理されているものとする） 2, 各ユーザは認証の際に決められた自分のユーザIDを自分の秘密鍵で暗号化したものをサーバに認証のための情報として送る。 3,サーバは送られてきたものを対応する公開鍵で複合し、ユーザIDを確認する。 という問題です。 特に問題点がないように思われます。 どなたか解説をしていただけませんでしょうか？ 長々と失礼しました。
- 締切済み
- ネットワーク
- SSLの電子証明書を使った身元保証について
別のカテで質問したのですが回答が得られなかったので、もう一度質問します。 知識がほとんどないまま毎日のようにインターネットを利用しているのでこれではいかんと、独学でインターネットのことについて勉強していて、度々こちらでもわからないことを教えてもらっています。 今日は、セキュリティーのことについて勉強しているところなのですが、SSLの電子証明書を使った身元保証についてわからないことがあるので教えて下さい。 ネット上で商売をしようという業者は、認証局から電子証明書を受け取り、自社のWebサーバーにインストールしておきますよね？ 買い物をするとき、顧客はSSLを業者に要求し、業者は電子証明書を送信し、顧客は業者を確認し、共通鍵を作成し、業者の公開鍵で暗号化して共通鍵を送り、業者は自分の秘密鍵で複合する、わけですが、具体的にどういうことなのかわからないんです。 買い物をしようとすると、認証局から電子証明書を受け取っている業者には、錠前のマークが出るんですよね？ 錠前のマークをダブルクリックすると「証明書の情報」が開きますよね？ 本当は、この情報を元に、相手の身元を確認する作業というのをしなければいけないものなのでしょうか？ それとも、錠前マークが出ている時点で、自動的に確認が取れているということなのでしょうか？ つまり、何がわからないかと言うと、「買い物をするとき、顧客はSSLを業者に要求し、業者は電子証明書を送信し、顧客は業者を確認し、共通鍵を作成し、業者の公開鍵で暗号化して共通鍵を送り、業者は自分の秘密鍵で複合する」この流れが、具体的にネットショッピングする際のどの作業のことなのかがイメージできないんです。 解説していただけると助かります。
- 締切済み
- その他(ネットショッピング)
- 自己署名証明書（オレオレ証明書）の暗号化について
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は正常に機能する」」をご参照ください． ここで，疑問になるのが，”傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえばいい”という点です． オレオレ証明書では，ルート証明書にたどり着けないため，ブラウザはオレオレ認証局の公開鍵をもっていない． そのため，サーバ証明書内の公開鍵を取得できない． だから，サーバ証明書送付時にオレオレ認証局の公開鍵を送付する必要がある． オレオレ認証局の公開鍵を用いて，サーバ証明書から公開鍵を抜き出す もしこのとき，オレオレ認証局の公開鍵が自作鍵に置き換えられたとしても，ただ単にサーバ証明書から公開鍵を抜き出すことができず，そこで通信が終了すれば”それで暗号化されて戻ってくる暗号文を復号できる”ことも無いように思えるのですが，いかがでしょうか． （つまり，高木氏の言う差し替えた自作鍵でサーバ証明書内の公開鍵が取得できるかどうか） これができなければ，確かに暗号化通信（というか通信そのもの）自体は破綻していますが，高木氏の懸念しているような「重要な情報の流出」にはつながらないように思えます． 乱文になってしまいまして申し訳ありません． もし，私自身に勘違いや解釈違い等ありましたら，ご指摘いただけると幸いです． よろしくお願いします．
- ベストアンサー
- ネットワーク
- SSHの公開鍵方式の接続について
SSHの公開鍵（＆秘密鍵）の認証での接続について質問です。 現在、Mac OSXのターミナルからLinuxのFC5サーバーに接続しようとしているのですが、うまく接続できません。 FC5側のSSHサーバーはすでに起動しているのですが、最初のホスト認証で躓いています。最初のアクセスの歳にSSHサーバー側から認証鍵を渡されるのですが、その時点で謝ってnoを選択してしまいました。以後、公開鍵が使えない状態になってしまい、接続しても「Permission denied (publickey,gssapi-with-mic).」になってしまいます。最初の接続時の公開鍵を再発行してもらうにはどうしたらよいのでしょうか？ ホスト認証の後は、ユーザー認証となると思いますが、この設定もちょっとよくわからない部分があります。 サーバー側で公開鍵と秘密鍵のセットをssh-kegenで作りますが、MacのOSXのターミナルから接続する場合は、この秘密鍵をどこに保存すればようのでしょうか？また保存後にこの秘密鍵を呼び出すにはどうしたらようでしょうか？ OSXも基本的にはUNIXなので、ホームディレクトリに.sshディレクトリなどを作成して保存するのでしょうか？ 詳細な設定方法を教えて頂けると幸いです。
- 締切済み
- ネットワーク
- ディジタル署名
シスアドの勉強中です。 共通鍵方式、公開かぎ方式はわかりました。 ん??となってしまったのはディジタル署名です。 公開かぎ方式の逆だ！、といわれたのですが・・・ とすると、送信者の秘密鍵で暗号化して、受信者は、送信者の公開鍵で複合する・・・・ということになりますよね・・・？ 署名鍵って？？？？どこに出てくるんですか??? 送信者の秘密鍵で暗号化されたものが、送信者の公開鍵で複合できたんだから、送信者の特定が出来ました・・・ ということで認証できた・・・ってことですか??? じゃあ・・・・署名鍵ってなに？？？？ すっきり説明できる方お願いします_(._.)_
- ベストアンサー
- その他（インターネット接続・通信）
お礼
解説がわかりやすくすごく参考になりました。本当にありがとうございました。