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

[Dan Harkins <[e-mail]>]

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.

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

   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.

  DPP has decided to use PKEX because DPP uses public keys for
authentication but does not use a PKI so it needs some way to
get a device's public key that has some manner of "trust" without
relying on certificates and a CA.

   In DPP, public keys are bootstrapped to gain that "trust". For
instance a base64-encoded subjectPublicKeyInfo that is further QR
encoded. Scan the QR code on the device, get the device's key. PKEX is
another  "bootstrapping" technique. Two devices enter the same passphrase,
and they get each other's public keys. Now that the devices have each
other's trusted public keys they can do DPP.

>>>>> A well designed short authentication string system (e.g. ZRTP's)
>>>>> should have no such issues.
>>> Interesting Š yes, a short authentication string is good idea for some
>>> user cases (Rich-UI device to Rich-UI device). I¹ll look at it some more Š
>>    That is exactly the case here. A short authentication string is used to
>> bootstrap trust in a peer's public key.
>>
> Properly designed short authentication strings have very nice security
> properties.  An online attacker has a 1/N chance of spoofing an
> authentication per actual user interaction.  An offline attacker can't
> get anything at all (unless they're willing to brute-force the
> underlying high-entropy crypto).  Look at ZRTP for an example.
>
> PKEX, as vaguely described here, doesn't sound like a properly
> designed short authentication string.  Sorry.

I did the secdir review for the ZRTP draft that became RFC 6189; I
am familiar with ZRTP.

   Dan.