Re: key recovery vs data backup

[Alan Barrett <apb@iafrica.com>]

On Thu, 8 May 1997, Kent Crispin wrote:
> 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.

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.

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.

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

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

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


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.

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

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

--apb (Alan Barrett)