{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "K-0019",
    "slug": "evidence-binding",
    "title": "Evidence binding",
    "aliases": [
      "binding",
      "attribution of evidence"
    ],
    "status": "draft",
    "last_reviewed": "2026-09-23",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "Tying verification evidence to the specific device, workload, data and time it describes, so it cannot be substituted, replayed or misattributed.",
    "sources": [
      {
        "source": "S-1603",
        "supports": "evidence must be securely associated with its target environment so a verifier cannot be tricked into accepting claims from a different environment; evidence generated with the attester's key material; signed nonces for freshness",
        "locator": "§3.1; §8.1; §10.2"
      },
      {
        "source": "S-0018",
        "supports": "evidence can identify each forward pass uniquely and attribute it to the hardware and time it was processed on",
        "locator": "verification goals"
      },
      {
        "source": "S-0005",
        "supports": "private-key extraction lets other chips impersonate a chip and spoof its location",
        "locator": "On-chip mechanisms for location verification"
      },
      {
        "source": "S-0031",
        "supports": "taps hash and timestamp captured traffic",
        "locator": "tap functions"
      },
      {
        "source": "S-0029",
        "supports": "chip firmware hashes and signs weight snapshots taken at random times",
        "locator": "§4"
      },
      {
        "source": "S-0012",
        "supports": "confidential VMs with GPUs and incremental multiset hashing to track dataset integrity for property attestation",
        "locator": "abstract"
      },
      {
        "source": "S-0017",
        "supports": "prover commits a hash of sampled weights before it learns whether a step will be audited",
        "locator": "pre-training scheme"
      }
    ],
    "related": [
      "K-0004",
      "K-0024",
      "K-0005"
    ],
    "type": "concept",
    "url": "https://trustbutveri.fyi/concepts/evidence-binding/",
    "source_file": "content/concepts/evidence-binding.md",
    "flags_all": [
      "ai-drafted"
    ],
    "body_markdown": "Evidence binding ties a piece of verification evidence to the device, workload, data and time it describes, so that it cannot be replayed, substituted or attributed to something else [[S-1603]] [[S-0018]].\n\nThe IETF remote-attestation architecture states the requirement for devices: evidence must be securely associated with the environment it describes, so that a verifier cannot be tricked into accepting claims that originate elsewhere [[S-1603]]. Binding has several dimensions:\n- **Device.** Evidence is signed with key material held by the attesting device, as in [[M-0008|TEE remote attestation]] [[S-1603]]; Scher and Thiergart note that if a chip's private key were extracted, other chips could impersonate it and spoof its location [[S-0005]].\n- **Time.** A nonce from the appraising party, signed into the evidence, shows that it is fresh rather than replayed [[S-1603]], and [[M-0013|network taps]] hash and timestamp the traffic they capture [[S-0031]].\n- **Workload.** Shavit's design has chip firmware hash and sign weight snapshots taken at random times [[S-0029]], and one low-trust system aims to identify each forward pass uniquely and attribute it to the hardware and time that processed it [[S-0018]].\n- **Model and data.** PAL\\*M tracks dataset integrity with incremental multiset hashing inside confidential virtual machines, so that attested properties refer to the model and data actually used [[S-0012]].\n\nBinding also constrains when evidence is fixed: for sampled checks, the prover must [[K-0024|commit]] to its records before it learns which ones will be audited [[S-0017]].",
    "body_text": "Evidence binding ties a piece of verification evidence to the device, workload, data and time it describes, so that it cannot be replayed, substituted or attributed to something else [S-1603] [S-0018]. The IETF remote-attestation architecture states the requirement for devices: evidence must be securely associated with the environment it describes, so that a verifier cannot be tricked into accepting claims that originate elsewhere [S-1603]. Binding has several dimensions: - Device. Evidence is signed with key material held by the attesting device, as in TEE remote attestation [S-1603]; Scher and Thiergart note that if a chip's private key were extracted, other chips could impersonate it and spoof its location [S-0005]. - Time. A nonce from the appraising party, signed into the evidence, shows that it is fresh rather than replayed [S-1603], and network taps hash and timestamp the traffic they capture [S-0031]. - Workload. Shavit's design has chip firmware hash and sign weight snapshots taken at random times [S-0029], and one low-trust system aims to identify each forward pass uniquely and attribute it to the hardware and time that processed it [S-0018]. - Model and data. PALM tracks dataset integrity with incremental multiset hashing inside confidential virtual machines, so that attested properties refer to the model and data actually used [S-0012]. Binding also constrains when evidence is fixed: for sampled checks, the prover must commit to its records before it learns which ones will be audited [S-0017].",
    "referenced_by": [
      {
        "id": "M-0012",
        "title": "Model identity attestation",
        "url": "https://trustbutveri.fyi/mechanisms/model-identity-attestation/"
      },
      {
        "id": "M-0013",
        "title": "Network taps and certifiers",
        "url": "https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/"
      },
      {
        "id": "M-0023",
        "title": "Safeguard attestation",
        "url": "https://trustbutveri.fyi/mechanisms/safeguard-attestation/"
      },
      {
        "id": "M-0008",
        "title": "TEE remote attestation for AI workloads",
        "url": "https://trustbutveri.fyi/mechanisms/tee-remote-attestation/"
      },
      {
        "id": "I-0007",
        "title": "Attestable Audits",
        "url": "https://trustbutveri.fyi/implementations/attestable-audits/"
      },
      {
        "id": "I-0006",
        "title": "Tinfoil model identity (Modelwrap)",
        "url": "https://trustbutveri.fyi/implementations/tinfoil-model-identity/"
      },
      {
        "id": "C-0002",
        "title": "Chips are where they are declared to be",
        "url": "https://trustbutveri.fyi/claims/chips-are-where-declared/"
      },
      {
        "id": "C-0005",
        "title": "The declared model is the one being served",
        "url": "https://trustbutveri.fyi/claims/declared-model-is-served/"
      },
      {
        "id": "C-0006",
        "title": "Declared safeguards were applied during inference",
        "url": "https://trustbutveri.fyi/claims/safeguards-were-applied/"
      },
      {
        "id": "K-0024",
        "title": "Cryptographic commitment",
        "url": "https://trustbutveri.fyi/concepts/cryptographic-commitment/"
      },
      {
        "id": "K-0014",
        "title": "Network tap",
        "url": "https://trustbutveri.fyi/concepts/network-tap/"
      },
      {
        "id": "K-0004",
        "title": "Remote attestation",
        "url": "https://trustbutveri.fyi/concepts/remote-attestation/"
      }
    ]
  }
}