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

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

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

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

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

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

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

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

No.1 ベストアンサー 回答者： anmochi 回答日時： 2014/08/19 19:40

公開鍵暗号には二通りのやり方がある。

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

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

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

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

この回答へのお礼

ご丁寧にご教示頂きまして、情報有難う御座います。
頂きました情報を参考に作成してみます。

お礼日時：2014/08/20 15:37

No.3 回答者： uyama33 回答日時： 2014/08/20 07:00

http://www.ietf.org/rfc/rfc4880.txt

上の資料が役立つかも。

この回答へのお礼

情報有難うございます。
しかし、英語の苦手は私でも多少の英語は翻訳しながら見てきましたが、これはすごいボリュームですね

お礼日時：2014/08/20 14:36

No.2 回答者： uyama33 回答日時： 2014/08/19 21:40

実際に、困ることが少しあります。

１．クライアント側で、RSAの公開鍵と秘密鍵を作成するときに、時間がかかることです。
　　乱数を普通に作ると鍵作成には２時間くらいかかります。

２．次に、公開鍵、秘密鍵の作成には乱数を使うのですが、
　　NISTが警告を出していますので、そのことも検討する必要があります。
警告は、
http://www.businessnewsline.com/biztech/20130916 …

です。

３．送信するデータサイズが大きい場合は、RSAでの暗号化は、少し時間がかかります。
　　接続中に暗号化や復号化をしないで、暗号化してから接続して送信。
　　受信が終わってから復号化する。
　　
ようにしたほうが良いと思います。または、SSLのように混合型にする。

４．公開鍵暗号としては、楕円曲線暗号もありますが、鍵作成には大量のメモリーとRSAのとき以上の時間が
　　かかります。

鍵作成と乱数についてはよく確認したほうが良いと思います。

この回答へのお礼

情報誠に有難うございます。

鍵作成に2時間ほどかかるとの事ですが、下記の方法で実施した結果、ユーザーIDや鍵長の選択等、必要情報の入力を除いた時間はほんの数秒で完了しました。

2時間というのは、鍵作成だけでなく、公開サーバへの登録等、諸作業を含めての時間でしょうか？

お礼日時：2014/08/20 14:40