security: authenticate and version persistent storage against offline tampering

[forkwright]

Finding

The persistent root is wrapped in AES-256-XTS. XTS provides confidentiality but no authenticity, freshness, or rollback protection. The active threat model treats raw eMMC as attacker-controlled, while LFS currently relies on unkeyed structural magic and bounds. An offline attacker can therefore malleate ciphertext or replace the volume with an older valid snapshot without the storage layer detecting it.

Evidence

• crates/thumos/src/encryption.rs implements sector-level AES-XTS without an authentication tag or persisted version.
• crates/thumos/src/lfs.rs validates filesystem structure but has no keyed integrity or rollback anchor.
• Phase 08 currently describes XTS as the persistent-root construction.
• Phase 09 requires protected identity/session state and rollback rejection; those consumers cannot inherit that guarantee from the current volume.

Why this matters

This is software-first work. Live eMMC qualification cannot prove protection against crafted ciphertext, valid-volume rollback, tail substitution, or wholesale replacement. Treating XTS as a complete at-rest security boundary would overstate the system's resistance to an offline attacker.

Done when

• The accepted storage threat model explicitly distinguishes confidentiality, integrity, freshness, and rollback resistance.
• Persistent security-sensitive state uses an authenticated, versioned construction with domain-separated keys, nonces/tweaks that cannot repeat under the accepted lifecycle, and a durable rollback/freshness anchor.
• Power-loss recovery defines atomic update and failure behavior without accepting unauthenticated plaintext or stale authenticated state.
• Adversarial tests cover bit flips, sector swaps, replay of an older whole-volume image, torn metadata/data updates, forged genesis/reset, and key/epoch mismatch.
• Any data intentionally left confidentiality-only is enumerated with a consumer-level integrity/freshness contract and explicit residual risk.
• Software acceptance is green before operator-owned M7 storage qualification.

[forkwright]

Operator decision: adopt the TUF model as this issue's acceptance bar

An earlier lane recommended "signed, versioned, replay-resistant configuration with offline signing custody" and then, asked whether that was genuinely a no-compromise answer, graded its own recommendation as strong direction, incomplete. The operator has adopted the stronger form. Recording it here because this issue owns the surface and the reasoning would otherwise be lost with the session that produced it.

The gap in "signed and versioned" is that it defeats forgery and nothing else. An attacker with offline access to persistent storage does not need to forge a record if they can replay an old authentic one — roll the device back to a configuration whose signature is perfectly valid and whose policy was weaker. Signature verification passes, version monotonicity is the only thing standing in the way, and a naive implementation checks the signature and not the ordering. The same access also permits freeze (withhold updates so the device believes it is current) and mix-and-match (assemble a set of individually-valid records that were never valid together).

The Update Framework is the model that names all three and is the reference this acceptance adopts. It is cited as a design model, not as a dependency to vendor — a bare-metal Rust kernel does not need TUF's transport machinery to adopt its threat decomposition.

Added acceptance

• Rollback resistance: the device persists the highest accepted version and refuses any record at or below it. Signature validity is necessary and not sufficient.
• Freshness / freeze resistance: records carry an expiry, and an expired record is refused rather than accepted as "the last thing we saw".
• Target and schema binding: a record names the device and the schema it is for, so a record valid for one target cannot be presented to another.
• Canonical serialization: signing operates over a canonical encoding, so two byte sequences cannot both verify as the same logical record.
• Threshold offline root with delegated signing keys, root custody offline. Key rotation and revocation are part of the design, not a later addition — a scheme with no revocation path treats key compromise as unrecoverable.
• Atomic application: a partially-applied configuration is not a reachable state.
• Tests exercise each attack the model names — replay of a valid older record, an expired record, a record for another target, a mixed set — and each must be refused. Per this repo's own standard, a test suite for a refusal that only contains the already-refused case proves nothing; the fixtures must include the authentic-but-wrong record.

Not adopted here

The same grading proposed transport-independent signed authority with GitHub and the forge demoted to untrusted mirrors. That concerns fleet repository authority, is owned outside this lane, and is not part of this issue.

[forkwright]

There is already a signed-record verifier in this tree, and what it lacks is precisely the operator's point

Before designing a record format for the TUF acceptance above, I looked for where one already lives. metaxu_core::SignedGrant (crates/metaxu-core/src/grants.rs) is one, built for #544, and measuring the operator's decision against it makes the remaining work concrete rather than abstract.

TUF property the decision names	SignedGrant today
signature over the record	✅ verify_strict under the issuer key
freshness / expiry	✅ now_ms >= expires_at_ms → Expired, expiry exclusive and tested at the boundary
target binding	✅ subject != expected_device → WrongDevice
rollback resistance	❌ no version field, no highest-accepted anchor
schema binding	❌ no record-type discriminator
canonical serialization	⚠️ signs postcard::to_allocvec; determinism unasserted
threshold root, rotation, revocation	❌ single issuer key, no revocation path
atomic application	❌ out of scope for a transient grant

The one gap is the one the decision is about. The operator's note says signature-and-version "defeats forgery and nothing else", and that an attacker with offline access replays an authentic older record rather than forging one. SignedGrant has no version at all, so a captured grant is replayable for its whole validity window — which is bounded and short, and that is why it was acceptable for #544. It is not acceptable for durable state.

