March 4, 2021

Why Unbreakable Codes Don't Make Unbreakable DRM

It’s commonly understood among independent security experts that DRM (i.e., copy prevention) technology is fundamentally insecure, at least based on today’s state of the art. Non-experts often misunderstand why this is true. They often ask, “When you say DRM is insecure, isn’t that just another way of saying that any code can be broken?” Actually, it’s not. Let me explain why.

First of all, unbreakable codes do exist. Claude Shannon proved (in the strict, mathematical sense of “proof”) in 1949 that a code called the “one time pad” cannot be broken by any method. One time pads reportedly are used on the Washington-Moscow “hot line”.

One time pads are rarely used in practice, because there are certain other codes that present other advantages and are nearly unbreakable. (By “nearly unbreakable” I mean that the odds of their being broken are so low that it is pointless to worry about that possibility.) These are the codes used in “secure” web transactions.

Yet unbreakable codes, whether theoretically impregnable or practically untouchable, do not imply that DRM is possible.

To understand why, imagine that you can build an impregnable armored truck. This truck can carry bags of money anywhere; and as long as you keep the doors closed nobody can rob the truck. The problem is that the truck is useless unless you open its doors. Suppose you want to carry the day’s sales from a WalMart store to the Bank. You have to open the doors at WalMart to put money in, and you have to open them again at the Bank to get the money out. Robbers can strike when you open the doors at WalMart or at the Bank.

The armored truck doesn’t solve your problem because it doesn’t provide end-to-end protection. The middle part of the money’s journey from customer to bank account is protected, but the first part and the last part of the journey happen outside the truck, and the money is vulnerable there.

The same is true for encryption-based DRM. End-to-end protection requires that the material be protected all the way from the performer, to the customer’s eyes and ears. If you leave the content unprotected anywhere along that path, it’s vulnerable. And encryption can’t protect the entire path, in the same way that the armored truck can’t protect the money’s entire path. You can’t seal the content inside its envelope of encryption until after it has been recorded, and you have to unseal it before you can play it for the customer.

The lack of end-to-end protection is especially serious for DRM systems, where one of the endpoints is under the control of the customer – who is the presumed adversary. It’s as if, in the armored-truck scenario, a criminal had control over the bank. If you have to open the truck’s doors at the bank, and the bank is controlled by a bad guy, then you’re sunk. It doesn’t matter how strong your armored truck is.

This is the predicament that DRM faces. The content needs to be unwrapped at the endpoint, and the system doesn’t control the endpoint. The content is vulnerable, regardless of how strong your codes are.