3

I am trying to devise a security scheme for encrypting the application level data between a silverlight client, and a php webservice that I created. Since I am dealing with a public website the information I am pulling from the service is public, but the information I'm submitting to the webservice is not public. There is also a back end to the website for administration, so naturally all application data being pushed and pulled from the webservice to the silverlight administration back end must also be encrypted.

Silverlight does not support asymmetric encryption, which would work for the public website. Symmetric encryption would only work on the back end because users do not log in to the public website, so no password based keys could be derived. Still symmetric encryption would be great, but I cannot securely save the private key in the silverlight client. Because it would either have to be hardcoded or read from some kind of config file. None of that is considered secure. So... plan B.

My final alternative would be then to implement the Diffie-Hellman algorithm, which supports symmetric encryption by means of key agreement. However Diffie-Hellman is vulnerable to man-in-the-middle attacks. In other words, there is no guarantee that either side is sure of each others identity, making it possible for communication to be intercepted and altered without the receiving party knowing about it. It is thus recommended to use a private shared key to encrypt the key agreement handshaking, so that the identity of either party is confirmed.

This brings me back to my initial problem that resulted in me needing to use Diffie-Hellman, how can I use a private key in a silverlight client without hardcoding it either in the code or an xml file.

I'm all out of love on this one... is there any answer to this?

EDIT:

Remember that this is about a custom PHP web service that I rolled out on my own.

I found an RSA implementation i can use in Silverlight. It seems pretty safe to use this to encrypt the handshake for the DiffieHellman key agreement between the Silverlight client and PHP web service, and subsequently also use it to encrypt the symmetric key that was agreed upon (which is itself generated from the result of the key exchange by hashing it).

After this I'm pretty much guaranteed that all communication going to the web service has not been intercepted, modified and then retransmitted (MITM). However I believe it is still possible; technically, for an attacker to impersonate the silverlight client and send messages to the webservice (assuming they discover the url).

Security from unauthorized access is provided since the attacker does not know the "secret api" of my custom webservice, hence they are unable to communicate with it.

The only way to break this would be to brute force the webservice with whatever strings an attacker may suspect to be valid to try and get a response from the web service. I don't think you can brute force a variable length string. It sounds impractical.

Does anyone see a problem with this approach?

4

3 に答える 3

3

SSL/TLS は、思いついた Diffie-Hellman ベースの実装と同じ問題を抱えており、中間者攻撃によって破られる可能性があります。

TLS が安全で信頼できる理由は、クライアントがサーバーの証明書を受信すると、それが既知の信頼できる ID (VeriSign など) からの別の証明書で署名されていることを確認して認証するためです。これまでのところ、VeriSign の秘密鍵がなければ中間者攻撃を実行することはできません。侵入者がサーバーであると宣言する偽の証明書を送信すると、クライアントはこの証明書が署名されていないことを簡単に検出します。信頼された ID の証明書を破棄し、接続から抜け出し、ユーザーに警告を表示します。

あなたの目的のためには、TLS を使用するのがおそらく最も簡単です。セキュリティを確保するには、サーバー用の証明書を生成し、その証明書の公開鍵をクライアントに埋め込みます。クライアントは、配布する必要のない秘密鍵を公開することなく、サーバーと通信していることを確認できます。

編集:ジェリーの回答に対するあなたのコメントに応えて、ホスティング プロバイダーが SSL/TLS 接続をまったく許可していない場合、中間者攻撃を防ぐのは難しいでしょう。これが TLS を回避する唯一の理由である場合は、プロバイダーに TLS を有効にしてもらうか、TLS を許可するプロバイダーを見つけることをお勧めします。

編集:編集した質問への回答: Silverlight クライアントで RSA を使用して Web サービスにデータを送信している場合でも、クライアント自体が変更されていないことを保証することはできません。攻撃者がクライアントを掘り下げ、暗号化/ハンドシェイクを実行するために使用しているアルゴリズムを特定し、クライアントになりすますためのコードを作成する (または実際には、クライアントを変更してコードを含める) 可能性は十分にあります。それが完了すると、API の分析を開始し、それを使用して Web サービスを呼び出すことができます。

SSL/TLS の場合も同じです。クライアントはホストの証明書を使用してホストの ID を検証でき、ホストのサーバーが保護されている限り、クライアントはホストからの出力を信頼できます。ただし、クライアントは制御された実行環境を持たないマシン上で実行されるため、ホストがクライアントが本人であることを 100% 検証できるメカニズムはありません。

ただし、上記が真実であり、攻撃者がこの方法でシステムを侵害する可能性あるにもかかわらず、多くの注目/使用を引き付ける公開システムで作業していない限り、またはなんらかの形で金銭を直接扱うシステムであるため、攻撃者は自分の入力を Web サービスに送信する前に、ある程度の努力をする必要があります。

最善の策は、Web サービスが受け取った入力を徹底的に検証し、通常のクライアントが決して使用しないダングリング API をアクセス可能なままにしないことです。

于 2010-04-23T03:26:43.090 に答える
1

明らかな解決策は、アプリケーションに組み込むのではなく、WCF を使用して SSL または TLS 接続を確立することです。

于 2010-04-23T03:14:06.213 に答える
0

この JavaScript+PHP DH キー交換プロトコルから始めることをお勧めします: http://enanocms.org/News:Article/2008/02/20/Diffie_Hellman_key_exchange_implemented

その後、Silverlight で JavaScript を書き直すことができます。Wireshark を使用してパケットをダンプすることをお勧めします。その後、Meld などを使用してパケットを比較し、実装が元の実装とどこが異なるかを確認できます。

幸運を!

(免責事項: Enano 開発チームに完全に同意します。これは SSL の完全な代替ではなく、可能な限り SSL を使用する必要があります。)

于 2010-04-27T21:16:59.807 に答える