Rotating the Keys of a Live Stream

Set how often the content key changes, how many viewers are watching and how far apart their players sit behind the live edge. The page counts the keys, the licence requests they cause and the load those requests put on the licence server when the key changes, for three ways of getting each key to a player.

Worked example — Rotating the Keys of a Live Stream

Crypto periods in the run	262,800
Content keys	262,800
Key material, at 16 bytes a key	4.20 MB
Licence requests per viewer	262,800
Licence requests in all	2.628×10¹¹
Average load on the licence server	8,333 /s
Peak load	100,000 /s
Peak over average	12.0×

These are the values the calculator shows when the page opens. Change any input above to recompute them.

Loading interactive simulation...

Lesson

The theory — Rotating the Keys of a Live Stream

A content key is the AES key that encrypts the media. A player gets it inside a licence from a licence server, made out to that one device. Key rotation replaces the content key every crypto period while a live stream runs, so the player needs a new key each time. In a key hierarchy the licence carries a root key instead, and the content keys, called leaf keys there, travel inside the stream itself and are usable only with the root.

What each symbol means

T: the crypto period, how long one content key is in use, in seconds
N: viewers watching at the same time
w: how far apart their playheads sit behind the live edge, which is the window all of them cross a key boundary in
R: how long a root key lasts in a hierarchy, in hours

Assumes: One licence request per viewer per boundary, carrying every key of the period, and every viewer watching for the whole run. Asked on change, the requests spread evenly over the w seconds after a boundary; fetched ahead, evenly over the whole period. Real arrivals bunch and scatter around those averages and a server is sized with margin for it, so the peaks here are a floor for what a server must carry. Viewers joining and leaving, retries after a failed request and the licence every player fetches when it starts are left out.
Breaks when: When the key that leaks is the device's own. Rotation bounds what one content key opens and a hierarchy bounds what one root key opens, but a player whose device key has been extracted can go on asking for, or unwrapping, every key the service issues it. No crypto period helps then. The device has to be refused its licences, or, where there is no licence server to refuse them, revoked, which is what the device revocation page counts.

262,800 keys are the easy part 🖖

Press A year at two minutes. A year is 31,536,000 seconds, one key every 120 of them is 262,800 content keys, and at 16 bytes a key the whole year's key material is 4.20 MB. Nobody's key store notices that. What the count really measures is a question every viewer has to ask: 262,800 licence requests from each of them, and from a million viewers 2.628×10¹¹, an average of 8,333 a second for as long as the stream runs. Press Four keyed tracks: audio and three video qualities, each under its own key, and DASH-IF's key exchange format lists encrypting SD, HD and UHD separately among the reasons a stream carries several. The keys go up to 1,051,200 and the requests do not move, because one licence can carry all four.

When players ask sets the peak, and how often the key changes does not 🖖

With A year at two minutes still pressed, look at the requests chart. Every player meets the new key ID at the boundary and asks for the key then, and with their playheads spread over 10 seconds a million requests land inside those 10 seconds: 100,000 a second, 12.0 times the average. DASH-IF's guidelines say it of this very scheme: "all players will perform license requests at the same time". Press Fetched ahead. The same requests, each made at a random moment in the period before, arrive at 8,333 a second and the wall is gone. The ladder under the table shows the other half. Rotate every 10 seconds or once a day and the on-change peak is 100,000 a second either way; a shorter period buys more peaks, 8,640 a day at 10 seconds against 720 at two minutes, and never a taller one.

A key hierarchy trades requests for exposure, one for one 🖖

Press Key hierarchy. A root licence fetched once a day unlocks each two-minute leaf key as it arrives inside the media segments, so a viewer makes 365 requests a year instead of 262,800, 720 times fewer. DASH-IF describes this arrangement "in scenarios where a license request is only performed once per day". The price is in the last row. One leaked content key opens two minutes of what it encrypts; one leaked root key opens every leaf key until the root changes, 24 hours of stream, which is 720 periods. The factor that comes off the licence server goes onto the leak, because both are the root's lifetime divided by the crypto period. And the root change is still a wall of 100,000 requests a second, once a day instead of 720 times, unless the root licences are fetched ahead as well. None of it makes any one key harder to break. The same guidelines put it flatly: changing the content keys "does not increase the cryptographic security of content protection".

Problem solved in full

Can one licence server carry a final? 4 steps
How short can the crypto period be? Press A cup final: 3,000,000 viewers, keys rotating every two minutes and fetched ahead, 25,000 requests a second. The licence server is rated for 20,000. Find the shortest crypto period it can carry with the keys fetched ahead, what asking on change would demand of it, and what a daily root key fetched ahead would cost instead.

Open this problem in the tool
1. Fetched ahead, every viewer asks once a period and the asks spread evenly across it, so the load is N/T. It has to stay at or under the server's 20,000.
  
  $\frac{N}{T} \leq C = 20, 000 / s$
2. At two minutes the load is 1.25 times the rating. Solve for T instead: no shorter than 150 seconds.
  
  $\frac{3 , 000 , 000}{120} = 25, 000 / s = 1.25 C T \geq \frac{N}{C} = \frac{3 , 000 , 000}{20 , 000} = 150 s$
3. Asked on change, the whole audience asks inside the 10 seconds its playheads are spread over: 300,000 a second, fifteen times the rating, at every boundary. T does not appear in N/w, so no crypto period fixes it; only playheads 150 seconds apart would.
  
  $\frac{N}{w} = \frac{3 , 000 , 000}{10} = 300, 000 / s = 15 C$
4. In a hierarchy with a daily root whose licences are fetched at random moments during the previous day, the only requests are the roots, N over the 86,400 seconds of a day.
  
  $\frac{N}{86 , 400} = \frac{3 , 000 , 000}{86 , 400} = 34.72 / s$
Answer

At least 150 s fetched ahead, 300,000 a second on change, 34.72 a second with a daily root fetched ahead. Two-minute rotation does not fit this server whichever way the content keys are handed out one at a time, and two and a half minutes fits it with no margin at all. The hierarchy fits 576 times over and pays for it the way the third insight says: one leaked root key opens a whole day of the final.

$\frac{20 , 000}{34 . 72} = 576$

References (2)

The three delivery modes the page compares, and its three quotations: key rotation signalled in-band so every player asks at once (§9.3), the key hierarchy with a root licence once a day (§9.4), and rotation's purpose stated as re-authorisation rather than security (§9.2): DASH Industry Forum, DASH-IF Interoperability Points, Part 6: Content Protection. DASH-IF IOP-6 V5.0.0, January 2022, clause 9 Key rotation.
How a packager is handed one content key per crypto period, why a stream carries several keys at once, and the two-level root and leaf hierarchy: DASH Industry Forum, DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX), version 2.2, §6.2 Key Rotation Support and §6.3 Hierarchical Keys.

By the 42Math team · Reviewed against published sources. Corrections welcome.