Resumo Técnico: OTRO – Caminho de Tokenização Oblíqua com SqrtORAM

1. Declaração do Problema

O artigo identifica uma lacuna de segurança crítica no serviço de Grandes Modelos de Linguagem (LLMs) confidenciais: o tokenizador. Embora os Ambientes de Execução Confiáveis (TEEs), como Intel TDX e GPUs NVIDIA TEE, protejam o conteúdo da memória e as computações, eles não ocultam inerentemente os padrões de acesso à memória.

• A Vulnerabilidade: Os LLMs modernos utilizam tokenizadores de Codificação de Par de Bytes (BPE), que dependem de buscas determinísticas baseadas em tabelas (vocabulário e tabelas de fusão/merge) para converter texto bruto em IDs de tokens. Como o mapeamento de tokens para endereços de memória é fixo após a inicialização, um adversário que controle o hipervisor ou tenha acesso físico ao servidor pode observar os padrões de acesso à DRAM (via falhas de página ou canais laterais de cache).
• A Consequência: Trabalhos recentes (TDXRay) demonstraram que esses padrões de acesso permitem a reconstrução de ponta a ponta de prompts de usuários com mais de 90% de similaridade, contornando efetivamente as proteções de TEE.
• O Desafio da Mitigação: Soluções padrão de Memória Oblíqua (ORAM), como o PathORAM, introduzem latências proibitivas. A integração ingênua do PathORAM aumenta o Tempo para o Primeiro Token (TTFT) em aproximadamente 13×, enquanto a integração ingênua do SqrtORAM (Square-Root ORAM) o aumenta em cerca de 323× devido aos caros custos de reconstrução de $O(N \log^2 N)$ que ocorrem a cada $\sqrt{N}$ acessos. Esses excessos são inaceitáveis para a inferência de LLM que exige baixa latência.

2. Metodologia: Arquitetura OTRO

Os autores propõem o OTRO (Oblivious Tokenization Path), um caminho de tokenização oblíquo e eficiente, adaptado para o serviço de LLM. A ideia central é que as tabelas do tokenizador são somente leitura durante a inferência. Essa propriedade permite que o OTRO desvincule as operações de reconstrução dispendiosas do caminho crítico de acesso.

O OTRO alcança isso através de três inovações principais:

A. Replicação de SqrtORAM em Pool

Em vez de uma única instância de SqrtORAM que deve ser reconstruída após $\sqrt{N}$ acessos, o OTRO mantém um pool de instâncias de SqrtORAM replicadas e de somente leitura.

• Cada instância contém o mesmo vocabulário e dados de fusão, mas com uma permutação aleatória distinta.
• Como os dados são apenas para leitura, as instâncias não precisam reconciliar atualizações; elas apenas precisam ser reembaralhadas para manter a natureza oblíqua.
• Enquanto uma instância está sendo reconstruída, outras continuam a atender as requisições.

B. Rotação Baseada em Épocas e Preenchimento (Padding)

O OTRO implementa uma política de rotação baseada em épocas para gerenciar o pool:

• Rotação: Cada instância atende exatamente $\sqrt{N}$ acessos (uma época). Uma vez atingido o limite, a instância é marcada para reconstrução assíncrona em segundo plano, e o sistema rotaciona para uma nova instância.
• Preenchimento (Padding): Para evitar que o número exato de acessos dentro de uma época revele informações, o OTRO preenche cada época com acessos fictícios (dummy accesses) até atingir o limite de $\sqrt{N}$. Isso garante que o registro observável revele apenas a contagem de épocas (e, portanto, a contagem grosseira de acessos), não o número preciso de buscas.
• Segurança: A seleção da instância é uma função determinística da contagem global de acessos, independente do endereço lógico específico sendo acessado, garantindo a indistinguibilidade do padrão de acesso.

C. Tokenização em Blocos com Consciência de KV-Cache

Para minimizar o tamanho do pool necessário para evitar interrupções e ocultar a latência de reconstrução, o OTRO introduz a tokenização em blocos (chunked tokenization):

• Prompts longos são divididos em blocos menores em limites de pré-tokenização (palavras delimitadas por espaços em branco).
• A tokenização de um bloco é intercalada com a fase de prefill da GPU.
• O sistema é ajustado de modo que o tempo necessário para a GPU processar um bloco ($T_{gpu, prefill}$) seja maior que o tempo necessário para reconstruir uma instância de SqrtORAM ($T_{reshuffle}$).
• Essa sobreposição permite que as reconstruções ocorram em segundo plano enquanto a GPU está computando, amortizando efetivamente o custo de reconstrução e reduzindo o número de instâncias de SqrtORAM necessárias no pool.

D. Desotokenização

