December 23, 2024

Posts Comments

CD DRM: Attacks on Disc Recognition

January 26, 2006 by

Ed 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 the middle of the paper, where we’re wading through details about the copy protection systems and the techniques they use to recognize protected CDs.

Please note that this is a draft and should not be formally quoted or cited. The final version of our entire paper will be posted here when it is ready.

Attacks on Disk Recognition

The active protection mechanisms introduced earlier selectively regulate access to raw CD audio, blocking access to the audio tracks on albums protected with a particular scheme while allowing access to all other titles. To accomplish this, the schemes install a background process that interposes itself between applications and the original CD driver. In MediaMax, this process is a kernel-mode driver called sbcphid.sys. XCP uses a pair of filter drivers attached to the CD-ROM and IDE devices called crater.sys and cor.sys. In both schemes, the active protection drivers examine each disc that is inserted into the computer to see whether access to it should be restricted. If the disc is recognized as copy protected, the drivers monitor for attempts to read the audio tracks, as would occur during a playback, rip, or disc copy operation, and corrupt the audio returned by the drive to degrade the listening experience. MediaMax introduces a large amount of random jitter, making the ripped audio sound like it has come from a badly scratched or damaged CD; XCP replaces the audio with random noise.

Each scheme’s active protection software interferes with attempts to rip or copy any disc that is protected by the same scheme, not merely the disc from which the software was installed. This requires some mechanism for identifying discs that are to be protected. This section discusses the security requirements for such a recognition system, describes the design and limitations of the actual recognition mechanism employed by the MediaMax scheme, and presents an improved design that better satisfies the requirements.

Recognition Requirements

Any disc recognition system must involve detecting some identifying feature on discs protected by a particular scheme. Ideally, such a feature would satisfy these requirements:

  1. Uniqueness. The feature should identify protected discs without accidentally triggering the copy protection on unprotected titles.
  2. Detectability. It should be possible for the active protection drivers running on client systems to reliably and quickly detect the feature in protected discs. In practice, this limits the amount of audio that can be read from the disc before deciding whether to apply protection.
  3. Indelibility. The feature should be difficult to remove without substantially degrading the quality of the audio; that is, it should be difficult to make a copy of the copy protected disc that does not itself trigger the protection.
  4. Unforgeability. It should be difficult to apply the feature to an unprotected album without the cooperation of the protection vendor, even if the adversary has access to protected discs.

This last requirement stems from the business strategies of the copy protection vendors. As discussed in earlier, many of these vendors are pursuing a platform building strategy. The biggest obstacle to the success of an active protection system is getting the protection software installed on client machines. Once installed, the software can regulate access to all discs protected by the scheme, even if the user learns to disable autorun or refuse future CD DRM installation requests. Thus each completed installation increases the effectiveness of the protection platform and heightens its value to the protection vendor and its music label clients.

Being widely installed adds value to these copy protection systems, but it also exposes them to a new class of attacks. The protection companies earn revenue from record labels who license their schemes, typically paying some fee per title or per copy. This revenue stream may be threatened if disc publishers can mark their discs as protected without paying.

There are advantages and disadvantages for the person placing the unauthorized marks. Copyright would prohibit rogue publishers from distributing an installer for the active protection software, though they might depend on the existing installed base from licensed titles. They would also be prevented from employing the components of the protection software that allow users to access restricted copies of the music; however, they could create their own software to provide this capability if they desired. On the other hand, free riding publishers would not be restricted to marking their disc for only one scheme. By identifying their discs as copy protected with multiple schemes, they could invoke multiple layers of security and provide stronger protection than is available with any single technique, all without paying. (It is possible that protection producers could have legal remedies against such free riders, such as through a patented identification feature, but we are unaware of any patents that cover the identification features known to be in use. Even if some kind of legal remedy is available, it’s worth designing the mark to prevent the problem too, at least if the cost of doing so is low.) Preventing free riding by publishers requires some kind of disc authentication mechanism to control access to installed active protection software—a meta-copy protection technique.

