Descripción general de la certificación remota

La certificación remota es el proceso de verificar que la identidad de una instancia de Confidential VM sea legítima y que funcione en el estado esperado. La certificación puede ayudarte a evaluar la confiabilidad de un sistema antes de otorgarle acceso a tus recursos protegidos.

Partes y modelos de certificación

Por lo general, hay tres partes en el proceso de certificación:

• Un certificador. En Google Cloud, esta es una carga de trabajo en una instancia de Confidential VM que requiere acceso a recursos protegidos. Para aumentar la confianza en que la instancia de Confidential VM no se haya vulnerado y no sea un impostor, la VM y su host toman mediciones del estado del hardware y el software virtuales de la VM durante el proceso de inicio.

• Un verificador. Un verificador es un sistema externo que valida la evidencia de una instancia de Confidential VM y la compara con su política de certificación para asegurarse de que la configuración de la VM sea la esperada. Si la evidencia pasa las verificaciones requeridas, el verificador devuelve una versión firmada de la evidencia conocida como un resultado de certificación.

  Un verificador puede ser un servicio preexistente, como Google Cloud Attestation o Intel Trust Authority, o algo que hayas creado por tu cuenta.

• Una parte de confianza. La parte de confianza controla el acceso a los recursos protegidos que necesita el certificador. Cuando recibe un resultado de certificación, la parte de confianza compara los valores de la evidencia con su política de acceso. Si los valores coinciden, el certificador puede acceder a los recursos.

  En Google Cloud , la parte de confianza suele ser un grupo de identidades para cargas de trabajo, con el verificador agregado como proveedor de OpenID Connect (OIDC).

La forma en que interactúan las partes depende del modelo de certificación que siga tu arquitectura. El RFC de arquitectura de Remote ATtestation procedureS (RATS) define dos modelos de certificación remota principales: el modelo de pasaporte y el modelo de verificación de antecedentes. La diferencia principal entre ambos es qué parte tiene la posesión de la identidad verificada del certificador: el certificador o la parte de confianza.

Modelo de pasaporte

El modelo de pasaporte usa el siguiente proceso para confirmar la identidad de un certificador y otorgar acceso a los recursos solicitados:

1. El certificador envía evidencia de su identidad a un verificador.

2. Si la evidencia se considera confiable, el verificador envía al certificador el resultado de la certificación, que puede tomar la forma de un token de certificación.

3. El certificador envía el resultado de la certificación a una parte de confianza.

4. La parte de confianza verifica que el resultado de la certificación cumpla con ciertas condiciones. Si el resultado cumple con las expectativas, la parte de confianza permite que el certificador acceda a los recursos solicitados.

En el modelo de pasaporte, el certificador y la parte de confianza deben acordar cómo deben ser los resultados de la certificación, lo que significa que deben acordar un verificador.

Modelo de verificación de antecedentes

El modelo de verificación en segundo plano usa el siguiente proceso para confirmar la identidad de un certificador y otorgar acceso a los recursos solicitados:

1. El certificador envía evidencia de su identidad a un usuario de confianza.

2. La parte de confianza reenvía la evidencia a un verificador.

3. Si la evidencia se considera confiable, el verificador envía a la parte de confianza el resultado de la certificación, a menudo como un token de certificación.

4. La parte de confianza verifica que el resultado de la certificación cumpla con ciertas condiciones. Si el resultado cumple con las expectativas, la parte de confianza permite que el certificador acceda a los recursos solicitados.

Con el modelo de verificación en segundo plano, una parte de confianza determina la evidencia de certificación que requiere y elige el verificador.

Arquitectura y evidencia del certificador

En esta sección, se explica cómo una instancia de Confidential VM como certificador proporciona evidencia de su identidad a prueba de manipulaciones.

Raíces de confianza

En un entorno de ejecución confiable (TEE), como una instancia de Confidential VM, una raíz de confianza es un componente de seguridad fundamental a partir del cual se establece otra confianza. Una raíz de confianza proporciona funciones criptográficas, es resistente a la manipulación y no puede ser modificada por un sistema operativo host.

