認証時の一番最初の公開鍵の獲得方法

ベリサイン等での認証を利用する場合、原理的に少なくとも1つの公開鍵は(CAのルートの公開鍵)オフラインで配送する必要があ...

hitsuji さんからの 回答

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

  • 2001/03/25 01:54
  • 回答No.1
  • ベストアンサー
hitsuji

ベストアンサー率 22% (2/9)

ベリサインのルートCAの証明書(公開鍵)は、たとえばIEやNetscapeのようなブラウザに同梱されており、それらのブラウザを妥当な入手経路で入手すれば妥当な証明書を入手することができます。また、「一定期間で」更新する必要はないですが、証明書には有効期限がありますので、その際には新しい証明書を入手する必要があります。2000年になった時点である証明書が有効期限切れとなったのですが、その折にベリサインから出たアナウンスを参考URLにあげておきます。要するに、ブラウザをバージョンアップすると、新しい証明書もインストールされるということです。

なお、ブラウザに組み込まれている証明書が真正であるかどうかですが、これは証明書のシリアル番号とフィンガープリントを表示させ、その値をベリサインに照合することで確認できます(実際には
http://www.verisign.com/repository/root.html
のようなページに掲載されている値と比較する程度か)。
お礼コメント
mtbf0

お礼率 100% (2/2)

ご丁寧かつ明確なご回答有り難うございました。
よく調べれば解ることまでお聞きし大変恐縮しております。
大変ずうずうしいのですが、ご回答に関連してまたまた質問させてください。
Q1:ルートCAの証明書(公開鍵)をタンパーフリーな媒体以外で配布することに
   一抹の不安を感じるのですが、何か策が施されているのでしょうか?
Q2:フィンガープリントとはどのようなものでしょうか?一方向関数による
   ハッシュのようなものでしょうか?
お手すきのときに回答いただければ幸いです。
投稿日時:2001/03/26 10:45
この回答にこう思った!同じようなことあった!感想や体験を書こう!
この回答にはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。
関連するQ&A
  • 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申請の際にうまいこと,書き換えることができてしまいます. そう考えると,どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか, フィンガープリントは偽装することができないのでしょうか. 以上となります. 様々な質問を書いてしまい,申し訳ありません 説明不足で乱文だとは思いますが, 分かる範囲でお答え頂けませんでしょうか. 宜しくお願い致します....

  • 電子証明書の信頼性について ネットワーク

    電子証明書は公開鍵と共に相手に送信され、その公開鍵の信頼性を保障する証明書とのことですが、その電子証明書自体の正当性はどのように判断するのでしょうか? ある個人が公開鍵、秘密鍵を作成し、ベリサインなどのCAになりすまして、証明書自体も作成しまうことは可能なのでしょうか?(普通は無理なのかとおもいますが。。。。) 可能であった場合、その証明書がベリサインが本当に発行した証明書なのか、ある個人がなりすまして発行した証明書なのかどこ判断するのでしょうか? よろしくお願いいたします。...

  • ベリサインとは? ネットワーク

    VeriSign Secure Siteについて、そのサイトとの通信がSSL通信中であれば、情報は暗号化され、第三者の盗聴、改ざん、成りすましなどから保護されるということ自体は理解できるのですが、具体的には、公開鍵方式による暗号化などのスキームを利用しているのでしょうか? また、訪れたサイトが正規のVeriSign Secure Siteであることを確認するためにそのサイトのホームページのURLや「ステータス」が有効 (Valid) であることを確認する、というのは一体どういう意味があるのでしょう?...

  • S/MIME の欠点 ネットワーク

    S/MIME に関しての疑問です。 http://www.atmarkit.co.jp/fsecurity/special/04smime/smime01.html において、次のように書かれています。  S/MIMEでは、その仕組みにPKIを使っています。その点は、Webブラウザ~Webサーバ間の通信の暗号化、認証を行うSSLと同じですね。PKIを一言でいってしまうと、「認証局という第三者的機関が、公開鍵とその持ち主を保証する」です。その結果が、認証局が電子署名して発行した公開鍵証明書と呼ばれるデータです。認証局を商用のサービスとして提供している会社として、ベリサイン社などが有名です。ちなみに、ベリサイン社では公開鍵証明書のことをデジタルIDと呼んだりしています。PKIについての詳細はここでは省きますが、解説した記事が別にありますので、興味がある方はSecurity&Trustフォーラムを参照してください。 認証局という第三者的機関が、公開鍵とその持ち主を保証する」 の部分ですが、鍵に、その持ち主が山田太郎 だと書いてあったら、 ほんとに、その鍵の持ち主が山田太郎 だと言えるのでしょうか? 調べてみたら、 http://www.jipdec.or.jp/esac/reliability/smimeTable.html 個人対象の、証明書の発行では、 申込時の本人確認 行わない 申込時のメールアドレス確認 行う となっているところがほとんどでした。 本当は、川崎次郎 と言う人が Gメールのアドレスを 山田太郎と名乗って取得し そのアドレスを使って、山田太郎の名前の証明書を取得したら、 この証明書が、何を証明するのかが分かりません。 これは、S/MIME の方式の大きな欠点ではないでしょうか? 改良案などありましたら、教えてください。 また、私が誤解しているてんなどが、ありましたら教えてください。 なお、偽名の証明書は、無料で発行してくれる所から 実際に取得してみました。偽名のものを発行してくれました。...

  • 電子メール暗号化方式の混在はOK? ネットワーク

     初めて質問させていただきます。  会社ではベリサインのサービスを使っており、結果的に電子メールはS/MIME方式の暗号化を使っています。  たまに取引先から「うちはPGP方式を使っているのですが、そちらはPGPは使えますか?」という質問を受けることがあります。  私の理解では、お互いに公開鍵と電子署名のやりとりをするという仕組みから考えて、両者のの使っている暗号化方式が違っていても、双方向のやりとりともきちんと暗号化できると思えてなりません。  つまり、当社から取引先へのメールは、相手の公開鍵でPGP方式で暗号化され、取引先から当社へのメールは、当社の公開鍵でS/MIME方式で暗号化されるということですね。  そうなると、こちらと相手の暗号化方式をそろえる必要はないのではないかと思っているのですが、Webなどで調べてもなかなか確信が得られる情報がありません。  実際のところ、どうなのでしょう?  どなたか、教えていただけないでしょうか。 使用OS:Windows XP sp2 メールソフト:Outlook Expres 6またはThunderBird 1.5  よろしくお願いいたします。...

ページ先頭へ