고정 헤더 영역
상세 컨텐츠
본문
해당 포스터는 Redhat의 Security blog와 송도경 교수님의 컴퓨터과학입문 강의를 참고해서 적었다.
최근 많은 서비스들이 Cloud 서비스를 통해서 운영이 된다. 다만 AWS와 같이 외부적으로 지원하는 클라우드 서비스들은 보안 측면에서 본질적인 한계가 존재하는데, 바로 클라우드 제공사들이 사용자들의 데이터를 볼 수 있다는 점이다. 따라서 이들을 신뢰할 수 없다면 당연히 민감한 데이터가 유출될 가능성을 생각할 수밖에 없으므로, 클라우드 컴퓨팅을 이용할 수 없다. 암호화를 사용하면 되는 것 아니냐라고 할 수 있겠지만, 암호화는 저장 중인 데이터 (예: 디스크 암호화)와 전송 중인 데이터 (예: 네트워크 암호화)만 보호할 수 있다. 그러나 런타임에는 코드나 데이터나 메모리 상에 decrypt 된 상태로 올라가야 하고, 클라우드 제공사, 혹은 해당 권한을 얻는 attacker는 이러한 데이터에 접근이 가능하다. (예를 들어서 python runtime에 melicious 한 code가 injection 되어있는 경우가 있을 수 있다.) 이에 대한 해결책으로 제시되는 것이 하드웨어적인 지원을 더한 Confidential Computing이다.
- Confidential Computing 의 가장 기본적인 원리는 TCB를 아주 작게 설계한다. 대신 trust 할 수 있는 영역인 TEE(Trusted Execution Environment)만을 남기는 방식으로 구현을 한다.
- TCB에는 기본적으로 CPU vendor만 포함한다. 왜냐하면 Cloud Operator(혹은 Cloud Operator가 선택한 소프트웨어)를 신뢰할 수 없기 때문이다.
- 왜냐하면 Cloud Operator는 workload를 관리하면서 취약점이 발생할 수 있다. 한 가지 예시를 들자면 Cloud Operator는 workload를 관리하기 위해 해당 정보들을 볼 수 있는데 만약 그 정보가 private 하다면 문제가 발생할 수 있다.
- 그렇기 때문에 Cloud Operator의 관리는 TCB 외부에서 진행된다.
- Confidential Computing는 SW Configuration을 원격으로 verification하는 기능을 제공한다. 이를 Remote verification / Attestation이라고 한다.
- Cloud Operator나 각각의 task에 대해서 기본적으로 신뢰하지 않기에 만약 이를 이용하려면 sw가 내가 기대한대로 구성되었는지에 대한 여부를 원격으로, 그리고 암호화하여 확인할 수 있다.
- 예를 들어서 어떤 CPU가 있다고 했을 때, malicious people이 만약 fake CPU를 생성했을 수도 있다. 그런 상황에서 이런 기능을 통해서 이 CPU가 진짜 CPU인지 remotely verify 할 수 있다.
기존의 Cloud computing 방식하고 Confidential Cloud computing 비교
기존의 Cloud computing 방식은 TCB에 Cloud management software(ex : hypervisor)가 포함되어 있다. 반면에 Confidential Cloud computing의 경우에는 TCB를 minimize 하고, Cloud management software를 외부에서 관리하도록 한다.
이런 방식으로 설계한다면 TCB는 TEE(Trusted Execution Environment)를 구성할 수 있다. 가장 기본적으로는 Firmware와 HardWare로 구성되며, 그 위에는 윗 사진과 같이 kernel, library, runtime, program 등이 stack 형태로 쌓인다. 이때 CPU Chip을 통해서 이러한 것들을 검증하는 과정을 거치기 때문에 customer들은 해당 TCB를 fully trust 할 수 있는 환경이 조성된다. 이를 통해서 Untrusted cloud server에서 user는 TEE 환경을 통해서 원격으로 state와 configuration을 attest할 수 있다. 따라서 Remote attestation을 통해서 Cloud Operator나 외부 access에 대해서 검증을 하는 방식이 반드시 필요하다고 할 수 있다. 이 때 Remote attestation은 일반적으로 TEE state/configuration의 무결성을 증명하고 attestation report의 진위를 확인하는 것을 말한다.
(예시를 hypervisor로 든 이유는 새 모델에서 가장 확실한 공격 벡터 중 하나가 hypervisor이기 때문이다. malicious hypervisor는 상대적으로 쉽게 random data를 주입하거나 guest의 실행을 방해하여 timing attacks을 용이하게 하거나, supporting platform의 상태 및 기능에 대해 거짓말을 하여 필요한 완화를 억제할 수 있다. 특히 PCI 공간의 device register에 대한 access는 잘못된 데이터가 confidential data를 노출시키는 controlled guest crashes로 이어질 수 있기에 주의해야 한다.)
그렇다면 도대체 어떻게 Attestation을 하는 걸까?
가장 기본적인 해결책은 바로 one way hash function을 이용해서 root of trust로 시작하는 chain of trust를 구축하는 것이다.
- root of trust를 가장 먼저 measure 한다. 즉, 소프트웨어에 대한 자체 코드나 하드웨어에 대해 잘 알려진 version identifier를 통해 암호화 해시를 계산한다.
- 부팅할 코드의 다음 단계를 measure한다. 아래 그림에서는 rom based boot → bios phase 1→ … 순서대로이다.
- 이 작업이 완료되면 control이 boot ROM으로 전송되어 실행할 코드의 다음 단계를 찾아 measure 하는 작업이 수행된다.
여기서 원칙은 실행 전에 각 다음 단계가 이전 단계에 의해서 measure 된다는 것이다. 즉, 모든 해시가 trusted components로 구성된 경우 해시 체인이 root of trust에 기반을 두고 있기 때문에 전체 부팅 시퀀스를 신뢰할 수 있어야 한다. 이때 attacker는 가짜 코드를 삽입하거나 모든 단계(root 제외)에서 기존의 코드를 다른 코드로 대체하는 방식으로 공격을 할 수 있다. 그러나 이런 일이 발생하면 이전 단계의 measure는 잘못된 해시를 나타낸다.
이러한 일련의 과정들이 Attestation을 하는 방식의 한 형태이다. 이를 통해서 사용 중인 시스템에 대한 몇 가지 중요한 properties를 third party에게 증명한다.
여기에 제시된 모든 confidential computing platforms은 전체 chain of trust의 유효성을 확인하기 위해 암호화 방법을 사용하여 isolated, independent 한 physical root of trust라는 핵심 아이디어를 계승한다. 이러한 attestation 기법으로는 passport model과 the background check model 이 있다.
- passport model의 경우에는 Attester가 evidence를 Verifier에게 제공하면 Attestion result를 반환한다. 그 후 Relying party에 이를 제시하는 것으로 인증하는 모델이다.
- background check model의 경우에는 Attester가 Relying party에게 evidence를 제시하면 Relying party가 Verifier를 통해서 Attestation을 진행하는 과정을 거친다. 일반적으로 더 유용한 방식이다.
Attestation Flow
- attester는 attestation server로 요청을 보낸다.
- 서버는 replay attack을 피하기 위해 Cryptographic nonce를 포함하는 Challenge로 응답한다.
- attester는 아까 받은 challenge의 elements와 attester가 제공한 데이터를 combine 한 다음, hash 함수를 통해서 전자 서명을 한 evidence를 제출한다. 이러한 방식으로 결과는 제3자가 재현할 수 없고 challenge를 생성한 사람 이외에는 이 결과를 사용할 수 없다. 예를 들어 intel의 chip을 사용할 경우, 해당 chip에서 public key를 발급한 것을 통해서 decrypt 하는 방식으로 진행이 되는데, 이 경우에는 만약 attacker가 이것을 바꾸려고 시도를 한다고 하더라도 modify 된 것을 알아낼 수 있다. 따라서 man-in-the-middle attack을 막을 수 있다.
- (그림에서의 4~5) attestation server는 다양한 policy들을 적용하는 verifier가 포함되어 있다. 이를 통해서 evidence를 검증한다.
- 만약 attestation이 성공했다면, key broker service는 해당 attester에 대한 key를 release 하라고 지시한다.
- key는 verifier의 key broker client가 사용할 수 있는 request로 패키징 된다.
confidential computing은 어떤 것을 guarantee 할 수 있는가?
confidential computing이 보장하는 것은 confidentiality이다. confidentiality은 trusted domain 외부에서 데이터를 읽지 못하도록 보호하는 것이다. 다만 attacker가 trusted domain을 변조할 수 없도록 하려면 integrity protection도 필요하다는 것을 알 수 있다. 만약 trusted domain을 변조한다면, 신뢰할 수 있는 데이터가 손상될 뿐만 아니라 execution flow을 장악하여 데이터 유출이 발생할 수도 있다. 따라서 integrity protection까지 지켜져야만 confidential computing을 할 수 있다.
이를 위해서 hash함수를 이용한 전자 서명을 주로 사용한다. 그 후, private key를 통해서 dectypt하여 비교하는 방식을 통해서 integrity도 보장할 수 있다.
이러한 암호를 decryption 하는 방법은 대부분의 플랫폼에서 memory encryption key는 하드웨어에 존재하며, 이를 통해서 암호를 decryption 한다. 이를 추출하는 HW level에서 exploit 할 수 있는 방법을 찾는 것을 제외하고는 암호화된 메모리를 해독할 수 있는 실질적인 방법이 없다. 또한 이러한 방법을 통해 사람의 실수를 통해 key에 access 할 수 없다는 장점도 있다.
이렇게 될 경우 Public cloud server의 악의적인 시스템 관리자가 더 이상 가상 머신의 메모리를 dump 하여 암호가 처리되는 동안 이를 훔치려고 시도할 수 없음을 의미한다. Attacker가 만약 메모리를 dump하여 어떤 정보를 얻는다고 하더라도 얻을 수 있는 것은 기껏해야 암호의 암호화된 버전일 것이다.
+ ps: 그리고 많은 사람들이 Authentication과 Attestation을 착각하는데 정리하고 넘어가자면...
Authentication을 통해 Attestation’s result를 증명할 수 있다.
- 사용자 또는 장치가 누구인지 알 수 있다.
- ex) Intel에서 제조한 정품 칩과 대화 중임을 확인
Attestation은 integrity를 확인한다.
- device 또는 system의 state/configuration
- ex) 내 컨테이너의 state/configuration이 예상대로인지 확인한다.
