Authentification des messages électroniques

Dans un précédent article, nous avons présentés les risques d’usurpation d’identité et différents protocole qui vont permettre d’authentification un domaine de messagerie pour réduire ces risques, cependant, ces protocoles ne permettent pas d’authentifier un utilisateur. Il peut arriver qu’un compte de messagerie soit piraté et tous les messages reçus sont bien authentifier par ces protocoles car il proviennent bien du domaine émetteur, mais ne prouvent pas que nous communiquons avec l’utilisateur.

Prenons par l’exemple suivant: Paul situé dans le domaine example.org souhaite discuter avec Jean-Paul situé dans le domaine example.com et sont de très bon amis, par ailleurs, les deux domaines ont activés l’authentification SPF et DKIM. Paul, qui est inconscient des risques à eu son adresse mail piraté via des attaques de phishing. Un jour, Jean-Paul reçoit des messages contenant des pièces jointes et ces messages ont bien été authentifié par SPF et DKIM puisqu’ils proviennent du domaine example.org. Sans se soucier, Jean-Paul ouvres ces messages et pas de chance, son poste de travail est infectés. Comme le montre cet exemple, l’authentification SPF/DKIM ne va pas permettre d’éviter une usurpation d’identité, mais simplement d’authentifier le domaine émetteur et éviter simplement les relais SMTP qui ne sont pas autorisés à émettre un message pour un domaine. Pour résoudre ce problème d’usurpation, nous devons avoir recours à une authentification de l’utilisateur.

Dans cet article, nous allons voir deux protocoles qui vont permettre d’authentifier un utilisateur au moyen d’un certificat électronique et permettre aussi de sécuriser les échanges puisque ces protocoles prennent en charge le chiffrement. Dans la section qui suit, nous allons voir rapidement le fonctionnement des certificats, puis dans la prochaine section, nous verrons ces deux protocoles.

Les certificats électroniques

Le certificat électronique est un moyen permettant d’assurer quatre grandes fonctions dans la sécurité des échanges:

• L’intégrité des données, c’est-à-dire de s’assurer que les données transmises n’ont pas été altérée;
• La non-répudiation, assure que les messages ont bien été envoyés par la personne et ne peux être contesté;
• La confidentialité, permet de rendre un message illisible pour une tierce personne;
• L’authentification va permettre de s’assurer que nous communiquons bien avec la bonne personne.

Pour permettre de réaliser ces différentes fonctions, un certificat électronique se base sur un algorithme de chiffrement asymétrique ce qui nécessite d’avoir une paire de clé privée et publique. La clé privée va permettre de signer un certificat pour prouver sont identité, puisqu’une clé privée n’appartient qu’à l’utilisateur mais permet aussi de déchiffrer les messages, tandis que la clé publique va permettre de chiffrer les messages par un autre utilisateur, c’est cette clé qui doit être distribuer aux utilisateurs.

Un certificat est une structure de données qui contient des informations caractérisant un utilisateur: nom, prénom, adresse mail, etc. sa clé publique mais aussi la durée de validité du certificat. Un certificat c’est comme une carte d’identité. Lorsqu’un nous avons un contrôle d’identité, nous montrons notre carte d’identité pour prouver notre identité car le vérificateur sait que cette carte fait foi puisqu’elle à été signé par un organisme de confiance qui est la sous-préfecture. Un certificat c’est pareil, nous montrons notre certificat aux utilisateurs pour prouver notre identité et elle à été signé par une tierce personne.

Pour accentuer l’identité d’un utilisateur, un certificat doit être signé par une tierce personne de confiance. Le signataire va signer ce certificat grâce à sa clé privée et l’ajouter dans le certificat. Lorsqu’un client va vérifier la validité du certificat, il va savoir que le certificat est digne de confiance puisqu’il connait le signataire car il possède son certificat.

Mais que signe le signataire dans le certificat ? Pour prouver que la clé publique appartient bien à l’utilisateur, le signataire va générer un condensat grâces à des algorithmes de hachage (SHA ou MD5) des différentes informations indiqué dans le certificat: nom, prénom, adresse mail etc. mais aussi la clé publique. Le signataire va générer une empreinte numérique sur le condensat avec sa clé privée et l’ajouter au certificat. Lorsqu’un client va vérifier la validiter du certificat, il va extraire l’empreinture numérique du signataire grâce à sa clé publique qu’il possède au préalable, puis va générer un condensat des données du certificat et effectue une comparaison avec l’empreinte générée. Si ces deux condensats sont correctes, alors le certificat est valide. La figure ci-dessous illustre le processus de signature d’un certificat et de vérification:

