Visão geral da declaração remota

A atestação remota é 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. O atestado pode ajudar você a avaliar a confiabilidade de um sistema antes de conceder a ele acesso aos seus recursos protegidos.

Partes e modelos de atestado

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

• Um atestador. No Google Cloud, essa é uma carga de trabalho em uma instância de VM confidencial que requer acesso a recursos protegidos. Para aumentar a confiança de que a instância de VM confidencial não foi comprometida e não é um impostor, a VM e o host dela fazem medições do estado do hardware e do software virtual 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 correta. Se as evidências passarem nas verificações necessárias, o verificador retornará uma versão assinada das evidências, conhecida como resultado do atestado.

  Um verificador pode ser um serviço pré-existente, como o Google Cloud Attestation ou o Intel Trust Authority, ou algo que você mesmo 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 correspondentes, o atestador terá acesso aos recursos.

  No Google Cloud , a parte confiável geralmente é um pool de Identidade da carga de trabalho, com o verificador adicionado como um provedor do OpenID Connect (OIDC).

A forma como as partes interagem depende do modelo de atestação que sua arquitetura segue. A RFC de arquitetura de procedimentos de atestação remota (RATS, na sigla em inglês) define dois modelos principais de atestação: o modelo de passaporte e o modelo de verificação de histórico. A principal diferença entre os dois é qual parte tem a posse da identidade verificada do atestador: o atestador ou a parte confiável.

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 dele para um verificador.

2. Se as evidências forem consideradas confiáveis, o verificador enviará ao atestador o resultado do atestado, que pode assumir a forma de um token de atestado.

3. O atestador envia o resultado do atestado 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 confiável permitirá que o atestador acesse os recursos solicitados.

No modelo de passaporte, o atestador e a parte confiável 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 investigação de histórico para contratação 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 para um verificador.

3. Se as evidências forem consideradas confiáveis, o verificador enviará à parte confiável o resultado do atestado, geralmente como um token de atestado.

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

Com o modelo de verificação de histórico para contratação, uma parte confiável determina as evidências de atestação necessárias e escolhe o verificador.

Arquitetura e evidências do atestador

Nesta seção, abordamos como uma instância de VM confidencial como atestador fornece evidências de identidade resistentes a adulterações.

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 que estabelece outras relações de confiança. Uma raiz de confiança fornece funções criptográficas, é resistente a adulteraçõ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). A TCB é uma coleção de hardware e software em uma VM convidada e no host dela, responsável por tarefas como isolamento de ambiente (por mecanismos como criptografia de memória e isolamento de hipervisor) e 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 as medições da raiz de confiança para armazenamento e as agrupa em um pacote de evidências assinado, chamado de relatório de cotação ou 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 as evidências sejam recentes e protegidas contra ataques de repetição.

  Termo-chave: um ataque de repetição ocorre quando um usuário de má-fé copia evidências que verificam uma identidade e as usa para ter acesso ilegítimo a recursos. Uma maneira de combater ataques de repetição é 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 comprova a identidade precisa incorporar o valor de uso único às evidências antes que elas sejam enviadas. Se um usuário de má-fé tentar usar evidências roubadas para acessar recursos, é provável que ele falhe porque o valor de uso único 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 AMD SEV atesta o ambiente e a configuração usando medições baseadas em vTPM de VM protegida. O processador seguro da AMD e a SEV da 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 de VM protegida

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

Para saber quais medições são registradas 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 dela por meio do processador seguro da 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 em vTPM de VM protegida.

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

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

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

• Raiz de confiança para relatórios:

  • Medições de inicialização: o processador seguro da AMD, que usa a chave de endosso de chip de versão (VCEK, na sigla em inglês) 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 processador seguro da AMD, consulte o registro de medição do AMD SEV-SNP.

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

Intel TDX

Uma instância de VM confidencial com o Intel TDX atesta o ambiente e a configuração dela por meio do 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 ambiente de execução (RTMR, na sigla em inglês).

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, na sigla em inglês) e registros de medição de ambiente de execução (RTMR, na sigla em inglês)

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

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

Raízes de confiança de hardware e software

Seu nível de isolamento do hipervisor do host depende de a cadeia de atestado estar ancorada em uma raiz de confiança de software ou em uma raiz de confiança de hardware:

• Raiz de confiança de software (dependente do hipervisor): a cadeia de confiança começa no software gerenciado pelo provedor de nuvem. O firmware virtual do convidado atua como a raiz de confiança para medição, e o vTPM da VM protegida do hipervisor do host atua como a raiz de confiança para armazenamento e relatórios. No Google Cloud, os dois componentes são controlados pelo Google.

