DDS mit SGX absichern: Verschlüsselte Applikationen mit SCONE & Micro DDS erstellen

Dies ist Teil 2 einer sechsteiligen Blogserie. Falls Sie Teil 1 verpasst haben, lesen Sie ihn hier.

Warum SGX Re-Architektur erfordert

Intel® führte Software Guard Extensions (SGX) mit dem Versprechen ein, sensiblen Code und Daten in einer geschützten Enclave zu isolieren. Die ursprüngliche SDK-Leitlinie ermutigte Entwickler, ihre Anwendungen von Grund auf neu zu gestalten oder bestehenden Code so umzuarchitekturieren, dass Geheimnisse und die sie verwaltende Logik in einer separaten Partition leben. Dieser Ansatz hält die Trusted Computing Base (TCB) so klein wie möglich und adressiert direkt viele Angriffsvektoren, die moderne verteilte Systeme bedrohen.

Die Kosten der Refaktorierung bestehender Anwendungen

Das Re-Architekturieren reifer Codebasen ist arbeitsintensiv. In einer gemeinsamen Studie zwischen Intel und der United States Air Force Academy wurde ein Open-Source-PDF-Viewer transformiert, um feingranulare Zugriffskontrolle und digitale Schwärzung zu unterstützen. Eine separate Open-Source-Videokonferenz-Applikation wurde modifiziert, um Mediastreams vor Erreichen des Displays zu verschlüsseln. Beide Projekte erforderten etwa zwei Mannjahre Aufwand.

Alternative Pfade: SGX-geschützte Container

Da der Refaktorierungsprozess teuer ist – und oft unmöglich, wenn Quellcode nicht verfügbar ist – sind mehrere Projekte entstanden, um SGX-Integration zu vereinfachen. Nennenswerte Beispiele sind Graphene und SCONE, die SGX-geschützte Container und Cross-Compiler bereitstellen, die mit bestehenden Binaries arbeiten. In diesem Post fokussieren wir uns auf SCONE, das RTI Connext DDS Micro und seine Security Plugins mit nur geringfügigen Anpassungen an Build-Skripten oder leichten Library-Tweaks bauen kann.

SCONE produziert auch ein statisch gelinktes Executable, das auf einer vanilla Ubuntu 16.04 Installation mit SGX-Treiber und kompatibler CPU läuft. Graphene erfordert dagegen das Hinzufügen eines neuen Systemcalls (getifaddrs) oder die Modifikation von DDS, um ihn zu vermeiden, sowie mehrere Änderungen an anderen DDS-Calls wie nanosleep. Zudem müssen Graphene-Applikationen in einem Docker-Container laufen. Aus diesen Gründen starten wir mit SCONE in diesem Artikel.

Build-Umgebung vorbereiten

Der SCONE Cross-Compiler bündelt eine musl-basierte Toolchain, die alle Dependencies statisch linkt. Zum Kompilieren von RTI DDS Micro und OpenSSL benötigen Sie folgende Ressourcen:

• RTI DDS Connext Micro 3.0 (Quellcode über Lizenzierung von RTI erhältlich)
• OpenSSL 1.0.2r Source (Download hier)
• SCONE Container Images (privat; Zugriff anfordern unter info@scontain.com)

Ihre Host-Maschine sollte SGX unterstützen und Ubuntu 16.04 LTS laufen. Falls Sie eine SGX-fähige CPU haben, installieren Sie den Treiber von GitHub. Vertrautheit mit Docker und Linux wird vorausgesetzt.

Legen Sie die beiden Source-Tarballs in Ihr Home-Verzeichnis und entpacken Sie sie, wodurch diese Verzeichnisse entstehen:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Alle nachfolgenden Befehle sind relativ zu diesen Pfaden.

SCONE Cross-Compiler starten

cd ~ docker run -it --device=/dev/isgx -v "$PWD":/home sconecuratedimages/crosscompilers:ubuntu 

