Fabrication industrielle
Internet des objets industriel | Matériaux industriels | Entretien et réparation d'équipement | Programmation industrielle |
home  MfgRobots >> Fabrication industrielle >  >> Industrial Internet of Things >> Technologie de l'Internet des objets

Redéfinition de la sécurité du micrologiciel

Un article récent a souligné la menace d'attaques basées sur des micrologiciels sur les plates-formes de serveurs et a expliqué en détail comment un fournisseur de services comme Cloudflare peut défendre sa plate-forme. Il a discuté de la mise en œuvre d'une racine matérielle de confiance pour la signature de code des entités de démarrage critiques, permettant au matériel de devenir une première ligne de défense pour garantir que l'intégrité du matériel et des logiciels du serveur peut tirer la confiance par des moyens cryptographiques - et plus important encore, défendre les clients contre de telles attaques . L'article s'est terminé par un regard tourné vers l'avenir, indiquant que même si la solution fonctionne pour le présent, il y a toujours place à l'amélioration dans le cadre d'un effort continu pour fournir la meilleure sécurité du secteur.

Cet article poursuit cette discussion en passant en revue les vecteurs potentiellement non traités inhérents aux plates-formes actuelles et présente une solution optimale pour prévenir les attaques de micrologiciels et élever la sécurité de la plate-forme au niveau supérieur, basée sur le processeur de sécurité de l'unité de contrôle/calcul (TCU) d'Axiado.

Enracinement de la confiance dans le micrologiciel

Le problème clé est l'hypothèse implicite de la sécurité de la racine de confiance (RoT) dans la chaîne de démarrage. Situé au niveau du micrologiciel UEFI (Unified Extensible Firmware Interface), l'hypothèse est que le RoT n'est pas une cible potentielle pour une attaque. Cette hypothèse s'est avérée dangereuse, comme en témoigne la croissance des attaques basées sur les micrologiciels au fil des ans, et en particulier, plus de dix fois en 2019 par rapport à 2010. Les pirates ont rapidement réalisé qu'en corrompant ce micrologiciel, le module de plate-forme de confiance (TPM) les mesures à des fins d'attestation à distance pourraient également être corrompues, car les mesures reposent sur l'interaction avec le micrologiciel pour valider ces mesures (elle ne s'appelle pas « racine de confiance » pour rien). Pour garantir l'intégrité de la plate-forme, il est impératif que le micrologiciel UEFI lui-même soit authentifié, c'est-à-dire qu'une politique de confiance zéro soit adoptée au niveau du RoT.

Solution initiale

Pour résoudre ce problème, les entreprises ont pris la mesure importante d'authentifier le micrologiciel UEFI de leurs serveurs avec Cloudflare à l'aide du processeur AMD EPYC qui prend en charge cette authentification. Le sous-système de sécurité matériel d'EPYC nommé AMD Secure Processor exécute une fonction nommée Platform Secure Boot (PSB) qui authentifie le premier bloc d'UEFI avant de libérer le CPU principal de la réinitialisation. PSB est la mise en œuvre par AMD de l'intégrité de démarrage matérielle. C'est mieux que la racine de confiance basée sur le micrologiciel UEFI car elle est destinée à affirmer, par une racine de confiance ancrée dans le matériel, l'intégrité et l'authenticité de l'image ROM système avant qu'elle ne puisse s'exécuter. Il le fait en effectuant les actions suivantes :

Ceci est accompli par le processeur de sécurité de la plate-forme AMD (PSP), un microcontrôleur ARM Cortex-A5 qui est une partie immuable du système sur puce (SoC).

Avec cette approche, Cloudflare a mis en place une solution qui semble répondre à ses besoins d'authentification du micrologiciel UEFI.

Problèmes avec le démarrage sécurisé UEFI

Contrôleurs non authentifiés

Un composant commun qui se trouve sur presque tous les serveurs est un contrôleur de gestion de la carte mère (BMC). Les BMC ont plusieurs connexions au système hôte, offrant la possibilité de surveiller le matériel, de flasher le micrologiciel BIOS/UEFI, de donner un accès à la console via un KVM série ou physique/virtuel, de redémarrer les serveurs et de consigner les événements.

Dans le cadre de la chaîne de démarrage, la méthode de signature PSB actuelle ne traite pas de la signature du BMC, ce qui limite l'extension de la limite de confiance à un contrôleur doté de nombreuses interfaces avec les composants du système.

Démarrage avec un processeur spécifique à la plate-forme

L'intégration de l'authentification du micrologiciel UEFI dans un bloc intégré au processeur principal d'un serveur introduit des problèmes de logistique dans le domaine de la gestion des unités de stockage (SKU). L'un de ces problèmes implique le verrouillage d'un processeur sur une plate-forme particulière. Avec l'authentification UEFI et les clés cryptographiques associées liées à la fois au code dans le flash de démarrage intégré ainsi qu'au processeur AMD EPYC, tous doivent être présents sur la plate-forme pour que le serveur démarre correctement. Cependant, cela limite la possibilité de mettre à niveau ou de modifier un processeur sur cette carte mère. Cet effet secondaire a été observé sur le marché des revendeurs à valeur ajoutée, car les appareils EPYC utilisant la fonction PSB ne peuvent pas être échangés. Certaines entreprises (telles que HPE) ont reconnu cette limitation et ont désactivé la fonction PSB sur leurs serveurs basés sur EPYC, choisissant plutôt d'authentifier leur micrologiciel UEFI en externe avec leur solution de silicium interne.

