Blind Quantum Computing (y 4)

Con esta parte damos por finalizado este artículo que recoge el Trabajo de Fin De Curso del Curso de Especialización en Quantum y Post-Quantum Computing para Ciberseguridad - que tendrá una nueva edición en el mes de Noviembre de este año. Vamos a concluirlo tras lo que se ha tratado en la primera, segunda parte de este artículo y tercera parte dedicadas a las tecnologías de Blind Quantum Computing, pensadas para dotar a la Computación Cuántica como Servicio  (Quantum Computing as a Service "QCaaS") de un entorno de privacidad sobre el algoritmo que se ejecuta en un Quantum Computer en la "nube".

Figura 21: Blind Quantum Computing (y 4)

En esta parte vamos a recoger algunas conclusiones de todo lo que se ha visto hasta el momento, así como recopilar las referencias para todos aquellos que deseéis profundizar sobre las tecnologías que hemos ido hablando en las secciones anteriores.

11. Conclusión: BQC como límite criptográfico de la computación cuántica delegada

La Computación Cuántica avanza hacia un modelo donde gran parte de los usuarios accederán al hardware a través de servicios cloud. En este escenario, la seguridad ya no consiste únicamente en proteger los datos o las comunicaciones, sino también en proteger la propia computación.

Las soluciones actuales basadas en PQC y TEE representan una respuesta práctica, madura y necesaria para los servicios QCaaS de hoy. Sin embargo, siguen apoyándose en un cierto grado de confianza en el proveedor que opera la infraestructura.

Figura 22: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

 
Blind Quantum Computing propone un enfoque distinto. No intenta simplemente ocultar los datos, sino que persigue algo mucho más ambicioso: permitir que un servidor cuántico ejecute una computación sin conocer realmente qué está computando.

Figura 23: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

Aunque su adopción masiva todavía parece lejana, BQC ya ha conseguido algo importante, que es demostrar que la privacidad de la computación cuántica delegada puede abordarse desde los propios principios de la mecánica cuántica.

Figura 24: Privacidad por capas en Computación Cuántica

Quizás el valor más relevante de BQC no sea resolver los problemas de los servicios QCaaS actuales, sino ayudarnos a responder a la pregunta que probablemente seguirá siendo fundamental en el Internet Cuántico y la computación cuántica distribuida del futuro:

¿Podemos utilizar recursos cuánticos remotos sin revelar qué estamos calculando?

Si la criptografía clásica nos enseñó a proteger nuestras comunicaciones, Blind Quantum Computing (BQC) nos invita a imaginar el siguiente paso:

 Un mundo donde no solo se protejan los datos, sino también la propia computación

12. Referencias y lecturas recomendadas

Quienes deseen profundizar en Blind Quantum Computing encontrarán una literatura creciente que abarca desde los protocolos fundacionales hasta implementaciones experimentales recientes sobre hardware cuántico real.

Figura 25: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

A continuación, se recopilan algunas referencias recomendables para continuar explorando este campo. Las referencias se han agrupado por temática para facilitar la profundización en aquellos aspectos que resulten de mayor interés.

Artículos fundacionales de BQC

• Universal Blind Quantum Computing (UBQC); A. Broadbent, J. Fitzsimons y E. Kashefi (2009). Considerado el trabajo fundacional de Blind Quantum Computing y punto de partida de gran parte de la investigación posterior. 

Figura 26: Universal Blind Quantum Computin

Verificación y experimentación reciente

• Verifiable Blind Quantum Computing with Trapped Ions and Single Photons: P. Drmota et al. (2023). Ejemplo de implementación experimental de protocolos BQC verificables sobre tecnologías cuánticas reales.

Figura 27: Verifiable Blind Quantum Computing with Trapped Ions and Single Photons

• Experimental Verifiable Multiclient Blind Quantum Computing on a QLine Architecture: B. Polacchi et al. (2025). Trabajo representativo de BQC multiusuario y computación cuántica distribuida.

Figura 28: Experimental Verifiable Multiclient Blind Quantum

Computing on a QLine Architecture

• On-Chip Verified Quantum Computation with an Ion-Trap QPU: C. Gustiani et al. (2025). Avances recientes en computación cuántica verificable sobre hardware experimental.

Computación cuántica basada en medidas (MBQC)

• Computación Cuántica Basada en Medidas (MBQC y BQC):  N. Tuñón TFG Universidad de Oviedo (2024).Recurso introductorio que permite comprender el modelo computacional que sirve de base a gran parte de los protocolos BQC modernos.

Figura 29: Simulation of Two-Qubit Grover's Algorithm in MBQC

with Universal Blind Quantum Computation

