Important building blocks for building DRM systems - EME, CDM, AES, CENC and keys

▼Scan the QR code below to learn more about the Audio and Video Technology Conference▼

Translator and Editor: Alex

Technical proofreaders: Liu Shan, Zhou Yaqiao

This article is from OTTVerse by Krishna Rao Vijayanagar.

Easy-Tech#016#——DRM

Anyone trying to understand DRM (Digital Rights Management) will encounter acronyms like AES, CDM, CENC, EME, etc. For beginners, these words are easy to confuse, but only when you understand them can you truly understand DRM. In this article, we will briefly introduce the basic components of DRM: EME, CDM, AES, CENC, and the use of keys and key servers.

Simplified Architecture of DRM System

In the last article , we have seen that DRM uses encryption technology and business rules to control digital content access and consumption.

In simple terms, a DRM system can:

Provides tools and infrastructure for content providers to encrypt content.
Build an ecosystem around encrypted content, allowing content providers to control who decrypts and consumes content.

In the last article, we saw Ram and Shyam pass encrypted messages to each other. Meanwhile, Hari holds the codebook and it's up to him to decide who can read/write the information, remember?

Now, let's take this simple system and replace the components with techniques for securing and distributing video content. See what we got?

As you can see from the image above, we want to securely send a movie to an authenticated user. need:

Request a codebook from the DRM vendor's server
Then encrypt the video with a password book
Send movie video to user
The user requests the codebook to decrypt the video from the server of the DRM manufacturer
Now users can watch movies

Awesome!

Is that all there is to know about DRM?

Do not! We just gave an easy-to-understand example above on how to use DRM to transfer movies securely. This example nicely describes the nature of DRM, but it doesn't work well in reality.

Next, we will rethink and design this simple system step by step to see how it streams video over DRM. come together!

Step 1: Back to ABR Technology

Before discussing the sequence, let's modify the example to fit the ABR model in video delivery.

Review of ABR: Using ABR techniques, movies can be encoded into different rate-resolution combinations (also known as rate ladders) and divided into small video blocks or slices. Each video slice contains several seconds of video and can be decoded individually.

Packaging refers to dividing a movie into small video slices and describing them using a manifest or playlist. When a user wants to play a movie, he needs to play it according to the information of the playlist.

According to the available bandwidth, the player requests a video slice of a specific bit rate version, and the CDN responds and returns the requested slice.

MPEG DASH and HLS are common means of video transmission using ABR. For an in-depth understanding of these technologies, please read: What is HLS (HTTP Live Streaming)? and Easy Tech: What is the MPEG-DASH Protocol .

Let's modify the picture to represent ABR video delivery.

Packaging and CDN-based video delivery are the only steps that have changed.

Alright, now let's get to the encryption part.

Step 2: Video Encryption

Video encryption is when someone intercepts our data, ensuring that they cannot read the data or watch the video content.

Review Encryption: Encryption is a technique used to keep data confidential and prevent unauthorized persons from reading it. Cryptography uses a secret key to convert input data (plaintext) into an alternative form called ciphertext. Converting ciphertext to plaintext is almost impossible without the key.

In practice, however, it is possible to decrypt without the key, but cracking the encryption algorithm by reverse engineering costs a lot (including time, money, and required computing resources).

AES (Advanced Encryption Standard) is one of the most popular encryption technologies. AES, also known as Rijndael (named after the inventor), was introduced in 2001 by the National Institute of Standards and Technology (NIST) as a standard for encrypting electronic data.

The technical highlights of AES include:

Symmetric key encryption algorithm: use the same key for encryption and decryption.
Based on key length, there are three variants: 128bit, 192bit and 256bit. The longer the key length, the harder it is to crack.
Without the key, it would take 1 billion x 1 billion years to crack AES-128, plus a supercomputer.

Since I'm not an expert in cryptography, if you want to learn more about the AES standard, you can check out the AES wiki page.

Note: In the realm of video, encryption is not encoding, and decryption is not the same as decoding. For video, encoding and decoding often refer to compression and decompression, respectively. To learn more about encoding, decoding, and video codecs, read our article: The Complete Guide to Video Encoding .

Is encryption only AES-128?

No, there are other types of encryption, let's take a minute to think about what this sentence means.

If a content provider decides to work with three different DRM companies, and they all use different encryption techniques, it means that the content provider needs to encrypt the video three times, which is a waste of storage space and other resources.

