1

I am using Botan utility to perform encryption. When I initialize my connection to a remote machine using SSH, I am able to trade keys over the secure SSH connection. However, sometimes I use inetd to establish the connection, and in this case, there is no security on the inetd connection, but I need to use it to trade keys with the remote machine.

I imagine there is some standard for this whereby I send a public key over an insecure channel and the remote end uses this to encrypt a key to send back to me over the insecure channel, which I can then decrypt to get the key.

What would be an example of this kind of protocol that Botan supports?

WilliamKF
  • 41,123
  • 68
  • 193
  • 295
  • 1
    You need to do key exchange, Diffie-Hellman or public key or something. Found this: http://files.randombit.net/botan/tutorial.pdf key pair generation is on page 12. – AndreKR Nov 21 '10 at 17:22
  • 1
    The problem here is classical MITM: in the initial transmission, the remote side has no way to verify whether the key it received is yours or belongs to an attacker. If the remote side decides to trust it, they may have given trust to the attacker's key, who can then intercept their response and substitute their own. As the channel is insecure, there is no way to verify if this has taken place or not, using only this channel. – Piskvor left the building Nov 21 '10 at 17:23
  • 2
    @AndreKR: you need to establish some sort of trust beforehand (or through a trusted channel), otherwise all you're establishing is that you're communicating with the same remote endpoint on subsequent attempts - but DH *kex* doesn't give you any guarantees about the other side, just allows to exchange keys securely. – Piskvor left the building Nov 21 '10 at 17:27

2 Answers2

4

Without previous trust, or communication through a side channel, there's no way to do that. Diffie-Hellman kex allows you to establish a channel secure against others who don't participate in the connection, but you cannot verify that you're communicating with the intended recipient.

Classic MITM example: you connect to some remote endpoint, it receives your public key and sends you something signed with that key. However, you have no way to verify whether you've sent your key to the real destination, or whether the response comes from an attacker - therefore, you have a secure tunnel, but you have no information with whom you're securely communicating (the attacker may even connect to your intended destination and proxy the traffic, which passes over him unencrypted).

To be sure that you are indeed communicating with the intended endpoint, you need to exchange some sort of identification of the host beforehand or through a secure channel. SSH does this using the "fingerprints" - it asks you on first connection if you trust that host, and you're supposed to verify the fingerprint through an independent channel.

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
2

What I did in a similar situation was to first arrange to get a private/public key pair exchanged, so, I had the public key of each client, so when they connected to me, a message was passed, that had a timestamp on it, that I could then decrypt.

If that passed, and the timestamp was valid (I used 5 seconds as the life of the timestamp) then I would exchange the key, since we had a way to securely communicate.

But, this required doing something upfront.

If you expect an anonymous user to connect and have some security that is impossible.

One article I found very helpful on issues like this was *Programming Satan's Computer", http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf, where you are trying to have a secure communication with an untrustworthy sysadmin.

James Black
  • 41,583
  • 10
  • 86
  • 166