Rotation der Schlüssel eines Livestreams

Leg fest, wie oft der Content-Schlüssel wechselt, wie viele Zuschauer zusehen und wie weit ihre Player hinter dem Live-Rand verteilt sind. Die Seite zählt die Schlüssel, die dadurch ausgelösten Lizenzanfragen und die Last, die diese Anfragen beim Schlüsselwechsel auf den Lizenzserver ausüben, für drei Wege, wie ein Player jeden Schlüssel erhält.

Rechenbeispiel — Rotation der Schlüssel eines Livestreams

Kryptoperioden in der Laufzeit	262.800
Content-Schlüssel	262.800
Schlüsselmaterial, bei 16 Bytes pro Schlüssel	4,20 MB
Lizenzanfragen pro Zuschauer	262.800
Lizenzanfragen insgesamt	2,628×10¹¹
Durchschnittliche Last auf dem Lizenzserver	8.333 /s
Spitzenlast	100.000 /s
Spitze über Durchschnitt	12,0×

Das sind die Werte, die der Rechner beim Öffnen der Seite anzeigt. Ändere oben eine Eingabe, um sie neu zu berechnen.

Interaktive Simulation wird geladen...

Lektion

Die Theorie — Rotation der Schlüssel eines Livestreams

Ein Content-Schlüssel ist der AES-Schlüssel, der die Medien verschlüsselt. Ein Player erhält ihn innerhalb einer Lizenz von einem Lizenzserver, ausgestellt auf dieses eine Gerät. Schlüsselrotation ersetzt den Content-Schlüssel jede Kryptoperiode, während ein Livestream läuft, sodass der Player jedes Mal einen neuen Schlüssel braucht. In einer Schlüsselhierarchie trägt die Lizenz stattdessen einen Root-Schlüssel, und die Content-Schlüssel, dort Leaf-Schlüssel genannt, reisen im Stream selbst mit und sind nur mit dem Root nutzbar.

Was die einzelnen Symbole bedeuten

T: die Kryptoperiode, wie lange ein Content-Schlüssel im Einsatz ist, in Sekunden
N: Zuschauer, die gleichzeitig zusehen
w: wie weit ihre Playheads hinter dem Live-Rand verteilt sind, was dem Fenster entspricht, in dem sie alle eine Schlüsselgrenze überschreiten
R: wie lange ein Root-Schlüssel in einer Hierarchie gültig ist, in Stunden

Setzt voraus: Eine Lizenzanfrage pro Zuschauer pro Grenze, die jeden Schlüssel der Periode trägt, und jeder Zuschauer schaut über die gesamte Laufzeit zu. Beim Wechsel angefragt, verteilen sich die Anfragen gleichmäßig über die w Sekunden nach einer Grenze; im Voraus abgerufen, gleichmäßig über die gesamte Periode. Tatsächliche Zugriffe ballen und streuen sich um diese Durchschnitte, und ein Server wird mit einer entsprechenden Marge dimensioniert. Die Spitzen hier sind also eine Untergrenze für das, was ein Server tragen muss. Zuschauer, die dazukommen und gehen, Wiederholungen nach einer fehlgeschlagenen Anfrage und die Lizenz, die jeder Player beim Start abruft, werden weggelassen.
Versagt, wenn: Wenn der Schlüssel, der leakt, der eigene des Geräts ist. Rotation begrenzt, was ein Content-Schlüssel öffnet, und eine Hierarchie begrenzt, was ein Root-Schlüssel öffnet. Ein Player, dessen Geräteschlüssel extrahiert wurde, kann jedoch weiterhin jeden Schlüssel anfragen oder entschlüsseln, den der Dienst ihm ausstellt. Da hilft keine Kryptoperiode. Dem Gerät müssen die Lizenzen verweigert werden, oder, wo es keinen Lizenzserver gibt, der sie verweigern könnte, muss es widerrufen werden, was die Seite zum Gerätewiderruf zählt.

262.800 Schlüssel sind der einfache Teil 🖖

Klick Ein Jahr bei zwei Minuten. Ein Jahr hat 31.536.000 Sekunden, ein Schlüssel alle 120 davon ergibt 262.800 Content-Schlüssel, und bei 16 Bytes pro Schlüssel macht das Schlüsselmaterial des gesamten Jahres 4,20 MB aus. Kein Schlüsselspeicher bemerkt das. Was die Zählung wirklich misst, ist eine Frage, die jeder Zuschauer stellen muss: 262.800 Lizenzanfragen von jedem von ihnen, und von einer Million Zuschauern 2,628×10¹¹, im Durchschnitt 8.333 pro Sekunde, solange der Stream läuft. Klick Vier verschlüsselte Spuren: Audio und drei Videoqualitäten, jede unter einem eigenen Schlüssel, und das Schlüsselaustauschformat von DASH-IF führt die getrennte Verschlüsselung von SD, HD und UHD als einen der Gründe an, warum ein Stream mehrere trägt. Die Schlüssel steigen auf 1.051.200 und die Anfragen bewegen sich nicht, weil eine Lizenz alle vier tragen kann.

Wann Player anfragen, bestimmt die Spitze, nicht wie oft der Schlüssel wechselt 🖖

