Por que as FPGAs exigem um modelo de confiança diferente

Arrays de portas programáveis em campo alimentam tudo, desde sistemas avançados de assistência ao condutor e cargas de satélite para loops de infraestrutura e controle industrial 5G. Nestes ambientes, uma única imagem de firmware desonesto pode corromper funções de segurança, exfiltrar segredos ou transformar um nó confiável em um vetor para movimento lateral. As disciplinas gêmeas de inicialização segura e atualizações de firmware criptograficamente validadas não são mais extras opcionais – elas são a base de um ciclo de vida confiável do FPGA. Este artigo explora os princípios arquitetônicos, modelos de ameaça e padrões de implementação que os engenheiros podem aplicar para bloquear bitstreams do FPGA e manter dispositivos resilientes em suas vidas operacionais.

Ao contrário de um microcontrolador endurecido, um FPGA não executa instruções de uma máscara ROM fixa. Ele carrega dados de configuração, muitas vezes chamados de bitstream, que definem o próprio tecido de hardware. Um bitstream adulterado pode instanciar lógica oculta, contornar proteções de memória ou leituras de sensores subvertidas sem alterar uma única linha de código de aplicação. Como o bitstream fica abaixo da camada do sistema operacional, ele goza de uma posição privilegiada na pilha, tornando o compromisso excepcionalmente difícil de detectar.

Várias tendências da indústria tornam a proteção de bitstream robusta crítica. Primeiro, densidades FPGA agora excedem um milhão de elementos lógicos, executando subsistemas complexos de processadores, aceleradores de criptografia e pipelines de inferência de IA no mesmo dado. Segundo, globalização da cadeia de suprimentos significa que os dispositivos podem ser fornecidos em fabricantes de contratos onde o acesso físico é descontrolado. Terceiro, após a implantação, mecanismos de atualização sobre o ar transformam cada interface de rede em uma superfície de ataque potencial. Neste contexto, a inicialização segura garante que o dispositivo começa de um estado conhecido, enquanto atualizações autenticadas impedem um adversário de semear o firmware malicioso no meio do ciclo de vida.

Paisagem de ameaça para dispositivos FPGA

Compreender os objetivos do adversário aguça o design de contramedidas. As ameaças caem amplamente em três categorias: interferência de tempo de fabricação, manipulação pré-boot e substituição de tempo de execução.

  • Injecção da cadeia de fornecimento: Os Adversários substituem ou modificam a memória flash que mantém o bitstream de arranque, quer durante a montagem da placa, quer durante o trânsito do dispositivo. Uma imagem de arranque assinada impede isto, falhando a autenticação antes de o FPGA configurar a sua lógica.
  • Extracção de canal lateral: Um atacante mede potência ou emanações eletromagnéticas para recuperar chaves de descriptografia. FPGAs modernas integram funções fisicamente inclunáveis (PUFs) e armazenamento de chaves endurecidas que nunca expõe chaves de texto simples para software, reduzindo drasticamente esta superfície de ataque.
  • Reconfiguração induzida por malware: Uma vez que um processador em execução no FPGA tenha sido comprometido, um atacante pode tentar empurrar um novo bitstream através da porta de configuração interna.Controles de acesso e autenticação de bitstream em tempo de execução podem bloquear o motor de configuração mesmo quando o próprio processador foi violado.
  • Ataques de nível inferior: Uma imagem de firmware válida, mas desatualizada, com vulnerabilidades conhecidas é re-flashada. Protocolos de atualização seguros devem rastrear metadados de versão e forçar contadores anti-rollback.
  • JTAG e abuso de interface de depuração: As portas de depuração deixadas ativas na produção fornecem um caminho direto para ler ou sobrescrever a memória de configuração. Endurecer essas interfaces com bits de bloqueio controlados por fusíveis ou exigir sequências de desbloqueamento assinadas é essencial.

Uma cadeia de inicialização segura corretamente arquitetada aborda cada um desses vetores verificando a autenticidade em cada fase: primeira imagem de inicialização, volumes de firmware subsequentes e qualquer sobreposição de carga tardia ou região de reconfiguração parcial.

Fundações de Bota Segura em FPGAs

