Skip to main content
Contact Nelix Partner with Nelix
Root of trust

TrustCore

Continuous hardware trust, manufacture to retirement

Hardware root of trust on every Nelix die: PUF identity, measured boot, tamper monitoring, and signing authority for attestation across the deployed life of the device.

RTL in progress Pre-silicon
Partner with Nelix Product roadmap
Semiconductor die macro

Semiconductor die macro

Identity Device identity
Per-die cryptographic identity from a PUF A conceptual die floorplan. A physical unclonable function array on the left holds entropy created by manufacturing variation, unique to a single die. Its outputs converge through a one-way conditioning block into a root key, which is never stored. A key ladder derives an identity certificate key, an attestation quote key, a sealing key and a link session key. Only signatures leave the die; no key material is exported. Die boundary Puf macro Puf array Per-die entropy Manufacturing variation No two dies respond alike One-way Irreversible Key ladder Identity cert Names the die Attestation key Signs quotes Sealing key Binds data at rest Session key Protects the link Signatures out Key material never crosses this line Identity path
  • Derived key
  • Array cell
  • Light = derivation, one direction only
Identity comes from the die itself: the root key is reconstructed when needed and never written down.
TrustCore · architecture, design intent
ARCHITECTURE

Read the architecture

Each state is entered explicitly, failure is a defined transition rather than an absence, and what is drawn is specified rather than measured.

Sequence TrustCore
The enforced order of operations, 6 steps from first to last Sequence diagram with a trunk on the left edge. Steps in order: Provision; Measure; Verify; Monitor; Attest; Retire. Gate ticks sit between steps; the last step is the only exit. Enforced order 01 Provision Per-die identity derived and bound at manufacture 02 Measure Boot ROM measures each stage; anti-rollback checked 03 Verify Firmware and model checked against signed manifests 04 Monitor Tamper mesh and sensors armed for operational life 05 Attest Signed reports bind trust state to exported results 06 Retire Key material zeroised; device cannot be impersonated No step may be skipped The enforced order of operations, 6 steps from first to last Sequence diagram with a trunk on the left edge. Steps in order: Provision; Measure; Verify; Monitor; Attest; Retire. Gate ticks sit between steps; the last step is the only exit. 01 Provision Per-die identity derived and bound at manufacture 02 Measure Boot ROM measures each stage; anti-rollback checked 03 Verify Firmware and model checked against signed manifests 04 Monitor Tamper mesh and sensors armed for operational life 05 Attest Signed reports bind trust state to exported results 06 Retire Key material zeroised; device cannot be impersonated
  • Ordered step
  • Only exit
Every state is entered explicitly, and the gates between them are why the order holds.
Boot chain Secure boot
Measured secure boot sequence A conceptual staged boot diagram. Five stages ascend from an immutable boot ROM through first stage, loader and kernel to an attestable state. Each stage verifies the next before handing control on, and each writes a measurement into a shared register bank below, which fills as the sequence proceeds. If any measurement fails to match, control leaves the sequence into a halt state and no attestation is produced. Boot depth Boot sequence Mismatch Halt, no attestation S0 Boot ROM Immutable S1 First stage Verify + measure S2 Loader Verify + measure S3 Kernel Verify + measure S4 Attestable Quote ready Measurement register M0 M1 M2 M3 M4 Extend only · never rewind
  • Current stage
  • Reject path
  • Light = hand-off and measurement
Each stage measures the next before handing over, and the register only extends, so the boot history cannot be rewritten.
Mechanism context · design intent
MECHANISMS

What holds, and why

  1. PUF-derived identity

    Identity from die physics. Invasive attack disturbs the structure it depends on

  2. Measured boot

    Every stage measured; monotonic counters block withdrawn firmware

  3. Active tamper response

    Suspect state cannot return to service without authenticated remediation

  4. Attestation on demand

    Operator can request a signed state report at any point, not only at boot

Wafer probe station
Wafer probe station
DESIGN TARGETS

Specification

Pre-silicon. Architecture specified; RTL in progress; FPGA next. Figures are design targets, not measured silicon results.

TrustCore design targets
Status RTL in progress
Identity source Physical unclonable function, per-die
Key storage No stored private key material
Boot Measured, with monotonic anti-rollback
Cryptography Post-quantum and classical, HW-accelerated
Tamper Active mesh, sensors, key zeroisation
Update Signed, staged, offline-queueable
Where it fits
  • Device identity
  • Measured boot chains
  • Result attestation
  • Tamper response
  • Cryptographic retirement
Engage

Talk to the design team

The specification is still open to review.

Partner with Nelix Product roadmap
RELATED