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

Paul Lambert <paul@marvell.com> Fri, 07 October 2016 22:39 UTC

Return-Path: <paul@marvell.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA612946A for <cfrg@ietfa.amsl.com>; Fri, 7 Oct 2016 15:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWTuU3iU6vMf for <cfrg@ietfa.amsl.com>; Fri, 7 Oct 2016 15:39:56 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68A1129458 for <cfrg@irtf.org>; Fri, 7 Oct 2016 15:39:55 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u97MZPIZ006053; Fri, 7 Oct 2016 15:39:52 -0700
Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 25wjdea9xm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Oct 2016 15:39:51 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 7 Oct 2016 15:39:49 -0700
Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Fri, 7 Oct 2016 15:39:49 -0700
From: Paul Lambert <paul@marvell.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Thread-Topic: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
Thread-Index: AQHSHgrdOKDNID9LN0iPY9SSrJS9bKCX6jeAgAHYmwCAA9P/gIAABIQA
Date: Fri, 7 Oct 2016 22:39:49 +0000
Message-ID: <D41D71D9.A2F6E%paul@marvell.com>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com> <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com> <D418A094.A29E7%paul@marvell.com> <CAMr0u6mUWxjqZbFBriMv8wDnmsWU6g2SBm3vnvOhX=B2rRF3aQ@mail.gmail.com> <D41D5F87.A2EC7%paul@marvell.com>
In-Reply-To: <D41D5F87.A2EC7%paul@marvell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.94.250.30]
Content-Type: multipart/alternative; boundary="_000_D41D71D9A2F6Epaulmarvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_10:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610070391
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bxap9jL39916hudkil7QWPYM5-4>
Cc: Gabino Solano <gsolano@wi-fi.org>
Subject: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2016 22:39:58 -0000

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