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 2 (Micro + Security + SCONE)

Dies ist Teil 2 in sechs -Blog-Reihe zu diesem Thema. Wenn Sie die Übersicht zu Teil 1 verpasst haben, lesen Sie sie bitte hier.

Die Entwicklung für Software Guard Extensions (SGX) wurde ursprünglich von Intel® als Refactoring-Prozess konzipiert. Jede Anwendung würde von Grund auf neu entwickelt oder neu entwickelt, um Geheimnisse und Code zur Verwaltung von Geheimnissen von anderem Code zu trennen, und dann mit dem SGX Software Development Kit (SDK) kompiliert, um die sensible Codepartition zu schützen. Dies entsprach dem Ziel von Intel, die Trusted Computing Base (TCB) auf den kleinstmöglichen Bereich zu reduzieren.

Bei bestehenden Anwendungen ist dies jedoch ein ziemlicher Prozess. In Tests haben Intel und die United States Airforce Academy einen Open-Source-PDF-Viewer in einer Early-Access-Studie überarbeitet. Das Refactoring umfasste das Hinzufügen einer Zugriffskontrolle für jeden Teil eines Dokuments (digitale Redaktion) und eine Open-Source-Anwendung für Video Teleconferencing (VTC) (Wire-to-Screen-Verschlüsselung). Der Prozess dauerte zwei Mannjahre, um beide Projekte abzuschließen.

Da Refactoring/Recompiling sowohl eine schwere Arbeit als auch, was noch schlimmer ist, aufgrund des Codezugriffs nicht immer möglich ist, haben sich eine Reihe anderer Projekte entwickelt, um SGX-geschützte Container/LibOSes und Cross-Compiler zu erstellen. Graphene und SCONE sind gute Beispiele für Projekte, die öffentlich zugänglich sind, um diese Aufgaben zu erfüllen. Ich habe mir sowohl Graphene als auch SCONE angesehen und beide haben Vor- und Nachteile für die Endergebnisse eines erfolgreichen Builds. SCONE kann jedoch bereits sowohl RTI Connext® DDS Micro- als auch RTI Connext DDS Security-Plugins mit nur Optimierungen kompilieren, um Skripte zu erstellen und/oder triviale musl-Bibliotheksänderungen zu erstellen.

Darüber hinaus erstellt SCONE eine statisch verknüpfte Anwendung, die auf einem Vanilla-Ubuntu 16.04 mit installiertem SGX-Treiber (und fähiger CPU) ausgeführt werden kann.

Graphene erfordert die Implementierung mindestens eines neuen Systemaufrufs (getifaddrs) oder Änderungen an DDS, um den Aufruf zu vermeiden, sowie mehrere Änderungen an anderen DDS-Aufrufen, die häufig in Connext DDS Micro mit eingeschränkteren Betriebssystemen (d. h. Nanosleep) durchgeführt werden. Graphene muss auch als Docker-Container ausgeführt werden. Daher liegt dieser erste Fokus auf der Implementierung einer sicheren Connext DDS Micro-Anwendung mit SCONE. Wir werden später in dieser Blogserie mehr über Graphene sprechen.

Eines der SCONE-Projekte besteht aus einem Cross-Compiler, der eine ausführbare Binärdatei ausgibt, die die Anwendung in eine SGX-geschützte Umgebung einbettet. Dieser Cross-Compiler verlinkt statisch gegen musl und nicht gegen GLibC. Als Ergebnis werden wir alle Komponenten statisch kompilieren, die zum Erstellen unserer Anwendung erforderlich sind, einschließlich OpenSSL und Connext DDS Micro.

Um mitzumachen, benötigen Sie RTI DDS Connext Micro 3.0 (einschließlich der baubaren Quelle), openssl 1.0.2r-Quelle und SCONE. RTI Connext DDS-Produkte sind (mit lizenziertem Zugang) erhältlich, indem Sie sich an RTI wenden; OpelSSL ist verfügbar unter https://www.openssl.org/source/; und SCONE wird über von SCONE kuratierte Bilder auf Dockerhub aufgerufen. Diese SCONE-Container sind privat und Sie müssen Zugang erhalten, indem Sie SCONE über [email protected] kontaktieren.

Mein Hostsystem ist SGX-fähig und läuft mit Ubuntu 16.04 LTS. Sie können ohne SGX-System mitfahren. Wenn Sie ein SGX-System haben – und SGX verwenden möchten – müssen Sie den Intel SGX-Treiber von https://github.com/intel/linux-sgx-driver installieren. Wenn Sie diesen Blog lesen, wird davon ausgegangen, dass Sie mit Docker, Docker Hub und Linux vertraut sind (oder bereit sind, dies zu lernen).

