Resumen Técnico: OTRO – Ruta de Tokenización Obliviosa con SqrtORAM

1. Declaración del Problema

El artículo identifica una brecha de seguridad crítica en el servicio de Modelos de Lenguaje de Gran Escala (LLM) confidenciales: el tokenizador. Aunque los Entornos de Ejecución Confiables (TEE) como Intel TDX y los TEE de NVIDIA GPU protegen el contenido de la memoria y las computaciones, no ocultan inherentemente los patrones de acceso a la memoria.

• La Vulnerabilidad: Los LLM modernos utilizan tokenizadores de Codificación de Par de Bytes (BPE), que dependen de búsquedas deterministas basadas en tablas (vocabulario y tablas de fusión) para convertir texto bruto en IDs de tokens. Debido a que el mapeo de tokens a direcciones de memoria es fijo tras la inicialización, un adversario que controle el hipervisor o tenga acceso físico al servidor puede observar los patrones de acceso a la DRAM (mediante fallos de página o canales laterales de caché).
• La Consecuencia: Trabajos recientes (TDXRay) demostraron que estos patrones de acceso permiten la reconstrucción de extremo a extremo de los prompts del usuario con más del 90% de similitud, eludiendo efectivamente las protecciones de los TEE.
• El Desafío de la Mitigación: Las soluciones estándar de Memoria Obliviosa (ORAM), como PathORAM, introducen latencias prohibitivas. La integración ingenua de PathORAM aumenta el Tiempo de Primer Token (TTFT) aproximadamente 13×, mientras que la integración ingenua de Square-Root ORAM (SqrtORAM) lo aumenta aproximadamente 323× debido a los costosos costos de reconstrucción de $O(N \log^2 N)$ que ocurren cada $\sqrt{N}$ accesos. Estos sobrecostos son inaceptables para la inferencia de LLM que requiere baja latencia.

2. Metodología: Arquitectura OTRO

Los autores proponen OTRO (Ruta de Tokenización Obliviosa), una ruta de tokenización eficiente y obligatoria diseñada para el servicio de LLM. La idea central es que las tablas del tokenizador son de solo lectura durante la inferencia. Esta propiedad permite que OTRO desvincule las costosas operaciones de reconstrucción del camino crítico de acceso.

OTRO logra esto mediante tres innovaciones clave:

A. Réplica de SqrtORAM por Lotes (Pooled SqrtORAM Replication)

En lugar de una única instancia de SqrtORAM que debe reconstruirse después de $\sqrt{N}$ accesos, OTRO mantiene un grupo de instancias de SqrtORAM replicadas y de solo lectura.

• Cada instancia contiene el mismo vocabulario y datos de fusión, pero con una permutación aleatoria distinta.
• Dado que los datos son de solo lectura, las instancias no necesitan reconciliar actualizaciones; solo necesitan ser reordenadas para mantener la obligatoriedad.
• Mientras una instancia está siendo reconstruida, otras continúan atendiendo solicitudes.

B. Rotación Basada en Épocas y Relleno (Padding)

OTRO implementa una política de rotación basada en épocas para gestionar el grupo:

• Rotación: Cada instancia sirve exactamente $\sqrt{N}$ accesos (una época). Una vez alcanzado el límite, la instancia se marca para una reconstrucción asíncrona en segundo plano, y el sistema rota hacia una instancia fresca.
• Relleno (Padding): Para evitar que el número exacto de accesos dentro de una época filtre información, OTRO rellena cada época con accesos fictivos (dummy) para alcanzar el límite de $\sqrt{N}$. Esto asegura que el registro observable revele solo el conteo de épocas (y, por ende, el conteo grueso de accesos), no el número preciso de búsquedas.
• Seguridad: La selección de la instancia es una función determinista del conteo global de accesos, independiente de la dirección lógica específica que se esté accediendo, asegurando la indistinguibilidad del patrón de acceso.

C. Tokenización por Bloques con Conciencia de KV-Cache

Para minimizar el tamaño del grupo requerido para evitar paradas y ocultar la latencia de reconstrucción, OTRO introduce la tokenización por bloques (chunked tokenization):

• Los prompts de entrada largos se dividen en bloques más pequeños en los límites de pre-tokenización (palabras delimitadas por espacios en blanco).
• La tokenización de un bloque se entrelaza con la fase de prellenado (prefill) de la GPU.
• El sistema se ajusta de tal manera que el tiempo requerido para que la GPU procese un bloque ($T_{gpu, prefill}$) sea mayor que el tiempo requerido para reconstruir una instancia de SqrtORAM ($T_{reshuffle}$).
• Este solapamiento permite que las reconstrucciones ocurran en segundo plano mientras la GPU está computando, amortizando efectivamente el costo de reconstrucción y reduciendo el número de instancias de SqrtORAM necesarias en el grupo.

D. Desetokenización

OTRO también aplica la protección ORAM a la ruta de desetogenización (convertir IDs de tokens de nuevo a texto). Debido a la naturaleza de la etapa de decodificación (donde los tokens se generan lentamente a lo largo del tiempo), un grupo pequeño (por ejemplo, 2 instancias) es suficiente para solapar las reconstrucciones con los kernels de decodificación, ocultando la latencia.

