Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors

Resumen Técnico: Identificación de la Huella de E/S de Clústeres de IA sin Procesadores de Confianza Mutua

Declaración del Problema
A medida que los acuerdos internacionales sobre el desarrollo y despliegue de la inteligencia artificial (IA) se vuelven cada vez más probables, existe una necesidad crítica de infraestructura de verificación capaz de confirmar que los centros de datos de IA no están ejecutando cargas de trabajo no declaradas. El desafío central abordado por este documento es el Subobjetivo 2A de la agenda de verificación de la IA (Baker et al., 2025): permitir que un "Probador" (el operador del centro de datos) demuestre criptográficamente a un "Verificador" (un auditor) que no se realizaron computaciones no divulgadas dentro de un clúster.

El obstáculo técnico específico es la potencial exfiltración encubierta de resultados de cargas de trabajo no divulgadas. Incluso si un centro de datos afirma estar ejecutando solo tareas autorizadas, un actor malicioso podría ocultar los resultados de computaciones no autorizadas en el tráfico que sale de las instalaciones. Esto puede lograrse mediante:

1. Esteganografía: Ocultar datos en los encabezados de los protocolos (por ejemplo, bytes de relleno, números de puerto, números de secuencia) o dentro de las cargas útiles (payloads) de texto plano de los paquetes de red.
2. Canales Laterales: Codificar información en la temporización de la transmisión de paquetes (intervalos entre paquetes) o en las propiedades analógicas de la señal óptica.
3. No Determinismo: Explotar el no determinismo inherente de los resultados de la inferencia de los Modelos de Lenguaje Extensos (LLM) para codificar bits ocultos.

Las soluciones existentes suelen depender de Entornos de Ejecución Confiables (TEE) o componentes de hardware que requieren una confianza mutua entre el Probador y el Verificador. Sin embargo, establecer la confianza en un único componente de hardware es difícil debido a las vulnerabilidades de la cadena de suministro (por ejemplo, IPs maliciosas, troyanos a nivel de dopante) que no pueden parchearse tras el despliegue.

Metodología: El Dispositivo de Puerta de Enlace Segura (SeGaDev)
Los autores proponen un "Dispositivo de Puerta de Enlace Segura" (SeGaDev) colocado en el límite de la red norte-sur de un centro de datos de IA (entre el punto de terminación de TLS y la estructura de enrutamiento interna). El dispositivo captura todo el tráfico de entrada y salida, lo sanitiza para eliminar canales encubiertos y genera hashes criptográficos para una verificación posterior.

La arquitectura está diseñada para funcionar sin ningún procesador mutuamente confiable por ambas partes. En su lugar, se basa en la observabilidad basada en la física y en protocolos criptográficos:

1. Colocación y Observación Pasiva:

   • El SeGaDev intercepta el tráfico de texto plano después de la terminación del cifrado.
   • Se utilizan Divisores Ópticos Pasivos (usando Fused Biconical Taper o Planar Lightwave Circuit) en los enlaces que transportan los datos hacia el Verificador. Esto permite que el Probador observe de forma independiente los hashes enviados al Verificador sin poder interferir con la pata de monitoreo del Verificador. La confianza se fundamenta en la física de la división de haces en lugar de la integridad del hardware.

2. Sanitización (Guardián Activo):

   • El dispositivo emplea un Guardián Activo para limpiar los grados de libertad esteganográficos de los encabezados de los protocolos de red.
   • Protocolo de Lanzamiento de Moneda (Coin-Flip): Para evitar que cualquiera de las dos partes controle los valores aleatorios utilizados para sobrescribir los campos de los encabezados (por ejemplo, puertos de origen efímeros, Números de Secuencia Inicial de TCP), el Probador y el Verificador contribuyen a la generación de números aleatorios compartidos mediante un protocolo de compromiso-revelación (commit-reveal). Los valores pseudialeatorios resultantes se utilizan para sobrescribir los campos de los encabezados, eliminando la capacidad de codificar datos en ellos.
   • Re-temporización: El dispositivo almacena en búfer todos los paquetes y los libera siguiendo un esquema fijo a la tasa máxima del enlace. Esto elimina los canales laterales de temporización (por ejemplo, la modulación de los intervalos entre paquetes) y la modulación de la señal analógica.

3. Hashing y Compromiso:

   • Tras la sanitización, el dispositivo calcula hashes criptográficos (por ejemplo, SHA-256) sobre los datos de la carga útil (capa de aplicación).
   • Estos hashes, junto con las marcas de tiempo, se transmiten al Verificador a través de un enlace de fibra dedicado.
   • El Probador conserva los datos originales en texto plano y el mapeo de qué datos corresponden a cada hash.

