Directives d'authentification des courriels

ATTENTION !! Ce document a été traduit automatiquement de l'italien

Lignes directrices

Configuration du service de messagerie pour l'authentification

L'Agence nationale italienne de cybersécurité a publié les lignes directrices pour la configuration du service de messagerie électronique en vue de l'authentification, dans le but de renforcer la fiabilité du service de messagerie pour toutes les organisations intéressées et d'accroître son niveau global de sécurité.

Contrôle de version

INDICE

1. Introduction

1.1. Prémisse

Le courrier électronique représente aujourd'hui l'un des services les plus essentiels dans le contexte numérique, car il figure parmi les principaux canaux utilisés par les organisations et les utilisateurs pour la communication et l'échange d'informations¹.

Le fonctionnement du service de messagerie, et notamment la transmission des messages, repose sur le protocole SMTP qui, cependant, n'intègre pas nativement de mécanismes adéquats pour l'authentification de l'expéditeur et la protection de la confidentialité et de l'intégrité des messages. Ces vulnérabilités l'exposent à des risques d'attaques telles que l'usurpation d'identité, le phishing, la falsification et l'interception des messages en transit.

Pour atténuer les faiblesses du protocole SMTP et ainsi réduire le risque lié aux attaques susmentionnées, des mécanismes d'authentification de l'expéditeur et de protection de l'intégrité des messages ont été développés au fil du temps, tels que SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance).

Ces lignes directrices illustrent ces mécanismes dans le but de renforcer la fiabilité du service de messagerie électronique et d'accroître son niveau global de sécurité, en particulier en référence aux menaces décrites au chapitre 4.

Les contre-mesures et les protocoles nécessaires à la protection de la confidentialité des messages électroniques (tels que S/MIME et OpenPGP qui concernent le chiffrement des messages) ne font pas l'objet des présentes directives.

1.2. Règlement de référence

1.3. Documents de référence

» Retour en haut de page

2. Contexte réglementaire

Afin de protéger les actifs numériques du pays, notamment les services de messagerie électronique et les infrastructures qui les hébergent, un large éventail de mesures de sécurité, issues de la législation en vigueur, est en place et fait l'objet de mises à jour constantes.

Le plus haut niveau de protection des services les plus critiques du pays, liés à la protection de la sécurité nationale, est assuré par le Périmètre national de cybersécurité, établi par le décret-loi n° 105 du 21 septembre 2019, modifié par la loi n° 133 du 18 novembre 2019. Ce périmètre prévoit des mesures de sécurité à très haut niveau de protection, détaillées à l'annexe B du décret du Premier ministre n° 81 du 14 avril 2021, qui s'appliquent aux réseaux, systèmes d'information et services informatiques des entités publiques et privées dont dépend l'exercice d'une fonction essentielle de l'État ou la fourniture d'un service essentiel au maintien des activités civiles, sociales ou économiques fondamentales pour les intérêts de l'État, et dont la compromission pourrait porter atteinte à la sécurité nationale.

Par ailleurs, les services de messagerie électronique, comme tous les services numériques de l'administration publique, sont soumis aux dispositions du Règlement sur le cloud, adopté en application de l'article 33-septies du décret-loi n° 179 du 18 octobre 2012 et mis à jour par l'Agence nationale de la cybersécurité (ACN) par le décret directeur n° 21007 du 27 juin 2024. Conformément à ce Règlement, toutes les administrations publiques sont tenues de classer leurs données et services numériques en trois catégories : ordinaires, critiques ou stratégiques, selon le modèle établi par l'ACN. Cette démarche vise à garantir que les données et services numériques de l'administration publique soient traités et fournis via des infrastructures numériques et des services cloud conformes aux exigences, notamment de sécurité, adaptées aux risques liés au niveau de classification correspondant, tel que défini par le Règlement.

Le décret législatif du 4 septembre 2024, n° 138 (dit décret NIS) transposant la directive (UE) 2022/2555 a également établi – par le biais des annexes 1 et 2 de la décision ACN 379907/2025 – les mesures de sécurité de base que les entités essentielles et importantes doivent adopter aux fins des obligations prévues aux articles 23 et 24 du décret NIS, définissant un cadre de sécurité pour renforcer la protection des réseaux et des systèmes d’information, y compris les services de messagerie électronique.

» Retour en haut de page

3. Architecture du service de messagerie électronique

Comme indiqué dans le préambule, le fonctionnement du service de messagerie électronique repose sur le protocole SMTP qui régule la transmission des messages électroniques de l'expéditeur au destinataire.

Le protocole SMTP a été initialement défini en 1982^comme un protocole de stockage et de retransmission. L'expéditeur génère un message via son client de messagerie (également appelé agent utilisateur de messagerie ou MUA), qui l'envoie au serveur de messagerie de l'expéditeur. Ce dernier, par l'intermédiaire d'un composant appelé agent de transfert de messagerie (MTA), transmet le message, éventuellement via un ou plusieurs MTA intermédiaires, pour le livrer au MTA du serveur de messagerie de destination. Le destinataire accède ensuite au message via son client de messagerie (MUA)[1].

Le MTA est donc un composant du service de messagerie qui gère la transmission des messages électroniques de l'expéditeur au destinataire. Les composants MTA sont présents sur les serveurs de messagerie de l'expéditeur et du destinataire, et des MTA intermédiaires peuvent également être configurés, par exemple pour gérer les listes de distribution.

