원격 증명 개요

원격 증명은 컨피덴셜 VM 인스턴스의 ID가 합법적이고 예상된 상태로 작동하는지 확인하는 프로세스입니다. 증명을 사용하면 보호된 리소스에 대한 액세스 권한을 부여하기 전에 시스템의 신뢰성을 평가할 수 있습니다.

증명 당사자 및 모델

증명 프로세스에는 일반적으로 세 당사자가 있습니다.

• 증명자 Google Cloud에서 이는 보호된 리소스에 대한 액세스가 필요한 컨피덴셜 VM 인스턴스의 워크로드입니다. 컨피덴셜 VM 인스턴스가 손상되지 않았으며 사기꾼이 아님을 신뢰할 수 있도록 VM과 호스트는 부팅 프로세스 중에 VM의 가상 하드웨어 및 소프트웨어 상태를 측정합니다.

• 인증자 검증자는 컨피덴셜 VM 인스턴스의 증거를 검증하고 증명 정책에 따라 확인하여 VM 구성이 예상대로인지 확인하는 외부 시스템입니다. 증거가 필수 검사를 통과하면 인증서 검증 도구는 증명 결과라고 하는 서명된 증거 버전을 반환합니다.

  검증자는 Google Cloud 증명 또는 Intel Trust Authority와 같은 기존 서비스이거나 직접 빌드한 것일 수 있습니다.

• 신뢰 당사자 신뢰 당사자는 증명자가 필요로 하는 보호된 리소스에 대한 액세스를 제어합니다. 증명 결과를 수신하면 신뢰 당사자는 증거의 값을 액세스 정책과 비교하여 확인합니다. 값이 일치하면 증명자가 리소스에 액세스할 수 있습니다.

  신뢰 당사자는 Google Cloud OpenID Connect (OIDC) 제공업체로 추가된 검증 도구와 함께 워크로드 아이덴티티 풀인 경우가 많습니다.

당사자가 상호작용하는 방식은 아키텍처가 따르는 증명 모델에 따라 다릅니다. 원격 증명 절차 (RATS) 아키텍처 RFC에서는 여권 모델과 신원 조회 모델이라는 두 가지 주요 증명 모델을 정의합니다. 두 경우의 주요 차이점은 증명자의 확인된 신원을 보유한 당사자가 증명자인지 아니면 신뢰 당사자인지입니다.

여권 모델

여권 모델은 다음 프로세스를 사용하여 증명자의 신원을 확인하고 요청된 리소스에 대한 액세스 권한을 부여합니다.

1. 증명자는 신원 증거를 확인자에게 전송합니다.

2. 증거가 신뢰할 수 있는 것으로 간주되면 인증서 검증 도구는 증명자에게 증명 결과를 전송합니다. 증명 결과는 증명 토큰의 형태를 취할 수 있습니다.

3. 증명자는 증명 결과를 신뢰 당사자에게 전송합니다.

4. 신뢰 당사자는 증명 결과가 특정 조건을 충족하는지 확인합니다. 결과가 기대치를 충족하면 신뢰 당사자는 증명자가 요청된 리소스에 액세스하도록 허용합니다.

여권 모델에서 증명자와 신뢰 당사자는 증명 결과가 어떤 모습이어야 하는지에 동의해야 합니다. 즉, 검증자에 동의해야 합니다.

백그라운드 확인 모델

신원 조회 모델은 다음 프로세스를 사용하여 증명자의 신원을 확인하고 요청된 리소스에 대한 액세스 권한을 부여합니다.

1. 증명자는 신원 증거를 신뢰 당사자에게 전송합니다.

2. 신뢰 당사자는 증거를 확인자에게 전달합니다.

3. 증거가 신뢰할 수 있는 것으로 간주되면 검증 도구는 증명 결과를 신뢰 당사자에게 전송합니다(증명 토큰으로 전송되는 경우가 많음).

4. 신뢰 당사자는 증명 결과가 특정 조건을 충족하는지 확인합니다. 결과가 기대치를 충족하면 신뢰 당사자는 증명자가 요청된 리소스에 액세스하도록 허용합니다.

신원 조회 모델을 사용하면 신뢰 당사자가 필요한 증명 증거를 결정하고 인증 기관을 선택합니다.

증명자 아키텍처 및 증거

이 섹션에서는 증명자로서 컨피덴셜 VM 인스턴스가 ID의 변조 방지 증거를 제공하는 방법을 설명합니다.

신뢰할 수 있는 루트

컨피덴셜 VM 인스턴스와 같은 신뢰할 수 있는 실행 환경 (TEE)에서 신뢰할 수 있는 루트는 다른 신뢰가 설정되는 기본 보안 구성요소입니다. 신뢰할 수 있는 루트는 암호화 기능을 제공하고 변조 방지 기능이 있으며 호스트 운영체제에서 수정할 수 없습니다.