Lass Ein Jahr bei zwei Minuten ausgewählt und schau auf das Anfragediagramm. An der Grenze stößt jeder Player auf die neue Schlüssel-ID und fordert den Schlüssel an. Da die Abspielpositionen über 10 Sekunden verteilt sind, treffen innerhalb dieser 10 Sekunden eine Million Anfragen ein: 100.000 pro Sekunde, das 12,0-Fache des Durchschnitts. In den Richtlinien von DASH-IF heißt es zu genau diesem Verfahren: „Alle Player stellen ihre Lizenzanfragen gleichzeitig.“ Wähle Vorab abgerufen. Dieselben Anfragen werden nun jeweils zu einem zufälligen Zeitpunkt im vorhergehenden Zeitraum gestellt. So treffen 8.333 pro Sekunde ein, und die Wand verschwindet. Die Stufen unter der Tabelle zeigen die andere Hälfte des Zusammenhangs. Ob der Schlüssel alle 10 Sekunden oder einmal täglich wechselt: Die Lastspitze beim Wechsel liegt immer bei 100.000 Anfragen pro Sekunde. Ein kürzerer Zeitraum erzeugt lediglich mehr Spitzen, nämlich 8.640 pro Tag bei 10 Sekunden gegenüber 720 bei zwei Minuten; höher werden sie nicht.

Eine Schlüsselhierarchie tauscht Anfragen gegen Risiko, eins zu eins 🖖

Klick Schlüsselhierarchie. Eine einmal am Tag abgerufene Root-Lizenz entsperrt jeden zweiminütigen Leaf-Schlüssel, sobald er in den Mediensegmenten ankommt. Ein Zuschauer stellt also 365 Anfragen pro Jahr statt 262.800, 720-mal weniger. DASH-IF beschreibt diese Anordnung „in Szenarien, in denen eine Lizenzanfrage nur einmal pro Tag durchgeführt wird“. Der Preis steht in der letzten Zeile. Ein geleakter Content-Schlüssel öffnet zwei Minuten von dem, was er verschlüsselt; ein geleakter Root-Schlüssel öffnet jeden Leaf-Schlüssel, bis der Root wechselt, 24 Stunden Stream, was 720 Perioden entspricht. Der Faktor, der beim Lizenzserver abgezogen wird, kommt auf das Leck oben drauf, weil beide die Lebensdauer des Roots geteilt durch die Kryptoperiode sind. Und der Root-Wechsel ist immer noch eine Wand von 100.000 Anfragen pro Sekunde, einmal am Tag statt 720-mal, es sei denn, die Root-Lizenzen werden ebenfalls im Voraus abgerufen. Nichts davon macht irgendeinen Schlüssel schwerer zu knacken. Dieselben Richtlinien sagen es unmissverständlich: Ein Wechsel der Content-Schlüssel „erhöht die kryptografische Sicherheit des Inhaltsschutzes nicht“.

Aufgabe vollständig gelöst

Kann ein Lizenzserver ein Finale tragen? 4 Schritte
Wie kurz kann die Kryptoperiode sein? Klick Ein Pokalfinale: 3.000.000 Zuschauer, Schlüssel rotieren alle zwei Minuten und werden im Voraus abgerufen, 25.000 Anfragen pro Sekunde. Der Lizenzserver ist für 20.000 ausgelegt. Finde die kürzeste Kryptoperiode, die er mit im Voraus abgerufenen Schlüsseln tragen kann, was eine Anfrage beim Wechsel von ihm verlangen würde und was stattdessen ein täglich im Voraus abgerufener Root-Schlüssel kosten würde.

Öffne diese Aufgabe im Tool
1. Im Voraus abgerufen, fragt jeder Zuschauer einmal pro Periode an, und die Anfragen verteilen sich gleichmäßig über diese. Die Last ist also N/T. Sie muss bei oder unter den 20.000 des Servers bleiben.
  
  $\frac{N}{T} \leq C = 20, 000 / s$
2. Bei zwei Minuten beträgt die Last das 1,25-Fache der Auslegung. Löse stattdessen nach T auf: nicht kürzer als 150 Sekunden.
  
  $\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. Beim Wechsel angefragt, fragt das gesamte Publikum innerhalb der 10 Sekunden an, über die seine Playheads verteilt sind: 300.000 pro Sekunde, das Fünfzehnfache der Auslegung, an jeder Grenze. T kommt in N/w nicht vor, also behebt keine Kryptoperiode das Problem; nur Playheads, die 150 Sekunden auseinanderliegen, würden das tun.
  
  $\frac{N}{w} = \frac{3 , 000 , 000}{10} = 300, 000 / s = 15 C$
4. In einer Hierarchie mit einem täglichen Root, dessen Lizenzen in zufälligen Momenten während des Vortages abgerufen werden, sind die einzigen Anfragen die Roots, N über die 86.400 Sekunden eines Tages.
  
  $\frac{N}{86 , 400} = \frac{3 , 000 , 000}{86 , 400} = 34.72 / s$
Antwort

Mindestens 150 s im Voraus abgerufen, 300.000 pro Sekunde beim Wechsel, 34,72 pro Sekunde mit einem im Voraus abgerufenen täglichen Root. Eine zweiminütige Rotation passt zu diesem Server nicht, egal auf welchem Weg die Content-Schlüssel einzeln ausgegeben werden, und zweieinhalb Minuten passen ganz ohne Marge. Die Hierarchie passt 576-mal und bezahlt dafür, wie es die dritte Erkenntnis besagt: Ein geleakter Root-Schlüssel öffnet einen ganzen Tag des Finales.

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

Quellen (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.

Vom 42Math-Team · Anhand veröffentlichter Quellen geprüft. Korrekturen willkommen.