Asegurando DDS con SGX: Construyendo Aplicaciones Cifradas Usando SCONE y Micro DDS

Esta es la Parte 2 de una serie de seis blogs sobre este tema. Si se perdió la visión general de la Parte 1, por favor léala aquí.

Por Qué SGX Requiere Re-arquitectura

Intel® introdujo Extensiones de Guardia de Software (SGX) con la promesa de aislar código y datos sensibles en un enclave protegido. La guía original del SDK alentaba a los desarrolladores a rediseñar sus aplicaciones desde cero o re-arquitecturar código existente para que los secretos y la lógica que los gestiona vivan en una partición separada. Este enfoque mantiene la base de computación de confianza (TCB) lo más pequeña posible, abordando directamente muchos de los vectores de ataque que amenazan los sistemas distribuidos modernos.

El Costo de Refactorizar Aplicaciones Existentes

Re-arquitecturar bases de código maduras es intensivo en mano de obra. En un estudio conjunto entre Intel y la Academia de la Fuerza Aérea de EE. UU., un visor PDF de código abierto fue transformado para soportar control de acceso de grano fino y redacción digital. Una aplicación separada de videoconferencia de código abierto fue modificada para cifrar flujos multimedia antes de llegar a la pantalla. Ambos proyectos requirieron aproximadamente dos años-hombre de esfuerzo para completarse.

Vías Alternativas: Contenedores Protegidos por SGX

Debido a que el proceso de refactorización es costoso —y a menudo imposible cuando el código fuente no está disponible— han surgido varios proyectos para simplificar la integración de SGX. Ejemplos notables incluyen Graphene y SCONE, que proporcionan contenedores protegidos por SGX y compiladores cruzados que funcionan con binarios existentes. En esta publicación nos centramos en SCONE, que puede compilar RTI Connext DDS Micro y sus plugins de seguridad con solo ajustes menores en scripts de construcción o ligeras modificaciones de librerías.

SCONE también produce un ejecutable enlazado estáticamente que corre en una instalación vanilla de Ubuntu 16.04 equipada con el controlador SGX y una CPU compatible. Graphene, por el contrario, requiere agregar una nueva llamada al sistema (getifaddrs) o modificar DDS para evitarla, así como varios cambios en otras llamadas DDS como nanosleep. Además, las aplicaciones Graphene deben ejecutarse dentro de un contenedor Docker. Por esas razones, comenzamos con SCONE en este artículo.

Preparando su Entorno de Construcción

El compilador cruzado SCONE agrupa una toolchain basada en musl que enlaza estáticamente todas las dependencias. Para compilar RTI DDS Micro y OpenSSL, necesita los siguientes recursos:

• RTI DDS Connext Micro 3.0 (código fuente disponible mediante licencia de RTI)
• Código fuente OpenSSL 1.0.2r (descargue aquí)
• Imágenes de contenedor SCONE (privadas; solicite acceso en info@scontain.com)

Su máquina host debe soportar SGX y ejecutar Ubuntu 16.04 LTS. Si tiene una CPU capaz de SGX, instale el controlador desde GitHub. Se asume familiaridad con Docker y Linux.

Coloque los dos tarballs de código fuente en su directorio home y descomprímalos, creando estos directorios:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Todos los comandos subsiguientes son relativos a estas rutas.

Lanzando el Compilador Cruzado SCONE

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

Si no tiene un dispositivo SGX, omita --device=/dev/isgx. Dentro del contenedor, agregue utilidades convenientes:

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

Construyendo OpenSSL

El módulo Perl reinstalado resuelve dependencias faltantes en el script de configuración de OpenSSL. Ejecute:

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 

Los enlaces simbólicos acomodan el Makefile usado luego; son una solución pragmática que funciona de forma fiable.

Compilando 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 

Tras la finalización, tendrá librerías OpenSSL y RTI DDS Micro enlazadas contra musl, no glibc.

Construyendo una Aplicación de Ejemplo

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

Tanto un ejecutable publicador como suscriptor aparecen en /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Ejecute el publicador para ver las variables de entorno de runtime y el hash del enclave:

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

La salida típica incluye configuración SGX y un hash de enclave único. Mensajes "error" menores sobre comprobaciones de prioridad de hilo son benignos; provienen de la falta de soporte de musl para ciertas características de glibc y pueden silenciarse editando posixThread.c si se desea.

Ejecutando Fuera del Contenedor Docker

Como el ejecutable está enlazado estáticamente, puede correr en cualquier sistema Ubuntu 16.04 con el controlador SGX instalado. Primero cree un archivo de configuración 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 

Luego lance el publicador y suscriptor:

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 

La comunicación exitosa confirma que la aplicación corre dentro de un enclave SGX, incluso cuando se ejecuta fuera del entorno Docker original.

Lo Que Hemos Logrado

Hemos demostrado un flujo de trabajo completo para convertir una aplicación estándar RTI Connext DDS Micro en un binario autónomo protegido por SGX usando SCONE. Aunque este ejemplo "Hola Mundo" no cubre almacenamiento persistente, atestación remota ni políticas de seguridad avanzadas, establece una base sólida para construir servicios DDS endurecidos en entornos SGX.

Manténganse atentos para la Parte 3, donde exploraremos cómo endurecer servicios DDS para despliegues de producción.