Um projeto que eu acompanhei de perto usava um IP core licenciado de terceiros, sintetizado num FPGA, como parte central de um produto de processamento de sinal. O time de engenharia se preocupou bastante com a lógica funcional — validação, timing, integração — e quase nada com o fato de que o bitstream que configura aquele FPGA, se extraído e analisado, entrega o design inteiro, incluindo a lógica licenciada, pra qualquer concorrente com paciência suficiente pra fazer engenharia reversa. FPGA tem uma vantagem gigante de flexibilidade sobre ASIC — você reconfigura o hardware depois de fabricado — mas essa mesma flexibilidade é, ao mesmo tempo, superfície de ataque que ASIC dedicado simplesmente não tem.
O que torna FPGA um caso particular dentro de hardware security
Diferente de um ASIC, onde a lógica está fisicamente fixada no silício desde a fabricação, um FPGA carrega sua configuração — o bitstream — depois de fabricado, normalmente a partir de uma memória externa (flash) toda vez que o dispositivo liga. Isso cria uma categoria de risco que não existe da mesma forma em ASIC: o bitstream, se não for protegido, é um arquivo que descreve o design inteiro e pode ser extraído, copiado ou alterado sem tocar em silício nenhum.
As vulnerabilidades específicas
Overbuilding na fundição. Se a fabricação do FPGA (ou de componentes correlatos) é terceirizada, a fundição tecnicamente tem capacidade de produzir mais unidades do que o pedido contratado e vender o excedente por fora, sem o conhecimento ou consentimento do contratante. É um risco de cadeia de suprimentos, não de design em si, mas afeta diretamente quem depende de controle de quantidade pra modelo de negócio ou licenciamento.
Hardware trojans inseridos via terceiros. Blocos de IP licenciados de terceiros, ou até ferramentas de EDA comprometidas usadas no fluxo de síntese, são um vetor real de inserção de lógica maliciosa — o mesmo problema que discuti em detalhe no artigo sobre hardware trojans, aplicado especificamente ao contexto de FPGA, onde IP de terceiros é extremamente comum.
Engenharia reversa de bitstream e HDL. Um bitstream extraído (via dump da flash externa que armazena a configuração, por exemplo) pode ser analisado — em muitos casos até revertido de volta pra uma representação próxima do HDL original, dependendo da família de FPGA e das ferramentas disponíveis publicamente — entregando o design completo pra quem extraiu.
Clonagem pós-engenharia reversa. Uma vez que o design foi reconstituído, replicar em outro dispositivo (seja outro FPGA configurado com o mesmo bitstream, seja até migrado pra um ASIC dedicado com custo unitário menor em volume) é um caminho direto pra produto falsificado ou concorrente ilegítimo usando seu trabalho de engenharia.
Side-channel attacks. Assim como qualquer outro hardware processando operação criptográfica, um FPGA vaza informação por consumo de energia, tempo de resposta e emissão eletromagnética — os mesmos princípios que cobri no artigo sobre side-channel attacks se aplicam integralmente aqui, com o agravante de que designs em FPGA às vezes usam implementações de referência de bibliotecas de IP que não foram desenhadas pensando em resistência a esse tipo de ataque.
Replay attacks em reconfiguração. Se o mecanismo de atualização/reconfiguração do FPGA não verifica versão e integridade adequadamente, um atacante pode reverter deliberadamente pra uma versão de bitstream anterior com vulnerabilidade já conhecida e corrigida — o mesmo problema de rollback que discuti no artigo sobre secure boot, só que aplicado ao processo de reconfiguração do FPGA em vez do boot de um processador convencional.
Contramedidas, ameaça por ameaça
| Ameaça | Contramedida |
|---|---|
| Overbuilding | Hardware metering — mecanismos que exigem ativação remota por unidade, limitando o valor de unidades produzidas fora do contrato |
| Hardware trojans via IP de terceiros | Auditoria de segurança rigorosa em qualquer IP licenciado antes de integrar, e validação funcional que não se limita a “funciona conforme especificado” |
| Engenharia reversa de bitstream | Criptografia do bitstream (suportada nativamente pela maioria dos FPGAs modernos de fabricantes como Xilinx/AMD e Intel/Altera) e ofuscação de HDL |
| Clonagem | Watermarking digital e fingerprinting do design, permitindo provar origem em caso de disputa |
| Side-channel | Técnicas de mascaramento e minimização de emissão, as mesmas discutidas no artigo específico sobre side-channel attacks |
| Replay attacks na reconfiguração | Protocolo de atualização remota seguro, com verificação de versão mínima e integridade — mesma lógica de secure boot aplicada à reconfiguração |
Um ponto que costuma ser subestimado: criptografia de bitstream não é automática
A maioria dos FPGAs modernos de médio a alto custo já suporta criptografia de bitstream nativamente — a configuração chega criptografada e é decriptada internamente pelo próprio chip usando uma chave gravada em fusíveis, de forma semelhante ao boot criptografado que discuti no contexto de SoCs convencionais. O problema real que eu vejo repetidamente: esse recurso existe no datasheet, mas o time de projeto nunca o habilita, porque durante a fase de desenvolvimento é mais conveniente trabalhar com bitstream em texto plano (facilita debug, reprogramação rápida), e a decisão de “vamos habilitar criptografia antes de produção” fica pra depois — e “depois” tem o mesmo destino de qualquer item de segurança adiado indefinidamente: às vezes nunca acontece.
Se o seu FPGA suporta esse recurso (vale checar o datasheet específico do seu dispositivo, porque a implementação e o nível de proteção variam bastante entre fabricantes e famílias), a pergunta não deveria ser “vamos usar?” — deveria ser “por que ainda não estamos usando?”.
Onde priorizar, com recurso limitado
Se você está avaliando um projeto de FPGA que nunca passou por uma revisão de segurança, a ordem que eu sugeriria:
- Verificar se criptografia de bitstream está disponível no seu FPGA e habilitá-la — na maioria dos casos, é configuração, não redesign.
- Auditar qualquer IP de terceiros integrado ao design, com atenção especial a blocos que processam dados sensíveis ou chave criptográfica.
- Avaliar o processo de atualização/reconfiguração remota, garantindo verificação de versão e integridade.
- Só depois disso, investir em contramedidas mais específicas (watermarking, mascaramento contra side-channel), que endereçam ameaças mais direcionadas e geralmente têm custo de engenharia maior.
FPGA security compartilha fundamentos diretos com hardware trojans, side-channel attacks e secure boot — os três artigos que já publiquei aqui no blog. Se seu projeto usa FPGA com IP licenciado de terceiros, vale a leitura complementar dos três, porque cada um cobre uma fatia diferente do mesmo risco de cadeia de suprimentos e design.
