Industrielle Fertigung
Industrielles Internet der Dinge | Industrielle Materialien | Gerätewartung und Reparatur | Industrielle Programmierung |
home  MfgRobots >> Industrielle Fertigung >  >> Industrial Internet of Things >> Internet der Dinge-Technologie

DDS-Sicherheit auf die Hardware-Weise - SGX:Teil 1 (Übersicht)

Teil 1 eines Multi-Part Serie

Der Schutz geschäftskritischer industrieller IoT-Umgebungen erfordert Sicherheit, die vom Edge bis zur Cloud skaliert, über Systeme und Lieferanten hinweg. Als Hauptautor des OMG DDS-Sicherheitsstandards hat RTI eine führende Rolle bei der Definition der Anforderungen – und Umgebungen – gespielt, die für die Absicherung verteilter Umgebungen erforderlich sind. DDS Security-Plugins bieten robuste, datenzentrierte Sicherheitsmechanismen für Daten auf dem Draht. RTI Connext DDS Secure ist das bewährte, vertrauenswürdige Konnektivitäts-Framework, das Systeme durch flexible, fein abgestufte Sicherheit für optimale Leistung und Effizienz schützt, vom Gerät bis zur Cloud.

Wir wissen jedoch, dass Sicherheit ein komplexes Thema ist. Während RTI im Connext DDS-Software-Framework hochwertige Sicherheit geschaffen hat, untersucht unser Forschungsteam andere Bereiche, um robustere Sicherheit in das IIoT zu bringen. Vor diesem Hintergrund teilen wir gerne einige der Arbeiten von FTI Research mit Ihnen, die neue und innovative Ansätze für Sicherheit erforschen.

In dieser Blog-Serie schaut unser Sicherheitsexperte Jason Upchurch über die Software hinaus auf Hardware-Mechanismen, die Sicherheit auf einem nicht vertrauenswürdigen System bieten, auf dem eine kritische Anwendung ihre Daten verarbeitet. Im Geiste, den Sicherheitsbereich zu erweitern, untersucht er Intel SGX® im Kontext von RTI Connext® DDS Micro und Security Plugins.

Also lasst uns anfangen.

Was ist SGX und warum ist es wichtig?

SGX oder Software Guard Extensions ist eine Erweiterung der Intel ISA (Instruction Set Architecture), die eine TEE (Trusted Execution Environment) zum Ausführen von Anwendungen bereitstellt, die sensible Daten enthalten. Zwar dominiert Intel ISA das Industrial IoT (IIoT) nicht, hat aber Marktanteile im Serverraum, und der Serverraum wird oft in verschiedene IIoT-Architekturen integriert. Genauer gesagt sind diese Serverraum-Datenverarbeitungsanwendungen eher hochwertige Ziele böswilliger Benutzer, da sie möglicherweise mehr Zugriff auf geschützte Daten haben als herkömmliche IIoT-Endpunkte. Somit könnte SGX sehr gut dazu beitragen, das IIoT oder zumindest einen Teil davon abzusichern. Lassen Sie uns herausfinden, warum SGX für DDS-Benutzer und andere Anwendungsentwickler wichtig ist, die Hochsicherheitsumgebungen benötigen.

Abbildung 1:Connext DDS Secure Inside SGX Space

Over-the-Wire-Sicherheit reicht möglicherweise nicht aus

Schauen wir uns zunächst das klassische akademische Beispiel von Alice und Bob für das Teilen eines Geheimnisses an. Die Geschichte beginnt damit, dass Alice und Bob sich persönlich treffen, schreitet fort mit einer hinterhältigen Eve, die Nachrichten auf dem Kabel abfängt, und endet mit einer bewährten Methode, um Geheimnisse zu teilen. Dies ist die Basis für eine sichere Kommunikation, auch wenn Eve alle Nachrichten abfängt. Nachdem ich mehrere der weltweit größten Einbruchsuntersuchungen durchgeführt habe, kann ich mit Sicherheit sagen, dass ich noch nie gesehen habe, wie „Eve“ verschlüsselte Nachrichten auf dem Draht abgefangen und Geheimnisse sammelt. Ich kann auch mit Sicherheit sagen, dass „Eve“ fast immer die Geheimnisse bekommt, hinter denen sie her ist. Diese scheinbar widersprüchlichen Aussagen können beide zutreffen, da die Netzwerkverschlüsselung robust und daher selten das Ziel von Angriffen ist.

