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 esté funcionando en un estado esperado. La certificación puede ayudarte a evaluar la confiabilidad de un sistema antes de darle acceso a tus recursos protegidos.

Partes y modelos de certificación

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

• Un verificador En Google Cloud, se trata de 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 vio comprometida y no es una suplantadora, la VM y su host toman medidas del estado del hardware y 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 resultado de la certificación.

  Un verificador puede ser un servicio preexistente, como Google Cloud Attestation o Intel Trust Authority, o algo que hayas creado tú mismo.

• Un usuario de confianza La parte que confía controla el acceso a los recursos protegidos que necesita el verificador. Cuando recibe un resultado de certificación, la parte que confía en la certificación verifica los valores de la evidencia en función de su política de acceso. Si los valores coinciden, se le permite al verificador acceder a los recursos.

  La parte Google Cloud confiante 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 sigue tu arquitectura. La RFC de la arquitectura de los procedimientos de atestación remota (RATS) define dos modelos principales de atestación: el modelo de pasaporte y el modelo de verificación de antecedentes. La principal diferencia entre ambos es qué parte tiene la posesión de la identidad verificada del certificador: el certificador o la parte que confía.

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 verificador envía evidencia de su identidad a un verificador.

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

3. El verificador envía el resultado de la certificación a una entidad de confianza.

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

En el modelo de pasaporte, el certificador y la parte que confía 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 de antecedentes usa el siguiente proceso para confirmar la identidad de un verificador y otorgar acceso a los recursos solicitados:

1. El certificador envía evidencia de su identidad a una parte autenticada.

2. La parte autenticada reenvía la evidencia a un verificador.

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

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

Con el modelo de verificación de antecedentes, una parte que confía determina la evidencia de certificación que requiere y elige el verificador.

