Subject: [Lurk] Objectives, use cases, requirements, solution approaches.

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 4 Mar 2016 10:34:50 -0500

Sorry for the length of this, I have been working on a very similar
problem for a long time now:

I have been out of pocket for a while as I have been working on
getting the documents written up for the Mathematical Mesh. At this
point it is not clear to me whether the Mesh is or is not relevant.
The information is at http://prismproof.org. The new specs should be
up next week.

Rather than start with requirements or even use cases here, I think we
need to first start with the overall objective:

Objective: Minimize exposure of private keys when performing
cryptographic operations on untrusted machines.

This is a problem that recurs in many use scenarios:

* I offload my TLS secured Web Site to a CDN [Authentication]

* I read my S/MIME or OpenPGP mail in a Web browser on an untrusted
machine [Confidentiality, Authentication]

* I am sending DKIM mail through an email egress filter. [Authentication]

* Any time that a key is going to be installed on a mobile device that
may be lost. [Confidentiality, Authentication]

* Software signing, lots of malware gets tracked down to certificates
issued to legitimate software providers where the programmer lost
control of the private key.

Which use cases you decide are in scope and the security issues you
decide are important has a big impact on your solution space.

If we take Stephen's 'TLS on CDN' use case. What is our security concern?

A) The CDN can continue to use the private key after the site has
transferred to another host.

B) The CDN can authenticate as the certificate subject.

If we are only concerned about (A) then the answer is ACME and short
lived certificates. We can narrow the exposure window to a day or even
hours if we trust clients to have accurate clocks. If the concern is B
then I want to see more explanations because I strongly suspect that
the real requirement is to have multiple level authentication. In the
Mesh I have signed objects that are potentially authenticated at the
HTTP payload level with a MAC that are then wrapped in a TLS tunnel.
And no, I don't think that excessive.

I have been playing about in the lab with some Raspberry Pi computers
and the Mesh. The idea is that I start of with an off the shelf
Raspberry Pi computer and an almost standard operating system release
on an SD card with a little bit of bootstrap crypto in it. When I
start the machine it knows where to connect to and has a 'bootstrap'
authentication key that demonstrates it is a machine I am authorizing
to connect to 'my stuff'. After it has connected, the device discovers
it is to be a mail server or a DNS server or (more typical for me) the
control board that is operating the internals of one of the daleks or
K9 (BB8 to come).

So the way I would apply the Mesh to the CDN use case is that I would
create a Master profile for the Web site I was managing, Each CDN host
machine that might serve the Web site would have a Device profile. As
the administrator, I would connect the Device profile to the Master
profile when it was to start serving my Web site and populate the 'Web
Site' application profile with the configuration info for the site
itself and the configuration info for the TLS. That might be an
authentication key that let it apply for a certificate or the
certificate itself.

So far I am not convinced that I need the 'crypto on a stick' protocol
that Stephen is proposing for the CDN/TLS use case. But there are use
cases where I have looked into building something very similar.

Here there is an IPR caveat that there are some patents I am aware of
that might have claims that might cover some parts of what I describe.
But they expire in 2017 so I am not too worried about them. What the
patents and the CFRG curve work have meant is that this is a part of
the Mesh design that is still in my head and not implemented in code.
The CFRG work is relevant because these techniques only work for
Diffie Hellman based public key crypto.

The particular problem I was considering comes up in S/MIME, OpenPGP
and any type of document rights management system. Lets say I am the
director of the NSA and I want my operations directors to encrypt
their powerpoint files so that I can read them, so can anyone I give
access to now or in the future but the 29 year old system admin we
hired from the temp agency cannot.

Here there is a very useful, almost magical technique that was
invented by our friend Matt Blaze. He gave a presentation on it at the
Dallas IETF in 1996 or so (or at least so I recall, it might have been
some other time). And we completely ignored the potential.

What proxy re-encryption 'recryption' allows is that Alice can
configure a server S so that a message sent to the server with a
decryption blob for Alice's decryption key can be resent to Bob, Carol
and Doug with decryption blobs for their decryption keys without
decrypting and re-encrypting. The server has the ability to transmute
keys but not to decrypt the message.

So the way I plan to use it in the Mesh is that say Alice wants to
read her mail on her iPhone, iPad, laptop, watch, desktop and ring.
That is six devices. Three of which are quite likely to be lost or
stolen. But Alice doesn't want anyone to know about all that. She only
wants to have one email encryption key published for OpenPGP/SMIME at
a time.

Each device has its own device profile and its own decryption key
within the Mail profile. one or more email administration devices have
access to the actual email encryption keypair (hopefully the desktop
that is not likely to be lost or a mobile device she keeps in a safe).
When an email device is attached to the mail profile, a recryption key
is generated for that device that allows the mail server to calculate
recryption blobs for each of the devices permitted to read email.

What this means is that 1) if any of the devices is lost, the window
of vulnerability can be narrowed to the cached data on the device and
already decrypted and 2) Alice has full access to her email on all her
devices and is in full control.

Now making this happen depends on having client side public keypairs
deployed. And some folk are going to be complaining that this is all
too complex and 'too difficult to use'.

No, this system is far, far easier for the user than current systems
where the user is not using S/MIME or OpenPGP. I am using a personal
PKI to distribute the email configuration settings.

My approach has a lot more crypto going on than a traditional S/MIME
implementation. But it is a lot easier for the user to operate as a
result.

The cars I drive regularly were built in 1999, it has four separate
CANBUS networks, 50+ computers and the workshop manual comes on a
CDROM. But I don't see any of that complexity when I drive it. I sit
in my seat and the car automatically adjusts the steering wheel, seat,
mirrors etc. to my preferences.

Now consider the challenge of driving a Model T Ford. Most of us
probably couldn't even start the engine without running ourselves
over. The car would creep forward in some circumstances if nobody was
on the pedals. The Model T is a lot simpler than a modern car. It has
maybe a tenth of the number of parts. But it is a lot more complicated
for the operator and even for someone maintaining it. A Model T
requires a major overhaul every 3000 miles. A modern car can go five
yeas and 50,000 miles without the same sort of major service.

This is completely turnkey crypto. The user is doing S/MIME and they
don't need to know anything about it. When they connect a device to
their Mesh profile, it is a one time operation and from that point on,
all the network configuration (and potentially all aspects of machine
admin) can be controlled from an administration device for that
profile.

Right now my immediate focus is getting the stuff running on Linux and
adding support for SSH. Setting up SSH right is actually much harder
than it sounds because of the bootstrap problem. You need the SSH
tunnel to that machine before you can start setting up SSH. With the
Mesh, I hope to make configuring SSH on a headless machine much easier
(thanks to David Clark for suggesting I should look at that problem).

So I am not sure what to do as far as next steps go. I will be in BA.
I will be bringing equipment that lets me demonstrate the Mesh. I am
not yet ready to propose a WG or a BOF. But demonstrating the Mesh at
a Bar BOF might well be useful (if we are not too late for that).

This is already too long. I will just note that if you do want to do
crypto on a stick, then you might want to also consider the split key
generation scheme I presented in Prague.