Skip to main content
Contact Nelix Partner with Nelix
Sector

Secure Embedded Systems

Devices that have to stay trustworthy for the next fifteen years

Architecture specified · RTL in progress · no Nelix silicon yet

secure embedded systems context

Service life measured in decades, not product cycles
Service life measured in decades, not product cycles
THE CHALLENGE

A decision taken now has to hold into the 2040s

A protection relay, a payment terminal, a water quality controller or a telematics unit is specified once and then installed for fifteen or twenty years. Over that period the algorithms it was built around will weaken, the vendor that provisioned it may change hands, and the technicians maintaining it will not be the people who designed it. Throughout, the device has to remain able to prove what it is and what it is running.

The two ends of that life carry the most risk and get the least attention. At manufacture, identity and keys are injected in a facility the designer usually does not own, which is where cloning and overbuilding begin. At decommissioning, equipment leaves the field with credentials intact and becomes a convincing impersonator of a unit still in service.

LIMITATIONS

Why current compute does not serve it

The constraints are structural: placement, power, connectivity and service life, not missing features on a datasheet.

  1. Secure boot stops observing once it has passed

    Verification at power-on says nothing about the months of operation that follow, and a device compromised at runtime keeps reporting normally until its next reset.

  2. Cryptography is fixed at design time

    Boot ROMs and accelerators built around one algorithm suite cannot follow a standards transition, so a part with a twenty-year life inherits the assumptions of the year it was specified.

  3. Identity is injected at a third-party facility

    Provisioning secrets handled outside the designer's control create room for cloning and overbuilding that no downstream inspection reliably detects.

  4. Update mechanisms assume a usable link

    Delivery designed for connected devices fails on the intermittent, narrowband links these systems actually have, so equipment stays on firmware whose weaknesses are already published.

  5. Retirement is a logistics step, not a cryptographic one

    Units are removed, stored or scrapped with key material that still validates, and the disposal record is paperwork rather than evidence.

Advanced package
Advanced package
APPROACH

One trust chain from provisioning to retirement

TrustCore is specified as a continuous trust plane rather than a boot gate. Identity is derived from per-die manufacturing variation, so there is no secret to inject at a provisioning facility and no stored private key to recover from a returned part. Each boot stage is measured with monotonic anti-rollback counters, firmware and model artefacts are checked against signed manifests before load, and the tamper mesh and environmental sensors stay armed for the operational life.

The signing path is specified for post-quantum suites alongside classical algorithms, and updates are verified locally against signed manifests and can be queued offline for equipment reached only during a service visit. At end of life, cryptographic retirement zeroises key material so a decommissioned unit cannot authenticate as a deployed one.

These are specifications rather than measurements. TrustCore RTL is in progress, FPGA validation of the boot and attestation path is the next milestone, and there is no Nelix silicon to evaluate yet.

Specified, not measured. RTL in progress; FPGA next; no Nelix silicon yet.

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.
Trust chain from provisioning to retirement · design intent
POSITION

Where Nelix sits in this system

Identity is derived at the die and every boot stage is measured, so trust state can be attested at any point in the service life.

Key material held for the life of the device
Key material held for the life of the device
PATHWAY

From provisioning to cryptographic retirement

One trust chain across provision, operate, update and retire — design intent for decade-scale service life.

  1. Provision

    Derive identity at the die without injecting a secret

  2. Operate

    Keep measuring boot and runtime trust state in the field

  3. Update

    Verify signed manifests, including over intermittent links

  4. Retire

    Zeroise key material so recovered hardware cannot impersonate

CAPABILITIES

The mechanisms that address them

Technical mechanisms in the specification. None of these figures have been characterised in silicon.

  1. PUF-derived identity

    Identity comes from measurable manufacturing variation rather than programmed flash, and invasive attack disturbs the structure the identity depends on.

  2. Measured boot with anti-rollback

    Every stage is measured before it executes and monotonic counters prevent a forced return to a withdrawn firmware version.

  3. Cryptographic agility across service life

    Post-quantum and classical suites are specified together so an algorithm transition does not require replacing a deployed fleet.

  4. Attestation on demand

    An operator can request a signed report of current trust state at any point in the deployment, not only at power-on.

  5. Offline-tolerant signed update

    Updates are staged and verified on the device, so equipment on an intermittent link can still be brought to an approved version.

  6. Cryptographic retirement

    Key material is zeroised at decommissioning, so recovered hardware cannot present itself as a device still in service.

OUTCOMES

What changes if the architecture delivers

Operational consequences stated as design intent, not as measured field results.

  1. Counterfeit and overbuild become detectable

    A part whose identity is not derived from an authorised die cannot produce a valid attestation, so an unauthorised build fails verification instead of passing goods-in inspection.

  2. Fewer devices stranded on old firmware

    Offline queueing and staged rollout make updating equipment on poor links routine rather than a scheduled site visit per unit.

  3. Assurance that survives an algorithm transition

    Equipment specified now can move to post-quantum signing without a hardware replacement programme partway through its service life.

  4. A defensible end of life

    Decommissioning produces evidence that credentials were destroyed, which asset disposal and audit both need and rarely get.

  5. Runtime trust, not only boot trust

    Because state can be attested at any time, a compromise found on one unit can be checked for across the rest of the fleet.

PRODUCTS

Platform layers involved

The product family this sector is specified against. Each page states programme stage honestly.

What we need from this sector now

Partnership

We would rather find the gaps in this specification with product engineers than after tape-out. Pre-silicon, requirements from people who maintain long-lived fleets carry the most weight.

Partner with Nelix Contact the team
  • Requirements from embedded product and firmware teams
  • Provisioning and manufacturing test constraints from contract manufacturers
  • Field data on update failure, counterfeit parts and returns
  • FPGA-based evaluation of the boot and attestation path
  • Review of key lifecycle and decommissioning requirements
SOLUTIONS

Other sectors