Bien que le terme MTA désigne un composant spécifique des serveurs de messagerie³, étant donné que, dans le cadre de ce document, on se réfère principalement à ces derniers dans leur fonction de MTA, là où il n'y a pas d'ambiguïté, par souci de simplicité, le terme serveur de messagerie sera souvent utilisé à la place du terme plus spécifique MTA.

Ce guide porte sur la configuration des protocoles SPF, DKIM et DMARC afin de permettre aux serveurs de messagerie de vérifier l'authenticité et l'intégrité des messages électroniques.

» Retour en haut de page

4. Menaces

Le protocole SMTP présenté au chapitre précédent a été initialement conçu pour fonctionner au sein d'un réseau académique relativement restreint et ne prenait pas en compte les aspects liés à la sécurité des messages transmis ni à l'authentification de l'expéditeur [1].

La diffusion croissante du courrier électronique et les faiblesses intrinsèques du protocole SMTP ont favorisé, au fil du temps, l'émergence d'attaques dont les principaux types sont brièvement illustrés dans les paragraphes suivants.

4.1. Usurpation d'identité de l'expéditeur

L'usurpation d'identité est une technique de cyberattaque utilisée pour falsifier l'adresse de l'expéditeur d'un message et faire croire que ce dernier provient d'une adresse fiable (comme celle d'un collègue, d'une connaissance ou de sa propre banque), incitant ainsi le destinataire à effectuer des actions potentiellement dangereuses, comme ouvrir une pièce jointe ou cliquer sur des liens contenus dans le message.

Ce type d'attaque est relativement simple à réaliser, car le protocole SMTP ne comprend pas de mécanismes d'authentification de l'expéditeur et, par conséquent, il est possible, via le client de messagerie, de configurer n'importe quelle adresse d'expéditeur lors de l'envoi du message.

Adresse e-mail de l'expéditeur : envelope-from et message-from

Le format des messages électroniques prévoit deux champs distincts pour indiquer l'adresse électronique de l'expéditeur. Ces champs sont nommés envelope-from et message-from : le premier (également appelé chemin de retour car il spécifie l'adresse électronique à laquelle doivent être envoyés les messages d'erreur générés lorsqu'un message n'atteint pas son destinataire) est l'adresse utilisée pour acheminer correctement le message ; le second est l'adresse affichée par le destinataire dans l'en-tête du message reçu.

Par analogie avec l'envoi d'une lettre sous enveloppe par voie postale traditionnelle, l' de l'expéditeur figurant sur l'enveloppe de la lettre correspond à l'en-tête de la lettre indiquant qui a écrit au destinataire.

Il est important de noter que les deux adresses peuvent ne pas correspondre. Cette distinction permet de gérer des situations telles que, par exemple, le transfert de messages provenant de services tiers, la distribution via des listes de diffusion ou les réponses automatiques par courriel.

Il est en effet possible d'indiquer n'importe quel expéditeur à la fois au de l'expéditeur du message (adresse électronique de l'expéditeur affichée par le destinataire dans l'en-tête du message reçu) et au niveau de l'expéditeur de l'enveloppe (adresse électronique de l'expéditeur utilisée pour la transmission du message).

Pour contrer ces menaces, il est donc essentiel de mettre en place des mécanismes permettant d'authentifier de manière fiable l'expéditeur et de vérifier que la personne qui a envoyé le message est effectivement autorisée à le faire.

4.2. Hameçonnage

L’hameçonnage est une technique de cyberattaque visant à l’acquisition frauduleuse d’informations (telles que, par exemple, des identifiants de connexion, des numéros de carte de crédit ou d’autres données sensibles), généralement en envoyant des messages trompeurs qui simulent une origine provenant d’expéditeurs fiables³.

L’usurpation d’identité, examinée dans le paragraphe précédent, est l’une des principales techniques utilisées par un attaquant pour falsifier l’identité de l’expéditeur et faire croire que le message provient d’un utilisateur ou d’un domaine légitime.

Alternativement, une adresse/un domaine d'expéditeur similaire à celui que le destinataire peut reconnaître peut être utilisé, en modifiant, par exemple, le nom d'affichage⁴ afin de renforcer l'authenticité apparente du message.

Pour envoyer des messages d'hameçonnage, il est également possible d'utiliser des comptes légitimes préalablement compromis par l'attaquant.

Un message d'hameçonnage contient généralement un contenu conçu pour générer un sentiment d'urgence, d'inquiétude ou d'intérêt économique chez le destinataire, créant ainsi des situations qui l'incitent à réagir impulsivement et à effectuer des actions spécifiques telles que l'ouverture de pièces jointes malveillantes ou le clic sur des liens qui redirigent vers des sites Web apparemment légitimes, mais qui ont en réalité été créés par l'attaquant dans le but de voler des informations et/ou d'installer des logiciels malveillants.

Les attaques de phishing consistent généralement à envoyer le même message électronique à un grand nombre de victimes, sans adapter le texte au profil spécifique de chacune.

Une variante du phishing est ce qu'on appelle le spear phishing, dans lequel l'attaquant connaît et cible spécifiquement le profil de la victime.

Contrairement à un courriel d'hameçonnage générique, un message d'hameçonnage ciblé utilise des informations contextuelles plus précises pour convaincre l'utilisateur qu'il interagit avec un expéditeur fiable [2].

