From: Adam Back <aba@dcs.ex.ac.uk>
Date: Mon, 13 Oct 1997 09:28:32 +0800
To: hal@rain.org
Subject: Re: negative security aspects of GAK compliance
In-Reply-To: <199710121609.JAA09605@s20.term1.sb.rain.org>
Message-ID: <199710130026.BAA00930@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




I also was pondering this question as to which purpose the current
"encryption key" could be used for; should it become the
"communications key", or should it be the "storage key".

Clearly it could be used for either; and is in fact currently used for
both, which is where the security problem arises.

What you have described (very clearly as always) is the case for
making the current "encryption key" the "communications key".  You are
forced to make this choice because there is only one key available,
and without a communications key .. well you can't communicate :-)

However this leaves the question: what do you use for a "storage key"?


To see why this argument is important, you can see that you have
painted yourself into a corner where you will be forced to admit that
you need to have separate storage and communications keys.  Probably
this doesn't bother you as you didn't react adversely to my earlier
description of how it was a good idea to separate key functionality.
Let me quote:

Hal Finney <hal@rain.org> writes:
> This should facilitate more frequent changeover of encryption keys as Adam
> Back describes, which can be good security practice.  It is a significant
> improvement provided by the new key structures of PGP 5.

It is indeed.  It is also very good for another reason: it allows
corporate escrow of encryption keys without simultaneously allowing
the company to forge signatures.

However you have created a problem for your self in the following
argument which suggests that you must have two encryption keys; one
for storage and one for communication.  It also suggests that my
method for achieving corporate recovery of email is better acheived
without the GAK compliancy field (second recipient) which was my
earlier point.

> Adam wrote:
> 
> > This argues that if people are to insist on using the enforced second
> > recipient model for corporate snooping at all, they should for
> > security reasons be at least using short lived communications keys for
> > the GAK compliancy packet also.
> 
> That sounds reasonable, at least if the first recipient is also using
> short lived keys.  Presumably these kinds of policies would be established
> by the corporate security office.  But certainly if one class of keys
> uses short lived keys then it would be logical for the other class to
> do so as well.

By doing it this way you do claw back some of the security lost by
having a second crypto recipient, as you say.  However you now can't
recover communications past the expiry date of the short lived
corporate key.

As the whole point of corporate message recovery is to guarantee
message recovery of stored messages (or at least this is the user
requirement Jon Callas gave in his post explaining the need for CAK),
you have just thrown away much of that ability.  This is an extreme
pity because you are now faced with a dilemma.

Your dilemma is, do you:

a) use short lived encryption keys (for both user and corporate master
key), and have good security but limited recovery of stored encrypted
email after that short period.  Also the poor user won't be able to
even access, never mind recover his stored encrypted email!

b) or do you use a long term encryption key for the corporate master
key, and hence good recovery of stored encrypted email, but poorer
security (and as an additional disincentive end up building a GAK
compliant system.)


This dilemma highlights really very well my point as to why you really
do need separate storage and encryption keys.  Introduce them, and
both problems vanish.

You can then:

- Have short term communications keys for the employee
- Have long term storage keys for the user escrowed with the company
- Have long term key recovery storage key for the company

It's beautiful, everything falls into place, and it's more secure.

Also as a convenient side-effect the way that you build a corporate
stored message recovery scheme under this system is non-GAK compliant,
which saves you from being screamed at by cypherpunks, and from being
dissed in the NYT and other places.  Presumably given Jonathan
Seybolds clear statement of PGP's aims:

Jonathan Seybold <jseybold@pgp.com> wrote:
>        With regard to GAK, the objective should be to accommodate
> legitimate corporate needs without setting in place the foundation
> for GAK.

this side-effect of removing the GAK compliancy should therefore be
very pleasing to PGP also.

The way that you implement corporate recovery of stored encrypted
messages once you accept the clear need for separate communications
and storage keys is easily derivable from new the key purposes.  It is
basically as easy to circumvent as the previous GAK compliant method.
Several PGP employees commenting on this didn't seem to think
enforceability was that big a deal.  (I agree with them: if all it
takes is to super encrypt with PGP itself, it's not worth losing sleep
over.)

Here's how to do corporate recovery of stored encrypted messages, now
with the new separated storage and communications key functionality:

1. Corp. employee receives encrypted email, the email is encrypted to
the employee's short life time communications key.

- employee decrypts email with pgp5.6 client

- pgp5.6 client encrypts the plaintext to users long term storage
  key, and to the companies recovery key as a second
  "storage-recipient", and places in received mail folder

2. Corp. employee sends encrypted email

- The pgp5.6 mail client encrypts plaintext of email to users long
  term storage key and to the companies long term storage recovery key
  and stores in the sent email folder

- The pgp5.6 mail client encrypts the plaintext of the email to the
  recipients short lived communications key and passes on to the MTA

3. Normal user access of encrypted stored email

- user's email client decrypts stored email with users storage key

3. User forgets password, or dies, or leaves in a huff, company needs
access to stored email

- company uses company recovery key to decrypt users stored email


An alternate set up would be to escrow the users long term storage key
with the company.  Basically equivalent.  But I think it is probably
easier to use multiple recipient as it saves the headaches of having
to securely transmit 10000 users storage keys securely.  Much easier
to install the software with the department/company recovery key bound
into it, and to remote update the company recovery key by fetching the
new from the company key server when it expires.

There are lots of other issues of course, with regard to architecture
of recovery setup.  However there is a basic equivalence between key
escrow and session key recovery methods, and you can acheive all kinds
of departmental escrow jus the same as you could with the previous
system.

> Actually it's likely that the corporation will change its shared access
> keys more frequently than user keys, at least if they are using an
> access model where there are relatively few shared keys.  It will be
> easier to change a few keys which are controlled by corporate officers
> than to get every one of 10000 employees to generate a new key every week.

I can't see any reason why you would not be able to entirely automate
and hide the process of generating new communications keys every week,
every day, or _every communication_.

The process can be handled automatically by the software.

With El Gamal you have a very computationally cheap way to generate
keys other than the first key; discard the private components, and
treat the public modulus as a pre-computed prime as you currently do
for the fast key generation option on EG key generation.


I feel somewhat better about this post than previous ones; I haven't
been rude to PGP, and I feel some progress has been made in clarifying
things.  Perhaps it's just interacting with Hal, who always was one of
the most level headed people on cypherpunks; it's much harder to pick
faults in what he says, and he doesn't make ill thought out political
statements.

I think there are still some issues to resolve if we start to talk
about "per communication" communication key updates, but for per week,
or per month or whatever, I think the above is good.

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`