4. Flujo de Trabajo de Verificación:

   • El Verificador puede desafiar retroactivamente al Probador solicitando la preimagen de los datos para hashes específicos.
   • El Probador envía los datos en texto plano a una instalación de verificación segura y mutuamente confiable (fuera del alcance del propio SeGaDev) para repetir la computación y confirmar que el hash coincide.

Contribuciones Clave

• Arquitectura para la Verificabilidad Mutua: Un diseño detallado de un mecanismo de verificación que elimina la necesidad de procesadores mutuamente confiables, aprovechando divisores ópticos pasivos y protocolos de lanzamiento de moneda para asegurar que ninguna de las partes pueda manipular la evidencia o el proceso de monitoreo.
• Eliminación de Canales Encubiertos: Una metodología específica para borrar canales esteganográficos en los encabezados de los protocolos Ethernet y canales laterales de temporización utilizando una arquitectura de Guardián Activo adaptada para centros de datos de alta velocidad.
  os.
• Evaluación de Viabilidad: Un análisis de los requisitos de almacenamiento y ancho de banda para un despliegue a gran escala (por ejemplo, 100,000 GPUs), estimando que los costos son manejables en relación con la escala de los centros de datos de IA modernos.

Resultados y Análisis de Viabilidad
El documento proporciona una evaluación teórica y arquitectónica en lugar de resultados experimentales empíricos de un despliegue a escala completa. Los hallazgos clave incluyen:

• Canales Encubiertos Residuales: Incluso después de la sanitización, los autores identifican tres canales potenciales restantes:

  1. Modulación de Temporización: Mitigada mediante el conteo de tramas fijas y el orden canónico, reduciendo la capacidad a eventos del ciclo de vida de la conexión.
  2. Esteganografía en Salidas de ML: Identificada como el riesgo residual más significativo. El no determinismo en la inferencia de los LLM podría permitir la exfiltración de aproximadamente 0.1 bits de datos ocultos por token. Para un clúster de 200k GPUs, esto podría permitir teóricamente la exfiltración de ~40 Mbit/s. Los autores sugieren que esto puede mitigarse mediante la imposición de inferencia determinista (mediante la sincronización de semillas y el control del hardware) o añadiendo ruido para limpiar la entropía inducida por el hardware.
  3. Canales de Fallo: Codificación de datos en la temporización u ocurrencia de "fallos de hardware". Se estima que es un canal de bajo ancho de banda (~1 kbit/día), pero puede ser monitoreado mediante el análisis de las tasas de fallo frente a los datos con hash.

• Requisitos de Almacenamiento: Para un hipotético clúster de 100k GPUs que transmite 200 millones de tokens por segundo, los autores estiman un requisito de almacenamiento anual de caso de peor escenario de ~1,260 PB para datos en texto plano y ~200 PB para hashes. Señalan que este es un límite superior pesimista (asumiendo 1 token por paquete JSON) y que el procesamiento por lotes estándar y la compresión reducirían esto significamente. El costo se estima en menos del 1% del costo total del centro de datos.

• Implementación de Hardware: Los componentes (FPGAs, divisores ópticos, procesadores de hash) están disponibles comercialmente y se utilizan en entornos de alta exigencia como la regulación financiera (por ejemplo, MiFID II) y redes militares. Los autores estiman que la lista de materiales para un dispositivo de demostración es baja en comparación con los costos de ingeniería.

Significancia y Reivindicaciones
El documento afirma proporcionar una solución práctica y retroajustable para verificar el cumplimiento de la IA a nivel de red sin depender de la integridad de componentes de hardware específicos. Al desplazar la raíz de confianza hacia la observabilidad física (divisores ópticos) y los compromisos criptográficos, aborda el cuello de botella de la "confianza" en la verificación de la IA internacional.

Los autores enfatizan que, si bien el SeGaDev evita la exfiltración de resultados de cargas de trabajo no divulgadas, no evita la ejecución de tales cargas de trabajo internamente. Por lo tanto, es un componente crítico de un proceso de verificación más amplio que debe combinarse con otras medidas (por ejemplo, tomas de red de backend, contabilidad de utilización de cómputo) para asegurar plenamente la infraestructura de IA. El trabajo sirve como un diseño fundacional para la verificación de "Nivel 2" (captura de evidencia bruta de computación) en la jerarquía de verificación de IA general.