• Raiz de confiança de hardware (isolada por hipervisor): a cadeia de confiança começa em subsistemas de segurança de CPU dedicados fora do controle do provedor de nuvem: o processador seguro AMD ou o módulo Intel TDX. Esse hardware mede o estado inicial e assina relatórios ou cotações de atestado usando chaves fundidas ou derivadas no processador. Na CPU, os componentes de software subsequentes na cadeia de inicialização (incluindo o firmware virtual e o carregador de inicialização) são executados dentro da memória protegida por criptografia de hardware e controles de acesso. Isso remove o hipervisor do host da raiz de confiança: mesmo que um usuário malicioso comprometa o hipervisor, ele não poderá modificar as medições protegidas por hardware nem falsificar um relatório de atestado.

Dependendo da configuração da instância de VM confidencial, um ou mais dos mecanismos a seguir podem ser usados para medir e atestar o estado de inicialização:

• vTPM da VM protegida (raiz de confiança do software): o vTPM da VM protegida é necessário para o atestado com o AMD SEV. As instâncias de VM confidencial AMD SEV-SNP e Intel TDX ainda contam com o vTPM de VM protegida, mas o uso dele como parte da sua cadeia de confiança é opcional.

  O vTPM da VM protegida registra as medições do carregador de inicialização, do kernel e do espaço do usuário em PCRs. Como é gerenciado pelo hipervisor do host, ele mantém o estado em todas as reinicializações para recursos como o bloqueio de chaves.

• Processador seguro AMD (raiz de confiança de hardware): disponível em instâncias de VM confidencial AMD SEV-SNP. Antes da inicialização do convidado, o processador seguro da AMD mede o estado de inicialização inicial (incluindo o firmware virtual) no registro MEASUREMENT e assina um ATTESTATION_REPORT com o VCEK.

  É possível verificar o relatório de atestação do processador seguro da AMD por conta própria ou combiná-lo com uma cota de vTPM de VM protegida para verificar o restante da cadeia de inicialização.

• Registros de medição do Intel TDX (raiz de confiança do hardware): disponíveis em instâncias de VM confidencial do Intel TDX. O módulo Intel TDX registra medições de firmware virtual no momento da criação na Medição do Domínio de Confiança (MRTD, na sigla em inglês) e estende as medições do carregador de inicialização, do kernel e do espaço do usuário para os Registros de Medição em Tempo de Execução (RTMR, na sigla em inglês) dentro do domínio de confiança isolado, sem precisar de um vTPM.

  É possível verificar a cotação do módulo Intel TDX por conta própria para cobrir toda a cadeia de inicialização. Um vTPM de VM protegida está presente nas instâncias de VM confidencial do Intel TDX para uso em recursos de TPM, como vedação de chaves.

Registros de medição

As raízes de confiança da VM confidencial oferecem armazenamento protegido e resistente a adulterações para medições na forma de registros de medição (MRs). O nome desses registros de medição muda de acordo com a tecnologia de computação confidencial em uso:

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

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

• AMD SEV-SNP: o registro de inicialização MEASUREMENT. Ela fica dentro do processador seguro da AMD.

  Os PCRs dentro do 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 domínio de confiança (MRTD, na sigla em inglês) no momento da criação e os registros de medição no momento da execução (RTMR, na sigla em inglês).

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

Somente uma raiz de confiança pode alterar um valor de registro. Os registros de medição normalmente 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 inicialização ou de tempo de build de uma VM, uma raiz de confiança normalmente grava diretamente no registro e o torna imutável pelo restante da vida útil do TEE.

Os componentes carregados posteriormente 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 um 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 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, ela pode dificultar a definição de políticas com base em valores de registro de medição específicos. Isso ocorre 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 o trabalho de manutenção. Se você precisar basear a política em valores de registro de medição, tente selecionar valores de registro 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 log de eventos gerado pela TCB. Um verificador precisa primeiro realizar uma reprodução do log de eventos para verificar a integridade do log em relação aos registros de medição. Após a verificação, 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 que registra os eventos de medição que ocorrem.

Esses registros de eventos têm as seguintes finalidades:

• Um verificador pode reproduzir logs 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 pode aumentar a confiança de que o log de eventos e o processo de inicialização da instância de VM confidencial não foram adulterados.

