1997-10-12 - negative security aspects of GAK compliance

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: ietf-open-pgp@imc.org
Message Hash: 01579c662851da133f8829dd544dbba7adcbb54f8bc3d3622286e35f88aa8f53
Message ID: <199710120948.KAA00212@server.test.net>
Reply To: N/A
UTC Datetime: 1997-10-12 09:57:53 UTC
Raw Date: Sun, 12 Oct 1997 17:57:53 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 12 Oct 1997 17:57:53 +0800
To: ietf-open-pgp@imc.org
Subject: negative security aspects of GAK compliance
Message-ID: <199710120948.KAA00212@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




I think there is a clear technical security case against the GAK
compliant packet, which I would like to see comments on from people
who think the political GAK compliant argument is not significant.

This ties in with using separate storage and communications keys, and
with the better security practice of having shorter lived
communications keys to provide forward secrecy from the point of
issuing new communication keys (could be once per month, once per
week, or once per message).

Once you acknowledge that it is more secure to have short lived
communication keys (which in my view it very clearly is), it should be
clear that by putting a GAK compliancy packet feature, or other second
recipient you are weakening the security because that is another door
into a message which you are trying to make forward secret -- you are
trying to ensure that after the fact, no-one, not even the recipient
can decrypt the old traffic.  (This is a very good way of ensuring
that third parties, like industrial espionage spies, people using
black mail or the Feds using rubber hoses, or supeonas or other legal
or extra legal forms of coercion, can't obtain from you keys to
decrypt it either, so they don't get plain text).  

The fact that the extra door into the message is outside the
recipients control means that his own security could be compromised by
sloppy practice on the part of that key holder.


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.

Or, as I would argue, most secure of all is not using GAK compliancy
packets at all, but rather to use escrowed storage keys to retain
access to mail archives.  This is more secure because you don't keep
second doors into what should be a communication encrypted with as few
as possible (namely: one) transient communications key, with security
policy control being in the hands of the person who owns the key (the
recipient).

As I have pointed corporate access to stored email can be acheived
with similar amounts of snooping enforceability by having the PGP5.5
mail client store to an escrowed communications key after decryption,
or even to re-encrypt after decryption to a long term storage company
archive access bot within the LAN (with such encrypted messages
themselves being wrapped in an extra comms encryption envelope using
short term communications key if you like).


I would be interested to see anyone refute this security argument from
a security point of view.

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`






Thread