Attestable Computing posts

[Notes] SessionLatch: Attested TLS for Confidential Virtual Machines

Last updated Attestable Computing Papers

Paper

While TLS authenticates a service identity and attestation tells you an environment is approved, clients can’t be certain that the TLS session actually in use terminates in the expected environment. SessionLatch proposes using a trusted observer inside CVMs to prove session-endpoint correspondence.

This observer produces TEE-bound evidence which clients can fetch via a separate control channel as the handshake proceeds, holding (latching) client encrypted records until the evidence verifies and frees up the data path.

The Linux implementation relies on a userspace observer using SOCK_DIAG, nftables/NFQUEUE and other OS facilities. A measured/enforced eBPF or similar kernel mechanism could potentially provide a stronger reference monitor and bind the session to richer workload identity.

More broadly, the paper illustrates why endpoint attestation becomes harder as the TEE boundary expands from process enclaves to entire confidential VMs.

[Notes] Grimlock: Guarding High-Agency Systems with eBPF and Attested Channels

Last updated Attestable Computing Agent Runtime Security Papers

The core idea in Grimlock is separation of concerns for high-agency systems: agent code handles orchestration, while the sandbox substrate enforces identity, authentication, authorization, provenance, and least-privilege delegation. Much of this is established security architecture; what I found interesting is how the pieces are composed while leaving agent code unchanged.

eBPF provides no-bypass, application-transparent mediation at the sandbox boundary and associates ordinary socket flows with stable sandbox identities. Guard-to-guard communication uses TLS 1.3 with kTLS for the data plane, allowing authentication context and longer-lived channels to amortize setup costs.

Post-handshake attestation is of special note. TLS exporters bind fresh TEE evidence to an already-established channel, including nonce, audience, and requested delegation scope. Successful appraisal produces short-lived, channel-bound Scope Tokens that the destination guard revalidates before releasing plaintext to the destination sandbox.

[Notes] TIRA: Task-Based Intermittent Remote Attestation

Last updated Attestable Computing Papers

The most useful idea in TIRA: Task-Based Intermittent Remote Attestation is not that intermittent systems can be made task-based, or that remote attestation can hash code and report a digest. What is interesting is the way the paper treats the task abstraction itself as the unit of attestable progress.

The mechanism is a compiler/runtime co-design. Programmer-defined idempotent tasks are instrumented with software fault isolation; unsafe memory writes and control-flow transfers are mediated through a Trusted Compute Module; a protected bootloader establishes static attestation at boot; and successful task transitions, interrupt evidence, and mutable memory effects are folded into a cryptographically chained execution log.

The reported overheads are practical enough to make the design worth studying: about 18% runtime overhead and 4% code-size overhead on average. More broadly, the paper suggests that in some constrained systems, the right attestation boundary may be the application’s execution abstraction, not just the boot image or hardware root.

[Notes] Kettle: Attested Builds for Verifiable Software Provenance

Last updated Attestable Computing Software supply chain security Papers

Kettle turns build provenance from an assertion into hardware-rooted evidence. It runs builds inside a measured confidential VM, records source, resolved dependencies, toolchain, environment, and output digests as SLSA/in-toto provenance, then commits the provenance hash into the TEE attestation report. Verification becomes an attestation check plus digest comparisons rather than trusting CI infrastructure or reproducing the build.

The interesting part is the composition: Kettle reproducibly builds its own CVM image, providing a way to derive the expected launch measurement; uses a Merkle commitment over build inputs; and can optionally attest the CVM before confidentially delivering source. Reproducibility answers whether another build produces the same bytes; attestation proves that one measured environment actually observed specific inputs and produced specific bytes.

The broader lesson is that attestation can move build infrastructure outside the trust boundary—but verifier policy still determines which measured builders deserve trust.

For a related approach to ML provenance, see my notes on Atlas, which combines attestation and transparency logs to authenticate a model’s transformation history.

[Notes] Verifiable Provenance of Software Artifacts with Zero-Knowledge Compilation

Last updated Attestable Computing Software supply chain security

Paper

