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

DDS Security the Hard(ware) Way - SGX :Partie 1 (Présentation)

Partie 1 d'un Multi-Part Série

La protection des environnements IoT industriels critiques nécessite une sécurité qui s'étend de la périphérie au cloud, à travers les systèmes et les fournisseurs. En tant qu'auteur principal de la norme de sécurité OMG DDS, RTI a joué un rôle de premier plan dans la définition des exigences - et des environnements - nécessaires pour sécuriser les environnements distribués. Les plugins de sécurité DDS fournissent des mécanismes de sécurité robustes et centrés sur les données pour les données sur le fil. RTI Connext DDS Secure est le cadre de connectivité éprouvé et fiable qui protège les systèmes grâce à une sécurité flexible et précise pour des performances et une efficacité optimales, de l'appareil au cloud.

Nous reconnaissons cependant que la sécurité est une question complexe. Alors que RTI a créé une sécurité de haut niveau dans le cadre logiciel Connext DDS, notre équipe de recherche examine d'autres domaines pour renforcer la sécurité de l'IIoT. Dans cet esprit, nous sommes heureux de partager avec vous certains des travaux de RTI Research, alors qu'ils explorent des approches nouvelles et innovantes de la sécurité.

Dans cette série de blogs, notre expert en sécurité Jason Upchurch regarde au-delà des mécanismes logiciels et matériels qui assurent la sécurité sur un système non fiable où une application critique traite ses données. Dans l'esprit de repousser les limites de la sécurité, il explore Intel SGX® dans le contexte de RTI Connext® DDS Micro et des plugins de sécurité.

Alors, commençons.

Qu'est-ce que SGX et pourquoi est-ce important ?

SGX, ou Software Guard Extensions, est une extension d'Intel ISA (Instruction Set Architecture) qui fournit un TEE (Trusted Execution Environment) pour exécuter des applications contenant des données sensibles. S'il est vrai qu'Intel ISA ne domine pas l'IoT industriel (IIoT), il détient des parts de marché dans la salle des serveurs, et la salle des serveurs est souvent intégrée à diverses architectures IIoT. Plus précisément, ces applications de traitement de données de salle de serveurs sont plus susceptibles d'être des cibles de grande valeur pour les utilisateurs malveillants, car elles peuvent avoir plus d'accès aux données protégées que les points de terminaison IIoT traditionnels. Ainsi, SGX pourrait très bien aider à sécuriser l'IIoT, ou au moins une partie de celui-ci. Voyons pourquoi SGX est important pour les utilisateurs de DDS et d'autres développeurs d'applications qui nécessitent des environnements de haute sécurité.

Figure 1 :Connext DDS Secure Inside SGX Space

La sécurité sans fil peut ne pas suffire

Pour commencer, regardons l'exemple académique classique d'Alice et Bob de partage d'un secret. L'histoire commence avec la rencontre d'Alice et Bob en personne, progresse avec une Eve sournoise interceptant des messages sur le fil et se termine par une méthode éprouvée pour partager des secrets. C'est la base d'une communication sécurisée, même si Eve intercepte tous les messages. Après avoir mené plusieurs des plus grandes enquêtes sur les intrusions au monde, je peux dire en toute sécurité que je n'ai jamais vu "Eve" intercepter des messages cryptés sur le fil et recueillir des secrets. Je peux aussi dire avec certitude que « Eve » obtient presque toujours les secrets qu'elle recherche. Ces déclarations apparemment contradictoires peuvent toutes deux être vraies car le cryptage du réseau est robuste et, par conséquent, rarement la cible d'attaques.

Pour examiner le problème, examinons le scénario, où Eve est assise entre Alice et Bob et peut entendre et même manipuler des messages à volonté. Le scénario suppose qu'Alice et Bob se font confiance pour les secrets qu'ils partagent ; cependant, cette hypothèse s'avère gravement erronée dans la pratique. Le diagramme du manuel de la figure 2 illustre en fait le problème, car Alice communique apparemment avec Bob à distance sans aucune technologie.

Figure 2 : Communication du manuel Alice et Bob

La réalité de la situation est qu'une certaine forme d'appareil est utilisée pour permettre à Alice et Bob de communiquer, et c'est là que notre hypothèse prend le dessus sur nous. En sécurité informatique, il existe un concept connu sous le nom de Trusted Computing Base (TCB). Dans ses termes les plus simples, TCB est l'ensemble des composants (à la fois individuellement et en tant que système), y compris les logiciels, auxquels vous devez faire confiance pour sécuriser une sorte de traitement. Dans notre scénario classique Alice et Bob, nous tentons de sécuriser le partage de secrets à distance. Il est vrai qu'Alice fait l'hypothèse de faire confiance à Bob pour partager des secrets avec lui, mais elle fait également confiance à son environnement informatique (et au sien). Dans un scénario réel, il s'agit d'un ensemble de centaines de composants de divers fabricants qui (a) exécute probablement un système d'exploitation avec des millions de lignes de code ; (b) regorge d'applications codées par des personnes que vous ne connaissez pas ; et (c) probablement connecté à un réseau accessible au public qui permet aux attaquants et aux logiciels malveillants à propagation automatique d'accéder gratuitement au système à volonté. Ces systèmes sont loin d'être dignes de confiance, c'est le moins qu'on puisse dire.

