idnits 2.17.1 draft-haase-cpace-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2020) is 1538 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Haase 3 Internet-Draft Endress + Hauser Liquid Analysis 4 Intended status: Informational February 7, 2020 5 Expires: August 10, 2020 7 CPace, a balanced composable PAKE 8 draft-haase-cpace-01 10 Abstract 12 This document describes CPace which is a protocol for two parties 13 that share a low-entropy secret (password) to derive a strong shared 14 key without disclosing the secret to offline dictionary attacks. 15 This method was tailored for constrained devices, is compatible with 16 any group of both prime- and non-prime order, and comes with a 17 security proof providing composability guarantees. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 3. Definition CPace . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 58 3.3. CPace . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 . . . . . . . . . . 9 61 4.2. CPACE-P256-SSWU_SHA256-SHA256 . . . . . . . . . . . . . . 11 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 67 8.2. Informative References . . . . . . . . . . . . . . . . . 16 68 Appendix A. CPace25519 Test Vectors . . . . . . . . . . . . . . 17 69 A.1. X25519 test vectors . . . . . . . . . . . . . . . . . . . 17 70 A.2. Elligator2 test vectors . . . . . . . . . . . . . . . . . 18 71 A.3. Test vectors for the secret generator G . . . . . . . . . 19 72 A.4. Test vectors for CPace DH . . . . . . . . . . . . . . . . 20 73 A.5. Test vectors for intermediate session key generation . . 21 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 76 1. Introduction 78 This document describes CPace which is a protocol for two parties 79 that share a low-entropy secret (password) to derive a to derive a 80 strong shared key without disclosing the secret to offline dictionary 81 attacks. The CPace method was tailored for constrained devices and 82 specifically considers efficiency and hardware side-channel attack 83 mitigations at the protocol level. CPace is designed to be 84 compatible with any group of both prime- and non-prime order and 85 explicitly handles the complexity of cofactor clearing on the protcol 86 level. CPace comes with a security proof providing composability 87 guarantees. As a protocol, CPace is designed to be compatible with 88 so-called "x-coordinate-only" Diffie-Hellman implementations on 89 elliptic curve groups. 91 CPace is designed to be suitable as both, a building block within a 92 larger protocol construction using CPace as substep, and as a 93 standalone protocol. 95 It is considered, that for composed larger protocol constructions, 96 the CPace subprotocol might be best executed in a separate 97 cryptographic hardware, such as secure element chipsets. The CPace 98 protocol design aims at considering the resulting constraints. 100 2. Requirements Notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. Definition CPace 110 3.1. Setup 112 Let C be a group in which there exists a subgroup of prime order p 113 where the computational simultaneous Diffie-Hellman (SDH) problem 114 [VTBPEKE] is hard. C has order p*c where p is a large prime; c will 115 be called the cofactor. Let I be the unit element in C, e.g., the 116 point at infinity in if C is an elliptic curve group. We denote the 117 operations in the group using addition and multiplication operators, 118 e.g. P + (P + P) = P + 2 * P = 3 * P. We refer to a sequence of n 119 additions of an element in P as scalar multiplication by n and use 120 the notation scalar_multiply(P,n). 122 With F we denote a field that may be associated with C, e.g. the 123 prime base field used for representing the coordinates of points on 124 an elliptic curve. 126 We assume that for any element P in C there is a representation 127 modulo negation, encode_group_element_mod_neg(P) as a byte string 128 such that for any Q in C with Q != P and Q != -P, 129 encode_group_element_mod_neg(P) != encode_group_element_mod_neg(Q). 130 It is recommended that encodings of the elements P and -P share the 131 same result string. Common choices would be a fixed (per-group) 132 length encoding of the x-coordinate of points on an elliptic curve C 133 or its twist C' in Weierstrass form, e.g. according to [IEEE1363] in 134 case of short Weierstrass form curves. For curves in Montgomery form 135 correspondingly the u-coordinate would be encoded, as specified, 136 e.g., by the encodeUCoordinate function from [RFC7748]. 138 With J we denote the group modulo negation associated to C. Note 139 that in J the scalar multiplication operation scalar_multiply is well 140 defined since scalar_multiply(P,s) == -scalar_multiply(-P,s) while 141 arbitrary additions of group elements are no longer available. 143 With J' be denote a second group modulo negation that might share the 144 byte-string encoding function encode_group_element_mod_neg with J 145 such for a given byte string either an element in J or J' is encoded. 146 If the x-coordinate of an elliptic curve point group is used for the 147 encoding, J' would commonly be corresponding to the group of points 148 on the elliptic curve's quadratic twist. Correspondingly, with p' we 149 denote the largest prime factor of the order of J' and its cofactor 150 with c'. 152 Let scalar_cofactor_clearing(s) be a cofactor clearing function 153 taking an integer input argument and returning an integer as result. 154 For any s, scalar_cofactor_clearing(s) is REQUIRED to be of the form 155 c * s1. I.e. it MUST return a multiple of the cofactor. An example 156 of such a function may be the cofactor clearing and clamping 157 functions decodeScalar25519 and decodeScalar448 as used in the X25519 158 and X448 protocols definitions of [RFC7748]. In case of prime-order 159 groups with c == 1, it is RECOMMENDED to use the identity function 160 with scalar_cofactor_clearing(s) = s. 162 Let scalar_mult_cc(P,s) be a joint "scalar multiplication and 163 cofactor clearing" function of an integer s and an string-encoded 164 value P, where P could represent an element either on J or J'. If P 165 is an element in J or J', the scalar_mult_cc function returns a 166 string encoding of an element in J or J' respectively, such that the 167 result of scalar_mult_cc(P,s) encodes (scalar_cofactor_clearing(s) * 168 P). 170 Let scalar_mult_ccv(P,s) be a "scalar multiplication cofactor 171 clearing and verify" function of an integer s and an encoding of a 172 group element P. Unlike scalar_mult_cc, scalar_mult_ccv additionally 173 carries out a verification that checks that the computational 174 simultaneous Diffie-Hellman problem (SDH) is hard in the subgroup (in 175 J or J') generated by the encoded element SP = scalar_mult_cc(P,s). 176 In case that the verification fails (SP might be of low order or on 177 the wrong curve), scalar_mult_ccv is REQUIRED to return the encoding 178 of the identity element I. Otherwise scalar_mult_ccv(P,S) is 179 REQUIRED to return the result of scalar_mult_cc(P,s). A common 180 choice for scalar_mult_ccv for Montgomery curves with twist security 181 would be the X25519 and X448 Diffie-Hellman functions as specified in 182 [RFC7748]. For curves in short Weierstrass form, scalar_mult_ccv 183 could be implemented by the combination of a point verification of 184 the input point with a scalar multiplication. Here scalar_mult_ccv 185 SHALL return the encoding of the neutral element I if the input point 186 P was not on the curve C. 188 Let P=map_to_group_mod_neg(r) be a mapping operation that maps a 189 string r to an encoding of an element P in J. Common choices would 190 be the combination of map_to_base and map_to_curve methods as defined 191 in the hash2curve draft [HASH2CURVE]. Note that we don't require and 192 RECOMMEND cofactor clearing here since this complexity is already 193 included in the definition of the scalar multiplication operation 194 calar_mult_cc above. Additionally requiring cofactor clearing also 195 in map_to_group_mod_neg() would result in efficiency loss. 197 || denotes concatenation of strings. We also let len(S) denote the 198 length of a string in bytes. Finally, let nil represent an empty 199 string, i.e., len(nil) = 0. 201 Let H(m) be a hash function from arbitrary strings m to bit strings 202 of a fixed length. Common choices for H are SHA256 or SHA512 203 [RFC6234]. H is assumed to segment messages m into blocks m_i of 204 byte length H_block. E.g. the blocks used in SHA512 have a size of 205 128 bytes. 207 Let strip_sign_information(P) be function that takes a string 208 encoding of an element P in J and strips any information regarding 209 the sign of P, such that strip_sign_information(P) = 210 strip_sign_information(-P). For short Weierstrass (Montgomery) 211 curves this function will return a string encoding the x-coordinate 212 (u-coordinate). The purpose of defining this function is for 213 allowing for x-coordinate only scalar multiplication algorithms. The 214 sign is to be stripped before generating the intermediate session key 215 ISK. 217 With ISK we denote the intermediate session key output string 218 provided by CPace that is generated by a hash operation on the 219 Diffie-Hellman result. It is RECOMMENDED to apply ISK to a KDF 220 function prior to using the key in a higher-level protocol. 222 KDF(Q) is a key-derivation function that takes an string and derives 223 key of length L. A common choice for a KDF would be HMAC-SHA512. 225 With DSI we denote domain-separation identifier strings that may be 226 prepended to the inputs of Hash and KDF functions. 228 Let IHF(salt, username, pw, sigma) be an iterated hash function that 229 take a salt value, a user name and a password as input. IHF is 230 designed to slow down brute-force attackers as controlled by a 231 workload parameter set sigma. State of the art iterated hash 232 functions are designed for requiring a large amount of memory for its 233 operation and will be referred to as memory-hard hash functions 234 (MHF). Scrypt [RFC7914] or Argon2 are common examples of a MHF 235 primitive. 237 Let A and B be two parties. A and B may also have digital 238 representations of the parties' identities such as Media Access 239 Control addresses or other names (hostnames, usernames, etc). We 240 denote the parties' representation and the parties themselves both by 241 using the identifiers A and B. 243 With CI we denote a string that SHALL be formed by the concatenation 244 of the identifiers A and B and an an OPTIONAL associated data string. 245 AD includes information which A and B might want to authenticate in 246 the protocol execution. CI = A || B || AD; . One first example of 247 CI data is an encoding of the concatenation of IP addresses and port 248 numbers of both parties. AD might include a list of supported 249 protocol versions if CPace were used in a higher-level protocol which 250 negotiates use of a particular version. Including this list would 251 ensure that both parties agree upon the same set of supported 252 protocols and therefore prevent downgrade attacks. 254 We also assume that A and B share a common encoding of a password 255 related string PRS. Typically PRS is a low-entropy secret such as a 256 user-supplied password (pw) or a personal identification number. 257 Note that CPace is NOT RECOMMENDED to be used in conjunction with 258 user datbases that include more than one user account. CPace does 259 not provide mechanisms for agreeing on user names, deriving salt 260 values and agreeing on workload parameters, as required by the MHF 261 functions that should be used for such databases. In such settings 262 it is RECOMMENDED to use CPace as a subcomponent of the higher-level 263 AuCPace protocol. 265 Let sid be a session id byte string chosen for each protocol session 266 before protocol execution; The length len(sid) SHOULD be larger or 267 equal to 16 bytes. 269 With ZPAD we denote a zero-padding string that is appended to PRS 270 such that DSI||PRS has a length of at least H_block. CPace aims at 271 mixing in entropy of PRS into the full internal state of the hash 272 function before any adversary-known variable information (ADVI) 273 enters the hashing algorithm. ADVI such as party identities or 274 session IDs might be partially controlled by an adversary. 275 Correlations of ADVI with the bare PRS string are considered to be 276 easier exploitable by side-channel methods in comparison to a pre- 277 hashed representation of PRS. 279 3.2. Protocol Flow 281 CPace is a one round protocol to establish an intermediate shared 282 secret ISK with implicit mutual authentication. Prior to invocation, 283 A and B are provisioned with public (CI) and secret information (PRS) 284 as prerequisite for running the protocol. During the first round, A 285 sends a public share Ya to B, and B responds with its own public 286 share Yb. Both A and B then derive a shared secret ISK. ISK is 287 meant to be used for producing encryption and authentication keys by 288 a KDF function outside of the scope of CPace. Prior to entering the 289 protocol, A and B agree on a sid string. sid is typically pre- 290 established by a higher-level protocol invocing CPace. If no such 291 sid is available from a higher-level protocol, a suitable approach is 292 to let A choose a fresh random sid string and send it to B together 293 with Ya. This method is shown in the setup protocol section below. 295 This sample trace is shown below. 297 A B 298 | (setup protocol | 299 (sample sid) | and sid) | 300 |----------------->| 301 --------------------------------------- 302 | | 303 (compute Ya) | Ya | 304 |----------------->| 305 | Yb | (compute Yb) 306 |<-----------------| 307 | (verify data) | 308 | (derive ISK) | 310 3.3. CPace 312 Both parties start with agreed values on the sid string, the channel 313 identifier CI and the password-related string PRS. 315 The channel identifier, CI, SHOULD include an encoding of the 316 communication channel used by both parties A and B, such as, e.g., IP 317 and port numbers of both parties. 319 To begin, A calculates a generator G = map_to_group_mod_neg(DSI1 || 320 PRS || ZPAD || sid || CI). 322 A picks ya randomly and uniformly according to the requirement of the 323 group J and calculates Ya=scalar_mult_cc (G,ya). A then transmits Ya 324 to B. 326 B picks yb randomly and uniformly. B then calculates G = 327 map_to_group_mod_neg(DSI1 || PRS || ZPAD || sid || CI) and Yb = 328 scalar_mult_cc(G,yb). B then calculates K = scalar_mult_ccv(Ya,yb). 329 B MUST abort if K is the encoding of the neutral element I. 330 Otherwise B sends Yb to A and proceeds as follows. B strips the sign 331 information from K, Ya and Yb to obtain the strings Ks, Yas and Ybs 332 by using the strip_sign_information() function. B returns ISK = 333 H(DSI2 || sid || Ks || Yas || Ybs). 335 Upon reception of Yb, A calculates K = scalar_mult_ccv(Yb,ya). A 336 MUST abort if K is the neutral element I. If K is different from I, 337 A strips the sign information from K, Ya and Yb and returns ISK = 338 H(DSI2 || sid || Ks || Yas || Ybs). 340 K and Ks are shared values, though they MUST NOT be used as a shared 341 secret key. Note that calculation of ISK from Ks includes the 342 protocol transcript and prevents key malleability with respect to 343 man-in-the-middle attacks from active adversaries. 345 Upon completion of this protocol, the session key ISK returned by A 346 and B will be identical by both parties if and only if the supplied 347 input parameters sid, PRS and CI match on both sides and the 348 information on the public elements in J were not modified by an 349 adversary. 351 4. Ciphersuites 353 This section documents CPACE ciphersuite configurations. A 354 ciphersuite is REQUIRED to specify all of, 356 o a group modulo negation J with an associated 357 encode_group_element_mod_neg function 359 o scalar_mult_cc(P,s) and scalar_mult_ccv(P,s) functions operating 360 on encodings of elements P in J 362 o a mapping function map_to_group_mod_neg(r) converting byte strings 363 r into elements in J 365 o a strip_sign_information(Q) function operating on string 366 representations of elements Q 368 o a hash function H 370 o and domain separation strings DSI1, DSI2 372 Currently, detailed specifications are available for CPACE- 373 X25519-ELLIGATOR2_SHA512-SHA512 and CPACE-P256-SSWU_SHA256-SHA256. 374 These cipher suites are specifically designed for suitability also 375 with constrained hardware. It is recommended that cipher suites for 376 short Weierstrass curves are specified in line with the corresponding 377 definitions for NIST-P256. Cipher suites for modern Montgomery or 378 Edwards curves are recommended to be specified in line with the 379 definitions for Curve25519. 381 +------------+--------------------------+------------------+ 382 | J | map_to_group_mod_neg | KDF | 383 +------------+--------------------------+------------------+ 384 | X25519 | ELLIGATOR2_SHA512 | SHA512 [RFC6234] | 385 | | | | 386 | NIST P-256 | SSWU_SHA256 [HASH2CURVE] | SHA256 [RFC6234] | 387 +------------+--------------------------+------------------+ 389 Table 1: CPace Ciphersuites 391 4.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 393 This cipher suite targets particularly constrained targets and 394 implements specific optimizations. It uses the group of points on 395 the Montgomery curve Curve25519 for constructing J. The base field F 396 is the prime field built upon the prime 2^255 - 19. The Diffie- 397 Hellmann protocol X25519 and the group are specified in [RFC7748]. 398 The encode_group_element_mod_neg(P) is implemented by the 399 encodeUCoordinate(P) function defined in [RFC7748]. The neutral 400 element I is encoded as a 32 byte zero-filled string. 402 The domain separation strings are defined as DSI1 = "CPace25519-1", 403 DSI2 = "CPace25519-2" (twelve-byte ASCII encoding without ANSI-C 404 style trailing zeros). 406 Both, scalar_mult_cc and scalar_mult_ccv, are implemented by the 407 X25519 function specified in [RFC7748]. 409 The secret scalars ya and yb used for X25519 shall be sampled as 410 uniformly distributed 32 byte strings. 412 The map_to_group_mod_neg function is implemented as follows. First 413 the byte length of the ZPAD zero-padding string is determined such 414 that len(ZPAD) = max(0, H_block_SHA512 - len(DSI1 || PRS)), with 415 H_block_SHA512 = 128 bytes. Then a byte string u is calculated by 416 use of u = SHA512(DSI1||PRS||ZPAD||sid||CI). The resulting string is 417 interpreted as 512-bit integer in little-endian format according to 418 the definition of decodeLittleEndian() from [RFC7748]. The resulting 419 integer is then reduced to the base field as input to the Elligator2 420 map specified in [HASH2CURVE] to yield the secret generator G = 421 Elligator2(u). 423 CPace25519 returns a session key ISK of 64 bytes length by a single 424 invocation of SHA512(DSI2||sid||K||Ya||Yb). Since the encoding does 425 not incorporate the sign from the very beginning Qs = 426 strip_sign_information(Q) == Q for this cipher suite. 428 The following sage code could be used as reference implementation for 429 the mapping and key derivation functions. 431 433 def littleEndianStringToInteger(k): 434 bytes = [ord(b) for b in k] 435 return sum((bytes[i] << (8 * i)) for i in range(len(bytes))) 437 def map_to_group_mod_neg_CPace25519(sid, PRS, CI): 438 m = hashlib.sha512() 439 p = 2^255 - 19 441 H_block_SHA512 = 128 442 DSI1 = b"CPace25519-1" 443 ZPAD_len = max(0,H_block_SHA512 - len(CI) - len(PRS)) 444 ZPAD = ZPAD_len * "\0" 446 m.update(DSI1) 447 m.update(PRS) 448 m.update(ZPAD) 449 m.update(sid) 450 m.update(CI) 451 u = littleEndianStringToInteger(m.digest()) 452 return map_to_curve_elligator2_curve25519(u % p) 454 def generate_ISK_CPace25519(sid,K,Ya,Yb): 455 m = hashlib.sha512(b"CPace25519-2") 456 m.update(sid) 457 m.update(K) 458 m.update(Ya) 459 m.update(Yb) 460 return m.digest() 462 464 The definitions above aim at making the protocol suitable for 465 outsourcing CPace to secure elements (SE) where nested hash function 466 constructions such as defined in [RFC5869] have to be considered to 467 be particularly costly. As a result, the task of generating session 468 keys by a strong KDF function is left out of the scope of the CPace 469 protocol. This fact is expressed by the naming of the intermediate 470 shared Key ISK. The definitions above regarding the mapping deviate 471 from the definition in the encode_to_curve function from [HASH2CURVE] 472 by significantly reducing the amount of hash invocations. Moreover, 473 the CPace protocol specification, unlike the hash-to-curve draft 474 specification also considers the risk of side-channel leakage during 475 the hashing of PRS by introducing the ZPAD padding. Mitigating 476 attacks of an adversary that analyzes correlations between publicly 477 known information with the low-entropy PRS strings was considered 478 relevant in important settings. We also avoid the overhead of 479 redundant cofactor clearing, by making the Diffie-Hellman protocol 480 responsible for this task (and not the mapping algorithm). Due to 481 its use in Ed25519 [RFC8032], SHA512 is considered to be the natural 482 hash choice for Curve25519. The 512 bit output of SHA512 moreover 483 allows for removing any statistical bias stemming from the non- 484 canonical base field representations, such that the overhead of the 485 HKDF_extract/HKDF_expand sequences from [HASH2CURVE] are considered 486 not necessary (in line with the assessments regarding Curve25519 in 487 [HASH2CURVE]). 489 4.2. CPACE-P256-SSWU_SHA256-SHA256 491 This cipher suite targets applications that do not as agressively 492 focus on efficiency, bandwidth and code size as the Curve25519 493 implementation. Instead it aims at reusing existing encoding and 494 curve standards wherever possible. 496 It uses the group of points on the NIST P-256 curve which is defined 497 in short Weierstrass form for constructing J [RFC5480]. The base 498 field F is the prime field built upon the Solinas prime p = 499 2^256-2^224+2^192+2^96-1. Encoding of full group elements requires 500 both, x and y coordinates. In order to facilitate point validation 501 and in order to be in line with recent TLS 1.3 requirements, 502 implementations MUST encode both, x and y coordinates. It is 503 RECOMMENDED to use the uncompressed format from [SEC1] using the 0x04 504 octet prefix. The strip_sign_information() function returns the 505 substring from the SEC1 representation encoding the x-coordinate of 506 the curve point. 508 NIST P-256 is of prime order and does not require cofactor clearing. 509 The scalar_cofactor_clearing function is the identity function with 510 scalar_cofactor_clearing(s) == s 512 The domain separation strings are defined as DSI1 = "CPace-P256-1", 513 DSI2 = "CPace-P256-2". 515 For the scalar_mult_cc function operating on the internally generated 516 points, a conventional scalar multiplication on P-256 is used, i.e. 517 without the need of further verification checks. The scalar_mult_ccv 518 function that operates on remotely generated points includes the 519 mandatory verification as follows. First from the encoded point the 520 x and y coordinates are decoded. These points are used for verifying 521 the curve equation. If the point is not on the curve, 522 scalar_mult_ccv returns the neutral element I. If the point is on 523 the curve, scalar_mult_ccv calls scalar_mult_cc and returns the 524 result of the scalar multiplication. 526 For P-256, the map_to_group_mod_neg function is implemented as 527 follows. The zero-padding string length is calculated as len(ZPAD) = 528 max(0, H_block_SHA256 - len(DSI1 || PRS)) with H_block_SHA256 = 64. 529 For the mapping to the curve, a 32 byte string U1 = SHA256(DSI1 || 530 PRS || ZPAD || sid || CI) is calculated. From U1 a second 32 byte 531 value is calculated as U2 = SHA256(U1). The concatenation of U1 and 532 U2 is interpreted as a 512 bit integer u by use of the u = 533 OS2IP(U1 || U2) function from [HASH2CURVE]. This value is reduced to 534 a 32 byte representation of a field element fu = u % p. The 535 coordinates (x,y) in F of the secret generator G are calculated as 536 (x,y) = map_to_curve_simple_swu_3mod4(fu) function from [HASH2CURVE]. 538 As hash function H SHA256 is chosen, returning a session key ISK of 539 32 bytes length with ISK=SHA256(DSI2 || sid || Ks || Yas || Ybs). 541 The following sage code could be used as reference implementation for 542 the mapping and key derivation functions. 544 546 def map_to_group_mod_neg_CPace_P256(sid, PRS, CI): 547 m = hashlib.sha256() 549 H_block_SHA256 = 64 550 DSI1 = b"CPace-P256-1" 551 ZPAD_len = max(0,H_block_SHA256 - len(CI) - len(PRS)) 552 ZPAD = ZPAD_len * "\0" 554 m.update(DSI1) 555 m.update(PRS) 556 m.update(ZPAD) 557 m.update(sid) 558 m.update(CI) 559 U1 = m.digest() 560 U2 = hashlib.sha256(U1).digest() 561 u = OS2I(U1 + U2) 562 return map_to_curve_simple_swu_3mod4(u) 564 def generate_ISK_CPace_P256(sid,K,Ya,Yb): 565 m = hashlib.sha256(b"CPace-P256-2") 566 m.update(sid) 567 m.update(strip_sign_information(K)) 568 m.update(strip_sign_information(Ya)) 569 m.update(strip_sign_information(Yb)) 570 return m.digest() 572 574 Similarly to the Curve25519 implementation, the definitions above aim 575 at making the protocol suitable for outsourcing to secure elements 576 where hash function invocations have to be considered to be 577 particularly costly. As a result, the task of generating session 578 keys by a strong KDF function is left out of the scope of the CPace 579 protocol. The naming of ISK as intermediate shared key reflects this 580 fact. Also the method for calculating the generator has been 581 optimized for reducing the number of hash calculations in comparison 582 to the suggestions [HASH2CURVE]. 584 5. Security Considerations 586 A security proof of CPace is found in [cpace_paper]. 588 Elements received from a peer MUST be checked by a proper 589 implementation of the scalar_mult_ccv method. Failure to properly 590 validate group elements can lead to attacks. The Curve25519-based 591 cipher suite employs the twist security feature of the curve for 592 point validation. As such, it is mandatory to check that all low- 593 order points on both the curve and the twist are mapped on the 594 neutral element by the X25519 function. Corresponding test vectors 595 are provided in the appendix. 597 The choices of random numbers MUST be uniform. Randomly generated 598 values (e.g., ya and yb) MUST NOT be reused. 600 CPace is NOT RECOMMENDED to be used in conjunction with applications 601 supporting different username/password pairs. In this case it is 602 RECOMMENDED to use CPace as building block of the augmented AuCPace 603 protocol. 605 If CPace is used as a building block of higher-level protocols, it is 606 RECOMMENDED that sid is generated by the higher-level protocol and 607 passed to CPace. It is RECOMMENDED sid, is generated by sampling 608 ephemeral random strings. 610 Since CPace is designed to be used as a building block in higher- 611 level protocols and for compatibility with constrained hardware, it 612 does not by itself include a strong KDF construction. CPace uses a 613 simple hash operation for generating its intermediate key ISK. It is 614 RECOMMENDED that the ISK is post-processed by a KDF according the 615 needs of the higher-level protocol. In case that the CPace protocol 616 is delegated to a secure element hardware, it is RECOMMENDED that the 617 main processing unit applies a KDF to the externally generated ISK. 619 In case that side-channel attacks are to be considered practical for 620 a given application, it is RECOMMENDED to focus side-channel 621 protections such as masking and redundant execution (faults) on the 622 process of calculating the secret generator G. The most critical 623 aspect to consider is the processing of the first block of the hash 624 that includes the PRS string. The CPace protocol construction 625 considers the fact that side-channel protections of hash functions 626 might be particularly resource hungry. For this reason, CPace aims 627 at minimizing the number of hash functions invocations in the 628 specified mapping method. 630 CPace is proven secure under the hardness of the computational 631 Simultaneous Diffie-Hellmann (SDH) assumption in the group J (as 632 defined in [VTBPEKE]). Still, even for the event that large-scale 633 quantum computers (LSQC) will become available, CPace forces an 634 active adversary to solve one CDH per password guess. Using the 635 wording suggested by S. Tobtu on the CFRG mailing list, CPace is 636 "quantum-annoying". For the event that LSQC become ubiquitous, it is 637 suggested to consider the replacement of the group operations used in 638 CPace with a corresponding commutative group actions on isogenies, 639 such as suggested in [IsogenyPAKE]. CPace does not require arbitrary 640 group operations but only the operation set available in a group 641 modulo negation. This is considered to be a significant advantage 642 when using commutative isogeny-based group action cryptography as a 643 replacement for elliptic-curve Diffie-Hellmann. 645 6. IANA Considerations 647 No IANA action is required. 649 7. Acknowledgments 651 Thanks to the members of the CFRG for comments and advice. Any 652 comment and advice is appreciated. 654 Comments are specifically invited regarding the following aspect. 655 The CPace mapping function design is based on the following 656 assessments. 1.) Masked, hardware-side-channel-protected hash 657 function implementations should be considered highly desirable for 658 the calculation of the generators G if an implementation might be 659 exposed to physical attacks. 2.) The complexity of such protected 660 hash implementations (possibly with lots of boolean-arithmetic 661 masking conversions) was assessed critical for constrained hardware. 662 Hash operation complexity was also assessed to be critical for secure 663 element chipsets that often were assessed to run hash operations in 664 software without hardware accellerator support. 666 This assessment is not in line with the assumptions for the hash-to- 667 curve-05 draft. As a consequence, this draft aimed at more 668 aggressively reducing the number of nested hash function invocations 669 in comparison to the suggestions of the hash-to-curve-05 draft. 671 8. References 673 8.1. Normative References 675 [HASH2CURVE] 676 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 677 C. Wood, "draft-irtf-cfrg-hash-to-curve-05", 2019. 679 IRTF draft standard 681 [IEEE1363] 682 IEEE, ""Standard Specifications for Public Key 683 Cryptography", IEEE 1363", 2000. 685 IEEE 1363 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 693 "Elliptic Curve Cryptography Subject Public Key 694 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 695 . 697 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 698 Key Derivation Function (HKDF)", RFC 5869, 699 DOI 10.17487/RFC5869, May 2010, 700 . 702 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 703 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 704 DOI 10.17487/RFC6234, May 2011, 705 . 707 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 708 for Security", RFC 7748, DOI 10.17487/RFC7748, January 709 2016, . 711 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 712 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 713 August 2016, . 715 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 716 Signature Algorithm (EdDSA)", RFC 8032, 717 DOI 10.17487/RFC8032, January 2017, 718 . 720 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 721 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 722 May 2017, . 724 [SEC1] SEC, "STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: 725 Elliptic Curve Cryptography", version 2.0", May 2009. 727 8.2. Informative References 729 [cpace_paper] 730 Haase, B. and B. Labrique, "AuCPace. PAKE protocol 731 tailored for the use in the internet of things.", Feb 732 2018. 734 eprint.iacr.org/2018/286 736 [IsogenyPAKE] 737 Taraskin, O., Soukharev, V., Jao, D., and J. LeGrow, "An 738 Isogeny-Based Password-Authenticated Key Establishment 739 Protocol.", Sep. 2018. 741 eprint.iacr.org/2018/886 743 [VTBPEKE] Pointcheval, D. and G. Wang, "VTBPEKE: Verifier-based Two- 744 Basis Password ExponentialKey Exchange", 2017. 746 Proceedings of the 2017 {ACM} on Asia Conference on 747 Computer and Communications Security, AsiaCCS 2017 749 Appendix A. CPace25519 Test Vectors 751 The test vectors for CPace25519 consist of three blocks. 753 First test vectors for X25519 are provided which is used as combined 754 scalar multiplication, cofactor clearing and verification function. 755 Specifically, test vectors for the small order points are provided 756 for checking that all small order points are mapped to the neutral 757 element 759 Then test vectors for the Elligator2 primitive are provided. 761 Then test vectors for the encoding of the secret generator are 762 provided combining the hash operation and the encoding of the 763 generator. 765 Finally test vectors for a honest party protocol execution are 766 provided, including derivation of the session key ISK. 768 A.1. X25519 test vectors 769 ########################### /X25519 ############################### 770 Test vectors for X25519 include three values: 771 - The scalar encoding prior to co-factor clearing and clamping, s 772 - The little-endian byte string encoding of the input point, u 773 - The expected little-endian byte string encoding of the result, r 775 Test vector for X25519 with a coordinate on J: 776 s: a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 777 u: e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c 778 r: c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552 780 Test vector for X25519 with a coordinate on the twist J': 781 s: 4b66e9d4d1b4673c5ad22691957d6af5c11b6421e0ea01d42ca4169e7918ba0d 782 u: e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a413 783 r: 95cbde9476e8907d7aade45cb4b873f88b595a68799fa152e6f8f7647aac7957 785 Test vectors for X25519 with coordinates on J and J' that MUST all 786 yield the neutral element (0) independent of s: 788 s: a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 790 u: 0000000000000000000000000000000000000000000000000000000000000000 791 u: 0100000000000000000000000000000000000000000000000000000000000000 792 u: e0eb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b800 793 u: 5f9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f1157 794 u: ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f 795 u: edffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f 796 u: eeffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f 797 u: cdeb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b880 798 u: 4c9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f11d7 799 u: d9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 800 u: daffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 801 u: dbffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 803 r: 0000000000000000000000000000000000000000000000000000000000000000 805 ########################### X25519/ ############################### 807 A.2. Elligator2 test vectors 809 Two test vectors are provided 810 #################### /Elligator 2 ################################## 812 Vector set 1 as little endian byte strings: 813 in: bc149a46d293b0aeea34581349d72f8a5a96cd531102d67379cd9bfadd4ec800 814 out:66b68f7575cd282403fc2bd323ff04601203c1ec5516ce247f7c0adbef05d367 816 Vector set 1 as base 10 numbers: 817 in: 35391373371110637358764021258915994089392966 818 2186061014226937583985831318716 819 out: 46961069109971370193035504450677895166687682 820 601074157241352710439876254742118 822 #################################################################### 824 Vector set 2 as little endian byte strings: 825 in: 89cf55d4b5d3f84b1634957ac503a32b84ba11471a96b227bca70a0c3bf26375 826 out:1db163c86ceca7621903c9412d6dc71b4ed263b687eed092b194b5e540bba308 828 Vector set 2 as base 10 numbers: 830 in: 530971929581761349677698694411105058011053992421528586742712709 831 85522606362505 832 out: 390779123641965710057372702362153599533842156764537839663973068 833 2305857171741 835 #################### Elligator 2/ ################################## 837 A.3. Test vectors for the secret generator G 838 ###################### /Secret generator G ######################### 839 Inputs: 840 DSI1 = 'CPace25519-1' 841 PRS = 'password' 842 sid = SHA512('sid'), bytes 0 to 15 843 A = 'Ainitiator' 844 B = 'Bresponder' 845 AD = 'AD' 846 #################################################################### 847 Outputs and intermediate results: 849 DSI1 = 435061636532353531392d31 string ('CPace25519-1') of len(12) 850 PRS = 70617373776f7264 ('password') string of len(8) 851 ZPAD = 98 zero bytes (before mixing in variable data) 852 sid = 7e4b4791d6a8ef019b936c79fb7f2c57 string of len(16) 853 CI = 41696e69746961746f7242726573706f6e6465724144 854 ('AinitiatorBresponderAD') string of len(22) 856 u = SHA512(DSI1||PRS||ZPAD||sid||CI) as 512 bit little-endian int: 857 (0xced4bf3254970eaec9f304ed422d8fde59e8c4abb0a27c675b4820a0c2c8fd92 858 << 256) 859 + 0x6dd2899f728ed1620e01e3d7fb9f5cd86e06ee4b5d552bde1524e0cb1e9344e0 860 u as reduced base field element coordinate: 861 0x2166eb1800faff5408149f0fce62b7d9c6941fc79573a335a1d9b8a80868ed26 862 u encoded as little endian byte string: 863 26ed6808a8b8d9a135a37395c71f94c6d9b762ce0f9f140854fffa0018eb6621 865 Elligator2 output G as base field element coordinate: 866 0x307760941be97d7c68b037cb9d22d69838b60e194c50ded8b85873f9e1395126 867 Elligator2 output G encoded as little endian byte string: 868 265139e1f97358b8d8de504c190eb63898d6229dcb37b0687c7de91b94607730 870 ###################### Secret generator G/ ######################### 872 A.4. Test vectors for CPace DH 873 ##################### /CPace Diffie-Hellman ######################## 874 Inputs: 876 Elligator2 output G as base field element coordinate: 877 0x307760941be97d7c68b037cb9d22d69838b60e194c50ded8b85873f9e1395126 878 Elligator2 output G encoded as little endian byte string: 879 265139e1f97358b8d8de504c190eb63898d6229dcb37b0687c7de91b94607730 881 Secret scalar ya=SHA512('ya'), bytes 0...31, as integer: 882 0xbfec93334144994275a3eba9eb0adf3fe40d54e400d105d59724bee398b722d1 883 ya encoded as little endian byte string: 884 d122b798e3be2497d505d100e4540de43fdf0aeba9eba375429944413393ecbf 886 Secret scalar yb=SHA512('yb'), bytes 0...31, as integer: 887 0xb16a6ff3fcaf874cb59058493cb1f28b3e20084ad6d46fcd3c053284d60cecc0 888 yb encoded as little endian byte string: 889 c0ec0cd68432053ccd6fd4d64a08203e8bf2b13c495890b54c87affcf36f6ab1 891 #################################################################### 892 Outputs: 894 Public point Ya as integer: 895 0x79f9f2c1245fd8c4ab38bc75082f2daf6f47ca53fd5f0de7af72fee9c7ddd993 896 Ya encoded as little endian byte string: 897 93d9ddc7e9fe72afe70d5ffd53ca476faf2d2f0875bc38abc4d85f24c1f2f979 899 Public point Yb as integer: 900 0x18ac9063b4419695db48028d2eda7b2b2e649d22f56a5987eba9f05941de1c74 901 Yb encoded as little endian byte string: 902 741cde4159f0a9eb87596af5229d642e2b7bda2e8d0248db959641b46390ac18 904 DH point K as integer: 905 0x276896a227a09f389a04b9656099aa05ef8ec2b394cf32cc50cca9ae56334215 906 K encoded as little endian byte string: 907 15423356aea9cc50cc32cf94b3c28eef05aa996065b9049a389fa027a2966827 909 ##################### CPace Diffie-Hellman/ ######################## 911 A.5. Test vectors for intermediate session key generation 912 #################### /Session Key derivation ####################### 913 Inputs: 915 DSI2 = 435061636532353531392d32 string ('CPace25519-2') of len(12) 916 sid = 7e4b4791d6a8ef019b936c79fb7f2c57 string of len(16) 918 strings of length 32: 919 K = 15423356aea9cc50cc32cf94b3c28eef05aa996065b9049a389fa027a2966827 920 Ya= 93d9ddc7e9fe72afe70d5ffd53ca476faf2d2f0875bc38abc4d85f24c1f2f979 921 Yb= 741cde4159f0a9eb87596af5229d642e2b7bda2e8d0248db959641b46390ac18 923 #################################################################### 925 string of length 64: 926 ISK = SHA512(DSI2 || sid || K || Ya || Yb) 927 = de0be1eeb7e6453d8c961353cd333694866f5432f24b0d4ed393cb6473e835df 928 265ce72613effa3368a907031d897c733d300dfdb364ff66d270b404cdfbcb0a 930 #################### Session Key derivation/ ####################### 932 Author's Address 934 Bjoern Haase 935 Endress + Hauser Liquid Analysis 937 Email: bjoern.m.haase@web.de