Visão geral da declaração remota

O atestado remoto é o processo de verificar se a identidade de uma instância de VM confidencial é legítima e se ela está operando em um estado esperado. A comprovação pode ajudar você a avaliar a confiabilidade de um sistema antes de dar acesso a recursos protegidos.

Partes e modelos de atestado

Geralmente, há três partes no processo de comprovação:

• Um atestador. No Google Cloud, essa é uma carga de trabalho em uma instância de VM confidencial que exige acesso a recursos protegidos. Para aumentar a confiança de que a instância de VM confidencial não foi comprometida e não é uma impostora, a VM e o host fazem medições do hardware e do software virtuais da VM durante o processo de inicialização.

• Um verificador. Um verificador é um sistema externo que valida as evidências de uma instância de VM confidencial e as compara com a política de atestado para garantir que a configuração da VM esteja conforme o esperado. Se a evidência passar nas verificações necessárias, o verificador vai retornar uma versão assinada dela, conhecida como um resultado de comprovação.

  Um verificador pode ser um serviço preexistente, como o Google Cloud Attestation ou o Intel Trust Authority, ou algo que você criou.

• Uma parte confiável. A parte confiável controla o acesso aos recursos protegidos de que o atestador precisa. Ao receber um resultado de atestado, a parte confiável verifica os valores na evidência em relação à política de acesso. Se os valores forem iguais, o atestador terá acesso aos recursos.

  Na Google Cloud , a parte confiante geralmente é um pool de identidade da carga de trabalho, com o verificador adicionado como um provedor OpenID Connect (OIDC).

A forma como as partes interagem depende do modelo de comprovação seguido pela sua arquitetura. A RFC da arquitetura de procedimentos de atestado remoto (RATS) define dois modelos principais de atestado: o modelo de passaporte e o modelo de verificação de antecedentes. A principal diferença entre os dois é qual parte tem a posse da identidade verificada do atestador: o atestador ou a parte confiante.

Modelo de passaporte

O modelo de passaporte usa o seguinte processo para confirmar a identidade de um atestador e conceder acesso aos recursos solicitados:

1. O atestador envia evidências da identidade a um verificador.

2. Se a evidência for considerada confiável, o verificador enviará ao atestador o resultado do atestado, que pode ser um token de atestado.

3. O atestador envia o resultado da declaração para uma parte confiável.

4. A parte confiável verifica se o resultado do atestado atende a determinadas condições. Se o resultado atender às expectativas, a parte confiante permitirá que o atestador acesse os recursos solicitados.

No modelo de passaporte, o atestador e a parte confiante precisam concordar com a aparência dos resultados do atestado, o que significa que eles precisam concordar com um verificador.

Modelo de investigação de histórico para contratação

O modelo de verificação de antecedentes usa o seguinte processo para confirmar a identidade de um atestador e conceder acesso aos recursos solicitados:

1. O atestador envia evidências da identidade dele para uma parte confiável.

2. A parte confiável encaminha a evidência a um verificador.

3. Se a evidência for considerada confiável, o verificador enviará o resultado da declaração para a parte confiante, geralmente como um token de declaração.

4. A parte confiável verifica se o resultado do atestado atende a determinadas condições. Se o resultado atender às expectativas, a parte confiante permitirá que o atestador acesse os recursos solicitados.

Com o modelo de verificação de antecedentes, uma parte confiante determina as evidências de atestado necessárias e escolhe o verificador.

Arquitetura e evidências do atestado

Esta seção aborda como uma instância de VM confidencial como um atestador fornece evidências resistentes a adulteração da própria identidade.

Raízes de confiança

Em um ambiente de execução confiável (TEE), como uma instância de VM confidencial, uma raiz de confiança é um componente de segurança fundamental em que outras confianças são estabelecidas. Uma raiz de confiança oferece funções criptográficas, é resistente a violações e não pode ser modificada por um sistema operacional host.

As raízes de confiança pertencem a um limite de confiança em um TEE conhecido como Base de computação confiável (TCB, na sigla em inglês). O TCB é um conjunto de hardware e software em uma VM convidada e no host dela que são responsáveis por tarefas como isolamento de ambiente (por mecanismos como criptografia de memória e isolamento de hipervisor) e por fazer medições para manter a integridade do ambiente.

