How does Digital Rights Management (DRM) in video work?

How does a client device playback a DRM protected video?

Digital Rights Management or DRM in video impacts whether the video can be played back from mobile device or desktop or smart TV. DRM adds a layer of security to the video streaming workflow by encrypting either the adaptive bitrate segments that make up the video and/or the metadata of the stream. There are steps and technologies behind that allow for premium content to be played back safely and decrypted successfully on a client device, for example Widevine mainly for Android devices, Fairplay for Apple and Playready mainly for Windows. Video is actually encrypted and there is a whole process behind to make sure that the person that is consuming and plays back the video is authorised to do so.

So I’ve created a graph here of the different steps in a DRM system and the first one is actually the users so the users log in via authentication to get access to a catalog.

DRM in video architecture
DRM in video architecture

It’s the first step once they’ve logged in and they browse the catalog. They can make a video selection, so they choose a video which means that a request is created for a content type to be played back. Then, that video selection request has an associated Content ID, in conjunction with the requesting device ID which, basically both create a sort of a signature. So, more than a string, it’s a long. Don’t think of it as a string, think of it is as a sequence of bytes that are unique to the requesting device. So we have two pieces for now, the content ID that the user has chosen plus the signature of the requesting client device, then the next step, if the content was in clear and so not DRM encrypted, is that  the video is fetched from the Content Provider storage, so like a CDN and the video is divided up into segments that represent the different quality levels that the video can play back at depending on the user connection and the requesting device. So for example, if it’s a mobile device it will have a lower quality because you don’t need 4k on a small screen. Whereas, for example, was a tablet, you’re gonna have a bigger kind of screen size so your quality will increase also in function of your internet speed.

So on the other hand, if the video is DRM protected, one way to enforce a conditional access is that once the video is fetched from the storage,  the license of it is checked by the browser component (in the EME module) using the type of supported DRM system. There are multiple types used to encrypt the video and you can encrypt either the segments and/or the metadata. So once the “DRM” component in the browser receives the request for the license, it tries inside the realm of the player to decrypt the stream to play back the specific video. Under the hood the player through its and the browser DRM components contacts the DRM license server and it says, okay, is this user that has selected a specific video on that device allowed to actually play back that video? 

So this information gets aggregated together and sent to the DRM license proxy server which checks the user credentials. The DRM workflow for premium Hollywood type content also has a License database, which includes information, like the content ID. So, the video selection  from the user we can associate to the requesting device so that we can generate a client signature. The signature has also a key which was brought out from the Manifest of the video and that is necessary to decrypt all the video segments. Policies and permissions are embedded with the retrieved license, for example the impossibility to cast the video, or a lower quality. So, all this information is stored in a license DB, which then the proxy server contacts to actually get that information for the license.  We then check if the users on that device can view the video and this is the job of the proxy server and the license database usually set up by the service provider, which is different from the content provider. Once the DRM license proxy server has made  a decision, whether the user is allowed to watch on the device that is requesting it. The license proxy then serves back the license to the DRM browser component, which then uses the key from that license to decrypt part of the video and actually play.

To get playback with a DRM protected video  there are a couple of steps, this is a generalization and DRM is a complex ecosystem where multiple setups are possible. Let’s go through them again for a general case: the first step is that the user logs in the video platform. They select a video on a specific device, then if the user is authenticated the video manifest is fetched from Storage. So from the CDN, which is a server close to the users where the video is saved, the video segments and manifest are then sent to the browser. The browsers DRM component in conjunction with the player  then asks for a license, checks with the DRM license proxy server to verify that the user is authorized to decrypt the video content. It also checks with a license DB, which contains different information, like the key idea in the content ID and all of these together, tell whether the user is allowed to watch a specific piece of content on a device. If the user has that permission, then the license server sends back to the DRM browser component. The key to decrypt, the content and playback the video!

To know more on how to implement Digital Rights Management in video for mobile Android devices check this post!