3
$\begingroup$

I am trying to design MiTM protected key exchange algorithm. For instance I am using RSA asymmetric keys.

Alice and Bob respectively have each their own pair of keys. And they should be able to exchange public keys. In real life implementation there would be a relay 3rd party which should only allow Alice and Bob exchange messages in case if there is no way for direct connection. However this relay party can be compromised by Eve where she would have her own pair of keys, accept Alices And Bobs public keys during the exchange and send out hers instead. Therefore all encrypted messages will be decrypted, read, encrypted again and sent further by Eve compromising the whole key exchange process.

Apparently there can be Trent that could sign the key before it is sent to the recipient and later after it has been received could verify the signature. However I feel that this schema also has a flaw as Eve could somehow obtain public key signed by Trent.

Is there a way to make sure that if Trent is not compromised (means that it is not someone disguised as Trent) we can make sure that keys are exchanged securely?

What comes to mind is that any party can have information about Trent (certificate, public key or something similar) using which they can make sure they communicate with Trent, whereas Trent would confirm to each party from whom they received the key. Does this schema has a flaw or any issues that I haven't noticed?

Improve this question
$\endgroup$
3
  • $\begingroup$ Is this relevant? vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html $\endgroup$
    – GalacticJello
    Commented Sep 5, 2013 at 4:06
  • $\begingroup$ @GalacticJello Hardly. Things described there are pretty much basic theory which I know already. The case I am talking about is not when Eve listens to messages between Alice and Bob, but when Eve replaces their messages with her own, therefore simple exchange of asymmetric keys or DH will not work because each side (Alice and Bob) will think that their message received by another (Bob or Alice respectively), but in fact all messages are received by Eve and replaced with her desired messages. Therefore whole DH isn't working here and there should be some other way around this issue. $\endgroup$
    – Alexey Kamenskiy
    Commented Sep 5, 2013 at 4:48
  • $\begingroup$ I was hoping that the part where the authentication happens before the key exchange would be relevant. How about this? Provably-Secure Authenticated Group Diffie-Hellman Key Exchange $\endgroup$
    – GalacticJello
    Commented Sep 5, 2013 at 15:29

1 Answer 1

Reset to default
1
$\begingroup$

You are right that the session public keys can be replaced if they are not signed by long term private key known to all parties.

What you want to do is not have Trent do anything but be a relay, then you need a standard key exchange process between the two parties using new random key pairs. Then once all parties have both public keys, they can generate an authentication hash of the key pairs as well as the prime/exponent and any other common data. After the key exchange completes and the session key is generated, you would need some way to compare them, even if it is an insecure channel, as long as that comparison cannot be modified.

Several programs use this method or one like it. I use one over IRC, with the IRC server taking the place of Trent. The obvious alternative is known long term keys that are only used for signing the session public keys.

Improve this answer
$\endgroup$
3
  • $\begingroup$ long term keys can be asymmetric for signing or symmetric for authentication, to be a little more clear. Digital signature functionality may not be available, but an authentication routine using block ciphers or hash algorithms can be built easily $\endgroup$
    – Richie Frame
    Commented Sep 4, 2013 at 8:25
  • $\begingroup$ Could you maybe go a little bit more into details of such an exchange? I am quite new to cryptography with more of exact implementation experience rather than theory. In my understanding when we talk about trusted Trent that means we supply to each party digital entity capable of proving identity of Trent (public key, certificate or similar). If we have it, then Trent can act as trusted 3rd party signing Bobs public key before it is sent to Alice where as signature should be a prove of who is the sender, thus if there is MiTM then the key can't be replaced. $\endgroup$
    – Alexey Kamenskiy
    Commented Sep 4, 2013 at 8:45
  • $\begingroup$ The channel between Trent and the other parties can also be intercepted or tapped, therefore signing and authentication should occur before the data reaches the network adapter. If you are able to prove to Trent your identity, you should be able to do so to the other party. Trent can always be replaced. $\endgroup$
    – Richie Frame
    Commented Sep 4, 2013 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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