Which TUF roles can hold online keys, and what does stealing them let an attacker do?
answer
- what has to be signed every cycle
- what only changes at a release
- the hot key should be the cheapest to lose
- threshold means independent custodians
- denial and delay, not authorship
basics
~20 sOnly snapshot and timestamp must sign continuously, so only they need online keys. Stealing them lets an attacker withhold or hold back updates, but not introduce a new artifact — that still requires the offline targets key.
solid answer
~50 sThe role split exists so that the keys which have to be hot are the ones worth least to an attacker. `timestamp` is re-signed every cycle and `snapshot` every time the repository publishes, so both live on internet-facing infrastructure. `targets` is exercised only at release and `root` almost never, so both stay offline — root typically behind a threshold such as 3-of-5 keys held by different custodians in different places, so a single stolen key is worthless. Now the payoff: an attacker who owns the repository host and both online keys can pin clients to an older still-signed set and can make a stale snapshot look current, but cannot describe a new artifact, cannot change any hash, and cannot designate new signers. They get denial and delay, not authorship. That bounded outcome is the entire claim TUF makes about a compromised repository, and it evaporates the moment the targets key is moved onto the publishing host for convenience.
go deeper
Know that some TUF roles sign constantly and some rarely, and that the rarely-used ones are meant to be kept offline. The idea that not all signing keys carry the same power is the takeaway.
Explain why snapshot and timestamp must be online — publish cadence and liveness proof — and why targets and root need not be. Be able to state what each stolen key allows in concrete terms.
Reason about the breached signing host: what the attacker gains, what stays out of reach, and how the abuse shows up as freshness failures rather than novel artifacts. Name the shortcuts that quietly collapse the separation.
Own the trade between release throughput and compromise resilience. Be ready to defend refusing an offline targets key to an automated release pipeline, and to say what threshold and custodian independence you would require of a consortium.
## The design question A repository has to publish constantly, and something has to sign every time it does. The naive answer is to put the signing key on the publishing host — at which point breaching that host is equivalent to owning the project. TUF's answer is to ask a sharper question: *what is the least authority that has to be exercised continuously?* Then give only that authority to the key that must be online. Take a consortium-run artifact repository serving several member organisations. The decision on the table is which roles may hold keys on the always-on signing host and which stay in an offline ceremony. ## Role by role | Role | Where the key lives | What compromise of that key alone buys | | --- | --- | --- | | root | offline, threshold of several custodians | below threshold, nothing; at threshold, the power to re-designate every other role | | targets | offline, used at release | the ability to publish arbitrary content as authentic | | snapshot | online | the ability to pin clients to an older, still-signed version set | | timestamp | online | the ability to make a stale snapshot look current until it expires | Snapshot must be re-signed on every publish because the set of current targets versions changes. Timestamp must be re-signed every cycle because its whole purpose is to prove liveness. Neither can be an offline ceremony without destroying the update cadence. Targets, by contrast, changes only when a release happens, and root only when signers change — both are events a human can attend. ## What the attacker actually gets Assume the worst realistic case short of a ceremony failure: the signing host is breached and both online keys are exfiltrated. The attacker can now sign snapshot and timestamp freely. What that lets them do is choose *which already-signed targets metadata clients see, and when*. They can freeze the fleet on the current set, or point snapshot at an older targets version and hold back clients that have not yet recorded the newer one. What they cannot do is far more important. They cannot add an artifact, because artifact hashes live in targets metadata signed by an offline key. They cannot alter an existing artifact's hash for the same reason. They cannot appoint themselves a new signer, because that requires root. The damage ceiling is availability and staleness, and both are detectable: clients start failing on expiry, and a repository that monitors its own published metadata sees snapshot versions it did not produce. This is the property TUF is actually selling, and it is the answer to "what does a full repository compromise buy?". Not much — *provided the role separation was real*. ## Thresholds A threshold is M-of-N: the role's metadata is only valid when at least M of the N declared keys have signed it. Its value is entirely about independence. Five keys in one safe, or five keys in one key-management account with one administrator, is a 1-of-1 wearing a costume. Five keys held by five people in five organisations means an attacker needs three simultaneous, coordinated compromises. Thresholds are cheapest to apply where signing is rare, which is another reason they concentrate on root and targets: you cannot realistically convene three custodians every fifteen minutes to re-sign timestamp. ## The ways this gets quietly undone The most common is putting the targets key on the publishing host "just for the automated release job". That single move converts every online compromise from denial into authorship, and it usually happens for release-throughput reasons rather than as a security decision. The second is treating "offline" as "encrypted at rest on the build server" — if the automation can decrypt it unattended, it is online. The third is a threshold whose keys share one custodian or one recovery path. ## Detection and recovery shape Because online-key abuse produces stale or regressing metadata rather than novel artifacts, the detections are freshness detections: clients reporting expired metadata, and published snapshot versions the repository cannot account for. Recovery runs through root: publish a new root version listing replacement snapshot and timestamp keys, which clients adopt by verifying it against the root they already trust. Version numbers are reset when a role's keys are replaced, so an attacker who published an absurdly high version cannot lock out legitimate future ones. The procedural side of holding, splitting and recovering those keys is a custody discipline of its own; what matters here is the design decision that precedes it — which authority is allowed to be continuously available at all.
- If the online keys can only cause denial, why not put the targets key online too?Because that is the whole guarantee. The claim TUF makes about a compromised repository — that the attacker cannot make clients install something new — rests entirely on the content-describing key being unavailable to the breached host. Move targets online and a single intrusion escalates from delaying updates to publishing arbitrary artifacts as authentic, which is the failure the framework was designed around.
- A repository holds a 3-of-5 root threshold, all five keys in one hardware appliance. What has it bought?Almost nothing against compromise. A threshold only converts into attacker effort when the N keys have independent custodians, locations and recovery paths; five keys behind one administrator and one appliance fail together. It still helps with availability — losing one key does not block signing — but do not present it as compromise resistance in a review.
- What is the recovery path once you know the online keys were stolen?Publish a new root version that lists replacement snapshot and timestamp keys. Clients verify it against the root version they already trust, so no out-of-band redistribution is needed, which is exactly why root lists keys for every role including itself. Version numbers for the rotated roles are reset so an attacker who published a very high version cannot block legitimate future ones.
The key you leave in the ignition should start the radio, not the car.
saying these in an interview costs you the question
- Puts all four role keys online for automation
- Claims stolen online keys allow publishing a malicious artifact
- Treats a threshold as useful with keys on one host
- Calls a key on the build server offline because it is encrypted
- Cannot name what a repository compromise still cannot achieve