Cifrado Homomórfico: El santo grial de procesar datos sin descifrarlos jamás

Un hospital quiere usar un modelo de inteligencia artificial alojado en la nube, pero necesita mantener privados los datos de sus pacientes. Cifrarlos durante el envío y al guardarlos resuelve parte del problema. En una aplicación convencional, el servidor termina descifrando las entradas para procesarlas: la protección se interrumpe justo cuando empieza el cálculo.

El cifrado homomórfico permite ejecutar ciertas operaciones directamente sobre los datos cifrados y obtener un resultado que también permanece cifrado. La nube aporta capacidad de cómputo sin recibir la clave secreta que abre las entradas.

En el artículo sobre pruebas de cero conocimiento exploramos cómo demostrar una afirmación sin revelar el secreto que la respalda. Ahora avanzamos hacia otra pregunta: ¿cómo delegar un cálculo sin entregar los datos con los que se hace?

Recorrido del artículo

1. La propiedad matemática y el viaje de los datos
2. Paillier: multiplicar cifrados para sumar mensajes
3. De operaciones parciales a FHE
4. Ruido, profundidad y bootstrapping
5. BFV, BGV, CKKS y TFHE
6. Cómo ejecutar un modelo de IA sin ver sus entradas
7. Salud y colaboración entre instituciones
8. Qué protege y cómo se complementa con ZKP
9. El costo y las decisiones de implementación

1. La propiedad matemática y el viaje de los datos

Un homomorfismo conserva una estructura al pasar de una representación a otra. En este contexto, ciertas operaciones en el espacio de los cifrados corresponden a operaciones sobre los mensajes originales. La descripción de FHE del NIST lo expresa mediante una función de evaluación:

pk es la clave pública para cifrar; sk, la clave secreta para descifrar; y evk representa las claves de evaluación que requiera el esquema. Eval ejecuta una versión homomórfica de la función f. En esquemas aproximados, la igualdad se reemplaza por una aproximación dentro de la precisión prevista.

1. El cliente genera las claves. Conserva la secreta en su entorno de confianza.
2. Cifra las entradas. Envía a la nube los cifrados, los parámetros públicos y las claves de evaluación necesarias.
3. La nube evalúa el circuito. Opera sobre esas representaciones sin recuperar los mensajes.
4. Devuelve una respuesta cifrada. El cliente la descifra y obtiene el resultado del cálculo.

Las claves de evaluación habilitan transformaciones como rotaciones o refrescos del cifrado. Están diseñadas para compartirse bajo los supuestos del esquema; no equivalen a entregar la clave secreta.

2. Paillier: multiplicar cifrados para sumar mensajes

Podemos ver la idea con Paillier, un esquema de cifrado aditivo. Su implementación en Charm-Crypto permite seguir la construcción. Para una elección habitual de parámetros, se toma n = p · q, con dos primos, y g = n + 1. Un mensaje m se cifra como:

El valor r se elige al azar entre los enteros invertibles módulo n. Al multiplicar dos cifrados, los exponentes que contienen los mensajes se suman:

El servidor multiplica números cifrados y el cliente recupera una suma. Eso no significa que multiplicar los mensajes originales sea también una operación disponible. La correspondencia depende del esquema.

Probalo: una suma que viaja cifrada

Mové los valores y observá qué números recibiría el servidor. Repetí el cifrado para cambiar sus representaciones sin cambiar la suma.

Entrada a: 12

Entrada b: 7

1 · Cliente cifrac₁ = 78803c₂ = 32969Envía c₁ y c₂.

2 · Nube calculac₁ × c₂ mod 104329c = 55349La respuesta sigue cifrada.

3 · Cliente descifra

12 + 7 = 19

Usa su clave secreta.

Repetir cifrado de los mismos valores

Paillier didáctico, sin seguridad real. Todo sucede en tu navegador; los roles están simulados y la clave está en el código. Usamos primos diminutos y una secuencia fija de valores r para reproducir el ejemplo. Un sistema real necesita parámetros seguros y aleatoriedad criptográfica fresca.

Ver parámetros y descifrado

p = 17; q = 19; n = 323; g = 324; n² = 104329. La clave secreta usa λ = mcm(16, 18) = 144 y μ = 83, el inverso de 144 módulo 323. Se calcula L(u) = (u − 1) / n y Dec(c) = L(c^λ mod n²) · μ mod n.

