CacheSolidarity: Preventing Prefix Caching Side Channels in Multi-tenant LLM Serving Systems

O artigo apresenta o CacheSolidarity, um sistema que protege ambientes de inferência de LLMs multi-tenant contra canais laterais de temporização decorrentes do cache de prefixos, permitindo a reutilização segura de cache e melhor desempenho sem sacrificar a eficiência.

O essencial

Imagine que você está em um restaurante muito popular e eficiente, onde os chefs (os modelos de Inteligência Artificial) preparam pratos complexos para milhares de clientes ao mesmo tempo. Para não perder tempo, o restaurante usa um truque genial: se dois clientes pedem pratos que começam com a mesma receita (por exemplo, "Faça uma salada com tomate, alface e..."), o chef para de recomeçar do zero. Ele pega a parte que já foi preparada ("salada com tomate e alface") e guarda em uma prateleira especial, pronta para ser usada novamente. Isso é chamado de Cache de Prefixo Automático. É como se o restaurante tivesse uma "prateleira de sobras inteligentes" que acelera muito o serviço.

No entanto, esse truque cria um problema de segurança invisível.

O Problema: O "Relógio" que Vaza Segredos

Imagine que um cliente mal-intencionado (o "atacante") quer saber o segredo do prato que o cliente ao lado (a "vítima") está pedindo. A vítima pediu: "Faça um bolo de chocolate para o João". O atacante não sabe o nome "João", mas ele pode tentar adivinhar.

O atacante pede: "Faça um bolo de chocolate para o Pedro".

• Se o chef demorar um pouco mais para responder, significa que ele teve que recomeçar tudo do zero (o "cache" não ajudou, porque "Pedro" não estava na prateleira).
• Se o chef responder muito rápido, significa que ele pegou a parte "Faça um bolo de chocolate para o" da prateleira e só precisou escrever "Pedro".

O atacante percebeu: "Ei, quando eu digo 'Pedro', demora. Quando eu digo 'João', é rápido? Não, espera... quando eu digo 'João', é rápido porque a vítima já pediu isso antes!".

Através de apenas medir o tempo que o chef leva para começar a responder, o atacante consegue adivinhar letra por letra o que a vítima pediu, sem nunca ter acesso ao pedido dela. É como se o tempo de espera fosse um código secreto que vazava a informação.

A Solução Antiga: "Todos na Própria Cozinha"

Para resolver isso, os restaurantes anteriores decidiram: "Ok, vamos proibir a prateleira de sobras compartilhada". Agora, cada cliente tem sua própria cozinha e seus próprios ingredientes.

• Vantagem: Ninguém pode espionar ninguém.
• Desvantagem: O restaurante fica lento e caro. Se 100 pessoas pedirem "Café com leite", o chef tem que fazer 100 vezes o café do zero, em vez de fazer uma vez e servir a todos. Isso é um desperdício enorme de tempo e dinheiro.

A Nova Solução: "CacheSolidarity" (Solidariedade do Cache)

Os autores deste artigo criaram um sistema chamado CacheSolidarity. A ideia é inteligente e baseada em "solidariedade", mas com limites.

Imagine que o restaurante agora tem um Gerente de Segurança muito esperto que vigia a prateleira de sobras.

1. A Regra da Solidariedade: Se você e seu amigo pedirem a mesma coisa, o gerente deixa vocês usarem a mesma prateleira. Vocês são "amigos" (usuários benignos) e isso acelera o serviço para todos.
2. O Sinal de Alerta: O gerente observa quem está usando a prateleira. Se ele vê que o "Cliente A" criou uma sobra (ex: "Bolo de chocolate para...") e o "Cliente B" (um estranho) começa a tentar usar essa mesma sobra para adivinhar o final, o gerente levanta uma bandeira vermelha.
3. O Bloqueio Seletivo: Assim que o gerente vê o "Cliente B" tentando usar a sobra do "Cliente A", ele bloqueia apenas aquele pedaço específico da prateleira para o Cliente B.
   • O Cliente B ainda pode usar as primeiras partes do pedido (que são públicas), mas no momento em que entra no "segredo", o sistema diz: "Pare! O Chef vai ter que fazer essa parte do zero para você".
   • Isso impede que o Cliente B descubra o segredo pelo tempo de espera, porque o tempo agora é sempre o mesmo (tempo de fazer do zero), não importa o que ele tente adivinhar.