신뢰할 수 있는 루트는 신뢰할 수 있는 컴퓨팅 기반 (TCB)이라고 하는 TEE 내의 신뢰 경계에 속합니다. TCB는 게스트 VM과 호스트 전반의 하드웨어 및 소프트웨어 모음으로, 환경 격리 (메모리 암호화 및 하이퍼바이저 격리와 같은 메커니즘을 통해) 및 환경의 무결성을 유지하기 위한 측정과 같은 작업을 담당합니다.

TEE는 측정, 저장, 보고 기능의 신뢰할 수 있는 루트를 지원합니다.

• 측정을 위한 신뢰할 수 있는 루트는 TEE 부팅 프로세스의 측정을 시작하는 코드입니다.

• 스토리지의 신뢰할 수 있는 루트는 측정 레지스터 형식으로 측정용 차폐 메모리를 제공합니다.

• 보고를 위한 신뢰할 수 있는 루트는 측정 체인의 무결성과 신뢰성 보호를 제공합니다. 저장소의 신뢰할 수 있는 루트에서 측정을 가져와 인용 또는 증명 보고서라고 하는 서명된 증거 패키지로 번들링합니다. 이 패키지는 TEE 상주 증명 키로 서명되며 증거가 최신 상태이고 재생 공격으로부터 보호되도록 암호화 nonce를 포함할 수 있습니다.

  핵심 용어: 리플레이 공격은 악의적인 행위자가 ID를 확인하는 증거를 복사하고 해당 증거를 사용하여 리소스에 불법적으로 액세스하는 경우입니다. 재생 공격에 대처하는 한 가지 방법은 일회용 번호를 사용하는 것입니다. 일회용 번호는 리소스를 보호하는 당사자 중 하나(기밀 컴퓨팅의 경우 확인자)가 제공하는 일회성, 단기, 무작위 번호입니다. ID를 증명하는 엔티티는 증거를 보내기 전에 증거에 nonce를 통합해야 합니다. 악의적인 행위자가 도난된 증거를 사용하여 리소스에 액세스하려고 하면 증거에 포함된 nonce가 이미 사용되었거나 만료되었기 때문에 실패할 가능성이 높습니다.

다음 정보에서는 다양한 컨피덴셜 컴퓨팅 기술의 신뢰할 수 있는 루트에 대한 다양한 접근 방식을 자세히 설명합니다.

AMD SEV

AMD SEV가 적용된 컨피덴셜 VM 인스턴스는 보안 VM vTPM 기반 측정을 사용하여 환경과 구성을 증명합니다. AMD 보안 프로세서와 AMD SEV는 메모리 암호화에만 사용됩니다.

신뢰할 수 있는 루트는 다음과 같습니다.

• 측정을 위한 신뢰할 수 있는 루트: VM 인스턴스 펌웨어

• 스토리지의 신뢰할 수 있는 루트: 보안 VM vTPM

• 보고를 위한 신뢰할 수 있는 루트: 비공개 증명 키를 사용하여 증명 보고서에 서명하는 보안 VM vTPM

보안 VM vTPM의 어디에 측정값이 기록되는지 알아보려면 vTPM 플랫폼 구성 레지스터를 참고하세요.

AMD SEV-SNP

AMD SEV-SNP가 있는 컨피덴셜 VM 인스턴스는 주로 초기 실행 측정을 처리하는 AMD 보안 프로세서를 통해 환경과 구성을 증명합니다.

부트로더, 커널, 사용자 공간 측정의 경우 보안 VM vTPM 기반 측정을 사용할 수 있습니다.

신뢰할 수 있는 루트는 다음과 같습니다.

• 측정을 위한 신뢰할 수 있는 루트: AMD 보안 프로세서 + VM 인스턴스 펌웨어

• 스토리지 신뢰할 수 있는 루트: AMD 보안 프로세서 + 보안 VM vTPM

• 보고를 위한 신뢰할 수 있는 루트:

  • 초기 출시 측정: 칩 상주 버전 칩 보증 키 (VCEK)를 사용하여 증명 보고서에 서명하는 AMD 보안 프로세서

  • 부트로더, 커널, 사용자 공간 측정: 보안 VM vTPM

AMD 보안 프로세서에 기록되는 측정값에 대해 알아보려면 AMD SEV-SNP 측정값 레지스터를 참고하세요.

보안 VM vTPM의 어디에 측정값이 기록되는지 알아보려면 vTPM 플랫폼 구성 레지스터를 참고하세요.

Intel TDX

Intel TDX가 적용된 컨피덴셜 VM 인스턴스는 Intel TDX 모듈을 통해 환경과 구성을 증명합니다. Intel TDX 모듈은 격리된 신뢰 도메인 내에서 VM 게스트의 펌웨어를 측정하고 이러한 측정을 신뢰 도메인 측정 (MRTD)에 저장합니다. 부팅 체인의 후속 측정은 런타임 측정 레지스터 (RTMR)에 측정됩니다.

