Защита DDS с SGX: создание зашифрованных приложений с использованием SCONE и Micro DDS

Это Часть 2 в серии из шести блогов на эту тему. Если вы пропустили обзор Части 1, пожалуйста, прочитайте его здесь.

Почему SGX требует переархитектурирования

Intel® представила Software Guard Extensions (SGX) с обещанием изолировать чувствительный код и данные в защищенном анклаве. Оригинальное руководство SDK поощряло разработчиков перепроектировать свои приложения с нуля или переархитектурировать существующий код так, чтобы секреты и логика их управления жили в отдельном разделе. Этот подход держит доверенную вычислительную базу (TCB) максимально малой, прямо адресуя многие векторы атаг, угрожающие современным распределенным системам.

Стоимость рефакторинга существующих приложений

Переархитектурирование зрелых кодовых баз трудоемко. В совместном исследовании Intel и Военно-воздушной академии США, открытый PDF-смотрщик был трансформирован для поддержки гранулярного контроля доступа и цифровой редактирования. Отдельное открытое видео-конференц-приложение было модифицировано для шифрования медиа-потоков до достижения дисплея. Оба проекта потребовали примерно двух человеко-лет усилий для завершения.

Альтернативные пути: SGX-защищенные контейнеры

Поскольку процесс рефакторинга дорог — и часто невозможен, когда исходный код недоступен — несколько проектов возникли для упрощения интеграции SGX. Примерами являются Graphene и SCONE, которые предоставляют SGX-защищенные контейнеры и кросскомпиляторы, работающие с существующими бинарниками. В этом посте мы фокусируемся на SCONE, который может собрать RTI Connext DDS Micro и его плагины безопасности с лишь незначительными изменениями скриптов сборки или легкими правками библиотек.

SCONE также производит статически-связанный исполняемый файл, работающий на ванильном Ubuntu 16.04 с установленным SGX-драйвером и совместимым CPU. Graphene, напротив, требует добавления нового системного вызова (getifaddrs) или модификации DDS для его избежания, а также несколько изменений других DDS-вызовов, таких как nanosleep. Кроме того, Graphene-приложения должны запускаться внутри Docker-контейнера. По этим причинам мы начинаем с SCONE в этой статье.

Подготовка среды сборки

Кросскомпилятор SCONE связывает musl-базированный тулчейн, статически линкующий все зависимости. Для компиляции RTI DDS Micro и OpenSSL вам нужны следующие ресурсы:

• RTI DDS Connext Micro 3.0 (исходный код доступен по лицензии от RTI)
• OpenSSL 1.0.2r исходники (скачать здесь)
• SCONE образы контейнеров (приватные; запросить доступ на info@scontain.com)

Ваш хост-машин должен поддерживать SGX и работать на Ubuntu 16.04 LTS. Если у вас есть SGX-совместимый CPU, установите драйвер с GitHub. Предполагается знакомство с Docker и Linux.

Поместите два исходных тарбола в вашу домашнюю директорию и распакуйте их, создав эти директории:

openssl-1.0.2r
rti_connext_dds_micro-3.0.0

Все последующие команды относительно этих путей.

Запуск кросскомпилятора SCONE

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

Если у вас нет SGX-устройства, опустите --device=/dev/isgx. Внутри контейнера добавьте удобные утилиты:

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

Сборка OpenSSL

Переустановленный Perl-модуль решает отсутствующие зависимости в скрипте конфигурации OpenSSL. Запустите:

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 

Симлинки приспособляют Makefile, используемый позже; это прагматичное решение, которое надежно работает.

Компиляция 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 

После завершения у вас будут OpenSSL и RTI DDS Micro библиотеки, связанные с musl, а не glibc.

Сборка примера приложения

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

И издатель, и подписчик исполняемые файлы появляются в /home/rti_connext_dds_micro-3.0.0/example/unix/C/HelloWorld_dpde_secure/objs/sgxLinux_x64gcc/. Запустите издателя, чтобы увидеть переменные среды выполнения и хеш анклава:

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

Типичный вывод включает настройки конфигурации SGX и уникальный хеш анклава. Незначительные «ошибки» о проверках приоритета потока безвредны; они исходят из отсутствия поддержки musl определенных glibc-функций и могут быть подавлены редактированием posixThread.c при желании.

Запуск вне Docker-контейнера

Поскольку исполняемый файл статически связан, он может запускаться на любом Ubuntu 16.04 с установленным SGX-драйвером. Сначала создайте конфигурационный файл 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 

Затем запустите издателя и подписчика:

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 

Успешная коммуникация подтверждает, что приложение работает внутри SGX-анклава, даже при выполнении вне исходной Docker-среды.

Что мы достигли

Мы продемонстрировали полный рабочий процесс для превращения стандартного RTI Connext DDS Micro приложения в самодостаточный, SGX-защищенный бинарник с использованием SCONE. Хотя этот пример «Hello World» не охватывает постоянное хранилище, удаленную аттестацию или передовые политики безопасности, он устанавливает твердую основу для построения укрепленных DDS-сервисов в SGX-среде.

Оставайтесь на связи для Части 3, где мы исследуем, как укрепить DDS-сервисы для производственных развертываний.