Zu Beginn lege ich sowohl RTI DDS Connext Micro 3.0 als auch OpenSSL 1.0.2r in mein Home-Verzeichnis. Ich habe sie im Home-Verzeichnis entpackt und am Ende habe ich zwei Verzeichnisse:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Alle der folgenden Befehle sind spezifisch für diese Verzeichnisse. Melden Sie sich bei Docker an und stellen Sie sicher, dass Sie sich in Ihrem Home-Verzeichnis befinden. Führen Sie die folgenden Befehle aus, um den Container im interaktiven Modus zu starten. Wenn Sie ohne SGX weitermachen, lassen Sie das --device=/dev/isgx . weg aus dem Befehl.

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

Ich habe festgestellt, dass der Container in Bezug auf einige notwendige (und einige praktische) Werkzeuge etwas zu kurz ist. Um dies zu beheben, installieren Sie die Tools direkt.

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

Als nächstes kompilieren wir OpenSSL. Die vorherige Neuinstallation von Perl hat einige fehlende Module im Konfigurationsskript behoben. Führen Sie die folgenden Befehle aus, um OpenSSL in Ihrem Container zu erstellen, zu testen und zu installieren. Beachten Sie, dass der Test einige Zeit in Anspruch nehmen wird. Für einen Standard-Benchmark dauerte es 45 Minuten, um die folgenden Befehle auf einem i5 NUC auszuführen.

cd /home/openssl-1.0.2r
./config
machen
Test machen
Installation durchführen
OPENSSLHOME exportieren=/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 Softlinks am Ende des Befehls helfen beim Makefile in dem von uns verwendeten Beispiel. Ja, es ist ein bisschen hackig (was erwartest du von dem Sicherheitsmann?), aber es funktioniert.

Als nächstes kompilieren wir RTI DDS Micro 3.0. Führen Sie die folgenden Befehle aus.

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/
RTIMEHOME exportieren=/home/rti_connext_dds_micro-3.0.0
RTIMEARCH=sgxLinux_x64gcc exportieren

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 -- Konfigurationsfreigabe

An dieser Stelle sollten wir Bibliotheken von OpenSSL und RTI DDS Micro (einschließlich Sicherheit) haben, die mit musl verknüpft sind, anstatt mit GLibC.

Kommen wir zu einer Testanwendung. Führen Sie die folgenden Befehle aus.

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

Wenn alles gut gegangen ist, haben wir sowohl einen Herausgeber als auch einen Abonnenten im folgenden Verzeichnis:/home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Lassen Sie uns es ausführen, um zu sehen, was wir haben.

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

Die Ausgabe sollte ungefähr so ​​aussehen:

SCONE_QUEUES=1 exportieren
SCONE_SLOTS=256 exportieren
SCONE_SIGPIPE=0 exportieren
SCONE_MMAP32BIT=0 exportieren
SCONE_SSPINS=100 exportieren
SCONE_SSLEEP=4000 exportieren
SCONE_KERNEL=0 exportieren
SCONE_HEAP=87108864 exportieren
SCONE_STACK=81920 exportieren
SCONE_CONFIG=/home/jason/sgx-musl.conf exportieren
SCONE_ESPINS=10000 exportieren
SCONE_MODE=hw exportieren
SCONE_SGXBOUNDS=no exportieren
SCONE_VARYS=no exportieren
SCONE_ALLOW_DLOPEN=no exportieren
SCONE_MPROTECT=no exportieren
Überarbeitung:4be39d5943d5c15e11fa17055b859de4a25c0288 (Do 23. August 14:14:04 2018 +0200)
Zweig:cf-java-fix (schmutzig)
Optionen konfigurieren:--enable-shared --enable-debug --prefix=/home/christof/GIT/subtree-scone/built/cross-compiler/x86_64-linux-musl

Enklaven-Hash:14fa1810e1d35799ba9910243cab89660b7146f96babb97a32caef9c06b3c9a2

[1555446711.154091000]FEHLER:ModuleID=0 Errcode=17 X=1 E=0 T=1
osapi/posixThread.c:96/OSAPI_Thread_get_policy:sysrc=38
# Identitäts-CA, :file:security/ca/ca.pem
# Berechtigungen CA, :file:security/ca/ca.pem
# PEER-Zertifikat:file:security/ca/certs/publisher.pem
# PEER-Schlüssel:file:security/ca/certs/publisher_key.pem
# XML-Governance:file:security/xml/governance.p7s
# XML-Berechtigungen:file:security/xml/permissions_publisher.p7s

[1555446711.159431000]FEHLER:ModulID=0 Errcode=17 X=0 E=1 T=1
/:-1/:

[1555446711.159704000]FEHLER:ModulID=0 Errcode=17 X=0 E=1 T=1
/:-1/:

[1555446711.197874000]FEHLER:ModulID=0 Errcode=17 X=0 E=1 T=1

[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. Hyperkonvergenz und Berechnung am Rand:Teil 3
  7. Die Sicherheitsherausforderung durch das Internet der Dinge:Teil 2
  8. Die Sicherheitsherausforderung durch das Internet der Dinge:Teil 1
  9. Schutz des industriellen IoT:Einführung eines Ansatzes der nächsten Generation – Teil 2
  10. Sicherheit erschließt das wahre Potenzial des IoT