(Puede comprobarlo p. ej. en el servidor seguro del Banco Santander:).

RC4-40 significa una clave de 40 bits secretos. Esto se debe a que los protocolos de seguridad SSL utilizados por los navegadores (browsers) exportables fuera de EEUU trabajan con clave de no más de 40 bits. Romper la clave RC4-40 para una sesión de cifrado dada requiere 2^40 (aproximadamente un billón) de pruebas con distintos conjuntos de 40 bits. Parece mucho. Pero un ordenador Pentium trabajando a razón de medio millón de combinaciones por segundo tardaría unos quince días en reventar la clave ... así que no hablemos de criminales con recursos, usuarios con ordenadores potentes o, simplemente, personas con malas intenciones y acceso a grandes equipos informáticos.

¿Demasiado rebuscado para que pueda hacerse? Entonces, hablemos de hechos. La clave RC4-40 de 40 bits ya fue violentada tiempo atrás; es decir, se consiguió descifrar un mensaje cifrado con clave RC4-40. Hay que resaltar que, en principio, es necesario montar un ataque para cada sesión de cifrado de datos, esto es, no ha sido reventado el protocolo de cifrado, sino una aplicación concreta. Sin embargo, el desciframiento de un sólo mensaje mediante fuerza bruta significa que, en principio, cualquier mensaje cifrado resulta asimismo vulnerable. Es como si un ladrón hubiera abierto la puerta del vecino tras una hora probando ganzúas: puede que esa ganzúa no abra mi puerta, pero el caso es que ha conseguido entrar en la casa del vecino, así que con una hora más de trabajo, puede entrar en la mía.

De hecho, se han llegado a descifrar mensajes con claves más largas y consideradas antaño seguras, como la DES (56 bits) y las RC5 de 48 y 56 bits. En la actualidad existe un proyecto de grandes proporciones en Internet para reventar la RC5-64. (puede informarse sobre dicho proyecto pulsando aquí).

Respecto al estándar SSL (Secure Socket Layer, o capa de zócalos seguros) empleado por navegadores como el Netscape Navigator o el Microsoft Internet Explorer, aunque resulta más difícil de descifrar, es también vulnerable ante una ataque de "fuerza bruta", donde el atacante revisa todas las posibles claves. Antiguamente se utilizaba el estándar SSL 2.0, que en la actualidad está en desuso (entre otras cosas, por fallas en la seguridad). La versión SSL 3.0, habitual hoy día, es en apariencia mucho más robusta. Sin embargo, el primer mensaje codificado con SSL (clave RC4-40 bits) que fue roto requirió el equivalente de 50 PCs de alto rendimiento durante solamente ocho días; el segundo tardó 32 horas en una red de "hackers". Se trataba de mensajes inocuos, escritos deliberadamente para desafiar a la comunidad informática... pero el esquema sirve para cualquier mensaje enviado mediante SSL.

La situación empeora cuando se habla de fallos en la implementación de dichos protocolos criptográficos. Hace algún tiempo se descubrió que el generador de números aleatorios (imprescindible para crear claves) del Netscape Navigator versión 1.1 no era tan aleatorio, lo que permitía descifrar mensajes en cuestión de segundos. Internet Explorer no tiene una reputación mejor en lo que respecta a fallos de programa. Y mañana pueden encontrarse nuevos fallos en cualquier punto del proceso de creación de claves.

Demasiada vulnerabilidad para un sistema de protección que se vende como "totalmente seguro e indescifrable" por algunos servicios on-line.

Generalmente, los vendedores de "aceite de serpiente" (como se designa en argot a los productos que pretenden la perfección absoluta pero en la práctica se quedan lejos de tal distinción) abordan este espinoso problema de dos maneras. La primera es ocultar los hechos: mi sistema es formidable e inatacable, así que tranquilo y no se preocupe por los detalles técnicos. Por supuesto, también se puede atracar un banco a punta de pistola, y nadie deja de llevar su dinero a los bancos por ello. Pero, mientras que el banco se hace responsable del dinero depositado (de modo que mis ahorros están seguros aunque roben hasta la última peseta en mi sucursal), no lo hará en el caso de un robo por Internet, ya que sus sistemas criptográficos son maravillosos, y por lo tanto la culpa seguro que es del usuario. Más aún, sabemos que los bancos pueden robarse y cualquiera que diga lo contrario se expone a una carcajada, pero al mismo tiempo se nos intenta convencer de que los robos por red sin simplemente imposibles.

Un banco español que, entre otras cosas, emite Certificados electrónicos (usados para confirmar la relación existente entre una clave y el nombre de su propietario, esto es, una especie de notario digital), exhibe la siguiente perla en letras grandes y en negrita: "Cada solicitante reconoce que él mismo, y no (nombre del banco) es responsable absoluto de la protección de su(s) clave(s) privada(s) frente a posibles ataques, pérdida, modificaciones y uso no autorizado." (Culpable hasta que se demuestre lo contrario; me encantaría comentarlo con un abogado). Curiosamente, el mismo banco presume de sus "...sistemas de protección criptográfica, que impiden que los datos transmitidos puedan ser reconocidos por un eventual espía de las comunicaciones", así como de su servicio de comercio electrónico "apoyado en una infraestructura de seguridad que aporta máxima confianza a los participantes." Aceite de serpiente.