Por que isso é genial?

• Não é um martelada: A solução antiga (isolar tudo) era como trancar a porta de todos os clientes. O CacheSolidarity é como trancar apenas a gaveta onde está o segredo, deixando o resto da casa aberto.
• Velocidade: Como a maioria dos pedidos não envolve segredos ou ataques, a "prateleira compartilhada" continua funcionando para 99% das pessoas. O restaurante continua super rápido.
• Segurança: O atacante não consegue mais medir o tempo para descobrir o segredo, porque o sistema força o recálculo sempre que detecta uma tentativa suspeita de compartilhar um prefixo sensível.

Resumo em uma frase

O CacheSolidarity é como um gerente de restaurante que deixa todos usarem os ingredientes comuns para serem rápidos, mas, assim que percebe alguém tentando "bisbilhotar" o segredo de outro cliente usando a mesma prateleira, ele imediatamente separa os ingredientes daquela pessoa específica, garantindo que o segredo permaneça seguro sem deixar o restaurante lento.

O sistema é leve, inteligente e garante que a segurança não precise custar a eficiência que torna a Inteligência Artificial tão útil hoje em dia.

Resumo técnico

1. O Problema: Vazamento de Informação por Canais Laterais de Tempo

Os Grandes Modelos de Linguagem (LLMs) dependem de otimizações como o Cache de Prefixo Automático (APC - Automatic Prefix Caching) para acelerar a inferência. O APC funciona reutilizando estados computados anteriormente (chaves e valores, ou KV) para a parte inicial de uma solicitação (prefixo) quando outra solicitação começa com o mesmo texto. Embora isso aumente drasticamente o throughput e reduza a latência, ele introduz um canal lateral de tempo em sistemas multi-tenant (multi-inquilino).

• Mecanismo do Ataque: Em um ambiente compartilhado, se um usuário (vítima) envia uma solicitação com um prefixo sensível e um atacante envia uma solicitação com um prefixo similar, o sistema pode gerar um "acerto" (hit) no cache para o atacante.
• Vazamento: Um acerto no cache é significativamente mais rápido do que um erro (miss), pois evita a recomputação. O atacante pode medir o Tempo até o Primeiro Token (TTFT) de suas próprias solicitações. Ao observar variações de latência, o atacante pode inferir se partes de sua entrada correspondem ao cache da vítima.
• Consequência: Isso permite ataques de roubo de prompt (prompt stealing), onde o atacante reconstrói incrementalmente o prompt sensível de outro usuário (ex: dados médicos, nomes, senhas) apenas enviando variações de texto e medindo o tempo de resposta.

2. Limitações das Defesas Atuais

O artigo identifica que as defesas existentes são excessivamente conservadoras ("abordagem de marreta"), sacrificando a eficiência:

1. Isolamento Total de Usuários: Desabilitar o compartilhamento de cache entre usuários. Isso elimina o canal lateral, mas destrói os benefícios de desempenho do APC, aumentando drasticamente a latência e reduzindo o throughput.
2. Ofuscação de Tempo: Inserir ruído artificial para equalizar os tempos de acerto e erro. Isso penaliza usuários benignos com atrasos desnecessários e não resolve a raiz do problema (o cache compartilhado).
3. Seleção Semântica: Usar LLMs para analisar semanticamente se um prompt é "sensível". Isso é computacionalmente caro, não escala bem e pode falhar em classificar corretamente solicitações.

3. Metodologia: O Sistema CacheSolidarity

O CacheSolidarity é uma solução de nível de sistema projetada para proteger o APC sem sacrificar o desempenho. A ideia central é que não é necessário isolar usuários inteiros, mas sim isolar apenas os prefixos específicos que se tornaram suspeitos de serem alvo de ataques.

Arquitetura e Componentes Principais:

1. Extensão do KV Cache (Metadados Leves):

   • Cada entrada no cache é estendida com dois campos de metadados mínimos:
     • OwnerID: Identifica o usuário que criou a entrada.
     • AttackFlag: Um marcador que indica se o prefixo foi reutilizado por múltiplos usuários e deve ser isolado.
   • Isso adiciona apenas alguns bytes por entrada, sem alterar o layout de tensores.

