ベリサイン等での認証を利用する場合、原理的に少なくとも1つの公開鍵は(CAのルートの公開鍵)オフラインで配送する必要があると思うのですが、どのような方法でクライアント1台1台に、正当な公開鍵を配賦しているのでしょうか? またある一定期間での更新(こちらはオンラインでも可能でしょうが)するひつようもあると思うのですがどのように運用しているのでしょうか?

このQ&Aに関連する最新のQ&A

A 回答 (2件)

ベリサインのルートCAの証明書(公開鍵)は、たとえばIEやNetscapeのようなブラウザに同梱されており、それらのブラウザを妥当な入手経路で入手すれば妥当な証明書を入手することができます。

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

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

参考URL:http://www.verisign.co.jp/server/cus/rootcert/us …
    • good
    • 0
この回答へのお礼

ご丁寧かつ明確なご回答有り難うございました。
よく調べれば解ることまでお聞きし大変恐縮しております。
大変ずうずうしいのですが、ご回答に関連してまたまた質問させてください。
Q1:ルートCAの証明書(公開鍵)をタンパーフリーな媒体以外で配布することに
   一抹の不安を感じるのですが、何か策が施されているのでしょうか?
Q2:フィンガープリントとはどのようなものでしょうか?一方向関数による
   ハッシュのようなものでしょうか?
お手すきのときに回答いただければ幸いです。

お礼日時:2001/03/26 10:45

A1. 公開鍵証明書は(秘密の情報が含まれるものではないので)受け取った時点で偽造や改ざんを受けていないことを確認する手段があれば充分です。


A2. シグネチャーは公開鍵証明書を1方向ハッシュ関数に通すことによって計算されます。よって、真正な公開鍵証明書を元に計算したことが明らかなシグネチャ-と、手元の公開鍵証明書を元に計算したシグネチャ-が一致しない場合、手元の公開鍵証明書は伝送中に損傷を受けた/改ざんされた/偽造されたと判断することができます。

A1. について補足すると、
http://www.verisign.com/repository/root.html
のようなページが存在し、シグネチャーを照合できるようにしてあることが「策」を構成しています。もしも
上記URLの内容すら信頼できない場合にも、ベリサインのオフィスに電話を掛けたり、オフィスまで出向いたりする選択肢もあります(個人のエンドユーザがそこまでするとたぶん嫌がられると思います ^_^)
    • good
    • 0
この回答へのお礼

迅速かつ的確なご回答有り難うございます。
運用のイメージとセキュリティレベルについてイメージがつかめました。
ほんとうに有り難うございました。

お礼日時:2001/03/27 11:01

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q共通鍵・公開鍵・秘密鍵の鍵とは?

共通鍵・公開鍵・秘密鍵の鍵とは要は「123KJNIDlll・・・」などの数字や文字のパスワードのことでしょうか?

例えば、共通鍵暗号方式では、ファイル・テキストなどのパスワードを「123gh」などと設定して、
それを送信者と受信者でパスワードの情報を共有するのでしょうか?

公開鍵暗号方式も同様にファイル・テキストに「123yu」は公開鍵、「456ghjは秘密鍵と設定をするのでしょうか?

Aベストアンサー

> 共通鍵・公開鍵・秘密鍵の鍵とは要は「123KJNIDlll・・・」などの数字や文字のパスワードのことでしょうか?

そのとおり

> 例えば、共通鍵暗号方式では、ファイル・テキストなどのパスワードを「123gh」などと設定して、
> それを送信者と受信者でパスワードの情報を共有するのでしょうか?

考え方としては合っている
共有するパスワード自体が「共通鍵」

> 公開鍵暗号方式も同様にファイル・テキストに「123yu」は公開鍵、「456ghjは秘密鍵と設定をするのでしょうか?

公開鍵は教科書や参考書をちゃんと読んだほうがいい。

・秘密鍵と公開鍵は必ずセット
(秘密鍵をユーザーが好き勝手に決められるとしても、公開鍵はその暗号システムで秘密鍵と対になるものを計算してやらないとダメ)

・公開鍵で暗号化した暗号文は、対応する秘密鍵でないと開けない
(暗号化するときに秘密鍵は必要ない)

Q秘密鍵 公開鍵

AからBへ公開鍵暗号方式でメールを送信する場合、Aはどの鍵を使うか?という問題で、解答は「Bの公開鍵」が正解なのですが、これはどうしてそういう答えになるのか、理解が出来ていません。

ご教示、よろしくお願いいたします。

また、同じAからBへ秘密鍵暗号方式でメールを送信する場合はどうなるのかも、併せてご教示頂ける
幸いです。

Aベストアンサー

こんばんわ。専門は暗号ではありませんが、セキュリティを生業にしている者です。
可能な限り簡単に、イメージをつかめるように書きたいと思います。

