[Cryptography] The Mathematical Mesh

[Phillip Hallam-Baker]

Some of you will have seen this on other lists. My approach is
probably less of a surprise to people here.

I haven't yet finished the description of how this works but the
answer is pretty much, 'how would you do this if you were not shy of
using a very large number of public key pairs'. In the example shown,
12 keypairs are generated.

If you think of a cryptographic system as an animal, a cryptographic
keypair signing another keypair is sort of like a joint. I introduce
'joints' into the architecture at every point where I need a new point
of articulation, a separation of concerns.


Project Website: PrismProof.org
The project WebSite has links to the GitHub repository (MIT License),
the Internet Drafts and podcasts demonstrating the Mesh in use.


As most of you know, for the past couple of years I have been working
on a way to do secure email in a completely painless manner. It should
be exactly as easy to send secure mail as insecure. When you are
starting your car you do not need to remember to press the button
marked 'do not explode'. But that is what we demand of users when we
require them to click the 'encrypt message' button to do S/MIME or
OpenPGP.

I did a demo of that scheme 18 months ago. Since then I have been
looking at the problem of how to persuade people to change to a new
email infrastructure. My conclusion being that secure email isn't
going to be enough.

The only way we are going to get a billion people using secure
Internet applications is if doing so makes using the computer easier.

This seemed like an impossible challenge until I realized that:

1) Most users have multiple devices these days
2) Configuring devices is fiddly and complex enough without cryptography
3) We can use strong end-to-end cryptography to make the process of
transferring configurations from one device to another very, very
easy.

4) Manufacturers make money by selling more devices to existing
customers. Anything that makes it easier for a potential customer to
part with their cash is going to be interesting to a large number of
vendors.


The breakthrough came when I realized that instead of just putting a
user's S/MIME and OpenPGP keys into a profile, we could put all the
configuration data for email into a profile. So when Alice buys a new
laptop, she can configure it to use all her email, instant messaging,
VOIP, VPN, SSH, etc. etc. accounts in one go.

For years, the IETF has had the attitude 'we don't do UI'. Well maybe
that is the right approach after all because most times if you are
presenting the user with UI, you are doing it wrong. The Mesh allows
all the configuration decisions a user has to make to be gathered into
one place and administered from there. I can manage my 3 laptops, 4
desktops, 2 phones, 4 tablets and the watch from one machine.

There are of course obvious applications of this approach to IoT. The
biggest challenge in IoT is how to connect to the user's 'management
console' which currently doesn't exist. There are obvious enterprise
applications as well. But I think we need to build up experience of
using the mesh in standalone mode before going down those paths.


I chose secure email because it is the hardest problem to solve. If I
can configure a machine to use the S/MIME built into the current
release of Windows Live Mail and Outlook without the user having to
think about the process, we can support pretty much any application
protocol. In particular:

* Web password manager,
* SSH configuration
* OpenPGP
* VPN configuration

I have 100s of Web site accounts, most of which have the same weak
password because I don't actually care about them. Yes, there are many
proprietary password managers but I really wouldn't ever use them for
anything I relied on because I don't know how they are secured, I
can't audit them.

SSH is easy to congiure insecurely, thust create one keypair and copy
it to every machine. Using SSH with separate keys on each machine is a
lot more involved. And it is a hard bootstrap problem because you are
trying to configure a machine to do things securely before you have
security. Most people I know who do this right and have separate keys
on every machine and rotate them regularly do so with custom written
scripts. I would much rather trust a reviewed standards based protocol
than a script.

OpenPGP is of course one of the applications that must be supported. I
don't support it right now because configuring closed source
applications is actually the harder test.

VPN configuration is something that should have been solved long ago
but has not. Every corporate VPN I have used has required me to use a
proprietary or add-in client for access. Which is really strange when
Windows and OSX ship with IPSec built in. Configuring a VPN as a
remote user is absolutely no fun at all. It requires multiple emails
and phone calls and even then may not work at all.


The Mathematical Mesh is an untrusted cloud service that supports two
principal functions:

1) A place for users to store encrypted configuration 'profiles' for
their accounts and applications.
2) An infrastructure through which they can publish public aspects of
that profile to allow others to interact with them.

At present we are focusing on applications that only require the first
function. But the architecture of the Mesh is mostly designed to meet
the requirements of the second. The Mesh does not offer any
confidentiality guarantees, in fact it is assumed that all the bits
that are published to the Mesh are made public:

We distrust governments, corporations and users.
We believe in strong cryptography and secret keys.

Currently all the data in the Mesh is encrypted under RSA2048 and
AES256. That will change to CFRD448 when the spec is fully baked and
code is available.

As with DNS, it is of course possible to run the Mesh in a completely
stand-alone fashion. But if you want to be able to communicate with
anyone at all, you want your data to be available to anyone at all.
That is the role of the Inter-Mesh. So my email

Users access the Inter-Mesh through a portal provider. These providers
act as abuse filters for the Mesh. That is important because the Mesh
runs as a blockchain: every byte that is added to the Mesh must remain
there in perpetuity. There are ways to avoid someone deliberately
tainting the Mesh logs with kiddie porn or other prohibited material.
But if a user is allowed to to a billion transactions in an hour,
there is going to be a few gigs of transaction log that have to be
maintained forever.

A user can change their portal provider at any time however. There is
no 'lock in' effect.


Each mesh user has a master profile that can in principle be used
their entire life. This profile has a master key that is used to sign
updates to the master profile. The master profile then signs an
administrative profile which in turn...

In short, there is a lot of crypto going on. And each one of those
crypto steps is used to meet a very specific user requirement. One of
the big mistakes in traditional PKI was to think that some features
are for 'experts'. Key escrow for example, you want to be able to get
your data back if a machine fails. So key escrow has to be offered as
an option. But isn't the novice user at least as likely to blow up
their machine config and lose all their data as an 'expert'. In fact
using crypto *without* escrow is the thing that should be left to the
experts.

We could not have done something like the Mesh in 1995. Each user has
a personal PKI with four levels. In 2016 that is no burden at all even
with RSA2048 and it is even faster with CFRG448.

The Mesh provides for recovery of the user's private key. User's are
not required to use this feature but it is recommended. I do have
material that I would rather lose than have disclosed. But I would
rather the vast majority of my data was disclosed than risk losing it.
So I use escrow keys knowing that there is some risk of being coerced
to disclose.