2. Detector (Mecanismo de Isolamento Seletivo):

   • Monitora os acessos ao cache.
   • Se um prefixo não marcado for acessado por um usuário diferente do OwnerID, o AttackFlag é ativado para aquela entrada.
   • Comportamento:
     • Se o atacante tentar continuar após um prefixo marcado, o sistema para a reutilização naquele ponto.
     • O restante do prompt é recomputado (criando novos caminhos de cache), impedindo que o atacante obtenha um "acerto" completo que revelaria o segredo.
     • O usuário original (OwnerID) continua tendo acesso total e sem restrições ao seu próprio caminho de cache, garantindo que usuários benignos não sejam penalizados.

3. Ativador (Otimização Dinâmica):

   • Reconhece que o canal lateral só é explorável sob certas condições (prefixos longos, modelos grandes, baixa carga do sistema).
   • Monitora continuamente a sobreposição das distribuições de tempo (TTFT) entre acertos e erros usando Estimativa de Densidade Kernel (KDE).
   • Lógica: Se a sobreposição for alta (diferenças de tempo indistinguíveis devido à carga do sistema ou ruído), o Activator desativa o isolamento seletivo para maximizar o desempenho. Se a sobreposição for baixa (diferenças claras), o isolamento é ativado.

4. Contribuições Chave

• Análise Motivacional: Demonstração detalhada de que a explorabilidade do canal lateral depende de parâmetros críticos (tamanho do prefixo, tamanho do modelo, carga do sistema e hardware), refutando a ideia de que o vazamento é sempre uniforme.
• Design de Sistema: Criação de um mecanismo de isolamento seletivo baseado em "solidariedade cooperativa": usuários benignos compartilham cache, mas o sistema se protege isolando apenas os caminhos suspeitos quando necessário.
• Análise de Segurança Formal: Caracterização das garantias de segurança, provando que o sistema impede a reconstrução de prompts, exceto em casos extremos (tentativa de adivinhar o primeiro token ou adivinhar o segredo na primeira tentativa sem prefixo prévio).
• Implementação e Código Aberto: Implementação sobre o vLLM (sistema de ponta a ponta) e compromisso de liberar o código para adoção pela comunidade.

5. Resultados da Avaliação

O sistema foi avaliado em um servidor com GPU NVIDIA A100, utilizando 9 modelos LLM (de 0.5B a 13B parâmetros) e cargas de trabalho multi-tenant realistas (baseadas em ShareGPT).

• Desempenho vs. Isolamento de Usuário:
  • O CacheSolidarity alcançou até 70% de reutilização de cache a mais do que as defesas de isolamento total de usuários.
  • Redução de 30% na latência de inferência (TTFT) em comparação com o isolamento total.
  • O desempenho do CacheSolidarity ficou muito próximo (dentro de 5-10%) do sistema sem proteção (APC puro), mas com segurança garantida.
• Overhead:
  • O custo de tempo por solicitação foi insignificante (~0.007 ms).
  • O custo de memória foi mínimo (32 bytes por entrada de cache).
• Eficácia contra Ataques:
  • Em simulações de ataque de roubo de prompt, o CacheSolidarity eliminou completamente os picos de taxa de acerto e as variações de tempo que permitiriam ao atacante identificar o segredo correto. O atacante não conseguiu distinguir qual tentativa foi bem-sucedida.

6. Significado e Impacto

O CacheSolidarity demonstra que a segurança em sistemas de LLM não precisa ser um compromisso com o desempenho. Ao invés de desabilitar otimizações críticas ou penalizar todos os usuários com ruído artificial, o sistema propõe uma abordagem adaptativa e granular.

• Princípio da Solidariedade: Usuários benignos continuam a se beneficiar da eficiência do cache compartilhado.
• Resiliência: O sistema se adapta dinamicamente às condições de carga, ativando proteções apenas quando o canal lateral é realmente explorável.
• Viabilidade Prática: Com overheads quase nulos e integração direta com sistemas modernos como o vLLM, o CacheSolidarity oferece uma solução pronta para produção que permite a operação segura de APIs de LLM multi-tenant, protegendo dados sensíveis sem degradar a experiência do usuário.

Em resumo, o trabalho preenche uma lacuna crítica entre a segurança e a eficiência, permitindo que o APC continue sendo uma ferramenta vital para a escalabilidade de LLMs, mas de forma segura contra ataques de canal lateral.