신뢰할 수 있는 루트는 다음과 같습니다.

• 측정을 위한 신뢰할 수 있는 루트: Intel TDX 모듈

• 스토리지용 신뢰할 수 있는 루트: 신뢰 도메인 측정 (MRTD) 및 런타임 측정 레지스터 (RTMR)

• 보고를 위한 신뢰의 루트: 증명 인용문을 서명하기 위한 증명 키를 생성하는 Intel TDX 모듈 내의 신뢰 도메인 인용 엔클레이브 (TDQE)

TDX 측정 레지스터의 어디에 어떤 측정이 기록되는지 알아보려면 Intel TDX 측정 레지스터를 참고하세요.

소프트웨어 및 하드웨어 증명

Google Cloud 의 컨피덴셜 컴퓨팅 기술은 신뢰할 수 있는 루트에 따라 소프트웨어 또는 하드웨어 증명으로 간주될 수 있습니다.

소프트웨어 증명은 신뢰 루트가 소프트웨어를 기반으로 한다는 의미입니다. 가상 펌웨어는 측정의 신뢰 루트이고 스토리지의 신뢰 루트는 보안 VM vTPM입니다. vTPM은 호스트의 하이퍼바이저에서 관리하고 펌웨어는 게스트 VM에서 관리합니다. On Google Cloud에서는 이러한 구성요소가 모두 Google에 의해 제어됩니다.

하드웨어 증명은 서비스 제공업체의 제어 외부에서 전용 하드웨어로 측정이 관리되고 보호됨을 의미합니다. 온 Google Cloud에서 이 하드웨어에는 AMD SEV-SNP용 AMD 보안 프로세서 (실행 측정 전용)와 Intel TDX용 Intel TDX 모듈이 포함됩니다.

하드웨어 증명은 측정 및 저장소의 신뢰 루트에서 서비스 제공업체의 하이퍼바이저를 삭제하고 전용 하드웨어에서 측정을 격리합니다. 악의적인 행위자가 호스트의 하이퍼바이저를 제어하더라도 전용 하드웨어의 레지스터를 수정할 수 없으므로 증명 보고서나 인용을 위조할 수 없습니다.

Google Cloud 에서 제공하는 컨피덴셜 컴퓨팅 기술은 다음과 같이 분류됩니다.

• AMD SEV: 소프트웨어 증명 가상 펌웨어는 자체적으로 측정하며 측정값은 보안 VM vTPM에 저장됩니다.

• AMD SEV-SNP: 하이브리드 하드웨어 및 소프트웨어 증명 가상 펌웨어 측정을 비롯한 실행 측정은 AMD 보안 프로세서에 의해 기록되고 저장되므로 하드웨어 증명됩니다. 부트로더, 커널, 사용자 공간 측정은 보안 VM vTPM에 저장되므로 소프트웨어 증명이 가능합니다. 하드웨어 증명 측정, 소프트웨어 증명 측정 또는 둘 다를 사용하도록 선택할 수 있습니다.

• Intel TDX: 하드웨어 증명 TDX 모듈은 가상 펌웨어를 측정하고 모든 측정값은 Intel TDX 모듈에 저장됩니다. 보안 VM vTPM은 여전히 시스템의 일부이지만 TPM 인터페이스가 필요한 소프트웨어를 실행하지 않는 한 TCB의 일부는 아닙니다.

측정 등록

컨피덴셜 VM의 신뢰할 수 있는 루트는 측정 등록기 (MR) 형식의 측정값을 위한 보안되고 조작 방지 스토리지를 제공합니다. 이러한 측정 레지스터의 이름은 사용 중인 컨피덴셜 컴퓨팅 기술에 따라 달라집니다.

• AMD SEV: 플랫폼 구성 등록 (PCR) 이러한 키는 보안 VM vTPM 내에 있습니다.

  차폐 VM vTPM은 동일한 측정값을 저장하지만 SHA-1, SHA-256, SHA-384와 같은 서로 다른 알고리즘으로 해싱된 PCR 3개를 사용합니다.

• AMD SEV-SNP: 실행 MEASUREMENT 레지스터입니다. 이는 AMD 보안 프로세서 내에 있습니다.

  보안 VM vTPM 내부의 PCR은 부트로더, 커널, 사용자 공간 측정값을 저장하는 데도 사용됩니다.

• Intel TDX: 빌드 시간 신뢰 도메인 측정 (MRTD) 및 런타임 측정 레지스터 (RTMR)입니다.

  TPM 인터페이스를 필요로 하는 소프트웨어의 경우 보안 VM vTPM PCR에서도 측정을 사용할 수 있습니다.

