Select Page
Alta eko

Alta eko

La semana pasada finalizó la edición número 15 de la ekoparty con excelentes aportes y mucho para aprender. Este año tuve la suerte de poder participar los 3 días. Si bien no pude participar de varias actividades, les hago un resumen de lo que extraje de las charlas a las que asistí.

 

Jugando con Plantas de Gas

Este workshop fue dado por Pablo Almada de KPMG. Pablo dedicó el 80% del tiempo a explicar como funcionan las plantas de gas. Seguramente los más hackers estaban esperando ver herramientas, exploits, código… Sin embargo, la explicación fue muy buena y quedó clarísimo que es imposible atacar los sistemas de control de una planta de gas si no se conoce cómo funciona. En ese sentido, creo que los asistentes (o por lo menos yo) nos fuimos con un conocimiento muy completo de su funcionamiento.
Después de eso, nos explicó la forma que se utilizan los PLC en instalaciones industriales de este tipo y comenzamos a entender cómo buscarlas en Internet, reconocerlas y atacarlas. Bastante fácil por cierto. Como ejemplo, hice una búsqueda en Shodan para encontrar PLCs de Rockwell publicados en Internet (de más está decir que NO deberían!) y me encontré con esto…

 

La búsqueda que se muestra es:

port:44818 product:”Rockwell Automation/Allen-Bradley”

Da un poco de miedo.

 

OSINT e Ingeniería Social Aplicado a las Investigaciones

Emiliano Piscitelli, Alan Levy, Carlos Loyo y Jorge Martín Vila dieron una charla de cómo investigar utilizando OSINT. Utilizaron el ejemplo de los piedrazos que recibió el micro de Boca antes de la final de la Libertadores. Además de explicar bastante metodología como la de Juilán GL y su Ciberpatrulla, mostraron innumerables herramientas de análisis que ayudan investigar. Algunas de ellas son buscador.ova para buscar sin ser vistos; faceapp.com para crear perfiles falsos; hootsuite y postcron para generar contenido en las redes sociales; GeoSocial Footprint para ubicar geográficamente a las personas cuando postean, etc.
Pero lo mejor estaba por venir, y las clases de magia fueron el broche de oro para la charla. Fue muy interesante que nos mostraran como funciona el cerebro humano. Gracias a eso, cómo funciona la magia, y por la misma razón, como todos podemos ser fácilmente engañados.

 

¡Cazando bugs con redes de pesca!

Nico Waisman está trabajando en Semmle auditando código de Google. Explicó cómo usar QL, un motor que permite hacer análisis de código fuente de forma muy precisa. La charla fue puro código y encima usó un plugin de QL para Eclipse…. Sin embargo lo bueno es que todos nos fuimos con el conocimiento de la existencia de la aplicación y algunas nociones muy didácticamente explicadas, sobre cómo construir código en QL que audite código escrito en los lenguajes que soporta la herramienta. El concepto se basa en modelar la superficie de ataque del software, buscar fallas desde simples lineas hasta en flujos completos. Con esto se desarrolla código que después puede utilizarse para buscar las mismas fallas en otros programas.

 

SIEMs Framework

Esta fue una de las charlas de Containers (…porque se daban dentro de containers…). En este caso Yamila Levalle y Claudio Caracciolo presentaron una herramienta para atacar sistemas SIEM.

Inicialmente me había ilusionado ya que comentaron que iban a mostrar como utilizar los SIEMs como vectores de ataque. Pensé que habían desarrollado una vieja idea en la que nunca tuve tiempo de trabajar: la de, sabiendo que el blanco usa un SIEM, enviar paquetes que produzcan logs que puedan romper ese SIEM…

Buen, no era eso lo que presentaron. La charla consistió en la presentación de un framework para atacar sistemas SIEM. El framework se llama SIEMS FRAMEWORK (o MultiSIEM Modular Python3 Attack Framework?) y se puede encontrar en github.
El sistema por ahora soporta Splunk, Graylog y Ossim pero tienen planeado incorporar otros sistemas como Qradar, ArcSight, etc. No tuve tiempo de probarlo pero es una de las tareas que me llevo para los próximos días.

 

Hacking and auditing LoRaWAN networks

Cesar Cerrudo junto a Esteban Martinez Fayo y Matias Sequeira presentaron su análisis de vulnerabilidades de redes LoRaWAN, un protocolo de redes WAN inalámbricas de baja potencia. El sistema es bastante nuevo pero se cree que ya hay 80 millones de dispositivos LoRaWAN en el mundo. Se cree que la base instalada va a crecer exponencialmente y eso es preocupante por las fallas de seguridad que tiene el protocolo.
La arquitectura de LoRaWAN se puede ver en el siguiente gráfico:

Por ahora existen varios potenciales ataques bastante peligrosos y hay pocas herramientas para auditar su seguridad. Una de ellas es el LAF (LoRaWAN Auditing Framework). La gente de IOActive explicó en detalle las vulnerabilidades y algunas posibles contramedidas.

 

