November 23, 2024

Posts Comments

CD DRM: Threat Models and Business Models

January 24, 2006 by

Alex and I are working on an academic paper, “Lessons from the Sony CD DRM Episode”, which will analyze several not-yet-discussed aspects of the XCP and MediaMax CD copy protection technologies, and will try to put the Sony CD episode in context and draw lessons for the future. We’ll post the complete paper here next Friday. Until then, we’ll post drafts of a few sections here. We have two reasons for this: we hope the postings will be interesting in themselves, and we hope your comments will help us improve the paper.

Today’s excerpt is from a section early in the paper, where we are still setting the scene before the main technical discussion begins:

Threat Models and Business Models

Before analyzing the security of any system, we need to ask what the system is trying to accomplish: what its threat model is. In the case of CD DRM, the system’s goals are purely economic, and the technical goals of the system exist only to protect or enable the business models of the record label and the DRM vendor. Accordingly, any discussion of threat models must begin and end by talking about business models.

It is important to note that the record label and the DRM vendor are separate entities whose goals and incentives are not always aligned. Indeed, we will see that incentive differences between the label and the DRM vendor can be an important factor in understanding the design and deployment of CD DRM systems.

Record Label Goals

The record label would like to prevent music from the CD from becoming generally available on peer-to-peer file sharing networks, but this goal is clearly infeasible. If even one user succeeds in ripping an unprotected copy of the music and putting that copy onto P2P networks, then the music will be generally available. Clearly no CD DRM system can be nearly strong enough to stop this from happening; and as we will see below, real systems do not even try to achieve the kind of comprehensive coverage of all major computing platforms that we would needed as a prerequisite for stopping P2P sharing of protected music. We conclude that the goal of CD DRM systems cannot be to prevent P2P file sharing.

The record label’s goal must therefore be to stop many users from making disc-to-disc copies or from engaging in other forms of local copying or use of the music. By preventing local copying, the record company might be able to sell more copies of the music. For example, if Alice cannot make a copy of a CD to give to Bob, Bob might buy another copy from the record label.

By controlling other local uses, the record company might be able to charge extra fee for those uses. For example, if the record label can stop Alice from downloading music from a CD into her iPod, the label might be able to charge Alice an extra fee for iPod downloads. Charging extra for iPod downloads creates a new revenue stream for the label, but it also reduces the value to users of the original CD and therefore reduces the revenue that the label can extract from CD sales. Whether the new revenue stream outweighs the loss of CD revenue depends on detailed assumptions about customer preferences, which may not be easy for the label to determine in practice. For our purposes, it suffices to say that the label wants to establish control over the uses made by at least some users, because that control will tend generally to increase the label’s profit.

We note also that the record company’s profit-maximizing strategy in this regard is largely independent of the contours of copyright law. Whether the label would find it more profitable to control a use, as opposed to bundling it with the CD purchase, is a separate question from whether the law gives the label the right to file lawsuits relating to that use. Attempting to enforce copyright law exactly as written is almost certainly not the record label’s profit-maximizing strategy.

Monetizing the Platform

Even beyond its effect on controlling copying and use of content, CD DRM can generate revenue for the record label because it installs and runs software on users’ computers. The label can monetize this installed platform in various ways. For example, the DRM software comes with a special music-player application which is used to listen to the protected disc. This application can display advertisements or other promotional material that creates value for the label. Alternatively, the platform can gather information about the user’s music listening habits, and that information can be exploited for some business purpose. If these tactics are taken too far, the DRM software can become spyware. Even if these tactics are pursued more moderately, users may still object; but the record company may use these tactics anyway if it believes the benefits to it outweigh the costs.

DRM Vendor Goals

The DRM vendor’s primary goal, obviously, is to provide value to the record label, in order to maximize the price that the vendor can charge the label for using the DRM technology. If this were the only factor, then the incentives of the vendor and the label would be perfectly aligned and there would be no need to consider the vendor’s incentives separately.

However, there are at least two ways in which the DRM vendor’s incentives diverge from the record label’s. First, the vendor has a much larger tolerance for risk than the label does. The label is a large, established business with a valuable brand name. The vendor (at least in the cases at issue here) is a start-up company struggling to establish itself. The label has much more to lose than the vendor does if something goes horribly wrong. Accordingly, we can expect the vendor to be much more willing to accept security risks than the label is.

