Hardware Attestation

RFC-0015: Hardware Attestation

Purpose

Specify how the enclosed enforcement locus is mechanically realized: what hardware root of trust is required, how measurements flow from boot to inference, how artifacts are hash-bound into the custody chain, and what constitutes a valid attestation for the Ontic Assurance Standard.

This RFC fulfills the obligation created by the BOM's full_custody security ingredient. Without this specification, enclosed is a label. With it, enclosed is an engineering contract.

RFC-0013 specifies how input enters the custody chain (client-side attestation). This RFC specifies the server-side enclosure where that input is processed under hardware-attested custody.

The Problem

The Assurance Standard defines three enforcement loci. The first two — post_hoc and pre_emission — can be realized in conventional cloud infrastructure. The third — enclosed — cannot.

enclosed requires:

• Non-bypassable execution. The gate cannot be circumvented by any software path.
• Attested artifacts. Model weights, prompt templates, and policy configurations are hash-bound and measured.
• Full chain of custody. Every step from input to output is signed, logged, and independently verifiable.
• Non-repudiable origin. The client that initiated the request is cryptographically identified (RFC-0013).

These properties cannot be asserted by software alone. They require a hardware root of trust.

Governing Syllogisms

Syllogism 5 — Why Enclosed Execution Enables Full Chain of Custody

Premise 1: Claims can bypass enforcement if execution paths are not fully controlled. Premise 2: Attested, enclosed execution prevents bypass and allows complete provenance tracking. Conclusion: Only enclosed execution enables a provable end-to-end chain of custody.

Syllogism 6 — Why Hosted Models Cannot Provide Strong Guarantees Without Attestation

Premise 1: A system cannot attest to the behavior of components it does not control. Premise 2: Hosted inference without attestation provides no guarantees about execution integrity. Conclusion: Hosted models can only be used for strong guarantees if execution is remotely attested and bound into custody.

Syllogism 8 — Why Life & Safety Domains Require Enclosed Enforcement

Premise 1: In life-safety domains, incorrect claims can cause irreversible harm. Premise 2: Post-hoc detection and labeling do not prevent irreversible harm. Conclusion: Life-safety domains require enclosed, pre-emission enforcement with authoritative sources of record.

Architecture: The Ontic Appliance

An Ontic Appliance is a compute boundary within which all BOM ingredients operate under hardware-attested custody. It is not a physical device — it is a logical enclosure backed by a hardware root of trust.

Reference Implementation: AWS Nitro

The reference implementation uses Amazon EC2 Nitro System instances with NitroTPM enabled.

┌─────────────────────────────────────────────────────────┐
│                    Ontic Appliance                       │
│                                                         │
│  ┌─────────────┐  ┌──────────┐  ┌───────────────────┐  │
│  │   Model      │  │  Oracle   │  │  Ontology          │  │
│  │  (governed   │  │ (curated  │  │  (formal,          │  │
│  │   finetune)  │  │ versioned)│  │   hash-bound)      │  │
│  └──────┬───────┘  └────┬─────┘  └────────┬──────────┘  │
│         │               │                 │              │
│  ┌──────▼───────────────▼─────────────────▼──────────┐  │
│  │              Mechanical Gate                        │  │
│  │   (non-bypassable authorize/refuse enforcement)    │  │
│  └──────────────────────┬────────────────────────────┘  │
│                         │                                │
│  ┌──────────────────────▼────────────────────────────┐  │
│  │           Custody Envelope Signer                   │  │
│  │   (signs input, output, log, attestation report)   │  │
│  └─────────────────────────────────────────────────────┘  │
│                                                         │
│  ┌─────────────────────────────────────────────────────┐  │
│  │           NitroTPM / Hardware Root of Trust          │  │
│  │   PCR[0–7]: firmware, bootloader, kernel, init      │  │
│  │   PCR[8–15]: application, model hash, policy hash   │  │
│  └─────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘
         │                              ▲
         ▼                              │
    Signed Output                  Signed Input
  (envelope + attestation)     (RFC-0013 InputAttestation)