Um TEE oferece suporte a raízes de confiança para funções de medição, armazenamento e geração de relatórios:

• A raiz de confiança para medição é o código que inicia as medições do processo de inicialização do TEE.

• A raiz de confiança para armazenamento fornece memória protegida para medições na forma de registros de medição.

• A raiz de confiança para relatórios oferece proteção de integridade e autenticidade para a cadeia de medição. Ele recupera medições da raiz de confiança para armazenamento e as agrupa em um pacote de evidências assinado chamado de cotação ou relatório de atestado. Esse pacote é assinado com uma chave de atestado residente no TEE e pode incluir um valor de uso único criptográfico para garantir que a evidência seja recente e protegida contra ataques de repetição.

  Termo principal: um ataque de repetição ocorre quando um usuário de má-fé copia evidências que verificam uma identidade e usa essas evidências para ganhar acesso ilegítimo a recursos. Uma maneira de combater ataques repetidos é com um nonce: um número aleatório único e de curta duração fornecido por uma das partes que protegem os recursos. No caso da computação confidencial, o verificador. A entidade que prova sua identidade precisa incorporar o nonce às evidências antes que elas sejam enviadas. Se um usuário malicioso tentar usar evidências roubadas para acessar recursos, é provável que a tentativa falhe porque o nonce incluído nas evidências já foi usado ou expirou.

As informações a seguir detalham as diferentes abordagens para raízes de confiança em diferentes tecnologias de computação confidencial.

AMD SEV

Uma instância de VM confidencial com SEV da AMD atesta o ambiente e a configuração usando medições baseadas em vTPM de VM protegida. O processador seguro AMD e o SEV AMD são usados apenas para criptografia de memória.

As raízes de confiança são as seguintes:

• Raiz de confiança para medição: firmware da instância de VM

• Raiz de confiança para armazenamento: vTPM da VM protegida

• Raiz de confiança para geração de relatórios: vTPM da VM protegida, que usa uma chave de atestado particular para assinar relatórios de atestado.

Para saber quais medições são registradas e onde no vTPM da VM protegida, consulte Registros de configuração da plataforma vTPM.

AMD SEV-SNP

Uma instância de VM confidencial com AMD SEV-SNP atesta principalmente o ambiente e a configuração pelo processador seguro AMD, que processa as medições de inicialização.

Para medições de carregador de inicialização, kernel e espaço do usuário, é possível usar medições baseadas no vTPM da VM protegida.

As raízes de confiança são as seguintes:

• Raiz de confiança para medição: firmware do processador seguro AMD + instância de VM

• Raiz de confiança para armazenamento: processador seguro AMD + VM protegida vTPM

• Raiz de confiança para geração de relatórios:

  • Medições de inicialização: o processador seguro da AMD, que usa a chave de endosso do chip de versão (VCEK) residente no chip para assinar relatórios de atestado.

  • Medições do carregador de inicialização, do kernel e do espaço do usuário: vTPM da VM protegida

Para saber quais medições são registradas no AMD Secure Processor, consulte Registro de medição AMD SEV-SNP.

Para saber quais medições são registradas e onde no vTPM da VM protegida, consulte Registros de configuração da plataforma vTPM.

Intel TDX

Uma instância de VM confidencial com Intel TDX atesta o ambiente e a configuração usando o módulo Intel TDX. O módulo Intel TDX mede o firmware do convidado da VM em um domínio de confiança isolado e armazena essas medições na medição do domínio de confiança (MRTD, na sigla em inglês). As medições subsequentes na cadeia de inicialização são medidas nos Registros de Medição de Tempo de Execução (RTMR).

As raízes de confiança são as seguintes:

• Raiz de confiança para medição: módulo Intel TDX

• Raiz de confiança para armazenamento: medição do domínio de confiança (MRTD) e registros de medição de tempo de execução (RTMR)

• Raiz de confiança para relatórios: o Trust Domain Quoting Enclave (TDQE) no módulo Intel TDX, que gera uma chave de atestado para assinar citações de atestado

Para saber quais medições são registradas e onde nos registros de medição do TDX, consulte Registros de medição do Intel TDX.

Atestado de software e hardware

As tecnologias de computação confidencial no Google Cloud podem ser consideradas atestadas por software ou hardware, dependendo das raízes de confiança.

