Up to this point in my career, I had no major failures – every major project eventually worked as expected. Hardware based content protection broke my winning streak. The only good thing I can say about this experience was that I was able to work with some great engineers, such as Lucia Darsa and Hany Farag.

DRM and content protection is almost a religious battle, with people aligning on both sides. But by 2014, the movie studios tended to look at PCs less as a legitimate video playback device and more as a hacker device used to rip their content (usually with the intent to share on the web). They assumed that most legitimate video consumers used more dedicated devices (like the XBOX One) to watch video. Hence, in some cases they limited the value of the content that could be streamed to a PC (e.g. Netflix might not stream 4K, 1080p, or HDR content to a PC, but they would to an XBOX One). For some reason this did not apply to Apple (probably because of Steve Jobs and Pixar). Some will correctly point out that HDCP is probably the weakest link in content protection and that you can buy devices that will remove it, but my job was not to reason why – just to make sure that Hollywood had no good reason to prevent high-value content from playing on a Windows device. If you hate me for this, know that I don’t blame you and that I suffered much in the process.

First, I need to clarify my terminology:

• Security – Ensures that only the owner of the computer maintains control of the computer. Hacking into a computer means that a bad actor takes that control away from the rightful owner. The owner, however, is trusted to do whatever they want to.
• DRM – A technology used to ensure that a device/user is authorized to access content according to a content license. The video stream is only decrypted when authorization is granted. This does not necessarily imply that the device is entirely secure, however. Hardware DRM typically means that the mechanism to authorize the device/user and to decrypt the data is very secure – not that the device itself is secure.
• HDCP/Output protection – Technologies used to protect the connection from the device that consumes the video (e.g. computer) to the device displaying the data (e.g. TV or monitor).
• Content protection – Assurance that the decrypted data (either in compressed or uncompressed form) cannot be stolen from the device and that the proper output protection is applied.

In DRM/content protection scenarios, the user is not trusted – everybody assumes that they are a hacker wanting to steal your content. Hence, normal security measures do not apply. Moving secrets to kernel mode is insufficient because it is assumed that the user will gladly install a kernel mode component that would help them steal content.

Here’s how DRM works in the windows pipeline:

There were three components to this project.

Implementing PlayReady in a secure processor

While non-trivial, this was the most straightforward part (as long as the hardware had a secure processor that could be used for this). The PlayReady team had a porting kit and they provided support to the IHVs (sometimes I’d provide additional support). We travelled to California a few times to help support our partners.

Ensuring that HDCP was enabled when necessary

This sounds trivial and straightforward, but there are two issues.

First, are we allowed to enable HDCP on a monitor that does not contain protected content? This was not an issue if the computer only had one monitor connected, but if multiple monitors were attached:

• How could we know which monitor contained the protected content? There was not a guaranteed way to know this unless hardware overlays were used to display the content.
• How do we keep content from bleeding over to the other monitor? For example, a live thumbnail of the video could be displayed on the other monitor.
• Did it even matter?
  • It certainly did when Macrovision was involved, but they were largely irrelevant by this point.
  • People claimed that some countries had laws against enabling output protection unless it was needed, but this was never 100% clarified.

Second, what if a content license did not require HDCP to be enabled? Theoretically, some licensees allowed content to be displayed on a non-HDCP capable monitor if it was constricted (e.g. resized from HD to SD).

• If an IHV simplified the problem by failing to playback if HDCP was not enabled, how would they account for this?
• Since the video decoding was done by the GPU rather than the secure processor (which was largely just a low-bandwidth crypto engine), how could we force that the constriction occurs correctly?

In the end, everybody just gave up and always required the HDCP be enabled on every monitor.

Ensuring that the uncompressed content could not be stolen from memory

Making it difficult to steal content this way is easy, but how do you make it impossible?

There are two basic approaches:

The first approach is to create a memory carveout that cannot write to memory that is accessible to the CPU.

• This is the easy and obvious approach, but how big does the carveout need to be? This is memory that is entirely wasted when the user isn’t playing protected content.
  • There are ways to make a dynamic carveout size, but it requires that the hardware can automatically zero pages when the size shrinks).
  • If the video were always displayed using a hardware overlay, determining the size is straightforward and the size can be relatively small (but we cannot).
• Since we can never guarantee that a hardware overlay is used, however, choosing a fixed size limits the number of monitors that can be attached and the resolutions that they can display.

The second approach is to internally encrypt the protected content using a global session key. The GPU behavior is:

• In hardware DRM scenarios, automatically encrypt the output of the decode operation.
• When reading from a decrypted page, always decrypt on read and then re-encrypt on write.
• The display hardware is also capable of decrypting on read.

The second approach is an elegant solution that scales well, and it so happens that the IHV that we partnered with supported this type of hardware. We had to add a bunch of new infrastructure to DXGI and to the DWM to properly support it, but we got it working.

If it worked, why did I say it failed?

The GPU hardware that we initially partnered with had an extra feature that they called “teardown”. Just as a SawStop table saw immediately stops spinning when the blade detects flesh, their hardware would scramble the internal session key when they detected an unexpected state change. For example, if I used a hardware debugger to disable HDCP, their crypto would stop working such that the entire screen displays garbage.

This was a very jarring effect, so:

• We thought that we understood every scenario where this could occur, so I added hooks to the operating system to preemptively account for this (including blanking the screen momentarily when mode changes occurred, etc.)
• We added code to detect when this unexpectedly occurred after the fact and had a strategy to minimize the duration for which the artifacts remained visible (but it was still very noticeable).

Removing these artifacts, however, had a never-ending tail and it became an extremely frustrating project because:

• We partnered with an IHV that made us work with their “top” engineer (who was anything but). I won’t give examples (you wouldn’t believe them anyway), but everyday this engineer sucked the life out of us.
• Everything was extremely non-deterministic. We had dozens of Netflix test accounts (we were partnering with them to make this work), and we eventually learned that each account behaved slightly differently. Even the office we were in seemed to make a difference.

Eventually our IHV partner realized that their teardown feature was overactive and that it could trigger for several unexpected reasons, including internal power state changes that could never be predicted. At that point, everybody gave up and the project was cancelled. Today, Google says that Windows hardware DRM is working, so I’m not sure if they used our infrastructure with new hardware, or whether they started from scratch.