S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS
Home / Media / News / S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS; L'arbre vous cacherait-il la forêt ?

S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS
17 Dec ‘21

Intro :

La sécurisation des e-mails, c’est important, tout le monde s’accorde sur ce sujet. Afin de sécuriser l’accès aux e-mails, on utilise un nom d’utilisateur et un mot de passe ou, mieux, un Multi Factor Authentication (MFA), dont la connexion par Transport Layer Security (TLS)  se fait par un certificat SSL. TLS est également utilisé pour l’envoi d’e-mails entre serveurs mails.

Mais comment le réseau récepteur, et plus important encore, le destinataire de l’e-mail, est-il assuré que l’e-mail reçu a bien été envoyé par la personne supposée ?  Pour cela, il existe différentes normes complémentaires ayant chacune leur utilité spécifique.

Secure Multipurpose Internet Mail Extensions (S/MIME) existe depuis 2002 et est de faite la norme pour les e-mails protégés / vérifiables de bout en bout.

Bien que Sender Policy Framework (SPF), DomainKeys Identified Email (DKIM) et Domain-based Message Authentication, Reporting & Conformance (DMARC) existent depuis un certain nombre d’années, elles ne sont appliquées à grande échelle que depuis 2018.

Depuis 2021 une nouvelle norme s’y ajoute : Brand Indicators for Message Identification (BIMI) couplée à un Verified Mark Certificate (VMC).

Quésaco ?

Toutes les normes citées ont leur utilité et applications spécifiques ; elles ne sont donc pas interchangeables ou excluantes :

 

S/MIME Nécessite un certificat S/MIME par adresse e-mail, qui est généralement installé sur l’appareil de l’utilisateur. Ceci assure que :

  • Le destinataire sache avec certitude qui est l’expéditeur de l’e-mail
  • Le destinataire sache avec certitude que le contenu (corps et pièces jointes) de l’e-mail n’a pas été modifié
  • Pour les deux options ci-dessus, le certificat S/MIME est uniquement requis pour l’envoi
  • L’e-mail soit crypté sur l’appareil sur lequel il peut être lu et lors de l’envoi aussi bien pour le destinataire que pour l’expéditeur, ce qui permet uniquement à l’expéditeur et au destinataire de lire le message.
TLS Nécessite un ou plusieurs certificats SSL par environnement mail côté réseau. Ceci assure que :

  • Le mail soit crypté dès l’envoi par le client mail jusqu’à réception par le destinataire (encryptage durant le transport).
SPF Nécessite seulement un enregistrement DNS. Ceci assure que :

  • L’e-mail soit authentifié, ce qui permet de valider au niveau du réseau que le message a bien été envoyé depuis un serveur mail identifié pour un domaine spécifique.
DKIM Nécessite seulement un enregistrement DNS. Ceci assure que :

  • Chaque e-mail envoyé au niveau du domaine (donc pas au niveau de l’adresse e-mail) soit accompagné d’une signature électronique, pour s’assurer que l’e-mail a bien été envoyé depuis le domaine de l’expéditeur.
DMARC Nécessite seulement un enregistrement DNS. Ceci assure que :

  • Le serveur e-mail récepteur sache comment gérer les e-mails qui ne sont pas conformes aux validations SPF et DMARC. Par exemple : classer les e-mails reçus en quarantaine.
BIMI Nécessite seulement un enregistrement DNS. Ceci assure que :

  • Les e-mails reçus par le fournisseur e-mail du destinataire puissent être pourvus d’un logo visible et validé correspondant à l’entreprise qui a envoyé l’e-mail.
VMC Nécessite un sceau reconnu et protégé, auquel il faudra associer 1 Verified Mark Certificate par logo (valable 1 an). Ceci assure que :

  • Si BIMI est configuré, celui-ci puisse référer à un logo/sceau
  • Si le fournisseur e-mail récepteur supporte BIMI, le logo de l’émetteur soit affiché lors d’un la réception d’un e-mail

Les confusions courantes

 Maintenant que les différentes normes sont claires, il est important de répondre aux questions fréquentes :

  •  Si j’utilise DKIM, je n’ai pas besoin de S/MIME pour une signature électronique ?

DKIM assure une signature électronique au niveau e-mail qui est uniquement utilisé et visible pour le fournisseur e-mail du destinataire. Cette signature électronique DKIM n’est pas visible ou utilisable par le destinataire effectif.

Une signature via S/MIME est quant à elle visible pour le destinataire effectif. La signature électronique S/MIME permet au client mail d’indiquer directement si l’e-mail a été modifié en termes de corps et pièces jointes depuis son envoi ET au destinataire de vérifier l’expéditeur effectif de l’e-mail.

  • Si j’envoie un e-mail déjà crypté via TLS, il n’est pas nécessaire de disposer d’un encryptage e-mail S/MIME ?

TLS assure que l’e-mail est crypté depuis l’instant où on clique sur ‘envoyer’ dans le client mail et jusqu’au moment où il est reçu par le destinataire. En résumé, le chiffrement de données en mouvement, aussi appelé chiffrement de bout en bout.

S/MIME assure le chiffrement de l’e-mail envoyé aussi bien du côté de l’expéditeur que du destinataire. Aussi appelé chiffrement de bout en bout.

À moins de disposer de la clé privée du destinataire, il n’y a pas d’accès aux pièces jointes et au corps de l’e-mail.

Donc si quelqu’un accède illégalement au compte e-mail, il ne pourra lire les mails.

Même le fournisseur e-mail ne peut scanner le contenu des mails, par exemple pour l’envoi de publicités spécifiques.

  • BIMI et VMC, en tant que normes, assurent tout de même mondialement une protection complémentaire des e-mails ?

BIMI et VMC assurent la reconnaissance de marques, et sont de ce fait surtout destinés au marketing.

De plus BIMI et VMC sont, au moment de la rédaction de cet article, seulement pris en charge par Gmail et Yahoo ! Mail

Microsoft a indiqué ne pas envisager prendre en charge BIMI et VMC, et ne le font pas actuellement.

Vérification en ligne de BIMI/VMC en DMARK/DKIM/SPF

Voulez-vous vérifier si une entreprise a configuré (correctement) DMARK, DKIM, SPF, BIMI, et VMC pour son domaine ? C’est possible, très simplement, via : https://bimigroup.org/bimi-generator/

Voulez-vous plus d’informations? Contactez nous s’il vous plait.

L’équipe de KeyTalk