A Primer on Widevine and How It Can Be Abused to Download Encrypted Movies/Shows
First things first, what is Widevine?
Widevine is an encryption framework that is used for digital rights management (DRM). It’s owned by Google, but used by a huge array of content creators and streaming services, on account of it being royalty free to use and implement. With 5 billion devices shipped that support it and 82 billion content licenses issued quarterly, it forms one of the “big three” DRM providers alongside Apple’s FairPlay and Microsoft’s PlayReady.
What does it do?
Put simply, it makes sure consumers can’t make unauthorised copies of the media they have bought or licensed – either through streaming platforms like Netflix or from marketplaces like Google Play Movies.
Through a combination of hardware security and an isolated secure operating system (OS) to handle some security functions, Widevine ensures content is delivered securely.
Security Comes in Levels
Just like everything in IKEA, Widevine comes as a modular system that you can customise. There are three levels to the content protection: 1, 2 and 3, with level 1 being the most secure and 3 being the least. The Chrome browser supports level 3 in all of its implementations while most flagship Android smartphones from the past few years support level 1. A summary of the main differences in the levels can be found in the table below:
| Level of Widevine | How are keys provisioned? | How are keys used? | Secure hardware required? | Where does the stream go? |
| 1 – Most secure | From the factory, baked into the device | Used within the secure processing area to decrypt | Yes, with secure bootloader | The decrypted stream is sent to the display via a secured path like HDCP |
| 2 | From the factory, baked into the device | Used within the secure processing area to decrypt | Yes, with secure bootloader | The decrypted stream gets sent to the display unprotected |
| 3 – Least secure | From the factory, baked into the device | Used to decrypt using the device’s CPU | No, with secure bootloader* | The decrypted stream gets sent to the display unprotected |
* The bootloader may be authenticated by the device manufacturer in the case of devices like phones, to ensure integrity of the platform as a whole, but a secure bootloader isn’t technically required – for example Windows computers can support L3 without UEFI secure boot etc.
Key Exchange
Through the design of the Widevine framework, the keys that have been used to encrypt the content are never actually exposed directly to the user. Instead, the header file that gets sent to the client when a stream is started contains the bare minimum information needed, containing just some metadata about the encryption scheme used. This metadata then gets passed to the content decryption module (CDM), which is in the client or browser the user has installed.
The CDM
A CDM is used to decrypt the video streams – it’s a file containing proprietary code which is used to request the licenses from the Widevine license server, before the content is decrypted and displayed. Earlier versions of the CDM did not contain any obfuscation techniques, although now they use Arxan. This adds to the security of the framework.
When the user requests a stream, the CDM receives the header files to start the stream from the content provider. In there, information about the encryption methods used, along with some other information is utilised by the CDM to create a license request, which is sent to the license server for Widevine. The license server sends back a license to the client, which contains the content keys. These content keys are then used by the CDM to decrypt the content, which the user can then view.
The License Server
Google hosts the license server(s) for Widevine in house, using their cloud platform. This makes it super easy for content providers to implement, and also means that Google can take the necessary precautions to ensure the infrastructure and encryption keys are kept secure.
When encrypted media is first put onto a CDN by the provider, information about the media is collected and sent to the license server for later use – to issue the licenses to decrypt the video later. Then when it comes to a user viewing the video, the server is queried and license information is sent back to the client. The server uses standard HTTPS to send information over, but uses Google’s own protocol buffers.
Starting a Stream
So say you want to start a stream. What now? How does the key exchange actually go down?
A quick side-note – the player that’ll be mentioned acts as a middleman for this – it can’t read the encrypted license information; just relay it on. This maintains the integrity and security of the Widevine framework as the player is open source, but the license server and CDMs are closed source. This makes it really easy to create applications that are encrypted and secure, but still customisable.
So we have a stream from a user. First things first is to receive the raw, encrypted media. These would be the streams from a provider like Netflix, or a download from the Google Play store. Once the data has begun to be downloaded, the client will try to play it back. It’ll fail as the data it’s been sent is encrypted, so is basically gobbledygook but that’s intentional. Once it fails, the client will know for a fact that the source is encrypted and will know to perform the routine to decrypt.
To start the decryption process, the client will look for some initialisation data (initData) at the beginning of the file stream. Once it finds that, it’ll be raised in the player as an event that the CDM will need to step in to deal with. Since the player can’t decrypt anything, it needs to pass it to the CDM for this.
Once the CDM has the initData, it will create a request for a license to decrypt the data, which is where the license server comes in. Since the CDM and license server don’t interact directly, the player has to act as the middleman, so the encrypted license request gets passed to the player to forward on to the license server. The player forwards on this request and receives a response.
With that response, the player now can give the CDM all the information it needs to decrypt the data. The CDM doesn’t always decrypt the data itself though – most of the time it offloads it to a secondary system, using the OEMCrypto module. This is because the CDM isn’t in the trusted layer of the device – it shouldn’t perform the decryption itself because information around that can be intercepted or tampered with. In some implementations, decryption may take place within the CDM but this would utilise more safeguards to make it more difficult to intercept the decryption keys.
Once the content has been decrypted and decoded, it can be sent to the player in small chunks. The content is decrypted in small chunks, and isn’t stored anywhere on the device, to make it more difficult for people to save the decrypted content or make copies.
Breaking Widevine to Decrypt Netflix Movies/Shows
While the pipeline for secure content distribution as described in this blog post seems relatively secure, there are side channel attacks and other methods to decrypt the information. Our consultants were able to successfully decrypt and save content protected with Widevine Level 3, using a variant of the method mentioned by researcher David Buchanan.
In the example below, it was possible to download a raw file of ‘Stranger Things’ from Netflix and fully remove the content protection enabled; allowing for illegal distribution of the material. It should be noted that Netflix are not the only content provider vulnerable to this attack, as it’s to do with the DRM framework used, as opposed to the Netflix platform itself
Spoiler: We obviously have not, and will not distribute the file below, and will not be publishing Proof-of-Concept code due to the difficulty in fixing the vulnerability in the cryptography of the system.
With level 3 down, there’s 2 to go.