jueves, 27 de junio de 2019

La importancia del software libre incluso en computación cuántica

Cuando hablamos de computación cuántica y de cómo ésta puede ayudar al cifrado de comunicaciones trayendo una seguridad que, por puras características físicas, va a estar rozando el 100%; se nos olvida una parte fundamental como es el cómo se ha desarrollado o cómo se van a desarrollar todo este sistema. Es decir, demandar que se nos aporte un plan sobre cómo se van a desarrollar de forma completa estos sistemas informáticos cuánticos, pues, de no hacerlo, podríamos estar creando los sistemas más inseguros que hayamos visto jamás.


Parece que nos ponemos un poco paranoicos, pero es de vital importancia que los sistemas informáticos que utilicen computación cuántica se basen en software libre, de lo contrario estaremos expuestos.

Voy a ir explicando brevemente cada uno de los métodos que tenemos de comunicarnos con otro equipo.

Podemos, por ejemplo, enviar un mensaje (un correo electrónico por ejemplo) sin cifrar, por lo que cualquiera que capture el mensaje podría leerlo sin muchos problemas. Necesitamos algo más.

Para esto sacamos el cifrado para hacer más seguras nuestra comunicaciones.Este mecanismo funciona, de manera muy reducida de la siguiente forma:

Tenemos a Manu y a Rubén (a la mierda Bob y Alice). Cada uno genera su par de claves (privada y pública). Si Rubén quiere mandar un correo cifrado a Manu lo que tiene que hacer previamente es preguntarle a Manu cuál es su clave pública. Manu, que es un geek, ha añadido su clave pública a un servidor de claves y le dice a Rubén que en su cuenta de Twitter, en la biografía, tiene su clave.



Rubén sabe que, cuando cifre el correo con la clave pública de Manu, sólo Manu (quien posee la clave privada) podrá descifrarlo. Esto es perfecto ¿problemas?




Estos accesos a los sistemas informáticas podría provocar que, una vez dentro, el atacante busque claves privadas y se las pase a su equipo, por lo que toda la privacidad de los correos se habría roto por terceras vías.

Pero esto es en caso de ataque ¿y si pierdes o te roban el usb que llevas siempre encima con tu clave privada? Volvería a ocurrir lo mismo, la privacidad estaría rota.

Vamos más allá. Ahora tenemos un One Time Pad. Básicamente es como "un cuaderno" en el que en cada página tenemos muchos números que nos servirán de claves de cifrado. Si no conocéis bien este sistema, podéis utilizar de referencia este vídeo de Khan Academy. Pero ¿hay problemas con este mecanismo? Sí, 2 problemas esenciales:

El primero es la fuerza bruta. Un atacante podría ir probando números hasta dar con los números correctos. Es verdad que podría ser extremadamente largo, pero también recordemos que no tendríamos que hacer mucho trabajo, pues con lanzar un script y que este se ponga a trabajar en ello hasta que lo saque nos bastaría, no tendríamos tampoco que prestarle atención.

El segundo problema sería en caso de pérdida del One Time Pad, algo que es evidentemente malo per se.

Llegamos a la computación cuántica, lo que nos permitiría una mayor seguridad. Veamos cómo funciona ésta y utilizando este paper de referencia.

Tenemos unos bits cualesquiera que escribimos en q-bits (bits cuánticos). Para hacer esto tiene que decidir en qué eje lo escribe, en el "x" o en "z".




Por ejemplo, si tiene un 0 en el eje "x", eso apuntará, por ejemplo, a la izquierda y si tiene un 1 en el mismo eje, a la izquierda. Si tiene un 0 en el eje "z", eso apuntará abajo y si tiene un 1 en el mismo eje, apuntará arriba. Este es el convenio que vamos a seguir, aunque podría ser cualquier otro.

Con estos valores y su eje, se procederá a anotarlos en una "tabla de resultados" o base de datos. Así pues, yo, que quiero comunicarme con Rubén, elaboro una cadena lo suficientemente grande de q-bits con sus 4 valores posibles y se los mando. Rubén, conforme los reciba tendrá que elegir en qué eje los va a medir, si en el X o en el Z. Si, por ejemplo, el primer qbit que le mande es un 0 en el eje X (apunta a la izquierda) y Rubén decide medir en el eje Z, entonces, destruirá el estado cuántico y la función de onda colapsará en un 50% de probabilidades de que salga un 0 en el eje Z y otro 50% de probabilidad de que salga un 1 en el eje Z. Si por otro lado, Rubén decide medir en el eje X, acertará y verá, al 100% de probabilidad, un 0, que es lo que yo le mandé inicialmente. Todos estos resultados con su eje, Rubén se los va anotando en otra tabla de resultados o base de datos.

Una vez que Rubén termina de hacer esto y de pasar los ejes y los resultados que ha obtenido por cada q-bit que le mandé, hace públicos los ejes en los que ha medido. Ojo, sólo los ejes, no el resultado.  Esto Rubén lo hace para que yo lo vea y publique con él la misma tabla con los ejes en los que escribí valores a los q-bits. Con estas 2 tablas, comparamos resultados y eliminamos los que no coincidan.