Comprovado por software significa que as raízes de confiança são baseadas em software: o firmware virtual é a raiz de confiança para medição, e a raiz de confiança para armazenamento é o vTPM da VM protegida. O vTPM é gerenciado pelo hipervisor do host, enquanto o firmware é gerenciado pela VM convidada. No Google Cloud, os dois componentes são controlados pelo Google.

Hardware atestado significa que as medições são gerenciadas e protegidas por hardware dedicado fora do controle do provedor de serviços. No Google Cloud, esse hardware inclui o processador seguro da AMD para AMD SEV-SNP (somente para medições de inicialização) e o módulo Intel TDX para Intel TDX.

A comprovação de hardware remove o hipervisor do provedor de serviços da raiz de confiança para medição e armazenamento, além de isolar as medições em hardware dedicado. Mesmo que um usuário malicioso assuma o controle do hipervisor do host, ele não pode falsificar um relatório ou uma citação de atestado porque não tem acesso para modificar os registros do hardware dedicado.

As tecnologias de computação confidencial fornecidas pela Google Cloud são categorizadas da seguinte forma:

• AMD SEV: software atestado. O firmware virtual se mede, e as medições são armazenadas no vTPM da VM protegida.

• AMD SEV-SNP: hardware e software híbridos atestados. As medições de inicialização, incluindo as do firmware virtual, são registradas e armazenadas no processador seguro AMD, o que as torna atestadas por hardware. As medições do carregador de inicialização, do kernel e do espaço do usuário são armazenadas no vTPM da VM protegida, o que as torna atestadas por software. Você pode usar apenas as medições atestadas por hardware, as medições atestadas por software ou ambas.

• Intel TDX: hardware atestado. O módulo TDX mede o firmware virtual, e todas as medições são armazenadas no módulo Intel TDX. O vTPM da VM protegida ainda faz parte do sistema, mas não do TCB, a menos que você execute um software que precise de uma interface TPM.

Registros de medição

As raízes de confiança da VM confidencial oferecem armazenamento protegido e resistente a violações para medições na forma de registros de medição (MRs, na sigla em inglês). O nome desses registros de medição muda dependendo da tecnologia de computação confidencial em uso:

• AMD SEV: registros de configuração da plataforma (PCRs). Eles estão localizados dentro do vTPM da VM protegida.

  Os vTPMs das VM protegida usam três bancos de PCRs que armazenam as mesmas medições, mas são criptografados com algoritmos diferentes: SHA-1, SHA-256 e SHA-384.

• AMD SEV-SNP: o registro de MEASUREMENT do lançamento. Ele fica dentro do processador seguro da AMD.

  Os PCRs no vTPM da VM protegida também são usados para armazenar as medições do carregador de inicialização, do kernel e do espaço do usuário.

• Intel TDX: a medição do tempo de build do domínio de confiança (MRTD) e registros de medição de tempo de execução (RTMR).

  As medições também estão disponíveis nos PCRs de vTPM da VM protegida para software que espera uma interface de TPM.

Somente uma raiz de confiança pode mudar um valor de registro. Os registros de medição geralmente contêm um único resumo criptográfico, que representa um único evento ou um conjunto de eventos.

Para eventos únicos, como a medição de lançamento ou de tempo de build de uma VM, uma raiz de confiança geralmente grava diretamente no registro e o torna imutável pelo restante da vida útil do TEE.

Os componentes carregados mais tarde na cadeia de inicialização, como o carregador de inicialização, o kernel e o espaço do usuário, podem registrar medições de vários eventos em um único registro. Para armazenar as medições de conjuntos de eventos, os registros de medição expõem um comando extend que concatena o valor do registro atual com um novo resumo de evento, gera hash do valor concatenado e armazena o resumo resultante. Esse processo é representado pela seguinte fórmula:

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

Como as funções de hash são unidirecionais, é difícil replicar os mesmos valores de registro de medição sem fornecer as mesmas medições na mesma ordem. Embora essa propriedade ajude a determinar a integridade da VM, pode ser difícil basear a política em valores específicos de registro de medição. Isso acontece porque pequenas mudanças nas entradas de medição, como atualizações de software ou firmware ou uma mudança na ordem de medição, resultam em valores de registro diferentes, tornando-os critérios potencialmente instáveis para basear políticas e aumentando a carga de manutenção. Se você precisar basear a política em valores de registro de medição, tente selecionar valores mais estáveis, como PCR 0 ou PCR 7 em vTPMs.