• Simulation of Two-Qubit Grover's Algorithm in MBQC with Universal Blind Quantum Computation: Y. Lee, D. Chung, (2025) Ejemplo práctico donde MBQC y UBQC se aplican a un algoritmo cuántico conocido.

Internet Cuántico y computación cuántica distribuida

• Multi-client Distributed Blind Quantum Computation with the QLine Architecture: B. Polacchi et al. (Nature Communications, 2023). Trabajo especialmente interesante para entender la evolución de BQC hacia escenarios de Internet Cuántico y computación cuántica distribuida.

Figura 30: Multi-Client Blind Quantum Computing (MC-BQC)

• Multi-agent Blind Quantum Computation without Universal Cluster States: Shuxiang Cao (2022) Referencia útil para profundizar en escenarios colaborativos y distribuidos.

Seguridad actual en QCaaS: PQC y TEE

• Post-Quantum Algorithms on ARM Trusted Execution Environment (TEE): Findings of this Industrial Challenge: E. Andrade, C. Coimbra Goes, J. Oliveira de Sousa (2024) Análisis práctico sobre la integración de algoritmos post-cuánticos en entornos de ejecución confiables. 

• PQC in TEE de Srinath Venkataramani (2025): Lectura introductoria sobre la complementariedad entre criptografía post-cuántica y Trusted Execution Environments.

Lecturas divulgativas recomendadas

• Privacidad en tiempos de computación en la nube: Computación cuántica delegada, privada y verificable: Alejandro Mata Ali (2025) Artículo divulgativo que introduce de forma accesible los conceptos fundamentales de computación cuántica delegada, verificable y privada.

Un saludo,

Autor: José Antonio Castellano Prado, Alumno del Curso de Quantum Security de la Universidad de Deusto

Contactar con José Antonio Castellano Prado

Otros artículos sobre Quantum Computing publicados:

• III edición del Programa de Especialización de Quantum y Post-Quantum Computing para Ciberseguridad: Noviembre 2026
• Libro de Quatum Security: Tecnología Cuántica & Ciberseguridad. Criptográfica Cuántica y Post-Cuántica. 
• Foro Público de Quantum Security de la Universidad de Deusto en MyPublicInbox
• Quantum Computing Cybersecurity Preparedness Act: Comienza la era de Ciberseguridad Post-Quantum en Estados Unidos
• Hamming Quasi-Cyclic (HQC-KEM): Nuevo Key-Encapsulation Mechanism en Post-Quantum Cryptography
• FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"
• La Gran Búsqueda de Números Primos de Mersenne en Internet para superar el mayor Número Primo conocido hasta la fecha
• Cómo acelerar los algoritmos de Inteligencia Artificial con Computadores Analógicos Ópticos (AOC)
• Premio Nobel en Física 2025: El trabajo del "Efecto Tunel" que trajo la cuántica a nuestro mundo y abrió la puerta a los ordenadores cuánticos
• Un Reloj Atómico Óptico del MIT con Optimización Cuántica para medir el Tiempo del Futuro
• Quantum Cryptography: Una comunicación con cifrado cuántico
• Factorización de RSA con un Optimizador de Quantum Computing (y Classic Computing)
• Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography
• Algoritmo Cuántico de Grover: Un algoritmo de búsqueda optimizado por superposición cuántica 
• Quantum Sensors: Cuando lo invisible se hace visible gracias al Mundo Cuántico
• Bitcoin vs Quantum Computers: Hora de pasar a Post-Quantum Cryptography
• El White Paper de MasterCard que urge a pasar a Quantum Safe: Post-Quantum Cryptography (PQC) & Quantum Key Distribution (QKD)
• Dyber: Hardware-Accelerated Post-Quantum Cryptography (PQC)
• Cómo ser Quantum Safe y desplegar Post-Quantum Cryptography (PQC) con Cloudflare
• Quantum GPS: Navegación con GPS cuánticos para evitar ataques de Jamming & Spoofing
• Cómo comprobar si un Web Site es Quantum Ready con Post-Quantum Cryptography usando Radar
• Alaniz Cipher: Un Cifrado Simétrico Quantum Resistant
• Los Papers Académicos de los algoritmos PQC de Autenticación y Firma Digital en la Ronda 3 del NIST
• Blind Quantum Computing (1) (2) (3) (4)

Blind Quantum Computing (3)

Llegados a este punto del artículo, tras lo que se ha tratado en la primera y segunda parte de este artículo, Blind Quantum Computing puede parecer la solución ideal para proteger la privacidad en los servicios de computación cuántica en la nube. Si un servidor puede ejecutar una computación sin conocer realmente qué está calculando, resulta natural preguntarse por qué esta tecnología no forma parte todavía de las plataformas comerciales de QCaaS.

Figura 17: Blind Quantum Computing (3)

