Message de Phil Zimmermann, Créateur de PGP

(English PGP signed version)

Le 24 Août, nous avons découvert que nous avions un bug de sécurité dans PGP, dans l'implémentation de la fonction Clé de Déchiffrement Supplémentaire (ADK [ CDS]). Un chercheur allemand, Ralf Senderek, avait déjà publié la nouvelle de ce bug sur un site web. Nous nous sommes mobilisés rapidement et avons réalisé une version corrigée de PGP dans les 18 heures suivant cette nouvelle. Le correctif pour la version commerciale de PGP est disponible sur http://www.pgp.com, et la version freeware corrigée de PGP (version 6.5.8) est disponible sur le site web du MIT à http://web.mit.edu/network/pgp.html, ou sur http://www.pgpi.org.

Certains des messages postés sur Internet à ce sujet ont décrit ce bug comme une porte dérobée [backdoor] dans PGP. Croyez-moi, ce n'est rien de la sorte. C'est un bug (et nous l'avons maintenant corrigé). Un bug particulièrement embarrassant, parce qu'il est dans une fonctionnalité contre laquelle certaines personnes s'étaient élevées même quand tout le monde pensait que cela marchait correctement.

La fonction ADK a été conçue en 1997 pour être une alternative plus douce et plus légère en comparaison au séquestre de clés (key escrow) que certaines sociétés pourraient utiliser avec les clés de leurs employés. J'estimais que le séquestre de clés était une particulièrement mauvaise idée, et proposai cette alternative: Imaginez que vous ayiez publié votre clé publique en y joignant une petite note Post-it jaune (signée numériquement par vous), demandant aux utilisateurs qui voudraient chiffrer [un message] avec votre clé publique de chiffrer également le message avec une autre clé. Cela signifie que la note demande aux utilisateurs de chiffrer le message avec deux clés au lieu d'une -- la clé du destinataire désiré, et une clé supplémentaire [ADK] choisie par le destinataire, identifiée sur le petit Post-it. C'est une demande du destinataire que l'expéditeur d'un message peut choisir de respecter ou d'ignorer. L'expéditeur est libre de chiffrer le message avec une clé, ou les deux. S'il choisit de se conformer aux souhaits du destinataire et utilise l'ADK, le destinataire désiré ainsi que l'ADK peuvent alors tous deux déchiffrer le message. Cela satisfait une demande majeure de nos entreprises clientes qui souhaitent un mécanisme permettant de contrôler ce qui se produit quand un employé n'est pas disponible pour déchiffrer le fichier, parce qu'il est en vacances, ou qu'il est mort dans un accident d'avion, ou qu'il a tout simplement oublié sa phrase secrète. C'est de loin préférable au séquestre de clés, car l'utilisation cette fonction requiert le consentement de l'expéditeur comme du destinataire. C'est [l'utilisation de cette fonction] clairement visible pour l'expéditeur, et son consentement est demandé avant que le chiffrement ne soit effectué.

Nous n'aurions pas pu vendre PGP sans cette fonction. La plupart des utilisateurs du freeware n'avaient pas besoin de cette fonction, aussi nous ne rendîmes pas la version freeware de PGP capable de générer des ADKs sur ses clés. Vous devez acheter la version commerciale pour générer des clés comportant des paquets ADK corrects attachés. Puisque les utilisateurs freeware ne paient pas les salaires de nos ingénieurs, et que les utilisateurs commerciaux le font, nous devions ajouter cette fonctionnalité à PGP pour satisfaire une demande impérative de nos seuls clients payants. Il semble que les critiques les plus militants de la fonctionnalité ADK sont aussi ceux qui ne veulent pas payer pour PGP. Quelqu'un doit payer les ingénieurs afin que nous puissions continuer de développer PGP et le distribuer gratuitement à ces mêmes critiques.

