💻 computer science

State Authenticity under Multiple Bus Masters: A Non-Secure DMA Gap and Mitigation for TrustZone-M Proofs of Executio

Este artigo revela que as provas de execução do TrustZone-M são vulneráveis à manipulação de estado via controladores DMA não seguros, uma vez que as suas garantias de segurança dependem exclusivamente do isolamento da CPU, e propõe uma mitigação leve utilizando segurança de DMA por canal para garantir a autenticidade do estado contra todos os mestres de barramento.

Autores originais: Arash Razban

Publicado 2026-07-30

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Arash Razban

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mundo onde pequenos e baratos computadores estão espalhados por toda parte — dentro do seu termostato inteligente, do seu rastreador de fitness e até nos sensores de um chão de fábrica. Esses pequenos dispositivos devem ser repórteres honestos, enviando dados como leituras de temperatura ou contagens de movimento. Mas e se um hacker assumisse o controle de um desses dispositivos e começasse a mentir, inserindo dados falsos em um gigantesco banco de dados na nuvem? Para impedir isso, usamos uma "prova de execução" digital. Pense nisso como um tabelião para computadores: o dispositivo assina um recibo dizendo: "Eu prometo que executei este problema matemático específico exatamente como solicitado, sem que ninguém mexesse nos números".

Para que isso funcione, o dispositivo precisa de duas coisas: uma maneira segura de provar que executou o código correto e uma maneira de provar que os dados que utilizou (o "estado") não foram adulterados. O artigo que estamos discutindo analisa uma versão de alta tecnologia deste sistema de prova chamado TrustZone-M, que é integrado em muitos microchips modernos. É como um cofre superseguro dentro do chip que separa tarefas "confiáveis" de tarefas "não confiáveis". A grande questão é: se um hacker invadir o lado "não confiável", ele consegue mudar secretamente os dados enquanto o computador está fazendo sua conta, enganando o sistema para que assine um recibo falso? Este artigo investiga se as regras atuais do cofre são fortes o suficiente para deter um ajudante sorrateiro e invisível que pode escrever dados sem que o computador principal perceba.

A Caneta Invisível: Como um Hacker "Fantasma" Enganou um Chip Seguro

No jogo de alto risco da segurança embarcada, pesquisadores propuseram recentemente um esquema inteligente chamado SLAPP (Stateful Proofs of Execution). Imagine o SLAPP como um bibliotecário muito rigoroso que quer verificar se um aluno (o dispositivo) resolveu um problema de matemática corretamente. O bibliotecário verifica duas coisas: primeiro, se o aluno usou o livro didático correto (o código) e, segundo, se o aluno não trapaceou mudando os números em seu caderno (o estado) enquanto resolvia o problema.

A lógica do bibliotecário era simples e parecia à prova de falhas: "Se o aluno tentar mudar os números em seu caderno, ele deve primeiro abrir o livro didático para encontrar as instruções de como fazer isso. Mas, como temos um scanner mágico que observa o livro, qualquer alteração nas instruções seria detectada imediatamente. Portanto, se o livro parecer perfeito, os números no caderno também devem ser honestos".

Este artigo, no entanto, levanta a cortina para revelar uma falha nessa lógica. Os pesquisadores descobriram que o "aluno" não é o único que pode escrever no caderno. Existe um segundo escritor invisível: um controlador DMA (Direct Memory Access).

O Escritor "Fantasma"

Para entender o DMA, imagine o processador principal do computador (a CPU) como um chef de cozinha ocupado picando vegetais. O chef é o único autorizado a tocar a tábua de cortar (a memória) na cozinha. O chef é observado por uma câmera de segurança (o isolamento TrustZone-M) que garante que ninguém mais toque na tábua.

Mas espere! Há um braço robótico (o controlador DMA) sentado na cozinha. Este robesto é programado para mover ingredientes da geladeira para a tábua de cortar automaticamente. A câmera de segurança está observando apenas as mãos do chef. Ela não sabe que o robô existe. O robô pode esticar o braço, pegar um saco de farinha e despejá-lo na tábua de cortar enquanto o chef está ocupado picando. O chef nunca vê o robô, e a câmera de segurança nunca pisca porque as mãos do chef não se moveram.

