Pourquoi les FPGA exigent un modèle de confiance différent

Dans ces environnements, une image unique du firmware voyous peut corrompre les fonctions de sécurité, exfiltrer des secrets ou transformer un nœud de confiance en vecteur de mouvement latéral. Les deux disciplines des mises à jour sécurisées des firmwares et cryptographiques ne sont plus des extras optionnels – elles sont le fondement d'un cycle de vie fiable de FPGA. Cet article explore les principes architecturaux, les modèles de menace et les modèles d'implémentation que les ingénieurs peuvent appliquer pour verrouiller les flux de bits FPGA et garder les appareils résilients tout au long de leur vie opérationnelle.

Contrairement à un microcontrôleur durci, un FPGA n'exécute pas les instructions d'un masque ROM fixe. Il charge les données de configuration – souvent appelées bitstream – qui définissent le tissu matériel lui-même. Un bitstream altéré peut initier une logique secrète, contourner des protections de mémoire ou subvertir les lectures de capteurs sans modifier une seule ligne de code d'application.

D'abord, la densité des FPGA dépasse maintenant un million d'éléments logiques, la gestion de sous-systèmes complexes de processeurs, les accélérateurs de chiffrement et les pipelines d'inférence AI sur la même matrice. Deuxièmement, la mondialisation de la chaîne d'approvisionnement signifie que les appareils peuvent être fournis aux fabricants contractuels où l'accès physique est incontrôlé. Troisièmement, après le déploiement, les mécanismes de mise à jour en direct transforment chaque interface réseau en surface d'attaque potentielle.

Paysage de menaces pour les appareils FPGA

