2

Other considerations aside, is it possible to use DH with an established public key (together with fixed g, p, q) to safely authenticate a server instead of using some signing algorithm?

In other words, we will replace $SIG_S(Data)$ in some protocol with this scheme. The steps described below can be merged with whatever protocol is used, so it doesn't need to add more steps.

Client $C$ knows $g$, $p$, $q$ and $g^s$.

  1. $C \rightarrow S : \{ g^c \} $
  2. Server generates a random value $N_S$.
  3. $K \leftarrow KDF(N_S, g^{cs})$
  4. $S \rightarrow C : \{ N_S, HMAC_K(Data) \}$ where $Data$ is the relevant data signed in the protocol we're modifying.
  5. $C$ constructs $K$ and verifies that the HMAC calculation matches.

Assume that none of $K$, $N_S$, $g^s$ or $g^c$ is ever recycled for any other use (such as key generation).

What I wonder is if this would be an acceptable replacement for signing with DSA/RSA/etc to prove identity in this particular setup.

Examples:

Plain STS with server authentication only

  1. $C \rightarrow S: \{ g^x$ }
  2. $S \rightarrow C: \{ g^y, S, \{ SIG_S(g^x, g^y) \}_{K_s} \}$

Plain STS modified

  1. $C \rightarrow S: \{ g^x, g^c \}$
  2. $S \rightarrow C: \{ g^y, S, \{ N_S, HMAC_K(g^x, g^y) \}_{K_s} \}$

Plain SIGMA with server authentication only

  1. $C \rightarrow S: \{ g^x$ }
  2. $S \rightarrow C: \{ g^y, S, SIG_S(g^x, g^y), MAC_{K_m}(S) \}$

Plain SIGMA modified

  1. $C \rightarrow S: \{ g^x, g^c \}$
  2. $S \rightarrow C: \{ g^y, S, N_S, HMAC_K(g^x, g^y), MAC_{K_m}(S) \}$
Nuoji
  • 803
  • 1
  • 7
  • 21
  • Client $C$ is different from the $C$ in $g^C$, correct? – mikeazo Jul 01 '13 at 20:12
  • Do you mean $:HMAC_K(N_S-1):$? $;;$ –  Jul 01 '13 at 20:16
  • Even if that is the case, the OP's idea runs into very important subtleties, such as facing an analogue of CCA2 attacks as described in my answer, and revealing an HMAC value, which means that $N_S$ must be chosen so that it will never be HMACed in any other context. $:$ –  Jul 01 '13 at 20:17
  • @mikeazo Yes. That was clumsy of me. – Nuoji Jul 01 '13 at 20:25
  • @RickyDemer I've read that answer (regarding the CCA2 attack) but I'm still not sure if I understand it. In this case, $K$, $g^{s}$, $g^{cs}$ and $N_{s}$ are only ever used for the authentication. There is no relation to any DH keys that are used for key exchange etc. C must also be understood to never reuse $g^{c}$, as this is basically the client's "challenge" to server. How do you mean that $N_{s}$ might be HMACed in other contexts? – Nuoji Jul 01 '13 at 20:37
  • I mean that an adversary can make lots of connection attempts after receiving the step 1 message. $:$ You should edit your question to say that $K$ will only be used for authentication. $;;$ What I meant is that $:N_S-1:$ might be HMACed in other contexts, namely, in the authenticated communication that follows step 5. $;;;;$ –  Jul 01 '13 at 20:48
  • @RickyDemer I added the clarification. What would an adversary do after capturing $g^c$? I don't see the use of that. Or are we talking about that other question? – Nuoji Jul 01 '13 at 21:11
  • let us continue this discussion in chat –  Jul 01 '13 at 21:14
  • @RickyDemer see my modification and the examples, it should make the intended usage clearer. – Nuoji Jul 02 '13 at 10:14
  • Since your proposals use your idea for key agreement (and not just identification), you would need the implied PKE to be IND-CCA2. $:$ The reason is that an adversary could, between seeing the real g^c and responding to it, send arbitrary step 1 messages to the server and observe and observe the server's responses. $;;;$ –  Jul 02 '13 at 17:40
  • @RickyDemer Are you talking about the key exchange protocols (STS, SIGMA) in themselves? – Nuoji Jul 02 '13 at 18:50
  • No, I'm talking about the modified ones. $;$ –  Jul 02 '13 at 19:10
  • @RickyDemer if we look at the SIGMA protocol, an adversary would like to be able to reply with it's own public key (posing as S) or find out $g^{xy}$. 1) A fundamental assumption in SIGMA is that $K_m$ isn't directly related to the encryption key later used. So the adversary can't easily get to $g^{xy}$. 2) Posing as S requires being able to create $HMAC_K(Data, g^y)$ for a client requested value of $Data$ and $g^c$. I don't see how that's easily done either. STS, on the other hand, does not seem to make the same guarantees (due to the encryption). – Nuoji Jul 02 '13 at 19:24
  • I doubt there's any way to show that standard assumptions imply it can't be feasibly done, either. –  Jul 02 '13 at 19:44
  • @RickyDemer still, this is sort of besides the point. The question is if the proposed $HMAC_K(g^x,g^y)$ has some security leak not present in $SIG_S(g^x,g^y)$. – Nuoji Jul 02 '13 at 19:55
  • The answer is that that's probably far more of an open problem than, $\hspace{2.17 in}$ for example, Decisional Diffie-Hellman. $:$ –  Jul 02 '13 at 20:27
  • @RickyDemer Can you expand on what you mean by that? – Nuoji Jul 02 '13 at 20:30
  • I mean that, I don't see an actual attack, so one could hope it's secure, but one shouldn't do so $;;;;$ because the goal (half-authenticated key agreement) can be achieved from standard assumptions. –  Jul 02 '13 at 20:36
  • @RickyDemer "standard assumptions"? – Nuoji Jul 02 '13 at 21:39
  • Decisional Diffie-Hellman, RSA, quadratic residuosity, syndrome decoding, learning with errors, ... –  Jul 02 '13 at 22:03