En esta parte vamos a centrarnos justo en eso, en los problemas y limitaciones a los que se enfrentan las tecnologías de Blind Quantum Computing.

9.- Limitaciones actuales: por qué BQC aún no es una solución industrial

La respuesta es sencilla: 

BQC es una idea extraordinariamente potente desde el punto de vista teórico, pero enormemente exigente desde el punto de vista práctico. 

A diferencia de tecnologías como TLS, PQC o los Trusted Execution Environments (TEE), que pueden desplegarse sobre infraestructuras ya existentes, los protocolos BQC introducen requisitos adicionales que todavía resultan difíciles de satisfacer en entornos comerciales a gran escala.

El coste de ocultar la computación

Uno de los principales desafíos es que la privacidad no es gratuita. Para impedir que el servidor reconstruya el algoritmo, los protocolos BQC necesitan introducir información adicional, intercambiar mensajes entre cliente y servidor y ejecutar operaciones de corrección o verificación que no existirían en una computación cuántica convencional. Como consecuencia, el coste total de la ejecución suele aumentar en términos de:

• Comunicación entre cliente y servidor.
• Número de operaciones necesarias.
• Tiempo de ejecución.
• Complejidad del protocolo.

En otras palabras, cuanto mayor es el nivel de privacidad perseguido, mayor suele ser el sobrecoste asociado.

El cliente no siempre es completamente clásico

Otro aspecto relevante es que muchos protocolos BQC asumen que el cliente dispone de ciertas capacidades cuánticas mínimas. Aunque estas capacidades son muy inferiores a las del servidor, siguen representando una barrera práctica importante. En numerosos escenarios empresariales resulta mucho más sencillo asumir que el cliente dispone únicamente de recursos clásicos y delega toda la computación en el proveedor.

Figura 18: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

Precisamente por este motivo han aparecido variantes como Double-Server BQC, o nuevas líneas de investigación orientadas a reducir progresivamente las capacidades cuánticas necesarias en el extremo del cliente.

La realidad de la era NISQ

A estas dificultades se añade una limitación fundamental: 

El hardware cuántico actual sigue siendo imperfecto.

La mayoría de las plataformas comerciales operan todavía en la denominada era NISQ (Noisy Intermediate-Scale Quantum), caracterizada por la presencia de ruido, errores y limitaciones en el número de qubits utilizables.

Muchos protocolos BQC fueron diseñados inicialmente desde una perspectiva teórica, asumiendo condiciones que todavía resultan difíciles de reproducir de manera eficiente en dispositivos reales. Esto obliga a adaptar continuamente las propuestas a las restricciones impuestas por el hardware disponible.

Escalabilidad y despliegue industrial

Las plataformas QCaaS actuales deben prestar servicio a múltiples usuarios, optimizar recursos y mantener una operación estable y económicamente sostenible. En este contexto, la prioridad inmediata suele centrarse en mejorar aspectos como:

• La fidelidad de los qubits.
• La corrección de errores.
• La escalabilidad del hardware.
• La interoperabilidad con infraestructuras cloud existentes.

Frente a estos desafíos, BQC continúa siendo principalmente una línea de investigación especializada cuyo objetivo es explorar hasta dónde puede llegar la privacidad en la computación cuántica delegada.

Una tecnología adelantada a su tiempo

Esta situación no debe interpretarse como una debilidad de BQC. De hecho, muchas tecnologías que hoy consideramos esenciales comenzaron como propuestas teóricas aparentemente difíciles de implementar. La propia criptografía de clave pública es un buen ejemplo de ello.

En cierto modo, Blind Quantum Computing está recorriendo un camino similar. Actualmente no compite con PQC o TEE como solución industrial inmediata, sino que actúa como un laboratorio conceptual donde se exploran los límites de la privacidad en computación cuántica. Por eso, la pregunta relevante no es si BQC sustituirá mañana a las soluciones actuales, sino si algunas de sus ideas terminarán integrándose en las futuras infraestructuras de computación cuántica.

Figura 19: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Y para responder a esa cuestión resulta inevitable mirar hacia los escenarios que ya comienzan a perfilarse en el horizonte de la investigación cuántica, como son el Internet Cuántico y la Computación Cuántica Distribuida, donde privacidad, delegación segura y colaboración entre múltiples nodos podrían convertirse en requisitos tan importantes como la propia capacidad de cálculo.

10. ¿Qué papel podría tener BQC en el futuro Internet y Computación Cuántica Distribuida?

Hasta ahora hemos analizado Blind Quantum Computing desde la perspectiva de los servicios actuales de computación cuántica en la nube. Sin embargo, una parte importante del interés que despierta esta línea de investigación no está relacionada únicamente con el presente, sino con los escenarios que podrían surgir a medida que la tecnología cuántica continúe evolucionando. Entre ellos destaca uno especialmente ambicioso:

El desarrollo de un Internet Cuántico.

Aunque todavía se encuentra en una fase temprana de desarrollo, la idea general consiste en interconectar procesadores, memorias y dispositivos cuánticos mediante redes capaces de distribuir estados cuánticos y recursos de entrelazamiento entre múltiples nodos. Si esta visión llega a materializarse, el modelo actual de un usuario conectándose a un único proveedor de QCaaS podría evolucionar hacia entornos mucho más complejos, donde múltiples dispositivos y servicios cuánticos colaboren para resolver problemas de forma distribuida.

En ese contexto aparece otro concepto cada vez más relevante, como es la

Computación Cuántica Distribuida, 

cuyo objetivo es permitir que varios procesadores cuánticos, potencialmente ubicados en lugares distintos, cooperen para ejecutar una misma computación. Este enfoque podría convertirse en una alternativa al desarrollo de procesadores monolíticos cada vez más grandes, permitiendo combinar recursos cuánticos distribuidos a través de futuras redes cuánticas.

De la Computación Delegada a la Computación Distribuida

En un escenario de computación cuántica distribuida, la privacidad dejaría de ser únicamente un problema entre cliente y proveedor. Podrían intervenir múltiples actores:

• Diferentes nodos cuánticos.
• Servicios cuánticos especializados.
• Centros de procesamiento distribuidos.
• Usuarios colaborando en una misma computación.

La pregunta pasaría entonces de ser:

¿Cómo protejo una computación frente a un único proveedor?

a convertirse en:

¿Cómo protejo una computación cuando participa una red completa de sistemas cuánticos?

Es precisamente aquí donde muchas de las ideas desarrolladas en BQC comienzan a resultar especialmente interesantes. Protocolos como MC-BQC (Multi-Client Blind Quantum Computing) o algunas variantes basadas en Teleportación Cuántica ya exploran escenarios donde varias entidades participan en una computación manteniendo la privacidad de su información.

Figura 20: MC-BQC (Multi-Client Blind Quantum Computing)

Desde esta perspectiva, BQC deja de ser únicamente un mecanismo para proteger la privacidad frente a un proveedor de QCaaS. También podría convertirse en una pieza relevante para permitir colaboración segura entre múltiples nodos cuánticos, usuarios y servicios distribuidos dentro de una futura infraestructura cuántica global.

QKD protege las comunicaciones, BQC podría proteger la computación

Una forma sencilla de entender el posible papel de BQC es compararlo con una tecnología mucho más conocida: 

Quantum Key Distribution (QKD).

QKD se centra en proteger la distribución de claves y la confidencialidad de las comunicaciones. BQC persigue un objetivo diferente:

• QKD: protege los datos mientras se transmiten.
• BQC: protege la computación mientras se ejecuta.

Por este motivo, algunas visiones del futuro Internet Cuántico contemplan ambas tecnologías como piezas complementarias y no como alternativas. Puede resumirse de forma muy simple:

QKD + BQC = confidencialidad de las comunicaciones + confidencialidad de la computación. 

Naturalmente, este escenario todavía está lejos de convertirse en una realidad operativa, pero ilustra bien por qué BQC despierta tanto interés desde el punto de vista académico y de la investigación en seguridad.

Un posible paralelismo con la evolución de Internet

Existe además un paralelismo interesante con la evolución de Internet. Durante los primeros años de Internet, la principal preocupación era conseguir que los sistemas pudieran comunicarse entre sí. Con el tiempo aparecieron nuevos requisitos:

• Confidencialidad.
• Autenticación.
• Integridad.
• Privacidad.

Hoy resulta difícil imaginar Internet sin protocolos como TLS o sin mecanismos criptográficos ampliamente desplegados. Quizás algo similar ocurra en el ámbito cuántico.

Actualmente gran parte del esfuerzo se concentra en construir hardware más estable, aumentar el número de qubits lógicos y mejorar la corrección de errores. Sin embargo, a medida que estas barreras técnicas vayan superándose, las cuestiones relacionadas con la privacidad, la delegación segura y la confianza entre nodos podrían adquirir una relevancia cada vez mayor.

Mirando más allá del presente

Es imposible saber hoy qué protocolos concretos terminarán imponiéndose o si las formas actuales de BQC serán las que lleguen a utilizarse en sistemas reales. Lo que sí parece claro es que la pregunta que dio origen a Blind Quantum Computing seguirá siendo relevante:

¿Podemos utilizar recursos cuánticos remotos sin revelar completamente qué estamos calculando?

Responder a esa pregunta es, precisamente, lo que convierte a BQC en algo más que una curiosidad académica. Tal vez no sea todavía una tecnología preparada para el despliegue masivo, pero sí representa una de las ideas más interesantes que han surgido en la intersección entre computación cuántica, criptografía y privacidad.

