[1691] in cryptography@c2.net mail archive
GAK Taxonomy?
daemon@ATHENA.MIT.EDU (Phil Karn)
Fri Oct 3 15:25:18 1997
Date: Fri, 3 Oct 1997 12:19:53 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
To: cryptography@c2.net
Cc: karn@qualcomm.com
Has there ever been a serious effort to make a taxonomy of the various
mechanisms for implementing GAK in software encryption products? I
don't mean the various ways the "escrowed" keys are stored and
accessed -- I consider that to be a fairly straightforward application
of secret sharing -- but rather the way GAK is implemented (and
possibly enforced) in protocols spoken by end-user products.
I can see two major divisions: where the user software sends a key to
the government and the other in which the government sends a key to
the user.
The "sending" steps can be implicit; in the first category, it could
mean a file or protocol header that includes the session key encrypted
in the FBI's public key, which the government would get when it seizes
the file or taps the connection. In the second category, it could
consist of a centralized Key Management Center based on symmetric
encryption (e.g., Kerberos) set up to give session keys to the
government under court order. (In this sense, the KMC "becomes" the
government, so you effectively have the government issuing session
keys to the users).
I'm interested in seeing how easily each category of GAK could be
disabled by a user willing to patch his/her software or write their
own that uses the same ciphers, protocol standards and/or file formats
without GAK.
I posit that by patching one's software it is always possible to
defeat GAK in any decentralized scheme (e.g., all those based on
public key), at least in the absence of a man-in-the-middle
enforcement mechanism such as that reportedly included in the mail
transfer agents for PGP for Business Security 5.5 (see
http://www.nytimes.com/library/cyber/week/100397pgp.html).
Even there, it seems unlikely that the enforcement mechanism can
stop superencryption.
It will probably be necessary to defeat GAK on both ends of a
communication session, for two reasons: to disable "rogue peer"
checks, and also to ensure that the far end doesn't compromise a key
to the government via GAK even if the local end has disabled it.
The second reason shows that a feature in GAK that prohibits
interoperation with a peer that has disabled GAK can be seen as a Good
Thing...
Phil