신뢰할 수 있는 루트만 레지스터 값을 변경할 수 있습니다. 측정 레지스터는 일반적으로 단일 암호화 다이제스트를 보유하며, 이는 단일 이벤트 또는 이벤트 집합을 나타냅니다.

VM의 출시 측정 또는 빌드 시간 측정과 같은 단일 이벤트의 경우 신뢰할 수 있는 루트는 일반적으로 레지스터에 직접 쓰고 TEE의 나머지 수명 동안 레지스터를 변경할 수 없게 만듭니다.

부팅 체인에서 나중에 로드되는 구성요소(예: 부트로더, 커널, 사용자 공간)는 여러 이벤트의 측정을 단일 레지스터에 기록할 수 있습니다. 이벤트 집합의 측정값을 저장하기 위해 측정 등록기는 기존 등록기 값을 새 이벤트 다이제스트와 연결하고 연결된 값을 해싱한 다음 결과 다이제스트를 저장하는 extend 명령어를 노출합니다. 이 프로세스는 다음 수식으로 나타낼 수 있습니다.

\(MR_{new}=hash(MR_{old}\;∥\;hash(measured\;data))\)

해시 함수는 단방향이므로 동일한 순서로 동일한 측정을 제공하지 않고 동일한 측정 등록 값의 복제는 어렵습니다. 이 속성은 VM 무결성을 확인하는 데 도움이 되지만 특정 측정 레지스터 값을 기반으로 정책을 설정하기는 어려울 수 있습니다. 이는 소프트웨어 또는 펌웨어 업데이트나 측정 순서 변경과 같은 측정 입력의 작은 변화로 인해 레지스터 값이 달라지기 때문입니다. 따라서 정책을 기반으로 하는 불안정한 기준이 될 수 있으며 유지관리 부담이 증가합니다. 측정 레지스터 값을 기반으로 정책을 설정해야 하는 경우 vTPM의 PCR 0 또는 PCR 7과 같이 더 안정적인 레지스터 값을 선택하세요.

팁: 측정 등록 값 대신 안정적인 개별 측정값을 기반으로 정책을 적용하려면 TCB에서 생성된 이벤트 로그를 사용하면 됩니다. 확인자는 먼저 이벤트 로그 재생을 실행하여 측정 레지스터에 대해 로그 무결성을 확인해야 하며, 확인이 완료되면 이벤트를 파싱하여 의미 있는 측정을 추출할 수 있습니다.

이벤트 로그

측정값이 측정 레지스터에 기록되거나 확장되면 하나 이상의 로그가 게스트 운영체제의 파일 시스템에 기록되어 발생하는 측정 이벤트를 기록합니다.

이러한 이벤트 로그는 다음과 같은 용도로 사용됩니다.

• 확인자는 시뮬레이션된 측정 레지스터를 사용하여 컨피덴셜 VM 인스턴스의 측정 프로세스를 단계별로 실행하기 위해 이벤트 로그를 재생할 수 있습니다. 확인자가 계산한 최종 다이제스트가 증명자가 보고한 최종 다이제스트와 일치하면 이벤트 로그와 컨피덴셜 VM 인스턴스의 부팅 프로세스가 모두 조작되지 않았다는 신뢰도가 높아질 수 있습니다.

• 리플레이 후 확인자는 이벤트 로그를 파싱하여 증거를 증명 정책과 비교할 수 있습니다. 확인자는 증명자가 보안 부팅을 사용 설정하거나 특정 컨피덴셜 컴퓨팅 기술을 사용하는 등의 특정 기준을 통과해야 성공적인 증명 결과가 반환되도록 요구할 수 있습니다.

이벤트 로그는 게스트 운영체제의 파일 시스템에 다음 위치에 저장됩니다.

컨피덴셜 컴퓨팅 기술	확인할 MR	로그 유형	이벤트 로그 재생을 위한 게스트 OS 경로
AMD SEV, AMD SEV-SNP, Intel TDX	vTPM 플랫폼 구성 등록 (PCR)	신뢰할 수 있는 컴퓨팅 그룹 (TCG) 이벤트 로그	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	컨피덴셜 컴퓨팅 이벤트 로그 (CCEL)	/sys/firmware/acpi/tables/data/CCEL

이벤트 로그 재생 및 파싱에 대해 자세히 알아보세요.

견적 및 증명 보고서

보고를 위한 신뢰할 수 있는 루트는 증명 키로 측정을 서명하여 측정 레지스터에 저장된 다이제스트의 무결성과 진위 보호를 제공합니다. 결과 바이너리 블롭은 vTPM의 경우 PCR 인용, AMD SEV-SNP의 경우 증명 보고서, Intel TDX의 경우 인용이라고 합니다.

바이너리 블롭의 내용은 컨피덴셜 컴퓨팅 기술마다 다릅니다.

