Trusted Computing - How does a streaming site protect its contents?

Cover Image for Trusted Computing - How does a streaming site protect its contents?

You’re launching a brand new streaming site, like Netflix.

Your users pay good money to access your exclusive content. The last thing you want is for illegal copies to end up on shady streaming sites across the internet.

How well can you protect against piracy in 2023? Quite well, thanks to the advancements in Trusted Computing.

Trusted Computing allows your server to respond only to official clients. Official clients can restrict the copying and sharing of data you send to users.

Imagine this:

You have a server that sends video files only to active subscribers who use your Viewer App. Your Viewer App lets users stream, but will not allow making any copies of the video files.

A paying user is using the viewer app. The viewer app lets you view but not copy video.mp4. The server sends video.mp4 to the viewer app.

Now, here comes Pirate, who wants to share your video.mp4 far and wide. They ask their friend, Hacker, who is a paying user of your service, for a copy.

Pirate: "Hey bro, can you give me a copy of video.mp4?" Hacker (Paying User): "Sure bro. Let me try..."

Let’s put ourselves in the shoes of Hacker and see what they could try…

Attempt 1: Modifying The Viewer App

Hacker modifies your Viewer App to save videos to disk:

def playMedia():
  video = downloadMedia()

  # malicious change:
  save_to_disk("./video.mp4", video)


As a result, there's now a Modified Viewer App. Unlike the genuine app, this one is tweaked to save the video directly to the disk.

Viewer App: "I let you view, but not copy video.mp4" Modified Viewer App: "I let you view and copy video.mp4"

Unfortunately, it doesn’t go as planned:

Modified Viewer App tries to get video from your server. Your server: "Attestation failed!" Pirate: "What is attestation?!"

How does your server detect that the Viewer App has been modified?

And what is attestation?

Let’s see how you protected against this attack with the help of Trusted Computing.

Trusted Computing

We want the server to only answer to official Viewer Apps. With the help of Trusted Computing, your app can prove its identity to the server over a network connection.

How is this possible?

Your app itself could always lie about its own identity. An external auditing mechanism is required. This is where Trusted Platform Modules come into play.

Trusted Platform Modules

Every laptop, phone, and tablet you can buy today comes with a little hardware component called a Trusted Platform Module, or TPM for short.

Trusted Platform Module is a small non-reprogrammable computer. Think of it as an external auditor inside every user's machine. It follows your agenda of securing your DRM, not the device owner's instructions.

The TPM comes with a digital code pair called an Endorsement Key. This consists of a public endorsement key and a private endorsement key, which are mathematically linked. The Endorsement Key gets permanently programmed into the TPM during manufacturing.

The manufacturer digitally signs the public endorsement key.

The only copy of the private endorsement key is inside the TPM. The private key is designed to be impossible to extract (e. g. TPM memory shall self-destruct if physically tampered with).

There are many manufacturers out there, so attestation services take on the role of vetting manufacturers.

The trust hierarchy works as follows: You place your trust in the attestation service. In turn, this service trusts the hardware manufacturer, who then places their trust in the TPM they've produced.

Visualization of the chain of trust

You now have a chain of trust into hundreds of millions of devices worldwide. The TPM is also referred to as the “hardware root of trust”.

On computer startup:

  • The TPM verifies that the firmware is signed by the manufacturer.

  • The firmware verifies that the operating system is signed by a trusted party.

  • The OS verifies that the Viewer App is signed by its developer (you).

Visualization of the chain of trust

The robust chain of trust is the underlying principle with which Trusted Computing can ensure that only genuine Viewer Apps can access and stream content. As you can see, Trusted Computing requires a broad effort by hardware manufacturers, operating systems and app stores to work.

Next, let’s see how this trust can be conveyed to remote computers with the help of Remote Attestation.

Remote Attestation

For the Viewer App to access content, it must first demonstrate its trustworthiness to the server. This is where the chain of trust comes into play.

Each device has a unique Endorsement Key. To ensure user privacy, the OS exchanges this key for an app-specific Attestation Token via the attestation service.

Once the Attestation Token is successfully validated, the server grants access to the video file.

Visualization of the process for obtaining an Attestation Token.

