Detecção de Hardware Trojans e o Projeto de Circuitos Integrados Confiáveis - FortShield: Segurança para Desenvolvedores Profissionais

Aqui vai uma frase que eu quero que você leve deste artigo, porque ela muda como você pensa sobre segurança de hardware: não detectar um hardware trojan não é a mesma coisa que provar que o chip é seguro. Isso parece óbvio quando escrito assim, mas na prática é o erro mais comum em auditoria de IC — tratar “passou nos testes” como sinônimo de “confiável”.

Este artigo não é sobre técnicas específicas de detecção (isso já tem outro artigo aqui no blog, focado especificamente nos métodos). É sobre a pergunta anterior: o que significa, tecnicamente, chamar um circuito de “confiável” — e por que essa pergunta é mais difícil do que parece.

As quatro regiões do espaço de projeto

Quando você avalia a confiabilidade de um circuito fabricado, ele não cai simplesmente em “bom” ou “trojan”. O espaço de projeto se divide em quatro regiões:

Designs bem-sucedidos — atendem todas as especificações.
Designs falhos — não atendem alguns requisitos, sem que haja intenção maliciosa nisso. Defeito de fabricação comum.
Designs com funcionalidade maliciosa — contêm um trojan, que pode ou não ser pego pelos algoritmos de segurança que você está usando.
Designs “inocentes” — não têm comportamento malicioso, mas também não atendem certas especificações. Na prática, indistinguíveis de um design falho comum, exceto que aqui a falha não teve nenhuma origem maliciosa.

Repare no problema: as categorias 2 e 4 parecem idênticas do lado de fora — ambas falham em algo. E a categoria 3 pode, dependendo da qualidade do trojan e da qualidade do seu algoritmo de detecção, parecer idêntica à categoria 1. Você não está classificando “trojan vs. sem trojan” — você está tentando separar quatro grupos usando ferramentas que enxergam basicamente dois sinais: comportamento (bate ou não bate com a spec) e assinatura física (bate ou não bate com o chip de referência). Essa é a raiz de por que “confiança” em IC é probabilística, não binária.

Por que detectar trojan é estruturalmente difícil

Isso não é falta de esforço da indústria — é uma limitação de origem. Os métodos de teste e verificação tradicionais nasceram para pegar defeito de fabricação não intencional, não modificação maliciosa deliberada. São ferramentas desenhadas para outro problema, reaproveitadas.

Some a isso quatro fatores que jogam contra você:

Variedade de implementação: um trojan pode ser um bloco funcional inteiro ou uma mudança de um único transistor. Não existe assinatura universal.
Localização variável: pode estar em memória, em I/O, no datapath do processador — cada lugar exige uma abordagem de inspeção diferente.
Modo silencioso: a maioria fica inativa até o trigger disparar. Testar um chip “em repouso” simplesmente não revela nada.
Ruído de fabricação: variação de processo entre dois chips legítimos, saídos da mesma máscara, já produz diferença de consumo de energia e timing. Essa variação natural se mistura com qualquer sinal real de trojan, empurrando pra falso positivo ou falso negativo.

Se você já lidou com side-channel analysis pra outro propósito (por exemplo, atacar ou proteger uma implementação criptográfica), esse último ponto vai soar familiar — é o mesmo problema de sinal-ruído que aparece em power analysis attacks, só que aqui o “sinal” que você quer isolar é a presença de um trojan, não uma chave secreta.

As duas abordagens de detecção, em nível de estratégia

Sem entrar no detalhe técnico de cada método (de novo, isso fica pro artigo dedicado), existem duas famílias de abordagem, e a escolha entre elas é uma decisão de trade-off, não uma questão técnica pura:

Abordagem destrutiva. Remove o encapsulamento, expõe o die, faz engenharia reversa detalhada camada por camada. É a única abordagem que te dá certeza real sobre o que está fisicamente ali. O problema é óbvio: você destruiu o chip que analisou. Não dá pra fazer isso em cada unidade de uma linha de produção — só faz sentido como amostragem estatística ou auditoria pontual de altíssimo risco.

Abordagens não-destrutivas. Monitoramento em tempo de execução (observar sinais de controle e relações entrada-saída de blocos críticos durante operação real) e análise de canal lateral (medir consumo de energia, emissão eletromagnética). Ambas deixam o chip intacto e utilizável, mas ao custo de menos certeza — você está inferindo a partir de sinais indiretos, não observando a estrutura física diretamente.

Na prática, a decisão entre essas famílias depende de quanto o chip custa, quantas unidades você precisa validar, e qual é o custo de um trojan não detectado chegar a campo. Um chip de infraestrutura crítica ou de defesa justifica sacrificar amostras pra análise destrutiva. Um SoC de consumo em produção de milhões de unidades não.

A dinâmica do atacante: efetivo E discreto

Vale entender o outro lado da mesa, porque isso muda como você prioriza defesa. Quem projeta um hardware trojan bem-sucedido precisa acertar duas coisas simultaneamente, que puxam em direções opostas:

Efetividade: o trojan precisa disparar no momento certo e causar dano real quando ativado.
Discrição: ele precisa passar despercebido tanto em teste convencional quanto em análise de canal lateral.

O exemplo mais claro disso é o “kill switch” — um mecanismo que precisa ser ativável de forma controlada, sem alterar visivelmente o design original nem produzir uma assinatura elétrica óbvia em repouso. Todo trojan bem projetado é, no fundo, uma negociação entre esses dois objetivos — e é exatamente aí que mora a brecha que a defesa explora: um trojan mais efetivo tende a ser mais fácil de detectar, e um mais discreto tende a ser mais fraco. Poucos conseguem otimizar os dois eixos ao mesmo tempo, e é aí que multi-camada de defesa compensa.

O que isso significa pra construir um design “confiável”

Já que você não consegue provar ausência total de trojan, o objetivo realista de “trusted IC design” é reduzir a probabilidade e aumentar o custo de inserção não detectada, não eliminar o risco. Na prática isso significa:

Combinar múltiplas camadas de verificação — side-channel, monitoramento em runtime, verificação formal de sinais de controle — porque cada camada cobre uma fraqueza estrutural da outra.
Monitorar continuamente em sistemas críticos, não só validar uma vez na saída de fábrica.
Controlar rigorosamente componentes externos e conexões sem fio associadas ao chip, porque um trojan sem canal de ativação externo é um trojan sem gatilho utilizável.
Avaliar terceiros — fundições, fornecedores de IP, ferramentas de EDA — com o mesmo rigor que você avaliaria qualquer dependência de software não auditada, porque é exatamente isso que elas são.

“Confiável” em IC não é um selo que você ganha depois de rodar uma bateria de testes. É uma postura contínua de redução de risco. Se você quer entender as técnicas específicas por trás de cada uma dessas camadas — o que efetivamente cada método pega e o que ele deixa passar — é isso que eu detalho no próximo artigo desta série, sobre métodos populares de detecção.