← RFC Reference

RFC 8551: Especificación de Mensajes S/MIME 4.0

Por qué existe

S/MIME 3.2 (RFC 5751, publicado 2010) fue sólido para su época, pero la criptografía avanza:

• El modo CBC carece de autenticación. AES-CBC (el estándar de S/MIME 3.2) cifra datos pero no detecta manipulación. Un atacante puede modificar el texto cifrado de formas que produzcan cambios predecibles en el texto plano. AES-GCM proporciona cifrado autenticado — cualquier modificación se detecta.
• Los tamaños de clave RSA siguen creciendo. RSA-2048 se considera el mínimo hoy, y RSA-4096 es común. La criptografía de curva elíptica (ECDSA, ECDH) proporciona seguridad equivalente con claves mucho más pequeñas, reduciendo el tamaño del mensaje y el tiempo de cálculo.
• SHA-1 está roto. S/MIME 3.2 aún permitía SHA-1 para compatibilidad hacia atrás. S/MIME 4.0 depreca SHA-1 completamente para firmas.
• Protección de encabezados. S/MIME 3.2 solo firmaba/cifraba el cuerpo del mensaje. S/MIME 4.0 añade un mecanismo para proteger encabezados (Asunto, De, etc.) dentro del sobre cifrado.

Cómo funciona

La estructura MIME y el empaquetamiento CMS siguen siendo los mismos que en S/MIME 3.2. Los cambios están en los algoritmos y capacidades negociadas entre remitente y destinatario.

Qué cambió de 3.2 a 4.0

Cifrado autenticado (AES-GCM)

El cambio más significativo es el paso de AES-CBC a AES-GCM como algoritmo obligatorio de cifrado de contenido:

• AES-CBC cifra bloques independientemente. Un atacante que invierte un bit en el texto cifrado causa cambios predecibles en el texto plano descifrado. Sin una verificación de integridad separada, el destinatario puede no detectar la manipulación.
• AES-GCM (Galois/Counter Mode) combina cifrado con una etiqueta de autenticación incorporada. Cualquier modificación del texto cifrado causa que el descifrado falle completamente. Este es cifrado autenticado — obtienes confidencialidad e integridad en una sola operación.

Criptografía de curva elíptica

S/MIME 4.0 hace que ECDSA (para firma) y ECDH (para acuerdo de claves) sean obligatorios de implementar junto a RSA:

Las claves EC son dramáticamente más pequeñas que las claves RSA en niveles de seguridad equivalentes. Para correo electrónico, esto significa firmas más pequeñas y bloques de transporte de claves cifrados más pequeños, lo que reduce el tamaño del mensaje.

Protección de encabezados

S/MIME 4.0 define una forma de incluir copias protegidas de encabezados de correo electrónico (Asunto, De, Para, Fecha) dentro del cuerpo MIME firmado o cifrado. Los encabezados exteriores siguen siendo visibles para enrutamiento y visualización, pero las copias protegidas interiores permiten al destinatario verificar que los encabezados no fueron modificados en tránsito:

-- Dentro del cuerpo cifrado de S/MIME --
Content-Type: message/rfc822

Subject: Resultados trimestrales confidenciales
From: cfo@example.com
To: board@example.com
Date: Wed, 12 Mar 2025 09:00:00 -0400

(contenido del cuerpo cifrado...)

El cliente del destinatario compara los encabezados interiores con los exteriores y alerta si difieren.

Detalles técnicos clave

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

S/MIME 3.2 usaba RSA PKCS#1 v1.5 para transporte de claves. Este esquema de relleno es vulnerable a ataques de tipo Bleichenbacher. S/MIME 4.0 recomienda RSA-OAEP (Optimal Asymmetric Encryption Padding), que es probadamente seguro contra ataques de texto cifrado elegido. Los remitentes DEBERÍAN usar RSA-OAEP cuando el destinatario indica soporte mediante sus capacidades de S/MIME.

Atributo de capacidades de S/MIME

Al firmar un mensaje, el remitente incluye un atributo SMIMECapabilities listando los algoritmos que soporta. Los destinatarios usan esto para seleccionar los algoritmos mutuamente soportados más fuertes para respuestas cifradas. S/MIME 4.0 actualiza el orden de capacidades recomendado:

1. AES-256-GCM
2. AES-128-GCM
3. AES-256-CBC (para compatibilidad hacia atrás)
4. AES-128-CBC (para compatibilidad hacia atrás)

Compatibilidad hacia atrás

Los agentes de S/MIME 4.0 DEBEN ser capaces de recibir y procesar mensajes de S/MIME 3.2. Al enviar, deberían usar algoritmos de S/MIME 4.0 (AES-GCM, ECDSA) cuando las capacidades del destinatario indiquen soporte, y retroceder a algoritmos 3.2 en caso contrario. El atributo SMIMECapabilities conduce esta negociación.

Errores comunes

• Usar AES-CBC cuando AES-GCM está disponible. Si el destinatario soporta S/MIME 4.0, siempre prefiere AES-GCM. CBC sin verificación de integridad es vulnerable a ataques de oráculo de relleno.
• Ignorar RSA-OAEP. Si aún usas RSA para transporte de claves, usa relleno OAEP. PKCS#1 v1.5 tiene debilidades conocidas y solo debería usarse para compatibilidad hacia atrás con destinatarios heredados.
• No anunciar capacidades de S/MIME. Si tus mensajes firmados omiten el atributo SMIMECapabilities, los destinatarios asumirán el mínimo común denominador al responder con correo cifrado.
• Descuidar la protección de encabezados. S/MIME 4.0 define protección de encabezados, pero muchos clientes aún no la implementan. Si confías en líneas de Asunto protegidas, verifica que el cliente del destinatario realmente verifica encabezados interiores.
• Asumir que el soporte de certificados EC es universal. Aunque S/MIME 4.0 requiere soporte ECDSA/ECDH, muchos clientes implementados (especialmente versiones antiguas de Outlook) solo soportan RSA. Emite certificados duales si la interoperabilidad es crítica.
• Aún firmar con SHA-1. SHA-1 está deprecado en S/MIME 4.0. Los clientes modernos pueden rechazar firmas SHA-1 o mostrar advertencias. Usa SHA-256 como mínimo.

Impacto en entregabilidad

• Las mismas consideraciones que S/MIME 3.2. El cifrado de S/MIME hace que el contenido del mensaje sea opaco para servidores intermedios y filtros de spam. Esto puede causar problemas de entrega si las puertas de enlace receptoras no pueden inspeccionar contenido para cumplimiento de políticas.
• Firmas más pequeñas con EC. Las firmas de curva elíptica son aproximadamente 1/10 del tamaño de firmas RSA-2048. Para correo electrónico firmado de alto volumen, esto reduce significativamente el ancho de banda y el tamaño del mensaje.
• Compatibilidad con puerta de enlace empresarial. Muchas puertas de enlace de correo corporativas descifran S/MIME en el perímetro para escaneo de cumplimiento, luego re-cifran para el destinatario. Asegúrate de que tu puerta de enlace soporta algoritmos de S/MIME 4.0 si los implementas.
• Ventaja regulatoria. Las organizaciones sujetas a GDPR, HIPAA o regulaciones financieras pueden requerir cifrado autenticado (AES-GCM) en lugar de cifrado no autenticado (AES-CBC). El cumplimiento de S/MIME 4.0 puede ser un requisito para hacer negocios con entidades reguladas.

Related RFCs