Une carte d’identité possède une date de validité. A l’expiration de cette date, nous devons la renouveller. Un certificat possède aussi une durée de validité. Cette durée peut être choisie lors de la création du certificat. Lorsqu’un certificat dépasse cette durée, le vérificateur va s’assurer que cette date n’est pas dépassée. Si elle l’est, une erreur va survenir et le certificat ne sera pas considéré comme valide.

Comme nous l’avons vu précédemment, un certificat doit être signé par une personne de confiance pour accentuer l’identité et permettre ainsi d’établir un lien de confiance, cependant, la signature d’un certificat peut être différentes en fonction du type de certificat:

• Certificat X.509
• Certificat OpenPGP

Dans le chiffrement des messages, nous pouvons utiliser ces deux types de certificats, cependant, certaines nuances existent. Nous allons étudier dans la section ci-dessous deux méthodes de chiffrement pour la messagerie qui sont S/MIME et PGP qui s’appuient tous les deux sur les certificats.

Authentification d’un utilisateur

Dans cette section, nous allons étudier deux méthodes d’authentifications et de chiffrement qui s’appuie sur les certificats.

Authentification S/MIME

Le standard S/MIME est apparu en 1999 dans la RFC 2632 et la dernière version est décrit dans les RFC 5750 et 5751 et permet de sécuriser le contenu d’un message électronique mais aussi d’authentifier les émetteurs grâces aux certificats. Comme il est indiqué dans l’article “Authentification d’un domaine de message”, chaque message possède un en-tête SMTP qui contient différents directives qui vont permettre de relayer les messages jusqu’aux destinataires. Pour permettre de sécuriser un message, S/MIME va ajouter dans cette en-tête SMTP des directives que nous allons étudier un peu plus loin dans ce document.

S/MIME utilise des certificats X.509 qui définissent un format de certificats définit dans la norme X.509 mais aussi la façon dont les certificats sont signés. Ces signatures de certificats s’appuient sur un système hiérarchique et nécessite une infrastructure à clé publique (PKI) que nous allons voir dans la section suivante.

X.509 est un standard qui normalise le format des certificats et est standardisé par l’UIT (Union Internationnal des Télécommunications), puis l’IETF à standardisé ce format dans la RFC 5280. Un certificat X.509 possède un certains nombres de champs et ces champs suivent une convention de nommage.

L’infrastructure PKI

Comme nous l’avons vu précédemment, la signature d’un certificat nécessite l’action d’une tierce personne qui va signer le certificat via sa clé privée. Dans la norme X.509, il peut avoir un ou plusieurs acteurs qui signent les certificats et qui sont des Autorités de Certifications, CA (Certificate Authority). La signature des certificats s’appuie sur une infrastructure à clé publique, ou PKI (Public Key Infrastructure) qui est un ensemble de composants logiciels, humains et annuaires, qui délivrent des certificats mais aussi les révoques. Une PKI repose sur une infrastructure hiérarchique, dont chaque noeud possède un certificat signé par le noeud supérieur. Ce fonctionnement va permettre à des entités de déléguer la gestion des certificats. La figure ci-dessous illustre une PKI avec les certificats associés aux entités:

Mais comment un utilisateur va vérifier un certificat ? Prenons l’exemple avec Brad et Angelina et chacuns possède le certificat de l’autre. Lorsque Brad reçoit le certificat d’Angelina, il va voir que le certificat est signé par le CA3 mais il ne connait pas ce CA et ne lui fait pas confiance. Pour cela, CA3 va envoyer le certificat avec sa clé publique signé par CA1. Grâce à cette clé publique il verra que le certificat Angelina est bien signé par CA3. Cependant, Brad identifie que ce certificat est signé par CA1 et va donc lui demander son certificat pour obtenir sa clé publique et prouver ainsi la légitimité de CA3. Mais le certificat de CA1 est signé par le root. Brad doit maintenant contacter le root pour obtenir la clé publique et permettre ainsi de vérifier l’intégrité de CA2. Cependant, un certificat X.509 doit être signé par une entité supérieur, or, un root est situé dans le sommet de cette hiérarchie, mais qui à pu signer le certificat de root ? C’est tout simplement un certificat auto-signé. Mais est-ce que Brad peut faire confiance à cette entité et prouver qu’il est intègre car tout repose sur lui ? Et si oui, comment le vérifier ? En fait, nous possédons sur nos ordinateurs tous les certificats des roots qui sont mis à jour automatiquement par le système. Par exemple, sous Linux, vous trouverez dans le répertoire /etc/ssl/certs/ ces certificats.

Puisque Brad possède sur son ordinateur le certificat de root, il va pouvoir vérifier que CA2 est intègre car il a était signé par root. Mais une question subsiste. Peut-on faire confiance au certificat root ? Et c’est là qu’il faut faire confiance aux éditeurs qui mettent à jours nos certificats en partant du principe qu’ils vérifient bien la validité des certificats root.

Tout le processus de vérification que nous venons de voir ce nomme chaine de confiance et ont peut aussi identifier l’une des faiblesses dans cette infrastructure, c’est que si une partie d’une chaine est corrompu, alors le reste de la chaine qui en découle ne peux être considéré comme valide. Mais cet article n’est pas là pour faire de la polémique.

Commnt obtenir un certificat X.509 ? Tout d’abord, il faut générer une clé publique/privée et effectuer une requête de signature à un CA avec sa clé publique. Ce dernier va ensuite renvoyer la clé publique signé avec sa clé privée, ce qui nous donne un certificat X.509. Notre certificat aura aussi une durée de validité et à l’échéance de cette date, il faut renouveller le certificat. Par ailleurs, les certificats X.509 nécessite toutes une infrastructure de gestion (humaines, logiciels, matérielles) et sont souvent payant et onéreux pour un utilisateur lambda et sont plutôt utilisés par les entreprises, mais il existent des alternatives qui signent les certificats gratuitements comme Let’s Encrypt, cependant, la durée d’un certificat est relativement court (3 mois pour certains).

S/MIME

Maintenant que nous avons vu les certificats X.509, nous pouvons entrer dans le vif du sujet, c’est-à-dire le fonctionnement de S/MIME. Ce protocole va répondre à 4 fonctions de la sécurité que nous avons vu précédemment:

• Garantir l’intégrité des données
• Garantir la non-répudiation
• Garantir l’authentification
• Garantir la confidentialité

Pour permettre de réaliser ces 4 fonctions, S/MIME va appliquer un ensemble d’algorithme de hachage mais aussi de chiffrement dans un ordre précis. Ces étapes sont les suivantes:

1. Application d’une fonction de hachage sur des éléments de l’expéditeur, telle que son adresse email puis application de la clé privée sur l’empreinte pour la signature numérique
2. Chiffrement du message via un algorithme de chiffrement symétrique
3. Via la clé publique du destinataire, nous chiffrons la clé de chiffrement pour garantir la confidentialité des données

La première étape va permettre de garantir l’intégrité des données, la non-répudiation ainsi que l’authentification grâce à l’empreinte générée via l’algorithme de hachage mais aussi grâce à la clé privée qui va permettre de garantir l’identité de l’expéditeur.

La seconde étape va permettre de garantir la confidentialité des données via un algorithme de chiffrement symétrique, comme 3DES ou AES. Comme un algorithme de chiffrement symétrique nécessite l’utilisation d’une clé de cryptage, cette clé doit être transmit dans le message pour que le destinataire puisse déchiffrer ce message, or, si nous transmettons cette clé, une tierce personne pourra déchiffrer le message. C’est pour cette raison que la clé de chiffrement est chiffré grâce à la clé publique du destinataire, obtenue grâce au certificat.

Mais pourquoi utiliser un chiffrement symétrique pour chiffrer le message ? L’une des principales raison est le temps d’exécution. En effet, le chiffrement symétrique est plus rapide que le chiffrement asymétrique.

A l’issue de ces 3 étapes, le message sera transmit jusqu’au destinataire. Lorsque le destinataire reçoit le message, il va effectuer les opérations inverses pour la lecture du message.

