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

From: Paul Lambert <[email-masked]>
Date: Thu, 1 Sep 2016 13:46:05 +0000

Dan,

The PKEX protocol exchange is completely broken from the perspective of it’s original purpose and requirements documented in IEEE 802.11ai.

>
> 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."

The IEEE 802.11ai specification (Draft P802.11ai_D10.0) makes no mention of ‘bootstrapping’ and expresses no limitation on the number of times a public key should be used.

The intent of the IEEE 802.11ai specification use of PKEX (Section 12.7.12.1) is to provide an alternative to PKI based trusted third parties. The text explicitly describes that the ‘trust' provided by PKEX in the ownership of a public key will be used to will be used subsequently as part of signature validation for authentication.

The  protocol was intended to prove ownership of a ‘long-term public key’ that would have meaningful use as a means to represent the entity.

Nowhere in IEEE 802.11ai are the usage constraints of this mechanism described and quite the opposite, the intention of the specification is to prove ownership of a key that will be used multiple times.

PKEX is broken and should be removed or completely replaced in IEEE 802.11ai.

Paul

  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.