David Guerrero

Introducción

Cada día se hacen más necesarios mecanismos que nos proporcionen la seguridad en nuestras comunicaciones de la que adolecen los protocolos actuales. Esta necesidad se hace aún más acuciante en el caso de comunicaciones que se realicen a través de redes públicas de datos, como puede ser Internet, en las que es imposible controlar quién puede interceptar la información que se transmite. Es importante comprender los conceptos en los que se basan estos mecanismos de seguridad para poder utilizarlos a pleno rendimiento.

El Ministerio de Educación y Cultura se encuentra en fase de implantación de un sistema de gestión de transacciones vía WEB, que utiliza tecnología de cifrado a nivel de transporte, usando un esquema de claves públicas firmadas y certificadas por una entidad denominada autoridad de certificación.

En el presente artículo se intentarán revisar los conceptos en los que se apoya dicha tecnología y analizar las soluciones software utilizadas para su implantación.

Análisis del problema

El problema de la seguridad en las comunicaciones no es nuevo. Desde el principio de las redes ya se planteó el problema de la seguridad de la información que se transportaba. Muchos de estos problemas son inherentes al diseño físico de los sistemas de red y otros al diseño de los sistemas operativos sobre los que se sustentan las aplicaciones finales.

Dentro de una organización, las posibles soluciones al problema de la seguridad son abundantes y si no eliminan el problema, si lo minimizan de forma bastante razonable. Entre estas soluciones se encuentran los esquemas de autenticación a través de usuarios y contraseñas, sistemas de protección frente al exterior tipo "firewall" o cortafuegos, la posibilidad de imponer una política de seguridad definida entre los miembros de la organización, etc. La realidad es que todas estas herramientas no eliminan las debilidades de los protocolos y las aplicaciones, pero permiten enfocar el problema hacia un ámbito local, mucho más controlado y definido.

Por el contrario, cuando el escenario de nuestras comunicaciones es Internet, la situación cambia radicalmente. No hay posibilidad de imponer una política de seguridad determinada, y literalmente "cualquiera" puede interceptar las comunicaciones. Controles y restricciones como los accesos autenticados vía usuario y password, o por direcciones de IP se hacen casi inútiles, al poder interceptar un tercero las contraseñas o falsear su dirección de IP.

Se hace necesario un mecanismo para garantizar esta seguridad en las comunicaciones. La respuesta viene de la mano del cifrado o criptografía.

Comunicación segura

Antes de seguir avanzando en el enfoque de la criptografía, se hace necesario definir qué le pedimos a un sistema de cifrado entre dos entidades para considerarlo seguro. Básicamente, se le requieren cuatro características o funcionalidades:

  • Confidencialidad: el contenido de la comunicación ha de ser inútil para una tercera parte que lo pudiera interceptar.

  • Autenticación: el sistema ha de asegurarnos que una tercera parte no pueda usurpar la identidad de alguna de las dos partes que intervienen en la comunicación.

  • Integridad: nos debe garantizar que la información transmitida, además de no ser interceptada, no pueda ser modificada por una tercera parte.

  • No repudio: debe garantizar que ninguno de los participantes en una comunicación pueda negar parte de la misma. Es un concepto bastante ligado al de autenticación, y así será considerado.
A continuación analizaremos las dos alternativas que nos ofrece la criptografía convencional al problema del cifrado en las comunicaciones: la criptografía simétrica y la criptografía asimétrica o de clave pública.

Criptografía simétrica

Es el sistema de cifrado más antiguo y consiste en que tanto el emisor como el receptor encriptan y desencriptan la información con un único secreto que ambos comparten. El funcionamiento es muy sencillo, el emisor cifra el mensaje con el secreto y se lo envía al receptor. Este último, que conoce el secreto, lo utiliza para desencriptar la información.