How MediaMax Recognizes Protected Discs

To find out how the disc recognition mechanisms employed by CD DRM systems stack up the ideal requirements, we examined the recognition system built into MediaMax CD-3 and MM-5 systems. The MediaMax system drew our attention because MediaMax’s creators have touted their advanced disc identification capabilities, including the ability to identify individual tracks within a compilation as protected, and well as their platform-building strategy. (The XCP scheme appears to use a less sophisticated disc recognition system based on a marker stored in the data track of protected discs. We may talk more about it later.)

We determined how MediaMax identifies protected albums by tracing the commands sent to the CD drive with and without the active protection software running. These experiments took place on a Windows XP virtual machine running on top of a Fedora Linux host system, which we modified by patching the kernel IDE-SCSI device to log all drive activity.

With this setup we observed that the MediaMax software executes a disc recognition procedure immediately upon the insertion of a CD. The MediaMax driver reads two sectors of audio data at a specific offset from the beginning of audio tracks—approximately 365 and 366 frames in (a CD frame is 1/75 second). On unprotected discs, the software scans through every track in this way, but on MediaMax-protected albums, it stops after the first three tracks, apparently having detected an identifying feature. The software decides whether or not to block read access to the audio solely on the basis of information in this region, so we inferred that the identifying mechanism takes the form of an inaudible watermark embedded in this part of the audio stream. (By locating the watermark nearly five seconds after the start of the track, MediaMax reduces the likelihood that it will occur in a very quiet passage, where it might be more audible, and makes it more difficult to crop out.)

Locating the watermark amid megabytes of audio might have been difficult, but we had the advantage of a virtual Rosetta Stone. The actual Rosetta Stone is a 1500 lb. granite slab unearthed by French archaeologists in Rosetta, Egypt, in 1799. A single Ptolemaic decree is written on the stone in three scripts: ancient hieroglyphics, demotic (simplified) hieroglyphics, and Greek. Comparing these inscriptions provided the key to deciphering Egyptian hieroglyphic texts. Our Rosetta Stone was a single album, Velvet Revolver’s Contraband (BMG, 2004), released in three different versions: a U.S. release protected by MediaMax, a European release protected by a passive scheme developed by Macrovision, and a Japanese release with no copy protection. We decoded the MediaMax watermark by examining the differences between the audio on these three discs. Binary comparison revealed no differences between the releases from Europe and Japan; however, the MediaMax-protected U.S. release differed slightly from the other two in certain parts of the recording. By carefully analyzing these differences—and repeatedly attempting to create new watermarked discs using the MediaMax active protection software as an oracle—we were able to deduce the structure of the watermark.

The MediaMax watermark is embedded into the audio of each track in 30 clusters. Each cluster is made up of 288 marked 16-bit audio samples followed by 104 unaltered samples. Three mark clusters exactly fit into one 2352-byte CD audio frame. The watermark is centered at approximately frame 365 of the track; though the detection routine in the software only reads two frames, the mark extends several frames to either side of the designated read target to allow for imprecise seeking in the audio portion of the disc (a typical shortcoming of inexpensive CD drives). The MediaMax driver detects the watermark if at least one mark cluster is present in the region read by the detector.

A sequence of 288 bits we call the raw watermark is embedded into the 288 marked audio samples of each mark cluster. A single bit of the raw watermark is embedded into an unmarked audio sample by setting one of the three least significant bits to the new bit value (as shown in bold) and then patching up the two other bits, according to this table:

(This design seems to be intended to lessen the audible distortion caused by by setting one of the bits to the watermark value. The change in the other two bits reduces the magnitude of the difference from the original audio sample, but it also introduces a highly uneven distribution in the three LSBs that makes the watermark easier to detect or remove.)

The position of the embedded bit in each sample follows a fixed sequence for every mark cluster. Each of the 288 bits is embedded in the first-, second-, or third-least-significant bit position of the sample according to this sequence:

