TrustMee: Self-Verifying Remote Attestation Evidence

"TrustMee: Self-Verifying Remote Attestation Evidence" 논문에 대한 상세한 기술 요약입니다.

1. 문제 제기

원격 증명 (Remote Attestation) 은 기밀 가상 머신 (cVM) 과 신뢰 실행 환경 (TEE) 에서 신뢰를 확립하는 데 필수적입니다. 그러나 현재 검증 메커니즘은 다음과 같은 중대한 한계를 겪고 있습니다:

• 플랫폼별 복잡성: 검증자는 지원하는 모든 TEE(예: Intel SGX, Intel TDX, AMD SEV-SNP) 에 대해 하드웨어 특화 암호화 로직과 파싱 라이브러리를 구현해야 합니다.
• 증가된 신뢰 컴퓨팅 베이스 (TCB): 검증자는 인증서와 증명을 파싱하기 위해 메모리 안전하지 않은 언어 (OpenSSL 을 사용한 C/C++ 등) 로 작성된 네이티브 플러그인이나 드라이버에 의존합니다. 이는 버그와 취약점 (예: 원격 코드 실행) 을 검증자 자체에 도입합니다.
• 유지 관리 및 확장성: 새로운 TEE 를 지원하려면 검증자의 코드베이스를 업데이트하고, 재컴파일하며, 다시 배포해야 합니다. 이는 검증자가 보안 위험과 유지 관리 비용을 최소화하기 위해 더 적은 수의 플랫폼을 지원하도록 유도하는 '닭과 달걀' 문제를 야기합니다.
• 취약성: 하나의 TEE 에 대한 검증자 플러그인의 버그는 전체 검증 서비스를 침해할 수 있으며, 이는 공격자가 다른 플랫폼을 사칭할 가능성을 열어줍니다.

2. 방법론: TrustMee 아키텍처

저자들은 검증자에서 증명자로 플랫폼별 검증 로직의 부담을 전환하는 플랫폼 중립적 증명 검증기인 TrustMee를 제안합니다.

핵심 개념: 자기 검증 증명 (Self-Verifying Evidence)

검증 로직을 하드코딩하는 대신, 증명하는 TEE 는 해당 증명 형식을 파싱하고 유효성 검사하는 로직을 구현하는 WebAssembly (Wasm) 컴포넌트를 증명 데이터와 함께 번들링합니다.

• 증명자 (Attester): 표준 증명 데이터와 해당 증명 형식을 파싱 및 유효성 검사하는 로직을 구현하는 Wasm 컴포넌트를 생성합니다.
• 검증자 (TrustMee):
  1. 증명 데이터와 Wasm 컴포넌트를 수신합니다.
  2. Wasm 컴포넌트를 측정합니다 (신뢰 저장소와 대조하여 해시/서명을 확인).
  3. 샌드박싱된 WebAssembly 런타임(Wasmtime) 내부에서 컴포넌트를 실행합니다.
  4. 컴포넌트는 증명을 파싱하고, 승인서를 확인하며, 표준화된 일련의 주장 (claims) 을 출력합니다.
  5. TrustMee 호스트 (플랫폼 중립 코드) 는 이러한 주장에 평가 정책을 적용하고 결과를 표준 Entity Attestation Token (EAT) 형식으로 서명합니다.

주요 기술 구성 요소

• WebAssembly 컴포넌트 모델: 호스트와 컴포넌트 간의 엄격하고 언어 중립적인 인터페이스를 정의하기 위해 Wasm 인터페이스 타입 (WIT) 을 사용합니다. 이를 통해 TEE 에 관계없이 검증자는 일관된 API(evaluate 함수) 를 통해 컴포넌트와 상호작용합니다.
• 샌드박싱: Wasm 컴포넌트는 제한된 접근 권한을 가진 샌드박스 내에서 실행됩니다 (예: '연료 미터링'을 통한 제한된 CPU 사이클, 제어된 네트워크 접근, 격리된 파일 시스템). 이는 악의적이거나 버그가 있는 컴포넌트가 검증자를 충돌시키거나 민감한 호스트 데이터에 접근하는 것을 방지합니다.
• 신뢰 모델:
  • 검증자는 Wasm 런타임과 정책 엔진을 신뢰합니다.
  • 플랫폼별 로직은 신뢰할 수 없으나 격리되어 있습니다.
  • 검증자는 Wasm 컴포넌트의 서명자(일반적으로 TEE 벤더) 와 컴포넌트의 해시를 참조 값과 대조하여 확인합니다.
  • 컴포넌트가 서명되지 않았거나 알 수 없는 서명자인 경우, 엄격한 기본 정책 (네트워크 없음, 제한된 CPU) 하에 실행됩니다.

3. 주요 기여