Las raíces de confianza pertenecen a un límite de confianza dentro de un TEE conocido como la base de computación confiable (TCB). La TCB es una colección de hardware y software en una VM de invitado y su host que se encargan de tareas como el aislamiento del entorno (a través de mecanismos como la encriptación de memoria y el aislamiento del hipervisor) y la toma de mediciones para mantener la integridad del entorno.

Un TEE admite raíces de confianza para las funciones de medición, almacenamiento y generación de informes:

• La raíz de confianza para la medición es el código que inicia las mediciones del proceso de inicio del TEE.

• La raíz de confianza para el almacenamiento proporciona memoria protegida para las mediciones en forma de registros de medición.

• La raíz de confianza para los informes proporciona protección de integridad y autenticidad para la cadena de medición. Recupera las mediciones de la raíz de confianza para el almacenamiento y las agrupa en un paquete de evidencia firmado llamado informe de cotización o certificación. Este paquete se firma con una clave de certificación residente en el TEE y puede incluir un nonce criptográfico para garantizar que la evidencia sea reciente y esté protegida contra ataques de repetición.

  Término clave: Un ataque de reproducción se produce cuando un agente malicioso copia evidencia que verifica una identidad y la usa para obtener acceso ilegítimo a recursos. Una forma de combatir los ataques de reproducción es con un nonce: un número aleatorio, único y de corta duración que proporciona una de las partes que protege los recursos, en el caso de Confidential Computing, el verificador. La entidad que demuestra su identidad debe incorporar el nonce en su evidencia antes de que se envíe esa evidencia. Si un agente malicioso intenta usar evidencia robada para acceder a los recursos, es probable que falle porque el nonce que se incluye en la evidencia ya se usó o venció.

En la siguiente información, se detallan los diferentes enfoques de las raíces de confianza para las distintas tecnologías de Confidential Computing.

AMD SEV

Una instancia de Confidential VM con AMD SEV certifica su entorno y configuración con mediciones basadas en vTPM de VM protegida. El procesador seguro de AMD y la SEV de AMD se usan solo para la encriptación de la memoria.

Las raíces de confianza son las siguientes:

• Raíz de confianza para la medición: firmware de la instancia de VM

• Raíz de confianza para el almacenamiento: vTPM de VM protegida

• Raíz de confianza para los informes: vTPM de VM protegida, que usa una clave de certificación privada para firmar informes de certificación

Para saber qué mediciones se registran en el vTPM de la VM protegida, consulta Registros de configuración de la plataforma de vTPM.

AMD SEV-SNP

Una instancia de Confidential VM con AMD SEV-SNP certifica principalmente su entorno y configuración a través del procesador seguro de AMD, que controla las mediciones de inicio iniciales.

Para las mediciones del bootloader, el kernel y el espacio del usuario, se pueden usar las mediciones basadas en el vTPM de la VM protegida.

Las raíces de confianza son las siguientes:

• Raíz de confianza para la medición: Procesador seguro de AMD + firmware de la instancia de VM

• Raíz de confianza para el almacenamiento: Procesador seguro de AMD + vTPM de VM protegida

• Raíz de confianza para la generación de informes:

  • Mediciones de inicio iniciales: El procesador seguro de AMD, que usa la clave de aprobación de chip de versión (VCEK) residente en el chip para firmar los informes de certificación

  • Mediciones del bootloader, el kernel y el espacio del usuario: vTPM de la VM protegida

Para conocer qué mediciones se registran en el procesador seguro de AMD, consulta Registro de mediciones de AMD SEV-SNP.

Para saber qué mediciones se registran en el vTPM de la VM protegida, consulta Registros de configuración de la plataforma de vTPM.

Intel TDX

