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

From: Andy Lutomirski <[email-masked]>
Date: Tue, 30 Aug 2016 16:37:13 -0700

On Fri, Jul 29, 2016 at 6:27 PM, Paul Lambert <[email-masked]> wrote:
> The Wi-Fi Alliance (WFA) has posted a draft version of a new ‘setup
> protocol’:
>
>
> https://www.wi-fi.org/downloads-registered-guest/Wi-Fi_DPP_Tech_Spec_v0_0_23.pdf
>
>
>
> The WFA is looking for review and comments on this specification.
>

A few comments on a cursory reading:

Section 3.2 specifies a particular point format.  Is this actually
compatible with Curve 25519, etc?  Wouldn't it be more sensible to use
the point format recommended by each individual curve?

Section 5.5: Is the PKEX protocol publicly documented anywhere?  I'm
concerned that the crypto here is highly suboptimal.  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.

A well designed short authentication string system (e.g. ZRTP's)
should have no such issues.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 31 Aug 2016 00:46:55 +0000

Hi Andy,

Thank you very much for taking the time to look at the DPP specification.

On 8/30/16, 4:37 PM, "Andy Lutomirski" <[email-masked]> wrote:

>> The Wi-Fi Alliance (WFA) has posted a draft version of a new Œsetup
>> protocol¹:
>>
>> 
Note - this download site is off-line today Š may be back soon.

>compatible with Curve 25519, etc?
No it is not.

>Wouldn't it be more sensible to use

Yes - I would think we should always consider such values to be opaque
octet strings and the interpretation should be based on the algorithm
suite. Curve 25519 may not be able to be integrated because of:
 - big versus little endian
 - the ³curve" identification method

The hash algorithms are also locked down to SHAxxx and encryption to
AES-SIV so algorithm flexibility is limited.

>concerned that the crypto here is highly suboptimal.

Yes, I¹m not a fan of PKEX in DPP and tried to have it removed. It¹s not
been well reviewed, it¹s really hard to review (due to embedding in
802.11) and it¹s just the wrong mechanism (PAKE) for the desired user
experience.
However,it an interesting design where a PAKE has been extended to provide
both peers with authenticated public keys.  The shared passphrase
effectively introduces two longer term pubic keys. It¹s a significant
design improvement over a typical PAKE that only establishes a shared
symmetric key. PKEX should get some review and get used where appropriate
or we should be working on similar extensions to PAKEs to authenticate
long term public keys.

The specification for PKEX is available in two parts:
1) the base SAE protocol is described in IEEE 802.11
	http://www.ieee802.org/11/private/Draft_Standards/11mc/Draft%20P802.11REVm
c_D8.0.pdf 
	This is a IEEE 802.11 member private site, but I¹ve gotten agreement from
the chair that he will provide access to "security researchers²
	You¹ll have to contact Adrian Stevens (IEEE 802.11 Chair -
[email-masked]) to get the private area password
2) the extension to create PKIX is in IEEE 802.11ai (fragments of text
that will later be incorporated into 802.11)
	This is also on the private site:
http://www.ieee802.org/11/private/index.shtml

IEEE 802.11 keeps draft specifications private, but the contribution
archive is open: https://mentor.ieee.org/802.11/documents
You can see some of it¹s structure by looking at:
https://mentor.ieee.org/802.11/documents?is_dcn=PKEX

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

Paul

---

From: Dan Harkins <[email-masked]>
Date: Tue, 30 Aug 2016 22:49:13 -0700

> 	http://www.ieee802.org/11/private/Draft_Standards/11mc/Draft%20P802.11REVm
   PKEX has nothing to do with the SAE protocol. And it is not even in the
draft REVmc document you refer to.
> http://www.ieee802.org/11/private/index.shtml
   This (802.11ai) is where PKEX is defined.
>>> recover the code) by the entity that obtained the bootstrapping key the
   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.
> 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.

   Dan.
> Paul
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Paul Lambert <[email-masked]>
Date: Wed, 31 Aug 2016 19:03:53 +0000

>   PKEX has nothing to do with the SAE protocol.

PKEX is a direct extension (PAKE+Auth) of the PAKE processing used by SAE.

>And it is not even in the

PKEX uses cryptographic processing defined by SAE in REVmc (some open
documentation of SAE is in RFC7664).

