[Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA

[Paul Lambert <[e-mail]>]

Dear Stanislav,

Thank you so much for your time to review and break my proposed protocol :-)

This is an important result as it also breaks another draft specification – DPP.

II. The problem is SPM2 in the case of known password seems to be less secure than mbDH (it seems to be unsecure at all in this case).

Consider the following attack (thanks to my colleague Liliya Ahmetzyanova for the description)
Let the adversary who tries to impersonate himself as B, knows password w, but doesn't possess private key s_B and wants to make honest party A believe that he does it for some fixed value of P_B.



1.       A sends the values R_A, Y_A, where

R_A = x_A * G + w * M_A;  (according to the protocol description)

Y_A = y_A * P_A = y_A * s_A * G; (according to the protocol description)

2.       The adversary calculates for random x_B and y_B the values

Y_B = y_B * P_B;

R_B = x_B * G + w * M_B – Y_B;

K = x_B * (R_A – w * M_A) + x_B * Y_A       (     =     x_B * (x_A * G) + x_B * (y_A * s_A * G));

Then all actions are made according to the protocol.

3.       A calculates K according to the protocol:

K = (x_A + y_A * s_A)(R_B – w * M_B + Y_B)    (    =    (x_A + y_A * s_A)(x_B * G)  );

The key K is equal to the key of adversary = > decryption will be correct => the check

assert Y_B == y_B * P_B will be successful;

Thus SPM2 is not secure in the same case as mbDH is – it loses all private-key-related security when the password is known.
Again, Paul, please correct me if I missed something.
No – this is clearly a problem with SPM2 and the “DPP Authentication” protocol.

For background, I’ve been working on fixing 'Wi-Fi setup’. The current technology is old and quite broken:
https://www.wi-fi.org/download.php?file=/sites/default/files/private/members/Wi-Fi_Simple_Configuration_Technical_Specification_v2.0.5.pdf
The current work for new ‘setup’ within the Wi-Fi community is called Device Provisioning Protocol (DPP):
https://www.wi-fi.org/downloads-registered-guest/Wi-Fi_DPP_Tech_Spec_v0_0_23.pdf/31255
    and
https://groups.wi-fi.org/apps/org/workgroup/dpp_ttg/download.php/74822/latest/Explanation%20of%20DPP%20Authentication%20Protocol%20for%20Security%20Review.pdf

This specification contains PKEX 1.0 and there is now a rush to replace this broken functionality … this is the reason we have multiple PKEX and SPM proposals.  Rushing to provide an exact replacement for the PKEX functionality may be a mistake (IMHO) as it is a good opportunity to look at the broader implications and system design given the now identified issues with it’s accompanying ‘DPP Auth’ protocol.

On DPP … in SPM2 I borrowed the  "additive joint key proof-of-possesion” from DPP (draft .23 section 6.2). Here it describes ‘mutual authentication’ as:
    Initiator with: P_I = p_I*G       # Initiator long-term public key
                             B_I = b_I*G       # Initiator ephemeral ‘bootstrap’ public key (exchanged out-of-band, e.g QR code)
   Responder with: P_R = p_R*G       # Responder long-term public key
                                 B_R = b_R*G       # Responder ephemeral ‘bootstrap’ public key (exchanged out-of-band, e.g QR code)
   Secret key calculation:
       S = (p_R + b_R) * (p_I + b_I) * G
     = (p_R + b_R) * (P_I + B_I)[by Responder]
   = (p_I + b_I) * (P_R + B_R)               [by Initiator]

The “DPP Authentication” protocol is in short form the following:


—> B_I
                <— B_R
I_nonce = rand()
K1= H1(p_I * B_R)
—> H(B_R), H(B_I), P_I, { I_nonce, … }K1
                K1=H1(p_R*B_I)
                decrypt { I_nonce, … }K1
                R_nonce=rand()
                S2= (b_R + p_R) * (P_I + B_I)
                K2=H2(I_nonce | R_nonce, “DPP Key”, S2)
                R_auth = H(I_nonce | R_nonce | P_I.x | P_R.x |  [ B_I.x | ] B_R.x | 0)
                <— SHA256(B_R), [ SHA256(B_I), ] P_R, { R_nonce | I_nonce | R-capabilities | { R_auth }K2 }K1
S2=(p_I + b_I)  * (B_R + P_R)
K2 = H2(I_nonce | R_nonce, “DPP Key”, S2)
Decrypt { R_nonce | I_nonce | R-capabilities | { R-auth }K2 }K1
Decrypt { R_auth }K2
assert R_auth == R_auth = H(I_nonce | R_nonce | P_I.x | P_R.x |  [ B_I.x | ] B_R.x | 0)
I_auth = H(R-nonce | I-nonce | PR.x | PI.x | BR.x | [ BI.x | ] 1)
—> SHA256(B_R), [ SHA256(B_I), ] { I_auth }K2
              Decrypt { I_auth }K2
              assert I_auth == H(R-nonce | I-nonce | PR.x | PI.x | BR.x | [ BI.x | ] 1)

Your ‘break’ of SPM2 then applies to B_R where the responder could present any public key (P_R) as their own without having the associated private key by:

…
                <— B_R= b_R*G – P_R
…
                S2= (b_R ) * (P_I + B_I)  # ownership of private key p_R not required!

This being the exact attack you identified with SPM2!

I have several other issues with “DPP Authentication” - for example, why are P_I and P_R both sent openly? This clearly breaks any opportunity for privacy/unlinkability. This is a questionable design choice given that both keys could readily be sent encrypted.


On SPM3 … :-)
It’s clear now that ownership of each private key must be individually validated. Both protocols (SPAKE2 and mbDH) would be more completely preserved by:
    K1 = x_B * (R_A – w*M_A+ Y_A)
    K2 = y_B * s_B*Y_A
    sk_BA = H( “R” || len(id_A)|| id_A || len(id_B) || id_B || len(R_A) || R_A ||
                                len(R_B) || R_B || len(w) || w || len(K) || K1 || len(K2) || K2)


Best Regards,

Paul