PGP's GAK schon seit 5.0 in ALLE Versionen eingebaut

[Lutz Donnerhacke <lutz@iks-jena.de>]

Die Diskussion gehört eigentlich nach krypto@rhein-main.de, aber laßt uns
mal die "Journalisten" informieren.

Background: Es gab einen Sturm der Entrüstung, als bekannt wurde, daß die
neue Version 'PGP 5.5 for Business' einen Zugriff auf vorgeblich private
eMail durch Firmenleitungen (und mehr) nicht nur gestattet (wie in PGPMail
4.5 von Viacrypt, die damals für diese Idee von PGP Inc. gelyncht wurden)
sondern neuerdings sogar erzwingt. BTW: Viacrypt wurde von PGP Inc.
inzwischen aufgekauft.

Folgende Nachricht belegt, daß bereits PGP 5.0 diese Funktionen
implementiert hat und somit es ein leichtes ist, in den USA und dann in der
Welt auf mandantory GAK (erzwungener regierungsseitiger Zugriff auf private
Kommunikation) einzuführen.

Besondere Beachtung kommt insbesondere dem Punkt 3 der folgenden Mail zu,
der sich auf eine Aussage von Jon Callas (Sicherheitschef bei PGP Inc.)
bezieht, in der Jon klarlegt, daß man nicht nur ausgehende EMail zwangsweise
mitlesen will, sondern dies auch für eingehende EMail erzwingen kann.

Im Rahmen der Aktionen, die PGP Inc. auf dem Weg vom heiligen Ritter und
Hüter des Privatsphäre-Grals zum geldgierigen Drachen, unternommen hat, ist
von der Benutzung von PGP 5.0 ff. dringend abzuraten. Gründe sind
vielfältig, die wichtigsten:
  - Schlüsselmanagement ist noch rückschrittlicher als in PGP2.6.3xx.
  - Lizenz verbietet Bugfixes und Verbesserungen.
  - Batchbetrieb unmöglich.
  - Konventionelle Verschlüsselung existiert nicht mehr.
  - Mandantory GAK eingebaut.
    (GAK = Gouvernmental Access to Keys
         = Zugriff auf die Nachrichteninhalte durch Dritte insbesondere
	   Regierungen
     mandantory = erzwingbar, wer sich nicht dran hält, kann nicht
                  kommunizieren)

Die Versionen PGP 2.6.3 sind dagegen gut benutzbar. Entsprechend Frontends
existieren in guter Qualität. Die Version PGP 2.6.3in unterstützt
wesentliche Funktionen, die zum ordentlichen Schlüsselmanagement benötigt
werden, wie Zertifikatsrückruf, Rückruf von Nutzer­IDs, Verfallsdatum von
Schlüsseln, Verwendungszweck von Schlüsseln.

Die Version PGPin ist momentan in Arbeit und wird legal in die USA
importierbar sein. Die wird allerdings unter GPL entwickelt und legt
deutlich mehr Wert auf brauchbare Sicherheit, statt auf blindes (aber
verkaufbares) Klicken.

				     --

From: "Jim Russell" <jrussell@syncrypt.com>
To: <cypherpunks@cyberpass.net>
Cc: "Bruce Schneier" <schneier@counterpane.com>, <risks@csl.sri.com>,
Message-ID: <01bcd407$02595600$2901320a@Polaris.domain>

The swirl of controversy that has arisen since the 2 Oct announcement of the
PGP Business Security Suite has been quite amazing.  Yet, all of the focus
has been on what's been *added* to PGP v5.5.  Jon Callas said it explicitly:

>>Corporate Message Recovery is included *only* in PGP for Business
Security.

What sense, then, can I make of the following?

I have been examining the published source code for PGP v5.0 for Personal
Privacy (note that this is *not* a corporate version), and have discovered
that this recovery scheme already appears to be in place, in some form at
least, in that version.

The following code appears in the published pgp.c, lines 518-537:

   /*
    * This is our version of "Commercial Key Escrow".
    *
    * A company can set the CompanyKey in the site-wide
    * configuration file and it will be added to the
    * recipient list for all encrypted messages.  Then
    * again, the user can override the setting in their
    * own pgp.cfg or on the command line.
    */
   companyKey = pgpenvGetString (env, PGPENV_COMPANYKEY,
            NULL, NULL);
   if (companyKey && *companyKey) {
    /* Add the company key to the recipient list */
    e = ringSetFilterSpec (ui_arg->arg.ringset,
             ringset,
             companyKey,
             PGP_PKUSE_ENCRYPT);
    if (e <= 0)
     exitUsage(e);
   }

This certainly *looks* like the implementation that is being discussed in
the press release, although I did not find it mentioned in any documentation
for PGP for Personal Privacy v5.0. The questions this code brings to my mind
are:

1.  Does this mean that even the Personal Privacy versions of PGP have a
message recovery scheme available?  The 2 Oct press release from PGP states
that the corporate message recovery "transparently integrates with *any*
version of PGP client software".  (Emphasis mine).

2.  If this is implemented via a configuration setting, does it provide an
opportunity for an attacker to reset the "CompanyKey" to their own key?  In
the Windows environment, it appears that PGP uses the System Registry to
hold configuration settings.  Is it possible for me to trick someone into
running a .REG script that will set the CompanyKey to a key to which I hold
the private component?

3.  This appears to me to be quite contradictory to the descriptions posted
by Jon Callas on 7 Oct.  The procedure that Jon describes, using an
attribute in the self-signature, would tell an encryptor external to The
Corporation to use the "skeleton key" on INCOMING mail.  The 5.0 code seems
to imply an automatic extra recipient on OUTGOING mail, and this impression
is reinforced by the description of the SMTP server policy enforcement in
the 2 Oct product description on PGP's web site.  (Let's not forget that
SMTP is a protocol for OUTGOING mail.) Which is it, or is it actually both?

Now, I realize that the long-time PGP users, the computer experts who can
take the source code and recompile the application, could simply remove any
sections they don't like, or go into the configuration settings and change
everything to their liking.  However, isn't encryption supposed to be moving
to a new target audience, the people who use a computer as a tool, and don't
necessarily know the internals? These are the people who need to feel secure
using encryption, and magic, invisible encryption to a third-party is
probably not going to give them warm fuzzy feelings.

Jim Russell <jrussell@syndata.com>
 Senior Engineer
 SynData Technologies, Inc.
 http://www.syndata.com