Este sistema de cifrado tiene la ventaja de que es altamente eficiente, dado que los algoritmos utilizados son muy rápidos. Es importante considerar que para que el sistema sea razonablemente robusto contra ataques de tipo criptoanálisis, el secreto ha de ser mayor de 40 bits. Esto choca con las restricciones de exportación de tecnología criptográfica del gobierno americano, que marca los 40 bits como límite de clave para programas que utilicen este tipo de tecnología.

El mayor inconveniente la criptografía simétrica es que el secreto, al ser compartido, ha de ser comunicado de forma segura entre las dos partes de la comunicación (por teléfono, correo certificado, etc.), previamente a ésta. Si este secreto fuese enviado por un canal inseguro, como por ejemplo Internet, el valor del sistema sería bastante pobre, dado que cualquiera podría interceptarlo y comprometer todo el sistema.

Algoritmos típicos que utilizan cifrado simétrico son IDEA, RC5, etc.

Criptografía asimétrica o de clave pública

Más recientemente, se desarrolló un sistema criptográfico basado en propiedades matemáticas de los números primos, que permite que cada interlocutor tenga una pareja de claves propias. De esta pareja de claves, una se denomina privada o secreta y la otra, pública. La clave privada no se transmite nunca y se mantiene secreta. La clave pública, por el contrario, se puede y se debe poner a disposición de cualquiera, dado que es imposible deducir la clave privada a partir de la pública.

La propiedad fundamental de esta pareja de claves es que lo que se cifra con una de estas claves, se descifra con la otra. Esta potente característica asimétrica es la que permite a esta tecnología servir de base el diseño de sistemas de comunicación segura.

Para entender el funcionamiento de este sistema, nada mejor que un ejemplo gráfico como el de la fig. 1. En él se puede ver que cada interlocutor posee una pareja de claves, de las cuales, las públicas de ambos son conocidas por todos. El emisor cifra el mensaje con la clave pública del destinatario, y posteriormente se lo envía. El receptor al recibir el mensaje, lo desencripta con su clave privada, la única que puede desencriptar dicho mensaje, y que en ningún momento ha sido transmitida de ninguna forma.

Ejemplo de criptografía asimétrica (figura 1)

Con este sistema de cifrado de la transmisión logramos el primer requisito que le exigíamos al sistema: confidencialidad. Cualquier intruso que intercepte la transmisión no podrá descifrar el contenido de la misma al no poseer la clave privada del receptor. Para que este sistema sea lo suficientemente robusto contra ataques de criptoanálisis, las claves han de ser de una longitud mínima de 1024 bits, siendo recomendable, en los casos que sea posible, utilizar claves de 2048 bits. De nuevo nos encontramos con el límite de 512 bits impuestos por la legislación americana para la exportación de software criptográfico.

Algoritmos muy utilizados que utilizan cifrado asimétrico pueden ser RSA o Diffie-Hellman. Estos algoritmos tienen la desventaja de que no son tan eficientes a nivel de velocidad como pueden ser los basados en criptografía simétrica.

Una funcionalidad que se basa en este tipo de cifrado es la posibilidad de incluir una firma digital en los mensajes, que nos proporcione las funcionalidades de autenticación, integridad, y no repudio.

Firma digital

La firma digital es un sistema que nos va a garantizar que el mensaje no ha sido alterado en su transmisión (integridad), y además, que sólo el emisor es realmente quien dice ser (autenticación), y que el mensaje necesariamente ha sido enviado por el emisor y no por otro (no repudio).

La firma digital se basa en el cifrado, con la clave privada del emisor, de un resumen del mensaje, que acompañará a dicho mensaje, ya se transmita éste, cifrado o en claro.

El emisor genera un resumen del mensaje a través de una función HASH segura conocida. A continuación cifra ese resumen con su clave privada (por lo tanto solo será posible descifrarlo con su clave pública), y envía tanto el mensaje como el resumen cifrado al receptor. El receptor a la llegada del mensaje, utilizando la función HASH conocida, generará, a su vez, otro resumen a partir del mensaje. Por otra parte, descifrara el resumen enviado, con la ayuda de la clave pública del emisor. Simplemente, se trata ya de comparar ambos resúmenes, y si coinciden, se puede asegurar que el contenido no ha sido alterado en ningún momento de la transmisión (integridad), y que además el emisor solo puede ser el poseedor de la clave privada que correspondiese a la clave publica con la que se descifro el resumen (autenticación y no repudio).