Le destinataire doit faire une signature numériquee sur le petit Post-it jaune, consentant ainsi à avoir un ADK associée à sa clé. Et c'est ici que se trouve le bug. Le bug dans les versions de PGP 5.5 à 6.5.3 est que PGP ne vérifie pas toujours correctement que l'ADK est signé avant de l'utiliser, si le petit Post-it qui fait référence à l'ADK est improprement formaté d'une façon particulière. Cela signifie que quelqu'un pourrait attacher un ADK non autorisé à votre clé, et peut-être duper un expéditeur de message inattentif en le conduisant à l'utiliser. Ce ne serait pas une arnaque facile à monter, parce qu'il est probable que l'expéditeur n'a pas la fausse clé ADK correspondante dans son trousseau de clés, et même s'il franchit l'étape supplémentaire de l'obtenir depuis un serveur, la fausse clé ADK ne sera probablement pas signée par une Autorité Certificatrice dans laquelle l'expéditeur a confiance, aussi PGP l'avertira-t-il de l'utilisation de cette clé ADK pour chiffrer le message. C'est une attaque audacieuse, une attaque qui a de fortes probabilités d'être détectée. Ensuite, même si tous ces problèmes ont été surmontés d'une manière ou d'une autre, l'attaquant doit encore pouvoir intercepter l'e-mail chiffré durant son trajet vers le destinataire prévu. Les services secrets excellent dans l'interception du trafic e-mail, mais ils ne seraient jamais assez stupides pour tenter une attaque audacieuse. C'est peut-être la raison pour laquelle on n'a trouvé absolument aucun paquet ADK falsifié quand nous avons scanné toutes les clés publiques sur les serveurs de clés publiques après que le bug ait été rapporté, bien que ce bug ait été présent depuis près de trois ans. Si ç'avait été une porte dérobée [backdoor], cela aurait été une conception particulièrement stupide pour une porte dérobée.

Quoi qu'il en soit, nous avons corrigé le bug. Nous avons aussi modifié les serveurs de clés afin qu'ils rejettent désormais tout ADK falsifié avant que quelqu'un ne risque de l'utiliser, même s'il n'a pas encore la nouvelle version corrigée de PGP.