2,3,1,1,2,2,3,3,2,3,3,3,1,3,2,3,2,1,3,2,2,3,2,2,2,1,3,3,2,1,2,3,3,1,2,2,3,
1,2,3,3,1,1,2,2,1,1,3,3,1,2,3,1,2,3,3,1,3,3,2,1,1,2,3,2,2,3,3,3,1,1,3,1,2,
1,2,3,3,2,2,3,2,1,2,2,1,3,1,3,2,1,1,2,1,1,1,2,3,2,1,1,2,3,2,1,3,2,2,2,3,1,
2,1,3,3,3,3,1,1,1,2,1,1,2,2,2,2,3,1,2,3,2,1,3,1,2,2,3,1,1,3,1,1,1,1,2,2,3,
2,3,2,3,2,1,2,3,1,3,1,3,3,3,1,1,2,1,1,2,1,3,3,2,3,3,2,2,1,1,1,2,2,1,3,3,3,
3,3,1,3,1,1,3,2,2,3,1,2,1,2,3,3,2,1,1,3,2,1,1,2,2,1,3,3,2,2,3,1,3,2,2,2,3,
1,1,1,1,3,2,1,3,1,1,2,2,3,2,3,1,1,2,1,3,2,3,3,1,1,3,2,1,3,1,2,2,3,1,1,3,2,
1,2,2,2,1,3,3,1,2,3,3,3,1,2,2,3,1,2,3,1,1,3,2,2,1,3,2,1,3

The 288-bit raw watermark is detected by the active protection software only when it has certain properties, as shown in the sequence below. In the 288-bit sequence, 96 positions have fixed bit values, either 0 or 1. The trailing 32 positions have arbitrary values (as indicated by _), and can be used to store a 32-bit disc-specific value. The other 192 positions are divided into 32 groups of linked values (denoted a–z and alpha-zeta). In each group, three positions share the same value and three share the complement value. This allows the scheme to encode a second 32-bit value, though in actual discs it appears to be a different random value in each of the 30 mark clusters.

Attacks on the MediaMax Watermark

The MediaMax watermark fails to satisfy the indelibility and unforgeability requirements of an ideal disc recognition system. Far from being indelible, the mark is surprisingly brittle. Most advanced designs for robust audio watermarks manipulate the audio in the frequency domain and attempt to resist removal by lossy compression, multiple conversions between digital and analog formats, and other common transformation. In contrast, the MediaMax watermark is applied in the time domain and is rendered undetectable by even minor changes to the file. An adversary without any knowledge of the watermark’s design could remove it by converting the tracks to a lossy format like MP3 and then burning them back to a CD, which can be accomplished easily with standard consumer applications. This would result in some minor loss of fidelity, but a more sophisticated adversary could prevent the mark from being detected with almost no degradation by flipping the least significant of one carefully chosen sample from each of the 30 watermark clusters, thereby preventing the mark from exhibiting the pattern required by the detector.

The MediaMax watermark also fails to satisfy the unforgeability requirement. The mark’s only defense against forgery is its complicated, unpublished design, but as is often the case this security by obscurity has proved tedious rather than impossible to defeat. As it turns out, an adversary needs only limited knowledge of the watermark–its location within a protected track and its confinement to the three LSBs of each sample–to forge it with minimal loss of fidelity. Such an attacker could transplant the three LSBs of each sample within the watermarked region of a protected track to the corresponding sample from an unprotected one. Transplanting these bits would cause distortion more audible that that caused by embedding the watermark since the copied bits are likely to differ by a greater amount from the original sample values; however, the damage to the audio quality would be limited since the marked region is only 0.4 seconds in duration. A more sophisticated adversary could apply a watermark to an unprotected track by deducing the full details of the structure of the watermark, as we did; she could then embed the mark in an arbitrary audio file just as well a licensed disc producer.

Secure Disc Recognition

Having shown that the MediaMax watermark fails to provide either strong resistance to removal or strong resistance to forgery, we ask whether it is possible to securely accomplish either or both of these goals.