4.3. Falsification de messages

Le contenu d'un message électronique, comme toute autre communication transitant sur le réseau Internet qui n'utilise pas de techniques de chiffrement de bout en bout (E2EE), peut être intercepté et modifié pendant son transit entre l'expéditeur et le destinataire (un type de menace communément appelé attaque de l'homme du milieu).

Par conséquent, outre la perte de confidentialité, le message reçu pourrait ne pas correspondre à celui initialement rédigé par l'expéditeur.

Un attaquant pourrait, par exemple, manipuler le contenu du message pour lui faire croire qu'il provient d'un expéditeur fiable, modifier le texte ou les liens et/ou pièces jointes présents dans le message, ou encore insérer un code malveillant.

Le destinataire, se fiant à l'authenticité apparente du message, peut ainsi être amené à effectuer des actions potentiellement nuisibles, telles que la communication d'identifiants de connexion, l'autorisation de paiements ou l'ouverture de fichiers malveillants.

Pour contrer ces menaces, il est donc essentiel d'adopter des mécanismes garantissant l'intégrité et l'authenticité du message, en s'assurant que le contenu reçu n'a pas été modifié et que l'expéditeur est bien celui qu'il prétend être.

» Retour en haut de page

5. Contre-mesures

Le chapitre 2 a rappelé la réglementation relative aux mesures de sécurité applicables à la protection des services de messagerie électronique. Le présent document vise principalement à fournir un guide pour la mise en œuvre des mesures de sécurité prévues par cette réglementation et présentées à l'annexe A, qui concernent également la configuration des services de messagerie électronique, afin d'atténuer les risques liés aux menaces abordées au chapitre 4.Il convient toutefois de noter que les indications contenues dans ces lignes directrices s'adressent également aux personnes non soumises à la réglementation susmentionnée.

Les mesures de sécurité en question ne concernent pas explicitement la configuration du service de messagerie, mais – selon la réglementation applicable – la configuration des systèmes informatiques et des systèmes de contrôle industriel (PSNC et réglementation sur le cloud) ou des systèmes d'information et de réseau (NIS2). Les services de messagerie visés par ces lignes directrices relèvent de ces deux types de systèmes.

En particulier, les SPF, DKIMet DMARC sont illustrés ci-dessous ; ils fournissent des mécanismes de sécurité conçus dans le but de renforcer la sécurité globale du service de messagerie électronique et notamment l’authentification de l’expéditeur et le contrôle de l’intégrité des messages.

5.1. FPS

SPF – Sender Policy Framework est un protocole d'authentification, formalisé par la RFC 7208, qui permet à un propriétaire de domaine de spécifier quelles adresses IP sont autorisées à envoyer des messages électroniques en son nom et d'établir les politiques que le destinataire doit appliquer si l'adresse IP associée au domaine⁵ de l'adresse électronique de l'expéditeur ne figure pas parmi celles explicitement autorisées.

Les adresses IP autorisées sont répertoriées dans un enregistrement DNS TXT relatif au domaine de l'expéditeur, appelé enregistrement SPF et illustré dans la section suivante de ce paragraphe.

De cette manière, le serveur de messagerie du destinataire^6, lorsqu'il reçoit un message d'un domaine donné, peut interroger l'enregistrement SPF correspondant et authentifier son origine en vérifiant que l'adresse IP à partir de laquelle le message a été reçu figure parmi celles autorisées à envoyer des messages au nom du domaine.

Il est important de noter que le domaine vérifié au niveau SPF est celui de l'expéditeur (enveloppe). Par conséquent, l'adoption du protocole SPF seul ne suffit pas à contrer l'usurpation d'identité, car ce type d'attaque peut être mené au niveau de l'expéditeur (message)⁷.

Si une organisation externalise, en tout ou en partie, son service de messagerie auprès d'un tiers, tel qu'un fournisseur de services cloud, elle doit s'assurer que les messages envoyés par ce fournisseur passent les contrôles SPF. À cette fin, l'organisation doit inclure dans son enregistrement SPF les adresses IP à partir desquelles les fournisseurs envoient des courriels au nom de son domaine.

Dans le cas du transfert automatique de courriels, les messages étant généralement redirigés par un serveur intermédiaire, l'adresse IP effectuant la livraison finale ne correspond plus à celle initialement autorisée par le domaine de l'expéditeur. Dans ce cas, afin d'éviter l'échec de la vérification SPF, il est nécessaire d'autoriser également les serveurs de transfert intermédiaires, ou de recourir à des mécanismes tels que SRS (Sender Rewriting Scheme) ou ARC (Authenticated Received Chain), qui peuvent s'avérer plus efficaces, notamment en présence de nombreux serveurs de transfert intermédiaires.

Il convient de souligner que, pour que le protocole SPF soit véritablement efficace, il doit être correctement configuré non seulement par l'expéditeur, mais aussi par le destinataire. En particulier :

• L' expéditeur doit publier l'enregistrement SPF sur le serveur DNS concerné déclarant les adresses autorisées à envoyer des courriels en son nom ;
• Le destinataire doit configurer son propre serveur de messagerie afin qu'il exécute la vérification SPF sur les messages reçus et applique de manière cohérente les politiques qui en résultent.

5.1.1. Enregistrement SPF

