Why can a man-in-the-middle attack not happen with RSA?

Question

I understand how RSA works (generate private/public key pair, send public key to whoever you want to talk to, encrypt with public, decrypt with private), but isn't there a flaw in this?

Let's say A wants to send a message to B. A generates his public/private key pair, and sends the public key over a network to B, right? What's stopping C coming along and intercepting this public key, generating his own public key, and then sending his own public key to B? Then, when B sends his public key back to A, C could intercept this, store it, and send his own public key to A.

Now, when A sends an encrypted message using what he thinks is B's public key (but is actually C's), C will intercept this message, decrypt it, then encrypt it again using B's actual public key.

Would this work? If not, why not? Is it just a matter of using a secure network to send the public key?

Answer 1

This is the problem of key distribution, and it is difficult. In general, Alice must already know that the key belongs to Bob, or have someone she trusts attest that it belongs to him.

For HTTPS this is accomplished by a Public Key Infrastructure (PKI), where Certificate Authorities (CAs) attest that a key belongs to a certain domain or set of domains. This scheme quickly falls apart if any widely trusted CA proves unworthy of the trust placed in it, and unfortunately this has happened multiple times in the past (WoSign, Symantec).

SSH mitigates it by storing the host key for each server you connect you, then warning you if the host key changes for future connections (this is called trust on first use). It also warns you and allows you to verify the key's fingerprint when first connecting, but this requires obtaining the fingerprint through some other means, so it doesn't solve the problem so much as pass it on to the user.

Answer 2

The problem you described can indeed happen - nothing in RSA (or any other encryption scheme) prevents it. This is called eg. "key distribution problem".

Yes, exchanging they key over a secure channel, instead of the insecure one of the message, is one way to solve it. Depending on the use case there might be other useful ways (or not).

In TLS, this is prevented by already having something on the other side - the public vertificates of various CAs, pre-installed with the operating system or browser. It can be used to check the signature of the transmitted public key, that a CA first made.

(Not really relevant for this question, but no one encrypts messages directly with RSA. Eg. because it is slow. Encrypting the messages with AES and then only the AES key with RSA is much more common, but this doesn't change the problem here).

Answer 3

You aren't wrong, in the narrow sense. The confidentiality and authenticity guarantees offered by asymmetric encryption presuppose that all parties have authentic copies of their counterparts' public keys. If an adversary impersonates your counterpart and fools you into accepting their own unauthentic key as the real deal, it all falls apart.

The advantage of asymmetric cryptography is that this authentication can happen over some channel that's visible to the whole public. Think of it this way: all cryptography requires that the participants use some sort of intermittent secure channel at some point to set up the cryptography for later. Pure symmetric cryptography require a confidential and authentic channel for the participants to establish the shared secret keys. Asymmetric cryptography improves on that because it only requires an authentic channel—you can authenticate your counterparts' public keys in plain sight of eavesdroppers.

Answer 4

Why you assert that it can not happen with RSA? Of course it can.

In case the public key is a fake. Suppose A requests public key of B. A refers target host by name. If DNS of A is compromized by attacker, A may get the IP of the compromized host, which provides you a fake certificate. The whole certificate chain can be compromized. A obtains a public key and believes this is a key of B, whereas actually it is a key of C. Then happens what you have described. C is in the middle and reads the whole traffic.

Read about Public Key Pinning. It is one of possible measures against man in the middle attacks in PKI, not limited to RSA.

Answer 5

Now, when A sends an encrypted message using what he thinks is B's public key (but is actually C's), C will intercept this message, decrypt it, then encrypt it again using B's actual public key.

Would this work? If not, why not? Is it just a matter of using a secure network to send the public key?

Yes, this "would work" in a sense. This is a well-known MITM attack on asymmetric key crypto. This technique is not only used by "bad guys." For example, this is exactly what certain vendors' network security appliances do in order to "inspect" encrypted network traffic and block "bad" traffic.

So, why did I put "would work" in quotes? Well, for example, if a bad MITM attacker substitutes his own certificate for a known HTTPS website's certificate, that certificate will most likely not have been signed by a trusted CA (unless the MITM could have somehow tricked the trusted CA into signing a certificate that stated that he was the known web site). In this case a web browser going to the HTTPS website that receives the MITM certificate will send up an alarm and tell the user not to proceed because the domain name either doesnt match or it does match but the certificate was not signed by a trusted CA.

Trusted CA certificates are embedded in your operating system when you purchase it. These are guys like Verisign, etc. You can view your trusted CA certs using operating system utilities. You could remove them if you like, but then all the websites you visit will show up without a nice green Lock symbol.

Answer 6

I think you missed the Certificate Authority's (CA) role in certificate creation/distribution.

The public key infrastructure concept has evolved to help address these problems and others. A public key infrastructure (PKI) consists of software and hardware elements that a trusted third party can use to establish the integrity and ownership of a public key.

The trusted party, called a certification authority (CA), typically accomplishes this by issuing signed (encrypted) binary certificates that affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate. The CA signs the certificate by using its private key. It issues the corresponding public key to all interested parties in a self-signed CA certificate. When a CA is used, the preceding example can be modified in the following manner:

1. Assume that the CA has issued a signed digital certificate that contains its public key. The CA self-signs this certificate by using the private key that corresponds to the public key in the certificate.
2. Alice and Bob agree to use the CA to verify their identities.
3. Alice requests a public key certificate from the CA.
4. The CA verifies her identity, computes a hash of the content that will make up her certificate, signs the hash by using the private key that corresponds to the public key in the published CA certificate, creates a new certificate by concatenating the certificate content and the signed hash, and makes the new certificate publicly available.
5. Bob retrieves the certificate, decrypts the signed hash by using the public key of the CA, computes a new hash of the certificate content, and compares the two hashes. If the hashes match, the signature is verified and Bob can assume that the public key in the certificate does indeed belong to Alice.
6. Bob uses Alice's verified public key to encrypt a message to her.
7. Alice uses her private key to decrypt the message from Bob.

In summary, the certificate signing process enables Bob to verify that the public key was not tampered with or corrupted during transit. Before issuing a certificate, the CA hashes the contents, signs (encrypts) the hash by using its own private key, and includes the encrypted hash in the issued certificate. Bob verifies the certificate contents by decrypting the hash with the CA public key, performing a separate hash of the certificate contents, and comparing the two hashes. If they match, Bob can be reasonably certain that the certificate and the public key it contains have not been altered.

Source: https://docs.microsoft.com/en-us/windows/desktop/seccertenroll/public-key-infrastructure