Do not extend Grant to cover this. A grant is a transient session capability that expires in minutes; a persistent-storage record is durable state that must resist rollback across power cycles. Different lifetimes need different anchors — a wall-clock expiry is meaningless to an attacker who controls the volume and can also present an older clock. Folding a version into Grant would give one type two lifecycles and make the weaker one the default.

What should be shared is the verification discipline, not the struct: the ordering of checks, the refusal taxonomy, and the property that signature validity is necessary and never sufficient.

Two things worth settling before any code

Where the highest-accepted version lives is the whole problem. Rollback resistance reduces entirely to a store the attacker cannot roll back. If the anchor sits in the same volume the record does, replaying the volume replays the anchor and the check is decorative. On this platform the candidates are eMMC RPMB (a replay-protected memory block, authenticated with a key the device holds) or a hardware monotonic counter — and whether the MT6739 exposes either is a hardware-fact question I have not answered. Everything else in this acceptance is implementable today; this is the part that decides whether it is worth implementing.

The canonical-serialization clause needs a test, not a claim. postcard is deterministic for a fixed type in practice, but TUF's requirement is stronger: no two byte sequences may verify as the same logical record. That is a property of the decoder accepting non-minimal encodings, not of the encoder. A fixture that hand-builds a non-minimal varint and asserts the decoder refuses it would settle it; until someone writes that, SignedGrant should be read as unverified, not as satisfying the clause.

Suggested slicing

1. The record and its verifier — version, schema id, target, expiry, canonical encoding, and a RollbackAnchor the verifier consults rather than owns. Pure, host-testable, and it is what security: the master-key KDF has no versioned parameter record, so its cost can never be raised #914 (versioned master-key KDF record), security: make CSPRNG wake and reboot reseeding non-repeating #873 (non-repeating reseed epoch) and OlmSession and DeviceKeys key material is never zeroized on drop #831/Olm prekey session keys are derived entirely from values the homeserver holds #902 (persistent device identity) each need a piece of. The anchor being a seam is what lets this land before the hardware question is answered — with the residual risk stated, per this issue's own "enumerate what is confidentiality-only" clause.
2. The durable anchor — blocked on the RPMB/counter fact above.
3. Authenticated volume encryption — XTS → AEAD or an integrity tree; the largest piece and independent of 1 and 2.

The adversarial fixtures the decision requires belong in slice 1 and are the reason to do it first: replay of a valid older record, an expired record, a record for another target, a mixed set. Per the standard the decision itself cites, a refusal suite containing only already-refused cases proves nothing — every fixture has to be authentic-but-wrong.

Source: first-hand read of crates/metaxu-core/src/grants.rs (Grant, SignedGrant::verify, and its boundary tests) at main. The RPMB/monotonic-counter availability on the MT6739 is explicitly not sourced and is the next thing to establish.

[forkwright]

Answering my own open question: the device cannot currently tell whether it has a rollback anchor

I flagged "does the MT6739 expose RPMB or a monotonic counter" as the unanswered fact that decides whether the rollback work is worth doing. It resolves into a dependency rather than a yes or no.

RPMB presence is discoverable, and this driver never looks. An eMMC reports its RPMB partition size in the EXT_CSD register (the field name is RPMB_SIZE_MULT; confirm the exact offset against the JEDEC eMMC spec when implementing rather than trusting this note). crates/thumos/src/emmc.rs:425-427 defines CMD8_SEND_EXT_CSD and marks it:

#[expect(dead_code, reason = "reserved for EXT_CSD readback (#753)")]
const CMD8_SEND_EXT_CSD: u32 = 8;

So the command is named and never issued. There is no EXT_CSD readback, no partition-switch support, and nothing anywhere in the tree that mentions RPMB.

What that means for the three slices.

RPMB is mandatory in eMMC 4.4 and later, so the part very likely has one — but "very likely" is not a fact a security boundary may rest on, and the device cannot confirm it about itself until EXT_CSD is read. That readback is already #753's declared scope, and it is hardware-gated: QEMU models no block medium, so it can only be verified on the M7.

The chain is therefore:

slice 2 (durable anchor) → RPMB access → EXT_CSD readback (#753) → real hardware

That is three steps of which the last is operator-gated, and it confirms the slicing rather than changing it: slice 1 is the part that can be built and proved now, with the anchor as a seam the verifier consults. Its adversarial fixtures — authentic-but-older, expired, wrong-target, mixed-set — are all exercisable against an injected in-memory anchor, and they are the substance of the operator's TUF decision.

One consequence worth stating plainly rather than discovering later. Until slice 2 exists, slice 1's rollback resistance is only as strong as wherever the highest-accepted version is kept — and if that is the same volume the record lives on, an attacker who replays the volume replays the anchor with it. Slice 1 must therefore ship saying so, under this issue's own clause requiring confidentiality-only data to be enumerated with its residual risk. A versioned record with a rollback check that an attacker can also roll back is not rollback resistance; it is the shape of it, and the difference has to be written down where a reader of the code will meet it.

Source: first-hand — crates/thumos/src/emmc.rs:425-427 and a tree-wide search for RPMB returning nothing, at main. The JEDEC field name is from recall and is flagged above as needing confirmation; the eMMC-4.4 mandatory-RPMB claim is spec knowledge, not something I verified against a document in this session.