idnits 2.17.1 draft-hallambaker-mesh-cryptography-02.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 : ---------------------------------------------------------------------------- ** 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 (July 8, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 922 -- Looks like a reference, but probably isn't: '2' on line 925 -- Looks like a reference, but probably isn't: '3' on line 928 -- Looks like a reference, but probably isn't: '4' on line 931 -- Looks like a reference, but probably isn't: '5' on line 934 -- Looks like a reference, but probably isn't: '6' on line 937 Summary: 1 error (**), 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 July 8, 2019 4 Intended status: Informational 5 Expires: January 9, 2020 7 Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms 8 draft-hallambaker-mesh-cryptography-02 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 This document is also available online at 20 http://mathmesh.com/Documents/draft-hallambaker-mesh- 21 cryptography.html [1] . 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 62 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 63 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 64 3.1. Mesh Device . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Constrained Device . . . . . . . . . . . . . . . . . . . 5 66 4. Multi-Party Cryptography . . . . . . . . . . . . . . . . . . 6 67 4.1. Application to Diffie Hellman (not normative) . . . . . . 6 68 4.2. Multi-Party Key Generation . . . . . . . . . . . . . . . 6 69 4.3. Multi-Party Decryption . . . . . . . . . . . . . . . . . 7 70 4.4. Mutually Authenticated Key Exchange. . . . . . . . . . . 7 71 4.5. Implementation . . . . . . . . . . . . . . . . . . . . . 7 72 4.5.1. Implementation for Ed25519 and Ed448 . . . . . . . . 8 73 4.5.2. Implementation for X25519 and X448 . . . . . . . . . 8 74 5. Multi-Party Key Generation . . . . . . . . . . . . . . . . . 9 75 5.1. Example: Provisioning the Confirmation Service . . . . . 10 76 6. Multi-Party Decryption . . . . . . . . . . . . . . . . . . . 10 77 6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13 79 6.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 14 80 6.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 14 81 6.2.3. Message Encryption and Decryption . . . . . . . . . . 14 82 6.3. Example: Messaging group . . . . . . . . . . . . . . . . 15 83 7. Mutually Authenticated Key Agreement . . . . . . . . . . . . 17 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 87 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 11.1. Key Combination . . . . . . . . . . . . . . . . . . . . 18 89 11.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . 18 90 11.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . 18 91 11.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 18 92 11.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19 93 11.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 19 94 11.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19 95 11.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 98 12.2. Informative References . . . . . . . . . . . . . . . . . 20 99 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 This document describes the cryptographic algorithm suites used in 105 the Mesh and the implementation of Multi-Party Encryption and Multi- 106 Party Key Generation used in the Mesh. 108 To allow use of Mesh capabilities on the least capable computing 109 devices currently in use, separate schedules of recommended and 110 required algorithms are specified for Standard Devices and 111 Constrained Devices. 113 The Constrained device class may be considered to include most 8-bit 114 CPUs equipped with sufficient memory to support the necessary 115 operations. For example an Ardunino Mega 2560 which can perform ECDH 116 key agreement and signature operations in times ranging from 3 to 8 117 seconds. While such a device is clearly not suited to perform such 118 operations routinely, a one-time connection process that takes 119 several minutes to complete need not be of major concern. 121 The Standard device class may be considered to include the vast 122 majority of general purpose and personal computing devices 123 manufactured since 2010. Even a Raspberry Pi Zero which currently 124 retails at $5 is capable of performing the cryptographic functions 125 required to implement the Mesh with negligible impact on the user. 127 2. Definitions 129 This section presents the related specifications and standard, the 130 terms that are used as terms of art within the documents and the 131 terms used as requirements language. 133 2.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119] . 139 2.2. Defined Terms 141 The terms of art used in this document are described in the Mesh 142 Architecture Guide [draft-hallambaker-mesh-architecture] . 144 2.3. Related Specifications 146 The architecture of the Mathematical Mesh is described in the Mesh 147 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 148 documentation set and related specifications are described in this 149 document. 151 2.4. Implementation Status 153 The implementation status of the reference code base is described in 154 the companion document [draft-hallambaker-mesh-developer] . 156 3. Recommended and Required Algorithms 158 To allow implementation of Mesh capabilities on the widest possible 159 range of devices, separate algorithm requirements and recommendations 160 are specified for four classes of device: 162 Administration Device A general-purpose computing device that is 163 used for Mesh administration functions. 165 Mesh Device A general-purpose computing device that is not used for 166 Mesh administration functions with sufficient memory and 167 processing power to perform public key cryptography operations 168 without paying particular attention to the impact on performance. 170 Constrained Device An embedded computing device with limited memory 171 and computing power that offers sufficient processing capabilities 172 to perform occasional public key operations (e.g. during device 173 initialization) but is not suited to repeated operations. 175 Bridge Device A trusted device that enables Mesh Devices to 176 interoperate with Constrained devices. 178 Since Administration Devices and Mesh Devices MUST support 179 communication with Mesh Devices and Constrained devices, they MUST 180 meet all the REQUIRED algorithms for both types of device. 182 3.1. Mesh Device 184 Support for the following algorithms is REQUIRED: 186 o SHA-2-512 [SHA-2] 188 o HMAC-SHA-2-512 [RFC2104] 190 o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 191 o AES-CBC-256 Encryption [FIPS197] 193 o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 195 o Montgomery Curve Diffie-Hellman Key Agreement X25519 and X448 196 [RFC7748] 198 o Edwards-Curve Digital Signature Algorithm Ed25519 and Ed448 199 [RFC8032] 201 Support for the following algorithms is RECOMMENDED: 203 o AES-GCM-256 Encryption [AES-GCM] 205 o SHA-3-512 [SHA-3] 207 o KMAC SHA-3-512 [SHA-3-Derived] 209 While the use of GCM is generally preferred over CBC mode in IETF 210 security protocols, this mode is not currently supported by the 211 reference implementation platform. 213 3.2. Constrained Device 215 Support for the following algorithms is REQUIRED: 217 o SHA-2-512 [SHA-2] 219 o HMAC-SHA-2-512 [RFC2104] 221 o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 223 o Poly1035 Authenticated Encryption [RFC8439] 225 o ChaCha20 Encryption [RFC8439] 227 o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 229 o Edwards-Curve Digital Signature Algorithm Ed25519 [RFC8032] 231 o Edwards-Curve Diffie-Hellman Key Agreement Ed25519 [RFC8032] 233 Use of the Edwards Curves for Signature and Key Agreement allows both 234 functions to be supported by a single library with no reduction in 235 security. 237 4. Multi-Party Cryptography 239 The multi-party key generation and multi-party decryption mechanisms 240 used in the Mesh protocols are made possible by the fact that Diffie 241 Hellman key agreement and elliptic curve variants thereof support 242 properties we call the Key Combination Law and the Result Combination 243 Law. 245 Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs. 247 The Key Combination law states that we can define an operator ? such 248 that there is a keypair {Z, z} such that: 250 Z = X ? Y and z = (x + y) mod o (where o is the order of the group) 252 The Result Combination Law states that we can define an operator ? 253 such that: 255 (x ? E) ? (y ? E) = (z ? E) = (e ? Z). 257 4.1. Application to Diffie Hellman (not normative) 259 For the Diffie Hellman system in a modular field p, o = p-1 and a ? b 260 = a ? b = a.b mod p. 262 Proof: 264 By definition, X = e^x mod p, Y = e^y mod p, and Z = e^z mod p. 266 Therefore, 268 Z = e^z mod p = e^x+y mod p = (e^xe^y) mod p = e^x mod p.e^y mod p = 269 X.Y 271 A similar proof may be constructed for the operator ?. 273 4.2. Multi-Party Key Generation 275 The Key Combination Law provides the basis for the Key Co-Generation 276 technique used to ensure that the cryptographic keys used in devices 277 connected to a Mesh profile are sufficiently random and have not been 278 compromised by malware or other 'backdoor' compromise to the machine 279 during or after manufacture. 281 For the Diffie Hellman system, the Key Combination law provides all 282 the mechanism needed to implement a Key Co-Generation mechanism. If 283 the Device key is {X, x}, the administration device can generate a 284 Co-Generation Key Pair {Y, y} and generate a Device Connection 285 Assertion for the final public key E calculated from knowledge of X 286 and Y alone. Passing the value y to the device (using a secure 287 channel) allows it to calculate the corresponding private key e 288 required to make use of the Device Connection Assertion. 290 This approach ensures that a party with knowledge of either x or y 291 but not both obtains no knowledge of e. 293 Section REF _Ref5309729 \w \h 5 describes the implementation of these 294 schemes in the Mesh 296 4.3. Multi-Party Decryption 298 The Key Combination Law and Result Combination Law provide the basis 299 for the Multi-Party Decryption technique used to support Mesh 300 Encryption Groups. 302 Section REF _Ref5309538 \w \h 6 describes the application of this 303 technique in the Mesh 305 4.4. Mutually Authenticated Key Exchange. 307 The Result Combination Law is used to provide a Key Exchange 308 mechanism that provides mutual authentication of the parties while 309 preserving forward secrecy. 311 4.5. Implementation 313 For elliptic curve cryptosystems, the operators ? and ? are point 314 addition. 316 Implementing a robust Key Co-Generation for the Elliptic Curve 317 Cryptography schemes described in [RFC7748] and [RFC8032] requires 318 some additional considerations to be addressed. 320 o The secret scalar used in the EdDSA algorithm is calculated from 321 the private key using a digest function. It is therefore 322 necessary to specify the Key Co-Generation mechanism by reference 323 to operations on the secret scalar values rather than operations 324 on the private keys. 326 o The Montgomery Ladder traditionally used to perform X25519 and 327 X448 point multiplication does not require implementation of a 328 function to add two arbitrary points. While the steps required to 329 create such a function are fully constrained by the specification, 330 the means of satisfying the constraints is not. 332 4.5.1. Implementation for Ed25519 and Ed448 334 The data structures used to implement co-generation of public keys 335 are defined in the main Mesh Reference Guide. This document 336 describes only the additional implementation details. 338 Note that the 'private key' described in [RFC8032] is in fact a seed 339 used to generate a 'secret scalar' value that is the value that has 340 the function of being the private key in the ECDH algorithm. 342 To provision a new public key to a device, the provisioning device: 344 1. Obtains the device profile of the device(s) to be provisioned to 345 determine the type of key to perform co-generation for. Let the 346 device {public, private} key be {D, d}. 348 2. Generates a private key m with the specified number of bytes (32 349 or 57]. 351 3. Calculates the corresponding public key M. 353 4. Calculates the Application public key A = D+M where + is point 354 addition. 356 5. Constructs the application device entry containing the private 357 key value m and encrypts under the device encryption key d. 359 On receipt, the device may at its option use its knowledge of the 360 secret scalar corresponding to d and m to calculate the application 361 secret scalar a or alternatively maintain the two secrets separately 362 and make use of the result combination law to perform private key 363 operations. 365 4.5.2. Implementation for X25519 and X448 367 While the point addition function can be defined for any elliptic 368 curve system, it is not necessary to implement point addition to 369 support ECDH key agreement. 371 In particular, point multiplication using the Montgomery ladder 372 technique over Montgomery curves only operate on the x co-ordinate 373 and only require point doubling operations. 375 For expediency, the current implementation of the Mesh reference code 376 uses the Edwards curves for both signature and encryption pending 377 announcement of platform support for both algorithms. 379 5. Multi-Party Key Generation 381 Multi-Party Key Generation is a capability that is used in the Mesh 382 to enable provisioning of application specific private key pairs to 383 connected devices without revealing any information concerning the 384 application private key of the device. 386 For example, Alice provisions the confirmation service to her watch. 387 The provisioning device could generate a signature key for the device 388 and encrypt it under the encryption key of the device. But this 389 means that we cannot attribute signatures to the watch with absolute 390 certainty as the provisioning device has had knowledge of the watch 391 signature key. Nor do we wish to use the device signature key for 392 the confirmation 394 service. 396 Multi-Party Key Generation allows an administration device to 397 provision a connected device with an application specific private key 398 that is specific to that application and no other such that the 399 application can determine the public key of the device but has no 400 knowledge of the private key. 402 Provisioning an application private key to a device requires the 403 administration device to: 405 o Generate a new application public key for the device. 407 o Construct and publish whatever application specific credentials 408 the device requires to use the application. 410 o Providing the information required to make use of the private key 411 to the device. 413 Note that while the administration device needs to know the device 414 application public key, it does not require knowledge of the device 415 application private key. 417 [[This figure is not viewable in this format. The figure is 418 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 419 cryptography.html [2].]] 421 Two party key pair generation. 423 5.1. Example: Provisioning the Confirmation Service 425 For example, Alice provisions the confirmation service to her watch. 426 The device profile of the watch specifies an Ed25519 signature key. 427 Note that for production use, Ed448 is almost certainly prefered but 428 Ed25519 has the advantage of more compact presentation. 430 TBS: 432 The provisioning device could generate a signature key for the device 433 and encrypt it under the encryption key of the device. But this 434 means that we cannot attribute signatures to the watch with absolute 435 certainty as the provisioning device has had knowledge of the watch 436 signature key. Nor do we wish to use the device signature key for 437 the confirmation service. 439 Instead, the provisioning device generates a companion keypair. A 440 random seed is generated. 442 TBS: 444 A key derrivation function (HKDF) is used to derrive a 255 bit secret 445 scalar. 447 TBS: 449 The provisioning device can calculate the public key of the composite 450 keypair by adding the public keys of the device profile and the 451 companion public key: 453 TBS: 455 The provisioning device encrypts the private key of the comanion 456 keypair under the encryption key of the device. 458 TBS: 460 The provisioning device calculates the private key of the composite 461 keypair by adding the two private key values and verifies that scalar 462 multiplication of the base point returns the composite public key 463 value. 465 6. Multi-Party Decryption 467 A key limitation of most deployed messaging systems is that true end- 468 to-end confidentiality is only achieved for a limited set of 469 communication patterns. Specifically, bilateral communications 470 (Alice sends a message to Bob) or broadcast communications to a known 471 set of recipients (Alice sends a message to Bob, Carol and Doug). 472 These capabilities do not support communication patterns where the 473 set of recipients changes over time or is confidential. Yet such 474 requirements commonly occur in situations such as sending a message 475 to a mailing list whose membership isn't known to the sender, or 476 creating a spreadsheet whose readership is to be limited to 477 authorized members of the 'accounting' team. 479 [[This figure is not viewable in this format. The figure is 480 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 481 cryptography.html [3].]] 483 Traditional End-to-End Encryption is static. 485 The mathematical approach that makes key co-generation possible may 486 be applied to support a public key encryption mode in which 487 encryption is performed as usual but decryption requires the use of 488 multiple keys. This approach is variously described in the 489 literature as distributed key generation and proxy re- 490 encryption [Blaze98] . 492 The approach specified in this document borrows aspects of both these 493 techniques. This combined approach is called 'recryption'. Using 494 recryption allows a sender to send a message to a group of users 495 whose membership is not known to the sender at the time the message 496 is sent and can change at any time. 498 [[This figure is not viewable in this format. The figure is 499 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 500 cryptography.html [4].]] 502 Recryption supports End-to-End Encryption in dynamic groups. 504 Proxy re-encryption provides a technical capability that meets the 505 needs of such communication patterns. Conventional symmetric key 506 cryptography uses a single key to encrypt and decrypt data. Public 507 key cryptography uses two keys, the key used to encrypt data is 508 separate from the key used to decrypt. Proxy re-encryption 509 introduces a third key (the recryption key) that allows a party to 510 permit an encrypted data packet to be decrypted using a different key 511 without permitting the data to be decrypted. 513 The introduction of a recryption key permits end-to-end 514 confidentiality to be preserved when a communication pattern requires 515 that some part of the communication be supported by a service. 517 The introduction of a third type of key, the recryption key permits 518 two new roles to be established, that of an administrator and 519 recryption service. There are thus four parties: 521 Administrator Holder of Decryption Key, Creator of Recryption Keys 523 Sender Holder of Encryption Key 525 Recryption Service Holder of Recryption keys 527 Receiver Holder of personal decryption key 529 The communication between these parties is shown in Figure X below: 531 [[This figure is not viewable in this format. The figure is 532 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 533 cryptography.html [5].]] 535 Mesh/Recrypt Parties 537 The information stored at the recryption service is necessary but not 538 sufficient to decrypt the message. Thus, no disclosure of the 539 message plaintext occurs even in the event that an attacker gains 540 full knowledge of all the information stored by the recryption 541 service. 543 6.1. Mechanism 545 The mechanism used to support recryption is the same as the mechanism 546 used to support key co-generation except that this time, instead of 547 combining two keys to create one, the private component of a 548 decryption key (i.e. the private key) is split into two parts, a 549 recryption key and a decryption key. 551 Recall that the key combination law for Diffie Hellman crypto-systems 552 states that we can add two private keys to get a third. It follows 553 that we can split the private key portion of a keypair {G, g} into 554 two parts by choosing a random number that is less than the order of 555 the Diffie-Hellman group to be our first key x. Our second key is y 556 = g - r mod o, where o is the order of the group. 558 Having generated x, y, we can use these to perform private key 559 agreement operations on a public key E and then use the result 560 combination law to obtain the same result that we would have obtained 561 using g. 563 One means of applying this mechanism to recryption would be to 564 generate a different random value x for each member of the group and 565 store it at the recryption service and communicate the value y to the 566 member via a secure channel. Applying this approach, we can clearly 567 see that the recryption service gains no information about the value 568 of the private key since the only information it holds is a random 569 number which could have been generated without any knowledge of the 570 group private key. 572 [RFC8032] requires that implementations derive the scalar secret by 573 taking a cryptographic digest of the private key. This means that 574 either the client or the service must use a non-compliant 575 implementation. Given this choice, it is preferable to require that 576 the non-standard implementation be required at the service rather 577 than the client. This limits the scope of the non-conformant key 578 derivation approach to the specialist recryption service and ensures 579 that the client enforce the requirement to generate the private key 580 component by means of a digest. 582 6.2. Implementation 584 Implementation of recryption in the Mesh has four parts: 586 o Creation and management of the recryption group. 588 o Provisioning of members to a recryption group. 590 o Message encryption. 592 o Message decryption. 594 These operations are all performed using the same catalog and 595 messaging infrastructure provided by the Mesh for other purposes. 597 Each recryption group has its own independent Mesh account. This has 598 many advantages: 600 o Administration of the recryption group may be spread across 601 multiple Mesh users or transferred from one user to another 602 without requiring specification of a separate management protocol 603 to support these operations. 605 o The recryption account address can be used by Mesh applications 606 such as group messaging, conferencing, etc. as a contact address. 608 o The contact request service can be used to notify members that 609 they have been granted membership in the group. 611 6.2.1. Group Creation 613 Creation of a Recryption group requires the steps of: 615 o Generating the recryption group key pair 617 o Creating the recryption group account 619 o Generating administrator record for each administrator. 621 o Publishing the administrator records to the recryption catalog. 623 Note that in principle, we could make use of the key combination law 624 to enable separation of duties controls on administrators so that 625 provisioning of members required multiple administrators to 626 participate in the process. This is left to future versions. 628 6.2.2. Provisioning a Member 630 To provision a user as a member of the recryption group, the 631 administrator requires their current recryption profile. The 632 administrator MAY obtain this by means of a contact service request. 633 As with any contact service request, this request is subject to 634 access control and MAY require authorization by the intended user 635 before the provisioning can proceed. 637 Having obtained the user's recryption profile, the administration 638 tool generates a decryption private key for the user and encrypts it 639 under the member's key to create the encrypted decryption key entry. 641 The administration tool then computes the secret scalar from the 642 private key and uses this together with the secret scalar of the 643 recryption group to compute the recryption key for the member. This 644 value and the encrypted decryption key entry are combined to form the 645 recryption group membership record which is published to the catalog. 647 6.2.3. Message Encryption and Decryption 649 Encryption of a messages makes use of DARE Message in exactly the 650 same manner as any other encryption. The sole difference being that 651 the recipient entry for the recryption operation MUST specify the 652 recryption group address an not just the key fingerprint. This 653 allows the recipient to determine which recryption service to contact 654 to perform the recryption operation. 656 To decrypt a message, the recipient makes an authenticated recryption 657 request to the specified recryption service specifying: 659 o The recipient entry to be used for decryption 661 o The fingerprint of the decryption key(s) the device would like to 662 make use of. 664 o Whether or not the encrypted decryption key entry should be 665 returned. 667 [[This figure is not viewable in this format. The figure is 668 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 669 cryptography.html [6].]] 671 Two key decryption. 673 The recryption service searches the catalog for the corresponding 674 recryption group to find a matching entry. If found and if the 675 recipient and proposed decryption key are dully authorized for the 676 purpose, the service performs the key agreement operation using the 677 recryption key specified in the entry and returns the result to the 678 recipient. 680 The recipient then decrypts the recryption data entry using its 681 device decryption key and uses the group decryption key to calculate 682 the other half of the result. The two halves of the result are then 683 added to obtain the key agreement value that is then used to decrypt 684 the message. 686 6.3. Example: Messaging group 688 Alice creates a recryption group. The group encryption and signature 689 key parameters are: 691 TBS: 693 To verify the proper function of the group, Alice creates a test 694 message and encrypts it under the group key. 696 TBS: 697 TBS: 699 Alice decides to add Bob to the group. Bob's recryption profile is: 701 TBS: 703 The decryption key is specified in the same way as any other Ed25519 704 private key using the hash of a private key seed value: 706 TBS: 708 The the recryption key is the group secret scalar minus (mod p) the 709 secret scalar of Bob's private key: 711 TBS: 713 The Recryption entry consists of Bob's address, the recryption key 714 and the decryption key encrypted under Bob's encryption key: 716 TBS: 718 The group administration tool creates a notification request to tell 719 Bob that he has been made a member of the new group and signs it 720 using the group signature key. The recryption entry and the 721 notification are then sent to the recryption service: 723 TBS: 725 The notification message contains a link to the test message. When 726 he accepts membership of the group, Bob clicks on the link to test 727 that his membership has been fully provisioned. Providing an 728 explicit test mechanism avoids the problem that might otherwise occur 729 in which the message spool fills up with test messages being posted. 731 Bob's Web browser requests the recryption data for the test message. 732 The request is authenticated and encrypted under Bob's device keys. 733 The plaintext of the message is: 735 TBS: 737 The plaintext of the response contains the additional information 738 Bob's Web browser needs to complete the decryption process: 740 TBS: 742 The Web browser decrypts the private key and uses it to calculate the 743 decryption value: 745 TBS: 747 The key agreement value is obtained by point addition of the 748 recryption and decryption values: 750 TBS: 752 This value allows the test message to be decrypted. 754 7. Mutually Authenticated Key Agreement 756 Diffie Hellman key agreement using the authenticated public keys of 757 the principals provides mutual authentication of those principals. 759 For example, if Alice's key pair is {a, A} and Bob's key pair is {b, 760 B}, the Diffie Hellman key agreement value DH (a, B) = DH (b, A) can 761 only be generated from the public information if a or b is known. 763 The chief disadvantage of this approach is that it only allows Alice 764 and Bob to establish a single shared secret that will never vary and 765 does not provide forward secrecy. To avoid this, cryptographic 766 protocols usually perform the key agreement against an ephemeral key 767 and either accept that the client key is not authenticated or perform 768 multiple key agreements and combine the results. 770 Using the Result Combination Law allows a key agreement mechanism to 771 combine the benefits of mutual authentication with the use of 772 ephemeral keys without the need for multiple private key operations 773 or additional round trips. 775 In its simplest form, the key exchange has two parties which we refer 776 to as the client and the server. The client being the party that 777 initiates the protocol exchange and the server being the party that 778 responds. Let the public key pair of the client be {a, A} and that 779 of the server {b, B}. 781 Two versions of the key agreement mechanism are specified: 783 Client ephemeral The client contributes an ephemeral key pair {n_A, 784 N_A}. The effective public key of the client is A ? N_A. 786 The server uses its public key B. 788 The key agreement value is DH (a + n_A, B) = DH (b, A ? N_A) 790 Dual ephemeral The client contributes an ephemeral key pair {n_A, 791 N_A}. The effective public key of the client is A ? N_A. 793 The server contributes an ephemeral key pair {n_B, N_B}. The 794 effective public key of the client is B ? N_B. 796 The key agreement value is DH (a + n_A, B ? N_B) = DH (b + n_B, A 797 ? N_A) 799 The function of the ephemeral key is effectively that of a nonce but 800 it is shared with the counter-party as a public key value. 802 The dual ephemeral approach has the advantage that it limits the 803 scope for side channel attacks as both sides have contributed unknown 804 information to the key agreement value. The disadvantage of this 805 approach is that the key agreement value can only be calculated after 806 the server has provided its ephemeral. 808 Implementations MAY take advantage of the result combination law to 809 enable private key operations involving the authenticated key (or a 810 contribution to it) to be performed in trustworthy hardware. 812 An advantage of this key exchange mechanism over the traditional TLS 813 key exchange approach is that no signature operation is involved, 814 thus ensuring that either party can repudiate the exchange and thus 815 the claim that they were in communication. 817 The master secret is calculated from the key agreement value in the 818 usual fashion. For ECDH algorithms, this comprises the steps of 819 converting the key agreement value to an octet string which forms the 820 input to a Key Derivation Function. 822 8. Security Considerations 824 The security considerations for use and implementation of Mesh 825 services and applications are described in the Mesh Security 826 Considerations guide [draft-hallambaker-mesh-security] . 828 9. IANA Considerations 830 This document requires no IANA actions. 832 10. Acknowledgements 834 A list of people who have contributed to the design of the Mesh is 835 presented in [draft-hallambaker-mesh-architecture] . 837 11. Examples 839 11.1. Key Combination 841 11.1.1. Ed25519 843 11.1.2. Ed448 845 11.1.3. X25519 846 11.1.4. X448 848 11.2. Group Encryption 850 11.2.1. X25519 852 11.2.2. X448 854 12. References 856 12.1. Normative References 858 [AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 859 Operation: Galois/Counter Mode (GCM) and GMAC", November 860 2007. 862 [draft-hallambaker-mesh-architecture] 863 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 864 Architecture Guide", draft-hallambaker-mesh- 865 architecture-08 (work in progress), July 2019. 867 [draft-hallambaker-mesh-security] 868 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 869 Considerations", draft-hallambaker-mesh-security-00 (work 870 in progress), April 2019. 872 [FIPS197] NIST, "Advanced Encryption Standard (AES)", November 2001. 874 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 875 Hashing for Message Authentication", RFC 2104, 876 DOI 10.17487/RFC2104, February 1997. 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997. 882 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 883 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 884 September 2002. 886 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 887 Key Derivation Function (HKDF)", RFC 5869, 888 DOI 10.17487/RFC5869, May 2010. 890 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 891 for Security", RFC 7748, DOI 10.17487/RFC7748, January 892 2016. 894 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 895 Signature Algorithm (EdDSA)", RFC 8032, 896 DOI 10.17487/RFC8032, January 2017. 898 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 899 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018. 901 [SHA-2] NIST, "Secure Hash Standard", August 2015. 903 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 904 Extendable-Output Functions", August 2015. 906 [SHA-3-Derived] 907 Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived 908 Functions: cSHAKE, KMAC, TupleHash and ParallelHash 909 SHARE", December 2016. 911 12.2. Informative References 913 [Blaze98] "[Reference Not Found!]". 915 [draft-hallambaker-mesh-developer] 916 Hallam-Baker, P., "Mathematical Mesh: Reference 917 Implementation", draft-hallambaker-mesh-developer-08 (work 918 in progress), April 2019. 920 12.3. URIs 922 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 923 cryptography.html 925 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh- 926 cryptography.html 928 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh- 929 cryptography.html 931 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh- 932 cryptography.html 934 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh- 935 cryptography.html 937 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh- 938 cryptography.html 940 Author's Address 942 Phillip Hallam-Baker 944 Email: phill@hallambaker.com