Beyond Confidential: Establishing Trust in Your Computing Environment
Co-Author: Kirk SwidowskiConfidential Computing is an evolving security technology and the term is often used in industry to showcase broad applicability of a trustworthy execution environment. In this blog, we would like to clarify how confidential computing is defined in Google Cloud, key components integral to this technology, and explore how it can be used to establish trustworthiness. What is Confidential Computing?At a high level, confidential computing is a term for an environment designed to protect the confidentiality of code and data from unauthorized access. To build such an environment, we need three key components:A Threat Model: This is used to identify and define the unauthorized or untrusted entities, including hardware and software components. Access Control: The ability to limit access to protected code and data from those untrusted components. Attestation: A mechanism that proves all those limitations are in place.In Google Cloud, we offer confidential computing products and services built on AMD and Intel platforms, each with different levels of confidentiality and security guarantees. The AMD SEV-SNP and Intel TDX white papers provide more details on their respective threat models and security features.AMD SEV: Our Confidential VMs using AMD SEV use hardware-based memory encryption to isolate VM memory from the host workload, which can be attested via a Google-managed vTPM. AMD SEV-SNP and Intel TDX: These technologies provide memory and CPU state confidentiality and integrity protections, significantly reducing the attack surface. They also introduce the critical capability of hardware-rooted attestation. Confidentiality vs. TrustworthinessTrustworthiness is an assessment to determine if we can trust an underlying execution environment with confidential code or data. Confidential Computing technologies provide new capabilities to help establish that trust, but are they enough on their own?In any trust relationship, we either establish trust based on the direct familiarity with the other party or have them verified by an already-trusted third party. To establish trustworthiness in a computing environment, multiple hardware and software stacks must be trusted. It's impossible to find a single entity to represent this whole system.Instead, trustworthiness must be established by creating a chain of trust. This chain starts from a hardware root of trust and requires verifying every software and hardware component that impacts the system's trustworthiness.AMD SEV-SNP and Intel TDX facilitate an extension of the chain of trust to include the hardware itself. This enables the trusted execution environment to function without reliance on the cloud provider's underlying software stack. Both provide hardware-rooted attestation reports, signed by the CPU vendor, that allow customers to verify the environment's state without having to trust the cloud provider itself. So, now that we have a signed attestation report, how do we verify it? The Lifecycle of Establishing TrustA customer uses cloud APIs to create a Confidential VM. Once the VM is created, the customer can request an attestation report and establish trust after verifying it. This verification step is critical, often overlooked, and may differ based on the use case.There are three main categories to verify in any attestation report. 1. Authenticity of the ReportHardware-rooted reports include signatures that can be verified using trusted certificate chains from the CPU vendors, ensuring the hardware itself is legitimate. Such validation will ensure that the trusted execution environment is running on genuine hardware and not emulated by any malicious actor. Customers must also verify the report's freshness by checking that a "nonce" value in the report matches the "nonce" they provided when requesting the report. 2. Platform ConfigurationThe report includes specific information about the underlying platform, which is needed to evaluate its trustworthiness. This configuration mainly includes:Security feature configurations that impact confidential computing capabilities. Security Version Numbers (SVNs) for platform firmware and microcode (in AMD SNP reports). SVN for the CPU and firmware, plus the cryptographic hash of the TDX Module loaded on the system (in Intel TDX reports). 3. Guest ConfigurationThe report also captures information specific to the Confidential VM itself:Initial Memory Measurement: A measurement of the guest UEFI firmware image and all static configuration as part of that image loaded into the guest VM memory when the CVM was built. Google signs the firmware used by our Confidential VMs, which can be verified with Google's attestation tools. CVM Configuration Policy: This defines options that impact CVM security, such as enabling debug capabilities, allowing/disallowing migration, and the behavior of certain CPU features. Beyond the Initial BootHardware-rooted attestation reports provide information on the CVM's initial state. This state is the root of trust used to continue verifying the runtime state. Customers must use established security practices to verify runtime components. Confidential VM attestation provides an event log and measurements of all binaries loaded during boot. These measured boot hash values can be accessed via the Google-managed vTPM for AMD platforms or through hardware-rooted runtime measurement support on Intel TDX platforms. AMD platforms also support trusted vTPM through AMD's Secure VM Service Module (SVSM) SW extension running within the Confidential VM. Challenges in Securing the FoundationLike all software and hardware, components in the confidential computing trusted computing base (TCB) will have vulnerabilities. How quickly these can be addressed introduces unique challenges.Traditionally, cloud vendors patch their fleets based on their own risk assessment. With confidential computing, the risk assessment might be different for each user. The owner of the confidential environment should decide how to handle vulnerabilities based on their specific use case. For example, a third-party attestation service may delay enforcing a new TCB reference number to prevent production outages, even after a patch is available.Furthermore, new firmware updates introduce new features. Intel TDX has optional features such as TDX Live Migration, Performance Monitoring Capabilities and (soon) TDX Connect. Similarly, AMD SNP will have SEV-TIO (Trusted IO) and may have additional software components (such as Secure VM Service Module for SEV-SNP Guests) as part of its trusted computing base. Every new feature or software component added to the trusted computing base adds risks. While these features may have no known security issues, we believe unused features should not be enabled in Confidential VMs until they are well-reviewed or understood by both the cloud provider and the customers. The Customer's Role: Verifying Complex AttestationThe previous points highlight a crucial fact: attestation verification is complex. As technologies like Intel TDX evolve, increases in the feature set can also increase the attack surface.Because confidential computing reduces or removes the cloud provider from the trust boundary, it is the customer's responsibility to understand the default security and confidentiality guarantees provided. For use cases requiring a more strict and explicit security policy, customers must set their own attestation appraisal policy. This policy should consider:Auditing Unused Features: Customers must make sure features they don't use or would impact the expected confidential computing guarantees —such as debug capabilities or live migration—are explicitly disabled in the attestation report. While cloud providers will update to the latest firmware, they may not use all new features. Customers should expect the attestation to reflect only the set of features actually in use and nothing more. Defining an SVN Policy: Customers should create their own policy about what SVNs to trust. This includes understanding the difference between TCB enforcement (the platform refusing to load a module with an old SVN) and TCB recovery (the process of patching and updating your trust policy). Attestation Verification ToolsGoogle provides guidance on how Confidential VM attestation can be used to verify trustworthiness of different confidential computing environments we support. We provide open source libraries for TDX and SNP that our customers can use to build their own attestation verification tools. Through those tools and libraries, customers can verify and validate the attestation report against the customer provided attestation policy. Each Confidential VM attestation report includes the measurement of the initial firmware loaded into the Confidential VM. We publish the binaries and launch endorsement for those firmware images that customers can use to verify the CVM firmware image through their own tools or Google provided tools. Conclusion: Our Commitment and Your Next StepsAt Google, we are continuously working to improve the security posture of our confidential computing products in collaboration with CPU vendors. Customers should review the limitations of current offerings and work with providers (CPU vendors, Google or any 3rd party service provider depending on the use case) to address their concerns. Together, we can remove the blind trust inherent in traditional computing and create a more secure future for your valuable computation needs. Attestation Reference for Building Custom PoliciesAt Google, we continuously harden and maintain our Confidential VM infrastructure to protect customers from known vulnerabilities and security risks. These protections are applied automatically when you run Confidential VMs and use Google's attestation tools.As part of our commitment to transparency, we provide our reference configuration for confidential computing below. We also offer details on selected claims to empower customers who wish to build their own attestation verification policies. Reference Values for Intel TDX and AMD SNP Attestation verification through Google, CPU vendor or 3rd-party provided services verifies the genuinity of the attestation but might not validate the actual attestation claims. Below, we have provided a few selected attestation claims with the current reference values that confidential computing customers can use to build their own attestation policy.Alternatively, Intel provides an attestation verification service, Intel Trust Authority, that customers can use to build an attestation appraisal policy and verify attestation claims for Google Cloud Confidential VMs. Verification of SVN numbers for Intel TDX:Intel provides regular updates on the trusted computing base changes and required actions through Trusted Computing Base Recovery Attestation (TCBR) updates. Unfortunately, it is not easy to map the cpu_svn and isv_svn numbers to specific CPU families after each TCBR update. Intel provides Intel DCAP SGX attestation verification library that provides a single high-level function, and the library internally performs the entire TCB comparison, including all SVN checks. The verification function will fail if the TCB is not up to date. But by default, this method will only verify the TCB after any TCBR enforcement which is usually 12 months after any security update is publicly disclosed. At Google, we assess the risk of all known issues and update the platform SVN numbers with the urgency appropriate to the associated risks. Google attestation tools validates that the latest SVN number available in our production environment automatically. Alternatively, we can query the latest TCB version available for the current processor and enforce the minimum TCB versions before the TCBR enforcement. The primary method for retrieving this information is by querying Intel's Provisioning Certification Service (PCS) or a trusted compatible caching service. We can query the Intel PCS service if we know the processor identification number, fmspc (Family, Model, Stepping, Platform, Customization). The fmspc number can be requested from Intel with a REST API call to Intel PCS certification API by using the PCE SVN (Provisioning Certification Enclave Security Version Number), PCE ID (Provisioning Certification Enclave Identifier), CPU SVN and Encrypted PPID (An encrypted hardware identifier) values found in the TDX Attestation Quote.TDX Attestation Quote (reduced version as reference) Attestation Field Value Description tee_tcb_svn 0x080108 (Might change) Describes the TCB of TDX when the TD was launched. Byte 0: TDX Module minor SVN Byte 1: TDX Module major version Byte 2: Contains the microcode SVN on a non-TD Preserving update of the TDX Module Remaining bytes are not used in the current TDX module version and set to 0. Currently we are using TDX Module 1.5.09. Intel publishes the SVN numbers for all TDX Module binary releases at https://github.com/intel/tdx-module/releases seam_attributes 0x0 Not used and set to zero for the current TDX module td_attributes 0x10000000 This TD is configured as : - Debugging is disabled for this TD - Disable EPT violation conversion to #VE on guest TD access of PENDING pages - Migration is not allowed for this TD - Supervisor Protection Keys are disabled - Perfmon and PERF_METRICS are disabled. - Key Locker is disabled No other security features are enabled through these settings. mr_td #HASH Measurement of the guest firmware image loaded at TD build. Google Cloud provides tools to verify guest firmware. rtmrs[4] #HASH Run time measurements that can be used to validate the measured boot event log. report_data HEX DATA User provided data or nonce value. Customer should verify if this nonce value is matching with the nonce value provided during TDQuote request cpu_svn 0x600FF041BFF0808 Security Version of HW components in the TDX TCB (raw value). attributes 0xE70000000000000015 SGX Security attributes which can configure if the SGX enclave is in debug mode, support 64bit, etc... The most important information here is to verify that SGX is not running in debug mode (Bit 1 must be 0) isv_svn 6 Security Version of the enclave. * For more information and the complete list of the attestation claims, please refer to Intel TDX Module 1.5 Specification. An example REST API call will look like this:GET /sgx/certification/v4/pckcert?encrypted_ppid=...&pcesvn=...&pceid=...&cpusvn=... The fmspc will be in the SGX-FMSPC HTTP response header. With the fmspc value, a developer can make a REST API call to the Intel PCS and get the new TCB information earlier than the TCBR enforcement date. The relevant endpoint for retrieving TCB information is typically in the format:GET /sgx/certification/v4/tcb?fmspc=<fmspc_value>&update=earlyThe response from the PCS is a JSON object that contains detailed TCB information for the specified platform. This includes an array of tcbLevels, where each level represents a different certified state of the TCB. Within each tcbLevel, the tcb object contains the cpusvn. An example JSON response will look like this:{ "tcbInfo": { "fmspc": "0123456789ab", "tcbLevels": [ { "tcb": { "sgxtcbcomp01svn": 0, "sgxtcbcomp02svn": 1, ... "pcesvn": 5, "cpusvn": "0a0b0c0d0e0f10111213141516171819" }, "tcbDate": "2025-10-26T10:00:00Z", "tcbStatus": "UpToDate" }, ... ] }, ...} AMD SNP Attestation Report (reduced version as reference)A limited set of attestation claims included in the SNP Attestation report can be found below. Attestation Field Value Description policy 0x30000 - PAGE SWAPPING is not disabled. - Ciphertext hiding for the DRAM is not enabled. - Allow Running Average Power Limit (RAPL). - Allow AES 128 XEX or AES 256 XTS for memory encryption. - CXL cannot be populated with devices or memory. - Guest can be activated on multiple sockets. - Debugging is disallowed. - Migration agent is disallowed. - SMT is allowed. - ABI Minor/Major is not set for this VM. current_tcb 0xDB19000000000004 Security Version Numbers (SVNs) of the currently executing platform firmware and microcode platform_info 0x25 - SEV-TIO is disabled. - Alias detection has completed since the last system reset and there are no aliasing addresses. - Ciphertext hiding is not enabled for the DRAM. - RAPL feature is disabled. - Platform is using error correcting codes (ECC) for memory. - TSME is disabled in the system. - SMT is enabled in the system. report_data NONCE User provided data or nonce value. Customer should verify if this nonce value matching with the nonce value provided during SNP attestation report request measurement #HASH Hash of the guest firmware image loaded at SNP VM build. Google Cloud provides tools to verify guest firmware. reported_tcb 0xDB19000000000004 Hypervisor has option to report a lower version to ease continuity on TCB update committed_tcb 0xDB19000000000004 SVNs of the anti-rollback minimum of the platform firmware and microcode launch_tcb 0xDB19000000000004 SVNs of the version of the platform firmware and microcode at time of launch of this guest cpuid1eax_fms 0xA00F11 Extended Family ID: 0xA, Family ID: 0xF Model: 0x1 SteppingID: 0x1 (AMD Milan CPU) * For more information and the complete list of the attestation claims, please refer to AMD SEV Secure Nested Paging Firmware ABI Specification. Note that there are some security features such as ciphertext hiding and disabling page swapping that are not enabled due to those features being not supported in this CPU family. Customers can use the cpuid1eax_fms claim to verify the limitations. Verification of SVN numbers for AMD SNP:AMD provides an AMD Key Distribution Service (KDS) that can be used to query the TCB information. Using the Chip ID and reported_tcb from the attestation report, we can request a VCEK certificate chain for this CPU.An example REST API call will look like this:GET https://kdsintf.amd.com/vcek/v1/Milan/<chip-id-hex>The KDS will respond with the VCEK certificate chain. The latest TCB version is not in plain text; it's encoded in a custom X.509 extension within the certificate. We can compare the TCB values parsed from the VCEK certificate's extension with the reported_tcb values from the attestation report. The verification passes if every component of the reported_tcb is greater than or equal to the corresponding component from the VCEK. More information and the details can be found at AMD Versioned Chip Endorsement Key (VCEK) Certificate and KDS Interface Specification. We thank the Google PSS (Privacy, Safety & Security) and Cloud CISO Security Engineering team members who contributed to the blog: Google PSS: Daniel Moghimi (danielmm@google.com) Senior Research Scientist and Cloud CISO: Josh Eads (josheads@google.com) Security Engineer.
