Encrypting One Block in Ten (CENC cbcs)

Set the size of a video slice and how many bytes of header stay clear. The page encrypts it the way Common Encryption does, with cbcs's one block in ten or cenc's every byte, marks which blocks are ciphertext, and adds up what that means for a whole stream and for the device that has to decrypt it.

Worked example — Encrypting One Block in Ten (CENC cbcs)

Protected range after the clear header	20,801 B
Bytes of the slice that are ciphertext	2,080 B
Share of the slice that is ciphertext	9.98%
Where the first ciphertext byte sits	32 B
Slices a second at this bitrate	30.0 /s
Share of each AAC frame that is ciphertext	98.53%
Share of the whole stream that is ciphertext	12.19%
AES blocks the device decrypts each second	4,884 /s

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

Loading interactive simulation...

Lesson

The theory — Encrypting One Block in Ten (CENC cbcs)

Common Encryption (ISO/IEC 23001-7) lets one set of encrypted files serve several DRM systems. It encrypts media samples with AES-128 and keeps their structure readable: each coded video slice is split into a clear part, the NAL unit's length, header and slice header, and a protected range after it. The cenc scheme runs AES in counter mode over every byte of that range. The cbcs scheme runs AES in CBC mode over a pattern of whole 16-byte blocks, one encrypted and nine left clear, repeated to the end of the range, and a partial block at the end stays clear.

What each symbol means

L: the slice, one coded-slice NAL unit, in bytes
h: the clear header: length prefix, NAL header and slice header, which subsample encryption leaves readable
B: whole 16-byte blocks in the protected range P = L − h; cbcs encrypts ⌈B/10⌉ of them

Assumes: One slice size for the whole stream. A real encoder writes large slices for the pictures others are predicted from and small ones for the rest, so the per-slice figures hold slice by slice and the stream figures describe a stream of equal slices. The clear header is 32 bytes by default because that is the one length a specification fixes: Apple's SAMPLE-AES leaves the NAL type byte and the 31 bytes after it clear. A CENC packager clears exactly the headers, which vary from slice to slice. Parameter sets, SEI messages and the MP4 boxes around the samples are clear and are left out, so a real file's ciphertext share is a little lower. Audio is AAC-LC at 48 kHz, 1024 samples a frame, and encrypted; a service that leaves its audio clear takes the audio out of the work as well.
Breaks when: As a way to hide anything but the pictures. The clear headers are there to be read, and they give away the type of every slice, the size of every frame and the timing of the whole stream to anyone holding the file, with the key or without it.

One block in ten is not one byte in ten 🖖

Press A 48-byte slice: a third of it is ciphertext. The pattern starts with the encrypted block, so a protected range of B whole blocks carries ⌈B/10⌉ encrypted ones, and a range of a single block carries one. Press One slice per macroblock row: 306 bytes, 10.46%. The ladder gives the rest, 16.00% at 100 bytes and 8.00% at 200, and with this 32-byte header every size from 10 kB up lands between 9.95% and 10.11%. The clear header and the partial block at the end pull the share down; rounding B/10 up pulls it up; nothing in the scheme makes the two cancel. The bottom panel draws every size at once, a sawtooth whose teeth shrink as the slice grows, and a tenth is where it settles only once one block more or less stops mattering.

The clear nine tenths are unreadable because of where the tenth is 🖖

Look at the strip of blocks under the frame. Whatever the slice size, as long as one whole block follows the clear header, the first byte after the header is ciphertext, and from there the clear bytes come in runs of at most 144, each opened by a 16-byte block that nobody without the key can read. A slice is entropy-coded. A decoder reads its bits in order and finds out where one macroblock ends only by decoding it, so it cannot step over the unreadable block and resume in the clear run behind it: it stops at the first one. In a protected track every coded slice is treated this way, the pictures that the others are predicted from included, so a player without the key gets headers it can parse and pictures it cannot draw. Leaving those headers readable is deliberate. ISO/IEC 23001-7 specifies subsample encryption "to enable normal processing and editing of video elementary streams prior to decryption".

cbcs saves nine tenths of the video's work and none of the audio's 🖖

Press 360p on a phone. The video is still 9.98% ciphertext. Audio has no NAL units for a pattern to step through, so it is encrypted without one, every whole block of every frame: 98.53% of each AAC frame. At 1.5 Mbit/s the 128 kbit/s soundtrack is 7.86% of the bytes and 45.69% of the AES work, and on the whole stream cbcs does 5.90 times less decryption than cenc, not ten. Press 1080p, 5 Mbit/s and the same soundtrack is 20.15% of the work, with a saving of 8.20 times. The standard's own case for pattern encryption is that it "reduces the computational power required by devices to decrypt video tracks", and the word it chose is video.

Problem solved in full

The most a 1:9 pattern can over-encrypt 3 steps
How far above a tenth can a slice go? Press One slice per macroblock row: 306 bytes, 10.46% ciphertext. The page prints one slice at a time. Find the largest share cbcs can encrypt of any slice of at least 1,000 bytes with a 32-byte header, and how that worst case shrinks as slices grow.

Open this problem in the tool
1. The share is 16⌈B/10⌉/L. While ⌈B/10⌉ holds still it only falls as L grows, so the worst sizes are the ones where a new encrypted block has just begun: a protected range of exactly 10k + 1 whole blocks, with k + 1 of them encrypted.
  
  $P = 16 (10 k + 1) \Rightarrow L = h + 16 (10 k + 1), E = k + 1$
2. At those sizes L = h + 16(10k + 1). Divide, and split off the tenth: what remains is the excess over 10%, a fixed number of bytes over L.
  
  $\frac{16 ( k + 1 )}{h + 160 k + 16} = \frac{1}{10} + \frac{16 - \frac{h + 16}{10}}{L}$
3. With h = 32 the excess is 11.2 bytes over L. The first worst size at or above 1,000 bytes is k = 6: 61 whole blocks, 7 of them encrypted, in a slice of 1,008 bytes.
  
  $h = 32 : \frac{1}{10} + \frac{11 . 2}{L}, k = 6 : L = 32 + 16 \times 61 = 1, 008$
Answer

112 bytes of 1,008, 11.11%, and nothing of 1,000 bytes or more does worse. The excess falls as 1/L: the worst slice of 10,000 bytes or more is 10,128 bytes at 10.11%, the top of the band the first insight quotes. The formula also says which header ends the over-encryption. The excess is 16 − (h + 16)/10 bytes, which is zero at h = 144, and a slice whose clear header is 144 bytes or longer never has more than a tenth of itself encrypted, at any size.

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

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

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