As far as indelibility is concerned, watermarking schemes have a poor history of resisting removal. This is especially true against an adversary who has oracle access to the watermark detector, as was the case with a previous application of watermarks to audio copy protection, SDMI, and with CD DRM systems. Making marks that are both indelible and unforgeable is likely much more difficult. There seems to be tension between marks that are difficult to remove and ones that are hard to forge. Enforcing both requirements creates two ways to fool the detector–by rendering the mark invisible and by making it appear forged. If, as in CD DRM, either situation leads to the same result (no protection), the attacker’s power is multiplied.

In contrast, a mark strongly robust to forgery is simple to create based on digital signatures if we aren’t concerned with its being easy to remove. A very simple scheme works as follows:

  • To sign an audio track, the licensed publisher reads a fixed portion L1 of the audio data (say, the first ten seconds), then computes a cryptographic hash of L1 and signs it using a public key signature algorithm to derive the signature SL1 := SignKS(Hash(L1)). SL1 is then stored at a second location in the track by setting the LSB of each sample in the region to the corresponding bit in the signature. A 320-bit DSA signature could be embedded in this way using approximately the same space as one mark cluster of the MediaMax watermark.

  • The publisher keeps the signing key KS secret, and builds the corresponding verification key KV into the client software. When presented with a CD, the software checks for a valid signature. First it reads the audio from the signed area of the track and hashes it, and it locates and extracts the signature stored in the LSBs in the second mark location. Next, it verifies the signature on the hash using KV. If the signature is correct, the watermark is valid and genuine; otherwise, forgery or data corruption is indicated.

Forging such a mark would require defeating the digital signature scheme or splicing both L1 and SL1 from a legitimately marked album. We set L1 to be several seconds of audio to make such splicing less appealing.

Clearly this watermark is highly vulnerable to removal. If even a single bit of the hashed region is changed, the mark will not be recognized as valid. Yet the watermark MediaMax actually uses is also vulnerable to corruption by a single bit too while being far less resistant to forgery. Robustness to removal, while desirable in principle, is of limited value in real CD DRM applications. Removal of the watermark is unlikely to be the weakest link protecting the audio, and while the gains from creating a more indelible watermark are slight, the loss to free riders from an easily forgeable mark is potentially much larger.

Filed Under: Uncategorized Tagged With: , , ,

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: , , , ,

Analog Hole Bill Would Impose a Secret Law

January 23, 2006 by

If you’ve been reading here lately, you know that I’m no fan of the Sensenbrenner/Conyers analog hole bill. The bill would require almost all analog video devices to implement two technologies called CGMS-A and VEIL. CGMS-A is reasonably well known, but the VEIL content protection technology is relatively new. I wanted to learn more about it.

So I emailed the company that sells VEIL and asked for a copy of the specification. I figured I would be able to get it. After all, the bill would make compliance with the VEIL spec mandatory – the spec would in effect be part of the law. Surely, I thought, they’re not proposing passing a secret law. Surely they’re not going to say that the citizenry isn’t allowed to know what’s in the law that Congress is considering. We’re talking about television here, not national security.

After some discussion, the company helpfully explained that I could get the spec, if I first signed their license agreement. The agreement requires me (a) to pay them $10,000, and (b) to promise not to talk to anybody about what is in the spec. In other words, I can know the contents of the bill Congress is debating, but only if I pay $10k to a private party, and only if I promise not to tell anybody what is in the bill or engage in public debate about it.

Worse yet, this license covers only half of the technology: the VEIL decoder, which detects VEIL signals. There is no way you or I can find out about the encoder technology that puts VEIL signals into video.

The details of this technology are important for evaluating this bill. How much would the proposed law increase the cost of televisions? How much would it limit the future development of TV technology? How likely is the technology to mistakenly block authorized copying? How adaptable is the technology to the future? All of these questions are important in debating the bill. And none of them can be answered if the technology part of the bill is secret.

Which brings us to the most interesting question of all: Are the members of Congress themselves, and their staffers, allowed to see the spec and talk about it openly? Are they allowed to consult experts for advice? Or are the full contents of this bill secret even from the lawmakers who are considering it?

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: ,

