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:
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.
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
Faça uma solicitação de convidado estendida ao processador seguro da AMD para recuperar um relatório de atestado.
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.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
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
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}"
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.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
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:
Alocar uma nova mensagem
VMGoldenMeasurement
.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
De uma recomendação de lançamento, descompacte o valor
serialized_uefi_golden
em umVMGoldenMeasurement
. Para exemplos, consulte a implementação em Go ou a compilação protoc deendorsement.proto
para outro idioma que ofereça suporte a buffers de protocolo.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.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
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.