Y quizás por eso, más que una solución para los servicios QCaaS actuales, Blind Quantum Computing deba entenderse como una referencia que nos permite explorar cuál podría ser el límite criptográfico de privacidad en la futura computación cuántica delegada, distribuida e interconectada.

Continúa en la última parte: Blind Quantum Computing (y 4)

Un saludo,

Autor: José Antonio Castellano Prado, Alumno del Curso de Quantum Security de la Universidad de Deusto

Contactar con José Antonio Castellano Prado

Otros artículos sobre Quantum Computing publicados:

• Libro de Quatum Security: Tecnología Cuántica & Ciberseguridad. Criptográfica Cuántica y Post-Cuántica. 
• Foro Público de Quantum Security de la Universidad de Deusto en MyPublicInbox
• Quantum Computing Cybersecurity Preparedness Act: Comienza la era de Ciberseguridad Post-Quantum en Estados Unidos
• Hamming Quasi-Cyclic (HQC-KEM): Nuevo Key-Encapsulation Mechanism en Post-Quantum Cryptography
• FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"
• La Gran Búsqueda de Números Primos de Mersenne en Internet para superar el mayor Número Primo conocido hasta la fecha
• Cómo acelerar los algoritmos de Inteligencia Artificial con Computadores Analógicos Ópticos (AOC)
• Premio Nobel en Física 2025: El trabajo del "Efecto Tunel" que trajo la cuántica a nuestro mundo y abrió la puerta a los ordenadores cuánticos
• Un Reloj Atómico Óptico del MIT con Optimización Cuántica para medir el Tiempo del Futuro
• Quantum Cryptography: Una comunicación con cifrado cuántico
• Factorización de RSA con un Optimizador de Quantum Computing (y Classic Computing)
• Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography
• Algoritmo Cuántico de Grover: Un algoritmo de búsqueda optimizado por superposición cuántica 
• Quantum Sensors: Cuando lo invisible se hace visible gracias al Mundo Cuántico
• Bitcoin vs Quantum Computers: Hora de pasar a Post-Quantum Cryptography
• El White Paper de MasterCard que urge a pasar a Quantum Safe: Post-Quantum Cryptography (PQC) & Quantum Key Distribution (QKD)
• Dyber: Hardware-Accelerated Post-Quantum Cryptography (PQC)
• Cómo ser Quantum Safe y desplegar Post-Quantum Cryptography (PQC) con Cloudflare
• Quantum GPS: Navegación con GPS cuánticos para evitar ataques de Jamming & Spoofing
• Cómo comprobar si un Web Site es Quantum Ready con Post-Quantum Cryptography usando Radar
• Alaniz Cipher: Un Cifrado Simétrico Quantum Resistant
• Los Papers Académicos de los algoritmos PQC de Autenticación y Firma Digital en la Ronda 3 del NIST
• Blind Quantum Computing (1)
• Blind Quantum Computing (2)
• Blind Quantum Computing (3)
• Blind Quantum Computing (4)

Cómo funciona LavaRand para generar Cryptographically-Secure Pseudorandom Numbers con Lámparas de Lava en las oficinas de Cloudflare

Esta es una historia antigua, que comienza en el siglo pasado, pero como muchos me siguen preguntando por ello, voy a dedicarle un artículo para los que no conocen la historia de los Cloudflare LavaRamp, o los muros de Lámparas de Lava que hay en algunas oficinas de Cloudflare por el mundo.

Figura 1: Cómo funciona LavaRand para generar

Cryptographically-Secure Pseudorandom Numbers

con Lámparas de Lava en las oficinas de Cloudflare

Para contar cómo funcionan, debemos irnos al año 1996, cuando la empresa Silicon Graphics solicitó la patente US5732138A con el título: "Method for seeding a pseudo-random number generator with a cryptographic hash of a digitization of a chaotic system" donde se describe en detalle el funcionamiento del sistema LavaRand, para crear un Cryptographically-Secure Pseudorandom Number Generator (CSPNG).

Figura 2: Method for seeding a pseudo-random number generator

with a cryptographic hash of a digitization of a chaotic system

La patente, que ya no está activa, describe un mecanismo para generar estos números critográficamente-seguros pseudo-aleatorios, a partir de un estado concreto en el tiempo de un sistema caótico. Ese sistema caótico, debe tener un fuente de datos con mucha entropía para que los números que salgan de la generación no sean predecibles bajo ningún factor de sesgo.

Figura 3: Esquema de generación de número

pseudo-aleatorios a partir un sistema caótico.

