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

[Paul Lambert <[e-mail]>]

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


Paul


- - - PKEX Summary - - -

For two entities Alice and Bob:
 - subscripts indicate entity (e.g. P_a for Alice public key)
 - operating on additive group
 - with generator G on a 'curve'
 - with hash H()
 - and huntandpeck(Point,curve) as defined in 802.11mc
 - scalars are lower case group element (Points) in upper case

Each peer has a long term public key:
   P_a = s_a * G
   P_b = s_b * G
 and MAC addresses
   MAC_a
   MAC_b

Each peer shares by out-of-band a string 'passphrase'

The following is a view of PKEX processing from Alice's perspective:

Pwe_a = huntandpeck( passphrase, curve ) # a point on the curve
m_a = H( MAC_a )
Q_a = m_a * Pwe_a
C_a = P_a + Q_a
nonce_a = random()

Alice ---> Bob   sendCommit( nonce_a, C_a )  from MAC_a
 
Alice <--- Bob   sendCommit( nonce_b, C_b )  from MAC_b

m_b = H(MAC_b)
Q'_b = m_b * Pwe
P'_b = C_b - Q'_b
k = KDF(s_a*P'_b', nonce_a, nonce_b)

Alice ---> Bob  sendCommit( HMAC-Hash(k, P_a || P'_b || MAC_a || MAC_b) )
Alice <--- Bob  sendCommit( HMAC-Hash(k, P_b || P'_a || MAC_b || MAC_b) )

Alice validates that Bob¹s commit message is correct and if so:
 - Alice has demonstrated ownership of P_a to Bob
 - Bob has demonstrated ownership of P_b to Alice
 - no pair-wise shared key is available







>
>>
>>On 8/31/16 12:03 PM, Paul Lambert wrote:
>>> Yes, PKEX is not SAE, but they share the same underlying PAKE
>>> cryptographic processing
>>
>>   That is not true. They both use a secret group element that is derived
>>from a password but the exchanges are completely different.
>
>Yes - the protocols are very different.
>
>My original point was that it is difficult to fully evaluate PKEX without
>having the text for SAE that includes field definitions and important
>aspects of the cryptographic processing.
>
>Both PKEX and SAE use the identical textual specification that describes
>the hunt-and-peek mapping of a passphrase to a group element.  This
>mapping is a fundamental aspect of the PAKE processing and makes SAE and
>PKEX both members of the class of PAKE algorithms that operate by the
>mapping of a passphrase to a group element (point on ECC curve).
>
>The demonstration of knowledge of this group element is very different for
>the two protocols.
>
>Paul
>
>>
>>   Dan.
>>
>>
>
>_______________________________________________
>T2TRG mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/t2trg