Is this scenario safe?

Question

I use RSA to encrypt communication between server and client. Suppose we have 2 Asymmetric keys, keys 1 and key2.

The server has key1 (private) from the start, and the client has key1 (public)

So here is the scenario:

• the client generates a key2
• client connects to server
• key transfer2 (public), encrypted using key1 (public)
• from this moment the server will send all the data encrypted using key2 (public)
• the client sends some random data to the server.
• the server sends back the same hashed data
• the client checks the correctness of the data.

As far as I see, this should prevent a man in the middle attack, or am I missing something? At point 7, the client should know if someone is trying to force the server to encrypt the wrong key, since no one except the server can decrypt key2 (public).

If there is anything that can be done to improve security, tell me.

Answer 1

The best you can do to improve safety is to use your existing design and not try to reinvent the wheel. I'm not saying that what you did is necessarily wrong, but many people are much smarter than you and I have been thinking about this problem for a long time. Use TLS instead.

Answer 2

Until key1 (private) has been intercepted by a third party in any way, your script looks safe.

I think I saw it somewhere in the newspaper. In it, Alice gave Bob an unlocked box (key 1 public), then Bob put a bunch of his boxes (key 2 public), blocked it and sent it back to Alice. Alice then opens the box (key 1 is closed), and now she can securely seal the boxes that Bob just gave her.

Despite the box analogy, this is what you do, so I would say that it is safe.

Answer 3

No, this protocol is not secure.

A person in the middle can intercept the data sent by the client and send whatever it wants to the server, since you have not specified any mechanism for client authentication or message integrity verification.

Of course, you could study your protocol to fix these glaring problems, but there would be others. If you ever fix them all, you will have something that appears in TLS or SSH, so why not just start there?

---

@Petoj - the problem I focused on is that the server trusts the messages it receives; Your offer does not provide any security there. However, if you are concerned about privacy, you still have a problem, because MITM can send messages back and forth without changes until it sees what it wants to find, because you do not have confidentiality in client messages.

Your suggestion seems to be aimed at ensuring the integrity of messages from the client. You developed a protocol until the client cannot distinguish between attack and network failure. Instead of trying to help the client determine if the server was acting on a forged message, allow the server to check the integrity of the message before acting on it.

Answer 4

I agree, just use TLS.

Also, what is the meaning of steps 5 through 7? MITM, who wants to make an attack that will work after steps 1-4 (for example, DoS of some type, passing n transactions through, and then stopping, forcing to try again from the very beginning), can do this also after 5-7. What do they add?

- MarkusQ

Answer 5

I agree with Greg that you are reinventing the wheel . Basically you describe the basic form of key exchange . By the way, to make sure that it is protected from man-in-the-middle attacks, you should also be sure of the server’s identity, that is, make sure that the client can confidently know that what he considers public (key1), it’s really a server, not a man in the middle (for example, using a CA or having a public server (key1) in a secure store on the client side.)

In addition, there are additional considerations that you should know from a systemic point of view, for example:

• asymmetric key encryption is slower than symmetric key encryption, which is one of the reasons why existing solutions such as TLS will use asymmetric key encryption only to negotiate a temporary symmetric key, which is then used to encrypt the channel.
• If a third-party traffic analysis manages to crack a temporary symmetric key, you have not compromised the asymmetric key pair. For this reason, we recommend re-discussing the temporary key . Perhaps creating a new key2 in your script will reduce this aspect.