Arquitectura y evidencia del verificador

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

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 base de procesamiento confiable (TCB). El TCB es una colección de hardware y software en una VM invitada y su host que son responsables de tareas como el aislamiento del entorno (a través de mecanismos como el cifrado 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 la generación de informes proporciona protección de integridad y autenticidad para la cadena de medición. Recupera mediciones de la raíz de confianza para el almacenamiento y las agrupa en un paquete de evidencia firmado llamado informe de cita o atestación. Este paquete está firmado 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 reproducción.

  Término clave: Un ataque de reproducción se produce cuando una persona malintencionada copia evidencia que verifica una identidad y la usa para obtener acceso ilegítimo a los recursos. Una forma de combatir los ataques de reproducción es con un nonce: un número aleatorio de un solo uso y de corta duración que proporciona una de las partes que protegen los recursos (en el caso de la 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 recursos, es probable que falle porque el nonce incluido en la evidencia ya se usó o venció.

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

AMD SEV

Una instancia de Confidential VM con SEV de AMD certifica su entorno y configuración con mediciones basadas en el 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: Es el firmware de la instancia de VM.

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

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

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

AMD SEV-SNP

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

Para las mediciones del cargador de arranque, 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: Firmware del procesador seguro de AMD y de la instancia de VM

• Raíz de confianza para el almacenamiento: Procesador seguro de AMD y 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 informes de certificación

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

Para obtener información sobre qué mediciones se registran en el procesador seguro de AMD, consulta Registro de medición de AMD SEV-SNP.

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

Intel TDX

Una instancia de Confidential VM con Intel TDX certifica su entorno y configuración a través del módulo 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 registran en los registros de medición del tiempo 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: Registro de medición del dominio de confianza (MRTD) y registros de medición del tiempo de ejecución (RTMR)

• Raíz de confianza para la generación de informes: Es el enclave de citas del dominio de confianza (TDQE) dentro del módulo Intel TDX, que genera una clave de certificación para firmar citas de certificación.

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

Certificación de software y hardware

Las tecnologías de Confidential Computing en Google Cloud se pueden considerar como software o hardware atestiguado, según sus raíces de confianza.

Atestación de software significa que las raíces de confianza se basan en software: el firmware virtual es la raíz de confianza para la medición, y la raíz de confianza para el almacenamiento es el vTPM de la VM protegida. El hipervisor del host administra el vTPM, mientras que la VM invitada administra el firmware. En Google Cloud, Google controla ambos componentes.

Certificado por hardware significa que las mediciones se administran y protegen con hardware dedicado fuera del control de tu proveedor de servicios. En Google Cloud, este hardware incluye el procesador seguro de AMD para AMD SEV-SNP (solo para mediciones de inicio) y el módulo Intel TDX para Intel TDX.

La certificación de hardware quita el hipervisor del proveedor de servicios de la raíz de confianza para la medición y el almacenamiento, y aísla las mediciones en hardware dedicado. Incluso si un agente malicioso obtiene el control del hipervisor del host, no puede falsificar un informe o una cita de certificación, ya que no tiene acceso para modificar los registros del hardware dedicado.

Las tecnologías de Confidential Computing que proporciona Google Cloud se clasifican de la siguiente manera:

• AMD SEV: Se certifica el software. El firmware virtual se mide a sí mismo, y las mediciones se almacenan en el vTPM de la VM protegida.

• AMD SEV-SNP: Se certifica el hardware y el software híbridos. El procesador seguro de AMD registra y almacena las mediciones de inicio, incluidas las del firmware virtual, lo que las convierte en mediciones certificadas por hardware. Las mediciones del cargador de arranque, el kernel y el espacio del usuario se almacenan en el vTPM de la VM protegida, lo que hace que se certifiquen por software. Puedes optar por usar solo las mediciones certificadas por hardware, las mediciones certificadas por software o ambas.

• Intel TDX: Hardware certificado. El módulo TDX mide el firmware virtual, y todas las mediciones se almacenan en el módulo TDX de Intel. Sin embargo, el vTPM de la VM protegida sigue siendo parte del sistema, pero no del TCB, a menos que ejecutes software que necesite una interfaz de TPM.

Registros de medición

Las raíces de confianza de las Confidential VMs proporcionan almacenamiento protegido y resistente a manipulaciones para las mediciones en forma de registros de medición (MR). El nombre de esos registros de medición cambia según la tecnología de Confidential Computing que se use:

• SEV de AMD: Registros de configuración de la plataforma (PCR) Estos 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 generan con diferentes algoritmos de hash: SHA-1, SHA-256 y SHA-384.

• AMD SEV-SNP: Es el registro de MEASUREMENT de inicio. 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 cargador de arranque, el kernel y el espacio del usuario.

• Intel TDX: La medición del dominio de confianza (MRTD) en tiempo de compilación y los registros de medición en 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 el valor de un registro. Por lo general, los registros de medición contienen 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 del 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 cargador de arranque, 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 del 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 aplicación de políticas basadas en valores específicos del registro de medición. 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 los convierte en criterios potencialmente inestables para basar las políticas y aumenta la carga de mantenimiento. Si necesitas basar la política en valores de registros de medición, intenta seleccionar valores de registros 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. Un verificador primero 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 tienen lugar.

Estos registros de eventos tienen los siguientes fines:

• 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 en que no se manipuló 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 arranque seguro o usar una tecnología específica de Confidential Computing antes de que se muestre un resultado de certificación exitoso.

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 para verificar	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 de 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 el análisis y la reproducción de registros de eventos.

Informes de certificación y citas

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, ya que firma sus mediciones con una clave de certificación. El BLOB binario resultante se conoce como cita de PCR para los vTPM, informe de certificación para AMD SEV-SNP y cita para Intel TDX.

El contenido del BLOB binario varía según las diferentes 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 usó 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 cita de PCR.

  Para obtener detalles sobre la estructura de TPMS_ATTEST, consulta Trusted Platform Module Library, Part 2: Structures (PDF).

• SEV-SNP de AMD: El procesador seguro de AMD genera un resumen SHA-384 basado en sus mediciones de inicio iniciales que se toman antes de que se ejecute el UEFI de la instancia de Confidential VM.

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

  Para obtener detalles sobre la estructura de ATTESTATION_REPORT, consulta la 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 un presupuesto es un proceso de varios pasos. En primer lugar, el enclave de certificación de aprovisionamiento dentro de la CPU deriva una clave de certificación de aprovisionamiento (PCK) de los secretos criptográficos fusionados en la CPU. Luego, el enclave de citas dentro de la CPU genera una clave de certificación privada, que se firma con la clave de certificación de aprovisionamiento. Luego, se firma el TDREPORT_STRUCT con la clave de certificación privada para crear una cita.

  Para obtener detalles sobre la estructura de TDREPORT_STRUCT, consulta Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification (PDF).

Recomendaciones

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

Certificados

Los certificados X.509 v3 se usan como evidencia de que se está usando hardware genuino de AMD o Intel en el host, o de que la instancia de Confidential VM está usando 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)

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

En el caso de AMD SEV-SNP y de Intel TDX, el host extrae evidencia de hardware de la CPU y la presenta en 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:

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

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

• Solo certificación de hardware: 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 filtrar. En el caso de AMD SEV-SNP, 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. Las confirmaciones de inicio son búferes de protocolo serializados de forma binaria y firmados que se usan para confirmar que no se manipuló el firmware virtual de una instancia de Confidential VM.

Cuando se inicia una VM, el procesador seguro de AMD o el módulo TDX de Intel 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 una aprobación 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 registró en la aprobación.

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

Para obtener más información, consulta Cómo verificar 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 en relación con los valores de su registro de medición.

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, aumenta la confianza en que no se manipuló 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 que confía 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 comprender los conceptos iniciales, 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 eventos, el valor en el banco SHA-256 del 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 del PCR 0 ahora es 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

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

3. El mismo proceso se usa 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), lo que hace que el resumen hexadecimal final de SHA-256 del PCR 0 sea a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

En el siguiente código de Python, se muestra el procedimiento anterior mediante la creación de un PCR 0 de Compute Engine simulado. El código no es una repetició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 entidad de confianza

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

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

Un patrón común para configurar una entidad externa en Google Cloud es usar la federación de identidades para cargas de trabajo y tratar al verificador 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 VM confidencial puede actuar como una identidad federada y acceder a los recursos necesarios.

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

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

   Luego, puedes otorgarle al verificador acceso directo a los recursos agregando una vinculación de rol para su principal federada a las políticas de permiso de los recursos necesarios. En el caso de los servicios que no admiten identidades federadas, puedes proporcionar acceso a los recursos a través del robo de identidad de la 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 una máquina virtual confidencial.