そのため、DPAPI を使用して対称キーを保存しようとしています。すべてはうまくいっていますが、エントロピーをどうするのでしょうか? この回答済みの質問は、実際には十分な洞察を提供していません。滑りやすい坂道のように思えます - マシン ストアを使用してエントロピーを保存することもできますが、誰かがそれを行うのを妨げるものは何ですか? 注: ユーザー スコープを使用して現在のキーを保存しています。
だから私の質問は - DPAPI を使用してエントロピーを格納する最良の方法は何ですか?
そのため、DPAPI を使用して対称キーを保存しようとしています。すべてはうまくいっていますが、エントロピーをどうするのでしょうか? この回答済みの質問は、実際には十分な洞察を提供していません。滑りやすい坂道のように思えます - マシン ストアを使用してエントロピーを保存することもできますが、誰かがそれを行うのを妨げるものは何ですか? 注: ユーザー スコープを使用して現在のキーを保存しています。
だから私の質問は - DPAPI を使用してエントロピーを格納する最良の方法は何ですか?
ローカルに保存するものはすべて危険にさらされる可能性があります。しかし、それをより困難にするためにあなたが取ることができるステップがあります。パスワードの処理に関するドキュメントがあり、確認することを検討してください。エントロピーキーをアプリケーションに固有のパスワードと見なします。
機能的には追加のキーであるため、エントロピーをキーと呼びます。
やりたくないのは、暗号化されていない形式でキーをローカルに保存することです。代わりに、キーを暗号化するか、別の非自明なソースからキーを取得する必要があります。もちろん、キーを暗号化する場合は、暗号化に使用したキーを保存する必要がありますが、多くの場合、この1層の間接参照で、ほとんどの挑戦者を思いとどまらせることができます。
それはあなたの鍵を引き出すことの利点でしょう。他の定数データのハッシュとして導出できます(アプリケーションのリビジョンによって変更されないものである必要があります)。ただし、ハッシュを導出する際の1つのトリックは、ハッシュを他の定数値(GUIDや大きな乱数など)と組み合わせて、他の誰かが既知のハッシュアルゴリズムを組み合わせてキーを取得できないようにすることです。これは、独自のハッシュアルゴリズムを作成するよりもはるかに優れた代替手段です(数学の博士号を取得していない限り、絶対に実行しないでください)。
ある時点で、アプリケーションにハードコーディングされたある種のキーが必要になります。このキーは、ハッシュ内の他のデータと組み合わせてエントロピーキーを作成するか、エントロピーキーを復号化するために使用されます。既存のキーを復号化するために古いキーを保持している限り、実際には、アプリケーションの新しいリビジョンでキーを変更できます。次に、新しいキーまたはメソッドを使用して再暗号化できます。
最高のセキュリティが必要な場合は、エントロピーキーをコンピュータから保存できます。これにはインターネット接続とSSL証明書が必要ですが、それらのキーがローカルのどこにも保持されて検出されることはありません。これを行うには、より堅牢なチャレンジレスポンスシステムをセットアップして、リクエスト認証が毎回異なるようにし、キーがSSL暗号化を介して配信されるため、傍受されないようにすることができます。キーが使用されると、それは破棄されます。もちろん、この種の方法では、ローカルの安全なストレージにDPAPIを使用している多くのシナリオの目的が損なわれます。
何をするにしても、それが危険にさらされることに注意してください。これは、誰かがローカルマシンとそこに保存されているデータに完全にアクセスできる場合に常に発生します。その解決策は、古いクラックが機能しなくなるほどメソッドを変更する更新をリリースし続けることです。これにより、適切なバージョンのクラックを見つけることが困難になるため、クラックの配布の価値が低下します。
まず、元の投稿の質問に答えさせてください。要するに、エントロピーを永続ストレージに使用する場合は、ユーザーの権限および/またはアプリケーションの権限の下でエントロピーを保存する必要があるという事実です。アプリケーションに保存されているキーを使用して、永続化されたストア内の情報を暗号化できると思いますが、悪意のあるアプリケーションがこの暗号化キーにアクセスできる可能性があります。したがって、コメントで言及したシナリオから保護する手段があるとは思いません。ただし、あなたが言ったことはエントロピーの意図された使用であることを考えると、それがあなたの問題の解決に役立つとは思いません.
実際の問題は、クライアント アプリケーションとサーバー間の安全な通信チャネルの確立にあるようです。設計では、通信の暗号化に使用されるキーを交換しています。カスタム コードを使用してこの問題を解決しようとすると、セキュリティ上の脆弱性がさらに増えると思います。
以上のことから、機密情報の取得に使用される WCF (Windows Communication Foundation) サービスを作成することをお勧めします。もちろん、すべての情報を取得するために使用できますが、最小限の変更は、サービスを機密情報に限定することです。
WCF を使用すると、クライアントとサーバーの両方がセキュリティで保護されたチャネルを使用するように構成できます。WCF には、サーバーへの安全な通信チャネルを確立するための多くのオプションがあります。
<wsHttpBinding>
<binding>
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</wsHttpBinding>
安全なチャネルがあれば、CC データへのアクセスなど、他の問題の多くは簡単になります。そのデータが安全なチャネルに送信されると、チャネル セキュリティではなく承認の問題になります。
詳細については、「方法: セキュリティで保護されたセッションを作成する」を参照してください。