1. TrustMee 아키텍처: 증명자가 검증 코드를 제공하는 자기 검증 원격 증명을 위한 새로운 설계. 이는 검증자가 플랫폼별 드라이버를 유지 관리할 필요성을 제거합니다.
2. 구현: Confidential Containers 프로젝트의 일부인 Trustee 프레임워크에 통합된 작동 프로토타입. AMD SEV-SNP, Intel TDX, Intel SGX에 대한 Wasm 검증 컴포넌트를 포함합니다.
3. 표준화: 시스템은 기존 의존 주체 (relying parties) 와의 호환성을 보장하는 표준 EAttestation Result (EAR) 형식으로 결과를 생성합니다.
4. 보안 분석: Wasm 내에서 플랫폼별 파싱 로직을 격리함으로써 검증자의 TCB 를 크게 줄이고 메모리 안전하지 않은 라이브러리와 관련된 위험을 완화함을 입증했습니다.
5. 성능 평가: 네이티브 드라이버 대비 Wasm 방식의 오버헤드를 정량화했습니다.

4. 결과 및 평가

저자들은 AMD SNP, Intel TDX, Intel SGX 에 대한 네이티브 Trustee 드라이버와 비교하여 TrustMee 를 평가했습니다.

• 호환성: 수정되지 않은 단일 검증자 호스트를 사용하여 세 가지 서로 다른 TEE 아키텍처의 증명을 성공적으로 검증했습니다. 새로운 TEE 를 추가하는 것은 이제 검증자를 업데이트하는 것이 아니라 새로운 Wasm 컴포넌트만 배포하면 됩니다.
• 보안:
  • Wasm 샌드박스는 파싱 및 암호화 작업을 성공적으로 격리합니다.
  • 악의적인 컴포넌트는 정책 엔진 (서명자/해시 확인을 통해) 에 의해 탐지되지 않는 한 검증자를 침해하거나 다른 플랫폼을 사칭할 수 없습니다.
  • 서비스 거부 (DoS) 공격은 연료 미터링 및 네트워크 제한을 통해 완화됩니다.
• 성능 (지연 시간):
  • 콜드 스타트: 컴포넌트 다운로드 및 컴파일을 포함한 초기 검증은 네트워크 및 컴파일 오버헤드로 인해 지연 시간이 더 깁니다.
  • 웜 스타트: 컴포넌트가 캐시되면 오버헤드는 관리 가능한 수준입니다.
    • AMD SNP: 현재 Wasm 런타임의 하드웨어 가속 암호화 부재로 인해 네이티브 Wasm 검증은 네이티브 C/Rust 드라이버보다 약 3.67 배 느렸습니다. 그러나 호스트 기반 암호화(Wasm 에서 네이티브 암호 함수 호출) 를 사용하면 이 오버헤드가 약 1.47 배로 감소했습니다.
    • Intel TDX/SGX: 순수 Rust 라이브러리 (dcap-qvl) 를 사용하는 Wasm 기반 검증기는 Intel 의 독점 DCAP 라이브러리를 사용하는 네이티브 Trustee 드라이버보다 실제로 더 빨랐습니다. dcap-qvl 을 사용하는 네이티브 드라이버와 비교했을 때 Wasm 오버헤드는 약 3.17 배였지만, 절대 지연 시간은 대부분의 경우 50ms 미만으로 낮았습니다.
  • 요청 크기: TrustMee 요청은 컴포넌트 식별자 크기를 상쇄하는 대신 base64 인코딩된 JSON 대신 CBOR 인코딩을 사용하므로 네이티브 요청보다 종종 더 작습니다(최대 37% 감소).

5. 중요성 및 미래 영향

• 검증과 하드웨어의 분리: TrustMee 는 검증자와 TEE 벤더 간의 긴밀한 결합을 끊습니다. 이는 클라우드 제공업체와 검증자가 코드 변경 없이 즉시 새로운 TEE 를 지원할 수 있게 합니다.
• 공격 표면 축소: 오류가 발생하기 쉬운 파싱 및 암호화 로직을 샌드박스로 이동함으로써 검증자의 TCB 를 핵심 로직과 Wasm 런타임으로 축소하여 원격 코드 실행 취약점의 위험을 크게 낮춥니다.
• 확장성: 이 모델은 유지 관리 부담을 검증자 운영자가 아닌 (이미 검증 라이브러리를 유지 관리하는) TEE 벤더로 전환합니다.
• 확장성: 아키텍처는 컴포지트 증명(하드웨어 레이어 위의 애플리케이션 레이어 검증) 을 지원하며 Veraison 과 같은 다른 프레임워크에도 적용할 수 있습니다.

결론: TrustMee 는 보안이나 성능을 희생하지 않고 원격 증명을 플랫폼 중립적으로 만들 수 있음을 보여줍니다. WebAssembly 를 활용하여 검증 로직을 증명 데이터와 번들링함으로써, 현재 이종 TEE 생태계의 통합 및 유지 관리 병목 현상을 해결합니다.