That's why the CENC encryption format was born - reducing the fragmentation trend of the encryption market and reducing storage requirements.

We will talk about it below.

Common Encryption CENC

Before we dive into CENC, let's take a look at OTT streaming protocols, especially CMAF.

MPEG-DASH and HLS are currently the two most commonly used protocols. Other protocols include MSS (Microsoft Smooth Streaming), etc., but we will not discuss them today.

In video transmission, MPEG-DASH usually uses the mp4 container format, and HLS usually uses the MPEG-TS (ts) format. If a content provider uses both MPEG-DASH and HLS, it needs to store a copy in mp4 and ts file formats.

Now, we add the DRM encryption issue. Assuming three DRM vendors use three different encryption standards, the content provider needs to store 2x3=6 copies of each video. What a waste of storage space!

In order to solve the first problem posed by the video streaming protocol, the CMAF standard came into being, which stipulates that video can be stored in the fragmented mp4 container format (fmp4). With the support of MPEG-DASH and HLS, you now only need to create a set of videos, store them in fmp4 format, and use the same set of files for both protocols.

Just make sure you create two video manifests (sigh).

How about unified encryption?

If different DRM technologies use different standards, we still need to store different copies of each file, right?

To this end, MPEG developed the CENC (Common Encryption specification), which stipulates that video can be encrypted using either cenc (AES-128 CTR) or cbcs (AES-128 CBC). CTR stands for counter mode; CBC stands for ciphertext block chaining mode. CENC means that the content provider only has to encrypt the video once, and any decryption module can decrypt it.

Note: As long as the key is absolutely secure, even if the encryption algorithm is exposed, it will not be a problem.

CENC may sound like an easy way to unify DRM, but it's not.

There are three main DRM technologies in the market today: Apple FairPlay, Google Widevine and Microsoft PlayReady:

Apple FairPlay only supports AES-CBC cbcs mode.
HLS only supports AES-CBC cbcs mode (not related to CMAF).
Widevine and PlayReady support AES-128 CTR cenc and AES-128 CBC cbcs modes.
MPEG-DASH using CMAF supports AES-128 CTR cenc and AES-128 CBC cbcs modes.
MPEG-DASH without CMAF only supports AES-128 CTR cenc mode.

As you can see, the CMAF and CENC standards have caused confusion and fragmentation in the streaming world.

The widespread use of CMAF and AES-CBC cbcs modes may be able to end the confusion, but how will they affect legacy devices that only support CTR or only support MPEG-TS?

We'll discuss it next time.

Step 3: Key, Key ID and License Server

So far, we have determined that the video will be encrypted using AES-128bit. At this stage, several issues that arise are:

Where do we get the encryption key for AES-128bit?
How to associate encryption keys with movies?
Where to store encryption keys?

Let us answer them one by one.

Where to get the encryption key for AES-128bit?

Any content provider can manually generate encryption keys using professional software. Alternatively, the necessary tools and software to generate keys are provided by several DRM vendors.

How to tie encryption keys and movies together?

Let's first understand the reasons for this. When you go to a hotel, you have to report the room number to the hotel front desk in order to apply for the room key, right? What you're doing is creating the connection between the key and the room by telling the room number.

Similarly, when you encrypt a movie with a key, we need to establish this link and provide it to the DRM license server (aka hotel front desk).

In DRM, the key ID provides the link between the encryption key and the movie, it is a unique string that is generated when the encryption key is created for a specific movie.

Finally, where to store the encryption key and its key ID?

Encryption keys and key IDs are stored in the KMS (Key Store) that works with the DRM license server.

When the client needs to play an encrypted movie, it requests the decryption key from the DRM license server by providing the key ID of this movie. If the DRM license server approves the request (authentication request), it will ask the keystore to provide the decryption key corresponding to that key ID.

Reviewer's Note: Generally, the application to the DRM license server is not a "decryption key", but a "license". The license server will apply for a decryption key according to the key ID, and then generate a license and issue it to the client.

Bonus question: How is the key ID transmitted to the player?

Rationale: Without the key ID, the license server cannot view the decryption key for a movie.

Answer: The key ID is sent to the video player along with the DASH or HLS manifest. The player parses the manifest, finds the key ID, and then requests the decryption key corresponding to the key ID from the DRM license server.

Now, let's wrap up the discussion around encryption keys, key IDs, and license servers.