La entropía mide el grado de incertidumbre en el valor de un determinado bit a la hora de sacar un valor aleatorio. Es decir, si tenemos una lista de bits, la probabilidad de que cada bit sea 1 o sea 0 debería ser del 50% sin que dependa de ningún dato o factor externo que pudiera sesgarlo. En la patente, se busca un sistema caótico que no sea predecible - o díficilmente predecible - por lo que su entropía debe ser muy alta, y es ahí donde entran las Lámparas de Lava.

Figura 4: Secuencias del sistema caótico formado por lámparas de lava

La idea es que si tenemos una serie de Lámparas de Lava, y hacemos una instantánea temporal en forma de fotografía, tendremos siempre formas diferentes con alta incertidumbre de predicción. Lo que sirve como fuente de generación de valores con alta entropía. La forma de llevar esta fuente de entropía al sistema es tan sencillo como tener un "Wall of Lava Lamps" y tomar una fotografía de ellas.

Figura 5: Lava Lamp Wall de Cloudflare

Esto lo implementa Cloudflare en varias oficinas, donde se pueden ver los "Lava Lamp Wall" de diferentes colores, y cada una de ellas generando diferentes composiciones en las fotografías. Es decir, cada fotografía tomada en un instante de tiempo tiene una secuencia de colores única, que traducida a una secuencia de bits, es de alta entropía.

Figura 6: Transformación de los píxeles a secuencias binárias

Las imágenes, como podéis ver en la explicación técnica que se hizo en el blog de Cloudflare, es el inicio del sistema de generación de los números pseudo-aleatorios criptográficamente seguros que se utilizan después en las plataforma de Cloudflare.

Figura 7: Proceso de generación de CSPNs

Como podéis ver en la imagen anterior, el "Lava Lamp Wall" no es el único factor de entropía con el que se va mezclando, ya que las imágenes generan una fuente de datos de entrada con una función de entropía basada en los píxeles de colores, pero esta es mezclada también con otras fuentes de entropía para generar claves criptográficas lo más seguras posibles.

Figura 8: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

En este caso, después de la entropía que se genera con las imágenes de las lámparas, se usan datos con más entropía provenientes del sensor de movimiento de la cámara, de los generados por el servidor que controla la cámara - que tiene sus propios números aleatorios generados con su factor de entropía - y son mezclados con la fuente de números aleatorios del servidor donde corre el servicio de LavaRand, lo que permite que los consumidores de estos números aleatorios tengan la garantía de que llevan un alto nivel de entropía.

Figura 9: Imagen de un Lava Lamp Wall capturado por la cámara Hi-Res

Por supuesto, las imágenes con Lamparas de Lava se pueden sustituir por otro tipo de imágenes, y en la oficina de Cloudflare en Lisboa, estas han sido cambiadas por Water Waves, para honrar al sistema con la conexión que Lisboa tiene con el agua, vía río y mar.

Figura 10: Muro de olas de mar

El funcionamiento es similar, y puedes verlo en este vídeo que está publicado en Youtube. Yo subí un pequeño vídeo de unos segundos a mi cuenta de Instagram que puedes ver aquí mismo. 

Ver esta publicación en Instagram

Una publicación compartida de Chema Alonso (@chemaalonso)

Figura 11: Generando entropía para tener números aleatorios robustos 

Por supuesto, desde que tenemos los Quantum-Based Random Number Generators donde se utilizan fotones y mediciones de valores cuánticos, tenemos fuentes de altísima entropía para generar números aleatorios, pero la historia de LavaRand es un ejemplo de cómo tener tus propias fuentes de entropía utilizadas para enriquecer, aún más, cualquier generador de números aleatorios que utilices, incluso los QRND.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

TicketBleed: Un "Heartbleed" para los productos F5 BIG-IP

El nombre de esta vulnerabilidad que ha sido publicada esta semana tiene claras reminiscencias, claramente, al ya famoso Heartbleed (al que le dediqué un capítulo en el libro de Hacking Web Technologies). De hecho, tiene mucho que ver, aunque a menor escala, ya que en lugar de conseguir un volcado de 64 Kas de memoria, se consigue el volcado de 31 bytes de memoria aleatoria en cada petición, lo que lo hace menos efectivo. Además, F5 TLS solo está presente en los productos de F5 BIG-IP, y la versión vulnerable no en todos. No obstante, el bug es peligroso y debe parchearse cuanto antes.

Figura 1: TicketBleed: Un "Heartbleed" para los productos F5 BIG-IP

El fallo de TicketBleed reside en la implementación que hace el software de F5 TLS en las reconexiones rápidas de sesiones TLS, debido a cómo gestiona el código del producto los Session ID y los Session Tickets cuando se intenta reutilizar una sesión TLS anterior. La idea es bastante sencilla, y tiene que ver con mejorar el rendimiento de los sistemas criptográficos en la web. Os lo intento explicar resumidamente para que entendáis el bug. Si queréis más detalles, la lectura obligatoria es el libro de Cifrado de las Comunicaciones Digitales.