¿Cómo hacer entrevistas técnicas?

La psicóloga Carolina Maristany explicó en este workshop cómo hacer entrevistas técnicas a la hora de seleccionar personal. Fui a ese workshop porque tenía mucha curiosidad de ver qué hace un tema como este en una eko. Lo que Carolina contó fue más o menos lo mismo que conozco y que vengo aplicando desde hace años en las entrevistas laborales. Lo que más me llamó la atención de esta charla fue la gran cantidad de asistentes. Me pregunté si los especialistas en seguridad (…hackers…) presentes en la eko necesitarían escuchar estos tips para cuando ellos vayan a ser entrevistados…

 

Receta Práctica y Económica de un Implante de Hardware

En esta charla, Andrés Blanco y Lautaro Fain contaron con detalle cómo implantar un microcontrolador en un dispositivo de hardware estándar de forma de poder tener control del mismo. Empezaron el proyecto trabajando a partir de una placa de desarrollo similar a la Blue Pill pero basada en ARM, la STM32F030F4.

El objetivo fue el de implantar el controlador en un router WiFi TP-Link. Una vez que verificaron que era posible interceptar la función de actualización del firmware con un dispositivo del tamaño del STM32, pasaron a miniaturizar el implante y a instalarlo de forma totalmente imperceptible. Si alguien hiciera esto el algún dispositivo que estemos usando, sería muy difícil detectarlo.
De más está decir que me dieron ganas de desarmar todos mis dispositivos para ver si alguno tiene hardware implantado.

 

OpenBSD una workstation segura

Este workshop me entusiasmó bastante por un proyecto que tengo en el que había pensado usar OpenBSD como sistema operativo base. Lo dió la gente de BSDar, una organización fundada en mayo de este año y se ve que con mucha fuerza y ganas.
El objetivo de Matías y Anatoli fue el de explicar qué es OpenBSD, mostrar su instalación y configuración como workstation configuración de 2 window managers y compilación del kernel incluida. El plan original no se logró por completo debido a que la intro de OpenBSD que dio Anatoli se llevó casi todo el tiempo del workshop. Sin embargo, todo lo que se contó sobre sistema me pareció realmente muy interesante. Todos sabemos que OpenBSD es uno de los sistemas operativos más seguros del mundo. Lo que yo no sabía hasta ese momento es exáctamente por qué.
El generador de números aleatorios propio, sumado a los sistemas para ubicar en forma aleatoria los programas en memoria, generar aleatoriamente los pids, relinkear el kernel en cada instalación, ya muestran características de seguridad desde el diseño. A esto se le agrega el esquema de seguridad en el que no es posible relajar un permisos mientras el sistema esté online, la eliminación de captura de audio/video, la imposibilidad de correr las X como root, que todos los servicios se chroot’een o el doas, mucho más seguro que el sudo. Y como broche de oro, la mínima cantidad de vulnerabilidades halladas sobre OpenBSD a lo largo de la historia.
Por supuesto que lo primero que hice al llegar a casa fue tratar de instalarlo. Como no tenía un equipo donde hacerlo, lo hicen en una VM de virtualbox. Me llevó bastaaaante tiempo, pero finalmente y con ayuda de los chicos de BSDar…

Gracias a este grupo y a OpenBSD seguramente pasaré muchas noches sin dormir.

 

Backdooring Hardware Devices by Injecting Malicious Payloads…

La charla de Sheila se basó en su investigación sobre tres formas de inyectar código en microcontroladores. Las pruebas las hizo sobre el PICkit3. Con mucho detalle técnico y una explicación impecable como siempre, mostró como hacer para que estos PICs carguen código malicioso. Para la demo, sólo hizo que enciendan unos leds, pero evidentemente es posible hacer cosas más graves. En particular, si estos PICs son que se usan dentro de los autos.

 

Modern Secure Boot Attacks: Bypassing Hardware Root of Trust from Software

En esta charla, Alex Matrosov no sólo mostró vulnerabilidades del hardware relacionadas con el software. Además presentó una paradoja muy interesante desde el punto de vista de seguridad.

Si se prentende que los programas sobre los dispositivos sean seguros e inalterables, una solución es instalarlos sobre el hardware en ROM. Pero si en algún momento aparece alguna vulnerabilidad en ellos, estas son imposible patchearlas. Esto exáctamente es lo que pasó con EPIC Jailbreak, la vunerabilidad de los iPhone desde el 4 en adelante, que fue publicada el viernes 27, precisamente el último día de la eko. Como fue hallada en la Secure BootROM de los iPhones no es posible patchearla.
Para evitar esto, el software entonces podría instalarse como firmware, es decir en la flash de la BIOS, con la posibilidad de que sea actualizado y patcheado. Pero en este caso, los mecanismos para actualizar el firmware, también pueden ser utilizados de forma maliciosa para infectarlo.

Tan sencillo se vuelve para un atacante utilizar esos mecanismos, que Matrosov presentó funciones de PowerShell que permiten fácilmente modificar parámetros de la BIOS. Muy cómodas para el administrador… y también para los atacantes.

 