Una instancia de Confidential VM con Intel TDX certifica su entorno y configuración a través del módulo de Intel TDX. El módulo Intel TDX mide el firmware del invitado de la VM dentro de un dominio de confianza aislado y almacena esas mediciones en la medición del dominio de confianza (MRTD). Las mediciones posteriores en la cadena de inicio se miden en los registros de medición del entorno de ejecución (RTMR).

Las raíces de confianza son las siguientes:

• Raíz de confianza para la medición: Módulo Intel TDX

• Raíz de confianza para el almacenamiento: Medición del dominio de confianza (MRTD) y registros de medición del tiempo de ejecución (RTMR)

• Raíz de confianza para los informes: El enclave de cotización de dominio de confianza (TDQE) dentro del módulo Intel TDX, que genera una clave de certificación para firmar las cotizaciones de certificación

Para saber qué mediciones se registran en los registros de medición de TDX, consulta Registros de medición de Intel TDX.

Raíces de confianza de hardware y software

Tu nivel de aislamiento del hipervisor del host depende de si la cadena de certificación está anclada en una raíz de confianza de software o en una raíz de confianza de hardware:

• Raíz de confianza de software (dependiente del hipervisor): La cadena de confianza comienza en el software que administra el proveedor de servicios en la nube. El firmware virtual del invitado actúa como la raíz de confianza para la medición, y el vTPM de la VM protegida del hipervisor del host actúa como la raíz de confianza para el almacenamiento y los informes. En Google Cloud, Google controla ambos componentes.

• Raíz de confianza de hardware (aislada del hipervisor): La cadena de confianza comienza en subsistemas de seguridad de CPU dedicados fuera del control de tu proveedor de servicios en la nube: el procesador seguro de AMD o el módulo Intel TDX. Este hardware mide el estado inicial y firma informes o cotizaciones de certificación con claves fusionadas o derivadas dentro del procesador. En la CPU, los componentes de software posteriores de la cadena de inicio (incluidos el firmware virtual y el bootloader) se ejecutan dentro de la memoria protegida por la encriptación de hardware y los controles de acceso. Esto quita el hipervisor del host de la raíz de confianza: incluso si un agente malicioso vulnera el hipervisor, no puede modificar las mediciones protegidas por hardware ni falsificar un informe de certificación.

Según la configuración de tu instancia de Confidential VM, se pueden usar uno o más de los siguientes mecanismos para medir y certificar su estado de inicio:

• vTPM de VM protegida (raíz de confianza de software): El vTPM de VM protegida es necesario para la certificación con SEV de AMD. Las instancias de Confidential VM de AMD SEV-SNP y de Intel TDX aún cuentan con el vTPM de VM protegida, pero usarlo como parte de tu cadena de confianza es opcional.

  El vTPM de la VM protegida registra las mediciones del bootloader, el kernel y el espacio de usuario en los PCR. Debido a que lo administra el hipervisor del host, mantiene el estado en los reinicios para funciones como el sellado de claves.

• Procesador seguro de AMD (raíz de confianza de hardware): Disponible en las instancias de Confidential VM con SEV-SNP de AMD. Antes de que se inicie el invitado, el procesador seguro de AMD mide el estado de inicio inicial (incluido el firmware virtual) en su registro MEASUREMENT y firma un ATTESTATION_REPORT con su VCEK.

  Puedes verificar el informe de certificación del procesador seguro de AMD por tu cuenta o combinarlo con una cotización de vTPM de VM protegida para verificar el resto de la cadena de inicio.

• Registros de medición de Intel TDX (raíz de confianza de hardware): Están disponibles en las instancias de Confidential VM de Intel TDX. El módulo Intel TDX registra las mediciones del firmware virtual en el momento de la compilación en la medición del dominio de confianza (MRTD) y extiende las mediciones del bootloader, el kernel y el espacio de usuario a los registros de medición del tiempo de ejecución (RTMR) dentro del dominio de confianza aislado, sin necesidad de un vTPM.

  Puedes verificar la cotización del módulo de Intel TDX por tu cuenta para abarcar toda la cadena de inicio. Un vTPM de VM protegida está presente en las instancias de Confidential VM de Intel TDX para usarlo en funciones de TPM, como el sellado de claves.