Figura 2: TicketBleed (CVE-2016-9244)

El protocolo TLS tiene un impacto en el rendimiento de los protocolos que se tunelicen sobre él por culpa de los algoritmos criptográficos que añaden privacidad a la comunicación. Estos son especialmente costosos en la fase de negociación inicial de las claves y menos costosos luego en el cifrado y descifrado de paquetes una vez que ya ha quedado establecida la negociación inicial - el famoso saludo -.

TLS Resumption in a nutshell

Como sobre el protocolo TLS pueden ir protocolos no orientados a conexión, es decir, que no mantienen sesiones vivas sino que realizan peticiones discretas y arrítmicas - como visitar una web, leer durante unos minutos una noticia y hacer clic en un link que navega a otra página dentro del mismo servidor - en los protocolos de cifrado se creo el concepto de reconexión rápida, es decir, re-aprovechar la fase inicial de una negociación TLS que no haya caducado para mejorar la velocidad. 

Figura 3: RFC 5077 TLS Session Resumption withos Server-Side State

En el estándar RFC 5077 se especifica que esta es una característica que debe tener soportada el servidor y que para ello el cliente debe enviar el Session ID y el Session Ticket, es decir, el identificador de la sesión que se quiere recuperar y la información necesaria para recuperarla. 

Figura 4: Especificación de gestión del SessionID

El servidor deberá devolver el mismo SessionID al cliente si se puede reutilizar esta sesión, por lo que cuando el cliente pide una reconexión debe enviar un SessionID y un SessionTicket. El servidor comprueba que el SessionID no está vacío y que es válido, por lo que devuelve una sesión con el mismo SessionID que copia directamente desde el SessionID que envía el cliente.

Y aquí está el problema.

La longitud del SessionID puede ser de 32 bytes, pero puede ser también solo de 1 byte. Si un cliente crea una conexión con un SessionID de 1 byte de longitud y el el servidor TLS copia 32 bytes de la memoria donde está el SessionID que ha recibido del cliente copiado, lo que contendrá el SessionID que se envía desde el servidor será 1 byte con el SessionID que envió el cliente, más 31 bytes de la memoria del servidor, en concreto de la memoria que utiliza el proceso TLS, por lo que puede venir cualquier cosa, como en el caso de HeartBleed.

Figura 5: Código vulnerable en F5 TLS

Por supuesto, cada petición solo "leakea" 31 bytes, pero si son los de una contraseña, un id o cualquier otra información sensible, el impacto puede ser muy alto. Además, como en el caso de HeartBlead, se puede poner un cliente a forzar el volcado de estos 31 bytes durante días y ver qué ha ido cayendo en el canasto, que seguro que habrá algo jugoso.

Figura 6: Test de TicketBleed y script en Go para probarlo tú mismo

El investigador Filippo Valsorda ha puesto un sitio en la web para que puedas comprobar si un servidor de F5 BIG-IP tiene este software F5 TLS vulnerable a TicketBleed o no. Nosotros lo hemos añadido a nuestro sistema de pentesting persistente Faast, pero si tienes equipos F5 BIG-IP deberías asegurarte que tienes todo actualizado a la última versión.

Saludos Malignos!

DROWN Attack: Descifrar HTTPs TLS por bugs en SSLv2

Coincidiendo con el 1 de Marzo y la RSA Conference, tenemos un nuevo ataque criptográfico a HTTPs al que se le ha puesto un nombre llamativo. En este caso The DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) Attack que viene a afectar a aproximadamente una tercera parte de los servidores HTTPs en Internet.

Figura 1: The Drown Attack

El ataque se describe en el paper que han publicado en el sitio, pero básicamente lo que hacen es aprovecharse de que un servidor permita conexiones SSLv2 inseguras y conexiones TLS para capturar las sesiones TLS y descifrar las claves RSA que se usan en la conexión TLS mediante el ataque a SSLv2. Es decir, tal y como dice el paper necesitan capturar unas 1.000 sesiones TLS utilizando intercambios de claves RSA, después hacer unas 40.000 conexiones SSLv2 y realizar 2 elevado a 50 operaciones de cifrado simétrico para descifrar 1 sesión TLS. Pero si el premio es gordo, hay que ir a por ello.

Figura 2: Resumen del proceso de ruptura de 1 sesión TLS

Los servidores vulnerables son los que permitan ambos protocolos, es decir, TLS y SSLv2, además de aquellos que comparten claves públicas en frontales y alguno de ellos soporta SSLv2. En la web han publicado una herramienta para comprobar si tu sitio es vulnerable o no.

Figura 3: Sitios vulnerables a DROWN

