Tech

Time to talk about DRM again.

Naturally, most people don't care much about this topic, and I'm sorry if another blog post talking about DRM might seem very boring and too technical for you, but I really need to get this off my chest.

With that said, I'll try to keep this as simple and easy to understand for non-technical people as I can.

So, let's get started!

A bit of background on DRM

So, what is DRM anyways? DRM stands for Digital Rights Management and is an umbrella term used to refer to any technological means of enforcing copyright over digital information of any kind. Examples of digital information that are usually DRM protected are music, books, video games and, of course, video files.

Since copy-pasting a file in a computer is as simple as doing a Control + C, Control + V on it and, just like that, you have an exact copy of it without having had to pay any amount of money for a second copy of it, DRM was invented to stop the user from being able to do just that, for the sake of enforcing copyright restrictions.

There are many schemes that have been invented (and reinvented) over the years to do just that, one of the most popular known ones being Apple's FairPlay technology, that is implemented on macOS and iOS. This tech was used historically for protecting music that was distributed over the iTunes store (and still is), but was also extended for protecting ebooks too, as well as video and other media.

Microsoft also tried their hand at this and came up with the PlayReady technology, a similar proprietary tech that is used primarily for encrypting copyrighted video that gets streamed to devices running the Windows family of operating systems (especially on Microsoft's own brand of web browsers, particularly Microsoft Edge).

These pieces of technology are needed in the modern day world simply because, if they did not exist, it would be trivial for anyone to steal digital information passing through their computer. Simple tools like Wireshark (which are free, by the way), would allow anyone with a Netflix subscription to capture the network packets coming from Netflix servers and reconstruct the video file that would represent any TV show or movie that you wanted to get a hold of.

Once this reconstruction process would be complete, you, as a simple Netflix customer, would have in your possession a digital copy of the episode or movie in question and would then be able to share it illegally with anyone of your choice.

It is for this reason that Netflix and other video-on-demand platforms have been employing the aforementioned technologies to protect their digital content and bar computer users from misusing their privileges to enable software piracy.

Why is this a problem?

Now, on paper, DRM sounds quite fine and dandy and, for all intents and purposes, it can be seen even as a necessity in a modern digital age.

After all, how could you, as a movie studio or a musician, ever feel comfortable to distribute your own work digitally to your customers if there was no protection in place to prevent them from illegally copying your work and then distributing it freely to others against your will?

After all, piracy means loss of money to you, doesn't it?

Well, here's where we get into murky territory.

While it's easy to think in black and white terms like that when you're the owner of your own work, it gets complicated when you have to really think about how to prevent people from copying over information when that information has to go through untrusted computers.

Because, at the end of the day, anything that can be shown on a computer, whether it's a book, music or video, has to come down to being a long series of bits. Because, deep down, that's the only thing that computers can work with: digital data.

And, also, that data, in order to be useful to a customer that pays you money, has to go through his own hardware: his CPU, his GPU and, eventually, reach his display or his speakers. A song can only be useful to someone if it plays on his speakers, a video can only be useful if it gets played on his monitor etc.

So, regardless of how you spin it, this protected data, somehow, has to travel through the medium of the internet and eventually reach hardware that is a customer's, a customer that may or may not have malicious intentions of illegally copying it for his own needs.

The inherent problem that I'm trying to highlight here is that, in the end, the data has to reach untrusted territory, and be processed by untrusted hardware.

How can this be resolved when any piece of hardware can be tampered with, physically? How can one guarantee the safety of a piece of data if it has to pass through a CPU that can be made to run an untrustworthy operating system on it?

Well, there is no easy answer to that question. Theoretically, the answer is it's impossible but, then, that would be quite problematic.

That answer would cause a lot of issues, least of which is the fact that video on demand, as a business model, would be effectively impossible to implement if that were the colloquial answer to this dilemma.

Oh, you want to make a business out of streaming copyrighted content to computers all over the world that have an internet connection? Well, TOO BAD. It's technically impossible to protect said data from being illegally copied by malicious technically savvy actors and so, well, you can't make a business out of that. Sorry.

Imagine if that was the case! Netflix, as a business, wouldn't exist. And TV shows and movies would remain only in the world of TV and Blu-ray/DVD releases. That would be a very sad thing indeed.

But wait a second! I just mentioned Blu-ray and DVD, didn't I? Home media, as a concept, has been a very lucrative industry for many years and, even that, in theory, relies on giving customers access to copyrighted digital data and letting them view that at their leisure.

Blu-ray, by definition, allows a customer that had purchased the Blu-ray disc of a particular movie or TV show, to watch said movie or TV show on their own TV, which is technically untrusted (since any piece of hardware can be tampered with).

So, if Blu-ray could do it, why can't video-on-demand platforms?

The breakthrough (sort of)

Multiple things had to happen at the same time to make Blu-ray, as a piece of technology, become possible.

For one, digital transmission of video streams had to be locked down entirely.

Ever used an HDMI cable? Or a DisplayPort? That's digital video transmission and everything going through those cables has to be encrypted.

The exact name for this encryption technique is known as HDCP, which stands for High-bandwidth Digital Content Protection and it was invented back in 2000 by none other than the Intel Corporation (initially for DVI and later expanded to include other kinds of physical links as well).

Nowadays HDCP is used behind the scenes by pretty much every piece of hardware in existence.

Any type of graphics card will, at the very end of the processing pipeline, encrypt the video stream before it sends it out on the physical cable so that, no matter what that cable is connected to, it will only receive encrypted data (and when I say graphics card, I also mean integrated graphics as well).

But how can a TV or computer monitor read a video stream that's encrypted?

Well, before the encryption even begins, there's a special kind of key exchange that happens, and that kind of exchange is only possible if the TV or monitor in question has its own kind of key burned into its own hardware that is, inherently, trusted. The exact type of exchange is complicated and is designed in such a way as to not leak trusted key material to untrusted parties. I won't go into detail of how this is done but, if you're up to the task, you can read up on the details here.

In addition to this, the trusted keys that have to be burned into monitors or TVs had to be buried into microchips that are difficult to extract data from.

Physically this is not impossible but it requires specialized equipment and knowledge to reverse engineer these keys.

This is to say, to circumvent the problem of How can you protect copyrighted information that has to go through untrustworthy hardware, the solution engineers came up with was Simple! Just design all hardware in existence that has to handle such information to be trustworthy.

This is to say, make an authentication scheme that cannot be spoofed very easily to ensure that sensitive information doesn't get sent out to tampered hardware, bury sensitive cryptographic materials that such schemes rely on in microchips that are very difficult to tamper with and, finally, whenever data has to exit such trusted hardware and has to travel through physical links whose integrity cannot be guaranteed, encrypt that information before it has to travel through said links so that only trusted hardware can decrypt it back to a readable form.

So, how did Microsoft and Apple implement a solution for video-on-demand providers? They designed their FairPlay and PlayReady protection schemes to make use of these hardware technologies by enhancing their respective operating systems with the capability of creating secure write-only pipes that have special anti-tamper protections built into the very kernels. Such pipes would have sensitive copyright protected information travel through them, which, in practice, just means that this information gets encrypted as it gets passed around from one memory area to another (much like how a VPN encrypts your network traffic as it travels from one point to the next) and only the hardware parts that need raw access to that information has the means of decrypting it. Everything else would just see encrypted gibberish.

To make this possible, TPMs had to become widespread (as they are designed to be trusted by default and also handle sensitive information), drivers for graphics cards had to be enhanced by video card manufacturers to support these protection schemes, and much more.

Ultimately, the end result of all of this was a very complex system with many many moving parts, where many giant tech companies had to agree to multiple standards and had to come together in their engineering efforts (among of which were Microsoft, Apple, Intel, nVidia, AMD, Google; pretty much all the big names that you can think of) and, in the end, it resulted in a highly advanced protection scheme whose sole purpose was to enforce copyright over digital data.

And, after all these efforts, we had a technological means of guaranteeing to video-on-demand providers that their data could be safely handed over to secure machines running secure operating systems, that would run secure hardware handled by secure signed proprietary drivers.

But wait! What about Linux?

Oh right, of course things couldn't be that easy! Open source just had to make things complicated again!

You see, dear reader, in this world of security through proprietary secret technologies and encryption schemes implemented through locked-down TPMs or proprietary drivers that nobody can inspect the source code for, there exist those people that want to run only free software, open source software; there exist operating systems whose very kernel can be modified by whoever has the technical knowledge to do so and can be changed to do whatever they so desire. And doing that requires no reverse engineering or hardware tampering whatsoever.

In such a world, you may wonder, how can such data be protected, if the operating system can be modified by anyone in any way?

It would be one thing if the web browser ran directly on the video card and web developers could interface against a secret API from Javascript to access the proprietary underlying drivers to encrypt media, but that's not how anything works.

The web browser runs from the context of an operating system. The operating system runs on a CPU. In order for data coming from a Netflix server to be protected against illegal copying, it has to be passed over from the web browser process to the video drivers (since we're talking specifically about video content now) through system calls, and then the video drivers have to take it and encrypt it and then pass it on to the monitor link.

It is at this point where the data has to be passed over from the web browser process to the video card drivers where it is vulnerable to being copied.

If the kernel is truly open source and a hacker can manipulate its source code to make a modified malicious version that can steal any data that gets passed over during this time and extract the unencrypted bits, then it's all over.

What's even worse is the fact that there are versions of graphics drivers that are also open source, made by third parties unrelated to nVidia or AMD or Intel, who cannot be controlled by them and who publish the source code for their work as well. These drivers can very well be rewritten by anyone skilled enough to copy the data when it is still unencrypted and dump it into a file.

These issues are very pressing and, honestly, this is where we get into the grey area that nobody likes to talk about.

In a world where nobody cares, the solution that most engineering companies would come up with would be “just ignore Linux users” and that would be it. “Since we cannot ensure a secure pipeline for copyrighted data from the web browser to the physical wire that goes to the monitor, we cannot trust the operating system at all. As such, let's not support it” and that would be the end of the discussion.

What this would mean would be that Linux users would be left in the dust, and Netflix, Amazon Prime Video, HBO max and all these other platforms would simply refuse to service them, as none of them would be willing to hand over their copyrighted video data to such untrustworthy platforms.

Thankfully, this is not the case.

Widevine to the rescue

And here we come to the end of our story. The hero that saved Linux and made video-on-demand streaming possible to it was none other than a company that wanted to provide a means of securing data from the context of a web browser.

Widevine Technologies have been making a name for themselves in the area of protecting digital content from 1999 onwards, being among the most famous companies that enforce content protection on various platforms.

In 2010, the company was acquired by Google, who was very well aware of the necessity of acquiring their tech.

The problem with the aforementioned PlayReady and FairPlay technologies is that they were proprietary and relied on special support from the underlying operating system to work.

PlayReady would only work on Windows and FairPlay would only be accessible from the context of Apple's own ecosystem of operating systems.

This posed a problem to Google, since they wanted to make a cross-platform web browser that would the same across all operating systems (namely Google Chrome).

To make Chrome work correctly, it would, in theory, be possible to maintain different code bases for each separate operating system, but that would be an unnecessary amount of extra effort to invest into a means of protecting digital data.

Instead, Google sought to obtain a universal solution, a one-size-that-fits-all glove that would be agnostic to the operating system that it ran on and, would additionally work well on Google's own operating systems, namely the Linux-based Android and ChromeOS environments which lacked the aforementioned protection schemes.

As such, Google realized that it only made sense to acquire Widevine Technologies as a response to this necessity, and integrate their solutions into Google Chrome and Android ecosystems, which lacked them.

“But how can an open source web browser like Chromium ever be able to encrypt data in such a way that's impossible to be bypassed by hackers who can just change the source code? And how can they protect such data from a potentially hostile tampered operating system?” you may ask.

Well, the answer is a fair bit complicated, but, to put it simply, Google had to do a lot of patchwork to get there. But, it's Google. At the end of the day, they had more than enough money and engineers to throw at the problem.

The way they did it for the Chromium project was to simply not make their solution available there, at all.

If you use a pure version of the Chromium web browser to watch Netflix, you'll quickly find out that it simply doesn't work. That's because Google could not reliably implement such a solution into an open source project, lest it invite the open source dilemma that we already talked about.

Instead, they implemented it only for Google Chrome as a proprietary plugin-in dynamic library who does all the heavy work duty of both encrypting and decrypting the media streams in a closed proprietary environment that's very difficult to reverse engineer.

This is known as the Widevine CDM, and is only a small part of the whole Widevine infrastructure that's behind the content protection that's needed.

As this CDM is just a dynamic library file on the local file system, in theory, it is possible for a malicious party to simply disassemble it and extract its inner functioning, analyze it, and figure out how it does things (and this has happened before; I've even read up on a now archived Github page how one user attempted to do just that).

At one point in the past, the way this CDM did things was by using RSA encryption to decrypt video content that was being sent over the wire to it.

Basically, the CDM had its own public-private RSA keypair burned into the library, with the private key very cleverly hidden in some .data section in the library file. Whenever a protected content stream was to be initiated, the Chrome browser would load the proprietary plug-in, the plug-in would send an exact copy of its public key in clear text to the Widevine server that was on the other end of the internet connection, the server would check against its database of trusted RSA keys to see if it was trusted and, if it still was trusted at that point in time, would start encrypting the protected data stream using that public key and send the encrypted data to the browser over the internet. The CDM would then use its associated private key to decrypt the stream back to its original form and then display everything from the context of the web browser as a video feed.

Simple, easy and very elegant.

That was how it was done at one point. Since then, especially after this information got released from the guy that reverse engineered it, I imagine Google engineers updated the method to something else now.

The point is, there exist many different ways to do it, and, as hackers reverse engineer the Widevine library to keep finding out how it works, Google has the resources to find new ways of protecting the content, in a constant cat-and-mouse game of trying to evolve a solution to protect digital video feeds.

“But wouldn't a tampered host operating system defeat this? One could just inspect the RAM memory of the Widevine CDM and access the raw decrypted data directly, if they were skilled enough”.

Yes, yes they could. For this reason Widevine has such a thing as protection levels. Because, unlike Windows or macOS, the Linux operating system that runs in the background cannot have its integrity guaranteed in any way, if Google Chrome detects that it's running on such an environment, it considers this to be in an L3 (i.e. protection level 3) context. This is the least secure context and it is, for this reason, considered the highest risk one.

Within an L3 context, all operations are done in an unprotected memory area by the Widevine CDM, and this is considered low security. For this reason, most video-on-demand platforms only hand over low quality streams to such an environment, content that, even if it were illegally copied and then distributed via piracy, would only lead to marginal financial damages. I forgot exactly what type of restrictions this has, but for Netflix, if I recall correctly, I think they send out only a maximum of 540p quality streams to such environments (either that or 480p or 720p, I can't remember which). Such low quality streams are considered low-risk enough that even if they were sent over to insecure channels, the amount of damage they would do would be limited.

The next level up would be L2 protection, in which video decoding and encoding is done in an unprotected environment but cryptographic operations are done securely. This is where Google Chrome running from the context of ChromeOS would be (sometimes, ChromeOS might even support L1 protection even). Technically ChromeOS is also Linux, but it's treated in a special way, because the operating system is heavily modified by Google to be locked down intensely against tampering, and its own source code is not published online (there is the open source ChromiumOS project that ChromeOS is based off of, but it's only an approximation of the real thing, as ChromeOS modifies it using proprietary means very heavily, much in the same way that the Chromium project is only an open source approximation of Google Chrome).

Inside the L2 context, most video-on-demand platforms would allow for content streaming up to 1080p, as it's very unlikely for memory inspection tools to be available in such environments for hackers to tamper around with.

Finally, there is the L1 context, that's only available on modern hardware that use TPMs and hardware-protected video decoding to ensure the availability of a secure pipeline to send copyright protected information through. This is a 1:1 equivalent to the aforementioned PlayReady and FairPlay solutions, where data protection is guaranteed on every step of the way through the pipeline, from the browser until the data gets displayed on the monitor/TV.

This level of protection can only be guaranteed only on the latest versions of Intel and AMD CPUs (that have TPMs incorporated in them), you have up to date device drivers that ensure that the hardware can handle protected data and the host operating system is guaranteed to not have been tampered with in any way (usually by integrity checks and ensuring that the boot loader of the device is locked, if possible).

From the context of Widevine, this is usually only possible on the latest Chromebooks and on Android devices (smartphones, tablets or smart TVs) that have never had their bootloaders unlocked (and always on iOS and iPadOS devices as well).

In such environments, the security guaranteed is so high that there are no more limits with regards to the quality of the content being shown. This is considered the maximum level of security that Widevine can afford, equivalent to the PlayReady and FairPlay schemes.

And so, thanks to Widevine, Linux as a whole now supports protected video playback (albeit L3 level but still).

Blog post by Alexandru Pentilescu.

You may contact me at alexandru.pentilescu@disroot.org

Optionally, you may also encrypt your emails to me using the following PGP key: 0xFF49E5748BD42A6A6A7DECFDD38B28DF9F7497A2

Download that key from any keyserver you wish