Silverlight and Encryption, how to store/generate they key/iv pair?

Question

I have a Silverlight app that connects to a php webservice. I want to encrypt the communication between the webservice and the Silverlight client. I'm not relying on SSL. I'm encrypting/decrypting the POST string myself using AES 256bit Key and IV.

The big questions then are:

1. How do I generate a random unique key/iv pair in PHP.

2. How do I share this key/iv pair between the web service and silverlight client in a secure way.

It seems impossible without having some kind of hard coded key or iv on the client. Which would compromise security.

This is a public website, there are no logins. Just the requirement of secure communication.

I can hard code the seed for the key/iv (which is hashed with SHA256 with a time stamp salt and then assigned as the key or iv) in PHP source code, that's on the server so that is pretty safe. However on the client the seed for the key/iv pair would be visible, if it is hard coded.

Further more using a time stamp as the basis for uniqueness/randomness is definitely not ok, since timestamps are predictable. It does however provide a common factor between the C# code and the PHP code.

The only other option that I can think of would be to have a 3rd service involved that provides the key/iv to the Silverlight client, as well as the php webservice. This of course start the cycle anew, with the question of how to store the credentials for accessing the key/iv distribution service on the Silverlight client.

Sounds like the solution is then asymmetric encryption, since sensitive data will be viewed only on the administrative back end of the website. Unfortunately Silverlight has no asymmetric encryption classes. The solution? Roll my own Diffie-Hellman key exchange! Plug that key into AES256!

Answer 1

You could use a public/private key encryption system like RSA. The client would encrypt a packet using the well-known public key of the server, send the encrypted data, and the server would decrypt it using the secret private key. Anyone can send the server data encrypted using the public key, but only the server can decrypt it. Just like SSL does.

Which brings us back to the question: why aren't you using SSL?

Answer 2

The answers to your questions are: "SSL".

Symmetric encryption expands a shared secret of relatively small size (e.g. a 256-bit key) into a secure data transmission tunnel which ensures confidentiality and integrity. This is not as easy as it may seem; there are many small but deadly details.

Asymmetric cryptography is about establishing that shared secret over an insecure network. RSA encryption, Diffie-Hellman... are algorithms which can help you with that. You still have to begin somewhere; i.e., if you use the public key of the server (its RSA public key, its half of Diffie-Hellman...) then you must have some way to know that you are using the right public key, not the public key of some bad guy who intercepts the communication and feeds you his own key instead. There are ways to do that, mainly with hardcoding a public key within the client application, public key which is either the server public key or a key which can be used to sign it (that's certification). Of course, with Silverlight the client code is also downloaded, hence potentially tweaked by the same bad guy, so you would have to sign the code and have the browser verify that signature.

All this is hard work and has scores of pitfalls. The SSL protocol went through all of them, and was patiently but painfully updated and fixed. It took many years and many smart people, and there was much grinding of teeth. A similar protocol is SSH (some encoding details differ but the principles are the same). If you want to design your own protocol, then chances are that you will reenact most of the weaknesses and issues that plagued SSL and SSH. Simply using SSL or SSH would save you much time and trouble.