Supply-chain Security with Signed Targets and Rollback Defense

This lesson does not build or attack a real update service. SEC014-LAB1 is entirely local and synthetic: metadata is fabricated for instruction, targets are harmless text files, and no private key, package manager, external repository, or network operation is used. The goal is to distinguish four different claims: matching target bytes, authorized metadata, a consistent repository view, and fresh/non-rollback client state.

The learner output is Signed Update Trust & Freshness Record v1. Each row preserves Metadata Role / Trusted Key ID / Version / Expiry / Authorized Targets / Target Hash / Observed State / Acceptance Decision / Negative Evidence / Residual Risk.

1. A signature or hash is not the whole trust decision

A matching target hash says the observed bytes match an expected digest. It does not by itself say who was authorized to publish that target, whether the metadata is still fresh, or whether the client has already accepted a newer state. In this lesson, target digest verification is one gate, not the entire trust model.

The same boundary applies to the synthetic signature state. A valid signature flag matters only when the signer is authorized for that role and target namespace. A delegated signer for plugins/ is not silently treated as authority for core/.

2. The four top-level roles make different statements

In the bounded TUF model, root identifies trusted keys and role authority. targets describes authorized target metadata and may delegate narrower namespaces. snapshot ties targets/delegation metadata versions to a consistent repository view. timestamp is short-lived and helps a client detect when it cannot establish a sufficiently fresh snapshot state.

None of these roles proves that software is semantically safe. The lab proves only the declared synthetic trust/freshness decision.

3. Root of trust and role separation

The lab uses opaque identifiers such as key:root-A; it performs no cryptographic signing. The client model checks whether the signer identifier is authorized for the metadata role.

Separating roles bounds authority. Collapsing every responsibility into one online identity would erase useful boundaries between target authorization, repository consistency, and freshness. The model rejects that shortcut.

4. Targets and delegation

The baseline contains core/ and plugins/ namespaces. The delegated plugins-team role is authorized only for plugins/. If a target is moved from plugins/widget-2.1.txt to core/widget-2.1.txt while keeping the same delegated signer, the model returns DENY_DELEGATION_SCOPE.

A synthetically valid signature therefore does not imply unlimited target authority.

5. Snapshot and a consistent view

Snapshot metadata binds versions of targets/delegation metadata into one repository view. In the fixture, the current snapshot is version 12 and the client state records that version 12 has already been accepted.

If the repository presents snapshot version 11, the model returns DENY_ROLLBACK_SNAPSHOT even when target bytes and hash are unchanged. Artifact integrity cannot replace client freshness state.

6. Timestamp and the freeze boundary

The synthetic timestamp has a version, an expiry, and a reference to the current snapshot version. If the timestamp is expired, the client model refuses to make a positive freshness claim and returns DENY_TIMESTAMP_EXPIRED.

This rejection is not proof that a real attacker exists. The observation is only that the synthetic state failed the declared freshness requirement.

7. Rollback and freeze are different failures

Rollback presents state older than what the client has already accepted. Freeze keeps a client on stale state or prevents it from establishing freshness. Both require state beyond a target hash. The evidence record preserves the exact failure boundary rather than collapsing both into a generic integrity failure.

8. Baseline core channel

The baseline root, targets, snapshot, and timestamp records have authorized signer identifiers. Snapshot is version 12 and timestamp is version 40. core/app-2.4.0.txt is directly authorized by the targets role and its digest matches the local fixture.

Running run_local_lab.py should produce ACCEPT_TARGET while exposing separate authority, rollback, freshness, and digest checks. The output is local evidence, not production proof.

9. Baseline delegated plugin channel

plugins/widget-2.1.txt is delegated from targets to plugins-team. The signer must belong to that delegated role and the target path must remain inside the declared namespace before freshness and digest gates can support acceptance.

This demonstrates why a trusted key must always be interpreted together with its role and target scope.

10. Negative evidence: snapshot rollback

The first mutation changes only snapshot version 12 to 11 while client state still records 12 as the minimum accepted snapshot. Target bytes and digest remain unchanged. The decision must stop at the rollback gate.

This proves that artifact integrity and repository freshness are separate claims.

11. Negative evidence: expired timestamp

The second mutation expires the timestamp. The model must refuse the freshness claim without relying on the target digest. The evidence record keeps the observed expiry and a bounded inference: freshness is not established; it does not claim a real attacker has been identified.

12. Negative evidence: delegation scope

The third mutation moves a delegated target outside plugins/*. The synthetic signer remains key:plugins-A and the signature flag remains valid, but path authority is wrong. The result must be DENY_DELEGATION_SCOPE.

This prevents the shortcut “valid signature means unlimited authority.”

13. Evidence completeness

If a record drops fields such as Version, Expiry, Authorized Targets, or Negative Evidence, it can no longer support the bounded decision. The local validator rejects missing and extra fields.

Observed State stores fixture output. Residual Risk remains an inference and explicitly states that the lab proves no real signing operation, package installation, compromise analysis, or semantic malware safety.

14. Changed-context transfer

The transfer case has independent plugin and core-update channels. The learner must rebuild role authority, namespace, version/freshness state, and target evidence instead of copying one channel's delegation into the other.

The transfer template leaves final_decision blank. That blank field preserves human accountability: tooling can report observations, but it does not fill the final trust decision for the learner.

15. Source freshness boundary

The September 20, 2026 recheck stayed inside the three locked source IDs. Official TUF project surfaces no longer provide one unambiguous patch-level Latest label, so this lesson does not assert an exact latest TUF patch. TUF-SPEC binds only the current 1.x specification family used by this lesson. The official roles/metadata page continues to describe Snapshot as a consistent-view mechanism and Timestamp as short-lived freshness metadata, and the official security page documents rollback and indefinite-freeze threats. These sources constrain only the claims declared by the Bible; they are not universal deployment requirements.

16. Completion evidence

SEC-014 requires Signed Update Trust & Freshness Record v1 with a positive case, rollback negative evidence, expired-timestamp negative evidence, delegation-scope negative evidence, and an independent changed-context transfer. owner_acceptance remains blank in the starter. The lesson contains no procedure for attacking, bypassing, or manipulating a real update service.