Asymmetric cryptography example in C#

Question

I need to send confidential data to a server over a TCP connection. I have done a lot of researching and I understand the theoretical part. Based on what I have researched I

Answer 1

Posting as an answer since it would be too long for a comment - it isn't specifically answering your question though.

As mentionned in the comment by driis, you should really rely on existing solutions which are regarded as being secure. That said, your protocol does have security issues:

• Communication is usually two-way, you however only seem to address one-way communication (client to server). This doesn't make much sense, since you say that you're going to use TCP, which is a two-way protocol in itself.

• Steps 4 and 5 are buggy: since you send the public key of the client inside the message, anyone could create a pair and encrypt the client identification using this pair. From your description the server has no forward knowledge of the client's keys, which makes this signature do nothing but ensure the integrity of the message - specifically is does not in any way make the client identification trustworthy.

For proper identification, you do have additional prerequisites; the server has to know the client's public key in advance or it has to be able to trust the client's claim to be himself by using a trusted 3rd party. This is what certificates and the certificate trust chains are about: if that client presents a certificate issued by the 3rd party X and the server trusts X, then he can assume that the client is who he pretends to be.

SSL basically supports two modes:

• Either only the server identity is verified and any client can communicate with it; the client's identity is not verified, only that (after the connection has been negotiated) it always is the same client which communicates to the server. This is the typical usage for online shopping etc. - you (as the client) trust the server and create a trusted connection, but the server does not know who you are.

• Two-way authentification can be done as well by using client certificates. The server has to know and trust either the client certificate directly or the issuer of the client certificate in order to negotiate the connection successfully. In this scenario, the server does indeed know who the client is, but the prerequisite as mentioned above has to be met.

Answer 2

As you note, you are a beginner at crypto. If this is a fun toy project to learn about crypto, great. If this is real production code you are going to implement it insecurely. You should be using off-the-shelf tools like SSL/HTTPS/whatever to solve this problem rather than doing it wrong yourself.

I'll take this opportunity to point out areas where your sketch is fatally weak.

3) the client get's the server's public key.

OK. How? This is the most important step. The security of the entire system relies upon this step, and you have completely glossed over how it works. How does the client obtain the public key of the server? What stops an evil person from calling up the client and saying "hey client, I'm the server. Here's my public key!" And now the client is encrypting messages that can only be decrypted by the evildoer. The evildoer has the real server's public key, so the evildoer re-encrypts the message with the real public key and sends it on. Your whole system is thereby compromised. The public key cryptosystem is only secure if there is a secure key exchange mechanism. (And a reasonable question then is: if you have a secure key exchange mechanism, why not simply use it to exchange the message in the first place?)

4) since the server needs to be certain that the message comes from that specific client then the client will encrypt his name (signature) with his private key.

The client should encrypt a hash of the entire message as the signature, not just a part of the message. That way the server has evidence that the whole message was from the client.

6) the client will encrypt the message with the public key from the server. client will then send that message to the server.

This is extremely inefficient. Better is for the server and client to agree upon a key to a symmetric cryptosystem. The key can be transmitted between the server and the client using the public key cryptosystem. The server and client now have a shared secret key that they can use for this communication session.

9) lastly, the server will decrypt the client signature with the public key that was contained on the message to verify that the message is from that client.

How on earth does that help anything? I want to send you a message. You want to know who it comes from. So I send you a photocopy of my drivers license, so you can compare the signature on the license with the signature on the message. How do you know I sent you my drivers license and not a photocopy of someone else's? This doesn't solve the client authentication problem at all. Again, you need to solve the key distribution problem. The system depends on there being a secure key distribution infrastructure, which you have not specified.