Comprendre les objectifs de l'adversaire affûte la conception des contre-mesures. Les menaces se répartissent en trois catégories : l'interférence dans le temps de fabrication, la manipulation pré-démarrage et la substitution dans le temps de fonctionnement.

  • Injection de chaîne d'alimentation:[Les adversaires remplacent ou modifient la mémoire flash qui maintient le bitstream de démarrage, soit pendant l'assemblage de la carte, soit pendant le transit de l'appareil.
  • Extraction de canaux latéraux:[ Un attaquant mesure la puissance ou les émanations électromagnétiques pour récupérer les clés de déchiffrement. Les FPGA modernes intègrent des fonctions physiquement incontrôlables (PUF) et un stockage de clés durci qui n'expose jamais les clés en texte clair au logiciel, réduisant ainsi fortement cette surface d'attaque.
  • Reconfiguration induite par le malware:[ Une fois qu'un processeur fonctionnant sur le FPGA a été compromis, un attaquant peut tenter de pousser un nouveau bitstream via le port de configuration interne.
  • Attaques de dégradation:[ Une image firmware valide mais périmée avec des vulnérabilités connues est re-clashée. Les protocoles de mise à jour sécurisés doivent suivre les métadonnées de la version et faire appliquer les compteurs anti-retour.
  • JTAG et debug interface abus:[ Les ports de débogue laissés actifs en production fournissent un chemin direct pour lire ou écraser la mémoire de configuration.

Une chaîne de démarrage sécurisée correctement conçue s'adresse à chacun de ces vecteurs en vérifiant l'authenticité à chaque étape : première image de démarrage, volumes de firmware ultérieurs, et toute zone de superposition tardive ou de reconfiguration partielle.

Fondations de la sécurité des démarrages sur les FPGA

Le démarrage sécurisé d'un FPGA vérifie que le bitstream de configuration chargé à power-on provient d'une source de confiance et n'a pas été modifié. La chaîne de vérification repose sur trois piliers : les signatures cryptographiques, une racine matérielle de confiance et un flux de démarrage non conforme.

1. Signatures cryptographiques et hiérarchie des clés

Un schéma typique utilise la cryptographie à clé publique. Le fabricant ou l'intégrateur de système détient une clé privée qui signe le bitstream doré. La clé publique correspondante, intégrée dans des registres eFuses programmables ou des registres à piles, agit comme la racine de confiance. Pendant le démarrage, un noyau IP dur lit la signature annexée au bitstream, recompile le hash et vérifie la signature contre la clé publique stockée. Si la vérification échoue, le FPGA peut revenir à une image connue, verrouiller l'interface de configuration ou affirmer une remise à zéro du système.

Pour limiter les dommages causés par un compromis clé, de nombreux modèles adoptent une hiérarchie clé à deux niveaux : une clé racine primaire qui signe les clés secondaires, qui signent à leur tour les flux de bits d'application réels. Cela permet de rotationner les clés d'application sans rebrûler eFuses, une opération qui est souvent de nature unique.

2. La racine matérielle de la confiance

Un bloc de sécurité durci à l'intérieur du FPGA fournit un point de départ immuable. Par exemple, les appareils Xilinx intègrent un DNA de périphérique et une zone eFuse qui peuvent stocker un digest de hachage ou un hash à clé publique. Les familles Intel Agilex et Stratix 10 intègrent un Gestionnaire de périphériques sécurisé (SDM) qui agit comme coprocesseur pour l'authentification de démarrage. Ces blocs durcis lisent le flash externe via une séquence de commande authentifiée, donc même si un attaquant échange la puce flash, le FPGA n'acceptera pas le bitstream.

Lorsque le FPGA manque d'un bloc de sécurité complet, les ingénieurs peuvent le jumeler avec un élément de sécurité externe, comme un Microchip ATECC608 ou un TPM, qui stocke les clés et effectue la vérification de signature. L'IC externe communique sur une interface I2C ou SPI, et le FPGA se configure seulement après avoir reçu un signal --vérifié. Cette approche ajoute le coût des composants mais est une adaptation commune pour les familles FPGA antérieures.

3. Débit de démarrage de type Tamper-Evident

Le débit de démarrage doit être conçu de manière à ce que chaque étape authentifie la prochaine avant de passer le contrôle.

  1. Auto-test de la mémoire :[ Le circuit de réinitialisation de la puissance FPGA stabilise les horloges et vérifie l'intégrité logique interne.
  2. Charge de la clé de roulis:[ Le bloc de sécurité charge la clé publique à partir d'eFuses ou d'un élément sécurisé. Dans certains modèles, cette étape dérive également une clé de décryptage de session de la clé racine.
  3. Authentification du flux de démarrage:[ Le bloc de chargeur de démarrage lit le flux de bits candidat, calcule un hachage SHA-384 ou SHA-256 et vérifie la signature ECDSA ou RSA. Si le flux de bits est chiffré, le moteur de décryptage utilise une clé symétrique déballée par la clé racine.
  4. Fallback et verrouillage:[ En cas de défaillance, le FPGA peut réessayer à partir d'une image dorée désignée stockée dans une partition flash séparée. Si l'image dorée échoue également, l'appareil doit entrer dans un état verrouillé avec une fonctionnalité minimale, émettant un indicateur de défaillance de démarrage sécurisé sur un plan de gestion. Cet état peut être signalé via un GPIO dédié ou un message sur un bus I2C vers un moniteur système.

De nombreux FPGA prennent également en charge les bits chiffrés. Le chiffrement fournit à lui seul la confidentialité mais pas l'intégrité à moins d'être associé à un mode de chiffrement authentifié tel que AES-GCM. Sans authentification, un attaquant peut retourner des bits dans le chiffrement sans connaître la clé, ce qui peut entraîner un comportement exploitable.

Mise en œuvre d'un démarrage sécurisé : une marche pratique

Les ingénieurs qui s'approchent de démarrage sécurisé pour la première fois sont souvent en phase avec l'intégration de la chaîne d'outils. Les étapes suivantes décrivent un flux d'implémentation typique pour un appareil Xilinx UltraScale+ ou Intel Agilex, bien que les concepts généralisent aux familles Lattice, Microchip et Gowin avec des variations mineures.

Étape 1: Clés de fourniture en toute sécurité

Générez une paire de clés ECDSA P-384 ou RSA-3072 dans un module de sécurité matérielle (HSM) détenu dans une installation physiquement sécurisée. Hash la clé publique et programmez le digest dans les FPGA. Ne jamais exposer la clé privée au serveur de construction. La signature est plutôt effectuée par le HSM, qui reçoit le hash bitstream et retourne un blob signature. Ce blob est ensuite ajouté au fichier bitstream. Pour les flottes, envisagez d'utiliser un service HSM cloud comme AWS CloudHSM ou Azure Dediced HSM pour mettre à niveau la fourniture à travers plusieurs endroits tout en maintenant les clés sous protection matérielle.

Étape 2: Configurer l'image de démarrage

Les outils FPGA seller , vous permettent de spécifier les paramètres d'authentification pendant la génération bitstream. Vous demandez à l'outil de réserver de l'espace pour la signature, de définir le digest de la clé publique et d'activer le chiffrement avec une clé AES enveloppée par la clé racine. L'image résultante est stockée dans un flash externe quad-SPI ou NAND accessible au contrôleur de configuration FPGA , et ce, pour permettre une mise à jour A/B robuste.

Étape 3: Définir les politiques de sécurité dans le matériel

Une fois le système configuré, le FPGA rejettera tout flux de bits qui n'a pas de signature valide, y compris les images par défaut fournies par le fournisseur. Cette étape irréversible ne doit être exécutée qu'après validation en laboratoire. En production, les scripts ATE (équipement de test automatisé) appliquent les paramètres de fusible dans le cadre du test de fin de ligne. Certaines familles offrent également un mode de fusible « développement » qui permet aux images signées d'une clé de test de démarrer lors de l'introduction, la clé de production étant fusionnée plus tard.

Étape 4: Tester la chaîne

Valider tous les scénarios du monde réel : démarrage à froid, réinitialisation à chaud, récupération de l'image en panne et un flux de bits délibérément corrompu. Mesurer la latence des démarrages – vérification de la signature avec des accélérateurs matériels ajoute généralement moins de 100 millisecondes, mais cela peut varier. Confirmer que l'image en chute d'or se propène correctement et que les indicateurs de défaillance se propagent au contrôleur de gestion system. Inclure des tests pour l'état verrouillé JTAG : un attaquant ne devrait pas pouvoir lire ou reconfigurer l'appareil à travers l'interface de débogage après que le démarrage sécurisé est appliqué.

Une référence bien connue pour un tel flux est NIST , qui décrit les exigences de protection, de détection et de récupération applicables à tout dispositif programmable.

Architecture de mise à jour sécurisée du micrologiciel

Même l'image de démarrage la plus rigoureusement vérifiée aura besoin d'une mise à jour – qu'il s'agisse de corriger une vulnérabilité, d'ajouter des fonctionnalités ou de s'aligner sur une politique de sécurité révisée.

Créer un pipeline de mise à jour fiable

Un pipeline de mise à jour sécurisé commence dans l'infrastructure d'ingénierie et se termine dans la logique de configuration FPGA. Les étapes clés sont les suivantes :

  1. Création et signature d'images : Le système de construction produit un nouveau bitstream. Un HSM le signe avec une clé privée actuellement active. La signature peut être enveloppée dans un manifeste qui comprend des hachages de fichiers, des métadonnées de versions et un horodatage.
  2. Sécurité de transport:[ L'image signée voyage sur TLS 1.3 vers un serveur de mise à jour puis vers l'appareil. L'authentification mutuelle entre le serveur et l'appareilLe paramètre TLS empêche les attaques de l'homme dans le milieu.Le certificat TLS de l'appareil doit être lié à son identité unique, comme l'ADN du périphérique FPGA.
  3. Stockage stable: L'appareil écrit l'image entrante sur une partition flash dédiée, maintenant intacte l'image amorçable actuelle. Ce schéma de partition -A/B- garantit qu'une mise à jour ratée ne brique pas l'unité. Certains modèles utilisent trois partitions : A (active), B (backup) et G (image d'usine dorée) pour une fiabilité maximale.
  4. Vérification de pré-installation:[ L'agent de mise à jour – qu'il s'agisse d'une routine logicielle exécutée sur un processeur intégré ou sur le gestionnaire de configuration de FPGA – valide la signature et vérifie le numéro de version sur un compteur anti-retour stocké. Si les deux contrôles passent, il marque la nouvelle partition comme image active.
  5. Activation atomique: Le pointeur de configuration de démarrage est mis à jour dans une écriture à sécurité électrique unique. Lors de la prochaine réinitialisation, le FPGA démarre à partir de la nouvelle image. Si l'image s'avère inutilisable, un minuteur de veille déclenche un retour à la partition précédente. Le délai de sortie du chien de garde devrait être assez long pour permettre une tentative de démarrage complète, mais assez court pour détecter un système bloqué avant une date critique.

Techniques anti-roulard

Pour combler cette lacune, il suffit de signer l'image si un attaquant peut rejouer une version firmware valide mais ancienne. Pour la réduire, il suffit de concevoir un compteur anti-roulement stocké dans une mémoire monotonique non volatile telle que eFuses ou un module de plateforme de confiance. Chaque manifeste firmware comprend un numéro de version de sécurité minimum. L'agent de mise à jour compare ce numéro avec le compteur stocké et rejette toute image dont la version est inférieure. Lorsqu'une nouvelle mise à jour est acceptée, le compteur est avancé à cette version. Comme eFuses ne peut être soufflé que dans une seule direction, il s'agit d'un compteur monotonique idéal à cette fin.

Gestion de la reconfiguration partielle

De nombreux modèles à haute performance utilisent la reconfiguration partielle pour échanger des modules matériels au moment de l'exécution. Ces bitstreams partiels doivent être authentifiés aussi rigoureusement que les bitstreams complets. Le flux Xilinx Dynamic Function eXchange (DFX) supporte par exemple les bitstreams partiels authentifiés où chaque module reconfigurable porte sa propre signature. Le port d'accès de configuration interne FPGA valide la signature avant de configurer la région dynamique, empêchant un processeur compromis de charger en face une superposition malveillante. Des capacités similaires existent dans le flux de reconfiguration partielle Intels et les intégrations d'analyses logiques de Lattice.

Primitifs cryptographiques et considérations de performance

Le choix des algorithmes affecte à la fois la sécurité et le temps de démarrage. ECDSA avec courbes P-256 ou P-384 offre des signatures compactes et une vérification rapide sur les accélérateurs matériels, ce qui en fait un choix populaire. RSA-2048 est toujours commun dans les anciens appareils mais nécessite un stockage de clé plus grand et des temps de vérification plus longs.

Pour le cryptage en vrac, AES-256 en mode GCM fournit à la fois confidentialité et intégrité. Beaucoup de familles FPGA plus récentes incluent les moteurs AES-GCM durs qui peuvent déchiffrer et authentifier les bitstreams multi-mégaoctets à la vitesse du fil. Les ingénieurs doivent s'assurer que les vecteurs d'initialisation (IV) ne sont jamais réutilisés; un générateur de nombres aléatoires basé sur le matériel ou un compteur monotonique enveloppé dans le gestionnaire de clé peut fournir des IV uniques par session de démarrage.

Une analyse de latence pratique de Le guide utilisateur de configurationXilinx="s montre que le décryptage AES-256 et l'authentification HMAC permettent d'ajouter environ 50 à 80 millisecondes au temps de configuration total pour un flux binaire de 25 Mo typique, bien dans les limites acceptables pour la plupart des applications intégrées.

Gestion des clés tout au long du cycle de vie

La gestion des clés est la partie la plus difficile de tout système de démarrage sécurisé. Une approche de cycle de vie-connaissante segmente l'utilisation des clés en phases distinctes:

  • Dispositions de fonctionnalités:[ Le hachage de la clé publique racine est programmé en eFuses. La clé privée est verrouillée dans un HSM hors ligne et ne quitte jamais l'installation. Pendant cette phase, l'identité unique de l'appareil (p. ex., l'ADN de l'appareil) peut être fusionnée pour permettre la liaison des clés à des unités individuelles.
  • Les touches de signature secondaires sont utilisées pour les mises à jour de routine du firmware. Ces touches sont elles-mêmes signées par la clé racine et peuvent avoir une durée de vie plus courte ou être stockées dans un HSM basé sur le cloud. La rotation de la clé secondaire peut être automatisée de sorte qu'un appareil ne fonctionne jamais avec une clé plus, disons, un an.
  • Fin de vie:[ Lorsqu'un produit est désaffecté, les certificats de révocation ou un bit de -kill , peuvent être configurés pour désactiver définitivement la capacité FPGA , ce qui rend l'appareil inutilisable pour un adversaire qui obtient un accès physique.

La rotation automatisée des clés peut être mise en œuvre en adressant un manifeste contenant la nouvelle clé publique, signée par l'ancienne. L'agent de mise à jour vérifie la chaîne, installe la nouvelle clé dans un registre protégé par écriture, puis avance le compteur anti-retour. L'ancienne clé peut être retirée dès que le compteur se propage à tous les appareils. Cette approche est documentée dans l'atelier IAB Internet of Things Software Update et s'aligne sur la norme de manifeste SUIT en cours de développement par l'IETF (IETF SUIT Manifeste.

Harmonisation des normes réglementaires et industrielles

Les ingénieurs des secteurs automobile, médical et industriel doivent aligner la sécurité de la FPGA sur les réglementations sectorielles. La norme ISO 21434 pour les véhicules routiers exige un mécanisme de mise à jour logicielle sécurisé et une racine matérielle de confiance pour toute logique programmable qui affecte la sécurité. IEC 62443 pour les systèmes de contrôle industriel exige que les appareils vérifient l'intégrité du firmware avant l'exécution et supportent les mises à jour authentifiées sur le terrain.

Pour les applications aérospatiales et de défense, des normes telles que DO-254 et FIPS 140-3 imposent des exigences supplémentaires sur le module cryptographique et le système de gestion des clés. L'utilisation d'une bibliothèque cryptographique validée par FIPS pour la vérification de la signature, même si elle est mise en œuvre dans le tissu FPGA, peut simplifier la certification.

Pratiques exemplaires opérationnelles pour la sécurité de la flotte de l'AGPF

La technologie ne peut à elle seule garantir la sécurité d'un parc automobile. Les équipes doivent envelopper leur mise en œuvre dans des pratiques opérationnelles robustes :

  • Sécurisez votre infrastructure de construction: Isolez le serveur de signature à partir du réseau local d'entreprise. Utilisez un HSM physique pour tenir des clés privées et enregistrer chaque opération de signature.
  • Sécuriser les contrôles d'accès fondés sur le rôle :[ Séparer les fonctions de développement, de test et de déploiement du flux binaire.Seul un gestionnaire de diffusion désigné devrait être en mesure de commencer la signature d'une image de production.
  • Moniteur et audit: Les bases de données de gestion d'actifs doivent suivre la version du firmware, la valeur du compteur anti-retour et le dernier temps de démarrage réussi pour chaque FPGA déployé. Les systèmes de détection d'anomalies devraient indiquer les dispositifs qui reviennent à plusieurs reprises à une image dorée ou afficher les compteurs de version qui se déplacent en arrière.
  • Plan pour la réponse à l'incident:[ Avoir une procédure pré-test pour distribuer une mise à jour du firmware d'urgence en réponse à une vulnérabilité de zéro jour. Cela comprend la tenue d'une liste de révocation pour les clés compromises et de s'assurer que le canal de mise à jour reste accessible même sur des appareils partiellement compromis.
  • Conduire des tests de pénétration réguliers:[ Les évaluations de sécurité externe devraient cibler spécifiquement la chaîne de configuration FPGA. Les vecteurs d'attaque courants comprennent le glissade de l'alimentation pendant le démarrage, l'extraction de flux de bits via JTAG, ou l'exploitation de la génération IV faible dans le moteur de décryptage.
  • Maintenir un inventaire cryptographique :[ Tenir un registre de tous les documents clés, y compris le digest de clé publique racine, l'autorité de certification de clé publique et les dates des rotations clés. Cet inventaire est essentiel lors de la révocation ou de la mise à jour des clés dans l'ensemble de la flotte.

Ces pratiques créent une posture de défense en profondeur qui s'étend du silicium au moteur du nuage.

L'avenir de la sécurité de l'AFPG : après Quantum et au-delà

Les systèmes de signature basés sur des réseaux tels que CRYSTALS-Dilithium offrent des tailles de clés plus petites que RSA pour une sécurité équivalente, mais la vitesse de vérification et la complexité de la mise en oeuvre restent des domaines de recherche actifs. Certains fournisseurs de FPGA ont commencé à démontrer des accélérateurs matériels pour ces algorithmes, anticipant que les équipements d'infrastructure à cycle de longue durée auront besoin d'un chemin de migration avant l'arrivée du calcul quantique à grande échelle. Le processus de normalisation post-quantum NIST, qui en est à ses dernières étapes, fournira des choix d'algorithmes clairs pour l'authentification bitstream d'ici 2024-2025. Les ingénieurs qui conçoivent des produits aujourd'hui devraient s'assurer que le bloc de sécurité dure de FPGA peut être mis à jour pour soutenir de nouveaux algorithmes, ou inclure un accélérateur de noyau souple pour la vérification post-quantum qui peut être chargé par reconfiguration partielle.

En outre, les progrès de la technologie PUF permettent une génération de clés spécifique qui ne stocke jamais les clés au repos, réduisant encore la surface d'attaque. Combinez un PUF avec une chaîne de démarrage sécurisée qui mesure la sortie PUF contre les données d'aide stockées – cela permet à chaque FPGA de dériver sa propre clé racine sans injection de clé pendant la fabrication. Cette approche, déjà disponible dans certains dispositifs Intel et Lattice, élimine le risque d'exposition de clé pendant la fourniture.

Alors que les primitives cryptographiques évoluent, les principes sous-jacents de la mise à jour sécurisée du firmware et des firmwares mesurés restent constants : ancrer la confiance dans le matériel immuable, mesurer chaque lien de la chaîne de démarrage, et ne jamais permettre l'exécution de code non signé.