Dica: para basear a política em medições individuais estáveis em vez de valores de registro de medição, use um registro de eventos gerado pelo TCB. Um verificador primeiro precisa realizar uma repetição do registro de eventos para verificar a integridade do registro em relação aos registros de medição. Depois de uma verificação bem-sucedida, ele pode analisar os eventos para extrair medições significativas.

Logs de eventos

À medida que as medições são gravadas ou estendidas em registros de medição, um ou mais registros são gravados no sistema de arquivos do sistema operacional convidado, registrando os eventos de medição que ocorrem.

Esses registros de eventos têm as seguintes finalidades:

• Um verificador pode reproduzir registros de eventos para percorrer o processo de medição da instância de VM confidencial usando registros de medição simulados. Se os resumos finais calculados pelo verificador corresponderem aos resumos finais informados pelo atestador, isso poderá aumentar a confiança de que o registro de eventos e o processo de inicialização da instância de VM confidencial não foram adulterados.

• Depois da reprodução, um verificador pode analisar os registros de eventos para comparar evidências com políticas de atestado. Um verificador pode exigir que um atestador atenda a determinados critérios, como ter a inicialização segura ativada ou usar uma tecnologia específica de computação confidencial antes que um resultado de atestado seja retornado.

Os registros de eventos são armazenados no sistema de arquivos do sistema operacional convidado nos seguintes locais:

Tecnologia de computação confidencial	MRs a serem verificadas	Tipo de registro	Caminho do SO convidado para repetição do registro de eventos
AMD SEV, AMD SEV-SNP, Intel TDX	Registros de configuração de plataforma (PCRs) do vTPM	Registro de eventos do Trusted Computing Group (TCG)	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	Registro de eventos de computação confidencial (CCEL)	/sys/firmware/acpi/tables/data/CCEL

Saiba mais sobre reproduções e análise de registros de eventos.

Citações e relatórios de atestação

A raiz de confiança para relatórios oferece proteção de integridade e autenticidade para os resumos armazenados no registro de medição ao assinar as medições com uma chave de atestado. O blob binário resultante é conhecido como uma citação de PCR para vTPMs, um relatório de atestado para AMD SEV-SNP e uma citação para Intel TDX.

O que está no blob binário é diferente para as diferentes tecnologias de computação confidencial:

• AMD SEV: o vTPM da VM protegida lê os valores de um dos bancos de PCR (SHA-1, SHA-256 ou SHA-384), concatena esses valores em ordem numérica e faz o hash do resultado com o mesmo algoritmo usado para o banco de PCR, criando um resumo. Esse resumo, junto com um valor de uso único opcional fornecido por um verificador, é colocado em uma estrutura TPMS_ATTEST e assinado pela chave de atestado privada do vTPM para criar uma cotação de PCR.

  Para detalhes sobre a estrutura TPMS_ATTEST, consulte Biblioteca do módulo de plataforma confiável, Parte 2: Estruturas (PDF).

• AMD SEV-SNP: o processador seguro AMD gera um resumo SHA-384 com base nas medições de inicialização iniciais feitas antes da execução da UEFI da instância de VM confidencial.

  Esse resumo, outros dados da VM e um nonce opcional fornecido por um verificador são colocados em uma estrutura ATTESTATION_REPORT assinada pela chave de endosso do chip de versão (VCEK, na sigla em inglês) do processador seguro da AMD para criar um relatório de atestado.

  Para detalhes sobre a estrutura ATTESTATION_REPORT, consulte Especificação de ABI do firmware de paginação aninhada segura do SEV (PDF).

