{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "K-0004",
    "slug": "remote-attestation",
    "title": "Remote attestation",
    "aliases": [
      "attestation"
    ],
    "status": "draft",
    "last_reviewed": "2026-09-23",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "A process in which a device sends signed evidence about its state, such as software measurements, so a remote party can judge its trustworthiness.",
    "sources": [
      {
        "source": "S-1603",
        "supports": "purpose of attestation; Attester, Evidence, Verifier, Relying Party, Attestation Result; evidence generated with key material; nonces for freshness",
        "locator": "§1; §3.1; §4; §10.2"
      },
      {
        "source": "S-1600",
        "supports": "NIST definition of attestation as signing measurements securely stored in hardware, which the requester validates",
        "locator": "term: attestation (NIST SP 1800-19B)"
      },
      {
        "source": "S-1602",
        "supports": "Root of Trust for Reporting provides authenticity and non-repudiation when attesting to platform characteristics",
        "locator": "p. 9"
      },
      {
        "source": "S-1604",
        "supports": "attestability as an optional TEE attribute that confidential computing requires; attestation as validation of a hardware-signed report of TCB measurements",
        "locator": "TEE attributes; attestation"
      },
      {
        "source": "S-0005",
        "supports": "location attestation depends on the chip's private key not being extractable",
        "locator": "On-chip mechanisms for location verification"
      }
    ],
    "related": [
      "K-0005",
      "K-0006",
      "K-0019"
    ],
    "type": "concept",
    "url": "https://trustbutveri.fyi/concepts/remote-attestation/",
    "source_file": "content/concepts/remote-attestation.md",
    "flags_all": [
      "ai-drafted"
    ],
    "body_markdown": "Remote attestation is a process in which a device produces evidence about its own state, signed with keys it protects, so that a remote party can decide whether to consider it trustworthy [[S-1603]] [[S-1600]].\n\nThe IETF RATS architecture names three roles:\n- **Attester.** It produces evidence: claims that may include configuration data, measurements and telemetry, typically signed with its key material [[S-1603]].\n- **Verifier.** It appraises the evidence against reference values and an appraisal policy, and produces attestation results [[S-1603]].\n- **Relying party.** It uses the results to decide whether to treat the attester as trustworthy [[S-1603]].\n\nIn the Trusted Computing Group's model, a [[K-0005|root of trust]] for reporting gives attested platform characteristics their authenticity and non-repudiation [[S-1602]]. A nonce sent by the appraising party and signed into the evidence shows that the evidence is fresh rather than replayed [[S-1603]]. Attestation is not isolation: a [[K-0006|trusted execution environment]] protects a workload, while attestation lets a remote party check what a genuine TEE loaded, and confidential computing requires both [[S-1604]]. In AI verification, attestation underlies [[M-0008|TEE remote attestation for AI workloads]] and [[M-0018|chip location verification]]; for location, Scher and Thiergart note that the chip's private key must not be extractable, or other chips could impersonate it [[S-0005]].",
    "body_text": "Remote attestation is a process in which a device produces evidence about its own state, signed with keys it protects, so that a remote party can decide whether to consider it trustworthy [S-1603] [S-1600]. The IETF RATS architecture names three roles: - Attester. It produces evidence: claims that may include configuration data, measurements and telemetry, typically signed with its key material [S-1603]. - Verifier. It appraises the evidence against reference values and an appraisal policy, and produces attestation results [S-1603]. - Relying party. It uses the results to decide whether to treat the attester as trustworthy [S-1603]. In the Trusted Computing Group's model, a root of trust for reporting gives attested platform characteristics their authenticity and non-repudiation [S-1602]. A nonce sent by the appraising party and signed into the evidence shows that the evidence is fresh rather than replayed [S-1603]. Attestation is not isolation: a trusted execution environment protects a workload, while attestation lets a remote party check what a genuine TEE loaded, and confidential computing requires both [S-1604]. In AI verification, attestation underlies TEE remote attestation for AI workloads and chip location verification; for location, Scher and Thiergart note that the chip's private key must not be extractable, or other chips could impersonate it [S-0005].",
    "referenced_by": [
      {
        "id": "M-0018",
        "title": "Chip location verification",
        "url": "https://trustbutveri.fyi/mechanisms/chip-location-verification/"
      },
      {
        "id": "M-0025",
        "title": "Confidential multi-party verification",
        "url": "https://trustbutveri.fyi/mechanisms/confidential-multi-party-verification/"
      },
      {
        "id": "M-0009",
        "title": "Hardware-enabled guarantees (flexHEG) and guarantee processors",
        "url": "https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/"
      },
      {
        "id": "M-0012",
        "title": "Model identity attestation",
        "url": "https://trustbutveri.fyi/mechanisms/model-identity-attestation/"
      },
      {
        "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-0009",
        "title": "Lucid sovereignty (location) certificates",
        "url": "https://trustbutveri.fyi/implementations/lucid-location-certificates/"
      },
      {
        "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-0019",
        "title": "Evidence binding",
        "url": "https://trustbutveri.fyi/concepts/evidence-binding/"
      },
      {
        "id": "K-0007",
        "title": "Hardware-enabled mechanism (HEM)",
        "url": "https://trustbutveri.fyi/concepts/hardware-enabled-mechanism/"
      },
      {
        "id": "K-0001",
        "title": "Prover",
        "url": "https://trustbutveri.fyi/concepts/prover/"
      },
      {
        "id": "K-0005",
        "title": "Root of trust",
        "url": "https://trustbutveri.fyi/concepts/root-of-trust/"
      },
      {
        "id": "K-0006",
        "title": "Trusted execution environment (TEE)",
        "url": "https://trustbutveri.fyi/concepts/trusted-execution-environment/"
      },
      {
        "id": "K-0002",
        "title": "Verifier",
        "url": "https://trustbutveri.fyi/concepts/verifier/"
      }
    ]
  }
}