Esto, que en principio puede parecer un poco confuso, se ve más claramente con el ejemplo gráfico de las fig. 2 y 3. En la fig. 2 se puede ver como el emisor genera un resumen, lo cifra con su clave privada y lo anexa al mensaje original. Por otra parte, el receptor, en la fig. 3, recibe el mensaje y la firma, genera un resumen a través del mensaje, y además descifra con la clave pública del emisor la firma, compara ambos resúmenes y si son idénticos, la verificación de identidad e integridad es positiva.

Firma digital (figura 2) Firma digital (figura 3)

Evidentemente, para que la firma sea fiable se ha de utilizar una función HASH segura para generar los resúmenes, que cumpla los siguientes requisitos:

  • Una determinada entrada genera siempre la misma salida.

  • Un cambio mínimo en la entrada genera una salida completamente distinta e imprevisible.
  • No se puede deducir la entrada de la salida.

  • Dada una entrada no es computacionalmente viable encontrar otra que produzca la misma salida.
Como función HASH segura se suele utilizar el algoritmo MD5.

Problemas de la criptografía asimétrica

El problema fundamental al que se enfrenta la criptografía asimétrica es al de la autenticidad de las claves públicas, es decir, ¿quién nos garantiza que la clave pública de un interlocutor, que se obtiene libremente en la red, es realmente de él?. ¿Qué ocurriría si alguien nos envía su clave pública afirmando ser alguien que realmente no es?

Básicamente, nos queda por resolver el problema de la distribución de claves de forma que se garantice que pertenecen a sus legítimos propietarios. Es aquí donde entra en juego el concepto de Autoridad de Certificación o CA, una tercera parte de confianza reconocida, que firma digitalmente las claves e identidades de usuarios y sistemas.

Aplicaciones reales

A la hora de implantar esta tecnología dentro de una organización, se hace necesaria una evaluación de las distintas soluciones software que existen en el mercado y en la red, de estas características.

PGP

PGP (Pretty Good Privacy) [1] es un programa de cifrado de clave pública, desarrollado en USA por Phil Zimmerman, que tiene una fuerte implantación en Internet debido a su robustez y seguridad. A causa de problemas de exportación y de patentes, se mantienen paralelamente dos versiones: la americana y la internacional, desarrollada fuera de USA, que hace que su uso sea legal en el resto del planeta.

Aunque empiezan a surgir versiones de este software en forma de librería incorporables a programas externos, la versión más utilizada, funciona a nivel de línea de comando, cifrando y firmando digitalmente ficheros de disco. Esta dificultad de integración con terceras aplicaciones y la dificultad de uso de su interfaz para un usuario medio, así como la limitación de su uso a nivel de aplicación, hacen que no sea muy recomendado para un sistema de transacciones interactivas vía WEB.

El problema de la certificación de claves lo resuelve a través del concepto de "web of trust", o "tela de araña de confianza", por la cual usuarios particulares firman claves públicas de otros usuarios, y la calidad de una clave pública depende de cuanta y qué gente avala dicha clave.

Secure Sockets Layer (SSL)

SSL [2] es un sistema de cifrado a nivel de transporte aplicable a cualquier transmisión de tipo TCP desarrollado por Netscape, de forma completamente abierta, que ha logrado en muy poco tiempo convertirse en el estándar de facto de este tipo de aplicaciones. Se incluye soporte para SSL en la gran mayoría de los navegadores y servidores WEB del mercado. Se puede comprobar la interacción del subsistema SSL dentro de la pila de protocolos y aplicaciones en la fig. 4.

