Seguridad

Correo electrónico seguro mediante certificados digitales

Matt Clapham and Blake Hutchinson

De un vistazo:

• Creación de una identidad comprobable
• Actualización del estado de certificados
• Obtención e intercambio de certificados
• Solución de problemas en su sistema S/MIME

Durante milenios, los humanos han usado varios métodos para ocultar información en tránsito, validar remitentes y autenticar mensajes. Al evolucionar la civilización, se desarrolló un método para realizar las tres tareas cuyo uso está cada vez más extendido. Extensiones seguras multipropósito al correo

de Internet (S/MIME) es un sistema para enviar correos electrónicos de forma segura mediante el cifrado y las firmas digitales.

Las tecnologías de cifrado actuales (de ocultación) se dividen en dos tipos principales: algoritmos de claves simétricos (secreto), como el Estándar de cifrado de datos (DES) y el Estándar de cifrado avanzado (AES), y algoritmos de claves asimétricos (público/privado), como RSA y la criptografía de curva elíptica (ECC). Las herramientas modernas de validación del remitente son funciones matemáticas unidireccionales, denominadas hash, que crean firmas únicas. Dos de los métodos de hash usados comúnmente son Message Digest 5 (MD5) y algoritmo hash seguro (SHA). Los equipos pueden usarlos para generar un hash único o un número que corresponda con el texto de origen individual (hash idéntico de los textos de origen para el mismo valor). Estas sencillas herramientas se usan y combinan para crear un sistema de infraestructura de claves públicas (PKI).

Una identidad comprobable

Recursos de la entidad de certificación

• Uso de una entidad de certificación para el servicio de cifrado de archivos
• No se puede cambiar el nombre ni quitar de la red los servidores de la entidad de certificación
• Cómo quitar una entidad de certificación de confianza de los equipos en el dominio
• Cómo retirar del servicio a una entidad de certificación empresarial de Windows y cómo quitar todos los objetos relacionados de Windows Server 2003 y Windows 2000 Server
• Cómo mover una entidad de certificación a un servidor nuevo que se ejecuta en un controlador de dominios

Las identidades de un sistema PKI se administran mediante certificados digitales similares a la identificación del gobierno que la mayoría de personas usa para cruzar las fronteras internacionales: el pasaporte. El pasaporte estándar del mundo de la certificación digital es el formato X.509 y se suele usar tanto para la firma como para el cifrado en tecnologías como S/MIME, el protocolo de seguridad de Internet (IPsec), shell seguro (SSH), seguridad de red inalámbrica, redes privadas virtuales (VPN) e incluso las comunicaciones seguras del servidor (como sitios web SSL).

Los certificados están creados a partir del cifrado y de los hash asimétricos. Para crear un certificado, el solicitante (entidad que desea una clave firmada por una autoridad más importante) genera una clave privada. La clave se mantiene guardada en un lugar seguro para que no se pueda cuestionar su autenticidad. Junto con la clave privada, también se genera la clave pública correspondiente. Tal como su nombre indica, la parte pública no es secreta y se distribuye libremente, aunque de manera que se garantiza su autenticidad.

Este par de claves permite dos operaciones fundamentales. En primer lugar, cualquiera puede usar la clave pública para cifrar los elementos que sólo puede descifrar la clave privada. En segundo lugar, la clave pública se puede usar para descifrar los elementos cifrados con la clave privada. Esto es importante para la comprobación de una firma que tan sólo podría crear una clave privada.

La solicitud a la entidad de certificación incluye detalles como la identidad de la persona o el equipo para los cuales está pensada la clave, el tipo de algoritmo y la seguridad, y la parte pública del par de claves. La entidad de certificación (CA) recibe y valida la información de la solicitud y, mediante un algoritmo de hash, crea un identificador único correspondiente a la información.