Primera pareja didáctica: r₁ = 2; r₂ = 5.

La suma se interpreta módulo n: si se excede el rango, el resultado vuelve a empezar desde cero. En la demo las entradas llegan hasta 40 y su suma queda por debajo de 323. Esta elección evita confundir el efecto modular con un error de descifrado.

3. De operaciones parciales a FHE

«Homomórfico» describe una propiedad, pero no todas sus variantes admiten los mismos programas:

• Parcialmente homomórfico (PHE): permite una familia limitada de operaciones, como las sumas de Paillier.
• Somewhat homomorphic (SHE): admite sumas y multiplicaciones, con capacidad limitada antes de perder corrección.
• Leveled homomorphic: se configura para una profundidad de circuito prevista, sin necesitar bootstrapping durante esa evaluación.
• Totalmente homomórfico (FHE): permite evaluar circuitos de profundidad arbitraria mediante los mecanismos adecuados, sujeto al tiempo y la memoria disponibles.

Sumar y multiplicar permite construir polinomios; las puertas booleanas universales permiten expresar cualquier cálculo finito. El desafío es sostener esas operaciones de forma segura y eficiente. El trabajo Fully Homomorphic Encryption over the Integers muestra cómo una construcción con capacidad limitada puede transformarse en FHE usando las técnicas de Gentry.

La palabra «totalmente» habla de expresividad. No promete que un programa convencional se ejecute sin adaptación ni que cualquier tamaño de cálculo resulte práctico.

4. Ruido, profundidad y bootstrapping

Muchos esquemas modernos se apoyan en problemas de retículas, como Learning With Errors (LWE) y sus variantes con estructura de anillo, descritos en las guías de implementación de cifrado homomórfico. La intuición es ocultar una relación algebraica añadiéndole un error pequeño: sin la clave, recuperar el secreto desde muchas relaciones perturbadas se considera difícil para los parámetros elegidos.

Ese ruido forma parte del diseño criptográfico. Las operaciones lo transforman y pueden hacerlo crecer hasta impedir un descifrado correcto. Las multiplicaciones suelen consumir más capacidad que las sumas, por lo que importa la profundidad multiplicativa: cuántas multiplicaciones dependientes atraviesa una ruta del circuito.

Por ejemplo, calcular x⁸ como x², luego x⁴ y finalmente x⁸ requiere tres multiplicaciones encadenadas. Tener muchas operaciones independientes no equivale a tener esa misma cantidad de niveles consecutivos.

El bootstrapping refresca un cifrado para recuperar capacidad de cálculo. Conceptualmente, evalúa homomórficamente un procedimiento de descifrado usando material de clave cifrado incluido en la clave de evaluación. El resultado es otra representación cifrada del mensaje, con ruido controlado. El servidor no obtiene el mensaje en claro.

Este paso tiene costo y requiere los supuestos de seguridad correspondientes al material de evaluación. En familias como TFHE, el refresco puede combinarse con la evaluación de funciones; la introducción técnica de Zama explica el programmable bootstrapping. El trabajo de Chillotti, Gama, Georgieva e Izabachène desarrolla una de las construcciones que impulsaron esta familia.

5. BFV, BGV, CKKS y TFHE

La elección comienza por los datos y las operaciones que necesita la aplicación. La documentación de Microsoft SEAL distingue aritmética modular exacta y aritmética aproximada; TFHE ofrece otra vía basada en circuitos booleanos.

En CKKS, los valores se codifican con una escala. Las multiplicaciones alteran esa escala y el rescaling ayuda a controlarla reduciendo el módulo, con pérdida de precisión. Un resultado como 18,9998 en lugar de 19 puede ser coherente con el esquema. El margen aceptable debe fijarlo la aplicación.

También existe el empaquetado: varios valores ocupan posiciones de un mismo cifrado y una operación actúa sobre muchas posiciones a la vez. Esto permite amortizar costos, aunque las rotaciones y la reorganización de los vectores también requieren trabajo. El artículo original de CKKS describe su técnica de empaquetado y sus límites de precisión.

6. Cómo ejecutar un modelo de IA sin ver sus entradas

Consideremos un modelo lineal con entradas normalizadas x y coeficientes w:

