DDS 보안 - 하드(웨어) 방식 - SGX:1부(개요)

다중 부분의 1부 시리즈

미션 크리티컬 산업용 IoT 환경을 보호하려면 시스템과 공급업체 전반에 걸쳐 에지에서 클라우드로 확장되는 보안이 필요합니다. OMG DDS 보안 표준의 주 저자인 RTI는 분산 환경을 보호하는 데 필요한 요구 사항과 환경을 정의하는 데 주도적인 역할을 했습니다. DDS 보안 플러그인은 유선 데이터에 대한 강력한 데이터 중심 보안 메커니즘을 제공합니다. RTI Connext DDS Secure는 장치에서 클라우드에 이르기까지 최적의 성능과 효율성을 위해 유연하고 세분화된 보안을 통해 시스템을 보호하는 입증되고 신뢰할 수 있는 연결 프레임워크입니다.

그러나 우리는 보안이 복잡한 문제라는 것을 알고 있습니다. RTI가 Connext DDS 소프트웨어 프레임워크에서 고급 보안을 구축한 동안 우리 연구팀은 IIoT에 보다 강력한 보안을 적용하기 위해 다른 영역을 찾고 있습니다. 이를 염두에 두고 새롭고 혁신적인 보안 접근 방식을 모색하는 RTI Research의 작업 중 일부를 여러분과 공유하게 된 것을 기쁘게 생각합니다.

이 블로그 시리즈에서 보안 전문가인 Jason Upchurch는 중요한 응용 프로그램이 데이터를 처리하는 신뢰할 수 없는 시스템에 보안을 제공하는 하드웨어 메커니즘에 대해 소프트웨어를 넘어 살펴봅니다. 보안 한계를 뛰어넘는 정신으로 그는 RTI Connext® DDS Micro 및 보안 플러그인 컨텍스트 내에서 Intel SGX®를 탐구합니다.

시작하겠습니다.

SGX란 무엇이며 왜 중요한가요?

SGX 또는 소프트웨어 가드 확장은 민감한 데이터가 포함된 응용 프로그램을 실행하기 위해 TEE(신뢰할 수 있는 실행 환경)를 제공하는 Intel ISA(명령 세트 아키텍처)의 확장입니다. Intel ISA가 산업용 IoT(IIoT)를 지배하지 않는 것은 사실이지만 서버실에서 시장 점유율을 차지하고 있으며 서버실은 종종 다양한 IIoT 아키텍처에 통합됩니다. 더 중요한 것은 이러한 서버실 데이터 처리 애플리케이션은 기존 IIoT 엔드포인트보다 보호된 데이터에 더 많이 액세스할 수 있기 때문에 악의적인 사용자의 고가치 표적이 될 가능성이 더 큽니다. 따라서 SGX는 IIoT 또는 적어도 그 일부를 보호하는 데 매우 도움이 될 수 있습니다. SGX가 DDS 사용자와 높은 보안 환경을 필요로 하는 기타 애플리케이션 개발자에게 중요한 이유를 살펴보겠습니다.

그림 1:Connext DDS Secure Inside SGX Space

전선 보안만으로는 충분하지 않을 수 있음

시작하려면 비밀을 공유하는 고전적인 Alice와 Bob 학문적 예를 살펴보겠습니다. 이야기는 Alice와 Bob이 직접 만나는 것으로 시작하여 교활한 Eve가 유선으로 메시지를 가로채는 것으로 진행되며, 비밀을 공유하는 입증된 방법으로 끝납니다. 이는 Eve가 모든 메시지를 가로채더라도 안전한 통신을 위한 기반입니다. 세계 최대 규모의 침입 조사를 여러 번 실행했지만 "Eve"가 유선에서 암호화된 메시지를 가로채서 비밀을 수집하는 것을 본 적이 없다고 자신 있게 말할 수 있습니다. 나는 또한 "이브"가 거의 항상 그녀가 추구하는 비밀을 알고 있다고 자신 있게 말할 수 있습니다. 네트워크 암호화가 강력하고 공격의 대상이 되는 경우는 드물기 때문에 이러한 겉보기에 상충되는 진술은 둘 다 사실일 수 있습니다.

