Algoritmo de Shor y factorización

Adolfo García Yagüe | En mi profesión, que un cliente dedique una hora de su tiempo a escucharte es un privilegio. Si de ese tiempo quieres reservar al menos 15 minutos para escuchar su opinión o contrastar alguna información relevante, la exposición se queda en unos 45 minutos, de los que solo 40 son realmente útiles: pequeños retrasos, introducción de por qué estamos aquí, etc.

Siendo optimista, cuentas con 40 minutos para recorrer 26 diapositivas, lo que significa que dispones de apenas 1 minuto y medio por slide. Es evidente que, en cuanto intentes profundizar en ciertos temas, consumirás el tiempo en explicaciones en las probablemente quedarás atrapado…

Esta introducción me permite hablar de la presentación que compartí hace unas semanas sobre Computación Cuántica y PQC. Aunque está siendo muy bien recibida y, desde que la liberé en mayo, la he presentado ya en una docena de clientes con un feedback satisfactorio, es una presentación de elevado riesgo por su densidad conceptual y las ramificaciones hacia temas que suscitan numerosas preguntas… con el temido riesgo de hacer descarrilar cualquier planificación de tiempos…

Aun así, hasta el momento no se ha producido ninguna catástrofe. Al contrario, cada exposición se ha convertido en un ejercicio de mejora continua que me permite afianzar conceptos que antes tenía algo difusos. Esa evolución me ha llevado incluso a construir en Excel un sencillo modelo del Algoritmo de Shor, que me ha servido para entender con mayor precisión su funcionamiento y explicar sus fundamentos de forma más clara. Os lo dejo para que podáis experimentar con él; además, me apoyaré en este ejemplo para repasar paso a paso cómo funciona el algoritmo.

Cifrado de clave pública RSA
Para este ejercicio he tomado como punto de partida el sistema de cifrado RSA (Rivest, Shamir y Adleman), desarrollado en 1977 y todavía ampliamente utilizado. Recordemos que el elemento público más importante de RSA es el número N, obtenido como el producto de dos números primos, p y q. Si un atacante consiguiera factorizar N y recuperar esos dos números primos, podría reconstruir la clave privada.

Aunque algunos podéis pensar —con razón— que RSA está siendo sustituido poco a poco por algoritmos basados en criptografía de curva elíptica (ECC, Elliptic Curve Cryptography), ambos comparten la misma idea fundamental: su seguridad descansa en problemas matemáticos que un ordenador clásico no puede resolver en un tiempo razonable.

La ventaja de usar RSA como ejemplo está en que parte de su base matemática resulta más intuitiva que la de ECC. Al fin y al cabo, tod@s hemos trabajado con números primos en el colegio y, cuando llega el momento de aplicar Shor, no resulta confuso calcular un máximo común divisor o construir una función periódica. Como veréis, estos conceptos se asimilan fácilmente y permiten percibir la gravedad del problema con mayor claridad.

Antes de seguir y así evitar que alguien se frote las manos pensando que vamos a enseñar a romper RSA con Shor, es importante recordar que nuestro ejercicio toma números muy pequeños de 2 y 3 cifras. Esto, en el mundo actual de la seguridad, es ridículo y cualquier número empleado en RSA es superior a las 600 cifras (2048 bits) llegando incluso a superar las 1200 cifras (4096 bits).

Esto es así porque, para un ordenador convencional, recuperar p y q a partir de un N lo suficientemente grande es computacionalmente inabordable. El método básico de criptoanálisis por fuerza bruta obligaría a buscar divisores de forma secuencial y, aunque se empleen algoritmos como General Number Field Sieve (GNFS), el problema sigue siendo descomunal ya que romper un módulo RSA de 2048 bits continúa siendo una tarea computacionalmente inabordable con la tecnología actual.

Algoritmo de Shor
En 1994, el matemático Peter Shor (1959) demostró que la factorización de números no tenía por qué resolverse mediante una búsqueda exhaustiva. Su algoritmo transformó el citado problema de factorización de N en el de hallar el período de una determinada función. Para ello, el primer paso consiste en construir una función a partir del número N —recordemos, el módulo público del sistema RSA— y estudiar su período.

A primera vista puede parecer una idea extraña. ¿Qué tiene que ver el período de una función con la factorización de un número? Antes de responder a esa pregunta conviene olvidarnos por un momento de los ordenadores cuánticos. De hecho, podemos comprender la idea utilizando únicamente la hoja de cálculo adjunta.

El primer concepto que necesitamos conocer es la aritmética modular, también conocida como “la matemática de los relojes”. En un reloj, cuando pasan doce horas volvemos a empezar desde la una. No importa cuántas vueltas demos; el reloj siempre muestra un número comprendido entre 1 y 12.

La aritmética modular funciona exactamente igual. Si trabajamos, por ejemplo, módulo 12, cualquier resultado que supere ese valor vuelve a empezar desde el principio. Así, 9 + 5 = 14, pero como 14 deja un resto de 2 al dividirlo entre 12, escribimos simplemente:

14 mod 12 = 2

La criptografía RSA utiliza precisamente este tipo de matemáticas. En lugar de trabajar con números cada vez más grandes, realiza continuamente operaciones “módulo N”. Gracias a ello, aunque las cifras intermedias sean gigantescas, el resultado final siempre queda comprendido entre 0 y N − 1.

La función que empleó Shor es sorprendentemente sencilla:

f(x) = aˣ mod N

donde N es el módulo público de RSA y a es un número entero elegido de forma que no comparta factores con N. Para comprobarlo utilizamos una operación muy conocida en matemáticas: el máximo común divisor (MCD), que indica cuál es el mayor número que divide exactamente a otros dos. Si el MCD de a y N es igual a 1, decimos que ambos números son coprimos y podemos continuar. Curiosamente, si el MCD fuese mayor que 1, habríamos encontrado directamente uno de los factores de N, resolviendo el problema incluso antes de empezar. Veamos un ejemplo muy sencillo:

En nuestro ejemplo, supongamos que el módulo público es N = 15 y elegimos a = 2. Como el MCD de 2 y 15 es 1, podemos construir la función y empezar a calcular sus valores (podéis cambiar estos valores en la hoja hasta un máximo de N=101).

En esta tabla lo interesante es el resultado de la segunda columna. Si nos fijamos, en ella observaremos un patrón que se repite 1, 2, 4, 8, 1, 2, 4, 8… La función ha entrado en un bucle. Decimos entonces que su período r es igual 4, porque cada cuatro valores la secuencia vuelve exactamente al mismo punto.

Y aquí aparece la idea brillante de Peter Shor. Ese número, que a primera vista parece un simple dato más, contiene en realidad la información necesaria para recuperar los factores primos de N.

Sin entrar en la demostración matemática, basta saber que, cuando el período es par y se cumplen determinadas condiciones, tomamos el mismo valor de a que elegimos al principio y lo elevamos a la mitad del período (r/2).

En nuestro caso:

r = 4     y    a = 2

Por tanto:

2 ^(4/2) = 4

Nota: En este ejemplo ocurre una curiosidad ya que el período r vale 4 y el cálculo de a^(r/2) también da como resultado 4. Es una simple coincidencia. En general, ambos valores no tienen por qué guardar ninguna relación. Dicho esto, a partir de ese resultado solo tenemos que realizar dos cálculos utilizando el máximo común divisor.

Primero restamos una unidad:

MCD(4 − 1, 15) = 3

Después sumamos una unidad:

MCD(4 + 1, 15) = 5

Y, casi sin darnos cuenta, hemos recuperado los dos factores primos del número:

15 = 3 × 5

Una vez conocido el período, factorizar el número deja de ser un problema complicado. La verdadera dificultad consiste en descubrir ese período cuando N tiene cientos o miles de bits, como ocurre en las claves RSA reales.

