Re: key recovery vs data backup

[Kent Crispin <kent@songbird.com>]

On Wed, May 07, 1997 at 09:56:21PM -0700, Lucky Green wrote:
> At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
> >I was saying that if Sam needs to read my encrypted file/mail, then I should 
> >list Sam as a crypto-recipient.  If Acme,Inc. needs to read my encrypted 
> >file/mail, then I should list Acme,Inc. as a crypto-recipient.
> >
> >There's no safe of keys.  It's even simpler to explain to an executive.
> 
> Several people on this list asked me to elaborate on my claim that KR is
> not required. I doubt that I could put it more succinctly than Carl has in
> his post.

Unfortunately, it doesn't solve the problem at all.  In fact it
doesn't even address the problem.  So much so that reading these
replies makes me think that I am looking at different problem than
you. 

So perhaps backing up to discuss the problem a bit would be helpful. 
I hope you will forgive me if this is old ground.  

The problem is key management for an organization.  

The keys are used to protect and authenticate data owned, not by any
individual, but by an organization.  Keys are generated for the
organization's purposes, not the purposes of any individual. 
Furthermore, the individual privacy of an individual who works for an
organization is not a necessary priority for the organization. 

Organizations are composed of many individuals, some of which may not
share the goals of the organization, or who may indeed be inimical to
the organization.  And the members of an organization may vary widely
in competence, personal responsibility, and so on.  Thus, the members
of an organization cannot be trusted to do the "right thing".  [I am
using "organization" in a loose sense, so that we can consider a
business an organization, and an employee as a member of that
organization.]

In fact, in most cases, only a small fraction of the members of an
organization care more about the welfare of the organization than
about their personal welfare.  So people will almost always be more
concerned about their own personal data security than they will for
that of an organization.  This, coupled with difficulties of
coordination and control, and the above conditions, means that in a
global sense information security for an organization will always be
difficult, regardless of the security of the crypto they use. 

For a moment consider the analogy with physical keys.  Consider the
key management problem of a moderate sized corporation that occupies a
large office building.  There are office keys, storeroom keys, supply
room keys, conference room keys, bathroom keys, keys to filing
cabinets -- there are *lots* of keys, lots of different delegations of
authority involved.  In many cases there is a "key czar", a "building
coordinator" that hands out keys, and gets them back when someone
changes offices or jobs.  It *has* to be this way -- you can't rekey
the entire building when a janitor quites.  So, occasionally it is
necessary to rekey a lock, but typically keys are just reused.  Many
office keys are designed to be difficult to casually duplicate, for 
this reason.

Of course any key *can* be duplicated, but that's not really that
important -- the building is full of employees during the day, and 
the night watchman checks each person that enters after normal 
hours.  

All these physical keys all fit locks that can be broken quite easily
-- there is essentially *no* possibility of something valuable being
lost behind a lock that cannot be broken.  This is vastly different
from cryptographic keys -- for all systems of interest, encryption
represents locks that cannot be broken.  Data behind a lost 
cryptographic key is gone forever.  You can't call a locksmith or a 
safe cracker.  It's really just gone.

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?  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?

Contrast that with a key-safe model, where a copy of every encryption
key is kept in a secure database.  The encryption client software only
talks to the key-safe when a new key is generated, over a
cryptographically secure channel, of course.  There is no policy the
client has to know.  The user encrypts freely without concern about
who else should get copies.  The organization knows that there is very
little chance of data loss because of lost keys, and can use any
policy it chooses to recover keys, from the company president's ad hoc
whim to a carefully specified organization al security policy. 

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

-- 
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