Axiado pense qu'un coprocesseur externe gérant l'authentification du micrologiciel UEFI tout en permettant la flexibilité du processeur est idéal pour l'industrie dans son ensemble.

Défis avec plusieurs plates-formes

Un autre problème lié à la gestion des SKU concerne la gestion des plates-formes avec potentiellement plusieurs méthodologies de démarrage sécurisé. Un déploiement de serveurs de centre de données peut inclure un mélange de processeurs, tels qu'Intel, AMD et Arm, chacun avec sa direction de mise en œuvre de l'authentification du micrologiciel UEFI. Ce scénario peut entraîner une charge excessive avec la gestion des différentes méthodologies de démarrage sécurisé/racine de confiance développées en interne de chaque fournisseur de processeur.

Par conséquent, un coprocesseur externe pour gérer l'authentification du micrologiciel UEFI avec la flexibilité du processeur est idéal pour l'industrie dans son ensemble.

Un guichet unique potentiel pour une sécurité optimale du micrologiciel ?

Une solution qui permet un guichet unique pour les besoins de sécurité, tout en améliorant simultanément la sécurité du micrologiciel et sans ajouter de composants à la nomenclature est le coprocesseur d'unité de contrôle/calcul (TCU) d'Axiado. Cela offre la meilleure authentification du micrologiciel UEFI pour une solution de démarrage sécurisé uniforme sur toutes les références, quel que soit le choix de l'entreprise en matière de fournisseur de processeur principal, et le tout sans ajouter de composants à la plate-forme.

En tant que coprocesseur dans un serveur, Axiado TCU joue le rôle de la puce du contrôleur de gestion de la carte mère (BMC), donc aucun espace supplémentaire sur le serveur n'est requis pour cet appareil. Le TCU est responsable de l'attestation de tous les composants du système, y compris lui-même. Il offre une solution de consolidation de composants attrayante en prenant en charge toutes les fonctionnalités héritées attendues d'un appareil BMC et en incluant des fonctionnalités supplémentaires qui permettent à TCU de jouer le rôle de module de plate-forme de confiance (TPM) et de dispositif logique programmable complexe (CPLD) trouvés sur les serveurs.

Au cœur de TCU se trouve la technologie de coffre-fort sécurisée brevetée d'Axiado, qui fournit une authentification du micrologiciel UEFI inviolable et immuable basée sur le matériel et un démarrage sécurisé. Entre autres choses, cette technologie comprend des protections contre les attaques par analyse de puissance différentielle qui sont utilisées pour faire de l'ingénierie inverse des clés cryptographiques qui permettent aux pirates d'accéder à des informations privées cryptées.

Le TCU comprend une technologie d'IA sécurisée dotée d'un sous-système dédié de processeur de réseau neuronal (NNP) conçu pour modéliser le comportement normal de l'appareil, et ainsi, pour identifier les anomalies qui pourraient indiquer la présence d'une attaque. Cela permet de mettre en œuvre toutes les contre-mesures nécessaires pour protéger le système avant les attaques, y compris celles qui ne sont pas formellement identifiées. De plus, le NNP est connecté à diverses E/S de l'appareil, ce qui lui permet de modéliser le comportement normal et d'identifier les anomalies de la plate-forme du serveur dans son ensemble, élargissant ainsi le rayon de protection du TCU contre les tentatives de piratage.

En proposant une solution de coprocesseur de sécurité, Axiado résout les problèmes présentés dans cet article en ce qui concerne les offres SKU. Premièrement, une solution unique minimise le nombre de surfaces d'attaque que les pirates peuvent essayer d'exploiter sur l'ensemble d'une gamme de références. Il n'est pas nécessaire de se protéger contre les attaques contre les solutions de sécurité AMD, Intel, Arm et d'autres fournisseurs. Cela simplifie également la gestion et la maintenance des déploiements de SKU de serveur, en minimisant le nombre de variantes de mise à jour du logiciel/micrologiciel de la plate-forme. Deuxièmement, en déchargeant le sous-système de démarrage sécurisé sur la TCU, le CPU n'est plus verrouillé sur le matériel serveur spécifique. On peut alors être libre de mélanger et assortir les processeurs entre les variantes matérielles et d'effectuer des mises à niveau sans avoir à passer par la tâche de configurer le processeur sur le matériel spécifique sur lequel il est installé.

En résumé, le coprocesseur TCU fournit une solution de protection du micrologiciel UEFI basée sur le matériel uniforme et sécurisée pour toutes ses plates-formes, avec la possibilité d'apprendre de nouvelles attaques avant même qu'elles ne soient officiellement reconnues. Cela permet d'avoir un réseau sécurisé alimenté par des sous-systèmes CPU hautes performances et riches en fonctionnalités, ainsi qu'un réseau plus facile à gérer et à entretenir.


Technologie de l'Internet des objets

  1. La route vers la sécurité industrielle de l'IoT
  2. Redéfinition de la sécurité du micrologiciel
  3. Gestion de la sécurité IIoT
  4. Sécurité de l'IoT :à qui incombe la responsabilité ?
  5. Tout devient IoT
  6. Sécurité IoT – Un obstacle au déploiement ?
  7. Rénovation de la cybersécurité
  8. Sécuriser l'IoT par la tromperie
  9. Une liste de contrôle de sécurité ICS