Skip to main content
Contact Nelix Partner with Nelix
Sector

Government

Compute whose provenance an institution can establish for itself

Architecture specified · RTL in progress · no Nelix silicon yet

government context

Firmware provenance an institution can establish itself
Firmware provenance an institution can establish itself
THE CHALLENGE

Critical systems depend on parts nobody local can inspect

Revenue collection, identity registers, power dispatch, water treatment, transport signalling and public safety networks all run on hardware designed and fabricated outside the countries that depend on them. The exposure is not only commercial: an institution that cannot establish what its equipment is currently running has no technical basis for the assurances it gives about the systems built on top of it.

Procurement makes this difficult to correct. Requirements are written around products that already exist, evaluation is largely documentary, and the equipment that results stays in service for a decade or more. The engineering capability to specify and review a design, rather than to buy one, sits outside the region, so each procurement cycle begins from the same position as the last.

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. Assurance is documentary rather than measurable

    A certificate describes a design at a point in time. It gives an operator no way to ask a fielded device what firmware and what model it is running today.

  2. Firmware provenance stops at the vendor

    When updates are applied through a supplier toolchain, the deploying institution holds no independent evidence of what was installed on which unit.

  3. Identity is programmed, not intrinsic

    Keys written into flash during manufacture can be extracted or copied, so device identity is only as strong as the least controlled step in a supply chain the buyer never sees.

  4. Buying finished parts transfers no design capability

    Importing completed silicon leaves the specification, verification and threat-modelling skills elsewhere, so each replacement cycle of a national system is again specified by people who did not design the hardware.

Wafer probe station
Wafer probe station
APPROACH

Regional design capability and devices that can be interrogated

Nelix Chip Design Ltd. is a fabless semiconductor company headquartered in Accra. The architecture is published in a public whitepaper rather than held as a private specification, so a ministry, regulator or national operator can review the trust model, the threat model and the attestation format before there is anything to buy.

TrustCore is specified so that identity is derived from per-die manufacturing variation instead of injected at a provisioning facility, and every boot stage is measured with anti-rollback protection. Attested Infrastructure Inference makes the operator, not the supplier, the party that verifies a result: an exported decision arrives with an attestation bundle binding it to device identity, firmware measurement and model version, and can be refused if it does not match approved configuration.

This is an early-stage design programme. Nothing has been fabricated, RTL is in progress, FPGA validation is the next milestone, and a tape-out is not expected before 2029. The present-day work is design services and university collaboration, which is also how the engineering base is being built.

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

Boundary Attestation
Attestation boundary between device and operator A conceptual diagram of the attestation boundary. On the left, inside the device domain, a measurement store, a nonce buffer and a key handle feed a quote generator that binds measurements to a fresh challenge and signs the result. A hatched membrane with a single aperture separates the device from the operator domain on the right, where a verifier checks the quote against a trust anchor and a policy store before issuing an admit or deny decision. Only the challenge and the signed quote pass through the aperture. Device domain Operator domain Attestation boundary One aperture · signed payloads only Measurements Digest chain Nonce Freshness Key handle Attest key Quote Bind & sign Digests Nonce Device id Signed per challenge Verifier Check chain Anchor Root cert Policy Admit rules Decision Admit / deny Signed quote Challenge nonce Inside Outside
  • Signed quote outward
  • Challenge inward
  • Everything else stops at the band
The operator never reaches inside the device: it sends a challenge and checks the signature that comes back.
Attestation boundary · design intent
POSITION

Where Nelix sits in this system

The deploying institution, not the supplier, verifies the attestation bundle before a result is admitted to a workflow.

Verification held by the operator
Verification held by the operator
PATHWAY

From published architecture to operator-held verification

Specify, identify, measure and verify — so an institution can establish provenance for itself.

  1. Specify

    Review a published architecture before there is silicon to buy

  2. Identify

    Derive device identity at the die, not at a provisioning facility

  3. Measure

    Measure every boot stage with anti-rollback protection

  4. Verify

    Hold verification at the institution that operates the system

CAPABILITIES

The mechanisms that address them

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

  1. Published architecture

    The trust model, threat model and energy model are documented publicly, so technical review does not depend on a supplier relationship or a disclosure agreement.

  2. Identity derived at the die

    PUF-derived per-die identity leaves no stored private key to extract during manufacture, distribution or service, and no provisioning secret to handle in a third-party facility.

  3. Verification held by the operator

    Attestation bundles are checked by the deploying institution before a result is admitted to a workflow, rather than trusted because of the network it arrived on.

  4. Measured boot with anti-rollback

    Monotonic counters prevent a device being forced back onto withdrawn firmware, closing a common route to reintroducing a vulnerability that was already fixed.

  5. Cryptographic retirement

    Decommissioned equipment has key material zeroised, so hardware leaving a public estate cannot be used to impersonate a device still in service.

  6. Design and verification work in the region

    Architecture, RTL and verification are carried out in Accra alongside university partners, so the capability accumulates locally rather than only the finished parts.

OUTCOMES

What changes if the architecture delivers

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

  1. Infrastructure that can be audited

    Because provenance travels with each result, an audit can establish what ran, on which device, under which firmware and model version.

  2. A specification to write requirements against

    Standards bodies and procurement teams can express hardware trust requirements against a published architecture they have read, instead of adopting a vendor description.

  3. Reduced dependence on a single foreign source

    A regional design capability is intended to give public operators an alternative to specifying national systems entirely around imported finished silicon.

  4. Engineering capacity that outlasts one programme

    Design services and university collaboration build semiconductor skills locally regardless of the schedule of any individual part.

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

What is useful to us now is requirements and review, not a purchase. Public bodies that operate national systems or write standards can still shape a specification that has not been committed to silicon.

Partner with Nelix Contact the team
  • Requirements input from operators of national infrastructure
  • Engagement on hardware trust and attestation standards
  • Research collaboration with universities and national laboratories
  • Review of the published architecture and threat model
  • Pilot sites for FPGA-based validation ahead of silicon
SOLUTIONS

Other sectors