S/MIMEでの公開鍵の個数
- S/MIME通信における公開鍵の個数について
- S/MIMEを利用した複数の相手との通信には異なる公開鍵が必要
- サンダーバードを使用して複数の公開鍵を運用することは可能か
- ベストアンサー
S/MIMEでの公開鍵の個数
S/MIMEについて調べています。 Xさんが、Aさん、Bさん、、、、Jさんの１０人とS/MIMEを使って通信するとします。 暗号はRSAとします。 Xさんは、Aさん用の証明書つきの公開鍵、Bさん用の証明書つきの公開鍵、、、、 のように、１０人分の異なる公開鍵を用意して運用することは可能ですか？ とうぜん、Aさんが使う秘密鍵は１０個となります。 個別にしておいたほうが、因数分解されたときの被害が最小限になる。 もちろん、１１番目のKさんとは暗号化しないでメールのやり取りをする。 サンダーバードを使って上のようなことが出来ないかと考えています。 使ったことが無いので、へんな質問かもしれませんがよろしくお願いいたします。
- uyama33
- お礼率71% (399/560)
- ネットワーク
- 回答数4
- ありがとう数1
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
1.堅牢性の観点から 費用対効果で考える場合、例えば、 10年間、10人それぞれに別個の公開鍵を用いるよりも、 1年毎に10人共通の公開鍵を更新する方が堅牢性は高いと考えます。 >個別にしておいたほうが、因数分解されたときの被害が最小限になる。 上記文言は、当該公開鍵に依存する情報量を最小化することで堅牢性を確保することが目的ですよね？ 当該公開鍵に依存する情報量を最小化する方法としては、 ・時間当たりの情報量を減らす(当該公開鍵の利用者を減らす。uyama33さんのアイディア) ・公開鍵の運用期間を短くする(短期間で新しい公開鍵に変更する) の2種類があります。 公開鍵の堅牢性は解読に時間がかかる(平均100年以上など)ことで保証されています。 逆に、うっかり解読されてしまった(平均100年なので、うっかり5年で解読される可能性もある)リスク への対策としては、後者の短期間で公開鍵を交換する方が効果的ではないでしょうか? 2.運用性の観点から PKIシステムで他人の証明書(≒公開鍵)が自由にダウンロードできる環境だと、 Aさんに、Aさん専用のXさん証明書を使ってもらうことが困難(Bさん専用のXさん証明書をAさんが入手できる) なので、運用実現性に高いハードルがあるように思います。
その他の回答 (3)
- jjon-com
- ベストアンサー率61% (1599/2592)
> ありがとうございます。確認しました。 > http://www.trustss.co.jp/smnHsk010.html > （回答No.2への補足） こちらこそ，有益なリンク先をご紹介いただけました，ありがとうございます。
お礼
ご丁寧にありがとうございます。 スノー伝君の件以来、メールソフトのあり方について、いろいろ考えています。 openssl を検討し始めたのは今年の夏からです。 S/MIMEでの証明書を取得したのも初めてです。 数学や暗号は以前からいろいろな本を読んでいますが、 それらの利用方法についての現在の常識には疑いをもっています。 ひとつずつ検証したいと思っています。 変な質問にもかかわらず真剣に指導していただき、感謝しております。
- jjon-com
- ベストアンサー率61% (1599/2592)
> ＧメールのＳＳＬで使うマスター暗号化キーがもれたら > Ｇメール全体が一挙に崩壊します。 mail.google.comとの暗号化に使われるキー(※)は不特定多数に公開されています。 mail.google.comの電子証明書にそのまま格納されていますから，言うなれば，世界中の人々に漏れているわけです。 （※正しくは，暗号通信で使われる暗号化キーを相手と共有するための暗号化キー） -------- > この記述は、暗号化鍵を登録させる立場に立った考え方 いいえ，間違っています。 第一に，秘密鍵は自分のPCの中で生成されて自分のPCに登録されただけです。自分のPCから外へは送信されていません。 http://okwave.jp/qa/q8246984.html の私の回答No.1 第二に，公開鍵暗号方式を使うということと，公開鍵を電子証明書という形で登録することは別の話です。電子証明書に不信感がぬぐえないのなら，各人相互の通信で自由に公開鍵暗号方式を使えばよいだけです。 http://okwave.jp/qa/q8242041.html の私の回答No.6 -------- > １箇所を攻撃すれば崩壊するようなシステムはもろすぎます。 > インターネットの構造のように、一部分を破壊されても残りはきちんと機能する。 > そんなシステムのほうが良いと思っています。 原則としては反対はしませんけれど， セキュリティシステムにおいて，強固な一元管理と，脆弱な分散管理とがあるなら，前者しか現実的に採用できないです。 「インターネットのカタチ，もろさが織り成す粘り強い世界」と謳われたような，強固な分散管理システムが現実的な候補として存在するなら自然とそこへ移行していくでしょうけれど，そのようなセキュリティインフラストラクチャの存在が不確かなのに理想論だけで強固な一元管理を捨てるわけにはいかないです。
補足
以前gooで教えていただいた、ＳＳＬでの秘密鍵 http://oshiete.goo.ne.jp/qa/8202271.html のことを意味していると解釈して、 http://www.zaikei.co.jp/article/20130727/142814.html の記事の言葉を使ってしまいました。 変な表現になってしまいました。すみません。 なお、 「インターネットのカタチ，もろさが織り成す粘り強い世界」と謳われたような，強固な分散管理システムが現実的な候補として存在するなら自然とそこへ移行していくでしょうけれど，そのようなセキュリティインフラストラクチャの存在が不確かなのに理想論だけで強固な一元管理を捨てるわけにはいかないです。 これについては、送信者と受信者の順序対ごとに暗号化方式と暗号化鍵を決定出来る形にして、 （送信者と受信者の互いの意思だけで決定できる。） 暗号メールが送受信できるようにすれば良いと考えています。 これならば、ネットワークの一部の暗号化が破られても全体は機能し続けます。 また、暗号鍵の集積ポイントがないので攻撃目標が定めにくい。 こんなことを考えています。
- jjon-com
- ベストアンサー率61% (1599/2592)
> １０人分の異なる公開鍵を用意して運用することは可能ですか？ そうする必要性がないです。 「Aさん用の証明書つきの公開鍵、Bさん用の証明書つきの公開鍵」とおっしゃっている時点で，公開鍵による暗号化の仕組みをそもそも勘違いなさっているのだと思います。 ネット検索でヒットした，共通鍵暗号と公開鍵暗号の初心者向け解説ページがこちら。 http://www.geocities.co.jp/SiliconValley-Cupertino/2190/topic/angouka/angouka.html -------- 必要性はないけれどそれは可能か，と問われたら「可能です」と答えることになりますが。 認証サービスは一般的に年契約の有料サービスです。一人がただひとつ取得すればニーズを満たすことができる電子証明書を10個も取得するなんて酔狂でしょう。 https://www.verisign.co.jp/ssl/chart.html -------- > 個別にしておいたほうが、因数分解されたときの被害が最小限になる。 現在の暗号は，数学上の新たな発見がないかぎり，因数分解によって鍵が見つかるなんて数百年の時間を費やしても不可能だという点に立脚しています。 そもそも認証サービス事業者自身が，自らのRoot認証局の秘密鍵を極めて強固に守ることによってサービスを成り立たせているわけで。 仮に攻撃者が因数分解によって鍵を見つけようとするのなら，たかが一利用者を対象にするより，認証局の鍵を攻撃対象にするはずです。
補足
初歩的な説明のページのご紹介ありがとうございます。 内容は、Handbook of APPLIED CRYPTGRAPHY の31ページから 35ページの内容と同じだと思います。 でも、この記述は、暗号化鍵を登録させる立場に立った考え方で、暗号化通信のネットワークを 弱体化させるものだと思っています。 １箇所を攻撃すれば崩壊するようなシステムはもろすぎます。 インターネットの構造のように、一部分を破壊されても残りはきちんと機能する。 そんなシステムのほうが良いと思っています。 たとえば、ＧメールのＳＳＬで使うマスター暗号化キーがもれたらＧメール全体が一挙に崩壊します。
関連するQ&A
- 無料S/MIME証明書発行での公開鍵秘密鍵
無料S/MIME証明書発行での公開鍵秘密鍵 ですが、IEで、無料の証明書を申し込むときに、 RSAの公開鍵と秘密鍵を作成しなくてはならないと思うのですが、 この計算は、自分のPCの中で行われるのでしょうか、 それとも、証明書を発行してくれる会社のサーバーで計算されるのでしょうか？
- ベストアンサー
- ネットワーク
- SSHの公開鍵について
お世話になっております。 現在3台のサーバA,B,Cがあり、AのサーバからB,Cにパスワードなしでログインできるようにするため、 AのサーバでSSHの公開鍵と秘密鍵を作成しました。（パスフレーズはnull) 具体的な手順は以下になります。 ------------------------------------------------------------------------------------------- 1. Aサーバにて公開鍵と秘密鍵を作成 A # ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (//.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in //.ssh/id_rsa. Your public key has been saved in //.ssh/id_rsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@A 2. 秘密鍵、公開鍵が作成されていることを確認 A # ls ~/.ssh id_rsa id_rsa.pub known_hosts 3. 公開鍵をBとCサーバへ配信 A # scp ~/.ssh/id_rsa.pub root@B:/tmp Password: id_rsa.pub 100% |***************************************| 223 00:00 4. BとCサーバ側で公開鍵の登録 B # cat /tmp/id_rsa.pub > ~/.ssh/authorized_keys ------------------------------------------------------------------------------------------- 登録後、AサーバからB,CサーバにSSHで接続してみたのですが、一見パスワードなしでログインできているようでした。 ただ、何故か B,Cサーバや無関係なDサーバからもAサーバへパスワードなしでアクセスできてしまいます。 公開鍵を登録したのはB,Cサーバのみで、B,CサーバからAサーバに対してパスワードなしでアクセスできないはずという認識です。 更に、数日後AサーバからB,Cサーバに接続を試みたところ、以下のメッセージが出力されました。 ------------------------------------------------------------------------------------------- ホスト 'B (1.1.1.1)' の認証を確立できません. RSA 鍵フィンガープリントは xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx です 本当に接続を継続してもよろしいですか (yes/no)? ------------------------------------------------------------------------------------------- 公開鍵はBサーバ初回接続時にknown_hostsへ登録済みで、Bサーバ側のIPアドレスの変更なども実施していません。 SSHの仕様で、公開鍵が数日で変更されるのでしょうか？ 上記について、アドバイスや問題点があればご教示いただければ幸いです。
- 締切済み
- Linux系OS
- ＳＳＬ での 公開鍵、秘密鍵
Ｇメールで、ＰＯＰ接続してメールを取り出すときは、 ＳＳＬ（ＴＬＳ）での接続となります。 ここで、ＲＳＡ暗号を使う場合の、公開鍵を秘密鍵のセットは 接続した瞬間に作成されるのでしょうか？ それとも、既に作ってある公開鍵と秘密鍵のセットが選ばれるのでしょうか？ もし、既に作ってあるセットの中から選ぶ場合には、 鍵のセットはサーバーの中に何セットくらい用意されているのでしょうか？ WireShark で、ＳＳＬ の暗号化を解読してパケットの中を見る方法があるとのことで、 すこし、気になっています。 お分かりの方よろしくお願いいたします。 参考： https://www.softbanktech.jp/yko/2010/07/001129.html
- ベストアンサー
- ネットワーク
- S/MIMEでの証明書の保存と多重暗号化
メールソフトを作っています。 １．S/MIMEでの証明書は個別のファイルとして保管するのと、 データベースにしておくのではどちらが普通なのでしょうか？ ２．S/MIMEでの暗号化をして、さらに他の方式で多重暗号化する上で、 注意することは何でしょうか？（単純なS/MIMEとの上位互換性を持たせたい。） 以上、よろしくお願いします。
- ベストアンサー
- C・C++・C#
- 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 の方式の大きな欠点ではないでしょうか？ 改良案などありましたら、教えてください。 また、私が誤解しているてんなどが、ありましたら教えてください。 なお、偽名の証明書は、無料で発行してくれる所から 実際に取得してみました。偽名のものを発行してくれました。
- ベストアンサー
- ネットワーク
- 公開鍵・秘密鍵・共通鍵
公開鍵・秘密鍵・共通鍵 予備校の模試の正誤問題で 「ＳＳＬとは、通信データを暗号化する技術のことをいい、公開鍵暗号方式と共通鍵暗号方式を組み合わせて、データを送受信し、通信経路におけるデータの盗聴、改ざん、なりすましを防ぐことができるため、インターネット上での取引決済時におけるクレジット情報や個人情報の送受信等に使用されている」 とあり、これは正答となっています。 「公開鍵暗号方式と共通鍵暗号方式を組み合わせて」は誤りで 「公開鍵暗号方式と秘密鍵暗号方式を組み合わせて」が正しいのではないでしょうか。
- ベストアンサー
- 行政書士
- 学校でRSA暗号について勉強して分からないところがありましたので質問し
学校でRSA暗号について勉強して分からないところがありましたので質問します。 暗号文の作成者をAさん、復号者をBさんとします。 Aさんは暗号文と公開鍵｛e,n｝を一般に公開しますよね？ 暗号文を復号化するには秘密鍵が必要ですが、Bさんはeとnしか分からない（一般の人と得られる情報が同じ）のにどうやって秘密鍵を作成するのですか？nのもとになっている2つの素数がわからないことには秘密鍵が作成できないとおもうのですが… RSA暗号はnの素因数分解が計算量的に困難だから安全なんですよね？Bさんはどうやって２つの素数を特定するのでしょうか？ 教えてください。
- ベストアンサー
- ネットワーク
補足
アドバイスありがとうございます、 PKIシステムで他人の証明書(≒公開鍵)が自由にダウンロードできる環境だと、 Aさんに、Aさん専用のXさん証明書を使ってもらうことが困難(Bさん専用のXさん証明書をAさんが入手できる) なので、運用実現性に高いハードルがあるように思います。 これは、保障による信頼性の連鎖の上で公開鍵暗号を利用することだと思っています。 今はほとんどの人が暗号通信をしていないと思っています。 （SSLについては、スノー伝君のことがあるので信用しない。） 日常の相互信頼の上に、少しずつ暗号化する部分を、それぞれが自分と通信相手のPCの能力を考慮しながら、広げていくと言う方向を考えています。 暗号化していない通信をしていた中で、お互いに合意したらその人との暗号化通信を開始する。 別の人とは互いに合意が出来た時点で暗号化通信を開始する。 必要に応じて公開鍵暗号や対称鍵暗号を選択する。 便利な点は、自分が最新のPCを持っていて、Bさんも最新のPCを持っているなら自分とBさんとの間では、強力な暗号化をしてもたがいのPCが処理できる。 Cさんが古いPCしか持っていないときは、自分とCさんとの間の暗号化はCさんのPCの能力に合わせて 軽い暗号化にする。 こうすれば、ネットワーク全体におけるPCの能力を最大に生かした暗号通信網になると考えます。 費用の件ですが、 いまは、RSA暗号ソフトも楕円曲線暗号のソフトも無料で入手できるので、 自分で公開鍵を作り、PC環境に合わせて変更してゆくことにしても、費用は電気代だけで１０円もかかりません。 対称鍵暗号のソフトも無料で入手できますので、それぞれの好みで使うことも出来ます。 偉い人に保障してもらうのではなくて、相互の日常の交流に安全性を少しずつ付け加える方式です。 もちろん、メールソフトの機能を少し拡張する必要があります。 互いに暗号通信を使う合意をしたら、その方式で暗号化してから送信できる機能と 受信してから復号化できる機能が必要です。 そして、合意していない人とは暗号化しないでメール交換が出来る。 そんなメールソフトがあればよい、 こんなことを考えています。