Jeden zehnten Block verschlüsseln (CENC cbcs)

Lege die Größe eines Video-Slices fest und wie viele Bytes im Header unverschlüsselt bleiben. Die Seite verschlüsselt es wie Common Encryption: mit cbcs (jeder zehnte Block) oder cenc (jedes Byte). Sie markiert den Chiffretext und rechnet zusammen, was das für den gesamten Stream und das entschlüsselnde Gerät bedeutet.

Rechenbeispiel — Jeden zehnten Block verschlüsseln (CENC cbcs)

Geschützter Bereich ab Header	20.801 B
Ganze 16-Byte-Blöcke und Rest	1.300 Blöcke + 1 B
Chiffretext-Bytes im Slice	2.080 B
Chiffretext-Anteil im Slice	9,98%
Erstes Chiffretext-Byte bei	32 B
Slices pro Sekunde (Bitrate)	30,0 /s
Chiffretext-Anteil AAC-Frame	98,53%
Chiffretext-Anteil am Stream	12,19%

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 — Jeden zehnten Block verschlüsseln (CENC cbcs)

Common Encryption (ISO/IEC 23001-7) erlaubt es, mit einem einzigen Satz verschlüsselter Dateien mehrere DRM-Systeme zu bedienen. Es verschlüsselt Medien-Samples mit AES-128 und hält deren Struktur lesbar. Jedes kodierte Video-Slice wird in einen Klartext-Teil (Länge der NAL-Einheit, Header und Slice-Header) und einen anschließenden geschützten Bereich aufgeteilt. Das cenc-Verfahren wendet AES im Counter Mode auf jedes Byte dieses Bereichs an. Das cbcs-Verfahren führt AES im CBC-Modus über ein Muster aus ganzen 16-Byte-Blöcken aus. Ein Block wird verschlüsselt, neun bleiben unverschlüsselt. Dieses Muster wiederholt sich bis zum Ende des Bereichs. Ein unvollständiger Block am Schluss bleibt immer unverschlüsselt.

Was die einzelnen Symbole bedeuten

L: Das Slice, also eine kodierte NAL-Einheit in Bytes
h: Der Klartext-Header: Längenpräfix, NAL-Header und Slice-Header, die durch Subsample-Verschlüsselung lesbar bleiben
B: Ganze 16-Byte-Blöcke im geschützten Bereich P = L − h; cbcs verschlüsselt ⌈B/10⌉ davon

Setzt voraus: Eine einheitliche Slice-Größe für den gesamten Stream. Ein echter Encoder schreibt große Slices für Bilder, aus denen andere vorhergesagt werden, und kleine für den Rest. Die Zahlen pro Slice gelten also jeweils für sich. Die Stream-Werte beschreiben hingegen einen Stream aus gleich großen Slices. Der Klartext-Header ist standardmäßig 32 Bytes lang, da dies die einzige durch eine Spezifikation festgelegte Länge ist. Apples SAMPLE-AES belässt das NAL-Typ-Byte und die folgenden 31 Bytes unverschlüsselt. Ein CENC-Packager lässt exakt die Header unverschlüsselt, die von Slice zu Slice variieren. Parametersätze, SEI-Nachrichten und die MP4-Boxen um die Samples bleiben klar und sind hier ausgenommen. Der Chiffretext-Anteil einer echten Datei fällt daher etwas geringer aus. Audio liegt als AAC-LC bei 48 kHz vor, umfasst 1024 Samples pro Frame und wird verschlüsselt. Ein Dienst, der sein Audio unverschlüsselt ausliefert, nimmt dieses Audio auch aus der Rechenarbeit heraus.
Versagt, wenn: Als Methode, um irgendetwas anderes als die Bilder zu verbergen. Die Klartext-Header sollen gelesen werden. Sie verraten jedem, der die Datei besitzt, den Typ jedes Slices, die Größe jedes Frames und das Timing des gesamten Streams. Der Schlüssel wird dafür nicht benötigt.