O arranque seguro num FPGA verifica que o bitstream de configuração carregado no estado ligado se originou de uma fonte de confiança e não foi alterado. A cadeia de verificação assenta em três pilares: assinaturas criptográficas, uma raiz de confiança de hardware e um fluxo de arranque evidente.

1. Assinaturas criptográficas e hierarquia chave

Um esquema típico usa criptografia de chave pública. O fabricante ou integrador de sistema possui uma chave privada que assina o bitstream dourado. A chave pública correspondente, incorporada em eFuses programáveis de uma vez ou registros com bateria, atua como a raiz da confiança. Durante o arranque, um núcleo de IP rígido lê a assinatura anexada ao bitstream, recompõe o hash e verifica a assinatura contra a chave pública armazenada. Se a verificação falhar, o FPGA pode voltar a ser uma imagem conhecida, bloquear a interface de configuração ou afirmar uma redefinição do sistema.

Para limitar os danos de um compromisso chave, muitos desenhos adotam uma hierarquia de chaves de dois níveis: uma chave raiz primária que assina chaves secundárias, que, por sua vez, assina os fluxos de bits reais da aplicação. Isto permite que as teclas de aplicação rotativas sem reiniciar os eFuses, uma operação que é muitas vezes única na natureza. Para frotas que abrangem vários locais de implantação, um esquema de classificação também permite chaves de assinatura regionais ou específicas do cliente que limitam o raio de explosão de uma única chave.

2. Raiz de confiança do hardware

Um bloco de segurança endurecido dentro do FPGA fornece um ponto de partida imutável. Por exemplo, os dispositivos Xilinx incorporam um DNA de Dispositivo e uma área eFuse que pode armazenar um hash digest ou um hash de chave pública. As famílias Intel Agilex e Stratix 10 integram um Gerenciador de Dispositivos Seguros (SDM) que atua como um coprocessador para autenticação de inicialização. Estes blocos endurecidos lêem o flash externo através de uma sequência de comando autenticada, de modo que, mesmo que um atacante troque o chip flash, o FPGA não aceitará o fluxo de bits.

Quando o FPGA não possui um bloco de segurança completo, os engenheiros podem emparelhá-lo com um elemento seguro externo – como um Microchip ATECC608 ou um TPM – que armazena chaves e realiza verificação de assinatura. O IC externo se comunica por uma interface I2C ou SPI, e o FPGA se configura apenas após receber um sinal “verificado”. Esta abordagem adiciona um custo de componente, mas é um retrofit comum para famílias FPGA anteriores. Dispositivos mais novos do Semicondutor de Lattice, como o MachXO3D, incorporam um bloco de segurança endurecido semelhante que inclui flash on-chip para armazenamento de chaves e geração de PUF.

3. Fluxo de inicialização do Evidente-Apertador

O fluxo de inicialização deve ser projetado de modo que cada etapa autentice o próximo antes de passar o controle. Um fluxo mínimo se parece com isto:

  1. Hardware auto-teste:] O circuito de reset do FPGA estabiliza os relógios e verifica a integridade lógica interna. Muitos dispositivos incluem uma verificação CRC da própria memória de configuração.
  2. Carregamento da chave de root: O bloco de segurança carrega a chave pública do eFuses ou um elemento seguro. Em alguns projetos, esta etapa também deriva uma chave de decodificação de sessão da chave de root.
  3. Autenticação do Bitstream:] O bloco de carregador de arranque lê o bitstream candidato, calcula um hash SHA-384 ou SHA-256 e verifica a assinatura ECDSA ou RSA. Se o bitstream estiver criptografado, o motor de descodificação usa uma chave simétrica desembrulhada pela chave raiz.
  4. Fallback e shlock: Quando falha, o FPGA pode tentar novamente de uma imagem dourada designada armazenada em uma partição flash separada. Se a imagem dourada também falhar, o dispositivo deve entrar em um estado bloqueado com funcionalidade mínima, emitindo um indicador de falha de inicialização seguro para um plano de gerenciamento. Este estado pode ser sinalizado através de um GPIO dedicado ou uma mensagem sobre um barramento I2C para um monitor de sistema.

Muitos FPGAs suportam também bitstreams criptografados. A criptografia por si só fornece confidencialidade, mas não integridade, a menos que emparelhe com um modo de criptografia autenticado, como o AES-GCM. Sem autenticação, um atacante pode inverter bits no texto cifrado sem saber a chave, causando potencialmente um comportamento explorável. Portanto, a melhor prática é usar criptografia ao lado da verificação de assinatura ou confiar em primitivos criptografia autenticada onde existe suporte a silício.