The second incentive difference is that the vendor can monetize the installed platform in ways that are not available to the record label. For example, once the vendor’s software is installed on a user’s system, the software can control copying and use of other labels’ CDs. Having a larger installed base makes the vendor’s product more
attractive to other labels. Because the vendor gets this extra benefit from installing the software, the vendor has an incentive to be more aggressive about pushing the software onto users’ computers than the label would be.

In short, the vendor’s incentives diverge from the label’s incentives in ways that make the vendor more likely to (a) cut corners and accept security and reliability risks, and (b) push its software onto more user’s computers, even in some cases where the label would prefer to do otherwise. If the label knew everything about how the vendor’s technology worked, then this would not be an issue – the label would simply insist that the vendor protect its interests. But if some aspects of the vendor’s design are withheld from the label as proprietary, or if the label is not extremely diligent in monitoring the vendor’s design choices – both of which are likely in practice – then the vendor will sometimes act against the label’s interests.

Filed Under: Uncategorized Tagged With: , , , ,

Google Video and Privacy

January 20, 2006 by

Last week Google introduced its video service, which lets users download free or paid-for videos. The service’s design is distinctive in many ways, not all of them desirable. One of the distinctive features is a DRM (anti-infringement) mechanism which is applied if the copyright owner asks for it. Today I want to discuss the design of Google Video’s DRM, and especially its privacy implications.

First, some preliminaries. Google’s DRM, like everybody else’s, can be defeated without great difficulty. Like all DRM schemes that rely on encrypting files, it is vulnerable to capture of the decrypted file, or to capture of the keying information, either of which will let an adversary rip the video into unprotected form. My guess is that Google’s decision to use DRM was driven by the insistence of copyright owners, not by any illusion that the DRM would stop infringement.

The Google DRM system works by trying to tether every protected file to a Google account, so that the account’s username and password has to be entered every time the file is viewed. From the user’s point of view, this has its pros and cons. On the one hand, an honest user can view his video on any Windows PC anywhere; all he has to do is move the file and then enter his username and password on the new machine. On the other hand, the system works only when connected to the net, and it carries privacy risks.

The magnitude of privacy risk depends on the details of the design. If you’re going to have a DRM scheme that tethers content to user accounts, there are three basic design strategies available, which differ according to how much information is sent to Google’s servers. As we’ll see, Google apparently chose the design that sends the most information and so carries the highest privacy risk for users.

The first design strategy is to encrypt files so that they can be decrypted without any participation by the server. You create an encryption key that is derived from the username and password associated with the user’s Google account, and you encrypt the video under that key. When the user wants to play the video, software on the user’s own machine prompts for the username and password, derives the key, decrypts the video, and plays it. The user can play the video as often as she likes, without the server being notified. (The server participates only when the user initially buys the video.)

This design is great from a privacy standpoint, but it suffers from two main drawbacks. First, if the user changes the password in her Google account, there is no practical way to update the user’s video files. The videos can only be decrypted with the user’s old password (the one that was current when she bought the videos), which will be confusing. Second, there is really no defense against account-sharing attacks, where a large group of users shares a single Google account, and then passes around videos freely among themselves.

The second design tries to address both of these problems. In this design, a user’s files are encrypted under a key that Google knows. Before the user can watch videos on a particular machine, she has to activate her account on that machine, by sending her username and password to a Google server, which then sends back a key that allows the unlocking of that user’s videos on that machine. Activation of a machine can last for days, or weeks, or even forever.

This design addresses the password-change problem, because the Google server always knows the user’s current password, so it can require the current password to activate an account. It also addresses the account-sharing attack, because a widely-shared account will be activated on a suspiciously large number of machines. By watching where and how often an account is activated, Google can spot sharing of the account, at least if it is shared widely.

In this second design, more information flows to Google’s servers – Google learns which machines the user watches videos on, and when the user first uses each of the machines. But they don’t learn which videos were watched when, or which videos were watched on which machine, or exactly when the user watches videos on a given machine (after the initial activation). This design does have privacy drawbacks for users, but I think few users would complain.