Podemos eliminar estos resultados porque si mando un 1 en el eje Z, pero Rubén mide en el X, tiene un 50-50 % de probabilidades de que el valor sea 0 ó 1, por lo que, en realidad, no se ha pasado ninguna información. Sin embargo, los casos en los que ambos coincidan con el eje medido, coincidirán con el resultado.

Imaginemos que hemos enviado 10 q-bits, pues Rubén, por pura estadística, ha podido acercar un 50% de las veces, es decir, 5 q-bits. Una vez que hemos eliminado resultados que no coincidan, pido a Rubén que esta vez publique los valores y los ejes de los, por ejemplo, q-bits del 1 al 3. Cuando lo haga, lo que me tocaría a mí sería analizar los valores y, en teoría, deberían coincidir SIEMPRE.

¿Hay algún pero? Sí, que podría ser que vea valores distintos para el mismo eje medido, algo que no es lógico. Las causas de esto que podría pasar sería por la propia conexión, la red, la preparación del q-bit, el aparto de medida de Rubén...o que hay una persona en medio de la conexión capturando el tráfico de q-bits. Vamos a analizar este caso un poco más.

Pongamos que elaboro un q.bit cuyo valor en el eje Z es un 1. Yo lo mando, pero en medio de la conexión hay un atacante que captura ese q--bit ¿Qué hace? Pues como no conoce el estado inicial del q-bit, tendrá que medir en el eje X o en el eje Z. Pongamos que mide en el eje Z. No pasa nada, acierta y mide un 1, vuelva a mandar el q-bit a Rubén y aquí nada ha pasado. Nadie puede sospechar nada. Pero el problema está en si mide en el eje X, pues el estado anterior del q-bit se destruirá y, de forma random, se asignará, para el eje X un valor que será 0 ó 1. Para nuestro ejemplo, pongamos un 0. El atacante envía de nuevo a Rubén el q-bit, puesto que no sabe si quiera si ha acertado o no. 

Cuando Rubén recibe el q-bit modificado ya, si lo mide en el eje X no pasará nada, medirá un 0 que es el valor que se ha asignado al medirlo el atacante y, al no ser el mismo eje que el que yo le mandé inicialmente, cuando comparemos resultados eliminaremos ese caso sin darnos cuenta que hay una persona en medio de la conexión...pero el problema es como a Rubén le de por medir en el eje Z, entonces, ya no colapsará con un 100% de probabilidad en el 1 (valor inicial), sino que tendrá un 50% que sea un 1 y un 50% de que sea un 0. Esto para el atacante es un problema, pues cuando comparemos los ejes, lo daremos por bueno y cuando, posteriormente, analicemos los valores, si medimos otro valor que no sea un 1, saltarán las alarmas.

Podréis pensar que el atacante tiene un 25% de probabilidades de ser pillado. Y es verdad, pero esa probabilidad es para un sólo q-bit, no para toda la cadena. Conforme más q-bits se manden, más probabilidades de ser pillada existen. Si tan sólo pido de comprobar el valor y el eje medido por Rubén de 10 q-bits, esa probabilidad de pillar a un atacante asciende a un 95%, y con 50 q-bits analizados, la probabilidad es del 99.9999%. No está mal.

Por lo tanto, con una gran probabilidad, podremos pillar a un atacante y, si pedimos 50 q-bits para analizar de muestra y vemos que todos coinciden, entonces decimos a Rubén algo como:

"Oye, los 50 q-bits analizados que HEMOS HECHO PÚBLICOS son correctos, los demás que NO SON PÚBLICOS (son privados) los puedes utilizar a modo de clave."

Estos valores binarios los pasamos a decimal y ahí tenemos, por ejemplo, una página del One Time Pad. Esto, para automatizarlo, pues es un gran trabajo, lo podemos hacer con máquinas y sistemas especializados, de hecho ya hay algunos a la venta y en España donde se puede comprar algunos de estos es en Barcelona.

Pues perfecto, estos sistemas son seguros casi al 100%, vamos a utilizarlos ya...¿no? Pues NO. Hay un problema, el problema de siempre ¿Cómo se desarrollan estos sistemas? ¿Qué software utiliza? y lo más importante ¿Permite las 4+1 libertades básicas del usuario? Es decir ¿Son soluciones basadas en Software libre? Me explico más detalladamente.

De acuerdo, este procedimiento es bastante más seguro, pero cuando se genera la clave, ésta debe almacenarse ¿Cómo lo hace? Y ¿Cómo sabemos que estos sistemas o software de automatización solamente generan claves y no, por ejemplo, las mandan a otros servidores? Aquí está el problema.


¿Cómo sabemos que estas claves no se mandan a, por ejemplo, servidores gubernamentales para espiar a ciudadanos? Y ojo que este envío lo podrían hacer también con cifrado cuántico, por lo que nos sería imposible de saber qué han enviado.

Pues todo esto no podríamos saberlo si no es con software libre. Detectar esta backdoor intencional solamente podríamos detectarla si vemos el código, sino o no la veremos nunca o con el paso del tiempo al ver mejor su funcionamiento podríamos empezar a darnos cuenta.

Por esta razón es importante que, si se desarrollan estos sistemas (los cuales veo necesarios) que se hagan con software libre, de lo contrario podríamos estar creando los sistemas más inseguros nunca vistos.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...