En la siguiente lista tenéis, por ejemplo, sitios de microsoft.com vulnerables a DROWN. Como veis a este bug le han asignado el CVE-2016-0703. Nosotros hemos añadido esta comprobación a la lista de plugins de nuestro motor de Faast para que puedas erradicar estos protocolos inseguros lo antes posible.

Figura 4: Sitios de microsoft con vulnerabilidad DROWN

El paper que describe el proceso de explotación paso por paso lo tienes en la web de The Drown Attack, puro para amantes de criptografía, por lo que si quieres entender bien RSA te recomiendo que leas el libro de Cifrado de las comunicaciones digitales.

Saludos Malignos!

¿Por qué sale el candado rojo en los mensajes de Gmail?

Supongo que muchos ya estaréis al día de que Gmail ha añadido una nueva función para mejorar la información sobre los mensajes de correo electrónico que recibe de forma insegura. Si todavía no has visto ninguno, te recomiendo que vayas a la carpeta de Spam de tu cuenta de Gmail y busques por allí, verás que hay más de uno seguro que tiene el candadito rojo de correo inseguro.

Figura 1: ¿Por qué sale el candado rojo en los mensajes de Gmail?

Ese candado rojo abierto al lado del mensaje significa que la conexión que el servidor de correo saliente del dominio del remitente hizo con el servidor de correo entrante de Gmail no se hizo sobre un túnel TLS o SSL. Es decir, cuando se entregó ese mensaje de correo electrónico a Gmail para que lo pusiera en tu buzón, se hizo por el puerto 25 sin cifrado alguno, por lo que cualquiera que pudiera esnifar el tráfico de la red en medio podría haberlo leído.

Figura 2: Mensaje enviado por SMTP sin cifrado puerto 25

Esto lo tienes explicado en la página de soporte que ha añadido Google en su knowledge base, y no hay mucho que puedas hacer a nivel de usuario para que tus correos electrónicos lleguen sin candado, ya que es algo de configuración del servidor de correo electrónico que utilizas para enviar los mensajes.

Figura 3: Explicación de Google sobre el candado rojo

Si cuando envías un mensaje de correo electrónico llega a las cuentas de Gmail con el candado, entonces es que tu servidor de correo electrónico no has configurado el servidor SMTP de correo saliente para que envíe todo el tráfico cifrado.

Figura 4: Información sobre los puertos con cifrado en Gmail para SMTP

Para ello, debes hablar con tu proveedor, o si gestionas tú el servidor de correo electrónico activar la opción de conexión TLS o SSL por los puertos 25 o 465 con SSL yo 587 con TLS. Ojo, si tu cuenta es de Gmail, actívalo si tus mensajes llegan con ese candado, que podría ser que hubieras configurado tu cliente de correo electrónico con SMTP en lugar de IMAP.

Figura 5: Conexión a tu buzón usando IMAP con SSL para enviar y recibir e-mails

Por supuesto, esto no garantiza que el correo electrónico no haya podido ser interceptado por alguien en medio que haga un ataque de man in the middle con capacidad de tener certificados emitidos a nombre de los servidores de correo electrónico, tal y como se explicaba en este gráfico de servilleta que apareció en uno de los documentos filtrados por Edward Snowden.

Figura 6: Explicación de Muscular de la NSA para espiar Gmail

Si no hay un proceso de Certificate Pinning entre los servidores de correo electrónico saliente y servidor de correo entrante, entonces el atacante podría dar al servidor de correo saliente un certificado falso emitido por una entidad certificadora controlada en la que confíe el servidor de correo saliente y descifrar los mensajes.

Figura 7: Correo de Gmail enviado sin cifrar

Gmail entre sus servidores utiliza autenticación mutua, pero si el servidor viene desde un servidor de correo saliente de tercero entonces solo hay conexiones SSL o TLS, pero no Mutual SSL o Mutual TLS, ya que para ello debería haber un intercambio de certificados entre ambos servidores a nivel de configuración.

Figura 8: Gmail permite las conexiones SMTP puerto 25 sin cifrado

Este es un esfuerzo más desde de Google por cifrar el tráfico de Internet y ayuda a evitar la interceptación de correos por parte de atacantes, pero desde luego, mientras que no haya Mutual TLS/SSL entre todos los servidores de correo electrónico, los estados podrán seguir espiando el correo como lo hacían antes y la única solución sigue siendo usar PGP o S/MIME para tener cifrado end-to-end, así que, el que no salga el candado no garantiza que nadie haya podido espiar ese mensaje desde que salió del cliente de correo electrónico del remitente. Si quieres saber más sobre criptografía, ya sabes que una lectura recomendable es el libro de Cifrado de las comunicaciones digitales.

Saludos Malignos!