Falls Sie kein SGX-Device haben, lassen Sie --device=/dev/isgx weg. Innerhalb des Containers fügen Sie nützliche Utilities hinzu:

apt update apt install -y make default-jre cmake nano less apt install -y perl --reinstall 

OpenSSL bauen

Das neu installierte Perl-Modul löst fehlende Dependencies im OpenSSL-Konfigurationsskript. Ausführen:

cd /home/openssl-1.0.2r ./config make make test make install export OPENSSLHOME=/usr/local/ssl ln -s /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libcryptoz.a ln -s /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libsslz.a 

Die Symlinks berücksichtigen das spätere Makefile; sie sind eine pragmatische Lösung, die zuverlässig funktioniert.

RTI DDS Micro 3.0 kompilieren

cp /opt/scone/cross-compiler/x86_64-linux-musl/lib/libpthread.a /opt/scone/cross-compiler/x86_64-linux-musl/lib/libnsl.a PATH=$PATH:/opt/scone/cross-compiler/libexec/gcc/x86_64-linux-musl/7.3.0/ export RTIMEHOME=/home/rti_connext_dds_micro-3.0.0 export RTIMEARCH=sgxLinux_x64gcc cd /home/rti_connext_dds_micro-3.0.0/ ./resource/scripts/rtime-make -DRTI_NO_SHARED_LIB:bool=true -DOPENSSLHOME=/usr/local/ssl --delete --target self --name $RTIMEARCH -G "Unix Makefiles" --build --config Release 

Nach Abschluss haben Sie OpenSSL und RTI DDS Micro Bibliotheken, die gegen musl, nicht glibc, gelinkt sind.

Beispiel-Applikation bauen

cd /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure rm -rf objs make 

Sowohl ein Publisher- als auch Subscriber-Executable erscheinen in /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Führen Sie den Publisher aus, um Laufzeit-Umgebungsvariablen und Enclave-Hash zu sehen:

SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_publisher 

Typische Ausgabe umfasst SGX-Konfigurationseinstellungen und einen einzigartigen Enclave-Hash. Geringfügige "Error"-Meldungen zu Thread-Prioritätsprüfungen sind benign; sie resultieren aus musls fehlender Unterstützung bestimmter glibc-Features und können durch Bearbeiten von posixThread.c unterdrückt werden, falls gewünscht.

Außerhalb des Docker-Containers ausführen

Da das Executable statisch gelinkt ist, kann es auf jedem Ubuntu 16.04 System mit installiertem SGX-Treiber laufen. Zuerst eine SCONE-Konfigurationsdatei erstellen:

tee ~/sgx-musl.conf << EOF Q 4 e -1 0 0 s -1 0 0 e -1 1 0 s -1 1 0 e -1 2 0 s -1 2 0 e -1 3 0 s -1 3 0 EOF 

Dann Publisher und Subscriber starten:

cd ~/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure SCONE_CONFIG=~/sgx-musl.conf SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_publisher SCONE_CONFIG=~/sgx-musl.conf SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_subscriber 

Erfolgreiche Kommunikation bestätigt, dass die Applikation inside einer SGX-Enclave läuft, selbst wenn sie außerhalb der ursprünglichen Docker-Umgebung ausgeführt wird.

Was wir erreicht haben

Wir haben einen vollständigen Workflow demonstriert, um eine Standard-RTI-Connext-DDS-Micro-Applikation in ein selbstständiges, SGX-geschütztes Binary mittels SCONE zu verwandeln. Während dieses "Hello World"-Beispiel persistente Speicherung, Remote Attestation oder erweiterte Security-Policies nicht abdeckt, etabliert es ein solides Fundament für den Aufbau gehärteter DDS-Services in SGX-Umgebungen.

Bleiben Sie dran für Teil 3, wo wir erforschen, wie man DDS-Services für Produktions-Deployments härtet.