The interesting idea here is shifting software provenance from reproducing or trusting a build to cryptographically verifying the computation itself. Reproducible builds effectively say “repeat my computation”; TEE-based systems attest that trusted hardware performed it. COSMICTURTLE instead runs compilation inside the RISC Zero zkVM and produces the binary plus a succinct proof binding the claimed source, compiler, and output.

The prototype runs unmodified ChibiCC and successfully zk-compiles 252 C programs, including OpenSSL and libsodium source files. Adversarial tests reject compiler substitution, source or binary tampering, and replay. This is still far from proving an industrial GCC/LLVM build graph, but it suggests that software provenance can be dealt with as a verifiable-computation problem rather than primarily a reproducibility or hardware-attestation problem.

[Notes] aflock: Cryptographically Signed Policies for Constrained AI Agent Execution

Last updated Software supply chain security Attestable Computing Agent Runtime Security

aflock applies familiar ideas from SPIFFE/SPIRE, in-toto, capability systems, and policy engines to agent execution. Rather than trusting an agent to report its own behavior, aflock moves authorization and evidence generation into an external MCP server. Agent identity is derived from introspectable properties; short-lived JWTs convey authority; and the server signs attestations with keys the agent never sees.

Policies can constrain individual actions and cumulative properties of an execution trajectory. Session attestations are committed through a Merkle tree to provide ordering and completeness evidence, while Rego evaluates cross-attestation constraints. Hierarchical sub-agent delegation uses in-toto-style sublayouts with mandatory attenuation, so delegated authority cannot exceed the parent’s constraints.

The broader systems principle is compelling: securing autonomous agents may require treating execution trajectories much like software supply chains—externally constrained, cryptographically recorded, and recursively verifiable—rather than relying on the agent itself to enforce or describe its boundaries.

[Notes] Fortress: Securing IoT Peripherals with Trusted Execution Environments

Last updated Attestable Computing

Fortress: Securing IoT Peripherals with Trusted Execution Environments (Peterson Yuhala, Jämes Ménétrey, Pascal Felber, Marcelo Pasin, Valerio Schiavoni)

The motivation in Fortress is to extend the trust boundary from TrustZone to peripherals. MMIO/DMA regions are assigned to the secure world, and the driver is partitioned so that code touching sensitive data executes in OP-TEE’s secure kernel. Data then flows through a PTA to a user-space TA for filtering or encryption before being released to the untrusted OS or cloud. This can help protect sensor data from a compromised OS or hypervisor. Direct MMIO has little overhead; the expensive part is crossing protection boundaries with buffers—up to orders of magnitude slower in their evaluation. The broader lesson is that confidential execution alone may be insufficient when plaintext inputs traverse privileged, untrusted software before reaching the TEE.

[Notes] Atlas: A Framework for ML Lifecycle Provenance & Transparency

Last updated Attestable Computing Transparency logs Software supply chain security Papers

Atlas: A Framework for ML Lifecycle Provenance & Transparency

ML provenance is not just software provenance with models added. The interesting problem is that datasets, code, configurations, weights, and execution environments are coupled through transformations, while models can subsequently be fine-tuned or otherwise adapted. Atlas treats lineage as an authenticated chain of transformations rather than simply an inventory of artifacts.

The individual mechanisms presented in the paper include Intel TDX, remote attestation, cryptographic measurements, C2PA manifests, and Merkle-tree transparency logs. What I found interesting is their composition. An attestation client monitors PyTorch/Kubeflow execution, measures inputs and outputs, records runtime/configuration metadata, and signs a transformation attestation containing hashes of precursor attestations. The transparency service makes these records tamper-evident; verification reconstructs and validates the lineage.

More broadly, Atlas suggests that ML supply-chain integrity may require authenticating the transformation history, not merely signing the resulting model.

[Notes] Remote Attestation with Constrained Disclosure

Last updated Papers Attestable computing

Remote Attestation with Constrained Disclosure (2023) proposes a selective log disclosure mechanism for TPM-based attestation. It uses non-interactive zero-knowledge (NIZK) proofs over IMA logs to let systems prove integrity without revealing full software inventories.

The selective disclosure primitives introduced here are interesting beyond privacy—for example, for fine-grained trust delegation across supply chains.