Un enregistrement SPF est un enregistrement DNS de type TXT dont le nom correspond au domaine de l'expéditeur et dont le contenu est constitué⁸ par la section indiquant la version⁹ et une série de directives qui indiquent le comportement du serveur de messagerie du destinataire lorsqu'il y a correspondance entre l'adresse IP du domaine de l'expéditeur et une directive.

Les directives sont formées par un mécanisme précédé d'un qualificateur. Les principaux mécanismes utilisés dans les enregistrements SPF sont : [2]:

• ip4, liste les adresses IPv4 autorisées ;
• ip6, liste les adresses IPv6 autorisées ;
• a, autorise les adresses IP présentes dans l'enregistrement A du domaine ;
• mx, autorise les adresses IP liées aux enregistrements MX du domaine ;
• include, autorise les adresses IP présentes dans l'enregistrement SPF d'un autre domaine ;
• « all» représente toutes les adresses IP qui n'ont pas été explicitement autorisées par d'autres mécanismes.

En particulier, le « all » permet d'établir des politiques pour les messages provenant d'adresses IP qui n'ont pas été déclarées par les mécanismes précédents.

De plus, SPF fournit les qualificateurs suivants à associer aux mécanismes :

• + (pass) indique que les adresses IP correspondant au mécanisme associé sont autorisées. Il s'agit du qualificateur par défaut si aucun autre n'est spécifié ;
• - (échec) indique que les adresses IP correspondant au mécanisme associé ne sont pas autorisées ;
• ~ (softfail) indique que les adresses IP correspondant au mécanisme associé ne sont probablement pas autorisées. Cette déclaration est plus incertaine que la précédente. Dans ces cas, le message doit être accepté mais marqué pour une analyse plus approfondie ; il est utilisé par exemple dans les cas de débogage ou lorsqu'il est prévu que la vérification SPF pourrait échouer ;
• ? (Neutre) indique qu'aucune indication n'est donnée pour les adresses IP correspondant au mécanisme associé. Le comportement par défaut consiste à accepter le message.

Il est important de souligner qu'en pratique, l'enregistrement SPF est composé de manière à spécifier les adresses IP autorisées, puis à utiliser la directive `-all` pour indiquer que toutes les autres adresses ne sont pas autorisées (voir les exemples ci-dessous). Cette configuration est recommandée car elle permet d'indiquer explicitement les adresses IP autorisées et d'exclure toutes les autres.

En tout cas, il est recommandé de ne jamais utiliser la directive +all (ou son équivalent all) car elle correspondrait à l'autorisation de toutes les adresses IP.

Exemples d'enregistrements SPF

Autoriser une adresse IP spécifique

v=spf1 ip4:203.0.113.0 -all

