Courrier électronique: utilisation du cryptage pour authentification et confidentialité

Problèmes:

• Usurpation d'identité (identity spoofing): certains outils, tels Netscape Mail, permettent très facilement à leurs utilisateurs de changer le nom qui apparaîtra dans le champs From: des messages qu'ils envoient (exemple humoristique).
• Lecture  ou modification par des personnes non-autorisées: des responsables de systèmes informatiques ou des personnes mal intentionnées peuvent "intercepter" le contenu d'un message
• Ouverture de pièces jointes ayant un contenu exécutable et semblant provenir d'une personne digne de confiance (par exemple, le fameux message "ILOVEYOU" de mai 2000 ou AnnaKournikova de février 2001)

Besoins:

• pouvoir s'assurer de l'authenticité d'un message (auteur aussi bien que contenu).
• pouvoir cacher le contenu des regards indiscrets.
• pouvoir éviter l'exécution automatique de macros Word/Excel ou de virus envoyés en pièces jointes.

Solution: cryptage à l'aide de deux clés asymétriques (publique et secrète):

• Ces mécanismes sont basés sur le fait qu'il est possible de calculer deux clés complémentaires (une clé publique et une clé secrète) telles que:
  1. La clé publique est accessible à tout le monde
  2. il est "quasiment" impossible de retrouver la clé secrète à l'aide de la clé publique
  3. tout texte encrypté à l'aide d'une des deux clés peut être décrypté à l'aide de l'autre clé: chacune des deux clés permet d'inverser l'encryption réalisée avec l'autre.
• Plus la clé d'encryption est longue, plus robuste sera le cryptage.
• Toute personne voulant utiliser ces mécanismes de cryptage
  • devra se fabriquer, une fois pour toute, une paire de clés (secrète et publique).
  • La clé publique pourra alors être divulguée à tout le monde, par exemple
    • en l'ajoutant au fichier de "signature" automatiquement inclus dans tout message de courrier électronique,
    • ou en l'envoyant à un serveur de clés qui pourra alors la fournir à qui la demandera,
    • ou encore en la mettant dans sa "home page" sur WWW
    • ou dans des serveurs/annuaires globalement accessibles.
  • La clé secrète sera par contre conservée sur l'ordinateur de la personne, de telle façon qu'elle ne puisse être utilisée qu'en fournissant le mot de passe (ou la phrase secrète) fourni lors de la création.

Pour les explications qui suivent, nous supposerons qu'il y a deux correspondants, A et B, qui veulent communiquer entre eux et nous utiliserons la convention suivante pour noter leurs clés correspondantes:

	personne A	personne B
clé publique	CPA	CPB
clé secrète	CSA	CSB

Authentification

Si A veut envoyer un message à B de façon que B ait la certitude que c'est bien A qui l'a envoyé, A va utiliser sa clé secrète (CS_A) pour encrypter son message et n'importe qui, en particulier B, pourra utiliser la clé publique de A (CP_A) pour décrypter le message et ainsi avoir la "certitude" que A est bien l'auteur du message, car seul lui est en possession de la clé CS_A complémentaire à CP_A. Cela implique, bien entendu, que l'on ait confiance en l'authenticité de la clé CP_A.

		Authentification
		Message en clair rédigé par A				Message en clair lisible par B
CSA		Programme d'encryption utilisé par A		CPA		Programme d'encryption utilisé par B
		Message encrypté	envoyé à l'adresse électronique de B			Message encrypté reçu par B

Note: bien que le message envoyé par A circule sur le réseau sous forme encryptée, le message ne peut pas vraiment être considéré comme confidentiel puisque toute personne ayant accès à la clé publique de A peut décrypter le message.

Confidentialité

Si A veut envoyer un message à B de façon que seul B puisse le lire, A devra utiliser la clé publique de B (CP_B) pour encrypter son message et seul B, en possession de la clé CS_B complémentaire à CP_B, pourra le décrypter.

		Confidentialité
		Message en clair rédigé par A				Message en clair lisible par B
CPB		Programme d'encryption utilisé par A		CSB		Programme d'encryption utilisé par B
		Message encrypté	envoyé à l'adresse électronique de B			Message encrypté reçu par B

Ces deux mécanismes sont cumulables, pour assurer aussi bien l'authentification de l'auteur que la confidentialité du contenu: Si A veut envoyer un message à B, il va d'abord utiliser sa propre clé secrète (CS_A) pour encrypter son message une première fois, puis il va utiliser la clé publique de B (CP_B) pour encrypter le résultat de la première phase et envoyer le résultat final à B. Ce dernier devra d'abord utiliser sa clé secrète personnelle (CS_B) pour décrypter une première fois le message reçu, puis devra utiliser la clé publique de A (CP_A) pour décrypter le résultat de la phase précédente et obtenir en clair le message initial de A.

		Authentification+confidentialité
		Message en clair rédigé par A				Message en clair lisible par B