シナリオ:
 ・AさんがBさんにメールを送る。
 ・Aさんは、世界中の他の誰でもなくBさんにそのメールを読んでもらいたいと思っています。

Bさんの公開鍵と秘密鍵の状態
 ・公開鍵と秘密鍵はそれぞれ別々のもので、片方からもう片方を推測することはできない。
 ・Bさんの公開鍵は、基本的に世界中のだれでも入手・利用することができる。
 ・Bさんの秘密鍵は、世界中でBさんただ一人が持っている。
 ・Bさんの公開鍵で暗号化されたデータを復号できるのは、Bさんの秘密鍵だけ。
 ・(逆に、Bさんの秘密鍵で暗号化されたデータを復号できるのは、Bさんの秘密鍵だけ)

Aさんが目的を達成するには、Bさんの公開鍵で暗号化する必要があるということがわかると思います。要するに、仮に暗号化された通信文が世界中に公開されたとしても、その暗号を解いて元の通信文を取り出せるのは、世界中でBさんしかいないからです。

2つ目の質問の秘密鍵暗号方式ですが、こちらの鍵の状態がどうなっているかというと、
 ・暗号化と復号に利用する鍵 = AさんとBさんが持っている鍵は同一の鍵。
 ・このため、この鍵を持っているのは世界中でAさんとBさんしかいてはならない。
 ・逆に言えば、この鍵を入手した人は誰でも、その鍵で暗号化されたデータを復号できる。

となっています。ですから、あえて答えるならば"AさんとBさんが同一の鍵を共有して、それを暗号化と復号に利用する"ということになります。
しかし、少し考えればわかりますが、秘密鍵暗号のみで安全に暗号化通信を行うのは容易ではありません。なぜならば、直接会うことでもできない限り、安全にAさんとBさんとが同じ鍵を持つことができないからです(直接会えるならば暗号化の必要はない)。

このため、現在のインターネットで実際に現在利用されている方式(S/MIME)は以下の通りです。
 1. Aさんは通信文をまず任意の秘密鍵αで暗号化し、"暗号化された通信文"を作成する(秘密鍵αをBさんと事前に共有している必要はない)
 2. 1.で使った秘密鍵αをBさんの公開鍵で暗号化し、"暗号化された秘密鍵α"を作成する
 3. Aさんは"暗号化した通信文"と"暗号化された秘密鍵α"をBさんに送る(もし誰かがこの通信文を手に入れても復号は不可能)
 4. Bさんは自分の秘密鍵で"暗号化された秘密鍵α"を復号し、秘密鍵αを取り出す。
 5. 続いて、取り出した秘密鍵αで"暗号化された通信文"を復号する。
 6. 元の通信文を取り出す。

なぜこんな面倒くさいことをするかというと、公開鍵暗号方式は秘密鍵暗号方式に比べて計算時間が圧倒的にかかるので、通信文そのものを公開鍵暗号方式で暗号化・復号するには時間がかかりすぎてしまうからです。秘密鍵暗号方式で利用した鍵を公開鍵暗号方式で暗号化することで、安全性と速度との両方を実現しているのです。

こんばんわ。専門は暗号ではありませんが、セキュリティを生業にしている者です。
可能な限り簡単に、イメージをつかめるように書きたいと思います。

シナリオ:
 ・AさんがBさんにメールを送る。
 ・Aさんは、世界中の他の誰でもなくBさんにそのメールを読んでもらいたいと思っています。

Bさんの公開鍵と秘密鍵の状態
 ・公開鍵と秘密鍵はそれぞれ別々のもので、片方からもう片方を推測することはできない。
 ・Bさんの公開鍵は、基本的に世界中のだれでも入手・利用することができる。
 ・Bさんの秘密鍵...続きを読む

Q無料S/MIME証明書発行での公開鍵秘密鍵

無料S/MIME証明書発行での公開鍵秘密鍵
ですが、IEで、無料の証明書を申し込むときに、
RSAの公開鍵と秘密鍵を作成しなくてはならないと思うのですが、
この計算は、自分のPCの中で行われるのでしょうか、
それとも、証明書を発行してくれる会社のサーバーで計算されるのでしょうか?

Aベストアンサー

> IEがRSAの公開鍵と秘密鍵を作る機能を持っているのでしょうか?

Windowsがその機能を持っています。
http://okwave.jp/qa/q4229519.html の私の回答No.1


> その機能は独自に働かせることは出来るのでしょうか?

オンラインソフトの openssl を用いてRSA鍵を生成した経験はありますが,
http://oshiete.goo.ne.jp/qa/6683057.html の私の回答No.6

Windows標準の機能で,かつ,EFS機能を介さないで,RSA鍵を生成した経験は残念ながらありません。

