Subject: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

From: "Björn Haase" <[email-masked]>
Date: Tue, 7 Jan 2020 00:51:20 +0100

Dear CFRG community,

I have just posted a first version of an RFC-style draft regarding the balanced subcomponent CPace.

https://datatracker.ietf.org/doc/draft-haase-cpace/

Any feedback would be appreciated!

A corresponding draft for the augmented protocol is in preparation.

Yours,

Björn.

---

From: "Hao, Feng" <[email-masked]>
Date: Tue, 7 Jan 2020 13:02:13 +0000

Hi Bjorn,

I have a couple of comments for your consideration.

First of all, it’s not safe to assume the sender must know the receiver’s exact identity before the key exchange. Identities are normally transmitted “in-flow” as part of the key exchange protocol, as each party may not always know the other party’s exact identity beforehand. I understand Watson Ladd is trying to modify SPAKE2 by hashing the user identities before the key exchange to avoid the trusted setup, but that wouldn’t work for the same reason. Also, I suggest you have a look at the SPEKE specification in the IEEE P1363.2 (2006). If you interpret that specification literally, you may find it’s basically the same as the CPace protocol you propose. The trick is how you define the “shared secret”. In IEEE P1363.2, it’s defined as follows (also see [1])

“A password-based octet string which is generally derived from a password or a hashed password, identifiers for one or more entities, an identifier of a communication session if more than one session might execute concurrently, and optionally includes a salt value and/or other data.”

The items you define in the hash-to-curve function include the above. But obviously, the definition above is highly ambitious and makes the incorrect assumption that identities and session identifiers are always known by the other party even before the key exchange. This is addressed in the latest SPEKE specification in ISO/IEC 11770-4:2017, in which the shared secret is defined as “the password only”. No assumption is made about knowing the other party’s precise identity before the key exchange.

Second, some people on this list seem to assume hash-to-curve will provide you with an ideal RO-like mapping with negligible cost at a constant time. I would urge caution on that assumption until the fact is fully established. The use of hash-to-curve is not anything new; people in the PAKE field have been playing with that idea for nearly 2 decodes. There are previous efforts in IEEE P1363 (2000-2008) and ISO/IEC 11770-4 to define and standardize this function. However, over the past many years, hash-to-curve has been known to be notoriously difficult to get right. In fact, the original SPAKE2 protocol was designed with the motivation to avoid hash-to-curve (but it introduces the trusted setup assumption instead). We may need to wait a bit until the ongoing IEFT effort on defining and standardizing hash-to-curve to finish and for that to become a really established secure primitive (which will be a major contribution to the field, but we should not underestimate that this is actually a very tricky and challenging task).

[1] https://arxiv.org/pdf/1802.04900.pdf

Cheers,
Feng

From: Cfrg <[email-masked]> on behalf of Björn Haase <[email-masked]>
Date: Monday, 6 January 2020 at 23:52
To: "[email-masked]" <[email-masked]>
Subject: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

Dear CFRG community,

Yours,

Björn.

---

From: "Björn Haase" <[email-masked]>
Date: Tue, 7 Jan 2020 15:31:55 +0100

Dear Feng,
 
thank you for your reply. I would like to respond point by point.
 
>First of all, it’s not safe to assume the sender must know the receiver’s exact identity before the key exchange.
>Identities are normally transmitted “in-flow” as part of the key exchange protocol, as each party may not always
>know the other party’s exact identity beforehand.
 
There seems to be the need for more clearly specify, what is "identity".
For the CPace draft, I assumed that the receiver or sender "identity", i.e. the content
of the strings A and B in the CPace draft, would be something like a destination IP address and
a destination port on this machine. I.e. information that is required for establishing the link and exchanging
the message.
 
This is also why I did denote the compiled information that enters CPace as "Channel Identifier" (CI).
In fact the "identities" are not actually the identities in the sense of "Name: Peter, Birthday: 29th of februrary"
but only the "communication identities" such as "Peter's phone number".
 
I think that it might be worth rephrasing this aspect in the draft as A and B denote the "Communication identity"
of the two parties, for making it more clear and explicit.
 
In this understanding the party identifier *will* be known before the protocol could start.
With including the "communication identity" mechanism, we are able to fend off "relay attacks" where A party is thinking it is communicating
with party B while in fact its messages are actually relayed by an adversary
to a party C (which might share the same password).
 
>I understand Watson Ladd is trying to modify SPAKE2 by hashing the user identities before the
>key exchange to avoid the trusted setup, but that wouldn’t work for the same reason. Also,
>I suggest you have a look at the SPEKE specification in the IEEE P1363.2 (2006). If you
>interpret that specification literally, you may find it’s basically the same as
>the CPace protocol you propose.
It is not astonishing to find close similiarities with SPEKE, since CPace *is* essentially SPEKE.
The difference IMO is 1) that with CPace
we *mandatorily* use a session identifier that makes the generator ephemeral and
2) that CPace comes with a proof of the security guarantees
without the requirement for explicit mutual authentication as part of CPace itself.
(Allowing for optionally subsequent mutual explicit authentication, as AuCPace is doing, e.g..)
 
Note that the latter aspects leaves the implementer the freedom to use the mutual explicit
authentication scheme of his personal choice (e.g. exactly the ones used in TLS1.3 or IPSEC).
 
>The trick is how you define the “shared secret”. In IEEE P1363.2, it’s defined as follows (also see [1])
>
>“A password-based octet string which is generally derived from a password or a hashed password,
>identifiers for one or more entities, an identifier of a communication session if more
>than one session might execute concurrently, and optionally includes a salt
>value and/or other data.”
Yes this is close, but CPace REQUIRES the session id.
 