Internet-Scale analysis of AWS Cognito Security

La investigación presentada por el amigo Andrés Riancho en esta charla, tuvo por objetivo mostrar cómo utilizar la función de AWS Cognito de forma inversa a su propósito original. Cognito es un esquema de autenticación, autorización y manejo de usuarios para aplicaciones web y móviles. Los errores de configuración de las aplicaciones que lo usan, le permitieron a Andrés hacer un relevamiento a escala de Internet encontrando una gran cantidad de credenciales de acceso. Si bien no lo hizo, con esas credenciales pudo haber obtenido acceso a gran cantidad de datos sensibles de miles de usuarios. Excelente trabajo y una alerta para los que piensan que “la nube” es intrínsecamente segura.

 

 

Disfruté mucho de la eko de este año, aprendí mucho y, por sobre todo, me encontré con amigos muy queridos que hacía mucho que no veía. Ahora, a pensar en la eko 16….

 

 

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
NetCAT: otro side-channel de Intel

NetCAT: otro side-channel de Intel

Otra vulnerabilidad de side-channel en procesadores Intel, permite reconstruir sesiones SSH usando Keystroke Dynamics.

Ya habíamos hablado hace tiempo de las vulnerabilidades de side-channels (o Canales laterales). Meltdown y Spectre son los más resonantes ejemplos de dichas vulnerabilidades que afectan a los procesadores Intel.
En ese sentido, investigadores de la universidad de Vrije de Amsterdan publicaron un paper donde presentan un nuevo ataque a procesadores Intel modernos explotando canales laterales.

A partir del descubrimiento, el grupo inició un proceso de publicación de la vulnerabilidad acordado con Intel y el CERT Alemán el 23 de Junio pasado. A la vulnerabilidad se le asignó el código CVE-2019-11184 y además Intel, le asignó el suyo propio: INTEL-SA-00290.

 

Fundamentos:

El grupo de 5 investigadores del Departamento de Ciencias de la Computación de la universidad, señala la dificultad que poseen los procesadores modernos para sostener la alta tasa de transferencia de placas de red modernas. En lugar de transferir esos datos desde y hacia la DRAM, los procesadores Intel modernos realizan operaciones de E/S directamente en la LLC. Esta función se denomina DCA (Direct Cache Access) y se utiliza en lugar de acceder a la memoria vía DMA (Direct Memory Access). La función para acelerar la transferencia de datos con esta técnica se denomina Data-Direct I/O (DDIO).

El problema de utilizar LLC es que esta memoria caché se comparte entre la CPU y el resto de los periféricos, y está implementada por diseño sin medidas de seguridad. Los investigadores de Vrije hicieron foco en uno de los dispositivos, las interfaces de red. De esta forma crearon un ataque denominado NetCAT (abreviatura de Network Cache ATtack) mediante el que explotan información sensible de tiempos en comunicaciones de redes. Particularmente, detectan las teclas oprimidas por otro usuario que comparta la misma CPU en una sesión SSH.

¿Pero cómo hacen para saber qué teclas oprimió un usuario? Esto sería imposible teniendo en cuenta que la vulnerabilidad descubierta es sobre el contenido de información de red (que quedan en la LLC) y a nivel de red, los paquetes SSH viajan cifrados. La forma de obtener esa información es adivinando las teclas que oprimen los usuarios. Y eso lo hacen mediante Keystroke Dynamics.

 

Prueba de concepto

Los investigadores publicaron el detalle de como construyeron el ataque. Éste empieza conectándose a un dispositivo que esté utilizando un procesador intel con DDIO y RDMA habilitados. Si hay un usuario que se conecta al mismo servidor y establece una sesión SSH, es posible registrar la llegada de cada paquete de dicha sesión. Dado que en SSH los caracteres que el usuario tipea se envían de a uno por vez, es posible adivinar los caracteres enviados por la latencia entre ellos. Esta técnica es bastante antigua. Esto ya lo hacía el viejo Chaosreader hace unos 15 años. El que, a su vez, había tomado el concepto de Song en su paper de 2001.
Podemos ver lo que hacía Chaosreader ya que milagrosamente ¡la página de Brendan Gregg sigue viva! La diferencia con NetCAT es que Chaosreader capturaba paquetes de red y trabajaba con ellos para obtener información diversa. Una de las funciones de la herramienta era “adivinar” el contenido de sesiones SSH mediante una herramienta denominada sshkeydata.
En esta página se pueden ver los resultados de procesar paquetes de sesiones SSH. Aquí se puede ver cómo se analizan los paquetes para tratar de reconstruir la sesión.

La gente de Vrije utilizó además que el de Song, otros trabajos más modernos que le permitieron aumentar la precisión. Por otro lado, leer los tiempos de llegada de los paquetes via DDIO es más preciso que usando libpcap por la red. Sin embargo, se enfrentaron con los mismos problemas que todos los que hicimos esto alguna vez: extraer las teclas tipeadas por usuarios no enrolados*. Teniendo en cuenta que todas las personas escriben sobre un teclado con patrones de tipeo diferentes, esta tarea es la más difícil de realizar.

 