Um das Problem zu untersuchen, schauen wir uns das Szenario an, in dem Eve zwischen Alice und Bob sitzt und Nachrichten nach Belieben hören und sogar manipulieren kann. Das Szenario geht davon aus, dass Alice und Bob sich die Geheimnisse anvertrauen, die sie teilen; diese Annahme erweist sich jedoch in der Praxis als sehr falsch. Das Lehrbuchdiagramm in Abbildung 2 veranschaulicht das Problem tatsächlich, da Alice scheinbar ohne jegliche Technologie aus der Ferne mit Bob kommuniziert.

Abbildung 2:Lehrbuch Kommunikation von Alice und Bob

Die Realität der Situation ist, dass eine Art von Gerät verwendet wird, um Alice und Bob die Kommunikation zu ermöglichen, und hier überwiegt unsere Annahme. In der Computersicherheit gibt es ein Konzept, das als Trusted Computing Base (TCB) bekannt ist. Einfach ausgedrückt sind TCB alle Komponenten (sowohl einzeln als auch als System), einschließlich der Software, denen Sie vertrauen müssen, um eine Art von Verarbeitung zu gewährleisten. In unserem klassischen Alice-und-Bob-Szenario versuchen wir, das Teilen von Geheimnissen aus der Ferne zu sichern. Es stimmt, dass Alice annimmt, Bob zu vertrauen, um Geheimnisse mit ihm zu teilen, aber sie vertraut auch seiner Computerumgebung (und ihrer). In einem realen Szenario ist dies ein Ensemble aus Hunderten von Komponenten verschiedener Hersteller, auf dem (a) wahrscheinlich ein Betriebssystem mit Millionen von Codezeilen ausgeführt wird; (b) voller Anwendungen, die von Personen codiert wurden, die Sie nicht kennen; und (c) wahrscheinlich mit einem öffentlich zugänglichen Netzwerk verbunden, das Angreifern und sich automatisch verbreitender Malware freien Zugang ermöglicht, um das System nach Belieben anzugreifen. Diese Systeme sind alles andere als vertrauenswürdig, um es gelinde auszudrücken.

...die Situation ist vergleichbar mit dem Bau einer Stahltür mit aufwendigen Schlössern an einem Haus mit Papierwänden.

Es ist die Quelle des zynischen Humors für viele in der Computersicherheitsgemeinschaft, wenn ein neues und besseres Verschlüsselungsverfahren empfohlen wird, um die Kommunikation über das Kabel zu verschlüsseln. Schließlich lassen sich Geheimnisse mit geringem Aufwand an der Quelle oder am Zielort ganz im Klaren sein, ohne sich Gedanken über die Verschlüsselung machen zu müssen. Ich habe immer gedacht, dass die Situation analog zum Bau einer Stahltür mit aufwendigen Schlössern an einem Haus mit Papierwänden ist.

Was ist also zu tun? Der gegenwärtige Ansatz in der Industrie konzentriert sich weitgehend darauf, die minimal praktikablen Komponenten (Hardware und Software) zu finden, die erforderlich sind, um eine kritische Aufgabe zu erfüllen, jede Komponente zu zertifizieren und/oder zu messen und sie von anderen Komponenten im System zu isolieren. Auf einer sehr grundlegenden Ebene verkleinert dieser Ansatz den TCB und überprüft, ob keine Komponente innerhalb des TCB hinzugefügt oder modifiziert wurde.