No mundo do esquema de segurança SLAPP, o "robô" é o controlador DMA. Os pesquisadores descobriram que o sistema de segurança estava observando apenas o chef (a CPU). Ele assumia que, se o livro de receitas (memória do programa) não fosse alterado, ninguém poderia alterar os ingredientes (o estado). Mas o robô podia alterar os ingredientes sem tocar no livro de receitas.

O Ataque: Um Envenenamento Silencioso

Os pesquisadores montaram um teste em um chip real (um microcontrolador STM32L5) para ver se esse escritor "fantasma" poderia realmente quebrar o sistema. Eles criaram um cenário onde um hacker, que já havia assumido o controle da parte "não confiável" do chip, usou o robô DMA para trocar um número legítimo por um número falso bem no meio do cálculo.

Veja como o truque aconteceu:

A Verificação: A parte segura do chip verificou o caderno e viu que os números estavam limpos. Deu um sinal de positivo.
A Troca: Imediatamente após a verificação, mas antes que o resultado final fosse assinado, o robô DMA surgiu e substituiu o número por um valor "envenenado".
A Assinatura: O chip terminou a conta usando o número envenenado e assinou o recibo.
O Resultado: A câmera de segurança olhou para o livro de receitas, viu que ele estava intacto e aceitou o recibo como válido.

O resultado foi uma "prova de execução" que era matematicamente válida, mas factualmente mentirosa. O sistema certificou um resultado baseado em dados que haviam sido adulterados, tudo isso enquanto o computador principal pensava que estava tudo bem.

Por Que as Defesas Usuais Falharam

Os pesquisadores então perguntaram: "Por que a segurança integrada do chip não impediu isso?". Eles testaram três defesas padrão, e cada uma falhou por um motivo diferente e curioso:

A Tentativa de "Trancar o Robô": Eles tentaram dizer ao sistema de segurança para trancar o braço do robô. Mas o sistema disse: "Eu não controlo robôs; eu só controlo o chef". O portão de segurança simplesmente não se aplicava ao robô.
A Tentativa de "Trancar a Mesa": Eles tentaram trancar a tábua de cortar para que ninguém pudesse tocá-la. Mas isso era rigoroso demais! O chef também precisava escrever na tábua. Se eles trancassem a tábua, o chef não conseguiria fazer seu trabalho e todo o sistema pararia de funcionar.
A Tentativa do "Alarme": Eles tentaram configurar um alarme que tocaria se o robô tocasse na tábua. Mas o alarme só toca se alguém quebrar uma regra. Como o robô tinha permissão para tocar na tábua (era apenas o tipo errado de toque para essa regra de segurança específica), o alarme permaneceu silencioso.

A Solução: Domando o Robô

A solução não foi construir um muro maior ou um alarme mais alto. Foi dar ao robô seu próprio crachá de segurança. Os pesquisadores descobriram que o robô (o controlador DMA) na verdade tinha uma chave oculta dentro dele que poderia ser acionada pelo chef seguro.

Ao acionar essa chave, o mundo seguro poderia dizer: "Este braço robótico específico está agora sob meu controle. Se o hacker tentar dizer a ele para se mover, ele irá ignorá-lo e levantar uma bandeira vermelha".

Este ajuste foi surpreendentemente barato e fácil. Não atrasou o chef nem exigiu novo hardware. Os pesquisadores testaram isso protegendo todos os braços robóticos no chip. Quando tentaram o ataque novamente, o robô recusou-se a se mover, o alarme disparou e o recibo falso foi rejeitado.

A Grande Lição

A lição mais importante deste artigo não é apenas sobre um chip específico ou um truque de hacker específico. É uma lição sobre como pensamos sobre segurança.

