December 22, 2024

More on Unbreakable DRM

Ernest Miller at LawMeme likes my explanation of why unbreakable codes don’t mean unbreakable DRM. But he takes me to task for writing a posting that ignores fair use and assumes that the customer is the enemy.

I guess I should have been more explicit about my assumptions. I agree that fair use is important and that treating your customers like thieves is a dubious approach. The point I was trying to make is that even if you’re willing to ignore fair use and even if you’re willing to treat your customers as enemies, you still can’t build unbreakable DRM.

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.

DarkNet

Lots of buzz lately about the DarkNet paper written by four Microsoft Research people.

The paper makes a three-part argument. First, there is really no way to stop file sharing, as long as people want to share files. Second, in the presence of widespread file sharing, a copy-prevention technology must be perfect, for the presence in a file sharing environment of even a single uncontained copy of a work enables anyone who wants to infringe its copyright to do so. (This is what I call the “break once, infringe anywhere” model.) Finally, there is little if any hope that a copy-prevention (or “DRM”) technology can be strong enough to prevent the creation of single uncontained copies of works. So the conclusion is that the current DRM approach will not work.

This paper has gotten attention in the policy community because it is well written and makes a compelling argument. But its argument is far from new. Indeed, the paper’s claims have been the consensus of independent security experts for a few years already. You can see this, for instance, in Bruce Schneier’s writing on DRM.

So why has the DarkNet paper gotten this much attention? My guess is that there are two reasons. First, the paper was written by guys from Microsoft Research, and Microsoft has previously taken a pro-DRM position. The paper includes a standard disclaimer saying that it is the opinion of the authors and not of Microsoft. But still it reflects a change. In past years, conference presentations from industrial researchers, both at Microsoft and elsewhere, have shied away from anti-DRM statements, so as to keep their employers happy (although vigorous anti-DRM language could often be heard at dinner afterwards). So non-techies will put more weight on the paper because of its authors’ affiliation.

The second reason for the buzz around this paper is that the “DarkNet” terminology has a certain persuasive power, evoking a subterranean world of illicit activity, a sort of criminal underground of the Net. Although compelling, the “DarkNet” concept is misleading, if it is understood as implying that one can draw a neat line between the “legitimate Net” and the illegal “DarkNet”.

In practice, the same technologies are used to conceal both legal and illegal activity. You can use a safe to lock up either criminal plans or business data. You can use encryption to conceal either copyright infringement or love letters. You can use “sneakernet” (which is a DarkNet technology, according to the paper) to share software illegally with your neighbor, or to give baby pictures to grandparents. Attempts to regulate or ban the DarkNet often affect legitimate networking. Examples of this include both the Hollings CBDTPA, which would have regulate many innocuous devices (as documented in Fritz’s Hit List), and the Berman-Coble “P2P Hacking” bill, which would affect ordinary websites.

On balance, the DarkNet paper will be valuable not because it breaks new ground technically but because of its persuasive power. If it can move the policy debate forward, and onto sounder technical ground, that will be a major achievement.

Report from the ACM DRM Workshop

Yesterday I attended the ACM “Digital Rights Management” Workshop in Washington DC. There were about 100 attendees, most of them computer scientists, with a few lawyers and Washington policy types thrown in. Papers from the workshop are available online.

My main impression was that the speakers were more openly skeptical about DRM than at past conferences. I don’t think this represents any real change in opinion. The real cause, in my view, is that industrial researchers are now starting to say in public what they would only say in private before.

The skepticism about watermarking was especially strong. One speaker described a simple attack that apparently can defeat essentially all state-of-the-art watermarking methods. Another speaker’s paper says

Proposals for systems involving mandatory watermark detection in rendering devices try to impact the effectiveness of [file sharing systems]…. In addition to severe commercial and social problems, these schemes suffer from several technical deficiencies, which, in the presence of an effective [file sharing system], lead to their complete collapse. We conclude that such schemes are doomed to failure.

More Great Stuff From Seth Schoen

If you want to understand what the whole Palladium/LaGrande/”trusted computing” issue is about, you should read Seth Schoen’s recent writing. His analysis is insightful, technically sound, independent, and hype-free. For the latest example, click here, scroll down to “Trusted Computing,” and read the next several sections.