CGMS-A + VEIL = SDMI ?

January 17, 2006 by

I wrote last week about the Analog Hole Bill, which would require almost all devices that handle analog video signals to implement a particular anti-copying scheme called CGMS-A + VEIL. Today I want to talk about how that scheme works, and what we can learn from its design.

CGMS-A + VEIL is, not surprisingly, a combination of two discrete signaling technologies called CGMS-A and VEIL. Both allow information to be encoded in an analog video signal, but they work in different ways.

CGMS-A stores a few bits of information in a part of the analog video signal called the vertical blanking interval (VBI). Video is transmitted as a series of discrete frames that are displayed one by one. In analog video signals, there is an empty space between the frames. This is the VBI. Storing information there has the advantage that it doesn’t interfere with any of the frames of the video, but the disadvantage that the information, being stored in part of the signal that nobody much cares about, is easily lost. (Nowadays, closed captioning information is stored in the VBI; but still, VBI contents are easily lost.) For example, digital video doesn’t have a VBI, so straight analog-to-digital translation will lose anything stored in the VBI. The problem with CGMS-A, then, is that it is too fragile and will often be lost as the signal is stored, processed, and translated.

There’s one other odd thing about CGMS-A, at least as it is used in the Analog Hole Bill. It’s remarkably inefficient in storing information. The version of CGMS-A used there (with the so-called RCI bit) stores three bits of information (if it is present), so it can encode eight distinct states. But only four distinct states are used in the bill’s design. This means that it’s possible, without adding any bits to the encoding, to express four more states that convey different information about the copyright owner’s desires. For example, there could be a way for the copyright owner to signal that the customer was free to copy the video for personal use, or even that the customer was free to retransmit the video without alteration. But our representatives didn’t see fit to support those options, even though there are unused states in their design.

The second technology, VEIL, is a watermark that is inserted into the video itself. VEIL was originally developed as a way for TV shows to send signals to toys. If you pointed the toy at the TV screen, it would detect any VEIL information encoded into the TV program, and react accordingly.

Then somebody got the idea of using VEIL as a “rights signaling” technology. The idea is that whenever CGMS-A is signaling restrictions on copying, a VEIL watermark is put into the video. Then if a signal is found to have a VEIL watermark, but no CGMS-A information, this is taken as evidence that CGMS-A information must have been lost from that signal at some point. When this happens, the bill requires that the most restrictive DRM rules be applied, allowing viewing of the video and nothing else.

Tellingly, advocates of this scheme do their best to avoid calling VEIL a “watermark”, even though that’s exactly what it is. A watermark is an imperceptible (or barely perceptible) component, added to audio or video signal to convey information. That’s a perfect description of VEIL.

Why don’t they call it a watermark? Probably because watermarks have a bad reputation as DRM technologies, after the Secure Digital Music Initiative (SDMI). SDMI used two signals, one of which was a “robust” watermark, to encode copy control information in content. If the robust watermark was present but the other signal was absent, this was taken as evidence that something was wrong, and strict restrictions were to be enforced. Sound familiar?

SDMI melted down after its watermark candidates – all four of them – were shown to be removable by an adversary of modest skill. And an adversary who could remove the watermark could then create unprotected copies of the content.

Is the VEIL watermark any stronger than the SDMI watermarks? I would expect it to be weaker, since the VEIL technology was originally designed for an application where accidental loss of the watermark was a problem, but deliberate removal by an adversary was not an issue. So how does VEIL work? I’ll write about that soon.

UPDATE (23 Jan): An industry source tells me that one factor in the decision not to call VEIL a watermark is that some uses of watermarks for DRM are patented, and calling it a watermark might create uncertainty about whether it was necessary to license watermarking patents. Some people also assert (incorrectly, in my view) that a watermark must encode some kind of message, beyond just the presence of the watermark. My view is still that VEIL is accurately called a watermark.

Filed Under: Uncategorized Tagged With: ,