1 Answers1

1

An adversary can (repeatedly) submit $h$ as $g^c$ to get a random $N_s$ such that the adversary will
be able to test, with heuristically overwhelming accuracy, whether or not $\: \operatorname{KDF}(N_s,h^s) = x \;$.
An adversary could also attempt to learn something more about what session key the
server obtained, by sending an alleged ciphertext to the server after the key agreement.
(In particular, an adversary could do those things after seeing the client's actual value of $g^c$.)

It would be tricky to show security against such an attack without also showing
security against the case where, for each $h$ value, the adversary will learn
$\langle N_s,\operatorname{KDF}(N_s,h^s)\rangle\:$ for a random $N_s$ (chosen after the adversary chose $h$).
Such a security result would be somewhat analogous to CCA2 security; the analogy would be better
if $N_s$ was the same each time. $\;\;$ Unlike when I previously addressed a similar construction, I am now convinced that this will hold under $\:$KEA1 + KDF-is-a-random-oracle + computational-diffie-hellman$\:$ .
Under those three assumptions, the key agreement will be secure against an adversary
that can choose the server nonces $N_s$, including the ability to cause them to repeat.

The four signing algorithms that you might prefer over the above are BLS,BB,ECDSA.
(That's four because the middle one gives a variant that does use a random oracle.)



However, there are potential efficiency improvements that can be
obtained for only a known and very minor decrease in security.
In particular, in three of your four examples, it will only decrease security against an
active adversary that nonetheless does not have reliable communications with both honest parties.


For the first example and the last two examples, the encryption or MAC with $K_s$ or $K_m$ respectively
will defend against an adversary that [can modify a message in transit but will later
be unable to communicate with either $C$ or $S\hspace{.02 in}$] carrying out a "weak misbinding".
(I use the term "weak" because that is something an adversary with full control over
the communiations channel can necessarily do, no matter what protocol is used.)

Furthermore, for the first example, the encryption won't necessarily
succeed at that goal, although I suspect that it heuristically should.

For STSsao, encrypting the signature will (also) stop a passive eavesdropper
from being able to show that the server carried out a key agreement.


Those are the only reasons to use $K_s$ and $K_m$.
If one declines to use the relevant key, then one obviously should also not derive that key.

Community
  • 1
  • For STSsao, the main reason for encrypting the signature is to show that the signature did indeed come from S. Otherwise an adversary could insert their own credentials e.g. assuming no encryption an adversary could replace the server response with ${ g^y, E, SIG_E(g^x, g^y }$. In the SIGMA paper, they point out that using encryption is weak for verification, and thus removing the encryption and replacing it with a $MAC(S)_{K_s}$. – Nuoji Jul 06 '13 at 10:17
  • An adversary who inserted their own credentials could just choose their own $g^y$ too. $\hspace{1.28 in}$ (Although I might be missing something here.) $;;;$ –  Jul 06 '13 at 10:33
  • After inserting the fake authentication, the adversary can then allow the server-client protocol to continue running. Depending on the later protocol, this may or may not be an attack vector. – Nuoji Jul 06 '13 at 13:58
  • Since the adversary could ordinarily instead just connect to $S$ and then run a "MitM", your suggestion would only make a difference if the adversary loses its connection to $C$ or $S$. $:$ –  Jul 06 '13 at 20:56