• AMD SEV: 차폐 VM vTPM은 PCR 뱅크 (SHA-1, SHA-256 또는 SHA-384) 중 하나의 값을 읽고, 이러한 값을 숫자 순서로 연결한 다음, PCR 뱅크에 사용된 것과 동일한 해싱 알고리즘으로 결과를 해싱하여 요약 다이제스트를 생성합니다. 이 요약 다이제스트는 검증자가 제공한 선택적 nonce와 함께 TPMS_ATTEST 구조에 배치되고 vTPM의 비공개 증명 키로 서명되어 PCR 인용을 만듭니다.

  TPMS_ATTEST 구조에 관한 자세한 내용은 신뢰 플랫폼 모듈 라이브러리, 파트 2: 구조 (PDF)를 참고하세요.

• AMD SEV-SNP: AMD 보안 프로세서는 컨피덴셜 VM 인스턴스 UEFI가 실행되기 전에 수행된 초기 실행 측정을 기반으로 SHA-384 다이제스트를 생성합니다.

  이 다이제스트, 기타 VM 데이터, 검증자가 제공하는 선택적 nonce는 증명 보고서를 만들기 위해 AMD 보안 프로세서의 버전 칩 보증 키 (VCEK)로 서명된 ATTESTATION_REPORT 구조에 배치됩니다.

  ATTESTATION_REPORT 구조에 관한 자세한 내용은 SEV Secure Nested Paging Firmware ABI Specification (PDF)을 참고하세요.

• Intel TDX: TDX 모듈은 MRTD 및 RTMR 값, 기타 VM 데이터, 검증 도구에서 제공하는 선택적 nonce를 TDREPORT_STRUCT 구조에 배치합니다.

  견적을 만드는 것은 여러 단계로 이루어진 프로세스입니다. 먼저 CPU 내부의 프로비저닝 인증 인클레이브가 CPU에 융합된 암호화 보안 비밀에서 프로비저닝 인증 키 (PCK)를 파생시킵니다. 그런 다음 CPU 내부의 인용 엔클레이브가 프로비저닝 인증 키로 서명된 비공개 증명 키를 생성합니다. 그런 다음 TDREPORT_STRUCT에 비공개 증명 키로 서명하여 인용을 만듭니다.

  TDREPORT_STRUCT 구조에 관한 자세한 내용은 Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification (PDF)을 참고하세요.

추천

다양한 유형의 보증은 컨피덴셜 VM 인스턴스가 예상되는 하드웨어, vTPM, 펌웨어 구성에서 실행되고 있다는 증거로 사용됩니다.

인증서

X.509 v3 인증서는 호스트에서 정품 AMD 또는 Intel 하드웨어가 사용되고 있거나 컨피덴셜 VM 인스턴스에서 보안 VM vTPM을 사용하고 있다는 증거로 사용됩니다.

인증서 이름은 각 컨피덴셜 컴퓨팅 기술마다 다릅니다.

• AMD SEV: 증명 키 (AK) 인증서

• AMD SEV-SNP: 버전 칩 승인 키 (VCEK) 인증서

• Intel TDX: 프로비저닝 인증 키 (PCK) 인증서

AMD SEV의 경우 인증서가 보안 VM vTPM을 확인합니다. 호스트는 Google의 인증 기관 서버에 요청을 하고 컨피덴셜 VM 인스턴스의 vTPM 비휘발성 스토리지에 직접 인증서를 자동 프로비저닝합니다. 게스트는 go-tpm-tools과 같은 소프트웨어로 vTPM에서 요청하여 이 인증서를 개별적으로 가져올 수 있습니다.

AMD SEV-SNP 및 Intel TDX의 경우 호스트가 CPU에서 하드웨어 증거를 추출하여 Google 관리 캐시에 제공합니다. 이 캐시는 이전에 AMD 키 배포 서비스와 Intel 프로비저닝 인증서 서비스에서 가져온 인증서를 저장합니다. 하드웨어 증거를 성공적으로 제시하면 인증서가 호스트의 디스크에 캐시되고 게스트와 공유됩니다. 게스트는 이러한 인증서를 개별적으로 검색하여 go-sev-guest, go-tdx-guest과 같은 소프트웨어로 하드웨어를 검증할 수 있습니다.

인증서에는 다음 정보가 포함됩니다.

• 인증서 발급자 ID(AMD, Google 또는 Intel)입니다.

• PCR 인용 (vTPM), 증명 보고서 (SEV-SNP), 증명 인용 (Intel TDX)의 서명을 확인하는 공개 증명 키입니다.

• 하드웨어 증명만: 호스트의 펌웨어가 실행되는 하드웨어 마이크로코드 및 펌웨어 TCB 버전입니다.

• 하드웨어 증명만 해당: 인증서를 특정 물리적 프로세서에 바인딩하는 증거로, 프로세서의 비공개 키로 서명되었으며 유출될 수 없습니다. AMD SEV-SNP의 경우 이 증거는 플랫폼 ID입니다. Intel TDX의 경우 증거는 플랫폼 매니페스트입니다.

