💻 technology
By WNT
CBCS and CENC: The DRM Battle Nobody Talks About
Your streaming video works because of two encryption schemes most people have never heard of. CENC (Common Encryption) and CBCS (Cipher Block Chaining) determine whether your iPhone, Android phone, or smart TV can actually play that protected content. The wrong choice locks out millions of devices.
Digital Rights Management (DRM) is the bouncer at the door of every streaming service, and the encryption scheme is the dress code. Two main players dominate this space: CENC (Common Encryption) and CBCS (Cipher Block Chaining Scheme). Both are part of the ISO/IEC 23001-7 standard, but they handle video encryption fundamentally differently, and that difference matters enormously for device compatibility.
CENC, specifically the 'cenc' scheme, uses AES-128 CTR (Counter Mode) encryption. It encrypts video in a pattern that works beautifully with older devices and has been the industry workhorse since around 2012. The 'cenc' scheme encrypts full sample data and is supported by virtually every device manufactured in the last decade. It works seamlessly with DASH (Dynamic Adaptive Streaming over HTTP) in MP4 and fragmented MP4 containers, and it is compatible with Widevine, PlayReady, and FairPlay DRM systems. If you have an Android device from 2014 or a smart TV from 2015, CENC is probably why Netflix works on it.
CBCS, the newer 'cbcs' scheme introduced in 2015, uses AES-128 CBC (Cipher Block Chaining) mode with pattern encryption. Apple pushed hard for CBCS adoption because it offers better performance on iOS devices and enables features like offline playback with sample-level encryption. The critical difference is that CBCS uses a constant initialization vector (IV) and encrypts in 16-byte blocks with a pattern (typically encrypting 1 block and skipping 9 blocks in video frames). This pattern encryption means less data to decrypt, which translates to lower battery consumption and better performance on mobile devices. Apple's FairPlay DRM strongly prefers CBCS when used with HLS (HTTP Live Streaming) in TS (Transport Stream) or fMP4 (fragmented MP4) containers.
The protocol and container relationship gets messy quickly. HLS, Apple's streaming protocol, originally used MPEG-TS containers but has increasingly adopted fMP4. When you use HLS with fMP4 and FairPlay DRM, CBCS is the recommended encryption scheme, especially for iOS 10 and later. DASH, the competing standard backed by Google and others, traditionally pairs with MP4/fMP4 containers and works with either CENC or CBCS, though CENC remains more widely supported. Smooth Streaming, Microsoft's protocol, typically uses CENC with PlayReady DRM in fragmented MP4 containers.
Device support is where content providers lose sleep. CBCS requires iOS 9.3 or later for Apple devices, Android 7.0 (Nougai) or later with Widevine L1, and smart TVs manufactured after approximately 2016-2017. Anything older than that cannot decrypt CBCS-encrypted content, period. This is why major streaming services maintain multiple encrypted versions of the same content. They serve CENC to older devices and CBCS to newer Apple devices for optimal performance. The device detection and decision-making happens server-side during the streaming session negotiation.
The practical workflow for a streaming service looks like this:
- Content arrives from production in high-quality master format
- Encoding pipeline creates multiple bitrate versions (adaptive streaming)
- Each version gets encrypted with both CENC and CBCS schemes
- Multiple DRM systems (Widevine, PlayReady, FairPlay) wrap the encryption keys
- Content Delivery Network (CDN) stores all versions
- When a user hits play, their device sends capabilities information
- Server selects appropriate protocol (HLS vs DASH), container (TS vs fMP4), encryption scheme (CENC vs CBCS), and DRM system
- Wrong choice means playback failure or suboptimal performance
The storage and bandwidth costs are staggering. A single 4K movie might require 20-30 different encoded versions, then doubled for CENC and CBCS encryption, resulting in 40-60 files per title. This is why smaller streaming services sometimes choose CENC-only deployment, accepting that iOS devices will not get optimal performance but ensuring maximum device compatibility. The decision between universal compatibility and optimal performance defines modern streaming infrastructure.
My Take
Here's the uncomfortable truth: the streaming industry built itself on a fragmented foundation, and we are all paying for it with duplicate storage, higher CDN costs, and unnecessary complexity. Apple's push for CBCS made technical sense for their ecosystem, but it fractured an already complicated landscape. The result is that every streaming service maintains massive duplicate libraries of encrypted content just to serve different device generations.
The real scandal is that this complexity is entirely invisible to consumers until something breaks. Your elderly parent's 2015 smart TV suddenly cannot play a show because the service switched to CBCS-only delivery to cut costs. Your company's conference room display won't play the training video because someone chose the wrong encryption scheme. These are not hypothetical scenarios, they happen constantly.
The industry needs to pick a direction. Either mandate backward compatibility for a reasonable device lifespan (say, 10 years) or establish clear sunset dates so consumers know when their hardware becomes obsolete. The current system where encryption scheme support determines device longevity, but nobody tells you that when you buy the TV, is fundamentally dishonest. Consumers deserve to know that the encryption standard, not the screen or processor, will kill their device.
What Happens Next
The next battleground is AV1 codec support combined with encryption schemes. As the industry migrates from H.264 and HEVC to AV1 for better compression, the encryption question becomes even more critical. AV1 works with both CENC and CBCS, but device support is still rolling out. Expect major streaming services to maintain triple-encrypted libraries (CENC for legacy, CBCS for modern Apple, and AV1-CBCS for cutting-edge devices) through at least 2027-2028.
Smart TV manufacturers will face increasing pressure to support both schemes indefinitely, but cheaper models will likely drop CENC support for devices sold after 2026 to reduce licensing and implementation costs. This will create a new wave of compatibility complaints as people discover their budget 2027 TV cannot play content from older streaming apps that still use CENC-only delivery.
The real change will come from emerging markets where device lifespans are longer and consumers cannot afford frequent upgrades. If India, Brazil, or Southeast Asian markets demand 15-year device support, streaming services will have to maintain CENC compatibility longer than they would prefer. The financial pressure from these massive markets may actually save backward compatibility for everyone else. Watch for industry consortiums to issue new guidelines on encryption scheme deprecation timelines within the next 18 months.
What History Tells Us
The CENC versus CBCS divide mirrors the earlier codec wars between H.264 and VP8, or the format wars between Blu-ray and HD DVD. In each case, competing technical standards created consumer confusion and industry fragmentation until market forces or consortium agreements resolved the conflict. The difference here is that encryption schemes operate below the surface, invisible to most consumers until something breaks. This makes resolution slower because there is less public pressure to standardize.
The DRM landscape itself has always been fractured. The Content Scramble System (CSS) used on DVDs was famously broken within three years of release. HDCP (High-bandwidth Digital Content Protection) for HDMI connections has gone through multiple versions, each breaking compatibility with older displays. The streaming era promised to simplify content protection, but instead multiplied the complexity by adding protocol layers, container formats, and now multiple encryption schemes. History suggests this will not resolve cleanly, instead, we will layer new standards on top of old ones until the weight becomes unbearable.