S / MIME ( Extensiones de correo de Internet seguras / multipropósito ) es un estándar para el cifrado de clave pública y la firma de datos MIME . S / MIME se encuentra en una pista de estándares IETF y se define en una serie de documentos, los más importantes son RFC 3369 , 3370 , 3850 y 3851 . Fue desarrollado originalmente por RSA Data Security y la especificación original utilizó la especificación IETF MIME [1] con el estándar de facto de la industria PKCS # 7 formato de mensaje seguro. Desde entonces, el control de cambios a S / MIME se ha otorgado al IETF y la especificación ahora se superpone a la sintaxis de mensajes criptográficos (CMS), una especificación IETF que es idéntica en la mayoría de los aspectos a PKCS # 7. La funcionalidad S / MIME está integrada en la mayoría del software de correo electrónico moderno e interactúa entre ellos. Dado que se basa en CMS, MIME también puede contener una firma digital avanzada.
Función
S / MIME proporciona los siguientes servicios de seguridad criptográfica para aplicaciones de mensajería electrónica:
- Autenticación
- Integridad del mensaje
- No repudio de origen (mediante firmas digitales)
- Intimidad
- Seguridad de los datos (mediante cifrado)
S / MIME especifica el tipo MIME application/pkcs7-mime
[2] (smime-type "sobreped-data") para el envolvente de datos (cifrado) donde toda la entidad MIME (preparada) a envolver se cifra y empaqueta en un objeto que posteriormente se inserta en un entidad MIME application / pkcs7-mime.
Certificados S / MIME
Antes de que S / MIME se pueda utilizar en cualquiera de las aplicaciones anteriores, se debe obtener e instalar una clave / certificado individual, ya sea de la propia autoridad de certificación (CA) o de una CA pública. La mejor práctica aceptada es utilizar claves privadas separadas (y certificados asociados) para la firma y para el cifrado, ya que esto permite la custodia de la clave de cifrado sin comprometer la propiedad de no repudio de la clave de firma. El cifrado requiere tener el certificado de la parte de destino en la tienda (que generalmente es automático al recibir un mensaje de la parte con un certificado de firma válido). Si bien es técnicamente posible enviar un mensaje cifrado (utilizando el certificado de la parte de destino) sin tener un certificado propio para firmar digitalmente, en la práctica, los clientes S / MIME requerirán que el usuario instale su propio certificado antes de permitir el cifrado a otros. Esto es necesario para que el mensaje se pueda cifrar tanto para el destinatario como para el remitente, y se pueda guardar una copia del mensaje (en la carpeta de enviados) y ser legible para el remitente.
Un certificado personal básico típico ("clase 1") verifica la "identidad" del propietario solo en la medida en que declare que el remitente es el propietario de la dirección de correo electrónico "De:" en el sentido de que el remitente puede recibir correos electrónicos enviados a esa dirección, y, por lo tanto, simplemente prueba que un correo electrónico recibido realmente proviene de la dirección "De:" proporcionada. No verifica el nombre de la persona o el nombre comercial. Si un remitente desea permitir que los destinatarios de correo electrónico verifiquen la identidad del remitente en el sentido de que el nombre de un certificado recibido lleva el nombre del remitente o el nombre de una organización, el remitente debe obtener un certificado ("clase 2") de una CA que lleva a cabo una proceso de verificación de identidad más profundo, y esto implica hacer consultas sobre el posible titular del certificado. Para obtener más detalles sobre la autenticación, consulte firma digital .
Dependiendo de la política de la CA, el certificado y todo su contenido pueden publicarse como referencia y verificación. Esto hace que el nombre y la dirección de correo electrónico estén disponibles para que todos puedan ver y posiblemente buscar. Otras CA solo publican números de serie y estado de revocación, que no incluye ninguna información personal. Este último, como mínimo, es obligatorio para mantener la integridad de la infraestructura de clave pública.
Grupo de trabajo S / MIME de CA / Foro de navegadores
En 2020, el Grupo de trabajo de certificados S / MIME [3] del CA / Browser Forum se creó para crear un requisito básico aplicable a las CA que emiten certificados S / MIME utilizados para firmar, verificar, cifrar y descifrar el correo electrónico. Ese esfuerzo está destinado a crear estándares que incluyen:
- Perfiles de certificado para certificados S / MIME y CA que los emiten
- Verificación del control sobre las direcciones de correo electrónico
- Validación de identidad
- Gestión de claves, ciclo de vida de certificados, prácticas operativas de CA, etc.
Obstáculos para implementar S / MIME en la práctica
- A veces se considera que S / MIME no es adecuado para su uso a través de clientes de correo web . Aunque el soporte puede piratearse en un navegador, algunas prácticas de seguridad requieren que la clave privada se mantenga accesible para el usuario pero inaccesible desde el servidor de correo web, lo que complica la ventaja clave del correo web: proporcionar accesibilidad ubicua. Este problema no es completamente específico de S / MIME: otros métodos seguros para firmar correo web también pueden requerir que un navegador ejecute código para producir la firma; Las excepciones son PGP Desktop y las versiones de GnuPG , que tomarán los datos del correo web, los firmarán mediante un portapapeles y volverán a colocar los datos firmados en la página del correo web. Visto desde el punto de vista de la seguridad, esta es una solución más segura.
- S / MIME está diseñado para brindar seguridad de un extremo a otro. Lógicamente, no es posible tener un tercero que inspeccione el correo electrónico en busca de malware y también tener comunicaciones seguras de un extremo a otro. El cifrado no solo cifrará los mensajes, sino también el malware. Por lo tanto, si el correo no se analiza en busca de malware en ningún lugar, excepto en los puntos finales, como la puerta de enlace de una empresa, el cifrado anulará el detector y entregará el malware con éxito. La única solución a esto es realizar un escaneo de malware en las estaciones de los usuarios finales después del descifrado. Otras soluciones no brindan confianza de un extremo a otro, ya que requieren que un tercero comparta las claves con el fin de detectar malware. Ejemplos de este tipo de compromiso son:
- Soluciones que almacenan claves privadas en el servidor de la puerta de enlace para que el descifrado pueda ocurrir antes del escaneo de malware de la puerta de enlace. Estos mensajes no cifrados se envían a los usuarios finales.
- Soluciones que almacenan claves privadas en escáneres de malware para que pueda inspeccionar el contenido de los mensajes, el mensaje cifrado se retransmite a su destino.
- Debido al requisito de un certificado para la implementación, no todos los usuarios pueden aprovechar S / MIME, ya que algunos pueden desear cifrar un mensaje sin la participación o la sobrecarga administrativa de los certificados, por ejemplo, cifrando el mensaje con una clave pública / privada. emparejar en su lugar.
Cualquier mensaje que un cliente de correo electrónico S / MIME almacena cifrado no se puede descifrar si la clave privada del par de claves correspondiente no está disponible o no se puede utilizar (por ejemplo, el certificado se ha eliminado o perdido o la contraseña de la clave privada se ha olvidado). Sin embargo, un certificado vencido, revocado o que no es de confianza seguirá siendo utilizable con fines criptográficos. Es posible que la indexación del texto sin cifrar de los mensajes cifrados no sea posible con todos los clientes de correo electrónico. Ninguno de estos posibles dilemas es específico de S / MIME, sino más bien el texto cifrado en general y no se aplica a los mensajes S / MIME que solo están firmados y no cifrados.
Las firmas S / MIME suelen ser "firmas separadas": la información de la firma está separada del texto que se firma. El tipo MIME para esto es multiparte / firmado y la segunda parte tiene un subtipo MIME de application / (x-) pkcs7-signature . El software de listas de correo es conocido por cambiar la parte textual de un mensaje y por lo tanto invalidar la firma; sin embargo, este problema no es específico de S / MIME y una firma digital solo revela que se ha cambiado el contenido firmado.
Temas de seguridad
El 13 de mayo de 2018, Electronic Frontier Foundation (EFF) anunció vulnerabilidades críticas en S / MIME, junto con una forma obsoleta de PGP que todavía se usa en muchos clientes de correo electrónico. [4] Apodado EFAIL , el error requirió un esfuerzo coordinado significativo por parte de muchos proveedores de clientes de correo electrónico para corregirlo. [5]
Ver también
- CryptoGraf
- DomainKeys Identified Mail para la firma de mensajes de correo electrónico gestionados por el servidor.
- Cifrado de correo electrónico
- EFAIL , un problema de seguridad en S / MIME
- Guardia de privacidad GNU (GPG)
- Pretty Good Privacy (PGP), especialmente "Seguridad MIME con OpenPGP" ( RFC 3156 ).
Referencias
- ^ RFC 2045: Extensiones multipropósito de correo de Internet (MIME). La primera parte se publicó en noviembre de 1996.
- ^ Balladelli, Micky; Clercq, Jan De (2001). Active Directory de misión crítica: diseño de una infraestructura segura y escalable para Windows 2000 . pag. 550. ISBN 9781555582401.
S / MIME agrega nuevos tipos de contenido MIME que brindan confidencialidad de datos, protección de la integridad, no repudio y servicios de autenticación: application / pkcs7-mime, multipart /igned y application / pkcs7-signature
- ^ CA / Grupo de trabajo del certificado S / MIME del foro del navegador https://cabforum.org/working-groups/smime-certificate-wg/
- ^ Gebhart, Danny O'Brien y Gennie (13 de mayo de 2018). "Atención, usuarios de PGP: las nuevas vulnerabilidades requieren que actúe ahora" . Fundación Frontera Electrónica . Consultado el 29 de mayo de 2018 .
- ^ Hansen, Robert (20 de mayo de 2018). "Efail: una autopsia" . Robert Hansen . Consultado el 30 de mayo de 2018 .
enlaces externos
- RFC 5652 : Sintaxis de mensajes criptográficos (CMS)
- RFC 3370 : Algoritmos de sintaxis de mensajes criptográficos (CMS)
- RFC 5751 : Extensiones de correo de Internet seguras / multipropósito (S / MIME) Versión 3.2 Especificación de mensajes
- RFC 8551 : Extensiones de correo de Internet seguras / multipropósito (S / MIME) Versión 4.0 Especificación de mensajes
- Microsoft Exchange Server: comprensión de S / MIME (descripción general de alto nivel).