문제를 조사하기 위해 Eve가 Alice와 Bob 사이에 앉아 마음대로 메시지를 듣고 조작할 수 있는 시나리오를 살펴보겠습니다. 시나리오에서는 Alice와 Bob이 공유하는 비밀을 서로 신뢰한다고 가정합니다. 그러나 이 가정은 실제로 심각한 결함이 있는 것으로 판명되었습니다. 그림 2의 교과서 다이어그램은 실제로 Alice가 기술 없이 멀리서 Bob과 통신하는 것처럼 보이는 문제를 보여줍니다.

그림 2:교과서 앨리스와 밥 커뮤니케이션

상황의 현실은 Alice와 Bob이 통신할 수 있도록 하기 위해 어떤 형태의 장치가 사용되며, 여기서 우리의 가정이 더 유리합니다. 컴퓨터 보안에는 TCB(신뢰할 수 있는 컴퓨팅 기반)라는 개념이 있습니다. 가장 간단한 용어로 TCB는 소프트웨어를 포함하여 일종의 처리를 보호하기 위해 신뢰해야 하는 모든 구성 요소(개별적으로 또는 시스템으로서)입니다. 우리의 고전적인 Alice와 Bob 시나리오에서 우리는 원거리에서 비밀 공유를 확보하려고 시도하고 있습니다. Alice가 Bob과 비밀을 공유하기 위해 Bob을 신뢰한다고 가정하는 것은 사실이지만 그녀는 또한 그의 컴퓨팅 환경(및 그녀의)을 신뢰하고 있습니다. 실제 시나리오에서 이것은 (a) 수백만 줄의 코드로 운영 체제를 실행할 가능성이 있는 다양한 제조업체의 수백 가지 구성 요소의 앙상블입니다. (b) 모르는 사람들이 코딩한 애플리케이션으로 가득 차 있습니다. (c) 공격자 및 자동 전파 맬웨어가 시스템을 마음대로 공격할 수 있도록 허용하는 공개 네트워크에 연결되었을 가능성이 있습니다. 이러한 시스템은 말할 것도 없이 신뢰할 수 없습니다.

...상황은 종이 벽으로 된 집에 정교한 자물쇠가 달린 강철 문을 만드는 것과 비슷합니다.

유선을 통한 통신을 암호화하기 위해 새롭고 더 나은 암호화 체계가 권장될 때 이는 컴퓨터 보안 커뮤니티의 많은 사람들에게 냉소적인 유머의 원천입니다. 결국, 비밀은 암호화에 대해 전혀 걱정할 필요 없이 원본이나 대상에서 약간의 노력으로 완전히 명확하게 뽑아낼 수 있습니다. 나는 항상 상황이 종이 벽으로 된 집에 정교한 자물쇠가 달린 강철 문을 만드는 것과 유사하다고 생각했습니다.

그래서 무엇을해야합니까? 현재 업계의 접근 방식은 중요한 작업을 달성하고, 각 구성 요소를 인증 및/또는 측정하고, 시스템의 다른 구성 요소와 분리하는 데 필요한 최소 실행 가능한 구성 요소(하드웨어 및 소프트웨어)를 찾는 데 주로 중점을 두고 있습니다. 매우 기본적인 수준에서 이 접근 방식은 TCB를 축소하고 TCB 내부의 구성 요소가 추가되거나 수정되지 않았는지 확인합니다.

끝점(및 그 사이의 모든 지점)에서의 보안

