From: Kent Crispin <kent@songbird.com>
Date: Sun, 11 May 1997 17:57:57 +0800
To: cypherpunks@cyberpass.net
Subject: Re: key recovery vs data backup
In-Reply-To: <19970508192011.29178@bywater.songbird.com>
Message-ID: <19970511024334.53652@bywater.songbird.com>
MIME-Version: 1.0
Content-Type: text/plain


I addressed many of your issues in another post, so I will be 
relatively brief...
On Sun, May 11, 1997 at 10:24:46AM +0200, Alan Barrett wrote:
[...]
> There are many similarities between your idea of a "key safe" for CAK
> (corporate access to keys), and the idea espoused by Carl and others
> of encrypting everything to a corporate key as well as to the other
> recipients.
> 
> If the corporation expects to be successful at forcing it's staff to run
> special software that talks to the CAK key safe, then the corporation
> should also expect to be successful at forcing its staff to run special
> software that adds the special coprorate key as a recipient of all
> encrypted messages.

True.

> If the corporation expects to be successful at keeping the keys to the
> CAK key safe secure, while still allowing an appropriate coalition of
> high level managers to get access to the contents of the key safe,
> then the corporation should also expect to be successful at keeping
> the private part of the corporate key secure, while still allowing
> an appropriate coalition of high level managers to use the special
> corporate private key to decrypt messages.
>
> If the coproration trusts those with access to the CAK key safe not to
> abuse their access, then the corporation should also trust those with
> access to the special corporate key not to abuse it.

Not true.  The activities are quite different in detail.  In the 
multiple recipients (MR) case the coalition keymeisters get together to 
decrypt a single document; in the key safe (KS) case the keymeisters get 
together to decrypt a key, which can then be used to decrypt many 
documents.   In the multiple recipient case, therefore, the master 
key is potentially used quite frequently, and hence much more 
exposed.  There are many other differences: I won't try to go into 
detail here.

The frequent use of the master key is a major problem, because in the 
MR case, when a master key is compromised every document in the 
company is exposed; whereas in the KS case, given appropriate 
security around the keysafe, it is not anywhere as much of a problem.

> > With this background, perhaps now you can see why I say that Carl's
> > solution doesn't even address the problem.  The problem is management
> > of complexity.  Carl says "encrypt to Acme Corp".  Who in Acme Corp?
> > What part of the organization that is Acme Corp is authorized to know
> > this particular bit of information?
> 
> Whatever the answer to the latter question is, it's the same in the CAK
> case as it is in the "encrypt to a special coprorate key" case.

Not if the encryption client encrypts to different company recipients
depending on a policy (which one might want if one tries to limit the 
compromised master key problem described above.)  Then the policy, 
contrary to what you state below, must be reflected in the client.

> > Because some of the employees are idiots you want this
> > built automatically into the application they are using for
> > encryption/email/whatever.  How does this software know what policy
> > is appropriate for which employee?  How is that policy distributed?
> > What is the interface that allows a policy to be defined?  How do you
> > protect the policy definition from subversion?
> 
> The same problems arise in the CAK case.  And the same solution: you
> make the user's software do the same thing every time, and implement the
> policy elsewhere.

Sigh.  The situations are really quite different.  In the KS
case the policy never impacts the software; in the MR case I don't 
think you can avoid it.

> > Access to the key-safe is critical, of course, but it can be made very
> > secure -- a special-purpose piece of hardware that requires passwords
> > from n out of m key czars before access is granted, for example.
> > Or the contents of the key safe can be encrypted via keys escrowed
> > through a secret sharing mechanism
> 
> The same problems and solutions apply in both the CAK case and in the
> "corporate key as extra crypto recipient" case.

Not at all.  The corporate master key is used to decrypt documents in the 
MR case; in the KS case the master key is used to get to the key 
database.  Two totally different functions, two totally different 
security paradigms.  The old saw -- you can either hide your eggs all 
over the case, and hope not too many of them get found, or you can 
put them all in one basket and guard the basket.

> Now, having spent some time attempting to show that the two cases are
> almost identical in many respects, let me point out a few ways in which
> I think encrypting to a special corporate key is better than CAK.
> 
>   - With CAK, the key safe contains at least a copy of every key used by
>     every staff member.  All that needs to be kept secure.  This storage
>     problem does not arise in the non-CAK case.

But a relatively straightforward storage problem, really.

>   - With CAK, every time a user creates a new key, the user's software
>     needs to talk to teh key safe.  This needs a secure channel, which
>     raises further authentication problems (how does the user know that
>     he's not talking to a fake key safe).  These don't arise in the
>     non-CAK case.

Not so.  You have to exactly the same issue -- how does the user find 
out the master key to encrypt to?

>   - Once a CAK infrastructure is in place, it is likely to be easier
>     for a government to impose GAK.  It's better not to set up the CAK
>     infrastructure in the first place.
> 
>     To be fair, similar arguments apply to the "add an extra crypto
>     recipient" case: just add two extra crypto recipients (corporate key
>     and big-brother key).  But I think that the general public is more
>     likely to understand what the government wants and to reject the
>     idea in this case than in the GAK case.

Arguable.  Guv won't say "everybody has encrypt every file to the
government key".  Instead they will insist that the corporate master
key be escrowed.  Any master key is an easy target.  And they will
have very good excuses for it -- corporations are public entities, tax
records, etc, so I don't think the public will get worked up about 
it.  Corporations won't, either.

Note that the keysafe model doesn't really need a master key -- it 
will work with just good physical security.  In that case the Gov 
would just issue a subpoena, I guess.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html