L'enregistrement SPF ci-dessus utilise la version 1 et autorise l'adresse IP 203.0.113.0 via le mécanisme ip4 (en réalité, aucun qualificateur n'étant spécifié pour ce mécanisme , le qualificateur par défaut « + » est utilisé implicitement). La directive « -all » , formée par le mécanisme « all » et le qualificateur « - » (échec), indique que toutes les autres adresses ne sont pas autorisées.

Autoriser un espace d'adressage IP spécifique

v=spf1 ip4:203.0.113.0/24 -all

L'enregistrement SPF présenté ci-dessus est analogue au précédent, mais autorise toutes les adresses IP de l' 203.0.113.0/24 .

Autoriser plusieurs adresses IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -tous

L'enregistrement SPF indiqué ci-dessus autorise exclusivement les adresses IPv4 203.0.113.22 et 203.0.113.44.

Autoriser les adresses d'enregistrement MX et un domaine spécifique

v=spf1 mx include:spf.emailprovider.it -all

L'enregistrement SPF présenté ci-dessus autorise exclusivement les adresses IP des enregistrements MX du même domaine que l'enregistrement SPF et celles autorisées du domaine spf.emailprovider.it (par exemple, le domaine d'un fournisseur de services de messagerie).

5.1.2. Processus d'authentification

Si la vérification SPF est correctement configurée, le serveur de messagerie du destinataire, à la réception d'un nouveau message, récupère l'enregistrement SPF du domaine de l'expéditeur en interrogeant le serveur DNS qui contient les enregistrements de ce domaine, à partir de l'adresse indiquée dans le champ « De ». Par exemple, si l'adresse indiquée dans le champ « De » est alice@example.com, le serveur de messagerie du destinataire récupère l'enregistrement SPF du domaine example.com.

Le serveur de messagerie du destinataire effectue ensuite la vérification SPF, en analysant l'enregistrement SPF pour déterminer si l'adresse IP d'où provient le message est autorisée à envoyer des courriels pour le example.com . Si le message est validé par la vérification SPF, il est remis au destinataire.

Par exemple, si l'enregistrement SPF du domaine example.com était v=spf1 ip4:203.0.113.22 -all, la vérification ne réussirait que si l'adresse IP du serveur expéditeur était 203.0.113.22 , tandis qu'elle échouerait pour toute autre adresse.

» Retour en haut de page

5.2. DKIM

DKIM – DomainKeys Identified Mail est un protocole d'authentification, formalisé par la RFC 6376, qui permet à un propriétaire de domaine de garantir l'authenticité des messages électroniques envoyés en apposant une signature numérique (signature DKIM) générée par le serveur de messagerie via des algorithmes de cryptographie publics et insérée dans les en-têtes du message à transmettre.

Pour permettre au destinataire de vérifier que le message n'a pas été modifié pendant la transmission, la clé publique associée à la signature DKIM est conservée dans un enregistrement TXT du DNS public du domaine de l'expéditeur, appelé enregistrement DKIM, qui est interrogé par le serveur de messagerie du destinataire lors de la réception du message.

La signature et l'enregistrement DKIM sont illustrés dans les sections suivantes de ce paragraphe.

Comme pour SPF, DKIM doit également être correctement configuré par l'expéditeur et le destinataire, et en particulier :

• L'expéditeur doit configurer son serveur de messagerie pour générer des signatures DKIM et publier l'enregistrement DKIM sur le serveur DNS correspondant ;
• Le destinataire doit configurer son serveur de messagerie afin qu'il effectue une vérification DKIM sur les messages reçus.

5.2.1. Signature DKIM

La signature DKIM est générée à partir d'éléments désignés du corps et des en-têtes du message et se compose d'une série de paires clé-valeur qui spécifient des éléments parmi lesquels :

• v: version du protocole¹⁰;
• a: algorithme de chiffrement utilisé¹¹;
• d: domaine de signature déclarant l'authenticité du message¹²;
• s: sélecteur indiquant quelle clé publique DKIM rechercher dans l'enregistrement DNS¹³;
• h: liste des en-têtes d'e-mail inclus dans la signature¹⁴;
• bh: hachage du corps du message encodé au format base64¹⁵;
• b: signature numérique réelle générée avec la clé privée et encodée au format base64¹⁶;
• x: date de validité de la signature ;
• c: type de canonisation.

La canonisation est le processus de normalisation des éléments d'un message avant sa signature numérique, afin de réduire l'impact des petites modifications pouvant survenir lors de sa transmission, telles que les espaces ou les sauts de ligne répétés. Il existe deux types de canonisation : la canonisation simple, qui exige une correspondance exacte entre le message original et le message reçu, et assouplie, qui applique des normalisations comme la suppression des espaces, la conversion des majuscules en minuscules dans les en-têtes et la réduction du nombre de lignes vides consécutives dans le corps du message.

5.2.2. Enregistrement DKIM

L'enregistrement DKIM est stocké dans un enregistrement DNS de type TXT dont le nom suit la structure selector._domainkey.domain, où _domainkey est une étiquette indiquant qu'il s'agit bien d'un enregistrement DKIM. Le contenu de l'enregistrement DKIM est constitué d'une série de paires clé-valeur spécifiant des éléments parmi lesquels :

• v: version du protocole ;
• k: type de clé, qui par défaut est RSA ;
• p: clé publique encodée au format base64.

Exemple d'enregistrement DKIM

Nom : s1._domainkey.example.com
Valeur : v=DKIM1 ; k=rsa ; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

L'enregistrement DKIM d'exemple est associé au sélecteur s1 du example.com , utilise la version 1 et contient la clé publique RSA encodée au format base64 (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Processus d'authentification

Si le protocole DKIM est correctement configuré sur les serveurs de messagerie de l'expéditeur et du destinataire, le processus d'authentification et de vérification DKIM prévoit que le serveur de messagerie de l'expéditeur crée la signature DKIM du message, comme décrit au paragraphe 5.2.1, et l'ajoute au message lui-même. Plus précisément, la signature DKIM contient dans le champ « d » ^le domaine de signature et dans le champ « b » la signature numérique du message, générée avec la clé privée de ce domaine.

À la réception d'un message, le serveur de messagerie du destinataire récupère l'enregistrement DKIM du domaine signataire (d de la signature DKIM) auprès du serveur DNS contenant les enregistrements de ce domaine. Il utilise ensuite la clé publique contenue dans l'enregistrement DKIM pour vérifier la signature numérique (b ) de la signature DKIM. Si la vérification est concluante, le message est remis au destinataire.

5.2.4. Aspects cryptographiques

Sur le plan cryptographique, DKIM a historiquement utilisé l' algorithme RSA , en particulier dans la variante rsa-sha256 , considérée comme la norme depuis 2007. La nouvelle alternative, introduite par la RFC 8463 , est Ed25519-SHA256 , une forme moderne de signature numérique basée sur des courbes elliptiques qui garantit une plus grande efficacité et des clés beaucoup plus compactes.

Sur le plan technique, RSA, avec une longueur de clé de 2048 bits, demeure la norme universelle, mais les clés sont longues et les signatures relativement volumineuses. Ed25519, quant à lui, offre des clés neuf fois plus courtes et des signatures quatre fois plus petites, avec des performances de signature jusqu'à trente fois supérieures à celles de RSA 2048. Malgré ces avantages, son adoption en production reste limitée : en 2026, Ed25519 n'est vérifié que par quelques fournisseurs, tandis que certains opérateurs majeurs ne prennent pas en charge de manière fiable la signature ni la vérification, ce qui le rend inadapté comme solution unique en production.

Pour cette raison, malgré sa supériorité technique, l'utilisation d' Ed25519 n'est pas recommandée , au moment de la rédaction du présent document, sauf en combinaison avec RSA , via une double signature , à titre expérimental et comme mesure de compatibilité future. Tant que les principaux fournisseurs n'auront pas pleinement mis en œuvre sa vérification, RSA demeure essentiel pour garantir une fiabilité maximale de la livraison des messages.

En ce qui concerne la sécurité à long terme, il est important de rappeler que ni RSA ni Ed25519 ne sont résistants aux attaques des futurs ordinateurs quantiques [3], et la transition vers des algorithmes post-quantiques nécessitera de nouvelles normes DKIM qui n'existent pas actuellement, ce qui rend essentiel de surveiller les développements de la cryptographie de nouvelle génération et les futures recommandations de l'ACN dans ce domaine.

En ce qui concerne la gestion des clés cryptographiques, la clé privée DKIM doit être protégée par des mesures de sécurité rigoureuses, en la conservant sur des systèmes isolés accessibles uniquement aux services autorisés, en adoptant des permissions restrictives, une rotation périodique et une surveillance constante pour empêcher tout accès non autorisé ou toute compromission.

» Retour en haut de page

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance est un protocole d'authentification, formalisé par la RFC 7489, qui intègre^les mécanismes SPF et DKIM permettant à un propriétaire de domaine de spécifier, aux destinataires des messages transmis à partir de ce domaine, les politiques de gestion des messages qui échouent aux vérifications SPF et DKIM.

Plus précisément, DMARC introduit un mécanisme d'authentification, appelé alignement, qui vérifie la correspondance entre les domaines authentifiés par SPF et DKIM et le domaine associé au « de » du message reçu. Il est important de noter que la vérification d'alignement entre le « de » et le domaine SPF/DKIM échoue systématiquement si la vérification SPF/DKIM correspondante échoue (voir figure 4).

L'alignement peut être vérifié en strict , où une correspondance exacte est requise entre les domaines authentifiés par SPF/DKIM et celui relatif au message-from , ou en mode souple, où il suffit que les domaines principaux correspondent, même si les sous-domaines peuvent être différents.

Par exemple, en permissif , pour les domaines sub1.example.com et sub2.example.com, un alignement serait trouvé à des fins de vérification DMARC (puisque le domaine principal, example.com, est identique). En strict , en revanche, la vérification d'alignement DMARC échouerait en raison de l'absence de correspondance exacte entre les domaines.

Grâce à la vérification d'alignement, même si un attaquant réussissait à passer les contrôles SPF et/ou DKIM en utilisant un message provenant d'une enveloppe différente de celle authentifiée par SPF et/ou du domaine de signature authentifié, DMARC détecterait toujours la divergence, assurant une vérification cohérente et fiable de l'identité de l'expéditeur [2] .

Les politiques de gestion des messages qui échouent¹⁹ sont spécifiées dans un enregistrement TXT du serveur DNS relatif du domaine de l'expéditeur appelé enregistrement DMARC et illustrées dans la section suivante de ce paragraphe.

DMARC permet également d'indiquer aux destinataires d'envoyer des rapports aux propriétaires des domaines expéditeurs concernant les messages prétendant provenir de ce domaine. Ainsi, le propriétaire du domaine peut vérifier si son domaine est utilisé de manière non autorisée et dans quelle mesure, en analysant, par exemple, le nombre de messages qui lui sont effectivement attribués parmi l'ensemble des messages revendiquant son origine.

Comme pour SPF et DKIM, DMARC doit également être correctement configuré par l'expéditeur et le destinataire, et en particulier :

• l'expéditeur doit publier l'enregistrement DMARC dans son DNS spécifiant les politiques selon lesquelles gérer les messages ne passant pas la vérification DMARC ;
• Le destinataire doit configurer son serveur de messagerie pour exécuter la vérification DMARC sur les messages reçus.

5.3.1. Enregistrement DMARC

Le nom de l'enregistrement DMARC a la structure _dmarc.domaine, où _dmarc est une étiquette utilisée pour indiquer que l'enregistrement DNS est un enregistrement DMARC et domaine est le domaine auquel la politique fait référence.

L'enregistrement DMARC se compose d'une série de paires clé-valeur spécifiant des éléments parmi lesquels :

• v: Protocole DMARC version²⁰;
• p: politique à appliquer aux messages échouant à la vérification DMARC, peut prendre l'une des valeurs suivantes : aucune, quarantaine, rejet;
• aspf: mode d'alignement à appliquer à la vérification SPF (peut être relâché, valeur par défaut ou strict) ;
• adkim: mode d'alignement à appliquer à la vérification DKIM (peut être relâché, valeur par défaut ou strict) ;
• rua: adresses électroniques auxquelles envoyer des rapports agrégés contenant des informations statistiques et récapitulatives sur les messages reçus du domaine de l'expéditeur ;
• ruf: adresses e-mail auxquelles envoyer des rapports détaillés sur les messages individuels reçus du domaine de l'expéditeur qui ont échoué à la vérification DMARC.

Exemple d'enregistrement DMARC

Nom :
_dmarc.example.com
Valeur :
v=DMARC1 ; p=reject ; rua=mailto:dmarc-reports@example.com ; ruf=mailto:dmarc-fail@example.com ; adkim=s ; aspf=s

L'enregistrement DMARC d'exemple est associé au domaine example.com , utilise la version 1 et spécifie la politique de rejet des messages échouant à la vérification DMARC, demandant le mode strict pour la vérification de l'alignement des domaines SPF et DKIM et pour transmettre des rapports agrégés à l'adresse électronique dmarc-reports@example.com et des rapports d'échec à l'adresse dmarc-fail@example.com .

5.3.2. Politiques DMARC

Comme indiqué dans le paragraphe précédent, l'enregistrement DMARC indique la politique que le serveur de messagerie du destinataire doit appliquer aux messages qui ne réussissent pas la vérification DMARC. Les politiques possibles sont les suivantes :

• aucun: le domaine de l'expéditeur ne donne aucune indication concernant la livraison des messages dont la vérification DMARC a échoué ;
• mise en quarantaine: le domaine de l'expéditeur indique que les messages ne passant pas la vérification DMARC doivent être considérés comme suspects (par exemple, soumis à un examen plus approfondi, traités comme spam ou étiquetés comme suspects) ;
• rejeter: le domaine de l'expéditeur indique que les messages ne passant pas la vérification DMARC doivent être rejetés.

5.3.3. Processus de vérification et d'application des polices d'assurance

Si le protocole DMARC est correctement configuré sur les serveurs de messagerie de l'expéditeur et du destinataire, à la réception du message, le serveur de messagerie du destinataire récupère les enregistrements SPF et DKIM pour effectuer les vérifications correspondantes, ainsi que l'enregistrement DMARC (détaillé au début du paragraphe 5.2.4). Si le message échoue à la vérification DMARC, la politique indiquée dans l'enregistrement DMARC (aucune, mise en quarantaine ou rejet) est appliquée.

Il convient de noter que chaque serveur de messagerie peut adopter des heuristiques et des politiques locales pour déterminer la distribution ou non d'un message, en tenant compte également du résultat des vérifications SPF, DKIM et DMARC. Par conséquent, un processus de décision supplémentaire (« Filtre standard » dans la figure 5) intervient généralement en aval des vérifications susmentionnées et peut inclure des contrôles complémentaires (tels que des filtres anti-spam et anti-malware).

De plus, le serveur de messagerie du destinataire peut transmettre :

• aux adresses indiquées dans le rua de l'enregistrement DMARC, des rapports agrégés contenant des informations statistiques et récapitulatives sur les messages reçus du domaine de l'expéditeur ;
• aux adresses indiquées dans le ruf de l'enregistrement DMARC, des rapports détaillés sur les messages individuels reçus du domaine de l'expéditeur qui n'ont pas passé la vérification DMARC.

» Retour en haut de page

6. Conclusions

Comme indiqué dans le chapitre précédent, afin de contrer au mieux les menaces liées à l'usurpation d'identité du domaine de l'expéditeur, il est nécessaire que les trois protocoles examinés soient mis en œuvre conjointement et, en particulier, que [3]:

• le domaine de l'expéditeur publie correctement les enregistrements SPF, DKIM et DMARC dans le DNS ;
• Le serveur de messagerie de l'expéditeur est configuré pour signer les messages avec DKIM ;
• Le serveur de messagerie du destinataire est configuré pour effectuer les vérifications SPF et DKIM et appliquer les politiques DMARC.

En ce qui concerne la mise en œuvre du protocole, les recommandations suivantes sont également formulées [2]:

• Configurez le SPF en spécifiant quelles adresses IP sont autorisées à envoyer des e-mails au nom du domaine ; pour les domaines non utilisés pour la transmission d’e-mails, par exemple ceux destinés exclusivement aux sites Web, un enregistrement SPF doit tout de même être créé pour indiquer explicitement qu’il n’existe aucun expéditeur d’e-mails valide pour ce domaine ;
• utiliser des protocoles et algorithmes de chiffrement de pointe considérés comme sûrs pour les clés DKIM ; à la date de rédaction de ce document, le RSA 2048 bits est recommandé ;
• protéger adéquatement la clé privée DKIM stockée sur le serveur de messagerie, en adoptant des autorisations d'accès restrictives, et s'assurer que seul le logiciel du serveur de messagerie dispose de privilèges de lecture sur la clé ;
• configurer chaque serveur de messagerie avec une paire de clés et un sélecteur uniques, afin de réduire l'impact d'une éventuelle compromission de clé privée ;
• protéger la clé privée contre toute divulgation accidentelle et contre les tentatives d'accès ou de modification par un attaquant ;
• veiller à ce que les logiciels relatifs aux listes de diffusion vérifient les signatures DKIM sur les messages entrants et apposent de nouvelles signatures DKIM sur les messages sortants ;
• utiliser des paires de clés DKIM uniques pour chaque tiers envoyant des courriels au nom de l'organisation ;
• faire tourner périodiquement les paires de clés DKIM (au moins tous les six mois) afin d'atténuer l'impact d'une éventuelle compromission ;
• révoquer immédiatement les clés en cas de suspicion de compromission ;
• Surveillez les rapports DMARC pour identifier toute erreur de configuration ou tentative d'abus.

Pour plus de détails, veuillez vous référer aux ressources énumérées dans les documents de référence.

Il est à noter que, pour assurer une protection adéquate de la sécurité des courriels, outre les protocoles d'authentification examinés ici, il existe d'autres protocoles – qui ne font pas l'objet de ces directives – tels que, par exemple, TLS – Transport Layer Security qui garantit le chiffrement du canal de transmission et SMIME et OpenPGP qui concernent le chiffrement de bout en bout et l'authentification des messages.

Il est également à noter que, bien qu'il ne s'agisse pas d'un protocole de sécurité de messagerie au sens strict, la mise en œuvre de DNSSEC (Domain Name System Security Extensions) est recommandée pour la sécurité des services de messagerie. DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS afin de garantir l'intégrité et l'authenticité des requêtes DNS. Grâce à DNSSEC, par exemple, les informations relatives aux enregistrements SPF, DKIM et DMARC sont protégées lors de leur transmission, réduisant ainsi le risque d'altération et renforçant la sécurité des services de messagerie.

» Retour en haut de page

Annexe A : Mesures de sécurité

Périmètre national de cybersécurité (PSNC)

PR.IP-1 : Des pratiques de référence (appelées bases de référence) sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriels qui intègrent des principes de sécurité (par exemple, le principe de moindre fonctionnalité).

1. Il existe un document détaillé et mis à jour indiquant, également en ce qui concerne la catégorie ID.AM, au moins :
   • a) les politiques de sécurité adoptées pour le développement des configurations des systèmes informatiques et de contrôle industriel et le déploiement des seules configurations adoptées ;
   • b) la liste des configurations des systèmes informatiques et de contrôle industriel utilisées et la référence aux pratiques de référence relatives ;
   • c) les processus, méthodologies et technologies utilisés qui contribuent au respect des politiques de sécurité.

