• U conecta con B mediante una dirección de tipo https://www.banco.es

• El navegador de U solicita al servidor de B una conexión segura.

• B envía un certificado electrónico acompañado de su clave pública RSA o DH

• El navegador de U comprobará el certificado de B con la clave de la autoridad de certificación (AC) adecuada. Dicha clave está integrada en el propio navegador, y corresponde a una AC conocida y de confianza (VeriSign, RSA Secure Server AC, AT&T, Thawte, etc).

• U genera una clave de cifrado simétrico generada aleatoriamente (utilizando algoritmos como el RC4), la cifra con la clave pública del servidor de B, y la envía a B.

• B descifra el mensaje con su clave privada RSA, y obtiene la clave de cifrado simétrico.

• A partir de este momento, la clave simétrica está en posesión de B y U, quienes la utilizan para sus transacciones.

• Una vez se termina la conexión segura, la clave simétrica deja de tener validez. Una conexión posterior requerirá la repetición de todo el proceso anterior con una nueva clave simétrica.

Los usuarios de PGP pueden aquí encontrar una pauta parecida. Un algoritmo de clave simétrica es ideal por su eficacia y brevedad de clave, pero ¿cómo hacer llegar a las dos partes la clave sin que oídos indiscretos fisguen por el camino? Se requiere una comunicación segura para compartir la clave, pero hace falta una clave compartida para establecer comunicación segura. Esta pescadilla que se muerde la cola se resuelve mediante algoritmos asimétricos: el protocolo RSA (o DH) permite enviar de manera segura la clave de cifrado RC4 (o similar).

La seguridad de la comunicación depende de la de sus partes componentes, principalmente cuatro:

1.- El sistema de clave simétrica para la comunicación en sí
2.- El sistema de clave pública para el intercambio inicial
3.- La implementación en el navegador (SSL)
4.- La aceptación de la autoridad de certificación.

La seguridad de un sistema es igual a la de su eslabón más débil. El eslabón número cuatro (la aceptación o no de un certificado) es, más que otra cosa, un "acto de fe." Se supone que una AC goza de prestigio e implantación en el mercado, de manera que se pueda fiar uno de ella (como se puede uno fiar, en principio, de un notario). No puedo ni quiero calibrar este punto con precisión, pero ACs como RSA Secure Server o VeriSign tienen gran implantación hoy día (el expediente de RSA en temas de seguridad habia por sí solo). En cualquier caso, cada certificado de una AC tiene un conjunto de códigos (llamados "huellas digitales") que identifican tanto a la propia AC como al servidor al que certifican. Consultas on-line a dichas AC (via http, por ejemplo) pueden confirmar o desmentir que una huella digital concreta corresponde al banco B y no ha sido falseada. ¿Por qué es necesaria una AC? ¿No puede el banco enviar su clave pública sin más? Poder, puede. Pero el usuario solamente recibe una clave pública de alguien que pretende ser el banco B. Puede ser una página web falsa, con la apariencia de la real, pero que realmente no es controlada por dicho banco. Una certificación de una AC es una garantía de que quien establece la comunicación es efectivamente el banco B y no un aprovechado.

Vamos con el eslabón número tres: ¿es segura la implementación SSL usada por los navegadores? Existen hoy día dos variantes: SSL 2.0 y SSL 3.0. La primera está dejando de ser usada por dos motivos: el limitado tamaño de sus claves simétricas ( de eso hablaremos más adelante) y ciertas debilidades en su seguridad. SSL 2.0 podía sufrir ataques del tipo "hombre-en-el-medio" (man-in-the-middle), que podrían forzar a un cliente a usar cifrado de 40 bits, independientemente del cifrado exigido al navegador. También tenía una limitación en el tamaño de la función resumen (hash) utilizada para la autentificación del mensaje: 40 bits frente a los 128 de la 3.0. La versión SSL 3.0, además de estar reforzada contra este y otros problemas, permite (en las últimas versiones de los navegadores) el uso de claves de mayor longitud y, por tanto, más seguras. Al menos por ahora, parece que SSL 3.0 es adecuado para aplicaciones de seguridad.

En 1994, un mensaje cifrado mediante SSL 3.0 fue difundido por la Red como desafío a la comunidad internauta. Este mensaje fue descifrado en aproximadamente ocho días. Un segundo desafío duró 32 horas (puede encontrar todos los detalles, incluyendo la furiosa respuesta de Netscape Communications aquí). Cierto es que dichos desafíos se pudieron llevar a buen puerto gracias a la corta longitud de la clave simétrica (vea más adelante): 40 bits. Por ello, no pueden tomarse como debilidad de la implementación SSL 3.0 en sí.

¿Qué hay del eslabón número dos? Esto concierne al esquema de claves públicas (o asimétricas). SSL 3.0 utiliza los protocolos RSA (Rivest-Shamir-Adleman) y DH (Diffie-Hellman), considerados como de alta seguridad si la clave es lo bastante larga. Las versiones autorizadas para la exportación desde EEUU emplean claves RSA o DH de hasta 512 bits para el cifrado. También permite firmas digitales con claves RSA de más de 512 bits (con "revoltillos" o hash SHA y MD5) y con algoritmos DSS (revoltillo SHA). ¿Es eso suficiente? Los usuarios de PGP han optado, en su mayoría, por utilizar claves RSA o DH de al menos 1.024 bits. Claves de 512 bits entran dentro de las posibilidades computacionales de entidades con grandes recursos (agencias de inteligencia, empresas, universidades, incluso particulares con acceso a grandes ordenadores), pero está muy lejos de ser una tarea trivial. A efectos de ataques mediante métodos de fuerza bruta, una clave asimétrica RSA de 512 bits es aproximadamente tan fuerte como una clave simétrica de 64 bits. Este tope podría ser fácilmente elevado si se permite la exportación de sistemas SSL con claves asimétricas de más de 512 bits (Netscape, uno de los mayores fabricantes de navegadores de Internet, ya ha obtenido permisos para tal exportación).

