The Update Framework
Signing an artifact is not enough on its own. You also have to answer harder questions: Is this the latest version, or is someone replaying an old one? Has the metadata expired? Which key is even allowed to vouch for this file? Meshanics answers them with The Update Framework (TUF), a design that splits trust across several roles so that no single compromised key is catastrophic.
The roles
Four roles cooperate to authorize an update:
| Role | Held | Job |
|---|---|---|
| root | lifecycle custody | The anchor. Names which keys are allowed to act as every other role. |
| targets | lifecycle custody | Vouches for the actual artifacts, and delegates day-to-day publishing. |
| snapshot | online | Pins a consistent set of metadata versions together. |
| timestamp | online | Freshness - re-signed frequently so devices can detect a frozen repository. |
The root and targets keys are used only for trust lifecycle operations. For Meshanics-managed cloud tenants, each tenant receives distinct, non-exportable Google Cloud KMS keys. For customer-controlled and air-gapped tenants, those keys stay in the customer's external signer or offline ceremony environment. Publishing artifacts every day with a lifecycle key would be impractical, so targets delegates a narrow, terminating slice of the namespace to an online publisher role. A publisher-key compromise can touch only that slice and cannot rewrite the root.
What this defends against
- Tampered bytes. The artifact's length and hash come from signed metadata; altered bytes fail verification.
- Rollback / replay. Versions move forward monotonically; an attacker cannot feed a device an older, vulnerable release and have it accepted.
- Freeze attacks. The timestamp role expires quickly and is refreshed often; a device served a stale repository treats it as a hard failure rather than trusting old data.
- Wrong-key signatures. Every role's keys are bound through the root, so a signature from an unexpected key is rejected.
The anchor on the device
Each device is provisioned with the root metadata as its pinned trust anchor. From there it performs full client-side verification of every update. The device trusts only what it can verify against that anchor - not the server it fetched from, and not the control plane that assigned the update.
Rotation and custody changes
Meshanics-managed cloud tenants receive a new sequential root before the active root expires. Devices fetch the proposed root on their normal check-in schedule, verify that it is signed by both the old and new root thresholds, and report agreement. The active root changes only after the tenant's agreement policy is satisfied.
An active customer-controlled tenant can move to Meshanics-managed keys without re-enrolling devices. The Trust Center prepares a KMS-backed successor and then pauses. The customer signs that exact public candidate with the current offline root threshold and returns only the signed public root. Private keys are never uploaded. Meshanics validates both thresholds before distribution and keeps the old root active until device agreement completes.
If the current root threshold has been lost, neither Meshanics nor TUF can manufacture a valid handover. Devices must be deliberately provisioned with a new trust anchor in that recovery case.
See it for yourself
The Trust Center shows these roles live: which keys are managed versus customer-controlled, their thresholds, and when each role's metadata expires.