Nuestra hoja de cálculo reproduce el método clásico: incrementa el valor de x, calcula aˣ mod N y espera hasta que la secuencia empieza a repetirse. Con números pequeños funciona perfectamente, pero con una clave RSA real esa búsqueda puede resultar prácticamente inabordable.

¿Cómo evita ese problema un ordenador cuántico? La clave está en la Transformada Cuántica de Fourier (Quantum Fourier Transform o QFT). Aunque su nombre resulte complejo, su función es muy sencilla: poner de manifiesto la periodicidad de la función.

Una buena analogía es la música. Cuando escuchamos una orquesta percibimos una única melodía, aunque en realidad está formada por muchos instrumentos. La transformada de Fourier actúa como una herramienta capaz de separar esos sonidos y revelar el patrón que había oculto. En el algoritmo de Shor hace algo parecido: utiliza la superposición cuántica para trabajar con muchos valores de x simultáneamente y, mediante la Transformada Cuántica de Fourier, hace visible el período de la función.

Esa es la auténtica revolución del algoritmo de Shor. El ordenador cuántico no factoriza números por arte de magia ni calcula las potencias modulares mucho más deprisa; simplemente encuentra el período de la función de una forma mucho más eficiente. Una vez conocido ese período, el resto del algoritmo vuelve a ser completamente clásico y permite obtener los factores primos mediante unas sencillas operaciones con el máximo común divisor. Y precisamente por eso ha sido necesario desarrollar una nueva generación de algoritmos PQC (Post-Quantum Cryptography) resistentes a este tipo de ataques.

[Descargar hoja de cálculo]

Computación Cuántica y Criptografía Postcuántica

Adolfo García Yagüe | Cuando hace unos meses hablábamos de radiotelegrafía, algunos lectores repararon en que entre los documentos de la colección hay un estadillo militar de 1912 donde se contabilizaban los mensajes cifrados del año anterior. Aquello, lejos de ser una singularidad, es una pequeña muestra de la relación que ha existido desde la antigüedad entre el cifrado y el mundo militar.

Desde los sacerdotes egipcios, que reservaban la escritura jeroglífica a una élite, hasta los espartanos del siglo V a. C., que empleaban la escítala para enviar órdenes secretas, la necesidad de ocultar información ha sido constante. Durante siglos, la criptografía fue un arte reservado a gobernantes, diplomáticos y militares. Hoy, sin embargo, forma parte de nuestra vida cotidiana, aunque la mayoría no seamos conscientes de ello: cada conexión con un servidor en Internet, cada pago electrónico, cada instalación de una app en el smartphone o, por ejemplo, cualquier procedimiento para certificar nuestra identidad digital dependen de la criptografía.

La complejidad y el oscurantismo que la rodean no son casuales, pues entender sus fundamentos exige conocimientos de matemáticas, informática, estadística y, antaño, lingüística. Aun así, su evolución puede narrarse como una sucesión de cambios de paradigma en los que historia y tecnología se entrelazan con acontecimientos decisivos. En este sentido, conviene recordar que hace un siglo la criptografía clásica quedó obsoleta frente a las máquinas de rotores y las técnicas inspiradas en el cifrado de Vernam. Más tarde, en los años setenta, ambas cedieron el paso al cifrado computacional basado en problemas matemáticos difíciles de resolver.

Hoy vivimos otro momento de transición en el que la computación cuántica amenaza esos problemas «difíciles» que sustentan a Diffie-Hellman, RSA (Rivest–Shamir–Adleman) y ECC (Elliptic Curve Cryptography), ya que un ordenador cuántico capaz de ejecutar el algoritmo de Shor podría factorizar números enteros y resolver logaritmos discretos con una eficiencia imposible para la computación clásica. Incluso los algoritmos simétricos robustos, como AES (Advanced Encryption Standard), o las funciones criptográficas, como SHA (Secure Hash Algorithm), se verán afectados por el algoritmo de Grover, al reducir el esfuerzo de fuerza bruta a su raíz cuadrada y obligar a duplicar los tamaños de clave para mantener el mismo nivel de seguridad. Por estas razones, y aunque aún hoy no existan máquinas cuánticas capaces de hacerlo a gran escala, el riesgo HNDL (Harvest Now, Decrypt Later) ya es real: los datos cifrados hoy podrían ser descifrados mañana.

En este contexto se enmarca esta presentación. Su objetivo es ayudar a los clientes de Axians —y a cualquier interesad@— a comprender la amenaza cuántica, explorando cómo funciona actualmente un ordenador cuántico y a qué desafíos se enfrenta esta tecnología. A continuación, explicaremos en qué se basan los nuevos algoritmos PQC (Post-Quantum Cryptography) estandarizados por el NIST (National Institute of Standards and Technology, EE. UU.) y cómo se integran en un certificado X.509 y en la negociación TLS (Transport Layer Security), IKE (Internet Key Exchange) e IPSec. Más adelante revisaremos las iniciativas impulsadas por diversas instituciones europeas y su impacto en la normativa vigente: DORA (Digital Operational Resilience Act), NIS2 (Network and Information Security Directive 2) y eIDAS (Electronic Identification, Authentication and Trust Services). Por último, presentaremos una estrategia de referencia para abordar la transición hacia PQC y analizaremos cómo algunos fabricantes de soluciones de seguridad están afrontando este reto.

No lo olvidemos: la criptografía es la capa matemática que garantiza la confidencialidad, la integridad y la autenticidad de los datos, además de salvaguardar la identidad y la confianza digital. Y, por primera vez en medio siglo, nos vemos obligados a replantear sus cimientos.

[Descargar presentación]

Origen y evolución del Malware, 1971-1995 (y 3)

Adolfo García Yagüe | Hacia el final de la década de los 80, las únicas herramientas con las que contaban las empresas para defenderse de una infección, era una suscripción a un buen antivirus, la aplicación estricta de políticas que prohibieran el uso de software no corporativo, y la existencia de copias de seguridad actualizadas… por si acaso. No había mucho más dónde elegir.

Malware en Redes Corporativas
El incidente sufrido por IBM con el virus Cascade, nos permite recordar el riesgo al que se enfrentaba cualquier organización con una red de área local (LAN) en la que sus usuarios compartían impresoras, disponían de almacenamiento centralizado o, simplemente, intercambiaban archivos. Como hemos comentado en otros artículos, la mayoría de estas redes LAN se articulaban sobre NetBIOS, que era una extensión del sistema operativo MS-DOS para ofrecer soporte de red. Como sabéis, con el despliegue de estas redes se pretendía que el usuario tuviera acceso a unas unidades de red que podían ser privadas o compartidas entre compañeros. Esto significaba, que si un virus ya se encontraba presente en el equipo del usuario, también tendría acceso a cualquier carpeta y fichero existente en las unidades remotas X:, Y: o Z:, por ejemplo. Es decir, para que una infección se propagase, no era necesario intercambiar un disquete con un colega, pues el virus se podía mover libremente en todo el entramado de la Red LAN.

Por otra parte, hasta la popularización de las mencionadas redes locales, en algunas organizaciones, la forma más habitual de trabajar contra un recurso central era a través del teleproceso ofrecido por un miniordenador y mainframe. Normalmente estos ordenadores funcionaban veinticuatro horas al día en instalaciones acondicionadas, la mayoría inexpugnables, y era en estos sistemas donde residía cualquier base de datos y allí se ejecutaban todas las aplicaciones de negocio o mensajería. Desde un usuario, en el caso de IBM, el acceso a estos sistemas estaba limitado al uso de una aplicación mediante un “terminal tonto” SNA 3270 o 5250 o, desde un PC, a través de la correspondiente emulación de terminal. En resumen, un usuario común no tenía ningún acceso al sistema operativo o los procesos que corrían dentro de la máquina central, por lo que era poco probable que un virus pudiese infectar al sistema. Además, recordemos, que el código de un malware para MS-DOS y el microprocesador Intel 8086 no tendría ningún efecto, por ejemplo, en un sistema MVS de IBM… aunque Bernad Fix, también conocido como Foxi, coqueteó con un virus para sistemas MVS/370 de IBM.

