Riepilogo Tecnico: OTRO – Percorso di Tokenizzazione Oblivio con SqrtORAM

1. Definizione del Problema

Il documento identifica una lacuna critica nella sicurezza del servizio di Large Language Models (LLM) confidenziali: il tokenizer. Sebbene gli Ambienti di Esecuzione Fidati (TEE) come Intel TDX e i TEE per GPU NVIDIA proteggano il contenuto della memoria e le computazioni, essi non nascondono intrinsecamente i pattern di accesso alla memoria.

• La Vulnerabilità: Gli LLM moderni utilizzano tokenizer a codifica Byte-Pair Encoding (BPE), che si basano su lookup deterministici guidati da tabelle (vocabolario e tabelle di merge) per convertire il testo grezzo in ID di token. Poiché la mappatura dai token agli indirizzi di memoria è fissa dopo l'inizializzazione, un avversario che controlla l'hypervisor o che ha accesso fisico al server può osservare i pattern di accesso alla DRAM (tramite page fault o canali collaterali della cache).
• La Conseguenza: Il lavoro recente (TDXRay) ha dimostrato che questi pattern di accesso permettono la ricostruzione end-to-end dei prompt dell'utente con una somiglianza superiore al 90%, eludendo efficacemente le protezioni TEE.
• La Sfida della Mitigazione: Le soluzioni standard di Oblivious RAM (ORAM), come PathORAM, introducono una latenza proibitiva. L'integrazione ingenua di PathORAM aumenta il Time-To-First-Token (TTFT) di circa 13×, mentre l'integrazione ingenua di Square-Root ORAM (SqrtORAM) lo aumenta di circa 323× a causa dei costosi costi di rebuild $O(N \log^2 N)$ che si verificano ogni $\sqrt{N}$ accessi. Questi overhead sono inaccettabili per l'inferenza LLM, che è critica per la latenza.

2. Metodologia: Architettura OTRO

Gli autori propongono OTRO (Oblivious Tokenization Path), un percorso di tokenizzazione efficiente e oblio, progettato su misura per il servizio LLM. L'intuizione fondamentale è che le tabelle del tokenizer sono sola lettura (read-only) durante l'inferenza. Questa proprietà permette a OTRO di disaccoppiare le costose operazioni di rebuild dal percorso critico di accesso.

OTRO raggiunge questo obiettivo attraverso tre innovazioni chiave:

A. Replicazione SqrtORAM a Pool

Invece di un singolo istanza SqrtORAM che deve essere ricostruita dopo $\sqrt{N}$ accessi, OTRO mantiene un pool di istanze SqrtORAM replicate e in sola lettura.

• Ogni istanza contiene lo stesso vocabolario e i dati di merge, ma con una permutazione casuale distinta.
• Poiché i dati sono in sola lettura, le istanze non devono riconciliare gli aggiornamenti; devono solo essere rimescolate per mantenere l'oblio.
• Mentre un'istanza viene ricostruita, le altre continuano a servire le richieste.

B. Rotazione Basata su Epoca e Padding

OTRO implementa una politica di rotazione basata su epoche per gestire il pool:

• Rotazione: Ogni istanza serve esattamente $\sqrt{N}$ accessi (un'epoca). Una volta raggiunto il limite, l'istanza viene contrassegnata per una ricostruzione asincrona in background, e il sistema ruota verso un'istanza fresca.
• Padding: Per evitare che l'esatto numero di accessi all'interno di un'epoca riveli informazioni, OTRO aggiunge il padding a ogni epoca con accessi dummy per raggiungere il confine di $\sqrt{N}$. Ciò assicura che il transcript osservabile riveli solo il conteggio delle epoche (e quindi il conteggio grossolano degli accessi), non il numero preciso di lookup.
• Sicurezza: La selezione dell'istanza è una funzione deterministica del conteggio globale degli accessi, indipendente dall'indirizzo logico specifico che viene accessato, garantendo l'indistinguibilità del pattern di accesso.

C. Tokenizzazione a Blocchi con Consapevolezza della KV-Cache

Per minimizzare la dimensione del pool necessaria per evitare blocchi e nascondere la latenza di rebuild, OTRO introduce la tokenizzazione a blocchi (chunked tokenization):

• I prompt di input lunghi vengono suddivisi in blocchi più piccoli ai confini pre-tokenizzazione (parole delimitate da spazi bianchi).
• La tokenizzazione di un blocco è intersecata con la fase di prefill della GPU.
• Il sistema è tarato in modo che il tempo richiesto alla GPU per elaborare un blocco ($T_{gpu, prefill}$) sia maggiore del tempo richiesto per ricostruire un'istanza SqrtORAM ($T_{reshuffle}$).
• Questa sovrapposizione permette ai rebuild di avvenire in background mentre la GPU sta computando, ammortizzando efficacemente il costo di rebuild e riducendo il numero di istanze SqrtORAM richieste nel pool.

D. Detokenizzazione

OTRO applica la protezione ORAM anche al percorso di detokenizzazione (conversione degli ID dei token in testo). Data la natura della fase di decode (dove i token vengono generati lentamente nel tempo), un piccolo pool (ad esempio, 2 istanze) è sufficiente per sovrapporre i rebuild ai kernel di decode, nascondendo la latenza.

3. Contributi Chiave

1. Caratterizzazione dei Costi: Gli autori dimostrano che, sebbene le difese ORAM naive siano proibitive (slowdown di 13×–323×), il costo di rebuild è il collo di bottiglia principale. Rimuovendo i rebuild dal percorso critico, OTRO segue il baseline non protetto con un overhead inferiore a 2.4×.
2. Architettura Oblivio: Una nuova architettura che utilizza un pool di istanze SqrtORAM in sola lettura, rotazione basata su epoca e padding del conteggio degli accessi per eliminare i rebuild dal percorso critico.
3. Integrazione Consapevole della Latenza: L'integrazione della tokenizzazione a blocchi con il prefill della GPU e i meccanismi della KV-cache per sovrapporre i rebuild lato CPU con la computazione della GPU, minimizzando l'impronta di memoria e il numero di istanze.
4. Prototipo End-to-End: Implementazione di OTRO all'interno di HuggingFace Tokenizers e nano-vLLM, in esecuzione all'interno di una Confidential Virtual Machine (CVM) abilitata a TDX con una GPU NVIDIA H100.
5. Riduzione della Leakage: Prova formale che i pattern di accesso di OTRO non rivelano nulla sulle voci specifiche della tabella toccate. Con il padding, l'unica perdita inevitabile è la lunghezza del prompt di input (lunghezza in byte), che è inerente a qualsiasi design ORAM pratico.

4. Risultati Sperimentali

Il sistema è stato valutato sui modelli Llama-3.1, Qwen3, Gemma-3 e Phi-3 utilizzando una CPU Intel Xeon Gold e una GPU NVIDIA H100.

• Latenza (TTFT): OTRO limita l'overhead del TTFT a un massimo del 4.5% rispetto al baseline non protetto.
  • PathORAM ha aumentato il TTFT di circa 1.48×.
  • Il SqrtORAM naive ha aumentato il TTFT di circa 11.12×.
  • OTRO (con chunking) performa vicino allo scenario "ideale" di SqrtORAM (senza penalità di rebuild), mantenendo la latenza indotta dal tokenizer sotto il 10% del TTFT totale.
• Overhead di Memoria: OTRO aggiunge meno di 0.5 GB di overhead di memoria per client (ad esempio, ~286 MB per Llama-3.1 con 48 istanze). Questo è significativamente inferiore all'overhead richiesto da PathORAM in alcune configurazioni e consente a una CVM da 256 GB di supportare decine di client concorrenti.
• Inizializzazione: I costi di inizializzazione aumentano del 35–350% a seconda del modello, ma poiché si tratta di un costo una tantum per il caricamento del modello, non è considerato un collo di bottiglia del sistema.
• Analisi della Leakage:
  • Senza ORAM, un avversario può ricostruire i prompt con circa 0 bit di incertezza residua.
  • Con OTRO (senza padding), l'incertezza residua è di 1.60 bit.
  • Con OTRO (con access-count padding), l'incertezza residua sale a 5.49 bit, recuperando il 38.4% dell'entropia originale del prompt. La perdita rimanente è dovuta principalmente alla correlazione inevitabile tra la lunghezza in byte dell'input e il conteggio degli accessi.

5. Significato e Rivendicazioni

Il paper sostiene che OTRO fornisce un percorso vitale verso la riservatezza end-to-end negli stack di servizio LLM in produzione. Affronta un side-channel specifico ad alta fedeltà (i pattern di accesso del tokenizer) che sopravvive alle protezioni TEE standard.

• Praticità: A differenza delle precedenti soluzioni ORAM teoriche o progettate per diversi modelli di minaccia (ad esempio, SGX con vincoli di memoria), OTRO è progettato specificamente per la natura a bassa latenza e in sola lettura della tokenizzazione LLM nelle moderne CVM con supporto GPU.
• Trade-off Sicurezza vs Performance: Il lavoro dimostra che è possibile ottenere una forte riservatezza dei pattern di accesso (nascondendo quali token vengono accessati) con un impatto sulle prestazioni trascurabile (<5% di overhead del TTFT), un compromesso che prima era ritenuto proibitivo.
• Ambito: Gli autori dichiarano esplicitamente che OTRO protegge i pattern di accesso alla memoria delle tabelle del tokenizer. Non sostiene di eliminare tutti i side-channel (ad esempio, la variabilità temporale da specifici pattern di codice) o di proteggere contro la perdita di informazioni sulla lunghezza dell'input, che è trattata come un baseline inevitabile in qualsiasi deployment ORAM pratico.

In sintesi, OTRO trasforma il costo di rebuild bursty e critico del percorso di SqrtORAM in un lavoro in background attraverso la replicazione e la pianificazione, consentendo un'inferenza LLM sicura e a bassa latenza in presenza di un avversario potente e privilegiato.