{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "K-0005",
    "slug": "root-of-trust",
    "title": "Root of trust",
    "aliases": [
      "RoT",
      "hardware root of trust"
    ],
    "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 component that anchors security functions such as measurement, storage and reporting, and must be trusted because its misbehaviour cannot be detected.",
    "sources": [
      {
        "source": "S-1601",
        "supports": "definition of RoT and its security-specific functions; must always behave as expected because its misbehaviour cannot be detected; first element of a chain of trust anchoring more complex functionality",
        "locator": "§3.3, pp. 11–12"
      },
      {
        "source": "S-1600",
        "supports": "roots of trust as highly reliable hardware, firmware and software components that must be secure by design",
        "locator": "term: roots_of_trust (NIST SP 800-172r3; NISTIR 8320)"
      },
      {
        "source": "S-1602",
        "supports": "RTM and RTR definitions",
        "locator": "p. 9"
      },
      {
        "source": "S-0029",
        "supports": "hardware roots of trust on ML chips; open-source RoT designs so verifiers can check for backdoors",
        "locator": "§6.2"
      },
      {
        "source": "S-0014",
        "supports": "vendor as root of trust as a concern; holder of hardware key can produce valid attestation reports",
        "locator": "Limitations"
      }
    ],
    "related": [
      "K-0004",
      "K-0006",
      "K-0007",
      "K-0015"
    ],
    "type": "concept",
    "url": "https://trustbutveri.fyi/concepts/root-of-trust/",
    "source_file": "content/concepts/root-of-trust.md",
    "flags_all": [
      "ai-drafted"
    ],
    "body_markdown": "A root of trust is a hardware, firmware or software element that forms the basis of security functions such as measurement, storage, reporting, recovery, verification and update, and that must always behave as expected because its misbehaviour cannot be detected [[S-1601]] [[S-1600]].\n\nIt is typically the first element in a chain of trust and anchors more complex functions built on it [[S-1601]]. Because it is trusted by assumption, it must be secure by design [[S-1600]]. The Trusted Computing Group distinguishes a root of trust for measurement, which makes the first integrity measurement and adds it to a tamper-resistant log, from a root of trust for reporting, which vouches for platform characteristics during [[K-0004|remote attestation]] [[S-1602]]. Shavit's framework needs hardware roots of trust on ML chips, and calls for open-source designs so that independent verifiers can check them for backdoors [[S-0029]]. A 2026 MIRI Technical Governance Team post describes reliance on the hardware vendor as root of trust as a significant concern for [[M-0008|TEE-based attestation]], since whoever holds the hardware's key can produce valid attestation reports [[S-0014]].",
    "body_text": "A root of trust is a hardware, firmware or software element that forms the basis of security functions such as measurement, storage, reporting, recovery, verification and update, and that must always behave as expected because its misbehaviour cannot be detected [S-1601] [S-1600]. It is typically the first element in a chain of trust and anchors more complex functions built on it [S-1601]. Because it is trusted by assumption, it must be secure by design [S-1600]. The Trusted Computing Group distinguishes a root of trust for measurement, which makes the first integrity measurement and adds it to a tamper-resistant log, from a root of trust for reporting, which vouches for platform characteristics during remote attestation [S-1602]. Shavit's framework needs hardware roots of trust on ML chips, and calls for open-source designs so that independent verifiers can check them for backdoors [S-0029]. A 2026 MIRI Technical Governance Team post describes reliance on the hardware vendor as root of trust as a significant concern for TEE-based attestation, since whoever holds the hardware's key can produce valid attestation reports [S-0014].",
    "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-0011",
        "title": "Hardware performance throttling and licensing",
        "url": "https://trustbutveri.fyi/mechanisms/hardware-performance-throttling/"
      },
      {
        "id": "M-0023",
        "title": "Safeguard attestation",
        "url": "https://trustbutveri.fyi/mechanisms/safeguard-attestation/"
      },
      {
        "id": "M-0017",
        "title": "Tamper evidence for verifier devices",
        "url": "https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/"
      },
      {
        "id": "M-0008",
        "title": "TEE remote attestation for AI workloads",
        "url": "https://trustbutveri.fyi/mechanisms/tee-remote-attestation/"
      },
      {
        "id": "I-0009",
        "title": "Lucid sovereignty (location) certificates",
        "url": "https://trustbutveri.fyi/implementations/lucid-location-certificates/"
      },
      {
        "id": "I-0010",
        "title": "RAND secure inference data center (SIDC) design",
        "url": "https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/"
      },
      {
        "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-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-0004",
        "title": "Remote attestation",
        "url": "https://trustbutveri.fyi/concepts/remote-attestation/"
      },
      {
        "id": "K-0015",
        "title": "Tamper evidence and tamper resistance",
        "url": "https://trustbutveri.fyi/concepts/tamper-evidence/"
      },
      {
        "id": "K-0018",
        "title": "Threat model",
        "url": "https://trustbutveri.fyi/concepts/threat-model/"
      },
      {
        "id": "K-0006",
        "title": "Trusted execution environment (TEE)",
        "url": "https://trustbutveri.fyi/concepts/trusted-execution-environment/"
      }
    ]
  }
}