Meilleures pratiques pour gérer les autorisations de registres dans les conceptions de matériel sécurisé

Introduction à l'enregistrement des autorisations dans la conception de matériel sécurisé

Dans les systèmes matériels modernes, les registres servent d'éléments de stockage fondamentaux qui contrôlent le comportement, la configuration et le flux des données des appareils. Des microcontrôleurs dans les capteurs IoT aux processeurs d'application dans les appareils mobiles, chaque registre représente une surface d'attaque potentielle. L'accès non autorisé en lecture ou en écriture à un registre critique peut conduire à une escalade de privilèges, à une fuite d'informations ou à un dysfonctionnement permanent des appareils.

La sécurité matérielle n'est pas un effort ponctuel; elle doit être intégrée à l'architecture dès les premières étapes. La gestion des autorisations d'enregistrement influence directement le système et le numéro 8217; la capacité de résister aux manipulations, aux attaques de canaux latéraux et aux exploits de micrologiciels.

Principes fondamentaux des types de permis de conduire

Chaque registre dans un équipement sécurisé devrait avoir une politique d'accès clairement définie. Les trois types de permission de base sont:

• Lire : Permet à un logiciel ou à un autre agent matériel de récupérer la valeur actuelle du registre.
• Écrire: Permet de modifier le contenu du registre et le contenu du registre, qui peut changer l'état ou la configuration du périphérique.
• Exécute: Utilisé pour les registres contenant des commandes ou des pointeurs pour exécuter le code; lire et écrire sont généralement aussi nécessaires.