• Intel TDX: o módulo TDX coloca os valores de MRTD e RTMR, outros dados da VM e um nonce opcional fornecido por um verificador em uma estrutura TDREPORT_STRUCT.

  Criar um orçamento é um processo de várias etapas. Primeiro, o enclave de certificação de provisionamento dentro da CPU deriva uma chave de certificação de provisionamento (PCK, na sigla em inglês) de segredos criptográficos fundidos na CPU. Em seguida, o Enclave de cotação dentro da CPU gera uma chave de atestado privada, que é assinada com a chave de certificação de provisionamento. Em seguida, o TDREPORT_STRUCT é assinado com a chave de atestado privada para criar uma cotação.

  Para detalhes sobre a estrutura TDREPORT_STRUCT, consulte Especificação da arquitetura básica do módulo Intel Trust Domain Extensions (Intel TDX) (PDF).

Endossos

Diferentes tipos de endossos são usados como evidência de que uma instância de VM confidencial está sendo executada nas configurações esperadas de hardware, vTPM e firmware.

Certificados

Os certificados X.509 v3 são usados como evidência de que um hardware AMD ou Intel genuíno está sendo usado no host ou de que a instância de VM confidencial está usando um vTPM de VM protegida.

O nome do certificado é diferente para cada uma das tecnologias de computação confidencial:

• AMD SEV: certificado de chave de atestado (AK)

• AMD SEV-SNP: certificado de chave de endosso de chip de versão (VCEK)

• Intel TDX: certificado de chave de certificação de provisionamento (PCK)

Para o AMD SEV, o certificado verifica o vTPM da VM protegida. O host faz uma solicitação ao servidor da autoridade certificadora do Google e provisiona automaticamente o certificado diretamente no armazenamento não volátil do vTPM de uma instância de VM confidencial. Um visitante pode recuperar esse certificado individualmente solicitando-o do vTPM com softwares como go-tpm-tools.

Para AMD SEV-SNP e Intel TDX, o host extrai evidências de hardware da CPU e as apresenta a um cache gerenciado pelo Google. Esse cache armazena certificados extraídos anteriormente do serviço de distribuição de chaves da AMD e do serviço de certificado de provisionamento da Intel. Depois de apresentar as evidências de hardware, os certificados são armazenados em cache no disco do host e compartilhados com o convidado. Um convidado pode recuperar esses certificados individualmente para validar o hardware com software como go-sev-guest e go-tdx-guest.

Os certificados contêm as seguintes informações:

• A identidade do emissor do certificado, seja AMD, Google ou Intel.

• A chave de atestado público, que verifica a assinatura em citações de PCR (vTPM), relatórios de atestado (SEV-SNP) e citações de atestado (Intel TDX).

• Atestado de hardware apenas: as versões de microcódigo de hardware e TCB de firmware em que o firmware do host está sendo executado.

• Somente confirmação de hardware: evidência que vincula o certificado a um processador físico específico, que foi assinado com uma chave privada no processador e não pode ser exfiltrado. Para o AMD SEV-SNP, essa evidência é o ID da plataforma. Para o Intel TDX, a evidência é o manifesto da plataforma.

Firmware

Para o atestado de hardware, os endossos de inicialização de firmware estão disponíveis diretamente nas instâncias de VM ou podem ser baixados on-line. Os endossos de inicialização são buffers de protocolo serializados em binário assinados que são usados para confirmar que o firmware virtual de uma instância de VM confidencial não foi adulterado.

Quando uma VM é iniciada, o processador seguro da AMD ou o módulo Intel TDX faz hash do binário de firmware antes da execução. Esse resumo SHA-384 é armazenado no campo MEASUREMENT para AMD SEV-SNP e no MRTD para Intel TDX.

Você pode usar esse resumo para baixar uma declaração de lançamento do Google, verificar se a assinatura está vinculada ao Google com uma ferramenta como gcetcbendorsement e, em seguida, verificar se os resumos SHA-384 correspondem entre a medição do firmware e o que está registrado na declaração.

Além da verificação de firmware, você pode usar determinadas propriedades em uma assinatura de inicialização para aplicar uma política de acesso, como o número mínimo da versão de segurança (SVN), a contagem de vCPUs, a configuração de memória ou o ID da família da UEFI.

Para mais informações, consulte Verificar o firmware de uma instância de VM confidencial.

Repetição e análise do registro de eventos do verificador

Além de verificar diretamente as evidências fornecidas por um atestador, um verificador pode reproduzir um registro de eventos fornecido pelo atestador para verificar a integridade dele em relação aos valores de registro de medição.

