An Azure service that is used to provision Windows and Linux virtual machines.
Retrieve the raw measured-boot evidence from Linux’s binary TCG event-log interface, but do not expect standard Azure Trusted Launch to provide Microsoft-signed evidence binding the quote’s attestation key to the VM’s full Azure Resource Manager resource ID.
Retrieve the complete raw measured-boot log
On Ubuntu, mount securityfs if necessary and copy the binary log without transforming it:
sudo mountpoint -q /sys/kernel/security ||
sudo mount -t securityfs securityfs /sys/kernel/security
sudo test -r /sys/kernel/security/tpm0/binary_bios_measurements
sudo cat /sys/kernel/security/tpm0/binary_bios_measurements \
> measured-boot.tcg
sha256sum measured-boot.tcg
measured-boot.tcg is the raw binary TCG event log used to replay the boot PCR measurements. It is not the text output from journalctl, Azure Boot Diagnostics, dmesg, or the IMA runtime log. Microsoft’s attestation guidance distinguishes the TCG boot log from the IMA log and requires the TCG log when verifier policy evaluates boot PCRs.^1^
If that exact path is absent, inspect the interfaces actually exposed by the running kernel:
sudo find /sys/kernel/security -type f \
\( -name binary_bios_measurements -o -name ascii_bios_measurements \) \
-print
ls -l /sys/kernel/security/tpm*
Do not substitute ascii_bios_measurements when byte-for-byte raw evidence is required. If no binary interface exists, the available Microsoft documentation does not specify an Azure API that exports the guest’s complete raw log; capture the missing path, kernel version, and TPM devices and open an Azure support request for that exact image build.
The event log must be verified by replaying its ordered events and comparing the result with PCR values covered by a fresh quote. The log alone is not signed evidence. Trusted Launch’s vTPM measures the boot chain, and Microsoft Azure Attestation uses those measurements for remote boot-integrity checks.^2^
Identity binding: full Azure ID is not documented
For an ordinary Trusted Launch VM on Standard_D2as_v5, the published Microsoft evidence does not document a certificate or claim that binds all of the following together:
- The attestation key that signed a fresh TPM quote.
- The VM’s complete ARM resource ID:
/subscriptions/[Subscription ID] ID]/resourceGroups/[Resource Group] Group]/providers/Microsoft.Compute/virtualMachines/... - A Microsoft signature over that binding.
Trusted Launch can produce a Microsoft Azure Attestation token containing signed Secure Boot and PCR claims, such as secureboot and x-ms-azurevm-attested-pcr-values.pcr0 through pcr7.^3^ Azure Attestation receives evidence, validates it, and produces cryptographic proofs for relying parties, but its Trusted Launch description does not specify a full ARM-resource-ID claim or an AK certificate carrying that resource ID.^4^
Do not treat x-ms-azurevm-vmid as the full Azure resource ID. Microsoft documents it as a VM ID GUID, and that documentation applies to confidential VM guest attestation, not standard Trusted Launch.^5^
Do not import the confidential-VM endorsement model
Confidential VMs have a separately documented chain:
- Reserved vTPM AK at handle
0x81000003. - Azure-issued vTPM AK certificate.
- Hardware report containing the AK public key.
- Hardware-vendor certificate chain.
That design explicitly applies to Azure confidential VMs.^6^ It is not evidence that the same AK-certificate and hardware-report chain is exposed on a Standard_D2as_v5 Trusted Launch VM, nor does the documented confidential-VM chain place the full ARM resource ID in the AK certificate.
Therefore, if the verifier requires cryptographic binding to the complete ARM ID, an additional application/control-plane binding protocol is required—for example, recording the expected resource ID against an independently authenticated enrollment and binding each transaction to a fresh nonce. That extra mapping is your protocol evidence, not a Microsoft-signed AK-to-resource-ID endorsement.
References