DDS Security the Hard (ware) Way - SGX:Part 2 (Micro + Security + SCONE)

Esta es la Parte 2 en seis -serie de blogs sobre este tema. Si se perdió la descripción general de la Parte 1, léala aquí.

El desarrollo de Software Guard Extensions (SGX) fue diseñado originalmente por Intel® para ser un proceso de refactorización. Cada aplicación se diseñaría desde cero o se rediseñaría para particionar secretos y código de administración de secretos de otro código, luego se compilaría con el kit de desarrollo de software (SDK) SGX para proteger la partición del código sensible. Esto se alineó con el objetivo de Intel de reducir la base informática confiable (TCB) al área más pequeña posible.

Sin embargo, con las aplicaciones existentes, esto es todo un proceso. En las pruebas, Intel y la Academia de la Fuerza Aérea de los Estados Unidos refactorizaron un visor de PDF de código abierto en un estudio de acceso temprano. La refactorización incluyó agregar control de acceso a cualquier parte de un documento (redacción digital) y una aplicación de video teleconferencia (VTC) de código abierto (cifrado de cable a pantalla). El proceso tomó dos años hombre para completar ambos proyectos.

Como la refactorización / recompilación es una tarea pesada y, lo que es peor, no siempre es posible debido al acceso al código, se han presentado varios otros proyectos para crear contenedores / LibOS protegidos SGX y compiladores cruzados. Graphene y SCONE son buenos ejemplos de proyectos que están disponibles públicamente para realizar estas tareas. He analizado tanto Graphene como SCONE, y ambos tienen ventajas y desventajas para los resultados finales de una compilación exitosa. Sin embargo, SCONE ya puede compilar de forma cruzada los complementos RTI Connext® DDS Micro y RTI Connext DDS Security con solo ajustes para crear scripts y / o crear cambios triviales en la biblioteca de musl.

Además, SCONE produce una aplicación vinculada estáticamente que se puede ejecutar en un Ubuntu 16.04 básico con el controlador SGX (y CPU capaz) instalado.

El grafeno requiere la implementación de al menos una nueva llamada al sistema (getifaddrs) o cambios en DDS para evitar la llamada, así como varios cambios en otras llamadas DDS que a menudo se realizan en Connext DDS Micro con sistemas operativos más limitados (es decir, nanosleep). El grafeno también debe ejecutarse como contenedor acoplable. Como resultado, este primer enfoque está en implementar una aplicación segura Connext DDS Micro con SCONE. Hablaremos más sobre el grafeno más adelante en esta serie de blogs.

Uno de los proyectos de SCONE consiste en un compilador cruzado que genera un binario ejecutable que envuelve la aplicación en un entorno protegido por SGX. Este compilador cruzado enlaza estáticamente contra musl en lugar de GLibC. Como resultado, compilaremos estáticamente todos los componentes necesarios para construir nuestra aplicación, incluidos OpenSSL y Connext DDS Micro.

Para seguir adelante, necesitará RTI DDS Connext Micro 3.0 (incluida la fuente compilable), la fuente openssl 1.0.2r y SCONE. Los productos RTI Connext DDS están disponibles (con acceso con licencia) contactando a RTI; OpelSSL está disponible en https://www.openssl.org/source/; y se accede a SCONE a través de imágenes seleccionadas por SCONE en dockerhub. Estos contenedores de SCONE son privados y debe obtener acceso poniéndose en contacto con SCONE a través de [email protected].

Mi sistema host es compatible con SGX y ejecuta Ubuntu 16.04 LTS. Puede seguir adelante sin un sistema SGX. Si tiene un sistema SGX y desea utilizar SGX, debe instalar el controlador Intel SGX desde https://github.com/intel/linux-sgx-driver. Si está leyendo este blog, se asume que sabe cómo usar Docker, Docker Hub y Linux (o está dispuesto a aprender).

Para empezar, puse tanto el RTI DDS Connext Micro 3.0 como OpenSSL 1.0.2r en mi directorio de inicio. Los desempaqueté en el directorio de inicio y terminé con dos directorios:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Todos los siguientes comandos son específicos de estos directorios. Inicie sesión en Docker y asegúrese de estar en su directorio de inicio. Ejecute los siguientes comandos para iniciar el contenedor en modo interactivo. Si está siguiendo sin SGX, omita el --device =/ dev / isgx desde el comando.

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