Por muito tempo, os designers de segurança assumiram que, se você protegesse o cérebro principal (a CPU), você protegeria tudo. Este artigo prova que, em chips modernos, existem outras "mãos" alcançando a memória que o cérebro não vê. Se você quer confiar nos dados de um computador, você não pode apenas observar o cérebro; você tem que observar todas as mãos que podem tocar os dados.

Os pesquisadores mostraram que o sistema SLAPP, conforme publicado, tinha um buraco em sua lógica porque esqueceu dos "braços robóticos". Eles não apenas encontraram o buraco; eles mostraram exatamente como corrigi-lo com um ajuste simples e leve. É um lembrete de que, no mundo dos pequenos computadores, os hackers mais perigosos podem não ser aqueles digitando em um teclado, mas os robôs invisíveis trabalhando nos bastidores, esperando por alguém que esqueça de checar sua identificação.

Resumo Técnico: Autenticidade de Estado sob Múltiplos Mestres de Barramento

Definição do Problema
O artigo identifica uma lacuna crítica de integridade em provas de execução com estado em plataformas de uso comum Arm TrustZone-M, visando especificamente o esquema SLAPP (publicado na IEEE TIFS 2025). O SLAPP visa fornecer garantias de atestação remota de que um dispositivo embarcado de baixo custo executou uma função corretamente sobre um estado autêntico e não modificado, mesmo que o mundo não seguro esteja totalmente comprometido.

A vulnerabilidade central reside na Propriedade P4 (Autenticidade de Estado). O argumento de segurança do SLAPP baseia-se em uma redução: ele assume que qualquer adversário que manipule o estado atestado ( $S$ ) durante a execução deve modificar a memória do programa ($PMEM$) para fazê-lo. Como o SLAPP mede a integridade da $PMEM$, conclui-se que a manipulação do estado seria detectada.

No entanto, essa redução é inconsistente no hardware TrustZone-M. O isolamento baseado em endereço da plataforma (SAU/IDAU) restringe apenas a CPU. Outros mestres de barramento, como controladores DMA, não estão sujeitos aos atributos de segurança centrados na CPU. Na plataforma alvo STM32L5, os controladores DMA são não seguros e programáveis por padrão. Um adversário pode programar um canal DMA para escrever diretamente no estado atestado na memória de dados sem que a CPU execute quaisquer instruções, modificando assim $S$ enquanto deixa a $PMEM$ intacta. Consequentemente, a medição $h = H(PMEM, \dots)$ permanece válida, e a prova é aceita sobre um estado envenenado.

Metodologia
Os autores validam essa lacuna utilizando o exato hardware de referência e o modelo de adversário definidos pelo SLAPP:

Modelo de Ameaça: Um mundo não seguro totalmente comprometido com acesso a todo o código e dados não seguros, mas sem acesso à memória segura ou falhas de hardware.
Construção do Ataque: Os autores implementaram um ataque puramente baseado em software em uma placa NUCLEO-L552ZE-Q.
- Um adversário não seguro pré-arma um canal DMA (configurado para transferência memória-para-memória) para sobrescrever o estado protegido (um cache de resposta randomizada) com um valor venenoso.
- O ataque é disparado dentro da janela "verificar-então-confirmar" (check-then-commit): após o mundo seguro verificar o estado (CheckState), mas antes do estado ser confirmado (SetState).
- A transferência DMA executa de forma autônoma, corrompendo o estado sem intervenção da CPU.
Avaliação de Atomicidade: Os autores testaram o ataque contra tanto a configuração estrita do SLAPP (interrupções desabilitadas) quanto sua configuração relaxada. Eles demonstraram que desabilitar as interrupções da CPU não restringe o mestre de barramento DMA, o que significa que o ataque tem sucesso mesmo na configuração estritamente atômica, conforme publicada.
Análise de Defesas Nativas: O artigo avalia sistematicamente por que as instalações de isolamento nativas do TrustZone-M falham em mitigar isso:
- Controlador de Segurança de Periféricos (TZSC): Não governa os controladores DMA; tentar proteger os controladores via TZSC causa uma falha de inicialização (boot fault).
- Proteção de Memória Baseada em Blocos (MPCBB): Filtra com base nos atributos de segurança da transação (seguro vs. não seguro) em vez do mestre emissor. Não consegue distinguir entre uma escrita legítima da CPU não segura e uma escrita maliciosa de um DMA não seguro; proteger os blocos de memória bloqueia a CPU, quebrando o esquema.
- Controlador de Acesso Ilegal (TZIC): Apenas reporta violações; não pode impedir a transferência se o acesso for tecnicamente "legal" (mestre não seguro escrevendo em memória não segura).

