3
$\begingroup$

At the moment I'm designing a crytosystem for a VPN server. One of the requirements is Perfect Forward Secrecy, but I'n not sure how to implement authentication on the ephemeral key exchange.

If both parties possess a signed public key (signed by a CA or common trusted party) and exchange this, they can verify the identity of each other through the CA's public key. To implement perfect forward secrecy, both parties have to generate an ephemeral keypair and send each other the public key. Since these keys are not signed, how can one authenticate the other to guarantee that the keys were not altered/switched? Even if the keys are exchanged over an verified channel (for example using the signed and trusted public keys) that doesn't automatically ensure the ephemeral keys were generated by the same party. Also calculating a MAC over the public ephemeral key does not lead to a secure cryptoscheme since the public key could have been created by an man-in-the-middle in the first place. Is there any way the ephemeral key exchange can be authenticated?

Improve this question
$\endgroup$

3 Answers 3

Reset to default
2
$\begingroup$

Since these keys are not signed, how can one authenticate the other to guarantee that the keys were not altered/switched?

They have to be signed. By the key-exchanging parties, using their long term keys.

Even if the keys are exchanged over an verified channel (for example using the signed and trusted public keys) that doesn't automatically ensure the ephemeral keys were generated by the same party.

The keys are guaranteed to be generated by the signing party unless: 1) they are not following the protocol but signing someone else's key (you have to assume this is not the case) or 2) the long term keys have already been compromised (which is why it's called forward secrecy).

Also calculating a MAC over the public ephemeral key does not lead to a secure cryptoscheme since the public key could have been created by an man-in-the-middle in the first place.

A MAC would work, if you could exchange the key for that securely. E.g. if the long term keys are for authenticated encryption (rather than just signatures) you could generate an ephemeral MAC key to authenticate the exchange of the ephemeral public keys. A man-in-the-middle who does not know the MAC key could not forge the MAC value for their own public key in this case.

That is unnecessarily complex, however, since you might as well use the authenticated encryption directly to exchange the ephemeral public keys.

Improve this answer
$\endgroup$
2
  • $\begingroup$ This relates directly to the situation I'm in and does answer the question quite well. The MAC isn't necessary but I do have keys that are used for authenticated encryption (Curve25519-Poly1305-ChaCha20). When the long term keys are compromised, the confidentiality of the entire cryptosystem falls apart and however the messages are still encrypted, a new ephemeral keypair cannot be securely authenticated whatsoever. $\endgroup$
    – Yorick de Wid
    Sep 12, 2015 at 19:52
  • $\begingroup$ @YorickdeWid, correct. Your best option is to generate ephemeral key-pairs and exchange the public keys using the long term keys. (Take care to prevent replay attacks!) If the long term keys are compromised there's nothing you can do. $\endgroup$
    – otus
    Sep 12, 2015 at 20:11
4
$\begingroup$

I think you're confusing some things here.

The usual TLS-handshake with ECDHE (which you really should use, unless you have very good reasons) has two public keys. One of them is signed by the CA, the other one is generated on-the-fly.

And before proceeding, please note: (Perfect) Forward secrecy (PFS, not security usually) only means that you don't compromise secrecy of future sessions if a long-term key is leaked, meaning PFS won't protect you against man-in-the-middle attacks if your long-term key is compromised, but very well against passive eavesdroppers.

So the usual key-exchange protocol makes use of the Diffie-Hellman protocol to let both parties agree on a common secret. The values exchanged for this sub-protocol are called public keys and if not authenticated may be subject to a man-in-the-middle attack, but the use of DH prevents passive eavesdropping, thereby yieldin the requested forward secrecy. Those public keys are also completely random (not a random bitstring though).

Now to prevent man-in-the-middle attacks each party signs their DH public keys using the key corresponding to the one in their valid CA signed certificate. If this key is leaked, the contents of future communication are not leaked unless the attacker uses a MitM attack, so PFS is preserved and MitM are prevented if the signature key is not compromised.

TL;DR: There are two public keys, one is long-term and one is short-term, the long-term one is CA authenticated and authenticates the short-term one thereby preventing MitM attacks and the short-term one yields the desired PFS property.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you for your answer, but how is this any different than what I describe? I do use two keypairs, and I know they serve different purposes, but the question really is how to establish an authenticated PFS connection. The VPN protocol doesn't rely on TLS/SSL, but uses a custom tunnel. Both parties can indeed sign the key with there own signed key, which is exactly what I'll do. Thank you $\endgroup$
    – Yorick de Wid
    Sep 12, 2015 at 12:40
  • 1
    $\begingroup$ @YorickdeWid, you should really use TLS or something other trusted and standardized (IPSec?) if possible. If you want examples, you can look at STS or TLS, they both achieve PFS. $\endgroup$
    – SEJPM
    Sep 12, 2015 at 13:18
1
$\begingroup$

Yes there is. You have a lot of possibilities.

You can check different protocols: Station to Station, NAXOS, KEA and KEA+, ...

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ STS is what I was thinking of when I read the title $\endgroup$
    – Richie Frame
    Sep 11, 2015 at 19:18

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.