Verificar o firmware de uma instância de VM confidencial

O firmware de todas as instâncias de VM confidencial é UEFI e se baseia no projeto Open Virtual Machine Firmware. O firmware é gerenciado pelo Google para manter a segurança, o desempenho e a estabilidade.

O firmware gerenciado pelo Google também garante a consistência dos valores armazenados nos registros de medição na raiz de confiança de uma instância de VM confidencial. Isso ajuda a evitar que as cargas de trabalho de Computação confidencial sejam bloqueadas pela verificação de atestado quando o firmware de uma instância de VM confidencial é atualizado.

Para ajudar a estabelecer que sua instância de VM confidencial está sendo executada em um firmware genuíno gerenciado pelo Google, faça o seguinte:

  • Recupere um endosso de inicialização assinado pelo Google em instâncias de VM confidencial com AMD SEV-SNP ou Intel TDX ativado. Uma aprovação de lançamento contém medidas pré-calculadas e assinadas relacionadas ao firmware.

  • Verifique o endosso de inicialização comparando com medidas específicas da arquitetura.

  • Verifique se o binário da UEFI é endossado pelo Google e não foi modificado.

Além do atestado remoto, é possível incluir a verificação de firmware como parte da sua política de segurança, que determina se uma instância de VM confidencial deve ter acesso a recursos protegidos.

Recuperar endossos de lançamento

É possível recuperar as recomendações de lançamento usando as ferramentas do Google ou as suas próprias.

Recuperar endossos de lançamento com as ferramentas do Google

Para recuperar uma declaração de inicialização de uma instância de VM confidencial AMD SEV-SNP ou Intel TDX usando ferramentas do Google:

  1. Use SSH para se conectar à instância de VM confidencial.

  2. Use Go-TPM-Tools (AMD SEV-SNP ou Intel TDX) ou SEV Guest (AMD SEV-SNP) para recuperar um relatório de atestado e os certificados associados.

  3. Use gcetcbendorsement para extrair a aprovação do UEFI do atestado e armazená-la em um arquivo. Em seguida, verifique se a recomendação tem origem no Google e se a medição do relatório de atestado está entre as medições assinadas.

Recuperar endossos de lançamento com suas próprias ferramentas

Para recuperar uma recomendação de lançamento usando suas próprias ferramentas, siga estas instruções.

AMD SEV-SNP

  1. Faça uma solicitação de convidado estendida ao processador seguro da AMD para recuperar um relatório de atestado.

  2. Extraia a medição de 384 bits do relatório armazenada no deslocamento 90h. Para mais informações, consulte SEV Secure Nested Paging Firmware ABI Specification, capítulo 7.3, tabela 22.

  3. Use a medição de 384 bits para baixar uma recomendação de lançamento de referência serializada do seguinte bucket do Cloud Storage:

    gs://gce_tcb_integrity/ovmf_x64_csm/sevsnp/384_BIT_MEASUREMENT.binarypb

  4. Decodifique o arquivo BINARYPB com uma ferramenta como protoc, usando a definição de mensagem VMLaunchEndorsement:

    message VMLaunchEndorsement {
  bytes serialized_uefi_golden = 1;
  bytes signature = 2;
}

Outros locais de apoio ao lançamento

A aprovação de lançamento também pode ser disponibilizada em uma tabela GUID no mecanismo de entrega de certificados SEV-SNP da AMD. Ele tem o seguinte GUID:

9f4116cd-c503-4f5a-8f6f-fb68882f4ce2

A tabela GUID está documentada na especificação do bloco de comunicação do hipervisor convidado da AMD, na seção "Solicitação estendida do convidado SNP".

Também pode haver referências a locais locais e remotos da aprovação de inicialização no registro de eventos do cliente de PC do Trusted Computing Group, encontrado no evento SP800-155, conforme documentado em TCG PC Client Platform Firmware Profile Specification Version 1.06 Revision 52.

