Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 January 2021.¶

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

This document describes the cryptographic algorithm suites used in the Mesh and the implementation of Multi-Party Encryption and Multi-Party Key Generation used in the Mesh.¶

To allow use of Mesh capabilities on the least capable computing devices currently in use, separate schedules of recommended and required algorithms are specified for Standard Devices and Constrained Devices.¶

The Constrained device class may be considered to include most 8-bit CPUs equipped with sufficient memory to support the necessary operations. For example an Ardunino Mega 2560 which can perform ECDH key agreement and signature operations in times ranging from 3 to 8 seconds. While such a device is clearly not suited to perform such operations routinely, a one-time connection process that takes several minutes to complete need not be of major concern.¶

The Standard device class may be considered to include the vast majority of general purpose and personal computing devices manufactured since 2010. Even a Raspberry Pi Zero which currently retails at $5 is capable of performing the cryptographic functions required to implement the Mesh with negligible impact on the user.¶

2. Definitions

This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶

3. Recommended and Required Algorithms

To allow implementation of Mesh capabilities on the widest possible range of devices, separate algorithm requirements and recommendations are specified for four classes of device:¶

Administration Device

A general-purpose computing device that is used for Mesh administration functions.¶

Mesh Device

A general-purpose computing device that is not used for Mesh administration functions with sufficient memory and processing power to perform public key cryptography operations without paying particular attention to the impact on performance.¶

Constrained Device

An embedded computing device with limited memory and computing power that offers sufficient processing capabilities to perform occasional public key operations (e.g. during device initialization) but is not suited to repeated operations.¶

Bridge Device

A trusted device that enables Mesh Devices to interoperate with Constrained devices.¶

Since Administration Devices and Mesh Devices MUST support communication with Mesh Devices and Constrained devices, they MUST meet all the REQUIRED algorithms for both types of device.¶

4. Multi-Party Cryptography

The multi-party key generation and multi-party decryption mechanisms used in the Mesh protocols are made possible by the fact that Diffie Hellman key agreement and elliptic curve variants thereof support properties we call the Key Combination Law and the Result Combination Law.¶

Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs.¶

The Key Combination law states that we can define an operator ? such that there is a keypair {Z, z} such that:¶

Z = X ? Y and z = (x + y) mod o (where o is the order of the group)¶

The Result Combination Law states that we can define an operator ? such that:¶

(x ? E) ? (y ? E) = (z ? E) = (e ? Z).¶

5. Multi-Party Key Generation

Multi-Party Key Generation is a capability that is used in the Mesh to enable provisioning of application specific private key pairs to connected devices without revealing any information concerning the application private key of the device.¶

For example, Alice provisions the confirmation service to her watch. The provisioning device could generate a signature key for the device and encrypt it under the encryption key of the device. But this means that we cannot attribute signatures to the watch with absolute certainty as the provisioning device has had knowledge of the watch signature key. Nor do we wish to use the device signature key for the confirmation service.¶

Multi-Party Key Generation allows an administration device to provision a connected device with an application specific private key that is specific to that application and no other such that the application can determine the public key of the device but has no knowledge of the private key.¶

Provisioning an application private key to a device requires the administration device to:¶

• Generate a new application public key for the device.¶
• Construct and publish whatever application specific credentials the device requires to use the application.¶
• Providing the information required to make use of the private key to the device.¶

Note that while the administration device needs to know the device application public key, it does not require knowledge of the device application private key.¶

Device Key

UDF Seed:       ZAAA-G4F5-G34W-HHLC-24AP-SZKI-VGO7-UHI
Private Key:
  B7 48 FF 8A  1B D2 04 BC  BA 53 70 80  91 66 08 8E
  26 15 B5 52  ED C9 C4 CE  80 D7 75 A6  BD A9 4A 1C
Secret Scalar:
561256512376003542287986996396194037798558214965969766613823935719031
    34631504
Public Key:
  2B B3 8F D1  93 16 E1 5E  24 44 BA 82  9F 4A D3 7D
  F6 7F B5 A0  92 65 A1 7B  F4 8C B6 51  6D F3 9F DC
Fingerprint:    MANZ-N7DM-BYZH-EQIO-E7YL-C6SX-GONP

Device Key