Comme il a été dit précédement, S/MIME va insérer dans l’en-tête SMTP des directives, mais quels sont-elles ? Dans la section 3.2.1 de la RFC 5751(2), est indiqué 4 grands types de directive qu’ajoute S/MIME, cependant, nous allons nous consacrer seulement sur deux d’entre elles:

• application/pkcs7-signature
• application/pkcs7-mime

La première directive va permettre d’indiquer que le fichier fournit en pièce jointe contient la signature du message (Cf. Section 3.4.3 de la RFC 5751(2)). En effet, il est possible d’utiliser S/MIME que pour la signature d’un message. Cela peut être utile dans le cas où le destinataire ne possède pas de certificat et donc de clé publique pour un échange sécurisé. Pour permettre d’identifier le fichier contenant la signature, S.MIME fournit en paramètre de cette directive filename qui indique le nom du fichier qui contient la signature encodé en base64. L’exemple ci-dessous est tiré de la RFC 5751 et nous montre une signature d’un message:

Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

Comme le montre l’exemple ci-dessous, nous avons notre signature encodé en base64 et est situé dans le fichier smime.p7s situé en pièce jointe. Remarquer l’extension particulière, ici p7s, qui indique que c’est une signature. Cette extension n’est pas choisi au hasard, mais c’est spécifié dans la section 3.2.1 de la RFC 5751(2).

La directive pkcs7-mime indique que le fichier fournit en pièce jointe contient la signature du message ainsi que le message encrypter lui même avec sa clé (Cf. Section 3.2 de la RFC 5751(2)). Comme le montre l’exemple ci-dessous (tiré de la RFC 5751), nous avons notre contenue encodé en base64 et est fournit en pièce jointe dans le fichier smime.p7m.

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V

Avantages et inconvénients

L’un des avantages de l’utilisation de S/MIME c’est sa sécurité. En effet, durant la transmission de bout-en-bout, le message sera sécurisé et seule le destinataire pour lire le message car lui seul possède la clé qui permet de déchiffrer le message. Par ailleurs, il permet aussi de garantir l’identité d’un utilisateur et cela va éviter toute usurpation d’identité.

Cependant, S/MIME repose sur des certificats X.509 et nécessite une PKI, pour obtenir un certificat, il suffit de contacter une entité qui délivre, mais cela à un coût. En effet, ces certificats ne sont pas gratuit et doivent être renouveller lorsque la date de fin de validité arrive à échéance. Ce coût peut être relativement coûteux pour un utilisateur lambda, c’est donc une solution utilisée à des fins commerciaux.

Nous avons terminé avec la présentation des certificats X.509 ainsi que S/MIME. Dans la section ci-dessous, nous allons voir un autre type de protocole au même titre que S/MIME pour sécuriser les messages.

Authentification PGP

PGP (Pretty Good Privacy) est un protocole de sécurité qui répond aux 4 grandes fonctions que nous avons vu précédement, cependant, son application ne s’est pas limité à la messagerie électronique mais à plusieurs utilisation: sécurisation des fichiers, des partitions systèmes. Par la suite, PGP est devenu un standard normalisé dans la RFC 4880: OpenPGP. Ce protocole va décrire le format des messages échangés entre différentes applications PGP et permettre ainsi leurs intéropérabilités.

PGP au même titre que S/MIME va permettre de garantir l’identité d’un utilisateur au moyen d’un certificat numérique et appliqer une signature numérique aux données, cependant, OpenPGP introduit un nouveu concept de signature: le Web of Trust, ou toile de confiance.

La toile de confiance

Dans une infrastructure hiérarchique comme PKI, nous devons avoir une confiance totale dans le CA, puisque seule lui atteste l’identité d’un utilisateur. PGP utilise une infrastructure décentralisé dont chaque noeud peut signer un certificat et permettre ainsi d’avoir une confiance plus forte dans l’identité d’un utilisateur. Ces relations entre tous ces noeuds va former une toile de confiance.

