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

[Andy Lutomirski <[e-mail]>]

On Aug 31, 2016 4:38 PM, "Dan Harkins" <[e-mail]> wrote:
>
>
>
> 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.

That's more or less what I expected.  I think it's vulnerable to all of the
attacks I described.

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