Confidential Computing이란

[0]

AWS나 Google Cloud Platform 등의 클라우드 컴퓨팅은 이미 굉장히 보편화되어 있다. 이런 서비스들은 보안 측면에서 본질적인 한계가 존재하는데, 바로 클라우드 제공사(아마존, 구글 등)들이 사용자들의 데이터를 볼 수 있다는 점이다. 따라서 이들을 신뢰할 수 없다면 당연히 민감한 데이터가 유출될 가능성을 생각할 수밖에 없으므로, 클라우드 컴퓨팅을 이용할 수 없다. 암호화를 사용하면 되는 것 아니냐라고 할 수 있겠지만, 암호화는 저장중/전송중인 데이터만 보호할 수 있다. 런타임에는 코드 건 데이터 건 반드시 메모리 상에 decrypt된 상태로 올라가야 하고, 클라우드 제공사들은 당연히 여기에 접근이 가능하다. 이에 대한 해결책으로 제시되는 것이 하드웨어적인 지원을 더한 confidential computing이다.

 

[1]

confidential computing은 trusted execution environment(TEE)를 제공한다. 하지만 모든 실행 영역을 TE

E에서 제공할 수 없으므로(하드웨어적인 제약도 있지만 이럴 경우 하이퍼바이저나 커널 등 코드의 모든 stack을 제공해야 한다!) 어플리케이션을 trusted code와 untrusted code로 나눈다. trusted code는 Enclave라고 불리는 독립된 실행 영역을 보장한다. Enclave는 하드웨어적으로 예약된 메모리를 제공받으며, 전용 명령어 셋을 사용하여 data encrption/decryption을 수행한다. 또한 untrusted code와 통신하기 위한 Encalve call / user call이 제공되며, 역시 하드웨어 전용 명령어 셋으로 수행된다. 하드웨어 단에서 명령어를 제공하기 때문에, 소프트웨어적인 encrypt/decrypt보다 performance overhead가 훨씬 작게 된다. 물론 그럼에도 overhead가 상당하기 때문에, trusted code 영역을 최대한 줄이고자 하는 프로그래머의 노력이 필요하다. 

 

[2] 

Enclave 메모리 영역은 untrusted code에서 접근이 불가능하다. 설령 메모리를 물리적으로 직접 뜯어보더라도(cold boot attack) 암호화되어 있으므로 컨텐츠를 알아낼 수 없다. 여기에서 untrusted code에 대한 정의가 중요한데, 이는 Enclave를 제외한 모든 코드이다. 즉 privilege가 높은 OS나 hypervisor도 untrusted code로 취급되며, Enclave에 직접 접근이 불가능하다! OS 혹은 hypervisor에서 취약점이 발생하여 공격자가 마음껏 privilege를 획득할 수 있다고 하더라도, Enclave를 보호할 수 있다. 따라서 Enclave 코드 자체에 취약점이 존재하지 않는다면, Enclave의 security를 보장할 수 있다. 즉 공격자의 attack surface가 훨씬 줄어들게 되며, 개발자 입장에선 작은 trusted code만 신경 쓰면 되기 때문에 보안성이 훨씬 더 향상된다. (다만 최근에는 Enclave을 공격할 수 있는 side channel attack 논문들이 나와있긴 하다...)

 

물론 DDoS는 가능하긴 하지만 이건 의미가 없는게, rmsid 클라우드 제공사에서 서버를 꺼버리면 당연히 해당 클라우드 컴퓨팅 서비스도 모두 이용 불가능하기 때문이다. 이 부분에 대해 제공사를 신뢰하는 건 무슨 짓을 해도 불가피하다. 

 

 

 

[참고]

https://www.fortanix.com/blog/2019/07/why-are-enclaves-taking-over-security-world/

Why are Enclaves Taking Over the Security World? by Nishank Vaish | Fortanix Blog

https://www.computerweekly.com/blog/Open-Source-Insider/What-is-confidential-computing

What is confidential computing? - Open Source Insider