Let's see what happens at each step if one of the components has been tampered with:

  • If the Viewer App is modified, the Operating System will refuse to issue Attestation Tokens.

  • If the OS is also modified, the Firmware will refuse to boot.

  • If the Firmware is also modified to allow insecure boot, the TPM will refuse to sign requests with the endorsement key.

  • If the TPM is emulated with a fake TPM, the attestation service will not recognize its endorsement public key.

  • If the attestation service is emulated with a fake one, your server will not recognize its attestation tokens.

In any of these cases, the Viewer App will not pass the attestation process – a sign of possible tampering or unauthorized changes. The server subsequently blocks access. This mechanism ensures content is only streamed to authentic, secure apps.


Using this remote attestation process, Trusted Computing provides a way to theoretically eliminate any tampering with your app (except for human error in its implementation). We will touch upon these attack vectors in a later chapter.

Past copy protection attempts often relied on the flawed principle of security through obscurity. (Some even went to the extent of installing malware on consumer devices!) Trusted Computing is a more secure advancement.
Trusted Computing has use cases beyond remote attestation or DRM protection, a follow up article will discuss the other use cases.

Enjoying it so far?

Subscribe to get more posts like this one delivered in your inbox.

From our discussion, it's clear that Hacker cannot directly modify our app to access the video files. Let’s look at other approaches they could take.

Attempt 2: Memory Access

The next convenient place to steal the video is in the device's memory (RAM).

Modern processors have a feature known as memory curtaining. While different manufacturers name it differently — Apple calls it the "Secure Enclave", Intel terms it "SGX (Security Guard Extensions)", and AMD labels it "TrustZone" — the primary goal is similar: to protect sensitive data in memory.

Memory curtaining aids in creating Trusted Execution Environments (TEE). Within a TEE, sensitive files, such as your mp4 files, are insulated and cannot be accessed or stolen by other applications on the same system.

Speculative Execution Attacks

It's worth noting that in recent years, vulnerabilities have been discovered in modern processors. These vulnerabilities allowed rogue applications to pilfer data from the memory of other apps by leveraging a technique known as speculative execution.

Examples of such vulnerabilities include Spectre and Meltdown. The most recent one, named Downfall, was disclosed just last week.

These bugs are quickly fixed, usually before being made public. Your app could incorporate a feature that checks for the latest security patches on the device's operating system. If the app detects an out-of-date or unpatched system, it could halt its operation, ensuring that it operates only in a secure environment

Attempt 3: Eavesdropping

Hacker might try to obtain the video while it is in transit over the internet.

Traffic Inspection

Tools like Wireshark let users view packets that enter and leave their computers.

Fortunately, your Viewer App encrypts your traffic with HTTPS, so packet inspectors cannot interpret the traffic between your app and server.

Your Server sends video.mp4 to your Viewer App. A Packet Inspector like Wireshark is inspecting the traffic. However, it is TLS traffic. It cannot decode.

The above scenario is a passive Man-in-the-Middle attack.

Impersonating Your Server

If Hacker can obtain the Attestation Token from your Viewer App, they can exchange it for video.mp4 from your server.

The goal is to trick the Viewer App into sending the Attestation Token to an impersonating server, which steals the Attestation Token.

Your Viewer App insists on establishing an HTTPS connection. As part of this process, the identity of your server is verified with the help of public key certificates.

Hacker cannot generate a valid certificate for your website, but they can generate a fake certificate and add it to the certificate store on their operating system. Almost every operating system allows the end user to install a custom certificate.

HTTP Public Key Pinning (HPKP) protects against this attack vector. You provide your allowlist of trusted Certificate Authorities inside your app. The end user cannot modify this list without breaking attestation.

Impersonating Server: "I steal Attestation Tokens" Viewer App: "Can't establish connection!"

The above scenario is an active Man-in-the-Middle attack.

Eavesdropping On Hardware

TPMs are usually a microchip on the motherboard, separate from the CPU. One could eavesdrop on the communication between the two components.

Historically, the communication between the TPM and the OS was not encrypted by default. This allowed for attacks such as TPM Genie, where the device owner with physical device access could launch a Man in the Middle attack to sniff endorsement signatures.

Newer versions of TPM standard support transport security which prevents such attacks. The OS first verifies the public key of the TPM and then establishes an encrypted communication channel.

Attempt 4: Screen Recording

Another potential vulnerability is simply recording the screen and audio

OS-based screen recording

Modern operating systems offer APIs to prevent screen recording. For instance, Android provides the FLAG_SECURE API which your viewer app can leverage.

HDMI Output

Your users could connect their computers to an HDMI recorder device.