Mediante la clave privada, la CA cifra el hash de información, lo reúne en un formato estándar (como X.509) y crea el certificado correspondiente a la solicitud original. El certificado X.509 contendrá una lista de solicitudes incluidas la identidad del certificado (el asunto), un margen de tiempo de validez, la clave pública y las operaciones para las que se puede usar el certificado. A continuación, el certificado se devuelve al solicitante. En efecto, se trata de un token que indica: "Yo, la CA, doy fe de esta clave pública y la parte privada correspondiente, para todos los usos descritos en este documento".

En el caso de las CA raíz (las que se encuentran en el nivel más alto de la cadena de confianza), los certificados son autofirmados. La mayoría de las CA raíz aceptables están preinstaladas en el sistema operativo básico o aplicación base, pero se pueden actualizar y alterar a través de la configuración de paquetes o empresas. Entre la CA raíz y un nodo hoja (que suele describir un particular o sistema), puede haber varias CA intermedias.

La cadena consiste en todos los nodos y certificados anteriores incrustados en ellos, firmados por la CA en ese nivel. Un tercero que trate de validar el certificado puede comprobar el hash calculado de forma local y compararlo con el que se ha descifrado a partir del certificado mediante la clave pública correspondiente para esa CA o particular. Es decir, una cadena de confianza completamente validada desde la hoja a la raíz (siempre que la raíz sea confiable).

Actualización del estado de la certificación

Cada CA satisfactoria dispone de un medio para distribuir una lista de certificados en los que no se debe confiar. Esta lista de revocación de certificados (CRL) describe los elementos publicados que la CA ha anulado de forma específica. Afortunadamente, la ubicación de la CRL suele ser propiedad del certificado de CA.

Las CA publican las CRL de forma rutinaria en dos bases: una programación (alrededor de cada dos semanas) o un evento (los casos en los que un certificado publicado no es de confianza). Una CA firmará las CRL emitidas durante su publicación. Cuando un sistema de recepción evalúa la validez de una cadena, suele intentar obtener la CRL para las CA emisoras de la cadena (a través de los detalles incrustados en los certificados o de algún mecanismo de distribución predefinido de confianza). Si no hay disponible ninguna CRL, el cliente puede recurrir a una copia en caché reciente y correcta siempre que no sea más antigua que el período de actualización especificado en la CRL. Sin embargo, si no se cumplen estos requisitos, los sistemas cliente mostrarán algún tipo de error en el que se indique que el certificado parece válido pero el estado de revocación no se puede determinar.

Muchas aplicaciones tardan más en cargar un certificado si no pueden validar la cadena o la CRL para todos los nodos de la cadena. En función de la protección del certificado, el usuario puede confiar en él o no. Es imprescindible que las dispongan de un punto de distribución de CRL actualizado de forma rutinaria, especialmente para sus raíces públicas.

Las raíces son la base de la cadena de certificados y el encadenamiento es la base de las jerarquías de todos los certificados. La mayoría de los sistemas o aplicaciones del cliente sólo presumen que un certificado de nodo hoja es válido si está encadenado a una raíz de confianza. Puede tratarse de una CA de empresa, perteneciente y usada por una empresa concreta, o bien, podría ser una CA de raíz pública (como VeriSign).

Mediante las CA de raíz pública, se puede obtener una experiencia operativa significativa que permita asegurar la integridad. Las empresas deben procurar el mismo nivel para sus operaciones internas, como la importancia que tiene la inquebrantabilidad de una CA de raíz en ese contexto. Para una protección óptima, las CA de raíz se deben mantener sin conexión y usarlas únicamente para publicar certificados y actualizar CRL. Para obtener más información acerca de las prácticas recomendadas operativas de las CA, consulte los artículos incluidos en la barra lateral "Recursos de la entidad de certificación".