The encryption key is kept confidential and needs to be stored in a secure keystore with the corresponding key ID.
The key ID can be "public".
Anyone with the key ID can request the secret key (decryption key) from the license server. It is up to the DRM vendor to authenticate the requester before providing (or refusing to provide) the decryption key.

The diagram below depicts what we just learned about keys, encryption, and license servers.

Step 4: Decrypt the video on the player and key server

On the client side (player application), the user presses the play key to start playing the movie he wants to watch. Now video players need a way to identify if a movie is encrypted. Otherwise, the player will try to play encrypted movies and crash, resulting in a bad user experience.

Signals that a movie is encrypted can be signaled in the following ways:

A note can be added to the manifest stating that the movie is encrypted and providing a key ID.
Another way: insert some bytes containing unique information into the video stream. When the player checks the video stream before playback, it captures this unique information and determines that the movie is encrypted.

The next few steps in the player are more intuitive:

The player discovers the key ID and requests the decryption key from the license server.
The license server uses a predefined mechanism to identify whether a player request is authenticated.
If the license server is authenticated by the player, it will return the license with decryption key information.

We've just sketched a simple solution, but there are a lot of problems, both technically and commercially. Let's take a look at some of the first problems that arise:

1. We have described a prototype "player" that sends a decryption key request to the DRM license server. but:

How does the license server know if the player is trustworthy?
What if the decryption software in the player leaks the key and decrypts the content?

2. If you are a video player developer, do you have to develop decryption modules for each DRM technology? Do you have to update every time when they change the interface?

Also, the sequence of events in the player (client) looks like this:

Get movies and their listings from CDN
Extract the key ID in the manifest
Generate license request
Send the request to the license server
Waiting for a response from the license server
Decrypt content with decryption license from server
Decode decrypted content
Display the decoded movie

A single program or company cannot do all of the above steps.

It will form a tightly coupled architecture and will not enable any open, plug-and-play ecosystem. Let's see what can be done.

Playback Architecture

At the player level, the responsibilities described above are divided into different modules, as follows:

The player is responsible for fetching the movie, parsing the manifest, extracting the key ID, sending requests to the DRM license server, etc.
A separate module (called CDM or Content Decryption Module) is responsible for creating license requests, decrypting and decoding content.

Now, let's look at CDM.

Content Decryption Module CDM

Every DRM vendor offers:

Own mechanism to create license request (via key ID, device identifier, signing request, etc.).
Own mechanism to understand the license response received from the DRM license server (which is also encrypted) and extract the decryption key.
Storing licenses, license renewals, and expiry rules locally on the client side.

With these details, the CDM module can be embedded in browsers such as Chrome, Firefox, Microsoft Edge and Safari.

DRM vendors test and validate these CDMs to ensure:

The license request is well-formed and compliant.
They do not reveal the decryption key.
They do not reveal decrypted and decoded movies.
They can securely store decryption keys according to license specifications (such as how long the keys are stored).
Safely stream videos to the screen without leaking.

For the above reasons, the CDM in the browser is closed source, which is also the source of controversy in the industry and the outside world. Because the outside world can't see the source code in the CDM, people can't trust it.

Note: A few browsers offer the option to turn off CDM, but if you do, you won't be able to watch DRM-protected content. That's the tradeoff for the industry.

Below is a screenshot of the Widevine plugin from the Firefox plugins page (from my Ubuntu 20.04 computer).

Wait, there's another technical detail we haven't discussed yet.

Encrypted Media Extension EME

We already know earlier that the player application needs to "talk" to the CDM in the browser and exchange license information with the license server, right?

Why is this a technical problem as well as a business problem?

Player manufacturers need to integrate all the different license servers and CDMs, and keep track of changes to their interfaces to stay up to date.
A player company says they won't support some popular platforms because they change interface so often that there is a high chance that no one will buy the player in the end, that's bad!

This creates EME (Encrypted Media Extensions) between the player and CDM . EME provides a set of standardized APIs for players (applications) to communicate with CDM.

Now let's understand how EME and CDM work together:

EME is a JavaScript API.
CDM is software that decrypts video, decodes and displays video (optional).
The video player is a JavaScript program that uses the EME API to transfer information between the CDM and the license server.

The advantage of EME is: Because of the interoperability that EME brings, vendors and player manufacturers can develop streaming services that can watch videos in different browsers. You can develop an app that uses the EME standard to communicate with the license server and CDM, regardless of which DRM platform and browser to use.

Video decoding and display

