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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
Los datos de un sujeto que se incluyen en un certificado X.509 son:
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.
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.
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.
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.
Las transparencias de esta ponencia pueden consultarse en:
http://www.mec.es/~david/papers/certificacion/slides