Implementando uma Bota Segura: Uma Caminhada Prática

Os engenheiros que se aproximam de inicialização segura pela primeira vez frequentemente se apegam à integração com a ferramenta. Os passos seguintes delineiam um fluxo de implementação típico para um dispositivo Xilinx UltraScale+ ou Intel Agilex, embora os conceitos generalizem para famílias Lattice, Microchip e Gowin com variações menores.

Passo 1: Chaves de provisão com segurança

Gere um par de chaves ECDSA P-384 ou RSA-3072 em um módulo de segurança de hardware (HSM) mantido em uma instalação fisicamente segura. Hash a chave pública e programa o digest no eFuses do FPGA. Nunca expose a chave privada para o servidor de construção. Em vez disso, a assinatura é realizada pelo HSM, que recebe o hash bitstream e retorna uma bolha de assinatura. Este blob é então anexado ao arquivo bitstream. Para frotas, considere usar um serviço de HSM na nuvem, como o AWS CloudHSM ou o Azure Dedicated HSM para escalar o provisionamento em vários locais, mantendo as chaves sob proteção de hardware.

Passo 2: Configurar a imagem de inicialização

As ferramentas do fornecedor FPGA permitem- lhe indicar os parâmetros de autenticação durante a geração de bitstream. Você instrui a ferramenta para reservar espaço para a assinatura, definir a chave pública digerir e opcionalmente habilitar a criptografia com uma chave AES envolvida pela chave raiz. A imagem resultante é armazenada em um quad- SPI externo ou flash NAND acessível ao controlador de configuração do FPGA. Preste atenção ao layout flash: particione a memória em pelo menos dois bancos, um para a imagem ativa e outro para o retorno dourado, para permitir uma capacidade robusta de atualização A/B.

Passo 3: Definir as políticas de segurança em hardware

Grave o eFuses para bloquear o dispositivo no modo de arranque seguro. Uma vez configurado, o FPGA irá rejeitar qualquer bitstream que não tenha uma assinatura válida, incluindo imagens padrão fornecidas pelo fornecedor. Este passo irreversível só deverá ser executado após a validação completa do laboratório. Na produção, os programas ATE (equipamento de teste automatizado) aplicam as configurações de fusível como parte do teste de fim de linha. Algumas famílias também oferecem um modo de fusível "desenvolvimento" que permite que as imagens assinadas de uma tecla de teste arranque durante o arranque, com a chave de produção fundida posteriormente.

Passo 4: Teste a cadeia

Validar todos os cenários do mundo real: boot frio, restauração quente, recuperação de dados desativados e um bitstream deliberadamente corrompido. Medir a latência do boot - verificação da assinatura com aceleradores de hardware normalmente adiciona menos de 100 milissegundos, mas isso pode variar. Confirme que as botas de imagem douradas desativadas corretamente e que os indicadores de falhas se propagam ao controlador de gerenciamento do sistema. Inclua testes para o status bloqueado do JTAG: um atacante não deve ser capaz de ler ou reconfigurar o dispositivo através da interface de depuração após a execução do boot seguro.

Uma referência conhecida para tal fluxo é NIST Platform Firmware Resilience Guidelines, que descreve os requisitos de proteção, detecção e recuperação aplicáveis a qualquer dispositivo programável.

Arquitetura de atualização segura do Firmware

Mesmo a imagem de inicialização mais rigorosamente verificada eventualmente precisará de uma atualização, seja para corrigir uma vulnerabilidade, adicionar recursos ou alinhar com uma política de segurança revisada. O mecanismo de atualização deve fornecer integridade, autenticidade e proteção de retorno final, minimizando o tempo de inatividade.

Construindo um Pipeline de Atualização confiável

