5
$\begingroup$

See here for the man-in-the-middle attack on Diffie-Hellman that I'm concerned about: What is Diffie-Hellman?

How do we combat this? I have two questions:

  1. Is one solution for both Alice and Bob just using a certificate authority, then they can each look up the other's certificate and know the secret key without really communicating (through Eve)?

  2. The other solution I heard about is using RSA for signatures. My question in this case is that, if Alice and Bob are using RSA, why doesn't Alice just send Bob a secret symmetric key using Bob's public RSA key (signed with her private RSA key)? Isn't this basically what PGP does? I don't see the point in using DH if we're using RSA anyway.

Improve this question
$\endgroup$
4
  • $\begingroup$ possible duplicate of Diffie-Hellman Key Exchange with Authentication: Man-in-the-Middle query $\endgroup$
    – T.B
    Commented Sep 19, 2014 at 8:32
  • $\begingroup$ I saw that. I think my questions are different. $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 8:37
  • 1
    $\begingroup$ If you have a public key infrastructure or know the other party's public information (encryption key, verification key, etc.), you can do authenticated key exchange. If you don't, you have no idea how to distinguish a real key exchange from Alice or a MitM attempt by Eve. The other question might look different, but it is essentially the same. $\endgroup$
    – tylo
    Commented Sep 19, 2014 at 8:44
  • $\begingroup$ Possible duplicate of crypto.stackexchange.com/questions/31291/… $\endgroup$
    – Nayuki
    Commented Apr 2, 2018 at 1:16

4 Answers 4

Reset to default
3
$\begingroup$