Aunque donde más se viene utilizando este sistema es en los llamados servidores WEB seguros, no es exclusivo del servicio WEB, y de hecho, ya comienzan a surgir servicios de NEWS, E-MAIL, TELNET y FTP basados en cifrado SSL.

Secure Sockets Layer (figura 4)

Además de cifrado de la conexión, a nivel de socket, permite la autenticación del servidor, en su versión 2.0, y a partir de la versión 3.0, autenticación de clientes. La autenticación de servidor implica la garantía para el usuario final de que cuando se conecta a un servidor, este servidor es realmente quién dice ser. Esta característica abre el servicio WEB a aplicaciones de comercio electrónico, en los que la preocupación de los usuarios de a quién envían sus datos queda resuelta. Con la autenticación de clientes (certificados de clientes) se logra que también el servidor WEB tenga constancia con absoluta seguridad de la identidad del sujeto que se esta conectando.

Para el cifrado de la transmisión, utiliza un enfoque híbrido, en el que se usa un sistema de clave pública para el intercambio de un secreto simétrico generado aleatoriamente. Por lo tanto, al comienzo de la comunicación se intercambia un secreto, que a partir de ese momento será el utilizado para cifrar los datos transmitidos con un algoritmo de encriptado simétrico. SSL también emplea el mecanismo de la firma digital para la autenticación de ambos interlocutores.

Certificados X.509

SSL utiliza certificados X.509 para el intercambio de claves públicas. Estos certificados X.509 contienen además de la clave pública del interlocutor, información acerca de su identidad, así como información complementaria sobre algoritmos utilizados para la generación de claves, plazos de validez del propio certificado, etc. Por otra parte, estos certificados contienen una firma digital que garantiza la integridad de sus contenidos, ya sea por la clave privada del mismo interlocutor (certificados autofirmados), o por la clave privada de una tercera parte (certificado firmado por una CA). Son los de este último tipo, los firmados por una CA, los necesarios para garantizar los cuatro requerimientos iniciales.

Los datos de un sujeto que se incluyen en un certificado X.509 son:

  • CN: Nombre común o nombre largo

  • E-MAIL: Dirección de correo electrónico

  • O: Nombre de su organización

  • OU: Departamento

  • L: Localidad

  • SP: Provincia o estado.

  • C: País

El proceso de generación de un certificado es sencillo. Inicialmente, el navegador ha de generar una pareja de claves, a través del tag HTML <KEYGEN>, y rellenar en una pagina WEB todos sus datos.

Posteriormente y utilizando su conexión de red envía tanto su clave pública como los datos de identidad que rellenó a una Autoridad de Certificación. Es lo que se denomina petición de certificado o CSR. La CA firmará esta petición con su clave privada, y le devolverá en algún momento al peticionario el resultado en forma de certificado X.509, que a partir de ese momento lo podrá utilizar en cualquier transacción de naturaleza SSL. Los datos del certificado X.509 que se presenta al servidor WEB son pasados a la aplicación para que, en base a ellos, realice los procesos de control de accesos y accounting correspondientes.

La generación de un certificado para un servidor web seguro es bastante similar, con la única diferencia de que su CN o nombre común será el nombre FQDN con el que se le conoce en la red.

Autoridad de certificación

Como ya se ha comentado, es necesaria la existencia de una tercera parte, en la que ambos interlocutores confíen, y de la que además posean su clave pública. Ha de ser una entidad administrativa con capacidad para verificar la identidad de los sujetos que soliciten certificados firmados y devuelva los mismos a sus peticionarios, ya sean certificados de servidor o de clientes (navegadores).

Otra funcionalidad que debe poseer una CA es la de mantener listas de certificados revocados o CRLs. En esta listas se publicará la lista de certificados cuya clave privada haya sido comprometida o cuyo poseedor haya demostrado hacer un mal uso del mismo.

La autoridad de certificación ha de poseer una pareja de claves, de las cuales, la privada o secreta ha de mantenerse fuera del alcance de cualquier posible intruso, y es la que se utilizara para firmar los CSRs.