Registros de mediciones

Las raíces de confianza de Confidential VM proporcionan almacenamiento protegido y resistente a la manipulación para las mediciones en forma de registros de medición (MR). Los nombres de esos registros de medición cambian según la tecnología de Confidential Computing que se use:

• AMD SEV: Registros de configuración de la plataforma (PCR). Estas se encuentran dentro del vTPM de la VM protegida.

  Los vTPM de VM protegida usan tres bancos de PCR que almacenan las mismas mediciones, pero se les aplica un algoritmo de hash diferente: SHA-1, SHA-256 y SHA-384.

• AMD SEV-SNP: El registro de inicio MEASUREMENT. Este se encuentra dentro del procesador seguro de AMD.

  Los PCR dentro del vTPM de la VM protegida también se usan para almacenar las mediciones del bootloader, el kernel y el espacio de usuario.

• Intel TDX: La medición del dominio de confianza (MRTD) en el momento de la compilación y los registros de medición del tiempo de ejecución (RTMR).

  Las mediciones también están disponibles en los PCR de vTPM de la VM protegida para el software que espera una interfaz de TPM.

Solo una raíz de confianza puede cambiar un valor de registro. Los registros de medición suelen contener un solo resumen criptográfico, que representa un solo evento o un conjunto de eventos.

En el caso de eventos únicos, como la medición de inicio o la medición del tiempo de compilación de una VM, una raíz de confianza suele escribir directamente en el registro y lo hace inmutable durante el resto de la vida útil del TEE.

Los componentes que se cargan más adelante en la cadena de inicio, como el bootloader, el kernel y el espacio del usuario, pueden registrar mediciones de varios eventos en un solo registro. Para almacenar las mediciones de conjuntos de eventos, los registros de medición exponen un comando extend que concatena el valor de registro existente con un resumen de evento nuevo, genera un hash del valor concatenado y, luego, almacena el resumen resultante. Este proceso se representa con la siguiente fórmula:

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

Dado que las funciones hash son unidireccionales, es difícil replicar los mismos valores de registro de medición sin proporcionar las mismas mediciones en el mismo orden. Si bien esta propiedad ayuda a determinar la integridad de la VM, puede dificultar la creación de políticas basadas en valores de registro de medición específicos. Esto se debe a que los pequeños cambios en las entradas de medición, como las actualizaciones de software o firmware, o un cambio en el orden de medición, generan diferentes valores de registro, lo que hace que sean criterios potencialmente inestables en los que se basan las políticas y aumentan la carga de mantenimiento. Si necesitas basar la política en los valores de registro de medición, intenta seleccionar valores de registro más estables, como PCR 0 o PCR 7 en vTPM.

Sugerencia: Para basar la política en mediciones individuales estables en lugar de valores de registro de medición, puedes usar un registro de eventos que genere tu TCB. Primero, un verificador debe realizar una reproducción del registro de eventos para verificar la integridad del registro en relación con los registros de medición y, después de una verificación exitosa, puede analizar los eventos para extraer mediciones significativas.

Registros de eventos

A medida que las mediciones se escriben o se extienden en los registros de medición, se escriben uno o más registros en el sistema de archivos del sistema operativo invitado que registran los eventos de medición que se llevan a cabo.

Estos registros de eventos tienen los siguientes propósitos:

• Un verificador puede reproducir los registros de eventos para recorrer el proceso de medición de la instancia de Confidential VM con registros de medición simulados. Si los resúmenes finales calculados por el verificador coinciden con los resúmenes finales informados por el certificador, esto puede aumentar la confianza de que no se alteraron ni el registro de eventos ni el proceso de inicio de la instancia de Confidential VM.

