idnits 2.17.1 draft-hallambaker-mesh-cryptography-04.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2019) is 1636 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 945 -- Looks like a reference, but probably isn't: '2' on line 948 -- Looks like a reference, but probably isn't: '3' on line 951 -- Looks like a reference, but probably isn't: '4' on line 954 -- Looks like a reference, but probably isn't: '5' on line 957 -- Looks like a reference, but probably isn't: '6' on line 960 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft November 2, 2019 4 Intended status: Informational 5 Expires: May 5, 2020 7 Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms 8 draft-hallambaker-mesh-cryptography-04 10 Abstract 12 The Mathematical Mesh 'The Mesh' is an infrastructure that 13 facilitates the exchange of configuration and credential data between 14 multiple user devices and provides end-to-end security. This 15 document describes the cryptographic algorithm suites used in the 16 Mesh and the implementation of Multi-Party Encryption and Multi-Party 17 Key Generation used in the Mesh. 19 [Note to Readers] 21 Discussion of this draft takes place on the MATHMESH mailing list 22 (mathmesh@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 25 This document is also available online at 26 http://mathmesh.com/Documents/draft-hallambaker-mesh- 27 cryptography.html [1] . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 5, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 68 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 69 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 70 3.1. Mesh Device . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Constrained Device . . . . . . . . . . . . . . . . . . . 5 72 4. Multi-Party Cryptography . . . . . . . . . . . . . . . . . . 6 73 4.1. Application to Diffie Hellman (not normative) . . . . . . 6 74 4.2. Multi-Party Key Generation . . . . . . . . . . . . . . . 7 75 4.3. Multi-Party Decryption . . . . . . . . . . . . . . . . . 7 76 4.4. Mutually Authenticated Key Exchange. . . . . . . . . . . 7 77 4.5. Implementation . . . . . . . . . . . . . . . . . . . . . 7 78 4.5.1. Implementation for Ed25519 and Ed448 . . . . . . . . 8 79 4.5.2. Implementation for X25519 and X448 . . . . . . . . . 9 80 5. Multi-Party Key Generation . . . . . . . . . . . . . . . . . 9 81 5.1. Example: Provisioning the Confirmation Service . . . . . 10 82 6. Multi-Party Decryption . . . . . . . . . . . . . . . . . . . 11 83 6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.2. Implementation . . . . . . . . . . . . . . . . . . . . . 14 85 6.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 14 86 6.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 15 87 6.2.3. Message Encryption and Decryption . . . . . . . . . . 15 88 6.3. Example: Messaging group . . . . . . . . . . . . . . . . 16 89 7. Mutually Authenticated Key Agreement . . . . . . . . . . . . 18 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1. Key Combination . . . . . . . . . . . . . . . . . . . . 19 95 11.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . 19 96 11.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . 19 97 11.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19 98 11.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 20 99 11.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 20 100 11.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 20 101 11.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 20 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 12.2. Informative References . . . . . . . . . . . . . . . . . 21 105 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 This document describes the cryptographic algorithm suites used in 111 the Mesh and the implementation of Multi-Party Encryption and Multi- 112 Party Key Generation used in the Mesh. 114 To allow use of Mesh capabilities on the least capable computing 115 devices currently in use, separate schedules of recommended and 116 required algorithms are specified for Standard Devices and 117 Constrained Devices. 119 The Constrained device class may be considered to include most 8-bit 120 CPUs equipped with sufficient memory to support the necessary 121 operations. For example an Ardunino Mega 2560 which can perform ECDH 122 key agreement and signature operations in times ranging from 3 to 8 123 seconds. While such a device is clearly not suited to perform such 124 operations routinely, a one-time connection process that takes 125 several minutes to complete need not be of major concern. 127 The Standard device class may be considered to include the vast 128 majority of general purpose and personal computing devices 129 manufactured since 2010. Even a Raspberry Pi Zero which currently 130 retails at $5 is capable of performing the cryptographic functions 131 required to implement the Mesh with negligible impact on the user. 133 2. Definitions 135 This section presents the related specifications and standard, the 136 terms that are used as terms of art within the documents and the 137 terms used as requirements language. 139 2.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119] . 145 2.2. Defined Terms 147 The terms of art used in this document are described in the Mesh 148 Architecture Guide [draft-hallambaker-mesh-architecture] . 150 2.3. Related Specifications 152 The architecture of the Mathematical Mesh is described in the Mesh 153 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 154 documentation set and related specifications are described in this 155 document. 157 2.4. Implementation Status 159 The implementation status of the reference code base is described in 160 the companion document [draft-hallambaker-mesh-developer] . 162 3. Recommended and Required Algorithms 164 To allow implementation of Mesh capabilities on the widest possible 165 range of devices, separate algorithm requirements and recommendations 166 are specified for four classes of device: 168 Administration Device A general-purpose computing device that is 169 used for Mesh administration functions. 171 Mesh Device A general-purpose computing device that is not used for 172 Mesh administration functions with sufficient memory and 173 processing power to perform public key cryptography operations 174 without paying particular attention to the impact on performance. 176 Constrained Device An embedded computing device with limited memory 177 and computing power that offers sufficient processing capabilities 178 to perform occasional public key operations (e.g. during device 179 initialization) but is not suited to repeated operations. 181 Bridge Device A trusted device that enables Mesh Devices to 182 interoperate with Constrained devices. 184 Since Administration Devices and Mesh Devices MUST support 185 communication with Mesh Devices and Constrained devices, they MUST 186 meet all the REQUIRED algorithms for both types of device. 188 3.1. Mesh Device 190 Support for the following algorithms is REQUIRED: 192 o SHA-2-512 [SHA-2] 194 o HMAC-SHA-2-512 [RFC2104] 196 o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 198 o AES-CBC-256 Encryption [FIPS197] 200 o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 202 o Montgomery Curve Diffie-Hellman Key Agreement X25519 and X448 203 [RFC7748] 205 o Edwards-Curve Digital Signature Algorithm Ed25519 and Ed448 206 [RFC8032] 208 Support for the following algorithms is RECOMMENDED: 210 o AES-GCM-256 Encryption [AES-GCM] 212 o SHA-3-512 [SHA-3] 214 o KMAC SHA-3-512 [SHA-3-Derived] 216 While the use of GCM is generally preferred over CBC mode in IETF 217 security protocols, this mode is not currently supported by the 218 reference implementation platform. 220 3.2. Constrained Device 222 Support for the following algorithms is REQUIRED: 224 o SHA-2-512 [SHA-2] 226 o HMAC-SHA-2-512 [RFC2104] 228 o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 230 o Poly1035 Authenticated Encryption [RFC8439] 232 o ChaCha20 Encryption [RFC8439] 234 o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 235 o Edwards-Curve Digital Signature Algorithm Ed25519 [RFC8032] 237 o Edwards-Curve Diffie-Hellman Key Agreement Ed25519 [RFC8032] 239 Use of the Edwards Curves for Signature and Key Agreement allows both 240 functions to be supported by a single library with no reduction in 241 security. 243 4. Multi-Party Cryptography 245 The multi-party key generation and multi-party decryption mechanisms 246 used in the Mesh protocols are made possible by the fact that Diffie 247 Hellman key agreement and elliptic curve variants thereof support 248 properties we call the Key Combination Law and the Result Combination 249 Law. 251 Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs. 253 The Key Combination law states that we can define an operator ? such 254 that there is a keypair {Z, z} such that: 256 Z = X ? Y and z = (x + y) mod o (where o is the order of the group) 258 The Result Combination Law states that we can define an operator ? 259 such that: 261 (x ? E) ? (y ? E) = (z ? E) = (e ? Z). 263 4.1. Application to Diffie Hellman (not normative) 265 For the Diffie Hellman system in a modular field p, o = p-1 and a ? b 266 = a ? b = a.b mod p. 268 Proof: 270 By definition, X = e^x mod p, Y = e^y mod p, and Z = e^z mod p. 272 Therefore, 274 Z = e^z mod p = e^x+y mod p = (e^xe^y) mod p = e^x mod p.e^y mod p = 275 X.Y 277 A similar proof may be constructed for the operator ?. 279 4.2. Multi-Party Key Generation 281 The Key Combination Law provides the basis for the Key Co-Generation 282 technique used to ensure that the cryptographic keys used in devices 283 connected to a Mesh profile are sufficiently random and have not been 284 compromised by malware or other 'backdoor' compromise to the machine 285 during or after manufacture. 287 For the Diffie Hellman system, the Key Combination law provides all 288 the mechanism needed to implement a Key Co-Generation mechanism. If 289 the Device key is {X, x}, the administration device can generate a 290 Co-Generation Key Pair {Y, y} and generate a Device Connection 291 Assertion for the final public key E calculated from knowledge of X 292 and Y alone. Passing the value y to the device (using a secure 293 channel) allows it to calculate the corresponding private key e 294 required to make use of the Device Connection Assertion. 296 This approach ensures that a party with knowledge of either x or y 297 but not both obtains no knowledge of e. 299 Section REF _Ref5309729 \w \h 5 describes the implementation of these 300 schemes in the Mesh 302 4.3. Multi-Party Decryption 304 The Key Combination Law and Result Combination Law provide the basis 305 for the Multi-Party Decryption technique used to support Mesh 306 Encryption Groups. 308 Section REF _Ref5309538 \w \h 6 describes the application of this 309 technique in the Mesh 311 4.4. Mutually Authenticated Key Exchange. 313 The Result Combination Law is used to provide a Key Exchange 314 mechanism that provides mutual authentication of the parties while 315 preserving forward secrecy. 317 4.5. Implementation 319 For elliptic curve cryptosystems, the operators ? and ? are point 320 addition. 322 Implementing a robust Key Co-Generation for the Elliptic Curve 323 Cryptography schemes described in [RFC7748] and [RFC8032] requires 324 some additional considerations to be addressed. 326 o The secret scalar used in the EdDSA algorithm is calculated from 327 the private key using a digest function. It is therefore 328 necessary to specify the Key Co-Generation mechanism by reference 329 to operations on the secret scalar values rather than operations 330 on the private keys. 332 o The Montgomery Ladder traditionally used to perform X25519 and 333 X448 point multiplication does not require implementation of a 334 function to add two arbitrary points. While the steps required to 335 create such a function are fully constrained by the specification, 336 the means of satisfying the constraints is not. 338 4.5.1. Implementation for Ed25519 and Ed448 340 The data structures used to implement co-generation of public keys 341 are defined in the main Mesh Reference Guide. This document 342 describes only the additional implementation details. 344 Note that the 'private key' described in [RFC8032] is in fact a seed 345 used to generate a 'secret scalar' value that is the value that has 346 the function of being the private key in the ECDH algorithm. 348 To provision a new public key to a device, the provisioning device: 350 1. Obtains the device profile of the device(s) to be provisioned to 351 determine the type of key to perform co-generation for. Let the 352 device {public, private} key be {D, d}. 354 2. Generates a private key m with the specified number of bytes (32 355 or 57]. 357 3. Calculates the corresponding public key M. 359 4. Calculates the Application public key A = D+M where + is point 360 addition. 362 5. Constructs the application device entry containing the private 363 key value m and encrypts under the device encryption key d. 365 On receipt, the device may at its option use its knowledge of the 366 secret scalar corresponding to d and m to calculate the application 367 secret scalar a or alternatively maintain the two secrets separately 368 and make use of the result combination law to perform private key 369 operations. 371 4.5.2. Implementation for X25519 and X448 373 While the point addition function can be defined for any elliptic 374 curve system, it is not necessary to implement point addition to 375 support ECDH key agreement. 377 In particular, point multiplication using the Montgomery ladder 378 technique over Montgomery curves only operate on the x co-ordinate 379 and only require point doubling operations. 381 For expediency, the current implementation of the Mesh reference code 382 uses the Edwards curves for both signature and encryption pending 383 announcement of platform support for both algorithms. 385 5. Multi-Party Key Generation 387 Multi-Party Key Generation is a capability that is used in the Mesh 388 to enable provisioning of application specific private key pairs to 389 connected devices without revealing any information concerning the 390 application private key of the device. 392 For example, Alice provisions the confirmation service to her watch. 393 The provisioning device could generate a signature key for the device 394 and encrypt it under the encryption key of the device. But this 395 means that we cannot attribute signatures to the watch with absolute 396 certainty as the provisioning device has had knowledge of the watch 397 signature key. Nor do we wish to use the device signature key for 398 the confirmation service. 400 Multi-Party Key Generation allows an administration device to 401 provision a connected device with an application specific private key 402 that is specific to that application and no other such that the 403 application can determine the public key of the device but has no 404 knowledge of the private key. 406 Provisioning an application private key to a device requires the 407 administration device to: 409 o Generate a new application public key for the device. 411 o Construct and publish whatever application specific credentials 412 the device requires to use the application. 414 o Providing the information required to make use of the private key 415 to the device. 417 Note that while the administration device needs to know the device 418 application public key, it does not require knowledge of the device 419 application private key. 421 [[This figure is not viewable in this format. The figure is 422 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 423 cryptography.html [2].]] 425 Two party key pair generation. 427 5.1. Example: Provisioning the Confirmation Service 429 For example, Alice provisions the confirmation service to her watch. 430 The device profile of the watch specifies an Ed25519 signature key. 431 Note that for production use, Ed448 is almost certainly prefered but 432 Ed25519 has the advantage of more compact presentation. 434 Device Key 436 UDF Seed: ZAAA-G4F5-G34W-HHLC-24AP-SZKI-VGO7-UHI 437 Private Key: 438 B7 48 FF 8A 1B D2 04 BC BA 53 70 80 91 66 08 8E 439 26 15 B5 52 ED C9 C4 CE 80 D7 75 A6 BD A9 4A 1C 440 Secret Scalar: 441 56125651237600354228798699639619403779855821496596976661382393571903134631504 442 Public Key: 443 2B B3 8F D1 93 16 E1 5E 24 44 BA 82 9F 4A D3 7D 444 F6 7F B5 A0 92 65 A1 7B F4 8C B6 51 6D F3 9F DC 445 Fingerprint: MANZ-N7DM-BYZH-EQIO-E7YL-C6SX-GONP 447 The provisioning device could generate a signature key for the device 448 and encrypt it under the encryption key of the device. But this 449 means that we cannot attribute signatures to the watch with absolute 450 certainty as the provisioning device has had knowledge of the watch 451 signature key. Nor do we wish to use the device signature key for 452 the confirmation service. 454 Instead, the provisioning device generates an overlay keypair: 456 Device Key 458 UDF Seed: ZAAA-HIGJ-GGBY-NTBF-YS2T-ABNO-4WT2-SIY 459 Private Key: 460 F9 44 69 38 A7 E2 52 A1 F6 1D 9D 9B 29 D1 5D 52 461 77 23 26 0C AF F3 14 A6 4E 95 CB 76 5B 24 B1 67 462 Secret Scalar: 463 49437431830830005043554286843388551057265319605872247754572631754571997461496 464 Public Key: 465 C7 EF 8B 19 BE D9 E7 F7 45 17 73 8E B3 92 6E 86 466 C2 0F A4 06 84 58 BF 3B FE EE 87 A5 B8 EB 62 0A 467 Fingerprint: MBQO-UETO-EL5H-EQBI-PM4Y-QOE7-E6PH 469 The provisioning device can calculate the public key of the composite 470 keypair by adding the public keys of the device profile and the 471 companion public key: 473 Composite public key = Device + Overlay: 474 0A FD 34 5B D7 49 47 BF C3 CC 2E 4B AB A6 BF FE 475 E1 7A B1 3C 74 C6 49 EE 04 9C FF C0 4B D3 05 F6 476 Fingerprint: MBAK-3KK5-F3AN-E6AJ-EIIT-IIL6-7KTP 478 The provisioning device encrypts the private key of the comanion 479 keypair (or the seed from which it was generated) under the 480 encryption key of the device. 482 The provisioning device calculates the private key of the composite 483 keypair by adding the two private key values modulo the order of the 484 group and verifies that scalar multiplication of the base point 485 returns the composite public key value. 487 Composite Secret Scalar = Device + Overlay: 488 3696218815216775247999600833593893946854897602495339232735523069524455498173 489 Fingerprint: MBAK-3KK5-F3AN-E6AJ-EIIT-IIL6-7KTP 491 6. Multi-Party Decryption 493 A key limitation of most deployed messaging systems is that true end- 494 to-end confidentiality is only achieved for a limited set of 495 communication patterns. Specifically, bilateral communications 496 (Alice sends a message to Bob) or broadcast communications to a known 497 set of recipients (Alice sends a message to Bob, Carol and Doug). 498 These capabilities do not support communication patterns where the 499 set of recipients changes over time or is confidential. Yet such 500 requirements commonly occur in situations such as sending a message 501 to a mailing list whose membership isn't known to the sender, or 502 creating a spreadsheet whose readership is to be limited to 503 authorized members of the 'accounting' team. 505 [[This figure is not viewable in this format. The figure is 506 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 507 cryptography.html [3].]] 509 Traditional End-to-End Encryption is static. 511 The mathematical approach that makes key co-generation possible may 512 be applied to support a public key encryption mode in which 513 encryption is performed as usual but decryption requires the use of 514 multiple keys. This approach is variously described in the 515 literature as distributed key generation and proxy re- 516 encryption [Blaze98] . 518 The approach specified in this document borrows aspects of both these 519 techniques. This combined approach is called 'recryption'. Using 520 recryption allows a sender to send a message to a group of users 521 whose membership is not known to the sender at the time the message 522 is sent and can change at any time. 524 [[This figure is not viewable in this format. The figure is 525 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 526 cryptography.html [4].]] 528 Recryption supports End-to-End Encryption in dynamic groups. 530 Proxy re-encryption provides a technical capability that meets the 531 needs of such communication patterns. Conventional symmetric key 532 cryptography uses a single key to encrypt and decrypt data. Public 533 key cryptography uses two keys, the key used to encrypt data is 534 separate from the key used to decrypt. Proxy re-encryption 535 introduces a third key (the recryption key) that allows a party to 536 permit an encrypted data packet to be decrypted using a different key 537 without permitting the data to be decrypted. 539 The introduction of a recryption key permits end-to-end 540 confidentiality to be preserved when a communication pattern requires 541 that some part of the communication be supported by a service. 543 The introduction of a third type of key, the recryption key permits 544 two new roles to be established, that of an administrator and 545 recryption service. There are thus four parties: 547 Administrator Holder of Decryption Key, Creator of Recryption Keys 549 Sender Holder of Encryption Key 550 Recryption Service Holder of Recryption keys 552 Receiver Holder of personal decryption key 554 The communication between these parties is shown in Figure X below: 556 [[This figure is not viewable in this format. The figure is 557 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 558 cryptography.html [5].]] 560 Mesh/Recrypt Parties 562 The information stored at the recryption service is necessary but not 563 sufficient to decrypt the message. Thus, no disclosure of the 564 message plaintext occurs even in the event that an attacker gains 565 full knowledge of all the information stored by the recryption 566 service. 568 6.1. Mechanism 570 The mechanism used to support recryption is the same as the mechanism 571 used to support key co-generation except that this time, instead of 572 combining two keys to create one, the private component of a 573 decryption key (i.e. the private key) is split into two parts, a 574 recryption key and a decryption key. 576 Recall that the key combination law for Diffie Hellman crypto-systems 577 states that we can add two private keys to get a third. It follows 578 that we can split the private key portion of a keypair {G, g} into 579 two parts by choosing a random number that is less than the order of 580 the Diffie-Hellman group to be our first key x. Our second key is y 581 = g - r mod o, where o is the order of the group. 583 Having generated x, y, we can use these to perform private key 584 agreement operations on a public key E and then use the result 585 combination law to obtain the same result that we would have obtained 586 using g. 588 One means of applying this mechanism to recryption would be to 589 generate a different random value x for each member of the group and 590 store it at the recryption service and communicate the value y to the 591 member via a secure channel. Applying this approach, we can clearly 592 see that the recryption service gains no information about the value 593 of the private key since the only information it holds is a random 594 number which could have been generated without any knowledge of the 595 group private key. 597 [RFC8032] requires that implementations derive the scalar secret by 598 taking a cryptographic digest of the private key. This means that 599 either the client or the service must use a non-compliant 600 implementation. Given this choice, it is preferable to require that 601 the non-standard implementation be required at the service rather 602 than the client. This limits the scope of the non-conformant key 603 derivation approach to the specialist recryption service and ensures 604 that the client enforce the requirement to generate the private key 605 component by means of a digest. 607 6.2. Implementation 609 Implementation of recryption in the Mesh has four parts: 611 o Creation and management of the recryption group. 613 o Provisioning of members to a recryption group. 615 o Message encryption. 617 o Message decryption. 619 These operations are all performed using the same catalog and 620 messaging infrastructure provided by the Mesh for other purposes. 622 Each recryption group has its own independent Mesh account. This has 623 many advantages: 625 o Administration of the recryption group may be spread across 626 multiple Mesh users or transferred from one user to another 627 without requiring specification of a separate management protocol 628 to support these operations. 630 o The recryption account address can be used by Mesh applications 631 such as group messaging, conferencing, etc. as a contact address. 633 o The contact request service can be used to notify members that 634 they have been granted membership in the group. 636 6.2.1. Group Creation 638 Creation of a Recryption group requires the steps of: 640 o Generating the recryption group key pair 642 o Creating the recryption group account 644 o Generating administrator record for each administrator. 646 o Publishing the administrator records to the recryption catalog. 648 Note that in principle, we could make use of the key combination law 649 to enable separation of duties controls on administrators so that 650 provisioning of members required multiple administrators to 651 participate in the process. This is left to future versions. 653 6.2.2. Provisioning a Member 655 To provision a user as a member of the recryption group, the 656 administrator requires their current recryption profile. The 657 administrator MAY obtain this by means of a contact service request. 658 As with any contact service request, this request is subject to 659 access control and MAY require authorization by the intended user 660 before the provisioning can proceed. 662 Having obtained the user's recryption profile, the administration 663 tool generates a decryption private key for the user and encrypts it 664 under the member's key to create the encrypted decryption key entry. 666 The administration tool then computes the secret scalar from the 667 private key and uses this together with the secret scalar of the 668 recryption group to compute the recryption key for the member. This 669 value and the encrypted decryption key entry are combined to form the 670 recryption group membership record which is published to the catalog. 672 6.2.3. Message Encryption and Decryption 674 Encryption of a messages makes use of DARE Message in exactly the 675 same manner as any other encryption. The sole difference being that 676 the recipient entry for the recryption operation MUST specify the 677 recryption group address an not just the key fingerprint. This 678 allows the recipient to determine which recryption service to contact 679 to perform the recryption operation. 681 To decrypt a message, the recipient makes an authenticated recryption 682 request to the specified recryption service specifying: 684 o The recipient entry to be used for decryption 686 o The fingerprint of the decryption key(s) the device would like to 687 make use of. 689 o Whether or not the encrypted decryption key entry should be 690 returned. 692 [[This figure is not viewable in this format. The figure is 693 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 694 cryptography.html [6].]] 696 Two key decryption. 698 The recryption service searches the catalog for the corresponding 699 recryption group to find a matching entry. If found and if the 700 recipient and proposed decryption key are dully authorized for the 701 purpose, the service performs the key agreement operation using the 702 recryption key specified in the entry and returns the result to the 703 recipient. 705 The recipient then decrypts the recryption data entry using its 706 device decryption key and uses the group decryption key to calculate 707 the other half of the result. The two halves of the result are then 708 added to obtain the key agreement value that is then used to decrypt 709 the message. 711 6.3. Example: Messaging group 713 NB: The current code implements encryption in the Elliptic Curve 714 Ed25519, not the Montgomery Curve X.25519 as it should. This will be 715 lifted in the near future. 717 Alice creates an encryption keypair. 719 Group Key: 720 51 C5 D1 84 5F C3 31 97 D3 80 2A 25 CE 7F 82 AF 721 F0 30 5B 7D 52 D0 B6 CE 3C 1C 95 A0 33 CB 89 98 722 Value: 723 32231959352602868314725639964100760889451477817969178194652896778421852742616 725 To verify the proper function of the group, Alice creates a test 726 message and encrypts it under the group key. 728 Message = This is a test as UTF8: 729 54 68 69 73 20 69 73 20 61 20 74 65 73 74 731 [{ 732 "enc": "A256CBC", 733 "Salt": "HmQcfDk3qgOudmzqLZdtEw", 734 "recipients": [{ 735 "kid": "MCGR-HO5N-2FPS-VUFQ-DEKF-7TRA-JHM6", 736 "epk": { 737 "PublicKeyECDH": { 738 "crv": "Ed25519", 739 "Public": "T3NLoRxqQEyUPOPQJIp0aVDN4tH2f3BOVXqgCq5SyDs"}}, 740 "wmk": "jjSkEuWVIJZx8zLpedPMzJ9HyXzOcIqJh2i8MdRAHRnYa7E1oMKYyQ"}]}, 741 "Sjd7SsWo4o3OPfM-xBbnIQ"] 743 Alice decides to add Bob to the group. She creates an encryption key 744 for Bob: The decryption key is specified in the same way as any other 745 Ed25519 private key using the hash of a private key seed value: 747 Bob's Member Key: 748 C1 3D 09 F2 D0 46 2B ED 34 43 A2 06 EB C9 C5 6D 749 68 92 08 3C 31 FC E7 35 EB 3D 65 82 82 66 92 1C 750 Value: 751 39765297387767177229798479396757873493329325191929553639423911645504436683984 753 The the recryption key is the group secret scalar minus (mod p) the 754 secret scalar of Bob's private key: 756 Bob's Service Key: 757 [Not specified as a digest input value] 758 Value: 759 6940673119500215512873533693428875877836385344799439767232887009488324560610 761 To decrypt: 763 Member Agreement Value: 764 1D 32 8A 93 79 65 29 58 89 0A D7 A4 2E 57 C6 F6 765 95 B4 78 71 F2 21 EE 63 4F 1D C7 FB A9 52 28 59 767 Service Agreement Value: 768 B8 C1 13 4C 1B 22 21 38 BD 2E 7E 96 39 2C 7B 21 769 56 69 3B 58 6C FE 1E E9 5A 09 09 AD 30 39 09 DC 771 Key Agreement IKM: 772 E7 88 C7 64 12 02 0E E8 66 38 60 F8 C8 A8 DB 36 773 FF DC E5 63 DF 64 61 D7 3E 41 E8 0E 8D FC 65 62 775 This value allows the test message to be decrypted. 777 7. Mutually Authenticated Key Agreement 779 Diffie Hellman key agreement using the authenticated public keys of 780 the principals provides mutual authentication of those principals. 782 For example, if Alice's key pair is {a, A} and Bob's key pair is {b, 783 B}, the Diffie Hellman key agreement value DH (a, B) = DH (b, A) can 784 only be generated from the public information if a or b is known. 786 The chief disadvantage of this approach is that it only allows Alice 787 and Bob to establish a single shared secret that will never vary and 788 does not provide forward secrecy. To avoid this, cryptographic 789 protocols usually perform the key agreement against an ephemeral key 790 and either accept that the client key is not authenticated or perform 791 multiple key agreements and combine the results. 793 Using the Result Combination Law allows a key agreement mechanism to 794 combine the benefits of mutual authentication with the use of 795 ephemeral keys without the need for multiple private key operations 796 or additional round trips. 798 In its simplest form, the key exchange has two parties which we refer 799 to as the client and the server. The client being the party that 800 initiates the protocol exchange and the server being the party that 801 responds. Let the public key pair of the client be {a, A} and that 802 of the server {b, B}. 804 Two versions of the key agreement mechanism are specified: 806 Client ephemeral The client contributes an ephemeral key pair {n_A, 807 N_A}. The effective public key of the client is A ? N_A. 809 The server uses its public key B. 811 The key agreement value is DH (a + n_A, B) = DH (b, A ? N_A) 813 Dual ephemeral The client contributes an ephemeral key pair {n_A, 814 N_A}. The effective public key of the client is A ? N_A. 816 The server contributes an ephemeral key pair {n_B, N_B}. The 817 effective public key of the client is B ? N_B. 819 The key agreement value is DH (a + n_A, B ? N_B) = DH (b + n_B, A 820 ? N_A) 822 The function of the ephemeral key is effectively that of a nonce but 823 it is shared with the counter-party as a public key value. 825 The dual ephemeral approach has the advantage that it limits the 826 scope for side channel attacks as both sides have contributed unknown 827 information to the key agreement value. The disadvantage of this 828 approach is that the key agreement value can only be calculated after 829 the server has provided its ephemeral. 831 Implementations MAY take advantage of the result combination law to 832 enable private key operations involving the authenticated key (or a 833 contribution to it) to be performed in trustworthy hardware. 835 An advantage of this key exchange mechanism over the traditional TLS 836 key exchange approach is that no signature operation is involved, 837 thus ensuring that either party can repudiate the exchange and thus 838 the claim that they were in communication. 840 The master secret is calculated from the key agreement value in the 841 usual fashion. For ECDH algorithms, this comprises the steps of 842 converting the key agreement value to an octet string which forms the 843 input to a Key Derivation Function. 845 8. Security Considerations 847 The security considerations for use and implementation of Mesh 848 services and applications are described in the Mesh Security 849 Considerations guide [draft-hallambaker-mesh-security] . 851 9. IANA Considerations 853 This document requires no IANA actions. 855 10. Acknowledgements 857 A list of people who have contributed to the design of the Mesh is 858 presented in [draft-hallambaker-mesh-architecture] . 860 11. Examples 862 11.1. Key Combination 864 11.1.1. Ed25519 866 11.1.2. Ed448 868 11.1.3. X25519 869 11.1.4. X448 871 11.2. Group Encryption 873 11.2.1. X25519 875 11.2.2. X448 877 12. References 879 12.1. Normative References 881 [AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 882 Operation: Galois/Counter Mode (GCM) and GMAC", November 883 2007. 885 [draft-hallambaker-mesh-architecture] 886 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 887 Architecture Guide", draft-hallambaker-mesh- 888 architecture-11 (work in progress), October 2019. 890 [draft-hallambaker-mesh-security] 891 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 892 Security Considerations", draft-hallambaker-mesh- 893 security-02 (work in progress), October 2019. 895 [FIPS197] NIST, "Advanced Encryption Standard (AES)", November 2001. 897 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 898 Hashing for Message Authentication", RFC 2104, 899 DOI 10.17487/RFC2104, February 1997. 901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, 903 DOI 10.17487/RFC2119, March 1997. 905 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 906 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 907 September 2002. 909 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 910 Key Derivation Function (HKDF)", RFC 5869, 911 DOI 10.17487/RFC5869, May 2010. 913 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 914 for Security", RFC 7748, DOI 10.17487/RFC7748, January 915 2016. 917 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 918 Signature Algorithm (EdDSA)", RFC 8032, 919 DOI 10.17487/RFC8032, January 2017. 921 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 922 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018. 924 [SHA-2] NIST, "Secure Hash Standard", August 2015. 926 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 927 Extendable-Output Functions", August 2015. 929 [SHA-3-Derived] 930 Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived 931 Functions: cSHAKE, KMAC, TupleHash and ParallelHash 932 SHARE", December 2016. 934 12.2. Informative References 936 [Blaze98] "[Reference Not Found!]". 938 [draft-hallambaker-mesh-developer] 939 Hallam-Baker, P., "Mathematical Mesh: Reference 940 Implementation", draft-hallambaker-mesh-developer-09 (work 941 in progress), October 2019. 943 12.3. URIs 945 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 946 cryptography.html 948 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh- 949 cryptography.html 951 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh- 952 cryptography.html 954 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh- 955 cryptography.html 957 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh- 958 cryptography.html 960 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh- 961 cryptography.html 963 Author's Address 965 Phillip Hallam-Baker 967 Email: phill@hallambaker.com