본문 바로가기

Programming

Intel SGX basics

MIT 의 "SGX explained" 문서를 토대로 아주 기초적인 SGX 핵심원리만 정리해보았다.



1. SGX 무결성 검증이 이루어지는 원리는 다음과 같다: SGX 앱 개발자는, 먼저 자신의 private key 로 앱의 hash 를 서명한, 뒤, 자신의 public key 와 함께 앱을 배포한다.  SGX CPU 는 SGX 앱 실행을 위한 준비들을 모두 끝마친 뒤에 EINIT 명령어를 통해서 무결성을 검증하는데, 그 방법으로 enclave 의 각 EPC 페이지들에 대한 hash (ENCLAVEHASH) 를 계산하고, 그 hash 를 아래와같이 앱과함께 배포된 인증서 (public key 로 풀어서 볼수있는) 의 hash 와 동일한지 체크한다. 



Field

Bytes

Description

ENCLAVEHASH

32

Must equal the enclave’s measure- ment (§ 5.6).

ISVPRODID

32

Differentiates mod- ules signed by the same public key.

ISVSVN

32

Differentiates versions of the same module.

VENDOR

4

Differentiates Intel enclaves.

ATTRIBUTES

16

Constrains the enclave’s attributes.

ATTRIBUTEMASK

16

Constrains the enclave’s attributes.

Table19: A subset to the metadata fields in a SIGSTRUCT enclave certificate. 



하드웨어적으로 EINIT 을 거쳐야만, SGX 의 기능들이 동작한다는게 보장된다면, 결국 private key 를 가진 개발자가 아닌이상, 앱을 변조하는것은 불가능하다. (앱을 수정하면 public key 로 사이닝된 hash 의 서명이 불일치할 것이고, public key 로 사이닝된 hash 서명은 private key 가 없는이상 변경할수 없으므로). 그렇다면 public key 가 신뢰할수 있는 개발자의 것이라는 인증서는 어떻게 처리되는가? OS 가 보장해주나? 하지만 SGX 모델에선 OS 를 믿을수없는데...? 이부분은 아직 의문이다.

아, 이건 일단 OS 의 의존없이 CPU 적 기능만으로 enclave 가 변조되지 않고 실행되는거까지만 보장을 해주고, 이 sgx 앱의 개발자가 믿을수있는사람인가? 하는 부분은 enclave 의 실행애서는 검증하지 않는다.  이 검증(개발자가 intel 로부터 인정된 개발자인가?) 은 remote attestation 과정을 통해서 확인한다.



2. 무결성이 보장되는 상태로 SGX 앱이 EPC 메모리에 올라가서 실행된다고 가정하자.  이때 OS 가 EPC 메모리를 건드리지 못하는 원리는 다음과 같다: 일단 CPU 가 enclave 모드에 진입하지 않는이상 EPC 메모리는 PRM(processor reserved memory) 영역에 존재하기때문에 MMU 로 접근이 불가능하며, 하드웨어적으로 접근이 차단된다.  enclave 모드 진입은 EENTER 명령어로 이루어지고 EEXIT 명령어로 빠져나오게된다.  이 명령어들은 CPL 이 3 인경우에만 사용가능하다.


그럼 enclave A 의 코드가 enclave B 의 EPC 를 접근하지 못하게 하는건 어떻게되는가?:

하드웨어 구성요소중 PMH (page miss handler) 가 이를 처리한다. 최초의 메모리 접근시 TLB miss 가 반드시 나게되면서 PMH 가 동작하게 되는데, 이때 PMH 는 CPU 가 enclave 모드인경우, 접근하려는 물리주소에 대해서 EPCM 이라는 자료구조를 확인해 현재 CPU 의 enclave 모드 ID 가 access 하려는 EPC 페이지에 권한이 있는지를 확인한다.  EPCM 은 PRM 메모리영역에 여러개가있고, 하나의 EPCM 은 하나의 EPC 마다 각각 매핑되어있다.  EPCM 에는 SECS 라는 자료구조의 물리주소가 적혀있는데, SECS 자료구조는 enclave 를 고유하게 구별해줄수 있다.  현재 실행중인 enclave 의 SECS 자료구조에 대한 물리주소가 SGX CPU 레지스터에 저장되어있어서 (EENTER 로 enclave 모드 진입시 저장되는듯), CPU 는 이 레지스터상에 있는 SECS 값과, 접근하고자 하는 EPC 페이지에 해당하는 EPCM 에 명시된 SECS 값을 대조하여 enclave 코드가 접근하고자 하는 EPC 에 접근해도 되는지를 결정한다.


Conceptually, SGX adds the access control logic il- lustrated in Figure 86 to the PMH. SGX’s security checks are performed after the page table attributes-based checks (§ 2.5.3)

...
When the processor is inside enclave mode, the PMH performs the checks described below, which provide the security guarantees described in § 5.2.3


또한 DMA 는 아래와같이 하드웨어적으로 차단한다.


The SDM states that DMA transactions (§ 2.9.1) that target the PRM range are aborted by the processor. The SGX patents disclose that the PRMRR protection against unauthorized DMA is implemented by having the SGX microcode set up entries in the Source Address De- coder (SAD) in the uncore CBoxes and in the Target Address Decoder (TAD) in the integrated Memory Con- troller (MC). 





남은 의문점.


 SGX 앱에 무결성뿐만아니라 기밀성을 보장하고싶은 데이터나 코드가 있는경우, 이러한 데이터는 file system level 에서도 암호화를 해야한다.  이때 개발자가 암호화에 사용하는 algorithm과 key 는 자신이 개인적으로 직접 선택하고... 복호화를 위한 코드는 누구나 볼수있는 enclave 의 코드로서 만들어둔다.  enclave 가 실행되면, 복호화코드(변조는 못하지만 누구나 이 코드는 볼수있다) 가 실행되면서 remote attestation 을 통해 복호화에 필요한 key 를 네트워크로부터 받아오고, 이후 복호화하여 비밀로직을 실행한다.  여기서 왜 복호화코드를 네트워크로부터 받아오는일을 OS 가 보고 따라할수가 없는가??


이 이유는, 사전에 CPU 와 개발자간에 미리 private/public 키 배포가 끝나있는 상태이기때문에 MITM 이 불가능하기때문임.

MITM 은 일단 키쉐어링을 동적으로 하는 프로토콜에서 인증서를 무시할때 가능한건데, 이미 키쉐어링이 끝난상태이므로 EPC 메모리내부의 enclave 로직과 remote attestation 을 수행한 intel 개발자가 아닌이상 알수없음.


문제는 remote attestation 의 과정이 하드웨어적으로 이미 하드코딩된 1:N 형태의 private key (1개의 public key 로 N 개의 private key 와 암복호화가 가능한 모델) 가 박힌 intel cpu 가 배포된 상태에서, intel 로부터 인증받고 unique 한 public key 를 가진 개발자가 할수있다는것...? 이게 확실한지는 모르겠지만, 이게 맞다면, unique public key 가 유출한번만 되면 큰일이라는게...



그리고 provisioning 이라는게 있는데, 이건 특정 그룹의 CPU 에 대해서만 remote attestation 을 하는것이라고 보면됨.

SGX 모델에서 반드시 해야하는 일은 아님.




'Programming' 카테고리의 다른 글

OSX routing table setup  (0) 2016.08.06
ARM DACR basics  (0) 2016.07.13
Mount QEMU qcow image  (0) 2015.12.17
커널모듈 Cross Compile 주의사항  (0) 2015.12.09
RSA crap  (0) 2015.10.19