I need to implement end-to-end encryption. To do this, I'm thinking of exchanging public keys between two users, then encrypt messages with the public key, and send the message back to the user via the server. Does it make sense to do this messaging over TLS, or would it be redundant? Since the data will be encrypted, I think TLS will be superfluous here, but I doubt it.
It's not only about encryption. You also need a trustful third party to authenticate the website in order to avoid DNS poisoning. That's the job of an SSL/TLS certificate.
Related
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.
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?
Alexandru Lungu has created an article on codeproject:
WCF Client Server Application with Custom Authentication, Authorization, Encryption and Compression
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.
I'm sorry, the only two methods of providing secure communications are:
Use a public key infrastructure that includes a chain of trust relationships, a.k.a. certificates
or
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.
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.
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.
I am implementing an app where I don't have a system requiring username and password. What I do require is a name and a phone number.
The scenario is like this:
1) user opens the app for the first time
2)app makes a request to my server and gets a unique UserKey
3)from now one any request the app makes to my REST service also has a signature. The signature is actually a SHA(UserKey:the data provided in the request Base64Encoded)
4)The server also performs the same hash to check the signature
Why I don't use SSH:
not willing to pay for the certificate
I don't need to send sensitive data like passwords, so I don't see the benefit of using it
I just need a simple way to call my own WCF REST services from own app
I understand that there is a flow of security at step2 when the UserKey comes in cleartext, but this happens only once when the app is first opened. How dangerous do you think this is?
What would you recommend? Is there any .NET library that could help me?
Actually, there are several problems with that approach. Suppose there's man-in-the-middle whenever you make a request to the server. By analyzing, for example, 100 sent packets he would recognize similar pattern with signature in your requests. Then he would forge his own request and add your signature. The server checks the hash - everything's alright, it's you and your unique user key. But it's not.
There's a notion of asymmetric keys in cryptography which currently is really popular and provides tough security service. Main concept is the following: server generates two keys - public and private; public key is used to encode texts; they can be decoded only with the use of private key, which is kept by the server in secure location. So server gives client the public key to encode his messages. It may be made double: client generates public key and gives it to the server. Then server generates keys and gives encoded with client's public key his own public key. This way it's almost impossible for man-in-the-middle to make an attack.
Better yet, since the problem is really common, you could use OAuth to authorize users on your website. It is secure, widely used (facebook, g+, twitter, you name them) and has implementations already in variety of languages.
Since you control both the application itself and the webservices, you can do this with SSL (which gets rid of the problems with your current approach) without paying for anything. You can create a self-signed certificate and install that on your webserver; configure the SSL context of your client application to only trust that one certificate. Then, create a client-side self-signed certificate and install that within your application. Set the server up to require mutually-authenticated SSL and only allow your self-signed certificate for access.
Done. You client will only talk to your legitimate server (so no one can spoof your server and trick the client in to talking to it) and your server will only talk to your legitimate clients (so no one can steal information, ID, etc). And it's all protected with the strong cryptography used within SSL.
If one way SSL is used (Server Certificate authentication) then data sent from client gets encrypted using Public key of the server certificate. So privacy protection is available for data sent from client. My questions are
Does this mean that in One way SSL data sent from Server to client is not encrypted and sent as plain text ?
For both server to client and client to server communications the data/message is not signed and so tamper protection or data integrity is not assured. Are there any other means to achieve data integrity while using SSL based transport security and not Message security options ?
One way SSL just means that the server does not validate the identity of the client. It has no effect on any of the other security properties of SSL.
While the SSL protocol is a bit complex, the basic gist of what happens is this: The client generates a random key, encrypts it so that only the server can decrypt it, and sends it to the server. The server and client now have a shared secret that can be used to encrypt and validate the communications in both directions.
The server has no idea of the client's identity, but otherwise, the encryption and message validation is two way.
Update:
1) Yes, encryption both ways is symmetric and uses a shared secret generated during session setup.
2) With a shared secret, message integrity is trivial to assure. You just ensure the message has a particular form. For example, I can prefix every message I send with a sequence number and append a checksum onto it before encryption. You decrypt it with the shared secret and validate the sequence number and checksum. How can an attacker substitute or modify the message without knowing the shared secret and still keep the sequence number and checksum intact?
In SSL, two things happen:
First, a session key is negotiated using something like the
Diffie-Hellman method. That generates a shared session key but never
transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for
the duration of the connection.
SSL does use public/private in one way, because an X509 certificate is
used to identify at least one end of the connection. Those certs are
signed using an asymmetric key pair.
Extracted from How can SSL secure a two-way communication with only one key-pair?
What is the best means to verify that a server is who it says it is.
I'm guessing using signed SSL certs is the best route, but was wondering if there was any programmatic means to do this..
EDIT: This is for a an app where servers deal with other servers (authenticating each other) in order to exchange user info. (sorry if I forgot to mention that)
SSL certificates signed by an authorized CA (certificate authority) is the only way to be sure. Anything else can be faked, and especially any "programmatic means" would be particularly unreliable. Short and simple: an authorized SSL cert is the only thing a browser will recognize as reliable, regardless.
You don't need certificates to prove your identity (or a server's for that case) to someone. You can use pre-shared keys for that purpose, and avoid any public key infrastructure. The TLS (or SSL) protocol supports that. Find a TLS library that allows you to use TLS-PSK and use it.
I'd recommend HMAC or RSA. HMAC is pretty secure and much easier to implement. HMAC could get unwieldy if you have 5 servers that all need to communicate with each other directly.
What are you trying to secure? It sounds like a web application, and if it is one, then you should go with SSL certs.
Hopefully a quick question.
I want to secure my WCF service that will be consumed by a known party. Our organisation trust theirs and vice versa.
This service is already restricted by IP address, so we know the caller must have come from their network.
However I would like it to be protected against malicious developers within that organisation. In theory they could write a Bad App and install it anywhere on this network, and call our service, which would return the data.
I think a way around this would be to also use Client Certificates, which would be validated using Peer Trust. Each request would send this certificate, which we would validate on the WCF service, and send back the data.
My question - is this going to protect against the malicious developer scenario outlined above? We would know that the request would have to originate on the server with the client certificate installed (right?) - and I imagine it should be difficult for a malicious developer to get a Bad App on there. It is a shame we can't tie it down to exactly the client application - or could we?
Any help appreciated - just want to make sure I nail my understanding of this!
If you will be granting access to your service based on the specific incoming client certificate, it should be as secure as the private key of that certificate. That is, if the private key is kept safe in the other organization, your service will be as safe (as safe as that public/private key pair of the certificate in terms of encryption).
If the private key is compromised within the other organization, for example, an attacker has access to it on the remote server, or is able to copy it to another remote server, then that attacker has access to your service. Because, once they have the private key, they can use the client certificate to connect using an SSL connection, and then they just have to pass the IP address check. Protect the client certificate's private key.
You may check on the service side if the client has authenticated itself with specific certificate. You may also write Custom Certificate Validator and validate certificate according to your own needs. However, if you assume that the attacker may be able to use private key of trusted certificate in your environment, then I guess you may assume that the attacker can basically do anything and there is no way you can secure your service.