DDS Beveiligen met SGX: Gecrypteerde Applicaties Bouwen met SCONE & Micro DDS
Dit is Deel 2 in een zes‑blogreeks over dit onderwerp. Als u Deel 1 overzicht gemist heeft, lees het hier.
Waarom SGX Her‑Architectuur Vereist
Intel® introduceerde Software Guard Extensions (SGX) met de belofte om gevoelige code en data in een beschermde enclave te isoleren. De oorspronkelijke SDK‑richtlijnen moedigden ontwikkelaars aan om hun applicaties vanaf nul te herontwerpen of bestaande code te her‑architecturen zodat geheimen en de logica die ze beheert in een afzonderlijke partitie leven. Deze benadering houdt de trusted computing base (TCB) zo klein mogelijk, wat direct veel van de aanvalsvectoren aanspreekt die moderne gedistribueerde systemen dreigen.
De Kosten van Refactoring Bestaande Applicaties
Her‑architectuur van volwassen codebases is arbeidsintensief. In een gezamenlijke studie tussen Intel en de United States Air Force Academy, werd een open‑source PDF‑viewer getransformeerd ter ondersteuning van fijnmazige toegangscontrole en digitale redactering. Een aparte open‑source videoconferentie‑applicatie werd gewijzigd om mediastreams te versleutelen voordat ze het display bereikten. Beide projecten vereisten ongeveer twee man‑jaren om te voltooien.
Alternatieve Paden: SGX‑Beschermde Containers
Omdat het refactoringproces duur is – en vaak onmogelijk wanneer broncode niet beschikbaar is – zijn er verschillende projecten ontstaan om SGX‑integratie te vereenvoudigen. Opvallende voorbeelden zijn Graphene en SCONE, die SGX‑beschermde containers en cross‑compilers bieden die werken met bestaande binaries. In deze post richten we ons op SCONE, wat RTI Connext DDS Micro en de beveiligingsplugins kan bouwen met slechts kleine aanpassingen aan buildscripts of lichtgewicht library‑tweaks.
SCONE produceert ook een statisch‑gelinkte executable die draait op een vanilla Ubuntu 16.04 installatie uitgerust met de SGX driver en een compatibele CPU. Graphene daarentegen vereist het toevoegen van een nieuwe system call (getifaddrs) of het wijzigen van DDS om het te vermijden, alsook diverse wijzigingen aan andere DDS calls zoals nanosleep. Bovendien moeten Graphene applicaties draaien binnen een Docker container. Om die redenen beginnen we met SCONE in dit artikel.
Uw Build Omgeving Voorbereiden
De SCONE cross‑compiler bundelt een musl‑gebaseerde toolchain die alle dependencies statisch linkt. Om RTI DDS Micro en OpenSSL te compileren, heeft u de volgende bronnen nodig:
- RTI DDS Connext Micro 3.0 (broncode beschikbaar via licentie van RTI)
- OpenSSL 1.0.2r bron (download hier)
- SCONE container images (privé; vraag toegang aan bij info@scontain.com)
Uw host machine moet SGX ondersteunen en Ubuntu 16.04 LTS draaien. Als u een SGX‑capable CPU heeft, installeer de driver vanaf GitHub. Kennis van Docker en Linux wordt verondersteld.
Plaats de twee bron tarballs in uw home directory en pak ze uit, wat deze directories creëert:
openssl-1.0.2r
rti_connext_dds_micro-3.0.0
Alle daaropvolgende commando's zijn relatief aan deze paden.
De SCONE Cross‑Compiler Starten
cd ~ docker run -it --device=/dev/isgx -v "$PWD":/home sconecuratedimages/crosscompilers:ubuntu
Als u geen SGX device heeft, laat --device=/dev/isgx weg. Binnen de container, voeg handige utilities toe:
apt update apt install -y make default-jre cmake nano less apt install -y perl --reinstall
OpenSSL Bouwen
De hergeïnstalleerde Perl module lost ontbrekende dependencies in het OpenSSL configuratiescript op. Voer uit:
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
De symlinks accommoderen de Makefile die later gebruikt wordt; ze zijn een pragmatische oplossing die betrouwbaar werkt.
RTI DDS Micro 3.0 Compileren
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
Na voltooiing heb je OpenSSL en RTI DDS Micro libraries gelinkt tegen musl, niet glibc.
Een Voorbeeldapplicatie Bouwen
cd /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure rm -rf objs make
Zowel een publisher als subscriber executable verschijnen in /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Draai de publisher om de runtime omgevingsvariabelen en enclave hash te zien:
SCONE_VERSION=1 SCONE_HEAP=87108864 ./objs/sgxLinux_x64gcc/HelloWorld_publisher
Typische output omvat SGX configuratie‑instellingen en een unieke enclave hash. Kleine "error" berichten over thread prioriteitscontroles zijn benigne; ze voortkomen uit musl's gebrek aan ondersteuning voor bepaalde glibc features en kunnen gedempt worden door posixThread.c te bewerken indien gewenst.
Draaien Buiten de Docker Container
Omdat de executable statisch gelinkt is, kan het draaien op elk Ubuntu 16.04 systeem met de SGX driver geïnstalleerd. Maak eerst een SCONE configuratiebestand:
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
Start vervolgens de publisher en subscriber:
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
Succesvolle communicatie bevestigt dat de applicatie draait binnen een SGX enclave, zelfs wanneer uitgevoerd buiten de oorspronkelijke Docker omgeving.
Wat We Hebben Bereikt
We hebben een complete workflow gedemonstreerd om een standaard RTI Connext DDS Micro applicatie om te zetten in een zelfstandige, SGX‑beschermde binary met behulp van SCONE. Hoewel dit "Hello World" voorbeeld geen persistente opslag, remote attestatie, of geavanceerde beveiligingsbeleidsregels dekt, vestigt het een stevige basis voor het bouwen van geharde DDS services in SGX omgevingen.
Blijf op de hoogte voor Deel 3, waar we verkennen hoe DDS services te harden voor productie‑deployments.
Internet of Things-technologie
- DDS Beveiligen met Intel SGX: Deel 3 – Gehardede DDS Services
- Industriële IoT Beveiligen met Intel SGX: Overzicht van DDS Beveiliging
- De Industriële IoT Beveiligen: Een Praktische Roadmap
- Waarom Industriële IoT-Systemen Primaire Doelen Zijn voor Cyberaanvallen – en Hoe Ze Te Beveiligen
- IoT Beveiligen: Uw Netwerk Beschermen Tegen Cyberaanvallen
- Uw IoT-ecosysteem beveiligen: Expert strategieën tegen ransomware en cyberdreigingen
- Edge Hyperconvergentie: VMware & Eurotech drijven efficiënte industriële IoT
- De IoT-landschap Beveiligen: Belangrijkste Bedreigingen en Strategische Oplossingen – Deel 2
- IoT-beveiliging: De Unieke Bedreigingslandschap voor Verbonden Apparaten Ontcijferen (Deel 1)
- Industriële IoT-beveiliging: een next-generation blueprint – Deel 2
- Beveiliging ontgrendelt IoT's volle potentieel