Conclusiones

Por un lado, en la eterna pelea performance y usabilidad vs. seguridad, a veces ganan unos y a veces otros. Habilitar DDIO y RDMA sabemos que es poner a los procesadores en modo turbo. Pero el efecto secundario es que se pierde seguridad. En este caso, poder leer datos de la caché de los dispositivos va mucho más allá que reconstruir sesiones SSH. Hay mucha información sensible que puede estar siendo transferida entre dispositivos por un usuario y vista por otro que no tiene privilegios y sólo por estar en el mismo procesador.

Por el otro, ciberseguridad ya tiene tantos años que dejó de ser nueva. Otra vez side-channel attacks… otra vez Intel… otra vez keystroke dynamics.
Los problemas que se encuentran hoy ya no son nuevos, sino viejos que se reciclan.

 

 

*Usuarios no enrolados: usuarios de los cuales no se tiene la información de su patrón de tipeo.

 Usuarios enrolados: usuarios que se los somete a varias pruebas repetitivas, para que tipeen textos conocidos y controlados, y así se puede obtener su patrón de tipeo.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Jugando con Qubits: el proyecto qiskit (parte 3)

Jugando con Qubits: el proyecto qiskit (parte 3)

Qiskit es parte del proyecto abierto de IBM para que cualquiera pueda experimentar con computadoras cuánticas. En esta tercera parte, veremos qué se puede programar en una computadora cuántica, y cómo jugar con las computadoras cuánticas que IBM pone a disposición de la comunidad.

Ya vimos algunos conceptos básicos de computación cuántica, hablamos de hardware y de software. Ahora vamos a poner manos a la obra.

Para poder jugar con las computadoras cuánticas de IBM, lo primero que tenemos que hacer es darnos de alta el el sitio correspondiente, es decir: https://quantum-computing.ibm.com.

Fig. 1 – IBM Quantum computing – login.

 

Como podemos ver, nos podemos loguear con cualquiera de estas opciones. Aunque por temas de seguridad, mi recomendación es NUNCA utilizar autenticación cruzada.

Una vez logueado, lo recomendables es recorrer los tutoriales y “getting started” iniciales para poder comenzar a entender lo que vamos a hacer.

 

Fig. 2 – IBM Quantum computing – home.

 

A la derecha se pueden las herramientas cuánticas disponibles. En el momento de tomar el screenshot, había 5 backends disponibles: las cuatro computadoras cuánticas y un simulador. Como puede verse, las computadoras cuánticas de Yorkshire y de Tenerife (ambas de 5 quibits) se encontraban en mantenimiento. Por otro lado, las de Melbourne (14 qubits) y Ourense (5 qubits) estaban en linea. Al final de la lista, puede verse un simulador de hasta 32 qubits.

Al hacer clic sobre cada máquina, se pueden ver sus características y su estructura. A modo de ejemplo, se muestra la computadora de Melbourne:

Fig. 3 – Estructura de la computadora cuántica de Melbourne de 14 qubits.

¿Qué es qiskit?

Qiskit es un framework de desarrollo open source, que permite desarrollar software sobre las computadoras cuánticas actuales. Qiskit cuenta con diferentes frameworks y librerías que tienen por objeto experimentar diferentes aspectos de las computadoras cuánticas. Como ejemplo:

Terra

Es prácticamente el core del sistema. Incluye herramientas para desarrollar programas cuánticos a nivel de circuitos y pulsos, optimizándolos para un procesador cuántico físico en particular.

Aqua

Incluye librerías con algoritmos cuánticos en diferentes dominios sobre los que se pueden desarrollar aplicaciones en forma relativamente sencilla y rápida. Permite hacer experimentos con aplicaciones de química, inteligencia artificial, optimización y finanzas.

Aer

Tal como comenté en la parte 1, el ruido o la decoherencia es uno de los grandes enemigos de las computadoras cuánticas. Aer tiene un conjunto de herramientas para trabajar con modelos de ruido altamente configurables para crear simulaciones de ruido realistas. Esto permite minimizar los errores que se producen durante la ejecución en dispositivos reales.

Ignis

Como Aer, es otro framework para entender y mitigar el ruido en circuitos y sistemas cuánticos.

Una de las mayores dificultades que, al menos yo, he tenido, fue la de trasladar los problemas del mundo real para resolverlos en una computadora cuántica en vez de en una computadora convencional. Para esto, qiskit ayuda bastante. He aquí por ejemplo un tutorial en el que con ejemplos muy básicos nos va guiando a cómo hacer ese cambio de paradigma en la cabeza.

 

Hello world!

Ok, ¿cómo empezamos a programar? Usando Qiskit, se pueden utilizar como inicio los tutoriales de Quiskit. Aquí se nos presentan no sólo las bases de la programación de framework, sino que también notebooks armadas de Jupyter donde podemos jugar desarrollando piezas simples de código.