Well, as it says in your link the problem is authentication. So somehow Alice and Bob must set up an authenticated channel. One way of implementing such a channel is by Alice and Bob holding each others public verification key for a signature scheme.

  1. A CA would probably not hold a secret key for Alice and Bob. However, using a CA to get an authentic copy of the other parties public key for a signature scheme that would allow to set up an authenticated channel between Alice and Bob, so they could do DH key exchange. Apart from not trusting the CA with secret information, this has the benefit that Alice and Bob can now generate many secret keys with out involving the CA.

  2. It is true that if Alice has a public encryption key for Bob and Bob has a public signature verification key for Alice, they could use the protocol you describe. However in general public key encryption and signature schemes are not the same(although for the particular instance of RSA there may be some overlap). If Alice and Bob only have keys set up for a signature scheme, they could use DH exchange to get a secret key.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Thanks for your answer. With regards to 1), is this superior to my suggestion purely because you get a fresh session key each time (whereas, in my suggestion, the DH symmetric key would be the same each time)? With regards to 2), again, using DH anew each time is better than my suggestion purely for forward secrecy and, like you say, perhaps it's faster to use a special signature scheme rather than RSA? Basically, is it that everything comes down to using a CA for signatures? $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 12:24
  • $\begingroup$ 1) It is superior because you could generate as many session keys you like without involving the CA more than once (to get the certificate). It is also superior because the CA would not know any of your session keys. 2) I never mentioned performance, or forward security (both may be a factor but I haven't though about it). You could probably use your suggestion. What I'm saying is that in general you only need a signature scheme and DH key exchange. Your suggestion uses both public key encryption and public key signatures. In a sense you are using more than you generally need. $\endgroup$
    – Guut Boy
    Commented Sep 19, 2014 at 13:05
  • $\begingroup$ I see. Thanks for your help. Is the reason you don't encrypt the public key in the DH key exchange mainly speed? $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 15:51
  • $\begingroup$ I am sorry, I dont think I understand the question. Which public key are we talking about now? There is no public key directly involved in DH key exchange. $\endgroup$
    – Guut Boy
    Commented Sep 19, 2014 at 16:06
  • $\begingroup$ @GuutBoy: actually, while we don't typically call the values $g^a$ and $g^b$ exchanged in the DH key exchange "public keys", it doesn't do violence to the language to call them that, and in fact they are on occasion referred to as public keys. They do share the attributes that we normally expect from "public keys". $\endgroup$
    – poncho
    Commented Sep 19, 2014 at 17:42
3
$\begingroup$

The problem about Man-in-the-Middle attack on Diffie-Hellman is that both sides are not confident about other side's public key (g^a and g^b). If they were sure that they have correct public key of their's friend Man-in-the-Middle attack wouldn't be possible, because MITM attack is based on the forgery of public keys by adversary! If for instance Bob and Alice meet at home each other and exchange theirs keys using a USB flash they will be certain that they have each others public keys not the adversary's (except for the rare case if the adversary has set up a special trojan on their's flash card or computer to copy wrong (forged) public key).

So the task is to securely (with total confidence) obtain each others public key. There are many solutions for that. First descibed above is exchange in private presence of each other without using public networks. Second is to provide public keys certificates signed by common trusted third party (which confirms that public keys belong to Alice and Bob), but third party CA (certificate authority) is not very reliable because they may suffer from Man-in-the-Middle attack when some adversary intercepts all traffic between certificate receiver and CA injecting forged public keys... Third possibility is to use some shared secret and exchange public keys encrypted and MACed (MAC is a kind of signature showing that the data wasn't modified and was encrypted by shared symmetric key), and decrypt shared key and check MAC on the other side. Fourth possibility is to use asymmetric shared secret, e.g. if they are confident about other public key e.g. RSA then they can sign (in RSA it means encryption) DH public key using RSA private key and send it to each other and verify RSA signature using RSA public key of each other. Fifth solution is to establish web of trust using e.g. PGP. Sixth is to use some well-known website to share public keys, e.g. put public keys on FaceBook's user's page (this solution expects that FaceBook is hard to break and an adversary can't inject forged public key on user's page). Using several solutions to exchange public key increases confidence about the key.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks for your answer. Alice and Bob meeting up in person to exchange their public keys make sense but why would they ever do that when, if they're meeting up in person, they may as well exchange a one-time pad? Also, is man-in-the-middle-attack for Alice and a CA ever stoppable? That's surely a fundamental problem in cryptography I guess? (Basically if Eve is so omiscent that she can intercept and change all communication Alice ever does, then Alice is screwed)? Same with web of trust, right? $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 12:29
  • $\begingroup$ And the other solutions you suggest about having a pre-shared secret or other public certificate obviously suffer from an infinite regression kind of problem, don't they? (You need a shared secret to agree on the shared secret to agree on the shared secret, etc)? Are you saying, that, somehow, you need to a leap of faith and you need to trust something (eg Facebook, CA, web of trust, or whatever)? $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 12:30
  • $\begingroup$ @Luke, If Alice and Bob meet in private they can exchange any shared secret for any reliable protocol to be used in future for data exchange. They can exchange assymetric pub keys in a case if they can't really meet in private, but e.g. they can phone each other and recognize voice and tell by voice theirs public keys or some pub keys small checksums to proof ownership. MITM attack for CA is stoppable if CA and certificate requester are authenticated for each other through shared secret, best would be for certificate requester to visit CA's office and show passport and exchange public keys. $\endgroup$
    – Arty
    Commented Sep 19, 2014 at 13:09
  • $\begingroup$ Web of trust prooves ownership with some probability only - the more persons tell Alice that Bob has a given public key the more Alice is confident, and whom you trust more contribute more to the score of Bob's public key, sot its probabilistic. The more channels Alice involves to get Bob's public key more Alice is confident about his key, thus protecting from Eve's tampering. About second shared key encrypted or signed by already shared key is not suffering from regression, because you do it very rarely, maybe once in a year, just to change crypto protocol, not for every day or message. $\endgroup$
    – Arty
    Commented Sep 19, 2014 at 13:19
  • $\begingroup$ @Luke, regarding a leap of faith is true! You should trust computer (which may have some trojan/virus stealing keys or tampering data), you should trust encryption algorithms that were not created by you (e.g. AES symmetric cipher may have some special attacks not exposed to public e.g. using quantum computers) (e.g. RSA, DH might be broken for long time if somebody has invented fast discrete logarithming or number factorization algorithm, certainly they won't share it to public to have profit).Also Eve might have stolen Bob's private key thus can decrypt all messages without exposing herself. $\endgroup$
    – Arty
    Commented Sep 19, 2014 at 13:28
2
$\begingroup$

The question Alex linked in comments explains why authentication works to prevent a man-in-the-middle attack on Diffie–Hellman. So, whenever you can do the key exchange in an authenticated channel, you can be sure there is no MitM attack. (Assuming DH problem remains unbroken, of course.)

Now, your questions:

  1. Is one solution for both Alice and Bob just using a certificate authority, then they can each look up the other's certificate and know the secret key without really communicating (through Eve)?

If they look up each others' Diffie–Hellman public keys in a CA and can trust that CA, then yes, they have a secure shared secret. However, in practice it is nice to use ephemeral Diffie–Hellman keys for perfect forward secrecy, and this is not possible with a static CA. Also, this ties the symmetric key lifetime to the certificates': e.g. AES requires relatively frequent rekeying in many modes, while you would often like to have any CA keys be rather long term.

  1. The other solution I heard about is using RSA for signatures. My question in this case is that, if Alice and Bob are using RSA, why doesn't Alice just send Bob a secret symmetric key using Bob's public RSA key (signed with her private RSA key)? Isn't this basically what PGP does? I don't see the point in using DH if we're using RSA anyway.

Here, again, using an authenticated Diffie–Hellman key exchange allows ephemeral keys and thus forward secrecy. Further, your idea of sending an encrypted key over allows an attacker who knows only Bob's private key to eavesdrop on the whole protocol. In comparison, with authenticated Diffie–Hellman, you need to know both users' private authentication keys to even set up a successful man-in-the-middle attack.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Many thanks for your answer. Could both of my questions be asked about pretty much any key exchange protocol? There’s nothing unique about DH here is there, really? Basically my questions boil down to: ‘how can you trust it’s really their public key?’ So basically, is the system this: Alice looks up Bob’s RSA/DSA public key in a CA. Bob does the same for Alice. They proceed with DH anew because this provides perfect forward secrecy? $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 12:20
  • $\begingroup$ @Luke, I think you could ask similar questions about other key exchange protocols. That's the gist of it, yes, exchanging ephemeral keys gets you forward secrecy, while some sort of authentication is always required. If there's no CA you can authenticate in person or via web of trust etc. $\endgroup$
    – otus
    Commented Sep 19, 2014 at 15:31
  • $\begingroup$ Thanks! One additional question if I may: When we do Diffie-Hellman with (say) RSA authentication, do we typically not also use RSA encryption when we exchange the public keys of DH? Is this just because of speed? If not, I can't see how it will hurt to encrypt the public keys anyway, even though obviously it shouldn't matter if the DLP is infeasible anyway $\endgroup$
    – Luke
    Commented Sep 19, 2014 at 15:44
  • $\begingroup$ @Luke, I believe at least TLS only uses the RSA keys for authentication in DHE_RSA. It shouldn't hurt to encrypt, but every extra operation you do adds to risk of bugs. $\endgroup$
    – otus
    Commented Sep 19, 2014 at 16:20
0
$\begingroup$

I would also mention that there are many required properties that you want a authenticated key exchange (AKE) protocol to satisfy, e.g. authentication, key confirmation, forward secrecy, key freshness, secrecy on the session key.

What you want is allow Alice and Bob to stablish "session keys" for each session of communication. These session keys are established on some secret which has to be shared befor the protocol starts, i.e. long term symmetric keys or long term public keys.

Why do you want session keys to be established rather than using the long term keys for communication? One could say: 1. You want each session to be encrypted with a different key, 2. If you encrypt several sessions with the same key, it is subject to cryptoanalysis (for example, in cases of password based authentication where the entropy of the keys is relatively low), 3. You want to ensure that if some session key is revealed, it does not compromise previous communications. 4. Also, as here in the forum, AES requires fresh keys when establishment of communications.

Going back to your question, I would suggest that look at the properties I mentioned above and see if your solution satisfies them (Which I would say, your solution does not satisfy). This explain why there is a huge research going around Key exchange protocols and why the naive solution is not the best. Hope this helps.

There is a very good book for key exchange protocols, called "Protocols for Authentication and Key Establishment", by Colin Boyd. Just in case you are interested on the topic :)

Improve this answer
$\endgroup$

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.