Un aspecto importante que hay que tener en cuenta es la recuperación de claves. Para facilitar las investigaciones y asegurarse de que ningún usuario bloquee los datos de forma irreversible, la empresa debe hacer copias de seguridad de todas las claves publicadas por el usuario. Además, estas copias de seguridad se deben almacenar en un repositorio seguro. De esta forma, si desaparece la clave de un usuario, por ejemplo, al olvidar una tarjeta inteligente en un taxi, se puede obtener acceso al contenido protegido mediante la clave.

Por último, dentro de todos los sistemas cifrados de calidad se encuentra el concepto de administración del ciclo de vida. A medida que los equipos son más rápidos, los algoritmos son más deficientes. Los sistemas de cifrado de calidad deben tener la capacidad de renovarse y desplazarse a nuevos algoritmos y tamaños de clave con el tiempo. Las CA se deben actualizar de forma apropiada al encontrar deficiencias en el cifrado y al introducir o retirar determinadas funciones.

Implementación de S/MIME

Existen varias fases de secuencia de arranque, redacción, envío y recepción de correo electrónico firmado o cifrado que usa S/MIME. Trataremos los detalles, los problemas y las posibles soluciones a medida que progresamos en una situación típica de S/MIME: dos usuarios que se envían correos electrónicos firmados o cifrados desde dos bosques de Active Directory® diferentes y desde cadenas de entidad de certificación distintas (es decir, desde entidades independientes de forma operativa, aunque estén en la misma compañía) mediante Microsoft® Office Outlook® 2007.

Suponemos que existe la infraestructura necesaria para permitir las operaciones que describimos. En nuestro caso, usamos un servidor de certificados empresariales integrado en Active Directory.

Obtención de certificados

La primera tarea es obtener los certificados apropiados. Para ello, abra el administrador de certificados en MMC (certmgr.msc), haga clic con el botón secundario del mouse en la carpeta Personal, seleccione All Tasks en la lista emergente y, a continuación, seleccione Request New de la lista.

Esto inicia el asistente de inscripción de certificados, tal como se muestra en la figura 1. De forma predeterminada, aparecerán varias opciones centradas en la empresa, pero el certificado User es el importante. Se usará para habilitar los procesos de firma y cifrado más adelante. El certificado se podrá usar para:

Figura 1** Solicitar un certificado **(Hacer clic en la imagen para ampliarla)

• Firmas digitales (creación de un mensaje con sello de autenticidad de su creador)
• Cifrado de claves (protección de una clave con otra para tecnologías como el sistema de cifrado de archivos)
• Correo seguro (mensajes cifrados que sólo puede leer el destinatario al que van dirigidos que disponen de la clave privada correspondiente)

Para enviar S/MIME firmado por correo electrónico, no es necesaria la propiedad de cifrado de claves. Sin embargo, para enviar o recibir correo cifrado, se necesita esta propiedad y no la propiedad de firma. De forma predeterminada, las plantillas de los servicios de servidor certificados de Windows® habilitan estas tres propiedades. Si el usuario no puede solicitar certificados nuevos, no aparecerá ninguno al iniciar el asistente. Si no hay disponible ninguna CA empresarial, el usuario podrá ver un "Error de inscripción" en el que se indicará que no se pudo poner en contacto con el dominio o la CA. En este tutorial, consideraremos un solo certificado que permita tanto la firma como el cifrado.

Intercambio de certificados

La manera más sencilla de que dos usuarios se empiecen a enviar correos electrónicos cifrados es sencillamente enviarse mensajes firmados. Después de redactar un mensaje, el usuario debe hacer clic en el botón Firmar. (Puede que el botón esté oculto en Outlook de forma predeterminada hasta que se usa al menos una vez. Para encontrarlo, haga clic en la configuración Opciones para mensajes nuevos, haga clic en el botón "Configuración de seguridad...", a continuación, active el cuadro "Agregar una firma digital a este mensaje" en el cuadro de diálogo Propiedades de Seguridad.) El botón de firma (un sobrecito amarillo con una cinta roja en el que aparece Firmar) agrega una firma digital al mensaje para establecer la autenticidad de su origen.

