Timed challenge-response and memory-occupation challenges

How it works

A timed challenge asks a device a question designed so that answering correctly within a deadline requires holding certain data locally or dedicating certain resources to the answer ² ⁴ ⁶. The verifier must know the expected hardware and rule out outside help, such as remote memory ² ⁶. The designs differ in what the answer depends on:

Code. In timed attestation, as in SWATT, a 2004 scheme for embedded devices, the verifier sends a random seed and the device computes a checksum over its memory in a pseudorandom order ⁶. If memory has been altered, the extra work shows up as a detectable delay ⁶. SAGE applies the idea to GPUs ⁵.
Stored data. A residency challenge asks for a computation over data that the device should hold, and the response time shows whether the data is local ² ⁴. See VRAM-residency challenge for a GPU test and Data-centre memory challenging for a data-centre design.
Model weights. Model fingerprint attestation proposes fresh challenges that would need the declared model or shard already in memory to meet a deadline. Construction of the challenge remains future work ¹.
Full capacity. A saturation challenge loads incompressible data until capacity is full, then challenges random samples, which bounds free memory ². It builds on proofs of space, in which a prover shows that it dedicates "a significant amount of disk space as opposed to computation" ⁹. See Data-centre memory challenging.
Spare compute. A contention probe times a puzzle whose solve time lengthens when other work shares the processor ⁴. See GPU contention probes.

Two neighbouring mechanisms use the same timing principle. Some proofs of secure erasure fill memory and then run timed rounds, accepting only answers that arrive within a round-trip bound ¹⁰ ¹¹; see Memory wiping and proofs of secure erasure. Delay-based location checks are covered in Chip location verification.

What it establishes

Response time is the main evidence, because an answer that needs another device can arrive measurably later ². What a timely answer shows depends on the design:

A capacity-filling challenge that is answered on time bounds how much free memory a device had, provided remote memory access is ruled out ².
Timing variations can expose whether a GPU is engaged in other work, complementing other accountability mechanisms ⁴.
The AI 2040 plan says memory-challenge verification "has the promise of potentially also not requiring a hardware retrofit, but seems likely to face some difficulties with verifying completeness" ³.

A presence check does not show that nothing else is stored ². Data could be staged into local memory before a challenge. The MIRI system overview proposes an unpredictable challenge that fills the available capacity to close this route ².

Threat model

The designs state these assumptions:

Known device. SWATT's verifier must know the device's clock speed, instruction set, memory architecture and expected memory contents ⁶. SAGE assumes that the verifier knows the exact hardware configuration of the GPU ⁵.
No outside help. In data centres, remote memory access is the helper to exclude ². Its round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, and the MIRI system overview says verification "depends on the ability to rule out RDMA, either via response latency or physical disconnection" ².
Verifier placement. The MIRI overview notes that most memory-challenge mechanisms need a probe close to the challenged memory ². SAGE's verifier runs in an enclave on the same host as the GPU ⁵.
Compromised stack. Monfared et al. consider host and GPU firmware that "may be modified, virtualized, or colluding" ⁴. They present their measurements as heuristic indicators of usage and do not claim full adversarial resistance or proofs ⁴.
Device binding. Monfared et al. tie the VRAM-residency test to a GPU model with a floating-point fingerprint. They state that this is not a secure binding and does not distinguish individual GPUs, and their threat model accepts outsourcing to an identical GPU of the same model ⁴.

Proofs of space are proved secure in the random oracle model, with one additional mild assumption ⁹.

Implementations

Data-centre memory challenging

A proposed design that times answers from a data centre's memory to check that declared data is present or that no free memory remains.

Proposed for confirming data presence and bounding free memory across data-centre servers

This compute runs inference, not trainingSupporting

GPU contention probes

Three timed GPU puzzles whose solve times lengthen when another workload shares the device, a heuristic sign to a verifier that the GPU is shared.

Research demonstration for detecting another workload running on the same GPU

Declared hardware is idle or shut downPrimary

Low-trust AI compute verification system overview

A reference design that existing data centres could add: network taps hash all traffic, and air-gapped, independently sourced checkers later re-run randomly chosen records.

Proposed for screening challenged records to show declared inference compute is not training

This compute runs inference, not trainingPrimary
The declared model is the one being servedSupporting
Declared safeguards were applied during inferenceSupporting
Communication between compute groups is boundedSupporting

Model fingerprint attestation

A proposed timed challenge that tests whether declared model weights are already in a chip's memory.

Proposed for checking residency of declared model weights with timed challenges

The declared model is the one being servedSupporting

SAGE

A software-only attestation scheme in which a GPU must compute a checksum over its own code within a time limit, without trusted GPU hardware.

Research demonstration for attesting code execution on a GPU that lacks hardware trusted-execution support

The declared model is the one being servedSupporting

VRAM-residency challenge

A timed challenge that tests whether verifier-supplied data is still held in a GPU's on-board memory or has moved to host memory.

Research demonstration for detecting whether verifier-supplied data remains in a single GPU's memory

Declared hardware is idle or shut downSupporting

Mechanism claim links

Implementation-specific claims are listed with each implementation.

Declared hardware is idle or shut downPrimary. Timed compute probes take longer when other work shares the GPU, which Monfared et al. treat as a heuristic indicator of usage. Their memory-residency probe runs alongside AI workloads, so it does not show idleness ⁴.

This compute runs inference, not trainingSupporting. A capacity-filling challenge answered on time bounds the free memory left for undeclared work on the challenged devices, provided remote memory access is ruled out ². The AI 2040 plan lists memory challenges as an inference-verification direction that may not need a hardware retrofit but may have difficulty verifying completeness ³.

Chips are where they are declared to beSupporting. Monfared et al. list location estimation from delay-amplified GPU interactions as a possible use, which they do not evaluate ⁴. Delay-based location checks time a cryptographic challenge-response between a chip and landmark servers ¹³; see Chip location verification.

The declared model is the one being servedSupporting. The code-attestation variant supports execution integrity. SAGE uses a timed checksum, verifies the GPU kernel and authenticates data exchanged with a host enclave ⁵. Identifying the served model also depends on which code and weights the enclave supplies. Separately, model fingerprint attestation proposes timed checks of declared model residency, with challenge construction still open ¹. Residency alone does not bind a delivered response to those weights.