Por último, hay que recordar a los sistemas basados en UNIX y TCP/IP. Con una filosofía distinta a las comentadas anteriormente, este sistema operativo se utilizaba principalmente en el ámbito académico e Internet y, comparativamente, su empleo en el entorno empresarial estaba menos extendido, aunque en sectores como el ingenieril, era bien conocido gracias a su potencia y flexibilidad.

Un sistema corriendo UNIX, al igual que sucede en su descendiente GNU Linux, consta de decenas o cientos de servicios en ejecución y, para delicia de un malware o atacante, es habitual que alguno de estos servicios sea accesible remotamente a través de TCP/IP para, por ejemplo, intercambiar archivos (FTP), acceder vía terminal (Telnet) o enviar un correo electrónico (SMTP)…

Gusano Morris
Un sábado de noviembre de 1988, el programa Informe Semanal abrió uno de sus reportajes alertando “…en la red de comunicaciones auspiciada por el sistema de defensa americano y conectada con el programa más famoso y espectacular del presidente Reagan, conocido como Guerra de las Galaxias, el joven Robert Morris había introducido un virus informático…”. A continuación, en ese mismo espacio de televisión, uno de los españoles que mejor entendía los entresijos de la red afectada, José A. Mañas profesor de la Universidad Politécnica de Madrid (UPM), daba unas pinceladas sobre los virus informáticos y comentaba el suceso…

Tras esta introducción, quedé perplejo por su aparente magnitud y trascendencia. Aunque un año un año antes había leído sobre ARPANET en un artículo firmado por el propio Robert E. Kahn (1938), no fui capaz de dar sentido a lo escuchado y entender de qué se trataba. Lo único que me quedó claro es que en el incidente se vio afectado un futurista programa militar estadounidense del que conocíamos su existencia por los medios.

Meses más tarde supe que muchas instituciones académicas y científicas alrededor del mundo estaban conectando sus redes a través de TCP/IP y que, la mayoría de sus máquinas, eran sistemas UNIX… y que un tal Robert Tappan Morris (1965), a días de cumplir 24 años, había tumbado todo ese tinglado…

También conocí que el agente patógeno no era un virus, sino un gusano al que se había bautizado con el nombre de su autor. Es decir, se trataba de un código maligno con capacidad para propagarse a través de esa red mundial sin necesidad infectar e intercambiar ficheros. Ah, se me olvidaba, nuestro protagonista era hijo de Robert H. Morris, uno de los creadores de Darwin (1961) y, además, en el momento del incidente, papá Morris trabajaba en la NSA (National Security Agency)… alucinante… todo quedaba en casa…

Siguiendo un orden basado en la probabilidad de éxito, el gusano Morris podía emplear cuatro vectores diferentes en su intento de colonizar remotamente un objetivo:

• sendmail, a través del puerto TCP 25. Servicio para envío y recepción de correos. El gusano se aprovechaba del modo de depuración (activo por defecto) para ejecutar comandos arbitrarios sin autentificación. Probabilidad de éxito alta.
• fingerd, TCP 79. Demonio que permitía conocer remotamente el nombre de los usuarios y el estado de su sesión. Morris se aprovechaba de una vulnerabilidad de fingerd en la distribución UNIX Berkeley (BSD) permitiendo la ejecución remota de código. Probabilidad de éxito alta.
• rsh, TCP 514. Este servicio permitía la ejecución remota de comandos, sin contraseña, y estaba basada en autenticaciones de confianza que se configuraban en el archivo .rhost. Morris buscaba aquellos archivos .rhost que carecían de un permiso de acceso restrictivo para conocer las máquinas y usuarios que tenían concedido el acceso. Probabilidad media.
• rexec, TCP 512. Este servicio permitía la ejecución remota de comandos con contraseña. A diferencia de rsh, en rexec si era necesario introducir un nombre de usuario y una contraseña. El gusano Morris sorteaba esta barrera probando, una a una, diferentes contraseñas para cada nombre de usuario con palabras generadas a partir de un diccionario y/o permutaciones de estas. Probabilidad baja.

Trascurridas unas horas tras su liberación, el 2 de noviembre de 1988, el gusano Morris ya había logrado infectar a más de 6000 sistemas y se estimaba que unas 60000 máquinas se encontraban a su alcance… Recordar que en aquel año se contabilizaban en Internet, aproximadamente, 500 redes estadounidenses y no más de 100 redes internacionales (entre las que se encontraba la UPM). Precisamente, y según la declaración de Robert Morris tras su detención, justificó su acción diciendo que aquello era solo un experimento para intentar conocer la población y envergadura de Internet, y que se le fue de las manos…

La realidad es que este gusano, intencionadamente o no, contenía un error en su programación lo que permitió la reinfección de sus víctimas, ocasionando el agotamiento y el colapso de los sistemas afectados. Para atajar la crisis provocada por Morris, la mañana del 3 de noviembre se pusieron al frente expertos de la Universidad de Berkeley, el MIT y la Universidad de Purdue, y juntos lograron desentrañar su funcionamiento y desarrollar los parches necesarios para corregir el incidente.

Esta respuesta reactiva e improvisada, aunque efectiva, puso de manifiesto la necesidad de establecer algún tipo de coordinación y protocolo para gestionar futuras crisis. Por este motivo, tras el suceso, inició su andadura en la Universidad Carnegie Mellon el primer CERT o Computer Emergency Response Team y, entre sus atribuciones, quedaba la dirección de la respuesta ante un incidente de seguridad, además de analizar amenazas y vulnerabilidades.

Otra consecuencia del gusano de Morris fue la incorporación en los sistemas UNIX de capacidades para establecer filtros IP, como los TCP Wrappers (1990) e IPFilter (1992). En esta línea de protección conviene recordar el caso de ciertos routers, como los de Cisco Systems, que incluirían a partir de 1993 la posibilidad de establecer ACL (Access Control Lists). Inmediatamente después, gracias al servicio ipfw de UNIX, se desarrolla el concepto Firewall y aparecen las primeras soluciones específicas de seguridad, como FireWall-1 de Check Point que se apoyaba en estaciones Sun Microsystems y su sistema operativo Solaris.

Junto a estos avances, en algunas organizaciones cuyos servicios eran especialmente sensibles se fue un paso más allá en materia de ciberseguridad. Estas compañías eran conscientes del riesgo que representaba un adversario motivado y, por ello, se esforzaron en levantar barreras para proteger sus datos y cifrar sus comunicaciones. Esta preocupación aumentaba si contaban con una red de sucursales o delegaciones, o si formaban parte de una red bancaria internacional como SWIFT.

Más allá del trastorno y los cambios que provocó, el gusano de Morris puso en evidencia la realidad de los sistemas, dejando importantes lecciones que, en mi opinión, podrían formar parte de unos ficticios (pero todavía vigentes) Diez Mandamientos de la Ciberseguridad:

• No expondrás información que pueda ser aprovechada por un atacante (nombre y tipo de los sistemas empleados, nombre de usuarios, correos…).
• Corregirás cualquier vulnerabilidad de un sistema y/o sus programas.
• Siempre bastionarás un sistema y no dejarás desatendidas configuraciones por defecto.
• No dejarás servicios innecesarios expuestos y sin protección alguna.
• No dejarás ningún fichero de configuración y passwords a la vista de un atacante.
• No utilizarás passwords débiles y las sustituirás periódicamente.
• Establecerás controles para detectar y frenar reintentos al ingresar una contraseña.
• y cifrarás todo, comunicaciones y datos… aunque en 1988 esto no estaba al alcance de la mayoría de los sistemas.
• …

Con estas líneas daría por terminado el repaso al origen y primeros años del fenómeno malware. No obstante, es obvio que la cosa no acabó en 1995 y, en muchos sentidos, lo verdaderamente interesante empezaría a partir de aquel año. Permitirme recordar: Internet llega a los hogares; el correo electrónico se convierte en una popular herramienta de comunicación; las empresas adoptan masivamente redes LAN; aparece Windows 95, con todas sus luces y sombras; el uso de macros embebidas en los documentos ofimáticos; empezamos a usar teléfonos GSM, agendas y ordenadores de bolsillo con conexión a Internet… y los malotes se dan cuenta de que la propiedad de virus y gusanos para replicarse de forma sigilosa no tiene por qué ser un fin, sino que puede ser un medio para desarrollar ataques más sofisticados… Pero esto es otra historia que contaré en futuros textos…

Introducción a la Ciberseguridad | Origen y evolución del Malware, 1971-1995 (1) | Origen y evolución del Malware, 1971-1995 (2)

Origen y evolución del Malware, 1971-1995 (2)

Adolfo García Yagüe | En este texto continuamos con el repaso de los primeros años del fenómeno malware. Como en otras ocasiones, os ruego que seáis indulgentes si detectáis alguna omisión o imprecisión. Gracias.

Virus en ficheros .COM y .EXE
Seguimos en 1987, año en el que llegaron las primeras noticias de Vienna y su capacidad para infectar los conocidos ficheros .COM de MS-DOS. Este formato de archivos, que carecían de cualquier encabezado, era una imagen exacta del programa binario que ejecutaba el microprocesador y, al cargarlo en memoria, siempre se ubicaban en la dirección 0x100h ocupando, como máximo, un segmento de 64KB.

Cuando el virus Vienna se encontraba en la memoria de la víctima, buscaba archivos no infectados con la extensión .COM. Para identificar si un archivo ya había sido infectado, el virus realizaba una comprobación de la hora de creación: si los segundos de la marca de tiempo indicaban un valor de 62 segundos, consideraba que el archivo ya estaba infectado y lo ignoraba. Este timestamp de 62 segundos resultó ser una característica ingeniosa ya que, como todos sabemos, no es un valor válido en un reloj real cuyo máximo es de 59 seg.

En cambio, cuando el malware encontraba un archivo limpio, lo abría y sobrescribía sus primeros bytes con una instrucción de salto JMP. Este salto tenía como fin redirigir la ejecución del programa hacia el código malicioso. Después de ejecutar su propio código, el virus devolvía el control al programa original saltando a la dirección donde se encontraba el código sobrescrito. Finalmente, el virus cerraba el archivo .COM y actualiza su hora de creación estableciendo los segundos a 62 para marcarlo como infectado y evitar futuras reinfecciones.

Se especula que este virus fue originario de la ciudad de Viena, pero su autor siempre ha permanecido en el anonimato y lo único que sabemos es que fue descubierto por el austriaco Franz Swoboda, quien indicó que el virus le llegó a través de Ralf Burger, que afirmaba lo contrario… Lo único claro es que fue Bernad Fix quien programó un antídoto para eliminar Vienna y que el propio Burger aprovechó aquel suceso para publicar el polémico “Computer Viruses a high-tech disease” detallando el funcionamiento de Vienna y convirtiéndolo en un virus de referencia para desarrollar nuevas especies… En mi opinión, no es descabellado especular que tras la creación de Vienna se encontraba alguien del entorno del Chaos Computer Club de Alemania. Recordemos que allí, en 1986, Ralf Burger presentó el virus Virden y Bernad Fix a Rush Hour y que ambos virus fueron descritos, junto a otros especímenes, en el libro de Burger.

Estas líneas estarían incompletas si no recordara al famoso virus Jerusalem. Además de por su elaborada y efectiva técnica para infectar ficheros .COM y .EXE, este malware alcanzó los primeros puestos de popularidad debido a sus efectos -dañinos- que se materializaban cada día Viernes 13. Independientemente de la bomba de tiempo que alojaba, la mayor parte de los daños provocados por este virus eran consecuencia la inutilización de los ficheros .EXE que reinfectaba repetidamente. Con cada infección el tamaño de los ficheros se incrementaba 2KB, siendo lo que llamó la atención de sus descubridores de la Universidad Hebrea de Jerusalén.

A diferencia de Vienna, el virus Viernes 13 o Jerusalem tenía la capacidad de permanecer residente en memoria y monitorizaba constantemente las llamadas que hacía cualquier programa a la interrupción 21h, que era el punto de entrada para que MS-DOS realizara funciones básicas, como abrir o cerrar ficheros. Esto le permitía interferir en el acceso a cualquier fichero sin llamar la atención. En aquel instante, insertaba su código de manera similar a lo comentado antes, con la particularidad de que en los ficheros .EXE el virus tenía, además, que saber moverse en el encabezado de estos archivos para identificar el punto de entrada.

Primera generación de antivirus
A esas alturas los sufridos usuarios nos defendíamos como podíamos y la mayor parte de las ocasiones optábamos por el “fuego purificador” de un buen formateo. Este borrón y cuenta nueva era una práctica habitual hasta que llegaron las primeras copias -piratas, eso si- de programas antivirus.

Hasta el año 1988 no conocí un antivirus “de amplio espectro” con capacidad de detectar varios virus. En cambio, si llegó hasta mí algún programa que servía de vacuna frente a un tipo de virus particular e, incluso, algunos eran capaces de identificar ese malware y extirparlo. Como digo, eran remedios muy específicos y solo eran efectivos frente a un determinado código y cualquier variación, por pequeña que fuera, los hacia inútiles cuando no catastróficos inutilizando totalmente el archivo que se intentaba sanar.

El producto más popular de esta primera generación de antivirus fue ViruScan de McAfee Associates. Tras esta compañía estaba el excéntrico, pero visionario, John David McAfee (1945-2021) cuyo currículo incluía experiencia previa en compañías como la NASA, Univac, Xerox y Lockheed… Precisamente, en 1987 y durante su paso por esta última empresa conoció la existencia de Brain. Como hobby programó un antivirus para, posteriormente, distribuirlo a través de BBS en modalidad shareware. Ante el éxito de ViruScan, John McAfee dejaría su empleo en 1989 para profesionalizar los servicios que se ofrecerían a través de McAfee Associates, como la prestación de soporte telefónico, acceso a actualizaciones del producto a través de Compuserve, un modelo de registro y suscripción, y el desarrollo de un canal de ventas.

En esencia, aquellos antivirus se basaban en la identificación de firmas o una secuencia de códigos que permitían reconocer cada tipo de malware. Para ello, el fabricante de la solución debía dotar al producto de tantas firmas como virus fuera capaz de detectar, lo que exigía una actualización constante. Esta actualización, en la mayoría de los casos, no resultaba ni sencilla ni económica para, por ejemplo, un usuario español. La citada base de datos de firmas constituía el núcleo central del sistema del cual se alimentaban tres motores independientes: uno para el análisis de la memoria RAM; otro para los discos flexibles y el disco duro a bajo nivel; y un tercero para analizar el sistema de ficheros para ser capaz de examinar directorios completos o archivos específicos.