Al seleccionar el botón Enviar, al usuario se le puede solicitar que proporcione tokens adicionales de posesión de claves, como insertar una tarjeta inteligente o especificar un PIN. Esto depende de los métodos particulares de protección de claves de la organización.

El usuario que recibe el mensaje firmado de S/MIME debe hacer clic con el botón secundario del mouse en el nombre del remitente (después de De:), y seleccionar "Agregar a contactos de Outlook" del menú contextual, que agrega una nueva entrada de contacto o actualiza una existente. Entonces, el certificado se asocia con esta entrada de contacto. Tenga en cuenta que en un entorno común de Active Directory (dos usuarios en el mismo bosque o compañía), la distribución pública de certificados para usuarios se realiza de forma automática a través de atributos del objeto Active Directory del usuario.

Otra forma de intercambiar certificados es que cada usuario envíe sus certificados de S/MIME como datos adjuntos. Para ello, ambas partes deberán exportar sus certificados a un archivo CER. Los usuarios deben ver el certificado y seguir el proceso de exportación que trataremos en breve, con cuidado de no exportar la clave privada con él, tal y como se muestra en la figura 2.

Figura 2** Al intercambiar los certificados, no exporte la clave privada **(Hacer clic en la imagen para ampliarla)

A continuación, cada receptor crea una entrada de contacto en Outlook y agrega el certificado a la entrada del remitente de forma manual. Una vez que los dos usuarios han intercambiado los certificados, podrán intercambiar correos electrónicos cifrados.

Solución de problemas

A veces, el receptor tiene dificultades para abrir el mensaje cifrado. Los tres orígenes de problemas que solemos detectar en esta área son: las CA raíz no son de confianza, no se pueden validar las CA intermedias y las CRL no están disponibles.

Una CA raíz que no sea de confianza suele aparecer en Outlook como un mensaje de error asociado con la firma: "Existen problemas con la firma. Haga clic en el botón de la firma para obtener más detalles". Para resolver el problema, abra el certificado desde Outlook y haga clic en el botón "Ver entidad emisora de certificados" del diálogo emergente. Consulte el mensaje en la ficha General del cuadro de diálogo de propiedades del certificado. Si indica que el certificado de raíz de CA no es de confianza y es necesario instalarlo, vaya a la ficha Detalles. Haga clic en el botón "Copiar en archivo..." y siga los pasos del asistente, acepte todos los valores predeterminados y proporcione un nombre de archivo y una carpeta cuando se le solicite.

Ahora abra una nueva consola de Microsoft Management Console (MMC) como administrador del equipo. Vaya a Archivo|Agregar o quitar complemento (Ctrl+M), seleccione Certificados y agréguelo a la cuenta del equipo (cuando se le solicite, debe elegir el equipo Local). A continuación, amplíe el nodo Certificados del árbol izquierdo y haga lo mismo con las entidades emisoras raíz de confianza. Haga clic con el botón secundario del mouse y seleccione Todas las tareas|Importar del menú emergente. Importe el archivo de certificado exportado que se menciona anteriormente a las entidades emisoras raíz de confianza y haga clic en Finalizar. Entonces, el usuario afectado debe reiniciar Outlook.

Estas instrucciones sólo se deben seguir para agregar una CA raíz de confianza. No todas raíces se crean de la misma manera. Considere detenidamente quién posee y usa la CA raíz antes de usar este método para agregar una raíz al almacén del sistema. Si su empresa controla la lista de raíces de confianza a través de la directiva de grupo, la configuración se insertará en los sistemas cliente. En ese caso, puede que no funcionen las instrucciones. De ser así, puede que necesite considerar alternativas como sitios web o servidores protegidos para intercambiar datos, ya que el correo electrónico no será una experiencia perfecta y protegida.