Réglementation du cloud – Infrastructures et services numériques pour l’administration publique

PR.IP-01 : Des pratiques de référence (appelées bases de référence) sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriels qui intègrent des principes de sécurité (par exemple, le principe de moindre fonctionnalité).

1. Des politiques et des procédures sont définies en référence à la sécurité des applications afin de fournir un soutien adéquat pour la planification, la mise en œuvre et le maintien des fonctionnalités de sécurité des applications, lesquelles doivent être revues et mises à jour au moins une fois par an.
2. Il existe un document détaillé et mis à jour indiquant, également en ce qui concerne la catégorie ID.AM, au moins :
   • a) les politiques de sécurité adoptées pour le développement des configurations des systèmes informatiques et de contrôle industriel et le déploiement des seules configurations adoptées ;
   • b) la liste des configurations des systèmes informatiques et de contrôle industriel utilisées et la référence aux pratiques de référence relatives ;
   • c) les processus, méthodologies et technologies utilisés qui contribuent au respect des politiques de sécurité.
3. Les exigences de base en matière de sécurité des différentes applications sont définies et documentées.
4. Des indicateurs techniques, utiles pour surveiller le niveau de respect des exigences de sécurité et des obligations de conformité définies, sont définis et mis en œuvre.
5. Il existe un processus d'atténuation et de récupération des vulnérabilités des applications pour la sécurité des applications, automatisant la correction lorsque cela est possible.
6. Il existe une procédure pour valider la compatibilité des appareils avec les systèmes d'exploitation et les applications.
7. Il existe un système de gestion des variations en termes de système d'exploitation, de correctifs et/ou d'applications.

