3

WCF を使用してクライアントとサーバー間のメッセージを暗号化する方法を探しています。WCF には、クライアントとサーバー間のトラフィックを暗号化するための組み込みのセキュリティ メカニズムが多数用意されていますが、私の要件に適合するものはないようです。

証明書は複雑すぎるので使いたくないので、証明書の使用を勧めないでください。機密性は必要ないので、プレーンな RSA を使用するのが最善です。

ハードコードされたキーなどは必要ありません。サーバーが起動するたびに公開鍵と秘密鍵のペアを生成することを考えていました。両方のキーは RAM にのみ保存されます。その後、クライアントが接続すると、SSL とまったく同じように動作するはずです。ここで説明したとおりです。

1.何らかの形式の秘密鍵と公開鍵のペアを交換します。サーバーはキー ペアを生成し、秘密キーをそれ自体に保持し、公開キーをクライアントと共有します (たとえば、WCF メッセージを介して)。

2.その秘密鍵と公開鍵のペアを使用して、メッセージを対称的に暗号化する「暗号化鍵」などの共通の共有秘密を交換します（対称であるため、サーバーは同じ鍵を使用してメッセージを復号化できます）

3. クライアントにインフラストラクチャをセットアップする (例: 動作と呼ばれる WCF 拡張機能)。メッセージが送信される前に検査し、共有シークレットで暗号化します。

それは安全ですよね？

私が説明したものをアーカイブする既存のソリューションはありますか? 無ければ自分で作ります。どこから始めればよいですか？どの種類の WCF カスタム動作を実装するのが最適ですか?

編集: これは安全ではないため、次のアプローチをとります。

サーバー コンポーネントをインストールすると、新しい X509 証明書が生成され、(サーバーの) 証明書ストアに自動的に追加されます。この生成された証明書の公開部分は、クライアントのセットアップに動的に含まれます。クライアント マシンでクライアント セットアップを実行すると、証明書はクライアントの trustet Windows 証明書ストアにインストールされます。

そのため、製品をインストールする際に余分な作業は必要なく、すべてが安全である必要があります。

4

4 に答える 4

4

証明書を使用したくないと言いました。私はあなたに証明書の使用を押し付けるつもりはありませんが、あなたが見逃していることの 1 つは、証明書が目的を果たすということです。

証明書は、SSL 接続をネゴシエートしているキーが、それが属していると思われるエンティティに属していることを証明します。 証明書を使用せずにこれが当てはまることを確認する方法がある場合は、必ず生のキーを使用してください。

問題は、ステップ 1 にあります。

1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)

クライアントは、サーバーから受け取った公開鍵が中間者によって傍受され、MITM の鍵に置き換えられたものではないことをどのようにして知るのでしょうか?

これが、証明書が存在する理由です。それらを使用したくない場合は、この問題を解決する別の方法を考え出す必要があります。

小規模で有名なクライアントのセットはありますか? クライアントでサーバーの公開鍵を事前に構成することは可能ですか?

于 2012-11-01T14:11:13.923 に答える
4

Alexandru Lungu が codeproject に関する記事を作成しました。

カスタム認証、承認、暗号化、および圧縮を使用する WCF クライアント サーバー アプリケーション

于 2012-11-01T12:56:19.080 に答える
2

いいえ、安全ではありません。

機密性がないため、攻撃者が中間者攻撃を行う可能性があり、すべてのセキュリティが失われます。

サーバーとクライアントの間でメッセージを暗号化する唯一の安全な方法は、実際にデジタル証明書を使用することです。

于 2012-11-01T13:25:30.043 に答える