From: Adam Back <aba@dcs.ex.ac.uk>
Date: Tue, 14 Oct 1997 17:58:11 +0800
To: ietf-open-pgp@imc.org
Subject: proposal: commercial data recovery
Message-ID: <199710140937.KAA01187@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




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


I think we can distill the design principles required to meet the
design goal of a non-GAK compliant Corporate Data Recovery (CDR) down
to ensuring that:

1. no keys used to secure communications in any part of the system are
   a-priori escrowed with third parties

2. second crypto recipients on encrypted communications are not
   used to allow access to third parties who are not messaging
   recipients manually selected by the sender

3. communications should be encrypted to the minimum number of
   recipients (typically one), and those keys should have as short a
   life time as is practically possible

Included in 2) is the principle of not re-transmitting over
communication channels keys or data re-encrypted to third parties
after receipt -- that is just structuring -- and violates design
principle 2.


With these three principles you still have lots of flexibility because
you can escrow storage keys, do secret splitting of storage keys, and
store keys encrypted to second storage accessors on the local disk for
stored data recovery purposes.

As an additional bonus, principle 3 adds extra security against
attackers gaining access to encrypted traffic after the fact -- the
recipient no longer has the key -- this is a form of forward secrecy.


Systems designed to the CDR design principles are of significantly
less use to GAKkers than PGP Inc's GAK compliant Commercial Message
Recovery (CMR) design.  The CDR design significantly hinders the take
up of GAK if widely deployed.  

Design principle 3 -- forward secrecy -- is inherently hostile to
GAKkers, and is the strongest statement you can make against GAK: you
are purposelly _destroying_ communications keys at the earliest
possible moment to ensure that GAKkers can not obtain the keys by
legal and extra-legal coercion, black mail, and rubber hose
cryptanalysis.

The whole system translates into the Feds having to come and
physically take your disk to obtain information about you, which is
much better than GACK, and not what the GAKkers are interested in at
this point.  The GAKkers would like to install themselves, and coerce
companies into installing for them (via GAKker/USG/NSA/NIST organised
efforts such as the 56 bit export permit for companies installing key
escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)).
I fear that PGP Inc's CMR proposal inadvertently meets most of the
NIST/NSA specified KRAP requirements.

What the GACKers want is systems where they can perform routine key
word scanning and fishing expeditions into your communications from
the comfort of their offices, without your knowledge.  This is push
button Orwellian government snooping.

Within the constraints imposed by the CDR design principles, there is
plenty enough flexibility to acheive the commercial data recovery
functionality to similarly weak levels of enforcability as achieved by
the CMR design.  Weak levels of enforceability are appropriate because
there are other exceedingly easy bypass routes: super-encryption, and
walking out of the office with a DAT tape.


I would like to organise a collaborative effort to write a white paper
discussing how to implement various functionalities using the CDR
design principle.

Then I would like to see discussion of which set of these
functionalities which best acheive the user requirement for company
data recovery.

Lastly I would like to see a collaborative development effort to
provide a example implementation of a CDR system which can be used as
a discussion point for the OpenPGP standardisation process.

I suppose the best place to discuss this process is the IETF forum for
discussion of the OpenPGP standard, the OpenPGP mailing list
(subscribe by sending message body "subscribe ietf-open-pgp" to
"majordomo@imc.org").

I have already had people express in email to me their interest in
doing this.  Those people can speak up if they want to.  Technical
input is sought from people opposed to GAK compliant software, and
from PGP Inc, and others defending PGP's GAK compliant CMR proposal.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`