← RFC Reference

RFC 5751 : Spécification des messages S/MIME 3.2

Pourquoi cela existe

La sécurité au niveau transport (TLS, STARTTLS) protège les emails entre les sauts, mais elle a des limites :

• Les opérateurs de serveurs peuvent lire votre courrier. TLS se termine sur chaque serveur. Le serveur d'envoi, le serveur de réception et les intermédiaires voient le contenu en clair.
• Aucune garantie d'origine. DKIM prouve qu'un domaine a traité le message, mais ne prouve pas quelle personne l'a rédigé.
• Pas de détection de modification après livraison. Une fois qu'un message est stocké sur le serveur, les signatures DKIM peuvent être invalidées si le message est modifié. Les signatures S/MIME protègent le contenu lui-même.

S/MIME fournit le chiffrement de bout en bout (seul le destinataire peut déchiffrer) et les signatures numériques (le destinataire peut vérifier l'identité de l'expéditeur et que le contenu n'a pas été altéré). Il utilise des certificats X.509 de la même PKI qui sécurise HTTPS.

Comment cela fonctionne

Les deux opérations

S/MIME enveloppe les messages MIME standard dans des enveloppes cryptographiques utilisant CMS (Cryptographic Message Syntax) :

Vous pouvez signer uniquement, chiffrer uniquement, ou signer puis chiffrer (la combinaison la plus courante).

Signature d'un message

L'expéditeur utilise sa clé privée pour créer une signature numérique sur le contenu du message. Deux formats existent :

• En clair signé (multipart/signed) : Le message original est lisible par n'importe quel client. La signature est une partie MIME séparée. Les clients non-S/MIME voient le message normalement et ignorent la signature.
• Opaque signé (application/pkcs7-mime) : Le message et la signature sont regroupés ensemble. Seuls les clients S/MIME peuvent extraire le contenu.

-- Structure du message signé en clair --
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha-256; boundary="----sig"

------sig
Content-Type: text/plain

This is the original message content.
It is readable by any email client.

------sig
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBgl...
(CMS SignedData encodé en base64)
------sig--

Chiffrement d'un message

L'expéditeur chiffre en utilisant la clé publique du destinataire (de son certificat X.509). Seule la clé privée correspondante du destinataire peut déchiffrer :

-- Structure du message chiffré --
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIAGCSqGSIb3DQEHA6CAMIA...
(CMS EnvelopedData encodé en base64)

En pratique, S/MIME utilise le chiffrement hybride : une clé symétrique aléatoire (par exemple, AES-128-CBC) chiffre le message, et la clé publique RSA/EC du destinataire chiffre cette clé symétrique.

Détails techniques clés

Exigences de certificat

S/MIME s'appuie sur des certificats X.509 émis par une autorité de certification (CA). Le certificat doit :

• Inclure l'adresse email de l'expéditeur dans le Nom alternatif du sujet (SAN) ou le champ Sujet.
• Avoir l'utilisation de clé étendue (EKU) emailProtection.
• Être émis par une CA que le client du destinataire fait confiance.

C'est la plus grande barrière pratique à l'adoption de S/MIME : chaque expéditeur a besoin d'un certificat, et chaque destinataire a besoin du certificat public de l'expéditeur pour vérifier les signatures ou envoyer des réponses chiffrées.

Exigences algorithmiques (S/MIME 3.2)

SHA-1 et 3DES sont encore référencés pour la compatibilité rétroactive mais sont considérés comme faibles. S/MIME 4.0 met à jour ces exigences de façon importante.

Découverte de certificat

Pour le chiffrement, l'expéditeur a besoin du certificat du destinataire. Méthodes courantes de découverte :

• Correspondance antérieure : Extraire le certificat d'un message signé que le destinataire vous a envoyé.
• Répertoire LDAP : De nombreuses organisations publient des certificats dans un répertoire LDAP.
• DNS (SMIMEA/DANE) : RFC 8162 définit la découverte de certificat basée sur DNS via les enregistrements SMIMEA.
• Serveur de clés ou passerelle : Les passerelles S/MIME d'entreprise gèrent les certificats de manière centralisée.

Erreurs courantes

• Confondre S/MIME avec TLS. TLS protège la connexion entre les serveurs. S/MIME protège le contenu du message de bout en bout. Ils résolvent des problèmes différents et doivent être utilisés ensemble.
• Utiliser SHA-1 pour les signatures. SHA-1 est cryptographiquement cassé pour la résistance aux collisions. Utilisez toujours SHA-256 ou plus fort.
• Chiffrer sans signer. Un message chiffré mais non signé ne prouve rien sur l'identité de l'expéditeur. Signez toujours avant de chiffrer pour le chiffrement authentifié.
• Oublier la distribution de certificats. Vous ne pouvez pas envoyer un email chiffré à quelqu'un si vous n'avez pas son certificat public. Planifiez l'échange de certificats avant de déployer S/MIME.
• Utiliser des certificats auto-signés. Les clients des destinataires afficheront des avertissements de confiance. Utilisez des certificats d'une CA reconnue pour l'interopérabilité.
• Ne pas gérer les destinataires mixtes. Si certains destinataires ont des certificats S/MIME et d'autres non, vous devez envoyer le message deux fois : chiffré pour ceux qui ont des certificats, en clair pour les autres.
• Casser DKIM avec signature opaque. Les messages signés opaques restructurent le corps MIME, ce qui peut invalider les hachages de corps DKIM. Les messages signés en clair sont plus sûrs pour la compatibilité DKIM.

Impact sur la livraison

• Les signatures S/MIME peuvent améliorer la confiance. Certaines passerelles de messagerie d'entreprise vérifient les signatures S/MIME et traitent les messages signés plus favorablement. Microsoft Outlook affiche de manière bien visible un ruban de confiance pour les signatures S/MIME valides.
• Le contenu chiffré est opaque pour les filtres de spam. Les filtres de spam ne peuvent pas inspecter les corps de messages chiffrés. Certains filtres peuvent traiter les messages chiffrés avec suspicion, tandis que d'autres les laissent passer. Pour les emails en masse, le chiffrement S/MIME n'est généralement pas pratique.
• Pas un remplacement pour SPF/DKIM/DMARC. S/MIME opère au niveau utilisateur ; SPF, DKIM et DMARC opèrent au niveau domaine. Les deux couches servent à des objectifs différents. S/MIME prouve l'identité individuelle ; DKIM prouve l'autorisation du domaine.
• Conformité d'entreprise. Les secteurs réglementés (finance, santé, gouvernement) exigent souvent S/MIME. La prise en charge des signatures S/MIME sur les emails transactionnels peut être un facteur de différenciation pour les destinataires sensibles à la conformité.

Related RFCs