펌웨어

하드웨어 증명의 경우 펌웨어 실행 보증을 VM 인스턴스에서 직접 사용할 수 있거나 온라인으로 다운로드할 수 있습니다. 실행 보증은 컨피덴셜 VM 인스턴스의 가상 펌웨어가 조작되지 않았음을 확인하는 데 사용되는 서명된 바이너리 직렬화 프로토콜 버퍼입니다.

VM이 시작되면 AMD 보안 프로세서 또는 Intel TDX 모듈이 실행되기 전에 펌웨어 바이너리를 해싱합니다. 이 SHA-384 다이제스트는 AMD SEV-SNP의 경우 MEASUREMENT 필드에, Intel TDX의 경우 MRTD에 저장됩니다.

이 다이제스트를 사용하여 Google에서 출시 보증을 다운로드하고, gcetcbendorsement과 같은 도구로 서명이 Google에 연결되어 있는지 확인한 다음, 펌웨어 측정과 보증에 기록된 내용 간에 SHA-384 다이제스트가 일치하는지 확인할 수 있습니다.

펌웨어 확인 외에도 출시 보증의 특정 속성을 사용하여 최소 보안 버전 번호 (SVN), vCPU 수, 메모리 구성, UEFI의 가족 ID와 같은 액세스 정책을 적용할 수 있습니다.

자세한 내용은 컨피덴셜 VM 인스턴스의 펌웨어 확인을 참고하세요.

인증자 이벤트 로그 재생 및 파싱

증명자가 제공한 증거를 직접 확인하는 것 외에도 확인자는 증명자가 제공한 이벤트 로그를 재생하여 측정 레지스터 값에 대한 무결성을 확인할 수 있습니다.

이렇게 하기 위해 검증자는 증명 정책의 일부로 확인해야 하는 각 측정 레지스터의 시뮬레이션된 버전을 만듭니다. 그런 다음 이벤트 로그의 이벤트를 사용하여 시뮬레이션된 레지스터를 채웁니다. 시뮬레이션된 레지스터의 최종 값이 동등한 실제 측정 레지스터에 저장된 값과 일치하면 이벤트 로그와 컨피덴셜 VM 인스턴스의 부팅 프로세스가 모두 조작되지 않았다는 신뢰도가 높아집니다.

이러한 방식으로 로그가 확인되면 확인자나 신뢰 당사자가 정책을 기반으로 할 수 있는 개별 측정값을 파싱할 수 있습니다.

자체 이벤트 로그 재생 및 파싱 도구 빌드

이벤트 로그를 재생하고 파싱하는 자체 소프트웨어를 빌드할 수 있지만, 신뢰할 수 있는 컴퓨팅 그룹 및 컨피덴셜 컴퓨팅 이벤트 로그 형식의 EventType 취약점과 같은 일반적인 함정을 피하려면 go-eventlog과 같은 기존 소프트웨어를 사용하는 것이 좋습니다.

여전히 자체 리플레이 및 파싱 소프트웨어를 빌드하려는 경우 다음 vTPM 기반 예시가 초기 이해에 도움이 될 수 있습니다. 하지만 자체 컨피덴셜 VM 인스턴스에서 생성된 이벤트 로그를 기반으로 구현해야 합니다.

다음 예시에는 PCR 0으로 측정되는 Ubuntu 24.04 vTPM 이벤트 로그의 이벤트가 선택되어 있습니다. 이벤트 로그가 다음 명령어를 사용하여 tpm2_eventlog로 바이너리에서 ASCII로 변환되었습니다.

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

로그의 PCR 0 이벤트는 다음과 같습니다.

---
version: 1
events:
- EventNum: 0
  PCRIndex: 0
  EventType: EV_NO_ACTION
  Digest: "0000000000000000000000000000000000000000"
  EventSize: 41
  SpecID:
  - Signature: Spec ID Event03
    platformClass: 0
    specVersionMinor: 0
    specVersionMajor: 2
    specErrata: 0
    uintnSize: 2
    numberOfAlgorithms: 3
    Algorithms:
    - Algorithm[0]:
      algorithmId: sha1
      digestSize: 20
    - Algorithm[1]:
      algorithmId: sha256
      digestSize: 32
    - Algorithm[2]:
      algorithmId: sha384
      digestSize: 48
    vendorInfoSize: 0