One specific example is the definition in PKEX of the “PWE”. The PWE is
used in the 802.11ai specification, but the definition of the acronym and
the cryptographic processing is contained in the IEEE 802.11mc
specification. The PKEX text (Section 12.7.12.4.1 Initial provisioning for
PKEX) references text in 802.11mc (Section 12.4.4.2.2 Generation of the
password element with ECC groups) that defines the detailed processing of
hunt-and-peck algorithm for the PAKE processing (Section 12.4
Authentication with a password).

PKEX and SAE share the same text for “Authentication with a password"

Yes, PKEX is not in 802.11mc, but it refers to very significant processing
defined in 802.11mc.

Yes, PKEX is not SAE, but they share the same underlying PAKE
cryptographic processing

To understand the PKEX cryptographic processing you MUST have access to
both 802.11ai (188 page specification) and 802.11mc (3,774 page
specification). This is a very large issue for the casual reviewer. Even
with both specifications, parsing out the cryptographic processing from
the verbose 802.11 document is difficult.

...

>bootstrap trust in a peer's public key.

ZRTP defines a short authentication string (SAS) as a unique string
derived from a shared secret created by a DH exchange. Users may validate
the correctness of the string on both ends of the channel. A PAKE requires
a preexisting shared secret that must be exchanged in an out-of-band
manner.  A PAKE is not a SAS and each has significantly different system
and user experience implications.

Paul

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 31 Aug 2016 12:25:35 -0700

On Tue, Aug 30, 2016 at 10:49 PM, Dan Harkins <[email-masked]> wrote:
>   Think of EKE, a password is used to encrypt a public key to peer1. Now
> some
> 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.

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?

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

--Andy

---

From: Dan Harkins <[email-masked]>
Date: Wed, 31 Aug 2016 13:12:32 -0700

> all the relevant documents), the protocol being used doesn't really

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.

> And can someone explain what security properties the protocol is

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.

> designed short authentication string.  Sorry.

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

   Dan.

---

From: Dan Harkins <[email-masked]>
Date: Wed, 31 Aug 2016 13:17:58 -0700

> Yes, PKEX is not SAE, but they share the same underlying PAKE

   That is not true. They both use a secret group element that is derived
from a password but the exchanges are completely different.

   Dan.

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 31 Aug 2016 13:34:28 -0700

On Wed, Aug 31, 2016 at 1:12 PM, Dan Harkins <[email-masked]> wrote:
>>> the

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.

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

>     determine the shared key/code/word/phrase.

You aren't actually providing this last property AFAICT.

> I did the secdir review for the ZRTP draft that became RFC 6189; I

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

-- 
Andy Lutomirski
AMA Capital Management, LLC

---

From: Dan Harkins <[email-masked]>
Date: Wed, 31 Aug 2016 14:27:56 -0700

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

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

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

   What is the security flaw in PKEX that makes other protocols "much
more secure"?
> 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?
> 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.

   Please explain how the _protocol_ itself is not providing this property
because it's not clear to me what you mean.

   Dan.

---

From: Paul Lambert <[email-masked]>
Date: Wed, 31 Aug 2016 22:23:42 +0000

>from a password but the exchanges are completely different.

Yes - the protocols are very different.

My original point was that it is difficult to fully evaluate PKEX without
having the text for SAE that includes field definitions and important
aspects of the cryptographic processing.

Both PKEX and SAE use the identical textual specification that describes
the hunt-and-peek mapping of a passphrase to a group element.  This
mapping is a fundamental aspect of the PAKE processing and makes SAE and
PKEX both members of the class of PAKE algorithms that operate by the
mapping of a passphrase to a group element (point on ECC curve).

The demonstration of knowledge of this group element is very different for
the two protocols.

Paul

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 31 Aug 2016 15:50:10 -0700

On Wed, Aug 31, 2016 at 2:27 PM, Dan Harkins <[email-masked]> wrote:
>>>>> Now

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

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

> using DPP so we each enter some short code on our devices and they

And who generates the short code?

>   What is the security flaw in PKEX that makes other protocols "much

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.

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

> 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

---

From: Dan Harkins <[email-masked]>
Date: Wed, 31 Aug 2016 16:38:47 -0700

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

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 31 Aug 2016 16:48:56 -0700

> actually having seen the protocol.

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