El segundo problema mencionado anteriormente (que las CA intermedias no se pueden validar) se suele producir en dos situaciones: un cliente que intenta validar el certificado no puede obtener acceso a la ubicación de Acceso a la información de entidad emisora (AIA) que aparece definida en el certificado, o el cliente tiene una versión del certificado de la CA intermedia que no coincide lo que la que emite la CA (el cliente suele tener una o dos versiones anteriores). Estas situaciones parecen muy similares en la interfaz de usuario de Outlook. Sólo lo hemos advertido en una circunstancia muy específica: cuando expira una CA de nivel medio de la cadena y se vuelve a emitir antes de que expiren otros certificados subordinados emitidos.

Básicamente, este problema ocurre cuando la cadena tiene huecos. Puede que algunos certificados primarios no estén bien detallados o no estén incrustados en el nodo hoja correctamente, lo que complicaría la situación aún más.

Para resolver este problema, el remitente deberá abrir un mensaje nuevo y hacer clic en Opciones del mensaje nuevo, a continuación, en el botón de configuración Seguridad, y después en el botón de configuración Cambiar. Haga clic en el botón Elegir del certificado de firma y, a continuación, en el botón Ver certificado del cuadro de diálogo emergente. Vaya a la ficha Ruta de certificado, seleccione el emisor del nodo hoja (es decir, suba un nivel de la cadena) y haga clic en el botón Ver certificado. Haga clic en la ficha Detalles, a continuación, en el botón Copiar en archivo..., complete el asistente de exportación y seleccione PKCS #7 (.P7B). Asegúrese de que está activada la opción "Incluir todos los certificados en la ruta de certificación", tal como se muestra en la figura 3. Por último, envíe el archivo exportado de la cadena al receptor deseado.

Figura 3** Corrección de huecos de una cadena de certificados **(Hacer clic en la imagen para ampliarla)

Después de obtener la cadena de certificados exportada, el destinatario deberá abrir e importar la cadena de la misma forma que importamos una raíz anteriormente. La diferencia es que la carpeta de almacenamiento elegida debe ser donde se encuentran las entidades de certificación intermedias. Si se abre el mensaje y el certificado se muestra como válido en Outlook, todo funciona correctamente.

En cuanto al tercer problema (las CRL no están disponibles), en comparación, la corrección es bastante sencilla. La respuesta inicial de Outlook será muy parecida a la del problema anterior. Sin embargo, el error aparecerá incluso aunque la raíz o la CA de firma intermedia sean de confianza. En cada nivel de la cadena de certificados por encima de la hoja, abra las propiedades del certificado, a continuación, la ficha de detalles y consulte el campo denominado "Puntos de distribución CRL".

En cada punto de distribución CRL enumerado (especialmente los que tienen acceso a Internet), compruebe que se puede abrir la dirección URL del archivo CRL. Al validar cada nivel, suba un nivel de la cadena. Si no se puede adquirir ninguna CRL, probablemente éste sea el origen del problema. Para resolver el problema, debe comprobar que su directiva de red local no le bloquea el acceso. De lo contrario, intente de ponerse en contacto con la empresa que posee la CA o espere que el punto de distribución CRL de CA vuelva a encontrarse en estado operativo.

Distribución de certificados

La distribución es la parte fácil. Básicamente, el mensaje firmado se transmite a un servidor de correo, que lo envía de una ubicación a otra a través de un método de eficacia probada, el SMTP. El problema con el que nos encontramos al tratar con el correo firmado o cifrado en tránsito es que algunos sistemas de correo rechazan o interrumpen los mensajes firmados o cifrados que pasan por ellos. La corrección sirve para funcionar con el administrador de TI del sistema y obtener los tipos de mensajes permitidos. Por supuesto, deberá trabajar sabiendo que algunos tipos de mensajes están bloqueados. La parte receptora puede tener una buena razón para no permitir los mensajes cifrados en un entorno operativo particular.

Cifrado de respuestas