Jeder zehnte Block ist nicht jedes zehnte Byte 🖖

Drück auf Ein Slice mit 48 Byte: Ein Drittel davon besteht aus Chiffretext. Das Muster beginnt mit dem verschlüsselten Block. Ein geschützter Bereich aus B vollständigen Blöcken enthält daher ⌈B/10⌉ verschlüsselte Blöcke; besteht der Bereich aus einem einzigen Block, enthält er einen verschlüsselten. Drück auf Ein Slice je Makroblockzeile: 306 Byte, 10,46 %. Die Stufenleiter zeigt die übrigen Werte: 16,00 % bei 100 Byte und 8,00 % bei 200 Byte. Mit diesem 32-Byte-Header liegen alle Größen ab 10 kB zwischen 9,95 % und 10,11 %. Der unverschlüsselte Header und der unvollständige Block am Ende drücken den Anteil nach unten, das Aufrunden von B/10 zieht ihn nach oben. Das Verfahren sorgt nicht dafür, dass sich beides genau ausgleicht. Das untere Diagramm zeigt alle Größen zugleich: einen Sägezahn, dessen Zacken mit wachsendem Slice kleiner werden. Bei einem Zehntel pendelt sich der Anteil erst ein, wenn ein Block mehr oder weniger kaum noch ins Gewicht fällt.

Die unverschlüsselten neun Zehntel sind aufgrund der Position des zehnten unlesbar 🖖

Schau dir den Blockstreifen unter dem Frame an. Unabhängig von der Größe des Slice gilt: Sobald auf den unverschlüsselten Header mindestens ein vollständiger Block folgt, ist das erste Byte danach Chiffretext. Anschließend kommen die unverschlüsselten Bytes in Abschnitten von höchstens 144 Byte. Davor steht jeweils ein 16-Byte-Block, den niemand ohne Schlüssel lesen kann. Ein Slice ist entropiecodiert. Der Decoder liest seine Bits der Reihe nach und erkennt erst beim Decodieren, wo ein Makroblock endet. Deshalb kann er den unlesbaren Block nicht überspringen und im unverschlüsselten Abschnitt dahinter weitermachen: Am ersten solchen Block ist Schluss. In einer geschützten Spur wird jedes codierte Slice so behandelt, einschließlich der Bilder, auf deren Grundlage die anderen vorhergesagt werden. Ein Abspielprogramm ohne Schlüssel kann die Header also auswerten, aber keine Bilder darstellen. Dass die Header lesbar bleiben, ist Absicht. ISO/IEC 23001-7 legt die Teilbereichsverschlüsselung fest, „um die normale Verarbeitung und Bearbeitung von Video-Elementarströmen vor der Entschlüsselung zu ermöglichen“.

cbcs spart neun Zehntel der Video-Rechenarbeit und nichts beim Audio 🖖

Klick auf 360p auf dem Handy. Das Video besteht noch immer zu 9,98 % aus Chiffretext. Audio besitzt keine NAL-Einheiten, durch die ein Muster wandern könnte. Daher wird es ohne Muster verschlüsselt: jeder ganze Block jedes Frames. Das entspricht 98,53 % eines AAC-Frames. Bei 1,5 Mbit/s macht die 128-kbit/s-Tonspur 7,86 % der Bytes und 45,69 % der AES-Rechenarbeit aus. Auf den gesamten Stream bezogen leistet cbcs 5,90-mal weniger Entschlüsselung als cenc, nicht zehnmal. Klick auf 1080p, 5 Mbit/s. Dieselbe Tonspur beansprucht hier 20,15 % der Arbeit, was einer Einsparung um den Faktor 8,20 entspricht. Der Standard selbst begründet die Musterverschlüsselung damit, dass sie die von Geräten zum Entschlüsseln von Videospuren benötigte Rechenleistung reduziert. Das gewählte Wort ist Video.

