[Cryptography] Keeping backups (was Re: Separating concerns

Thu Aug 29 17:51:02 EDT 2013

On Thu, Aug 29, 2013 at 1:30 PM, Perry E. Metzger <perry at piermont.com>wrote:

> On Wed, 28 Aug 2013 20:04:34 +0200 Faré <fahree at gmail.com> wrote:
> > One thing that irks me, though, is the problem of the robust, secure
> > terminal: if everything is encrypted, how does one survive the
> > loss/theft/destruction of a computer or harddrive?
>
> So, as has been discussed, I envision people having small cheap
> machines at home that act as their "cloud", and the system prompting
> them to pick a friend to share encrypted backups with.
>
> Inevitably this means that said backups are going to either be
> protected by a fairly weak password or that the user is going to have
> to print the key out and put it in their desk drawer and risk having
> it lost or stolen or destroyed in a fire.
>
> I think I can live with either problem. Right now, most people
> have very little protection at all. I think making the perfect the
> enemy of the good is a mistake. If doing bad things to me requires
> breaking in to my individual home, that's fine. If it is merely much
> less likely that I lose my data rather than certain that I have no
> backup at all, that's fine.
>
> BTW, automation *does* do a good job of making such things invisible.
> I haven't lost any real data since I started using Time Machine from
> Apple, and I have non-technical friends who use it and are totally
> happy with the results. I wish there was an automated thing in Time
> Machine to let me trade backups with an offsite friend as well.
>

Now this is an area where QR codes might be useful

First point of simplification is that we only ever need to worry about
symmetric key backup since we can always add a private key to the rest of
our encrypted archive. We can encrypt the key and backup the encryption key
or we can use a deterministic keygen algorithm and escrow the seed. either
way we only need to escrow 256 bits.

Second point is that we can reduce exposure to risk by using some sort of
key splitting scheme. We can also use this to effect key transport between
devices. The problem with 'end to end' encryption these days is that most
of us have multiple devices we receive email on, which is why WebMail has
become so attractive.

I have to be able to read my email on any of my 5 principal machines
(Windows, 2 MacBooks, iPhone, iPad). Any email scheme that does not support
all of them is useless.

Third point of simplification: ditch key rollover. Don't expire a key
unless it is necessary because of a suspected or known compromise. Use a
sufficiently strong key to make cryptanalysis infeasible.

I know that key rollover is part of the ideology but it introduces more
vulnerability than it eliminates. Any encryption key you have that ends up
compromised is likely a maximum damage situation. So using ten keys in ten
years gives the attacker ten opportunities to compromise you if you muck up
the distribution or they manage to compromise a CA.

Fourth point of simplification: Just duplicate the key into every end point
rather than attempting a key service with split control and key shares.

A better way to manage crypto in a mobile device like a phone would be to
split the prime into two (or more parts) for each mobile device to be
enabled. To decrypt data the device would have to ask a service(s) with the
other part(s) of the key to do their work and then combine with the local
result.

So lets imagine the full key establishment sequence from the user's point
of view.

Key Generation.

To generate my first key, I tell my MUA my email address and the CA domain
name[1]. It checks to see if the email address already has a key
registered. If so it will ask if I am really, really sure I want to replace
it etc. Otherwise it generates for me a new keypair.

The CA is hopefully going to do validation of my key before issuing the
certificate. At minimum an email callback. We might push the encrypted
escrowed key out to the CA at the same time. But that is orthogonal to the
private key backup and distribution.

To backup the key we tell the device to print out the escrow data on paper.
Let us imagine that there there is a single sheet of paper which is cut
into six parts as follows:

1) Three copies of the encrypted private key, either as raw data or a link
to the raw data.

2) Three key shares allowing the key to be reconstructed from 2 of them.
For a 256 bit key that would be no more than 512 bits doing it the simple
way and there is probably a cleverer encoding.

The data for each would be presented as both a QR code (for installing in a
phone) and a BASE32 alphanumeric code (for installing on a machine without
a camera.

The user can easily escrow the keys by cutting the paper into 3 parts and
storing them in an acceptably safe location.

In my case that would probably mean mailing the shares to my parents and
family for offsite backup. Or I might give them to my broker or a bank or...

Banks are quite possibly going to be interested in helping this type of
scheme because it helps them meet their own commercial goals.

Escrowing a key share with my bank means that I may be subject to a
warranted intercept. But that is lightyears from the abuses PRISM allows
the government to commit. And in any case every device I have that can read
email has a copy.

To enable a new device I either ask one of my existing devices to print out
a new distribution paper or pull them from the safe. I can use them in a
cell phone with the camera or on a desktop by typing them in. Exposure can
be limited in this case by deleting the encrypted key rather than keeping
it.

[1] All Key Signers are a CA by definition. All CAs must have a domain name
to support the enrollment protocol but someone can set up their own CA if
they have a domain name (even if that domain name is local.)

-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130829/80a54587/attachment.html>