Descubrí que el contenedor es un poco liviano en algunas herramientas necesarias (y convenientes). Para remediar esto, instale las herramientas directamente.

actualización de apt
apt install -y hacer default-jre cmake nano menos
apt install -y perl - reinstalar

A continuación, compilemos OpenSSL. La reinstalación anterior de perl se encargó de algunos módulos que faltaban en el script de configuración. Para crear, probar e instalar OpenSSL en su contenedor, ejecute los siguientes comandos. Tenga en cuenta que la prueba tardará algún tiempo en completarse. Para un punto de referencia aproximado, se necesitaron 45 minutos para ejecutar los siguientes comandos en un i5 NUC.

cd /home/openssl-1.0.2r
./config
hacer
hacer prueba
hacer instalación
exportar 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 suaves al final del comando ayudarán con el Makefile en el ejemplo que usaremos. Sí, es un poco hacky (¿qué esperas del tipo de seguridad?), Pero funciona.

A continuación, compilemos RTI DDS Micro 3.0. Ejecute los siguientes comandos.

cp /opt/scone/cross-compiler/x86_64-linux-musl/lib/libpthread.a /opt/scone/cross-compiler/x86_64-linux-musl/lib/libnsl.a

RUTA =$ RUTA:/opt/scone/cross-compiler/libexec/gcc/x86_64-linux-musl/7.3.0/
exportar RTIMEHOME =/ home / rti_connext_dds_micro-3.0.0
exportar 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

En este punto, deberíamos tener bibliotecas de OpenSSL y RTI DDS Micro (incluida la seguridad) vinculadas contra musl en lugar de GLibC.

Pasemos a una aplicación de prueba. Ejecute los siguientes comandos.

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

Si todo ha ido bien, tendremos tanto un editor como un suscriptor en el siguiente directorio:/home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Ejecútelo para ver qué tenemos.

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

La salida debería tener un aspecto similar a:

exportar SCONE_QUEUES =1
exportar SCONE_SLOTS =256
exportar SCONE_SIGPIPE =0
exportar SCONE_MMAP32BIT =0
exportar SCONE_SSPINS =100
exportar SCONE_SSLEEP =4000
exportar SCONE_KERNEL =0
exportar SCONE_HEAP =87108864
exportar SCONE_STACK =81920
exportar SCONE_CONFIG =/ home / jason / sgx-musl.conf
exportar SCONE_ESPINS =10000
exportar SCONE_MODE =hw
exportar SCONE_SGXBOUNDS =no
exportar SCONE_VARYS =no
exportar SCONE_ALLOW_DLOPEN =no
exportar SCONE_MPROTECT =no
Revisión:4be39d5943d5c15e11fa17055b859de4a25c0288 (jueves 23 de agosto 14:14:04 2018 +0200)
Rama:cf-java-fix (sucio)
Configurar opciones:--enable-shared --enable-debug --prefix =/ home / christof / GIT / subtree-scone / built / cross-compiler / x86_64-linux-musl

Hash del enclave:14fa1810e1d35799ba9910243cab89660b7146f96babb97a32caef9c06b3c9a2

[1555446711.154091000] ERROR:ModuleID =0 Errcode =17 X =1 E =0 T =1
osapi / posixThread.c:96 / OSAPI_Thread_get_policy:sysrc =38
# Identity CA,:file:security / ca / ​​ca.pem
# Permisos CA,:file:security / ca / ​​ca.pem
# certificado PEER:archivo:security / ca / ​​certs / publisher.pem
# clave PEER:archivo:security / ca / ​​certs / publisher_key.pem
# Gobernanza XML:archivo:security / xml / Governance.p7s
# permisos XML:file:security / xml / permissions_publisher.p7s

[1555446711.159431000] ERROR:ModuleID =0 Errcode =17 X =0 E =1 T =1
/ :- 1 / :

[1555446711.159704000] ERROR:ModuleID =0 Errcode =17 X =0 E =1 T =1
/ :- 1 / :

[1555446711.197874000] ERROR:ModuleID =0 Errcode =17 X =0 E =1 T =1
/

[1] [2] 下一页