Se você já leu o artigo aqui no blog sobre o que são hardware trojans, sabe o básico: trigger, payload, always-on vs. acionado por evento. O que aquele artigo não cobre — e que é exatamente o problema que você enfrenta quando está fazendo due diligence num design que passou por fundição terceirizada — é onde na cadeia de produção um trojan pode ter entrado, e que forma física ele assume dentro do chip. Sem essa taxonomia, você não sabe se está procurando um bloco de lógica adicional óbvio ou uma variação de 2% na largura de uma trilha de metal.
Este artigo é sobre isso: os três eixos de classificação que efetivamente mudam sua estratégia de auditoria.
Eixo 1: em que fase da cadeia de fabricação o trojan entrou
O modelo fabless — você projeta, terceiros fabricam — significa que seu design passa por pelo menos cinco fases distintas, e cada uma tem seu próprio vetor de ataque.
Especificação do sistema. Aqui se definem requisitos: consumo de energia, protocolos de comunicação, tamanho. Parece cedo demais pra um ataque, mas não é — um especificador malicioso (ou comprometido) pode alterar sutilmente a definição de um protocolo de comunicação de um jeito que abre uma brecha que só vai aparecer três fases depois, quando ninguém mais está olhando pra especificação original.
Projeto do circuito. Esta é, na prática, a fase mais vulnerável, e o motivo é simples: você quase certamente está usando IP de terceiros, ferramentas de EDA de terceiros, bibliotecas de padrão-cell de terceiros. Cada uma dessas dependências é uma porta que você não fechou você mesmo. Um trojan inserido aqui pode ficar escondido dentro de um bloco de IP licenciado que você nunca abriu pra inspecionar linha por linha — e por que abriria, se o fornecedor tem certificação e histórico?
Fabricação da máscara. Depois do projeto fechado, o layout vira máscara de litografia. Um ataque aqui não mexe na lógica — mexe na composição química ou na geometria física pra acelerar desgaste, por exemplo aumentando eletromigração nas redes de clock ou de alimentação. Isso não aparece em nenhuma revisão de RTL, porque a alteração acontece depois que o RTL já foi congelado.
Montagem do chip. Na integração de componentes, é possível adicionar trilhas extras conectando o die a pinos que vazam informação ou permitem controle não autorizado. Esse tipo de trojan literalmente não existe no design que você mandou pra fábrica — ele é acrescentado no empacotamento.
Fase de teste. Ironicamente, a etapa cujo propósito é pegar defeitos é também onde um trojan bem-feito passa despercebido: ele foi desenhado justamente para não disparar sob os vetores de teste padrão.
O ponto prático aqui: se você só audita RTL, você cobre uma fase de cinco. Se sua fundição é a única variável não controlada, foque energia de auditoria em mask fabrication e assembly, não em revisar o Verilog de novo.
Eixo 2: onde dentro do chip o trojan se instala
Independente da fase de inserção, o trojan precisa morar em algum bloco funcional do chip, e isso também é uma classificação útil porque muda a técnica de detecção:
- Unidades de processamento — alterações na lógica de execução comprometem funções críticas diretamente. Tende a ser mais fácil de pegar por teste lógico, porque afeta o resultado computacional.
- Memória — um trojan aqui pode alterar dados armazenados ou simplesmente observar e vazar o que passa por ali. Mais difícil de pegar por teste funcional puro, porque a memória “funciona” — só que também está sendo monitorada.
- Dispositivos de I/O — controlam a comunicação com o mundo externo, então um trojan aqui pode interceptar ou alterar dados em trânsito sem tocar no núcleo de processamento.
- Redes de alimentação e clock — mudanças aqui não vazam dado diretamente, mas podem causar falha operacional ou criar as condições pra um vazamento por canal lateral (side-channel) em outro lugar do chip.
Repare que os últimos dois — I/O e power/clock — são exatamente os pontos que side-channel analysis foi desenhada pra vigiar. Não é coincidência: quem projeta um trojan pensando em passar despercebido evita a unidade de processamento (fácil de testar) e prefere esses cantos mais “silenciosos”.
Eixo 3: característica física do trojan
Aqui está a distinção que mais importa na prática, e que costuma ser mal explicada: funcional vs. paramétrico.
Um trojan funcional adiciona ou modifica lógica — um bloco de processamento extra, uma porta lógica a mais controlando um sinal. Ele muda o comportamento do circuito. É, em teoria, detectável por teste lógico ou verificação formal, porque ele produz uma diferença de output sob as condições certas.
Um trojan paramétrico não muda uma única porta lógica. Ele altera parâmetros físicos — espessura de uma trilha, dimensionamento de um transistor — de um jeito que reduz a confiabilidade do componente ao longo do tempo, sem nunca produzir um output logicamente incorreto. Isso é fundamentalmente invisível pra qualquer verificação funcional, formal ou não. A única chance de pegar é medição física fina (side-channel, análise de degradação) — e mesmo assim, competindo com o ruído normal de variação de processo de fabricação, que já existe entre dois chips perfeitamente legítimos saídos da mesma máscara.
Some a isso duas dimensões adicionais que mudam a dificuldade prática de detecção:
- Tamanho e distribuição: um trojan grande e concentrado numa única área do chip tende a ser mais fácil de identificar — ele se destaca. Um trojan pequeno e espalhado explora os espaços vazios (dead space) do layout, e cada fragmento individual é pequeno demais pra chamar atenção.
- Exigência de redesenho de layout: alguns trojans só cabem se o layout inteiro for refeito — o que aumenta a chance de alguém perceber a diferença numa auditoria de layout. Outros são projetados pra se encaixar sem alterar significativamente o design original, o que os torna praticamente invisíveis numa comparação superficial de layout antes/depois.
Um exemplo concreto pra fixar
Pegue um circuito simples que calcula o quadrado de um número. Um atacante pode alterar esse circuito pra também aceitar entradas originalmente inválidas — digamos, 10 ou 11 — como uma espécie de “senha” que ativa uma função maliciosa. Isso é um trojan funcional, pequeno, provavelmente distribuído dentro do bloco aritmético, inserido na fase de projeto do circuito (provável candidato: dentro de um IP de terceiros). Trocar um sinal de controle por uma porta lógica adicional, criando um “kill switch” que liga ou desliga um bloco funcional inteiro, segue o mesmo padrão: pequena mudança estrutural, grande efeito quando ativado.
Note que nenhuma dessas alterações aparece como uma “porta lógica gigante e estranha” no meio do layout — o trojan bem-feito é, por definição, discreto em pelo menos um dos três eixos que acabei de descrever.
Por que essa taxonomia importa na prática
Ela não te dá um método de detecção — isso é assunto para o próximo artigo desta série, onde eu mapeio qual técnica de detecção pega qual tipo de trojan (e qual não pega de jeito nenhum). O que essa taxonomia te dá é a pergunta certa antes de escolher a técnica: em que fase da cadeia esse chip passou por mãos que eu não controlo, em que bloco funcional eu mais preciso confiar, e o que estou procurando é uma mudança de comportamento ou uma mudança de parâmetro físico. Sem responder isso primeiro, qualquer verificação que você rodar é só um chute.