To counter this, HDCP (High-bandwidth Digital Content Protection) can be used. It allows you to authenticate the monitor, similar to remote attestation, and disable recording features.

HDCP leverages a Sink Key, analogous to the Endorsement Key used in Trusted Computing. Video is only transferred after successful authentication of the monitor. The video stream is encrypted to prevent eavesdropping.

Display Manufacturer embeds a sink key inside Monitor. Monitor lets you view but not record video.mp4. Viewer App authenticates Monitor via sink key, then sends it an encrypted video steam.

Operating Systems have native support for HDCP. For example, Android’s FLAG_SECURE feature mentioned above takes care of this for you.

Analog Hole

Your users can put a video recorder in front of their screen. This is the so-called analog (loop)hole, a reminder that no system is entirely foolproof."1

While the analog hole is a fundamental challenge, its implications are limited in scope. Recording content through this method results in a significant loss of quality, making it less appealing.

Attempt 6: Attacking the Chain Of Trust

The strength of Trusted Computing is dependent on flawless execution and implementation, leaving room for human error.

There are several supply chain vulnerabilities in the chain of trust: Malicious manufacturers could sign private keys outside TPMs; TPMs can be tampered with; firmware or OS software can be hacked; attestation services can provide attestations to security researchers, and so on…

For example, AMD's TPM was recently compromised.

A sophisticated hacker with enough resources will find a crack in the system. As Trusted Computing matures, you can expect the difficulty to increase.

However, not all adversaries will have the resources or expertise to exploit these vulnerabilities. Fortunately for you, Hacker is not very resourceful.

Hacker: Ugh. I give up!

Hacker has run out of ideas.

It’s not perfect yet

Trusted Computing for DRM relies on perfection. One loophole and your entire media library can be extracted and shared online. You won't be surprised to find many recently released TV shows and movies freely available on pirating sites. This is because the system is not perfect yet.

The payoff for making the system perfect is large. Apple, Google and Microsoft are all in the business of selling you hardware, operating systems, as well as movies, music, games and other DRM content. They have the means and incentives to invest in perfecting Trusted Computing.

Platform Support

All major desktop and mobile operating systems support Trusted Computing. The APIs to do so are platform specific.

All APIs are currently offered for free. Consult the table below:

iOSDeviceCheck or AppAttest
AndroidPlay Integrity
WindowsBring your own (e.g. Azure Attestation)
LinuxBring your own (e.g. Azure Attestation)
WebEncrypted Media Extensions (DRM streaming only)
Web - Safari (macOS & iOS)Privacy Access Tokens
Web - Chrome for AndroidWeb Environment Integrity

It’s incredibly easy to integrate these APIs. I was able to add attestation to my test Android app and backend in under 10 minutes with a few lines of code.

You can check out Firebase App Check's tutorial for Play Integrity to get a feel for the necessary steps.

As discussed, you will also need to protect against other attack vectors. This is a non-exhaustive list:

  • memory access via memory curtaining

  • eavesdropping via HPKP

  • screen recording via secure buffers and HDCP enforcement

  • modification through DevTools or browser extensions

Consult the documentation of your platform of choice on how to do each of these.

Before you jump ahead and implement Trusted Computing, I should let you know that Trusted Computing is pretty controversial. We'll dive into the reasons why in the third post of these series.


Not every user has a device with a TPM, a monitor which supports HDCP, an up-to-date operating system, etc. You will probably want to accommodate these users.

Streaming apps like Netflix allow users without valid attestation to view content only in lower resolutions (SD). This is one way to protect IP without causing complete disruption to consumers.

Every new laptop, PC and phone comes with a TPM. Installing Windows 11 requires having a TPM. As the support situation improves, you can increase the device requirements.


Thanks for reading this far! By now, you hopefully have a basic understanding of Trusted Computing, what role Trusted Platform Modules play in it and how steaming apps like Netflix or Amazon Prime use Trusted Computing to protect their intellectual property.

Trusted Computing is not only useful for DRM protection. The next chapter will explore other use cases.

Part 2 is not released yet. Subscribe and be among the first to read it.

1: Of course, solving the analog hole is not an impossible challenge. Here’s an idea: In the future, recording devices could emit a machine-readable signal while they are recording. Displays and audio playback devices would detect this and pause playback. Media companies can lobby for regulation to ban the sale of non-compliant recording devices

Subscribe to my newsletter