← RFC Reference

RFC 8551 : Spécification des messages S/MIME 4.0

Pourquoi cela existe

S/MIME 3.2 (RFC 5751, publié en 2010) était solide pour son époque, mais la cryptographie progresse :

• Le mode CBC manque d'authentification. AES-CBC (par défaut dans S/MIME 3.2) chiffre les données mais ne détecte pas les modifications. Un attaquant peut modifier le texte chiffré d'une manière qui produit des changements prévisibles dans le texte en clair. AES-GCM fournit un chiffrement authentifié — toute modification est détectée.
• Les tailles de clé RSA ne cessent de croître. RSA-2048 est considéré comme le minimum aujourd'hui, et RSA-4096 est courant. La cryptographie par courbe elliptique (ECDSA, ECDH) fournit une sécurité équivalente avec des clés beaucoup plus petites, réduisant la taille des messages et le temps de calcul.
• SHA-1 est cassé. S/MIME 3.2 permettait toujours SHA-1 pour la compatibilité rétroactive. S/MIME 4.0 déconseille entièrement SHA-1 pour les signatures.
• Protection des en-têtes. S/MIME 3.2 signait/chiffrait uniquement le corps du message. S/MIME 4.0 ajoute un mécanisme pour protéger les en-têtes (Subject, From, etc.) à l'intérieur de l'enveloppe chiffrée.

Comment cela fonctionne

La structure MIME et l'encapsulation CMS restent identiques à S/MIME 3.2. Les changements se font au niveau des algorithmes et des capacités négociées entre l'expéditeur et le destinataire.

Ce qui a changé de 3.2 à 4.0

Chiffrement authentifié (AES-GCM)

Le changement le plus significatif est le passage de AES-CBC à AES-GCM en tant qu'algorithme de chiffrement de contenu obligatoire :

• AES-CBC chiffre les blocs indépendamment. Un attaquant qui bascule un bit dans le texte chiffré cause des changements prévisibles dans le texte en clair déchiffré. Sans une vérification d'intégrité distincte, le destinataire peut ne pas détecter la modification.
• AES-GCM (Galois/Counter Mode) combine le chiffrement avec une balise d'authentification intégrée. Toute modification du texte chiffré fait échouer complètement le déchiffrement. Ceci est un chiffrement authentifié — vous obtenez la confidentialité et l'intégrité en une seule opération.

Cryptographie par courbe elliptique