• Después de la reproducción, un verificador puede analizar los registros de eventos para comparar la evidencia con las políticas de certificación. Un verificador puede requerir que un certificador cumpla con ciertos criterios, como tener habilitado el inicio seguro o usar una tecnología específica de Confidential Computing antes de que se devuelva un resultado de certificación correcto.

Los registros de eventos se almacenan en el sistema de archivos del sistema operativo invitado en las siguientes ubicaciones:

Tecnología de Confidential Computing	MRs to verify	Tipo de registro	Ruta de acceso del SO invitado para la reproducción del registro de eventos
AMD SEV, AMD SEV-SNP, Intel TDX	Registros de configuración de la plataforma (PCR) del vTPM	Registro de eventos del Trusted Computing Group (TCG)	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	Registro de eventos de Confidential Computing (CCEL)	/sys/firmware/acpi/tables/data/CCEL

Obtén más información sobre las reproducciones y el análisis de registros de eventos.

Informes de cotizaciones y certificaciones

La raíz de confianza para la generación de informes proporciona protección de integridad y autenticidad para los resúmenes almacenados en el registro de medición firmando sus mediciones con una clave de certificación. El BLOB binario resultante se conoce como una cotización de PCR para vTPM, un informe de certificación para SEV-SNP de AMD y una cotización para TDX de Intel.

El contenido del BLOB binario es diferente para las distintas tecnologías de Confidential Computing:

• AMD SEV: El vTPM de la VM protegida lee los valores de uno de sus bancos de PCR (SHA-1, SHA-256 o SHA-384), concatena esos valores en orden numérico y, luego, genera un hash del resultado con el mismo algoritmo de hash que se usa para el banco de PCR para crear un resumen. Este resumen, junto con un nonce opcional proporcionado por un verificador, se coloca en una estructura TPMS_ATTEST y se firma con la clave de certificación privada del vTPM para crear una cotización de PCR.

  Para obtener detalles sobre la estructura TPMS_ATTEST, consulta Biblioteca de módulos de plataforma de confianza, parte 2: Estructuras (PDF).

• SEV-SNP de AMD: El procesador seguro de AMD genera un resumen SHA-384, según sus mediciones de inicio iniciales tomadas antes de que se ejecute la UEFI de la instancia de Confidential VM.

  Este resumen, otros datos de la VM y un nonce opcional que proporciona un verificador se colocan en una estructura ATTESTATION_REPORT que está firmada por la clave de aprobación de chip de versión (VCEK) del procesador seguro de AMD para crear un informe de certificación.

  Para obtener detalles sobre la estructura ATTESTATION_REPORT, consulta Especificación de ABI del firmware de paginación anidada segura de SEV (PDF).

• Intel TDX: El módulo TDX coloca los valores de MRTD y RTMR, otros datos de la VM y un nonce opcional proporcionado por un verificador en una estructura TDREPORT_STRUCT.

  Crear una cotización es un proceso de varios pasos. Primero, el enclave de certificación de aprovisionamiento dentro de la CPU deriva una clave de certificación de aprovisionamiento (PCK) a partir de secretos criptográficos fusionados en la CPU. Luego, el enclave de cotización dentro de la CPU genera una clave de certificación privada, que se firma con la clave de certificación de aprovisionamiento. Luego, el TDREPORT_STRUCT se firma con la clave de certificación privada para crear una cotización.

  Para obtener detalles sobre la estructura de TDREPORT_STRUCT, consulta Especificación de la arquitectura base del módulo de Intel Trust Domain Extensions (Intel TDX) (PDF).

Recomendaciones

Se usan diferentes tipos de respaldos como evidencia de que una instancia de Confidential VM se ejecuta en el hardware, el vTPM y las configuraciones de firmware esperados.

Certificados

Los certificados X.509 v3 se usan como evidencia de que se usa hardware original de AMD o Intel en el host, o de que la instancia de Confidential VM usa un vTPM de VM protegida.

El nombre del certificado es diferente para cada una de las tecnologías de Confidential Computing:

• AMD SEV: Certificado de clave de certificación (AK)

