{{indexmenu_n>20}} # Renouveler les clés DKIM DKIM est un protocole permettant d'authentifier l'expéditeur du message et de vérifier son intégrité par des moyens cryptographiques. En savoir plus [[technique:old:etudes:mail:protocoles:smtp:limites#dkim|ici]]. ## Motivation Pour rappel, DKIM implique l'usage d'une clé privée et d'une clé publique. On se réfère à une paire de clés par un *sélecteur* et la clé publique est publiée dans un enregistrement DNS. DKIM prévoit le renouvellement des clés. Mais pourquoi faudrait-il renouveler les clés ? Il y a deux raisons. La première est de se prémunir d'une compromission de la clé. De la même manière que l'on renouvelle les mots de passe régulièrement, on fait de même avec les clés. Ceci étant, on peut raisonnablement supposer qu'une clé RSA de 4096 bits ne soit pas compromise facilement. La deuxième raison est plus "politique". L'article sur lequel se base cet argument est disponible ici : [Ok Google: please publish your DKIM secret keys](https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/). L'idée est que DKIM a été conçu pour assurer l'authenticité de l'expéditeur et l'intégrité du mail pendant que celui-ci **est en transit**. C'est une très bonne chose, car si la clé n'est pas compromise (et que DNSSEC est utilisé), alors on peut avoir l'assurance que le mail provient bien du serveur que l'on pense et que son contenu n'a pas été modifié. Ceci étant, l'effet de bord est le suivant : des années après, on peut toujours valider l'authenticité et l'intégrité d'un mail, alors que celui-ci est arrivé à destination depuis bien longtemps. Avec DKIM, l'intégrité et l'origine de mails piratés peut être vérifiée cryptographiquement pour une durée illimitée, sans que les utilisateurs puissent choisir, puisque c'est le serveur de soumission qui signe le mail. Or, le but originel de DKIM est d'empêcher des spammeurs de modifier un mail en transit par des relais non-sécurisés, ou de forger un faux mail. C'est essentiellement une mesure anti-spam, dont l'objectif n'a jamais été de garantir la [non répudiation](https://fr.wikipedia.org/wiki/Non-r%C3%A9pudiation) ou l'intégrité d'un mail à vie. Cette utilisation de DKIM n'est pas hypothétique : de nombreux mails leakés ont été authentifiés grâce à DKIM (voir [cet article de Wikileaks](https://wikileaks.org/DKIM-Verification.html)). L'idée n'est pas vraiment de discuter si cet effet de bord est souhaitable, mais plutôt de noter que ce n'est pas le but de DKIM ni ce à quoi on s'attend en envoyant un mail. Lorsque j'envoie un mail que je ne signe pas moi-même, je ne m'attends pas à ce que le serveur mail l'authentifie cryptographiquement à vie. L'auteur de l'article argumente que cet effet de bord peut créer des incitatifs au piratage de mail et au chantage. D'un autre côté, on pourrait argumenter que l'authenticité garantie par DKIM dans les mails concernant des scandales politiques est une bonne chose. L'argument consiste finalement à dire que le mail n'est pas censé empêcher le **déni plausible** (ou *plausible deniability* en anglais), terme couramment employé dans les communications chiffrées pour désigner que personne ne peut prouver cryptographiquement que j'ai bien envoyé tel ou tel message. Par exemple, [Signal garantit le déni plausible](https://signal.org/blog/simplifying-otr-deniability/) : les messages peuvent avoir été écrits par l'une ou l'autre des parties d'une conversation sans que l'on puisse prouver quoi que ce soit. Les utilisateurs de mail devraient pouvoir choisir s'ils souhaitent renoncer à vie au déni plausible. Pour éviter cet effet de bord, il faut donc : * Renouveler plus ou moins régulièrement les clés DKIM. * Publier les **anciennes clés privées**, afin de restaurer le déni plausible lorsque le mail est stocké et archivé. ## Renouvellement Inspiré de [[technique:adminsys:mail:config:dkim|la création d'une clé DKIM]]. ### Créer une nouvelle clé On se rend dans le conteneur mail, dans le dossier `/etc/dkimkeys`. Ce dossier correspond à un volume Docker persistent dont le chemin réel n'est pas important. ``` $ docker exec -it pica-mail-mta bash # cd /etc/dkimkeys ``` On lance ensuite : ``` opendkim-genkey -b 4096 -s -d picasoft.net ``` Cette commande génère une paire de clés DKIM (RSA/4096 bits), valides pour le nom de domaine `picasoft.net` et avec un sélecteur au format `mAAAA` (*e.g.* `janv2021` pour janvier 2021). Le nom du sélecteur est arbitraire. Les fichiers créés ont pour nom `.private` pour la clé privée et `.txt` pour l'enregistrement DNS qui contient la clé publique. Renommer `.private` en `.picasoft.net.rsa` pour un changement transparent au redémarrage de Postfix et lui assigner les bonnes permissions : ``` mv .private .picasoft.net.rsa chmod 600 .picasoft.net.rsa chown opendkim:opendkim .picasoft.net.rsa ``` ### Publier la nouvelle clé publique dans le DNS Le fichier `.txt` contient déjà l'enregistrement DNS pré-formaté, ce qui rend facile sa publication. Il suffit de le rajouter au fichier de zone et de redémarrer le serveur DNS. On trouvera un peu de documentation sur le serveur DNS de Picasoft [[technique:adminsys:dns:picasoft|sur cette page]]. On peut ensuite vérifier que l'opération a bien fonctionné avec la commande suivante : ``` dig -t txt .picasoft.net._domainkey ``` ### Modifier le sélecteur utilisé par Postfix La troisième étape est de modifier la clé DKIM utilisée par Postfix. À ce jour, la modification se fait dans le [docker-compose.yml](https://gitlab.utc.fr/picasoft/projets/services/mail-system/-/blob/master/docker-compose.yml) du serveur de mail, via la variable d'environnement `DKIM_SELECTOR`. Une fois la modification faite, on redémarrage le conteneur Postfix. Pour tester si la modification a fonctionné, on peut s'envoyer un mail depuis une adresse Picasoft (mail de test Mattermost, par exemple). On cherche le header `DKIM-Signature` et on vérifie que le sélecteur correspond bien au nouveau ``. À ce stade, on peut supposer que cela fonctionne sans vérifier manuellement l'intégrité du message... ### Révoquer et publier l'ancienne clé Pour le moment, cette publication n'est pas faite car par encore discutée/votée. À ne faire qu'après quelques jours d'utilisation de la nouvelle clé, pour laisser le temps aux mails retardataires d'arriver et d'être vérifiés par les destinataires. On peut "révoquer" l'ancienne clé en supprimant tout ce qui se trouve après `p=` dans l'enregistrement DNS. Elle ne sera alors plus utilisable automatiquement (ce qui ne pose aucun souci, puisque DKIM n'est utilisé en théorie qu'à la fin du transit, plus jamais ensuite). On peut enfin publier la clé privée à un endroit que l'on aura défini. [Une astuce](https://rya.nc/dkim-privates.html) propose de publier la clé privée directement dans la zone DNS.