1

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?

|improve this question|||||
2

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.

|improve this answer|||||
  • What about personal certificates / Key pairs? – Johan Mar 20 '15 at 12:51
  • Well, as I say, you have to decide on a common Trusted (Third) Party from which you can reliably get a public key. If you can have this (whether it's an official CA, or your own) you can make the PKI works. Otherwise, you will have problem with MitM attacks. – M'vy Mar 20 '15 at 13:00
  • The problem remains. If the server trusts only some PKI, then that becomes a limiting factor for user adoption. I should have explained that this is for an "open to the public" situation, not in-house corporate where the users and their personal keys can be enforced to a specific PKI service. – Johan Mar 20 '15 at 13:06
  • This is not a limiting factor. In the case of HTTPS, a website trusts a single CA, while client browsers trust multiple CAs (as you can see if you take time to explore the list of root certificate on your machine). As a server/website, you just have to choose to trust a CA that is already in that list of client-trusted-CAs. Of course if you are running your own CA, you have to make the clients accept it as trusted. – M'vy Mar 20 '15 at 13:16
  • Either there is something huge that I am not aware of (Eg users can with zero or near zero interaction obtain a personal certificate from a CA), or you don't understand my issue. – Johan Mar 20 '15 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.