Finalmente, vamos con el eslabón número uno. Todo lo anterior resulta inútil si el sistema no dispone de un sistema de clave simétrica segura. Dicha seguridad se basa tanto en la fortaleza del protocolo en sí como en el tamaño de la clave. Para poner un ejemplo, una caja fuerte con mil millones de combinaciones no sirve para nada si se puede abrir de una patada; y al contrario, una caja a prueba de bombas sirve de poco si tiene solamente diez combinaciones posibles.

Las implementaciones SSL versiones 2.0 y 3.0 exportadas hasta hace poco usan los algoritmos RC2 y RC4, con clave de 40 bits (SSL 3.0 emplea, además, algoritmos "hash" MD5 para autentificación de mensajes). RC2 es un algoritmo que, debido a un fallo de concepto, resulta especialmente vulnerabla a un ataque de fuerza bruta (donde se prueban todas las posibles combinaciones de claves) si el tamaño de la clave lo permite. Bruce Schneier, de Counterpane Systems, ha creado un programa para romper claves RC2 de 40 bits, y que funciona como ...!un salvapantallas! (puedes leer su análisis sobre la debilidad de RC2-40, e incluso conseguir una copia del salvapantallas aquí). RC4 es algo más duro de roer, pero también cae con relativa facilidad ante ataques de fuerza bruta. Un mensaje cifrado con un algoritmo similar, RC5-40, con clave de 40 bits, fue descifrado mediante fuerza bruta en 3.5 horas

La escasa longitud de dichas claves hace que las comunicaciones mediante el sistema SSL sean en la práctica sólo medianamente seguras (vea los datos dados anteriormente, en el eslabón tres). A pesar de ello, muchos servidores de tipo seguro lo utilizan, quizá en la creencia de que es mejor seguridad menuda que ninguna. Algunos incluso permiten solamente el establecimiento de comunicaciones mediante el más deficiente sistema SSL 2.0. Sin embargo, no hay motivos técnicos para que las claves simétricas de SSL no puedan ser más largas; solamente se trata de problemas legales. De hecho, existe un "parche" llamado Fortify, capaz de dotar a SSL de capacidad en clave simétrica de 128 bits. Una empresa australiana ofrece asimismo implementaciones SSL de 128 bits.

Recientemente, y ante presiones por parte de los fabricantes y usuarios de software, han aparecido versiones nuevas de navegadores, que utilizan claves más seguras, fuera de EEUU. El Netscape Navigator 4 incorpora, dentro de su SSL 3.0, dos tipos nuevos de cifrado simétrico: RC4 con clave de 128 bits y Triple-DES con clave de 168 bits; este último es una variación del venerable DES, y ha resistido todos los ataques criptoanalíticos hasta la fecha (Microsoft Internet Explorer soporta asimismo los sistemas SSL 2.0 y 3.0). Si, de ahora en adelante, los navegadores incorporan asimismo la posibilidad de generar claves RSA o DH de tamaño mayor de 512 bits (tampoco consta este extremo en ningún manual para los navegadores, pero es de suponer que así sea), nos encontraremos con un sistema de comunicaciones en Internet verdaderamente seguro. Esto, por supuesto, supuesto que el proveedor seguro esté establecido de manera correcta, esto es, sin puertas traseras o fallos de instalación.

¿De qué nos sirve eso a los usuarios no-norteamericanos? Hasta el año pasado, para nada. Pero el gobierno norteamericano se ha visto forzado a conceder permisos para exportar navegadores con cifrado de 128 bits. No poco ha influido el hecho de que claves como la famosa DES (de 56 bits) han caído bajo los esfuerzos combinados de miles de ordenadores, poniendo de manifiesto la debilidad de dicho algoritmo ante ataques masivos de fuerza bruta. El 17 de Junio de 1997, el grupo DESCHALL consiguió descifrar una clave DES gracias al trabajo desinteresado de miles de voluntarios de todo el mundo; el 24 de Junio (una semana escasa después), Netscape Communications obtuvo la aprobación del gobierno de EEUU para exportar software Navigator versión 4, con cifrado de 128 bits. También Microsoft obtuvo licencia para exportar su Internet Explorer 4 con cifrado de 128 bits. A partir de ahora, por tanto, no vale excusarse tras las leyes de exportación para no ofrecer la máxima seguridad a los usuarios españoles.

Como de costumbre, habrá de todo. Por un lado, servidores semiseguros que no pasen de cifrados simétricos RC2/RC4 de 40 bits; por otro, servidores que hayan hecho un verdadero esfuerzo en pro de la seguridad y deleiten a sus cibervisitantes con conexiones en clave de 128 o 168 bits. Si la comunidad de Internet se muestra preocupada ante la seguridad en correo electrónico (PGP, claves de gestión corporativas, depósitos obligatorios, redes de confianza, puertas traseras...), no podrá menos que prestar atención a la seguridad de los navegadores cuandoquiera que se pongan en juego datos confidenciales. Sólo el tiempo, y la mirada crítica e implacable de los usuarios, conseguirá separar el oro del oropel.