Aufgabe vollständig gelöst

Die maximale Überverschlüsselung durch ein 1:9-Muster 3 Schritte
Wie weit über ein Zehntel kann ein Slice hinausschießen? Klick auf Slice je Makroblockzeile: 306 Bytes, 10,46 % Chiffretext. Die Seite gibt jeweils ein Slice aus. Finde den größten Anteil, den cbcs bei einem Slice von mindestens 1.000 Bytes mit einem 32-Byte-Header verschlüsseln kann. Vergleiche, wie dieser schlimmste Fall bei wachsenden Slices schrumpft.

Öffne diese Aufgabe im Tool
1. Der Anteil beträgt 16⌈B/10⌉/L. Solange ⌈B/10⌉ konstant bleibt, fällt der Wert mit wachsendem L. Die schlimmsten Größen sind jene, bei denen gerade ein neuer verschlüsselter Block begonnen hat. Das ist ein geschützter Bereich von exakt 10k + 1 ganzen Blöcken, von denen k + 1 verschlüsselt sind.
  
  $P = 16 (10 k + 1) \Rightarrow L = h + 16 (10 k + 1), E = k + 1$
2. Bei diesen Größen ist L = h + 16(10k + 1). Dividiere das und spalte das Zehntel ab. Übrig bleibt der Überschuss über 10 %. Das ist eine feste Anzahl von Bytes dividiert durch L.
  
  $\frac{16 ( k + 1 )}{h + 160 k + 16} = \frac{1}{10} + \frac{16 - \frac{h + 16}{10}}{L}$
3. Mit h = 32 beträgt der Überschuss 11,2 Bytes über L. Die erste schlimmste Größe ab 1.000 Bytes ist k = 6. Das sind 61 ganze Blöcke, von denen 7 verschlüsselt sind, in einem Slice von 1.008 Bytes.
  
  $h = 32 : \frac{1}{10} + \frac{11 . 2}{L}, k = 6 : L = 32 + 16 \times 61 = 1, 008$
Antwort

112 Bytes von 1.008, also 11,11 %. Nichts ab 1.000 Bytes schneidet schlechter ab. Der Überschuss fällt proportional zu 1/L. Das schlimmste Slice ab 10.000 Bytes liegt bei 10.128 Bytes und 10,11 %. Das ist genau die Obergrenze des Bereichs, den die erste Erkenntnis nennt. Die Formel verrät auch, welcher Header die Überverschlüsselung beendet. Der Überschuss beträgt 16 − (h + 16)/10 Bytes. Bei h = 144 ergibt das null. Ein Slice mit einem Klartext-Header von 144 Bytes oder mehr hat somit bei keiner Größe jemals mehr als ein Zehntel Chiffretext.

$\frac{16 \times 7}{1 , 008} = \frac{112}{1 , 008} = 11 . 11% 16 - \frac{h + 16}{10} \leq 0 ⟺ h \geq 144$

Quellen (3)

The standard itself. Paywalled; the publisher's preview is openly readable and carries the introduction, the scope and the table of contents, which is where the page's two quotations come from: ISO/IEC 23001-7:2023, Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files. 4th edition. Preview via iTeh Standards.
The cbcs rules as a working decryptor applies them, with the standard's §9.6.1 and §10.4.2 quoted in its comments: the pattern over whole blocks, the partial block left clear, and a 0:0 pattern meaning every block: The Chromium Authors, media/cdm/cbcs_decryptor.cc, Chromium source tree (BSD licence).
HLS's transport-stream format, SAMPLE-AES, which uses the same one-block-in-ten pattern with a fixed 32-byte clear leader. RFC 8216 names it as the format for non-fMP4 segments and 'cbcs' for fMP4 ones: Apple Inc., "MPEG-2 Stream Encryption Format for HTTP Live Streaming", §2.2 H.264 Video Streams and §2.3 Audio Streams. Documentation Archive, updated 2015-10-29.

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