CSA		Programme d'encryption utilisé par A		CPA		Programme d'encryption utilisé par B
		Message encrypté				Message partiellement décrypté
CPB		programme d'encryption utilisé par A		CSB		Programme d'encryption utilisé par B
		Message doublement encrypté	envoyé à l'adresse électronique de B			Message encrypté reçu par B

• Il existe des logiciels "domaine public" permettant de faire l'encryptage et le décryptage, par exemple PGP. Certains systèmes de courrier électronique intègrent directement les fonctions d'encryptage et de décryptage, par exemple EXMH (PGP offre aussi des "plugins" pour Eudora et d'autres systèmes). A défaut, il vous faudra apprendre à utiliser le logiciel de cryptage pour préparer des fichiers que vous enverrez ensuite par courrier électronique.

• Note: certains pays interdisent l'utilisation par des particuliers de mécanismes de cryptage ou de brouillage des communications. Il est donc illégal, dans ces pays, d'utiliser des logiciels tels que PGP. D'autres pays, tels que les Etats-Unis, interdisent l'exportation de technologie cryptographique en dehors de leurs frontières, ce qui représente un sérieux obstacle à la généralisation de l'utilisation de ces techniques.

Accès à des clés publiques PGP

Pour qu'un système de cryptographie à clés assymétriques fonctionne, il faut que les utilisateurs ait confiance en l'authenticité des clés publiques qu'ils utilisent et cette confiance dépendra fortement de la méthode utilisée pour obtenir cette clé:

• La clé publique peut être transmise sur une disquette directement par son propriétaire
• Des clés publiques peuvent être échangées lors de réunions durant lesquelles les participants peuvent contrôler les identités les uns des autres et collecter l'ensemble des clés publiques des participants. Les participants pourront aussi se porter garants les uns des autres pour augmenter le degré de confiance en l'authenticité des clés.
• La clé publique d'une personne peut être sur le Web, dans la "home page" de la personne.
• Les clés publiques peuvent être déposées sur un serveur accessible à tous. Les clés sont stockées avec le nom de leur "propriétaire" et une "empreinte" ("fingerprint", sorte de checksum) est fournie par le serveur pour distinguer chaque clé d'autres clés qui pourraient être associées au même nom de personne (homonymes). Ces serveurs sont accessibles soit par courrier électronique, soit via une interface Web:
  • pgp-public-keys@keys.pgp.net
  • pgp-public-keys@keys.ch.pgp.net
  • pgp-public-keys@keys.de.pgp.net
  • pgp-public-keys@keys.no.pgp.net
  • pgp-public-keys@keys.uk.pgp.net
  • pgp-public-keys@keys.us.pgp.net
  • serveur en Suisse (recherche, ajout)
  • serveur en Autriche (recherche, ajout)
  • serveur en Angleterre (recherche, ajout)

Pièces jointes avec contenu exécutable

Le problème lié aux pièces jointes tient surtout au fait que les fournisseurs de logiciels ne prennent pas de mesures suffisantes pour assurer que l'utilisation de leurs logiciels n'aie pas de conséquences néfastes pour leurs utilisateurs. Beaucoup trop de logiciels sont installés avec, par défaut, des mécanismes de macros ou de scripts activés. Ce sont ces mécanismes qui sont souvent la cause de problèmes tel que la propagation de virus.

Les utilisateurs peuvent toutefois prendre un certain nombre de précautions pour se protéger:

1. Toujours garder à l'esprit que le message que l'on est en train de lire peut avoir été automatiquement envoyé par un programme, sans intervention explicite de l'utilisateur au nom duquel le message est envoyé. Un "bon" logiciel ne devrait pas pouvoir envoyer de message sans le consentement explicite de l'utilisateur.

2. Toujours désactiver l'exécution de scripts qui seraient contenus dans le corps principal d'un message (par exemple Javascript dans un message de type text/html) ou dans une de ses pièces jointes (par exemple script Visual Basic, reconnaissable à l'extension ".vbs".

   Pour désactiver Javascript dans Netscape Navigator, il faut utiliser l'élément de menu "Edit/Preferences" puis, dans le paneau de dialogue, choisir l'onglet "Advanced" (ou "Avancées" si l'interface est en français); suivant le version utilisée, il devrait y avoir une ou deux cases à cocher pour désactiver Javascript, soit globalement, soit uniquement dans des messages de courrier électronique ou de forums de discussion.

   Pour désactiver les scripts (Javascript, Visual Basic, etc.) dans Outlook, il faut modifier les options Internet, choisir l'onglet "Sécurité", puis, pour chaque catégorie de sites, choisir la configuration personnalisée et cocher systématiquement la case "désactiver" pour toutes les rubriques mentionnant des composants ActiveX ou des scripts.

3. Chaque fois que l'on s'apprète à ouvrir une pièce jointe, vérifier le type MIME de la pièce jointe en question et s'abstenir d'ouvrir la pièce jointe si le contenu est un script ou un programme. Si la pièce jointe est un document Word ou Excel ou d'un autre type similaire, n'ouvrir la pièce jointe que si l'on a désactivé les macros dans le logiciel en question. Il est important de désactiver aussi les scripts, car un script peut réactiver automatiquement l'exécution de macros.

   Attention: certains logiciels de courrier électronique ne se basent pas uniquement sur le type MIME d'une pièce jointe pour sélectionner le logiciel qui va ouvrir la-dite pièce jointe. Le nom de fichier associé est parfois aussi utilisé. Par exemple, le fameux virus ILOVEYOU qui a sévi au début du mois de mai 2000, était envoyé dans une pièce jointe de type application/octet-stream, mais un "header" Content-Disposition: attachment; filename="LOVE-LETTER-FOR-YOU.TXT.vbs" (notez l'extension .vbs) faisait que le logiciel Outlook exécutait le contenu en tant que script Visual Basic dès que l'utilisateur demandait au logiciel d'ouvrir la pièce jointe.

   Il faut faire doublement attention si le système est configuré pour ne pas afficher les extensions pour les types de fichiers connus (Windows 9X et suiv.). En effet, dans un tel cas, le nom de la pièce jointe peut sembler complètement anodin (p.ex. AnnaKournikova.jpg au lieu de AnnaKournikova.jpg.vbs

Messages en format HTML

A priori, il peut paraître anodin d'avoir un système de messagerie qui permet de lire des messages en format HTML. Il faut toutefois réaliser que certains mécanismes peuvent donner des effets inattendus. En particulier, la balise <meta http-equiv="Refresh" content="0; URL=UrlDUnDocumentPornographique"> va amener le système de courrier électronique de l'utilisateur à aller chercher automatiquement sur un site web inconnu un document sans que l'utilisateur n'ait explicitement demandé ce document et sans que des mécanismes de filtrage de courrier électronique n'aient pu en examiner le contenu.

La fabrication de virus se démocratise

La création de virus pouvant se propager par courrier électronique ou par copie de fichiers devient un jeu d'enfants: des outils de fabrication automatisés, tels que VBS Worm Generator, disponibles sur Internet, permettent la fabrication de virus personalisés et pour le moment indétectables par les logiciels anti-virus actuels.

---

Pretty Good Privacy (PGP)

• PGP User's Guide (copies locales: Vol. I: Essential Topics; Vol. II: Special Topics)
• Where to get the Pretty Good Privacy Program (PGP) FAQ (ma copie locale du 26 juin 98)
• The International PGP Home Page
• alt.security.pgp FAQ (ma copie locale du 11 février 98)
• PGP public key online server
• RFC 2015: MIME Security with Pretty Good Privacy.

Autres:

• Outlook 98/2000 E-Mail Security Update, sur le site de Microsoft
• Outlook 2000 SR-1 Update: E-mail Security, sur le site de Microsoft
• CERT® Coordination Center: Protecting Yourself from Email-borne Viruses and Other Malicious Code During Y2K and Beyond
• RSAEuro est un outil compatible RSAref developpé en-dehors des US.
• Internet Draft draft-ietf-pkix-ipki-kea-00.txt: Internet Public Key Infrastructure
• Internet Draft draft-ietf-pkix-ipki-part1-05.txt: Internet Public Key Infrastructure, Part I: X.509 Certificate and CRL Profile
• Internet Draft draft-ietf-pkix-ipki2opp-00.txt: Internet Public Key Infrastructure, Part 2: Operational Protocols
• Internet Draft draft-ietf-pkix-ipki3cmp-03.txt: Internet Public Key Infrastructure, Part III: Certificate Management Protocols
• Internet Draft draft-ietf-pkix-ipki-part4-01.txt: Internet Public Key Infrastructure, Part IV: Certificate Policy and Certification Practices Framework
• Internet Draft draft-ietf-pkix-ipki5tsp-00.txt: Internet Public Key Infrastructure, Part V: Time Stamp Protocols
• Internet Draft draft-ietf-pkix-ipki6np-00.txt: Internet Public Key Infrastructure, Part VI: Notary Protocols
• Internet Draft draft-ramsdell-smime-msg-00.txt: S/MIME Version 3 Message Specification

---