Um pipeline de atualização seguro começa na infraestrutura de engenharia e termina dentro da lógica de configuração do FPGA. As etapas principais são:

  1. Criação e assinatura de imagens: O sistema de compilação produz um novo bitstream. Um HSM assina-o com uma chave privada atualmente ativa. A assinatura pode ser embrulhada em um manifesto que inclui hashes de arquivos, metadados de versão e um timestamp.
  2. Segurança de transporte: A imagem assinada viaja sobre o TLS 1.3 para um servidor de atualização e depois para o dispositivo. A autenticação mútua entre o servidor e o terminal TLS do dispositivo evita ataques de homem-no-médio. O certificado TLS do dispositivo deve ser ligado à sua identidade única, como o DNA do dispositivo FPGA.
  3. Armazenamento estacionário: O dispositivo escreve a imagem recebida para uma partição flash dedicada, mantendo a imagem inicializável intacta. Este esquema de partição "A/B" garante que uma atualização falhada não bloqueia a unidade. Alguns projetos usam três partições: A (ativa), B (backup) e G (imagem de fábrica dourada) para máxima confiabilidade.
  4. Verificação pré-instalação: O agente de atualização – seja uma rotina de software em execução em um processador incorporado ou o próprio gerenciador de configuração do FPGA – valida a assinatura e verifica o número da versão em um contador anti-rollback armazenado. Se ambas as verificações passarem, ela marca a nova partição como a imagem ativa.
  5. [[FLT: 0]] Activação atómica: O ponteiro de configuração do arranque é actualizado numa única gravação segura. Na próxima redefinição, o FPGA inicia a nova imagem. Se a imagem se revelar inutilizável, um watchdog timer activa um retorno à partição anterior. O tempo- limite do watchdog deverá ser longo o suficiente para permitir uma tentativa de arranque completa, mas suficientemente curta para detectar um sistema bloqueado antes de um prazo crítico.

Técnicas Anti-Rollback

A assinatura da imagem é insuficiente se um atacante puder reproduzir uma versão de firmware válida, mas antiga. Para fechar esta lacuna, desenhe um contador anti- rollback armazenado numa memória monotônica não volátil, como o eFuses ou um módulo de plataforma confiável. Cada manifesto de firmware inclui um número mínimo de segurança. O agente de atualização compara este número com o contador armazenado e rejeita qualquer imagem cuja versão seja inferior. Quando uma nova atualização for aceita, o contador é avançado para essa versão. Dado que o eFuses só pode ser soprado em uma direção, eles formam um contador monotônico ideal para este fim. Para dispositivos que suportam fusíveis programáveis em campo, o contador pode ser incrementado remotamente como parte da transação de atualização, com um design seguro de perda de energia que verifica a gravação concluída antes de marcar a atualização como bem- sucedida.

Manuseando a Reconfiguração Parcial

Muitos projetos de alto desempenho usam uma reconfiguração parcial para trocar módulos de hardware em tempo de execução. Estes fluxos de bits parciais devem ser autenticados tão rigorosamente quanto os fluxos de bits completos. O fluxo da Função Dinâmica eXchange (DFX) Xilinx, por exemplo, suporta os fluxos de bits parciais autenticados onde cada módulo reconfigurado carrega sua própria assinatura. A porta de acesso interno da configuração do FPGA valida a assinatura antes de configurar a região dinâmica, impedindo que um processador comprometido carregue uma sobreposição maliciosa. Existem capacidades semelhantes no fluxo de reconfiguração parcial da Intel e nas integrações do analisador lógico Reveal da Lattice. Certifique- se de que as teclas de autenticação para fluxos de bits parciais são derivadas da mesma raiz de confiança, mas podem ser giradas independentemente para permitir o gerenciamento do ciclo de vida específico do módulo.

Primitivos criptográficos e considerações de desempenho

A escolha de algoritmos impacta tanto a segurança quanto o tempo de inicialização. As curvas ECDSA com P-256 ou P-384 oferecem assinaturas compactas e verificação rápida em aceleradores de hardware, tornando-o uma escolha popular. RSA-2048 ainda é comum em dispositivos mais antigos, mas requer maior armazenamento de chaves e tempos de verificação mais longos. Os algoritmos de transição do NIST para pós-quantum irão eventualmente afetar a autenticação de bitstream FPGA, mas a maioria das aplicações atuais operam dentro do modelo de segurança clássico.

