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

[Andy Lutomirski <[e-mail]>]

On Aug 31, 2016 5:53 PM, "Dan Harkins" <[e-mail]> wrote:
>
>
> On 8/31/16 5:14 PM, Andy Lutomirski wrote:
>>
>> On Aug 31, 2016 4:55 PM, "Paul Lambert" <[e-mail]> 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.

Then perhaps the design should change to something that doesn't have these
constraints.  This wouldn't be particularly difficult.

I, for one, find it implausible that any real implementation will above by
the constraints.  And I still think it's broken even if you do abide by the
constraints due to the existence of oracles that can test a bootstrapping
public key