SGX로 DDS 보안하기: SCONE & Micro DDS로 암호화된 애플리케이션 구축

이 주제에 대한 6부작 블로그 시리즈의 2부입니다. 1부 개요를 놓치셨다면 여기서 읽어보세요.

SGX가 재설계를 요구하는 이유

인텔®은 소프트웨어 가드 확장(SGX)을 통해 민감한 코드와 데이터를 보호된 엔클레이브에 격리할 것을 약속했습니다. 원래 SDK 가이드는 개발자들이 애플리케이션을 바닥부터 재설계하거나, 비밀과 이를 관리하는 로직이 별도 파티션에 살도록 기존 코드를 재설계하도록 권장했습니다. 이 접근법은 신뢰 컴퓨팅 베이스(TCB)를 가능한 한 작게 유지하여 현대 분산 시스템을 위협하는 많은 공격 벡터를 직접 해결합니다.

기존 애플리케이션 리팩토링 비용

성숙한 코드베이스 재설계는 노동 집약적입니다. 인텔과 미국 공군 사관학교의 공동 연구에서 오픈소스 PDF 뷰어를 세분화된 접근 제어와 디지털 편집 지원하도록 변환했습니다. 별도 오픈소스 화상 회의 애플리케이션은 디스플레이에 도달하기 전 미디어 스트림을 암호화하도록 수정했습니다. 두 프로젝트 모두 약 2인년(man-year)의 노력이 필요했습니다.

대안 경로: SGX 보호 컨테이너

리팩토링 과정이 비용이 많이 들고(소스 코드 부재 시 종종 불가능), 여러 프로젝트가 SGX 통합을 단순화하기 위해 등장했습니다. 대표적으로 Graphene과 SCONE이 있으며, 기존 바이너리와 작동하는 SGX 보호 컨테이너와 크로스 컴파일러를 제공합니다. 이 글에서는 SCONE에 초점을 맞춥니다. SCONE은 빌드 스크립트나 가벼운 라이브러리 조정만으로 RTI Connext DDS Micro와 보안 플러그인을 빌드할 수 있습니다.

SCONE은 SGX 드라이버와 호환 CPU가 장착된 바닐라 Ubuntu 16.04 설치에서 실행되는 정적 링크 실행 파일을 생성합니다. 반면 Graphene은 새로운 시스템 콜(getifaddrs) 추가나 DDS 수정으로 회피 필요, nanosleep 같은 다른 DDS 콜 여러 개 변경 필요, 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 라이브러리가 glibc가 아닌 musl에 링크됩니다.

샘플 애플리케이션 빌드

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 컨테이너 외부에서 실행

실행 파일이 정적 링크되어 SGX 드라이버가 설치된 모든 Ubuntu 16.04 시스템에서 실행 가능. 먼저 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 

성공적인 통신은 애플리케이션이 원래 Docker 환경을 벗어나도 SGX 엔클레이브 내부에서 실행됨을 확인.

달성한 것

표준 RTI Connext DDS Micro 애플리케이션을 SCONE을 사용해 독립형 SGX 보호 바이너리로 전환하는 완전한 워크플로를 시연했습니다. 이 "Hello World" 예제는 지속적 스토리지, 원격 증명, 고급 보안 정책은 다루지 않지만, SGX 환경에서 강화된 DDS 서비스를 구축하기 위한 견고한 기반을 마련합니다.

3부에서 프로덕션 배포를 위한 DDS 서비스 강화 방법을 탐구할 예정이니 기대해 주세요.