La segunda manera de enfrentarse a los problemas de seguridad es reconocer que existen, pero minimizar sus efectos. A fin de cuentas, la cosa no es tan sencilla como parece. He aquí algunos de los razonamientos de los técnicos de estos servidores seguros. En primer lugar, descifrar un sólo mensaje no significa gran cosa, ya que se tendría que movilizar los mismos recursos informáticos para descifrar otro. Es decir, el descifrado se haría caso por caso. No es como tener una llave maestra para todas las puertas, sino ganzúas que no permiten abrir una puerta sino mediante una laboriosa tarea. En segundo lugar, puede que el gasto en equipo informático sea desproporcionado en relación con el valor de la información obtenida (a fin de cuentas, reventar un mensaje cifrado con SSL 3.0 o RC4-40 no se hace en un par de horas de PC). Esto es, no os gastéis cien millones de pesetas en ordenadores para acceder a mi cuenta corriente, porque no vale la pena. Y aunque se pueda obtener la clave de acceso, puede no servir de mucho. Según la Netscape Corporation, la duración de la clave maestra "Master_Key) utilizada en SSL es de tan sólo 100 segundos, y las claves varían de una sesión de comunicaciones a otra.

No son argumentos irrazonables, pero tampoco resultan aplastantes. Puede pensarse en situaciones donde valga la pena el gasto (secretos industriales de alto valor), y la duración limitada de las claves resulta irrelevante si lo que se quiere no es el acceso al sistema, sino a la información en sí; por ejemplo, el código personal (análogo al de las tarjetas de los cajeros automáticos) que, al margen de las protecciones tipo SSL, puede exigir el servidor al usuario. En efecto, no puedo hallar la clave de una sesión dada y utilizarla (no en menos de 100 segundos, al menos), pero puedo obtener mensajes que entren o salgan del servidor, guardarlos y descifrarlos cuando tenga tiempo. Tampoco es fácil interceptar las comunicaciones de un usuario determinado, pero ¿y si no me interesa ese usuario en particular, sino uno cualquiera?

He aquí un posible escenario de ataque, que puede estarse desarrollando ahora mismo. Un grupo del crimen organizado consigue una gran cantidad de potencia de cómputo: PCs, estaciones de trabajo .. quizá incluso algunos superordenadores. Centenares de megaflops (un flop es una operación en coma flotante por segundo), quizá gigaflops. O, si cuentan con verdaderos expertos, pueden construir máquinas con chips especialmente diseñados para el desciframiento de claves. Durante varios meses, se dedican a grabar las comunicaciones que entran a determinado servidor "seguro" del banco X, y a intentar descifrar todas las que puedan (si el sistema funciona bien y las claves no se repiten, solamente un ataque por fuerza bruta será factible). No saben qué contendrá un mensaje concreto, pero de vez en cuando dicho mensaje contiene el código personal de acceso de algún cliente. Así, van elaborando una lista de clientes y códigos de acceso.

Cuando tienen un buen número de códigos, pasan al ataque. En la madrugada de un sábado, se monta un ataque coordinado y simultáneo contra las cuentas corrientes cuyos códigos de acceso conocen, se desvalijan y sus saldos se transfieren a cualquier banco de un paraíso fiscal. Si tienen los conocimientos adecuados, podrán hacerlo en cuestión de minutos y sin dejar rastro. A la mañana siguiente, tal vez algunos de los titulares se aperciban de lo sucedido, pero el robo ya está perpetrado. Por supuesto, el banco declina toda responsabilidad y culpa a los titulares de las cuentas o a un fallo del sistema. Incluso puede admitir la vulnerabilidad de sus sistemas, pero eso ya da igual. ¿Cambiarán su política de banca por Internet, o se arriesgarán a las posibles consecuencias con tal de sacar tajada de tan jugoso sector financiero? No se sabe; lo único cierto es que alguien lee la prensa con una sonrisa de oreja a oreja ... y con los ordenadores listos para el próximo ataque.

Este escenario parece digno de una novela de John le Carré o Tom Clancy (y si la escriben, exigo mi porcentaje), pero es perfectamente factible y está dentro de las posibilidades de la tecnología actual. Así que, si algún día llegáis a aparecer en el periódico, recordad dónde lo leísteis por vez primera. Quizá estoy exagerando. Quizá esta filosofía de desconfianza pueda parecer conservadora en extremo. Pero creo que la seguridad hay que respaldarla con algo más que palabras, y que se hace un mal servicio a un usuario prometiéndole seguridad absoluta que no es tal. Y, si bien protocolos como el RC4-40 y la implementación SSL pueden utilizarse en aplicaciones donde el grado de seguridad necesario es pequeño, en ningún modo puede confiarse en ella para transmitir información sensible.