Para trabajar con Aqua, un buen pinto de comienzo son los tutoriales y ejemplos que se encuentran en Github. Se puede comenzar con los fundamentals, y continuar con el advanced. Si bien muchos de estos notebooks se pueden encontrar dentro del sitio de IBM una vez que se logueen, si se encuentran algún notebook por ahí que no esé, se puede importar dentro de la app de IBM.

 

Fig. 3 – Menú de Notebooks de Qiskit.

 

 

Fig. 4 – Importar Notebooks en Qiskit.

 

Además de toda la información que se puede encontrar en el proyecto de IBM, existen otras fuentes que se pueden consultar y de donde aprender para empezar a desarrollar en modo Q. Una de ellas es Project Q, un proyecto que está bajo la licencia Apache 2. Su propósito es el de proporcionar herramientas que faciliten la invención, implementación, prueba, debugging y ejecución de algoritmos cuánticos utilizando tanto hardware clásico como computadoras cuánticas reales. En Project Q podemos encontrar 3 ejemplos concretos de aplicaciones desarrolladas para computación cuántica.

 

Shor

Hasta ahora llevamos tres partes de la nota y no hicimos ninguna mención a aplicaciones de ciberseguridad. Pero es obvio que las hay. La estrella de estas aplicaciones es el algoritmo de Shor. Peter Shor es un matemático del MIT que desarrolló un algoritmo revolucionario. El mismo permite factorizar números primos en una computadora cuántica de una forma que es imposible en computadoras clásicas debido a la complejidad y el tiempo necesario para el cálculo (años, siglos o milenios…). No hace falta que explique que si tenemos un número enorme que forma parte de un algoritmo de cifrado… y podemos extraer los dos números primos que se multiplicaron para obtenerlo… estamos a un paso de descifrar el mensaje sin tener las claves.

 

Hasta el infinito y más allá…

Pero esto recién empieza. Las posibilidades del uso de computación cuántica se multiplican en todas las ramas. Por lo que todo lo que necesite horas o días de procesamiento y hoy no se puede hacer, será posible cuando la potencia de cálculo cuántico esté disponible masivamente. Las aplicaciones de ciberseguridad no quedan ajenas. Desde las aplicaciones de redes como las Network Centric Quantum Communications, para la protección de infraestructuras críticas, como el uso de Machine Learning a velocidades de cálculo extremas, o sistemas de clasificación basados en Support Vector Machines.

¿Será entonces cuestión de esperar…? NOOO!!! Será entonces cuestión de poner manos a la obra, aprender, programar, experimentar y desarrollarse en este campo.

 

 

 

Nota: Vayan mis respetos a uno de mis colegas, ex-Si6, que hoy se encuentra trabajando en el proyecto Qiskit. Mis felicitaciones Luciano Bello!!! y GRACIAS por revisar y ayudar a mejorar el artículo.

 

 

 

< Jugando con Qubits (parte 2)

 

 

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Jugando con Qubits: el proyecto Qiskit (parte 2)

Jugando con Qubits: el proyecto Qiskit (parte 2)

Qiskit es parte del proyecto abierto de IBM para que cualquiera pueda experimentar con computadoras cuánticas. En esta segunda parte, veremos cómo es el hardware que se utiliza, y qué significa el concepto de software en computación cuántica.

En la primera parte vimos algunos conceptos básicos de computación cuántica. Ok, ¿pero cómo y dónde se hace el procesamiento en sistemas cuánticos?

 

Hardware

Dijimos que las computadoras cuánticas utilizan propiedades cuánticas a nivel atómico o subatómico. Entonces, ¿cómo se construye una computadora que trabaje con partículas subatómicas individuales? La respuesta es que no se puede. Además sería muy poco eficiente, dado que las partículas individuales son inestables debido al ruido ambiente. ¿Entonces?
Lo que se hace es simular estados cuánticos con diversas técnicas. La más utilizada es mediante el uso de superconductores. (Ver Superconductores). Para los interesados, aquí tienen un video de Google sobre como es posible simular estados cuánticos a escalas muy superiores a la atómica.

 

Superconductores

Son estructuras cristalinas en las que cuando se baja suficientemente la temperatura (es decir energía) ambiente, los átomos quedan como si estuvieran fijos (sin vibrar) y alineados. De esta forma, los electrones pueden atravesar dichas estructuras sin chocar con nada a su paso. Eso significa que nada les ofrece resistencia. Llevada a parámetros físicos, esto significa que su resistencia se vuelve cero ohms.

Rsc = 0 Ω

La superconductividad es una propiedad muy curiosa ya que cuando un material entra en estado superconductor su resistencia es absolutamente 0. Sí cero, no 0.00002 o 10-37… sino cero… es por eso que el conductor que entra en ese estado, se gana merecidamente el prefijo de Súper.

En mi caso personal, ¡qué bueno haberme reencontrado con los superconductores después de tantos años! Allá por fines de los ’80 participé en las mediciones de materiales superconductores cerámicos de alta temperatura (YBaCuO) fabricados por mi amigo que en ese entonces era mi jefe, el Lic. Ricardo Juárez.

