シナリオ:
私が完全に制御できる、公開されている Web サービス。しかし、この特定のデスクトップ アプリケーション (公開アプリケーション) だけが Web サービスにアクセスできるようにしたいと考えています。デスクトップクライアントに秘密のパスワードを保存することはできましたが、それは簡単に解読できてしまいます。
これを強制する既知の実装はありますか? PKI、非対称鍵?
シナリオ:
私が完全に制御できる、公開されている Web サービス。しかし、この特定のデスクトップ アプリケーション (公開アプリケーション) だけが Web サービスにアクセスできるようにしたいと考えています。デスクトップクライアントに秘密のパスワードを保存することはできましたが、それは簡単に解読できてしまいます。
これを強制する既知の実装はありますか? PKI、非対称鍵?
一般の人々がこのデスクトップ アプリのコピーにアクセスできる場合、優れたリバーサーはそれをクラックして、サーバーとのトランザクションを「模倣」することができます。アプリがデータを暗号化/復号化するために必要なものはすべてバイナリに含まれているため、クラッカーはそれを掘り出すだけで済みます。
暗号化の目的は、転送中のデータを「仲介者」のハッカーから保護することですが、ピアの誰かにアクセスできれば、簡単に解読できます。
サーバーは、クライアント側から来るものを決して信頼してはなりません。
[編集再開]
サーバーへの想定されるクライアントがアプリまたはサードパーティ製の「エミュレーター」であるかどうかを100%保証することはできませんが、物事を複雑にすることができます. ゲームのチート対策では、クライアント アプリを「オフセット A からオフセット B への main.exe のハッシュは?」のようなひっかけ問題にすることがよくあります。または「これからは、パケット タイプ 0x07 がパケット タイプ 0x5f とスワップされます」。偽物が検出されると、サーバーは「ばかげたモード」に入り、機能不全に陥り、IP /アカウントをこのモードに数時間ブラックリストに載せて、プログラムが間違っていることを確認できなくなります.
誰かがエミュレーターを作成していることに気付いたら、最初からやり直してください: パケット タイプ テーブル、暗号化テーブルをごちゃまぜにし、いくつかのパケット フォーマットを変更し、クライアントを強制的に更新します。しばらくはクラッカーに悩まされることはないでしょう...笑
WS-Securityは X509 暗号化を提供します。
その実装の一部には、生成された公開鍵を特定のクライアントにのみ与える可能性が含まれます。そうすれば、選択したクライアントのみがサービスに接続できます。
最も簡単な方法は、クライアントとサーバーの証明書を使用したメッセージ セキュリティです。最善の方法は、サーバー コンピューターにクライアント証明書をインポートし、app.config ファイルにクライアント証明書の拇印をハード コードすることです。もう 1 つの方法は、これまで試したことのない証明書のネゴシエーションです。
IIS を使用してサービスをホストしている場合は、SSL を使用するクライアント証明書も別のオプションです。
WCF Securityの MSDN リンク。