Prevent server MITM attack

Question

I want to create a secure messaging application such that you don't have to trust the server.

1. Register with username and password. ->
2. Generate a pair of PGP keys (RSA). ->
3. Encrypt the private key with the password. ->
4. Hash the password

This is what the server knows:

• username
• pubKey
• AES/CBC(SHA256(pass), privKey)
• SHA256(SHA256(pass))

I double hash the password so that the server can't use it to decrypt the privKey.

This works: after the login the user receives his private key and unread messages, he can query the server for somebody's public key and send them a message.

However, the server could generate a PGP pair and send his public key to Bob instead of Alice's when Bob wants to send a message to her. Decrypt the message and then encrypt it with Alice's actual public key and then send it to her.

How can I prevent this?

Answer 1

Your question boils down to the subject of authentication. In other words, how can Bob authenticate that the public key that he has received for Alice through the untrusted network does in fact belong to Alice, and is not the public key of a Man in the Middle (MITM) attacker? This question has vexed security researchers since the advent of public key cryptography, and this question crops up whenever a public key must be sent from one party to another through an untrusted network or untrusted server.

There are several solutions to this problem, but none of them are perfect:

1. Public Key Infrastructure (PKI). This is the model used on the world wide web. We rely on trusted certificate authorities (CA's) to authenticate the certificates (which contain public keys) of web servers on the web.

2. Web of Trust (WoT). David has authenticated Alice's public key. Carol trusts David, and Bob trusts Carol. So, Bob figures that the public key for Alice that he has received from Carol, who received it from David, must be authentic. PGP relies on a Web of Trust model.

3. Trust on First Use (TOFU). When Bob contacts Alice for the first time, he stores Alice's public key. Then, on each subsequent connection, he checks that the public key that he sees for Alice matches the one that he has stored for her. This method is also sometimes referred to as 'public key pinning'. SSH relies on this model.

4. Out of band verification. Bob receives Alice's public key through the untrusted network, then Bob calls Alice (or texts her, or faxes her, or sends a telegram to her, etc.) to verify that the public key that he has received for her is authentic. Signal has come up with a clever way of simplifying this process, using 'safety numbers' (see Signal protocol implementations: pub key authentication and inspectability? (Allo, WhatsApp, FB messenger, Signal) for more info).