Au-delà de ces éléments, les conceptions modernes intègrent souvent des qualificatifs supplémentaires tels que read-clear[, write-once[, self-clearing[ et keyed access[. Par exemple, un registre d'écriture-once empêche la reconfiguration accidentelle ou malveillante après le démarrage initial, tandis qu'un registre clé nécessite une séquence d'authentification correcte avant toute opération autorisée.

Les registres matériels sont souvent regroupés en banques ou blocs par fonction (par exemple, registres de contrôle DMA, registres d'interruption de statut, registres d'enclave de sécurité). Chaque groupe peut avoir un profil d'autorisation distinct en fonction de la sensibilité des opérations qu'il contrôle. Un système simple sur puce peut avoir plusieurs centaines de registres; un processeur serveur complexe peut avoir des dizaines de milliers. La logique d'autorisation centralisée ou distribuée doit être mise à l'échelle en conséquence.

Meilleure pratique 1 : Appliquer le principe du moindre privilège

Le principe du moindre privilège stipule que chaque entité — qu'il s'agisse de bloc matériel, de thread logiciel ou de maître de bus externe — ne devrait recevoir que les autorisations nécessaires pour remplir sa fonction légitime.

• Par défaut, ne pas avoir accès; n'accorder explicitement l'accès qu'au besoin.
• Séparer les registres de contrôle et de données de sorte que le firmware manipulant les flux de données ne modifie pas accidentellement la configuration sensible.
• Limiter l'accès par écrit aux registres qui affectent les limites de puissance, d'horloge, de tension ou de sécurité à un seul composant firmware bien isolé (p. ex., un moniteur de sécurité).

Une erreur courante est de donner tout accès au firmware à chaque registre dans un périphérique. Au lieu de cela, implémentez une matrice de permission du logiciel[ qui massique chaque niveau de maître ou de privilège de bus à l'ensemble des registres qu'il peut lire et écrire. Dans les systèmes basés sur ARM, cela est souvent réalisé par un système de protection de mémoire TrustZone-aware (MPU) ou un contrôleur d'accès de niveau système. Par exemple, l'architecture ARM TrustZone[ utilise le bits NS (Non-Secure) pour séparer les espaces de registre sécurisés et non sécurisés, en faisant respecter le moins de privilèges au niveau de transaction.

Lors de la conception d'IP personnalisé, envisager d'ajouter un registre de contrôle d'accès dédié par bloc qui définit quels identifiants maîtres ou niveaux de privilèges sont autorisés. Cet ACR lui-même devrait être écrit une fois après le démarrage pour empêcher la récursation des autorisations d'exécution.

Pratique exemplaire 2 : Utiliser des contrôles d'accès renforcés par le matériel

Les contrôles de permission uniquement logiciels sont vulnérables aux contournements par des exploits, des dépassements de tampon ou des attaques d'accès direct à la mémoire (DMA). Les contrôles renforcés par le matériel fournissent une couche déterministe qui ne peut pas être surchargée par un code malveillant.

Portails de niveau de privilège

De nombreuses architectures de processeur supportent deux niveaux de privilèges ou plus (par exemple, utilisateur/superviseur, EL0/EL1/EL2/EL3 dans ARM). Un registre peut être étiqueté comme accessible uniquement à partir de certains niveaux de privilèges. Par exemple, un registre contrôlant une clé de démarrage sécurisée doit être enregistrable uniquement à partir du niveau de privilège le plus élevé (EL3) et seulement pendant une phase de démarrage spécifique.

Accès à clé de la fonction physique non-clonable (PUF)

Pour les registres ultrasensibles (p. ex., les tableaux de fusibles, les magasins de clés cryptographiques), les niveaux de privilèges traditionnels peuvent ne pas suffire. Certains modèles relient l'accès à une clé matérielle dérivée d'un PUF. Sans clé valide, lisez retourner tous les zéros et les écrits sont silencieusement rejetés.

Unités de protection de la mémoire (UMP) et unités de gestion de la mémoire du système (UMSM)

Ces unités définissent les permissions d'accès par région sur toute la carte d'adresse. Un MPU bien configuré peut empêcher un contrôleur DMA de lire des registres en dehors de sa plage autorisée. L'exemple ARM SMMU montre comment ces unités peuvent appliquer des autorisations à grain fin dans des systèmes hétérogènes avec plusieurs maîtres.

Permission de matériel tampons lookaside

Dans les conceptions haute performance, la vérification des autorisations par transaction peut ajouter de la latence. Un tampon de permission lookaside cache les droits d'accès pour les adresses de registre récentes, permettant de vérifier pour compléter dans un cycle d'horloge unique. Cette technique est similaire à un TLB mais dédiée au contrôle d'accès.

Pratique exemplaire 3 : Mettre en oeuvre le contrôle d'accès axé sur les rôles (CAR) pour les registres

L'accès basé sur le rôle organise la permission par fonction plutôt que par identifiant maître individuel. Ceci simplifie la gestion, surtout lorsque le nombre d'agents est important. Les rôles communs dans un système matériel sécurisé comprennent:

• Boot ROM: Accès complet aux registres d'initialisation et de stockage sécurisé pendant le démarrage; généralement verrouillé après le démarrage.
• Firmware fiable: Ecrire l'accès aux registres de configuration qui affectent les politiques de sécurité; lire l'accès aux registres de statut.
• Firmware non fiable : Accès en lecture seule aux registres d'état non critique; aucun accès à la configuration de sécurité.
• Contrôleur de débogage: Accès à la lecture/écriture conditionnelle seulement lorsqu'un système d'authentification de débogage sécurisé le permet.
• DMA Engines: Accès lecture/écriture uniquement aux registres tampons de données, non pas aux registres de contrôle ou de statut.

Les concepteurs de matériel peuvent mettre en œuvre le RBAC en utilisant une table role stockée dans une mémoire programmable une fois (OTP) ou une RAM sécurisée qui est initialisée pendant le démarrage. Chaque transaction de bus porte le demandeur et #8217;s ID de rôle, et le contrôleur d'accès le compare aux acls pour le registre cible. Cette approche s'harmonise avec le modèle NIST RBAC et permet de vérifier qui a accédé au registre et pourquoi.

Exemple : Gestionnaire de clés sécurisé Enregistrer la carte

Considérez un gestionnaire de clés sécurisé avec trois registres : KEY CTRL, KEY VALID et KEY CLEAR.

• Le ROM de démarrage peut écrire KEY CTRL et KEY VALID pendant la fourniture des clés.
• Le firmware fiable peut lire KEY VALID mais ne peut pas écrire KEY CTRL.
• Le firmware non fiable est bloqué dans les trois registres.

Cette granularité empêche un firmware de confiance compromis de ré-provisionner les clés, tout en permettant les requêtes d'état.

Mesures de sécurité supplémentaires au-delà des autorisations

La gestion rigoureuse des autorisations de registre doit être complétée par des mécanismes de sécurité au niveau du système.

Intégrité de la chaîne de démarrage sécurisée

Les registres qui contrôlent l'ordre de démarrage, les drapeaux de démarrage sécurisés ou les fusibles doivent avoir leurs permissions verrouillées avant l'avancement du processus de démarrage. Utilisez des machines d'état matériel qui passent d'un état configurable à un état d'exécution “locked”. Une fois verrouillé, même le firmware privilégié ne peut pas changer ces registres à moins qu'une réinitialisation complète ne se produise. Cela empêche les attaques persistantes qui modifient la configuration du démarrage.

Environnements d'exécution fiables (TEE)

Les EE comme ARM TrustZone, Intel SGX ou RISC-V MultiZone partition ressources matérielles dans des mondes sûrs et normaux. Les registres dans le monde sécurisé sont invisibles et inaccessibles aux logiciels mondiaux normaux. Tous les registres du monde sécurisé doivent être configurés avec le contrôle d'accès au niveau mondial comme première porte.

Accès au sentier d'exploitation forestière et de vérification

Pour les systèmes d'assurance élevée (p. ex. avionique militaire, automobile ASIL-D), chaque accès à un registre critique doit être enregistré. Un moteur de l'enregistrement du matériel dédié peut enregistrer l'ID principal, l'opération (lecture/écriture), l'adresse et l'horodatage dans un tampon sécurisé et non volatil. Cette piste d'audit permet de détecter les modèles d'accès anormaux après un incident de sécurité. Le journal lui-même doit être append-on seulement et lisible par un agent d'audit autorisé.

Détection et réponse de tambours

Certains systèmes intègrent des capteurs de détection de voltage, d'extrêmes de température ou de détection laser. Lorsqu'un événement de manipulation est détecté, le matériel peut automatiquement révoquer les autorisations sur les registres sensibles, effacer les clés ou déclencher une réinitialisation sécurisée. Cela nécessite une logique de l'autorisation de l'enregistrement pour avoir une entrée de l'unité de détection de manipulation, dépassant les politiques d'accès normales.

Sécuriser le débogage et l'accès aux tests

Les interfaces de débogage (JTAG, SWD) contournent souvent les vérifications d'autorisation des registres. Un appareil de production doit désactiver ou authentifier fortement l'accès aux débogages. Utilisez un système d'authentification défi-réponse avec un secret unique de périphérique. De plus, les registres de débogage eux-mêmes devraient être soumis aux mêmes contrôles d'autorisation que les autres registres; par exemple, seul un rôle de débogage spécifique avec un certificat valide peut définir des points d'arrêt sur un code sécurisé.

Considérations relatives au cycle de vie pour les autorisations de registre

Les permissions de sécurité matérielle ne sont pas statiques. Le système passe par des phases distinctes du cycle de vie : fabrication, démarrage, écoulement, éventuellement réparation de champ ou déclassement. Chaque phase nécessite un profil d'autorisation différent.

Phase de fabrication

Pendant la fabrication et le test de puces, de nombreux registres ont besoin d'un accès illimité pour la validation. Cependant, les registres de tests devraient être isolés des registres fonctionnels en utilisant des modes de test dédiés qui sont désactivés après la fabrication. Utilisez e-fuses pour désactiver définitivement l'accès au test avant l'expédition de la puce.

Phase de démarrage

Le code de démarrage initial (ROM) est supposé immuable. Il a un accès complet temporaire à tous les registres nécessaires à l'initialisation. Une fois que le ROM de démarrage se retire au firmware de niveau suivant, il verrouille ses propres registres et met le contrôleur d'accès à une politique d'exécution. Un modèle commun est d'utiliser un registre de verrouillage de démarrage qui, une fois écrit avec une clé spécifique, désactive les modifications supplémentaires à la matrice d'autorisation.

Phase d'exécution

Les permissions d'exécution doivent être aussi restrictives que possible. Idéalement, aucune entité ne peut modifier les politiques d'autorisation après le démarrage (la table des permissions est immuable). Si la reconfiguration d'exécution est nécessaire, elle doit être authentifiée et enregistrée. Par exemple, une mise à jour du firmware de champ peut nécessiter l'extension temporaire des permissions; cela devrait déclencher une réinitialisation sécurisée avant que les nouvelles permissions ne prennent effet.

Fin de vie (Déclassement)

Lorsqu'un appareil est retiré, les permissions doivent être révoquées pour empêcher l'extraction de données résiduelles. Les registres qui détiennent des secrets doivent être effacés par une commande de péremption matérielle. La logique de permission doit fournir un signal “secure efface” qui force tous les registres sensibles à leurs états de réinitialisation sûrs.

Vérification et vérification des autorisations de registres

La conception d'un système de permission n'est que la moitié du travail; il est également essentiel de vérifier qu'il se comporte correctement dans tous les scénarios.

Essais dirigés et aléatoires

Créez des cas de test qui tentent d'accéder à chaque registre à partir de chaque maître/rôle avec chaque opération possible. Utilisez des vérificateurs de simulation qui affirment une défaillance lorsqu'un accès non autorisé réussit.

Vérification formelle

Pour les conceptions critiques en matière de sécurité, la vérification formelle (vérification du modèle) peut mathématiquement prouver qu'aucune séquence de transactions de bus ne peut violer la politique de permission. Des outils comme Cadence JasperGold ou Synopsys VC Formal peuvent vérifier des propriétés telles que “Enregistrer X n'est jamais écrit par maître Y après le verrouillage de démarrage est défini.” Les méthodes formelles sont particulièrement utiles pour détecter les effets secondaires, comme les écritures à un registre modifiant par inadvertance une autre en raison de la logique de décodage partagée.

Injection par défaut et essais par équipe rouge

Si une erreur change l'ACR, le système retombe-t-il gracieusement dans un état sûr (par exemple, tous les accès bloqués) ou permet-il une escalade? Les tests de pénétration par équipe rouge sur les prototypes FPGA peuvent révéler des vulnérabilités qui manquent à la simulation, comme les problèmes de synchronisation qui contournent les comparateurs.

Pièges courants et comment les éviter

Même les concepteurs expérimentés peuvent faire des erreurs lors de la gestion des autorisations de registre.

• En lecture seule enregistre les secrets qui fuient sur écrit:[ Certains registres retourneront des données antérieures lorsqu'elles sont écrites avec une valeur non valide. Assurez-vous toujours que les registres en lecture seule ou en écriture seulement renvoient des valeurs fixes (par exemple zéro) plutôt que l'état interne.
• L'accès à tous les registres est très large et n°8220;superviseur et n°8221; accès :[ L'accès au niveau du superviseur à tous les registres compromet le moindre privilège.
• Ignorer les canaux latéraux du timing:[ Si les vérifications des autorisations prennent un temps variable selon que l'accès est autorisé, un attaquant peut utiliser le timing pour sonder les autorisations de registre.
• Fermer les registres de débogage : Les ports d'accès de débogage fonctionnent souvent en dehors du cadre de permission normal. Assurez-vous que toute interface de débogage qui peut contourner les permissions est désactivée dans le matériel de production.

Normes et références industrielles

L'adoption de normes sectorielles permet d'harmoniser les conceptions des permis de registre avec les pratiques exemplaires dans l'ensemble du secteur.

• Spécification du groupe informatique fiable (TCG) pour les racines matérielles de confiance et de stockage sécurisé.
• IEEE P1735 pour les pratiques recommandées en matière de protection de la PI, y compris les mécanismes de contrôle d'accès.
• NIST Cybersecurity Framework pour intégrer le contrôle d'accès matériel à la fonction Protect.
• La spécification RISC-V Physical Memory Protection (PMP) est un exemple d'application de la permission fondée sur le registre.

Conclusion

En appliquant le principe du moins de privilèges, en tirant parti des contrôles d'accès renforcés par le matériel et en mettant en œuvre des modèles basés sur les rôles, les concepteurs peuvent construire des systèmes qui résistent à l'abus accidentel et à l'attaque délibérée. Associés à des autorisations sécurisées de démarrage, de l'audit et du cycle de vie, ces pratiques forment une stratégie de défense complète en profondeur pour la sécurité matérielle.

Les techniques d'attaque évoluent, de même que notre approche pour enregistrer le contrôle d'accès. Les développements futurs tels que les modèles de permission abstraite guidés par des spécifications formelles, la détection d'anomalies assistées par machine sur les modèles d'accès, et la séparation de privilèges plus granulaires vont durcir nos conceptions.