Sicherheit am Endpunkt (und an jedem Punkt dazwischen)

Es ist nützlich anzumerken, dass wir in der Computertechnik zwar nicht trivial sind, aber den Punkt erreicht haben, an dem es möglich ist, eine sichere Computerumgebung aufzubauen. Das Problem ist, dass die aktuelle Marktnachfrage nach einer umfassenden Computerumgebung besteht, die im Widerspruch zu einer sicheren steht. Selbst im IIoT besteht die Nachfrage nach umfangreichen Computing-Umgebungen nicht immer aufgrund der enormen Funktionalität, die sie bieten, sondern weil sie beliebt und gut unterstützt sind und daher viel kostengünstiger in der Entwicklung und Wartung sind. So findet das große TCB-Problem seinen Weg in Geräte, die mit einem anderen Ansatz abgesichert werden könnten. Als Antwort auf dieses Problem hat die Industrie dazu übergegangen, Systeme zu entwickeln, die sowohl ein umfangreiches Betriebssystem als auch eine (irgendwie) getrennte Trusted Execution Environment (TEE) in einem einzigen Gerät bieten.

Die meisten TEE-Designs haben im Wesentlichen zwei Betriebssysteme, die parallel auf einem einzigen Gerät laufen. Das reichhaltige Betriebssystem verarbeitet allgemeine Aufgaben, und das sichere Betriebssystem verarbeitet sensible Aufgaben. Das TEE-Design ermöglicht das Umschalten zwischen den beiden. Der Wechsel wird oft hardwareunterstützt und durchgesetzt. Auf der sicheren Seite werden gängige Vertrauensmechanismen – wie das Laden der Root-of-Trust-Chain – verwendet, um sicherzustellen, dass kein unautorisierter Code eingeführt wurde.

SGX ist ganz anders. Sogar ein TCB auf der sicheren Seite kann ziemlich groß sein. Die Vertrauensbasis stellt lediglich sicher, dass ein Programm beim Laden unverändert bleibt. Daher hängt seine Sicherheit von Software-Validierungstechniken für jedes geladene Programm (einschließlich des minimalen Betriebssystems) ebenso ab wie von seinem vertrauenswürdigen Boot-Prozess. Intel hat sich vorgenommen, den TCB radikal zu minimieren. Die Angriffsfläche in einem SGX-fähigen Prozessor ist die CPU und die Anwendung. Es gibt kein Betriebssystem, keine Firmware, keinen Hypervisor, keine andere Hardware oder kein BIOS, dem in einer SGX-Umgebung vertraut werden muss. Die einzige Software, der man vertrauen muss, ist die Anwendung selbst. SGX bietet eine Methode, um das vertrauenswürdige Laden dieser Anwendung auf die gleiche Weise wie bei einem normalen vertrauenswürdigen Start sicherzustellen, außer dass die Vertrauenskette nur 3 Glieder lang ist (Root Attestation, CPU, Anwendung) anstelle der ziemlich langen Ketten in einem herkömmlichen sicheren Bootsystem.

[1] [2] 下一页

Internet der Dinge-Technologie

  1. DDS-Sicherheit auf die Hardware-Weise - SGX Teil 3:Gehärtete DDS-Dienste
  2. Der Weg zur industriellen IoT-Sicherheit
  3. Bekämpfung von Sicherheitslücken des industriellen IoT
  4. Sicherung des IoT gegen Cyberangriffe
  5. Absicherung des IoT-Bedrohungsvektors
  6. Die Sicherheitsherausforderung durch das Internet der Dinge:Teil 2
  7. Die Sicherheitsherausforderung durch das Internet der Dinge:Teil 1
  8. Schutz des industriellen IoT:Einführung eines Ansatzes der nächsten Generation – Teil 2
  9. Sicherheit erschließt das wahre Potenzial des IoT
  10. UID-Übersichtsserie – Teil III – Die Zukunft der UID