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
[email protected]
http://www.pgp.com/phil
Traduction <[email protected]> et <[email protected]>
-----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
[email protected]
http://www.pgp.com/phil
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0
iQA/AwUBOayfwGPLaR3669X8EQJ7yACgxtAa5JDnyrQeDu3nsKyRby2Yri8An2Du
cjX/kE8Rzbfql+Q/i+DTVYoq
=GE5B
-----END PGP SIGNATURE-----