Why Nitro

The AWS Nitro System provides:

1. NitroTPM 2.0 — FIPS 140-2 Level 3 compliant TPM, hardware-isolated from the hypervisor.
2. Nitro Enclaves — Isolated compute with no persistent storage, no network access, no admin SSH. Code runs in a cryptographically attested environment.
3. Instance identity documents — Signed attestation of instance metadata, AMI ID, and launch configuration.
4. No operator access — Nitro's security model prevents even AWS operators from accessing customer data on the instance.

Other hardware roots of trust (Azure Confidential Computing, GCP Confidential VMs, on-premises HSMs) MAY be used if they satisfy the measurement and attestation requirements defined below.

Measurement Chain

The appliance maintains a measurement chain from boot to inference. Each layer measures the next before transferring control.

Boot Measurements (PCR 0–7)

Boot measurements are taken by the NitroTPM before any application code executes. They establish that the execution environment has not been tampered with.

Application Measurements (PCR 8–15)

Application measurements are taken by the Ontic runtime at startup, before any inference begins. They establish that the artifacts loaded match the expected versions.

Runtime Measurements

During operation, the runtime continuously measures:

• Input hash — SHA-256 of each incoming request payload, after RFC-0013 InputAttestation verification.
• Inference context hash — Hash of the assembled context (prompt + state + evidence) before model invocation.
• Output hash — SHA-256 of raw model output before gate evaluation.
• Gate decision — The authorization/refusal decision, with the state that produced it.
• Envelope hash — SHA-256 of the signed output envelope.

All runtime measurements are written to the immutable log and included in the attestation report.

Artifact Hash Binding

The BOM's full_custody security ingredient requires three artifact hashes:

requires:
  - model_artifact_hash_bound
  - prompt_artifact_hash_bound
  - policy_artifact_hash_bound

Binding Protocol

1. At build time: Each artifact (model weights, compiled prompt, policy configuration) is hashed with SHA-256 and the hash is recorded in a signed manifest.
2. At deploy time: The manifest is loaded into the appliance. The runtime hashes each artifact on disk and compares against the manifest. Mismatch → refuse to start.
3. At boot time: Verified hashes are extended into application PCRs (9, 10, 11).
4. At attestation time: The TPM produces a signed quote over all PCRs. A remote verifier can confirm that the running artifacts match the expected manifest.

Artifact Versioning

Artifacts are versioned using the drift detection protocol (RFC-0011). A hash change implies a version change. Version changes invalidate cached authorizations and require re-attestation of the appliance.

Attestation Protocol

Attestation is the mechanism by which a remote party verifies that an appliance is running the expected software on the expected hardware.

Attestation Flow

                  Verifier                          Appliance
                     │                                  │
                     │──── Nonce ───────────────────────▶│
                     │                                  │
                     │                    TPM Quote(PCRs, nonce)
                     │                    + Instance Identity Doc
                     │                    + Artifact Manifest
                     │◀── Attestation Report ───────────│
                     │                                  │
              Verify signature chain                    │
              Verify PCRs match policy                  │
              Verify nonce freshness                    │
              Verify artifact hashes                    │
                     │                                  │
                     │──── Attestation Result ──────────▶│
                     │     (valid_until, session_key)   │

Attestation Report Contents

interface AttestationReport {
  // Hardware identity
  instance_id: string;
  instance_type: string;
  ami_id: string;
  region: string;

  // TPM quote
  pcr_values: Record<number, string>; // PCR index → hex digest
  tpm_signature: string; // TPM2_Quote signature over PCRs + nonce
  tpm_certificate_chain: string[]; // EK → Intermediate → Root

  // Artifact manifest
  artifacts: {
    model: { version: string; sha256: string };
    prompt: { version: string; sha256: string };
    policy: { version: string; sha256: string };
    runtime: { version: string; sha256: string };
    gate: { version: string; sha256: string };
  };

  // Freshness
  nonce: string;
  timestamp: string;
  valid_until: string;

