Industrial IoT mit Intel SGX absichern: Überblick über DDS-Sicherheit

Teil 1 einer mehrteiligen Serie

Der Schutz missionskritischer industrieller IoT-Umgebungen erfordert Sicherheit, die vom Edge bis zur Cloud skaliert, über mehrere Systeme und Lieferanten hinweg. Als führender Autor des OMG DDS Security Standards hat RTI mitgeholfen, die wesentlichen Anforderungen für den Schutz verteilter Umgebungen zu definieren. DDS Security Plugins liefern robusten, datenzentrischen Schutz für Daten in der Übertragung, während RTI Connext DDS Secure einen bewährten, vertrauenswürdigen Konnektivitätsrahmen bietet, der Systeme mit flexibler, feingranularer Kontrolle und optimaler Leistung vom Gerät bis zur Cloud absichert.

Sicherheit bleibt eine komplexe Herausforderung. Obwohl RTIs Connext DDS Framework hochgradige Software-Sicherheit integriert, erforscht unser Research-Team aktiv zusätzliche Ebenen, um IIoT-Deployments zu befestigen. In dieser Serie teilen wir Einblicke aus RTI Research zu innovativen Sicherheitsansätzen.

Sicherheitsexperte Jason Upchurch untersucht Hardware-Mechanismen, die Applikationen auf unvertrauten Systemen schützen. Er fokussiert auf Intel SGX® im Kontext von RTI Connext® DDS Micro und Security Plugins und erweitert die Schutzgrenzen.

Lassen Sie uns eintauchen.

Was ist SGX und warum ist es wichtig?

SGX (Software Guard Extensions) ist eine Intel ISA-Erweiterung, die eine Trusted Execution Environment (TEE) für Applikationen bietet, die sensible Daten verarbeiten. Obwohl Intel-Prozessoren in IIoT-Geräten nicht dominieren, erscheinen sie häufig in Serverräumen, die viele IIoT-Architekturen untermauern. Diese serverseitigen Applikationen sind hochwertige Ziele für Angreifer, was SGX zu einem wertvollen Werkzeug für die Sicherung kritischer Datenflüsse macht.

Abbildung 1: Connext DDS Secure innerhalb des SGX-Raums

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

Betrachten Sie das klassische Alice-und-Bob-Szenario: Nachrichten reisen über ein Netzwerk, das ein Lauscher, Eve, abfangen könnte. Während Verschlüsselung Daten im Transit schützt, kompromittieren reale Angreifer oft die Endpunkte selbst. Als ehemaliger Ermittler großangelegter Intrusionen habe ich gesehen, dass Eve selten verschlüsselten Traffic abfängt, aber häufig Geheimnisse von kompromittierten Systemen stiehlt.

In der Praxis verlassen sich Alice und Bob auf eine Vielzahl von Komponenten – Betriebssysteme, Applikationen, Firmware und Netzwerkhardware –, um Nachrichten zu übermitteln. Die Trusted Computing Base (TCB) für ein solches System kann hunderte Elemente verschiedener Vendors umfassen, was es schwierig macht, dem gesamten Stack zu vertrauen.

Wie ein Sicherheitsexperte einmal bemerkte: „Es ist wie der Bau einer Stahltür mit aufwendigen Schlössern an einem Haus aus Papierwänden.“

Um dieses Risiko zu mindern, verfolgt die Industrie die Strategie, die minimal notwendige Menge an Komponenten zu isolieren, die vertraut werden müssen, jede zu zertifizieren und sicherzustellen, dass kein unautorisierter Code in die TCB gelangt.

Sicherheit am Endpunkt (und jedem Punkt dazwischen)

Heutige Computing-Umgebungen balancieren reiche Funktionalität mit Sicherheit. In IIoT bevorzugen Entwickler oft weit verbreitete, funktionsreiche Betriebssysteme aus Kosten- und Kompatibilitätsgründen, was die TCB vergrößert. Um diese Anforderungen zu vereinbaren, führen viele Geräte nun ein Standard-OS neben einer separaten Trusted Execution Environment (TEE) aus.

Typische TEEs arbeiten mit zwei parallelen Betriebssystemen: einem Rich-OS für allgemeine Aufgaben und einem Secure-OS für sensible Operationen. Der Übergang zwischen ihnen wird hardware-kontrolliert und durch Mechanismen wie Root-of-Trust Chain Loading verifiziert.

SGX bietet einen distincten Ansatz. Seine TCB beschränkt sich auf die CPU und die Applikation selbst, eliminiert das Vertrauen in OS, Firmware, Hypervisor oder BIOS. Die einzige Software, der vertraut werden muss, ist die Applikation, und die Vertrauenskette ist nur drei Glieder lang – Root Attestation, CPU, Applikation – was eine substanzielle Reduktion der Angriffsfläche bietet.

Abbildung 3: Angriffsfläche in einer SGX-Umgebung

In meinen Experimenten führe ich eine DDS-Applikation innerhalb einer SGX-Enclave auf einem vanilla Ubuntu 16.04 System aus. Von DDS Secure verschlüsselte Daten erreichen das OS, werden dann in SGX weitergeleitet, wo die Verschlüsselung entfernt und von der Applikation in einer isolierten, undurchsichtigen Umgebung verarbeitet wird. Die Ergebnisse werden mit Connext DDS Secure erneut verschlüsselt, bevor sie die Enclave verlassen. Dieser Ansatz schützt Daten vor dem OS und jeglicher bösartiger Software, sodass selbst ein privilegierter Angreifer nicht auf die Daten der Applikation zugreifen kann.

Für einen tieferen Einblick in SGX und DDS Security, kontaktieren Sie mich gerne direkt.