- EventNum: 1
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 160
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e37000300000028000000468e85a27fa36a458c790c1fe48b65ff4600690072006d007700610072006500520049004d0000000000000000000000000000000000"
- EventNum: 2
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 288
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e370001000000a800000068747470733a2f2f73746f726167652e676f6f676c65617069732e636f6d2f6763655f7463625f696e746567726974792f6f766d665f7836345f63736d2f3834383939616564336339653837363735666638303966356665613365366638383733353533643166303130306464623961653333323639323832356163636537333866343562646563323738613430393864316332376534393533373134332e66642e7369676e65640000000000000000000000000000"
- EventNum: 3
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "4031fe1129fb826f12dcad169992cca9f4f56aa3"
  - AlgorithmId: sha256
    Digest: "fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d"
  - AlgorithmId: sha384
    Digest: "21d340a4a30bb8865486d150cd9ceb46100662b92f336d38b87d70b373ca15c4c60878336924baa818dc2aceaeb40ea6"
  EventSize: 48
  Event: "47004300450020005600690072007400750061006c0020004600690072006d0077006100720065002000760032000000"
- EventNum: 4
  PCRIndex: 0
  EventType: EV_NONHOST_INFO
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "2b106cedd1631981619790bbc1afaa80cc6ecd3e"
  - AlgorithmId: sha256
    Digest: "6ac9241348a80c5755a63bcd1865b9f6d5720f6e925dc869bb4694281c1510c5"
  - AlgorithmId: sha384
    Digest: "1167e32c3814259ea4809234cccfbd2785c32bde882833bb199d6df6bd989a49f45663e63ce11699fcd01250050f042c"
  EventSize: 32
  Event: "474345204e6f6e486f7374496e666f0001000000000000000000000000000000"
- EventNum: 19
  PCRIndex: 0
  EventType: EV_SEPARATOR
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "9069ca78e7450a285173431b3e52c5c25299e473"
  - AlgorithmId: sha256
    Digest: "df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119"
  - AlgorithmId: sha384
    Digest: "394341b7182cd227c5c6b07ef8000cdfd86136c4292b8e576573ad7ed9ae41019f5818b4b971c9effc60e1ad9f1289f0"
  EventSize: 4
  Event: "00000000"

컨피덴셜 VM 인스턴스가 재설정되면 PCR이 0으로 초기화됩니다. 이벤트가 발생하면 PCR 0 (PCRIndex: 0)의 SHA-256 뱅크 값이 다음과 같이 변경됩니다 (EV_NO_ACTION 이벤트는 레지스터를 확장하지 않음).

1. 레지스터의 값은 PCR 0에 할당된 다음 이벤트의 SHA-256 다이제스트와 연결됩니다(EV_S_CRTM_VERSION). 연결된 결과는 SHA-256 해싱을 다시 거친 후 레지스터에 저장됩니다. PCR 0의 SHA-256 16진수 다이제스트가 이제 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365입니다.

2. EV_NONHOST_INFO 이벤트에도 동일한 프로세스가 사용됩니다. PCR 0의 SHA-256 16진수 다이제스트가 이제 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d입니다.

3. 특정 레지스터로의 측정 확장 프로그램이 완료되었음을 나타내는 EV_SEPARATOR 이벤트에도 동일한 프로세스가 사용됩니다. EV_SEPARATOR은 32비트 0 값 (\x00*4)입니다. 따라서 PCR 0의 최종 SHA-256 16진수 다이제스트는 a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85입니다.

다음 Python 코드는 시뮬레이션된 Compute Engine PCR 0을 만들어 이전 절차를 보여줍니다. 이 코드는 알려진 값에서 이벤트 다이제스트를 파생하므로 이벤트 로그 리플레이가 아닙니다. 적절한 이벤트 로그 리플레이를 만들 때는 VM 인스턴스의 이벤트 로그에서 다이제스트를 읽어야 합니다.

import hashlib