Intel TDX

  1. Faça uma entrada de relatório configfs-tsm:

    name=/sys/kernel/config/tsm/report/report0
mkdir "${name}"
cat "${your_nonce_file}" > "${name}/inblob"
cat "${name}/outblob" > "${your_quote_destination}"

  2. Extraia a medição do domínio de confiança de 384 bits do MRTD da cotação armazenada no deslocamento b8h (para o módulo TDX 1.5). Para mais informações, consulte a biblioteca de cotação do DCAP da TDX.

  3. Use a medição de 384 bits para baixar uma recomendação de lançamento de referência serializada do seguinte bucket do Cloud Storage:

    gs://gce_tcb_integrity/ovmf_x64_csm/tdx/384_BIT_MEASUREMENT.binarypb

  4. Decodifique a confirmação de lançamento com uma ferramenta como protoc, usando a definição de mensagem VMLaunchEndorsement:

    message VMLaunchEndorsement {
  bytes serialized_uefi_golden = 1;
  bytes signature = 2;
}

Exemplo de recomendação de lançamento

Uma declaração de lançamento é semelhante ao exemplo a seguir:

VMLaunchEndorsement:
serialized_uefi_golden: "SERIALIZED_BYTES"
signature: "LAUNCH_ENDORSEMENT_SIGNATURE_BYTES"

Medições douradas do UEFI

O campo serialized_uefi_golden contém uma versão serializada de vários valores, conforme definido pelo seguinte buffer de protocolo:

message VMGoldenMeasurement {
  google.protobuf.Timestamp timestamp = 1;

  // The changelist number this UEFI was built from.
  uint64 cl_spec = 2;

  // DER format certificate of the key that signed this document.
  bytes cert = 4;

  // SHA-384 digest of the UEFI binary without TEE-specifics about launch.
  bytes digest = 5;

  // A sequence of PEM-encoded certificates of keys used in cert in Root ...
  // final intermediate order. The last certificate will have a signed cert.
  bytes ca_bundle = 6;

  VMSevSnp sev_snp = 7;

  VMTdx tdx = 8;
}

O campo VMSevSnp na mensagem VMGoldenMeasurement é definido pelo seguinte buffer de protocolo:

message VMSevSnp {
  // The Google-reported security version number of this UEFI on SEV-SNP.
  uint32 svn = 1;

  // Expected MEASUREMENT report field values given [key]-many VMSAs at launch.
  map<uint32, bytes> measurements = 2; // bytes size 48

  // A UUID that Google uses for its CVM UEFIs
  bytes family_id = 3; // size 16

  // A UUID to name this specific release of the UEFI image. This is randomly
  // generated with each build.
  bytes image_id = 4; // size 16

  // The launch policy that verifiers should expect with this UEFI.
  uint64 policy = 5;

  // Optional. PEM-encoded certs for Identity..Author..Root. If a singleton,
  // only an Id-key is used.
  bytes ca_bundle = 6;
}

O campo VMTdx na mensagem VMGoldenMeasurement é definido pelo seguinte buffer de protocolo:

message VMTdx {
  message Measurement {
    // The amount of RAM in GiB provided to the VM. This is relevant to the
    // construction of the measured TDHOB page that includes memory region
    // resource attributes.
    uint32 ram_gib = 1;
    // If true, EFI_UNACCEPTED_MEMORY not presented to guest.
    // All memory is accepted by the firmware. Relevant to the TDHOB page
    // since the resource attribute will include
    // EFI_RESOURCE_ATTRIBUTE_NEEDS_EARLY_ACCEPT.
    bool early_accept = 2;
    // The SHA-384 digest of the measurement operations for the VM at launch.
    bytes mrtd = 3;
  }
  // The Google-reported security version number of this UEFI on TDX.
  uint32 svn = 1;

  // Expected MRTD report field values given legal configurations.
  repeated Measurement measurements = 2;
}