Para isso, o verificador cria uma versão simulada de cada registro de medição que precisa verificar como parte da política de atestado. Em seguida, ele preenche esse registro simulado usando eventos de um registro de eventos. Se o valor final do registro simulado corresponder ao valor armazenado no registro de medição equivalente e real, isso aumenta a confiança de que o registro de eventos e o processo de inicialização da instância de VM confidencial não foram adulterados.

Depois que um registro é verificado dessa forma, ele pode ser analisado para medições individuais que um verificador ou uma parte confiante pode usar como base para a política.

Crie suas próprias ferramentas de análise e repetição de registros de eventos

Embora seja possível criar seu próprio software para reproduzir e analisar registros de eventos, recomendamos usar um software estabelecido, como o go-eventlog, para evitar problemas comuns, como a vulnerabilidade EventType para os formatos de registro de eventos do Trusted Computing Group e da computação confidencial.

Se você ainda quiser criar seu próprio software de reprodução e análise, os exemplos a seguir baseados em vTPM podem ajudar na compreensão inicial. No entanto, baseie sua implementação no registro de eventos gerado pela sua própria instância de VM confidencial.

O exemplo a seguir tem eventos selecionados de um registro de eventos vTPM do Ubuntu 24.04, que medem o PCR 0. O registro de eventos foi convertido de binário para ASCII com tpm2_eventlog usando o seguinte comando:

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

Os eventos de PCR 0 do registro são os seguintes:

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

Quando a instância de VM confidencial é redefinida, os PCRs são inicializados como zero. À medida que os eventos ocorrem, o valor no banco SHA-256 do PCR 0 (PCRIndex: 0) muda da seguinte forma (os eventos EV_NO_ACTION não estendem o registro):

1. O valor do registro é concatenado com o resumo SHA-256 do próximo evento atribuído ao PCR 0, EV_S_CRTM_VERSION. O resultado concatenado é novamente hash SHA-256 e armazenado no registro. O hexdigest SHA-256 do PCR 0 agora é 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. O mesmo processo é usado para o evento EV_NONHOST_INFO. O hexdigest SHA-256 do PCR 0 agora é 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

3. O mesmo processo é usado para um evento EV_SEPARATOR, que indica que as extensões de medição em um registro específico foram concluídas. O EV_SEPARATOR é um valor zero de 32 bits (\x00*4). Isso torna o hexdigest SHA-256 final do PCR 0 a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

O código Python a seguir demonstra o procedimento anterior criando um PCR 0 simulado do Compute Engine. O código não é uma repetição do registro de eventos, porque deriva os resumos de eventos de valores conhecidos. Ao criar uma repetição adequada do registro de eventos, leia os resumos do registro de eventos da instância 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()

Configuração da entidade confiável

Dependendo do uso do modelo de passaporte ou do modelo de verificação de antecedentes, a parte confiante recebe os resultados da declaração do declarante ou do verificador.

Em seguida, a parte confiante verifica se as declarações recebidas nos resultados da atestação correspondem aos valores esperados. Se os valores forem iguais, a parte confiável permitirá que o atestador acesse recursos como uma identidade local.

Um padrão comum para configurar uma parte confiável em Google Cloud é usar a federação de identidade da carga de trabalho e tratar o atestador como uma identidade federada:

1. Adicione seu verificador como um provedor OIDC a um pool de identidades de carga de trabalho. Depois disso, a conta de serviço anexada à carga de trabalho da instância de VM confidencial pode agir como uma identidade federada e acessar os recursos necessários.

2. Defina os valores que as declarações de atestado do verificador precisam corresponder para que o atestador tenha acesso aos recursos.

   No Google Cloud, isso envolve mapear declarações de atestado para atributos para que o Identity and Access Management (IAM) possa processá-las como condições que uma identidade federada precisa atender para se autenticar como uma principal.

   Em seguida, conceda ao atestador acesso direto aos recursos adicionando uma vinculação de papel para o principal federado às políticas de permissão dos recursos necessários. Para serviços que não oferecem suporte a identidades federadas, é possível conceder acesso a recursos por personificação de conta de serviço.

Como alternativa à federação de identidade da carga de trabalho, você pode escrever um código para analisar as declarações de um token de atestado diretamente. Por exemplo, consulte Certificação remota de vTPM em máquina virtual confidencial.