Réglementation du cloud – Services cloud pour l’administration publique

PR.IP-01 : Des pratiques de référence (appelées bases de référence) sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriels qui intègrent des principes de sécurité (par exemple, le principe de moindre fonctionnalité).

1. Les politiques et les procédures sont définies en référence à la sécurité des applications afin de fournir un soutien adéquat pour la planification, la réalisation et le maintien des fonctionnalités de sécurité des applications, qui doivent être revues et mises à jour au moins une fois par an [IaaS, SaaS].
2. Il existe un document détaillé et mis à jour indiquant, également en ce qui concerne la catégorie ID.AM, au moins :
   • a) les politiques de sécurité adoptées pour le développement des configurations des systèmes informatiques et de contrôle industriel et le déploiement des seules configurations adoptées ;
   • b) la liste des configurations des systèmes informatiques et de contrôle industriel utilisées et la référence aux pratiques de référence relatives ;
   • c) les processus, méthodologies et technologies utilisés qui contribuent à la conformité aux politiques de sécurité [SaaS].
3. Les exigences de base en matière de sécurité des différentes applications sont définies et documentées.
4. Des indicateurs techniques, utiles pour surveiller le niveau de respect des exigences de sécurité et des obligations de conformité, sont définis et mis en œuvre. 5. Un processus d'atténuation et de récupération des vulnérabilités applicatives est en place pour la sécurité des applications, avec automatisation des corrections lorsque cela est possible.
5. Il existe un processus pour valider la compatibilité des appareils avec les systèmes d'exploitation et les applications [PaaS, SaaS].
6. Il existe un système de gestion des variations en termes de système d'exploitation, de correctifs et/ou d'applications [PaaS, SaaS].

NIS 2

PR.PS-01 : Les pratiques de gestion de la configuration sont établies et appliquées.

1. Pour au moins les systèmes d'information et de réseau pertinents, leurs configurations de base sécurisées (renforcées) sont définies et documentées dans une liste mise à jour.
2. Conformément aux politiques mentionnées dans la mesure GV.PO-01, des procédures sont adoptées et documentées en relation avec le point 1.

» Retour en haut de page

Bibliographie

[1] NIST, « Note technique 1945 ».
[2] NIST, « Publication spéciale NIST 800-177, révision 1 ».
[3] Agence nationale de cybersécurité, « Cryptographie post-quantique et quantique : préparation à la menace quantique ».
[4] Agence nationale de cybersécurité, « Cadre d’authentification du courrier électronique ».

» Retour en haut de page