S/MIME 4.0 rend ECDSA (pour la signature) et ECDH (pour l'accord de clé) obligatoires à implémenter aux côtés de RSA :

Les clés EC sont dramatiquement plus petites que les clés RSA à des niveaux de sécurité équivalents. Pour le courrier électronique, cela signifie des signatures plus petites et des blocs de transport de clé chiffrés plus petits, ce qui réduit la taille des messages.

Protection des en-têtes

S/MIME 4.0 définit un moyen d'inclure des copies protégées des en-têtes de courrier électronique (Subject, From, To, Date) à l'intérieur du corps MIME signé ou chiffré. Les en-têtes extérieurs restent visibles pour le routage et l'affichage, mais les copies intérieures protégées permettent au destinataire de vérifier que les en-têtes n'ont pas été modifiés en transit :

-- À l'intérieur du corps S/MIME chiffré --
Content-Type: message/rfc822

Subject: Confidential quarterly results
From: cfo@example.com
To: board@example.com
Date: Wed, 12 Mar 2025 09:00:00 -0400

(encrypted body content...)

Le client du destinataire compare les en-têtes intérieurs avec les en-têtes extérieurs et alerte s'ils diffèrent.

Détails techniques clés

RSA-OAEP vs. RSA PKCS#1 v1.5

S/MIME 3.2 utilisait RSA PKCS#1 v1.5 pour le transport de clé. Ce schéma de remplissage est vulnérable aux attaques de type Bleichenbacher. S/MIME 4.0 recommande RSA-OAEP (Optimal Asymmetric Encryption Padding), qui est prouvablement sûr contre les attaques par texte chiffré choisi. Les expéditeurs DEVRAIENT utiliser RSA-OAEP lorsque le destinataire indique le support via ses capacités S/MIME.

Attribut Capacités S/MIME

Lors de la signature d'un message, l'expéditeur inclut un attribut SMIMECapabilities énumérant les algorithmes qu'il supporte. Les destinataires utilisent ceci pour sélectionner les algorithmes mutuellement supportés les plus forts pour les réponses chiffrées. S/MIME 4.0 met à jour l'ordre des capacités recommandées :

1. AES-256-GCM
2. AES-128-GCM
3. AES-256-CBC (pour la compatibilité rétroactive)
4. AES-128-CBC (pour la compatibilité rétroactive)

Compatibilité rétroactive

Les agents S/MIME 4.0 DOIVENT être capables de recevoir et traiter les messages S/MIME 3.2. Lors de l'envoi, ils devraient utiliser les algorithmes S/MIME 4.0 (AES-GCM, ECDSA) lorsque les capacités du destinataire indiquent le support, et revenir aux algorithmes 3.2 sinon. L'attribut SMIMECapabilities conduit cette négociation.

Erreurs courantes

• Utiliser AES-CBC quand AES-GCM est disponible. Si le destinataire supporte S/MIME 4.0, préférez toujours AES-GCM. CBC sans vérification d'intégrité est vulnérable aux attaques par oracle de remplissage.
• Ignorer RSA-OAEP. Si vous utilisez toujours RSA pour le transport de clé, utilisez le remplissage OAEP. PKCS#1 v1.5 a des faiblesses connues et ne devrait être utilisé que pour la compatibilité rétroactive avec les destinataires hérités.
• Ne pas annoncer les capacités S/MIME. Si vos messages signés omettent l'attribut SMIMECapabilities, les destinataires supposeront le plus petit dénominateur commun lors de la réponse avec du courrier chiffré.
• Négliger la protection des en-têtes. S/MIME 4.0 définit la protection des en-têtes, mais de nombreux clients ne l'implémentent pas encore. Si vous comptez sur les lignes Subject protégées, vérifiez que le client du destinataire vérifie réellement les en-têtes intérieurs.
• Supposer que le support des certificats EC est universel. Bien que S/MIME 4.0 mandate le support ECDSA/ECDH, de nombreux clients déployés (en particulier les anciennes versions d'Outlook) ne supportent que RSA. Émettez des certificats duaux si l'interopérabilité est critique.
• Toujours signer avec SHA-1. SHA-1 est déconseillé dans S/MIME 4.0. Les clients modernes peuvent rejeter les signatures SHA-1 ou afficher des avertissements. Utilisez au minimum SHA-256.

Impact sur la livrabilité

• Les mêmes considérations que S/MIME 3.2. Le chiffrement S/MIME rend le contenu des messages opaque aux serveurs intermédiaires et aux filtres anti-spam. Cela peut causer des problèmes de livraison si les passerelles de réception ne peuvent pas inspecter le contenu pour la conformité aux politiques.
• Signatures plus petites avec EC. Les signatures par courbe elliptique sont environ 1/10 de la taille des signatures RSA-2048. Pour les courriers électroniques signés en grand volume, cela réduit la bande passante et la taille des messages de manière significative.
• Compatibilité des passerelles d'entreprise. De nombreuses passerelles de courrier électronique d'entreprise déchiffrent S/MIME à la périphérie pour l'analyse de conformité, puis re-chiffrent pour le destinataire. Assurez-vous que votre passerelle supporte les algorithmes S/MIME 4.0 si vous les déployez.
• Avantage réglementaire. Les organisations soumises au RGPD, HIPAA ou aux réglementations financières peuvent exiger un chiffrement authentifié (AES-GCM) plutôt qu'un chiffrement non authentifié (AES-CBC). La conformité à S/MIME 4.0 peut être une exigence pour faire des affaires avec des entités réglementées.

Related RFCs