Para criptografia de bitstream em massa, o AES-256 no modo GCM fornece tanto confidencialidade quanto integridade. Muitas famílias mais novas de FPGA incluem motores rígidos AES-GCM que podem descriptografar e autenticar bitstreams multimegabyte a velocidade do fio. Os engenheiros devem garantir que os vetores de inicialização (IVs) nunca sejam reutilizados; um gerador de números aleatórios baseado em hardware ou um contador monotônico embrulhado no gerenciador de chaves pode fornecer IVs únicos por sessão de inicialização.

Uma análise prática da latência de O guia de configuração do usuário da Xilinx mostra que habilitar a decodificação AES-256 e autenticação baseada em HMAC adiciona aproximadamente 50-80 milissegundos ao tempo total de configuração para um bitstream típico de 25 MB, dentro de limites aceitáveis para a maioria das aplicações incorporadas.Para aplicações críticas ao tempo, como a fusão de sensores automotivos durante a inicialização, os designers podem pré-autenticar o bitstream em um passo de fundo, enquanto o FPGA mantém I/Os em um estado seguro.

Gestão de Chaves Ao longo do ciclo de vida

A gestão de chaves é a parte mais difícil de qualquer esquema de arranque seguro. Um ciclo de vida consciente de utilização de segmentos chave em fases distintas:

  • Provisão de Fábrica: O hash de chave pública raiz é programado em eFuses. A chave privada está bloqueada em um HSM offline e nunca sai da instalação. Durante esta fase, a identidade única do dispositivo (por exemplo, DNA de dispositivo) pode ser fundida para permitir a ligação de chaves a unidades individuais.
  • Atualizações de campo: As chaves de assinatura secundárias são usadas para atualizações de firmware de rotina. Estas chaves são assinadas pela chave root e podem ter vida útil mais curta ou ser armazenadas em um HSM baseado em nuvem. A rotação de chave secundária pode ser automatizada para que um dispositivo nunca funcione com uma chave mais antiga do que, digamos, um ano.
  • Fim de vida: Quando um produto é desactivado, certificados de revogação ou um bit de "kill" pode ser configurado para desativar permanentemente a capacidade do FPGA de aceitar novo firmware, tornando o dispositivo inutilizável para um adversário que obtém acesso físico. Algumas soluções também suportam a eliminação criptográfica de todas as chaves armazenadas, soprando um eFuse dedicado.

A rotação automática de chaves pode ser implementada enviando um manifesto que contém a nova chave pública, assinada pela chave antiga. O agente de atualização verifica a cadeia, instala a nova chave em um registro protegido por gravação, e então avança o contador anti-rollback. A chave antiga pode ser retirada assim que o contador propaga-se a todos os dispositivos. Esta abordagem está documentada no IAB Internet of Things Software Update Workshop e se alinha com o padrão manifesto SUIT sendo desenvolvido pelo IETF (]IETF SUIT Manifest).

Regulamentação e Normas Industriais Alinhamento

Os engenheiros em setores automotivos, médicos e industriais devem alinhar a segurança do FPGA com as regulamentações do setor. ISO 21434 para veículos rodoviários requer um mecanismo seguro de atualização de software e uma raiz de confiança de hardware para qualquer lógica programável que afete a segurança. IEC 62443 para sistemas de controle industrial manda que os dispositivos verifiquem a integridade do firmware antes da execução e suportem atualizações autenticadas de campo. A avaliação de Critérios Comuns para perfis de proteção IP agora referencia requisitos para assinatura de bitstream de configuração. Seguindo os padrões arquitetônicos descritos anteriormente, as equipes de produtos podem satisfazer esses requisitos sem re-arquitetar a plataforma.

Para aplicações aeroespaciais e de defesa, padrões como DO-254 e FIPS 140-3 impõem requisitos adicionais ao módulo criptográfico e esquema de gerenciamento de chaves. Usando uma biblioteca criptográfica validada pelo FIPS para verificação de assinaturas, mesmo que implementada em tecido FPGA, pode simplificar a certificação. Além disso, a especificação TPM 2.0 do Trusted Computing Group fornece uma interface padronizada para armazenamento e certificação de chaves que podem ser aproveitadas por FPGAs com chips TPM externos.

Melhores práticas operacionais para a segurança da frota FPGA