UDF Seed:       ZAAA-HIGJ-GGBY-NTBF-YS2T-ABNO-4WT2-SIY
Private Key:
  F9 44 69 38  A7 E2 52 A1  F6 1D 9D 9B  29 D1 5D 52
  77 23 26 0C  AF F3 14 A6  4E 95 CB 76  5B 24 B1 67
Secret Scalar:
494374318308300050435542868433885510572653196058722477545726317545719
    97461496
Public Key:
  C7 EF 8B 19  BE D9 E7 F7  45 17 73 8E  B3 92 6E 86
  C2 0F A4 06  84 58 BF 3B  FE EE 87 A5  B8 EB 62 0A
Fingerprint:    MBQO-UETO-EL5H-EQBI-PM4Y-QOE7-E6PH

Composite public key = Device + Overlay:
  0A FD 34 5B  D7 49 47 BF  C3 CC 2E 4B  AB A6 BF FE
  E1 7A B1 3C  74 C6 49 EE  04 9C FF C0  4B D3 05 F6
Fingerprint:    MBAK-3KK5-F3AN-E6AJ-EIIT-IIL6-7KTP

Composite Secret Scalar = Device + Overlay:
369621881521677524799960083359389394685489760249533923273552306952445
    5498173
Fingerprint:    MBAK-3KK5-F3AN-E6AJ-EIIT-IIL6-7KTP

6. Multi-Party Decryption

A key limitation of most deployed messaging systems is that true end-to-end confidentiality is only achieved for a limited set of communication patterns. Specifically, bilateral communications (Alice sends a message to Bob) or broadcast communications to a known set of recipients (Alice sends a message to Bob, Carol and Doug). These capabilities do not support communication patterns where the set of recipients changes over time or is confidential. Yet such requirements commonly occur in situations such as sending a message to a mailing list whose membership isn't known to the sender, or creating a spreadsheet whose readership is to be limited to authorized members of the 'accounting' team.¶

The mathematical approach that makes key co-generation possible may be applied to support a public key encryption mode in which encryption is performed as usual but decryption requires the use of multiple keys. This approach is variously described in the literature as distributed key generation and proxy re-encryption [Blaze98].¶

The approach specified in this document borrows aspects of both these techniques. This combined approach is called 'recryption'. Using recryption allows a sender to send a message to a group of users whose membership is not known to the sender at the time the message is sent and can change at any time.¶

Proxy re-encryption provides a technical capability that meets the needs of such communication patterns. Conventional symmetric key cryptography uses a single key to encrypt and decrypt data. Public key cryptography uses two keys, the key used to encrypt data is separate from the key used to decrypt. Proxy re-encryption introduces a third key (the recryption key) that allows a party to permit an encrypted data packet to be decrypted using a different key without permitting the data to be decrypted.¶

The introduction of a recryption key permits end-to-end confidentiality to be preserved when a communication pattern requires that some part of the communication be supported by a service.¶

The introduction of a third type of key, the recryption key permits two new roles to be established, that of an administrator and recryption service. There are thus four parties:¶

Administrator

Holder of Decryption Key, Creator of Recryption Keys¶

Sender

Holder of Encryption Key¶

Recryption Service

Holder of Recryption keys¶

Receiver

Holder of personal decryption key¶

The information stored at the recryption service is necessary but not sufficient to decrypt the message. Thus, no disclosure of the message plaintext occurs even in the event that an attacker gains full knowledge of all the information stored by the recryption service.¶

Group Key:
  51 C5 D1 84  5F C3 31 97  D3 80 2A 25  CE 7F 82 AF
  F0 30 5B 7D  52 D0 B6 CE  3C 1C 95 A0  33 CB 89 98
Value:
322319593526028683147256399641007608894514778179691781946528967784218
    52742616

Message = This is a test as UTF8:
  54 68 69 73  20 69 73 20  61 20 74 65  73 74

