#11 Intel SGX

https://sgx101.gitbook.io/sgx101/sgx-bootstrap/overview

 

Security feature -> keep it secretive

어떻게 구현되어 있는지 자세한 설명이 많지는 않지만 최대한 심층적으로 살펴볼 것 (ISCA 2015 tutorial)

 

Protected Mode는 App끼리 간섭, App이 OS를 공격하는 것을 막아주지만, OS가 어떻게든 공격당했으면 이제 방어할 방법이 마땅치 않다.

때문에 Attack Surface가 broad해져 이를 다 막아내기는 쉽지 않았다.

 

SGX가 하려고 하는 것은 Attack Surface를 줄이는 것이다.

OS나 VMM에 이슈가 있다 하더라도, 믿을만한 HW와 App 내 일부 믿을만한 영역을 확보함으로서 해당 부분만 지켜내면 안전성이 확보되도록 하는 것이다.

인텔만 믿으라고 하는 것인데 실제로는 그렇지는 않다 (추후 설명)

 

---

application code를 두 개의 영역으로 분리한다.

Untrusted Part -> 일반적으로 코딩하는 영역

Trusted Part -> 인텔이 제공하는 "안전한" 영역

Trusted Part에는 call gate가 붙어있어, 마치 system call을 부를 때처럼 동작한다.

마치 또 하나의 OS 영역으로 들어가는 것처럼

OS도 enclave를 건들일 수 없다.

 

enclave는 그의 code와 data를 가지고 있고,

TCS (thread control structure) -> multithread 지원

enclave에서 일반 application의 영역을 접근하는 것은 가능하다.

 

 

page table을 조작하더라도 SGX 접근을 막기 위한 보조 메커니즘이 있다 (EPCM?)

SGX 설정이 되어있다면 DRAM의 일부 영역을 분리하여 OS도 접근하지 못하도록 한다. (EPC)

 

Access Control

주소 변환을 했다.

만약 enclave 접속이 아니라면 접근하려는 영역이 EPC 내에 있는지를 우선 확인한다.

만약 아니라면 일반 접근하듯이 처리한다.

만약 enclave 내부가 아닌 곳에서 EPC로의 접근이라면 abort page로 address를 바꾼다.

 

Enclave 내부 access라면 최종적으로 EPCM을 확인한뒤에 접근을 허가한다.

 

---

좀더 구체적으로 DRAM의 영역을 확보하는 과정을 살펴보자

 

DRAM 내부 일부 구역을 PRM(Processor Reserved Memory)으로 만들고

PRM 내부에 EPC를 생성한다. (Enclave Page Cache)

또한 이 EPC는 여러개의 4kB page로 구성이 되어 있으며, 각 page 마다 추가 기록인 메타데이터 structure (VA -> PA) 정보를 담고 있는 EPCM이 따라 붙는다.

 

Enclave가 바라보는 virtual address에서 ELRANGE는 EPC로 연결이 되어 있으며, 이는 일반 application에서는 abort page로 보이게 된다.

 

enclave는 DRAM 또한 믿지 못한다. 때문에 데이터를 저장할 때는 모든 정보가 암호화되고 CPU에 들어가서 decrypt되어 연산된다. 때문에 외부에서 이 정보를 snooping하더라도 아무것도 알아낼 수 없다.

 

Attestation (내가 누군지를 밝히는 것)

Generally speaking, the goal of Remote Attestation is for a Hardware entity or a combination of Hardware and Software to gain the trust of a remote service provider, such that the service provider can confidently provide the client with the secrets requested.

 

내 기기가 Remote Service Provider에게 신뢰할만한 기기임을 증명하는 방법

SGX module이 돌아가고 있음을 보여야 한다.

 

challenge로 RSP가 요구하는 사항들을 보내면 그에 대한 답을 보내야 한다.

EREPORT라고 하는 instruction이 있고 SGX를 지원하는 칩이면 칩마다 public / private key pair를 가지고 있어 private key로 서명해서 보내는 방식

intel 측에서 이 서명이 유효함을 인증할 수 있으므로 기기를 검증할 수 있다.

인증이 완료되었으면 key 교환을 하고 필요하다면 sealing을 통해 정보를 보관하고

 

---

In Depth Architecture

 

다 기억하는 것은 큰 의미 없다. 대략적인 느낌만 잡아라.

 

Enclave 생성하기 - ISV (independent software vendor)

개발자는 shared library를 만들듯이 enclave를 만든다.

1.0 -> static한 메모리 할당

2.0 -> dynamic allocation 가능

DEBUG 모드로 디버깅도 가능하다. -> enclave의 이념에 반하긴 하지만 개발시에는 필요하긴 하다.

 

debug enclave

enclave 내에는 코드, 데이터와 인증서가 있다.

코드와 데이터를 넘길 때 인증서 형태로 넘기며, 해당 인증서에 환경이 명시되어 있기 때문에 enclave에서 디버거 모드가 설정된다.

 

디버거에서는 특정 위치에 8 byte를 읽거나 쓸 수 있도록 하고, breakpoint와 LBR이 활성화되어있다.

 

이 인증서가 SIGSTRUCT이다.

ISV information(Product ID, Security version number)과 함께 Enclave 환경(attribute)가 들어가있다.

SIGSTRUCT를 ISV의 private key로 signing한다.

 