Q公開鍵暗号化方式での鍵の配置について

上長より、ファイルのやり取りはGPGにて公開鍵方式で実施するとの事で、
技術検証を任されたのですが、そこでいくつか不明な点がある為、
ご教示頂きたく何卒宜しくお願い申し上げます。

公開鍵方式では受信側にて公開鍵、秘密鍵を保持し、送信側が受信側にアクセスして公開鍵を使用して暗号化を実施し、受信側へ送信する・・・とあります。

受信(取得する)側がクライアント、送信(取得される)側がサーバを想定しており、
サーバ側にはある検査結果を検査が終わる度に決まったディレクトリに配置するのですが、
クライアント側から取得するのは1日1回と考えております。

その際、サーバ側においてあるファイルを暗号化した状態で配置しておきたいのですが、
よくある図解では、受信側に公開鍵と秘密鍵を保持しているイメージですが、
作成した公開鍵をサーバに配置して暗号化、復元用に秘密鍵はクライアントに配置と考えておりますが、この考えで正しいでしょうか?

ちなみに環境は以下を想定しております。
クライアント = Win7
サーバは = Linux系
言語 = VB.NET

また、VB.NETで実現しようと考えているのですが、サンプルプログラムが英語用サイトでもあまり見つける事が出来ませんでしたので、参考サイトもご存知でしたらご教示頂けると非常に助かります。

クライアント(取得側)、サーバ(取得される側)での公開鍵方式をしようしたファイルのやり取りについて、どのような手段が常套手段なのかぜひご教示頂きたく、何卒宜しくお願い申し上げます。

上長より、ファイルのやり取りはGPGにて公開鍵方式で実施するとの事で、
技術検証を任されたのですが、そこでいくつか不明な点がある為、
ご教示頂きたく何卒宜しくお願い申し上げます。

公開鍵方式では受信側にて公開鍵、秘密鍵を保持し、送信側が受信側にアクセスして公開鍵を使用して暗号化を実施し、受信側へ送信する・・・とあります。

受信(取得する)側がクライアント、送信(取得される)側がサーバを想定しており、
サーバ側にはある検査結果を検査が終わる度に決まったディレクトリに配置するのですが、
...続きを読む

Aベストアンサー

公開鍵暗号には二通りのやり方がある。
●パターン1:受信側が秘密鍵
・電文を受信したい人Bがキーペア(公開鍵と秘密鍵)を作る。
・Bが全世界にBの公開鍵を公開する。
・Bに電文を送信したい人AがBの公開鍵をゲット。
・AはBの公開鍵で電文を暗号化してBに送信。
・BはBの秘密鍵で暗号化電文を復号化。
・正しく復号化されたらOK。電文は暗号化された状態でAからBに渡された。
→暗号化電文を復号化できるのはBのみ。
●パターン2:送信側が秘密鍵
・電文を送信したい人Qがキーペアを作る。
・Qが全世界にQの公開鍵を公開する。
・Qから電文を受け取りたい人RがQの公開鍵をゲット。
・QはQの秘密鍵で電文を暗号化してRに送信。
・RはQの公開鍵で暗号化電文を復号化。
・正しく復号化されたらOK。電文は暗号化された状態でQからRに渡された「、かつ確実にQからの電文である事が確認された」。
→暗号化電文を複合できるのは全世界の全ての人間。

ついでにSSLの暗号化方式について軽く説明しておくと、
・サーバーがキーペアを作る。
・公開鍵も秘密鍵もサーバーが持っている。
・クライアントが接続する。
・サーバーが公開鍵をクライアントに平文で送りつける。
・クライアントは共通鍵の元ネタを作ってそれをサーバーの公開鍵で暗号化しサーバーに送信する。
・クライアントとサーバーはそれぞれ共通鍵の元ネタから共通鍵を作る。
・クライアントは今までのやり取りのハッシュ値を共通鍵を使って暗号化しサーバーに送信する。
・サーバーは今までのやり取りのハッシュ値を計算し、クライアントから受け取った暗号化ハッシュ値を共通鍵で復号化して一致したら通信開始OK。
・ ~~~暗号化通信中~~~
という流れで、実はSSLはキーペアを使い捨て共通鍵の交換にのみ使い、以後の通信は使い捨て共通鍵で行っている。

> クライアント(取得側)、サーバ(取得される側)での公開鍵方式をしようしたファイルのやり取りについて、
> どのような手段が常套手段なのかぜひご教示頂きたく、何卒宜しくお願い申し上げます。
何を、いつ、どこで、暗号化して、それを、いつ、どこで復号化するのか、するべきなのか、しなきゃ脅威があるのか、そこをもう一度練り直してみてはどうかな。