사소하지는 않지만 안전한 컴퓨팅 환경을 구축하는 것이 가능한 컴퓨팅의 지점에 도달했다는 점에 유의하는 것이 좋습니다. 문제는 현재 시장 수요가 보안 환경과 상충되는 풍부한 컴퓨팅 환경에 대한 것이라는 점입니다. IIoT에서도 풍부한 컴퓨팅 환경에 대한 수요는 항상 제공하는 방대한 기능이 아니라 인기 있고 잘 지원되므로 개발 및 유지 관리 비용이 훨씬 저렴하기 때문입니다. 따라서 큰 TCB 문제는 다른 접근 방식으로 보호할 수 있는 장치로 진행됩니다. 이 문제에 대한 답으로 업계에서는 단일 장치에서 풍부한 운영 체제와 (어느 정도) 분리된 TEE(신뢰할 수 있는 실행 환경)를 모두 제공하는 시스템 아키텍처를 채택했습니다.

대부분의 TEE 설계에는 기본적으로 단일 장치에서 병렬로 실행되는 두 개의 운영 체제가 있습니다. 풍부한 운영 체제는 일반적인 작업을 처리하고 보안 운영 체제는 민감한 작업을 처리합니다. TEE 디자인은 둘 사이의 전환을 허용합니다. 스위치는 종종 하드웨어가 지원되고 시행됩니다. 루트 오브 트러스트 체인 로딩과 같은 일반적인 신뢰 메커니즘은 인증되지 않은 코드가 도입되지 않았는지 확인하기 위해 보안 측면에서 사용됩니다.

SGX는 완전히 다릅니다. 보안측 TCB도 상당히 클 수 있습니다. 신뢰 루트는 로드 시 프로그램이 변경되지 않도록 보장합니다. 따라서 보안은 신뢰할 수 있는 부팅 프로세스만큼 로드된 모든 프로그램(최소 OS 포함)에 대한 소프트웨어 유효성 검사 기술에 따라 달라집니다. 인텔은 TCB를 근본적으로 최소화하기 시작했습니다. SGX 지원 프로세서의 공격 표면은 CPU와 애플리케이션입니다. SGX 환경에서 신뢰할 수 있어야 하는 OS, 펌웨어, 하이퍼바이저, 기타 하드웨어 또는 BIOS가 없습니다. 신뢰할 수 있는 유일한 소프트웨어는 응용 프로그램 자체입니다. SGX는 신뢰 체인이 전통적인 보안 방식의 긴 체인 대신 단 3링크(루트 증명, CPU, 애플리케이션)라는 점을 제외하고는 일반 신뢰 부팅과 거의 동일한 방식으로 해당 애플리케이션의 신뢰 로드를 보장하는 방법을 제공합니다. 부팅 시스템.

그림 3:SGX 환경의 공격 표면

Intel SGX 및 DDS+Security를 ​​실험해 왔습니다. 내 목표는 SGX가 활성화된 바닐라 Ubuntu 16.04의 보호 영역에서 DDS 애플리케이션을 실행하는 것입니다. 아이디어는 DDS 보호 와이어 통신이 Ubuntu OS에 도착한 다음 SGX 보호 공간으로 전달된다는 것입니다. DDS 보호는 보호된 공간 내부에서 제거됩니다. 그런 다음 데이터는 OS 및 시스템에 존재하는 악의적인 사용자/소프트웨어에 불투명한 보호 영역 내의 애플리케이션에 의해 조작될 수 있습니다. 이 작업은 OS(CPU 보호/암호화 조합)에 대해 불투명하므로 SGX 공간 내부의 Connext DDS Secure로 결과를 보호하고 유선으로 전달할 수 있습니다. 따라서 OS 또는 CPU 및 애플리케이션 외에 시스템의 어떤 부분에도 데이터가 노출되지 않습니다. 시스템에 대한 루트(또는 루트+) 액세스 권한이 있는 시스템 관리자 또는 공격자는 측면으로 애플리케이션 데이터에 액세스할 수 없으며 권한 있는 공격은 SGX 공간에 액세스할 수 없습니다.

이것은 이 주제에 대해 자세히 설명하는 여러 부분으로 구성된 시리즈의 1부입니다. 이 주제에 대한 자세한 내용은 저에게 직접 연락해 주십시오.