Re: [Cfrg] [T2TRG] Wi-Fi Alliance Device Provisioning Protocol (DPP) - Draft Released for Public Review and Comments

Dan Harkins <dharkins@lounge.org> Thu, 01 September 2016 00:53 UTC

Return-Path: <dharkins@lounge.org>
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 D5AFA12D513; Wed, 31 Aug 2016 17:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 b_NlhiyUaWbg; Wed, 31 Aug 2016 17:53:28 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1686512B044; Wed, 31 Aug 2016 17:53:28 -0700 (PDT)
Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 745D51022406C; Wed, 31 Aug 2016 17:53:27 -0700 (PDT)
To: Andy Lutomirski <luto@amacapital.net>, Paul Lambert <paul@marvell.com>
References: <D3ECA739.9C587%paul@marvell.com> <CALCETrWV5ASUvFCnQDVwL8ULCBeWPoCq45zNFdYhg-n7YeHFYw@mail.gmail.com>
From: Dan Harkins <dharkins@lounge.org>
Message-ID: <2738f67f-b37b-c538-8a72-e0b452f32cb1@lounge.org>
Date: Wed, 31 Aug 2016 17:53:26 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CALCETrWV5ASUvFCnQDVwL8ULCBeWPoCq45zNFdYhg-n7YeHFYw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A2A91B29A3ADBBE020E9BDEA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/URKc_tCVjyAsfqTQDroNfoHBXFc>
Cc: t2trg@irtf.org, cfrg@irtf.org, "adrian.p.stephens@ieee.org" <adrian.p.stephens@ieee.org>, "lear@cisco.com" <lear@cisco.com>
Subject: Re: [Cfrg] [T2TRG] Wi-Fi Alliance Device Provisioning Protocol (DPP) - Draft Released for Public Review and Comments
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: Thu, 01 Sep 2016 00:53:30 -0000

On 8/31/16 5:14 PM, Andy Lutomirski wrote:
>
> On Aug 31, 2016 4:55 PM, "Paul Lambert" <paul@marvell.com 
> <mailto:paul@marvell.com>> wrote:
> >
> >
> > I¹ve made a short summary of the PKEX protocol below. Comments and
> > corrections would be appreciated.
> >
> > Assuming my summary is correct ...
> >
> > If a third party Carol with P_c knows the MAC address and public key of
> > Alice (MAC_a and P_a) a MiTM attack is possible.
> >
> > 1) Alice and Bob share a one-time passphrase to bootstrap 
> connectivity and
> > learn each others associated public keys.
> > 2) Alice
> >    - calculates Pwe_ab = huntandpeck(passphrase_ab)   # passphrase 
> between
> > Alice and Bob
> >    - calculates Q_a = H( MAC_a ) * Pwe_a
> >    - sends Commit with nonce_a and C_a = P_a + Q_a
> > 3) Carol intercepts Alice¹s Commit and having met Alice, know¹s P_a and
> > MAC_a
> >    - calculates  Q_a = (C_a - P_a)
> >    - creates spoofed commit as
> >       C¹_a = P_c + Q_a
> >    - send spoofed commit with nonce_c and C¹_a
> > 4) Carol continues PKEX exchange with Bob using MAC_a
> > 5) At end Bob thinks P_c belongs to MAC_a
> >
>
> Nifty!  IMO that's a rather serious problem -- no brute forcing is needed.
>
> I can improve my quadratic attack, too.  Suppose Carol can convince 
> Alice to run the protocol twice with different passwords pw1 and pw2.  
> (The two runs don't even need to be with the same peer.)  Carol learns 
> Q1_a - Q2_a.  With high probability, Carol can now jointly bruteforce 
> pw1 and pw2 without needing to know P_a.  Now Carol can calculate P_a.
>
> Of course, having done so, Carol can now run your attack to MITM any 
> further exchanges involving Alice.
>
> So I guess that passive observation of two protocol runs almost 
> completely breaks PKEX.
>

   What you both seem to have noticed is what is already mentioned in 
the DPP spec
that you both have quite obviously read. Namely,

   "This bootstrapping technique [PKEX] should never be run multiple 
times with
the  same code. Using this bootstrapping technique more than once with a 
different
code but the same bootstrapping key can enable a dictionary attack."

   There are usage constraints. Go beyond them and your assumptions are not
valid anymore. This is true for all of the boostrapping techniques used in
DPP. The NAN-based method assumes the peers are in close proximity and 
that no
adversaries are. A bold assumption-- when there are no adversaries, the 
exchange
is secure! All security is lost if that's not true-- i.e. it "completely 
breaks".
Yet some people still want to use it because they seem comfortable with 
those
usage constraints.

   These bootstrapping techniques are trying to establish "trust" out of 
whole
cloth, or damn near whole cloth. The usage constraints are being mentioned
honestly so people know how to use them and what they're getting when 
they do.
If you think the usage constraints make a particular bootstrapping 
technique be
effectively worthless that is useful information I guess but that 
doesn't mean
it's completely broken.

   Dan.