User Key pairs and Man-in-the-middle issues

Question

I'm trying to wrap my head around how to exchange user's keys with a server.

Maybe during sign-up a JS applet generates a key-pair for the user. These keys would be used for signing subsequent requests from the user to the server, so the server needs a copy of the users' public key to associate with that user's account.

But sending the public key to the server is subject to MITM attacks - if a sufficiently motivated bad guy wanted to he could put himself in the middle, capture the public key on its way to the server and substitute with a key for which he controls the secret key.

Part of the solution seems to be to have the agent submit the public key only via an encrypted channel, eg TLS. But it seems that with browser based applications, the onus is still very much on the user to be both educated and awake enough to realize when their session is not with the right server that he aught to be connected to. In particular our motivated bad guy could set up something that appears authentic and credible, eg

httpS://certificate_server_acme.com

which he would be in control of. Our user may not realize he SHOULD be connecting only to, eg, httpS://certificates.acme.com

I suspect that this is just a case of "self-signed certificates". Passwords doesn't solve the issue. Verifying a user's key by means of an email message is not viable unless users can compare and verify a key and our motivated bad guy cannot tamper with email messages on the way to the user.

Or is there something, maybe a feature of OpenID, that can be used?

Answer 1

There is already an infrastructure to manage trust and it's called "Public Key Infrastructure". This is the basis of all the SSL/TLS protocols used over the internet and websites.

The main idea is to designate a Trusted Third Party (TTP) which is recognised by all the parties involved. These TTP issues their public key and they are shipped by default in all major browsers (we have to assume there is no tampering before this point, or the all thing fails). Once you have that public key that you trust with no doubt, any server can ask the TTP (which is called a Certificate Authority) to deliver them a certificate. The certificate includes a public key and the identity of the certificate requester and the certificate issuer. When the CA verified the identity of the requester, the certificate is signed by the private key of the CA.

Anyone who gets this signed certificate can verify the CA signature. If it's ok, you deduce that the certificate (therefore the public key) belongs to the entity mentioned in the certificate. You can then use it to encrypt message to this person without fear of it being intercepted by someone else.

If someone where to make a MitM attack on the system he would need to :

• get a forged certificate for a domain name he does not own
• get the victim to accept a new/fake CA certificate on which he has control (and then generate forged certificate)
• break the public key (very unlikely)

Otherwise, the certificate signature would not be verified and therefore the authenticity of the public key would not be proven.