Normalmente, los primeros productos lanzados al mercado no eran capaces de limpiar un fichero colonizado y se limitaban marcarlo como infectado, borrarlo o ponerlo en cuarentena. En este sentido, todos los fabricantes insistían en la necesidad de tener y mantener copias de respaldo actualizadas.

De aquellos años, además del citado McAfee, me viene a la cabeza el sofisticado The Norton Antivirus (1990) de Symantec y su intuitiva interfaz de usuario (recordar, estamos en MS-DOS) junto con la posibilidad de actualizar manualmente las firmas conforme van apareciendo nuevos virus y su capacidad -más o menos eficiente- para extirpar el código malicioso de un fichero infectado. Pero, en mi opinión y dejándome llevar por el orgullo patrio, las dos soluciones antivirus con mayor repercusión en España fueron Anyware (1989) de Carlos Jiménez, y Artemis (1990) de Mikel Urizarbarrena, fundador de Panda Security.

Polimorfismo y virus Cascade
La ciberseguridad, salvando las distancias, es una carrera armamentística y la lucha contra el malware es un buen ejemplo de ello. Como era de suponer, era cuestión de tiempo que los métodos de detección basados en firmas quedaran obsoletos porque a alguien se le ocurriría la forma de alterar el código de un virus con cada copia y así, la apariencia de toda su descendencia, sería distinta e imposible de detectar mediante firmas conocidas.

Esta capacidad, llamada polimorfismo, está en la base de aquellos virus que, empleando alguna técnica de cifrado, consiguen alterar su apariencia para convertirlos en únicos. No es menos importante la ofuscación que consiguen de su código, complicando de esta forma el análisis de su funcionamiento.  Aunque pueda parecer que hay similitudes con el actual malware Ransomware -por aquello del cifrado- no hay que confundirlo. Estamos hablando de técnicas de cifrado muy elementales, de finales de los ´80, cuyo objetivo no era el cifrado masivo de ficheros y directorios, simplemente alterar el propio código para pasar desapercibido.

De nuevo volvemos a Centroeuropa, concretamente a Alemania, y allí encontramos las primeras señales del virus Casacade (1987), también conocido como 1701 y 1704 por el tamaño que añadía a los ficheros infectados, y otros tantos nombres con los que se identificó a sus mutaciones. Haciendo uso de una comparación biológica, podemos afirmar que el virus Cascade fue un salto evolutivo al incorporar un sencillo mecanismo que le permitía ser polimórfico. Afortunadamente, este virus no fue infalible frente a la mayoría de antivirus de primera generación, pues su algoritmo de cifrado podía ser identificado mediante firma, pero el resto del código del virus se encriptaba y éste era diferente en cada copia. Sin duda, aquello fue un comienzo y señaló el camino por donde evolucionaría el malware y las herramientas de detección.

Cascade infectaba ficheros .COM y aunque inicialmente estaba programado para atacar solo a equipos clónicos PC y excluir a máquinas IBM, su rutina para identificar al fabricante de dicho PC mediante el copyright de la BIOS no consideró las posibles variantes que hacía IBM en cada versión, por lo que afectó a casi a cualquier PC. Paradójicamente, sería la propia IBM de Bélgica uno de los mayores damnificados de esta plaga, teniendo que desarrollar un antídoto para frenar sus “simpáticos” efectos tras comprobar como a sus empleados se les caían -literalmente- los caracteres de sus monitores.

Como he comentado, en el código de Cascade existía una rutina de encriptación basada en la operación lógica XOR, fácilmente implementable a nivel ensamblador. En los primeros especímenes de 1701, la clave para el cifrado y posterior descifrado se correspondía con la longitud original del archivo infectado. Recordar que este mecanismo encriptación solo se aplicaba al payload del malware para ocultar su código frente miradas indiscretas y la descrita identificación a partir de firmas.

Este cambio de tendencia en el desarrollo de malware, unido a un incremento exponencial de virus y variantes, hizo insostenible seguir basando únicamente las capacidades de detección en una base de datos de firmas conocidas. Pensemos en la dificultad para mantener actualizado ese gigantesco repositorio de firmas y lo más complicado, desarrollar un motor lo suficientemente rápido para analizar decenas o cientos de ficheros contra esta base de datos de firmas.

Vacunación y primeros antivirus heurísticos
Bajo las técnicas de vacunación los antivirus fueron incorporando capacidades para identificar cambios inesperados en un fichero, como aquella basada en guardar el checksum o suma de verificación de cada archivo en una base de datos, para, si un malware alteraba ese fichero poder detectarlo, aunque no se conociese la identidad del artefacto responsable del cambio. Otra capacidad de detección muy básica consistía en conocer la fecha de creación original y la longitud del fichero víctima y, una vez más, ante un cambio no esperado se generaba una alerta.

Un paso más allá en la detección de agentes malignos desconocidos, y aproximándonos más al término heurístico, consistía en analizar -en tiempo real- el comportamiento de un posible malware e identificar ciertas acciones sospechosas, como las llamadas a la interrupción 13h para hacer accesos al sistema de almacenamiento a través de la BIOS. Recordar que por heurístico entendemos una forma de encontrar una solución de una manera rápida y, a veces, no del todo perfecta y óptima.

Como digo, estas técnicas, aunque efectivas, no eran perfectas y podían generar falsos positivos porque, por ejemplo, el funcionamiento de algunas aplicaciones precisaba hacer cambios en sus respectivos archivos e, incluso, algunos sistemas anticopia hacían un uso legítimo de la interrupción 13h, como aquella consistente en la detección de una marca láser en la superficie del disco. También, para sacar el máximo partido a estos mecanismos de vacunación, era necesario trabajar con ordenadores que tuvieran disco duro y que fuesen rápidos porque, de lo contrario, era inviable en un sistema con solo diskettes. [Continuará]

Introducción a la Ciberseguridad | Origen y evolución del Malware, 1971-1995 (1) | Origen y evolución del Malware, 1971-1995 (y 3)

Origen y evolución del Malware, 1971-1995 (1)

Adolfo García Yagüe | Tras el interés surgido con la presentación anterior, no he podido evitar recuperar algunos documentos para recordar como los Virus informáticos o más genéricamente, el Malware, se hicieron un hueco en nuestros corazones.

Origen teórico
Al hablar del origen de los virus informáticos, es común citar el artículo Self-Reproducing Machines de L. S. Penrose (1898-1972), publicado en junio de 1959 por Scientific American. En contra de lo que cabría esperar, en este trabajo no se tratan temas relacionados con ordenadores, lenguajes de programación o sistemas operativos, ahí son estudiadas las capacidades que debería tener una máquina para fabricar copias de sí misma que, como sabemos, es la característica esencial de cualquier virus. Como no podía ser de otra forma, el mencionado artículo de Penrose sigue la estela de los trabajos que previamente publicó John von Neumann (1903-1957) entre los años 1948 y 1952, abordando el tema de las máquinas autorreplicantes y el concepto de un autómata capaz de crear copias de sí mismo. El objetivo de Neumann no era otro que comprender los principios lógicos que subyacen en la replicación biológica.

Sin abandonar esta línea teórica, en ocasiones también se recuerda al Juego de la Vida de John Horton Conway (1937-2020), de 1970. Aquel no era un juego al uso y podría ser considerado un pseudo-autómata cuya programación, a través de reglas básicas (= algoritmos), emulaba el comportamiento de una célula y su ciclo vital de nacimiento, reproducción y muerte. Visualmente, la conducta de aquella célula era representada a través de los movimientos de una ficha dentro de una cuadrícula, siendo posible resumir este comportamiento mediante un  programa informático, como el desarrollado por Guy y Bourne en un Digital PDP-7. Una vez más, podemos trazar paralelismos entre un virus informático y una forma de vida artificial programada para evolucionar en su entorno y perpetuarse.

