| Internet-Draft | Mesh Architecture 3.0 | October 2022 |
| Hallam-Baker | Expires 26 April 2023 | [Page] |
The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience.¶
This document provides an overview of the Mesh data structures, protocols and examples of its use.¶
[Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.¶
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html.¶
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 26 April 2023.¶
Copyright (c) 2022 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.¶
The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure (TKI) that uses cryptography to make computers easier to use. This document describes version 3.0 of the Mesh architecture and protocols.¶
In 1977, Public Key cryptography laid out a powerful proposition: If Alice and Bob have private keys on their devices and each knows the public key of the other, Alice and Bob can communicate with confidentiality and integrity. The realization of this proposition at Internet scale was vested in a technology called Public Key Infrastructure (PKI) whose principal function is to provide a trustworthy means by which Alice and Bob can discover each other's public key.¶
Yet despite the power of PKI, Internet security remains a work in progress. While PKI has proved an effective means of authenticating services to users, attempts to apply PKI to the equally important task of authenticating users to services and securing data at rest have been confined to the margins. One critical reason for that failure is that Public Key Infrastructure has only provided effective tools for managing public keys. If we are to achieve comprehensive Internet security, we must provide every user with the ability to manage private keys across their devices with zero effort on their part.¶
Threshold cryptography is a sub-field of public key cryptography that defines operations on cryptographic keys, including operations on private keys. Threshold cryptography allows Key generation and key use operations may be split between multiple devices. These tools make zero effort management of private keys practical.¶
The Mesh is a TKI that addresses the three principal concerns that have proved obstacles to the use of end-to-end security in computer applications:¶
The infrastructure developed to address these original motivating concerns can be used to facilitate deployment and use of existing security protocols (OpenPGP, S/MIME, SSH) and as a platform for building end-to-end secure network applications. Current Mesh applications include:¶
A core principle of the design of the Mesh is autonomy. That is each user has full control over their digital environment and is their own source of authority. They may choose to delegate that authority to another to act on their behalf (i.e. a Trusted Third Party) and they may choose to surrender parts of that authority to others (e.g. an employer) without surrendering their autonomy. Delegation of authority is always for limited times and limited purposes.¶
Thus, from the user's point of view, the Mesh is divided into two parts: The part of the Mesh that belongs to them and everything else. As with the Internet, which is a network of networks, a Mesh of Meshes has certain properties that are similar to those of its constituent parts and some that are quite different.¶
This document is not normative. It provides an overview of the Mesh comprising a description of the architecture, and a discussion of typical use cases and requirements. The remainder of the document series provides a summary of the principal components of the Mesh architecture and their relationship to each other.¶
Normative descriptions of the individual Mesh encodings, data structures and protocols are provided in separate documents addressing each component in turn.¶
The currently available Mesh document series comprises:¶
Provides an overview of the Mesh as a system and the relationship between its constituent parts.¶
Describes the UDF format used to represent cryptographic nonces, keys and content digests in the Mesh and the use of Encrypted Authenticated Resource Locators (EARLs) and Strong Internet Names (SINs) that build on the UDF platform.¶
Describes the cryptographic message and append-only sequence formats used in Mesh applications and the Mesh Service protocol.¶
Describes the syntax and semantics of Mesh Profiles, Catalog and Spool Entries and Mesh Messages and their use in Mesh Applications.¶
Describes the Mesh Service Protocol.¶
Describes the Mesh presentation and transport layer.¶
Describes issue and use of Mesh callsigns.¶
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.¶
Describes the cross notarization of DARE sequences to prevent rollback attacks.¶
Describes the recommended and required algorithm suites and the security considerations for the Mesh protocol suite.¶
The following documents describe technologies that are used in the Mesh but do not form part of the Mesh specification suite:¶
Describes the social work factor metric used to evaluate the effectiveness of different approaches to exchange of credentials between users and organizations in various contexts and argues for a hybrid approach taking advantage of direct trust, Web of Trust and Trusted Third Party models to provide introductions.¶
Describes extensions to the JSON serialization format to allow direct encoding of binary data (JSON-B), compressed encoding (JSON-C) and extended binary data encoding (JSON-D). Each of these encodings is a superset of the previous one so that JSON-B is a superset of JSON, JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C.¶
Describes the means by which prefixed DNS SRV and TXT records are used to perform discovery of Web Services.¶
Describes threshold key generation and key agreement operations for the Ed25519, Ed448, X25519 and X448 elliptic curves.¶
The following documents describe aspects of the Mesh Reference implementation:¶
Describes the reference code distribution license terms, implementation status and currently supported functions.¶
Describes how platform specific functionality such as secure key storage and trustworthy computing features are employed in the Mesh.¶
This section presents the related specifications and standards on which the Mesh is built, the terms that are used as terms of art within the Mesh protocols and applications and the terms used as requirements language.¶
TBS¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
The examples in this document were created on 18-Oct-22 1:16:01 PM. Out of 249 examples, 52 failed.¶
The Mathematical Mesh (Mesh) is a Threshold Key Infrastructure that uses cryptography to make computers easier to use.¶
For several decades, it has been widely noted that most users are either unwilling or unable to make even the slightest efforts to protect their security, still less those of other parties. Yet despite this observation being widespread, the efforts of the IT security community have largely focused on changing this user behavior rather that designing applications that respect it. Real users have real work to do and have neither the time nor the inclination to use tools that will negatively impact their performance.¶
The Mesh is based on the principle that if the Internet is to be secure, secure use of applications must become effortless. Rather than beginning the design process by imagining all the possible modes of attack and working out how to address these as best as possible with least inconvenience to the user, we must reverse the question and ask how much security can be provided without requiring any effort whatsoever from the user. This principle is called Zero Effort Security.¶
Today's technology requires users to put their trust in an endless variety of devices, software and services they cannot fully understand let alone control. Even the humble television of the 20th century has been replaced by a 'smart' TV with 15 million lines of code whose undeclared capabilities may well include placing the room in which it is placed under continuous audio and video surveillance.¶
Every technology deployment by necessity requires some degree of trust on the owner/user's part. But this trust should not compromise the user's autonomy. Delegation of trust should be limited and subject to accountability. If manufacturers continue to fail in this regard, they risk a backlash in which users seek to restore their rights through litigation, legislation or worst of all, simply not buying more technology that they have learned to distrust through their own experience.¶
The Mesh is based on the principle of radical distrust, that is, if a party is capable of defecting, we assume that they will. As the Russian proverb goes: ???????, ?? ????????: trust, but verify.¶
In the 1990s, the suggestion that 'hackers' might seek to make financial gains from their activities was denounced as 'fear-mongering'. The suggestion that email or anonymous currencies might be abused received a similar response. Today malware, ransomware and spam have become so ubiquitous that they are no longer news unless the circumstances are particularly egregious. In 1949, Edward A. Murphy Jr. proposed his now eponymous law which states, 'Anything that can go wrong will go wrong'. We must now apply a similar principle to Internet security: 'Anything that can be made to go wrong is already being made to go wrong and will only get worse until something is done to stop it.'¶
We must dispense with the notion that it is improper or impolite to question the good faith of technology suppliers of any kind whether they be manufacturers, service providers, software authors or reviewers. Modern supply chains are complex, typically involving hundreds if not thousands of potential points of deliberate or accidental compromise. The technology provider who relies on the presumption of good faith on their part risks serious damage to their reputation when others assert that a capability added to their product may have malign uses.¶
Radical distrust means that we apply the principles of least principle and accountability at every level to the design of the Mesh:¶
Security is risk management and not the elimination of every possible risk. Radical distrust means that we raise the bar for attackers to the point where for most attackers the risk is greater than the reward. It does not demand that we immediately address every issue with perfection or delay deployment of technologies that are capable of controlling many risks until we have achieved the control of every risk.¶
In addition to distrusting technology providers the Mesh Architecture allows the user to limit the degree of trust they place in themselves. In the real world, devices are lost or stolen, passwords and activation codes are forgotten, natural or man-made catastrophes cause property and data to be lost. The Mesh permits but does not require use of escrow techniques that allow recovery from such situations.¶
Existing PKIs were developed in an era when the 'personal computer' was still coming into being. Only a small number of people owned a computer and an even smaller number owned more than one. In these circumstances, it arguably sufficed to provision a user with a single key pair on the single device they were likely to use. Creating keys was a time-consuming business that might take several minutes, an architecture in which an end user might create and use hundreds of key pairs was beyond the capabilities of the available hardware.¶
Today, computers are ubiquitous and a typical home in the developed world contains several hundred of which a dozen or more may have some form of network access. The modern consumer faces a problem of device management that is considerably more complex than the IT administrator of a small business might have faced in the 1990s but without any of the network management tools such an administrator would expect to have available.¶
One important consequence of the proliferation of devices is that end-to-end security is no longer sufficient. To be acceptable to users, a system must be ends-to-ends secure. That is, a user must be able to read their encrypted email message on their laptop, tablet, phone, or watch with exactly the same ease of use as if the mail were unencrypted. A cryptographic security control that impedes the user is a control that is not going to be used.¶
Each personal Mesh contains a device catalog in which the cryptographic credentials and device specific application configurations for each connected device are stored. A device granted administration rights can use the device catalog to configure each connected device with the precise cryptographic credentials it needs to perform its functions.¶
One of the most challenging, certainly the most contentious issues in PKI is the means by which cryptographic credentials are published and validated. Here there are two different challenges.¶
Developing an infrastructure that provides a mapping to a cryptographic key from a name that serves no other purpose than identifying the key is relatively easy. Developing an infrastructure that maps existing names with semantics that are already established is considerably harder.¶
The Mesh does not attempt to impose criteria for accepting credentials as valid as no such set of criteria can be comprehensive. Rather, the Mesh provides an internal trust infrastructure that makes use of a direct trust model similar to that of PGP fingerprints to which external names may be mapped using whatever validation criteria users consider are appropriate to the purpose for which they intend to use them.¶
The principles of providing extended trust management in the Mesh are further described in [draft-hallambaker-mesh-trust].¶
Configuration of cryptographic applications is typically an afterthought (or worse). Configuration of one popular mail user agent to use S/MIME security requires 17 steps to be performed using four separate application programs. And since S/MIME certificates expire, the user is required to repeat these steps every few years. Contrary to the public claims made by one major software vendor it is not necessary to perform 'usability testing' to recognize abject stupidity.¶
Rather than writing down configuration steps and giving them to the user, we should turn them into code and give them to a machine. Users should never be required to do the work of the machine. Nor should any programmer be allowed to insult the user by casting their effort aside and requiring it to be re-entered.¶
While most computer professionals who are required to do such tasks on a regular basis will create a tool for the purpose, most users do not have that option. And of those who do write their own tools, only a few have the time and the knowledge to do the job without introducing security vulnerabilities.¶
As might be expected of a Key Infrastructure, use of the Mesh typically requires the use of an online service to provide an always present point of service through which devices which are not permanently connected can exchange messages. This online service is called a Mesh Service Provider (MSP).¶
An MSP performs similar functions to an SMTP mail provider but with one important distinction: MSPs do not issue or own Mesh accounts. A Mesh account is always created by and belongs to its user who can change their MSP at any time without changing their account. Further, a user MAY choose to act as their own MSP.¶
Meeting the core objectives of the Mesh required new naming, communication and cryptographic capabilities provided to be developed. These capabilities may in turn be used to develop new end-to-end secure applications.¶
For example, the Mesh Catalogs used to maintain collections of device descriptions, bookmarks, credentials, etc. might be used in an electronic records infrastructure to maintain chain of custody of digital evidence.¶
The Mesh is designed to provide the greatest practical level of security that does not detract from the user experience. The usual CIA triad is considered:¶
The confidentiality of user content should be protected at all times and against all unauthorized parties including their MSP.¶
Reasonable efforts should be taken to protect user data against traffic analysis and metadata attacks. It is not necessary to consider disclosure of this information to MSPs. Metadata must be shielded from external parties but controls to prevent traffic analysis may be left to implementers.¶
The design should consider unauthorized modification of data to be at least as serious as disclosure.¶
The design should consider loss of data likely to be at least as serious as disclosure.¶
In addition to protecting the user's data, the Mesh is designed to protect the user's autonomy. While the use of any electronic device or service entails a degree of trust, the user should have the right to decide which devices and which service providers to trust and to have the practical ability to revoke that trust at any time they choose.¶
Development of PKI has traditionally focused on the needs of large enterprises. The Mesh is focused on the individual user. While this change of focus is in part a recognition of the need to reverse the traditional bias, it is also a recognition of the fact that we must understand the needs of the individual user before attempting to understand the additional needs of an enterprise IT department serving a large number of users.¶
This section describes the Mesh in use. These use cases described here are re-visited in the companion Mesh Schema Reference [draft-hallambaker-mesh-schema] and Mesh Protocol Reference [draft-hallambaker-mesh-protocol] with further details and additional examples.¶
For clarity and compactness of exposition, these use cases are illustrated using the command line tool meshman, a tool that makes the cryptographic operations explicit. This does not represent the ideal user experience in which Zero-effort security is achieved. Such a user experience requires that the Mesh operations be seamlessly integrated into the user's applications so that instead of using the meshman tool to encrypt or decrypt document, the word processor application itself would be extended to read and write documents encrypted in the DARE format.¶
From the user's perspective, their personal Mesh consists of a collection of devices that communicate seamlessly and securely through a Mesh account serviced by an MSP.¶
As with an email service provider, the user is only likely to be aware of their interactions with their MSP in the case of a service interruption. As far as the user is concerned the data is replicated across their devices automatically unless there is a problem.¶
While the term 'account' is used because it is the term a user is familiar with that most closely describes its functions, Mesh accounts are different from traditional Internet accounts in one important respect: In order to realize the principle of 'autonomy', Mesh accounts are created by and belong to the user and not the service provider. Should a serious problem occur, a user may opt to change their MSP. But unlike a changing an SMTP email provider, this change is made seamless and cost free.¶
Another important difference between the Mesh and SMTP is that all Mesh data is encrypted end to end. The MSP does not have access to any user content and does not have access to any user meta-data except that which is strictly necessary to service the account.¶
The only Mesh catalogs associated with a Mesh account that can be read by an MSP are the Access Catalog which serves as the basis for specifying and enforcing access control policy on the resources associated with the account and the Publications Catalog which is an index of encrypted data published through the account.¶
To create a Mesh account, the user need only specify the account name and the initial MSP:¶
The user specifies the initial account address to be used (alice@example.com). Use of this address is of course dependent on authorization by the Mesh Service Provider (example.com) and is likely to require authentication and possibly payment.¶
Alice> meshman account create alice@example.com Account=alice@example.com UDF=MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA¶
The command returns the value of Alice's Mesh Account fingerprint . This value is used as a unique identifier that is cryptographically bound to the signature key used to authenticate the account profile.¶
Note that the user does not specify the cryptographic algorithms to use. Choice of cryptographic algorithm is primarily the concern of the protocol designer, not the user. The only circumstance in which users would normally be involved in algorithm selection is when there is a transition in progress from one algorithm suite to another.¶
Having created an account, Alice can use it to encrypt files and decrypt them on the same machine.¶
Alice encrypts the text file plaintext.txt to create an encrypted version readable only by Alice:¶
Alice> meshman type plaintext.txt
This is a test
Alice> meshman dare encode plaintext.txt ciphertext.dare /encrypt ^
alice@example.com
Alice> meshman dare verify ciphertext.dare
File: ciphertext.dare
Bytes: 16
Encryption Algorithm: A256CBC
Recipient: MC7V-XVMJ-73OL-YWGL-5MIK-ROXQ-GL3Y
Digest Algorithm: S512
Payload Digest: 6EA307959C0C97D67F8464954CCD0E4CCEEC0EC1FF0356565
B574E9CDC49F6DD4E2FBF825E995B20DD307DDE6AE91153B3074846157F0FC8284068
4A02F3630E
¶
Alice can recover the file at any time using the decryption command:¶
Alice> meshman dare decode ciphertext.dare plaintext1.txt Alice> meshman type plaintext1.txt This is a test¶
Although the encrypted file can be accessed by Alice with precisely the same ease as the plaintext version, the contents of the encrypted file are not readable by any other user of the machine unless Alice explicitly grants access. The encrypted file may be stored on a shared drive, cloud file system or removable storage without disclosing the contents.¶
While encrypting and decrypting files using a tool provides the desired functionality, it does not meet our objectives for usability. These capabilities should be integrated into applications or the platform itself.¶
Every Mesh account is created with a set of catalogs and spools. For example, the bookmarks catalog maintains a list of the user's Web bookmarks. The credentials catalog maintains a list of the user's usernames and passwords for the various network services they use. As with the file encryption example, these capabilities are clearly going to be most effective when incorporated into the user's applications, (i.e. their Web browser).¶
Alice adds the username and password she uses to access her weather service account to her credentials catalog:¶
Alice> meshman password add ftp.example.com alice1 password
alice1@ftp.example.com = [password]
Alice> meshman password add www.example.com alice@example.com ^
newpassword
alice@example.com@www.example.com = [newpassword]
¶
As with all Mesh Catalogs, the catalog data is encrypted and cannot be accessed by any unauthorized party including the Mesh Service Provider.¶
If needed, she can retrieve the credentials from the catalog by specifying the network resource to which access is required:¶
Alice> meshman password get ftp.example.com alice1@ftp.example.com = [password]¶
This capability provides a means of preventing one of the most common causes of enterprise password breach in which a system administrator encodes the access credentials for a service into a script used to access the service. A script containing a command to extract the credentials from a Mesh catalog will only work for a user authorized to access the credentials in the Mesh.¶
Computers have become ubiquitous and inexpensive. Most people living in affluent countries interact with several dozen computer systems every day. Every household appliance from the television to the coffee pot has become or is in the process of becoming a computer. It is this circumstance that has exposed the critical flaw in traditional PKI: The lack of practical means of managing private keys across multiple devices.¶
The Mesh allows users to connect all their devices together so that they may be considered part of a single entity whose component parts communicate and interact seamlessly and securely.¶
Although any type of network capable device may be connected to a Mesh profile, some devices are better suited for use with certain applications than others. Connecting an oven to a Mesh profile could allow it to be controlled through entries to the user's recipe and calendar catalogs and alert the user when the meal is ready but attempting to use it to read emails or manage Mesh profiles. The Mesh allows the principle of least privilege when connecting a device granting precisely the set of capabilities required to perform its intended function.¶
Multiple connection mechanisms are specified, each of which provides strong mutual authentication. In each case, the connection request must be approved by a device provisioned with the Mesh administration privilege:¶
The connection request is initiated on the device being requested and approved on the administration device. Authentication of the connection request is performed by comparing witness values presented on the connecting device and the administration device.¶
A PIN code is generated on an administration device and passed to the connecting device out of band. The connecting device provides proof of knowledge of this PIN code when making the connection request allowing an administration device to approve the request automatically without further user interaction.¶
This connection mechanism is a variation of the PIN connection mechanism in which administration device presents the PIN code value to the connecting device in the form of a QR code. This allows a connecting device with a camera to connect with minimal user effort.¶
This connection method is designed to support connection of constrained IoT devices that lack a camera or display capability but requires that the device be pre-provisioned during manufacture or distribution.¶
An administration device equipped with a camera reads a static QR code printed on the device that provides the information used to enable the administration device to establish a local network connection (e.g. WiFi, Bluetooth, strobe, IR) that can be used to complete the connection.¶
These connection mechanisms are described in detail in the Mesh Protocol Reference [draft-hallambaker-mesh-protocol].¶
For example, Alice connects a second device using the direct connection mechanism:¶
The connection request is initiated on the device being connected:¶
Alice2> meshman device request alice@example.com Device UDF = MBYN-Q2AT-73EJ-2RO5-FZG3-CMIE-3YFA Witness value = 7QI7-PLXA-DZB2-XCQK-NGHH-DRXM-FIRV¶
Using her administration device, Alice gets a list of pending requests. Seeing that there is a pending request matching the witness value presented by the device, Alice accepts the request, granting the new device the messaging and web roles:¶
Alice> meshman device pending
MessageID: 7QI7-PLXA-DZB2-XCQK-NGHH-DRXM-FIRV
Connection Request::
MessageID: 7QI7-PLXA-DZB2-XCQK-NGHH-DRXM-FIRV
To: From:
Device: MBYN-Q2AT-73EJ-2RO5-FZG3-CMIE-3YFA
Witness: 7QI7-PLXA-DZB2-XCQK-NGHH-DRXM-FIRV
Alice> meshman device accept 7QI7-PLXA-DZB2-XCQK-NGHH-DRXM-FIRV ^
/message /web
¶
Alice can now synchronize her newly connected device to her account:¶
Alice2> meshman device complete Device UDF = MBYN-Q2AT-73EJ-2RO5-FZG3-CMIE-3YFA Account = alice@example.com Account UDF = MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA¶
Alice connects a third device using the PIN code connection mechanism:¶
The Alice begins the connection process by creating a one time use PIN authentication code on her administration device. The PIN creation request specifies the rights to be granted to the connecting device:¶
Alice> meshman account pin /threshold PIN=AAIT-WXRD-BVB7-3BBT-D6JS-44GE-B4 (Expires=2022-10-19T12:48:11Z)¶
A connection request is made on the connecting device as before except that this time the PIN is specified. This time, only the 'threshold' right is granted.¶
Alice3> meshman device request alice@example.com /pin ^
AAIT-WXRD-BVB7-3BBT-D6JS-44GE-B4
Device UDF = MDVU-AOST-TDIH-AXGE-WUJS-I56V-WJP3
Witness value = AI7W-YKPK-MR3U-CZW7-GAVQ-24LZ-MSFA
¶
Since the connection request is pre-authenticated by the PIN, it is not necessary for Alice to review the connection request. The connection request is accepted automatically when the administration device is synchronized:¶
Alice> meshman message pending
MessageID: AI7W-YKPK-MR3U-CZW7-GAVQ-24LZ-MSFA
Connection Request::
MessageID: AI7W-YKPK-MR3U-CZW7-GAVQ-24LZ-MSFA
To: From:
Device: MDVU-AOST-TDIH-AXGE-WUJS-I56V-WJP3
Witness: AI7W-YKPK-MR3U-CZW7-GAVQ-24LZ-MSFA
MessageID: NBGK-6BGU-5C5H-4WUR-OGDF-NZTH-ZLCW
Confirmation Request::
MessageID: NBGK-6BGU-5C5H-4WUR-OGDF-NZTH-ZLCW
To: alice@example.com From: console@example.com
Text: start
Alice> meshman account sync /auto
¶
Alice can now synchronize her newly connected device to her account:¶
Alice3> meshman device complete Device UDF = MDVU-AOST-TDIH-AXGE-WUJS-I56V-WJP3 Account = alice@example.com Account UDF = MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA Alice3> meshman account sync¶
The Dynamic QRCode connection scheme uses exactly the same mechanism except that instead of the PIN being presented to Alice in the form of an alphanumeric string, the connection information is encoded as a URI and presented to the connecting device as a QR code.¶
The URI corresponding to the connection PIN is:¶
mcu://alice@example.com/AAIT-WXRD-BVB7-3BBT-D6JS-44GE-B4¶
Having connected a second device and granted it web access rights, Alice can use it to decrypt files and access her bookmark and password catalogs in exactly the same fashion as the first. If a password is changed on one device, all her connected devices receive the update.¶
For example, because Alice granted the device the Web role, she can now access her credential catalog and decrypt the file she encrypted on her first device from the new device:¶
Alice2> meshman password get ftp.example.com alice1@ftp.example.com = [password] Alice2> meshman dare decode ciphertext.dare plaintext2.txt Alice2> meshman type plaintext2.txt This is a test¶
By default, devices connected with the web access right can access all the catalogs connected to a personal Mesh. Devices MAY be connected with greater or lesser access rights according to their intended use. A coffee pot does not require access to the password catalog or the ability to send messages to other Mesh users. A software development station is likely to require the ability to sign commits to a source code repository.¶
Limiting the access rights granted to a device when it is connected mitigates the consequences of the device being lost, stolen or infected by malware before the compromise occurs. Disconnecting the device from the user's personal Mesh as described in a later section provides further mitigation.¶
Connected devices can also make use of connected applications for which they are granted the necessary rights.¶
Alice creates an SSH profile within her Mesh on the administrative device making the private key information available to devices she has connected to her Mesh with the 'web' access right.¶
Alice> meshman ssh create /web /threshold /id=ssh UDF: MDCT-IRNQ-JDWH-IRIP-FZK2-YP4G-5MGS¶
She can extract the private key to configure her SSH clients:¶
Alice> meshman ssh get ssh /private /file=alice1_ssh_prv.pem¶
She can also extract her public key to configure her SSH server to allow access to the machine:¶
Alice> meshman ssh get ssh /file=alice1_ssh_pub.pem¶
Ideally these steps would be performed on Alice's behalf by an automated script that detects the applications Alice has installed on her device and performs the necessary configuration on her behalf.¶
The SSH keys created on one device are available to every device connected by the 'web' access right:¶
Alice2> meshman account sync Alice2> meshman ssh get ssh /private /file=alice2_ssh_prv.pem¶
At present the Mesh only supports an SSH configuration in which a single client key is shared across multiple devices. The Mesh is in principle capable of supporting more sophisticated configurations in which each device has its own individual client key. Consideration of these configuration modes is currently outside the scope of work for the Mesh and is probably more usefully considered as part of an effort to integrate Mesh functionality into the SSH system. Such an effort would also describe the means by which SHH server key fingerprints are recorded in the Mesh Contacts catalog.¶
Support for SMTP mail with OpenPGP and S/MIME end to end security is supported in a similar fashion.¶
As is to be expected of a Threshold Key Infrastructure, Mesh devices MAY be configured to use a threshold key share for decryption, the other key share being held by the Mesh service servicing the account.¶
Connecting a device with the threshold access right grants it the same range of functionality as the web access right for as long as it is connected to the user's personal Mesh. Instead of being provisioned with the account decryption key, the device is provisioned with a key share. To decrypt documents encrypted to the account key, the device requires the active participation of the service holding the other half of the shared key. This allows the service to prevent further use of the decryption capability by the device after it has been disconnected from that personal Mesh.¶
Provisioning devices with threshold access rights has the advantage of allowing greater control of the decryption capability at the cost of requiring an interaction with the network service for each decryption operation. There is thus a tradeoff between performance and security.¶
While the Mesh architecture permits any decryption key to be threshold shared, it is RECOMMENDED that implementations use this capability sparingly and develop mechanisms that avoid the need for a device to preform repeated threshold operations to decrypt the same data. For example, rather than decrypting every entry in the password catalog each time it is used, a device should encrypt a primary secret under the account threshold key that can be decrypted each time the device is activated and re-encrypt threshold encrypted data to that secret each time a threshold decryption is performed. This provides the same security properties with considerably less load on the service.¶
The current version of the Mesh protocols require that the administration device used to provision threshold keys to a device have access to the original key. As described in [draft-hallambaker-mesh-schema], this requirement will be lifted in a future edition of the protocol.¶
The Mesh Messaging system is a push messaging system analogous to SMTP, but its purpose is limited to secure exchange of control plane messages. This leads to some important differences:¶
This size restriction ensures that exchange of Mesh Messages does not impose an undue burden on the inbound and outbound MSP. While users can and do send much larger messages, 32KB should be more than sufficient to demonstrate to the recipient that the message should be accepted. It is not necessary for a sender to transfer multiple MB message before the receiver decides to refuse it. Connected devices may efficiently synchronize their message spools even over limited bandwidth connections. A short message is never blocked by a larger one.¶
For exchange of longer messages, a pull model is employed. A short Mesh message sent a message advising the recipient's client of the location from which the full content may be obtained. This approach has many benefits over the SMTP push model. There is no longer a need for any limitation on message size. The same messaging platform can be used to send a short text message, a spreadsheet or raw video file archives spanning multiple TB.¶
Exchange of certain content types naturally leads to security concerns. These concerns are mitigated in the Mesh by performing access control on every message. When accepting Bob as a partner, Alice can choose the types of Mesh Message and the types of content she is willing to accept from him. Thus, Alice might be willing to accept a spreadsheet containing macro code from Bob but not from Carol or Mallet. And she might not want to accept anything at all from Susan because of past abuse.¶
While there are important technical differences between Mesh Messaging and SMTP, these are not visible to Alice or Bob except insofar as there is no restriction on message size other than the storage capacity of the machine they wish to receive the messages on, there is very little scope for messaging abuse and (unless the Mesh becomes ubiquitous) they can only use Mesh Messaging to communicate with other Mesh users. Thus, while Mesh messaging has been designed to enable replacement of SMTP in the long term, it is not currently a focus for the client implementations. Use of Mesh messaging is thus currently limited to support for applications built on the Mesh platform. One of those applications is the device connection protocol describe earlier. Another is the contact exchange protocol used to acquire contact information from other Mesh users.¶
Besides management of private keys across devices, the biggest obstacle to effective use of existing security protocols such as SSH, OpenPGP and S/MIME is the difficulty of obtaining the authentic public keys of the counterparties.¶
The question of issue and validation of credentials is a complex and difficult one that does not have a single answer that is valid for every use case. For certain applications credentials issued by a Trusted Third Party are appropriate. For others, the Web of Trust proposed in OpenPGP provides a better fit to the requirements and constraints. These issues are discussed in [draft-hallambaker-mesh-trust].¶
Rather than imposing a single trust model for credential acquisition, the Mesh allows the use of whatever model is best for validating a credential for a particular use. It is unlikely Alice would have the same security concerns for communication with her employer, her friends, her bank, etc.¶
For many applications, Trust After First Use provides an adequate basis for credential acquisition.¶
Alice wants to exchange Mesh messages with Bob. Although Alice knows Bob's Mesh address (bob@example.com), she does not (yet) have permission to send any message to Bob excepting a request to exchange contact information.¶
Bob sends Alice a contact exchange request:¶
Bob> meshman contact request alice@example.com Envelope ID: MA6Z-6YGY-7TJB-CADG-SZN3-Q6IS-6BHF Message ID: NDRX-MOGE-HQ5D-FZHD-R42W-2U6V-OTKD Response ID: MCN2-CAZY-X3PZ-673C-QCYR-MIQ5-TAHN¶
Alice checks his Mesh messages and approves Bob's request:¶
Alice> meshman account sync
Alice> meshman message pending
MessageID: NBDK-G2OV-7H3S-BO6N-NXUZ-3PE6-ZNE4
Contact Request::
MessageID: NBDK-G2OV-7H3S-BO6N-NXUZ-3PE6-ZNE4
To: alice@example.com From: mallet@example.com
PIN: ACRO-GLXA-VJ3P-4CZ2-KQRO-J3LU-TESA
MessageID: NDRX-MOGE-HQ5D-FZHD-R42W-2U6V-OTKD
Contact Request::
MessageID: NDRX-MOGE-HQ5D-FZHD-R42W-2U6V-OTKD
To: alice@example.com From: bob@example.com
PIN: ABMH-MBQP-GX34-A7AG-ZEOL-R4XO-VGYQ
Alice> meshman message accept NDRX-MOGE-HQ5D-FZHD-R42W-2U6V-OTKD
Alice> meshman contact list
Entry: MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA
Person MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA
Anchor MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA
Address alice@example.com
Entry: NBL7-CLVR-MT2M-EWR5-U2NY-NWEN-IF7S
Person
Anchor MDLP-RRZJ-ZASG-GUBZ-PP2K-5YDH-EMGE
Address bob@example.com
¶
Bob can now collect Alice's contact:¶
Bob> meshman account sync /auto Bob> meshman contact list Entry: MDLP-RRZJ-ZASG-GUBZ-PP2K-5YDH-EMGE Person MDLP-RRZJ-ZASG-GUBZ-PP2K-5YDH-EMGE Anchor MDLP-RRZJ-ZASG-GUBZ-PP2K-5YDH-EMGE Address bob@example.com Entry: NCCQ-N3CB-4ZV2-M2DT-QQ7P-P3EF-65PM Person Anchor MDRR-5W72-3RJO-VZB3-VUVQ-IOEC-6UNA Address alice@example.com¶
At this point Alice and Bob can exchange Mesh messages of any type with seamless end to end security. Every Mesh message is signed and encrypted without exception. If Alice and Bob have used the Mesh to configure their email accounts for OpenPGP or S/MIME, they can use these to exchange end-to-end secure SMTP mail.¶
Alternatively, Bob might have opted to grant Alice only specific messaging access. Bob might choose to restrict synchronous messaging modalities such as instant messaging or voice that interrupt his workflow to specific colleagues. The fact that Alice wants to speak to Bob does not necessarily mean she is interested in what he might say in reply. Thus, messaging access need not be reciprocated.¶
As with device connection, multiple contact exchange methods are supported including the use of a QR code printed on a business card or presented on a mobile device. These methods are also described in [draft-hallambaker-mesh-protocol].¶
As a respected figure within the cryptographic community, Alice might employ a curation service for credential requests advising her that Bob's credentials appear to be in order while Mallet's are suspicious. Such services might be offered by her MSP or another provider. Alice might be willing to accept contact requests from members of professional associations she is a member of or who have attended certain conferences in her field. A variety of approaches might be followed for curation of other requests including Machine Learning approaches.¶
The Mesh confirmation service is an improvement of traditional second factor authentication techniques offering offers far greater usability and security.¶
Instead of being asked to present a meaningless numeric code, Alice is presented a request from a named, authenticated source to confirm a specific action. Alice's response will be signed using a signature key that is unique to the particular confirmation device she uses, thus providing a non-repudiable record of her decision.¶
Alice attempts to log into a secure console in the control room. The secure console recognizes Alice but a second factor is required. The console issues a challenge to Alice at her registered account asking if she would like to log into the secure console:¶
Console> meshman message confirm alice@example.com start Envelope ID: MBFM-RPD5-MYYX-UK3M-2SCV-GUYR-J446 Message ID: NBGK-6BGU-5C5H-4WUR-OGDF-NZTH-ZLCW Response ID: MA6X-RZBB-RBT7-EWC2-ZPDV-ZUJI-3BRE¶
Alice checks her pending messages and accepts the request:¶
Alice> meshman message accept NBGK-6BGU-5C5H-4WUR-OGDF-NZTH-ZLCW¶
The secure console verifies the response and grants access:¶
Console> meshman message status MA6X-RZBB-RBT7-EWC2-ZPDV-ZUJI-3BRE Accept¶
In an enterprise environment, tying the confirmation process to a specific source, a specific action and specific device allows for confirmation interactions to be used to implement business processes with attribution and thus accountability.¶
Using traditional second factor approaches, a system administrator presents their credentials to authenticate access to the machine at which point they can perform any action permitted by their current privileges. This typically includes modification of any access logs that might be kept. Using the confirmation approach the individual actions of the system administrator may be authenticated, traced and logged. If a user account is added to the system, it is known which administrator is responsible and the device that was used. This information may then be used if it becomes necessary to unwind the consequences of a breach or an insider threat.¶
As seen earlier, the Mesh allows encrypted files to be shared with other named users. While this capability is sufficient for simple messaging type use cases, decades of experience prove that it is inadequate to meet the needs of protecting data at rest. In the simple messaging case the list of recipients is known to the sender at the time a message is sent. In the general case the party encrypting the data cannot know the list of intended readers because that will change over time.¶
Even in the smallest organization, employees join and leave. A new employee must be granted access to all the information they need for their work. The access rights of a terminated employee must also terminate.¶
Traditional 'Digital Rights Management' product employ key management techniques originating in the field of copyright enforcement to control access to content by controlling disclosure of symmetric decryption keys. This provides the necessary flexibility to control access to the data but leaves the decryption keys vulnerable to a server breach. Such systems do not provide 'end-to-end' security in any useful sense.¶
Use of threshold techniques allows a threshold service to control decryption of the data without having the ability to decrypt. Sharing data through a Mesh group allows access to be controlled without loss of end-to-end encryption.¶
Alice creates the recryption group groupw@example.com to share confidential information with her closest friends:¶
Alice> meshman group create groupw@example.com /web Account=groupw@example.com UDF=MAXE-Z6UJ-A7XI-MIEH-IDQK-L2LH-2DEG¶
Alice encrypts a test file but she can't decrypt it because she hasn't added herself to the group yet.¶
Alice> meshman type grouptext.txt
The group secret handshake
Alice> meshman dare encode grouptext.txt groupsecret.dare /encrypt ^
groupw@example.com
Alice> meshman dare decode groupsecret.dare grouptext_alice.dare
ERROR - No decryption key is available
¶
Alice adds herself to the group, now she can decrypt:¶
Alice> meshman group add groupw@example.com alice@example.com alice@example.com [MD5B-HJIJ-2Q6Z-2O3U-UY4K-PYRQ-O3N6] Alice> meshman account sync /auto Alice> meshman dare decode groupsecret.dare grouptext_alice.dare Alice> meshman type grouptext_alice.dare The group secret handshake¶
At this point, Bob can't encrypt or decrypt messages because he doesn't know the public key and he isn't in the group. Alice could allow Bob to encrypt but not decrypt by sending him the group contact information without a decryption share. Instead she adds Bob to the group as a member:¶
Alice> meshman group add groupw@example.com bob@example.com bob@example.com [MD5B-HJIJ-2Q6Z-2O3U-UY4K-PYRQ-O3N6]¶
Adding Bob to the group gives him immediate access to any file encrypted under the group key without making any change to the encrypted files:¶
Bob> meshman account sync /auto Bob> meshman dare decode groupsecret.dare grouptext_bob.dare Bob> meshman type grouptext_bob.dare The group secret handshake¶
Removing Bob from the group immediately withdraws his access.¶
Alice> meshman group delete groupw@example.com bob@example.com bob@example.com [MD5B-HJIJ-2Q6Z-2O3U-UY4K-PYRQ-O3N6]¶
Bob cannot decrypt files encrypted under the group key any more. But he still has access to the file grouptext_bob.dare he decrypted earlier.¶
Bob> meshman dare decode groupsecret.dare grouptext_bob2.dare ERROR - A cryptographic operation was refused. Bob> meshman type grouptext_bob.dare The group secret handshake¶
The threshold key service acts as a policy enforcement point and can impose additional accounting and authorization controls on the use of the decryption service.¶
For example, the threshold key service might be configured to alert a supervisor and/or deny decryption requests if a group member made an unusual volume of requests in a short period.¶
If a connected device is lost, stolen or simply broken, Alice can limit further use of the device by disconnecting it from her Mesh:¶
Alice disconnects the new device:¶
Alice> meshman device delete MBYN-Q2AT-73EJ-2RO5-FZG3-CMIE-3YFA ERROR - Cannot access a closed file.¶
Disconnecting a device will always prevent the device receiving further services from the account service and thus the ability to receive encrypted catalog updates. But a device connected with direct key access rights (e.g. web) is still capable of decrypting documents encrypted under the account key unless the device application discovers that it has been disconnected and deletes the corresponding keys:¶
The device can no longer access the password catalog, but it can still decrypt files:¶
Alice2> meshman account sync ERROR - The server returned an invalid response. Alice2> meshman dare decode ciphertext.dare plaintext3.txt Alice2> meshman type plaintext3.txt This is a test¶
A device connected with the threshold access right loses the ability to decrypt immediately:¶
The third device was connected with threshold rights, it is disconnected in the same way as before.¶
Alice> meshman device delete MDVU-AOST-TDIH-AXGE-WUJS-I56V-WJP3 ERROR - Cannot access a closed file.¶
The device can no longer access the password catalog or decrypt files:¶
Alice3> meshman account sync ERROR - The server returned an invalid response. Alice3> meshman dare decode ciphertext.dare plaintext3.txt ERROR - A cryptographic operation was refused.¶
While disclosure of sensitive data might cause serious harm to its owner it is very rarely the case that the consequences of disclosure are greater than the consequences of loss. Thus, whenever static data is to be encrypted, the question of key recovery must be considered.¶
Alice decides to create a recovery key set. To do this, she specifies the number of key shares to be created and the number required for recovery:¶
Alice> meshman account escrow Share: SAQE-JRDL-32AC-GBJK-6WC5-IUEO-5VGH-5LHC-F6GO-7R4S-UAMS-IDDQ-LX HD-GHKE-GTPQ Share: SAQ4-DB6V-V4E3-DTCA-OTCE-K56Z-JQ4L-66NG-QDFF-SGJ4-47QM-RQT4-ST 36-UX6R-IPIQ Share: SARD-4SZ7-P6JU-BE2V-6QBL-NHZD-VMSQ-ARTK-2ID4-E2XH-F6UG-26EI-ZQ Q2-DIS6-KKLA¶
Recovery of the key data requires the key recovery record and a quorum of the key shares:¶
>>>> Unfinished ArchitectureRecovery¶
Alice2> meshman account recover /verify ERROR - No account specified¶
The Mesh is a Threshold Key Infrastructure and as with any infrastructure, it is designed as a platform to support as wide a range of future developments as possible. Selection of the initial feature set was determined by the need to achieve zero-effort security.¶
Further development of the Mesh will require careful consideration of costs and benefits. The range of security features that could be added is infinite, the range of features that should be added is small. Real world deployment and use is required before extensive addition of new features.¶
While 'single sign on' gets much attention in the Enterprise computing space, it is actually 'single sign off' that provides the real security value. Future enhancements of the Mesh will consider:¶
?A notification mechanism to allow a disconnected device to advise the user that it has completely disconnected from the user's Mesh and deleted relevant data.¶
?Use of trustworthy hardware to prevent use of confidential data accessed through a personal Mesh after the device is disconnected.¶
?Use of threshold timed key release to limit the period during which a device has access to confidential data.¶
Allowing users to transfer their accounts from one service provider to another without switching costs is an important goal of the Mesh project. Enabling such transfers is the principal purpose of the Callsign registry [draft-hallambaker-mesh-callsign].¶
Support for account transition is currently limited and untested. In theory a user MAY transfer their account from one service provider to another by opening an account at the new service provider and uploading the data provided that they have access to the profile primary secret and all threshold key shares granted to the devices are regenerated.¶
A different application of threshold cryptography and in particular the use of threshold techniques to generate key shares would allow a user to transfer their account without the need to reconstitute the primary secret.¶
At present the administration device has direct access to the administrator key and it is not possible to determine which device performed a particular administration action. Similarly, the administration device requires access to the full decryption keys to create threshold key shares for devices.¶
As with the service transition issue described earlier, meeting this particular requirement using threshold cryptography is straightforward in itself. The challenge lies in meeting the requirements simultaneously. Or to be more precise, the challenge lies in understanding what the precise requirements are.¶
A sketch has been developed of an approach addressing both sets of requirements as currently understood. Instead of using an additive key splitting approach for creating key shares, the additive approach is combined with a Shamir/Lagrange approach such that:¶
Achieving the last requirement makes use of the fact that Lagrange interpolation can be used to generate additional shares without reconstructing the original secret. The x coordinate of each share holder is determined from the fingerprint of the device profile signature key.¶
The current group encryption architecture requires that the group administrator have access to the decryption key. The administrator is thus able to decrypt any documents they chose and bypass the accounting restrictions of the service.¶
Further application of threshold techniques would allow the administrator role to be split between two or more parties, one of which might be a service enforcing additional controls.¶
Addition of a presence service capability to the MSP would allow Mesh Messaging to be used to support the full range of synchronous messaging services from text chat (e.g. xmpp) to video and VOIP. The chief security benefit to the end user for such a scheme would be that every communication request is mediated by access control. While it is impossible to absolutely guarantee that every possible form of abuse is prevented, stopping the organized crime ring that just called me purporting to be my credit card company is much more straightforward.¶
The main technical issue to be addressed to enable such a service is specifying a means of layering Mesh Messages direct over UDP transport. This is currently at the concept phase. While the precise means of layering audio and video formats onto a network connection is a complex problem, it is one that has already been solved by existing standards.¶
All the cryptographic algorithms used in the Mesh are either industry standards or present a work factor that is provably equivalent to an industry standard approach. Since threshold cryptography is not currently part of the 'canon' from which designers of cryptographic security protocols work, much of the cryptography used in the Mesh has been designed for the Mesh. Despite this fact, it is properly regarded as part of the Internet platform on which the Mesh is built rather than a part of the Mesh itself.¶
Existing Internet security protocols are based on approaches developed in the 1990s when performance tradeoffs were a prime consideration in the design of cryptographic protocols. Security was focused on the transport layer as it provided the best security possible given the available resources.¶
With rare exceptions, most computing devices manufactured in the past ten years offer either considerably more computing power than was typical of 1990s era Internet connected machines or considerably less. The Mesh architecture is designed to provide security infrastructure both classes of machine but with the important constraint that the less capable 'constrained' devices are considered to be 'network capable' rather than 'Internet capable' and that the majority of Mesh related processing will be offloaded to another device.¶
For example, Alice uses her Desktop and Laptop to exchange end-to-end secure Mesh Messages and documents but her Internet-of-Things food blender and light bulb are limited in the range of functions they support and the telemetry information they provide. The IoT devices connect to a Mesh Hub which acts as an always-on point of presence for the device state and allows complex cryptographic operations to be offloaded if necessary.¶
Except where support for external applications demand otherwise, the Mesh requires that the following 'best practices' be followed:¶
All cryptographic protocols make use of the most recently adopted industry standard algorithms.¶
Only the strongest modes of each cipher algorithm are used. All symmetric encryption is performed with 256-bit session keys and all digest algorithms are used in 512-bit output length mode.¶
Separate public key pairs are used for all cryptographic functions: Encryption, Signature and Authentication. This enables separate control regimes for the separate functions and partitioning of cryptographic functions within the application itself.¶
Each device has a separate set of Encryption, Signature and Authentication key pairs. These MAY be bound to the device to which they are assigned using hardware or other techniques to prevent or discourage export.¶
Traditional approaches to security have treated many functions as being 'advanced' and thus suited for use by only the most sophisticated users. The Mesh rejects this approach noting that all users operate in precisely the same environment facing precisely the same threats.¶
Industry best practices change over time. In the 1990s it was generally believed that supporting the widest possible range of cryptographic algorithms allowed the greatest highest level of security. This view has been decisively rejected in the light of the objection that a successful downgrade attack results in the security afforded by the weakest algorithm supported.¶
All Mesh protocol transactions are protected at the Transport, Message and Data level. This provides security in depth that cannot be achieved by applying security at the separate levels independently. Data level encryption provides end-to-end confidentiality and non-repudiation, Message level authentication provides the basis for access control and Transport level encryption provides a degree of protection against traffic analysis.¶
Traditional public key encryption algorithms have two keys, one for encryption and another for decryption. The Mesh makes use of threshold cryptography techniques to allow the decryption key to be split into two or more parts.¶
For example, if we have a private key z, we can use this to perform a key agreement with a public key S to obtain the key agreement value A. But if z = (x+y) mod g (where g is the order of the group). we can obtain the exact same result by applying the private keys x and y to S separately and combining the results:¶
The approach to threshold decryption used in the Mesh was originally inspired by the work of Matt Blaze et. al. on proxy re-encryption. But the approach used may also be considered a form of Torben Pedersen's Distributed Key generation which is in turn one form of threshold cryptography.¶
This technique is used in the Mesh to allow use of decryption key held by a user to be controlled by a cloud service without giving the cloud service the ability to decrypt by itself.¶
These techniques are described in detail in [draft-hallambaker-threshold].¶
The mathematics that support threshold decryption are also the basis for the multi-party key generation mechanism that is applied at multiple levels in the Mesh. The basis for the multi-party key generation used in the Mesh is that for any Diffie-Hellman type cryptographic scheme, given two keypairs { x, X }, { y, Y }, we calculate the public key corresponding to the private key x + y using just the public key values X and Y.¶
Threshold key generation ensures that keys used to bind devices to a personal Mesh or within a Mesh account are 'safe' if any of the contributions to the generation process are safe.¶
These techniques are also described in detail in [draft-hallambaker-threshold].¶
The techniques that support threshold decryption and key generation are also applicable to signature albeit with some very important constraints. Incorrect implementation of the techniques used to create ECDSA signatures can result in disclosure of the private key. It is therefore essential that a threshold signature algorithm is rigorously reviewed.¶
This technique is used in the mesh to partition the use of administration keys so that the consequences of losing an administrative device can be mitigated.¶
These techniques are currently being developed by the CFRG. This work is currently described in [draft-irtf-cfrg-frost].¶
The Data At Rest Encryption (DARE) format is used for all confidentiality and integrity enhancements. The DARE format is based on the JOSE Signature and Encryption formats and the use of an extended version of the JSON encoding allowing direct encoding of binary objects.¶
The DARE Envelope format offers similar capabilities to existing formats such as OpenPGP and CMS without the need for onerous encoding schemes. DARE Assertions are presented as DARE Envelopes.¶
A feature of the DARE Envelope format not supported in existing schemes is the ability to encrypt and authenticate sets of data attributes separately from the payload. This allows features such as the ability to encrypt a subject line or content type for a message separately from the payload.¶
A DARE Sequence is an append-only sequence of DARE Envelopes. A key feature of the DARE Sequence format is that entries MAY be encrypted and/or authenticated incrementally. Individual entries MAY be extracted from a DARE Sequence to create a stand-alone DARE Envelope.¶
Sequences may be authenticated by means of a Merkle tree of digest values on the individual frames. This allows similar demonstrations of integrity to those afforded by Blockchain to be provided but with much greater efficiency.¶
Unlike traditional encryption formats which require a new public key exchange for each encrypted payload, the DARE Sequence format allows multiple entries to be encrypted under a single key exchange operation. This is particularly useful in applications such as encrypting server transaction logs. The server need only perform a single key exchange operation each time it starts to establish a new shared secret for that session. The shared secret is then used to create fresh symmetric keying material for each entry in the log using a unique nonce per entry.¶
Integrity is provided by a Merkle tree calculated over the sequence of log entries. The tree apex is signed at regular intervals to provide non-repudiation.¶
Four types of DARE Sequence are used in the mesh¶
A DARE Sequence whose entries track the status of a set of related objects which may be added, updated, or deleted.¶
A DARE Sequence whose entries track the status of a series of Mesh Messages.¶
A DARE Sequence recording a sequence of events.¶
A DARE Sequence containing a collection of files, each encoded in a DARE envelope. DARE archives perform a similar function to ZIP archives except that the primary objective is to support confidentiality and integrity rather than data compression.¶
The Uniform Data Fingerprint (UDF) format provides a compact means of presenting cryptographic nonces, keys and digest values using Base32 encoding that resists semantic substitution attacks. UDF provides a convenient format for data entry. Since the encoding used is case-insensitive, UDFs may if necessary be read out over a voice link without excessive inconvenience.¶
The following are examples of UDF values:¶
NCAN-7BZW-ZWHL-GGXB-JOKC-WUJL-JUSA F43K-UTTY-CTR2-26I2-EAL4-OSNO-RU SAQH-TMFY-CO2E-7O2S-BSQK-K2LS-FWSM-6 MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN ADPP-OMTJ-LIV4-ZEK7-2HHC-LPAN-WG2E¶
UDF content digests are used to support a direct trust model similar to that of OpenPGP. Every Mesh Profile is authenticated by the UDF fingerprint of its signature key. Mesh Friendly Names and UDF Fingerprints thus serve analogous functions to DNS names and IP Addresses. Like DNS names, Friendly Names provide the basis for application-layer interactions while the UDF Fingerprints are used as to provide the foundation for security.¶
Internet addressing schemes are designed to provide a globally unique (or at minimum unambiguous) name for a host, service or account. In the early days of the Internet, this resulted in addresses such as 10.2.3.4 and alice@example.com which from a usability point of view might be considered serviceable if not ideal. Today the Internet is a global infrastructure servicing billions of users and tens of billions of devices and accounts are more likely to be alice.lastname.1934@example.com than something memorable.¶
Friendly names provide a user or community specific means of identifying resources that may take advantage of geographic location or other cues to resolve possible ambiguity. If Alice says to her voice activated device "close the garage door" it is implicit that it is her garage door that she wishes to close. And should Alice be fortunate enough to own two houses with a garage, it is implicit that it is the garage door of the house she is presently using that she wishes to close.¶
The Mesh Device Catalog provides a directory mapping friendly names to devices that is available to all Alice's connected devices so that she may give and instruction to any of her devices using the same friendly name and expect consistent results.¶
Various schemes have been used to employ QR Codes as a means of device and/or user authentication. In many of these schemes a QR code contains a challenge nonce that is used to authenticate the connection request.¶
The Mesh supports a QR code connection mode employing the Encrypted Authenticated Resource Locator (EARL) format. An EARL is an identifier which allows an encrypted data object to be retrieved and decrypted. In this case, the encrypted data object contains the information needed to complete the interaction.¶
An EARL contains the domain name of the service providing the resolution service and an encryption master key:¶
mcu://maker@example.com/ED6B-KIW3-TSCC-P4LM-4D3I-IAPD-LE¶
The EARL may be expressed as a QR code:¶
An EARL is resolved by presenting the content digest fingerprint of the encryption key to a Web service hosted at the specified domain. The service returns a DARE Envelope whose payload is encrypted and authenticated under the specified master key. Since the content is stored on the service under the fingerprint of the key and not the key itself, the service cannot decrypt the plaintext. Only a party that has access to the encryption key in the QR code can decrypt the message.¶
Secure Internet Names bind an Internet address such as a URL or an email address to a Security Policy by means of a UDF content digest of a document describing the security policy. This binding enables a SIN-aware Internet client to ensure that the security policy is applied when connecting to the address. For example, ensuring that an email sent to an address must be end-to-end encrypted under a particular public key or that access to a Web Service requires a particular set of security enhancements.¶
Alice's regular email address (not a SIN).¶
A strong email address for Alice that can be used by a regular email client.¶
A strong email address for Alice that can only used by an email client that can process SINs.¶
Using an email address that has the Security Policy element as a prefix allows a DNS wildcard element to be defined that allows the address to be used with any email client. Presenting the Security Policy element as a suffix means it can only be resolved by a SIN-aware client.¶
One of the core objectives of the Mesh is to make data level encryption ubiquitous. While data level encryption provides robust protection of data confidentiality, loss of the ability to decrypt means data loss.¶
For many Internet users, data availability is a considerably greater concern than confidentiality. Ten years later, there is no way to replace pictures of the children at five years old. Recognizing the need to guarantee data recovery, the Mesh provides a robust personal key escrow and recovery mechanism. Lawful access is not supported as a requirement.¶
Besides supporting key recovery in the case of loss, the Mesh protocols potentially support key recovery in the case of the key holder's death. The chief difficulty faced in implementing such a scheme being developing an acceptable user interface which allows the user to specify which of their data should survive them and which should not. As the apothegm goes: Mallet wants his beneficiaries to know where he buried Aunt Agatha's jewels but not where he buried Aunt Agatha.¶
The Mesh supports use of Shamir/Lagrange secret sharing and recovery to split a secret key into a set of shares, a predetermined number of which may be used to recover the original secret. For convenience secret shares are represented using UDF allowing presentation in Base32 (i.e. text format) for easy transcription or QR code presentation if preferred.¶
To facilitate escrow and recovery, all the public key pairs and key shares associated with a Mesh profile are generated from a seed value using a deterministic algorithm. Thus, escrow of the seed value is sufficient to permit recovery of the private key data.¶
For example, Alice escrows her Mesh Profile creating three recovery shares, two of which are required to recover the master secret:¶
To recover the master secret, Alice presents the necessary number of key shares. These are used to recover the master secret which is used to generate the decryption key:¶
A user may choose to store their encrypted recovery record themselves or make use of the EARL mechanism to store the information at one or more cloud services using the fingerprint of the master secret as the locator.¶
The Mesh infrastructure is supported by a compact set of structures and protocols. These are discussed in detail in the Schema Reference [draft-hallambaker-mesh-schema] and Protocol Reference [draft-hallambaker-mesh-protocol] documents.¶
The JSON object model and JSON or JSON-B serialization [draft-hallambaker-jsonbcd] are used for all Mesh data structures. These include:¶
A DARE envelope containing a signed data object. Assertions include Profiles and Connections.¶
A self-signed assertion describing a Mesh principal. Principals include Accounts, Devices and Services.¶
Every profile specifies a profile signature key under which it is signed. The UDF fingerprint of the profile signature key is used as a unique identifier for the profile. Thus, all attributes declared in the profile such as authentication keys and encryption keys are bound to the unique identifier for the profile.¶
An assertion signed by one principal delegating rights to another. Connection assertions are used to bind devices to accounts and hosts to a service.¶
A DARE envelope encrypted under the encryption key of a principal that grant rights or capabilities to that principal. This is typically but not always achieved through use of threshold key techniques.¶
A DARE envelope signed by the sender that is encrypted under the encryption key of the intended recipient(s) whose content is a Mesh messaging object.¶
An object stored in a catalog that carries an identifier that is unique for that catalog.¶
Three Mesh actors are defined: Accounts, Devices and Services. Each of these is described by a specific type of profile.¶
Two types of Mesh account are currently specified: personal accounts and group accounts. For concise exposition, this document is limited to the description of personal accounts. Group accounts are specified in the Schema Reference [draft-hallambaker-mesh-schema].¶
A Mesh account is an abstraction which may be loosely regarded as the thing to which a collection of devices (in the case of a user account) or a collection of members (in the case of a group account) belong.¶
Each personal account profile specifies:¶
Used to authenticate the profile. Updates to the profile require use of the Profile Signature Key. The Profile Signature Key cannot be changed but a profile may be replaced by a new profile.¶
The UDF fingerprint of the Profile Signature Key. This is used as a unique identifier for the account.¶
The account name through which the profile is serviced.¶
UDF fingerprint of keys that are authorized to sign device connection assertions and update the Device Catalog.¶
Public parameters of the account signature key. This is the key that counterparties will use to verify messages sent by the account holder.¶
Public parameters of the account encryption key. This is the key that counterparties will use to encrypt messages sent to the account holder.¶
Public parameters of the account authentication key. This is the key that counterparties will use to establish authenticated exchanges with the account holder.¶
The public keys for encryption, authentication and signature specified in the account profile are the only keys that will (in normal circumstances) be visible to other Mesh accounts.¶
A Mesh Device is any device that is connected to a Mesh Account through a Device profile. A given physical device may have multiple device profiles associated with it but for the purposes of the Mesh, these are considered to be separate devices. A given device profile may be connected to more than one account¶
The device profile specifies:¶
Used to authenticate the profile. Updates to the profile require use of the Profile Signature Key. The Profile Signature Key cannot be changed but a profile may be replaced by a new profile.¶
The UDF fingerprint of the Profile Signature Key. This is used as a unique identifier for the device.¶
Public parameters of the device signature key share. This key share is used as a contribution to the signature key the device will use in the context of the account and to authenticate device connection requests.¶
Public parameters of the account encryption key share. This key share is used as a contribution to the encryption key the device will use in the context of the account and to decrypt activation records sent in response to device connection requests.¶
Public parameters of the account authentication key share. This key share is used as a contribution to the authentication key the device will use in the context of the account.¶
Optional information describing the device provided by the manufacturer. E.g. model, serial number, date of manufacture etc.¶
A Mesh Device is connected to an account through the creation of an activation record and a connection record.¶
The activation record contains key shares that are overlaid on the corresponding shares specified in the device profile to create the set of encryption, authentication and signature keys the device will use in the context of the account. Since the private keys corresponding to the device profile keys are only used to enable the connection of the device to an account, these keys are only trusted to a minimal degree.¶
In the ideal case, the device profile keys are fixed to the device such that they may be used to perform private key operations without the ability to extract the private key data from the device. Since the device profile is only trusted for the limited purpose of connecting the device to an account, the device profile may be created during manufacture without undue concern for either disclosure of the private key on the part of the account holder or a reputation attack alleging disclosure of the private key on the part of the manufacturer.¶
The device connection record is functionally a certificate that the device may use to interact with the Mesh Service or to other devices connected to the same account. Note however that use of threshold cryptography means that Mesh devices would not normally present their device connection record to any other party since all communication with external parties takes place through the keys published in the account profile.¶
A Mesh Service is an abstract network service that is provided by one or more hosts. The properties of the service are described by the service profile.¶
The service profile specifies:¶
Used to authenticate the profile. Updates to the profile require use of the Profile Signature Key. The Profile Signature Key cannot be changed but a profile may be replaced by a new profile.¶
The UDF fingerprint of the Profile Signature Key. This is used as a unique identifier for the device.¶
Public parameters of the service signature key. This is the key that counterparties will use to verify messages sent by the service.¶
Public parameters of the service encryption key. This is the key that counterparties will use to encrypt messages sent to the service.¶
Public parameters of the account authentication key. This is the key that counterparties will use to establish authenticated exchanges with the service.¶
Hosts are Mesh Devices that have been granted a Host Activation and Host Connection by a service administrator. These are used in the same fashion as the device activation and connection records.¶
Mesh Stores are append-only sequences that are used to represent collections of objects, messages and data. All Mesh stores are implemented as DARE Sequences authenticated by means of a Merkle tree. The payload of each envelope in the sequence is usually encrypted.¶
Two types of Mesh store are currently defined:¶
A set of Mesh objects, each of which has an identifier that is unique in the scope of the catalog. Objects may be added, updated, and deleted.¶
A sequence of Mesh Messages.¶
All the state represented within a Mesh account is contained in Mesh stores bound to the account. Thus, to synchronize a device to the state of the account, it is sufficient to synchronize the collection of stores the device is permitted to read. Since every store is an append-only sequence, it is sufficient for the Mesh service to return the envelopes added to each of the stores since the device was last synchronized.¶
Rapid synchronization of catalogs and spools is ensured by limiting the size of entries to each. Implementations may further improve performance by redacting stores to remove obsolete entries that have been updated or deleted. Alternatively, a device may maintain a complete record of the state of the store to allow erroneous changes to the store to be unwound.¶
Mesh Catalogs track a collection of entries. Every Mesh account contains a Threshold Catalog that is used by Mesh services as the source of access control policy. The Threshold Catalog is unique in that it is the only catalog whose contents can be read by the Mesh Service. Every other Mesh Catalog connected to a Mesh account is end-to-end encrypted so that it can only be read by devices connected to the account.¶
The Mesh specifies various catalogs that are used to track information relevant to a Mesh Account:¶
The devices connected to the corresponding Mesh profile.¶
Logical and physical contact information for people and organizations.¶
Web bookmarks and citations.¶
Username and password information for network resources.¶
Appointments and tasks.¶
Network access configuration information allowing access to wireless networks and VPNs.¶
Configuration information for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH.¶
A catalog that is readable by the Mesh Service that is used to determine access to account resources including device access rights, threshold keys and message delivery.¶
Each catalog connected to an account has a unique identifier of the form mmm_<<name>. Applications may specify additional catalogs without risk of collision with future Mesh catalogs by using an appropriate IANA assigned protocol label.¶
Mesh services communicate with Mesh devices and other Mesh Services through the Mesh Service Protocol. Despite the wide range of Mesh functionality, the Mesh protocol is remarkably compact. The bulk of the semantics associated with the Mesh are expressed in the schemas describing Mesh Messages and Catalogs. The objective of reducing the degree of trust in the Mesh service to the absolute minimum by necessity requires that the Mesh Service be extremely simple.¶
Mesh Service Protocol transactions are divided into the following groups:¶
The Hello transaction returns a description of the service including information used to authenticate future interactions with the service.¶
The Create and Delete transactions are used to bind an account to a service.¶
The Connect and Complete transactions are used to connect devices to an account¶
The Status, Download and Transact transactions are used to update stores connected to an account.¶
The Post transaction is used by one Mesh Service to transfer a message from one of its users to a different Mesh Service serving one of the recipients.¶
The Publish, Claim and PollClaim transactions are used to publish and retrieve data objects through an account.¶
The Operate transaction requests that the service performs a cryptographic operation on behalf of the account. This is used to provide execution of threshold operations on behalf of the account holder for both internal and external users.¶
Future versions of the Mesh Service Protocol may support additional transactions to support features such as providing DNS resolution.¶
Every Mesh Service Protocol transaction consists of a single request from a Mesh client followed by a single response. Requests and responses are authenticated and encrypted under a key established between the client and the service. This application layer enhancement is in addition to any transport layer enhancement that may be employed (e.g. TLS).¶
Mesh Service Protocol messages may be exchanged through any binding advertised by the service by means of the Hello transaction. Currently only one binding is defined, mapping Mesh requests and responses to the content data of HTTP POST requests and responses layers over a TLS transport.¶
While the use of up to three layers of encryption may be regarded as excessive, each layer provides separate protections:¶
Provides confidentiality for metadata and limited traffic analysis protections.¶
Encryption and authentication of requests and responses using keys bound to the specific device and service performing the interaction provides the basis for access control.¶
Encryption of stored data (catalog data, device activations, etc.) provides end to end security between the devices connected to the account.¶
The Access Catalog of a Mesh account is the only catalog whose payload contents are readable by the service. This is necessary because the catalog provides the sole source for the authorization component of the access control policy for the account.¶
Each entry in the catalog specifies an operation that the service will perform when it receives a request that is authenticated and authorized by the access control policy specified in the entry. Operations include:¶
Account operations such as operations on stores (Status, Download, Transact) require that the client be authenticated by means of an authentication key that has a matching entry in the Access catalog that authorizes the operation.¶
Messages received by the service that match the specified criteria will be appended to the inbound message spool.¶
Performs a threshold key splitting operation of a private key held by the service and encrypts one part under a key known only to the service and encrypts the other under a public key specified by the party making the request.¶
Performs a key agreement operation on a private key held by the service. This may be used as a component in a threshold key agreement scheme.¶
Performs a signature operation on a private key held by the service. This may be used as a component in a threshold signature scheme.¶
These operations provide the vocabulary from which a Threshold Key Infrastructure is built. Keys that are bound to a service using threshold techniques can only be applied with the co-operation of that service.¶
Mesh devices connected to an account interact with the Mesh Service through the Mesh Service protocol. Mesh devices interact with other Mesh devices through the Mesh Messaging Protocols, each of which provides a distinct application functionality:¶
Each of these protocols is described in depth in the Mesh Protocol Reference [draft-hallambaker-mesh-protocol].¶
Mesh Messages provide a means of communication between Mesh Service Accounts with capabilities that are not possible or poorly supported in traditional SMTP mail messaging:¶
Note that although Mesh Messaging is designed to facilitate the transfer of very large data sets, the size of Mesh Messages themselves is severely restricted. The current default maximum size being 64 KB. This approach allows Mesh¶
In addition, the platform anticipates but does not currently support additional cryptographic security capabilities:¶
While these capabilities might in time cause Mesh Messaging to replace SMTP, this is not a near term goal. The short-term goal of Mesh Messaging is to support the Contact Exchange and Confirmation applications.¶
Two important classes of application that are not currently supported directly are payments and presence. While prototypes of these applications have been considered, it is not clear if these are best implemented as special cases of the Confirmation and Contact Exchange applications or as separate applications in their own right.¶
Messages exchanged between Mesh Users MUST be mediated by a Mesh Service for both sending and receipt. This 'four corner' pattern permits ingress and egress controls to be enforced on the messages and that every message is properly recorded in the appropriate spools.¶
For example, to send a message to Alice, Bob posts it to one of the Mesh Services connected to the Mesh Account from which the message is to be sent. The Mesh Service checks to see that both the message and Bob's pattern of behavior comply with their acceptable use policy and if satisfactory, forwards the message to the receiving service example.com.¶
The receiving service uses the recipient's contact catalog and other information to determine if the message should be accepted. If accepted, the message is added to the recipient's inbound message spool to be collected by her device(s) when needed.¶
For efficiency and to limit the scope for abuse, all inbound Mesh Messages are subject to access control and limited in size to 32KB or less. This limit has proved adequate to support transfer of complex control messages and short content messages. Transfer of data objects of arbitrary size may be achieved by sending a control message containing a URI for the main content which may then be fetched using a protocol such as HTTP.¶
This approach makes transfers of exceptionally large data sets (i.e. multiple Terabytes) practical as the 'push' phase of the protocol is limited to the transfer of the initial control message. The bulk transfer is implemented as a 'pull' protocol allowing support for features such as continuous integrity checking and resumption of an interrupted transfer.¶
The Mesh provides an infrastructure for supporting existing Internet security applications and a set security features that may be used to build new ones.¶
For example, Alice uses the Mesh to provision and maintain the keys she uses for OpenPGP, S/MIME, SSH and IPSEC. She also uses the credential catalog for end-to-end secure management of the usernames and passwords for her Web browsing and other purposes:¶
The Mesh design is highly modular allowing components that were originally designed to support a specific requirement within the Mesh to be applied generally.¶
Since a wide range of network applications may be reduced to synchronization of sets and lists, the basic primitives of Catalogs and Spools may be applied to achieve end-to-end security in an even wider variety of applications.¶
For example, a Spool may be used to maintain a mailing list, track comments on a Web forum or record annotations on a document. Encrypting the sequence entries under a multi-party encryption group allows such communications to be shared with a group of users while maintaining full end-to-end security and without requiring every party writing to the spool to know the public encryption key of every recipient.¶
Another interesting possibility is the use of DARE Sequences as a file archive mechanism. A single signature on the final Merkle Tree digest value would be sufficient to authenticate every file in the archive. Updates to the archive might be performed using the same sequence synchronization primitives provided by a Mesh Service. This approach could afford a robust, secure, and efficient mechanism for software distribution and update.¶
The security considerations for use and implementation of Mesh services and applications are described in the Mesh Security Considerations guide [draft-hallambaker-mesh-security].¶
This document does not contain actions for IANA¶
Comodo Group: Egemen Tas, Melhi Abdulhayo?lu, Rob Stradling, Robin Alden, Michael Richardson.¶
Appendix A: Outstanding Issues¶
The following issues need to be addressed.¶
| Issue | Description |
|---|---|
| Recovery | Expand explanation and example to show applications being recovered. |