ietf-openpgp
[Top] [All Lists]

Re: proposal: commercial data recovery

1997-10-14 09:40:03
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> writes:

If we take the design goal of designing a commercial data recovery
system which is not GAK compliant, we can most succinctly state this
design goal as the task of ensuring that:

- at no point will any data transferred over communications links be
  accessible to anyone other than the sender and recipient with out
  also obtaining data on the recipient and/or senders disks

You do a good job of saying what you want to avoid, but not much about
what you want to accomplish!  You are doing this to satisfy some kind
of market need for commercial access to data.  What are the requirements
your design will satisfy?  What do the customers need?  You can't design
a system based solely on what it doesn't do.

PGP, Inc. has made its design choices based on interaction and discussion
between people responsible for security, human interface, sales/marketing
and customer support, as well as the customers themselves.  The lessons
which have come out of this include an emphasis on solutions which
people can use and which will work in the field.  This means they have
to be transparent, easy to learn, fit into existing procedures, and
be reliable, as well as being secure.  Systems which require extensive
retraining, new operational procedures, or which will hurt reliability
are not acceptable - they simply won't be deployed.  That's the reality.

A system with forward secrecy on email and rapid turnover of
communications keys has some attractive security properties, but you
need to look at the other aspects of using it.  How will it respond to
errors?  How can companies guarantee that they will be able to decrypt
data when they need it?  Can you assure that no data will ever be around
which requires a key which no longer exists, and can you do so not in
a theoretical world where everything works perfectly, but in a real
company where people make mistakes and forget things?

If you were to talk to people responsible for human engineering and
deployment you'd find that there are many more considerations which go
into a successful system than theoretical security properties.  Otherwise
we'd all be using one time pads.

With our current design, as I described earlier, we have data structures
which will enable people to easily replace encryption keys, if a system
can be designed to solve the usability problems in a practical way.
It looks to me like our current model supports the necessary feature
set for what you want to do, so I don't see any need for changes.

The one new suggestion has been to have separate communication and storage
keys, but this has several problematic aspects.  Unlike the distinction
between encryption and signature keys, where it is obvious whether a key
is being used properly, it is not at all clear whether a particular
function represents communication or storage.  Consider the case of a
remotely mounted file system, where what looks like a storage operation
is actually travelling across a (possibly insecure) network.

Another example comes from the initial version of the Eudora API.  When
that makes calls out to the crypto library to encrypt messages, Eudora
actually stores the message in a disk file, has the library encrypt that
to another disk file, then constructs the message from that output file.
It will look to the library like it is encrypting a disk file using a
communications key, a violation of this proposed security policy.

In fact, in most cases a storage key will not be a public key at all,
but will be a symmetric cipher key, such as with our own PGPDisk product.
This allows transparent disk encryption and decryption.  In that case you
really don't have "storage keys" as such in the public key infrastructure,
so there is no need for a distinction.

As it stands, you could design a system to use rapid replacement of
email encryption keys in order to provide forward secrecy, without any
changes whatsoever to the existing key structure as it is documented
in the current draft spec.  The operational problems of creating such a
system which is reliable and usable are going to be very severe, but the
support is there in the Open-PGP data formats, and other companies and
groups are welcome to tackle them.  However I don't think that Open-PGP
is the right forum for the discussion, since the issues are largely
matters of user interface and customer support.

Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org