idnits 2.17.1 draft-hallambaker-mesh-cryptography-05.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 document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 January 2020) is 1561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft 16 January 2020 4 Intended status: Informational 5 Expires: 19 July 2020 7 Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms 8 draft-hallambaker-mesh-cryptography-05 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. 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 19 July 2020. 46 Copyright Notice 48 Copyright (c) 2020 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 (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 64 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 65 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 66 3.1. Mesh Device . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Constrained Device . . . . . . . . . . . . . . . . . . . 5 68 4. Multi-Party Cryptography . . . . . . . . . . . . . . . . . . 6 69 4.1. Application to Diffie Hellman (not normative) . . . . . . 6 70 4.2. Multi-Party Key Generation . . . . . . . . . . . . . . . 6 71 4.3. Multi-Party Decryption . . . . . . . . . . . . . . . . . 7 72 4.4. Mutually Authenticated Key Exchange. . . . . . . . . . . 7 73 4.5. Implementation . . . . . . . . . . . . . . . . . . . . . 7 74 4.5.1. Implementation for Ed25519 and Ed448 . . . . . . . . 8 75 4.5.2. Implementation for X25519 and X448 . . . . . . . . . 8 76 5. Multi-Party Key Generation . . . . . . . . . . . . . . . . . 9 77 5.1. Example: Provisioning the Confirmation Service . . . . . 9 78 6. Multi-Party Decryption . . . . . . . . . . . . . . . . . . . 11 79 6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13 81 6.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 13 82 6.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 14 83 6.2.3. Message Encryption and Decryption . . . . . . . . . . 14 84 6.3. Example: Messaging group . . . . . . . . . . . . . . . . 15 85 7. Mutually Authenticated Key Agreement . . . . . . . . . . . . 17 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 11.1. Key Combination . . . . . . . . . . . . . . . . . . . . 19 91 11.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . 19 92 11.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . 19 93 11.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19 95 11.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 19 96 11.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19 97 11.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19 98 12. Normative References . . . . . . . . . . . . . . . . . . . . 19 99 13. Informative References . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 This document describes the cryptographic algorithm suites used in 104 the Mesh and the implementation of Multi-Party Encryption and Multi- 105 Party Key Generation used in the Mesh. 107 To allow use of Mesh capabilities on the least capable computing 108 devices currently in use, separate schedules of recommended and 109 required algorithms are specified for Standard Devices and 110 Constrained Devices. 112 The Constrained device class may be considered to include most 8-bit 113 CPUs equipped with sufficient memory to support the necessary 114 operations. For example an Ardunino Mega 2560 which can perform ECDH 115 key agreement and signature operations in times ranging from 3 to 8 116 seconds. While such a device is clearly not suited to perform such 117 operations routinely, a one-time connection process that takes 118 several minutes to complete need not be of major concern. 120 The Standard device class may be considered to include the vast 121 majority of general purpose and personal computing devices 122 manufactured since 2010. Even a Raspberry Pi Zero which currently 123 retails at $5 is capable of performing the cryptographic functions 124 required to implement the Mesh with negligible impact on the user. 126 2. Definitions 128 This section presents the related specifications and standard, the 129 terms that are used as terms of art within the documents and the 130 terms used as requirements language. 132 2.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2.2. Defined Terms 140 The terms of art used in this document are described in the _Mesh 141 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 143 2.3. Related Specifications 145 The architecture of the Mathematical Mesh is described in the _Mesh 146 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 147 documentation set and related specifications are described in this 148 document. 150 2.4. Implementation Status 152 The implementation status of the reference code base is described in 153 the companion document [draft-hallambaker-mesh-developer]. 155 3. Recommended and Required Algorithms 157 To allow implementation of Mesh capabilities on the widest possible 158 range of devices, separate algorithm requirements and recommendations 159 are specified for four classes of device: 161 Administration Device A general-purpose computing device that is 162 used for Mesh administration functions. 164 Mesh Device A general-purpose computing device that is not used for 165 Mesh administration functions with sufficient memory and 166 processing power to perform public key cryptography operations 167 without paying particular attention to the impact on performance. 169 Constrained Device An embedded computing device with limited memory 170 and computing power that offers sufficient processing capabilities 171 to perform occasional public key operations (e.g. during device 172 initialization) but is not suited to repeated operations. 174 Bridge Device A trusted device that enables Mesh Devices to 175 interoperate with Constrained devices. 177 Since Administration Devices and Mesh Devices MUST support 178 communication with Mesh Devices and Constrained devices, they MUST 179 meet all the REQUIRED algorithms for both types of device. 181 3.1. Mesh Device 183 Support for the following algorithms is REQUIRED: 185 * SHA-2-512 [SHA-2] 187 * HMAC-SHA-2-512 [RFC2104] 189 * HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 190 * AES-CBC-256 Encryption [FIPS197] 192 * Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 194 * Montgomery Curve Diffie-Hellman Key Agreement X25519 and X448 195 [RFC7748] 197 * Edwards-Curve Digital Signature Algorithm Ed25519 and Ed448 198 [RFC8032] 200 Support for the following algorithms is RECOMMENDED: 202 * AES-GCM-256 Encryption [AES-GCM] 204 * SHA-3-512 [SHA-3] 206 * KMAC SHA-3-512 [SHA-3-Derived] 208 While the use of GCM is generally preferred over CBC mode in IETF 209 security protocols, this mode is not currently supported by the 210 reference implementation platform. 212 3.2. Constrained Device 214 Support for the following algorithms is REQUIRED: 216 * SHA-2-512 [SHA-2] 218 * HMAC-SHA-2-512 [RFC2104] 220 * HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 222 * Poly1035 Authenticated Encryption [RFC8439] 224 * ChaCha20 Encryption [RFC8439] 226 * Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 228 * Edwards-Curve Digital Signature Algorithm Ed25519 [RFC8032] 230 * Edwards-Curve Diffie-Hellman Key Agreement Ed25519 [RFC8032] 232 Use of the Edwards Curves for Signature and Key Agreement allows both 233 functions to be supported by a single library with no reduction in 234 security. 236 4. Multi-Party Cryptography 238 The multi-party key generation and multi-party decryption mechanisms 239 used in the Mesh protocols are made possible by the fact that Diffie 240 Hellman key agreement and elliptic curve variants thereof support 241 properties we call the Key Combination Law and the Result Combination 242 Law. 244 Let {_X_, _x_}, {_Y_, _y_}, {_E_, _e_} be {public, private} key 245 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 251 of the group) 253 The Result Combination Law states that we can define an operator ? 254 such that: 256 (_x_ ? _E_) ? (_y_ ? _E_) = (_z_ ? _E_) = (_e_ ? _Z_). 258 4.1. Application to Diffie Hellman (not normative) 260 For the Diffie Hellman system in a modular field p, o = p-1 and _a_? 261 _b_ = _a_? _b_ = _a_._b_mod _p_. 263 _Proof:_ 265 By definition, X = e^(x) mod p, Y = e^(y) mod p, and Z = e^(z)mod p. 267 Therefore, 269 Z = e^(z) mod p = e^(x+y) mod p = (e^(x)e^(y)) mod p = e^(x)mod 270 p.e^(y) mod p = X.Y 272 A similar proof may be constructed for the operator ?. 274 4.2. Multi-Party Key Generation 276 The Key Combination Law provides the basis for the Key Co-Generation 277 technique used to ensure that the cryptographic keys used in devices 278 connected to a Mesh profile are sufficiently random and have not been 279 compromised by malware or other 'backdoor' compromise to the machine 280 during or after manufacture. 282 For the Diffie Hellman system, the Key Combination law provides all 283 the mechanism needed to implement a Key Co-Generation mechanism. If 284 the Device key is {_X_, _x_}, the administration device can generate 285 a Co-Generation Key Pair {_Y_, _y_} and generate a Device Connection 286 Assertion for the final public key E calculated from knowledge of X 287 and Y alone. Passing the value _y_ to the device (using a secure 288 channel) allows it to calculate the corresponding private key _e_ 289 required to make use of the Device Connection Assertion. 291 This approach ensures that a party with knowledge of either _x_ or 292 _y_ but not both obtains no knowledge of _e_. 294 Section REF _Ref5309729 \w \h 5 describes the implementation of these 295 schemes in the Mesh 297 4.3. Multi-Party Decryption 299 The Key Combination Law and Result Combination Law provide the basis 300 for the Multi-Party Decryption technique used to support Mesh 301 Encryption Groups. 303 Section REF _Ref5309538 \w \h 6 describes the application of this 304 technique in the Mesh 306 4.4. Mutually Authenticated Key Exchange. 308 The Result Combination Law is used to provide a Key Exchange 309 mechanism that provides mutual authentication of the parties while 310 preserving forward secrecy. 312 4.5. Implementation 314 For elliptic curve cryptosystems, the operators ? and ? are point 315 addition. 317 Implementing a robust Key Co-Generation for the Elliptic Curve 318 Cryptography schemes described in [RFC7748] and [RFC8032] requires 319 some additional considerations to be addressed. 321 * The secret scalar used in the EdDSA algorithm is calculated from 322 the private key using a digest function. It is therefore 323 necessary to specify the Key Co-Generation mechanism by reference 324 to operations on the secret scalar values rather than operations 325 on the private keys. 327 * The Montgomery Ladder traditionally used to perform X25519 and 328 X448 point multiplication does not require implementation of a 329 function to add two arbitrary points. While the steps required to 330 create such a function are fully constrained by the specification, 331 the means of satisfying the constraints is not. 333 4.5.1. Implementation for Ed25519 and Ed448 335 The data structures used to implement co-generation of public keys 336 are defined in the main Mesh Reference Guide. This document 337 describes only the additional implementation details. 339 Note that the 'private key' described in [RFC8032] is in fact a seed 340 used to generate a 'secret scalar' value that is the value that has 341 the function of being the private key in the ECDH algorithm. 343 To provision a new public key to a device, the provisioning device: 345 0. Obtains the device profile of the device(s) to be provisioned to 346 determine the type of key to perform co-generation for. Let the 347 device {public, private} key be {D, d}. 349 1. Generates a private key _m_ with the specified number of bytes 350 (32 or 57]. 352 2. Calculates the corresponding public key _M_. 354 3. Calculates the Application public key A = D+M where + is point 355 addition. 357 4. Constructs the application device entry containing the private 358 key value m and encrypts under the device encryption key d. 360 On receipt, the device may at its option use its knowledge of the 361 secret scalar corresponding to d and m to calculate the application 362 secret scalar a or alternatively maintain the two secrets separately 363 and make use of the result combination law to perform private key 364 operations. 366 4.5.2. Implementation for X25519 and X448 368 While the point addition function can be defined for any elliptic 369 curve system, it is not necessary to implement point addition to 370 support ECDH key agreement. 372 In particular, point multiplication using the Montgomery ladder 373 technique over Montgomery curves only operate on the x co-ordinate 374 and only require point doubling operations. 376 For expediency, the current implementation of the Mesh reference code 377 uses the Edwards curves for both signature and encryption pending 378 announcement of platform support for both algorithms. 380 5. Multi-Party Key Generation 382 Multi-Party Key Generation is a capability that is used in the Mesh 383 to enable provisioning of application specific private key pairs to 384 connected devices without revealing any information concerning the 385 application private key of the device. 387 For example, Alice provisions the confirmation service to her watch. 388 The provisioning device could generate a signature key for the device 389 and encrypt it under the encryption key of the device. But this 390 means that we cannot attribute signatures to the watch with absolute 391 certainty as the provisioning device has had knowledge of the watch 392 signature key. Nor do we wish to use the device signature key for 393 the confirmation service. 395 Multi-Party Key Generation allows an administration device to 396 provision a connected device with an application specific private key 397 that is specific to that application and no other such that the 398 application can determine the public key of the device but has no 399 knowledge of the private key. 401 Provisioning an application private key to a device requires the 402 administration device to: 404 * Generate a new application public key for the device. 406 * Construct and publish whatever application specific credentials 407 the device requires to use the application. 409 * Providing the information required to make use of the private key 410 to the device. 412 Note that while the administration device needs to know the device 413 application public key, it does not require knowledge of the device 414 application private key. 416 5.1. Example: Provisioning the Confirmation Service 418 For example, Alice provisions the confirmation service to her watch. 419 The device profile of the watch specifies an Ed25519 signature key. 420 Note that for production use, Ed448 is almost certainly prefered but 421 Ed25519 has the advantage of more compact presentation. 423 Device Key 425 UDF Seed: ZAAA-G4F5-G34W-HHLC-24AP-SZKI-VGO7-UHI 426 Private Key: 427 B7 48 FF 8A 1B D2 04 BC BA 53 70 80 91 66 08 8E 428 26 15 B5 52 ED C9 C4 CE 80 D7 75 A6 BD A9 4A 1C 429 Secret Scalar: 430 561256512376003542287986996396194037798558214965969766613823935719031 431 34631504 432 Public Key: 433 2B B3 8F D1 93 16 E1 5E 24 44 BA 82 9F 4A D3 7D 434 F6 7F B5 A0 92 65 A1 7B F4 8C B6 51 6D F3 9F DC 435 Fingerprint: MANZ-N7DM-BYZH-EQIO-E7YL-C6SX-GONP 437 The provisioning device could generate a signature key for the device 438 and encrypt it under the encryption key of the device. But this 439 means that we cannot attribute signatures to the watch with absolute 440 certainty as the provisioning device has had knowledge of the watch 441 signature key. Nor do we wish to use the device signature key for 442 the confirmation service. 444 Instead, the provisioning device generates an overlay keypair: 446 Device Key 448 UDF Seed: ZAAA-HIGJ-GGBY-NTBF-YS2T-ABNO-4WT2-SIY 449 Private Key: 450 F9 44 69 38 A7 E2 52 A1 F6 1D 9D 9B 29 D1 5D 52 451 77 23 26 0C AF F3 14 A6 4E 95 CB 76 5B 24 B1 67 452 Secret Scalar: 453 494374318308300050435542868433885510572653196058722477545726317545719 454 97461496 455 Public Key: 456 C7 EF 8B 19 BE D9 E7 F7 45 17 73 8E B3 92 6E 86 457 C2 0F A4 06 84 58 BF 3B FE EE 87 A5 B8 EB 62 0A 458 Fingerprint: MBQO-UETO-EL5H-EQBI-PM4Y-QOE7-E6PH 460 The provisioning device can calculate the public key of the composite 461 keypair by adding the public keys of the device profile and the 462 companion public key: 464 Composite public key = Device + Overlay: 465 0A FD 34 5B D7 49 47 BF C3 CC 2E 4B AB A6 BF FE 466 E1 7A B1 3C 74 C6 49 EE 04 9C FF C0 4B D3 05 F6 467 Fingerprint: MBAK-3KK5-F3AN-E6AJ-EIIT-IIL6-7KTP 469 The provisioning device encrypts the private key of the comanion 470 keypair (or the seed from which it was generated) under the 471 encryption key of the device. 473 The provisioning device calculates the private key of the composite 474 keypair by adding the two private key values modulo the order of the 475 group and verifies that scalar multiplication of the base point 476 returns the composite public key value. 478 Composite Secret Scalar = Device + Overlay: 479 369621881521677524799960083359389394685489760249533923273552306952445 480 5498173 481 Fingerprint: MBAK-3KK5-F3AN-E6AJ-EIIT-IIL6-7KTP 483 6. Multi-Party Decryption 485 A key limitation of most deployed messaging systems is that true end- 486 to-end confidentiality is only achieved for a limited set of 487 communication patterns. Specifically, bilateral communications 488 (Alice sends a message to Bob) or broadcast communications to a known 489 set of recipients (Alice sends a message to Bob, Carol and Doug). 490 These capabilities do not support communication patterns where the 491 set of recipients changes over time or is confidential. Yet such 492 requirements commonly occur in situations such as sending a message 493 to a mailing list whose membership isn't known to the sender, or 494 creating a spreadsheet whose readership is to be limited to 495 authorized members of the 'accounting' team. 497 The mathematical approach that makes key co-generation possible may 498 be applied to support a public key encryption mode in which 499 encryption is performed as usual but decryption requires the use of 500 multiple keys. This approach is variously described in the 501 literature as distributed key generation and proxy re-encryption 502 [Blaze98]. 504 The approach specified in this document borrows aspects of both these 505 techniques. This combined approach is called 'recryption'. Using 506 recryption allows a sender to send a message to a group of users 507 whose membership is not known to the sender at the time the message 508 is sent and can change at any time. 510 Proxy re-encryption provides a technical capability that meets the 511 needs of such communication patterns. Conventional symmetric key 512 cryptography uses a single key to encrypt and decrypt data. Public 513 key cryptography uses two keys, the key used to encrypt data is 514 separate from the key used to decrypt. Proxy re-encryption 515 introduces a third key (the recryption key) that allows a party to 516 permit an encrypted data packet to be decrypted using a different key 517 without permitting the data to be decrypted. 519 The introduction of a recryption key permits end-to-end 520 confidentiality to be preserved when a communication pattern requires 521 that some part of the communication be supported by a service. 523 The introduction of a third type of key, the recryption key permits 524 two new roles to be established, that of an administrator and 525 recryption service. There are thus four parties: 527 Administrator Holder of Decryption Key, Creator of Recryption Keys 529 Sender Holder of Encryption Key 531 Recryption Service Holder of Recryption keys 533 Receiver Holder of personal decryption key 535 The information stored at the recryption service is necessary but not 536 sufficient to decrypt the message. Thus, no disclosure of the 537 message plaintext occurs even in the event that an attacker gains 538 full knowledge of all the information stored by the recryption 539 service. 541 6.1. Mechanism 543 The mechanism used to support recryption is the same as the mechanism 544 used to support key co-generation except that this time, instead of 545 combining two keys to create one, the private component of a 546 decryption key (i.e. the private key) is split into two parts, a 547 recryption key and a decryption key. 549 Recall that the key combination law for Diffie Hellman crypto-systems 550 states that we can add two private keys to get a third. It follows 551 that we can split the private key portion of a keypair {_G_, _g_} 552 into two parts by choosing a random number that is less than the 553 order of the Diffie-Hellman group to be our first key _x_. Our second 554 key is _y_ = _g_ - _r_ mod _o_, where _o_ is the order of the group. 556 Having generated _x_, _y_, we can use these to perform private key 557 agreement operations on a public key _E_ and then use the result 558 combination law to obtain the same result that we would have obtained 559 using _g_. 561 One means of applying this mechanism to recryption would be to 562 generate a different random value x for each member of the group and 563 store it at the recryption service and communicate the value y to the 564 member via a secure channel. Applying this approach, we can clearly 565 see that the recryption service gains no information about the value 566 of the private key since the only information it holds is a random 567 number which could have been generated without any knowledge of the 568 group private key. 570 [RFC8032] requires that implementations derive the scalar secret by 571 taking a cryptographic digest of the private key. This means that 572 either the client or the service must use a non-compliant 573 implementation. Given this choice, it is preferable to require that 574 the non-standard implementation be required at the service rather 575 than the client. This limits the scope of the non-conformant key 576 derivation approach to the specialist recryption service and ensures 577 that the client enforce the requirement to generate the private key 578 component by means of a digest. 580 6.2. Implementation 582 Implementation of recryption in the Mesh has four parts: 584 * Creation and management of the recryption group. 586 * Provisioning of members to a recryption group. 588 * Message encryption. 590 * Message decryption. 592 These operations are all performed using the same catalog and 593 messaging infrastructure provided by the Mesh for other purposes. 595 Each recryption group has its own independent Mesh account. This has 596 many advantages: 598 * Administration of the recryption group may be spread across 599 multiple Mesh users or transferred from one user to another 600 without requiring specification of a separate management protocol 601 to support these operations. 603 * The recryption account address can be used by Mesh applications 604 such as group messaging, conferencing, etc. as a contact address. 606 * The contact request service can be used to notify members that 607 they have been granted membership in the group. 609 6.2.1. Group Creation 611 Creation of a Recryption group requires the steps of: 613 * Generating the recryption group key pair 614 * Creating the recryption group account 616 * Generating administrator record for each administrator. 618 * Publishing the administrator records to the recryption catalog. 620 Note that in principle, we could make use of the key combination law 621 to enable separation of duties controls on administrators so that 622 provisioning of members required multiple administrators to 623 participate in the process. This is left to future versions. 625 6.2.2. Provisioning a Member 627 To provision a user as a member of the recryption group, the 628 administrator requires their current recryption profile. The 629 administrator MAY obtain this by means of a contact service request. 630 As with any contact service request, this request is subject to 631 access control and MAY require authorization by the intended user 632 before the provisioning can proceed. 634 Having obtained the user's recryption profile, the administration 635 tool generates a decryption private key for the user and encrypts it 636 under the member's key to create the encrypted decryption key entry. 638 The administration tool then computes the secret scalar from the 639 private key and uses this together with the secret scalar of the 640 recryption group to compute the recryption key for the member. This 641 value and the encrypted decryption key entry are combined to form the 642 recryption group membership record which is published to the catalog. 644 6.2.3. Message Encryption and Decryption 646 Encryption of a messages makes use of DARE Message in exactly the 647 same manner as any other encryption. The sole difference being that 648 the recipient entry for the recryption operation MUST specify the 649 recryption group address an not just the key fingerprint. This 650 allows the recipient to determine which recryption service to contact 651 to perform the recryption operation. 653 To decrypt a message, the recipient makes an authenticated recryption 654 request to the specified recryption service specifying: 656 * The recipient entry to be used for decryption 658 * The fingerprint of the decryption key(s) the device would like to 659 make use of. 661 * Whether or not the encrypted decryption key entry should be 662 returned. 664 The recryption service searches the catalog for the corresponding 665 recryption group to find a matching entry. If found and if the 666 recipient and proposed decryption key are dully authorized for the 667 purpose, the service performs the key agreement operation using the 668 recryption key specified in the entry and returns the result to the 669 recipient. 671 The recipient then decrypts the recryption data entry using its 672 device decryption key and uses the group decryption key to calculate 673 the other half of the result. The two halves of the result are then 674 added to obtain the key agreement value that is then used to decrypt 675 the message. 677 6.3. Example: Messaging group 679 NB: The current code implements encryption in the Elliptic Curve 680 Ed25519, not the Montgomery Curve X.25519 as it should. This will be 681 lifted in the near future. 683 Alice creates an encryption keypair. 685 Group Key: 686 51 C5 D1 84 5F C3 31 97 D3 80 2A 25 CE 7F 82 AF 687 F0 30 5B 7D 52 D0 B6 CE 3C 1C 95 A0 33 CB 89 98 688 Value: 689 322319593526028683147256399641007608894514778179691781946528967784218 690 52742616 692 To verify the proper function of the group, Alice creates a test 693 message and encrypts it under the group key. 695 Message = This is a test as UTF8: 696 54 68 69 73 20 69 73 20 61 20 74 65 73 74 698 [{ 699 "enc": "A256CBC", 700 "Salt": "KDsofrPkFsnlhRsVaxPvvA", 701 "recipients": [{ 702 "kid": "MCGR-HO5N-2FPS-VUFQ-DEKF-7TRA-JHM6", 703 "epk": { 704 "PublicKeyECDH": { 705 "crv": "Ed25519", 706 "Public": "wKdpaMbC5sF8moAusBtJlZ9XRetMzOhfb3pnW0F_uIw"}} 707 , 708 "wmk": "Z0JQvs1BtVDcRDow6hDV47wPiymwn0ybJEXkteYbaSNByhLxGKf3c 709 A"}]}, 710 "SUXu-b3kAgMzly2_HQZjGg"] 712 Alice decides to add Bob to the group. She creates an encryption key 713 for Bob: The decryption key is specified in the same way as any other 714 Ed25519 private key using the hash of a private key seed value: 716 Bob's Member Key: 717 C1 3D 09 F2 D0 46 2B ED 34 43 A2 06 EB C9 C5 6D 718 68 92 08 3C 31 FC E7 35 EB 3D 65 82 82 66 92 1C 719 Value: 720 397652973877671772297984793967578734933293251919295536394239116455044 721 36683984 723 The the recryption key is the group secret scalar minus (mod p) the 724 secret scalar of Bob's private key: 726 Bob's Service Key: 727 [Not specified as a digest input value] 728 Value: 729 694067311950021551287353369342887587783638534479943976723288700948832 730 4560610 732 To decrypt: 734 Member Agreement Value: 735 B2 DB FC 97 A5 D9 14 FB B9 47 85 A0 DF 74 44 31 736 0B 28 64 EE 6C C3 97 BF FA 6A 39 05 16 07 70 0F 738 Service Agreement Value: 739 74 E2 28 0B FF 65 50 5B A9 10 87 14 0C C8 91 DB 740 6B FE CF 82 CC C9 10 C0 0E 93 05 14 CD 81 28 39 742 Key Agreement IKM: 743 2A 22 97 20 56 77 8D 13 F1 35 C9 5E 5A 5B 93 B0 744 4A 18 D5 90 B2 C6 40 3F 9F 2A 9E 3D 9E D3 E4 49 746 This value allows the test message to be decrypted. 748 7. Mutually Authenticated Key Agreement 750 Diffie Hellman key agreement using the authenticated public keys of 751 the principals provides mutual authentication of those principals. 753 For example, if Alice's key pair is {_a_, _A_} and Bob's key pair is 754 {_b_, _B_}, the Diffie Hellman key agreement value _DH_ (_a_, _B_) = 755 _DH_ (_b_, _A_) can only be generated from the public information if 756 _a_ or _b_ is known. 758 The chief disadvantage of this approach is that it only allows Alice 759 and Bob to establish a single shared secret that will never vary and 760 does not provide forward secrecy. To avoid this, cryptographic 761 protocols usually perform the key agreement against an ephemeral key 762 and either accept that the client key is not authenticated or perform 763 multiple key agreements and combine the results. 765 Using the Result Combination Law allows a key agreement mechanism to 766 combine the benefits of mutual authentication with the use of 767 ephemeral keys without the need for multiple private key operations 768 or additional round trips. 770 In its simplest form, the key exchange has two parties which we refer 771 to as the client and the server. The client being the party that 772 initiates the protocol exchange and the server being the party that 773 responds. Let the public key pair of the client be {_a_, _A_} and 774 that of the server {_b_, _B_}. 776 Two versions of the key agreement mechanism are specified: 778 Client ephemeral The client contributes an ephemeral key pair 779 {_n_(A)_, _N_(A)_}. The effective public key of the client is _A_ 780 ? _N_(A)_. 782 The server uses its public key _B_. 784 The key agreement value is _DH_(_a_ + _n_(A)_, B) = _DH_ (_b_, _A_ 785 ? _N_(A)_) 787 Dual ephemeral The client contributes an ephemeral key pair 788 {_n_(A)_, _N_(A)_}. The effective public key of the client is _A_ 789 ? _N_(A)_. 791 The server contributes an ephemeral key pair {_n_(B)_, _N_(B)_}. 792 The effective public key of the client is _B_ ? _N_(B)_. 794 The key agreement value is _DH_(_a_ + _n_(A)_, _B_ ? _N_(B)_) = 795 _DH_ (_b_ + _n_(B)_, _A_ ? _N_(A)_) 797 The function of the ephemeral key is effectively that of a nonce but 798 it is shared with the counter-party as a public key value. 800 The dual ephemeral approach has the advantage that it limits the 801 scope for side channel attacks as both sides have contributed unknown 802 information to the key agreement value. The disadvantage of this 803 approach is that the key agreement value can only be calculated after 804 the server has provided its ephemeral. 806 Implementations MAY take advantage of the result combination law to 807 enable private key operations involving the authenticated key (or a 808 contribution to it) to be performed in trustworthy hardware. 810 An advantage of this key exchange mechanism over the traditional TLS 811 key exchange approach is that no signature operation is involved, 812 thus ensuring that either party can repudiate the exchange and thus 813 the claim that they were in communication. 815 The master secret is calculated from the key agreement value in the 816 usual fashion. For ECDH algorithms, this comprises the steps of 817 converting the key agreement value to an octet string which forms the 818 input to a Key Derivation Function. 820 8. Security Considerations 822 The security considerations for use and implementation of Mesh 823 services and applications are described in the Mesh Security 824 Considerations guide [draft-hallambaker-mesh-security]. 826 9. IANA Considerations 828 This document requires no IANA actions. 830 10. Acknowledgements 832 A list of people who have contributed to the design of the Mesh is 833 presented in [draft-hallambaker-mesh-architecture]. 835 11. Examples 837 11.1. Key Combination 839 11.1.1. Ed25519 841 11.1.2. Ed448 843 11.1.3. X25519 845 11.1.4. X448 847 11.2. Group Encryption 849 11.2.1. X25519 851 11.2.2. X448 853 12. Normative References 855 [AES-GCM] Dworkin, M. J., "Recommendation for Block Cipher Modes of 856 Operation: Galois/Counter Mode (GCM) and GMAC", November 857 2007. 859 [draft-hallambaker-mesh-architecture] 860 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 861 Architecture Guide", Work in Progress, Internet-Draft, 862 draft-hallambaker-mesh-architecture-12, 16 January 2020, 863 . 866 [draft-hallambaker-mesh-security] 867 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 868 Security Considerations", Work in Progress, Internet- 869 Draft, draft-hallambaker-mesh-security-02, 23 October 870 2019, . 873 [FIPS197] NIST, "Advanced Encryption Standard (AES)", November 2001. 875 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 876 Hashing for Message Authentication", RFC 2104, 877 DOI 10.17487/RFC2104, February 1997, 878 . 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, 882 DOI 10.17487/RFC2119, March 1997, 883 . 885 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 886 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 887 September 2002, . 889 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 890 Key Derivation Function (HKDF)", RFC 5869, 891 DOI 10.17487/RFC5869, May 2010, 892 . 894 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 895 for Security", RFC 7748, DOI 10.17487/RFC7748, January 896 2016, . 898 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 899 Signature Algorithm (EdDSA)", RFC 8032, 900 DOI 10.17487/RFC8032, January 2017, 901 . 903 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 904 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 905 . 907 [SHA-2] NIST, "Secure Hash Standard", August 2015. 909 [SHA-3] Dworkin, M. J., "SHA-3 Standard: Permutation-Based Hash 910 and Extendable-Output Functions", August 2015. 912 [SHA-3-Derived] 913 Kelsey, J. M., Chang, S. H., and R. A. Perlner, "SHA-3 914 Derived Functions: cSHAKE, KMAC, TupleHash and 915 ParallelHash SHARE", December 2016. 917 13. Informative References 919 [Blaze98] "[Reference Not Found!]". 921 [draft-hallambaker-mesh-developer] 922 Hallam-Baker, P., "Mathematical Mesh: Reference 923 Implementation", Work in Progress, Internet-Draft, draft- 924 hallambaker-mesh-developer-09, 23 October 2019, 925 .