Quand nous avons ajouté la fonction ADK en 1997, de nombreuses critiques nous ont affirmé que cela ouvrait la voie aux services de police gouvernementaux ou aux services secrets, car ils pourraient exploiter la fonction ADK afin d'espionner les citoyens ordinaires. En réalité, cela n'est pas arrivé. Après de nombreuses années de lutte, nous avons gagné le débat sur la cryptographie aux Etats-Unis (et en France, et dans une liste croissante d'autres pays en Europe), et les contrôles américains à l'exportation ont été complètement levés en Janvier 2000. Après près de trois ans d'utilisation, la fonction ADK n'a eu strictement aucun impact sur l'état de la surveillance par le gouvernement aux Etats-Unis, et dans le monde. Les prédictions étaient fausses. Dans le même temps, l'acceptation commerciale de PGP (en partie grâce à l'ajout de la fonction ADK) a permis à PGP de pénétrer plus largement l'industrie informatique politiquement puissante, ce que je soupçonne d'avoir en un sens contribué à faire pression sur le gouvernement pour qu'il lève les contrôles à l'export en cette année électorale.

Une chose ennuyeuse que j'ai vu dans certains articles de presse sur le web est l'hypothèse que l'ajout de la fonction ADK dans PGP aurait quelque chose à voir avec la Key Recovery Alliance (KRA) [Association pour le recouvrement de clés], un groupe industriel formé dans les années 1990 pour mettre des fonctions de recouvrement de clés dans les produits de cryptographie, essentiellement pour permettre à ces produits d'obtenir des licences d'exportation de la part du gouvernement américain. Laissez-moi vous assurer que la KRA n'a rien à voir avec l'ajout de cette fonction dans PGP. J'ai fait ajouter cette fonction dans PGP fin 1997, avant que Network Associates n'acquière PGP Inc. Nous l'avons ajouté parce que c'était une bonne fonctionnalité pour résoudre le problème spécifique de récupération de données qu'avaient les entreprises, problème que j'ai décrit ci-dessus. Cela n'avait rien à voir avec les licences d'exportation. Nous contournâmes les contrôles d'exportation en publiant le code source de PGP dans des livres imprimés et en exportant légalement ces livres (qui n'étaient pas sujets aux contrôles d'exportation) vers l'Europe, où ils furent scannés via OCR, recompilés pour en refaire des logiciels fonctionnels, et vendus sur des CDROMs dans le monde entier. Un moyen astucieux, ne trouvez-vous pas ? Cela marcha magnifiquement, et nous n'eûmes aucun besoin de compromettre l'intégrité cryptographique de PGP pour lui permettre d'être exporté. Par ailleurs, Network Associates acquit plus tard PGP Inc, et je leur fis quitter la KRA aussitôt. Quelques mois plus tard, NAI acquit une autre société (NIS), qui était membre de la KRA, et de ce fait en redevint automatiquement membre également. Leur adhésion devant être renouvelée, je leur demandai de ne pas le faire, et ils acceptèrent à nouveau ma requête. Aujourd'hui, il semble que la KRA n'existe plus, maintenant que les contrôles à l'exportation ont disparu.

Personne n'a passé d'accord avec le gouvernement. Il n'y a ici aucune conspiration. Il continue de n'y avoir aucune porte dérobée dans PGP. Nous continuons à publier le code source de PGP pour un examen extérieur, parce que nous voulons que les gens nous aident à trouver des bugs. La plupart des sociétés de logiciels informatiques ne font pas ça. Leurs logiciels sont aussi gros et complexes que les nôtres, donc ils ont probablement autant (si ce n'est plus) de bugs, mais vous n'en entendez pas parler autant parce que leur code source n'est pas publié pour examen extérieur.

PGP a été lancé comme un projet orienté vers les Droits de l'Homme, et est aujourd'hui utilisé par chaque organisation des Droits de l'Homme dans le monde. Nos ingénieurs restent dans l'équipe de PGP parce qu'ils ont le sentiment qu'ils travaillent sur quelque chose d'important pour le monde. C'est un travail ingrat pour la plupart d'entre eux, particulièrement avec toutes ces critiques de théoriciens de la conspiration qui imaginent que nous nous sommes vendus au gouvernement. Pourquoi les gens doivent-ils supposer les pires motivations ? Si NAI essayait de mettre une porte dérobée dans PGP, tous les ingénieurs de l'équipe de PGP démissionneraient dans une protestation hautement visible, et j'en parlerais à la presse. En aucune façon je ne laisserais cela arriver, et NAI n'a montré aucun envie de mettre une porte dérobée dans PGP.

Philip Zimmermann
29 Août 2000
prz@pgp.com
http://www.pgp.com/phil

Traduction <pgpenfrancais@bigfoot.com> et <michel@bouissou.net>




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 24 August, we found out that we had a security related
bug in PGP, in the implementation of the Additional Decryption Key
(ADK) feature.  A German researcher, Ralf Senderek, had already
published news of this bug on a web site.  We mobilized quickly and
released a fixed version of PGP within about 18 hours of hearing the
news.  The fix for the commercial version of PGP is available from
http://www.pgp.com, and the fixed freeware PGP (version 6.5.8) is
available from the MIT web site at
http://web.mit.edu/network/pgp.html, or from http://www.pgpi.org.

Some of the postings on the Internet about this subject have
portrayed this bug as a back door in PGP.  Let me assure you, it is
nothing of the sort.  It is a bug (and we have now fixed it).  An
especially embarrassing bug, because it is in a feature that some
people have objected to even when everyone thought it was working
correctly.

The ADK feature was designed in 1997 to be a kinder, gentler
alternative to key escrow for companies to use for employee's keys.
I felt that key escrow was an especially bad idea, and came up with
this alternative:  Imagine that you published your public key with a
little yellow Post-it note (digitally signed by you) attached to it,
asking users who want to encrypt with your public key to encrypt the
message with another key as well.  That means the note asks users to
encrypt the message with two keys instead of one -- the intended
recipient's key, and an additional key chosen by the recipient,
identified on the little Post-it note.  It is a request from the
recipient that the sender of a message may choose to comply with, or
choose to ignore.  The sender is free to encrypt the message with
one key, or both keys.  If he chooses to comply with the recipient's
wishes and use the ADK, either the intended recipient or the ADK may
decrypt the message.  This satisfied a major requirement from our
corporate customers for a mechanism of handling what happens when an
employee is not available to decrypt the file, perhaps because he's
on vacation, or died in a plane crash, or simply forgot his pass
phrase.  It is so much better than key escrow because it requires the
consent of both the sender and receiver to use the feature.  It is
highly visible to the sender, and asks his consent before proceeding
with the encryption.

We could not sell PGP without this feature.  Most freeware users
didn't need this feature, so we did not make the freeware version of
PGP capable of generating ADKs on their keys.  You have to buy the
commercial version to generate keys with proper ADK packets attached
to them.  Since the freeware users don't pay the salaries of our
engineers, and the commercial users do, we had to add this feature
to PGP to meet an absolute requirement of our only paying customers.
It seems the most militant critics of the ADK feature are also the
ones who don't want to pay for PGP.  Somebody has to pay the
engineers so that we can keep developing PGP and give it away for
free to these critics.

The recipient has to make a digital signature on the little yellow
Post-it note, giving his consent to having an ADK associated with his
key.  And therein lies the bug.  The bug in PGP versions 5.5 through
6.5.3 is that PGP does not always properly check to see if the ADK is
signed before using it, if the little Post-it note that references
the ADK is improperly formatted in a particular way.  This means
someone could attach an unauthorized ADK to your key, and possibly
fool an inattentive message sender into using it.  It would not be an
easy scam to pull off, because chances are, the sender does not have
the bogus ADK on his keyring, and even if he goes through the extra
trouble to get it from a server, the bogus ADK is probably not going
to be signed by a Certificate Authority trusted by the sender, so
PGP will object to him using that ADK to encrypt the message.  This
is a daring attack, an attack that has a very high probability of
being detected.  Then, even if all those problems are somehow
overcome, the attacker still has to intercept the encrypted email on
its way to the intended recipient.  Intelligence agencies are good at
intercepting email traffic, but they would never be foolish enough to
try a daring attack.  That might be why we found absolutely no bogus
ADK packets when we scanned all the public keys on the public key
servers after the bug was reported, even after nearly three years of
deployment of this bug.  If this were a back door, it would be a
particularly stupid design for a back door.

Anyway, we fixed the bug.  We also fixed it on the key servers so
that the key servers would reject bogus ADKs before anyone had a
chance to use them, even if they did not yet have the new fixed
version of PGP.

When we added the ADK feature in 1997, many critics charged that this
would pave the way for government law enforcement or intelligence
agencies to exploit the ADK feature to spy on ordinary citizens.  In
fact, this has not happened.  After many years of struggle, we have
won the crypto debate in the US (and France, and a growing list of
other countries in Europe), and the US export controls were relaxed
completely in January 2000.  After nearly three years of deployment,
the ADK feature has had absolutely zero impact on the state of
government surveillance in the US, and around the world.  The
predictions were wrong.  At the same time, the commercial acceptance
of PGP (in part because of the addition of the ADK feature) has
propagated PGP more widely in the politically powerful computer
industry, which I suspect has in some way contributed to pressure on
the government to relax the export controls in this election year.

One annoying thing I've seen in some of these press reports on the
web is that adding this ADK feature had something to do with the Key
Recovery Alliance (KRA), an industry group formed in the 1990s to put
key recovery features in crypto products, mostly to allow those
products to get export licenses from the US government.  Let me
assure you all that the KRA has nothing to do with us adding this
feature to PGP.  I had this ADK feature added to PGP in late 1997,
before Network Associates acquired PGP Inc.  We added it because it
was a good feature to solve specific data recovery problems that
corporations had, problems I have described above.  It had nothing to
do with export licenses.  We avoided the export controls by
publishing PGP source code in printed books and legally exporting the
books (which were not subject to export controls) to Europe, where
they were scanned in via OCR and compiled back into working software
again and sold on CDROMs all over the world.  A neat trick, don't you
think?  It worked beautifully, and there was no need for us to
compromise PGP's cryptographic integrity to allow it to be exported.
Anyway, later Network Associates acquired PGP Inc, and I made them
drop out of the KRA as soon as they did.  A few months later, NAI
acquired another company (TIS), which was a member of the KRA, and
thereby became a member again by default.  Their membership was up
for renewal, and I asked them not to renew, and they again complied
with my request.  Today it appears the KRA no longer exists, now that
the export controls are gone.

No one made any deals with the government.  There is no conspiracy
here.  There are still no back doors in PGP.  We still publish the
PGP source code for peer review, because we want people to help us
find the bugs.  Most other software companies don't do that.  Their
software is as big and complex as ours, so they probably have as many
(if not more) bugs, but you don't hear about them as much because the
source code is not published for peer review.

PGP started out as a human rights project, and today is used by every
human rights organization in the world.  Our engineers stay with the
PGP team because they feel that they are working on something
important for the world.  It's a thankless job for most of them,
especially with all this criticism from conspiracy theorists who
imagine we've sold out to the government.  Why do people have to
assume the worst motives?  If NAI tried to put a back door in PGP,
all the engineers on the PGP team would quit in a highly visible
protest, and I would be talking to the press about it.  There is no
way that I would let this happen, and NAI has shown no interest in
putting a back door in PGP.
 

Philip Zimmermann
29 August 2000
prz@pgp.com
http://www.pgp.com/phil

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOayfwGPLaR3669X8EQJ7yACgxtAa5JDnyrQeDu3nsKyRby2Yri8An2Du
cjX/kE8Rzbfql+Q/i+DTVYoq
=GE5B
-----END PGP SIGNATURE-----