Lo veía en el laboratorio pero me costaba creer que esos materiales pudieran levitar sobre sobre un imán debido a sus propiedades diamagnéticas… Es el efecto Meissner, por si no lo conocían y quieren verlo.

Lo que tuvo de maravilloso el descubrimiento de Bednorz y Müller allá por 1986 fue que hasta ese momento, la única forma de llevar a un material al estado superconductor era bajarle la temperatura a unos 4° Kelvin, la temperatura del Helio líquido, ¡¡¡…carísimo…!!! Pero con el nuevo material descubierto, ahora es posible hacerlo a unos 78 °K, la temperatura del aire líquido… en comparación ¡¡¡baratísimo!!!

Si bien hoy en día existen algunas iniciativas para usar superconductores de alta temperatura en computadoras cuánticas, todavía están en estado experimental. Los superconductores que se utilizan actualmente en computadoras cuánticas, son metales que se los enfría a temperaturas extremadamente bajas, del orden de los miliKelvins. Llevar a un material a esa temperatura no solo demora días sino que además el costo es extremadamente alto.

Es por estos elevadísimos costos que no solo la construcción, sino la misma operación de computadoras cuánticas quedan limitados a grandes corporaciones o laboratorios con muchos fondos disponibles. Esto… hasta que se logren construir computadoras cuánticas basadas en YBaCuO…

Dado que los superconductores utilizados deben ser enfriados a sólo algunos miliKelvins de temperatura, la construcción y puesta en funcionamiento de una computadora cuántica no es nada sencillo. En la siguiente imagen se puede ver cómo es una computadora cuántica. En este caso, la IBM-Q.

 

Fig 1.- Computadora cuántica IBM-Q

 

En el caso de las computadoras cuánticas de IBM, los qubits se simulan con capacitores de Niobio y superconductores de Aluminio formando junturas Josephson a temperaturas de 0.015 °K.
En el extremo inferior de lo que se ve en la figura, se encuentra el chip cuántico.

 

Fig. 2 – Chip de IBM-Q

 

Potencia

Es muy difícil medir la potencia de una computadora cuántica. La dificultad reside en que existen diferentes tecnologías que tienden a hacer foco en diferentes aspectos.  La métrica más obvia y simple de entender es la cantidad de qubits. En un sitio del MIT denominado qubitcounter se puede ver cómo viene evolucionando la carrera por construcción de computadoras cuánticas de mayor cantidad de qubits.
La computadora con la mayor cantidad de quibits construida hasta el momento, fue desarrollada por la empresa Righetti de Estados Unidos y es de 128 qubits.
En el siguiente gráfico, se puede ver cómo fue la linea de tiempo desde la primer computadora cuántica hasta ahora.

Fig. 3 – Linea de Tiempo de desarrollo de procesadores cuánticos.

 

 

Sin embargo, la cantidad de qubits no define la eficiencia o la potencia de una computadora cuántica. El tema del benchmarking de computadoras cuánticas está en discusión permanente dado que cada fabricante trata de favorecer lo que cada uno tiene como fortaleza. Un intento por determinar un parámetro que sea lo suficientemente objetivo puede verse aquí, aunque todavía no existe un acuerdo o normalización en este tema.

 

Software

Una vez que se posee la computadora cuántica, se necesita hacer que nuestros problemas sean resueltos por ésta. En el caso de una computadora clásica, esto se hace programando la lógica de lo que queremos hacer en lenguajes de alto nivel. Este programa después se compila en instrucciones de código de máquina para que el procesador pueda interpretarlo y ejecutarlo.

En el caso de una computadora clásica, se podría pensar en en que el código de programación se mapea en código de máquina de la siguiente forma.

 

Fig. 4 – Mapeo entre un lenguaje de alto nivel (izquierdaa) versus las respectivas instrucciones para un procesador (derecha).

 

 

En el caso de las computadoras cuánticas, el proceso es bien diferente. De acuerdo con la arquitectura que posea cada diseño, el código resulta en la construcción de circuitos cuánticos que representan el problema que queremos resolver. Este es un ejemplo:

Fig. 5 – Mapeo entre un programa en Python (izquierda) versus su respectivo circuito cuántico (derecha).

 

En el caso particular de los procesadores de IBM, se puede encontrar una documentación muy completa y clara sobre los circuitos cuánticos.

Ahora bien, ¿qué problemas se pueden resolver con computadoras cuánticas? La respuesta es: algunos problemas sencillos, y algunos que son imposibles para la computación clásica.

En la tercera parte, veremos qué se puede programar en una computadora cuántica, y cómo jugar con las computadoras cuánticas que IBM pone a disposición de la comunidad.

 

< Jugando con Qubits (parte 1)

 

 

 

Jugando con Qubits (parte 3) >

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Jugando con Qubits: el proyecto qiskit (parte 1)

Jugando con Qubits: el proyecto qiskit (parte 1)