• AMD SEV-SNP: Certificado de clave de aprobación de chip de versión (VCEK)

• Intel TDX: Certificado de clave de certificación de aprovisionamiento (PCK)

Para AMD SEV, el certificado verifica el vTPM de la VM protegida. El host realiza una solicitud al servidor de la autoridad certificadora de Google y aprovisiona de forma automática el certificado directamente en el almacenamiento no volátil del vTPM de una instancia de Confidential VM. Un invitado puede recuperar este certificado de forma individual solicitándolo al vTPM con un software como go-tpm-tools.

Para AMD SEV-SNP e Intel TDX, el host extrae la evidencia de hardware de la CPU y la presenta a una caché administrada por Google. En esta caché, se almacenan los certificados que se extrajeron anteriormente del servicio de distribución de claves de AMD y del servicio de certificados de aprovisionamiento de Intel. Después de presentar correctamente la evidencia de hardware, los certificados se almacenan en caché en el disco del host y se comparten con el invitado. Un invitado puede recuperar estos certificados de forma individual para validar el hardware con software como go-sev-guest y go-tdx-guest.

Los certificados contienen la siguiente información:

• La identidad de la entidad emisora del certificado, ya sea AMD, Google o Intel.

• La clave de certificación pública, que verifica la firma en las cotizaciones de PCR (vTPM), los informes de certificación (SEV-SNP) y las cotizaciones de certificación (Intel TDX).

• Solo certificación de hardware: las versiones de TCB de microcódigo y firmware de hardware en las que se ejecuta el firmware del host.

• Solo certificación de hardware: evidencia que vincula el certificado a un procesador físico específico, que se firmó con una clave privada en el procesador y no se puede exfiltrar. Para SEV-SNP de AMD, esta evidencia es el ID de la plataforma. En el caso de Intel TDX, la evidencia es el manifiesto de la plataforma.

Firmware

Para la certificación de hardware, las aprobaciones de inicio del firmware están disponibles directamente desde las instancias de VM o se pueden descargar en línea. Los respaldos de inicio son búferes de protocolo serializados en formato binario y firmados que se usan para confirmar que no se alteró el firmware virtual de una instancia de Confidential VM.

Cuando se inicia una VM, el procesador seguro de AMD o el módulo Intel TDX genera un hash del objeto binario del firmware antes de que se ejecute. Este resumen SHA-384 se almacena en el campo MEASUREMENT para AMD SEV-SNP y en el MRTD para Intel TDX.

Puedes usar ese resumen para descargar un aval de lanzamiento de Google, verificar que la firma esté vinculada a Google con una herramienta como gcetcbendorsement y, luego, verificar que los resúmenes SHA-384 coincidan entre la medición del firmware y lo que se registra en el aval.

Más allá de la verificación del firmware, puedes usar ciertas propiedades en una aprobación de inicio para aplicar una política de acceso, como el número mínimo de versión de seguridad (SVN), el recuento de CPU virtuales, la configuración de la memoria o el ID de familia de la UEFI.

Para obtener más información, consulta Verifica el firmware de una instancia de Confidential VM.

Reproducción y análisis del registro de eventos del verificador

Además de verificar directamente la evidencia proporcionada por un certificador, un verificador puede reproducir un registro de eventos proporcionado por el certificador para verificar su integridad con respecto a los valores de su registro de mediciones.

Para ello, el verificador crea una versión simulada de cada registro de medición que necesita verificar como parte de su política de certificación. Luego, propaga ese registro simulado con eventos de un registro de eventos. Si el valor final del registro simulado coincide con el valor almacenado en el registro de medición real equivalente, esto aumenta la confianza de que no se alteraron el registro de eventos ni el proceso de inicio de la instancia de Confidential VM.

Después de que se verifica un registro de esta manera, se puede analizar para obtener mediciones individuales en las que un verificador o una parte de confianza pueden basar la política.

Crea tus propias herramientas de análisis y reproducción de registros de eventos