After the video is decrypted, it needs to be decoded and displayed to the user. This process cannot reveal the decoded, decrypted information or the original frame. CDM is the first point of contact for decrypted data, and it plays an important role in preventing data breaches.

When playing video, CDM can respectively:

Decrypt the movie and stream it to the app (not very secure because someone would hack the app and dump the video).
Decrypt, decode and send the decoded video frames to the platform display engine.
Decrypt, decode and display the video yourself (most secure).

This process also happens in software and device hardware (more secure).

Integrating all the technologies in the player (client side), we get the following diagram.

Our DRM system prototype is in place.

But there are still some important features that could attract content providers.

Step 5: Authentication, Certificate Rotation and Support for Offline Play

At this stage, I would like to differentiate the leading DRM technology vendors (such as Apple, Google, and Microsoft) from the DRM vendors that provide services around these technologies. In this part, let's take a look at some of the business rules proposed by the industry for DRM technology (which may be provided by DRM technology suppliers or DRM manufacturers directly).

User authentication

DRM technology providers such as FairPlay, Widevine and PlayReady do not provide user authentication services. But DRM vendors can! When the user presses the play button, a separate server verifies the user's qualifications (eg user ID). It checks whether the user has permission to play the content based on information such as subscription level, promo code, etc. After the server verifies the user rights, the App can issue a license application to the license server.

Note: The above is just a simplified version of user authentication, professional DRM manufacturers need more complex verification process.

geoblocking

Geo- blocking is used when content providers want to prevent a movie from being played in certain regions . Similar to user authentication, this is an add-on service for most DRM vendors. When the user presses the play button to play a particular movie, the DRM manufacturer's server can check whether the movie is available for viewing in the user's region. Licenses and encryption keys are delivered (or denied delivery) to the client according to the rules set by the content provider.

Perpetual and non-perpetual licenses

As the name implies, after the license server receives a permanent license , it can store it on the client device. It can be used to play movies until the license expires. Before the license expires, the CDM needs to generate a license renewal request.

A non-perpetual license is for immediate movie playback. They are not stored long-term, and are generally discarded after the current playback session expires (or in the middle of a session, when a short-term expiration time is set).

key rotation

Key rotation refers to encrypting different parts (slices) of a video with different keys in order to reduce attacks. If a hacker obtains the key for a movie, in the case of key rotation, he can only watch a small part of the movie, because the other parts use a different key. In addition, by using multiple keys, you can map different licensing rules to different parts of the video content. For example, the "behind-the-scenes exclusive portion" of a movie is only available to Premium members, and other free subscribers can only watch the rest of the movie content.

Play offline

Some services offer to play videos offline when an internet connection is unavailable . When I know I'm going to have a long flight, I download a few movies on Netflix. In this case, the player does not need to communicate with the license server to obtain the DRM key.

At the same time, DRM providers need to provide an option to store keys securely on the device so that content can be unlocked and played without an internet connection. A highly secure CDM implementation is required to prevent key disclosure.

Optimized encryption for video

Encrypting and decrypting movies can be very expensive, especially in UHD and 4K movies, and this is where encryption needs to be optimized. One of these optimizations is to encrypt only the frame content (keyframes or I-frames or IDR-frames) of each video slice. This approach has several advantages:

Encryption is fast because the frame content occupies only a small fraction of the total frames in the movie.
Only after decoding the frame contents, its related frames (both frames that depend on I-frames) can be decoded.

So without decodable frame content, a movie is useless.

An example is SAMPLE-AES in Apple FairPlay, which encrypts only part of each media slice.

Security levels and blocking certain resolution videos

Content decryption can be performed in software or hardware. Generally, hardware decryption is considered more secure because the decryption operation takes place in a Trusted Execution Environment (TEE). Wikipedia defines TEE as: a secure area of the main processor that ensures the privacy and integrity of loaded code and data.

However, some devices (typically low-end devices) cannot perform hardware decryption and decoding.

Content providers need a mechanism to conditionally allow/block video playback on various devices. A straightforward approach is to generate a DRM license specifying which devices are allowed to play certain resolutions in the movie bitrate ladder.

Conclusion

I hope you now understand how AES, EME, CDM, CENC, keys and key servers make up a DRM system.

Thanks for reading, see you in the next article!

Thanks:

This article has been translated and published with permission from the author, Krishna Rao Vijayanagar, thanks.

Original link: https://ottverse.com/eme-cenc-cdm-aes-keys-drm-digital-rights-management/