Set-top boxes ship with one trust anchor and can never be given another - how long must that root signing key live, and how do you plan its succession?

## The constraint that decides everything else A firmware channel for set-top boxes inverts the usual assumption. Normally the verifier is a browser or a server runtime that updates itself, so a trust decision made today can be revisited. Here the verifier is a sealed appliance in somebody's living room. It holds one anchor, burned in at manufacture. There is no recall, and a device that will not accept a signature cannot be given a new anchor **because the mechanism for delivering one is itself authenticated by the anchor**. That circularity is the whole problem, and every other decision on this leaf is downstream of it. ## Why the lifetime is not a policy choice The required lifetime is not something you pick; it is measured off the fleet: - the service life of the hardware - for consumer appliances commonly a decade and a half or more, because devices stay in use far longer than the manufacturer plans for; - plus the shelf tail: units built in the last production run and switched on for the first time two years later; - plus the period after you stop selling them, during which the channel still has to work. Two things must cover that whole span, and candidates usually name only the first: the **key material** must remain uncompromised and usable, and the root certificate's own `notBefore`/`notAfter` window must still be open, because a device that checks dates will reject an expired anchor. Getting the key right and the validity window wrong produces exactly the same outcome as losing the key. ## Split the hierarchy, then the lifetimes stop fighting The classic arrangement exists precisely because one key cannot be both long-lived and operationally available: 1. **The root key stays offline.** It is generated in a witnessed ceremony, kept where no network reaches it, and used only for a handful of operations - certifying a subordinate issuing authority, and eventually its successor. 2. **A subordinate issuing authority does the daily work.** Its key is online, shorter-lived, and replaceable: if it is compromised, you certify a new one with the root and the fleet keeps working, because the anchor never changed. 3. **The devices verify a path** from a signed firmware image up to the anchor they hold, which means the replaceable part of the hierarchy is the part that is exposed. This converts the most likely incident - compromise of an online, network-reachable signing service - from fleet-ending into a scheduled recovery. It does nothing for the unlikely one, and that asymmetry is the point. ## What offline actually buys, and what it costs | | what you get | what you pay | |---|---|---| | key unreachable from any network | remote compromise is off the table; an attacker needs physical access plus the quorum | you cannot respond quickly to anything that needs the root | | use only under ceremony | every use is witnessed, scripted and recorded | ceremonies are expensive, and one that is never rehearsed fails on the day it matters | | media held in split custody | no single person can use the key | custodians leave, media ages, formats and readers become obsolete over twenty years | The third row is the one that bites on this timescale. A key you must still be able to use in 2045 has to survive people, buildings and storage technology, and that is an organisational commitment more than a technical one. ## The algorithm decision is a manufacture-time decision Because the verifier is frozen, the box can only check signatures made with algorithms its firmware already implements. So: - Choose parameters that you would still defend at the far end of the window, not the near end. - If you want the option of a successor algorithm, **implement it in the shipping firmware** even though nothing will use it for years. An algorithm you did not ship is an algorithm you can never adopt. - If you want the option of a successor key, it has to be present at manufacture as well, and then it is dormant material you must protect for the same two decades with no operational benefit in the meantime. That protection cost is real and is the honest argument against doing it. ## The judgment, and how to defend it There is no correct answer here, which is what makes it a lead's decision. The defensible position states its own failure mode: *we run one offline root whose key and certificate cover the fleet's full life plus the shelf tail, with a subordinate issuing key rotated on a routine schedule to absorb operational compromise; we ship a second algorithm in firmware so migration is possible without a recall; we accept that a root compromise is unrecoverable and price the ceremony, the custody and the rehearsals accordingly.* What makes it credible is not the design but the second half - naming the outcome you have chosen not to survive, and showing that the money went where that risk is. The common failure is arguing this as a cryptography problem. It is a logistics problem with a cryptographic constraint: the key is easy, the twenty years of custody and the un-recallable verifier are the work.