Si bien puedes compilar tu propio software para reproducir y analizar los registros de eventos, te recomendamos que uses software establecido, como go-eventlog, para evitar errores comunes, como la vulnerabilidad EventType para los formatos de registro de eventos de Trusted Computing Group y Confidential Computing.

Si aún deseas compilar tu propio software de reproducción y análisis, los siguientes ejemplos basados en vTPM pueden ayudarte a comprenderlo, aunque debes basar tu implementación en el registro de eventos que genera tu propia instancia de Confidential VM.

En el siguiente ejemplo, se muestran eventos seleccionados de un registro de eventos de vTPM de Ubuntu 24.04, que se miden en el PCR 0. El registro de eventos se convirtió de binario a ASCII con tpm2_eventlog usando el siguiente comando:

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

Los eventos de PCR 0 del registro son los siguientes:

---
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"

Cuando se restablece la instancia de Confidential VM, sus PCR se inicializan en cero. A medida que ocurren los eventos, el valor en el banco SHA-256 de PCR 0 (PCRIndex: 0) cambia de la siguiente manera (los eventos EV_NO_ACTION no extienden el registro):

1. El valor del registro se concatena con el resumen SHA-256 del siguiente evento asignado al PCR 0, EV_S_CRTM_VERSION. El resultado concatenado se vuelve a codificar con SHA-256 y, luego, se almacena en el registro. El resumen hexadecimal SHA-256 de PCR 0 ahora es 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. Se usa el mismo proceso para el evento EV_NONHOST_INFO. El resumen hexadecimal SHA-256 de PCR 0 ahora es 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

3. Se usa el mismo proceso para un evento EV_SEPARATOR, que indica que se completaron las extensiones de medición en un registro específico. El EV_SEPARATOR es un valor cero de 32 bits (\x00*4). Esto hace que el resumen hexadecimal SHA-256 final de PCR 0 sea a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

En el siguiente código de Python, se muestra el procedimiento anterior creando un PCR 0 de Compute Engine simulado. El código no es una reproducción del registro de eventos, ya que deriva sus resúmenes de eventos de valores conocidos. Cuando crees una reproducción adecuada del registro de eventos, debes leer los resúmenes del registro de eventos de tu instancia de 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()

Configuración de la parte de confianza

Según si se usa el modelo de pasaporte o el modelo de verificación de antecedentes, la parte de confianza recibe los resultados de la certificación del certificador o del verificador.

Luego, la parte de confianza verifica que las reclamaciones que recibió en los resultados de la certificación coincidan con los valores esperados. Si los valores coinciden, la parte de confianza permite que el certificador acceda a los recursos como una identidad local.

Un patrón común para configurar una parte de confianza en Google Cloud es usar la federación de identidades para cargas de trabajo y tratar al certificador como una identidad federada:

1. Agrega tu verificador como proveedor de OIDC a un grupo de identidades para cargas de trabajo. Después de esto, la cuenta de servicio adjunta a la carga de trabajo de tu instancia de Confidential VM puede actuar como una identidad federada y acceder a los recursos necesarios.

2. Define los valores que deben coincidir con las reclamaciones de certificación del verificador para que se le otorgue acceso a los recursos al certificador.

   En Google Cloud, esto implica asignar reclamaciones de certificación a atributos para que Identity and Access Management (IAM) pueda procesarlas como condiciones que una identidad federada debe pasar para autenticarse como principal.

   Luego, puedes otorgarle al certificador acceso directo a los recursos agregando una vinculación de rol para su principal federada a las políticas de permisos de los recursos necesarios. Para los servicios que no admiten identidades federadas, puedes proporcionar acceso a los recursos a través de la identidad temporal como cuenta de servicio.

Como alternativa a la federación de identidades para cargas de trabajo, puedes escribir código para analizar las reclamaciones de un token de certificación directamente. Para ver un ejemplo, consulta Certificación remota de vTPM en la máquina virtual confidencial.