Qiskit es parte del proyecto abierto de IBM para que cualquiera pueda experimentar con computadoras cuánticas. En esta primera parte, les cuento algunos conceptos básicos de computación cuántica.

Existe una gran cantidad de recursos para aprender y experimentar con computación cuántica. En este artículo les voy a mostrar cómo hacerlo con el proyecto de IBM.

Antes de empezar, quiero avisar que esta nota no es para nada sencilla y que para entender van a tener que leerse todas las referencias. En algunos casos hay cuadros que intentan explicar algunos conceptos y en otros es mejor recurrir a la fuentes. Advertidos están…

El mismísimo Richard Feynnman decía que si alguien cree que entendió la física cuántica es que no entiende la física cuántica. Obviamente yo no la entiendo y no pretendo que ustedes lo hagan. Sin embargo, creo que del mismo modo que para conectar, encender y apagar una lámpara led, no es necesario entender cómo se mueven los electrones en un cable o cómo un semiconductor emite fotones; tampoco necesitamos entender profundamente la mecánica cuántica para utilizar computadoras cuánticas.
Así que, vamos…

 

Primer interrogante:

Hago esta pregunta porque no sólo yo mismo me la hice, sino que la escuché muchísimas veces: ¿Criptografía o computación cuántica? después de todo… ¿no es lo mismo?
Bueno, definitivamente no.

Si bien en ambas áreas se utilizan las propiedades cuánticas como base, las formas de efectuar operaciones en los dos casos, son bastante diferentes. Leí decenas de textos que dicen que las computadoras cuánticas van a factorizar primos tan rápidamente, que la criptografía clásica va a morir. Y creo que es por esa conexión que muchas veces se confunden ambas disciplinas, pero no son lo mismo.

 

Criptografía cuántica:

Esta disciplina se refiere a los métodos y técnicas para cifrar información basándose en los principios de la mecánica cuántica. Existen varias aplicaciones de criptografía cuántica tales como dinero cuántico, generación de números aleatorios, computación segura entre dos o más partes, computación cuántica delegada. De todas estas aplicaciones, la más conocida es la distribución de claves cuánticas o QKD (Quantum Key Distribution). Su objetivo principal es el de realizar un intercambio seguro de claves simétricas entre emisor y receptor. En este caso no se realiza ninguna operación matemática, esto lo diferencia sustancialmente de la computación cuántica. (Ver QKD).

 

QKD

Este sistema fue presentado inicialmente por Bennet y Brassard en 1984. En su paper, los autores describen el diseño del protocolo de intercambio de claves denominado BB84, mediante la cual dos usuarios intercambian una clave aleatoria que luego se utilizará para cifrado asimétrico clásico, por ejemplo mediante AES.

El protocolo se inicia cuando el emisor genera fotones en secuencia y una secuencia de bits que corresponden a la semilla de lo que va a ser la clave. Cada bit de la clave corresponde a un dirección de polarización. El emisor entonces codifica dichos fotones uno a uno polarizándolos según la semilla de bits de la clave, llevando a cada uno a un estado de polarización relacionado con dicha secuencia.

Estos fotones se transmiten al receptor quien no conoce qué secuencia de polarización utilizó el emisor. Por este motivo, el receptor prueba aleatoriamente una secuencia de filtros para detectar el estado de cada fotón. En función de los resultados le envía al emisor la información de qué secuencia de filtros utilizó.

El emisor confirma cuáles filtros coinciden con los reales, sin decir los resultados obtenidos ya que esro se envía por un canal público. En función de esa información, ambos descartan los fotones erróneos y obtienen la clave que corresponde a una secuencia de bits que es un subconjunto de la semilla inicial.

Sin abundar en detalles, si alguien interceptara este mensaje, no podría determinar la clave debido a que tampoco conoce la secuencia de filtros utilizados. Como al leer los estados los destruye, el intruso debería regenerar los mismos fotones con la secuencia de polarizaciones que él considera válida. Como esta no lo es, tanto emisor como receptor se dan cuenta que alguien alteró la información debido a que la probabilidad total de estados correctos es menor a la que debería.

Sobre este protocolo se hallaron vulnerabilidades y se desarrollaron ataques, pero también se desarrollaron mejoras al protocolo BB84, como lo es SARG04.

Computación cuántica:

El principio básico de la computación cuántica consiste en que se pueden utilizar las propiedades cuánticas para representar y estructurar datos. Por otra parte, los mecanismos cuánticos pueden diseñarse y construirse para realizar operaciones con estos datos. Las dos principales propiedades cuánticas usadas son superposición y entrelazamiento. (Ver Propiedades Cuánticas).

La forma de modelar los datos y las operaciones son completamente diferentes a los sistemas binarios utilizados en las computadoras normales. En vez de codificar los números en bits que pueden tomar los valores 1 ó 0 como en la computación clásica, los datos se codifican en qubits. Éstos también pueden tomar valores |1〉 ó |0〉 pero en este caso, no mutualmente exclusivos, sino ambos valores al mismo tiempo. Los estados posibles de un qubit se representan en la esfera de Bloch.

 