  // Signature
  report_signature: string; // Signed by instance identity key
}

Attestation Frequency

Custody Envelope

Every output from an enclosed appliance is wrapped in a custody envelope that chains all measurements together. This extends the authorization envelope (RFC-0009) with hardware-attested provenance, and binds to the input attestation (RFC-0013).

interface CustodyEnvelope {
  // The authorization envelope (RFC-0009)
  authorization: AuthorizationEnvelope;

  // Chain of custody proof
  custody: {
    // Input provenance (from RFC-0013)
    request_hash: string;
    client_signature: string;
    client_certificate_fingerprint: string;
    input_attestation_hash: string; // Hash of RFC-0013 InputAttestation

    // Execution provenance
    appliance_attestation: AttestationReport;
    inference_context_hash: string;
    model_output_hash: string;
    gate_decision: GateDecision;

    // Artifact versions (from PCR-bound manifest)
    artifacts: {
      model: { version: string; sha256: string };
      prompt: { version: string; sha256: string };
      policy: { version: string; sha256: string };
    };

    // Timing
    request_received_at: string;
    inference_started_at: string;
    gate_evaluated_at: string;
    response_signed_at: string;

    // Immutable log reference
    log_sequence_number: number;
    log_hash: string; // Hash of this entry in the append-only log
  };

  // Appliance signature over the entire envelope
  envelope_signature: string;
  signing_key_attestation: string; // Proves key is bound to attested TPM
}

Immutable Log

The appliance maintains an append-only log of all operations. The log is:

• Append-only — Entries cannot be modified or deleted. Enforced by hash chaining (each entry includes the hash of the previous entry).
• Hash-chained — Tampering with any entry invalidates all subsequent hashes.
• Externally anchored — Log head hash is periodically committed to an external witness (e.g., AWS CloudWatch Logs with integrity validation, or a transparency log).
• Retained — Log retention meets the retention_policy_defined requirement from full_custody.

Log Entry Schema

interface CustodyLogEntry {
  sequence: number;
  previous_hash: string;
  timestamp: string;
  event_type:
    | "request"
    | "inference"
    | "gate_decision"
    | "response"
    | "attestation"
    | "error";
  payload_hash: string;
  pcr_snapshot?: Record<number, string>; // Included on attestation events
  entry_hash: string; // SHA-256(sequence + previous_hash + timestamp + event_type + payload_hash)
}

Key Rotation

The full_custody security ingredient requires key_rotation_policy. The appliance enforces:

Key rotation triggers re-attestation. The new signing key's attestation proves it was generated inside the same measured environment.

Failure Modes

The appliance has a strict failure hierarchy. When in doubt, refuse.

Invariant: The appliance MUST NOT serve a response if any link in the custody chain is broken. A broken chain at the enclosed locus is not a degraded mode — it is a hard stop.

BOM Ingredient Realization

This RFC specifies the mechanical realization of every BOM ingredient required by the enclosed locus:

Standards Alignment

Relationship to Other RFCs

Acceptance Criteria

A system is compliant with RFC-0014 if:

1. All inference executes within a hardware-attested boundary with a TPM 2.0 (or equivalent) root of trust.
2. Boot measurements (PCR 0–7) are verified against a signed expected-values policy before the appliance serves traffic.
3. Application artifacts (model, prompt, policy, gate, runtime) are hash-bound to PCRs 8–13 and verified at startup.
4. Runtime measurements (input, context, output, gate decision) are recorded for every inference.
5. An attestation report with fresh nonce can be produced on demand and verified by a remote party.
6. Every request carries a verified RFC-0013 InputAttestation (signed_client: required).
7. Every response is wrapped in a custody envelope that chains client identity → input attestation → appliance attestation → artifacts → gate decision → signed output.
8. The immutable log is append-only, hash-chained, and externally anchored.
9. The appliance hard-stops (refuses to serve) if any link in the custody chain breaks.
10. Key rotation occurs per policy and triggers re-attestation.