He querido recoger estas referencias porque es importante conocerlas, al ser consideradas como base teórica, pero, en mi opinión, para entender el fenómeno malware es necesario un enfoque más cercano al contexto de su creador, en concreto, su motivación y medios. Francamente, a veces tengo dudas que alguno de los primeros creadores de virus y gusanos encontraran la inspiración entre los eruditos trabajos de Newmann, Penrose o Conway.

Creeper y Reaper
Como digo, para entender el desarrollo de cualquier acontecimiento es preciso conocer el entorno circundante. Por eso es importante recordar que Creeper, el que es considerado primer gusano de la historia, fue programado en 1971 por Bob Thomas mientras trabajaba en BBN Technologies (Bolt, Beranek and Newman), la compañía responsable del desarrolló ARPANET. Aquel joven andaba metido en la compartición de recursos entre ordenadores Digital PDP-10 con sistema operativo TENEX y desarrolló un programa que saltaba entre equipos. Este programa saltarín, en su demostración, imprimía el mensaje “I’M THE CREEPER: CATCH ME IF YOU CAN” y, a continuación, pasaba a la máquina siguiente y se borraba en la anterior sin dejar rastro. Es decir, entre los ordenadores objeto del ensayo, en un determinado instante solo era perceptible una copia de Creeper. Sin lugar a dudas, Creeper incluía el atributo básico de cualquier gusano, que es la réplica remota sin necesidad de infectar ficheros, sin embargo, aquello solo fue un ensayo divertido y benévolo dentro de BBN que, no lo olvidemos, estaba tras del desarrollo del citado TENEX, nuevos protocolos de encaminamiento de paquetes y otras formas de comunicación, entre las que destaca el correo electrónico, inventado allí por Ray Tomlinson (1941-2016).

Precisamente, la información más fiable que ha llegado hasta nuestros días sobre Creeper ha sido a través de Tomlinson, quién modificó el Creeper original para que se perpetuase de forma indefinida y simultánea en múltiples máquinas sin desaparecer, eso sí, seguimos en el aquel laboratorio de BBN. Para asegurarse de que esta experiencia podía ser detenida y revertida sin riesgos, Tomlinson desarrolló un programa llamado Reaper que se encargaba de buscar y borrar a Creeper.

Virus informático: el nacimiento de una nueva especie
Hacia finales de 1983 Frederick B. Cohen (1956), entonces estudiante de la Escuela de Ingeniería de la Universidad del Sudeste de California, creó un programa experimental capaz de infectar y replicarse en otras máquinas. Este programa se camuflaba dentro del código de un software legítimo y se propagaba a través de un disquete.

Fue su profesor, Len Adleman (1945) -coinventor de la criptografía RSA-, quien sugirió el nombre de «Virus» para este tipo de software. Las experiencias y conclusiones de Cohen fueron recogidas en su artículo de 1984 “Computer Viruses – Theory and Experiments”. Aquel trabajo fue pionero al establecer definiciones que hoy consideramos evidentes, como, por ejemplo, la que se refiere a un “virus” como un tipo de programa capaz de infectar a otros programas, modificándolos para incluir una copia de sí mismo. En este sentido, Cohen insiste en distinguir los virus de otros programas de propagación, como los gusanos y, enfatiza, que la característica clave de un virus es su habilidad para infectar a otros programas.

Core War
De forma paralela a la publicación del trabajo de Cohen, Alexander Keewatin Dewdney (1941-2024), mientras ejercía como profesor en la Universidad de Western Ontario, empezó a escribir en 1984 en Scientic American bajo la sección Computer Recreations. En España la revista Investigación y Ciencia también publicaría sus trabajos dentro del apartado Juegos de Ordenador. En su primer artículo, publicado el mes de mayo, A. K. Dewdney hizo una descripción de Core War, un juego de ordenador que desarrolló junto a D. G. Jones. En aquel juego dos programas competían entre si -de manera autónoma- para hacerse con el control de la memoria de un ordenador. En estos enfrentamientos cibernéticos podía competir cualquier interesado mientras programara a su “campeón” en Redcode, que no era otra cosa que un conjunto reducido de instrucciones similares al ensamblador.

En el primer texto dedicado a Core War, A. K. Dewdney cuenta que encontró la inspiración tras conocer la anécdota de Creeper y Reaper, no obstante, es curioso comprobar que los datos que llegaron hasta él no parecen ser correctos y hace referencia a estos programas como «refritos» de otros dos programas, uno de ellos anterior, Darwin, desarrollado en 1961 por Malcolm Douglas McIlroy (1932), Victor Vyssotsky (1931-2012) y, quedaros con este nombre, Robert H. Morris (1932-2011) mientras trabajaban en Bell Labs. El otro programa al que hace referencia es Worm, un gusano programado por John F. Shoch en Xerox PARC en 1980 (¿casi 10 años después de Creeper?) mientras investigaba en las posibilidades de la computación distribuida a través de Ethernet.

Tras dar a conocer en Scientic American el funcionamiento de Core War, A. K. Dewdney no contaba con que su artículo daría visibilidad a un buen número de sucesos e iniciativas relacionadas con el malware… Por eso, en su segundo texto publicado solo unos meses después (en mayo de 1985 ed. española), Dewdney se afana en explicar que Core War es un proyecto lúdico, cercano a los planteamientos de la vida artificial y no guarda relación con el incipiente fenómeno malicioso. Para dejar claras estas diferencias, cita la aparición en la Universidad Politécnica Estatal de California de un gusano para Apple II, o nos recuerda que un muchacho de Pittsburgh, Richard J. Skrenta Jr. (1967), cuando contaba con 15 años escribió un virus para Apple DOS 3.3 al que llamó Elk Cloner…

Los virus, la nueva epidemia
Es atrevido aventurar fechas concretas, pero, según mis recuerdos, fue a partir de 1985 cuando el fenómeno malware salió de los círculos especializados y llegó a la opinión pública. De ese año me viene a la memoria el artículo “Los ordenadores, infectados por virus”, publicado en la revista Conocer. En sus páginas nos alertaban de la existencia de una nueva epidemia que podría afectar a nuestros discos y ficheros, y comentaba la reciente novela francesa de Thierry Breton y Denis Beneich “Softwar, la guerra suave” (ed. española en 1985). Softwar introduce una nueva variedad de malware llamado bomba lógica que sirve como preludio al enfrentamiento entre EE.UU. y la desaparecida URSS.

De esa época, también recuerdo un breve artículo que se publicó en 1986 en la revista Muy Interesante Ordenadores titulado “La nueva epidemia”. En él se advertía del riesgo al que podían estar expuestas las instalaciones militares frente a los virus y, acompañando el texto, incluían un pequeño ejemplo de un virus para Commodore 64… Aunque todavía era de Spectrum aquello me convenció de que era cuestión de tiempo de los virus se convirtieran en una amenaza seria.

Virus en el boot de diskettes y disco duro
En 1987 por fin llegó a mi familia un flamante Amstrad PC 1512 y, como tantos usuarios de PC, no paraba de intercambiar y acumular software. Sin duda alguna, aquella obsesión por copiar fue la principal razón de las primeras infecciones y era cuestión de tiempo, unos meses o un año quizás, para verse infectado con cualquier virus liberado al otro lado del mundo… Así es como me enteré de la existencia del legendario virus Brain, que empezó a circular en Pakistán en 1986 y aterrizó en Occidente hacia 1987-88. Fue programado por los hermanos Basit y Amjad Farooq Alvi y, según su relato, fue un intento para controlar las copias indiscriminadas que otros hacían del software que comercializaban desde su establecimiento, Brain Computer Services. Irónicamente, la mayor parte del software que distribuían eran copias piratas de programas comerciales…