Para descompactar e decodificar esses valores do serialized_uefi_golden field com suas próprias ferramentas, siga estas etapas:

  1. Alocar uma nova mensagem VMGoldenMeasurement.

  2. Faça o unmarshal de serialized_uefi_golden na mensagem.

Se preferir, use o comando gcetcbendorsement inspect .

Verificar recomendações de lançamento

Depois de recuperar um endosso de lançamento, verifique a assinatura dele e integre as medições à sua política de segurança, quando apropriado.

Verificar uma assinatura de endosso de lançamento

É possível verificar a assinatura de uma declaração de inicialização incluindo o certificado da chave raiz da base de computação confiável do Confidential Computing do Compute Engine nas suas âncoras de confiança.

O campo cert do VMGoldenMeasurement na confirmação de inicialização contém um certificado X.509v3 codificado em DER da chave pública da chave de assinatura de confirmação. O certificado é assinado pela chave raiz.

Use gcetcbendorsement para mostrar quais comandos openssl executar para verificar a assinatura. Por exemplo, se você executar o comando:

gcetcbendorsement verify --show LAUNCH_ENDORSEMENT_FILENAME.binarypb

Você receberá uma resposta semelhante ao seguinte exemplo:

openssl verify -CAfile <(openssl x509 -outform pem -in <(curl https://pki.goog/cloud_integrity/GCE-cc-tcb-root_1.crt)) \
    <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert) \
    && \
    openssl pkeyutl -verify -pkeyopt rsa_padding_mode:pss \
        -pkeyopt rsa_pss_saltlen:32 -pkeyopt digest:sha256 -pkeyopt rsa_mgf1_md:sha256 -pubin \
        -inkey <(openssl x509 -pubkey -nocert -outform pem -in <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert)) \
        -sigfile <(gcetcbendorsement inspect signature "LAUNCH_ENDORSEMENT_FILENAME.binarypb") -keyform PEM \
        -in <(openssl dgst -sha256 -binary <(gcetcbendorsement inspect payload "LAUNCH_ENDORSEMENT_FILENAME.binarypb")

Se preferir usar suas próprias ferramentas, substitua os comandos gcetcbendorsement inspect usados na resposta pela sua própria lógica de extração de buffer de protocolo para os campos nomeados da mensagem VMGoldenMeasurement desserializada.

Verificar as medições de endosso de lançamento

O código de exemplo de como uma recomendação de lançamento é criada está disponível no repositório do GitHub gce-tcb-verifier. Use isso para entender como o Google derivou as medições do UEFI e para incorporar medições relevantes à sua política de segurança.

Por exemplo, você pode verificar se o firmware foi assinado pelo fornecedor dele e comparar as medições específicas da arquitetura com valores pré-calculados e assinados fornecidos na mensagem VMLaunchEndorsement.

Embora o firmware virtual do Compute Engine seja atualizado na redefinição, o valor de PCR0 não muda. Por isso, o valor svn do firmware na medição assinada pode ser diferente do EV_S_CRTM_VERSION medido para PCR0, e o evento EV_POST_CODE no resumo do blob de firmware é ignorado.

Verificar o binário UEFI de uma instância de VM confidencial

  1. De uma recomendação de lançamento, descompacte o valor serialized_uefi_golden em um VMGoldenMeasurement. Para exemplos, consulte a implementação em Go ou a compilação protoc de endorsement.proto para outro idioma que ofereça suporte a buffers de protocolo.

  2. Recupere o valor de resumo de VMGoldenMeasurement. Esse é o resumo SHA-384 do binário UEFI em que a instância de VM confidencial está sendo executada.

  3. Use o resumo SHA-384 para fazer o download do binário de firmware no seguinte bucket do Cloud Storage:

    gs://gce_tcb_integrity/ovmf_x64_csm/UEFI_BINARY_DIGEST.fd

  4. Se for um URL válido e o firmware for baixado, execute um hash SHA-384 no binário do firmware. Se ele corresponder ao resumo da medição de referência, o firmware em execução na instância de VM confidencial estará inalterado.