Principais Contribuições

Primeira Demonstração em Silício: O artigo fornece a primeira prova empírica de que um esquema publicado de prova de execução com estado para TrustZone-M (SLAPP) falha em impor sua propriedade de autenticidade de estado contra um adversário DMA não seguro em seu próprio hardware de referência.
Independência de Atomicidade: Os autores mostram que a vulnerabilidade não é resultado de relaxamentos opcionais de atomicidade, mas afeta a configuração estritamente atômica, pois o mascaramento de interrupções da CPU não restringe os mestres de barramento.
Análise Sistemática de Defesa: Uma análise detalhada explicando por que as três primitivas de isolamento naturais do TrustZone-M (TZSC, MPCBB, TZIC) são insuficientes, estabelecendo restrições de design específicas para qualquer mitigação correta.
Mitigação Leve: Os autores propõem e validam uma correção mínima usando a segurança por canal nativa do controlador DMA (DMA_CCRx.SECM). Ao proteger o canal DMA a partir do mundo seguro durante o boot, o software não seguro é impedido de reprogramar o canal. Isso bloqueia o adversário no nível do mestre sem afetar a capacidade da CPU de ler/escrever o estado.
Princípio Geral: O artigo estabelece que, para qualquer esquema de atestação sobre estado mutável em uma plataforma com múltiplos mestres, a autenticidade deve ser mediada contra cada mestre de barramento capaz de escrever o estado, não apenas a CPU.

Resultos

Sucesso do Ataque: Na placa de referência, o adversário conseguiu corromper o estado atestado dentro da janela do protocolo. O esquema não levantou erros, e o verificador do protótipo aceitou a prova sobre a saída envenenada.
Sucesso da Mitigação: Quando todos os 16 canais DMA do dispositivo foram protegidos no boot:
- A tentativa do adversário de reprogramar o canal DMA foi interceptada (um erro de acesso ilegal foi disparado).
- O estado permaneceu não corrompido.
- O protocolo benigno executou corretamente com overhead negligenciável (a correção é uma escrita de registro única no tempo de boot).
- A correção mostrou-se "cirúrgica", bloqueando o caminho do DMA enquanto preservava o acesso legítimo da CPU ao estado.
Análise de Overhead: A configuração de atomicidade estrita (desabilitando interrupções) incorre em um custo de tempo real significativo (~654ms de janela mascarada), mas fornece zero benefício de segurança contra a ameaça do DMA. A configuração relaxada remove esse custo sem sacrificar a segurança contra este vetor de ataque específico.

Significância e Alegações
O artigo alega que o esquema específico do SLAPP, conforme publicado, não possui implementação de sua garantia de autenticidade de estado contra um adversário DMA não seguro em seu hardware de referência. A falha reside em uma redução inconsistente em seu argumento formal, que incorretamente equipara integridade de código com integridade de estado sob uma suposição de escritor único (CPU).

Os autores enfatizam que esta é uma falha do argumento e da implementação específica, não uma prova de que nenhuma atestação de estado segura seja possível no TrustZone-M. A mitigação proposta (segurança de DMA por canal) é suficiente para a carga de trabalho publicada do SLAPP (que não utiliza DMA) e restaura a propriedade de segurança pretendida. O artigo conclui que qualquer esquema de atestação futuro que raciocine sobre estado mutável em plataformas de múltiplos mestres deve explicitamente mediar todos os mestres de barramento, não apenas a CPU.