Históricamente, aquel virus se recordará por ser el primero para ordenadores compatibles IBM PC y, sobre todo, por aprovechar a su favor el proceso de arranque de un PC para tomar el control de una máquina y así logar replicarse a otros diskettes. Recordar que esta técnica, con los matices propios de cada sistema, era la base del virus Elk Cloner (1982) y ya fue comentada por los italianos Roberto Cerruti y Marco Morocutti en el artículo que Dewdney publicó en 1985 en Investigación y Ciencia. En resumen, se trataba de copiar el código del virus en los 512 bytes del MBR (master boot sector: cilindro 0, cabeza 0 y sector 1) de un diskette formateado para arrancar el sistema MS-DOS, es decir, donde estuvieran los archivos de kernel (IO.SYS y MSDOS.SYS), junto al intérprete de comandos COMMAND.COM. Si este disco infectado estaba insertado en la disquetera cuando finalizase el bootstrap de la BIOS, el virus pasaba a memoria y tomaba el control. A continuación, se cargarían los citados ficheros de kernel e intérprete de comandos y el usuario seguirá trabajando como si no pasara nada, pero, desde ese momento, todos los disquetes empleados para cargar y guardar otros archivos serian infectados…

Este proceso, con ciertas variaciones, inauguró la primera generación de virus para PC y fue imitado por otros virus célebres como, por ejemplo, Stoned (1987), Ping-Pong (1988) y el temido Michelangelo (1991) y su devastador borrado del disco duro cada 6 de marzo. [Continuará]

Introducción a la Ciberseguridad | Origen y evolución del Malware, 1971-1995 (2) | Origen y evolución del Malware, 1971-1995 (y 3)

Introducción a la Ciberseguridad

Adolfo García Yagüe | Hacia el final de este año escolar, me pidieron que diera una pequeña charla a jóvenes que estaban terminando la ESO. El objetivo era que conocieran una profesión y les ayudara a enfocar su carrera profesional.

En la presentación, intenté resumir algunos conceptos clave de la ciberseguridad: su evolución histórica, cómo se desarrolla un ataque y qué es MITRE ATT&CK. 40 diapositivas no dan para mucho y sé que me dejé miles, quizás millones, de cosas en el tintero.

Espero haber despertado alguna inquietud o, al menos, haber contribuido a que todos seamos más cuidadosos cuando hacemos clic. Si alguien se aburre este verano se puede descargar el PDF, está limpio 😉

Introducción

• Perspectiva histórica
• Automatización, Criptomonedas, Darknet e IA
• Adversario

Desarrollo de un Ciberataque

• Activos
• Superficie de exposición
• Riesgo
• Información
• Vulnerabilidades
• Exploits
• Malware
• Movimiento Lateral
• Ransomware
• Herramientas

Modelos de Amenazas y Marcos de Referencia

• Cyber Kill Chain
• Pirámide del Dolor
• MITRE ATT&ACK

[Descargar presentación]

GTP y la seguridad en redes 4G y 5G NSA

Adolfo García Yagüe | En el Fortinet Security Day de hace unos días, con la idea de presentar alguna de las áreas Cyber en las que trabajamos en Axians, hice esta pequeña presentación repasando las amenazas a las que han estado expuestas las redes telefonía de móvil: desde la denegación de servicio en el acceso radio hasta llegar a los ataques contra GPRS Tunneling Protocol.

Colección | Los Móviles | 1G o primera generación de telefonía móvil | HarmonyOS y los Sistemas Operativos Móviles | Ciberseguridad e IoT

Ciberseguridad e IoT

Adolfo García Yagüe | Estos días estoy dando un curso sobre Ciberseguridad e IoT en Fuenlabrada. Se enmarca en un proyecto impulsado por el propio Ayuntamiento y la Unión Europea. Se pretende formar a los asistentes en nuevas capacidades con el fin de reforzar y actualizar su curriculum. Es una iniciativa admirable que ayuda a crear sociedad y, sobre todo, porque me está permitiendo conocer la realidad de otras personas. En este módulo denominado “IoT” comparto el papel de formador junto a otros profesionales de Flexbot, la Fundación Telefónica y la Fundación Santa Maria la Real. Como digo es un privilegio estar ahí.

Os dejo la presentación del curso que estoy dando por si os resulta de interés. Como digo va sobre IoT, economía de datos, comunicaciones y seguridad. Muchas de las cosas que aquí trato son totalmente trasladables a nuestra cotidianeidad como usuarios de un equipo informático o un Smartphone. También, como no, se aclaran conceptos acerca de la importancia de los datos o 5G y como puede cambiar el entorno en el que vivimos. Milma Fuenlabrada. Laboratorio IoT

Agenda

Acerca del TELNET
Conceptos de IoT y Sistemas Embebidos

• Telemetría y telecontrol
• Smartphones
• Internet de las Cosas
• Tratamiento y economía de datos, Big Data
• Dispositivos basados en Microcontrolador y Microprocesador
• Arduino
• Raspberry PI
• TELNET BabelGate
• Riesgos Amenazas y Ataques

Software y Hardware

• Seguridad Física
• Identificación de vulnerabilidades
• Bootloader, Kernel, drivers y librerias
• Aplicaciones
• Cifrado
• Repositorios de claves
• Puertos Abiertos, Banners y Port-Knocking
• API (Application Program Interface)
• Ejemplo de instalación y mantenimiento desatendido
• Electrónica y Buses
• Memorias SD
• SIM (Subscriber Identity Module)
• TPM (Trusted Planform Module)

Conectividad Inalámbrica de un dispositivo IoT

• Conectividad Radio
• Frecuencias
• Topología, seguridad y radio
• Servicios M2M de Operador
• Sigfox
• LoRa
• Zigbee
• Z-Wave
• Bluetooth
• IEEE 802.11

Buses y Redes Industriales

• Seguridad lógica en Redes Industriales
• PRIME/COSEM

[Descargar ponencia]

Datos, datos y más datos

Hace unos días, en una intervención de Dimas Gimeno, presidente de El Corte Inglés, hablaba de la necesidad de equiparar a todos con las mismas reglas de juego, se refería, como es de suponer, a las empresas que están dando pequeños mordiscos al negocio tradicional de esta marca. También dejaba ver la necesidad de cambiar porque, queramos o no, los hábitos de los consumidores cambian y, como no, también se refirió al manido tema de los datos. Nos recordaba los 75 años de historia de ECI y de la experiencia que ello le confiere en “ese conocimiento del cliente”. Casi de igual forma se manifestaba Chema Alonso en la víspera del MWC, cuando desveló el significado de Aura. Nos contaba que ellos, Telefónica, tienen acceso a muchos datos porque llevan casi 100 años prestando servicio. Está claro que cada uno comenta cosas muy diferentes pero ambos hablaban de una realidad que está ahí, los datos.

Comerciar con los datos no es nuevo para nadie. Recordar cuando nos sentíamos importantes por ver nuestro nombre en las mastodónticas guías telefónicas… Menos ilusión hacía cuando empezábamos a recibir en nuestro domicilio publicidad no solicitada. ¿Cómo llega nuestro número de teléfono a una empresa de telemarketing? Mejor ni pensarlo… ¿De dónde salen nuestros datos? Si hablamos de empresas como ECI es similar: Cuando te haces una tarjeta de cliente o fidelización sueles estar «controlado». Aquellas tarjetas, que nacieron con el sano propósito de financiar la compra, pronto se usaron como un medio más de conocer nuestro patrón de consumo. Me olvidaba: Otros que saben mucho de datos son los bancos. Ellos conocen, de primera mano, cuales son nuestros  ingresos y gastos.