Prenons un exemple pour mieux illustre ce fonctionnement. Nous avons ici Bob et Alice ainsi que Eve. Bob et Alice se connaissent, mais Bob ne connait pas Eve. Un jour, Bob et Alice se rencontre durant un meeting et s’échangent leurs certificats via un support quelconque: messagerie, physique et même téléphone (mais c’est un peu compliqué) et Bob va signer le certificat d’Alice pour attester l’identité d’Alice et vice-versa. Lorsqu’ils ont effectués cette échange, ils peuvent désormais communiquer via la messagerie en toute sécurité via PGP. Un autre jour, Alice et Eve se rencontre durant un after-work, par exemple, et ils décident eux aussi d’échanger leurs certificats PGP et de signer chacun le certificat de l’autre. A cette étape-là, nous avons eu deux signatures pour le message certificat: celui d’Alice.

Puis un jour, Bob, reçoit un message de la part d’Eve et contient dans l’objet de ce message le certificat d’Eve. Bob remarque que ce certificat à été signé par Alice, ne connaissant pas Eve mais connaissant Alice, il sais qu’il peut faire confiance à Eve. C’est cette relation entre ces trois noeuds qui va créer une toile de confiance.

Que ce passe-t-il si un certificat est révoqué ? Comme nous l’avons vu précédemment, lorsque la date de validité du certificat arrive à échéance, ce certificat ne sera plus valide et le vérificateur ne fera pas confiance au détenteur du certificat. Reprenons l’exemple avec Bob qui reçoit le message d’Eve. Lorsque Bob va vérifier le certificat d’Eve, il va remarquer qu’il est invalide car il n’a pas été renouvellé. A cette étape-là, il ne va pas faire confiance à Eve car Bob ne la connait pas encore et il peut ignorer son message même s’il remarque qu’il est signé par Alice.

L’exemple précédent nous à montré que la distribution des clés est effectuée de façon physique, cependant, cela peut être très contraignant pour des grands réseaux PGP, ou nous pouvons avoir plus d’une centaine de certificat et lorsque le certificat à été une fois de plus signée, il faut le redistribuer à tous ses contacts. Pour simplifier cette distribution, nous pouvons avoir recourt à un serveur de certificat, où serveur de clé, qui contiendra tous les certificats déposés et un utilisateur pourra depuis son application PGP récupérer un certificat et chiffrer un message.

Les certificats OpenPGP

Quels sont les informations que contiennent un certificat PGP ? Tout comme un certificat X.509, un certificat PGP contient des informations sur l’identité du détenteur: nom, prénom mais aussi sa clé publique et autres informations listés dans le tableau ci-dessous:

Un certificat PGP peut être composé de plusieurs identité pour une même personne. Dans chacune de ces identités, figurent des informations permettant l’identification de la personne: nom, prénom, adresse mail, etc. Les informations personnelles sont stockés dans une “fiche” indiqué dans le certificat. Reprenons l’exemple avec Bob et Alice. Supposons que Bob possède un certificat avec deux fiches pour s’identifier. La première fiche contient des informations telle que son nom mais aussi son adresse mail personnel: [email protected], tandis que la seconde fiche contient l’adresse mail de Bob mais de son travail: [email protected].

Bob et Alice ce connaissent en dehors de la vie professionelle, puisqu’ils se trouvent régulièrement le soir après le travail pour discuter. Lorsque Bob va présenter son certificat à Alice, cette dernière va signer la fiche de Bob contenant l’adresse mail personnel: [email protected]. De ce faut, elle va attester que cette adresse mail est bien celle de Bob.

Bob, travail dans un environnement OpenSource, il souhaite distribuer sa clé à ses collègues de travail et chacun d’entre eux, va signer la fiche de Bob contenant l’adresse mail [email protected], car ils savent que Bob travail bien dans cette entreprise. A ce stade, nous avons plusieurs personnes qui ont signées le certificat de Bob sur des fiches différentes, mais représente une seule personne: Bob.

Par exemple, sur un serveur de clé du MIT, nous pouvons voir que la clé de Linus Torvalds est signé par plusieurs acteurs: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x79BE3E4300411886

Le fonctionnement de PGP

Nous avons vu que PGP va permettre de chiffrer différents éléments: fichiers, partitions, messages électronique et permet aussi de garantir l’identité grâce aux certificats et créer un réseau de confiance: Web of Trust. Dans cette section, nous allons voir comment fonctionne PGP pour le chiffrement des données.

