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

Andy Lutomirski <luto@amacapital.net> Fri, 07 October 2016 22:57 UTC

Return-Path: <luto@amacapital.net>
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 27FB2129450 for <cfrg@ietfa.amsl.com>; Fri, 7 Oct 2016 15:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com
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 dcKcmBZQBNzn for <cfrg@ietfa.amsl.com>; Fri, 7 Oct 2016 15:57:42 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD2D129431 for <cfrg@irtf.org>; Fri, 7 Oct 2016 15:57:42 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id p25so56007268uaa.1 for <cfrg@irtf.org>; Fri, 07 Oct 2016 15:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l4DizhAuEYQea9Mi5qlx9JLDQUog6WUwkNRI1YSiK5U=; b=S2Ww4M4+wA1nKlCgKtUdDz5nRTMzzWWzUPNOcJB6p8FagdwtmoEHwEaqDCVJhS/I3F y5u9gtA1OI3C0JeK1kqYZzCt664XM1amA2WnJNBpGoUJY6bw04vf02Pokw4WSTYarZCq jQX8LKwsGa5M7Al0KKW4kEwYaKoKAjGui/PDCWNf2GM5rKKyKL5hpOEZUVdk6oL/2pjB zmyhxmCGTCOH/pOxSsApTFdUBIeWMZZPJzLgPWlk9a4Ndkvmn0QVPyz7LCOqKMC+VWOo PZh1TYQnQnIsY2o7BIHKE2oktfggnZ4SkYEgmpe29udGGkaCBIiMBTpm4t8AClaJCdUz lRBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l4DizhAuEYQea9Mi5qlx9JLDQUog6WUwkNRI1YSiK5U=; b=dCjF/icSUAQXeQgtTARRcL6La2KjqLbdn8XjiYrZKhO0IucPljP9XqLpZJQmcU0IKt brN1dGH2PTaTv+X1ZjwvbCutyLk5Ua0G4Y8Ex9rMHGdrbyNzII1Fu6RPY2SFoStYabO3 KdFQiK3NyfSZLDjjumOLuxgGHUwGYBSWNXFWcFC/N37z//Z++EcIGl/WEN1d7aBaNuHS jNK8FFqi+gU/wetpff/fGhQkkiQ2HY5mBh6M+7i0UEFWxS7hVdG4nEO0YwlV7tycgE8L 3E1vZf10wd68HPTqR2gc/PltcAqNRIMPKtowkhLFkAlMoDpJDI5A7bgtiTWdgD75hhAS f6DA==
X-Gm-Message-State: AA6/9RnfN7RnkAcV3NnKnZiesCwhRoiGf1UjnMzP+NzVYl2WGmeYhq7+oWqpXjyZhWiFkb3v2i5Mmy2WhhKZ9Gwq
X-Received: by 10.159.54.171 with SMTP id p40mr14351402uap.93.1475881061332; Fri, 07 Oct 2016 15:57:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.89.204 with HTTP; Fri, 7 Oct 2016 15:57:20 -0700 (PDT)
In-Reply-To: <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> <D41D71D9.A2F6E%paul@marvell.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 7 Oct 2016 15:57:20 -0700
Message-ID: <CALCETrVG501pb=JgZ7LAsqWPVnpQ=_wVD7YZ3fM+=YGvtYM8FQ@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/lcDuzVa1JI-nHuMbHeM4e3JAEK8>
Cc: Gabino Solano <gsolano@wi-fi.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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:57:45 -0000

On Fri, Oct 7, 2016 at 3:39 PM, Paul Lambert <paul@marvell.com> wrote:
> 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]

What's the need for this fanciness?  Why not create a secure channel
using your favorite authenticated DH protocol using just the bootstrap
keys and then exchange long-term public keys over that channel?  This
all seems to be doing something like Signal's [or whatever it's called
these days] "triple DH" protocol, except that triple DH uses genuinely
unauthenticated ephemeral points and triple DH hashes everything
together instead of using EC addition.

I guess what I'm really asking, though, is: what's the point of having
separate bootstrap and long-term keys?

--Andy