...la situation est analogue à la construction d'une porte en acier avec des serrures élaborées sur une maison avec des murs en papier.

C'est la source d'humour cynique pour de nombreux membres de la communauté de la sécurité informatique lorsqu'un nouveau et meilleur schéma de cryptage est recommandé pour crypter la communication sur le fil. Après tout, les secrets peuvent être simplement extraits avec peu d'effort de la source ou de la destination, en toute clarté, sans se soucier du tout du cryptage. J'ai toujours pensé que la situation était analogue à la construction d'une porte en acier avec des serrures élaborées sur une maison aux murs de papier.

Alors que faire ? L'approche actuelle dans l'industrie est largement centrée sur la recherche des composants minimum viables (matériel et logiciel) nécessaires pour accomplir une tâche critique, certifier et/ou mesurer chaque composant et les isoler des autres composants du système. À un niveau très basique, cette approche réduit le TCB et vérifie qu'aucun composant à l'intérieur du TCB n'a été ajouté ou modifié.

Sécurité au point de terminaison (et à chaque point intermédiaire)

Il est utile de noter que, bien que non trivial, nous avons atteint le point en informatique qu'il est possible de construire un environnement informatique sécurisé. Le problème est que la demande actuelle du marché porte sur un environnement informatique riche, ce qui est en contradiction avec un environnement sécurisé. Même dans l'IIoT, la demande pour des environnements informatiques riches n'est pas toujours due aux vastes fonctionnalités qu'ils offrent, mais parce qu'ils sont populaires et bien pris en charge, donc beaucoup moins chers à développer et à entretenir. Ainsi, le gros problème du TCB se retrouve dans des appareils qui pourraient être sécurisés avec une autre approche. En réponse à ce problème, l'industrie s'est mise à concevoir des systèmes qui fournissent à la fois un système d'exploitation riche et un environnement d'exécution sécurisé (TEE) séparé (en quelque sorte) dans un seul appareil.

La plupart des conceptions TEE ont essentiellement deux systèmes d'exploitation fonctionnant en parallèle sur un seul appareil. Le système d'exploitation riche gère les tâches courantes et le système d'exploitation sécurisé gère les tâches sensibles. La conception TEE permet de basculer entre les deux. Le commutateur est souvent pris en charge et appliqué par le matériel. Des mécanismes de confiance courants, tels que le chargement de la racine de la chaîne de confiance, sont utilisés du côté sécurisé pour garantir qu'aucun code non autorisé n'a été introduit.

SGX est assez différent. Même un TCB côté sécurisé peut être assez volumineux. La racine de confiance garantit uniquement qu'un programme n'est pas altéré lors du chargement. En tant que tel, sa sécurité dépend des techniques de validation logicielle pour chaque programme chargé (y compris le système d'exploitation minimal) autant que de son processus de démarrage fiable. Intel a entrepris de minimiser radicalement le TCB. La surface d'attaque dans un processeur compatible SGX est le CPU et l'application. Il n'y a aucun système d'exploitation, micrologiciel, hyperviseur, autre matériel ou BIOS auquel faire confiance dans un environnement SGX. Le seul logiciel auquel il faut faire confiance est l'application elle-même. SGX fournit une méthode pour assurer le chargement sécurisé de cette application de la même manière qu'un démarrage sécurisé normal, sauf que la chaîne de confiance ne fait que 3 liens (Attestation racine, CPU, application) au lieu des chaînes plutôt longues dans un système sécurisé traditionnel. système de démarrage.

[1] [2] 下一页

Technologie de l'Internet des objets

  1. La route vers la sécurité industrielle de l'IoT
  2. S'attaquer aux vulnérabilités de sécurité de l'IoT industriel
  3. Sécuriser l'IoT contre les cyberattaques
  4. Sécurisation du vecteur de menace IoT
  5. Le défi de sécurité posé par l'Internet des objets :2e partie
  6. Le défi de sécurité posé par l'Internet des objets :1ère partie
  7. Sécuriser l'IoT industriel :adopter une approche de nouvelle génération – Partie 2
  8. La sécurité renforce le véritable potentiel de l'IoT
  9. UID Overview Series - Partie III - L'avenir de l'UID