>The items you define in the hash-to-curve function include the above. But obviously, the definition above is highly
>ambitious and makes the incorrect assumption that identities and session identifiers are always known by the
>other party even before the key exchange.
 
As described beforehand that depends on what we call "Identity". If a true identity is available: "Fine you should use it!"
if only the communication identity is available: "This needs to be used as a bare minimum for fending off relay attacks.".
 
>This is addressed in the latest SPEKE specification in ISO/IEC 11770-4:2017, in which the shared secret is
>defined as “the password only”. No assumption is made about knowing the other party’s precise
>identity before the key exchange.
 
The definitions like the SPEKE-"password only" definition would not be provably secure in UC
in my perception, because this would allow for "relay attacks".
 
>Second, some people on this list seem to assume hash-to-curve will provide you with an ideal RO-like
>mapping with negligible cost at a constant time. I would urge caution on that assumption until the
>fact is fully established.
>
>The use of hash-to-curve is not anything new; people in the PAKE field have been playing with that idea for
>nearly 2 decodes. There are previous efforts in IEEE P1363 (2000-2008) and ISO/IEC 11770-4 to define and
>standardize this function.
>However, over the past many years, hash-to-curve has been known to be notoriously difficult to get
>right. In fact, the original SPAKE2 protocol was designed with the motivation to avoid hash-to-curve
> (but it introduces the trusted setup assumption instead).
 
In my conviction, the true reason for all of the problems with efficient constant-time hash-to-curve algorithms
has nothing to do with techical aspects. I am convinced, it's all about legal stuff and IPR.
(Also note, that CPace does not require a true RO hashing to the curve but just an encoding.)
 
The IPR nightmare is exactly, why I have been so painfully picky regarding IPR in conjunction with hash-to-curve.
It's not because I love this awful and annoying attorney stuff: I HATE digging through that!
Still I am convinced that this IPR stuff is the only and
true source of all the awful "PACE-Generic-Mapping" complexity and at the source of the "Dragonblood" issue.
 
It's also all about patents, IMO, why J-PAKE has been integrated by companies like Mozilla, and SPEKE and
SPAKE2 were not considered.
(In fact, I  believe that very few people will be talking openly about this type of reasoning.)
 
Note also, while the SPEKE patent has expired, the PAK patent that I believe to be relevant for
SPAKE2 will still be a painful problem for the years to come.
 
In my opinion it is a major achievement of the hash-to-curve team (notably Riad!) to have found a
way to work around the IPRs! I am not able and willing to give any legal advice (IANAL!), but personally I
am now fully convinced that with the current specficiations for SSWU in hash-to-curve-05 the team has found
a way through the jungle also for short-Weierstrass curves.
 
>We may need to wait a bit until the ongoing IEFT effort on defining and standardizing hash-to-curve to
>finish and for that to become a really established secure primitive (which will be a major contribution
>to the field, but we should not underestimate that this is actually a very tricky and challenging task).
 
Actually as mentioned above, I personally don't see any remaining technical or security risks.
(This is also what I did take with me from discussions with the BSI people that designed the PAKE protocol
for the german identity cards.)
Also note, that there *are* already high security applications that use PAKE with mapping,
such as the "french" version of PACE.
 
Maybe you could be more specific, where exactly, you identify security issues with hashing to curves.
 
Yours,
 
Björn.

---

From: Björn Haase <[email-masked]>
Date: Wed, 8 Jan 2020 11:26:34 +0000

Dear CFRG community.

after posting the draft, I have also sent my questions in the draft to several persons. I'd like to share with you one first preliminary response regarding the hash operation for generating the input of the map algorithm that I have received from a secure-element expert in an off-the-list discussion.

----------
"Regarding your question in the draft: Your assessment is completely right. Hash functions on secure elements have to be used with ‘care’. Typically these functions are *not* hardened. I.e. they are leaking inputs and/or outputs. If ever, there is one implementation of one hash function, mostly SHA256, which has less leakage. However this function shall only be used with specific constraints. The constraints limit the number of permissible invocations of the function to X iterations with equal secret-part of the input, often with small X.

A construction like SHA256(DSI1 || PRS || ZPAD || sid || CI) is likely to be particularly bad in this context because it is possible to trigger with the known components ‘CPace-P256-1’ or ZPAD on the secret to extract, PRS. My suggestion would be to use a CMAC-PRF instead of the hash function, for instance RFC4615."
----------

From this I draw the conclusion, that for the use-case of password blinding, a construction such as HMAC and/or the HKDF construction, where the key enters the hash function 
several times might actually not be good candidates if used for protecting low-entropy secrets in a hostile environment where side-channels become relevant (as described e.g. in RFC 8125). The keying information enters the operations very often in the nested hash function invocations ☹.

(RFC8125: 
  "If a device operates in a potentially hostile environment, such as a smart card,
   other side channels like power consumption and electromagnetic
   emanations or even active implementation attacks have to be taken
   into account as well.")

One consequence for the hash_to_curve draft architecture might be, that we possibly should better not standardize the encode_to_curve(s) operation with a specific mandatory hash operation.? It seems that at least as soon as side-channel resilience is to be considered, that this complexity might better be left over to the consideration of the higher-level protocol that makes use of the encoded point.

I expect to be receiving more detailed input next week from experts with a stronger background than I could be providing from discussions at the Brainpool meeting. I will keep you synchronized.

Yours,

Björn.

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

Von: Cfrg <[email-masked]> Im Auftrag von "Björn Haase"
Gesendet: Dienstag, 7. Januar 2020 00:51
An: cfrgirtf.org <[email-masked]>
Betreff: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

Dear CFRG community,

 

Yours,
 
Björn.