El cliente cifra el vector de características. El servidor puede mantener los pesos en claro y evaluar el producto escalar mediante multiplicaciones entre cifrados y constantes, más sumas. Devuelve un cifrado de z. El cliente descifra el puntaje y, si corresponde, aplica localmente una transformación final.

La siguiente secuencia es pseudocódigo conceptual; omite codificación, parámetros y gestión de niveles:

# Cliente
pk, sk, evk = generar_claves(parametros)
cx = cifrar(pk, codificar(caracteristicas))
enviar_a_nube(cx, evk, parametros_publicos)

# Nube: pesos y sesgo en claro, entradas cifradas
cz = producto_escalar_homomorfico(cx, pesos, evk)
cz = sumar_constante(cz, sesgo)
devolver_al_cliente(cz)

# Cliente
puntaje = decodificar(descifrar(sk, cz))

TenSEAL expone operaciones sobre vectores cifrados, productos escalares y multiplicaciones por matrices desde Python, sobre Microsoft SEAL. Estas piezas permiten reconocer la relación entre el álgebra de un modelo y el circuito cifrado que lo evalúa.

Una red neuronal introduce más trabajo. Las activaciones, las comparaciones y decisiones como if x > 0 necesitan una representación homomórfica. Una condición cifrada no puede controlar una rama visible sin revelar información sobre esa condición. Se utilizan aproximaciones polinómicas, selección cifrada o técnicas de evaluación de funciones, según el esquema.

CryptoNets, publicado en 2016, mostró cómo adaptar redes ya entrenadas para producir predicciones cifradas sobre entradas cifradas. Su demostración usó reconocimiento de dígitos de MNIST: es evidencia de viabilidad técnica, no una validación clínica.

Inferencia y entrenamiento son cargas distintas. Entrenar implica repetir evaluaciones, calcular gradientes y actualizar parámetros. Puede investigarse bajo cifrado, pero el éxito de una inferencia pequeña no establece que entrenar un modelo grande con FHE sea viable para el mismo presupuesto. Tampoco se obtiene automáticamente privacidad de los pesos frente al cliente: ocultar el modelo requiere propiedades adicionales.

7. Salud y colaboración entre instituciones

Volvamos al hospital. Una arquitectura ilustrativa podría extraer y normalizar ciertas características dentro de la institución, cifrarlas, delegar la evaluación de un modelo y recuperar un puntaje cifrado. La clave secreta quedaría bajo custodia del hospital y el resultado se abriría en su entorno autorizado.

El objetivo sería aprovechar un servicio de cómputo externo sin entregarle las mediciones originales. Esto exige validar tanto el modelo como su versión cifrada: cuantización, aproximaciones y errores numéricos pueden modificar una decisión cercana a un umbral. El cifrado protege la confidencialidad; la utilidad clínica depende de una evaluación independiente.

Para estadísticas compartidas entre hospitales aparece otra dificultad: los cifrados de claves independientes no se combinan automáticamente con una suma ordinaria del esquema. Se necesita acordar quién puede descifrar, usar un diseño con clave colectiva y descifrado distribuido, o adoptar construcciones multiclave. Lattigo, por ejemplo, implementa protocolos homomórficos multipartitos con claves secretas compartidas. El protocolo elegido también fija qué ocurre si algunas instituciones colaboran entre sí.

Por último, obtener solo un agregado no garantiza anonimato. Si se permite consultar grupos que difieren en una única persona, la diferencia entre dos respuestas puede revelar su contribución. Dwork y Roth explican estos ataques por diferencias en The Algorithmic Foundations of Differential Privacy. El diseño debe controlar las consultas y la divulgación de resultados; puede complementarse con privacidad diferencial cuando el objetivo sea limitar esa inferencia.

8. Qué protege y cómo se complementa con ZKP

La confidencialidad de las entradas es una garantía específica. Para diseñar un servicio conviene distinguirla de otras propiedades:

• Corrección frente a un servidor malicioso. Un servidor puede devolver un cifrado equivocado. FHE por sí solo no aporta una prueba de ejecución correcta.
• Autenticidad. Poder transformar cifrados es parte de la funcionalidad. La procedencia y la integridad necesitan mecanismos de protocolo.
• Metadatos. Tamaños, tiempos y patrones de solicitudes pueden seguir siendo observables si no se protegen por separado.
• Extremos y claves. Un cliente comprometido o una clave secreta expuesta permite acceder a los datos que esa clave protege.

