Appendix E. Hardware Profiles

Jason St George. "Appendix E. Hardware Profiles" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/read/appendix/e-hardware-profiles/

Appendix E: Hardware Profiles

Throughout this thesis we treat “hardware profiles” as first-class objects. They are the way we talk about machines in the same language we use for proofs and receipts.

Concept

A hardware profile is a public description of a class of devices that are interchangeable for security and performance purposes. It is not a single physical unit; it is the specification for what counts as a valid unit of that type.

Informally: a profile says, “devices that meet this description behave like this, within these error bars, under this sampling regime.”

We use hardware profiles to:

• express trust and threat-model assumptions at the protocol and application layer;
• bind proofs and receipts to the types of machines that produced them; and
• make the honesty (and failure rates) of machines measurable over time.

Naming

Profiles are identified by short, stable strings. Three broad kinds:

1. Open-hardware profiles — devices whose RTL/microarchitecture and sampling regime are publicly documented.

   • open_tee_v2 — second-generation open TEE design with published RTL, side-channel budget, and lot-sampling plan.
   • open_signer_v1 — simple key-storage/signing chip with open RTL and sampling.
   • open_camera_v1 — camera/capture pipeline with documented sensor path, secure element, and sampling method.

2. Logical or pure-cryptography profiles — paths that do not rely on special hardware.

   • pure_zk_only — verification/proving path relying only on general-purpose CPUs/GPUs and cryptographic assumptions.
   • software_only_v1 — profile used for testing or where hardware attestations are unavailable.

3. Vendor or mixed profiles — existing devices not fully open but characterized and sampled.

   • vendor_tee_X_v1 — proprietary TEE profile with documented side-channel and attestation scheme.
   • gpu_cluster_Y_v1 — particular GPU farm configuration with known performance and sampling behavior.

Hardware profile specification

Each profile has a specification that is part of the public “bill of materials” for the stack. At a minimum:

• profile_id: string (e.g., “open_tee_v2”)
• device_class: what the device is used for (e.g., “TEE”, “signer”, “accelerator”, “camera”)
• trust_mode: “open”, “mixed”, “opaque”, or “logical”
• design_commit: identifiers for design artifacts (hashes of RTL, GDS, firmware images)
• side_channel_budget: qualitative/quantitative bounds
• sampling_plan: how lots and devices are checked
• attestation_scheme: how devices prove identity and state
• security_target: high-level security goal

Hardware profiles in receipts and policies

Profiles appear in three main places:

1. Policies — Developers express requirements using profiles:

   allowed_hardware_profiles = ["open_tee_v2", "pure_zk_only"]

2. Receipts (PIDL) — Every PIDL receipt includes a hardware_profile field.

3. Telemetry — The observability layer aggregates metrics by profile.

Example profiles:

open_tee_v2:

• device_class: “TEE”
• trust_mode: “open”
• design_commit: hashes of RTL, layout, firmware
• sampling_plan: random lot sampling, SEM/optical inspection
• intended use: high-value proving, key storage, secure computation

open_camera_v1:

• device_class: “camera”
• trust_mode: “open”
• sampling_plan: device sampling and destructive testing per lot
• intended use: origin-anchored capture for media provenance

pure_zk_only:

• device_class: “logical”
• trust_mode: “logical” (no hardware assumptions)
• intended use: contexts where hardware trust is unacceptable

Tip: hover a heading to reveal its permalink symbol for copying.