En 2006 el matemático e investigador en materia ciberseguridad, Riccardo Pucella expresó “La seguridad generalmente se expresa en términos de probabilidad”. Razón no le faltó, pero al tratar los peligros y protecciones de muchos artefactos tecnológicos de nuestra modernidad digital, ese no es el discurso que a diario se difunde por numerosos medios.
Así por ejemplo, dentro del trágico conflicto Israel contra Irán, hace días que esta última nación pidió a su ciudadanía dejar de usar una conocida y muy extendida aplicación de mensajería instantánea. Una que conforma una Red Social mundial al alcance de millones de teléfonos inteligentes, propiedad del conglomerado corporativo Meta®. Argumentó, sin evidencia, que el gobierno antagonista podía espiar las comunicaciones y foros de los usuarios que usan esa aplicación. Enseguida y a través de una declaración para la Associated Press, la plataforma de comunicación en Internet negó el señalamiento y declaró que “esos falsos reportes serán una excusa para que nuestros servicios sean bloqueados en el momento en que la gente más los necesita”.
Dirimir si la sospecha persa tiene justificación puede no resultar fácil para muchos. Y es que gran cantidad de usuarios se preguntan cómo es posible que usando un mecanismo de cifrado de datos, que opera de un extremo de la comunicación al otro y que el fabricante ha incorporado en su aplicación, se les pueda espiar y hasta seguirles el rastro. Luego, ante los discursos absolutos de inseguridad total o blindaje perfecto, la gente puede sentirse desconcertada. La respuesta correcta puede expresarse en términos probabilísticos, pero la sola presencia del término matemático puede producir mayor confusión y hasta cierto rechazo. Así que uno tiene que recurrir a experiencias previas para ilustrar la potencial fragilidad; ese es el caso del escándalo de 2019 con el software para espionaje israelí Pegasus, que vulneró parte de la plataforma de mensajería arriba citada y facilitó a algunos gobiernos, invadir ilegalmente las comunicaciones de periodistas, disidentes políticos, activistas sociales y abogados por los derechos humanos.
Más recientemente, a comienzos de este mismo año, otro incidente con varios usuarios de la misma plataforma de mensajería, también resultaron perjudicados en su privacidad. Eso tuvo su origen con otro software de una empresa privada israelí, Paragon Solutions®. En esa ocasión se inoculó un tipo de “spyware”, con técnicas de “phishing” selectivo e ingeniería social. Adicionalmente, podemos referir las pasadas advertencias de seguridad por causas del software, conformadas por numerosos registros hasta el año 2025. Datos acumulados que constituyen parte del contenido de la base de datos de exposición y vulnerabilidades comunes (CVE) del Mitre®. A pesar de eso, suponemos que habrá quien insista en la desconfianza de nuestro respaldo argumental y por ello seguidamente nos centraremos en la firmeza de los protocolos de cifrado punto a punto. El conocido protocolo de capa de “sockets seguros/capa de transporte segura (SSL/TLS)” puede servirnos para como modelo y es que es ampliamente empleado, para proveer resguardo a la confidencialidad e integridad de distintas aplicaciones webs.
Para operar con normalidad SSL/TLS debe en su inicio negociar entre sus partes los parámetros de su posterior funcionalidad. Esa fase conocida como “handshake”, le permite establecer la versión, el tipo de algoritmo de cifrado, el certificado y otros elementos de extensión, que seguidamente serán usados en la otra etapa. Este primer momento, por su propia naturaleza, constituye una ventana de exposición, ya que el enlazamiento y la conectividad es insegura, así como que también es altamente dependiente de otros sistemas, como por ejemplo con el de nombres de dominio (DNS). Cualquier ataque del tipo hombre en el medio (MITM), potencialmente, puede vulnerar el resto de SSL/TLS.
Obviamente existen alternativas como “Secure DNS” para auxiliar la debilidad descrita, pero casi, a modo recurrente, este otro protocolo también tiene sus propias y potenciales flaquezas. Aún así, la verificación del cliente SSL/TLS para el certificado X.509, que recibe al principio e incorpora la clave pública y viene con firma certificada del servidor, así como la formulación de la clave secreta temporal, que exige ser suficientemente aleatoria y se vincula con la sesión del cifrado, al igual que el modo de comprensión y otros aspectos de la política de seguridad activada, son procedimientos que exigen una ejecución correcta y precisa. Si alguna de las partes ha sido previamente comprometida, nada de lo que viene después será seguro. ¿Cómo comprobar esa condición de pureza? Nuevamente aparece el concepto de probabilidad como base firme de la suposición, pero si usted desea tener una idea intuitiva de la magnitud del problema, basta con que piense en los problemas de virus y “malware” que tan comunes resultan en nuestros días y lo complejo que resulta mantener limpio y confiable cualquier dispositivo electrónico digital.
Retomando a SSL/TLS, podemos recordar que desde décadas atrás, existen numerosos ataques conocidos que se enfocan en trampear cualquiera de sus procedimientos e instrumentaciones, sea por explotación de las relaciones de confianza, por fallas de implementación del código o debido a una pobre configuración, establecida inicialmente cuando se instaló el software. Así por ejemplo, el hecho de que durante la negociación, para ajustar funcionalmente la comunicación, resulta una norma que el sistema más sólido deba bajar al nivel del más débil, esto constituye un riesgo notable cuando los sistemas a atender no disponen de las últimas características técnicas disponibles. Ese escenario se repite continuamente y a veces la actualización depende hasta del hardware que se tiene. Para otros escenarios de miedo, debemos recordar los ataques de renegociación forzada, con la consecuente regresión de parámetros a versiones flacas del protocolo.
De cualquier forma, con el tiempo cada ataque conocido a obtenido una respuesta técnica en versiones más recientes del protocolo, pero esto además de hacerlo más complejo, lo que es malo para la codificación del programa y en consecuencia para su seguridad, también puede potenciar otras amenazas. Ese es el caso de SSLv3.0 y la clave maestra para instrumentar un código de autenticación del mensaje (MAC) de negociación. Esto puede lucir como correr la arruga, ya que para negociar una clave secreta, que requiere ser dinámica y no predecible, se debe apelar a una clave fija y débil, ante posibles ataques de repetición. Es decir, esto es una trampa estilo yo te cubro pero dependo de tu solidez sosteniéndome. Por otro lado, han surgido otros tipos de ataques más sofisticados, que van desde la explotación de la aleatoriedad del formato de cierto estándar de criptografía de clave pública (PKCS#), hasta ataques colaterales del cifrado que se aprovechan de una pobre temporización; uno con nombre código “Suertudo13” es uno de los más representativos de este tipo. A estas dificultades hay que añadir la clásicas fallas de torpes implementaciones, algunas con procedimientos de factorización que hacen mal uso de los almacenamientos temporales y otras con un almacenamiento indebido de objetos confidenciales (nombre código: corazón sangrante). La existencia de claves de encriptamiento del tipo exportación, que fueron pensadas para clientes de baja necesidad de protección y los usuarios que las usaban desconocían esa característica, también resultó una falla histórica de este protocolo de seguridad.
Otros problemas reconocidos son un mal manejo del encadenamiento de bloques cifrados (CBC) con vectores de inicialización predecibles (nombre código: Bestia), también un mal manejo de los protocolos de comprobación de la continuidad operativa, tipo “Are you alive?” y hasta del truncamiento del tráfico TCP subyacente, con banderas de “FIN” en los paquetes de redes. Incluso se han descrito embrollos de un secuestro de la sesión aún no cerrada, por un servidor que no está al tanto de la desconexión en el otro extremo del cliente con el que previamente está interactuando. Los peligros de clase de Guión de Sitios Cruzados (XSS) que soportan el robo de las galletas, que vuelven al tráfico HTTP sin estado, en mensajes con historia y que contienen la clave secreta, son otro desastre que puso de rodillas a los ingenieros de software de algunos reconocidos navegadores comerciales. Podemos agregar a esta lista de fallas, los ataques colaterales que revelan la clave de sesión y están basados en un inapropiado manejo de la tasa de compresión de requerimientos HTTP (nombre código: Crimen).
Frente a esta avalancha de dificultades y conste que estamos dejando por afuera a otras, debemos alertar que algunas variantes más recientes de lo que hemos mencionado, todavía carecen de soluciones viables y firmes. Es por eso que resulta ingenuo asumir que con la simple presencia de un cifrado de datos, se obtiene seguridad y privacidad completa. Aclaramos que tampoco queremos sembrar conclusiones erróneas, como aquella de que es igual encriptar que no hacer nada, ni tampoco la de sostener que cualquier cifrado es igual de resistente. Eso no es cierto y puede que resulte más racional presumir que ciertos adversarios, en especial los poderosos y muy motivados, pueden tener posibilidades reales de escucharnos furtivamente y hasta de seguirnos.
Si esta postura no le satisface, recuerde una sentencia del matemático Karl Pearson: “La estadística es la gramática de la ciencia” y haga su propio esfuerzo con la materia estocástica, para así descubrir quién realmente le dice la verdad.
Autor: Miguel Torrealba Sánchez.
Departamento de Computación y Tecnología de la Información de la Universidad Simón Bolívar. mtorrealba@usb.ve
