Sécuriser DDS avec SGX : Construire applications chiffrées avec SCONE & Micro DDS

Ceci est la Partie 2 d'une série de six blogs sur ce sujet. Si vous avez manqué l'aperçu Partie 1, lisez-le ici.

Pourquoi SGX Requiert une Re-architecture

Intel® a introduit Software Guard Extensions (SGX) avec la promesse d'isoler code et données sensibles dans une enclave protégée. Le guidage SDK original encourageait développeurs à redessiner applications from scratch ou re-architecturer code existant pour que secrets et logique les gérant vivent dans une partition séparée. Cette approche garde la trusted computing base (TCB) aussi petite que possible, adressant directement de nombreux vecteurs d'attaque menaçant systèmes distribués modernes.

Le Coût du Refactoring Applications Existantes

Re-architecturer codebases matures est laborieux. Dans une étude conjointe Intel et United States Air Force Academy, un visualiseur PDF open-source fut transformé pour support contrôle accès granulaire et rédaction numérique. Une application open-source de vidéoconférence fut modifiée pour chiffrer flux média avant affichage. Les deux projets requirent environ deux années-homme pour compléter.

Voies Alternatives : Conteneurs Protégés SGX

Puisque le refactoring est coûteux – et souvent impossible quand code source indisponible – plusieurs projets ont émergé pour simplifier intégration SGX. Exemples notables : Graphene et SCONE, qui fournissent conteneurs protégés SGX et cross-compilateurs travaillant avec binaires existants. Dans ce post nous nous concentrons sur SCONE, qui peut builder RTI Connext DDS Micro et ses plugins sécurité avec seulement ajustements mineurs aux scripts de build ou légers tweaks bibliothèques.

SCONE produit aussi un exécutable statiquement lié tournant sur installation vanilla Ubuntu 16.04 avec driver SGX et CPU compatible. Graphene, par contraste, requiert ajout nouvel appel système (getifaddrs) ou modification DDS pour l'éviter, plus plusieurs changements autres appels DDS comme nanosleep. De plus, applications Graphene doivent tourner dans conteneur Docker. Pour ces raisons nous commençons avec SCONE ici.

Préparation Environnement Build

Le cross-compilateur SCONE bundle une toolchain musl-based qui lie statiquement toutes dépendances. Pour compiler RTI DDS Micro et OpenSSL, vous avez besoin :

• RTI DDS Connext Micro 3.0 (code source via licence RTI)
• OpenSSL 1.0.2r source (téléchargement ici)
• Images conteneurs SCONE (privées ; demandez accès info@scontain.com)

Votre machine hôte doit supporter SGX et tourner Ubuntu 16.04 LTS. Si vous avez CPU SGX-capable, installez driver depuis GitHub. Familiarité Docker et Linux assumée.

Placez les deux tarballs source dans votre home directory et décompressez, créant ces répertoires :

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Toutes commandes subséquentes sont relatives à ces paths.

Lancement Cross-Compilateur SCONE

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

Si vous n'avez pas device SGX, omettez --device=/dev/isgx. Inside conteneur, ajoutez utilitaires pratiques :

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

Construction OpenSSL

Le module Perl réinstallé résout dépendances manquantes dans script configuration OpenSSL. Exécutez :

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 

Les symlinks accommodent le Makefile utilisé plus tard ; solution pragmatique qui fonctionne fiablement.

Compilation RTI DDS Micro 3.0

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 

Après completion, vous aurez OpenSSL et RTI DDS Micro bibliothèques liées contre musl, pas glibc.

Construction Application Exemple

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

Un éditeur et un souscripteur exécutables apparaissent dans /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Lancez l'éditeur pour voir variables environnement runtime et hash enclave :

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

Sortie typique inclut paramètres configuration SGX et hash enclave unique. Messages "erreur" mineurs sur vérifications priorité threads sont bénins ; ils découlent du manque support musl pour certaines fonctionnalités glibc et peuvent être silencés en éditant posixThread.c si désiré.

Exécution Hors Conteneur Docker

Puisque l'exécutable est statiquement lié, il peut tourner sur tout système Ubuntu 16.04 avec driver SGX installé. Créez d'abord fichier config SCONE :

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 

Puis lancez éditeur et souscripteur :

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 

Communication réussie confirme que l'application tourne inside enclave SGX, même exécutée hors environnement Docker original.

Ce Que Nous Avons Réussi

Nous avons démontré un workflow complet pour transformer une application RTI Connext DDS Micro standard en binaire auto-contenu, protégé SGX utilisant SCONE. Bien que cet exemple "Hello World" ne couvre pas stockage persistant, attestation distante, ou politiques sécurité avancées, il établit une base solide pour construire services DDS durcis en environnements SGX.

Restez branché pour Partie 3, où nous explorerons comment durcir services DDS pour déploiements production.