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

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

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

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

Which doesn't mean that PKEX has good security properties.



-- 
Andy Lutomirski
AMA Capital Management, LLC