LIB-TRAP: Standard Cell Library Hardware Trojan Risk Assessment and Prevention

Resumo Técnico: LIB-TRAP: Avaliação de Risco e Prevenção de Hardware Trojan em Bibliotecas de Células Padrão

Problema
O modelo de fabricação de semicondutores fabless, que desacopla o design de CI da fabricação, introduz riscos de segurança significativos ao terceirizar a produção para fundições externas. Embora pesquisas existentes tenham explorado extensivamente a detecção e mitigação de Hardware Trojans (HT), focando frequentemente em HTs inseridos entre células padrão ou utilizando análise de canal lateral, existe uma lacuna crítica na avaliação das vulnerabilidades inerentes às próprias bibliotecas de células padrão. As metodologias de detecção atuais operam amplamente sob a premissa de que as bibliotecas de células padrão fornecidas pelas fundições são confiáveis e que os modelos de tempo/potência são precisos. Este artigo postula que, se uma fundição maliciosa controla a biblioteca de células padrão, ela pode embutir HTs furtivos diretamente nos blocos de construção fundamentais dos designs digitais, tornando os métodos de detecção tradicionais ineficazes.

Metodologia
Os autores propõem um novo modelo de ameaça, o LIB-TRAP, onde o adversário é uma fundição nefasta que manipula a biblioteca de células padrão antes que ela chegue à casa de design. A metodologia envolve três estágios principais:

1. Construção do Modelo de Ameaça: A fundição projeta uma carga útil de HT (especificamente uma célula de buffer modificada para funcionar como uma porta OR) que se ajusta às restrições geométricas e elétricas de uma célula padrão.
2. Tampering de Biblioteca e Caracterização:
   • A fundição cria uma versão "desativada" da célula infectada pelo HT, conectando a entrada de gatilho (trigger) a um valor constante benigno (ex: terra/ground). Isso garante que a célula retenha sua funcionalidade original e características de I/O durante a fase de síntese do design.
   • A fundição recaracteriza essa célula desativada usando ferramentas padrão de Automação de Design Eletrônico (EDA) (Synopsys SiliconSmart para 32nm e OpenRoad/ngspice para Sky130nm) para gerar arquivos .lib, LEF e GDSII precisos.
   • A biblioteca adulterada é fornecida ao cliente. A casa de design sintetiza seu netlist usando essas células, sem saber que a biblioteca contém HTs latentes.
3. Ativação: Durante a fabricação, a fundição substitui as instâncias das células desativadas por contrapartes "ativadas", conectando as entradas de gatilho a redes (nets) vizinhas. Isso ativa a carga útil (ex: forçando a saída para nível alto) sem alterar a pegada física da célula ou exigir pinos externos.

Para avaliar a furtividade deste ataque, os autores sintetizaram três circuitos de referência (AES-128, controlador Ethernet e WISHBONE DMA) usando bibliotecas limpas e infectadas com Trojan através das tecnologias Synopsys 32nm e SkyWater 130nm. Eles extraíram características de nível de design (contagem de células, área, potência dinâmica/estática e timing slack) para treinar classificadores de Aprendizado de Máquina (ML) (Regressão Logística, SVM, Random Forest e DNN) para distinguir entre designs infectados por Trojan e livres de Trojan.

Principais Contribuições

• Novo Modelo de Ameaça: Introdução de um vetor de ataque de HT baseado em células padrão onde a própria biblioteca é o vetor de comprometimento, desafiando a suposição de confiança nas bibliotecas fornecidas pela fundição.
• Implementação de Furtividade: Demonstração de como HTs podem ser integrados em células de buffer de modo que as variantes desativadas sejam funcional e parametricamente indistinguíveis de células benignas, mesmo sob análise de variação de processo (PV).
• Avaliação Empírica: Caracterização abrangente do ataque através de dois nós tecnológicos (32nm e 130nm) e múltiplos designs de referência, quantificando os excessos (overheads) de projeto físico.
• Análise de Limitação de Detecção: Teste sistemático de métodos de detecção convencionais e baseados em ML, revelando sua incapacidade de identificar esta classe específica de ataques.

Resultados

• Overhead de Projeto Físico: As células infectadas por HT foram dimensionadas para corresponder à força de drive e área originais. Os resultados experimentais mostraram overhead mínimo: os aumentos de área variaram de +1,6% a +6,7%, os aumentos de potência dinâmica de +2,7% a +4,6%, e as mudanças de potência estática foram inferiores a 1%. Essas variações caíram dentro dos limites de variação de processo de 3σ, tornando-as estatisticamente indistinguíveis do ruído normal de fabricação.
• Evasão de Canal Lateral: As células desativadas exibiram características de fuga (leakage) e atraso quase idênticas às células originais. O mecanismo de gatilho foi projetado para permanecer latente, garantindo que os perfis de potência, padrões de comutação e perfis térmicos sob vetores de teste padrão fossem idênticos aos designs livres de Trojan.
• Falha de Detecção por ML: Os classificadores de ML treinados em características de nível de design performaram mal, com acurácias de detecção variando entre 24% e 40% e F1 scores consistentemente abaixo de 0,40. Isso indica que o vetor de ataque proposto é efetivamente invisível para métodos de detecção que dependem de dados de fluxo de design tradicional e extração de características padrão.

Significância e Alegações
O artigo alega que o modelo LIB-TRAP expõe um ponto cego crítico nas práticas atuais de segurança de hardware. Ao explorar a posição privilegiada da fundição no controle do desenvolvimento da biblioteca de células, atacantes podem integrar HTs em blocos de construção fundamentais sem introduzir variações detectáveis em potência, área ou tempo. Os autores afirmam que a detecção tradicional e baseada em ML, que dependem da suposição de bibliotecas confiáveis e modelos golden precisos, são insuficientes contra esta ameaça.

A significância deste trabalho reside na demonstração de que mesmo algoritmos de detecção sofisticados falham quando a raiz do design (a biblioteca de células padrão) é comprometida. Consequentemente, os autores argumentam que o design seguro de CI não pode ser garantido sem estratégias de validação ascendentes (upstream), tais como:

1. Utilizar Análise de Canal Lateral (SCA) via rastreamento de potência para capturar HTs.
2. Realizar a verificação de equivalência entre esquemáticos de células e layouts GDSII para revelar inconsistências estruturais.
3. Recaracterizar independentemente as bibliotecas de células usando ferramentas confiáveis ou modelos SPICE golden para expor anomalias comportamentais.

O artigo conclui que, sem esses protocolos de verificação rigorosos que englobem tanto a análise de design quanto a validação física de canal lateral, a integridade dos designs de CI permanece vulnerável a hardware trojans furtivos baseados em biblioteca.