how to encrypt soap message in silverlight.. i am currently looking for ideas... as silverlight doesn't support WCF Message Security.. i have gone through a post by Peter Bromberg but it is also not discussing the idea about when how to exchange public/private keys or sort of...
SSL is no option because client end is not secure..
Usman Masood
2009-06-17 06:56:13
What do you mean, "is not secure"? Does it not implement SSL? Does that machine never make SSL connections today?
John Saunders
2009-06-17 10:46:30
Simply due to some business constraint.
Usman Masood
2009-06-17 11:52:21
Nonsense. Give us some understanding of the business constraint. I've never heard of a reason to not use SSL. The last good reason I heard of (not enough memory and this is an embedded device) has been getting less and less of a problem since I first heard that complaint 10 years ago.
John Saunders
2009-06-17 12:05:26
simple widgets developed in silverlight and deployed on client side... can't enforce them to have ssl... its my business constraint... and based on requirements.... its nothing about becoming offensive.
Usman Masood
2009-06-17 18:15:50
@Usman: thanks. That's all you had to say. I now say that if they don't want encryption, then they won't get it. Support SSL or nothing, and if they don't want SSL, they'll get nothing. I still have trouble imagining a client machine that does not support SSL. Do these machines never use a web browser to go to a secure site?
John Saunders
2009-06-17 19:16:52
A:
The approach discussed in the post doesn't appear to do any asymmetric key exchange (as TLS does). Instead it relies on a symmetric key that is generated based on some assembly metadata. See the last paragraph of the article:
In closing, let me just address a couple of concerns: First, nowhere here do I say that this is "better" than SSL. I provide it only as an alternative. Second, the fact that the password or other component of the generated cryptographic key may be shown in plaintext in the code is not useful to a hacker, as both the password and the hash (both of which can be generated only at runtime) are required for a valid key. The download reflects the change to using the FullName property of the assembly to generate the salt value, and the ManifestModule.Name.GetHashCode() for the password, as discussed earlier.
It's not a very strong key generation mechanism as an attacker could simply download the same Silverlight application fire up a debugger and get the key. However it will protect any man-in-the-middle attacks where the attacker only has access to your HTTP traffic.
Personally I'd stick with SSL, with a self signed certificate if the goal is to have a free solution.
sipwiz
2009-06-17 06:48:36
i agree but due to constratin SSL is no option. thats why i have to come up with alternate options..
Usman Masood
2009-06-17 06:56:56
The only "proper" way to do it then is to use an asymmetric algorithm and generate a new public/private key pair for the Silverlight app each time it runs. Your server's public key can be hard coded into the silverlight app which would allow the SL end to generate a new symmetric key. The hard part is the asymmetric algorithm. I'm not sure if the SL framework has one but I don't think so. There's probably an open source one around though.
sipwiz
2009-06-17 07:06:12
you are right! SL doesn't provide any asymmetric and neither are there any plans for it in Version 3.
Usman Masood
2009-06-17 11:53:23