해당 SIGSTRUCT이 넘어왔다.

attestation까지 전부 끝났다고 하자.

 

그러면 ECREATE라는 것이 수행된다.

enclave 자체를 만들기 위한 instruction

- linear address range 세팅

- enclave mode(32/64), debug 여부 확인

- 만들어진 enclave의 정보는 Secure Enclaves Control Structure(SECS)에 담아 저장한다.

해당 정보의 위치는 EPC 내부이다.

 

EADD / EREMOVE

enclave 내부의 페이지를 할당/해제 하는 역할을 한다.

페이지를 할당할 때는 regular 또는 TCS 페이지로서 추가한다.

각 페이지가 할당될 때는 EPCM도 같이 추가된다.

EPCM은 각 enclave 내부 페이지의 VA -> PA 변환 정보, RWX 정보 등을 포함하고 있다.

 

EPC의 크기 자체는 BIOS에서 설정된 것이고

미할당된 것을 할당/반환시키는 역할이다.

OS가 이상한 페이지를 줄 것을 염두해 두어 자체적으로 검사하는 루틴이 돌아가고 있다.

 

반환시에는 페이지 내용을 clear시켜서 다른 enclave로의 내용 유출을 막는다.

 

EEXTEND

cryptographic hash를 뜨는 것 (256 Byte)

16번 반복하면 4K page 하나의 hash를 뜰 수 있다.

인증서와 비교해본다.

 

EINIT

개발자가 만든 SIGSTRUCT대로 enclave의 content가 잘 세팅되었는지 검증하고 enclave가 동작할 수 있도록 한다.

 

EENTER

SYSENTER와 비슷한 역할, enclave 영역으로의 변환을 담당

mutlithreading을 염두에 두어 TCS가 occupy가 되었는지를 확인하고 busy하지 않다면 TLB entry를 flush한다. 이유는?

TLB attack에 대비하기 위함

-> HW는 cache coherence는 신경 쓰지만 TLB coherence는 OS의 담당이기 때문에 악의적인 OS가 SGX에서 사용될 주소의 매핑을 TLB에 미리 세팅해두어(또는 OS가 의도치 않게 coherence를 맞추지 않아) 원치 않는 곳에 정보가 유출될 수 있으므로 이를 방지.

문제는 성능상 overhead가 생기며, Page Table Walkthrough를 해야하므로 느릴 수밖에 없다.

 

Transfer Control

 

Change Mode of Operation -> 가장 문제가 많이 터지는 원인

수행과정이 길기 때문에 OOO랑 더불어서 진행된다면 Spectre같은 문제가 생길 수 있다.

Foreshadowing 보안 취약점 (L1TF)

 

RSP/RBP 를 저장해서 추후 복구할 때 사용할 수 있도록 한다.

application level에서 function call을 할 때 일어나는 일들이 일어난다.

 

EEXIT

TLB entry를 clear한다. access한 흔적을 지워서 side channel attack이 일어나는 것을 방지한다.

 

handling exception

기본적인 방법은 일반적인 프로그램에서 exception을 처리하는 것과 같으나, enclave 내에서 쓰던 data가 유출되는 것을 방지하기 위해 exception frame 역할을 하는 SSA 프레임이 EPC 내부에 위치하게 된다.

 

또한 어디에서 문제가 일어났는지가 유출되는 것을 막아야 한다. 그래서 exception handler를 부르기 전에 반환될 주소를 스택에 넣고 trampoline area로 우선적으로 뛴 다음에 exception handler로 진행한다. exception이 처리된 후에는 IRET으로 trampoline area로 control이 반환될 것이다. 그 후에는 ERESUME을 통해 다시 enclave 영역으로 진입한다.

 

EPC page swapping

DRAM에 저장된 내용은 전부 seal되어 있고, EPC 영역이 부족해지면 시스템 메모리로 swap out하게 된다.

 

---

Security Analysis

 

- physical attack에 대해서는 크게 신경쓰지 않는 모습이다. (power attack, bus tapping)

그러나 circuitry의 복잡성으로 인해 내부 구조를 스캔해도 알아내기는 쉽지 않다.

어디를 access 하는지 pattern은 알 수 있으나 이를 이용해서 뭔가를 하기에는 부족한 느낌

 

Privileged Software attack

이것이 SGX의 존재의의이다. 그러나 몇가지 문제가 있다.

 

데이터의 종착점은 결국 레지스터이다.

레지스터를 clear하는 것은 주체가 불명확하다. 결국 유저가 신경써서 clear하게 할 수 밖에 없는데, 이마저도 compiler가 담당해주지 않으면 안된다.

때문에 모드 변환시 register로 인해 유출이 될 수 있다는 우려가 있다.

 

hyperthreading-based monitoring에 대한 대처가 불분명하다.

enclave 내에서 무슨 짓을 하는지 정확히 알기는 어려워도 대략적으로는 알 수 있다.

 

Address Translation Attack

EPCM이 VA -> PA 매핑을 기억하고 있고 TLB가 enclave 출입시에 계속 flush 되어 공격을 방지한다.

어느 페이지를 건들이다가 fault가 났는지도 유출하기 싫어서 최하위 12bit는 clear한다.

 

cache timing attack -> 방어하는데 전혀 도와주지 않는다.