Uma pergunta que eu vejo confundir muita gente que está começando em hardware security: “qual é o método de detecção de hardware trojan?” — como se existisse um. Não existe. Existem uns quatro ou cinco métodos, cada um bom pra um tipo específico de trojan e cego pra outro tipo. Este artigo é o mapa prático: qual técnica você usa dependendo do que está procurando, e — mais importante — quando cada técnica simplesmente não vai funcionar, não importa quanto esforço você colocar nela.
Vou dividir por quando a detecção acontece: em tempo de teste (test-time) e em tempo de execução (run-time). E no final, cruzo isso com os tipos de trojan pra você ver onde cada método realmente serve.
Detecção em tempo de teste
Teste lógico
A ideia é simples: aplicar vetores de teste no circuito e comparar a resposta com o comportamento esperado. Se um trojan estiver ativo, a saída malformada aparece.
O problema é escala. Para um bloco combinacional com n entradas, o número de vetores possíveis é 2ⁿ — cresce exponencialmente. Testar exaustivamente é inviável a partir de um número modesto de entradas. E o pior: um trojan bem projetado usa exatamente uma condição rara como trigger — o tipo de vetor que teste aleatório dificilmente vai sortear, porque ele foi desenhado pra estar fora da distribuição normal de teste.
Técnicas de geração de vetores raros existem pra atacar esse problema especificamente, mas elas competem contra o mesmo limite estrutural: quanto mais raro o trigger, mais caro (em tempo e cobertura) é achá-lo por busca.
Side-channel analysis
Aqui você para de olhar pra saída lógica e passa a medir parâmetros físicos durante a operação:
- Canal de potência: mede corrente de alimentação em repouso e durante transientes. Um trojan pode aumentar consumo por corrente de fuga adicional ou chaveamento extra. Funciona bem — mas variação normal de fabricação e ruído do sistema geram taxa alta de falso alarme.
- Canal de tempo (delay): portas lógicas extras alteram o atraso de propagação de sinal em caminhos específicos do circuito. Exige visibilidade completa dos pontos de início e fim do caminho medido, e também é sensível a variação de fabricação.
- Emissão eletromagnética (EM): monitora padrões de chaveamento via emissão de campo. Mesma vulnerabilidade a ruído das outras duas.
A vantagem real do side-channel é que ele pega tanto trojans funcionais quanto paramétricos — esses últimos não alteram lógica nenhuma, só características físicas, e por isso são estruturalmente invisíveis pra teste lógico. É a única ferramenta desta lista capaz de enxergar esse tipo de ameaça.
Monitoramento em tempo de execução (run-time)
Já que nenhuma técnica de teste garante pegar todo trojan antes da fabricação sair de linha, monitoramento em runtime entra como camada complementar: unidades de observação instaladas no chip acompanham o comportamento continuamente durante operação real, e mecanismos de interrupção podem sinalizar ou parar o sistema se algo anômalo disparar.
Vantagem real: pega trojans que passaram batido em teste — inclusive os que só disparam depois de um volume de uso que nenhuma bateria de teste de fábrica reproduziria.
Custo real: as próprias unidades de monitoramento consomem energia e área, o que é um trade-off de performance que você paga em todo chip, sempre, mesmo quando não há trojan nenhum. E trojans always-on, que não produzem variação perceptível de comportamento, continuam escapando — porque não há “evento anômalo” pra runtime monitoring pegar quando o comportamento malicioso é constante desde o primeiro ciclo.
A tabela que realmente importa: método x tipo de trojan
Isso é o que costuma faltar nos guias genéricos sobre o assunto — cruzar técnica com tipo de ameaça, porque a resposta certa pra “qual método eu uso” depende inteiramente do que você está tentando pegar:
Trojans paramétricos (mudam parâmetro físico, não lógica): invisíveis para teste lógico, por definição — não existe vetor de entrada que revele uma mudança que não afeta a função lógica. Só side-channel (potência ou timing) tem chance real de pegar.
Trojans grandes: detectáveis tanto por teste lógico (porque a mudança funcional é significativa) quanto por side-channel (porque o impacto em consumo e delay é proporcionalmente grande). Este é o caso mais fácil — e, não por acaso, o menos comum em ataques bem executados.
Trojans pequenos: o consumo de energia extra é pequeno demais pra se destacar do ruído de fabricação normal — side-channel de potência fica cego. Teste lógico e medição de delay ainda têm alguma chance, dependendo do impacto funcional específico.
Trojans localizados (concentrados numa área): produzem variação de potência e delay mais concentrada e perceptível — mais fácil de pegar por side-channel.
Trojans distribuídos (espalhados pelo chip): o efeito de cada fragmento é diluído, dificultando análise de potência. Teste lógico e medição de delay ainda podem ajudar, dependendo de como o trojan afeta a função final.
Trojans always-on: como estão ativos desde sempre, não geram uma variação detectável como anomalia em potência ou em runtime monitoring — não há “antes e depois” para comparar. A pista mais confiável aqui costuma ser mudança de delay, porque mesmo uma alteração estrutural sutil no circuito tende a deixar uma marca mensurável na propagação de sinal, ainda que pequena.
O que fazer com isso na prática
Se você só tem orçamento pra uma técnica, a pergunta que decide qual escolher não é “qual detecta mais trojans em geral” — é “que tipo de trojan é mais provável, dado o meu modelo de ameaça”. Chip crítico com fornecedor de IP não auditado e alto risco de modificação funcional? Priorize teste lógico com geração de vetores raros. Preocupado com degradação de confiabilidade de longo prazo ou vazamento sutil por canal físico? Side-channel é obrigatório, teste lógico sozinho não serve pra nada ali.
Na prática, nenhuma organização séria usa uma técnica isolada. A combinação de teste lógico (robusto contra falso alarme, forte contra trojans pequenos funcionais) com side-channel (única ferramenta contra paramétricos) e monitoramento em runtime (rede de segurança pra tudo que passou pelas duas primeiras camadas) é o que efetivamente reduz o risco a um patamar administrável — nenhuma delas sozinha chega perto disso.
Se você ainda não decidiu como vai estruturar a fase de projeto para reduzir a superfície de ataque antes mesmo de chegar em detecção, é esse o assunto do próximo artigo desta série, sobre técnicas práticas de proteção contra hardware trojans.