A tecnologia por si só não pode garantir uma frota segura. As equipas devem envolver a sua implementação em práticas operacionais robustas:

  • Secure your build infrastructure: Isole o servidor de assinatura da LAN corporativa. Use um HSM físico para manter chaves privadas e registrar cada operação de assinatura. Implemente o código de avaliação que irá usar para qualquer alteração no manifesto de bitstream.
  • Forneça controles de acesso baseados em funções: Separe as tarefas de desenvolvimento, testes e implantação de bitstream. Apenas um gestor de lançamento designado deve ser capaz de iniciar a assinatura de uma imagem de produção. Use as regras de aprovação de duas pessoas no HSM para evitar a assinatura unilateral.
  • Monitor e auditoria:] As bases de dados de gerenciamento de ativos devem rastrear a versão de firmware, o valor do contador anti-rollback e o último tempo de inicialização bem sucedido para cada FPGA implantado. Os sistemas de detecção de anomalias devem sinalizar dispositivos que repetidamente se refiram a uma imagem dourada ou mostrar contadores de versão que se movem para trás. A telemetria pode ser coletada através de um agente leve em um processador incorporado ou através de uma CPU de gerenciamento dedicada.
  • Planeje para resposta a incidentes:] Tenha um procedimento pré-testado para distribuir uma atualização de firmware de emergência em resposta a uma vulnerabilidade de zero dias. Isto inclui manter uma lista de revogação para chaves comprometidas e garantir que o canal de atualização permaneça acessível mesmo em dispositivos parcialmente comprometidos. Pratique o procedimento em um ambiente de estadiamento pelo menos trimestral.
  • Conduzir testes de penetração regulares:] As avaliações de segurança externa devem segmentar especificamente a cadeia de configuração do FPGA. Os vetores comuns de ataque incluem a falha na fonte de alimentação durante o arranque, extrair bitstreams via JTAG, ou explorar a geração IV fraca no motor de descodificação. Inclua testes para ataques de injeção de falhas que tentam pular as etapas de autenticação.
  • Mantenha um inventário criptográfico: Mantenha um registro de todo o material chave, incluindo a chave pública raiz digerir, a autoridade de certificação chave pública, e as datas das rotações chave. Este inventário é essencial quando revogar ou atualizar chaves em toda a frota.

Essas práticas criam uma postura de defesa em profundidade que se estende do silício à infra-estrutura de nuvem.

O Futuro da Segurança FPGA: Pós-Quantum e Além

Olhando para o futuro, a transição para criptografia pós-quantum irá influenciar os projetos de inicialização seguros do FPGA. Sistemas de assinatura baseados em malha, como o CRYSTALS- Dilithium, oferecem tamanhos-chave menores do que o RSA para segurança equivalente, mas a velocidade de verificação e complexidade de implementação permanecem áreas de pesquisa ativas. Alguns fornecedores do FPGA começaram a demonstrar aceleradores de hardware para esses algoritmos, antecipando que o equipamento de infraestrutura de ciclo de longa duração precisará de um caminho de migração antes da chegada da computação quântica em larga escala. O processo de padronização pós-quantum do NIST, agora em suas etapas finais, fornecerá opções claras de algoritmo para autenticação de bitstream até 2024-2025. Os engenheiros que projetam produtos hoje devem garantir que o bloco de segurança rígido do FPGA possa ser atualizado para suportar novos algoritmos, ou incluir um acelerador de núcleo macio para verificação pós-quant que pode ser carregado via reconfiguração parcial.

Além disso, avanços na tecnologia PUF estão permitindo a geração de chaves específicas que nunca armazenam chaves em repouso, diminuindo ainda mais a superfície de ataque. Combine um PUF com uma cadeia de inicialização segura que mede a saída PUF contra um suporte armazenado – isso permite que cada FPGA dedique sua própria chave raiz sem qualquer injeção de chave durante a fabricação. Esta abordagem, já disponível em alguns dispositivos Intel e Lattice, elimina o risco de exposição chave durante o provisionamento.

Enquanto os primitivos criptográficos evoluem, os princípios subjacentes de inicialização segura e atualização de firmware medida permanecem constantes: a confiança âncora em hardware imutável, mede cada link da cadeia de inicialização e nunca permite que o código não assinado seja executado. Ao incorporar esses princípios no ciclo de vida FPGA, as equipes de engenharia podem acionar dispositivos que resistem aos adversários mais determinados e se adaptar graciosamente às ameaças futuras.