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

[Andy Lutomirski <[e-mail]>]

On Wed, Aug 31, 2016 at 2:27 PM, Dan Harkins <[e-mail]> wrote:
>
>
> On 8/31/16 1:34 PM, Andy Lutomirski wrote:
>>
>> On Wed, Aug 31, 2016 at 1:12 PM, Dan Harkins <[e-mail]> wrote:
>>>
>>>
>>> On 8/31/16 12:25 PM, Andy Lutomirski wrote:
>>>>
>>>> On Tue, Aug 30, 2016 at 10:49 PM, Dan Harkins <[e-mail]>
>>>> wrote:
>>>>>
>>>>>
>>>>>>> For example, the
>>>>>>> text mentions that:
>>>>>>>
>>>>>>>> Using this bootstrapping technique more than once with a different
>>>>>>>> code
>>>>>>>> but the same bootstrapping key can enable a dictionary attack (to
>>>>>>>> recover the code) by the entity that obtained the bootstrapping key
>>>>>>>> the
>>>>>>>> first time.
>>>>>
>>>>>     Think of EKE, a password is used to encrypt a public key to peer1.
>>>>> Now
>>>>> some
>>>>> time later the same public key is sent to peer2 using a different
>>>>> password.
>>>>> In this case peer1 would be able to do an off-line dictionary attack to
>>>>> recover
>>>>> the password used in the exchange to peer2. That's what is intended by
>>>>> the
>>>>> text
>>>>> in question.
>>>>
>>>> If by EKE you mean DH-EKE, then I think this just means you're doing
>>>> EKE wrong.  For DH-EKE (which is actually secure), you send a brand
>>>> new share every time.  Given my very, very limited understanding of
>>>> what is proposed here (since I haven't gone and asked the editors for
>>>> all the relevant documents), the protocol being used doesn't really
>>>> achieve anything useful.
>>>
>>>
>>> Yes, you use a fresh share every time with EKE because the derived
>>> session key is the important thing, you're doing a key exchange protocol
>>> to derive a secure, shared session key. That's not the case with PKEX.
>>> In PKEX the important thing is the decrypted public key, any derived
>>> session key is discarded. So reusing the public key would result in
>>> the issue that the text addresses.
>>
>> Then at the very least why not do real PAKE (DH-EKE or whatever) and
>> then exchange public keys over the resulting secure channel?  ISTM the
>> spec is inventing a new protocol that's strictly worse than the
>> standard protocols out there.
>
>
>   Doing DH-EKE and exchanging public keys in the resulting secure channel
> would not provide proof of possession of the exchanged public keys. And it
> would also double the amount of crypto for no apparent benefit.

But it does prove that someone who legitimately knows the password
intended to pair the devices in question.  If you actually need to
prove possession of keys, then that's easy to add.  But think your
threat model may be a bit confused -- an attacker is going to try to
get you to accept the wrong key, and the attacker will know that wrong
key and will thus have no problems proving possession of it.  An
attacker who gets you to think you provisioned a connection while not
possessing a key doesn't achieve very much as they won't be able to
associate.

>
>   Can you please explain how it is "strictly worse" than the standard
> protocols out there?
>

You can run DH-EKE more than once without enabling an offline attack.

>
>>>> But from reading the draft DPP document, I can't even tell what the
>>>> workflow is.  Who generates a password, who types it where, and who
>>>> sends what?
>>>>
>>>> And can someone explain what security properties the protocol is
>>>> trying to achieve?
>>>
>>>
>>> It was added to 802.11ai to enable raw public keys to be used for
>>> authentication in the 802.11ai protocol. Usually raw public keys are
>>> exchanged "in a manner outside the scope of the standard" but that's
>>> kind of a cop out. So PKEX was added to allow for 2 parties to exchange
>>> raw public keys in a manner that would provide some modicum of trust
>>> to the received public key. Each device will get the peer's public key
>>> in a manner that guarantees the integrity of the received key, with
>>> proof of possession of the private key, from a someone who knows the
>>> shared password. Presuming no one else knows the shared password then
>>> you know who's public key you just received and you know to whom
>>> you just gave your public key.
>>
>> This doesn't answer the question.  What's the workflow?  Do I, as the
>> user, make up an arbitrary password and type it in to both devices?
>> Do I, as a user, read a password generated by one device and type it
>> in to the other?  I'm pretty sure that, for any of these variants,
>> there exist much more secure protocols.  If you further clarify the
>> workflow, I'm sure I can name a better protocol, and the folks lurking
>> here who are good at provable security can probably come up with a
>> straightforwardly provably secure protocol for a far stronger notion
>> of security than you're providing.
>
>
>   The workflow could be either of those. Or it could be: I see you
> in person and we want to enable our devices to securely communicate
> using DPP so we each enter some short code on our devices and they
> do PKEX.

And who generates the short code?

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

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