• Após a repetição, um verificador pode analisar os logs de eventos para comparar as evidências com as políticas de atestação. 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 atestação bem-sucedido 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 para verificar	Tipo de registro	Caminho do SO convidado para repetição do log de eventos
AMD SEV, AMD SEV-SNP, Intel TDX	Registros de configuração da plataforma (PCRs) do vTPM	Log 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, na sigla em inglês)	/sys/firmware/acpi/tables/data/CCEL

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

Cotações e relatórios de atestado

A raiz de confiança para relatórios oferece proteção de integridade e autenticidade para os resumos armazenados no registro de medição, assinando 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, em seguida, gera um hash do resultado com o mesmo algoritmo de hash usado para o banco de PCR para criar 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 particular do vTPM para criar uma citaçã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 feitas antes da execução da UEFI da instância de VM confidencial.

  Esse resumo, outros dados da VM e um valor de uso único opcional fornecido por um verificador são colocados em uma estrutura ATTESTATION_REPORT assinada pela chave de endosso de 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 a 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 valor de uso único opcional fornecido por um verificador em uma estrutura TDREPORT_STRUCT.

  A criação de uma cotação é 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 secrets criptográficos fundidos na CPU. Em seguida, o enclave de citação dentro da CPU gera uma chave de atestado particular, que é assinada com a chave de certificação de provisionamento. O TDREPORT_STRUCT é assinado com a chave de atestado particular para criar uma cotação.

  Para detalhes sobre a estrutura TDREPORT_STRUCT, consulte Especificação da arquitetura base 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 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, na sigla em inglês)

Para 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 convidado pode recuperar esse certificado individualmente solicitando-o ao vTPM com um software como o 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 softwares como go-sev-guest e go-tdx-guest.

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

• A identidade do emissor do certificado, que pode ser AMD, Google ou Intel.

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

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

• Somente atestado 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 AMD SEV-SNP, essa evidência é o ID da plataforma. Para o Intel TDX, a evidência é o manifesto da plataforma.

Firmware

Para atestado de hardware, as aprovações de inicialização de firmware estão disponíveis diretamente nas instâncias de VM ou podem ser baixadas 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 AMD ou o módulo Intel TDX gera um hash do binário do firmware antes de ser executado. Esse resumo SHA-384 é armazenado no campo MEASUREMENT para AMD SEV-SNP e no MRTD para Intel TDX.

É possível usar esse resumo para fazer o download de um endosso de inicialização 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 no endosso.

Além da verificação de firmware, é possível usar determinadas propriedades em um endosso de inicialização para aplicar uma política de acesso, como o número mínimo de 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.

Análise e repetição do log de eventos do verificador

Além de verificar diretamente as evidências fornecidas por um atestador, um verificador pode reproduzir um log 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 atestação. Em seguida, ele preenche esse registro simulado usando eventos de um log de eventos. Se o valor final do registro simulado corresponder ao valor armazenado no registro de medição real equivalente, isso aumenta a confiança de que o log 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 em que um verificador ou uma parte confiável pode basear a política.

Criar 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 logs de eventos, recomendamos o uso de softwares estabelecidos, como o go-eventlog, para ajudar a evitar armadilhas comuns, como a vulnerabilidade EventType para os formatos de log de eventos do Trusted Computing Group e da Computação Confidencial.

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

O exemplo a seguir tem eventos selecionados de um log de eventos do vTPM do Ubuntu 24.04, que são medidos no PCR 0. O log 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 do 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 dela 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 é criptografado com hash SHA-256 novamente e armazenado no registro. O resumo hexadecimal SHA-256 do PCR 0 agora é 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. O mesmo processo é usado para o evento EV_NONHOST_INFO. O resumo hexadecimal 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 de log de eventos, porque ele deriva os resumos de eventos de valores conhecidos. Ao criar uma repetição de log de eventos adequada, leia os resumos do log 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 parte confiável

Dependendo do uso do modelo de passaporte ou do modelo de investigação de histórico para contratação, a parte confiável recebe os resultados da atestação do atestador ou do verificador.

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

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

1. Adicione o verificador como um provedor OIDC a um pool de Identidade da carga de trabalho. Depois disso, a conta de serviço anexada à carga de trabalho da instância de VM confidencial pode atuar 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 receba 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 passar para se autenticar como principal.

   Em seguida, é possível conceder 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 são compatíveis com identidades federadas, é possível fornecer acesso a recursos por meio da identidade temporária de conta de serviço.

Como alternativa à federação de identidade da carga de trabalho, é possível escrever um código para analisar diretamente as declarações de um token de atestado. Para ver um exemplo, consulte Atestado remoto do vTPM em máquinas virtuais confidenciais.