La guía de seguridad de SEAL advierte que sus cifrados no están autenticados y que no ofrece privacidad del circuito. También señala riesgos al compartir descifrados, especialmente con CKKS: una aplicación no debe convertirse en un oráculo que descifra entradas elegidas por un atacante.

Aquí encaja la conexión con ZKP. FHE permite calcular manteniendo ocultas las entradas al evaluador; una prueba de conocimiento cero puede acreditar una relación sobre un cálculo y conservar privados los testigos. Un protocolo que combine ambas técnicas podría exigir una prueba de que la salida corresponde al circuito acordado aplicado a las entradas cifradas.

Esa composición necesita vincular la prueba con el circuito, los parámetros y los cifrados concretos. Verificar una prueba sobre una operación distinta no protege la solicitud real. Las dos herramientas resuelven problemas complementarios, y combinarlas añade costo y complejidad.

9. El costo y las decisiones de implementación

El costo práctico incluye latencia, memoria, tamaño de los cifrados, claves de evaluación, transferencia y eventuales refrescos. Una cifra aislada de «operaciones por segundo» sirve de poco sin conocer el circuito, la precisión, el hardware y los parámetros de seguridad. El rendimiento por lotes tampoco equivale al tiempo que espera una solicitud individual.

Las guías de seguridad de HomomorphicEncryption.org reúnen recomendaciones de parámetros y herramientas para estimar la resistencia a ataques conocidos. Sus tablas relacionan decisiones que afectan capacidad, rendimiento y seguridad; ampliar un módulo para admitir más cálculo exige revisar el resto de los parámetros.

Para evaluar una aplicación concreta, el recorrido puede ser:

1. Definir el resultado y quién lo verá. Precisar entradas, circuito, custodios de las claves y modelo de amenaza.
2. Fijar rangos y tolerancia al error. Decidir si se necesita aritmética modular exacta o aproximada y cómo se representan los datos.
3. Medir un circuito representativo. Incluir cifrado, transferencia, evaluación y descifrado; comparar la salida con una referencia en claro.
4. Diseñar el protocolo completo. Autenticación, validación de entradas, manejo de errores, divulgación de resultados y recuperación de claves también forman parte del sistema.

El atractivo del cifrado homomórfico está en esa separación concreta: quien dispone de la infraestructura puede ejecutar un cálculo sin recibir los secretos que le dan sentido. Para IA y salud, abre una forma de colaboración que reduce la exposición de datos sensibles. Su utilidad aparece cuando el cálculo, las garantías y el presupuesto se diseñan juntos.

Fuentes y lecturas para profundizar

• NIST: Fully-Homomorphic Encryption. Definición y funcionalidad ideal.
• Charm-Crypto: implementación de Paillier. Referencia para las operaciones de la demostración.
• Van Dijk, Gentry, Halevi y Vaikuntanathan: Fully Homomorphic Encryption over the Integers. De capacidad limitada a cifrado totalmente homomórfico.
• Zama: Homomorphic Encryption 101. Ruido, niveles y bootstrapping programable.
• Cheon, Kim, Kim y Song: Homomorphic Encryption for Arithmetic of Approximate Numbers. Construcción de CKKS.
• Chillotti, Gama, Georgieva e Izabachène: Faster Fully Homomorphic Encryption y documentación de TFHE.
• Microsoft SEAL y su modelo de seguridad. Operaciones, límites y precauciones de protocolo.
• TenSEAL. Operaciones sobre tensores cifrados.
• Dowlin y colaboradores: CryptoNets. Inferencia sobre datos cifrados.
• HomomorphicEncryption.org: Security Guidelines y Security Guidelines for Implementing Homomorphic Encryption. Guías comunitarias y estimación de parámetros.
• Lattigo. Esquemas y protocolos homomórficos multipartitos.
• Dwork y Roth: The Algorithmic Foundations of Differential Privacy. Privacidad de los resultados y ataques sobre agregados.

Los escenarios de salud son ejemplos de arquitectura; no describen una implementación clínica desplegada. La demostración de Paillier ilustra una propiedad aditiva y no implementa FHE.