In the third design, the user’s computer contacts Google’s server every time the user wants to watch a protected video, transmitting the username and password, and possibly the identity of the video being watched. The server then provides the decryption key needed to watch that particular video; after showing the video the software on the user’s computer discards the key, so that another handshake with the server is needed if the user wants to watch the same video later.

Google hasn’t revealed whether or not they send the identity of the video to the server. There are two pieces of evidence to suggest that they probably do send it. First, sending it is the simplest design strategy, given the other things we know about Google’s design. Second, Google has not said that they don’t send it, despite some privacy complaints about the system. It’s a bit disappointing that they haven’t answered this question one way or the other, either to disclose what information they’re collecting, or to reassure their users. I’d be willing to bet that they do send the identity of the video, but that bet is not a sure thing. [See update below.]

This third design is the worst one from a privacy standpoint, giving the server a full log of exactly where and when the user watches videos, and probably which videos she watches. Compared to the second design, this one creates more privacy risk but has few if any advantages. The extra information sent to the server seems to have little if any value in stopping infringement.

So why did Google choose a less privacy-friendly solution, even though it provided no real advantage over a more privacy-friendly one? Here I can only speculate. My guess is that Google is not as attuned to this kind of privacy issue as they should be. The company is used to logging lots of information about how customers use its services, so a logging-intensive solution would probably seem natural, or at least less unnatural, to its engineers.

In this regard, Google’s famous “don’t be evil” motto, and customers’ general trust that the company won’t be evil, may get Google into trouble. As more and more data builds up in the company’s disk farms, the temptation to be evil only increases. Even if the company itself stays non-evil, its data trove will be a massive temptation for others to do evil. A rogue employee, an intruder, or just an accidental data leak could cause huge problems. And if customers ever decide that Google might be evil, or cause evil, or carelessly enable evil, the backlash would be severe.

Privacy is for Google what security is for Microsoft. At some point Microsoft realized that a chain of security disasters was one of the few things that could knock the company off its perch. And so Bill Gates famously declared security to be job one, thousands of developers were retrained, and Microsoft tried to change its culture to take security more seriously.

It’s high time for Google to figure out that it is one or two privacy disasters away from becoming just another Internet company. The time is now for Google to become a privacy leader. Fixing the privacy issues in its video DRM would be a small step toward that goal.

[Update (Feb. 9): A Google representative confirms that in the current version of Google Video, the identity of the video is sent to their servers. They have updated the service’s privacy policy to disclose this clearly.]

Filed Under: Uncategorized Tagged With: ,

Open Thread: SonyBMG Lawsuit Settlement

December 29, 2005 by

SonyBMG has reportedly reached a settlement agreement in the class action lawsuits. Alex Eckelberry has posted the motion proposing the settlement, and a brief summary of its terms. The settlement must be approved by a court before taking effect.

We’re on holiday hiatus, so I won’t analyze the settlement now. Feel free to discuss it in the comments, though.

(Update: Discussion had already started in the comments on another post, starting here. It has moved over here now.)

(Update 2: Jim Tyre pointed out that what I had previously called the “settlement” was actually a motion asking the court to approve the settlement. I modified the text to reflect this, and I added a link to the actual settlement.)

Filed Under: Uncategorized Tagged With: , , ,

Sony CDs and the Computer Fraud and Abuse Act

December 21, 2005 by

We’ve written plenty here about the adventures of SonyBMG, First4Internet, and SunnComm/MediaMax in CD copy protection. Today, I want to consider whether the companies violated the Computer Fraud and Abuse Act (CFAA), which is the primary Federal law banning computer intrusions and malware. A CFAA violator is subject to criminal enforcement and to civil suits filed by victims.

A major caveat is in order: remember that although I have studied this statute, I am not a lawyer. I think I know enough to lay out the issues, but I won’t pretend to give a firm legal opinion on whether the companies have violated the CFAA. Also, bear in mind that the facts are different as to First4Internet (which designed and distributed the XCP software), SunnComm/MediaMax (which designed and distributed the MediaMax software), and SonyBMG (which distributed both software systems but may have known less about how they worked).

There are two relevant provisions in the CFAA. The first one, which I’ll call the “spying provision”, says this:

Whoever … intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains … information from any protected computer if the conduct involved an interstate or foreign communication … shall be punished …

The second one, which I’ll call the “damage provision”, says this:

Whoever … intentionally accesses a protected computer without authorization, and as a result of such conduct, causes damage … shall be punished …

(“Protected computer” is defined in the CFAA to include nearly every computer at issue here.)

Let’s look first at the spying provision. We know that the programs obtained information from the user’s computer (about how the user used the CD drive) and sent that information across the Net to either SonyBMG or SunnComm. In most cases that would be interstate communication. So the main issue would seem to be whether the companies, in installing their software on a user’s computer, intentionally accessed the computer without authorization or exceeded authorized access.

According to the CFAA,

the term “exceeds authorized access” means to access a computer with authorization and to use such access to obtain or alter information in the computer that the accesser is not entitled so to obtain or alter

In the case of XCP, the software that gathers and sends information only gets installed if the user agrees to an End User License Agreement (EULA), so the company is authorized to access the computer. They might still have exceeded authorized access, if the EULA’s terms did not entitle them to obtain some information that they obtained. Given the vagueness of the EULA language, this seems like a close call. Eric Goldman has argued that a court would give XCP the benefit of the doubt.

Things look worse for MediaMax. The company sometimes installs its software even if the user rejects the EULA. In this case the company is not authorized to put software on the user’s computer or to cause that software to run. But they do it anyway. It’s hard to see how that’s not either accessing without authorization or exceeding authorized access. It looks like MediaMax is in jeopardy on the spying provision.

Sony’s position here is interesting. They shipped the affected software, but they may not have known as much about how it worked. The spying provision applies only if the company accessed the computer (or exceeded authorized access) “intentionally”. If Sony didn’t know that MediaMax installed when the user denied the EULA, then Sony may be in the clear even if MediaMax itself is in violation.

Let’s turn now to the damage provision. This provision covers access without authorization, but doesn’t cover exceeding authorization. As I understand it, this means that you’re not in violation if you had any kind of authorization to access the computer.

The provision also requires that there be “damage”. According to the CFAA, damage includes “any impairment to the integrity or availability of data, a program, a system, or information, that causes loss aggregating at least $5,000 in value during any 1-year period to one or more individuals”. As I understand it, the cost of detecting and mitigating a problem, including the value of time spent by people on detection and mitigation, can be included in the loss. Given that, there can be little doubt that each of these software systems caused damage of more than $5000 total. For example, if a system was installed on 100,000 computers and imposed at least five cents in detection and mitigation costs on each one of those computers, the aggregate damage is more than $5000.

It seems clear, too, that the installation of a rootkit, or the installation of software without permission – not to mention the security vulnerabilities caused by the software – constitutes an impairment to the integrity of users’ systems.

So the main sticking point in the damage provision would seem to be access without authorization. XCP gets a limited authorization to access the computer when the user agrees to the EULA, so they would seem to be okay. But when MediaMax installs despite the user rejecting the EULA, that looks to me like access without authorization. Again, it looks like MediaMax may be in trouble.

The word “intentionally” pops up in again in the damage provision, and again it might protect SonyBMG, if SonyBMG did not know that the software was designed to install without authorization.

There are two more issues regarding the damage provision. The first one is a possible objection from MediaMax, claiming that although the unauthorized installation may have been intentional, the damage was not intentional. As I understand it, courts have rejected this reading of the CFAA, holding that only the access must be intentional, but the statute applies even if the damage was an accident. It’s easy to understand why Congress would have wanted to write the law that way, to say that if you intentionally break in to somebody’s computer, you are responsible for any damage you cause to that computer, even if the damage happens accidentally.

The last issue is whether the companies had authorization to install or run software immediately upon insertion of the CD into the computer, even before the user is presented with a EULA. I think there’s a good argument that the companies ran more software than they were authorized to run in that situation, but it seems like a stretch to argue that they had no authorization to do anything at all. It seems reasonable to allow them to at least run enough software to pop up a EULA. In any case, it would be hard to find $5000 in damage from this behavior.

So here’s my very tentative bottom line: XCP is in the gray area but is probably okay; MediaMax may well be in violation; and Sony’s status depends on how much they knew about what the MediaMax software did. Perhaps a court hearing one of the SonyBMG lawsuits will give us its own analysis.