Pour comprendre le fonctionnement de PGP, nous allons revenir vers nos deux amis: Bob et Alice. Dans cette exemple, ont part du principe que chacun possède le certificat PGP de l’autre et que Bob souhaite envoyer un message à Alice. Pour générer son message, Bob va faire appel au programme PGP et lui envoyer son message. Tout d’abord, le programme va générer la signature du message. Pour cela, il va faire un hash du message via un algorithme de chiffrement, puis, il va chiffrer cette empreinte via sa clé privée. Comme nous l’avons vu précédement, Alice va déchiffrer cette signature via la clé publique de Bob pour obtenir l’empreinte et vérifier si le message n’a pas été corrompu durant le transfert. Cette partie va permettre de garantir la non-répudiation mais aussi l’authentification (grâce à la clé privée) et l’intégrité des données. Cette signature est ajouter au message.

Ensuite, Bob va devoir générer une clé de session, qui est un nombre aléatoire générée via l’entropie du système (je ferais d’ailleur un article à ce sujet). Cette clé de session va permettre de chiffrer le message via un algorithme de chiffrement symétrique. Et enfin, le programme va chiffrer la clé de session via la clé publique d’Alice et ajouter cette clé au message chiffré. A ce stade là, Bob peut envoyer le message à Alice.

Lorsqu’Alice reçoit le message, elle va déchiffrer via sa clé privée le message pour obtenir la clé de session et permettre ainsi de déchiffrer le message. Lorsqu’elle à déchiffrer ce message, elle va pouvoir vérifier l’intégrité des données en déchiffrant via la clé publique de Bob l’empreinte générée à la première étape. Elle va ensuite appliquer l’algorithme de hachage au message et comparer ces deux hash. S’ils correspondent, alors le message est bien intègre. La figure ci-dessous illustre ce fonctionnement.

Avantages et inconvénients

PGP possède un grand avantage concernant la gestion des certificats, puisqu’il ne s’appuie pas sur un fonctionnement hiérarchique et centralisé que PKI, mais son utilisation est plus approprié dans les réseaux, telles que la Recherche ou l’éducation et son coût est nul puisque nous générons nous même nos certificats.

Cependant, PGP n’est pas réellement développé pour la message électronique, puisque le message chiffré généré doit être mis en pièce jointe d’un message (car généré en Base64) et il est nécessaire d’avoir recourt à des agents externes pour chiffrer les messages électroniques, contrairement à S/MIME qui s’intègre très bien dans la message électronique.

Conclusion

Pour résumer cet article, S/MIME et PGP vont permettre de chiffrer la communication entre deux interlocuteurs de bout-en-bout via des algorithmes de chiffrement et s’appuient sur des certificats pour attester l’identité d’un utilisateur via une signature numérique appliquée sur le message. La différence majeure entre ces deux protocoles résident dans la gestion des certificats. Dans S/MIME, c’est plutôt une infrastructure de gestion centralisé (PKI) et s’emploie plus dans des environnements professionnels puisqu’ils sont payants, tandis que PGP utilise un réseau de noeud pour la signature des certificats mais s’emploie plus dans un réseau ouvert. L’utilisation d’un de ces protocoles dépend essentiellement de l’environnement de travail.

Comme tout élément de sécurité qui nécessite des clés de chiffrement, il est vivement conseillé de changer une fois par an ces clés. En effet, un attaquant pourra casser les clés de chiffrement lorsqu’il aura assez de message pour deviner cette clé ce qui va rendre ces protocoles obsolète. Par ailleurs, il est conseillé de ne pas utiliser de clé de petite taille pour ne pas faciliter l’attaquant, une taille supérieur à 1024 bits est raisonable.

Cependant, avec tous les protocoles que nous pouvons mettre en place, la meilleure sécurité reste la vigilance de l’utilisateur, c’est pour cette raison, qu’il est important de former les utilisateurs aux risques et de ne pas répondre à des messages qui semble suspects.

Mes sources

1. Livre “Les Réseaux” d’Andrew Tanenbaum et David Wetherall
2. https://tools.ietf.org/html/rfc5751
3. https://users.ece.cmu.edu/~adrian/630-f04/PGP-intro.html
4. https://tools.ietf.org/html/rfc4880