O OTRO também aplica proteção ORAM ao caminho de desotokenização (conversão de IDs de tokens de volta para texto). Devido à natureza da etapa de decodificação (onde os tokens são gerados lentamente ao longo do tempo), um pool pequeno (ex: 2 instâncias) é suficiente para sobrepor as reconstruções com os kernels de decodificação, ocultando a latência.

3. Principais Contribuições

1. Caracterização de Custo: Os autores demonstram que, embora as defesas de ORAM padrão sejam proibitivas (atrasos de 13× a 323×), o custo de reconstrução é o principal gargalo. Ao remover as reconstruções do caminho crítico, o OTRO acompanha a linha de base não protegida com menos de 2,4× de overhead.
2. Arquitetura Oblíqua: Uma nova arquitetura que utiliza um pool de instâncias de SqrtORAM de somente leitura, rotação baseada em épocas e preenchimento de contagem de acessos para eliminar as reconstruções do caminho crítico.
3. Integração Consciente de Latência: A integração da tokenização em blocos com o prefill da GPU e mecanismos de KV-cache para sobrepor as reconstruções do lado da CPU com a computação da GPU, minimizando a pegada de memória e a contagem de instâncias.
4. Protótipo de Ponta a Ponta: Implementação do OTRO dentro dos Tokenizers do HuggingFace e do nano-vLLM, rodando dentro de uma Máquina Virtual Confiável (CVM) habilitada para TDX com uma GPU NVIDIA H100.
5. Redução de Vazamento (Leakage): Prova formal de que os padrões de acesso do OTRO não revelam nada sobre as entradas da tabela tocadas. Com o preenchimento (padding), o único vazamento inevitável é o comprimento do prompt de entrada (comprimento em bytes), que é inerente a qualquer design prático de ORAM.

4. Resultados Experimentais

O sistema foi avaliado utilizando os modelos Llama-3.1, Qwen3, Gemma-3 e Phi-3 usando uma CPU Intel Xeon Gold e uma GPU NVIDIA H100.

• Latência (TTFT): O OTRO limita o overhead do TTFT a no máximo 4,5% em relação à linha de base não protegida.
  • O PathORAM aumentou o TTFT em ~1,48×.
  • O SqrtORAM ingênuo aumentou o TTFT em ~11,12×.
  • O OTRO (com chunking) performa próximo ao cenário "ideal" do SqrtORAM (sem penalidades de reconstrução), mantendo a latência do tokenizador abaixo de 10% do TTFT total.
• Overhead de Memória: O OTRO adiciona menos de 0,5 GB de overhead de memória por cliente (ex: ~286 MB para Llama-3.1 com 48 instâncias). Isso é significativamente menor que o overhead exigido pelo PathORAM em algumas configurações e permite que uma CVM de 256 GB suporte dezenas de clientes simultâneos.
• Inicialização: Os custos de inicialização aumentam entre 35% e 350% dependendo do modelo, mas como este é um custo único por carregamento de modelo, não é considerado um gargalo do sistema.
• Análise de Vazamento:
  • Sem ORAM, um adversário pode reconstruir prompts com ~0 bits de incerteza residual.
  • Com OTRO (sem padding), a incerteza residual é de 1,60 bits.
  • Com OTRO (com preenchimento de contagem de acessos), a incerteza residual sobe para 5,49 bits, recuperando 38,4% da entropia original do prompt. O vazamento restante deve-se principalmente à correlação inevitável entre o comprimento em bytes da entrada e a contagem de acessos.

5. Significância e Alegações

O artigo afirma que o OTRO fornece um caminho viável para a confidencialidade de ponta a ponta em pilhas de serviço de LLM de produção. Ele aborda um canal lateral de alta fidelidade específico (padrões de acesso ao tokenizador) que sobrevive às proteções padrão de TEE.

• Praticidade: Diferente de soluções ORAM teóricas anteriores ou projetadas para diferentes modelos de ameaça (ex: SGX com restrições de memória), o OTRO é projetado especificamente para a natureza de somente leitura e sensível à latência da tokenização de LLM em CVMs modernas com suporte a GPU.
• Troca entre Segurança e Desempenho: O trabalho demonstra que é possível alcançar uma forte confidencialidade de padrão de acesso (ocultando quais tokens são acessados) com um impacto de desempenho insignificante (<5% de overhead de TTFT), uma troca que anteriormente era considerada proibitiva.
• Escopo: Os autores afirmam explicitamente que o OTRO protege os padrões de acesso às tabelas do tokenizador. Ele não pretende eliminar todos os canais laterais (ex: variabilidade de tempo de padrões de código específicos) ou proteger contra o vazamento do comprimento da entrada, que é tratado como um baseline inevitável em implementações práticas de ORAM.

Em resumo, o OTRO transforma o custo de reconstrução intermitente e crítico do SqrtORAM em trabalho de segundo plano através de replicação e agendamento, permitindo a inferência de LLM segura e de baixa latência na presença de um adversário poderoso e privilegiado.