Detectar um hardware trojan depois que o chip já foi fabricado é sempre um jogo de probabilidade, e eu já cobri isso em outros dois artigos aqui no blog. Este aqui é sobre a pergunta anterior, que é mais barata de responder: como eu reduzo a chance de um trojan ser inserido em primeiro lugar? Prevenção não substitui detecção — mas reduz a superfície que a detecção precisa cobrir, e é bem mais barata de aplicar em escala.
Vou dividir por quando você aplica a técnica: antes da síntese (no RTL, antes do layout existir) ou depois (no layout físico já fechado).
Técnicas de pré-síntese
Verificação formal
Transformar a verificação de um IP num problema formal — property checking, model checking, equivalence checking — é a abordagem mais robusta que existe pra confirmar que um bloco faz exatamente o que a especificação diz, nem mais nem menos.
Um exemplo concreto: pra comparar dois módulos combinacionais, você pode verificar se uma expressão lógica envolvendo AND, OR e complementos dos dois circuitos sempre resulta em zero. Se resultar, a equivalência funcional está garantida — matematicamente, não por amostragem de teste. É esse “nem mais nem menos” que pega um trojan funcional escondido: qualquer lógica extra que altere o comportamento sob alguma condição vai quebrar a prova de equivalência.
Teste tradicional
Não descarte o óbvio: testar um IP contra as especificações continua útil, tanto pra validar funcionalidade quanto como primeira triagem contra trojans óbvios. Não é robusto sozinho — já expliquei por que no artigo sobre métodos de detecção — mas como camada inicial de baixo custo, ainda vale a pena.
Equivalência de máquinas de estado finito (FSM)
Para circuitos sequenciais, verificação formal pura de combinacional não basta — você precisa comparar comportamento ao longo de sequências de estado. A técnica de máquina produto resolve isso: combina os estados dos dois circuitos (mesmo que tenham números diferentes de estados) e verifica se, para qualquer sequência de entrada, as saídas correspondentes permanecem idênticas. Divergência em qualquer ponto indica não-equivalência — e, potencialmente, uma modificação maliciosa inserida em algum lugar da lógica de estados.
Isso importa especialmente quando você está integrando um IP sequencial de terceiro sem acesso ao RTL original completo — a máquina produto te dá uma forma de validar equivalência comportamental sem depender de confiar cegamente na documentação do fornecedor.
Técnicas de pós-síntese
Depois que o layout está fechado, o jogo muda: agora você está protegendo a implementação física contra inserção posterior (por exemplo, na fase de fabricação da máscara ou montagem).
Eliminação de espaço morto (dead space)
Espaço não utilizado no layout é, na prática, um convite. É onde um trojan pequeno e distribuído se esconde, porque não desloca nada que já existia.
Solução prática: preencher esses espaços com lógica dummy. Não elimina o risco totalmente, mas reduz drasticamente a área disponível pra inserção discreta sem alterar visivelmente o layout original.
Ofuscação de circuito
Ofuscar embaralha a lógica interna de um jeito que dificulta engenharia reversa. Se um atacante não consegue mapear com confiança o que cada bloco faz, fica muito mais difícil escolher um ponto estratégico pra inserir um trojan funcional que produza o efeito desejado sem quebrar alguma outra coisa por engano.
Blindagem e proteção de interface
Blindar trilhas e proteger interfaces — pinos de I/O, conexões entre módulos internos, redes de clock, scan chains — é o que permite monitorar e detectar sinais suspeitos depois. Não é prevenção pura, é prevenção que também habilita detecção: uma interface bem protegida e instrumentada é uma interface onde uma tentativa de ativação de trojan (por exemplo, via scan chain, que é um vetor de ataque clássico) fica visível mais cedo.
Técnicas específicas para aumentar a chance de detecção
Duas técnicas merecem menção separada porque não são “prevenção” nem “detecção” pura — elas mudam as condições do circuito pra tornar a detecção mais fácil depois.
Remoção de eventos raros
Hardware trojans dependem, na maioria dos casos, de triggers que só disparam sob condições extremamente raras — é assim que eles escapam de teste. A técnica aqui é inverter essa lógica: transformar eventos raros em eventos mais frequentes, forçando qualquer trigger malicioso a disparar bem mais cedo, dentro de uma janela de teste viável.
Um exemplo prático: modificar a lógica de um circuito hierárquico (por exemplo, um AND de dois níveis) pode aumentar significativamente a frequência de um evento que originalmente só ocorreria 1 em 256 vezes. Isso não elimina o trojan — mas aumenta drasticamente a chance de ele disparar durante teste normal, em vez de só em produção.
Registradores-sombra (shadow registers)
Medir o atraso entre registradores internos diretamente é complicado na prática. Um registrador-sombra — que compartilha o clock do sistema, mas com fase diferente — permite uma comparação detalhada com o registrador de destino. Qualquer discrepância entre os dois é um indicador confiável de que algo mudou a propagação de sinal ali — inclusive um trojan.
Quem já trabalhou nisso antes de você
Vale conhecer nomes por trás dessas técnicas, porque cada um resolveu uma fatia diferente do problema, e a literatura por trás disso é sólida o suficiente pra você não precisar reinventar a roda:
- Banga e Hsiao (2009) propuseram VITAMIN, que inverte a lógica de portas pra alterar a frequência de eventos.
- Gu, Qu e Zhou (2009) propuseram uma abordagem de information hiding que altera deliberadamente a especificação do sistema pra tornar qualquer modificação maliciosa mais perceptível.
- Chakraborty e Bhunia (2009) focaram em ofuscação de circuito pra dificultar tanto análise quanto inserção de trojan.
- Potkonjak (2010) endereçou o problema de construir circuitos confiáveis usando ferramentas de CAD não confiáveis — relevante justamente porque suas ferramentas de síntese e EDA também são uma dependência de terceiro.
- Love, Jin e Makris (2011) propuseram “proof carrying hardware”, embutindo prova de confiabilidade diretamente dentro do próprio IP.
O ponto prático
Nenhuma dessas técnicas sozinha resolve o problema — isso já devia estar claro a essa altura, se você leu os outros artigos desta série. Verificação formal e equivalência de FSM pegam trojans funcionais antes da fabricação. Preenchimento de dead space e ofuscação reduzem a superfície física de inserção depois. Remoção de eventos raros e registradores-sombra não previnem nada sozinhos, mas tornam qualquer trojan que passou pelas camadas anteriores muito mais fácil de flagrar depois, seja em teste ou em campo.
Combinar as duas fases — pré e pós-síntese — junto com as técnicas de detecção que eu cobri nos artigos anteriores desta série é o que de fato move a agulha. Tratar isso como uma única técnica de “solução definitiva” é subestimar um problema que a indústria de semicondutores ainda está ativamente resolvendo.