Fig. 1 – Esfera de Bloch

 

El valor del qubit se puede representar como:

α|0〉 + β|1〉

Donde α y β son las probabilidades de cada estado y

α² + β² = 1

Como puede observarse fácilmente, la cantidad de números posibles de representar con n qubits es la misma que con n bits, es decir 2n. Sin embargo, lo disruptivo del modelo es que en computación clásica, con n bits, se puede representar sólo “un” estado dentro de los 2n posibles. En cambio con n qbits, por el principio de superposición, se pueden representar “todos” los 2n estados posibles a la vez.

 

Propiedades cuánticas

Superposición

Es la habilidad de un sistema cuántico de estar en múltiples estados a la vez, hasta tanto sea medido cuando la superposición se destruye. Para los que lo recuerdan de cuando lo estudiaron en física, este efecto es el que se explica con el gato de Schroedinger, que mientras el gato está dentro de la valija está vivo y muerto a la vez, hasta el momento de abrir la caja…

Entrelazamiento (Entanglement)

Propiedad por la cual dos partículas de energía o materia se correlacionan entre sí de modo que es posible predecir lo que va a hacer una si se interactúa con la otra. Esto ocurre sin importar la distancia que las separe.

Decoherencia

Pérdida de información de los qubits debido a su interacción con el medio ambiente. Si bien es una propiedad, corresponde a una vulnerabilidad para la computación cuántica y los equipos que desarrollan computadoras cuánticas trabajan constantemente para minimizarla.

 

En la segunda parte, hablaremos de los sistemas de procesamiento cuántico.

 

 

Jugando con Qubits (parte 2) >

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Cada vez más cerca

Cada vez más cerca

Un informe publicado el día de hoy, señala que es posible para un atacante alterar datos de sensores en aviones, que podrían desencadenar en desastres aéreos.

El informe de la empresa Rapid7, presenta el resultado del análisis de investigadores de dicha empresa sobre dos implementaciones de redes CAN populares en el mercado.

El bus de redes CAN (Controller Area Network) en un avión, es un medio de transmisión de datos donde viaja la información de todos los sensores del avión. Estos sensores miden parámetros físicos vitales para la operación de la aeronave, tales como los datos de parámetros del motor, o del mismo avión como: actitud, altitud, dirección, etc. Esa información se envía por un bus CAN hacia los diferentes sistemas y panel de instrumentos de la cabina del avión.

Es evidente que los pilotos necesitan esa información para navegar. En medio de la noche y a 10 mil metros de altura, el piloto no tiene idea de si está a 10 mil, 11 mil u 8 mil metros y si se está dirigiendo al Norte o al Nor-Noroeste si no fuera por sus instrumentos.

¿Qué pasaría entonces, si alguien pudiese alterar esa información?, ¿si alguien pudiera hacer que los instrumentos indiquen que está a 8 mil metros cuando en realidad está a sólo mil…? ¿..y con el avión descendiendo..?

Bueno, los investigadores descubrieron que esto es posible, al menos en aviones pequeños. Sin embargo, los buses CAN o variantes de ésta tecnología se utilizan también en aviones grandes y hasta en la industria automotriz. La popularidad de este sistema se debe a su bajo costo. En los buses CAN, TODOS los mensajes se transmiten por el mismo bus desde todos los sensores hacia todos los endpoints.  Esta característica es barata, pero como ya se habrán dado cuenta, no demasiado segura… En algunos casos se utiliza autenticación de mensajes, pero que puede saltearse fácilmente.

Otra condición para que un ataque de este tipo sea “existoso”, es que el atacante tenga acceso físico al avión…. (como por ejemplo… ¿¿¿un pasajero..???).

Por un lado, ya alguna vez hablamos sobre los pobres sistemas de seguridad que poseen las aerolíneas en sus sistemas de gestión de pasajes (1, 2). Por el otro, ya hace algunos años algunos investigadores descubrieron que los sistemas de entretenimiento de los aviones comerciales eran vulnerables. Uno de los defectos de seguridad de estos sistemas es que los dispositivos USB de los sistemas de entretenimiento, permiten conectar dispositivos como teclados o mice que son reconocidos por los sistemas. De esta forma, es posible interactuar tanto con las aplicaciones, como con los sistemas operativos.

Aquí se puede ver un ejemplo de cómo salir de la pantalla de control de un sistema de entretenimiento de un avión de una aerolínea internacional muy importante, simplemente conectando un teclado y probando diferentes combinaciones de teclas:

La pregunta entonces, es: ¿cuánto puede demorar alguien en saltar del sistema de entretenimiento a una red CAN y producir un desastre aéreo?

Tan grave fue el resultado de esta investigación y del informe publicado hoy, que el mismo US-CERT publicó hoy mismo una alerta en su página sobre infraestructuras críticas.

No por nada se están creando desde hace poco más de un año empresas de ciberseguridad que dedicarán sólo a desarrollar soluciones tendientes a mitigar potenciales ciberataques sobre aeronaves.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.