Protegendo DDS com SGX: Construindo Aplicações Criptografadas Usando SCONE e Micro DDS

Esta é a Parte 2 de uma série de seis blogs sobre este tópico. Se você perdeu a visão geral da Parte 1, por favor leia aqui.

Por que SGX Requer Re-Arquitetura

A Intel® introduziu Software Guard Extensions (SGX) com a promessa de isolar código e dados sensíveis em um enclave protegido. A orientação original do SDK encorajava desenvolvedores a redesenhar suas aplicações do zero ou re-arquitetar código existente para que segredos e a lógica que os gerencia vivam em uma partição separada. Esta abordagem mantém a base de computação confiável (TCB) o menor possível, abordando diretamente muitos dos vetores de ameaça que ameaçam sistemas distribuídos modernos.

O Custo de Refatorar Aplicações Existentes

Re-arquitetar bases de código maduras é intensivo em mão de obra. Em um estudo conjunto entre Intel e a Academia da Força Aérea dos EUA, um visualizador de PDF de código aberto foi transformado para suportar controle de acesso de grão fino e redacção digital. Uma aplicação de videoconferência de código aberto separada foi modificada para criptografar fluxos de mídia antes de chegarem ao display. Ambos os projetos exigiram aproximadamente dois homens-ano de esforço para completar.

Caminhos Alternativos: Contêineres Protegidos por SGX

Como o processo de refatoração é caro — e frequentemente impossível quando o código-fonte não está disponível — vários projetos surgiram para simplificar a integração SGX. Exemplos notáveis incluem Graphene e SCONE, que fornecem contêineres protegidos por SGX e compiladores cruzados que funcionam com binários existentes. Neste post, focamos no SCONE, que pode compilar RTI Connext DDS Micro e seus plugins de segurança com apenas pequenos ajustes em scripts de build ou tweaks leves de biblioteca.

SCONE também produz um executável estaticamente linkado que roda em uma instalação vanilla Ubuntu 16.04 equipada com o driver SGX e uma CPU compatível. Graphene, por outro lado, requer adicionar uma nova system call (getifaddrs) ou modificar DDS para evitá-la, bem como várias mudanças em outras chamadas DDS como nanosleep. Além disso, aplicações Graphene devem rodar dentro de um contêiner Docker. Por essas razões, começamos com SCONE neste artigo.

Preparando Seu Ambiente de Build

O compilador cruzado SCONE agrupa uma toolchain baseada em musl que linka estaticamente todas as dependências. Para compilar RTI DDS Micro e OpenSSL, você precisa dos seguintes recursos:

• RTI DDS Connext Micro 3.0 (código-fonte disponível por licenciamento da RTI)
• Código-fonte OpenSSL 1.0.2r (download aqui)
• Imagens de contêiner SCONE (privadas; solicite acesso em info@scontain.com)

Sua máquina host deve suportar SGX e rodar Ubuntu 16.04 LTS. Se você tem uma CPU capaz de SGX, instale o driver de GitHub. Familiaridade com Docker e Linux é assumida.

Coloque os dois tarballs de fonte em seu diretório home e desempacote-os, criando estes diretórios:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Todos os comandos subsequentes são relativos a estes caminhos.

Iniciando o Compilador Cruzado SCONE

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

Se você não tem um dispositivo SGX, omita --device=/dev/isgx. Dentro do contêiner, adicione utilitários convenientes:

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

Compilando OpenSSL

O módulo Perl reinstalado resolve dependências faltantes no script de configuração do OpenSSL. Execute:

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 

Os symlinks acomodam o Makefile usado depois; são uma solução pragmática que funciona de forma confiável.

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 

Após a conclusão, você terá bibliotecas OpenSSL e RTI DDS Micro linkadas contra musl, não glibc.

Compilando uma Aplicação de Exemplo

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

Tanto um executável publisher quanto subscriber aparecem em /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Execute o publisher para ver variáveis de ambiente de runtime e hash do enclave:

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

A saída típica inclui configurações SGX e um hash de enclave único. Mensagens de "erro" menores sobre verificações de prioridade de thread são benignas; decorrem da falta de suporte do musl para certos recursos do glibc e podem ser silenciadas editando posixThread.c se desejado.

Executando Fora do Contêiner Docker

Como o executável é estaticamente linkado, pode rodar em qualquer sistema Ubuntu 16.04 com o driver SGX instalado. Primeiro crie um arquivo de configuração 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 

Então inicie o publisher e 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 

Comunicação bem-sucedida confirma que a aplicação roda dentro de um enclave SGX, mesmo quando executada fora do ambiente Docker original.

O que Alcançamos

Demonstramos um fluxo de trabalho completo para transformar uma aplicação padrão RTI Connext DDS Micro em um binário autossuficiente protegido por SGX usando SCONE. Embora este exemplo "Hello World" não cubra armazenamento persistente, atestação remota ou políticas de segurança avançadas, estabelece uma base sólida para construir serviços DDS fortalecidos em ambientes SGX.

Fique atento para a Parte 3, onde exploraremos como fortalecer serviços DDS para implantações de produção.