- A notary key was created in an attested TDX environment with selected measured-boot values, conditional on vendor trust.
- The key was linked to an attested NVIDIA GPU and confidential-computing session in the described configuration.
- Specific bytes, hashes, metrics, or governance-check results were signed by that key or a chained container key.
- A later verifier can validate the signature chain and compare measurements with selected trusted artifacts.
Mechanism under review
Tamperproof certificates, continuously
EQTY Lab's Verifiable Compute chains Intel TDX and NVIDIA H100 attestations to a notary key inside a confidential VM. The key signs inputs, outputs, metrics, and configured governance-check results as persistent credentials.
Read primary source ↗Adversary realism4/5
Concrete but vendor-bounded
The source considers untrusted hosts, administrators, key leakage, remote poisoning, output races, corruption, and phishing, but not vendor compromise or invasive physical attack.Trusted dependencies5/5
Very high
CPU/GPU roots, vendor services, measured boot, audit and build provenance, key isolation, capture, remote inputs, policy checks, and long-term verification must compose.Policy reach4/5
High
The system moves from authenticated execution artifacts to broad claims about governance, regulation, lineage, correctness, output authenticity, and accountability.01Mechanism under review
Create portable evidence about the hardware and software environment, workload artifacts, computation metrics, confidentiality state, and execution of configured governance checks.
- 01
Intel TDX secure boot authenticates boot components and measures an expected VM file-system hash.
- 02
The VM generates a notary key and binds it and the file-system measurement into a CPU attestation.
- 03
A secure channel validates the NVIDIA H100 certificate and firmware attestation and binds GPU evidence to the notary.
- 04
Container-specific keys sign workload inputs, outputs, selected metrics, and governance-check results.
- 05
Signatures and attestations are packaged as persistent Verifiable Credentials, SPDX, or SLSA artifacts.
Technical output
A chain of vendor hardware attestations and signed artifacts described as proofs of environment, confidentiality, correctness, computation, and governance.
02Claim boundary
What the primitive says—and what it does not.
- Whether audited code is correct, complete, vulnerability-free, or faithful to a law or policy.
- Whether every input, external service, nondeterministic event, side effect, output, and communication was captured.
- Whether signed metrics prove useful or correct computation rather than emitted measurements.
- Whether a passing check establishes full compliance, output truth, model safety, or accountable intent.
- Whether vendor roots, audits, build systems, revocation, algorithms, and certificate meaning remain trustworthy decades later.
03Threat model in scope
Protected asset
The notary key, measured environment, signed artifacts, and the chain connecting CPU and GPU attestation to governance claims.
Adversary
An untrusted host, malicious administrator, compromised remote resource, or external actor seeking to alter code, inputs, outputs, keys, or evidence.
Enforcement boundary
The system signs observations and may halt application logic when configured checks fail inside the measured workload; it does not validate the adequacy of those checks or govern unobserved services.
Capabilities considered
- Control the host, hypervisor, storage, network, and services around the confidential VM.
- Attempt post-boot access, signing-key exfiltration, or signing-oracle abuse.
- Poison or replace models and datasets downloaded at runtime.
- Modify outputs before signing, corrupt encrypted state, or present a phishing endpoint.
Limits and exclusions
- The whitepaper gives mitigations but no formal, parameterized threat model.
- H100 is described as protecting against basic physical attacks; invasive state analysis is not established.
- Compromised vendors, root authorities, attestation services, and hardware supply chains are not located as evaluated adversaries.
- No independent complete-system audit, reproducible security evaluation, or quantitative attack results are provided.
- Policy correctness, model semantics, and third-party service behavior remain outside attestation.
04Trust register
The assurance dependency chain.
DomainRequirementFailure consequenceSource treatment
CPU/GPU and vendor roots
TDX, H100, firmware, quotes, certificates, revocation, and vendor services are genuine, secure, and current.
The notary is validly bound to an environment that is vulnerable or not what the verifier assumes.
centralAudited image and build
The measured file system is competently audited and reliably built from the reviewed source.
Attestation proves exact execution of malicious or semantically wrong code.
centralNotary key and artifact capture
Keys cannot leak or become signing oracles, and every relevant artifact is signed at the correct point.
Arbitrary documents are signed or selected evidence omits the real workflow.
centralExternal resources and governance checks
Remote inputs have meaningful integrity and configured checks correctly implement complete policy requirements.
The system faithfully signs poisoned inputs or a narrow predicate that passes while the advertised policy fails.
centralLong-term verification and semantics
Formats, cryptography, reference measurements, revocation, and interpretation remain available and appropriately narrow.
A credential stays syntactically valid but becomes insecure, uninterpretable, or overstated as proof of compliance.
not located05Caveats on the record
Limitations the source already recognizes.
- All proofs depend on auditing the VM file system, access controls, input handling, and absence of malicious code.
- The system must be deterministic or log nondeterminism, and deterministic builds are not broadly achievable.
- A leaked notary key can forge arbitrary outputs; remote resources must be checked or logged and signed.
- Outputs must be protected until signing, and confidential computing does not fully prevent corruption attacks.
- The then-current bounce buffer adds overhead and supports one GPU or eight in one server; external APIs remain a separate trust boundary.
06Consortium assessment
Where the assurance moves
The design transfers hardware-rooted assurance to a signing key and selected measured code and artifacts. It does not transfer that assurance to code correctness, capture completeness, output truth, policy adequacy, or legal compliance.
Load-bearing sequence
- Intel and NVIDIA hardware, firmware, roots, services, and isolation are trustworthy.
- The measured image is exactly the artifact competent auditors reviewed.
- The VM protects keys and captures every relevant artifact and event.
- The governance check encodes the intended policy property.
- Long-term verifiers retain secure algorithms, reference state, revocation data, and disciplined interpretation.
Institutional translationThe certificate can authenticate that the configured check passed. Whether the check exhausts the meaning of ‘compliant’ is not included in the signature.
07Tests that would change our mind
A finding should be falsifiable.
Insert malicious or incomplete code into the measured image and assess audit detection; no independent audit result is linked.
Attack system and container signing interfaces from a malicious administrator and workload; no penetration result is reported.
Exercise revoked certificates, stale firmware policy, compromised services, and unavailable vendor infrastructure; end-to-end behavior is not reported.
Introduce unsigned side effects, nondeterminism, poisoned downloads, and output races and measure capture coverage; no metric is reported.
Validate archived credentials after key rotation, revocation, algorithm deprecation, and retired reference images; the decades-later claim has no located lifecycle test.
08Record provenance
Primary sourceIntroducing Verifiable Compute ↗
Reviewed2026-08-22
Methodologyv1.0
Correction statusnone
Evidence register (4)
EQTY Lab, 'Introducing Verifiable Compute,' public landing page, 'Hardware-based Assurance' and 'The Basics' (accessed 2026-08-22)
Public claims about runtime certificates, lineage, governance, code, execution location, and outputs.
EQTY Lab, Verifiable Compute Whitepaper v1.08, December 2024, Executive Summary and pp. 7–10
The notary, signed inputs and outputs, persistent certificates, governance gate, and distinction from base attestation.
EQTY Lab, Verifiable Compute Whitepaper v1.08, pp. 19–29
TDX measured boot, file-system hash, key generation, H100 binding, workload signing, governance checks, and credential formats.
EQTY Lab, Verifiable Compute Whitepaper v1.08, pp. 35–41
The external API boundary and dependencies on audit, nondeterminism logs, builds, key secrecy, input integrity, output protection, and corruption mitigations.