Add RSA based encryption to WCF service without ce

问题:

I am looking for a way to encrypt messages between client and server using the WCF. WCF offers a lot of built in security mechanisms to enrcypt traffic between client and server, but there seems to be nothing fitting my requirements.

I don't want to use certificates since they are too complicated, so don't suggest me to to use certificates please. I don't need confidentiality, so I though I'll go best using plain RSA.

I want real security, no hardcoded key or something. I was thinking about having a public/private keypair generated every time the server starts. Both keys will only be stored in RAM. Then wen a client connects it should do exactly like SSL. Just as described here.

1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)

2.using that private/public key pair, exchange a common shared secret, e.g. an "encryption key" that will symmetrically encrypt your messages (and since it's symmetrical, the server can use the same key to decrypt the messages)

3.setup infrastructure on your client (e.g. a WCF extension called a behavior) to inspect the message before it goes out and encrypt it with your shared secret

That would be secure, wouldn't it?

Is there any existing solution to archive what I described? If not I'll create it on my own. Where do I start best? Which kind of WCF custom behaviour is the best to implement?

---

EDIT: As this is NOT secure, I'll take the following approach:

When Installing the server component a new X509 certificate will be generated and automatially added to the cert store (of the server). The public part of this generated certificate will be dynamically included into the client setup. When running the client setup on the client machine the certificate will be installed into the trustet windows certificate store of the client.

So there's no extra work when installing the product and everything should be secure, just as we want it.

回答1:

You've said you don't want to use certificates. I won't push certificate use on you, but one thing you are missing is that certificates serve a purpose.

A certificate proves that key you are negotiating an SSL connection with belongs to the entity you think it belongs to. If you have some way of ensuring this is the case without using certificates, by all means, use raw keys.

The problem is, in step 1:

1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)

How does the client know that the public key it received from the server wasn't intercepted by a man-in-the-middle and replaced with the MITM's key?

This is why certificates exist. If you don't want to use them, you have to come up with another way of solving this problem.

Do you have a small, well-known set of clients? Is it possible to preconfigure the server's public key on the client?

回答2:

Alexandru Lungu has created an article on codeproject:

WCF Client Server Application with Custom Authentication, Authorization, Encryption and Compression

回答3:

No, it would not be secure!

since there's no confidentiality, an attacker could do a men in the middle attack, and all the security is gone.

The only real secure way of encrypting messages between server and client IS to actually use digital certificates.

回答4:

I'm sorry, the only two methods of providing secure communications are:

1. Use a public key infrastructure that includes a chain of trust relationships, a.k.a. certificates

or

1. Use a shared secret, a.k.a. a hardcoded key.

Nothing else addresses all of the known common attack vectors such as man-in-the-middle, replay attack, etc. That's the hard truth.

On the other hand I can offer you an alternative that may alleviate your problem somewhat: Use both.

1. Write a very, very simple web service whose only job is to generate symmetric keys. Publish this service via SSL. Require end user credential authentication in order to obtain a symmetric key.

2. Write the rest of your services without SSL but using the symmetric keys published via the first service.

That way your main app doesn't have to deal with the certificates.