def CalculatePCR0(version_num: int, mem_encrypt_enum: int):
  """Calculates the expected SHA-256 PCR 0 value given the
  Compute Engine firmware version and Confidential Computing technology
  that's in use.

  This code uses derived values for events instead of reading digests from an
  event log. It's intended to demonstrate how to simulate the extend function
  used in measurement registers.

  While the code should provide correct values for PCR 0 in
  Compute Engine VM instances, for other PCRs and true event log replay
  you should read in digests from an event log instead of using derived values.

  PCR 0 measurements include:
    * EV_S_CRTM_VERSION: The firmware version string, in UTF-16 little-endian
      form. This value remains stable as long as the firmware version stays the
      same.
    * EV_NONHOST_INFO: This value changes based on the Confidential Computing
      technology that's in use.
    * EV_SEPARATOR: A 32-bit zero value to split UEFI and bootloader
      measurements.

  Args:
    version_num (int): The Compute Engine firmware version number. The
      value is 2.

    mem_encrypt_enum (int): The type of Confidential Computing technology used
      on the VM:

      0: None
      1: AMD SEV
      2: AMD SEV-ES
      3: Intel TDX
      4: AMD SEV-SNP

  Returns:
    A hexstring representing the expected PCR 0 digest.
  """
  # Create a hash object to act as PCR 0, and initialize it with zeroes.
  h = hashlib.sha256()
  h.update(b'\x00' * h.digest_size)

  # Update the hash object with the EV_S_CRTM_VERSION event, with a hard-coded
  # firmware version `version_num`.
  #
  # This code uses derived values for events. To use the digest supplied in an
  # event log for event log replay, you need to read in the event digest, and
  # then convert it to bytes before updating the hash object, similar to the
  # following:
  #
  # h.update(bytes.fromhex('fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d'))
  #
  h.update(
          hashlib.sha256(
              # The firmware uses UCS-2 encoding, so we match it by encoding to
              # the equivalent UTF-16 little-endian. An extra null byte is
              # needed to match the required byte length.
              f'GCE Virtual Firmware v{version_num}\x00'.encode('utf-16-le')).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h2 = hashlib.sha256()

  h2.update(h.digest())

  # Update the hash object with the EV_NONHOST_INFO event, which includes
  # `mem_encrypt_enum`, the Confidential Computing technology in use. Performing
  # this update completes the simulated EXTEND function.

  h2.update(
          hashlib.sha256(
              b'GCE NonHostInfo\x00'
              + (mem_encrypt_enum).to_bytes(1, byteorder='little')
              + (b'\x00' * 15)
              ).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h3 = hashlib.sha256()
  h3.update(h2.digest())

  # Update the hash object with the EV_SEPARATOR event. Performing this update
  # completes the simulated EXTEND function.
  h3.update(hashlib.sha256(b'\x00' * 4).digest())

  # There are more PCR 0 events, but they're all `EV_NO_ACTION` and don't
  # affect the register value. Return the final simulated register value.
  digest = h3.hexdigest()
  return digest

print('\nPCR 0 simulation')
print('\nConfidential Computing type\tDigest')
# Compute Engine firmware version 2, no Confidential Computing
# Expected hexdigest: d0c70a9310cd0b55767084333022ce53f42befbb69c059ee6c0a32766f160783
print(f'None\t\t\t\t{CalculatePCR0(2, 0)}')

# Compute Engine firmware version 2, AMD SEV
# Expected hexdigest: a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85
print(f'AMD SEV\t\t\t\t{CalculatePCR0(2, 1)}')

# Compute Engine firmware version 2, AMD SEV-SNP
# Expected hexdigest: 50597a27846e91d025eef597abbc89f72bff9af849094db97b0684d8bc4c515e
print(f'AMD SEV-SNP\t\t\t{CalculatePCR0(2, 4)}')

# Compute Engine firmware version 2, Intel TDX
# Expected hexdigest: 0cca9ec161b09288802e5a112255d21340ed5b797f5fe29cecccfd8f67b9f802
print(f'Intel TDX\t\t\t{CalculatePCR0(2, 3)}')

print()

신뢰 당사자 구성

여권 모델 또는 신원 조회 모델이 사용되는지에 따라 신뢰 당사자는 증명자 또는 검증자로부터 증명 결과를 수신합니다.

그런 다음 신뢰 당사자는 증명 결과에서 수신한 클레임이 예상 값과 일치하는지 확인합니다. 값이 일치하면 신뢰 당사자는 증명자가 로컬 ID로 리소스에 액세스하도록 허용합니다.

Google Cloud 에서 신뢰 당사자를 구성하는 일반적인 패턴은 워크로드 아이덴티티 제휴를 사용하고 증명자를 제휴 ID로 취급하는 것입니다.

1. 확인자를 워크로드 아이덴티티 풀에 OIDC 제공업체로 추가합니다. 이렇게 하면 컨피덴셜 VM 인스턴스 워크로드에 연결된 서비스 계정이 제휴 ID로 작동하여 필요한 리소스에 액세스할 수 있습니다.

2. 증명자가 리소스에 대한 액세스 권한을 부여받기 위해 증명자 증명에서 일치해야 하는 값을 정의합니다.

   Google Cloud에서 이는 ID 및 액세스 관리 (IAM)가 제휴 ID가 주체로 인증되기 위해 통과해야 하는 조건으로 처리할 수 있도록 증명 클레임을 속성에 매핑하는 것을 의미합니다.

   그런 다음 필요한 리소스의 허용 정책에 제휴 주 구성원의 역할 바인딩을 추가하여 증명자에게 리소스에 대한 직접 액세스 권한을 부여할 수 있습니다. 제휴 ID를 지원하지 않는 서비스의 경우 서비스 계정 명의 도용을 통해 리소스에 대한 액세스 권한을 제공할 수 있습니다.

워크로드 아이덴티티 제휴 대신 코드를 작성하여 증명 토큰의 클레임을 직접 파싱할 수 있습니다. 예를 보려면 컨피덴셜 가상 머신의 vTPM 원격 증명을 참고하세요.