Por otra parte, la clave pública de la CA se almacenará en forma de certificado X.509 y se mantendrá a accesible a todo el mundo, para que puedan verificar la validez de las firmas de la CA.

Este certificado de la CA ha de ser instalado previamente en los navegadores que pretendan confiar en dicha CA. Normalmente, los navegadores ya vienen con una serie de certificados de CAs preinstalados, pertenecientes a CAs comerciales, tipo Verisign [3], que han llegado a un acuerdo con el fabricante del navegador, pero esta lista de CAs confiadas es fácilmente modificable, y un nuevo certificado puede ser instalado de forma transparente, conectándose a una página WEB que lo contenga.

Es muy importante que una CA haga pública su política de certificación. Hay que definir cuál es su ámbito, es decir, a quién se va a certificar, y sobre todo, con que calidad se va a certificar, es decir, qué requisitos se van a emplear para la verificación de identidades. Esta información es muy importante para terceras organizaciones que en un momento dado decidan establecer acuerdos de confianza en los certificados emitidos por nuestra CA.

Un paso más allá van las estructuras de certificación jerárquicas, en las que unas CAs pueden firmar a otras CAs y así, establecer criterios de confianza con cadenas de certificados. Este es un punto en que se esta trabajando actualmente dentro de la comunidad de RedIRIS [4], y se espera que en poco tiempo surjan resultados.

Solución software

Para la implementación dl sistema de transacciones seguras a través de WEB, hemos utilizado distintos componentes que están accesibles en la red.

Para la CA se ha utilizado el software de dominio público SSLeay [5], de Eric Young, que contiene código para la verificación y firma de solicitudes de certificados.

Para los servidores seguros, se ha utilizado Stronghold de UKWEB [6], que consiste en una versión modificada de Apache, el popular servidor HTTP de libre distribución, al que se le han aplicado los parches para soporte SSL de Ben Laurie, y que contiene una serie adicional de utilidades. Este producto, Stronghold, se distribuye gratuitamente para su uso en aplicaciones no comerciales.

Es posible definir en la configuración del servidor Stronghold que requiera certificado de cliente para acceder al servidor, o simplemente use el certificado del servidor para la verificación de su identidad.

Este requerimiento se realiza a nivel de servidor virtual, de forma que en una misma máquina pueden convivir dos servidores: uno que requiera certificados de clientes, para procesos que precisen de la identificación del usuario final, y que no los requiera, para procesos donde solo interese garantizar la identidad del servidor, y no la de los usuarios finales.

Conclusión

La implantación de las tecnologías de cifrado de clave pública es inminente, gracias al protocolo SSL. La transparencia para el usuario final es su punto fuerte ante otro tipo de aplicaciones, tipo PGP, restringidas a usuarios más técnicos. Es importante comprender el papel que juegan las Autoridades de Certificación en todo el esquema de las comunicaciones seguras y su mantenimiento y operación ha de ser riguroso.

La utilización de certificados X.509 abre la puerta a aplicaciones de correo electrónico seguro, a través del protocolo S/MIME. En el futuro, deberán evolucionar los sistemas de distribución de certificados a través de aproximaciones nuevas o basadas en standards de servicios de directorio tipo X.500.

Referencias

  1. PGP. http://www.pgpi.com

  2. SSL. http://home.netscape.com/newsref/ref/netscape-security.html

  3. Verisign. http://www.verisign.com

  4. Grupo de trabajo IRIS-PCA. http://www.rediris.es/cert/pca

  5. SSLeay. http://www.psy.uq.edu.au:8080/~ftp/Crypto

  6. Stronghold. http://stronghold.ukweb.com

David Guerrero
Ministerio de Educación y Cultura
Subdirección Gral. de
Tratamiento de información
Area de Comunicaciones y Sistemas
dirección de correo david [at] mec [dot] es

Las transparencias de esta ponencia pueden consultarse en:
http://www.mec.es/~david/papers/certificacion/slides