[{
    "enc": "A256CBC",
    "Salt": "KDsofrPkFsnlhRsVaxPvvA",
    "recipients": [{
        "kid": "MCGR-HO5N-2FPS-VUFQ-DEKF-7TRA-JHM6",
        "epk": {
          "PublicKeyECDH": {
            "crv": "Ed25519",
            "Public": "wKdpaMbC5sF8moAusBtJlZ9XRetMzOhfb3pnW0F_uIw"}}
                ,
        "wmk": "Z0JQvs1BtVDcRDow6hDV47wPiymwn0ybJEXkteYbaSNByhLxGKf3c
            A"}]},
  "SUXu-b3kAgMzly2_HQZjGg"]

Bob's Member Key:
  C1 3D 09 F2  D0 46 2B ED  34 43 A2 06  EB C9 C5 6D
  68 92 08 3C  31 FC E7 35  EB 3D 65 82  82 66 92 1C
Value:
397652973877671772297984793967578734933293251919295536394239116455044
    36683984

Bob's Service Key:
   [Not specified as a digest input value]
Value:
694067311950021551287353369342887587783638534479943976723288700948832
    4560610

Member Agreement Value:
  B2 DB FC 97  A5 D9 14 FB  B9 47 85 A0  DF 74 44 31
  0B 28 64 EE  6C C3 97 BF  FA 6A 39 05  16 07 70 0F

Service Agreement Value:
  74 E2 28 0B  FF 65 50 5B  A9 10 87 14  0C C8 91 DB
  6B FE CF 82  CC C9 10 C0  0E 93 05 14  CD 81 28 39

Key Agreement IKM:
  2A 22 97 20  56 77 8D 13  F1 35 C9 5E  5A 5B 93 B0
  4A 18 D5 90  B2 C6 40 3F  9F 2A 9E 3D  9E D3 E4 49

7. Mutually Authenticated Key Agreement

Diffie Hellman key agreement using the authenticated public keys of the principals provides mutual authentication of those principals.¶

For example, if Alice's key pair is {a, A} and Bob's key pair is {b, B}, the Diffie Hellman key agreement value DH (a, B) = DH (b, A) can only be generated from the public information if a or b is known.¶

The chief disadvantage of this approach is that it only allows Alice and Bob to establish a single shared secret that will never vary and does not provide forward secrecy. To avoid this, cryptographic protocols usually perform the key agreement against an ephemeral key and either accept that the client key is not authenticated or perform multiple key agreements and combine the results.¶

Using the Result Combination Law allows a key agreement mechanism to combine the benefits of mutual authentication with the use of ephemeral keys without the need for multiple private key operations or additional round trips.¶

In its simplest form, the key exchange has two parties which we refer to as the client and the server. The client being the party that initiates the protocol exchange and the server being the party that responds. Let the public key pair of the client be {a, A} and that of the server {b, B}.¶

Two versions of the key agreement mechanism are specified:¶

Client ephemeral

The client contributes an ephemeral key pair {n_A, N_A}. The effective public key of the client is A ? N_A.¶

The server uses its public key B.¶

The key agreement value is DH (a + n_A, B) = DH (b, A ? N_A)¶

Dual ephemeral

The client contributes an ephemeral key pair {n_A, N_A}. The effective public key of the client is A ? N_A.¶

The server contributes an ephemeral key pair {n_B, N_B}. The effective public key of the client is B ? N_B.¶

The key agreement value is DH (a + n_A, B ? N_B) = DH (b + n_B, A ? N_A)¶

The function of the ephemeral key is effectively that of a nonce but it is shared with the counter-party as a public key value.¶

The dual ephemeral approach has the advantage that it limits the scope for side channel attacks as both sides have contributed unknown information to the key agreement value. The disadvantage of this approach is that the key agreement value can only be calculated after the server has provided its ephemeral.¶

Implementations MAY take advantage of the result combination law to enable private key operations involving the authenticated key (or a contribution to it) to be performed in trustworthy hardware.¶

An advantage of this key exchange mechanism over the traditional TLS key exchange approach is that no signature operation is involved, thus ensuring that either party can repudiate the exchange and thus the claim that they were in communication.¶

The master secret is calculated from the key agreement value in the usual fashion. For ECDH algorithms, this comprises the steps of converting the key agreement value to an octet string which forms the input to a Key Derivation Function.¶

8. Security Considerations

The security considerations for use and implementation of Mesh services and applications are described in the Mesh Security Considerations guide [draft-hallambaker-mesh-security].¶

9. IANA Considerations

This document requires no IANA actions.¶

10. Acknowledgements

A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture].¶

11. Examples