From: Adam Back <aba@dcs.ex.ac.uk>
Date: Tue, 14 Oct 1997 22:53:36 +0800
To: zooko@xs4all.nl
Subject: Re: commercial data recovery
In-Reply-To: <199710141053.MAA03610@xs1.xs4all.nl>
Message-ID: <199710141329.OAA02853@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Zooko Journeyman <zooko@xs4all.nl> writes:
> Adam, I applaud your effort to steer discourse toward 
> productive work re: GAK, CMR, CDR.  I haven't thought about 
> your idea enough to have a definite opinion, but at first blush
> it seems a promising strategy to design high-security and 
> forward-secrecy for communication but recovery/sharing features
> for stored data.

Thank you.  I would encourage others to read the proposal, and
provide criticisms of it.

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?  
> Probably so.  Better just punch out a standard with current
> tech...

I agree entirely.  The motivation for attempting to formalise the CDR
design principles, and for exploring designs which are non-GAK
compliant is based on these lines of reasoning, that we should:

1. Persuade PGP Inc that there are less GAK friendly ways of
   implementing data recovery

2. If that argument fails, and in the event that PGP were to try to
   influence the IETF OpenPGP forum to adopt any features relating to
   pgp5.5 GAK compliant functionality into the OpenPGP standard that we
   have an alternate proposal well enough thought through to compete
   with PGP's CMR proposal with sound technical arguments.

3. Of improving the state of the technology by working to include
   forward secrecy as much as possible into secure email messaging.
   This is a very effective method of giving the bird to the
   GAKkers, by purposefully destroying communications keys as soon as
   possible after the fact.  This is consistent with the CDR design
   goal: make the GAKkers job as difficult as possible.  Frustrating the
   GAKkers is a fun, morally satisfying activity.

> Hm.  What about the idea of storing your data remotely (for
> cost-efficiency, safety, etc.) using encryption to maintain 
> your privacy?  In that case, the distinction between comms and
> storage keys is blurred.  A company may choose to e.g. store 
> all long-term data at Zooko's Backup Server, encrypted in such
> a way that some combination of corporate keys (controlled by 
> individual employees and/or departments) is necessary to 
> decrypt each package of data.  This would open the door, as you
> fear, for a government to mandate that _its_ key be added to 
> each set, with authority to open any package even without the 
> cooperation of any corporate keys.

The application you describe has very interesting implications for the
CDR vs CMR debate.

I think that one way that you could implement remote backup in a way
which is sympathetic to CDR design principles like this:

- The communications security aspect could be acheived via the normal
  design for securing communications derived from the CDR design
  principles.  That is using short lived communications keys with no
  third party access to communications in transit without access to
  hard disks at either end.

- The data would be super-encrypted to the companies backup recovery
  storage key(s).

This technically violates the CDR design goal and principles of not
allowing third party access to communicated data, super encryption
doesn't negate this, it is just more structuring.

However, super-encryption does minimise the damage by preserving CDR
principle that recovery of data should require physical compromise of
one or both end points, which I think is an important principle, and
a useful property in this case.

This lesson leads to the corollary to the CDR principles that:

- if you can't keep to the principle of not transmitting data with third
  party recovery information attached,

that:

- super-encryption of the transmitted recoverable data can be
  used to at least preserve the requirement for one or both ends of
  the communication to be compromised to effect third party access.



But still, the remaining way that this system could be perverted would
be as you say for the GAKkers to demand to be one of the storage
accessors for the encrypted disk backup, and for the GAKkers to then
attempt to coerce the remote storage service provider to hand over the
ciphertext, or for the government to set themselves up as a central
provider of off site backup services.

The GAKkers desire for automatic access to communicated storage data
is frustrated to the maximal extent possible by those CDR design
principles we have managed to retain.  To achieve automated access the
GAKkers must start replacing software, and we have prevented automatic
snooping of our backup data whilst it is in communication, with
software we have fielded.

- CDR design principles do not prevent someone modifying software, but
  as we all know deployed systems are additional obstacles to overcome:
  they have to coerce some company in to implementing the new software
  with built in GAK, and they have to coerce everyone into replacing
  their existing software with this unpopular new software.

Widely deployed systems can be large obstacles.  The mess the US IRS
in with their millions of lines of hard to modify source attest to
this fact.

The IRS scenario has some lessons for us, for possible additional CDR
design principles:

- keep the source code out of reach of GAKkers so that they can not
  coerce us so easily to modify it.  Off shore backup might be useful;
  destroy the backup recovery key if GAK comes in.

- make systems non-interoperable where this does not interfere with
  functionality

- have mandatory GAK company contingency plans such as moving the
  company to Switzerland.

That first suggestion costs so much in the loss of user access to
source code to assure ourselves that there is no backdoor that we
probably can't employ it.  The other two look like sound principles to
me.


> Zooko's Backup Server can be physically located in a country 
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

One comfort which can be drawn from the above design using super
encryption inside a communications envelope protected with short lived
non-escrowed communication keys, is that the fielded software could
not be used as-is to prevent the practice of jurisdiction shopping.

Another comfort is that companies can, even if forbidden from using
offshore remote backup facilities, simply stop using remote backup
facilities at all, unless the GAKkers really go overboard and demand
that all citizen units will run this government remote backup software
to upload diffs of their disks to government run backup services.  I'm
sure they would love to do that, and charge you for the "service" too.

Also I expect there would be significant political hurdles for the
GAKkers to overcome in mandating government run remote backup services
for citizen units, or even for companies in our countries.

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`