Pourquoi ai-je besoin d'un propre certificat pour crypter un message S / MIME?
J'essaie d'utiliser Thunderbird pour crypter un message. Je ne veux pas signer le message. Le cryptage est effectué avec la clé publique du récepteur. J'ai importé le certificat du récepteur. Mais quand j'essaie d'envoyer le message, Thunderbird insiste sur mon certificat. Pourquoi?
Lorsqu'un expéditeur utilise Thunderbird pour envoyer un message chiffré S/MIME à un destinataire, Thunderbird requiert le certificat de l'expéditeur en plus du certificat du destinataire, afin que Thunderbird puisse envoyer le certificat de l'expéditeur avec le message au destinataire. Ceci est fait pour deux raisons:
1) Pour que le destinataire puisse vérifier la signature numérique de l'expéditeur sur le message, qui est effectuée à l'aide de la clé privée de l'expéditeur qui correspond à la clé publique de l'expéditeur dans le certificat de l'expéditeur.
2) Pour que le destinataire puisse répondre avec un message chiffré à l'expéditeur.
Thunderbird (ainsi que tout autre client de messagerie) a également besoin de votre propre certificat pour crypter le courrier électronique.
Pourquoi est-ce si?
Lorsque vous envoyez un e-mail, l'e-mail n'est pas seulement envoyé, mais une copie de celui-ci est conservée dans votre dossier envoyé . Par conséquent, lorsque vous envoyez un e-mail crypté, l'e-mail doit être crypté non seulement pour le destinataire, mais aussi pour vous-même. Sinon, vous ne pourrez pas lire votre propre copie de l'e-mail envoyé. Cela signifie que le message est chiffré à l'aide des deux, la clé publique du destinataire et de l'expéditeur, afin que les deux puissent le déchiffrer à l'aide de leurs clés privées. (Le même mécanisme est utilisé lorsque vous envoyez à plusieurs destinataires, btw.)
Ce qui précède est spécifié dans RFC 8551 S/MIME 4.0 Message Specification (ainsi que ses prédécesseurs). Cité à la section 3.3 Création d'un message enveloppé uniquement, étape 2:
En plus de chiffrer une copie de la clé de chiffrement de contenu (CEK) pour chaque destinataire, une copie de la CEK DEVRAIT être chiffrée pour l'expéditeur et incluse dans EnvelopedData.
Notez que la clé de chiffrement de contenu (CEK) fait référence au mécanisme réel qui consiste à chiffrer le contenu du message à l'aide d'une clé symétrique générée ad hoc (la CEK). Cette clé est ensuite chiffrée de manière asymétrique à l'aide de la clé publique. Ainsi, par souci de simplicité, nous disons qu'un message est chiffré avec une clé publique, cela signifie en fait que seule la CEK est chiffrée avec la clé publique et attachée au message. Une spécification détaillée peut être trouvée dans RFC 5652 Cryptographic Message Syntax (CMS) .
En théorie, le client de messagerie pourrait simplement chiffrer pour le destinataire et laisser la copie envoyée non chiffrée, mais cela créerait une faille de sécurité dont l'utilisateur ne serait probablement pas au courant, ce qui est totalement indésirable.