Comprendre SPF, DKIM, DMARC (dans le détail) – Partie 4

Dans la Partie 3, on a vu comment SPF permettait de contrôler les serveurs qui écrivent des emails en notre nom. Maintenant, on va montrer comment se prémunir d’une manipulation de message à notre insu avec DKIM.

DKIM

DKIM est l’acronyme de “DomainKeys Identified Mail” que l’on pourrait traduire de manière maladroite par “Message identifié par des clés de Domaine”.

Cet algorithme permet de vérifier un message en contrôlant :

• Que le message n’a pas été altéré pendant le transport ;
• Que le message provient bien du domaine expéditeur.

Comment fonctionne DKIM ?

DKIM s’appuie sur le chiffrement pour pouvoir authentifier le message.

Pour cela, l’expéditeur génère une paire de clés (une clé publique, une clé privée) et publie la clé publique dans un enregistrement DNS “DKIM” :

selector1._domainkey    TXT "v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZzGCHr2p0l0U1CwaTbMkGfboCvEycCvUtBZshMrJ4uO831ehNso0GQzc6z0P9F6EZSNjThVQdoZZflawVfgL1tv2kpjawVXYjVGtOvgQjNlxy6kwR2sTLPSEYHeyhzOgyxkQexfe12zRpOsK0mybE82optqQkZVgi6OJtDIY9GwIDAQAB;"

Dans l’enregistrement, on trouve en premier lieu “v=DKIM1” indiquant la version 1 de DKIM.
Puis, ‘h’ et ‘k’ qui vont définir l’algorithme de hachage et de chiffrement qui sont utilisés par l’expéditeur.
Ensuite dans ‘p’, la clé publique qui servira aux destinataires pour déchiffrer les signatures émises par l’expéditeur. La clé est en Base64 pour être compatible avec les enregistrements DNS.

Ici, nous avons un sélecteur nommé “selector1” : en effet, le domaine peut avoir autant de clés DKIM que nécessaires. Ces dernières sont différenciées par leur “selector”.

Lorsque l’émetteur écrit à son destinataire, le serveur émetteur calcule le hash du message, le signe avec sa clé privée et le transmet au destinataire qui vérifiera la conformité à réception à l’aide de la clé publique.

Comment est déterminé le résultat du contrôle par DKIM

Sans entrer dans les détails plus complexes de l’ordre de signature des différents éléments du message (header, body), lorsqu’un message est émis par l’expéditeur :

1. Le composant DKIM de son serveur de messagerie calcule le hash du message (Body) ;
2. Il calcule le hash de plusieurs champs d’en-tête ;
3. Il signe les hash avec la clé privée ;
4. Il insère ensuite un en-tête contenant :

• Le nom des en-têtes utilisés pour le contrôle ;
• La taille prise en compte pour le calcul du hash du body ;
• Les signatures ;

D’autres éléments sont ajoutés comme le sélecteur et le domaine utilisé pour la signature.

A réception du message, le serveur de messagerie du destinataire :

1. Calcule à son tour le hash des en-têtes ;
2. Calcule le hash du body ;
3. Déchiffre les hash à l’aide de la clé publique (récupérée dans l’enregistrement DNS DKIM) ;
4. Compare les hash déchiffrés à ceux qu’il a calculés lui-même.

Si les hash concordent, cela signifie que le message provient bien du domaine expéditeur, et qu’il n’a pas été altéré ni manipulé pendant le transport.

L’IETF impose que les en-têtes à signer incluent obligatoirement le champs “From”. Ils recommandent d’exclure “Return-Path” et tout autre en-tête suceptible d’être retiré ou modifié en cours de transport.

Dans la dernière partie, nous allons étudier DMARC, où comment en finir avec les problèmes !