idnits 2.17.1 draft-hallambaker-mesh-cryptography-00.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 (April 4, 2019) is 1848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 647 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 April 4, 2019 4 Intended status: Informational 5 Expires: October 6, 2019 7 Mathematical Mesh Part VIII: Cryptographic Algorithms 8 draft-hallambaker-mesh-cryptography-00 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 advanced encryption services supported by the 16 Mesh. 18 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh- 20 cryptography.html [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 6, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 3 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 62 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 63 4. Key Co-Generation . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1.1. Application to Elliptic Curve systems . . . . . . . . 5 66 4.2. Implementation for Ed25519 and Ed448 . . . . . . . . . . 5 67 4.3. Example: Provisioning the Confirmation Service . . . . . 6 68 4.4. Implementation for X25519 and X448 . . . . . . . . . . . 7 69 5. Recryption . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 72 5.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 10 73 5.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 10 74 5.2.3. Message Encryption and Decryption . . . . . . . . . . 11 75 5.3. Example: Messaging group . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Key Combination . . . . . . . . . . . . . . . . . . . . . 13 81 9.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 13 84 9.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 13 85 9.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 13 86 9.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 13 87 9.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 13 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 10.2. Informative References . . . . . . . . . . . . . . . . . 14 91 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 One of the core goals of the Mesh is to move the state of the art in 97 commercial cryptography beyond that achieved in the 1990s when PKIX, 98 S/MIME and OpenPGP were first developed. While each of these 99 infrastructures and protocols has been subject to incremental 100 improvement, none has seen widespread adoption of new cryptographic 101 approaches. 103 This document describes the application of three technologies which 104 have been discussed in the cryptographic literature for many decades 105 but have not (yet) been applied to standards-based network protocols: 107 o Recryption 109 o Key Co-Generation 111 o Quantum Resistant Signatures. 113 2. Definitions 115 This section presents the related specifications and standard, the 116 terms that are used as terms of art within the documents and the 117 terms used as requirements language. 119 2.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119] . 125 2.2. Defined Terms 127 The terms of art used in this document are described in the Mesh 128 Architecture Guide [draft-hallambaker-mesh-architecture] . 130 2.3. Related Specifications 132 The architecture of the Mathematical Mesh is described in the Mesh 133 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 134 documentation set and related specifications are described in this 135 document. 137 2.4. Implementation Status 139 The implementation status of the reference code base is described in 140 the companion document [draft-hallambaker-mesh-developer] . 142 3. Recommended and Required Algorithms 144 4. Key Co-Generation 146 Public Key Co-Generation is a capability that is used in the Mesh to 147 enable provisioning of application specific private key pairs to 148 connected devices without revealing any information concerning the 149 application private key of the device. 151 For example, Alice provisions the confirmation service to her watch. 152 The provisioning device could generate a signature key for the device 153 and encrypt it under the encryption key of the device. But this 154 means that we cannot attribute signatures to the watch with absolute 155 certainty as the provisioning device has had knowledge of the watch 156 signature key. Nor do we wish to use the device signature key for 157 the confirmation 159 service. 161 Public Key Co-Generation allows an administration device to provision 162 a connected device with an application specific private key that is 163 specific to that application and no other such that the application 164 can determine the public key of the device but has no knowledge of 165 the private key. 167 Provisioning an application private key to a device requires the 168 administration device to: 170 o Generate a new application public key for the device. 172 o Construct and publish whatever application specific credentials 173 the device requires to use the application. 175 o Providing the information required to make use of the private key 176 to the device. 178 Note that while the administration device needs to know the device 179 application public key, it does not require knowledge of the device 180 application private key. 182 4.1. Mechanism 184 The Diffie Hellman key agreement and elliptic curve variants thereof 185 support properties we call the Key Combination Law and the Result 186 Combination Law. 188 Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs. 190 The Key Combination law states that we can define an operator ? such 191 that there is a keypair {Z, z} such that: 193 Z = X ? Y and z = (x + y) mod o (where o is the order of the group) 195 The Result Combination Law states that we can define an operator ? 196 such that: 198 (x ? E) ? (y ? E) = (z ? E) = (e ? Z). 200 For the Diffie Hellman system in a modular field p, o = p-1 and a ? b 201 = a ? b = a.b 203 Proof, 205 By definition, X = e^x mod p, Y = e^y mod p, Z = e^z mod p. 207 Therefore, 209 Z = e^z mod p = e^x+y mod p = (e^xe^y) mod p = e^x mod p.e^y mod p = 210 X.Y 212 A similar proof may be constructed for the operator ?. 214 4.1.1. Application to Elliptic Curve systems 216 For elliptic curve cryptosystems, the operators ? and ? are point 217 addition. 219 While the point addition function can be defined for any elliptic 220 curve system, it is not necessary to implement point addition to 221 support ECDH key agreement. 223 In particular, point multiplication using the Montgomery ladder 224 technique over Montgomery curves only operate on the x co-ordinate 225 and only require point doubling operations. For this reason, Ed448 226 and Ed25519 are the preferred algorithms for key agreement even 227 though this is not their intended purpose. 229 4.2. Implementation for Ed25519 and Ed448 231 The data structures used to implement co-generation of public keys 232 are defined in the main Mesh Reference Guide. This document 233 describes only the additional implementation details. 235 Note that the 'private key' described in [RFC8032] is in fact a seed 236 used to generate a 'secret scalar' value that is the value that has 237 the function of being the private key in the ECDH algorithm. 239 To provision a new public key to a device, the provisioning device: 241 1. Obtains the device profile of the device(s) to be provisioned to 242 determine the type of key to perform co-generation for. Let the 243 device {public, private} key be {D, d}. 245 2. Generates a private key m with the specified number of bytes (32 246 or 57]. 248 3. Calculates the corresponding public key M. 250 4. Calculates the Application public key A = D+M where + is point 251 addition. 253 5. Constructs the application device entry containing the private 254 key value m and encrypts under the device encryption key d. 256 On receipt, the device may at its option use its knowledge of the 257 secret scalar corresponding to d and m to calculate the application 258 secret scalar a or alternatively maintain the two secrets separately 259 and make use of the result combination law to perform private key 260 operations. 262 4.3. Example: Provisioning the Confirmation Service 264 For example, Alice provisions the confirmation service to her watch. 265 The device profile of the watch specifies an Ed25519 signature key. 266 Note that for production use, Ed448 is almost certainly prefered but 267 Ed25519 has the advantage of more compact presentation. 269 TBS: 271 The provisioning device could generate a signature key for the device 272 and encrypt it under the encryption key of the device. But this 273 means that we cannot attribute signatures to the watch with absolute 274 certainty as the provisioning device has had knowledge of the watch 275 signature key. Nor do we wish to use the device signature key for 276 the confirmation service. 278 Instead, the provisioning device generates a companion keypair. A 279 random seed is generated. 281 TBS: 283 A key derrivation function (HKDF) is used to derrive a 255 bit secret 284 scalar. 286 TBS: 288 The provisioning device can calculate the public key of the composite 289 keypair by adding the public keys of the device profile and the 290 companion public key: 292 TBS: 294 The provisioning device encrypts the private key of the comanion 295 keypair under the encryption key of the device. 297 TBS: 299 The provisioning device calculates the private key of the composite 300 keypair by adding the two private key values and verifies that scalar 301 multiplication of the base point returns the composite public key 302 value. 304 4.4. Implementation for X25519 and X448 306 5. Recryption 308 A key limitation of most deployed messaging systems is that true end- 309 to-end confidentiality is only achieved for a limited set of 310 communication patterns. Specifically, bilateral communications 311 (Alice sends a message to Bob) or broadcast communications to a known 312 set of recipients (Alice sends a message to Bob, Carol and Doug). 313 These capabilities do not support communication patterns where the 314 set of recipients changes over time or is confidential. Yet such 315 requirements commonly occur in situations such as sending a message 316 to a mailing list whose membership isn't known to the sender, or 317 creating a spreadsheet whose readership is to be limited to 318 authorized members of the 'accounting' team. 320 Traditional End-to-End Encryption is static. 322 The mathematical approach that makes key co-generation possible may 323 be applied to support a public key encryption mode in which 324 encryption is performed as usual but decryption requires the use of 325 multiple keys. This approach is variously described in the 326 literature as distributed key generation and proxy re- 327 encryption [Blaze98] . 329 The approach specified in this document borrows aspects of both these 330 techniques. This combined approach is called 'recryption'. Using 331 recryption allows a sender to send a message to a group of users 332 whose membership is not known to the sender at the time the message 333 is sent and can change at any time. 335 Recryption supports End-to-End Encryption in dynamic groups. 337 Proxy re-encryption provides a technical capability that meets the 338 needs of such communication patterns. Conventional symmetric key 339 cryptography uses a single key to encrypt and decrypt data. Public 340 key cryptography uses two keys, the key used to encrypt data is 341 separate from the key used to decrypt. Proxy re-encryption 342 introduces a third key (the recryption key) that allows a party to 343 permit an encrypted data packet to be decrypted using a different key 344 without permitting the data to be decrypted. 346 The introduction of a recryption key permits end-to-end 347 confidentiality to be preserved when a communication pattern requires 348 that some part of the communication be supported by a service. 350 The introduction of a third type of key, the recryption key permits 351 two new roles to be established, that of an administrator and 352 recryption service. There are thus four parties: 354 Administrator 356 Holder of Decryption Key, Creator of Recryption Keys 358 Sender 360 Holder of Encryption Key 362 Recryption Service 364 Holder of Recryption keys 366 Receiver 368 Holder of personal decryption key 370 The communication between these parties is shown in Figure X below: 372 Mesh/Recrypt Parties 374 The information stored at the recryption service is necessary but not 375 sufficient to decrypt the message. Thus, no disclosure of the 376 message plaintext occurs even in the event that an attacker gains 377 full knowledge of all the information stored by the recryption 378 service. 380 5.1. Mechanism 382 The mechanism used to support recryption is the same as the mechanism 383 used to support key co-generation except that this time, instead of 384 combining two keys to create one, the private component of a 385 decryption key (i.e. the private key) is split into two parts, a 386 recryption key and a decryption key. 388 Recall that the key combination law for Diffie Hellman crypto-systems 389 states that we can add two private keys to get a third. It follows 390 that we can split the private key portion of a keypair {G, g} into 391 two parts by choosing a random number that is less than the order of 392 the Diffie-Hellman group to be our first key x. Our second key is y 393 = g - r mod o, where o is the order of the group. 395 Having generated x, y, we can use these to perform private key 396 agreement operations on a public key E and then use the result 397 combination law to obtain the same result that we would have obtained 398 using g. 400 One means of applying this mechanism to recryption would be to 401 generate a different random value x for each member of the group and 402 store it at the recryption service and communicate the value y to the 403 member via a secure channel. Applying this approach we can clearly 404 see that the recryption service gains no information about the value 405 of the private key since the only information it holds is a random 406 number which could have been generated without any knowledge of the 407 group private key. 409 [RFC8032] requires that implementations derive the scalar secret by 410 taking a cryptographic digest of the private key. This means that 411 either the client or the service must use a non-compliant 412 implementation. Given this choice, it is preferable to require that 413 the non-standard implementation be required at the service rather 414 than the client. This limits the scope of the non-conformant key 415 derivation approach to the specialist recryption service and ensures 416 that the client enforce the requirement to generate the private key 417 component by means of a digest. 419 5.2. Implementation 421 Implementation of recryption in the Mesh has four parts: 423 o Creation and management of the recryption group. 425 o Provisioning of members to a recryption group. 427 o Message encryption. 429 o Message decryption. 431 These operations are all performed using the same catalog and 432 messaging infrastructure provided by the Mesh for other purposes. 434 Each recryption group has its own independent Mesh account. This has 435 many advantages: 437 o Administration of the recryption group may be spread across 438 multiple Mesh users or transferred from one user to another 439 without requiring specification of a separate management protocol 440 to support these operations. 442 o The recryption account address can be used by Mesh applications 443 such as group messaging, conferencing, etc. as a contact address. 445 o The contact request service can be used to notify members that 446 they have been granted membership in the group. 448 5.2.1. Group Creation 450 Creation of a Recryption group requires the steps of: 452 o Generating the recryption group key pair 454 o Creating the recryption group account 456 o Generating administrator record for each administrator. 458 o Publishing the administrator records to the recryption catalog. 460 Note that in principle, we could make use of the key combination law 461 to enable separation of duties controls on administrators so that 462 provisioning of members required multiple administrators to 463 participate in the process. This is left to future versions. 465 5.2.2. Provisioning a Member 467 To provision a user as a member of the recryption group, the 468 administrator requires their current recryption profile. The 469 administrator MAY obtain this by means of a contact service request. 470 As with any contact service request, this request is subject to 471 access control and MAY require authorization by the intended user 472 before the provisioning can proceed. 474 Having obtained the user's recryption profile, the administration 475 tool generates a decryption private key for the user and encrypts it 476 under the member's key to create the encrypted decryption key entry. 478 The administration tool then computes the secret scalar from the 479 private key and uses this together with the secret scalar of the 480 recryption group to compute the recryption key for the member. This 481 value and the encrypted decryption key entry are combined to form the 482 recryption group membership record which is published to the catalog. 484 5.2.3. Message Encryption and Decryption 486 Encryption of a messages makes use of DARE Message in exactly the 487 same manner as any other encryption. The sole difference being that 488 the recipient entry for the recryption operation MUST specify the 489 recryption group address an not just the key fingerprint. This 490 allows the recipient to determine which recryption service to contact 491 to perform the recryption operation. 493 To decrypt a message, the recipient makes an authenticated recryption 494 request to the specified recryption service specifying: 496 o The recipient entry to be used for decryption 498 o The fingerprint of the decryption key(s) the device would like to 499 make use of. 501 o Whether or not the encrypted decryption key entry should be 502 returned. 504 The recryption service searches the catalog for the corresponding 505 recryption group to find a matching entry. If found and if the 506 recipient and proposed decryption key are dully authorized for the 507 purpose, the service performs the key agreement operation using the 508 recryption key specified in the entry and returns the result to the 509 recipient. 511 The recipient then decrypts the recryption data entry using its 512 device decryption key and uses the group decryption key to calculate 513 the other half of the result. The two halves of the result are then 514 added to obtain the key agreement value that is then used to decrypt 515 the message. 517 5.3. Example: Messaging group 519 Alice creates a recryption group. The group encryption and signature 520 key parameters are: 522 TBS: 524 To verify the proper function of the group, Alice creates a test 525 message and encrypts it under the group key. 527 TBS: 528 TBS: 530 Alice decides to add Bob to the group. Bob's recryption profile is: 532 TBS: 534 The decryption key is specified in the same way as any other Ed25519 535 private key using the hash of a private key seed value: 537 TBS: 539 The the recryption key is the group secret scalar minus (mod p) the 540 secret scalar of Bob's private key: 542 TBS: 544 The Recryption entry consists of Bob's address, the recryption key 545 and the decryption key encrypted under Bob's encryption key: 547 TBS: 549 The group administration tool creates a notification request to tell 550 Bob that he has been made a member of the new group and signs it 551 using the group signature key. The recryption entry and the 552 notification are then sent to the recryption service: 554 TBS: 556 The notification message contains a link to the test message. When 557 he accepts membership of the group, Bob clicks on the link to test 558 that his membership has been fully provisioned. Providing an 559 explicit test mechanism avoids the problem that might otherwise occur 560 in which the message spool fills up with test messages being posted. 562 Bob's Web browser requests the recryption data for the test message. 563 The request is authenticated and encrypted under Bob's device keys. 564 The plaintext of the message is: 566 TBS: 568 The plaintext of the response contains the additional information 569 Bob's Web browser needs to complete the decryption process: 571 TBS: 573 The Web browser decrypts the private key and uses it to calculate the 574 decryption value: 576 TBS: 578 The key agreement value is obtained by point addition of the 579 recryption and decryption values: 581 TBS: 583 This value allows the test message to be decrypted. 585 6. Security Considerations 587 The security considerations for use and implementation of Mesh 588 services and applications are described in the Mesh Security 589 Considerations guide [draft-hallambaker-mesh-security] . 591 7. IANA Considerations 593 All the IANA considerations for the Mesh documents are specified in 594 this document 596 8. Acknowledgements 598 9. Examples 600 9.1. Key Combination 602 9.1.1. Ed25519 604 9.1.2. Ed448 606 9.1.3. X25519 608 9.1.4. X448 610 9.2. Group Encryption 612 9.2.1. X25519 614 9.2.2. X448 616 10. References 618 10.1. Normative References 620 [draft-hallambaker-mesh-security] 621 "[Reference Not Found!]". 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997. 627 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 628 Signature Algorithm (EdDSA)", RFC 8032, 629 DOI 10.17487/RFC8032, January 2017. 631 10.2. Informative References 633 [Blaze98] "[Reference Not Found!]". 635 [draft-hallambaker-mesh-architecture] 636 Hallam-Baker, P., "Mathematical Mesh Part I: Architecture 637 Guide", draft-hallambaker-mesh-architecture-06 (work in 638 progress), August 2018. 640 [draft-hallambaker-mesh-developer] 641 Hallam-Baker, P., "Mathematical Mesh: Reference 642 Implementation", draft-hallambaker-mesh-developer-07 (work 643 in progress), April 2018. 645 10.3. URIs 647 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 648 cryptography.html 650 Author's Address 652 Phillip Hallam-Baker 654 Email: phill@hallambaker.com