以下はあくまで一例だが、
暗号化のタイミングは既に分かっている。VB.NETが検査結果をサーバーに上げるタイミングだ。
では、検査結果を復号化するのは、いつで、誰? これもクライアント側から1日1回取得するタイミングだろうな。
それが決まったら次は送信側と受信側のどちらが秘密鍵を持つべきかだ。まぁこれも受信側が秘密鍵でないとおかしいよね。

公開鍵暗号には二通りのやり方がある。
●パターン1:受信側が秘密鍵
・電文を受信したい人Bがキーペア(公開鍵と秘密鍵)を作る。
・Bが全世界にBの公開鍵を公開する。
・Bに電文を送信したい人AがBの公開鍵をゲット。
・AはBの公開鍵で電文を暗号化してBに送信。
・BはBの秘密鍵で暗号化電文を復号化。
・正しく復号化されたらOK。電文は暗号化された状態でAからBに渡された。
→暗号化電文を復号化できるのはBのみ。
●パターン2:送信側が秘密鍵
・電文を送信したい人Qがキーペアを作る。
・Qが全世界にQの公開...続きを読む

QSSL での 公開鍵、秘密鍵

Gメールで、POP接続してメールを取り出すときは、
SSL(TLS)での接続となります。
ここで、RSA暗号を使う場合の、公開鍵を秘密鍵のセットは
接続した瞬間に作成されるのでしょうか?
それとも、既に作ってある公開鍵と秘密鍵のセットが選ばれるのでしょうか?

もし、既に作ってあるセットの中から選ぶ場合には、
鍵のセットはサーバーの中に何セットくらい用意されているのでしょうか?

WireShark で、SSL の暗号化を解読してパケットの中を見る方法があるとのことで、
すこし、気になっています。

お分かりの方よろしくお願いいたします。
 
参考:

https://www.softbanktech.jp/yko/2010/07/001129.html

Aベストアンサー

> ここで、RSA暗号を使う場合の、公開鍵を秘密鍵のセットは
> 接続した瞬間に作成されるのでしょうか?

理論上はそういうこともできるとは思いますが、そういう運用はしないですね。
優位な長さのセットを作るのはそれなりにCPUを使いますし、時間もかかりますから。

> それとも、既に作ってある公開鍵と秘密鍵のセットが選ばれるのでしょうか?
> もし、既に作ってあるセットの中から選ぶ場合には、
> 鍵のセットはサーバーの中に何セットくらい用意されているのでしょうか?

複数セット持っておくということも理論上は可能だと思いますが、運用上は普通 1セットしか持たないのが普通です。

> WireShark で、SSL の暗号化を解読してパケットの中を見る方法があるとのことで、
> すこし、気になっています。

そのリンク先ですが、"5. RSA keys list の箇所にPEMファイルの場所を入力。"と書いてませんか?
この解説はRSA暗号を攻略して秘密鍵を見つけたのではなくて、RSA key listにサーバーの秘密鍵を予め登録しておくと、Wiresharkがそれを使って復号して見せてくれるという話ですよね。

"秘密鍵さえあれば、もうこっちのものですよ。フフフ…"というのもそれを物語っていると思います。


そもそも、今推奨されている鍵長である2048 bitのRSA公開鍵は2030年くらいまでは安全だと考えられているようですが...
http://ascii.jp/elem/000/000/550/550217/

例えば、Gmailで使われている公開鍵暗号はECC 256 bitですが、これはRSA 3072 bitに相当するみたいで、上の記事によると2050年くらいまでは安全そうですね。
https://www.verisign.co.jp/ssl/ecc-dsa/

ちなみに、そのGoogleの公開鍵の署名にはGeoTrustの1024bit RSA証明書が使われているようですが、それですらそこら辺のPCで一瞬で解読できるような強度ではないです。
http://sehermitage.web.fc2.com/crypto/safety.html

まあ、この手の公開鍵が攻略されると偽の署名を付けて偽Googleサイトに誘導できるようになりますが、その時はすぐに遮断されそうですけどね。
http://www.itmedia.co.jp/enterprise/articles/1301/08/news029.html


ついでに、SSLのRFCでも見てみると面白いかもしれません。
http://www.ipa.go.jp/security/rfc/RFC2246-07JA.html#73

> ここで、RSA暗号を使う場合の、公開鍵を秘密鍵のセットは
> 接続した瞬間に作成されるのでしょうか?

理論上はそういうこともできるとは思いますが、そういう運用はしないですね。
優位な長さのセットを作るのはそれなりにCPUを使いますし、時間もかかりますから。

> それとも、既に作ってある公開鍵と秘密鍵のセットが選ばれるのでしょうか?
> もし、既に作ってあるセットの中から選ぶ場合には、
> 鍵のセットはサーバーの中に何セットくらい用意されているのでしょうか?

複数セット持っておくというこ...続きを読む


人気Q&Aランキング

おすすめ情報