Quando o aprendizado de máquina conta a história errada
(jackcook.com)- O projeto de segurança de hardware do MIT reproduziu um ataque de canal lateral assistido por aprendizado de máquina viável no navegador e revelou a armadilha de achar que alta precisão do modelo prova a causa real
- Pesquisas anteriores sobre fingerprinting de sites atribuíam a causa à contenção de cache da CPU, mas uma abordagem que elimina acessos ao cache e apenas incrementa um contador simples obteve precisão maior em vários ambientes
- A equipe descartou, em sequência, as hipóteses de escalonamento de frequência da CPU, contenção entre núcleos da CPU e cache, e com instrumentação via eBPF confirmou que mais de 99% dos intervalos de parada acima de 100ns eram tratamento de interrupções
- Só os sinais de interrupções do sistema já revelavam a atividade de carregamento de sites, e em Chrome/Linux a precisão para identificar o site vítima entre 100 sites chegou a 96,6%
- Para projetar defesas, é preciso primeiro analisar e confirmar o mecanismo real do canal lateral, em vez de se basear apenas no fato de o modelo ter acertado
O que deu início à pesquisa
- Em 2020, na disciplina Secure Hardware Design do MIT, começou um projeto para reimplementar um ataque de fingerprinting de sites com base em experiência em desenvolvimento web e aprendizado de máquina
- Mengjia Yan percebeu que havia algo estranho em pesquisas recentes de fingerprinting de sites que atacavam fraquezas de hardware com aprendizado de máquina e propôs a reimplementação
- O projeto depois levou ao artigo There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack
- O trabalho ficou em 1º lugar no Intel 2024 Hardware Security Academic Award e entrou no IEEE Micro Top Picks de 2023
- A pesquisa trata de três eixos: ataques via navegador, vazamento por interrupções do sistema e erros de interpretação em aprendizado de máquina
Canais laterais e fingerprinting de sites
- O isolamento de processos separa a memória e os recursos dos aplicativos, mas em computadores reais recursos como placa de rede, GPU e CPU continuam sendo compartilhados
- Recursos compartilhados podem vazar, sem intenção, informações sobre a atividade do usuário
- Se alguém usando o mesmo roteador Wi‑Fi estiver assistindo a um vídeo pesado, o tempo de download de outro usuário pode ficar mais lento
- Variações no consumo de energia ou emissões eletromagnéticas também podem virar canais laterais para estimar chaves criptográficas ou atividade do usuário
- Fingerprinting de sites é um ataque em que um site malicioso aberto em uma aba tenta identificar o site vítima aberto em outra aba
- Um estudo anterior de Shusterman et al. apresentou um ataque que usa o cache da CPU para adivinhar qual site está aberto entre 100 sites candidatos
- O atacante cria um array do tamanho do cache da CPU e o preenche com 1
- Enquanto o site vítima carrega, mede a cada 2ms o tempo de acesso ao array
- Ao longo de 15 segundos, coleta um total de 7.500 medições
- Como cada site tende a repetir padrões parecidos de scripts, imagens, folhas de estilo e renderização, o traço de medições funciona como uma impressão digital
- Reunindo 100 traços para cada um dos 100 sites, forma-se um conjunto rotulado total de 10.000 amostras para treinar o modelo de aprendizado de máquina
- Em vários navegadores e sistemas operacionais, o método alcançou até 91,4% de precisão
O ataque por contador sem cache
- Na reimplementação inicial, classificar 4 sites foi fácil, e um classificador simples Random Forest obteve 98% de precisão
- Quando o experimento foi ampliado para 10 sites, a precisão no começo era 75%, mas depois melhorou até alcançar classificações com 10, 50 e 100 sites
- A mudança decisiva foi remover o acesso ao array de cache e fazer o atacante repetir
value++o mais rápido possível- Salvando periodicamente o valor do contador, fica registrado no traço quanto o computador conseguiu executar naquele intervalo
- Outras atividades, como redimensionar a janela do navegador ou abrir uma nova aba, também aparecem no traço do contador
- No artigo, o valor é salvo a cada 5ms para extrair mais informação em um tempo fixo
- O modelo treinado com traços de contador mostrou precisão de identificação de sites maior do que os traços tradicionais de latência de cache
- Esse resultado levantou dúvidas sobre se o ataque anterior realmente explorava contenção de cache e levou a uma análise para encontrar a causa real
A distância entre a precisão do modelo e a análise de causa
- Em ataques de canal lateral assistidos por aprendizado de máquina, o fato de o modelo prever de forma estável a atividade do usuário só demonstra a existência de um sinal
- Alta precisão não prova de qual canal lateral esse sinal veio
- Mesmo que o modelo de Shusterman et al. acertasse o site vítima com 91,4% de precisão, isso não significa que ele estivesse capturando contenção no cache da CPU
- O que o modelo encontra são correlações, não a explicação causal do sinal
- Uma análise errada da causa pode desviar o projeto de defesas
- Pesquisadores projetam defesas para tornar computadores mais seguros com base em artigos que descrevem ataques
- Se a causa do ataque for mal compreendida, tempo e esforço podem ser desperdiçados
Testando hipóteses: frequência, núcleos e interrupções
- A equipe comparou o ataque tradicional baseado em cache com o novo ataque baseado em contador em vários ambientes
- Na tarefa de identificar 100 sites, o ataque por contador obteve precisão maior em quase todas as configurações experimentais
- No Safari do macOS, o ataque por cache teve 72,6% de precisão, enquanto o ataque por contador chegou a 96,6%
- Na configuração padrão, a resposta correta entre 100 sites foi identificada com 95,2% de precisão
-
Hipótese de escalonamento de frequência da CPU
- CPUs modernas aumentam ou reduzem a frequência conforme a carga de trabalho para economizar energia
- A hipótese era que a frequência da CPU mudaria durante o carregamento do site vítima e alteraria o valor do contador
- Depois de desativar o escalonamento de frequência no BIOS, foram coletados novos dados e treinado um novo modelo
- A precisão caiu só 1 ponto percentual, de 95,2% para 94,2%, então a variação do contador dificilmente poderia ser explicada por mudança de frequência da CPU
-
Hipótese de contenção entre núcleos da CPU
- Se a aba do atacante e a da vítima rodarem no mesmo núcleo da CPU, o carregamento da vítima pode reduzir o tempo de execução do contador do atacante
- Com
tasksetno Linux, atacante e vítima foram fixados em núcleos diferentes - Mesmo com o escalonamento de frequência desligado, a precisão permaneceu em 94,0%
- Isso indica que a contenção entre núcleos também dificilmente era a principal causa
-
Hipótese de interrupções do sistema
- A hipótese seguinte foi que interrupções do sistema seriam o sinal por trás do ataque baseado em contador
- O sistema operacional usa interrupções para se comunicar com dispositivos de hardware como teclado, mouse, monitor e placa de rede
- Quando uma interrupção chega a um núcleo da CPU, o programa em execução naquele núcleo para imediatamente e o tratador de interrupção entra em ação
- Enquanto o site vítima carrega, vários dispositivos como rede e gráficos geram interrupções e, se elas forem tratadas no mesmo núcleo do atacante, o valor do contador pode cair
- No Linux, o tratamento de interrupções pode ser observado com
cat /proc/interrupts
Interrupções migráveis e não migráveis
- O Linux pode direcionar algumas interrupções migráveis para núcleos específicos
- Isso vale para interrupções com ID numérico
- Muitas vezes elas vêm de dispositivos externos, como teclado e placa de rede
- Muitas interrupções não migráveis não podem ser isoladas em um núcleo específico
- Isso vale para interrupções com ID de três letras
- Como são usadas para sincronizar atividade entre núcleos da CPU, precisam ser tratadas em todos os núcleos
- No ambiente experimental, elas respondiam pela maior parte da atividade de interrupções
- Com
irqbalance, as interrupções migráveis foram enviadas para o núcleo 1, enquantotasksetcolocou atacante e vítima nos núcleos 2 e 3 - Com a frequência da CPU também fixa, a precisão caiu quase 6 pontos percentuais, reforçando a hipótese das interrupções
A causa real confirmada com eBPF
- Como um experimento que isolasse completamente até as interrupções não migráveis era impossível por causa da arquitetura do sistema operacional, a execução foi instrumentada com eBPF
- Com eBPF, foram registrados dois tipos de momento
- quando o programa do atacante começava e parava
- quando o tratador de interrupção começava e parava
- Como a frequência da CPU estava fixa, se o atacante não fosse interrompido ele deveria executar quase o mesmo número de instruções em um intervalo fixo
- Com o código eBPF escrito por Jonathan Behrens, foram comparados os intervalos em que o atacante ficava parado e os intervalos de tratamento de interrupções
- Foi confirmado que mais de 99% dos intervalos de interrupção da execução do atacante com duração superior a 100ns correspondiam a tempo de tratamento de interrupções
- Na prática, o núcleo de CPU do atacante estava quase sempre fazendo uma de duas coisas: executar o código de contagem ou tratar interrupções; quando o tempo gasto com interrupções diminuía, o valor do contador subia, e quando aumentava, ele caía
Os dois principais resultados do artigo
- O primeiro resultado é que interrupções do sistema vazam atividade do usuário
- As propriedades de segurança das interrupções do sistema nunca haviam sido estudadas na literatura anterior
- A equipe foi a primeira a analisar um canal lateral baseado em interrupções do sistema
- O segundo resultado é que ataques de canal lateral assistidos por aprendizado de máquina precisam ser analisados com cuidado
- Modelos de aprendizado de máquina podem construir ataques poderosos mesmo sem compreender o canal lateral
- Sem instrumentar o sistema operacional, não seria possível concluir qual canal lateral estava sendo explorado
- Defesas anteriores contra ataques baseados em cache consistiam em expulsar repetidamente o conteúdo do cache da CPU para introduzir ruído
- Uma defesa que gera muitas interrupções, como enviar requisições de rede para um endereço IP local, funcionou melhor tanto contra o ataque baseado em cache quanto contra o baseado em contador
- Essa comparação reforça a evidência de que o ataque de Shusterman et al. se apoia principalmente em sinais de interrupção, e não no cache
Experimentos adicionais e possibilidades de defesa
- O artigo também inclui resultados adicionais
- Propõe uma forma de mitigar completamente o ataque modificando o clock do navegador exposto ao JavaScript
- Realiza um experimento de isolamento colocando atacante e vítima em máquinas virtuais separadas
- Analisa a frequência e o tempo de tratamento de várias interrupções não migráveis
- Os navegadores reduzem a precisão do clock oferecido ao JavaScript para dificultar ataques baseados em temporização de alta precisão
- O Chrome arredonda para 0,1ms e adiciona ruído aleatório
- Firefox e Safari arredondam para 1ms
- O Tor Browser arredonda para 100ms, reduzindo a precisão do ataque de 96,6% no Chrome para 49,8%
- Reduzir a precisão do clock tem trade-offs
- Engines de jogos no navegador precisam de temporizadores de alta precisão para renderização e animações
- Usuários do Tor Browser provavelmente terão dificuldade para jogar a maioria dos jogos, mas isso pode não ser um problema para quem prioriza segurança
Questões de pesquisa em aberto
- Interrupções do sistema estão ligadas a mecanismos de hardware profundos dos computadores modernos, como Spectre e Meltdown
- Hoje não há como implementar uma defesa que isole interrupções não migráveis do atacante, e não está claro como seria preciso redesenhar os computadores para tornar isso possível
- A relação entre atividade de sites e interrupções também ainda não é bem compreendida
- weather.com gerava muitas rescheduling interrupt, mas nytimes.com e amazon.com não
- Não foi analisado como imagens extras, anúncios e scripts afetam os traços do contador
- O ataque ainda pode ficar mais forte
- O artigo é mais um “artigo de análise” do que um “artigo de ataque”
- A precisão de 96,6% obtida em Chrome/Linux pode não ser um teto, e sim um piso
- Com modelos melhores ou outras metodologias, ainda pode haver aplicação em tarefas como classificar 1.000 sites, detectar se alguém está vendo um filme, usando VPN ou com que frequência verifica o Robinhood
- Defesas baseadas no navegador também precisam ser implementadas em navegadores reais e avaliadas quanto à praticidade para usuários comuns
O impacto da pesquisa na trajetória pessoal
- Antes deste projeto, entrar na pós-graduação não era uma opção considerada seriamente, e após uma experiência como estagiário de pesquisa em deep learning na NVIDIA a ideia era trabalhar em uma grande empresa de tecnologia ou startup de IA
- Depois do projeto, veio a percepção de que pesquisa pode ser divertida e bonita
- Após se formar no MIT, foi feito mais um ano no programa MEng em ciência da computação, e depois, com uma Rhodes scholarship, houve dois anos de estudo na University of Oxford
- No ano seguinte, está previsto o início de um PhD de seis anos em ciência da computação no MIT
1 comentários
Comentários do Hacker News
Bom texto, e a pesquisa por trás dele também é limpa
A contribuição do artigo, na verdade, não tem muito a ver com machine learning; vejo mais como a descoberta de um novo canal lateral usando interrupções
Aqui, machine learning parece servir mais para atrair leitores, e acho que não faria tanta diferença se chamassem de “estatística”
Lembro de um antigo orientador dizendo: “quando você descobrir do que seu artigo realmente trata, reescreva-o e remova as partes que antes achava que eram o tema”
Acho que o título desse artigo deveria ter focado no novo canal lateral, e não na história de machine learning. Mas isso é uma implicância pequena; é um trabalho excelente
A descoberta sobre o equívoco em machine learning é especialmente importante porque coloca em dúvida uma parte considerável da pesquisa em arquitetura de computadores existente
Antes, para fazer esse tipo de ataque, era preciso entender profundamente o canal lateral explorado, mas modelos de machine learning — neste caso, LSTM — permitem uma precisão muito maior do que simples “estatística” e tornam mais fácil criar ataques poderosos que exploram canais laterais pouco compreendidos
Hoje há muitos ataques auxiliados por machine learning criados dessa forma, e só o artigo de Shusterman et al. recebeu quase 200 citações, um número enorme para um artigo de arquitetura de computadores
O objetivo de publicar esse tipo de pesquisa é entender melhor os sistemas para criar defesas mais fortes, e o custo de entender errado e induzir a comunidade ao erro é alto
Mesmo que se tenha descoberto que a causa do ataque anterior era, no fim, o cache, esse ponto continua válido; mas a descoberta de um novo canal lateral no processo tornou a mensagem muito mais clara. O post do blog talvez pudesse ter enfatizado mais esse aspecto
Na prática, quando se está mergulhado em um mar de dados, esse bom senso pode se perder em meio a uma enxurrada de correlações, mas um bom desenho experimental e a revisão por pares deveriam, em tese, filtrar conclusões e interpretações fracas
Nesse sentido, este estudo de reprodução fez esse trabalho de forma excelente
Excelente texto. Eu não imaginava que seria possível entender ataques por canal lateral com tanta facilidade
Li como um mistério de assassinato em que você sabe desde o começo quem é o vilão, mas vai descobrindo “como ele fez”
Coloquei nos favoritos
Mas li por causa desta reação e, de fato, foi muito bom
A parte “No ano que vem, volto ao MIT para começar um doutorado de seis anos em ciência da computação. Eu não poderia estar mais animado!” é surpreendente
É impressionante que tudo tenha começado com uma ideia sortuda do autor de tentar usar contadores, em vez do ataque de expulsão de cache muito mais sofisticado do ataque por canal lateral original, e que isso tenha funcionado por causa de conceitos que ele ainda não conhecia na época
Eu, provavelmente uma pessoa como milhares de outras, não tive essa sorte, desisti cedo da ideia de ficar na academia e fui para a indústria, onde tive uma carreira comum
Comecei um Honours Degree australiano em ciência da computação, algo parecido com um mestrado, e por volta de 2010, muito antes da atual febre de IA, eu queria escrever um artigo sobre inteligência artificial com base em casos de aplicação que tinha aprendido em uma disciplina regular de IA
Minha ideia partia de como vinícolas usavam IA para melhorar a qualidade e a produção de vinho, e eu queria aplicar isso a usos mais “gerais”, mas o orientador designado não tinha nenhum interesse em ajudar, e sem outro apoio ficou difícil continuar
Especialmente porque eu tinha uma oferta de emprego em tempo integral com salário bastante bom, e, mesmo que tivesse continuado, provavelmente não teria produzido muita coisa
Como o autor também diz, as coisas deram certo graças ao orientador e ao apoio ao redor; sozinho, é preciso ter um impulso e talento enormes, e acho que eu não tinha nenhum dos dois
Durante meu primeiro doutorado no Japão, o professor e as pessoas ao redor passaram três anos criticando tudo que eu propunha, sem oferecer ideias viáveis
O professor do laboratório ao lado gostava da minha pesquisa, mas descobri isso tarde demais para mudar de laboratório
Agora estou em um lugar onde posso trabalhar com metade das pessoas do país — ou seja, duas pessoas no total — que conseguem entender completamente meu outro projeto e se importar com ele, e os dados delas já melhoraram o projeto
O diretor também tem uma boa impressão de mim e me inclui nas atividades do laboratório, mesmo eu não tendo vínculo formal
Em um ambiente assim, dá para ter sucesso. Encontrar o ambiente e as pessoas certas é difícil, mas é decisivo; sem isso, até um trabalho muito bom pode acabar sendo esforço desperdiçado
O texto foi bom
Como uma implicância muito pequena sobre a página, o estilo de separador com grandes pontos alinhados parecia um indicador de posição de carrossel de imagens, o que me confundiu
O texto é excelente, a explicação é muito acessível, e a demonstração interativa é realmente muito legal
Também gostei de terem contado o contexto de como começaram a trabalhar nisso
Muito interessante e bem explicado. Se já faz dois anos que a pesquisa saiu, coletores de dados interessados provavelmente já levaram isso em conta
Esqueça hackers. Isto é um exploit para empresas e governos
Será que um site que valoriza a privacidade poderia distribuir um pacote que gerasse interrupções aleatoriamente? Uma extensão de navegador poderia fazer isso para todos os sites?
Nossa contramedida que gera interrupções aleatoriamente foi implementada como extensão de navegador, e o código-fonte está aqui: https://github.com/jackcook/bigger-fish
Dito isso, é difícil recomendá-la para uso cotidiano. Nos testes, lembro que os tempos de carregamento das páginas ficaram cerca de 10% mais lentos
Algumas variaram bastante quando o computador estava sob uso intenso, mas parece possível que o Safari já tenha algumas mitigações
Ainda assim, o artigo é realmente muito legal