public key encryption, whats my mistake?

[Thorium]

I started developing a web application.
What gives me the most headaches is security. For example i don't get how public key encryption is secure if communicating data on a public network like the internet.

I think i get the concept:
-I have a private key and a public key.
-It's easy to get the public key from the private key but it's very hard to get the private key from the public key. So it's impractical to break the encryption by calculating the private key from the public key. That's fine, i get this.
-I send the public key to my communication partner. He encrypts a message with it and sends it to me. I decrypt it with my private key.
-He sends me his public key. I can encrypt messages with his public key and he can decrypt them with his private key.
-So no one can listen in on our conversation. Because no one can decrypt the messages send without having the private keys, which are never exposed.

But somewhere there must be a mistake in my thoughts, because a man in the middle attack would be very easy.
I am between partner A and partner B. I intercept the message containing the public key A sends to B and keep it. I send my own public key to B. So if B sends a message to A i get the message encrypted with my public key and can decrypt it with my private key. Then i encrypt it with the public key of A and send it to A.
For example my ISP could to this.

Where is my mistake?
It surely wouldn't be used if it would be so easy.

[Julian]

You are right, it is open to MITM attacks. Have someone else sign your key, like a signing authority does for SSL certificates.

PGP uses a web of trust, google it, plenty of info out there.

[freak]

Direct communication (like SSL) is usually not done with public/secret keys, but with an algorithm like Diffie-Hellman which allows both sides to agree on a secret key for encryption without anybody in between knowing it.

It basically works like this:
- both sides think of a secret
- both sides apply some math to the secret which is hard to reverse (exponentiation and modulo on large prime numbers)
- they exchange their secrets in this non-reversable form
- both sides add their own secret to what they received from the other. this way both sides reach the same result (containing both secrets) because the order of math operations does not matter

Wikipedia has a nice analogy for this using colors: http://en.wikipedia.org/wiki/Diffie%E2% ... escription

Even if an attacker intercepts all of the communication, he does not know the final key, because he only saw both secrets in their non-reversable form, from which the final key cannot easily be calculated without knowing at least one of the original secrets.

After this key exchange is complete, both sides encrypt their data with that key an exchange it.

Public/Private keys are used in such communication only to establish trust between both parties (so both know they are talking to the right person). This requires that the public keys (in the form of certificates) are exchanged beforehand, or issued by an authority that both sides trust.

[Thorium]

Thanks freak. Now it makes sense.

[Thorium]

Direct communication (like SSL) is usually not done with public/secret keys, but with an algorithm like Diffie-Hellman which allows both sides to agree on a secret key for encryption without anybody in between knowing it.

I thought a little bit about it and it does not provide security against a man in the middle attack. The very same attack described in my first post can be applied to Diffie-Hellman key exchange as well.

I have read a little bit about certificates but they seem to be very complicated. But in the end if i can't trust a public channel i dont see how i can trust a certificate.

[Little John]

But in the end if i can't trust a public channel i dont see how i can trust a certificate.

As far as I can see, for getting a safe certificate a safe "channel" is needed.
For instance you can personally visit a company that is accepted as authority in this field, and you prove that you are actually the person that you claim to be by showing them your identity card.

[freak]

Direct communication (like SSL) is usually not done with public/secret keys, but with an algorithm like Diffie-Hellman which allows both sides to agree on a secret key for encryption without anybody in between knowing it.

I thought a little bit about it and it does not provide security against a man in the middle attack. The very same attack described in my first post can be applied to Diffie-Hellman key exchange as well.

Yes, this is true. You need something like certificates to prevent the man in the middle attack. There are key exchange protocols (such as STS http://en.wikipedia.org/wiki/Station-to ... n_protocol) which are build around the Diffie-Hellman algorithm which combine the key exchange with certificate signing so in the end both sides can be sure who the other is and they have a common key for the following communication.

Certificates work like public-key encryption in reverse:
- the private part of the certificate is a key to encrypt things
- the public part is a key to decrypt
- to prove his identity, the person with the private part can generate some random bytes and encrypt them. Then he sends the encrypted bytes + a secure hash of the original bytes
- the receiver (everybody who has the public part) can decrypt the bytes, calculate the hash and verify that the information came from somebody who had the secret key

Now, on its own such a simplified certificate check like above once again has the man in the middle problem because the attacker can just pass along the certificate check data and claim them as his own. It has to be combined with something like Diffie-Hellman in the proper way (like in the STS mentioned above) to ensure that this is not possible.

This is why real encryption protocols are so complicated. A single algorithm is not enough to provide security. Multiple methods have to be combined in a very carefully selected sequence of steps to ensure that it remains secure if somebody in the middle (or even the sender or receiver) have hostile intentions.

For certificates to work, you have to know the public part in advance to be sure. This is what the "known_hosts" file with SSH is for. It is a list of public keys for the servers you have logged in to. If you log in again and the server answers with a different certificate, you get a message about a potential attack. This may indicate that there is a man in the middle attack going on.

With websites this approach does not work, because you can't get the key in advance for every website you want to visit. This is why it works like this here:
- the certificate of the website is created and signed by a registered certificate authority (CA)
- the certificate also contains the host name of the website
- every browser has a list of such CA certificates which he trusts
- the browser now checks that the certificate comes from a CA he trusts, and that the host matches. Then he trusts the website

This is a weaker check than knowing the actual certificate of the website in advance, but it is not bad, because an attacker would have to get (buy) a certificate from a CA with the hostname of the existing website and that should raise a red flag at the CAs if they do their job right.