Para crear una respuesta cifrada (suponiendo que el proceso de secuencia de arranque mencionado anteriormente ya se ha realizado), el remitente sólo debe crear un mensaje y, a continuación, hacer clic en el botón Cifrar (el sobrecito amarillo con el candado azul en el que aparece Cifrar) en la ventana de composición de mensajes. Si el botón Cifrar no está disponible, siga los pasos para enviar un mensaje firmado (menos el último) y, en lugar de eso, marque la casilla "Cifrar el contenido del mensaje y de los datos adjuntos".

Para enviar un mensaje cifrado a un destinatario no es necesaria la firma de S/MIME, pero con toda certeza funcionan bien juntos, debido a que la firma permite que el lector valide el remitente (la función de cifrado no realiza ninguna notificación al remitente). El proceso de cifrado tratará de cifrar el mensaje con las claves públicas conocidas de todos los destinatarios. Si el sistema no puede encontrar certificados para algunos destinatarios a los que van dirigidos, se marcarán en un cuadro de diálogo emergente que permite enviar el mensaje sin cifrar, tal como se muestra en la figura 4.

Figura 4** Puede decidir enviar un mensaje sin cifrar si se encuentra con algún problema relacionado con un certificado **(Hacer clic en la imagen para ampliarla)

De forma predeterminada, la firma y el cifrado deben funcionar con otros sistemas cliente configurados, pero, a veces, los mensajes cifrados o firmados cruzados pueden tener problemas si el algoritmo de cifrado o de hash no es compatible con el nivel inferior. Nos encontramos con un problema al enviar un correo electrónico firmado (mediante SHA-512 como el algoritmo de hash) a un usuario que ejecuta Windows XP SP2. Ya que el sistema receptor no era compatible con el hash, el usuario no pudo validar la firma digital ni leer el mensaje. No obstante, a menos que se hayan cambiado los valores predeterminados de Outlook, no es probable que los usuarios se encuentren con muchos problemas en esta fase.

Tras la recepción del mensaje, el destinatario al que va dirigido debe poder abrirlo, siempre que esté disponible la clave privada asociada con el certificado público. De nuevo, puede que el usuario tenga que proporcionar un token adicional para demostrar la posesión de la clave privada, en función de cómo se haya implementado. Otros usuarios que hayan completado un proceso de secuencia de arranque similar pueden participar en comunicaciones firmadas y cifradas semejantes con el remitente. Si un usuario cambia la clave privada en algún momento (quizás por la pérdida de un equipo), deberá volver a solicitar certificados y redistribuir un mensaje firmado o un archivo de certificado a los que deseen intercambiar el correo cifrado.

Conclusión

El uso de S/MIME firmado y cifrado entre dos usuarios en dos directorios u organizaciones diferentes no suele ser mucho más complicado que el proceso que acabamos de tratar. La firma es muy útil cuando se usa correctamente, ya que proporciona autenticidad al mensaje. En el caso de la información confidencial, los mensajes cifrados ofrecen un nivel extra de confidencialidad para los datos en tránsito. Al combinarse, permiten autenticar tanto el origen como la confidencialidad de los datos. A través del proceso descrito en este documento, la mayoría de usuarios podrá sacar partido de estas capacidades sin ningún problema.

Matt Clapham, CISSP, es ingeniero en seguridad de Microsoft IT. Realiza revisiones de seguridad en aplicaciones de LOB durante el día y durante la noche se interesa por la tecnología, los juegos, la música por PC y la seguridad. En ocasiones, habla en la comunidad acerca de seguridad Puget Sound IT. Póngase en contacto con él en matt.clapham@microsoft.com.

Blake Hutchinson es analista de soporte técnico del grupo de servicios en línea empresariales (BOSG) de Microsoft. Su función incluye el soporte técnico operacional y la revisión de proyectos de las herramientas LOB creadas internamente para clientes empresariales de BOSG. A Blake le gusta la fotografía, el esquí y los videojuegos. Puede ponerse en contacto con él en blakeh@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.