サーバ側で秘密鍵（証明書）を生成するのは悪い考えですか？

Question

私は暗号化プロジェクト（C＃を使用）を使って作業しています。

非対称暗号化用の秘密鍵を生成するにはクライアントが必要ですが、いくつかのライブラリを見直したので、それほどクリーンではありません&簡単な作業です。

なぜですか？ makecert.exe、pvk2pfx.exeなどを使用してそれらを生成

• ...しかし、これらのツール は、Windows SDKからであり、彼らがリンクされているように思わ：Windowsで秘密鍵を生成するための

  、私は次の可能性を持っています クライアントがクリーンなOS（インストールされているライブラリなし）を持っている場合は、私は 1）とすることができます。クライアントのPCにWindows SDKをインストールする2）。コピーmakecert.exeおよびその他のユーティリティと は、プロジェクトの分布とそれを保持する（私が思うに、それは悪い考えですが異なるため、Windowsのバージョン（7〜10）と32/64ビットアーキテクチャ

• がBouncy Castle、悪くない道を（使用して生成します私はプログラミング言語を使用することができますし、外部ツールではありません）、C＃のバージョンはよく文書化されておらず、ソースコードにいくつかの醜い場所があります

• OpenSSLを使用して、複数の関数があるので、ライブラリにエラーがある を呼び出す（マルチスレッドの場合）

• PowerShell使用

  （またオプションを、私は7のようなWindowsの古いバージョンでそれをサポートして 問題があるだろうと仮定）私は、クライアントを解放した場合にどのようなものを事実により

、私が思います、秘密鍵の生成からですか？それは悪い考えですか？私はそれをサーバ側で生成することができ、秘密鍵を保存しないでください。秘密鍵はTLS経由で転送するだけです。

どのような脆弱性が存在しますか？ TLSの使用がSTRICTオプションであると考えてください。

Answer 1

これはアプリケーションによって異なります。サーバー上に秘密鍵を生成することには少なくとも2つの問題があります。

1. クライアントは、このキーを後で保存するとは限りません。あなたは知っているが、クライアントはそれを知らない。アプリケーションによっては、重要な違いがあるかもしれません。

2. TLSでキーを送信しても、特定の状況下では途中で人によって傍受される可能性があります。たとえば、組織内の各コンピュータに信頼されたルート証明書をインストールし、この組織にあるすべてのSSLトラフィックを傍受して解読することができます。これは、アプリケーションのタイプによっては重要ではないかもしれません。

多数のユーザーを対象としたチャットアプリケーションを作成し、ユーザー間のすべてのメッセージを暗号化したいとします。サーバー上で鍵を生成する場合、誰もあなたのアプリケーションを使用することはありません。まず、すべての鍵を政府にダンプすることができます（100％保証されているとは限りません）。もしそうでない場合でも、 "偽の"信頼されたルート証明書を使用してsslトラフィックが検査される全国があります。

短い話ですが、クライアントで秘密鍵を生成できるのであれば、そうしてください。あなたの場合、私はできると思います。

Answer 2

複数の考慮事項に応じて！

• ユーザーは何を期待していますか？ SpiderOakのような「ゼロ知識」ソリューションを提供することを目指す設計は、サーバーへの管理者全員がデータを復号化することができないことを保証します。この場合、サーバー上で鍵を生成し、それを保管しないことを約束してもそれを切断するわけではありません。サーバーへの完全な管理アクセス権を持つ人はいつでも、その約束を破る可能性があります。実際のゼロ知識を得るためには、クライアント側で鍵を生成する必要があります。
• パフォーマンスへの影響を受け入れますか？それはDoSベクトルを開きますか？たぶん私は警備員なので、私は絶対にサーバーでやっていないでしょう。

私があなただったら、私はクライアント側でBouncyCastleを追求します。