¿Qué ha cambiado?
Estos datos estaban antes de que naciéramos: Nuestro DNI, teléfono, dirección, ingresos, gastos y, como veíamos, la cesta de la compra. La aparición de Internet y el uso masivo del correo electrónico hizo que a esta lista de datos (digamos básica) se añadieran otros. Recordar, no tardamos en ser castigados con el molesto spam… Por otra parte, las comunicaciones en Internet, para que funcionen, requiere de una dirección IP única y, con todo el sentido, un administrador de un servidor web está interesado en conocer cuántos visitantes se cuelgan de su página. Así las cosas, irrumpen los buscadores cuya misión principal es hacernos la vida más cómoda en Internet. Ellos actúan de intermediarios entre nosotros e Internet. Conocen todo lo que buscamos y lo guardan en sus bases de datos. En un principio solo conocen nuestra dirección IP, que puede cambiar en cada acceso que hacemos, pero se cuidan de enviarnos una silenciosa piececita de software -o cookie- con la que nos identificamos (sin saberlo). Recordar que el uso de estas cookies es generalizado y no es exclusivo de un buscador. Ya nos tiene controlados y pueden modelar o dirigir nuestra navegación y atención como quieran. Más tarde nos regalaron direcciones de correo y espacio de almacenamiento y, lógicamente, nos teníamos que registrar y aportarles más detalles sobre nuestra identidad. Por último, se les ocurrió montar una red de conocidos dentro de Internet con la que podríamos compartir imágenes, textos o cualquier archivo multimedia. Esa red, para que funcione y sea eficiente, tiene que almacenar todo lo que queremos compartir. Es decir, son más datos vinculados con nosotros.

En modo alguno pretendo criticar o dirigirme contra esta industria pues, esta forma de funcionar, ha demostrado mejorar nuestra experiencia en Internet. También ha permitido innovar en campos donde parecía que todo estaba inventado y está iniciando una fuerte Trasformación, Digital por supuesto. Es cierto que esta Transformación está provocando que muchos sectores vean amenazada su posición o puestos de trabajo, y que el uso de cierta tecnología haga aumentar, exponencialmente, la riqueza de unos pocos en contra del desempleo de muchos. Creo que esta situación no nos conviene en una sociedad pues, a la larga, es mala para todos y tendremos o tenderemos a remediarla.

Tampoco nos conviene, como individuos, perder nuestra privacidad. Aunque nuestros datos estén ahí, no creo que a nadie de Google o Facebook le interese quien soy. A ellos les interesa el conjunto del que formo parte. Ellos usan nuestros datos analizándolos para entender o predecir que hacemos o que queremos. Parece ser que, incluso, pueden conocer un resultado electoral analizando la actividad previa en Twitter… En fin, para nuestro consuelo, hay que decir que muchas de las decisiones clave de estas empresas, incluidas las poner en marcha una nueva iniciativa, se toman analizando estos datos y es importante no olvidar que, aun así, se equivocan y fracasan, y algunos proyectos acaban en la basura por culpa su interpretación.

En cambio, sí me preocupa el uso criminal de esta información. Si los datos que almacena Facebook, LinkedIn, Apple o cualquier otro, caen en manos inadecuadas podemos encontrarnos con situaciones incomodas. Es importante recordar esto para que la próxima vez que nos suscribamos a una nueva plataforma o tarjeta de fidelización pensemos: ¿Si me doy de alta aquí y alguien “malicioso” se entera, en que me vuelvo vulnerable? ¿Alguien me puede atacar sabiendo el tipo de café que tomo?

Sociedad de la Información y minería de datos

Adolfo García | Ayer el Consejo de Ministros aprobó un plan para suprimir 29 empresas públicas y 32 altos cargos de la Administración y así ahorrar 16 millones de euros. Entre los órganos afectados desaparecerá la Dirección General para el Desarrollo de la Sociedad de la Información, dependiente del Ministerio de Industria, Turismo y Comercio. No puedo decir que me sorprenda, y tampoco creo que tenga consecuencias relevantes para el ciudadano. En cualquier caso, esta noticia me da pie para compartir algunas reflexiones.

La Sociedad de la Información es una bonita etiqueta para definir el mundo en el que vivimos. Sin lugar a dudas, esta denominación encierra un poderoso atractivo que la relaciona con el acceso democrático a la información y la comunicación global entre personas. Por esta razón, entre los quehaceres del Ministerio de Industria, se ha intentado fomentar el progreso social y económico a través del acceso a redes de datos y consumo de información. Más allá de esta visión tan idealista, el término Sociedad de la Información esconde otro significado menos saludable y a la vez más real e inquietante. Me refiero al hecho de que nuestras vidas y sociedades están dirigidas por los datos y la interpretación de estos.

La minería de datos, es decir, la recolección información y su posterior análisis es la auténtica esencia de la Sociedad de la Información. Instituciones públicas y entidades financieras son un ejemplo de organizaciones que necesitan conocer detalles de nuestra cotidianeidad para poder tomar decisiones. A veces, la posesión de información, su manipulación e interpretación interesada tiene consecuencias desastrosas, especialmente cuando se trata de la clase política. No es muy difícil asistir a intervenciones donde, flagrantemente, se falsean o malinterpretan datos para justificar una u otra política… ¿Y qué podemos decir de aquellas compañías que invaden la intimidad de nuestro hogar -o correo electrónico- ofreciéndonos productos a la medida de nuestras necesidades? Por último, seguro que todos conocemos alguna página en Internet que nos ha sorprendido presentando nuestros datos personales, domicilio, teléfono, etc. Caramba, ahora que me doy cuenta ¿No será más acertado emplear el término Información de la Sociedad?

Contra lo que muchos puedan pensar la minería de datos no es nueva. De hecho es bastante anterior a la existencia de ordenadores y redes de datos. Esta hunde sus raíces en los albores de otra Sociedad -esta vez la Industrial- a comienzos del siglo XIX en Inglaterra. Allí apareció una corriente de pensamiento denominada utilitarismo que influyó notablemente en la vida política y económica del país. Al igual que siglos antes Francis Bacon (1561-1626) llegó a la conclusión de que el único camino para desentrañar los misterios de la naturaleza era -partiendo de una posición escéptica- observar, tomar mediciones (datos) e interpretar estos, los utilitaristas se dieron cuenta de la importancia de recoger datos de cualquier aspecto de la vida en sociedad  para, posteriormente, interpretarlos y tomar decisiones políticas… A la cabeza de este movimiento estaba el excéntrico Jeremy Benthan (1748 – 1832).

Cada día es más difícil establecer los límites en el acceso y manipulación a los datos que definen nuestra vida y costumbres porque, al vivir en un mundo dominado por la tecnología, vamos dejando (consciente o inconscientemente) tras nuestros pasos un reguero de valiosa información. Es este sentido es oportuno recordar la regulación procedente de la Administración Pública a través de la Agencia de Protección de Datos y  la LOPD (Ley Orgánica de Protección de Datos).

Quiero acabar este post citando AbreDatos 2010. Este concurso se celebró los días 17 y 18 de abril con la pretensión de generar un debate en torno a la necesidad de que los organismos públicos proporcionen sus datos de forma accesible, para permitir su uso y reutilización por parte de los ciudadanos. Los participantes tenían como objetivo desarrollar una aplicación en menos de 48 horas que hiciera uso de al menos una fuente de datos públicos y transformara estos en información útil.

Dirección General Desarrollo de la Sociedad de la Información www.mityc.es/dgdsi
Agencia de Protección de Datos www.agpd.es
AbreDatos 2010 www.abredatos.es
Fuentes de Datos Abiertos en España https://datospublicos.jottit.com/