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

[Dan Harkins <[e-mail]>]

On 8/31/16 3:50 PM, Andy Lutomirski wrote:
> On Wed, Aug 31, 2016 at 2:27 PM, Dan Harkins <[e-mail]> wrote:
>>    What is the security flaw in PKEX that makes other protocols "much
>> more secure"?
> Since I still haven't read a full description of PKEX, here are my
> guesses.  None of them depend on the details of the mapping from
> (passphrase, cleartext group element) -> (ciphertext).  If that
> mapping were biased, then additional attacks would be possible.

   Oh, I didn't realize you were making these statements without
actually having seen the protocol.

   See the attached.

   Dan.

> 1. An attacker who has once legitimately paired with one of the
> devices in question and thus knows the public key can apparently
> passively capture a PKEX exchange and brute-force the password.  This
> seems like a rather serious weakness.
>
> 2. I think there's a quadratic brute-force attack if passwords are not
> reused.  Suppose there are N possible passwords.  An attacker can wait
> for a PKEX exchange attempt, capture the messages, and also block the
> messages so it fails.  Then the attacker captures a second PKEX
> attempt between the same two parties.  There are N^2 possible pairs of
> passwords for the first and second attempts.  Since, in general, we
> can expect N^2 << sqrt(2^256) or so (especially if the passwords are,
> say, six-digit numbers, and using six-digit or even four-digit numbers
> for an exchange like this is entirely reasonable if the crypto is
> good), the attacker can simply try all N^2 possibilities to find one
> for which the recovered public keys match.  With high probability, the
> attacker will have recovered both keys and the public key.  You seem
> to be treating the public key as somewhat secret, this already breaks
> it.  If the attacker has full MITM capabilities, the attacker can now
> edit the exchanged messages in the second exchange to substitute his
> or her own keys.
>
> This attack seems complicated, but I can imagine it being fast enough
> to run in real time and hijack a connection.
>
> 3. You have no forward protection against brute-forcing.  A leak of a
> potential long-term secret (the *public bootstrapping key*, since this
> protocol really does seem to think that the public key is secret)
> allows brute-forcing the exchange after the fact.  Real PAKE protocols
> don't have this problem -- the information that needs to be protected
> is ephemeral.
>
> 4. I suspect that, once a PKEX exchange succeeds in the context of
> DPP, a passive eavesdropper will be able to capture enough information
> to be able to evaluate whether a given guess of a party's public key
> is correct.  This enables a full off-line attack on the password.
>
> 5. The really, really easy attack: in the real world, I suspect that a
> lot of PKEX-supporting devices will be things like APs and will also
> have QR codes.  So an attacker can simply read the QR code, learn the
> AP's public key, and then brute force all subsequent PKEX exchanges.
>
> This whole protocol doesn't have a coherent description of exactly who
> does what and what the security properties are supposed to be, which
> makes it very unlikely that provable security is possible.  I wouldn't
> be terribly surprised if I or others could break it further if anyone
> cared to.
>
> If an implementation really never reuses a bootstrapping public key,
> then #1, #2, and #5 don't work.  I find it implausible that devices
> will actually use ephemeral bootstrapping keys, if for no other reason
> than that it would significantly complicate the rest of the protocol.
> And if devices do use ephemeral bootstrapping keys, then evaluating
> whether #4 is a problem cannot be done by simply analyzing PKEX.  One
> would also need to analyze the DPP Authentication protocol to
> determine whether it leaked enough information (to a passive or active
> attacker) to allow checking whether a guess of the bootstrap key is
> correct.  This is, in my book, sufficient reason to reject the entire
> PKEX primitive.  A primitive should be secure on its own without
> regard to the context in which it's used.
>
> 6.2.3 says: The Responder receives the DPP Authentication Request
> message and checks whether a SHA256 hash of the DER encoded ASN.1
> SubjectPublicKeyInfo of its public bootstrapping key is in the
> message. If not, it discards the message and returns to its quiescent
> state. If a hash of its key is in the message, ...
>
> That looks like it could give a clear indication of whether a guessed
> bootstrap key is correct.
>
>
> On another note, this looks like a potential vulnerability;
>
> 6.2.3 further says: If a hash of its key is in the message, it next
> checks whether it has a copy of the Initiator’s public bootstrapping
> key (whose SHA256 hash matches that in the message). If so, and the
> Responder wishes to do mutual authentication, it will perform mutual
> authentication, otherwise it will not perform mutual authentication.
>
> This looks like it might be a way to force a downgrade that prevents
> mutual authentication.
>
>>>
>>> The 802.11 folks already screwed up WPA Personal by failing to use a
>>> real PAKE for silly reasons.  Please don't screw up DPP as well.
>>
>>    SAE is the PAKE in 802.11. But as I said to Paul, PKEX is not SAE.
>>
>>    I would like to understand what you mean by "screw up DPP as well."
>> How is DPP being screwed up by the inclusion of PKEX?
>>>>     The properties listed in in the 802.11ai amendment for PKEX are:
>>>>
>>>>     - the protocol will result in the exchange of trusted public
>>>>       keys or it will fail;
>>>>     - a passive adversary is unable to subvert the exchange, insert
>>>>       any different public keys, learn the public keys, or learn the
>>>>       key/code/word/phrase shared by the two peers;
>>>>     - an active adversary that does not know the shared key/code/word/
>>>>       phrase cannot successfully complete the exchange; and,
>>>>     - an attacker is not able to perform an off-line dictionary attack
>>>>       against PKEX in order to determine wither the public keys or
>>>>       determine the shared key/code/word/phrase.
>>> You aren't actually providing this last property AFAICT.
>>
>>    Why not? If you mean that reusing the same public key with a different
>> key/code/word/phrase then see the quote at the top of this email that
>> started this thread. That is an acknowledged security consideration already.
> Saying it's "an acknowledged security consideration" doesn't make it
> magically stop being a violation of the intended security properties.
>
>>    Please explain how the _protocol_ itself is not providing this property
>> because it's not clear to me what you mean.
> A protocol with a big nasty gotcha like this that's already known when
> the protocol is proposed is unacceptable in my book.  Also, it seems
> considerably more broken than just this gotcha -- see above.
>
> But why oh why is the 802.11 group inventing its own crypto?  It's not
> the 1990s any more.  Use a real primitive.
>
> --Andy