3. Contribuciones Clave

1. Caracterización de Costos: Los autores demuestran que, si bien las defensas ingenuas de ORAM son prohibitivas (retrasos de 13× a 323×), el costo de reconstrucción es el cuello de botella principal. Al eliminar las reconstrucciones del camino crítico, OTRO sigue la línea base sin protección con un sobrecosto menor a 2.4×.
2. Arquitectura Obliviosa: Una arquitectura novedosa que utiliza un grupo de instancias de SqrtORAM de solo lectura, rotación basada en épocas y relleno de conteo de accesos para eliminar las reconstrucciones del camino crítico.
3. Integración Consciente de la Latencia: La integración de la tokenización por bloques con el prellenado de la GPU y los mecanismos de KV-cache para solapar las reconstrucciones del lado de la CPU con la computación de la GPU, minimizando la huella de memoria y el conteo de instancias.
4. Prototipo de Extremo a Extremo: Implementación de OTRO dentro de los tokenizadores de HuggingFace y nano-vLLM, ejecutándose dentro de una Máquina Virtual Confiable (CVM) habilitada para TDX con una GPU NVIDIA H100.
5. Reducción de Fugas: Prueba formal de que los patrones de acceso de OTRO no revelan nada sobre las entradas de la tabla tocadas. Con el relleno, la única fuga inevitable es la longitud del prompt de entrada (longitud en bytes), la cual es inherente a cualquier diseño práctico de ORAM.

4. Resultados Experimentales

El sistema fue evaluado con los modelos Llama-3.1, Qwen3, Gemma-3 y Phi-3 utilizando un CPU Intel Xeon Gold y una GPU NVIDIA H100.

• Latencia (TTFT): OTRO limita el sobrecosto del TTFT a un máximo del 4.5% en comparación con la línea base sin protección.
  • PathORAM aumentó el TTFT aproximadamente 1.48×.
  • El SqrtORAM ingenuo aumentó el TTFT aproximadamente 11.12×.
  • OTRO (con fragmentación) se desempeña cerca del escenario "ideal" de SqrtORAM (sin penalizaciones de reconstrucción), manteniendo la latencia inducida por el tokenizador por debajo del 10% del TTFT total.
• Sobrecosto de Memoria: OTRO añade menos de 0.5 GB de sobrecosto de memoria por cliente (por ejemplo, ~286 MB para Llama-3.1 con 48 instancias). Esto es significativamente menor que el sobrecosto requerido por PathORAM en algunas configuraciones y permite que una CVM de 256 GB soporte decenas de clientes concurrentes.
• Inicialización: Los costos de inicialización aumentan entre un 35% y un 350% dependiendo del modelo, pero dado que es un costo de una sola vez por carga de modelo, no se considera un cuello de botella del sistema.
• Análisis de Fugas:
  • Sin ORAM, un adversario puede reconstruir los prompts con ~0 bits de incertidumbre residual.
  • Con OTRO (sin relleno), la incertidumbre residual es de 1.60 bits.
  • Con OTRO (con relleno de conteo de accesos), la incertidumbre residual aumenta a 5.49 bits, recuperando el 38.4% de la entropía original del prompt. La fuga restante se debe principalmente a la correlación inevitable entre la longitud en bytes de la entrada y el conteo de accesos.

5. Significancia y Reivindicaciones

El artículo afirma que OTRO proporciona una vía viable hacia la confidencialidad de extremo a extremo en los stacks de servicio de LLM en producción. Aborda un canal lateral específico de alta fidelidad (patrones de acceso de tablas de tokenización) que sobrevive a las protecciones estándar de los TEE.

• Practicidad: A diferencia de las soluciones ORAM teóricas previas o aquellas diseñadas para modelos de amenazas diferentes (como SGX con restricciones de memoria), OTRO está diseñado específicamente para la naturaleza de solo lectura y baja latencia de la tokenización de LLM en las CVM modernas con soporte de GPU.
• Compromiso Seguridad vs. Rendimiento: El trabajo demuestra que es posible lograr una fuerte confidencialidad de los patrones de acceso (ocultar qué tokens se acceden) con un impacto de rendimiento insignificante (<5% de sobrecosto en TTFT), un compromiso que anteriormente se consideraba prohibitivo.
• Alcance: Los autores declaran explícitamente que OTRO protege los patrones de acceso a la memoria de las tablas del tokenizador. No pretende eliminar todos los canales laterales (como la variabilidad de tiempo de patrones de código específicos) ni proteger contra la fuga de longitud de entrada, la cual es tratada como una base inevitable en los despliegues prácticos de ORAM.

En resumen, OTRO transforma el costo de reconstrucción por ráfagas y crítico de SqrtORAM en un trabajo de segundo plano mediante la replicación y la programación, permitiendo un servicio de LLM seguro y de baja latencia ante un adversario privilegiado y poderoso.