UPDATE (1:30 PM EST): In the comments, Sam points out an important issue that I missed in writing this post. Even if SonyBMG did not know from the beginning that MediaMax installs and runs without authorization, they did find out about it eventually, and they kept shipping MediaMax discs anyway. So the software’s behavior would seem to be intentional on Sony’s part, at least with respect to those discs sold after Sony learned about the MediaMax behavior. ]

Filed Under: Uncategorized Tagged With: , , ,

Is DRM Good for You?

December 19, 2005 by

Randy Picker, a principled DRM (copy protection) advocate, had an interesting comment on one of my prior posts about the Sony incident. Here’s the core of it:

Assume for now that you are right that DRM leads to spyware; all that means is that we need to figure out whether we should or shouldn’t favor active protection/supervision environments.

That gets us to the central point: namely the fact that consumers don’t want it doesn’t tell us anything about whether it is in the joint interests of consumers and producers. I spent the morning writing my exam and then will have to grade it after the students take it (no grad student graders for law profs). By far and away the worst part of the job, and I certainly don’t want it as part of the job, but that doesn’t mean that it isn’t jointly sensible.

Putting that point slightly differently, consumers may gain more from a DRM world than they would from whatever alternative world emerges without DRM; those subject to restrictions rarely want them but restrictions are frequently welfare maximizing; the fact that one party would like to get rid of the restrictions tells me little (nothing, probably) about whether the restriction is in the joint interest of the parties to the transaction.

It’s true in principle that an arrangement can be unwanted but ultimately good for those on whom it is imposed; but I don’t think that observation matters much in the specific case of CD DRM.

To understand why, let’s look at a case where a similar argument has traditionally worked: copyright. Copyright can be understood as an agreement among all of us that we will not infringe. Even though each of us individually would prefer to use works without paying, we understand that if we all refrain from infringing this increases incentives for authors, leading to the creation of more works we can enjoy. By making and keeping this copyright deal with each other, we come out ahead. (That’s the theory anyway. We all know what happens when the lobbyists show up, but work with me here, okay?)

One of the practical problems with this kind of deal is that each individual can gain by defecting from the deal – in the case of copyright, by infringing at will. If enough people defect, the deal could collapse. This danger is especially acute when it’s technologically easy to defect. Some people argue that this is happening to the copyright deal.

Anyway, what Randy is suggesting is that there might be a similar deal in which we all agree to accept some kind of DRM in order to boost incentives for authors and thereby cause the creation of more works than would otherwise exist. I think that if we weigh the costs and benefits, that would be a bad deal. And I’m especially sure it’s a bad deal for CD DRM. Let me explain why.

First, it turns out to be easy technologically to defect from the CD-DRM deal. Experience with the copyright deal teaches us that when it’s easy to defect, many people will, whether we like it or not.

Second, the costs of the CD-DRM deal seem much clearer than the benefits. Allowing spyware-DRM on our computers will open loopholes in our anti-spyware defenses that will foster more spyware infections. And as we have seen already, spyware-DRM will itself expose us to security risks. That’s the cost side. On the benefit side, we have only the dubious premise that CD-DRM might boost record sales. The costs are more certain, and larger.

The best argument against the CD-DRM deal, though, is that it is inferior to the copyright deal. If we’re going to make and keep a deal of this general type, the copyright deal is the one to pick. Compared to the copyright deal, the CD-DRM deal is a loser: costs are higher, benefits are the same at best, and the deal is just as easy to defect from. If we can’t keep the copyright deal, then we won’t be able to keep the CD-DRM deal either. But more to the point, we shouldn’t make the CD-DRM deal in the first place.

I’ve looked here at the specific case of DRM for CDs, but I think the same argument holds for other types of DRM as well. Leaving aside the mythical side-effect-free DRM systems and perfectly just legal regimes that some DRM advocates dream about, and looking instead at DRM systems and legal rules that could actually exist and how they would work in practice – as I am sure Randy and other principled DRM advocates would want us to do – the available DRM deals look lousy. Certainly they look worse than the original copyright deal.

Now I’m not arguing here that the current copyright deal is perfect or even close to perfect. The copyright deal is under stress and we need to keep thinking about how we might improve it or how we might renegotiate it to work better in the digital world. I’m not certain what the best deal would look like, but I’m pretty sure that it won’t try to lock in any kind of DRM.

Filed Under: Uncategorized Tagged With: , , , ,