4
$\begingroup$

Can the channel keys that are derived from an AKE (authenticated key exchange) protocol be used in a secure channel that wants to have perfect forward secrecy?

If the goal of AKE is to establish channel keys and provide authentication of the entities at the same time, then this implies that the long term key used for authentication is contributing to the shared channel key.

But if we want PFS, then the long term key should not be contributing to the channel key.

Meaning that if we want PFS you can not rely on AKE, but you should use a key establishment protocol that does not provide authentication and just authenticate the transcript afterwards.

So my question is: if we say that we use AKE to create our channel keys, does that mean that by definition of AKE we can no longer claim PFS of our secure channel?

$\endgroup$
  • 2
    $\begingroup$ 'the long term key should not be contributing to the channel key'; isn't the actual requirement 'with knowledge of the long term key, but not the ephemeral state, you cannot rederive the channel key'? That is, there's not a problem with the long term key being part of the mix (but it can't be the only non-public data) $\endgroup$ – poncho Apr 30 '17 at 19:12
5
$\begingroup$

In fact, if you use the first described password authenticated key exchange protocol (Encrypted Key Exchange, by Bellovin and Merrit, in 1992), it is quite clear that you get forward secrecy for free. Roughly put, this is a Diffie-Hellman key exchange with ephemeral keys, whose messages are then symmetrically encrypted, using the shared secret (the password) as key (this symmetric encryption must be such that decrypting with the wrong password still yields syntactically valid DH public keys). Even if an attacker learns the password, all he can do is to recover the inner DH exchange, that used ephemeral keys.

This is in fact a general property for all PAKE. The point of a PAKE is that both parties have only one long-term secret (the password), so everything else is ephemeral; moreover, since that secret has low entropy and is thus in range of exhaustive search (a "dictionary attack"), a strong PAKE must be such that whenever the attacker tries a potential password, he can never know whether he got the right one. This implies, in particular, that even if the password is revealed after the fact, the key exchange itself must remain impregnable. That password being the only non-ephemeral secret, the property of forward secrecy follows.

Or, said in the other direction: if a PAKE protocol is not forward-secure, and obtaining a copy of the shared password allows unraveling the subsequent data encryption, then that mechanism can be used to "test" passwords (run the break-the-encryption attack for each potential password, see if that yields a key which makes sense); in that case, the PAKE protocol does not fulfill its PAKE properties.

To sum up: contrary to what you fear, you will get forward secrecy because you use a PAKE protocol.

(Of course either party can still do something stupid and, for instance, save the secret key resulting from the PAKE into a file, which then breaks forward secrecy.)

$\endgroup$
  • $\begingroup$ Thank you. So would you say that protocols whom use some scheme to derive a channel key and sign the transcript with a long term shared secret are not AKE? Because the authentication part does not come from the key establishment part itself. $\endgroup$ – Lee. M May 1 '17 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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