[Endymail] Parts of the problem - managing private keys

[Phillip Hallam-Baker <[e-mail]>]

Lets drill down on some of the parts of the problem that are not 'trust'.

One of the biggest problems for end users is managing private keys.
And quite often this problem gets exported back into the 'trust' area
by deciding the answer to 'what happens if the user forgets a
passphrase' be 'let them reboot their trust network from scratch'.


I like the concept of using a fingerprint of a public key as the
lynch-pin for the trust infrastructure. Every trust infrastructure
proposed to date can deliver a key fingerprint as output. They are
short and convenient.

What I don't like is having to work out mechanisms for rebooting the
trust network in the case that a passphrase is forgotten or the like.
So I want to give the end user the tools that allow them to make that
as infrequent as possible. I want it to be possible for a user to keep
their master public key life long.

Email isn't the only thing that we are going to hang off this
infrastructure. Lets imagine our user decides to take nude pictures of
themselves and store them in the cloud. If they are sensible, they
likely want to have some form of encryption in place.


When I looked at the set of requirements that result, they look pretty
much the same as the requirements for running an embedded root key for
a CA because, well that is what we are doing. We are giving the end
user a personal PKI hierarchy with themselves at the root of trust.

So this is the current hierarchy I give people. [NB please just assume
I don't do anything stupid here as this is an abbreviated version]


Master key - self signed cert valid 30 years
Sub key - cert signed by master, valid 10 years

Use keys (Minimum) all signed by sub key

* Common encryption key valid 3 months
* Per device signature key valid 5 years for use in authentication
* Per device encryption key for use in distributing keys.


Now this might seem to be a lot of keys but it isn't a problem because
the user does not need to be aware of this complexity. As far as they
are concerned they just have one key.

Separating the concerns like this solves a lot of problems. I don't
worry too much about revocation because we can deal with that by
rotating the encryption keys. Just stop giving the device new
decryption keys if it is lost.

I make no assumptions about how the keys are stored on the machine. I
do not approve of mandatory passphrases. If people really have secrets
so important they worry if they lose their device then they will use
the locking function on their device.

The only key I escrow right now is the master key. And that is
encrypted under a session key which is then split in two. Right now we
are just using 2 way XOR splitting and BASE-32 encoding. But QR codes
would be better.



I am currently working on the code for an escrow scheme where the
encrypted private key would be stored on a service which will only
release it to someone who can provide proof they know the decryption
key. This eliminates the need to depend on the user not loosing their
encrypted key blob.

Moving keys from one device to another is just a matter of sending
each device a message with the new decryption key encrypted under
their per device encryption key.

What I have not yet really looked into is how we escrow the encryption
keys for messages. I was thinking we would have a master decryption
key and escrow that. But I can imagine people wanting to have multiple
keys for different email accounts with different policies attached.


So for example if you are a journalist you might well want to not use
escrow at all.

There are also concerns for what happens when you die. So for example
you might want your heirs to know where you buried aunt Miranda's
jewelry and give then the info on how to retrieve that key. But you
would likely want to take where you buried Aunt Miranda to the grave
with you.


So I am now thinking of adding in additional keys that would be
encryption escrow keys that were backed up in the same way as the
master. i.e. encrypted in the cloud by default but with the option of
keeping the binary blob yourself.